Hello Folks,
Although already written in the vol-users list this thread belongs to the
vol-dev one:
in 1.4rc1 there was a nice feature to visualize the output of psscan in the
GraphViz-dot-format with -output=dot.
I have used it frequently to explain memory structures to non IT-Experts or
for training purposes.
Is it possible to add this feature to Version 2.0 again, please?
Many thanks in advance!
Michael
neofito,
I thought that you might like to know that we have just committed
profiles for Vista SP1 and SP2. Would you like to test them out on
your Vista images? Let us know if you have any problems.
All the best,
-gleeda
> Date: Wed, 26 Jan 2011 19:25:49 +0100
> From: neofito <vjaviergarcia(a)ono.com>
> Subject: Re: [Vol-dev] A doubt about vista_sp0_x86_vtypes.py
> To: vol-dev(a)volatilityfoundation.org
> Message-ID: <4D40672D.9010200(a)ono.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> The current Vista profile is working well, it was just a doubt
>
> Thanks
>
>
> El 20/01/2011 7:37, AAron Walters escribió:
>>
>>
>> neofito,
>>
>> I would guess that is the file that Bradley was interested in when he
>> generated the profile. If you would prefer to use types from
>> ntkrpamp.pdb, please feel free. With all the changes in the upcoming
>> 1.4, adding new types and profiles has become a lot easier. Hopefully
>> you will also decide to submit them back and assist with Vista testing.
>>
>> Have you run into problems with the current profile? Is it not working?
>> Thanks,
>>
>> AW
>>
Hello,
From "Windows Internals, Fifth Edition":
On 32-bit x86 systems, the flag in the page table entry to mark a page
as nonexecutable is available only when processor is running in Physical
Address Extension (PAE) mode. Thus, support for hardware DEP on 32-bit
systems requires loading the PAE kernel
Why the file used is ntkrnlmp.pdb instead of ntkrpamp.pdb?
Thanks,
---
La verdad nos hara libres
http://neosysforensics.blogspot.comhttp://www.wadalbertia.org
-<|:-P[G]
First, I'm not a spammer, I promise :)
Following the instructions provided by Bradley Schatz [1] I added a new
profile for
Windows Vista SP2.
since the code is actively revised it's obvious that not all commands
work how is
expected, but I'm very surprised that the command kpcrscan always get
the same value:
C:\Volatility-1.4_rc1>volatility.py --profile=VistaSP2x86 -f
vistasp2.dmp kpcrscan
Volatile Systems Volatility Framework 1.4_rc1
Potential KPCR structure virtual addresses:
Phys addr 00150000 Virt addr ffdff000
_KPCR: ffdff000
obviously this is not correct
0: kd> !pcr
KPCR for Processor 0 at 81d45800:
Major 1 Minor 1
NtTib.ExceptionList: ffffffff
NtTib.StackBase: 00000000
NtTib.StackLimit: 00000000
NtTib.SubSystemTib: 80151000
NtTib.Version: 001d39f9
NtTib.UserPointer: 00000001
NtTib.SelfTib: 00000000
SelfPcr: 81d45800
Prcb: 81d45920
Irql: 00000002
IRR: 00000000
IDR: ffffffff
InterruptMode: 00000000
IDT: 81bff400
GDT: 81bff000
TSS: 80151000
CurrentThread: 81d49640
NextThread: 00000000
IdleThread: 81d49640
DpcQueue:
The volatility code version is the latest available via subversion (r493).
[1]
http://blog.schatzforensic.com.au/2010/05/adding-new-structure-definitions-…
---
La verdad nos hara libres
http://neosysforensics.blogspot.comhttp://www.wadalbertia.org
-<|:-P[G]
Hello,
With quite a bit of help & patience from ikelos, I have created a
skeleton for generic Linux support for Vol. In order to show the
complete process of how it currently works, I am going to demonstrate
the process from start to finish (a simple process listing of a memory
image). The main reason I am sending this email is because I hope
that the volatility developers can review what I have so far, comment,
and ultimately we can finalize a skeleton that can then be rapidly
added on to develop tens of useful plugins for Linux memory analysis.
I already have code for quite a bit of kernel analysis, so my whole
goal of this is to fit it inside the framework and ultimately get it
accepted into Volatility stable.
So the process of my system currently works like this (will be
illustrated with code and examples after):
1) Gather all of the structure offsets from a kernel through an LKM
2) Feed the LKM's output to a python script that generates a vtype /
profile automatically based on structure definitions kept in another
file
3) Make a profile python file for these types
4) Now we have a profile for the specific type and plugins can use it as normal
after this point we can run plugins, so now to illustrate all of this:
1) Gathering of offsets is facilitated in this LKM. (I added a simple
license & author header to each file due to ikelos's advice to do so)
http://gist.github.com/595600
This module works by gathering the offset of members from every
structure necessary to do analysis. It also adds the size of each
structure into the output file in order to have correct profile
information. Note that this code is kernel version aware and will be
able to get offsets from any 2.6.x version. Also, it only gathers a
small number of structures & members now b/c that is all that is
needed in order to list processes. Once the code is reviewed by devs,
other structures can be quickly added.
2) Feed this 1) to a python script
So at this step we need to generate the profile and we also need to
set the DTB. Even though it may seem odd, its not possible in a 2.6.x
generic way to get the cr3/dtb of the init process in order to
automatically acquite the dtb, even inside the kernel module. This is
because the DTB we want (swapper_pg_dir) is not exported and the mm
structure that references it (init_mm) stopped being exported in
2.6.26. Also, you can't get a reference to init_mm through init_task,
because after initialize init_task->mm is set to NULL. Because of all
this, we have to accept the DTB value on the commandline to this
script, but this is easily obtained by grepping for 'swapper_pg_dir'
in the corresponding System.map file for the kernel.
Here is the python script to generate the output, note that the
linux_kernel_types file will take work as well to support all
structures & members needed for full analysis, but that it will be
stable for all of 2.6.x once set:
http://gist.github.com/595589http://gist.github.com/595598
Here is using it on the test kernel:
http://gist.github.com/595594
as you can see it has all the kernel structures and uses
volatility_magic to store the DTB. This means the users never have to
deal with DTB and it will still with the profile forever and will auto
load on vol initialization
now that we have this:
3) make a simple python profile
With the help of ikelos, I have made the profile system very easy to
add support for new kernel versions. To support this there is an
abstract Linux Profile that does everything but set the
abstract_types:
http://gist.github.com/595604
and the simple profile needed to support the debian test image:
http://gist.github.com/595606
4) time to write a plugin!
this is the simple plugin I came up with to list processes & it uses
profile just generated:
http://gist.github.com/595607
note that the system map parsing stuff will go into a utility file
once devs approve of the current way of doing things or we change
stuff around. its very quick to parse so its not an issue to parse it
on every load or eventually have the system map hash table pickled in
the cache
With that, we have distro / version generic Linux support. We also
have an easy method to generate profiles for any Linux System.
Please send any comments / suggestions, as once its approved I would
like to quickly add support for a large number of more plugins &
kernels
I didn't want to put this in the last email as it wasn't exactly related.
I currently see two (non-technical) issue with full blown Linux support.
1) Since there are now 36 stable 2.6.x kernel versions and ten or so
distros, even partial coverage will require a huge amount of profiles.
While its easy to install a bunch of distros & kernels in a VM and get
profiles for them, the big problem will be how to allow users to
choose what profile is right without overwhelming them with options.
It is no where near as simple as Windows with relatively few versions
compared to Linux.
2) Going off 1), there is also the problem of how to name all the
profiles and the eventual --profile option. Since distros have
multiple kernels packaged for the same kernel version its not as
simple as what I have now (LinuxDebian2626) because debian has
multiple 2626 packages, that will all have different offsets, dtb, and
such. So we need to come up with a sane method of allowing all the
profiles to be choosen.
What I was thinking for this is a complete reorder of the --help
system, which honestly is confusing now. Since vol will now have
windows & linux support, and (soon ;)) will have support for some
specific applications memory analysis, I think the help menu should be
something like this (close to what svn does)
python volatility -h Windows
python volality -h Linux
python volatility -h some_app
and then it will show you only the plugins for whichever os/app you
are interested in. This can be made simple inside the current
framework, by tagging each plugin with what they support inside of the
string message. so for instance you can have:
class some_linux_plugin(...):
''' Linux - A module for linux process listing '''
class some_windows_plugin(...):
''' Windows - A module for windows process listing '''
and this way only the stuff after - gets displayed and the parser
knows what plugins work on which apps.
for plugins that work regardless of OS there could be a "-h any"
option or similar...
3) To help with profile explosion, there also should be some way to
list profiles for a specific app/os and for linux, which distro:
as of right now, the only way I know of to get a list of profiles is
with --info, which also lists a bunch of other stuff. If there was a
way to do something like:
python volalitility.py --list-profiles Windows
which wouuld return all windows profiles
or
--list-profiles Windows XP
which would return profiles for windows xp
similarly for linux you could have:
--list-profiles Linux
--list-profiles Linux Debian
which would greatly help if we are going to properly support Linux &
all the different distros and versions
Even without Linux support, this issue will crop up as volality moves
to support XP (with 3 service packs), vista (with 2 currently), 7,
2008, 2003, etc as relying on --info will just result in huge blocks
of text
Hi Jason,
I think you sent this only to me by mistake :-) I'm forwarding this
to the list so others can respond to you.
As for other OS's it there's been some discussion related to this
recently on the users list you can check out too:
http://lists.volatilityfoundation.org/pipermail/vol-users/2010-January/thre…
But yes, you should be able to extend Volatility to include other OS's.
All the best,
-Jamie
---------- Forwarded message ----------
From: Jason Reynolds <JReynolds(a)pathwayforensics.com>
Date: Wed, Jan 6, 2010 at 5:13 PM
Subject: RE: [Vol-dev] Re: Vol-dev Digest, Vol 14, Issue 1
To: Jamie Levy <jamie.levy(a)gmail.com>
Hi All,
A similar question to John's, but also a little different --
Is there a place where the format of ram allocation and DTB's are
documented, or is the best
documentation simply disassembling the associated operating system?
I am curious to know if additional OS's could be easily added to
volatility. If there is sufficient
documentation on the OS it should be relatively simple to write a parser.
Thanks in advance.
Hi John,
You can check out the entire branch like so:
svn checkout http://volatility.googlecode.com/svn/branches/Volatility-1.4_beta1/
volatility
All the best,
-Jamie
> Date: Wed, 6 Jan 2010 09:02:15 -0500
> From: "McCash John-GKJN37" <john.mccash(a)motorola.com>
> Subject: RE: [Vol-dev] Possible Volatility Bug
> To: "Mike Auty" <mike.auty(a)gmail.com>
> Cc: vol-dev(a)volatilityfoundation.org
> Message-ID:
> <D8DFDF3C534B344B9A266EB03CC828BB049270A3(a)de01exm71.ds.mot.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Mike,
> I'm running the version pulled from SVN this morning, 1.3.1
> (08.09.2009). How would I list the candidate DTB addresses? The way I
> found out about this problem originally was to just email Peter the
> error from memorize. He instantly recognized the problem. Also, how
> would I get the 1.4 branch to try out? Apologies for the dumb questions.
> I'm reasonably bright, but I only use this thing about once every four
> months.
> Thanks lots
> John
Mike,
I'm running the version pulled from SVN this morning, 1.3.1
(08.09.2009). How would I list the candidate DTB addresses? The way I
found out about this problem originally was to just email Peter the
error from memorize. He instantly recognized the problem. Also, how
would I get the 1.4 branch to try out? Apologies for the dumb questions.
I'm reasonably bright, but I only use this thing about once every four
months.
Thanks lots
John
-----Original Message-----
From: Mike Auty [mailto:mike.auty@gmail.com]
Sent: Wednesday, January 06, 2010 7:48 AM
To: McCash John-GKJN37
Subject: Re: [Vol-dev] Possible Volatility Bug
Hiya John,
First off could you please specify which version of volatility you're
using (whether you're using a tarball, or the sources from subversion)?
Also, whilst I can't comment too well on the 1.3 branch, I don't think
Windows 2003 is supported, I believe it's mostly aimed at XP SP2.
Having said that, it is possible to manually specify a DTB in the 1.4
branch using --dtb and in the 1.3 branch using -b (although for 1.3 this
is probably plugin dependent).
I'll leave it to someone who's been working with Volatility longer to
give you a more in-depth answer once you let us know which version you
were using, but hopefully this'll let you work around the problem for a
bit... 5:)
Mike 5:)
Hey Folks,
I was just reading Gleeda's blog & CEIC presentation,
and was interested to discover that Volatility modules had been written
for Linux and Vista. Now I'm wondering why these modules haven't shown
up anywhere I can see them, including in the public view of the SVN
repository. After digging for a bit, I did see that they (or at least a
modified version of the Linux ones) have apparently been incorporated
into the Pyflag distribution, but that just caused me more confusion. If
they're stable enough to release as part of Pyflag, why aren't they in
the public Volatility repository?
Also, are you expecting to release an 'official' update
anytime soon? The last update available from the main Volatility page is
still 1.3_Beta. Is there some defined list of fixes or features that has
to be ready before an 'official' 1.3 version is released? Or has that
been bypassed, so that current work is really going toward 1.4? Maybe a
roadmap section would make a good addition to the main Volatility page.
I'm sure there are a lot of people who would be interested in what's
going on.
Thanks much (Sorry if I sound like I'm
ranting, you guys really have done some awesome work!)
John
----------------------------------------------------------
Quis custodiet ipsos custodes?... I do!
