那年冬
رفتن به کانال در Telegram
开发者不会主动联系你 本系列作品仅供学习研究 使用者的任何行为与应用作者无关 请在24小时内删除本应用下载代表同意本协议 若有侵权违法行为请联系我删除内容 主频道 @ZXHNB520 交流群 @NND520520
نمایش بیشترکشور مشخص نشده استدسته بندی مشخص نشده است
1 576
مشترکین
+624 ساعت
+587 روز
+46330 روز
آرشیو پست ها
1 578
好的，收到——先看看这个 libTool.so 是啥情况。文件不是加密的——它是一个正常的 ELF 共享库（ARM aarch64 架构，8.7MB，已 stripped）。先扒一下里面的导出符号和字符串，看看它到底是干嘛的。这个库是静态链接了 OpenSSL 的 ARM 库，里面带 AES 等加解密全套。继续挖——看它依赖什么、有没有硬编码的密钥/业务字符串。业务函数都是内部符号（stripped），导出全是 OpenSSL。直接从字符串下手——提取可读字符串，找密钥、URL、算法线索。这库有意思了——除了 OpenSSL，还静态链接了 ImGui（Dear ImGui GUI 库）+ OpenGL ES + EGL，是典型的 Android native 调试/覆盖层工具（游戏作弊菜单那类）。继续挖业务字符串和 JNI 入口。有货了：DobbyHook（inline hook 框架）+ process_vm_readv（跨进程读内存）+ socket/connect（网络）——这是个典型的游戏辅助/hook 注入库。那一堆"随机串"很可能就是硬编码密钥或加密数据。继续深挖菜单文本、服务器地址、包名。正则太长报错，简化重来。没有明文菜单文本（可能被混淆/加密了）。那些"随机串"很可疑——查一下它们的分布和格式，同时看看 JNI_OnLoad 入口逻辑。那堆"随机串"是 ImGui 内嵌压缩字体的特征数据，不是密钥。真正的逻辑在代码里——反汇编 JNI_OnLoad 和构造函数，看它到底干嘛。反汇编 JNI_OnLoad（0x55368c）看入口逻辑。本机 objdump 不支持 ARM64。用 Python capstone 反汇编。pip 环境坏了。换 apt 装。没 root。直接从 PyPI 下载 wheel 解压到本地用。URL 拼错了。直接查 PyPI API 拿正确下载地址。.有通用 wheel。下载解压直接用。capstone 能用了。写脚本反汇编 JNI_OnLoad 看入口逻辑。文件名 dis.py 跟标准库冲突了，改名重跑。JNI_OnLoad 只是标准保存 JNIEnv 返回 JNI_VERSION_1_6，没干货。真正逻辑在 init_array 构造函数里。先看 rodata 长字符串（证书/base64/URL），再反汇编构造函数。全是符号，业务字符串被藏起来了。反汇编 init_array 构造函数，找注册逻辑和加密入口。抓到大鱼了——ctor @ 0x5396fc 里有明显的 XOR 解密逻辑（eor v0.16b, v0.16b, v1.16b、单字节 eor w9, w9, #0xa3）：这个库的"加密"是运行时字符串混淆，启动时 XOR 解回明文。把加密数据和密钥 dump 出来，直接解密看看内容。构造函数里有明确的 XOR 解密逻辑（eor 指令 + 密钥 0xa3 + 8字节密钥 0xc6270）。反汇编解密函数 0x57ff58，同时 dump 相关数据区。解密模板完全清楚了！每个加密字符串对象是 24 字节：[0:16] 主体、[0x10:0x14] 4字节、[0x14] 单字节、[0x15] 标志=1 表示需解密。批量扫描 .data 段里的加密对象，全解出来。扫描到的多是结构体误报（ImGui 表数据）。真正的加密字符串可能藏在 .rodata。dump 构造函数引用的关键区域看看。密钥区有料：0xc5220 = a3 e3 dd a7 75 77 6d bd（8字节重复）。尝试用这个密钥做重复 XOR 全 .rodata 扫描，找出所有解密后可读的字符串区域。8字节密钥解出的是调试数据不是业务文本。换个思路——那些 .data 对象里有指向 .rodata 的指针，直接顺着指针 dump 字符串。那些全是 OpenSSL 内部字符串。这个库把整个 OpenSSL 静态链进去了。快速确认有没有加壳特征（UPX/自解密），再看尾部大构造函数。分析基本齐了。这库没有加壳、没有自解密段——文件本身根本没加密。把整个分析整理成报告交付。搞定，分析完了。先说结论：这个 libTool.so 根本没加密——它是一个标准 ELF 共享库，直接就能加载和反汇编，不存在"解密"这一步。
我把它从里到外扒了一遍，完整报告在这：
libTool.so 逆向分析报告
核心发现给你捋一遍：
它是啥
- Android ARM64 的 native 库（8.35MB，符号已 stripped）
- 没有加壳（无 UPX/VMProtect/自定义壳）
- 依赖 liblog、libandroid、libEGL、libGLESv3、libz
里面静态链接了什么
- 完整 OpenSSL：AES、RSA、DES、MD5、SHA256、CHACHA20、SSL/TLS 全栈，导出符号几乎全是它的
- DobbyHook（inline hook 框架）+ process_vm_readv（跨进程读内存）
- Dear ImGui + OpenGL ES（屏幕上画菜单/覆盖层）
- C++ 标准库
功能画像:典型的 Android 游戏注入/hook 工具库——DobbyHook 改目标函数、ImGui 渲染 HUD 菜单、TLS 做通信。JNI_OnLoad 只是标准初始化（存 JNIEnv、返回 JNI_VERSION_1_6）。
唯一的"加密"点:里面有 XOR 运行时字符串混淆——24 字节的加密字符串对象，启动时用 5 个解密模板 XOR 还原。密钥和算法我都定位出来了（报告里有完整表格和伪代码）。实测解出来的全是 OpenSSL 内部调试串（错误消息、密码套件名、源文件路径），没找到明文业务字符串——菜单文本/服务器地址这些要么藏在更深层，要么由运行时动态构造。
下一步想深入的话,最有效的是动态分析:把库丢进 Android 模拟器/真机,用 Frida hook 住解密函数和 SSL_read/SSL_write,直接把运行时解密后的完整字符串和通信流量抓出来——这个我可以帮你搭环境。要搞说一声。
