3:31 a.m.
Tamas, Nir, Michael,
Thank you all for the replies. I suspected something similar about Vmware
not synching the vmem file too often.
Michael,
WinpMem seems to be a very good method (from the video), I deliberately
didn't look into the source code yet, because I think I need to develop
something similar, and would like to do so from scratch. We cannot use any
existing code. I tried to avoid writing a driver since it complicated
maintenance and release cycles, typically extending them, but if there is
no easy way, perhaps that is the way to go.
For my previous driver experience (and please correct me if I am wrong),
this driver needs to interpret Windows memory management and open sections
of memory and furnish the contents and contexts through IOCTLs to the user
mode service for further analysis.
A few quick questions :
1. This can be done completely agentless? Which means we need to insert
nothing inside the VMs? Everything stays in the hyper-visor.
2. Have you guys tried constructing the call stack for such a break point?
So when one hits a memory location and that is a function call, I would
like to interpret the frames to get a call stack for the function call?
(perhaps this is already mentioned in the video, and I didnt pay enough
attention)
Thanks
amit
On Sat, Jun 1, 2013 at 3:33 AM, Michael Cohen <scudette(a)gmail.com> wrote:
Hi ab,
You can use volatility tech preview with live systems by simply loading
the winpmem driver (using the -l option) and then pointing volatility at
the live memory (i.e. the \\.\pmem device). You can also turn on write
support in the driver, and get volatility to write at the memory location.
It should be quite simple to insert instrumentation stubs into code in that
case.
See the recent dfir workshop where we did just this:
http://www.youtube.com/watch?v=9aC7yIYwvAY
Michael.
On 31 May 2013 17:22, A B <amitrajitb(a)gmail.com> wrote:
--
- ab
All,
This is my first post in this forum, and I am also very new to this
website, so please excuse my ignorance.
This is a fantastic project no doubt.
Now, coming to my questions:
1. Is it possible to run volatility on a running 'live' VM's memory? That
is, assuming that I have vmware work station running, can I use the live
vmem file as input and get reliavble outputs?
2. If one is possible, then is it possible to generate a breakpoint or
get a call back when a particular memory location is hit? I ask this
because, assuming that an executable is loaded in certain pages inside the
vmem, and I want to get notified when a particular function of that loaded
executable is called, this wuld mean that when the virtual CPU executes the
first instruction of that function I need a callback, is that possible?
thanks in advance...
--
- ab
_______________________________________________
Vol-dev mailing list
Vol-dev(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-dev
9:41 a.m.
New subject: Breakpoints On Instruction calls
Hi Amit,
The Winpmem driver just exports the physical memory to a windows device
file so the userspace application can read (and write) this memory
directly. This is done using a variety of methods (different APIs) but they
all essentially achieve the same thing.
We then use Volatility to map from virtual to physical address spaces, find
the function preambles etc to figure out the physical address to write,
then write using the driver.
We have done some research on instrumentation, where we overwrite function
pointers, or preambles and redirect them to an instrumented version. This
is pretty basic and reliable technique which used by many rootkits as well.
For our technique you do need to load the driver and code into the guest
kernel because we are mostly focusing on real machines in our research (not
VMs). I believe that some of the virtualization technologies out there
allow you to read and write arbitrary memory locations (check out libvmi).
If you wanted to do instrumentation this way you could do it the same way -
hook up volatility to the guest vm via libvmi and then alter running memory
to insert the hooks.
We did not look at the call stack, but check out carl pulley's plugin for
an interesting way to do this (issue 149).
Michael.
On 4 June 2013 09:31, A B <amitrajitb(a)gmail.com> wrote:
Tamas, Nir, Michael,
Thank you all for the replies. I suspected something similar about Vmware
not synching the vmem file too often.
Michael,
WinpMem seems to be a very good method (from the video), I deliberately
didn't look into the source code yet, because I think I need to develop
something similar, and would like to do so from scratch. We cannot use any
existing code. I tried to avoid writing a driver since it complicated
maintenance and release cycles, typically extending them, but if there is
no easy way, perhaps that is the way to go.
For my previous driver experience (and please correct me if I am wrong),
this driver needs to interpret Windows memory management and open sections
of memory and furnish the contents and contexts through IOCTLs to the user
mode service for further analysis.
A few quick questions :
1. This can be done completely agentless? Which means we need to insert
nothing inside the VMs? Everything stays in the hyper-visor.
2. Have you guys tried constructing the call stack for such a break point?
So when one hits a memory location and that is a function call, I would
like to interpret the frames to get a call stack for the function call?
(perhaps this is already mentioned in the video, and I didnt pay enough
attention)
Thanks
amit
On Sat, Jun 1, 2013 at 3:33 AM, Michael Cohen <scudette(a)gmail.com> wrote:
Hi ab,
You can use volatility tech preview with live systems by simply loading
the winpmem driver (using the -l option) and then pointing volatility at
the live memory (i.e. the \\.\pmem device). You can also turn on write
support in the driver, and get volatility to write at the memory location.
It should be quite simple to insert instrumentation stubs into code in that
case.
See the recent dfir workshop where we did just this:
http://www.youtube.com/watch?v=9aC7yIYwvAY
Michael.
On 31 May 2013 17:22, A B <amitrajitb(a)gmail.com> wrote:
--
- ab
_______________________________________________
Vol-dev mailing list
Vol-dev(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-dev
All,
This is my first post in this forum, and I am also very new to this
website, so please excuse my ignorance.
This is a fantastic project no doubt.
Now, coming to my questions:
1. Is it possible to run volatility on a running 'live' VM's memory?
That is, assuming that I have vmware work station running, can I use the
live vmem file as input and get reliavble outputs?
2. If one is possible, then is it possible to generate a breakpoint or
get a call back when a particular memory location is hit? I ask this
because, assuming that an executable is loaded in certain pages inside the
vmem, and I want to get notified when a particular function of that loaded
executable is called, this wuld mean that when the virtual CPU executes the
first instruction of that function I need a callback, is that possible?
thanks in advance...
--
- ab
_______________________________________________
Vol-dev mailing list
Vol-dev(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-dev
4180
days inactive
4181
days old
vol-dev@lists.volatilityfoundation.org
1 comments
2 participants
participants (2)
-
A B -
Michael Cohen