In this post, we'll walk through fuzzing from the ground up: what it is, the main styles (black, grey, and white-box), and how to pick the right fuzzer for your target. Then we'll build practical fuzzing harnesses, point them at real CVE-affected libraries, and reproduce the exact crashes behind those bugs. Along the way, you'll use ASan/UBSan.

In our last post we black-box fuzzed Samsung's libhwui.so (Skia/Android frontend) and re-created the CVE-2020-8899 class of issues. AFL++ turned up ~674 unique crashes. This follow-up is the so what?: we'll turn those opaque SIGSEGVs into actionable bug buckets using an AddressSanitizer-enabled harness and a Python triage script that batch-runs every crash, captures full ASAN reports, and scores exploitability.

0-click vulnerabilities are million-dollar bugs. Here’s how we reproduced one using a black-box fuzzing harness for Samsung’s Qmage parser. In this article, we'll reproduce the crash associated with CVE-2020-8899 by fuzzing libhwui.so. This work builds on our previous article, where we extracted the Samsung Note 10+ stock firmware and obtained the libhwui.so library. Using the extracted firmware as a rootfs to emulate the target filesystem for fuzzing, we'll construct a custom fuzzing harness to rediscover the same vulnerability.

In this article we'll explore the Linux Kernel Library (LKL), diving into its functionality, how it operates, and its use in fuzzing kernel components from userspace with tools like libFuzzer. We'll examine how LKL emulates a kernel environment and enables access to kernel functions from a userspace application.