how to protect .NET executable from de4dot or similar tools?

Question

I have tried obfuscation with following obfuscators but none is successful against de40 tool [https://bitbucket.org/0xd4d/de4dot/]

It's really painful to see how easy this is.. just drag the obfuscated .net exe on de4dot.exe and you will get the source code..

Obfuscators tried are:

Agile.NET (aka CliSecure) Babel.NET CodeFort CodeVeil CodeWall CryptoObfuscator DeepSea Obfuscator Dotfuscator .NET Reactor Eazfuscator.NET Goliath.NET ILProtector MaxtoCode MPRESS Rummage Skater.NET SmartAssembly Spices.Net Xenocode

All are useless.. that's really frustrating..

Can you give some better solution for protection against this tool?

Sapota

Answer 1

de4dot will be compatible with most obfuscators/protectors out there very soon, and if not, something else will.

What I'd do is download Confuser from codeplex and use the advanced feature tab in that.

What I do that ALWAYS works and can't be reversed, is I:

Confuse everything but 'reduce meta' in 'Advanced' in confuser. I then, Compress the assembly with RPX packer. I then, Re-Confuse the compressed assembly with 'Resource encryption' in Confuser.

This makes the assembly almost entirely irreversible (there are always those people who are good crackers). I'd also suggest adding md5/sha-1 encryption to your strings IN the source code.

With all these methods of protection, I'd officially say your .net assembly is very severely protected.

Ibby

Well I guess this topic (and also my reason for being here) is to lock out these youtube-tutorial-crackers. De4dot is unfortunately easy to use. Thanks for this explaination. Exactly what I was looking for! – Simonides

Answer 2

I faced the same problem and couldn't work it out until now. I follow releases of some obfuscators. I checked the latest version of ILProtector was released so I tried it to protect .NET executable and can say ILProtector definitely works against de4dot. de4dot cannot decompile protected assemblies.

Fleischman

Answer 3

As today, it seems that the last version of De4dot can deofuscate ILProtector too.

Agile.net Code Protection from Secureteam.net says that Defeats de4dot among others deobfuscators, but i haven't tried it yet. I'll edit my answer as soon as I have tested it.

Bitten

Answer 4

Better try packing with custom packer of your own. All commercial packer can be decompiled by one or other unpacker.

Good luck.

Parshall

Answer 5

I checked 4-5 obfuscator today. The main purpose of an obfuscator should not be hide your license code, but instead to protect your software / algorithm from being written easily by a programmer just by seeing the code. Because if any software like Windows, SQL Server, Adobe etc. can be easily hacked then there is no chance that you can hide your license code. In my case, I have developed a few software in C# that can be easily replicated if someone has access to its code inside the button click events. So, I tested a few obfuscators that implement "Code Flow Obfuscation" that makes it really hard to understand the execution flow / algorithm of the code. In fact when I did "Code Flow Obfuscation" on my software, I was not able to understand my code itself, let alone what others could understand.

Just image you spent a few weeks in developing an algorithm that can do a certain task like: you can fetch airline tickets from all websites and show in the software. If someone can see the code of it, he/she can simply create the same software in a day. So, its better to jumble the algorithm in suc a way that it becomes very hard for anyone to understand.

I tried: Dotfuscator, Eziriz .NET Reactor and Crypto Obfuscator and rustemsoft Skater .NET Obfuscator. (And a few others)

The following were my results:

1. All string / variable / function encryptions by all obfuscators were easily de-obfuscated by de4dot de-obfuscator. So, there is no point in encrypting strings / variables / functions.
2. I used maximum level of "Code Flow Obfuscation" for all 3. I could not use rustemsoft Skater .NET because its software was hanging a lot and the user interface was confusing for me. And the free / evaluation version did not have "Code Flow Obfuscation" enabled to evaluate. So, Dotfuscator did the best srabling of code. And then .NET Reactor and Crypto Obfuscator were of same level but their obfuscation was much inferior to Dotfuscator.
3. You can try to virtualize the software using a Virtualization software that should prevent direct de-obfuscating using de4dot, but again the exe can be easily unpacked using any good unpacker and then the extracted Assembly can be de-obfuscated using de4dot. A virtualization software is used to pack the main exe, dll and other resources in one big exe so that you do not have to create a setup file etc. and run the exe directly on any computer. So, in this case, you can ecrypt the .NET assembly in a single encrypted exe. But, like I said it can be easily unpacked. There are many videos on YouTube on this topic. It does not do "control flow obfuscation" which was my main purpose.

So, finally what I did was:

Obfuscate control flow using Dotfuscator, then again "control flow" obfuscate the obfuscated exe using .NET Reactor or Crypto Obfuscator. After this if I de-obfuscate the exe, the code can not be understood by any intermediate level programmer.

Tuyere

Answer 6

There was never the option to really protect any assemblies from reverse engineering - neither for .NET nor for native code. However reverse engineering native code is more difficult. The best bet you have got is letting others use your software only as a service (i.e. running a website that uses your software as a service in its backend, or even better that gets just fed by the data your software produces from a different server in your backend). Also you could consider just exporting the central logic of each of your functions to such a backend that requires a connection with your servers and pair that with a software license and an encrypted software which uses client-based compilations that are close to unique. That way you could write most of your code (i.e. the UI) in C# and only have to use some of the code in a remote fashion. However this requires people to be constantly online and if the demand for whatever your software supplies is not tremendous they might consider taking your competitors software instead, since it works offline as well.

Holiday