1. 项目概述当抓包工具遇上“隐身”的APP作为一名在移动安全领域摸爬滚打了十来年的老手我处理过太多“抓不到包”的棘手情况。你兴冲冲地打开Burp Suite或Charles配置好代理准备对目标安卓APP进行安全测试或协议分析结果却发现APP要么直接网络错误要么数据流空空如也请求根本发不出去。这背后就是APP内置的各种抓包检测与防护机制在起作用。它们像给APP套上了一层“隐身衣”让传统的代理抓包手段瞬间失效。今天要聊的就是如何用Frida这件“神器”亲手把这层“隐身衣”给扒下来。Frida是一个动态代码插桩框架简单说它能在APP运行时像做手术一样精准地修改其内存和逻辑。我们这次实战的核心目标非常明确针对APP用于检测代理、证书的5种最常见“姿势”逐一找到其检测逻辑的关键点并用Frida脚本进行“绕过”或“欺骗”。我会提供经过实战检验的代码模板你拿到手稍作修改就能用。无论你是从事安全测试、逆向分析还是单纯对APP通信协议感到好奇的开发者掌握这些方法都能让你在分析道路上扫清一大障碍。2. 核心思路与工具准备为什么是Frida在开始“手术”之前我们必须先理解“病因”。APP阻止抓包本质上是检测到了运行环境与正常用户环境的不同。其主要“侦查”手段无外乎以下几类检测系统是否设置了代理、检测是否安装了“额外”的证书即我们抓包工具安装的CA证书、检测证书链是否被“劫持”SSL Pinning。传统的对抗方法比如尝试用Postern等工具做全局代理转发、或者寻找低版本无需证书的APP都越来越乏力因为防护手段在持续升级。这时Frida的优势就凸显出来了。与静态反编译修改Smali/字节码再重打包相比Frida的动态Hook挂钩方式有三大不可替代的优势无需重打包与签名直接附加到运行中的进程进行修改避免了繁琐且易出错的脱壳、修改、回编译、签名对齐流程。实时交互与快速迭代脚本可以随时修改、重新加载调试和验证逻辑的效率极高。精准打击可以精确到某个类、某个方法的某一行进行逻辑修改或信息打印实现“指哪打哪”。2.1 基础环境搭建清单工欲善其事必先利其器。以下是经过无数次环境配置后总结的最稳当的清单测试设备一台已经Root的安卓手机或模拟器。推荐使用官方Android Studio自带的x86/x86_64镜像模拟器性能好快照功能方便或者实体机如Google Pixel系列对Root支持友好。注意高版本安卓特别是Android 7.0以上对证书安装和系统安全性有更严格限制建议从Android 9或10开始练习其机制具有代表性。Frida环境PC端通过Python的pip安装pip install frida-tools。这会将frida、frida-ps、frida-ls-devices等命令行工具一并安装。设备端需要安装与PC端frida-tools版本匹配的frida-server。去Frida官网的GitHub Releases页面根据设备CPU架构通常是arm64下载对应的frida-server-xx.x.x-android-arm64.xz解压后得到二进制文件通过adb push推送到设备/data/local/tmp/目录并赋予可执行权限chmod 755 frida-server然后在后台运行./frida-server 。抓包工具Burp Suite Professional/Community版或Charles。确保其代理已开启如Burp默认为127.0.0.1:8080并且已将抓包工具的CA证书安装到安卓设备的系统证书目录/system/etc/security/cacerts/或用户证书目录对于Android 7.0系统级Hook往往需要将证书移至系统目录。安装到系统目录需要Root权限。逆向辅助工具Jadx-GUI或Ghidra。用于静态分析APP快速定位我们感兴趣的类和方法名为编写Frida Hook脚本提供“坐标”。注意frida-server的版本务必与PC端frida和frida-tools的版本保持一致或尽可能接近否则在连接时会出现协议错误。这是新手最常踩的坑之一。2.2 核心思路拆解我们的作战计划是“侦察-定位-打击”侦察通过静态分析Jadx或动态探索Frida的枚举API找到APP中可能负责网络库初始化、代理检查、证书验证的相关类和方法。常见嫌疑对象包括OkHttpClient.Builder、X509TrustManager、HostnameVerifier、Proxy、System.getProperty等。定位编写试探性的Frida脚本Hook这些可疑方法打印出它们的调用栈、参数和返回值观察在开启抓包和关闭抓包时这些方法的执行逻辑有何不同。从而精确定位到触发“检测”的关键代码行。打击针对定位到的关键方法编写最终的Hook脚本。我们的目标不是“修复”或“删除”代码而是“欺骗”——让方法返回我们期望的值如返回一个空的代理列表、让证书验证总是成功或者直接阻止某些检测函数的执行。3. 姿势一Hook系统属性与Proxy类检测这是最基础、也最常见的一种检测方式。APP会读取系统的某些属性或者检查Proxy类的相关方法来判断是否设置了代理。3.1 检测原理分析APP通常会通过以下方式检测代理读取系统属性System.getProperty(http.proxyHost)、System.getProperty(https.proxyHost)。如果这些属性不为空则说明设置了代理。使用ProxySelectorJava标准库中的ProxySelector会尝试获取系统默认的代理配置。APP可能通过ProxySelector.getDefault().select(...)来获取代理列表。网络库内置检测如OkHttp的OkHttpClient.Builder在构建时如果没有显式设置proxy(Proxy.NO_PROXY)它可能会使用系统默认代理。3.2 Frida Hook实战与代码模板我们的策略是Hook这些读取属性的方法或Proxy选择逻辑让它们返回“空”或“无代理”的结果。Java.perform(function () { console.log([*] 开始Hook系统代理检测...); // 1. Hook System.getProperty 针对代理相关属性返回null var System Java.use(java.lang.System); System.getProperty.overload(java.lang.String).implementation function (key) { var result this.getProperty(key); // 关键拦截代理相关属性的查询 if (key (key.indexOf(proxy) ! -1 || key.indexOf(PROXY) ! -1)) { console.log([] 拦截 System.getProperty( key ) 原值: result 返回: null); return null; // 或者返回空字符串 } return result; }; // 2. Hook ProxySelector.getDefault().select 返回空列表表示无代理 var ProxySelector Java.use(java.net.ProxySelector); var defaultSelector ProxySelector.getDefault(); if (defaultSelector) { // 注意这里需要获取原始类的引用并替换其select方法 var OriginalProxySelectorClass Java.use(defaultSelector.$className); OriginalProxySelectorClass.select.overload(java.net.URI).implementation function (uri) { console.log([] 拦截 ProxySelector.select() for URI: uri); // 返回一个空的Java List表示没有可用的代理 var ArrayList Java.use(java.util.ArrayList); var emptyList ArrayList.$new(); return emptyList; }; } // 3. Hook OkHttpClient.Builder 的 proxy 方法如果存在 try { var OkHttpClient_Builder Java.use(okhttp3.OkHttpClient$Builder); OkHttpClient_Builder.proxy.overload(java.net.Proxy).implementation function (proxy) { console.log([] 拦截 OkHttpClient.Builder.proxy() 强制设置为 Proxy.NO_PROXY); var Proxy Java.use(java.net.Proxy); return this.proxy(Proxy.NO_PROXY); }; } catch (e) { console.log([-] 未找到OkHttpClient.Builder 可能未使用OkHttp或版本不同: e); } console.log([*] 系统代理检测Hook完成。); });3.3 实操心得与注意事项顺序很重要有时APP会有多层检测先检查系统属性再检查ProxySelector。我们的Hook脚本最好能覆盖所有层面。注意OverloadSystem.getProperty有多个重载方法我们通常Hook的是String参数的那个。使用overload关键字可以精确指定。兼容性处理像HookOkHttpClient.Builder的代码需要用try-catch包裹因为不是所有APP都使用OkHttp或者使用的版本可能不同。脚本应具备一定的容错能力。验证方法注入脚本后可以打开APP的网络设置页面如果有或者触发一个网络请求同时观察Frida的控制台输出看我们的Hook是否被触发。4. 姿势二绕过证书绑定SSL Pinning这是对抗抓包最核心、也是最复杂的一环。SSL Pinning证书绑定是指APP在代码中“硬编码”了它信任的服务端证书或公钥哈希。当建立TLS连接时APP会将自己内置的证书与服务器返回的证书进行比对如果不匹配比如我们的抓包工具返回的是Burp/Charles的证书就直接断开连接。4.1 SSL Pinning的常见实现方式网络库层PinningOkHttp、Retrofit等库提供了便捷的证书绑定API开发者可以配置CertificatePinner。自定义TrustManagerAPP实现自己的X509TrustManager接口在checkServerTrusted方法中实现自定义的验证逻辑包括比对证书。自定义HostnameVerifier实现HostnameVerifier接口在verify方法中严格校验主机名。Native层Pinning将验证逻辑写在C/C层JNI/NDK增加逆向难度。4.2 Frida Hook方案与代码模板我们的目标是“瓦解”这些验证逻辑。Java.perform(function () { console.log([*] 开始Hook SSL Pinning相关组件...); // 1. 万能钥匙Hook X509TrustManager 让所有证书都通过验证 var X509TrustManager Java.use(javax.net.ssl.X509TrustManager); // 注意这里需要找到APP实际使用的TrustManager类可能是自定义的。以下是一种通用但可能不完美的尝试。 // 更好的方法是通过枚举或静态分析找到具体类名。 Java.choose(javax.net.ssl.X509TrustManager, { onMatch: function (instance) { console.log([] 发现 X509TrustManager 实例: instance); // Hook checkServerTrusted 方法 var clazz Java.use(instance.$className); clazz.checkServerTrusted.overload([Ljava.security.cert.X509Certificate;, java.lang.String).implementation function (chain, authType) { console.log([] 绕过 X509TrustManager.checkServerTrusted, authType: authType); // 什么都不做直接通过或者打印一下证书信息 for (var i 0; i chain.length; i) { console.log( Cert[ i ]: chain[i].getSubjectDN()); } return; }; clazz.checkClientTrusted clazz.checkClientTrusted.overload([Ljava.security.cert.X509Certificate;, java.lang.String).implementation function (chain, authType) { console.log([] 绕过 X509TrustManager.checkClientTrusted); return; }; clazz.getAcceptedIssuers clazz.getAcceptedIssuers.overload().implementation function () { console.log([] 绕过 X509TrustManager.getAcceptedIssuers); return []; }; }, onComplete: function () { console.log([*] X509TrustManager 实例搜索完成。); } }); // 2. Hook HostnameVerifier 让所有主机名都验证通过 var HostnameVerifier Java.use(javax.net.ssl.HostnameVerifier); HostnameVerifier.verify.overload(java.lang.String, javax.net.ssl.SSLSession).implementation function (hostname, session) { console.log([] 绕过 HostnameVerifier.verify for hostname: hostname); return true; // 总是返回true }; // 3. Hook OkHttp的CertificatePinner如果使用 try { var CertificatePinner Java.use(okhttp3.CertificatePinner); CertificatePinner.check.overload(java.lang.String, java.util.List).implementation function (hostname, pins) { console.log([] 绕过 OkHttp CertificatePinner.check for: hostname); // 直接跳过检查不抛异常 return; }; // 或者Hook其构造方法使其不添加任何Pin规则 CertificatePinner.$init.overload(okhttp3.CertificatePinner$Builder).implementation function (builder) { console.log([] 拦截 CertificatePinner 初始化 返回一个空的无pinning的实例); // 调用原始构造但传入一个空的Builder更直接的方法是替换整个对象。 // 这里提供一个思路可以尝试在OkHttpClient.Builder构建时替换其certificatePinner。 }; } catch (e) { console.log([-] 未找到OkHttp CertificatePinner: e); } console.log([*] SSL Pinning Hook完成。); });4.3 高级技巧定位自定义TrustManager上面的代码通过Java.choose来寻找X509TrustManager实例这有时可能不够精确或找不到。更可靠的方法是静态分析用Jadx搜索checkServerTrusted方法。查看哪些类实现了X509TrustManager接口。找到在SSLContext.init或网络库初始化时被使用的那个具体类。在Frida脚本中直接Hook这个具体的类名。// 假设通过静态分析发现APP使用了一个叫com.example.app.CustomTrustManager的类 var CustomTrustManager Java.use(com.example.app.CustomTrustManager); CustomTrustManager.checkServerTrusted.overload([Ljava.security.cert.X509Certificate;, java.lang.String).implementation function (chain, authType) { console.log([] 绕过 CustomTrustManager.checkServerTrusted); return; // 静默通过 };5. 姿势三对抗证书链完整性校验除了SSL Pinning一些更严格的APP会校验整个证书链的完整性或者检测证书是否由系统已知的CA签发而我们的Burp证书是用户安装的。它们可能通过TrustManagerFactory或KeyStore相关的API来实现。5.1 检测原理APP可能加载一个预设的、仅包含官方CA的密钥库KeyStore然后基于此生成TrustManager。这样非系统预设的CA证书如Burp证书将不被信任。5.2 Frida Hook策略我们的策略是Hook密钥库的加载过程或者直接替换掉整个TrustManagerFactory的初始化。Java.perform(function () { console.log([*] 开始Hook证书链与KeyStore相关逻辑...); // 1. Hook KeyStore的load方法 尝试阻止其加载特定文件或加载一个空的KeyStore var KeyStore Java.use(java.security.KeyStore); KeyStore.load.overload(java.io.InputStream, [C).implementation function (stream, password) { console.log([] 拦截 KeyStore.load()); // 我们可以选择 // A. 让加载失败不这可能导致APP崩溃。 // B. 调用原方法但之后清空它比较复杂。 // C. 更常见的做法是Hook TrustManagerFactory.init见下文。 return this.load(stream, password); // 暂时先正常执行 }; // 2. Hook TrustManagerFactory的init方法 这是更关键的入口 var TrustManagerFactory Java.use(javax.net.ssl.TrustManagerFactory); TrustManagerFactory.init.overload(java.security.KeyStore).implementation function (ks) { console.log([] 拦截 TrustManagerFactory.init(KeyStore)); // 关键传入一个null或空的KeyStore 这样工厂会使用默认的系统信任库。 // 但我们的Burp证书如果已安装到系统目录就会被信任。 // 然而如果APP就是想用自定义KeyStore排除系统CA我们这样做可能破坏其逻辑。 // 另一种思路获取默认的系统KeyStore传给它。 try { var defaultKs KeyStore.getInstance(KeyStore.getDefaultType()); defaultKs.load(null, null); // 加载默认的系统KeyStore console.log( - 替换为系统默认KeyStore); return this.init(defaultKs); } catch (e) { console.log( - 替换失败 使用原始KeyStore: e); return this.init(ks); } }; // 3. Hook SSLContext的init方法 直接替换TrustManager var SSLContext Java.use(javax.net.ssl.SSLContext); SSLContext.init.overload([Ljavax.net.ssl.KeyManager;, [Ljavax.net.ssl.TrustManager;, java.security.SecureRandom).implementation function (keyManagers, trustManagers, secureRandom) { console.log([] 拦截 SSLContext.init()); // 创建一个“信任所有”的TrustManager数组 var TrustAllManager Java.registerClass({ name: com.bypass.TrustAllManager, implements: [X509TrustManager], methods: { checkClientTrusted: function (chain, authType) { }, checkServerTrusted: function (chain, authType) { console.log( TrustAllManager: Accepting server cert for: (chain chain[0] ? chain[0].getSubjectDN() : unknown)); }, getAcceptedIssuers: function () { return []; } } }); var dummyTrustManagers [TrustAllManager.$new()]; console.log( - 替换为自定义的TrustAllManager); return this.init(keyManagers, dummyTrustManagers, secureRandom); }; console.log([*] 证书链完整性校验Hook完成。); });5.4 实操心得风险较高直接替换SSLContext.init或TrustManagerFactory.init是比较“暴力”的方法可能会影响APP其他需要严格SSL校验的功能如支付需谨慎测试。顺序问题这些Hook需要在APP网络库初始化之前执行。确保Frida脚本在APP启动早期就注入例如使用frida -U -f com.example.app --no-pause -l script.js在启动时注入。组合使用姿势二和姿势三经常需要组合使用因为APP可能同时采用多种证书校验机制。6. 姿势四应对基于网络状态/连接属性的检测有些APP不直接检测代理而是检测当前活跃网络的属性例如判断网络是否是通过VPN或代理连接NetworkInfo/ConnectivityManager或者检查LinkProperties。6.1 检测原理在Android中可以通过ConnectivityManager.getActiveNetwork()获取当前网络然后通过NetworkCapabilities和LinkProperties来查询网络详细信息。如果LinkProperties中包含了代理相关的ProxyInfo或者NetworkCapabilities表明网络是VPNAPP就可能拒绝在此网络下发送敏感请求。6.2 Frida Hook代码模板Java.perform(function () { console.log([*] 开始Hook网络连接属性检测...); // Hook ConnectivityManager 的相关方法 var ConnectivityManager Java.use(android.net.ConnectivityManager); // 方法1Hook getActiveNetworkInfo (旧APIdeprecated但可能还在用) try { ConnectivityManager.getActiveNetworkInfo.implementation function () { var originalResult this.getActiveNetworkInfo(); if (originalResult) { console.log([] 拦截 getActiveNetworkInfo 类型: originalResult.getTypeName()); // 可以尝试修改返回对象的属性但更简单的是Hook返回后APP调用的方法。 } return originalResult; }; } catch (e) { /* 方法可能不存在 */ } // 方法2Hook getActiveNetwork (新API) 和 getNetworkCapabilities / getLinkProperties try { ConnectivityManager.getActiveNetwork.implementation function () { var originalNetwork this.getActiveNetwork(); console.log([] 拦截 getActiveNetwork); return originalNetwork; // 返回原始网络对象但后续可以Hook对它的查询 }; } catch (e) { /* 方法可能不存在 */ } // 方法3Hook LinkProperties 的 getHttpProxy 方法关键 var LinkProperties Java.use(android.net.LinkProperties); LinkProperties.getHttpProxy.implementation function () { console.log([] 拦截 LinkProperties.getHttpProxy() 返回 null); return null; // 强制返回null告诉APP此网络没有HTTP代理 }; // 方法4Hook NetworkCapabilities 的 hasTransport 或 hasCapability 避免被识别为VPN var NetworkCapabilities Java.use(android.net.NetworkCapabilities); NetworkCapabilities.hasTransport.overload(int).implementation function (transportType) { var result this.hasTransport(transportType); // TRANSPORT_VPN 的值通常是 17 (Android 10) 或 4 (旧版本需要查常量)。这里是一个示例。 // 更稳妥的做法是获取常量值var TRANSPORT_VPN Java.use(android.net.NetworkCapabilities).TRANSPORT_VPN.value; if (transportType 17 || transportType 4) { // 假设是VPN类型 console.log([] 拦截 NetworkCapabilities.hasTransport(VPN) 原结果: result 返回 false); return false; } return result; }; console.log([*] 网络连接属性检测Hook完成。); });6.3 注意事项版本适配Android网络API变化较大不同版本尤其是Android 5.0, 7.0, 10.0的检测方式可能不同。需要根据目标APP的targetSdkVersion来调整Hook策略。常量值像TRANSPORT_VPN这样的常量其整数值可能随版本变化。最准确的方式是在Hook脚本中动态获取Java.use(android.net.NetworkCapabilities).TRANSPORT_VPN.value。7. 姿势五处理Native层JNI/NDK检测最高级的防护会将关键检测逻辑下沉到Native层C/C通过JNI调用。这增加了逆向分析的门槛因为需要分析so库文件。7.1 检测原理APP的Java代码通过System.loadLibrary加载so库并调用其中的native方法。这些方法可能执行检测frida-server进程或端口27042。检测/proc/self/maps中是否包含frida-agent等字符串。执行更底层的网络套接字操作绕过Java层的代理设置。实现自己的TLS逻辑如BoringSSL进行证书绑定。7.2 Frida Hook Native函数Frida同样可以Hook Native层的函数这需要一些C/C的基础。Java.perform(function () { console.log([*] 开始处理Native层检测...); // 首先确保APP已经加载了目标so库 // 我们可以Hook System.loadLibrary var System Java.use(java.lang.System); System.loadLibrary.overload(java.lang.String).implementation function (libname) { console.log([] Java层加载Native库: libname); var result this.loadLibrary(libname); // 库加载后我们可以开始Hook其中的Native函数 if (libname.indexOf(security) ! -1 || libname.indexOf(net) ! -1) { // 假设库名包含关键词 setTimeout(hookNativeFunctions, 500); // 延迟执行确保库完全加载 } return result; }; // 也可以直接枚举已加载的模块 Process.enumerateModules({ onMatch: function (module) { console.log(模块: module.name 基址: module.base); // 如果发现可疑模块如libnetguard.so, libssl.so等可以针对性Hook }, onComplete: function () { console.log([*] 模块枚举完成。); } }); }); // 单独的Native Hook函数 function hookNativeFunctions() { console.log([*] 尝试Hook Native函数...); // 示例1Hook libc 的 getaddrinfo 函数这是域名解析的核心函数有些检测会在这里做手脚。 var libc Module.findBaseAddress(libc.so); if (libc) { // 注意函数签名和偏移量因Android版本和设备架构(arm/arm64/x86)而异。这里是一个示例。 // 在实际操作中你需要用IDA/Ghidra反编译so库找到目标函数的偏移量或符号。 var getaddrinfo Module.findExportByName(libc.so, getaddrinfo); if (getaddrinfo) { Interceptor.attach(getaddrinfo, { onEnter: function (args) { // args[0]是node, args[1]是service, args[2]是hints, args[3]是res var hostname Memory.readCString(args[0]); console.log([Native] getaddrinfo called for hostname: hostname); // 可以在这里修改hostname或者记录信息 }, onLeave: function (retval) { // console.log([Native] getaddrinfo returned: retval); } }); console.log([] Hook libc.getaddrinfo 成功); } } // 示例2Hook一个自定义的JNI函数假设我们知道它的符号 // 通过静态分析so库发现一个函数 Java_com_example_app_NativeHelper_checkProxy var targetSymbol Java_com_example_app_NativeHelper_checkProxy; var targetAddress Module.findExportByName(null, targetSymbol); // 在已加载的所有模块中查找 if (targetAddress) { Interceptor.attach(targetAddress, { onEnter: function (args) { console.log([Native] 进入自定义检测函数: targetSymbol); // 这个函数可能返回一个布尔值或整数表示是否检测到代理。 // 我们可以修改其返回值。 }, onLeave: function (retval) { console.log([Native] 函数原始返回值: retval); // 强制返回0假或1真取决于函数语义。假设返回0表示安全。 retval.replace(ptr(0)); console.log([] 修改返回值为 0 (安全)); } }); console.log([] Hook targetSymbol 成功); } else { console.log([-] 未找到符号: targetSymbol); } // 示例3对抗Frida检测如果Native代码在检测Frida // 常见的检测扫描maps文件查找frida-agent。我们可以Hook文件读取相关函数。 var fopen Module.findExportByName(libc.so, fopen); if (fopen) { Interceptor.attach(fopen, { onEnter: function (args) { var filename Memory.readCString(args[0]); var mode Memory.readCString(args[1]); if (filename filename.indexOf(/proc/self/maps) ! -1) { console.log([Native] 检测到 maps 文件读取: filename); // 可以在这里做手脚但比较复杂。一种思路是Hook后续的fgets/fread过滤掉包含frida的行。 } } }); } }7.3 高级技巧与排查符号剥离发布版的so库经常被剥离符号你找不到像Java_com_example_app_NativeHelper_checkProxy这样清晰的函数名。这时需要通过反汇编工具分析so找到关键函数的偏移地址offset然后通过Module.base.add(offset)来获取函数地址进行Hook。参数与返回值Hook Native函数需要了解其调用约定ARM/ARM64/x86和参数类型。使用Frida的Memory.readCString、Memory.readByteArray等API来读取内存中的数据。动态注册JNI有些JNI函数是动态注册的通过JNIEnv-RegisterNatives其符号名可能不是标准的Java_开头。需要在JNI_OnLoad函数或RegisterNatives调用处下钩子来获取这些函数的地址。8. 实战整合与问题排查在实际对抗中一个成熟的APP往往会同时采用上述多种姿势。因此一个完整的绕过脚本需要将上述多个Hook点整合起来形成一个“组合拳”。8.1 脚本整合策略分模块编写将针对不同检测姿势的代码写成独立的函数或模块如hookProxyDetection(),hookSSLPinning(),hookNativeChecks()。顺序执行在Java.perform的主函数中按顺序调用这些模块。通常先处理Java层的通用代理和SSL Pinning再处理网络属性最后处理Native层。错误处理每个Hook点都用try-catch包裹避免因为某个类或方法不存在导致整个脚本崩溃。日志分级使用console.log输出不同级别的信息如[*]信息[]成功[-]失败/未找到[!]警告便于调试。8.2 常见问题排查实录即使脚本写好了注入后也可能遇到APP崩溃、Hook不生效、网络依然不通等问题。以下是我踩过无数坑后总结的排查清单问题现象可能原因排查思路与解决方案注入后APP立即闪退1. Frida版本不匹配。2. Hook了错误的方法或类导致无限递归或内存访问错误。3. Native Hook触发了反调试。1. 检查frida-server与PC端版本。使用frida --version和adb shell /data/local/tmp/frida-server --version比对。2. 注释掉部分Hook代码采用二分法定位导致崩溃的Hook点。特别注意implementation函数中是否错误地调用了原方法导致循环。3. 尝试先不进行Native Hook只进行Java层Hook看是否稳定。Hook脚本执行无日志输出检测依然生效1. 脚本未成功注入或执行。2. Hook的类名/方法签名不正确。3. 检测逻辑发生在脚本注入之前。1. 在脚本开头加一句console.log(“脚本开始执行”);确认Frida连接和脚本加载正常。2. 使用frida -U -f com.example.app -l script.js --no-pause在APP启动时注入。确保在检测逻辑初始化前执行Hook。3. 使用Java.available()检查Java运行时是否就绪。使用Java.enumerateLoadedClasses()或Frida的-D参数打印所有类确认目标类已加载。部分网络请求通了部分还是失败1. APP使用了多个网络库或连接方式如HttpURLConnection,OkHttp,WebView,Socket直连。2. Native层实现了独立的网络栈。3. 证书绑定针对不同域名有不同的策略。1. 检查失败请求的库。Hook更底层的类如java.net.Socket、javax.net.ssl.SSLSocketFactory。2. 对libssl.so、libcrypto.so等系统库的SSL_read/SSL_write或SSL_CTX_new等函数进行Hook观察流量。3. 分析证书绑定的代码看是否是“动态Pinning”从服务器获取pin列表需要Hook其获取和更新的逻辑。Frida自身被检测到APP有反Frida机制如检测frida-server进程、端口、内存特征、文件特征等。1. 重命名frida-server二进制文件并运行。2. 修改Frida默认端口frida-server -l 0.0.0.0:8080。3. 使用Frida的D-Bus协议而非默认的listen模式更复杂。4. 使用objection等基于Frida的工具它可能有一些反反制措施。5. 在非Root环境下尝试使用frida-gadget注入但难度较高。8.3 一个综合性的脚本启动命令# 在APP启动时注入并等待--no-pause同时允许子进程派生--enable-child-gating这对于多进程APP有用 frida -U -f com.example.targetapp --no-pause --enable-child-gating -l bypass_all.js # 附加到已运行的APP进程 frida -U com.example.targetapp -l bypass_all.js # 开启调试输出可以看到更详细的Frida内部通信和错误信息 frida -U com.example.targetapp -l bypass_all.js -D绕过抓包检测是一场持续的“攻防战”。今天有效的技术明天可能因为APP更新或系统升级而失效。核心不在于记住所有脚本而在于理解其原理和Frida这个工具的强大能力——动态修改运行时。掌握了“侦察-定位-打击”这个基本方法论你就能应对层出不穷的新防护手段。最后所有的技术都应用于合法授权的安全测试与学习研究这是从业者不可逾越的底线。
Frida实战：绕过安卓APP抓包检测的5种核心姿势
发布时间：2026/7/4 16:31:45
1. 项目概述当抓包工具遇上“隐身”的APP作为一名在移动安全领域摸爬滚打了十来年的老手我处理过太多“抓不到包”的棘手情况。你兴冲冲地打开Burp Suite或Charles配置好代理准备对目标安卓APP进行安全测试或协议分析结果却发现APP要么直接网络错误要么数据流空空如也请求根本发不出去。这背后就是APP内置的各种抓包检测与防护机制在起作用。它们像给APP套上了一层“隐身衣”让传统的代理抓包手段瞬间失效。今天要聊的就是如何用Frida这件“神器”亲手把这层“隐身衣”给扒下来。Frida是一个动态代码插桩框架简单说它能在APP运行时像做手术一样精准地修改其内存和逻辑。我们这次实战的核心目标非常明确针对APP用于检测代理、证书的5种最常见“姿势”逐一找到其检测逻辑的关键点并用Frida脚本进行“绕过”或“欺骗”。我会提供经过实战检验的代码模板你拿到手稍作修改就能用。无论你是从事安全测试、逆向分析还是单纯对APP通信协议感到好奇的开发者掌握这些方法都能让你在分析道路上扫清一大障碍。2. 核心思路与工具准备为什么是Frida在开始“手术”之前我们必须先理解“病因”。APP阻止抓包本质上是检测到了运行环境与正常用户环境的不同。其主要“侦查”手段无外乎以下几类检测系统是否设置了代理、检测是否安装了“额外”的证书即我们抓包工具安装的CA证书、检测证书链是否被“劫持”SSL Pinning。传统的对抗方法比如尝试用Postern等工具做全局代理转发、或者寻找低版本无需证书的APP都越来越乏力因为防护手段在持续升级。这时Frida的优势就凸显出来了。与静态反编译修改Smali/字节码再重打包相比Frida的动态Hook挂钩方式有三大不可替代的优势无需重打包与签名直接附加到运行中的进程进行修改避免了繁琐且易出错的脱壳、修改、回编译、签名对齐流程。实时交互与快速迭代脚本可以随时修改、重新加载调试和验证逻辑的效率极高。精准打击可以精确到某个类、某个方法的某一行进行逻辑修改或信息打印实现“指哪打哪”。2.1 基础环境搭建清单工欲善其事必先利其器。以下是经过无数次环境配置后总结的最稳当的清单测试设备一台已经Root的安卓手机或模拟器。推荐使用官方Android Studio自带的x86/x86_64镜像模拟器性能好快照功能方便或者实体机如Google Pixel系列对Root支持友好。注意高版本安卓特别是Android 7.0以上对证书安装和系统安全性有更严格限制建议从Android 9或10开始练习其机制具有代表性。Frida环境PC端通过Python的pip安装pip install frida-tools。这会将frida、frida-ps、frida-ls-devices等命令行工具一并安装。设备端需要安装与PC端frida-tools版本匹配的frida-server。去Frida官网的GitHub Releases页面根据设备CPU架构通常是arm64下载对应的frida-server-xx.x.x-android-arm64.xz解压后得到二进制文件通过adb push推送到设备/data/local/tmp/目录并赋予可执行权限chmod 755 frida-server然后在后台运行./frida-server 。抓包工具Burp Suite Professional/Community版或Charles。确保其代理已开启如Burp默认为127.0.0.1:8080并且已将抓包工具的CA证书安装到安卓设备的系统证书目录/system/etc/security/cacerts/或用户证书目录对于Android 7.0系统级Hook往往需要将证书移至系统目录。安装到系统目录需要Root权限。逆向辅助工具Jadx-GUI或Ghidra。用于静态分析APP快速定位我们感兴趣的类和方法名为编写Frida Hook脚本提供“坐标”。注意frida-server的版本务必与PC端frida和frida-tools的版本保持一致或尽可能接近否则在连接时会出现协议错误。这是新手最常踩的坑之一。2.2 核心思路拆解我们的作战计划是“侦察-定位-打击”侦察通过静态分析Jadx或动态探索Frida的枚举API找到APP中可能负责网络库初始化、代理检查、证书验证的相关类和方法。常见嫌疑对象包括OkHttpClient.Builder、X509TrustManager、HostnameVerifier、Proxy、System.getProperty等。定位编写试探性的Frida脚本Hook这些可疑方法打印出它们的调用栈、参数和返回值观察在开启抓包和关闭抓包时这些方法的执行逻辑有何不同。从而精确定位到触发“检测”的关键代码行。打击针对定位到的关键方法编写最终的Hook脚本。我们的目标不是“修复”或“删除”代码而是“欺骗”——让方法返回我们期望的值如返回一个空的代理列表、让证书验证总是成功或者直接阻止某些检测函数的执行。3. 姿势一Hook系统属性与Proxy类检测这是最基础、也最常见的一种检测方式。APP会读取系统的某些属性或者检查Proxy类的相关方法来判断是否设置了代理。3.1 检测原理分析APP通常会通过以下方式检测代理读取系统属性System.getProperty(http.proxyHost)、System.getProperty(https.proxyHost)。如果这些属性不为空则说明设置了代理。使用ProxySelectorJava标准库中的ProxySelector会尝试获取系统默认的代理配置。APP可能通过ProxySelector.getDefault().select(...)来获取代理列表。网络库内置检测如OkHttp的OkHttpClient.Builder在构建时如果没有显式设置proxy(Proxy.NO_PROXY)它可能会使用系统默认代理。3.2 Frida Hook实战与代码模板我们的策略是Hook这些读取属性的方法或Proxy选择逻辑让它们返回“空”或“无代理”的结果。Java.perform(function () { console.log([*] 开始Hook系统代理检测...); // 1. Hook System.getProperty 针对代理相关属性返回null var System Java.use(java.lang.System); System.getProperty.overload(java.lang.String).implementation function (key) { var result this.getProperty(key); // 关键拦截代理相关属性的查询 if (key (key.indexOf(proxy) ! -1 || key.indexOf(PROXY) ! -1)) { console.log([] 拦截 System.getProperty( key ) 原值: result 返回: null); return null; // 或者返回空字符串 } return result; }; // 2. Hook ProxySelector.getDefault().select 返回空列表表示无代理 var ProxySelector Java.use(java.net.ProxySelector); var defaultSelector ProxySelector.getDefault(); if (defaultSelector) { // 注意这里需要获取原始类的引用并替换其select方法 var OriginalProxySelectorClass Java.use(defaultSelector.$className); OriginalProxySelectorClass.select.overload(java.net.URI).implementation function (uri) { console.log([] 拦截 ProxySelector.select() for URI: uri); // 返回一个空的Java List表示没有可用的代理 var ArrayList Java.use(java.util.ArrayList); var emptyList ArrayList.$new(); return emptyList; }; } // 3. Hook OkHttpClient.Builder 的 proxy 方法如果存在 try { var OkHttpClient_Builder Java.use(okhttp3.OkHttpClient$Builder); OkHttpClient_Builder.proxy.overload(java.net.Proxy).implementation function (proxy) { console.log([] 拦截 OkHttpClient.Builder.proxy() 强制设置为 Proxy.NO_PROXY); var Proxy Java.use(java.net.Proxy); return this.proxy(Proxy.NO_PROXY); }; } catch (e) { console.log([-] 未找到OkHttpClient.Builder 可能未使用OkHttp或版本不同: e); } console.log([*] 系统代理检测Hook完成。); });3.3 实操心得与注意事项顺序很重要有时APP会有多层检测先检查系统属性再检查ProxySelector。我们的Hook脚本最好能覆盖所有层面。注意OverloadSystem.getProperty有多个重载方法我们通常Hook的是String参数的那个。使用overload关键字可以精确指定。兼容性处理像HookOkHttpClient.Builder的代码需要用try-catch包裹因为不是所有APP都使用OkHttp或者使用的版本可能不同。脚本应具备一定的容错能力。验证方法注入脚本后可以打开APP的网络设置页面如果有或者触发一个网络请求同时观察Frida的控制台输出看我们的Hook是否被触发。4. 姿势二绕过证书绑定SSL Pinning这是对抗抓包最核心、也是最复杂的一环。SSL Pinning证书绑定是指APP在代码中“硬编码”了它信任的服务端证书或公钥哈希。当建立TLS连接时APP会将自己内置的证书与服务器返回的证书进行比对如果不匹配比如我们的抓包工具返回的是Burp/Charles的证书就直接断开连接。4.1 SSL Pinning的常见实现方式网络库层PinningOkHttp、Retrofit等库提供了便捷的证书绑定API开发者可以配置CertificatePinner。自定义TrustManagerAPP实现自己的X509TrustManager接口在checkServerTrusted方法中实现自定义的验证逻辑包括比对证书。自定义HostnameVerifier实现HostnameVerifier接口在verify方法中严格校验主机名。Native层Pinning将验证逻辑写在C/C层JNI/NDK增加逆向难度。4.2 Frida Hook方案与代码模板我们的目标是“瓦解”这些验证逻辑。Java.perform(function () { console.log([*] 开始Hook SSL Pinning相关组件...); // 1. 万能钥匙Hook X509TrustManager 让所有证书都通过验证 var X509TrustManager Java.use(javax.net.ssl.X509TrustManager); // 注意这里需要找到APP实际使用的TrustManager类可能是自定义的。以下是一种通用但可能不完美的尝试。 // 更好的方法是通过枚举或静态分析找到具体类名。 Java.choose(javax.net.ssl.X509TrustManager, { onMatch: function (instance) { console.log([] 发现 X509TrustManager 实例: instance); // Hook checkServerTrusted 方法 var clazz Java.use(instance.$className); clazz.checkServerTrusted.overload([Ljava.security.cert.X509Certificate;, java.lang.String).implementation function (chain, authType) { console.log([] 绕过 X509TrustManager.checkServerTrusted, authType: authType); // 什么都不做直接通过或者打印一下证书信息 for (var i 0; i chain.length; i) { console.log( Cert[ i ]: chain[i].getSubjectDN()); } return; }; clazz.checkClientTrusted clazz.checkClientTrusted.overload([Ljava.security.cert.X509Certificate;, java.lang.String).implementation function (chain, authType) { console.log([] 绕过 X509TrustManager.checkClientTrusted); return; }; clazz.getAcceptedIssuers clazz.getAcceptedIssuers.overload().implementation function () { console.log([] 绕过 X509TrustManager.getAcceptedIssuers); return []; }; }, onComplete: function () { console.log([*] X509TrustManager 实例搜索完成。); } }); // 2. Hook HostnameVerifier 让所有主机名都验证通过 var HostnameVerifier Java.use(javax.net.ssl.HostnameVerifier); HostnameVerifier.verify.overload(java.lang.String, javax.net.ssl.SSLSession).implementation function (hostname, session) { console.log([] 绕过 HostnameVerifier.verify for hostname: hostname); return true; // 总是返回true }; // 3. Hook OkHttp的CertificatePinner如果使用 try { var CertificatePinner Java.use(okhttp3.CertificatePinner); CertificatePinner.check.overload(java.lang.String, java.util.List).implementation function (hostname, pins) { console.log([] 绕过 OkHttp CertificatePinner.check for: hostname); // 直接跳过检查不抛异常 return; }; // 或者Hook其构造方法使其不添加任何Pin规则 CertificatePinner.$init.overload(okhttp3.CertificatePinner$Builder).implementation function (builder) { console.log([] 拦截 CertificatePinner 初始化 返回一个空的无pinning的实例); // 调用原始构造但传入一个空的Builder更直接的方法是替换整个对象。 // 这里提供一个思路可以尝试在OkHttpClient.Builder构建时替换其certificatePinner。 }; } catch (e) { console.log([-] 未找到OkHttp CertificatePinner: e); } console.log([*] SSL Pinning Hook完成。); });4.3 高级技巧定位自定义TrustManager上面的代码通过Java.choose来寻找X509TrustManager实例这有时可能不够精确或找不到。更可靠的方法是静态分析用Jadx搜索checkServerTrusted方法。查看哪些类实现了X509TrustManager接口。找到在SSLContext.init或网络库初始化时被使用的那个具体类。在Frida脚本中直接Hook这个具体的类名。// 假设通过静态分析发现APP使用了一个叫com.example.app.CustomTrustManager的类 var CustomTrustManager Java.use(com.example.app.CustomTrustManager); CustomTrustManager.checkServerTrusted.overload([Ljava.security.cert.X509Certificate;, java.lang.String).implementation function (chain, authType) { console.log([] 绕过 CustomTrustManager.checkServerTrusted); return; // 静默通过 };5. 姿势三对抗证书链完整性校验除了SSL Pinning一些更严格的APP会校验整个证书链的完整性或者检测证书是否由系统已知的CA签发而我们的Burp证书是用户安装的。它们可能通过TrustManagerFactory或KeyStore相关的API来实现。5.1 检测原理APP可能加载一个预设的、仅包含官方CA的密钥库KeyStore然后基于此生成TrustManager。这样非系统预设的CA证书如Burp证书将不被信任。5.2 Frida Hook策略我们的策略是Hook密钥库的加载过程或者直接替换掉整个TrustManagerFactory的初始化。Java.perform(function () { console.log([*] 开始Hook证书链与KeyStore相关逻辑...); // 1. Hook KeyStore的load方法 尝试阻止其加载特定文件或加载一个空的KeyStore var KeyStore Java.use(java.security.KeyStore); KeyStore.load.overload(java.io.InputStream, [C).implementation function (stream, password) { console.log([] 拦截 KeyStore.load()); // 我们可以选择 // A. 让加载失败不这可能导致APP崩溃。 // B. 调用原方法但之后清空它比较复杂。 // C. 更常见的做法是Hook TrustManagerFactory.init见下文。 return this.load(stream, password); // 暂时先正常执行 }; // 2. Hook TrustManagerFactory的init方法 这是更关键的入口 var TrustManagerFactory Java.use(javax.net.ssl.TrustManagerFactory); TrustManagerFactory.init.overload(java.security.KeyStore).implementation function (ks) { console.log([] 拦截 TrustManagerFactory.init(KeyStore)); // 关键传入一个null或空的KeyStore 这样工厂会使用默认的系统信任库。 // 但我们的Burp证书如果已安装到系统目录就会被信任。 // 然而如果APP就是想用自定义KeyStore排除系统CA我们这样做可能破坏其逻辑。 // 另一种思路获取默认的系统KeyStore传给它。 try { var defaultKs KeyStore.getInstance(KeyStore.getDefaultType()); defaultKs.load(null, null); // 加载默认的系统KeyStore console.log( - 替换为系统默认KeyStore); return this.init(defaultKs); } catch (e) { console.log( - 替换失败 使用原始KeyStore: e); return this.init(ks); } }; // 3. Hook SSLContext的init方法 直接替换TrustManager var SSLContext Java.use(javax.net.ssl.SSLContext); SSLContext.init.overload([Ljavax.net.ssl.KeyManager;, [Ljavax.net.ssl.TrustManager;, java.security.SecureRandom).implementation function (keyManagers, trustManagers, secureRandom) { console.log([] 拦截 SSLContext.init()); // 创建一个“信任所有”的TrustManager数组 var TrustAllManager Java.registerClass({ name: com.bypass.TrustAllManager, implements: [X509TrustManager], methods: { checkClientTrusted: function (chain, authType) { }, checkServerTrusted: function (chain, authType) { console.log( TrustAllManager: Accepting server cert for: (chain chain[0] ? chain[0].getSubjectDN() : unknown)); }, getAcceptedIssuers: function () { return []; } } }); var dummyTrustManagers [TrustAllManager.$new()]; console.log( - 替换为自定义的TrustAllManager); return this.init(keyManagers, dummyTrustManagers, secureRandom); }; console.log([*] 证书链完整性校验Hook完成。); });5.4 实操心得风险较高直接替换SSLContext.init或TrustManagerFactory.init是比较“暴力”的方法可能会影响APP其他需要严格SSL校验的功能如支付需谨慎测试。顺序问题这些Hook需要在APP网络库初始化之前执行。确保Frida脚本在APP启动早期就注入例如使用frida -U -f com.example.app --no-pause -l script.js在启动时注入。组合使用姿势二和姿势三经常需要组合使用因为APP可能同时采用多种证书校验机制。6. 姿势四应对基于网络状态/连接属性的检测有些APP不直接检测代理而是检测当前活跃网络的属性例如判断网络是否是通过VPN或代理连接NetworkInfo/ConnectivityManager或者检查LinkProperties。6.1 检测原理在Android中可以通过ConnectivityManager.getActiveNetwork()获取当前网络然后通过NetworkCapabilities和LinkProperties来查询网络详细信息。如果LinkProperties中包含了代理相关的ProxyInfo或者NetworkCapabilities表明网络是VPNAPP就可能拒绝在此网络下发送敏感请求。6.2 Frida Hook代码模板Java.perform(function () { console.log([*] 开始Hook网络连接属性检测...); // Hook ConnectivityManager 的相关方法 var ConnectivityManager Java.use(android.net.ConnectivityManager); // 方法1Hook getActiveNetworkInfo (旧APIdeprecated但可能还在用) try { ConnectivityManager.getActiveNetworkInfo.implementation function () { var originalResult this.getActiveNetworkInfo(); if (originalResult) { console.log([] 拦截 getActiveNetworkInfo 类型: originalResult.getTypeName()); // 可以尝试修改返回对象的属性但更简单的是Hook返回后APP调用的方法。 } return originalResult; }; } catch (e) { /* 方法可能不存在 */ } // 方法2Hook getActiveNetwork (新API) 和 getNetworkCapabilities / getLinkProperties try { ConnectivityManager.getActiveNetwork.implementation function () { var originalNetwork this.getActiveNetwork(); console.log([] 拦截 getActiveNetwork); return originalNetwork; // 返回原始网络对象但后续可以Hook对它的查询 }; } catch (e) { /* 方法可能不存在 */ } // 方法3Hook LinkProperties 的 getHttpProxy 方法关键 var LinkProperties Java.use(android.net.LinkProperties); LinkProperties.getHttpProxy.implementation function () { console.log([] 拦截 LinkProperties.getHttpProxy() 返回 null); return null; // 强制返回null告诉APP此网络没有HTTP代理 }; // 方法4Hook NetworkCapabilities 的 hasTransport 或 hasCapability 避免被识别为VPN var NetworkCapabilities Java.use(android.net.NetworkCapabilities); NetworkCapabilities.hasTransport.overload(int).implementation function (transportType) { var result this.hasTransport(transportType); // TRANSPORT_VPN 的值通常是 17 (Android 10) 或 4 (旧版本需要查常量)。这里是一个示例。 // 更稳妥的做法是获取常量值var TRANSPORT_VPN Java.use(android.net.NetworkCapabilities).TRANSPORT_VPN.value; if (transportType 17 || transportType 4) { // 假设是VPN类型 console.log([] 拦截 NetworkCapabilities.hasTransport(VPN) 原结果: result 返回 false); return false; } return result; }; console.log([*] 网络连接属性检测Hook完成。); });6.3 注意事项版本适配Android网络API变化较大不同版本尤其是Android 5.0, 7.0, 10.0的检测方式可能不同。需要根据目标APP的targetSdkVersion来调整Hook策略。常量值像TRANSPORT_VPN这样的常量其整数值可能随版本变化。最准确的方式是在Hook脚本中动态获取Java.use(android.net.NetworkCapabilities).TRANSPORT_VPN.value。7. 姿势五处理Native层JNI/NDK检测最高级的防护会将关键检测逻辑下沉到Native层C/C通过JNI调用。这增加了逆向分析的门槛因为需要分析so库文件。7.1 检测原理APP的Java代码通过System.loadLibrary加载so库并调用其中的native方法。这些方法可能执行检测frida-server进程或端口27042。检测/proc/self/maps中是否包含frida-agent等字符串。执行更底层的网络套接字操作绕过Java层的代理设置。实现自己的TLS逻辑如BoringSSL进行证书绑定。7.2 Frida Hook Native函数Frida同样可以Hook Native层的函数这需要一些C/C的基础。Java.perform(function () { console.log([*] 开始处理Native层检测...); // 首先确保APP已经加载了目标so库 // 我们可以Hook System.loadLibrary var System Java.use(java.lang.System); System.loadLibrary.overload(java.lang.String).implementation function (libname) { console.log([] Java层加载Native库: libname); var result this.loadLibrary(libname); // 库加载后我们可以开始Hook其中的Native函数 if (libname.indexOf(security) ! -1 || libname.indexOf(net) ! -1) { // 假设库名包含关键词 setTimeout(hookNativeFunctions, 500); // 延迟执行确保库完全加载 } return result; }; // 也可以直接枚举已加载的模块 Process.enumerateModules({ onMatch: function (module) { console.log(模块: module.name 基址: module.base); // 如果发现可疑模块如libnetguard.so, libssl.so等可以针对性Hook }, onComplete: function () { console.log([*] 模块枚举完成。); } }); }); // 单独的Native Hook函数 function hookNativeFunctions() { console.log([*] 尝试Hook Native函数...); // 示例1Hook libc 的 getaddrinfo 函数这是域名解析的核心函数有些检测会在这里做手脚。 var libc Module.findBaseAddress(libc.so); if (libc) { // 注意函数签名和偏移量因Android版本和设备架构(arm/arm64/x86)而异。这里是一个示例。 // 在实际操作中你需要用IDA/Ghidra反编译so库找到目标函数的偏移量或符号。 var getaddrinfo Module.findExportByName(libc.so, getaddrinfo); if (getaddrinfo) { Interceptor.attach(getaddrinfo, { onEnter: function (args) { // args[0]是node, args[1]是service, args[2]是hints, args[3]是res var hostname Memory.readCString(args[0]); console.log([Native] getaddrinfo called for hostname: hostname); // 可以在这里修改hostname或者记录信息 }, onLeave: function (retval) { // console.log([Native] getaddrinfo returned: retval); } }); console.log([] Hook libc.getaddrinfo 成功); } } // 示例2Hook一个自定义的JNI函数假设我们知道它的符号 // 通过静态分析so库发现一个函数 Java_com_example_app_NativeHelper_checkProxy var targetSymbol Java_com_example_app_NativeHelper_checkProxy; var targetAddress Module.findExportByName(null, targetSymbol); // 在已加载的所有模块中查找 if (targetAddress) { Interceptor.attach(targetAddress, { onEnter: function (args) { console.log([Native] 进入自定义检测函数: targetSymbol); // 这个函数可能返回一个布尔值或整数表示是否检测到代理。 // 我们可以修改其返回值。 }, onLeave: function (retval) { console.log([Native] 函数原始返回值: retval); // 强制返回0假或1真取决于函数语义。假设返回0表示安全。 retval.replace(ptr(0)); console.log([] 修改返回值为 0 (安全)); } }); console.log([] Hook targetSymbol 成功); } else { console.log([-] 未找到符号: targetSymbol); } // 示例3对抗Frida检测如果Native代码在检测Frida // 常见的检测扫描maps文件查找frida-agent。我们可以Hook文件读取相关函数。 var fopen Module.findExportByName(libc.so, fopen); if (fopen) { Interceptor.attach(fopen, { onEnter: function (args) { var filename Memory.readCString(args[0]); var mode Memory.readCString(args[1]); if (filename filename.indexOf(/proc/self/maps) ! -1) { console.log([Native] 检测到 maps 文件读取: filename); // 可以在这里做手脚但比较复杂。一种思路是Hook后续的fgets/fread过滤掉包含frida的行。 } } }); } }7.3 高级技巧与排查符号剥离发布版的so库经常被剥离符号你找不到像Java_com_example_app_NativeHelper_checkProxy这样清晰的函数名。这时需要通过反汇编工具分析so找到关键函数的偏移地址offset然后通过Module.base.add(offset)来获取函数地址进行Hook。参数与返回值Hook Native函数需要了解其调用约定ARM/ARM64/x86和参数类型。使用Frida的Memory.readCString、Memory.readByteArray等API来读取内存中的数据。动态注册JNI有些JNI函数是动态注册的通过JNIEnv-RegisterNatives其符号名可能不是标准的Java_开头。需要在JNI_OnLoad函数或RegisterNatives调用处下钩子来获取这些函数的地址。8. 实战整合与问题排查在实际对抗中一个成熟的APP往往会同时采用上述多种姿势。因此一个完整的绕过脚本需要将上述多个Hook点整合起来形成一个“组合拳”。8.1 脚本整合策略分模块编写将针对不同检测姿势的代码写成独立的函数或模块如hookProxyDetection(),hookSSLPinning(),hookNativeChecks()。顺序执行在Java.perform的主函数中按顺序调用这些模块。通常先处理Java层的通用代理和SSL Pinning再处理网络属性最后处理Native层。错误处理每个Hook点都用try-catch包裹避免因为某个类或方法不存在导致整个脚本崩溃。日志分级使用console.log输出不同级别的信息如[*]信息[]成功[-]失败/未找到[!]警告便于调试。8.2 常见问题排查实录即使脚本写好了注入后也可能遇到APP崩溃、Hook不生效、网络依然不通等问题。以下是我踩过无数坑后总结的排查清单问题现象可能原因排查思路与解决方案注入后APP立即闪退1. Frida版本不匹配。2. Hook了错误的方法或类导致无限递归或内存访问错误。3. Native Hook触发了反调试。1. 检查frida-server与PC端版本。使用frida --version和adb shell /data/local/tmp/frida-server --version比对。2. 注释掉部分Hook代码采用二分法定位导致崩溃的Hook点。特别注意implementation函数中是否错误地调用了原方法导致循环。3. 尝试先不进行Native Hook只进行Java层Hook看是否稳定。Hook脚本执行无日志输出检测依然生效1. 脚本未成功注入或执行。2. Hook的类名/方法签名不正确。3. 检测逻辑发生在脚本注入之前。1. 在脚本开头加一句console.log(“脚本开始执行”);确认Frida连接和脚本加载正常。2. 使用frida -U -f com.example.app -l script.js --no-pause在APP启动时注入。确保在检测逻辑初始化前执行Hook。3. 使用Java.available()检查Java运行时是否就绪。使用Java.enumerateLoadedClasses()或Frida的-D参数打印所有类确认目标类已加载。部分网络请求通了部分还是失败1. APP使用了多个网络库或连接方式如HttpURLConnection,OkHttp,WebView,Socket直连。2. Native层实现了独立的网络栈。3. 证书绑定针对不同域名有不同的策略。1. 检查失败请求的库。Hook更底层的类如java.net.Socket、javax.net.ssl.SSLSocketFactory。2. 对libssl.so、libcrypto.so等系统库的SSL_read/SSL_write或SSL_CTX_new等函数进行Hook观察流量。3. 分析证书绑定的代码看是否是“动态Pinning”从服务器获取pin列表需要Hook其获取和更新的逻辑。Frida自身被检测到APP有反Frida机制如检测frida-server进程、端口、内存特征、文件特征等。1. 重命名frida-server二进制文件并运行。2. 修改Frida默认端口frida-server -l 0.0.0.0:8080。3. 使用Frida的D-Bus协议而非默认的listen模式更复杂。4. 使用objection等基于Frida的工具它可能有一些反反制措施。5. 在非Root环境下尝试使用frida-gadget注入但难度较高。8.3 一个综合性的脚本启动命令# 在APP启动时注入并等待--no-pause同时允许子进程派生--enable-child-gating这对于多进程APP有用 frida -U -f com.example.targetapp --no-pause --enable-child-gating -l bypass_all.js # 附加到已运行的APP进程 frida -U com.example.targetapp -l bypass_all.js # 开启调试输出可以看到更详细的Frida内部通信和错误信息 frida -U com.example.targetapp -l bypass_all.js -D绕过抓包检测是一场持续的“攻防战”。今天有效的技术明天可能因为APP更新或系统升级而失效。核心不在于记住所有脚本而在于理解其原理和Frida这个工具的强大能力——动态修改运行时。掌握了“侦察-定位-打击”这个基本方法论你就能应对层出不穷的新防护手段。最后所有的技术都应用于合法授权的安全测试与学习研究这是从业者不可逾越的底线。
![华为OD机试2025C卷-字符串变换最小次数[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率](http://pic.xiahunao.cn/yaotu/华为OD机试2025C卷-字符串变换最小次数[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率)
![华为OD机试2025C卷-内存资源分配[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率](http://pic.xiahunao.cn/yaotu/华为OD机试2025C卷-内存资源分配[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率)
