Update 2023-11-04-New_Fuzzer_Project.md

_posts/2023-11-04-New_Fuzzer_Project.md

@@ -14,7 +14,7 @@ tags:
 ---
 
 ## Introduction && Credit to Gamozolabs
-For a long time I've wanted to develop a fuzzer on the blog, but for one reason or another, I could never really conceptualize a project that would be not only worthwhile as an educational tool, but also offer *some* utility to the fuzzing community in general. Recently, for Linux Kernel exploitation reasons, I've been very interested in [Nyx](https://nyx-fuzz.com/). Nyx is a KVM-based hypervisor fuzzer that you can use to snapshot fuzz traditionally hard to fuzz targets. A lot of the time (most of the time?), we want to fuzz things that don't naturally lend themselves well to traditional fuzzing approaches. When faced with target complexity in fuzzing (leaving input generation and nuance aside for now), there have generally been two approaches.
+For a long time I've wanted to develop a fuzzer on the blog during my weekends and freetime, but for one reason or another, I could never really conceptualize a project that would be not only worthwhile as an educational tool, but also offer *some* utility to the fuzzing community in general. Recently, for Linux Kernel exploitation reasons, I've been very interested in [Nyx](https://nyx-fuzz.com/). Nyx is a KVM-based hypervisor fuzzer that you can use to snapshot fuzz traditionally hard to fuzz targets. A lot of the time (most of the time?), we want to fuzz things that don't naturally lend themselves well to traditional fuzzing approaches. When faced with target complexity in fuzzing (leaving input generation and nuance aside for now), there have generally been two approaches.
 
 One approach is to lobotomize the target such that you can isolate a small subset of the target that you find "interesting" and only fuzz that. That can look like a lot of things, such as ripping a small portion of a Kernel subsystem out of the kernel and compiling it into a userland application that can be fuzzed with traditional fuzzing tools. This could also look like taking an input parsing routine out of a Web Browser and fuzzing just the parsing logic. This approach has its limits though, in an ideal world, we want to fuzz anything that may come in contact with or be affected by the artifacts of this "interesting" target logic. This lobotomy approach is reducing the amount of target state we can explore to a large degree. Imagine if the hypothetical parsing routine successfully produces a data structure that is later consumed by separate target logic that actually reveals a bug. This fuzzing approach fails to explore that possibility.
 
@@ -57,3 +57,4 @@ So in general, this is how our fuzzing setup should look:
 In order to provide a sandboxed environment, we must load an executable Bochs image into our own fuzzer process. So for this, I've chosen to build Bochs as an ELF and then load the ELF into my fuzzer process in memory. Let's dive into how that has been accomplished thus far. 
 
 ## Loading an ELF In Memory
+So in order to make this portion of loading Bochs in memory in the most simplistic way possible, I've chosen to compile Bochs as a `-static-pie` ELF. Now this means that the built ELF has no expectations about where it is loaded. In its `_start` routine, it actually has all of the logic of the normal OS ELF loader necessary to perform all of its own relocations. How cool is that? But before we get too far ahead of ourselves, the first goal will just be to simply build and load a `-static-pie` test program and make sure we can do that correctly.