ssdt plugin needs updating to work on windows 7 image

[GoogleCodeExporter]

Currently the ssdt plugin will return no results for a windows 7 image.

It'd be good if this could be updated to work with windows 7.

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

• Blocking: #9

[GoogleCodeExporter]

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

[GoogleCodeExporter]

Hey guys,

I was able to get the ssdt plugin working for Win7. Here's what I did:

1) From ssdt.ssdt_types, I removed the following lines and added them to 
xp_sp2_x86_vtypes.py:

#  '_ETHREAD' : [ None, {
#    'ThreadListEntry' : [ 0x22c, ['_LIST_ENTRY']],
#} ],
#  '_KTHREAD' : [ None, {
#    'ServiceTable' : [ 0xe0, ['pointer', ['_SERVICE_DESCRIPTOR_TABLE']]],
#} ],

The proper offsets for XPSP3, Vista, and 7 are already in their respective 
files, so they are OK. However, I had to change the ServiceTable from 
pointer->void to pointer->_SERVICE_DESCRIPTOR_TABLE in all of them.

2) Changed ssdt.syscalls into a list of dictionaries, similar to this: 
http://miscellaneouz.googlecode.com/svn/trunk/winsyscalls/winsyscalls.py. I 
modified that a tiny bit so there is one entry for each table (so syscalls[0] 
is for native and syscalls[1] is for gui).  The dic keys are syscall names, and 
the values are lists of SSDT function indexes for various OSs. The index is -1 
if a given function doesn't exist in the SSDT for an OS.

3) The proper values are chosen based on the Volatility profile in use. I 
really don't know if this is how you want to keep it, so I haven't filled in 
the win32k info yet.

4) In the attached ssdt.py there are a few other mods - one for speed and one 
for some extra sanity checks. 

Thoughts? 

Original comment by michael.hale@gmail.com on 11 Nov 2010 at 8:52

Attachments:

• ssdt.py

[GoogleCodeExporter]

Is there any way to pull the SSDT from the pdb files?

Original comment by scude...@gmail.com on 11 Nov 2010 at 9:18

[GoogleCodeExporter]

BDG has a script 
(http://code.google.com/p/pdbparse/source/browse/get_syscall_table.py?spec=svn55
&r=55) which seems to work, at least for the XPSP3 system that I used for 
testing:

$ python get_syscall_table.py ntoskrnl.exe ntoskrnl.pdb

Ordinal 0x0000 Name: NtAcceptConnectPort Args: 6 (0x18 bytes) Offset: 0xb21f1
Ordinal 0x0001 Name: NtAccessCheck Args: 8 (0x20 bytes) Offset: 0xa22d1
Ordinal 0x0002 Name: NtAccessCheckAndAuditAlarm Args: 11 (0x2c bytes) Offset: 
0xb55e8
[...]

This tool requires the NT and Win32k files though (not just the PDBs). I'm not 
sure if there's a way to pull straight from the PDB. 

Original comment by michael.hale@gmail.com on 11 Nov 2010 at 11:07

[GoogleCodeExporter]

You can pull the SSDT from a combination of the PE and PDB for ntoskrnl or 
win32k. Basically, you find the offset of KiServiceTable or W32pServiceTable 
using the PDB, then go look in the PE file for that table. 
KiServiceLimit/W32pServiceLimit will then tell you how many entries to read. 
These are the pointers to the system calls themselves, and you can then look up 
the symbol associated with that address to get the name of the system call.

I have a script that does this, but I have only tested it on XP 32 bit:
http://code.google.com/p/pdbparse/source/browse/get_syscall_table.py

Original comment by moo...@gmail.com on 11 Nov 2010 at 11:09

[GoogleCodeExporter]

I just tested with ntoskrnl.exe/ntkrnlmp.pdb from a Win7 machine and it worked 
fine. So what should we do here...gather the exe and pdb files from the NT 
module and Win32k module from all OS's we want the ssdt module to support? Put 
them in some location that everyone can access? 

Any comments on the format of the ssdt.syscalls...should it be kept as I have 
it or should the lists be separated into profiles?

Original comment by michael.hale@gmail.com on 11 Nov 2010 at 11:23

[GoogleCodeExporter]

I'm just making my way through the code, so I'm still learning exactly what the 
SSDT is and how it works, but it strikes me that if the data's per profile, we 
should probably store it per-profile, and if it's per-DLL-per-profile then we 
should probably still have it split into per profile data.  It's only if the 
data's shared across profiles that it might be work keeping it all together.

If it's going to be a core plugin, then it's not a problem keeping it in the 
non-generated areas, until we can ensure automatic generation (like the vtypes 
at the moment).

If we think that'll be hard to manage, or that automatic generation isn't on 
the cards, then it might be worth having SSDT data tables (again per profile), 
which can be read in by the plugin from a resource directory somewhere (or just 
more python files if people are happy with that).

Original comment by mike.auty@gmail.com on 11 Nov 2010 at 11:28

[GoogleCodeExporter]

Also, just to mention, this might tie in with issue 6, in that both need a way 
of storing offsets/data from specific EXEs/DLLs.  I was envisaging doing that 
through volatiltity magic constants, but I haven't decided if that's the best 
way or whether there should be some special storage system for multiple options 
per profile (different DLLs on essentially the same system)...

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

[GoogleCodeExporter]

Ok, so (since I seem to have forgotten to say it in my first comments), great 
work!  5:)  I've integrated some of the changes from your file.  Until we get 
the XPSP2 autogenerated files, I've included the two bits that *would* be 
autogenerated into the current XPSP2 profile.

I've left the ServiceTable entry as a pointer to void, since that's what the 
other autogenerated values will show.  We've got two options:

* the first is to overlay on top of the profiles, changing the pointer to void 
to a pointer to _SERVICE_DESCRIPTOR_TABLE, but then we'll need to include the 
_SERVICE_DESCRIPTOR_TABLE for each profile.  
* If the structures are the same for every profile, then the better (and 
current option), is to use dereference_as on the pointer, rather than just 
dereference.

Finally I added the additional checks (such as checking ServiceLimit, etc), so 
thanks for those!

Once we figure out the best format for storing the tables, we can get the it 
all integrated, and have another multi-platform plugin!  Yay!  5:)

Original comment by mike.auty@gmail.com on 12 Nov 2010 at 12:42

[GoogleCodeExporter]

Excellent, this sounds good. As far as I know, _SERVICE_DESCRIPTOR_TABLE is the 
same on all platforms, so dereference_as may be the best fit. Thanks!

Original comment by michael.hale@gmail.com on 12 Nov 2010 at 2:36

[GoogleCodeExporter]

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

[GoogleCodeExporter]

This is just about done, pending a few minutes of verification tomorrow. By 
noon we should have patches so that ssdt works accurately on all profiles for 
which Volatility current supports. 

Original comment by michael.hale@gmail.com on 21 Jan 2011 at 6:36

[GoogleCodeExporter]

Excellent, all committed (r603) after splitting out the tables (since they 
rather swamp the profile itself, which I'd like to keep a clear list of the 
tweaks required).  That's another one... FIXED! 5:)

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

• Changed state: Fixed