Stop Exposing Secrets in IL: Hide API Keys & Connection Strings in .NET Assemblies

Why string literals are a high-value target

Most teams think of obfuscation as a “code problem.” But in .NET, secrets often show up before any meaningful logic executes-inside the assembly itself.

Decompilers reconstruct near-source output from the managed module, and string literals appear as plain, searchable text inside the metadata. That means an attacker can jump straight to interesting locations without understanding your architecture.

What the attacker does (in practice)

1. Open your .dll or .exe in ILSpy/dnSpy/dotPeek.
2. Search for recognizable fragments like "api.mycompany.com" or "prod-sql01".
3. Read the surrounding declarations (or copy the secrets directly).

Once a single “anchor string” is found (e.g., an error message or a license verification URL), reverse engineering becomes a guided scavenger hunt.

Two escalating solutions for string protection

You can harden string literals by increasing the difficulty of locating them in the managed artifact. The two-step approach looks like this:

• In-assembly encryption: keep the decryption mechanism inside your managed assembly and replace plaintext literals with encrypted representations.
• Native DLL storage: remove the secrets from the managed module entirely. Extract them and compile them into a native C++-backed DLL that decompilers for managed code can’t interpret.

A minimal example of “plaintext string risk”

Consider a configuration class that includes an API endpoint, a connection string, a license server URL, and error text. When compiled without string hardening, those constants land in the assembly as readable literals.

public class AppConfiguration
{
    public const string ApiUrl = "https://api.mycompany.com/v2/data";

    public const string ConnectionString =
        "Server=prod-sql01.internal;Database=Customers;User Id=appuser;Password=Xk9mP2qR;";

    public const string LicenseServer = "https://license.mycompany.com/verify";

    public const string ErrorMessage = "License validation failed: server returned status 403";
}

In a reverse-engineering workflow, that means you don’t need to understand the program to get the values-you only need to search.

Configuration workflow (how to apply both options)

1) Load your target assembly

Start by opening the obfuscation tool and loading the assembly you want to protect. Both .dll and .exe inputs are supported.

2) Inspect the strings you plan to protect

Use the Strings view to locate specific literals inside the assembly-classes, methods, fields, and the exact string values associated with them.

3) Choose what gets encrypted

You can mark sensitive strings in multiple granularities:

• Individual strings for surgical protection
• Entire classes if the class is dedicated to configuration
• Whole assemblies for broad coverage

It’s usually better to protect only what matters: API URLs, connection strings, license endpoints, and error messages that disclose internal behavior.

4) Decide where the “real secret” lives

This is the core trade-off:

Option A - Encrypt in the managed assembly

The tool replaces string literals with encrypted ciphertext and injects a runtime decryption routine to restore values when needed.

Option B - Store strings in a native DLL (recommended for secrets)

The tool removes the sensitive strings from the managed binary, generates a native machine-code DLL, and rewires your .NET code to fetch strings through P/Invoke at runtime.

How to verify the result with ILSpy

In-assembly encryption: strings become ciphertext

After protection, searching your original values should no longer return readable strings in ILSpy. You’ll see encoded byte arrays/ciphertext placeholders instead.

public class AppConfiguration
{
    public const string ApiUrl = "\u0018\u0043\u00A7\u0021\u009B...";

    public const string ConnectionString = "\u000E\u0072\u00C4\u0038...";

    public const string LicenseServer = "\u00A1\u0056\u008D\u00F2...";

    public const string ErrorMessage = "\u003F\u0099\u00B1\u0004...";
}

Native DLL storage: strings disappear from managed code

With native DLL storage, the sensitive string values are absent from the managed assembly. ILSpy searches for the original plaintext should return zero hits.

public class AppConfiguration
{
    [DllImport("appExtension.dll", EntryPoint = "GetString0")]
    public static extern string GetApiUrl();

    [DllImport("appExtension.dll", EntryPoint = "GetString1")]
    public static extern string GetConnectionString();

    // ...
}

Choosing the right option (a practical matrix)

A tight test plan before you ship

1) Confirm protection by searching

• With in-assembly encryption: verify original strings are no longer readable.
• With native DLL storage: verify the strings are absent from managed IL.

2) Run full functional paths

Exercise the code paths that rely on the protected strings-API calls, DB connections, license validation-and ensure behavior is unchanged from the user perspective.

3) Validate native DLL deployment

If you used native DLL storage, ensure appExtension.dll is present alongside the application binary. Running without it should fail predictably (e.g., DllNotFoundException), which confirms the dependency is correctly wired.

Common issues (and what they usually mean)

DllNotFoundException at startup

This typically indicates the generated native DLL wasn’t deployed with your app. Fix your installer/build pipeline so the DLL ships into the app directory every time.

Strings still appear after “encryption”

Often the string selection step didn’t include the target literals, or the tool’s “do not obfuscate below length threshold” setting excluded them. Re-check the Strings list and adjust thresholds/select individually.

Unexpected performance impact

If you encrypt too broadly-especially in hot paths-you may see overhead. Be selective: protect secrets and high-impact literals instead of encrypting every string.

Native DLL architecture mismatch

If you ship both 32-bit and 64-bit builds, you need matching native outputs. Ensure your obfuscation targets the same platform as your runtime.

Production guidance (what to protect first)

Use a “risk-based” priority list:

• Database connection strings → native DLL storage
• API keys/tokens → native DLL storage
• License server endpoints → native DLL storage
• Error messages / UI text → in-assembly encryption (or none if acceptable)
• Log format strings → typically lower value; avoid over-protection

Remember: string hardening is strongest when combined with other layers such as identifier renaming and control flow obfuscation.

FAQ

Related guides

• Reflection-Safe Obfuscation in .NET Keeping Dynamic Code Alive After Protection: preserve dynamic type resolution, serialization, and DI while hardening assemblies with Skater .NET Obfuscator
• Reverse-Mapping Obfuscated Stack Traces An enterprise guide to resolving obfuscated C# and .NET exception logs in telemetry platforms using automated XML symbol map lookup tables and build artifacts
• Automating .NET Assembly Protection in Visual Studio & MSBuild Architectural guide for embedding Opaquer CLI obfuscation into Visual Studio post-build steps and MSBuild execution pipelines
• Deterministic .NET Obfuscation: A Release Evidence Playbook A release-engineering approach to repeatable protected .NET builds, signing, traceability, and CI artifact retention
• How to Manage Keys in Skater Private Keys Depot? Manage private keys through the online Depot interface
• Native machine-code DLL approach A deeper walkthrough of the native DLL storage method
• Opaquer .NET Obfuscator - articles & guides A complete index of articles published for Opaquer .NET Obfuscator
• What is Opaquer .NET Obfuscator? Product overview and capability comparison
• Best WPF .NET obfuscator for .NET 8/9/10 Modern .NET support and practical string protection capabilities