Security - Settings

The second of the four settings tabs. Here you'll find the advanced security features available in the Obfuscator to protect your Unity games from reverse engineering, cheating, and piracy.

Random Code - Settings

Generates thousands of fake, meaningless methods and injects them into your classes to confuse reverse engineers. This creates a "needle in a haystack" effect, forcing hackers to analyze massive amounts of useless code. It dramatically increases the complexity and time required for reverse engineering.

Figure 1 - Add random code to your classes.

How it works

  • Analyzes existing methods in your classes to create realistic fakes.
  • Clones methods and randomizes their instructions with meaningless data.
  • Injects fake methods with obfuscated names into existing classes.
  • Randomly shuffles the order of all methods (real and fake).
  • Ensures fake code never executes but still looks legitimate to analysis tools.

What build code is affected

Hundreds or thousands of fake methods are added to your classes with randomized, obfuscated names. Method order is shuffled randomly. Your real code's functionality remains completely unchanged – only fake methods are added.

How build resources are affected

No additional resource files are generated. Assembly file size increases by 10–20% depending on how much fake code is generated. Larger assemblies provide better protection, but they also increase download size.

Platform Support

  • Mono Support: ✅ Full support
  • IL2CPP Support: ✅ Full support
  • Standalone Support: ✅ All platforms
  • Mobile Support: ✅ All platforms
  • WebGL Support: ✅ Full support
  • Console Support: ✅ All consoles

Important Notes: Force Mode adds fake code even to non-obfuscated classes. There's no runtime performance impact, since fake code never executes. Compatibility is excellent across all platforms and backends.

Method Control Flow - Settings

Scrambles the execution order of instructions within your methods while preserving their functionality. Linear code is transformed into a complex, puzzle-like control flow using jumps, switches, and conditional branches. This makes reverse engineering exponentially more difficult by breaking traditional code analysis patterns.

Figure 2 - Scrambles the instructions inside methods.

How it works

  • Breaks each method into small instruction blocks.
  • Randomizes the physical order of these blocks in the assembly.
  • Adds complex jump logic with random control flow variables.
  • Uses conditional statements and loops to navigate between blocks.
  • Keeps identical functionality while completely changing the execution pattern.

What build code is affected

Method bodies are completely restructured with a randomized instruction order. New local variables for control flow management are added, and complex branching logic replaces linear execution paths – all while preserving the original functionality.

How build resources are affected

No additional resource files are created. Assembly file size increases due to the added control flow logic and variables. The obfuscated methods contain significantly more instructions than the originals.

Platform Support

  • Mono Support: ✅ Full support
  • IL2CPP Support: ❌ Not supported
  • Standalone Support: ✅ All platforms
  • Mobile Support: ❌ Not supported
  • WebGL Support: ❌ Not supported
  • Console Support: ❌ Not supported

Important Notes: Beta feature requiring .NET 5+ or .NET Standard 2.1+. Adds minimal runtime overhead from extra conditional checks. May impact performance-critical methods. Mono backend only.

String Obfuscation - Settings

Encrypts all string literals in your code to hide sensitive information from hackers. Original text is replaced with encrypted versions and decryption methods are generated to run at runtime. This protects API keys, passwords, debug messages, and other sensitive strings from static analysis.

Figure 3 - Obfuscate your strings.

How it works

  • Scans all assemblies for string literals (text in quotes).
  • Encrypts each string using XOR encryption with unique keys.
  • Replaces original strings with calls to decryption methods.
  • Generates obfuscated static classes containing encrypted data arrays.
  • Creates individual getter methods for each unique string.

What build code is affected

All string literals are removed from your code and replaced with calls to decryption methods. New obfuscated classes with random names are added, containing the encrypted string data and decryption logic.

How build resources are affected

No additional resource files are created. Assembly size increases due to the encrypted data arrays and decryption methods. All encrypted strings are embedded directly in the assembly files.

Platform Support

  • Mono Support: ✅ Full support
  • IL2CPP Support: ✅ Full support
  • Standalone Support: ✅ All platforms
  • Mobile Support: ✅ All platforms
  • WebGL Support: ✅ Full support
  • Console Support: ✅ All platforms

Important Notes: Slight memory overhead for storing the encrypted data. Very small CPU cost when decrypting strings (first access only).

Suppress ILDasm - Settings

Blocks Microsoft's ILDASM debugging tool and similar disassemblers from examining your compiled code. Adds the SuppressIldasmAttribute to prevent common reverse engineering tools from working. Provides basic protection against beginner-level code analysis.

Figure 4 - Prevent common debuggers from inspecting your code.

How it works

  • Adds the SuppressIldasmAttribute to assembly metadata.
  • Tells .NET framework tools to refuse disassembly requests.
  • Blocks ILDASM (IL Disassembler) and similar Microsoft debugging tools.
  • Works at the .NET runtime level to prevent tool access.
  • Provides immediate protection against common reverse engineering utilities.

What build code is affected

A single attribute is added to the assembly metadata. No changes are made to your actual game code or method implementations. The protection works at the assembly level, rather than modifying individual classes or methods.

How build resources are affected

No additional files or resources are created. Assembly file size increases negligibly due to the added attribute metadata. No impact on build resources.

Platform Support

  • Mono Support: ✅ Full support
  • IL2CPP Support: ✅ Full support
  • Standalone Support: ✅ All platforms
  • Mobile Support: ✅ All platforms
  • WebGL Support: ✅ All platforms
  • Console Support: ✅ All platforms

Important Notes: Only blocks Microsoft's official tools – advanced hackers use other methods. More of a "speed bump" than strong security. Professional reverse engineers can easily bypass this protection.

Code Integrity Check - Settings

Monitors your game's assemblies at runtime and automatically terminates the application if tampering is detected. SHA256 hashes of the assemblies are calculated during the build and verified when the game starts. This provides the strongest protection against code modification attacks.

Figure 5 - Check for tampering with micro checks at runtime.

How it works

  • Calculates SHA256 hash fingerprints of each assembly during obfuscation.
  • Stores encrypted hash verification data in the StreamingAssets/Cache directory.
  • Injects security runtime code into module initializers.
  • Performs integrity checks before any game code runs.
  • Immediately terminates the application if a hash mismatch is detected.

What build code is affected

Hidden anti-tampering runtime code is cloned into each assembly. Module initializers receive injected calls to integrity verification methods. The security code runs before any of your game logic executes.

How build resources are affected

Creates hash verification files in StreamingAssets/Cache/ with numeric names. These files contain encrypted assembly fingerprints and must be shipped with the final build. The directory is created automatically during obfuscation.

Platform Support

  • Mono Support: ✅ Full support
  • IL2CPP Support: ✅ Full support
  • Standalone Support: ✅ All platforms
  • Mobile Support: ❌ Not supported
  • WebGL Support: ❌ Not supported
  • Console Support: ❌ Not supported

Important Notes: The StreamingAssets/Cache folder is mandatory – the game won't run without these files. Only works on Standalone platforms with the Mono backend. A failed integrity check results in silent application termination.

Sign Assembly - Settings

Cryptographically signs your compiled assemblies with RSA 2048-bit digital signatures to prevent tampering. This creates tamper-evident seals that detect if someone modifies your game files, providing industry-standard protection against assembly replacement attacks.

Figure 6 - Sign your assemblies to prevent tampering.

How it works

  • Uses RSA 2048-bit encryption to create unique digital signatures for each assembly.
  • Signs .dll files during the build process with cryptographic certificates.
  • Creates mathematical "fingerprints" that prove code authenticity.
  • Any modification to signed assemblies invalidates the signature.
  • Generates and manages encryption key pairs automatically.

What build code is affected

Assembly metadata is modified to include digital signature information. Your actual game code logic remains unchanged, but each compiled assembly receives cryptographic signature data that validates its authenticity.

How build resources are affected

By default, encryption key files are stored in the Assets/GUPS/Obfuscator/Editor/Keys/ directory. You can change this path in the component settings. No runtime resources or StreamingAssets are affected.

Platform Support

  • Mono Support: ✅ Full support
  • IL2CPP Support: ❌ Not supported
  • Standalone Support: ✅ All platforms
  • Mobile Support: ✅ All platforms
  • WebGL Support: ✅ Full support
  • Console Support: ✅ All platforms

Important Notes: Only compatible with the Mono scripting backend. Keep key files secure and backed up – losing them prevents future updates to signed assemblies.