我正在尝试解密由usbmon产生的USB I / O流量的痕迹，并且我遇到了一些问题，让我不知所措。例如，以下是我正在使用的跟踪中的两行：
ffff8800650e7000 433121059 S Ci:2:000:0 s 80 06 0100 0000 0040 64 <
ffff8800650e7000 433121661 C Ci:2:000:0 0 18 = 12010002 00000040 da0b8781 00010102 0301
我最初对跟踪中除了big-endian之外的任何事情都没有任何怀疑，但后来我在第二行看到了da0b8781，这与我跟踪的USB设备的身份相对应ID为0x0bda，产品ID为0x8187（请注意跟踪中字节顺序的反转）。
所以在这一点上我认为可能在usbmon跟踪的给定字段内，字节总是以反向字节顺序排列，应该这样解释。但恰恰相反，让我们检查第一条跟踪线末端附近的一小部分，... 0040 64
0040是一个十六进制字段，表示最大接受响应大小。 64是一个十进制字段，应该代表完全相同的东西。 0x0040 = 64十进制，而不将字节顺序切换为0x4000，然后！= 64十进制。所以在这一点上，我开始对usbmon跟踪的不同部分的字节顺序有点不确定。
接下来我想，也许只是usbmon跟踪的数据部分是反向字节顺序。所以我想也许我真的应该读书了
...12010002 00000040 da0b8781 00010102 0301
作为
1030 20101000 1878b0ad 04000000 20001021...
不，这似乎也不对。 USB规范声明供应商Id（在我的情况下为0x0bda）对于此特定字符串应为字节偏移量8。如果我们将上面的字符串保留为原始顺序，那么供应商Id确实从字节偏移量8开始（12010002 00000040消耗前8个字节），但是如果我们像上面那样反转它，那么它从字节偏移开始6（1030 20101000仅消耗前6个字节。）
所以我最好的猜现在是usbmon显示所有big-endian，接受它切换到每个4字节字的反向字节顺序，但仅适用于数据。任何人都可以提供一些关于这是否正确的澄清，或者是否可能有其他我遗漏的东西？
答案 0 :(得分：2)