auditing-mobile-root-jailbreak-and-tamper-resistance

Auditing mobile root/jailbreak and tamper resistance: when a client check guards nothing

A mobile app often tries to protect itself by checking its environment: is the device rooted or jailbroken, is the app repackaged or being debugged, is it running on an emulator. These checks are reasonable telemetry, but they become a false boundary when the app treats their outcome as a security decision made on the client. An attacker runs the app on a device they fully control, and any check whose verdict is computed and enforced locally can be forced to return the answer the attacker wants, the detection routine patched, the response hooked, the flag flipped. So the real question is not whether the app checks, but whether anything important depends on the check, and whether the dependency is enforced somewhere the attacker cannot reach. A secret gated only by a local root check is recovered the moment the check is defeated; an operation allowed only when the app believes it is untampered proceeds once the app is made to believe it. The bug is a security decision resting on a client-side integrity verdict. You audit these by finding what each check protects and whether a server verifies the environment independently.

When to use

• A mobile app performs root, jailbreak, repackaging, debugger, or emulator checks and acts on the result.
• A secret or a sensitive operation is gated by the app's own integrity or environment verdict.
• The app treats a client-computed integrity result as a security boundary rather than as telemetry.

Scope check

Audit tamper resistance only on apps and devices you own or are authorized to assess, on test devices and accounts, defeating a check on a device you control to reach only test assets rather than real user data. A confirmed bypass reaches whatever the check was trusted to protect, so keep every probe within scope. If you can't name the authorization, stop.

The loop

1. Establish what each check protects and where the decision is enforced first. For each integrity or environment check, determine what asset or operation depends on its outcome and whether the decision is made and enforced only on the client, or whether a server independently verifies the environment through an attestation the client cannot forge. This is the false-positive killer: a check that is pure telemetry, protecting nothing, and one whose verdict a server verifies independently are both fine; the finding is a security decision resting on a client-computed result. Name what the check protects before defeating it.