-
-
[原创]分析一下X加密
-
发表于: 2021-5-9 14:54
-
本地环境依然是6.0.1的系统，这应该是最后一个分析的抽取类型的壳，后面会正式进入VMP的分析，文章没有分析的太透彻，主要还是以脱壳为主。文中ida中出现的字段和函数名可能根据自己的理解被修改过，也可能出现错误，还请各位大佬多多担待，并且指正，由于某些原因最终的脱壳脚本没办法给大家提供，但是会有思路，还请大家多多包涵.
首先，这个壳有点不太一样
大家通过看上面图片可以发现，这个应用的dex抽取过后和壳打到一起了。所以后面就不会有再去加载dex的操作。OK，下面正式开始分析
定位s.h.e.l.l.S
s.h.e.l.l.N->静态块
之后进入so层的分析
调试的话，直接定位linker，调试一下.init_proc
过掉UND之后，可以开始dump了。
发现并不是从ELF头开始的，而是0x10000起始的。所以直接修复了
我采用新建一个2进制文件，先将0x10000之前的数据copy进去，后面再拼接此dump出的数据，然后实际大小，是dump出的大小加上前面的数据得出总大小
然后把数据追加到新创建的so中，注意对齐
由于我并不需要把so完美修复好，我本地修复主要是动态调试有个对照，所以这2个segment修复后，就可以看到大致的代码了。
init_array做了保护，被编译器拆分成很多函数，我分析的时候几乎是一个一个看的，总结出来了，init_array主要做2个事情，第一，字符串解密，并保存；第二，反调试，下面简单介绍一下主要流程.
前面若干个函数主要做了一些字符串的解密，类似于下图
定位sub_12BDC:
兼容性处理与函数地址初始化
定位sub_2CB80
这函数主要做反调试
这个函数并不是很长，通过分析，核心做了2个事情。(这里说一下)
初始化一些数据:例如: 机型相关的数据：HARDWARE,MODEL,RELEASE,sdk_version等等（这个是为了兼容性考虑，后面逻辑会有一些判断），applicationInfo，processName，sourceDir, 待使用的文件路径，和一些Java层的class名字，最终都会保存在一个全局结构体中，和乐固类似。
Java层的函数动态注册: 其中主要涉及到如下函数
**N:l->sub_3C02C
N:r->sub_3EF5C
N:ra->sub_3F46C**
下面做简单分析，定位sub_3AB48(JNI_ONLOAD核心实现在这里)
JNI_ONLOAD走完了，下面继续回到Java层，看看调用了哪个native函数
这个函数有很多的兼容性的操作.
这里hook了非常多的art的函数，我们比较关注的,定位sub_26BAC, 壳的还原时机就是hook了这个loadMethod函数
后面还有一些逻辑，不过到这里，这个壳已经可以脱了。
定位sub_27034
然后进入sub_51CD8开始真正的填充
init_array已经有3中反调试了
后面还有，但是我idb丢失了一次，这个忘记了，大家到时候自己调试一下在sub_2D6CC
检测是否有/data/dexname
尝试env->loadClass("cn/youlor/Unpacker")
检测是否存在“/data/local/tmp/unpacker.config”
检测是否存在fart
检测/data/local/tmp/re.frida.server
然后有个专门的线程，检测maps中的内容，检测了如下字符串
com.android.reverse-
/data/local/tmp/libFupk3.so
xposed.Fdex2
/system/bin/app_process32_xposed
xposed.installer
app_process64_xposed
libxposed_art.so
io.va.exposed
io.virtualapp.sandvxposed
libriru_
com.saurik.substrate
re.frida.server
mapp.rm-
_frida-agent.so
com.example.FunDex-
经过下面一段脚本的执行，可以直接F9让应用完美运行起来
比较抱歉，这边由于某些原因，最终的脚本不能给到大家，下面说一下思路。
大家要先仔细调试一下sub_27034这个函数，就知道dump哪里了，很明显。
根据上面壳本身的还原逻辑，我们可以直接从内存中dump出3段数据，
第一段是真正的opcode相关信息存放的数据段，例如opcode的长度，以及真正的opcode。
后面2段是存放有关debuginfo相关的数据，例如debuginfo的值，以及当前debuginfo在第一段数据中对应的起始地址。
然后我们还需要保存当前3段数据的起始地址，因为这些数据dump出来的时候，存放的都是实际地址，所以我们需要减去起始地址，纯计算偏移去做。
这里用py脚本解析DexFile就好。把每个code_item的debuginfo保存到文件，这里是否保存到文件取决于大家最终的修复脚本用py还是C，我是用C的，但是我的解析脚本是py，所以保存文件中给C解析.
这里还原大家一定要直接看指令，不要F5，不要F5，不要F5！
1.还原sub_152D2
2.还原sub_51CD8
脱壳前:
脱壳后:
[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！
