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
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