]> git.somenet.org - pub/jan/ctf-seminar.git/blob - writeups/kernelpanic/seccon19.md
Update writeups/Ch4s3r/36c3.md, writeups/Ch4s3r/36c3/game.png, writeups/Ch4s3r/36c3...
[pub/jan/ctf-seminar.git] / writeups / kernelpanic / seccon19.md
1 # Retrospective
2
3 Since Seccon was only the second CTF I participated in, I browsed for challenges which,
4 if I didn't manage to solve them (which would be quite likely), would at least teach me
5 something new and concrete that I could use in further CTFs, e.g. some tool that comes up
6 quite often, that I hadn't used yet. Since I did some reversing for my Bachelor's thesis,
7 I headed for the reversing challenges and ended up spending most of my time trying to
8 teach myself how to use angr. When I got too angry, I took a look at other challenges.
9 All in all, I'm happy that I could spend some time working with angr, but looking at the
10 writeups from other teams, my overall approach was likely flawed and I should've looked
11 for alternative approaches earlier instead of committing from the beginning and spending
12 hours on that approach.
13
14 # Attempted Challenges
15
16 I spent most of my time on reversing-follow-me. We were given a simple binary containing
17 a stack based calculator and a stack trace of an execution. The goal was to get an input 
18 to the binary, which would produce the same execution trace. My idea was to leverage angr's
19 symbolic execution engine to get a range of possible inputs which could then be used to
20 somehow recover the original input or at least drastically reduce the possibilities.
21 Unfortunately I didn't get angr to comply with my wishes and I ended up debugging my python
22 code and browsing the angr documentation for about 6 hours without any tangible results.
23
24 I also took a quick look at the crypto challenges zkpay and crazy repetition of codes. In 
25 the former, we were given a web application for issuing payments between different user
26 accounts. The goal was to achieve a balance of 1,000,000$. Performing a payment would
27 generate a QR code which could then be uploaded to receive the payment. It contained the
28 user's name, a hash associated with that user name (i.e. some kind of wallet ID) and a proof
29 of some form. I noticed that the QR code could be replayed by simply uploading it for a
30 second time, but didn't manage to test it as the challenge server was under heavy load at
31 the time and simply switching from balance overview to transactions took ages or resulted
32 in timeouts. Looking at the writeups from other teams, it seems like there was a bug in the
33 challenge itself and instead of doing something with the (zk - zero knowledge) proof, a
34 negative amount in a transaction was enough to circumvent some checks, as the system only
35 expected positive values.
36
37 Crazy repetition of codes was a python script which performed CRC32, an error-detecting code
38 on blocks of null bytes to generate a key for AES in ECB mode which was used to encrypt the
39 flag. The script also contained the corresponding cipher text. The CRC operations were
40 performed in loops with `int("1" * 10000)` iterations, which obviously precludes us from
41 simply executing the script. I tried to find a cycle in the execution by simply looking for
42 values occurring twice in the crc32 function. I didn't find any after letting my script run
43 for some time, so I gave up and started to look into the cipher text itself, thinking that I
44 could maybe exploit a weakness in ECB encryption by looking for repeating cipher text blocks
45 or similar - unsuccessfully.