thrdscan fails on some Win2008R2SP1x64 and WIn7SP1x64

[GoogleCodeExporter]

on a few (but not all) Win2008R2SP1x64 and Win7SP1x64 images, the thrdscan 
plugin returns 0 results. there is no backtrace or anything, just no results. 

the # of threads column in pslist reports that all processes do have > 0 
threads. also in volshell if you walk the ThreadListHead, you get results. so 
most likely there's a bad constraint in the CheckThreads() ScannerCheck. 

contact wyatt for debugging etc, he's the only one with access to the 
troublesome images. 

Original issue reported on code.google.com by michael.hale@gmail.com on 8 Jun 2013 at 4:02

• Merged into: #174

[GoogleCodeExporter]

This happens on my laptop, running Win7SP1x64. 8GB of ram, acquired with knt. 

Can test whatever is needed.

Original comment by atc...@gmail.com on 17 Jun 2013 at 2:57

[GoogleCodeExporter]

Andrew, can you moddump the nt module or get it from disk? from the win7 sp1 
x64 in our current profile the _KTHREAD ends like this:

    'ThreadCounters' : [ 0x350, ['pointer64', ['_KTHREAD_COUNTERS']]],
    'XStateSave' : [ 0x358, ['pointer64', ['_XSTATE_SAVE']]],

from wyatt's Win2008R2SP1x64 dump, the _KTHREAD ends like this:

    'ThreadCounters' : [ 0x350, ['pointer64', ['_KTHREAD_COUNTERS']]],
   'StateSaveArea' : [ 0x358, ['pointer64', ['_XSAVE_FORMAT']]],
   'XStateSave' : [ 0x360, ['pointer64', ['_XSTATE_SAVE']]],

So they added a field to _KTHREAD, which increases the size of _ETHREAD. When 
we carve objects from pools using the bottom-up method, everything is shifted. 

Original comment by michael.hale@gmail.com on 17 Jun 2013 at 8:36

[GoogleCodeExporter]

I can confirm the same thing in a private 9GB Win2008R2SP1x64 sample as well.  
I pulled the ntkrnlmp and it has the same structs as you mentioned above.  

Original comment by jamie.l...@gmail.com on 18 Jun 2013 at 2:18

[GoogleCodeExporter]

Looking at the _ETHREAD structure, there actually appear to be another member 
that isn't present in our other profile:

'KernelStackReference' : [ 0x4a0, ['unsigned long']],

I'm also looking at _EPROCESS structures and see that there's a few additional 
fields there as well:

'ExplicitAffinity' : [ 0x43c, ['BitField', dict(start_bit = 21, end_bit = 22, 
native_type='unsigned long')]],
    'Spare1' : [ 0x43c, ['BitField', dict(start_bit = 22, end_bit = 23, native_type='unsigned long')]],
    'ForceRelocateImages' : [ 0x43c, ['BitField', dict(start_bit = 23, end_bit = 24, native_type='unsigned long')]],
    'DisallowStrippedImages' : [ 0x43c, ['BitField', dict(start_bit = 24, end_bit = 25, native_type='unsigned long')]],
    'Flags' : [ 0x440, ['unsigned long']],

Do you have your own copy of vtypes or should I send these along?

Original comment by jamie.l...@gmail.com on 18 Jun 2013 at 2:30

[GoogleCodeExporter]

Same:
  'ThreadCounters' : [ 0x350, ['pointer64', ['_KTHREAD_COUNTERS']]],
  'StateSaveArea' : [ 0x358, ['pointer64', ['_XSAVE_FORMAT']]],
  'XStateSave' : [ 0x360, ['pointer64', ['_XSTATE_SAVE']]],

my ntoskrnl.exe was modified on march 19th of this year. 

I have attached a diff of the vtypes for sp1 x64 in volaltity with a diff of my 
system. I removed structures that were only different b/c the "unnamed" number 
was different. You can see the kthread changes as well as ethread, which looks 
like three members were added:

<     'Spare1' : [ 0x43c, ['BitField', dict(start_bit = 22, end_bit = 23, 
native_type='unsigned long')]],
<     'ForceRelocateImages' : [ 0x43c, ['BitField', dict(start_bit = 23, 
end_bit = 24, native_type='unsigned long')]],
<     'DisallowStrippedImages' : [ 0x43c, ['BitField', dict(start_bit = 24, 
end_bit = 25, native_type='unsigned long')]],

Original comment by atc...@gmail.com on 18 Jun 2013 at 2:40

Attachments:

• vtype.diff

[GoogleCodeExporter]

Thanks guys. So yeah looks like MSFT patched nt and now there's multiple 
versions of the same struct. This is similar to issue #174 which is still open 
because we don't have much of a framework for dealing with things like this. 

Also FYI I was using the comparison.py script attached to this issue [1]. It 
tells you which structs changed sizes, which members have been removed, added, 
and if any offsets for members changed. 

So yeah as I said at the end of issue #174 i don't think there's anything we 
can do until there's a way to pick vtypes per PE GUID. That may rely on 
integrating PDB parsing. Another solution would be to change the scanner to not 
use the bottom-up method, which scudette said may need changing before windows 
8 anyway. I hate leaving bugs open but this is fairly minor (limited to 
threadscan on win7 and 2008 sp1 after march)...but we may have to wait to fix 
this one....

[1]. https://code.google.com/p/volatility/issues/detail?id=144#c9

Original comment by michael.hale@gmail.com on 18 Jun 2013 at 4:34

[GoogleCodeExporter]

I'll be finding the update that causes this problem today/tomorrow. I will 
update once I pinpoint it. 

Original comment by wyattroe...@gmail.com on 20 Jun 2013 at 3:58

[GoogleCodeExporter]

This update according to microsoft applies to everything all the way back to 
Windows XPSP3 32bit and 64bit platforms. 
KB2676562
http://technet.microsoft.com/en-us/security/bulletin/ms12-034
Let me know if I can provide any more information I have before and after 
images etc. 

Original comment by wyattroe...@gmail.com on 20 Jun 2013 at 6:46

[GoogleCodeExporter]

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

• Changed state: Duplicate