commit 66aad836f9e7dd5de4bdbf012c388e221614da5c
parent 88f4ea4c85a4224515ba1146b8058bce9e2a1994
Author: Louis Burda <quent.burda@gmail.com>
Date: Fri, 5 Apr 2024 20:15:45 +0200
Add description and notes
Diffstat:
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/chall/description b/chall/description
@@ -0,0 +1,7 @@
+This is an introductory challenge for exploiting Linux binaries with memory corruptions. Nowadays there are quite a few mitigations that make it not as straight forward as it used to be. So in order to introduce players to pwnable challenges, LiveOverflow created a video walkthrough of the first challenge.
+
+This challenge was already featured in last year's CSCG. We are aware that public writeups exist, but we figured this challenge is still a nice-to-have for newcomers, so we released it again.
+
+Note: The video writeup of LiveOverflow is not completely functional. To give you hint: It's about the address of the ret instruction that was chosen to re-align the stack. Suppose ASLR is rather 'smooth' - meaning a whole bunch of nibbles are zero - (which is pretty much always the case in our setup) all addresses within the offset range of 0xa00 to 0xaff translate to addresses looking like xxxxxxxxxx0axx, requiring you to send the bytes xx xx xx xx xx xx 0a xx over the wire. Now the problem with this is that 0a is a newline (\\n), which in turn terminates gets() (refer to man 3 gets), meaning that your payload terminates prematurely.
+
+https://www.youtube.com/watch?v=hhu7vhmuISY
diff --git a/solve/notes b/solve/notes
@@ -0,0 +1,10 @@
+We can use format string exploit to leak values from the stack.
+
+This reveals the base address..
+
+We can look up the function offset from the base address
+by inspecting where the function lies within the code segment.
+
+objdump -d | grep WIN
+
+gives 0x9ec
