我有一个带RS232端口的硬件设备，以及一个与之通信的Windows（XP）应用程序。除了基本串行以外，没有操作系统级别的驱动程序，因此所有解码都在应用程序中完成。日志文件，并进行一些perl后处理（解析出
IRP_MJ_(READ|WRITE)事件以获取原始字节转储）。由此我获得了基本的有线协议详细信息（波特率，设置等）
消息似乎采用
{ $body }\n格式，其中发送的命令通常在正文中为单个字节或2个字节，响应则复杂得多。它们跨越多条消息并出现具有其他结构，例如：
Header（
{IDCOMPLIANCE ...}）元数据？ （
{SA...}）数据[+]（{
DL20...））数据结尾指示符（
{TE5186}）实际示例如下：
> {C}\x0D
< {IDCOMPLIANCE\x20\x20\x20\x20\x20\x20D245}
{SA001FD8BL0001C061BC}
{DL20I000000V80050300DE076A0012000400AF002400FF030300DE0700000000010003000000B883}
{DL20I000020VFF140200DE070900010001000D000100FF0C0200DE076E006E000300A5075904C953}
{DL20I000040VFF0B0200DE07120111010700DE11E406FF0A0200DE070401030105008D12640B3B0C}
{DL20I000060VFF090200DE07F400F400050046112F0AFF080200DE076C016C0107003419950D7181}
{DL20I000080VFF070200DE0753015101060063172A0CFF060200DE07D400D3000A00BE0DF504877D}
{DL20I0000A0VFF050200DE07F200F200040047117309FF040200DE071601150107000414F10C292B}
{DL20I0000C0VFF030200DE07D400D4000500260FC108FF020200DE07B900B90006004C0D26083825}
{DL20I0000E0VFF010200DE07B601B60107001E21F718FF1F0100DE0710010C010900B913150DE89C}
{DL20I000100VFF1E0100DE0785017F010900531A2F0EFF1D0100DE071B01180108001C146D0CE542}
{DL20I000120VFF1C0100DE077E007B0005009C092107FF090100DE0754000100020008000100A748}
{DL20I000140V0000000000000000000000000000000000000000000000000000000000000000D71C}
{DL20I000160V0000000000000000000000000000000000000000000000000000000000000000725F}
{DL20I000180V000000000000000000000000000000000000000000000000000000000000000010A5}
{DL20I0001A0V00000000000000000000000000000000000000000000000000000000000000004CC1}
{TE5186}
我还可以访问控制应用程序，我可以将某些数据（可能或可能不完全是通过有线方式记录的日志）记录为CSV等友好格式。
问题
鉴于我到目前为止的进展主要是将CSV输出与焊丝输出相匹配，尝试更具侵略性地研究实际应用是否有任何价值？
我对asm，Windows二进制文件和Windows调试的经验很少，但是似乎可以静态地或在运行时在二进制文件中四处查找，并寻找解码发生的地方。 br />如果我能找到它，我希望可以拼凑足够的asm以了解它是如何生成/解析的，并将其映射到我实际看到的内容。
问题实际上是找到[解码] rou我的知识有限的尖齿。
两种方法向我建议：在调试器中运行，弄清楚如何在串行端口读/写上设置断点，并从那里逐步查找解码逻辑。
装入反编译器中，然后（a）跟踪串行读/写操作，或（b）寻找出现在输出CSV中的已知字符串，然后向后处理使用它们的代码。
我目前一直在使用Windows的OllyDbg以及Hopper Decompiler的演示版，如果可以使用的话，它是可以承受的。
IDA或Hex-Rays会很好，但是除非有什么理由（例如“解码神秘协议”按钮）可以证明其合理性，否则我的预算会有点不足。
所以，
有人可以识别上述格式吗？
是否有更好的RS232嗅探工具（实际上是通过USB串行适配器）？我发现USBpcap（hxxp：//desowin.org/usbpcap/）可以生成Wireshark跟踪，但是对它进行挖掘以获取实际的串行数据非常繁琐，而且捕获不是实时的。
人们会建议我下一步会移动（继续攻击黑匣子的csv / wire-data，反编译还是调试？）
如果进行调试，ollydbg是否可以在读取串行端口时断点（以及在哪里可以找到有关如何使用n00b级文档的信息）这样做吗？）
如果进行反编译，我应该采取什么方法（从端口读取前进，还是从csv / strings前进？同样，指向该操作的指针也很棒。） ，特别是对
{DL20...}消息的结构有何启发？我怀疑它分解了类似以下内容： 。某种长度？ 2
每个条目都包含一个日期（dd / mm / yy，可能是一种奇怪的格式，例如“自罗马沦陷后的第一个夏至以来两周的分数），以及一堆整数和小数（固定点而不是浮点数， ）
我认为有些字段是16位的，并且是little-endian（条目＃2的后4个字节为0x0459，它与观察到的数据匹配）
DL20-不确定，可能是校验和还是CRC？尝试了一些明显的标准，尽管这些标准不匹配，并且可能遍及整个数据包或仅遍及数据。 2显然] #1 楼
我的猜测：DL20I000000V80050300DE076A0012000400AF002400FF030300DE0700000000010003000000B883
^^ ^ ^ ^^^^
|| Addr Data CRC16
|` Length
` Data tag
D用于数据
L20用于0x20或32个十六进制字节，或64个十六进制数字（请注意，每行增加0x20，同时支持L20作为长度，支持I作为地址） “全0”除外，每个都有唯一的校验和，表明地址是公式的一部分。 IHEX没有字母。 SREC与您拥有的类似。