Updated and improved list view

RAM in mobile devices is a new area for investigation within the field of digital forensics, and RAMalyzer is a tool used to examine how memory is used within an Android system. Within our previous RAM blog series, we looked at the basics of how to target a particular task and how to examine the memory allocated to that task. In one blog post we also looked at the internals of a task to find the command line used to invoke the task. This used a procedure for dumping the memory and looking for the arguments at the address shown within the task structure. This was used because the tasks common name was shown to be related to inter-process communications and didn’t indicate the command. It could also be seen that the common name’s length limitation of 16 bytes meant that tasks invoked to run via the Java Virtual Machine (most user applications use the Java Virtual Machine) also had their common name truncated.

This truncation and other problems with the common name within the task structure led to a review of how tasks are represented within RAMalyzer. Since we already had a procedure for finding the command line of the task (from the previous set of blogs), it was decided that we should provide this as well as the common name for a task. The most obvious place to show this would also be the list command, so now the list command will show the argument list.

We also noted that the anonymous threads, used by the kernel to service various hardware services, are probably not very interesting from an examination point of view. As part of this same review, we decided to add a switch so that these anonymous tasks are removed from the task list. This helps the user to focus on the more useful processes within the task list. A sample command using list and the new process command is shown in Figure 1.0.

ramalyzer list –process –file Osaka.xry

Figure 1.0

The status field in this list is discussed in an upcoming blog post in this update series, but the process ID (PID), the common name (Name) and ProcessType fields are carried over from the first version of RAMalyzer, with the new fields to include the arguments (ArgsList). Figure 2.0 shows how this is an improvement when we look at the process with PID 475. This has the common name “Binder:475_2” which is related to inter-process communication but doesn’t tell us what the process is, so the common name in this case is unhelpful to see what the process is doing. However, we can see that PID 475 is the Volume Daemon (vold) which has been invoked with a full command line as shown.

Since the arguments and environment variables are essentially located together, and we were showing the arguments list, we decided that we should also show the environment variables for the task, as found. Since this wouldn’t be as commonly used as the command line, we decided that they should be shown as part of the verbose logging showing the internals of the task:

ramalyzer task –pid 475 –verbose –file Osaka.xry

Figure 2.0

Here we can see the task internals for the vold task at PID 475, with the new fields showing both the arguments and the environment variables. The environment variables are probably most useful when investigating if something unexpected or unusual has occurred with a task.

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.