KGDTENTRY in hibernate_vtypes.py masks the real KGDTENTRY

[GoogleCodeExporter]

Hey guys, 

This may relate to some issues discussed recently, but I wanted to point out an 
issue after running into it today while researching something else (and the 
issue exists currently in trunk). 

Basically, _KGDTENTRY is defined in two places. It's defined in the OS profile. 
For example in xpsp2:

http://code.google.com/p/volatility/source/browse/trunk/volatility/plugins/overl
ays/windows/xp_sp2_x86_vtypes.py#2686

  '__unnamed_1501' : [ 0x4, {
    'BaseMid' : [ 0x0, ['BitField', dict(start_bit = 0, end_bit = 8)]],
    'Type' : [ 0x0, ['BitField', dict(start_bit = 8, end_bit = 13)]],
    'Dpl' : [ 0x0, ['BitField', dict(start_bit = 13, end_bit = 15)]],
    'Pres' : [ 0x0, ['BitField', dict(start_bit = 15, end_bit = 16)]],
    'LimitHi' : [ 0x0, ['BitField', dict(start_bit = 16, end_bit = 20)]],
    'Sys' : [ 0x0, ['BitField', dict(start_bit = 20, end_bit = 21)]],
    'Reserved_0' : [ 0x0, ['BitField', dict(start_bit = 21, end_bit = 22)]],
    'Default_Big' : [ 0x0, ['BitField', dict(start_bit = 22, end_bit = 23)]],
    'Granularity' : [ 0x0, ['BitField', dict(start_bit = 23, end_bit = 24)]],
    'BaseHi' : [ 0x0, ['BitField', dict(start_bit = 24, end_bit = 32)]],
} ],
  '__unnamed_1503' : [ 0x4, {
    'Bytes' : [ 0x0, ['__unnamed_14fa']],
    'Bits' : [ 0x0, ['__unnamed_1501']],
} ],
  '_KGDTENTRY' : [ 0x8, {
    'LimitLow' : [ 0x0, ['unsigned short']],
    'BaseLow' : [ 0x2, ['unsigned short']],
    'HighWord' : [ 0x4, ['__unnamed_1503']],
} ],

Its also defined in hibernate_vtypes.py  here:

http://code.google.com/p/volatility/source/browse/trunk/volatility/plugins/overl
ays/windows/hibernate_vtypes.py#20

 '_KGDTENTRY' : [  0x8 , {
  'BaseLow' : [ 0x2 , ['unsigned short']],
  'BaseMid' : [ 0x4, ['unsigned char']],
  'BaseHigh' : [ 0x7, ['unsigned char']],
} ],

Unfortunately the one in hibernate_vtypes.py overwrites the one in the main 
profile, so if I wanted to access _KGDTENTRY.HighWord.Bits.Dpl (for example) in 
a plugin, I'd get an AttributeError. 

So I think the fix for this is going to be:

1) Delete the version of _KGDTENTRY in hibernate_vtypes.py
2) Fix whatever code in the hibernation plugin to use the members in the main 
OS profile 

Original issue reported on code.google.com by michael.hale@gmail.com on 14 Feb 2012 at 10:50

[GoogleCodeExporter]

Yeah, I noticed that too when writing a patch for hibernation file support that 
_KGDTENTRY is defined in all vtypes and varies somewhat between OSes.  I think 
presently the only place it is used is in hibinfo 
(http://code.google.com/p/volatility/source/browse/trunk/volatility/plugins/hibi
nfo.py#42) and that (to get NtTibAddress) code only works as is for XP and 2K3 
x86.

Original comment by jamie.l...@gmail.com on 14 Feb 2012 at 11:29

[GoogleCodeExporter]

OK thanks to Gleeda and AW for some thoughts, we have a patch. Please take a 
look and let me know. 

So there are several compelling reasons why the code must be patched:

* The current method that relies on finding TEB (NtTibAddress) by looking up 
the 7th (0x3B >> 3) entry in the GDT only applies to XP/2K3 x86

* In other words the current method specifically does not work on any x64 

* Even on XP/2K3 x86 the current method isn't guaranteed to work. The 7th entry 
in the GDT may be 0 based on context switch at the time of the memory dump. For 
example from 4 different XP samples, using the gdt plugin, 75% of the time the 
value was 0. 

Sel       Base              Limit        Type           DPL    Gr     Pr
0x38   0x0               0xfff        Data RW Ac     3      By     P  

0x38   0x7ffdd000   0xfff        Data RW Ac     3      By     P

0x38   0x0               0xfff        Data RW Ac     3      By     P

0x38   0x0               0xfff        Data RW Ac     3      By     P

* The current method requires the KGDTENTRY vtype in hibernate_vtypes.py which 
overwrites/masks the real profile's KGDTENTRY vtype definition. 

The method in the proposed patch (is really Gleeda's method) works for all OS 
on x86 and x64. 

Original comment by michael.hale@gmail.com on 15 Feb 2012 at 5:47

Attachments:

• volatility-hibinfo-peb.patch

[GoogleCodeExporter]

Looks good from a code point of view, no idea if Peb blocks are the same 
between different tasks, or if it doesn't matter.  I'll leave that matter up to 
a different reviewer...  5:)

Original comment by mike.auty@gmail.com on 15 Feb 2012 at 10:12

[GoogleCodeExporter]

The Peb blocks are technically different (different virtual addresses in each 
process, many fields *can* and are different between processes), but the only 
fields printed by hibinfo (peb.OSMajorVersion, peb.OSMinorVersion, 
peb.OSBuildNumber) should definitely be the same in all Pebs. 

Original comment by michael.hale@gmail.com on 15 Feb 2012 at 10:17

[GoogleCodeExporter]

I'll commit this later today if no one objects.

Original comment by michael.hale@gmail.com on 16 Feb 2012 at 2:17

[GoogleCodeExporter]

This issue was closed by revision r1449.

Original comment by mike.auty@gmail.com on 18 Feb 2012 at 11:01

• Changed state: Fixed