Quote Originally Posted by _Mitch View Post
Yeah, it would probably be a waste of time, but that's something I find myself doing a lot (like right now)... I have a feeling my post was kinda misunderstood.
I'm sorta assuming there is no "bypassing" the encryption; the file is decoded before the data is actually read (that's usually the point of encryption).

If the decoding code is compiled, how would anyone get to see it? Obviously the encryption isn't that good (I have seen quite a few exploits for it myself).
Also, anyone could just use ollydbg and either dump the memory after loading the map, or patch ZQ so it skips the password altogether (with the current version, it's 5 bytes I have heard).

Although it doesn't matter how one would get in there, it's doable, and not very hard.
So yeah, I agree, it's probably best just to remove all of it, and label the password bytes in a quest as "obsolete" or "deprecated" password bytes.
But it's definitely not my decision how the password stuff is going to be handled anyways.
You are still missing the obvious problem. If you encrypt all the data how will the quest player read it? Let's say you separate ZQ files and ZC files, one for developing and the other for playing. ZQ files could be encoded with whatever password you want and ZC files could have a common password for ZC decoding. No bypassing! Sound perfect? Well let's forget for a second that we have completely redone quest files and loading (a great deal of effort and time). How much effort do you think it will take to find out the common code? Or better yet let ZC do the decrypting and grab the unencrypted data?

We could do this all week long, but there is one simple fact that makes it all moot. Our less than secure passwords have worked for 15 years and they will work even after Open Source. Hell, they used to be stored in plain text.