【发布时间】:2020-03-13 10:20:05
【问题描述】:
我正在构建一个 python 库来操作我便宜的中文 iGK64 机械键盘的照明和可编程性功能,因为 Windows 驱动程序应用程序无法在 Linux 上运行。
我在 Windows VM 中运行了制造商的驱动程序应用程序并捕获了 USB 数据包以进行分析。在过去几天的空闲时间里,我一直在分解这些数据包的内容,以确定不同的部分是什么,以及它们的作用。
到目前为止,我已经确定了以下事实:
- 发送到键盘和从键盘接收的每个数据包都是 64 字节。
- 第一个字节是某种目的地指示符。我将其称为“注册 ID”,可能更准确地说是“页面 ID”。该字段长 1 个字节。
- 第二个字节是“指令”。例如,0x02 表示“写”,0x01 表示“读”,我也见过 0x09(我认为是“执行”)和 0x00(我认为是 noop 或 ping)。该字段长 1 个字节。
- 下一部分是“地址”,它是一个 16 位无符号整数,指示 在哪里进行读取或写入。此字段长 2 个字节,小端。
- 接下来是有效载荷长度。一个 16 位无符号整数,指示要读取或写入的字节数。此字段长 2 个字节,小端。
- 在负载本身之前是校验和。一个16位的值,我对此知之甚少。字段长 2 个字节,我假设为小端。
- 有效负载在最后。它的长度在 0 到 56 字节之间,但用零填充,因此总数据包大小为 64 位。
- 看起来像
reg:{} instr: {} addr: {} len: {} checksum: {} payload: {}
这是一个数据包的示例:
原始:
0x220200003800E670FFFFFFFFFFFFFFFF010000020200000204000002080000021000000220000002FFFFFFFFFFFFFFFF00040002000500020006000200070002
解构:
reg: 0x22 instr: 0x02 addr: 0x0000 len: 56 (0x3800) sum: 0xE670
payload: 0xFFFFFFFFFFFFFFFF010000020200000204000002080000021000000220000002FFFFFFFFFFFFFFFF00040002000500020006000200070002
我一直在确定用于计算校验和的算法。我尝试了一些基本的异或序列,以及一些加/减方法,但没有一个是正确的。
这是两个几乎相同的数据包的示例,都发送到相同的寄存器,有效负载长度为零,唯一的区别是指令和地址。但是看看校验和是不同的。
原始1:
0x210201000000B63D0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
解构1:
reg: 0x21 instr: 0x02 addr: 0x0100 len: 00 (0x0000) sum: 0xB63D
payload: 0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
原始 2:
0x21000000000092610000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
解构2:
reg: 0x21 instr: 0x00 addr: 0x0000 len: 00 (0x0000) sum: 0x9261
payload: 0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
在这种情况下,这是从主机到外设的通信(写入 tr 寄存器 0x21,地址 0x100,零负载),然后从外设到主机(寄存器 0x21“ack”)。
我很确定数据包的每个属性都用于计算校验和,包括 reg id、instr、addr、len 和整个有效负载。
这里有更多示例可能有助于阐明校验和的计算方式:
Raw3(这是一个 PING,即主机和外围设备之间每秒发送多次的“活动”数据包):
0x0C0000000000A70D0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
解构3:
reg: 0x0C instr: 0x00 addr: 0x0000 len: 00 (0x0000) sum: 0xA70D
payload: 0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Raw4(一个负载全为 0xFF):
0x220288013800BC74FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
解构4:
reg: 0x22 instr: 0x02 addr: 0x8801 len: 56 (0x3800) sum: 0xBC74
payload 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
我有几个较大的原始通信转储,但与此处提供的示例相比,它们对于确定校验和算法可能不再有用。
任何帮助将不胜感激!
【问题讨论】:
-
那么您试图解决他们如何确定总和?我对此很感兴趣。
-
我找到了这个,它们看起来像您要的尺寸:lammertbies.nl/comm/info/crc-calculation.html
-
是的,我一直在确定用于计算校验和的算法。
-
非常感谢!我找到了。使用您链接的那个站点,作为快速测试,我输入了原始十六进制捕获,但校验和字段清零,单击计算,正确的校验和显示在“CRC-CCITT (0xFFFF)”下。
-
您能否使用您在网站中输入的确切数据更新您的帖子以获取校验和。我认为这将有助于发现这篇文章的未来调试器
标签: python algorithm usb driver checksum