search

volatilityfoundation / volatility

An advanced memory forensics framework
http://volatilityfoundation.org/
GNU General Public License v2.0
7.31k stars 1.28k forks source link

Vol 2.4 not parsing raw linux memory dump created with LiMe #174

Closed swappage closed 9 years ago

swappage commented 9 years ago

i don't think i'm doing anything wrong but appearently when i try to process a linux memory dump made with LiMe in raw format it doesn't get recognized.

RAM dump made with LiMe on the same exact machine in LiMe format gets parsed correctly using the same profile.

here is what i get in debug mode:

$ python vol.py --debug -f ../memory.raw --profile=LinuxCentOS66x64 linux_bash
Volatility Foundation Volatility Framework 2.4
DEBUG   : volatility.plugins.overlays.linux.linux: CentOS66: Found dwarf file boot/System.map-2.6.32-504.1.3.el6.x86_64 with 520 symbols
DEBUG   : volatility.plugins.overlays.linux.linux: CentOS66: Found system file boot/System.map-2.6.32-504.1.3.el6.x86_64 with 1 symbols
DEBUG   : volatility.obj      : Applying modification from BashHashTypes
DEBUG   : volatility.obj      : Applying modification from BashTypes
DEBUG   : volatility.obj      : Applying modification from BasicObjectClasses
DEBUG   : volatility.obj      : Applying modification from ELF32Modification
DEBUG   : volatility.obj      : Applying modification from ELF64Modification
DEBUG   : volatility.obj      : Applying modification from ELFModification
DEBUG   : volatility.obj      : Applying modification from HPAKVTypes
DEBUG   : volatility.obj      : Applying modification from LimeTypes
DEBUG   : volatility.obj      : Applying modification from LinuxTruecryptModification
DEBUG   : volatility.obj      : Applying modification from MachoModification
DEBUG   : volatility.obj      : Applying modification from MachoTypes
DEBUG   : volatility.obj      : Applying modification from MbrObjectTypes
DEBUG   : volatility.obj      : Applying modification from VMwareVTypesModification
DEBUG   : volatility.obj      : Applying modification from VirtualBoxModification
DEBUG   : volatility.obj      : Applying modification from LinuxIntelOverlay
DEBUG   : volatility.obj      : Applying modification from LinuxKmemCacheOverlay
DEBUG   : volatility.obj      : Applying modification from LinuxMountOverlay
DEBUG   : volatility.obj      : Applying modification from LinuxObjectClasses
DEBUG   : volatility.obj      : Applying modification from LinuxOverlay
DEBUG   : volatility.plugins.overlays.linux.linux: CentOS66: Found dwarf file boot/System.map-2.6.32-504.1.3.el6.x86_64 with 520 symbols
DEBUG   : volatility.plugins.overlays.linux.linux: CentOS66: Found system file boot/System.map-2.6.32-504.1.3.el6.x86_64 with 1 symbols
DEBUG   : volatility.obj      : Applying modification from BashHashTypes
DEBUG   : volatility.obj      : Applying modification from BashTypes
DEBUG   : volatility.obj      : Applying modification from BasicObjectClasses
DEBUG   : volatility.obj      : Applying modification from ELF32Modification
DEBUG   : volatility.obj      : Applying modification from ELF64Modification
DEBUG   : volatility.obj      : Applying modification from ELFModification
DEBUG   : volatility.obj      : Applying modification from HPAKVTypes
DEBUG   : volatility.obj      : Applying modification from LimeTypes
DEBUG   : volatility.obj      : Applying modification from LinuxTruecryptModification
DEBUG   : volatility.obj      : Applying modification from MachoModification
DEBUG   : volatility.obj      : Applying modification from MachoTypes
DEBUG   : volatility.obj      : Applying modification from MbrObjectTypes
DEBUG   : volatility.obj      : Applying modification from VMwareVTypesModification
DEBUG   : volatility.obj      : Applying modification from VirtualBoxModification
DEBUG   : volatility.obj      : Applying modification from LinuxIntelOverlay
DEBUG   : volatility.obj      : Applying modification from LinuxKmemCacheOverlay
DEBUG   : volatility.obj      : Applying modification from LinuxMountOverlay
DEBUG   : volatility.obj      : Applying modification from LinuxObjectClasses
DEBUG   : volatility.obj      : Applying modification from LinuxOverlay
Pid      Name                 Command Time                   Command
-------- -------------------- ------------------------------ -------
DEBUG   : volatility.utils    : Voting round
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.macho.MachOAddressSpace'> 
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.lime.LimeAddressSpace'> 
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.hibernate.WindowsHiberFileSpace32'> 
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.crashbmp.WindowsCrashDumpSpace64BitMap'> 
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace64'> 
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.hpak.HPAKAddressSpace'> 
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.vmem.VMWareMetaAddressSpace'> 
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.elfcoredump.VirtualBoxCoreDumpElf64'> 
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.vmware.VMWareAddressSpace'> 
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.elfcoredump.QemuCoreDumpElf'> 
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace32'> 
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.amd64.AMD64PagedMemory'> 
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.intel.IA32PagedMemoryPae'> 
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.intel.IA32PagedMemory'> 
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.osxpmemelf.OSXPmemELF'> 
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.standard.FileAddressSpace'> 
DEBUG   : volatility.utils    : Succeeded instantiating <volatility.plugins.addrspaces.standard.FileAddressSpace object at 0xb380ecc>
DEBUG   : volatility.utils    : Voting round
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.macho.MachOAddressSpace'> 
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.lime.LimeAddressSpace'> 
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.hibernate.WindowsHiberFileSpace32'> 
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.crashbmp.WindowsCrashDumpSpace64BitMap'> 
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace64'> 
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.hpak.HPAKAddressSpace'> 
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.vmem.VMWareMetaAddressSpace'> 
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.elfcoredump.VirtualBoxCoreDumpElf64'> 
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.vmware.VMWareAddressSpace'> 
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.elfcoredump.QemuCoreDumpElf'> 
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace32'> 
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.amd64.AMD64PagedMemory'> 
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.intel.IA32PagedMemoryPae'> 
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.intel.IA32PagedMemory'> 
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.osxpmemelf.OSXPmemELF'> 
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.standard.FileAddressSpace'> 
DEBUG   : volatility.utils    : Trying <class 'volatility.plugins.addrspaces.arm.ArmAddressSpace'> 
DEBUG   : volatility.plugins.addrspaces.arm: get_pte: invalid pde_value 81239dc0
DEBUG   : volatility.plugins.addrspaces.arm: get_pte: invalid pde_value 81239dc0
DEBUG   : volatility.plugins.addrspaces.arm: get_pte: invalid pde_value 81239dc0
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
 WindowsCrashDumpSpace64: No base Address Space
 HPAKAddressSpace: No base Address Space
 VMWareMetaAddressSpace: No base Address Space
 VirtualBoxCoreDumpElf64: No base Address Space
 VMWareAddressSpace: No base Address Space
 QemuCoreDumpElf: No base Address Space
 WindowsCrashDumpSpace32: 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
 WindowsCrashDumpSpace64: Header signature invalid
 HPAKAddressSpace: Invalid magic found
 VMWareMetaAddressSpace: VMware metadata file is not available
 VirtualBoxCoreDumpElf64: ELF Header signature invalid
 VMWareAddressSpace: Invalid VMware signature: 0x0
 QemuCoreDumpElf: ELF Header signature invalid
 WindowsCrashDumpSpace32: Header signature invalid
 AMD64PagedMemory: Failed valid Address Space check
 IA32PagedMemoryPae: Incompatible profile LinuxCentOS66x64 selected
 IA32PagedMemory: Incompatible profile LinuxCentOS66x64 selected
 OSXPmemELF: ELF Header signature invalid
 FileAddressSpace: Must be first Address Space
 ArmAddressSpace: Failed valid Address Space check

and here is what happens when i run the same command against the LiMe format image

$ python vol.py -f ../memory.lime --profile=LinuxCentOS66x64 linux_bash
Volatility Foundation Volatility Framework 2.4
Pid      Name                 Command Time                   Command
-------- -------------------- ------------------------------ -------
    1113 bash                 2015-02-04 23:54:49 UTC+0000   cd network-scripts/
    1113 bash                 2015-02-04 23:54:49 UTC+0000   ./configure
    1113 bash                 2015-02-04 23:54:49 UTC+0000   ls -la
    1113 bash                 2015-02-04 23:54:49 UTC+0000   ls -la
    1113 bash                 2015-02-04 23:54:49 UTC+0000   less README.md 
    1113 bash                 2015-02-04 23:54:49 UTC+0000   cd src/
    1113 bash                 2015-02-04 23:54:49 UTC+0000   ls -la
    1113 bash                 2015-02-04 23:54:49 UTC+0000   make
...

I wonder if i'm doing anything wrong, if this is a bug.

I'm looking for a place to upload the samples and the profile if anyone is willing to reproduce the scenario for testing and diagnostics.

atcuno commented 9 years ago

Could you please run the 'limeinfo' against the lime formatted one and paste the output?

Thanks, Andrew (@attrc)

On 02/05/2015 04:13 AM, swappage wrote:

i don't think i'm doing anything wrong but appearently when i try to process a linux memory dump made with LiMe in raw format it doesn't get recognized.

RAM dump made with LiMe on the same exact machine in LiMe format gets parsed correctly using the same profile.

here is what i get in debug mode:

|$ python vol.py --debug -f ../memory.raw --profile=LinuxCentOS66x64 linux_bash Volatility Foundation Volatility Framework 2.4 DEBUG : volatility.plugins.overlays.linux.linux: CentOS66: Found dwarf file boot/System.map-2.6.32-504.1.3.el6.x86_64 with 520 symbols DEBUG : volatility.plugins.overlays.linux.linux: CentOS66: Found system file boot/System.map-2.6.32-504.1.3.el6.x86_64 with 1 symbols DEBUG : volatility.obj : Applying modification from BashHashTypes DEBUG : volatility.obj : Applying modification from BashTypes DEBUG : volatility.obj : Applying modification from BasicObjectClasses DEBUG : volatility.obj : Applying modification from ELF32Modification DEBUG : volatility.obj : Applying modification from ELF64Modification DEBUG : volatility.obj : Applying modification from ELFModification DEBUG : volatility.obj : Applying modification from HPAKVTypes DEBUG : volatility.obj : Applying modification from LimeTypes DEBUG : volatility.obj : Applying modification from LinuxTruecryptModification DEBUG : volatility.obj : Applying modification from MachoModification DEBUG : volatility.obj : Applying modification from MachoTypes DEBUG : volatility.obj : Applying modification from MbrObjectTypes DEBUG : volatility.obj : Applying modification from VMwareVTypesModification DEBUG : volatility.obj : Applying modification from VirtualBoxModification DEBUG : volatility.obj : Applying modification from LinuxIntelOverlay DEBUG : volatility.obj : Applying modification from LinuxKmemCacheOverlay DEBUG : volatility.obj : Applying modification from LinuxMountOverlay DEBUG : volatility.obj : Applying modification from LinuxObjectClasses DEBUG : volatility.obj : Applying modification from LinuxOverlay DEBUG : volatility.plugins.overlays.linux.linux: CentOS66: Found dwarf file boot/System.map-2.6.32-504.1.3.el6.x86_64 with 520 symbols DEBUG : volatility.plugins.overlays.linux.linux: CentOS66: Found system file boot/System.map-2.6.32-504.1.3.el6.x86_64 with 1 symbols DEBUG : volatility.obj : Applying modification from BashHashTypes DEBUG : volatility.obj : Applying modification from BashTypes DEBUG : volatility.obj : Applying modification from BasicObjectClasses DEBUG : volatility.obj : Applying modification from ELF32Modification DEBUG : volatility.obj : Applying modification from ELF64Modification DEBUG : volatility.obj : Applying modification from ELFModification DEBUG : volatility.obj : Applying modification from HPAKVTypes DEBUG : volatility.obj : Applying modification from LimeTypes DEBUG : volatility.obj : Applying modification from LinuxTruecryptModification DEBUG : volatility.obj : Applying modification from MachoModification DEBUG : volatility.obj : Applying modification from MachoTypes DEBUG : volatility.obj : Applying modification from MbrObjectTypes DEBUG : volatility.obj : Applying modification from VMwareVTypesModification DEBUG : volatility.obj : Applying modification from VirtualBoxModification DEBUG : volatility.obj : Applying modification from LinuxIntelOverlay DEBUG : volatility.obj : Applying modification from LinuxKmemCacheOverlay DEBUG : volatility.obj : Applying modification from LinuxMountOverlay DEBUG : volatility.obj : Applying modification from LinuxObjectClasses DEBUG : volatility.obj : Applying modification from LinuxOverlay Pid Name Command Time Command

DEBUG : volatility.utils : Voting round DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.macho.MachOAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.lime.LimeAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.hibernate.WindowsHiberFileSpace32'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crashbmp.WindowsCrashDumpSpace64BitMap'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace64'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.hpak.HPAKAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.vmem.VMWareMetaAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.elfcoredump.VirtualBoxCoreDumpElf64'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.vmware.VMWareAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.elfcoredump.QemuCoreDumpElf'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace32'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.amd64.AMD64PagedMemory'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.intel.IA32PagedMemoryPae'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.intel.IA32PagedMemory'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.osxpmemelf.OSXPmemELF'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.standard.FileAddressSpace'> DEBUG : volatility.utils : Succeeded instantiating <volatility.plugins.addrspaces.standard.FileAddressSpace object at 0xb380ecc> DEBUG : volatility.utils : Voting round DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.macho.MachOAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.lime.LimeAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.hibernate.WindowsHiberFileSpace32'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crashbmp.WindowsCrashDumpSpace64BitMap'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace64'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.hpak.HPAKAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.vmem.VMWareMetaAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.elfcoredump.VirtualBoxCoreDumpElf64'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.vmware.VMWareAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.elfcoredump.QemuCoreDumpElf'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace32'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.amd64.AMD64PagedMemory'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.intel.IA32PagedMemoryPae'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.intel.IA32PagedMemory'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.osxpmemelf.OSXPmemELF'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.standard.FileAddressSpace'> DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.arm.ArmAddressSpace'> DEBUG : volatility.plugins.addrspaces.arm: get_pte: invalid pde_value 81239dc0 DEBUG : volatility.plugins.addrspaces.arm: get_pte: invalid pde_value 81239dc0 DEBUG : volatility.plugins.addrspaces.arm: get_pte: invalid pde_value 81239dc0 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 WindowsCrashDumpSpace64: No base Address Space HPAKAddressSpace: No base Address Space VMWareMetaAddressSpace: No base Address Space VirtualBoxCoreDumpElf64: No base Address Space VMWareAddressSpace: No base Address Space QemuCoreDumpElf: No base Address Space WindowsCrashDumpSpace32: 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 WindowsCrashDumpSpace64: Header signature invalid HPAKAddressSpace: Invalid magic found VMWareMetaAddressSpace: VMware metadata file is not available VirtualBoxCoreDumpElf64: ELF Header signature invalid VMWareAddressSpace: Invalid VMware signature: 0x0 QemuCoreDumpElf: ELF Header signature invalid WindowsCrashDumpSpace32: Header signature invalid AMD64PagedMemory: Failed valid Address Space check IA32PagedMemoryPae: Incompatible profile LinuxCentOS66x64 selected IA32PagedMemory: Incompatible profile LinuxCentOS66x64 selected OSXPmemELF: ELF Header signature invalid FileAddressSpace: Must be first Address Space ArmAddressSpace: Failed valid Address Space check

and here is what happens when i run the same command against the LiMe format image

|$ python vol.py -f ../memory.lime --profile=LinuxCentOS66x64 linux_bash Volatility Foundation Volatility Framework 2.4 Pid Name Command Time Command

1113 bash                 2015-02-04 23:54:49 UTC+0000   cd network-scripts/
1113 bash                 2015-02-04 23:54:49 UTC+0000   ./configure
1113 bash                 2015-02-04 23:54:49 UTC+0000   ls -la
1113 bash                 2015-02-04 23:54:49 UTC+0000   ls -la
1113 bash                 2015-02-04 23:54:49 UTC+0000   less README.md 
1113 bash                 2015-02-04 23:54:49 UTC+0000   cd src/
1113 bash                 2015-02-04 23:54:49 UTC+0000   ls -la
1113 bash                 2015-02-04 23:54:49 UTC+0000   make

... |

I wonder if i'm doing anything wrong, if this is a bug.

I'm looking for a place to upload the samples and the profile if anyone is willing to reproduce the scenario for testing and diagnostics.

— Reply to this email directly or view it on GitHub https://github.com/volatilityfoundation/volatility/issues/174.

swappage commented 9 years ago

of course.

here is the output of limeinfo on the lime formatted image

$ python vol.py -f ../memory.lime --profile=LinuxCentOS66x64 limeinfo
Volatility Foundation Volatility Framework 2.4
Memory Start       Memory End         Size              
------------------ ------------------ ------------------
0x0000000000001000 0x000000000009fbff 0x000000000009ec00
0x0000000000100000 0x000000001ffeffff 0x000000001fef0000
atcuno commented 9 years ago

I just saw the IRC convo. Could you patch the dtb check as described in:

http://lists.volatilesystems.com/pipermail/vol-users/2013-February/000743.html

and see if it works?

Thanks, Andrew (@attrc)

On 02/05/2015 10:38 AM, swappage wrote:

of course.

here is the output of limeinfo on the lime formatted image

|$ python vol.py -f ../memory.lime --profile=LinuxCentOS66x64 limeinfo Volatility Foundation Volatility Framework 2.4 Memory Start Memory End Size

0x0000000000001000 0x000000000009fbff 0x000000000009ec00 0x0000000000100000 0x000000001ffeffff 0x000000001fef0000

— Reply to this email directly or view it on GitHub https://github.com/volatilityfoundation/volatility/issues/174#issuecomment-73078625.

swappage commented 9 years ago

Hi, i'm following the document you linked me, but the volatility files layout seems pretty different from how it's explained over there, so i'm having a bit of issues in following the steps, and i get lost.

here is what i get when i grep the system-map for the get for init_level4_pgt 

]# grep init_level4_pgt /boot/System.map-2.6.32-504.1.3.el6.x86_64
ffffffff818364e0 r __ksymtab_init_level4_pgt
ffffffff8184cb98 r __kcrctab_init_level4_pgt
ffffffff81858113 r __kstrtab_init_level4_pgt
ffffffff81a85000 D init_level4_pgt

then later on the document talks about a module they loaded to detect the actual offset for the dtb, but i don't know which module is being used

and then about the patching

the files appears to be way different, there is no linux64.py in the overlays directory, and also if i grep for this particular line of code

yield profile.get_symbol("init_level4_pgt")

i cant find anything. the same function is called but with a different argument in linux.py at line 1692

1678 class VolatilityDTB(obj.VolatilityMagic):
1679     """A scanner for DTB values."""
1680
1681     def generate_suggestions(self):
1682         """Tries to locate the DTB."""
1683         profile = self.obj_vm.profile
1684
1685         if profile.metadata.get('memory_model', '32bit') == "32bit":
1686             sym   = "swapper_pg_dir"
1687             shift = 0xc0000000
1688         else:
1689             sym   = "init_level4_pgt"
1690             shift = 0xffffffff80000000
1691
1692         yield profile.get_symbol(sym) - shift
swappage commented 9 years ago

anyway, i've uploaded

on my gdrive account (i don't have any other place to store them), if you think it can be helpful, i can give you the links for downloading, but i need a contact of yours.

gleeda commented 9 years ago

Any update on this? @atcuno 's contact details can be found here if he hasn't given them to you yet:

http://dfir.org/?q=contact

swappage commented 9 years ago

@gleeda I've tried to look into previous issues to check if i could find a workaround but yet i can't seem to get the dump to work.. sorry i've sent a copy of the dumps and the profiles to Andrew.

gleeda commented 9 years ago

Any update on this ? cc @atcuno

joywsx commented 9 years ago

Hi @swappage ,

Are you using centos6.6? I've tried using .lime format but the result shows no suitable address space mapping found. Please help!

Thanks

swappage commented 9 years ago

Il 10/08/2015 21:09, joywsx ha scritto:

Hi @swappage https://github.com/swappage ,

Are you using centos6.6? I've tried using .lime format but the result shows no suitable address space mapping found. Please help!

Thanks

Hi, no, my problem wasn't distribution specific, i was dealing with a debian memory image.

MaelC commented 9 years ago

Hi,

I've just encountered a similar problem with CentOS 6.4. The LiME RAW format fails, but the LiME and Padded formats work fine.

Thanks, -Daniel

atcuno commented 9 years ago

Ok, I am not sure why I missed this before. The RAW format is not supported and actually can't be. The raw format just glues all the regions together and does not pad them (like the padding format does) and doesn't produce any metadata that maps the offsets to where they were in physical memory (the lime format).

Because of this I will close the issue. Please use the lime format (or padding, but lime is better) and do not produce raw memory dumps. No memory forensics tools will be able to analyze them unless the system has contiguous RAM from physical offset 0, which is very rare.