解决Android加壳过程中mprotect调用失败的原因分析

问题原由

函数抽取壳是当前最为流行的dex加壳方式之一，这种加壳方式的主要流程包含两个步骤：一、将dex中需要保护的函数指令置空（即抽取函数体）；二、在应用启动的过程中，hook 类的加载过程，比如classlinker::loadmethod函数，然后及时回填指令。

笔者在实现抽取壳的过程中遇到了一个问题，即在步骤二回填指令之前，需要先调用mprotect将目标内存设置为“可写”，但在初次尝试过程中一直调用失败，于是有了今天这篇文章。

本文探讨的主要内容是mprotect调用失败的根本原因，以及在加壳实现中的解决方案，通过本文的阐述，一方面能够帮助遇到同类问题的小伙伴解决心中的疑惑，另一方面能够给大家提供可落地的实现方案。

调用mprotect修改内存失败的现象

以下代码块截取自自定义loadmethod函数，其目标是将目标函数指令所在内存页的属性修改为可写——通过mprotect函数的参数“prot_write”指定，实际结果是mprotect调用失败了，返回”-1“，errno为”13“

int pagesize = sysconf(_sc_pagesize);
int protectsize = pagesize;
byte *code_item_start = static_cast<byte *>(code_item_addr) + 16;
void *protectaddr = (void*) ((int) code_item_start - ((int) code_item_start % pagesize) - pagesize);
logd("process:%d,enter loadmethod:protectaddr:%p,protectsize:%d", getpid(), protectaddr, protectsize);
int result = mprotect(protectaddr, protectsize,  prot_write);
logd("mprotect return 0: %d, errno: %d", result, errno);

”13“号errno的符号为eacces，查看linux手册可知是权限问题。手册中给出一个可能的场景，即如果使用mmap映射一个以”只读“模式打开的文件，然后使用mprotect尝试修改内存属性为可写，就会返回eacces错误。

eacces the memory cannot be given the specified access. this can
happen, for example, if you mmap(2) a file to which you
have read-only access, then ask mprotect() to mark it
prot_write.

接下来我们将沿着这个可能的场景，首先验证dex文件是否以只读模式打开，然后再进行下一步分析。

mprotect调用失败的原因分析

使用strace跟踪应用的系统调用，验证了dex文件的打开模式为只读模式——”o_rdonly”，然后通过mmap2将dex文件映射进内存，内存属性为只读的私有映射。

[pid 13190] openat(at_fdcwd, “/storage/emulated/0/payload.dex”, o_rdonly|o_largefile) = 49
mmap2(null, 2121728, prot_read, map_private, 49, 0) = 0xcef7a000

为了进一步证实并彻底理清背后的逻辑，我研究了下mprotect的设计文档[1]。mprotect是用户空间pax的一部分，它的核心目标是缓解可利用内存漏洞被利用的情况，所以我理解mprotect实际上就是“memory protect”，它的主要目的是从安全的角度保护内存：

the goal of mprotect is to help prevent the introduction of new executable

code into the task’s address space. this is accomplished by restricting the

mmap() and mprotect() interfaces.

mprotect通过内存属性控制内存的访问权限，其中安全状态良好的属性组合包括如下几种：

vm_write

vm_maywrite

vm_write | vm_maywrite

vm_exec

vm_mayexec

vm_exec | vm_mayexec

即内存要么是“可写”的，要么是“可执行”的，“可写”与“可执行”必须互斥，这样才能阻断“写入并执行”的内存攻击。

理解了mprotect的设计理念之后，我们再回到本文所遇到的问题本身：为什么以只读方式打开的dex文件映射到内存之后，无法使用mprotect修改为“可写”内存？

根据mprotect设计文档的阐述，mprotect主要通过vm_maywrite控制内存是否可被设置为“可写”，该属性的设置时机在mmap调用之时：

vm_write | vm_maywrite or vm_maywrite if prot_write was requested at

mmap() time

mmap首先将所有可能的属性标致置位，然后再进行合法性检查：

kernel/msm/+/refs/heads/android-msm-vega-4.4-oreo-daydream/mm/mmap.c

/* do simple checking here so the lower-level routines won't have
 * to. we assume access permissions have been handled by the open
 * of the memory object, so we don't do any here.
 */
vm_flags |= calc_vm_prot_bits(prot) | calc_vm_flag_bits(flags) |
mm->def_flags | vm_mayread | vm_maywrite | vm_mayexec;

如果文件打开时未设置“可写”属性，则清除“vm_maywrite”属性。

kernel/msm/+/refs/heads/android-msm-vega-4.4-oreo-daydream/mm/mmap.c

if (!(file->f_mode & fmode_write))
 
vm_flags &= ~(vm_maywrite | vm_shared);

最后mprotect会对相关属性进行检查，如果vm_maywrite没有被设置，则不可通过mprotect设置内存的写属性，返回eacces错误标识：

kernel/msm/+/refs/heads/android-msm-vega-4.4-oreo-daydream/mm/mprotect.c

/* newflags >> 4 shift vm_may% in place of vm_% */
if ((newflags & ~(newflags >> 4)) & (vm_read | vm_write | vm_exec)) {
error = -eacces;
goto out;
}

通过strace日志可以证实mmap dex文件到内存的过程中并没有设置vm_maywrite和vm_write，所以直接使用mprotect设置内存为“可写”的行为会被拒绝。

	
mmap2(null, 2121728, prot_read, map_private, 49, 0) = 0xcef7a000

综上，mprotect修改内存为可写的整个逻辑如下：

系统以只读模式打开dex文件，所以mmap在映射文件时清除了vm_maywrite标志，导致接下来在调用mprotect修改内存为可写的过程中，mprotect检测目标内存未设置vm_maywrite标志，返回eacces错误代码。

两种可行的解决方案

在研究清楚原因之后，我们再来聊聊可能的解决方案。我这里给出两种经过验证的思路：

1）hook openat函数，设置文件打开时的属性为可读写——o_rdwr；

if(strstr(pathname,"payload")){
        logd("[myopenat] path: %s, flags: %d", (char*)pathname, flags);
        flags &= (~o_rdonly);
        flags |= o_rdwr;
    }

2）hook mmap函数，或者在mmap之前修改传入mmap的标签，直接将内存属性修改为“可写”。这里我们以后面一种思路为例，hook memmap::mapfileataddress函数，在调用mmap映射文件之前修改prot参数：

art/runtime/mem_map.cc

void* mymapfileataddr(int expected_ptr, int byte_count, int prot, int flags, int fd, int start, int low_4gb, int reuse, char *filename, int error_msg){
    if(strstr(filename, "payload"))
    {
        logd("[mymapfileataddr] file name contains 'payload': %s, prot: %d, flags: %d, fd: %d", filename, prot, flags, fd);
        prot |= prot_write;
    }
    void* res = orimapfileataddr(expected_ptr, byte_count, prot, flags, fd, start, low_4gb, reuse, filename, error_msg);
    return res;
}

小结

网络上很多关于抽取壳实现的教程都没有提过mprotect的问题，默认mprotect修改内存是成功的，这可能是因为大多数人都是通过模拟器进行实验。然而，如果我们要做线上的加壳产品，面向生产环境进行开发的话，mprotect调用失败的问题大概率会遇到，希望本文能有所帮助。

参考：

[1].mprotect设计文档：https[:][/][/]pax[.]grsecurity[.]net[/]docs[/]mprotect[.]txt

到此这篇关于android加壳过程中mprotect调用失败的原因及解决方案的文章就介绍到这了,更多相关android加壳mprotect调用失败内容请搜索www.887551.com以前的文章或继续浏览下面的相关文章希望大家以后多多支持www.887551.com！

解决Android加壳过程中mprotect调用失败的原因分析

目录

问题原由

调用mprotect修改内存失败的现象

mprotect调用失败的原因分析

两种可行的解决方案

小结

相关推荐