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.
Hi All,
I was looking at the Stuxnet footprint blog post (who is excellent btw) and
I was interested by the userhandles plugin.
./vol.py userhandles -t TYPE_WINDOW
http://mnin.blogspot.com/2011/06/examining-stuxnets-footprint-in-memory.html
I can't find this plugin for volatility... Does it comes with another
plugin? Where can I download it?
Thanks in advance,
Sebastien
Glad I could help!
Yep, I've seen this before many times ;-)
All the best,
-gleeda
-----Original Message-----
From: Mike Lambert <dragonforen(a)hotmail.com>
Date: Mon, 27 Feb 2012 17:02:15
To: <jamie.levy(a)gmail.com>
Subject: RE: [Vol-users] stings input file format question
My thanks! Well you called that one! I was using Encase's "Export" to output a text file of the offsets of the hits from the search result tab. Encase outputs unicode text.
I just need to put a new step in the process, convert it to ANSI before running it with the strings command.
And it does have a funky befinning of file marker....
You must have seen this before?
Best,
Mike
> Date: Mon, 27 Feb 2012 16:39:08 -0500
> Subject: Re: [Vol-users] stings input file format question
> From: jamie.levy(a)gmail.com
> To: dragonforen(a)hotmail.com
>
> hrmmmmm I don't see anything obviously wrong here... But since you
> said these offsets are from EnCase, how were they obtained? By
> EnScript to a file, copy+paste from the console or some other method?
> I'm just curious if the offsets were exported in ASCII or EnCase's
> default UTF-16. Also sometimes when exporting in unicode, there's a
> funky corrupt BOM that EnCase uses that might be messing things up...
> I'm just trying to think of things that might have gone wrong here.
>
> Maybe you could try copy and pasting a few of these "Ypycub" entries
> into a new text file and running the strings plugin again to see.
>
> All the best,
>
> -gleeda
>
>
> On Mon, Feb 27, 2012 at 4:06 PM, Mike Lambert <dragonforen(a)hotmail.com> wrote:
> > I am mystified why I see the following: in one case I get output from
> > strings and the other I get an input file format error. I have tried this
> > with 1.3 and 2.0 and get the same result. It takes 1.3 a looonnngg time to
> > return the error, 2.0 returs the error quickly.
> >
> > I thought the reason may be length, so I broke up the Ypycub offsets into
> > increasingly smaller input files; no success was achived with the smaller
> > input files.
> > I don't see a format difference in these 2 files.
> >
> > The offsets come from an Encase search of 120225b.mem. It is a 458MB
> > WinXPSP3x86 image converted from hiberfil.sys.
> >
> >
> > Vol 1.3 example: The same result is seen with Vol 2.0
> >
> > The input file is:
> >
> > 357229672:Glows
> > 280642408:Glows
> > 257105340:Glows
> > 113457472:Glows
> > 357230696:Glows
> >
> >
> > C:\Python27\Volatility-1.3_Beta>python volatility strings -f
> > e:\tests\120225b\IRinfo\120225b.mem -s 120225b_Glows_offsets.txt
> >
> > 357229672 [kernel:df864468 ] Glows
> > 280642408 [1456:45b8368 ] Glows
> > 257105340 [kernel:e1ec1dbc ] Glows
> > 113457472 [1456:2ac0940 ] Glows
> > 357230696 [kernel:df864868 ] Glows
> >
> > ----------------------cut-here-------------------------
> > The input file is:
> >
> > 7744388:Ypycub
> > 10830274:Ypycub
> > 70385414:Ypycub
> > 70918297:Ypycub
> > 70918649:Ypycub
> > 73375514:Ypycub
> > 91390974:Ypycub
> > 104879126:Ypycub
> > 104879154:Ypycub
> > 132968006:Ypycub
> > 215776800:Ypycub
> > 232868024:Ypycub
> > 232869190:Ypycub
> > 237434963:Ypycub
> > 237434991:Ypycub
> > 256642118:Ypycub
> > 285030170:Ypycub
> > 310449659:Ypycub
> > 310449687:Ypycub
> > 314178656:Ypycub
> > 325974496:Ypycub
> > 327972307:Ypycub
> > 327972335:Ypycub
> > 338814062:Ypycub
> > 338814854:Ypycub
> > 339229856:Ypycub
> > 339763304:Ypycub
> > 339763544:Ypycub
> > 339893168:Ypycub
> > 340101984:Ypycub
> > 343215259:Ypycub
> > 343215287:Ypycub
> > 357229759:Ypycub
> > 361836122:Ypycub
> > 367889650:Ypycub
> > 455348611:Ypycub
> > 455348639:Ypycub
> >
> >
> > C:\Python27\Volatility-1.3_Beta>python volatility strings -f
> > e:\tests\120225b\IRinfo\120225b.mem -s 120225b_Ypycub_offsets.txt
> >
> > Usage: strings [options] (see --help)
> > volatility: error: String file format invalid.
> >
> >
> > Thanks for any assistance.
> >
> > Mike
> >
> >
> >
> >
> >
> > _______________________________________________
> > Vol-users mailing list
> > Vol-users(a)volatilesystems.com
> > http://lists.volatilesystems.com/mailman/listinfo/vol-users
> >
>
>
>
> --
> PGP Fingerprint: 2E87 17A1 EC10 1E3E 11D3 64C2 196B 2AB5 27A4 AC92
Sorry I meant for this to go to the list also:
On Mon, Feb 27, 2012 at 4:39 PM, Jamie Levy <jamie.levy(a)gmail.com> wrote:
> hrmmmmm I don't see anything obviously wrong here... But since you
> said these offsets are from EnCase, how were they obtained? By
> EnScript to a file, copy+paste from the console or some other method?
> I'm just curious if the offsets were exported in ASCII or EnCase's
> default UTF-16. Also sometimes when exporting in unicode, there's a
> funky corrupt BOM that EnCase uses that might be messing things up...
> I'm just trying to think of things that might have gone wrong here.
>
> Maybe you could try copy and pasting a few of these "Ypycub" entries
> into a new text file and running the strings plugin again to see.
>
> All the best,
>
> -gleeda
>
>
> On Mon, Feb 27, 2012 at 4:06 PM, Mike Lambert <dragonforen(a)hotmail.com> wrote:
>> I am mystified why I see the following: in one case I get output from
>> strings and the other I get an input file format error. I have tried this
>> with 1.3 and 2.0 and get the same result. It takes 1.3 a looonnngg time to
>> return the error, 2.0 returs the error quickly.
>>
>> I thought the reason may be length, so I broke up the Ypycub offsets into
>> increasingly smaller input files; no success was achived with the smaller
>> input files.
>> I don't see a format difference in these 2 files.
>>
>> The offsets come from an Encase search of 120225b.mem. It is a 458MB
>> WinXPSP3x86 image converted from hiberfil.sys.
>>
>>
>> Vol 1.3 example: The same result is seen with Vol 2.0
>>
>> The input file is:
>>
>> 357229672:Glows
>> 280642408:Glows
>> 257105340:Glows
>> 113457472:Glows
>> 357230696:Glows
>>
>>
>> C:\Python27\Volatility-1.3_Beta>python volatility strings -f
>> e:\tests\120225b\IRinfo\120225b.mem -s 120225b_Glows_offsets.txt
>>
>> 357229672 [kernel:df864468 ] Glows
>> 280642408 [1456:45b8368 ] Glows
>> 257105340 [kernel:e1ec1dbc ] Glows
>> 113457472 [1456:2ac0940 ] Glows
>> 357230696 [kernel:df864868 ] Glows
>>
>> ----------------------cut-here-------------------------
>> The input file is:
>>
>> 7744388:Ypycub
>> 10830274:Ypycub
>> 70385414:Ypycub
>> 70918297:Ypycub
>> 70918649:Ypycub
>> 73375514:Ypycub
>> 91390974:Ypycub
>> 104879126:Ypycub
>> 104879154:Ypycub
>> 132968006:Ypycub
>> 215776800:Ypycub
>> 232868024:Ypycub
>> 232869190:Ypycub
>> 237434963:Ypycub
>> 237434991:Ypycub
>> 256642118:Ypycub
>> 285030170:Ypycub
>> 310449659:Ypycub
>> 310449687:Ypycub
>> 314178656:Ypycub
>> 325974496:Ypycub
>> 327972307:Ypycub
>> 327972335:Ypycub
>> 338814062:Ypycub
>> 338814854:Ypycub
>> 339229856:Ypycub
>> 339763304:Ypycub
>> 339763544:Ypycub
>> 339893168:Ypycub
>> 340101984:Ypycub
>> 343215259:Ypycub
>> 343215287:Ypycub
>> 357229759:Ypycub
>> 361836122:Ypycub
>> 367889650:Ypycub
>> 455348611:Ypycub
>> 455348639:Ypycub
>>
>>
>> C:\Python27\Volatility-1.3_Beta>python volatility strings -f
>> e:\tests\120225b\IRinfo\120225b.mem -s 120225b_Ypycub_offsets.txt
>>
>> Usage: strings [options] (see --help)
>> volatility: error: String file format invalid.
>>
>>
>> Thanks for any assistance.
>>
>> Mike
>>
>>
>>
>>
>>
>> _______________________________________________
>> Vol-users mailing list
>> Vol-users(a)volatilityfoundation.org
>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>
>
>
>
> --
> PGP Fingerprint: 2E87 17A1 EC10 1E3E 11D3 64C2 196B 2AB5 27A4 AC92
--
PGP Fingerprint: 2E87 17A1 EC10 1E3E 11D3 64C2 196B 2AB5 27A4 AC92
