有的人可能會有些疑問，這個好像跟逆向沒啥關係，其實不是的。逆向工程的本身就是在不能輕易獲得必要的生產信息的情況下對成品進行分析，然後推導出設計原理的過程。把成品看成一個黑盒，那麼這個黑盒中對外開放的接口就顯得尤爲重要了。
所以在拿到一個新的app之後，第一件事不是忙着去編譯反編譯巴拉巴拉折騰一堆。而是對這個黑盒的接口做測試。
這裏介紹一些我曾經用到過的抓包工具。
1、wireshark。（這個除了http，看得到更多的協議）
2、fidder（http）
3、burpsuite（http）
這裏的這3個工具是我比較常用的。這裏介紹下他們的使用方法。
對於wireshark，如果我們要使用它對手機端app進行抓包分析，需要先在pc端安裝一個無線網卡，又或者是360免費wifi之類的軟件。總之就是讓你的pc釋放出一個可以讓android手機連上的熱點，讓android機的流量經過pc，才能對流量進行分析。wireshark因爲可以抓取除了http之外的協議類型，所以使用的範圍可以更加廣一點。
另外有點需要介紹的是wireshark對網絡封包的抓取是旁路的，其本質就是wireshark使用的是對網卡數據的複製，所有經過網卡的流量都會被抓取。這樣一來就不限制是應用層面上的數據包了，而是可以抓取到更多更全面的包。但是因爲是旁路，所以無法去修改這些數據包。簡單的可以理解爲它只是將流量copy出來一份，供你查看而已。
如果要做一些比較猥瑣的事情。。。比如修改request和resopnse，就要用到2、3工具了。當然前提是針對應用層面上的協議。比如說這裏的http、https、websocket等。有的人可能會覺得到這裏，味道就有些變了。確實是這樣，如果你修改了應用的request或者response值。我們其實就可以視爲你已經發動了一次中間人攻擊。將我們的代理工具視應用的web 後臺和app之間中間人，在雙方都不知道的情況下我們修改了一次他們之間的通信，這種對request或者response包的重構，可能是我們精心設計的，以爲了達到某些目的。可能是或者某些數據或者驗證某些想法。話題有點跑遠了，我們回到HTTP抓包上。。
下面是HTTP協議抓包介紹：
對於fidder，burpsuite等http流量，可以通過代理的方法進行抓取。
有的人可能對HTTP代理不太理解。這裏簡單介紹些HTTP代理的運作。
上述的代理工具，burp，fidder這些工具其實本質上就是一個HTTP代理服務器。在不同的系統代理的設置有不同的方法。一些應用比如瀏覽器，有自己的代理選項，找到高級設置頁面去設置即可，但是這樣設置的代理可能只在瀏覽器中生效。如果是windows系統，可以在IE瀏覽器中設置代理(這裏設置的就是全局的代理了)。如果是android手機，可以在wifi設置的高級選項中設置代理。當我們在系統中設置了代理，這時候運行在我們系統中的http客戶端在發送請求的時候，就不會按照正常的流程去進行dns解析，而是直接去連接我們的代理服務器（比如這裏就是我們的burp和開放的代理端口，無論是http還是https亦或是其他支持的代理協議，全部都是連上這一個端口）。然後代理服務器接收到來自http客戶端的請求後再去連接真正的服務器。所以，我們經常是將代理看做是一箇中間人，實際上也確實是這樣。
下面簡單介紹下代理的設置方法。
具體就是讓android手機和pc 處於同一個局域網。然後在android機上設置代理（一般在在wifi設置裏面，點卡連接的wifi，然後點開高級設置，一般就可以看到）。設置代理的IP爲PC 的IP，端口爲任意沒佔用的端口就行。比如，android機和你的pc都連上一個熱點名稱叫test的wifi，然後查看pc的IP 爲192.168.1.100，就需要在android機上設置代理的ip爲192.168.1.100，端口任意，我一般是設爲8080,80xx之類的，只要不被佔用就行。
接下來需要打開fidder或者burp等代理軟件，這裏以burp爲例，
點開proxy選項，選擇options。這裏可以點擊add或者edit都行。
然後選擇你要監聽的ip和輸入監聽的端口，就是在android機上設置的那個ip和端口。這樣一來，android機的http流量就會經過burp，打開http history 選項卡，在列表中就可以看到我們截取的http流量
對於fidder，使用方法也是類似的，無非是找到設置代理的地方，然後將代理的ip 和端口填進去，然後開始監聽而已。
我們上面有提到過，burp還可以對http進行修改。我們可以很容易找到有intercept選項，這裏是攔截到的數據包，我們可以在option裏面設置需要攔截的數據包，然後進行一定的修改後再response。當然攔截request也是可以的。這裏做request和response修改是爲了更好的測試對應的接口，找到我們關注的信息。
具體的攔截規則這裏不介紹，只是提醒有這樣一個功能而已。關於burp，其實能做的事情還有很多，有更多更有意思的功能，有興趣可以私下交流。
上面是對於HTTP的截取，但是大多數情況下，http的截取已經幫不上很大的忙了。因爲大多數app開發者也認識到了http是明文的，容易被利用，所以將http升級到了更加安全的https。
下面是HTTPS協議抓包介紹：
如果想回頭先了解下https 的可以看
相比於傳統的HTTP抓包，HTTPS的抓包需要在設置代理之後加上一步證書的驗證。
在進行https中間人攻擊中，攻擊機以自己的證書替代服務器發給客戶端的證書。通常，客戶端不會驗證該證書，直接接受該證書，從而建立起和攻擊機的安全連接。這樣，客戶端發送的數據，都會被攻擊機獲取和解密。
注意上面說的是通常，但是也有不通常的。而且大多說網站和app也正在向這種不通常轉變。
首先是證書綁定(Certificate pinning)
證書鎖定Certificate Pinning是SSL/TLS加密的額外保證手段。它會將服務器的證書公鑰預先保存在客戶端。在建立安全連接的過程中，客戶端會將預置的公鑰和接受的證書做比較。如果一致，就建立連接，否則就拒絕連接。
Certificate Pinning在手機軟件中應用較多。因爲這些應用連接的服務器相對固定，可以預先將服務器的X509證書或者公鑰保存在App中。例如，蘋果應用商店Apple App Store就預置了這個功能。當使用中間人工具或者Fiddler之類的工具攔截數據，就會造成應用商店無法聯網的情況。
https代理抓包原理
簡單來講，就是burp充當客戶端與服務端通信，得到服務端的響應之後用自己的證書充當服務端與app通信。如果app不對證書進行驗證，或應用使用系統的ca信任庫進行驗證，而系統又安裝了burp的證書，burp就可以完成中間人的角色。所以我們的破解需要研究這個證書認證的過程，如果認證過程不完善，那我們就可以使用相應的手段進行破解。
我們首先來一個假的 https 的認證，比如我們在app開發過程中，認證邏輯中這麼寫：
static SSLSocketFactory trustAllSocketFactory() throws Exception{
TrustManager[] trustAllCerts = new TrustManager[]{
new X509TrustManager() {
public java.security.cert.X509Certificate[] getAcceptedIssuers() {
return null;
}
public void checkClientTrusted(X509Certificate[] certs, String authType) {
}
public void checkServerTrusted(X509Certificate[] certs, String authType) {
}
}
};
SSLContext sslCxt = SSLContext.getInstance("TLSv1.2");
sslCxt.init(null, trustAllCerts, null);
return sslCxt.getSocketFactory();
}
那麼恭喜你，你的https形同虛設。因爲這樣是接受所有證書(不對證書做驗證)，此時直接通過代理就可以抓包。像這代碼一般都是放在爬蟲裏抓數據的。那麼根本就不能算是用上了https。。
接下來，開發者要進階了。比如做了一些簡單的校驗。。。
這時候我們的HTTPS繞過遊戲纔算真正開始：
防線1：使用系統CA庫認證
針對信任系統自帶CA庫情況。有的開發者會信任系統自帶的CA庫證書，所以我們方法很簡單，將中間人證書放到系統庫中就行，自動會信任的。
比如安卓瀏覽器，Mac下的Chrome瀏覽器都是使用系統的信任證書做驗證。另外像下面這類代碼請求https，應用也是通過系統信任證書做驗證。
URL url = new URL(“https://www.baidu.com/“);
HttpsURLConnection urlConnection = (HttpsURLConnection) url.openConnection();
urlConnection.connect();
System.out.println(urlConnection.getResponseCode());
對於這種情況，將burp suite等工具的CA證書安裝到系統中就可破解。如下是安卓上安裝burp證書的過程。
1、導出burp ca證書
當然除了這種方法導出證書之外，還有另一種方法，就是在瀏覽器中直接訪問監聽端口，比如設置了127.0.0.1:8080 作爲代理端口，則就直接在瀏覽器訪問127.0.0.1：8080，這時候會彈出一個頁面
，下載後將證書保存到本地就行。
2、直接將證書上傳到手機，點擊安裝就可以，有的可能到設置裏面去找
這裏再順便說說pc 的吧。
PC上的firefox瀏覽器維護着一套受信憑據，點擊 首選項->高級->證書->查看證書，在證書機構中導入就可以了，如下圖
點擊查看證書，然後選擇服務器的選項卡，導入
導入剛纔的cacert.der文件，那麼在服務器中就會存在“PortSwigger CA”這樣的證書（burp的內置證書）
另外，我們還可以通過瀏覽器對我們證書的格式進行轉化，比如，這裏導出證書，我們會得到一個PortSwiggerCA.crt 格式的證書，保存到本地
3、最後信任證書
我們將剛剛導出的PortSwiggerCA.crt 導入到證書機構中，並勾選信任此CA標識的網站
完成之後，就可能正常訪問https 網站並通過burp抓取數據包了。這裏我說的是可能，因爲https 的繞過通常還沒有這麼簡單。請耐心看下去吧。
這裏多提一下，burp suite出於安全考慮，每次安裝都會重新生成一套CA證書，所以如果重新安裝了burp，要記得將系統中的CA證書更新。
前面提到了，將burp證書導入到android系統中並且設置信任就可以解決這個問題。顯然現在很多的android app 開發者也意識到了，系統信任的證書就就不一定是安全證書，而且很有可能是系統遭遇攻擊，惡意導入的中間人證書。
聰明的開發者從來就沒覺得這招很棘手，因爲讓這一招失效的方法也很簡單，就是不相信系統信任的證書，這個在app中可以設置。設置的方法這裏就不提了，反正也就是幾行代碼。那麼不相信系統證書，就只能相信自己自帶的證書了。這種情況app 中肯定會自帶server端的公鑰證書，而且一般都在assert目錄中，老鳥可能會對證書加密，不好找。但是大致方向就是這樣的。這種自帶證書進行驗證，就叫做證書綁定
證書綁定（Certificate Pinning）
前幾年的app雖然也都用了https協議，但只需要簡單地通過設置代理就能抓到，而從去年開始遇到的幾個app都不能走代理抓包了，一設置代理就說網絡有問題，聯不上網。經過分析其實很多都用了證書綁定技術，證書綁定簡單來說就是app只信任自己內置的證書，如果服務端的證書與app內的信任證書不符，客戶端主動拒絕連接，從而造成“網絡無法訪問”。如下是引用自stackexchange的關於證書驗證與綁定的相關評論。
Typically certificates are validated by checking the signature hierarchy; MyCert is signed by IntermediateCert which is signed by RootCert, and RootCert is listed in my computer’s “certificates to trust” store.
Certificate Pinning is where you ignore that whole thing, and say trust this certificate only or perhaps trust only certificates signed by this certificate.
So for example, if you go to google.com, your browser will trust the certificate if it’s signed by Verisign, Digicert, Thawte, or the Hong Kong Post Office (and dozens others). But if you use (on newer versions) Microsoft Windows Update, it will ONLY trust certificates signed by Microsoft. No Verisign, no Digicert, no Hong Kong Post office.
Also, some newer browsers (Chrome, for example) will do a variation of certificate pinning using the HSTS mechanism. They preload a specific set of public key hashes into this the HSTS configuration, which limits the valid certificates to only those which indicate the specified public key.
翻譯：
通常證書有自己的校驗結構和組織，我的證書是被一個由根證書籤名過的中間證書籤名過的，而根證書是在我的電腦中被加入了信任列表中的。
證書綁定的意思就是忽略所有的東西，只信任當前這個證書以及被這個證書籤名過的證書。
舉個例子，如果你想要的訪問google.com，那你的瀏覽器會信任一些被 Verisign, Digicert, Thawte,或者Hong Kong Post Office簽名過的證書，如果你更新到最新的windows 系統，那就只會信任 Microsoft 簽名過的證書，而不是Verisign, Digicert, Thawte,或者Hong Kong Post Office這些簽名過的證書。
當然一些新的瀏覽器，例如chrome等，會根據HSTS 機制做一些證書綁定的變體，它們預加載一些具體的公鑰哈希到HSTS配置中，這樣就限制了只有被指定了公鑰的有效證書才能生效。
（渣渣翻譯，不知道我理解到位沒有。。）
前面我們將中間人證書放到系統信任庫中，突破了第一道https防線，那麼現在我們遇到第二道防線，那就是證書綁定。證書綁定意味着，客戶端會使用自帶的證書來驗證服務器是否是可信。
一般來說這裏只是客戶端校驗服務器，而服務器是不校驗客戶端的。也就是誰來請求服務器都
根據證書綁定的描述，來突破這第二道安全防線：
從根本上來說，校驗邏輯是手機在做的，只要手機上的校驗邏輯沒有正常執行就可以繞過這個校驗流程。總的有下面幾個方法
1、反編譯app, 修改認證邏輯（不過這種方法慢慢不可取了，因爲大多數app現在已經不是這麼容易反編譯和回編譯了，而且回編譯之後還要重新簽名，繞過簽名又是一件麻煩事。這個方法效率太低）
2、用xposed或修改smali控制創建連接的SSLSocketFactory，使它不加載信任庫。
這裏簡單介紹下第二種方法，這是主流的也是我常用的方法。而且大神們已經給出瞭解決方案，我們拿來用就行。我一般是使用xposed+justTrustme 進行這種證書校驗後的https 包的抓取。這時候我們就可以使用xposed+justTrustme 來幫助我們抓包。
不過這裏因爲篇幅有限，我們重點是https抓包的問題，所以對於xposed框架，這裏只是提一下，不做介紹，後續會專門有關於xposed的專題整理出來。
xposed 是一款框架服務，安裝的話需要先root手機。justTrustme是一款 xposed 的插件，xposed 插件是可以自行開發的，所以可以按照自己的需要開發出很多強大的模塊出來。這裏的justTrustme 在https://github.com/Fuzion24/JustTrustMe/releases/latest 可以下載，然後安裝到安裝了xposed框架的手機中
如上圖就是安裝並激活了xposed框架。然後安裝我們的justTrustme 插件，並勾選啓用。
當我們安裝了插件，可以在模塊列表中看到我們的插件列表，這裏勾選啓用。啓用後可能需要重啓一次手機才能生效。手機重啓過後，我們就可以使用burp進行抓包了。你會發現原來不能抓包的https 現在都可以抓包了。
上面我們簡單介紹了下如果遇到經過完整校驗的https應該怎麼抓包，這裏用到了xposed框架。到這裏爲止，就可以解決大多數https抓包問題了，也就成功突破了這個第一道HTTPS的安全防線。但爲什麼是大多數，根據目前抓包的狀況看，依舊是有一些未知的https流量，顯然是一些安全程度要求較高的應用，除了做了證書方面的校驗，還採取了別的措施。
這裏介紹下我遇到的第三道HTTPS安全防線。
爲了更好說明這個第三道防線，我們再來看看HTTP請求的一些細節。
上面是一個簡單的http請求。這個請求是正常沒有使用代理的。這個時候客戶端向服務器的請求行裏面其實只有url部分，並沒有實際連接的主機名/IP，和端口號。因爲在沒有中間人代理的情況下，客戶端在發送HTTP報文之前，就已經知道了服務器的地址並且與之建立了TCP連接，沒必要在發送主機名和端口號。但是在代理的時候，情況就不一樣了。客戶端會先去連接代理服務器，而代理服務器卻沒法連接正確的服務器，因此客戶端發送給代理服務器的請求其實會在請求行裏面加上完成的url，方便代理服務器解析真正的服務器地址。
代理能實現的核心就是應用中的http客戶端會去連接我們設置的代理服務器。當然我們的代理服務器如果在系統層面上做了設置，標準的http客戶端是應該按照要求去執行的。就是系統中的http客戶端都應該在http請求前檢查下系統中是否設置了代理，如果有，就按照系統代理走。但是因爲HTTP客戶端基本都是應用自己實現的，所以不一定會這麼中規中矩地執行這些標準。雖然大多數HTTP客戶端都按照標準實現了代理功能，但是涉及到一些敏感的流量時候，並不一定會使用這種系統層面上的代理。可能是直接不發送請求給你報一個網絡異常，又或者是使用自己信得過的代理完成這次敏感的請求。總之，不同平臺有自己不同的處理方法。
那麼問題就出現在這了，一些有經驗的app開發人員會對當前app運行的網絡環境進行判斷，如果發現了使用代理上網，就不進行請求或者換用自己信得過的代理服務器。那麼我們依舊是抓不到這種HTTP數據。因爲這些數據壓根就沒走我們的代理服務器。
那麼有沒解決的方法？有的，只要想辦法讓流量經過我們就好
1、dns欺騙。這是一種常見的改變流量流向的方法。通過修改dns引導http客戶端連接上我們的目標服務器。但是這種方法侷限性也是比較明顯的。首先要架設dns服務器。知道目標流量的域名，纔能有效對流量進行引導
2、在網絡的上層進行流量的轉發。比如在上層流量中過濾出目標終端80和443端口的流量，並且將流量轉發到我們的代理服務器上。這種方法就比較高級了，完成流量引導之後就是坐等接收數據了，但是需要有專門的設備。而且這種設備一般也只有保密單位或者安全單位纔有。
3、使用***工具轉發流量到我們的目標服務器。這種方法需要拿到客戶端並安裝上***工具，但是如果這個前提容易辦到的話，就算是比較理想的一種方法了。
這裏我依舊選擇用方法3進行測試，因爲對於逆向學習來說，測試機就在手邊，安裝一個***工具根本就算不上是一項困難的事。android的***工具網上一搜一大堆，這裏我介紹我用的一款 drony (當然別的工具也行，開心就好)
安裝完成drony之後，我們可以切換到setting選項卡，並且選中網絡類型爲wifi。
然後點擊選中我們連接的wifi網絡，這個網絡應該要能連接上我們的代理服務器，比如與我們的代理服務器同網段什麼的。
然後進去將代理模式打開爲手動，設置代理的ip和端口號。最後點擊保存運行即可。這款軟件有一個我喜歡的好處就是可以設置直接的代理規則。比如可以指定哪些app的流量經過代理，甚至還可以指定ip和端口肚餓流量才轉發，因爲我們知道一個app中並不是所有流量都是http的，我們也不希望所有的流量到引導到我們的代理服務器，所以有針對性的可設置代理規則就很管用了。
其他的代理軟件也是大同小異的，不外乎就是一個代理ip和端口的設置。這是完成之後就去查看你的burp吧。然後你就會發現又多了不少的流量哈哈。這些流量就是之前不通過我們代理走出去的。
總的來說就是，我們的防線3，就是會判斷當前的網絡狀況，如果系統中有設置代理，就斷開連接。
但是，是否這就是終極方案？非也。我們傳統HTTPS還沒完呢。爲什麼這麼說？
我們前面提到的HTTPS其實只是做了一半。哪一半？那就是客戶端驗證了服務器。
那反之，還剩下一半。就是服務器也要驗證客戶端啊。
於是乎就有了HTTPS的雙向認證。那我們之前做的，其實只是HTTPS的單向認證而已。
雙向認證中，客戶端和服務器端都帶有自己的證書。而且互相校驗。
在我們上述的xposed方案中，客戶端這邊算是完全掌握了。即使服務器是中間人，客戶端都能完全信任。但是服務器呢？這個就不行了。因爲中間人沒有客戶端的證書，所以服務器是不會買賬的。。
額，好像說漏嘴了。。明顯的讓服務器買賬的方法，就是讓中間人擁有客戶端的證書哈哈。這樣豈不是就能完全僞裝成客戶端了麼？
是的，事實就是如此。只不過僞裝也是有難度的。雖然客戶端已經在你手中，但是老鳥們肯定經過處理，不會這麼容易讓你找到證書的藏身之地，即使找到了，也很可能二次加密了。這也是HTTPS最後的倔強。
但是道理還是簡單的。找到這個證書。導入到我們的burp。那麼burp就是一個完美的中間人。
首先我們注意到我們使用的代理工具，比如，burp，fidder等。這些工具是可以生成自己的證書的，也支持雙向證書的驗證。但是在使用這些工具抓取https數據包時，默認是單向認證的。也就是默認不轉發證書給服務器端。
接下來讓我們介紹幾種客戶端證書校驗的突破方法：
1、找到這些app對應的web平臺（可以根據域名這些判斷），然後直接在web應用上提取證書。一般在雙向認證過程中會彈出確認證書的彈出框，或者通過查看證書屬性，類似的方法提取證書。像有的金融類應用，還會提過一個U盾之類的東西，其實這種usb-key很可能就帶有證書，我們可以從中提取。如果本身具有導出功能的話更好。但是一般來說，這種安全要求較高的應用，一定是有各種方法阻止這個證書的獲取的。
安裝證書之後我們可以導出這個證書，或者事後keytools 工具來生成證書
2、很多時候app中的應用並不一定有對應的web應用。這時候就要我們在應用中找證書了。一般的證書會跟android 應用一起打包(當然也不排除有那種動態發送過來的)。這時我們可以搜索一些證書的後綴文件，例如cer/p12/pfx等，一般安卓下的爲bks，也可以先去assets或者res目錄下去找找。
找到證書之後，我們可以嘗試安裝一下證書。
當然安裝的過程肯定是會需要我們輸入私鑰的。這個私鑰也必定藏在app中。
用java代碼模擬雙向認證的請求的過程：
// 雙向認證證書
KeyStore keyStore = KeyStore.getInstance("PKCS12");
KeyStore trustStore = KeyStore.getInstance("jks");
// keyStore是服務端驗證客戶端的證書，trustStore是客戶端的信任證書
InputStream ksIn = new FileInputStream("E:/Java/jre8/lib/security/re/1.pfx");
InputStream tsIn = new FileInputStream(new File("E:/Java/jre8/lib/security/re/1"));
keyStore.load(ksIn, "123456".toCharArray());
SSLContext sslContext = SSLContexts.custom().loadTrustMaterial(trustStore, new TrustSelfSignedStrategy())
.loadKeyMaterial(keyStore, "123456".toCharArray()).setSecureRandom(new SecureRandom()).useSSL().build();
ConnectionSocketFactory pSocketFactory = new PlainConnectionSocketFactory();
SSLConnectionSocketFactory sslConnectionSocketFactory = new SSLConnectionSocketFactory(sslContext);
Registry<ConnectionSocketFactory> r = RegistryBuilder.<ConnectionSocketFactory> create()
.register("http", pSocketFactory).register("https", sslConnectionSocketFactory).build();
PoolingHttpClientConnectionManager secureConnectionManager = new PoolingHttpClientConnectionManager(r);
HttpClientBuilder secureHttpBulder = HttpClients.custom().setConnectionManager(secureConnectionManager);
HttpClient client = secureHttpBulder.build();
HttpGet httpGet = new HttpGet("https://xxx.com");
HttpResponse httpResponse1 = client.execute(httpGet);
我們可以參考上面java 請求中做客戶端校驗的代碼。按照這些寫法反編譯一次，找到類似的smali 代碼。
最後通過對smali 的研究找到其中的私鑰。
當然不排除這個私鑰的保存是在native層做的。這就需要對native層做分析了。不過這不是這文章說明要說明的內容。
最後讓我們來回顧下HTTP的幾個防線和繞過方法：
1、純HTTP
方法：設系統代理直接抓包
2、HTTPS 信任系統CA
方法：生成中間人證書，並導入到系統信任庫
3、HTTPS 證書綁定
方法：使用xposed + justTrustme 插件。繞過本地證書校驗邏輯
4、HTTPS + 代理檢測
方法：使用***工具代理
5、HTTPS 雙向認證
方法：從客戶端中找到內置證書，並安裝到中間人工具中進行請求。
以上就是面對HTTPS常用的幾招了。
一般來說，如果一款app中抓不到什麼包，但是app中的數據卻是正常加載，大多數都是因爲設置的問題或者是app中做了什麼限制，用其他的tcp協議還是比較少的。如果是直接用tcp的話這個代價也太高了，不太實際。
這裏說到了http抓包，那就再介紹一款神器吧，雖然這個工具在這裏暫時沒用到，但是在pc端的抓包分析中是必不可少的。這個神器叫Proxifier。有興趣的可以下載來看看，軟件很小但是功能很強大很實用。
界面是這樣的，安裝在pc上。我覺得這個好用的地方就是它可以設置代理規則。比如說，我們前面在本地8080口開了burp，想抓本地chrome的流量，原先有兩種方法。1、設置chrome代理，2、設置全局代理。當然在IE中設置全局代理也是可以的。但是這樣的話就會帶來了很多額外的流量，這些流量大多數是其他應用的，過多的無關流量會給我們分析加大難度。當然除了這一個原因外還有更重要的，並不是每一個應用都支持設置代理的。瀏覽器基本都可以，但是其他應用呢？比如你要抓取桌面版wechat 的包？除了全局代理，你還會怎麼做？
遇到這種情況，使用Proxifier事情就變得簡單多了。這個工具可以自己設置代理規則，甚至可以指定運行中的哪個應用的數據需要經過代理。如此一來，就更加方便我們對某一個目標盡心抓包分析了。
以上就是http(s) 抓包中我覺得有用的一些東西。如果使用Fidder進行抓包，過程也大致相同，感興趣的可以到這個老哥下看他的文章
對https 的抓包就先寫到這，如果有新的東西會不定時更新
水平有限歡迎指正