日韩精品一区熟女观看,avsm观看

前提說明

我們經(jīng)常會遇到很多APP的 HTTPS 接口請求，Charles 安裝證書后也無法進行抓包看到內(nèi)容。

為什么要抓包呢，如果我們能夠抓取APP任何的請求，那么就可以干很多事情，比如分析接口返回數(shù)據(jù)，分析下發(fā)內(nèi)容，分析性能，分析圖片，分析接口，等等很多用途。

所以本篇文章主要是講是針對這種抓不到HTTPS 加密請求的解決方案和問題探究。

涉及

脫殼（Frida 脫殼，脫殼后才能進行修改APP代碼）

重簽名（非越獄機安裝ipa的一種方法）

動態(tài)注入（修改代碼后，注入正常APP）

MonkeyDev （一種懶人越獄開發(fā)環(huán)境工具）

NSURLProtocol （用于攔截請求）

Charles中間人攻擊與HTTPS原理（了解）

重簽名原理，動態(tài)注入，脫殼，本篇文章不做詳細深入。

背景說明

猜測連接為 CONNECT 原因?qū)е?/p>

Charles 抓取HTTPS原理

逆向思考 - 如何預(yù)防Charles 抓 HTTPS 包

客戶端判斷用戶是否代理訪問

使用 HTTPS 雙向認證

客戶端本地證書校驗

思考解決方案

得出最終結(jié)論

實戰(zhàn)破解探探APP，HTTPS網(wǎng)絡(luò)請求

總結(jié)

一、背景說明

（1）舉例

例如《探探》APP，抓 HTTPS 的接口

可以看到有些HTTPS請求能夠抓到返回內(nèi)容，有些不能夠抓到返回內(nèi)容。

我們知道 MAC 客戶端可以通過Charles代理，安裝信任Charles證書，然后抓取到HTTPS 請求返回內(nèi)容。

（2）結(jié)論

但是還是發(fā)現(xiàn)很多APP，例如探探的接口，有的 HTTPS 接口能抓到返回，有的抓不到，很是奇怪，不知原因，所以猜想幾個層面去解決。

一、猜測 - 連接為 CONNECT 原因?qū)е隆?/p>

有聽說請求Method 為 CONNECT 就無法進行抓包。

實驗：嘗試抓取項目 HTTPS 請求

結(jié)論：Method 為 CONNECT

實驗：開啟SSL代理信任證書后

CONNECT結(jié)論

Method 變?yōu)?GET ，并且可以抓到HTTPS響應(yīng)內(nèi)容。

CONNECT 最終結(jié)論

HTTP 1.1定義了8種方法，CONNECT 只是為其中之一，通常用于SSL加密服務(wù)器的鏈接。

當客戶端向Proxy發(fā)起HTTP CONNECT Method的時候，就是告訴Proxy，先在Proxy和目標服務(wù)器之間先建立起連接，在這個連接建立起來之后，目標服務(wù)器會返回一個回復(fù)給Proxy，Proxy將這個回復(fù)轉(zhuǎn)發(fā)給客戶端，在此之后，客戶端跟目標服務(wù)器的所有通信都將使用之前建立起來的建立。

Proxy僅僅實現(xiàn)轉(zhuǎn)發(fā)，而不會關(guān)心轉(zhuǎn)發(fā)的數(shù)據(jù)。因為HTTPS的數(shù)據(jù)都是經(jīng)過加密的，Proxy是無法對Https的數(shù)據(jù)進行解密的，所以只能使用CONNECT，僅僅對通信數(shù)據(jù)進行轉(zhuǎn)發(fā)。

HTTPS Method 基本均為 CONNECT （因為是加密的無法解析，只是建立一個通道而已）Charles 中間人攻擊后，某些域名開啟后可以抓到內(nèi)容，某些域名依然抓取不到，所以跟 Method 為 CONNECT 沒有直接的絕對關(guān)系。所以繼續(xù)往下找原因。

二、Charles抓取HTTPS原理（簡述）

（1）探究

思考過后，想了下既然是要解決HTTPS抓包問題，那么也是應(yīng)該了解下 Charles 抓 HTTPS的原理。

了解后知道 Charles 抓 HTTPS 的原理邏輯，其實很簡單明了。

主要利用中間人攻擊原理，代理后Charles 會偽裝為客戶端和服務(wù)器，充當雙面間諜。

Charles作為“中間人代理”，客戶端與服務(wù)器的交流通信都會經(jīng)過Charles，所以Charles可以拿到服務(wù)器證書公鑰， HTTPS連接的對稱密鑰等。

既然拿到了對稱密鑰，那么就可以內(nèi)容一切都是透明的了。

（2）結(jié)論

知道了 Charles 抓包原理，并且客戶端使用Charles進行中間人攻擊，開啟了SSL Proxying 代理，按照理論應(yīng)該是能抓到HTTPS內(nèi)容的，但是發(fā)現(xiàn)抓取 HTTPS 請求還是失敗，所以繼續(xù)探究問題。

三、逆向思考 - 如何預(yù)防Charles 抓 HTTPS 包

既然前兩種方案都不可行，那么思考想了一下不如逆向思維，不去思考如何抓 HTTPS 包，而是去思考果是我們，我們該如何去預(yù)防別人 Charles 中間人攻擊抓取HTTPS包呢。

進行思考與調(diào)研方案后，得出以下幾種方法：

（1）判斷是否代理訪問

如果檢測出客戶端使用代理訪問，那么就不允許訪問。

（2）使用 HTTPS 雙向認證

一般做法只有客戶端驗證服務(wù)端公鑰證書是不是合法，服務(wù)器對來訪的客戶端身份不做任何限制。如果采用雙向驗證的方式，在通信過程中，不但客戶端驗證服務(wù)端公鑰證書，服務(wù)端也會驗證客戶端 app 的公鑰證書。

在雙向驗證中，客戶端需要用到保存自己的私鑰和證書，并且證書需要提前發(fā)給服務(wù)器，由服務(wù)器放到它的信任庫中。

如果使用雙向驗證，這時候就沒辦法使用 Charles（中間人攻擊的方式）進行抓包。

結(jié)論

（1）探探APP 防止抓包的方法猜測

首先從表面來看不是客戶端端判斷是否代理，而禁止訪問。

在開啟SSL Proxying 后依然提示證書問題，所以感覺應(yīng)該是使用了雙向驗證或者類似的工程內(nèi)置證書，進行驗證的一種方式。

（2）針對雙向驗證，破解的方法

SSL Kill Switch

didReceiveAuthenticationChallenge

修改HTTPS 請求

四、思考解決方案

思考后，準備破解方法，目前想到有幾種：

（1）SSL Kill Switch 越獄插件

通過hook的方式將校驗證書的結(jié)果返回true或者干脆不讓其做校驗。

https://nabla-c0d3.github.io/blog/2016/02/21/ssl-kill-switch-twitter/

缺點：需要越獄。

（2）didReceiveChallenge 代理方法

既然客戶端有驗證證書的處理，那么如果客戶端能夠信任所有證書，不就解決了問題。

NSURLSession有個代理方法 didReceiveChallenge ，只要訪問的是HTTPS就會調(diào)用。

該方法的作用就是?處理服務(wù)器返回的證書?。

如果使用了雙向驗證和本地證書校驗等，客戶端應(yīng)該會在里面進行證書驗證處理。

如果HOOK 這個代理方法，信任所有證書，那么問題就可以解決了。

例如一下代碼：

-(void)URLSession:(NSURLSession*)session didReceiveChallenge:(NSURLAuthenticationChallenge*)challenge completionHandler:(void(^)(NSURLSessionAuthChallengeDisposition,NSURLCredential*_Nullable))completionHandler{//? ? NSURLSessionAuthChallengeUseCredential = 0, 使用（信任）證書//? ? NSURLSessionAuthChallengePerformDefaultHandling = 1, 默認，忽略//? ? NSURLSessionAuthChallengeCancelAuthenticationChallenge = 2,? 取消//? ? NSURLSessionAuthChallengeRejectProtectionSpace = 3,? 這次取消，下載次再來問if([challenge.protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]){NSURLCredential*credential=[NSURLCredential credentialForTrust:challenge.protectionSpace.serverTrust];if(completionHandler)completionHandler(NSURLSessionAuthChallengeUseCredential,credential);}}

（4）修改Reuquest 請求schme

我們知道iOS可以利用NSURLProtocol 攔截請求進行修改.

如果能夠攔截到所有 reuquest，進行修改HTTPS 為 HTTP 問題也可得到解決。

例如以下代碼

NSMutableURLRequest*mutableReq=[request mutableCopy];NSString*originUrlStr=mutableReq.URL.absoluteString;NSString*newURLStr=[originUrlStr stringByReplacingOccurrencesOfString:@"https"withString:@"http"];mutableReq.URL=[NSURL URLWithString:newURLStr];

五、得出最終結(jié)論

（1）SSL Kill Switch 越獄插件

這種方法，需要設(shè)備越獄，比較費事，所以不采用。

（2）修改 Reuquest 和信任所有證書辦法可行，但是如何修改探探APP代碼呢，是個問題。

利用逆向技術(shù)即可解決，利用逆向技術(shù)可以往APP中注入動態(tài)庫，進行執(zhí)行自己想要執(zhí)行的代碼，只要植入NSURLProtocol，在內(nèi)部進行攔截拿到最高權(quán)限，進行信任證書和修改Request等可隨意操作。

具體步驟可參考之前文章：https://drive.google.com/open?id=1fpesf7U4PnzA0pLajbpD8K2FQL0ko7zH914MMRP05d8

六、實戰(zhàn) - 破解探探APP HTTPS網(wǎng)絡(luò)請求

（1）首先設(shè)備下載探探APP，然后對探探APP進行脫殼。

布置好 Frida 脫殼環(huán)境，連接設(shè)備SSH，對探探APP進行脫殼。