So, what is RAMalyzer?

The original work to look at RAM in mobile devices began with the Formobile project. This was a three-year project funded by the European Union and had a range of goals, one of which was to look at obtaining RAM dumps via a hardware exploit and then analyzing the results of the RAM extraction process to find keys and other useful data to get into secure handsets. Discussions within the work packages responsible for RAM extraction and analysis showed that the exploitation part might not be achievable or would take some time, and we decided to look at dumping RAM from Samsung devices as that would provide us with RAM dumps to work with. For this, we used Samsungs upload mode method. This was a known method to dump RAM and was designed to help kernel developers to find problems when a kernel crash happened. A side effect of this debugging process included the ability to download either the whole RAM or selected regions of RAM dependent on the handset being used.

In the first instance we were able to find passcodes in plain text from looking at the strings in the binary. Dumping strings resulted in over two million strings and this was deemed an unsatisfactory result, and it was decided to attempt to design a new application that could act like Volatility. Unlike Volatility which requires a profile that includes data from the kernel compile process, we would not use profiles and attempt to reconstruct processes and their allocated memory from the dump itself. This was successful and a proof-of-concept application was written to test more ideas.

It was around this time that XRY began to be able dump RAM, and we were able to keep testing and expanding the proof-of-concept to keep up with both passcodes and their changing handling within Android, but also look at other applications, such as cloud apps and keyboard applications. This started to become a more useful RAM examination tool, and we started playing with turning this into a product. However, we still don’t know what might be important, so we decided to keep the tool as simple as possible and let others (read customers who will use this) decide what’s important for us. We now have a RAMalyzer tool, which can support a limited number of devices and with some small functionality to help investigate RAM dumps.

XRY RAMalyzer is this new command line tool included within XRY PRO that can be used to analyze process memory within the RAM node of an XRY file. We decided to make it a separate command line tool since we know that not all users of XRY will want to install it, and that we don’t know the best way to present RAM to a user would be. We also think that most users interested in a new tool like this will already be familiar with tools like Volatility, which is also command line, so a command line tool would be appropriate at least for the moment.

XRY RAMalyzer is also meant to work within the XRY File format, so it will work with your XRY PRO dumps, but not with dumps you have taken from other sources. Currently, it doesn’t add to the XRY log file, so contemporaneous notes are required if you are to formally defend your findings. These seem like a lot of limitations, but we just wanted to get it out there and let the users tell us what is important to them. We expect to continue to develop this and eventually to integrate it into the XRY PRO suite in the future.

For now, let’s just look at the command line and what we can potentially use the tool for at this time. The picture below shows the help screen which gives an indication on which commands are available and how the tool can be used. We won’t look at all the commands within this series, but we will look at some of the more relevant ones to an investigation.

The first we will look at is the ‘list’ command. This will list the tasks in the task list as found within the RAM dump. We use the term task here since we reconstruct the task list, which is a list of both processes and anonymous threads that require processing time. The task list is used by the scheduler to choose which task requires processing and its priority so that it can choose the next thing to run. The difference between processes and anonymous threads in practical terms is that processes have their own memory management structures and its own address space, whereas anonymous threads use the kernels address space, and are often owned by kernel thread daemon (kthreadd). Often these are used for servicing hardware and software drivers within the kernel, but since they don’t have their own memory management are considered lower priority currently (we want to look at the apps, right)?

The next command we should look at is the ‘task’ command, since this will tell us some information about the task. Tasks have a lot of potential information included in their structure, and the task command will look at some of this information from the task itself, but also some information from the memory management structures associated with that task. It only shows some information from the task since we don’t want to assume what is important information for the user. We understand that different users will have different requirements, and even the same user may have different requirements dependent on the investigation underway (looking for an instance of malware is very different to looking for message in a messaging app for example). Some of the information we show is important to us for debugging purposes also, so may be completely irrelevant to a user.

Finally, we should look at the ‘regex’ command, where we will pick a target application and attempt to find some useful data within it. Since we are able to use a regex, we can look for both binary signatures and strings within a process, this means that we are able to use the knowledge gained within computer forensics and transfer it to the mobile device investigation.

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.