What was the web search?

There are a few search engines that can be used to look for things on the Internet. The biggest, by far, is Google. Our investigation into the test handset has reached a point where we have identified that Firefox is installed on the device, and that it has been active. Now we can continue the investigation by looking for actual instances of searches from Google. We saw in the last post that there were three instances of Firefox in the task tree, with one that was probably playing a video in a tab, and another two tabs.

We use the ‘regex’ command to perform searches on the data within the RAM extraction. As the command name suggests, we can use our collected store of regular expressions that we use for other tools for searching for artifacts within the RAM analysis process which can include both strings and binary searches. A common regular expression for looking for searches performed by Google is:

www.google.com\/search\?q=

which is the URL posted to Google to perform the search. This includes the escape characters for the forward slash and question mark, making it a valid regular expression (rather than just a string search).

We also should target our search to a particular application. We can run a regular expression across the whole RAM extraction and find results, but this would not provide context. As an investigator, finding the data is the first step in finding evidence, it only becomes evidence when some context is placed on the data (why is it there, how did it get there for example). So, we must target our regular expression to a particular application, or even a single process in this case. This would then show that, in this case, Firefox was used to perform this search.

Let us then, perform this search, using this regular expression on one of the processes identified by the list command. Let us first remind ourselves which process IDs are relevant in this case.

We can discount the task with PID 25771 for the moment, since it appears to be showing a video, which leaves PIDs 25721 and 26814. We will use the process 25721 for our initial search, for no other reason than it appears first in the list above.

We have now assembled all the information we need to perform our regular expression search on a process that was running in RAM. The complete command line for the XRYRAMalyzer:

xryramalyzer regex –pattern «www.google.com\/search\?q=» –pid 25721 –file osaka.xry

We can run this on the file and after a short time will get the output:

What does this show us? In the first instance, it shows that we only looked in one process. We can run the search across all tasks in the task tree. This can take some significant time, since reconstructing the tasks allocated pages can take a few seconds, then a search would have to be made on all pages for each task in the tree. The output would show which tasks had a hit for the search term which still has value if you aren’t sure which application was used for a particular artifact, or if an artifact was shared by a few applications (think of how a picture might be taken and shared onto a cloud application for example).

Secondly, this gives us a location in the file to find the artifact. This assumes a flat file was used as input which may not be the case, so some additional mathematical work may be required to find the artifact. This was the case in this extraction, where the first file was of length 0x80000000, so any file offsets over that would be in the second file, at an offset with this value subtracted. Let us look at the first result:

25721    0x0000000014acf110 www.google.com/search?q=

This shows it was found in the first file in the extraction, so we can directly look:

Here we can see the artifact was indeed a search using the Firefox client with the search term being for “the plough”. This is a common name for a pub. Let us look at another:

25721    0x00000002dafa5910 www.google.com/search?q=

This is the last one in the results and is in the second file. Since we can see it is greater than the first file, we can take its size off the result and look in the second file at 0x025afa5910. This gives us the result:

Which shows a search result for london.police pictures. This was also one of the searches that were in the test data.

We can now see that Firefox was used for several searches and have shown that already gained knowledge could be used to find a common artifact in memory taken from a device. Some knowledge about how the device is extracted may be required and we shall look at some of this in future posts. We can also use the tool for different contexts, we may need to look at a task in detail, or a different way to look for malicious behaviour for example. We are able to show some different data about a task to aid in this, and this is the subject of further posts in this series.

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.