逆向工程串行数据包答案

【问题标题】：Reverse engineer serial data packet逆向工程串行数据包
【发布时间】：2015-04-11 01:17:22
【问题描述】：

我有一个设备连接到 PC vie 串行端口 (rs-232)。该设备从串口接收命令后发送数据，我嗅探数据流经端口，几乎完全找出数据包结构，但至少有两个重要字段我无法确定。

第一个示例数据包（十六进制） - 内部有 2 个有效负载数据包：

0baa00000200039540330137732904020033000005534d6c07a567a73e15040701125600043853048a5c085500000000e940406f00039540330058388900020033000005534d6c07b501b4f01504070113020004fd1d040342155500000000e940406f0002009d0a03004a3030313733353530303830343630303830373131313030323415040701210801001035390000000000000000d3a7226c287472874b2a216a000000000000000000ab04

第二个示例数据包（十六进制） - 内部有 6 个有效负载数据包：

0b6601000600039540330137732904020033000005534d6c07a567a73e15040701125600043853048a5c085500000000e940406f00039540330058388900020033000005534d6c07b501b4f01504070113020004fd1d040342155500000000e940406f00039540330137732904020033000005534d6c07a567a73e15040702174901043853048a5c085500000000e940406f00039540330058388900020033000005534d6c07b501b4f01504070218010104fd1d040342155500000000e940406f00039540330137732904020033000005534d6c07a567a73e15040703301002043853048a5c085500000000e940406f00039540330058388900020033000005534d6c07b501b4f01504070331280204fd1d040342155500000000e940406f000600a10a03004a303031373335353030383034363030383037313131303032341504071152520100103539000000000000000094b5d2c94a11672acaa0abec0000000000000000006a85

我确定的数据包结构（以第一个数据包为例）：

文件标记为??? - 我不知道它是什么，需要猜测。有效载荷数据包的数量可能不同。如果我从数据包内部编辑任何字节并重新计算最后一个 CRC16，程序将接受数据包，但带有损坏的消息。如果我在没有重新计算 CRC16 的情况下编辑任何字节，程序将拒绝该数据包。

我需要什么？例如，我需要编辑 - 添加或删除一些内部有效负载数据包。

如果能提供任何帮助，我将不胜感激。

更新 1

具有不同请求时间字段的两个相同数据包：

0b6601000600039540330137732904020033000005534d6c07a567a73e15040701125600043853048a5c085500000000e940406f00039540330058388900020033000005534d6c07b501b4f01504070113020004fd1d040342155500000000e940406f00039540330137732904020033000005534d6c07a567a73e15040702174901043853048a5c085500000000e940406f00039540330058388900020033000005534d6c07b501b4f01504070218010104fd1d040342155500000000e940406f00039540330137732904020033000005534d6c07a567a73e15040703301002043853048a5c085500000000e940406f00039540330058388900020033000005534d6c07b501b4f01504070331280204fd1d040342155500000000e940406f000600a10a03004a303031373335353030383034363030383037313131303032341504081008320100103539000000000000000021c3e1c0e04d909a7cf512b20000000000000000008b61

0b6601000600039540330137732904020033000005534d6c07a567a73e15040701125600043853048a5c085500000000e940406f00039540330058388900020033000005534d6c07b501b4f01504070113020004fd1d040342155500000000e940406f00039540330137732904020033000005534d6c07a567a73e15040702174901043853048a5c085500000000e940406f00039540330058388900020033000005534d6c07b501b4f01504070218010104fd1d040342155500000000e940406f00039540330137732904020033000005534d6c07a567a73e15040703301002043853048a5c085500000000e940406f00039540330058388900020033000005534d6c07b501b4f01504070331280204fd1d040342155500000000e940406f000600a10a03004a303031373335353030383034363030383037313131303032341504071152520100103539000000000000000094b5d2c94a11672acaa0abec0000000000000000006a85

【问题讨论】：

您寻求帮助的具体内容是什么？你想知道神秘领域是什么吗？您有一个有趣的问题，其中显示了很多工作，但我不确定 Stack Overflow 是否适合在此类事情上寻求帮助。
感谢您的回复，我寻求帮助以确定可能是哪些字段：从开始的第二个和第三个字节（例如 aa00; 6601）和最后一个零序列之前的最后 14 个字节。跨度>

标签： serial-port protocols reverse-engineering

【解决方案1】：

对此我无法解释太多，但我可以提供这么多。

您展示的每个数据包似乎都具有以下布局：

<start><length><data><zeros><checksum>

地点：

<start> 是 1 个字节 (0b)。
<length> 是 2 个字节（aa00 和 6601）。这是<data> 的大小，小端（0x00AA 为 170，0x0166 为 358）。
<data> 以 2 字节的项目计数开头（0002 和 0006），大端（0x0002 为 2，0x0006 为 6），其余内容大多遵循您的分析.
<zeros> 是00 字节的可变长度块。
<checksum> 是 2 个字节。

您显示的数据包将因此分解如下：

0b
aa00
  0002
    0003954033 0137732904 020033000005534d6c07 a567a73e 150407 011256 0004 3853048a5c08 5500000000e940406f
    0003954033 0058388900 020033000005534d6c07 b501b4f0 150407 011302 0004 fd1d04034215 5500000000e940406f
  0002 009d 0a0300 4a303031373335 35303038303436303038303731313130303234 150407 012108 0100103539 0000000000000000 d3a7226c287472874b2a216a
000000000000000000
ab04

0b
6601
  0006
    0003954033 0137732904 020033000005534d6c07 a567a73e 150407 011256 0004 3853048a5c08 5500000000e940406f
    0003954033 0058388900 020033000005534d6c07 b501b4f0 150407 011302 0004 fd1d04034215 5500000000e940406f
    0003954033 0137732904 020033000005534d6c07 a567a73e 150407 021749 0104 3853048a5c08 5500000000e940406f
    0003954033 0058388900 020033000005534d6c07 b501b4f0 150407 021801 0104 fd1d04034215 5500000000e940406f
    0003954033 0137732904 020033000005534d6c07 a567a73e 150407 033010 0204 3853048a5c08 5500000000e940406f
    0003954033 0058388900 020033000005534d6c07 b501b4f0 150407 033128 0204 fd1d04034215 5500000000e940406f
  0006 00a1 0a0300 4a303031373335 35303038303436303038303731313130303234 150407 115252 0100103539 0000000000000000 94b5d2c94a11672acaa0abec 00000000
0000000000
6a85

您会注意到，在第二个数据包中，<data> 末尾有额外的00 字节，而<zeros> 比第一个数据包小。如果这些额外的00 字节被下移到<zeros>，那么两个数据包在<zeros> 中将有9 个字节：

0b
aa00
  0002
    0003954033 0137732904 020033000005534d6c07 a567a73e 150407 011256 0004 3853048a5c08 5500000000e940406f
    0003954033 0058388900 020033000005534d6c07 b501b4f0 150407 011302 0004 fd1d04034215 5500000000e940406f
  0002 009d 0a0300 4a303031373335 35303038303436303038303731313130303234 150407 012108 0100103539 0000000000000000 d3a7226c287472874b2a216a
000000000000000000
ab04

0b
6601
  0006
    0003954033 0137732904 020033000005534d6c07 a567a73e 150407 011256 0004 3853048a5c08 5500000000e940406f
    0003954033 0058388900 020033000005534d6c07 b501b4f0 150407 011302 0004 fd1d04034215 5500000000e940406f
    0003954033 0137732904 020033000005534d6c07 a567a73e 150407 021749 0104 3853048a5c08 5500000000e940406f
    0003954033 0058388900 020033000005534d6c07 b501b4f0 150407 021801 0104 fd1d04034215 5500000000e940406f
    0003954033 0137732904 020033000005534d6c07 a567a73e 150407 033010 0204 3853048a5c08 5500000000e940406f
    0003954033 0058388900 020033000005534d6c07 b501b4f0 150407 033128 0204 fd1d04034215 5500000000e940406f
  0006 00a1 0a0300 4a303031373335 35303038303436303038303731313130303234 150407 115252 0100103539 0000000000000000 94b5d2c94a11672acaa0abec
000000000000000000
6a85

但是第二个数据包的<length> 是错误的，因为它必须是5C01 而不是6601。

需要更深入的分析来找出这种差异，并根据<length> 以及所有其他已知字段了解这些00 字节是否有意义。

【讨论】：

感谢您的分析，我在问题之前确定的每个块的大小，这些数据包是来自设备的原始数据，程序认为它们是正确的。我可以添加一件事，如果我将在不同时间从设备请求相同的信息 - 最后一个 DATE 和 TIME 将是我请求数据的时间，所有字段直到“d3a7226c287472874b2a216a”（从末尾开始的 14 个唯一字节）将是相同的。我认为它是一种从设备名称块开始的哈希，至少不同的数据包时间给出了这 14 个字节的不同序列。
我想如果我能理解这些字节的算法，我就可以制作正确的数据包。我不需要从头开始制作整个数据包，我只需要从设备中获取信息，编辑它（添加、删除内部有效负载）并将其发送到程序。我想说，我不需要反转所有字节，因为其中一些是来自设备的静态字节（例如“0b”）。 Mb -> 可以是?
现在我尝试至少更改数据包请求时间字段中的秒数，以确定 14 字节的算法，但如果我自己更改它，程序会说数据损坏。我有两个相同的数据包，具有相同的有效负载等，但它们的请求时间字段不同，也许，它会帮助你帮助我找到算法。我在问题 UPDATE 1 中添加了数据包。
没有办法仅通过查看原始字节来识别正在使用的哈希算法（如果它甚至是哈希）。我建议您找出发送此数据的设备类型，然后直接联系制造商并询问有关此协议的详细信息。
制造商拒绝有关协议的请求...概述该制造商的其他一些设备提供的信息表明他们使用 DLMS/COSEM 通信标准（以及一些关于 HDLC 和 x.25 之类的词），但是我不确定我的设备，没有这样的规范。附言也许它不是哈希，而是 FCS（帧校验序列）？

【解决方案2】：

这种情况下，除非您的时间几乎是空闲的，否则您只需去购买规格。如果你有几千美元要布局，你绝对应该成为 DLMS-UA（他们的用户协会）的成员，这样你就可以访问所谓的“彩色书籍” - 的“基本事实”标准DLMS 组织本身。

彩色书籍的摘录是freely available。这些应该涵盖一些基础知识。

感兴趣的核心书籍是蓝皮书和绿皮书，它们通过 ISO/IEC 标准化流程向非成员“开放”。引用DLMS International Standardization page，相关国际标准为：

IEC 62056-5-3，DLMS/COSEM 应用层。 3.0 版（2017 年）与绿皮书 8.3 版一致；

IEC 62056-6-2，COSEM 接口类。 3.0 版（2017 年）与蓝皮书 12.2 版一致；

IEC 62056-6-1，OBIS 对象识别系统 3.0 版，（2017 年）符合蓝皮书 12.2 版。

X.25 是一个开放的 ITU 建议。

HDLC 框架的基础知识在IETF RFC1662 PPP in HDLC-like Framing 中进行了解释。

【讨论】：