无需触碰，通过音箱入侵你的电脑

# Pwnd Blaster: 无需物理接触，利用扬声器入侵你的电脑 原文链接：https://blog.nns.ee/2026/06/03/katana-badusb 在我的上一篇文章（https://blog.nns.ee/2026/02/20/katana-v2x-re）中，我讲述了逆向工程我的全新 Creative Sound Blaster Katana V2X 固件的过程。 起初我只是想写一个 Linux 工具来与我的扬声器通信，结果却发现了多个漏洞。这些漏洞允许大约 15 米范围内的任意攻击者，将任意 Katana V2X 转化为隐蔽的窃听工具和 Rubber Ducky —— 全程无需配对，也无需物理接触设备。 ### CTprotocol 背景（https://blog.nns.ee/2026/06/03/katana-badusb#ctprotocol-background） 正如我上一篇文章所解释的，Katana V2X 是一个通过 USB 连接电脑的音箱。由于采用 USB 连接，Creative 提供了一个应用程序，允许你更改扬声器的设置——比如 DSP、LED 配置、输出源等。 为此，他们使用了一个自定义协议，称为 CTP（我猜是 *Creative Transport Protocol* 的缩写）。基本上，这是一个相当简单的专有协议，用于发送各种命令并读取相应响应。这里我就不详细展开了，但如果你感兴趣，我在上一篇文章中描述了它的工作原理（https://blog.nns.ee/2026/02/20/katana-v2x-re/#reverse-engineering-the-protocol）。 然而，需要注意的重要一点是：要通过 USB 使用 CTP *做任何事*，你首先必须对设备进行挑战-响应认证。密钥是静态的，可以从 Creative 应用程序附带的二进制文件中推导出来。我不确定为什么会这样，但在完成认证之前，扬声器不会接受任何命令。好吧。 另一个后面会变得重要的点是：固件更新也是通过 CTP 进行的。我最初就是这样获得固件镜像的——我用 Wireshark 嗅探了 USB 流量，并从捕获中提取了数据。 使用 Wireshark 显示第一个固件载荷数据包的截图（https://blog.nns.ee/img/2026-02-20-katana-v2x-re/wireshark.png） ### 固件分析（https://blog.nns.ee/2026/06/03/katana-badusb#firmware-analysis） 固件容器也是专有的，但本质上是一个原始的 Zip 文件，包含三个具有重要价值的部分。 首先是 `FBOOT`，我之前推测这只是一个引导加载程序（因此得名），但它也包含了扬声器的一种恢复模式。按住 SOURCE 键同时启动设备即可进入此恢复模式，从而从故障状态中恢复。这多次拯救了我的设备免于变砖，对此我非常感激。 第二部分是 `FMAIN`，它是设备的主固件。当设备“正常”启动时，就会运行这部分。虽然 `FBOOT` 实现了许多与 `FMAIN` 相同的功能（例如，它们都处理 CTP 命令），但 `FMAIN` 比 `FBOOT` 大 6.5 倍左右。 `FBOOT` 和 `FMAIN` 都基于一个（经过相当大量修改的）FreeRTOS 版本，这从二进制文件中出现的字符串可以推断：`/home/jieyi/mcuos2.5/kernel/freertos-8.2.3/`。 最后值得注意的部分是 `CHK2`，它是对整个固件容器的 SHA-256 校验和，附加在最末尾。 考虑到 CTP 认证投入的精力，看到除了这个 `CHK2` SHA-256 校验和（修补它很容易）之外，刷写固件时没有其他保护措施，我有点惊讶但也不算震惊。我本以为这里会有签名检查，或者至少是 `hashsum(secret_value + container_contents)` 这样的保护，但在我的自有工具 `v2x-ctl`（https://crates.io/crates/v2x）中重新实现了固件升级功能后，我发现只要 `CHK2` 正确，设备就会愉快地接受修补后的固件。 为了测试这一点，我做了一个非常简单的修改——我将设备启动时在段显示器上显示的字符串 `WELCOME` 替换成了 `PATCHED`。刷写固件并重新启动设备后，我高兴地看到我的字符串显示了出来： 设备正面段显示器显示文本 PATCHED 的图片（https://blog.nns.ee/img/2026-04-08-katana-badusb/patched.jpg） 我内心的黑客部分觉得这很棒——人们应该能对他们购买并拥有的设备为所欲为。而安全专业人员的那部分则认为，完全没有*任何*保护措施（比如像移动设备那样需要解锁引导加载程序）是很糟糕的实践。但如果需要通过 USB 物理接触设备来更新固件，那倒也不是世界末日。 如果。 ### 人人都爱蓝牙（https://blog.nns.ee/2026/06/03/katana-badusb#everybody-loves-bluetooth） 像现在所有“有自尊”的扬声器一样，Katana V2X 当然也必须有蓝牙，尽管它大部分时间很可能都是通过线缆连接到电脑或游戏机上。 而且，*当然* Creative 需要有一个应用程序，让你可以通过手机蓝牙控制扬声器的设置和花哨的 LED 灯。 BLE（低功耗蓝牙）的工作原理是：每个设备都有各种寄存器（称为 *GATT 特性*），如果你连接到设备，就可以写入、读取、订阅通知等等。重要的是，要连接到一个设备，你（不一定）需要与之配对。你通常可以只连接设备，然后立即开始读写特性数据。配对会建立加密，但可以在没有加密的情况下建立连接。 在深入研究 Katana 固件时，我发现内部的 CTP 处理程序桥接了 USB 和蓝牙： CtpService_Init 函数的 Ghidra 反编译输出（https://blog.nns.ee/img/2026-04-08-katana-badusb/ctp-init.png） 对此很感兴趣的我下载了 Creative 移动应用程序，并尝试连接到我的扬声器。 “请按 POWER 按钮配对。” 我想知道这个配对过程到底是怎么工作的。也许它使用了与 USB 相同的认证方案，也许我可以直接用共享密钥通过蓝牙认证*任何*扬声器，就像我的电动滑板车的情况一样（https://blog.nns.ee/2026/01/06/aike-ble/）。 我设置了一个蓝牙嗅探环境，并观察到：为了启动配对过程，手机将一个类似 `5a 0b...` 的载荷写入特性 `9e9daaec-3a10-4fe8-b69f-7397aff77886`，并从特性 `9e9daaeb-3a10-4fe8-b69f-7397aff77886` 读取响应。 `5a` 让我非常、非常怀疑，因为所有 CTP 命令都是以这个字节开头的。出于直觉，我从笔记本电脑通过蓝牙连接到设备，并写入了载荷 `5a 09 01 02`，这是读取固件版本的 CTP 命令，通过 USB 发送时需要认证。 令我惊讶的是，在读取特性 `9e9daaeb-3a10-4fe8-b69f-7397aff77886` 时，我得到了完整的版本字符串。这意味着任何人都可以直接通过蓝牙连接到任意 Katana V2X，开始向它发送 CTP 命令，读取信息，更改设置等等。 ### 空中更新（糟糕的那种）（https://blog.nns.ee/2026/06/03/katana-badusb#over-the-air-updates-the-bad-kind） 我没花太多时间就能联想到，固件升级也是通过 CTP 进行的。结合任何人都可以构建有效自定义固件这一事实，我开始思考：是否有可能让攻击者通过蓝牙直接上传自定义固件，而无需认证或配对？ 在与一些 BLE 小问题（我将在本文后面详细描述）搏斗之后，我编写了一个相对简单的 Python 脚本，它完全做了我的 `v2x-ctl` 工具升级固件所做的事情，但这次是通过蓝牙。我尝试将之前制作的自定义固件上传到我的扬声器。由于 BLE 相当慢，整个过程大约花了 10 分钟，但完成后，我再次看到了可爱的“PATCHED”欢迎信息。 我思考了一会儿这其中的影响。扬声器有个麦克风。攻击者理论上可以上传一个自定义固件，将扬声器变成一个隐蔽的监控设备，窃听对话并通过蓝牙转发到接收器。 对我来说更有趣的是，在标准设置下，扬声器是通过 USB 连接到电脑的。它完全是一个受信任的 USB 设备。 如果我们编写一个自定义固件，强制扬声器充当键盘，发送按键打开终端并执行任意命令呢？这样我们就可以把扬声器变成一个 Rubber Ducky（https://shop.hak5.org/products/usb-rubber-ducky），但却是远程的，而且无需向扬声器或电脑插入任何东西。 ### 在内核领域寄生（https://blog.nns.ee/2026/06/03/katana-badusb#living-off-the-kernel-land） 起初，我认为这将是一项艰巨的任务。由于我无法访问固件的源代码，我必须想办法拼凑出一整段代码：将设备设置为 HID（*人机接口设备*）USB 设备（如果这个 SoC 支持的话），然后利用它通过 USB 向电脑发送按键，同时让固件的其余部分继续运行，以保证扬声器行为正常。 然而，在固件中进一步挖掘后，我意识到它可能没有看起来那么困难。 首先，事实证明扬声器已经将自己设置为 HID 设备。不是完整的键盘，而是作为消费控制设备——基本上让扬声器可以更改电脑的音量和媒体状态（播放/暂停），但仅此而已。 这可以从内核日志中看到： 显示 Katana 消费控制 HID 设备的 dmesg 输出（https://blog.nns.ee/img/2026-04-08-katana-badusb/dmesg-before.png） USB 设备这样做的方法是：向电脑提供一个 USB 描述符集，这基本上是其能力、能做什么、要枚举多少个接口等等的报告。 固件中的报告描述符很容易定位，幸运的是，它有足够的空间来追加第二个报告描述符条目，该条目也将设备呈现为键盘。运行 `dmesg` 现在显示设备也报告自己是键盘： 显示 Katana 键盘 HID 设备的 dmesg 输出（https://blog.nns.ee/img/2026-04-08-katana-badusb/dmesg-after.png） 第二个问题是发送实际的 HID 数据并模拟击键。非常幸运的是，固件中已经有一个简洁可用的发送 HID 数据的例程，我所做的就是提供数据（要按下或释放的键）并调用它。 第三个问题让我费了不少劲。很难找到足够的空闲空间来写入（这些空间需要能正确映射到内存，或者在启动时不会立即导致设备崩溃），还要找到一个合适的跳板，并且在返回正常指令流时不会崩溃等等。 我最终意识到，如果这是在 FreeRTOS 上运行，那么启动时很可能会有大量任务被执行。我不需要编写跳板并处理执行流，我可以直接覆盖一个现有的任务，让固件为我生成它。我最终找到了一个 `diagnostic` 任务，在正常使用中它似乎什么都不做——据我所知，它只用于从 DSP 协处理器收集诊断数据。 我用一个任务覆盖了该任务： 1. 等待约 20 秒，让扬声器启动并拉起 USB 子系统 2. 输入 `echo pwned` 并回车，每次击键间隔约 20ms 3. 结束任务，保持扬声器的其余功能完好无损 这样设备每次启动都会执行这个操作。 最终的补丁非常小——USB 报告只有 83 字节，手动编写的 ARM/Thumb 汇编代码（用于按键注入器）为 102 字节，再加上每个要发送的按键 2 字节。 ### 结果（https://blog.nns.ee/2026/06/03/katana-badusb#the-result） 将所有环节串联起来，我能够完全远程地、通过空中（未配对）向我的扬声器上传自定义固件。设备会重启，刷入自定义固件，然后再次重启后输入并执行命令 `echo pwned`。 终端输出显示修补和刷写固件，以及扬声器在重启后输入 "echo pwned" 并按回车（https://blog.nns.ee/img/2026-04-08-katana-badusb/poc.png） 在真实的攻击场景中，我会执行打开 `powershell.exe` 或类似程序的按键，并粘贴一个真正的恶意单行命令。但作为概念验证，这对我来说已经足够了。真实的攻击者可能还会禁用正常模式和恢复模式下更新固件的例程，使得从设备中清除恶意固件或将来修补它变得不可能。 更糟糕的是，扬声器的蓝牙*始终开启*，即使在睡眠模式下也是如此，而且似乎没有办法禁用它。 ### 补救措施（https://blog.nns.ee/2026/06/03/katana-badusb#remediation） 与 Creative 联系的过程令人沮丧。 他们没有安全联系人。实际上，我甚至找不到常规的联系方式，只有他们网站上的支持表单。我尝试了两次通过网页表单联系他们，然后放弃了，转而联系 SingCERT 作为中间人，希望他们能更顺利地联系到 Creative。 起初，SingCERT 似乎也无法联系到 Creative。Creative 花了将近两个月才回复 SingCERT。不幸的是，他们的回复是“他们认为这不构成漏洞，因为它不构成网络安全风险”。我不知道他们是如何得出这个结论的，但很明显 Creative 没有兴趣回应或解决这个问题。 因此，目前没有来自 Creative 的补丁。最新的固件仍然存在漏洞。 作为部分补救措施，为了确保人们仍然能够安全使用这些设备，我编写了一个固件补丁，用于阻止 CTP-over-Bluetooth。这很可能会破坏 Creative 的移动应用程序，但在没有源代码的情况下，很难在固件中正确实现认证。 如果你有兴趣使用这个补丁，我创建了一个工具，可以从 Creative 的服务器下载官方固件，在内存中修补它，然后上传到你的 USB 连接 Katana V2X。你可以从这里获取：https://git.dog/xx/v2x-patcher（或者如果你想事先检查补丁，可以自己用 `cargo` 构建）。 --- ## 技术细节（https://blog.nns.ee/2026/06/03/katana-badusb#the-nitty-gritty） 以下是逆向工程过程和二进制补丁的一些技术细节，顺序不分先后。 ### 内存布局问题（https://blog.nns.ee/2026/06/03/katana-badusb#memory-layout-woes） 为了使 Ghidra（或任何其他逆向工程工具包）的自动分析能够正常工作，二进制文件需要正确的基地址。否则，使用基地址计算的指针将指向错误的数据，你只会得到没有多大意义的反汇编结果。 对于 `FMAIN.bin`，我费了不少劲。仅仅用我假设的正确基地址（`0x10000000`）加载固件是不够的。当我使用这个基地址加载二进制文件时，自动分析似乎产生了有效的结果，启动代码和 FreeRTOS 核心看起来也是正确的。但在那之后的一小段区域，自动分析似乎失效并产生了垃圾数据。