"No suitable address space mapping found" work on my own raw Windows memory dump.

[NielsBuch]

I've tried to figure out the solution but without luck. I've been scrolling through the different issues and while many have had the same error message, it seems like they had problems with their dependencies. I haven't found anything that has worked in my case. Hope you can help.

I've created a raw dump from a Windows 10 x86 machine with 1 gb ram using winpmem.

Edition: Windows 10 Home Version: 2004 OS build: 19041.264

I took the output AFF4 and extracted a raw image:

C:\winpmem.exe -o CleanMem.aff4 C:\winpmem.exe CleanMem.aff4 -e PhysicalMemory -o CleanMem.raw

When running imageinfo, which took a good while to complete, I get:

python vol.py -f Clean/CleanMem.raw imageinfo
Volatility Foundation Volatility Framework 2.6.1
INFO    : volatility.debug    : Determining profile based on KDBG search...
          Suggested Profile(s) : Win10x86_18362, Win10x86_17763 (Instantiated with no profile)
                     AS Layer1 : FileAddressSpace (/home/niels/Desktop/volatility/Clean/CleanMem.raw)
                      PAE type : No PAE

Now to go a bit further I used the kdbgscan plugin. It says:

python vol.py -f Clean/CleanMem.raw kdbgscan
Volatility Foundation Volatility Framework 2.6.1
**************************************************
Instantiating KDBG using: /home/niels/Desktop/volatility/Clean/CleanMem.raw WinXPSP2x86 (5.1.0 32bit)
Offset (P)                    : 0x32b6830
KDBG owner tag check          : True
Profile suggestion (KDBGHeader): Win10x86_17763
Version64                     : 0x32b8f60 (Major: 15, Minor: 19041)
PsActiveProcessHead           : 0x822d6e40
PsLoadedModuleList            : 0x822de918
KernelBase                    : 0x82013000

**************************************************
Instantiating KDBG using: /home/niels/Desktop/volatility/Clean/CleanMem.raw WinXPSP2x86 (5.1.0 32bit)
Offset (P)                    : 0x32b6830
KDBG owner tag check          : True
Profile suggestion (KDBGHeader): Win10x86_18362
Version64                     : 0x32b8f60 (Major: 15, Minor: 19041)
PsActiveProcessHead           : 0x822d6e40
PsLoadedModuleList            : 0x822de918
KernelBase                    : 0x82013000

As far as I can see that seems fairly normal. Now that I have some ideas about the profiles I run the pslist plugin.

python vol.py -f Clean/CleanMem.raw --profile=Win10x86_18362 --kdbg=0x32b6830 pslist
Volatility Foundation Volatility Framework 2.6.1
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
 QemuCoreDumpElf: No base Address Space
 VMWareAddressSpace: 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: No xpress signature found
 WindowsCrashDumpSpace64BitMap: Header signature invalid
 VMWareMetaAddressSpace: VMware metadata file is not available
 WindowsCrashDumpSpace64: Header signature invalid
 HPAKAddressSpace: Invalid magic found
 VirtualBoxCoreDumpElf64: ELF Header signature invalid
 QemuCoreDumpElf: ELF Header signature invalid
 VMWareAddressSpace: Invalid VMware signature: 0x0
 WindowsCrashDumpSpace32: Header signature invalid
 SkipDuplicatesAMD64PagedMemory: Incompatible profile Win10x86_18362 selected
 WindowsAMD64PagedMemory: Incompatible profile Win10x86_18362 selected
 LinuxAMD64PagedMemory: Incompatible profile Win10x86_18362 selected
 AMD64PagedMemory: Incompatible profile Win10x86_18362 selected
 IA32PagedMemoryPae: No valid DTB found
 IA32PagedMemory: No valid DTB found
 OSXPmemELF: ELF Header signature invalid
 FileAddressSpace: Must be first Address Space
 ArmAddressSpace: No valid DTB found

Is this a problem with my dumps or am I just being a numpty and haven't done my research on volatility well enough? The memory dumps I've created can be found here (Both the aff4 and the raw format): https://drive.google.com/drive/folders/1NgX5Izpln1k7mD2-k2q62khBJ0gQCoOD?usp=sharing

N.B. I've cloned reinstalled volatility with the newest version of git to get the results seen above. It is the same result that I've always received. Should have most of the important dependencies installed such as distorm3.

Hope I've supplied with enough and have formated the information well enough. Regards, Niels

[nganhkhoa]

This should not be working. Volatility is using hard coded values and new versions or odd versions of Windows will not be working. The build number (19041.264) is obviously the insider build that Volatility doesn't have support for. I suggest you create the relays for that version of Windows. Then put the new relay inside plugins/overlays/windows, rename to Win10x86_19041.264 and try running with --profile=Win10x86_19041.264 it may work.

The new profile adding example is here. I remember there was a python script to do these kind of things by parsing the PDB file, but I can't find it after a few searches.

[nganhkhoa]

It seems this is the one https://volatility3.readthedocs.io/en/latest/volatility.framework.symbols.windows.pdbconv.html

The script: https://github.com/volatilityfoundation/volatility3/blob/master/volatility/framework/symbols/windows/pdbconv.py

But I haven't look into these. We should wait or you can look into these and generate the profile. The core volatility team is rewriting vol3, so it may take a while.

[atcuno]

@NielsBuch

Running Windows 10 with 1GB of RAM is going to get you bad results in most cases. Is this a VM? If so, please increase the RAM to at least 4GB, but 8GB would be ideal. Also, winpmem is an unstable and abandoned acquisition tool. If you are using a VM, then just suspend it and perform analysis on the suspend file (paired .vmss and .vmem for workstation and fusion).

Let me know if you have any issues after increasing RAM and also using a stable acquisition method.

[atcuno]

@nganhkhoa What you said is not true. Volatility supports that version of Windows.

[NielsBuch]

Thank you all for giving your input. I'm working at the moment (have a smalle break to write this) but will look further into your responses when I get home. Hopefully you'll have the time for a few more questions if I've misunderstood you.

@atcuno Yes, it is a VM virtualBox. I tried the smallest amount of RAM as I wanted to test an intrusion but didn't want to sift through a large amount of memory (and I don't have too much room on my laptop to stash a large dump of memory).

I've tried to run the debug mode with VirtualBox. I got the error message:

VBoxManage debugvm "Windows10" dumpvmcore --filename=Win10mem.raw
VBoxManage.exe: error: DBGFR3CoreWrite failed with VERR_ACCESS_DENIED
VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component MachineDebuggerWrap, interface IMachineDebugger, callee IUnknown
VBoxManage.exe: error: Context: "DumpGuestCore(bstrFilename.raw(), bstrCompression.raw())" at line 327 of file VBoxManageDebugVM.cpp

Are there any guides to your memory acquisition? I haven't seen many posts using that method. I'd really like to see that, as I've worked with the stuxnet.vmem before. Most guides reference products that are expensive or products where you have to register to even test out the product (dumpit).

[NielsBuch]

@atcuno Thanks for the help. Dropped the use of VirtualBox and changed to VMware player. That creates a .vmem when you suspend a VM. It worked wonders!

[oold]

@NielsBuch I realize that you've already found a workaround for your issue, but I just want to point out that VERR_ACCESS_DENIED means that you don't have permission to perform that action. You might need admin privileges on Windows to do that.