TGViewer
ReverseEngineering ReverseEngineering @reverseengine · 1.33K subscribers
Post #1745 39
Fuzzing

means first understand
where the input comes from
then understand
how it is processed inside the program
then do Fuzzing on that path
This is much better than just generating a bunch of random data without knowing the program and hoping that something will explode
Because the operating system and programs are unfortunately not designed to cooperate with our wishes
When a Crash is found
Now suppose the Fuzzer gives us a result

Crash found
input_0421.dat

The work is not over here
Incidentally, the interesting part has just begun
We run the same Input again with the Debugger

Input
↓
Program
↓
Crash
↓
Debugger
↓
Call Stack
↓
Faulting Instruction

Now we want to find out
Where exactly the Crash occurred
Which instruction caused it
What state did the registers have
What was the memory like
What path does the Call Stack show
And most importantly
What was the Root Cause
For example, we might first just see the program crash on a specific instruction
But this still does not mean that the same Instruction is the root cause of the bug
It is possible that corrupt data was entered into the program a few steps earlier and its effect has only shown itself here.
So the analysis path can look like this:

Crash
↓
Faulting Instruction
↓
Register State
↓
Memory State
↓
Call Stack
↓
Data Flow
↓
Root Cause

This is exactly where Fuzzing and Reverse Engineering come together
Fuzzer says
This Input caused the Crash
Reverse Engineer says
Well, now let's see why

When we don't have Source Code
First, we don't go to Fuzzing blindly
First, we examine the Binary
Then we look for Input
Then we find the path of Input movement inside the program, then we understand the Input Format structure as much as we can
Then we find the appropriate Seed
Then we put the Fuzzer on that path
And if a Crash is found
We go back to Debugger and Reverse Engineering
The whole path can be seen like this

Binary
↓
Reverse Engineering
↓
Input Discovery
↓
Input Analysis
↓
Seed
↓
Fuzzing
↓
Crash
↓
Debugger
↓
Root Cause Analysis

The main point of this post is that
when you don't have the source code
it doesn't mean you can't do fuzzing
you just need to understand the binary before fuzzing
Reverse Engineering helps you understand
where the data comes from
where it is parsed
what parts of the input are important
and what paths it takes in the program
and this information can greatly improve the quality of fuzzing

@reverseengine
More from @reverseengine
  1. Oct 15, 2026Reverse Engineer Anything v6.5.0 A tool for reverse engineering that allows AI agents to a…
  2. Oct 15, 2026Someone Used AI to Reverse-Engineer PS5 Security in Weeks: What Is REA? https://pub.toward…
  3. Oct 15, 2026How Dangerous Is REA (Reverse Engineer Anything) for Your App? https://21zerixpm.medium.co…
  4. Oct 15, 2026REA Is Impressive. But Reverse Engineering Was Never the New Part https://crizantlai.mediu…
  5. Oct 15, 2026QuarkslaB Dynamic binary Instrumentation https://qbdi.quarkslab.com/introduction @reversee…
  6. Oct 15, 2026angr’s documentation https://docs.angr.io/en/latest/search.html?q=Document&check_keywords=…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →