Security - Settings

The second of the four tabs for settings. Here you will find 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. Creates a "needle in a haystack" effect where hackers must analyze massive amounts of useless code. Dramatically increases the complexity and analysis 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
  • Shuffles the order of all methods (real and fake) randomly
  • Ensures fake code never executes but appears 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. Real code 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 the amount of fake code generated. Larger assemblies provide better protection but 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. No runtime performance impact since fake code never executes. Excellent compatibility across all platforms and backends.

Method Control Flow - Settings

Scrambles the execution order of instructions within your methods while preserving functionality. Transforms linear code into complex puzzle-like control flow using jumps, switches, and conditional branches. 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 jumping logic with random control flow variables
  • Uses conditional statements and loops to navigate between blocks
  • Maintains identical functionality while completely changing execution patterns

What build code is affected

Method bodies are completely restructured with randomized instruction order. New local variables for control flow management are added. Complex branching logic replaces linear execution paths while preserving original functionality.

How build resources are affected

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

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. Replaces original text with encrypted versions and generates decryption methods that run at runtime. 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 method calls to decryption functions. New obfuscated classes with random names are added containing encrypted string data and decryption logic.

How build resources are affected

No additional resource files are created. Assembly size increases due to 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 encrypted data storage. Very small CPU cost when decrypting strings (first access only).

Supress 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 debugger from debugging your code.

How it works

  • Adds 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 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 if tampering is detected. Calculates SHA256 hashes of assemblies during build and verifies them when the game starts. 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 StreamingAssets/Cache directory
  • Injects security runtime code into module initializers
  • Performs integrity checks before any game code runs
  • Immediately terminates application if hash mismatches are 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. Directory is created automatically during obfuscation.

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: StreamingAssets/Cache folder is mandatory - game won't run without these files. Only works on Standalone platforms with Mono backend. Failed integrity checks result in silent application termination.

Sign Assembly - Settings

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

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

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. The actual game code logic remains unchanged, but each compiled assembly receives cryptographic signature data that validates its authenticity.

How build resources are affected

Encryption key files are by default stored in 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 Mono scripting backend. Keep key files secure and backed up - loss prevents future updates to signed assemblies.