Android Arm64 profile System.map missing key

[JRomainG]

Description

I am working with a memory dump from a physical Android device running Android 9 (kernel 4.9).
I built the kernel and OS myself, and managed to build a profile and do a memory dump using LiME.

Unfortunately, I haven't been able to use the profile I built to analyze the memory image, as the System.map file is missing both the init_level4_pgt and the init_top_pgt key. I rebuilt the kernel just to make sure it wasn't a mistake, but indeed there is no such key.

I uploaded the System.map file here, and the module.dwarf file here. I can also provide the memory dump from the physical device if it's of any help.

I have seen other issues opened about Android/ARM dumps, but they don't seem to be facing the same issue as I am. Would there be another way of locating the DTB, using other keys from the System.map? If not, as I have access to the live phone before doing the dump, can I perhaps get the missing information from elsewhere and bypass the scanner?

Volatility version

python vol.py --info
Volatility Foundation Volatility Framework 2.6.1

git show --summary
commit 805a6a377c4fcf153b2f4fb5929ade80dc6c8543 (HEAD -> master, origin/master, origin/HEAD)
Author: atcuno <andrew@dfir.org>
Date:   Tue Mar 3 12:21:49 2020 -0600

    Update mac_dump_maps

I also applied the changes from #652 to add a missing symbol in the dwarf parser and make the profile show up as ARM.

Operation system used to run volatility

uname -rvpio
4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC 2020 x86_64 x86_64 GNU/Linux

Python version used to run volatility

python --version
Python 2.7.17

Operation system of the memory image

AOSP Pie 9.0 with the 4.9 kernel (build number aosp_f5121 9 PQ2A).

Command line entered to run volatility

python vol.py --profile=LinuxAndroidProfileARM -f ram-dump.lime linux_pslist --debug

[...]

DEBUG   : volatility.debug    : Trying <class 'volatility.plugins.addrspaces.standard.FileAddressSpace'> 
DEBUG   : volatility.debug    : Succeeded instantiating <volatility.plugins.addrspaces.standard.FileAddressSpace object at 0x7f9013075390>

[...]

DEBUG   : volatility.debug    : Trying <class 'volatility.plugins.addrspaces.lime.LimeAddressSpace'> 
DEBUG   : volatility.debug    : Succeeded instantiating <volatility.plugins.addrspaces.lime.LimeAddressSpace object at 0x7f9013075350>

[...]

DEBUG   : volatility.debug    : Trying <class 'volatility.plugins.addrspaces.arm.ArmAddressSpace'> 
Traceback (most recent call last):
  File "/android/volatility/volatility/utils.py", line 48, in load_as
    base_as = cls(base_as, config, astype = astype, **kwargs)
  File "/android/volatility/volatility/plugins/addrspaces/paged.py", line 40, in __init__
    self.dtb = dtb or self.load_dtb()
  File "/android/volatility/volatility/plugins/addrspaces/paged.py", line 100, in load_dtb
    dtb = obj.VolMagic(self.base).DTB.v()
  File "/android/volatility/volatility/obj.py", line 795, in v
    return self.get_best_suggestion()
  File "/android/volatility/volatility/obj.py", line 821, in get_best_suggestion
    for val in self.get_suggestions():
  File "/android/volatility/volatility/obj.py", line 813, in get_suggestions
    for x in self.generate_suggestions():
  File "/android/volatility/volatility/plugins/overlays/linux/linux.py", line 2344, in generate_suggestions
    dtb_sym_addr   = tbl[sym][0][0] + virtual_shift_address
KeyError: 'init_top_pgt'

[hanetzer]

Yeah, that's x86/amd64 only, apparently. arm64 has idmap_pg_dir and
swapper_pg_dir in System.map; I think this is akin to what they want.
They should guard the change from swapper_pg_dir with a check for x86/
amd64 systems, though I'm unsure about the python struct.unpack stuff
used for arm in this situation (eg the '<Q' and '<I' bits).

[JRomainG]

Thanks for the info!
If I'm not mistaken, "<Q" should be used for arm64. My temporary solution was to rely on the swapperScan instead of using the info from System.map.
Unfortunately, the virtual to physical address translation isn't implemented for arm64, so it's not quite enough to analyze memory dumps for that architecture yet.

[hanetzer]

Yeah. I ended up switching to an arm32 phone for that.

[atcuno]

Volatility 2 does not have support for ARM64 analysis.

We certainly would be open to support being added by the community. You can also consider writing the support for Volatility 3 instead as it will have a longer shelf life.