前言

最近有個工控安全大賽，老板讓我們參加。雖然參賽的經驗少，但誰叫我們是研究流量分析的呢，硬著頭皮也得上。于是乎開始找題刷，然而互聯網上工控CTF的題不多，只能是有一道就狠勁兒地啃一道。“工匠安全實驗室”（ID：icsmaster）在今年年初解析了一道工控業務流量分析題（見傳送門），遂啃之。

正文
我們先來理一理他的解題思路，總結如下：
先過濾出屬于工控業務的流量包，在wireshark中直接進行端口過濾，命令為tcp.port in {102 502};
數據包中存在大量重傳的包，懷疑有中間人攻擊的可能，編寫腳本，判斷是否存在中間人攻擊行為；
排除S7comm中存在flag的可能；
根據modbus協議數據包中出現的非常見功能碼，判斷并找出異常數據包；
對異常數據包的data字段進行解密。
本人所做的工作主要集中在第二、四、五點。一是進一步將解題思路進行腳本話；二是提出了新的檢索異常數據包的方法；三是對data字段的解密做了更進一步的解讀。
在第二點中，原文利用scapy庫來排查中間人攻擊的數據包，代碼如下：

可以看到，通過檢測重復seq和ack號來查找重放的數據包。本人重敲了這段代碼，在運行的過程中，發現這段代碼的運行時間很長，甚至會出現報錯，因此換了一個庫，利用dpkt庫重寫了這個代碼，見腳本midder_check.py，如下：
運行方式：python ./check_middler.py  pcapfile

同樣的功能，但這段代碼的執行效率快得多。
在第四點，本人提出了新的找異常數據包的思路。根據工控業務流量的特點，只要工業生產的模式固定，數據包按照一定地規律出現，那么其中傳送的數據包種類和數據包載荷數據一定是固定的。可以從最簡單的數據包長度的類型著手，本人剛好在此有所積淀，可以訪問這篇文章，拿來小改一下，即可使用。見腳本ics_packets_analysis.py運行該程序：
運行方式：python ./ics_packet_analysis.py –pcapfile=./ics.pcapng -i

可以看到，這里有很特殊的一個數據包出現，輸入這個長度，對該數據包進行進一步排查，有：

直接打印出了這個數據包載荷內容且將這個數據包以pcap的形式存儲下來，用wireshark打開，剛好是原文中找出的異常數據包，如下圖所示。 

直接打印出了這個數據包且將這個數據包以pcap的形式存儲下來，用wireshark打開，剛好是原文中找出的異常數據包，如下圖所示。

下次要再出這類題，用這個腳本一下就跑出來了，是不是很爽。下面就是對data數據的解密了。
第五點，要對這個陌生的字符串解密，一開始確實沒啥思路，好在原文給出了解密腳本，見腳本format_transfer.py。

其中的關鍵代碼是：chr(int(‘{:08b}’.format(ord(data))[::-1], 2))。這句話代表將data中每一個16進制數轉換成二進制并將二進制序列倒序排列并得出倒序的數值，最后將這個數值轉換成字符串（其實倒序的這個數值即是ASCII表中的值了）。
本人試著總結了一下對字符串解密的解題思路，由于flag一般是一串可讀的字符串。要將一串不可讀的16進制數，轉換成可讀的一串數，大概率從bit位的順序做文章，更難一點，解密出的字符串有可能是編碼的字符串，再解一次碼就行了。如何解碼呢？在github上我找到了一份較全的解碼腳本，該腳   本支持如下所示有這幾種解碼方式：

運行方式：python3 ./try_decodings.py ZmVuZ3poZW5nMTIzNTY=

下次如遇到需要解碼的字符串，即可用此腳本自動完成了。
本人所有的腳本程序，見github：https://github.com/scu-igroup/ctf_ics_traffic
總結
最后，稍作總結一下，由于工業生產模式固定，其中傳送的工控網絡數據包類型是有規律可循的，因此要從工控業務流量中找出異常的數據包并不難。需要注意的是，flag可以藏在一個數據包中，也可以藏在幾個數據包中，在幾個數據包中的時候，做一次字符串拼接就行了。字符串解碼這一塊，筆者只能說，理清思路，多多嘗試，相信做得多了，自然會有感覺。最后，師傅們如果有更多的套路，歡迎一起討論。