Scanner framework changes [+combined scans]

[GoogleCodeExporter]

So for our next API break we should consider making the following changes to 
the scanning framework:

* Pass the check function an upper bound so they know how much data at a 
maximum they can look at.
* Make the check functions return the hit or a length value as well as the 
offset.
* Refactor the check/skip function so that existing efficient block searching 
systems can be used instead of our own system (for example, yara's scanning 
engine).

Original issue reported on code.google.com by mike.auty@gmail.com on 22 Jul 2012 at 7:53

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi Tamas,
   This is a great idea which is already implemented here:

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

So it will hopefully make it to trunk eventually :-)

Michael.

Original comment by scude...@gmail.com on 25 Jul 2012 at 10:21

[GoogleCodeExporter]

Original comment by mike.auty@gmail.com on 29 Jul 2012 at 9:28

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

[GoogleCodeExporter]

Original comment by michael.hale@gmail.com on 1 Feb 2013 at 5:06

• Added labels: Milestone-3.0.x

[GoogleCodeExporter]

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

• Changed title: Scanner framework changes [+combined scans]

[GoogleCodeExporter]

Issue 314 has been merged into this issue.

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

[GoogleCodeExporter]

Mike, I'm going to ask that if you have desired scanner framework changes, 
either log the issue in the 2.4 tracker on Github or the 3.0 skeleton branch. 
Regarding issue #314 which was merged into this current issue, I've already 
implemented the combined scans into the upcoming 2.4 branch so that is all 
taken care of. 

Original comment by michael.hale@gmail.com on 7 Mar 2014 at 6:11

• Changed state: Fixed