final tweaks to documentations, added intro and final presentation slidesHEADmaster

1 files changed, 253 insertions, 0 deletions

diff --git a/documentation/slides-final/slides.md b/documentation/slides-final/slides.md
new file mode 100644
index 0000000..54b1fa8
--- /dev/null
+++ b/documentation/slides-final/slides.md
@@ -0,0 +1,253 @@
+title: STLDoctor
+output: index.html
+controls: false
+
+--
+
+<style>
+
+.footnote {
+	font-size: 16pt;
+	position: absolute;
+	color: gray;
+	bottom: 0px;
+	right: 0px;
+}
+
+.slide-content {
+	position: relative;
+}
+
+.slide-content > ul >li {
+	padding: 7px 0px;
+}
+
+.slide-content > p > img {
+	width: 100%;
+}
+
+</style>
+
+--
+
+<!-- Recap of the service and the problems I
+encountered preparing for the CTF and during the CTF -->
+
+# STLDoctor 💉
+
+--
+
+### Index 🗄️
+
+- Service recap
+- Optimization
+- ENOWARS 5
+- Reflection
+
+--
+
+### Refreshing Memories 💾
+
+- Plaintext service written in C
+- Users upload STL files for parsing
+- Private and public storage (2 flagstores)
+- 1. Vuln: Deserialization
+- 2. Vuln: Hash preimage
+
+<img style="width:300px !important; height:240px; position:absolute; bottom:80px; right:70px;" src="media/stldoc.png">
+
+--
+
+### Since Last Meeting ⏩
+
+<!-- Of these three, we want to take a closer look
+at the performance improvements necessary -->
+
+- Performance improvements
+- Added service fluff
+
+<img id=img1 src="media/stl1.png">
+<img id=img2 src="media/stl2.png">
+<img id=img3 src="media/stl3.png">
+
+<style>
+	#img1 {
+		position: absolute;
+		left: 2.5%;
+		bottom: 7%;
+		width: 30%;
+	}
+	#img2 {
+		position: absolute;
+		left: 35%;
+		bottom: 7%;
+		width: 30%;
+	}
+	#img3 {
+		position: absolute;
+		left: 67.5%;
+		bottom: 7%;
+		width: 30%;
+	}
+</style>
+
+--
+
+### Issues 😒
+
+<!-- since there were some slow io operations and
+either memory leak issues with pwnlib (witout patch)
+or engine request issues with the patch,
+sooo I decided to refactor to use enochecker3 for asyncio
+
+also noticed that I was checking the same thing multiple times
+in the checker, so tried to condense functionality -->
+
+- Slow search / list operations
+- Enochecker memory leak without patch
+- Engine error on worker restart with patch
+- Logs not showing up in ELK
+
+--
+
+### Solutions 💡
+
+- Index files with locks for directory listing
+- Refactored checker for asyncio
+- Condensed checker functionality
+- Increase docker-compose log size
+
+--
+
+# ENOWARS 5
+
+--
+
+### OSError 💢
+
+- Checker throws `INTERNAL_ERROR` on bad connection
+- Fixed in c97789ad.. of enochecker3
+
+<img style="" src="media/stldoc_dead_offline.png">
+
+--
+
+### Checker Overload 💥
+
+<!-- all of a sudden all checker tasks are being aborted.
+Since all tasks were aborted, all workers must be affected
+and a blockage of a single worker could not have been the
+cause.. 
+During the ctf we found the checker at high load..
+Suspected that OFFLINE/unresponsive teams could be slowing
+down the service since then the timeouts are too large and the
+queue couldnt be emptied fast enough -->
+
+- Checker tasks being aborted for every team
+
+<img style="height: 80%" src="media/stldoc_dead_r432.png">
+
+--
+
+### Checker Overload 💥
+
+<!-- MEME CREDIT: Liikt -->
+<img style="height: 80%" src="media/stldoc_dead.png">
+
+--
+
+### Anomaly 👽
+
+<!-- service didnt timeout except on vulnboxes where everything
+seemed to be running weirdly, so unsure how to debug -->
+
+<img style="" src="media/enowars5-timeout.png">
+
+--
+
+### Feedback 🤔
+
+- 1. flagstore exploited after ~4h (R190)
+- 2. flagstore not exploited
+
+<!-- MEME CREDIT: [KuK] cluosh -->
+<img style="position:absolute; right:0px; height:300px; width:450px" src="media/player-meme-struggling.png">
+<img style="position:absolute; left:0px; height:300px; width: 400px;" src="media/player-meme-hashfunc.png">
+
+--
+
+### Conclusion 🎉
+
+- Relatively good uptime
+- Not too easy / hard
+- Users found vulns interesting
+- No (known) unintended vuln
+- Had a lot of fun
+
+--
+
+--
+
+### Slow IO 🐌
+
+<!-- Noticed that running 'ls' on the service upload directory
+takes very long
+implementation in e.g. glibc actually pretty sane (see end slides)
+but bad cache performance / buffer not used / docker overlay fs -->
+
+- Enumerating files in a directory is expensive
+- Index file per directory containing file names
+- File locks to ensure exclusive writes
+
+<img style="position:absolute; bottom: 30%; left:10%; width: 70% !important;" src="media/dirlist.png">
+
+--
+
+### Investigating `readdir(..)` 🔍
+
+<!-- What makes readdir slow? actually looks like a sane implementation.
+We buffer an amount of entries and rebuffer when we run out.
+My guess is that we can buffer more with a regular file (also we have the choice).
+Better cache performance?
+Although the read is from one location, is probably just an abstraction
+Source: GLIBC 2.0.2-->
+
+`__readdir(..)`:
+
+<img style="" src="media/readdir.png">
+
+--
+
+### Investigating `readdir(..)` 🔍
+
+`__get_dir_entries(..)`:
+
+<img style="" src="media/getdirentries.png">
+
+--
+
+### Checker Overload
+
+<img style="" src="media/stldoc_dead_r17.png">
+
+--
+
+### Checker Overload
+
+<img style="" src="media/stldoc_dead_r469.png">
+
+--
+
+
+
+
+
+<script>
+	// var slide_headers = document.querySelectorAll(".slide-content > h3");
+	// for (var i = 0; i < slide_headers.length; i++) {
+	// 	var img = document.createElement('img')
+	// 	img.src = "logo.png";
+	// 	img.style = "height: 2.4ex; padding-right: 10px; float:right";
+	// 	slide_headers[i].append(img);
+	// }
+</script>