背景

工作上由于需要對(duì)一些DPI的規(guī)則進(jìn)行維護(hù)，很多時(shí)候需要對(duì)一些非標(biāo)準(zhǔn)協(xié)議進(jìn)行逆向分析，從而找到非標(biāo)準(zhǔn)協(xié)議中的可識(shí)別內(nèi)容。例如典型的是各種游戲協(xié)議。

因此多多少少接觸到了一些協(xié)議的逆向分析工作。協(xié)議逆向目前并沒有一個(gè)靠譜的工具可以使用，主流的思路還是使用大量的數(shù)據(jù)，進(jìn)行自動(dòng)化對(duì)比分析+人工干預(yù)。

本文總結(jié)一下平時(shí)在協(xié)議逆向上的一些心得。

協(xié)議逆向簡介

一個(gè)協(xié)議中包含數(shù)據(jù)報(bào)文和控制報(bào)文，對(duì)于單個(gè)報(bào)文，分析最主要的工作就是把報(bào)文分割成不同的域，每個(gè)域都有自己的長度，名稱，意義，數(shù)據(jù)類型，各個(gè)域的類型，長度，相互關(guān)系，時(shí)序就構(gòu)成了協(xié)議的語法。

協(xié)議逆向本身比較依賴先驗(yàn)經(jīng)驗(yàn)，以及對(duì)數(shù)據(jù)的敏感，在協(xié)議逆向工作前加強(qiáng)對(duì)核心數(shù)據(jù)的收集，能顯著提升逆向的成功率?？傮w而言，這是一個(gè)比較依賴個(gè)人經(jīng)驗(yàn)和技巧的工作，以下介紹為基本思路。

協(xié)議逆向場(chǎng)景

1，網(wǎng)絡(luò)對(duì)抗

2，惡意軟件分析

3，漏洞挖掘，其中自動(dòng)化挖掘漏洞主要依靠模糊測(cè)試，模糊測(cè)試分為白盒模糊測(cè)試，基于模型的模糊測(cè)試，基于反饋的模糊測(cè)試其中基于模型的模糊測(cè)試主要是利于文件格式和協(xié)議格式構(gòu)造測(cè)試用例，所以也依賴于協(xié)議分析。

4，協(xié)議重用，例如跨平臺(tái)的文件共享samba就是逆向了微軟的smb協(xié)議

5，網(wǎng)絡(luò)管理，比如家庭防火墻的應(yīng)用識(shí)別和應(yīng)用攔截功能

協(xié)議逆向的幾種方式：

協(xié)議格式提取技術(shù)包括基于網(wǎng)絡(luò)流量的協(xié)議逆向，和基于執(zhí)行軌跡的協(xié)議逆向，基于交互式的協(xié)議逆向方式。

基于網(wǎng)絡(luò)流量的協(xié)議逆向

基于網(wǎng)絡(luò)流量的協(xié)議逆向有以下幾個(gè)局限性

①在僅有正例的情況下，無法得到絕對(duì)準(zhǔn)確的協(xié)議格式

②對(duì)于加密或則壓縮后的協(xié)議，無法逆向

③分析結(jié)果依賴于樣本覆蓋（比如游戲協(xié)議的分析，可能需要區(qū)分不同平臺(tái)，不同角色，不同區(qū)服等等的樣本）

但是有以下優(yōu)點(diǎn)

①時(shí)效性強(qiáng)，因?yàn)閷儆陟o態(tài)分析，成本比較低，快速得出結(jié)果

②對(duì)終端依賴比較小，不需要獲得客戶端程序

③通用性比較強(qiáng)

在實(shí)際的應(yīng)用識(shí)別規(guī)則提取中，用的比較多的也是這種方式。詳細(xì)逆向思路下下文。

基于執(zhí)行軌跡的協(xié)議逆向

基于執(zhí)行軌跡的協(xié)議逆向，一般是需要獲取二進(jìn)制文件，對(duì)二進(jìn)制文件進(jìn)行逆向，獲取協(xié)議格式或者加密密鑰等。如果二進(jìn)制文件可以執(zhí)行，可以進(jìn)行動(dòng)態(tài)調(diào)試。由于在實(shí)際的應(yīng)用識(shí)別規(guī)則提取工作中，針對(duì)的都是apk，都做了混淆和加殼處理，逆向難度很大，這方面我也不擅長。包括逆向工作實(shí)際耗時(shí)很多，也不適合在應(yīng)用識(shí)別的規(guī)則提取工作中使用，所以不做描述。

基于交互式的協(xié)議逆向

交互式的協(xié)議逆向在目前實(shí)際工作中，是作為基于網(wǎng)絡(luò)流量協(xié)議逆向的補(bǔ)充。這種方式的前提是可以通過發(fā)送指定數(shù)據(jù)包的方式與服務(wù)器交互，根據(jù)服務(wù)器的返回內(nèi)容來確定數(shù)據(jù)包的協(xié)議格式。這個(gè)步驟目前可以通過手動(dòng)/自動(dòng)化的方式進(jìn)行。詳細(xì)逆向思路下下文。

如何基于網(wǎng)絡(luò)流量進(jìn)行協(xié)議逆向

目前工作中用到的主要是基于網(wǎng)絡(luò)流量的協(xié)議逆向分析方式。前提條件是先對(duì)需要逆向協(xié)議的APP進(jìn)行抓包，抓包的適合需要配合實(shí)際使用場(chǎng)景。如針對(duì)一款游戲進(jìn)行抓包的時(shí)候，要抓完整的從啟動(dòng)—登錄—進(jìn)入游戲的全過程。

另外由于基于網(wǎng)絡(luò)協(xié)議這種方式的特性，抓包的時(shí)候盡量覆蓋多種不同場(chǎng)景，例如不同的平臺(tái)（android/ios），不同的登錄id，不同的版本之間進(jìn)行比對(duì)。

基本的流程如下圖，根據(jù)需要，可以選擇使用自動(dòng)化系統(tǒng)，或者直接手動(dòng)進(jìn)行。

由于自動(dòng)化輸出結(jié)果后，也需要人工進(jìn)行核對(duì)，調(diào)整，所以這里主要介紹人工分析的方式和思路。

第一步，定位需要分析的核心數(shù)據(jù)流

可以根據(jù)以下參數(shù)從pacp中定位需要進(jìn)行協(xié)議逆向的核心數(shù)據(jù)流，直接將pcap導(dǎo)入腳本運(yùn)行既可輸出。如果要人工分析的話，也需要參考一下參數(shù)。

#?print?'數(shù)據(jù)流時(shí)間%s'?%?str(tcp_time)

#?print?'數(shù)據(jù)包數(shù)量%s'?%?str(len(pkt_list))

#?print?'大包比例%s'?%?str(largepkt_proportion)

#?print?'發(fā)送數(shù)據(jù)包平均大小%s'?%?str(srcavg)

#?print?'返回?cái)?shù)據(jù)包平均大小%s'?%?str(repavg)

#?print?'發(fā)送數(shù)據(jù)包最小值%s'?%?str(srcmin)

#?print?'返回?cái)?shù)據(jù)包最小值%s'?%?str(repmin)

#?print?'發(fā)送包高延遲數(shù)量%s'?%?str(srcdelaynum)

#?print?'返回包高延遲數(shù)量%s'?%?str(repdelaynum)

#?print?'平均包間隔%s'?%?str(avgdelay)

#?print?'平均發(fā)送包間隔%s'?%?str(avgintervalsrc)

#?print?'平均返回包間隔%s'?%?str(avgintervalrep)

第二步，從抓包場(chǎng)景和抓包文件中確定關(guān)鍵字

關(guān)鍵信息，一種是抓包場(chǎng)景下的信息，包括網(wǎng)絡(luò)環(huán)境信息等。如客戶端的ip，端口號(hào)，服務(wù)端的ip,端口號(hào)，協(xié)議發(fā)生時(shí)的時(shí)間戳等信息。具體獲取哪些指定信息，有一個(gè)預(yù)設(shè)的配置文件。獲取成功后，將這些信息加入關(guān)鍵信息庫1。

例如針對(duì)一條數(shù)據(jù)，可以獲得該條數(shù)據(jù)的關(guān)鍵信息如下：

客戶端ip:?192.168.137.151

服務(wù)端ip：106.14.176.31

客戶端端口：?60857

服務(wù)端端口：16100

協(xié)議發(fā)生時(shí)的時(shí)間戳：1609210534

另外一種是在pcap文件中包含的關(guān)鍵信息，這些信息是從其他數(shù)據(jù)流中提取出來的。提取方式可以通過腳本，用tf-idf算法直接輸出結(jié)果，也可以人工提取。這些信息可能包含在協(xié)議中，來進(jìn)行協(xié)議逆向的時(shí)候，猜測(cè)語義的時(shí)候優(yōu)先考慮這些信息。

例如針對(duì)數(shù)據(jù)包通過機(jī)器學(xué)習(xí)算法提取出來的關(guān)鍵數(shù)據(jù)如下：

username=qzPicd

vuin=310290686

version=3.1.1.2232

platform=30403

第三步：先確定常見的協(xié)議格式字段

分隔符字段，用來標(biāo)識(shí)可顯示字符串的結(jié)束

長度字段：取值為后續(xù)某一字段或者復(fù)合字段的字節(jié)長度

計(jì)數(shù)字段：取值為后續(xù)某一復(fù)合字段中元素重復(fù)次數(shù)

關(guān)鍵字字段：聲明報(bào)文，復(fù)合字段或字段的類型（例如hello,request）

格式標(biāo)識(shí)字段：指示后續(xù)某一復(fù)合字段的格式

校驗(yàn)和

IP網(wǎng)絡(luò)地址

協(xié)議實(shí)體身份識(shí)別，也就是cookies

主機(jī)名

文件名，路徑名

網(wǎng)絡(luò)端口

時(shí)間戳

data，協(xié)議實(shí)體使用的數(shù)據(jù)，可能就是單純的用戶數(shù)據(jù)

這些字段相對(duì)來說比較好確定，如果有滿足條件的先確定這些字段，從而得到協(xié)議的初步格式。自動(dòng)分析的方式可以參考findlenth.py中的邏輯。手動(dòng)的話，比較依賴個(gè)人經(jīng)驗(yàn)。

第四步：通過序列對(duì)比和交互式的協(xié)議逆向，進(jìn)一步分析協(xié)議格式以及每一個(gè)字段語義/取值范圍

序列對(duì)比，這個(gè)自動(dòng)化腳本會(huì)直接輸出結(jié)果。如果手動(dòng)進(jìn)行的話，需要預(yù)先挑選出兩個(gè)相同場(chǎng)景下的協(xié)議內(nèi)容，比較典型的如下：

27:74:00:00:48:00:00:00:00:00:02:00:00:00:0d:00:00:00:1c:00:00:00:00:00:00:00:ba:00:00:00:28:32:31:36:38:65:34:61:39:36:36:33:30:36:64:63:66:34:65:30:33:31:32:65:31:34:30:66:35:32:30:63:39:35:33:31:37:62:34:30:66:00:00:00:04:00:00:00:22

27:74:00:00:48:00:00:00:00:00:02:00:00:00:0e:00:00:00:1f:00:00:00:00:00:00:00:be:00:00:00:28:32:31:36:38:65:34:61:39:36:36:33:30:36:64:63:66:34:65:30:33:31:32:65:31:34:30:66:35:32:30:63:39:35:33:31:37:62:34:30:66:00:00:00:04:00:00:00:22

這兩個(gè)協(xié)議在14:1?18:1?25:1?三個(gè)位置有區(qū)別，根據(jù)之前進(jìn)行的常見協(xié)議格式字段分析，可以得知這三個(gè)字段比較可能是控制字段，或者可變的遞增字段。

再結(jié)合實(shí)際抓包時(shí)候的場(chǎng)景，比如這兩個(gè)協(xié)議內(nèi)容不同可能是因?yàn)槠脚_(tái)不同？用戶id不同？操作場(chǎng)景不同？渠道號(hào)不同？版本不同？等等，最終可以人工分析出來14:1?18:1?25:1?這三個(gè)位置，是代表版本號(hào)的字段。

補(bǔ)充交互式的協(xié)議逆向

這個(gè)步驟主要是在完成了上面步驟后，已經(jīng)有了初步的協(xié)議格式，不過有部分語義或者部分字段的取值范圍無法確定。如果這個(gè)時(shí)候服務(wù)器處于一個(gè)可以交互的狀態(tài)，那么可以通過手動(dòng)制造數(shù)據(jù)包的方式，探測(cè)服務(wù)器返回，通過服務(wù)器返回來確定字段的語義，以及取值范圍。

例如一段未知的網(wǎng)絡(luò)協(xié)議，客戶端發(fā)送的數(shù)據(jù)包A如下：

3366000800081001000000000100000052000000000203000000ff000000651002030000001d6f30466e5876726b326b525a53734a4e4e7047326b63496e4f5a4b3100000000000000000000000100000000

發(fā)送這段網(wǎng)絡(luò)數(shù)據(jù)后，服務(wù)器響應(yīng)的數(shù)據(jù)包B是：

336600080008100201000000010000003000000010021048614a41394858517638476b5556573800000004000000000061c1d9b1276ba954cb3d4b438e236251

首先針對(duì)發(fā)送的數(shù)據(jù)包A，簡單劃分區(qū)域，針對(duì)每一個(gè)區(qū)域，將原有數(shù)據(jù)更換為其他數(shù)據(jù)。

如A開頭的336600,變更為000000,則重新構(gòu)建數(shù)據(jù)包A1為

0000000800081001000000000100000052000000000203000000ff000000651002030000001d6f30466e5876726b326b525a53734a4e4e7047326b63496e4f5a4b3100000000000000000000000100000000

將數(shù)據(jù)包A1發(fā)送到服務(wù)器。獲取服務(wù)器結(jié)果的時(shí)候發(fā)現(xiàn)服務(wù)器沒有響應(yīng)此請(qǐng)求。

則初步認(rèn)定或者更加確定336600為協(xié)議的定義字段，此協(xié)議固定以336600開頭，如果不以336600開頭，則服務(wù)器不會(huì)做出響應(yīng)。

同理，通過此方式可以確定其他的字段。比如懷疑一處字段為用戶的cookies，那修改cookies后，服務(wù)器預(yù)期的返回應(yīng)該是可以響應(yīng)，但是用戶數(shù)據(jù)相關(guān)的data段為空，或者是返回一段報(bào)錯(cuò)信息。如果發(fā)送后返回符合了預(yù)期，那么可以確定之前的語義推測(cè)是正確的。

第五步：對(duì)比場(chǎng)景、倒退到場(chǎng)景，核實(shí)逆向結(jié)果的準(zhǔn)確性

這一步的目的是確定之前分析的協(xié)議格式、語義的正確性。由于應(yīng)用識(shí)別和應(yīng)用攔截都需要很高的準(zhǔn)確度，如果針對(duì)于協(xié)議的某一個(gè)字段的格式、語義分析錯(cuò)誤，可能會(huì)導(dǎo)致無法識(shí)別，或者更嚴(yán)重的出現(xiàn)大范圍的誤識(shí)別。

比如之前外網(wǎng)出現(xiàn)過提取的規(guī)則被mqtt協(xié)議誤命中的問題，由于mqtt協(xié)議在安卓手機(jī)上使用還比較廣泛，出現(xiàn)了用戶反饋，就是典型的協(xié)議逆向結(jié)果不準(zhǔn)確，導(dǎo)致識(shí)別規(guī)則出現(xiàn)誤命中的情況。

這一步主要工作，是把上面流程中完成初步分析的結(jié)果，跟實(shí)際的場(chǎng)景做一個(gè)核實(shí)，查看是否存在沖突，增強(qiáng)協(xié)議逆向結(jié)果的可信度。

這部分工作比較依賴于經(jīng)驗(yàn)和技巧，具典型的例子如下

初步認(rèn)定版本信息相關(guān)的協(xié)議字段，需要跟pcap中提取出來的版本信息做核對(duì)

初步認(rèn)定為用戶cookies的，需要配合登錄用戶相關(guān)信息做核對(duì)

初步認(rèn)定為渠道相關(guān)信息的，需要根據(jù)不同的渠道包信息進(jìn)行核對(duì)。