From 90ba525d3cf6cc963d466962812c0697fc1db9ae Mon Sep 17 00:00:00 2001 From: Michael Strasser Date: Wed, 23 Oct 2019 08:59:58 +0000 Subject: [PATCH] Upload New File --- writeups/kernelpanic/writeup.md | 45 +++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 writeups/kernelpanic/writeup.md diff --git a/writeups/kernelpanic/writeup.md b/writeups/kernelpanic/writeup.md new file mode 100644 index 0000000..679b81e --- /dev/null +++ b/writeups/kernelpanic/writeup.md @@ -0,0 +1,45 @@ +# Retrospective + +Since Seccon was only the second CTF I participated in, I browsed for challenges which, +if I didn't manage to solve them (which would be quite likely), would at least teach me +something new and concrete that I could use in further CTFs, e.g. some tool that comes up +quite often, that I hadn't used yet. Since I did some reversing for my Bachelor's thesis, +I headed for the reversing challenges and ended up spending most of my time trying to +teach myself how to use angr. When I got too angry, I took a look at other challenges. +All in all, I'm happy that I could spend some time working with angr, but looking at the +writeups from other teams, my overall approach was likely flawed and I should've looked +for alternative approaches earlier instead of committing from the beginning and spending +hours on that approach. + +# Attempted Challenges + +I spent most of my time on reversing-follow-me. We were given a simple binary containing +a stack based calculator and a stack trace of an execution. The goal was to get an input +to the binary, which would produce the same execution trace. My idea was to leverage angr's +symbolic execution engine to get a range of possible inputs which could then be used to +somehow recover the original input or at least drastically reduce the possibilities. +Unfortunately I didn't get angr to comply with my wishes and I ended up debugging my python +code and browsing the angr documentation for about 6 hours without any tangible results. + +I also took a quick look at the crypto challenges zkpay and crazy repetition of codes. In +the former, we were given a web application for issuing payments between different user +accounts. The goal was to achieve a balance of 1,000,000$. Performing a payment would +generate a QR code which could then be uploaded to receive the payment. It contained the +user's name, a hash associated with that user name (i.e. some kind of wallet ID) and a proof +of some form. I noticed that the QR code could be replayed by simply uploading it for a +second time, but didn't manage to test it as the challenge server was under heavy load at +the time and simply switching from balance overview to transactions took ages or resulted +in timeouts. Looking at the writeups from other teams, it seems like there was a bug in the +challenge itself and instead of doing something with the (zk - zero knowledge) proof, a +negative amount in a transaction was enough to circumvent some checks, as the system only +expected positive values. + +Crazy repetition of codes was a python script which performed CRC32, an error-detecting code +on blocks of null bytes to generate a key for AES in ECB mode which was used to encrypt the +flag. The script also contained the corresponding cipher text. The CRC operations were +performed in loops with `int("1" * 10000)` iterations, which obviously precludes us from +simply executing the script. I tried to find a cycle in the execution by simply looking for +values occurring twice in the crc32 function. I didn't find any after letting my script run +for some time, so I gave up and started to look into the cipher text itself, thinking that I +could maybe exploit a weakness in ECB encryption by looking for repeating cipher text blocks +or similar - unsuccessfully. -- 2.43.0