Symbols Renaming
Last updated
Last updated
Babel Obfuscator can rename namespaces, types, methods, properties, events, and fields, making reverse engineering challenging. By default, it uses ASCII for renaming, but you can opt for Unicode for more unreadable symbols.
Babel automatically renames internal symbols, but not those visible to other assemblies. Thus, private and internal symbols are renamed, while public and protected members remain unchanged unless custom rules are applied to enforce 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.
Renaming in Babel Obfuscator offers flexibility through various methods, including the User Interface (UI), Command Line Interface (CLI), and MSBuild task integration. Each approach offers unique advantages and can be tailored to suit specific project requirements or preferences.
The UI provides a user-friendly way to configure renaming settings in Babel Obfuscator. It allows developers to visually select and apply renaming rules to their assemblies without the need to use the command line or edit XML rules files.
To adjust the renaming settings in Babel Obfuscator using the UI, first create a new project or open an existing project file. If creating a new project, add the assembly you wish to obfuscate to the Input grid. Then, navigate to the Settings tab from the left navigation panel. There, you will find the Renaming section where you can configure the available renaming options: you can enable or disable renaming for types, methods, properties, fields, and parameters, as well as configure the removal of namespace information. Additionally, you can select the character set for generating symbol names along with other renaming configurations that will be detailed further.
Configuring renaming in Babel Obfuscator via the Command Line Interface (CLI) offers a powerful and flexible approach for integrating obfuscation into your build process if you are using CLI scripts.
To configure renaming in Babel Obfuscator, from the Command Prompt on Windows or Terminal if you are on MAC or Linux, navigate to where your project is located and enter:
Here myapp.exe should be replaced with the name of your built assembly that you intend to obfuscate. The following CLI switches indicate the types of symbols you wish to rename.
Each switch (--types, --methods, etc.) enables renaming for that specific category of symbols within your assembly. By including these switches, you're instructing Babel Obfuscator to apply renaming to types, methods, properties, events, fields, and parameters. If you need to exclude a specific category from renaming, you use the --no prefix with the symbol type. For example, to disable renaming for types, you would use --notypes. This can be done for any symbol type to customize which elements are obfuscated.
To access command line help for specific renaming switches, enter the following command
This will display detailed help information for the --types switch.
The MSBuild Babel Task seamlessly integrates Babel Obfuscator into your build workflow, granting fine-grained control over obfuscation preferences. This capability enables you to precisely designate which elements of your code are to be obfuscated, tailoring the obfuscation process to meet your specific needs.
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.
To learn more about name prefix command line switch enter:
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]
To learn more about name length command line switch enter:
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.
To disable unicode renaming enter:
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.
To disable namespace flattening enter:
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.
To disable overloaded renaming enter:
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.
To disable virtual functions obfuscation enter:
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
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.
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.
