资讯专栏INFORMATION COLUMN

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

tigerZH / 2284人阅读

摘要:一序无论是逆向分析还是漏洞利用,我所理解的攻防博弈无非是二者在既定的某一阶段,以高维的方式进行对抗,并不断地升级维度。正因如此,成为了畸形文件格式的对抗目标。对于基于的安卓系统而言,进程的运行环境和结构是由内核来提供和维护的。

一、序

无论是逆向分析还是漏洞利用,我所理解的攻防博弈无非是二者在既定的某一阶段,以高维的方式进行对抗,并不断地升级维度。比如,逆向工程人员一般会选择在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呢?

以Segment加载的流程对ELF文件进行解析,获取和重建Section信息(参看上面所说贴子)。
把文件信息在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
", 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
", 
        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/ThomasKing...

作者:团控@阿里聚安全,更多阿里安全类技术文章,请访问阿里聚安全博客

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/13539.html

相关文章

  • [系统安全] 三十八.APT系列(3)恶意代码与APT攻击中武器(Seak老师)

    摘要:在尚未承载关键资产以磁盘为主要信息交换方式时,以制造者心理满足作为主要动力编写的感染病毒。在时代,反病毒引擎的整个体系结构已经趋于成熟,反病毒引擎的更新维护成为安全对抗的工作主线。下图是著名的攻击组织方程式对中东最大的金融服务机构的攻击。 ...

    HtmlCssJs 评论0 收藏0
  • 火热生成对抗网络(GAN),你究竟好在哪里

    摘要:自年提出生成对抗网络的概念后,生成对抗网络变成为了学术界的一个火热的研究热点,更是称之为过去十年间机器学习领域最让人激动的点子。 自2014年Ian Goodfellow提出生成对抗网络(GAN)的概念后,生成对抗网络变成为了学术界的一个火热的研究热点,Yann LeCun更是称之为过去十年间机器学习领域最让人激动的点子。生成对抗网络的简单介绍如下,训练一个生成器(Generator,简称G...

    mist14 评论0 收藏0
  • 感知对抗网络 PAN,一个框架搞定多种图像转换

    摘要:此前有工作将像素损失和生成对抗损失整合为一种新的联合损失函数,训练图像转换模型产生分辨率更清的结果。一般来说,结合使用多种损失函数的效果通常比单独使用一种要好。结合感知对抗损失和生成对抗损失,提出了感知对抗网络这一框架,处理图像转换任务。 近来,卷积神经网络的发展,结合对抗生成网络(GAN)等崭新的方法,为图像转换任务带来了很大的提升,包括图像超分辨率、去噪、语义分割,还有自动补全,都有亮眼...

    happen 评论0 收藏0
  • 为什么让GAN一家独大?Facebook提出非对抗式生成方法GLANN

    摘要:的两位研究者近日融合了两种非对抗方法的优势,并提出了一种名为的新方法。的缺陷让研究者开始探索用非对抗式方案来训练生成模型,和就是两种这类方法。不幸的是,目前仍然在图像生成方面显著优于这些替代方法。 生成对抗网络(GAN)在图像生成方面已经得到了广泛的应用,目前基本上是 GAN 一家独大,其它如 VAE 和流模型等在应用上都有一些差距。尽管 wasserstein 距离极大地提升了 GAN 的...

    iOS122 评论0 收藏0
  • 到底什么是生成式对抗网络GAN?

    摘要:很多人可能会问这个故事和生成式对抗网络有什么关系其实,只要你能理解这段故事,就可以了解生成式对抗网络的工作原理。 男:哎,你看我给你拍的好不好?女:这是什么鬼,你不能学学XXX的构图吗?男:哦……男:这次你看我拍的行不行?女:你看看你的后期,再看看YYY的后期吧,呵呵男:哦……男:这次好点了吧?女:呵呵,我看你这辈子是学不会摄影了……男:这次呢?女:嗯,我拿去当头像了上面这段对话讲述了一位男...

    GitCafe 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<