-
-
[原创]内核层隐藏inject so来规避maps扫描
-
2021-10-14 14:41
-
声明
学习交流, 请勿用于非法用途
防护系统如何检测你
续接上文内核层偷天换日之hook openat进行文件重定向
我们在分析一些软件的时候. 防护系统通过扫描/proc/self/maps,发现一些异常的so, 那么就会进行上报. 我们有很多方式解决这种问题, 但是我还是希望能够了解内核层底层原理的同时, 能够非常方便的解决此问题.
mmap文件映射需要注意的点
关于mmap的原理这里就不做详细的阐述, 这里面主要关注下文件映射, addr并不是完全相等映射, 只是相近而已. 通过官方的文档可以了解到.
maps文件简单介绍
进程的每段地址空间由struct vm_area_struct 描述。如上所示的每一行对应一个vm_area_struct结构体。一个文件可以映射到内存中，vm_area_struct的vm_file保存了文件描述符，这种映射称为有名映射，反之则为匿名映射
7857803000-785784b000
本段内存映射的虚拟地址空间范围, 对应vm_area_struct中的vm_start和vm_end
rw-p----权限
r-读，w-写 x-可执行 p-私有，对应vm_flags。
00000000
针对有名映射，指本段映射地址在文件中的偏移，对应vm_pgoff。对匿名映射而言，为vm_area_struct->vm_start
fd：00
所映射的文件所属设备的设备号，对应vm_file->f_dentry->d_inode->i_sb->s_dev。匿名映射为0。其中fd为主设备号，00为次设备号
00048000
文件的索引节点号，对应vm_file->f_dentry->d_inode->i_ino，与ls –i显示的内容相符。匿名映射为0。
/data/local/tmp/xxxx.so
所映射的文件名。对有名映射而言，是映射的文件名，对匿名映射来说，是此段内存在进程中的作用。[stack]表示本段内存作为栈来使用，[heap]作为堆来使用，其他情况则为无。
cat /proc/self/map底层实现
在内核层fs系统实现了/proc/self/maps设备驱动, 其中核心实现在task_mm.c的show_map_vma函数中.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 | static void show_vma_header_prefix2(struct seq_file *m, unsigned long start, unsigned long end, vm_flags_t flags, unsigned long long pgoff, dev_t dev, unsigned long ino){ seq_setwidth(m, 25 + sizeof(void *) * 6 - 1); seq_printf(m, "%08lx-%08lx %c%c%c%c %08llx %02x:%02x %lu ", start, end, //文件权限相关, 这里把可执行权限隐藏掉, 伪造成匿名映射.或者其他系统映射都可以 flags & VM_READ ? 'r' : '-', flags & VM_WRITE ? 'w' : '-', '-',//flags & VM_EXEC ? 'x' : '-', flags & VM_MAYSHARE ? 's' : 'p', 0,//pgoff, 0, 0, 0);//MAJOR(dev), MINOR(dev), ino);}static voidshow_map_vma(struct seq_file *m, struct vm_area_struct *vma, int is_pid){ struct mm_struct *mm = vma->vm_mm; struct file *file = vma->vm_file; vm_flags_t flags = vma->vm_flags; unsigned long ino = 0; unsigned long long pgoff = 0; unsigned long start, end; dev_t dev = 0; const char *name = NULL; char path_buf[PATH_MAX] = {0}; if (file) { struct inode *inode = file_inode(vma->vm_file); dev = inode->i_sb->s_dev; ino = inode->i_ino; pgoff = ((loff_t)vma->vm_pgoff) << PAGE_SHIFT; } start = vma->vm_start; end = vma->vm_end; if(file) { show_vma_header_prefix2(m, start, end, flags, pgoff, dev, ino); } else { show_vma_header_prefix(m, start, end, flags, pgoff, dev, ino); } /* * Print the dentry name for named mappings, and a * special [heap] marker for the heap: */ if (file) { // 获取文件名称 char *path = d_path(&file->f_path, path_buf, sizeof(path_buf)); seq_pad(m, ' '); if(strlen(path) > 0) { if(strstr(path, "xxxx.so")) { // 过滤xxxx.so goto done; } } seq_file_path(m, file, "\n"); goto done; } if (vma->vm_ops && vma->vm_ops->name) { name = vma->vm_ops->name(vma); if (name) goto done; } name = arch_vma_name(vma); if (!name) { if (!mm) { name = "[vdso]"; goto done; } if (vma->vm_start <= mm->brk && vma->vm_end >= mm->start_brk) { name = "[heap]"; goto done; } if (is_stack(vma)) { name = "[stack]"; goto done; } if (vma_get_anon_name(vma)) { seq_pad(m, ' '); seq_print_vma_name(m, vma); } }done: if (name) { seq_pad(m, ' '); seq_puts(m, name); } seq_putc(m, '\n');} |
结果验证
通过上面的信息处理后, 所有的都没有对应的可执行权限了, 有了这种方法, 你就可以定制你自己的隐藏技术, maps文件便由你掌控
对应实现
https://github.com/yhnu/op7t/tree/dev/hide_inject_so
[培训]《安卓高级研修班(网课)》月薪三万计划，掌握调试、分析还原ollvm、vmp的方法，定制art虚拟机自动化脱壳的方法
|
|
|---|---|
|
|
|
|
|
rom真不真好解决后面再分享. 可能还得考虑linker下面2组获取modules的数据, 针对这个问题能否详细阐述下. 没理解 |
|
|
|
|
|
|
|
|
好主意,我已经按照这种模式改了 |
|
|
学习了,一段匿名空间但是有可执行权限, 在防护系统看来是否很可疑? |
|
|
感觉还好吧，目前的风控sdk大多还是扫描so文件特征。
最后于 2021-10-18 10:29
被virjar编辑
，原因：
|
|
|
很可疑，某讯就会检测此类内存段 |
|
|
那么如何过内存段是可执行属性检测呢 如果代码需要长时间驻留在内存里执行的话 |
|
|
要是能操控cpu就好了 
|
|
|
用户层的话就是拦截io操作，重定向maps，smaps文件，隐藏map_files目录，实现难度较高。内核层的话隐藏对应vma即可，难度较低。
最后于 2021-10-18 12:58
被不吃早饭编辑
，原因：
|
|
|
|
|
|
重定向maps文件在很多情况导致各种闪退。不太好操作。fd反查可以拿到重定向的真实的路径 |
|
|
重定向包括对stat系列函数的hook，许多io相关的操作都需要，例如inotify_add_watch等，当然不只是open/openat。另外重定向只要处理完善并不会出现频繁的闪退，至少我这里没有遇到
最后于 2021-10-18 15:12
被不吃早饭编辑
，原因：
|
|
|
一般来讲io重定向的主要问题是内联syscall，这种情况下如果不做专门处理确实会产生逃逸，不过实际上也有解决方案 |
|
|
ptrace？还是扫描全部可执行区域？ 我测试普通的io重定向没有出现过闪退，但是只要对maps进行fd重定向，确实有一定概率闪退。可能真的没有处理完善吧 |
|
|
|
|
|
 欢迎添加更多功能互相学习
|
|
|
就是，先生成一个进程，再attach它，在检测它的tracerid，看有无自相矛盾 |
|
|
大佬，这种方法是什么意思呢？是直接删除有rwxp权限的那一行吗？如果直接去掉的话maps中的内存地址不连续了 |
|
|
简单用户态可以参考 CobaltStrike，不执行的时候修改内存块权限，唤醒的时候再改一遍，要么就按内核 rootkit做 hook 内核函数写一个 filter |
|
|
|
|
|
是的，检测inline hook特征的 |
|
|
|
RiDiN
