Cool.
If it becomes an annoyance to type -f --profile --kdbg --dtb, you can
always dump those in environment variables or a configuration file [1] and
then just invoke the much shorter vol.py pslist, vol.py psscan, etc.
MHL
[1].
On Thu, Oct 4, 2012 at 5:21 PM, David Kovar <dkovar(a)gmail.com> wrote:
Greetings,
That did the trick! (And found some stuff that either wasn't present or
wasn't obvious in Redline.)
Thank you very much.
-David
On Oct 4, 2012, at 4:16 PM, Michael Hale Ligh <michael.hale(a)gmail.com>
wrote:
Hey David,
Thanks for working with us to figure out the problem. Based on your
imageinfo output:
Suggested Profile(s) : Win2003SP0x86, Win2003SP1x86,
Win2003SP2x86
AS Layer1 : JKIA32PagedMemoryPae (Kernel AS)
AS Layer2 : FileAddressSpace (/Users/kovar/Mem
Analysis/redacted_memdump.mem)
PAE type : PAE
DTB : 0x1595000L
KDBG : 0x808943e0
Number of Processors : 2
Image Type (Service Pack) : 2
KPCR for CPU 0 : 0xffdff000
KPCR for CPU 1 : 0xf772f000
KUSER_SHARED_DATA : 0xffdf0000
Image date and time : 2012-10-01 19:31:06 UTC+0000
Image local date and time : 2012-10-01 13:31:06 -0600
Although there are three suggested profiles at the top, a little lower
down it says the Image Type is Service Pack 2 - so IMO it sounds like the
real profile is Win2003SP2x86. The AS Layer1 is JKIA32PagedMemoryPae
which indicates its definitely a 32-bit memory dump and not x64. The fact
that you see KPCR for CPU 0 and CPU 1 means we can dereference points in
virtual space and properly translate them to physical addresses, which
indicates the DTB of 0x1595000 should be valid. The value shown for the
KDBG (0x808943e0) *can* be incorrect sometimes (which is why we have
kdbgscan) but you ran kdbgscan and it only found one KDBG in physical space
at 0x8943e0 (must be the one at virtual address 0x808943e0).
What I would suggest is combining these pieces of evidence and supply them
explicitly to volatility like this:
$ python vol.py -f <IMAGE> --profile=Win2003SP2x86 --kdbg=0x808943e0
--dtb=0x1595000 <PLUGIN>
If you could let us know the output of that sequence when using the
plugins pslist and psscan, we would appreciate it!
Thanks,
MHL
On Thu, Oct 4, 2012 at 2:58 PM, David Kovar <dkovar(a)gmail.com> wrote:
Greetings,
I am unable to get a viable profile for two different images. I built
V2.2 on a MacBook Pro running 10.8.2.
This one may be a bad image:
<kdbgscan returns silently>
DawnTreader:Mem Analysis kovar$ vol.py -f *dmp kdbgscan
Volatile Systems Volatility Framework 2.2
DawnTreader:Mem Analysis kovar$ vol.py -f *dmp imageinfo
Volatile Systems Volatility Framework 2.2
Determining profile based on KDBG search...
Suggested Profile(s) : No suggestion (Instantiated with no
profile)
AS Layer1 : FileAddressSpace (/Users/kovar/Mem
Analysis/redacted-27-09-2012-10-47-50.dmp)
PAE type : No PAE
----------------
But this one loads in Mandiant Redline but Volatility will not produce
any valid results. I've tried all three profiles with no success.
DawnTreader:Mem Analysis kovar$ vol.py -f *mem imageinfo
Volatile Systems Volatility Framework 2.2
Determining profile based on KDBG search...
Suggested Profile(s) : Win2003SP0x86, Win2003SP1x86,
Win2003SP2x86
AS Layer1 : JKIA32PagedMemoryPae (Kernel AS)
AS Layer2 : FileAddressSpace (/Users/kovar/Mem
Analysis/redacted_memdump.mem)
PAE type : PAE
DTB : 0x1595000L
KDBG : 0x808943e0
Number of Processors : 2
Image Type (Service Pack) : 2
KPCR for CPU 0 : 0xffdff000
KPCR for CPU 1 : 0xf772f000
KUSER_SHARED_DATA : 0xffdf0000
Image date and time : 2012-10-01 19:31:06 UTC+0000
Image local date and time : 2012-10-01 13:31:06 -0600
DawnTreader:Mem Analysis kovar$ vol.py -f *mem kdbgscan
Volatile Systems Volatility Framework 2.2
**************************************************
Instantiating KDBG using: /Users/kovar/Mem Analysis/redacted.mem
Win2003SP0x86 (5.2.3789 32bit)
Offset (P) : 0x8943e0
KDBG owner tag check : True
Profile suggestion (KDBGHeader): Win2003SP1x86
Version64 : 0x8943b8 (Major: 15, Minor: 3790)
PsActiveProcessHead : 0x808ad0c8
PsLoadedModuleList : 0x808a6ea8
KernelBase : 0x80800000
**************************************************
Instantiating KDBG using: /Users/kovar/Mem Analysis/redacted.mem
Win2003SP0x86 (5.2.3789 32bit)
Offset (P) : 0x8943e0
KDBG owner tag check : True
Profile suggestion (KDBGHeader): Win2003SP2x86
Version64 : 0x8943b8 (Major: 15, Minor: 3790)
PsActiveProcessHead : 0x808ad0c8
PsLoadedModuleList : 0x808a6ea8
KernelBase : 0x80800000
**************************************************
Instantiating KDBG using: /Users/kovar/Mem Analysis/redacted.mem
Win2003SP0x86 (5.2.3789 32bit)
Offset (P) : 0x8943e0
KDBG owner tag check : True
Profile suggestion (KDBGHeader): Win2003SP0x86
Version64 : 0x8943b8 (Major: 15, Minor: 3790)
PsActiveProcessHead : 0x808ad0c8
PsLoadedModuleList : 0x808a6ea8
KernelBase : 0x80800000
DawnTreader:Mem Analysis kovar$ vol.py -f *mem --profile=Win2003SP0x86
pslist
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
IA32PagedMemoryPae: Module disabled
JKIA32PagedMemoryPae: No base Address Space
IA32PagedMemory: Module disabled
LimeAddressSpace: Invalid Lime header signature
WindowsHiberFileSpace32: No xpress signature found
WindowsCrashDumpSpace64: Header signature invalid
WindowsCrashDumpSpace32: Header signature invalid
AMD64PagedMemory: Incompatible profile Win2003SP0x86 selected
JKIA32PagedMemory: No valid DTB found
IA32PagedMemoryPae: Module disabled
JKIA32PagedMemoryPae: No valid DTB found
IA32PagedMemory: Module disabled
FileAddressSpace: Must be first Address Space
-----
Thanks for any help you might be able to offer.
-David
_______________________________________________
Vol-users mailing list
Vol-users(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users