iOS

Decrypted / unencrypted main binaryApp tamper

Inspects the Mach-O encryption load command to tell whether the executable is still FairPlay-encrypted. Opt-in.

tamper_binary_decryptedCompromising by default

At a glance

Platform: iOS
Category: App tamper
Source: DITamperChecks.m · isMainExecutableDecryptedOrMissingEncryption
Default status: Makes status compromised
Seen firing: Not yet seen firing in a validated run. Based on validated scenarios whose observed result includes this signal; see below.
OWASP MASTG: MASTG-TEST-0090, MASTG-TEST-0091

How it works

What the code inspects.

Finds the main executable's Mach-O header, walks its load commands, and reads LC_ENCRYPTION_INFO / LC_ENCRYPTION_INFO_64. A cryptid of 0 — or the absence of the command entirely — means the binary is not encrypted.

App Store / TestFlight builds ship FairPlay-encrypted (cryptid != 0). A cryptid of 0 at runtime means the binary was decrypted and rewritten, or was never a store build.

Opt-in via ios.requireEncryptedBinary; intended for App Store / TestFlight distribution. Skipped on the Simulator.

The exploit it addresses

Why this matters.The threat.

Reverse engineers 'decrypt' an App Store binary by dumping it from memory after FairPlay decrypts it (e.g. frida-ios-dump), then re-sign and redistribute a cracked, patched, or trojanized copy. An unencrypted main binary at runtime is strong evidence of exactly that pipeline.

How it can be bypassed

No single check is sufficient.Known evasions.

An attacker can patch the cryptid byte back to a non-zero value after dumping, so the check sees a value that claims encryption even though the payload is plaintext.

Enterprise / ad-hoc / development builds are legitimately unencrypted, so this check is only meaningful for store distribution and will false-positive otherwise.

Validation scenarios

Where this check is exercised.1 scenario.

D04

iOS binary encryption

Pending · ios

Open →

References & further reading

All checks

← Team ID mismatch Signing certificate mismatch →