I built LiME from the tarball on the project site (not latest svn) and was able to dump memory successfully (type=lime). After many trials and tribulations I was able to get the Volatility profile built for CentOS 5.3x64 (had to remove pmem from the Makefile). I put the profile in the correct directory, and vol.py --info lists it as expected, however when I try to use the profile with the memory image I get an error.
chort@hydra:~/code/profiles-volatility/CentOS_5.3_x64$ vol.py --profile=LinuxCentOS_5_3x64 -f /fun/ir/geriatrix.lime linux_lsmod
Volatile Systems Volatility Framework 2.3_alpha
WARNING : volatility.obj : Overlay structure cpuinfo_x86 not present in vtypes
No suitable address space mapping found
Tried to open image as:
MachOAddressSpace: mac: need base
LimeAddressSpace: lime: need base
WindowsHiberFileSpace32: No base Address Space
WindowsCrashDumpSpace64: No base Address Space
HPAKAddressSpace: No base Address Space
VirtualBoxCoreDumpElf64: No base Address Space
VMWareSnapshotFile: No base Address Space
WindowsCrashDumpSpace32: No base Address Space
JKIA32PagedMemoryPae: No base Address Space
AMD64PagedMemory: No base Address Space
JKIA32PagedMemory: No base Address Space
IA32PagedMemoryPae: Module disabled
IA32PagedMemory: Module disabled
MachOAddressSpace: MachO Header signature invalid
MachOAddressSpace: MachO Header signature invalid
LimeAddressSpace: Invalid Lime header signature
WindowsHiberFileSpace32: PO_MEMORY_IMAGE is not available in profile
WindowsCrashDumpSpace64: Header signature invalid
HPAKAddressSpace: Invalid magic found
VirtualBoxCoreDumpElf64: ELF64 Header signature invalid
VMWareSnapshotFile: Invalid VMware signature: 0xf000ff53
WindowsCrashDumpSpace32: Header signature invalid
JKIA32PagedMemoryPae: Incompatible profile LinuxCentOS_5_3x64 selected
AMD64PagedMemory: Failed valid Address Space check
JKIA32PagedMemory: Incompatible profile LinuxCentOS_5_3x64 selected
IA32PagedMemoryPae: Module disabled
IA32PagedMemory: Module disabled
FileAddressSpace: Must be first Address Space
ArmAddressSpace: Incompatible profile LinuxCentOS_5_3x64 selected
On a hunch I checked the directory I built the profile in (copied headers & source from the target system):
chort@hydra:~/code/profiles-volatility/CentOS_5.3_x64$ grep cpuinfo *
System.map-2.6.18-128.el5:ffffffff8006f328 t show_cpuinfo
System.map-2.6.18-128.el5:ffffffff80103251 t cpuinfo_open
System.map-2.6.18-128.el5:ffffffff8020eadb t show_cpuinfo_max_freq
System.map-2.6.18-128.el5:ffffffff8020eafa t show_cpuinfo_min_freq
System.map-2.6.18-128.el5:ffffffff8020f759 t show_cpuinfo_cur_freq
System.map-2.6.18-128.el5:ffffffff802f0bc0 D cpuinfo_op
System.map-2.6.18-128.el5:ffffffff80308420 d proc_cpuinfo_operations
System.map-2.6.18-128.el5:ffffffff803319a0 d cpuinfo_cur_freq
System.map-2.6.18-128.el5:ffffffff80331b20 d cpuinfo_min_freq
System.map-2.6.18-128.el5:ffffffff80331b60 d cpuinfo_max_freq
Platform running Volatility (2.3_alpha, latest from svn):
Linux hydra 3.2.0-35-generic #55-Ubuntu SMP Wed Dec 5 17:42:16 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Source of memory image:
Linux geriatrix.smtps.net 2.6.18-128.el5 #1 SMP Wed Jan 21 10:41:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux
What am I missing?
--
chort
Good day,
As the title suggests I am working with a custom Android installation and I have encountered the "No suitable address space mapping found".
I have not cross-compiled lime.ko and module.ko with exactly the same compiler that I used to build the rest of my installation but I have carried out the build pointing to the same kernel directories and lime.ko can successfully be used to get a memory dump. Can this be the reason for the inconsistency?
Here is what I did:
1. I have downloaded lime from svn:
URL: http://lime-forensics.googlecode.com/svn/trunk/src
Repository Root: http://lime-forensics.googlecode.com/svn
Repository UUID: e105e084-e930-c66b-6cfa-9f740464420f
Revision: 17
Node Kind: directory
Schedule: normal
Last Changed Author: Joe.Sylve(a)gmail.com
Last Changed Rev: 15
Last Changed Date: 2013-03-19 08:10:00 -0700 (Tue, 19 Mar 2013)
2. I have downloaded volatility from svn:
URL: https://volatility.googlecode.com/svn/trunk
Repository Root: https://volatility.googlecode.com/svn
Repository UUID: 8d5d6628-2090-11de-9909-f37ff7dbbc12
Revision: 3444
Node Kind: directory
Schedule: normal
Last Changed Author: michael.hale(a)gmail.com
Last Changed Rev: 3440
Last Changed Date: 2013-06-18 10:08:37 -0700 (Tue, 18 Jun 2013)
3. I have cross-compiled lime for a custom android installation and produced a kernel module and with it I have successfully retrieved a memory dump of size a little less than 2GB.
1951400096 Jun 25 14:50 mem.dump
4. I have also created a profile pointing to the same custom android installatin:
*** note that pmem is not visited and pmem.c is not compiled ***
cd volatility/tools/linux
edit Makefile and cross-compile module.c and produce module.ko
dwarfdump -di module.ko > module.dwarf
head module.dwarf
.debug_info
<0><0x0+0xb><DW_TAG_compile_unit> DW_AT_producer<"GNU C 4.6.x-google 20120106 (prerelease)"> DW_AT_language<DW_LANG_C89> DW_AT_name<"/home/antonios/dev/tools/volatility/tools/linux/module.c"> DW_AT_comp_dir<"/media/DATADRIVE1/B2B_ANTONIOSTIMAE_JFLTE_ATT_SERVER/android/out/target/product/jflteatt/obj/KERNEL_OBJ"> DW_AT_low_pc<0x00000000> DW_AT_high_pc<0x00000000> DW_AT_stmt_list<0x00000000> <Unknown AT value 0x2134><0> <Unknown AT value 0x2135><0>
<1><0x2d><DW_TAG_typedef> DW_AT_name<"__s8"> DW_AT_decl_file<0x00000001 /media/DATADRIVE1/B2B_ANTONIOSTIMAE_JFLTE_ATT_SERVER/android/kernel/include/asm-generic/int-ll64.h> DW_AT_decl_line<0x00000013> DW_AT_type<<0x00000038>>
<1><0x38><DW_TAG_base_type> DW_AT_byte_size<0x00000001> DW_AT_encoding<DW_ATE_signed_char> DW_AT_name<"signed char">
<1><0x3f><DW_TAG_typedef> DW_AT_name<"__u8"> DW_AT_decl_file<0x00000001 /media/DATADRIVE1/B2B_ANTONIOSTIMAE_JFLTE_ATT_SERVER/android/kernel/include/asm-generic/int-ll64.h> DW_AT_decl_line<0x00000014> DW_AT_type<<0x0000004a>>
<1><0x4a><DW_TAG_base_type> DW_AT_byte_size<0x00000001> DW_AT_encoding<DW_ATE_unsigned_char> DW_AT_name<"unsigned char">
<1><0x51><DW_TAG_typedef> DW_AT_name<"__s16"> DW_AT_decl_file<0x00000001 /media/DATADRIVE1/B2B_ANTONIOSTIMAE_JFLTE_ATT_SERVER/android/kernel/include/asm-generic/int-ll64.h> DW_AT_decl_line<0x00000016> DW_AT_type<<0x0000005c>>
<1><0x5c><DW_TAG_base_type> DW_AT_byte_size<0x00000002> DW_AT_encoding<DW_ATE_signed> DW_AT_name<"short int">
zip volatility/volatility/plugins/overlays/linux/mylinux.zip module.dwarf System.map
adding: home/antonios/dev/tools/volatility/tools/linux/module.dwarf (deflated 92%)
adding: media/DATADRIVE1/B2B_ANTONIOSTIMAE_JFLTE_ATT_SERVER/android/out/target/product/jflteatt/obj/KERNEL_OBJ/System.map (deflated 74%)
5. python vol.py --info
LinuxmylinuxARM - A Profile for Linux mylinux ARM
6. however
python vol.py --profile=LinuxmylinuxARM -f mem.dump linux_pslist
results in:
Volatile Systems Volatility Framework 2.3_beta
Offset Name Pid Uid Gid DTB Start Time
---------- -------------------- --------------- --------------- ------ ---------- ----------
No suitable address space mapping found
Tried to open image as:
MachOAddressSpace: mac: need base
LimeAddressSpace: lime: need base
WindowsHiberFileSpace32: No base Address Space
WindowsCrashDumpSpace64: No base Address Space
HPAKAddressSpace: No base Address Space
VirtualBoxCoreDumpElf64: No base Address Space
VMWareSnapshotFile: No base Address Space
WindowsCrashDumpSpace32: No base Address Space
AMD64PagedMemory: No base Address Space
IA32PagedMemoryPae: No base Address Space
IA32PagedMemory: 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
WindowsCrashDumpSpace64: Header signature invalid
HPAKAddressSpace: Invalid magic found
VirtualBoxCoreDumpElf64: ELF64 Header signature invalid
VMWareSnapshotFile: Invalid VMware signature: 0x0
WindowsCrashDumpSpace32: Header signature invalid
AMD64PagedMemory: Incompatible profile LinuxmylinuxARM selected
IA32PagedMemoryPae: Failed valid Address Space check
IA32PagedMemory: Failed valid Address Space check
FileAddressSpace: Must be first Address Space
ArmAddressSpace: Failed valid Address Space check
I have not cross-compiled lime.ko and module.ko with exactly the same compiler that I used to build the rest of my installation but I have carried out the build pointing to the same kernel directories and lime.ko can successfully be used to get a memory dump. Can this be the reason for the inconsistency?
Antonios
Thanks again Michael.
I shall take some time to digest the links you've sent me.
I'm much happier with virtual memory now.
Thank you,
Adam
On 31/08/13 00:32, Michael Cohen wrote:
> Hi Adam,
> "Where is this virtual memory being stored" does not really make
> sense - the virtual memory is virtualized - meaning it does not exist
> in reality and hence needs no storage. As the process accesses
> addresses in the virtual memory space, the kernel pages this memory in
> on demand from either the pagefile, or regular files on disk. Whilst
> you may disable page files, the OS will always be able to use the
> files on disk. Therefore, it is very possible (in fact likely) that
> not all the addressable memory for a process will be available in the
> memory image.
>
> The most common effect of this is when you try to dump out a process
> executable, e.g. with pedump, dlldump, etc. You may find pages which
> are not resident and hence can not be dumped from the memory image
> alone.
>
> Some references to help explain this:
> https://volatility.googlecode.com/svn/branches/scudette/docs/references.html
> http://www.youtube.com/watch?v=9aC7yIYwvAY
>
> And more information about memory layout:
> http://dfrws.org/2013/proceedings/DFRWS2013-13.pdf
>
> Michael.
>
> On 31 August 2013 00:33, Adam Bridge <adam.bridge(a)yahoo.com> wrote:
>> Hi Michael,
>>
>> Thank you again - I really can't thank you enough for your willingness
>> to help!
>> So, I shall definitely make this my last clarifying questions... :)
>>
>> Given "Any process running under 32 bit Windows versions gets a set of
>> virtual memory addresses going from 0 to 4 GB, no matter how much RAM is
>> actually installed on the computer."[1], if, as in my example, the
>> pagefile has been disabled, "where" is this virtual memory being stored?
>> Or is it that if the pagefile.sys is turned off, it can only commit to
>> 512MB, so after 512MB of allocation the system will basically fall over?
>> The virtual 4GB becomes irrelevant and unobtainable?
>>
>> [1]
>> http://members.shaw.ca/bsanders/WindowsGeneralWeb/RAMVirtualMemoryPageFileE…
>> (I kinda put this in to demonstrate that I am trying to find the answers
>> myself - I'm not just relying on your kindness!)
>>
>> Adam
>>
>> On 30/08/13 22:55, Michael Cohen wrote:
>>> Hi Adam,
>>> that depends by what you mean by "all the memory the process is
>>> using". If you mean "All addressable virtual memory" then the answer
>>> is no. Processes usually map files into memory in such a way that if
>>> the process accesses the mapped region of memory, a page fault occurs
>>> and the page is read from disk into memory - so the process thinks
>>> that the file is all mapped into memory at the same time. But since
>>> the file does not exist in the physical memory until its needed, then
>>> you wont see that in the capture. This process is kind of similar to
>>> paging to the page file, except that when mapping files from disk, the
>>> kernel does not need to write the data into the pagefile since it can
>>> just re-read it from the filesystem if it is needed again.
>>>
>>> Michael.
>>>
>>>
>>>
>>> On 30 August 2013 23:47, Adam Bridge <adam.bridge(a)yahoo.com> wrote:
>>>> Michael,
>>>>
>>>> Thanks again - that really helps, and makes sense!
>>>>
>>>> For clarity, given this is a Win7SP1x86 machine where I have disabled
>>>> PAE and disabled pagefile, is it correct to conclude that ALL of the
>>>> memory that this process is using is in the capture? (I gave it 512MB
>>>> RAM and captured all the RAM.)
>>>>
>>>> Adam
>>>>
>>>> On 30/08/13 22:27, Michael Cohen wrote:
>>>>> Adam,
>>>>> Virtual memory is not contiguous. memmap will show you the regions
>>>>> which are mapped to physical memory and the offset in the virtual
>>>>> address space where they are mapped into. The simple answer is that
>>>>> the process's virtual address range from 0x00000000-0x00010000 does
>>>>> not exist - all this means is that if the process was to reference
>>>>> addresses in that range, the processor will issue a page fault, and be
>>>>> killed.
>>>>>
>>>>> Note also that for 64 bit processes, the address space is much larger
>>>>> than 4GB (2^^48 actually).
>>>>>
>>>>> Michael.
>>>>>
>>>>> On 30 August 2013 22:50, Adam Bridge <adam.bridge(a)yahoo.com> wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Hoping for some more newbie assistance!
>>>>>>
>>>>>> I have a sample from Win7SP1x86.
>>>>>> When I took the capture I had notepad.exe running.
>>>>>>
>>>>>> Using pslist(1) I identified the pid and used this with memmap(2).
>>>>>> (1) python vol.py -f win7.raw --profile=Win7SP1x86 pslist
>>>>>> (2) python vol.py -f win7.raw --profile=Win7SP1x86 memmap -p 1260
>>>>>>
>>>>>> So really two questions:
>>>>>>
>>>>>> 1> Why does the first entry show a virtual offset of 0x00010000? Why
>>>>>> isn't it 0x00000000? Where are the first 0x00010000 bytes of this
>>>>>> process's virtual memory?
>>>>>>
>>>>>> 2> (and I know this is gonna be a face palm moment) Why aren't the
>>>>>> virtual memory offsets contiguous? If this is a dump of the process's
>>>>>> virtual memory shouldn't it be one big lump of 4GB? What's the obvious
>>>>>> thing I'm missing? (Is it simply that notepad.exe isn't using all 4GB so
>>>>>> the empty pages have been ignored?)
>>>>>>
>>>>>> Thank you!
>>>>>>
>>>>>> Adam
>>>>>>
>>>>>> --
>>>>>> Have you sent me your PGP Public Key yet?
>>>>>>
>>>>>> _______________________________________________
>>>>>> Vol-users mailing list
>>>>>> Vol-users(a)volatilityfoundation.org
>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>>> --
>>>> Have you sent me your PGP Public Key yet?
>>>>
>> --
>> Have you sent me your PGP Public Key yet?
>>
--
Have you sent me your PGP Public Key yet?
Hi Michael,
Thank you again - I really can't thank you enough for your willingness
to help!
So, I shall definitely make this my last clarifying questions... :)
Given "Any process running under 32 bit Windows versions gets a set of
virtual memory addresses going from 0 to 4 GB, no matter how much RAM is
actually installed on the computer."[1], if, as in my example, the
pagefile has been disabled, "where" is this virtual memory being stored?
Or is it that if the pagefile.sys is turned off, it can only commit to
512MB, so after 512MB of allocation the system will basically fall over?
The virtual 4GB becomes irrelevant and unobtainable?
[1]
http://members.shaw.ca/bsanders/WindowsGeneralWeb/RAMVirtualMemoryPageFileE…
(I kinda put this in to demonstrate that I am trying to find the answers
myself - I'm not just relying on your kindness!)
Adam
On 30/08/13 22:55, Michael Cohen wrote:
> Hi Adam,
> that depends by what you mean by "all the memory the process is
> using". If you mean "All addressable virtual memory" then the answer
> is no. Processes usually map files into memory in such a way that if
> the process accesses the mapped region of memory, a page fault occurs
> and the page is read from disk into memory - so the process thinks
> that the file is all mapped into memory at the same time. But since
> the file does not exist in the physical memory until its needed, then
> you wont see that in the capture. This process is kind of similar to
> paging to the page file, except that when mapping files from disk, the
> kernel does not need to write the data into the pagefile since it can
> just re-read it from the filesystem if it is needed again.
>
> Michael.
>
>
>
> On 30 August 2013 23:47, Adam Bridge <adam.bridge(a)yahoo.com> wrote:
>> Michael,
>>
>> Thanks again - that really helps, and makes sense!
>>
>> For clarity, given this is a Win7SP1x86 machine where I have disabled
>> PAE and disabled pagefile, is it correct to conclude that ALL of the
>> memory that this process is using is in the capture? (I gave it 512MB
>> RAM and captured all the RAM.)
>>
>> Adam
>>
>> On 30/08/13 22:27, Michael Cohen wrote:
>>> Adam,
>>> Virtual memory is not contiguous. memmap will show you the regions
>>> which are mapped to physical memory and the offset in the virtual
>>> address space where they are mapped into. The simple answer is that
>>> the process's virtual address range from 0x00000000-0x00010000 does
>>> not exist - all this means is that if the process was to reference
>>> addresses in that range, the processor will issue a page fault, and be
>>> killed.
>>>
>>> Note also that for 64 bit processes, the address space is much larger
>>> than 4GB (2^^48 actually).
>>>
>>> Michael.
>>>
>>> On 30 August 2013 22:50, Adam Bridge <adam.bridge(a)yahoo.com> wrote:
>>>> Hi all,
>>>>
>>>> Hoping for some more newbie assistance!
>>>>
>>>> I have a sample from Win7SP1x86.
>>>> When I took the capture I had notepad.exe running.
>>>>
>>>> Using pslist(1) I identified the pid and used this with memmap(2).
>>>> (1) python vol.py -f win7.raw --profile=Win7SP1x86 pslist
>>>> (2) python vol.py -f win7.raw --profile=Win7SP1x86 memmap -p 1260
>>>>
>>>> So really two questions:
>>>>
>>>> 1> Why does the first entry show a virtual offset of 0x00010000? Why
>>>> isn't it 0x00000000? Where are the first 0x00010000 bytes of this
>>>> process's virtual memory?
>>>>
>>>> 2> (and I know this is gonna be a face palm moment) Why aren't the
>>>> virtual memory offsets contiguous? If this is a dump of the process's
>>>> virtual memory shouldn't it be one big lump of 4GB? What's the obvious
>>>> thing I'm missing? (Is it simply that notepad.exe isn't using all 4GB so
>>>> the empty pages have been ignored?)
>>>>
>>>> Thank you!
>>>>
>>>> Adam
>>>>
>>>> --
>>>> Have you sent me your PGP Public Key yet?
>>>>
>>>> _______________________________________________
>>>> Vol-users mailing list
>>>> Vol-users(a)volatilityfoundation.org
>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>> --
>> Have you sent me your PGP Public Key yet?
>>
--
Have you sent me your PGP Public Key yet?
Michael,
Thanks again - that really helps, and makes sense!
For clarity, given this is a Win7SP1x86 machine where I have disabled
PAE and disabled pagefile, is it correct to conclude that ALL of the
memory that this process is using is in the capture? (I gave it 512MB
RAM and captured all the RAM.)
Adam
On 30/08/13 22:27, Michael Cohen wrote:
> Adam,
> Virtual memory is not contiguous. memmap will show you the regions
> which are mapped to physical memory and the offset in the virtual
> address space where they are mapped into. The simple answer is that
> the process's virtual address range from 0x00000000-0x00010000 does
> not exist - all this means is that if the process was to reference
> addresses in that range, the processor will issue a page fault, and be
> killed.
>
> Note also that for 64 bit processes, the address space is much larger
> than 4GB (2^^48 actually).
>
> Michael.
>
> On 30 August 2013 22:50, Adam Bridge <adam.bridge(a)yahoo.com> wrote:
>> Hi all,
>>
>> Hoping for some more newbie assistance!
>>
>> I have a sample from Win7SP1x86.
>> When I took the capture I had notepad.exe running.
>>
>> Using pslist(1) I identified the pid and used this with memmap(2).
>> (1) python vol.py -f win7.raw --profile=Win7SP1x86 pslist
>> (2) python vol.py -f win7.raw --profile=Win7SP1x86 memmap -p 1260
>>
>> So really two questions:
>>
>> 1> Why does the first entry show a virtual offset of 0x00010000? Why
>> isn't it 0x00000000? Where are the first 0x00010000 bytes of this
>> process's virtual memory?
>>
>> 2> (and I know this is gonna be a face palm moment) Why aren't the
>> virtual memory offsets contiguous? If this is a dump of the process's
>> virtual memory shouldn't it be one big lump of 4GB? What's the obvious
>> thing I'm missing? (Is it simply that notepad.exe isn't using all 4GB so
>> the empty pages have been ignored?)
>>
>> Thank you!
>>
>> Adam
>>
>> --
>> Have you sent me your PGP Public Key yet?
>>
>> _______________________________________________
>> Vol-users mailing list
>> Vol-users(a)volatilityfoundation.org
>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
--
Have you sent me your PGP Public Key yet?
Hi all,
Hoping for some more newbie assistance!
I have a sample from Win7SP1x86.
When I took the capture I had notepad.exe running.
Using pslist(1) I identified the pid and used this with memmap(2).
(1) python vol.py -f win7.raw --profile=Win7SP1x86 pslist
(2) python vol.py -f win7.raw --profile=Win7SP1x86 memmap -p 1260
So really two questions:
1> Why does the first entry show a virtual offset of 0x00010000? Why
isn't it 0x00000000? Where are the first 0x00010000 bytes of this
process's virtual memory?
2> (and I know this is gonna be a face palm moment) Why aren't the
virtual memory offsets contiguous? If this is a dump of the process's
virtual memory shouldn't it be one big lump of 4GB? What's the obvious
thing I'm missing? (Is it simply that notepad.exe isn't using all 4GB so
the empty pages have been ignored?)
Thank you!
Adam
--
Have you sent me your PGP Public Key yet?
Hi all,
I'm definitely still learning with memory forensics, but I can't get my
head around this one.
I created a Virtualbox VM of Win7SP1x86 with 512MB RAM.
I disabled the pagefile - confirmed with reboot that pagefile.sys
disappeared.
I disabled pae - confirmed with reboot followed by: wcim os get
PAEEnabled, returned FALSE.
I then used:
vboxmanage debugvm "Win7" dumpguestcore --filename test.elf
to grab the ELF64 dump.
This file is: 569.5MB
I then used:
python vol.py -f test.elf --profile=Win7SP1x86 imagecopy -O test.raw
test.raw is: 4.0GB
Given that pae is off and pagefile.sys is off, where has the extra data
come from?!
I get that in 32-bit, we can represent up to 0xFFFFFFFF (2^32) = 4GB,
but where has the extra data come from?
Is it all going to be 0-padded or have I done something wrong somewhere?!
Any clues, tips, links to read, and flames welcome.
Adam
--
If you like, we could go PGP..?
Hi All,
Currently, I am using Volatility to analyze a lime dump of an Android device and I have the same error message as the post of the no suitable address space mapping found (http://lists.volatilityfoundation.org/pipermail/vol-users/2013-July/000942.…)
I have followed the steps as indicated in the Volatility Android memory forensic instructions (https://code.google.com/p/volatility/wiki/AndroidMemoryForensics) and listed them below the dotted line in this mail.
However, the error No suitable address space mapping found is showing.
Anybody have any idea what is going / I am doing wrong ? (please see the steps I have performed below)
Winston
*****************************************
Steps I followed:
Memory research of Device : HTC One V
kernel device primou-ics-crc-3.0.16-133e482
Android : 4.0.3
Host system for Volatility: Ubuntu 13.04
Python 2.7.4 (default, Apr 19 2013, 18:32:33)
[GCC 4.7.3] on linux2
Steps as followed from https://code.google.com/p/volatility/wiki/AndroidMemoryForensics except for the emulator steps:
1. Downloaded lime, cross compiled lime and build a *.ko file and created a lime.dump (format=lime) file
2. Downloaded Volatility, created a zip profile
a. System.map retrieved from the device at /proc/kallsyms
b. Module.dwarf
$ head module.dwarf
.debug_info
<0><0x0+0xb><DW_TAG_compile_unit> DW_AT_producer<"GNU C 4.7"> DW_AT_language<DW_LANG_C89> DW_AT_name<"/android/volatility-2.2/tools/linux/module.c"> DW_AT_comp_dir<"/home/winston/htc/primou-ics-crc-3.0.16-133e482"> DW_AT_stmt_list<0x00000000>
<1><0x1d><DW_TAG_typedef> DW_AT_name<"__s8"> DW_AT_decl_file<0x00000001 include/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 include/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 include/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">
3. Using Volatility 2.2 and I have tried volatility 2.3-development and the latest volatility from svn co https://volatility.googlecode.com/svn/trunk (latest check out at 9th of august 2013)
a. $ python vol.py info
LinuxprofileHTCOneV2x86 - A Profile for Linux profileHTCOneV2 x86
b. Note, I implemented a work around since my system.map / proc/kallsyms sometimes contained four columns instead of 3.
Part of my system.map file:
c0682d70 A _etext
bf005000 t dhd_sleep_pm_callback [bcmdhd]
Error:
File "/android/volatility-2.2/volatility/plugins/overlays/linux/linux.py", line 86, in parse_system_map
(str_addr, symbol_type, symbol) = line.strip().split()
ValueError: too many values to unpack
Work around :
Added in /android/volatility-2.2/volatility/plugins/overlays/linux/linux.py, line 87:
(str_addr, symbol_type, symbol) = line.strip().split()[0:3] //added work around
#(str_addr, symbol_type, symbol) = line.strip().split() // original
c. $ python vol.py --profile=LinuxprofileHTCOneV2x86 -f /android/resultfiles/HTVOneV/lime7-31-13_1317.lime linux_pslist
Volatile Systems Volatility Framework 2.3_alpha
WARNING : volatility.obj : Overlay structure cpuinfo_x86 not present in vtypes
Offset Name Pid Uid Start Time
---------- -------------------- --------------- --------------- ----------
No suitable address space mapping found
Tried to open image as:
MachOAddressSpace: mac: need base
LimeAddressSpace: lime: need base
WindowsHiberFileSpace32: No base Address Space
WindowsCrashDumpSpace64: No base Address Space
WindowsCrashDumpSpace32: No base Address Space
JKIA32PagedMemoryPae: No base Address Space
AMD64PagedMemory: No base Address Space
JKIA32PagedMemory: No base Address Space
IA32PagedMemoryPae: Module disabled
IA32PagedMemory: Module disabled
MachOAddressSpace: MachO Header signature invalid
MachOAddressSpace: MachO Header signature invalid
LimeAddressSpace: Invalid Lime header signature
WindowsHiberFileSpace32: PO_MEMORY_IMAGE is not available in profile
WindowsCrashDumpSpace64: Header signature invalid
WindowsCrashDumpSpace32: Header signature invalid
JKIA32PagedMemoryPae - EXCEPTION: unsupported operand type(s) for -: 'NoneType' and 'long'
AMD64PagedMemory: Incompatible profile LinuxprofileHTCOneV2x86 selected
JKIA32PagedMemory - EXCEPTION: unsupported operand type(s) for -: 'NoneType' and 'long'
IA32PagedMemoryPae: Module disabled
IA32PagedMemory: Module disabled
FileAddressSpace: Must be first Address Space
ArmAddressSpace - EXCEPTION: unsupported operand type(s) for -: 'NoneType' and 'long'
Hey all,
A while ago I did some experiments with finding the swap_info_structs
for linux swap files/devices.
Since I don't have time to finish any work on that (this was the easy
part) I've uploaded it to my github:
https://github.com/Dutchy-/volatility-plugins/blob/master/linux/swap.py
Do with it as you wish :D note that a proper swap implementation would
likely need modification in volatility itself, not just a plugin.
Cheers,
Edwin
PS. I've also added all the plugins from my submission to the plugin contest.
This post is not specifically about Volatility; however, I know that the
topic will be of interest to many list members. Reliable memory
analysis depends on reliable memory acquisition. No matter how good an
analysis tool is, it can only analyze what is in the memory "dump." If
the memory acquisition tool produces an incomplete or erroneous memory
dump the analysis will also fail or be misleading. It is thus with
pleasure that I note the progress that is being made toward developing a
critical framework for evaluating and testing memory acquisition tools.
The latest contribution is by Stefan Vömel and Johannes Stüttgen whose
paper, "An evaluation platform for forensic memory acquisition software"
was presented at the recent DFRWS conference and may be downloaded from
the following link:
http://www.dfrws.org/2013/proceedings/DFRWS2013-11.pdf.
The authors adopt an approach which they call "white-box testing"
whereby the authors modify the source code for various open source tools
(win32dd, mdd, winpmem) to insert hypercalls at various locations in the
acquisition process. The hypercalls inform the test platform of various
important system events and operations and inspect the state of the
subject system at the moment of the hypercall. The state as recorded by
the hypercalls is then used as a metric to evaluate the reliability
(i.e. "correctness") of the tool which is under test.
The approach has a number of significant limitations which the authors
acknowledge, the most significant of which is that they require the
source code which must be modified in order to perform the test. Most
commercial tool vendors do not provide the source code to their memory
acquisition tools. Even one of the open source tools tested by Vömel
and Stüttgen, win32dd, is an old version of the current closed-source
Moonsols tool which contains many bug fixes which are not in the open
source precursor. As far as I am aware the MDD tool is no longer
supported or under active development. Michael Cohen's winpmem is the
only currently supported tool that the authors were able to test.
Another significant limitation is that the test platform is tied to a
highly customized version of the Bochs x86 PC emulator. The test
platform is restricted to 32-bit versions of Windows with not more than
2 GiB of memory. The acquisition of physical memory from systems
equipped with more than 4 GiB of memory and from 64-bit versions of
Microsoft Windows are areas where memory acquisition tool vendors have
stumbled in the past. Possibly all contemporary memory acquisition
tools handle 64-bit systems and systems with more than 4 GiB of memory
correctly; however, we would like to be able to test this and not rely
solely on faith.
One limitation which the authors do not discuss is the impact of
restricting the test platform to a particular VM (i.e. Bochs). In our
experience VMs provide a much more highly predictable and stable
environment than real hardware and may not be a good indication of how a
memory acquisition tool will perform on real hardware. In addition, as
was mentioned previously on this list, different VM manufacturers have
chosen to emulate very different PC designs. How a tool performs on
VMWare may not be a good indicator of how the same tool will perform on
Microsoft Hyper-V or VirtualBox or KVM.
Also, the authors do not acknowledge the possibility that memory
acquisition tools may perform differently on different versions of the
Microsoft operating system. Each new version of the Microsoft operating
system has brought changes to the Windows memory manager, in some cases
significant changes. Currently, we are (out of necessity) using
acquisition methods that differ in varying degrees on Microsoft Windows
XP, Windows 2003 SP1 and later, Windows Vista, Windows 7 and Windows 8.
For Windows 8.1 Preview we have found it necessary to invent new
methods that are different from all of the methods which we previously
employed.
Finally, the authors do not articulate the theoretical framework for
forensic volatile memory acquisition which serves as the basis for their
notion of "correctness." Historically, computer forensic experts have
evaluated the acquisition of volatile memory as an "imaging" process.
Most computer forensic experts were familiar with the imaging of "dead"
hard drives. It was natural to assume memory acquisition was doing much
the same thing. The problem is that a running computer system is by
nature a stochastic process (more precisely, it is a "continuous time
stochastic process") which cannot be "imaged." It can only be sampled.
Sampling is a common technique in forensic science, other than in
computer forensics. Computer forensics is somewhat unique among
forensic "sciences" in its almost exclusive reliance upon "imaging" as a
standard of reliability. It is difficult not to note the severe tension
which exists between this theoretic framework and the reality of modern
computer design. Not only is "live" imaging of hard drives now
commonplace for practical reasons (which equally aren't true images) but
also, as we now know, a hard drive is an embedded computer system which
may alter the physical layout of data on the disks any time power is
applied to the drive.
The theoretical approach which we have advocated (see, e.g. Garner, Maut
Design Document (unpublished manuscript, 2011), is to view volatile
memory acquisition as a process of sampling the state of a
continuous-time stochastic process. We further propose to use the
structural elements created by the operating system and the hardware as
a metric to evaluate the reliability of the sampling process. We
believe that these structural elements may be used for this purpose
because they possess the Markhov property. Their future state is
predictable, depending entirely on their present state and is
conditionally independent of the past. A sample is said to be reliable
when it is "representative" of the entire population. In other words, a
sample is reliable with respect to a specific issue of material fact if
an inference drawn upon the basis of the sample will arrive at the same
conclusion as if the inference were drawn upon the basis of the entire
population.
The authors appear to assume the tradition "imaging" framework for
volatile computer memory acquisition, however, this assumption should be
stated since the entire rest of the paper depends on it.
In conclusion, this paper makes an important contribution to a topic
that is important for the future of computer forensics. However, the
authors need to better articulate their assumptions. Development of a
professional memory forensic tool testing platform will require the
development of a test enviroment which overcomes the current limitations.
Regards,
George M. Garner Jr.
President
GMG Systems, Inc.
