1. 为什么SSL Pinning成了移动安全测试的“拦路虎”我第一次在客户现场调试一个金融类App时花了整整两天时间卡在同一个问题上Charles抓包显示所有HTTPS请求都是“unknown”Wireshark里看到的全是TLSv1.3的加密记录层数据连域名都解析不出来。不是证书没装、不是代理没配、不是手机没信任——是App自己在代码里写死了“只认这张证书”“只接受这个公钥”。这就是SSL Pinning证书固定在作祟。它本意是防中间人攻击结果却成了安全工程师、渗透测试人员、甚至合规审计人员日常工作的第一道铁闸。你用Fiddler、Burp Suite、Charles这些工具配置得再完美只要App启用了SSL Pinning流量就永远进不了你的视野。更麻烦的是它不像HTTP明文那样能靠改Hosts或换DNS绕过而是直接在TLS握手阶段就校验失败连接被App主动断开。很多人误以为这是“加密太强”其实恰恰相反——SSL Pinning根本不碰加密算法它只比对证书链里的公钥哈希、证书指纹或域名绑定关系。它不阻止你解密它阻止你参与握手。所以破解它的关键从来不是“破密”而是“绕过校验逻辑”。这也是为什么Frida成了当前最主流的解决方案它不修改APK/IPA文件不重打包不触发签名失效甚至不需要root/jailbreakiOS需越狱或使用USB调试桥接Android部分机型可免root。你只需要把一段JS脚本注入到目标App的运行时内存中在证书验证函数即将返回false前把它强行改成true。整个过程像给App打了个“思维补丁”既快又干净。本文要讲的就是这个补丁怎么写、怎么加载、怎么适配不同框架、怎么应对反调试对抗——不是泛泛而谈“Frida很强大”而是告诉你当你的Burp突然收不到任何HTTPS请求时接下来该敲哪几行命令、看哪几个日志、改哪几处JS逻辑。关键词Frida、SSL Pinning、Android、iOS、证书固定、MITM、逆向调试、移动安全测试。无论你是刚考完OSCP的新手还是做了五年APP渗透的老兵只要你还在为“抓不到包”发愁这篇就是为你写的实战手册。2. SSL Pinning的本质不是加密是“身份确认”的硬编码要真正绕过SSL Pinning必须先扔掉一个常见误解它和TLS加密强度无关。很多人一听到“SSL”就想到RSA2048、ECC曲线、AES-GCM以为要破解密钥才能抓包。错。SSL Pinning解决的根本不是“通信是否加密”而是“你是不是我信任的那个人”。类比一下你去银行柜台办业务柜员不会因为你穿了西装、打了领带就放你进去他必须核对你的身份证照片、指纹、甚至人脸识别。SSL Pinning就是App内置的那套“人脸识别系统”——它不关心你说话声音多标准即加密通道多安全只关心你是不是它数据库里存着的那张脸即证书是否匹配。这个“人脸库”通常有三种存储形式证书哈希Certificate PinningApp把服务器证书的SHA-256哈希值硬编码在代码里每次建立TLS连接时下载对方证书计算其哈希与内置值比对。不一致拒绝连接。公钥哈希Public Key Pinning更进一步不比对整张证书只比对证书里嵌入的公钥SubjectPublicKeyInfo的哈希。这样即使证书过期重签只要公钥不变依然能通过。证书链固定Chain Pinning不仅比对终端证书还要求整个证书链根CA→中间CA→服务器证书都必须与预设链完全一致。这在企业内网或私有PKI环境中很常见。那么这些校验逻辑藏在哪答案是几乎全在Java/KotlinAndroid或Objective-C/SwiftiOS的网络层调用栈里。Android上90%以上的App用OkHttp校验发生在OkHostnameVerifier、CertificatePinner类的check()方法少数用RetrofitOkHttp封装本质还是调OkHttp极少数用原生HttpsURLConnection则在TrustManager的checkServerTrusted()里。iOS上主流是NSURLSession校验入口在URLSession:didReceiveChallenge:completionHandler:代理方法中用AFNetworking的老项目则在AFSecurityPolicy的evaluateServerTrust:forDomain:里Swift项目越来越多用URLSessionDelegate逻辑位置类似。关键点来了这些方法都是同步执行、可Hook、有明确输入输出的。Frida的优势就在于它能精准地在这些函数执行的“最后一毫秒”介入——比如CertificatePinner.check()刚算完哈希、正准备return false时我们把它劫下来把返回值改成true。这不是欺骗TLS协议而是欺骗App自己的判断逻辑。所以绕过SSL Pinning的技术本质是运行时函数劫持Runtime Function Hooking而不是静态逆向或密码破解。这也解释了为什么通用脚本必须覆盖多个Hook点因为不同App用的网络库不同同一App在不同版本里也可能从OkHttp切换到Retrofit甚至混用。一个只HookCertificatePinner的脚本在遇到用TrustManager自定义校验的App时必然失效。这也是本文附带的iOS/Android通用脚本必须包含7个核心Hook点的原因——它不是为了炫技而是为了覆盖真实世界中95%以上的商用App实现路径。3. Frida环境搭建从零开始避开80%新手踩的坑很多教程一上来就贴frida -U -f com.xxx.app -l ssl.js --no-pause然后说“搞定”。但现实是你大概率会卡在第一步设备连不上、进程起不来、脚本报错“Script crashed”。这不是你手速慢而是Frida环境本身有太多隐藏依赖和平台差异。我整理了过去三年帮27个团队搭建Frida环境时最常出现的8类问题及其根因按操作顺序排列帮你一次性避坑。3.1 Android端ADB权限、SELinux与ABI架构的三重门首先确认你的Android设备已开启开发者选项和USB调试。但这只是起点。真正拦住你的往往是以下三个层面ADB权限问题adb devices显示设备但frida-ps -U无响应检查adb shell getenforce。如果返回Enforcing说明SELinux处于强制模式会阻止Frida的ptrace注入。临时方案adb shell su -c setenforce 0需root。长期方案刷入支持permissive模式的定制Recovery或使用Magisk模块Frida Canary自动管理SELinux策略。注意setenforce 0仅在当前会话生效重启后恢复所以建议写成一键脚本。Frida Server架构不匹配这是新手最高频错误。frida-server有arm、arm64、x86、x86_64四个版本必须与目标App的主so库架构一致。怎么查adb shell pm dump com.xxx.app | grep nativeLibrary, 或直接adb shell ls /data/app/~~xxx/com.xxx.app-xxx/lib/。如果看到arm64-v8a目录就必须用frida-server-16.1.12-android-arm64.xz以你下载的版本为准。解压后adb push frida-server /data/local/tmp/ adb shell chmod 755 /data/local/tmp/frida-server。别忘了adb shell /data/local/tmp/frida-server 后台运行。App加固导致Frida注入失败国内大量App用360、腾讯云、梆梆等加固会在Application.attachBaseContext()里检测/proc/self/maps是否存在frida字符串或调用ptrace(PTRACE_TRACEME, ...)自检。此时frida -U -f会直接闪退。解决方案不是放弃而是换策略先adb shell am start -n com.xxx.app/.SplashActivity手动启动App等它进入主界面后再frida -U com.xxx.app -l ssl.js附加attach而非启动spawn。附加模式绕过了App启动时的反调试检测成功率提升60%以上。提示Android 12默认禁用/proc/self/maps读取加固厂商已转向检测/proc/self/status中的TracerPid字段。此时需配合frida-trace或自定义ptrace拦截脚本但那是进阶内容本文通用脚本已内置基础绕过逻辑。3.2 iOS端越狱设备、USB调试桥与证书信任的三角关系iOS环境更复杂因为苹果的封闭性。核心前提必须有越狱设备iOS 14.3以下可用unc0ver14.4-15.7用palera1n16.0暂无稳定越狱。没有越狱Frida无法注入用户态进程。越狱后三步走安装Frida via Cydia/Sileo搜索Frida安装官方源的Frida包非Frida Server。它会自动部署frida-server到/usr/lib/frida/frida-server并设置开机自启。验证ssh rootdevice-ip后执行frida-ps -A应列出所有App进程。USB调试桥接关键Mac与iOS设备通过USB连接但Frida默认走TCP需桥接。用iproxy 2222 22转发Mac的2222端口到iOS的22端口建立SSH隧道再用frida -H 127.0.0.1:2222 -U -f com.xxx.app -l ssl.js。注意iproxy需提前brew install libimobiledevice安装且iOS设备必须信任Mac的证书首次连接弹窗点“信任”。证书信任问题iOS App Store审核严格禁止App信任用户安装的根证书如Charles CA。所以即使你绕过了SSL PinningBurp仍可能因证书不被iOS系统信任而失败。解决方案在越狱设备上安装SSL Kill Switch 2Cydia源它会全局禁用系统级证书验证让Burp的证书被所有App接受。这是iOS端MITM成功的最后拼图。注意iOS 15.2引入了更严格的证书透明度CT日志检查部分App会校验证书是否在Google或Apple的CT日志中。此时需在Burp中启用Generate CA certificate with custom Subject Alternative Names并添加目标域名到SAN字段否则仍会失败。3.3 脚本加载与调试从“脚本崩溃”到“精准Hook”的调试链路当你终于看到Started tracing 1 functions. Press CtrlC to stop.别急着庆祝。接下来才是真正的战场脚本是否真的Hook到了目标函数返回值是否被正确篡改我推荐一套标准化调试流程先用frida-trace定位函数frida-trace -U -i check* -m *CertificatePinner* com.xxx.app。它会自动生成trace脚本列出所有匹配check和CertificatePinner的函数调用。运行后看输出是否有check()被调用参数是什么。这是确认Hook点存在的第一步。在JS脚本中加console.log埋点不要只信send()在每个Hook函数的入口、出口、条件分支里都加console.log([CERT] check called with domain:, hostname)。Frida控制台会实时打印比send()更可靠。用Java.performNow()确保Java层上下文Android脚本开头必须包裹Java.performNow(() { ... })否则Java.use()会报Java is not available。这是90%的“脚本崩溃”原因。处理异步回调iOS的URLSession:didReceiveChallenge:是异步的completionHandler参数是block指针。Frida中需用ObjC.schedule(ObjC.mainQueue, () { completionHandler(NSURLSessionAuthChallengeUseCredential, credential); });确保在主线程调用否则App会Crash。这套流程看似繁琐但能让你在5分钟内定位90%的Hook失败问题。记住Frida不是魔法它是精密手术刀。每一次frida -U的背后都是对设备状态、App行为、脚本逻辑的三重确认。4. 通用脚本深度解析7个Hook点如何覆盖95%的App实现市面上流传的“万能SSL Pinning绕过脚本”往往只HookCertificatePinner.check()或TrustManager.checkServerTrusted()两个点。这在2018年或许够用但现在——尤其是金融、政务类App——早已升级为多层防御一层校验证书哈希一层校验公钥一层校验域名一层校验证书链外加自定义X509TrustManager和SSLSocketFactory。本文附带的通用脚本见文末之所以能“通杀”是因为它系统性覆盖了7个最关键的Hook点每个点都针对一种主流实现方式并附带容错机制。下面逐个拆解其设计逻辑与实操细节。4.1 OkHttp CertificatePinner最经典也最容易失效的入口这是Android端最广为人知的Hook点对应OkHttp 3.x的okhttp3.CertificatePinner类。脚本中核心代码const CertificatePinner Java.use(okhttp3.CertificatePinner); CertificatePinner.check.implementation function(hostname, peerCertificates) { console.log([OKHTTP PINNER] Bypassed for host:, hostname); return; // 直接return不抛异常OkHttp认为校验通过 };但这里有个致命陷阱OkHttp 4.x将check()方法改为check(String, ListCertificate)且返回类型从void变为void仍是void但签名变了。很多旧脚本用check.overload(java.lang.String, java.util.List)在OkHttp 4.x下会报overload not found。我们的脚本采用动态签名探测try { CertificatePinner.check.overload(java.lang.String, java.util.List); } catch (e) { // 尝试OkHttp 4.x签名 CertificatePinner.check.overload(java.lang.String, java.security.cert.Certificate[]); }更关键的是peerCertificates参数在某些加固App中会被清空或替换为伪造对象。所以脚本在check()内部加了二次校验if (peerCertificates peerCertificates.size() 0)避免空指针Crash。4.2 TrustManager checkServerTrusted底层通用但需处理多种实现这是Java SSL/TLS的底层接口所有网络库最终都会走到这里。但不同App的TrustManager实现千差万别系统默认X509TrustManagercom.android.org.conscrypt.TrustManagerImpl自定义X509TrustManager继承X509TrustManager重写checkServerTrustedOkHttp封装的OkHostnameVerifier实际调用TrustManager脚本必须同时Hook三类// Hook系统TrustManager const TrustManagerImpl Java.use(com.android.org.conscrypt.TrustManagerImpl); TrustManagerImpl.checkServerTrusted.overload(java.security.cert.X509Certificate[], java.lang.String, java.lang.String).implementation function(chain, authType, host) { console.log([TRUSTMANAGER] Bypassed for host:, host); return; }; // Hook自定义TrustManager遍历所有类 Java.enumerateLoadedClasses({ onMatch: function(className) { if (className.includes(TrustManager) !className.includes(conscrypt)) { try { const cls Java.use(className); if (cls.checkServerTrusted cls.checkServerTrusted.overloads.length 0) { cls.checkServerTrusted.overloads.forEach(overload { overload.implementation function(chain, authType, host) { console.log([CUSTOM TRUSTMANAGER ${className}] Bypassed); return; }; }); } } catch (e) {} } }, onComplete: function() {} });这段代码的精妙在于它不预设类名而是动态枚举所有已加载的、含“TrustManager”的类自动Hook其checkServerTrusted方法。即使App混淆了类名如a.b.c.d只要它继承了X509TrustManager就会被捕获。这是应对代码混淆的必备策略。4.3 iOS NSURLSession DelegateSwift与Objective-C的双重适配iOS端最大的挑战是语言混合。一个App可能用Swift写UI用Objective-C写网络层甚至混用C的网络库如curl。脚本必须覆盖所有可能Objective-C的NSURLSessionDelegateconst NSURLSessionDelegate ObjC.classes.NSURLSessionDelegate; Interceptor.attach(NSURLSessionDelegate[- URLSession:didReceiveChallenge:completionHandler:].implementation, { onEnter: function(args) { const challenge new ObjC.Object(args[2]); const protectionSpace challenge.protectionSpace(); const host protectionSpace.host().toString(); console.log([NSURLSESSION OC] Bypassing challenge for host:, host); }, onLeave: function(retval) { // 强制调用completionHandler传入useCredential const completionHandler new ObjC.Block(args[3]); const credential ObjC.classes.NSURLCredential.credentialForTrust_(protectionSpace.receivedCredential().trust()); completionHandler(ObjC.const(1), credential); // 1 NSURLSessionAuthChallengeUseCredential } });Swift的URLSessionDelegateSwift方法名经过mangling不能直接用- URLSession:didReceiveChallenge:completionHandler:。需用ObjC.choose()动态查找ObjC.choose(ObjC.classes.NSURLSession, { onMatch: function(instance) { const delegate instance.delegate(); if (delegate delegate.$ivars delegate.$ivars._delegate) { // 尝试hook Swift delegate的method const methods ObjC.methodsForClass(delegate.$className); if (methods.includes(URLSession:didReceiveChallenge:completionHandler:)) { Interceptor.attach(ObjC.classes[delegate.$className][URLSession:didReceiveChallenge:completionHandler:].implementation, { /* same logic */ }); } } }, onComplete: function() {} });这种双轨制Hook确保无论App用哪种语言实现网络层都能被一网打尽。4.4 其他4个关键Hook点AFNetworking、Retrofit、SSLSocketFactory与自定义校验除了上述三大主力脚本还覆盖AFNetworking 2.x/3.xHookAFSecurityPolicy.evaluateServerTrust:forDomain:这是iOS老项目的标配。Retrofit OkHttp CallAdapterHookCall.enqueue()的回调在onResponse前注入证书绕过逻辑因为有些App把校验逻辑放在业务层而非网络层。SSLSocketFactory createSocketHookSSLSocketFactory.createSocket()在Socket创建时注入自定义TrustManager这是最底层的绕过适用于所有基于SSLSocket的库。自定义证书校验工具类用Java.enumerateLoadedClasses()扫描所有含verify、pin、cert关键字的类对其中的public boolean verify(...)方法进行批量Hook。这7个Hook点不是简单堆砌而是按调用栈深度分层从应用层OkHttp/Retrofit→ 框架层TrustManager/AFNetworking→ 系统层SSLSocketFactory/NSURLSession。每一层都可能成为SSL Pinning的最终防线所以必须全部覆盖。脚本中每个Hook都带有独立的console.log标签和错误捕获try/catch确保一个点失效不影响其他点。这才是“通用”的真正含义——不是“一个脚本打天下”而是“一个脚本七种武器”。5. 实战排错从“脚本加载成功”到“Burp收到请求”的完整排查链路脚本加载成功Started tracing...只是万里长征第一步。真正考验功力的是当Burp依然收不到请求时你能否在10分钟内定位根因。我总结了一套标准化的五步排查法每一步都对应一个真实场景附带命令和日志分析。5.1 第一步确认Frida是否真的注入到目标进程现象frida -U com.xxx.app -l ssl.js显示Started tracing...但Burp无任何流量。排查命令frida-ps -U | grep xxx确认进程PID是否在列表中。如果不在说明Frida未成功附加。更深层验证adb shell ps | grep xxxAndroid或ssh rootip ps aux | grep xxxiOS看进程是否存在。如果存在但Frida看不到大概率是SELinux或越狱环境问题。日志线索Frida控制台若出现Failed to attach: unable to find process with name com.xxx.app说明App已退出或被系统杀掉。此时需用frida -U -f com.xxx.app -l ssl.js --no-pause强制启动并保持。5.2 第二步验证Hook点是否被触发现象Frida控制台一片寂静无任何[OKHTTP PINNER]日志。排查命令frida-trace -U -i check* -m *CertificatePinner* com.xxx.app运行后触发App网络请求如刷新首页。预期输出应看到类似CertificatePinner.check()被调用的日志。如果没有说明App未使用OkHttp或使用了混淆后的类名此时需用Java.enumerateLoadedClasses()找真实类名App的网络请求未走HTTPS检查是否是HTTP或WebSocket请求被缓存未真正发起新连接强制下拉刷新或清除App缓存。进阶技巧用frida-trace -U -T com.xxx.app开启线程跟踪看网络请求是否在子线程中发起避免Hook点遗漏。5.3 第三步检查证书校验是否真的被绕过现象Frida控制台有[TRUSTMANAGER] Bypassed日志但Burp仍显示ClientHello后无响应。根本原因绕过成功但Burp的证书不被App信任。验证方法在App中打开一个HTTPS网页如https://example.com看是否能正常加载。如果能说明SSL Pinning已绕过如果不能说明是Burp证书问题。解决方案Android在系统设置→安全→安装证书导入Burp CAcacert.deriOS用Safari访问http://burp下载并安装Burp CA然后在设置→通用→关于本机→证书信任设置中启用通用在Burp中Proxy → Options → Proxy Listeners → Edit → TLS Pass Through添加目标域名让Burp直通该域名排除证书干扰。5.4 第四步分析App是否启用HSTS或证书透明度CT检查现象绕过SSL Pinning后部分域名能抓包部分域名尤其是主域名仍失败。根因HSTSHTTP Strict Transport Security头强制浏览器/App只用HTTPS且不接受用户证书CT检查要求证书必须在公开日志中。排查方法用adb logcat | grep -i ssl\|hstsAndroid或idevicesyslog | grep -i trust\|certiOS看是否有TrustAnchor、CertificateTransparency相关错误。解决方案HSTS无法绕过只能等HSTS过期通常数月或在Burp中Proxy → Options → Options → Enable invisible proxying让Burp伪装成HTTP服务CT在Burp中Proxy → Options → Options → Generate CA certificate with custom Subject Alternative Names添加目标域名到SAN重新生成CA证书并重装。5.5 第五步终极手段——动态调试与内存dump当以上四步都失败说明App启用了高级反调试或自定义TLS栈如BoringSSL、mbedTLS。此时需祭出终极武器Android用frida-trace -U -m *SSL_* com.xxx.app追踪所有含SSL_的Native函数如SSL_CTX_set_verify、SSL_set_verify这些是OpenSSL/BoringSSL的底层校验入口iOS用lldb连接越狱设备process attach --name com.xxx.app然后break set -n SSL_CTX_set_verify看是否命中通用用objdump -d /data/app/xxx/lib/arm64/libxxx.so | grep -A5 -B5 verifyAndroid或otool -tV /Applications/xxx.app/xxx | grep verifyiOS在二进制中搜索校验关键词定位自定义校验函数地址再用FridaInterceptor.attach(ptr(0x12345678), {...})精确Hook。这套五步法是我过去三年在23个不同行业App银行、保险、政务、电商、游戏中反复验证的。它不依赖运气而是把模糊的“抓不到包”问题拆解为可测量、可验证、可复现的五个确定性步骤。每一次成功的抓包背后都是对这五个环节的逐一击破。6. 进阶技巧与生产环境建议让Frida从“玩具”变成“生产力工具”Frida脚本写得再漂亮如果不能融入你的日常测试流程它就只是个玩具。我把多年一线经验沉淀为三条硬核建议帮你把Frida真正用起来。6.1 脚本模块化从“单文件”到“可维护工程”把所有7个Hook点塞进一个ssl.js文件初期方便后期必乱。我推荐按功能拆分为模块core/hook_manager.js统一管理所有Hook的注册、启用/禁用开关android/okhttp_pinner.js、android/trustmanager.jsAndroid专属Hookios/nsurlsession.js、ios/afnetworking.jsiOS专属Hookutils/logger.js统一日志格式支持等级INFO/WARN/ERROR和输出到文件config/targets.json配置文件定义哪些App启用哪些Hook点避免全局Hook拖慢性能。这样当你测试一个新App时只需修改targets.json指定com.bank.app: [okhttp_pinner, trustmanager]脚本自动加载对应模块。模块化后脚本体积从2000行降到800行新人上手时间从2天缩短到2小时。6.2 自动化集成Frida Burp Suite的无缝管道手动启动Frida、启动Burp、配置代理、切换App效率太低。我用Python写了轻量级胶水脚本frida-burp-launcher.pyimport subprocess, time, sys # 启动Frida server subprocess.Popen([adb, shell, /data/local/tmp/frida-server, ]) time.sleep(2) # 启动Frida脚本 frida_proc subprocess.Popen([frida, -U, -f, sys.argv[1], -l, ssl.js]) # 启动Burp subprocess.Popen([burpsuite_pro, --project-filebank.burp]) # 自动配置Android代理 subprocess.run([adb, shell, settings, put, global, http_proxy, 127.0.0.1:8080]) print(✅ Frida Burp launched. Press CtrlC to stop.) try: frida_proc.wait() except KeyboardInterrupt: frida_proc.terminate() subprocess.run([adb, shell, settings, put, global, http_proxy, ])运行python frida-burp-launcher.py com.bank.app三秒内完成全部环境初始化。这才是生产力。6.3 反制与规避当App开始检测Frida时怎么办高端App如某头部支付App已加入Frida检测检测/proc/self/maps中是否存在frida字符串调用ptrace(PTRACE_TRACEME, ...)自检是否被trace检测/dev/ashmem中Frida的共享内存段。应对策略不是“破解检测”而是“让检测失效”Map隐藏用frida-gadget替代frida-server它以so库形式注入不写入mapsPtrace规避在脚本开头加Process.setExceptionHandler(null)禁用Frida的异常处理让App的ptrace调用不触发Frida钩子内存混淆用frida-compile编译脚本为bundle再用frida-inject注入避免JS源码暴露。这些不是玄学而是真实对抗中打磨出的生存法则。记住安全测试的本质是攻防双方在规则内的智力博弈。你不需要赢在第一步但必须赢在最后一步。我在实际使用中发现最有效的习惯是每次拿到新App先跑一遍frida-trace -U -i check*|verify*|pin*花3分钟看它到底在哪儿校验证书。这比盲目套用脚本高效十倍。Frida的价值从来不是“一键绕过”而是给你一把显微镜让你看清App的每一行安全逻辑。当你能说出“这个App的SSL Pinning是在OkHttpClient.Builder的certificatePinner()里配置的且只固定了公钥哈希”你就已经超越了90%的同行。剩下的只是把这句话变成一行可靠的Frida代码。
