Wednesday, September 25, 2019

InCTF 2019 - Golden Den

by Kauê Doretto


The greatest heist in the town is here. Charlie and his gang have managed to enter into this three-way secured gold vault in Bulgaria. But he is pretty confused with the different layers of security attached to it. The entire challenge consists of breaking into the system by securely accessing the information in each vault. At each level, you will get the pieces of information which together opens the secret vault inside. One of the officers provided him with some crucial files to access the first vault.

Difficulty: Medium Author: cr4ck_3t Challenge: Link1 & Link2


The archive packs two files: Final and final.pcap.

File ‘final.pcap’

Open this file in wireshark and you’ll notice that, right in the first packet, there’s an ASCII encoded message. Leaving the first packet selected, in the toolbar select “Analyze -> Follow UDP Stream”. You’ll get the message:

Well great if you found the first part but don't forget the game is not over yet, send me the first part as "subject", then maybe you can get something usefulYou may need this [email protected]

File ‘Final’

Start with the basic reckon:

$ file Final
Final: data

Check the header:

$ xxd Final | head
00000000: 984e 6047 0a00 1a0a 0000 000d 4948 4452  .N`G........IHDR
00000010: 0000 0af0 0000 05dc 0806 0000 00fe ac5b  ...............[
00000020: fc00 0000 0662 4b47 4400 ff00 ff00 ffa0  .....bKGD.......
00000030: bda7 9300 0000 0970 4859 7300 002e 2300  .......pHYs...#.
00000040: 002e 2301 78a5 3f76 0000 0007 7449 4d45  ..#.x.?v....tIME
00000050: 07e3 090f 0f35 1253 a345 6800 0020 0049  .....5.S.Eh.. .I
00000060: 4441 5478 da8c bd5d 92dc 4a93 9ee9 1140  DATx...][email protected]
00000070: 6615 7978 ced7 26c9 a4eb bed3 2674 3163  f.yx..&.....&t1c
00000080: 9a99 bdb4 9936 a49d c8b4 002d a077 d026  .....6.....-.w.&
00000090: d345 8f7a faeb 431e 9255 9940 cc05 e081  [email protected]

The file look a lot like a PNG but with some messed up header bytes. Where you read 984e60470a001a0a should be a valid PNG signature 89504e470d0a1a0a. Also replace the last bytes to fix the IEND chunk:


49 4E 4E 44 AE 42 60 82
I  N  N  D


49 45 4E 44 AE 42 60 82
I  E  N  D

You’ll get the following PNG image:


Notice that the bottom of the image looks incomplete and we’ll take a change by hacking the image’s dimensions bytes to check for something hidden there. The PNG image header is composed of it’s signature followed by a series of chunks. Each chunk consists of an IHDR chunk and an IEND chunk. Like this:

Field >      | Signature         | Lenght    | Chunk Type | Chunk Data                      |
Hex Value>   | 89504e470d0a1a0a  | 0000 000d | 49484452   | 00000af0 000005dc 0806 0000 00  |
ASCII Value> | . P N G . . . .   |           | I H D R    |                                 |
Dec Value>   |                   |        13 |            |     2800     1500               |

As we’ll be changing the dimensions just ignore the other fields. The 2800 and 1500 are respectively the image’s width and height in pixels, so we’ll give a shot in the dark and replace the 05dc bytes for 0af0 to get a square image. If you try to open the resulting image an error we’ll be thrown because there’s an annoying little thing called CRC (Cyclic Redundancy Check), created to guarantee the image’s integrity in case someone ( ahem ) messes up with the header’s data. If we want to see the image with the new dimensions we must recalculate the CRC32 field.

Extract the fields involved in the calculation:

$ dd bs=1 skip=12 count=17 if=Final.png of=chunk_data
17+0 records in
17+0 records out
17 bytes copied, 0,00106953 s, 15,9 kB/s

$ xxd chunk_data 
00000000: 4948 4452 0000 0af0 0000 0af0 0806 0000  IHDR............
00000010: 00                                       .

$ crc32 chunk_data 

Replace the bytes from ‘0x1D’ to 0x20’ with the last command’s output. Now it’s possible to open the image and get the first part of the flag:


inctf{GoLd_g0LD_eV3Ry. Following the directions in the previously found message, an e-mail was sent to [email protected] with the partial flag in the subject. We got the following reply:

Hey Player,

Congrats on completing level 1, but remember it's just a beginning you still have 2 remaining, Here is a gift for breaking vault 1 : 

Help me break in!!!!!!!!!!! 

The provided URL pointed to an archive named with 3 files: map_for_th3_final_clu3.txt, stranger1.jpg and stranger2.jpg

Files ‘strange1.jpg’ and ‘strange2.jpg’

This needed some guessing but you’ll have the desired result diffing the two images:

compare -compose src strange1.jpg strange2.jpg strange.png


And another piece of the flag: Wh3r3_G0lD_U

File ‘map_for_th3_final_clu3.txt’

The file had the braille code ⠓⠞⠞⠏⠎:⠌⠌⠞⠊⠝⠽⠥⠗⠇⠲⠉⠕⠍⠌⠽⠼⠃⠍⠼⠙⠎⠏⠧⠇

that translated to, a Google Drive archive named with files 1.reg, 2.reg and 3.reg

Files ‘*.reg’

The first thing you’ll notice about there files is that it’s impossible to grep them. The reason is that they are not plaintext files:

$ file *.reg
1.reg: Windows Registry little-endian text (Win2K or above)
2.reg: Windows Registry little-endian text (Win2K or above)
3.reg: Windows Registry little-endian text (Win2K or above)

So, we convert them to unix format using dos2unix utility:

$ dos2unix -ascii -n 1.reg 1.txt
$ dos2unix -ascii -n 2.reg 2.txt
$ dos2unix -ascii -n 3.reg 3.txt

$ file *.txt
1.txt: ASCII text
2.txt: ASCII text
3.txt: ASCII text

After some random reckon we decided to remove all the keys and leave just it’s values, when present. Suddenly we noticed something like this:


Being suspectful of the “FuncID” field, we filtered it:

$ grep -Pi "FuncID\"=\"[0-9]" *.txt | cut -d "\"" -f4

And finally converted the ASCII byte representations to a binary file:

$ grep -Pi "FuncID\"=\"[0-9]" *.txt | cut -d "\"" -f4 | tr -d '\n' | xxd -r -p!6k0XGYYQ!Gc2kVlLnLHlS4TXuCsa60b-iomRgjoVRnaIMo6vns9Q`


Putting it all together: inctf{GoLd_g0LD_eV3RyWh3r3_G0lD_UG0t_7He_g0ld3n_7r3a$uRE}

Capture the Flag , Forensics , Writeup