爱加密加固产品原理分析_定制版

一、背景

一、背景

最近朋友让我帮忙对他们银行APP进行黑盒分析,检测其安全性，探未知程序漏洞与安全性测试，提升业务整体安全能力，我拿到APP后进行安装抓包后发现都是加密传输的，用JEB进行反编译找数据组合的地方，发现APP用某加固了，所以有了此文。

二、整体框架

主要对DEX整体加密、DEX代码分离运行时解密还原，java方法native化，大致框架如下图2-1所示：

                        图2-1

三、SO保护壳分析

3.1、so层壳流程分析

壳入口点：

LOAD:C5FD5960                               EXPORT .init_proc

从壳入口点特征可以大致判断出是UPX，我尝试通过upx -d进行脱壳出现异常，修改特征为upx!还是不能正常脱壳，应该是被变异了，考虑通过IDA进行动态调试脱壳。

dump so

将断点断在linker中调用壳入口的地方，启动调试，如图3-1所示：

                        图3-1

壳执行完成将解压完代码在内存中dump出来，如图3-1-2所示

                        图3-1-2

3.2、so层壳脱壳与修复

修复Elf32_Off、修复shdr、修复phdr、修复重定位，如图3-2所示：

                        图3-2

修复后可以正常反编译，代码有ollvm混淆，字符串加密，如图3-2-1所示：

                        图3-2-1

四、DEX保护壳分析

4.1、Jni_onLoad

Jni_onLoad主要就是动态注册几个Native方法，代码如下：

jint JNI_OnLoad(JavaVM *vm, void *reserved)

注册的native方法：

l(Landroid/app/Application;Ljava/lang/String;)Z

4.2、java层到native层

在壳的java层重写了android.app.AppComponentFactory类的几个关键方法，其中instantiateClassLoader是比较核心的，它最终会走到Native方法al中。

  @Override  // android.app.AppComponentFactory

4.3、反调试

反射调用isDebuggerConnected

.text&ARM.extab:C52C8060                               isDebuggerConnected_sub_C608A060

检测模拟器

.text&ARM.extab:C52C45A0                               check_qemu_anitdbg_sub_C60B05A0

检测特征:

init.svc.qemud

检测脱壳机与frida

.text&ARM.extab:C52C60B8                               check_frida_Youpk_sub_C60B20B8

检测特征:

_ZN3art8Unpacker12dumpAllDexesEv

检测调试器进程状态与调试端口

.text&ARM.extab:C52C42EC                               anitdbg1_sub_2F2EC

过反调试的方法就是直接path返回。

4.4、解密指令资源

读取ijiami.ajm

.text&ARM.extab:C52B9E3C                               Read_ijiami.ajm_sub_C2167E3C

解密解析指令

.text&ARM.extab:C52E924E 09 9D                         LDR             R5, [SP,#0x48+ptr]

4.5、hook关键方法

hook类加载方法

art::ClassLinker::LoadMethod

4.6、读取DEX资源文件解密并加载DEX

读取ijiami.dat并解密出dex

.text&ARM.extab:C52DA440                               read_ijiami.dat_sub_C60CE440 

这时候dump出内存中的dex大部分的方法指令被抽了，还有部分是被native。如图4-6-1所示:

                        图4-6-1

内存中加载dex

int __fastcall sub_C60E5120(int a1, int a2)

4.7、方法指令还原

判断是否为要修复

.text&ARM.extab:C52BDA04                               hook_ClassLinker_LoadMethod_sub_C52BDA04

修复指令

根据Debug info定位到指令，获取指令解密

.text&ARM.extab:C52AA9D2                               getDecCode_sub_C20E39D2

修复指令

.text&ARM.extab:C52E7F34                               ; r0:解密后方法指令,R1:方法地址

被抽走后的指令存储格式：

6C C6 FF 03   37 1E 38 00  08 00 00 00   xxxxxxx

五、Native原理分析

主要是通过解析smali代码进行了通过JNI反射调用等价的语义转换,转为了C代码，执行时通过FindClass、GetStaticMethodID、GetMethodID、CallxxxMethod。
我是通过JNItrace来分析，如图5-1所示：

                        图5-1

六、总结

壳整体是指令抽取加方法native化二者结合，所有被抽走的指令还原后dump出来也能分析出80%左右的代码，其它被native化的用JNItrace配合分析，所以用该加固方案客户端代码安全性一般。接下来就可以继续进行APP渗透分析。