基于Cynthion逆向USB协议，为DP100电源开发Linux控制软件

1. 项目概述：用Cynthion嗅探USB，为DP100电源打造Linux软件

作为一名长期在Linux环境下折腾硬件和嵌入式开发的爱好者，我经常遇到一个头疼的问题：很多不错的桌面小设备，比如电源、示波器、逻辑分析仪，它们的官方软件只支持Windows和macOS。最近我入手了一台Alientek DP100桌面可编程电源，它体积小巧，性能不错，但那个操作界面和显示屏实在让人捉急。更关键的是，官方没有提供Linux驱动或控制软件。这激发了我的探索欲——既然没有，那就自己造一个。

这个项目的核心，就是通过逆向工程（Reverse Engineering）来破解DP100与电脑通信的私有USB协议，并最终用Python写一个能在Linux上完美控制它的软件。整个过程就像一场数字侦探游戏，而我的“放大镜”和“指纹采集器”，是一块名为Cynthion的硬件工具。它来自Great Scott Gadgets，本质上是一个基于FPGA的可编程USB分析仪，专门用来捕获和解析USB总线上的原始数据流。相比早年我用过的usbmon配合Wireshark的方案，Cynthion的定向抓包和清晰的数据视图让协议分析效率提升了不止一个档次。

最终，我不仅成功破译了DP100那套有点“反直觉”的通信协议，还完成了一个功能完备的Python控制库。这篇文章，我会详细拆解从硬件抓包到软件实现的完整过程，分享其中踩过的坑和总结出的技巧。无论你是对USB协议分析感兴趣，还是想为自己手头不支持Linux的设备编写驱动，相信都能从中获得直接的参考。

2. 工具选型与逆向工程思路解析

2.1 为什么选择Cynthion而非传统方案？

在决定动手之前，我评估了几种常见的USB协议分析方案。最基础的方法是使用Linux内核内置的usbmon功能，它可以将USB总线上所有的通信数据包导出，然后通过Wireshark进行分析。这个方法免费，但问题也很明显：它是“无差别”抓包。这意味着你电脑上所有USB设备（鼠标、键盘、U盘等）的数据包都会混杂在一起，即使使用Wireshark强大的过滤功能，要从海量无关数据中精准定位目标设备的通信，也如同大海捞针，效率极低，且容易遗漏关键帧。

另一种方案是购买商业的USB协议分析仪，这类设备通常功能强大，但价格昂贵，从几千到上万元不等，对于个人爱好者或偶尔的项目来说，成本过高。

Cynthion则是一个折中而优雅的解决方案。它是一块开源硬件，核心是一颗FPGA（现场可编程门阵列）。这意味着它的功能不是固定的，你可以通过加载不同的“固件”（或称比特流文件）让它变身成不同的工具，比如USB 2.0协议分析仪、逻辑分析仪，甚至是简单的数字信号发生器。我这次使用的就是其USB 2.0分析仪功能。它的工作原理是作为“中间人”（Man-in-the-Middle），串联在主机（你的电脑）和目标设备（DP100电源）之间。所有流经的数据都会被它捕获、解码并上传到配套的电脑软件进行展示，而不会干扰正常的通信。这种定向、干净的抓包环境，是逆向工程成功的第一步。

注意：Cynthion支持USB 2.0的Low Speed（1.5 Mbps）、Full Speed（12 Mbps）和High Speed（480 Mbps）三种速率。在购买或使用前，务必确认你的目标设备使用的USB速率在其支持范围内。DP100使用的是Full Speed，完全兼容。

2.2 逆向工程的基本流程与心理准备

逆向一个私有USB协议，本质上是一个“观察-假设-验证”的循环过程。你需要像侦探一样，通过正常操作官方软件，观察并记录下产生的所有USB数据包，然后尝试找出数据包结构与实际功能（如设置电压、读取电流）之间的映射关系。

这个过程需要耐心和细心。协议很可能不是直观的，厂商可能会使用自定义的字节序、校验和、或者非标准的命令结构。我的经验是，先从最简单的、单向的操作开始，比如“读取设备型号”。这种操作通常只会触发主机向设备发送一个请求，然后设备返回一段数据。通过对比多个简单操作的数据包，更容易找到协议中的固定帧头、帧尾或命令字。

心理上要做好准备：你可能会面对一堆看似毫无规律的十六进制数字。不要气馁，充分利用分析软件提供的视图，从高层次的事务（Transaction）层面开始理解，再深入到数据包（Packet）层面去看原始字节。

3. 实战：使用Cynthion与Packetry捕获DP100协议

3.1 硬件连接与软件配置

首先，你需要搭建好抓包环境。将Cynthion通过USB线连接到你的电脑（这用于给Cynthion供电并传输抓取的数据）。然后，用两根USB线（A公 to B公）分别连接电脑的另一个USB口到Cynthion的“上游”（Upstream）端口，以及Cynthion的“下游”（Downstream）端口到DP100电源。这样，数据流路径就是：电脑 -> Cynthion -> DP100，Cynthion在中间进行监听。

电脑上需要安装Great Scott Gadgets提供的图形化软件Packetry。这个软件是Cynthion协议分析仪功能的控制中心和数据显示界面。启动Packetry后，选择正确的Cynthion设备端口，并将其模式设置为USB 2.0分析仪。

3.2 利用Packetry的三视图理解数据流

Packetry软件提供了三个核心视图，这是理解USB通信的关键：

1. 分层视图（Hierarchical View）：这是最高层的视图，按照USB的逻辑结构（设备->配置->接口->端点）来组织捕获的数据。它帮你快速了解设备枚举过程，识别出用于数据传输的“端点”（Endpoint）。对于DP100，我很快发现它使用了一个“中断传输”（Interrupt Transfer）端点来周期性地上传状态数据（如当前电压、电流），以及一个“控制传输”（Control Transfer）端点用于发送命令。

2. 事务视图（Transactions View）：这个视图将一次完整的USB通信“事务”组合在一起显示。例如，一次“设置电压”的操作，可能包含主机发送的“OUT”事务（包含命令数据）和设备返回的“ACK”握手包。这个视图让你能看到逻辑上完整的操作单元，是分析功能与数据对应关系的主要战场。

3. 数据包视图（Packets View）：这是最底层的视图，显示每一个原始的USB数据包，包括SYNC、PID（包标识符）、地址、端点、数据载荷、CRC校验等所有细节。当你在事务视图中发现异常或需要验证数据完整性时，就需要深入到这个视图来检查。

我的抓包策略是：打开Packetry开始捕获，然后在Windows虚拟机（运行官方软件）或另一台装有官方软件的电脑上，对DP100进行一个明确的单一操作，比如将输出电压从5.0V调整到5.1V。然后停止捕获。这样，捕获到的数据流中就几乎只包含与这次调整相关的通信，极大简化了分析难度。

3.3 从原始数据到协议解析

捕获到数据后，真正的解密工作开始。以下是我分析DP100协议的具体步骤：

1. 定位有效载荷：在事务视图中，找到主机发送给设备的数据事务。在数据包视图中，聚焦于“DATA”包，其“Data Payload”字段就是实际发送的命令内容。DP100的命令通常是一个8字节或16字节的数据块。

2. 寻找模式：进行多次不同设置的操作（改变电压、改变电流、开关输出），并分别抓包。将每次操作对应的数据载荷记录下来，并列成表格进行对比。

   操作	数据载荷 (十六进制)
   设置电压 5.00V	aa 03 01 01 40 9c 00 00
   设置电压 5.01V	aa 03 01 01 41 9c 00 00
   设置电流 1.00A	aa 04 01 01 e8 03 00 00
   开启输出	aa 01 01 01 01 00 00 00

3. 假设与验证：通过对比表格，可以做出一些假设。例如，看到设置5.00V和5.01V时，只有第5个字节从0x40变成了0x41。这很可能就是电压值的低字节部分。结合0x41是65的十进制，而5.01V可能是以10mV为单位表示的（即501个单位），501的十六进制是0x1F5，这与0x41似乎对不上。这说明可能需要考虑字节序（大端/小端）或多字节组合。进一步观察，我发现0x40 0x9c两个字节一起变化，0x409c的十进制是16540，而5.00V如果以1mV为单位则是5000，这也不对。直到我尝试将两个字节交换顺序（小端序），0x9c40的十进制是40000，这看起来像是40000个某种单位代表5.00V？经过计算，40000 / 5.00 = 8000，这暗示分辨率可能是1/8000 V，即0.125mV。这个精度对于电源来说合理。用5.01V验证：5.01 * 8000 = 40080，十六进制是0x9C90。而我抓到的数据是0x41 0x9c，交换后为0x9c41，十进制是40001。存在1个单位的误差，这可能是官方软件四舍五入或我抓包时机细微差别导致的，但基本证实了假设。

4. 解析完整帧结构：通过反复测试，我最终破译了DP100命令帧的基本结构。以设置电压为例，它看起来像这样：AA CMD LEN CH DATA0 DATA1 CHK0 CHK1

   • AA: 固定的帧头。
   • CMD: 命令字，0x03代表设置电压。
   • LEN: 数据长度。
   • CH: 通道号（DP100是单通道）。
   • DATA0, DATA1: 实际参数值，以小端序（Little-Endian）的16位整数表示。数值 = 电压值(V) * 8000。
   • CHK0, CHK1: 校验和，通常是对前面所有字节进行某种算术运算（如求和取反）的结果，用于保证数据传输的准确性。这是协议中“有点奇怪”的部分，我通过在线搜索类似的校验算法和暴力尝试，最终确定它是前面所有字节累加和后，取低16位，再经过一个简单的变换。

实操心得：在分析校验和时，不要试图完全从数学上推导。可以写一个小脚本，遍历常见的校验算法（累加和、CRC8、CRC16等），用已知的正确数据包去匹配，这是最快捷的方法。我就是在网上找到一个类似设备的校验算法后，稍作修改就适配了DP100。

4. Python控制软件的架构与实现细节

4.1 开发环境与库选择

协议搞清楚后，编写Python软件就水到渠成了。我选择Python是因为其跨平台性和丰富的库支持，这样写好的代码在macOS和Windows上稍作修改也能运行。核心的库是PyUSB。这是一个纯Python的USB访问库，它封装了底层的libusb，提供了非常直观的API来查找设备、声明接口、进行数据传输。

在Linux上使用PyUSB需要一些权限设置。通常你需要将自己的用户加入到plugdev组，或者为特定的USB设备创建一条udev规则，以避免每次都需要sudo权限运行脚本。我采用了后者，创建了一个udev规则文件，通过设备的供应商ID（Vendor ID, VID）和产品ID（Product ID, PID）来赋予其读写权限。

# 示例：/etc/udev/rules.d/99-dp100.rules SUBSYSTEM=="usb", ATTR{idVendor}=="0483", ATTR{idProduct}=="5740", MODE="0666", GROUP="plugdev"

4.2 软件核心类设计

我的dp100_manipulator软件结构并不复杂，但追求清晰和实用。核心是一个DP100类，它封装了与设备通信的所有细节。

import usb.core import usb.util class DP100: def __init__(self, vid=0x0483, pid=0x5740): """初始化，根据VID/PID查找设备""" self.dev = usb.core.find(idVendor=vid, idProduct=pid) if self.dev is None: raise ValueError("DP100 device not found!") # 在Linux上，有时需要手动卸载内核驱动 if self.dev.is_kernel_driver_active(0): try: self.dev.detach_kernel_driver(0) except usb.core.USBError as e: print(f"Could not detach kernel driver: {e}") # 设置设备配置 self.dev.set_configuration() # 获取用于控制传输的端点引用（根据抓包分析得知） self.cfg = self.dev.get_active_configuration() self.intf = self.cfg[(0,0)] # 通常第一个接口 self.ep_out = usb.util.find_descriptor(self.intf, custom_match=lambda e: usb.util.endpoint_direction(e.bEndpointAddress) == usb.util.ENDPOINT_OUT) self.ep_in = usb.util.find_descriptor(self.intf, custom_match=lambda e: usb.util.endpoint_direction(e.bEndpointAddress) == usb.util.ENDPOINT_IN) def _calculate_checksum(self, data): """计算协议要求的校验和""" # 这里是逆向工程得出的算法，例如简单的和校验 s = sum(data) & 0xFFFF chk0 = s & 0xFF chk1 = (s >> 8) & 0xFF # DP100协议可能要求某种转换，例如： # chk0 = 0xFF - chk0 # chk1 = 0xFF - chk1 return [chk0, chk1] def send_command(self, cmd, data_bytes): """构建并发送完整命令帧""" length = len(data_bytes) + 2 # 加上通道号和自身长度字节 frame = [0xAA, cmd, length, 0x01] + data_bytes # 0x01是通道号 chk = self._calculate_checksum(frame) frame.extend(chk) # 通过控制端点发送 self.dev.ctrl_transfer(bmRequestType=0x21, bRequest=0x09, wValue=0x0200, wIndex=0x00, data_or_wLength=bytes(frame)) # 或者通过中断OUT端点发送（根据实际抓包确定） # self.ep_out.write(bytes(frame)) def set_voltage(self, voltage_v): """设置输出电压""" # 将电压值转换为协议中的单位 value_int = int(voltage_v * 8000) data_low = value_int & 0xFF data_high = (value_int >> 8) & 0xFF self.send_command(0x03, [data_low, data_high]) def read_status(self): """读取当前状态（电压、电流等）""" # 发送读取状态命令，或从中断IN端点周期性读取 # 这里需要实现解析状态数据包的功能 pass def close(self): """关闭设备连接""" usb.util.dispose_resources(self.dev)

这个类隐藏了USB通信的复杂性，对外提供set_voltage(),set_current(),output_on()等高阶方法，让控制电源变得像调用普通函数一样简单。

4.3 实现图形化界面（可选）

为了让工具更易用，我使用Tkinter（Python标准库）为其添加了一个简单的图形界面。界面包含数字输入框用于设置电压电流，按钮用于开关输出，以及标签用于显示读取到的实际值。Tkinter虽然简陋，但无需额外依赖，跨平台兼容性好，对于这样一个工具来说完全够用。

界面的主要挑战在于如何将后台的USB通信（可能是阻塞的）与前台响应用户操作的GUI事件循环结合起来。我采用了简单的线程机制，将发送命令的操作放入一个单独的线程中执行，避免界面在等待USB响应时卡死。

5. 开发过程中的常见问题与解决方案

5.1 USB设备权限问题

这是Linux下开发USB应用最常见的“拦路虎”。症状是运行脚本时报告Access denied或Permission denied。

• 临时解决方案：使用sudo运行你的Python脚本。但这不适合最终使用。
• 永久解决方案（推荐）：创建udev规则。步骤如上文所述。创建规则后，需要重新插拔设备或运行sudo udevadm control --reload-rules && sudo udevadm trigger来使规则生效。
• 检查：使用lsusb命令找到设备的VID和PID，使用ls -l /dev/bus/usb/xxx/yyy查看设备文件权限，确认是否已变为0666。

5.2 PyUSB找不到设备或资源忙

• 问题：usb.core.find()返回None，或者后续操作报错Resource busy。
• 排查：
  1. 首先确认设备已连接，且VID/PID正确。用lsusb命令核对。
  2. Resource busy通常意味着设备已被系统内核或其他程序（如虚拟机）占用。在Linux上，你需要“夺回”设备控制权。这就是上面代码中detach_kernel_driver(0)的作用。注意，这个操作可能需要root权限，或者你的用户有相应的能力（Capability）。
  3. 确保没有其他软件（如官方Windows软件在虚拟机中）正在占用该设备。

5.3 数据发送后设备无响应

• 问题：命令发送成功（无异常抛出），但电源设备没有任何动作。
• 排查：
  1. 校验和错误：这是最可能的原因。私有协议对校验和非常严格，错一个字节整个数据包都会被设备丢弃。务必用抓包工具对比你生成的命令帧和官方软件发出的命令帧，确保完全一致，特别是校验和部分。我的校验和算法就是通过对比多个正确数据包反推出来的。
  2. 端点类型错误：USB有控制传输、中断传输、批量传输等。你发送数据使用的端点类型必须与设备期望的匹配。通过Cynthion抓包，明确看到命令是通过“控制传输”（Control Transfer）的特定请求发送的，还是通过“中断输出”（Interrupt OUT）端点发送的。我的代码示例中给出了两种方式的注释，你需要根据实际情况选择。
  3. 命令格式错误：重新检查你的命令帧结构，帧头、长度、通道号等字段是否正确。长度字段是否包含了它自身和通道号？

5.4 无法读取设备状态

• 问题：可以控制设备，但无法读取当前的电压、电流值。
• 排查：
  1. 读取方式：状态信息可能是设备主动周期性上报的（通过中断IN端点），也可能是需要主机发送特定查询命令后返回的。通过抓包分析官方软件是如何获取状态的。
  2. 解析数据：读取到的状态数据也需要逆向工程。抓取设备返回的数据包，对照电源屏幕上显示的实际值，找出电压、电流值在数据流中的位置和编码格式（通常也是某种缩放整数）。
  3. 异步处理：如果状态是周期性上报的，你的程序需要建立一个单独的线程或使用异步IO来持续读取中断IN端点，并解析数据，更新到GUI或日志中。

5.5 跨平台兼容性小贴士

虽然项目起源于Linux，但PyUSB是跨平台的。要让代码在Windows和macOS上也能运行，主要注意两点：

1. 驱动：在Windows上，USB设备需要安装一个通用的WinUSB或libusb驱动，而不是厂商驱动。可以使用Zadig这个工具来为设备安装libusb-win32或WinUSB驱动。
2. 后端：PyUSB支持多种后端（libusb0, libusb1, openusb等）。在代码开头可以指定后端，或者让PyUSB自动选择。通常import usb.backend.libusb1 as libusb1并指定后端是最可靠的方式，但需要确保系统已安装libusb。

这个项目从硬件抓包到软件实现，完整地走通了一个设备逆向与驱动的流程。最终得到的Python库不仅解决了我在Linux下使用DP100的问题，其代码结构和分析方法也可以作为模板，应用到其他USB设备的逆向工程中。最重要的是，整个过程充满了发现和解决问题的乐趣，这或许就是硬件黑客精神的所在。