Log in

View Full Version : Identifying a protection


kaotix
March 8th, 2005, 16:37
Hi,

DISCLAIMER: I'm pretty new to this trade, all I did by now is the easier kind of inverting jump conditions and NOPing etc., I do however have some years of programming experience, including assembler. So if anything of the below seems stupid, please bear with me :-)

I'm working on a target which requires a serial number to be unlocked. From what I saw, a working number is not dependant on a user name or anything. I found two suspicious long hex numbers as strings (w/ 0x prepended) in the code. The longer one I haven't really tackled yet, the shorter one is 72 hex bytes which are converted to binary representation and then stroed in a 40-byte array by some algorithm I was able to reproduce in C++. This happens both when entering a serial and when reading the serial as a string from the registry, so I assume it's some kind of magic array. The entered serial number is processed by a similar algorithm which I could also reproduce.
Unfortunately the code that follows then is so packed with calls and jumps that I'm not much farther...
So I left the attempt to keygen the beast for a bit and tried to just patch out the checks, which seemed very simple as the first serial I entered (all 1's) already wasn't rejected as invalid but as for an older version - which is funny because I also found in the EXE the possible characters in the serial and that charset doesn't include '1' :-)
Anyway, I was able to unlock the thing by chaning a single byte of data while debugging, so I changed the code a bit to set that byte to 1 and BANG! Now the program aborts not right away, but when switching tabs in its main dialog.
I tested some more and found out that any change to the EXE has this result, so I gather there is some checksum or even a real signature. I doubt it's too complicated, as the whole thing isn't packed or anything.
However, I set a bpx on the PEP and then a bpm on a code location where I definately know a change resulted in the termination, to find the routine that checks the code for tampering. But that bpm never ever hit, so I'm wondering how the target could possibly check that EXE is unchanged?
It doesn't seem to me that it reads the file from disk, all calls to CreateFileA() refer to user-created data files.
Then, there seems to be some kind of anti-debugger routines, which I didn't examine too closely yet, anyway it somehow walks the process tree to look for the module VMDBG.dll, but it doesn't seem to care about sice or gdb.

Long story short, my questions are: is a r/rw bpm on the code segment supposed to work? How could I find the checksum/sig verification when such a bpm doesn't hit? Does any of the above sound like a known protection tool to you?

Thanks,
kaotix

Kayaker
March 8th, 2005, 18:35
Hi, a few ideas

You should check other API's as well which might be used in the checksum,
CreateFileA, ReadFile, OpenFile, _hread, _lcreat, _lopen, CreateFileMapping, MapViewOfFile

Since you say it's unpacked, an api monitor would be useful.
Are any sections encrypted which might contain crc check code? A direct reading from memory may also be possible.
A checksum routine might be recognized by occurrences of any combination of ROL ROR SHL SHR in a long loop.

As for the bpm r issue, there might be breakpoint detection, though it seems less likely in general for unpacked apps. More likely is it's doing the crc check from a mapped view of the file, so your actual BP needs to be located there instead of an address in the real image.

Kayaker

kaotix
March 8th, 2005, 23:08
Thanks for the hints. It wasn't all that hard, the EXE *is* opened with CreateFileA, apparently I was too tired last time to spot this call :-(
But hey, you made me check again ;-)

The second 0x.... string contains the checksum in some mangled way, but I won't figure that one out this time. For now I went for a slightly unclean but simple approach. Patched 6 bytes to defuse the crc check and another 1 byte to accept the bogus serial and now 1111... is recognized as valid :-)

Oh well, once again someone did soo much to implement all these checks and still it was relatively easy to bypass even for such a noob...

+SplAj
March 9th, 2005, 02:56
Hi

Yes BPM -r and trace is the usual method however
PEiD has a nice 'krypto anlayzer' plugin that detects crypted parts. That gives a good clue as to where some checking could be done.