Combined scans

[GoogleCodeExporter]

I have a feature requests regarding the scanner plugins in Volatility that 
would greatly improve the speed of scanning live VM's through libvmi. 
Currently, we can scan for specific target data-structures individually. If we 
could combine scans into a "multiscan" plugin, where we can specify to run, for 
example psscan and sockscan simultaneously, Volatility would only have to loop 
through memory once and could combine the information of each subscan to skip 
ahead in memory (if psscan finds a hit, no need to check that area with 
sockscan as well). That would greatly reduce the memory bandwidth utilized by 
Volatility when performing searches for multiple structures and would also 
finish faster than running each scan on its own.

Original issue reported on code.google.com by tamas.k....@gmail.com on 25 Jul 2012 at 10:03

• Merged into: #310

[GoogleCodeExporter]

Definitely, this is actually on the roadmap for 2.2: 

http://code.google.com/p/volatility/wiki/VolatilityRoadmap#Volatility_2.2_(Offic
ial_Multi-OS_Support)

The "Pool scanner updates" (probably could have been more specific there) is 
intended to allow scanning for multiple objects with a single pass through the 
address space. You can check out a preview/prototype below (see ScannerGroup 
and DiscontigScannerGroup):

http://code.google.com/p/volatility/source/browse/branches/scudette/volatility/s
can.py

Original comment by michael.hale@gmail.com on 25 Jul 2012 at 11:17

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Awesome! Glad to hear there is already some code for that, I'll be happy to 
test it. As scudette branch is a rewrite, I noticed the command interface has 
changed from the existing significantly. Any way to define an address space 
here to load (-l A URN location from which to load an address space)?

Original comment by tamas.k....@gmail.com on 26 Jul 2012 at 6:28

[GoogleCodeExporter]

Hi tamas,
   I am trying to keep the command line args as close as possible to 2.x when it makes sense (There is still some work to do with that). You can load an image using -f filename (since the -l command line option was removed).  Sorry that documentation is a bit sketchy at the moment.

http://code.google.com/p/volatility/wiki/ScudettesBranch is a start but its a 
bit old.

Original comment by scude...@gmail.com on 26 Jul 2012 at 6:49

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I am not sure I understand. How is libvmi access provided? Is there a
special address space you are using?  I can not see anything specific
in

http://code.google.com/p/volatility/source/browse/#svn%2Ftrunk%2Fvolatility%2Fpl
ugins%2Faddrspaces

Original comment by scude...@gmail.com on 26 Jul 2012 at 6:15

[GoogleCodeExporter]

Yes, it's an addresspace provided by libvmi: 
https://code.google.com/p/vmitools/source/browse/tools/pyvmi/pyvmiaddressspace.p
y

It actually turns out to be possible to map a running VM's memory to a file 
through FUSE, so I should be able to use -f after all! It's a bit ugly that 
way, but if it works, it works.. =)

Original comment by tamas.k....@gmail.com on 26 Jul 2012 at 7:05

[GoogleCodeExporter]

Could you provide a brief description on how to use the ScannerGroup 
functionality? I see that I need to define a dictionary of BaseScanners and 
pass that to the ScannerGroup but my python skills are a bit rusty. Thanks!

Original comment by tamas.k....@gmail.com on 26 Jul 2012 at 8:25

[GoogleCodeExporter]

Hi Tamas, there's an example in the callbacks.py file: 

http://code.google.com/p/volatility/source/browse/branches/scudette/volatility/p
lugins/windows/malware/callbacks.py#535

Original comment by michael.hale@gmail.com on 27 Jul 2012 at 4:06

[GoogleCodeExporter]

Please also resync to the latest since it got broken when I refactored
the pool scanners to yield the pool header itself rather than the
offsets. (This is required since pools are handled differently on
windows 8).

Michael.

Original comment by scude...@gmail.com on 27 Jul 2012 at 4:23

[GoogleCodeExporter]

Awesome, thanks, I'll give it a spin!

Original comment by tamas.k....@gmail.com on 27 Jul 2012 at 5:23

[GoogleCodeExporter]

Original comment by michael.hale@gmail.com on 9 Aug 2012 at 4:58

• Added labels: Milestone-2.2.x

[GoogleCodeExporter]

Original comment by michael.hale@gmail.com on 26 Aug 2012 at 5:33

• Added labels: Milestone-2.3.x
• Removed labels: Milestone-2.2.x

[GoogleCodeExporter]

An additional request popped up in a conversation with my team that would also 
help us out a lot when using live pool scanning with Volatility. With Xen 4.2 
and LibVMI we can detect page changes in the memory of a live VM as it occurs, 
therefore if it were possible to restrict the scope of a pool scan to a 
specific memory region we could speed up our intrusion detection significantly 
by restricting the scope of the scan to that page +/- some buffer in case a 
datastructure is spanned across multiple pages. Is that something that's 
currently possible or could be added in the future?

Original comment by tamas.k....@gmail.com on 8 Oct 2012 at 3:15

[GoogleCodeExporter]

As you can see the prototype of the scan() method takes an offset and a maxlen:

https://code.google.com/p/volatility/source/browse/branches/scudette/volatility/
scan.py#307

This API is also the same with the current 2.x version of volatility as well.

So you would just call scan() with the offset of the page that changed and the 
length you want to scan. Is this what you mean?

Original comment by scude...@gmail.com on 8 Oct 2012 at 4:07

[GoogleCodeExporter]

Yes, thanks! =)

Original comment by tamas.k....@gmail.com on 8 Oct 2012 at 4:09

[GoogleCodeExporter]

Hey Tamas, sorry but this just isn't going to make it in time for 2.3. But the 
next release after that, 3.0, should be able to handle this for sure. 

Original comment by michael.hale@gmail.com on 1 Feb 2013 at 4:30

• Added labels: Milestone-3.0.x
• Removed labels: Milestone-2.3.x

[GoogleCodeExporter]

Just doing a little consolidation...I'm going to merge this with issue 310

Original comment by michael.hale@gmail.com on 9 Apr 2013 at 7:32

• Changed state: Duplicate