Hi everybody.

I have been working on certain program (I am not going to publish the name of the program in the public forum but if anybody wants to take a look just message me and I will tell you the name and the URL).
Defeating its protection is rather trivial, a simple change on a "registered or demo" flag, and it is not of interest here. After editing the program code with HIEW, it runs like a charm, several times, but the next day, it appears protected again!

I look at the code I edited the day before and the bytes have reverted to their original text.

Questions: Has anybody seen a protection like this?

How does the protection device detect and repair the changes I made?

I cannot find a file big enough to keep a copy of the code.

hey naides, this protection is common in many shareware applications and in some others as well. Anyways, it's usually very simple to detect and fix.

The way I always seen it done is: the program opens itself using CreateFileA and reads a chunk of code,usually the protection related code sometimes the entire code section. It then runs through a loop checking the code against a "static" block of original code bytes, the minute it detects a change it will overwrite the entire block of code with the original one therefore doing away with you patch.

The other way this could be done is by calculating a checksum of the code section and comparing it against a predetermined checksum and if it fails the code section is overwritten by the original code stored somewhere else in the EXE or in some other file.

The way to crack this is to find this checking loop and NOP out the jump that gets executed when a bad byte is found, this way it will never jump out of the checking loop if something was not the same as the original and will pass the checks and will never reverse itself.
Or in the case of the checksum, find the CMP and replace the static checsum value that is there with the one that was calculated for your patched code section.
BPX CreateFileA do "d *(esp+4)" and check that it opens your program's EXE, 99% of the time you will find the checking routine with ease.


goatass

hi,
you can also put your byte(s) in the checking loop

byebye,
ZaiRoN

Thank you for your reply Goatass, you are definitely a smart goat .

What I have not been able to figure out is the timing of the self repair device:


If I close the program and then open it a few minutes or hours later it remains patched, but after a day or a weekend it repairs itself, so I thought the self repair routine appears to be activated by some sort of timebomb. I have played with the system date by moving the current day a few days or months, but this maneuver does not, apparently, trigger the repair event. Only leaving the computer alone for some 24 hours appears to do the trick.
What sent me off balance was the fact that what appeared to be a straightforward crack, has some hidden surprises.

Hi there:

Just thought I'd share some of my thoughts, too. See if I were a protectionist, I'd foresee that you'd foresee (<grin> that some time-bomb mechanism is involved. So to possibly get you thinking, I might for instance not use time at all but use some random number trick. Check this one out:

- Program initializes
- Program calls rand()
- If rand() > some pre-determined value
call check_if_correct
- else
continue execution

This way, the way the code gets patched back to normal one is totally random (even to me: the protector!)

BTW, I've seen something of this kind of protection in a famous graphix software and was clueless until I debugged it instruction by instruction in SoftICE!!!

Signed,
-- FoxThree

Thanks, foxthree. That is a very useful suggestion and I am going to explore it a bit.
The program I am talking about is not from graphix, but appears to be a related company.
Having a protection system that does not activate in a consistent or predictable fashion is a little more challenging for the cracker.

The nice thing about the board is that what is somewhat perplexing to me may have been seen before by someone else.

Hmm. Wonder if it could also randomly patch itself in-memory?

Hiya Naides,

Your other option would be a trace after your fix using softice save how it processes the stuff. Then do a trace a couple of days later when it will fail. Dump the traces to file. Compare files old vs new. Where the differences start is where to start looking!

This is the brute force newbie approach. Also works well for the xx day limit then program stops. Not very intelligent but it will get the job done!

The only trick is to have softice start up and running the moment the program starts. IE backtrace, save history (this may take a few MB's of memory). Some fellow newbie cracker wrote a tut on this,called time limit cracking just can't remember her name.

Good Luck
MTB

OK my memory is coming back to me! The author was Mushy, the title of tut is "Crack 99% of All Time Trials", the krobar collection has it, but I down loaded it from another site.
MTB