UPX压缩壳简介

示例使用到的是变种爱加密的UPX壳
https://wwe.lanzous.com/iqV0Pfysrkj

文件目录

首先看看UPX压缩壳的一个特点

壳特点

拿到一个so文件先放进IDA解析一波，从导出函数列表中我们可以看到一个函数叫做init_proc()，点进去可以看到上面的一大堆IDA识别不了的代码，因为是压缩壳嘛，压缩后的指令IDA自然是识别不了，但是不管他怎么压缩，最后在内存中执行的时候都会是一个原版的完整的so文件，所以我们尝试使用frida脚本dump一下这个so文件

使用/proc/<pid>/map 查看一下地址映射

maps IDA ctrl+s

可以看到在内存中是多了一块debug区域的，这一块区域的访问权限为 读 执行 这就是解压出来的arm汇编指令

- 使用frida脚本dump so

frida -U -f monkeylord.trygetflag -l C:\Users\Administrator\Desktop\dump_so.js --no-pause

function dump_so(so_name) {
    Java.perform(function () {
        var currentApplication = Java.use("android.app.ActivityThread").currentApplication();
        var dir = currentApplication.getApplicationContext().getFilesDir().getPath();
        var libso = Process.getModuleByName(so_name);
        console.error("------------------------------");
        console.warn("[name]:", libso.name);
        console.warn("[base]:", libso.base);
        console.warn("[size]:", libso.size);
        console.warn("[path]:", libso.path);
        console.error("------------------------------");
        var file_path = dir + "/" + 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);
        }
    });
}

不一定是使用这种方式来dump so

- 或者是使用IDA动态调试的时候使用IDA脚本

• 如果反调试不在init函数可以使用ida的回溯找到linker的入口点
• 断点时机得选在linker执行init函数的时候，在第47个init函数反调试)
• 函数识别不正确的时候可以使用alt+G修改Arm/Thumb识别（0：Arm，1：Thumb）

auto i,fp,start_address,end_address;
start_address = 0xD6088000;
end_address = 0xD6142000;
fp = fopen("d:\\dump.so","wb");
for (i = start_address; i <= end_address; i++){
    fputc(Byte(i),fp);
}

- 再或者是更简单的方法，使用objeciton（最简单）

objection dump so

得到so文件后我们用010Editer打开原来的so以及得到的so

跳转到最开始特征的地址 0x6630 010查看so文件结构

这里用三种颜色标出来的是三个结构体
分别对应以下的三个结构体

struct l_info{
    LE32 l_checksum;
    LE32 l_magic;
    LE16 l_size;
    unsigned char l_version;
    unsigned char l_formart;
} l_info;

struct p_info{
    unsigned p_progid;
    unsigned p_filesize;
    unsigned p_blocksize;
} p_info;

struct b_info{
    unsigned sz_unc;          //uncomparessed_size
    unsigned sz_cpr;          //comparessed_size
    unsigned char b_method;   //compression akgorithm
    unsigned char b_ftid;     //filter id
    unsigned char b_cto8;     //filter paramter
    unsigned char b_unused;   //unused
} b_info;

示例：

l_info:

14 67 DD 61 41 4A 4D 21 B8 03 0D 17

14 67 DD 61	41 4A 4D 21	B8 03	0D	17
p_progid	l_magic	l_size	l_version	l_formart

p_info:

00 00 00 00 60 C3 0B 00 60 C3 0B 00

00 00 00 00	C3 0B 00 60	60 C3 0B 00
p_progid	p_filesize	p_blocksize

b_info:

54 01 00 00 A3 00 00 00 09 00 00 00

54 01 00 00	A3 00 00 00	09	00	00	00
sz_unc	sz_cpr	b_method	b_ftid	b_cto8	b_unused

关键的点就是sz_cpr，从地址偏移可以找到这个文件压缩前可执行代码段的真实大小

RealSize = 0x6654 + 0xA3 = 0x66F7

跳转地址过去可以找到真实的大小为 ： B0 ED 0A 00

修改这三个段

因为在内存中elf文件以段的方式存储节的信息也没有了，就顺便去掉节信息，防止IDA解析的时候乱七八糟的弹报错

去掉节信息

最后再看一下修改后IDA解析出来的效果：
还是看init_proc()

修改后的指令结果

最后在总结一句:对于普通未压缩的so直接hook或者是010Editer改就完事，但是对于以上这种压缩壳，除了我们需要内存dump修复之外，使用inlinehook去实现修改持久化就是一个比较好的选择

对于UPX压缩壳大概就这样吧
如有什么错误或者是建议望大佬指出 0.0