
第一次认真研究手机软件抓包是因为一个特别普通的场景App 页面数据不对后端说接口没问题前端说代码没问题我这个夹在中间的人只能去查网络层到底传了什么。网上一搜手机软件抓包有哪些出来的答案五花八门但真正上手才发现绝大多数人第一步就卡在概念上——装手机上的抓包工具和用电脑抓手机流量的工具压根是两条不同的路选错了一条后面全是白折腾。先说个结论这两条路的本质区别在于抓包软件站在哪里看流量。装手机上的是在手机内部开一个观察点所有数据在手机里就被记录下来了抓手机的是把手机的流量临时改道送到电脑上在电脑那边做统一的观察和分析。这个区别听起来简单却决定了工具选型、证书处理、使用场景甚至排查问题的思路全都不同。这篇就把两条路都拆开讲清楚。1. 先搞明白抓包到底在抓什么两条路的分水岭在哪1.1 抓包的本质就是在通信链路上放一个观察点任何手机App要联网数据都不是凭空出现的。一次普通的请求流程大致是App 把要访问的地址、请求头、参数打包成一个数据包交给系统网络模块然后经WiFi或移动网络发到服务器服务器响应后再原路返回。整个过程本质上是两个节点之间的快递收发。抓包就是在快递必经之路上安排一个快递点拆包检查员。数据包从手机发出时检查员先复制一份再把原件照常发出去服务器返回时也一样先在检查员这里留个底再交给手机App。这样我们就能看到完整的一来一回是哪个地址、带了什么参数、服务器回了什么。这个检查员放在不同位置就是不同流派的抓包。这里有一个很关键的概念需要区分抓包不等于解密。一台手机连上网通信是双向的但你得先保证这个通信链路确实经过了你的检查员你才有资格谈看到内容。很多人装了抓包工具却发现什么都没抓到绝大多数情况下不是工具坏了是流量根本没从工具预想的位置走。1.2 分水岭观察点放在手机里还是放在电脑上这两条路的分水岭就一句话检查员站在哪。装手机上的抓包工具作为一个App安装在手机里通过系统提供的网络通道服务在手机内部建立一个本地绕行点。所有App的流量在离开手机之前都会先经过这个绕行点抓包工具就在这里记录、解析。流量不出手机数据就被留下了。这类工具的特点是便携、即时、单机。抓手机的电脑上装一个代理抓包工具手机和电脑连同一个局域网然后在手机的WiFi设置里把HTTP代理指向电脑。这样一来手机发出的所有请求不再是直接发到互联网而是先发给电脑电脑记录完毕后再替手机转发出去。这类工具的特点是集中、强大、可扩展。打个比方。装手机上的就像在自家门口装了个摄像头只能拍到进出自己家门的人抓手机的就像是让小区里所有人的快递都先送到一个统一的中转站中转站里有齐全的分拣设备和登记系统你想要谁的件、想看哪一批翻个底朝天都行。理解了这一层后面工具怎么选、问题怎么排查逻辑就都顺了。2. 装手机上的这条路在手机内部做文章2.1 手机端抓包工具的原理调用系统本地虚拟网卡接口手机端抓包工具核心是利用了系统提供的一个能力允许应用创建一条本地虚拟网卡接口。你可以理解成系统允许某个App在手机内部开一条特殊的内部高速路并且默许所有网络数据都先在这条高速路上跑一圈再继续往前。抓包工具注册这个接口后流量会自发地从这里经过工具趁机把请求和响应都复制一份记录到自己的数据库里同时把原数据继续正常转发出去。用户看起来一切没变App该联网联网但数据已经被留底了。这里要特别提一个容易混淆的点这套机制是系统给本地应用用的所以它天然只能抓本机流量没法抓局域网里其他设备的包。想抓别人手机上的流量用手机端工具是做不到的。而且这种本地接管方式会被一部分App检测到有些安全意识强的App一旦发现系统存在流量接管通道会直接拒绝联网或者退出登录这在后面排查章节会细说。2.2 这条路有代表性的工具手机端抓包工具在安卓平台上比较丰富iOS上受系统限制数量少很多、功能也弱一些。这里把有代表性的列一下。工具平台特点适合场景HttpCanary小黄鸟安卓界面直观支持按应用过滤、查看完整请求/响应、断点调试、修改重放日常接口调试、学习HTTP协议Packet Capture安卓老牌轻量配置简单快速看一眼请求内容Reqable安卓/iOS/桌面新一代跨平台抓包工具多端数据同步需要在手机和电脑间切换工作流的人StreamiOSiOS端常见抓包工具界面简洁iOS设备上的基础抓包抓包精灵等国产工具安卓操作门槛低新手快速上手安卓端如果只让我推荐一个入门我一般先推荐 HttpCanary。它的知名度最高教程也多遇到问题随手一搜就有答案。它不光是能看还支持你对请求做修改然后重放——这在排查接口参数问题时非常实用。Reqable 属于后起之秀跨平台这一点很讨喜手机上抓完的数据包可以直接同步到电脑上继续分析省去了导出的麻烦。2.3 实际操作流程以安卓端工具为例装手机上的这条路实际操作非常轻量大概流程是这样安装抓包App以 HttpCanary 为例打开后按提示授予本地虚拟网卡接口权限。这一步系统会弹窗说明风险直接允许即可。在主界面选择你要抓的目标App。如果选了就只抓这一个App的流量其他App的流量自动忽略这样可以避免记录里全是乱七八糟的请求。点击开始按钮然后切到目标App里正常操作。比如你要查登录接口就去点一下登录按钮。回到抓包工具停止抓包查看记录。每条记录里包含请求地址、请求头、请求体、响应头、响应体基本想看的都有了。如果要看HTTPS加密内容还需要安装抓包工具提供的证书并信任。这一步在安卓7.0及以上版本会有额外的坑第四章详细说。从安装到抓到第一个包整个过程不超过五分钟。这就是手机端工具最大的价值——随手就能用不需要带电脑不依赖网络环境。2.4 要注意的天花板手机端工具虽然方便天花板也很明显。抓不到非本机流量前面说了它只能看本机。想抓智能音箱、另一台手机、平板上的流量这条路走不通。iOS限制大iOS 上本地抓包工具的权限被系统收得很紧功能远不如安卓端丰富很多工具只能做到基础查看。深度调试基本离不开电脑。稳定性一般长时间挂抓包工具手机发热会比较明显个别机型上还会出现断流。真机验证时手机端工具适合短时间快查不适合长时间跑。重放和篡改能力弱手机端工具能做简单的修改重放但和电脑端的断点、重写、Map Local 这些高级功能比差距比较大。如果你只是临时看一眼接口返回这条路足够但如果你要做系统的接口调试、多设备排查、自动化验证那得看第二条路。3. 抓手机的这条路把流量主动引到电脑上3.1 为什么要把流量引到电脑把流量引到电脑上听起来绕了一圈好像多此一举。但真正干过活的人都明白电脑端的优势是手机端完全替代不了的。首先是算力和展示能力。一次完整抓包数据量可能非常大手机上一个小屏幕翻记录翻到手抽筋。电脑上有大屏幕、有键盘、有鼠标工具可以分栏展示请求列表、请求详情、响应详情还能全文搜索、正则匹配、颜色高亮处理效率完全不是一个量级。其次是修改和重放能力。排查问题时最常用的手段是改一个参数重新发一遍请求验证是不是某个字段导致的问题。电脑端抓包工具可以在请求发出前拦截下来你修改完再放行也可以直接从历史记录里复制一条请求改完重放。这种玩法是接口调试的核心。再就是多设备支持和自动化。电脑上一开代理局域网内任何设备只要指向这台电脑都能抓手机、平板、模拟器全都行。配合脚本还能做自动化测试把抓包、改包、发包整个过程编程化。手机端工具在这方面基本是空白。3.2 PC代理抓包的工作原理PC代理抓包的核心机制是HTTP代理加上中间人技术。正常的请求链路是App → 路由器 → 服务器。开了代理之后变成App → 电脑代理工具→ 路由器 → 服务器。你在手机WiFi设置里填的那个代理地址相当于告诉手机你有网络请求先别自己发出去交给这个地址处理。电脑上的代理抓包工具收到请求后先记录再以自己的身份去请求服务器拿到响应后记录再返回给手机。整个过程对用户是无感的但数据已经被完整复制了一份。HTTP协议代理抓包是天然透明的因为它本身是明文。但HTTPS加了TLS加密代理工具如果只是转发只能看到密文看不到具体内容。要解开密文代理工具就得用中间人技术它伪造一个证书让手机以为它是服务器同时它又拿着真证书去请求服务器把两边的内容都解开来看。这个过程的实现方式就是让手机安装并信任代理工具自己生成的根证书。理解了这一点就理解了绝大多数HTTPS抓包难题的根源。3.3 主流工具怎么选电脑端抓包工具各有侧重按需求选就行。Charles功能最均衡界面友好断点调试、重写请求、Map Local/Remote 都有做客户端接口调试基本是事实标准。FiddlerWindows老牌和Charles功能重叠度高但在Windows生态里集成得更好。mitmproxy命令行工具支持Python脚本扩展适合自动化抓包场景。它没有图形界面但可以Web页面查看流量。Burp Suite安全测试领域标配代理功能强大带扫描器、注入工具。做安全测试选它做日常调试反而有点大材小用。Wireshark严格说它不是代理抓包工具而是网络层数据包分析工具直接抓网卡上的原始数据包。排查TCP连接、DNS解析、非HTTP协议等问题时它是绕不开的。如果你刚开始走这条路我建议从 Charles 或 Fiddler 二选一。这两者选哪个取决于操作系统Windows上两者顺手macOS上Charles更丝滑。先精通一个再学其他的会很快因为底层的代理和证书逻辑是通用的。3.4 完整流程以Charles为例在电脑端抓手机流量完整操作流程是这样确保电脑和手机连接同一个WiFi处于同一局域网。在电脑上打开Charles默认HTTP代理端口是8888不用改。菜单栏 Proxy Proxy Settings 里可以确认。记下电脑的局域网IP。macOS在系统偏好设置里看Windows在命令行敲ipconfig或者 Charles 菜单栏 Help Local IP Address 直接看。打开手机WiFi设置手动配置HTTP代理。服务器填电脑的IP端口填8888。回到Charles会弹出一个提示框询问是否允许来自该设备的请求点击Allow。如果没弹IPv4那一栏右键选择允许。用手机浏览器访问一个HTTP网站验证代理是否生效。浏览器访问没问题后再打开目标App。在Charles的SSL Proxying设置里添加目标域名或直接用通配符 *这样HTTPS流量才会被解密。手机浏览器访问 chls.pro/ssl 下载并安装Charles根证书。iPhone用户还需要去设置-通用-关于本机-证书信任设置里把信任开关打开。证书配好后Charles就能看到手机App发出的全部请求及响应内容。这套流程走完你会发现电脑端抓包的信息量比手机端大得多同一个App的每个接口、每个参数、每次跳转都清清楚楚列在列表里。3.5 这条路适合谁PC代理抓包适合的场景非常清晰你需要做系统性的接口调试、需要修改请求重放验证、需要同时观察多个设备的请求、需要把抓包数据和自动化流程衔接、需要做安全渗透测试。这些场景下手机端工具做不到或者做不好只有电脑端方案能顶上。它的代价是你得有一台电脑电脑和手机得在同一网络配置流程相对复杂。如果你只是偶尔看一眼数据上电脑抓包确实没必要。4. 两条路正面交锋选型逻辑与HTTPS这个共同的坎4.1 一张表看清两条路的差异把两条路的核心差异压缩成一张表选型心里就有数了。对比维度装手机上的手机端工具抓手机的PC代理工具工具部署位置手机App电脑软件是否需要电脑不需要必须抓包范围仅本机流量同一代理下所有设备流量观察点手机内部网络通道电脑端HTTP代理HTTPS解密支持但受系统版本限制支持证书信任后可全面解密修改重放基础支持强支持断点、重写、Map多设备支持不支持天然支持自动化扩展弱强支持脚本上手成本极低中等典型场景临时查接口、学习协议接口调试、安全测试、多设备排查选型逻辑很直白临时的、轻量的、单机的走手机端系统的、重度的、多设备的走PC端。两条路不是谁替代谁的关系而是互补关系。我自己的习惯是手机端常备一个应对随时可能出现的检查需求一旦要正儿八经排查一个接口问题就直接开电脑上Charles。4.2 HTTPS解密为什么是绕不开的坎不管走哪条路只要想抓HTTPS流量就一定会遇到证书问题。这个问题不解决抓到的全是一堆密文没有任何分析价值。HTTPS的原理可以简单理解成手机和服务器在正式通信前先协商出一个会话密钥之后所有数据都用这个密钥加密传输。抓包工具如果想看到内容必须让自己成为通信的中间人——手机信任抓包工具伪造的证书抓包工具再用真的证书去和服务器通信两边都解密。这个伪造证书被信任就是整个抓包链条里最核心的环节。工具生成了自己的根证书让手机装进去并标记为信任这样一来工具就可以为任意域名签发临时证书手机都会毫无保留地信任。整个过程可以用一个生活场景来理解快递员拿了一把配好的钥匙能够打开你家门前的快递柜检查包裹。前提是你手机同意把这把钥匙交给快递员抓包工具并且认可他开柜的行为。证书装上了不代表万事大吉。安卓和iOS两大平台各有各的限制往下看。4.3 Android 7.0 和 iOS 的证书信任细节安卓的坑主要出在系统版本上。Android 7.0 开始系统默认App只信任系统证书区里的证书不再信任用户自己安装的证书。也就是说就算你在设置里把抓包工具的证书装好了绝大多数App的HTTPS请求还是不会走抓包工具——因为App默认不认可你装的这个证书。这个机制堵死了很多人的入门之路也是新手最容易卡住的地方。处理方案大致有三条调试自己的App在App的network_security_config.xml里显式声明允许用户证书或者在debug构建里放开。这是最推荐的方式正规的开发流程都应该这么配。root手机后把证书放进系统证书区网上有Magisk模块可以一键把用户证书移动到系统目录。代价是需要一台能root的手机而且会让测试环境和真实用户环境产生差异。使用模拟器部分模拟器自带root证书直接改装到系统区省去不少麻烦。但模拟器毕竟是模拟器性能和兼容性不如真机。iOS这边逻辑相对简单但步骤多一步。证书下载安装后仅仅在已下载描述文件里点安装还不够必须再去设置-通用-关于本机-证书信任设置里把完全信任的开关打开。少这一步抓包的HTTPS仍然全是乱码。另外iOS上App的ATSApp Transport Security策略也会影响哪些地址能用HTTP、哪些必须HTTPS这也可能导致你明明配好了Charles却看不到部分请求。无论安卓还是iOS只要弄清楚证书有没有被目标App信任这一件事HTTPS抓包问题就已经解决了一半。另一半是App自己不让抓这个留到下一节说。5. 实战中绕不开的坑以及我的处理习惯5.1 App做了防抓包怎么办这是所有抓包场景里最让人头疼的代理配好了证书也装了浏览器访问Har文件验证一切正常结果一打开目标App要么直接提示网络异常要么请求全部超时要么干脆闪退。基本可以断定这个App做了防抓包。常见的防抓包手段有两种。一种是证书锁定SSL PinningApp在代码里内置了服务器证书的指纹或公钥信息每次建立HTTPS连接时它会自己检查对端的证书是不是它期望的那一个。抓包工具提供的伪造证书虽然被系统信任了但App不信任直接在应用层把连接掐断。另一种是代理检测App判断系统网络代理是否有异常比如代理地址指向了一个不正常的位置干脆拒绝走代理。对策要看你对这个App到底有什么权限。如果是在调试自己开发的App最合理的做法是在开发环境里临时关闭证书校验或者给测试包单独配一个信任用户证书的配置。如果是在做已获授权的黑盒安全测试通常会借助Frida这类动态插桩工具在运行时Hook掉证书校验相关的函数让校验逻辑失效也可以直接用现成的模块比如Xposed插件原理一样都是绕过校验。这里要提醒一句这类手段只应当在合法授权范围内使用未经授权去绕过别人App的安全机制性质完全不同。调试自己App时我是强烈反对一上来就Hook的那只会掩盖配置层面的问题。5.2 证书装上了却依然抓不到HTTPS内容有一次给同事排查他信誓旦旦说证书已经装好Charles就是看不到App的HTTPS请求。我拿过手机一看证书确实在用户证书区域里躺着但App的请求列表里全是TCP连接到某个IP、没有一条能展开看内容。原因就是前面说的Android 7.0默认不信任用户证书他的测试机没有rootApp的代码也没有开放用户证书信任。解决方案绕不开两条路要么给测试机root把证书塞进系统证书区要么在App开发期就配好network_security_config。如果你的测试场景不允许root还有个土办法找一台能root的旧手机专门当抓包测试机或者用Android模拟器。实测下来模拟器有时候反而比真机省心因为root和证书搬移都比较简单。当然模拟器和真机在硬件层行为有差异一些和传感器、短信、拨号相关的场景必须用真机但纯接口调试用模拟器没毛病。iOS端对应的问题则是记住了装证书、忘了开信任开关或者开了信任但App自身做了ATS强校验。iOS不越狱的情况下能做的不多能用代理工具看到多少算多少深度对抗场景系统限制太死。5.3 手机代理忘记关的惨痛教训这个坑几乎每个人都踩过在电脑上调试完顺手把电脑合盖走人手机却还停留在HTTP代理指向电脑IP的状态。第二天拿出手机无论打开什么App都提示无网络App一片片转圈吓得以为WiFi坏了或者手机出问题了。其实问题很简单——手机一直试图把流量发往一台已经离线或没开Charles的电脑自然什么都连不上。所以我把用完关代理当成一条铁律来执行。更稳妥的做法是在电脑端设置Charles自动退出时通知手机这个不是内置功能需要额外配置。实际操作中我最常用的方法更简单在手机WiFi代理设置里把代理改成无之后再顺手在电脑上关掉Charles养成一套固定的收尾动作基本不会再被这个坑绊倒。如果已经出现了断网问题第一步永远不是重启手机而是检查WiFi代理设置。5.4 抓不到包的排查顺序遇到抓不到包的问题按下面这个顺序过一遍能省掉大量盲目折腾的时间先验证代理通道本身通不通用手机浏览器访问一个HTTP网站如果Charles里有记录说明链路没问题问题出在目标App上如果连HTTP都没有记录说明代理设置就没生效回头检查IP、端口、同一局域网这些基础条件。检查抓包工具的过滤规则有时不是你抓不到是工具把目标App的流量过滤掉了。在Charles的Filters区域确认没有设奇怪的过滤条件。判断目标App是否做了防抓包替换成另一个没做过安全处理的App测试或者用浏览器访问同一个接口地址试试。如果其他App都能抓、就它抓不到大概率是SSL Pinning。检查协议类型有些App的重要业务不走HTTP/HTTPS而是走TCP长连接、UDP或者QUIC。Charles这类HTTP代理工具对非HTTP协议基本无能为力这时候得换成Wireshark抓网卡原始数据包才能看到。交叉验证工具配置换一个抓包工具重新试一遍。有时候不是方案错了是工具本身有Bug或系统兼容性问题。大部分抓不到包的问题在这个顺序里都能定位到具体环节。5.5 两条路都备好之后的个人建议工具不在多在顺手。我自己的组合是手机端装Reqable平时轻量看包、偶尔抓一下电脑端常驻Charles正经调试主力和Wireshark排查网络层疑难杂症。这三者覆盖了我日常百分之九十的抓包需求。最后分享一个偶尔能救命的小技巧抓包前先记下当前时间抓完包再看时间范围内的记录。如果数据量特别大先条件过滤掉图片、CSS、JavaScript这些静态资源只保留XHR和Document请求很多接口问题隐藏在这些看似无关的静态资源请求里过滤掉无关的噪音之后反而更容易看清真正的请求链路。