I built LiME from the tarball on the project site (not latest svn) and was able to dump memory successfully (type=lime). After many trials and tribulations I was able to get the Volatility profile built for CentOS 5.3x64 (had to remove pmem from the Makefile). I put the profile in the correct directory, and vol.py --info lists it as expected, however when I try to use the profile with the memory image I get an error.
chort@hydra:~/code/profiles-volatility/CentOS_5.3_x64$ vol.py --profile=LinuxCentOS_5_3x64 -f /fun/ir/geriatrix.lime linux_lsmod
Volatile Systems Volatility Framework 2.3_alpha
WARNING : volatility.obj : Overlay structure cpuinfo_x86 not present in vtypes
No suitable address space mapping found
Tried to open image as:
MachOAddressSpace: mac: need base
LimeAddressSpace: lime: need base
WindowsHiberFileSpace32: No base Address Space
WindowsCrashDumpSpace64: No base Address Space
HPAKAddressSpace: No base Address Space
VirtualBoxCoreDumpElf64: No base Address Space
VMWareSnapshotFile: No base Address Space
WindowsCrashDumpSpace32: No base Address Space
JKIA32PagedMemoryPae: No base Address Space
AMD64PagedMemory: No base Address Space
JKIA32PagedMemory: No base Address Space
IA32PagedMemoryPae: Module disabled
IA32PagedMemory: Module disabled
MachOAddressSpace: MachO Header signature invalid
MachOAddressSpace: MachO Header signature invalid
LimeAddressSpace: Invalid Lime header signature
WindowsHiberFileSpace32: PO_MEMORY_IMAGE is not available in profile
WindowsCrashDumpSpace64: Header signature invalid
HPAKAddressSpace: Invalid magic found
VirtualBoxCoreDumpElf64: ELF64 Header signature invalid
VMWareSnapshotFile: Invalid VMware signature: 0xf000ff53
WindowsCrashDumpSpace32: Header signature invalid
JKIA32PagedMemoryPae: Incompatible profile LinuxCentOS_5_3x64 selected
AMD64PagedMemory: Failed valid Address Space check
JKIA32PagedMemory: Incompatible profile LinuxCentOS_5_3x64 selected
IA32PagedMemoryPae: Module disabled
IA32PagedMemory: Module disabled
FileAddressSpace: Must be first Address Space
ArmAddressSpace: Incompatible profile LinuxCentOS_5_3x64 selected
On a hunch I checked the directory I built the profile in (copied headers & source from the target system):
chort@hydra:~/code/profiles-volatility/CentOS_5.3_x64$ grep cpuinfo *
System.map-2.6.18-128.el5:ffffffff8006f328 t show_cpuinfo
System.map-2.6.18-128.el5:ffffffff80103251 t cpuinfo_open
System.map-2.6.18-128.el5:ffffffff8020eadb t show_cpuinfo_max_freq
System.map-2.6.18-128.el5:ffffffff8020eafa t show_cpuinfo_min_freq
System.map-2.6.18-128.el5:ffffffff8020f759 t show_cpuinfo_cur_freq
System.map-2.6.18-128.el5:ffffffff802f0bc0 D cpuinfo_op
System.map-2.6.18-128.el5:ffffffff80308420 d proc_cpuinfo_operations
System.map-2.6.18-128.el5:ffffffff803319a0 d cpuinfo_cur_freq
System.map-2.6.18-128.el5:ffffffff80331b20 d cpuinfo_min_freq
System.map-2.6.18-128.el5:ffffffff80331b60 d cpuinfo_max_freq
Platform running Volatility (2.3_alpha, latest from svn):
Linux hydra 3.2.0-35-generic #55-Ubuntu SMP Wed Dec 5 17:42:16 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Source of memory image:
Linux geriatrix.smtps.net 2.6.18-128.el5 #1 SMP Wed Jan 21 10:41:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux
What am I missing?
--
chort
Hi List,
Running volatility-2.2.standalone.exe on Win7 Pro 64bit AMD with 32GB of
RAM.
I'm new to volatility and I'm attempting to use it to troubleshoot apps
that don't play nice with the Windows clipboard. I'm using the steps
here:
http://www.infosecisland.com/blogview/22429-Detecting-Window-Stations-and-C…
I changed my registry to force a complete memory dump by setting
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl\CrashDumpEnabled
to be 1. (http://support.microsoft.com/kb/969028)
I used System Internal's NotMyFault tool with the /crash switch to
create the dump.
(https://code.google.com/p/volatility/wiki/CrashAddressSpace)
The resulting c:\windows\memory.dmp file is about 34GB in size.
When I launch volatility, this is as far as it gets:
C:\Users\taa\Downloads>volatility-2.2.standalone.exe -f
c:\windows\memory.dmp --profile=Win7SP1x64 wndscan
Volatile Systems Volatility Framework 2.2
It has been showing this for close to 3.75 hours. Task Manager shows two
instances of volatility-2.2.standalone.exe running, one at a constant
1,144K RAM usage, and the other instance with RAM usage constantly
changing in the range of 58MB to 73MB, averaging 13% CPU utilization. To
mean this indicates it is doing /something/ even if it is caught in an
infinite loop.
If it's reasonable for volatility to run this long and longer, I'll just
be patient, though it would be helpful if someone could give me an idea
of how long it might take.
If this is taking too long, what can I do to troubleshoot what it's doing?
Kind regards,
Todd
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!
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
