Update README.md

README.md

@@ -2,16 +2,19 @@
 DARPA CGC Challenges Binaries in Linux, Windows, and OS X
 
 #original-challenges 
-This folder contains all of the unmodified challenge binaries
+This folder contains all of the unmodified sources for the challenge binaries. Challenges that are not building or are not yet supported are in `broken` and `multibin` respectively.
 
 #include
-This folder contains libcgc, which implements the syscalls to work on non-Decree systems. Currently works on OS X and Linux. 
+This folder contains libcgc, which implements the syscalls to work on non-Decree systems. Currently works on OS X and Linux.
 
 #tools
 This folder contains some python scripts that help with modifying, building, and testing the original challenges
 
 ###cb_patcher.py
-This script will copy all challenges out of `original-challenges`, modify them as necessary, and place them in `cqe-challenges`. The main modifications are a set of find/replace definitions in `manual_patches.yaml`.
+This script will copy all challenges out of `original-challenges`, modify them as necessary, and place them in `cqe-challenges`. These modifications include: 
+
+- Deleting `libcgc.h` if it appears anywhere in the challenge source
+- A set of find/replace definitions in `manual_patches.yaml`
 
 ###makefiles.py
 This will parse the `Makefile` in each challenge folder and generate a `CMakeLists.txt` with the same variables and CFLAGS. This also adds the `-nostdinc` flag to all challenges, so that they have no access to the system libraries, and can only include their own libraries and `libcgc.h`.
@@ -26,15 +29,13 @@ To build the binaries, run
 $ ./build.sh
 ```
 
-That should build both the original and patched binaries in the `bin` folder of the respective binary. 
-
-Currently this works on OS X. Some of the binaries also work on Linux, but not all. Yet. 
+This will build both the original and patched binaries in the `bin` folder of the respective binary. 
 
 #Testing
 The cgc provided testing tools (located in `tools/cb-testing`) can be made to work with some tweaking. 
 Key differences involved:
 
-- Changing the testing script to use SOCAT instead of their own program and adjusting the script accordingly (use local ip, and correct directories, etc)
+- Changing the testing script to use `socat` instead of their own `cb-server` and adjusting the script accordingly (use local ip, and correct directories, etc)
 - Lessening many of the sleep and timeout times so they could run at a reasonable rate
 
 Most changes were in `cb-test` although there were a few timeout changes in `cb-replay`.
@@ -56,11 +57,7 @@ $ ./cb_tester.py -c CROMU_00001 CROMU_00002 -o out.xlsx
 
 
 
-#current State
-The cgc testing tools were made to work on both linux and mac and the result of running these tests has been organized in the spreadsheet below. 
-
-https://docs.google.com/spreadsheets/d/1B88nQFs1G7MZemB2leOROhJKSNIz_Rge6sbd1KZESuE/edit?pli=1#gid=1553177307
-
-#Notes
-Some issues were found in which system specific constants (ie size of pointers) was hardcoded into certain binaries. I fixed errors of this nature where I could find them, but there may be more still present, specfically in binaries which implement their own malloc, although I am not sure.
+#Current State
+The cgc testing tools were made to work on both Linux and OS X and the result of running these tests has been organized in the spreadsheet below. 
 
+https://docs.google.com/spreadsheets/d/1B88nQFs1G7MZemB2leOROhJKSNIz_Rge6sbd1KZESuE/edit?pli=1#gid=1553177307