Knowledge Center / Mobile runtime attacks / mobile runtime attacks · 2026·01

Library injection via Frida and Xposed

Frida and Xposed are the two long-running dynamic-instrumentation toolchains for Android. Both achieve the same end — runtime method hooking, function interception, in-process scripting — by injecting an agent library into the target process. The injection is observable in the kernel's process-memory map; the hooks themselves are observable as overwrites on libc, libart, and app entry points.

Frida and Xposed inject agent libraries into the target process. The injection is visible in /proc/[pid]/maps as an unexpected .so mapped from a non-app path.

1. Mechanism

Frida [1] attaches to a target process by one of two paths: ptrace + dlopen (a Frida server running on the device attaches to the process, allocates memory, and dlopens the agent library) or spawn-and-attach (the Frida server spawns the app from zero and injects before main()). In both cases, the result is a shared library (frida-agent-64.so, typically) loaded into the target’s address space, exposing a JavaScript runtime that scripts the target through ART instrumentation, libc hooks, and arbitrary memory access.

Xposed [2] (today maintained as LSPosed) operates earlier in the lifecycle: a Magisk module hooks the zygote, and at the moment a target app forks, the Xposed framework’s module libraries are mapped into the new process. Method hooks are installed via ART method-table rewrites before the app’s first class is loaded. The hook payloads are written in Java/Kotlin inside the LSPosed module ecosystem.

The two are functionally similar from the defender’s perspective: an unexpected agent library is mapped into the process, and method hooks have been installed.

2. Where in the runtime it operates

The injection is visible in /proc/<pid>/maps [3] — the kernel’s per-process memory map — as a file-backed mapping of the agent’s .so file. The path is informative:

Frida’s default path is /data/local/tmp/frida-agent-64.so, though hosts customise this. The mapping’s flags show r-xp (read-execute, private) for code segments.
LSPosed module libraries are mapped from /data/adb/lspd/... paths.
ART method-table rewrites are visible by hashing the in-memory representation of suspect classes and comparing against the expected hash from the dex.

The hooks themselves are detectable by reading the first instructions of suspect functions and comparing against the on-disk dex / shared object — when a hook is installed, the in-memory bytes diverge.

3. Which checkpoints it bypasses

Play Integrity. MEETS_DEVICE_INTEGRITY and MEETS_BASIC_INTEGRITY can be defeated on rooted devices using Magisk + Zygisk + DenyList + Shamiko. (Magisk Hide was removed in Magisk v24, January 2022; the current cloaking stack is DenyList plus Zygisk-based hiding plus the Shamiko module.) MEETS_STRONG_INTEGRITY is hardware-backed: it consults the chip-level Root of Trust, which Magisk patching breaks. STRONG fails on Magisk-rooted devices because the unlocked bootloader is recorded at the chip layer and is not concealable in software.
App Attest. The Apple attestation chain is unaffected by Frida-style attacks against Android apps; on iOS, equivalent in-process hooks operate inside the app, not on the key.
Android Key Attestation / hardware attestation. Affected. Magisk patches boot.img to insert its hooks, which causes the attestation extension’s verifiedBootState to report Unverified (or Failed) and deviceLocked to be false. The attestation chain validates cryptographically, but its content reflects the broken boot state.

Privilege qualifier. Library injection into a non-debuggable release-build app on stock, non-rooted Android requires either repackaging-and-resigning the APK (a different attack class — the resigned APK has a different signing key and fails app-side signature checks at install) or a debug build. Frida/Xposed in the catalogue above presume root or Zygisk.

4. Which signals make it observable

code.integrity and runtime.environment. The Trusted Runtime Primitive enumerates loaded libraries (read from /proc/self/maps), hashes them against an expected manifest, and signs the discrepancy. ART method-table rewrites are detected by spot-checking critical methods — bytes-on-disk vs bytes-in-memory at the function prologue.

5. Evidence Token shape when observed

The following example is illustrative; field names, type values, and schema are defined in YEI-001 §4 (available through the spec-access process).

{
  "ev": [
    {
      "ts":   "2026-06-15T10:23:14Z",
      "class": "code.integrity",
      "type":  "unexpected_lib_loaded",
      "data": {
        "path":        "/data/local/tmp/frida-agent-64.so",
        "sha256":      "1c5a…7e",
        "in_app_path": false
      }
    },
    {
      "ts":   "2026-06-15T10:23:14.060Z",
      "class": "code.integrity",
      "type":  "method.prologue_hash_mismatch",
      "data": {
        "method":         "okhttp3.OkHttpClient.newCall",
        "expected_sha":   "9a2c…b1",
        "observed_sha":   "e431…77"
      }
    }
  ]
}

The unexpected-lib + prologue-hash pair, signed by Execution Evidence Infrastructure (EEI) — the device-identity infrastructure layer for banking and payments — is what the operator’s verifier reads to detect the injection class even where the platform attestation chain itself remains cryptographically valid.

6. Cross-references

Sibling articles: hook-detection-bypass, magisk-zygisk-modules, debugger-attachment
Architecture: /architecture/threat-model

7. External references

[1] Frida. Dynamic instrumentation toolkit. frida.re/docs/home/. Cited 2026-01-25.

[2] LSPosed. A modern Xposed framework. github.com/LSPosed/LSPosed. Cited 2026-01-25.

[3] Linux man-pages. proc(5) — /proc/[pid]/maps. man7.org/linux/man-pages/man5/proc.5.html. Cited 2026-01-25.