Initial analysis of the pcap (challenge.pcap, sha256: 97e4a17068ce3ed01ed1c25c3d263fc0145e5ecc53b7db6f2ba84496b53d4a65) shows a number of DNS requests and responses.

Further inspection of the DNS queries shows additional data within the request:

I examined the entire UDP stream to see the conversation in its entirety and observed this “additional” data is present in each of the DNS lookups:

Pulling the data out that appears in each query yields the following block:


UEsDBBQAAAAIAOCIr0qMVwGeKQAAACoA

AAAIABwAZmlsZS5kYXRVVAkAA3QYGlmB

GBpZdXgLAAEE6AMAAAToAwAAC3D0q3bM

yQnIz8wrSS0q9sxz8QsOzsgvzUkBCzkl

JmeXJxalFNdyAQBQSwECHgMUAAAACADg

iK9KjFcBnikAAAAqAAAACAAYAAAAAAAB

7AAAAtIEAAAAAZmlsZS5kYXRVVAUAA3QY

Gll1eAsAAQToAwAABOgDAABQSwUGAAAA

AAEAAQBOAAAAawAAAAAA

Remove the newlines to create a single string and we get:


UEsDBBQAAAAIAOCIr0qMVwGeKQAAACoAAAAIABwAZmlsZS5kYXRVVAkAA3QYGlmBGBpZdXgLAAEE6AMAAAToAwAAC3D0q3bMyQnIz8wrSS0q9sxz8QsOzsgvzUkBCzklJmeXJxalFNdyAQBQSwECHgMUAAAACADgiK9KjFcBnikAAAAqAAAACAAYAAAAAAAB7AAAAtIEAAAAAZmlsZS5kYXRVVAUAA3QYGll1eAsAAQToAwAABOgDAABQSwUGAAAAAAEAAQBOAAAAawAAAAAA

This looks like base64, so lets take a look:


cat base64_output | base64 -D -o output.bin

hexdump -C output.bin

00000000 50 4b 03 04 14 00 00 00 08 00 e0 88 af 4a 8c 57
|PK...........J.W|

00000010 01 9e 29 00 00 00 2a 00 00 00 08 00 1c 00 66 69
|..)...*.......fi|

00000020 6c 65 2e 64 61 74 55 54 09 00 03 74 18 1a 59 81
|le.datUT...t..Y.|

00000030 18 1a 59 75 78 0b 00 01 04 e8 03 00 00 04 e8 03
|..Yux...........|

00000040 00 00 0b 70 f4 ab 76 cc c9 09 c8 cf cc 2b 49 2d
|...p..v......+I-|

00000050 2a f6 cc 73 f1 0b 0e ce c8 2f cd 49 01 0b 39 25
|*..s...../.I..9%|

00000060 26 67 97 27 16 a5 14 d7 72 01 00 50 4b 01 02 1e
|&g.'....r..PK...|

00000070 03 14 00 00 00 08 00 e0 88 af 4a 8c 57 01 9e 29
|..........J.W..)|

00000080 00 00 00 2a 00 00 00 08 00 18 00 00 00 00 00 01
|...*............|

00000090 ec 00 00 02 d2 04 00 00 00 01 99 a5 b1 94 b9 91
|................|

000000a0 85 d1 55 50 14 00 0d d0 60 69 65 d5 e0 2c 00 04
|..UP....`ie..,..|

000000b0 13 a0 0c 00 00 13 a0 0c 00 01 41 2c 14 18 00 00
|..........A,....|

000000c0 00 00 04 00 04 01 38 00 00 01 ac 00 00 00 00 |......8........|

000000cf

It looks like the base64 is actually a zip file, the upiquitous “file” utility concurs.


file output.bin

output.bin: Zip archive data, at least v2.0 to extract

Lets go ahead the contents of the archive.


zip output.bin

zip warning: missing end signature--probably not a zip file (did you

zip warning: remember to use binary mode when you transferred it?)

zip warning: (if you are trying to read a damaged archive try -F)

zip error: Zip file structure invalid (output.bin)

Well, that seems to be a problem, helpfully, the zip1 utility has tools to fix the lack of a footer.


zip -FF output.bin --out rebuilt.zip

Fix archive (-FF) - salvage what can

zip warning: Missing end (EOCDR) signature - either this archive

is not readable or the end is damaged

Is this a single-disk archive? (y/n): y

Assuming single-disk archive

Scanning for entries...

copying: file.dat (41 bytes)

Central Directory found...

no local entry: [truncated]

Here we go again, with a fixed archive.


unzip rebuilt.zip

inflating: file.dat

And finally lets see whats in file.dat


cat file.dat

PAN{AllPointersInDNSShouldPointBackwards}

Its the flag! PAN{AllPointersInDNSShouldPointBackwards}

  1. 7z doesn’t care about this error and extracts file.dat with no problems, though it does complain the entire time.