]> git.somenet.org - pub/jan/ctf-seminar.git/blob - writeups/them/seccon19.md
chgue add more writeups
[pub/jan/ctf-seminar.git] / writeups / them / seccon19.md
1 # SECCON 2019 
2
3 ## The CTF in retrospective
4
5 I started playing this CTF after my two colleagues @someone and @astra informed me of the course, so i joined a little late (this is also the reason why i was not in the corresponding mattermost channel at that time). I spent around 12 hours playing this CTF, some more after plus some more for this writeup. Since i usually don't swap challenges a lot when playing CTF, the write-up is rather short in number (1 challenge only) but i attempted to make our train-of-thought very clear to at least provide a good documentation to what we did.
6
7 ## Challenges
8
9 ### Unsolved
10
11 #### for-repair
12
13 I worked at this challenge together with @astra and @someone from mattermost, sitting in a room next to each other.
14
15 The challenge was as follows:
16
17 ```
18   This file lost one sector. Please repair it.
19   960x540
20 ```
21
22 The download link gave us a ~2.7MB file that should be repaired. We started analysing it.
23
24  * `file` did not recognize it as something special, just "data".
25  * `binwalk` found some MYSQL compressed data file and some LZMA compressed data, but both seemed rather unlikely at that time.
26  * `strings` had some very interesting results: 
27   `JUNK LIST INFOISFT Lavf58.28.100 JUNK LIST movi00dc 00dc`
28   Especially the String `00dc` was interesting since it had more than 500 occurrences.
29   * `hexdump -C <file> | less -n 100` resulted in something that looks like some kind of header and then a repeating patteren revolving around the `00dc` we already have seen.
30
31 A google search for some of the keywords such as "JUNK LIST INFOISFT" and "00dc" gave a lot of hints towards an avi video file. This also matches up well with the file name `960x540` which seems to indicate a image/video resolution. 
32
33 At this point i attempted multiple video players to just run the file, including `mplayer vlc mpv`, but without success. Either nothing happened at all or unknown errors were reported. Especially interesting at this point is that no tool was able to recognize the file format. 
34
35 We searched online for several avi repair tools that could either repair it or atleast give us more information on what is broken exactly, but none really helped.
36
37 Since the challenge description says "lost one sector", it became quite likely that the file is missing header information and the repeating pattern noticed probably are frames of a video. This would mean if we would know what file format exactly it is, we might be able to read or recreate missing header information.
38
39 An attempt to fix the file was made by prefixing the file with 512 bytes (because 512 is the traditional size of a `sector`) of zeros. It was hoped that this might help various previously listed tools to recognize the file better. We did this using `dd if=/dev/zero of=./zerosector bs=1 count=512 && cat zerosector 960x540.avi > 960x540.mod.avi`.
40
41 Since the header probably has important information about the format of file contents, we attempted to convert the video using `ffmpeg -c:v <codec> -i "960x540.mod.avi" -c:v copy "recovery.avi"` with various different codecs we obtained `ffmpeg -codecs`. The idea was, if we specify the correct input codec to read, `ffmpeg` might just have enough information to copy and create a good video file as output. Some codecs produced an output, some just didn't work. Those that delivered output we attempted to play and see if it worked. But it didn't, mostly black and/or noise.
42
43 Next, we tried finding a reference video with the same resolution (960x540), so we could compare the file format and/or reuse [parts of] the header if possible. We found such a file [here][reference_video]. A side by side comparison of the hexdumps showed that only the information in the beginning seems missing, due to the position of the string "vprpD" which can be found at the exact same position in reference video line `0x000010f0` matching our file line `0x00000ef0`. Also, the reference file showed the same structure (keywords mentioned above) as our file, validating our believes in a video file.
44
45 We now tried to copy over the first 512 bytes (`0x000010f0 - 0x00000ef0 = 0x200 = 512 = traditional sector size`) from our reference video over to ours using `dd if=./reference.avi of=./960x540.mod.avi bs=1 count=512 conv=notrunc`, which allowed a little better results when attempting to play back the video with various media players. VLC now detected a runtime of 0:15 for this video (which is different from the 0:34 of the reference video, otherwise that would indicate that we just copied an encoded length field as well instead of using the one corresponding to our video).
46
47 We started spending a lot of time researching what the header actually contains and how we could find and reconstruct the missing information. We had some ideas, mostly revolving around writting our own decoder to extract frames. This is the point were the CTF ended, sadly, because at this point we were only one command aways from the solution :/ The rest below I found out after the end of the CTF.
48
49 If we had tried to convert the last file again using ffmpeg we would have had the result. `ffmpeg -c:v cinepak -i "960x540.mod.avi" -c:v copy "recovery.avi"`. (The codec parameter could have been found again using bruteforce trying every possible codec from `ffmpeg -codecs`) The result would have been a 10 second  video that is mostly black and shows three texts for a short while, one of which would have been the flag: `SECCON{FORENSICS_MOVIE_SECCON2019_TKTK}`.
50
51 It is also interesting to see that other teams according to their write-ups wrote some decoders using the ffmpeg api from python ([see here][wup1]) or attempted to do it in C ([see here][wup2]) manually, which we might also have attempted if the CTF would not have ended. 
52
53 The following script can produce a solution from the original input file using what we discoverd during and after the CTF:
54 ```
55 #!/bin/bash
56   INPUTFILE=./960x540.avi
57   REFERENCEFILE=./960x540.reference.avi
58   WORKFILE=./960x540.mod.avi
59   RESULTFILE=./recovery.avi
60
61   #generate missing sector of zeros
62   dd if=/dev/zero of=./zerosector bs=1 count=512
63
64   #prepend missing sector to file
65   cat zerosector $INPUTFILE > $WORKFILE
66
67   #overwrite first sector from reference file
68   if [ ! -e $REFERENCEFILE ]; then
69     wget "https://www.fm91.com.pk/wp-content/uploads/2017/08/960x540-AVI-MPEG-11.avi" -O $REFERENCEFILE
70   fi
71   dd if=$REFERENCEFILE of=$WORKFILE bs=1 count=512 conv=notrunc
72
73   #convert as means of repair using ffmpeg
74   ffmpeg -c:v cinepak -i $WORKFILE -c:v copy $RESULTFILE
75 ```
76
77 #### References:
78
79 [Reference Video][reference_video]  
80 [Write Up using Python and ffmpeg API][wup1]  
81 [GitHub Gist][wup2]  
82
83 [reference_video]: https://www.fm91.com.pk/wp-content/uploads/2017/08/960x540-AVI-MPEG-11.avi
84 [wup1]: https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=http%3A%2F%2Fblog.bonprosoft.com%2F1685
85 [wup2]: https://gist.github.com/hikalium/7567d487d32af63ec0f4bc68e5a354cb