In the last post we looked at the command line interface and some of the internal commands that we might use to investigate RAM in a device. We will now start looking at a device with some test data in. The test data was generated by one of our trainers who is an experienced practitioner as well as an experienced trainer. He documented what he did and when he did it so that we had some data to show how me might find this on a real device. This is the subject of a different post where Chris talks about generating test data and some common search terms from computer forensics that could be used in mobile device forensics. A PDF cheat sheet of search terms can be downloaded from the RAMalyzer section of our customer forum.

For the rest of this post series, we will examine the test RAM dump and find some of the data that we know is there to prove our search processes can be transferred and show that knowledge already gained can be transferred. The test data we will look for is search terms within the Firefox web browser. We know from the test documentation that Chris performed some searches and ran a video. So, we should limit our investigation to the Firefox application if possible. We also know how to look for searches within Firefox, so we can put that knowledge to good use and find our evidence. Chris’ RAM dump was contained within a file called osaka.xry and was an extraction of an SM-G891B device via the upload mode method.

The first thing we should do is verify that Firefox was running on the device, we can verify this by checking the task listing using the ‘list’ command:
xryramalyzer list –file osaka.xry

The output of the list command will provide us with a good way to verify that the RAM extraction is supported and that we have no subtle bit rot problems in the extraction. It will show us a list of both processes and anonymous threads, since it provides a listing of the task tree (in much the same way as running ‘ps -A’ on the device will show all running processes).

Here we can see such an output that has been truncated (this device had nearly 700 tasks in the task list, so it has been truncated for brevity). We can see that there is more than one Firefox entry in the list. We can see their PID and the fact that they are processes (denoted by the ‘P’ in the process type – anonymous threads are denoted with a ‘T’). The names here come from the task structure in the task list and are truncated to 16 bytes.

We can ensure that we have all the tasks with the name Firefox by modifying our list search with a name parameter:

xryramalyzer list –name firefox –file osaka.xry

this will give us an output of the three processes we saw before, verifying that we had seen all the tasks with Firefox in the name:

This gives us a lot of information on its own. We can see that there were three tabs open, when Firefox opens a new tab, it will create a new process and place that in the task list. One of those tabs was running a video (the addition of the ‘gpu’ string shows that a GPU was being used here, probably for video). There were another two tabs being used for browsing, and since we are looking for search terms in the process memory, these are the ones we should examine first.

When we look at the test data, we can see that indeed Chris was watching a video before he ran the extraction. We can also see that there were another 2 tabs open (tab3 and tab14) and that he records using Firefox for a number of searches and that he clicked a link for a pub. This may account for the extra tab (clicking a link may be used to open a new tab with that content in it). But it does establish that there has been activity using Firefox on this device, and that we are able to continue our examination of this device in a targeted way.

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.