The need for profile-specific scanners

[GoogleCodeExporter]

This is for Milestone-1.5.x....

There is a need for profile-specific scanners, or at least the ability to set 
constraints differently depending on the profile being used. 

One major reason that we're all familiar with is the fact that structure sizes 
are different across OS versions. Thus fine-tuning the CheckPoolSize parameter 
for one OS can have negative effects when used on a different OS. 

So theoretically we could do something like adjust the CheckPoolSize based on 
profile.get_obj_size. But, there are other concerns like CheckPoolIndex. For 
the same type of object, I've seen the PoolIndex is always 2 on XP and always 0 
on Win7. So currently in order to create a scanner that works on both, we'd 
need to 

1) say PoolIndex can be 0 or 2 
2) don't use the PoolIndex constraint at all

Both situations could increase the amount of false positives. Of course, we can 
always fall back on applying other constraints to the object's members, but if 
we *know* that one OS always uses 2 and one OS always uses 0 then it may be 
worthwhile to research ways to apply that to the scanner. 

Original issue reported on code.google.com by michael.hale@gmail.com on 28 Apr 2011 at 3:00

[GoogleCodeExporter]

Should be entirely doable, the trick will be allowing scanner checks to take 
multiple values based on volatility magic output.  For CheckPoolIndex, that's 
easy:

if callable(value):
    value = value(address_space)

Then when defining the check value, define it as:

lambda v: obj.Object('VOLATILITY_MAGIC', vm = v, offset = 0).ScannerCheckValue

Note that this will precalculate the check's value, rather than relooking it up 
each time (since the function's applied in __init__ for the check), meaning 
that if the profile changes during the scan, we'll miss it, but that 
*shouldn't* ever occur.

The problem arises for CheckPoolSize, since that's already callable, and we 
can't just add a parameter, because the existing lambdas would all need 
changing, and it's a bit messy.  The other option is to replace the checks in 
the scanner's init section, but that's also a bit messy.  I'm up for 
suggestions for cleanly solving this one?  Can lambdas return lambdas?

Original comment by mike.auty@gmail.com on 28 Apr 2011 at 7:21

[GoogleCodeExporter]

Any progress on this one?

Original comment by mike.auty@gmail.com on 23 Jan 2012 at 2:46

[GoogleCodeExporter]

This has been fixed in my branch for a while.

Original comment by scude...@gmail.com on 23 Jan 2012 at 2:53

[GoogleCodeExporter]

That's great, can you please provide patches for applying to trunk?

Original comment by mike.auty@gmail.com on 23 Jan 2012 at 4:38

[GoogleCodeExporter]

This solution implements profile specific commands (not just scanners). The 
command gets to decide if its active for a given profile using the is_active() 
method. There is also some work required to make the help system play nicely. 
This is used in the linux case for implementing a pslist command which operates 
on linux vs. the windows pslist command.

http://code.google.com/p/volatility/source/detail?r=1098
http://code.google.com/p/volatility/source/detail?r=1097

Original comment by scude...@gmail.com on 23 Jan 2012 at 8:24

[GoogleCodeExporter]

r1097 affects the profile mechanism, and just changes plugins, not scanners.  
r1098 is primarily for linux support.  Do you have any patches that solve this 
problem?  The ones you provided appear more relevant to issue 67...

Original comment by mike.auty@gmail.com on 12 Feb 2012 at 8:18

[GoogleCodeExporter]

MHL, where are we with this one?

Original comment by mike.auty@gmail.com on 21 May 2012 at 11:03

• Added labels: Milestone-2.1.x
• Removed labels: Milestone-1.5.x

[GoogleCodeExporter]

You may be able to take inspiration from this very simple refactoring:

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

Which breaks the constraints into an explicit method build_constraints(). Then 
you can add constraints _after_ instantiating the class but before actually 
scanning:

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

Original comment by scude...@gmail.com on 21 May 2012 at 11:09

[GoogleCodeExporter]

Hmmmm, so is there a reason we don't construct the constraints on demand during 
the scan() call, and then checks is the definitive source right up until scan 
is called?

Original comment by mike.auty@gmail.com on 22 May 2012 at 10:20

[GoogleCodeExporter]

Yeah that sounds like a good idea.

Original comment by scude...@gmail.com on 22 May 2012 at 10:37

[GoogleCodeExporter]

This issue was closed by revision r1789.

Original comment by mike.auty@gmail.com on 22 May 2012 at 1:41

• Changed state: Fixed