Hello,
Over the last week or so, when I've done an svn update on the
2.1_alpha code, I've been receiving the following errors:
Volatile Systems Volatility Framework 2.1_alpha
*** Failed to import
volatility.plugins.overlays.windows.win2k3_sp2_x64 (AttributeError:
'module' object has no attribute 'AbstractWindowsX86')
*** Failed to import volatility.plugins.overlays.windows.win7_sp0_x86
(AttributeError: 'module' object has no attribute
'AbstractWindowsX86')
*** Failed to import volatility.plugins.zeusscan1 (AttributeError:
'module' object has no attribute 'ImpScan')
*** Failed to import
volatility.plugins.overlays.windows.win2k3_sp1_x86 (AttributeError:
'module' object has no attribute 'AbstractWindowsX86')
*** Failed to import volatility.plugins.zeusscan2 (AttributeError:
'module' object has no attribute 'ApiHooks')
*** Failed to import volatility.plugins.overlays.windows.vista_sp1_x86
(AttributeError: 'module' object has no attribute
'AbstractWindowsX86')
*** Failed to import volatility.plugins.overlays.windows.win7_sp1_x86
(AttributeError: 'module' object has no attribute
'AbstractWindowsX86')
*** Failed to import volatility.plugins.overlays.windows.vista_sp2_x86
(AttributeError: 'module' object has no attribute
'AbstractWindowsX86')
*** Failed to import
volatility.plugins.overlays.windows.win2k3_sp1_x64 (AttributeError:
'module' object has no attribute 'AbstractWindowsX86')
*** Failed to import volatility.plugins.overlays.windows.xp_sp3_x86
(AttributeError: 'module' object has no attribute 'nt_types')
*** Failed to import volatility.plugins.evtlogs (AttributeError:
'module' object has no attribute 'LdrModules')
*** Failed to import volatility.plugins.overlays.windows.vista_sp1_x64
(AttributeError: 'module' object has no attribute
'AbstractWindowsX86')
*** Failed to import
volatility.plugins.overlays.windows.win2k3_sp0_x86 (AttributeError:
'module' object has no attribute 'AbstractWindowsX86')
*** Failed to import volatility.plugins.overlays.windows.win7_sp1_x64
(AttributeError: 'module' object has no attribute
'AbstractWindowsX86')
*** Failed to import
volatility.plugins.overlays.windows.win2k3_sp2_x86 (AttributeError:
'module' object has no attribute 'AbstractWindowsX86')
*** Failed to import volatility.plugins.overlays.windows.vista_sp0_x64
(AttributeError: 'module' object has no attribute
'AbstractWindowsX86')
*** Failed to import volatility.plugins.overlays.windows.vista_sp2_x64
(AttributeError: 'module' object has no attribute
'AbstractWindowsX86')
*** Failed to import volatility.plugins.overlays.windows.xp_sp2_x86
(AttributeError: 'module' object has no attribute 'nt_types')
*** Failed to import volatility.plugins.timeliner (AttributeError:
'module' object has no attribute 'LdrModules')
*** Failed to import volatility.plugins.overlays.windows.vista_sp0_x86
(AttributeError: 'module' object has no attribute
'AbstractWindowsX86')
*** Failed to import volatility.plugins.overlays.windows.win7_sp0_x64
(AttributeError: 'module' object has no attribute
'AbstractWindowsX86')
(This is with revision 1558)
This is just from doing an imageinfo. I was thinking since it
includes plugins that some plugins need to be updated for 2.1, but I
didn't want to make the assumption.
It does finish the KDBG search and give me the correct profile, so
it's parsing the dump. Just wasn't sure about the errors.
Thanks,
Tom
I have found an interesting result and have a fair amount of data to share.
Bottom line is that connscan may have missed (and miss reported) some connections (see memory image).
2 IPs are missing and note the ports recorded by cports and those reported by V2.0 connscan. Check the attached xls search hits, where did port 1088 and 1064 come from?
I can provide a copy of the memory image! Imager is win32dd.exe.
Here is the IP connection record I have from cports:
Date Time Log action PID Program Name Proto Source IP Destination IP
3/12/2012 3:53:10 PM Added 1344 fix_pack.exe TCP 192.168.1.44:1063 212.117.175.34:80
3/12/2012 3:53:10 PM Added 1344 fix_pack.exe TCP 192.168.1.44:1065 98.142.243.60:80
3/12/2012 3:53:10 PM Added 1344 fix_pack.exe TCP 192.168.1.44:1066 98.142.243.60:80
3/12/2012 3:53:11 PM Removed 1344 fix_pack.exe TCP 192.168.1.44:1065 98.142.243.60:80
3/12/2012 3:53:11 PM Removed 1344 fix_pack.exe TCP 192.168.1.44:1066 98.142.243.60:80
3/12/2012 3:53:45 PM Added 1344 fix_pack.exe TCP 192.168.1.44:1078 92.123.68.97:80
3/12/2012 3:54:06 PM Added 1344 fix_pack.exe TCP 192.168.1.44:1080 98.142.243.60:80
3/12/2012 3:54:06 PM Removed 1344 fix_pack.exe TCP 192.168.1.44:1078 92.123.68.97:80
3/12/2012 3:54:27 PM Removed 1344 fix_pack.exe TCP 192.168.1.44:1080 98.142.243.60:80
3/12/2012 3:54:30 PM Added 1344 fix_pack.exe TCP 192.168.1.44:1087 98.142.243.60:80
3/12/2012 3:54:31 PM Removed 1344 fix_pack.exe TCP 192.168.1.44:1063 212.117.175.34:80
3/12/2012 3:54:31 PM Removed 1344 fix_pack.exe TCP 192.168.1.44:1087 98.142.243.60:80
Here is the result of V2.0 connscan:
Scan for connection objects (connscan):
Offset Local Address Remote Address Pid
---------- ------------------------- ------------------------- ------
0x041484c0 192.168.1.44:1088 98.142.243.60:80 1344
0x04193278 192.168.1.44:1093 65.54.51.29:443 3756
0x041cdc40 192.168.1.44:1064 98.142.243.60:80 1344
Attached is search results of the memory image, with memory offsets. (A few are dups and that may be the Win32dd imager)
Where did ports 1088 and 1064 come from?
If anyone wants a copy of the memory image, it is 115 MB
Mike
When clicking on the list of Volatility plugins, I go to
http://www.forensicswiki.org/wiki/List_of_Volatility_Plugins
>From the web page
"Here is a list of the published plugins for the Volatility 1.3 framework"
I do not see any "installation instructions"
Do these plugins just get copied to C:\Python27\Volatility-1.3_Beta\memory_plugins ?
Also, is there a like page for v2.0 ?
>From http://code.google.com/p/volatility/wiki/FAQ#Where_do_I_find_the_"malware"_plugins there is a link to
http://malwarecookbook.googlecode.com/svn/trunk/malware.py
what Volatility version is the plugin for? I do not see Volatility version number in .py files so I get a little confused which is for which. Will plugins have "for Volaitility vX" in the future?
Maybe I'm just not getting it.
Sorry,
Mike
Meant to send this to the list not just the OP.
-------- Original Message --------
Subject: Re: [Vol-users] BSOD while collecting a memory image
Date: Sun, 11 Mar 2012 11:07:54 -0400
From: George M. Garner Jr. <ggarner_online(a)gmgsystemsinc.com>
To: Mike Lambert <dragonforen(a)hotmail.com>
Mike,
> Is there malware that stops all imaging programs.. <
Don't know about ALL imaging programs. There is anecdotal evidence of
malware that stops some imaging programs and then allows others to run.
Smart malware doesn't stop anything from running. Everything appears
to be normal. Welcome to the matrix.
Malware has for a long time sought to identify "white hat" software.
Until recently this has been almost exclusively based on the file names
of common anti-rootkit and IR packages. You could effectively defeat
the anti-forensic techniques simply by renaming your tools. More
recently, however, rootkits have begun to use other information to
identify IR tools, in particular, the certificate info for signed PE
executables. This is much more problematic. Particularly with the
widespread adoption of 64-bit Windows, all device drivers must be signed
and the signature can be used to identify your tools in an unambiguous
way. There is a paper that will be published in the near future on
developing a blackhat scanner. If you investigate sophisticated malware
you should be thinking about getting your own code signing certificate(s).
I believe that Sinowal was/is a "public" rootkit that attempts to remove
itself from memory during hibernation. Whether a rootkit successfully
removes all traces of itself from a hibernation file is another matter.
Regards,
g.
I was testing different memory imaging programs on a 64 bit Windows 7 with 8 GB of memory and found that I could (not on purpose) BSOD the system. That put a dent in determining which memory imaging products are compatible with Volatility.
Then I wondered if the "full memory dump on blue screen would be compatible". I'm looking into that now. A couple of problems are 1. "Full memory" dump is not available on the machines I'm working on so I don't know if I can just set it and go, or, does the system have to be booted with that option set. 2. Is the "full memory dump" comaptible with Volatility? 3. Keyboard generated crash dump is an option that has to be set and the system rebooted so that wouldn't work as a backup plan.
My ultimate backup plan is to hibernate and convert the hiberfil.sys. That works so I'm not stuck with nothing.
Question: Has someone gotten a full memory dump on BSOD and successfully processed it with Volatility?
Question: Has anyone else thought about how to deal with BSOD and analysis? If it is not something that the list is interested in, we could take this offline.
Have a good day everyone!
Mike Lambert
Hey all,
So we're moving to Windows 7 (64-bit) in our environment, and our
current method of getting memory images off of machines has changed.
So we're using EnCase Enterprise to grab memory dumps. Then what I've
been doing is using FTK Imager to convert that to a DD image, and we
run it through our regular tool. I run the same DD image through
Volatility. I'm running Volatility on OS X Lion.
Recently, I've noticed when I'm just doing an imageinfo with
Volatility (both 2.0 and 2.1_alpha), I'm getting the following:
Volatile Systems Volatility Framework 2.0
Determining profile based on KDBG search...
Suggested Profile(s) : No suggestion (Instantiated with no profile)
AS Layer1 : FileAddressSpace (memory.bin)
PAE type : No PAE
So my first thought was is was an issue with converting an E01 to a DD
image. So I ran a test on a standard Windows 7 build in our
organization.
1) Do a memory collection with EnCase, convert to DD with FTK Imager
2) Do a memory collection with FDPro
3) Do a memory collection with DumpIt
Run the imageinfo command in both Volatility 2.0 and the 2.1_alpha
code, and the results were the same with one exception. With the 2.0
code, and the DumpIt memory dump, I got the following:
Volatile Systems Volatility Framework 2.0
Determining profile based on KDBG search...
Suggested Profile(s) : Win7SP0x64 (Instantiated with no profile)
AS Layer1 : FileAddressSpace (memory.raw)
PAE type : No PAE
But if I try to run another command with --profile=Win7SP0x64 I get:
Volatile Systems Volatility Framework 2.0
ERROR : volatility.addrspace: Invalid profile Win7SP0x64 selected
I'm just wondering if there's something funky with my Volatility
installation, or if there could be something I need to check in our 7
build that could be causing this.
Thanks ahead of time,
Tom
Tom,
> If you have anything I'd love to see it.
Unfortunately nothing for public distribution. We provide our customers
with a test framework which is intended to help validate our tools for
the production of evidence suitable for admission in a court of law. A
lot of work remains to be done.
As you know volatile evidence collection tools cannot be validated in
the same manner as traditional computer forensic tools which are
designed for the acquisition of non-volatile storage media. There is no
"image" that you can acquire and then reproduce. Running computer
systems are often modeled as a continuous time stochastic process. By
its nature a continuous time stochastic process cannot be measured in
its entirety. It can only be sampled.
Nevertheless, while they cannot be measured in their entirety, running
computer systems do possess two attributes which may make it possible to
validate, or rather invalidate, memory acquisition tools. The first
attribute is that a running computer system is a STRUCTURED stochastic
process. It is not entirely random and could not run if it were. The
operating system, processor and other hardware define certain structural
elements the presence of which may be inferred merely by the fact that
the system is running. These structural elements CAN be measured and if
they are not found in precisely the right location then your memory
"dump" is crap.
The second attribute derives from the fact that Microsoft Windows (and
probably most other general purpose operating systems) provide an API
which permits the programmer/user to define a discrete time stochastic
process within the context of the larger continuous time stochastic
process. By this I mean that you can load and lock a block of data with
a known hash value into memory at a fixed location. You can then
acquire the memory "dump" and attempt to recover the data block from the
memory dump. If the number of samples is sufficiently large and the
location of the samples is representative with respect to the location
(below 4 GiB, above 4 GiB, "unmanaged" memory) and architecture (Intel,
AMD, NUMA, non-NUMA) and amount of memory (< 4 GiB, > 4 GiB, > 16
GiB***) then it should be possible to make an inference as to the
reliability of acquisition of memory as a whole based upon the
reliability of acquisition of the samples.
In any event, being able to exclude particularly unreliable memory
acquisition tools would be a step forward, even if it falls short of
validating the tools that remain for LE evidentiary purposes.
I though that Volatility might be able to play a useful role in
developing a public test framework if it were reworked to identify the
present or missing structural elements (e.g. the missing page tables) in
a documentable way. I asked Aaron about it last year but never got any
response.
Regards,
gmg.
Hey all,
So I went through the install docs for Linux on the wiki to install
Volatility on my MacBook Pro running OS X Lion. I'm testing it using
the samples from the Malware Cookbook (stuxnet.vmem in this case), and
just doing:
python ~/volatility-read-only/vol.py -f stuxnet.vmem imageinfo
I'm getting the following output:
Volatile Systems Volatility Framework 2.1_alpha
Determining profile based on KDBG search...
Traceback (most recent call last):
File "/Users/e18529/volatility-read-only/vol.py", line 135, in <module>
main()
File "/Users/e18529/volatility-read-only/vol.py", line 126, in main
command.execute()
File "/Users/e18529/volatility-read-only/volatility/commands.py",
line 101, in execute
func(outfd, data)
File "/Users/e18529/volatility-read-only/volatility/plugins/imageinfo.py",
line 37, in render_text
for k, v in data:
File "/Users/e18529/volatility-read-only/volatility/plugins/imageinfo.py",
line 47, in calculate
suglist = [ s for s, _, _ in kdbg.KDBGScan.calculate(self)]
File "/Users/e18529/volatility-read-only/volatility/plugins/kdbgscan.py",
line 95, in calculate
buf = addrspace.BufferAddressSpace(self._config)
File "/Users/e18529/volatility-read-only/volatility/addrspace.py",
line 161, in __init__
BaseAddressSpace.__init__(self, None, config, **kwargs)
File "/Users/e18529/volatility-read-only/volatility/addrspace.py",
line 68, in __init__
self.profile = self._set_profile(config.PROFILE)
File "/Users/e18529/volatility-read-only/volatility/addrspace.py",
line 90, in _set_profile
ret = registry.PROFILES[profile_name]()
File "/Users/e18529/volatility-read-only/volatility/obj.py", line
879, in __init__
self.reset()
File "/Users/e18529/volatility-read-only/volatility/obj.py", line
906, in reset
self.load_modifications()
File "/Users/e18529/volatility-read-only/volatility/obj.py", line
960, in load_modifications
mod.modification(self)
File "/Users/e18529/volatility-read-only/volatility/plugins/overlays/windows/ssdt_vtypes.py",
line 57, in modification
profile.additional['syscalls'] = module.syscalls
AttributeError: 'NoneType' object has no attribute 'syscalls'
So I'm guessing I still don't have something configured correctly.
Thanks ahead of time,
Tom
Thank you for your answers.
> There is no such thing as "the address spaces of all processes."
What I meant to say was that moddump plugin uses find_space function to find a process whose address space maps the searched driver.
def find_space(self, addr_space, procs, mod_base):
"""Search for an address space (usually looking for a GUI process)"""
if addr_space.is_valid_address(mod_base):
return addr_space
for proc in procs:
ps_ad = proc.get_process_address_space()
if ps_ad != None:
if ps_ad.is_valid_address(mod_base):
return ps_ad
return None
Hello,
I am doing some research on Windows kernel, using volatility.
I need to get the mapping from virtual addresses to physical ones for kernel memory.
As far as I know, every process maps kernel virtual addresses (addresses upper than 0x7fffffff in 32bit Windows versions with 3GB split disabled) to physical ones in the same way.
In other words, the address spaces relative to every process are equals for kernel virtual addresses.
Is this always true?
I noticed that some plugins (e.g. kdbgscan) use the address space of the process "Idle", others use the address spaces of all processes (e.g. modscan).
Which is the right way to proccede to develop a plugin to get the full virtual to physicall mapping for kernel addresses?
Thank you.
