[求助]某商业加固壳 libDexHelper.so 的签名校验 patch

加固特征

商业加固壳：secneo / 梆梆系 (libDexHelper.so + libRiskStub.so + libbangcle_risk.so 三件套)
ARM64 only（测试机 MIUI 13 / Android 13）
libRiskStub.so 内含 _Z14signatrueCheckv（typo "signatrue"）导出符号

已完成的工作
1. 业务 dex 脱壳 ✅
通过 dd if=/proc/PID/mem 从主进程 heap 区（[anon:libc_malloc] 160MB 段）成功 dump 8 个真实业务 dex 共约 110MB，baksmali 反编译完整。
2. libRiskStub.so 内部签名校验已绕过 ✅
反汇编发现导出符号 _Z14signatrueCheckv，函数 prologue 替换为 mov w0, wzr; ret 即可。但实测此函数根本没执行到——壳层在更早就崩了。
3. libDexHelper.so 完整反编译 ✅
Ghidra 11.4 headless 模式，对 init_array[0] (offset 0x4780) + init_array[1] (0x2b10) + 主初始化 0x33f8 等 9 个入口手动 CreateFunctionCmd，最终 decompile 出 56 个 C 函数。
确认 init 流程：

解析 /proc/self/maps 找当前 .so 的 base
反向找 ELF magic（0x464C457F）确定加载基址
dlopen("libc.so") + dlsym("sscanf") 获取函数指针（绕过静态导入检测）
open(self_apk_path, O_RDONLY)
pread(fd, &DAT_xxx, 0x14, offset) 读 20 字节（疑似 RC4 key）
调用 FUN_00103184（RC4 流密码解密：标准 KSA + PRGA，16 字节 key）
解密结果 mmap 到内存供 ART 使用

卡住的地方
重签 APK（仅替换证书，保留所有原 ZIP entries + v1+v2+v3 签名）→ 启动立即 SIGSEGV：
Cause: null pointer dereference
PC = 0x0000000000000b4c
LR = 0
SP = 0
x1=x8=x10=x19=0xb6a28b4e (同值传播)
x9=x12=0xb4c
x2=0xfff (掩码)

backtrace:
#00 pc 0x0b4c <unknown>
#01 pc 0 <unknown>

关键观察：

LR/SP 都是 0，明显是壳故意制造的 stack-smash 假崩溃——真实校验失败位置在 backtrace 之外
崩溃时只有 libDexHelper.so 加载到内存（其他 .so 都还没被加载）
libDexHelper.so 内没有 "signature" / "cert" 等明文字符串，没有显式 strcmp 比对签名
主初始化函数有 5 个 strcmp 但都是 /proc/self/maps 解析用，不是签名
0x0b4c 不是任何指令的立即数——动态计算（0xb6a28b4e & 0xfff = 0xb4e，跟 0xb4c 差 2，规律未明）

已尝试


方案
结果


Frida hook
被 secneo 检测，立即 SIGSEGV (fault 0x79c)


BlackDex / frida-fart
同样被检测


Magisk DenyList 隐藏 root
原版 APK 能跑，重签 APK 仍崩——说明跟 root 检测无关


patch libRiskStub.so::signatrueCheck
该 .so 根本没加载就崩了


仅添加 v2/v3 签名（保留原 META-INF + 不改 zip 结构）
仍崩


apksigner sign（v1+v2+v3 全开）
仍崩

---
来源: 看雪论坛
原文链接: https://bbs.kanxue.com/thread-291144.htm