Quote Originally Posted by _Mitch View Post
That's why I said someone would probably reverse engineer it, simply because it has less code and would be easier to do.
Yeah, but voiding or disregarding the passwords would be disregarding the user that created the quest some might say.

Are you saying all it takes is overwriting a few bytes in the quest file to open a passworded quest?
If so, that's kinda sad, and poor design- and that is only 5 bytes! But why is it different in the windows and linux version?

By posting those 5 bytes, could anyone with basic knowledge on file comparison and a hex editor could search for that string in a non-passworded quest,
overwriting it at the same location in a passworded quest- likely opening it right up (assuming the offsets are the same)?
It sounds like there was not much security to begin with really.
Yeah, and I'm not saying we should just disregard the wishes of users who have
chosen to protect their quests.

Rather, I'm saying that, with this being as simple as it is, there really doesn't seem to
be a whole lot of interest in reversing ZC to accomplish this, so I don't see why this
would change with an open-source release bundled with an optional library for the
encryption/password functions. Or a program to simply update/remove passwords
so that quests could be opened in the open source release, as Tamamo suggested.

No, not the quest files, but ZQuest's executable itself. The quest editor.
It's different because there are differences between the Windows and Linux builds.
No, you can't use these bytes to find out where to apply the patch as these
are only the new instructions; none of the original bytes are there.