From 2625e06eb94a7cdcaab69d351ca96cf5444667c7 Mon Sep 17 00:00:00 2001
From: h0mbre <47577114+h0mbre@users.noreply.github.com>
Date: Sat, 4 Nov 2023 15:06:11 -0400
Subject: [PATCH] Update 2023-11-04-New_Fuzzer_Project.md

---
 _posts/2023-11-04-New_Fuzzer_Project.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/_posts/2023-11-04-New_Fuzzer_Project.md b/_posts/2023-11-04-New_Fuzzer_Project.md
index eaa4704..800e129 100644
--- a/_posts/2023-11-04-New_Fuzzer_Project.md
+++ b/_posts/2023-11-04-New_Fuzzer_Project.md
@@ -51,4 +51,4 @@ Going a bit deeper, this setup requires us to sandbox Bochs and run it inside of
 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. 
 
 So in general, this is how our fuzzing setup should look:
-![](/assets/images/pwn/FuzzerArch.PNG
+![](/assets/images/pwn/FuzzerArch.PNG)