私有工业通讯协议的破解过程

私有工业通讯协议的破解过程在破解之前，先说一说为什么要破解的缘由。

随着现代工业化的进一步进展，信息化建设的需要，工业智能设备或系统与上层信息化系统之间的互联互通已成为必需的。虽说现在的工业现场各类智能设备都供应了多种行业标准协议，但对工业通讯较为熟识的人都应当有所了解，工业现场的一些掌握系统如plc，dcs等用于对外供应标准协议通讯的部分属于选配件，而非原生就支持，而且都需要增加硬件配件+软件配置才能实现行业标准协议的支持。这样的方式带来的一个现实问题就是，当时购买PLC或DCS时，实施工程的人在开发时并未实现行业标准协议的支持。经过了多年后，项目都验收了，而企业又消失了信息化建设的需求，这时候冲突就消失了。企业的信息化系统需要工业现场设备的数据，但现场设备的数据并未配置有用行业标准协议对外发布。而现场设备厂家供应的软件却是可以从现场设备猎取数据的。因此，从现场设备猎取数据的路线就有2种方式了。

1.联系现场设备厂家或者原来的工程实施人员，在现场停机检修的时候将现场设备的配置进行修改，使得现场设备的数据能以行业标准协议对外供应。这种方式对数据采集来说是最抱负的方式，平安性及牢靠性最高。但从实际操作来说，不少状况下是很困难的，由于时间太长，找不到原来的实施人员，或者由于需要修改的站点多而导致成本高，现场设备厂家也不供应现场设备或系统的私有通讯协议（欧美系的PLC厂家几乎都不会供应设备的私有通讯协议）。

2.让上层信息化系统厂家来解决此问题，实际上也就是让新系统的厂家自己想尽一切方法从现场设备猎取数据，修改现场设备（PLC或DCS）配置的方式一般也不会采纳，由于担忧带来PLC或DCS问题而担责任，因此上层系统的厂家能干的就是自己想法或拿到现场设备的私有通讯协议或破解其通讯协议。能想任何方法去搞到现场设备的私有通讯协议资料时间对通讯取数来说也是一种平安性和稳定性都很高的方式。而破解私有通讯协议完全就是通过抓包工具抓取现场设备和其上位软件之间通讯报文，然后利用相关工具对报文进行逐字节的分析比较，找出其规律，摸索各个报文之间的不同之处和界面配置参数的关系。所以从私有通讯协议的破解来说，是一件费时费劲而且具有较大失败风险的事情，其中的风险就在或许你已经破解了私有协议的95%，但最终的一点由于厂家使用了加密算法而导致完全的失败。

因此，如想破解一个厂家的私有协议，那么必需具备如下几个条件：

1）有人能供应给你用做模拟测试的现场设备以及尽量多的设备产品资料。

2）对于现场设备的配置及配置软件的操作自己能搞定或者有人全力配置你。

3）有软件能和现场设备通讯上，一般来说，设备厂家自己的上位软件都没有问题，于是你也必需对设备厂家的上位软件知道如何使用或有人帮助你。

4）厂家的私有协议是明文类协议，而不是加密类协议。

5）足够多的时间。

假如以上条件具备，就可以试一试破解私有通讯协议了。开头之前，先将协议分析的相关工具备好。我自己使用的工具如下：

1）通讯报文抓取工具，串口协议使用AccessPort，以太网上的协议使用Wireshark。

2）文本比较工具BeyondCompare。

3）各种类型数据转16进制的工具。

4）能对报文计算各种检验算法的工具。

本例中，我以一个国外PLC为例来破解它的私有通讯协议，这里的私有通讯协议仅仅设备到数据交换的部分。

1.搭建环境，这款国外PLC设备原生自带以太网口，默认就可使用私有协议读取其寄存器中的数据。搭建环境就根据最简化的方式，电脑与PLC直连，电脑上除了必需的软件，担心装其他任何软件，这样可以避开各种干扰信息。我自己习惯使用洁净的虚拟机系统，在虚拟机的XP系统中安装PLC的编程软件、上位组态软件及网络转包工具Wireshark。

2.刚开头时先在操作系统中检测和PLC之间是否能正常通讯，在使用上位组态软件测试是否能从PLC中猎取到相关数据，一切正常后，再开头抓包分析工作。

3.前两步都正常后，下面就开头抓包了。在上位组态软件中只留下一个IO点，记录现在IO的配置，一般包含功能区、开头地址，数据类型等设置，不同的协议不一样。实际也就是关注界面上可以设置的区域有哪些，待会儿抓取到多条报文后，进行对比分析，看同类型报文中哪些区域在变，哪些区域不变。同时在网络转包工具Wireshark中设置好过滤条件（原来中我对目的端口和源端口进行过滤就可完整无误的将上位软件和PLC之间的通讯完整的抓取到而且不会有垃圾报文），这是必需的，由于假如加上过滤条件，抓到的包成百上千，存在大量无用的信息，那么就无从下手了。下面是抓取的报文截图

4.通过对上位软件的多次停止然后又启动进行多次抓包后，先对多次抓包的报文发送挨次和报文长度进行对比，查找其规律。通过上面两次的抓包（其后只是转变了配置界面的一项配置）可以发觉一些规律，首先是每次开头都是3个固定长度的包，如你对TCP/IP熟识的话，可以看到这是TCP连接的3此握手。然后再看截图中的第4个包和第5个包，发觉两张图上这两个包的长度完全一样，这时候可以对比这两次抓包中的第4个包和第5个包的应用层数据是否完全一样，假如一样，再多次抓包后看每次在TCP连接建立后发送的包和回来的包的应用层数据是否都一样，假如完全一样，基本可以确定是PLC登录验证的报文。

5.接下来连续看后面的报文，通过截图可以观察后面的包都很有规律了，在本次场景的抓包中，基本是每4个包一个循环，很有规律。而且每次抓包看到的都一样，同时我们再去检查PLC中供应数据的地址和上位软件中对应的IO点的数据，看看是否一样，而且是否更随PLC中的数据变化而变化。假如是这么回事，那就恭喜了，破解有向前进了一步。现在进入到对这很有规律的4条报文的分析比较。我将3次分别转包得到的报文的第6条报文的应用层数据分别复制到记事本中，由于这段16进制的报文不长，就没有使用特地的分析工具了，从对3条报文的应用层数据的对比分析，我找到了其中的差异部分。如下图所示，前面部分完全一样，不同的部分已经用红框标注。然后再把每次抓包前对上位组态软件的设置参数列出来，看看是否能找到这个十六进制和设置参数的关系。

很幸运，报文红框中十六进制和上层组态软件的设置参数的关系基本已经确定，根据这种理解，再次在转变上层组态软件的设置参数，然后再次抓包，就可以确定所找到的规章是否正确。本例中的这个报文是从上位组态软件发给PLC的，报文中变化的区域是上层组态软件的设置参数开头地址和恳求的数据长度。

6.接下来的分析方法和第5条中的一样，如遇到应用层数据完全相同的报文，那么应当是协议中的确认帧一类的，假如遇到由于上层组态软件的设置参数变化而变化的，那么就和数据有很大关系了。有关后续报文的分析就不一一详述了。最终的结果算是对