❶ Wireshark 抓包理解 HTTPS 請求流程
目錄
我的操作是這樣的，讓手機和電腦在同一個區域網內（比如連接同一個 wifi），接著在手機的wifi上設置代理，電腦使用 Charles 做代理，IP 為電腦在區域網 IP，我這邊的環境，手機 IP 為 172.17.32.117，電腦 IP 為 172.17.32.19。再設置代理埠為 8888。設置代理後，接下來手機的請求都會通過電腦的網卡代理請求發送出去。
其實可以不用這么繞。我之所以多設了一個代理，是因為自己電腦創建的 wifi 熱點，手機接收不到。為了讓手機的包能經過電腦網路嗅探到才這么處理的。
最便捷的方式，就是電腦放個 wifi 熱點給手機連接完事。
創建後代理連接後，然後使用 Wireshark 嗅探網卡，比如我這里使用的是 etho0 網卡去訪問網路的。這時候玩玩手機，打開幾個請求，Wireshark 上面就會出現捕捉的大量的包旁慶祥，各種各樣的協議都有，有 ARP 尋人啟事（尋找 IP 對應的物理地址），有 TCP 連接包，有 HTTP 請求包。
這里我設置了一下過濾規則，把對網易的一個 https://nex.163.com 的一個的請求過濾出來如下：
整個完整的 HTTPS 請求的過程如下：
接下來把手機稱為 A（172.17.32.211），電腦稱為 B（172.17.32.19），對完整的過程進行簡要分析。
作為整個過程的第一個 TCP 包，這里對它做一個詳細的剖析，理解一下 TCP 報文的格式和內容。TCP 是傳輸層協議，負責可靠的數據通信，它在整個體系結構的位置如下：
作為傳輸層協議，主要為上層協議提供三個功能：
TCP 協議為 HTTP 和 SSL 協議提供了基礎的通信功能。所以 SSL 協議是基於 TCP 的。
三次握手的內容有：
對每個包進行詳細的分析：
A 發出一個帶 SYN 同步位的包，通知服務端要建立連接 。
第一次握手，發出的 TCP 包的數據和 Wireshark 解析的結果如下：
灰色部分就是 TCP 報文的數據內容，第一個兩個位元組 0x8c85 = 35973 表示源埠。
TCP 報文的格式如下，對應的如上圖的灰色部分。非灰色部分分別為 IP 首部和數據幀首部。
參考謝希仁版本的 《計算機網路》一書，對照著整個報文格式表，把整個 TCP 報文的二進制信息和相關意義做些說明：
到這里的話，TCP 數據報首部固定部分結束，固定部分一共有 20 位元組。也就是 TCP 首部，至少要有 20 位元組。
固定首部後，就是可長度可以變化的選項了：
整個所以 TCP 數據包的大小可以這樣表示：
我們 Wireshark 後面的運搏一長串的信息就指出了該 TCP 報文的一些主要信息：
從上面的分析可以看出，這個 SYN 包並沒有攜帶數據，但是按協議這里要消耗一個序號。
在發出 SYN 包後，A 端進入 SYN-SENT 狀態。
B 收到 SYN 包，發出 SYN + ACK 確認包 。
這個包，既是確認收到了第一差乎次握手的包，也是一個由 B 端發出的同步包，表示自己准備好了，可以開始傳數據了。
TCP 報文包相對於第一次握手的包可以窺見一些變化：
可以看到，這個包的應答時間戳剛好是第一次握手的發送時間戳。從這里也可以理解到，這個包就是在響應第一次握手的包
所以，接收方 A 可以利用這個值來計算這一次 RTT ，收到第二次握手的包後，計算當前時間戳減去該包的應答時間戳就是一個 RTT 的延時了。
這雖然是 ACK 包，但也是 SYN 包，所以也要消耗一個序號。
在發出這個包後，B 端進入 SYN-REVD 狀態。
A 收到後，再發出一個 ACK 確認包
發出的包如下：
這里我們產生一個疑問，這里發送端 A 發連接請求信息、接收端 B 發確認信息，又互相同步了序號，是不是已經可以傳輸數據了？但實際上 A 還要再發一個 ACK 確認報文，如圖所示，確認收到了 B 第二次握手發出的包，這個時候，在這個 ACK 包後 A 和 B 才正式進入 ESTABLISHED 狀態。這就是第三次握手。
這是為什麼呢？
假設我們用兩次握手，然後在第一次握手期間，A 發了第一次握手包後出現了這樣的場景：一直沒有得到響應而進行超時重傳，又發了一次包，然後我們稱上一次包為失效包。
然後我們可以看到：
所以，只有接收端 B 在發送端 A 發出了第三次握手包後，才認為連接已經建立，開始等待發送端 A 發送的數據，才不會因為失效的連接請求報文導致接收端異常。
TCP 三次握手的時序圖如下：
三次握手，有幾個重要的任務，一個是 同步序號 ，接收端和發送端都發出同步包來通知對方初始序號，這樣子後面接收的包就可以根據序號來保證可靠傳輸；另一個是讓發送端和接收都 做好准備 。然後就開始傳數據了。
整個過程都發生在 HTTP 報文發出之前。HTTP 協議就是依靠著 TCP 協議來做傳輸的管理。TCP 可以認為是它的管家，管理著傳輸的大大小小的事務，比如要不要保證包順序一致？什麼時候發包？要不要收包？TCP 是很嚴格的。
三次握手在 Java API 層面，對應的就是 Socket 的連接的創建（最終調用的是 native 層的 socket 創建）：
這里的 connectTimeout 對應的是三次握手的總時長，如果超時了就會被認為連接失敗。
比如一個場景，客戶端發出一個 SYN 報文後，遲遲沒有收到服務端的 SYN + ACK。這時候客戶端觸發重傳機制，每次重傳的間隔時間加倍，同樣沒有收到包。然後如果這段時間超出了連接超時時間的設置，那麼建立連接超時就發生了。
所以，如果三次握手要花的時間，總是大於這里的 connectTimeout 時間，這個 Socket 就無法建立連接。
我們這一次請求的三次握手時間在 180ms 左右。
像在 OkHttp 中，如果是三次握手階段的連接超時，是會有重試機制的。也就是重新建聯，重新發出 SYN 報文發起 TCP 連接。重新建聯的時候會更換連接的路由，如果已經沒有可選擇路由的話，那麼這個就真的失敗了。
在 OkHttp 3.9.0 的默認配置中，連接超時的時間為 10000ms = 10s。在 OkHttpClient.Builder 中。
實際應用的時候，根據業務場景來調整。
這次請求，為了讓 Wireshark 抓到手機的包，我使用了電腦作為代理。
其實就是客戶端 A 使用 HTTP 協議和代理伺服器 B 建立連接。和普通的 HTTP 請求一樣，需要攜帶 IP + 埠號，如果有身份驗證的時候還會帶上授權信息，代理伺服器 B 會使用授權信息進行驗證。然後代理伺服器會去連接遠程主機，連接成功後返回 200。
Wireshark 抓到的包有這樣兩條信息，就是在創建代理：
請求報文：
響應報文：
HTTP CONNECT 是在 HTTP1.1 新增的命令，用於支撐 https 加密。
因為我採用代理的方式抓包才有這一個步驟。如果是直接抓 PC 機上瀏覽器發出的 HTTPS 包，不會有這個過程。
然後我們思考一下，為什麼代理伺服器需要這些信息，要連接的主機名和埠號？
這是因為後面進行 SSL 加密 HTTP協議，因為代理伺服器拿不到加密密鑰，是無法獲取到 HTTP 首部的，進而無法這個請求是要發到哪個主機的。所以，這里先使用 CONNECT 方法，把主機名和對應的埠號通知代理伺服器。
這個也被稱為 HTTPS SSL 隧道協議。建立這個 SSL 隧道後，這個特殊代理就會對數據進行盲轉發。
SSL 整個協議實際上分兩層，SSL 記錄協議和其他子協議（SSL握手協議，SSL改變密碼協議，SSL警告協議）：
這兩層協議的關系，其實就是數據封裝的關系，SSL 握手封裝協議封裝其他上層協議。
封裝握手協議：
封裝應用數據協議，比如 HTTP：
封裝交換密碼協議：
封裝警報協議：
所以 SSL 記錄協議其實就是一個其他協議的載體，只是提供了一個封裝的功能。它的格式為：
MAC 就是消息驗證碼，用來驗證數據的完整性，保證中途沒有篡改。這個消息驗證碼比數字簽名弱一些，使用的是對稱密鑰加密摘要。數字簽名使用的是非對稱密鑰加密，有區分公鑰私鑰。
記錄協議的主要目的有這幾個，為其他 SSL 子協議提供了以下服務：
TCP 三次握手結束並且和代理伺服器成功連接後，建聯成功，客戶端 A 就開始發起 SSL 連接，首先會進入 SSL 握手階段。
SSL 握手階段的主要目的有這么幾個：
SSL 握手的流程並不是一成不變的，根據實際的應用場景來。主要有三種：
SSL 握手的完整的交互過程如下，這里是驗證服務端又驗證了客戶端的情況：
我們的請求只驗證服務端，所以 7,8,9 是不存在的。
現在具體分析每一個階段的內容。
Client Hello
作為 SSL 握手的第一個握手包，我們詳細分析和理解一下包的內容。
下面是 Wireshark 解析好的這個 SSL 協議的數據包：
這個包如何解讀，按照之前對 SSL 協議的分析，其實分成兩個部分：
因為是握手過程，密鑰還沒協商，這里還是使用明文傳輸，記錄協議的數據載體就是明文的 SSL 握手協議。
SSL 握手協議的格式為：
我們可以從握手協議的數據包中得到這些信息：
密碼套件隨著密碼學的發展而發展，而且根據現實應用中，可能會有某些密碼被破解，從而導緻密碼套件可能會導致安全問題，所以一般都會使用當前最新最安全的密碼套件。
在 Android 系統中，一般情況下，使用 SSLSocket進行連接的時候，會帶上系統默認的支持的密碼套件。但是這個有個缺點，比如某些密碼套件的加密演算法被破解或者出現安全漏洞，而且要跟著系統升級反應緩慢。OkHttp 在進行 SSL 握手的時候，會使用 ConnectionSpec 類中帶上提供了一系列最新的密碼套件。可以從注釋上看，這些密碼套件在 Chrome 51 和 Android 7.0 以上得到了完全支持。
然後，再把這些密碼套件和 Android 系統支持的密碼套件取交集，提交給服務端。這樣，萬一哪個密碼套件有問題，OkHttp 官方會下降支持。網路庫 OkHttp 庫會隨著版本的迭代，不斷地去提供比較新的密碼套件，並且放棄那些不安全的密碼套件。接入應用即時更新 OkHttp，就不用等待緩慢的系統更新了。
如果提供的所有密碼套件服務端都不支持，OkHttp 有回退機制，退而求其次，選比較舊的套件。
Server Hello
服務端收到了客戶端的 Hello，通過客戶端的配置信息，結合服務端的自身情況，給出了最終的配置信息。
Wireshark 解析後的內容如下：
具體內容如下：
Certificate
上面的 Server Hello 已經制定了接下來的非對稱加密演算法
服務端下發證書，客戶端驗證服務端的身份，並且取出證書攜帶的公鑰，這個公鑰是交換加密演算法的公鑰。也就是在 Server Hello 階段指定的 ECDHE （EC Diffie-Hellman）演算法，也是通常說的 DH 加密。
這個 Certificate 消息下發了從攜帶自己公鑰的數字證書和 CA 證書的證書鏈，在 Certificates 欄位中：
CA 是 PKI 體系的重要組成部分，稱為認證機構。
那什麼是 CA 證書？就是用來 CA 中心發布的，認證該服務單證書的合法性，可以確保該證書來源可靠而不是被中間人替換了。但是 CA 證書也可能被中間人攔截造假？那就再用一個證書來認證它。看起來好像沒完沒了。實際上到最後有一個根 CA 證書，這個證書存儲再瀏覽器或者操作系統中，是系統直接信任的。
服務端證書需要 CA 證書做認證。使用的還是數字簽名方式，從數據中摘要一段信息，用 CA 證書的加密。然後驗證的時候時候，用 CA 證書的公鑰解密，用同樣的摘要演算法摘要數據部分和解密好的信息進行比較。
客戶端在驗證服務端證書的有效性有這樣的一個過程。首先會找到該證書的認證證書，也就是中級 CA 證書。然後找中級 CA 證書的認證證書，可以是另一個中級 CA 證書，也可能是根 CA 證書。這樣直到根 CA 證書。
接著從根 CA 證書開始往下去驗證數字簽名。比如有這樣的證書鏈：根 CA 證書-> 中級 CA 證書 -> 服務端證書。用 CA 證書的公鑰去驗證中級證書的數字簽名，再用中級證書的公鑰去驗證伺服器證書的數字簽名。任何一個環節驗證失敗，就可以認為證書不合法。
這就是整個證書鏈的認證過程：
查看抓到的包的數據，發現只有兩個證書。為服務端證書和中級 CA 證書。根 CA 證書呢？順藤摸瓜找到它。
首先看服務端證書。它內容如下：
從這個證書中我們可以窺見這些信息：
首先是 signedCertificate 欄位的內容，即數字證書的數據：
然後是證書頒發機構的簽名信息：
從上面的 issuer 可以了解到，認證該伺服器證書的 CA 證書為 GeoTrust SSL CA - G3 ，我們從 Certificates 找到對應的中級證書的內容如下（中級證書可以有好幾級，我們這兒只有一級）：
可以得到中級證書名為 GeoTrust SSL CA - G3 ，證書組織為 GeoTrust Inc. 。
認證該 CA 證書的證書呢？還是看 issue 欄位，認證證書名為 GeoTrust Global CA ，組織同樣是 GeoTrust Inc. 。
其實這個就是根 CA 證書。在這個請求中沒有找到，但在瀏覽器或者操作系統可以找到。一般的瀏覽器和系統都會內置該 CA 證書。所以根證書是受瀏覽器或者操作系統信任的，無需其他證書做擔保。
如果想要自己的系統再信任某些非通用的權威機構的根 CA 證書，那麼就去安裝它。
比如我的 Windows 系統就安裝了 GeoTrust Global CA 證書：
像我們平時使用 Charles 抓 HTTPS 就是這個原理，把 Charles 的 CA 證書安裝在手機中，成為受信任的根 CA 證書。
基本原理就是，Charles 代理作為 SSL 隧道，並沒有透明傳輸，而是作為一個中間人，攔截了 SSL 握手信息，修改裡面的 CA 證書。仿冒手機端和真實服務端建立連接獲取主密鑰，然後又仿冒服務端和手機客戶端建立 SSL 連接，修改服務端證書的 CA 和數字簽名，這樣 Charles 就可以解析到加密的 HTTP 內容了。
修改後的服務端證書如下，可以看到 issuer 被替換成了 Charles 的證書。
❷ WPE抓包發包,怎麼用
1、對於網游的封包來說，我們關心的內容只是IP包中的資料信息，我們可以使用Wpe輕松截獲客戶端與伺服器之間交換資料，然後根據自己所需要的進行資料修改達到刷裝備的目的。
2、WPE使用方法：執行WPE會有下列幾項功能可選擇：SELECTGAME選擇目前在記憶體中您想攔截的程式，您只需雙擊該程式名稱即可。TRACE追蹤功能。用來追蹤擷取程式送收的封包。WPE必須先完成點選欲追蹤的程式名稱，才可以使用此項目。
3、在商店隨便買樣道具抓包，打開數據包：然後把紅圈位置改成對應數字，點紅25後一位步長1遞進。前面紅圈改25，後面改05，不會找位置就去從後往前數00其他所有數據全部不要改動。
4、是。根據wpe官網查詢：wpe是一個網路游戲抓包神器，裡面抓到包就是成功了。抓包就是將網路傳輸發送與接收的數據包進行截獲、重發、編輯、轉存等操作，也用來檢查網路安全。
5、目標程序選定游戲主程序上面有一個類似於播放器播放按鈕的按鈕打開然後進CF點某樣東西。