What’s in a (task) name?

Sometimes we can be looking for a task in the task list that we know was running but is not in the names there. One such task that should be running but is often not in the list is ‘vold’ the volume daemon. This takes care of mounting disks and partitions within the system and is often not named since it may have been started via a service handler. How do we find such a task? In this post we explore one method of looking at a task and we look in more detail at what can be seen within the task information we display.
In the first instance, let us look for tasks that share a name, one such task name is the Binder tasks. These are tasks that could have been started by a service or via an exec() command at some point. We can list these tasks using the name modifier:
XRYRAMalyzer.exe list –name Binder –file osaka.xry

Here, we can see there are several results for the Binder process, we will choose the first, since we don’t know which processes these are, but vold is started early in the boot process. For this, we will need to look at the binary data itself and for now, we can look in any hex viewer after we dump the process. We can dump the process to a known directory using the file_path switch, but here we will dump it to the same folder. The dumped process will appear in a dump folder with the PID as the folder name where the files are. This enables us to dump a few processes and keep some order in which process memory is which.
XRYRAMAnalyzer.exe dump –pid 475 –file osaka.xry

Each virtual memory area within the task is dumped to a separate file and the name of the file is the start address of the memory area. It should be noted that these are all in virtual address order, which means that contiguous virtual addresses are contiguous within the file, as opposed to their physical address pages. This means that if we were looking for files, they should remain contiguous also within these files.

We now have a dump of the process, but where should we look to see which program this really is? We can now look in detail at the task information using the ‘task’ command in verbose mode:
XRYRAMalyzer.exe task –pid 475 –file osaka.xry –verbose

There is a lot of information here, with some information being shown as file offset and some with addresses, but the information we really want is contained within the ‘Arg’ element here.
Arg: [0x7FCD12FD17,0x7FCD12FDC0]
This is the arguments that were used to start the process and is list of strings with the first string being the actual program being run. In the picture above, we can see that the arguments are contained this this line, and they start at 0x7FCD12FD17, which is a virtual address in this user address space. When we look at the binary that contains this address, we can see that our list of strings are there and that this process is, indeed vold (we can also see the start of the environment variables too).

 

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.