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
Hi guys,
I found out that version 2.3 of volatility shows an additional DTB address
value for each process in the linux_pslist command.
Can anyone tell me what this address exactly is and how it can be useful?
Thank you!
--
Sebastian
vol-users,
The official registration invitations for OMFW 2013 went out this week. If
you are still planning to attend, I recommend sending a request soon.
There are less than 10 spots remaining!
https://www.volatilityfoundation.org/default/omfw
Reserve your seat by contacting: info [at] volatilesystems [dot] com.
Thanks,
The Volatility Foundation
Good evening,
I have what purports to be a Windows Server 2003 vmss file from an ESXi
server.
Volatile Systems Volatility Framework 2.2
Determining profile based on KDBG search...
Suggested Profile(s) : Win2003SP0x86, Win2003SP1x86, Win2003SP2x86
AS Layer1 : FileAddressSpace (E:\memory.vmss)
PAE type : No PAE
DTB : 0xe02000L
KDBG : 0x89e3e0
Number of Processors : 32
Image Type (Service Pack) : 8388479
KPCR for CPU 1 : 0xb4428734L
KPCR for CPU 105 : 0x6ab88836
KPCR for CPU 187 : 0xbbb081feL
KPCR for CPU 217 : 0xd26666cfL
KPCR for CPU 244 : 0xf6396926L
KPCR for CPU 43 : 0xdb784fe4L
KPCR for CPU 0 : 0xbfcc7b14L
KPCR for CPU 144 : 0xfdce5831L
KPCR for CPU 163 : 0xe645d2edL
KPCR for CPU 240 : 0xe641b395L
KPCR for CPU 0 : 0x54430b95
KPCR for CPU 121 : 0xe647cb92L
KPCR for CPU 156 : 0x11fcab95
KPCR for CPU 88 : 0x7e5a9411
KPCR for CPU 0 : 0x3a144ddb
KPCR for CPU 0 : 0xad8d25f2L
KPCR for CPU 167 : 0x6a05fdd2
KPCR for CPU 149 : 0x9623d84aL
KPCR for CPU 116 : 0x4d5a811c
KPCR for CPU 0 : 0x770a23f1
KPCR for CPU 0 : 0x62485716
KPCR for CPU 47 : 0xb52572fcL
KPCR for CPU 0 : 0x1449293a
KPCR for CPU 46 : 0x4997edb2
KPCR for CPU 0 : 0x95971adeL
KPCR for CPU 0 : 0x95bcc716L
KPCR for CPU 53 : 0x55851105
KPCR for CPU 0 : 0x55bcc700
KPCR for CPU 0 : 0xd5893716L
KPCR for CPU 169 : 0x4a21113d
KPCR for CPU 1 : 0x88f33d8dL
KPCR for CPU 0 : 0xa3d2de22L
KUSER_SHARED_DATA : 0xffdf0000L
Image date and time : 1970-01-01 00:00:00 UTC+0000
Traceback (most recent call last):
File "vol.py", line 186, in <module>
main()
File "vol.py", line 177, in main
command.execute()
File "E:\Tools\volatility-2.2\volatility\commands.py", line 111, in
execute
func(outfd, data)
File "E:\Tools\volatility-2.2\volatility\plugins\imageinfo.py", line 34,
in re
nder_text
for k, v in data:
File "E:\Tools\volatility-2.2\volatility\plugins\imageinfo.py", line 109,
in c
alculate
yield ('Image local date and time',
timefmt.display_datetime(data['ImageDate
time'].as_datetime(), data['ImageTz']))
File "E:\Tools\volatility-2.2\volatility\timefmt.py", line 82, in
display_date
time
dt = dt.astimezone(custom_tz)
ValueError: tzinfo.utcoffset() returned 1440; must be in -1439 .. 1439
Or, maybe it isn't.
Anyhow, I converted it with imagecopy and while imageinfo returns the same
information, none of the other commands will work:
E:\Tools\volatility-2.2>python vol.py -f E:\RAM\memory.raw
--profile=Win2003SP2x86 connections
Volatile Systems Volatility Framework 2.2
No suitable address space mapping found
Tried to open image as:
LimeAddressSpace: lime: need base
WindowsHiberFileSpace32: No base Address Space
WindowsCrashDumpSpace64: No base Address Space
WindowsCrashDumpSpace32: No base Address Space
AMD64PagedMemory: No base Address Space
JKIA32PagedMemory: No base Address Space
JKIA32PagedMemoryPae: No base Address Space
IA32PagedMemoryPae: Module disabled
IA32PagedMemory: Module disabled
LimeAddressSpace: Invalid Lime header signature
WindowsHiberFileSpace32: No xpress signature found
WindowsCrashDumpSpace64: Header signature invalid
WindowsCrashDumpSpace32: Header signature invalid
AMD64PagedMemory: Incompatible profile Win2003SP2x86 selected
JKIA32PagedMemory: Failed valid Address Space check
JKIA32PagedMemoryPae: Failed valid Address Space check
IA32PagedMemoryPae: Module disabled
IA32PagedMemory: Module disabled
FileAddressSpace: Must be first Address Space
Any thoughts on how to work with this image would be most welcome.
-David
As part of some recent work, I was looking at integrating CMU's Binary Analysis Platform (BAP)[1] with the Volatility framework. The (partly hacky) result of this work can be found at:
https://bitbucket.org/carlpulley/libbap
If nothing else, it provides some idea as to what can be done with such integrations. Hopefully, it will be of interest to others within the RE/Memory forensics communities?
All the best,
Carl.
[1] http://bap.ece.cmu.edu/
1) There are missing symbols required for plugins to run that kallsyms does
not have. I suspect you can get a partial listing of these if you run
Volatility with -dd and look for errors about symbol resolution errors.
2) It seems you built a kernel using the sources of the phone, but that it
is not actually the kernel running on the phone? If you are going to use
the System.map from the kernel then the phone needs to actually run that
kernel. Otherwise, you need the System.map from when the vendor compiled
the kernel. Did the distributed sources you use have a System.map file with
them and/or a debug kernel (vmlinux)?
On Wed, Aug 28, 2013 at 5:52 AM, Winston Siauw (DT) <winston(a)holmes.nl>wrote:
> Hi Andrew,****
>
> ** **
>
> Thanks again for your reply.****
>
> I have manage to build the kernel, retrieve the System.map file and build
> a profile with it.****
>
> However, volatility does not give any output nor error as can be seen
> below:****
>
> ** **
>
> $ python vol.py --profile=LinuxprofileHtcOneV-IcsARM -f /dump.lime
> linux_pslist****
>
> Volatile Systems Volatility Framework 2.3_beta****
>
> WARNING : volatility.obj : Overlay structure tty_struct not present
> in vtypes****
>
> Offset Name Pid Uid Gid
> DTB Start Time****
>
> ---------- -------------------- --------------- --------------- ------
> ---------- ----------****
>
> ( empty )****
>
> ** **
>
> As indicated in your last mail, the build System.map and the device
> Kallsyms are not equal. ****
>
> However, besides not having the same symbols as System.map the memory
> addresses also differ. ****
>
> Is this expected or is this because I have done something wrong?****
>
> I.e.:****
>
> ** **
>
> System.map (builded kernel):****
>
> c0008200 t set_reset_devices****
>
> c0008224 t debug_kernel****
>
> c000824c t quiet_kernel****
>
> ** **
>
> Kallsyms (from device):****
>
> c0008200 t set_reset_devices****
>
> c0008218 t debug_kernel****
>
> c0008230 t quiet_kernel****
>
> ** **
>
> ** **
>
> Moreover, is it known which symbols are exactly missing in the Kallsyms
> file that are noted in the System.map and can I implement a work around for
> this? ****
>
> Furthermore, in another post (
> http://lists.volatilityfoundation.org/pipermail/vol-users/2013-February/000…)
> Michael Hale Ligh* *indicated: ****
>
> “Only as a last resort use /proc/kallsyms and even in that case, delete
> the lines related to lime so****
>
> it doesn't raise ValueError”. Thus if I delete all lime related lines in
> the kallsyms then it would work?****
>
> ** **
>
> ** **
>
> Best regards,****
>
> ** **
>
> Winston****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> *From:* Andrew Case [mailto:atcuno@gmail.com]
> *Sent:* Wednesday, August 14, 2013 7:58 PM
> *To:* Winston Siauw (DT)
> *Cc:* vol-users(a)volatilityfoundation.org
> *Subject:* Re: [Vol-users] custom Android profile: No suitable address
> space****
>
> ** **
>
> Hello,
>
> We are working on new documentation for this issue and actually hope to
> develop a workaround if at all possible. The issue is that kallsyms, while
> having a different file format as you noticed, does not contain all of the
> same symbols as System.map and because of this Volatility cannot use a
> profile that has kallsyms output. There are symbols in System.map that are
> currently required for Volatility to operate and these symbols are not
> contained in kallsyms. ****
>
> If you can obtain the System.map file for the kernel you wish to analyze
> then please use that and incorporate it into the profile.
>
> Thanks,
> Andrew****
>
> ** **
>
> On Wed, Aug 14, 2013 at 3:28 AM, Winston Siauw (DT) <winston(a)holmes.nl>
> wrote:****
>
> 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'****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
>
> _______________________________________________
> Vol-users mailing list
> Vol-users(a)volatilityfoundation.org
> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users****
>
> ** **
>
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?
