Hello,
We are writing to announce the public offering of our Windows Memory
Forensics for Analysts training course. 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. Full details can be found here:
http://volatility-labs.blogspot.com/2012/11/windows-memory-forensics-traini…
Please write or comment on the post if you have any questions or comments.
Thanks,
Andrew (@attrc)
Have never seen this error when trying to dump a process. Any
suggestions? tried -u as well with the same results.
vol.exe -f image.raw --profile Win2003SP2x86 procexedump -D dump/ -p 1684
Volatile Systems Volatility Framework 2.2
Process(V) ImageBase Name Result
---------- ---------- -------------------- ------
0x89b1e020 ---------- redactedxxxxx.e Error: Cannot acquire process AS
I am aware of the tech preview tools (that I learned about sitting in
scudette's class no less!) but I haven't had enough "stick time" with
them to trust a remote user running a dump for me with them.
On Tue, Oct 30, 2012 at 7:47 PM, alex pease <alex.pease(a)gmail.com> wrote:
>
> http://volatility.googlecode.com/files/volatility-3.0-tp2.zip
>
> Not that I am saying use a different imager.
>
> I know scudette didn't write that all you need to do is run his tool. If I
> remember write it is winpmem.exe -o file.mem, and you have a raw memory
> dump.
>
> Dumpit likes to deadlock systems.
>
>
> On Tuesday, October 30, 2012, Dewhirst, Rob wrote:
>>
>> I know I have the right profile but hearing something like this makes
>> me question the image. I took a new image with a different tool and
>> can now dump the process without error.
>>
>> FWIW I used Dumpit for the first image and FTK Imager for the second.
>>
>> On Tue, Oct 30, 2012 at 11:47 AM, Michael Cohen <scudette(a)gmail.com>
>> wrote:
>> > Rob,
>> > According to the psscan output you posted the PDB (Process directory
>> > base) is 0xcf3392c0. This is clearly an invalid address since a DTB is
>> > always aligned on page boundaries.
>> >
>> > Can you dump other processes from this image? Is it possible that you
>> > dont have the correct profile chosen for your image?
>> >
>> > Michael.
>> >
>> > On 30 October 2012 17:07, Dewhirst, Rob <robdewhirst(a)gmail.com> wrote:
>> >> The process doesn't appear to have exited based on pslist (and it was
>> >> still generating network traffic while I dumped ram)
>> >>
>> >> Offset(V) Name PID PPID Thds Hnds Sess
>> >> Wow64 Start Exit
>> >> ---------- -------------------- ------ ------ ------ -------- ------
>> >> ------ -------------------- --------------------
>> >> 0x8b3802a8 System 4 0 127 -------- ------
>> >> 0
>> >> 0x89be3290 smss.exe 312 4 2 -------- ------
>> >> 0 2012-10-26 02:29:26
>> >> [...]
>> >> 0x89b1e020 redactedxx.e 1684 432 15 -------- ------
>> >> 0 2012-10-26 02:29:39
>> >>
>> >> Don't know if this helps
>> >>
>> >> psxview
>> >>
>> >> Volatile Systems Volatility Framework 2.2
>> >> Offset(P) Name PID pslist psscan thrdproc pspcdid
>> >> csrss
>> >> ---------- -------------------- ------ ------ ------ -------- -------
>> >> -----
>> >> 0x09b17b70 svchost.exe 2632 True True False False
>> >> False
>> >> [...]
>> >> 0x09b1e020 redactedxx.e 1684 True True False False
>> >> False
>> >>
>> >> psscan
>> >>
>> >> sansforensics@SIFT-Workstation:~/Desktop$ vol.py -f
>> >> ~/Desktop/image.raw --profile Win2003SP2x86 psscan
>> >> Volatile Systems Volatility Framework 2.2
>> >> Offset(P) Name PID PPID PDB Time created
>> >> Time exited
>> >> ---------- ---------------- ------ ------ ----------
>> >> -------------------- --------------------
>> >> 0x09b1e020 redactedxx.e 1684 432 0xcf3392c0 2012-10-26 02:29:39
>> >>
>> >>
>> >> On Mon, Oct 29, 2012 at 6:44 PM, Michael Hale Ligh
>> >> <michael.hale(a)gmail.com> wrote:
>> >>> This means that the DTB (page directory) for the process doesn't
>> >>> appear
>> >>> valid, which is typically because the process has exited (although the
>> >>> _EPROCESS structure itself may still exist, its page tables can be
>> >>> corrupt).
>> >>> Can you check the exit time for this process with pslist or psscan?
>> >>>
>> >>> MHL
>> >>>
>> >>> On Mon, Oct 29, 2012 at 5:46 PM, Dewhirst, Rob <robdewhirst(a)gmail.com>
>> >>> wrote:
>> >>>>
>> >>>> Have never seen this error when trying to dump a process. Any
>> >>>> suggestions? tried -u as well with the same results.
>> >>>>
>> >>>> vol.exe -f image.raw --profile Win2003SP2x86 procexedump -D dump/ -p
>> >>>> 1684
>> >>>> Volatile Systems Volatility Framework 2.2
>> >>>> Process(V) ImageBase Name Result
>> >>>> ---------- ---------- -------------------- ------
>> >>>> 0x89b1e020 ---------- redactedxxxxx.e Error: Cannot acquire
>> >>>> process
>> >>>> AS
>> >>>> _______________________________________________
>> >>>> Vol-users mailing list
>> >>>> Vol-users(a)volatilityfoundation.org
I have a memory acquisition case which I don't know how to solve it: If a
limited user account on Windows XP SP3 is infected by malware, how could I
acquire a live memory dump from his account?
Could you help me please, thank you a lot.
Hi
We are trying to reproduce the steps to access application specific
informations from Android phones as Andrew Case demonstrated here:
http://digitalforensicssolutions.com/papers/android-memory-analysis.pdf (Page
17 and following)
We already have a Android Profile for our Goldfish kernel and are able to
run the existing plugins (e.g. linux_pslist) against the memory dump
acquired from the emulator.
Now we are writing our own Volatility Plugin according to Andrews
presentation. But so far we could not instantiate a DvmGlobals object as
Volatility does not know this specific type.
A snippet from our plugin:
gDvm = obj.Object("DvmGlobals", vm = self.addr_space, offset
= gDvm_addr)
When run, Volatility prints the following warning:
WARNING : volatility.obj : Cant find object DvmGlobals in profile
<volatility.plugins.overlays.linux.linux.LinuxAndroid_Goldfishx86 object at
0x3a57910>?
How can we get Volatility to know this object type?
We pulled libdvm.so from our emulator and disassembled it using
arm-linux-androideabi-objdump and found the following:
*000aa1a8 *<gDvm>:
This lines up with the DWARF informations from libdvm.so we compiled
ourselves:
<1><0x12484><DW_TAG_variable> DW_AT_name<"gDvm"> DW_AT_decl_file<0x00000001
dalvik/vm/Init.cpp> DW_AT_decl_line<0x00000032>
DW_AT_type<<0x0000c3b8>> DW_AT_external<yes(1)>
DW_AT_location<DW_OP_addr *0x000aa1a8*>
We aren't sure if this address actually is what we are looking for, that is
the offset of gDvm in the memory dump. Can you confirm this?
Thanks for any help
Alex & Dario
I've tried this on SuSE Linux 11.1 32-bit and 64-bit with the same results.
Following linux instructions for creating a profile, dwarfdump is unable to
locate module.ko.
https://code.google.com/p/volatility/wiki/LinuxMemoryForensics
user@linux:~> cat /etc/SuSE-release
SUSE Linux Enterprise Server 11 (i586)
VERSION = 11
PATCHLEVEL = 1
user@linux:~> uname -r
2.6.32.12-0.7-pae
user@linux:~> wget
https://volatility.googlecode.com/files/volatility-2.2.tar.gz
user@linux:~> tar -xzf volatility-2.2.tar.gz
user@linux:~> cd volatility-2.2/tools/linux
user@linux:~/volatility-2.2/tools/linux> sudo make
.... wait a very long time on first run ....
WARNING: modpost: Found 6 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
make[1]: Leaving directory `/usr/src/linux-2.6.32.12-0.7-obj/i386/pae'
dwarfdump -di module.ko > module.dwarf
dwarfdump ERROR: can't open module.ko
make: *** [dwarf] Error 1
user@linux:~/volatility-2.2/tools/linux> sudo make
CONFIG_DEBUG_SECTION_MISMATCH=y
....
make[1]: Leaving directory `/usr/src/linux-2.6.32.12-0.7-obj/i386/pae'
dwarfdump -di module.ko > module.dwarf
dwarfdump ERROR: can't open module.ko
make: *** [dwarf] Error 1
user@linux:~/volatility-2.2/tools/linux> dwarfdump -V
Tue Apr 10 11:43:32 PDT 2012
What am I missing?
Hi,
I have troubles getting the offset from an x86 Ubuntu system. Using GDB
is not showing the needed address:
# gdb --quiet /bin/bash
Leyendo simbolos desde /bin/bash...(no se encontraron simbolos de
depuracion)hecho.
(gdb) disassemble history_list
Dump of assembler code for function history_list:
0x080eb0c0 <+0>: push %ebp
0x080eb0c1 <+1>: mov 0x81159fc,%eax
0x080eb0c6 <+6>: mov %esp,%ebp
0x080eb0c8 <+8>: pop %ebp
0x080eb0c9 <+9>: ret
End of assembler dump.
(gdb)
Thoughts?
Thanks in advance!!