简介这份资源面向逆向工程初学者与安全分析人员聚焦 Android 平台 .so 动态库的反编译与静态分析借助 IDA Pro 及其 Hex-Rays 反编译插件帮助读者理解二进制代码还原为类 C 语言伪代码的完整流程。压缩包共收录 2000 个文件约 156.76MB其中以 1769 个 Python 脚本为主体配合 119 个文本说明、93 个 C 头文件、8 个 C 源文件以及少量 XML、HTML、JSON、Shell 与 hpp 文件覆盖反编译插件示例、类型定义与辅助分析脚本等多种用途。资源中可见 Hex-Rays 系列示例源码与 unicodeobject、abstract 等头文件便于对照研究反编译器的类型推导与结构还原逻辑。目前已有 2714 人学习下载适合希望从零掌握 IDA Pro 反编译 .so 文件、积累逆向分析经验并参考现成脚本与头文件进行二次开发的读者。1. 反编译 .so 文件从 IDA Pro 的伪代码里挖出 C 语言逻辑第一次拿到一个 stripped 的 .so 文件时我盯着 IDA Pro 里满屏的sub_xxxx和loc_xxxx发了十分钟呆。那是一个硬件驱动模块符号表被扒得干干净净导出函数只剩几个JNI_OnLoad和Java_xxx的入口。当时我以为反编译就是按 F5 看伪代码结果 F5 出来的东西比汇编还难读——变量名是v1、v2、v3类型是int和__int64混着来结构体全被拍平成字节偏移。后来踩了足够多的坑才明白反编译 .so 的核心不是“看伪代码”而是“重建类型系统和调用约定”。这篇内容面向的是手里已经有一份 .so 文件、想用 IDA Pro 把 C/C 逻辑还原出来的安全分析人员我会把从加载文件到还原出可读 C 代码的完整链路拆开讲包括那些 IDA 不会自动帮你做、但必须手动补上的步骤。2. 加载与识别.so 文件在 IDA Pro 里的初始配置2.1 处理器架构与加载选项的匹配拿到一个 .so 文件第一件事不是直接双击打开。我一般会先用file命令确认架构file libtarget.so # 输出示例libtarget.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, stripped这一步决定了 IDA Pro 加载时选哪个处理器模块。ARM64 和 ARM32 的指令集差异很大选错了连反汇编都出不来。如果是 Android 平台的 .so常见的是ARM aarch64或ARM32 位偶尔也会遇到 x86_64 的模拟器版本。在 IDA Pro 的加载对话框里有几个选项需要手动确认选项推荐设置原因Processor type根据file输出选择选错会导致指令解码失败Loading offset默认 0.so 是位置无关代码IDA 会自动处理基址Manual load不勾选让 IDA 自动解析 ELF 头Rename DLL entries勾选把导出表里的符号名恢复出来加载完成后先看两个窗口Functions window 和 Exports window。如果 Functions window 里只有几十个函数说明符号表被 strip 得很干净后续工作量会大很多。Exports window 里能看到JNI_OnLoad、Java_xxx_xxx这类入口这些是分析的起点。2.2 识别 JNI 入口与初始化函数Android 的 .so 文件通常通过 JNI 和 Java 层交互。JNI_OnLoad是动态注册的入口里面会调用RegisterNatives把 Java 方法和 native 函数绑定起来。找到这个函数就能拿到一张“Java 方法名 → native 函数地址”的映射表。在 IDA Pro 里定位JNI_OnLoad的方法在 Exports window 里直接搜JNI_OnLoad如果没被 strip 就能直接看到。如果被 strip 了就去.init_array段找初始化函数指针数组第一个或第二个条目通常就是JNI_OnLoad。找到之后按 F5 生成伪代码重点看RegisterNatives的调用参数。第三个参数是一个JNINativeMethod数组每个元素包含三个字段Java 方法名、方法签名、native 函数指针。在伪代码里这个数组通常表现为一个全局变量或栈上的结构体数组。我一般会手动把这个数组的每个条目解析出来在 IDA 里给对应的 native 函数重命名比如Java_com_example_NativeLib_encrypt。这一步做完后续分析就有了明确的入口不用在sub_xxxx的海洋里瞎撞。注意有些 .so 会把RegisterNatives的调用拆散在多个函数里或者用字符串加密隐藏方法名。遇到这种情况先找RegisterNatives的导入表引用交叉引用往回追调用者。3. 类型重建把int和__int64还原成结构体与指针3.1 从伪代码的异常类型推断真实类型IDA Pro 的 Hex-Rays 反编译器在类型信息缺失时会做保守推断。最常见的表现是一个本该是指针的变量被标成int或__int64一个本该是结构体的参数被拆成多个独立变量。比如下面这段伪代码__int64 __fastcall sub_1234(__int64 a1, int a2, int a3) { int v3; __int64 v4; v3 *(_DWORD *)(a1 8); v4 *(_QWORD *)(a1 16); if ( v3 a2 ) return (*(__int64 (__fastcall **)(__int64, _QWORD))(v4 24))(a1, a3); return 0xFFFFFFFFLL; }这里a1明显是一个结构体指针偏移 8 处是一个int字段偏移 16 处是一个指针指向一个虚表或函数指针表24 处是其中一个函数指针。IDA 不知道这些所以全用__int64和int凑合。我的做法是先创建一个结构体类型把观察到的偏移和大小填进去然后在伪代码里把a1的类型改成MyStruct *。改完之后按 F5 重新反编译伪代码会立刻变得可读__int64 __fastcall sub_1234(MyStruct *self, int a2, int a3) { if ( self-field_8 a2 ) return self-vtable-method_24(self, a3); return 0xFFFFFFFFLL; }这一步的关键是“观察偏移规律”。同一个指针变量在多个地方出现每次访问的偏移和大小都一致那它大概率就是一个结构体指针。IDA Pro 的Local Types窗口ShiftF1可以手动添加结构体定义支持 C 语法直接粘贴进去就行。3.2 恢复 C 的 this 指针与虚表结构C 编译的 .so 文件成员函数的第一个参数永远是this指针。在 ARM64 的调用约定里this放在X0寄存器对应伪代码里的第一个参数。虚函数的调用表现为从this指针的偏移 0 处取出虚表地址再从虚表里按索引取出函数指针。识别虚表的方法在 IDA Pro 的.data.rel.ro段里会有一片连续的指针数组每个指针都指向.text段的函数。这些就是虚表。我一般会数一下每个虚表有多少个条目然后创建一个对应的结构体类型字段名用method_0、method_8这种偏移命名等后续分析出功能再改成有意义的名字。对于多重继承或虚继承的情况this指针可能会有调整。在伪代码里表现为调用某个虚函数之前先对this做加减偏移。遇到这种不要急着改类型先把调用链跟一遍确认是哪个基类的虚表再决定结构体怎么定义。提示IDA Pro 7.x 之后的版本支持自动识别 RTTIRun-Time Type Information。如果 .so 里保留了 RTTI可以在View → Open subviews → Type libraries里加载对应的 C 类型库IDA 会自动恢复一部分类名和继承关系。4. 控制流还原从loc_xxxx到可读的 if-else 与循环4.1 识别编译器优化后的分支与循环模式编译器优化会打乱源码的控制流结构。常见的模式有条件跳转反转源码里的if (a b)可能被编译成if (a b) goto else_block。循环展开一个简单的for循环可能被展开成几段重复的代码。尾调用优化函数末尾的调用被替换成b指令伪代码里表现为return sub_xxxx(...)。在 IDA Pro 的图形视图里这些模式比较直观。我一般会先看函数的 CFGControl Flow Graph找出所有的基本块和跳转边。如果一个基本块只有一条跳转指令且跳转目标是一个循环头那大概率是循环结构。如果多个基本块的代码高度相似只是偏移量不同那可能是循环展开。对于条件跳转反转Hex-Rays 通常能自动处理但偶尔会生成goto语句。遇到goto不要慌先看goto的目标标签判断它是向前跳还是向后跳。向前跳通常是if-else的else分支向后跳通常是循环。手动把goto改写成if-else或while伪代码的可读性会提升一个档次。4.2 手动修复 Hex-Rays 的goto与死代码Hex-Rays 在某些情况下会生成死代码比如if ( condition ) { // do something } else { // do something else } // 死代码永远不会执行 result 0; return result;这种死代码通常是编译器插入的占位指令或者 Hex-Rays 对跳转表的误判。我一般会先确认这段代码是否真的不可达在图形视图里看它有没有入边。如果没有入边直接 NOP 掉或者删掉。如果有入边但条件恒假那就把条件改成0或false让 Hex-Rays 重新优化。跳转表是另一个难点。C 语言的switch语句在编译后可能变成跳转表Hex-Rays 有时能识别有时会生成一堆goto。遇到跳转表我会先找到跳转表的基址和索引计算方式然后在伪代码里手动重建switch结构。IDA Pro 的Edit → Other → Specify switch功能可以辅助识别但需要手动指定跳转表的范围和默认分支。注意ARM64 的跳转表通常用adrpaddbr三条指令实现。adrp加载页基址add加上偏移br跳转。在伪代码里表现为一个数组索引和间接跳转。5. 避坑与排查反编译 .so 时最容易翻车的五个点5.1 现象F5 反编译失败提示 “call analysis failed”原因IDA Pro 无法确定某个函数的调用约定或参数数量导致 Hex-Rays 放弃反编译。常见于间接调用、尾调用或栈不平衡的代码。解决先找到报错的地址在汇编视图里看该处的指令。如果是间接调用手动设置调用约定右键函数 →Set function type指定参数类型和返回类型。如果是栈不平衡检查函数开头和结尾的SP调整是否匹配必要时手动修改栈指针值。5.2 现象伪代码里出现大量__int64强制转换逻辑混乱原因类型信息缺失Hex-Rays 用最宽的类型来兼容所有可能的操作。解决不要逐个改先分析变量的实际用途。如果它被当作指针解引用就改成指针类型如果它被当作结构体访问就创建结构体类型。改完之后按 F5 重新反编译Hex-Rays 会自动传播类型信息大部分强制转换会消失。5.3 现象字符串被加密IDA 里看不到明文原因.so 里使用了字符串加密运行时才解密。常见的加密方式有 XOR、AES、自定义算法。解决找到解密函数分析其算法和密钥。如果解密函数在JNI_OnLoad或.init_array里被调用可以在 IDA 里用 IDC 或 Python 脚本模拟解密过程批量还原字符串。我一般会写一个 IDAPython 脚本遍历所有引用加密字符串的地址调用解密函数把结果写回注释。5.4 现象函数识别不全很多代码没有被识别为函数原因.so 被 strip 后符号表丢失IDA 只能靠启发式规则识别函数。有些函数没有明显的push/pop序言或者被故意混淆。解决手动创建函数。在汇编视图里找到代码起始地址按P键创建函数。如果函数边界不对用Edit → Functions → Set function end手动调整。对于 ARM64函数开头通常是stp x29, x30, [sp, #-0x10]!或sub sp, sp, #0x20。5.5 现象反编译结果和实际运行行为不一致原因.so 里可能有反调试、反反编译逻辑或者代码在运行时被动态修改自修改代码。解决先确认是否有反调试。检查ptrace、/proc/self/status等系统调用的引用。如果有尝试在静态分析时绕过这些检查或者在动态调试时 patch 掉。对于自修改代码静态分析很难处理需要结合动态调试在内存中 dump 出解密后的代码段再分析。6. 从伪代码到 C 代码还原一个硬件加密模块的完整流程假设我们拿到一个硬件加密模块的 .so导出函数只有一个Java_com_example_HwCrypto_encrypt。目标是还原出它的 C 语言实现。第一步在 Exports window 里找到这个函数按 F5 生成伪代码。初始伪代码大概长这样__int64 __fastcall Java_com_example_HwCrypto_encrypt(__int64 a1, __int64 a2, __int64 a3, __int64 a4) { __int64 v4; __int64 v5; int v6; __int64 v7; __int64 v8; v4 (*(__int64 (__fastcall **)(__int64, __int64))(*(_QWORD *)a1 1360LL))(a1, a3); v5 (*(__int64 (__fastcall **)(__int64, __int64))(*(_QWORD *)a1 1400LL))(a1, a4); v6 sub_1A2C(v4, v5); v7 (*(__int64 (__fastcall **)(__int64, __int64, _QWORD))(*(_QWORD *)a1 1680LL))(a1, a3, 0LL); v8 sub_1B4C(v7, v6); (*(void (__fastcall **)(__int64, __int64, __int64))(*(_QWORD *)a1 1720LL))(a1, a3, v8); return v8; }这里a1是JNIEnv *a2是jobjecta3和a4是jbyteArray。*(_QWORD *)a1 1360是JNIEnv虚表里的GetByteArrayElements1400是GetArrayLength1680是NewByteArray1720是SetByteArrayRegion。手动把a1的类型改成JNIEnv *a3和a4改成jbyteArray然后在Local Types里加载jni.h的类型定义。重新反编译后伪代码变成jbyteArray __fastcall Java_com_example_HwCrypto_encrypt(JNIEnv *env, jobject thiz, jbyteArray input, jbyteArray key) { jbyte *input_bytes (*env)-GetByteArrayElements(env, input, 0); jsize input_len (*env)-GetArrayLength(env, input); jbyte *key_bytes (*env)-GetByteArrayElements(env, key, 0); jsize key_len (*env)-GetArrayLength(env, key); int encrypted_len sub_1A2C(input_bytes, input_len, key_bytes, key_len); jbyteArray output (*env)-NewByteArray(env, encrypted_len); jbyte *output_bytes sub_1B4C(input_bytes, encrypted_len); (*env)-SetByteArrayRegion(env, output, 0, encrypted_len, output_bytes); return output; }接下来分析sub_1A2C和sub_1B4C。sub_1A2C接收输入字节、输入长度、密钥字节、密钥长度返回一个整数。这大概率是加密算法的核心返回的是密文长度。sub_1B4C接收输入字节和长度返回一个字节指针可能是分配内存并拷贝数据。进入sub_1A2C发现里面有一个循环每次处理 16 个字节还有大量的 XOR 和位移操作。结合硬件加密模块的背景这很可能是 AES-128 的软件实现。继续跟下去找到 S-box 和轮密钥扩展的逻辑确认是 AES-CBC 模式。最后把整个流程用 C 语言重写出来jbyteArray Java_com_example_HwCrypto_encrypt(JNIEnv *env, jobject thiz, jbyteArray input, jbyteArray key) { jbyte *input_bytes (*env)-GetByteArrayElements(env, input, 0); jsize input_len (*env)-GetArrayLength(env, input); jbyte *key_bytes (*env)-GetByteArrayElements(env, key, 0); jsize key_len (*env)-GetArrayLength(env, key); // AES-128-CBC 加密PKCS7 填充 int padded_len (input_len / 16 1) * 16; unsigned char *padded pkcs7_pad((unsigned char *)input_bytes, input_len, padded_len); unsigned char *encrypted aes_128_cbc_encrypt(padded, padded_len, (unsigned char *)key_bytes, key_len); jbyteArray output (*env)-NewByteArray(env, padded_len); (*env)-SetByteArrayRegion(env, output, 0, padded_len, (jbyte *)encrypted); free(padded); free(encrypted); (*env)-ReleaseByteArrayElements(env, input, input_bytes, 0); (*env)-ReleaseByteArrayElements(env, key, key_bytes, 0); return output; }回过头看这个还原过程最耗时的不是算法分析而是类型重建。如果一开始就把JNIEnv *和jbyteArray的类型定义好后续的伪代码可读性会高很多。从那以后我每次打开一个新的 .so 文件都强制先做三件事确认架构、加载 JNI 类型库、把导出函数重命名。这三步做完后面的分析至少省一半时间。希望帮到你。本文还有配套的精品资源点击获取