逆向工程 Creative Katana 音箱：在 Linux 下掌控你的硬件

背景

作者近期购入了一款 Creative Sound Blaster Katana V2X 条形音箱，旨在替换旧的 Logitech 电脑音箱，以获得更好的音乐和电影聆听体验。然而，在设置过程中发现了一个棘手的问题：该音箱的 USB 端口不仅用于音频输入，还允许用户通过软件配置均衡器（EQ）、LED 灯光模式等高级功能。

然而，Creative 官方提供的配置工具（Creative App）是专有软件，且仅支持 Windows 平台。虽然作者尝试在虚拟机（VM）中运行该应用，但体验极不便捷。对于习惯使用 Linux 且热衷于逆向工程专有应用、设备和协议的技术人员来说，这构成了一个完美的挑战：通过逆向工程，编写工具以在 Linux 环境下直接控制该设备。

核心内容

初步侦察与协议发现

作者首先对 Creative App 的安装目录进行分析，确认其为 .NET 应用程序。通过 dnSpy 加载 exe 及对应的 DLL 文件后，发现大部分模块经过混淆处理，难以直接阅读。因此，作者将重点转向 USB 通信本身。

利用 Wireshark 和 USBPcap 捕获 USB 流量，作者记录了音箱与主机之间的所有交互。在固件升级过程中，作者注意到数据包大小显著大于周围数据包，且固件负载似乎是明文格式。通过脚本，作者成功从捕获文件中提取了整个固件文件。

为了理解协议逻辑，作者系统性地遍历了应用中的每一个选项，点击、更改设置，并为每个操作创建了单独的捕获文件。经过约一天的工作，积累了约 100 个不同的捕获文件。分析表明，通信通过 CDC ACM 串行接口进行，在 Linux 下暴露为 /dev/ttyACM* 设备。

协议帧结构

所有专有命令使用简单的帧结构： 5A [cmd] [len] [payload...]

• 0x5A：静态起始标记。
• cmd：命令操作码。
• len：后续负载字节数。
• payload：负载或子命令本身。

响应结构类似，通常包含一个标识其为响应的字节。例如，请求当前固件版本的命令及响应如下：

• 主机 -> 设备: 5a 09 01 02
• 设备 -> 主机: 5a 09 12 02 10 "1.3.230619.1820\0"

挑战-响应认证机制

在发送任何控制命令之前，设备要求通过挑战-响应认证。作者最初怀疑使用 HMAC-SHA512，但在 dnSpy 中搜索相关哈希算法并未找到线索。通过 grep 搜索字符串 "whoareyou"，作者定位到唯一的匹配文件 CTCDC.dll，并在 Ghidra 中分析其交叉引用，最终确定了负责初始通信的函数。

分析揭示，该机制并非使用 SHA，而是基于 AES-256-GCM 的认证方案。

挑战消息格式： whoareyou [1E 04] [83 32] [32-byte nonce] \r\n

• [1E 04]：挑战头。
• [83 32]：设备类型（USB PID 0x3283 的小端序）。
• [32-byte nonce]：32 字节的随机数。

密钥生成： 密钥并非硬编码在 DLL 中，而是由挑战消息和 DLL 中的静态数据动态构建：

• 字节 0-1：挑战头 (1E 04)
• 字节 2-3：DLL 静态数据 (D3 1A)
• 字节 4-27：DLL 静态数据（24 字节，来自地址 0x101dba78）
• 字节 28-29：DLL 静态数据 (E0 7B)
• 字节 30-31：挑战中的 USB PID 字节 (83 32)

由于挑战头对设备是常量，该密钥对于此特定设备实际上是硬编码的。

响应计算：

1. 生成 16 个随机字节作为 iv。
2. 使用 iv[0:12] 作为 GCM nonce。
3. 使用 AES-256-GCM 加密 32 字节挑战 nonce：(ciphertext, tag) = AES-256-GCM(key, iv[:12], nonce)。
4. 响应格式："unlock" + iv + ciphertext + tag + "\r\n"。

作者指出，这种使用加密而非 HMAC 的方式较为罕见，主要提供完整性校验，而机密性在此场景下意义不大（因为 nonce 双方已知）。

工具开发与固件提取

基于逆向工程的结果，作者使用 Rust 编写了一个名为 v2x-ctl 的库和 CLI 应用程序，允许 Linux 用户控制 Katana V2X 音箱。该工具目前仅针对最新固件版本（1.3.230619.1820）进行了充分测试。

此外，作者还详细描述了固件升级的数据包结构，并编写了使用 tshark 提取固件的脚本。提取出的文件标识为 CIFF（Creative Image File Format），这是一种包含不同部分的容器格式。作者分析了其中的 CINF 部分（设备信息，UTF-16LE 字符串），为后续可能的固件修改或分析奠定了基础。

关键要点

• 专有协议逆向：Creative Katana V2X 音箱使用基于 CDC ACM 的串行通信协议，帧头为 0x5A，结构清晰。
• 非标准认证：设备采用基于 AES-256-GCM 的挑战-响应机制进行认证，而非传统的 HMAC，密钥由设备 PID 和 DLL 静态数据动态生成。
• Linux 兼容性缺失：官方配置工具仅限 Windows，迫使 Linux 用户通过逆向工程获取控制权。
• 开源工具产出：作者开发了 v2x-ctl（Rust 编写），实现了在 Linux 下对音箱 EQ、灯光等功能的控制。
• 固件提取可行：通过捕获 USB 流量，成功提取了明文固件负载，并识别出 CIFF 容器格式，为固件分析提供了可能。
• 潜在扩展性：虽然工具目前针对特定型号和固件版本，但协议结构可能适用于其他 Sound Blaster 设备，只需调整密钥和 ID。

意义与影响

这一逆向工程项目展示了开源社区在对抗专有硬件锁定方面的能力。通过深入分析 USB 通信和二进制代码，作者不仅解决了个人在 Linux 环境下使用 Creative 硬件的痛点，还为其他用户提供了控制该设备的开源工具 v2x-ctl。

从技术角度看，该案例揭示了现代消费电子产品中常见的安全设计缺陷：

1. 密钥管理薄弱：认证密钥虽然动态构建，但核心组件（DLL 静态数据）是固定的，导致密钥对特定设备实际上是硬编码的，容易被逆向提取。
2. 协议不透明：专有协议缺乏公开文档，用户被迫依赖逆向工程才能正常使用设备的高级功能。
3. 固件更新机制：固件更新载荷以明文形式传输，使得固件提取和分析变得相对容易，这可能带来固件修改或安全审计的机会，但也暴露了更新过程缺乏完整性保护（在传输层面）的风险。

最终，这项工作不仅赋予了 Linux 用户对自己硬件的控制权，也促使厂商反思其专有软件生态和硬件兼容性策略，推动了硬件开放性和互操作性的讨论。