added new gurthang documentation

sfi/after_fuzzing.md

@@ -4,7 +4,7 @@ Once you've completed a fuzzing run, you'll most likely have a few output files
 
 ![](./images/img_fuzz_results_screenshot1.png)
 
-The `LD_PRELOAD` library ("sockstorm") developed for this purpose uses a special file format to represent several connections' data in a single run. Because of this, sending the file straight to your server won't reproduce the exact behavior found by the fuzzer.
+The `LD_PRELOAD` library ("gurthang") developed for this purpose uses a special file format to represent several connections' data in a single run. Because of this, sending the file straight to your server won't reproduce the exact behavior found by the fuzzer.
 
 (If you'd like to see the details of one of these **comux** files, run `~cs3214/bin/comux -s -i PATH_TO_FILE [-v]` on one to show a summary of how many connections are represented in the file, and what data will be sent to the server.)
 

sfi/concepts_gurthang.md

@@ -0,0 +1,17 @@
+# Concepts: What is gurthang?
+
+AFL and AFL++ are excellent at what they do, but they have limitations. One such limitation is how AFL feeds input to the target program: it only works with programs that read from STDIN or from a file. In many cases, this is sufficient; lots of C programs take their input from STDIN or a file.
+  
+However, this project is about creating a HTTP server. Servers don't read input through a file or STDIN - they read from network sockets. So, the question becomes: how can we force a HTTP server to read input from STDIN, so we can fuzz it with AFL? Additionally, how can we do this without modifying your source code?
+  
+Gurthang is a C library I developed to solve this problem. It works by "overloading" the `accept` system call and running some extra code to establish an internal connection to your server. Using the special `LD_PRELOAD` environment variable, it can convince your server to use gurthang's copy of `accept`, rather than the actual system call.
+
+## Connection Multiplexing
+
+Once called, gurthang's version of the `accept` system call spawns a controller thread. This controller threads reads input via stdin, expecting a specific file format (dubbed the **comux** file format). These comux files are designed to specify the data to be sent to the target server across multiple connections. The controller thread parses the input file, then spawns individual threads to send "chunks" of data to the target server across specific connections.
+
+This approach allows for multiple internal client connections to be made to your server, increasing the probability of finding multithreading-related bugs. As a bonus, it requires *zero* modification to your source code. All you have to do is prepend `LD_PRELOAD=/path/to/gurthang-preload.so` to your command-line invocation of your server, then pipe one of these comux files to your process via stdin.
+
+## AFL++ Custom Mutator
+
+The other half of gurthang is an AFL++ custom mutator. AFL++ does great when fuzzing many programs on its own, but for more complex file formats (such as the **comux** files being used here), a custom mutator can be implemented to ensure the file's structure doesn't get overwritten during fuzzing. Gurthang's mutator (`gurthang-mutator.so`) does just that; it maintains the structure of each comux file while also randomly modifying (fuzzing) the connection data to be sent to the target server.

sfi/overview.md

@@ -4,7 +4,7 @@ The security of computer systems is extremely important. If vulnerabilities exis
   
 Web servers are one such type of computer system, and since most are directly connected to the internet, they're tested (and often deliberately attacked) every day by thousands of users. How can we be sure a web server can gracefully handle any sort of input?
   
-Some may argue that it's impossible to uncover _every_ bug in a system. But, we as computer scientists and computer engineers can use some effective techniques to catch most of them. Fuzzing is one such technique. This "fuzzing interface" allows you to utilize AFL++ (an advanced fuzzer) along with a special `LD_PRELOAD` library (called "sockstorm") to fuzz your pserv implementation. This will help you uncover any bugs in your code that cause your server to crash or hang.
+Some may argue that it's impossible to uncover _every_ bug in a system. But, we as computer scientists and computer engineers can use some effective techniques to catch most of them. Fuzzing is one such technique. This "fuzzing interface" allows you to utilize AFL++ (an advanced fuzzer) along with a special `LD_PRELOAD` library (called "gurthang") to fuzz your pserv implementation. This will help you uncover any bugs in your code that cause your server to crash or hang.
 
 A quick crash-course on how to get started is below. However, many more useful details can be found throughout the documentation.
 
@@ -12,14 +12,14 @@ A quick crash-course on how to get started is below. However, many more useful d
 
 ### **Concepts**
 
-- [What is fuzzing?](./sfi_concepts_fuzzing.md)
+- [What is fuzzing?](./concepts_fuzzing.md)
-- [What is AFL++?](./sfi_concepts_afl.md)
+- [What is AFL++?](./concepts_afl.md)
-- [What is sockstorm?](./sfi_concepts_sockstorm.md)
+- [What is gurthang?](./concepts_gurthang.md)
 
 ### **Fuzzing Interface**
 
-- [How do I fuzz my server?](./sfi_how_to_fuzz.md) (`fuzz-pserv.py`)
+- [How do I fuzz my server?](./how_to_fuzz.md) (`fuzz-pserv.py`)
-- [What do I do after fuzzing?](./sfi_after_fuzzing.md)
+- [What do I do after fuzzing?](./after_fuzzing.md)
 
 ## Quickstart: Fuzzing your Server
 

sfi/sfi_concepts_sockstorm.md

@@ -1,17 +0,0 @@
-# Concepts: What is sockfuzz?
-
-AFL and AFL++ are excellent at what they do, but they have limitations. One such limitation is how AFL feeds input to the target program: it only works with programs that read from STDIN or from a file. In many cases, this is sufficient; lots of C programs take their input from STDIN or a file.
-  
-However, this project is about creating a HTTP server. Servers don't read input through a file or STDIN - they read from network sockets. So, the question becomes: how can we force a HTTP server to read input from STDIN, so we can fuzz it with AFL? Additionally, how can we do this without modifying your source code?
-  
-Sockstorm is a C library I developed to solve this problem. It works by "overloading" the `accept` system call and running some extra code to establish an internal connection to your server. Using the special `LD_PRELOAD` environment variable, it can convince your server to use sockfuzz's copy of `accept`, rather than the actual system call.
-
-## Connection Multiplexing
-
-Once called, sockstorm's version of the `accept` system call spawns a controller thread. This controller threads reads input via stdin, expecting a specific file format (dubbed the **comux** file format). These comux files are designed to specify the data to be sent to the target server across multiple connections. The controller thread parses the input file, then spawns individual threads to send "chunks" of data to the target server across specific connections.
-
-This approach allows for multiple internal client connections to be made to your server, increasing the probability of finding multithreading-related bugs. As a bonus, it requires *zero* modification to your source code. All you have to do is prepend `LD_PRELOAD=/path/to/sockstorm-preload.so` to your command-line invocation of your server, then pipe one of these comux files to your process via stdin.
-
-## AFL++ Custom Mutator
-
-The other half of sockstorm is an AFL++ custom mutator. AFL++ does great when fuzzing many programs on its own, but for more complex file formats (such as the **comux** files being used here), a custom mutator can be implemented to ensure the file's structure doesn't get overwritten during fuzzing. Sockstorm's mutator (`sockstorm-mutator.so`) does just that; it maintains the structure of each comux file while also randomly modifying (fuzzing) the connection data to be sent to the target server.