梆x加固分析

前言

这个样本是年初自己拿到官网去加固，回来没有直接dump就直接分析了。可能是我的demo代码太少了就一句log.结果，分析了几天，发现这个样本没抽取。。。。但是还是简单记录一下，感兴趣的小伙伴可以看看。文章中若有出错的地方，请大佬们指正，然后由于是没抽取的版本，可能有些校验之类的没有调试到，还请多多包涵.

0x0 对样本进行简单分析

Java层 先定位Application

so层看一下

调试了一段时间，发现和upx特征很相似，所以也按upx的通用方法进行脱壳，下面是修复so的方法。

0x1 so脱壳与修复

获取解压缩后的segment数据

断点:0xA38F0（mprotect）

进行dump被压缩的segment。，第一个就是起始地址，第二个参数为被压缩的segment原大小。根据原大小和起始地址，可以dump出解压后的内容，然后本地进行修复。

本地修复

修复流程基本是固定的，主要就是把解压缩后的内容，填充回去，这边篇幅原因，修复之前已经写过了，就直接已资源的形式放到文章末尾了。。关于最后函数的真实地址，可以直接断点linker执行init的时机（脚本里面有），F7后面就是原来so init函数的真实地址，可以选择性的修复回去。

修复后

0x2 搭建一个调试环境

1. 我这里大概开2个IDA，一个用来打开修复后的so记录日志，另一个用来动态调试.
2. 由于修复后的so没办法直接运行，所以只能直接动态调试原包，每次定位init_array
3. 快速定位上一次调试的地址
4. 对ITE指令做一些特殊的处理

idapython也会在文章末尾给出。注:目前脚本中的偏移地址都是根据Android6.0.1来的

0x3 init_array

init_array在修复后so的偏移sub_E4E8

经过一段时间分析，没发现特别重要的，主要是做了一些初始化，比如libc中相关函数的初始化.....

0x4 JNI_ONLOAD

简介

UPX修复好之后，JNI_ONLOAD已经暴露出来了，看一下代码执行流程图

比较明显，加了不是很复杂的ollvm，IDA 7.5 F5后可以看到大致代码的逻辑，就是很多控制流平坦化，调试的时候比较耗时间。

字符串基本都是加密的，不过到时候用我的idb，已经都标注好了

第一阶段

这个阶段主要是做初始化，例如初始化一些后面常用libc函数的地址，初始化一些后面会用到的私有目录、sdcard目录等等......，和一些兼容性的处理(根据不同的机型，不同的Android版本号).

第二阶段

第二阶段是比较重要的一个阶段，主要做了一些动态注册Java层函数，与dex的初始化(包括拷贝assets，以及load到内存)，hook一些系统函数的操作，下面详细介绍一下这个流程. 主要偏移从0x1EA1C开始。

注册Java层的native函数

注册基本都在sub_126BC函数中:

注册函数详情:

有个单独注册的函数

操作assets目录下的资源

定位偏移0x1F1F0

上面进行一系列校验后，下面就开始走copy流程了

文件本地落地

执行好后，可以看到私有目录多了文件

Hook一些函数

Hook API实现在pECFD6C6E0567ABA6034040D903F38908这个函数中

主要对libc、libart进行了hook

例如:sub_33B08函数中libart下的hook:3art15DexFileVerifier6Verify、3art7DexFile10OpenMemory等

sub_392E8函数中主要是libc相关的hook: write、read、mmap、munmap等

加载dex

定位函数sub_15928
先构造path

JNI调用java层加载dex

java层的实现

加载后可以看到，dex已经到内存中了

其实后面还有一些流程，但是一看没有抽取，发现自己这个版本不太对劲，瞬间没有动力分析下去了。

0x5 脱壳

由于没抽取，所以脱壳还是比较简单，这里说一句，本身用来加载的dex的落地文件是不规则的，个人猜测是通过fread和fwrite进行解密的，但是没去验证.

执行完sub_15928之后，对maps下classes.jar的地址进行dump就可以了。

0x6 一些检测

sub_17218:签名校验

sub_18DF4:Hook Android日志

sub_49794:检测FART

eBPF安全开发与攻防对抗