Low level WinNT debugger

[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

there's no magic in it.
it's merely a simple text substitution going on.

It just keeps track of what it has modified. When you want to view something that was modified, it just substitutes it before displaying it to you. There's no need for special tricks, softice controls what and how to display.