一般情況下，在建立 HTTPS 連線的時候，客戶端會去檢查伺服器端的憑證。只有憑證合法的情況下才繼續連線。
客戶端會有一個憑證列表，該憑證要在列表裡面才會繼續連線。
這是為什麼，在建立 mitmproxy 的撈封包環境之前，需要把字簽憑證加進列表裡面，為的是讓客戶端願意和我們建立 HTTPS 連線。
SSL Pinning 的機制在於，客戶端永遠只會相信一組憑證。
比方說客戶端程式是用來跟 A 網站連線的，而 A 網站的憑證是 B，那麼 SSL Pinning 就是負責把 B Pinning 起來。
當今天的連線加入一個中間人，客戶端就可以藉由憑證發現連線的節點不是一對一的，因此就放棄連線。
以 PC 的環境來說，一般情況下，程式相信的憑證列表就是作業系統的憑證列表。
但這不代表客戶端程式不能有自己的憑證列表。舉例來說，瀏覽器就是一個例子。
而 mitmproxy 的官方文件也有教怎麼在常見的瀏覽器新增憑證，方法會和作業系統的新增方式不同。
如果在確定 mitmproxy 的憑證有正確設定好的情況下，就無法用中間人攻擊去劫持連線了。
有一個 APP 叫麥當勞報報，該 APP 是有 root 偵測 和 SSL Pinning 保護的。
如果裝置有 root，APP 會完全無法使用。
當時我想對這個 APP 撈封包，首先我先對 APP 反編譯，找到偵測 root 的函式，讓它永遠回傳 false。
另外打破 SSL Pinning 的方法，我是在 GitHub 上找到現成的工具 apk-mitm 直接使用的。
實際上，要將反編譯且修改後的程式碼，重新打包回 APK 的時候，有蠻複雜的簽署 APK 流程。
不過 apk-mitm 會幫忙處理好簽署 APK 的流程，有點一舉兩得的感覺。
iThome鐵人賽
看影片追技術