User Tag List

View Poll Results: What is your opinion of ZQuest Password Protection?

Voters
19. You may not vote on this poll
  • I believe password protection should be removed

    11 57.89%
  • I am indifferent to the presence of password protection

    5 26.32%
  • I use passwords to protect my quest but it is a feature I can live without

    3 15.79%
  • If password protection is no longer available I will cease utilizing ZQuest

    0 0%
Page 1 of 4 1 2 3 ... LastLast
Results 1 to 10 of 38

Thread: [Poll]: Password Protection for Quests

  1. #1
    Cor Blimey! CJC's Avatar
    Join Date
    Dec 2002
    Location
    Fading into the darkness
    Age
    35
    Posts
    1,398
    Mentioned
    150 Post(s)
    Tagged
    6 Thread(s)
    vBActivity - Stats
    Points
    6,618
    Level
    25
    vBActivity - Bars
    Lv. Percent
    0.96%

    [Poll]: Password Protection for Quests

    If you've been around lately you may have noticed a lot of threads discussing password protection and an open source code release for Zelda Classic and its editor ZQuest.

    This poll is to try and collect the raw numbers about passwords and their use in QST files.


    Here are the facts:
    1.) There IS a program available (somewhere) that lets anyone replace the hash of a password with the hash of a blank in the quest file, allowing anyone to open even protected quests.

    2.) All of ZQuest's developers are on board with the removal of the password system, as it will streamline the release of the source code.

    3.) There is an exploit that allows users to indirectly edit quests by abusing file names.

    4.) AGN staff took the position that password protection was made available and should remain for the benefit of the community. However, due to 1 and 3 above, the only real protection for quests and their content is our connection as a community and our ability to shun users that misappropriate the work of others.


    So... please select one of the poll options (if you use ZQuest to make custom games). You may elaborate in a reply if you so choose.


    EDIT:
    Quote Originally Posted by SUCCESSOR View Post
    Okay there is some misinformation in this thread. The idea that we have to remove passwords to release the source is silly. Encryption can stay in. Yes someone can simply fork the code to bypass it, just as they can fork the code anyway, just like they can write a [really] simple script to overwrite password hashes. But for most people the main branch will still be just as password protected as it is now.

    The AGN staff never agreed on any position on this topic. AGN staff and ZC Devs agreed that the community was not okay with releasing the code as is and that we should do whatever we can to protect quest encryption(an idea that has always been a catch 22). I have always supported releasing the code as is. Quest protection has never been secure and it has always been a bare minimum deterrent. If passwords were gone it would hardly change a thing, except maybe more people fixing bugs on their own to keep playing. Passwords can stay just stop pretending we are doing any service by removing the encryption code and delaying development. They will continue to serve bare minimum deterrent.

    Just about any idea for reworking quest protection has been discussed and rule as easily bypass-able. The only thing that would be an improvement would be to make quests self contained games completely changing how the software(and community sharing) works.
    I was under the impression that we had agreed that password protection would stay as a service to the community (as there was already the expectation that it was there). In the creation of this thread I may have paraphrased some of the issues incorrectly because I don't really understand file encryption, but it was never my intent to misinform anyone.
    SUCCESSOR knows what's going on, though, so you should give his words more weight than mine.

  2. #2
    Quest Builder Anarchy_Balsac's Avatar
    Join Date
    Nov 2005
    Posts
    751
    Mentioned
    11 Post(s)
    Tagged
    2 Thread(s)
    vBActivity - Stats
    Points
    2,590
    Level
    16
    vBActivity - Bars
    Lv. Percent
    63.38%
    I vote for option 1, if people can access the quests anyway, and our conceit is that we just do what other modding communities do about theft when that happens, then let's not waste the staff's development time protecting it. The only real benefit to keeping it seems to be that it will require the few who would try to dig a little harder than they would have to in other modding communities. I don't personally think that's enough to offset the downsides.

  3. #3
    Wizrobe
    Join Date
    Dec 2006
    Age
    29
    Posts
    3,692
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    8,930
    Level
    28
    vBActivity - Bars
    Lv. Percent
    42.29%
    I'm in favor of removing passwords. As of now, they serve no purpose other than creating a false sense of security. Programs to bypass password exists, as you mentioned. I know of at least two and I'm sure there are more. Anybody who wants to open a quest can, so all the password system do is create the illusion that, by putting a password on your quest, it's safe and cannot be opened. Therefore, it serves no real purpose, and removing it would actually aid in the future development of ZC by allowing an easier release of the source code. In light of all this, I see no reason for keeping password protection around, and vote to have it removed.
    Play The Darkness Within, my newest ZC Quest! Download here:
    http://www.purezc.net/index.php?page=quests&id=374

    Quote Originally Posted by rock_nog View Post
    Well of course eveything's closed for Easter - don't you know of the great Easter tradition of people barricading themselves up to protect themselves from the return of Zombie Christ?


  4. #4
    Empty and become Moosh Moosh's Avatar
    Join Date
    Oct 2012
    Posts
    54
    Mentioned
    13 Post(s)
    Tagged
    4 Thread(s)
    vBActivity - Stats
    Points
    617
    Level
    8
    vBActivity - Bars
    Lv. Percent
    82.89%
    I'm also in favor of removing passwords. The only positive purpose I see them serving is encouraging that people actually play the quest by giving the password out at the end, but there's no way to enforce that. If passwords are getting in the way of open source, by all means do away with them. I'd also like to see some way to get scripts out of a quest that imported files instead of putting it all in the buffer. I like importing stuff instead of keeping it in the buffer, but I also like letting people look at and reuse my scripts if they have the patience to try and port them.

  5. #5
    Gel
    Join Date
    Jul 2015
    Posts
    26
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    436
    Level
    7
    vBActivity - Bars
    Lv. Percent
    54.84%
    I may be in the favor of removing it, but it could be re-done, and a converter tool could be made or something- if needed.
    Although, that really would probably be pretty pointless. No matter what is done, someone would probably break it.

    And if the encryption code isn't ridiculous, and random, someone could just use ollydbg to reverse it.
    Here is a (terrible) example of a ridiculous attempt to keep hackers at bay.

    void Encrypt1(char a) { // DooM inspired encryption
    ((((a)&1)<<2)+(((a)&2)>>1)+(((a)&4)<<5)+(((a)&8)<< 2)+
    (((a)&16)>>3)+(((a)&32)<<1)+(((a)&64)>>3)+(((a)&12 8)>>3));
    }
    void Encrypt2(char a) {
    ((((a)&1)<<1)+(((a)&2)>>6)+(((a)&4)<<5)+(((a)&8)<< 2)+
    (((a)&16)>>2)+(((a)&32)<<6)+(((a)&64)>>3)+(((a)&12 8)>>7));
    }

    // Filled with random BS that is further encrypted (to reduce hackability).
    char key[15] = {Encrypt1(0xCA), Encrypt2(0x3d), Encrypt2(0x0e), ...}

    for (i = 0; i < data.len; ++i) { // Encrypt the file or whatever
    if (i&1 || i&6) {
    key[i^2] = Encrypt1((i<<1)+(i>>1));
    fileData[i] ^= passData[i+key[((i^32)&15)]+Encrypt1(i<<1)];
    } else {
    key[i] = Encrypt2((i<<1)^(i>>1));
    fileData[i] ^= Encrypt2(passData[i+key[((i^32)&15)]+Encrypt1(i<<1)]);
    }
    }

    [ANOTHER EDIT]
    This is a fine example of why I dislike this kind of stuff. It's cludgy, and boring, often has loopholes, and it's just a mess.
    No matter how you do encryption on this kind of project, there is usually a way to break it (reversing, memory editing, etc).
    If it's open source that just makes it that much more of a pain. So...
    Last edited by _Mitch; 07-30-2015 at 08:31 PM.

  6. #6
    Username Kaiser SUCCESSOR's Avatar
    Join Date
    Jul 2000
    Location
    Winning.
    Age
    37
    Posts
    4,436
    Mentioned
    152 Post(s)
    Tagged
    7 Thread(s)
    vBActivity - Stats
    Points
    10,560
    Level
    30
    vBActivity - Bars
    Lv. Percent
    51.7%
    Okay there is some misinformation in this thread. The idea that we have to remove passwords to release the source is silly. Encryption can stay in. Yes someone can simply fork the code to bypass it, just as they can fork the code anyway, just like they can write a [really] simple script to overwrite password hashes. But for most people the main branch will still be just as password protected as it is now.

    The AGN staff never agreed on any position on this topic. AGN staff and ZC Devs agreed that the community was not okay with releasing the code as is and that we should do whatever we can to protect quest encryption(an idea that has always been a catch 22). I have always supported releasing the code as is. Quest protection has never been secure and it has always been a bare minimum deterrent. If passwords were gone it would hardly change a thing, except maybe more people fixing bugs on their own to keep playing. Passwords can stay just stop pretending we are doing any service by removing the encryption code and delaying development. They will continue to serve bare minimum deterrent.

    Just about any idea for reworking quest protection has been discussed and rule as easily bypass-able. The only thing that would be an improvement would be to make quests self contained games completely changing how the software(and community sharing) works.

    I support the source being released as is(encryption code and all).

  7. #7
    Gel
    Join Date
    Jul 2015
    Posts
    26
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    436
    Level
    7
    vBActivity - Bars
    Lv. Percent
    54.84%
    That would probably be fine and dandy, but really, the encryption stuff could be compiled int a DLL at the very least (so others can't see it).

  8. #8
    Username Kaiser SUCCESSOR's Avatar
    Join Date
    Jul 2000
    Location
    Winning.
    Age
    37
    Posts
    4,436
    Mentioned
    152 Post(s)
    Tagged
    7 Thread(s)
    vBActivity - Stats
    Points
    10,560
    Level
    30
    vBActivity - Bars
    Lv. Percent
    51.7%
    Quote Originally Posted by _Mitch View Post
    That would probably be fine and dandy, but really, the encryption stuff could be compiled int a DLL at the very least (so others can't see it).
    Doesn't matter. It will still be easily bypassed. So it really doesn't make a difference.

  9. #9
    Gel
    Join Date
    Jul 2015
    Posts
    26
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    436
    Level
    7
    vBActivity - Bars
    Lv. Percent
    54.84%
    I guess that depends on what you mean. But I've never seen the encryption code so I don't know.

    Unless the encryption is just plain stupid, I would imaging that it would make a little bit of a difference.
    If the encrypting source is available all someone would have to do is search and find it, then they would know how it works.
    If the encryption code is all pre-compiled into a binary, then you would have to reverse that binary to see how the encryption works.
    It's a lot harder to decompile than it is to read C or C++ code.

    Then again, someone could just patch ZQ and make it skip password authentication all together.
    But that depends on how it is implemented, so I guess I'm clueless here. 0.o

    [EDIT] I actually voted to remove the protection. Although I don't really know how much sway this vote has!

  10. #10
    Username Kaiser SUCCESSOR's Avatar
    Join Date
    Jul 2000
    Location
    Winning.
    Age
    37
    Posts
    4,436
    Mentioned
    152 Post(s)
    Tagged
    7 Thread(s)
    vBActivity - Stats
    Points
    10,560
    Level
    30
    vBActivity - Bars
    Lv. Percent
    51.7%
    Quote Originally Posted by _Mitch View Post
    I guess that depends on what you mean. But I've never seen the encryption code so I don't know.

    Unless the encryption is just plain stupid, I would imaging that it would make a little bit of a difference.
    If the encrypting source is available all someone would have to do is search and find it, then they would know how it works.
    If the encryption code is all pre-compiled into a binary, then you would have to reverse that binary to see how the encryption works.
    It's a lot harder to decompile than it is to read C or C++ code.

    Then again, someone could just patch ZQ and make it skip password authentication all together.
    But that depends on how it is implemented, so I guess I'm clueless here. 0.o
    You are missing the point. It is irrelevant HOW the "encryption" works. The quest still has to be played, which means bypassing the "encryption", which means it can be easily bypassed for any purpose. I am not talking about encryption in general. The issue is how ZC works.

    Any option to create more true security is simply much more work for little gain AKA a waste of time.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
About us
Armageddon Games is a game development group founded in 1997. We are extremely passionate about our work and our inspirations are mostly drawn from games of the 8-bit and 16-bit era.
Social