.NET Obfuscation/Protection

[3dsboy08]

As of now, most .NET obfuscators are regarded as nothing more then a joke by tools such as 'de4dot'/similar.

What tools are currently available that hinder reversing for .NET? There seems to be virtually unlimited amounts of obfuscators available for purchase/download, but which ones are actually worthwhile (and worth my money)?

Thanks.

[binarycoder]

if you don't want anyone the get your source code avoid java or .net or other similar languages that compile to an intermediate language. because when the protection get craked anyone can get your original source easly.
when you use a native language like delphi or c++ you make make the operation so hard for anyone to get your original source even after unpacking the protection...just an advanced person that can analyse your assembly code and try to emulate it

[Techlord]

On 10/2/2017 at 11:55 AM, 3dsboy08 said:

As of now, most .NET obfuscators are regarded as nothing more then a joke by tools such as 'de4dot'/similar.

What tools are currently available that hinder reversing for .NET? There seems to be virtually unlimited amounts of obfuscators available for purchase/download, but which ones are actually worthwhile (and worth my money)?

Thanks.

Just one  answer from me : None (at least at the moment) :D

ALL of these tools are pretty much useless and many on this forum itself can reverse the protected code in a matter of minutes.

[Maria Yukie]

So it means, .Net Platform is by default not a secured Language for programmers?

[Techlord]

3 hours ago, Maria Yukie said:

So it means, .Net Platform is by default not a secured Language for programmers?

.Net is excellent in terms of UI and integration with Windows (especially the version 10 of Windows). But when it comes to the security of your apps programmed in .Net languages, they can be more or less reversed in minutes by most reversers, especially with the help of readily available tools such as DnSpy and De4Dot.

Having said that, any protection in general can be reversed by experienced reversers. It's just that it is far easier to reverse .Net apps than native ones. If you really are concerned about the security of your software, ensure that the sensitive portions of the code is not made directly available to the client at all, for example by running it on your own server and letting the client connect to your server. This may not always be practicable though.

Ultimately, most vendors choose to code their sensitive portions of the code in native languages and code the rest in .Net, .though I would not say that this is the best solution.

 

[Maria Yukie]

You really gave me a heavy hammer of answers. Thank you so much for the incites! 😁

[Progman]

Theoretically a very strong protection can still be made in .NET via virtualization or other methods like encryption - there is full reflection support, on-the-fly compiling, etc which would enable concepts like self-modifying code at least on an abstract level quite easily.  So just because no commercial obfuscator is up to the task, and generally professionals would shy away from doing this given that native code just adds additional difficulty which is generally desired, from a theoretical perspective there is hardly a reason a strong protection could not be realized here.  From a practical point of view, it will probably remain rare to say the least.  As decompilers get better for native code but decidability remains an ever fundamental limit, its also important to remember that a lot more can be decided in .NET due to the structure imposed.  So only advanced methods which seek to break away from all those structure layers and bring it closer to native code would further promote the theoretical argument that its possible.  The language features as mentioned actually make a great deal of modern languages theoretically difficult given the right wrappers.

[SkyProud]

Well this is an old but fresh discussion because different users will ask about it again and again at intervals.

If you are asking around for opinions from the developers, they will usually tell you that the obfuscator that he uses is the best of all, so you should not expect the standard answer then.

However, if talking about the cleanest and purest obfuscators for .NET platform, maybe I could offer some clues. I would share with you about some of my recent findings when searching in the Japanese market. From the advertisements in the Japanese language, two players are outperformed, one is the Dotfuscator, the other is Spices .Net. They are not developed by Japanese developers themselves, but having been imported into Japan.

If you read the code of the deobfuscator such as de4dot for these two, you could not find any Magic numbers during the process of deobfuscation, except for the string Decrypter. That's why I see them clean. Although de4dot offers stable support for them, you would not worried about any surprising modded de4dot comming out, which makes use of some Magic calculator, or even code generator.

On the other hand, they offer fundamental obfuscation so you could not find any encryption or PE header tricks during the process of deobfuscation for them. That's why I see them pure in the aspect of obfuscation. On the contrary, some other protectors, such as .NET Reactor, Maxtocode, babelfor.NET, take advantage of XOR encryption for code, but the XorKeys can be calculated inside the assembly. So these kind of keys can also be decrypted, however, they are far away from the pure obfuscation.

Of course, there are many factors when evaluating an obfuscator, along with the technical view. Commands from the boss, the trend, the reviews you have read in your language, can also influence your rating towards the specific obfuscator.

If you would have worried about the deobfuscators such as de4dot, I could only say that the interface of the command line is the threshold for newbies to use it. I don't know what the circumstance would be in your location, but in my here in China, a typical computer expert would have double-clicked on the de4dot and said : "What is the black box jumping out?", "Why can't I see any GUI here?", "How can I open the assembly without the OpenFile DialogBox?" ... So I will not imagine that de4dot could become popular in China, if somebody would have known how to use it.

Regarding my location, Maxtocode and DNGuard HVM are the major players in the production environment in China, but I will not recommend them to any new comer, if he has not already built some dependencies on it. They are popular for two reasons: The developers in the enterprise are encouraged to pick up the natively developed obfuscators to show patriotic, and there are a lot of articles and discussions written in Simplified Chinese and developers are reading them if they are familiar in this language.

For the current status, Maxtocode is playing with the MagicLo and MagicHi keys, due to lack of the pressure from the updated deobfuscators. These keys can be calculated by simply modding the de4dot itself, but few Chinese developers are able to know how to do.

I'm planning to fix the de4dot to the latest version of Maxtocode, but no promise yet because of lack of time. And don't expect much if it upgrades the encryption engine. For DNGuard HVM, since the de4dot doesn't support it, I will follow this policy.

Just my two cents.

[collins]

     Looking forward to your update de4dot .

[SkyProud]

Obfuscation just makes the code unreadable for developers, but without any key.

Encryption encrypts the code with the key, it requires this key to be decrypted.

They are both reversible with different mechanisms. The deobfuscator deobfuscates it by some fixed regex pattern and so on. But for decryption, it requires the key. So the protector often hide the key inside the assembly, but the decrypter will use some key finder or calculator to calculate the key.

So in the view of deobfuscator/unpacker, if the key of the protector has been changed, they must be updated at the same time to work it out. The official release of the unpacker is sometimes slower than the key updating process of the protector, but on the other hand, if the unpacker is open source and you know how to calculate the key, you can code your own unpacker to beat it. (But remember de4dot is currently released under GPLv3 license, you know that😀)

So the philosophy is different here, to let you know it can be obfuscated, or update the key to become quicker than the offcial release of the unpacker. The latter one can be tricky because you don't know how many unofficial mods out there.

Assuming everything on .NET platform is reversible is the presumption that I agree with.😊

[lyliucn]

Looking forward to your update de4dot！

[jemie1234]

waiting for your champion update!