Category: Forensics Points: 50 Solves: Description:
Is kill can fix? Sign the autopsy file?
In this challenge we get a file named "kill.pcapng". However, running wireshark on will not open it:
The file "kill.orig.pcapng" isn't a capture file in a format Wireshark understands.
Running strings on it we find evidence that it indeed is a pcap of some sort, such as "Counters provided by dumpcap". The file command returns the file as being identified as "data", which is the generic response when file doesn't know what to make of it.
If nothing else, this points to a problem with the magic bytes of the file. There are different ways of looking up the proper magic bytes for this. However, we happen to have a program that checks for the values, might as well use their own definitions. Since most magic files will be in compiled form on the local host, we should look at the source. Going down to pcapng, we see:
# "pcap-ng" capture files.
# http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html
# Pcap-ng files can contain multiple sections. Printing the endianness,
# snaplen, or other information from the first SHB may be misleading.
#
0 ubelong 0x0a0d0d0a
>8 ubelong 0x1a2b3c4d pcap-ng capture file
>>12 beshort x - version %d
>>14 beshort x \b.%d
0 ulelong 0x0a0d0d0a
>8 ulelong 0x1a2b3c4d pcap-ng capture file
>>12 leshort x - version %d
>>14 leshort x \b.%d
We can go ahead and read this top down. What this is saying is that starting at offset 0, we should see the value 0x0a0d0d0a. Note that while this is a palindrome, it's important to understand the endianness of your architecture. Most cases will be endian, meaning you basically reverse the byte oder that you read (least significant byte first). Opening the pcap up in radare2 (r2 kill.pcapng; V):
[0x00000000 0% 1056 kill.pcapng]> x
- offset - 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF
0x00000000 aadd ddaa 8c00 0000 4d3c 2b1a 0100 0000 ........M<+.....
0x00000010 ffff ffff ffff ffff 0300 2f00 4d61 6320 ........../.Mac
0x00000020 4f53 2058 2031 302e 3131 2e36 2c20 6275 OS X 10.11.6, bu
0x00000030 696c 6420 3135 4731 3030 3420 2844 6172 ild 15G1004 (Dar
0x00000040 7769 6e20 3135 2e36 2e30 2900 0400 3400 win 15.6.0)...4.
0x00000050 4475 6d70 6361 7020 312e 3132 2e34 2028 Dumpcap 1.12.4 (
0x00000060 7631 2e31 322e 342d 302d 6762 3438 3631 v1.12.4-0-gb4861
0x00000070 6461 2066 726f 6d20 6d61 7374 6572 2d31 da from master-1
0x00000080 2e31 3229 0000 0000 8c00 0000 0100 0000 .12)............
0x00000090 6000 0000 0100 0000 0000 0400 0200 0600 `...............
Looking at the first bytes, they certainly don't match the magic bytes they're supposed to. Looks like the chars got duplicated (aa instead of 0a). We can replace that very easily in r2. Simply change r2 into write mode (oo+), tab once so that you're in the hex area, then type in your change. Radare2 automatically saves, so just exit. Now, load the file up in wireshark:
$ file kill.pcapng
kill.pcapng: pcap-ng capture file - version 1.0
franklin@Pluto:~/CSAW/forensics/kill$ wireshark kill.pcapng
If we follow the main stream, we can see this is an FTP session. One interesting thing about FTP is that it transfers data over a separate port (port 20). We can find the transfer by first finding the frame where the control command happens. For instance, "STOR sad.jpg", we would add the following as a filter "frame contains sad.jpg". We can see the command is in frame 55. Now, remove the filter and scroll down to the FTP-Data transfer below it. Follow that stream (right click -> follow -> tcp stream) then save it (save as button).
After extracting all the images, I attempted to open them and discovered I couldn't open one (girls.jpg). Performing a strings on that file yielded the flag.
flag{roses_r_blue_violets_r_r3d_mayb3_harambae_is_not_kill}