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


  1. How to make cracking your app a little bit harder...
  2. More tips you might take into consideration...
  3. Advanced tips given by Assembler freaks...
  4. Special on Delphi VCL cracking...
  5. Some notes on registration numbers...
  6. How to find cracks for your apps...
  7. What to do if you found a crack for your app...
  8. Facts and Myths about Software pirating...
  9. Thoughts and letters from crackers
  10. Links of interest...

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 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 file containing claims that the producers are nothing less than the greatest ones on Earth and that the cracked program is another one which could not stop them with "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.


But finally, here is ..
How to make cracking your app a little bit harder:
(tips are not sorted by importance)

More tips you might take into consideration:

Advanced tips ..given by assembler freaks.


Special on Delphi VCL cracking
Quoted from a helpful cracking tutorial*) - just read and learn from it!

"Let's learn something about the innards of new Borland's programming tools. This knowledge will allow us to speed up cracking sessions, as will teach shareware programmers who use Delphi to be more careful and not to happily expose their 'secrets' to curious eyes B) [..]

VCL stands for "visual component library", a library used by recent Borland visual languages as Delphi and BC++ Builder.
These environments use a proprietary resource format, that appear as 'RCDATA' when listed by Resource Workshop. These resources contain 'forms'. In Delphi jargon, forms are the windows of the program. All the info about their design is stored there. When a typical Delphi app is starting, the initialisation code creates the forms, loading the required information from the resources. Sometimes this loading is deferred - forms that aren't used very often are created and destroyed as needed.
This system is the best and the worst of Delphi. It allows a very fast way of programming but, for full-length apps, it can slow down the loading.

The really interesting part of this information is that the address of the routines - called in response to user interactions with the elements of the form - are bound at run time by name. So knowing these names we can find the appropriate addresses!

If you have cracked any Delphi apps, you have surely experienced the long chain of calls inside the library, from the breakpoints on the API calls to the "do something" code. I hoped that these addresses could help in pinpointing the relevant code."

[..describes his installation of a quite well-known Delphi-writen application..] I cracked it completely and without problems, as you are about to see :=) After first installation the weeks passed and I hadn't had the time to work on it... when I started it, I found a nasty 'Your evaluation period has expired' message :-(

The first step is to gather the information about the target exe with a resource or form spy tool. You may be tempted to investigate TVALIDATORDLG, the form where the user name and registration key is obviously input. But all you'll find is a mere dialog. The real work is accomplished from its caller: TSPLASHFORM. This is the nag window that appears at the beginning of the program, as well as when it's shutting down and from the Help->About menu.

You can select TSplashForm and look at the text representation of it. A lot of information about the buttons and labels will appear. Let's concentrate on the following part, near the end:

  object RegButton: TButton
    Left = 200
    Top = 176
    Width = 97
    Height = 25
    Caption = 'Register'
    TabOrder = 1
    OnClick = RegButtonClick

What's that? This is the button with the caption "Register". You can see its size, position... and something with a suggestive name: "OnClick". "OnClick" tells us the name of the routine invoked when the user presses this button. Once we have the name (yes, "nomen est omen" :) we can search for the address of this routine. This is because the routine is bound to the button at run time by name.

Using a hex editor, I looked for "RegButtonClick" and I found it twice. The second occurrence is the resource itself, the first is within an address table:

000A4990 ____ ____ ____ BC57 4A00 0E52 6567 4275 ______.WJ..RegBu
000A49A0 7474 6F6E 436C 6963 6B__ ____ ____ ____ ttonClick_______

Now look at the magic numbers before the name. There is a byte ('0E') indicating the length of "RegButtonClick" (14 characters) and before that an address: 004ABC57.

Some disassemblers seem to think that file is too long and it doesn't disassemble this portion of the exe correctly - however, with a special tool we can bpx on this and... right! It stops at the point just when we push the button.

A couple of instructions forward you'll find a CALL. Tracing into it you'll find a "standard stack frame" in 44ECC8:

0044ECC8 55     push ebp
0044ECC9 8BEC   mov ebp, esp

This is the kind of thing expected at the beginning of a high level routine, made by the application programmer. We have avoided the whole chain of library calls through the VCL from Windows notifications, and landed in the right place!
From this point, there are some calls you can easily test by setting breakpoints on them - you'll find that their purpose is to show the dialog asking for the user name and registration key. Then, the key is calculated from the user name and compared with the one the user entered. You can enter the name you choose, and anything as the key, after BPXing 44ED69. Here, a call to a routine compares two strings. D EDX will show the fake key you entered and D EAX will show the correct calculated key. Easy, isn't it? A ten minute crack by a beginner!!

[description about spying the key generator routine comes next. It's been an average routine of about 10-20 Object pascal code lines.]

How this way of cracking can be avoided?

Read my tips above. The basics are: don't use automatic methods created by double clicking on the button or the object inspector. Write your code somewhere else in your program, preferably in another module, and bind it to the button using code such as:

  RegButton.OnClick := RegButtonClick;

Of course you'll need to enter this code after the form is created and before it's called. Best if it's rounded by a lot of unrelated stuff. This won't necessarily prevent your program from being cracked of course, but things will not be as easy as you have seen in the lines above O:)

Notes on registration numbers
(if you can't avoid them)

How can I find out if cracks exist for my program?

What to do if you found a crack for your app "Blow the whistle!"..
I've heard and read many programmers telling "you can't do everything against them, there are too many crackers around, too many warez sites on the Net, so that few people ever get caught."
Fact is, however, that you as a software author would have excellent chances to win any lawsuit against operators of ISP's awaringly keeping crack/warez sites online or against the crackers themselves. Hundreds of sites have been closed down during the last years due to offering or linking to pirated software. In some cases, computers were confiscated, and the operators are still paying settlements.
So, you don't have just to accept if you find pirated copies or cracks for your software around .. try to detect where it comes from and get into action against the source!
Facts and Myths about Software pirating
Provided by the Business Software Alliance

Myth: "None of the software offered was stored on my site - I only had links to the files."
Fact: You could be liable for anything that you do that contributes to the infringement of copyrighted works. This includes facilitating a download by linking to remote files.

Myth: "I have a disclaimer on my site that protects me."
Fact: A disclaimer cannot shift your liability to someone else. You are still contributing to copyright infringement.

Myth: "I thought it was okay to download programs to try them out if I delete them within 24 hours."
Fact: This is a common Net Myth. You may only use the software as described in the end-user license provided by the software publisher.

Myth: "..there is something called 'freedom of speech' in this country..?"
Fact: Free speech refers to your right to provide opinions and original content without censure. Even so, free speech has limits. You cannot use this right to break the law. Internet sites that provide access to others' copyrighted materials - whether it's on the same site or a remote site - violate the author's right to control distribution of their works, which is against the law.

Myth: "What about "fair use"? I am only providing a service for "educational purposes."
Fact: Fair use is widely accepted to mean the reproduction of a part of a copyrighted work, not the wholesale copying of an entire program or contributing to software piracy.

Myth: "I only post serial numbers."
Fact: Legal software comes with required numbers or keys to install the software. It should not be necessary to get these off the Internet. Providing them for others to use with pirated software contributes to copyright infringement and is illegal."

Myth: What if I lose my serial number or one of my disks is trashed?
Fact: Most software publishers have provisions for replacing media. Contact them to resolve your problems.

Myth: Writing a book about robbing banks and robbing them yourself are two different things, not?
Fact: A better analogy is "robbing the bank" vs. "driving the getaway car." Or, another analogy is stealing software vs. marking the computer store window with an big X and telling people that, if they throw a brick at the X, they can steal the software in the store window. Both are illegal.

Myth: Software is so expensive, and I've wasted a lot of money just to find out that an expensive program is worthless! If it's any good, then I'll reward the authors. If not, forget the compensation!
Fact: Cars are expensive, too, but society doesn't allow people to use them and decide later if they want to pay for them or not. In the same way, you cannot use pirated software and pay for it only if you want to at some later date.

Myth: Isn't everything on the Internet in the public domain?
Fact: An author does not waive copyrights by publishing on the Internet. Pirated software is published on the Internet by someone other than the author or without the author's explicit permission.

Myth: It's not really illegal to distribute warez.
Fact: An author can seek civil damages in the amount of their actual value, or statutory damages of $100,000 per work infringed. (Note that some "programs" are actually bundles of more than one copyrighted work.) Criminal penalties include fines of up to $250,000 and jail terms up to 5 years, or both. In December 1997, President Clinton signed a law called the "No Electronic Theft" (NET) Act that allows for criminal prosecution of copyright infringement, even where there is no profit motive, closing a loophole in U.S. copyright law.

Thoughts and comments from Crackers

Since I've published this FAQ, I've received a number of letters from former and still active crackers which told me their thoughts about my lines.

"Why the hell should a Cracker provide Richey with tips for his page!", you might ask yourself.. ;-)

As already mentioned, I don't believe that Software protection is the answer to all sales-related problems (think of the enourmous -also financial!- success of some popular Freeware products, Open Source projects and not the least weak protected programs like WinZip and so many others!) ... in most cases the main reasons why developers don't see money is because they are producing the 1000'th clone of already popular products, provide poor quality or simply don't have any idea of 1) really innovative products 2) good design and 3) marketing.

However, there ARE reasons why protection might make sense. One of them might be the following: you are investing 2 years (or many months) of hard work in a brand-new product with some new, advanced features or logic no one else on the market has ever offered before. You have a limited number of potential customers for which your product might be of real interest - but want to protect some specific parts of your program from being reengineered or simply copied -> you need a working protection for that...

Well, I have to admit that I've been suprised that at least some crackers accept that and especially that some of them even decided to provide us all with tips how to protect our work in a better way. Let me tell those fair guys a big "THANK YOU" at this place.

Note: I'm keeping all letters from Crackers strictly confidential except there's an explicit permission to publish them.

Links of Interest
Programming-related stuff
  • efg's CRC Lab good explanation of the "Cyclic Redundancy Check" algorithm and coding examples

Just some thoughts..

Thanks to Fravia+ (a cracker), who allowed me to quote some of his experiences and knowledge on this page.

Again: please e-mail me if you have tips or suggestions !
If you want to support my work on this page or simply say "thanks" for opening my treasure box to you, I'd be happy if you would register one of my apps!
Based on your support, page will be updated frequently. Last update: 22-Apr-99