某相安全平台加密，除Main类外，其他class文件均被加密，熵值非常高

除jar外，还有一个.so文件。在启动时，需要指定-agentpath:./.so命令行参数。由于未确定其加固方案（比如xjar)，于是手动逆向其流程。

基本启动流程

jvm在指定-agentpath:./.so后，会先加载此so文件，然后运行此入口函数：

1

JNIEXPORT jint JNICALL Agent_OnLoad(JavaVM *vm,char *options,void *reserved)

参考：Java Agent机制 · 攻击Java Web应用-[Java Web安全]
容易推测，jvm会先通过此入口函数进行初始化，包括实现一个Loader，其在运行时会对Class文件进行解密。

so脱壳

拖入IDAPro对so文件进行分析，从导出表进入查看其代码，发现被加密，其他函数也是加密状态：

很明显so本身也加壳，并且未能确定so壳类型。由于so在加载时，操作系统会调用其_init_proc函数。于是查看此函数，发现未被加密：

可推测此函数进行了so的解密流程。于是手动编写加载程序test.c：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

#include <stdio.h>
#include <dlfcn.h>

int main(int argc, char* argv[]) {
        void * handle;
        char * error;
    
        handle = dlopen(argv[1], RTLD_NOW);
        if (handle == NULL) {
                printf("Open library *s error: *s\n", argv[1], dlerror());
                return -1;
        }
        printf("Open success! %x %s\n", handle, argv[1]);
        while (1) {}
    
        return 0;
}

编译后通过ida进行远程调试，待so被加载后查看其内存段：

进入可执行段，修复ida的函数声明。其中解密后的函数相对段基址的偏移不变，因此可以对照原so对虚拟基址的偏移确定解密后段中函数的位置。
由于dump（参考Android so层怎么去脱壳）后需要修复虚拟地址等，于是直接在此进程中进行分析。为方便分析应使用ctrl+F9导入jni.h头文件（参考ida导入jni.h）

so分析

分析Agent_OnLoad函数：

通过分析发现so会先注册两个Native函数：

其中参数class_obj在Agent_OnLoad通过使用MethodID获取后传递。后面进行分析发现就是org.springframework.asm.ClassReader。

然后会使用RegisterNatives进行注册：

1

jint RegisterNatives(jclass clazz, const JNINativeMethod* methods, jint nMethods)

其中JNINativeMethod结构体在jni.h中有声明，需要在IDA中Structures窗口中添加：

查看两个结构体地址，发现一个是isCipher函数，一个是decrypt函数

查看方法签名发现接受一个字节数组作为参数，并返回一个布尔值。后者则接受一个字节数组，返回一个字节数组。

进一步分析isCipher函数：

发现会检查输入的字节数组前四个字节是否为0BAh, 0BEh, 0CAh, 0FEh，可以发现加密的class文件头就是如此：

另外正常的class文件头是CAFEBABE。由此可知此函数用于判断是否为一个加密的class文件
再分析decrypt函数。发现解密时会使用一个全局16长度字节数组和加密class生成aes key和vi。

通过交叉引用发现global_bytes_16在Agent_OnLoad结尾处进行了初始化，通过一个初始key和vi对一个长度0xA150的密文进行解密并转换提取16个字节生成。

使用AES CBC NoPadding对密文进行解密，发现就是ClassReader.class

回到正常class解密流程，class密文前21字节和global_bytes_16生成aes key和vi，再解密21偏移后的内容即可解密class文件。

此文章仅作技术交流，严禁利用文中技术进行非法行为，否则后果自负！