Serial port 反向工程串行数据包

我有一个设备连接到PC vie串行端口rs-232。 该设备在接收到来自串口的命令后发送数据，我嗅探了通过该端口的数据流，几乎完全了解了数据包的结构，但至少有两个重要字段我无法确定

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

0baa00000200039540330137732904020033000005534d6c07a567a73e15040701125600043853048a5c085500000000e940406f00039540330058388900020033000005534d6c07b501b4f01504070113020004fd1d040342155500000000e940406f0002009d0a03004a3030313733353530303830343630303830373131313030323415040701210801001035390000000000000000d3a7226c287472874b2a216a000000000000000000ab04

0b6601000600039540330137732904020033000005534d6c07a567a73e15040701125600043853048a5c085500000000e940406f00039540330058388900020033000005534d6c07b501b4f01504070113020004fd1d040342155500000000e940406f00039540330137732904020033000005534d6c07a567a73e15040702174901043853048a5c085500000000e940406f00039540330058388900020033000005534d6c07b501b4f01504070218010104fd1d040342155500000000e940406f00039540330137732904020033000005534d6c07a567a73e15040703301002043853048a5c085500000000e940406f00039540330058388900020033000005534d6c07b501b4f01504070331280204fd1d040342155500000000e940406f000600a10a03004a303031373335353030383034363030383037313131303032341504071152520100103539000000000000000094b5d2c94a11672acaa0abec0000000000000000006a85

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

0baa00000200039540330137732904020033000005534d6c07a567a73e15040701125600043853048a5c085500000000e940406f00039540330058388900020033000005534d6c07b501b4f01504070113020004fd1d040342155500000000e940406f0002009d0a03004a3030313733353530303830343630303830373131313030323415040701210801001035390000000000000000d3a7226c287472874b2a216a000000000000000000ab04

0b6601000600039540330137732904020033000005534d6c07a567a73e15040701125600043853048a5c085500000000e940406f00039540330058388900020033000005534d6c07b501b4f01504070113020004fd1d040342155500000000e940406f00039540330137732904020033000005534d6c07a567a73e15040702174901043853048a5c085500000000e940406f00039540330058388900020033000005534d6c07b501b4f01504070218010104fd1d040342155500000000e940406f00039540330137732904020033000005534d6c07a567a73e15040703301002043853048a5c085500000000e940406f00039540330058388900020033000005534d6c07b501b4f01504070331280204fd1d040342155500000000e940406f000600a10a03004a303031373335353030383034363030383037313131303032341504071152520100103539000000000000000094b5d2c94a11672acaa0abec0000000000000000006a85

作为示例，我确定第一个数据包的数据包结构：

标记为？？？的文件我不知道是什么，需要猜一下。 有效负载数据分组可以是不同的计数。 若我编辑数据包内部的任何字节并重新计算最后一个CRC16，程序将接受数据包，但会显示其已损坏的消息。若我在不重新计算CRC16的情况下编辑任何字节，程序将拒绝该数据包

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

我将非常感谢您的帮助

更新1

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

0b6601000600039540330137732904020033000005534d6c07a567a73e15040701125600043853048a5c085500000000e940406f00039540330058388900020033000005534d6c07b501b4f01504070113020004fd1d040342155500000000e940406f00039540330137732904020033000005534d6c07a567a73e15040702174901043853048a5c085500000000e940406f00039540330058388900020033000005534d6c07b501b4f01504070218010104fd1d040342155500000000e940406f00039540330137732904020033000005534d6c07a567a73e15040703301002043853048a5c085500000000e940406f00039540330058388900020033000005534d6c07b501b4f01504070331280204fd1d040342155500000000e940406f000600a10a03004a303031373335353030383034363030383037313131303032341504081008320100103539000000000000000021c3e1c0e04d909a7cf512b20000000000000000008b61

0b6601000600039540330137732904020033000005534d6c07a567a73e15040701125600043853048a5c085500000000e940406f00039540330058388900020033000005534d6c07b501b4f01504070113020004fd1d040342155500000000e940406f00039540330137732904020033000005534d6c07a567a73e15040702174901043853048a5c085500000000e940406f00039540330058388900020033000005534d6c07b501b4f01504070218010104fd1d040342155500000000e940406f00039540330137732904020033000005534d6c07a567a73e15040703301002043853048a5c085500000000e940406f00039540330058388900020033000005534d6c07b501b4f01504070331280204fd1d040342155500000000e940406f000600a10a03004a303031373335353030383034363030383037313131303032341504071152520100103539000000000000000094b5d2c94a11672acaa0abec0000000000000000006a85

---

我不能在这方面透露太多，但我可以提供这么多

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

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

您将注意到，在第二个数据包中，在末尾有额外的00字节，并且比第一个数据包小。如果将这些额外的00字节下移到，则两个数据包中都将有9个字节：

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

---

需要进行更深入的分析，以找出这种重复性，并了解这00个字节是否具有它们最初基于的位置以及所有其他已知字段的含义。

除非您的时间几乎空闲，否则您只需去购买规格。如果你有几千美元的预算，你肯定应该成为DLMS-UA用户协会的成员，这样你就可以访问所谓的彩色书籍——DLMS组织本身的基本真理标准

彩色书籍的摘录如下。这些应该包括一些基本知识

感兴趣的核心书籍将是蓝皮书和绿皮书，这些书籍通过ISO/IEC标准化过程向非成员开放。引用的相关国际标准如下：

，DLMS/COSEM应用层。2017年第3.0版与绿皮书第8.3版一致； ，COSEM接口类。2017年第3.0版与蓝皮书第12.2版一致； ，OBIS对象识别系统2017年3.0版符合蓝皮书12.2版。 这是国际电联的公开建议

---

HDLC成帧的基本原理在中进行了解释。

您需要帮助的具体内容是什么？你想知道神秘的领域是什么吗？你有一个有趣的问题，展示了大量的工作，但我不确定堆栈溢出是否是寻求此类帮助的地方。谢谢你的回答，我请求帮助确定哪些字段可能是：从开始的第二个和第三个字节，例如aa00；6601和最后一个零序列之前的最后14个字节。感谢您的分析，我在提问之前确定的每个块的大小，这些数据包是来自设备的原始数据包，程序接受它们是正确的。我可以补充一点，如果我在不同的时间从设备请求相同的信息-最后的日期和时间将是我请求数据的时间，所有字段直到D3A72226C287472874B2A216A结束14个唯一字节将是相同的。我认为这是一种从设备名块开始的散列，至少不同的数据包时间给出了这14个字节的不同序列。我想如果我能理解这些字节的算法，我就能得到正确的数据包。我不需要从头开始制作整个数据包，我只需要从设备中获取信息，编辑它，添加，删除内部有效负载并将其发送到程序。我想说的是，我不需要反转所有字节，因为其中一些字节来自设备（如0b）。Mb->可以吗？现在我正在尝试至少更改数据包请求时间字段中的秒数，以确定14字节的算法，但如果我自己更改，程序将说明数据已损坏。我有两个相同的数据包，具有相同的有效负载等，但它们在请求时间域不同，也许，这将帮助您帮助我找到算法。我在问题更新1中添加了数据包。如果仅通过查看原始字节就无法识别正在使用的哈希算法，即使它是一个哈希。我建议您找出发送此数据的设备类型，然后直接联系制造商，询问有关此协议的详细信息。制造商拒绝有关协议的请求。。。在该制造商提供的一些其他设备概述中，介绍了他们使用DLMS/COSEM通信标准的信息，以及一些关于HDLC和x.25之类的词语，但我不确定我的设备，没有此类规范。还有，也许吧 它不是散列，而是FCS帧检查序列？

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