Android Roaming note (1)---memory mapped image

The Android kernel is based on the linux2.6+ kernel, so many of the mechanisms in process memory management are similar to Linux. First, let's look at a typical memory image of the Android process (the app process and the native local process are slightly different, but the principle is the same):

Like Linux, Android provides a/proc-based "pseudo-file" system as an Interface (CAT/PROC/PID/MAPS) for viewing user process memory images. It can be said that this is a window of the Android system kernel layer open to the user layer about process memory information. Through it, we can see the memory mapping of the current process space, module loading and virtual address and memory read-write Execution (RWXP) properties, and so on.

First, we will read the above maps.

Take libc.so as an example:

The first column: 400dd000------40142000, you can see that this is an in-memory contiguous address space, divided into 3 sub-space, divided into 400dd000-40142000,40142000-40144000,40144000-40146000. You might ask, since it's loading libc.so, why load it 3 times? Good question!

We continue to look at the second column: R-xp r--p rw-p. where r is read-only, W is writable, X is executable, p means private (s means shared). Let's take a look at the libc.so Elf's program header and paragraph Description section (Elf for Unix-like executable or shared image format, similar to the Windows PE format, follow-up roaming series explained in detail), we can use the Android NDK provided by Google Toolchains the arm-linux-androideabi-readelf of the tool chain to read (Arm-linux-androideabi-readelf-a libc.so).

This piece we do not parse in detail, focusing on the two pieces of content I tagged. Load indicates that the segment needs to be loaded into memory, and the FLG flag represents the attribute of the segment in memory mirroring, so that you can basically answer the above question. When the kernel is loading the libc.so, refer to the ELF program header to see that segment one by one is mapped to memory. Because libc.so contains code snippets, data segments, and so on, it is mapped to different locations according to different attributes.

As the above 400dd000-40142000 contains sections such as. text. PLT, and 40142000-40144000,40144000-40146000 contains. Data. BSS. Got.

To summarize: When libc.so is mapped to memory, the kernel is mapped "assembled" according to the ELF program header one by one, and different types of segments are mapped to different regions.

Let's look at the memory-mapping API (MMAP) provided by the Linux kernel.

       #include <sys/mman.h>       void *mmap (void *addr, size_t length, int prot, int flags,int fd, off_t offset);

Parameters:

Addr: The memory address reference to be mapped, the kernel follows this address to dynamically determine the newly allocated memory location

Length: Size (bytes)

Prot:

       Prot_exec  pages May executed.//executable       prot_read  pages can be read.//readable       prot_write pages could be written./ /writable       Prot_none  Pages May is accessed.//not accessible

Flags

       map_shared Share this mapping.  Updates                  to the mapping is visible to other processes that maps this file, and is carried                  through to the Underlyin G file.  The file may not actually are                  updated until Msync (2) or Munmap () is called.       Map_private                  Create a PRIVATE copy-on-write mapping.  Updates                  to the mapping is not visible to other processes mapping                  the same file, and is not carried through to T He underlying                  file.  It is unspecified whether changes made to the file after the                  mmap () call was visible in the mapped region.

FD and offset represent the file handle to be mapped and the initial offset, such as null, equivalent to allocating an empty block of memory, MMAP returns the mapped memory block base address. In fact, the kernel is calling Mmap to move the elf file into memory step by step.

Write here, we open a deserted, detailed study of the mmap prot parameters, as stated above, the flag indicates that the memory block will be mapped read-write and execution properties, and Linux in addition to the initial mapping can be set memory properties, after loading into memory, can still modify its properties (need root permission), That makes sense, which means that we can dynamically modify its memory properties (in addition to the kernel Vsyscall area) when the process executes, you know.

See API (Mprotect)

       #include <sys/mman.h>       int mprotect (void *addr, size_t len, int prot);

Parameters:

Addr: Memory base Address to modify (must be page aligned, multiples of page size, typically 4K aligned)

Len: Size (bytes)

Prot: The modified rwx property.
See here, those so-called game "auxiliary, plug-in" all laughed!

We might as well write a code to see what Mproject and mmap are capable of!

/* *  mmap & mprotect call *  Created on:2014-6 * author:chris.z * *  #include <stdio.h> #include <st dlib.h> #include <sys/mman.h> #include <errno.h>int main () {    void* membase = NULL;    printf ("[+]call mmap to Alloc memory,size of 4k btyes\n");    Membase = Mmap (null,0x1000,prot_read,map_anonymous| Map_private,null,null);    if (membase = = map_failed)    {        printf ("[+]mmap FAILED with errno:%d\n", errno);        return 1;    }    printf ("[+]allocated memory Base:0x%x\n", membase);    if (GetChar ())    {        printf ("[+]modify the addr:0x%x prots to rwx\n", membase);        Mprotect (membase,0x1000,prot_read| prot_write| prot_exec);    }    if (GetChar ()) Free        (membase);    return 0;}

In the code snippet above, we let the kernel allocate a size of 4K of anonymous memory in the current process memory space, the initial property is "read Only", and then we call Mprotect to change its properties to "rwx". Look at the results of the operation:

We can see the base of our allocated memory block is: 0x401da000, view process maps, found that the property has been assigned to "R--p" memory block, the end address is 0x401db000, the size is 0x1000, exactly 4 K.

After entering the carriage return, we see the result:

Here, we know how to dynamically allocate a page of memory in the current process, while modifying its properties, of course, here is to demonstrate the operation of the current process, if you want to operate a third-party process, but also need some other things, such as the process of attaching, injection and other operations, this is slowly said later!

All right, just write it down here, Enjoy it!.

Reprint please indicate the Source: Life Show