Lbolt99
April 12th, 2002, 16:18
I've been messing around with CacheX 4.51 for a week or so now and have a couple of questions. First of all, the author is paranoid and the protection is pretty heavy. A brief synopsis on the executable file: it is not "wrapped" with anything traditional like ASpr or whatever.. the author uses his own protection mechanism.
By debugging and trial and error, it looks like the program checks its file on disk as well as the image in memory. It does a couple of crc checks on the code and data in memory, placing various result codes in memory that are later used as decryption keys for sections of the program that are later decrypted. This decryption seems to occur throughout the program.
The one weak point I've found in the CRC check on disk -- the author placed the 32 bit "key" in the EXE file's data section, so one can replace the key in the EXE with the result of the calculation when debugging the CRC routine.
The memory is CRC'd at two spots, and I *think* I might be able to add code to the mem check routine to have it "fool" the checker if any patches are made.
The program has a nag on startup, as usual. If you bypass this, with the program expired (30 day trial), anything you try to do in the program will pop up the nag. I've found a way around the initial nag, but am having no luck figuring out the internal "check" that it does. It seems to use the same windows calls to pop up the nag that it does to do "normal program functions". I've debugged the program both normally and expired, at this point, nothing seems obvious.
Patching the memory it checks to see whether it should skip the startup nag, well, that seems to be detected by the mem check somehow. The decryption routines are screwed up at that point, and it page faults.
Registry keys: I found something in CLSID\blah\blah\CustomType which I deleted, and it reset it to 30 days. But it still detected this somehow. I installed the program on another machine, took the key it installed, placed it in. It *still* detected the tampering, and I can't find anywhere else on the system it might be comparing it with (ran filemon and regmon). The logical thing I can think of is that the key is stored somewhere else, and it's comparing it. Can't find anything though.
I originally wanted to take the keygen approach: the code is so complicated that I abandoned that idea and thought a hard patch would be better...
Any advice?
By debugging and trial and error, it looks like the program checks its file on disk as well as the image in memory. It does a couple of crc checks on the code and data in memory, placing various result codes in memory that are later used as decryption keys for sections of the program that are later decrypted. This decryption seems to occur throughout the program.
The one weak point I've found in the CRC check on disk -- the author placed the 32 bit "key" in the EXE file's data section, so one can replace the key in the EXE with the result of the calculation when debugging the CRC routine.
The memory is CRC'd at two spots, and I *think* I might be able to add code to the mem check routine to have it "fool" the checker if any patches are made.
The program has a nag on startup, as usual. If you bypass this, with the program expired (30 day trial), anything you try to do in the program will pop up the nag. I've found a way around the initial nag, but am having no luck figuring out the internal "check" that it does. It seems to use the same windows calls to pop up the nag that it does to do "normal program functions". I've debugged the program both normally and expired, at this point, nothing seems obvious.
Patching the memory it checks to see whether it should skip the startup nag, well, that seems to be detected by the mem check somehow. The decryption routines are screwed up at that point, and it page faults.
Registry keys: I found something in CLSID\blah\blah\CustomType which I deleted, and it reset it to 30 days. But it still detected this somehow. I installed the program on another machine, took the key it installed, placed it in. It *still* detected the tampering, and I can't find anywhere else on the system it might be comparing it with (ran filemon and regmon). The logical thing I can think of is that the key is stored somewhere else, and it's comparing it. Can't find anything though.
I originally wanted to take the keygen approach: the code is so complicated that I abandoned that idea and thought a hard patch would be better...
Any advice?
