How to deobfuscate but make sure metadata tokens stay the same?

--preserve-tokens will preserve all important metadata tokens, the #US and #Blob heaps, and keep junk data in signatures.

--keep-types should normally also be used. If used, no obfuscator types or methods will be removed.

Most of the time you don‘t need to preserve the method parameters‘ metadata tokens. You can use--preserve-table all,-pd which will preserve all important tokens except the parameter tokens.

--dont-rename or --keep-names can also sometimes be necessary. For example, if you‘re deobfuscating Confuser obfuscated assemblies, then --keep-names d will rename everything except fields in delegate types.

If the file has been obfuscated by an unsupported obfuscator, then all tokens are preserved by default.

Examples:

Preserve all important tokens, #US heap, #Blob heap, junk sig data, and don‘t remove any obfuscator types/methods:

de4dot --preserve-tokens --keep-types file.dll

Preserve all tokens except parameter tokens, and don‘t rename fields in delegate types:

de4dot --keep-names d --preserve-table all,-pd file.dll

An assembly has been obfuscated by two or more supported obfuscators. How do I deobfuscate the assembly?

If two or more obfuscators are detected, de4dot will print that and a description on how to force detection of one of them.

You need to figure out in which order the obfuscators were used and deobfuscate it in reverse order. You should also use --preserve-tokens to preserve metadata tokens in case the next obfuscator uses hard coded metadata tokens to decrypt eg. strings.

The -p XX option can be used to force detection of an obfuscator, where XX is the type of the obfuscator. de4dot -h will show all types.

Assume filename.dll has been obfuscated by sa followed by ef, then you should use these commands:

de4dot --preserve-tokens --dont-rename filename.dll -p ef -o tmp.dll
de4dot tmp.dll -p sa -o cleaned-file.dll
del tmp.dll

The output will be in cleaned-file.dll.

How do I decrypt strings in an assembly obfuscated by an unsupported obfuscator?

First you must figure out the metadata token of the string decrypter. You can use Simple Assembly Explorer (SAE). Locate the string decrypter and hover the mouse over the method name and you should see something like 06001234. That‘s the method‘s metadata token. The following command will dynamically decrypt the strings:

de4dot filename.dll --strtyp delegate --strtok 06001234

If it has more than one string decrypter, just append more --strtok 06xxxxxx like so:

de4dot filename.dll --strtyp delegate --strtok 06001234 --strtok 06001235 --strtok 06001236

--strtyp delegate will create a dynamic method and simply call the string decrypter and let it decrypt the string for us. --strtype emulate needs to be used if the string decrypter detects dynamic methods. If you suspect the assembly to be malware, you should only do this in a sandbox since unknown code is executed.

What could be the reason for an assembly to crash if it‘s been renamed?

If it‘s a supported obfuscator, renaming should always work, except in a few cases.

It could happen when a resource isn‘t renamed when the class that uses it has been renamed.

It could also happen if you deobfuscate an assembly, A.dll, but there‘s another assembly, B.dll, that has a reference to A, and that reference has been renamed in A.dll but not in B.dll. In this case, you must deobfuscate both A.dll and B.dll to make sure all references to A.dll in B.dll also are renamed.

de4dot A.dll B.dll

After deobfuscating a .NET Reactor obfuscated assembly, I see methods with only a throw (uint)-559038242 statement.

That throw is actually throw 0xDEADCODE. Those methods are encrypted native (x86 code) methods and the throw won‘t execute at run time. The method body will be replaced with the real method at run time by the obfuscator‘s methods decryptor. You‘ll know when there are native methods left in the image if you see something like this after deobfuscation:

Re-encrypted 10/73 native methods

In this example, there are 10 methods left that are still native methods. The remaining 63 methods were converted back to CIL code or deleted from the image. A future version of de4dot may convert the remaining native methods back to CIL code.

de4dot FAQ