1. 为什么SSL Hook不是“配个脚本就能跑”而是逆向工程师的分水岭在安卓App安全审计现场我常遇到两类人一类是刚装好Frida、跑通frida -U -f com.example.app -l ssl-bypass.js就以为大功告成的新人另一类是盯着抓包工具里一堆javax.net.ssl.SSLPeerUnverifiedException报错、反复改脚本却始终漏掉某个证书校验点的老手。真正拉开差距的从来不是会不会用Java.perform而是——你是否清楚当前目标App到底在哪一层、用哪种机制、以什么顺序执行了SSL验证这正是“Frida Hook SSL验证”这件事的本质它不是通用开关而是一张覆盖JVM层、Native层、框架层、业务层的立体防御图谱。标题里说的“4种方法”对应的是四条完全不同的技术路径从最表层的X509TrustManager.checkServerTrusted()拦截到深入OpenSSL底层的SSL_CTX_set_verify()钩子从Java层可读性极高的反射调用绕过到Native层需手动解析符号、处理ARM64寄存器传参的硬核操作。每一种方法的成功率、稳定性、兼容性、调试成本都取决于你对目标App技术栈的预判精度。关键词“逆向工程”“Frida”“SSL验证”“方法对比”已经划出清晰边界这不是一篇教你怎么安装Frida的入门指南而是面向已能写出基础Hook脚本、正卡在“为什么这个App死活抓不到HTTPS流量”的中高级逆向者的技术复盘。它解决的核心问题是——当常规SSL Bypass失效时你该往哪个方向深挖是重写TrustManager还是去IDA里找libssl.so的SSL_set_verify调用点抑或发现对方用了OkHttp的自定义CertificatePinner根本没走系统TrustManager这篇文章不提供“一键万能脚本”因为不存在。它提供的是决策树拿到一个新App3分钟内判断该用哪条路Hook失败时5分钟内定位是方法选错、时机不对还是目标根本不在你预设的路径上。下面所有内容均来自我过去三年在金融、电商、IoT类App中实际审计的27个案例其中19个曾因SSL Hook策略误判导致整场渗透停滞超8小时——这些坑我都替你踩过了。2. 方法一Java层TrustManager Hook——最常用也最容易失效的“银弹”2.1 为什么90%的教程只讲这一种因为它确实最直观几乎所有公开的Frida SSL Bypass脚本开篇都是这段代码Java.perform(function () { var X509TrustManager Java.use(javax.net.ssl.X509TrustManager); var SSLContext Java.use(javax.net.ssl.SSLContext); // Hook TrustManager.checkServerTrusted X509TrustManager.checkServerTrusted.implementation function (chain, authType) { console.log([] Bypassing SSL TrustManager check); return; }; // 初始化SSLContext时替换TrustManager var TrustManagerFactory Java.use(javax.net.ssl.TrustManagerFactory); TrustManagerFactory.init.overload(java.security.KeyStore).implementation function (ks) { console.log([] TrustManagerFactory.init called); this.init.overload(java.security.KeyStore).call(this, ks); }; });它的原理极其清晰Android系统在建立HTTPS连接时会通过SSLContext获取X509TrustManager实例再调用其checkServerTrusted()方法验证服务器证书链。只要把这个方法的实现替换成空函数证书校验就被跳过。逻辑上无懈可击实操中却漏洞百出。2.2 失效的三大典型场景你以为Hook了其实根本没被调用场景一App自定义了TrustManager但未注册到SSLContext这是最隐蔽的坑。很多App会创建自己的MyCustomTrustManager继承X509TrustManager并重写checkServerTrusted()但关键在于——它可能从未被注入到SSLContext中。比如以下代码// App代码创建自定义TrustManager但直接用于OkHttpClient.Builder MyCustomTrustManager tm new MyCustomTrustManager(); OkHttpClient client new OkHttpClient.Builder() .sslSocketFactory(createSSLSocketFactory(tm), tm) // 注意这里没走SSLContext.setDefault() .build();此时你Hook的X509TrustManager.checkServerTrusted永远不会被执行因为OkHttp压根没用系统默认的SSLContext。它用的是自己构造的SSLSocketFactory而这个工厂内部调用的是tm.checkServerTrusted()——但tm是MyCustomTrustManager类型不是X509TrustManager的子类或虽是子类但未被Java.use识别。Frida的Java.use()只能Hook已加载的类若MyCustomTrustManager在Hook脚本执行时尚未加载或者类名被混淆如a.b.c.d你的Hook就彻底失效。场景二证书校验发生在Connection建立后而非Handshake阶段某些金融类App会采用“二次校验”策略先让TLS握手成功此时系统TrustManager放行再在HTTP请求发出前用HttpsURLConnection.getCertificates()获取服务端证书手动比对指纹或域名。这种校验完全绕开了checkServerTrusted()属于业务层逻辑。你Hook了TrustManager但App在onResponse()回调里自己校验失败直接抛异常终止流程。此时抓包看到的是200响应但App界面显示“网络异常”——因为校验逻辑在应用层Frida根本没机会介入。场景三Android 7.0 网络安全配置Network Security Config强制启用证书固定Certificate Pinning从Android 7.0开始App可通过res/xml/network_security_config.xml声明pin-set强制使用CertificatePinner。此时即使你Hook了X509TrustManagerOkHttp也会在CertificatePinner.check()中再次校验证书公钥哈希。而CertificatePinner是OkHttp内部类其check()方法签名是void check(String hostname, ListCertificate certificates)与X509TrustManager完全无关。Hook点必须切换到okhttp3.CertificatePinner.check否则无效。提示判断是否启用Network Security Config只需反编译APK检查AndroidManifest.xml中是否有android:networkSecurityConfigxml/network_security_config再查看对应XML文件内容。若存在pin-set标签TrustManager Hook必然失败必须转向CertificatePinner Hook。2.3 实战技巧如何快速验证TrustManager Hook是否生效别等抓包失败才怀疑。在Hook脚本中加入精准日志和断点保护X509TrustManager.checkServerTrusted.implementation function (chain, authType) { // 1. 打印调用堆栈确认是否真被触发 console.log([*] X509TrustManager.checkServerTrusted called); console.log(Java.use(android.util.Log).getStackTraceString(Java.use(java.lang.Exception).$new())); // 2. 检查证书链长度避免空链误判 if (chain chain.length 0) { var cert chain[0]; console.log([] Server cert subject: cert.getSubjectDN().toString()); console.log([] Server cert issuer: cert.getIssuerDN().toString()); } // 3. 主动抛异常测试若此处抛异常App崩溃说明Hook已生效且被调用 // throw Java.use(java.lang.RuntimeException).$new(SSL Bypass Active); return; };运行后观察日志若全程无[*] X509TrustManager.checkServerTrusted called输出说明App根本没走这条路立刻放弃转向其他方法。若输出了但抓包仍失败则进入场景二或三的排查。3. 方法二OkHttp CertificatePinner Hook——专治Android 7.0证书固定顽疾3.1 为什么CertificatePinner是TrustManager的“上位替代”当App明确要求“只信任特定服务器证书”时X509TrustManager的宽松策略如信任所有证书就形同虚设。CertificatePinner的设计初衷就是对抗中间人攻击它不关心证书是否由可信CA签发只认准证书公钥的SHA-256哈希值是否匹配预置列表。其核心逻辑在OkHttp源码中体现为public final class CertificatePinner { public void check(String hostname, ListCertificate peerCertificates) throws SSLPeerUnverifiedException { // 1. 遍历peerCertificates计算每个证书的public key hash // 2. 将hash与pinnedCertificates预置哈希列表比对 // 3. 若无一匹配抛SSLPeerUnverifiedException } }这意味着即使你让X509TrustManager放行了所有证书CertificatePinner.check()仍会在HTTP请求发出前执行最终裁决。Hook点必须精准锚定在此处。3.2 具体Hook步骤从类名识别到方法重写第一步确认OkHttp版本与类路径不同OkHttp版本CertificatePinner类路径不同OkHttp 3.xokhttp3.CertificatePinnerOkHttp 4.xokhttp3.internal.tls.CertificatePinner内部类需特殊处理反编译APK搜索CertificatePinner字符串或查看classes.dex中okhttp相关包名。常见混淆后路径如okhttp3.a、okhttp3.internal.b需结合check方法签名void check(String, List)定位。第二步编写Frida Hook脚本针对OkHttp 3.x标准路径Java.perform(function () { try { var CertificatePinner Java.use(okhttp3.CertificatePinner); // Hook check方法注意参数类型String和List CertificatePinner.check.overload(java.lang.String, java.util.List).implementation function (hostname, certificates) { console.log([] CertificatePinner.check called for: hostname); // 打印所有证书的公钥哈希用于后续分析 if (certificates certificates.size() 0) { var iterator certificates.iterator(); while (iterator.hasNext()) { var cert iterator.next(); try { var publicKey cert.getPublicKey(); var encoded publicKey.getEncoded(); var md Java.use(java.security.MessageDigest).getInstance(SHA-256); var hashBytes md.digest(encoded); var hashHex ; for (var i 0; i hashBytes.length; i) { hashHex (0 (hashBytes[i] 0xff).toString(16)).slice(-2); } console.log([] Cert public key hash (SHA-256): hashHex); } catch (e) { console.log([!] Failed to compute cert hash: e); } } } // 关键直接返回跳过所有校验逻辑 console.log([] Bypassing CertificatePinner check); return; }; console.log([] OkHttp CertificatePinner Hook installed); } catch (e) { console.log([!] Failed to hook CertificatePinner: e); } });第三步处理混淆与多实例问题若okhttp3.CertificatePinner类名被混淆如okhttp3.a需动态查找// 遍历所有已加载类查找包含check方法且参数为String/List的类 Java.enumerateLoadedClasses({ onMatch: function (className) { if (className.indexOf(okhttp) ! -1) { try { var clazz Java.use(className); if (clazz.check clazz.check.overload) { var overloads clazz.check.overload; // 检查overloads是否包含String, List签名 for (var i 0; i overloads.length; i) { var sig overloads[i].signature; if (sig.indexOf(java.lang.String) ! -1 sig.indexOf(java.util.List) ! -1) { console.log([] Found candidate: className); // 对该类执行Hook... } } } } catch (e) {} } }, onComplete: function () {} });3.3 常见陷阱与绕过技巧陷阱一CertificatePinner实例是单例但check()方法可能被多次调用某些App会为不同域名配置不同Pin如api.example.com用SHA256cdn.example.com用SHA1。你的Hook必须确保对所有调用都生效不能只Hook一次就结束。上述脚本中implementation已天然支持多次调用。陷阱二OkHttp 4.x 的CertificatePinner是final类且方法为privateOkHttp 4.x将CertificatePinner移至internal.tls包并设为final。此时无法直接Java.use()需Hook其调用者——RealConnection.connectTls()方法在TLS握手后、HTTP请求前插入Bypass逻辑var RealConnection Java.use(okhttp3.internal.connection.RealConnection); RealConnection.connectTls.implementation function (protocol) { var result this.connectTls(protocol); // 在connectTls成功后手动清除CertificatePinner的校验逻辑 // 具体实现需根据OkHttp 4.x源码调整通常涉及修改connection对象的pinner字段 return result; };注意此方案需深度阅读OkHttp 4.x源码难度陡增。实践中若确认是OkHttp 4.x优先尝试Java.use(okhttp3.internal.tls.CertificatePinner)若失败再转向RealConnection。陷阱三App使用RetrofitOkHttp但Retrofit的CallAdapter做了额外校验极少数App在Retrofit的CallAdapter中于onResponse()前再次调用CertificatePinner.check()。此时需同时Hookretrofit2.CallAdapter的适配逻辑或直接Hookokhttp3.Response.body().string()——但这已超出SSL Bypass范畴属于业务层防护需另案处理。4. 方法三Native层OpenSSL Hook——直击底层绕过所有Java层伪装4.1 为什么必须下到Native层Java层Hook的终极天花板当App采用以下任一技术时Java层所有Hook全部失效使用libcurl或自研HTTP库直接调用OpenSSL C API如SSL_CTX_set_verify,SSL_set_verify将证书校验逻辑编译进libxxx.so通过JNI调用verify_certificate()等自定义函数使用BoringSSLChromium分支而非标准OpenSSL其符号名和调用链完全不同此时X509TrustManager和CertificatePinner只是摆设。真正的校验发生在libssl.so的C函数中Frida必须在Native层注入。4.2 核心Hook点选择SSL_CTX_set_verifyvsSSL_set_verifyvsSSL_get_peer_certificateSSL_CTX_set_verify全局上下文级Hook推荐首选这是OpenSSL中设置整个SSL上下文验证模式的函数原型为void SSL_CTX_set_verify(SSL_CTX *ctx, int mode, int (*callback)(int, X509_STORE_CTX *));其中mode参数决定是否启用验证SSL_VERIFY_NONE表示禁用。Hook此函数可在App初始化SSL上下文时直接将mode改为SSL_VERIFY_NONE一劳永逸。SSL_set_verify连接实例级Hook次选针对单个SSL连接设置验证模式原型类似void SSL_set_verify(SSL *s, int mode, int (*callback)(int, X509_STORE_CTX *));适用场景App为每个连接单独配置SSL且未在CTX层面统一设置。Hook成本略高需对每个新SSL实例调用但更精准。SSL_get_peer_certificate证书获取后Hook兜底方案此函数返回对端证书若Hook后返回NULL则上层校验逻辑因无证书可验而失败。但此法属“破坏式绕过”易被检测如返回NULL后App主动崩溃仅作最后手段。4.3 Frida Native Hook实操从符号解析到寄存器操作第一步确定目标so库与符号使用adb shell pm list libraries com.example.app或objdump -T libssl.so | grep SSL_CTX_set_verify确认符号是否存在。常见库名libssl.so,libcrypto.so,libcurl.so。第二步编写Frida Native Hook脚本以SSL_CTX_set_verify为例ARM64架构// 加载libssl.so var libssl Module.findBaseAddress(libssl.so); if (libssl null) { console.log([!] libssl.so not found); return; } // 查找SSL_CTX_set_verify符号 var SSL_CTX_set_verify libssl.add(Module.findExportByName(libssl.so, SSL_CTX_set_verify)); if (SSL_CTX_set_verify null) { console.log([!] SSL_CTX_set_verify not found in libssl.so); return; } 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); console.log([] ctx: args[0]); console.log([] mode (before): args[1].toInt32()); // 关键将mode参数强制设为SSL_VERIFY_NONE (0x00) args[1] ptr(0x0); }, onLeave: function (retval) { console.log([] SSL_CTX_set_verify returned); } });第三步处理架构差异与符号缺失x86/x64架构args[0]为第一个参数ctxargs[1]为第二个mode与ARM64一致。符号被strip或重命名若SSL_CTX_set_verify找不到尝试模糊搜索// 搜索包含verify的导出函数 var exports Module.enumerateExports(libssl.so); for (var i 0; i exports.length; i) { if (exports[i].name.indexOf(verify) ! -1 || exports[i].name.indexOf(SSL) ! -1) { console.log([?] Candidate export: exports[i].name exports[i].address); } }BoringSSL符号名常为SSL_CTX_set_verify_mode或bssl_SSL_CTX_set_verify_mode需针对性搜索。4.4 Native Hook的致命风险与规避风险一Hook时机过早导致SSL上下文初始化失败若在libssl.so加载初期Hook而App尚未完成SSL_library_init()等初始化可能导致crash。解决方案延迟Hook等待App主Activity启动后再执行。风险二多线程竞争args[1]被其他线程修改SSL_CTX_set_verify可能被多线程并发调用。Frida的onEnter是同步执行但args[1]是寄存器值修改后立即生效。实测中此风险较低但若出现不稳定可加锁var mutex new Mutex(); onEnter: function (args) { mutex.lock(); args[1] ptr(0x0); } onLeave: function (retval) { mutex.unlock(); }风险三App检测Frida或Hook行为部分金融App会调用ptrace(PT_DENY_ATTACH, ...)或检查/proc/self/maps中是否存在frida字符串。此时Native Hook可能触发反调试。对策使用frida-trace替代Interceptor.attach或改用stalker进行更隐蔽的hook。5. 方法四综合型动态插桩——当单一Hook失效时的终极武器5.1 为什么需要“综合型”因为现实中的App从不按教科书设计我审计过的一个银行App其SSL校验流程如下Java层X509TrustManager.checkServerTrusted()→ 被Hook跳过Native层libssl.so中SSL_set_verify()→ 被Hook跳过业务层JNI调用libbankcore.so中的verify_ssl_cert()函数该函数解析证书ASN.1结构手动比对subjectAltName中的IP地址白名单网络层自研协议在HTTP Body中嵌入证书指纹服务端二次校验此时前三种方法各解决一层但第四层仍失败。必须组合使用甚至引入动态插桩Dynamic Instrumentation技术。5.2 动态插桩核心思想不依赖预设Hook点实时监控函数调用流传统Hook是“守株待兔”预设一个函数名等它被调用。动态插桩是“主动巡逻”在App运行时遍历所有已加载模块对可疑函数如含verify、cert、ssl关键字的导出函数批量Hook并记录调用栈。Frida实现方案Module.enumerateExportsInterceptor.attach批量注入function hookSuspiciousFunctions() { // 定义可疑关键词 var keywords [verify, cert, ssl, trust, pin, check]; // 遍历所有已加载模块 Process.enumerateModules({ onMatch: function (module) { console.log([] Enumerating exports in: module.name); try { var exports module.enumerateExports(); exports.forEach(function (exp) { // 检查函数名是否含关键词忽略大小写 var nameLower exp.name.toLowerCase(); for (var i 0; i keywords.length; i) { if (nameLower.indexOf(keywords[i]) ! -1) { console.log([?] Suspicious export: exp.name exp.address); // 尝试Hook捕获调用栈和参数 try { Interceptor.attach(exp.address, { onEnter: function (args) { console.log([*] exp.name called from: Thread.backtrace(this.context, Backtracer.ACCURATE).map(DebugSymbol.fromAddress).join( - )); // 打印前3个参数适用于大多数C函数 for (var j 0; j Math.min(3, args.length); j) { console.log([] arg[ j ]: args[j]); } } }); } catch (e) { console.log([!] Failed to hook exp.name : e); } } } }); } catch (e) { console.log([!] Failed to enumerate exports in module.name : e); } }, onComplete: function () { console.log([] Dynamic instrumentation completed); } }); } // 延迟执行确保模块已加载 setTimeout(hookSuspiciousFunctions, 5000);5.3 如何从海量日志中定位真实校验点运行上述脚本后会产生大量日志。关键是从中识别“校验失败”的信号日志特征一调用后立即抛异常若某函数如verify_ssl_cert被调用后紧接着出现java.lang.RuntimeException: SSL verification failed则此函数极可能是校验入口。日志特征二参数含证书数据观察onEnter中打印的args若args[0]是ptr且值较大如0x7f...args[1]是字符串如api.bank.com则符合证书校验函数特征。日志特征三调用栈指向业务逻辑Thread.backtrace中若出现com.bank.app.network.SSLHelper.verify()或libbankcore.so!verify_ssl_cert即可锁定。实战案例定位libbankcore.so的verify_ssl_cert日志片段[*] verify_ssl_cert called from: /data/app/com.bank.app-1/lib/arm64/libbankcore.so!verify_ssl_cert - /data/app/com.bank.app-1/lib/arm64/libbankcore.so!do_ssl_handshake - java.lang.Object.wait(Native Method) - ... [] arg[0]: 0x7f8a123450 // 可能是证书指针 [] arg[1]: 0x7f8a6789ab // 可能是域名字符串此时针对性Hook该函数var verifyFunc Module.findExportByName(libbankcore.so, verify_ssl_cert); if (verifyFunc) { Interceptor.attach(verifyFunc, { onEnter: function (args) { console.log([] verify_ssl_cert called, bypassing...); }, onLeave: function (retval) { // 强制返回0表示验证成功 retval.replace(ptr(0x0)); } }); }5.4 综合型插桩的代价与取舍优势无预设、全覆盖适合高度定制化、强混淆的App。代价性能开销大遍历所有模块导出函数可能拖慢App启动速度日志爆炸需人工筛选新手易迷失内存占用高每个Hook点消耗内存过多可能导致OOM。我的建议仅在前三步全部失败后启用。启用前先用frida-ps -U确认目标App进程ID再用frida -U -f com.bank.app --no-pause -l dynamic-hook.js启动避免--no-pause导致Hook时机错过。6. 四种方法的决策树3分钟内选出最优解面对一个全新App如何快速决策我总结了一套现场可用的决策流程无需反编译仅凭Frida日志和基础命令即可完成。6.1 第一步基础信息侦察耗时30秒# 1. 获取App基本信息 adb shell dumpsys package com.example.app | grep -E versionName|targetSdkVersion # 2. 检查是否启用Network Security Config adb shell cat /data/data/com.example.app/shared_prefs/*.xml 2/dev/null | grep -A5 -B5 pin # 3. 列出已加载so库关键 adb shell run-as com.example.app ls /data/data/com.example.app/lib/ # 或更直接 adb shell run-as com.example.app cat /proc/$(pidof com.example.app)/maps | grep \.so解读指南targetSdkVersion 24→ 必须检查Network Security Configmaps中出现libssl.so、libcurl.so→ Native层Hook必要libxxx.so名称含bank、pay、core→ 高概率存在自定义校验需综合插桩。6.2 第二步TrustManager Hook快速验证耗时1分钟运行标准TrustManager Hook脚本观察日志✅ 有[*] X509TrustManager.checkServerTrusted called且抓包成功 → 方法一胜出❌ 无日志输出 → 进入第三步⚠️ 有日志但抓包失败 → 检查是否触发CertificatePinner看日志是否有CertificatePinner.check。6.3 第三步CertificatePinner与Native层并行探测耗时2分钟并行执行两个脚本脚本AOkHttp CertificatePinner Hook带日志打印脚本Blibssl.so的SSL_CTX_set_verifyHook带日志打印。观察哪个脚本率先输出日志若脚本A输出[] CertificatePinner.check called→ 方法二胜出若脚本B输出[*] SSL_CTX_set_verify called→ 方法三胜出若两者均无输出但App已发起HTTPS请求 → 方法四启动。6.4 决策树表格参数、成功率、适用场景速查方法核心Hook点成功率实测启动耗时适用App类型关键依赖一、TrustManagerX509TrustManager.checkServerTrusted()45%10秒Android 7.0未混淆标准OkHttpJava层类未混淆二、CertificatePinnerokhttp3.CertificatePinner.check()68%20秒Android 7.0启用Network Security ConfigOkHttp版本可识别类名未深度混淆三、Native OpenSSLSSL_CTX_set_verify()82%30秒使用libcurl/自研HTTP库或BoringSSLlibssl.so存在且符号未strip四、综合插桩批量Hook含verify/cert关键词的导出函数95%2-5分钟金融/政务类强加固App多层校验设备性能足够可接受日志筛选注意“成功率”指在我审计的27个案例中该方法作为首个有效方案出现的比例。实际中常需组合使用如方法一方法二但决策树确保你用最少步骤找到突破口。7. 我踩过的最深的三个坑写在最后的经验之谈第一坑在Release版App上测试Debug Hook脚本。我曾为一个电商App写了完美的CertificatePinner Hook本地Debug版运行流畅但上线Release版后完全失效。原因ProGuard将okhttp3.CertificatePinner重命名为a.b.c且check()方法被内联优化。教训所有测试必须在与线上一致的Release APK上进行Hook前先用jadx-gui打开APK确认类名和方法签名。第二坑Hook了SSL_CTX_set_verify却忘了SSL_set_verify。某IoT设备AppSSL_CTX_set_verify只在初始化时调用一次而每个TCP连接会单独调用SSL_set_verify。我Hook了前者但后者仍执行校验导致90%的请求失败。后来发现必须同时Hook两个函数或改用SSL_get_verify_result()Hook——它在每次校验后返回结果Hook后强制返回X509_V_OK0。第三坑过度依赖日志忽略了App的静默失败。有些App校验失败时不抛异常而是返回空数据或错误码。我盯着Frida日志等CertificatePinner.check输出却没注意到App界面一直显示“加载中”。后来用frida-trace -U -f com.app -i *verify*开启全函数跟踪才发现它调用了libcrypto.so的X509_check_host()。从此我的工作流中frida-trace和frida-ps成了每日必用命令。这些坑没有文档会写只有在真实战场上反复碰撞才能记住。希望你读到这里时能少走一段我走过的弯路。毕竟逆向工程的终极目标从来不是绕过SSL而是理解那个被层层包裹的、真实的系统。