Android Fuzzing & Vulnerability Research

Fuzzing is feeding large volumes of malformed or random input to a program to provoke crashes that reveal bugs. Modern fuzzers are coverage-guided: they keep inputs that reach new code paths and mutate them further, so the search steadily learns the target instead of guessing blindly.

Pentesting exploits known weakness classes within a scope to measure risk; a bug bounty hunts known-class bugs in a live target for a reward. Vulnerability research discovers previously unknown vulnerabilities, the 0-days, typically through fuzzing and reverse engineering. Research produces the bugs the other two later check for.

Code that parses untrusted, structured input in a memory-unsafe language: native C/C++ media and image parsers, font and archive handlers, an app's own JNI libraries, crypto routines, and system services reachable over Binder. Pure Java is a weaker target because the runtime is memory-safe.

Many memory errors corrupt silently and never crash on their own, so a fuzzer would miss them. Sanitizers instrument the code to detect the error the instant it happens and print the bug class and location. Running ASan or UBSan during fuzzing turns silent corruption into loud, located crashes.

Triage: reproduce it deterministically from the saved input, deduplicate crashes by stack, and judge which are genuine, security-relevant bugs. Real research then follows coordinated disclosure, reporting the vulnerability to the vendor rather than publishing a weaponised exploit.

A plain byte-mutating fuzzer invalidates the checksum with every edit, so the parser rejects its inputs before the deeper code runs and coverage plateaus. The fixes are to disable the checksum in the harness or use structure-aware fuzzing that mutates a parsed representation and recomputes the checksum, keeping inputs valid enough to reach the bug.