加固特征

• 商业加固壳：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，规律未明）

已尝试

求助

libDexHelper.so 中签名/完整性校验在哪个函数？怎么 patch？

可能方向：

• 从 APK 文件某 offset 读取证书 hash 与硬编码值比对
• RC4 解密 key 由证书数据派生
• 0x33f8 函数中某处隐式比对了 APK 签名块的某段数据

如果有 secneo 加固经验的师傅看过类似版本（特征：导出 signatrueCheck typo + libc_malloc 16MB 多 dex），希望能给个方向。

工作模式

• 附件仅提供 libDexHelper.so（1.1MB），原 APK 因 NDA 无法外发
• 师傅交付 patched libDexHelper.so（说明改了哪些字节即可）
• 我本地拿原 APK 替换 .so 后重签验证
• 验收标准：重签 APK 装上能正常启动到登录页（不再 0x0b4c 崩溃）

传播安全知识、拓宽行业人脉——看雪讲师团队等你加入！