The Three Pillars of Vulnerability Research: Code Review, Reverse Engineering, and Fuzzing

The Three Pillars of Vulnerability Research: Code Review, Reverse Engineering, and Fuzzing

Vulnerability research is a complex and evolving field that combines multiple disciplines to uncover security flaws in software and systems. At its core, it revolves around three main techniques:

  1. Code Review
  2. Reverse Engineering
  3. Fuzzing

Each of these plays a critical role in identifying vulnerabilities — from the foundational understanding of source code to the deep exploration of compiled binaries and the automated discovery of bugs through fuzz testing.


1. Code Review – The Foundation of Vulnerability Discovery

Code review is the process of analyzing source code to identify potential vulnerabilities. It is often the first step in vulnerability research, as it allows researchers to understand the logic, structure, and behavior of a system at a granular level.

Key Techniques in Code Review:

  • Manual code tracing: Following data flow from input (source) to sensitive operations (sink)
  • Static analysis tools: Automated tools like CodeQL, Semgrep, or Coverity help detect common patterns
  • Taint analysis: Tracking untrusted input through the code to identify unsafe operations
  • Root cause analysis: Understanding the underlying logic that leads to a vulnerability

🛠️ Why Code Review Matters:

Code review is essential because many vulnerabilities stem from subtle logic flaws or overlooked edge cases, especially in widely used open-source libraries.

Real-World Example: CVE-2021-44228 (Log4Shell)

The infamous Log4Shell vulnerability in Apache Log4j was a result of a JNDI injection flaw discovered in 2016 but existed in the codebase since 2013. Despite its critical impact — allowing remote code execution on millions of devices — it remained undetected for years, likely due to insufficient code review and automated scanning.

This case highlights how critical human expertise is in code review, especially when automated tools may miss complex vulnerabilities.

Open Source Dependencies: A Double-Edged Sword

Many modern applications rely on open-source libraries, often without understanding the security implications. Vulnerabilities in these libraries can propagate across thousands of projects.

  • Apache OpenOffice RCE: A vulnerability discovered in 2021 was actually a copy of a patched flaw in LibreOffice, showing how forked code can carry unpatched issues.
  • liblzma Backdoor (2024): A malicious backdoor was inserted into the widely used liblzma compression library, affecting many Linux distributions. The vulnerability could allow attackers to gain access to SSH services remotely.

These examples demonstrate the importance of reviewing not just your own code, but also third-party dependencies.


2. Reverse Engineering – Uncovering the Hidden Flaws

Reverse engineering involves analyzing compiled binaries to understand their behavior and uncover vulnerabilities when source code isn’t available.

Key Techniques in Reverse Engineering:

  • Static analysis: Using tools like IDA Pro, Ghidra, or Radare2 to disassemble and decompile binaries
  • Dynamic analysis: Running the binary under debuggers like GDB or x64dbg to observe runtime behavior
  • Decompilation: Reconstructing high-level code from compiled binaries
  • Binary instrumentation: Tools like Frida or Pin allow runtime manipulation and tracing

Why Reverse Engineering Is Powerful:

Many systems rely on “security through obscurity”, assuming that compiled code is too complex or unreadable to be exploited. However, this often leads to undiscovered vulnerabilities lingering for years.

Think of reverse engineering as exploring a dark tunnel — you don’t know what’s around the corner, but with the right tools and techniques, you’ll eventually uncover hidden dangers.

Real-World Example: Angelboy’s NAS Exploits

Security researcher Angelboy discovered remote code execution vulnerabilities in several network-attached storage (NAS) devices by analyzing Netatalk, an open-source Apple Filing Protocol (AFP) server used by vendors. Instead of targeting the proprietary firmware, he focused on the open-source component, which was common across multiple devices.

This demonstrates how reverse engineering can bypass proprietary protections by targeting shared open-source components.


3. Fuzzing – Automated Vulnerability Hunting

Fuzzing is a highly automated technique that involves feeding unexpected or malformed inputs to a program to trigger crashes, memory leaks, or other abnormal behavior that may indicate a vulnerability.

Key Techniques in Fuzzing:

  • Coverage-guided fuzzing: Tools like AFL++, libFuzzer, or Honggfuzz use feedback to explore more code paths
  • Fuzzing harnesses: Custom code that feeds inputs to specific functions or components
  • Crash triaging: Identifying exploitable crashes using tools like AddressSanitizer (ASan) or Dr. Memory
  • Distributed fuzzing: Scaling fuzzing across multiple machines to accelerate discovery

Why Fuzzing Is Effective:

Fuzzing automates the process of vulnerability discovery, making it ideal for early detection in the software development lifecycle. It’s especially useful for testing parsers, file formats, and network protocols.

Real-World Applications:

  • Google OSS-Fuzz: A continuous fuzzing service that has found tens of thousands of bugs in popular open-source projects.
  • Modern Fuzzing in Practice: Many mature development teams now integrate fuzzing into CI/CD pipelines, catching low-hanging vulnerabilities before release.

However, effective fuzzing requires knowledge of the code and system behavior, which is why it builds on code review and reverse engineering skills.


How These Disciplines Work Together

While each technique has its own strengths, the most effective vulnerability research combines all three:

StageDisciplinePurpose
1Code ReviewUnderstand system logic, identify potential flaws
2Reverse EngineeringAnalyze compiled binaries, find hidden issues
3FuzzingAutomatically test for edge cases and crashes

For example, a researcher might:

  1. Review the source code of a target library
  2. Reverse engineer a binary that uses the library
  3. Write a fuzzing harness to test specific functions for crashes or vulnerabilities

This layered approach increases the chances of discovering deep, critical vulnerabilities.


Summary: Choosing the Right Technique

TechniqueBest ForTools
Code ReviewOpen-source projects, understanding logicCodeQL, Semgrep, Coverity
Reverse EngineeringClosed-source binaries, firmware, proprietary softwareGhidra, IDA Pro, Radare2
FuzzingAutomated bug hunting, testing edge casesAFL++, libFuzzer, OSS-Fuzz

Resources & Further Reading

Total
2
Shares

Leave a Reply

Previous Post
Vulnerability Research vs. Penetration Testing: Different Goals, Shared Techniques

Vulnerability Research vs. Penetration Testing: Different Goals, Shared Techniques

Next Post
How to Select the Right Target for Vulnerability Research: A Practical Guide

How to Select the Right Target for Vulnerability Research: A Practical Guide

Related Posts