Android

Xposed / code injectionHooking & instrumentation

Detects Xposed and LSPosed via loaded libraries, bridge classes, and the call stack.

hooking_xposedCompromising by default

At a glance

Platform: Android
Category: Hooking & instrumentation
Source: IntegrityChecks.kt · checkHookingXposed
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-0048, MASTG-TEST-0050

How it works

What the code inspects.

Scans /proc/self/maps for XposedBridge.jar, liblspd, libriru, libsubstrate and libzygisk.

Attempts Class.forName("de.robv.android.xposed.XposedBridge") across class loaders, and walks the current thread's stack trace for frames in de.robv.android.xposed or com.saurik.substrate.

Each of the three — mapped library, loadable bridge class, or bridge frame on the stack — independently indicates a Xposed-family hooking framework is active in the process.

The exploit it addresses

Why this matters.The threat.

Xposed / LSPosed let a 'module' hook arbitrary methods of any app process-wide without modifying the APK — a persistent, reboot-surviving way to patch out security logic, spoof data, or harvest inputs.

How it can be bypassed

No single check is sufficient.Known evasions.

Modern LSPosed runs through Zygisk and can hide itself from a target app's class loader and maps, and Shamiko-style hiding further removes its traces.

An attacker can unload the bridge from the enumerated class loaders, or hook the maps/stack inspection itself.

Validation scenarios

Where this check is exercised.1 scenario.

A04

Xposed / LSPosed

Pending · android

Open →

References & further reading

All checks

← Frida instrumentation Debugger attached →