Deeper into tasks
We have looked at how we can use the XRYRAMalyzer to find data within a process. But in some instances, we might want to look at the task list itself, and perhaps some of the data within the process’ task structure. There is a lot of information available within tasks that could be shown, we chose to show some of the data in locations that might help to look for other pieces of data, and to help look for malicious insertions into the task list. This isn’t an exhaustive processing of the task and memory management structures, just some that we thought might be useful. We can also look at the structure of the task and see which memory areas have been allocated to the task. This is not a tutorial in how tasks work, since this would be inappropriate in a series of short posts about investigating memory, if this is required there are many good books and courses that can give this information.
We can begin by looking at the task list again, we saw previously how we could obtain a task list via the ‘list’ command, however if we use the ‘tree’ command, we can see the same list in a tree format, which helps us to see which tasks are the parents of other tasks:
XRYRAMAnalyzer.exe tree –file osaka.xry
Will give us the output:
This is also truncated to show more of the tree structure but also to an interesting area for our previous exploration of Firefox. Within this picture we can see the process called ‘main’ at PID 869 is both a parent and a grandparent, a look at the tasks that are its children shows that this is the java zygote which is a component of the java virtual machine. We can deduce from this that children of PID 869 are java tasks, and more likely to be non-system apps. We can also see that the webview_zygote is present as a task within this list, this task has two children itself, and these are likely to be processes being used by a web browser (perhaps one is being used to show the video in the Firefox tab which the input data tells us was happening).
This structuring of the task list to a tree shows how we can see if a malicious process was spawned, for example by seeing if a non-shell process was spawned by the ADB process. This can be found by inspection of this tree structure. We can also filter out the kernel threads since they are all children of the kernel thread daemon (kthreadd). We can also see in our picture that there are Binder processes being scheduled. These can be seen at PIDs 525, 867, 868, and potentially belong to the Binder IPC process, this means that potentially there is data being passed from one process to another within these processes.
Although kernel threads do not have their own memory management structures, the existence of some threads denote that some function within the kernel was being used. In this picture, we
can see that disk partitions have been mounted and that some are mounted using ext4 and some are mounted using f2fs (we don’t know which partitions are which at this point).
Another thing we can show from just the task list is the availability of Bluetooth on the device. This can be achieved by looking for the Bluetooth App, which is started when the service is started on the handset. In our original ‘Osaka’ file, we can see that Bluetooth services was probably turned on:
But in another test handset it was not:
Just as a final note, since we found that ‘Osaka’ has Bluetooth on, we can use a regex to look for potential Bluetooth MAC addresses within the app:
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!
If you want to learn more or have any questions, don’t hesitate to get in touch with us.
About the author:
Dave Lauder is a Security Researcher at MSAB.