Windows 7 SP1 - SSDT offset

WINDBG
1

Hi there,

I have recently taken to using LiveKD to periodically audit my system
manually using debug scripts.

Part of this is constructing the SSDT table using the kernel pointers
keServiceDescriptorTable and kiServiceTable.

The output to show the top of the listing (bottom of the table) is typically
shown below.

[Win 7 SP1 x64]

I have not seen many listings that explain the 3rd listed offset, and some
explanations are hooked/poisoned entries throw to memories outside of kernel
space might be malware.

Is this something abnormal?

What methods are available to confirm the integrity of the SSDT?

Can I trace this offset to resolve the function to identify the endpoint?

Thank you.

[start]

Pointers

nt!KeServiceDescriptorTable = Evaluate expression: -8796062627520 =
fffff800`01cfc940

fffff800`01cfc940 01ac0500 fffff800

fffff800`01ac0500 0417c800 02f40b00

nt!KeServiceDescriptorTableShadow = Evaluate expression: -8796062627456 =
fffff800`01cfc980

fffff800`01cfc980 01ac0500 fffff800

fffff800`01ac0500 0417c800 02f40b00

nt!KeServiceDescriptorTable (length)= Evaluate expression: -8796062627504 =
fffff800`01cfc950

Evaluate expression: 401 = 00000000`00000191

nt!KeServiceDescriptorTableShadow (length)= Evaluate expression:
-8796062627440 = fffff800`01cfc990

Evaluate expression: 401 = 00000000`00000191

nt!KiServiceTable = Evaluate expression: -8796064971520 = fffff800`01ac0500

fffff800`01ac0500 0417c800 02f40b00

nt!KiArgumentTable = Evaluate expression: -8796064968308 = fffff800`01ac118c

fffff800`01ac118c 14000000 00041418

Top of descriptor table only

Evaluate expression: -8796064971520 = fffff800`01ac0500

fffff800`01ac0500 0417c800

fffff800`01ac0504 02f40b00

fffff800`01ac0508 fff6f000 ? this offset cannot be resolved into
a SSDT function

fffff800`01ac050c 02e7b605

fffff800`01ac0510 031b1506

fffff800`01ac0514 03123a05

fffff800`01ac0518 02b9f201

fffff800`01ac051c 02b376c0

fffff800`01ac0520 0313b840

fffff800`01ac0524 03f0e500

fffff800`01ac0528 02c62f00

fffff800`01ac052c 02e70e80

fffff800`01ac0530 02f54700

fffff800`01ac0534 02de8a01

fffff800`01ac0538 02db6c01

fffff800`01ac053c 02d75100

[end]

01 -----------------------------

nt:KiServiceTable Offset: 0417c800

Evaluate expression: -8796060679808 = fffff800`01ed8180

nt!NtMapUserPhysicalPagesScatter:

02 -----------------------------

nt:KiServiceTable Offset: 02f40b00

Evaluate expression: -8796061874768 = fffff800`01db45b0

nt!NtWaitForSingleObject:

03 -----------------------------

nt:KiServiceTable Offset: fff6f000

Evaluate expression: 1152912708541838336 = 0ffff800`01ab7400

* not fetched (fault) *

2

Try sign extending the offset out to be 64-bit (i.e. add ffffffff`ffff6f00)

-scott
OSR
@OSRDrivers

“ete” wrote in message news:xxxxx@windbg…

Hi there,

I have recently taken to using LiveKD to periodically audit my system
manually using debug scripts.

Part of this is constructing the SSDT table using the kernel pointers
keServiceDescriptorTable and kiServiceTable.

The output to show the top of the listing (bottom of the table) is typically
shown below.

[Win 7 SP1 x64]

I have not seen many listings that explain the 3rd listed offset, and some
explanations are hooked/poisoned entries throw to memories outside of kernel
space might be malware.

Is this something abnormal?

What methods are available to confirm the integrity of the SSDT?

Can I trace this offset to resolve the function to identify the endpoint?

Thank you.

[start]

Pointers

------------------------------------------------------------------

nt!KeServiceDescriptorTable = Evaluate expression: -8796062627520 =
fffff80001cfc940<br><br>fffff80001cfc940 01ac0500 fffff800

fffff80001ac0500 0417c800 02f40b00<br><br>nt!KeServiceDescriptorTableShadow = Evaluate expression: -8796062627456 = <br>fffff80001cfc980

fffff80001cfc980 01ac0500 fffff800<br><br>fffff80001ac0500 0417c800 02f40b00

nt!KeServiceDescriptorTable (length)= Evaluate expression: -8796062627504 =
fffff80001cfc950<br><br>Evaluate expression: 401 = 0000000000000191

nt!KeServiceDescriptorTableShadow (length)= Evaluate
expression: -8796062627440 = fffff80001cfc990<br><br>Evaluate expression: 401 = 0000000000000191

nt!KiServiceTable = Evaluate expression: -8796064971520 = fffff80001ac0500<br><br>fffff80001ac0500 0417c800 02f40b00

nt!KiArgumentTable = Evaluate expression: -8796064968308 = fffff80001ac118c<br><br>fffff80001ac118c 14000000 00041418

Top of descriptor table only

------------------------------------------------------------------

Evaluate expression: -8796064971520 = fffff80001ac0500<br><br>fffff80001ac0500 0417c800

fffff80001ac0504 02f40b00<br><br>fffff80001ac0508 fff6f000 ß this offset cannot be resolved into
a SSDT function

fffff80001ac050c 02e7b605<br><br>fffff80001ac0510 031b1506

fffff80001ac0514 03123a05<br><br>fffff80001ac0518 02b9f201

fffff80001ac051c 02b376c0<br><br>fffff80001ac0520 0313b840

fffff80001ac0524 03f0e500<br><br>fffff80001ac0528 02c62f00

fffff80001ac052c 02e70e80<br><br>fffff80001ac0530 02f54700

fffff80001ac0534 02de8a01<br><br>fffff80001ac0538 02db6c01

fffff80001ac053c 02d75100<br><br>[end]<br><br>01 -----------------------------<br><br>nt:KiServiceTable Offset: 0417c800<br><br>Evaluate expression: -8796060679808 = fffff80001ed8180

nt!NtMapUserPhysicalPagesScatter:

02 -----------------------------

nt:KiServiceTable Offset: 02f40b00

Evaluate expression: -8796061874768 = fffff80001db45b0<br><br>nt!NtWaitForSingleObject:<br><br>03 -----------------------------<br><br>nt:KiServiceTable Offset: fff6f000<br><br>Evaluate expression: 1152912708541838336 = 0ffff80001ab7400

* not fetched (fault) *

3

Thanks for replying Scot, in attempting to understand your suggestion I tried several permutations but none of them worked in resolving a function address.

I noticed the left MSbyte of the resolved lookup was zeroed.
So I padded it with '1’s and it now finds a function.

No idea if this is correct. Is it?

This=> 0ffff800`01ab7400
^

Becomes: fffff800`01ab7400
nt!NtCallbackReturn

Could you confirm this is normal for the SSDT construct?
Thanks.

4

The 3rd offset is not abnormal, it is simply a negative offset. As Scott
said you should sign extend it to a 64-bit value, perform a shift right
*arithmetic* by 4 (i.e. the top BYTE will remain 0xF and you will not have
to pad it) and only then add it to the base.

So for your case you would have:
? poi(nt!KeServiceDescriptorTable) + ( fff6f000 >>> 4 )

On 17 June 2015 at 02:20, wrote:

> Thanks for replying Scot, in attempting to understand your suggestion I
> tried several permutations but none of them worked in resolving a function
> address.
>
> I noticed the left MSbyte of the resolved lookup was zeroed.
> So I padded it with '1’s and it now finds a function.
>
> No idea if this is correct. Is it?
>
> This=> 0ffff80001ab7400<br>&gt; ^<br>&gt;<br>&gt; Becomes: fffff80001ab7400
> nt!NtCallbackReturn
>
> Could you confirm this is normal for the SSDT construct?
> Thanks.
>
>
>
> —
> WINDBG is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

5

Thank you Scott and Alexandru for the explanations - by fluke the result was the same.

The difference was in right shifting the pointers using >> instead of the more correct >>>

> did not affect the results for other pointers with zeroed 32bit MSBytes…
>> works for all of them, resolving that issue.

Thumbs up!