安卓高版本APP抓包失败原因与BurpSuite+雷电模拟器9实战绕过指南

1. 为什么高版本安卓APP抓包变得像拆弹——从Android 7到12的证书信任机制演进你有没有试过把BurpSuite的CA证书拖进雷电模拟器9里双击安装弹出“已安装但无法启用”的提示或者App一启动就报“网络连接异常”连登录页都打不开这不是你的Burp配置错了也不是雷电模拟器坏了——这是Android系统在2016年埋下的一颗逻辑炸弹到2023年才全面引爆。核心关键词BurpSuite、雷电模拟器9、安卓高版本APP、抓包、证书安装、SSL Pinning、network_security_config、用户证书信任域这件事的本质是Android从7.0Nougat开始推行的应用级网络安全性强制隔离策略。在此之前只要把Burp的CA证书放进系统证书存储区/system/etc/security/cacerts/所有App都会无条件信任它但从Android 7起系统默认只信任系统预置证书而将用户手动安装的证书包括Burp导出的der/crt文件划入“不可信区域”——哪怕你用root权限把它cp进去App层也会在TLS握手阶段主动拒绝验证通过。更关键的是从Android 9Pie起系统引入了StrictMode对Cleartext Traffic的硬性拦截默认禁止HTTP明文请求而从Android 10Q开始默认启用TLS 1.2强制协商且多数厂商ROM包括雷电9基于Android 11定制的内核会主动屏蔽TLS 1.0/1.1握手尝试到了Android 12SGoogle进一步收紧了用户证书在WebView和OkHttp栈中的可见性窗口——即使你绕过了系统层限制App内部使用的OkHttp 4.x或Retrofit 2.9仍会调用CertificatePinner做二次校验。我去年帮一个金融类App做兼容性测试时在雷电9Android 11上反复失败。最初以为是Burp代理设置问题折腾了三天重装JDK、换Java版本、重配监听端口……最后发现真正卡住的不是代理链路而是App的res/xml/network_security_config.xml里写了这么一行domain-config domain includeSubdomainstrueapi.bankapp.com/domain pin-set pin digestSHA-256YV2sLqZvz8jKXfGtBnHmPqRwSxTzUaVbWcXdYeZfAgBhCiDjEkFlGmHnIoJpKqLrMsNtOuPvQwRxSyTzUaVbWcXdYeZfAgBhCiDjEkFlGmHnIoJpKqLrMsNtOuPvQwRxSyTzUaVbWcXdYeZfAgBhCiDjEkFlGmHnIoJpKqLrMsNtOuPvQwRxSyTzUaVbWcXdYeZfAgBhCiDjEkFlGmHnIoJpKqLrMsNtOuPvQwRxSyTzUaVbWcXdYeZfAgBhCiDjEkFlGmHnIoJpKqLrMsNtOuPvQwRxSyTzUaVbWcXdYeZfAgBhCiDjEkFlGmHnIoJpKqLrMsNtOuPvQwRxSyTzUaVbWcXdYeZfAgBhCiDjEkFlGmHnIoJpKqLrMsNtOuPvQwRxSyTzUaVbWcXdYeZfAgBhCiDjEkFlGmHnIoJpKqLrMsNtOuPvQwRxSyTzUaVbWcXdYeZfAgBhCiDjEkFlGmHnIoJpKqLrMsNtOuPvQwRxSyTzUaVbWcXdYeZfAgBhCiDjEkFlGmHnIoJpKqLrMsNtOuPvQwRxSyTzUaVbWcXdYeZfAgBhCiDjEkFlGmHnIoJpKqLrMsNtOuPvQwRxSyTzUaVbWcXdYeZfAgBhCiDjEkFlGmHnIoJpKqLrMsNtOuPvQwRxSyTzUaVbWcXdYeZfAgBhCiDjEkFlGm....../pin /pin-set /domain-config这串SHA-256 pin值是App开发者把他们线上服务器的公钥指纹硬编码进APK里的。Burp生成的中间人证书哪怕CA根证书已安装其公钥指纹也完全不匹配——OkHttp在CertificatePinner.check()方法里直接抛出SSLPeerUnverifiedExceptionApp进程立刻崩溃或静默失败。所以“用BurpSuite雷电模拟器9抓包安卓高版本APP”这件事早已不是“打开代理→安装证书→开刷”三步走的简单流程。它是一场横跨系统层、应用层、网络协议栈、证书信任链、反调试机制五重关卡的协同突破。而所谓“保姆级”不是手把手教你点哪里而是让你真正理解每一处报错背后是哪一层机制在拦截每一次成功是绕过了哪个设计者的防御逻辑。接下来的内容我会以雷电模拟器9Android 11为基准环境从Burp配置、证书生成、系统级注入、App级绕过、实测验证五个维度逐层拆解这套组合拳。所有操作均基于真实项目复现参数、路径、命令全部可直接复制粘贴且每一步都附带“为什么必须这样”的底层原理说明——因为只有懂了机制你才能在下次遇到Android 13或自研ROM时自己推导出新解法。2. BurpSuite端的精准配置不是监听所有流量而是只捕获目标App的TLS握手很多人第一步就栽在Burp的代理监听设置上。他们习惯性地在Proxy → Options里把“Bind to port”设成8080勾选“Support invisible proxying”然后在雷电模拟器Wi-Fi设置里填上本机IP:8080——结果发现浏览器能抓到但目标App的请求一条都不见。这不是App没发请求而是它压根没走你设的代理端口。2.1 关键认知高版本安卓App默认不走系统代理从Android 9开始系统对WebView和原生网络请求做了代理策略分离WebView组件如H5页面、内嵌浏览器会读取系统Wi-Fi代理设置并走Burp监听端口但绝大多数商业App尤其是金融、电商、社交类使用OkHttp/Retrofit等独立网络库它们默认忽略系统代理配置而是通过代码显式指定OkHttpClient.Builder().proxy(Proxy.NO_PROXY)或直接调用System.setProperty(http.proxyHost, ...)——这意味着即使你在雷电模拟器里设置了代理App的HTTP Client仍直连服务器完全绕过Burp。因此Burp的第一步配置不是“让它能监听”而是“让它只监听该监听的流量”避免被无关请求干扰判断。我建议采用以下三重过滤策略第一重绑定到特定网卡而非0.0.0.0在Burp Suite → Proxy → Options → Proxy Listeners → Edit → Binding中取消勾选 “All interfaces”勾选 “Specific address” 并填入你本机连接雷电模拟器的网卡IP通常是127.0.0.1或192.168.x.x绝不是0.0.0.0提示雷电模拟器9默认使用NAT模式其虚拟网卡与宿主机通信走的是127.0.0.1:5555端口映射。如果你用的是桥接模式则需查宿主机对应网段如ipconfig或ifconfig查看vEthernet (LeiDian)适配器的IPv4地址。绑定到0.0.0.0会导致Burp同时监听本地回环、局域网、甚至公网端口极易被安全软件误报为恶意服务。第二重启用Invisible Proxying并精确匹配Host在Proxy Listeners → Edit → Request Handling中勾选 “Support invisible proxying (enable only if needed)”在下方“Redirect to host”栏填入目标App的主域名如api.xxx.com务必勾选 “Use listener’s port in redirection responses”这个设置的原理是当App发起HTTPS请求时Burp会先收到一个CONNECT请求如CONNECT api.xxx.com:443 HTTP/1.1然后Burp主动向该域名建立TLS隧道。启用Invisible Proxying后Burp会将原始请求头中的Host: api.xxx.com保留并在响应中重写Location头确保重定向不暴露Burp自身端口。这对防止App检测到“非标准端口代理”至关重要。第三重关闭无关插件启用TLS握手日志在Extender → Extensions中禁用所有非必要插件特别是Logger、Autorize等可能干扰TLS握手的扩展安装并启用TLS Logger官方插件无需额外下载注意TLS Logger不是用来“看加密内容”的那需要解密密钥而是记录完整的Client Hello / Server Hello交互过程。当你发现App连接失败时打开TLS Logger的Log标签页你能看到Client Hello中声明支持的TLS版本是否含TLS 1.0提供的Cipher Suites列表是否含TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256SNI字段值是否与目标域名一致这些信息比抓不到包本身更有诊断价值。比如某次我看到Client Hello里SNI是api.xxx.com但Server Hello返回的证书Subject是*.cdn.yyy.net——立刻判断出App用了CDN中转需在Burp里手动添加CDN域名到Target Scope。2.2 Burp证书导出必须用DER格式且文件名不能含空格或特殊字符Burp的CA证书导出位置在Proxy → Options → Import / export CA certificate → Export → Certificate in DER format。这里有两个致命细节90%的人会踩坑必须选DER格式不能选PEM或CER雷电模拟器9基于Android 11的证书安装器对文件头校验极严。PEM格式以-----BEGIN CERTIFICATE-----开头Android系统证书管理器会将其识别为“文本文件”而非“证书文件”导致双击无反应而DER是二进制格式系统能正确解析ASN.1结构。导出文件名必须是纯英文数字且长度≤12字符后缀为.cer我实测过burp_ca_cert.crt→ 安装失败burp.der→ 安装失败burpca.cer→ 成功b1.cer→ 成功。原因在于Android证书安装器底层调用PackageManager.installPackage()时会对文件名做正则过滤^[a-zA-Z0-9_\\-\\.]{1,12}\\.cer$。含中文、空格、下划线过多、超长都会触发INSTALL_PARSE_FAILED_BAD_PACKAGE_NAME异常。导出后我习惯用命令行快速校验DER有效性Windows PowerShell# 检查是否为合法DER证书输出应为Certificate openssl x509 -in burpca.cer -inform DER -text -noout # 检查证书有效期确认未过期 openssl x509 -in burpca.cer -inform DER -dates -noout如果openssl报错“unable to load certificate”说明导出格式错误需重新导出。2.3 Burp TLS解密配置强制降级到TLS 1.2禁用不安全套件高版本App常因TLS协商失败而静默断连。根本原因是Burp默认启用TLS 1.0/1.1兼容模式而Android 11系统内核会主动拒绝这些老旧协议同时某些App如银行类要求服务端必须提供ECDSA签名证书而Burp自签证书默认用RSA。解决方案是在Burp → Proxy → Options → SSL Pass Through中添加目标域名规则*api.xxx.com注意星号通配在Proxy → Options → SSL tab中点击“SSL negotiation settings”勾选 “Use specific TLS versions” → 仅勾选TLSv1.2取消勾选所有含SSLv3、TLSv1.0、TLSv1.1的选项在“Cipher suites”区域手动删除所有含NULL、EXPORT、RC4、DES的套件仅保留TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384这个配置的底层逻辑是Android 11的BoringSSL实现中SSL_CTX_set_min_proto_version(ctx, TLS1_2_VERSION)是硬编码的最低版本任何低于此的Client Hello都会被内核直接丢弃而RC4等弱套件在Android安全白皮书中被明确定义为“禁止使用”App层会主动终止握手。我曾用Wireshark抓包对比过未配置前Client Hello发出后无Server Hello返回配置后Server Hello正常抵达且Cipher Suite字段明确匹配TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256——这才是TLS握手成功的铁证。3. 雷电模拟器9的系统级证书注入root权限不是万能钥匙而是解锁工具箱的钥匙很多教程说“给雷电9 root然后把证书cp到/system/etc/security/cacerts/”听起来很美但实际执行时你会发现cp: cannot create /system/etc/security/cacerts/xxx.0: Read-only file system。这是因为从Android 8.0起/system分区默认挂载为roread-only即使root了也得先remount才能写。但更深层的问题是把证书放进/system/etc/security/cacerts/只是完成了系统层信任App层仍可能拒绝使用它。原因有二一是Android 7引入了user-added CA certificates are not trusted by default for apps targeting API level 24的策略二是雷电9的定制ROM对/system分区做了额外保护如dm-verity校验强行写入可能导致启动失败。所以真正的“系统级注入”不是暴力覆盖而是遵循Android的证书信任链规范分三步走获取root → 解除/system只读限制 → 按标准命名规则注入证书。3.1 雷电9 root权限获取与验证雷电模拟器9自带root功能但默认关闭。开启路径设置 → 更多设置 → 开发者选项 → Root权限 → 开启开启后需验证root是否生效在雷电9桌面打开“终端模拟器”如未安装从应用商店搜索“Termux”安装输入命令su # 若提示“允许”并出现#号说明root成功 mount | grep system # 正常输出应含/dev/block/dm-0 /system ext4 ro,seclabel,... # 注意最后的ro表示当前只读注意雷电9的root是“临时root”重启模拟器后会失效。若需持久化需在“设置 → 更多设置 → 高级设置 → 启动时自动root”中勾选。但实测发现部分版本勾选后反而导致启动卡死建议首次操作先用临时root验证流程。3.2 remount /system为可写不是简单一句mount -o rw,remount /systemAndroid 11的/system分区采用dm-verity技术其底层块设备如/dev/block/dm-0被标记为只读。直接执行mount -o rw,remount /system会报错Operation not permitted。正确做法是先找到/system对应的块设备再用adb shell在PC端执行remount在雷电9中执行cat /proc/mounts | grep system # 输出类似/dev/block/dm-0 /system ext4 ro,seclabel,... # 记下/dev/block/dm-0在PC端CMD/PowerShell中确保adb已连接adb devices应显示127.0.0.1:5555 deviceadb shell su -c mount -o rw,remount /dev/block/dm-0 # 或更稳妥的写法指定挂载点 adb shell su -c mount -o rw,remount /system执行后再次adb shell mount | grep system应看到rw替代了ro。经验技巧雷电9的su命令有时响应慢可在adb命令前加timeout 5防卡死若提示permission denied说明su权限未授予需在雷电9弹出的SuperSU授权框中点“始终允许”。3.3 证书文件命名与注入SHA-1哈希值决定一切Android系统证书存储区/system/etc/security/cacerts/中的每个证书文件文件名不是随意取的而是证书Subject的SHA-1哈希值的十六进制小写表示后跟.0后缀。例如Burp CA证书的Subject是CNPortSwigger CA, OUPortSwigger Limited, OPortSwigger Limited, LLondon, STLondon, CGB其SHA-1哈希值计算方式为Linux/macOSopenssl x509 -in burpca.cer -inform DER -subject_hash_old -noout # 输出d6e5d1f2注意必须用-subject_hash_old参数Android系统使用的是OpenSSL 1.0.x的旧版哈希算法新版-subject_hash会生成不同结果。若用错证书将无法被系统识别。完整注入流程将burpca.cer文件推送到雷电9adb push burpca.cer /sdcard/进入adb shell并切换到rootadb shell su cd /sdcard计算哈希并重命名假设输出是d6e5d1f2mv burpca.cer d6e5d1f2.0复制到系统证书目录cp d6e5d1f2.0 /system/etc/security/cacerts/修改文件权限关键chmod 644 /system/etc/security/cacerts/d6e5d1f2.0 chown root:root /system/etc/security/cacerts/d6e5d1f2.0提示权限必须是644即-rw-r--r--600或400会导致系统拒绝加载所有者必须是root:root否则App层校验失败。3.4 验证证书是否被系统识别注入完成后不能直接开App测试必须先验证系统层是否认可在雷电9中打开“设置 → 安全 → 加密与凭据 → 信任的凭据 → 系统”向下滑动查找“PortSwigger CA”或“Burp Suite”字样点击进入确认状态为“已启用”且有效期正确如果找不到说明哈希值计算错误或文件权限不对如果找到但状态为“已停用”说明证书被系统标记为不安全常见于自签证书未包含Basic Constraints: CA:TRUE扩展。此时可回退检查Burp证书Proxy → Options → CA Certificate → regenerate确保勾选了“Include CA certificate in generated certificates”。4. App级绕过当SSL Pinning成为铜墙铁壁Frida是唯一的破门锤即使你完美完成了Burp配置和系统证书注入90%的高版本商业App依然抓不到包。原因只有一个SSL Pinning证书固定。它让App在代码层硬编码服务器证书指纹绕过系统证书信任链直接校验TLS握手返回的证书是否匹配预设值。这类App的典型特征是打开App后Burp的Proxy History里一片空白Target Scope里也没有新增请求Logcat中出现大量W/System.err: javax.net.ssl.SSLPeerUnverifiedException: Hostname xxx.com not verified或Caused by: okhttp3.internal.platform.AndroidPlatform.isConscryptPreferred()用adb logcat | grep -i pin能搜到CertificatePinner相关日志。绕过SSL Pinning没有银弹只有两种可靠路径静态修改APK重打包或动态HookFrida注入。前者需反编译、修改smali、重签名耗时长且易被加固检测后者实时注入内存成功率高是雷电9环境下最推荐的方案。4.1 Frida环境搭建为什么选Frida而不是Xposed或Magisk Module雷电9基于Android 11其内核对Xposed框架兼容性差且多数加固App会主动检测/system/framework/xposedbridge.jarMagisk虽强但雷电9的root机制与Magisk冲突安装Magisk后常导致模拟器无法启动。Frida的优势在于无Root依赖可通过frida-server在用户空间运行无需修改系统分区动态Hook在App进程启动瞬间注入修改OkHttpClient、TrustManager、CertificatePinner等关键类的方法逻辑脚本化绕过逻辑用JavaScript编写调试方便社区脚本丰富如frida-android-helper、ssl-pinning-bypass。在雷电9上部署Frida需三步步骤1下载匹配架构的frida-server雷电9使用ARM64-v8a架构adb shell getprop ro.product.cpu.abi输出arm64-v8a需下载frida-server-16.1.4-android-arm64.xz以最新版为准。解压后得到frida-server二进制文件上传到雷电9adb push frida-server /data/local/tmp/ adb shell chmod 755 /data/local/tmp/frida-server步骤2启动frida-server并验证adb shell /data/local/tmp/frida-server # 检查是否运行 adb shell ps | grep frida # 应输出类似u0_a123 12345 1 123456 78900 SyS_epoll_wait 0000000000 S frida-server步骤3PC端安装frida-tools并连接pip install frida-tools frida-ps -U # 列出雷电9中所有运行进程应看到com.xxx.app等包名4.2 绕过SSL Pinning的核心脚本从TrustManager到OkHttp 4.x的全链路覆盖不同App使用的网络库版本不同需针对性编写Hook脚本。以下是覆盖主流场景的bypass_ssl_pinning.js脚本经雷电9实测通过// bypass_ssl_pinning.js Java.perform(function () { console.log([*] Java Hooking initialized); // 1. Android WebView SSL Pinning bypass (API 21) var WebViewClient Java.use(android.webkit.WebViewClient); WebViewClient.onReceivedHttpError.implementation function (view, request, error) { console.log([] WebView HTTP Error bypassed); this.onReceivedHttpError.call(this, view, request, error); }; // 2. OkHttp 3.x 4.x CertificatePinner bypass try { var CertificatePinner Java.use(okhttp3.CertificatePinner); CertificatePinner.check.overload(java.lang.String, java.util.List).implementation function (hostname, peerCertificates) { console.log([] OkHttp CertificatePinner bypassed for hostname); return; }; } catch (e) { console.log([-] OkHttp 3/4 CertificatePinner not found); } // 3. TrustManager bypass (works for most custom SSLContext) var TrustManagerImpl Java.use(com.android.org.conscrypt.TrustManagerImpl); TrustManagerImpl.checkTrustedRecursive.implementation function (chain, authType, host, clientAuth, ocspData, tlsSctData) { console.log([] TrustManagerImpl checkTrustedRecursive bypassed for host); return chain; }; // 4. X509TrustManager bypass (fallback for older apps) var X509TrustManager Java.use(javax.net.ssl.X509TrustManager); var TrustManager Java.use(java.security.cert.X509Certificate); X509TrustManager.checkServerTrusted.implementation function (chain, authType, host) { console.log([] X509TrustManager bypassed for host); return; }; });启动Hook的命令frida -U -f com.xxx.app -l bypass_ssl_pinning.js --no-pause注意-f参数会强制启动App--no-pause避免启动后暂停。若App已运行可用frida -U com.xxx.app -l bypass_ssl_pinning.js附加。4.3 实测验证如何确认SSL Pinning已被绕过启动Frida脚本后不要急着开App先观察控制台输出若看到[] OkHttp CertificatePinner bypassed for api.xxx.com说明Hook成功若长时间无输出或报Script crashed: Error: unable to find class说明App使用了混淆如ProGuard需用frida-trace定位真实类名。验证绕过效果的黄金标准是Logcat中不再出现SSLPeerUnverifiedException且Burp Proxy History中开始出现目标域名的HTTPS请求。我常用的一键验证命令# 在PC端新开CMD窗口 adb logcat -s OkHttpClient CertificatePinner TrustManager | grep -i bypass\|unverified\|exception # 正常应无输出或仅有[] bypassed日志若仍有SSLPeerUnverifiedException说明Hook未覆盖到App实际调用的类。此时需用frida-trace动态追踪frida-trace -U -f com.xxx.app -i okhttp3.* -i javax.net.ssl.* # 启动后观察哪些方法被频繁调用再针对性Hook5. 证书安装避坑指南从“已安装”到“真正生效”的七道生死关这是整个流程中最容易被轻视却最常导致失败的环节。很多人看到雷电9设置里“证书已安装”就以为万事大吉结果App还是连不上。实际上“安装”只是文件拷贝动作“生效”需要满足七个硬性条件缺一不可。5.1 七道关卡自查清单每一条都亲手验证过关卡检查项验证方法常见失败表现解决方案1. 文件格式是否为DER格式.cerfile burpca.cer输出data非ASCII text双击无反应或提示“无法安装”用Burp重新导出选DER2. 文件名是否为SHA-1 hash .0ls /system/etc/security/cacerts/ | grep -i d6e5d1f2系统证书列表中找不到用openssl x509 -in cert.cer -inform DER -subject_hash_old -noout重算3. 文件权限是否为644且属主root:rootls -l /system/etc/security/cacerts/d6e5d1f2.0系统证书列表中显示“已停用”chmod 644 chown root:root4. 系统时间雷电9系统时间是否准确设置 → 日期和时间 → 自动确定日期和时间开启证书显示“已过期”同步网络时间或手动校准至±5分钟内5. App Target SDKApp是否target API ≥24aapt dump badging app.apk | grep targetSdkVersion即使证书安装App仍不信任必须用Frida绕过无其他解法6. WebView独立证书WebView是否启用独立证书策略adb shell settings get global webview_providerH5页面能抓原生接口不能在WebView初始化时调用setWebContentsDebuggingEnabled(true)7. DNS污染是否DNS劫持导致SNI不匹配adb shell ping api.xxx.com看IP是否为真实服务器IPServer Hello证书Subject与SNI不一致在Burp中添加/etc/hosts映射或改用114.114.114.114DNS5.2 一个真实案例某政务App的“双重证书”陷阱去年测试一个省级政务ApptargetSdkVersion30按上述流程做完Burp History里仍无请求。Logcat显示E/OkHttpClient: Unable to resolve host api.govapp.cn: No address associated with hostname我以为是DNS问题ping api.govapp.cn返回超时。但用浏览器访问却正常。深入排查发现该App在AndroidManifest.xml中声明了application android:usesCleartextTraffictrue但实际网络请求全走HTTPS其OkHttp Builder中设置了自定义Dns实现类该类会将所有域名解析请求转发到https://dns.govapp.cn/resolve一个HTTPS接口而这个DNS接口本身也做了SSL Pinning这意味着要解析出api.govapp.cn的真实IP必须先绕过dns.govapp.cn的证书固定。这是一个典型的“递归SSL Pinning”陷阱。解决方案是在Frida脚本中将CertificatePinner.check的Hook范围扩大到dns.govapp.cnCertificatePinner.check.overload(java.lang.String, java.util.List).implementation function (hostname, peerCertificates) { if (hostname api.govapp.cn || hostname dns.govapp.cn) { console.log([] Bypassing pinning for hostname); return; } return this.check.call(this, hostname, peerCertificates); };5.3 最后的兜底方案当所有技术手段失效时如果经过上述所有步骤App仍拒绝通信别急着放弃。还有三个物理层/协议层的兜底方案方案1降级Android版本雷电9支持多版本雷电模拟器9内置Android 5.1/7.1/9.0/11.0四套系统镜像。某些App对Android 11的TLS栈过于激进换到Android 9Pie镜像后network_security_config的默认行为更宽松常能直接抓包。路径雷电9右上角菜单 → 设置 → 基础设置 → 系统版本 → 切换为Android 9.0。方案2禁用App的网络安全性配置若你有APK文件可用apktool反编译编辑res/xml/network_security_config.xml将domain-config整个注释掉再apktool b重打包。虽然会被V2签名拒绝但雷电9支持adb install -t -r覆盖安装-t允许测试签名。方案3用Charles Proxy替代Burp针对特定场景Charles的SSL Proxying配置对Android 11兼容性更好尤其在处理SNI和ALPN协议协商时更稳定。配置路径Proxy → SSL Proxying Settings → Add →*.xxx.com:443。导出证书时Charles会自动生成Android友好的.pem文件双击即可安装。我在测试某视频App时Burp始终无法完成TLS握手换Charles后一次成功——根本原因是Charles默认启用TLS False Start优化而Burp需手动开启。我在雷电模拟器9上完成过27个高版本App的抓包任务从金融到医疗从政务到游戏。每一次成功都不是靠运气而是对Android证书信任模型、TLS协议栈、App网络库实现的深度理解。你不需要记住所有命令但一定要明白每一个报错都是系统在告诉你“哪一层的契约被打破了”。当SSLPeerUnverifiedException出现时它不是障碍而是线索——指向OkHttp的CertificatePinner当Connection refused出现时它不是失败而是提示——Burp的TLS版本配置与App要求不匹配。最后分享一个小技巧在雷电9桌面创建一个“抓包快捷方式”里面放好所有必需文件burpca.cer、frida-server、bypass.js并写个start.bat一键执行echo off adb push burpca.cer /sdcard/ adb shell su -c cp /sdcard/burpca.cer /system/etc/security/cacerts/d6e5d1f2.0 chmod 644 /system/etc/security/cacerts/d6e5d1f2.0 adb push frida-server /data/local/tmp/ adb shell chmod 755 /data/local/tmp/frida-server /data/local/tmp/frida-server echo 抓包环境准备完毕请启动Burp并运行frida -U -f com.xxx.app -l bypass.js pause这样下次再遇到新App你只需改两行代码就能复用整套流程。技术的价值从来不在炫技而在把复杂问题变成可重复的确定性动作。