MOVP II - 1.5 - ARM Address Space (Volatility and Android / Mobile)

In order to support Android, Volatility now includes an ARM address space. This is the first new hardware architecture supported by Volatility since the inclusion of Intel support in the earliest of releases. The creation of the address space was based upon the ARM documentation.  The address space was first developed by myself during the research that eventually led to our Android memory forensics paper that was published in Digital Investigation.  It was later cleaned up and received some bug fixes by Joe Sylve.

ARM Virtual Addressing

The first noticeable difference between virtual addressing in ARM and virtual addressing in Intel is that ARM mixes and matches sections and pages within the same system as well as pages of different sizes and the Volatility address space needs to account for all of these. The following picture, taken from the referenced ARM manual introduces the two types of sections, both Sections and Supersections, the three types of pages, tiny (1KB), small (4KB), and large (64KB), and the first-level and second-level tables and their descriptors.

As can be seen, this is a much different setup compared to Intel where the paging scheme is much simpler.

First Level Descriptors

To translate a virtual address to a physical offset, which occurs in the vtop function of the ARM address space, the first level descriptor needs to be computed. This process is illustrated in the following diagram and performed in the pde_value function.

Once the first level descriptor is obtained, we then need to determine if it leads us to a second level page table or a section. This is done by checking bits 0 and 1 of the first level descriptor. This is performed in the top level conditionals of the get_pte function and described in the following picture:

Parsing Sections

Sections are parsed in the second conditional of get_pte. If a normal second is found then its address is computed. If a super section is found, an error is printed and the process bails (no translation occurs) as Volatility does not yet support super sections. We have tested many Android devices and none have used super sections so we are comfortable with this limitation for the time being.

Parsing Second-Level Page Tables

If the first-level descriptor describes a coarse page, then Volatility calculates the descriptor for second-level coarse pages and then checks this value to determine the size of the actual page represented, which can be either 64KB or 4KB. 

If the first-level descriptor describes a fine page, then Volatility calculates the descriptor for second-level fine pages and again determines the actual size of the page represented, which can be 64KB, 4KB, or 1KB.

Wrapping Up Translation

After the corresponding section or second-level page table is translated, then we have the physical offset of the virtual address requested. We can then perform memory analysis as normal. 

Note: The links to Volatility SVN for the functions are based on the current reversion (3420). These line numbers will likely change if/when the ARM address space is updated, but the names of the functions will likely not change. You can also check out revision 3420 and follow along in your text editor/IDE in order to follow the line numbers into the future.

64-Bit ARM

The address space currently only supports 32 bit ARM. Devices with 64 bit ARM will likely hit the market sometime this year. It is currently unknown if Android will adopt the 64 bit architecture at all or if they will eventually be forced to as all chips move towards 64 bit.  If anyone has further insight into this please leave us a note in the comments or email/Twitter us. Once there is an official Android device running 64 bit or if/when the emulator gets 64 bit support, the address space will be updated to support the 64 bit translations.

Conclusion

I believe that the inclusion of Android really shows the flexibility and power of the Volatility framework. Intel Linux support was already included in Volatility during the development of Android support, and the only addition needed to make it work was the inclusion of the ARM address space. All of the existing Linux plugins (30+) then immediately worked on all of our Android samples.

Also, we strongly believe that ARM forensics is going to be a key skill going into the future due to it being the sole architecture chosen for mobile phones and other portable devices. Learning how to perform disk and memory forensics on the platform will only serve to better your worth as a forensics practitioner into the future.

As usual, if you have any questions or comments, please leave a note below, find us on Twitter, or send us an email.