S7CommPlus协议研究之动态调试

在完成了对V4.1.3固件版本的研究后，此次使用更高的固件版本作为研究目标，基本环境配置如下：Win7x64虚拟机、

PLC：S7-1200 , 6ES7 212-1BE40-0XB0

Firmware: V4.2.3

Software：TIA Portal V14

S7Comm-Plus Wireshark dissector plugin: V0.0.8

3.1、数据一致性校验

通过TIA软件操作PLC，对其进行启动/停止操作，并对通信过程进行抓包，可看到相关数据如下：

数据中有一个长度为32字节的“Intergity part”字段，该字段即为数据一致性校验，其通过某种算法，以“Data”字段数据为对象进行某种运算，最终得到32字节的校验值，只有当该校验值计算正确、PLC校验通过后，才会执行操作指令如启动/停止，否则，即使与PLC建立了通信，也无法进行实质操控。

“Intergity part”字段是如何计算得到的呢？从前期的文章中可以找到一些信息。绿盟2017年的文章表述如下：

文章指出该字段的计算与Session ID有关，加密过程使用了一个极为复杂的算法，图示中的函数输入参数只有a1,a2，且没有其他更多详细新。

再看2019年的文章：

文章指出：Integrity保护算法基于session key和通信内容（即上面提到的“Data”字段）进行MAC值计算（即HMAC-SHA256算法）计算得出，而session key的获得又与Algorithm 1有关，可以看到session key的计算过程比较复杂：f函数以challenge和8作为参数进行运算，结果拼接上challenge内容，基于KDK进行HMAC-SHA256算法运算，得到的结果取前24个字节即为session key。所以“Integrity part”字段计算方法方式可以描述如下：

Session key = Hmac-sha256KDK (f(challenge,8)||challenge)[:24]

Integrity part = Hmac-sha256Session key (Data)

由此可知，计算“Integrity part”的关键在于获取到Session key和KDK。

3.2、动态调试

由于绿盟文章并未提到HMAC-SHA256算法用于计算“Integrity part”内容，其截图中给出的分析函数位置可作为参考，用于查找Session key计算的位置：

进一步跟踪调试之后，找到了Session key的计算位置：

此函数有三个参数：其中一个指向的内容为实际用到的16字节challenge:

另一个参数为24字节内容，即文章中指出的24字节KDK，因此与文章中描述的Session key计算过程吻合，进一步分析计算过程，可以推测到：sub_5E2F22ED即为文章中描述的f函数，此过程计算为西门子私有算法。第三个参数即为函数的输出了，即Session key计算结果。

使用IDA静态分析看看f函数到底有些什么内容：

居然复杂到IDA无法打开的地步？百度了一通关于IDA如何解决上述错误问题，最终还是没能解决，或许是IDA的版本（v6.8）过低？更换了一个7.2再次尝试，F5之后的代码超过1600行，各种函数、数据运算，到此我们可以忽略这一个函数了。

通过调试定位了函数位置以及参数传递，接下来就是构造正确参数进行函数调用，获取Session key, 进而对交互数据计算出“Integrity part”值了。

3.3、实验验证

西门子新版本的S7-1200、S7-1500均使用了新的S7Comm-Plus通信协议，想要对PLC进行任意攻防测试，基本过程分两步走：成功握手建立通信、正确计算“Integrity part”进行具体操控。本次系列文章完成了协议分析、动态调试和演示测试，希望对同行研究者有所裨益，不当之处还请批评指正。

原文来源：安全客