OBJECT_TYPE handling needs extending to work on Windows 7 images

[GoogleCodeExporter]

Hiya guys,

It looks as though the Files plugin doesn't work on Windows 7 images.  
Initially this was due to the array being instantiated at an invalid address, 
and throwing an exception (in earlier versions this check was done once the 
loop had started), but even with that fixed it still seems to be having issues.

I dunno why the TableCode/ObjectTable stuff isn't working.  All the right 
profile elements seem to be defined, and that's as far as my knowledge goes, so 
I'm going to have to call in an expert to investigate please...

Original issue reported on code.google.com by mike.auty@gmail.com on 18 Aug 2010 at 1:32

• Blocking: #9

[GoogleCodeExporter]

Ok, quick update.  This seems to be because Windows 7 _OBJECT_HEADERs don't 
have a Type field, they have a TypeIndex, which appears to require knowing 
where a separate table is [1,2].  Without that, the handle finder (in 
overlays/Windows/xp_sp2, _EPROCESS definition) won't return any handles.  The 
good news is, this doesn't appear to affect Vista, but he haven't really 
started on testing the plugins against Vista yet.

So, since this differs between profiles, we probably want to either override 
the _EPROCESS object in the Windows 7 overlay with one that produces the 
handles() list differently, or override the _OBJECT_HEADER object to have a 
get_type() function that gets the type on all the different profiles.  We'll 
also need to check if the return objects all have the same members, or whether 
we need to alter the plugins in any way (since I think several of them re-read 
the type once it's been found by the handles() function).

So, anyone up for figuring out where the ObjectTypeIndexTable's kept?

[1] Message 26 on http://www.osronline.com/showthread.cfm?link=161424
[2] 
http://forum.sysinternals.com/windows-7-Object-type-difference_topic23393.html

Original comment by mike.auty@gmail.com on 20 Aug 2010 at 7:32

[GoogleCodeExporter]

Ok, so attc's done some great work and found out that ObjectTypeIndexTable is 
exported, so should be possible to track down.  It works out as a list of 
_OBJECT_TYPE objects, which all have _LIST_ENTRYs at the start, so find one you 
find them all.

Now it looks as though we've got two options.  The first is to find some way to 
pull out the location of this table during the pdb/vtypes extraction and store 
them in the profile.  The other option is to try and find them with some kind 
of a scan.

What are people's suggestions for solving this one?

Original comment by mike.auty@gmail.com on 21 Aug 2010 at 12:33

[GoogleCodeExporter]

okay I think scudette and I found something good that should provide 100% 
positive signature*

so from [1] in "comment 1":

0: kd> dd nt!ObTypeIndexTable
06:01 <attc> 827478c0 00000000 bad0b0b0 83d33ce8 83d33c20
06:01 <attc> 827478d0 83d33b58 83d33910 83d337d0 83d33708
06:01 <attc> 827478e0 83d33640 83d33578 83d334b0 83dbbca0

which is the same thing I saw when I was debugging the kernel. The "signature" 
part is the second entry, "bad0b0b0", which I tested with a script and only 
shows up once in the win7vss.vmem. I then googled the value and found this:

http://www.osronline.com/showThread.cfm?link=32441

message 6:

""bad0b0b0", eh? It's been my experience that this value appears in the object 
type field after an object has been freed."

and since each object_type is only in memory once because of the table it 
should be the only version of it.

* it "should" be the only version, obviously a malware piece could throw it all 
around memory. for that purpose, stronger checking should be done such as 
checking the other _object_types "name" member to see if they are something 
reasonable or any other check that can be done. also we still need to enumerate 
that table once its found in order to know what each _object_type is. hopefully 
the "name" member can accomplish this.

Original comment by atc...@gmail.com on 22 Aug 2010 at 4:14

[GoogleCodeExporter]

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

• Changed title: OBJECT_TYPE handling needs extending to work on Windows 7 images

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

• Added labels: Milestone-Release1.4

[GoogleCodeExporter]

This issue has been fixed by r630.  YAY!  5:)

Original comment by mike.auty@gmail.com on 30 Jan 2011 at 6:16

• Changed state: Fixed

[GoogleCodeExporter]

Here is the complete list of info for the TypeIndexMap VolatilityMagic in 
win7_sp0_x86.py:

'Type' : 0x2,
'Directory' : 0x3,
'SymbolicLink' : 0x4,
'Token' : 0x5,
'Job' : 0x6,
'Process' : 0x7,
'Thread' : 0x8,
'UserApcReserve' : 0x9,
'IoCompletionReserve' : 0xa,
'DebugObject' : 0xb,
'Event' : 0xc,
'EventPair' : 0xd,
'Mutant' : 0xe,
'Callback' : 0xf,
'Semaphore' : 0x10,
'Timer' : 0x11,
'Profile' : 0x12,
'KeyedEvent' : 0x13,
'WindowStation' : 0x14,
'Desktop' : 0x15,
'TpWorkerFactory' : 0x16,
'Adapter' : 0x17,
'Controller' : 0x18,
'Device' : 0x19,
'Driver' : 0x1a,
'IoCompletion' : 0x1b,
'File' : 0x1c,
'TmTm' : 0x1d,
'TmTx' : 0x1e,
'TmRm' : 0x1f,
'TmEn' : 0x20,
'Section' : 0x21,
'Session' : 0x22,
'Key' : 0x23,
'ALPC Port' : 0x24,
'PowerRequest' : 0x25,
'WmiGuid' : 0x26,
'EtwRegistration' : 0x27,
'EtwConsumer' : 0x28,
'FilterConnectionPort' : 0x29,
'FilterCommunicationPort' : 0x2a,
'PcwObject' : 0x2b,

Original comment by michael.hale@gmail.com on 1 Feb 2011 at 6:40

[GoogleCodeExporter]

Thanks for checking in the additional types MHL, I've been a bit distracted the 
past couple of days, sorry...  5:(

Original comment by mike.auty@gmail.com on 3 Feb 2011 at 1:13

[GoogleCodeExporter]

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

• Added labels: Milestone-1.4.x
• Removed labels: Milestone-Release1.4