by Dan East » Mar 27, 2004 @ 10:22pm
Since DEXplor has been cracked for some time, I guess I can describe a bit more of how its protection works.
The registration key is actually a DLL encrypted with the Product ID. So the key is not just something to unlock features within the EXE, it actually contains missing components of the program required to load plugins, etc.
So it is impossible to crack DEXplor unless the cracker would code entire non-existant routines to gain the functionality found in the registered version. Unfortunately due to time constraints I could not finish the registration system to my satisfaction. As it stood, DEXplor would decrypt the registration key to a temporary file. That temporary file was the unencrypted version of the DLL, which DEXplor would then load. Someone finally (after well over a year) figured that out, and simply modified DEXplor to skip the step of trying to decrypt the DLL, and they distributed the unencrypted DLL (which they would never have had access to if my security system had been "complete") with their KeyGen.
Now if I would have had time to not have to use LoadLibrary to load the DLL and use my own routine that dealt directly with a DLL pre-loaded into memory, then I'm sure DEXplor would still not be cracked to this day.
Even with the unencrypted DLL DEXplor still has checks to make sure the Product ID within the DLL matches the device-specific Product ID. That was not cracked within the EXE, hence the need for a keygen that would place that information within the unencrypted DLL.
I'll refer you to this illustrating the problem I ran into that I did not have time to rectify before I released DEXplor, resulting in the weakness to DEXplor's security.
So Sponge, Registration Keys produced with that KeyGen will not work with the official version of DEXplor. So it is the worst of both worlds. Not only does it require a KeyGen, but it requires a cracked EXE too.
Dan East