writeups/fkehrer/seccon19.md

   1 # SECCON 2019 Online CTF
   2
   3 I could not work on this CTF the whole 24 hours due to other obligations and a need to sleep, so there is a lot of unfinished business here, but at least some success was achieved.
   4
   5 ## Beeeeeeeeeer
   6
   7 This is an obfuscated bash script. It's hard to read and hard to run (although it could have been even worse).
   8
   9 Among the difficulties in working with this script are such elements as:
  10 + no formatting, the whole script is on one line
  11 + most commands are not written as words but a combination of character codes and strings run through utilities like base64, rev and tr. For example: ```$'\145\170\160\157\162\164' $'\u0053\u0031'=$(echo aG9nZWZ1Z2EK |base64 -d);```
  12 + random delays
  13 + checks for environment variables
  14 + many ways of ending the script prematurely
  15 + useless sections of code
  16 + zipped code
  17 + encrypted code
  18 + code which consists of anything but letters or numbers
  19 + simple anti-debugging (checks for -x flag)
  20
  21 All of these problems could be worked around, with a combination of bash debugging, patching the script where needed, extracting the zipped/encrypted parts and running them separately.
  22
  23 In the last lines of the encrypted block, we find the command ```echo SECCON{$S1$n$_____};```. All 3 variables can be easily found out. $S1 is set early in the script and just needs to be printed out (*hogefuga*), $n is set by the user just before the innermost block is decrypted (*3*), and $_____ is also set by the user in the innermost block (*bash*), as it's the password required there.
  24
  25 This gives us the flag: ```SECCON{hogefuga3bash}```
  26
  27 ## Sandstorm
  28
  29 A picture with some text above seemingly random black and white noise.
  30
  31 This reminded me a lot of other challenges with black and white noise in pictures, in which additional information like text or QR codes is revealed when the picture is shifted and XORed with itself. After trying it for a few minutes though, nothing popped up, except the sudden realization that the name almost certainly refers to the noise, which, when looked at through something like StegSolve and shifted rapidly, looks as chaotic as a sandstorm.
  32
  33 As other people investigated the file itself and did not seem to progress either, I continued with another challenge.
  34
  35 ## Sum
  36
  37 The program takes a handful of numbers via stdin and prints their sum.
  38 This was the last challenge I had a look at before having to leave.
  39
  40 When using the binary it quickly becomes apparent that the reading in of the numbers is handled very poorly. As soon as a sixth number is provided, the program crashes with a segfault. Investigating this crash unveils that the program gives the sixth number to the sum function as the second argument (probably by accidentally overwriting the address of a legit variable), which is then used as an address to write a 0 to, at address **0x0040077a**. Since I supplied it with small integers, those addresses were far outside any mapped memory of the program, and it produced a SegFault.
  41
  42 ![you should see a picture here. if you don't, fear not, it's only illustrating what is described in the text](seccon19/sum.png)
  43
  44 This means that we can override a memory location of our choice with 0 (which I tried and it worked). However, that alone does not an exploit make. It also means that we can overwrite whichever value lies after the number array in memory. Since the libc binary is distributed with the challenge binary, this probably enables a ret2libc or libc-rop attack, but at this point I had to leave, and when I returned to the challenge the next day, no progress had been made and I didn't make any either.
  45
  46 ## follow-me
  47
  48 Three things are given: A binary, a trace of said binary's execution, and the source file of the tracer. To receive the flag, one would have to find an input which would lead to the same trace being produced.
  49
  50 The first thing I did, which took a while, was to figure out how to build the tracer, which took a while. It's based upon Intel's PIN, a tool for binary instrumentation. (instructions are in the challenge channel)
  51 The second thing was to find out what the binary actually does. The first few inputs I gave it gave errors saying that "the stack" was empty or that "the formula" was invalid. Soon after I had figured out that the binary takes mathematical formulas in the form of a stack, meaning things like "1,1,+" to write 1+1 or "1,2,+,3,\*,4,-" to get (((1+2)\*3)-4), which Someone (the person) suggested to be Reverse Polish Notation. I also noticed that whatever the binary was doing, doing it with the tracer meant it ran extremely slow. Any operation with bigger numbers or a handful of operators took literal seconds. This unfortunately meant that just generating formulas, trying them out with the tracer and then making another, hopefully better guess did not seem like a feasible strategy.
  52
  53 Aaand that was about as far as I got with that challenge :)