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
