native-audit

Audit bundled Android native libraries and the JNI boundary for memory corruption and RCE flaws.

48|27|Updated Jul 30, 2026
One-click install
npx skills add https://github.com/abisheikM1/Tribunal --skill native-audit-abisheikm1
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: native-audit
Source: https://github.com/abisheikM1/Tribunal/tree/main/legacy-harness/skills/native-audit
Command: npx skills add https://github.com/abisheikM1/Tribunal --skill native-audit-abisheikm1

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve? Android apps ship compiled C/C++ code as .so libraries with no memory safety, and auditing them for buffer overflows, use-after-free, and insecure JNI boundaries requires deep reverse-engineering expertise that is easy to get wrong or skip entirely. ## Core Features & Use Cases - Native Library Inventory: A read-only detector script lists every bundled lib/<abi>/.so with ABI and size, and flags JNI_OnLoad, Java_ exports, and risky imports like strcpy, sprintf, and memcpy when binutils are available. - Five-TTP Methodology: Structured test procedures cover memory corruption, use-after-free, native RCE, insecure JNI boundaries, and known-CVE bundled libraries, each with preconditions, signals, and confirmation steps. - Hardening Review: checksec-style commands verify RELRO, stack canaries, PIE, FORTIFY, and NX so missing mitigations are reported alongside any memory bug. - Use Case: During an authorized bug-bounty test, you find an exported Activity passing attacker bytes to a native method; use this Skill to inventory the .so, reverse the JNI handler in radare2 or Ghidra, and confirm an out-of-bounds write under ASan. ## Quick Start Run the native-audit inventory script against my extracted APK target hash and tell me which bundled .so libraries expose JNI entry points or risky C imports worth reversing.

Frequently Asked Questions about native-audit

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I find memory corruption bugs in Android native libraries?

Inventory the bundled .so files, flag risky imports like strcpy and memcpy, then reverse each reachable JNI handler in Ghidra or radare2 to find unchecked length copies. Confirm with an ASan-instrumented fuzzing harness or frida-trace on the dangerous sinks.

How to audit the JNI boundary in an Android app?

Grep the decompiled jadx output for System.loadLibrary and native method declarations, then trace which attacker-controlled sources feed those methods. Use frida-trace with -i "Java_*" to observe the exact bytes and lengths crossing into native code.

What tools do I need to reverse Android .so files?

The inventory script uses read-only binutils tools (nm, readelf, strings) and degrades gracefully without them. For depth you need a disassembler such as Ghidra, radare2, or IDA, plus Frida for live tracing and libFuzzer or AFL++ with ASan for fuzzing.

Does the native library scanner work without binutils installed?

Yes, the inventory script degrades gracefully when nm, readelf, and strings are missing from PATH. It still lists every .so file with ABI and size, but skips JNI export and risky-import signal detection until binutils is installed.

When should I not start with native code auditing?

Native auditing is the highest-effort surface, so exhaust cheaper checks like exported components, deep links, and WebView first. Only start here when a bundled .so is clearly reachable from an in-scope attacker input or another finding delivers data to native code.