Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
Re: [Dailydave] Memory, Elephantine
From: jnf (jnfnosec.net)
Date: Sat Mar 04 2006 - 12:51:00 CST
I'm curious how this works exactly as I have written a similar but
probably not as pretty tool, I haven't extended it to read a memory dump
for anything but a windows box. That said, I focused only on the process
list (and yes i know it will miss dkom).
I noticed that it was problematic getting most things beyond rudimentary
informationm, which the PEB being what it is caused some problems as a
result (i dont track things down in swap).
I also found that as of 2003, a dd of the physical memory object caused
the pointers in the linked list to get zero'd out, so even though I was
able to find the correct address of the linked list, I wasn't able to walk
How has your tool dealt with these and similar issues?
There are only two choices in life. You either conform the truth to your desire,
or you conform your desire to the truth. Which choice are you making?
On Fri, 3 Mar 2006, Nick Petroni wrote:
> Date: Fri, 3 Mar 2006 17:32:34 -0500 (EST)
> From: Nick Petroni <npetronics.umd.edu>
> To: dailydavelists.immunitysec.com
> Cc: awalters4tphi.net
> Subject: Re: [Dailydave] Memory, Elephantine
> While on the topic of memory forensics, the Python enthusiasts in
> the crowd may be interested in a new extensible research framework for
> analyzing volatile memory images that we will be releasing at an upcoming
> (yet to be determined) venue.
> For more information, check out: http://www.4tphi.net/fatkit/
> On Fri, 3 Mar 2006, Dave Aitel wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > I think it's interesting that Maniant (aka RedCliff) released a memory
> > forensics tool recently (http://www.mandiant.com/features.htm) - this
> > is also something we see people doing a lot more with CANVAS these
> > days. The main benefits of using an exploitation framework for such
> > things is that:
> > 1. We can use the same exploitation path an attacker would use to
> > obtain access to the machine. This means we're completely in memory
> > and haven't messed up the disk at all. (Or we can remotely install as
> > a service, copy a file over, whatever.)
> > 2. You get the power of MOSDEF for doing the hard work...i.e. you can
> > inject into processes, grab all the memory on the system from every
> > process, etc.
> > Of course, the downside is that you have to use MOSDEF to do the hard
> > work. :>
> > The other side of the story is that as an exploitation framework, you
> > now need to clean/encrypt memory up as you go along. And you can do
> > "remote forensics" as you go - I can look at other processes and see
> > if someone else is also using CANVAS or anything similar on this box...
> > - -dave
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.1 (GNU/Linux)
> > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> > iD8DBQFECH9pB8JNm+PA+iURAvJpAJ48qV13TcPpRiFXXu1yWCsffoQxpQCcDOBf
> > 37ykn9FpdVIJbVClewwiKLo=
> > =lYqp
> > -----END PGP SIGNATURE-----