Driver Extraction/Loading

[crazyd...@gmail.com]

We are currently looking at migrating to winpmem, primarily due to licensing issues. However, in experimenting, I run into two problems. The first is that winpmem 2 doesn't export as RAW any longer (no option/flag). So that drove us to winpmem 1.6.2. However, 1.6.2 extracts the driver to the defined temp path (%temp%) and attempts to load from there. Due to security protections in place, execution is blocked. While there is the option of extracting the driver, there is no way to tell winpmem what drive to load or where to extract the driver to. Is there either a way to convert winpmem 2 to RAW (a single, raw file), or force winpmem to load the driver from another location - like system32?

Thanks,
David

[Michael Cohen]

Hi David,
are you saying that the -d option to winpmem 1.6.2 does not work? I
just tried it and it seems to do what you want:

C:\Users\mic\rekall>..\Downloads\winpmem_1.6.2.exe -d c:\users\mic\foo.sys -l
Extracting driver to c:\users\mic\foo.sys
Driver Unloaded.
Loaded Driver c:\users\mic\foo.sys.
CR3: 0x00001AA000
4 memory ranges:
Start 0x00001000 - Length 0x0009E000
Start 0x00100000 - Length 0x00002000
Start 0x00103000 - Length 0x7FDDD000
Start 0x7FF00000 - Length 0x00100000
Acquitision mode PTE Remapping

Can I just ask why you prefer raw images? They are inferior because we
can not capture any metadata, or additional files like pagefile or
drivers, mapped files etc. This make later analysis more complicated
because you need to guess all that stuff which you could have gotten
at acquisition time.

We want to make the AFF4 format standard for memory acquisition, but I
am curious if there are any objections. Is the problem just
compatibility with other software like Volatility? Is it a problem to
export to raw later?

Also we have brought the issue of winpmem to discussion before. The
choice moving forward was to use rekall itself as an acquisition tool,
see this blog post:

http://rekall-forensic.blogspot.ch/2015/09/installing-rekall-on-windows.html

which shows how to make a standalone windows thumbdrive for IR. Then
you can just image using Rekall - the preferred way:

rekall aff4acquire myimage.aff4

Or to raw file:

rekall --live imagecopy myimage.raw

Or to ewf format

rekall --live ewfacquire myimage.e01

you can always use rekall to extract the physical memory from AFF4 volume later:

rekall -f myaff4image.aff4 imagecopy myrawimage.raw

Thanks
Michael.

> --
> You received this message because you are subscribed to the Google Groups "rekall-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to rekall-discus...@googlegroups.com.
> To post to this group, send email to rekall-...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[David Gainey]

Michael,

Several questions there, so I will do my best to answer them all.

Thanks for the commandline; that does work.  I was trying "winpmem_1.6.2.exe -l driver.sys", which wasn't working (-d only defined extracting the driver).

Regarding raw RAM dump files, we have several tools that only utilize raw files.  I haven't seen anything in my searching for a relatively simply way to generate a raw memory dump from winpmem 2 AFFs.  Exporting to raw files after the fact would be fine - we already have an automated triage process that we could simply include extraction of the memory dump within.  However, the big downside I see is dependency installation (libraries).  While it is often stated that the up-front cost is the only big issue, bug fixes perpetuate the dependency installation issues.  However, I am open to the idea.  I would be interested in exploring the possibility of AFF if we can extract as a RAW file for tools other than rekall.

Regarding rekall acquisition, we currently maintain our own tool that collects the various data we need for our analysis.  It is a 'double-click and relax' tool that we have customized for our needs over the years; it was designed so anyone can do the dump - even if they don't know how to open a command prompt.  It collects various files that may or may not be in memory.  With the latest version, we have been trying to get away from licensing issues.  Additionally, we have been compressing the data ourselves.  So while it would be more efficient to do so in memory, we would have to have a way to extract the memory dump to run through the various tools.

Thanks,

David

[Michael Cohen]

Hi David,
Thanks for your feedback. The heart of the winpmem tool is actually
the driver and the userspace code is not really important - in fact
you can just obtain a simple raw memory image with a very small python
script - https://github.com/google/rekall/blob/master/tools/windows/winpmem/winpmem.py
is a POC and it can easily be re-written in any other language. All
our tools use the same driver which is released under the Apache
license.

The main use of the acquisition userspace tool is to produce an
imaging format which best preserved the evidence and fits well into
the processing pipelines. The nice thing about AFF4 is that it is very
fast (uses snappy compression) and you can also store multiple streams
in the same file so we can capture files, pagefile etc. Our goal is
similar in that we want to automate the acquisition process as much as
possible so that the operator does not forget to acquire something -
so I would be interested to know what other files you collect in
addition to the memory.

The reason we want to do the acquisition from rekall itself is that we
can run triage analysis _during_ the acquisition on the live device,
and therefore already know all the files that currently have handles
opened, all the mapped files etc. This way we know that we acquire all
the relevant files at the time of acquisition. In the winpmem2.0
series we also acquired extra files but we kind of had to guess
because winpmem2.0 is written in c++ and does not have any triaging or
analytical capabilities. So this is the tradeoff - do we guess during
acquisition the files that we might need, but have a smaller self
contained tool, or do we just bring Rekall along and know that we grab
everything and wont miss anything. There is nothing worse than doing
an analysis later only to find that you have to dump the malware from
memory and it has a lot of unmapped padded holes in the binary. At
this point its way too late - you should have got the binary from disk
in the first place.

Otherwise an AFF4 file behaves similar to a zip file (it is actually a
zip file) in that it just stores different streams within it. You can
extract any of the streams to raw using the aff4ls and aff4export
rekall plugins (think of these plugins like unzip tool).

Thanks
Michael.

[David Gainey]

Michael,

So I'm running into an issue with your suggestion that I was hoping you could provide some input to.  I'm running some python code that is simply doing subprocess calls to launch winpmem.  I've simplified it a little (removed variables, paths, etc.), but here is what I'm doing:

subprocess.call('C:\\path\\winpmem_1.6.2.exe', '-d', 'C:\\windows\\winpmem.sys', '-l')

print os.path.isfile('C:\\windows\\winpmemn.sys')

subprocess.call('C:\\path\\winpmem_1.6.2.exe', 'dump')

My file check is returning true, so I know the driver is extracted.  However, winpmem is only loading the driver from the extracted location about 50% of the time.  The rest of the time it is running from temp.  I also tried extracting the driver prior to loading; however, I have the same results.  Am I doing something wrong?

David

[Michael Cohen]

In your second call to winpmem you are not telling it to use the same
driver it was extracting in the first call? so it will extract to
temp. Does this work?

subprocess.call('C:\\path\\winpmem_1.6.2.exe', '-d',

'C:\\windows\\winpmem.sys', 'dump')

[David Gainey]

That did it.  Thanks!