Unlocking the Code
It looks like you’ve run into a bit of a problem. You simply don’t have the key
that is needed in order to decrypt the “success” path in Defender. It looks like
Defender is using the username and serial number information to generate
this key, and the user must type the correct information in order to unlock the
code. Of course, closely observing the code that computes the key used in the
decryption reveals that there isn’t just a single username/serial number pair
that will unlock the code. The way this algorithm works there could probably
be a valid serial number for any username typed. The only question is what
should the difference be between the VolumeSerial * NameLowPartand the low
part of the serial number? It is likely that once you find out that difference, you
will have successfully cracked Defender, but how can you do that?
Brute-Forcing Your Way through Defender
It looks like there is no quick way to get that decryption key. There’s no evi-
dence to suggest that this decryption key is available anywhere in
Defender.EXE; it probably isn’t. Because the difference you’re looking for is
only 32 bits long, there is one option that is available to you: brute-forcing.
Brute-forcing means that you let the computer go through all possible keys
until it finds one that properly decrypts the code. Because this is a 32-bit key
there are only4,294,967,296 possible options. To you this may sound like a
whole lot, but it’s a piece of cake for your PC.
To find that key, you’re going to have to create a little brute-forcer program
that takes the encrypted data from the program and tries to decrypt it using
every key, from 0 to 4,294,967,296, until it gets back valid data from the decryp-
tion process. The question that arises is: What constitutes valid data? The
answer is that there’s no real way to know what is valid and what isn’t. You
could theoretically try to run each decrypted block and see if it works, but
that’s extremely complicated to implement, and it would be difficult to create
a process that would actually perform this task reliably.
What you need is to find a “token”—a long-enough sequence that you know
is going to be in the encrypted block. This will allow you to recognize when
you’ve actually found the correct key. If the token is too generic, you will get
thousands or even millions of hits, and you’ll have no idea which is the correct
key. In this particular function, you don’t need an incredibly long token
because it’s a relatively short function. It’s likely that 4 bytes will be enough if
you can find 4 bytes that are definitely going to be a part of the decrypted code.
You could look for something that’s likely to be in the code such as those
repeated calls to NtDelayExecution, but there’s one thing that might be a
bit easier. Remember that funny variable in the first function that was set to
one and then immediately checked for a zero value? You later found that the
Breaking Protections 409