说实话，有时候技术探索的起因真的hen简单。那天下午，阳光透过窗帘洒在键盘上，我盯着手机屏幕发呆。因为某些众所周知的原因，iOS 端一直没法安装那个应用，而网页版的功Neng又和移动端差了十万八千里。一个念头突然冒了出来：既然官方不给我用，那我就自己“造”一个。只要Neng把移动端那套 API 给扒下来我就Neng用 Web 技术复刻一个一模一样的。

这听起来像是天方夜谭，毕竟我也就是个半吊子开发者，对逆向工程这种高深莫测的领域一直是敬而远之。但这次不一样，我有了一把新武器——Claude Code。原本以为这会是一场漫长而痛苦的拉锯战，结果却让我大受震撼。从 APK 解包到全套 API 跑通，整个过程竟然只花了一个下午。而且，Zui离谱的是我几乎没怎么动手写代码，大部分时间dou在给 AI “点赞”。

起因：当需求撞上技术壁垒

事情的初衷非常朴素。我想在 Web 端实现移动端的所有功Neng，包括搜索、影片详情、磁力链接下载等等。但摆在面前的第一座大山就是：我不知道 API 地址，geng不知道请求参数和签名规则。传统的抓包？在这个应用面前显得有些力不从心，因为它的通信逻辑被封装得严严实实。

我甚至没有直接说出“逆向”或者“反编译”这种吓人的词，只是试探性地问了一句：“有没有办法kan API 代码？” 就这么一句轻描淡写的话，开启了一场自动化的技术解剖。

工具链准备：工欲善其事

在正式开始之前，我们得先把“手术台”搭好。这次行动的主力军是 Claude Code ，它负责统筹全局。配合它的还有几位老将：

apktool负责把 APK 文件拆解成人类可读的目录结构。

blutter这是专门对付 Flutter 应用的神器，因为 Dart 代码被编译成了机器码，常规工具根本kan不懂。

llvm-objdump用来反汇编原生库，也就是那个让人头大的 .so 文件。

环境搭建的过程还算顺利，虽然中间编译 Dart SDK 的时候等得我喝了两杯咖啡，但kan到终端里跳出的成功提示时一切等待dou是值得的。

第一阶段：拆解 APK，初探

我们把目标 APK 扔进了 apktool。随着解压进度的推进，一个标准的 Android 目录结构展现在眼前。但这里面藏着不少猫腻。

jdb_official_v1.x/
├── AndroidManifest.xml    # 配置文件
├── lib/arm64-v8a/         # 原生库
│   ├── libapp.so          # Flutter 引擎
│   └── libsecurity.so     # 安全库，只有 20KB
└── smali/                 # Java 层代码

当你打开 AndroidManifest.xml 时你会发现开发者非常有“幽默感”。包名居然成了 xxx.pornhub.fuck，甚至还配置了四个不同的 activity-alias 来切换图标，甚至设置了从Zui近任务列表中隐藏。这哪里是正经应用，简直像个间谍软件。不过这也侧面说明了他们对安全性的重视，逆向之路注定不会平坦。

第二阶段：Flutter 的迷雾与 blutter 的利刃

Ru果是传统的 Android 应用，用 jadx 把 smali 转成 Java 代码基本就Nengkan个大概了。但 JavDB 是用 Flutter 写的。这意味着所有的 Dart 逻辑dou被 AOT编译成了 ARM64 机器码，塞进了 libapp.so 里。对着那一堆二进制字节，人类是kan不懂的。

这时候就需要 blutter 出场了。它Neng把机器码反编译成带注释的汇编代码，甚至Neng提取出字符串常量池。运行 blutter 的过程有点像炼金术，它需要先编译对应版本的 Dart SDK，处理上百个 C++ 文件。

终于，在漫长的等待后blutter_out 目录生成了。这里面Zui珍贵的不是汇编代码，而是一个叫 pp.txt 的文件。这可是个宝藏，里面包含了应用里所有的字符串常量。

第三阶段：从字符串海洋中捞针

有了 pp.txt，提取 API 端点就变得像在大海里捞针——只不过这针是磁铁Zuo的，一捞一个准。我们只需要简单的 grep 命令：

grep '"/api/v' blutter_out/pp.txt

瞬间，几十个 API 路径整齐地排列在屏幕上：

"/api/v1/startup"
"/api/v2/search"
"/api/v4/movies/%s"
"/api/v1/actors/%s"
"/api/v1/rankings"
"/api/v1/sessions"
...以及geng多

这简直是意外的收获。我们不仅找到了启动配置、搜索、影片详情这些核心接口，甚至还发现了登录、注册、VIP 套餐等隐藏功Neng。但光有地址没用，服务器还有一道铁闸——签名验证。

第四阶段：攻克签名算法

这是整个过程中Zui烧脑的部分。Ru果你直接请求 API，服务器会冷冰冰地回复：“参数不Neng为空: jdsignature”。这个 jdsignature 就是守护 API 的大门神。

通过分析反编译出来的 intercept.dart，我们发现请求头里确实带了这个字段。它的生成逻辑藏在 common_tools.dart 的 getSignature 函数里。但这个函数调用了原生层的 getKey，而 getKey 又调用了 libsecurity.so 里的 getSecret。

这就像剥洋葱，一层套一层。我们不得不拿出 llvm-objdump 来分析那个 20KB 的 libsecurity.so。

寻找密钥：APK 证书的秘密

在汇编代码的海洋里潜水，我们终于发现了 getSecret 的逻辑。原来所谓的“密钥”并不是硬编码在代码里的，而是动态生成的！它会去读取 APK 的签名证书，提取 DER 编码的十六进制字符串，然后截取前 5 个字符。

这招真绝。只要你改了 APK 重新打包，签名变了密钥就变了API 也就调不通了。我们用 OpenSSL 提取了证书：

openssl pkcs7 -in original/META-INF/CERT.RSA -inform DER -print_certs | openssl x509 -outform DER | xxd | head

拿到那一串以 3082... 开头的字符，截取前 5 位，这就是我们的 secret。

还原解密逻辑：汇编代码的翻译

有了密钥，还没完。签名算法里还有两个加密常量 part1 和 part2 需要解密。这涉及到 getDecryptString 函数。对着几百行汇编代码kan，眼睛dou要瞎了。

经过反复推敲，我们还原出了 Python 版本的解密逻辑。这里有个坑，我差点踩进去：循环索引的计算方式。我一开始以为是取模运算，结果仔细kan汇编指令 cmp x8, x6 和 b.le，发现其实是 min。也就是说当数据长度超过密钥长度后就一直用密钥的Zui后一个字节。这细节，差之毫厘谬以千里。

还有一个坑：双重 Base64 解码。解密出来的字符串居然还是 Base64 编码的，必须再解码一次才Neng得到明文。这开发者真是把“防御性编程”玩到了极致。

签名的Zui终拼图

Zui后我们把所有碎片拼在了一起。签名的格式是：

timestamp.part2.md5

有了这个公式，生成正确的 jdsignature 就易如反掌了。那一刻，kan着终端里生成的签名字符串，我竟然有一种解开达芬奇密码的快感。

第五阶段：实战验证与工具化

理论再完美，也得经得起实践的检验。我们写了个 Python 脚本，试着调用了一下 /api/v1/startup 接口。

第一次请求，服务器报错：“参数不Neng为空: platform”。 第二次请求，又报错：“参数不Neng为空: app_channel”。 第三次我们老老实实地把所有参数dou补齐了。

终于，那个令人心动的 JSON 响应跳了出来：

{
  "success": 1,
  "action": null,
  "data": { ... }
}

成功了！那一刻，感觉整个世界dou亮了。随后我们像疯了一样测试了搜索、详情、磁力链接等几十个接口，全部畅通无阻。

为了方便以后使用，我们还顺手生成了两个东西： 1. 一个开箱即用的 Python API 客户端，把签名算法dou封装好了。 2. 一个标准的 OpenAPI JSON 文件，Ke以直接导入 Postman 或者其他工具。

经验：AI 时代的逆向工程

回过头来kan这次经历，感触良多。以前Zuo逆向，那是真的苦力活，对着 IDA Pro 一坐就是一天眼睛kan瞎了还不一定Neng搞懂逻辑。而现在有了像 Claude Code 这样的 AI 助手，局面完全变了。

我发出的指令其实非常模糊，比如“你先去试试”、“我觉得可行吗”。AI 居然Neng理解我的意图，自主选择工具，分析汇编代码，甚至自己调试错误。这不再是“辅助”，这是“主导”。

当然Flutter 的逆向依然比原生 Android 要难得多。Dart 代码的机器码还原不是一件轻松的事，但只要有合适的工具链和强大的 AI 辅助，这层壁垒也并非不可逾越。

Zui后kan着手里这份完整的 API 文档和可用的客户端代码，我不禁感叹：技术这东西，只要你敢想，敢去拆解，就没有什么秘密是藏得住的。当然这一切的学习和探索，仅限于技术研究目的，大家可千万别干坏事哦。

---