Firmware-level Android Backdoor via libandroid_runtime Zygote Injection

Overview

Supply-chain tampering of /system/lib[64]/libandroid_runtime.so can hijack android.util.Log.println_native so that every app forked from Zygote executes attacker code. The Keenadu backdoor adds a single call inside println_native that drives a native dropper. Because all app processes run this code, Android sandbox boundaries and per-app permissions are effectively bypassed.

The same post-root execution model also appears in multi-stage Android rootkits delivered from apparently benign Play-distributed apps. In McAfee's Operation NoVoice analysis, the malware first landed in user space, obtained root with device-tailored exploits, and then replaced libandroid_runtime.so and libmedia_jni.so on the system partition so that every app spawned by zygote inherited the attacker hooks after reboot.

Pre-root staging: SDK init hijack + PNG tail polyglot

Before the libandroid_runtime.so replacement, NoVoice used an app-level bootstrap that is worth recognizing during APK triage:

Auto-exec on first launch: bootstrap code ran from a tampered Facebook SDK init path, so no extra user interaction or suspicious permission prompt was required.
Payload smuggling in assets: the app shipped a valid PNG with an encrypted blob appended after the PNG IEND marker. Android image decoders ignore trailing bytes, but the loader carved the tail into enc.apk, decrypted it into h.apk, loaded it, and deleted the staging files.
Triage clue: if bytes immediately after IEND begin with a magic such as CAFEBABE, assume the image is acting as a polyglot carrier for a Java class / JAR / APK payload rather than as a pure media asset.

Quick checks:

pngcheck -v suspicious.png
tail -c +1 suspicious.png | xxd | tail
binwalk -e suspicious.png

Hunting notes:

Search APK assets/ for PNGs with unexpected trailing bytes or high entropy after IEND.
Trace early init paths such as Application.onCreate, third-party SDK bootstrap code, or native JNI_OnLoad handlers that open asset PNGs and then write *.apk / *.jar files into the app sandbox.

Dropper path: native patch → RC4 → DexClassLoader

Hooked entry: extra call inside println_native to __log_check_tag_count (injected static lib libVndxUtils.a).
Payload storage: RC4-decrypt blob embedded in the .so, drop to /data/dalvik-cache/arm[64]/system@framework@vndx_10x.jar@classes.jar.
Load & execute: DexClassLoader loads the jar and invokes com.ak.test.Main.main. Runtime logs use tag AK_CPP (triage artifact).
Anti-analysis: aborts in Google/Sprint/T-Mobile system apps or if kill-switch files exist.
Zygote role split:
In system_server → instantiate AKServer.
In any other app → instantiate AKClient.

Binder-based client/server backdoor

AKServer (running in system_server) sends protected broadcasts:
com.action.SystemOptimizeService → binder interface for clients.
com.action.SystemProtectService → binder interface for downloaded modules.
AKClient (inside every app) receives the interface via broadcast and performs an attach transaction, handing an IPC wrapper so the server can load arbitrary DEX inside the current app process.
Exposed privileged operations (via SystemProtectService): grant/revoke any permission for any package, retrieve geolocation, and exfiltrate device info. This centralizes privilege bypass while still executing code in chosen target apps (Chrome, YouTube, launcher, shopping apps, etc.).

C2 staging, crypto, and gating

Host discovery: Base64 → gzip → AES-128-CFB decrypt with key MD5("ota.host.ba60d29da7fd4794b5c5f732916f7d5c"), IV "0102030405060708".
Victim registration: collect IMEI/MAC/model/OS, encrypt with key MD5("ota.api.bbf6e0a947a5f41d7f5226affcfd858c"), POST to /ak/api/pts/v4 with params m=MD5(IMEI) and n=w|m (network type). Response data is encrypted identically.
Activation delay: C2 serves modules only after ~2.5 months from an "activation time" in the request, frustrating sandbox detonations.

Module container (proprietary):

struct KeenaduPayload {
    int32_t  version;
    uint8_t  padding[0x100];
    uint8_t  salt[0x20];
    KeenaduChunk config;   // size + data
    KeenaduChunk payload;  // size + data
    KeenaduChunk signature;// size + data
} __packed;

Integrity: MD5 file check + DSA signature (only operator with private key can issue modules).
Decryption: AES-128-CFB, key MD5("37d9a33df833c0d6f11f1b8079aaa2dc" + salt), IV "0102030405060708".

Post-root persistence: wrapper libraries + framework patching + self-heal

Once root is available, replacing libandroid_runtime.so is only one layer of persistence. NoVoice shows a more resilient pattern:

Wrapper replacement instead of inline patching: the installer backed up the original system library and replaced it with an architecture-matched hook wrapper. The same campaign also replaced libmedia_jni.so, giving multiple code-execution choke points inside the framework.
Second-stage persistence in framework bytecode: after the library swap, a dedicated patcher modified pre-compiled Android framework bytecode on disk. This means restoring the original .so may still leave injected redirections active.
Self-healing watchdog: a daemon checked the installation roughly every 60 seconds, restored missing components, and could force a reboot if reinsertion kept failing. The malware also replaced the system crash handler / recovery flow so rebooting re-launched the rootkit.
Per-app payload assembly at runtime: after reboot, the replaced libandroid_runtime.so caused each spawned app to load attacker code. NoVoice stored secondary payloads as fragments inside the malicious library, assembled them in memory, and deleted the disk copies immediately after load.

Practical implications:

Factory reset is insufficient when the malware has modified the system partition or framework artifacts. Reflash the firmware instead.
Diff both /system/lib*/libandroid_runtime.so and framework oat/odex/vdex artifacts; checking only the shared library can miss the bytecode persistence layer.
If a device keeps restoring the malicious library after manual cleanup, look for a watchdog daemon, modified recovery scripts, or a replaced crash-handler path that is re-seeding the implant on boot.

Persistence & forensic tips

Supply chain placement: malicious static lib libVndxUtils.a linked into libandroid_runtime.so during build (e.g., vendor/mediatek/proprietary/external/libutils/arm[64]/libVndxUtils.a).
Firmware auditing: firmware images ship as Android Sparse super.img; use lpunpack (or similar) to extract partitions and inspect libandroid_runtime.so for extra calls in println_native.
On-device artifacts: presence of /data/dalvik-cache/arm*/system@framework@vndx_10x.jar@classes.jar, logcat tag AK_CPP, or protected broadcasts named com.action.SystemOptimizeService/com.action.SystemProtectService indicate compromise.
For Android rootkits deployed from apps instead of factory supply chain, also inspect:
APK assets/ for polyglot PNGs with appended data after IEND
Replaced /system/lib*/libandroid_runtime.so or /system/lib*/libmedia_jni.so
Modified framework oat/odex/vdex files that preserve hook redirections
Periodic watchdog processes that rewrite removed files or trigger forced reboots