安卓怎么下载抓包

‘壹’ 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包后也断开连接了。