Page Fault at entry 0x0 in table page table #222

olifre · 2020-05-28T09:28:33Z

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: 69be215
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

The text was updated successfully, but these errors were encountered:

atcuno · 2020-05-28T15:02:18Z

Can you please paste the full backtrace? That way I can see the lines of code that caused the fault.

olifre · 2020-05-28T15:08:06Z

@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

atcuno · 2020-05-28T15:43:15Z

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.

olifre · 2020-05-28T16:18:05Z

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.PsList
linux.pstree.PsTree
linux.proc.Maps
linux.bash.Bash
linux.lsmod.Lsmod
linux.lsof.Lsof
linux.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.

atcuno · 2020-05-28T16:30:29Z

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.

ikelos · 2020-05-28T16:43:08Z

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.

olifre · 2020-05-28T16:54:10Z

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?).

atcuno · 2020-05-28T16:58:47Z

@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.

atcuno · 2020-05-28T17:15:51Z

@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.

olifre · 2020-05-28T17:38:47Z

@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).

atcuno · 2020-05-28T17:46:11Z

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

olifre · 2020-05-28T18:02:48Z

@atcuno Argh, my bad!

To summarize: When following the instructions you linked (did that before), I hit:
volatilityfoundation/profiles#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-pae
taken 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-pae
taken 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 volatilityfoundation/volatility#638 , right?

atcuno · 2020-05-28T20:01:50Z

@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.

olifre · 2020-05-28T20:07:15Z

@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'

atcuno · 2020-05-28T20:10:29Z

Okay, lets move the discussion to volatilityfoundation/volatility#638 for now. We will come back to this ticket once we sort the Vol2 part.

olifre · 2020-06-03T22:22:38Z

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.

github-actions · 2023-12-23T01:48:28Z

This issue is stale because it has been open for 200 days with no activity.

github-actions · 2024-02-22T01:47:29Z

This issue was closed because it has been inactive for 60 days since being marked as stale.

olifre · 2024-02-22T02:13:45Z

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.

ikelos · 2024-02-22T10:25:10Z

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?

github-actions · 2024-09-10T01:59:39Z

This issue is stale because it has been open for 200 days with no activity.

github-actions · 2024-11-10T02:04:21Z

This issue was closed because it has been inactive for 60 days since being marked as stale.

kesullivan mentioned this issue Jun 1, 2020

Support Flat TranslationLayerRequirements - Old linux images (such as Lynx) symbols differ #215

Closed

olifre mentioned this issue Jun 2, 2020

KeyError: 'DW_AT_byte_size' error on Ubuntu-Linux 4.15.0_48-generic system using Python 2.7.12 volatilityfoundation/volatility#638

Open

ikelos assigned atcuno Jun 3, 2020

gleeda added the linux/mac label Jul 15, 2020

github-actions bot added the stale label Dec 23, 2023

github-actions bot closed this as completed Feb 22, 2024

ikelos reopened this Feb 22, 2024

github-actions bot removed the stale label Feb 23, 2024

github-actions bot added the stale label Sep 10, 2024

github-actions bot closed this as completed Nov 10, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Page Fault at entry 0x0 in table page table #222

Page Fault at entry 0x0 in table page table #222

olifre commented May 28, 2020

atcuno commented May 28, 2020

olifre commented May 28, 2020

atcuno commented May 28, 2020

olifre commented May 28, 2020

atcuno commented May 28, 2020

ikelos commented May 28, 2020

olifre commented May 28, 2020 •

edited

Loading

atcuno commented May 28, 2020

atcuno commented May 28, 2020 •

edited

Loading

olifre commented May 28, 2020

atcuno commented May 28, 2020

olifre commented May 28, 2020

atcuno commented May 28, 2020

olifre commented May 28, 2020

atcuno commented May 28, 2020

olifre commented Jun 3, 2020

github-actions bot commented Dec 23, 2023

github-actions bot commented Feb 22, 2024

olifre commented Feb 22, 2024

ikelos commented Feb 22, 2024

github-actions bot commented Sep 10, 2024

github-actions bot commented Nov 10, 2024

Page Fault at entry 0x0 in table page table #222

Page Fault at entry 0x0 in table page table #222

Comments

olifre commented May 28, 2020

atcuno commented May 28, 2020

olifre commented May 28, 2020

atcuno commented May 28, 2020

olifre commented May 28, 2020

atcuno commented May 28, 2020

ikelos commented May 28, 2020

olifre commented May 28, 2020 • edited Loading

atcuno commented May 28, 2020

atcuno commented May 28, 2020 • edited Loading

olifre commented May 28, 2020

atcuno commented May 28, 2020

olifre commented May 28, 2020

atcuno commented May 28, 2020

olifre commented May 28, 2020

atcuno commented May 28, 2020

olifre commented Jun 3, 2020

github-actions bot commented Dec 23, 2023

github-actions bot commented Feb 22, 2024

olifre commented Feb 22, 2024

ikelos commented Feb 22, 2024

github-actions bot commented Sep 10, 2024

github-actions bot commented Nov 10, 2024

olifre commented May 28, 2020 •

edited

Loading

atcuno commented May 28, 2020 •

edited

Loading