来自高维的对抗 - 逆向TinyTool自制

来自高维的对抗 - 逆向TinyTool自制

一、序

无论是逆向分析还是漏洞利用，我所理解的攻防博弈无非是二者在既定的某一阶段，以高维的方式进行对抗，并不断地升级维度。比如，逆向工程人员一般会选择在Root的环境下对App进行调试分析，其是以root的高权限对抗受沙盒限制的低权限；在arm64位手机上进行root/越狱时，ret2usr利用技术受到PXN机制的约束，厂商从修改硬件特性的高维度进行对抗，迫使漏洞研究者提高利用技巧。

下文将在Android逆向工程方面，分享鄙人早期从维度攻击的角度所编写的小工具。工具本身可能已经不能适应现在的攻防，“授人以鱼不如授人以渔”，希望能够给各位读者带来一些思路，构建自己的分析利器。

二、正

0x00 自定义Loader

早期Android平台对SO的保护采用畸形文件格式和内容加密的方式来对抗静态分析。随着IDA以及F5插件地不断完善和增多，IDA已经成为了逆向人员的标配工具。正因如此，IDA成为了畸形文件格式的对抗目标。畸形方式从减少文件格式信息到构造促使IDA加载crash的变化正应证了这一点。对此，鄙人研究通过重建文件格式信息的方式来让IDA正常加载。

在完成编写修复重建工具不久之后，鄙人在一次使用IDA的加载bin文件时，猛然意识到畸形文件格式的对抗目标是IDA对ELF文件的加载的默认loader。既然防御的假象和维度仅仅在于默认loader，那么以自定义的loader加载实现高维攻击，理论是毫无敌手的。

那如何来实现IDA自定义loader呢？

1. 以Segment加载的流程对ELF文件进行解析，获取和重建Section信息(参看上面所说贴子)。
2. 把文件信息在IDA中进行展示，直接调用对应的IDAPython接口

实现加载bin文件的py代码见文末github链接，直接放置于IDA/loaders目录即可。由于早期少有64位的安卓手机，加载脚本仅支持arm 32位格式，有兴趣读者可以改写实现全平台通用。不同ndk版本所编译文件中与动态加载无关的Section不一定存在，注释相应的重建代码即可。

0x01 Kernel Helper

以APP分析为例，对于加固过的应用通常会对自身的运行环境进行检测。比如: 检测自身调试状态，监控proc文件等。相信各位读者有各种奇淫技巧来绕过，早期鄙人构建hook环境来绕过。从维度的角度，再来分析这种对抗。对于APP或者bin文件而言，其仅运行于受限的环境中，就算exp提权后也只是权限的提升和对内核有一定的访问控制权。对于Android系统而言，逆向人员不仅能够拿到root最高权限，而且还可以修改系统的所有代码。从攻防双方在运行环境的维度来看，“魔”比”道“高了不只三丈，防御方犹如板上鱼肉。而在代码维度，防御方拥有源代码的控制权，攻防处于完全劣势。随着代码混淆和VMP技术的运用，防御方这块鱼肉越来越不好"啃"。

对于基于linux的安卓系统而言，进程的运行环境和结构是由内核来提供和维护的。从修改内核的维度来对抗，能达到一些不错的效果。下文将详述在内核态dump目标进程内存和系统调用监控。

1. 内存DUMP

对内核添加一些自定义功能时，通常可以采用内核驱动来实现。虽然一部分Android手机支持驱动ko文件加载，但内核提供的其他工具则不一定已经编译到内核，在后文中可以看到。nexus系列手机是谷歌官方所支持的，编译刷机都比较方便，推荐使用。

S1. 编译内核

为了让内核支持驱动ko文件的加载，在make memuconfig配置内核选项时，以下勾选:

[*] Enable loadable module support

次级目录所有选项

编译步骤参看谷歌官方提供的内核编译步骤。

S2. 驱动代码

linux系统支持多种驱动设备，这里采用最简单的字符设备来实现。与其他操作系统类似，linux驱动程序也分为入口和出口。在module_init入口中，对字符设备进行初始化，创建/dev/REHelper字符设备。文末代码采用传统的方式对字符设备进行注册，也可直接使用misc的方式。字符设备的操作方式通过注册file_operations回调实现，其中ioctl函数比较灵活，满足实现需求。

定义command ID:

#define CMD_BASE 0xC0000000

#define DUMP_MEM (CMD_BASE + 1)

#define SET_PID (CMD_BASE + 2)

构建dump_request参数:

struct dump_request{

pid_t pid; //目标进程

unsigned long addr; //目标进程dump起始地址

ssize_t count; //dump的字节数 char __user *buf; //用户空间存储buf

};

在ioctl中实现分支:

case DUMP_MEM:
target_task = find_task_by_vpid(request->pid); //对于用户态，进程通过进程的pid来标示自身；在内核空间，通过pid找到对应的进程结构task_struct
if(!target_task){
printk(KERN_INFO "find_task_by_vpid(%d) failed\n", request->pid);
ret = -ESRCH;
return ret;
}
request->count = mem_read(target_task->mm, request->buf, request->count, request->addr); //进程的虚拟地址空间同样由内核进程管理，通过mm_struct结构组织

memread其实是对memrw函数的封装，mem_rw能够读写目标进程，简略流程:

static ssize_t mem_rw(struct mm_struct *mm, char __user *buf,
size_t count, unsigned long addr, int write)
{
ssize_t copied;
char *page;

...

page = (char *)__get_free_page(GFP_TEMPORARY); // 获取存储数据的临时页面

...

while (count > 0) {
int this_len = min_t(int, count, PAGE_SIZE);

// 将写入数据从用户空间拷贝到内核空间
if (write && copy_from_user(page, buf, this_len)) {
copied = -EFAULT;
break;
}

// 对目标进程进行读或写操作，具体实现参看内核源码
this_len = access_remote_vm(mm, addr, page, this_len, write);
// 将获取到的目标进程数据从内核拷贝到用户空间
if (!write && copy_to_user(buf, page, this_len)) {
copied = -EFAULT;
break;
}
...
}
...
}

内核驱动部分的dump功能实现，接着只需在用户空间访问驱动程序即可。

// 构造ioctl参数
request.pid = atoi(argv[1]);
request.addr = 0x40000000;
request.buf = buf;
request.count = 1000;

// 打开内核驱动
int fd = open("/dev/REHelper", O_RDWR);
// 发送读取命令
ioctl(fd, DUMP_MEM, &request);
close(fd);

S3. 测试

文末代码中，dump_test为目标进程，dump_host通过内核驱动获取目标进程的数据。insmod和dump_host以root权限运行即可。

2. 系统调用监控

通常情况下，APP通过动态链接库libc.so间接的进行系统调用，直接在用户态hook libc.so的函数即可实现监控。而对于静态编译的bin文件和通过svc汇编指令实现的系统调用，用户态直接hook是不好处理的。道理很简单，系统调用由内核实现，hook也应该在内核。

linux系统的系统调用功能统一存在syscall表中，syscall表通常编译放在内核映像的代码段，修改syscall表需要修改内核页属性，感兴趣的读者可以找到linux rootkit方面的资料。本文对系统调用监控的实现，采用内核从2.6支持的probe功能来实现，选用的最重要原因是：通用性。在不同abi平台通过汇编实现系统调用的读者应该知道，不同abi平台的系统调用功能号并不一定相同，这就意味其在syscall表中的数组索引是不一致的，还需要额外的判定，实现并不优雅。

linux内核提供了kprobe、jprobe和kretprobe三种方式。限于篇幅，仅介绍利用jprobe实现系统调用监控。感兴趣的读者可以参看内核Documentation/kprobes.txt文档以及samples目录下的例子。

S1. 编译选项

为了能够支持probe功能，需在上述开启驱动ko编译选项的基础上勾选kprobe选项。如果没有开启内核驱动选项，是不会有kprobes(new)选项的

General setup --->
[*] Kprobes(New)

S2. 驱动代码

以监控sys_open系统调用为例。首先，在module_init函数中对调用register_jprobes进行注册。注册信息封装在struct jprobe结构中。

static struct jprobe open_probe = {
.entry = jsys_open, //回调函数
.kp = {
.symbol_name = "sys_open", //系统调用名称
},
};

由于系统调用为所有进程提供服务，不加入过滤信息会造成监控信息过多。回调函数的声明和被监控系统调用的声明一致。

asmlinkage int jsys_open(const char *pathname, int flags, mode_t mode){
pid_t current_pid = current_thread_info()->task->tgid;
// 从当前上下文中获取进程的pid

// monitor_pid初始化-1，0为全局监控。
if(!monitor_pid || (current_pid == monitor_pid)){
printk(KERN_INFO "[open] pathname %s, flags: %x, mode: %x\n",
pathname, flags, mode);
}

jprobe_return();
return 0;
}

对monitor_pid的设置通过驱动的ioctl来设置，参数简单直接设置。

case SET_PID:
monitor_pid = (pid_t) arg;

S3. 测试

文末代码bin_wrapper和ptrace_trace均为静态编译，bin_wrapper通过设置监控对ptrace_trace的进行监控。内核prink的打印信息通过cat /proc/kmsg获取，输出类似如下:

<6>[34728.283575] REHelper device open success!
<6>[34728.285504] Set monitor pid: 3851
<6>[34728.287851] [openat] dirfd: -100, pathname /dev/__properties__, flags: a8000, mode: 0
<6>[34728.289348] [openat] dirfd: -100, pathname /proc/stat, flags: 20000, mode: 0
<6>[34728.291325] [openat] dirfd: -100, pathname /proc/self/status, flags: 20000, mode: 0
<6>[34728.292016] [inotify_add_watch]: fd: 4, pathname: /proc/self/mem, mask: 23
<6>[34729.296569] PTRACE_PEEKDATA: [src]pid = 3851 --> [dst]pid = 3852, addr: 40000000, data: be919e38

三、尾

本文介绍了鄙人对攻防的维度思考，以及从维度分析来实现的早期工具的部分介绍。希望能够给各位读者带来一些帮助和思考。限于鄙人水平，难免会有疏漏或者错误之处，敬请各位指出，谢谢。

四、附

https://github.com/ThomasKing2014/ReverseTinytoolDemo

本文来自合作伙伴“阿里聚安全”，发表于2017年02月28日  09:48.