Vagrant run fails to function properly about 50% of the time (Ubuntu Linux client)

[mvh]

Describe the bug I made a Vagrantfile to document the steps needed to do a RAM capture and run Volatility. The run seems to fail about half the time, the runs that work have, I think, a line like DEBUG volatility3.framework.automagic.linux: Linux ASLR shift values determined: physical 6800000 virtual 10200000 in the debug output, the ones that don't have a line like DEBUG volatility3.framework.automagic.linux: Linux ASLR shift values determined: physical 96f1d000 virtual 0

Note that running 'vagrant up' sometimes fails due to hash errors in the kernels with debug symptoms, they return a failure like: default: E: Failed to fetch http://ddebs.ubuntu.com/dists/jammy-updates/main/binary-amd64/Packages.xz File has unexpected size (84408 != 86348). Mirror sync in progress? [IP: 91.189.91.49 80] These errors seem to resolve after a few hours.

Context Volatility Version: Volatility 3 Framework 2.4.1 Operating System: Ubuntu 22.04 Python Version: Python 3.10.6 Suspected Operating System:
Command: see Vagrantfile

To Reproduce Steps to reproduce the behavior: Run the attached Vagrantfile. If should create a file like vrun-2023-03-01T22:17:01.txt which should end with a proper 'linux.pslist' output. Sometimes it does, sometimes it does not. Note that I had to copy the Vagrantfile to 'Vagrantfile.txt' to get it to upload, you will obviously have to rename it back to 'Vagrantfile' to use it.

Expected behavior Again, 'linux.pslist' should not return an empty output, it should return a list of all of the programs

Example output See attached

Additional information I am running 'vagrant' on pop_os but that should not make a difference vrun-2023-03-01T22:17:01.txt vrun-2023-03-01T22:25:10.txt vrun-2023-03-01T22:37:37.txt vrun-2023-03-01T22:44:31.txt vrun-2023-03-01T22:55:17.txt vrun-2023-03-01T23:08:11.txt Vagrantfile.txt

[ikelos]

Hi there, so to try and clarify, you're acquiring memory from the system that vagrant is running on, and it's the same system, but some of the acquisitions work correctly and determine the correct values, and others do not, is that right?

I hate to say this, but some of the difficulty may be running volatility on the system you're doing the acquisition on. If ram contains copies of the kernel banner (say, from a previous execution of volatility) then it might misidentify this as being the actual kernel banner which it uses to determine the correct ASLR shifts. We don't really have many ways of figuring out the ASLR shift from a blind machine, however, if you're running on the system in question, you might be able to extract the relevant information about ASLR and the kernel location from the running system itself, which would both save time and get you more accurate results.

I've copied in @atcuno who may be able to help suggest a way to determine the needed parameters, and then I can help you fashion a configuration file to pass to volatility containing those values to allow the image to be scanned appropriately. That's my best guess as to the issue you're encountering...

[mvh]

Thanks! Based on your feedback, I moved the LiME dump to the beginning of the Vagrantfile and then Volatility 3 worked 10/10 times. Your explanation makes sense.

I'm just doing the Vagrant build as a way to provide some documentation and also provide a sandbox for practice. I think going forward it would make sense to build the LiME kernel module, Volatility 3 profile, and Volatility, then reboot the Vagrant instance to use the sandbox, which would clear out the RAM of any leftovers from processing the debugging kernel. I'll post what I end up with here, it may be helpful to others.

[ikelos]

Cool, thanks for following up on that, I'm glad we figured it out. I'm going to mark this issue as closed, but feel free to continue to add to it with your findings, I think they'll be useful if people go looking. 5:)