back to .. Richey's DELPHI-BOX   Software Tools  Hot Links  Make suggestion  Contact us   

Delphi-Box Home

Delphi News

Delphi WWW Sites

Delphi FTP sites

Delphi Tips, Tricks & Docs

Delphi Tools & Updates

Delphi Information resources

Delphi User Groups

Delphi Job Offers


Anti Cracking FAQ
Letters and Contributions

Back to the FAQ..


BuLLeT's Letter

Hey !

Lately I read the info about how to protect your software from being cracked, or modified in other ways. I was surprised how little programmers know about that subject and one thing I am wondering about is why programmers don't put more effort in protecting programs in which they have put lots of hours in programming. Then I saw this page and thought that, since I am a programmer myself *), I might get some hints or something out of it. It started out great, and I learned a little - looking at it from a programmers point of view. But as I looked at it from a crackers point of view I was surprised how easy it would be to crack what had just been described as "almost" secure.

I therefore decided to contact the author and write an "answer" to his text. My answer is what you will be looking at on the next pages.

  1. Why protect your programs.
  2. How to decide which way to protect it.
  3. How do protect it once you've decided.
  4. Hints to make it even harder for the cracker.
  5. Final comment on this subject.

These are the subjects that will be described in the following text and I hope that you can use it. I've mixed them together to make it easier to read and understand.

This question actually answers itself since it's pretty obvious that if you want to get some registration money you'll have to protect it. You could of course decide to release it as FREEWARE but what good would that do? Well many people would be glad that they are allowed to use a program without paying, but that's about it. There is no other real advantages of making FREEWARE. That is why many programmers make their programs SHAREWARE. Since SHAREWARE is something for which you need to pay if you want to use all the features, it's obvious that you'll somehow have to get money from the users. This is done by implementing a REGISTRATION option in the program. This is actually a good idea and many programmers use that option not only because it's the easiest, but also because it CAN be hard to crack. The program, however, forget to make a hard algo, which makes the protection very weak. Then finally if you find a program who made a hard algo, he most likely forgot to implement the registration-process. This is one of the most common mistakes of these days programs. Well actually 90% of all programs today are very week and can easily be cracked within a matter of minutes. To prevent this you will have to implement the code in the right way. By this i mean don't just make the usual protection.

Another option would be a KEYFILE protecting which is also a common protection scheme these days. KEYFILE protection CAN also be hard to crack - again depending on how you do it. This way of protecting a program CAN actually be one of the hardest to crack cause there are so many ways in which you can do this kind of protection. How hard it is for the cracker depends on how you generate/encrypt it, and also on how you check for it.

One option which is not that common is CRIPPLEWARE. CRIPPLEWARE means that some options have been disabled in the program and can not be enabled by registering or cracking. This is due to the fact that the code is missing. For example take a program in which you'd like to SAVE but that option is greyed/ disabled. That is crippleware and that kind of programs can ONLY in VERY special cases be cracked. Cracking CRIPPLEWARE is HARD and only something that really good crackers do - if they have enough time.

The last protection-scheme i'll describe is DONGLE. Dongle is a device which is put into your COM/PARALLEL-port and the program will then check for the dongle upon start and sometimes by a timer in the program. This is the best way of protecting your program - if you have money to develop such a dongle. That's expensive and i'll not advice you to do so. The dongle is mostly used by huge companies. For example 3D Studio Max. This program has that kind of check and is hard to crack. It's, however, NOT impossible so don't use it. Having a dongle will give you a false-protection-feeling so drop it.

This is pretty much the protection-schemes i'll describe now since these are the ones you'll probably use. Now it's time to give you some advice on how to make it harder to crack. This is actually not a question i can answer once and for all, cause there are so MANY ways of doing it but i'll try to explain the basics.


An example of a "normal/weak" protection:

For those of you who don't know what this code does i'll explain shortly. CMP means COMPARE. EAX & ECX are registers. JE means "Jump if Equal". After entering the Name/Serial the (wrong)-serial is moved to EAX while the (correct)-serial is moved to ECX. Then it is compared using the JE-line. So shortly this code moves the input and the correct serial into registers and compare them in a single line.

This way of protecting your program is VERY easy so crack since there is only one byte which needs to be changed in order to crack it. To crack it the only thing you have to do is change the JE to JNE (=Jump if NOT Equal). Then it will compare the (wrong)-serial with the (correct)-serial and jump to the OK- area if they are NOT equal. That's pretty logical and i hope you programmers understand what i'm saying. So to make this more secure the only thing you'll have to do is add more checks to the serial. This could be a length-check or a check for the -'s in the serial (= XXX-XXXX-XXXXX). The more checks you add, the harder it get's to crack. So add MANY checks!

A lot of checks, however, is not the saviour for you, cause it's still pissible to get the correct serial using SoftICE (debugger). Therefore you'll also have to add some crypt-code. By this I mean that you'll somehow try to split the serial up. For example you could first check the first 3 chars. Then jump to another location and check the next 4 and so on. Do a lot of weird things to confuse the crackers and some might give up.


This one can actually be protected and be a secure protection. Again it's depending on how you do it. One thing is for sure. Do NOT just add a single check to the keyfile. This is something many programmers do. They add a single check when starting the program. That is TOO easy to crack since, once again, there is only one byte which needs to be changed. My advice to you here is: check MANY times for the file. Don't just add a start-check. Add several timers and delayed checks in the program so the cracker has to do a LOT of tracing/patching. Fx. add a timer which checks every minute, and one that checks every 5th time you press a button. Adding such rather weird checks will most likely give the cracker a hard time and maybe make him give up.

Another important thing is the way the Name/Serial is written to the file. Again i advice you NOT to just add a line saying: NAME=XXXXXX / SERIAL=XXXXXX. Make a SEPERATE keyfile and avoid to add the registration-info in the INI/CFG- file. Make a seperate keyfile and encrypt it as hell. Encrypt it in a way that will make it look like some random data. It doesn't matter if it's several pages long as long as you remember to speed up the calculation so the user does not have to wait 2 hours for the check to be done. Make it HARD but FAST.


One thing that surprise me is the fact that eventhough the authors see that a keygenerator has been made for their products, they don't change the way they register. They MAYBE change the algo a bit but the scheme remains the same. MANY, well almost ALL programmers add a decryption-routine to their programs. This is the DUMBEST thing you can do. NEVER add that routine to your program since THAT is what crackers use to make those keygens i'm sure you hate. Rather write the Name/Serial to a file/registry. Then make several checks which encrypts the Name/Serial and checks if it match the pattern of your registration. What i mean is: encrypt the name/serial and check if it matches YOUR way of registering the program. An EASY example of doing this could looke a bit like this:

	Calculate(Name + Serial)
	Is the length > than 10 ?
	Is the length < than 10 ?
	Is the second char a ^ ?
It's very hard to explain what i mean but i hope you get the idea. The thing you'll have to avoid is NOT to add the decryption-routine in the program. IF you do it like the above it will not be possible to make a keygen since the cracker can not decrypt it and therefore doesn't know how to make the keygen.

You could also do like this:

	Encrypt(Name + Serial)
	Is result = SLDF)YSGUDFG)/YSG(/%"#Y=(&G(%SDF ?
What i mean by this is: Have an encrypted string. Then the user will HAVE to enter a serial that will, together with the name, generate the encrypted string. Once again i remind you to make a HARD algo since if you make it simple the cracker can just compare the different results.

An example of what i mean: (The key is: 456987453)

	Name = Cracker
	Serial = 12345
	Encrypt(Name + Serial) = 456987456
The cracker then get's the serial (which is wrong).
He then tries again and here it is important that your algo is HARD, cause if you have an algo which does:
	Name = Cracker
	Serial = 12346
	Encrypt(Name + Serial) = 456987455
You get it? Well, increasing the serial with 1 the crackers get's 1 closer to the CORRECT string. What i mean is MAKE IT HARD!!! Make an algo which will change the entire string only by adding 1 or changing A to B.

One more thing that can REALLY make crackers angry is encryption. A LOT OF crackers don't have the knowledge or time to decrypt a program. Therefore ENCRYPT all the text in the program. Disassembling a program in which the only chars you see is: *ASD("#`&DSFIUGFR=TF(/GFDS will not do any good! Do it and i bet you'll loose 30-40% of the crackers. The harder the better :)


Ok, this is pretty much what i can think of writing at the moment. I hope I made at least one topic clear for you. If you still have questions, or if you cant me to test your registration-scheme then feel free to write to me.

NOTE: As ALWAYS there are exceptions and you should NEVER trust this 100% !!!

(Dislaimer by BuLLeT: this text is written and copyright by BuLLeT and may NOT be copied/used on ANY other pages without my permission! Doing such will be a federal crime and I'll do anything in my power to get you and shut your page down.
I will, however, any time be available and give advise and in special cases even test your protection-scheme if you THINK you have developed a scheme that you don't think can be cracked.
You can contact me through the author of this page and NO other ways! When/if you contact me do NOT ask for my ICQ# or any other information. I'm doing this ONLY because i want to help programmers to protect their programs.)

*) and still a cracker, too.. (footnote by Richey)


A LAXiTY (cracking group) member's letter

just saw your page and read bullets text. in one case he isn't right :

cmp eax, ecx
je xxxxxxxx
..first of all: ecx wouldnt be used very often cause the processor uses it as a counter register for loops. the next point is that "je" is simply not correct. the cmp either sets the zero flag to 1 or to 0 (depends on if the values have been the same or not). and then either follows a jz (jump if zero = if zero flag is set then jump) or jnz (jump if not zero = zero flag is not set). Ok this isn't really important but it wasnt right what bullet said :).

next thing i want to tell is about closing crack sites. i am myself in a cracking group (laxity) and if we get emails from shareware authors to remove the cracks from our page WE REMOVE THEM. You dont have to close our site. [..]

now i would like to give ya some tips how to detect a debugger. the easiest way is to look into the autoexec.bat :) the next one would be looking into the dump text of "mem /c" if there is a WINICE, a debugger is loaded, this is a very good protection (ive used it myself for a crackme). hmm thats all i wanted to say.

Back to the Anti Cracking FAQ..
[e-mail] [PGP] [Copyright]
Do not copy to other sites or include in commercial compilations without the written authorization from the author.