We are given a Windows application and a .pcapng packet capture. Running the
application under wine produces a warning about unimplemented MIDI
functionality, after which the application exits. A quick look with IDA reveals
that the application insists on talking to a cool DDJ-XP1 DJ pad, which is
split in two 16-button halves. .pcapng contains a bunch of USB packets flying
in both directions, which must be key presses.
Dumping it with pyshark reveals the following repeating pattern:
1.7.4 -> host: 09:97:04:7f
host -> 1.7.4:
1.7.4 -> host: 09:97:04:00
host -> 1.7.4:
1.7.4 -> host: 09:99:08:7f
host -> 1.7.4:
1.7.4 -> host: 09:99:08:00
host -> 1.7.4:
1.7.4 -> host messages look like ACKs, let's get rid of them:
1.7.4 -> host: 09:97:04:7f
1.7.4 -> host: 09:97:04:00
1.7.4 -> host: 09:99:08:7f
1.7.4 -> host: 09:99:08:00
The messages ending with :00 must be key releases, which leaves us with:
1.7.4 -> host: 09:97:04:7f
1.7.4 -> host: 09:99:08:7f
The pattern always alternates between 97 and 99, which most likely means
that DJ was pressing first the button on the left half, and then the button
on the right half. 04 and 08 must be button codes.
Frequency analysis (1-grams, 2-grams) does not produce any results, but the message is fairly short, so it's probably okay. Key press durations are all over the place, so this can't be Morse code.
One could notice though that 0x04 and 0x08 can be concatenated to 0x48, which is the ASCII code for the letter 'H'. This way the entire message can be deciphered:
Hey guys! FLAG is SECCON{3n73r3d_fr0m_7h3_p3rf0rm4nc3_p4d_k3yb04rd}
P.S. Of course, turns out it's not necessary to resort to guessing to solve this task. One could simply
use the brain, read the midiInOpen manual, reverse engineer the callback
that's passed to it, and figure out the logic explained above. But why would
anyone in their mind do that? /s