随着现代工业化的进一步发展，信息化建设的需要，工业智能设备或系统与上层信息化系统之间的互联互通已成为必需的。虽说现在的工业现场各类智能设备都提供了多种行业标准协议，但对工业通讯较为熟悉的人都应该有所了解，工业现场的一些控制系统如plc，dcs等用于对外提供标准协议通讯的部分属于选配件，而非原生就支持，而且都需要增加硬件配件+软件配置才能实现行业标准协议的支持。这样的方式带来的一个现实问题就是，当初购买PLC或DCS时，实施工程的人在开发时并未实现行业标准协议的支持。经过了多年后，项目都验收了，而企业又出现了信息化建设的需求，这时候矛盾就出现了。企业的信息化系统需要工业现场设备的数据，但现场设备的数据并未配置实用行业标准协议对外发布。而现场设备厂家提供的软件却是可以从现场设备获取数据的。因此，从现场设备获取数据的路线就有2种方式了。
1. 联系现场设备厂家或者原来的工程实施人员，在现场停机检修的时候将现场设备的配置进行修改，使得现场设备的数据能以行业标准协议对外提供。这种方式对数据采集来说是最理想的方式，安全性及可靠性最高。但从实际操作来说，不少情况下是很困难的，因为时间太长，找不到原来的实施人员，或者由于需要修改的站点多而导致成本高，现场设备厂家也不提供现场设备或系统的私有通讯协议（欧美系的PLC厂家几乎都不会提供设备的私有通讯协议）。
2. 让上层信息化系统厂家来解决此问题，实际上也就是让新系统的厂家自己想尽一切办法从现场设备获取数据，修改现场设备（PLC或DCS）配置的方式一般也不会采用，因为担心带来PLC或DCS问题而担责任，因此上层系统的厂家能干的就是自己想法或拿到现场设备的私有通讯协议或破解其通讯协议。能想任何办法去搞到现场设备的私有通讯协议资料时间对通讯取数来说也是一种安全性和稳定性都很高的方式。而破解私有通讯协议完全就是通过抓包工具抓取现场设备和其上位软件之间通讯报文，然后利用相关工具对报文进行逐字节的分析比较，找出其规律，摸索各个报文之间的不同之处和界面配置参数的关系。所以从私有通讯协议的破解来说，是一件费时费力而且具有较大失败风险的事情，其中的风险就在也许你已经破解了私有协议的95%，但最后的一点由于厂家使用了加密算法而导致完全的失败。
因此，如想破解一个厂家的私有协议，那么必须具备如下几个条件：
1） 有人能提供给你用做模拟测试的现场设备以及尽量多的设备产品资料。
2） 对于现场设备的配置及配置软件的操作自己能搞定或者有人全力配置你。
3） 有软件能和现场设备通讯上，一般来说，设备厂家自己的上位软件都没有问题，于是你也必须对设备厂家的上位软件知道如何使用或有人协助你。
4） 厂家的私有协议是明文类协议，而不是加密类协议。
5） 足够多的时间。
如果以上条件具备，就可以试一试破解私有通讯协议了。开始之前，先将协议分析的相关工具备好。我自己使用的工具如下：
1） 通讯报文抓取工具，串口协议使用AccessPort，以太网上的协议使用Wireshark。
2） 文本比较工具Beyond Compare。
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条中的一样，如遇到应用层数据完全相同的报文，那么应该是协议中的确认帧一类的，如果遇到由于上层组态软件的设置参数变化而变化的，那么就和数据有很大关系了。有关后续报文的分析就不一一详述了。最终的结果算是对向PLC读取数据的私有通讯协议有了较为全面的了解。
最后想说的是，对工业的私有通讯协议的破解是一个繁琐且需要极大耐心的事情。能不能破解主要还是看此私有协议的复杂程度及是否存在不可逆的加密算法，如是明文类通讯协议，一般都可破解，需要的是时间和耐心，而对于加密的通讯协议，一般就选择放弃吧。