本帖最后由 15221329862 于 2024-03-17 00:05 编辑
在去年9月的时候,我就想研究一下apk的加固,在网上逛了一圈,感觉有一个加固不错,所以先选它啦,写了一个测试apk丢到这个加固里面加固了一下 这里我用的是这个加固的免费版(因为付费版太贵啦) 本来计划着去年分析完的,但是总是抽不出一段完整的时间来所以就拖到了现在,终于最近因为过年赋闲在家,就花了几天分析了一下,感觉这几天探索加固壳的过程真是充满了惊喜和乐趣呢~
2024年3月8号记: 距离上次看这个加固已经半个月啦,今天正想着自己要做什么事情的时候,到博客看了眼TODOlist,突然发现咦我是不是还没看过dex的解密算法长什么样?所以今天就把这个给做完了,不得不说逆向真的是消磨无聊时间最有效的方法哈哈哈
包名:com.oacia.apk_protect 入口:com.stub.StubApp 我们从AndroidManifest.xml中可以得知,这个加固的入口是com.stub.StubApp,所以我们就先进到apk的入口进行分析 
在这个入口类中,不仅有常规的onCreate()函数,还有一个函数值得注意,他就是attachBaseContext(Context context) 
Application 的onCreate和attachBaseContext是 Application 的两个回调方法，通常我们会在其中做一些初始化操作,attachBaseContext 在onCreate之前执行 其中出现的字符串经过了加密混淆操作,加密函数如下,算法是将所有的字符与16进行异或 
我们写个jeb脚本把加密字符串解密来方便后续的静态分析 # coding=utf-8
from com.pnfsoftware.jeb.client.api import IScript, IconType, ButtonGroupType
from com.pnfsoftware.jeb.core import RuntimeProjectUtil
from com.pnfsoftware.jeb.core.units.code.java import IJavaSourceUnit
from com.pnfsoftware.jeb.core.units.code import ICodeUnit, ICodeItem
from com.pnfsoftware.jeb.core.output.text import ITextDocument
from com.pnfsoftware.jeb.core.units.code.java import IJavaSourceUnit, IJavaStaticField, IJavaNewArray, IJavaConstant, IJavaCall, IJavaField, IJavaMethod, IJavaClass
from com.pnfsoftware.jeb.core.events import JebEvent, J
from com.pnfsoftware.jeb.core.util import DecompilerHelper
# 解密字符串函数的类名以及方法名
methodName = ['Lcom/qihoo/util/a;', 'a']
class dec_str_jiagu(IScript):
def run(self, ctx):
print('start deal with strings')
self.ctx = ctx
engctx = ctx.getEnginesContext()
if not engctx:
print('Back-end engines not initialized')
return
projects = engctx.getProjects()
if not projects:
print('There is no opened project')
return
units = RuntimeProjectUtil.findUnitsByType(projects[0], IJavaSourceUnit, False)
for unit in units:
javaClass = unit.getClassElement()
print('[+] decrypt:' + javaClass.getName())
self.cstbuilder = unit.getFactories().getConstantFactory()
self.processClass(javaClass)
unit.notifyListeners(JebEvent(J.UnitChange))
print('Done.')
def processClass(self, javaClass):
if javaClass.getName() == methodName[0]:
return
for method in javaClass.getMethods():
block = method.getBody()
i = 0
while i < block.size():
stm = block.get(i)
self.checkElement(block, stm)
i += 1
def checkElement(self, parent, e):
try:
if isinstance(e, IJavaCall):
mmethod = e.getMethod()
mname = mmethod.getName()
msig = mmethod.getSignature()
if mname == methodName[1] and methodName[0] in msig:
v = []
for arg in e.getArguments():
if isinstance(arg, IJavaConstant):
v.append(arg.getString())
if len(v) == 1:
decstr = self.decryptstring(v[0])
parent.replaceSubElement(e, self.cstbuilder.createString(decstr))
for subelt in e.getSubElements():
if isinstance(subelt, IJavaClass) or isinstance(subelt, IJavaField) or isinstance(subelt, IJavaMethod):
continue
self.checkElement(e, subelt)
except:
print('error')
def decryptstring(self, string):
src = []
for index, char in enumerate(string):
src.append(chr(ord(char) ^ 16))
return ''.join(src).decode('unicode_escape')
解密后的效果如下 
我们往下进行分析,可以知道attachBaseContext的第一个作用是根据目标手机的架构加载libjiagu_xxx.so如图 
这些so在assets目录下 
在加载完libjiagu_xxx.so之后,还调用了DtcLoader类进行初始化,这里使用的jadx的反编译结果,因为jeb没有反编译出DtcLoader.init();方法来 
DtcLoader类如图所示
当DtcLoader类被加载到JVM中时,会去加载libjgdtc.so,如果加载失败,则会尝试从/data/app/com.oacia.apk_protect/lib/arm64/libjgdtc.so或者/data/data/com.oacia.apk_protect/lib/libjgdtc.so中去加载这个so 但是当我们去进入到这两个目录进行寻找时,却发现没有这个libjgdtc.so存在 
所以我们的分析重点是在libjiagu.so中,这里我选取了arm64架构的so文件libjiagu_a64.so进行分析 我们使用ida分析libjiagu_a64.so,发现导入表和导出表都没有内容,既然是这种情况,那么应该是在so装载进内存时导入导出表才会去进行相应的链接操作 
所以我们可以先用frida把这个so给dump下来 首先我们在手机上运行一下frida server PS D:\frida> adb shell
blueline:/ $ su
blueline:/ # cd /data/local/tmp
blueline:/data/local/tmp # ./fs -l 0.0.0.0:1234
随后做一下端口转发 adb forward tcp:1234 tcp:1234
frida命令行语句如下 frida -H 127.0.0.1:1234 -l .\hook.js -f "com.oacia.apk_protect"
注入如下脚本 function my_hook_dlopen(soName = '') {
Interceptor.attach(Module.findExportByName(null, "android_dlopen_ext"),
{
onEnter: function (args) {
var pathptr = args[0];
if (pathptr !== undefined && pathptr != null) {
var path = ptr(pathptr).readCString();
if (path.indexOf(soName) >= 0) {
this.is_can_hook = true;
}
}
},
onLeave: function (retval) {
if (this.is_can_hook) {
dump_so("libjiagu_64.so");
}
}
}
);
}
function dump_so(so_name) {
var libso = Process.getModuleByName(so_name);
console.log("[name]:", libso.name);
console.log("[base]:", libso.base);
console.log("[size]:", ptr(libso.size));
console.log("[path]:", libso.path);
var file_path = "/data/data/com.oacia.apk_protect/" + libso.name + "_" + libso.base + "_" + ptr(libso.size) + ".so";
var file_handle = new File(file_path, "wb");
if (file_handle && file_handle != null) {
Memory.protect(ptr(libso.base), libso.size, 'rwx');
var libso_buffer = ptr(libso.base).readByteArray(libso.size);
file_handle.write(libso_buffer);
file_handle.flush();
file_handle.close();
console.log("[dump]:", file_path);
}
}
setImmediate(my_hook_dlopen("libjiagu_64.so"));
随后我们使用SoFixer修复一下这个so,这里的-m参数即这个so在内存中的base基地址 .\SoFixer-Windows-64.exe -s .\libjiagu_64.so_0x74a2845000_0x274000.so -o
.\libjiagu_64_0x74a2845000_0x274000_fix.so -m 0x74a2845000 -d
修复完成后,导入表和导出表就恢复了 
首先我们去hook一下打开so的函数 function hook_dlopen() {
Interceptor.attach(Module.findExportByName(null, "android_dlopen_ext"),
{
onEnter: function (args) {
var pathptr = args[0];
if (pathptr !== undefined && pathptr != null) {
var path = ptr(pathptr).readCString();
console.log("load " + path);
}
}
}
);
}
setImmediate(hook_dlopen)
日志如下,所以反调试是在libjiagu_64.so中 load libstats_jni.so
load /data/app/~~P6meiEqXSQZrP2ChUgVgOg==/com.oacia.apk_protect-ezyVSLdtBZmLTZejgPlSoQ==/oat/arm64/base.odex
load /data/data/com.oacia.apk_protect/.jiagu/libjiagu_64.so
然后去hook打开文件的函数open function my_hook_dlopen(soName = '') {
Interceptor.attach(Module.findExportByName(null, "android_dlopen_ext"),
{
onEnter: function (args) {
var pathptr = args[0];
if (pathptr !== undefined && pathptr != null) {
var path = ptr(pathptr).readCString();
if (path.indexOf(soName) >= 0) {
this.is_can_hook = true;
}
}
},
onLeave: function (retval) {
if (this.is_can_hook) {
hook_open();
}
}
}
);
}
function hook_open(){
var pth = Module.findExportByName(null,"open");
Interceptor.attach(ptr(pth),{
onEnter:function(args){
this.filename = args[0];
console.log("",this.filename.readCString())
},onLeave:function(retval){
}
})
}
setImmediate(my_hook_dlopen,"libjiagu");
日志如下 
这里我们发现了/proc/self/maps,这是常见的反调试,要绕过这个检测,我们可以备份一个正常的maps文件,然后用frida去hook open函数,如果匹配到字符串maps,就将字符串重定向到我们备份的maps文件 首先我们正常打开一次加壳的apk,然后使用下列命令备份maps cp /proc/self/maps /data/data/com.oacia.apk_protect/maps
然后我们注入如下frida脚本 function my_hook_dlopen(soName = '') {
Interceptor.attach(Module.findExportByName(null, "android_dlopen_ext"),
{
onEnter: function (args) {
var pathptr = args[0];
if (pathptr !== undefined && pathptr != null) {
var path = ptr(pathptr).readCString();
if (path.indexOf(soName) >= 0) {
this.is_can_hook = true;
}
}
},
onLeave: function (retval) {
if (this.is_can_hook) {
hook_proc_self_maps();
}
}
}
);
}
function hook_proc_self_maps() {
const openPtr = Module.getExportByName(null, 'open');
const open = new NativeFunction(openPtr, 'int', ['pointer', 'int']);
var fakePath = "/data/data/com.oacia.apk_protect/maps";
Interceptor.replace(openPtr, new NativeCallback(function (pathnameptr, flag) {
var pathname = Memory.readUtf8String(pathnameptr);
console.log("open",pathname);
if (pathname.indexOf("maps") >= 0) {
console.log("find",pathname,",redirect to",fakePath);
var filename = Memory.allocUtf8String(fakePath);
return open(filename, flag);
}
var fd = open(pathnameptr, flag);
return fd;
}, 'int', ['pointer', 'int']));
}
setImmediate(my_hook_dlopen,"libjiagu");
但是当注入这段脚本后,进程由于非法内存访问而退出了,这说明加固壳不仅读取maps文件,并且会尝试访问maps文件中所记录的文件或内存映射.这里由于frida注入后重启apk,但是备份的maps文件中记录的是先前的映射起始地址(这块内存在关闭apk后就被抹去了),所以当壳尝试访问其中的映射时产生了非法内存访问从而让进程崩溃 
这里我的解决方式是将上述frida代码中的fakePath赋值为一个不存在的文件例如/data/data/com.oacia.apk_protect/maps_nonexistent,来让壳没有内容可以访问 修改完fakePath后重新注入代码,这个打印出来的日志可以说非常有意思,我们来看一下,相比hook open之前的日志,我们成功的让这个加固壳释放出了dex 
然而这个壳似乎是又发现了些什么异常,随后赶紧让app退出了,但是由于退出的太过仓促,它甚至还没有来得及把dex从文件夹中删除 
用010editor打开classes.dex,发现前几位并不是dex的魔术头,说明这个dex还没有被解密,不过现在我们只需要分析dex如何被壳从内存中释放出来的过程就可以了~ 
如何可以定位到是什么位置调用了open函数来打开classes.dex呢? 很简单,打印一下堆栈就可以了 假如我们使用常规的frida打印堆栈代码,即使用DebugSymbol.fromAddress函数来判断地址所在的so的位置,那么进程是会报错退出的 console.log('RegisterNatives called from:\\n' + Thread.backtrace(this.context, Backtracer.FUZZY).map(DebugSymbol.fromAddress).join('\\n') + '\\n');
所以这里DebugSymbol.fromAddress所实现的逻辑需要自己编写,即下方的addr_in_so函数 function addr_in_so(addr){
var process_Obj_Module_Arr = Process.enumerateModules();
for(var i = 0; i < process_Obj_Module_Arr.length; i++) {
if(addr>process_Obj_Module_Arr[i].base && addr<process_Obj_Module_Arr[i].base.add(process_Obj_Module_Arr[i].size)){
console.log(addr.toString(16),"is in",process_Obj_Module_Arr[i].name,"offset: 0x"+(addr-process_Obj_Module_Arr[i].base).toString(16));
}
}
}
function hook_proc_self_maps() {
const openPtr = Module.getExportByName(null, 'open');
const open = new NativeFunction(openPtr, 'int', ['pointer', 'int']);
var fakePath = "/data/data/com.oacia.apk_protect/maps_nonexistent";
Interceptor.replace(openPtr, new NativeCallback(function (pathnameptr, flag) {
var pathname = Memory.readUtf8String(pathnameptr);
console.log("open",pathname);//,Process.getCurrentThreadId()
if (pathname.indexOf("maps") >= 0) {
console.log("find",pathname+", redirect to",fakePath);
var filename = Memory.allocUtf8String(fakePath);
return open(filename, flag);
}
if (pathname.indexOf("dex") >= 0) {
Thread.backtrace(this.context, Backtracer.FUZZY).map(addr_in_so);
}
var fd = open(pathnameptr, flag);
return fd;
}, 'int', ['pointer', 'int']));
}
function my_hook_dlopen(soName='') {
Interceptor.attach(Module.findExportByName(null, "android_dlopen_ext"),
{
onEnter: function (args) {
var pathptr = args[0];
if (pathptr !== undefined && pathptr != null) {
var path = ptr(pathptr).readCString();
//console.log(path);
if (path.indexOf(soName) >= 0) {
this.is_can_hook = true;
}
}
},
onLeave: function (retval) {
if (this.is_can_hook) {
hook_proc_self_maps();
}
}
}
);
}
setImmediate(my_hook_dlopen,'libjiagu');
于是我们得到了释放三个dex文件的堆栈回溯 
这里我们发现classes.dex与classes2.dex的堆栈回溯完全相同,并且classes3.dex的前半部分和前两个dex的堆栈一样,随后进程便又退出了 通过对堆栈的分析,我们可以发现三个dex应该是在一个循环中被依次加载的 接下来我们便跳转到堆栈所打印的偏移来进一步分析下 然而当我们跳转到堆栈回溯中的libjiagu_64.so的偏移0x19b780或者0x134598时,却发现这些地址的值都是0 
我们很快就能想到这里用到的技术应该是先将一块内存标记为可写可执行,随后将字节码填充进去,所以说,我们只需要在壳打开dex时,将此时的libjiagu_64.so从内存中dump下来就可以了 function dump_so(so_name) {
var libso = Process.getModuleByName(so_name);
console.log("[name]:", libso.name);
console.log("[base]:", libso.base);
console.log("[size]:", ptr(libso.size));
console.log("[path]:", libso.path);
var file_path = "/data/data/com.oacia.apk_protect/" + libso.name + "_" + libso.base + "_" + ptr(libso.size) + ".so";
var file_handle = new File(file_path, "wb");
if (file_handle && file_handle != null) {
Memory.protect(ptr(libso.base), libso.size, 'rwx');
var libso_buffer = ptr(libso.base).readByteArray(libso.size);
file_handle.write(libso_buffer);
file_handle.flush();
file_handle.close();
console.log("[dump]:", file_path);
}
}
var dump_once = false;//因为会打开三次dex,所以这里我们仅dump打开第一次dex时的libjiagu_64.so
function hook_proc_self_maps() {
const openPtr = Module.getExportByName(null, 'open');
const open = new NativeFunction(openPtr, 'int', ['pointer', 'int']);
var fakePath = "/data/data/com.oacia.apk_protect/maps_nonexistent";
Interceptor.replace(openPtr, new NativeCallback(function (pathnameptr, flag) {
var pathname = Memory.readUtf8String(pathnameptr);
console.log("open",pathname);//,Process.getCurrentThreadId()
if (pathname.indexOf("maps") >= 0) {
console.log("find",pathname+", redirect to",fakePath);
var filename = Memory.allocUtf8String(fakePath);
return open(filename, flag);
}
if (pathname.indexOf("dex") >= 0) {
if(!dump_once){
dump_once = true;
dump_so("libjiagu_64.so");
}
}
var fd = open(pathnameptr, flag);
return fd;
}, 'int', ['pointer', 'int']));
}
然后再去用SoFixer修复这个dump下来的so .\SoFixer-Windows-64.exe -s .\libjiagu_64.so_0x7a69829000_0x274000_open_classes.dex.so -o
.\libjiagu_64.so_0x7a69829000_0x274000_open_classes.dex_fix.so -m 0x7a69829000 -d
再次来到偏移0x19B780处,可以发现这块空内存已经被填充了数据 
接下来我们想知道的是究竟是从什么地方开始被填充了新的数据,所以我们可以用WinMerge来让填充和未填充数据的so进行比较看看,结果却有了惊人的发现,被填充的数据是从0xe7000开始的,它的开头竟然是ELF文件的魔数头!?这有意思了,那么就是一个so里面藏了另外一个so咯~ 
我们写个python脚本,把这个ELF从0x0e7000开始后面的所有字节都复制到新的文件里面 with open('libjiagu_64.so_0x7a69829000_0x274000_open_classes.dex.so','rb') as f:
s=f.read()
with open('libjiagu_0xe7000.so','wb') as f:
f.write(s[0xe7000::])
但是当把这个elf提取出来之后拿010editor看却发现program header table被加密了 
这就导致ida根本就无法进行正常的分析 
壳elf加载主elf,并且program header还被加密了,感觉这种形式很像是 自实现linker加固so 对于这种加固方式,壳elf在代码中自己实现了解析ELF文件的函数,并将解析结果赋值到soinfo结构体中,随后调用dlopen进行手动加载 来到ida里面在导入表对dlopen进行交叉引用,我们看到dlopen有5个交叉引用 
看到第二个交叉引用,来到sub_3C94函数,这个for循环看起来像是在用符号表通过dlopen加载依赖项 
向上面翻翻代码,看到这个switch就知道找对地方了,这里应该就是自实现linker来加载so的 
因为这和AOSP源码(android-platform\bionic\linker\linker.cpp)中的预链接(soinfo::prelink_image)这部分的操作极为的相似 
那接下来就在ida中导入soinfo相关的符号就可以啦 在ida中依次点击View->Open subviews->Local Types,然后按下键盘上的Insert将下面的结构体添加到对话框中 //IMPORTANT
//ELF64启用该宏
#define __LP64__ 1
//ELF32启用该宏
//#define __work_around_b_24465209__ 1
/*
//https://android.googlesource.com/platform/bionic/+/master/linker/Android.bp
架构为32位 定义__work_around_b_24465209__宏
arch: {
arm: {cflags: ["-D__work_around_b_24465209__"],},
x86: {cflags: ["-D__work_around_b_24465209__"],},
}
*/
//android-platform\bionic\libc\include\link.h
#if defined(__LP64__)
#define ElfW(type) Elf64_ ## type
#else
#define ElfW(type) Elf32_ ## type
#endif
//android-platform\bionic\linker\linker_common_types.h
// Android uses RELA for LP64.
#if defined(__LP64__)
#define USE_RELA 1
#endif
//android-platform\bionic\libc\kernel\uapi\asm-generic\int-ll64.h
//__signed__-->signed
typedef signed char __s8;
typedef unsigned char __u8;
typedef signed short __s16;
typedef unsigned short __u16;
typedef signed int __s32;
typedef unsigned int __u32;
typedef signed long long __s64;
typedef unsigned long long __u64;
//A12-src\msm-google\include\uapi\linux\elf.h
/* 32-bit ELF base types. */
typedef __u32 Elf32_Addr;
typedef __u16 Elf32_Half;
typedef __u32 Elf32_Off;
typedef __s32 Elf32_Sword;
typedef __u32 Elf32_Word;
/* 64-bit ELF base types. */
typedef __u64 Elf64_Addr;
typedef __u16 Elf64_Half;
typedef __s16 Elf64_SHalf;
typedef __u64 Elf64_Off;
typedef __s32 Elf64_Sword;
typedef __u32 Elf64_Word;
typedef __u64 Elf64_Xword;
typedef __s64 Elf64_Sxword;
typedef struct dynamic{
Elf32_Sword d_tag;
union{
Elf32_Sword d_val;
Elf32_Addr d_ptr;
} d_un;
} Elf32_Dyn;
typedef struct {
Elf64_Sxword d_tag; /* entry tag value */
union {
Elf64_Xword d_val;
Elf64_Addr d_ptr;
} d_un;
} Elf64_Dyn;
typedef struct elf32_rel {
Elf32_Addr r_offset;
Elf32_Word r_info;
} Elf32_Rel;
typedef struct elf64_rel {
Elf64_Addr r_offset; /* Location at which to apply the action */
Elf64_Xword r_info; /* index and type of relocation */
} Elf64_Rel;
typedef struct elf32_rela{
Elf32_Addr r_offset;
Elf32_Word r_info;
Elf32_Sword r_addend;
} Elf32_Rela;
typedef struct elf64_rela {
Elf64_Addr r_offset; /* Location at which to apply the action */
Elf64_Xword r_info; /* index and type of relocation */
Elf64_Sxword r_addend; /* Constant addend used to compute value */
} Elf64_Rela;
typedef struct elf32_sym{
Elf32_Word st_name;
Elf32_Addr st_value;
Elf32_Word st_size;
unsigned char st_info;
unsigned char st_other;
Elf32_Half st_shndx;
} Elf32_Sym;
typedef struct elf64_sym {
Elf64_Word st_name; /* Symbol name, index in string tbl */
unsigned char st_info; /* Type and binding attributes */
unsigned char st_other; /* No defined meaning, 0 */
Elf64_Half st_shndx; /* Associated section index */
Elf64_Addr st_value; /* Value of the symbol */
Elf64_Xword st_size; /* Associated symbol size */
} Elf64_Sym;
#define EI_NIDENT 16
typedef struct elf32_hdr{
unsigned char e_ident[EI_NIDENT];
Elf32_Half e_type;
Elf32_Half e_machine;
Elf32_Word e_version;
Elf32_Addr e_entry; /* Entry point */
Elf32_Off e_phoff;
Elf32_Off e_shoff;
Elf32_Word e_flags;
Elf32_Half e_ehsize;
Elf32_Half e_phentsize;
Elf32_Half e_phnum;
Elf32_Half e_shentsize;
Elf32_Half e_shnum;
Elf32_Half e_shstrndx;
} Elf32_Ehdr;
typedef struct elf64_hdr {
unsigned char e_ident[EI_NIDENT]; /* ELF "magic number" */
Elf64_Half e_type;
Elf64_Half e_machine;
Elf64_Word e_version;
Elf64_Addr e_entry; /* Entry point virtual address */
Elf64_Off e_phoff; /* Program header table file offset */
Elf64_Off e_shoff; /* Section header table file offset */
Elf64_Word e_flags;
Elf64_Half e_ehsize;
Elf64_Half e_phentsize;
Elf64_Half e_phnum;
Elf64_Half e_shentsize;
Elf64_Half e_shnum;
Elf64_Half e_shstrndx;
} Elf64_Ehdr;
/* These constants define the permissions on sections in the program
header, p_flags. */
#define PF_R 0x4
#define PF_W 0x2
#define PF_X 0x1
typedef struct elf32_phdr{
Elf32_Word p_type;
Elf32_Off p_offset;
Elf32_Addr p_vaddr;
Elf32_Addr p_paddr;
Elf32_Word p_filesz;
Elf32_Word p_memsz;
Elf32_Word p_flags;
Elf32_Word p_align;
} Elf32_Phdr;
typedef struct elf64_phdr {
Elf64_Word p_type;
Elf64_Word p_flags;
Elf64_Off p_offset; /* Segment file offset */
Elf64_Addr p_vaddr; /* Segment virtual address */
Elf64_Addr p_paddr; /* Segment physical address */
Elf64_Xword p_filesz; /* Segment size in file */
Elf64_Xword p_memsz; /* Segment size in memory */
Elf64_Xword p_align; /* Segment alignment, file & memory */
} Elf64_Phdr;
typedef struct elf32_shdr {
Elf32_Word sh_name;
Elf32_Word sh_type;
Elf32_Word sh_flags;
Elf32_Addr sh_addr;
Elf32_Off sh_offset;
Elf32_Word sh_size;
Elf32_Word sh_link;
Elf32_Word sh_info;
Elf32_Word sh_addralign;
Elf32_Word sh_entsize;
} Elf32_Shdr;
typedef struct elf64_shdr {
Elf64_Word sh_name; /* Section name, index in string tbl */
Elf64_Word sh_type; /* Type of section */
Elf64_Xword sh_flags; /* Miscellaneous section attributes */
Elf64_Addr sh_addr; /* Section virtual addr at execution */
Elf64_Off sh_offset; /* Section file offset */
Elf64_Xword sh_size; /* Size of section in bytes */
Elf64_Word sh_link; /* Index of another section */
Elf64_Word sh_info; /* Additional section information */
Elf64_Xword sh_addralign; /* Section alignment */
Elf64_Xword sh_entsize; /* Entry size if section holds table */
} Elf64_Shdr;
//android-platform\bionic\linker\linker_soinfo.h
typedef void (*linker_dtor_function_t)();
typedef void (*linker_ctor_function_t)(int, char**, char**);
#if defined(__work_around_b_24465209__)
#define SOINFO_NAME_LEN 128
#endif
struct soinfo {
#if defined(__work_around_b_24465209__)
char old_name_[SOINFO_NAME_LEN];
#endif
const ElfW(Phdr)* phdr;
size_t phnum;
#if defined(__work_around_b_24465209__)
ElfW(Addr) unused0; // DO NOT USE, maintained for compatibility.
#endif
ElfW(Addr) base;
size_t size;
#if defined(__work_around_b_24465209__)
uint32_t unused1; // DO NOT USE, maintained for compatibility.
#endif
ElfW(Dyn)* dynamic;
#if defined(__work_around_b_24465209__)
uint32_t unused2; // DO NOT USE, maintained for compatibility
uint32_t unused3; // DO NOT USE, maintained for compatibility
#endif
soinfo* next;
uint32_t flags_;
const char* strtab_;
ElfW(Sym)* symtab_;
size_t nbucket_;
size_t nchain_;
uint32_t* bucket_;
uint32_t* chain_;
#if !defined(__LP64__)
ElfW(Addr)** unused4; // DO NOT USE, maintained for compatibility
#endif
#if defined(USE_RELA)
ElfW(Rela)* plt_rela_;
size_t plt_rela_count_;
ElfW(Rela)* rela_;
size_t rela_count_;
#else
ElfW(Rel)* plt_rel_;
size_t plt_rel_count_;
ElfW(Rel)* rel_;
size_t rel_count_;
#endif
linker_ctor_function_t* preinit_array_;
size_t preinit_array_count_;
linker_ctor_function_t* init_array_;
size_t init_array_count_;
linker_dtor_function_t* fini_array_;
size_t fini_array_count_;
linker_ctor_function_t init_func_;
linker_dtor_function_t fini_func_;
/*
#if defined(__arm__)
// ARM EABI section used for stack unwinding.
uint32_t* ARM_exidx;
size_t ARM_exidx_count;
#endif
size_t ref_count_;
//怎么找不到link_map这个类型的声明...
link_map link_map_head;
bool constructors_called;
// When you read a virtual address from the ELF file, add this
// value to get the corresponding address in the process' address space.
ElfW(Addr) load_bias;
#if !defined(__LP64__)
bool has_text_relocations;
#endif
bool has_DT_SYMBOLIC;
*/
};
导入完成后按下Y键,将a1定义为soinfo* 
然后就可以看到这些符号了,但是看这些符号总感觉有些不太对劲,这里不应该出现a1[1]或者a1[2],所以我猜测这个soinfo有被魔改的痕迹 
虽然这个soinfo可能有被魔改了,我们还是从sub_3C94这个预链接相关函数入手好了,交叉引用发现sub_3C94是被sub_49F0调用 随后我们来到sub_49F0内调用sub_3C94函数的位置,向下看,进入sub_4918函数中 
sub_4918中调用了sub_5E6C,我们进入sub_5E6C
这个函数中出现了0x38这个数字,0x38是这个循环的步长 
0x38这个数字有什么特殊的含义吗?当然有了!! 我们把刚刚提取出来的elf用010editor打开,看到elf_header的phentsize这个字段,这个字段的含义是一个Program header table的长度,它正正好好也是0x38 
所以说在sub_5E6C中变量v5的类型应该是Elf64_Phdr *,我们直接重定义类型 
既然知道了真正的program header table就是在这个位置的,那我们直接在这个地方把program header table整个给dump下来不就行了 所以我们直接去hooksub_5E6C的三个传入的值 function hook_5E6C(){
var module = Process.findModuleByName("libjiagu_64.so");
Interceptor.attach(module.base.add(0x5E6C), {
// fd, buff, len
onEnter: function (args) {
console.log(hexdump(args[0], {
offset: 0,// 相对偏移
length: 0x38*0x6+0x20,//dump 的大小
header: true,
ansi: true
}));
console.log(args[1])
console.log(args[2])
console.log(`base = ${module.base}`)
},
onLeave: function (ret) {
}
});
}
上面的第一个hexdump就是program header table,我们可以用cyberchef将hexdump转成数组的形式 
0x6则对应着phnum,这表示共有6个program header table
0x793ca38000表示这个主ELF的基址,因为这个主ELF的位置在壳ELF基址的偏移0xe7000处,而最下面这行也已经打印出了壳ELF的基址为0x793c951000,0x793ca38000==0x793c951000+0xe7000等式成立
至此为止,我们拿到了解密之后的program header table,同时我们也知道了sub_5E6C传入的三个参数分别是phdr,phnum以及base 但是phdr成员命名是在soinfo偏移的0x0的位置 
那假如a1的类型就是soinfo*,为什么在sub_4918里面调用sub_5E6C传入的是偏移是232呢? 
所以soinfo*必定有被魔改,同时我们也可以在soinfo前填充一个大小为232的char类型数组看看是什么情况 
很好,这验证了我们对于soinfo*被魔改的猜测,因为在一切正常的情况之下,函数的调用应该是sub_5E6C(a1->phdr, a1->phnum, a1->base)才对 
但是我很想知道这个壳ELF究竟是如何被解密出来的,那么首先来看看主ELF的函数调用链是什么样子的吧~ 我写了一个ida插件来实现这个过程stalker_trace_so 在IDA中使用Edit->Plugins->stalker_trace_so后,在so所在的目录下会生成一个js脚本,我们用frida注入到apk中即可,需要注意的是so_name需要改成libjiagu_64.so 
打印出来的完整日志如下 call1:JNI_OnLoad
call2:j_interpreter_wrap_int64_t
call3:interpreter_wrap_int64_t
call4:getenv
call5:sub_13908
call6:inotify_add_watch
call7:sub_11220
call8:fopen
call9:sub_9DD8
call10:sub_E3E0
call11:strtol
call12:feof
call13:raise
call14:memset
call15:sub_C918
call16:sub_9988
call17:sub_9964
call18:sub_9AC4
call19:j_ffi_prep_cif
call20:ffi_prep_cif
call21:j_ffi_prep_cif_machdep
call22:ffi_prep_cif_machdep
call23:j_ffi_call
call24:ffi_call
call25:sub_1674C
call26:j_ffi_call_SYSV
call27:ffi_call_SYSV
call28:sub_167BC
call29:sub_1647C
call30:sub_163DC
call31:sub_9900
call32:sub_94BC
call33:inotify_init
call34:fmod
call35:strncpy
call36:_Z9__arm_a_1P7_JavaVMP7_JNIEnvPvRi
call37:sub_9E58
call38:sub_999C
call39:sub_10964
call40:j_lseek_1
call41:lseek
call42:sub_96E0
call43:sub_8000
call44:dlopen
call45:sub_60E0
call46:sub_6544
call47:sub_4B54
call48:sub_6128
call49:_ZN9__arm_c_19__arm_c_0Ev
call50:sub_A3EC
call51:sub_99CC
call52:sub_9944
call53:sub_6484
call54:sub_6590
call55:prctl
call56:sub_6698
call57:sub_9FFC
call58:j_lseek_3
call59:j_lseek_2
call60:j_lseek_0
call61:sub_9A90
call62:sub_5F20
call63:sub_6044
call64:sub_3574
call65:uncompress
call66:sub_49F0
call67:sub_5400
call68:sub_5478
call69:sub_5B08
call70:sub_5650
call71:sub_580C
call72:open
call73:atoi
call74:sub_3C94
call75:strncmp
call76:sub_4918
call77:sub_4000
call78:sub_41B4
call79:sub_35AC
call80:sigaction
call81:sub_5E6C
call82:sub_5444
call83:sub_633C
call84:sub_8130
call85:sub_4C70
call86:sub_825C
call87:sub_8B50
call88:sub_8ED4
call89:sub_8430
call90:interpreter_wrap_int64_t_bridge
call91:sub_9D60
call92:sub_166C4
call93:memcpy
call94:_Z9__arm_a_2PcmS_Rii
call95:j_ffi_prep_cif_var
call96:ffi_prep_cif_var
我们以sub_3C94为起点开始分析,因为这是我们通过dlopen交叉引用找到的自实现linker加固so的一个功能函数 对sub_3C94不断按下X查看交叉引用,得到如下的调用关系sub_4B54->sub_49F0->sub_3C94 sub_4B54可能被sub_8000或sub_8C74调用
我们将stalker_trace_so打印出来的内容中,提取关键的部分拿过来看看,说明sub_3B54是被sub_8000调用的 call43:sub_8000 <--
call44:dlopen
call45:sub_60E0
call46:sub_6544
call47:sub_4B54 <--
call48:sub_6128
call49:_ZN9__arm_c_19__arm_c_0Ev
call50:sub_A3EC
call51:sub_99CC
call52:sub_9944
call53:sub_6484
call54:sub_6590
call55:prctl
call56:sub_6698
call57:sub_9FFC
call58:j_lseek_3
call59:j_lseek_2
call60:j_lseek_0
call61:sub_9A90
call62:sub_5F20
call63:sub_6044
call64:sub_3574
call65:uncompress
call66:sub_49F0 <--
call67:sub_5400
call68:sub_5478
call69:sub_5B08
call70:sub_5650
call71:sub_580C
call72:open
call73:atoi
call74:sub_3C94 <--
sub_8000的函数长这个样子,请记住第25行0xB8010这个数字,后面会派上用场的
跟着函数调用链一处一处的在IDA中跳转到相应的地址进行查看,在call62:sub_5F20我们发现了有意思的代码 这个函数,一眼RC4呀 
用frida去hook一下这个函数看看RC4的密钥是什么 function hook_5f20_guess_rc4(){//像是RC4的样子,hook看看
var module = Process.findModuleByName("libjiagu_64.so");
Interceptor.attach(module.base.add(0x5f20), {
// fd, buff, len
onEnter: function (args) {
console.log(hexdump(args[0], {
offset: 0,// 相对偏移
length: 0x10,//dump 的大小
header: true,
ansi: true
}));
console.log(args[1])
console.log(hexdump(args[2], {
offset: 0,// 相对偏移
length: 256,//dump 的大小
header: true,
ansi: true
}));
},
onLeave: function (ret) {
}
});
}
所以密钥就是这个咯 key = b"vUV4#\x91#SVt"
继续跟着函数调用链走,在call63:sub_6044我们发现了RC4的解密函数 
hook一下call63:sub_6044看看到底给什么数据解密了 var rc4_enc_text_addr,rc4_enc_size;
function hook_rc4_enc(){
var module = Process.findModuleByName("libjiagu_64.so");
Interceptor.attach(module.base.add(0x6044), {
// fd, buff, len
onEnter: function (args) {
rc4_enc_text_addr = args[0];
rc4_enc_size = args[1];
console.log(hexdump(args[0], {
offset: 0,// 相对偏移
length: 0x30,//dump 的大小
header: true,
ansi: true
}));
console.log(args[1])
},
onLeave: function (ret) {
console.log(hexdump(rc4_enc_text_addr, {
offset: 0,// 相对偏移
length: 0x30,//dump 的大小
header: true,
ansi: true
}));
}
});
}
这个函数的第二个参数是0xb8010,感觉是解密的数据的长度的样子,而且这个数字,有没有感觉在哪里见过呢? 没错,这个数字刚刚就出现在sub_8000中 
而v5[0]的值是qword_2E270,这个数组也是01 18 25 e7开头的 
继续跟着调用链走,接下来是调用call65:uncompress,进行解压缩操作 function hook_uncompress_res(){
var module = Process.findModuleByName("libjiagu_64.so");
Interceptor.attach(Module.findExportByName(null, "uncompress"), {
onEnter: function (args) {
console.log("hook uncompress")
console.log(hexdump(args[2], {
offset: 0,// 相对偏移
length: 0x30,//dump 的大小
header: true,
ansi: true
}));
console.log(args[3])
dump_memory(args[2],args[3],`uncompress_${args[2]}_${args[3]}`)
},
onLeave: function (ret) {
}
});
}
我们发现解压缩的数据,前面四个字节b9 0e 1a 00没有包含在解压缩的字节之内 
现在既然我们已经知道了主ELF在壳ELF中的位置,以及解密的算法,那我们直接从解压apk,找到里面的assets/libjiagu_a64.so,不就能直接把壳ELF解密出来咯 import zlib
import struct
def RC4(data, key):
S = list(range(256))
j = 0
out = []
# KSA Phase
for i in range(256):
j = (j + S[i] + key[i % len(key)]) % 256
S[i], S[j] = S[j], S[i]
# PRGA Phase
i = j = 0
for ch in data:
i = (i + 1) % 256
j = (j + S[i]) % 256
S[i], S[j] = S[j], S[i]
out.append(ch ^ S[(S[i] + S[j]) % 256])
return out
def RC4decrypt(ciphertext, key):
return RC4(ciphertext, key)
wrap_elf_start = 0x1e270
wrap_elf_size = 0xb8010
key = b"vUV4#\x91#SVt"
with open('com.oacia.apk_protect/assets/libjiagu_a64.so','rb') as f:
wrap_elf = f.read()
# 对密文进行解密
dec_compress_elf = RC4decrypt(wrap_elf[wrap_elf_start:wrap_elf_start+wrap_elf_size], key)
dec_elf = zlib.decompress(bytes(dec_compress_elf[4::]))
with open('wrap_elf','wb') as f:
f.write(dec_elf)
解密完成后,我们发现0x1a0eb9应该表示解压缩之后数据的大小 
 wrap_elf的前半部分是一大堆莫名其妙有很多D3的东西,但是看到中间还是发现了壳ELF的身影
我们以.ELF为标志将这两部分分离一下 with open('wrap_elf', 'rb') as f:
wrap_elf = f.read()
ELF_magic = bytes([0x7F, 0x45, 0x4C, 0x46])
for i in range(len(wrap_elf) - len(ELF_magic) + 1):
if wrap_elf[i:i + len(ELF_magic)] == ELF_magic:
print(hex(i))
with open('wrap_elf_part1', 'wb') as f:
f.write(wrap_elf[0:i])
with open('wrap_elf_part2', 'wb') as f:
f.write(wrap_elf[i::])
break
跟着函数调用链来到call69:sub_5B08,这里又出现了0x38,并且word_38跳转过去的值为6 
这正好和phentsize和phnum的值相对应 
所以可想而知,这又是一个关键点了,往下看一下代码,发现了循环异或,那我们不妨用frida把v4的值hook下来看看是什么 
v4的值出现了那么多的d3 
而这就是wrap_elf的前半部分那一大堆我们看不懂的字节 
接下来用来解密的循环就是一个arm64的neon运算 
官网可以找到vdupq_n_s8和veorq_s8,根据函数描述可以知道这里用向量运算,把向量中的每一个元素都异或了0xd3 
对sub_5B08进行分析之后,我们便可以知道wrap_elf_part1的读取方式是第一个字节表示被异或的数字,这里是0xD3,后面的四个字节表示一个段的长度,随后读取指定长度的字节并异或,之后再读取四个字节获取到下一个段的长度,以此类推,直到读取到文件末尾 
在sub_5B08的最后,因为v31,v19,v43,v7代表对应的数据组的长度,所以这里共有四个数据组,而为了表示每一个数据组的长度共需占用4*4=16字节,并且文件开头还有1位的异或值,于是这些长度加起来,*(a1 + 0x98)的偏移就来到了主ELF的魔术头.ELF的位置了 
我们可以在sub_5B08中为变量a1定义一个结构体,成员分别表示数据组的1,2,3,4这四个部分,这样我们就知道这四个部分分别被用到什么地方了 struct deal_extra
{
char blank[72];
int phnum;
int *extra_part1;
int phdr_size;
char blank2[36];
int *extra_part2;
int *extra_part3;
int *extra_part4;
int *main_elf;
};
接下来再捋一下函数的调用链sub_49F0->sub_5478(&v16, a1, v4)->sub_5B08(a1, a2, a3),在sub_5B08中,我们把a1的类型定义成了deal_extra,所以理所应当的,我们也把sub_49F0中的变量v16的类型定义为deal_extra 在sub_49F0中我们发现成员extra_part赋值给了变量v7,所以我们也为v7建立一个结构体让v7的偏移可以对应这些变量 
struct deal_extra_B
{
char blank[232];
int *extra_part1;
char blank1[8];
int phnum;
int *extra_part4;
char blank2[24];
int *extra_part2;
char blank3[8];
int *extra_part3;
};
这样做有什么意义呢? 我们发现变量v7分别被传入到了sub_3C94和sub_4918中,我们分别进去看看 
在sub_3C94中解析了extra_part4,显而易见,这个switch是用来处理动态链接库的,即extra_part4对应.dynamic段 
在sub_4918中,extra_part2和extra_part3被传入到sub_4000中 
而这个函数中的switch是用来处理重定位的,因为重定位主要有基址重定位和符号重定位,这两个的值分别是0x403和0x402 所以extra_part2和extra_part3分别对应着.rela.plt(402重定位)和.rela.dyn(403重定位) 
而之后extra_part1被传入到了sub_5E6C中 
而来到sub_5E6C也来到了我们最开始分析的起点(兜兜转转又回来了),所以extra_part1表示program header table 
至此为止,四个数据组所对应的段都分析完成 数据组1表示program header table数据组2表示.rela.plt数据组3表示.rela.dyn数据组4表示.dynamic
所以接下来,写个脚本把这四个数据组给分离成单独的文件咯 import copy
import zlib
def RC4(data, key):
S = list(range(256))
j = 0
out = []
# KSA Phase
for i in range(256):
j = (j + S[i] + key[i % len(key)]) % 256
S[i], S[j] = S[j], S[i]
# PRGA Phase
i = j = 0
for ch in data:
i = (i + 1) % 256
j = (j + S[i]) % 256
S[i], S[j] = S[j], S[i]
out.append(ch ^ S[(S[i] + S[j]) % 256])
return out
def RC4decrypt(ciphertext, key):
return RC4(ciphertext, key)
wrap_elf_start = 0x1e270
wrap_elf_size = 0xb8010
key = b"vUV4#\x91#SVt"
with open('com.oacia.apk_protect/assets/libjiagu_a64.so', 'rb') as f:
wrap_elf = f.read()
# 对密文进行解密
dec_compress_elf = RC4decrypt(wrap_elf[wrap_elf_start:wrap_elf_start + wrap_elf_size], key)
dec_elf = zlib.decompress(bytes(dec_compress_elf[4::]))
with open('wrap_elf', 'wb') as f:
f.write(dec_elf)
class part:
def __init__(self):
self.name = ""
self.value = b''
self.offset = 0
self.size = 0
index = 1
extra_part = [part() for _ in range(7)]
seg = ["phdr", ".rela.plt", ".rela.dyn", ".dynamic"]
v_xor = dec_elf[0]
for i in range(4):
size = int.from_bytes(dec_elf[index:index + 4], 'little')
index += 4
extra_part[i + 1].name = seg[i]
extra_part[i + 1].value = bytes(map(lambda x: x ^ v_xor, dec_elf[index:index + size]))
extra_part[i + 1].size = size
index += size
for p in extra_part:
if p.value!=b'':
filename = f"libjiagu.so_{hex(p.size)}_{p.name}"
print(f"[{p.name}] get {filename}, size: {hex(p.size)}")
with open(filename,'wb') as f:
f.write(p.value)
于是我们得到了这四个文件 
需要被修复的主ELF是我们在从assets/libjiagu_a64.so利用RC4和decompress解密出来的文件的后半部分那个ELF 可以写个python脚本分离出后面的ELF with open('wrap_elf', 'rb') as f:
wrap_elf = f.read()
ELF_magic = bytes([0x7F, 0x45, 0x4C, 0x46])
for i in range(len(wrap_elf) - len(ELF_magic) + 1):
if wrap_elf[i:i + len(ELF_magic)] == ELF_magic:
with open('libjiagu_0xe7000.so', 'wb') as f:
f.write(wrap_elf[i::])
break
现在我们拿到了主ELF的四个重要的数据段,分别是phdr,.rela.plt,.rela.dyn,.dynamic,那么接下来需要做的工作就是修复主ELF的导入导出表了,不然导入导出函数都看不见怎么逆嘞~ 在使用自实现linker加固so时,phdr,.rela.plt,.rela.dyn,.dynamic这四个段是从待加固的so中提取出来,然后加密存储到其他位置,原来的位置会使用无关字节直接覆盖 等到需要为加固的so进行预链接和重定位的工作时,才将这些段解密并通过自己实现的预链接和重定位代码,让待加固的so可以正确的被壳so加载出来 我们进行修复的方法其实就藏在这句话中原来的位置会使用无关字节直接覆盖,我们可以将分离出来的这四个段再塞回到原来的位置 自实现linker加固so的加固方案既然都把那四个段加密存到其他地方了,那怎么不直接把原来的四个段直接删除而是用无关字节覆盖呢?
因为直接把段删除掉的话,会影响了一整个ELF文件的布局,偏移就会变得和原先不一样,然后产生各种奇奇怪怪的问题 在010editor中,按下ctrl+shift+C可以复制整块内存,按下ctrl+shift+V可以粘贴整块内存
修复program header table 复制libjiagu.so_0x150_phdr的所有字节,然后来到libjiagu_0xe7000.so中选中struct program_header_table粘贴
随后按下F5刷新模板 修复.dynamic program header table的(RW_) Dynamic Segment的p_offset指向.dynamic段的位置、
跳转到该位置,复制libjiagu.so_0x1b0_.dynamic的内容并粘贴到这个位置 修复重定位表
我们需要通过.dynamic段的d_tag字段来找到重定位表的位置,下面是AOSP中d_tag的宏定义 
所有的d_tag标志对应的含义可以在ORACLE 链接程序和库指南 中找到 对于我们修复主ELF比较重要的tag有 
我们可以在.dynamic中发现这些tag以及对应的值 
看看这两个大小分别是0x1650和0x25188,这不就和我们刚刚分离出来的文件大小一模一样嘛,说明我们离修复完成不远了 
然后就是和之前一样,跳转到.rela.plt和.rela.dyn的对应地址,然后把这些段本来的数据粘贴进去 现在我们就修复好啦,拿ida打开主ELF看看,满满的都是符号! 
随便找个导入函数交叉引用看看,一切正常(●'◡'●) 
为了方便起见,我们可以将主ELF的基址定义成在其在壳ELF的偏移0xe7000方便后续的分析 还记得在加固壳反调试初步分析中,我们拿到了未解密的dex嘛 
那么接下来有个问题就是,这个未解密的dex究竟藏在了apk的什么地方呢? 我将未加固的apk解压出来,然后用7zip压缩其中的dex,发现大小依然有2.8MB 
随后我将经过加固之后的apk解压出来,按大小对文件进行排序之后发现,最大的文件就只有这个壳classes.dex,而别的文件甚至连1MB都没到,总不可能压缩率可以高到这种地步吧 
所以我们打开classes.dex看看,在这个classes.dex的末尾,果然藏着一大堆的数据 
而末尾的数据是由71 68 00 01和我们之前看到的加密的dex一模一样 接下来我们继续用stalker_trace_so去看看补充上主ELF的函数地址以及名称之后的函数调用链是什么样子的,首先在主ELF中运行插件Edit->Plugins->stalker_trace_so 之后同样的,我们需要将so_name改成libjiagu_64.so,特别注意的是,这里我们需要把壳ELF的func_addr和func_name给复制过来,同时使用concat方法将主ELF和壳ELF的函数地址和函数名拼接成一个新的数组 
之前替换/proc/self/maps来实现初步反调试的js函数hook_proc_self_maps也需要同时执行 输出结果如下,KEkeELF标志表示壳ELF,mainELF表示主ELF,(为什么是KEke,只是为了对齐看着舒服:)) 要判断调用的函数在哪个ELF里面,在trace_so()里面稍作修改判断一下范围可以了 
打印出来的结果如下 (KEkeELF)call1:JNI_OnLoad
(KEkeELF)call2:j_interpreter_wrap_int64_t
(KEkeELF)call3:interpreter_wrap_int64_t
(KEkeELF)call4:getenv
(KEkeELF)call5:sub_13908
(KEkeELF)call6:inotify_add_watch
(KEkeELF)call7:sub_11220
(KEkeELF)call8:fopen
(KEkeELF)call9:sub_9DD8
(KEkeELF)call10:sub_E3E0
(KEkeELF)call11:strtol
(KEkeELF)call12:feof
(KEkeELF)call13:raise
(KEkeELF)call14:memset
(KEkeELF)call15:sub_C918
(KEkeELF)call16:sub_9988
(KEkeELF)call17:sub_9964
(KEkeELF)call18:sub_9AC4
(KEkeELF)call19:j_ffi_prep_cif
(KEkeELF)call20:ffi_prep_cif
(KEkeELF)call21:j_ffi_prep_cif_machdep
(KEkeELF)call22:ffi_prep_cif_machdep
(KEkeELF)call23:j_ffi_call
(KEkeELF)call24:ffi_call
(KEkeELF)call25:sub_1674C
(KEkeELF)call26:j_ffi_call_SYSV
(KEkeELF)call27:ffi_call_SYSV
(KEkeELF)call28:sub_167BC
(KEkeELF)call29:sub_1647C
(KEkeELF)call30:sub_163DC
(KEkeELF)call31:sub_9900
(KEkeELF)call32:sub_94BC
(KEkeELF)call33:inotify_init
(KEkeELF)call34:fmod
(KEkeELF)call35:strncpy
(KEkeELF)call36:_Z9__arm_a_1P7_JavaVMP7_JNIEnvPvRi
(KEkeELF)call37:sub_9E58
(KEkeELF)call38:sub_999C
(KEkeELF)call39:sub_10964
(KEkeELF)call40:j_lseek_1
(KEkeELF)call41:lseek
(KEkeELF)call42:sub_96E0
(KEkeELF)call43:sub_8000
(KEkeELF)call44:dlopen
(KEkeELF)call45:sub_60E0
(KEkeELF)call46:sub_6544
(KEkeELF)call47:sub_4B54
(KEkeELF)call48:sub_6128
(KEkeELF)call49:_ZN9__arm_c_19__arm_c_0Ev
(KEkeELF)call50:sub_A3EC
(KEkeELF)call51:sub_99CC
(KEkeELF)call52:sub_9944
(KEkeELF)call53:sub_6484
(KEkeELF)call54:sub_6590
(KEkeELF)call55:prctl
(KEkeELF)call56:sub_6698
(KEkeELF)call57:sub_9FFC
(KEkeELF)call58:j_lseek_3
(KEkeELF)call59:j_lseek_2
(KEkeELF)call60:j_lseek_0
(KEkeELF)call61:sub_9A90
(KEkeELF)call62:sub_5F20
(KEkeELF)call63:sub_6044
(KEkeELF)call64:sub_3574
(KEkeELF)call65:uncompress
(KEkeELF)call66:sub_49F0
(KEkeELF)call67:sub_5400
(KEkeELF)call68:sub_5478
(KEkeELF)call69:sub_5B08
(KEkeELF)call70:sub_5650
(KEkeELF)call71:sub_580C
(KEkeELF)call72:open
(KEkeELF)call73:atoi
(KEkeELF)call74:sub_3C94
(KEkeELF)call75:strncmp
(KEkeELF)call76:sub_4918
(KEkeELF)call77:sub_4000
(KEkeELF)call78:sub_41B4
(KEkeELF)call79:sub_35AC
(KEkeELF)call80:sigaction
(KEkeELF)call81:sub_5E6C
(KEkeELF)call82:sub_5444
(mainELF)call83:sub_11603C
(mainELF)call84:j__Znwm
(mainELF)call85:_Znwm
(mainELF)call86:malloc
(mainELF)call87:__cxa_atexit
(mainELF)call88:sub_1160B4
(mainELF)call89:sub_1160C4
(mainELF)call90:strlen
(mainELF)call91:memcpy
(mainELF)call92:sub_1161FC
(mainELF)call93:sub_1164AC
(mainELF)call94:sub_1164D8
(mainELF)call95:sub_116528
(mainELF)call96:sub_1165C8
(mainELF)call97:sub_1A32C0
(mainELF)call98:sub_1A3150
(mainELF)call99:sub_1A3204
(mainELF)call100:sub_1166FC
(mainELF)call101:sub_116728
(mainELF)call102:sub_116750
(mainELF)call103:sub_116830
(mainELF)call104:sub_116BA0
(KEkeELF)call105:sub_633C
(KEkeELF)call106:sub_8130
(KEkeELF)call107:sub_4C70
(KEkeELF)call108:sub_825C
(KEkeELF)call109:sub_8B50
(KEkeELF)call110:sub_8ED4
(KEkeELF)call111:sub_8430
(mainELF)call112:JNI_OnLoad
(mainELF)call113:j_interpreter_wrap_int64_t
(mainELF)call114:interpreter_wrap_int64_t
(KEkeELF)call115:interpreter_wrap_int64_t_bridge
(KEkeELF)call116:sub_9D60
(mainELF)call117:sub_1B3F0C
(mainELF)call118:gettimeofday
(mainELF)call119:sub_11BD9C
(mainELF)call120:sub_1182D8
(mainELF)call121:sub_123970
(mainELF)call122:sub_1B6448
(mainELF)call123:getenv
(mainELF)call124:sub_11F130
(mainELF)call125:sub_12047C
(mainELF)call126:j__ZdlPv
(mainELF)call127:_ZdlPv
(mainELF)call128:free
(mainELF)call129:sub_1427E8
(mainELF)call130:dlopen
(mainELF)call131:sub_11BDA8
(mainELF)call132:sub_11BE58
(mainELF)call133:sub_11F69C
(mainELF)call134:sub_117BE0
(mainELF)call135:sub_117CA0
(mainELF)call136:fopen
(mainELF)call137:sub_117E90
(mainELF)call138:sub_14285C
(mainELF)call139:sub_1429CC
(mainELF)call140:sub_11C1AC
(mainELF)call141:sub_11C1B4
(mainELF)call142:sub_11C210
(KEkeELF)call143:sub_166C4
(KEkeELF)call144:memcpy
(mainELF)call145:sub_123324
(mainELF)call146:sub_1205A0
(mainELF)call147:sub_11F768
(mainELF)call148:memcmp
(mainELF)call149:opendir
(mainELF)call150:closedir
(mainELF)call151:sub_11859C
(mainELF)call152:sub_11C268
(mainELF)call153:sub_11C300
(mainELF)call154:sub_117B68
(mainELF)call155:sub_1186B8
(mainELF)call156:sub_143964
(mainELF)call157:sub_1B66A8
(mainELF)call158:pthread_mutex_lock
(mainELF)call159:sub_142EA0
(mainELF)call160:sub_143A38
(mainELF)call161:sub_11CF8C
(mainELF)call162:sub_131D58
(mainELF)call163:sub_1B66D0
(mainELF)call164:pthread_mutex_unlock
(mainELF)call165:sub_1178E8
(mainELF)call166:sub_13D70C
(mainELF)call167:sub_19F984
(mainELF)call168:sub_11F1C8
(mainELF)call169:atoi
(mainELF)call170:sub_12D2F8
(mainELF)call171:sub_17ABE8
(mainELF)call172:sub_172660
(mainELF)call173:sub_13BFF0
(mainELF)call174:sub_172AA4
(mainELF)call175:sub_13BD80
(mainELF)call176:sub_13BE2C
(mainELF)call177:sub_13BE4C
(mainELF)call178:memmove
(mainELF)call179:sub_13BE64
(mainELF)call180:sub_172D78
(mainELF)call181:sub_13E510
(mainELF)call182:sub_1926F0
(mainELF)call183:sub_13DB7C
(mainELF)call184:sub_1B7A08
(mainELF)call185:sub_1B7ABC
(mainELF)call186:pthread_cond_broadcast
(mainELF)call187:sub_12FA34
(mainELF)call188:sub_120664
(mainELF)call189:sub_1332B8
(mainELF)call190:sub_13E0F8
(mainELF)call191:sub_12743C
(mainELF)call192:sub_124C68
(mainELF)call193:sub_125DC4
(mainELF)call194:sub_124510
(mainELF)call195:sub_126888
(mainELF)call196:strdup
(mainELF)call197:sub_126920
(mainELF)call198:sub_122180
(mainELF)call199:sub_11BC1C
(mainELF)call200:sub_13DF34
(mainELF)call201:getpid
(mainELF)call202:memset
(mainELF)call203:snprintf
(mainELF)call204:sub_124FA0
(mainELF)call205:sub_1B6498
(mainELF)call206:sub_1A0C88
(mainELF)call207:sub_217444
(mainELF)call208:sub_2175E0
(mainELF)call209:read
(mainELF)call210:strncmp
(mainELF)call211:close
(mainELF)call212:sub_1B578C
(mainELF)call213:j___self_lseek
(mainELF)call214:__self_lseek
(mainELF)call215:sub_1B586C
(mainELF)call216:j_j___read_self
(mainELF)call217:j___read_self
(mainELF)call218:__read_self
(mainELF)call219:sub_1B6528
(mainELF)call220:sub_1B6578
(mainELF)call221:mmap
(mainELF)call222:sub_1B5B50
(mainELF)call223:calloc
(mainELF)call224:memchr
(mainELF)call225:sub_1B5D04
(mainELF)call226:sub_1B5EC4
(mainELF)call227:sub_1B6270
(mainELF)call228:sub_1B6180
(mainELF)call229:sub_1B6678
(mainELF)call230:inflateInit2_
(mainELF)call231:inflate
(mainELF)call232:inflateEnd
(mainELF)call233:sub_1B6540
(mainELF)call234:munmap
(mainELF)call235:sub_1B56F8
(mainELF)call236:sub_19BC9C
(mainELF)call237:sub_19CCD4
(mainELF)call238:sub_12D470
(mainELF)call239:sub_142FE0
(mainELF)call240:sub_143008
(mainELF)call241:sub_142ABC
(mainELF)call242:sub_143848
(mainELF)call243:sub_143B48
(mainELF)call244:sub_143088
(mainELF)call245:sub_1222D0
(mainELF)call246:sub_14316C
(mainELF)call247:sub_142954
(KEkeELF)call248:_Z9__arm_a_2PcmS_Rii
(mainELF)call249:sub_142894
(mainELF)call250:sub_1428BC
(mainELF)call251:sub_127DCC
(mainELF)call252:sub_14292C
(mainELF)call253:sub_121B78
(mainELF)call254:sub_121BE0
(mainELF)call255:sub_123CE8
(mainELF)call256:sub_123BC0
(mainELF)call257:sub_11959C
(mainELF)call258:sub_1AC170
(mainELF)call259:pthread_create
(mainELF)call260:sub_1AC210
(mainELF)call261:sub_1B5DE4
(mainELF)call262:sub_1B60E8
(mainELF)call263:sub_19F7C4
(mainELF)call264:sub_1B2DC8
(mainELF)call265:sub_1B1CE8
(mainELF)call266:sub_1B0974
(mainELF)call267:sub_1AFE6C
(mainELF)call268:sub_126ED8
(mainELF)call269:sub_1AFE8C
(mainELF)call270:sub_1AFE90
(mainELF)call271:sub_1AB87C
(mainELF)call272:sub_1B26D4
(mainELF)call273:sub_1B26F4
(mainELF)call274:sub_1B27C8
(KEkeELF)call275:j_ffi_prep_cif_var
(KEkeELF)call276:ffi_prep_cif_var
(mainELF)call277:sub_1AAF48
(mainELF)call278:sub_1AAF54
(mainELF)call279:sub_2162D4
(mainELF)call280:sub_1B2898
(mainELF)call281:sub_1B2918
(mainELF)call282:sub_1ABE90
(mainELF)call283:sub_13E0EC
(mainELF)call284:sub_124900
(mainELF)call285:sub_1A0C34
(mainELF)call286:sub_217188
(mainELF)call287:j_strcmp
(mainELF)call288:strcmp
(mainELF)call289:sub_194514
(mainELF)call290:sub_1A2380
(mainELF)call291:sub_1A23CC
(mainELF)call292:sub_1A2718
(mainELF)call293:sub_1A2A94
(mainELF)call294:sub_1A25E0
(mainELF)call295:sub_1A2984
分析输出的结果,我们发现了三个有趣的函数inflateInit2_,inflate,inflateEnd,这不是zlib用来解压缩的函数嘛~ (mainELF)call230:inflateInit2_
(mainELF)call231:inflate
(mainELF)call232:inflateEnd
对inflateInit2_交叉引用,发现有两个函数调用了它 
那么要怎么知道是哪一个函数先调用的inflateInit2_呢?向上看看函数调用链就行了 于是我们发现是sub_1B6270调用了inflateInit2_ (mainELF)call227:sub_1B6270 <--
(mainELF)call228:sub_1B6180
(mainELF)call229:sub_1B6678
(mainELF)call230:inflateInit2_
(mainELF)call231:inflate
(mainELF)call232:inflateEnd
我们来到sub_1B6270,先到https://github.com/madler/zlib把zlib.h中的z_stream_s,导入的方法和之前一样 # define z_const const
typedef unsigned char Byte; /* 8 bits */
typedef unsigned int uInt; /* 16 bits or more */
typedef unsigned long uLong; /* 32 bits or more */
typedef struct z_stream_s {
z_const Bytef *next_in; /* next input byte */
uInt avail_in; /* number of bytes available at next_in */
uLong total_in; /* total number of input bytes read so far */
Bytef *next_out; /* next output byte will go here */
uInt avail_out; /* remaining free space at next_out */
uLong total_out; /* total number of bytes output so far */
} z_stream;
重定义s的类型为z_stream,这四个字段的含义如下 s.next_in: 压缩数据s.avail_in:压缩数据的长度s.next_out: 解压后的数据s.avail_out: 解压后数据的长度
各个成员的偏移如图所示 
随后我们用frida去hook一下inflate函数看看解压缩之后的数据是什么 这里有个技巧,就是如何可以hook到主ELF中的函数,,因为在壳ELF加载进内存时,主ELF还没有被加载,所以假如在壳ELF通过android_dlopen_ext打开时我们进行hook,是会hook失败的 那么如何才能获取到主ELF的hook时机呢?我们可以通过统计外部函数的调用次数来判断是否已经加载了主ELF,例如我这里,我通过zlib_count统计外部函数inflate调用次数,因为在壳ELF会使用uncompress调用一次inflate,所以当第二次调用inflate,我们就知道这肯定是主ELF调用的,所以我们也可以在这个位置放心大胆的hook了 function dump_memory(start,size,filename) {
var file_path = "/data/data/com.oacia.apk_protect/" + filename;
var file_handle = new File(file_path, "wb");
if (file_handle && file_handle != null) {
var libso_buffer = start.readByteArray(size.toUInt32());
file_handle.write(libso_buffer);
file_handle.flush();
file_handle.close();
console.log("[dump]:", file_path);
}
}
function hook_zlib_result(){
var module = Process.findModuleByName("libjiagu_64.so");
Interceptor.attach(module.base.add(0x1B63F0), {
// fd, buff, len
onEnter: function (args) {
console.log("inflate result")
console.log(hexdump(next_in, {
offset: 0,// 相对偏移
length: 0x50,//dump 的大小
header: true,
ansi: true
}));
console.log(hexdump(next_out, {
offset: 0,// 相对偏移
length: 0x50,//dump 的大小
header: true,
ansi: true
}));
dump_memory(next_out,avail_out,"dex001")
},
onLeave: function (ret) {
}
});
}
var zlib_count=0;
var next_in,avail_in,next_out,avail_out;
function hook_zlib(){
Interceptor.attach(Module.findExportByName(null, "inflate"), {
// fd, buff, len
onEnter: function (args) {
zlib_count+=1
if(zlib_count>1){
hook_zlib_result();
}
next_in=ptr(args[0].add(0x0).readS64());
avail_in=ptr(args[0].add(0x8).readS64());
next_out=ptr(args[0].add(0x18).readS64());
avail_out=ptr(args[0].add(0x20).readS64());
console.log(hexdump(next_in, {
offset: 0,// 相对偏移
length: 0x50,//dump 的大小
header: true,
ansi: true
}));
console.log(args[1]);
},
onLeave: function (ret) {
}
});
}
解压缩之后的输出如下,在输出的文件头,我们发现了dex035,所以我们把这块内存dump下来看看,使用上方的dump_memory(start,size,filename)函数即可 
把这个解压缩之后的dex拖入到jadx里面,却发现这个类名怎么和壳DEX的类名一模一样,通过校验哈希发现dump下来的dex和壳dex其实是同一个文件 
我们在之前的分析中知道壳dex的末尾附带了一大串的加密数据,所以通过将这个解压缩得到了这个dex,就说明马上要进行加密主DEX的解密操作了 解压缩的函数是sub_1B6270,接下来我们继续通过stalker_trace_so打印出来的内容,并利用交叉引用来追踪该函数的调用链 就比如说对于函数sub_1B6270,它有两个交叉引用 
通过stalker_trace_so打印出来的函数调用链,我们发现是sub_1A0C88在sub_1B6270之前调用,所以函数的调用关系就是sub_1A0C88->sub_1B6270,以此类推 (mainELF)call206:sub_1A0C88
(mainELF)call227:sub_1B6270
所以一路跟过来之后,函数的调用链为sub_1332B8->sub_124FA0->sub_1A0C88->sub_1B6270->inflate,sub_1332B8函数之后就没有交叉引用了 (mainELF)call189:sub_1332B8
(mainELF)call204:sub_124FA0
(mainELF)call206:sub_1A0C88
(mainELF)call227:sub_1B6270
(mainELF)call230:inflateInit2_
(mainELF)call231:inflate
(mainELF)call232:inflateEnd
在这个函数中,我们发现了apk@classes.dex,而它的作用,正是为了找到已加载到内存且优化后的壳dex 
在加固壳反调试初步分析的后半部分,我们打印出了加固壳打开dex的堆栈回溯,现在我们直接跳转到相对应的地方看看 
我们到0x19b780看看,看起来是一个标准的打开并写入文件的函数 
随后对该函数进行交叉引用,我们发现sub_1332B8竟然调用了它,就在刚刚我们就分析出这个函数中可是同时也执行了从内存中获取壳dex的操作的呢 
我们对这两处调用都hook一下看看是什么情况,打印的结果如下,说明这两处调用都打开了dex,sub_1332B8中的前一个调用打开了classes.dex,后一个调用打开了classes2.dex和classes3.dex,而classes.dex文件中的内容就是加密的主dex 
在创建完classes2.dex和classes3.dex,通过hook发现调用在调用sub_128D44之后进程就退出了 
我们去hook一下sub_128D44这个函数,发现传入的参数v8正是加密的主DEX 
而sub_128D44函数是这个样子的,并且在壳ELF加载时启动stalker_trace_so的trace_so()函数所打印出的结果中,并没有这个函数的调用被打印出来 
这该怎么办呢? 很简单,在调用sub_128D44的位置再去调用一次trace_so()函数从现在的位置开始打印函数的调用链不就行咯:) 
函数调用关系如下,我们发现再mainELF调用完sub_128D44之后,通过一系列操作又回到了壳ELF中,最终调用raise导致进程退出 
然而,当我跳转到最后调用的几个函数时,可以说函数复杂到让人咋舌 
这么复杂,是给人分析的吗!?所以我便卡在这里了很久 我想了想现在摆在面前的有两条路,是和一眼望不到尽头的这俩函数死磕到底,还是选择把这个加固壳的反调试搞定? 我选择后者,因为明显搞定反调试要比把这两个函数分析明白要稍微简单一点 在加固壳反调试初步分析中,我曾尝试过dbus,TracerPid,readlink,strstr都没有明显的效果,只有hook open函数让我看到了些许的曙光,那么现在应该还有一种非常重要的反调试手段没有用到,那就是pthread_create反调试 function check_pthread_create() {
var pthread_create_addr = Module.findExportByName(null, 'pthread_create');
var pthread_create = new NativeFunction(pthread_create_addr, "int", ["pointer", "pointer", "pointer", "pointer"]);
Interceptor.replace(pthread_create_addr, new NativeCallback(function (parg0, parg1, parg2, parg3) {
var so_name = Process.findModuleByAddress(parg2).name;
var so_path = Process.findModuleByAddress(parg2).path;
var so_base = Module.getBaseAddress(so_name);
var offset = parg2 - so_base;
var PC = 0;
if ((so_name.indexOf("jiagu") > -1)) {
console.log("======")
console.log("find thread func offset", so_name, offset.toString(16));
Thread.backtrace(this.context, Backtracer.ACCURATE).map(addr_in_so);
var check_list = []//1769036,1771844
if (check_list.indexOf(offset)!==-1) {
console.log("check bypass")
} else {
PC = pthread_create(parg0, parg1, parg2, parg3);
}
} else {
PC = pthread_create(parg0, parg1, parg2, parg3);
}
return PC;
}, "int", ["pointer", "pointer", "pointer", "pointer"]))
}
function addr_in_so(addr){
var process_Obj_Module_Arr = Process.enumerateModules();
for(var i = 0; i < process_Obj_Module_Arr.length; i++) {
if(addr>process_Obj_Module_Arr[i].base && addr<process_Obj_Module_Arr[i].base.add(process_Obj_Module_Arr[i].size)){
console.log(addr.toString(16),"is in",process_Obj_Module_Arr[i].name,"offset: 0x"+(addr-process_Obj_Module_Arr[i].base).toString(16));
}
}
}
注入代码之后,pthread_create的调用都指向了同一个地址0x17710 
我们跳转到这个地址之后却发现为什么会没有pthread_create呢?? 
看了一眼这个代码所在的函数的名称ffi_call_SYSV 
hmmm,看来是用libffi动态调用函数呀 
直接到libffi的github仓库看一眼ffi_call_SYSV的源码 一进去注释都写得清清楚楚了 
利用注释就可以知道每行汇编都代表什么了,所以BLR X24表示去动态调用函数,而前面的X0,X2,X4,X6是用来传参的 
我们hook一下x0看看有没有什么敏感的字符串 function anti_frida_check(){
var module = Process.findModuleByName("libjiagu_64.so");
Interceptor.attach(module.base.add(0x1770C), {
onEnter: function (args) {
try{
console.log(this.context.x0.readCString())
}
catch (e){
}
},
onLeave: function (ret) {
}
});
}
然而神奇的是,我仅仅去hook并打印x0字符串,其他什么事情都不干,apk竟然神奇的进去了,只不过会没有响应,感觉距离成功不远了呢 
有点意思,筛选一下看看有没有什么敏感的字符串好咯 function anti_frida_check(){
var module = Process.findModuleByName("libjiagu_64.so");
Interceptor.attach(module.base.add(0x1770C), {
onEnter: function (args) {
try{
var s = this.context.x0.readCString();
if (s.indexOf('frida')!==-1 ||
s.indexOf('gum-js-loop')!==-1 ||
s.indexOf('gmain')!==-1 ||
s.indexOf('linjector')!==-1 ||
s.indexOf('/proc/')!==-1){
console.log(s)
}
}
catch (e){
}
},
onLeave: function (ret) {
}
});
}
竟然还真有,那就把这些字符串全部替换成无意义的字符串看看咯 
function anti_frida_check(){
var module = Process.findModuleByName("libjiagu_64.so");
Interceptor.attach(module.base.add(0x1770C), {
onEnter: function (args) {
try{
var s = this.context.x0.readCString();
if (s.indexOf('frida')!==-1 ||
s.indexOf('gum-js-loop')!==-1 ||
s.indexOf('gmain')!==-1 ||
s.indexOf('linjector')!==-1 ||
s.indexOf('/proc/')!==-1){
console.log(s)
Memory.protect(this.context.x0, Process.pointerSize, 'rwx');
var replace_str=""
for(var i=0;i<s.length;i++){
replace_str+="0"
}
this.context.x0.writeUtf8String(replace_str);
}
}
catch (e){
}
},
onLeave: function (ret) {
}
});
}
然而这样做进程却一个劲的崩溃!! 没事,寄存器x0用不了,还有x2,x4,x6没替换过呢!我一个一个的试过去,终于,当我将寄存器改成x6时,进程终于不再崩溃成功的进入了apk! function anti_frida_check(){
var module = Process.findModuleByName("libjiagu_64.so");
Interceptor.attach(module.base.add(0x1770C), {
onEnter: function (args) {
try{
var s = this.context.x6.readCString();
if (s.indexOf('frida')!==-1 ||
s.indexOf('gum-js-loop')!==-1 ||
s.indexOf('gmain')!==-1 ||
s.indexOf('linjector')!==-1 ||
s.indexOf('/proc/')!==-1){
//console.log(s)
Memory.protect(this.context.x0, Process.pointerSize, 'rwx');
var replace_str=""
for(var i=0;i<s.length;i++){
replace_str+="0"
}
this.context.x0.writeUtf8String(replace_str);
}
}
catch (e){
}
},
onLeave: function (ret) {
}
});
}
看一眼检测的字符串,怎么全是/memfd:frida-agent-64.so 
回到这个卡了我们很久位置,现在过了反调试之后这里的代码终于可以继续执行下去了 
向下看找到这一个函数 
在这个函数中的字符串全部都是加密的,颇有种此地无银三百两的感觉,我们把字符串解密后发现了DexFileLoader相关的字符串,说明这个函数肯定和加载dex有某种关联 
我们hook一下这个函数,发现这个函数共调用了三次,而且传入的值都是已经解密了的dex,classes.dex,classes2.dex,classes3.dex分别通过这个函数加载 classes.dex
把这三个dex给dump下来看看,于是我们得到了这三个文件 
把最大的那个dex拖到jadx分析里面,发现这正是我们要找的主DEX 
其他函数都很正常,唯独onCreate函数变成了native声明,要是有同样分析到这里的朋友可以去研究研究onCreate函数对应的native本地函数究竟在什么地方,相信有了本文的铺垫,对于进行后续onCreate函数的分析应该是有所帮助的吧~ 而除此之外的别的类和直接反编译未加固的apk的类是一样的 
我们在加固壳反调试深入分析成功的绕过了加固壳的frida检测,现在我们再次回到sub_1332B8中的sub_128D44,来进行后续的解密算法的分析 下图是主DEX解密流程初步分析末尾部分的内容,我们将以这个函数sub_128D44为起点进行解密算法的分析,因为参数v8传入的值是加密之后的主DEX 
我们在这个内存用frida打一个内存读写断点来看看是究竟是什么函数读取了主DEX,同时需要注意加上我们的反调试函数 var so_name = "libjiagu_64.so";
function hook_dex_dec_enter_in_main_elf(){
var module = Process.findModuleByName("libjiagu_64.so");
Interceptor.attach(module.base.add(0x1346B4), {
onEnter: function (args) {
//memory breakpoint
MemoryAccessMonitor.enable(
{
base:this.context.x0.add(0x8),
size:40
},{
onAccess: function (details) {
console.log(details.operation)
console.log(get_addr_in_so(details.from));
}
}
)
},
onLeave: function (ret) {
}
});
}
var zlib_count=0
function hook_zlib(){
Interceptor.attach(Module.findExportByName(null, "inflate"), {
// fd, buff, len
onEnter: function (args) {
zlib_count+=1
if(zlib_count===2){
hook_dex_dec_enter_in_main_elf();
}
},
onLeave: function (ret) {
}
});
}
function anti_frida_check(){
var module = Process.findModuleByName("libjiagu_64.so");
Interceptor.attach(module.base.add(0x1770C), {
onEnter: function (args) {
try{
var s = this.context.x6.readCString();
if (s.indexOf('frida')!==-1 ||
s.indexOf('gum-js-loop')!==-1 ||
s.indexOf('gmain')!==-1 ||
s.indexOf('linjector')!==-1 ||
s.indexOf('/proc/')!==-1){
//console.log(s)
Memory.protect(this.context.x0, Process.pointerSize, 'rwx');
var replace_str=""
for(var i=0;i<s.length;i++){
replace_str+="0"
}
this.context.x0.writeUtf8String(replace_str);
}
}
catch (e){
}
},
onLeave: function (ret) {
}
});
}
function get_addr_in_so(addr){
var process_Obj_Module_Arr = Process.enumerateModules();
for(var i = 0; i < process_Obj_Module_Arr.length; i++) {
if(addr>process_Obj_Module_Arr[i].base && addr<process_Obj_Module_Arr[i].base.add(process_Obj_Module_Arr[i].size)){
return addr.toString(16)+" is in "+process_Obj_Module_Arr[i].name+" offset: 0x"+(addr-process_Obj_Module_Arr[i].base).toString(16);
}
}
return addr.toString(16);
}
function hook_dlopen() {
//hook_call_constructors();
Interceptor.attach(Module.findExportByName(null, "android_dlopen_ext"),
{
onEnter: function (args) {
var pathptr = args[0];
if (pathptr !== undefined && pathptr != null) {
var path = ptr(pathptr).readCString();
console.log("dlopen "+path);
if (path.indexOf(so_name) >= 0) {
this.is_can_hook = true;
}
}
},
onLeave: function (retval) {
if (this.is_can_hook) {
//you can do any thing before stalker trace so
//trace_so();
hook_zlib();
anti_frida_check();
//hook_C918();
}
}
}
);
}
setImmediate(hook_dlopen);
打印日志如下 
说明是在0xd364处读取了这个主DEX 跳转到0xd364之后发现这个地址在函数sub_C918中,看起来这个函数的形状像一个火车头一样XD 
接下来我们继续使用staker_trace_so生成的trace_so()函数去看看函数的调用链是什么样子的,trace的起点就是在sub_1332B8中的sub_128D44,同时注意加上我们的反调试函数 
打印出来的函数调用链如下 start Stalker!
Stalker end!
(mainELF)call1:sub_128D44
(mainELF)call2:j_interpreter_wrap_int64_t
(mainELF)call3:interpreter_wrap_int64_t
(KEkeELF)call4:interpreter_wrap_int64_t_bridge
(KEkeELF)call5:getenv
(KEkeELF)call6:sub_13908
(KEkeELF)call7:inotify_add_watch
(KEkeELF)call8:sub_11220
(KEkeELF)call9:fopen
(KEkeELF)call10:sub_9DD8
(KEkeELF)call11:sub_E3E0
(KEkeELF)call12:strtol
(KEkeELF)call13:feof
(KEkeELF)call14:raise
(KEkeELF)call15:memset
(KEkeELF)call16:sub_C918//这个函数中读取加密之后的dex
(KEkeELF)call17:sub_9964
(KEkeELF)call18:sub_9AC4
(KEkeELF)call19:sub_9988
(KEkeELF)call20:j_ffi_prep_cif
(KEkeELF)call21:ffi_prep_cif
(KEkeELF)call22:j_ffi_prep_cif_machdep
(KEkeELF)call23:ffi_prep_cif_machdep
(KEkeELF)call24:j_ffi_call
(KEkeELF)call25:ffi_call
(KEkeELF)call26:sub_1674C
(KEkeELF)call27:j_ffi_call_SYSV
(KEkeELF)call28:ffi_call_SYSV
(KEkeELF)call29:sub_167BC
(KEkeELF)call30:sub_1647C
(KEkeELF)call31:sub_163DC
(mainELF)call32:_Znwm
(mainELF)call33:malloc
(mainELF)call34:sub_128D64
(KEkeELF)call35:sub_9E58
(KEkeELF)call36:j_lseek_1
(KEkeELF)call37:lseek
(KEkeELF)call38:sub_A3EC
(KEkeELF)call39:sub_99CC
(KEkeELF)call40:sub_9944
(KEkeELF)call41:sub_999C
(mainELF)call42:sub_128D70
(mainELF)call43:memcpy
(mainELF)call44:sub_14283C
(mainELF)call45:j__Znwm
(mainELF)call46:sub_1429CC
(mainELF)call47:sub_142FE0
(KEkeELF)call48:sub_10964
(KEkeELF)call49:sub_9D60
(mainELF)call50:sub_143008
(mainELF)call51:sub_142ABC
(mainELF)call52:sub_142EA0
(mainELF)call53:sub_143A38
(mainELF)call54:sub_11CF8C
(mainELF)call55:sub_12047C
(mainELF)call56:strlen
(mainELF)call57:memcmp
(mainELF)call58:sub_117B68
(KEkeELF)call59:sub_166C4
(KEkeELF)call60:memcpy
(mainELF)call61:sub_143848
(mainELF)call62:sub_1B66A8
(mainELF)call63:pthread_mutex_lock
(mainELF)call64:sub_143B48
(mainELF)call65:sub_1B66D0
(mainELF)call66:pthread_mutex_unlock
(mainELF)call67:sub_143088
(mainELF)call68:sub_11F768
(mainELF)call69:j__ZdlPv
(mainELF)call70:_ZdlPv
(mainELF)call71:free
(mainELF)call72:sub_1178E8
(mainELF)call73:sub_1222D0
(mainELF)call74:sub_14316C
(mainELF)call75:sub_142954
(KEkeELF)call76:_Z9__arm_a_2PcmS_Rii
(KEkeELF)call77:j_interpreter_wrap_int64_t
(KEkeELF)call78:interpreter_wrap_int64_t
(KEkeELF)call79:sub_9FFC
(KEkeELF)call80:j_lseek_3
(KEkeELF)call81:j_lseek_2
(KEkeELF)call82:sub_9A90
(mainELF)call83:sub_142894
(mainELF)call84:sub_1428BC
(mainELF)call85:sub_127DCC
(mainELF)call86:sub_14292C
(mainELF)call87:sub_14285C
(KEkeELF)call88:j_lseek_0
(mainELF)call89:_Znam
(mainELF)call90:sub_128E88
(mainELF)call91:_ZdaPv
(mainELF)call92:sub_142AA4
(mainELF)call93:sub_142A10
(mainELF)call94:sub_12036C
(mainELF)call95:sub_1B6680
(mainELF)call96:pthread_mutex_destroy
(mainELF)call97:sub_131D58
(mainELF)call98:sub_11F3A4
(mainELF)call99:sub_18FEA8//这个函数中传入解密之后的dex,位置如下图所示
追踪函数调用链,我们发现了两个有趣的函数 (mainELF)call50:sub_143008
(mainELF)call51:sub_142ABC
sub_143008看起来是一个解密的函数,先加上0x70再异或0x36,我们hook一下传入的参数看看是什么情况
我们再去看看加密的dex,发现这个函数传入的就是加密的主dex 
把这部分解密看看里面是什么内容 with open('ke_classes.dex', 'rb') as f:
s = f.read()
dexA = s[0x31A4:0x31A4 + 0x41E]
dexA = bytearray(dexA)
for i in range(len(dexA)):
dexA[i] = ((dexA[i] + 0x70) ^ 0x36)&0xff
with open('dexA.dex','wb') as f:
f.write(dexA)
简单看了看,APPKEY,activityName等等像是一些配置信息的样子 
这部分内容解密完之后,在sub_142ABC中以pk为标志读取各个配置信息 
之后我继续一个一个跳转到打印出来的函数中看,却一直都没有发现后续部分的解密算法的身影,随后我又仔细的看了一下调用的函数,突然有了惊喜的发现,这里的pthread_mutex_lock不就意味着要用互斥锁来切换到另外一个线程了吗!? (mainELF)call61:sub_143848
(mainELF)call62:sub_1B66A8
(mainELF)call63:pthread_mutex_lock
(mainELF)call64:sub_143B48
(mainELF)call65:sub_1B66D0
(mainELF)call66:pthread_mutex_unlock
我们hook一下sub_143848,并同时打印出pid来看看是什么情况 
果不其然,在这里我们发现除了主线程外,还有三个不同的线程调用了这个函数 
那我们在pid和主线程不同的时候,用stalker_trace_so的trace_so函数在去看看究竟调用了什么函数吧 var stalker_trace_once = false;
function hook_thread(){
var module = Process.findModuleByName("libjiagu_64.so");
Interceptor.attach(module.base.add(0x143848), {
onEnter: function (args) {
if(main_thread!==Process.getCurrentThreadId()){
if(!stalker_trace_once){
stalker_trace_once = true;
trace_so();
}
}
},
onLeave: function (ret) {
}
});
}
打印出的内容如下 main thread 9434
start Stalker!, pid: 9472
Stalker end!
(mainELF)call1:sub_1B66A8
(mainELF)call2:pthread_mutex_lock
(mainELF)call3:sub_143B48
(mainELF)call4:memcmp
(mainELF)call5:sub_142EA0
(mainELF)call6:sub_143A38
(mainELF)call7:sub_1B66D0
(mainELF)call8:pthread_mutex_unlock
(KEkeELF)call9:memset
(KEkeELF)call10:inotify_add_watch
(KEkeELF)call11:sub_9AC4
(KEkeELF)call12:j_ffi_prep_cif
(KEkeELF)call13:ffi_prep_cif
(KEkeELF)call14:j_ffi_prep_cif_machdep
(KEkeELF)call15:ffi_prep_cif_machdep
(KEkeELF)call16:j_ffi_call
(KEkeELF)call17:ffi_call
(KEkeELF)call18:fopen
(KEkeELF)call19:sub_1674C
(KEkeELF)call20:j_ffi_call_SYSV
(KEkeELF)call21:ffi_call_SYSV
(KEkeELF)call22:sub_167BC
(KEkeELF)call23:sub_1647C
(KEkeELF)call24:sub_163DC
(mainELF)call25:sub_1178E8
(KEkeELF)call26:sub_9988
(mainELF)call27:sub_1236B8
(mainELF)call28:strlen
(mainELF)call29:sub_1222D0
(mainELF)call30:sub_128D70
(mainELF)call31:memcpy
(KEkeELF)call32:getenv
(KEkeELF)call33:sub_9E58
(KEkeELF)call34:j_lseek_1
(KEkeELF)call35:lseek
(mainELF)call36:sub_1A1AE8
(mainELF)call37:j_strcmp
(mainELF)call38:strcmp
(mainELF)call39:sub_19F7C4
(mainELF)call40:j__Znwm
(mainELF)call41:_Znwm
(mainELF)call42:malloc
(mainELF)call43:sub_1A1B64
(KEkeELF)call44:sub_9964
(mainELF)call45:sub_1A1B7C
(mainELF)call46:memset
(mainELF)call47:sub_1A1D84
(mainELF)call48:sub_1A1E74
(mainELF)call49:j_j__ZdlPv_12
(mainELF)call50:j__ZdlPv
(mainELF)call51:_ZdlPv
(mainELF)call52:free
(mainELF)call53:sub_18DC28
(mainELF)call54:sub_18DC4C
(KEkeELF)call55:sub_9FFC
(mainELF)call56:sub_19B7EC
(mainELF)call57:mmap
(KEkeELF)call58:sub_A3EC
(KEkeELF)call59:sub_9944
(mainELF)call60:sub_18DCC0
(mainELF)call61:sub_18F6AC
(mainELF)call62:sub_18DDA8
(mainELF)call63:sub_18DD94
(mainELF)call64:sub_18DDB8
(mainELF)call65:sub_18E8D0
(mainELF)call66:sub_18E244
(mainELF)call67:j_j__ZdlPv_5
(mainELF)call68:sub_129468
(mainELF)call69:sub_12D478
(mainELF)call70:sub_1A19EC
(KEkeELF)call71:raise
(KEkeELF)call72:j_lseek_2
(KEkeELF)call73:sub_9A90
(KEkeELF)call74:j_lseek_0
(KEkeELF)call75:j_lseek_3
(mainELF)call76:sub_19BC9C
(mainELF)call77:sub_11CF8C
(mainELF)call78:sub_131D58
(mainELF)call79:memmove
继续跟着调用的函数一处一处到ida里面看,在下面的函数中我们终于有了收获 (mainELF)call45:sub_1A1B7C
(mainELF)call46:memset
(mainELF)call47:sub_1A1D84
(mainELF)call48:sub_1A1E74
这个算法,看起来又是RC4呐 
hook一下这个函数,发现密钥是b"\x68\x76\x99\x72\x96\x60\x9f\x63\x96\x2c\x98\x30\xc2\x36\x51\x42" 
再去hook sub_1A1E74看看传入了什么数据,我们发现前三部分都是f7 4f e8 0e开头的 
看到这些数据,终于离成功又更进一步了,因为这些数据就是我们读取完壳DEX尾部的前0x41E个加密数据并解密出配置信息之后的那部分加密数据,同时我们也可以在010editor中通过搜索壳DEX找到它们,这三部分加密数据段所在的位置分别为0x35CE,0x3A93AD,0x417064 
我们先来到第一个数据段的位置来分析数据段的结构,这个位置是在0x31A4+0x41E,即0x35c2之后 
所以这dex的第一个解密算法如下 def RC4(data, key):
S = list(range(256))
j = 0
out = []
# KSA Phase
for i in range(256):
j = (j + S[i] + key[i % len(key)]) % 256
S[i], S[j] = S[j], S[i]
# PRGA Phase
i = j = 0
count = 1
for ch in data:
i = (i + 1) % 256
j = (j + S[i]) % 256
S[i], S[j] = S[j], S[i]
out.append(ch ^ S[(S[i] + S[j]) % 256])
return out
def RC4decrypt(ciphertext, key):
return RC4(ciphertext, key)
key = b"\x68\x76\x99\x72\x96\x60\x9f\x63\x96\x2c\x98\x30\xc2\x36\x51\x42"
with open('com.oacia.apk_protect/classes.dex', 'rb') as f:
enc_data = f.read()
start = 0x35C2
dexcount = int.from_bytes(enc_data[start:start+4],'little')
start+=4
for i in range(dexcount):
total_data_len = int.from_bytes(enc_data[start:start+4],'little')
start+=4
rc4_data_len = int.from_bytes(enc_data[start:start+4],'little')
start+=4
enc_dex = enc_data[start:start+rc4_data_len]
start+=rc4_data_len
dec_dex = RC4decrypt(enc_dex,key)
dec2_data_len = int.from_bytes(dec_dex[9:13],'little')
with open(f'dex{i+1}.dex','wb') as f:
f.write(bytes(dec_dex))
extra = enc_data[start:start+total_data_len-rc4_data_len]
extra_data_base = int.from_bytes(dec_dex[5:9], 'little')
extra_data_len = len(extra)
start+=total_data_len-rc4_data_len-4
print(f"part{i + 1}: total_data_len: {hex(total_data_len)}, rc4_data_len: {hex(rc4_data_len)}")
print(f"rc4_dec_part{i + 1}: extra_data_base: {hex(extra_data_base)},extra_data_len: {hex(extra_data_len)}, dec2_data_len: {hex(dec2_data_len)}")
with open(f'dex{i+1}_extra.dex','wb') as f:
f.write(bytes(extra))
但是光这还不够,因为rc4解密出来的数据仍然不是DEX格式 
之后继续跟着函数调用链走,找到这些函数 (mainELF)call60:sub_18DCC0
(mainELF)call61:sub_18F6AC
(mainELF)call62:sub_18DDA8
(mainELF)call63:sub_18DD94
(mainELF)call64:sub_18DDB8
在sub_18F6AC中的代码感觉很像是算法相关 
通过hook其中的sub_18DDB8函数发现a3是rc4解密之后的从0xc开始的数据段 
而前面的0xc位额外数据的读取方式为5+4+4,在sub_18DCC0中有读取操作,通过这样的读取操作我们可以依次得到0x010000005D,0x400000,0x109492 
这里的0x109492表示的是第二次解密的数据段的大小,那么0x40000表示什么呢? 还记得我们的加密数据段是有前后两部分的嘛,前半部分用rc4解密,那么后半部分我们来看看长什么样子好了 
后半部分的数据看起来十分的规整,不像是有加密的样子 而在主DEX加载流程分析中,我们成功的dump出了主DEX,那么我们不妨把这个这里的数据到主DEX中搜索一番看看有什么发现吧 在主DEX中搜索第一行的字节,我们惊喜的发现竟然可以搜索到,并且它的位置正好就是0x400000! 
所以说经过RC4解密之后的这部分的数据结构我们也就可以知道了 
接下来我们只要搞清楚在sub_18DDB8中第二次解密的算法是什么就可以了 我们再回到分析的起点sub_128D44函数,来看看能不能有其他的发现 
通过hook sub_128D44的返回值v150之后发现,三级指针指向着解密之后的dex console.log(hexdump(ptr(ptr(ptr(this.context.x0.readS64()).add(0x0).readS64()).readS64()), {
offset: 0,// 相对偏移
length: 0x40,//dump 的大小
header: true,
ansi: true
}));
而倘若我们观察这个解密数据所在的内存703bc75000,它正好是0x1000的倍数,而0x1000正好就是一页的大小 这意味着什么呢? 这说明dex所在的内存极有可能是通过mmap函数分配的! 而在stalker_trace_so打印的数据中,正好就有这个函数被调用了 (mainELF)call57:mmap
于是我们来到mmap被调用的函数 
使用frida hook mmap返回的内存指针,然后打上内存读写断点,就可以帮助我们快速定位到最终解密算法完成之后赋值的地址 function hook_mmap(){
var module = Process.findModuleByName("libjiagu_64.so");
Interceptor.attach(module.base.add(0x19B81C), {
// fd, buff, len
onEnter: function (args) {
console.log("mmap!")
console.log(this.context.x0);
MemoryAccessMonitor.enable(
{
base:this.context.x0,
size:30
},{
onAccess: function (details) {
console.log(details.operation)
console.log(get_addr_in_so(details.from));
}
}
)
},
onLeave: function (ret) {
}
});
}
function get_addr_in_so(addr){
var process_Obj_Module_Arr = Process.enumerateModules();
for(var i = 0; i < process_Obj_Module_Arr.length; i++) {
if(addr>process_Obj_Module_Arr[i].base && addr<process_Obj_Module_Arr[i].base.add(process_Obj_Module_Arr[i].size)){
return addr.toString(16)+" is in "+process_Obj_Module_Arr[i].name+" offset: 0x"+(addr-process_Obj_Module_Arr[i].base).toString(16);
}
}
return addr.toString(16);
}
在0x18ebd4中将值写入最终的目标内存,这个地址在sub_18E8D0中 
 在这个函数的开头,有对参数a1的读取操作 
我们hook一下值来看看a1各个部分都有什么含义 
给a1写一个结构体好了 struct dec2_struct{
long long shift_bit;//移位的位数
int reversed0;
int reversed1;
long long constA;
long long dest;//解密后的dex存储的地址
long long constB;
long long constC;
long long index;
long long extra_dex_base;//额外数据将要复制到的基址
int guess_count2;
int reversed2;
int flag;
int key[4];
int reversed3;
int reversed4;
int reversed5;
int data_len;//记录额外数据的长度
int input_read_index;//记录读取输入的加密数据的下标
unsigned char data[0x112];//记录额外数据
}
最后带着我们的结构体逛逛这个解密算法的函数好咯 sub_18F6AC 
sub_18DDB8 
sub_18E244 
sub_18E8D0 
这些函数无壳无花无打乱,也没有vmp加固,显得相当的干净,看起来是一个自定义算法 算法千变万化,但是加固永远不是重在算法 逆向一款优秀的加固壳,从中学习到的知识可以受益终生,同时也可以借此思考如何避免让别人轻易找到加固方案的突破口 逢山开路，遇水搭桥。兵来将挡，水来土掩。 我们最后来hook一下下面这个地方来为我们的分析画上圆满的句号吧 
至此,加固壳分析完毕 这个加固壳和常规的加固方案类似,也是壳DEX->壳ELF->主ELF->主DEX这样的过程,其中壳ELF解密主ELF所用到的算法是RC4和uncompress,壳ELF加载主ELF所用到的技术是自实现linker加固so 当然这个加固壳还有许多值得继续研究的地方,例如分发so函数的vmp其内部逻辑究竟是什么样子呢?native化的onCreate函数,dex2c的原理究竟是什么呢?这些都还有待探索,就把它们交给时间和未来的不眠之夜吧 月遇从云，花遇和风，今晚上的夜空很美。
下方隐藏内容为本帖所有文件或源码下载链接：
游客你好，如果您要查看本帖隐藏链接需要登录才能查看，
请先登录
|
发表于 2024-03-17 00:05
发表于 2024-09-10 01:44:27.0
评分
顶
踩
扫码赞助