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!

[Blue0fSky]

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.

[Abyss-W4tcher]

Hi,

I started investigating Windows AArch64, in parallel of @k1nd0ne work, and I think it might be a better place to talk about this subject than in the AArch64 PR ?

As pointed out, I was able to locate the _KARM64_ARCH_STATE struct manually in the memory sample (I cannot debug it with windbg since I do not possess a AArch64 machine :/). This struct seems to not be hibernation specific, which would allow to extract the needed values consistenly via automagic. I think the extraction of these values should be done in a second time, after making the Windows DTB automagic work, with hardcoded page sizes and virtual address space values :

t1sz = 17
addr_mask = 0x7fffffffffff # 2**47-1 <=> 2**(64-17)-1
tcr_el1 = 0x00000605b5513511 # got it from the dump
page_size = 0x1000 # TG1 : bits [31:30] from tcr_el1

By checking out the scanned sections content, I noticed that the following hardcoded offsets :

volatility3/volatility3/framework/automagic/windows.py

Lines 198 to 209 in 6b739f6

	test_sets = [
	(
	"Detecting Self-referential pointer for recent windows",
	[DtbSelfRef64bit()],
	[(0x150000, 0x150000), (0x650000, 0xA0000)],
	),
	(
	"Older windows fixed location self-referential pointers",
	[DtbSelfRefPae(), DtbSelfRef32bit(), DtbSelfRef64bitOldWindows()],
	[(0x30000, 0x1000000)],
	),
	]

points to null bytes sections of the memory sample. To confirm this, I inserted :

if ptr != 0:
    vollog.info(f"non-null ptr found : {hex(ptr)}")

after

volatility3/volatility3/framework/automagic/windows.py

Line 70 in 6b739f6

(ptr,) = struct.unpack(self.ptr_struct, ptr_data)

and got no output.

Do you think it can be related to the hibernation->raw convertion, or could it simply be that we need to determine the appropriate AArch64 sections to scan for a DTB ?

edit :

Using the TTBR1 value, both from the sample and this link, I identified the following BADDR/page_map_offset :

# As opposed to the doc, I noticed that (47,0) was needed instead of (47,1). -> Requires investigation
>>> hex(_mask(0x400000802a9800, 47,0))
'0x802a9800'
>>> hex(_mask(0x400000800a9800 , 47,0))
'0x800a9800'

However, this is a bit of snake biting its tail situation, where we need _KARM64_ARCH_STATE to directly read the DTB (no scanning), but we also need the DTB to translate the _KARM64_ARCH_STATE symbol addresse reliably. Another solution, would be to scan for patterns of the _KARM64_ARCH_STATE, which would allow to directly gain DTB, page size and virtual addressing size...

[Abyss-W4tcher]

By manually creating the AArch64 layer in windows.py, I was able to confirm layer stacking and address translation for WindowsAArch64, without modifying any additional logic (including the arm layer), except for the hardcoded intel.Intel checks in plugins and in the core 🚀:

windows.sessions sample :

* |          1 |      Console |       7804 | FileCoAuth.exe |         VOLATILITY/k1nd0ne | 2024-06-21 05:05:22.000000 UTC
* |          1 |            - |       8860 | powershell.exe |         VOLATILITY/k1nd0ne | 2024-06-21 05:05:38.000000 UTC
* |          1 |            - |       8868 |    conhost.exe |         VOLATILITY/k1nd0ne | 2024-06-21 05:05:38.000000 UTC
* |          1 |            - |       8468 | CredentialEnro |         VOLATILITY/k1nd0ne | 2024-06-21 05:15:40.000000 UTC
* |          1 |            - |        980 |    dllhost.exe |         VOLATILITY/k1nd0ne | 2024-06-21 05:15:40.000000 UTC
* |          1 |            - |       1184 |   rundll32.exe |         VOLATILITY/k1nd0ne | 2024-06-21 05:17:33.000000 UTC
* |          1 |            - |       6400 |    LogonUI.exe |                    /SYSTEM | 2024-06-21 05:17:33.000000 UTC
* |          1 |      Console |       6104 |    dllhost.exe |         VOLATILITY/k1nd0ne | 2024-06-21 05:17:38.000000 UTC
* |        N/A |            - |       1864 | MemCompression |                          - | 2024-06-21 04:56:48.000000 UTC

windows.pslist sample :

  |  PID | PPID |  ImageFileName |          Offset(V) | Threads | Handles | SessionId | Wow64 |                     CreateTime |                       ExitTime | File output
* |    4 |    0 |         System | 0xffffd60f534e2080 |     164 |       - |       N/A | False | 2024-06-21 04:56:45.000000 UTC |                            N/A |    Disabled
* |   92 |    4 |       Registry | 0xffffd60f53496080 |       4 |       - |       N/A | False | 2024-06-21 04:56:41.000000 UTC |                            N/A |    Disabled
* |  372 |    4 |       smss.exe | 0xffffd60f559eb080 |       2 |       - |       N/A | False | 2024-06-21 04:56:45.000000 UTC |

The following needs to be done now :

• Registers automagic, DTB detection (via register, heuristic ?)
• AArch64 integration in windows.py, which needs to be reworked for scalability I guess
• Plugins checks and adjustments for AArch64 integration (applies to Linux too :) )

[Abyss-W4tcher]

I identified general slowness in the mapping() functions, when initated by plugins like threads or netscan

volatility3/volatility3/framework/interfaces/layers.py

Lines 235 to 238 in 6b739f6

	if sections is None:
	sections = [
	(self.minimum_address, self.maximum_address - self.minimum_address)
	]

as it tries to read the entire virtual mapping space (2**46 here) to determine physically mapped virtual pages. It does not make sense from my point of view, to repeat this operation for each plugin (takes ~6 minutes for a 6GB sample).

If I am not mistaken, this problem is quite similar to the windows.strings PR, because we need to map all virtual pages to confidently assure that a set of bytes belongs to a specific process...