摘要

最近在做项目分析时发现普通的抓包代理方式抓不到某多的响应内容，故记录一下。

首先就是使用了最常见的app端进行https代理的方式进行抓包 结果只能抓到部分什么gif结尾的内容 分析dex发现 某多多使用了longlink技术 让普通的https根本是抓不到的

具体详情在 xxx.xxxx.xxxxtitan.api.TitanApiRequest和xxx.xxxx.xxxxtitan.api.TitanApiCall里 我这里只采用fridahook 前者TitanApiRequest 进行直接拦截得到请求 而不是完全关闭longlink 关闭longlink在最新的775版本貌似不太行了 应该是在后者 TitanApiCall里 没有进行深度分析 所以目前只分析了前者 附上frida脚本 由于本人文笔不好 故以下文章部分使用AI进行美化操作

本文分两部分：抓包部分（Frida） 和 商品详情的 hook 部分 两部分均给出思路、示例(Frida 脚本)

开始分析

某多使用了 longlink / 持久连接技术，把部分响应通过非普通短连接通道处理，导致常见的 HTTP(S) 代理只能抓到有限内容（例如 gif 结尾的静态片段或小包），而真正的业务响应在 Titan 网络层被处理。
为了解决这一点，分析后使用 Frida 拦截并输出响应内容 商品详情则直接在 Java 层 hook即可, 将json响应数据格式化后储存。

抓包部分（Frida Hook）

下面是可直接注入的 Frida 脚本（已对常见字段访问失败做多重尝试与反射容错），用于获取 TitanApiRequest.Builder 构造的请求并监控 longlink：

Java.perform(function () {
    var TitanApiResponse = Java.use("xxx.xxxx.xxxxtitan.api.TitanApiResponse");
    var StringCls = Java.use("java.lang.String");

    if (TitanApiResponse.getBodyBytes) {
        TitanApiResponse.getBodyBytes.implementation = function () {
            var hookPoint = "TitanApiResponse.getBodyBytes()";
            var data = this.getBodyBytes();
            if (data) {
                try {
                    var resp = StringCls.$new(data, "UTF-8");
                    if (resp) {
                        console.log("\n=== 📥 " + hookPoint + " 响应捕获 ===");
                        console.log(resp.length > 2000 ? resp.substring(0, 2000) + "..." : resp);
                        console.log("====================================\n");
                    }
                } catch (e) {
                    console.log("[!] " + hookPoint + " - 响应解析失败:", e);
                }
            }
            return data;
        };
    }
});

商品详情的 hook（仅提供伪代码与思路，不贴详细实现）

目标：在 Java 层拿到商品详情结构化对象（例如 IntegrationRenderResponse / GoodsResponse），将其序列化（如 Gson）为 JSON，上报或保存，以便后续分析。
说明：不贴出完整 Kotlin/Java 代码，以下为伪代码与流程示意，便于按你项目风格用 YukiHook/Xposed/Frida 等实现。

伪代码：hook 商品详情并导出 JSON
初始化 Hook 框架（YukiHookAPI / Xposed / Frida-Java）
加载目标包 "xxx.xxxx.xxxx"

找到目标类 GoodsResponse
找到目标方法 setRenderResponse(IntegrationRenderResponse)

在方法调用之前（before）:
    获取入参 renderResponse
    如果有 Gson 类:
        使用 Gson.toJson(renderResponse) 将对象序列化为 JSON 字符串
    否则:
        尝试调用 renderResponse 的 toString/其它序列化方法或手动提取关键字段
    将 JSON 保存到本地文件 或 发起 HTTP 请求 上报到分析服务器（注意防抖/限速）
    可选: 根据配置决定是否阻止或修改原始方法执行（通常不阻止）

在方法执行之后（after， 可选）:
    根据返回值或上下文做进一步分

商品详情 hook 的注意点与建议

• 序列化手段：优先使用 app 自带的 Gson 实例（避免与模块内的不同版本冲突）；若缺失 Gson，可手动取关键字段构造 JSON。
• 线程与上下文：上报请在子线程中执行，避免阻塞主线程。显示 Toast、启动 Activity 等需在主线程/Looper 上执行。
• 性能与限流：商品详情频繁触发时注意限速与重试策略，避免网络泛滥或被服务端风控。

实践中常见问题与排查清单

• 无日志输出 / 无 hook 生效：

  • 检查脚本注入时机（onCreate 前后、Activity 启动点等），尝试延迟注入或在不同进程注入，因为我做的时候就在这卡了一下午，最后延迟注入解决了，我真吐了

• 字段访问报错（NoSuchField/IllegalAccess）：

  • 先尝试 .field.value，再用反射 getDeclaredField 并 setAccessible(true)。

• longlink 无法禁用：

  • longlink 控制点可能在 TitanApiCall、native 层或独立的长连接管理器，需扩展枚举与 hook 范围。

• body 为二进制或压缩数据：

  • 尝试在拿到 body 后判断是否为 gzip/protobuf 等，进行解压或走 proto 反序列化入口 hook。

• 数据上报失败/被拦截：

  • 检查上报目标是否可达、是否有证书/代理限制、是否触发了反作弊策略。可改为先本地保存再人工批量上报。

结论与后续建议

• 抓包：在应用层 hook TitanApiRequest.Builder 是最直接有效的方式之一，能获取构建时的 URL/headers/body 但需准备多种 hook 点以应对版本差异。
• 商品详情：在 Java 层 hook 商品对象并序列化上报是一条稳定路径（前提是详情以 Java 对象存在并可序列化）。
• 组合方案：静态分析（jadx）→ 动态 hook（Frida/Yuki）→ 本地复现（curl/okhttp）三步走，能够最大化覆盖不同版本与协议差异。
• 合规：务必确保你对目标系统和数据有合法访问权限，遵守相关法律法规。