Original title: In my last post, I talked about reverse engineering my new Creative Sound Blaster Katana V2X's firmware.
Article
The author reverse engineered the Creative Sound Blaster Katana V2X and found that its custom CTP protocol uses a static key for USB authentication while firmware updates rely on a simple checksum check, so patched firmware is accepted when CHK2 is correct. They analyzed FBOOT, FMAIN, and CHK2 in a FreeRTOS-based firmware image and confirmed that CTP commands are reachable over BLE without pairing. By connecting to the speaker’s BLE characteristics and issuing CTP packets, they could read firmware details and upload firmware remotely, then verified this with a custom script that wrote a modified image over the air. The exploit path was extended by modifying USB descriptors so the device could also appear as a keyboard, and by replacing a dormant diagnostic task with payload code that injects keystrokes after boot. The proof of concept triggers echo pwned, but the same mechanism can enable opening terminals and running malicious commands, while also leaving the speaker microphone available for covert audio monitoring. The write-up notes practical engineering obstacles, including watchdog resets and task scheduling behavior, and documents firmware memory-layout tricks used for stable reverse engineering. The author published a mitigation patch that blocks CTP-over-Bluetooth because no official patch was delivered and the latest firmware is still vulnerable. Vendor outreach through support and SingCERT took weeks, and Creative ultimately rejected the report as not a cybersecurity risk, a conclusion many readers and commenters dispute. In the thread, commenters largely frame the issue as a broader example of hardware vendors treating security as an afterthought and leaving consumers exposed to persistent attacks even with limited physical access.
Readers broadly agree the finding shows a meaningful security weakness and highlight a familiar pattern where consumer devices ship with software and update paths that are poorly hardened. Many commenters criticize the vendor response as negligent, arguing that unauthenticated remote firmware upload into a device trusted by a computer is security-relevant even without a sophisticated payload. Several participants expand the threat discussion beyond bad-keyboard demos, suggesting malware could spread across nearby devices, abuse audio channels, or bridge USB and Bluetooth in ways that increase blast radius. Some ask practical defensive questions about protecting against malicious HID behavior, while others compare the work to reverse-engineering on related audio equipment and note differences in BLE auth exposure. The thread contains both concern and admiration, with repeated emphasis on delayed vendor communication, absent public security contacts, and the risk that similar models remain in other devices. Overall, commenters treat the write-up as valuable technical evidence and a warning sign for the connected-audio ecosystem.