Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

No suitable address space mapping found #381

Closed
harpreetsc1992 opened this issue Mar 10, 2017 · 7 comments
Closed

No suitable address space mapping found #381

harpreetsc1992 opened this issue Mar 10, 2017 · 7 comments
Labels
linux/mac

Comments

@harpreetsc1992
Copy link

harpreetsc1992 commented Mar 10, 2017 •
edited
Loading

Hey
I am working on trying to use LiME to create memory dumps to be read by Volatility. I am currently using LiME 1.7.7 and Volatility 2.6.
I know that volatility is set up properly, because I can run it successfully for memory images and profiles obtained from https://www.memoryanalysis.net/amf.

I create the memory dump using:

sudo insmod lime.ko “path=<pathname>/mem_dump.lime format=lime”

on the system whose memory dump I wish to analyze.

I create the volatility profile as a zip file consisting of my kernel’s System.map file and module.dwarf in volatility/tools/linux, and place it in volatility/plugins/overlays/linux

I am getting the following error while trying to make volatility read from the memory dump using the command

sudo python vol.py -f ~/mem_dump.lime --profile="LinuxLinuxnn6x64" linux_psaux

Volatility Foundation Volatility Framework 2.4
Pid Uid Gid Arguments
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
AMD64PagedMemory: No base Address Space
IA32PagedMemoryPae: No base Address Space
IA32PagedMemory: No base Address Space
PyVmiAddressSpace: Location doesn't start with vmi://
OSXPmemELF: No base Address Space
MachOAddressSpace: MachO Header signature invalid
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: 0x0
QemuCoreDumpElf: ELF Header signature invalid
WindowsCrashDumpSpace32: Header signature invalid
AMD64PagedMemory: Failed valid Address Space check
IA32PagedMemoryPae: Incompatible profile LinuxLinuxnn6x64 selected
IA32PagedMemory: Incompatible profile LinuxLinuxnn6x64 selected
PyVmiAddressSpace: Must be first Address Space
OSXPmemELF: ELF Header signature invalid
FileAddressSpace: Must be first Address Space
ArmAddressSpace: Failed valid Address Space check

My uname -a output is:

Linux nimbnode6 3.16.0-70-generic #90~14.04.1-Ubuntu SMP Wed Apr 6 22:56:34 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

I have tried the same with LiME v1.6 and Volatility 2.4, but that doesn’t work either.
With LiME v1.4, I get an error similar to the issue 504ensicsLabs/LiME#7.

I know that my problem is similar to the one raised in issue #359, but since no one has replied to it yet, I am restating it here.
@harpreetsc1992 harpreetsc1992 changed the title Lime: Need base Lime: Need base error Mar 10, 2017
@harpreetsc1992 harpreetsc1992 changed the title Lime: Need base error LimeAddressSpace: lime: need base Mar 10, 2017
@harpreetsc1992 harpreetsc1992 changed the title LimeAddressSpace: lime: need base No suitable address space mapping found Mar 10, 2017
@kd8bny
Copy link

kd8bny commented Mar 15, 2017

@harpreetsc1992 What is the output of your dwarf? I dont believe its the same as #359 since you are running a 3.16 kernel.

@harpreetsc1992
Copy link
Author

@kd8bny Output of module.dwarf? How can I get that? Do you mean a cat output of the file?

Is there anyone who knows about which versions of volatility + linux kernel version + the Debian system name actually work, and have tried and tested some commands on it? I have tried various combinations for various linux distros (supported by a certain volatility version), but they seem to pop up with the same errors. Though, it is possible I might have missed out on some.
Also, it seems that volatility's "vmi:" option is compatible with Windows HVMs when running with Xen. Trying volatility with "vmi:" on an Ubuntu HVM gives partial outputs with a lot of "..." in the output. I had to switch to previous versions of volatility for these, namely 2.3 and 2.4. It doesn't work for OpenSUSE HVM virtual machines.
But again, trying to run the volatility commands using a LiME image for Debian based systems doesn't seem to work at all for me, irrespective of the system I run it on.

P.S. Sorry for the late response, was caught up somewhere else.

@pagabuc
Copy link
Contributor

pagabuc commented Apr 26, 2017

@harpreetsc1992 not sure if it's related but try to pass timeout=0 to lime.

@kd8bny
Copy link

kd8bny commented Apr 26, 2017

@harpreetsc1992 Sorry for the lack of response I was out for a while. By output of dwarf I meant run cat of the .dwarf file you get from creating a volatility profile
How to. If it is abnormally short and includes an error message I believe it is related to the aforementioned issue.

Hope this helps!

@ghost
Copy link

ghost commented May 1, 2017

Hi,
I have the same error:

$ python vol.py -f ~/lime.dump --profile=LinuxGoldfish-3_18x86 limeinfo  
Volatility Foundation Volatility Framework 2.6
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
 QemuCoreDumpElf: No base Address Space
 VMWareAddressSpace: No base Address Space
 WindowsCrashDumpSpace32: No base Address Space
 Win10AMD64PagedMemory: 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
 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
 QemuCoreDumpElf: ELF Header signature invalid
 VMWareAddressSpace: Invalid VMware signature: 0x0
 WindowsCrashDumpSpace32: Header signature invalid
 Win10AMD64PagedMemory: Incompatible profile LinuxGoldfish-3_18x86 selected
 WindowsAMD64PagedMemory: Incompatible profile LinuxGoldfish-3_18x86 selected
 LinuxAMD64PagedMemory: Incompatible profile LinuxGoldfish-3_18x86 selected
 AMD64PagedMemory: Incompatible profile LinuxGoldfish-3_18x86 selected
 IA32PagedMemoryPae: Failed valid Address Space check
 IA32PagedMemory: Failed valid Address Space check
 OSXPmemELF: ELF Header signature invalid
 FileAddressSpace: Must be first Address Space
 ArmAddressSpace: Failed valid Address Space check/

$  head module.dwarf

.debug_info

<0><0x0+0xb><DW_TAG_compile_unit> DW_AT_producer<GNU C 4.9 20140827 (prerelease) -mssse3 -fno-short-enums -mbionic -m32 -msoft-float -mregparm=3 -mpreferred-stack-boundary=2 -march=i686 -mtune=core2 -mtune=generic -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -g -Os -std=gnu90 -fno-strict-aliasing -fno-common -freg-struct-return -ffreestanding -fno-asynchronous-unwind-tables -fno-delete-null-pointer-checks -fno-PIE -fno-stack-protector -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-var-tracking-assignments -fno-strict-overflow -fconserve-stack --param allow-store-data-races=0> DW_AT_language<DW_LANG_C89> DW_AT_name</opt/volatility/volatility/tools/linux/module.c> DW_AT_comp_dir</home/at/andoid-build/goldfish3> DW_AT_stmt_list<0x00000000>
<1><0x1d><DW_TAG_typedef> DW_AT_name<__s8> DW_AT_decl_file<0x00000001 /home/at/andoid-build/goldfish3/include/uapi/asm-generic/int-ll64.h> DW_AT_decl_line<0x00000013> DW_AT_type<<0x00000028>>
<1><0x28><DW_TAG_base_type> DW_AT_byte_size<0x00000001> DW_AT_encoding<DW_ATE_signed_char> DW_AT_name<signed char>
<1><0x2f><DW_TAG_typedef> DW_AT_name<__u8> DW_AT_decl_file<0x00000001 /home/at/andoid-build/goldfish3/include/uapi/asm-generic/int-ll64.h> DW_AT_decl_line<0x00000014> DW_AT_type<<0x0000003a>>
<1><0x3a><DW_TAG_base_type> DW_AT_byte_size<0x00000001> DW_AT_encoding<DW_ATE_unsigned_char> DW_AT_name<unsigned char>
<1><0x41><DW_TAG_typedef> DW_AT_name<__s16> DW_AT_decl_file<0x00000001 /home/at/andoid-build/goldfish3/include/uapi/asm-generic/int-ll64.h> DW_AT_decl_line<0x00000016> DW_AT_type<<0x0000004c>>
<1><0x4c><DW_TAG_base_type> DW_AT_byte_size<0x00000002> DW_AT_encoding<DW_ATE_signed> DW_AT_name<short int>

@atcuno
Copy link
Contributor

atcuno commented May 1, 2017 via email

@ghost
Copy link

ghost commented May 1, 2017

From the emulator.

@atcuno atcuno closed this as completed Nov 29, 2019
@S1ddh1 S1ddh1 mentioned this issue May 19, 2020
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
linux/mac
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@gleeda @atcuno @kd8bny @pagabuc @harpreetsc1992