How to protect .Net exe from Decompiling/Cracking

Question

I am really sad because a few days ago we launched our software developed in .Net 4.0 (Desktop application). After 3 days, its crack was available on the internet. We tried to protect the software from this but somehow people got away cracking it.

Here is the scenario: When the application launches the first time it communicates with the web server and checks the credentials passed by the user. If the credentials are correct, the software saves the values in the Registry, sends the MachineID back to the server and stores it in the database.

Now, the hacker has replaced the Server communication with a "return true;" statement (I checked that with Telrik JustDecompile). and he has uploaded the cracked software on the internet.

Now, following are my questions:
1- How to make sure that .Net application will not get cracked ?
2- The hacker now knows my code since he has done the modification. What steps should i take ?
3- I read on the internet about - obfuscators . But the hacker knows my code what should i do ?
4- Any other pro tips that i can use to avoid getting the software cracked ?
5- I am not sure but can these reflector softwares also decompile the App.Config with sensitive data ?

Answer 1

1- How to make sure that .Net application will not get cracked ?

If a computer can run your code + The hacker can run his own code at a higher privilege level than you, there is nothing that can 100% prevent your app from being cracked. Even if they just have access to the executable but not the target platform they still can step through and mimic what the target platform would do and figure out how the protection is being done.

2- The hacker now knows my code since he has done the modification. What steps should i take ?

Totally rewrite the authentication portion so they have to start from scratch but they will get it again, it is just a matter of how long.

3- I read on the internet about - obfuscators . But the hacker knows my code what should i do ?

The jinni is out of the bottle now that they have the non-obfuscated code. There is not much you can do unless you drastically re-write the software so they have to start from scratch. A obfuscateor will not prevent a determined attacker, they only thing that can prevent it is keeping the binary out of their hands.

4- Any other Pro tips that i can use to avoid getting the software cracked ?

The only copy protection I have seen to remotely delay for any period of time is what Ubisoft did with Assassin's Creed: Brotherhood. They encrypted ther levels with the game disk and it had to download the decryption key from the internet as it was needed (This is the keeping the binary out of their hands approach). But that did not work forever, eventually the hackers did get those levels decrypted and it was fully cracked. This approach is just what I saw take the longest time to get around without legal involvement (See point 2 at the bottom)

5- I am not sure but can these reflector softwares also decompile the App.Config with sensitive data ?

All the reflector software needs to do is look for the section that loads App.config and read what the defaults are. There is no secure place to store information on a computer you do not have full control over. If it is on the computer, it can be read. If it can be read, it can be reverse engineered.

---

The only real solution I can see to prevent piracy is one of two options.

1. The person never gets your app, it is streamed from a server under your control and they never get to see the binary. The only thing you send them is the information they need to drive the UI. This is the approach that all MMO's work on. People can reverse engineer what you are sending to the UI and mimic the logic that is going on on your servers but they will never be able to outright see what it is doing and if your software is complex enough it may not be feeseable for the attacker to recreate the server side code. The downside to this approach is you will need to host servers for your users to connect to, this will be a reoccurring cost you will need a way to re-coup. Often this method is called a "Rich Client" or "Thin Client" depending on how much processing is done client side and how much processing is done server side. See Chapter 22 of "Microsoft Application Architecture Guide, 2nd Edition". Specifically I am describing what is shown in figure 4 and 5

2. The seccond option is whoever you sell your software too have them sign a legal contract not to distribute the software (not a EULA, a actual contract that must be physically signed by the client). In that contract have large fines be applied to the person who leaks the software, then riddle your program with fingerprints that are unique to the person who buys the software so that when the program is leaked you can see who did it. (This is the method the vendor Hex-Rays use for their disassembler IDA. A quick google search could not turn up any cracked versions newer than 6.1, they are on 6.3). This method will not stop piracy, but it may discourage the copy to be leaked in the first place. This also lets you recover some lost costs associated with the program being leaked in the first place. One issue is that you will need to put a lot of fingerprints and they will need to be subtle, if a attacker can get two copies of the program and can compare the files between the two he will be able to tell what is the identifying information and just put whatever they want in so they can't tell who they got it from. The only way to do this is put a lot of red-herrings in that can't just be stripped out or randomized, also make the identifying code non-critical to running the software, if they don't have to work to crack it they are more likely to leave it in.

---

Update: After revisiting this answer to link to it for another question I thought of a easy way of implementing the #2 solution.

All you need to do is run your code through an obfuscateor and let it rename your classes for every person you sell your software to (I would still make them sign a license agreement, not just click a EULA so you can enforce the next part). You then make a database of the obfuscation mapping, when you see a leaked copy on the internet you just need to find one class anywhere in the project, look it up in your database, and you will know who leaked it and know who you need to go after for legal damages.

Answer 2

1: you can't. You can obfuscate, but the only way of preventing this is: don't give anyone the exe. Look how much games companies spend on this; they haven't solved it either.

2: obfuscation would help a little, although it is an arms race between obfuscators and de-obfuscators

3: too late to go back and undo that, but the obfuscation will slow them down a bit in future

5: app.config is usually very readable; you not much you can do here; encrypting will only slow them down a bit if the keys are in your app and therefore obtainable

Answer 3

As others have said there really isn't anything you can do against a determined cracker if they have access to your code. Obfuscation will provide some protection against a lazy cracker. Dotfuscator is built into VS you can give it a try. Keep in mind that there is a real cost to obfuscation. It will make it very difficult to debug issues from stack traces that your (paying) customers send you.

Answer 4

The best answer is one you will have to accept. You can't. Just focus on giving your users a great user experience, and make licensing very easy. The possibility that your application can be cracked does not mean that choosing to build a desktop application was a bad idea. Pirates will be pirates and honest customers will be honest customers.

Answer 5

Apparently there is enough commercial or intellectual value cracking your app that someone with reasonable skills tried it almost right away.

The only way you will win that war is to use commercial software protection packages.

If you try to implement copy protection yourself, you will be an easy target to hack again.

If you write a business application you would not also write the database engine that stores the data. You should also not write the crack prevention code for your application. That is not what solves your customer's problem, and it takes a tremendous skill set to do it right.

Answer 6

What you can do, in addition to the code obfuscation is, adding a mechanism of code decryption based on hardwareID, have in mind the following scenario, the send their HwID to your server, you identify the copy/owner/installation number/etc with that HwID, and you reply with a decription key BASED in that HwID for THAT specific binary (with the fingerprints mentioned before), so the hacking would be harder, since for fully functionality they need valid access to your server, otherwise they can't use the software.

Cheers,