Value And Array Encryption

Constant values and arrays declared inline in your code can often contain sensitive information, such as data encryption keys or other critical data that you want to keep hidden from disassemblers or reverse engineering attempts. Babel Obfuscator provides a feature to encrypt these constant values and arrays, adding an extra layer of protection to your sensitive information.

Babel Obfuscator provides configuration options that allow you to encrypt inline values of various data types, including int32, int64, single, double, and arrays. By leveraging these options, you can enhance the security of your code by encrypting these specific types of values.

The encryption of int32 and int64 values ensures that numeric data of these types, such as integers or long integers, are protected from unauthorized access. Similarly, the encryption of single and double values offers protection for floating-point numbers, such as decimals or real numbers. By encrypting these inline values, you can safeguard sensitive numeric data within your code from being easily deciphered or modified.

Furthermore, Babel Obfuscator allows you to encrypt arrays declared inline in your code. Arrays are collections of elements, and encrypting them helps ensure the confidentiality and integrity of the data they contain. This added layer of encryption prevents attackers from gaining insights into the contents of your arrays, even if they manage to analyze or decompile your code.

This section covers:

• How It Works
• Supported Values — which constants and arrays are encrypted, and which are left as-is
• Configuration — CLI, MSBuild and Babel Desktop
• Performance and Deobfuscation Resistance

How It Works

At build time Babel removes the constant from the method body and replaces it with a lookup: the literal ldc instruction is rewritten so that the value is fetched from an encrypted table embedded in the assembly and decrypted on demand at runtime. Numeric constants (int32, int64, single, double) are collected per type, encrypted into that table, and each original load becomes a small call that returns the decrypted value. Inline arrays are handled similarly: the array’s initialization data — normally stored as a plaintext blob in the assembly — is encrypted and rebuilt at runtime.

The result is that a decompiler no longer sees the real numbers or array contents in the IL; it only sees indexes into an opaque, encrypted table. Values are decrypted lazily as your code runs, so behavior is unchanged.