So, you have a RAM dump, now what?

For a while now, XRY has been able to dump RAM, and if you are a PRO user, you have been dumping RAM for some time as part of the normal physical dump process whenever an exploit is used, where possible. If you are not a PRO user, you are still able to dump RAM from Samsung devices using the upload mode method. As a user of XRY you can examine the RAM using the hex viewer in XAMN, with or without a PRO license. However, a PRO user now has a choice to look deeper into the structure of the RAM and the processes that were running at the time the dump was taken. This provides a new source of information, and therefore a new source of evidence in mobile devices. This is the first in a series of blog posts intended to highlight this new technology, and how it can be used to look at evidence in a device. For those that already examine RAM in computers, it can hopefully show that the knowledge you have already acquired examining RAM in Linux devices can be used within an Android device also. It should also be noted that much is still unknown, and that we don’t have all the answers, but hopefully we can come together and find those answers and strengthen the field of forensics in RAM.

In the first instance, we should check that we do have a RAM dump as part of the extraction. This can be checked using the XAMN hex viewer. Opening the XRY file and using the hex viewer in tree mode we should be able to see a RAM node. This confirms we have a RAM dump as part of the extraction and that we have an image, at least to use for RAM analysis. The picture below shows a RAM node and a logical node in the hex viewer.

We can then continue to use the hex viewer to ensure there is no bit rot, which will have a detrimental effect on the analysis of the dump. There are ways we can minimize bit rot, such as freezing the handset before dumping, but here, we will just look at identifying dumps with bit rot so that we know if they can be successfully analyzed. As should be well understood, bit rot is a kind of data corruption and if it has occurred on the device during the extraction then we are not able to use that extraction for analysis. If a RAM dump is required, then mitigating processes should be used at seizure and extraction to ensure that the RAM dump integrity is maintained (it is usually a good idea to cool a device before extraction, for example).

We can detect bit rot by looking at an extraction using the hex viewer. Bit rot causes an unusual number of bits in a byte to be set, so an extraction with more bits set over the course of a page at the beginning, in the middle and at the end would indicate that an extraction may be corrupted. In the first picture below, we can see a good extraction, there are a good number of bytes set to zero, and the bytes that do have bits set, aren’t always 0xFF.

Whereas one with bit rot will be like the picture below, where we can see a lot more bits are set, and many of the bytes are also set to 0xFF. We should choose one at each end and one in the middle randomly and see how they look to decide if the extraction can be used for analysis.

We should now be satisfied that the extraction is clean and can be used for analysis. We can now turn to the new analysis tool to examine the RAM extraction. This tool is command line only at present and is a separate tool to the main XRY Pro suite.

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.