Crack me!

[thefool]

> Personally i don't like "please restart the program" and then after that
> either run registered or not

That's not what I meant, but doing that is the best method of registering
because it makes the app that little bit harder for the cracker to succeed.

Nono you misunderstand me, as i was talking quite badly. From a crackers viewpoint, those "please restart the program" smacks of many newbies
So its GOOD to use!

[PB]

> Nono you misunderstand me, as i was talking quite badly. From a crackers
> viewpoint, those "please restart the program" smacks of many newbies

But you misunderstand me too!

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?

[thefool]

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

[Kaeru Gaman]

really interesting topic...

if I want to write a "crackme" to let you test....

should it enter only some code, or some username and a produced code?
or what else would be "legal" for this "contest"....

[localmotion34]

I read the Team SND forums quite alot. One thing I have noticed, is that they are able to crack ANYTHING.

Even non-SND people, like Fly, and shoorick, or bith@ck, crack the MOST difficult protections. WhiteRat from ICU is downright dangerous.

Polymorphic, dongle, FlexM, no matter what, are all taken down in a matter of days, but mostly hours.

If you read my posts about multipart serials, youll probably find that the example i posted has not been cracked, YET. I took an idea that is uncommon to protection and cracking, something crackers almost NEVER look for, and implemented it.

1) find a protector/packer that takes a while to unpack. at least choose one that does not have an unpacker, and only has an OllyDBG script.

2) break up the serial into multiple parts, and have many, many procedure addresses of the same serial routines that are called at random. this exponentially increases the number of patches required, and makes keygenning almost impossible.

3) QUIETLY check serial parts, like say when the user switches a panel gadget item, and if the serial is not correct, set a registry value of the date, and then 2 days later or whenever, execute your "bad boy" code. crackers HATE HATE HATE delayed "gotcha" techniques.

[thefool]

1) find a protector/packer that takes a while to unpack. at least choose one that does not have an unpacker, and only has an OllyDBG script.

2) break up the serial into multiple parts, and have many, many procedure addresses of the same serial routines that are called at random. this exponentially increases the number of patches required, and makes keygenning almost impossible.

3) QUIETLY check serial parts, like say when the user switches a panel gadget item, and if the serial is not correct, set a registry value of the date, and then 2 days later or whenever, execute your "bad boy" code. crackers HATE HATE HATE delayed "gotcha" techniques.

Delayed techniques always rock
Well, anything can be done. But using new techniques always make a delay

[Derek]

I always think that if a program detects that it has been cracked that it should put out incorrect data, so for instance a spreadsheet that actually adds up wrong, just make it subtle to start with and then increase the errors over time.

If it's being used in a commercial sense then this could really get back at the people who are using it illegally.

Might even cost some people their jobs! Ha.