diff --git a/_posts/2023-11-04-New_Fuzzer_Project.md b/_posts/2023-11-04-New_Fuzzer_Project.md
index 9926c18..84d6e80 100644
--- a/_posts/2023-11-04-New_Fuzzer_Project.md
+++ b/_posts/2023-11-04-New_Fuzzer_Project.md
@@ -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.