Extending Emuroot: support for Android 10 & 11

Find an entry point to the task list

The designers of Android Emuroot have chosen to locate the process descriptor "init" as a reference point to access the task list. "init" is an always-present process in the Linux system whose identifier is 1.

In recent versions of the Android system, the address of the init descriptor can change (after a cold reboot of the system for example). It is therefore preferable to use the descriptor of the first process created by the kernel as a reference point: swapper.

swapper (PID 0) is a special process crafted by the kernel. Historically, it was used for swap operations, now it mainly runs the idle loop when the CPU is idle. This is the very first process spawned on the system.

To retrieve the descriptor of the swapper process in memory we use the following method.

First we create a process with a particular name via Android Debug Bridge (ADB):

$ adb shell
$ cd /data/local/tmp
$ ln -s /system/bin/sh QUARKSLAB
$ ./QUARKSLAB

Here, we simply create a symbolic link named "QUARKSLAB" to the sh (shell) binary, then we execute the shell using this link. This creates a new sh process with the name "QUARKSLAB":

$ ps
USER            PID   PPID     VSZ    RSS WCHAN            ADDR S NAME
shell          2955    366   12916   3172 __ia32_co+          0 S sh
shell          4395   2955   12916   2880 __ia32_co+          0 S QUARKSLAB
shell          4463   4395   12584   3836 0                   0 R ps

The goal is to locate the descriptor of the QUARKSLAB process in memory. The process descriptors are represented by a structure named task_struct. These structures are very regularly accessed by the system and as such are present in a directly mapped physical memory area (0xffff8800000000 - 0xffffc7ffffffff). For this we use GDB:

gdb> find 0xffffa30440000000, +0x40000000, "QUARKSLAB"
0xffffa30441257310
0xffffa3045d9a5378

Two occurrences of the string "QUARKSLAB" were found. One of them is associated with the comm field of the task_struct structure associated with the process :

/*
 * executable name, excluding path.
 *
 * - normally initialized setup_new_exec()
 * - access it with [gs]et_task_comm()
 * - lock it with task_lock()
 */
char                                comm[TASK_COMM_LEN];

To identify which of the two previous results is the one we are looking for, we will use a Python interactive interpreter and the pygdbmi module. More precisely, a wrapper we developed in our script that provides various methods to read and write in the emulated system memory. This is not the only solution, but it has the advantage of being fast and simple to implement (find_tasks_field.py):

from aeroot import GdbHelper

comm = 0xffffa30441257310

gdb = GdbHelper("x86_64")
gdb.start()

for offset in range(0, 3000, 8):
    ptr_prev = gdb.read_addr(comm - offset)

     if hex(ptr_prev).startswith("0xffff"):
         ptr_next = gdb.read_addr(comm - offset - 8)

         if hex(ptr_next).startswith("0xffff"):
             print(hex(comm - offset - 8), gdb.read_str(ptr_next + offset + 8), gdb.read_str(ptr_prev + offset + 8))

gdb.stop()

Output:

0xffffa304412572f8
0xffffa30441257208 \\377\\377\\377\\377\\377\\377\\377\\377 \\377\\377\\377\\377\\377\\377\\377\\377
0xffffa30441257200
0xffffa304412571f8 QUARKSLAB QUARKSLAB
0xffffa304412571f0  B
0xffffa304412571e8 sh
0xffffa304412571e0  0
0xffffa304412571a8
0xffffa304412571a0 QUARKSLAB QUARKSLAB
0xffffa30441257198  B
0xffffa30441257190 QUARKSLAB QUARKSLAB
0xffffa30441257188  B
0xffffa30441257180 \\200aP\\250\\004\\243\\377\\377\\200aP\\250\\004\\243\\377\\377 \\b
0xffffa30441257178 \\200aP\\250\\004\\243\\377\\377 \\200aP\\250\\004\\243\\377\\377
0xffffa30441257170
0xffffa30441257168 QUARKSLAB QUARKSLAB
0xffffa30441257160 , B
0xffffa30441257158
0xffffa304412570c0 \\300\\300$\\264\\377\\377\\377\\377\\064 \\240\\324#\\264\\377\\377\\377\\377
0xffffa304412570b8 \\022 4
0xffffa30441257098
0xffffa30441257078  B
0xffffa30441257070 QUARKSLAB QUARKSLAB
0xffffa30441257068  B
0xffffa30441257060 QUARKSLAB QUARKSLAB
0xffffa30441257048 kworker/3:0 sh
0xffffa30441257018 QUARKSLAB QUARKSLAB

What does this badly coded snippet do? It iterates downwards in steps of 8 from the potential comm field that is initialized with the first address we want to test comm = 0xffffa30441257310. The algorithm tests the presence of two contiguous pointers (result starting with 0xffff). The goal is to find the tasks field (located before the comm field) of the process descriptor.

struct list_head            tasks;

list_head is declared as follows in types.h:

struct list_head {
    struct list_head *next, *prev;
};

That is to say, the task list of the system!

For each pair of addresses preceding the comm field found, the code will try to display the comm fields of the previous and next process descriptor in the task list by reapplying the offset that corresponds to the current difference with the comm field (in the example: 0xffffa30441257310).

In the output of the script we can see in the penultimate line that the task list pointers were most probably found:

0xffffa30441257048 kworker/3:0 sh

From there, it is possible to iterate on the task list to the process descriptor "init". As a bonus we also got the offset that separates the task field from the comm field.

With a few tricks of the same style it is possible to simply identify the other useful fields of the task_struct structure (pointer to the credentials structure, PID of the process).

Address of the SELinux mode variable

In order to be able to change the mode of operation of SELinux (change it to Permissive mode) it is necessary to locate the enforcing variable present in the selinux_state structure (security/selinux/include/security.h):

struct selinux_state {
    bool disabled;
#ifdef CONFIG_SECURITY_SELINUX_DEVELOP
    bool enforcing;
#endif
    bool checkreqprot;
    bool initialized;
    bool policycap[__POLICYDB_CAPABILITY_MAX];
    struct selinux_avc *avc;
    struct selinux_ss *ss;
};

In order to do so, the authors of Emuroot proceed to the static analysis of the AVD kernel with IDA and localize the enforcing variable using specific strings. This method is not usable for all versions of the kernel. We preferred to use dynamic analysis.

So we started to work with an Android 11.0 x86_64 image that uses the same version of the Linux kernel as the Google Play image and provides the su binary in order to be able to manipulate the SELinux mode via the setenforce command.

The goal of the procedure is to locate the address of the enforcing variable via several successive dumps of a certain memory range (in kernel space) by changing the value of the variable via the setenforce command between two dumps.

It is possible to produce real (binary) memory dumps via gdb, however we preferred to use the debugger logs so as to work directly with the output of the find command which we use to look for the values in memory.

The default SELinux mode is Enforcing, so the enforcing variable has the value 1.

# getenforce
Enforcing

So we scan the memory range we are interested in with gdb looking for bytes whose value is "1". An important point to note, is that the implementation of the enforcing field in the kernel used by Android 11.0 (Linux 5.4) changes compared to previous versions. Indeed, in version 5.4 the field is of type bool (stored on one byte in memory). Before, enforcing was stored in a u32 (double-word). This point is important because searching for the 1 value as bytes or double-words is not the same thing and does not lead to the same result. The selinux_state structure is loaded into the kernel module mapping space (0xffffffffa0000000 - 0xffffffffff5fffff).

In GDB:

gdb> set logging file A
gdb> set log on
gdb> find /b 0xffffffffb4693000, +0x40000000, 1
gdb> set log off

First we define the A file as log output. Then we execute the find command looking for bytes (switch /b) whose value is 1.

This gives us a resulting set of 45624 addresses of bytes whose value is 1. The variable enforcing is one of these 45624 bytes.

We then change the value of the variable using the setenforce command:

# setenforce 0

We repeat the search in memory with gdb:

gdb> set logging file B
gdb> set log on
gdb> find /b 0xffffffffb4693000, +0x40000000, 1
gdb> set log off

This gives us a set of 45518 addresses that cannot be the enforcing variable. We search for the "1's" with the find command while the current value is "0". The results are stored in the B file.

We finally prepare a last set of results:

gdb> set logging file C
gdb> set log on
gdb> find /b 0xffffffffb4693000, +0x40000000, 0
gdb> set log off

The resulting C file contains the addresses of the 2002519 bytes with "0" in the memory range.

So for the moment we have 3 files (A, B and C) which contain a lot of addresses... Far too many to be analyzed manually. So the next step is to reduce the number of potential candidates for the enforcing variable.

To do this we use the following formula : CANDIDATES = (A \ B) ∩ C

First of all, we make the difference between A and B as a whole:

Then we perform the intersection of the resulting set (A') with C :

The result of this intersection gives us the set candidates.

Put into practice with Python:

with open(“A”, “r”) as f:
    A = {int(l, 16) for l in f if l.startswith(“0x”)}

with open(“B”, “r”) as f:
    B = {int(l, 16) for l in f if l.startswith(“0x”)}

with open(“C”, “r”) as f:
    C = {int(l, 16) for l in f if l.startswith(“0x”)}

candidates = (A - B) & C

This results in a candidates set of about 50 addresses. If the resulting set would have been larger, we would have extracted more dumps to reduce it further. After a certain number of iterations (the volatility of the values in memory helps) the set ends up being reduced to a reasonable number of results. This method has the advantage of being quite fast (a few minutes to extract a set of candidate addresses via the gdb logs) and simple to implement.

To find the address of the SELinux mode variable among these 50 addresses, we use the following method:

Set SELinux to enforcing mode:

# setenforce 1

Then with a small Python script (find_enforcing_candidates.py):

from aeroot import GdbHelper

gdb = GdbHelper(“x86_64”)
gdb.start()

for addr in candidates:
    if gdb.read_byte(addr) == 1:
        print(hex(addr))

Output:

0xffffffffb4718b19
0xffffffffb472ab4c

The total of 45624 potential departure candidates is now reduced to two possibilities.

To determine which of these two addresses corresponds to the variable enforcing we will modify the value of the byte of one of the two addresses. In GDB:

gdb> set *(unsigned char*) (0xffffffffffffb4718b19) = 0

And observe the impact via the getenforce command :

# getenforce
Permissive

SELinux has switched to Permissive mode, so the address of the enforcing variable is 0xffffffffb4718b19.

Dealing with KASLR

In the previous part we saw how to retrieve both the absolute memory address of the swapper task_struct and the SELinux mode variable.

Unfortunately, if we cold reboot the emulated device, the solution we found will not work anymore. That is due to the KASLR.

Address Space Layout Randomization is a well known security mechanism used in various OS which is intended to complicate the implementation of exploits based on the use of absolute addresses. To make this possible, ASLR loads the different sections of a process at random addresses in memory.

KASLR is the same kind of mechanism but for the kernel. At boot time the kernel code is loaded in a randomized address space. This feature has been implemented in the Linux kernel since version 3 and enabled by default since the version 4.12.

This feature will make unusable the addresses we previously found.

One solution is to disable KASLR at boot time with the parameter nokaslr as follows:

$ emulator @Pixel_2_API_30_x86_64 -qemu -s -append nokaslr

Once the addresses of the swapper task_struct and SELinux mode variable are found, they will not change as long as we use this parameter to boot the emulated system.

A funnier solution is to bypass KASLR so we don't need to disable the feature and the script will work properly regardless of whether KALSR activated or not.

Bypassing KASLR can be done by finding the dynamic virtual address of a kernel element whose offset from the kernel base address is fixed. Several vulnerabilities allowing this from the user space on real machines have been reported in the past. A notable vulnerability is the CVE-2019-10639 which allows to obtain the kernel address in memory via ICMP or UDP, so it can be exploited remotely.

In our case, the use of GDB server gives us access to the memory of the emulated device. So we just need to locate a non-randomized memory area that contains a pointer to the kernel space. To maximize our chances of finding a pointer to the kernel space we are interested in, we search the cpu_entry_area range which contains the global descriptor table (GDT) and trampolines for syscalls (0xfffffe00000000 - 0xfffffe7fffffff).

For this we use a Python interpreter and the pygdbmi module (find_ptrs_to_kernel.py):

from aeroot import GdbHelper

gdb = GdbHelper(“x86_64”)
gdb.start()

candidate_ptrs = dict()

for addr in range(0xfffffe0000000000, 0xfffffe000000fff8, 4):
     candidate = gdb.read_addr(addr)
     hex_candidate = hex(candidate)

     if 0xffffffff00000000 <= candidate <= 0xfffffffffeffffff:
         candidate_ptrs[addr] = 0xffffffffb3028310 - candidate
         print(hex(addr), hex(candidate), 0xffffffffb3028310 - candidate)

This script lists the potential pointers to the kernel space as well as the offsets to the comm field of the swapper descriptor calculated from each potential pointer.

Output:

# PTR              ADDR               OFFSET TO SWAPPER COMM FIELD
0xfffffe0000000004 0xffffffffb2448e00 12449040
0xfffffe0000000014 0xffffffffb2448e03 12449037
0xfffffe0000000024 0xffffffffb2448e02 12449038
0xfffffe0000000034 0xffffffffb244ee00 12424464
0xfffffe0000000044 0xffffffffb243ee00 12490000
0xfffffe0000000054 0xffffffffb2448e00 12449040
0xfffffe0000000064 0xffffffffb2448e00 12449040
0xfffffe0000000074 0xffffffffb2438e00 12514576
0xfffffe0000000084 0xffffffffb2448e01 12449039
0xfffffe0000000094 0xffffffffb2448e00 12449040
0xfffffe00000000a4 0xffffffffb2448e00 12449040
0xfffffe00000000b4 0xffffffffb2438e00 12514576
0xfffffe00000000c4 0xffffffffb2448e00 12449040
0xfffffe00000000d4 0xffffffffb2448e00 12449040
0xfffffe00000000e4 0xffffffffb2448e00 12449040
0xfffffe00000000f4 0xffffffffb2438e00 12514576
0xfffffe0000000104 0xffffffffb2448e00 12449040
0xfffffe0000000114 0xffffffffb2448e00 12449040
0xfffffe0000000124 0xffffffffb2448e04 12449036
0xfffffe0000000134 0xffffffffb2448e00 12449040
0xfffffe0000000144 0xffffffffb3178e00 -1379056
0xfffffe0000000154 0xffffffffb3178e00 -1379056
0xfffffe0000000164 0xffffffffb3178e00 -1379056

We then perform a cold reboot of the emulator to test our pointer dictionary.

Then we test the different candidate pointers as follows (validate_ptrs_to_kernel.py):

for ptr, offset in candidate_ptrs.items():
    addr = gdb.read_addr(ptr)
    swapper_comm_addr = addr + offset

    print(hex(ptr), gdb.read_str(swapper_comm_addr))

Output:

# PTR              ADDR               STR @ ADDR + OFFSET
0xfffffe0000000004 0xffffffffa2448e00 swapper/0
0xfffffe0000000014 0xffffffffa2448e03 swapper/0
0xfffffe0000000024 0xffffffffa2448e02 swapper/0
0xfffffe0000000034 0xffffffffa244ee00 swapper/0
0xfffffe0000000044 0xffffffffa243ee00 swapper/0
0xfffffe0000000054 0xffffffffa2448e00 swapper/0
0xfffffe0000000064 0xffffffffa2448e00 swapper/0
0xfffffe0000000074 0xffffffffa2438e00 swapper/0
0xfffffe0000000084 0xffffffffa2448e01 swapper/0
0xfffffe0000000094 0xffffffffa2448e00 swapper/0
0xfffffe00000000a4 0xffffffffa2448e00 swapper/0
0xfffffe00000000b4 0xffffffffa2438e00 swapper/0
0xfffffe00000000c4 0xffffffffa2448e00 swapper/0
0xfffffe00000000d4 0xffffffffa2448e00 swapper/0
0xfffffe00000000e4 0xffffffffa2448e00 swapper/0
0xfffffe00000000f4 0xffffffffa2438e00 swapper/0
0xfffffe0000000104 0xffffffffa2448e00 swapper/0
0xfffffe0000000114 0xffffffffa2448e00 swapper/0
0xfffffe0000000124 0xffffffffa2448e04 swapper/0
0xfffffe0000000134 0xffffffffa2448e00 swapper/0
0xfffffe0000000144 0xffffffffa3178e00 swapper/0
0xfffffe0000000154 0xffffffffa3178e00 swapper/0
0xfffffe0000000164 0xffffffffa3178e00 swapper/0
...

We see that once each pointer is resolved and the offset applied, we fall back to the swapper comm field. So here we have a set of persistent pointers to the kernel space. We just have to choose one of them and then apply offsets to get back the addresses of:

• the task_struct of swapper

• the SELinux mode variable

KASLR is bypassed!