Shark Fail – CTF challenge GP August ’21

Taking a look on the challenges in the "Misc" category, they all seems interesting. But not giving a clear road to catch on. The last challenge in the category "Shark Fail" seems to have something to do with .pcap-files. Lets start there.

Running file on the downloaded .pcapng-file, tells us that the file really is a PCAP file that we could investigate with tools like Wireskark or its terminal equivalent tshark:

sharkfail.pcapng: pcapng capture file - version 1.0

Firstly I took a short look on the first few packets with tshark -r sharkfail.pcapng | head:

    1   0.000000         host → 1.6.0        USB 64 GET DESCRIPTOR Request DEVICE
    2   0.000864         host → 4.2.0        USB 64 GET DESCRIPTOR Request DEVICE
    3   0.000174        1.6.0 → host         USB 82 GET DESCRIPTOR Response DEVICE
    4   0.000211         host → 1.1.0        USB 64 GET DESCRIPTOR Request DEVICE
    5   0.000999        4.2.0 → host         USB 82 GET DESCRIPTOR Response DEVICE
    6   0.000217        1.1.0 → host         USB 82 GET DESCRIPTOR Response DEVICE
    7   0.001035         host → 4.1.0        USB 64 GET DESCRIPTOR Request DEVICE
    8   0.001040        4.1.0 → host         USB 82 GET DESCRIPTOR Response DEVICE
    9   0.000337         host → 2.1.0        USB 64 GET DESCRIPTOR Request DEVICE
   10   0.000392         host → 3.4.0        USB 64 GET DESCRIPTOR Request DEVICE

Nothing overly interesting - except for the fact that this might be an USB-capture. I have used Wireshark to analyse TCP/IP and so forth, so looking into a USB-protocol capture should be interesting - there is a first for everything.
Opening the file in Wireshark shows an error, telling us something is wrong with the file.

It seems the file opens fine and both packet-count in the bottom-right and the file statistics (Statistics --> Capture File Properties) doesn't seem to give any leads on what might be wrong. Let's write that on a piece of paper to investigate later, should we need to follow up on that.

After some short manual enumeration on the packages the capture withholds, we see that the file clearly is for USB and primarily a storage-device by the product-ID "Kingston DataTraveler 2.0 Stick". No obvious packets or interesting information is lighting up upon first glans. With a possible full-scale USB-packet capture forensics at hand (and the required deep-dive into the USB-protocol specifications), I chosed to close the file and enumerate a bit directly on the file to see if any obvious signs on why the file reported as damaged or corrupted by Wireshark.

Running head and tail didn't alert me with any interesting details, so the next thing I tried was good old strings.
While it didn't gave the flag at first sight, between all the non-interesting strings, there was a long (much longer than all other stings) string that looked kind of odd in there.

[...]
USBSH
USBCI
USBSI
USBCJ
USBSJ
USBCK
U3Rvcm1DVEZ7TWlzYzI6NzZlRjEyNDE2Mzc2M0IzNTJCOTg4Y0JBMWU3NzVBOEF9
USBSK
USBCL
DALI       
OR1        
TRASHE~1   
OR1        
[...]

A quick run through the base64 decoder:

import base64
print(base64.b64decode('U3Rvcm1DVEZ7TWlzYzI6NzZlRjEyNDE2Mzc2M0IzNTJCOTg4Y0JBMWU3NzVBOEF9'))

And we indeed have a flag StormCTF{Misc2:76eF124163763B352B988cBA1e775A8A} - off to the scoreboard and earn the 400-points for the GuidePoint CTF August 2021. Yay - this is indeed a fun way to learn, expand and acquire new knowledge, something important in Cyber Security and fun for the mind.