前言

在日常對(duì)客戶端應(yīng)用進(jìn)行安全審計(jì)或者漏洞挖掘的時(shí)候，或多或少都會(huì)涉及到網(wǎng)絡(luò)協(xié)議的分析。而對(duì)于業(yè)務(wù)風(fēng)控安全而言，APP 的網(wǎng)絡(luò)請(qǐng)求往往也代表著終端安全防御水平的上限，因?yàn)榭蛻舳耸钦瓶卦诠粽呤种械?，服?wù)端的業(yè)務(wù)邏輯才是安全的核心兜底保障。

本文是筆者在分析眾多 Android 應(yīng)用協(xié)議的過程中所嘗試總結(jié)的一些經(jīng)驗(yàn)，大部分情況下也可以適用于其他平臺(tái)的終端應(yīng)用，如 iOS、macOS、Windows 等，盡管各個(gè)操作系統(tǒng)中會(huì)存在一些特有的小技巧。

網(wǎng)絡(luò)流量分析

在介紹具體的流量分析方法之前，我們需要先明確流量分析的目的。對(duì)于筆者而言，流量分析的目的通常是為了搞清楚應(yīng)用某個(gè)操作背后實(shí)際的行為。比如對(duì)于 IM 聊天軟件而言，需要了解發(fā)送文本消息、圖片消息、多媒體消息等背后實(shí)際的請(qǐng)求是什么，以梳理其中潛在的攻擊面；對(duì)于社交類應(yīng)用，可能黑灰產(chǎn)最關(guān)心的是賬號(hào)創(chuàng)建、登錄以及點(diǎn)贊等操作背后的協(xié)議，以用于水軍的構(gòu)建；而對(duì)于病毒分析師，可能更關(guān)注樣本與 CC 服務(wù)器之間命令協(xié)議，以嘗試溯源木馬背后的僵尸網(wǎng)絡(luò)?！?/p>

其中木馬病毒的場(chǎng)景相對(duì)特殊，本文更多是針對(duì)商業(yè)應(yīng)用的網(wǎng)絡(luò)流量分析。在分析流量的時(shí)候，我們顯然需要能夠觀測(cè)到目標(biāo)流量的明文。這看似是一個(gè)簡(jiǎn)單的需求，卻并不容易實(shí)現(xiàn)。

首先考慮網(wǎng)絡(luò)協(xié)議的類型，既然是商業(yè)應(yīng)用，那么大部分情況下使用的也是較為通用的網(wǎng)絡(luò)協(xié)議，即 HTTP。但由于面臨運(yùn)營(yíng)商劫持等原因，目前以 HTTP 請(qǐng)求進(jìn)行明文傳輸?shù)膬H是少數(shù)了，TLS 已經(jīng)成為目前網(wǎng)絡(luò)加密的主流。

其次在應(yīng)用層，目標(biāo)請(qǐng)求也有不少是經(jīng)過自行加密的，可以是一個(gè)簡(jiǎn)化版的 ECDH，也可以是隨機(jī) AES 秘鑰 + 內(nèi)置公鑰加密的方式。這對(duì)于第三方而言，并沒有一個(gè)很好的方式進(jìn)行通用解密，只能根據(jù)不同應(yīng)用進(jìn)行 case by case 的逆向分析并進(jìn)行還原。

因此，對(duì)于應(yīng)用層加密的情況姑且先不考慮，在面對(duì)常規(guī) TLS 加密的流量時(shí)，我們最好能夠有一種方法能夠?qū)ζ溥M(jìn)行解密還原。在 TLS 之下并非只有 HTTP，也有部分使用了 MQTT、Websocket 等協(xié)議的請(qǐng)求，必要時(shí)也需要考慮在內(nèi)。

因此，我們的應(yīng)用網(wǎng)絡(luò)流量分析目標(biāo)，又可以分解成兩個(gè)小目標(biāo):

1. 1. 目標(biāo)應(yīng)用流量截取(捕獲)；

2. 2. 目標(biāo)應(yīng)用流量解密(TLS 解密)；

當(dāng)然，實(shí)際的流量分析并不一定需要兩個(gè)目標(biāo)同時(shí)達(dá)成。在某些場(chǎng)景下，可以僅僅通過解密觀察到目標(biāo)的請(qǐng)求數(shù)據(jù)，并通過日志打印等方式展示出來。

流量抓取

首先看應(yīng)用流量截取的方案，也即通常我們所說的“抓包”。

系統(tǒng)代理

這是最為簡(jiǎn)單也是最為常用的一種抓包方案。在 Android、iOS、macOS 這些操作系統(tǒng)中連接 WiFi 時(shí)可以指定我們自定義的 HTTP 代理地址。如果應(yīng)用使用了是系統(tǒng)提供的網(wǎng)絡(luò)庫(kù)或者遵循這個(gè)代理配置，那么就會(huì)將 HTTP(S) 請(qǐng)求通過該代理進(jìn)行發(fā)送。

因此，這種方式有個(gè)很明顯的缺點(diǎn): 應(yīng)用可能不按規(guī)矩來。不管是設(shè)置的系統(tǒng)代理，還是通過?HTTP_PROXY?環(huán)境變量指定代理，都只是一種約定俗成的規(guī)則而已。應(yīng)用完全可以在自身代碼中通過?socket、connect、write?三連去直接發(fā)送網(wǎng)絡(luò)請(qǐng)求，這樣我們的代理就無法收到任何數(shù)據(jù)。即便是對(duì)于系統(tǒng)提供的 HTTP 網(wǎng)絡(luò)庫(kù)，一般也會(huì)有額外的配置選項(xiàng)，讓調(diào)用者指定或者忽略任何系統(tǒng)代理。

設(shè)置系統(tǒng)代理進(jìn)行抓包的方法也是有優(yōu)點(diǎn)的。這種方式配置起來比較簡(jiǎn)單，而且對(duì)應(yīng)的配套工具也相對(duì)成熟，Burpsuite、Fiddle 之類的工具可以很方便的對(duì)代理到的流量進(jìn)行格式化和重放分析。當(dāng)然，對(duì)于非 HTTP 的其他協(xié)議支持可能就不是很完善了。

除了直接設(shè)置系統(tǒng)代理，對(duì)于桌面應(yīng)用其實(shí)還有一些其他方式去對(duì)目標(biāo)應(yīng)用進(jìn)行代理，比如使用?proxychains?工具去加載動(dòng)態(tài)庫(kù)從而重定向目標(biāo)網(wǎng)絡(luò)請(qǐng)求。雖然原理不同，但其實(shí)際效果比較類似，因此也統(tǒng)一歸類為系統(tǒng)代理方法。

路由抓包

既然系統(tǒng)代理模式抓包容易被應(yīng)用繞過導(dǎo)致流量缺失，那么一個(gè)直觀的想法就是回歸流量分析的本身，直接在網(wǎng)絡(luò)層進(jìn)行抓包。其中比較常用的方式就是路由抓包，即在網(wǎng)關(guān)層進(jìn)行抓包。

具體實(shí)現(xiàn)也不難，大家應(yīng)該都知道在近源滲透中的 evilTwin AP, 即假熱點(diǎn)的攻擊方法。攻擊者通過可以完全控制的機(jī)器創(chuàng)建一個(gè)假熱點(diǎn)，待目標(biāo)連入后進(jìn)行網(wǎng)絡(luò)劫持，從而獲取敏感信息，或者替換關(guān)鍵流量實(shí)現(xiàn)代碼執(zhí)行。從這個(gè)角度上看，該方法也可以看作是一種 “網(wǎng)絡(luò)臨偵”。

對(duì)于我們的抓包方案來說，可以構(gòu)建一個(gè)真熱點(diǎn)，一般使用開源的?hostapd?可以實(shí)現(xiàn)；而熱點(diǎn)網(wǎng)絡(luò)所需要的 DHCP 服務(wù)器或者 DNS 服務(wù)器可以通過?dnsmasq?去實(shí)現(xiàn)。

路由抓包方案通常與透明代理進(jìn)行結(jié)合使用，以實(shí)現(xiàn) HTTP 請(qǐng)求分析、劫持與重放的功能。透明代理對(duì)于客戶端而言是一個(gè)真實(shí)的 HTTP 服務(wù)器，通常通過 DNS 劫持或者路由劫持去實(shí)現(xiàn)。Nginx 中一個(gè)重要的功能就是透明代理，在同一個(gè)公網(wǎng)地址進(jìn)行監(jiān)聽，并通過不同的域名分發(fā)到實(shí)際的后端服務(wù)器中。

前文提到的許多 HTTP 代理工具也支持透明代理，比如 BurpSuite 就支持?invisible proxy^[1]，mitmproxy 中稱為?Transparent proxy^[2]?，通過?-m transparent?指定。

路由抓包和系統(tǒng)代理相比具有很多優(yōu)點(diǎn)，比如可以保證抓到所有的 HTTP/HTTPS 流量，并且對(duì)于目標(biāo)應(yīng)用透明。這里有個(gè)潛在的好處，由于對(duì)被抓包目標(biāo)透明，因此路由抓包可以用于一些 IoT 設(shè)備的流量分析，比如車機(jī)設(shè)備、智能家居等等。

缺點(diǎn)也很明顯，即路由抓包需要額外的自定義路由設(shè)備。如果是運(yùn)行在 PC 端且驅(qū)動(dòng)支持完善的話還好，可以在個(gè)人電腦上作為臨時(shí)熱點(diǎn)；如果電腦(系統(tǒng))不支持可能還需要在虛擬機(jī)里跑個(gè) Ubuntu 去運(yùn)行，或者使用額外的硬件如樹莓派去執(zhí)行代碼，相比于前面的方法復(fù)雜度上升不少。另外使用路由抓包方法捕獲到的流量是整個(gè)系統(tǒng)的流量，而不僅限于目標(biāo)應(yīng)用，因此我們還需要對(duì)這些流量進(jìn)行額外的過濾。

虛擬網(wǎng)卡

路由抓包方案的目標(biāo)是為了完全捕捉到目標(biāo)應(yīng)用流量，確保沒有遺漏，另外還可以使用透明代理去實(shí)現(xiàn) HTTP 請(qǐng)求的解析。這種方法的本質(zhì)是在目標(biāo)應(yīng)用的路由中間節(jié)點(diǎn)進(jìn)行網(wǎng)絡(luò)劫持，其實(shí)要實(shí)現(xiàn)這個(gè)目標(biāo)可以直接在應(yīng)用端實(shí)現(xiàn)。

實(shí)現(xiàn)原理就是在本地運(yùn)行一個(gè)虛擬專用網(wǎng)絡(luò)，構(gòu)建一個(gè)虛擬網(wǎng)卡設(shè)備，并將路由規(guī)則修改為優(yōu)先通過我們虛擬的網(wǎng)卡進(jìn)行請(qǐng)求。比如，Android 上可以通過實(shí)現(xiàn) VPNService 去構(gòu)建自己的 VPN 服務(wù)，ProxyDroid?就是其中的一個(gè)實(shí)現(xiàn)；在 macOS 或者 iOS 中可以使用 Surge 等工具去實(shí)現(xiàn)類似的功能。

將路由抓包在客戶端上實(shí)現(xiàn)的一大好處是可以通過系統(tǒng)信息將網(wǎng)絡(luò)請(qǐng)求與實(shí)際的進(jìn)程相關(guān)聯(lián)，同時(shí)省去了對(duì)額外設(shè)備的依賴；缺點(diǎn)則是比較依賴代理工具的工程實(shí)現(xiàn)，據(jù)我所知實(shí)現(xiàn)效果較好的工具其價(jià)格也不菲。當(dāng)然這種抓包方式筆者使用得不多，如果有其他好的類似工具也歡迎留言分享一下。

libpcap

那位說了，既然都在端上抓包了，為什么不更直接一點(diǎn)，使用 tcpdump 或者 Wireshark 這類工具進(jìn)行抓包？別急，這正是這一節(jié)要介紹的最后一種抓包方法。tcpdump 這類工具本質(zhì)上是基于 libpcap 的，相信大家都比較熟悉了。

其實(shí)在前文中路由(網(wǎng)關(guān))抓包和虛擬網(wǎng)卡抓包的方式中，都可以使用 tcpdump 進(jìn)行抓包，前者需要指定網(wǎng)卡為熱點(diǎn)網(wǎng)卡(AP)，后者指定為虛擬網(wǎng)卡(TUN)即可。這樣抓包出來的結(jié)果是一個(gè)?pcap?文件，一般直接丟到 Wireshark 里面去進(jìn)行分析。與前面的方法相比，這種方法對(duì)于 HTTP 的可視化解析可能相對(duì)簡(jiǎn)陋，但是對(duì)于協(xié)議類型的支持卻非常廣泛，基本上你能叫出名字的標(biāo)準(zhǔn)協(xié)議都可以進(jìn)行解析。

因此，pcap 分析往往作為一種兜底的網(wǎng)絡(luò)分析方式。而之所以很多情況下使用前面的方法而不是此法，是因?yàn)樯虡I(yè)應(yīng)用的大部分是 HTTP/HTTPS 流量，前面那些代理工具可以幫我們解決以很大部分的解密和可視化工作，即與下一節(jié)中提到的 TLS 解密方法相互權(quán)衡后所采用的決策。

這里分享一個(gè) libpcap 的抓包技巧。筆者平時(shí)分析 Android 應(yīng)用比較多，而在抓包時(shí)會(huì)發(fā)現(xiàn)有很多不相關(guān)的后臺(tái)流量擾亂視聽。實(shí)際上可以在 UID 為維度進(jìn)行抓包，這樣就可以只抓取對(duì)應(yīng)應(yīng)用的流量了。

這個(gè)功能稱為?NFLOG^[3]，即 NetFilter Log。libpcap 在 1.2.1 版本之后支持抓取 nflog 的數(shù)據(jù)，而?iptables?又支持支持 uid 的過濾，二者相結(jié)合，比如要抓取 uid 為 1000 的應(yīng)用數(shù)據(jù)，可以這樣實(shí)現(xiàn):

$?iptables?-A?OUTPUT?-m?owner?--uid-owner?1000?-j?CONNMARK?--set-mark?1
$?iptables?-A?INPUT?-m?connmark?--mark?1?-j?NFLOG?--nflog-group?30?
$?iptables?-A?OUTPUT?-m?connmark?--mark?1?-j?NFLOG?--nflog-group?30?
$?tcpdump?-i?nflog:30?-w?uid-1000.pcap

由于 uid 信息只關(guān)聯(lián)在發(fā)送包上，因此只能添加到?OUTPUT?鏈上，但可以通過?connmark?去關(guān)聯(lián)返回的數(shù)據(jù)，這樣即可實(shí)現(xiàn)單個(gè)指定應(yīng)用(uid)的的抓包了。

流量解密

上節(jié)中介紹了流量抓取的一些方案，對(duì)于常規(guī) HTTP 流量而言沒有太大爭(zhēng)議，但是對(duì)于當(dāng)今日趨普遍的 HTTPS 卻有一些懸而未決的問題。如果我們抓到的所有 HTTPS 流量都是通過 TLS 進(jìn)行加密的，那對(duì)于分析而言就幾乎毫無價(jià)值了。

因此，為了能夠?qū)δ繕?biāo)應(yīng)用進(jìn)行網(wǎng)絡(luò)分析，應(yīng)用層的私有加密姑且不論，至少要解決標(biāo)準(zhǔn)的 TLS 的解密問題。解密是為了中間人攻擊，獲取明文流量，那么就需要知道 TLS 中常規(guī)的中間人防御方案，一般來說，有下面幾種:

1. 1. 客戶端驗(yàn)證服務(wù)端的證書鏈可信，基本操作；

2. 2. 服務(wù)端驗(yàn)證客戶端的證書可信(Certificate Request)，又稱為雙向證書綁定；

3. 3. 客戶端驗(yàn)證服務(wù)端的證書 HASH 是否在白名單中，即 SSL Pinning；

4. 4.?……

在介紹后文的具體解密方案中也會(huì)圍繞這幾點(diǎn)去進(jìn)行分析。

根證書

添加自定義的根證書應(yīng)該是 HTTPS 流量分析的標(biāo)準(zhǔn)答案了。前文中提到的 Burpsuite、mitmproxy 等工具的文檔中肯定都有介紹如何添加自定義根證書，根證書的存放對(duì)于不同的操作系統(tǒng)甚至不同的應(yīng)用都有不同路徑。比如在 Android 中，根證書存放在?/system/etc/security/cacerts?目錄之下；在 iOS/macOS 中，根證書存放在?Keychain?中；對(duì)于?Firefox?瀏覽器，其應(yīng)用中打包了證書鏈，不使用系統(tǒng)的證書?！?/p>

至于如何添加根證書，上過學(xué)的話應(yīng)該都能在搜索引擎中找到方法，這里就不再啰嗦了。雖然添加自定義根證書可以讓我們很方便地使用代理工具進(jìn)行 HTTPS 流量分析，但其實(shí)際上只解決了第一個(gè)問題，因此對(duì)于某些做了額外校驗(yàn)的應(yīng)用而言 TLS 握手還是無法成功的。

如果目標(biāo)應(yīng)用服務(wù)器在 TLS 握手中校驗(yàn)了客戶端證書，那么我們還需要在代理工具中添加對(duì)應(yīng)私鑰才能順利完成握手。該證書一般以?p12?格式存放，包含了客戶端的證書及其私鑰，通常還有一個(gè)額外的密碼。通過逆向分析目標(biāo)應(yīng)用的的加載代碼往往不難發(fā)現(xiàn)客戶端證書的蹤跡，甚至有時(shí)可以直接在資源文件中找到。

如果目標(biāo)應(yīng)用使用了 SSL Pinning 加固，那么通常是將服務(wù)器的證書 HASH 保存在代碼中，并在握手之后進(jìn)行額外校驗(yàn)。由于相關(guān)數(shù)據(jù)(證書HASH)和邏輯都在代碼中，因此這種情況下往往只能通過侵入式的方式去繞過 Pinning 校驗(yàn)，比如 Patch 代碼或者使用 hook 等方法實(shí)現(xiàn)。由于這是一個(gè)較為常見的功能，因此網(wǎng)上有很多相關(guān)腳本可以實(shí)現(xiàn)常規(guī)的 SSL Pinning bypass，但需要注意的是這并不意味著可以 100% 繞過，對(duì)于一些特殊實(shí)現(xiàn)仍然需要進(jìn)行特殊分析。

SSL keylog

除了在端側(cè)添加自定義根證書，還有一種方式可以解密 SSL/TLS 的流量，即在握手過程中想辦法獲取到 TLS 會(huì)話的?Master Key，根據(jù)協(xié)商的加密套件，就可以對(duì)整個(gè) TLS stream 進(jìn)行解密。關(guān)于 TLS 握手的原理介紹，可以參考筆者上一篇文章 ——?深入淺出 SSL/TLS 協(xié)議。

知名的抓包和網(wǎng)絡(luò)協(xié)議分析工具?Wireshark?就支持通過添加?keylog?文件去輔助 TLS 流量的解密。這里的 keylog 就是?TLS 會(huì)話秘鑰^[4]，文件格式為?NSS Key Log Format^[5]。對(duì)于不同版本的 TLS 內(nèi)容略有不同，在 TLS 1.2 中只需要一個(gè)會(huì)話的 MasterKey，使用?CLIENT_RANDOM?去區(qū)分不同會(huì)話；而在 TLS 1.3 中每個(gè)會(huì)話包含 5 個(gè)秘鑰，分別用于解密握手、數(shù)據(jù)階段的不同數(shù)據(jù)。

那么，這個(gè) keylog 文件我們應(yīng)該如何獲取呢？對(duì)于大部分 SSL 庫(kù)而言，比如 OpenSSL、BoringSSL、libreSSL 等，都可以通過?SSL_CTX_set_keylog_callback^[6]?這個(gè) API 去設(shè)置獲取的回調(diào)，令 SSL 庫(kù)在握手成功后調(diào)用對(duì)應(yīng)的回調(diào)函數(shù)從而獲取 keylog。因此我們就需要通過靜態(tài) patch 或者動(dòng)態(tài) hook 的方式去為 TLS 添加該回調(diào)。

這看似很簡(jiǎn)單，但實(shí)際操作起來會(huì)遇到一些問題。比如，很多大型商業(yè)應(yīng)用都封裝了自己的 SSL 庫(kù)，甚至同一個(gè)應(yīng)用中不同組件中又間接包含了有多個(gè) SSL 庫(kù)，為了每一個(gè) TLS 會(huì)話都能成功解密，需要確保每個(gè) SSL 庫(kù)都要被正確 patch 或者 hook；

其次，對(duì)于某些組件而言，實(shí)際是通過靜態(tài)編譯的方式引入 SSL 庫(kù)，比如?webview、libflutter、libffmpeg?等。在去除掉符號(hào)后，我們可能需要通過一些方法去搜索定位所需的符號(hào)地址。這個(gè)任務(wù)的難度可大可小，簡(jiǎn)單的可以通過 yara、Bindiff 去進(jìn)行定位，復(fù)雜的話也可以通過一些深度學(xué)習(xí)算法去進(jìn)行相似度分析，比如科恩的?BinaryAI?或者阿里云的?Finger?等。感興趣的也可以去進(jìn)一步閱讀相關(guān)的綜述文章:

USENIX Security 2022 - How Machine Learning Is Solving the Binary Function Similarity Problem^[7]

另外還有一個(gè)問題，SSL_CTX_set_keylog_callback?這個(gè) API 并不是最初就存在于 SSL 庫(kù)中的。以 openssl 為例，keylog 文件的支持實(shí)際上是在 commit 4bf73e^[8]?中才被引入。因此，如果遇到了某些應(yīng)用中依賴于舊版本的 SSL 庫(kù)，那么可能就不支持 keylog。我們要想強(qiáng)行支持就要進(jìn)行二進(jìn)制級(jí)別的 cherry-pick，這個(gè)工作量還是挺大的。

雖然有這些那些難點(diǎn)，但這種解密方法的一大優(yōu)點(diǎn)是可以一次性解決本節(jié)開頭所提及的三個(gè)問題，即服務(wù)端證書校驗(yàn)、客戶端證書校驗(yàn)和 SSL Pinning。因?yàn)樵摲椒ú]有對(duì)流量進(jìn)行網(wǎng)絡(luò)層面的中間人，而是在應(yīng)用的運(yùn)行過程中泄露會(huì)話秘鑰，因此不會(huì)影響上層的證書校驗(yàn)。

SSL read/write

既然設(shè)置 keylog 如此麻煩，為什么不找一些相對(duì)簡(jiǎn)單且通用的 API 去進(jìn)行解密呢？一個(gè)直接的思路就是通過掛鉤?SSL_read^[9]、SSL_write 來獲取 SSL 讀寫的明文數(shù)據(jù)?；谶@個(gè)思路目前網(wǎng)上有許多工程化的實(shí)現(xiàn)，比如?eCapture^[10]?是基于?eBPF/uprobes?的 TLS 抓包方案；r0capture^[11]?則是基于?frida?注入的 TLS 抓包方案。

使用該方法進(jìn)行解密的一大優(yōu)點(diǎn)，或者說特點(diǎn)，是這種方式可以在解密的同時(shí)直接輸出明文信息，因此可以完全略過流量抓取這一步。雖然許多開源工具是將結(jié)果保存為 pcap 文件進(jìn)行進(jìn)一步分析的，但實(shí)際上也可以直接在標(biāo)準(zhǔn)輸出或者日志文件中打印出來進(jìn)行分析。

由于這些抓包工具本質(zhì)上都是在獲取 SSL read/write 明文的基礎(chǔ)上再以 pcap 格式進(jìn)行轉(zhuǎn)儲(chǔ)，因此同樣會(huì)面臨 keylog 方案所面臨的問題，即依賴 SSL 庫(kù)的符號(hào)。但不同的是其所依賴的是較為通用的符號(hào)，因此不太會(huì)受到 SSL 庫(kù)版本的限制。唯一需要考慮的難題是如何解析無符號(hào)的 SSL 庫(kù)中相關(guān)函數(shù)的偏移地址，這在上節(jié)中有些簡(jiǎn)單介紹，展開的話又是另一篇論文了。

小結(jié)

上述介紹的每一種流量抓取方法都可以和任意一種流量解密方法相結(jié)合，組成一種網(wǎng)絡(luò)流量分析方案。實(shí)踐上使用較多的是下面幾種組合:

• ??系統(tǒng) HTTP 代理 + 根證書

• ??路由抓包/透明代理 + 根證書

• ??tcpdump + keylog

• ??SSL_read/SSL_write hook

每種方案都有其優(yōu)點(diǎn)和缺點(diǎn):

那么實(shí)際安全分析中要如何選擇呢？正如那句老話所說:?網(wǎng)絡(luò)安全沒有銀彈，實(shí)際情況也無法一概而論，通常是根據(jù)具體的目標(biāo)去進(jìn)行分析。

例如，對(duì)于操作系統(tǒng)比較封閉的 IoT 設(shè)備，通過路由抓包是唯一選擇；對(duì)于移動(dòng)應(yīng)用或者桌面應(yīng)用而言，可以先嘗試傳統(tǒng)的系統(tǒng)代理方式，添加對(duì)應(yīng)根證書，如果不能抓到包，可以通過流量分析可能的問題:

• ??流量日志中服務(wù)端有 Certificate Request 則表示進(jìn)行了客戶端證書校驗(yàn)；

• ??流量日志中握手成功但很快斷開，則客戶端中可能使用了 SSL Pinning 加固；

• ??流量日志中客戶端握手失敗，Alert 提示證書不可信，則說明客戶端使用了自定義的 keystore 而不是系統(tǒng)的根證書；

• ??……

此時(shí)如果發(fā)現(xiàn)客戶端使用了多種方法防止 HTTP 代理進(jìn)行中間人抓包，那么就可以嘗試使用 keylog 或者 SSL read/write hook 的方式進(jìn)行分析?？偠灾?，流量層的分析可以確保數(shù)據(jù)的完備性，即應(yīng)用發(fā)送的請(qǐng)求都能夠確保抓到；而 HTTP 代理和部分解密方法對(duì)于 Web 流量則更具針對(duì)性，在不同的場(chǎng)景中可以對(duì)不同分析方案進(jìn)行靈活切換。

參考鏈接

• ??深入淺出 SSL/TLS 協(xié)議

• ??Intercepting traffic from Android Flutter applications^[12]

• ??自動(dòng)定位webview中的SLL_read和SSL_write^[13]

引用鏈接

[1]?invisible proxy:?https://portswigger.net/burp/documentation/desktop/tools/proxy/options/invisible
[2]?Transparent proxy:?https://docs.mitmproxy.org/stable/howto-transparent/
[3]?NFLOG:?https://wiki.wireshark.org/CaptureSetup/NFLOG
[4]?TLS 會(huì)話秘鑰:?https://wiki.wireshark.org/TLS
[5]?NSS Key Log Format:?https://firefox-source-docs.mozilla.org/security/nss/legacy/key_log_format/index.html
[6]?SSL_CTX_set_keylog_callback:?https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_keylog_callback.html
[7]?USENIX Security 2022 - How Machine Learning Is Solving the Binary Function Similarity Problem:?https://www.eurecom.fr/publication/6847/download/sec-publi-6847.pdf
[8]?4bf73e:?https://github.com/openssl/openssl/commit/4bf73e9f86804cfe98b03accfc2dd7cb98e018d6
[9]?SSL_read:?https://www.openssl.org/docs/man1.1.1/man3/SSL_read.html
[10]?eCapture:?https://github.com/ehids/ecapture
[11]?r0capture:?https://github.com/r0ysue/r0capture
[12]?Intercepting traffic from Android Flutter applications:?https://blog.nviso.eu/2019/08/13/intercepting-traffic-from-android-flutter-applications/
[13]?自動(dòng)定位webview中的SLL_read和SSL_write:?https://mabin004.github.io/2020/07/24/%E8%87%AA%E5%8A%A8%E5%AE%9A%E4%BD%8Dwebview%E4%B8%AD%E7%9A%84SLL-read%E5%92%8CSSL-write/