Symbols Renaming
Babel Obfuscator can rename namespaces, types, methods, properties, events, and fields, making it difficult for someone to understand the code or reverse engineer it. This is achieved by changing the names to a combination of either alphabet characters or unprintable Unicode symbols, and the original name is lost in the process. The renaming convention used is ASCII by default, but you can switch to the Unicode character set to generate unreadable symbol names.
Babel obfuscates all symbols by default except those that are externally visible to the assembly. This means that symbols that are used only within the assembly and are not visible to other assemblies will be renamed by Babel. However, symbols that are exposed to other assemblies through the public interface of the assembly will not be renamed by Babel unless you specify a custom rule to force renaming.
It's important to note that renaming public symbols can potentially break the public interface of the component, as external code may depend on the specific names of those symbols. It is generally recommended to avoid renaming externally visible symbols and instead focuses on obfuscating internal implementation details.
If a symbol is not meant to be used externally, it should be declared as internal, which will ensure that it is not visible outside of the assembly and will not be part of the public interface.
By lowering the visibility of public types to internal, you can increase the overall number of members obfuscated while still preserving the public interface of the component.
babel MyApp.exe --types --methods --properties --events --fields --parameters
<PropertyGroup>
<ObfuscateTypes>true</ObfuscateTypes>
<ObfuscateMethods>true</ObfuscateMethods>
<ObfuscateProperties>true</ObfuscateProperties>
<ObfuscateEvents>true</ObfuscateEvents>
<ObfuscateFields>true</ObfuscateFields>
<ObfuscateParameters>true</ObfuscateParameters>
</PropertyGroup>
<Babel ObfuscateTypes="$(ObfuscateTypes)" ObfuscateMethods="$(ObfuscateMethods)" ObfuscateProperties="$(ObfuscateProperties)" ObfuscateEvents="$(ObfuscateEvents)" ObfuscateFields="$(ObfuscateFields)" ObfuscateParameters="$(ObfuscateParameters)" />
Babel Obfuscator allows you to apply a name prefix to every generated symbol name. You can specify the prefix to be applied to a particular kind of symbol, such as types, methods, properties, events, fields or parameters. The prefix can be specified using the
--nameprefix or --prefix followed by the desired prefix string. Additionally, you can specify the kind of symbol that the prefix should be applied to by using the syntax --prefix [kind]=[prefix]Babel accepts the prefix $name, which will be replaced with the original symbol name during renaming. This can be helpful for debugging purposes or to identify issues that might arise due to renaming.
babel MyApp.exe --prefix xy_ --prefix types=tp_ --prefix fields=m_
<PropertyGroup>
<NamePrefix>xy_;types=tp_;fields=m_</NamePrefix>
</PropertyGroup>
<Babel NamePrefix="$(NamePrefix)" />
In Babel Obfuscator, you can specify the minimum length of the generated obfuscated names by using the
--namelength option followed by the desired length. This can be useful if you want to ensure that the obfuscated names are of a certain length. Additionally, you can specify the kind of symbol that the name length should be applied to by using the syntax --namelength [kind]=[value]babel myapp.exe --namelength 3 --namelength types=8
<PropertyGroup>
<NameLength>3;types=8</NameLength>
</PropertyGroup>
<Babel NameLength="$(NameLength)" />
Babel allows you to specify the Unicode character set to be used when generating obfuscated names. You can use comma-separated values of Unicode characters or ranges of characters represented in hexadecimal, decimal, or character form.
babel myapp.exe --unicode 10,13,a-z,0x4E00-0x4FFF
<PropertyGroup>
<UnicodeNormalization>10,13,a-z,0x4E00-0x4FFF</UnicodeNormalization>
</PropertyGroup>
<Babel UnicodeNormalization="$(UnicodeNormalization)" />
When Flatten Namespace is enabled, Babel will remove all namespace information from the obfuscated assembly and move all renamed types into the global namespace. This makes it more difficult for an attacker to understand the organization of the code and to locate specific types or members within the assembly.
Optionally, you can specify the name of the namespace Babel will use as a global container for all renamed types.
Note that in Babel, only renamed types will have their namespace name updated according to the flat namespace settings.
babel myapp.exe --flatns
babel myapp.exe --flatns glbns
<PropertyGroup>
<FlattenNamespaces>true</FlattenNamespaces>
</PropertyGroup>
<Babel FlattenNamespaces="$(FlattenNamespaces)" />
Overloaded renaming is a technique used by Babel to rename methods with different signatures using the same name, as long as it is allowed by the .NET Framework design rules. This makes it harder for a hacker to understand and reverse engineer the code. Additionally, Babel renames overloads even when only the method return type differs, which makes it impossible to fully decompile the code to high-level languages like C# and VB.NET since overloading the return type is not allowed in these languages.
babel myapp.exe --overloaded
<PropertyGroup>
<OverloadedRenaming>true</OverloadedRenaming>
</PropertyGroup>
<Babel OverloadedRenaming="$(OverloadedRenaming)" />
Babel can obfuscate virtual functions by renaming them in a way that preserves their virtual nature. This means that the original virtual function table (vtable) layout is maintained, even after obfuscation. This is important to ensure that the program continues to function correctly since virtual functions are a critical part of many object-oriented programs. By obfuscating virtual functions, Babel can make it more difficult for attackers to understand the program's behaviour and exploit vulnerabilities.
babel myapp.exe --virtualmembers
<PropertyGroup>
<VirtualFunctions>true</VirtualFunctions>
</PropertyGroup>
<Babel VirtualFunctions="$(VirtualFunctions)" />
In .NET metadata, local variable names are not explicitly stored. Instead, they are inferred by decompilers based on various factors. For example, when a variable's type is explicitly specified, such as in the case of
var list1 = new List<string>();
the decompiler can determine the variable name as "list1" based on the assignment statement.
Alternatively, local variable names can be loaded from the assembly Program Database (PDB) file. The PDB file contains additional debugging information, including variable names, which can be utilized by decompilers to reconstruct the original names.
To mitigate the exposure of local variable names, Babel Obfuscator offers the option to enable Dynamic Proxy generation for external types.
babel myapp.exe --proxy external
This feature wraps the original types, like
List<string>, in proxy types that are renamed, effectively hiding the variable types.It is essential to ensure that the decompiler being used does not load the PDB file, as this would enable it to reconstruct the original variable names. By disabling PDB loading or deleting the PDB file, the decompiler will have limited access to the debugging information.
For comprehensive protection of method code, it is recommended to enable code encryption whenever possible. Code encryption transforms the method code into an encrypted form, making it significantly more challenging for reverse engineers to understand or modify the code, even if they manage to retrieve the original variable names.
Last modified 4mo ago