Android端Charles抓包

阿新 • • 發佈：2020-09-21

目錄介紹

01.下載安裝
02.抓包代理設定
03.抓包Https操作
04.抓包原理介紹
05.抓包資料介紹
06.常見問題總結
07.Android攔截抓包

01.下載安裝

下載地址(下載對應的平臺軟體即可)
- https://www.charlesproxy.com/download/
下載破解檔案
- https://assets.examplecode.cn/file/charles.jar
- 開啟Finder,在應用程式中選擇Charles並右鍵選擇顯示包內容
- 顯示包內容後在Content/Java目錄下將破解檔案複製過來替換掉原檔案即可
- 如果開啟Charles時提示：程式已損壞，打不開。您應該將它移到廢紙簍。此時需要在終端中執行以下命令即可：sudo spctl --master-disable

02.抓包代理設定

charles代理設定
- 可以設定抓包資料型別，包括http與socket資料。可以根據需要在proxies欄下勾選。這裡簡單操作進行設定，Proxy ---> Proxy Settings預設埠是8888，根據實際情況可修改。
Android手機代理設定
- 首先獲取電腦ip地址
  - 第一種方式：檢視本機IP地址：Help ---> Local IP Addresses
  - 第二種方式：命令列方式，輸入ifconfig即可
- 然後開啟手機設定代理
  - 注意：手機需要和電腦使用同一個Wi-Fi網路，這是前提！！！
  - 操作步驟：開啟WiFi列表 ---> 長按連線的WiFi修改網路設定代理 --- > 設定代理資訊
最後抓包如下
- 抓包資料如下所示

03.抓包Https操作

需要做哪些操作
- 1.電腦上需要安裝證書
- 2.手機上需要安裝證書
- 3.Android專案程式碼設定相容
1.電腦上需要安裝證書
- 第一步安裝證書：help ---> SSl Proxying ---> install charles root certificate ---> 安裝證書
- 第二步設定SSL屬性：Proxy ---> SSL Proxy Settings ---> 然後add操作(設定port為443)。如下所示
- 然後抓包試一下，會發現Android7.0手機之前可以抓包，但是Android7.0之後是無法抓包的
  - 報錯資訊：客戶端SSL握手失敗:處理證書時出現未知問題(certificate_unknown)
- 如何解決在Android7.0之後也可以抓包https資訊，接著往下看。
2.手機上需要安裝證書
- 第一步下載證書
  - 開啟瀏覽器，輸入：chls.pro/ssl，就會自己下載到手機上，這裡需要記住下載完成儲存到本地的路徑。
- 第二步安裝證書
  - 設定 ---> 更多設定 ---> 系統安全 ---> 加密與憑據 ---> 從SD卡安裝，選擇之前儲存證書的路徑。
  - 注意，有的手機是直接點選下載的檔案即可安裝……
- 安裝操作如下圖所示
3.Android專案程式碼設定相容
- 新增安全配置檔案。如下所示：
- java.security.cert.CertPathValidatorException: Trust anchor for certification path not found 這個異常，解決方案如下所示：
```
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="true">
        <trust-anchors>
            <certificates
                overridePins="true"
                src="system" />
            <certificates
                overridePins="true"
                src="user" />
        </trust-anchors>
    </base-config>
</network-security-config>

//清單檔案配置
<application
    android:networkSecurityConfig="@xml/network_security_config_debug">
```
- Android 7.0及以上為何不能輕易抓取到Https請求的明文資料？
  - 在Android 7.0(API 24 ) ，有一個名為“Network Security Configuration”的新安全功能。這個新功能的目標是允許開發人員在不修改應用程式程式碼的情況下自定義他們的網路安全設定。如果應用程式執行的系統版本高於或等於24，並且targetSdkVersion>=24，則只有系統(system)證書才會被信任。所以使用者(user)匯入的Charles根證書是不被信任的。
抓https最後結果如下所示

04.抓包原理介紹

1.抓包的原理：
- 代理。客戶端請求->經過代理->到達服務端服務端返回->經過代理->到達客戶端
2.任何Https的 app 都能抓的到嗎？
- 7.0以下是可以的，只要手機裡安裝對應CA證書，比如用charles抓包，手機要安裝charles提供的證書就行。
- Android 7.0 之後，Google 推出更加嚴格的安全機制，應用預設不信任使用者證書（手機裡自己安裝證書），自己的app可以通過配置解決，但是抓其它app的https請求就行不通。
3.如何避免抓包
- 1.基於抓包原理的基礎上，直接使用okhtttp禁止代理，就可以了 builder.proxy(Proxy.NO_PROXY);經過測試，可以避免抓包
- 2.直接使用加密協議，全是欄位亂碼，把域名換裝IP。這樣基本別人很難抓到，像混淆一樣
4.charles抓包原理圖
5.大概步驟流程
- 第一步，客戶端向伺服器發起HTTPS請求，charles截獲客戶端傳送給伺服器的HTTPS請求，charles偽裝成客戶端向伺服器傳送請求進行握手。
- 第二步，伺服器發回相應，charles獲取到伺服器的CA證書，用根證書（這裡的根證書是CA認證中心給自己頒發的證書）公鑰進行解密，驗證伺服器資料簽名，獲取到伺服器CA證書公鑰。然後charles偽造自己的CA證書（這裡的CA證書，也是根證書，只不過是charles偽造的根證書），冒充伺服器證書傳遞給客戶端瀏覽器。
- 第三步，與普通過程中客戶端的操作相同，客戶端根據返回的資料進行證書校驗、生成密碼Pre_master、用charles偽造的證書公鑰加密，並生成HTTPS通訊用的對稱金鑰enc_key。
- 第四步，客戶端將重要資訊傳遞給伺服器，又被charles截獲。charles將截獲的密文用自己偽造證書的私鑰解開，獲得並計算得到HTTPS通訊用的對稱金鑰enc_key。charles將對稱金鑰用伺服器證書公鑰加密傳遞給伺服器。
- 第五步，與普通過程中伺服器端的操作相同，伺服器用私鑰解開後建立信任，然後再發送加密的握手訊息給客戶端。
- 第六步，charles截獲伺服器傳送的密文，用對稱金鑰解開，再用自己偽造證書的私鑰加密傳給客戶端。
- 第七步，客戶端拿到加密資訊後，用公鑰解開，驗證HASH。握手過程正式完成，客戶端與伺服器端就這樣建立了”信任“。
- 在之後的正常加密通訊過程中，charles如何在伺服器與客戶端之間充當第三者呢？
- 伺服器—>客戶端：charles接收到伺服器傳送的密文，用對稱金鑰解開，獲得伺服器傳送的明文。再次加密，傳送給客戶端。
- 客戶端—>服務端：客戶端用對稱金鑰加密，被charles截獲後，解密獲得明文。再次加密，傳送給伺服器端。由於charles一直擁有通訊用對稱金鑰enc_key，所以在整個HTTPS通訊過程中資訊對其透明。
6.總結一下
- HTTPS抓包的原理還是挺簡單的，簡單來說，就是Charles作為“中間人代理”，拿到了伺服器證書公鑰和HTTPS連線的對稱金鑰，前提是客戶端選擇信任並安裝Charles的CA證書，否則客戶端就會“報警”並中止連線。這樣看來，HTTPS還是很安全的。

05.抓包資料介紹

HTTP請求包的結構
- 請求報文
  - 請求報文結構格式：
```
請求行： <method> <request-URL> <version>
頭部：   <headers>
主體：   <entity-body>
```
  - 請求報文結構示意圖：
  - 例子：
    - 請求了就會收到響應包(如果對面存在HTTP伺服器)
```
POST /meme.php/home/user/login HTTP/1.1
Host: 114.215.86.90
Cache-Control: no-cache
Postman-Token: bd243d6b-da03-902f-0a2c-8e9377f6f6ed
Content-Type: application/x-www-form-urlencoded

tel=13637829200&password=123456
```
- 常見的是那些
  - User-Agent：產生請求的瀏覽器型別。
  - Accept：客戶端可識別的響應內容型別列表;
  - Accept-Language：客戶端可接受的自然語言;
  - Accept-Encoding：客戶端可接受的編碼壓縮格式;
  - Host：請求的主機名，允許多個域名同處一個IP 地址，即虛擬主機;
  - Connection：連線方式(close 或keep-alive);
  - Cookie：儲存於客戶端擴充套件欄位，向同一域名的服務端傳送屬於該域的cookie;
HTTP響應包結構
- 響應報文
  - 響應報文結構格式：
```
狀態行：  <version> <status> <reason-phrase>
響應頭部：    <headers>
響應主體：    <entity-body>
```
  - 響應報文結構示意圖：
  - 例子：
```
HTTP/1.1 200 OK
Date: Sat, 02 Jan 2016 13:20:55 GMT
Server: Apache/2.4.6 (CentOS) PHP/5.6.14
X-Powered-By: PHP/5.6.14
Content-Length: 78
Keep-Alive: timeout=5, max=100    Connection: Keep-Alive
Content-Type: application/json; charset=utf-8

{"status":202,"info":"\u6b64\u7528\u6237\u4e0d\u5b58\u5728\uff01","data":null}
```
- 常見的響應頭部引數
  - Allow 伺服器支援哪些請求方法（如GET、POST等）。
  - Content-Encoding 文件的編碼（Encode）方法。
  - Content-Length 表示內容長度。只有當瀏覽器使用持久HTTP連線時才需要這個資料。
  - Content-Type 表示後面的文件屬於什麼MIME型別。
  - Server 伺服器名字。
  - Set-Cookie 設定和頁面關聯的Cookie。
  - ETag：被請求變數的實體值。ETag是一個可以與Web資源關聯的記號（MD5值）。
  - Cache-Control：這個欄位用於指定所有快取機制在整個請求/響應鏈中必須服從的指令。

響應報文狀態碼

包含了狀態碼以及原因短語，用來告知客戶端請求的結果。

關於狀態碼，可以看這篇文章，http狀態碼。

狀態碼	類別	原因短語
1XX	Informational（資訊性狀態碼）	接收的請求正在處理
2XX	Success（成功狀態碼）	請求正常處理完畢
3XX	Redirection（重定向狀態碼）	需要進行附加操作以完成請求
4XX	Client Error（客戶端錯誤狀態碼）	伺服器無法處理請求
5XX	Server Error（伺服器錯誤狀態碼）	伺服器處理請求出錯

06.常見問題總結

1.配置好後無法開啟APP
- 在我們抓取時碰到個別APP在配置代理後無法開啟，這個主要是因為該APP做了防止抓取處理，比如校驗https的證書是否合法等，這種解決方法可以通過反編譯APP，檢視原始碼解決，難度較大。
2.抓取到的內容為亂碼
- 有的APP為了防止抓取，在返回的內容上做了層加密，所以從Charles上看到的內容是亂碼。這種情況下也只能反編譯APP,研究其加密解密演算法進行解密。