Hi guys, i'm working on a project to analyze memory dumps of Android devices with Volatility. But it seems that it isn't possible to do so if the source code does not provide me with the System.map file. I can't compile my own System.map file using commands like "make ARCH=arm CROSS_COMPILE=$CCOMPILER" (this would give me inaccurate addresses) nor can i use the /proc/kallsyms (this does not have symbols required for volatility to prepare) file from the Android device itself. I just wanna verify, is it actually still possible for me to use volatility to analyze this memory dump if the System.map file wasn't distributed with the headers/source? Thanks.
Dear all,
sorry, I'm using webmail only and couldn't set an in reply-to header to my last message.
Libvmi seems a bit complicated to install, at least compared to the vboxmanage debugvm command. Is libvmi required for KVM or is it possible to use virsh dump?
Thank you in advance.
- Chris
Hi,I am trying to build a volatility 2.3p profile using a mac os host 10.8.5 and a 4.3 android goldfish guest custom kernel.edited my make file under tools/linux/ to: "obj-m += module.oKDIR := ~/goldfish-ksemulator/ CCPATH := ~/android-ndk/toolchains/arm-linux-androideabi-4.7/prebuilt/darwin-x86_64/bin/DWARFDUMP := /Users/Hanaysha/dwarf/dwarfdump/dwarfdump-include version.mkall: dwarfdwarf: module.c $(MAKE) ARCH=arm CROSS_COMPILE=$(CCPATH)/arm-linux-androideabi- -C $(KDIR) CONFIG_DEBUG_INFO=y M=$(PWD) modules$(DWARFDUMP) -di module.ko > module.dwarf "I am awarded with the follwing errors :"Hanayshas-MacBook-Pro:linux Hanaysha$ makemake -C ~/goldfish-ksemulator//lib/modules/12.5.0/build CONFIG_DEBUG_INFO=y M=/Users/Hanaysha/android-volatility/tools/linux modulesmake: *** /Users/Hanaysha/goldfish-ksemulator//lib/modules/12.5.0/build: No such file or directory. Stop.make: *** [dwarf] Error 2Hanayshas-MacBook-Pro:linux Hanaysha$ makemake ARCH=arm CROSS_COMPILE=~/android-ndk/toolchains/arm-linux-androideabi-4.7/prebuilt/darwin-x86_64/bin//arm-linux-androideabi- -C ~/goldfish-ksemulator/ CONFIG_DEBUG_INFO=y M=/Users/Hanaysha/android-volatility/tools/linux modulesBuilding modules, stage 2.MODPOST 1 modulesCC /Users/Hanaysha/android-volatility/tools/linux/module.mod.o/Users/Hanaysha/android-volatility/tools/linux/module.mod.c:8:1: error: variable '__this_module' has initializer but incomplete type/Users/Hanaysha/android-volatility/tools/linux/module.mod.c:9:2: error: unknown field 'name' specified in initializer/Users/Hanaysha/android-volatility/tools/linux/module.mod.c:9:2: warning: excess elements in struct initializer [enabled by default]/Users/Hanaysha/android-volatility/tools/linux/module.mod.c:9:2: warning: (near initialization for '__this_module') [enabled by default]/Users/Hanaysha/android-volatility/tools/linux/module.mod.c:10:2: error: unknown field 'arch' specified in initializer/Users/Hanaysha/android-volatility/tools/linux/module.mod.c:10:10: error: 'MODULE_ARCH_INIT' undeclared here (not in a function)/Users/Hanaysha/android-volatility/tools/linux/module.mod.c:10:2: warning: excess elements in struct initializer [enabled by default]/Users/Hanaysha/android-volatility/tools/linux/module.mod.c:10:2: warning: (near initialization for '__this_module') [enabled by default]make[2]: *** [/Users/Hanaysha/android-volatility/tools/linux/module.mod.o] Error 1make[1]: *** [modules] Error 2make: *** [dwarf] Error 2"Any ideas !? your help is appreciated
Hi guys,
I'm trying to find out the addresses of the memory pages of a target
process that are used as stack and heap on Linux.
(Precisely, I would like to have the output which can be seen in
/proc/<pid>/maps for a target process)
Unfortunately, the command linux_proc_maps is not working, I always get
a segmentation fault,
although I tried different kernels as well as Linux setups (Ubuntu) -
it's just not working.
Can anyone tell me a setup (Linux & Kernel) in which the linux_proc_maps
command works?
Or give me a hint how I could figure out these addresses on another way?
Thank you!
Hi everyone,
I ran apihook command in Volatility with the very fast pyvmi address space.
However, I didn't see significant performance improvement in terms of the
total runtime as it still ran for 5 mins - 6 mins.
Although I have got profiling report of apihooks by cProfile and have been
aware that __read_bytes(), the acquisittion of memory content, just
consumed a very small part, which is 7 secs, of the total 5~6 mins, and
that the overhead may be categorized in apihook algorithm, memory
acquisition as well as Python runtime, I can hardly go further in figuring
out which part of the apihook cost the most.
I attach the profiling report here, and hope anyone help analysis.
Thank you so much.
Guanglin
We are working volatility. Firstly we installed python, then its
dependencies i.e. pycrpto, yara, distorm Min gw. After installing all this
to our system, out volatility 2.1 software is not working, or we are not
able to use it. Need help in this regard.
We wrote a blog post today that announced our first two trainings of 2014:
http://volatility-labs.blogspot.com/2013/09/2014-malware-and-memory-forensi…
We will be in San Diego, CA in January as well as London in June. Once
we confirm our other trainings that are currently in the works we will
post them as well. At least one of these trainings will be on the east
coast.
Also, as a reminder, we still have a few spots left in our November
training in Reston, so please contact us ASAP if you would like to
attend.
Thanks,
Andrew (@attrc)
Hi,
what's the preferred virtualization method to create memory dumps? Is it possible to acquire the guest memory without guest modifications? Linux and Windows guests are used.
Regards,
Chris
HaHa! Thanks Jesse!
Thank you for the hints - I'm just trying to get my head around walking
the VAD tree at the moment.
I'll be sure to ask you if I need some more assistance.
Hopefully down the line I'll write a mini-tutorial around this to share
with the list.
Adam
On 21/09/13 19:25, Jesse Kornblum wrote:
> Hi Adam,
>
> Two hints, in progressive levels of practicality:
>
> 1. I when I tried to do this, I ended up falling down in a Heap.
>
> 2. Memory allocated by a program is stored in the VADs.
>
> If you're stuck, write back and I'll show you exactly how to do it!
>
> Good luck,
--
Have you sent me your PGP Public Key yet?
Hi all,
I'm hoping for some suggestions around how to find the answer for
myself, rather than the actual answer.
I'm experimenting with notepad to try and learn more about Windows
memory management.
Currently I'm trying to see if I can reliably locate what has been typed
into a notepad window from a memory capture taken when the notepad
window was still open.
I can prove my text is present like so:
$ python vol.py -f ~/memtest/win7.raw --profile=Win7SP1x86 pslist | grep
notepad
Volatile Systems Volatility Framework 2.3_beta
0x84f08030 notepad.exe 292 1664 2 59
1 0 2013-08-28 20:50:36 UTC+0000
$ python vol.py -f ~/memtest/win7.raw --profile=Win7SP1x86 memdump
--dump-dir=~/memtest/ -p 292
Volatile Systems Volatility Framework 2.3_beta
************************************************************************
Writing notepad.exe [ 292] to 292.dmp
$ strings -e l ~/memtest/292.dmp | grep "i-typed-"
i-typed-this-into-notepad
(The "-e l" switch is because notepad stores its text in 16-bit
little-endian.)
Combining the output of memdump and memmap I can see where in physical
and virtual memory my string is located.
Of course this relies on me knowing the string ahead of time.
Do I need to go down the route of disassembling/debugging notepad.exe in
order to determine how/when it writes the contents to memory?
Or is there another approach that I simply haven't though of?
Comments greatly appreciated!
Thanks,
Adam
--
Have you sent me your PGP Public Key yet?
Hi people,
Currently I'm trying to use Volatility to analyze a memory image that i have acquired from my Samsung Galaxy Nexus using LiME. I saw somewhere on this forum(?) that the System.map file pulled out from /proc/kallsyms is unusable due to those lines that contain "[lime]" but can be addressed by removing those lines.
I managed to built the profile and verified it against the following command:
# python vol.py --info | grep ProfileVolatile Systems Volatility Framework 2.3_beta
Profiles
Linuxsamsungx86 - A Profile for Linux samsung x86
VistaSP0x64 - A Profile for Windows Vista SP0 x64
VistaSP0x86 - A Profile for Windows Vista SP0 x86
VistaSP1x64 - A Profile for Windows Vista SP1 x64
VistaSP1x86 - A Profile for Windows Vista SP1 x86
VistaSP2x64 - A Profile for Windows Vista SP2 x64
VistaSP2x86 - A Profile for Windows Vista SP2 x86
Win2003SP0x86 - A Profile for Windows 2003 SP0 x86
Win2003SP1x64 - A Profile for Windows 2003 SP1 x64
Win2003SP1x86 - A Profile for Windows 2003 SP1 x86
Win2003SP2x64 - A Profile for Windows 2003 SP2 x64
Win2003SP2x86 - A Profile for Windows 2003 SP2 x86
Win2008R2SP0x64 - A Profile for Windows 2008 R2 SP0 x64
Win2008R2SP1x64 - A Profile for Windows 2008 R2 SP1 x64
Win2008SP1x64 - A Profile for Windows 2008 SP1 x64
Win2008SP1x86 - A Profile for Windows 2008 SP1 x86
Win2008SP2x64 - A Profile for Windows 2008 SP2 x64
Win2008SP2x86 - A Profile for Windows 2008 SP2 x86
Win7SP0x64 - A Profile for Windows 7 SP0 x64
Win7SP0x86 - A Profile for Windows 7 SP0 x86
Win7SP1x64 - A Profile for Windows 7 SP1 x64
Win7SP1x86 - A Profile for Windows 7 SP1 x86
WinXPSP1x64 - A Profile for Windows XP SP1 x64
WinXPSP2x64 - A Profile for Windows XP SP2 x64
WinXPSP2x86 - A Profile for Windows XP SP2 x86
WinXPSP3x86 - A Profile for Windows XP SP3 x86
However, when i run the command:
#python vol.py --profile=Linuxsamsungx86 -f /root/majorProject/ram.lime linux_pslist
I get the following error:
Volatile Systems Volatility Framework 2.3_beta
WARNING : volatility.obj : Overlay structure cpuinfo_x86 not present in vtypes
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: 0x81ed
WindowsCrashDumpSpace32: Header signature invalid
AMD64PagedMemory: Incompatible profile Linuxsamsungx86 selected
IA32PagedMemoryPae - EXCEPTION: unsupported operand type(s) for -: 'NoneType' and 'int'
IA32PagedMemory - EXCEPTION: unsupported operand type(s) for -: 'NoneType' and 'int'
FileAddressSpace: Must be first Address Space
ArmAddressSpace - EXCEPTION: unsupported operand type(s) for -: 'NoneType' and 'int'
It's the same regardless of the volatility plugin i'm using. Any idea where i'm wrong over here? Anyway attached is zip folder that contains the System.map file as well as my module.dwarf file. Any help or advise in this area would be greatly appreciated thank you very much :)
Oh yes, do let me know if there's any other information required that might help solve this issue, i'm quite desperate over here =P
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?
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.
Hi all,
I wrote a little tool to convert a KVM/libvirt dump to a raw memory
file (https://github.com/juergh/lqs2mem) Volatility seems to be able
to handle the resulting file just fine for small dumps but not so much
the larger they get. Specifically, things start to break when the
memory size of the VM approaches 4 GB. I double and triple checked my
code and can't find anything obviously wrong (like using a 32bit
variable for a 64bit address or pointer). I also don't think that
Volatility has a problem with larger dumps since it can handle a 8 GB
memory dump that I obtained using some other means. I'm just running
out of ideas and am looking for some help or suggestions on how to
debug this further.
In my testing with Win 2008 R2 SP1 x64 I found that (see full outputs below):
1) imageinfo and pslist return the correct output for VMs with less than 3588 MB
2) pslist only returns a single task (System) for VMs larger than 3587 MB
3) imageinfo shows only 1 processor (when there are actually two) for
VMs larger than 3712 MB (give or take)
Any help is greatly appreciated.
Thanks
...Juerg
VM memory size: 3584 MB:
Determining profile based on KDBG search...
Suggested Profile(s) : Win2008R2SP0x64, Win7SP1x64,
Win7SP0x64, Win2008R2SP1x64
AS Layer1 : AMD64PagedMemory (Kernel AS)
AS Layer2 : FileAddressSpace
(/var/lib/libvirt/qemu/save/win-3584.ram)
PAE type : PAE
DTB : 0x187000L
KDBG : 0xf800017fb0a0
Number of Processors : 2
Image Type (Service Pack) : 1
KPCR for CPU 0 : 0xfffff800017fcd00L
KPCR for CPU 1 : 0xfffff880009b8000L
KUSER_SHARED_DATA : 0xfffff78000000000L
Image date and time : 2013-07-16 12:24:50 UTC+0000
Image local date and time : 2013-07-16 12:24:50 +0000
Offset(V) Name PID PPID Thds Hnds
Sess Wow64 Start Exit
------------------ -------------------- ------ ------ ------ --------
------ ------ ------------------------------
------------------------------
0xfffffa8002a7cb30 System 4 0 70 396
------ 0 2013-07-16 12:24:33 UTC+0000
0xfffffa80030f09d0 smss.exe 220 4 4 31
------ 0 2013-07-16 12:24:33 UTC+0000
0xfffffa80034574d0 csrss.exe 300 292 9 339
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003465b30 wininit.exe 352 292 7 93
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003469b30 csrss.exe 368 344 8 76
1 0 2013-07-16 12:24:34 UTC+0000
0xfffffa800349c280 winlogon.exe 412 344 5 83
1 0 2013-07-16 12:24:34 UTC+0000
0xfffffa80034a7160 services.exe 448 352 17 215
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa80034b4b30 lsass.exe 464 352 9 458
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa80034b64f0 lsm.exe 472 352 12 194
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa800350cb30 svchost.exe 584 448 17 355
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003522060 svchost.exe 664 448 13 221
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003547060 svchost.exe 724 448 16 312
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003552b30 LogonUI.exe 744 412 8 157
1 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003572b30 svchost.exe 812 448 43 782
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa8003594b30 svchost.exe 856 448 14 234
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa800359b9b0 svchost.exe 900 448 8 128
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa80035b3060 svchost.exe 940 448 19 361
0 0 2013-07-16 12:24:34 UTC+0000
0xfffffa80035fcb30 svchost.exe 372 448 16 259
0 0 2013-07-16 12:24:35 UTC+0000
0xfffffa80035f6b30 spoolsv.exe 1048 448 8 89
0 0 2013-07-16 12:24:35 UTC+0000
0xfffffa8003679650 blnsvr.exe 1076 448 7 100
0 0 2013-07-16 12:24:35 UTC+0000
0xfffffa80035e5450 svchost.exe 1116 448 4 50
0 0 2013-07-16 12:24:35 UTC+0000
0xfffffa8003732b30 WmiPrvSE.exe 1364 584 15 294
0 0 2013-07-16 12:24:35 UTC+0000
0xfffffa8003767250 svchost.exe 1484 448 12 241
0 0 2013-07-16 12:24:35 UTC+0000
0xfffffa80037df620 WmiApSrv.exe 1684 448 7 112
0 0 2013-07-16 12:24:36 UTC+0000
0xfffffa80037a56c0 WmiPrvSE.exe 1716 584 7 105
0 0 2013-07-16 12:24:36 UTC+0000
0xfffffa8003763270 WmiPrvSE.exe 1764 584 7 175
0 0 2013-07-16 12:24:38 UTC+0000
VM memory size: 3588 MB
Determining profile based on KDBG search...
Suggested Profile(s) : Win2008R2SP0x64, Win7SP1x64,
Win7SP0x64, Win2008R2SP1x64
AS Layer1 : AMD64PagedMemory (Kernel AS)
AS Layer2 : FileAddressSpace
(/var/lib/libvirt/qemu/save/win-3588.ram)
PAE type : PAE
DTB : 0x187000L
KDBG : 0xf8000180e0a0
Number of Processors : 2
Image Type (Service Pack) : 1
KPCR for CPU 0 : 0xfffff8000180fd00L
KPCR for CPU 1 : 0xfffff880009b8000L
KUSER_SHARED_DATA : 0xfffff78000000000L
Image date and time : 2013-07-16 12:50:59 UTC+0000
Image local date and time : 2013-07-16 12:50:59 +0000
Offset(V) Name PID PPID Thds Hnds
Sess Wow64 Start Exit
------------------ -------------------- ------ ------ ------ --------
------ ------ ------------------------------
------------------------------
0xfffffa800308d9e0 System 4 0 68 275
------ 0 2013-07-16 12:50:55 UTC+0000
VM memory size: 3840 MB
Determining profile based on KDBG search...
Suggested Profile(s) : Win2008R2SP0x64, Win7SP1x64,
Win7SP0x64, Win2008R2SP1x64
AS Layer1 : AMD64PagedMemory (Kernel AS)
AS Layer2 : FileAddressSpace
(/var/lib/libvirt/qemu/save/win-3840.ram)
PAE type : PAE
DTB : 0x187000L
KDBG : 0xf800018400a0
Number of Processors : 1
Image Type (Service Pack) : 1
KPCR for CPU 0 : 0xfffff80001841d00L
KUSER_SHARED_DATA : 0xfffff78000000000L
Image date and time : 2013-07-16 12:28:55 UTC+0000
Image local date and time : 2013-07-16 12:28:55 +0000
Offset(V) Name PID PPID Thds Hnds
Sess Wow64 Start Exit
------------------ -------------------- ------ ------ ------ --------
------ ------ ------------------------------
------------------------------
0xfffffa80033849e0 System 4 0 72 --------
------ 0 2013-07-16 12:28:47 UTC+0000
vol-users,
During last year's OMFW, I gave a presentation on a new Volatility plugin
called dumpfiles[1]. This plugin automates the process of extracting both
memory mapped and cached files. While we have distributed early versions
of the plugin in the Volatility training classes, we are in the final
stages of testing for its inclusion in the upcoming 2.3 release. If you
have some cycles and interest in helping us test, please send me a note
off-list.
Thanks,
AW
PS: Special thanks to Ikelos, MHL, Gleeda, attc, and Carl Pulley for their
help with earlier versions!
[1] http://volatility-labs.blogspot.com/2012/10/movp-44-cache-rules-everything-…
We are writing to announce that our upcoming Amsterdam class is
completely sold out and that our next public training will be in
Reston, VA in November. We have a blog post on the Reston training
here:
http://volatility-labs.blogspot.com/2013/06/memory-forensics-training-resto…
This will be our last public training of 2013 and we are actively
planning 2014 trainings. These will be announced when they are ready.
Our last Reston class sold out a full month in advance so please
contact us ASAP if you would like to attend.
Volatility Community,
If you are planning to attend the Open Memory Forensics Workshop 2013, I
would suggest registering soon. We only have a limited number of seats
remaining:
https://www.volatilityfoundation.org/default/omfw
PS: The only way to reserve a seat is by emailing:
info [at] volatilesystems [dot] com
Thanks,
AAron Walters
The Volatility Foundation
Juerg,
*Or are you saying that I need to shift everything resulting in a file that
is bigger than the actual physical RAM size of the VM?*
Yes. Physical address space is always bigger than physical RAM because it
contains device memory (
http://blogs.technet.com/blogfiles/markrussinovich/WindowsLiveWriter/Pushin…
).
*In my testing with Win 2008 R2 SP1 x64 I found that (see full outputs
below):*
*1) imageinfo and pslist return the correct output for VMs with less than
3588 MB
2) pslist only returns a single task (System) for VMs larger than 3587 MB*
I think important structure used by pslist are usually map over 0x100000000
on Windows 7/2008 with more that 3.5GB (approximately, depending on the
hardware installed).
During my (limited) tests, I was not able to run pslist on those OS without
the proper padding of my vmem files:
https://volatility.googlecode.com/issues/attachment?aid=2720017001&name=Vme…
Sebastien
On Wed, Aug 7, 2013 at 12:06 PM, Juerg Haefliger <juergh(a)gmail.com> wrote:
> Hi Sebastien,
>
>
> > Hello Juerg,
> >
> > Your issues seems to be similar to the one I had with VmWare
> Workstation. To
> > solve the problem, I have wrote a vmem address space that use vmss
> metadata
> > to pad the hardware range:
> >
> > https://code.google.com/p/volatility/issues/detail?id=272#c17
>
> I read through that email chain but don't claim to understand it all.
>
>
> > Maybe you need to do something similar with KVM.
> >
> > It depends on the hardware installed on your PC, but most of the time
> (on my
> > PCs), the range to pad was between 0xC0000000 - 0x100000000
>
> Hmm... The KVM file contains page addresses that I use to seek in the
> output file. If there are no pages for the 0xc000000 - 0x10000000
> range than that part of the output file will just contain garbage. Or
> are you saying that I need to shift everything resulting in a file
> that is bigger than the actual physical RAM size of the VM?
>
> ...Juerg
>
>
> > Sebastien
> >
> > On Wed, Aug 7, 2013 at 7:20 AM, Juerg Haefliger <juergh(a)gmail.com>
> wrote:
> >>
> >> Hi all,
> >>
> >> I wrote a little tool to convert a KVM/libvirt dump to a raw memory
> >> file (https://github.com/juergh/lqs2mem) Volatility seems to be able
> >> to handle the resulting file just fine for small dumps but not so much
> >> the larger they get. Specifically, things start to break when the
> >> memory size of the VM approaches 4 GB. I double and triple checked my
> >> code and can't find anything obviously wrong (like using a 32bit
> >> variable for a 64bit address or pointer). I also don't think that
> >> Volatility has a problem with larger dumps since it can handle a 8 GB
> >> memory dump that I obtained using some other means. I'm just running
> >> out of ideas and am looking for some help or suggestions on how to
> >> debug this further.
> >>
> >> In my testing with Win 2008 R2 SP1 x64 I found that (see full outputs
> >> below):
> >>
> >> 1) imageinfo and pslist return the correct output for VMs with less than
> >> 3588 MB
> >> 2) pslist only returns a single task (System) for VMs larger than 3587
> MB
> >> 3) imageinfo shows only 1 processor (when there are actually two) for
> >> VMs larger than 3712 MB (give or take)
> >>
> >> Any help is greatly appreciated.
> >>
> >> Thanks
> >> ...Juerg
> >>
> >>
> >>
> >>
> >> VM memory size: 3584 MB:
> >>
> >> Determining profile based on KDBG search...
> >>
> >> Suggested Profile(s) : Win2008R2SP0x64, Win7SP1x64,
> >> Win7SP0x64, Win2008R2SP1x64
> >> AS Layer1 : AMD64PagedMemory (Kernel AS)
> >> AS Layer2 : FileAddressSpace
> >> (/var/lib/libvirt/qemu/save/win-3584.ram)
> >> PAE type : PAE
> >> DTB : 0x187000L
> >> KDBG : 0xf800017fb0a0
> >> Number of Processors : 2
> >> Image Type (Service Pack) : 1
> >> KPCR for CPU 0 : 0xfffff800017fcd00L
> >> KPCR for CPU 1 : 0xfffff880009b8000L
> >> KUSER_SHARED_DATA : 0xfffff78000000000L
> >> Image date and time : 2013-07-16 12:24:50 UTC+0000
> >> Image local date and time : 2013-07-16 12:24:50 +0000
> >>
> >> Offset(V) Name PID PPID Thds Hnds
> >> Sess Wow64 Start Exit
> >> ------------------ -------------------- ------ ------ ------ --------
> >> ------ ------ ------------------------------
> >> ------------------------------
> >> 0xfffffa8002a7cb30 System 4 0 70 396
> >> ------ 0 2013-07-16 12:24:33 UTC+0000
> >> 0xfffffa80030f09d0 smss.exe 220 4 4 31
> >> ------ 0 2013-07-16 12:24:33 UTC+0000
> >> 0xfffffa80034574d0 csrss.exe 300 292 9 339
> >> 0 0 2013-07-16 12:24:34 UTC+0000
> >> 0xfffffa8003465b30 wininit.exe 352 292 7 93
> >> 0 0 2013-07-16 12:24:34 UTC+0000
> >> 0xfffffa8003469b30 csrss.exe 368 344 8 76
> >> 1 0 2013-07-16 12:24:34 UTC+0000
> >> 0xfffffa800349c280 winlogon.exe 412 344 5 83
> >> 1 0 2013-07-16 12:24:34 UTC+0000
> >> 0xfffffa80034a7160 services.exe 448 352 17 215
> >> 0 0 2013-07-16 12:24:34 UTC+0000
> >> 0xfffffa80034b4b30 lsass.exe 464 352 9 458
> >> 0 0 2013-07-16 12:24:34 UTC+0000
> >> 0xfffffa80034b64f0 lsm.exe 472 352 12 194
> >> 0 0 2013-07-16 12:24:34 UTC+0000
> >> 0xfffffa800350cb30 svchost.exe 584 448 17 355
> >> 0 0 2013-07-16 12:24:34 UTC+0000
> >> 0xfffffa8003522060 svchost.exe 664 448 13 221
> >> 0 0 2013-07-16 12:24:34 UTC+0000
> >> 0xfffffa8003547060 svchost.exe 724 448 16 312
> >> 0 0 2013-07-16 12:24:34 UTC+0000
> >> 0xfffffa8003552b30 LogonUI.exe 744 412 8 157
> >> 1 0 2013-07-16 12:24:34 UTC+0000
> >> 0xfffffa8003572b30 svchost.exe 812 448 43 782
> >> 0 0 2013-07-16 12:24:34 UTC+0000
> >> 0xfffffa8003594b30 svchost.exe 856 448 14 234
> >> 0 0 2013-07-16 12:24:34 UTC+0000
> >> 0xfffffa800359b9b0 svchost.exe 900 448 8 128
> >> 0 0 2013-07-16 12:24:34 UTC+0000
> >> 0xfffffa80035b3060 svchost.exe 940 448 19 361
> >> 0 0 2013-07-16 12:24:34 UTC+0000
> >> 0xfffffa80035fcb30 svchost.exe 372 448 16 259
> >> 0 0 2013-07-16 12:24:35 UTC+0000
> >> 0xfffffa80035f6b30 spoolsv.exe 1048 448 8 89
> >> 0 0 2013-07-16 12:24:35 UTC+0000
> >> 0xfffffa8003679650 blnsvr.exe 1076 448 7 100
> >> 0 0 2013-07-16 12:24:35 UTC+0000
> >> 0xfffffa80035e5450 svchost.exe 1116 448 4 50
> >> 0 0 2013-07-16 12:24:35 UTC+0000
> >> 0xfffffa8003732b30 WmiPrvSE.exe 1364 584 15 294
> >> 0 0 2013-07-16 12:24:35 UTC+0000
> >> 0xfffffa8003767250 svchost.exe 1484 448 12 241
> >> 0 0 2013-07-16 12:24:35 UTC+0000
> >> 0xfffffa80037df620 WmiApSrv.exe 1684 448 7 112
> >> 0 0 2013-07-16 12:24:36 UTC+0000
> >> 0xfffffa80037a56c0 WmiPrvSE.exe 1716 584 7 105
> >> 0 0 2013-07-16 12:24:36 UTC+0000
> >> 0xfffffa8003763270 WmiPrvSE.exe 1764 584 7 175
> >> 0 0 2013-07-16 12:24:38 UTC+0000
> >>
> >>
> >> VM memory size: 3588 MB
> >>
> >> Determining profile based on KDBG search...
> >>
> >> Suggested Profile(s) : Win2008R2SP0x64, Win7SP1x64,
> >> Win7SP0x64, Win2008R2SP1x64
> >> AS Layer1 : AMD64PagedMemory (Kernel AS)
> >> AS Layer2 : FileAddressSpace
> >> (/var/lib/libvirt/qemu/save/win-3588.ram)
> >> PAE type : PAE
> >> DTB : 0x187000L
> >> KDBG : 0xf8000180e0a0
> >> Number of Processors : 2
> >> Image Type (Service Pack) : 1
> >> KPCR for CPU 0 : 0xfffff8000180fd00L
> >> KPCR for CPU 1 : 0xfffff880009b8000L
> >> KUSER_SHARED_DATA : 0xfffff78000000000L
> >> Image date and time : 2013-07-16 12:50:59 UTC+0000
> >> Image local date and time : 2013-07-16 12:50:59 +0000
> >>
> >> Offset(V) Name PID PPID Thds Hnds
> >> Sess Wow64 Start Exit
> >> ------------------ -------------------- ------ ------ ------ --------
> >> ------ ------ ------------------------------
> >> ------------------------------
> >> 0xfffffa800308d9e0 System 4 0 68 275
> >> ------ 0 2013-07-16 12:50:55 UTC+0000
> >>
> >>
> >> VM memory size: 3840 MB
> >>
> >> Determining profile based on KDBG search...
> >>
> >> Suggested Profile(s) : Win2008R2SP0x64, Win7SP1x64,
> >> Win7SP0x64, Win2008R2SP1x64
> >> AS Layer1 : AMD64PagedMemory (Kernel AS)
> >> AS Layer2 : FileAddressSpace
> >> (/var/lib/libvirt/qemu/save/win-3840.ram)
> >> PAE type : PAE
> >> DTB : 0x187000L
> >> KDBG : 0xf800018400a0
> >> Number of Processors : 1
> >> Image Type (Service Pack) : 1
> >> KPCR for CPU 0 : 0xfffff80001841d00L
> >> KUSER_SHARED_DATA : 0xfffff78000000000L
> >> Image date and time : 2013-07-16 12:28:55 UTC+0000
> >> Image local date and time : 2013-07-16 12:28:55 +0000
> >>
> >> Offset(V) Name PID PPID Thds Hnds
> >> Sess Wow64 Start Exit
> >> ------------------ -------------------- ------ ------ ------ --------
> >> ------ ------ ------------------------------
> >> ------------------------------
> >> 0xfffffa80033849e0 System 4 0 72 --------
> >> ------ 0 2013-07-16 12:28:47 UTC+0000
> >> _______________________________________________
> >> Vol-users mailing list
> >> Vol-users(a)volatilityfoundation.org
> >> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
> >
> >
>
Hi All
Apologies if this has been addressed already but can't find it in the
archives. Is volatility able to verify image signatures similar to how
process monitor can? Suspect the answer is no as it's not a live system and
may not be running under windows. None of the plugins seem to be able to do
this from what I can see, just want to check I'm not missing something.
Cheers
Ben
Hi all,
I'v have a memory dump has an evidence for a case.
Volatility can help me to discover "Alternate data stream" file on the system?
Thanks for your help!
Hey all,
Has anyone already made profiles for the memory dumps at
http://secondlookforensics.com/linux-memory-images/ ? I'm interested
in both the new ones (june 2013) and the old ones.
I know how to make profiles, but you'd save me quite a lot of time if
you already have some <3
Cheers,
Edwin
Hello,
As part of an assignment for a security and privacy class I am taking I need to determine the ip address of a windowsXP system whose memory dump I have. Actually, it is the zeus.vmem dump from the volatility dump images download page.
I have done a lot of searching in google, but haven't been able to find much about hwo to get this information.
I tried the technique outlined at:
http://code.google.com/p/volatility/wiki/CommandReference
in the area concerning strings.
When I use the perl script provided the only obvious ip address is 172.16.176.143 which is a private network address. My assignment is to determine the country of origin of the ip address, but so far I see no addresses which are not private addresses.
Does anyone have any suggestions on how to proceed with finding the system's ip address?
--
Best Regards, Donald
HYPERLINK "http://www.oracle.com/" \nOracle
Donald raikes | Accessibility Specialist/ QA Engineer
Phone: HYPERLINK "tel:+15202717608"+15202717608 | Mobile: HYPERLINK "tel:+15202717608"+15202717608
Oracle Quality Assurance
| Tucson, Arizona
HYPERLINK "http://www.oracle.com/commitment" \nGreen Oracle
Oracle is committed to developing practices and products that help protect the environment
Is there a Linux profile for RedHat for the latest version of volatility?
I am attempting to run pslist against a VM running Redhat. However, I am
having no luck. I used imagecopy to convert a .vmss and a .vmsn file to a
memory dump file. Neither file works with pslist. I used the CentOS
profile and the results are below. If I don't specify a profile, you don't
see the "invalid pde_value" lines. Any ideas?
> python vol.py --profile=LinuxCentOS63x64 -f serverName_vmsn.raw
linux_pslist
Volatile Systems Volatility Framework 2.3_beta
*** Failed to import volatility.plugins.addrspaces.legacyintel
(AttributeError: 'module' object has no attribute
'AbstractWritablePagedMemory')
WARNING : volatility.obj : Overlay structure tty_struct not present in
vtypes
Offset Name Pid Uid
Gid DTB Start Time
------------------ -------------------- --------------- ---------------
------ ------------------ ----------
WARNING : volatility.plugins.addrspaces.arm: get_pte: invalid pde_value
65d70100
WARNING : volatility.plugins.addrspaces.arm: get_pte: invalid pde_value
65d70100
WARNING : volatility.plugins.addrspaces.arm: get_pte: invalid pde_value
65d70100
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
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
AMD64PagedMemory: Failed valid Address Space check
IA32PagedMemoryPae: Incompatible profile LinuxCentOS63x64 selected
IA32PagedMemory: Incompatible profile LinuxCentOS63x64 selected
FileAddressSpace: Must be first Address Space
ArmAddressSpace: Failed valid Address Space check
We are excited to announce that the registration for the 4th annual OMFW
is officially open. The workshop will be held on November 4, 2013 and will
coincide with the Open Source Digital Forensics Conference. OMFW is the
single most important event for those who are interested in pushing the
state of the art of digital forensics and incident response. If you are
interested in getting involved or have an exciting memory related topic
that you would like to share with the digital forensics community, please
let the team know. For those interested in attending, please see the
official website for details:
https://www.volatilityfoundation.org/default/omfw
Due to the overwhelming response in previous year, we were not able to
fulfill all the registration requests, so please be sure to register
early! Check out what previous attendees of OMFW have said:
"The OMFW was well mind blowing for the most part. The amount of
knowledge the Volatility guys (and girl) have is insane."
Glenn P. Edwards Jr.
"For the last four years the Open Source Memory Forensics Workshop
(OMFW) has hosted a collective whos who of memory forensics and provided
a forum in which to discuss the latest advances and tools."
Mike Webber
"AAron was able to bring together an outstanding group of folks
interested in memory forensics" and there was some spirited discussion
among the participants along with some really outstanding talks/demos. It
was also great to be able to put faces to folks who until then had only
been handles in IRC or names on e-mail/blog posts in the past."
Jim Clausing
"My first impression of the event was that the underground could have
set digital forensics back 3-5 years if they had attacked our small
conference room. Where else do you have Eoghan Casey, Brian Carrier,
Harlan Carvey, Michael Cohen, Brendan Dolan-Gavitt, George Garner Jr.,
Andreas Schuster, Aaron Walters, et al, in the same room? I thought Brian
Dykstra framed the situation properly when asking the following: I know
this is an easy question for all you beautiful minds, but""
Richard Bejtlich
REMINDER: If you are planning to submit to the Volatility Framework Plugin
Contest, please make sure your entry is submitted before August 1, 2013.
It is a great platform for getting visibility and other people interested
in your exciting memory analysis projects.
AAron Walters
Volatility Foundation
Hi all,
I am having a problem reading certain values in an address space. I
know for certain that the range I am trying to read is mapped, i.e.
there is a vma for it.
The specific range in this case is shown in the vma list as this:
1206 0x00007faf9d98f000 0x00007faf9db4d000 r-x 0x0
8 1 241 /lib/x86_64-linux-gnu/libc-2.17.so
The offset in this range that I am trying to read is 0x21e9b = 0x7faf9d9b0e9b
the call may look like this: proc_as.read(0x7faf9d9b0e9b, 10)
and it will return None, meaning it could not read that address.
Using the linux_dump_map I exported the whole range and there's a
pretty big empty (inaccessible) chunk in the middle, which appears as
0-bytes in the export. I know for a fact that my libc does not have a
big area of 0-bytes, so this is pretty weird. It also works just fine
for other processes in the same dump (so using the same libc).
For research purposes I make my memory dumps with virtualbox, so I
don't think it's an issue with memory corruption; as far as i can
tell, virtualbox makes complete snapshots.
Does anyone know what might cause this problem?
Cheers,
Edwin
Dear Everyone:
I have a problem about analysing an android memory these days.
I am new to android memory forensic,and i analyse the windows memory before.But i think analysing an android memory may more interesting and valuable.
I have followed the url "https://code.google.com/p/volatility/wiki/AndroidMemoryForensics#Build_a_Vo…" ,and i have done successfully.
Now, by useing lime i can get my android memory, my android is samsung9001, and the memory file is ram.lime (almost 400M size).
But the problem is that: when i use volatility2.3_beta to analyse the android memory , volatility can't identify the profle that i created.
The output is below：
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 LinuxGolfishARM 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
and i use -dd option the output is:
yutruth@ubuntu:~/yutruth-android/volatility$ python vol.py --profile=Linuxsamsung9001ARM -f ~/yutruth-android/ram.lime linux_pslist -dd
Volatile Systems Volatility Framework 2.3_beta
DEBUG : volatility.plugins.overlays.linux.linux: samsung9001: Found dwarf file home/yutruth/yutruth-android/samsung9001-source/kernel/System.map with 407 symbols
DEBUG : volatility.plugins.overlays.linux.linux: samsung9001: Found system file home/yutruth/yutruth-android/samsung9001-source/kernel/System.map with 1 symbols
DEBUG : volatility.obj : Applying modification from BashTypes
DEBUG : volatility.obj : Applying modification from BasicObjectClasses
DEBUG : volatility.obj : Applying modification from ELF64Modification
DEBUG : volatility.obj : Applying modification from HPAKVTypes
DEBUG : volatility.obj : Applying modification from LimeTypes
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 LinuxKmemCacheOverlay
DEBUG : volatility.obj : Applying modification from LinuxMountOverlay
DEBUG : volatility.obj : Applying modification from LinuxObjectClasses
DEBUG : volatility.obj : Applying modification from LinuxOverlay
Offset Name Pid Uid Gid DTB Start Time
---------- -------------------- --------------- --------------- ------ ---------- ----------
DEBUG : volatility.utils : Voting round
DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.macho.MachOAddressSpace'>
DEBUG1 : volatility.utils : Failed instantiating MachOAddressSpace: mac: need base
DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.lime.LimeAddressSpace'>
DEBUG1 : volatility.utils : Failed instantiating LimeAddressSpace: lime: need base
DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.hibernate.WindowsHiberFileSpace32'>
DEBUG1 : volatility.utils : Failed instantiating WindowsHiberFileSpace32: No base Address Space
DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace64'>
DEBUG1 : volatility.utils : Failed instantiating WindowsCrashDumpSpace64: No base Address Space
DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.hpak.HPAKAddressSpace'>
DEBUG1 : volatility.utils : Failed instantiating HPAKAddressSpace: No base Address Space
DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.vboxelf.VirtualBoxCoreDumpElf64'>
DEBUG1 : volatility.utils : Failed instantiating VirtualBoxCoreDumpElf64: No base Address Space
DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.vmware.VMWareSnapshotFile'>
DEBUG1 : volatility.utils : Failed instantiating VMWareSnapshotFile: No base Address Space
DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace32'>
DEBUG1 : volatility.utils : Failed instantiating WindowsCrashDumpSpace32: No base Address Space
DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.amd64.AMD64PagedMemory'>
DEBUG1 : volatility.utils : Failed instantiating AMD64PagedMemory: No base Address Space
DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.intel.IA32PagedMemoryPae'>
DEBUG1 : volatility.utils : Failed instantiating IA32PagedMemoryPae: No base Address Space
DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.intel.IA32PagedMemory'>
DEBUG1 : volatility.utils : Failed instantiating IA32PagedMemory: No base Address Space
DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.standard.FileAddressSpace'>
DEBUG : volatility.utils : Succeeded instantiating <volatility.plugins.addrspaces.standard.FileAddressSpace object at 0x6949190>
DEBUG : volatility.utils : Voting round
DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.macho.MachOAddressSpace'>
DEBUG1 : volatility.utils : Failed instantiating MachOAddressSpace: MachO Header signature invalid
DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.lime.LimeAddressSpace'>
DEBUG1 : volatility.obj : None object instantiated: Invalid Address 0x18600040, instantiating lime_header
DEBUG : volatility.utils : Succeeded instantiating <volatility.plugins.addrspaces.lime.LimeAddressSpace object at 0x6949150>
DEBUG : volatility.utils : Voting round
DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.macho.MachOAddressSpace'>
DEBUG1 : volatility.utils : Failed instantiating MachOAddressSpace: MachO Header signature invalid
DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.lime.LimeAddressSpace'>
DEBUG1 : volatility.utils : Failed instantiating LimeAddressSpace: Invalid Lime header signature
DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.hibernate.WindowsHiberFileSpace32'>
DEBUG1 : volatility.utils : Failed instantiating WindowsHiberFileSpace32: PO_MEMORY_IMAGE is not available in profile
DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace64'>
DEBUG1 : volatility.utils : Failed instantiating WindowsCrashDumpSpace64: Header signature invalid
DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.hpak.HPAKAddressSpace'>
DEBUG1 : volatility.utils : Failed instantiating HPAKAddressSpace: Invalid magic found
DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.vboxelf.VirtualBoxCoreDumpElf64'>
DEBUG1 : volatility.utils : Failed instantiating VirtualBoxCoreDumpElf64: ELF64 Header signature invalid
DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.vmware.VMWareSnapshotFile'>
DEBUG1 : volatility.utils : Failed instantiating VMWareSnapshotFile: Invalid VMware signature: 0x0
DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace32'>
DEBUG1 : volatility.utils : Failed instantiating WindowsCrashDumpSpace32: Header signature invalid
DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.amd64.AMD64PagedMemory'>
DEBUG1 : volatility.utils : Failed instantiating AMD64PagedMemory: Incompatible profile Linuxsamsung9001ARM selected
DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.intel.IA32PagedMemoryPae'>
DEBUG1 : volatility.utils : Failed instantiating IA32PagedMemoryPae: Failed valid Address Space check
DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.intel.IA32PagedMemory'>
DEBUG1 : volatility.utils : Failed instantiating IA32PagedMemory: Failed valid Address Space check
DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.standard.FileAddressSpace'>
DEBUG1 : volatility.utils : Failed instantiating FileAddressSpace: Must be first Address Space
DEBUG : volatility.utils : Trying <class 'volatility.plugins.addrspaces.arm.ArmAddressSpace'>
DEBUG1 : volatility.obj : None object instantiated: No suggestions available
DEBUG1 : volatility.utils : Failed instantiating ArmAddressSpace: Failed valid Address Space check
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 Linuxsamsung9001ARM 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
Search the problem by google and i find some others have the same problem,but i can't find the solution. By the way, i know few people submit the problem last September and a week ago, and i know volatility can't support many Linux/android profile now, but i have create the profile for my android and just volatility can't identify:-(
I do these things under the ubuntu10.04 on the vmware, and i don't download the newest dwarfdump, i just use " apt-get install dwarfdump" on the ubuntu10.04, and i am sure the CC_PATH and some PATH Variable is true. I may think the dwarf execute file is wrong.
Thanks for your attention and sorry for my english. The attachment are my profile zip and dwarfdump execute file.
Hope to get your apply soon ^_^( I may be mad for the problem)
------------------
best wishes
yutruth
Dear everyone:
I have a problem about analysing an android memory these days.
I am new to android memory forensic,and i analyse the windows
memory before.But i think analysing an android memory may more interesting
and valuable.
I have followed the url "https://code.google.com/p/volatility/wiki/
AndroidMemoryForensics#Build_a_Volatility_Profile" ,and i have done
successfully.
Now, by useing lime i can get my android memory, my android is
samsung9001, and the memory file is ram.lime (almost 400M size).
But the problem is that: when i use volatility2.3_beta to analyse
the android memory , volatility can't identify the profle that i created.
The output is below：
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 LinuxGolfishARM 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
and i use -dd option the output is:
yutruth@ubuntu:~/yutruth-android/volatility$ python vol.py
--profile=Linuxsamsung9001ARM -f ~/yutruth-android/ram.lime linux_pslist
-dd
Volatile Systems Volatility Framework 2.3_beta
DEBUG : volatility.plugins.overlays.linux.linux: samsung9001: Found dwarf
file home/yutruth/yutruth-android/samsung9001-source/kernel/System.map with
407 symbols
DEBUG : volatility.plugins.overlays.linux.linux: samsung9001: Found
system file
home/yutruth/yutruth-android/samsung9001-source/kernel/System.map with 1
symbols
DEBUG : volatility.obj : Applying modification from BashTypes
DEBUG : volatility.obj : Applying modification from
BasicObjectClasses
DEBUG : volatility.obj : Applying modification from ELF64Modification
DEBUG : volatility.obj : Applying modification from HPAKVTypes
DEBUG : volatility.obj : Applying modification from LimeTypes
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
LinuxKmemCacheOverlay
DEBUG : volatility.obj : Applying modification from LinuxMountOverlay
DEBUG : volatility.obj : Applying modification from
LinuxObjectClasses
DEBUG : volatility.obj : Applying modification from LinuxOverlay
Offset Name Pid Uid Gid
DTB Start Time
---------- -------------------- --------------- --------------- ------
---------- ----------
DEBUG : volatility.utils : Voting round
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.macho.MachOAddressSpace'>
DEBUG1 : volatility.utils : Failed instantiating MachOAddressSpace:
mac: need base
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.lime.LimeAddressSpace'>
DEBUG1 : volatility.utils : Failed instantiating LimeAddressSpace:
lime: need base
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.hibernate.WindowsHiberFileSpace32'>
DEBUG1 : volatility.utils : Failed instantiating
WindowsHiberFileSpace32: No base Address Space
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace64'>
DEBUG1 : volatility.utils : Failed instantiating
WindowsCrashDumpSpace64: No base Address Space
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.hpak.HPAKAddressSpace'>
DEBUG1 : volatility.utils : Failed instantiating HPAKAddressSpace: No
base Address Space
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.vboxelf.VirtualBoxCoreDumpElf64'>
DEBUG1 : volatility.utils : Failed instantiating
VirtualBoxCoreDumpElf64: No base Address Space
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.vmware.VMWareSnapshotFile'>
DEBUG1 : volatility.utils : Failed instantiating VMWareSnapshotFile: No
base Address Space
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace32'>
DEBUG1 : volatility.utils : Failed instantiating
WindowsCrashDumpSpace32: No base Address Space
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.amd64.AMD64PagedMemory'>
DEBUG1 : volatility.utils : Failed instantiating AMD64PagedMemory: No
base Address Space
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.intel.IA32PagedMemoryPae'>
DEBUG1 : volatility.utils : Failed instantiating IA32PagedMemoryPae: No
base Address Space
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.intel.IA32PagedMemory'>
DEBUG1 : volatility.utils : Failed instantiating IA32PagedMemory: No
base Address Space
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.standard.FileAddressSpace'>
DEBUG : volatility.utils : Succeeded instantiating
<volatility.plugins.addrspaces.standard.FileAddressSpace object at
0x6949190>
DEBUG : volatility.utils : Voting round
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.macho.MachOAddressSpace'>
DEBUG1 : volatility.utils : Failed instantiating MachOAddressSpace:
MachO Header signature invalid
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.lime.LimeAddressSpace'>
DEBUG1 : volatility.obj : None object instantiated: Invalid Address
0x18600040, instantiating lime_header
DEBUG : volatility.utils : Succeeded instantiating
<volatility.plugins.addrspaces.lime.LimeAddressSpace object at 0x6949150>
DEBUG : volatility.utils : Voting round
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.macho.MachOAddressSpace'>
DEBUG1 : volatility.utils : Failed instantiating MachOAddressSpace:
MachO Header signature invalid
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.lime.LimeAddressSpace'>
DEBUG1 : volatility.utils : Failed instantiating LimeAddressSpace:
Invalid Lime header signature
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.hibernate.WindowsHiberFileSpace32'>
DEBUG1 : volatility.utils : Failed instantiating
WindowsHiberFileSpace32: PO_MEMORY_IMAGE is not available in profile
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace64'>
DEBUG1 : volatility.utils : Failed instantiating
WindowsCrashDumpSpace64: Header signature invalid
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.hpak.HPAKAddressSpace'>
DEBUG1 : volatility.utils : Failed instantiating HPAKAddressSpace:
Invalid magic found
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.vboxelf.VirtualBoxCoreDumpElf64'>
DEBUG1 : volatility.utils : Failed instantiating
VirtualBoxCoreDumpElf64: ELF64 Header signature invalid
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.vmware.VMWareSnapshotFile'>
DEBUG1 : volatility.utils : Failed instantiating VMWareSnapshotFile:
Invalid VMware signature: 0x0
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.crash.WindowsCrashDumpSpace32'>
DEBUG1 : volatility.utils : Failed instantiating
WindowsCrashDumpSpace32: Header signature invalid
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.amd64.AMD64PagedMemory'>
DEBUG1 : volatility.utils : Failed instantiating AMD64PagedMemory:
Incompatible profile Linuxsamsung9001ARM selected
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.intel.IA32PagedMemoryPae'>
DEBUG1 : volatility.utils : Failed instantiating IA32PagedMemoryPae:
Failed valid Address Space check
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.intel.IA32PagedMemory'>
DEBUG1 : volatility.utils : Failed instantiating IA32PagedMemory:
Failed valid Address Space check
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.standard.FileAddressSpace'>
DEBUG1 : volatility.utils : Failed instantiating FileAddressSpace: Must
be first Address Space
DEBUG : volatility.utils : Trying <class
'volatility.plugins.addrspaces.arm.ArmAddressSpace'>
DEBUG1 : volatility.obj : None object instantiated: No suggestions
available
DEBUG1 : volatility.utils : Failed instantiating ArmAddressSpace:
Failed valid Address Space check
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 Linuxsamsung9001ARM 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
Search the problem by google and i find some others have the same
problem,but i can't find the solution. By the way, i know few people submit
the problem
last September and a week ago, and i know volatility can't support many
Linux/android profile now, but i have create the profile for my android and
just volatility can't
identify:-(
I do these things under the ubuntu10.04 on the vmware, and i
don't download the newest dwarfdump, i just use " apt-get install
dwarfdump" on the ubuntu10.04,
and i am sure the CC_PATH and some PATH Variable is true. I may think the
dwarf execute file is wrong.
Thinks for your attention and sorry for my english. The
attachment are my profile zip and dwarfdump execute file.
Hope to get your apply soon ^_^( I may be mad for the problem)
Maybe a stupid question here but does Volatility currently support the
analysis of linux memory from a Virtual Machine?
I see that it supports VM's and Linux separately but not together?
Thanks in advance
Lou
After quickly selling out our recent course in Reston, we have now
scheduled another training there in November:
http://volatility-labs.blogspot.com/2013/06/memory-forensics-training-resto…
This course is taught directly by Volatility developers, and provides
intense training in memory forensics for incident response, malware
analysis, and digital forensic investigation.
We already have quite a few people signed up and had to turn away
people last time, so please contact us ASAP if you are interested in
taking it.
Thanks,
Andrew (@attrc)
This post is off-topic; however, there are a lot of bright people on
this list so maybe someone will be able to help. I need to set a static
ipv4 address on an interface in WinPE4.0/WinFE4.0. For example the
following command works on Windows 8:
netsh.exe interface ip set address Ethernet static 192.168.0.5
255.255.255.0
On WinPE 4.0 I am getting an error that the interface is not found which
is odd since the interface appears in the list of interfaces. For example:
netsh.exe interface ip show interfaces
and
netsh.exe interface ip show interface Ethernet
both work as expected.
I can also add a route on the interface in WinPE, e.g.:
netsh.exe interface ip add route 192.168.0.0/24 Ethernet
works. It is just adding the static ip address that doesn't work. I
have also tried using the IF index instead of the interface name; still
no joy. Unfortunately I can't use dhcp in some applications because the
client broadcasts an announcement that I am present, which wouldn't be
prudent.
I am wondering if there isn't maybe some dependency that is missing from
my winpe installation?
Anyone have any thoughts?
Regards,
George.
Hi all,
I'm currently attempting to code up a bitmap (within an overlay) that consists of an array of 4 ulongs.
With (say) a single ulong, the following works great:
profile.merge_overlay({
'XXX': [ None, ['Flags', {'target': 'unsigned long', 'bitmap': { 'A': 0, 'B': 1, 'C': 2 }}]]
})
However, the obvious generalisation to 4 ulongs:
profile.merge_overlay({
'XXX': [ None, ['Flags', {'target': ['array', 4, ['unsigned long']], 'bitmap': { 'A': 0, 'B': 1, 'C': 2 }}]]
})
fails. Looking at the source, the profile.merge_overlay calls:
obj.Object(['array', 4, ['unsigned long']], offset=0, ..)
and this function in turn raises an exception (i.e. TypeError: unhashable type: 'list') when it calls:
vm.profile.has_type(['array', 4, ['unsigned long']])
Attempts at using obj.Array instead also flounder.
Does anyone have any hints or tips as to how best to deal with bitmaps that are arrays of bytes, ulongs or similar? Is it a case of having to extend the obj.Flags class so that such things can be handled?
Many thanks,
Carl.
I look at mostly Win7/64 systems and have always found shimcache data in memory images before. In the last several weeks only about 50% of the images I looked at had it. I'm running a 2.3 alpha build from a month or two ago (have been all this time).
While not strictly a Volatility issue, could someone explain under what circumstances the data wouldn't be available? I'm not a Windows internals expert (yet, I have part 1 and part 2 on my bookshelf, waiting...)
Thanks!
--
chort
Hi everyone,
I would like to ask you if it is possible to dump the hive file from a
memory image.
For some reason the printkey cmd does not return expected values.
In my virtualbox Windows xp sp3 image contains vboxtray.exe in the RUN key,
but I dont see it in the printkey -K
"Software\Microsoft\Windows\CurrentVersion\Run" cmd output
I am using volatility version 2.3 beta.
I want to use Windows registry recovery tool to check if it is able to get
the info I need.
Thank you
Jaro
Hello all,
First congrats on a great tool :)
I'm looking for some iso/distro to be able to do some "coldboot" testing,
and i was thinking on using LiME module.
Does anyone have done anything related to this, like a really small kernel
booting to usb, and dump the mem?
What do you guys use to do memory dumps? (on "real" systems not vm's ?)
Thanks
Thanks both of you for your help and advice. I will try to verify if the memory is allocated. I have to convert the memory image to the crash dmp.
The --base switch works very well. I overlooked it in the help.
Thanks
Jaro
Od: "Michael Hale Ligh" <michael.hale(a)gmail.com<mailto:michael.hale@gmail.com>>
Datum: po, 6. 3, 2013 16:48
Předmět: [Vol-users] DPC procedure localization
Komu: "George M. Garner Jr." <ggarner_online(a)gmgsystemsinc.com<mailto:ggarner_online@gmgsystemsinc.com>>
Kopie: "vol-users" <vol-users(a)volatilesystems.com<mailto:vol-users@volatilesystems.com>>
Thanks for the explanation George!
Jaroslav - to answer your other question "how can I dump this using the
offset 0x80013000?" you can use the moddump plugin with --base= 0x80013000.
MHL
On Mon, Jun 3, 2013 at 10:43 AM, George M. Garner Jr. <
ggarner_online(a)gmgsystemsinc.com<mailto:ggarner_online@gmgsystemsinc.com>> wrote:
> Jaroslav,
>
> Kernel timers come and go at a very high rate which leads to a significant
> number of invalid or spurious timer artifacts which result from the fact
> that the memory dump was acquired from the system while it was running.
> Not that the last two timers are signaled and the periods are not
> coherent. It is possible that the last two "timer" objects reside in
> memory that once was a kernel timer object and has since been freed and
> that some of the timer fields (e.g. the routine address) have been
> overwritten with incoherent data. Try running the !pool command on the
> last two timer addresses (0x863ead10 and 0x85e451e8) and see if that memory
> is currently allocated. (I am assuming that you either have or can convert
> your memory dump to MS crashdump format.)
>
> Regards,
>
> George.
>
>
> On 6/3/2013 9:15 AM, BRTAN Jaroslav wrote:
>
>> Hi all,
>>
>> I'd like to ask you for your help with analysis. The timers module shows
>> that there is a strange DPC at 0x8647e4e0.
>>
>>
>> Timers module output:
>>
>> Offset(V) DueTime Period(ms) Signaled Routine
>> Module
>> ---------- ------------------------ ---------- ---------- ----------
>> ------
>> 0x873097d0 0x0000002f:0x2db9d0c3 0 - 0xa7386d8e
>> arp1394.sys
>> 0x85b9a2c8 0x8000002d:0x6d7d7c8e 0 - 0x80538a98
>> ntoskrnl.exe
>> 0x8a332b20 0x0000002f:0x2ea5d991 0 - 0xb9ddef1a
>> NDIS.sys
>> 0x863ead10 0x00010014:0x863ead28 -205...072 Yes 0x8647e4e0
>> UNKNOWN
>> 0x85e451e8 0x00010014:0x85e45200 -205...072 Yes 0x8647e4e0
>> UNKNOWN
>>
>>
> ______________________________**_________________
> Vol-users mailing list
> Vol-users(a)volatilesystems.com<mailto:Vol-users@volatilesystems.com>
> http://lists.volatilesystems.**com/mailman/listinfo/vol-users<http://lists.volatilesystems.com/mailman/listinfo/vol-users>
>
The information in this message may be proprietary and/or confidential, and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify First Data immediately by replying to this message and deleting it from your computer.
Hello,
We wanted to take the opportunity to point you to a blog post which gives a
preview of some of the research we've been working on at 504ENSICS Labs in
the area of Android memory analysis. This time we are demoing a feature
that will allow automatted volatility plugin generation with our Dalvik
Inspector tool. We think our results will be of great interest to the DFIR
community and look forward to your feed back. We plan on releasing the
tool this year at Black Hat.
The blog post can be found here:
http://www.504ensics.com/automated-volatility-plugin-generation-with-dalvik…
---
*Joe T. Sylve, M.S.*
Co-Founder
504ENSICS Labs
(504) 210-8270 (Office)
http://www.504ensics.com
PGP Key: http://www.504ensics.com/pgp_keys/joesylve.asc
Greetings
I am looking at Win 7 x86 SP1 memory and I dont understand why I am seeing
"established connections" but no PID or Process with it.
0x2d07480 TCPv4 10.22.41.40:58767
38.126.225.229:43405ESTABLISHED -------- --------------
0x1367da70 TCPv4 10.22.41.40:59302
151.213.50.211:22031ESTABLISHED -------- --------------
In addition I am seeing stuff "listening" and it contains the PID and
Process.
0xdb838178 TCPv4 0.0.0.0:49154 0.0.0.0:0
LISTENING 996 svchost.exe
0xdb850ab0 TCPv4 0.0.0.0:49155 0.0.0.0:0
LISTENING 1440 spoolsv.exe
0xdb855e78 TCPv4 0.0.0.0:49155 0.0.0.0:0
LISTENING 1440 spoolsv.exe
So my question is why can I see the listening processes but im not getting
the Process that are established?
Thanks for the help
Lou
For those of you interested in applying memory forensics to your
malware analysis and rootkit detection efforts, we've just posted a
new blog with some exciting news and updates:
http://volatility-labs.blogspot.com/2013/05/whats-happening-in-world-of-vol…
* Volatility 2.3 will enter beta this week and we'll introduce the new
features over the next four weeks (Month of Volatility Plugins II).
* There are three training courses open for registration (Reston in
June, Netherlands in September, Vermont in November). Email
voltraining(a)memoryanalysis.net for details.
* The plugin contest submissions are starting to trickle in. Enter to
win over $2250 in cash or a free seat at an upcoming training.
* This year's Open Memory Forensics Workshop will be in Chantilly VA
on November 4th, alongside OSDFC (Open Source Digital Forensics
Conference). CFP to be announced soon.
All the best,
Jamie / @gleeda
The Volatility Project
--
PGP Fingerprint: 2E87 17A1 EC10 1E3E 11D3 64C2 196B 2AB5 27A4 AC92
We are happy to announce that our memory forensics training course
will be going to the Netherlands in September:
http://volatility-labs.blogspot.com/2013/04/memory-forensics-training-nethe…
This course is taught directly by Volatility developers, and will
provide intense training in memory forensics for incident response,
malware analysis, and digital forensic investigation.
This will be our only course outside of the USA in 2013, and we have
already had a number of people inquire about attending, so please
contact us ASAP if you are interested in taking it.
Thanks,
Andrew (@attrc)
Hi all,
I've just created a profile for my Ubuntu 12.04 (3.5.0-25) and I've
dumped the memory using virtualbox guestcoredump.
Using the linux_proc_maps plugin I get the following output:
http://paste.ubuntu.com/5576450/
I was expecting similar output to "cat /proc/<pid>/maps". As you can
see, these "-0x4...000" addresses are obviously wrong. Is this I am
doing wrong myself, or is this a bug? It happens for other processes
as well.
If this is a bug I'll make a new issue in the tracker with the steps
I've followed to produce this.
Cheers,
Edwin
HI,
There was some talk on the #volatility irc channel.. Won't go into details,
Basically, wondering how one can use vtop from volshell as it is not a
plugin.
thanks
Dear all,
I was hoping that someone might be able to clear up a query I have wrt Windows memory and how it handles memory pages (specifically information regarding the pages executable permissions). I'm assuming that PAE is in use here.
The idea is that we have some page (holding virtual address addr) within a processes address space and wish to know if that page is executable.
Within user space, we can use the VADs and obtain executable information via vad.u.VadFlags.Protection - vadinfo.PROTECT_FLAGS allows the returned value (as an int) to be converted into a string representation.
Within kernel space, we can use the PTE to determine information regarding the pages exec status - for example:
def get_page_nx_bit(addrspace, addr):
pdpte = addrspace.get_pdpte(addr)
pde = addrspace.get_pde(addr, pdpte)
pte = addrspace.get_pte(addr, pde)
return pte >> 63
gets the NX bit for the PTE associated with a given page address.
Now, in comparing bit 63 of the PTE entries against the VAD protection permissions in user space, I'm noticing the occasional difference. Naively, I'd expected the PTEs to agree with the protection information on the VADs (within user space).
Any help or pointers to information resolving the above is very much appreciated.
Many thanks,
Carl.
Thanks Michael. My whole purpose in this instance was to test the nbdserver
project for my blog post. That's why I used this particular method. I'll
follow up with Jeff and let him know what you came up with.
Thanks!
Ken
On Mon, Apr 15, 2013 at 3:51 PM, Michael Cohen <scudette(a)gmail.com> wrote:
> Ah that explains the crash then....
>
> You can not read the entire physical address space from start to finish
> because you will hit DMA regions which will cause your reads to activate
> PCI devices and blue screen the box. You must skip the regions which are
> reserved to PCI devices.
>
> The winpmem device driver allows you to read where ever you want (i.e. it
> does not protect you from shooting yourself in the foot :-). The user space
> application is supposed to figure out where its safe to read. From quickly
> looking at the code for nbdserve
>
> https://github.com/jeffbryner/NBDServer/blob/master/main.cpp
>
> it does not seem to implement the correct algorithm for skipping the
> reserved memory regions (it should make an IO control to the pmem driver
> and ask it). There seems to be some code there to do it but it does not
> seem complete to me. Maybe best ask the author?
>
> Anyway for the purpose of experimenting you could just manually write a
> short bash script with dd involving the skip and seek parameters to skip
> over the reserved regions and only image the available regions. This should
> not crash.
>
> If you goal is just to obtain the image over the network, why not use
> netcat like the example demonstrates?
>
> Thanks,
> Michael.
>
>
>
>
>
> On 15 April 2013 22:34, Ken Pryor <kdpryor(a)gmail.com> wrote:
>
>> Hi Michael,
>>
>> Yes, I ran winpmem on the subject machine and allowed it to save an image
>> file to that machine successfully. In my nbdserver test, I ran winpmem -l
>> and verified the service was running. I went to the nbd Linux client and
>> began the process of imaging pmem from the subject computer via the
>> network. Running nbd-client on the Linux workstation, I assigned the pmem
>> output coming over the network to /dev/nbd0. I used the following command
>> line then to image:
>>
>> dd if=/dev/nbd0 of=./ramoutput.dd
>>
>> This has been successful on 32 bit XP machines, but it dies on the 64 bit
>> machine. If this description doesn't make sense, I'll try to do a better
>> description later this evening.
>>
>> Ken
>>
>>
>>
>> On Mon, Apr 15, 2013 at 12:16 PM, Michael Cohen <scudette(a)gmail.com>wrote:
>>
>>> Hi Ken,
>>> I have not had a chance to play with nbdserver. Are you saying that
>>> winpmem acquisition to the local disk completed ok?
>>>
>>> Did you manage to image with winpmem over a socket and netcat? Or are
>>> you trying to image to a network share?
>>>
>>> Thanks,
>>> Michael.
>>>
>>>
>>> On 15 April 2013 18:25, Ken Pryor <kdpryor(a)gmail.com> wrote:
>>>
>>>> I recently used the latest version of winpmem in conjunction with Jeff
>>>> Bryner's nbdserver to acquire ram for a couple different systems in support
>>>> of a blog post I was writing. Acquisition of 1 gb memory from an XP 32 bit
>>>> vm via the network worked perfectly.
>>>>
>>>> However, acquiring memory from a 64 bit Win 7 physical system with 12
>>>> GB ram failed. It would start okay, but would freeze up and reboot the Win
>>>> 7 system at 3.5 GB every time when being acquired using nbdserver via the
>>>> network. Using winpmem directly on the machine works successfully, but
>>>> fails on the network.
>>>>
>>>> Any suggestions as to the problem? I can provide any data or follow up
>>>> testing if needed.
>>>>
>>>> Ken
>>>>
>>>> _______________________________________________
>>>> Vol-users mailing list
>>>> Vol-users(a)volatilityfoundation.org
>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>>>
>>>>
>>>
>>
>
Hi Michael,
Yes, I ran winpmem on the subject machine and allowed it to save an image
file to that machine successfully. In my nbdserver test, I ran winpmem -l
and verified the service was running. I went to the nbd Linux client and
began the process of imaging pmem from the subject computer via the
network. Running nbd-client on the Linux workstation, I assigned the pmem
output coming over the network to /dev/nbd0. I used the following command
line then to image:
dd if=/dev/nbd0 of=./ramoutput.dd
This has been successful on 32 bit XP machines, but it dies on the 64 bit
machine. If this description doesn't make sense, I'll try to do a better
description later this evening.
Ken
On Mon, Apr 15, 2013 at 12:16 PM, Michael Cohen <scudette(a)gmail.com> wrote:
> Hi Ken,
> I have not had a chance to play with nbdserver. Are you saying that
> winpmem acquisition to the local disk completed ok?
>
> Did you manage to image with winpmem over a socket and netcat? Or are you
> trying to image to a network share?
>
> Thanks,
> Michael.
>
>
> On 15 April 2013 18:25, Ken Pryor <kdpryor(a)gmail.com> wrote:
>
>> I recently used the latest version of winpmem in conjunction with Jeff
>> Bryner's nbdserver to acquire ram for a couple different systems in support
>> of a blog post I was writing. Acquisition of 1 gb memory from an XP 32 bit
>> vm via the network worked perfectly.
>>
>> However, acquiring memory from a 64 bit Win 7 physical system with 12 GB
>> ram failed. It would start okay, but would freeze up and reboot the Win 7
>> system at 3.5 GB every time when being acquired using nbdserver via the
>> network. Using winpmem directly on the machine works successfully, but
>> fails on the network.
>>
>> Any suggestions as to the problem? I can provide any data or follow up
>> testing if needed.
>>
>> Ken
>>
>> _______________________________________________
>> Vol-users mailing list
>> Vol-users(a)volatilityfoundation.org
>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>
>>
>
Hey all,
So far I am unable to get hivedump to work specifying an offset in
either interactive or non-interactive mode:
Offset(V) Offset(P) Name
0xe1036b60 0x4948ab60
\Device\HarddiskVolume1\Windows\system32\config\SYSTEM @ 0xe1036b60
./vol.py --profile=WinXPSP3x86 -f ../20130412-194645.raw hivedump -o
0xe1036b60
**************************************************
Hive -
Last Written Key
------------------------ ---
ERROR:root:Error: invalid literal for int() with base 10: 'x'
ERROR:root:invalid literal for int() with base 10: 'x'. Try --debug for
more information.
Not specifying an offset works however:
./vol.py --profile=WinXPSP3x86 -f ../20130412-194645.raw hivedump
**************************************************
Hive \Device\HarddiskVolume1\Documents and Settings\ACS\NTUSER.DAT @
0xe1452b60
Last Written Key
------------------------ ---
2013-04-10 18:32:35+0000
CMILoadedHive-{D6ED518C-64C9-49F9-A016-8B8A7E2C051E}/AppEvents
...
Any hints on what I could be doing wrong? Thank you.
James
I recently used the latest version of winpmem in conjunction with Jeff
Bryner's nbdserver to acquire ram for a couple different systems in support
of a blog post I was writing. Acquisition of 1 gb memory from an XP 32 bit
vm via the network worked perfectly.
However, acquiring memory from a 64 bit Win 7 physical system with 12 GB
ram failed. It would start okay, but would freeze up and reboot the Win 7
system at 3.5 GB every time when being acquired using nbdserver via the
network. Using winpmem directly on the machine works successfully, but
fails on the network.
Any suggestions as to the problem? I can provide any data or follow up
testing if needed.
Ken
On 2013-04-12 15:24, Carl Pulley wrote:
> Hi James,
> you'll be able to do this using the dumpfiles plugin (it
> reconstructs the memory view of the on disk file system using the
> shared cache). I understand that this will be released with the
> Volatility 2.3 release.
>
> All the best,
>
> Carl.
Ah...guess I am out of luck until then...thank you!
James
On 2013-04-12 15:59, Michael Cohen wrote:
> you can try to install pytz :-)
>
> for example on ubuntu the package is called python-tz:
>
> apt-get install python-tz
>
> on windows you need to get pip or easy install then
>
> pip install pytz
>
> Or you can try the windows binary from the downloads section because
> it has no required dependencies.
>
> Michael.
Heh..always so easy :) Thanks...it's flying now. Last thing I think I
need is plugins...here's what the TP responds with:
subcommands:
The following plugins can be selected.
Plugin
dis Disassemble the given address space.
dt Print a symbol.
dump Hexdump an object or memory location.
grep Search an address space for keywords.
guess_profile Guess the exact windows profile using
heuristics.
imagecopy Copies a physical address space out as a raw DD
image
info Print information about various subsystems.
load_as Load address spaces into the session if its not
already loaded.
null This plugin does absolutely nothing.
peinfo Print information about a PE binary.
is there a different spot do snag the plugins, or am I barking up the
wrong tree? Thanks again for all your help on this.
James
On 2013-04-12 15:44, Michael Cohen wrote:
> Note that this actually is already available in the tech preview
> edition using a slightly different mechanism (Its specific to
> registry
> hives instead of for generally cached files):
>
>
> https://volatility.googlecode.com/svn/branches/scudette/docs/user_manual.ht…
> [3]
>
> YMMV
> Michael.
Thanks Michael...I did give that a go but got:
ImportError: No module named pytz
Betting I'm missing something. Thanks again.
James
On 2013-04-12 15:43, david nardoni wrote:
> Here is a blog post that may suit your needs
>
> http://mikemachnik.com/2013/02/16/memdumpcracking/ [3]
>
> Dave Nardoni
> dnardoni(a)gmail.com [4]
>
> On Fri, Apr 12, 2013 at 2:18 PM, James Lay <jlay(a)slave-tothe-box.net
> [5]> wrote:
>
>> Hey all,
>>
>> Topic says it...any way to dump a full registry hive to disk? My
>> plan is to import the SYSTEM and SECURITY into Cain ;) Thank you.
>>
>> James
Thank you for the info...very useful!
James
Topic says it...here's what I'm looking at:
Volatile Systems Volatility Framework 2.2
Traceback (most recent call last):
File "/usr/local/bin/vol.py", line 186, in <module>
main()
File "/usr/local/bin/vol.py", line 168, in main
command = cmds[module](config)
File "/opt/volatility-2.2/volatility/plugins/malware/malfind.py",
line 347, in __init__
help = 'Match wide (unicode) strings')
File "/opt/volatility-2.2/volatility/conf.py", line 364, in
add_option
self.optparser.add_option("-{0}".format(short_option),
"--{0}".format(option), **args)
File "/usr/lib/python2.7/optparse.py", line 1020, in add_option
self._check_conflict(option)
File "/usr/lib/python2.7/optparse.py", line 995, in _check_conflict
option)
optparse.OptionConflictError: option -W/--wide: conflicting option
string(s): -W
Any hints on how to get yarascan to run? Thank you.
James
Thanks,
looking forward for your reply :)
On Wed, Mar 20, 2013 at 3:18 PM, david nardoni <dnardoni(a)gmail.com> wrote:
> I will get you all those details today, except the full snapshot. I can
> not share that
>
> Happy to run whatever you need and provide output
>
> Sent from my iPhone
>
> On Mar 20, 2013, at 3:31 AM, nir izraeli <nirizr(a)gmail.com> wrote:
>
> Hi Dave,
>
> a few questions if you don't mind,
> what's the VM version (vmware has numbered versions for their file
> formats, you can usually look it up in the VM's properties)?
> could you share the output of psscan?
> what other plugins you've tried running? could you share the output?
> will it be possible to upload the VMware snapshot somewhere so i could
> look into it?
>
> Thanks,
> - Nir.
>
>
>
> On Tue, Mar 19, 2013 at 2:31 AM, david nardoni <dnardoni(a)gmail.com> wrote:
>
>> I think I have some issues with a 8+gb VMware snapshot. I can get
>> psscan and thrdscan output but no other output from other plugins.
>>
>> Any suggestions from the group on troubleshooting the image.
>>
>> Fyi I can see all the data when I view it in hbgary responder pro.
>>
>> Thanks
>>
>> Dave
>>
>> Sent from my iPhone
>> _______________________________________________
>> Vol-users mailing list
>> Vol-users(a)volatilityfoundation.org
>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>
>
>
Hello,
We wanted to take the opportunity to point you to a blog post which gives a
preview of some of the research we've been working on at 504ENSICS Labs in
the area of Android memory analysis. We think our results will be of great
interest to the DFIR community and look forward to your feed back.
The blog post can be found here:
http://www.504ensics.com/android-application-dalvik-memory-analysis-the-chu…
---
Joe T. Sylve, M.S.
Co-Founder
504ENSICS Labs
www.504ensics.com | (504) 210-8270
Hi,
I was wondering: did anyone ever managed to do an analysis with a real
device? I know the answer is Yes.
The thing is that I've seen around many nice examples and tutorials
working... but all of them with the emulator. The only real device sample
"in the wild" seems to be the Evo4GRodeo samples from DFWRS Challenge.
This time I'm pretty sure I did (almost?) everything right. Although if it
doesn't work, probably it's not.
I've tried also with another smartphone other than the HTC One X, the
Galaxy Nexus, getting the correct kernel version. No compilation errors, no
module errors, no lime module crashing on the phone, no volatility profiles
error, nothing. Everything (looks) right.
But still, when trying to run volatility I still keep getting empty results
like this:
hydra:volatility-read-only paco$ python vol.py
--profile=LinuxGalaxyNexus-3_0_1x86 -f ~/memdump/test-lime-4.7.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 Gid DTB
Start Time
---------- -------------------- --------------- --------------- ------
---------- ----------
Now I start wondering two things:
- Is it my lime dump the issue? the header looks fine, if I look inside
with hexdump it seems reasonable, if I strings it I find my data.
- Is it the volatility profile? Maybe, because I've event tried to dump the
memory of my Galaxy Nexus with FROST (which uses LiME) and the result looks
the same. So I started believing my problem is in the profile, although I
cannot seem to find any other way to understand where the problem could be.
So if anyone who successfully analyzed Android memory dumps from any real
life device is willing to share his experience and/or Volatility profile,
it would be great.
Thanks
P.
--
Pasquale Stirparo, MEng
GCFA, OPST, OWSE, ECCE
Brian,
You must be talking about Jesse's rawmoddump plugin. Its interesting to see
how people go about solving problems. Rather than typing 3 lines into the
existing volshell plugin, he re-implemented the same functionality into a
70 line file and then blogged about it as if it was some ground breaking
new capability...lol.
Anyway, there are a few possible explanations for finding a legitimate
driver at an offset from the base address reported by modscan. One is that
modscan found an _LDR_DATA_TABLE_ENTRY structure in physical memory that
represents a driver that was once loaded at address XXXXXXXX but has since
moved or unloaded. In that case, the kernel would be allowed to map another
driver into that available space (starting at either the exact same or a
nearby address).
Another plausible scenario is that modscan found an _LDR_DATA_TABLE_ENTRY
for a module that is still loaded at its original address (check with
modlist which will show currently loaded modules). The driver has another
driver embedded in its resources section that it installed or planned to
install. In that case you would expect to find another PE file somewhere
near the base of the first one.
Hope this helps,
MHL
On Fri, Mar 22, 2013 at 12:28 AM, Brian Keefer <chort(a)effu.se> wrote:
> Michael,
>
> Yes, modscan showed the file as being
> from C:\Users\Bob\ApplicationData\dumpme.sys -like path. It's great to
> learn this can be done via volshell, which is not something I've explored
> yet. Someone else sent me a plugin off-list that essentially wraps that
> functionality.
>
> It looks like the legitimate driver is at an offset from the base address
> reported by modscan (is it typical for drivers to load from a user
> directory?). I'm not sure what the padding is before it. Could it perhaps
> be instructions, or maybe an XOR'd PE header? Not sure exactly.
>
> --
> chort
>
>
>
> On Mar 21, 2013, at 8:53 PM, Michael Hale Ligh wrote:
>
> Hey Brian,
>
> You can use volshell to extract an arbitrary region of memory from any
> address space (in this case kernel memory if you're trying to acquire a
> kernel module). However, what do you mean "reference a file in user's
> AppData"? Is that the driver's path on disk (i.e.
> C:\Users\Bob\ApplicationData\dumpme.sys)?
>
> You would use volshell like this:
>
> >>> data = self.addrspace.zread(assumed_base_address, assumed_module_size)
> >>> with open('file.dmp', 'wb') as f:
> ...... f.write(data)
> >>>
>
> Cheers,
> MHL
>
>
> On Thu, Mar 21, 2013 at 5:32 PM, Brian Keefer <chort(a)effu.se> wrote:
>
>> Working with a ransomware infection, trying to dump one of the modules
>> that looks suspicious (the only one to reference a file in user's AppData).
>> I'm trying to dump it via the base address found through modscan, but
>> getting:
>> moddump Error: e_magic 8D4C is not a valid DOS signature.
>>
>> I tried -u. Is there any other way to dump it?
>>
>> --
>> chort
>>
>>
>>
>> _______________________________________________
>> Vol-users mailing list
>> Vol-users(a)volatilityfoundation.org
>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>
>
>
>
My Malware Analysts Cookbook refers to this module and I found a couple
of videos on how to use it; I just can't seem to locate the module itself.
Has it perhaps been deprecated by some other plugin or process?
Thanks!
-=[ Steve ]=-
> Hello,It seems you have identified some issues while the rest of the
output is explainable. 1) linux_check_afinfoBeing empty means that > nothing
is hooked (this is good)2) linux_check_creds, linux_pidhashtable,
linux_psxview
> These are missing support for your kernel version. Can you please paste
the output of uname -a on your machine along with the specific > version of
centos that you are using?
> 3) linux_check_evt_arm & linux_check_syscall_arm
> These only support ARM based computers (e.g. Android) and I assume your
memory sample is from an Intel based computer. We will soon > have a patch
that allows plugins to check what architecture they are being run against
and then these plugins will report they are ARM only instead of having
exceptions.
> 4) linux_check_ttyThis seems like a bug we will have to fix.Thank you for
your report and please get us the kernel & centos version so > we can
attempt to fix some of them.Thanks,Andrew (@attrc)
>
Hi Andrew,
I am sorry but it's my mistake because the os is not real centos but a
derived. The os is clearos (infact centos based) distro for firewalls.
Anyway:
# uname -a
Linux fw2.mycompany.local 2.6.18-308.1.1.v5 #1 SMP Sun Mar 11 18:15:19 MDT
2012 i686 i686 i386 GNU/Linux
# cat /etc/issue
ClearOS Enterprise Edition release 5.2
# cat /etc/redhat-release
CentOS release 5.4 (Final)
Thanks very much and I am sorry for the mistake.
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
autenticato? GRATIS solo con Email.it: http://www.email.it/f
Sponsor:
Trascorri la Pasqua all'Hotel Maestri di Riccione a due passi dal mare, da
Viale Ceccarini e dal nuovo lungomare pedonale. 2 giorni pensione completa a
Euro 170 in doppia a persona, un bambino fino
ai 6 anni in camera con due adulti gratuito
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=12790&d=20130325
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
Sponsor:
Last minute giugno in all inclusive all'Hotel Fior di Loto di Rimini per due persone, una settimana, Euro 686 a coppia, pensione completa, bevande ai pasti, servizio spiaggia
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=12774&d=25-3
> Hello,It seems you have identified some issues while the rest of the
output is explainable. 1) linux_check_afinfoBeing empty means that > nothing
is hooked (this is good)2) linux_check_creds, linux_pidhashtable,
linux_psxview
> These are missing support for your kernel version. Can you please paste
the output of uname -a on your machine along with the specific > version of
centos that you are using?
> 3) linux_check_evt_arm & linux_check_syscall_arm
> These only support ARM based computers (e.g. Android) and I assume your
memory sample is from an Intel based computer. We will soon > have a patch
that allows plugins to check what architecture they are being run against
and then these plugins will report they are ARM only instead of having
exceptions.
> 4) linux_check_ttyThis seems like a bug we will have to fix.Thank you for
your report and please get us the kernel & centos version so > we can
attempt to fix some of them.Thanks,Andrew (@attrc)
>
Hi Andrew,
I am sorry but it's my mistake because the os is not real centos but a
derived. The os is clearos (infact centos based) distro for firewalls.
Anyway:
# uname -a
Linux fw2.mycompany.local 2.6.18-308.1.1.v5 #1 SMP Sun Mar 11 18:15:19 MDT
2012 i686 i686 i386 GNU/Linux
# cat /etc/issue
ClearOS Enterprise Edition release 5.2
# cat /etc/redhat-release
CentOS release 5.4 (Final)
Thanks very much and I am sorry for the mistake.
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
autenticato? GRATIS solo con Email.it: http://www.email.it/f
Sponsor:
Pasqua all'hotel Stella di Riccione, pernottamento e colazione, 2 gg Euro
106 a persona in doppia, bimbo fino a 3 anni GRATIS. Biglietti per i parchi
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=12791&d=20130325
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
Sponsor:
Riduzione del 10% sulle tariffe di pensione per le prenotazioni pervenute entro il 30 aprile 2013 all'Hotel Embassy di Pesaro
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=12769&d=25-3
Hi,
I am trying to analyze a memory dump from a Centos server but I have got
some problems.
------ Plugin linux_check_afinfo ------
---------------------------------
Volatile Systems Volatility Framework 2.3_alpha
Symbol Name Member
Address
------------------------------------------ ------------------------------
----------
------ Plugin linux_check_creds ------
---------------------------------
Volatile Systems Volatility Framework 2.3_alpha
PIDs
--------
ERROR : volatility.plugins.linux.check_creds: This command is not
supported in this profile.
------ Plugin linux_check_evt_arm ------
---------------------------------
Volatile Systems Volatility Framework 2.3_alpha
Check PASS/FAIL Info
------------------------------ --------- ------------------------------
SWI Offset Instruction FAIL -
------ Plugin linux_check_syscall_arm ------
---------------------------------
Volatile Systems Volatility Framework 2.3_alpha
Index Address Symbol
---------- ---------- ------------------------------
Traceback (most recent call last):
File "vol.py", line 186, in <module>
main()
File "vol.py", line 177, in main
command.execute()
File
"/root/vltlt/volatility-read-only/volatility/plugins/linux/common.py", line
55, in execute
commands.Command.execute(self, *args, **kwargs)
File "/root/vltlt/volatility-read-only/volatility/commands.py", line 111,
in execute
func(outfd, data)
File
"/root/vltlt/volatility-read-only/volatility/plugins/linux/check_syscall_arm.py",
line 88, in render_text
for (i, call_addr, hooked) in data:
File
"/root/vltlt/volatility-read-only/volatility/plugins/linux/check_syscall_arm.py",
line 66, in calculate
num_syscalls = self._get_syscall_table_size()
File
"/root/vltlt/volatility-read-only/volatility/plugins/linux/check_syscall_arm.py",
line 38, in _get_syscall_table_size
opcode = obj.Object("unsigned int", offset = vector_swi_addr, vm =
self.addr_space)
File "/root/vltlt/volatility-read-only/volatility/obj.py", line 169, in
Object
offset = int(offset)
TypeError: int() argument must be a string or a number, not 'NoneType'
------ Plugin linux_check_tty ------
---------------------------------
Volatile Systems Volatility Framework 2.3_alpha
Name Address Symbol
---------------- ---------- ------------------------------
Traceback (most recent call last):
File "vol.py", line 186, in <module>
main()
File "vol.py", line 177, in main
command.execute()
File
"/root/vltlt/volatility-read-only/volatility/plugins/linux/common.py", line
55, in execute
commands.Command.execute(self, *args, **kwargs)
File "/root/vltlt/volatility-read-only/volatility/commands.py", line 111,
in execute
func(outfd, data)
File
"/root/vltlt/volatility-read-only/volatility/plugins/linux/tty_check.py",
line 59, in render_text
for name, call_addr in data:
File
"/root/vltlt/volatility-read-only/volatility/plugins/linux/tty_check.py",
line 52, in calculate
recv_buf = tty_dev.ldisc.ops.receive_buf
File "/root/vltlt/volatility-read-only/volatility/obj.py", line 735, in
__getattr__
return self.m(attr)
File "/root/vltlt/volatility-read-only/volatility/obj.py", line 717, in m
raise AttributeError("Struct {0} has no member
{1}".format(self.obj_name, attr))
AttributeError: Struct ldisc has no member ops
------ Plugin linux_pidhashtable ------
---------------------------------
Volatile Systems Volatility Framework 2.3_alpha
ERROR : volatility.plugins.linux.pidhashtable: calculate_v2: This profile
is currently unsupported by this plugin. Please file a bug report on our
issue tracker to have supprot added.
Offset Name Pid Uid Gid DTB
Start Time
---------- -------------------- --------------- --------------- ------
---------- ----------
------ Plugin linux_psxview ------
---------------------------------
Volatile Systems Volatility Framework 2.3_alpha
ERROR : volatility.plugins.linux.pidhashtable: calculate_v2: This profile
is currently unsupported by this plugin. Please file a bug report on our
issue tracker to have supprot added.
Offset(V) Name PID pslist pid_hash kmem_cache
---------- -------------------- ------ ------ -------- ----------
The others plugins work fine.
Bye.
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
autenticato? GRATIS solo con Email.it: http://www.email.it/f
Sponsor:
Una PASQUA in famiglia, in un hotel sul mare. L'Hotel Adelphi Riccione
propone un'offerta con ingresso ai parchi inclusi e i bimbi gratis fino a
tre anni. Piano famiglia a partire da 3 notti in mezza o pensione completa
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=12777&d=20130322
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
Sponsor:
Last minute giugno in all inclusive all'Hotel Fior di Loto di Rimini per due persone, una settimana, Euro 686 a coppia, pensione completa, bevande ai pasti, servizio spiaggia
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=12774&d=22-3
Working with a ransomware infection, trying to dump one of the modules that looks suspicious (the only one to reference a file in user's AppData). I'm trying to dump it via the base address found through modscan, but getting:
moddump Error: e_magic 8D4C is not a valid DOS signature.
I tried -u. Is there any other way to dump it?
--
chort
I think I have some issues with a 8+gb VMware snapshot. I can get
psscan and thrdscan output but no other output from other plugins.
Any suggestions from the group on troubleshooting the image.
Fyi I can see all the data when I view it in hbgary responder pro.
Thanks
Dave
Sent from my iPhone
We are pleased to announce the next public Volatility training
opportunity: the Windows Malware and Memory Forensics Training by The
Volatility Project. This course will take place in Reston, VA from
Monday, June 10th through Friday, June 14th 2013. For details, please
see our blog:
http://volatility-labs.blogspot.com/2013/03/official-training-by-volatility…
or email us at: voltraining(a)memoryanalysis.net
All the best,
-gleeda
--
PGP Fingerprint: 2E87 17A1 EC10 1E3E 11D3 64C2 196B 2AB5 27A4 AC92
I'm digging through a memory image of a pretty thoroughly compromised
system using Volatility and I've run across something new (to me
anyway...).
There's a rogue process in the image that lists a PID which exceeds the
width allocated by Volatility:
0xdba0f9a8 cmd.exe 5004 True True False True False
True False
0xda247250 chrome.exe 4764 True True False True False
True False
0x6da39918 ☼ 42...2 False False False False False
False True
0xdcd97610 SearchFilterHo 6956 False True False False False
False False
0xdace4568 PrintIsolation 6312 False True False False False
False False
I'd dearly love to get my hands on that executable, but I don't see an
easy way to get the PID.
Any easy way forward on this?
-=[ Steve ]=-
Hi Guys,
I've been messing around for about a week trying to get volatility to
analyse a memory dump of some system.
Since this is part of a puzzle I know I should be able to analyse it
(although I'm not sure volatility can , but it seems to be my best option).
The actual question is this:
I assume that I have a dump of a box running kernel version
2.6.32-45.104-generic-pae . How should I correctly create a profile in
volatility to analyse this dump? I can create a profile but I don't
think it's correct...
Because I do make some assumptions, I'd like to share my workflow below.
Please feel free to comment!
My current setup is:
- Recent ubuntu box
- On which KVM resides
- A "memory.raw" image of the memory of this machine. No other
information was provided.
First I wanted to determine what OS the image is from, and I had a look
by grepping the image like this:
strings memory.raw | grep -i <keyword>
I scanned for keywords like:
- Windows
- Ubuntu
- Debian
- Fedora
- RHEL
Looks like it's actually ubuntu:
boudewijn@ubuntu:~$ strings memory.raw | grep -i ubuntu | wc -l
1668
Okay for determining the kernel version, I started having a look at the
output of grepping ubuntu, and I found:
Linux version 2.6.32-45-generic-pae (buildd@lamiak) (gcc version 4.4.3
(Ubuntu 4.4.3-4ubuntu5.1) ) #104-Ubuntu SMP Tue Feb 19 21:36:53 UTC 2013
(Ubuntu 2.6.32-45.104-generic-pae 2.6.32.60+drm33.26)
Ubuntu 2.6.32-45.104-generic-pae 2.6.32.60+drm33.26
<5>[ 0.000000] Linux version 2.6.32-45-generic-pae (buildd@lamiak)
(gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1) ) #104-Ubuntu SMP Tue Feb
19 21:36:53 UTC 2013 (Ubuntu 2.6.32-45.104-generic-pae 2.6.32.60+drm33.26)
So I installed this kernel version 2.6.32-45.104-generic-pae, and
rebooted (which is less work than changing the makefile etc.... I'm a
lazy sod).
Okay, make the profile:
boudewijn@ubuntu:~/volatility/tools/linux$ make
make -C //lib/modules/2.6.32-45-generic-pae/build CONFIG_DEBUG_INFO=y
M=/home/boudewijn/volatility/tools/linux modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.32-45-generic-pae'
CC [M] /home/boudewijn/volatility/tools/linux/module.o
/home/boudewijn/volatility/tools/linux/module.c:70:33: error:
linux/net_namespace.h: No such file or directory
make[2]: *** [/home/boudewijn/volatility/tools/linux/module.o] Error 1
make[1]: *** [_module_/home/boudewijn/volatility/tools/linux] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-2.6.32-45-generic-pae'
make: *** [dwarf] Error 2
Fix the include statement , to include
/usr/src/linux-headers-2.6.32-45/include/net/net_namespace.h . make
clean ;make followed...
Created the overlay:
boudewijn@ubuntu:~$ sudo zip
volatility/volatility/plugins/overlays/linux/Ubuntu1004.zip
volatility/tools/linux/module.dwarf /boot/System.map-2.6.32-45-generic-pae
adding: volatility/tools/linux/module.dwarf (deflated 89%)
adding: boot/System.map-2.6.32-45-generic-pae (deflated 74%)
boudewijn@ubuntu:~$
Then I ran volatility with the newly created profile, and it crashed:
boudewijn@ubuntu:~$ python volatility/vol.py -f memory.raw --profile
LinuxUbuntu1004x86 imageinfo
Volatile Systems Volatility Framework 2.2
Determining profile based on KDBG search...
Suggested Profile(s) : No suggestion (Instantiated with
LinuxUbuntu1004x86)
AS Layer1 : JKIA32PagedMemoryPae (Kernel AS)
AS Layer2 : FileAddressSpace
(/home/boudewijn/memory.raw)
PAE type : PAE
DTB : 0x79b000L
Traceback (most recent call last):
File "volatility/vol.py", line 186, in <module>
main()
File "volatility/vol.py", line 177, in main
command.execute()
File "/home/boudewijn/volatility-2.2/volatility/commands.py", line
111, in execute
func(outfd, data)
File "/home/boudewijn/volatility-2.2/volatility/plugins/imageinfo.py",
line 34, in render_text
for k, v in data:
File "/home/boudewijn/volatility-2.2/volatility/plugins/imageinfo.py",
line 91, in calculate
kdbgoffset = volmagic.KDBG.v()
File "/home/boudewijn/volatility-2.2/volatility/obj.py", line 746, in
__getattr__
return self.m(attr)
File "/home/boudewijn/volatility-2.2/volatility/obj.py", line 728, in m
raise AttributeError("Struct {0} has no member
{1}".format(self.obj_name, attr))
AttributeError: Struct VOLATILITY_MAGIC has no member KDBG
I thought it might a an amd64 box, but grepping the output of strings
memory.raw just renders +- 10 results. Way to few to be an amd64 box.
Can anyone tell me what I'm actually doing wrong? Or is volatility just
not the right tool for the job.
Cheers,
Boudewijn Ector
Hello all,
I thought I'd let you know that we've put together a cheat sheet that
you might find useful when using Volatility in your investigations:
http://volatility-labs.blogspot.com/2013/03/if-youre-going-to-cheat_15.html
Also we plan to announce the next training opportunity for our Windows
Malware and Memory Forensics Training Course on Monday, March 18th
2013 so stay tuned!
All the best,
-gleeda
--
PGP Fingerprint: 2E87 17A1 EC10 1E3E 11D3 64C2 196B 2AB5 27A4 AC92
I apologize in advanced if I'm overlooking something. I'm using the Windows binary of Volatility 2.2 on a Windows 7 platform. Could someone tell me how I can extract a certain driver using the offset?
I looked at the moddump help and the offset option is not listed. I tried to use -o anyway and got an error saying there is no such option (--offset=offset didn't work either). The Volatility command wiki doesn't show the moddump help but it does link to this post which shows the offset as an option:
http://moyix.blogspot.com/2008/10/plugin-post-moddump.html
I'm not that familiar with Python so looking at the plugin code wasn't that helpful for me. What I am trying to do is to extract a specific driver from a memory image. The moddump command works for extracting all drivers but it would be nice to extract only the one I need.
Thanks for any help
Corey Harrell
"Journey into Incident Response"
http://journeyintoir.blogspot.com
Hi,
Yesterday during a challenge we had to use the linux_dump_map plugin
to dump a process stack, and the documentation at
https://code.google.com/p/volatility/wiki/LinuxCommandReference23#linux_pro…
says it has the -p option to select a process.
However, as far as I can tell looking in the svn history, this plugin
never had the -p option. And it's definitely not working currently.
I've heard a confirmation that the option was working in version
2.2-rc1, so maybe it was a global option?
The reason I'm mailing this is because, if the -s is virtual memory,
would you not get possible overlap in areas? How do you know it dumped
the correct VMA? Note that every time I tried, I got the correct area.
Cheers,
Edwin
Hi
I am running - revision 3164
I get the following error when running: Ignore the import errors
# python2.7 vol.py -f /opt/hiberfil.sys --profile=WinXPSP3x86 imagecopy -O
/opt/winxp_sp3_2nd.raw
Volatile Systems Volatility Framework 2.3_alpha
*** Failed to import volatility.plugins.zeusscan1 (AttributeError: 'module'
object has no attribute 'ImpScan')
*** Failed to import volatility.plugins.zeusscan2 (AttributeError: 'module'
object has no attribute 'ApiHooks')
Writing data (5.00 MB chunks):
|......................................................................................................................................................................................................................................................ERROR
: volatility.plugins.imagecopy: Error when reading from address space
I have tried coping over the .sys file twice. I generated a new .sys file
and same error. It worked wonderfully on lastweek. I tried reverting back
to revision 3159 and no dice. Also Oddly enough it works with an old
version of volatility running on remnux.
Not sure whats up. Also here is the output from imageinfo:
Determining profile based on KDBG search...
Suggested Profile(s) : WinXPSP2x86, WinXPSP3x86 (Instantiated
with WinXPSP2x86)
AS Layer1 : JKIA32PagedMemoryPae (Kernel AS)
AS Layer2 : WindowsHiberFileSpace32 (Unnamed AS)
AS Layer3 : FileAddressSpace (/opt/hiberfil.sys)
PAE type : PAE
DTB : 0x9300060L
KDBG : 0x80545be0L
Number of Processors : 1
Image Type (Service Pack) : 3
KPCR for CPU 0 : 0xffdff000L
KUSER_SHARED_DATA : 0xffdf0000L
Image date and time : 2013-03-05 06:26:20 UTC+0000
Image local date and time : 2013-03-05 00:26:20 -0600
thanks in advance
Hi,
I am trying to build a profile for the Arch Linux kernel (3.7.9-2),
but I am getting this error:
http://paste.ubuntu.com/5584634/
Is this a problem with newer kernels or am I doing something wrong?
Cheers,
Edwin
Hi All,
I'm trying to make a profile for android device.
I did a memory dump with LiME of an HTC One X (Android 4.0.3, HTC Sense
4.0, kernel 2.6.39.4-g6b459dc).
Now, following the instruction here
https://code.google.com/p/volatility/wiki/LinuxMemoryForensics , I was
trying to understand how to modify the makefile under
volatility/tools/linux/ , in order to point to my kernel source. The thing
is that in from my kernel source folder I couldn't find a proper value for
KDIR and KVER (although they should be pretty straightforward according to
their name) that would fit with the path for make command as from the
following source code:
pmem: pmem.c
$(MAKE) -C $(KDIR)/lib/modules/$(KVER)/build M=$(PWD) modules
dwarf: module.c
$(MAKE) -C $(KDIR)/lib/modules/$(KVER)/build CONFIG_DEBUG_INFO=y
M=$(PWD) modules
dwarfdump -di module.ko > module.dwarf
$(MAKE) -C $(KDIR)/lib/modules/$(KVER)/build M=$(PWD) clean
Did anyone ever created an android profile? Any hint?
I've seen in the mailing list archive a thread "Profile (ZIP) for Android
4.0.3" from Mike (in Cc), any news about that?
Thank you
P.
--
Pasquale Stirparo, MEng
GCFA, OPST, OWSE, ECCE
European Commission - JRC Joint Research Centre
Institute for the Protection and Security of the Citizen (IPSC)
Digital Citizen Security Unit
Via E. Fermi, 2749 - TP 361
21027 Ispra (VA) - Italy
PGP Key: 0x4C589FB2
Fingerprint: 776D F072 3F43 D5DE CB55 86D2 55FF 14A7 4C58 9FB2
Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
On 2013-02-27 13:51, Ayers, Robert wrote:
> By name alone I'd bet a beer that this is a malicious executable
>
> 0x89152020 qegyas.exe 2364 2236 0 -------- 0
> 0 2013-02-27 15:08:35 2013-02-27 15:08:44
Thanks for the quick response. I believe that qegyas.exe is the
injector (according to my procmon at least). Also, that process has
exited, so I'm out of luck for taking a peak at it (in memory at
least...happily the malware left the file on the drive :))
James
Greetings,
I was adding OS X support to my copy of Volatility per the instructions on https://code.google.com/p/volatility/wiki/MacMemoryForensics. It went well but I thought I'd pull the most recent version while I was at it.
Mac support went away when I did so. setup.py is now missing:
"volatility.plugins.overlays.mac",
Even when I add that back, vol.py --info doesn't show the OS X profiles.
Is this intentional? Is there a different version that I should be using?
Thanks!
-David
Hi there
We are looking to collect memory on an old Windows NT box. Of course, the tools we utilize are too recent to be compatible with Windows NT. Does anyone have any workaround suggestions or tools that may assist with this memory collection?
Regards,
Terrie
Group,
I have a memory image file for a Red Hat 6.3 box with 2.6.32-279.el6.x86_x64 kernel. Is it ok to use the CentOS 6.3 x64 (2.6.32-279.el6.x86_x64) example profile, given it's for the same kernel, or do I need to build a new profile?
Thanks for the help.
Kevin Marker
ACE, CCE, CISSP, EnCE
Johnny,
I will try to answer your question to the best of my knowledge. I have also
put the volatility user's mailing list in CC to share your problem with
other users and in case somebody have a better answer than mine ;-)
*Do you know how to send the memory using a netcat session from machine A
to machine B? I tied to do the below, but it did not work.
*
*Machine B (Start Netcat on BackTrack Server)
-------------------------------------------------
root@bt:/var/tmp# nc -l -vvv -p 4444 > lime.dd
listening on [any] 4444 ...
Machine A (On Metasploitable Server, Trying to send image to
BackTrack[192.168.1.107])
-------------------------------------------------
root@metasploitable:/var/tmp/LIME/src# insmod lime-2.6.24-16-server.ko
"path=tcp:4444 format=raw" | nc 192.168.1.107 4444*
Unlike dd, LiME operates in kernel mode so you can't pipe it to netcat in
user mode.
I think LiME was created to listen on the target OS (Machine A in your
case) and memory acquisition needs to be started with netcat on the
acquisition PC (Machine B in your case). I have not try it, but here's how
I think it works:
1) insmod lime-2.6.24-16-server.ko "path=tcp:4444 format=lime"
2) nc 192.168.1.107 -p 4444 > mem.lime
Also, I suggest you to use the padded format or the lime format to dump
memory because I think volatility will not be able to convert virtual to
physical addresses with a raw dump and analysis will fail (unless you pad
the dump manually).
Hope this helps!
Sebastien
On Mon, Feb 18, 2013 at 5:41 PM, Johnny Shaieb <johnny.shaieb(a)gmail.com>wrote:
> Sebastien,
>
> My name is Johnny. I am trying to figure out how to use Lime with
> Volatility.
>
> My end goal it to take and analyze the memory of a Vulnerable 8.04 VM made
> available by the Metasploitable Project.
> + Reference Link:
> http://sourceforge.net/projects/metasploitable/files/Metasploitable2/
>
> I have been able to dump the memory (See Below)
>
> root@metasploitable:/var/tmp/LIME/src# insmod lime-2.6.24-16-server.ko "path=/var/tmp/memory.dd format=raw"
>
> root@metasploitable:/var/tmp/LIME/src# ls -l /var/tmp/memory.dd
> -r--r--r-- 1 root root 536410112 2013-02-18 14:53 /var/tmp/memory.dd
>
>
> Do you know how to send the memory using a netcat session from machine A
> to machine B? I tied to do the below, but it did not work.
>
> *Machine B* (Start Netcat on BackTrack Server)
> -------------------------------------------------
> root@bt:/var/tmp# nc -l -vvv -p 4444 > lime.dd
> listening on [any] 4444 ...
> *Machine A *(On Metasploitable Server, Trying to send image to BackTrack[192.168.1.107])
> -------------------------------------------------
> root@metasploitable:/var/tmp/LIME/src# insmod lime-2.6.24-16-server.ko "path=tcp:4444 format=raw" | nc 192.168.1.107 4444
>
>
> Thank you for any guidance,
>
> Johnny
>
> --
> Johnny A. Shaieb
>
> http://www.computersecuritystudent.com
> http://www.studentJD.com <http://www.studentjd.com/>
> Education
> BS: Management Information Systems (Oklahoma State University)
> MS: Telecommunications (Oklahoma State University)
> MS: Computer Science / Computer Security (University of Tulsa)
>
> NSTISSI Certified
> 4011: Information Security Professional
> 4012: Designated Approving Authority
> 4013: Administration in Information Systems Security
> 4014: Information Systems Security Officer
>
