Add in Arm64 support

[ikelos]

This is a placeholder for requests concerning Arm/Arm64 support.

[JRomainG]

Hi, I just saw this issue and happen to have an Arm64 Android device, and would love to see support added in Volatility 3!

I built json files from the System.map and module.ko files (available respectively here and here) using dwarf2json.

I also uploaded the original System.map and module.ko files.

I have a 3Gb memory dump from a physical device running Android 9 (and the kernel 4.9) acquired using LiME that I can upload.

Is there any way this could be implemented, or for me to help?

[ikelos]

Hiya, sorry I've taken so long to get back to you, my time's been diverted a bit recently. Thanks very much for the files you've provided. Getting the memory image that goes with them would be much appreciated, in the past we've accepted memory images submitted through google drive (you can send it directly to me as mike.auty@gmail.com and just let me know that you're happy with me sharing it with the other Volatility developers or not).

As this placeholder suggests, it is on our list of things we'd like to implement, but there's a few other large tasks (such as compressed memory for windows) which we need to try and work on too, so I'm afraid I can't guarantee how quickly we'll be able to add it... 5:S

[JRomainG]

Thanks for your answer! Just sent you an email with a link to the memory dump

[kohnakagawa]

Hi. I hope volatility3 support for Windows 10 on Arm.

Currently, Windows 10 on Arm is not widely used, but this OS will be gradually used as the Arm64 laptop devices (e.g., Surface Pro X) come. I checked the symbol tables for Windows. However, these symbol tables for Windows 10 on Arm seems to be missing.

Is there any way to implement this? If you do not have enough time, I will help.

Thanks in advance!

[BlackDeeer]

Hi,

I would like to inquire if support for the arm/arm64 architectures will soon be implemented. Some files in the repository appear to take into account both architectures, but I am unable to analyze a memory dump from a machine running on armv7.

Thank you in advance for your assistance.

Best regards

[Abyss-W4tcher]

Hello, looking forward to implement Linux aarch64 support for Volatility3, I will work on this subject starting from now.

This does not imply that I will be able to provide a functional implementation soon, it is only to inform any peer already working on this.

Volatility state of the art :

• https://github.com/volatilityfoundation/volatility3/tree/arm64-support
• Arm64 volatility#726

Roadmap :

• Virtualization environment (https://gist.github.com/Abyss-W4tcher/8442b6b6b85f725158fe7e9b99e507be)
• Collect documentation and ressources, about aarch64 memory architecture (especially VMSA)
• Extract translation registers (TTBR0_EL1, TTBR1_EL1, TCR_EL1) from live VM
• Achieve kernel address translation (TTBR1 memory) + a few plugins running
• Investigate the "mapping" function and what are contiguous memory regions
• Fix the contiguous block discovery (correct values to return by _translate)
• RaspberryPI emulation + custom kernel with arbitrary address space sizes
• Calculate levels based on TnSZ values (address space max values)
• Support 52 bits VA
• Determine ASLR and KASLR
• Achieve Low space address translation (userland)
• Automagic -> detect page size and virtual address size with symbols and memory dump only.
• AArch64 Android emulation through avd (https://gist.github.com/Abyss-W4tcher/f1833623c975193446315d48c106750e)

TnSZ and PAGE_SIZE are needed, for each memory space (kernel/user).

Details :

• ASLR and KASLR : Current Intel implementation worked well against my samples, with only a small tweak (cls.virtual_to_physical isn't needed)
• Automagic : TTB1 (Kernel Land) is written to swapper_pg_dir, so following current Intel implementation allows to get rid of providing the TTBR1 register.