Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

The Sound Blaster X7 is a Digital to Analog (DAC) converter and amplifier. It takes several inputs, mixes them into a single output. There is an Android App over Bluetooth or (for Windows) over USB. The author just wanted to change their audio on their headphones!

To capture Bluetooth traffic on an Android device, there is a cool setting to output Bluetooth into a pcap file: Bluetooth HCI snoop log. The author then takes captures with VERY specific actions: on, volume up, volume down and off. This is to KNOW what each command does.

Once in Wireshark, viewing the pcap file, they had a bunch of character encoding issues (lolz); after they installed the right fonts ,every became better. The Bluetooth packet was showing RFCOMM as the information in the packet.

What do these values actually mean? 5a29050001000000 is change output to headset but we have NO idea what this means. Luckily for us, Android apps are super easy to reverse engineer using Jadx and APKTool.

From reversing the application, here is what they picked up on the format:

1. X7 Control packets start with 0x5A.
2. The second byte is the command ID, which seemed to always be 0x29.
3. The third byte is the LENGTH of the packet.
4. The rest is the command payload.

For the commands get/setSpeakerConfiguration, the first byte of the payload determined if this was a READ or a WRITE. The rest of the data, for setSpeakerConfiguration, was for changing the specific settings, such as changing the speaker being used and advanced settings.

Muting is done with the command setHardwareButtonState (38), with a byte for the button ID. Apparently, this code is reused for other applications, since this had MANY other hardware buttons that did not exist on the regular device.

The tricky part was the VOLUME. The volume being in dB, a logarithmic scale, definitely caused the author problems. First, replaying didn't work perfectly, with the same input producing different outcomes. Originally, they tried to use a percentage, which doesn't make sense in the logarithmic scale.

The inputs ended up having REALLY complicated formulas to get the actual output volume. In the end, they figured out that it was an INCREASE or DECREASE, instead of an actual value. Since this was keeping state, it made things a tad more complicated.

Overall, fun reversing project with practical implications. I appreciate the Bluetooth reversing notes!