安卓模拟器抓包渗透测试：从环境搭建到实战技巧

1. 项目概述：为什么要在模拟器里抓包？

做APP或者小程序的安全测试，尤其是渗透测试，你迟早会遇到一个绕不开的坎：抓包。直接在真机上抓，证书问题、系统限制、网络配置，每一步都可能让你卡上半天。这时候，一个配置好的安卓模拟器就成了测试人员的“安全屋”。它提供了一个纯净、可控、可任意折腾的沙箱环境，让你能像在Web端测试一样，从容地拦截、分析、重放每一个网络请求。

这个项目的核心，就是搭建一套基于模拟器的APP/小程序抓包渗透测试环境。听起来简单，不就是装个模拟器、配个代理吗？但实际操作中，从模拟器选型、网络桥接、证书安装到绕过各种抓包检测，每一步都有讲究。我见过太多新手卡在“为什么Burp就是看不到包”或者“为什么装了证书还是提示不安全”这类问题上。今天，我就把这几年来在模拟器里抓包做渗透测试的完整流程、核心原理和踩过的坑，系统地梳理一遍。无论你是刚入行的安全测试工程师，还是想对自己产品进行安全自查的开发人员，这套方法都能让你快速上手，把精力集中在漏洞挖掘本身，而不是和环境斗智斗勇。

2. 环境搭建：模拟器与抓包工具选型解析

工欲善其事，必先利其器。环境搭建是第一步，也是决定后续测试是否顺畅的基础。这里的选型没有绝对的最优解，只有最适合当前测试场景的组合。

2.1 安卓模拟器的选择与考量

市面上模拟器很多，但并非所有都适合安全测试。我们需要关注几个关键点：系统纯净度、Root权限获取难度、网络配置灵活性、以及兼容性。

  • MuMu模拟器：近年来在安全圈很受欢迎。它的优势在于基于Android 9+，对较新的APP兼容性好，并且提供了便捷的Root开关和共享文件夹功能。其网络模式通常设置为“桥接模式”，可以让你宿主机和模拟器处于同一局域网，方便代理设置。我个人在做常规测试时，MuMu是我的首选。
  • 夜神模拟器：老牌选手，功能稳定，支持多开。它的Android 7版本非常经典，Root权限获取简单。但需要注意，部分版本可能存在内置广告或后台进程，可能干扰网络流量。建议使用其提供的“纯净版”或国际版。
  • 雷电模拟器：性能不错，同样支持多开和Root。它的网络设置选项也比较清晰。但有时在安装用户证书到系统目录时，可能需要额外的步骤。
  • 官方Android Studio AVD：最“原生”的模拟器，完全可控，适合深度定制和研究。但缺点是启动慢、资源占用高，且默认不开启Root。对于追求效率和快速测试的场景，它可能不是第一选择。

注意：避免使用那些冷门或高度定制化的模拟器，它们可能在网络栈或证书处理上有非标准行为，导致抓包失败。对于小程序测试，由于微信客户端对运行环境有检测，建议优先使用MuMu或夜神，并关注其是否支持安装微信官方版本。

我的常规选择是：MuMu模拟器（Android 9）用于大多数APP测试；如果需要测试对旧系统兼容性，则辅以一个夜神模拟器（Android 7）。安装后第一件事，就是在设置中开启“Root权限”（不同模拟器该选项位置不同，通常在“设置”->“关于手机”连续点击版本号开启开发者选项后，在开发者选项或高级设置中找到）。

2.2 抓包代理工具的核心对比

选好模拟器，接下来是选择“中间人”。Burp Suite、Fiddler、Charles是三巨头，但它们侧重点不同。

  • Burp Suite Professional：渗透测试的“瑞士军刀”。它不仅是抓包工具，更是一个完整的测试平台，包含Proxy、Repeater、Intruder、Scanner等强大模块。对于以漏洞挖掘为目的的渗透测试，Burp是毋庸置疑的首选。它的代理功能强大，拦截、修改、重放请求是核心工作流。社区版（免费）功能有限，专业版是生产力工具。
  • Fiddler Classic：免费、强大，特别是在Windows平台下。它的优势在于HTTP/HTTPS流量监控和调试非常直观，自动解码JSON、图片等。对于快速查看API请求响应、进行简单的接口测试或调试非常方便。但在自动化攻击、漏洞扫描方面不如Burp专业。
  • Charles：macOS平台上的明星，界面优雅，功能同样强大。它对SSL证书处理、流量映射（Map Local/Remote）功能做得很好。适合前端开发或需要精细分析网络请求的场景。

对于APP渗透测试，我的建议非常明确：主用Burp Suite，用Fiddler或Charles作为辅助验证或特定场景下的补充。因为Burp的Repeater（重放器）和Intruder（入侵者）模块在测试参数篡改、暴力破解、逻辑漏洞时无可替代。接下来，我将以Burp Suite Professional作为核心工具进行讲解。

环境准备清单：

  1. 安装并启动MuMu模拟器（确保网络模式为“桥接模式”）。
  2. 在宿主机（你的电脑）上安装Java环境（Burp需要），并下载安装Burp Suite Professional。
  3. 获取你宿主机的局域网IP地址（在Windows上ipconfig查看以太网或WLAN IPv4地址；在macOS/Linux上ifconfig或ip addr查看）。

3. 核心配置：让流量流向你的Burp

环境就绪后，最关键的一步是建立“中间人”攻击的通道，即让模拟器中的所有网络流量，都经过你电脑上运行的Burp代理。

3.1 模拟器网络代理设置

原理很简单：告诉模拟器，“你上网不要直接走，先把所有请求发到我电脑的某个端口（Burp监听的端口）”。

  1. 在模拟器内，打开“设置” -> “WLAN”（或“网络和互联网”）。
  2. 长按当前已连接的Wi-Fi网络（通常叫“WiredSSID”或类似名称），选择“修改网络”。
  3. 在高级选项中，将“代理”设置为手动。
  4. 代理服务器主机名：填写你之前在宿主机上查到的局域网IP（例如192.168.1.100）。切记，不要填127.0.0.1或localhost，那是模拟器自己内部的环回地址，不是宿主机的地址。
  5. 代理服务器端口：填写Burp默认监听的端口8080（你可以在Burp的Proxy->Options中查看和修改监听端口）。
  6. 保存设置。

此时，模拟器的所有HTTP流量理论上都会流向192.168.1.100:8080。但你会发现，很多APP，特别是HTTPS的，依然无法访问或Burp抓不到包。这是因为缺少了关键的一环——SSL/TLS证书。

3.2 安装Burp的CA证书到模拟器系统信任区

HTTPS通信需要验证证书。Burp作为中间人，会对目标服务器进行HTTPS连接，然后用自己的CA证书签发一个“假”的站点证书给模拟器。如果模拟器不信任Burp的CA证书，就会中断连接，提示“证书不被信任”或“网络错误”。

步骤一：从Burp导出证书

  1. 在宿主机浏览器（配置为使用Burp代理）中访问http://burp或http://127.0.0.1:8080，进入Burp的CA证书下载页面。
  2. 下载cacert.der格式的证书。为什么是DER格式？因为安卓系统通常直接识别DER或PEM格式，而CER格式可能需要转换。

步骤二：将证书文件放入模拟器

  • 方法A（共享文件夹）：如果模拟器（如MuMu）支持共享文件夹，直接将cacert.der放入共享目录，在模拟器的文件管理器中就能找到。
  • 方法B（ADB推送）：使用Android Debug Bridge (ADB)。首先在模拟器设置中开启“USB调试”。然后在宿主机命令行执行：
    adb connect 127.0.0.1:7555 # MuMu默认端口，夜神可能是62001，雷电可能是5555 adb push cacert.der /sdcard/Download/
    这会将证书推送到模拟器的下载目录。

步骤三：在模拟器中安装证书这是最容易出错的一步。安卓高版本（7.0+）对证书安装有严格限制。

  1. 在模拟器内，打开“设置” -> “安全”或“加密与凭据”。
  2. 找到“安装证书”或“从存储设备安装”选项。
  3. 选择“CA证书”。
  4. 从文件管理器（如刚刚推送到的/sdcard/Download/）中找到cacert.der文件并点击安装。
  5. 系统会警告你，确认安装。安装成功后，你可以在“信任的凭据” -> “用户”页签下看到名为“PortSwigger CA”或类似名称的证书。

核心难点与解决方案：很多APP，特别是金融、社交类APP，采用了“证书锁定”（Certificate Pinning）技术。它们会预先将合法的服务器证书公钥或哈希值打包在APP内。当建立连接时，会对比接收到的证书和内置的证书，如果不匹配，即使你安装了Burp的CA证书，连接也会被拒绝。这不是你的配置错误，而是APP的主动防御。对付证书锁定，通常需要在已Root的模拟器上，使用Xposed框架配合JustTrustMe或SSLUnpinning模块，或者使用Frida等动态插桩工具来Hook掉证书验证的逻辑。这属于进阶内容，但你必须知道这个问题的存在。

4. 实战抓包与渗透测试工作流

配置妥当后，我们进入实战环节。抓包不是目的，通过抓包分析请求、寻找漏洞才是。

4.1 启动拦截与基础流量分析

  1. 在Burp中，确保Proxy->Intercept是Intercept is on状态。
  2. 在模拟器中，打开你要测试的APP，进行任意操作（如登录、浏览商品、刷新列表）。
  3. 此时，Burp的Intercept标签页会卡住，显示拦截到的第一个HTTP/HTTPS请求。你可以在这里查看和修改请求的所有内容：URL、方法、Headers、参数（GET参数或POST Body）。
  4. 点击Forward放行请求，或者Drop丢弃它。如果你只是想观察流量，可以点击Intercept is off关闭拦截，然后在Proxy->HTTP history中查看所有流经的历史记录。

分析要点：

  • 接口地址（Endpoint）：识别APP的核心API接口。
  • 请求参数：重点关注用户可控的输入点，如username、password、id、mobile、orderNo等。注意参数是明文还是编码/加密的。
  • 身份认证凭证：寻找Authorization头、Cookie、Token等字段。这是你后续测试其他需要认证接口的“钥匙”。
  • 响应内容：观察服务器返回的数据结构，是否暴露了敏感信息（如用户ID、手机号、地址等），是否存在错误信息泄露。

4.2 使用Repeater进行深度测试

HTTP history中右键任意一条请求，选择Send to Repeater。Repeater模块允许你对单个请求进行手动、反复的修改和重放，是测试逻辑漏洞的利器。

测试场景举例：

  1. 越权测试：在查看“我的订单”的请求中，找到一个代表订单ID的参数（如order_id=12345）。将其修改为另一个数字（如order_id=12346），重放请求。如果成功返回了他人的订单信息，则存在水平越权漏洞。
  2. 参数篡改：在支付请求中，找到金额参数（如amount=100，单位可能是分）。尝试修改为amount=1或amount=-100，观察后端是否校验充分。
  3. 输入点模糊测试：对每一个参数，尝试输入SQL注入 payload（如' OR '1'='1）、命令注入 payload（如; ls）、路径遍历 payload（如../../../etc/passwd）、XSS payload（如<script>alert(1)</script>），观察响应是否有错误、延迟或执行了脚本。

4.3 使用Intruder进行自动化爆破

对于需要大量重复测试的场景，如验证码爆破、密码枚举、ID遍历，Intruder模块是自动化神器。

以爆破4位数字验证码为例：

  1. 在Proxy history中找到发送验证码或验证验证码的请求，右键Send to Intruder。
  2. 在Intruder->Positions标签，Burp会自动标记一些参数。清除所有标记（Clear §），然后手动选中验证码参数（如vcode=1234）的值部分，点击Add §将其标记为攻击点。
  3. 切换到Payloads标签。因为验证码是4位数字，我们选择Payload type为Numbers。设置From为0，To为9999，Step为1。为了保持4位格式，在Payload Options的Number format中，将Min integer digits设置为4，Max integer digits设置为4。
  4. 在Options标签中，可以设置线程数、请求间隔（避免触发风控）等。
  5. 点击右上角Start attack开始攻击。攻击窗口会显示每个Payload（0000到9999）的请求状态、响应长度、响应内容。通过对比成功请求（如状态码200且响应内容不同）和失败请求的差异，找出正确的验证码。请注意，此操作仅用于授权测试，切勿用于非法攻击。

5. 小程序抓包的特殊性处理

微信小程序的抓包原理与APP类似，但有其特殊性。小程序运行在微信客户端内，其网络请求由微信统一管理。

  1. 证书安装：你需要将Burp的CA证书不仅安装到模拟器系统，还必须安装到微信的运行环境中。具体方法是：在模拟器内打开微信，随意访问一个外部链接（如http://www.baidu.com），由于你设置了代理，这个请求会被Burp拦截并返回一个证书错误页面。你需要在这个页面（或通过http://burp）下载证书，并在微信内部（或系统提示时）完成安装。安卓高版本下，微信可能使用自己的证书存储，这步至关重要。
  2. 代理设置：小程序的代理设置依赖于系统代理。因此，前面在模拟器Wi-Fi设置中配置的全局代理，通常对小程序也有效。
  3. 抓包启动时机：有时需要先启动Burp并开启拦截，再打开小程序，才能抓到最初的几个关键请求（如小程序代码包下载、初始化配置请求）。
  4. 接口识别：小程序的请求域名通常需要在其后台配置，且必须是HTTPS。抓包时你会看到大量指向https://servicewechat.com或配置的合法域名的请求。重点分析这些请求中的业务API。

6. 常见问题排查与进阶技巧

即使按照步骤操作，你也可能遇到问题。这里记录一些典型的“坑”和解决方案。

6.1 抓不到任何包（Burp History为空）

  • 检查代理配置：确认模拟器Wi-Fi代理中填写的IP和端口是否正确。IP必须是宿主机的局域网IP，不是127.0.0.1。可以在模拟器浏览器访问http://<宿主机IP>:8080，看是否能打开Burp的页面。
  • 检查Burp监听：确认Burp的Proxy->Options中，Proxy Listeners有一个运行在8080端口（或你设置的端口）的监听器，并且绑定在All interfaces或你的宿主机IP上。
  • 关闭防火墙：宿主机防火墙可能阻止了模拟器的连接。临时关闭防火墙或为Burp（java.exe）添加入站规则。
  • 模拟器网络模式：确保模拟器网络是“桥接模式”（Bridged），而不是NAT模式。NAT模式下模拟器可能无法直接访问宿主机IP。

6.2 HTTPS流量抓取失败（TLS握手错误）

  • 证书未正确安装：确认Burp的CA证书已成功安装到模拟器的“用户信任的凭据”中。可以访问https://www.baidu.com测试，如果能抓到包，说明证书对普通网站有效。
  • APP证书锁定：如前所述，这是最可能的原因。表现是只有该APP无法访问网络，或Burp抓到的是CONNECT请求而没有后续的HTTP流量。解决方案是使用Frida等工具进行动态脱壳和Hook。一个简单的检测方法是，尝试用系统浏览器访问该APP使用的同一个域名，如果浏览器能正常访问（通过Burp），而APP不行，基本就是证书锁定。
  • 安卓系统限制（Android 7+）：从Android 7开始，APP默认不再信任用户安装的CA证书，除非APP的网络安全配置明确允许。这需要你修改APP的包或使用已Root的模拟器将Burp证书移动到系统证书目录（/system/etc/security/cacerts/），并重命名为特定的哈希值。使用Magisk模块（如Move Certificates）可以简化这个过程。

6.3 抓到的请求/响应乱码或加密

  • 压缩编码：检查Content-Encoding头（如gzip,deflate,br）。Burp默认会自动解码这些压缩格式。如果没解码，可以在Proxy->Options->Response Modification中确保相关选项已勾选。
  • 自定义二进制协议：一些游戏或IM APP可能使用自定义的TCP或UDP协议，如Protobuf。Burp无法直接解析其内容，显示为乱码。你需要找到其协议文档或逆向分析其编解码方式，然后使用Burp的Decoder模块或自定义插件进行解码。
  • 应用层加密：这是越来越普遍的情况。APP在发送前，对请求体（甚至部分Header）进行了对称或非对称加密。你看到的是密文。解决方法包括：逆向APP找到加密密钥和算法、尝试Hook加密函数获取明文、或者寻找其Web端或旧版本APP可能存在的未加密接口。

6.4 进阶技巧：使用Frida进行动态分析

当静态抓包遇到障碍时，Frida这个动态插桩工具就派上用场了。它可以在APP运行时，注入JavaScript代码来Hook关键函数（如证书验证函数、加密函数、网络请求发送函数）。

一个简单示例：Hook常见的证书验证函数

Java.perform(function() { var Certificate = Java.use('java.security.cert.Certificate'); var X509Certificate = Java.use('java.security.cert.X509Certificate'); // Hook checkClientTrusted 和 checkServerTrusted， 让它们什么都不做 var TrustManagerImpl = Java.use('com.android.org.conscrypt.TrustManagerImpl'); TrustManagerImpl.checkClientTrusted.implementation = function(chain, authType) { console.log("Bypassing checkClientTrusted"); }; TrustManagerImpl.checkServerTrusted.implementation = function(chain, authType, host) { console.log("Bypassing checkServerTrusted for host: " + host); return chain; // 直接返回证书链，表示信任 }; });

将上述脚本保存为bypass_ssl.js，在已Root的模拟器上运行Frida服务，然后在宿主机执行frida -U -f com.target.app -l bypass_ssl.js --no-pause，即可尝试绕过该APP的SSL证书验证。这需要你对目标APP有一定逆向分析能力，以找到正确的Hook点。

整个流程从环境搭建到深入测试，是一个从易到难、不断解决问题的过程。最关键的还是对HTTP/HTTPS协议、移动端安全机制的理解，以及耐心和细心。每一次抓包失败，都是一次学习其背后原理的机会。