How to make a good anti-crack protection?

I will start off with saying I know that it is impossible to prevent your software from reverse engineering.

But, when I take a look at crackmes.de, there are crackmes with a diff开发者_JAVA百科iculty grade of 8 and 9 (on a scale of 1 to 10). These crackmes are getting cracked by genius brains, who write a tutorial on how to crack it. Some times, such tutorials are 13+ pages long!

When I try to make a crackme, they crack it in 10 minutes. Followed by a "how-to-crack" tutorial with a length of 20 lines.

So the questions are:

• How can I make a relatively good anti-crack protection.
• Which techniques should I use?
• How can I learn it?
• ...

Disclaimer: I work for a software-protection tools vendor (Wibu-Systems).

Stopping cracking is all we do and all we have done since 1989. So we thoroughly understand how SW gets cracked and how to avoid it. Bottom line: only with a secure hardware dongle, implemented correctly, can you guarantee against cracking.

Most strong anti-cracking relies on encryption (symmetric or public key). The encryption can be very strong, but unless the key storage/generation is equally strong it can be attacked. Lots of other methods are possible too, even with good encryption, unless you know what you are doing. A software-only solution will have to store the key in an accessible place, easily found or vulnerable to a man-in-the-middle attack. Same thing is true with keys stored on a web server. Even with good encryption and secure key storage, unless you can detect debuggers the cracker can just take a snapshot of memory and build an exe from that. So you need to never completely decrypt in memory at any one time and have some code for debugger detection. Obfuscation, dead code, etc, won't slow them down for long because they don't crack by starting at the beginning and working through your code. They are far more clever than that. Just look at some of the how-to cracking videos on the net to see how to find the security detection code and crack from there.

Brief shameless promotion: Our hardware system has NEVER been cracked. We have one major client who uses it solely for anti-reverse engineering. So we know it can be done.

Languages like Java and C# are too high-level and do not provide any effective structures against cracking. You could make it hard for script kiddies through obfuscation, but if your product is worth it it will be broken anyway.

I would turn this round slightly and think about:

(1) putting in place simple(ish) measures so that your program isn't trivial to hack, so e.g. in Java:

• obfuscate your code so at least make your enemy have to go to the moderate hassle of looking through a decompilation of obfuscated code
• maybe write a custom class loader to load some classes encrypted in a custom format
• look at what information your classes HAVE to expose (e.g. subclass/interface information can't be obfuscated away) and think about ways round that
• put some small key functionality in a DLL/format less easy to disassemble

However, the more effort you go to, the more serious hackers will see it as a "challenge". You really just want to make sure that, say, an average 1st year computer science degree student can't hack your program in a few hours.

(2) putting more subtle copyright/authorship markers (e.g. metadata in images, maybe subtly embed a popup that will appear in 1 year's time to all copies that don't connect and authenticate with your server...) that hackers might not bother to look for/disable because their hacked program "works" as it is.

(3) just give your program away in countries where you don't realistically have a chance of making a profit from it and don't worry about it too much-- if anything, it's a form of viral marketing. Remember that in many countries, what we see in the UK/US as "piracy" of our Precious Things is openly tolerated by government/law enforcement; don't base your business model around copyright enforcement that doesn't exist.

I have a pretty popular app (which i won't specify here, to avoid crackers' curiosity, of course) and suffered with cracked versions some times in the past, fact that really caused me many headaches.

After months struggling with lots of anti-cracking techniques, since 2009 i could establish a method that proved to be effective, at least in my case : my app has not been cracked since then.

My method consists in using a combination of three implementations :

1 - Lots of checks in the source code (size, CRC, date and so on : use your creativity. For instance, if my app detects tools like OllyDbg being executed, it will force the machine to shutdown)

2 - CodeVirtualizer virutalization in sensitive functions in source code

3 - EXE encryption

None of these are really effective alone : checks can be passed by a debugger, virtualization can be reversed and EXE encryption can be decrypted.

But when you used altogether, they will cause BIG pain to any cracker.

It's not perfect although : so many checks makes the app slower and the EXE encrypt can lead to false positive in some anti-virus software.

Even so there is nothing like not be cracked ;)

Good luck.

Personaly I am fan of server side check. It can be as simple as authentication of application or user each time it runs. However that can be easly cracked. Or puting some part of code to server side and that would requere a lot more work.

However your program will requere internet connection as must have and you will have expenses for server. But that the only way to make it relatively good protected. Any stand alone application will be cracked relatively fast.

More logic you will move to server side more hard to crack it will get. But it will if it will be worth it. Even large companies like Blizzrd can't prevent theyr server side being reversed engineered.

I purpose the following:

• Create in home a key named KEY1 with N bytes randomly.

• Sell the user a "License number" with the Software. Take note of his/her name and surname and tell him/her that those data are required to activate the Software, also an Internet conection.

• Upload within the next 24 hours to your server the "License number", and the name and surname, also the KEY3 = (KEY1 XOR hash_N_bytes(License_number, name and surname) )

• The installer asks for a "Licese_number" and the name and surname, then it sends those data to the server and downloads the key named "KEY3" if those data correspond to a valid sell.

• Then the installer makes KEY1 = KEY3 XOR hash_N_bytes(License_number, name and surname)

• The installer checks KEY1 using a "Hash" of 16 bits. The application is encrypted with the KEY1 key. Then it decrypts the application with the key and it's ready.

• Both the installer and application must have a CRC content check.

• Both could check is being debugged.

• Both could have encrypted parts of code during execution time.

What do you think about this method?