Task internal structure, explored!

Last time we looked at some of the task structure and memory management structures from the top. Here we will look in more detail at the structure of the task itself and the differences between native programs and applications. In computer forensics, most tasks are native tasks, but in the Android process space, a lot more tasks are written with Java, and will use the virtual machine provided by the zygote. We will look at these processes and their differences by using a view into the virtual memory areas (VMA’s). The VMA’s are also the organisation for the dump command, since the VMA’s are in virtual address order.

We can access a VMA view of a task by providing a PID and using the keyword –vma as shown:

XRYRAMalyzer.exe task –pid 475 –vma –file osaka.xry

This gives us a lot of information about the VMA structure of the process:

Along with the start and end addresses of the VMA, we have the number of pages within that VMA (basically the count of pages from start to end) and the number that have been allocated. This is often not the same, and in some cases may be zero since allocation in Android is through the lazy allocation algorithm, where a virtual page isn’t allocated until it is used. This minimises memory usage to pages being used, there are also instances where the zero-page allocation is zero on purpose usually as a guard page (like the pages surrounding the thread stacks in the picture above). This means that any out of bounds access on a stack will result in a page fault, and the kernel can choose to kill the process in this case.

The Designation of a VMA is either anonymous, or that there is a file backing the VMA. In the picture above we can see the designation of a file (vold) for the first four. This is the executable and data sections for the vold process. We then guard against stack interference and have the stacks for the threads that vold runs. Much later in the VMA list we can see how the libraries are loaded:

Here we can see several libraries and some of the control flow integrity memory areas used by the kernel for code integrity. There are other interesting areas such as shared pages used for the binder process, some others are the property pages. There are many places to explore in the process, here we would like to just show that this information exists, and we can use this to narrow down our search to interesting areas.

Tasks that are using the JVM also have VMA’s, but they do not follow the same order as a native program:

In this instance, we can see that the JVM main heap is the first VMA in the list, followed by the boot android runtime. The JVM is a new and interesting area to explore within RAM forensics that are unique to a mobile device, since much more of the applications will use it, and these processes are very different to the native tasks that we are used to.

 

Please join the conversation on the MSAB Forum in our dedicated RAMalyzer section, looking for tips? Want to share some interesting insights with fellow examiners? Head to the forum now!

Customer Forum 

 

If you want to learn more or have any questions, don’t hesitate to get in touch with us.   

Contact us 

 

About the author:
Dave Lauder is a Security Researcher at MSAB.