Low level WinNT debugger

http://www.sysinternals.com/ntw2k/freeware/debugview.shtml
http://www.sysinternals.com/files/dbgvnt.zip

DebugView is an application that lets you monitor debug output on your local system, or any computer on the network that you can reach via TCP/IP. It is capable of displaying both kernel-mode and Win32 debug output, so you don抰 need a debugger to catch the debug output your applications or device drivers generate, nor do you need to modify your applications or drivers to use non-standard debug output APIs.

DebugView works on Windows 95, 98, Me, NT 4, 2000, XP and .NET Server.
DebugView Capture


Under Windows 95, 98, and Me DebugView will capture output from the following sources:
Win32 OutputDebugString
Win16 OutputDebugString
Kernel-mode Out_Debug_String
Kernel-mode _Debug_Printf_Service
Under Windows NT, 2000, XP and .NET Server DebugView will capture:
Win32 OutputDebugString
Kernel-mode DbgPrint
All kernel-mode variants of DbgPrint implemented in Windows XP and .NET Server
DebugView also extracts kernel-mode debug output generated before a crash from Window NT/2000/XP crash dump files if DebugView was capturing at the time of the crash.

Originally Posted by _kin_

SoftICE have at least two components ALL components load as standard
drivers:
1. siwvid.sys - mostly UI code load as SERVICE_BOOT_START driver

2. ntice.sys - SoftICE heart can load as SERVICE_BOOT_START but also
can load as SERVICE_SYSTEM_START or SERVICE_DEMAND_START drver

Most frequently ntice.sys configured as SERVICE_SYSTEM_START driver

3. Sometimes if ntice.sys load as SERVICE_BOOT_START it use third part:
siwsym.sys - SERVICE_BOOT_START driver where packed symbolic and config
info. This module used because in time when loaded SERVICE_BOOT_START drivers no file I/O services available (this drivers load by NTLDR).

P.S. Sorry for my poor english

Thank you for your reply.

Sorry if this is a dumb question, but if that is the case, what's stopping another driver from loading and debugging softice. Or is there nothing stopping that?

Originally Posted by auroras

Thank you for your reply.

Sorry if this is a dumb question, but if that is the case, what's stopping another driver from loading and debugging softice. Or is there nothing stopping that?

SoftICE has check to prevent debugging itself.

When it loaded (started), It patch some system parts (kernel, keyboard driver and so on) to get control over system. Also, as I know SoftICE change
system IDT and "virtualize" it - in debugger you see system IDT, but real IDT is hidden by SoftICE.

Originally Posted by _kin_

SoftICE has check to prevent debugging itself.

Also, as I know SoftICE change system IDT and "virtualize" it - in debugger you see system IDT, but real IDT is hidden by SoftICE.

Ahh...now I see

So is virtualising the IDT a function provided within the Kernel API, or is it some hack that SoftICE comes up with. I haven't come across any documentations on that.

In fact, when I posted a similar question on the Microsoft MSDN list, try to directly handle certain interrupts in a driver, I was told that it couldn't be done, and that it had to go through the IoConnectInterrupt().

Thanks

Sample IDT dump from Softice (w2k sp4)

0000  IntG32   0008:80466B36  DPL=0  P   ntoskrnl!Kei386EoiHelper+0590
0001  IntG32   0008:80466C86  DPL=3  P   ntoskrnl!Kei386EoiHelper+06E0
0002  IntG32   0008:0000145E  DPL=0  P
0003  IntG32   0008:80466F5E  DPL=3  P   ntoskrnl!Kei386EoiHelper+09B8
0004  IntG32   0008:804670C2  DPL=3  P   ntoskrnl!Kei386EoiHelper+0B1C
0005  IntG32   0008:80467206  DPL=0  P   ntoskrnl!Kei386EoiHelper+0C60
0006  IntG32   0008:8046736A  DPL=0  P   ntoskrnl!Kei386EoiHelper+0DC4
0007  IntG32   0008:80467903  DPL=0  P   ntoskrnl!Kei386EoiHelper+135D
0008  TaskG    0050:000014B8  DPL=0  P
0009  IntG32   0008:80467CBF  DPL=0  P   ntoskrnl!Kei386EoiHelper+1719
000A  IntG32   0008:80467DC7  DPL=0  P   ntoskrnl!Kei386EoiHelper+1821
000B  IntG32   0008:80467EF3  DPL=0  P   ntoskrnl!Kei386EoiHelper+194D
000C  IntG32   0008:804681F8  DPL=0  P   ntoskrnl!Kei386EoiHelper+1C52
000D  IntG32   0008:80468404  DPL=0  P   ntoskrnl!Kei386EoiHelper+1E5E
000E  IntG32   0008:80468E78  DPL=0  P   ntoskrnl!Kei386EoiHelper+28D2
000F  IntG32   0008:80469213  DPL=0  P   ntoskrnl!Kei386EoiHelper+2C6D

...and from my own descriptor table dumper:

#0000: 0000 [00000008:80466b36] * 32bit=1, gran=0, present=1, dpl=0, type=[S] 32-bit Interrupt Gate      
#0001: 000b [00000008:b3fcd769] * 32bit=1, gran=1, present=1, dpl=3, type=[S] 32-bit Interrupt Gate      
#0002: 0010 [00000008:b3fcd778] * 32bit=1, gran=1, present=1, dpl=0, type=[S] 32-bit Interrupt Gate      
#0003: 001b [00000008:b3fcd787] * 32bit=1, gran=1, present=1, dpl=3, type=[S] 32-bit Interrupt Gate      
#0004: 0023 [00000008:804670c2] * 32bit=1, gran=0, present=1, dpl=3, type=[S] 32-bit Interrupt Gate      
#0005: 0028 [00000008:80467206] * 32bit=1, gran=0, present=1, dpl=0, type=[S] 32-bit Interrupt Gate      
#0006: 0030 [00000008:b3fcd796] * 32bit=1, gran=1, present=1, dpl=0, type=[S] 32-bit Interrupt Gate      
#0007: 0038 [00000008:80467903] * 32bit=1, gran=0, present=1, dpl=0, type=[S] 32-bit Interrupt Gate      
#0008: 0040 [00000050:000014b8] * 32bit=0, gran=0, present=1, dpl=0, type=[S] Task Gate                  
#0009: 0048 [00000008:80467cbf] * 32bit=1, gran=0, present=1, dpl=0, type=[S] 32-bit Interrupt Gate      
#000a: 0050 [00000008:80467dc7] * 32bit=1, gran=0, present=1, dpl=0, type=[S] 32-bit Interrupt Gate      
#000b: 0058 [00000008:b3fcd7a5] * 32bit=1, gran=1, present=1, dpl=0, type=[S] 32-bit Interrupt Gate      
#000c: 0060 [00000008:b3fcd7b4] * 32bit=1, gran=1, present=1, dpl=0, type=[S] 32-bit Interrupt Gate      
#000d: 0068 [00000008:b3fcd7c3] * 32bit=1, gran=1, present=1, dpl=0, type=[S] 32-bit Interrupt Gate      
#000e: 0070 [00000008:b3fcd7d2] * 32bit=1, gran=1, present=1, dpl=0, type=[S] 32-bit Interrupt Gate      
#000f: 0078 [00000008:80469213] * 32bit=1, gran=0, present=1, dpl=0, type=[S] 32-bit Interrupt Gate

As you can clearly see, real values are NOT the one Softice shows you

One fascinating behavior of sice is that when you bring out sice console, the entire system runs only one thread only--the sice thread, the schedular, I/O, etc instantly stops and sice takes control the entire system. This is indication of system hooking of IDT, TSS, GDT, LDT, you name it, anything that has to do with scheduling, I/O. So in fact it doesn't matter when s-ice is loaded, but once it's loaded, it took over the entire system. And sice HOOK everything that's necessary so that when s-ice console is up, s-ice thread is the only thing that runs on your CPU. And notably this HOOKING only occurs when the console is up, so I am guessing sice is reporting the correct idt, however, there is no other way to tell if sice is lying because when sice console is active, no other thread can run. So when you list the two tables, they are taken at two different time and they really don't mean anything. Only if you could manage to take 2 snapshots, one from sice, one from another application of the idt at the same time, you can tell if sice is reporting the real idt as it is seen by the cpu. I am inclined to think sice is reporting the correct idt at the moment it's active.

As far as I know, M$ kernel debugger kd does not do this, for that matter nothing else other than sice on windows effective turns windows OS into a dos like OS.

Well, Sice IDT dump shows that int1 & int3 handlers are in the ntoskrnl - but I think it's SI's code that really handles those ints. Maybe SI hooks itself inside windows handlers instead of just replacing IDT entries - I'm not that familiar with its internal working

[edit]
Just checked what's at address displayed by my dumper:

:bpx 8:b3fcd778
Breakpoints not allowed within SoftICE

Remember that even in ring0 there are IRQL interrupt priorities.

Maybe Softice has a higher priority.

Or, maybe I don't know what I'm talking about.

I know that, it just proves that int1 & int3 handlers are within softice, but softice doesn't display it.

[edit]
Looking from LiveKD with softice loaded shows this too.

[SiNTAX]

SoftICE is virtualising certain hardware parts of the system, tricking WinNT so to speak. You can compare it a bit with VMware or VirtualPC.. only that those 2 go way further in the virtualisation (ie. they also create virtual devices, which SoftICE doesn't do ofcourse).

I took a little time to look into the numbers, in fact, the numbers reported from sice for int3 and int0 interrupt handlers are the right address. This means either your kernel dumper is not working correctly or when you took the snapshot sice is not loaded. On my system, w2k+sp4, everything says 60466f5e is the right address for int3. And nobody knows what b3fcd787 is, in fact, by manually going through the PTE, this address is never allocated in the kernel.

Well, my tool is avaliable here: ry.pl/~omega/asm/sdt.zip
with source code in nasm.
And at ry.pl/~omega/sdt.jpg you can see output from livekd compared to output from this tool.

Originally Posted by homersux

And nobody knows what b3fcd787 is

As my previous post show, it IS allocated - by softice - which prohibits setting breakpoint at that address because of self-protection.

Breakpoints not allowed within SoftICE

softice hooks these interrupts, but obviously, for a successful hook to occur, it needs the "old handler address"... that's all that is being displayed to you when you view the idt within softice. SoftICE swaps the addresses back before displaying them - because it knows what's hooked.

It is the same thing as when you do :
bpx MessageBoxA
u MessageBoxA

in reality, softice changed the first byte of this function (to 0xCC), but when you do "u MessageBoxA" the function appears normally. SoftICE keeps track of this stuff internally and substitutes it before displaying.

btw, IceExt has an internal command (!idt) that displays the real values.

Well, Ok I tried "bpx b3fcd787" in sice 4.27, I didn't get that error message. But if you "d b3fcd787", it's all '?', which means non-present memory and it's not in PTE table. livekd reports same idt int3 handler address as sice on my computer. I'll take a look at the source code later, but there is another thing fishy about the sdt dumper because all its b3fcxxxx addresses show granuality = 1 (4kbytes per descriptor limit) while the good 80xxxxxx ones show granuality = 0.

I won't go into the debate about whether the IDT dump is correct or not, since you guys are far better at this than I am. However, since there is someone reading this thread, I was wondering *how* would SoftICE do such a thing? That really was my initial question. Is it some hack because Numega knew something about Windows, or is it part of some obscure kernel API?

Thanks
Aur