I've seen a lot of discussion on here about copy protection. I am more interested in anti-reversing and IP protection.

There are solutions such as Safenet and HASP that claim to encrypt the binary, but are these protected from reversing when used with a valid key?

What kinds of strategies can be used to obfuscate code and throw off reversers? Are there any decent commercial implementations out there?

I know most protection schemes can be cracked, but the goal here is to delay the ability to reverse the software in question, and make it much more blatant if another company tries to implement these methods.

7 Answers
7

There are solutions such as Safenet and HASP that claim to encrypt the binary, but are these protected from reversing when used with a valid key?

No. A dedicated reverse engineer can decrypt it, because the operating system has to be able to decrypt it in order to run it.

Personally, I wouldn't worry. Admittedly I don't know anything about your business, but it seems to me that reverse engineering C++ is relatively difficult compared to languages like Java or .NET. That will be enough protection to see off all but the most determined attackers.

However, a determined attacker will always be able to get past whatever you implement, because at some point it has to be turned into a bunch of CPU instructions and executed. You can't prevent them from reading that.

But that's a lot of effort for a non-trivial program. It seems a lot more likely to me that somebody might just create a competitor after seeing your program in action (or even just from your marketing material). It's probably easier than trying to reverse engineer yours, and avoids any potential legal issues. That isn't something you can (or should) prevent.

Its almost impossible to truely obfuscate code in such a way that it will be totaly impossible to reverse engineer.

If it was possible, then computer virus would be absolutely unstoppable, no one would be able to know how they work and what they do. Until we are able to run encrypted code, the encryption is at some point decrypted and "readable" (as in, someone that can read machine code) before it can be executed by the cpu.

Now with that in mind, you can safely assume that cheap protection will fend off cheap hackers. Read cheap as in "not good", it is totaly unrelated to price you pay. Great protection will fend off great hackers, but ultimate protection doesn't exist.

Usually, the more commercial your solution is, the more "well-known" the attack vectors are.

Also, please realise that things such as encrypted applications imply extra overhead and annoy users. USB dongles also annoy users because they have to carry it around and cost a fortune to replace. So it also become a trade-off between you being happy that you've been protected against a handful of hackers and all of your customers which will have to carry the hindrances your protection method bears.

Sure, you can go to all sorts of clever lengths to attempt to defeat/delay debuggers and reverse-engineering. As others have said, you will not stop a determined attacker, period...and once your app is hacked you can expect it to be available for free online.

You state two goals of your desired protection scheme:

1) Make it hard to reverse engineer.
2) Make it blatent somebody is ripping you off.

For #1, any obfuscator/debugging-detector/etc scheme will have at least some impact. Frankly, however, the shrinking % of engineers who have ever delved into compiler output means that compiled C/C++ code IS obfuscated code to many.

For #2, unless you have a specific and legally protected algorithm/process which you're trying to protect, once the app is reverse engineered you're sunk. If it IS legally protected you've already published the protected details, so what are you trying to gain?

In general, I think this is a hard way to "win" and that you're better off fixing this on the "business-side" -- that is, make your app a subscription, or charge maintenance/support...but the specifics are obviously dependant on your circumstances.

You need to set a limit of how far you will go to protect your code. Look at the market and what your are charging for your solution. You will never secure your product 100% so you should evaluate what method will give you the best protection. In most cases, a simple license key and no obfuscation will suffice.

Delaying reverse engineering will only 'delay' the inevitable. What you need to focus on is deterring the initial attempt to breach copyright/IP. A good legal Terms and Conditions notice on the About page, or a bold copyright notice warning that any attempts to reverse engineer the code will result in a pick-axe through the spinal column...

Most people will back off attempting to rip something off if there is a chance they will be served some legal action.

We use SafeNet and our clients see it as 'official' protection. That in itself is a good deterrent.