Block decompilation using something more than obfuscation

Question

Whenever it comes to Dll security, all the results on online search talk about obfuscation. Now, my question is that is there anything more than obfuscation that we can do to make our assemblies more secure and immune to re-engineering?

The reason I am asking is that because I am preparing for a code security presentation and I know that de-obfuscation happens and if you throw people determined enough to spend their time in re-engineering any code than they will end up doing it. Moral of the story is that obfuscation is not a full-proof solution, it just makes it hard to re-engineer the code. But if we combine obfuscation with some other technique then it will make it even harder.

Any suggestions?

Answer 1

Unfortunately, there is NO way to ensure that nobody will be able to decompile your code. The root problem is really that the code sits on a user-controlled machine can be fully analyzed by anyone with sufficient knowledge, patience and time, and get a somewhat legible source code from the binaries. The computer itself is able to decode and run it, so people are too.

Obfuscation, encryption, packaging or anything else will only give problems to potential hackers, but none of the are really impossible to bypass, you're just raising the bar. This not only happens on .NET, but in all and every programming language, decompilation is always possible, just more difficult or easy, and because the binary sits on a place where the user can read it.

The only safe measure is to put the binaries in a place where the user cannot even read them, which usually means a computer that you control, totally inaccessible to users directly. A web service is a classical approach to this problem, where your web page runs the code, and the user only has a tiny client program, or even just a browser. Of course, that has enormous implications on the way you deploy and the infrastructure they need or want to have, but it's the tradeoff to pay for code security.

Answer 2

Obfuscation is only going to slow them down.
If what you have is of value it will be hacked.
Protecting a DLL is not like encrypting a communications channel where you can change key and even if they hack the key they only got part of communication.
A DLL is a static piece of code that can be hacked.
You can make it very hard to hack but that is time spent not delivering features and a product that is harder to support and extend.

The other technique is legal protection.

I am not an attorney.
This is not legal advice.
This is just my limited understanding of the subject.

Copyright just protects a straight copy of the code.
If they reverse engineer it then copyright alone does nothing.
There are parts of the globe that do little to protect copyrights.

If you have a new algorithm or UI or ??? then the next level of legal protection is a utility patent.
If you are a small entity you can file one yourself for a few hundred dollars.
But without a patent attorney the chance of it being accepted goes down and the chance of it being enforceable goes down.
If the patent is denied you don't get a refund on the application fee.

Or you can treat it as a trade secrete and only host it in house.
In that case still need to take appropriate legal protection such as non disclosure agreements.

My take is obfuscate to the level that you take out the novices and minimize impact on features and support.
The next level of protection is legal.
You are not likely to sue the novices as there are too many of them.
Obfuscate just limits your attack surface and legal action is your recourse.

Again I am not an attorney but my understanding is there used to be a first to invent protection that is now a first to file.
A worst case scenario is you don't get a patent and an existing player (with deep pockets) sees the value in the idea, discovers you don't have it protected, and they get a patent.
Not only do they steal the idea from you but they sue you for stealing your idea.