Leor3961 / volatility

Automatically exported from code.google.com/p/volatility
0 stars 0 forks source link

CheckPoolSize condition for PoolScanDriver #51

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Hey guys, 

I have two different XPSP2 memory samples. Driverscan works on one sample, but 
shows no results for the other. It appears the pool size of _DRIVER_OBJECTS is 
not the same, so we may need to modify the CheckPoolSize condition in 
PoolScanDriver. 

For example, currently we have:

('CheckPoolSize', dict(condition = lambda x: x == 0xf8))

That condition works for only 1 sample. If I change it to either of the 
following conditions, then driverscan prints results for both of my memory 
samples:

('CheckPoolSize', dict(condition = lambda x: x >= 0xf8))
('CheckPoolSize', dict(condition = lambda x: x == 0xf8 or x == 0x108))

If anyone wants the memory sample with 0x108 sized _DRIVER_OBJECT pools for 
testing, let me know. 

Original issue reported on code.google.com by michael.hale@gmail.com on 11 Dec 2010 at 7:03

GoogleCodeExporter commented 8 years ago
Hmmmm, I'm happy to make the change, but I'd prefer to know why the 
CheckPoolSize was set to a specific value before, and what's changed in a 
(probably) more recent version of XPSP2.

CheckPoolSize looks up the _POOL_HEADER object's BlockSize.  If this is a 
variable block size, it seems odd that it was ever constrained to a single 
value in the first place?  I'd like someone who knows a bit more about it to 
comment here, before I apply anything.  I'm going to CC in labarum_X, scudette 
and mooyix as my crack team of knowledgeable forensics types, but the plugin 
itself looks like it originally written by Andreas Schuster, so it might be 
worth asking him about it too...

Original comment by mike.auty@gmail.com on 11 Dec 2010 at 7:30

GoogleCodeExporter commented 8 years ago
As discussed on IRC, this has been changed to >= 0xf8 (along with other 
CheckPoolSize constraints that have been made >=, rather than ==).  Fixed in 
r594!  5:)  As ever, do feel free to reopen this if there's any issues found 
with the solution...

Original comment by mike.auty@gmail.com on 14 Jan 2011 at 9:59