User-Input-Based Decryption Keys
The two most important functions in Defender are simply inaccessible unless
you have a valid serial number. This is similar to dongle protection where the
program code is encrypted using a key that is only available on the dongle.
The idea is that a user without the dongle (or a valid serial in Defender’s case)
is simply not going to be able to crack the program. You were able to crack
Defender only because I purposely used short 32-bit keys in the Chained Block
Cipher. Were I to use longer, 64-bit or 128-bit keys, cracking wouldn’t have
been possible without a valid serial number.
Unfortunately, when you think about it, this is not really that impressive.
Supposing that Defender were a commercial software product, yes, it would
have taken a long time for the first cracker to crack it, but once the algorithm
for computing the key was found, it would only take a single valid serial num-
ber to find out the key that was used for encrypting the important code
chunks. It would then take hours until a keygen that includes the secret keys
within it would be made available online. Remember: Secrecy is only a tempo-
rary state!
Heavy Inlining
Finally, one thing that really contributes to the low readability of Defender’s
assembly language code is the fact that it was compiled with very heavy inlin-
ing. Inlining refers to the process of inserting function code into the body of
the function that calls them. This means that instead of having one copy of the
function that everyone can call, you will have a copy of the function inside
the function that calls it. This is a standard C++ feature and only requires the
inline keyword in the function’s prototype.
Inlining significantly complicates reversing in general and cracking in par-
ticular because it’s difficult to tell where you are in the target program—clearly
defined function calls really make it easier for reversers. From a cracking
standpoint, it is more difficult to patch an inlined function because you must
find every instance of the code, instead of just patching the function and have
all calls go to the patched version.
Conclusion
In this chapter, you uncovered the fascinating world of cracking and saw just
closely related it is to reversing. Of course, cracking has no practical value
other than the educational value of learning about copy protection technolo-
gies. Still, cracking is a serious reversing challenge, and many people find it
Breaking Protections 419