iOS

DYLD_INSERT_LIBRARIES setHooking & instrumentation

Detects the environment variable used to force a dylib into the process at launch.

hooking_dyld_insertCompromising by default

At a glance

Platform: iOS
Category: Hooking & instrumentation
Source: DIIntegrityChecks.m · hasDyldInsertLibraries
Default status: Makes status compromised
Seen firing: Seen firing in D06. Based on validated scenarios whose observed result includes this signal; see below.
OWASP MASTG: MASTG-TEST-0091

How it works

What the code inspects.

Reads getenv("DYLD_INSERT_LIBRARIES"). A non-empty value means the dynamic linker was asked to load an extra library into the process before main() — the standard way tweak loaders and Frida Gadget inject.

Skipped on the Simulator, where Xcode itself legitimately sets DYLD_INSERT_LIBRARIES (e.g. for the debugger / sanitizers), which would be a false positive.

The exploit it addresses

Why this matters.The threat.

DYLD_INSERT_LIBRARIES (the macOS/iOS analogue of LD_PRELOAD) is the simplest injection primitive: point it at a malicious dylib and that code runs inside your app with full access to its memory and keychain.

How it can be bypassed

No single check is sufficient.Known evasions.

Apple's Hardened Runtime and the App Store's restricted entitlements strip DYLD_INSERT_LIBRARIES for store apps — but a jailbreak can inject through the kernel/substrate without ever setting the variable, so this check only catches the naive vector.

Clearing the variable after launch, or injecting via task_for_pid instead of dyld, evades it.

Validation scenarios

Where this check is exercised.2 scenarios.

D06

Debugger attached on an iPhone

Validated · ios

Open →A06

Jailbroken iPhone

Blocked · ios

Open →

References & further reading

All checks

← Suspicious loaded libraries Frida instrumentation →