Rip Art

Description: I can't believe I forgot to save my art!

Given: rip-art.tar.gz

Author: skat

We’ve been given a pcapng file, just as a heads up, the difference between a pcap and a pcapng (PCAP Next Generation) is more extensible and portable than PCAP and has a more flexible file structure. The first things first, let’s open it up in Wireshark. Looking at the protocol hierarchy, we can see that it’s completely USB protocol.

image.png

At first, let’s do some reconnaissance with both Wireshark and tshark[CLI alternative].

https://youtu.be/-KLEDJjXjrM?si=B8MkHhcRM90Sihkx

Reconnaissance

Here I check for the different lengths involved in the USB capture.

└─$ tshark -r art.pcapng -T fields -e frame.len | sort -n | uniq -c
  27335 64
   6333 71
   3684 72
  10986 74
   6332 722

To understand the reasoning behind this is, we need to understand about HID [Human Interface Device], it’s a type of computer device usually used by humans that takes input from or provides output to humans.

In case of the mouse data is captured, it’s transferred in HID with about 4 bytes [32 bits]. The first byte represents buttons pressed. 0x00 is no buttons pressed, 0x01 indicates left button pressed, and 0x02 indicates right button pressed. The second byte is a signed byte, where the highest bit is the sign bit. When positive, it represents how many pixels the mouse has moved horizontally to the right. When negative, it shows how many pixels it has moved horizontally to the left. The third byte, like the second byte, represents an offset that moves vertically up and down.

Now in case of keyboard data, it’s about 8 bytes [64 bits], and the keystrokes occur at the 3rd bytes, enough of the rant, let’s get back on topic. Now that we have all the lengths in the file, we can analyze them one by one.

As for the 64 length packets, which account for more than half of the packets, we encounter URB_INTERRUPT IN and URB_BULK OUT but the absence of HID-specific data and the Data length [bytes]: 0 suggests it is a control packet or placeholder with no actual payload being transferred.

Next up, let’s take the 722 length packets, in contrast to the 64 length packets, we see a huge size of payload being transferred, but we also notice it’s been padded heavily. let’s compare two of packets of same length to try and check out what type of payload in being transferred.

image.png

Used an online tool to do the job. Turns out only 3 bytes from the same indices keep changing and the others act like a padding around them.

image.png

Diffchecker - Compare text online to find the difference between two text files