🔖SO逆向

常量定位法：密码学算法的"指纹鉴定"SO 层逆向最高频的问题是"这段代码用的什么加密算法"。答案几乎总是同一个：搜特征常量。密码学算法的安全性来自密钥，不来自算法结构——所以标准算法内部都嵌着公开的数学常量，这些常量在二进制里就是独一无二的指纹。本文把主流算法的识别常量汇总成一张速查表，配合搜索方法，30 秒识别一个算法。速查表：算法 → 特征常量对称加密：算法特征常量（hex 字节序）AESS盒 63 7C 77 7B F2 6B 6F C5；逆S盒 52 09 6A D5SM4S盒 D6 90 E9 FE CC E1；FK A3B1BAC6TEA 家族delta 0x9E3779B9DES

先看懂平坦化长什么样正常函数的 CFG（控制流图）是树状的：入口 → 分支 → 汇合 → 返回，层次分明。被 OLLVM 控制流平坦化（Control Flow Flattening）处理过的函数，CFG 变成一个大循环套 switch：入口 ↓ state = 初始值 ↓ ┌─────────────┐ │ while(1) │ ←──┐ │ switch(state) │ │ └─────────────┘ │ ↑___________┘所有真实代码块被拍平到同一层级，执行顺序由 state 变量驱动。读这种代码就像看被洗牌的电影——每

JNI 层是 Java 与 SO 的边境检查站分析带 native 签名的 App 时，最有价值的信息都发生在 JNI 边界：Java 层把什么参数传进了 SO，SO 又把什么结果还了回来。jnitrace 这个 Frida 工具就是干这个的——自动 hook 所有 JNI 函数调用，打印参数和返回值。pip install jnitrace jnitrace -l libtarget.so com.target.app-l 指定要跟踪的 SO。跑起来后，目标 SO 的每一次 JNI 调用（FindClass、GetMethodID、CallObjectMethod、NewStringUTF…

unidbg 的定位：SO 的"虚拟机"unidbg 用 Unicorn 引擎模拟 ARM 指令执行，让 Android 的 SO 文件脱离手机在 JVM 里跑起来。它的价值场景很明确：签名算法在 SO 里，你想批量调用但不想养一屋子手机。但 SO 不是独立运行的——它会调 JNI 函数（拿 Context、读系统属性、访问文件），这些调用在 unidbg 里全要"补环境"：用 Java 代码模拟 Android 系统的行为，让 SO 以为自己真在手机上。最小可运行骨架public class SignEmulator { private final AndroidEmulator e

自定义加密的本质：混淆而非密码当 App 不用任何标准算法（AES/RSA/TEA 都不是），而是自己撸一套"加密"——通常是异或、加减、位移、置换的组合。从密码学角度它弱不禁风，从逆向角度它的难度在于"没有特征可循"：没有常量可搜，只能硬读逻辑。好消息是：这类算法的强度上限很低，掌握方法后还原是时间问题。识别：先确认是自定义算法排除法确认：搜遍密码学常量（AES S 盒、TEA delta、MD5 K 表）无命中加密函数里有大量 eor（ARM 异或指令）、lsl/lsr（位移）、查表操作输入输出长度关系：等长（流式异或）或按块膨胀（分组+填充）还原方法论：四步走第一步：圈定算法边界hook