移动端抓包 SSL Pinning 证书固定绕过与分层验证

简介围绕支付宝小程序 SSL 校验与代理抓包调试场景整理的轻量技术资料包面向具备一定移动端逆向与安全测试基础的研究者、开发者用于理解小程序网络请求分析中证书校验、代理转发与脚本注入的基本流程。压缩包共 3 个文件约 2KB包含 1 个 Python 脚本、1 个 Markdown 说明文档和 1 个 JavaScript 脚本Python 文件承担 Frida 入口与运行控制Markdown 文档提供使用说明与背景备注JavaScript 脚本对应注入逻辑。已有 3043 人学习下载说明该主题在移动端安全测试与抓包调试中有一定关注度。读者可据此梳理 SSL 校验处理思路、脚本组织方式与代理抓包调试的排错方向适合作为相关实验环境的参考材料。1. 抓不到包先别换工具九成是证书固定没绕对方向一次移动端测试抓包端就绪、证书也装进了系统信任区结果被测应用里每一个请求都返回 SSLHandshakeException。换抓包工具、换测试机、重装证书来来回回折腾了大半天报错一个字都没变。最后把安装包里的 so 拉出来跑了一遍字符串匹配才发现证书固定写死在 native 层前面那些操作全是无用功。这事之后我把 SSL Pinning 的验证流程重做了一遍先自己写三个测试应用分别用网络安全配置文件、OkHttp 的 CertificatePinner、自定义 TrustManager 实现固定再逐个验证钩子能不能过、过不去具体卡在哪一层。下面这套流程就是那次整理出来的适合正在做移动端抓包测试的同学也适合写应用的开发同学用来检查自己的证书固定是不是纸糊的。2. 证书固定到底固定了什么三层实现在测试端的对应关系2.1 从 TLS 握手往回看固定点其实只有三个普通 HTTPS 的信任链是这样的客户端拿到服务端证书链沿着链往上找到系统信任区里的根证书验证签名、有效期、域名全部通过就建连。证书固定是在这条链上额外加一道判断——不是“这个证书能不能被信任”而是“这个证书必须是我认识的那一个”。按固定对象拆只有三个层次第一层固定整张叶子证书比的是 DER 编码的完整字节。这种最严格但证书一续期或者换 CA 就全线失效运维成本极高实际项目里很少这么干。第二层固定公钥也就是 SPKI。做法是把证书里的 SubjectPublicKeyInfo 取出来算 SHA-256再做 Base64。这一层的好处是证书可以换、CA 可以换只要密钥对不变pin 就一直有效。这是主流做法OkHttp 的sha256/xxx和网络安全配置里的pin都是这个东西。第三层固定 CA 或中间证书只信任指定的签发者。这种方式粒度粗一些但对整个域名下的服务都有效常见于对第三方 SDK 做白名单的场景。测试端理解这三层的意义在于固定位置决定了钩子要打在哪里。固定整证书和固定公钥通常在 Java 层的 TrustManager 或者 OkHttp 里做固定 CA 更多落到配置文件和系统层如果真的下沉到 native就得靠 so 分析。搞不清哪一层就乱试钩子最后只能得到“我钩了但没用”这种没法推进的结论。顺带说一个容易被忽略的点pin 一定要有备份。线上做密钥轮换的时候如果只有一条 pin新证书一上所有老版本客户端立刻连不上。做测试的时候也一样你会发现某些应用的 pin 列表里有多条钩子脚本如果只处理第一条切到备用 pin 的场景就验证不出来。2.2 Android 上四种常见实现的指纹特征真打起来遇到的固定实现基本是这四类每类都有可以快速识别的特征。第一种是network_security_config.xml里的pin-set。把 APK 用 jadx 打开res/xml/下一般能找到特征是pin digestSHA-256加一串 Base64。这类固定的执行点在系统 TLS 栈Java 层钩子完全够不着这是最容易让人误判的一类——脚本打印了“hook 成功”请求照样失败。第二种是 OkHttp 的 CertificatePinner。异常堆栈里会明确出现okhttp3.CertificatePinner报错类型是SSLPeerUnverifiedException消息里带Certificate pinning failure。这是最好处理的一种Java 层直接替换方法即可。第三种是自定义 X509TrustManager在checkServerTrusted里手工比对公钥指纹或者直接return。这种代码通常是混淆过的类名看不出来但可以通过 hookSSLContext.init拿到所有注册进去的 TrustManager 实例再看具体类型。第四种是 native 层校验。可能是 BoringSSL 的自定义 verify callback也可能是加固厂商塞进去的独立校验模块。特征是Java 层所有钩子都打上了日志也正常但握手依然失败而且失败得非常快几乎在 TCP 建连后立刻断开。提示识别顺序建议从异常堆栈开始再翻 xml最后才动 so。从便宜的手段往贵的手段排能省掉大量时间。2.3 自建测试应用复现四种才有对照基线直接拿别人的应用练手最大的问题是不知道预期结果长什么样。钩子生效了但请求还是失败你分不清是钩子写错了还是对方用了别的方式。所以我一般会先自己写一个测试应用把四种实现各做一个构建变体形成对照基线。先准备一个测试域名这里用test.example.internal这种内部保留域名代替真实域名避免指向任何线上服务。然后是 OkHttp 版本的固定// 仅用于验证钩子脚本指向自建测试服务 private fun buildPinnedClient(): OkHttpClient { val pinner CertificatePinner.Builder() // 主 pin当前测试服务公钥的 SPKI SHA-256 .add(test.example.internal, sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA) // 备用 pin轮换后的公钥验证多 pin 场景 .add(test.example.internal, sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB) .build() return OkHttpClient.Builder() .certificatePinner(pinner) // 超时调短失败时能快速拿到结论 .connectTimeout(5, TimeUnit.SECONDS) .build() }add的第一个参数是主机名必须和实际请求的 host 完全一致includeSubdomains类的通配在 OkHttp 里是不支持的。第二个参数是sha256/前缀加 Base64注意末尾的等号不能省。多条 pin 之间是“或”的关系只要有一条匹配就放行这也是备份 pin 能生效的原因。配置文件版本!-- res/xml/network_security_config.xml -- network-security-config domain-config cleartextTrafficPermittedfalse domain includeSubdomainsfalsetest.example.internal/domain pin-set expiration2030-01-01 !-- 主公钥 -- pin digestSHA-256AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/pin !-- 备份公钥密钥轮换时顶上 -- pin digestSHA-256BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB/pin /pin-set /domain-config /network-security-configexpiration这个属性很容易被漏掉一旦过了这个日期pin 会直接失效、退回普通信任链校验而不是直接拒绝连接。做测试时如果发现某个版本的应用突然不 pin 了先去看看这个字段。自定义 TrustManager 版本就更直白在checkServerTrusted里拿到链取chain[0].publicKey.encoded算 SHA-256 比对不匹配就抛CertificateException。四个变体跑起来你就有一张清晰的对照表哪个变体在哪种钩子下能通、哪个不能通。后面遇到真实目标先跑一遍钩子看它的行为和哪个变体一致就能大致定位实现方式。3. 复现环境搭建从零到能抓到第一个包3.1 测试机与工具链的选型对照环境这块最容易在一开始就走弯路。我踩过的坑是拿着一台没 root 的零售机折腾了一下午最后发现根本没法往系统信任区写证书前面所有配置全部作废。所以选型要放在最前面。维度已 root 真机模拟器未 root 真机系统 CA 写入可写稳定可写需可写镜像不可写native 层 hook可行部分 ABI 受限不可行机型与系统版本覆盖单机型单版本覆盖面广反调试与完整性检测较少少较多适合的阶段联调验证快速跑通流程只做初步观察结论比较明确先用模拟器把脚本和流程跑通确认每一步的预期结果再上已 root 的真机做最终验证。未 root 的真机不要指望能搞定证书固定最多用来确认“这个应用到底有没有做固定”这件事——看它报不报证书错误就够了。工具链按用途分四块抓包端负责拦截和转发钩子框架负责运行时改写反编译工具负责静态看代码和资源so 分析工具负责看 native 层。四块里最容易被低估的是反编译很多人上来就 hook其实先花十分钟翻一遍 xml 和网络层代码能省掉后面两个小时。3.2 证书落位系统信任区和用户信任区的差别从 Android 7.0 开始应用默认不信任用户安装的 CA 证书只信任系统信任区里的。这条策略直接决定了证书固定的验证能不能做下去——你把抓包端的根证书装到“用户证书”里除了浏览器绝大多数应用都不会认。系统信任区的路径是/system/etc/security/cacerts/里面的文件名不是随便起的必须是subject_hash_old.0的形式。哈希算错文件放进去也不会被加载而且不会有任何提示属于典型的“静默失败”。# 从抓包端导出根证书转成 PEM openssl x509 -in mitm-root.crt -out mitm-root.pem -outform PEM # 关键用旧版 subject hash不是新版 HASH$(openssl x509 -inform PEM -subject_hash_old -in mitm-root.pem | head -n 1) echo 目标文件名: ${HASH}.0 # 生成待推送的文件 cp mitm-root.pem ${HASH}.0 # 推入系统信任区需测试机具备系统分区写入能力 adb push ${HASH}.0 /system/etc/security/cacerts/ adb shell chmod 644 /system/etc/security/cacerts/${HASH}.0-subject_hash_old里的 old 是重点。用新版-subject_hash算出来的值文件名对不上证书就是加载不进去而且系统日志里也不一定有明显报错。这个坑我在不同设备上踩过不止一次。推完之后必须重启或者至少重启netd让信任区重新加载。验证方式是打开系统设置里的信任证书列表看能不能找到刚装的那张找不到就是没生效别急着往下走。还有一种情况测试机拿不到系统分区写权限但应用本身在network_security_config里声明了信任用户证书。这种应用反而好办直接把证书装到用户区就行。判断方法很简单反编译看 xml 里有没有certificates srcuser /。3.3 基线验证抓不到包先确认这四件事环境搭好后不要立刻去碰目标先用一个普通的 HTTPS 请求验证整条链路通不通。这一步能排掉八成的假故障。第一件事网络本身通不通。用命令行直接请求目标域名确认能拿到响应。这一步排除 DNS 和路由问题。第二件事中间人有没有生效。用系统浏览器访问任意 HTTPS 站点抓包端应该能看到明文请求。看不到就说明证书没被信任或者抓包端没有正确转发。第三件事测试应用能不能过。拿 2.3 节里没开 pinning 的那个变体发请求能通说明证书链没问题。这一步是把“证书问题”和“pinning 问题”切开的关键。第四件事开了 pinning 的变体报什么错。这一步的报错类型基本就决定了后续方向报错或现象大概率原因下一步Trust anchor for certification path not found证书没装进被信任的区域回 3.2 检查哈希和路径SSLPeerUnverifiedException pinning 字样Java 层 pinning上第 4 章的钩子握手瞬间断开无 Java 异常native 层校验或双向认证分析 so检查客户端证书抓包端完全无记录但应用正常走了 UDP 或本地缓存关掉 HTTP/3清缓存重试最后一行的场景值得单独说。现在不少应用默认开启 HTTP/3走 UDP 443抓包端如果只监听 TCP就会完全看不到请求但应用本身工作正常非常迷惑。处理方式是先关掉抓包端的 HTTP/3 支持或者在测试构建里强制走 TCP。4. 逐层验证钩子四种固定实现分别怎么打4.1 TrustManager 层的通用钩子这一层是覆盖面最广的。所有走 Java 标准 TLS 栈的连接最终都会调用X509TrustManager.checkServerTrusted只要把这个方法换成空实现证书校验就被摘掉了。但直接 hook 接口方法没用得从SSLContext.init这个入口下手把传进去的 TrustManager 数组整个替换掉。// 目的验证被测应用是否依赖标准 TrustManager 做校验 Java.perform(function () { var X509TrustManager Java.use(javax.net.ssl.X509TrustManager); // 构造一个什么都不校验的实现 var BypassTrustManager Java.registerClass({ name: com.check.BypassTrustManager, implements: [X509TrustManager], methods: { checkClientTrusted: function (chain, authType) { }, checkServerTrusted: function (chain, authType) { console.log([] checkServerTrusted 被调用已放行); }, getAcceptedIssuers: function () { return []; } } }); var SSLContext Java.use(javax.net.ssl.SSLContext); // 三个参数的重载才是真正被应用调用的那个 var init SSLContext.init.overload( [Ljavax.net.ssl.KeyManager;, [Ljavax.net.ssl.TrustManager;, java.security.SecureRandom ); init.implementation function (km, tm, sr) { console.log([] SSLContext.init 被调用替换 TrustManager); // 注意KeyManager 必须原样传回否则双向认证场景会直接失败 init.call(this, km, [BypassTrustManager.$new()], sr); }; });几个参数的含义要点清楚。km是 KeyManager 数组管的是客户端证书双向认证场景下必须保留原值替换掉就握手不了了。tm是 TrustManager 数组是我们要换的目标。sr是随机源原样传回即可。这个脚本只能解决“通过 SSLContext.init 注册 TrustManager”的场景。如果应用用的是 OkHttp 默认配置OkHttp 内部也会调 SSLContext.init一样能拦到。但如果应用自己 new 了一个 TrustManager 直接塞给 SSLSocketFactory绕过了 SSLContext这个脚本就无效。另一条路径是 Conscrypt 的优化实现。Android 上com.android.org.conscrypt.TrustManagerImpl有个checkServerTrusted的扩展版本绕过标准接口直接调用。稳妥的做法是两手都上先 hookSSLContext.init再 hookTrustManagerImpl.verifyChain看日志里哪个先打印就能判断应用走的是哪条路。4.2 OkHttp CertificatePinner 的验证OkHttp 的 pinning 是在标准链校验之后再加一道所以只换 TrustManager 不够必须单独把 CertificatePinner 摘掉。它的判断入口在check方法里只要让它直接返回后续就正常建连。// 目的摘掉 OkHttp 的证书固定判断 Java.perform(function () { try { var CertificatePinner Java.use(okhttp3.CertificatePinner); // OkHttp 3.xcheck(String, List) CertificatePinner.check.overload(java.lang.String, java.util.List) .implementation function (host, peerCertificates) { console.log([] CertificatePinner.check 命中, host host); return; // 不抛异常即视为匹配成功 }; } catch (e) { console.log([-] 3.x 签名不存在尝试 4.x 的 check$okhttp); } try { // OkHttp 4.x 是 Kotlin 实现方法名被改写成 check$okhttp var Pinner4 Java.use(okhttp3.CertificatePinner); Pinner4[check$okhttp].overload(java.lang.String, kotlin.jvm.functions.Function0) .implementation function (host, cleaner) { console.log([] check$okhttp 命中, host host); return; }; } catch (e) { console.log([-] 4.x 签名也不存在目标可能没用 OkHttp); } });这里有两处要说明。第一处是版本差异OkHttp 3.x 用 Java 写方法就叫check4.x 改成 Kotlin 之后内部方法名带$Frida 里访问带$的成员必须用方括号写法点名会直接报语法错误。第二处是两个try块分别处理不要合并——同一个进程里可能同时存在两个版本的 OkHttp尤其是接了多个三方 SDK 的应用。还有一个更彻底的做法hookCertificatePinner.Builder.add在构造阶段就把所有 pin 记下来并清空。这个方式的好处是能看到应用到底固定了哪些主机和哪些 pin对分析有用坏处是如果应用在别处已经构建好了 client 实例Builder 阶段就错过了。实际验证时我一般两个都打看哪个先命中。判断脚本是否真的生效不能只看有没有打印。正确的验证顺序是先确认脚本注入成功再确认方法被调用最后确认请求成功。三个都对上才算这一次验证通过。只有打印、请求仍失败说明固定的执行点不在这一层。4.3 配置文件与 Flutter 场景的处理网络安全配置文件里的pin-set是最容易被误判的一类。它的执行点在系统的 TLS 栈里Java 层的任何钩子都碰不到。表现特征很典型钩子日志显示SSLContext.init被调用了checkServerTrusted也放行了但握手仍然失败而且报错信息里没有 pinning 字样只有一句干巴巴的证书验证失败。识别方法把 2.2 节的 jadx 步骤走一遍看res/xml/下有没有 pin-set。有且钩子无效就可以确定是这一类。处理方式只有两条——修改应用的 xml 后重新打包或者在 native 层钩住系统 TLS 的校验函数。前者对签名有影响后者成本高。做防护评估时我一般直接判定这一类为“有效”因为它确实拦住了绝大多数只会 Java 层钩子的测试者。Flutter 场景又是另一个样子。Flutter 的网络请求走 Dart 层底层的 TLS 实现是随libflutter.so一起打包的 BoringSSL跟系统的 TrustManager 完全没有关系。所以你会看到Java 层钩子打得好好的应用里的 Flutter 页面该失败还是失败而同一应用的原生页面却能通。识别特征也很明显钩子脚本注入后SSLContext.init的调用次数明显偏少但应用确实在发 HTTPS 请求。进一步确认可以看 APK 里有没有lib/*/libflutter.so。处理思路上Dart 层的badCertificateCallback是个可下手的点但这需要能改 Dart 代码对于闭源场景只能转向 so 层去定位 BoringSSL 里负责验证证书链的那个回调。常见的做法是找SSL_CTX_set_custom_verify这类函数并观察它是否被调用了自定义回调但 Android 上的 BoringSSL 符号经常被裁剪只能靠特征字符串定位——这一步的成本已经明显高于前面几种。React Native 的情况相对简单它的网络请求最终落到原生的 OkHttp 或系统网络栈按 4.1 和 4.2 处理就行不需要额外手段。4.4 native 层校验为什么钩子失效以及怎么判断native 层校验难处理的原因是它完全绕开了 Java 层的标准接口。BoringSSL 允许在SSL_CTX上设置自定义的 verify callback这个回调直接拿到证书链做任意比对比对失败就返回 0握手终止。整个过程不会产生任何 Java 异常日志也不会说什么就是连接断了。判断是不是这一类最快的方法是看 so。# 从 APK 中提取所有 so仅解压 lib 目录 unzip -o target.apk lib/* -d extracted # 在 so 里找证书校验相关的字符串特征 strings extracted/lib/arm64-v8a/*.so \ | grep -i -E pinning|spki|sha256/|x509_verify|cert.*mismatch \ | sort -u | head -n 20关注两类特征。一类是sha256/开头的 Base64 常量如果 so 里直接出现了基本可以确定是 native 层硬编码了 pin。另一类是错误文案比如“certificate mismatch”这种出现在 so 里说明校验逻辑就在这里而且失败时会走到这条分支。符号被 strip 掉是常态所以不要指望能看到函数名。这时候的思路变成先定位校验函数在哪个 so、大概哪个偏移再考虑要不要继续。实际做防护评估时如果确认校验下沉到了 native我一般就把结论写成“绕过成本高需要专门投入”不再往下钻因为再往下的收益和投入不成比例。顺带说一个判断双向认证的窍门。如果抓包端在收到 ClientHello 之后回证书客户端直接断开而且 so 里能搜到客户端证书相关的字符串那大概率是 mTLS。这类场景下光绕过 pinning 没用抓包端还得带上合法的客户端证书属于另一个维度的门槛。5. 排查记录五次翻车五种现象对应五种原因5.1 钩子打印了但请求还是失败现象脚本注入成功SSLContext.init的日志正常输出checkServerTrusted也放行了但应用里的请求依然报证书错误。原因钩子打在了接口上而应用实际用的是具体实现类。比如 hook 了javax.net.ssl.X509TrustManager但应用的信任逻辑写在com.android.org.conscrypt.TrustManagerImpl里走的是扩展方法根本没经过接口。解决用类枚举反查实际类型。在脚本里调Java.enumerateLoadedClassesSync()过滤出所有含TrustManager的类看哪个是应用自己的包名然后针对具体类下手。这一步比猜快得多。5.2 装了系统证书高版本系统上仍然不生效现象证书按流程推到了/system/etc/security/cacerts/权限也改了重启之后浏览器的 HTTPS 能抓但应用不行。原因文件名哈希算错了。用新版-subject_hash算出来的值和系统要求的不一致系统会静默忽略这个文件不报错也不加载。解决回到 3.2 节用-subject_hash_old。验证方式是装完之后打开系统的信任证书列表肉眼确认能找到。找不到就别往下走后面所有结论都不可信。5.3 抓包端一条记录都没有应用却工作正常现象抓包端界面干干净净应用该加载的加载、该刷新的刷新完全不像是出了问题。原因走了 UDP 上的 HTTP/3。抓包端默认只监听 TCP自然什么都看不到。另一种可能是应用有本地缓存某些页面根本没发请求。解决先在抓包端关掉 HTTP/3 相关的处理强制回落 TCP再清一次应用数据重进。两件事做完还是没记录才考虑是不是走了别的通道。5.4 部分接口能抓部分接口抓不到现象主流程的接口都能看到明文但某个特定功能死活抓不到返回的数据看起来又是正常的。原因应用里有多个 HTTP 客户端实例。有的走统一配置有的由三方 SDK 自己 new 了一个pinning 配置不统一。或者那部分页面用的是 WebView走的是另一套网络栈。解决在主流程和异常流程各打一次日志对比SSLContext.init的调用来源。WebView 的情况单独处理开启 WebView 的调试开关后用浏览器内核的调试协议看请求不要硬套原生那套钩子。5.5 钩子注入后应用直接闪退现象脚本一跑应用就崩日志里看不到任何业务相关的堆栈。原因三种可能——钩子框架版本和 ABI 不匹配应用有反调试检测发现注入进程后主动退出注入时机太晚类已经加载完了注册的替换被拒。解决先换 spawn 模式启动把注入时机提前到进程刚起来时再确认框架版本和应用架构一致arm64 还是 arm32如果还崩就先只注入一个空脚本测试排除是脚本本身的问题。反调试检测这条不好确认但特征是“空脚本也崩”可以用这个来区分。6. 加固侧的清单验完把洞补回去验证做完最有价值的产出不是“我绕过了”而是“哪些防护真的起了作用”。我自己评估了一圈把这几类固定方式按实际拦截效果排了个序顺手整理成一张可以直接对着改的清单。防护手段实现成本被绕过的难度适用场景仅网络安全配置 pin-set低中挡住 Java 层钩子快速上线作为基础门槛OkHttp CertificatePinner低低一条脚本已有 OkHttp 的项目聊胜于无自定义 TrustManager中低到中需要额外做业务判断时native 层校验高高对安全性有要求的核心接口双向认证 mTLS中高高客户端可唯一标识的场景请求签名 时间戳 随机数中高即使解了 TLS 也改不了包所有涉及金额和状态变更的接口这张表里最值得说的是最后一行。前面五项全都是“防止别人看到明文”但只要对方拿到了合法的客户端证书、绕过了所有 pinning明文照样能看。而请求签名不一样——它保护的不是传输层而是业务层。对方能看到请求但改了参数就验签失败改了时间戳就过期重放会被随机数挡住。真正要防住篡改这一层是绕不过去的。另外两个容易漏的点。一是 pin 的备份主 pin 和备用 pin 必须同时在线并且备用 pin 对应的密钥要在冷存储里保管不能和主密钥放在同一台机器上否则一次事故两个一起丢。二是证书固定的作用范围不要只在网络层封装的地方做三方 SDK 自己发起的请求经常是独立的客户端实例配置漏了就等于没做。回过头看那次折腾大半天的经历最大的教训不是“该怎么绕”而是“该先确认哪一层”。从那以后我每次开新的移动端测试都会强制走一遍顺序先用无 pinning 的测试应用确认链路通再用三个变体确认钩子各自的预期表现最后才碰目标。这套动作花不到二十分钟能省掉的却是几个小时的无效试错。我把这几段脚本和配置文件样例整理进了一个压缩包需要拿去做对照验证的按资源页的说明取用就行。希望帮到你。本文还有配套的精品资源点击获取