PB wrote:
All the anti-cracking tips I've read say that when a serial number is entered,
that the app SHOULD re-start instead of saying "thanks for registering" etc,
because the cracker can set a breakpoint on the "thanks" message; so it's
better to do the serial check on the app's startup (ie. silently), which is why
the apps should be re-started after the serial's entered. Know what I mean?
I probably wrote that tip hehe
You misunderstood my second post. I just wrote
From a crackers viewpoint, those "please restart the program" smacks of many newbies
This means, that using a check-serial silently on startup is a GOOD thing for the programmer, and annoys crackers as they have to go through the startup routines and determine when the check is done. Now, you have to store the serial someplace. The crackers would be able to monitor disk and registry activity, and then smack a breakpoint on when data is read for that sake. But again its not something the complete newbie cracker does, and hence just doing this trick will help a bit.
Now to stop people from going through the start routines is another thing. There are a few easy to implement things like changing the .CODE sections characteristics to a specific thing, and that will blow off w32dasm. An all-round trick is to change the image-size label in memory, after running. If you combine that with a sort of dynamic self-encryption, and some other stuff the cracker can't simply dump the image after running. Hence he would have to trace through every simple step to get to the final procedure.
But if he had a breakpoint on when reading the data you say? well, perhaps you would never GO so far to decrypt the routine if you detected the breakpoints..!
Other trace-buggers like gettickcount and comparing times of a long code is also working. And checking CRC of the procedures too.
Problem with making a PATCH for this: the cracker would either have to
A) figure the encryption and find the right place to patch. HARD. He would have to change crc too, no problem. or nop/change the crc check whatever
B) Make an in-memory patch. My favorite approach, Mr Mat was the first to crack my rather simple self modifying crackme [before i got clever to make something harder. I havent released a crackme for long now though]. This would simply have to wait till a certain point is reached [or check the memory of the process if it gets decrypted] and then BOOM, smack. Thats why the self-decrypting procs have to be done dynamically, only when needed! thats just VIP!
Oh. The selfmodification is done, i think Rings did it long time ago and i made personal procedures and things so it actually worked on a real basis, changing the characteristics, i made a PB program for that too [also removes section names], and i also did the changing of the image size. I had troubles getting it done in PB so i wrote an userlib in C and compiled with Pelle's, but it works like a charm. Also all the other tests like gettickcount, smacking bogous exceptions that debuggers catches and smacks around with the user for, softice driver detection, tons of different debugger checks etc etc. got all the codes right here
