Skip to content

Commit

Permalink
Update 2023-11-04-New_Fuzzer_Project.md
Browse files Browse the repository at this point in the history
  • Loading branch information
h0mbre authored Nov 4, 2023
1 parent ccfe63b commit da513ea
Showing 1 changed file with 3 additions and 1 deletion.
4 changes: 3 additions & 1 deletion _posts/2023-11-04-New_Fuzzer_Project.md
Original file line number Diff line number Diff line change
Expand Up @@ -48,7 +48,9 @@ This is where we discuss how the fuzzer will be designed according to the inform

Going a bit deeper, this setup requires us to sandbox Bochs and run it inside of our "fuzzer" process. In an effort to isolate Bochs from the user's OS and Kernel, we will sandbox Bochs so that it cannot interact with our operating system. This allows us to achieve a few things, but chiefly this should make Bochs deterministic. As Gamozo explains on stream, isolating Bochs from the operating system, prevents Bochs from accessing any random/randomish data sources. This means that we will prevent Bochs from making syscalls into the kernel as well as executing any instructions that retrieve hardware-sourced data such as `CPUID` or something similar. I actually haven't given much thought to the latter yet, but syscalls I have a plan for. With Bochs isolated from the operating system, we can expect it to behave the same way each fuzzing iteration. Given Fuzzing Input A, Bochs should execute exactly the same way for 1 trillion successive iterations.

Secondly, it also means that the entirety of Bochs' state will be contained within our sandbox, which should enable us to reset Bochs' state more easily instead of it being a remote process. In a paradigm where Bochs executes as intended as a normal Linux process for example, resetting its state is not trivial and may leave you making either Kernel modifications or writing your own Kernel driver. Neither of which I feel like doing for the simple purpose of resetting Bochs.
Secondly, it also means that the entirety of Bochs' state will be contained within our sandbox, which should enable us to reset Bochs' state more easily instead of it being a remote process. In a paradigm where Bochs executes as intended as a normal Linux process for example, resetting its state is not trivial and may require a heavy handed approach such as page table walking in the kernel for each fuzzing iteration or something even worse.

So in general, this is how our fuzzing setup should look:
![Fuzzer Architecture](/assets/images/pwn/FuzzingArch.PNG)

In order to provide a sandboxed environment, we must load an executable Bochs image into our own fuzzer process.

0 comments on commit da513ea

Please sign in to comment.