How Do I Prevent de4dot from Renaming Classes and Methods?

When working with .NET assemblies, developers often rely on deobfuscation tools to analyze, understand, and modify compiled applications. One of the most popular tools used for this purpose is de4dot. It helps remove various forms of obfuscation applied to .NET executables and libraries, making the code easier to inspect and work with. However, many users encounter a common issue during the deobfuscation process: de4dot automatically renames classes, methods, properties, fields, and other identifiers.

While automatic renaming can improve readability in some situations, it is not always desirable. Developers, reverse engineers, software analysts, and security researchers may need to preserve original names to maintain compatibility with other tools, compare versions of software, or better understand how the original application was structured. This often leads to the question: how do I prevent de4dot from renaming classes and methods?

Understanding de4dot and Its Purpose

de4dot is an open-source deobfuscation tool specifically designed for .NET applications. Many software developers use obfuscators to protect their code from reverse engineering. Obfuscation techniques can rename methods, encrypt strings, hide control flow, and perform various transformations that make code difficult to understand.

The primary goal of de4dot is to reverse many of these protections. It identifies common obfuscators and attempts to restore code into a more readable and manageable state. During this process, de4dot may rename classes and methods that have confusing or invalid names.

For example, some obfuscators replace meaningful method names with random characters such as “a”, “b”, or non-printable symbols. de4dot often replaces these names with cleaner identifiers so that decompilers can display the code more effectively.

Although this behavior is useful in many situations, there are cases where preserving original names is more important than readability.

Why de4dot Renames Classes and Methods

To understand how to stop renaming, it is important to understand why de4dot performs renaming in the first place.

Many obfuscators intentionally generate names that are difficult for humans to read. Some use Unicode characters, invisible symbols, or reserved keywords. These names can cause issues when viewing code in decompilers or editing assemblies.

de4dot attempts to solve this problem by assigning new names to identifiers. It creates standardized names that are easier to read and less likely to break analysis tools.

The renaming process may affect:

• Classes
• Methods
• Properties
• Fields
• Events
• Interfaces
• Namespaces
• Generic parameters

While the renamed output may look cleaner, it can also remove valuable information about the original assembly structure.

Situations Where You May Want to Preserve Names

There are several reasons why users choose to disable renaming.

One common scenario involves malware analysis. Security researchers often need to compare samples from different versions of the same program. Preserving names makes it easier to identify changes between versions.

Another scenario involves debugging software. If documentation or external references use original names, automatic renaming can create confusion and make troubleshooting more difficult.

Developers working on interoperability projects may also require original identifiers because external tools, scripts, or plugins depend on specific names.

In educational and research environments, preserving original names can help analysts better understand how an obfuscator modifies code.

Using the -dont-rename Option

The simplest method for preventing de4dot from renaming classes and methods is using the built-in command-line switch designed for this purpose.

The option commonly used is:

de4dot.exe -dont-rename input.exe

This command tells de4dot to perform deobfuscation while avoiding the renaming process.

When this option is enabled, de4dot attempts to keep original identifiers intact whenever possible. The tool still performs other deobfuscation operations unless additional options are specified.

For many users, this single command solves the renaming problem immediately.

Example Command with Output File

In practical situations, users often specify both input and output files.

A typical example looks like this:

de4dot.exe -dont-rename -o cleaned.exe protected.exe

Here:

• protected.exe is the original file.
• cleaned.exe is the processed output.
• -dont-rename prevents automatic renaming.

This approach creates a deobfuscated copy while preserving original names.

How the Option Affects Decompiled Code

After running de4dot with renaming disabled, opening the assembly in a decompiler often reveals identifiers that closely resemble the original protected application.

Instead of generic names such as:

Class1
Method1
Method2

You may see names like:

UserManager
AuthenticateUser
LoadConfiguration

If the original names survived the obfuscation process, they remain visible.

When names were already heavily obfuscated before de4dot processing, those obfuscated names remain unchanged.

Limitations of Disabling Renaming

Although the -dont-rename option is useful, users should understand its limitations.

If an obfuscator completely replaced meaningful names before de4dot was executed, de4dot cannot magically restore the original names. The information may no longer exist within the assembly.

For example, if a method originally named:

CalculateInvoiceTotal

was renamed by an obfuscator to:

a

de4dot cannot determine the original name.

Disabling renaming simply preserves whatever identifiers currently exist.

Combining de4dot with Other Analysis Tools

Many analysts combine de4dot with decompilers to improve visibility into code.

Popular tools include:

• dnSpy
• ILSpy
• JetBrains dotPeek

When using de4dot with renaming disabled, these tools display identifiers exactly as they appear in the processed assembly.

This workflow helps maintain consistency throughout the analysis process and reduces confusion caused by generated names.

Preserving Metadata During Analysis

Class and method names are only one aspect of assembly metadata.

A .NET assembly contains many other elements, including:

• Type definitions
• Assembly references
• Method signatures
• Attributes
• Resources
• Debug information

Using de4dot without renaming helps preserve the relationship between these components.

This can be especially important when comparing assemblies or tracking software evolution across versions.

Working with Obfuscated Names

Sometimes preserving names means accepting that many identifiers remain unreadable.

For example, an obfuscated application may contain classes named:

a
b
c
aa
bb
cc

Although these names are not descriptive, retaining them can still be beneficial.

Maintaining original identifiers allows analysts to correlate findings across multiple tools and reports. It also prevents accidental confusion introduced by generated names.

Comparing Renamed and Non-Renamed Output

Many professionals create two versions of a deobfuscated assembly.

The first version allows renaming:

de4dot.exe sample.exe

The second version disables renaming:

de4dot.exe -dont-rename sample.exe

Comparing both outputs provides valuable insight.

The renamed version may be easier to read, while the preserved version may better reflect the original structure of the protected application.

Having access to both versions often improves the overall analysis workflow.

When Renaming Is Actually Helpful

Although many users seek to disable renaming, there are situations where renaming provides advantages.

Some obfuscators generate invalid Unicode identifiers that cause problems in decompilers. In these cases, automatic renaming can improve compatibility and prevent display errors.

Renaming may also help when analyzing extremely large projects containing thousands of confusing identifiers.

Therefore, the decision to disable renaming should depend on the specific goals of the analysis.

Understanding Obfuscator Behavior

Different obfuscators handle naming differently.

Some preserve namespace structures while renaming methods. Others rename every identifier in the assembly. Certain commercial obfuscators use sophisticated naming strategies that make analysis particularly challenging.

The effectiveness of the -dont-rename option depends partly on how the original obfuscator modified the assembly.

If useful names still exist, preserving them is beneficial. If all names were replaced with random values, readability may remain limited.

Troubleshooting Name Preservation Issues

Occasionally users report that names still appear changed even after using the renaming switch.

Several factors may contribute to this behavior.

The most common issue is command syntax. Ensure the option is correctly written and placed in the command.

Another possibility is that the assembly was already modified during a previous processing step.

Some users accidentally analyze a file that was previously deobfuscated and renamed, making it appear that de4dot ignored the option.

Verifying the original input file often resolves this confusion.

Checking de4dot Version Compatibility

Different versions of de4dot may support slightly different command-line options and behaviors.

When working with archived builds or community forks, reviewing available parameters is recommended.

You can usually view supported options using:

de4dot.exe --help

or

de4dot.exe -h

The help output provides information about available switches and usage examples.

Best Practices for Preserving Original Names

When preventing renaming, it is useful to follow a structured workflow.

Always keep an untouched backup of the original assembly. Store processed versions separately and clearly label them. Document which command-line options were used during each analysis session.

Maintaining organized copies allows easy comparison between different deobfuscation results and reduces the risk of losing important information.

Many experienced analysts also maintain logs describing changes observed during processing.

Benefits of Name Preservation

Keeping original class and method names offers several practical advantages.

It improves consistency across multiple analysis tools. It helps compare software versions more accurately. It reduces confusion when referencing external documentation. It allows researchers to track behavior without introducing artificial identifiers.

For reverse engineering projects involving collaboration, preserving names also ensures that team members work from the same reference points.

These benefits often outweigh the readability improvements provided by automatic renaming.

Security Research Applications

Security researchers frequently investigate malware, packers, and protected commercial applications.

In these environments, preserving names can reveal patterns that might otherwise be hidden by generated identifiers.

Researchers may discover naming conventions, module structures, or developer habits that provide clues about the software’s origin and functionality.

Using de4dot with renaming disabled helps preserve this information throughout the investigation process.

Conclusion

Preventing de4dot from renaming classes and methods is usually straightforward. The most common solution is using the -dont-rename command-line option, which instructs de4dot to preserve existing identifiers during deobfuscation. This approach is especially valuable for reverse engineering, malware research, debugging, software comparison, and compatibility testing.