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
Hello,
I hope someone can help with this.
I am attempting to perform live memory analysis on linux virtual machines
using Xen, LibVMI and Volatility.
The command I am attempting to run is:
# python vol.py -l vmi://ubuntu-pvm-01 --profile=Linuxubuntux64 linux_psaux
I created the profile Linuxubuntux64 using the instructions on the
Volatility linux plugin page
I have included the pyvmiaddressspace.py file below:
# Volatility
#
# Copyright 2011 Sandia Corporation. Under the terms of Contract
# DE-AC04-94AL85000 with Sandia Corporation, the U.S. Government
# retains certain rights in this software.
#
# Authors:
# bdpayne(a)acm.org (Bryan D. Payne)
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or (at
# your option) any later version.
#
# This program is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
#
import volatility.addrspace as addrspace
import urllib
import pyvmi
#pylint: disable-msg=C0111
class PyVmiAddressSpace(addrspace.BaseAddressSpace):
"""
This address space can be used in conjunction with LibVMI
and the Python bindings for LibVMI. The end result is that
you can connect Volatility to view the memory of a running
virtual machine from any virtualization platform that
LibVMI supports.
For this AS to be instantiated, we need the VM name to
connect to.
"""
print "pyvmiaddressspace loaded"
order = 90
def __init__(self, base, config, layered = False, **kwargs):
print "__init__"
addrspace.BaseAddressSpace.__init__(self, base, config, **kwargs)
self.as_assert(base == None or layered, "Must be first Address
Space")
self.as_assert(config.LOCATION.startswith("vmi://"), "Location
doesn't start with vmi://")
self.name = urllib.url2pathname(config.LOCATION[6:])
self.vmi = pyvmi.init(self.name, "partial")
self.as_assert(not self.vmi is None, "VM not found")
self.dtb = self.get_cr3()
def read(self, addr, length):
print "read"
return self.zread(addr, length)
# assert addr < self.vmi.get_memsize(), "addr too big"
#
# end = addr+length
#
# if end > self.vmi.get_memsize():
# memory = None
# else:
# try:
# memory = self.vmi.read_pa(addr, length)
# except:
# memory = None
#
# return memory
# account for holes in physical mem
def zread(self, addr, length):
print "zread"
assert addr < self.vmi.get_memsize(), "addr too big"
end = addr+length
if end > self.vmi.get_memsize():
memory = None
else:
memory = self.vmi.zread_pa(addr, length)
assert memory != None, "memory is None"
print memory
return memory
def is_valid_address(self, addr):
print "is_valid_address"
if addr == None:
return False
return 4096 < addr < self.vmi.get_memsize() - 1
def write(self, addr, data):
print "write"
nbytes = self.vmi.write_pa(addr, data)
if nbytes != len(data):
return False
return True
def get_cr3(self):
print "get_cr3"
cr3 = self.vmi.get_vcpureg("cr3", 0);
return cr3
def get_available_addresses(self):
print "get_available_addresses"
yield (4096, self.vmi.get_memsize() - 1)
return
I have added the print statements myself in order to help with debugging
and the output is as follows:
root@xenbox:~/downloads/volatility-2.2# python vol.py -l
vmi://ubuntu-pvm-01 --profile=Linuxubuntux64 linux_psaux
Volatile Systems Volatility Framework 2.2
pyvmiaddressspace loaded
Pid Uid
Arguments
__init__
get_cr3
read
zread
read
zread
g�g�g02c�1c�c�
g�gP� 'pH�'�H�g -g�
g-
read
zread
g�
read
zread
g@�
read
zread
read
zread
g�
read
zread
g@�
read
zread
__init__
read
zread
g-
read
zread
root@xenbox:~/downloads/volatility-2.2#
I added the print statements to see if the addressspace plugin was
obtaining any information at all, because without them the only output was:
Volatile Systems Volatility Framework 2.2
Pid Uid Arguments
I am only just getting to grips with using Volatility so any advice as to
how to debug this issue would be much appreciated.
Thanks,
Mike
I am looking for an Android memory image to use Volatility on. Does anyone have (or know where I and get) a memory image I can look at?
If you are imaging Androids, can you reply offlist?
Thanks! Have a good week!
I've put together a package for you, http://michael-lambert.us/Rocra_130115b.zip
In it is the memory image, 130115b.w32. Infection time is approx 1637 CST on 15 Jan. svchost.exe PID is 464, parent is msmx21.exe PID 1404
Also included is the DOC file that drops and runs msmx21.exe which drops and runs svchost.exe
Thanks for looking at it.
Is anyone else looking at Red October?
Mike
Date: Fri, 18 Jan 2013 07:45:25 -0500
Subject: Re: [Vol-users] IAT hook question
From: michael.hale(a)gmail.com
To: dragonforen(a)hotmail.com
I got the exe from your website, thanks. Do you happen to have the original malware sample, or an md5 of the sample. There are a few things I'd like to check out that may be easier if I had a full memory dump.
Thanks, talk to you soon.
MHL
On Thu, Jan 17, 2013 at 3:49 PM, Mike Lambert <dragonforen(a)hotmail.com> wrote:
MHL,
I've tried sending twice, 2nd time passworded. Rejected both times. I've not seen anything on the Vol-list either. May be a size problem.
----
Reporting-MTA: dns;snt0-omc2-s18.snt0.hotmail.com
Received-From-MTA: dns;SNT118-W46
Arrival-Date: Thu, 17 Jan 2013 12:18:41 -0800
Final-Recipient: rfc822;michael.hale(a)gmail.com
Action: failed
Status: 5.5.0
Diagnostic-Code: smtp;552-5.7.0 Our system detected an illegal attachment on your message. Please
552-5.7.0 visit http://support.google.com/mail/bin/answer.py?answer=6590 to
552 5.7.0 review our attachment guidelines. m1si2744262obl.114
----
I have put it here. PW is Rocra http://michael-lambert.us/Rocra_svchost-exe_464_exe-dump.zip
Let me know when you receive the .exe successfully.
Thanks,
Mike
From: postmaster(a)mail.hotmail.com
To: dragonforen(a)hotmail.com
Date: Thu, 17 Jan 2013 12:26:58 -0800
Subject: Delivery Status Notification (Failure)
This is an automatically generated Delivery Status Notification.
Delivery to the following recipients failed.
michael.hale(a)gmail.com
--Forwarded Message Attachment--
From: dragonforen(a)hotmail.com
To: michael.hale(a)gmail.com
CC: vol-users(a)volatilityfoundation.org
Subject: RE: [Vol-users] IAT hook question
Date: Thu, 17 Jan 2013 14:26:31 -0600
First email was bounced by gmail. I've added a pw to the zip. PW is Rocra
Let me know when you have the .exe ok.
Thanks
Date: Thu, 17 Jan 2013 14:48:06 -0500
Subject: Re: [Vol-users] IAT hook question
From: michael.hale(a)gmail.com
To: dragonforen(a)hotmail.com
CC: vol-users(a)volatilityfoundation.org
Hmm sorry, I must be reading the GMER log incorrectly:
dragonforen(a)hotmail.com> wrote:
MHL,
Thank you very much. Attached is a ZIP. (Rocra is the short name) I used Volatility 2.1
C:\Python27\volatility-2.1>vol.py dlldump -f E:\Tests\130115b\Vol\130115b.w32 --profile=WinXPSP3x86 -p 464 -D E:\Tests\130115b\Vol\dlldump > E:\Tests\130115b\Vol\dlldump.txt
Volatile Systems Volatility Framework 2.1
C:\Python27\volatility-2.1>
Have a good day,
Mike
Date: Thu, 17 Jan 2013 12:47:54 -0500
Subject: Re: [Vol-users] IAT hook question
From: michael.hale(a)gmail.com
To: dragonforen(a)hotmail.com
CC: vol-users(a)volatilityfoundation.org
Mike, if you could use dlldump and extract kernel32.dll from pid 464 and send it to me, I'll take a look. The necessary pages of the PE file may just not be memory resident.
MHL
On Thu, Jan 17, 2013 at 12:31 PM, Mike Lambert <dragonforen(a)hotmail.com> wrote:
I am looking at a Red October infection. The malware is svchost PID 464, C:\Program Files\Windows NT\svchost.exe
GMER tells me that the IAT is hooked. See attached.
I wanted to see this with Volatility per the apihooks documentation here
http://code.google.com/p/volatility/wiki/CommandReferenceMal22
"As of Volatility 2.1, apihooks also detects hooked winsock procedure tables, includes an easier to read output format, supports multiple hop disassembly, and can optionally scan quicker through memory by ignoring non-critical processes and DLLs.
Here is an example of detecting IAT hooks installed by Coreflood. The hooking module is unknown because there is no module (DLL) associated with the memory in which the rootkit code exists. If you want to extract the code containing the hooks, you have a few options: "
I tried apihooks in Volatility 2.1 and 2.2, below is the result
C:\Python27\volatility-2.1>vol.py -f E:\Tests\130115b\Vol\130115b.w32 --profile=WinXPSP3x86 -p 464 apihooks
Volatile Systems Volatility Framework 2.1
C:\Python27\volatility-2.1>
-------------------------
C:\Python27\volatility-2.2>vol.py apihooks -f E:\Tests\130115b\Vol\130115b.w32 --profile=WinXPSP3x86 -p 464
Volatile Systems Volatility Framework 2.2
C:\Python27\volatility-2.2>
=========================
My question is, "what am I doing wrong?" It is probably something simple.
Thanks for the help,
Mike
_______________________________________________
Vol-users mailing list
Vol-users(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
On Thu, Jan 17, 2013 at 1:49 PM, Mike Lambert <dragonforen(a)hotmail.com> wrote:
> MHL,
>
> I've tried sending twice, 2nd time passworded. Rejected both times. I've not
> seen anything on the Vol-list either. May be a size problem.
>
> ----
> Reporting-MTA: dns;snt0-omc2-s18.snt0.hotmail.com
> Received-From-MTA: dns;SNT118-W46
> Arrival-Date: Thu, 17 Jan 2013 12:18:41 -0800
> Final-Recipient: rfc822;michael.hale(a)gmail.com
> Action: failed
> Status: 5.5.0
> Diagnostic-Code: smtp;552-5.7.0 Our system detected an illegal attachment on
> your message. Please
> 552-5.7.0 visit http://support.google.com/mail/bin/answer.py?answer=6590 to
> 552 5.7.0 review our attachment guidelines. m1si2744262obl.114
Gmail does pretty deep inspection of attachments, in this case
noticing a .exe file in the header of the ZIP archive:
$ zipinfo Rocra_svchost-exe_464_exe-dump.zip
Archive: Rocra_svchost-exe_464_exe-dump.zip 29582 bytes 2 files
-rwxa-- 2.0 fat 60928 Bl defN 16-Jan-13 14:44 svchost_executable.464.exe
-rw-a-- 2.0 fat 10543 Tl defN 16-Jan-13 14:46
130115b.w32_suspect_PID_464_volatility20_info.txt
2 files, 71471 bytes uncompressed, 29202 bytes compressed: 59.1%
I tend to strip extensions and send in encrypted zips when dealing
with Google services. Fantastic for everything except threat sharing.
:)
--
Darren Spruell
phatbuckett(a)gmail.com
MHL,
I've tried sending twice, 2nd time passworded. Rejected both times. I've not seen anything on the Vol-list either. May be a size problem.
----
Reporting-MTA: dns;snt0-omc2-s18.snt0.hotmail.com
Received-From-MTA: dns;SNT118-W46
Arrival-Date: Thu, 17 Jan 2013 12:18:41 -0800
Final-Recipient: rfc822;michael.hale(a)gmail.com
Action: failed
Status: 5.5.0
Diagnostic-Code: smtp;552-5.7.0 Our system detected an illegal attachment on your message. Please
552-5.7.0 visit http://support.google.com/mail/bin/answer.py?answer=6590 to
552 5.7.0 review our attachment guidelines. m1si2744262obl.114
----
I have put it here. PW is Rocra http://michael-lambert.us/Rocra_svchost-exe_464_exe-dump.zip
Let me know when you receive the .exe successfully.
Thanks,
Mike
From: postmaster(a)mail.hotmail.com
To: dragonforen(a)hotmail.com
Date: Thu, 17 Jan 2013 12:26:58 -0800
Subject: Delivery Status Notification (Failure)
This is an automatically generated Delivery Status Notification.
Delivery to the following recipients failed.
michael.hale(a)gmail.com
--Forwarded Message Attachment--
From: dragonforen(a)hotmail.com
To: michael.hale(a)gmail.com
CC: vol-users(a)volatilityfoundation.org
Subject: RE: [Vol-users] IAT hook question
Date: Thu, 17 Jan 2013 14:26:31 -0600
First email was bounced by gmail. I've added a pw to the zip. PW is Rocra
Let me know when you have the .exe ok.
Thanks
Date: Thu, 17 Jan 2013 14:48:06 -0500
Subject: Re: [Vol-users] IAT hook question
From: michael.hale(a)gmail.com
To: dragonforen(a)hotmail.com
CC: vol-users(a)volatilityfoundation.org
Hmm sorry, I must be reading the GMER log incorrectly:
dragonforen(a)hotmail.com> wrote:
MHL,
Thank you very much. Attached is a ZIP. (Rocra is the short name) I used Volatility 2.1
C:\Python27\volatility-2.1>vol.py dlldump -f E:\Tests\130115b\Vol\130115b.w32 --profile=WinXPSP3x86 -p 464 -D E:\Tests\130115b\Vol\dlldump > E:\Tests\130115b\Vol\dlldump.txt
Volatile Systems Volatility Framework 2.1
C:\Python27\volatility-2.1>
Have a good day,
Mike
Date: Thu, 17 Jan 2013 12:47:54 -0500
Subject: Re: [Vol-users] IAT hook question
From: michael.hale(a)gmail.com
To: dragonforen(a)hotmail.com
CC: vol-users(a)volatilityfoundation.org
Mike, if you could use dlldump and extract kernel32.dll from pid 464 and send it to me, I'll take a look. The necessary pages of the PE file may just not be memory resident.
MHL
On Thu, Jan 17, 2013 at 12:31 PM, Mike Lambert <dragonforen(a)hotmail.com> wrote:
I am looking at a Red October infection. The malware is svchost PID 464, C:\Program Files\Windows NT\svchost.exe
GMER tells me that the IAT is hooked. See attached.
I wanted to see this with Volatility per the apihooks documentation here
http://code.google.com/p/volatility/wiki/CommandReferenceMal22
"As of Volatility 2.1, apihooks also detects hooked winsock procedure tables, includes an easier to read output format, supports multiple hop disassembly, and can optionally scan quicker through memory by ignoring non-critical processes and DLLs.
Here is an example of detecting IAT hooks installed by Coreflood. The hooking module is unknown because there is no module (DLL) associated with the memory in which the rootkit code exists. If you want to extract the code containing the hooks, you have a few options: "
I tried apihooks in Volatility 2.1 and 2.2, below is the result
C:\Python27\volatility-2.1>vol.py -f E:\Tests\130115b\Vol\130115b.w32 --profile=WinXPSP3x86 -p 464 apihooks
Volatile Systems Volatility Framework 2.1
C:\Python27\volatility-2.1>
-------------------------
C:\Python27\volatility-2.2>vol.py apihooks -f E:\Tests\130115b\Vol\130115b.w32 --profile=WinXPSP3x86 -p 464
Volatile Systems Volatility Framework 2.2
C:\Python27\volatility-2.2>
=========================
My question is, "what am I doing wrong?" It is probably something simple.
Thanks for the help,
Mike
_______________________________________________
Vol-users mailing list
Vol-users(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
Hmm sorry, I must be reading the GMER log incorrectly:
IAT C:\Program Files\Windows NT\svchost.exe[464] @ C:\Program
Files\Windows NT\svchost.exe [KERNEL32.dll!GetFileType]
E80C244C
I thought that was saying functions in kernel32.dll's IAT were hooked, but
I think its saying the IAT entries in svchost.exe for kernel32 APIs are
hooked. So in that case I'd need you to use procexedump -p 464 and send the
extracted svchost.exe.
Also if that number at the end (E80C244C) is the address of the hook,
something is seriously wrong because that's an address in kernel space.
Hooray for log files with no meaningful labels ;-)
MHL
On Thu, Jan 17, 2013 at 1:09 PM, Mike Lambert <dragonforen(a)hotmail.com>wrote:
> MHL,
>
> Thank you very much. Attached is a ZIP. (Rocra is the short name) I used
> Volatility 2.1
>
> C:\Python27\volatility-2.1>vol.py dlldump -f
> E:\Tests\130115b\Vol\130115b.w32 --profile=WinXPSP3x86 -p 464 -D
> E:\Tests\130115b\Vol\dlldump > E:\Tests\130115b\Vol\dlldump.txt
>
> Volatile Systems Volatility Framework 2.1
>
> C:\Python27\volatility-2.1>
>
> Have a good day,
> Mike
>
> ------------------------------
> Date: Thu, 17 Jan 2013 12:47:54 -0500
> Subject: Re: [Vol-users] IAT hook question
> From: michael.hale(a)gmail.com
> To: dragonforen(a)hotmail.com
> CC: vol-users(a)volatilityfoundation.org
>
>
> Mike, if you could use dlldump and extract kernel32.dll from pid 464 and
> send it to me, I'll take a look. The necessary pages of the PE file may
> just not be memory resident.
>
> MHL
>
>
> On Thu, Jan 17, 2013 at 12:31 PM, Mike Lambert <dragonforen(a)hotmail.com>wrote:
>
> I am looking at a Red October infection. The malware is svchost PID 464,
> C:\Program Files\Windows NT\svchost.exe
>
> GMER tells me that the IAT is hooked. See attached.
>
> I wanted to see this with Volatility per the apihooks documentation here
> http://code.google.com/p/volatility/wiki/CommandReferenceMal22
>
> "As of Volatility 2.1, apihooks also detects hooked winsock procedure
> tables, includes an easier to read output format, supports multiple hop
> disassembly, and can optionally scan quicker through memory by ignoring
> non-critical processes and DLLs.
>
> Here is an example of detecting IAT hooks installed by Coreflood. The
> hooking module is unknown because there is no module (DLL) associated with
> the memory in which the rootkit code exists. If you want to extract the
> code containing the hooks, you have a few options: "
>
>
> I tried apihooks in Volatility 2.1 and 2.2, below is the result
>
> C:\Python27\volatility-2.1>vol.py -f E:\Tests\130115b\Vol\130115b.w32
> --profile=WinXPSP3x86 -p 464 apihooks
> Volatile Systems Volatility Framework 2.1
>
> C:\Python27\volatility-2.1>
>
> -------------------------
>
> C:\Python27\volatility-2.2>vol.py apihooks -f
> E:\Tests\130115b\Vol\130115b.w32 --profile=WinXPSP3x86 -p 464
> Volatile Systems Volatility Framework 2.2
>
> C:\Python27\volatility-2.2>
>
> =========================
>
> My question is, "what am I doing wrong?" It is probably something simple.
>
> Thanks for the help,
> Mike
>
>
> _______________________________________________
> Vol-users mailing list
> Vol-users(a)volatilityfoundation.org
> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>
>
>
I am looking at a Red October infection. The malware is svchost PID 464, C:\Program Files\Windows NT\svchost.exe
GMER tells me that the IAT is hooked. See attached.
I wanted to see this with Volatility per the apihooks documentation here
http://code.google.com/p/volatility/wiki/CommandReferenceMal22
"As of Volatility 2.1, apihooks also detects hooked winsock procedure tables, includes an easier to read output format, supports multiple hop disassembly, and can optionally scan quicker through memory by ignoring non-critical processes and DLLs.
Here is an example of detecting IAT hooks installed by Coreflood. The hooking module is unknown because there is no module (DLL) associated with the memory in which the rootkit code exists. If you want to extract the code containing the hooks, you have a few options: "
I tried apihooks in Volatility 2.1 and 2.2, below is the result
C:\Python27\volatility-2.1>vol.py -f E:\Tests\130115b\Vol\130115b.w32 --profile=WinXPSP3x86 -p 464 apihooks
Volatile Systems Volatility Framework 2.1
C:\Python27\volatility-2.1>
-------------------------
C:\Python27\volatility-2.2>vol.py apihooks -f E:\Tests\130115b\Vol\130115b.w32 --profile=WinXPSP3x86 -p 464
Volatile Systems Volatility Framework 2.2
C:\Python27\volatility-2.2>
=========================
My question is, "what am I doing wrong?" It is probably something simple.
Thanks for the help,
Mike
Hello All,
We were writing to announce the first annual Volatility framework
plugin writing contest:
http://volatility-labs.blogspot.com/2013/01/the-1st-annual-volatility-frame…
This contest is modeled after the well-known Hex-Rays plugin contest,
and we hope to attract the same level of high-quality submissions as
seen in the IDA contests.
To the winners we offer a variety of cash prizes, recognition, and a
chance to speak at our yearly conference.
If you have any questions or comments please contact me directly or
use the contact information listed in the blog post.
Thanks,
Andrew
