volatilityfoundation
Arm64
Hello!
This merge request is addressing https://github.com/volatilityfoundation/volatility/issues/687 - adding arm64 linux support for volatility. I would be very happy to hear your comments on code and fix as needed. Most work is rather straight forward - adapting for arm64 page-table format and kernel symbols.
supporting dual-pagetables was not entirely straight forward. In arm64 the entire kernel space is translated with a single pagetable for all process, and each userspace has it's own pagetable only translating userspace addresses (separated by the msb). Thus when working on a process two DTBs must be used. In my implementation (in a separate patch): when the arm64 validity checker finds a valid addresspace, it notifies the addresspace that it is valid - and then that DTB will be stored in the addresspace class as the kernel's page-table. The fisrt valid DTB will then be used as kernelspace DTB, while userspace dtbs may come from the address-space constructor.
My implementation for get_available_pages only traverses userspace pages.
Hi tsahee, Thanks for working on this and submitting a merge request. Are you able to share any memory samples that you used for testing or provide information about the configurations of the system's that you used for testing? I can help coordinate getting you feedback on the merge request. On a related note, you may also consider porting it to Volatility 3 since that is where most of the development effort is focused these days. It would make an interesting submission to the Volatility Plugin Contest!
Thank you! I would really appreciate any feedback on the pull request.
Creating memory dumps can be done with this patched LIme: https://github.com/AGSaidi/LiME.git Creating a profile requires using libdwarf which I had to compile from source (git://git.code.sf.net/p/libdwarf/code) other then that - I used a standard amazon-linux 2 on c6g or m6g instance with "Development Tools" package group.
I can give more detailed instructions, and I am checking in parallel if I can upload a ready profile & memory dump.
Currently volatility 2 is our priority, but I will certainly look at volatility 3.
@awalters Kinda late to the party, but I have a memory dump of a physical device running Android 9 (and the kernel 4.9) made using LiME. Though it was initially to help with the issue here, I can share it with you if it's of any help.
@JRomainG Can you please share that physical dump with me as I was unable to extract one even after so many attempts. It will be very kind of you.
@beena113 I guess this isn't the best place to discuss this, so I dropped you an email directly
@tsahee I am creating a profile for volatility to analyze my image "ram-dump.lime" but I got following errors. I downloaded volatility using link https://github.com/tsahee/volatility.git -b arm64". When I run command "python2 vol.py --profile= Linuxandroid-profilearm64 -f ../ram-dump.lime linux_pslist", it shows error "Volatility debug: Invalid profile selected" but when i run command "$ python2 vol.py --info | grep -i android" it shows "Linuxandroid-profilearm64 - A Profile for Linux android-profile arm64".Can you please help me to remove this.
There’s a space before the name of the profile that you need to remove:
python2 vol.py --profile= Linuxandroid-profilearm64 -f ../ram-dump.lime linux_pslist
Should be
python2 vol.py --profile=Linuxandroid-profilearm64 -f ../ram-dump.lime linux_pslist
However, from what I understood in your emails, you’re having another issue with the detection of the address space
In that case, the information you provided won’t be of any help, since you’re trying to solve another issue
I think it would be best to move this to a separate issue on the dedicated fork to avoid cluttering this thread, and include the information mentioned in the readme:
- The version of volatility you're using
- The operating system used to run volatility
- The version of python used to run volatility
- The suspected operating system of the memory image
- The complete command line you used to run volatility
- The suspected kernel version of the memory image
Including the full output of the command with the -ddd option also probably wouldn’t hurt
@beena113 I guess this isn't the best place to discuss this, so I dropped you an email directly
Would be great if you could share the lime dump to me too. The email is [email protected] Thank you!
Hello Panchajanya, Sorry it was a long time ago and I don't have it now. Regards, On Tuesday, April 2, 2024 at 03:11:40 PM GMT+5, panchajanya. @.***> wrote:
@beena113 I guess this isn't the best place to discuss this, so I dropped you an email directly
Would be great if you could share the lime dump to me too. The email is @.*** Thank you!
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>