updated documentation

1 files changed, 22 insertions, 72 deletions

diff --git a/documentation/README.md b/documentation/README.md
index c884c35..ca08eef 100644
--- a/documentation/README.md
+++ b/documentation/README.md
@@ -2,7 +2,7 @@ STLDoctor
 =========
 
 STLDoctor is a plain-text protocol service, that allows users to upload STL files
-and generate reports that include information on the files..
+and generate reports that include information on the file's..
 
 - model name
 - binary header
@@ -10,17 +10,22 @@ and generate reports that include information on the files..
 - file size
 - triangle count
 - bounding box size and position
+- validity
 
 Uploaded models and generated reports are stored in a directory structure.
 
-Unregistered users have their files saved in a collective directory, which
-allows users to search for public models via model name. Registered users have
-their uploads saved to a private directory. This (theoretically) prevents other
+Unregistered user's files are saved in a collective directory, which
+allows users to search for public models via model name. Registered user's
+uploads are saved to a private directory. This (theoretically) prevents other
 users from accessing their files.
 
 The service is hosted with socat, one process per client.
 
-A cron job is used to periodically clean up models by using their *last modified* date.
+Models are periodically cleaned up using files *last modified* date.
+
+For both flagstores the **service returns the flag in plaintext**, which is
+vulnerable to detection by network filters and can lead to easy replication
+of exploits.
 
 
 RCE Countermeasures
@@ -47,73 +52,18 @@ For this reason, additional security features are enabled via compilation flags:
 Checker
 =======
 
-The checker checks the following behavior:
-
-- File upload and search (for both bin and ascii):
-	- Open a session
-	- Upload a file of random, valid contents with random model name
-	- Ensure file is listed in search
-	- Open a new session
-	- Ensure file is listed in search
-	- Ensure file is not listed in search for different model name
-- Registering and private files (for both bin and ascii):
-	- Open a session
-	- Register with a random password
-	- Upload a file of random, valid contents with random model name
-	- Open a new session
-	- Ensure file is not listed in search
-	- Register with previous password
-	- Ensure file is listed in search
-- Check upload ordering and accessing indeces != 0:
-	- Open a session
-	- Upload a file of random, valid contents with random model and solid name
-	- Upload a different file of random, valid contents with same model name but different solid name
-	- Open a new session
-	- search for same model name and pick 1st entry
-	- Compare returned solid name with expected (1st upload)
-	- search for same model name and pick 2nd entry
-	- Compare returned solid name with expected (2nd upload)
-
-
-The checker tenets:
-
-- A checker SHOULD not be easily identified by the examination of network traffic
-	satisfied, because checker uses regular user interface and picks strings from a wordlist
-	to appear more human (TODO)
-- A checker SHOULD use unusual, incorrect or pseudomalicious input to detect network filters
-	satisfied, send various garbage bytes for model name and file contents (TODO)
-
-The checker does the following to upload the first flagstore's flag:
-
-- Open a session
-- Use `upload` to upload a file of random, valid contents with a
-	the flag as the model name
-
-The checker does the following to upload the second flagstore's flag:
-
-- Open a session
-- Register as a premium user
-- Use `upload` to upload a binary STL with the flag as its solidname
-	and a random model name chosen from a wordlist with numbers for
-	collision resistance
-
-The checker should not be easily identifiable, since this could allow
-players to only enable certain service functions when the checker is
-detected.
-
-Notes on evading detection of the checker through traffic analysis:
-
-- File upload contents are randomly generated valid STLs and the model name is
-	picked randomly from a wordlist to blend in with regular requests
-- The username used for premium user registration is chosen at random from
-	a wordlist (with numbers appended for collision resistance) to blend
-	in with other requests
-- The STL file which belongs to the second flagstore is not easily identifiable
-	since the binary file format is used and viewing the file contents does not
-	help identify the 3d model encoded
-- The first flagstore's flag IS easily identifiable, since it is sent in cleartext
-	to the service, however, the checker makes sure to test upload and searching
-	functionality of files with other model names in another session as well
+The checker is **not easily identifiable by the examination of network traffic**,
+because it uses the regular user interface and chooses random input in a way
+that appears human. This prevents players from only enabling certain service
+functions when the checker is detected.
+
+The checker **uses unusual, incorrect or pseudomalicious input to detect network filters**
+by replicating the same type of data sent in an exploit (negative chars) in other
+context, which avoids filtering.
+
+The checker **tests processing of many different valid and invalid inputs**
+to verify that the service can properly distinguish the two and verifies
+input as it should.
 
 
 Vuln 1: Value Collision