安卓怎麼下載抓包

『壹』 android socket請求數據怎麼抓包

從網路上面搜索到的資料看，要抓取手機中app的網路包有下面幾種方式：
(1).將tcpmp移植到Android平台，然後在命令行下啟動tcpmp進行抓包。Tcpmp程序實際上可以看作是wireshark的命令行版本，將該程序移植到Android平台直接抓包，這是一種最直接的抓包方式，然後將抓獲的數據包文件，從手機傳到windows系統上用wireshark打開進行分析，這種方式貌似不能用於蘋果手機。
(2).使用fiddler，在windows系統上打開fiddler軟體，該軟體會將我們的電腦變成一個代理，然後在手機上設置wifi網路，將代理指定為開啟fiddler的那台電腦，並且埠設置為fiddler偵聽的8888埠，這時候使用手機訪問的數據，就會通過該代理，在fiddler中就可以看到http的數據包。這種方法我試了半天怎麼都看不到數據包，不知道哪裡出問題了，根據原理，這種方式支持可以通過代理訪問網路的手機。所以從原理上說是支持Android和蘋果手機的。
(3).通過各種方式在pc電腦上建立wifi熱點，然後使用wireshark在pc電腦上監視該wifi熱點，通過手機連接該熱點訪問網路。這樣wireshark會獲取所有流經該熱點的數據包這種方式適用於所有能夠無線訪問的手機，也就是說所有的Android和蘋果手機。
那麼如何在pc電腦上建立wifi熱點呢，有這么幾種辦法：
(1).Win7電腦經過設置，可以將無線網卡設置為wifi熱點，這種方法我以前用過，可以成功，但是步驟繁瑣，而且不一定能夠成功，其他的windows系統估計就沒戲了。
(2).使用軟體自動建立wifi熱點，不需要自己手工配置，這樣的軟體有Connectify Hotspot，獵豹免費wifi，360免費wifi軟體，這幾個軟體我都使用過，比較好用，這種方式同樣也只能針對有無線網卡的筆記本電腦，原理也是將筆記本電腦上的無線網卡建立熱點了，只不過是軟體自動的，不需要人工設置，比方法1要方便。
注意：經過實驗發現，手機連接這種方式建立的熱點，所發送的數據，用wireshark去抓包，需要捕獲電腦上本身聯網的那個「網路連接」，例如我的筆記本上面有一個「本地連接」，該連接是使用有線網路的。我用獵豹免費wifi軟體建立一個熱點之後，我的電腦上多出一個「無線網路連接3」，可以看到該「無線網路連接3」是獵豹生成的，但是我抓包的時候，wireshark需要捕獲「本地連接」上的包，也就是我的手機訪問的數據實際上還是使用的「本地連接」，通信IP也是「本地連接」上的IP地址，而在手機的wifi連接設置中看到的ip地址，在我抓的包中也搜不到，也就是說手機通過該熱點訪問網路，實際上還是使用的「本地連接」的IP地址，至於是什麼原理，我目前也不太清楚。但是下面要說的隨身wifi硬體則與此不同，隨身wifi是建立了網卡。
(3).使用隨身wifi硬體。這種也是很方便的方法，而且比較穩定，對筆記本電腦和台式機都可以使用。我之前買了一個360的隨身wifi(不是打廣告，本人對360公司不感冒，但是他的隨身wifi做的確實還可以，同事中有買小米wifi的，不太穩定)。只要在360的官網上下載驅動，直接插上隨身wifi就可以使用，我推薦使用這種方法。
如果你用的是筆記本電腦可以使用方法2，如果是台式機器可以使用方法3。

『貳』 安卓7.0+https抓包新姿勢（無需Root）

在平常的安全測試過程中，我們都會攔截應用程序的HTTPS流量。通過向Android添加自定義CA，可以直接完成此操作。但是，從Android 7.0以上開始，應用程序不再信任客戶端證書，除非App應用程序自身明確啟用此功能。

在下面這篇文章中，介紹一個新的 Magisk模塊，通過Magisk模塊自動將客戶端證書添加到系統范圍的信任存儲區，這樣就可以完成對App應用程序的Https抓包了。

攔截Android上的HTTPS，只需以下幾步：

下面這些步驟做完後，就可以查看瀏覽器與伺服器之間發送的HTTPS流量了。

這種方法同樣適用於應用程序的Https流量，因為在默認情況下應用程序會信任所有已安裝的用戶證書。

補充說明

廠商阻止Https抓包的方式：
阻止應用程序流量被截獲的一種方法就是為應用程序本身安裝專有證書。這就意味著在每個SSL連接上，伺服器提供的證書將與本地存儲的證書進行比較。只有伺服器可以提供正確的標識，SSL連接才會成功。這是一個很好的安全功能，但實現起來是比較麻煩的，

我們知道從Android7.0開始，默認情況下，應用程序已經不再信任用戶證書。
在開發階段，開發人員可以通過更改應用程序中的AndroidManifest.xml文件，來配置networkSecurityConfig屬性，選擇接受用戶證書，即可完成對應用程序的Https抓包分析測試。

還有一種方法是反編譯App，修改和重新編譯應用程序，如果該App應用程序有加殼，加密，等配置，那反編譯的過程將非常困難。可以在warroom.securestate.com上找到App的反編譯教程。

還有另一種方法是將用戶證書添加到系統存儲中。存儲目錄位於：/system/etc/security/cacerts，包含每個已安裝根證書的文件。但這是需要對/system/etc/security/cacerts目錄有讀、寫的許可權，正常的手機沒有Root，是不具備此項功能的。如果把手機Root，並且這是一項非常危險的操作。

Magisk是一個「通用無系統介面「，可以在不改變系統本身的情況下創建系統的修改掩碼。」Magisk不修改/ system分區目錄，所以這是一個非常好的抓包解決方式，其中應用程序已經增強了root檢測。通過目標應用程序來激活「Magisk Hide」，使Magisk變得完全不可見。

Magisk還支持相當容易創建的自定義模塊。為了將任何用戶證書識別為系統證書，我們製作了一個簡單的Magisk模塊，可以在我們的github上找到： https://github.com/NVISO-BE/MagiskTrustUserCerts

該模塊的功能如下，非常基礎：

安裝完後，Magisk模塊的內容安裝在/magisk/trustusercerts/上。此文件夾包含多個文件，但最重要的是系統目錄。此目錄自動與real/ system目錄合並，實際上不會觸及到/system分區目錄。因此，/magisk/trusteusercerts/etc/security/中的所有證書都將以/system/etc/ security結尾。

該模塊使用如下：

安裝後，證書將顯示在系統范圍的信任存儲中，並受應用程序信任：

當然，如果應用程序自身已做了專用SSL連接，仍然無法攔截HTTPS流量，但這個小模塊使Android7.0+應用程序的運行方式與Android之前的7.0以下應用程序相同。

英文原版鏈接： https://blog.nviso.be/2017/12/22/intercepting-https-traffic-from-apps-on-android-7-using-magisk-burp/

『叄』 如何在 Android 手機上實現抓包

千鋒扣丁學堂Android開發為您解答：
tcpmp是最快捷方便的抓包方式，還可以加深對網路協議的理解。android下可以通過如下方式抓包：

1 Android上啟動tcpmp

Android設備可以把tcpmp的可執行文件上傳到android設備上，然後通過mac遠程登錄android設備運行tcpmp，前提是這台android設備必須已經root過。步驟如下：

下載android版本的tcpmp為android系統編譯的tcpmp版本。

通過adb將tcpmp上傳到android設備

通過adb push將tcpmp文件上傳到特定的目錄，這里我們選擇/sdcard/data目錄。

在android設備上運行tcpmp

通過adb shell登陸設備，並執行tcpmp，最後一步執行./tcpmp即可。

2. 分析tcpmp輸出

經過上面的步驟成功運行tcpmp之後，接下來就可以分析輸出的網路包內容了，iOS設備和Android設備的輸出是一致的。我們先來解析下幾個基本的格式：

圖中紅色方框內的部分是一個ip包的詳細記錄，類似的紀錄還有好幾條。這里我們著重分析第一條的各部分欄位含義。

14:37:41.615018 很簡單，是該包接收到的時間。

17.143.164.37.5223 是發送方的ip地址及埠號(5223是埠號)。

10.29.44.140.58036 是我android的ip地址及埠號。

Flags [P.]
是tcp包header部分的第14個位元組的P位。這個位元組所包含的幾個flag很重要，後面我會單獨詳細講解。這里P位表示接受方需要馬上將包push到應用層。

seq 1:54
tcp包的seq號，1是起始值，54結束值。tcp之所以被認為是流，是因為tcp包所攜帶的每一個位元組都有標號(seq號)。1:54表明總共有54個位元組被接受，其中一個位元組是三次握手階段所使用，所以一共發送的長度是53位元組。

ack 101 tcp包的ack號，ack 101表明seq號為100的位元組已被確認收到，下一個期望接收的seq號從101開始。

win 255 win表示的是tcp包發送方，作為接受方還可以接受的位元組數。這里win
255表明ip為17.143.164.37的主機還可以接受255個位元組。

options [nop,nop,…] options[…]表示的是該tcp包的options區域，nop是no
opertion的縮寫，沒什麼實際用途，主要是用做padding，因為options區域按協議規定必須是4位元組的倍數。

options[… TS val 2381386761] ts
val這個值是tcp包的時間戳，不過這個時間戳和設備的系統時間沒啥關系，剛開始是隨機值，後面隨著系統時鍾自增長。這個時間戳主要用處是seq序列號越界從0重新開始後，可以確認包的順序。

options[… ecr 427050796] ts ecr這個值主要用來計算RTT。比如A發送一個tcp包給B，A會在包里帶上TS
val，B收到之後在ack包里再把這個值原樣返回，A收到B的ack包之後再根據本地時鍾就可以計算出RTT了。這個值只在ack包里有效，非ack包ecr的值就為0.

length 53 這個length是應用層傳過來的數據大小，不包括tcp的header。這個值和我們上面分析的seq 1:54是一致的。

以上就是一個基本的tcp包結構，大家可以按照上面的分析再把其他幾個包理解下。我們在做應用的時候面對的更多是http協議，但對一個http請求是怎麼通過tcp/ip分解成一個個的packet，然後怎麼在網路上穩定可靠的傳輸，要有個基本的印象。下面我們再看下tcpmp更多的功能，這些功能都是基於對tcp/ip協議的理解，遇到不理解的建議多google下相關的技術概念。

3. tcpmp知識拓展

再繼續深入tcpmp之前，先貼上一張tcp header格式圖，常看常新。

[https://github.com/music4kid/music4kid.github.io/blob/master/images/tcpheader.png?raw=true](https://github.com/music4kid/music4kid.github.io/blob/master/images/tcpheader.png?raw=true)"
width="1056">

3.1 TCP Flags(tcp header第十四個位元組)

我們再仔細看下上面提到的flags概念，flags位於tcp
header的第十四個位元組，包含8個比特位，也就是上圖的CWR到FIN。這8個比特位都有特定的功能用途，分別是：CWR，ECE，URG，ACK，PSH，RST，SYN，FIN。

CWR ，ECE 兩個flag是用來配合做congestion
control的，一般情況下和應用層關系不大。發送方的包ECE(ECN-Echo)為0的時候表示出現了congestion，接收方回的包里CWR(Congestion
Window Reced)為1表明收到congestion信息並做了處理。我們重點看其他六個flag。

URG
URG代表Urgent，表明包的優先順序高，需要優先傳送對方並處理。像我們平時使用terminal的時候經常ctrl+c來結束某個任務，這種命令產生的網路數據包就需要urgent。

ACK
也就是我們所熟悉的ack包，用來告訴對方上一個數據包已經成功收到。不過一般不會為了ack單獨發送一個包，都是在下一個要發送的packet里設置ack位，這屬於tcp的優化機制，參見delayed
ack。

PSH Push我們上面解釋過，接收方接收到P位的flag包需要馬上將包交給應用層處理，一般我們在http
request的最後一個包里都能看到P位被設置。

RST Reset位，表明packet的發送方馬上就要斷開當前連接了。在http請求結束的時候一般可以看到一個數據包設置了RST位。

SYN
SYN位在發送建立連接請求的時候會設置，我們所熟悉的tcp三次握手就是syn和ack位的配合：syn->syn+ack->ack。

FIN
Finish位設置了就表示發送方沒有更多的數據要發送了，之後就要單向關閉連接了，接收方一般會回一個ack包。接收方再同理發送一個FIN就可以雙向關閉連接了。

這8個flag首字母分別是：C E U A P R S F。初看難以記憶，我腦洞了下，把它們組合成 supr
cafe，當然少了super少了個e，我可以將就下。我們在使用tcpmp的時候會經常看到這幾個flag，[S],[P],[R],[F],[.]。其他幾個都好理解，[.]特殊點，是個佔位符，沒有其他flag被設置的時候就顯示這個佔位符，一般表示ack。

3.2 tcpmp 更多使用參數

這部分我們來看下tcpmp常用的一些命令參數。文章最開始部分的tcpmp命令是這樣的：sudo tcpmp -i rvi0 -AAl。
-i rvi0 -AAl都是屬於參數部分。常見的有這些：

-i, 要監聽的網卡名稱，-i rvi0監聽虛擬網卡。不設置的時候默認監聽所有網卡流量。

-A, 用ASCII碼展示所截取的流量，一般用於網頁或者app里http請求。-AA可以獲取更多的信息。

-X，用ASCII碼和hex來展示包的內容，和上面的-A比較像。-XX可以展示更多的信息(比如link layer的header)。

-n，不解析hostname,tcpmp會優先暫時主機的名字。-nn則不展示主機名和埠名(比如443埠會被展示成https)。

-s，截取的包位元組長度，默認情況下tcpmp會展示96位元組的長度，要獲取完整的長度可以用-s0或者-s1600。

-c，只截取指定數目的包，然後退出。

-v，展示更多的有用信息，還可以用-vv -vvv增加信息的展示量。

src，指明ip包的發送方地址。

dst，指明ip包的接收方地址。

port，指明tcp包發送方或者接收方的埠號。

and,or,not,操作法，字面意思。

上面幾個是我個人比較常用的，更多的參數可以參考這個詳細文檔。有興趣的可以分析下面幾個例子練習下：

tcpmp 『tcp[13] & 16!=0』

tcpmp src port 80 and tcp

tcpmp -vv src and not dst port 23

tcpmp -nnvvS src 192.0.1.100 and dst port 443

4. 用tcpmp分析http完整請求

說了這么多，我們再來實戰下，看一個完整的http請求流程。sudo tcpmp -i rvi0 -AAl src 60.28.215.123 or
dst 60.28.215.123

列出了6個前面的packet，10.29.44.240是我android的ip地址，60.28.215.123是知乎server的ip地址，紅色方框內是android發出的packet，白色方框內是server發出的packet。packet1是android三次握手的第一個syn包，packet2是server
ack+syn的包，packet3是android ack的包。這3個packet之後tcp的三次握手就完成了。

packet4是android發出的http
request。長度只有240個位元組，所以一個packet就發過去了，當然還設置了flags的P位，request需要馬上被應用層處理。包裡面出現了spdy，點贊。

packet5是server ack剛收到的包，長度位0，所以這僅僅是一個ack包。

packet6是server返回http的response了，1388個位元組。packet5和packet6都ack了seq為241的包，當然是為了增加ack的成功率。

中間還有好幾個packet就不仔細分析了，最後再看下請求完成的最後幾個包：

最後兩個packet比較簡單，android發送個FIN+ACK的包就斷開連接了，server直接發送了一個RST包後也斷開連接了。