search

Leor3961 / volatility

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

PoolScanning signatures need some multi-profile support #17

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
"thrdscan" returns all the threads properly while "thrdscan2" returns no 
results.

I assume this would be a legitimate problem since both plugins claim to do the 
same thing.

Original issue reported on code.google.com by atc...@gmail.com on 26 Aug 2010 at 1:25

GoogleCodeExporter commented 8 years ago 
Ok, thrdscan2 uses some kind of pool checking and only once all that suceeds 
does it carry out the thread identification checks at the end.  The Pool checks 
involve a tag check (which seems to look for a four byte fixed value), then 
checks to see if it exceeds a certain size, then type, then index, and finally 
runs the thread checks.  My guess is that the tag isn't right for XPSP3 (which 
shouldn't be a problem, we can turn it into a VolatilityMagic constant once we 
know what it should be).

The best way of checking would be to remove the three checks starting on line 
133 in modscan2.py (CheckPoolSize, CheckPoolType and CheckPoolIndex) and see if 
it manages to find anything.  If not then it's likely the tag check's bad (you 
can't really try removing the tag check because it'll then try every byte in 
memory as an _ETHREAD).

If you could give that a go and let me know, we can start figuring out how best 
to fix it...  5:)

Original comment by mike.auty@gmail.com on 26 Aug 2010 at 11:38

GoogleCodeExporter commented 8 years ago 
okay so I changed the code to look like this:

 checks = [ ('PoolTagCheck', dict(tag = '\x54\x68\x72\xe5')),
               ('CheckThreads', {}),
               ]

and then ran thrdscan2 against the image:

root@newubuntu:~/vol# python volatility.py thrdscan2 -f winXP-32-SP3.vmem 
--profile=WinXPSP3
Volatile Systems Volatility Framework 1.4_rc1
PID    TID    Create Time               Exit Time                 Offset
------ ------ ------------------------- ------------------------- ----------
  1608   1380 24972104                  24972112                  0x017d0988
root@newubuntu:~/vol#

now it doesn't break, but I get only one result, whose PID corresponds to:

VMwareService.e        1608    668      3    144 2010-08-26 01:01:01

I am going to look around for a little bit and update with anything I find

Original comment by atc...@gmail.com on 26 Aug 2010 at 1:44

GoogleCodeExporter commented 8 years ago 
Okay so I think its more than just the tag. I looked in ida and the reactos 
source code and it the ->key member of _OBJECT_TYPE is used for the pool tag 
when they get created. Below the is the dump of the _OBJECT_TYPE for threads ( 
nt_PsThreadType symbol is the pdb symbol for this)

WINDBG>dt nt!_OBJECT_TYPE 0x81BCCCA0
   +0x000 Mutex            : _ERESOURCE
   +0x038 TypeList         : _LIST_ENTRY [ 0x81bcccd8 - 0x81bcccd8 ]
   +0x040 Name             : _UNICODE_STRING "Thread"
   +0x048 DefaultObject    : (null) 
   +0x04c Index            : 6
   +0x050 TotalNumberOfObjects : 0x143
   +0x054 TotalNumberOfHandles : 0x229
   +0x058 HighWaterNumberOfObjects : 0x150
   +0x05c HighWaterNumberOfHandles : 0x23e
   +0x060 TypeInfo         : _OBJECT_TYPE_INITIALIZER
   +0x0ac Key              : 0x65726854
   +0x0b0 ObjectLocks      : [4] _ERESOURCE

and as you can see the Key is 0x65726854 and thrdscan2 has a tag of:

'\x54\x68\x72\xe5'

so I went and changed the tag to be the key (in both little and big endian 
format across different runs) and I never had any threads return, the output 
was still nothiig.

so not only do the pool tags need to be moved to vtypes, but some deeper work 
needs to be done to figure out why the checks aren't happening. I don't really 
have time for it today or tomorrow but I can look after if necessary, but I 
think someone with more windows internals knowledge could do it faster

Original comment by atc...@gmail.com on 26 Aug 2010 at 5:01

GoogleCodeExporter commented 8 years ago 
just for the record, I check the thread _OBJECT_TYPE in windows 7 and the key 
is the same as xp sp3:

WINDBG>dt nt!_OBJECT_TYPE 84233698
   +0x000 TypeList         : _LIST_ENTRY [ 0x84233698 - 0x84233698 ]
   +0x008 Name             : _UNICODE_STRING "Thread"
   +0x010 DefaultObject    : (null) 
   +0x014 Index            : 0x8 ''
   +0x018 TotalNumberOfObjects : 0x215
   +0x01c TotalNumberOfHandles : 0x3b7
   +0x020 HighWaterNumberOfObjects : 0x217
   +0x024 HighWaterNumberOfHandles : 0x3bb
   +0x028 TypeInfo         : _OBJECT_TYPE_INITIALIZER
   +0x078 TypeLock         : _EX_PUSH_LOCK
   +0x07c Key              : 0x65726854
   +0x080 CallbackList     : _LIST_ENTRY [ 0x84233718 - 0x84233718 ]

Original comment by atc...@gmail.com on 26 Aug 2010 at 5:27

GoogleCodeExporter commented 8 years ago 
Hmmm, ok.  I think this probably needs someone with more windows internals 
knowledge than I have too.  I'll update the various bits and pieces, and call 
in the professionals...  5;)

I'm happy to help move any constants/algorithms into the profile, but I'd need 
to know what they should be first.

Original comment by mike.auty@gmail.com on 27 Aug 2010 at 9:04

GoogleCodeExporter commented 8 years ago 
Hi guys,
  The scanner checks for the pool tag - thats not the same as Key. The pool tag is used whenever you allocated a memory from the windows pool. So in this case it will be before the _OBJECT_TYPE and will be:

kd> dt nt!_POOL_HEADER
  +0x000 PreviousSize     : Pos 0, 9 Bits
  +0x000 PoolIndex        : Pos 9, 7 Bits
  +0x002 BlockSize        : Pos 0, 9 Bits
  +0x002 PoolType         : Pos 9, 7 Bits
  +0x000 Ulong1           : Uint4B
  +0x004 ProcessBilled    : Ptr32 _EPROCESS
  +0x004 PoolTag          : Uint4B
  +0x004 AllocatorBackTraceIndex : Uint2B
  +0x006 PoolTagHash      : Uint2B

The tag is PoolTag above
so you should do 
dt nt!_POOL_HEADER 84233698-8

Original comment by scude...@gmail.com on 27 Aug 2010 at 12:20

GoogleCodeExporter commented 8 years ago

Original comment by mike.auty@gmail.com on 29 Aug 2010 at 12:03

GoogleCodeExporter commented 8 years ago

Original comment by mike.auty@gmail.com on 23 Nov 2010 at 8:24

GoogleCodeExporter commented 8 years ago

Original comment by mike.auty@gmail.com on 21 Jan 2011 at 9:04

GoogleCodeExporter commented 8 years ago 
Sorry for the bugspam, but better to get this right now than later once it's 
more in use.

Original comment by mike.auty@gmail.com on 4 Feb 2011 at 9:34

GoogleCodeExporter commented 8 years ago 
Sorry, this was all fixed ages ago by the rather excellent labarum_x during 
commits r601 and r619.  Sorry for the delay in closing...

Original comment by mike.auty@gmail.com on 14 Feb 2011 at 10:10

GoogleCodeExporter commented 8 years ago

Original comment by mike.auty@gmail.com on 14 Feb 2011 at 10:10