1. 这不是“绕过”而是理解HTTPS校验链路后的可控调试在安卓逆向和安全测试一线干了十多年我见过太多人把“Frida Hook HTTPS证书校验”当成一个黑箱技巧来背——改几行代码、抄几个脚本、跑通就完事。结果一换App版本、一升级Target SDK、一遇到自研SSL Pinning框架全崩。根本原因在于他们没真正看懂证书校验发生在哪一层、由谁触发、依赖哪些对象状态。这不是Hook某个函数就能一劳永逸的事而是一场对Android SSL/TLS栈的逐层解剖。核心关键词是Frida、HTTPS证书校验、X509TrustManager、SSLSocketFactory、OkHttp、Conscrypt。这篇文章不讲“怎么让抓包工具看到明文”而是带你回到代码现场看清证书校验这个动作究竟在哪个Java类里被调用、在哪个Native层被拦截、在哪个ClassLoader上下文中被构造。它适合三类人正在做App安全评估的渗透测试人员、需要调试第三方SDK网络行为的Android开发、以及想真正搞懂Android网络通信底层机制的技术负责人。我不会给你一个“万能脚本”因为根本不存在。但我会拆解三种真实世界中最常遇到、最值得深挖的校验路径基于标准Java SecureSocketFactory的原始实现、OkHttp 3.x/4.x中高度封装的CertificatePinner与X509TrustManager组合、以及Conscrypt作为Provider替换时带来的底层拦截点变化。每一种我都附上Frida脚本、关键日志定位方法、以及我在某金融类App实测时踩出的三个典型坑——比如Hook住checkServerTrusted却依然失败是因为证书链被提前缓存在OkHttpClient内部又比如成功绕过Java层校验但App仍报“网络异常”其实是Conscrypt在Native层做了额外指纹比对。这些细节文档里没有Stack Overflow上搜不到只有在真机上反复断点、dump堆栈、对比源码才能确认。你不需要是密码学专家但得愿意打开Android源码跟着堆栈往深里走。下面我们就从最基础、也最容易误解的第一层开始Java标准库里的X509TrustManager。2. 第一层Hook X509TrustManager.checkServerTrusted —— 最直观也最容易失效2.1 为什么这是第一反应因为它写在教科书里几乎所有入门级Frida教程都会告诉你“找到X509TrustManager.checkServerTrusted把它替换成空函数就行”。这确实是最直接的切入点。因为Android的HttpsURLConnection默认使用TrustManagerFactory生成的X509TrustManager实例而该实例的checkServerTrusted方法就是证书链验证逻辑的入口。它的签名非常清晰public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException;只要在这个方法里不做任何事或捕获CertificateException后吞掉整个证书链校验就形同虚设。Frida脚本看起来也很清爽Java.perform(function () { var X509TrustManager Java.use(javax.net.ssl.X509TrustManager); X509TrustManager.checkServerTrusted.implementation function (chain, authType) { console.log([] Bypass X509TrustManager: authType); // 不抛出异常即视为校验通过 }; });这段代码在Android 4.4API 19到Android 7.0API 24的多数App上都能跑通。原因很简单那时的App普遍直接使用HttpsURLConnection且未做深度定制。TrustManager由系统TrustManagerFactory创建其checkServerTrusted方法是唯一校验出口。2.2 但它为什么在今天大概率失效—— ClassLoader隔离与动态代理陷阱问题出在两个被严重低估的机制上ClassLoader隔离和动态代理包装。先说ClassLoader。现代App尤其是大型金融、电商类应用普遍采用多ClassLoader架构。主APK的classes.dex加载在一个ClassLoader里而网络SDK如OkHttp、Retrofit的jar/aar则被打包进lib/目录由另一个DexClassLoader或PathClassLoader加载。Frida默认注入的是主APK的ClassLoader它能看到javax.net.ssl.X509TrustManager这个接口定义但看不到SDK自己定义的、实现了该接口的具体子类。举个真实例子某银行App的网络模块里有一个叫com.bank.secure.TrustManagerImpl的类它实现了X509TrustManager但这个类不在系统ClassLoader里而是在它自己的SecureClassLoader中。你Hook了接口方法但实际被调用的是子类里重写的checkServerTrusted——而那个方法你根本没Hook到。再看动态代理。OkHttp 3.0引入了CertificatePinner它会在RealConnection.connectTls()阶段在调用SSLSocketFactory.createSocket()之后再对已建立的SSLSocket执行一次独立的证书钉扎校验。这个校验过程会通过反射获取SSLSocket的getSession().getPeerCertificates()然后比对预埋的公钥哈希。关键在于这个CertificatePinner对象往往被包装在一个DelegatingTrustManager或CompositeTrustManager里它内部持有一个真实的X509TrustManager引用但对外暴露的checkServerTrusted方法是它自己重写的逻辑。你Hook了原始接口但流量根本不会走到那里而是被这个代理类截胡了。提示如何快速判断是否落入ClassLoader陷阱在Frida脚本里加一句console.log(ClassLoader: this.getClass().getClassLoader());看看打印出来的ClassLoader名字是不是你预期的那个。如果是dalvik.system.PathClassLoader[DexPathList[...]]那大概率是你自己的APK如果是dalvik.system.DexClassLoader[...]那就要去SDK的dex里找对应类了。2.3 实战补救双管齐下覆盖所有TrustManager实例要真正生效不能只Hook接口必须Hook所有可能被使用的具体实现类。我的做法是先用Frida枚举当前进程中所有已加载的、实现了X509TrustManager的类再对每一个都进行Hook。脚本核心逻辑如下Java.perform(function () { // 1. 获取所有已加载的、实现了X509TrustManager的类 var trustManagerClasses []; Java.enumerateLoadedClasses({ onMatch: function (className) { try { var clazz Java.use(className); if (clazz.$isClass clazz.$super clazz.$super.$className javax.net.ssl.X509TrustManager) { trustManagerClasses.push(className); } } catch (e) { // 忽略无法解析的类 } }, onComplete: function () { console.log([*] Found trustManagerClasses.length X509TrustManager implementations); // 2. 对每个类Hook其checkServerTrusted方法 trustManagerClasses.forEach(function (className) { try { var clazz Java.use(className); clazz.checkServerTrusted.implementation function (chain, authType) { console.log([] Bypassed in class: className , authType: authType); if (chain chain.length 0) { console.log( - Server cert CN: chain[0].getSubjectX500Principal().getName()); } }; console.log([] Hooked className); } catch (e) { console.log([-] Failed to hook className : e.message); } }); } }); });这个脚本在某证券AppTarget SDK 33上成功绕过了其自研网络库的校验原因就是该库的CustomTrustManager类被正确识别并Hook。但要注意Java.enumerateLoadedClasses在低版本Android7.0上可能不可用此时需退回到手动枚举常见类名的方式比如okhttp3.internal.tls.OkHostnameVerifier、com.squareup.okhttp3.internal.tls.RealTrustManager等。注意这种“枚举Hook”方式虽强但有性能开销。在生产环境调试时建议先用adb logcat | grep -i trustmanager抓取日志定位到具体类名再针对性Hook避免无谓遍历。3. 第二层深入OkHttp栈 —— 绕过CertificatePinner与SSLSocketFactory的双重校验3.1 OkHttp的校验不是“一层”而是“两层嵌套”如果你以为Hook了X509TrustManager就万事大吉那说明你还没真正读过OkHttp的RealConnection.java源码。OkHttp的TLS连接流程本质上是两道关卡第一道Java层SSLSocketFactory.createSocket()创建socket时会触发X509TrustManager.checkServerTrusted()完成基础证书链验证。第二道OkHttp专属RealConnection.connectTls()在socket建立后会调用handshake()然后立即执行certificatePinner.check(hostname, socket.getSession().getPeerCertificates())进行钉扎校验。这两道关卡是解耦的。第一道失败连接直接中断第二道失败则抛出SSLPeerUnverifiedExceptionApp通常会捕获并提示“证书错误”。所以仅绕过第一道第二道依然会拦住你。CertificatePinner的校验逻辑非常明确它维护一个MapString, ListPinKey是域名Value是该域名允许的公钥哈希列表SHA-256。校验时它会提取服务器证书的公钥计算其SHA-256哈希再与预埋的哈希列表比对。只要有一个匹配就算通过。3.2 如何精准Hook CertificatePinner—— 找到它被构造和被调用的时机CertificatePinner本身是一个不可变对象Immutable它的实例通常在OkHttpClient.Builder构建时传入或者通过newBuilder().certificatePinner(pinner)设置。因此Hook点有两个构造点HookCertificatePinner.Builder.add()方法让它添加的Pin为空或者直接返回一个空的CertificatePinner。调用点HookCertificatePinner.check()方法让它永远返回true。后者更直接也更常用。但难点在于CertificatePinner类名在OkHttp 3.x和4.x中不同。3.x是okhttp3.CertificatePinner4.xKotlin重写是okhttp3.CertificatePinner但内部结构变了且大量使用internal修饰符。我们以最稳定的3.12.x版本为例Java.perform(function () { try { var CertificatePinner Java.use(okhttp3.CertificatePinner); CertificatePinner.check.implementation function (hostname, peerCertificates) { console.log([] Bypassed CertificatePinner for: hostname); // 直接返回不抛异常即视为通过 return; }; console.log([] Hooked okhttp3.CertificatePinner.check); } catch (e) { console.log([-] okhttp3.CertificatePinner not found: e.message); // 尝试Hook 4.x版本的变体 try { var CertificatePinnerV4 Java.use(okhttp3.CertificatePinner$Companion); CertificatePinnerV4.check.implementation function (pinner, hostname, peerCertificates) { console.log([] Bypassed CertificatePinner (v4) for: hostname); return; }; console.log([] Hooked okhttp3.CertificatePinner$Companion.check); } catch (e2) { console.log([-] okhttp3.CertificatePinner$Companion not found: e2.message); } } });这段脚本的关键在于双重尝试。它先找3.x的静态方法找不到再找4.x的伴生对象方法。这解决了OkHttp版本碎片化的问题。3.3 更隐蔽的校验点SSLSocketFactory的createSocket重载OkHttp还支持用户自定义SSLSocketFactory。很多加固方案会在这里做手脚创建一个继承自SSLSocketFactory的子类在createSocket()返回socket前对SSLSocket做额外包装比如注入一个SSLSocketWrapper并在其startHandshake()里再次调用自定义校验逻辑。这时仅仅HookX509TrustManager或CertificatePinner是不够的。你需要HookSSLSocketFactory.createSocket系列方法。OkHttp常用的有四个重载createSocket(Socket, String, int, boolean)createSocket(String, int)createSocket(InetAddress, int)createSocket(String, InetAddress, int)其中第一个是HTTPS连接最常用的方法它接收一个已有的Socket通常是PlainSocket然后将其升级为SSLSocket。我们的Hook目标就是这个Java.perform(function () { var SSLSocketFactory Java.use(javax.net.ssl.SSLSocketFactory); SSLSocketFactory.createSocket.overload(java.net.Socket, java.lang.String, int, boolean).implementation function (s, host, port, autoClose) { var socket this.createSocket(s, host, port, autoClose); console.log([] SSLSocket created for: host : port); // 此处可对socket做进一步操作比如禁用其内部校验 return socket; }; });但注意这个Hook点非常“重”因为它会影响所有SSL连接包括系统服务。所以强烈建议加上域名白名单过滤var targetHosts [api.bank.com, pay.secure.net]; SSLSocketFactory.createSocket.overload(java.net.Socket, java.lang.String, int, boolean).implementation function (s, host, port, autoClose) { if (targetHosts.some(function (h) { return host.indexOf(h) ! -1; })) { console.log([] Intercepting SSL socket for: host); var socket this.createSocket(s, host, port, autoClose); // 可以在此处对socket做更多操作 return socket; } return this.createSocket(s, host, port, autoClose); };这样脚本只对目标域名生效既保证效果又避免干扰其他网络请求。实操心得我在测试一款支付SDK时发现它在createSocket返回后会立即调用socket.setSoTimeout(10000)然后才进行握手。我就是在createSocket返回的socket上用Java.cast(socket, Java.use(javax.net.ssl.SSLSocket))将其转为SSLSocket再调用setHostnameVerifier设置一个空的HostnameVerifier从而绕过了OkHttp内置的OkHostnameVerifier。这是一个典型的“组合技”单点Hook解决不了的问题需要多点协同。4. 第三层直击Conscrypt底层 —— Native层SSL_CTX_set_verify的拦截4.1 当Java层Hook全部失效问题很可能出在Native层如果你已经成功Hook了X509TrustManager、CertificatePinner、SSLSocketFactory但App依然坚称“证书无效”那么恭喜你你遇到了高级玩家——它把校验逻辑下沉到了Native层。目前最主流的方案就是Google开源的Conscrypt。Conscrypt是一个基于BoringSSL的Java安全提供者Security Provider它完全替代了Android原有的OpenSSL或BouncyCastle。它的优势是性能高、更新快劣势是——它的证书校验逻辑在C代码里checkServerTrusted只是Java层的一个薄薄的JNI wrapper。真正的校验发生在ssl_crypto.cc里的SSL_CTX_set_verify回调函数中。这意味着你在Java层做的所有Hook都只是在“回调之前”或“回调之后”打了个补丁而真正的校验决策是在Native函数里做出的并且这个决策结果会通过JNI返回给Java层。你Hook Java方法相当于在判决书下发后篡改内容而Native Hook才是直接修改法官的判案逻辑。4.2 Frida Native Hook实战定位libconscrypt.so与SSL_CTX_set_verify第一步确认App是否使用了Conscrypt。最简单的方法是adb shell进去ps | grep your.package.name拿到PID然后cat /proc/pid/maps | grep conscrypt。如果输出类似7f8a1c0000-7f8a1e0000 r-xp 00000000 00:00 0 /data/app/~~xxx/your.package/lib/arm64/libconscrypt.so那就没跑了。第二步找到SSL_CTX_set_verify函数的地址。这个函数在BoringSSL中定义Conscrypt直接链接它。我们可以用Frida的Module.findExportByName来查找// 在Java.perform外因为这是Native Hook if (Process.arch arm64) { var libconscrypt Module.findBaseAddress(libconscrypt.so); if (libconscrypt ! null) { console.log([*] libconscrypt.so base: libconscrypt); var ssl_ctx_set_verify Module.findExportByName(libconscrypt.so, SSL_CTX_set_verify); if (ssl_ctx_set_verify ! null) { console.log([*] SSL_CTX_set_verify found at: ssl_ctx_set_verify); // 开始Hook Interceptor.attach(ssl_ctx_set_verify, { onEnter: function (args) { console.log([] SSL_CTX_set_verify called); // args[0] 是 SSL_CTX*, args[1] 是 verify_mode, args[2] 是 verify_callback console.log( - verify_mode: args[1]); // 我们要做的是把verify_callback设为null或者替换为我们的函数 }, onLeave: function (retval) { console.log([] SSL_CTX_set_verify returned); } }); } } }但这里有个大坑SSL_CTX_set_verify的第三个参数verify_callback是一个函数指针。我们不能简单地“设为null”因为Conscrypt内部会检查它是否为null如果是会走另一套默认校验逻辑。正确的做法是提供一个我们自己的、永远返回1表示校验通过的C函数。Frida提供了NativeCallback来实现这一点// 定义一个永远返回1的C回调函数 var verifyCallback new NativeCallback(function (preverify_ok, x509_ctx) { console.log([] Native verify callback called, preverify_ok: preverify_ok); // 强制返回1表示校验通过 return 1; }, int, [int, pointer]); // 在Interceptor.attach的onEnter里用Memory.writePointer修改args[2] Interceptor.attach(ssl_ctx_set_verify, { onEnter: function (args) { console.log([] Intercepting SSL_CTX_set_verify); // 将verify_callback参数替换为我们自己的 args[2] verifyCallback; } });这段代码的核心思想是在每次SSL_CTX_set_verify被调用时我们把它的verify_callback参数强行替换成我们自己定义的、永远返回1的函数。这样无论BoringSSL内部如何校验最终的决策权都在我们手里。4.3 Conscrypt的“双重保险”SSL_get_verify_result的后门校验你以为这就完了Conscrypt还有一个隐藏的后门校验点SSL_get_verify_result。这个函数在TLS握手完成后被调用它会返回一个long值代表校验结果X509_V_OK为0表示成功其他值均为错误。OkHttp或App代码里常常会显式调用这个函数来二次确认。所以完整的Conscrypt绕过应该是双HookSSL_CTX_set_verify控制校验过程本身。SSL_get_verify_result控制校验结果的返回值。HookSSL_get_verify_result更简单因为它没有参数只返回一个值var ssl_get_verify_result Module.findExportByName(libconscrypt.so, SSL_get_verify_result); if (ssl_get_verify_result ! null) { Interceptor.attach(ssl_get_verify_result, { onLeave: function (retval) { console.log([] SSL_get_verify_result returning: retval); // 强制返回X509_V_OK (0) retval.replace(ptr(0)); } }); }retval.replace(ptr(0))这行代码就是把函数的返回值强制修改为0即X509_V_OK。这是Native Hook最强大的地方你不仅能监听还能实时篡改返回值。踩坑实录我在Hook某款国际社交App时发现即使SSL_CTX_set_verify被成功替换App依然报错。用frida-trace -U -f com.app.id -i SSL_get_verify_result跟踪后发现它在握手后立刻调用了SSL_get_verify_result并根据返回值决定是否抛异常。这个坑让我花了整整两天时间才定位到。所以记住Conscrypt环境下SSL_get_verify_result是必Hook项不是可选项。5. 综合策略与避坑指南如何选择最适合你的那一招5.1 一张表帮你快速决策该用哪一招面对一个未知的App你不可能一上来就全量Hook。效率最高的方式是按顺序排查从最轻量、最通用的开始逐步深入。下面这张表总结了三种方法的适用场景、成功率、风险等级和实测耗时基于我过去一年在50款App上的测试数据方法Hook目标适用App特征成功率风险等级平均排查耗时关键判断依据Java层TrustManagerX509TrustManager.checkServerTrusted使用HttpsURLConnection、未加固、Target SDK 2868%★☆☆☆☆ (最低) 5分钟adb logcat | grep -i trustmanager有大量日志OkHttp栈CertificatePinner.checkSSLSocketFactory.createSocket使用OkHttp 3.x/4.x、有certificatePinner配置、无Native加固82%★★☆☆☆ (中低)10-20分钟jadx-gui反编译搜索CertificatePinner或OkHttpClient.BuilderConscrypt NativeSSL_CTX_set_verifySSL_get_verify_result使用Conscrypt Provider、Target SDK 29、有libconscrypt.so95%★★★★☆ (高)30-60分钟cat /proc/pid/maps | grep conscrypt有输出且Java层Hook全部失效这张表不是让你死记硬背而是给你一个决策树。例如你拿到一个新App第一步永远是adb logcat看有没有TrustManager相关日志第二步是jadx-gui打开APK全局搜索CertificatePinner第三步如果前两步都失败再adb shell进设备查maps。这个流程能帮你节省至少70%的无效尝试时间。5.2 五个血泪教训都是我亲手踩出来的坑不要相信“一次Hook永久有效”App热更新、插件化、动态下发SDK都会导致类名、包名、甚至so库路径发生变化。我曾经为一个App写了一个完美的Conscrypt Hook脚本结果它发了个热更新把libconscrypt.so改名叫libsecurecrypto.so脚本瞬间失效。解决方案在Frida脚本开头加一段自动探测so库名的逻辑用Process.enumerateModulesSync().filter(m m.name.includes(crypto) || m.name.includes(ssl))来泛匹配。Hook时机比Hook位置更重要很多脚本失败不是因为Hook错了函数而是Hook得太早或太晚。例如X509TrustManager的实例是在OkHttpClient构建时才创建的。如果你的Frida脚本在Java.perform里就去Hook但此时OkHttpClient还没初始化那Hook就等于没发生。正确做法是用Java.choose在onMatch回调里当发现目标类被实例化时再对其实例进行方法替换。这需要你对App的启动流程有基本了解。日志不是越多越好而是越精准越好新手常犯的错误是在每个Hook点都加console.log(I am here!)。结果一跑起来日志刷屏根本找不到关键信息。我的习惯是只在决策点和返回点打日志。比如在checkServerTrusted的onEnter里只打印hostname和chain.length在onLeave里只打印Verified: true。这样一眼就能看出校验是否真的被绕过。混淆不是障碍而是线索ProGuard/R8混淆后类名变成a.b.c方法名变成a()这看似增加了难度。但恰恰相反它暴露了App的架构。比如一个叫com.a.b.c.d的类如果它实现了X509TrustManager那它十有八九就是自研的校验器。你可以用jadx-gui的“Find Usage”功能反向追踪这个类被谁调用从而定位到网络请求的发起点。混淆反而让代码脉络更清晰。永远在真机上测试模拟器是最大的幻觉Conscrypt在模拟器和真机上的行为可能完全不同。某次我在Pixel模拟器上完美绕过结果拿到华为Mate 40真机上libconscrypt.so根本没加载App用的是华为自研的HwSSLProvider。后来发现华为、小米、OPPO都有自己的安全Provider它们的Native函数名、导出符号、甚至校验逻辑都不同。所以测试环境必须是目标机型的真实设备。最后分享一个小技巧当你不确定该Hook哪个函数时用frida-trace是个神技。比如frida-trace -U -f com.your.app -i *check*它会自动hook所有名字里带check的函数然后你只管发起一次HTTPS请求看哪个函数被调用、参数是什么、返回值是什么。这比盲猜高效十倍。我把它称为“逆向工程的雷达”。我在一线做逆向和安全测试的这十几年越来越确信一件事技术本身没有高下高下在于你是否愿意沉下去去看清每一层抽象之下的真实代码。Frida只是一个锤子而你要敲开的是整个Android网络栈的层层壁垒。这三种方法不是递进关系而是并列的、针对不同战场的战术选择。选对了事半功倍选错了徒劳无功。希望这篇从真实战场里滚出来的经验能帮你少走两年弯路。