Encrypting String Constants with Dotfuscator

May 25, 2018 4066 Views Brent Prox

Welcome to the Support Corner, where we’ll occasionally talk about topics that we’re seeing while working with our customers. If you’d like to see more like this, please click the Support Corner Category.

In addition to Renaming and Control Flow, String Encryption is an obfuscation transform that can help protect your application. When customers enable String Encryption in Dotfuscator, they are often surprised to see that string constant definitions are still visible in decompiled code. Customers often contact us asking how to encrypt those string constants.

However, those string constants don’t need to be encrypted; they need to be removed entirely. Dotfuscator’s String Encryption feature takes the strings that have been inlined by the .NET compiler and encrypts them. That leaves the constant definitions behind, unused – and they can be removed.

Note: Dotfuscator Professional Edition is required in order to use String Encryption and Removal.

This leads us to Dotfuscator's Removal feature. If you are using String Encryption, you should also use Removal to remove those string constants. (This is another great example of how layered protection is far more valuable than any individual protection, alone.)

1. Within Dotfuscator, enable Removal by setting Settings > Global Options > Disable Removal to “No”
2. Select the “Remove only literals (const definitions)” option for Removal Kind in Removal > Options
3. Build your app with Dotfuscator
4. Decompile the assembly and verify the string constant definitions have been removed

Note: if you have Library Mode enabled, the public and protected constant definitions will not be removed. Turning on Library Mode for an assembly causes Dotfuscator to treat all visible types and members as entry points, automatically. Entry Points are excluded from Removal.

Please note: this is a basic overview of how to remove string constant definitions from your protected application. In applications with more complexity, there may be additional configurations necessary, such as removal exclusions. For more details, please see the documentation on Dotfuscator’s Removal Editor.

If you have any feedback on this topic, or other topics you would like us to discuss in the Support Corner, please feel free to contact us at support@preemptive.com.

Latest Blog Posts

Dotfuscator 6.0 Beta: Entering the Next Era of Dotfuscator

Today we're announcing the first new major-version release of Dotfuscator in thirteen years: Dotfuscator Professional 6.0 Beta. It's an exciting new release with major new capabilities, but before we get into that, let's take a look at why it's been so long since we had a major release and why we're choosing to do one now.

For development teams, adding Dotfuscator to a build pipeline can often seem like a challenge; the value it adds is mostly gained by the surrounding business, and the cost of adding it is mostly borne by the development team. We understand that constraint, which is why we focus on making Dotfuscator as easy to integrate and maintain as possible. If you're a long-time user of Dotfuscator, you've probably experienced that - release after release of painless upgrades. That's our "first do no harm" philosophy in action.

The dynamic type in C# provides flexibility that is not available in other statically-typed languages. Since its introduction in C# 4.0 (.NET 4.5), we have worked with customers who wanted to know more about how dynamic types are impacted by the obfuscation process.

Malicious actors — like any thieves — live by a simple rule: If the front door is locked, break the window.

It’s why threats like fileless malware and crypto-jacking have seen substantial gains over last few years. It’s why — despite increasing employee education and IT training — hackers are still hooking phish by developing more sophisticated and authentic-looking email spoofs. Cybercriminal communities, meanwhile, continue to grow on the dark web, allowing attackers to share info, purchase exploit kits and identify potential targets.

What does this mean for CISOs? That typical defense efforts are being outpaced as familiar attack vectors are replaced with non-traditional threats. But it’s not all bad news; here are three questions every CISO needs to ask to help close the doors, bolt the windows and leave hackers out in the cold.

Gabriel, you have been in the security industry for over 2 decades. You have seen many different tools and services. Why create a company around something as specific as obfuscation and in-app protection?

Our customers build a lot of really innovative apps that enable their users and customers to do new and cool things. These apps frequently run on untrusted client computers/devices and they control access to customer’s sensitive data or critical devices.

And after all the effort of designing, building, debugging, and deploying their applications, the last thing they want is for an attacker to steal their work or use it to look for vulnerabilities to break into their system.

Long ago, we built a Java code optimizer, but it became clear to us that our customer cared more about the obfuscation effects of the optimization than the actual performance improvement. That is when we really began to focus on app protection. First with Java, then .NET, Android, iOS, Xamarin, JavaScript, etc.

Gartner calls In-App Protection “crucial” in their July 2019 Market Guide for In-App Protection In-App Protection. The guide’s summary advises security and risk management leaders to “take due care in protecting their application clients” in order to avoid “security failure.”

This raises the question – what constitutes “due care?” Obviously, no development organization looks to recklessly expose their applications or sensitive data to attack or compromise. On the other hand, over-engineered (or poorly engineered) security controls can quickly lead to excessive development costs, performance and quality issues, and, ultimately, unacceptable user experiences. While terms and terminology may vary, there is broad consensus on how to best define “due care” for any given application/user scenario.

Encrypting String Constants with Dotfuscator

Dotfuscator 6.0 Beta: Entering the Next Era of Dotfuscator

Protecting C# Applications That Use Dynamic Types

Non-Traditional Attack Vectors: Three Questions Every CISO Needs to Ask

Q&A With PreEmptive CEO Gabriel Torok

Gabriel, you have been in the security industry for over 2 decades. You have seen many different tools and services. Why create a company around something as specific as obfuscation and in-app protection?

The Secret to Effective In-App Protection

Latest Blog Posts

Dotfuscator 6.0 Beta: Entering the Next Era of Dotfuscator

Introducing JSDefender: PreEmptive Protection now includes JavaScript

Protecting C# Applications That Use Dynamic Types

Non-Traditional Attack Vectors: Three Questions Every CISO Needs to Ask

Q&A With PreEmptive CEO Gabriel Torok

Twitter