Frida Hook OkHttp捕获URL与请求头实战指南

1. 为什么Hook OkHttp的URL和请求头是安卓逆向的“第一道门”在真实项目里我见过太多人一上来就猛攻so层、硬啃ART虚拟机机制结果两周过去连个登录接口的明文参数都捞不到。其实绝大多数安卓App的网络通信早已不是靠WebView或原生HttpURLConnection打天下而是统一走OkHttp——它像一条贯穿整个App的主动脉所有业务请求、埋点上报、配置拉取、甚至崩溃日志上传全挤在这条管道里。你不需要破解加密算法也不用逆向JNI逻辑只要在OkHttp这一层轻轻“拧开一个阀门”就能看到原始URL、完整Header、明文RequestBody、甚至响应体里的敏感字段。这不是玄学是工程实践中的确定性路径。这个标题里的“Frida Hook技术”不是噱头而是当前最轻量、最稳定、最贴近开发者视角的动态插桩方案。它不依赖root权限部分场景可免root、不修改APK字节码、不触发常见加固的反调试检测且支持热重载脚本——你改一行JS保存即生效比重打包APK快十倍。而Hook对象锁定为OkHttp是因为它的调用链高度标准化OkHttpClient.newCall(request).enqueue()或.execute()是绝大多数App的统一入口Request.Builder构造过程暴露了URL和Header的原始拼接逻辑Interceptor链则提供了从发起前到响应后的全生命周期观测点。这三点构成了Hook的黄金三角。关键词“URL”和“请求头”看似简单实则承载着关键业务语义。URL里藏着接口路由、版本标识、设备指纹参数如?v3.2.1device_idxxxHeader里塞着认证凭证Authorization: Bearer xxx、会话标识Cookie: sessionidxxx、风控标记X-Device-Fingerprint: xxx甚至有些App把加密密钥直接放在X-Enc-Key里传。这些信息一旦被截获后续的协议分析、自动化测试、安全审计、竞品功能还原就都有了坚实支点。所以这不是一个“玩具级”的技术演示而是逆向分析中真正能落地、能闭环、能产出业务价值的第一步。我带过的几个实习生都是从这个案例开始建立逆向信心的。他们之前觉得逆向反编译看smali猜逻辑痛苦又低效。但当第一次用Frida脚本在手机上实时打印出“https://api.example.com/v2/user/profile?uid123456”和“Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...”时那种“原来数据真的长这样”的震撼感远超任何理论讲解。这背后没有魔法只有对OkHttp源码结构的熟悉、对Frida JS API的精准调用、以及对Android运行时环境的务实判断。接下来的内容就是我把这三年在电商、金融、社交类App中反复验证过的完整路径掰开揉碎讲给你听。2. OkHttp核心调用链与Frida Hook的“黄金锚点”选择要Hook得准先得知道往哪儿钉钉子。OkHttp的调用流程看似复杂但主干非常清晰用户构建Request对象 → 通过OkHttpClient创建Call→ 调用enqueue()异步或execute()同步触发执行 → 进入Dispatcher分发 → 经过Interceptor链处理 → 最终由RealConnection完成TCP/HTTP通信。其中有三个位置是Hook URL和Header的绝对优先级锚点它们覆盖了95%以上的实际场景且稳定性极高。2.1 锚点一Request.Builder.addHeader() 与 .url() —— 构造阶段的源头捕获这是最干净、最无副作用的Hook点。几乎所有App在发起请求前都会用new Request.Builder().url(https://...).addHeader(User-Agent, ...)来组装请求。Builder类是OkHttp的公开API方法签名稳定不受混淆影响即使App做了代码混淆Builder类名和addHeader方法名通常保留。Hook这里你能拿到原始、未编码、未拼接的URL字符串和Header键值对连?后面的查询参数都还是明文状态。我实测过某头部电商App的首页请求其URL构造逻辑是String baseUrl https://api.shop.com/v3/; String path home/recommend; String query String.format(uid%scity%sv%s, uid, city, version); String fullUrl baseUrl path ? query; // 这里query是明文 new Request.Builder().url(fullUrl).addHeader(X-Session-ID, sessionId)HookBuilder.url(String)后直接打印fullUrl就能看到完整的带参URLHookBuilder.addHeader(String, String)则能逐条捕获每个Header。这种Hook方式的好处是完全不干扰请求流程不会因Hook导致请求失败且能100%覆盖所有手动构造的请求。缺点是无法捕获那些通过Request.Builder.url(HttpUrl)重载方法传入HttpUrl对象的场景较少见以及某些框架自动拼接的请求如Retrofit的Query注解生成的URL它内部仍会调用Builder.url()所以依然有效。2.2 锚点二OkHttpClient.newCall(Request) —— 请求实例化的统一入口当Builder.build()生成Request对象后下一步必然是okHttpClient.newCall(request)。这个方法是OkHttp的“闸口”所有请求都必须经过它才能变成可执行的Call。Hook这里你能拿到最终成型的Request对象然后调用其url().toString()和headers().toMultimap()方法获取标准化后的URL已处理重定向、编码等和全部Header包括Builder添加的和Interceptor链注入的。这个锚点的优势在于全覆盖、高保真。它不关心你是怎么构造Request的哪怕App用了自定义的网络封装库只要底层调用的是OkHttp就逃不过newCall()。更重要的是Request对象本身是不可变的immutable你在这里读取的数据就是即将发出的“最终版”请求快照。我曾在一个加固极强的金融App中成功Hook此点因为加固器通常只保护业务逻辑层对OkHttp这种基础库的调用入口极少做特殊防护。但要注意一个细节newCall()返回的是Call不是立即执行。如果你只Hook这里只能看到“准备发什么”看不到“什么时候发”。所以它常与下一个锚点配合使用。2.3 锚点三RealCall.execute() 与 RealCall.enqueue(Callback) —— 执行时刻的临门一脚RealCall是Call接口的具体实现类execute()同步和enqueue()异步是真正触发起网络I/O的方法。Hook这两个方法意味着你能在请求即将发出的毫秒级瞬间捕获所有信息。此时Request对象已完全绑定url()和headers()返回的数据就是网络栈实际发送的内容。这个锚点的价值在于时机精准、上下文完整。例如某些App会在Interceptor中动态修改Header如添加时间戳、签名这些修改在newCall()时还不存在只有到execute()/enqueue()时才最终确定。Hook这里你捕获的就是“签名后”的真实Header。另外enqueue()的Callback参数里还包含onFailure()和onResponse()回调你可以顺手HookonResponse()来捕获响应体形成请求-响应的完整链路。不过RealCall是OkHttp的内部类package-private类名可能随版本变化如OkHttp 3.x是RealCall4.x是RealCall但包路径不同。这就引出了一个关键经验不要硬编码类全限定名而要用Frida的Java.use()配合模糊匹配。比如我常用Java.choose(okhttp3.RealCall, {...})或者更稳妥地先HookOkHttpClient.newCall()拿到Call实例再用instanceof判断其真实类型再反射获取其私有字段。这比死记硬背类名可靠得多。下表对比了这三个锚点的核心特性帮你根据实际场景快速决策Hook锚点触发时机获取URL/Headers方式覆盖率稳定性典型适用场景Request.Builder.*请求构造期Builder.url(String)/addHeader(String,String)★★★★☆ (90%)★★★★★ (极高)分析URL拼接逻辑、抓取原始Header键值OkHttpClient.newCall()请求实例化Request.url().toString()/Request.headers().toMultimap()★★★★★ (100%)★★★★☆ (高)全量捕获、分析最终请求快照RealCall.execute()/enqueue()请求执行前同newCall()但数据为“最终版”★★★★★ (100%)★★★☆☆ (中)需要捕获Interceptor动态注入的Header、关联请求-响应提示在真实项目中我从不只Hook一个点。标准做法是同时HookBuilder和newCall()。前者帮你理解App的“意图”它想发什么后者帮你确认“事实”它实际发了什么。两者对比往往能发现隐藏的中间件逻辑或异常分支。3. Frida脚本实战从零编写可复用的OkHttp Hook模块光说原理不够得让你马上能跑起来。下面是一个我在多个项目中反复打磨、可直接复制粘贴的Frida脚本它同时Hook上述三个锚点并做了生产环境级别的健壮性处理。脚本用JavaScript编写适配Frida 14.2已在Android 8.0至13.0真机上稳定运行。3.1 脚本核心结构与设计哲学这个脚本不是一堆零散Hook的堆砌而是一个有明确职责划分的模块initOkHttpHooks()主入口负责探测OkHttp版本、加载对应Hook逻辑hookBuilder()专注Request.Builder捕获构造期URL和HeaderhookNewCall()HookOkHttpClient.newCall()捕获最终请求快照hookRealCallExecuteEnqueue()HookRealCall的执行方法补全执行时刻数据logRequest()统一日志格式化函数输出结构化、易筛选的日志。设计上遵循三个原则最小侵入、最大兼容、最简输出。不修改任何对象状态只做读取用try/catch包裹所有可能失败的操作如反射调用、字段访问日志用[OKHTTP]前缀方便adb logcat | grep OKHTTP一键过滤。所有关键操作都加了注释说明“为什么这么写”。3.2 完整可运行脚本含详细注释// okhttp-hook.js - 专为Android逆向设计的OkHttp URL/Headers捕获脚本 // 作者十年安卓逆向老兵 | 适配OkHttp 3.12 4.x // 使用方式frida -U -f com.example.app -l okhttp-hook.js --no-pause // 主初始化函数 function initOkHttpHooks() { console.log([OKHTTP] 开始探测OkHttp环境...); // 步骤1尝试加载OkHttpClient类确认OkHttp存在 try { const OkHttpClient Java.use(okhttp3.OkHttpClient); console.log([OKHTTP] ✅ 成功加载OkHttpClient类OkHttp 3.x已就绪); // 步骤2Hook OkHttpClient.newCall(Request) 方法 OkHttpClient[newCall].implementation function(request) { // 关键先调用原方法拿到RealCall实例 const call this[newCall].apply(this, arguments); // 关键在此处捕获Request对象的URL和Headers try { // 获取Request对象arguments[0]就是request const url request.url().toString(); const headersMap request.headers().toMultimap(); // 格式化Headers为字符串 let headersStr ; const keys headersMap.keySet().toArray(); for (let i 0; i keys.length; i) { const key keys[i]; const values headersMap.get(key).toArray(); for (let j 0; j values.length; j) { headersStr ${key}: ${values[j]}\n; } } console.log([OKHTTP] newCall捕获 - URL: ${url}); if (headersStr.length 0) { console.log([OKHTTP] newCall捕获 - Headers:\n${headersStr.trim()}); } } catch (e) { console.log([OKHTTP] ⚠️ newCall日志捕获异常: ${e.message}); } return call; }; } catch (e) { console.log([OKHTTP] ❌ 未找到OkHttpClient类可能是OkHttp 4.x或未加载。尝试备用方案...); // OkHttp 4.x 的包路径是 okhttp3.internal.http.RealCall但newCall在OkHttpClient里路径不变 // 所以这里先不处理等下Hook Builder } // 步骤3Hook Request.Builder 类OkHttp 3.x 和 4.x 均适用 try { const RequestBuilder Java.use(okhttp3.Request$Builder); console.log([OKHTTP] ✅ 成功加载Request$Builder类); // Hook Builder.url(String) 方法 RequestBuilder[url].overload(java.lang.String).implementation function(urlStr) { console.log([OKHTTP] Builder.url() - ${urlStr}); return this[url].apply(this, arguments); }; // Hook Builder.addHeader(String, String) 方法 RequestBuilder[addHeader].overload(java.lang.String, java.lang.String).implementation function(name, value) { console.log([OKHTTP] Builder.addHeader() - ${name}: ${value}); return this[addHeader].apply(this, arguments); }; // Hook Builder.header(String, String) 方法覆盖式会替换同名header RequestBuilder[header].overload(java.lang.String, java.lang.String).implementation function(name, value) { console.log([OKHTTP] Builder.header() - ${name}: ${value} (覆盖模式)); return this[header].apply(this, arguments); }; } catch (e) { console.log([OKHTTP] ⚠️ Hook Builder失败: ${e.message}. 可能被混淆尝试反射查找...); // 备用方案通过Java.enumerateLoadedClasses()遍历所有类找含Builder和Request的类 // 实际项目中很少需要此处省略保持脚本简洁 } // 步骤4Hook RealCall 的 execute() 和 enqueue() 方法需谨慎类名可能变化 // 策略先尝试标准路径失败则用Java.choose动态查找 const realCallClassNames [okhttp3.RealCall, okhttp3.internal.http.RealCall]; let realCallFound false; realCallClassNames.forEach(className { try { const RealCall Java.use(className); console.log([OKHTTP] ✅ 成功加载RealCall类: ${className}); // Hook execute() 方法 RealCall[execute].implementation function() { try { // 通过this获取其私有字段 originalRequest const requestField this.class.getDeclaredField(originalRequest); requestField.setAccessible(true); const request requestField.get(this); const url request.url().toString(); const headersMap request.headers().toMultimap(); let headersStr ; const keys headersMap.keySet().toArray(); for (let i 0; i keys.length; i) { const key keys[i]; const values headersMap.get(key).toArray(); for (let j 0; j values.length; j) { headersStr ${key}: ${values[j]}\n; } } console.log([OKHTTP] ⚡ execute()捕获 - URL: ${url}); if (headersStr.length 0) { console.log([OKHTTP] ⚡ execute()捕获 - Headers:\n${headersStr.trim()}); } } catch (e) { console.log([OKHTTP] ⚠️ execute()日志捕获异常: ${e.message}); } return this[execute].apply(this, arguments); }; // Hook enqueue(Callback) 方法 RealCall[enqueue].overload(okhttp3.Callback).implementation function(callback) { try { const requestField this.class.getDeclaredField(originalRequest); requestField.setAccessible(true); const request requestField.get(this); const url request.url().toString(); const headersMap request.headers().toMultimap(); let headersStr ; const keys headersMap.keySet().toArray(); for (let i 0; i keys.length; i) { const key keys[i]; const values headersMap.get(key).toArray(); for (let j 0; j values.length; j) { headersStr ${key}: ${values[j]}\n; } } console.log([OKHTTP] ⚡ enqueue()捕获 - URL: ${url}); if (headersStr.length 0) { console.log([OKHTTP] ⚡ enqueue()捕获 - Headers:\n${headersStr.trim()}); } } catch (e) { console.log([OKHTTP] ⚠️ enqueue()日志捕获异常: ${e.message}); } return this[enqueue].apply(this, arguments); }; realCallFound true; } catch (e) { // 继续尝试下一个类名 } }); if (!realCallFound) { console.log([OKHTTP] ⚠️ 未找到RealCall类将跳过execute/enqueue Hook。newCall和Builder已足够覆盖大部分场景。); } } // Frida入口函数 Java.perform(function() { console.log([OKHTTP] Frida脚本已注入正在初始化Hook...); // 加入延迟确保OkHttp类已加载某些App启动慢 setTimeout(initOkHttpHooks, 500); // 持续监听防止类加载延迟 Java.scheduleOnMainThread(function() { console.log([OKHTTP] 主线程调度完成Hook已激活。); }); });3.3 脚本部署与调试技巧把这个脚本保存为okhttp-hook.js然后在终端执行# 确保手机已连接frida-server已运行 frida -U -f com.example.app -l okhttp-hook.js --no-pause--no-pause参数至关重要它让App启动后不暂停避免某些加固App因长时间暂停而崩溃。调试时的三个黄金技巧日志分级过滤adb logcat | grep -E (OKHTTP|Frida)只看关键日志避免被系统日志淹没。动态开关Hook在脚本里加一个全局变量const ENABLE_LOGGING true;所有console.log都加if(ENABLE_LOGGING)判断。需要关闭日志时只需改一个变量不用删代码。异常静默处理所有try/catch里的console.log都加⚠️符号一眼就能从海量日志里识别出异常点。我甚至会把异常堆栈e.stack也打印出来方便定位是哪个反射调用失败。注意如果遇到Java.use is not a function错误说明Frida版本太低12.0请升级到最新版。如果Hook完全没反应大概率是App用了OkHttp 2.x已淘汰或自研网络库此时应先用frida-trace -U -i *okhttp* com.example.app命令粗略扫描所有OkHttp相关方法调用再针对性Hook。4. 真实踩坑全记录从日志爆炸到精准过滤的完整排查链路理论再完美不经历真实世界的毒打都不算真掌握。下面是我过去一年在三个不同App中踩过的典型坑每一步排查都附带具体命令、日志片段和解决方案。这不是事后诸葛亮的总结而是当时在终端前逐行调试的真实复盘。4.1 坑一日志刷屏根本找不到目标请求某社交App现象脚本一运行adb logcat瞬间被[OKHTTP] Builder.url() - https://api.social.com/v2/feed?offset0limit20刷满每秒上百条全是feed流刷新请求。我想找的是登录接口/v2/login但在上千行日志里肉眼根本无法定位。排查过程第一步确认是否是Builder.url()被高频调用。用frida-trace验证frida-trace -U -i okhttp3.Request\$Builder.url com.social.app输出显示该方法每200ms被调用一次证实是feed流。第二步思考如何过滤。Builder.url()是字符串参数我可以直接在Hook里加if (urlStr.includes(/login))判断。第三步但登录请求可能用Builder.url(HttpUrl)重载urlStr为空。于是改用newCall()钩子在那里request.url().toString()是最终URL必然包含路径。解决方案在newCall()Hook里加入智能过滤// 替换原newCall Hook中的console.log部分 const url request.url().toString(); if (url.includes(/login) || url.includes(auth) || url.includes(session)) { console.log([OKHTTP] 敏感请求捕获 - ${url}); // 后续Headers打印逻辑... }同时把日志前缀从换成用符号快速区分。现在grep 就能精准定位。4.2 坑二Header值为空但抓包显示有值某金融App现象脚本打印出Authorization:空值但用Charles抓包看到Authorization: Bearer xxx。明显数据对不上。排查过程第一步怀疑是Interceptor在newCall()之后、execute()之前注入的。于是启用RealCall.execute()Hook果然在那里捕获到了完整Header。第二步深挖原因。用frida-trace跟踪RealCall的整个生命周期frida-trace -U -i okhttp3.RealCall.execute -i okhttp3.RealCall.enqueue com.finance.app发现execute()调用前有okhttp3.internal.http.BridgeInterceptor.intercept()被调用。第三步查OkHttp源码BridgeInterceptor正是负责把Request.Builder的Header转换成网络层Header的地方。它会读取Request的headers()但某些加固App会Hookheaders()方法返回空Map。解决方案放弃读request.headers()改用反射读RealCall的私有字段// 在RealCall.execute() Hook里 const requestField this.class.getDeclaredField(originalRequest); requestField.setAccessible(true); const request requestField.get(this); // 不再用 request.headers() // 改用反射读Request内部的headers字段OkHttp 3.x是headers4.x是headerList try { const headersField request.class.getDeclaredField(headers); // 3.x headersField.setAccessible(true); const headers headersField.get(request); // ... 解析headers } catch (e) { // 尝试4.x的headerList字段 }这个方案绕过了被加固Hook的公开API直击内存数据。4.3 坑三Hook失效日志完全不输出某游戏App现象脚本注入成功但adb logcat里没有任何[OKHTTP]日志frida-trace也显示零调用。排查过程第一步确认App是否真用OkHttp。frida-trace -U -i *okhttp* com.game.app结果空空如也。说明它没用OkHttp第二步用jadx-gui反编译APK搜索import okhttp确实没有。再搜HttpURLConnection也没有。继续搜okioOkHttp依赖库也没有。第三步用strings命令扫APK的so库strings app-release.apk | grep -i http发现大量libcurl.so字符串。真相大白它用的是C层的libcurl网络库解决方案立刻切换技术栈。不再用Java层Frida改用frida-traceHook so层# 找到libcurl的so文件名通常是libcurl.so或libnative-lib.so frida-trace -U -i curl_easy_setopt -i curl_easy_perform com.game.appcurl_easy_setopt的第二个参数如果是CURLOPT_URL或CURLOPT_HTTPHEADER就能捕获URL和Header。虽然难度上升但思路一致找到网络调用的统一入口无论它在Java层还是Native层。经验总结Hook失败的第一反应永远不是“脚本写错了”而是“这个App到底用的什么网络库”。多花5分钟确认技术栈能省下几小时无谓调试。我现在的标准动作是frida-trace -U -i *http* -i *okhttp* -i *curl* com.app.id一网打尽。5. 进阶应用从单纯捕获到协议分析与自动化测试Hook URL和Header只是起点真正的价值在于如何用这些数据驱动后续工作。下面分享三个我已在实际项目中落地的进阶用法它们把“看到数据”变成了“利用数据”。5.1 用捕获的URL和Header自动生成Postman集合手动在Postman里敲URL、填Header、设Body效率极低。我们可以把Frida日志转成Postman的Collection JSON格式。实现思路修改Frida脚本在logRequest()函数里不只打印而是把每次捕获的URL、Method、Headers、RequestBody如果能Hook到组装成一个JSON对象用send()函数把JSON发给Python宿主进程Python端用frida库接收存为collection.json再用newman命令行工具运行测试。关键代码片段Frida端function sendToPostman(url, method, headers, body) { const postData { name: Auto-${method}-${url.split(/).pop().split(?)[0]}, request: { method: method, header: [], url: { raw: url } } }; // 转换Headers为Postman格式 for (let [key, value] of Object.entries(headers)) { postData.request.header.push({ key: key, value: value }); } if (body) { postData.request.body { mode: raw, raw: body }; } send(postman-request, postData); // 发送给Python }Python端接收并生成Collectionimport frida import json def on_message(message, data): if message[type] send and message[payload] postman-request: req_data message[data] # 追加到collection列表... collection[item].append(req_data) # 启动Frida并监听 device frida.get_usb_device() session device.attach(com.example.app) script session.create_script(open(okhttp-hook.js).read()) script.on(message, on_message) script.load() # 退出时保存为Postman Collection with open(auto_collection.json, w) as f: json.dump(collection, f, indent2)这样你一边操作App另一边就自动生成了一个可执行的Postman测试集用于回归测试、压力测试或接口文档生成。5.2 基于Header的会话状态监控与自动续期很多App的登录态靠Header里的Authorization或Cookie维持过期后会返回401。我们可以用Frida实时监控这个Header一旦发现过期自动触发续期逻辑。实现逻辑在newCall()Hook里提取Authorization值用正则匹配JWT的exp字段eyJhbGciOi...解码后有exp: 1712345678计算exp时间戳与当前时间差若小于5分钟则认为即将过期此时不拦截请求而是send()一个消息给Python端Python端调用App的“刷新Token”接口拿到新Token后再用Java.perform动态修改内存中的Token缓存。效果整个过程对用户透明App在后台自动完成Token刷新你抓到的永远是有效的Header。这在长时间自动化测试中极为关键。5.3 构建轻量级“网络流量沙箱”把所有Hook到的请求按域名、路径、响应码分类存入SQLite数据库就能构建一个App的“网络行为画像”。数据维度domain:api.example.compath:/v2/user/profilemethod:GETstatus_code:200(需HookonResponse())response_size: 响应体长度timestamp: 毫秒时间戳分析价值找出高频请求如每秒10次的/v2/feed/refresh评估服务器压力发现异常路径如/debug/dump提示存在未删除的调试接口统计401响应占比判断登录态管理是否健康对比不同版本APK的请求差异快速定位新增/废弃接口。这个沙箱不需要任何服务端纯本地运行数据完全可控。我把它集成进我们的逆向工作流每次新App接入第一件事就是跑20分钟这个沙箱生成一份《网络行为基线报告》后续所有分析都以此为参照。最后分享一个小技巧在Frida脚本里用Date.now()打时间戳再用console.log输出adb logcat的时间戳精度是秒级但Date.now()是毫秒级。把两者相减就能算出从Hook触发到日志输出的延迟这个延迟如果超过100ms说明你的Hook逻辑太重需要优化。我见过有人在Hook里做Base64解码导致UI卡顿就是没做这个延迟监控。我在实际使用中发现这套方法论最大的价值不是它能抓到多少数据而是它把模糊的“逆向分析”变成了可量化、可追踪、可协作的工程任务。当团队里每个人都能用同一套脚本、同一份日志规范、同一个沙箱数据库工作时沟通成本直线下降项目进度反而更快。技术本身没有高下能让团队高效运转的才是好技术。