1. 项目概述当 Objection 遇上 OkHttp 的 CertificatePinner在移动应用安全测试特别是 Android 应用的逆向分析中绕过 SSL Pinning证书绑定是一个常规但至关重要的步骤。它允许我们使用像 Burp Suite 这样的中间人代理工具来拦截和分析应用的网络流量。Objection 作为一款基于 Frida 的动态插桩工具其android sslpinning disable命令是许多安全研究人员的“瑞士军刀”一键式操作方便快捷。然而在实际测试中尤其是面对使用了 OkHttp 网络库并且精心配置了CertificatePinner的应用时我们常常会遇到一个令人头疼的情况Objection 的 SSL Pinning Bypass 命令执行了控制台也显示成功了但应用的网络请求依然失败Burp Suite 里什么也抓不到。这个问题困扰过很多人包括我自己。起初你会怀疑是不是 Objection 没装好或者 Frida 服务没跑起来。一通排查后发现 Hook 都正常但就是流量过不来。问题的核心往往就出在 OkHttp 的CertificatePinner这个类上。它实现 SSL Pinning 的机制与 Android 系统标准的TrustManager有所不同导致 Objection 默认的、针对系统 API 的绕过方法“鞭长莫及”。这就像你有一把万能钥匙Objection能打开大多数锁系统 SSL Pinning但面对一把结构特殊的防盗锁OkHttp CertificatePinner万能钥匙就失灵了。本文将深入拆解这个问题的根源并提供一套从原理到实战的完整解决方案让你在面对任何实现了CertificatePinner的应用时都能游刃有余。2. 核心原理OkHttp CertificatePinner 的工作机制与 Objection 的局限要解决问题必须先理解问题是如何产生的。我们需要分别弄清楚 OkHttp 的CertificatePinner和 Objection 的android sslpinning disable各自是如何工作的以及它们为何会“擦肩而过”。2.1 OkHttp CertificatePinner 的防御纵深OkHttp 是一个广泛使用的 HTTP 客户端库其CertificatePinner类提供了比系统默认更严格、更灵活的证书校验机制。它的核心思想是“证书锁定”即应用在代码中硬编码或从安全服务器获取它信任的服务器证书的公钥哈希通常是 SHA-256 指纹。当建立 TLS 连接时OkHttp 不仅会执行标准的证书链验证由系统TrustManager处理还会额外检查服务器证书链中是否存在与预存指纹匹配的证书。其工作流程可以概括为初始化在构建 OkHttpClient 时通过CertificatePinner.Builder()添加域名与预期证书指纹的映射关系。例如val certPinner CertificatePinner.Builder() .add(api.example.com, sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA) .build() val client OkHttpClient.Builder().certificatePinner(certPinner).build()连接验证当客户端向api.example.com发起请求时TLS 握手完成后OkHttp 会获取到服务器返回的证书链。指纹比对CertificatePinner会计算证书链中所有证书的 SHA-256 指纹并与代码中为该域名预设的指纹进行比对。决策如果找到至少一个匹配的指纹连接被允许否则抛出SSLPeerUnverifiedException连接中断。关键点在于这个校验过程发生在应用层是 OkHttp 库自身逻辑的一部分独立于Android 系统的javax.net.ssl.TrustManager。系统TrustManager只负责验证证书链是否由可信 CA 签发、是否过期等基础事项。而CertificatePinner在此基础上增加了一道“白名单”校验。2.2 Objectionandroid sslpinning disable的常规攻击面Objection 的android sslpinning disable命令本质上是一系列 Frida 脚本的集合它的目标是“麻痹”系统的证书校验体系使其接受我们代理工具如 Burp签发的、不被系统信任的证书。它主要尝试从以下几个层面进行绕过HookTrustManager相关方法这是最主要的手段。它会尝试 Hookjavax.net.ssl.TrustManager接口的checkClientTrusted、checkServerTrusted等方法或者其具体实现类如X509TrustManager的相关方法让这些方法直接返回不做任何校验。HookSSLContext初始化尝试替换默认的SSLContext或TrustManager注入一个自定义的、什么都信任的TrustManager。Hook 特定框架的验证方法对一些已知的第三方库如旧的 Apache HTTP Client、特定版本的 OkHttp早期自定义TrustManager实现进行 Hook。那么冲突点在哪里Objection 的默认脚本成功地“欺骗”了系统的TrustManager使得 Burp 的证书在系统层面被接受了。但是OkHttp 的CertificatePinner并不依赖系统的TrustManager的校验结果来做出最终决定它有自己的校验逻辑。即使系统TrustManager被绕过说“这个证书是OK的”CertificatePinner还是会固执地执行自己的指纹比对。由于 Burp 证书的指纹绝对不可能匹配应用硬编码的指纹比对失败连接依然被CertificatePinner拒绝。这就好比安全检查有两道岗第一道岗是保安系统TrustManagerObjection 把我们伪装成了内部人员保安放行了但第二道岗是门禁系统CertificatePinner需要刷员工卡匹配证书指纹我们伪造的身份卡刷不开还是进不去。3. 解决方案精准打击 CertificatePinner 的校验逻辑既然知道了问题根源在于CertificatePinner自身的校验逻辑那么解决方案就很明确了我们需要使用 Frida 直接 HookCertificatePinner类的关键方法使其校验逻辑失效。Objection 的默认命令没有做到这一点所以需要我们进行手动干预和定制。3.1 方案一使用增强版 Frida 脚本推荐这是最直接、最可靠的方法。我们编写一个 Frida JavaScript 脚本专门用于禁用CertificatePinner。脚本核心思路定位CertificatePinner类Hookokhttp3.CertificatePinner类。攻击校验入口CertificatePinner的核心校验方法是check。我们需要 Hook 这个方法并让它直接通过不做任何指纹比对。考虑重载方法check方法可能有多个重载版本不同 OkHttp 版本参数不同我们需要确保 Hook 到正确的那个或者全部 Hook。下面是一个功能强大的通用脚本示例它考虑了不同版本 OkHttp 的兼容性// disable_okhttp_pinning.js Java.perform(function() { console.log([*] 开始尝试禁用 OkHttp CertificatePinner...); var CertificatePinner Java.use(okhttp3.CertificatePinner); // 方案A: Hook check 方法 (OkHttp 3.x/4.x 常见签名) try { CertificatePinner.check.overload(java.lang.String, java.util.List).implementation function(hostname, peerCertificates) { console.log([*] CertificatePinner.check() 被调用主机名: ${hostname}); console.log([*] 已阻止证书指纹校验直接放行。); // 什么都不做直接返回相当于校验通过 // 注意某些版本可能需要返回 void有些可能返回 CertificatePinner 自身这里选择不调用原方法。 }; console.log([] 成功 Hook CertificatePinner.check(String, List)); } catch (err) { console.log([-] Hook check(String, List) 失败: ${err.message}); } // 方案B: Hook check 方法 (另一个常见重载参数为 String, Certificate[]) try { CertificatePinner.check.overload(java.lang.String, [Ljava.security.cert.Certificate;).implementation function(hostname, peerCertificates) { console.log([*] CertificatePinner.check() 被调用 (数组参数)主机名: ${hostname}); console.log([*] 已阻止证书指纹校验直接放行。); // 同样不调用原方法即表示绕过 }; console.log([] 成功 Hook CertificatePinner.check(String, Certificate[])); } catch (err) { console.log([-] Hook check(String, Certificate[]) 失败: ${err.message}); } // 方案C: 更激进的方法直接替换整个 CertificatePinner 实例在某些复杂场景下有效 // Hook OkHttpClient.Builder 的 certificatePinner 方法返回一个“无害”的 CertificatePinner var OkHttpClient_Builder Java.use(okhttp3.OkHttpClient$Builder); try { OkHttpClient_Builder.certificatePinner.overload(okhttp3.CertificatePinner).implementation function(pinner) { console.log([*] OkHttpClient.Builder.certificatePinner() 被调用正在替换为空校验器。); // 创建一个不进行任何校验的 CertificatePinner var CertificatePinner Java.use(okhttp3.CertificatePinner); var dummyPinner CertificatePinner.$new(); // 默认构造器创建的 pinner 通常不包含任何规则 return this.certificatePinner(dummyPinner); // 返回新的 builder }; console.log([] 成功 Hook OkHttpClient.Builder.certificatePinner()); } catch (err) { console.log([-] Hook OkHttpClient.Builder.certificatePinner 失败: ${err.message}); } console.log([*] OkHttp CertificatePinner 禁用脚本注入完成。); });使用步骤将上述脚本保存为disable_okhttp_pinning.js。确保 Frida-Server 已在目标设备上运行并且应用进程可被附加。在命令行中执行frida -U -f com.target.app -l disable_okhttp_pinning.js --no-pause(-U连接 USB 设备-f启动应用-l加载脚本--no-pause立即启动)观察 Frida 控制台输出看到成功的 Hook 信息后尝试在应用内触发网络请求。此时流量应该能正常通过 Burp Suite。实操心得在实际测试中优先尝试方案A和B。如果应用使用了较新或经过混淆的 OkHttp 版本方法名或签名可能发生变化。此时可以先用frida-trace快速追踪一下相关类和方法调用确定准确的签名后再修改脚本。命令如frida-trace -U -i “*check*” com.target.app。3.2 方案二修改并集成脚本到 Objection如果你习惯于使用 Objection 的统一界面也可以将上述 Frida 脚本整合到 Objection 的插件系统中或者在一个 Objection 会话中手动加载。在已启动的 Objection 会话中加载脚本使用objection -g com.target.app explore连接应用。在 Objection 的 REPL 环境中执行android hooking load disable_okhttp_pinning.js之后你依然可以运行android sslpinning disable来禁用系统级的校验两者结合确保万无一失。创建自定义 Objection 插件进阶你可以将脚本封装成 Objection 插件这样就能像原生命令一样调用。这需要一些额外的文件结构和工作但对于经常需要测试此类应用的安全人员来说能极大提升效率。核心是在插件的__init__.py中定义一个新的命令该命令在背后执行上述 Frida 脚本。3.3 方案三静态分析与 Patch备选方案如果动态插桩因反调试等原因失败或者你需要一个持久的绕过方案可以考虑静态修改 APK。操作流程反编译使用apktool或jadx-gui反编译目标 APK。定位代码搜索CertificatePinner、sha256/等关键字找到初始化CertificatePinner的代码位置。通常位于网络请求初始化或某个单例类中。修改逻辑方法一推荐找到调用certificatePinner()的地方将其替换为调用一个返回CertificatePinner.DEFAULT空实现的方法或者直接传入null需注意空指针处理。在 Smali 层面这可能需要一些技巧。方法二修改CertificatePinner.check方法的实现让其直接return。这需要修改对应的 Smali 代码找到check方法体在开头添加return-void或return-object v0根据返回类型。回编与签名使用apktool回编修改后的 APK并使用uber-apk-signer等工具进行签名。安装测试安装修改后的 APK 进行测试。注意事项静态 Patch 可能会触发应用自身的完整性校验Checksum、签名校验等导致应用崩溃。此外对于加固的应用此方法步骤更为复杂需要先脱壳。因此动态插桩通常是首选的测试方法。4. 实战排查与深度调试技巧即使使用了上述脚本有时可能还会遇到问题。下面分享一些实战中排查问题的进阶技巧。4.1 确认 CertificatePinner 确实被使用首先你需要确证问题确实由CertificatePinner引起而不是其他原因如非标准端口、证书透明度、或应用自定义的 SSL 套接字工厂。使用 Frida 进行侦察运行一个简单的脚本来枚举加载的类并检查CertificatePinner是否被使用。Java.perform(function() { Java.enumerateLoadedClasses({ onMatch: function(className) { if (className.includes(CertificatePinner)) { console.log([] 发现类: ${className}); } }, onComplete: function() { console.log([*] 类枚举完成。); } }); });查看堆栈跟踪在CertificatePinner.check方法的 Hook 中打印调用堆栈可以清晰地看到是谁发起了这次严格的校验。implementation: function(hostname, peerCertificates) { console.log([*] CertificatePinner.check 被调用主机名: ${hostname}); console.log(Java.use(android.util.Log).getStackTraceString(Java.use(java.lang.Exception).$new())); // ... 绕过逻辑 }4.2 处理混淆与自定义实现高强度的代码混淆会给 Hook 带来挑战。类名和方法名可能变成a、b、c。特征搜索即使被混淆CertificatePinner的核心逻辑和它使用的字符串常量如sha256/可能还在。你可以尝试在反编译后的代码中搜索sha256/字符串定位关键代码区域。动态分析定位在 Frida 中你可以 Hook 所有类的所有方法性能开销大谨慎使用或者更精准地通过已知的调用模式来定位。例如先找到OkHttpClient.Builder的build方法然后回溯其certificatePinner方法的参数。Hook 构造函数如果找不到check方法尝试 HookCertificatePinner的构造函数打印出实例以及它内部存储的“指纹”规则这能帮你确认它是否被正确初始化。4.3 与其他绕过手段协同工作一个健壮的测试环境应该是多层次的。建议按以下顺序建立你的测试流程系统代理设置确保设备系统代理正确指向 Burp Suite。安装 Burp 证书将 Burp 的 CA 证书安装到设备的系统信任证书存储区而不仅仅是用户存储区。对于高版本 Android这可能需要 root 后手动将证书移动到系统目录。运行 Objection 默认命令先执行android sslpinning disable解决系统层面的校验。加载专用脚本再加载我们编写的disable_okhttp_pinning.js脚本解决应用层的CertificatePinner校验。考虑其他库如果应用还使用了其他网络库如 Cronet、Volley 结合自定义校验可能需要额外的脚本。5. 常见问题与解决方案速查表下表总结了在绕过 OkHttpCertificatePinner过程中可能遇到的典型问题及其解决思路问题现象可能原因排查步骤与解决方案Frida 脚本注入成功但网络请求仍失败1. Hook 的方法签名不匹配。2. 应用使用了混淆后的类名/方法名。3.CertificatePinner并非根本原因存在其他校验如自定义X509TrustManager。1. 使用frida-trace追踪*check*和*CertificatePinner*相关调用确认准确方法签名。2. 反编译 APK搜索sha256/字符串定位关键代码确认混淆后的名称。3. 检查 Frida 输出确认check方法是否被真正调用。若没有需排查其他 SSL 验证点。应用崩溃或行为异常1. Hook 的check方法有返回值但脚本实现为空导致返回undefined。2. 脚本 Hook 了不存在的重载方法引发异常。3. 应用有反调试或反 Frida 检测。1. 在 Hook 实现中根据原方法签名返回一个合适的值如this或原方法的返回值。仔细查看原方法定义。2. 将 Hook 代码包裹在try-catch中或只 Hook 确认存在的重载。3. 使用 Frida 的反反调试脚本或尝试在应用启动后延迟注入。部分请求成功部分失败1. 应用针对不同域名配置了不同的CertificatePinner规则脚本可能只对部分生效。2. 应用动态加载或更新了证书指纹规则。1. 在脚本的check方法实现中打印hostname确认哪些域名被拦截。2. 考虑更彻底的绕过方案如方案C替换CertificatePinner实例。3. 尝试 Hook 规则加载的源头如从网络或文件读取指纹的方法。Objection 命令与自定义脚本冲突两者可能 Hook 了相同的底层方法导致行为不可预测。建议先运行 Objection 命令再加载自定义脚本。或者在自定义脚本中集成系统级的绕过逻辑放弃使用 Objection 的sslpinning disable命令。高版本 Android (9) 上系统证书不信任从 Android 9 开始用户安装的 CA 证书默认不用于安全连接。Root 方案将 Burp CA 证书移动到系统证书目录 (/system/etc/security/cacerts/)。非 Root 方案在应用网络配置中显式添加用户证书需修改应用。对于测试Root 方案更通用。最后我想分享一点个人体会。移动安全测试就像一场攻防博弈CertificatePinner这样的技术是开发者提升安全水位线的有效手段。作为测试者理解其原理并掌握绕过方法不仅是为了完成测试任务更是为了从攻击者视角评估防御的有效性。每次遇到像 Objection 默认命令失效的情况都是一个深入学习底层机制的好机会。记住没有银弹面对不断进化的防御技术保持好奇心熟练使用像 Frida 这样的动态分析工具并愿意深入源码比如多翻翻 okhttp 源码才是解决问题的根本。