Anti Cracking FAQ - How to make cracking your programs a little harder

[begood]

Contents

1. How to make cracking your app a little bit harder... [upd:24-Feb-2k]

2. More tips you might take into consideration... [upd:24-Feb-2k]

3. Advanced tips given by Assembler freaks... [upd:06-Aug-99]

4. Special on Delphi reverse engineering...

5. Some notes on registration numbers... [upd:06-Aug-99]

6. Some notes on timebombs... [new:14-Jan-2k]

7. How to find cracks for your apps... [new:21-Apr-2k]

8. What to do if you found a crack for your app... [upd:19-Aug-99]

9. Facts and Myths about Software pirating...

10. Thoughts and letters from crackers [upd:24-Sep-2k]

11. Links of interest... [upd:16-Aug-2k]

12. Visitor comments... [upd:22-Apr-2007]

Finding out that the program on which you worked for months or years has been cracked can really hurt and demotivate.

For me as a Shareware programmer, the reason has never been that I've lost a few cents (I don't want to do propability calculations here, it might hurt even more..), no, it was simply that I've always tried to hold my programs as cheap as possible to make them affordable for everyone, even for students or freeware programmers.

Somehow I can understand the fascination of cracking programs (if you are absolutely intolerant about software crackers and hackers, please excuse, but one of my educations is Psychotherapy, and I'm always searching for psychological reasons...) - cracking a restricted software program must be like solving a (sometimes very tricky) riddle, and you might get addicted to the feeling of solving them (I've found that when I saw my grandmother doing crossword puzzles all over the time for some months). The problem is (but at the latest, now we come to the undoubtedly illegal part of the "game"): it doesn't really satisfy the cracker if he is the the only one who knows about his "genius"...thus, he has to spread the news. He has to publish his "crack" (just see most crack packages: in most cases they just consist of: 1. the cracking utility 2. a short description 3. a big text file or even animation containing claims that the producers are nothing less than the most brilliant individuals on Earth and that the cracked program is another one which could not stop them due to "its lame protection scheme".)

But now the fun is completely over: by giving out this (let's try to be fair: "study of feasibility") to other people, by spreading it via Websites, newsgroups, mailing lists, anonymous FTP, CDROM "abonnements" and whatever, they clearly damage the business of everyone who puts time and energy in their software product. Even if we assume that typical crackers wouldn't have bought your product under normal circumstances: spreading the "crack" IS criminal and no one could claim that none of the receivers or downloaders would never have bought it. It's just like if someone hands out copies of the key to your car on the marketplace - and it doesn't really matter if he does that for money or not.

In earlier days, I have never put real energy in protecting my programs against cracking, but after finding several cracks for them around, I thought to myself: why make it too easy? As a programmer, of course I know that no - really: NO! - program can ever be crack-safe, and I know that of every interesting program sooner or later cracks (or at least pirated or illegally copied versions) will be around, but at least I could try to avoid the worst mistakes. Crackers are not super-geniuses .. they are simple programmers who have learned some techniques to counteract common protection schemes - and if you know where and how crackers are searching, you can make them lose *much* time! And that's what it is about: there is no bullet-proof way to protect your programs, but you can dance on the nerves of those people until they decide for an easier target to "get the feeling"... or even go outside to enjoy the nature instead of sitting in front of the monitor the whole day. ;-)

Most of the typical 'high language' programmers don't know Assembler anymore, so the 'protection ideas' they use are in most cases quite weak.

I don't know much about Assembler myself, so I decided to open my eyes and started to collect anti-crack protection tips wherever I found them. Also I did my best to "learn from the other side" .. many of the tips you can find here I've found by studying the typical cracking techniques, the various "cracking guides" around the web and by reading protection tips given even by professional crackers themselves (some of them generously give us tips to increase their challenge). Well, I hope I've learned my lessons well enough, but also want to share my experiences with you on this page.

Some rules given here were already stated in various essays on other sites, but are listed here for completeness. Many of these apply especially to Windoze, but can be "ported" to other OS'es or anywhere else.

PLEASE:

* This FAQ is just as good as the experiences that are webbed into it. If you think that I've missed some points or useful tips a typical developer could easily add to his/her programs to improve protection, please let me know. If you allow, then I'll add it here, otherwise I'll inform you about my experiences with it.

* Don't ask me questions - might be that I'm simply too overburden to answer.

1) as mentioned, I don't have much knowledge of the low-level stuff.

2) I can't send you demo sources, since I don't have anything ready for a publication. If I have something, you will read it here.

3) finally, I will not provide anyone with any of the URLs where I've found (or found out) some of these tips. Please understand, but this is a site dedicated to programming, but not to provide "step-in's" to available cracks or even to generic "Cracker hunting".

But finally, here is..

more : Richey's DELPHI-BOX