-
-
[原创]分析一下梆x加固
-
发表于: 2021-3-2 20:11
-
这个样本是年初自己拿到官网去加固，回来没有直接dump就直接分析了。可能是我的demo代码太少了就一句log.结果，分析了几天，发现这个样本没抽取。。。。但是还是简单记录一下，感兴趣的小伙伴可以看看。文章中若有出错的地方，请大佬们指正，然后由于是没抽取的版本，可能有些校验之类的没有调试到，还请多多包涵.
Java层 先定位Application
so层看一下
调试了一段时间，发现和upx特征很相似，所以也按upx的通用方法进行脱壳，下面是修复so的方法。
断点:0xA38F0（mprotect）
进行dump被压缩的segment。，第一个就是起始地址，第二个参数为被压缩的segment原大小。根据原大小和起始地址，可以dump出解压后的内容，然后本地进行修复。
修复流程基本是固定的，主要就是把解压缩后的内容，填充回去，这边篇幅原因，修复之前已经写过了，就直接已资源的形式放到文章末尾了。。关于最后函数的真实地址，可以直接断点linker执行init的时机（脚本里面有），F7后面就是原来so init函数的真实地址，可以选择性的修复回去。
idapython也会在文章末尾给出。注:目前脚本中的偏移地址都是根据Android6.0.1来的
init_array在修复后so的偏移sub_E4E8
经过一段时间分析，没发现特别重要的，主要是做了一些初始化，比如libc中相关函数的初始化.....
UPX修复好之后，JNI_ONLOAD已经暴露出来了，看一下代码执行流程图
比较明显，加了不是很复杂的ollvm，IDA 7.5 F5后可以看到大致代码的逻辑，就是很多控制流平坦化，调试的时候比较耗时间。
字符串基本都是加密的，不过到时候用我的idb，已经都标注好了
这个阶段主要是做初始化，例如初始化一些后面常用libc函数的地址，初始化一些后面会用到的私有目录、sdcard目录等等......，和一些兼容性的处理(根据不同的机型，不同的Android版本号).
第二阶段是比较重要的一个阶段，主要做了一些动态注册Java层函数，与dex的初始化(包括拷贝assets，以及load到内存)，hook一些系统函数的操作，下面详细介绍一下这个流程. 主要偏移从0x1EA1C开始。
注册基本都在sub_126BC函数中:
注册函数详情:
有个单独注册的函数
定位偏移0x1F1F0
上面进行一系列校验后，下面就开始走copy流程了
文件本地落地
执行好后，可以看到私有目录多了文件
Hook API实现在pECFD6C6E0567ABA6034040D903F38908这个函数中
主要对libc、libart进行了hook
例如:sub_33B08函数中libart下的hook:3art15DexFileVerifier6Verify、3art7DexFile10OpenMemory等
sub_392E8函数中主要是libc相关的hook: write、read、mmap、munmap等
定位函数sub_15928
先构造path
JNI调用java层加载dex
java层的实现
加载后可以看到，dex已经到内存中了
其实后面还有一些流程，但是一看没有抽取，发现自己这个版本不太对劲，瞬间没有动力分析下去了。
由于没抽取，所以脱壳还是比较简单，这里说一句，本身用来加载的dex的落地文件是不规则的，个人猜测是通过fread和fwrite进行解密的，但是没去验证.
执行完sub_15928之后，对maps下classes.jar的地址进行dump就可以了。
sub_17218:签名校验
[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
强
|
|
|
|
|
|
我记得之前是有的。但是最近加的都没有了。。。 可能是我的demo比较短小的原因？ |
|
|
mark
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
好，我改一下。写错了 
|
|
|
网上找了一个最新dexhelper加固的壳 https://app.mi.com/details?id=com.hn.catv&ref=search |
|
|
好的老哥，安排。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
搞定了？ |
|
|
|
|
|
|
