Android Exploit Development

It is the discipline of attacking memory in Android's native code — C/C++ libraries reached through JNI, system daemons and the kernel — rather than app logic. A memory-corruption bug in the right place can give arbitrary code execution and cross the app sandbox, far beyond what a logic flaw achieves.

Because JNI is where untrusted data crosses from the bounds-checked Java runtime into raw C pointers with no bounds checks. Length fields, offsets and buffers that were safe in Java become the programmer's responsibility in C, so mistakes there turn into memory corruption.

Four dominate on modern ARM64: ASLR randomises addresses so you need an info leak; NX (W^X) blocks executing injected code so you reuse existing code via ROP; stack canaries detect stack smashing; and PAC/CFI sign or constrain indirect branches. Each raises the bar and dictates which bug primitives you need.

No. Most crashes are not exploitable, or are only exploitable with primitives the mitigations deny. The core skill is triage: reproduce the crash, classify the bug, and judge whether it justifies the hours a reliable chain costs before committing to it.

Yes, when you stay in a lab you control. Memory-corruption research must only target software and devices you own or are explicitly authorised to test, and working exploits never leave the lab. The course stops at understanding a reproducible crash, not weaponising it.

Native crashes produce a tombstone, and a summary lands in logcat under the DEBUG tag. Look at the signal, the fault address, the register state and the backtrace. If the program counter or fault address holds your input bytes (such as 0x4141414141414141), you reached control of execution — a strong exploitability signal.