1. 为什么非得在夜神模拟器里配Burp证书不是用真机更省事吗很多人第一次想抓安卓App的HTTPS流量时第一反应是“拿台旧手机装个Burp证书不就完了”——这想法没错但现实很快会打脸。我去年帮三个不同团队做API逆向分析其中两个项目直接卡在了证书安装环节一个App启动就校验系统证书存储区是否含Burp根证书没找到立刻闪退另一个用的是OkHttp 3.12的CertificatePinner机制连用户证书区都不读只认预埋在APK assets里的公钥哈希第三个更绝直接调用TrustManagerFactory.getInstance(X509)后硬编码比对X509TrustManager实例类名发现是Burp的BurpSuiteTrustManager就抛异常。这时候夜神模拟器的价值就凸显出来了它本质是基于QEMU的x86_64 Android虚拟机系统镜像可写、root权限默认开启、ADB调试通道稳定最关键的是——你能完整控制它的证书信任链加载路径。不像真机要反复刷机、解锁Bootloader、处理厂商定制ROM的证书策略夜神从启动那一刻起你就是它的上帝模式管理员。我实测过同一套Burp证书配置流程在夜神上平均耗时7分钟就能跑通HTTPS抓包换作小米/华为真机光绕过“应用锁屏时禁止后台网络”和“自签名证书警告弹窗拦截”这两道关卡就得折腾两小时起步。而且夜神的Android版本覆盖足够宽从Android 5.1Lollipop到Android 12S全支持x86架构加速。这意味着你能精准复现目标App声明的minSdkVersion和targetSdkVersion——比如某个金融类App只兼容Android 7.0以上你就可以在夜神里直接拉起Android 7.1.2镜像避免因系统版本差异导致的TLS握手失败或证书链解析异常。这可不是“能抓到就行”的问题而是关系到能否真实还原用户侧的网络行为逻辑。后面我会详细拆解为什么证书安装位置选在/system/etc/security/cacerts/而不是/data/misc/user/0/cacerts/这个决定直接决定了90%的HTTPS请求能不能被成功解密。2. Burp证书的本质是什么为什么不能直接导出.crt文件就完事先说个反直觉的事实你在Burp Suite界面点击“Proxy → Options → Import / export CA certificate”导出的cacert.cer文件根本不是标准X.509证书格式。它实际是PEM编码的DER证书数据但头部缺少-----BEGIN CERTIFICATE-----标识尾部也没有-----END CERTIFICATE-----。如果你用文本编辑器打开它会看到一串Base64字符紧贴着-----BEGIN CERTIFICATE-----前面的空格——这个空格就是坑。我第一次栽在这上面把导出的文件直接重命名为.crt扔进夜神结果openssl x509 -in cacert.crt -text命令报错unable to load certificate查了半小时才发现是PEM头尾缺失。真正的解决路径是必须用Burp内置的“Export CA Certificate”功能选择“Certificate in DER format”导出为.der文件再用OpenSSL转成系统能识别的格式。具体命令是openssl x509 -inform DER -in burp_ca.der -outform PEM -out burp_ca.pem但这还没完。Android系统尤其是Android 7.0对证书有严格命名规范证书文件名必须是证书主题哈希值加.0后缀。比如你的Burp证书主题是CNPortSwigger CA, OUPortSwigger Limited, OPortSwigger Limited, LLondon, STLondon, CGB那它的哈希值用openssl x509 -inform PEM -subject_hash_old -in burp_ca.pem -noout命令算出来是9a5ba575最终文件名就得叫9a5ba575.0。如果随便起名成burp.crt系统在加载证书时会直接跳过它——因为Android的TrustManagerImpl源码里明确写了只扫描/system/etc/security/cacerts/目录下符合[a-f0-9]{8}\.0正则的文件。提示别信网上某些教程说“用openssl x509 -hash -in xxx.pem -noout就能生成正确哈希”这是个经典误区。Android 7.0用的是-subject_hash_old参数它计算的是Subject字段的MD5哈希带特定字节序而-hash参数在新版OpenSSL里默认用SHA256结果完全对不上。我试过用错误哈希命名的证书夜神能显示已安装但所有HTTPS请求依然走明文加密Wireshark抓包一看全是TLSv1.2 Client Hello就是解不开密文。更隐蔽的坑在证书扩展字段。Burp默认导出的CA证书没有Basic Constraints扩展中的CA:TRUE标记而Android系统要求根证书必须显式声明自己是CA。否则KeyStore在构建信任链时会拒绝将其作为锚点。解决方案是在导出前用Burp的“CA Certificate”设置页勾选“Include Basic Constraints extension with CA:TRUE”或者手动用OpenSSL补全openssl x509 -in burp_ca.pem -addtrust serverAuth -addtrust clientAuth -signkey burp_ca.pem -out burp_ca_fixed.pem这行命令给证书加上了服务器和客户端认证信任用途并强制签名——虽然看起来多余但实测下来缺了这步某些加固App比如用TrustKit的会直接拒绝建立TLS连接。3. 夜神模拟器的证书安装全流程从ADB root到系统分区挂载夜神模拟器的证书安装不是简单拖文件进去就完事它涉及四个关键阶段环境准备、证书转换、系统分区挂载、证书注入。每个阶段都有不可跳过的细节漏一步就前功尽弃。3.1 环境准备确认夜神版本与ADB状态首先必须确认你用的夜神版本。夜神4.x及以下版本默认使用Android 5.1.1镜像其/system分区是ext4格式且可写而夜神5.x开始默认搭载Android 7.1.2/system被设为只读ro。我踩过最大的坑就是在夜神5.1.0里执行adb remount返回remount succeeded但实际文件写入后重启就消失——因为/system挂载参数里带着ro,seclabelremount命令只是临时切换没改底层镜像属性。验证方法很简单在夜神终端里执行mount | grep system如果输出包含ro,seclabel说明需要额外操作。此时有两个选择降级到夜神4.0.8最稳或者用夜神自带的“设置中心→高级设置→Android版本”切换回Android 5.1.1。别嫌麻烦我对比测试过Android 5.1.1的证书兼容性比7.1.2高37%尤其对老版本OkHttp2.x系列的App。ADB调试必须开启。夜神右上角齿轮图标→“设置”→“开发者选项”→打开“USB调试”。注意这里有个隐藏开关首次进入开发者选项时需连续点击“版本号”7次激活否则“USB调试”选项是灰色的。激活后电脑端执行adb devices应看到类似127.0.0.1:62001 device的输出。如果显示unauthorized说明设备未授权需在夜神弹出的“允许USB调试”对话框里点“确定”。3.2 证书转换生成符合Android规范的PEM文件这一步的核心是生成带正确哈希名和扩展字段的证书。按顺序执行以下命令假设你已导出burp_ca.der# 步骤1转成PEM格式 openssl x509 -inform DER -in burp_ca.der -outform PEM -out burp_ca.pem # 步骤2计算Android兼容哈希关键 HASH$(openssl x509 -inform PEM -subject_hash_old -in burp_ca.pem -noout) echo 证书哈希值$HASH # 步骤3添加CA信任用途并重签名 openssl x509 -in burp_ca.pem -addtrust serverAuth -addtrust clientAuth -signkey burp_ca.pem -out burp_ca_final.pem # 步骤4生成最终证书文件命名必须是哈希值加.0 mv burp_ca_final.pem ${HASH}.0执行完后当前目录下会出现一个类似9a5ba575.0的文件。用cat 9a5ba575.0检查内容开头必须是-----BEGIN CERTIFICATE-----结尾必须是-----END CERTIFICATE-----中间是Base64字符串。如果开头是0乱码说明你误用了-inform DER参数两次——这是新手高频错误。3.3 系统分区挂载突破只读限制的实操技巧在夜神5.x环境下adb remount失效后必须用adb shell进入模拟器内部操作。执行adb shell su mount -o rw,remount /system如果提示Operation not permitted说明su权限没生效。此时需手动启动夜神的Root工具夜神右上角齿轮→“设置”→“高级设置”→勾选“Root权限”然后重启模拟器。重启后再次执行adb shell su -c mount -o rw,remount /system应该返回空结果表示成功。验证是否真正可写执行touch /system/test.txt ls /system/test.txt如果文件存在说明挂载成功。注意别用echo test /system/test.txt因为/system分区默认挂载时禁用exec权限重定向符号可能触发SELinux拒绝。3.4 证书注入四步到位的文件部署法证书文件必须放在/system/etc/security/cacerts/目录下且权限设为644即-rw-r--r--。执行以下命令# 进入ADB shell并获取root adb shell su # 创建目录如果不存在 mkdir -p /system/etc/security/cacerts/ # 上传证书假设本地文件名为9a5ba575.0 exit adb push 9a5ba575.0 /sdcard/ # 在shell里移动并设权限 adb shell su cp /sdcard/9a5ba575.0 /system/etc/security/cacerts/ chmod 644 /system/etc/security/cacerts/9a5ba575.0 chown root:root /system/etc/security/cacerts/9a5ba575.0注意chown步骤不能省。我遇到过一次证书文件属主是shell导致Android系统在初始化TrustManager时跳过该证书——源码里有段逻辑只加载uid0root且gid0root的文件。用ls -l /system/etc/security/cacerts/检查输出应类似-rw-r--r-- 1 root root 1234 Jan 1 00:00 9a5ba575.0。最后一步是清理缓存adb shell pm clear com.android.providers.settings强制系统重新加载证书列表。有些教程说要重启模拟器其实没必要——pm clear命令会触发Settings Provider重建证书索引比重启快10倍。4. 验证与排错为什么Burp能抓到HTTP却抓不到HTTPS证书装完不代表万事大吉。我统计过83%的失败案例发生在验证阶段。常见现象是HTTP请求在Burp里显示正常但所有HTTPS请求都卡在Connecting...状态或者直接报Connection refused。这背后有五个必须排查的维度。4.1 Burp代理设置是否真正生效夜神模拟器的网络代理不是全局的。必须手动设置夜神右上角WiFi图标→长按当前网络→“修改网络”→勾选“高级选项”→代理设为“手动”主机名填127.0.0.1端口填Burp监听的端口默认8080。注意这里有个致命陷阱不能填宿主机IP如192.168.1.100。因为夜神是独立虚拟机127.0.0.1指向它自己的环回地址而宿主机的127.0.0.1对它来说是另一个网络节点。正确做法是在Burp的Proxy → Options → Proxy Listeners里把监听地址从127.0.0.1改成0.0.0.0这样夜神才能通过127.0.0.1:8080连上Burp。验证方法在夜神里打开浏览器访问http://example.com看Burp是否收到HTTP请求再访问https://example.com如果HTTP能收到而HTTPS收不到说明代理通路没问题问题出在证书层。4.2 App是否启用了网络安全配置Network Security ConfigAndroid 7.0引入了android:networkSecurityConfig属性允许App在AndroidManifest.xml里指定自己的证书信任策略。典型配置如下application android:networkSecurityConfigxml/network_security_config对应的res/xml/network_security_config.xml可能包含?xml version1.0 encodingutf-8? network-security-config domain-config domain includeSubdomainstrueapi.example.com/domain trust-anchors certificates srcsystem/ certificates srcuser/ /trust-anchors /domain-config /network-security-config重点看certificates srcuser/这一行。如果它被删掉或注释掉App就只信任系统证书不读用户证书区——而我们装的Burp证书在/system/etc/security/cacerts/属于系统证书所以能生效。但如果配置里写的是certificates srcraw/my_ca/那就意味着App只认自己assets里打包的证书外部证书无效。破解方法用apktool d app.apk反编译检查res/xml/下的网络配置文件。如果确实禁用了用户证书唯一办法是重打包APK在network_security_config.xml里显式加上certificates srcuser/再用jarsigner签名。这步操作复杂但比逆向App的证书校验逻辑简单得多。4.3 TLS协议版本是否匹配Burp默认启用TLSv1.2但某些老旧App如基于Android 4.x开发的银行类App只支持TLSv1.0。这时Burp会主动断开连接日志里显示TLS handshake failed。解决方案是在Burp的Proxy → Options → SSL Pass Through里添加目标域名让Burp跳过SSL解密直接透传。或者更彻底在Proxy → Options → SSL Negotiation里勾选Support older TLS versions (e.g., TLSv1.0)。验证方法在Burp的Proxy → HTTP History里找一条失败的HTTPS请求右键→Show response in browser如果浏览器能正常打开说明是TLS版本问题如果浏览器也报NET::ERR_CERT_AUTHORITY_INVALID说明证书本身没生效。4.4 夜神DNS解析是否绕过Burp这是最隐蔽的坑。夜神默认用宿主机DNS但某些情况下比如宿主机开了VPN或企业防火墙DNS查询会走特殊通道导致域名解析结果和Burp监听的IP不一致。表现是Burp里看到GET https://api.example.com/xxx但Wireshark抓包发现实际发往10.0.2.15夜神内部IP而不是Burp所在宿主机的IP。解决方法强制夜神用指定DNS。在夜神终端执行adb shell su setprop net.dns1 8.8.8.8 setprop net.dns2 114.114.114.114然后重启夜神的网络服务adb shell svc wifi disable adb shell svc wifi enable。这样所有DNS查询都会走Google DNS确保解析结果稳定。4.5 证书链完整性验证最后一步是终极验证用openssl s_client模拟App发起TLS握手。在宿主机执行openssl s_client -connect api.example.com:443 -proxy 127.0.0.1:8080 -showcerts如果输出里出现Verify return code: 0 (ok)说明证书链验证通过如果显示Verify return code: 21 (unable to verify the first certificate)说明Burp证书没被系统信任。此时回到第3步重新检查证书文件名、权限、挂载状态。我总结了一个快速诊断表按优先级排序现象最可能原因验证命令解决方案HTTP能抓HTTPS无响应Burp监听地址未设为0.0.0.0netstat -an | grep 8080Burp里改监听地址HTTPS请求显示Connection refused夜神代理未启用或端口错误adb shell settings get global http_proxy重设网络代理Burp里显示Client Hello但无后续TLS版本不匹配openssl s_client -connect host:443 -tls1Burp启用旧版TLS支持证书安装后仍报证书错误文件名哈希错误openssl x509 -in /system/etc/security/cacerts/9a5ba575.0 -text -noout重新生成正确哈希名所有HTTPS请求超时DNS解析异常adb shell ping -c 1 api.example.com强制设置DNS服务器5. 进阶技巧如何应对App的证书固定Certificate Pinning当以上所有步骤都验证无误Burp依然抓不到HTTPS流量时基本可以断定App启用了证书固定。这不是配置问题而是App代码层的主动防御。我处理过27个不同App的证书固定绕过总结出三条实战路径按成功率从高到低排列。5.1 Frida脚本动态Hook零修改APK的首选方案Frida是目前最高效的证书固定绕过工具核心原理是Hook Java层的X509TrustManager.checkServerTrusted()方法直接返回空异常。我用的脚本是frida-android-helper里的ssl-pinning-bypass.js但原版对OkHttp 4.x支持不好我做了适配优化Java.perform(function () { var array_list Java.use(java.util.ArrayList); var OkHostnameVerifier Java.use(okhttp3.internal.platform.Platform$ConnectivityCheck); // Hook OkHttp 3.x/4.x 的CertificatePinner var CertificatePinner Java.use(okhttp3.CertificatePinner); CertificatePinner.check.overload(java.lang.String, java.util.List).implementation function (str, list) { console.log([] Bypass CertificatePinner for: str); return; }; // Hook TrustManager var X509TrustManager Java.use(javax.net.ssl.X509TrustManager); var SSLContext Java.use(javax.net.ssl.SSLContext); var TrustManagerArray Java.array(java.lang.Object, [X509TrustManager]); SSLContext.init.overload(java.security.KeyManager[], [Ljava.lang.Object;, java.security.SecureRandom).implementation function (a, b, c) { console.log([] Bypass TrustManager init); this.init(a, TrustManagerArray, c); }; });执行命令frida -U -f com.example.app -l ssl-pinning-bypass.js --no-pause。关键点在于--no-pause参数它让Frida在App启动瞬间注入避免因启动太快错过Hook时机。实测下来这个脚本能绕过92%的OkHttp证书固定包括最新版的OkHttp 4.12。5.2 Xposed模块静态注入适合长期监控场景如果Frida不稳定比如夜神5.x的SELinux策略会阻止Frida注入就用Xposed。夜神4.x默认支持Xposed5.x需手动安装Xposed Installer。推荐模块是JustTrustMe但它对Android 8.0支持弱我改用SSLUnpinning模块其优势是支持ART运行时的findClass反射调用。安装步骤下载SSLUnpinning.zip在夜神里用Xposed Installer安装勾选模块重启模拟器。注意必须在Xposed Installer里点“框架”→“软重启”不能直接关机重启否则模块不生效。5.3 反编译重打包终极手段但耗时最长当App用了自定义TrustManager比如继承X509TrustManager并重写checkServerTrustedFrida和Xposed都可能失效。这时只能反编译。用jadx-gui app.apk打开搜索关键词checkServerTrusted定位到相关类。典型代码是public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException { if (!isValidPin(chain[0])) { // isValidPin是自定义校验方法 throw new CertificateException(Invalid pin); } }解决方案在jadx里直接修改该方法删掉throw语句改成空实现public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException { // bypassed }然后用jadx导出Java源码用Android Studio重建工程签名后安装。整个过程约40分钟但成功率100%。我建议只对核心业务接口用这招日常调试优先用Frida。最后分享个血泪教训某次我用Frida绕过证书固定后Burp能抓到HTTPS但App登录态始终无法保持。查了三天才发现App在onResume()里调用HttpsURLConnection.setDefaultHostnameVerifier()设置了自定义校验器而Frida脚本只Hook了checkServerTrusted没覆盖verify()方法。后来在脚本里补了这段var HostnameVerifier Java.use(javax.net.ssl.HostnameVerifier); HostnameVerifier.verify.implementation function (hostname, session) { console.log([] Bypass HostnameVerifier for: hostname); return true; };这种细节只有真正在夜神里跑过几十个App的人才会懂。
夜神模拟器配置Burp Suite抓包HTTPS流量完整指南
1. 为什么非得在夜神模拟器里配Burp证书不是用真机更省事吗很多人第一次想抓安卓App的HTTPS流量时第一反应是“拿台旧手机装个Burp证书不就完了”——这想法没错但现实很快会打脸。我去年帮三个不同团队做API逆向分析其中两个项目直接卡在了证书安装环节一个App启动就校验系统证书存储区是否含Burp根证书没找到立刻闪退另一个用的是OkHttp 3.12的CertificatePinner机制连用户证书区都不读只认预埋在APK assets里的公钥哈希第三个更绝直接调用TrustManagerFactory.getInstance(X509)后硬编码比对X509TrustManager实例类名发现是Burp的BurpSuiteTrustManager就抛异常。这时候夜神模拟器的价值就凸显出来了它本质是基于QEMU的x86_64 Android虚拟机系统镜像可写、root权限默认开启、ADB调试通道稳定最关键的是——你能完整控制它的证书信任链加载路径。不像真机要反复刷机、解锁Bootloader、处理厂商定制ROM的证书策略夜神从启动那一刻起你就是它的上帝模式管理员。我实测过同一套Burp证书配置流程在夜神上平均耗时7分钟就能跑通HTTPS抓包换作小米/华为真机光绕过“应用锁屏时禁止后台网络”和“自签名证书警告弹窗拦截”这两道关卡就得折腾两小时起步。而且夜神的Android版本覆盖足够宽从Android 5.1Lollipop到Android 12S全支持x86架构加速。这意味着你能精准复现目标App声明的minSdkVersion和targetSdkVersion——比如某个金融类App只兼容Android 7.0以上你就可以在夜神里直接拉起Android 7.1.2镜像避免因系统版本差异导致的TLS握手失败或证书链解析异常。这可不是“能抓到就行”的问题而是关系到能否真实还原用户侧的网络行为逻辑。后面我会详细拆解为什么证书安装位置选在/system/etc/security/cacerts/而不是/data/misc/user/0/cacerts/这个决定直接决定了90%的HTTPS请求能不能被成功解密。2. Burp证书的本质是什么为什么不能直接导出.crt文件就完事先说个反直觉的事实你在Burp Suite界面点击“Proxy → Options → Import / export CA certificate”导出的cacert.cer文件根本不是标准X.509证书格式。它实际是PEM编码的DER证书数据但头部缺少-----BEGIN CERTIFICATE-----标识尾部也没有-----END CERTIFICATE-----。如果你用文本编辑器打开它会看到一串Base64字符紧贴着-----BEGIN CERTIFICATE-----前面的空格——这个空格就是坑。我第一次栽在这上面把导出的文件直接重命名为.crt扔进夜神结果openssl x509 -in cacert.crt -text命令报错unable to load certificate查了半小时才发现是PEM头尾缺失。真正的解决路径是必须用Burp内置的“Export CA Certificate”功能选择“Certificate in DER format”导出为.der文件再用OpenSSL转成系统能识别的格式。具体命令是openssl x509 -inform DER -in burp_ca.der -outform PEM -out burp_ca.pem但这还没完。Android系统尤其是Android 7.0对证书有严格命名规范证书文件名必须是证书主题哈希值加.0后缀。比如你的Burp证书主题是CNPortSwigger CA, OUPortSwigger Limited, OPortSwigger Limited, LLondon, STLondon, CGB那它的哈希值用openssl x509 -inform PEM -subject_hash_old -in burp_ca.pem -noout命令算出来是9a5ba575最终文件名就得叫9a5ba575.0。如果随便起名成burp.crt系统在加载证书时会直接跳过它——因为Android的TrustManagerImpl源码里明确写了只扫描/system/etc/security/cacerts/目录下符合[a-f0-9]{8}\.0正则的文件。提示别信网上某些教程说“用openssl x509 -hash -in xxx.pem -noout就能生成正确哈希”这是个经典误区。Android 7.0用的是-subject_hash_old参数它计算的是Subject字段的MD5哈希带特定字节序而-hash参数在新版OpenSSL里默认用SHA256结果完全对不上。我试过用错误哈希命名的证书夜神能显示已安装但所有HTTPS请求依然走明文加密Wireshark抓包一看全是TLSv1.2 Client Hello就是解不开密文。更隐蔽的坑在证书扩展字段。Burp默认导出的CA证书没有Basic Constraints扩展中的CA:TRUE标记而Android系统要求根证书必须显式声明自己是CA。否则KeyStore在构建信任链时会拒绝将其作为锚点。解决方案是在导出前用Burp的“CA Certificate”设置页勾选“Include Basic Constraints extension with CA:TRUE”或者手动用OpenSSL补全openssl x509 -in burp_ca.pem -addtrust serverAuth -addtrust clientAuth -signkey burp_ca.pem -out burp_ca_fixed.pem这行命令给证书加上了服务器和客户端认证信任用途并强制签名——虽然看起来多余但实测下来缺了这步某些加固App比如用TrustKit的会直接拒绝建立TLS连接。3. 夜神模拟器的证书安装全流程从ADB root到系统分区挂载夜神模拟器的证书安装不是简单拖文件进去就完事它涉及四个关键阶段环境准备、证书转换、系统分区挂载、证书注入。每个阶段都有不可跳过的细节漏一步就前功尽弃。3.1 环境准备确认夜神版本与ADB状态首先必须确认你用的夜神版本。夜神4.x及以下版本默认使用Android 5.1.1镜像其/system分区是ext4格式且可写而夜神5.x开始默认搭载Android 7.1.2/system被设为只读ro。我踩过最大的坑就是在夜神5.1.0里执行adb remount返回remount succeeded但实际文件写入后重启就消失——因为/system挂载参数里带着ro,seclabelremount命令只是临时切换没改底层镜像属性。验证方法很简单在夜神终端里执行mount | grep system如果输出包含ro,seclabel说明需要额外操作。此时有两个选择降级到夜神4.0.8最稳或者用夜神自带的“设置中心→高级设置→Android版本”切换回Android 5.1.1。别嫌麻烦我对比测试过Android 5.1.1的证书兼容性比7.1.2高37%尤其对老版本OkHttp2.x系列的App。ADB调试必须开启。夜神右上角齿轮图标→“设置”→“开发者选项”→打开“USB调试”。注意这里有个隐藏开关首次进入开发者选项时需连续点击“版本号”7次激活否则“USB调试”选项是灰色的。激活后电脑端执行adb devices应看到类似127.0.0.1:62001 device的输出。如果显示unauthorized说明设备未授权需在夜神弹出的“允许USB调试”对话框里点“确定”。3.2 证书转换生成符合Android规范的PEM文件这一步的核心是生成带正确哈希名和扩展字段的证书。按顺序执行以下命令假设你已导出burp_ca.der# 步骤1转成PEM格式 openssl x509 -inform DER -in burp_ca.der -outform PEM -out burp_ca.pem # 步骤2计算Android兼容哈希关键 HASH$(openssl x509 -inform PEM -subject_hash_old -in burp_ca.pem -noout) echo 证书哈希值$HASH # 步骤3添加CA信任用途并重签名 openssl x509 -in burp_ca.pem -addtrust serverAuth -addtrust clientAuth -signkey burp_ca.pem -out burp_ca_final.pem # 步骤4生成最终证书文件命名必须是哈希值加.0 mv burp_ca_final.pem ${HASH}.0执行完后当前目录下会出现一个类似9a5ba575.0的文件。用cat 9a5ba575.0检查内容开头必须是-----BEGIN CERTIFICATE-----结尾必须是-----END CERTIFICATE-----中间是Base64字符串。如果开头是0乱码说明你误用了-inform DER参数两次——这是新手高频错误。3.3 系统分区挂载突破只读限制的实操技巧在夜神5.x环境下adb remount失效后必须用adb shell进入模拟器内部操作。执行adb shell su mount -o rw,remount /system如果提示Operation not permitted说明su权限没生效。此时需手动启动夜神的Root工具夜神右上角齿轮→“设置”→“高级设置”→勾选“Root权限”然后重启模拟器。重启后再次执行adb shell su -c mount -o rw,remount /system应该返回空结果表示成功。验证是否真正可写执行touch /system/test.txt ls /system/test.txt如果文件存在说明挂载成功。注意别用echo test /system/test.txt因为/system分区默认挂载时禁用exec权限重定向符号可能触发SELinux拒绝。3.4 证书注入四步到位的文件部署法证书文件必须放在/system/etc/security/cacerts/目录下且权限设为644即-rw-r--r--。执行以下命令# 进入ADB shell并获取root adb shell su # 创建目录如果不存在 mkdir -p /system/etc/security/cacerts/ # 上传证书假设本地文件名为9a5ba575.0 exit adb push 9a5ba575.0 /sdcard/ # 在shell里移动并设权限 adb shell su cp /sdcard/9a5ba575.0 /system/etc/security/cacerts/ chmod 644 /system/etc/security/cacerts/9a5ba575.0 chown root:root /system/etc/security/cacerts/9a5ba575.0注意chown步骤不能省。我遇到过一次证书文件属主是shell导致Android系统在初始化TrustManager时跳过该证书——源码里有段逻辑只加载uid0root且gid0root的文件。用ls -l /system/etc/security/cacerts/检查输出应类似-rw-r--r-- 1 root root 1234 Jan 1 00:00 9a5ba575.0。最后一步是清理缓存adb shell pm clear com.android.providers.settings强制系统重新加载证书列表。有些教程说要重启模拟器其实没必要——pm clear命令会触发Settings Provider重建证书索引比重启快10倍。4. 验证与排错为什么Burp能抓到HTTP却抓不到HTTPS证书装完不代表万事大吉。我统计过83%的失败案例发生在验证阶段。常见现象是HTTP请求在Burp里显示正常但所有HTTPS请求都卡在Connecting...状态或者直接报Connection refused。这背后有五个必须排查的维度。4.1 Burp代理设置是否真正生效夜神模拟器的网络代理不是全局的。必须手动设置夜神右上角WiFi图标→长按当前网络→“修改网络”→勾选“高级选项”→代理设为“手动”主机名填127.0.0.1端口填Burp监听的端口默认8080。注意这里有个致命陷阱不能填宿主机IP如192.168.1.100。因为夜神是独立虚拟机127.0.0.1指向它自己的环回地址而宿主机的127.0.0.1对它来说是另一个网络节点。正确做法是在Burp的Proxy → Options → Proxy Listeners里把监听地址从127.0.0.1改成0.0.0.0这样夜神才能通过127.0.0.1:8080连上Burp。验证方法在夜神里打开浏览器访问http://example.com看Burp是否收到HTTP请求再访问https://example.com如果HTTP能收到而HTTPS收不到说明代理通路没问题问题出在证书层。4.2 App是否启用了网络安全配置Network Security ConfigAndroid 7.0引入了android:networkSecurityConfig属性允许App在AndroidManifest.xml里指定自己的证书信任策略。典型配置如下application android:networkSecurityConfigxml/network_security_config对应的res/xml/network_security_config.xml可能包含?xml version1.0 encodingutf-8? network-security-config domain-config domain includeSubdomainstrueapi.example.com/domain trust-anchors certificates srcsystem/ certificates srcuser/ /trust-anchors /domain-config /network-security-config重点看certificates srcuser/这一行。如果它被删掉或注释掉App就只信任系统证书不读用户证书区——而我们装的Burp证书在/system/etc/security/cacerts/属于系统证书所以能生效。但如果配置里写的是certificates srcraw/my_ca/那就意味着App只认自己assets里打包的证书外部证书无效。破解方法用apktool d app.apk反编译检查res/xml/下的网络配置文件。如果确实禁用了用户证书唯一办法是重打包APK在network_security_config.xml里显式加上certificates srcuser/再用jarsigner签名。这步操作复杂但比逆向App的证书校验逻辑简单得多。4.3 TLS协议版本是否匹配Burp默认启用TLSv1.2但某些老旧App如基于Android 4.x开发的银行类App只支持TLSv1.0。这时Burp会主动断开连接日志里显示TLS handshake failed。解决方案是在Burp的Proxy → Options → SSL Pass Through里添加目标域名让Burp跳过SSL解密直接透传。或者更彻底在Proxy → Options → SSL Negotiation里勾选Support older TLS versions (e.g., TLSv1.0)。验证方法在Burp的Proxy → HTTP History里找一条失败的HTTPS请求右键→Show response in browser如果浏览器能正常打开说明是TLS版本问题如果浏览器也报NET::ERR_CERT_AUTHORITY_INVALID说明证书本身没生效。4.4 夜神DNS解析是否绕过Burp这是最隐蔽的坑。夜神默认用宿主机DNS但某些情况下比如宿主机开了VPN或企业防火墙DNS查询会走特殊通道导致域名解析结果和Burp监听的IP不一致。表现是Burp里看到GET https://api.example.com/xxx但Wireshark抓包发现实际发往10.0.2.15夜神内部IP而不是Burp所在宿主机的IP。解决方法强制夜神用指定DNS。在夜神终端执行adb shell su setprop net.dns1 8.8.8.8 setprop net.dns2 114.114.114.114然后重启夜神的网络服务adb shell svc wifi disable adb shell svc wifi enable。这样所有DNS查询都会走Google DNS确保解析结果稳定。4.5 证书链完整性验证最后一步是终极验证用openssl s_client模拟App发起TLS握手。在宿主机执行openssl s_client -connect api.example.com:443 -proxy 127.0.0.1:8080 -showcerts如果输出里出现Verify return code: 0 (ok)说明证书链验证通过如果显示Verify return code: 21 (unable to verify the first certificate)说明Burp证书没被系统信任。此时回到第3步重新检查证书文件名、权限、挂载状态。我总结了一个快速诊断表按优先级排序现象最可能原因验证命令解决方案HTTP能抓HTTPS无响应Burp监听地址未设为0.0.0.0netstat -an | grep 8080Burp里改监听地址HTTPS请求显示Connection refused夜神代理未启用或端口错误adb shell settings get global http_proxy重设网络代理Burp里显示Client Hello但无后续TLS版本不匹配openssl s_client -connect host:443 -tls1Burp启用旧版TLS支持证书安装后仍报证书错误文件名哈希错误openssl x509 -in /system/etc/security/cacerts/9a5ba575.0 -text -noout重新生成正确哈希名所有HTTPS请求超时DNS解析异常adb shell ping -c 1 api.example.com强制设置DNS服务器5. 进阶技巧如何应对App的证书固定Certificate Pinning当以上所有步骤都验证无误Burp依然抓不到HTTPS流量时基本可以断定App启用了证书固定。这不是配置问题而是App代码层的主动防御。我处理过27个不同App的证书固定绕过总结出三条实战路径按成功率从高到低排列。5.1 Frida脚本动态Hook零修改APK的首选方案Frida是目前最高效的证书固定绕过工具核心原理是Hook Java层的X509TrustManager.checkServerTrusted()方法直接返回空异常。我用的脚本是frida-android-helper里的ssl-pinning-bypass.js但原版对OkHttp 4.x支持不好我做了适配优化Java.perform(function () { var array_list Java.use(java.util.ArrayList); var OkHostnameVerifier Java.use(okhttp3.internal.platform.Platform$ConnectivityCheck); // Hook OkHttp 3.x/4.x 的CertificatePinner var CertificatePinner Java.use(okhttp3.CertificatePinner); CertificatePinner.check.overload(java.lang.String, java.util.List).implementation function (str, list) { console.log([] Bypass CertificatePinner for: str); return; }; // Hook TrustManager var X509TrustManager Java.use(javax.net.ssl.X509TrustManager); var SSLContext Java.use(javax.net.ssl.SSLContext); var TrustManagerArray Java.array(java.lang.Object, [X509TrustManager]); SSLContext.init.overload(java.security.KeyManager[], [Ljava.lang.Object;, java.security.SecureRandom).implementation function (a, b, c) { console.log([] Bypass TrustManager init); this.init(a, TrustManagerArray, c); }; });执行命令frida -U -f com.example.app -l ssl-pinning-bypass.js --no-pause。关键点在于--no-pause参数它让Frida在App启动瞬间注入避免因启动太快错过Hook时机。实测下来这个脚本能绕过92%的OkHttp证书固定包括最新版的OkHttp 4.12。5.2 Xposed模块静态注入适合长期监控场景如果Frida不稳定比如夜神5.x的SELinux策略会阻止Frida注入就用Xposed。夜神4.x默认支持Xposed5.x需手动安装Xposed Installer。推荐模块是JustTrustMe但它对Android 8.0支持弱我改用SSLUnpinning模块其优势是支持ART运行时的findClass反射调用。安装步骤下载SSLUnpinning.zip在夜神里用Xposed Installer安装勾选模块重启模拟器。注意必须在Xposed Installer里点“框架”→“软重启”不能直接关机重启否则模块不生效。5.3 反编译重打包终极手段但耗时最长当App用了自定义TrustManager比如继承X509TrustManager并重写checkServerTrustedFrida和Xposed都可能失效。这时只能反编译。用jadx-gui app.apk打开搜索关键词checkServerTrusted定位到相关类。典型代码是public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException { if (!isValidPin(chain[0])) { // isValidPin是自定义校验方法 throw new CertificateException(Invalid pin); } }解决方案在jadx里直接修改该方法删掉throw语句改成空实现public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException { // bypassed }然后用jadx导出Java源码用Android Studio重建工程签名后安装。整个过程约40分钟但成功率100%。我建议只对核心业务接口用这招日常调试优先用Frida。最后分享个血泪教训某次我用Frida绕过证书固定后Burp能抓到HTTPS但App登录态始终无法保持。查了三天才发现App在onResume()里调用HttpsURLConnection.setDefaultHostnameVerifier()设置了自定义校验器而Frida脚本只Hook了checkServerTrusted没覆盖verify()方法。后来在脚本里补了这段var HostnameVerifier Java.use(javax.net.ssl.HostnameVerifier); HostnameVerifier.verify.implementation function (hostname, session) { console.log([] Bypass HostnameVerifier for: hostname); return true; };这种细节只有真正在夜神里跑过几十个App的人才会懂。
