[原创]APP加固dex解密流程分析-Android安全-看雪安全社区

[原创]APP加固dex解密流程分析

发表于: 2024-2-22 04:44 74970

[原创]APP加固dex解密流程分析

oacia

2024-2-22 04:44

74970

# 前言

> 在去年9月的时候,我就想研究一下apk的加固,在网上逛了一圈,感觉有一个加固不错,所以先选它啦,写了一个测试apk丢到这个加固里面加固了一下
>
> 这里我用的是这个加固的免费版(因为付费版太贵啦)
>
> 本来计划着去年分析完的,但是总是抽不出一段完整的时间来所以就拖到了现在,终于最近因为过年赋闲在家,就花了几天分析了一下,感觉这几天探索加固壳的过程真是充满了惊喜和乐趣呢~
>
2024年3月8号记:

> 距离上次看这个加固已经半个月啦,今天正想着自己要做什么事情的时候,到博客看了眼TODOlist,突然发现咦我是不是还没看过dex的解密算法长什么样?所以今天就把这个给做完了,不得不说逆向真的是消磨无聊时间最有效的方法哈哈哈

# java层初步分析

包名:`com.oacia.apk_protect`

入口:`com.stub.StubApp`

我们从`AndroidManifest.xml`中可以得知,这个加固的入口是`com.stub.StubApp`,所以我们就先进到apk的入口进行分析

![image-20230930183634640](upload/attach/202402/963320_9G8MNFNAYXD6NBZ.png)

在这个入口类中,不仅有常规的`onCreate()`函数,还有一个函数值得注意,他就是`attachBaseContext(Context context)`

![image-20230930183713453](upload/attach/202402/963320_QVUGRKF3BFVAUYU.png)

> Application 的`onCreate`和`attachBaseContext`是 Application 的两个回调方法，通常我们会在其中做一些初始化操作,`attachBaseContext` 在`onCreate`**之前执行**

其中出现的字符串经过了加密混淆操作,加密函数如下,算法是将所有的字符与`16`进行异或

![image-20230930183731411](upload/attach/202402/963320_2YXWJT4A6NRWJVF.png)

我们写个jeb脚本把加密字符串解密来方便后续的静态分析

```python
# 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')
```

解密后的效果如下

![image-20230930182440462](upload/attach/202402/963320_X3DH4R48XPZDPPG.png)

我们往下进行分析,可以知道`attachBaseContext`的第一个作用是根据目标手机的架构加载`libjiagu_xxx.so`如图

![image-20230930184207278](upload/attach/202402/963320_8QUXQNGNJJ58VB6.png)

这些so在`assets`目录下

![图片描述](upload/attach/202403/93_XPKHUCN4WP4N5VM.webp)

在加载完`libjiagu_xxx.so`之后,还调用了`DtcLoader`类进行初始化,这里使用的jadx的反编译结果,因为jeb没有反编译出`DtcLoader.init();`方法来

![image-20230930184605448](upload/attach/202402/963320_YQ744VNB2ESKB4V.png)

`DtcLoader`类如图所示

![image-20230930184748578](upload/attach/202402/963320_WTRH627XU3JGVFG.png)

当`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`存在

![image-20230930190258638](upload/attach/202402/963320_GGTSXDHBUHENUU2.png)

所以我们的分析重点是在`libjiagu.so`中,这里我选取了arm64架构的so文件`libjiagu_a64.so`进行分析

# 壳ELF导入导出表修复

我们使用ida分析`libjiagu_a64.so`,发现导入表和导出表都没有内容,既然是这种情况,那么应该是在so装载进内存时导入导出表才会去进行相应的链接操作

![image-20231118145804113](upload/attach/202402/963320_9WEU7EJGZGP35QG.png)

所以我们可以先用frida把这个so给dump下来

首先我们在手机上运行一下frida server

```shell
PS D:\frida> adb shell
blueline:/ $ su
blueline:/ # cd /data/local/tmp
blueline:/data/local/tmp # ./fs -l 0.0.0.0:1234
```

随后做一下端口转发

```shell
adb forward tcp:1234 tcp:1234
```

frida命令行语句如下

```shell
frida -H 127.0.0.1:1234 -l .\hook.js -f "com.oacia.apk_protect"
```

注入如下脚本

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"));
```

![image-20231118150855726](upload/attach/202402/963320_2GPCZ7RW6V45ZN4.png)

随后我们使用<a href="elink@13aK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6r3z5p5I4q4c8W2c8Q4x3V1k6e0L8@1k6A6P5r3g2J5">SoFixer</a>修复一下这个so,这里的`-m`参数即这个so在内存中的`base`基地址

```shell
.\SoFixer-Windows-64.exe -s .\libjiagu_64.so_0x74a2845000_0x274000.so -o .\libjiagu_64_0x74a2845000_0x274000_fix.so -m 0x74a2845000 -d
```

修复完成后,导入表和导出表就恢复了

![image-20231118151321228](upload/attach/202402/963320_SUNRBRTETWNMDUQ.png)

# 加固壳反调试初步分析

首先我们去hook一下打开so的函数

```js
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`中

```shell
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`

```js
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");
```

日志如下

![image-20231119122024522](upload/attach/202402/963320_HTX6TECNG6JDK8V.png)

这里我们发现了`/proc/self/maps`,这是常见的反调试,要绕过这个检测,我们可以备份一个正常的`maps`文件,然后用frida去hook `open`函数,如果匹配到字符串`maps`,就将字符串重定向到我们备份的`maps`文件

首先我们正常打开一次加壳的apk,然后使用下列命令备份maps

```shell
cp /proc/self/maps /data/data/com.oacia.apk_protect/maps
```

然后我们注入如下frida脚本

setImmediate(my_hook_dlopen,"libjiagu");
```

但是当注入这段脚本后,进程由于非法内存访问而退出了,这说明加固壳不仅读取maps文件,并且会尝试访问maps文件中所记录的文件或内存映射.这里由于frida注入后重启apk,但是备份的maps文件中记录的是先前的映射起始地址(这块内存在关闭apk后就被抹去了),所以当壳尝试访问其中的映射时产生了非法内存访问从而让进程崩溃

![image-20240212225108205](upload/attach/202402/963320_QUXS278UQ3GEZRY.png)

这里我的解决方式是将上述frida代码中的`fakePath`赋值为一个不存在的文件例如`/data/data/com.oacia.apk_protect/maps_nonexistent`,来让壳没有内容可以访问

修改完`fakePath`后重新注入代码,这个打印出来的日志可以说非常有意思,我们来看一下,相比hook `open`之前的日志,我们成功的让这个加固壳释放出了dex

![image-20240213225015953](upload/attach/202402/963320_GV29GNEHSPXDE96.png)

然而这个壳似乎是又发现了些什么异常,随后赶紧让app退出了,但是由于退出的太过仓促,它甚至还没有来得及把dex从文件夹中删除

![image-20231117143717038](upload/attach/202402/963320_BQ6KAW9HDX3DSN9.png)

用010editor打开`classes.dex`,发现前几位并不是dex的魔术头,说明这个dex还没有被解密,不过现在我们只需要分析dex如何被壳从内存中释放出来的过程就可以了~

![image-20231117143828767](upload/attach/202402/963320_V2EJSE4MKG66KBS.png)

如何可以定位到是什么位置调用了`open`函数来打开`classes.dex`呢?

很简单,打印一下堆栈就可以了

假如我们使用常规的frida打印堆栈代码,即使用`DebugSymbol.fromAddress`函数来判断地址所在的`so`的位置,那么进程是会报错退出的

```js
console.log('RegisterNatives called from:\\n' + Thread.backtrace(this.context, Backtracer.FUZZY).map(DebugSymbol.fromAddress).join('\\n') + '\\n');
```

所以这里`DebugSymbol.fromAddress`所实现的逻辑需要自己编写,即下方的`addr_in_so`函数

```js
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']));
}

于是我们得到了释放三个dex文件的堆栈回溯

* `classes.dex`
  ![image-20240213225949584](upload/attach/202402/963320_CSBWY9SXQSUETM9.png)
* `classes2.dex`
  ![image-20240213230022534](upload/attach/202402/963320_6E2MPVBVAF9Z9DT.png)
* `classes3.dex`
  ![image-20240213230048818](upload/attach/202402/963320_3YFJH6JPEVBKC5K.png)

这里我们发现`classes.dex`与`classes2.dex`的堆栈回溯完全相同,并且`classes3.dex`的前半部分和前两个dex的堆栈一样,随后进程便又退出了

通过对堆栈的分析,我们可以发现三个dex应该是在一个循环中被依次加载的

接下来我们便跳转到堆栈所打印的偏移来进一步分析下

然而当我们跳转到堆栈回溯中的`libjiagu_64.so`的偏移`0x19b780`或者`0x134598`时,却发现这些地址的值都是0

![image-20240213232138840](upload/attach/202402/963320_7JX5AGYBSTZEBU8.png)

![image-20240213232208410](upload/attach/202402/963320_JND9XHKKK8GVVPA.png)

我们很快就能想到这里用到的技术应该是先将一块内存标记为可写可执行,随后将字节码填充进去,所以说,我们只需要在壳打开dex时,将此时的`libjiagu_64.so`从内存中dump下来就可以了

```js
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);
    }
}

然后再去用<a href="elink@879K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6r3z5p5I4q4c8W2c8Q4x3V1k6e0L8@1k6A6P5r3g2J5">SoFixer</a>修复这个dump下来的so

```shell
.\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`处,可以发现这块空内存已经被填充了数据

![image-20240213233913165](upload/attach/202402/963320_8KUDETUFDP2WBGE.png)

接下来我们想知道的是究竟是从什么地方开始被填充了新的数据,所以我们可以用WinMerge来让填充和未填充数据的so进行比较看看,结果却有了惊人的发现,被填充的数据是从`0xe7000`开始的,它的开头竟然是ELF文件的魔数头!?这有意思了,那么就是一个so里面藏了另外一个so咯~

![image-20240213234737987](upload/attach/202402/963320_JHC4VWFPFHVGKM2.png)

我们写个python脚本,把这个ELF从`0x0e7000`开始后面的所有字节都复制到新的文件里面

```python
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`被加密了

![image-20240220220722659](upload/attach/202402/963320_6WFEBTZ6389NCR6.png)

这就导致ida根本就无法进行正常的分析

![image-20240217212952888](upload/attach/202402/963320_VEHWN8XG2GTN7RA.png)

![image-20240217213007622](upload/attach/202402/963320_GCR3CEHD29H5XFT.png)

# 主ELF解密流程分析

壳elf加载主elf,并且program header还被加密了,感觉这种形式很像是 **自实现linker加固so**

对于这种加固方式,壳elf在代码中自己实现了解析ELF文件的函数,并将解析结果赋值到`soinfo`结构体中,随后调用`dlopen`进行手动加载

来到ida里面在导入表对`dlopen`进行交叉引用,我们看到dlopen有5个交叉引用

![image-20240218174655222](upload/attach/202402/963320_G5D886AQ4PWUE6R.png)

看到第二个交叉引用,来到`sub_3C94`函数,这个for循环看起来像是在用符号表通过dlopen加载依赖项

![image-20240218174801778](upload/attach/202402/963320_WMXWCWVJ4G9PEVH.png)

向上面翻翻代码,看到这个switch就知道找对地方了,这里应该就是自实现linker来加载so的

![image-20240218175140788](upload/attach/202402/963320_NQ66CZQ8ZSYFKK5.png)

因为这和AOSP源码(`android-platform\bionic\linker\linker.cpp`)中的预链接(`soinfo::prelink_image`)这部分的操作极为的相似

![image-20240218175438786](upload/attach/202402/963320_MZHDQFWNU7BREU2.png)

那接下来就在ida中导入soinfo相关的符号就可以啦

在ida中依次点击`View->Open subviews->Local Types`,然后按下键盘上的`Insert`将下面的结构体添加到对话框中

```c
//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*`

![image-20240218175803731](upload/attach/202402/963320_2JB9E93A6TPTMMN.png)

然后就可以看到这些符号了,但是看这些符号总感觉有些不太对劲,这里不应该出现`a1[1]`或者`a1[2]`,所以我猜测这个soinfo有被魔改的痕迹

![image-20240219144353027](upload/attach/202402/963320_TTB39SUSMXHQKGB.png)

虽然这个soinfo可能有被魔改了,我们还是从`sub_3C94`这个预链接相关函数入手好了,交叉引用发现`sub_3C94`是被`sub_49F0`调用

随后我们来到`sub_49F0`内调用`sub_3C94`函数的位置,向下看,进入`sub_4918`函数中

![image-20240219181823744](upload/attach/202402/963320_SVUYVK4PH3MAMPK.png)

`sub_4918`中调用了`sub_5E6C`,我们进入`sub_5E6C`

![image-20240219181928308](upload/attach/202402/963320_62M6YZTBSFQK8UV.png)

这个函数中出现了`0x38`这个数字,`0x38`是这个循环的步长

![image-20240219184405967](upload/attach/202402/963320_NH5ZAE6B6KVKB63.png)

0x38这个数字有什么特殊的含义吗?当然有了!!

我们把刚刚提取出来的elf用`010editor`打开,看到`elf_header`的`phentsize`这个字段,这个字段的含义是一个`Program header table`的长度,它正正好好也是`0x38`

![image-20240219184824589](upload/attach/202402/963320_KX7EW9RXYDDURXA.png)

所以说在`sub_5E6C`中变量`v5`的类型应该是`Elf64_Phdr *`,我们直接重定义类型

![image-20240219185005955](upload/attach/202402/963320_UE2JDDD3GFWP5QV.png)

既然知道了真正的`program header table`就是在这个位置的,那我们直接在这个地方把`program header table`整个给dump下来不就行了

所以我们直接去hook`sub_5E6C`的三个传入的值

```js
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) {
        }
    });
}
```

![image-20240219185724473](upload/attach/202402/963320_YPZBWW68B5SX6DS.png)

上面的第一个hexdump就是`program header table`,我们可以用`cyberchef`将`hexdump`转成数组的形式

![image-20240219190012572](upload/attach/202402/963320_YSMNQETKM3FQTT4.png)

`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`的位置

![image-20240219191502430](upload/attach/202402/963320_NTMK74J4N35WFRZ.png)

那假如`a1`的类型就是`soinfo*`,为什么在`sub_4918`里面调用`sub_5E6C`传入的是偏移是`232`呢?

![image-20240219191628154](upload/attach/202402/963320_P6G6Z2A3THKJ8TW.png)

所以`soinfo*`必定有被魔改,同时我们也可以在soinfo前填充一个大小为232的char类型数组看看是什么情况

![image-20240219191808113](upload/attach/202402/963320_Q5V285KKW97X42A.png)

很好,这验证了我们对于`soinfo*`被魔改的猜测,因为在一切正常的情况之下,函数的调用应该是`sub_5E6C(a1->phdr, a1->phnum, a1->base)`才对

![image-20240219191839316](upload/attach/202402/963320_3V72AXUNJD3UDHH.png)

但是我很想知道这个壳ELF究竟是如何被解密出来的,那么首先来看看主ELF的函数调用链是什么样子的吧~

我写了一个ida插件来实现这个过程<a href="elink@424K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6G2j5h3y4A6j5g2)9J5c8Y4y4@1j5h3I4C8k6i4u0Q4y4h3k6@1M7X3q4U0k6g2)9#2k6Y4y4G2">stalker_trace_so</a>

在IDA中使用`Edit->Plugins->stalker_trace_so`后,在so所在的目录下会生成一个js脚本,我们用frida注入到apk中即可,需要注意的是`so_name`需要改成`libjiagu_64.so`

![image-20231118152818874](upload/attach/202402/963320_5RSEFHPK7T3H9P9.png)

打印出来的完整日志如下

```c
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`调用

![image-20240219195550519](upload/attach/202402/963320_QKT7M8V5CR7XWBJ.png)

我们将`stalker_trace_so`打印出来的内容中,提取关键的部分拿过来看看,说明`sub_4B54`是被`sub_8000`调用的

```c
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`这个数字,后面会派上用场的

![image-20240219200830705](upload/attach/202402/963320_6SX6YBJM6DQWCKF.png)

跟着函数调用链一处一处的在IDA中跳转到相应的地址进行查看,在`call62:sub_5F20`我们发现了有意思的代码

这个函数,一眼RC4呀

![image-20240219200139731](upload/attach/202402/963320_NDCVYQHNFT89YQR.png)

用frida去hook一下这个函数看看RC4的密钥是什么

```js
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) {

}
    });
}
```

![image-20240219200302071](upload/attach/202402/963320_Z9PFFE26C99Q8XG.png)

所以密钥就是这个咯

```python
key = b"vUV4#\x91#SVt"
```

继续跟着函数调用链走,在`call63:sub_6044`我们发现了RC4的解密函数

![image-20240219200510607](upload/attach/202402/963320_54VHCKBQXZ8HYY8.png)

hook一下`call63:sub_6044`看看到底给什么数据解密了

```js
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
            }));
        }
    });
}
```

![image-20240219200703480](upload/attach/202402/963320_KMTRP3X878UJJTK.png)

这个函数的第二个参数是`0xb8010`,感觉是解密的数据的长度的样子,而且这个数字,有没有感觉在哪里见过呢?

没错,这个数字刚刚就出现在`sub_8000`中

![image-20240219201000793](upload/attach/202402/963320_BUEQPTKH6HHZ7SU.png)

而`v5[0]`的值是`qword_2E270`,这个数组也是`01 18 25 e7`开头的

![image-20240219201131482](upload/attach/202402/963320_3EUHYVSZ4NGW9SS.png)

继续跟着调用链走,接下来是调用`call65:uncompress`,进行解压缩操作

```js
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`没有包含在解压缩的字节之内

![image-20240219202037098](upload/attach/202402/963320_46P6XGB8EVT9KCX.png)

现在既然我们已经知道了主ELF在壳ELF中的位置,以及解密的算法,那我们直接从解压apk,找到里面的`assets/libjiagu_a64.so`,不就能直接把壳ELF解密出来咯

```python
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`应该表示解压缩之后数据的大小

![image-20240220214503336](upload/attach/202402/963320_G7DGM3PCAGJ2AYT.png)

![image-20240220131405321](upload/attach/202402/963320_CP78MFKPAE9PAFT.png)

`wrap_elf`的前半部分是一大堆莫名其妙有很多`D3`的东西,但是看到中间还是发现了壳ELF的身影

![image-20240219203139130](upload/attach/202402/963320_UCEQQDKJTTXHZKJ.png)

我们以`.ELF`为标志将这两部分分离一下

```python
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

![image-20240220000932490](upload/attach/202402/963320_7GFNFDD8W3T8KMJ.png)

这正好和`phentsize`和`phnum`的值相对应

![image-20240220001104708](upload/attach/202402/963320_QWVTNTWH3SE5M2Q.png)

所以可想而知,这又是一个关键点了,往下看一下代码,发现了循环异或,那我们不妨用frida把`v4`的值hook下来看看是什么

![image-20240220001342895](upload/attach/202402/963320_VAJCC78K8WXXV62.png)

v4的值出现了那么多的`d3`

![image-20240220001528743](upload/attach/202402/963320_23N4A89WUZ77KNZ.png)

而这就是`wrap_elf`的前半部分那一大堆我们看不懂的字节

![image-20240220012621743](upload/attach/202402/963320_Q2Q79X9FTSNGHJ9.png)

接下来用来解密的循环就是一个arm64的neon运算

![image-20240220003908902](upload/attach/202402/963320_QAKQX4M2ZWYTDKR.png)

官网可以找到<a href="elink@c24K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6V1k6i4k6W2L8r3!0H3k6i4u0Q4x3X3g2S2M7X3#2Q4x3X3g2U0L8$3#2Q4x3V1k6S2M7X3y4Z5K9i4c8W2j5%4c8#2M7X3g2K6i4K6u0r3K9h3&6K6N6s2u0#2j5%4c8A6L8$3&6Q4x3X3c8K6k6i4c8K6i4K6u0r3K9h3&6@1M7X3W2F1M7$3W2U0M7#2)9J5c8W2)9J5x3%4q4Q4x3@1c8$3k6s2g2H3M7g2)9#2k6X3&6Q4y4h3k6K6z5l9`.`.">vdupq_n_s8</a>和<a href="elink@adfK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6V1k6i4k6W2L8r3!0H3k6i4u0Q4x3X3g2S2M7X3#2Q4x3X3g2U0L8$3#2Q4x3V1k6S2M7X3y4Z5K9i4c8W2j5%4c8#2M7X3g2K6i4K6u0r3K9h3&6K6N6s2u0#2j5%4c8A6L8$3&6Q4x3X3c8K6k6i4c8K6i4K6u0r3K9h3&6@1M7X3W2F1M7$3W2U0M7#2)9J5c8W2)9J5x3%4q4Q4x3@1c8$3k6h3!0J5M7g2)9#2k6Y4x3^5">veorq_s8</a>,根据函数描述可以知道这里用向量运算,把向量中的每一个元素都异或了`0xd3`

![image-20240220004233903](upload/attach/202402/963320_SHVPGU5YYTTFVVW.png)

![image-20240220004029770](upload/attach/202402/963320_4A3Y46FRSRBZB7P.png)

对`sub_5B08`进行分析之后,我们便可以知道`wrap_elf_part1`的读取方式是第一个字节表示被异或的数字,这里是`0xD3`,后面的四个字节表示一个段的长度,随后读取指定长度的字节并异或,之后再读取四个字节获取到下一个段的长度,以此类推,直到读取到文件末尾

![image-20240220012939262](upload/attach/202402/963320_WXJ6XACGDK2S3CY.png)

在`sub_5B08`的最后,因为`v31`,`v19`,`v43`,`v7`代表对应的数据组的长度,所以这里共有四个数据组,而为了表示每一个数据组的长度共需占用`4*4=16`字节,并且文件开头还有`1`位的异或值,于是这些长度加起来,`*(a1 + 0x98)`的偏移就来到了主ELF的魔术头`.ELF`的位置了

![image-20240220013039190](upload/attach/202402/963320_GVNTTZT9EXGHAXV.png)

![image-20240220013502056](upload/attach/202402/963320_Q5A7C85RJX4MYH5.png)

我们可以在`sub_5B08`中为变量`a1`定义一个结构体,成员分别表示数据组的1,2,3,4这四个部分,这样我们就知道这四个部分分别被用到什么地方了

```c
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;
};
```

![image-20240220023743626](upload/attach/202402/963320_3H38Q9AY2XCBQKU.png)

接下来再捋一下函数的调用链`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的偏移可以对应这些变量

![image-20240220024254105](upload/attach/202402/963320_W74FU4E6HQNQ9VK.png)

```c
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;
};

```

![image-20240220024130734](upload/attach/202402/963320_7F74SSG5B5QET7B.png)

这样做有什么意义呢?

我们发现变量`v7`分别被传入到了`sub_3C94`和`sub_4918`中,我们分别进去看看

![image-20240220024433454](upload/attach/202402/963320_5TD6NVR2MGJMD2Q.png)

在`sub_3C94`中解析了`extra_part4`,显而易见,这个`switch`是用来处理动态链接库的,即`extra_part4`对应`.dynamic`段

![image-20240220024522541](upload/attach/202402/963320_YYSTVUGSAHTBJ55.png)

![image-20240220024831366](upload/attach/202402/963320_AY8747TPUH8T87Y.png)

在`sub_4918`中,`extra_part2`和`extra_part3`被传入到`sub_4000`中

![image-20240220024916186](upload/attach/202402/963320_6J73FGUTG5A2FNQ.png)

而这个函数中的`switch`是用来处理重定位的,因为重定位主要有基址重定位和符号重定位,这两个的值分别是`0x403`和`0x402`

所以`extra_part2`和`extra_part3`分别对应着`.rela.plt`(402重定位)和`.rela.dyn`(403重定位)

![image-20240220025025814](upload/attach/202402/963320_C8HY3BX7UVE4RQP.png)

![image-20240220145850194](upload/attach/202402/963320_N84RVE27PD8AHVQ.png)

而之后`extra_part1`被传入到了`sub_5E6C`中

![image-20240220025453629](upload/attach/202402/963320_6JQUN253DSMRU78.png)

而来到`sub_5E6C`也来到了我们最开始分析的起点(兜兜转转又回来了),所以`extra_part1`表示`program header table`

![image-20240220025540021](upload/attach/202402/963320_D9AVRZXDSQZ79HM.png)

至此为止,四个数据组所对应的段都分析完成

* `数据组1`表示`program header table`
* `数据组2`表示`.rela.plt`
* `数据组3`表示`.rela.dyn`
* `数据组4`表示`.dynamic`

所以接下来,写个脚本把这四个数据组给分离成单独的文件咯

```python
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)
```

于是我们得到了这四个文件

![image-20240220220013192](upload/attach/202402/963320_DFAMDEAEMR9H77D.png)

![image-20240220220022117](upload/attach/202402/963320_J6CVKAGN2K6MN68.png)

# 主ELF导入导出表修复

需要被修复的主ELF是我们在从`assets/libjiagu_a64.so`利用`RC4`和`decompress`解密出来的文件的后半部分那个ELF

可以写个python脚本分离出后面的ELF

```python
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`可以粘贴整块内存

1. 修复`program header table`

复制`libjiagu.so_0x150_phdr`的所有字节,然后来到`libjiagu_0xe7000.so`中选中`struct program_header_table`粘贴

![image-20240220223148864](upload/attach/202402/963320_RFKKMSDZ5CB84UU.png)

随后按下`F5`刷新模板

2. 修复`.dynamic`

`program header table`的`(RW_) Dynamic Segment`的`p_offset`指向`.dynamic`段的位置
   ![image-20240220223253986](upload/attach/202402/963320_4Z2XMUHDACQVJP6.png)
   跳转到该位置,复制`libjiagu.so_0x1b0_.dynamic`的内容并粘贴到这个位置

3. 修复重定位表
   我们需要通过`.dynamic`段的`d_tag`字段来找到重定位表的位置,下面是AOSP中`d_tag`的宏定义
   ![image-20240220172348458](upload/attach/202402/963320_NG24GWRKJYN55RU.png)

所有的`d_tag`标志对应的含义可以在<a href="elink@b93K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6V1L8$3y4K6i4K6u0W2L8%4u0S2j5$3I4W2i4K6u0W2j5$3!0E0i4K6u0r3j5$3c8Q4x3V1k6q4x3U0b7^5y4o6N6Q4y4h3j5H3x3g2)9J5c8X3S2@1L8h3I4Q4x3V1k6q4x3U0t1I4z5e0k6Q4x3V1k6@1L8$3y4Q4x3X3g2Z5N6r3#2D9">ORACLE 链接程序和库指南 </a>中找到

对于我们修复主ELF比较重要的`tag`有

| d_tag       | 值   | 含义                      |
| ----------- | ---- | ------------------------- |
| DT_JMPREL   | 0x17 | `.rela.plt`在文件中的偏移 |
| DT_PLTRELSZ | 0x2  | `.rela.plt`的大小         |
| DT_RELA     | 0x7  | `.rela.dyn`在文件中的偏移 |
| DT_RELASZ   | 0x8  | `.rela.dyn`的大小         |

我们可以在`.dynamic`中发现这些`tag`以及对应的值

![image-20240221131839098](upload/attach/202402/963320_T8VW6KQAXA8S5E8.png)

看看这两个大小分别是`0x1650`和`0x25188`,这不就和我们刚刚分离出来的文件大小一模一样嘛,说明我们离修复完成不远了

![image-20240220224638674](upload/attach/202402/963320_A2JXGJ3AED2E6HN.png)

然后就是和之前一样,跳转到`.rela.plt`和`.rela.dyn`的对应地址,然后把这些段本来的数据粘贴进去

现在我们就修复好啦,拿ida打开主ELF看看,满满的都是符号!

![image-20240221131944227](upload/attach/202402/963320_DS65D39ETZ4PBSP.png)

随便找个导入函数交叉引用看看,一切正常`(●'◡'●)`

![image-20240221132044506](upload/attach/202402/963320_7HCT6N2J7M8Z4XT.png)

为了方便起见,我们可以将主ELF的基址定义成在其在壳ELF的偏移`0xe7000`方便后续的分析

# 主DEX解密流程初步分析

还记得在**加固壳反调试初步分析**中,我们拿到了未解密的dex嘛

![image-20240220231727044](upload/attach/202402/963320_NCB62GESABYUM84.png)

那么接下来有个问题就是,这个未解密的dex究竟藏在了apk的什么地方呢?

我将未加固的apk解压出来,然后用7zip压缩其中的dex,发现大小依然有2.8MB

![image-20240220231901275](upload/attach/202402/963320_4JP9N7U6EMCSPPY.png)

随后我将经过加固之后的apk解压出来,按大小对文件进行排序之后发现,最大的文件就只有这个壳`classes.dex`,而别的文件甚至连1MB都没到,总不可能压缩率可以高到这种地步吧

![image-20240220232029056](upload/attach/202402/963320_28ZMF67TE9RKV2G.png)

所以我们打开`classes.dex`看看,在这个`classes.dex`的末尾,果然藏着一大堆的数据

![image-20240220232313676](upload/attach/202402/963320_GJP6VZB46NP5BKV.png)

而末尾的数据是由`71 68 00 01`和我们之前看到的加密的dex一模一样

接下来我们继续用<a href="elink@a02K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6G2j5h3y4A6j5g2)9J5c8Y4y4@1j5h3I4C8k6i4u0Q4y4h3k6@1M7X3q4U0k6g2)9#2k6Y4y4G2">stalker_trace_so</a>去看看补充上主ELF的函数地址以及名称之后的函数调用链是什么样子的,首先在主ELF中运行插件`Edit->Plugins->stalker_trace_so`

之后同样的,我们需要将`so_name`改成`libjiagu_64.so`,特别注意的是,这里我们需要把壳ELF的`func_addr`和`func_name`给复制过来,同时使用`concat`方法将主ELF和壳ELF的函数地址和函数名拼接成一个新的数组

![image-20240221141755126](upload/attach/202402/963320_87WG45Q78QESP5V.png)

之前替换`/proc/self/maps`来实现初步反调试的js函数`hook_proc_self_maps`也需要同时执行

输出结果如下,`KEkeELF`标志表示壳ELF,`mainELF`表示主ELF,(为什么是`KEke`,只是为了对齐看着舒服:))

要判断调用的函数在哪个ELF里面,在`trace_so()`里面稍作修改判断一下范围可以了

![image-20240221142103021](upload/attach/202402/963320_3X7Q4XCFARPJFZF.png)

打印出来的结果如下

```c
(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用来解压缩的函数嘛~

```c
(mainELF)call230:inflateInit2_
(mainELF)call231:inflate
(mainELF)call232:inflateEnd
```

对`inflateInit2_`交叉引用,发现有两个函数调用了它

![image-20240221160528463](upload/attach/202402/963320_RGNGYZUZP2CZMKW.png)

那么要怎么知道是哪一个函数先调用的`inflateInit2_`呢?向上看看函数调用链就行了

于是我们发现是`sub_1B6270`调用了`inflateInit2_`

```c
(mainELF)call227:sub_1B6270 <--
(mainELF)call228:sub_1B6180
(mainELF)call229:sub_1B6678
(mainELF)call230:inflateInit2_
(mainELF)call231:inflate
(mainELF)call232:inflateEnd
```

我们来到`sub_1B6270`,先到<a href="elink@b3cK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6E0j5h3c8D9k6i4u0Q4x3V1k6*7L8r3W2T1"><mark class="encrypted">19eK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6E0j5h3c8D9k6i4u0Q4x3V1k6*7L8r3W2T1</mark></a>把`zlib.h`中的`z_stream_s`,导入的方法和之前一样

```c
#  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`: 解压后数据的长度

![image-20240221162607623](upload/attach/202402/963320_UJFHCSNBQGTCTBZ.png)

各个成员的偏移如图所示

![image-20240221162856663](upload/attach/202402/963320_QRWQQNVVH4U3S45.png)

随后我们用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了

```js
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)`函数即可

![image-20240221170453897](upload/attach/202402/963320_8CNUHM7B49FTUJ9.png)

把这个解压缩之后的dex拖入到jadx里面,却发现这个类名怎么和壳DEX的类名一模一样,通过校验哈希发现dump下来的dex和壳dex其实是同一个文件

![image-20240221170627481](upload/attach/202402/963320_W9JT38BKG6AWJBN.png)

我们在之前的分析中知道壳dex的末尾附带了一大串的加密数据,所以通过将这个解压缩得到了这个dex,就说明马上要进行加密主DEX的解密操作了

解压缩的函数是`sub_1B6270`,接下来我们继续通过`stalker_trace_so`打印出来的内容,并利用交叉引用来追踪该函数的调用链

就比如说对于函数`sub_1B6270`,它有两个交叉引用

![image-20240221172325310](upload/attach/202402/963320_ASNFDQWWDEBHYQ7.png)

通过`stalker_trace_so`打印出来的函数调用链,我们发现是`sub_1A0C88`在`sub_1B6270`之前调用,所以函数的调用关系就是`sub_1A0C88->sub_1B6270`,以此类推

```c
(mainELF)call206:sub_1A0C88
(mainELF)call227:sub_1B6270
```

所以一路跟过来之后,函数的调用链为`sub_1332B8->sub_124FA0->sub_1A0C88->sub_1B6270->inflate`,`sub_1332B8`函数之后就没有交叉引用了

```c
(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

![image-20240221172717168](upload/attach/202402/963320_DUDUTNJBVYQ55N2.png)

---

在**加固壳反调试初步分析**的后半部分,我们打印出了加固壳打开dex的堆栈回溯,现在我们直接跳转到相对应的地方看看

![image-20240220225331054](upload/attach/202402/963320_6VM9JZGEAK2E9SM.png)

我们到`0x19b780`看看,看起来是一个标准的打开并写入文件的函数

![image-20240221133619261](upload/attach/202402/963320_VER9JRE4F7Q5RSF.png)

随后对该函数进行交叉引用,我们发现`sub_1332B8`竟然调用了它,就在刚刚我们就分析出这个函数中可是同时也执行了从内存中获取壳dex的操作的呢

![image-20240221173657553](upload/attach/202402/963320_8D8XVGV7UVTT543.png)

我们对这两处调用都hook一下看看是什么情况,打印的结果如下,说明这两处调用都打开了dex,`sub_1332B8`中的前一个调用打开了`classes.dex`,后一个调用打开了`classes2.dex`和`classes3.dex`,而`classes.dex`文件中的内容就是加密的主dex

![image-20240221174419522](upload/attach/202402/963320_PK8AJDC6ABSZS62.png)

在创建完`classes2.dex`和`classes3.dex`,通过hook发现调用在调用`sub_128D44`之后进程就退出了

![image-20240221180350649](upload/attach/202402/963320_CYU4ZJ2DQY9VHZE.png)

我们去hook一下`sub_128D44`这个函数,发现传入的参数`v8`正是加密的主DEX

![image-20240221184130805](upload/attach/202402/963320_SRR2H9VKYHB5ND2.png)

而`sub_128D44`函数是这个样子的,并且在壳ELF加载时启动`stalker_trace_so`的`trace_so()`函数所打印出的结果中,并没有这个函数的调用被打印出来

![image-20240221180415665](upload/attach/202402/963320_Y88WWABDV38GPPU.png)

这该怎么办呢?

很简单,在调用`sub_128D44`的位置再去调用一次`trace_so()`函数从现在的位置开始打印函数的调用链不就行咯:)

![image-20240221180705025](upload/attach/202402/963320_D7435DMAUU8AHRP.png)

函数调用关系如下,我们发现再`mainELF`调用完`sub_128D44`之后,通过一系列操作又回到了壳ELF中,最终调用`raise`导致进程退出

![image-20240221185357390](upload/attach/202402/963320_DA9QE2QPSS4WQZS.png)

然而,当我跳转到最后调用的几个函数时,可以说函数复杂到让人咋舌

![image-20240222005607295](upload/attach/202402/963320_9MDJ2JK77G3KZR8.png)

![image-20240222005639325](upload/attach/202402/963320_C6D6VFURBVYT9GP.png)

这么复杂,是给人分析的吗!?所以我便卡在这里了很久

我想了想现在摆在面前的有两条路,是和一眼望不到尽头的这俩函数死磕到底,还是选择把这个加固壳的反调试搞定?

我选择后者,因为明显搞定反调试要比把这两个函数分析明白要稍微简单一点

# 加固壳反调试深入分析

在**加固壳反调试初步分析**中,我曾尝试过`dbus`,`TracerPid`,`readlink`,`strstr`都没有明显的效果,只有hook `open`函数让我看到了些许的曙光,那么现在应该还有一种非常重要的反调试手段没有用到,那就是`pthread_create`反调试

```js
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);

注入代码之后,`pthread_create`的调用都指向了同一个地址`0x17710`

![image-20240222010902622](upload/attach/202402/963320_GJZ7NCADJUEMXZJ.png)

我们跳转到这个地址之后却发现为什么会没有`pthread_create`呢??

![image-20240222011044885](upload/attach/202402/963320_YBHVUTWTWH44J45.png)

看了一眼这个代码所在的函数的名称`ffi_call_SYSV`

![image-20240222011143427](upload/attach/202402/963320_WSE92UKRZN6ZZC8.png)

hmmm,看来是用<a href="elink@09dK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6S2L8r3g2^5j5$3!0V1k6e0u0Q4x3X3g2Y4K9i4c8T1L8$3!0C8i4K6u0W2K9h3!0Q4x3V1k6A6L8%4y4Q4x3X3c8V1k6i4k6W2L8r3!0H3L8h3g2F1N6q4)9J5k6r3N6#2K9h3c8W2L8r3W2F1k6i4y4Q4x3V1k6A6L8%4y4Q4x3X3c8*7j5g2)9J5k6s2c8S2L8W2)9J5c8X3I4A6j5X3k6X3K9g2)9J5k6r3c8G2L8X3N6Q4x3X3c8@1j5h3W2Q4x3X3c8@1K9h3q4G2i4K6u0V1P5h3!0F1k6#2)9J5k6r3S2W2i4K6u0V1k6r3W2F1k6#2)9J5k6s2W2A6i4K6u0V1j5#2)9J5k6r3S2S2L8W2)9J5k6s2y4Z5N6b7`.`.">libffi动态调用函数</a>呀

![image-20240222011351754](upload/attach/202402/963320_KVJSJFV6YZ634K9.png)

直接到<a href="elink@da6K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6D9K9h3u0X3k6X3V1`.">libffi的github仓库</a>看一眼<a href="elink@d48K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6D9K9h3u0X3k6X3W2Q4x3V1k6D9K9h3u0X3k6X3W2Q4x3V1k6T1L8r3!0T1i4K6u0r3L8h3q4K6N6r3g2J5i4K6u0r3M7%4u0U0i4K6u0r3j5h3q4J5j5$3R3$3y4q4)9J5c8Y4y4&6M7%4k6Q4x3X3g2e0">ffi_call_SYSV的源码</a>

一进去注释都写得清清楚楚了

![image-20240222012001816](upload/attach/202402/963320_76DXCG7MKHJPUKU.png)

利用注释就可以知道每行汇编都代表什么了,所以`BLR X24`表示去动态调用函数,而前面的`X0`,`X2`,`X4`,`X6`是用来传参的

![image-20240222012543471](upload/attach/202402/963320_9ADKPD9J4ZDPW2U.png)

我们hook一下`x0`看看有没有什么敏感的字符串

}
        },
        onLeave: function (ret) {
        }
    });

}
```

然而神奇的是,我仅仅去hook并打印x0字符串,其他什么事情都不干,apk竟然神奇的进去了,只不过会没有响应,感觉距离成功不远了呢

![image-20240222013454838](upload/attach/202402/963320_HA989D2DG2S7YC2.png)

有点意思,筛选一下看看有没有什么敏感的字符串好咯

}
        },
        onLeave: function (ret) {
        }
    });

}
```

竟然还真有,那就把这些字符串全部替换成无意义的字符串看看咯

![image-20240222013944879](upload/attach/202402/963320_36S54VA5UK5PG4C.png)

```js
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!

```js
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) {
        }
    });
}
```

![image-20240222015211639](upload/attach/202402/963320_C5ZEGKHVC87D8GM.png)

看一眼检测的字符串,怎么全是`/memfd:frida-agent-64.so`

![image-20240222015139528](upload/attach/202402/963320_W73B8CK2J7A3X52.png)

# 主DEX加载流程分析

回到这个卡了我们很久位置,现在过了反调试之后这里的代码终于可以继续执行下去了

![image-20240222015651090](upload/attach/202402/963320_XXMJ5WYZBS3M3EZ.png)

向下看找到这一个函数

![image-20240222030003433](upload/attach/202402/963320_WHNAKZVSTPTFTUF.png)

在这个函数中的字符串全部都是加密的,颇有种此地无银三百两的感觉,我们把字符串解密后发现了`DexFileLoader`相关的字符串,说明这个函数肯定和加载dex有某种关联

![image-20240222030104410](upload/attach/202402/963320_XPRKFPJ9RZW867N.png)

我们hook一下这个函数,发现这个函数共调用了三次,而且传入的值都是已经解密了的dex,`classes.dex`,`classes2.dex`,`classes3.dex`分别通过这个函数加载

`classes.dex`

![image-20240222030239507](upload/attach/202402/963320_A6782WHCURMW6D7.png)

`classes2.dex`

![image-20240222030345127](upload/attach/202402/963320_BEA4FYU2UY5TMVN.png)

`classes3.dex`

![image-20240222030355010](upload/attach/202402/963320_N9JWPRWCAHZJDN8.png)

把这三个dex给dump下来看看,于是我们得到了这三个文件

![image-20240222030924824](upload/attach/202402/963320_AXQR4KCRE68TFZN.png)

把最大的那个dex拖到jadx分析里面,发现这正是我们要找的主DEX

![图片描述](upload/attach/202402/963320_XVUFVSTM3WB3WJJ.webp)

其他函数都很正常,唯独`onCreate`函数变成了`native`声明,要是有同样分析到这里的朋友可以去研究研究`onCreate`函数对应的`native`本地函数究竟在什么地方,相信有了本文的铺垫,对于进行后续`onCreate`函数的分析应该是有所帮助的吧~

而除此之外的别的类和直接反编译未加固的apk的类是一样的

![image-20240222031222988](upload/attach/202402/963320_C2CQRCY9WNUV7CF.png)

# 主DEX解密算法分析
我们在**加固壳反调试深入分析**成功的绕过了加固壳的frida检测,现在我们再次回到`sub_1332B8`中的`sub_128D44`,来进行后续的解密算法的分析

下图是**主DEX解密流程初步分析**末尾部分的内容,我们将以这个函数`sub_128D44`为起点进行解密算法的分析,因为参数`v8`传入的值是加密之后的主DEX
 ![图片描述](upload/attach/202403/963320_EXUSETB4BC6XX52.webp)
我们在这个内存用frida打一个内存读写断点来看看是究竟是什么函数读取了主DEX,同时需要注意加上我们的反调试函数

```js
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) {
        }
    });
}

}
        },
        onLeave: function (ret) {
        }
    });
}

setImmediate(hook_dlopen);
```

打印日志如下
 ![图片描述](upload/attach/202403/963320_6GGZ49PS5VC58RB.webp)
说明是在`0xd364`处读取了这个主DEX

跳转到`0xd364`之后发现这个地址在函数`sub_C918`中,看起来这个函数的形状像一个火车头一样XD
 ![图片描述](upload/attach/202403/963320_JTC7BB52BYT3GF9.webp)
接下来我们继续使用<a href="elink@634K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6G2j5h3y4A6j5g2)9J5c8Y4y4@1j5h3I4C8k6i4u0Q4y4h3k6@1M7X3q4U0k6g2)9#2k6Y4y4G2">staker_trace_so</a>生成的`trace_so()`函数去看看函数的调用链是什么样子的,trace的起点就是在`sub_1332B8`中的`sub_128D44`,同时注意加上我们的反调试函数
 ![图片描述](upload/attach/202403/963320_UNXZNRJJUE9EY9S.webp)
打印出来的函数调用链如下

```c
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,位置如下图所示
```
 ![图片描述](upload/attach/202403/963320_P87496Q93MGW22Q.webp)
追踪函数调用链,我们发现了两个有趣的函数

```c
(mainELF)call50:sub_143008
(mainELF)call51:sub_142ABC
```

`sub_143008`看起来是一个解密的函数,先加上0x70再异或0x36,我们hook一下传入的参数看看是什么情况
 ![图片描述](upload/attach/202403/963320_BZD6WYE78E5WF5Z.webp)
 ![图片描述](upload/attach/202403/963320_K24NMGNTN25HWQS.webp)
我们再去看看加密的dex,发现这个函数传入的就是加密的主dex
 ![图片描述](upload/attach/202403/963320_D36W6UP8BWPCJBZ.webp)
把这部分解密看看里面是什么内容

```python
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`等等像是一些配置信息的样子
 ![图片描述](upload/attach/202403/963320_PQSPPHKEEKQ6NTA.webp)
这部分内容解密完之后,在`sub_142ABC`中以`pk`为标志读取各个配置信息
 ![图片描述](upload/attach/202403/963320_3ETHV7HT29JRTXW.webp)
之后我继续一个一个跳转到打印出来的函数中看,却一直都没有发现后续部分的解密算法的身影,随后我又仔细的看了一下调用的函数,突然有了惊喜的发现,这里的`pthread_mutex_lock`不就意味着要用互斥锁来切换到另外一个线程了吗!?

```c
(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来看看是什么情况
 ![图片描述](upload/attach/202403/963320_XS4X864DDSCWSYZ.webp)
果不其然,在这里我们发现除了主线程外,还有三个不同的线程调用了这个函数
 ![图片描述](upload/attach/202403/963320_AA7QYGVCT5DJAMZ.webp)
那我们在pid和主线程不同的时候,用`stalker_trace_so`的`trace_so`函数在去看看究竟调用了什么函数吧

```js
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) {
        }
    });
}
```

打印出的内容如下

```c
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里面看,在下面的函数中我们终于有了收获

```c
(mainELF)call45:sub_1A1B7C
(mainELF)call46:memset
(mainELF)call47:sub_1A1D84
(mainELF)call48:sub_1A1E74
```

这个算法,看起来又是RC4呐
 ![图片描述](upload/attach/202403/963320_NDMHRWP3DCPHZT5.webp)
hook一下这个函数,发现密钥是`b"\x68\x76\x99\x72\x96\x60\x9f\x63\x96\x2c\x98\x30\xc2\x36\x51\x42"`
 ![图片描述](upload/attach/202403/963320_RA3P6BYSAMYMTD2.webp)
再去hook `sub_1A1E74`看看传入了什么数据,我们发现前三部分都是`f7 4f e8 0e`开头的
 ![图片描述](upload/attach/202403/963320_ZYWP4NJCNXF5QMT.webp)
看到这些数据,终于离成功又更进一步了,因为这些数据就是我们读取完壳DEX尾部的前`0x41E`个加密数据并解密出配置信息之后的那部分加密数据,同时我们也可以在010editor中通过搜索壳DEX找到它们,这三部分加密数据段所在的位置分别为`0x35CE`,`0x3A93AD`,`0x417064`
 ![图片描述](upload/attach/202403/963320_NN3JNW98QZHTPVB.webp)
我们先来到第一个数据段的位置来分析数据段的结构,这个位置是在`0x31A4+0x41E`,即`0x35c2`之后
 ![图片描述](upload/attach/202403/963320_8CKMMHQ9S2R6PHV.webp)
所以这dex的第一个解密算法如下

```python
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))
```

![图片描述](upload/attach/202403/963320_ZXGSYMUQ7UDMX3Z.webp)
但是光这还不够,因为rc4解密出来的数据仍然不是DEX格式
 ![图片描述](upload/attach/202403/963320_HP66NFHHH7DMWQE.webp)
之后继续跟着函数调用链走,找到这些函数

```c
(mainELF)call60:sub_18DCC0
(mainELF)call61:sub_18F6AC
(mainELF)call62:sub_18DDA8
(mainELF)call63:sub_18DD94
(mainELF)call64:sub_18DDB8
```

在`sub_18F6AC`中的代码感觉很像是算法相关

![图片描述](upload/attach/202403/963320_5ZGTV9U3BKDK3MS.webp)
通过hook其中的`sub_18DDB8`函数发现a3是rc4解密之后的从0xc开始的数据段
 ![图片描述](upload/attach/202403/963320_N4FDNQQA44XCHCH.webp)
 ![图片描述](upload/attach/202403/963320_5Y6NNVW4XF5TF7X.webp)
而前面的0xc位额外数据的读取方式为5+4+4,在`sub_18DCC0`中有读取操作,通过这样的读取操作我们可以依次得到`0x010000005D`,`0x400000`,`0x109492`
 ![图片描述](upload/attach/202403/963320_DKC6VQKYE6S65U7.webp)
这里的`0x109492`表示的是第二次解密的数据段的大小,那么`0x40000`表示什么呢?

还记得我们的加密数据段是有前后两部分的嘛,前半部分用rc4解密,那么后半部分我们来看看长什么样子好了
 ![图片描述](upload/attach/202403/963320_MXRQEHENXBH7H68.webp)
后半部分的数据看起来十分的规整,不像是有加密的样子

而在**主DEX加载流程分析**中,我们成功的dump出了主DEX,那么我们不妨把这个这里的数据到主DEX中搜索一番看看有什么发现吧

在主DEX中搜索第一行的字节,我们惊喜的发现竟然可以搜索到,并且它的位置正好就是`0x400000`!
 ![图片描述](upload/attach/202403/963320_KN2BARQ6X22BK65.webp)
所以说经过RC4解密之后的这部分的数据结构我们也就可以知道了
 ![图片描述](upload/attach/202403/963320_FF6TCWQ3TDFKKSD.webp)
接下来我们只要搞清楚在`sub_18DDB8`中第二次解密的算法是什么就可以了

我们再回到分析的起点`sub_128D44`函数,来看看能不能有其他的发现
 ![图片描述](upload/attach/202403/963320_F95UGC5CJCCSM2C.webp)
通过hook `sub_128D44`的返回值v150之后发现,三级指针指向着解密之后的dex

```js
console.log(hexdump(ptr(ptr(ptr(this.context.x0.readS64()).add(0x0).readS64()).readS64()), {
    offset: 0,// 相对偏移
    length: 0x40,//dump 的大小
    header: true,
    ansi: true
}));
```

![图片描述](upload/attach/202403/963320_R85DNP2B7GA7APG.webp)
而倘若我们观察这个解密数据所在的内存`703bc75000`,它正好是`0x1000`的倍数,而`0x1000`正好就是一页的大小

这意味着什么呢?

这说明dex所在的内存极有可能是通过`mmap`函数分配的!

而在`stalker_trace_so`打印的数据中,正好就有这个函数被调用了

```c
(mainELF)call57:mmap
```

于是我们来到mmap被调用的函数
 ![图片描述](upload/attach/202403/963320_M57739H3F78SCXZ.webp)
使用frida hook mmap返回的内存指针,然后打上内存读写断点,就可以帮助我们快速定位到最终解密算法完成之后赋值的地址

```js
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) {
        }
    });
}

在`0x18ebd4`中将值写入最终的目标内存,这个地址在`sub_18E8D0`中
 ![图片描述](upload/attach/202403/963320_BWVXY6CXX4BMJKA.webp)
 ![图片描述](upload/attach/202403/963320_648D7GF5JTTR7KU.webp)
在这个函数的开头,有对参数a1的读取操作
 ![图片描述](upload/attach/202403/963320_XVW6VHCEUXMBAP8.webp)
我们hook一下值来看看a1各个部分都有什么含义
 ![图片描述](upload/attach/202403/963320_FJ8MUK77S9M7KMR.webp)
 ![图片描述](upload/attach/202403/963320_8A8YBHUFVJUWUYW.webp)
给a1写一个结构体好了

```c
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
 ![图片描述](upload/attach/202403/963320_PPV9XVNRPC3M426.webp)
sub_18DDB8
 ![图片描述](upload/attach/202403/963320_FEK528P8TYE9FY2.webp)
sub_18E244
 ![图片描述](upload/attach/202403/963320_SDA2B97JZ6XYTJS.webp)
sub_18E8D0
 ![图片描述](upload/attach/202403/963320_47ZBWFKVJYR9493.webp)
这些函数无壳无花无打乱,也没有vmp加固,显得相当的干净,看起来是一个自定义算法

算法千变万化,但是加固永远不是重在算法

逆向一款优秀的加固壳,从中学习到的知识可以受益终生,同时也可以借此思考如何避免让别人轻易找到加固方案的突破口

逢山开路，遇水搭桥。兵来将挡，水来土掩。

我们最后来hook一下下面这个地方来为我们的分析画上圆满的句号吧
 ![图片描述](upload/attach/202403/963320_8BT29CVETF9ZMYN.webp)
 ![图片描述](upload/attach/202403/963320_F933UYESMFT6CT4.webp)
至此,加固壳分析完毕

# 总结

这个加固壳和常规的加固方案类似,也是`壳DEX->壳ELF->主ELF->主DEX`这样的过程,其中壳ELF解密主ELF所用到的算法是`RC4`和`uncompress`,壳ELF加载主ELF所用到的技术是自实现linker加固so

当然这个加固壳还有许多值得继续研究的地方,例如分发so函数的vmp其内部逻辑究竟是什么样子呢?native化的`onCreate`函数,dex2c的原理究竟是什么呢?这些都还有待探索,就把它们交给时间和未来的不眠之夜吧

*月遇从云，花遇和风，今晚上的夜空很美。*

# 参考资料

* <a href="elink@441K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6%4N6%4N6Q4x3X3f1%4y4K6p5$3z5g2)9J5k6h3&6W2N6q4)9J5c8X3S2@1L8h3I4Q4x3V1j5I4y4K6l9%4x3U0c8Q4x3X3g2Z5N6r3#2D9">加固保关键技术浅析</a>
* <a href="elink@3caK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6U0M7Y4W2H3N6r3q4^5i4K6u0W2L8h3g2V1K9i4g2E0i4K6u0W2j5$3!0E0i4K6u0r3k6r3g2U0M7Y4W2H3N6r3W2F1k6#2)9J5k6s2y4@1M7X3W2F1k6%4y4Q4x3X3c8%4K9i4c8Z5i4K6u0V1j5g2)9J5k6r3A6W2j5W2)9J5k6s2y4U0M7X3W2H3N6q4)9J5k6o6q4S2k6U0f1J5x3X3k6S2y4o6V1%4z5b7`.`.">Decrypting strings with a JEB script</a>
* <a href="elink@9b2K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6%4N6%4N6Q4x3X3g2U0L8X3u0D9L8$3N6K6i4K6u0W2j5$3!0E0i4K6u0r3M7X3g2$3k6i4u0U0j5#2)9J5c8Y4m8Q4x3V1j5I4y4K6p5H3x3o6x3H3z5q4)9J5k6h3S2@1L8h3H3`.">自实现linker加固so</a>
* [加固保分析](https://bbs.kanxue.com/thread-260049.htm)
* [误入虎穴，喜得虎子——记一次手游加固的脱壳与修复](https://bbs.kanxue.com/thread-275811.htm)

登录后可查看完整内容

传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！！

最后于 2024-3-29 18:16 被oacia编辑，原因：增加主DEX解密算法分析部分

#HOOK注入 #脱壳反混淆 #NDK分析 #逆向分析

收藏・252

点赞・101

打赏

赞赏记录

参与人

雪币

留言

时间

0xE4s0n

感谢你的积极参与，期待更多精彩内容！

2026-7-3 15:25

番茄丶

感谢你的贡献，论坛因你而更加精彩！

2026-5-30 19:22

wx_ㅤ_683

谢谢你的细致分析，受益匪浅！

2026-5-8 09:07

beimingyouyu

期待更多优质内容的分享，论坛有你更精彩！

2026-4-14 08:52

P.Z

这个讨论对我很有帮助，谢谢！

2026-3-3 17:59

mb_codxgics

你的帖子非常有用，感谢分享！

2026-2-25 23:09

taoying

感谢你的贡献，论坛因你而更加精彩！

2026-2-5 11:05

mb_zfqvurgb

感谢你的贡献，论坛因你而更加精彩！

2025-12-19 11:11

Sybbbcy

你的分享对大家帮助很大，非常感谢！

2025-12-18 15:40

autorun886

感谢你的积极参与，期待更多精彩内容！

2025-12-11 21:54

trackL

为你点赞！

2025-10-31 10:39

mb_cvtgkrbe

你的分享对大家帮助很大，非常感谢！

2025-10-7 10:22

mb_jkykcuwo

期待更多优质内容的分享，论坛有你更精彩！

2025-9-29 14:47

git_836761956425473q

为你点赞！

2025-9-4 06:46

BinStyle

谢谢你的细致分析，受益匪浅！

2025-8-7 11:19

mb_gshxxejl

为你点赞！

2025-7-24 18:40

灬哈密瓜

你的分享对大家帮助很大，非常感谢！

2025-6-18 14:20

shuozhang

感谢你的贡献，论坛因你而更加精彩！

2025-6-5 15:52

wx_frere jac

感谢你的积极参与，期待更多精彩内容！

2025-6-1 16:01

mb_gxoryghy

你的帖子非常有用，感谢分享！

2025-5-20 00:16

loveqiao

你的分享对大家帮助很大，非常感谢！

2025-4-17 23:17

CarsonZ

感谢你分享这么好的资源！

2025-4-15 09:52

wx_Kiyose

非常支持你的观点！

2025-3-28 01:01

mb_nwjlihsi

为你点赞！

2025-3-22 09:37

苏打水

非常支持你的观点！

2025-3-21 11:39

Javaer

为你点赞！

2025-3-7 00:37

mb_umwsdbnt

感谢你的贡献，论坛因你而更加精彩！

2025-3-6 22:10

mb_aprbabml

为你点赞！

2025-3-1 15:22

mb_ifqtwleh

你的分享对大家帮助很大，非常感谢！

2025-2-28 15:05

linkin5epk

谢谢你的细致分析，受益匪浅！

2025-2-24 10:43

fireworld

为你点赞！

2025-2-5 20:50

wois杨

谢谢你的细致分析，受益匪浅！

2025-1-27 16:14

Forgo7ten

这个讨论对我很有帮助，谢谢！

2025-1-21 17:52

zxk1ng

感谢你的积极参与，期待更多精彩内容！

2025-1-12 22:01

Arahat0

感谢你分享这么好的资源！

2024-12-17 20:42

mocha

谢谢你的细致分析，受益匪浅！

2024-12-9 09:20

Moly

为你点赞！

2024-12-7 20:50

东方玻璃

感谢你的积极参与，期待更多精彩内容！

2024-12-7 11:26

lixupeng

感谢你的积极参与，期待更多精彩内容！

2024-12-4 21:17

李汉斯

感谢你分享这么好的资源！

2024-11-28 10:11

jmzqwh

为你点赞！

2024-11-27 17:50

混迹

谢谢你的细致分析，受益匪浅！

2024-11-7 13:38

Yangser

为你点赞！

2024-10-27 13:07

mb_jhnrzvas

感谢你的贡献，论坛因你而更加精彩！

2024-10-14 00:26

菜鸟一高

感谢你的贡献，论坛因你而更加精彩！

2024-9-25 11:22

mb_ytalqmdq

你的分享对大家帮助很大，非常感谢！

2024-9-23 14:08

falconnnn

谢谢你的细致分析，受益匪浅！

2024-9-7 16:42

我是红领巾

谢谢你的细致分析，受益匪浅！

2024-9-4 10:25

darthy

期待更多优质内容的分享，论坛有你更精彩！

2024-8-8 23:31

Aar0n

感谢你分享这么好的资源！

2024-8-8 17:39

CIH_D39

你的帖子非常有用，感谢分享！

2024-8-7 17:46

珍惜Any

+10

感谢你分享这么好的资源！

2024-8-7 17:13

马先越

感谢你的贡献，论坛因你而更加精彩！

2024-6-13 17:20

h0pε

期待更多优质内容的分享，论坛有你更精彩！

2024-6-11 22:44

mb_artypltt

为你点赞~

2024-6-10 18:11

PLEBFE

为你点赞~

2024-5-31 01:05

mb_togfmrxs

为你点赞~

2024-4-10 11:20

zhang_derek

为你点赞~

2024-4-7 13:05

Ram98

为你点赞~

2024-3-25 15:23

黎明与黄昏

为你点赞~

2024-3-23 22:08

medmi

为你点赞~

2024-3-22 20:23

zx_994305

为你点赞~

2024-3-14 18:58

mb_hivqmkwr

为你点赞~

2024-3-14 01:48

caolinkai

为你点赞~

2024-3-13 14:55

wx_789十

为你点赞~

2024-3-12 09:50

v0id_

为你点赞~

2024-3-6 14:27

mb_xoptebus

为你点赞~

2024-3-6 14:06

初恒

为你点赞~

2024-3-6 11:58

Da_

为你点赞~

2024-3-5 19:31

Zedbully

为你点赞~

2024-3-5 14:45

Nameless_a

为你点赞~

2024-3-5 12:38

孤独的街

为你点赞~

2024-3-3 11:18

nevinhappy

为你点赞~

2024-3-2 12:01

ZDavy

为你点赞~

2024-2-29 21:43

万里星河

为你点赞~

2024-2-27 19:23

huangjw

为你点赞~

2024-2-26 21:37

Ally Switch

为你点赞~

2024-2-26 10:50

asdll

为你点赞~

2024-2-26 09:02

简单的简单

为你点赞~

2024-2-25 19:47

zhczf

为你点赞~

2024-2-24 21:50

北袅

为你点赞~

2024-2-23 22:07

大浮屠

为你点赞~

2024-2-23 18:27

tfflowers

为你点赞~

2024-2-23 14:06

slcn

为你点赞~

2024-2-23 08:23

st0ne

为你点赞~

2024-2-22 21:49

狄人3

为你点赞~

2024-2-22 21:12

mb_lpcoesnt

为你点赞~

2024-2-22 17:49

iyue_t

为你点赞~

2024-2-22 16:18

Xierluo

为你点赞~

2024-2-22 15:43

poppig

为你点赞~

2024-2-22 14:11

mb_qqnashwi

为你点赞~

2024-2-22 13:44

乐子人

为你点赞~

2024-2-22 12:48

逆天而行

为你点赞~

2024-2-22 12:39

coneco

为你点赞~

2024-2-22 11:31

mb_wpitiize

为你点赞~

2024-2-22 10:29

令狐双

为你点赞~

2024-2-22 10:29

南枫

为你点赞~

2024-2-22 10:15

vay

为你点赞~

2024-2-22 09:51

.KK

为你点赞~

2024-2-22 09:37

你瞒我瞒

为你点赞~

2024-2-22 09:27

Himeko

为你点赞~

2024-2-22 09:08

打赏 + 10.00雪花

万里星河

打赏次数 1

雪花 + 10.00

万里星河

+10.00

2024/02/27

如沐春风收益匪浅敬仰之情涛涛不绝

最新回复 (109) 1 2 3 4 5 ▶
csjwaman 雪币： 298 活跃值： (3024) 能力值： ( LV12，RANK：980 ) 在线值：发帖 75 回帖 892 粉丝 11 关注私信	csjwaman 24 2 楼楼主强大，把它脱光了 2024-2-22 08:44 1
陈可牛雪币： 6559 活跃值： (6677) 能力值： ( LV5，RANK：76 ) 在线值：发帖 3 回帖 111 粉丝 37 关注私信	陈可牛 1 3 楼大佬真的猛……结构体就收下啦！谢谢！ 2024-2-22 09:09 0
nullpointer1 雪币： 228 能力值： ( LV1，RANK：0 ) 在线值：发帖 3 回帖 38 粉丝 2 关注私信	nullpointer1 4 楼牛 2024-2-22 10:03 0
TrumpWY 雪币： 887 活跃值： (1105) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 79 粉丝 2 关注私信	TrumpWY 5 楼真强啊；写的好像也挺详细的，只是我只看懂第一章节。。。 2024-2-22 10:11 0
Himeko 雪币： 1484 活跃值： (1788) 能力值： ( LV3，RANK：20 ) 在线值：发帖 2 回帖 34 粉丝 14 关注私信	Himeko 6 楼太牛了 2024-2-22 10:36 0
秋狝雪币： 10072 活跃值： (34131) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 1571 粉丝 39 关注私信	秋狝 7 楼感谢分享 2024-2-22 10:37 1
哆啦噩梦雪币： 498 活跃值： (5751) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 53 粉丝 2 关注私信	哆啦噩梦 8 楼 niu 2024-2-22 10:39 0
hzqhacker 雪币： 323 活跃值： (1072) 能力值： ( LV5，RANK：70 ) 在线值：发帖 3 回帖 58 粉丝 2 关注私信	hzqhacker 1 9 楼脱壳哪用那么麻烦。主要是修复VMP。看起来内容挺多，但是有点太多 2024-2-22 11:10 0
hzqhacker 雪币： 323 活跃值： (1072) 能力值： ( LV5，RANK：70 ) 在线值：发帖 3 回帖 58 粉丝 2 关注私信	hzqhacker 1 10 楼 360加固是业界最强的了。一个免费版就这么折腾！ 2024-2-22 11:16 2
coneco 雪币： 5151 活跃值： (4978) 能力值： ( LV10，RANK：171 ) 在线值：发帖 10 回帖 141 粉丝 88 关注私信	coneco 3 11 楼赞，感谢分享！！ 2024-2-22 11:31 0
jilay 雪币： 19 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 25 粉丝 1 关注私信	jilay 12 楼 666 2024-2-22 12:15 0
oacia 雪币： 3523 活跃值： (5523) 能力值： ( LV9，RANK：140 ) 在线值：发帖 11 回帖 59 粉丝 349 关注私信	oacia 2 13 楼 hzqhacker 脱壳哪用那么麻烦。主要是修复VMP。看起来内容挺多，但是有点太多是的要是单论脱壳而言有很多内容的确是多余的,想要脱壳的话直接用FART,frida-hexdump内存搜索或者hook libart.so的DexFile相关类就可以了,这样最多只需要过一个反调试就够了.我本来也是冲着VMP来的不过没想到做完前面修复VMP前的铺垫就花了那么长的篇幅,之后等我对VMP理解足够深入了之后,再回来这里把VMP分析完吧最后于 2024-2-23 00:59 被oacia编辑，原因： 2024-2-22 12:25 4
逆天而行雪币： 4722 活跃值： (7271) 能力值： ( LV6，RANK：90 ) 在线值：发帖 12 回帖 124 粉丝 246 关注私信	逆天而行 1 14 楼太腻害了，博主怎么学的啊！？ 2024-2-22 12:40 0
怜渠客雪币： 6143 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 12 粉丝 1 关注私信	怜渠客 15 楼一般来说是会给Activity类的onCreate函数进行VMP的，不清楚楼主为什么没遇到 2024-2-22 12:45 0
乐子人雪币： 4511 活跃值： (7267) 能力值： ( LV9，RANK：220 ) 在线值：发帖 11 回帖 128 粉丝 656 关注私信	乐子人 4 16 楼他那个interpreter_wrap_int64就是他的vm，只不过他只是把入口函数流程vm了，子函数还是直接调用的。 2024-2-22 12:47 0
hzqhacker 雪币： 323 活跃值： (1072) 能力值： ( LV5，RANK：70 ) 在线值：发帖 3 回帖 58 粉丝 2 关注私信	hzqhacker 1 17 楼 oacia hzqhacker 脱壳哪用那么麻烦。主要是修复VMP。看起来内容挺多，但是有点太多是的要是单论脱壳而言有很多内容的确是多余的 ... ****************** 最后于 2024-2-22 15:39 被kanxue编辑，原因：请注意语气和用词 2024-2-22 13:01 0
oacia 雪币： 3523 活跃值： (5523) 能力值： ( LV9，RANK：140 ) 在线值：发帖 11 回帖 59 粉丝 349 关注私信	oacia 2 18 楼怜渠客一般来说是会给Activity类的onCreate函数进行VMP的，不清楚楼主为什么没遇到我才发现主dex的oncreate函数变成了native声明,得看看这是怎么个回事了 2024-2-22 13:02 0
oacia 雪币： 3523 活跃值： (5523) 能力值： ( LV9，RANK：140 ) 在线值：发帖 11 回帖 59 粉丝 349 关注私信	oacia 2 19 楼乐子人他那个interpreter_wrap_int64就是他的vm，只不过他只是把入口函数流程vm了，子函数还是直接调用的。怪不得只要看到interpreter_wrap_int64就不知道下一个调用的函数是什么了,原来是有个VMP在这里 2024-2-22 13:04 0
huangjw 雪币： 6679 活跃值： (11862) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 510 粉丝 2 关注私信	huangjw 20 楼正好刚才升级好脱壳工具，拿来试试。 2024-2-22 15:53 0
shinratensei 雪币： 1719 活跃值： (215957) 能力值： ( LV4，RANK：40 ) 在线值：发帖 1 回帖 141 粉丝 19 关注私信	shinratensei 1 21 楼 tql 2024-2-22 16:48 0
你瞒我瞒雪币： 3421 活跃值： (12739) 能力值： ( LV2，RANK：10 ) 在线值：发帖 4 回帖 269 粉丝 8 关注私信	你瞒我瞒 22 楼一个免费版本都卷成这样了啊，以后冇得玩了。看到修复表就看不懂了。。。 2024-2-22 17:10 0
mb_zzeuzvsd 雪币： 69 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 9 粉丝 1 关注私信	mb_zzeuzvsd 23 楼太厉害了，还能把解析过程写的这么详细更厉害最后于 2024-2-22 17:36 被mb_zzeuzvsd编辑，原因： 2024-2-22 17:35 1
zxvv 雪币： 516 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 5 粉丝 1 关注私信	zxvv 24 楼我都是直接用自定义aosp脱壳的，连反调试都不需要，没想到这免费壳实际这么复杂。。最后于 2024-2-22 18:31 被zxvv编辑，原因： 2024-2-22 18:30 0
万里星河雪币： 273 活跃值： (2389) 能力值： ( LV2，RANK：10 ) 在线值：发帖 3 回帖 603 粉丝 8 关注私信	万里星河 25 楼太强了我的佬 2024-2-22 18:37 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复

oacia

发帖

回帖

140

RANK

关注

私信

他的文章

[原创]APP加固dex解密流程分析 74970
[原创]flutter逆向 ACTF native app 26972
[原创]细品sec2023安卓赛题 29066
[原创]将rwProcMem33编译进安卓内核 38015
[原创]DASCTF 2023六月挑战赛二进制专项 RE writeup 22157

关于我们

联系我们

企业服务

看雪公众号

最新回复 (109) 1 2 3 4 5 ▶
csjwaman 雪币： 298 活跃值： (3024) 能力值： ( LV12，RANK：980 ) 在线值：发帖 75 回帖 892 粉丝 11 关注私信	csjwaman 24 2 楼楼主强大，把它脱光了 2024-2-22 08:44 1
陈可牛雪币： 6559 活跃值： (6677) 能力值： ( LV5，RANK：76 ) 在线值：发帖 3 回帖 111 粉丝 37 关注私信	陈可牛 1 3 楼大佬真的猛……结构体就收下啦！谢谢！ 2024-2-22 09:09 0
nullpointer1 雪币： 228 能力值： ( LV1，RANK：0 ) 在线值：发帖 3 回帖 38 粉丝 2 关注私信	nullpointer1 4 楼牛 2024-2-22 10:03 0
TrumpWY 雪币： 887 活跃值： (1105) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 79 粉丝 2 关注私信	TrumpWY 5 楼真强啊；写的好像也挺详细的，只是我只看懂第一章节。。。 2024-2-22 10:11 0
Himeko 雪币： 1484 活跃值： (1788) 能力值： ( LV3，RANK：20 ) 在线值：发帖 2 回帖 34 粉丝 14 关注私信	Himeko 6 楼太牛了 2024-2-22 10:36 0
秋狝雪币： 10072 活跃值： (34131) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 1571 粉丝 39 关注私信	秋狝 7 楼感谢分享 2024-2-22 10:37 1
哆啦噩梦雪币： 498 活跃值： (5751) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 53 粉丝 2 关注私信	哆啦噩梦 8 楼 niu 2024-2-22 10:39 0
hzqhacker 雪币： 323 活跃值： (1072) 能力值： ( LV5，RANK：70 ) 在线值：发帖 3 回帖 58 粉丝 2 关注私信	hzqhacker 1 9 楼脱壳哪用那么麻烦。主要是修复VMP。看起来内容挺多，但是有点太多 2024-2-22 11:10 0
hzqhacker 雪币： 323 活跃值： (1072) 能力值： ( LV5，RANK：70 ) 在线值：发帖 3 回帖 58 粉丝 2 关注私信	hzqhacker 1 10 楼 360加固是业界最强的了。一个免费版就这么折腾！ 2024-2-22 11:16 2
coneco 雪币： 5151 活跃值： (4978) 能力值： ( LV10，RANK：171 ) 在线值：发帖 10 回帖 141 粉丝 88 关注私信	coneco 3 11 楼赞，感谢分享！！ 2024-2-22 11:31 0
jilay 雪币： 19 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 25 粉丝 1 关注私信	jilay 12 楼 666 2024-2-22 12:15 0
oacia 雪币： 3523 活跃值： (5523) 能力值： ( LV9，RANK：140 ) 在线值：发帖 11 回帖 59 粉丝 349 关注私信	oacia 2 13 楼 hzqhacker 脱壳哪用那么麻烦。主要是修复VMP。看起来内容挺多，但是有点太多是的要是单论脱壳而言有很多内容的确是多余的,想要脱壳的话直接用FART,frida-hexdump内存搜索或者hook libart.so的DexFile相关类就可以了,这样最多只需要过一个反调试就够了.我本来也是冲着VMP来的不过没想到做完前面修复VMP前的铺垫就花了那么长的篇幅,之后等我对VMP理解足够深入了之后,再回来这里把VMP分析完吧最后于 2024-2-23 00:59 被oacia编辑，原因： 2024-2-22 12:25 4
逆天而行雪币： 4722 活跃值： (7271) 能力值： ( LV6，RANK：90 ) 在线值：发帖 12 回帖 124 粉丝 246 关注私信	逆天而行 1 14 楼太腻害了，博主怎么学的啊！？ 2024-2-22 12:40 0
怜渠客雪币： 6143 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 12 粉丝 1 关注私信	怜渠客 15 楼一般来说是会给Activity类的onCreate函数进行VMP的，不清楚楼主为什么没遇到 2024-2-22 12:45 0
乐子人雪币： 4511 活跃值： (7267) 能力值： ( LV9，RANK：220 ) 在线值：发帖 11 回帖 128 粉丝 656 关注私信	乐子人 4 16 楼他那个interpreter_wrap_int64就是他的vm，只不过他只是把入口函数流程vm了，子函数还是直接调用的。 2024-2-22 12:47 0
hzqhacker 雪币： 323 活跃值： (1072) 能力值： ( LV5，RANK：70 ) 在线值：发帖 3 回帖 58 粉丝 2 关注私信	hzqhacker 1 17 楼 oacia hzqhacker 脱壳哪用那么麻烦。主要是修复VMP。看起来内容挺多，但是有点太多是的要是单论脱壳而言有很多内容的确是多余的 ... ****************** 最后于 2024-2-22 15:39 被kanxue编辑，原因：请注意语气和用词 2024-2-22 13:01 0
oacia 雪币： 3523 活跃值： (5523) 能力值： ( LV9，RANK：140 ) 在线值：发帖 11 回帖 59 粉丝 349 关注私信	oacia 2 18 楼怜渠客一般来说是会给Activity类的onCreate函数进行VMP的，不清楚楼主为什么没遇到我才发现主dex的oncreate函数变成了native声明,得看看这是怎么个回事了 2024-2-22 13:02 0
oacia 雪币： 3523 活跃值： (5523) 能力值： ( LV9，RANK：140 ) 在线值：发帖 11 回帖 59 粉丝 349 关注私信	oacia 2 19 楼乐子人他那个interpreter_wrap_int64就是他的vm，只不过他只是把入口函数流程vm了，子函数还是直接调用的。怪不得只要看到interpreter_wrap_int64就不知道下一个调用的函数是什么了,原来是有个VMP在这里 2024-2-22 13:04 0
huangjw 雪币： 6679 活跃值： (11862) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 510 粉丝 2 关注私信	huangjw 20 楼正好刚才升级好脱壳工具，拿来试试。 2024-2-22 15:53 0
shinratensei 雪币： 1719 活跃值： (215957) 能力值： ( LV4，RANK：40 ) 在线值：发帖 1 回帖 141 粉丝 19 关注私信	shinratensei 1 21 楼 tql 2024-2-22 16:48 0
你瞒我瞒雪币： 3421 活跃值： (12739) 能力值： ( LV2，RANK：10 ) 在线值：发帖 4 回帖 269 粉丝 8 关注私信	你瞒我瞒 22 楼一个免费版本都卷成这样了啊，以后冇得玩了。看到修复表就看不懂了。。。 2024-2-22 17:10 0
mb_zzeuzvsd 雪币： 69 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 9 粉丝 1 关注私信	mb_zzeuzvsd 23 楼太厉害了，还能把解析过程写的这么详细更厉害最后于 2024-2-22 17:36 被mb_zzeuzvsd编辑，原因： 2024-2-22 17:35 1
zxvv 雪币： 516 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 5 粉丝 1 关注私信	zxvv 24 楼我都是直接用自定义aosp脱壳的，连反调试都不需要，没想到这免费壳实际这么复杂。。最后于 2024-2-22 18:31 被zxvv编辑，原因： 2024-2-22 18:30 0
万里星河雪币： 273 活跃值： (2389) 能力值： ( LV2，RANK：10 ) 在线值：发帖 3 回帖 603 粉丝 8 关注私信	万里星河 25 楼太强了我的佬 2024-2-22 18:37 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复