volatilityfoundation
Page Fault at entry 0x0 in table page table
Describe the bug Creating a dump with:
virsh dump <domainname> <dumpfile> --memory-only --format=elf
reveals a file of type:
ELF 64-bit LSB core file, Intel 80386, version 1 (SYSV), SVR4-style
The system was running Debian with linux-image-3.16.0-7-686-pae:i386, from the 3.16.59-1 package. I extracted the corresponding dbg package and ran the latest dwarf2json (built from HEAD) on the debug symbol file shipped by Debian (so kernel and debug file should exactly match).
Running volatility:
$ ./vol.py -vvv -f <dumpfile> linux.pslist.PsList
...
DEBUG volatility.framework.automagic.symbol_finder: Identified banner: b'Linux version 3.16.0-7-686-pae ([email protected]) (gcc version 4.9.2 (Debian 4.9.2-10+deb8u1) ) #1 SMP Debian 3.16.59-1 (2018-10-03)\n\x00'
DEBUG volatility.framework.automagic.symbol_finder: Using symbol library: file:///somewhere/volatility3/volatility/symbols/linux/vmlinux-3.16.0-7-686-pae.json
...
DEBUG volatility.framework.automagic.linux: Linux ASLR shift values determined: physical 0 virtual 0
...
File "/somewhere/volatility3/volatility/framework/layers/intel.py", line 125, in _translate_entry
"Page Fault at entry " + hex(entry) + " in table " + name)
volatility.framework.exceptions.PagedInvalidAddressException: Page Fault at entry 0x0 in table page table
Volatility was unable to read a requested page:
Page error 0xc1634c54 in layer primary (Page Fault at entry 0x0 in table page table)
It also happens when re-taking the dump after letting the machine run for a while, with the exact same address.
Context Volatility Version: 69be2157fbc5b2cb22811d068d88745ed2afcd84 Operating System: Gentoo Linux x86_64 (but also reproducible e.g. on Kali) Python Version: 3.7.7 Suspected Operating System: Debian 8 / Jessie Command: Any command inspecting the image
Can you please paste the full backtrace? That way I can see the lines of code that caused the fault.
@atcuno Yes, of course, here you go (only modified the paths ;-) ):
DEBUG volatility.framework.automagic.linux: Linux ASLR shift values determined: physical 0 virtual 0
DEBUG root : Traceback (most recent call last):
File "/somewhere/volatility/cli/__init__.py", line 292, in run
renderers[args.renderer]().render(constructed.run())
File "/somewhere/volatility/cli/text_renderer.py", line 163, in render
grid.populate(visitor, outfd)
File "/somewhere/volatility/framework/renderers/__init__.py", line 196, in populate
for (level, item) in self._generator:
File "/somewhere/volatility/framework/plugins/linux/pslist.py", line 53, in _generator
filter_func = self.create_pid_filter([self.config.get('pid', None)])):
File "/somewhere/volatility/framework/plugins/linux/pslist.py", line 84, in list_tasks
for task in init_task.tasks:
File "/somewhere/volatility/framework/symbols/linux/extensions/__init__.py", line 293, in to_list
link = getattr(self, direction).dereference()
File "/somewhere/volatility/framework/objects/__init__.py", line 707, in __getattr__
member = template(context = self._context, object_info = object_info)
File "/somewhere/volatility/framework/objects/templates.py", line 72, in __call__
return self.vol.object_class(context = context, object_info = object_info, **arguments)
File "/somewhere/volatility/framework/objects/__init__.py", line 120, in __new__
value = cls._unmarshall(context, data_format, object_info)
File "/somewhere/volatility/framework/objects/__init__.py", line 304, in _unmarshall
data = context.layers.read(object_info.layer_name, object_info.offset, length)
File "/somewhere/volatility/framework/interfaces/layers.py", line 540, in read
return self[layer].read(offset, length, pad)
File "/somewhere/volatility/framework/layers/linear.py", line 38, in read
for (offset, _, mapped_offset, mapped_length, layer) in self.mapping(offset, length, ignore_errors = pad):
File "/somewhere/volatility/framework/layers/intel.py", line 197, in mapping
chunk_offset, page_size, layer_name = self._translate(offset)
File "/somewhere/volatility/framework/layers/intel.py", line 99, in _translate
entry, position = self._translate_entry(offset)
File "/somewhere/volatility/framework/layers/intel.py", line 125, in _translate_entry
"Page Fault at entry " + hex(entry) + " in table " + name)
volatility.framework.exceptions.PagedInvalidAddressException: Page Fault at entry 0x0 in table page table
Volatility was unable to read a requested page:
Page error 0xc1634c54 in layer primary (Page Fault at entry 0x0 in table page table)
* Memory smear during acquisition (try re-acquiring if possible)
* An intentionally invalid page lookup (operating system protection)
* A bug in the plugin/volatility (re-run with -vvv and file a bug)
No further results will be produced
Ok thanks, I see its at: https://github.com/volatilityfoundation/volatility3/blob/master/volatility/framework/symbols/linux/extensions/init.py#L293
I will get a patch in for that today.
If you are comfortable coding, you can patch yourself in the meantime by putting the "link = " in a try/except, with catching "exceptions.PagedInvalidAddressException" and then "return" in the except block.
Interesting, thanks! So I changed that to:
try:
link = getattr(self, direction).dereference()
except exceptions.PagedInvalidAddressException:
return
and indeed the error and trace are gone!
I subsequently tried all linux. plugins. However, the initally used PsList and most others:
linux.pslist.PsListlinux.pstree.PsTreelinux.proc.Mapslinux.bash.Bashlinux.lsmod.Lsmodlinux.lsof.Lsoflinux.malfind.Malfind
output nothing apart from the column headers. Is that expected?
I then went on and tried
linux.check_syscall.Check_syscall
which produced this trace:
DEBUG root : Traceback (most recent call last):
File "/somewhere/volatility/cli/__init__.py", line 292, in run
renderers[args.renderer]().render(constructed.run())
File "/somewhere/volatility/cli/text_renderer.py", line 163, in render
grid.populate(visitor, outfd)
File "/somewhere/volatility/framework/renderers/__init__.py", line 196, in populate
for (level, item) in self._generator:
File "/somewhere/volatility/framework/plugins/linux/check_syscall.py", line 161, in _generator
for (i, call_addr) in enumerate(table):
File "/usr/lib/python-exec/python3.7/../../../lib/python3.7/_collections_abc.py", line 883, in __iter__
v = self[i]
File "/somewhere/volatility/framework/objects/__init__.py", line 591, in __getitem__
result += [self.vol.subtype(context = self._context, object_info = object_info)]
File "/somewhere/volatility/framework/objects/templates.py", line 72, in __call__
return self.vol.object_class(context = context, object_info = object_info, **arguments)
File "/somewhere/volatility/framework/objects/__init__.py", line 120, in __new__
value = cls._unmarshall(context, data_format, object_info)
File "/somewhere/volatility/framework/objects/__init__.py", line 304, in _unmarshall
data = context.layers.read(object_info.layer_name, object_info.offset, length)
File "/somewhere/volatility/framework/interfaces/layers.py", line 540, in read
return self[layer].read(offset, length, pad)
File "/somewhere/volatility/framework/layers/linear.py", line 38, in read
for (offset, _, mapped_offset, mapped_length, layer) in self.mapping(offset, length, ignore_errors = pad):
File "/somewhere/volatility/framework/layers/intel.py", line 197, in mapping
chunk_offset, page_size, layer_name = self._translate(offset)
File "/somewhere/volatility/framework/layers/intel.py", line 99, in _translate
entry, position = self._translate_entry(offset)
File "/somewhere/volatility/framework/layers/intel.py", line 125, in _translate_entry
"Page Fault at entry " + hex(entry) + " in table " + name)
volatility.framework.exceptions.PagedInvalidAddressException: Page Fault at entry 0x0 in table page table
Volatility was unable to read a requested page:
Page error 0xc14b7300 in layer primary (Page Fault at entry 0x0 in table page table)
* Memory smear during acquisition (try re-acquiring if possible)
* An intentionally invalid page lookup (operating system protection)
* A bug in the plugin/volatility (re-run with -vvv and file a bug)
No further results will be produced
Furthermore, also linux.check_afinfo.Check_afinfo produces a trace:
DEBUG root : Traceback (most recent call last):
File "/somewhere/volatility/cli/__init__.py", line 292, in run
renderers[args.renderer]().render(constructed.run())
File "/somewhere/volatility/cli/text_renderer.py", line 163, in render
grid.populate(visitor, outfd)
File "/somewhere/volatility/framework/renderers/__init__.py", line 196, in populate
for (level, item) in self._generator:
File "/somewhere/volatility/framework/plugins/linux/check_afinfo.py", line 86, in _generator
for name, member, address in self._check_afinfo(global_var_name, global_var, op_members, seq_members):
File "/somewhere/volatility/framework/plugins/linux/check_afinfo.py", line 52, in _check_afinfo
for hooked_member, hook_address in self._check_members(var.seq_fops, var_name, op_members):
File "/somewhere/volatility/framework/objects/__init__.py", line 707, in __getattr__
member = template(context = self._context, object_info = object_info)
File "/somewhere/volatility/framework/objects/templates.py", line 72, in __call__
return self.vol.object_class(context = context, object_info = object_info, **arguments)
File "/somewhere/volatility/framework/objects/__init__.py", line 120, in __new__
value = cls._unmarshall(context, data_format, object_info)
File "/somewhere/volatility/framework/objects/__init__.py", line 304, in _unmarshall
data = context.layers.read(object_info.layer_name, object_info.offset, length)
File "/somewhere/volatility/framework/interfaces/layers.py", line 540, in read
return self[layer].read(offset, length, pad)
File "/somewhere/volatility/framework/layers/linear.py", line 38, in read
for (offset, _, mapped_offset, mapped_length, layer) in self.mapping(offset, length, ignore_errors = pad):
File "/somewhere/volatility/framework/layers/intel.py", line 197, in mapping
chunk_offset, page_size, layer_name = self._translate(offset)
File "/somewhere/volatility/framework/layers/intel.py", line 99, in _translate
entry, position = self._translate_entry(offset)
File "/somewhere/volatility/framework/layers/intel.py", line 125, in _translate_entry
"Page Fault at entry " + hex(entry) + " in table " + name)
volatility.framework.exceptions.PagedInvalidAddressException: Page Fault at entry 0x0 in table page table
Volatility was unable to read a requested page:
Page error 0xc16a0910 in layer primary (Page Fault at entry 0x0 in table page table)
* Memory smear during acquisition (try re-acquiring if possible)
* An intentionally invalid page lookup (operating system protection)
* A bug in the plugin/volatility (re-run with -vvv and file a bug)
No further results will be produced
That feels like something is wrong (but I don't have a clue what this might be, the symbols should match since both kernels and symbols came from Debian upstream, and virsh dump seems to create the correct format). Also, Taking a memory dump after swapoff inside the VM did not change things.
It seems like there are a couple things here.
@olifre - would be up for testing this sample with Volatility 2 and see if linux_pslist produces a process list? You will need to make a custom profile, but it seems like you have the needed files since you made a Volatility 3 one.
It currently seems like either the sample is really corrupt or that our translation layer for parsing the ELF file is wrong. The comparison with Volatility 2 would really help determine that.
The "good" news here is that your sample is triggering smear-related bugs in plugins that we need to fix.
@ikelos looking at the system call backtrace, the bug comes from this line when the array is enumerated: https://github.com/volatilityfoundation/volatility3/blob/master/volatility/framework/plugins/linux/check_syscall.py#L156
What do you propose as the best fix? I could check that "tableaddr" is a valid address, but that would cover only where the table starts. If it ever crossed page boundaries, that would not be a complete check.
It really seems like vmlinux.object() should throw an exception if the object is asked for on page(s) needed to read the data structure, but definitely want to hear your thoughts and also what the code should look like to correctly handle this.
@ikelos - it seems the same root cause on this line:
https://github.com/volatilityfoundation/volatility3/blob/master/volatility/framework/plugins/linux/check_afinfo.py#L84
Is what also leads to afinfo backtracing.
I'd like to know if this is a corrupted image or not before we spend time trying to "fix" something that may well not be broken. You know my views on silently dropping bad values in an attempt to be helpful to users, it must be clear that this is not perfect information and that something is very definitely "up" with the results we're returning. I don't like papering over errors except in extreme situations where the remaining output would be more beneficial than ending the plugin and where the fact that something went awry is clearly indicated to the user (in this instance, getting a blank list would have been harder for us to debug and of no use to the user in determining that something was wrong).
I want to stress again backtraces are not necessarily bugs.
That's interesting. Volatility2 tells me:
$ python2 vol.py --profile=Linuxvmlinux-3_16_0-7-686-paex86 --debug -f some-machine-no-swap.dmp linux_pstree
...
DEBUG : volatility.debug : Trying <class 'volatility.plugins.addrspaces.elfcoredump.QemuCoreDumpElf'>
DEBUG : volatility.debug : Succeeded instantiating <volatility.plugins.addrspaces.elfcoredump.QemuCoreDumpElf object at 0x7f970cf9ee10>
DEBUG : volatility.debug : Voting round
DEBUG : volatility.debug : Trying <class 'volatility.plugins.addrspaces.macho.MachOAddressSpace'>
DEBUG : volatility.debug : Trying <class 'volatility.plugins.addrspaces.lime.LimeAddressSpace'>
DEBUG : volatility.debug : Trying <class 'volatility.plugins.addrspaces.hibernate.WindowsHiberFileSpace32'>
DEBUG : volatility.debug : Trying <class 'volatility.plugins.addrspaces.crashbmp.WindowsCrashDumpSpace64BitMap'>
DEBUG : volatility.debug : Trying <class 'volatility.plugins.addrspaces.vmem.VMWareMetaAddressSpace'>
DEBUG : volatility.debug : Trying <class 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace64'>
DEBUG : volatility.debug : Trying <class 'volatility.plugins.addrspaces.hpak.HPAKAddressSpace'>
DEBUG : volatility.debug : Trying <class 'volatility.plugins.addrspaces.elfcoredump.VirtualBoxCoreDumpElf64'>
DEBUG : volatility.debug : Trying <class 'volatility.plugins.addrspaces.vmware.VMWareAddressSpace'>
DEBUG : volatility.debug : Trying <class 'volatility.plugins.addrspaces.elfcoredump.QemuCoreDumpElf'>
DEBUG : volatility.debug : Trying <class 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace32'>
DEBUG : volatility.debug : Trying <class 'volatility.plugins.addrspaces.amd64.SkipDuplicatesAMD64PagedMemory'>
DEBUG : volatility.debug : Trying <class 'volatility.plugins.addrspaces.amd64.WindowsAMD64PagedMemory'>
DEBUG : volatility.debug : Trying <class 'volatility.plugins.addrspaces.amd64.LinuxAMD64PagedMemory'>
DEBUG : volatility.debug : Trying <class 'volatility.plugins.addrspaces.amd64.AMD64PagedMemory'>
DEBUG : volatility.debug : Trying <class 'volatility.plugins.addrspaces.intel.IA32PagedMemoryPae'>
DEBUG : volatility.debug : Failed instantiating (exception): 'comm'
DEBUG : volatility.debug : Trying <class 'volatility.plugins.addrspaces.intel.IA32PagedMemory'>
DEBUG : volatility.debug : Failed instantiating (exception): 'comm'
DEBUG : volatility.debug : Trying <class 'volatility.plugins.addrspaces.osxpmemelf.OSXPmemELF'>
DEBUG : volatility.debug : Trying <class 'volatility.plugins.addrspaces.standard.FileAddressSpace'>
DEBUG : volatility.debug : Trying <class 'volatility.plugins.addrspaces.arm.ArmAddressSpace'>
DEBUG : volatility.debug : Failed instantiating (exception): 'comm'
No suitable address space mapping found
Tried to open image as:
MachOAddressSpace: mac: need base
LimeAddressSpace: lime: need base
WindowsHiberFileSpace32: No base Address Space
WindowsCrashDumpSpace64BitMap: No base Address Space
VMWareMetaAddressSpace: No base Address Space
WindowsCrashDumpSpace64: No base Address Space
HPAKAddressSpace: No base Address Space
VirtualBoxCoreDumpElf64: No base Address Space
VMWareAddressSpace: No base Address Space
QemuCoreDumpElf: No base Address Space
WindowsCrashDumpSpace32: No base Address Space
SkipDuplicatesAMD64PagedMemory: No base Address Space
WindowsAMD64PagedMemory: No base Address Space
LinuxAMD64PagedMemory: No base Address Space
AMD64PagedMemory: No base Address Space
IA32PagedMemoryPae: No base Address Space
IA32PagedMemory: No base Address Space
OSXPmemELF: No base Address Space
MachOAddressSpace: MachO Header signature invalid
LimeAddressSpace: Invalid Lime header signature
WindowsHiberFileSpace32: PO_MEMORY_IMAGE is not available in profile
WindowsCrashDumpSpace64BitMap: Header signature invalid
VMWareMetaAddressSpace: VMware metadata file is not available
WindowsCrashDumpSpace64: Header signature invalid
HPAKAddressSpace: Invalid magic found
VirtualBoxCoreDumpElf64: ELF error: did not find any PT_NOTE segment with VBCORE
VMWareAddressSpace: Invalid VMware signature: 0x464c457f
MachOAddressSpace: MachO Header signature invalid
LimeAddressSpace: Invalid Lime header signature
WindowsHiberFileSpace32: PO_MEMORY_IMAGE is not available in profile
WindowsCrashDumpSpace64BitMap: Header signature invalid
VMWareMetaAddressSpace: VMware metadata file is not available
WindowsCrashDumpSpace64: Header signature invalid
HPAKAddressSpace: Invalid magic found
VirtualBoxCoreDumpElf64: ELF Header signature invalid
VMWareAddressSpace: Invalid VMware signature: 0xf000ff53
QemuCoreDumpElf: ELF Header signature invalid
WindowsCrashDumpSpace32: Header signature invalid
SkipDuplicatesAMD64PagedMemory: Incompatible profile Linuxvmlinux-3_16_0-7-686-paex86 selected
WindowsAMD64PagedMemory: Incompatible profile Linuxvmlinux-3_16_0-7-686-paex86 selected
LinuxAMD64PagedMemory: Incompatible profile Linuxvmlinux-3_16_0-7-686-paex86 selected
AMD64PagedMemory: Incompatible profile Linuxvmlinux-3_16_0-7-686-paex86 selected
IA32PagedMemoryPae - EXCEPTION: 'comm'
IA32PagedMemory - EXCEPTION: 'comm'
OSXPmemELF: ELF Header signature invalid
FileAddressSpace: Must be first Address Space
ArmAddressSpace - EXCEPTION: 'comm'
Let me know if you need all lines. Feels like it does not like the ELF format?
As stated, the dump is created with virsh dump after suspending the VM, so no smearing should be possible and I don't see a way the image can be corrupted (but maybe, the ELF format is somehow misinterpreted?).
@ikelos
Unhandled page faults are definitely bugs in our code, and plugins not being able to know if an object they instantiated is valid or not makes reliable programming extremely hard-to-impossible to do.
Analysts that get results like empty/short process lists and such will notice like what happened in this ticket.
@olifre Could you please apply this patch to your vol2 code and then re-run:
$ git diff volatility/utils.py
diff --git a/volatility/utils.py b/volatility/utils.py
index 8795f26d..661604bb 100644
--- a/volatility/utils.py
+++ b/volatility/utils.py
@@ -53,10 +53,10 @@ def load_as(config, astype = 'virtual', **kwargs):
debug.debug("Failed instantiating {0}: {1}".format(cls.__name__, e), 2)
error.append_reason(cls.__name__, e)
continue
- except Exception, e:
- debug.debug("Failed instantiating (exception): {0}".format(e))
- error.append_reason(cls.__name__ + " - EXCEPTION", e)
- continue
+ #except Exception, e:
+ #debug.debug("Failed instantiating (exception): {0}".format(e))
+ #error.append_reason(cls.__name__ + " - EXCEPTION", e)
+ #continue
if not isinstance(base_as, addrspace.AbstractVirtualAddressSpace) and (astype == 'virtual'):
base_as = None
It should cause a full backtrace to be printed where you are currently getting one line with:
"DEBUG : volatility.debug : Failed instantiating (exception): 'comm'"
that is not an expected exception. Please paste the full backtrace you get.
@atcuno Here you go:
Traceback (most recent call last):
File "vol.py", line 192, in <module>
main()
File "vol.py", line 183, in main
command.execute()
File "/somewhere/volatility/plugins/linux/common.py", line 67, in execute
commands.Command.execute(self, *args, **kwargs)
File "/somewhere/volatility/commands.py", line 147, in execute
func(outfd, data)
File "/somewhere/volatility/plugins/linux/pstree.py", line 83, in render_text
for task in data:
File "/somewhere/volatility/plugins/linux/pslist.py", line 65, in calculate
linux_common.set_plugin_members(self)
File "/somewhere/volatility/plugins/linux/common.py", line 48, in set_plugin_members
obj_ref.addr_space = utils.load_as(obj_ref._config)
File "/somewhere/volatility/utils.py", line 48, in load_as
base_as = cls(base_as, config, astype = astype, **kwargs)
File "/somewhere/volatility/plugins/addrspaces/intel.py", line 83, in __init__
paged.AbstractWritablePagedMemory.__init__(self, base, config, dtb = dtb, skip_as_check = skip_as_check, *args, **kwargs)
File "/somewhere/volatility/plugins/addrspaces/paged.py", line 40, in __init__
self.dtb = dtb or self.load_dtb()
File "/somewhere/volatility/plugins/addrspaces/paged.py", line 100, in load_dtb
dtb = obj.VolMagic(self.base).DTB.v()
File "/somewhere/volatility/obj.py", line 795, in v
return self.get_best_suggestion()
File "/somewhere/volatility/obj.py", line 821, in get_best_suggestion
for val in self.get_suggestions():
File "/somewhere/volatility/obj.py", line 813, in get_suggestions
for x in self.generate_suggestions():
File "/somewhere/volatility/plugins/overlays/linux/linux.py", line 2365, in generate_suggestions
comm_offset = profile.get_obj_offset("task_struct", "comm")
File "/somewhere/volatility/obj.py", line 1015, in get_obj_offset
offset, _cls = tmp.members[member]
KeyError: 'comm'
That's Python 2.7.18 (in case it matters).
Ok the profile is definitely broken if you are getting that error. task_struct has a "comm" member in all versions of Linux going back to the beginning.
Could you upload the profile you made, and did you follow this for the Volatility 2 profile? https://github.com/volatilityfoundation/volatility/wiki/Linux#creating-a-new-profile
@atcuno Argh, my bad!
To summarize: When following the instructions you linked (did that before), I hit: https://github.com/volatilityfoundation/profiles/issues/45 So I presumed that, as is the case with Volatility 3 to my understanding, using the dwarf debug symbols provided by Debian work. So I zipped together the files:
/usr/lib/debug/boot/vmlinux-3.16.0-7-686-paetaken from https://snapshot.debian.org/archive/debian-security/20181004T151533Z/pool/updates/main/l/linux/linux-image-3.16.0-7-686-pae-dbg_3.16.59-1_i386.deb/boot/System.map-3.16.0-7-686-paetaken from https://snapshot.debian.org/archive/debian-security/20181004T151533Z/pool/updates/main/l/linux/linux-image-3.16.0-7-686-pae_3.16.59-1_i386.deb
For Volatility 3, I just fed the /usr/lib/debug/boot/vmlinux-3.16.0-7-686-pae file to dwarf2json.
For Volatility 2, I forgot to run dwarfdump first...
I did now do that and rezipped things. Here's the new trace I get:
Traceback (most recent call last):
File "vol.py", line 192, in <module>
main()
File "vol.py", line 183, in main
command.execute()
File "/home/olifre/gits/forensics/volatility/volatility/plugins/linux/common.py", line 67, in execute
commands.Command.execute(self, *args, **kwargs)
File "/home/olifre/gits/forensics/volatility/volatility/commands.py", line 116, in execute
if not self.is_valid_profile(profs[self._config.PROFILE]()):
File "/home/olifre/gits/forensics/volatility/volatility/plugins/overlays/linux/linux.py", line 218, in __init__
obj.Profile.__init__(self, *args, **kwargs)
File "/home/olifre/gits/forensics/volatility/volatility/obj.py", line 862, in __init__
self.reset()
File "/home/olifre/gits/forensics/volatility/volatility/plugins/overlays/linux/linux.py", line 232, in reset
self.load_vtypes()
File "/home/olifre/gits/forensics/volatility/volatility/plugins/overlays/linux/linux.py", line 269, in load_vtypes
vtypesvar = dwarf.DWARFParser(dwarfdata).finalize()
File "/home/olifre/gits/forensics/volatility/volatility/dwarf.py", line 72, in __init__
self.feed_line(line)
File "/home/olifre/gits/forensics/volatility/volatility/dwarf.py", line 163, in feed_line
self.process_statement(**parsed) #pylint: disable-msg=W0142
File "/home/olifre/gits/forensics/volatility/volatility/dwarf.py", line 199, in process_statement
self.vtypes[name] = [ int(data['DW_AT_byte_size'], self.base), {} ]
KeyError: 'DW_AT_byte_size
So I'm now running into https://github.com/volatilityfoundation/volatility/issues/638 , right?
@olifre can you git pull volatility 2 and try to run again with that profile? I updated for the dwarf.py issue. Also, be aware, plugins might be really slow to run since your profile is based on the full kernel image and not just what module.c produces. The output will be the same, just know it might take a long time per plugin run. The main goal for now is just to see if you get a process list from Vol2 though.
@atcuno I certainly get further this time! Sadly, it still seems unhappy in dwarf.py:
Traceback (most recent call last):
File "vol.py", line 192, in <module>
main()
File "vol.py", line 183, in main
command.execute()
File "/home/olifre/gits/forensics/volatility/volatility/plugins/linux/common.py", line 67, in execute
commands.Command.execute(self, *args, **kwargs)
File "/home/olifre/gits/forensics/volatility/volatility/commands.py", line 116, in execute
if not self.is_valid_profile(profs[self._config.PROFILE]()):
File "/home/olifre/gits/forensics/volatility/volatility/plugins/overlays/linux/linux.py", line 218, in __init__
obj.Profile.__init__(self, *args, **kwargs)
File "/home/olifre/gits/forensics/volatility/volatility/obj.py", line 862, in __init__
self.reset()
File "/home/olifre/gits/forensics/volatility/volatility/plugins/overlays/linux/linux.py", line 232, in reset
self.load_vtypes()
File "/home/olifre/gits/forensics/volatility/volatility/plugins/overlays/linux/linux.py", line 269, in load_vtypes
vtypesvar = dwarf.DWARFParser(dwarfdata).finalize()
File "/home/olifre/gits/forensics/volatility/volatility/dwarf.py", line 72, in __init__
self.feed_line(line)
File "/home/olifre/gits/forensics/volatility/volatility/dwarf.py", line 163, in feed_line
self.process_statement(**parsed) #pylint: disable-msg=W0142
File "/home/olifre/gits/forensics/volatility/volatility/dwarf.py", line 277, in process_statement
self.vtypes[parent_name][1][name] = [off, memb_tp]
KeyError: '__unnamed_0x12d3e'
Okay, lets move the discussion to https://github.com/volatilityfoundation/volatility/issues/638 for now. We will come back to this ticket once we sort the Vol2 part.
As additional information: I have tried the very same approach (using virsh dump, with same libvirt and qemu versions) to create a memory dump of a CentOS 7, x86_64 virtual machine.
It worked without issues, both with volatility 2 and volatility 3.
So my best guess would be there's something wrong either because the VM imaged here is a 32 Bit system or because it's a Debian kernel.
This issue is stale because it has been open for 200 days with no activity.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This issue was closed because it has been inactive for 60 days since being marked as stale.
This issue is still relevant, I sadly just missed the first stalebot-notification since I get so many stalebot notifications these days over and over again. It would be nice if this still valid issue could be opened again.
Sure, no problem. I don't know if the vol2 part of the problem has been solved yet? It seems like that's still open even though volatility 2 is getting less attention these days. Not sure if there's still something to progress on the vol 3 front? @atcuno any update on this?