String Encryption helps protect sensitive information in an application by encrypting string literals stored in the assembly.
Attackers frequently search decompiled applications for strings that reveal the location of important functionality. Because strings often contain meaningful text, they can provide valuable clues about application behavior and help attackers locate code that they want to analyze or modify.
By encrypting strings, Dotfuscator reduces the usefulness of these searches and makes sensitive code paths more difficult to identify.
Why Protect Strings?
A common reverse engineering technique is to search decompiled output for strings associated with specific functionality.
For example:
| Scenario | How Strings Help Attackers |
| Time-limited features | An attacker searches for expiration or timeout messages to locate the associated validation logic. |
| Licensing and registration | An attacker searches for serial number prompts or license validation messages to locate registration code. |
| Security features | An attacker searches for error messages, warnings, or validation text to identify sensitive code paths. |
When strings are encrypted, these searches become significantly less effective because the original string values are no longer visible in the protected assembly.
How String Encryption Works
During protection, Dotfuscator encrypts selected string literals and replaces the original values with encrypted representations.
At runtime, the protected application decrypts the strings when they are needed.
This process:
- Preserves application functionality.
- Removes readable string values from the protected assembly.
- Makes string-based reverse engineering more difficult.
Example
The following example illustrates the effect of String Encryption on decompiled code.
Before Protection
After Protection
Limitations and Performance Considerations
String Encryption is effective for many applications, but there are several considerations to keep in mind.
Constant Strings
String Encryption does not encrypt const string definitions directly, but all the places that use them are updated with encrypted versions of the string.
If you want to remove constant string definitions from the assembly entirely:
- Enable Removal in the Settings tab of the Config Editor.
- Go to the Removal tab and navigate to Options.
- Select the Remove only literals (const definitions) option.
- Save the configuration file.
Performance Impact
String Encryption requires runtime decryption. In most applications, the impact is negligible. However, performance degradation may occur when:
- Strings are generated or accessed repeatedly in performance-critical code.
- Logging code executes frequently.
- Computationally intensive methods repeatedly access encrypted strings.
Pay particular attention to highly repetitive code paths and test the protected application to verify acceptable performance.
Including Strings for Encryption
Unlike Renaming and Control Flow Obfuscation, String Encryption does not automatically process all eligible strings. By default, no strings are encrypted.
To encrypt strings, you must explicitly include code elements for String Encryption. A common approach is to enable String Encryption for an entire assembly and then adjust the configuration as needed.
Use the following process when applying String Encryption:
- In the Config Editor, go to the Settings tab and ensure the String Encryption feature is enabled.
- Go to String Encryption > Include and select the assembly node in the application tree view to check all subitems.
- Add custom inclusion rules, if necessary.
- Build the protected application.
- Test the protected application to verify that it functions as expected.
For more information about available settings and exclusion options, see The String Encryption Editor.