Low level WinNT debugger
 

Clarification

Sorry, I wasn't being clear before. But what I really want to know is how SoftICE gets to load so early on in the Windows boot process.


Original Post:

Hi

I was wondering whether anyone knows how low level debuggers
like SoftICE work? I am trying to do something similar but
the lowest level I can get to is to write a software device
driver, which can still be debugged by SoftICE.

i think that everything is about RING mode, even SICE has your own sys driever in %SystemRoot%\system32\drivers

and my friend show me, somotime, that SICE loads up before windows and on Hercules monitor we see loading every windows modules

but inside magic of SICE is (i think) very difficult

and some API hooking ,modifiyng registry,IDT,GDT and other...
Good start point iz learnig how icedump or iceext work from his source code ..
;)

Sorry for my bad english iam only human ;o))

1. read one books..<Debugging Applications>

2. read win2k souce code in windows/windbg/*/...

3. learn some driver dev....

ok.u can design one debugger named.....XSoftice??

I also suggest one good book.
"How debuggers Work",Wiley.
It tell you how the debugger works on windows and Unix .

I don't think Ring 0 code will help. It did back in Win9x, and that's how TRW2000 works. However, I still cannot find any alternatives to SoftICE for WinNT. The problem I see is that the people at NuMega/Compuware seems to know something about WindowsNT that is not published. I can write a low level driver that loads. However, it is not low enough because it can still be debugged by SoftICE! What I want is something that is in the same level at SoftICE, so I can see and maybe alter the loading process of Windows programmatically.

I also suggest one good book.
"How debuggers Work",Wiley.
It tell you how the debugger works on windows and Unix .

Who is the author? And more importantly, do you have a soft copy?

And does it tell you about low level debuggers, or just the application level ones (ie the ones written using the Windows Debugging API)

"Good start point iz learnig how icedump or iceext work from his source code .. "

I am unaware where you can get icedump or iceext's source code....

.. source code is included with exe file try search google for thiz ... or try search CrudeICE it iz free clone of softICe ... EDITED > it have source code included too < sorry thiz iz not true - big mistake, sorry :confused:

Sorry iam only human ;o))

auroras:

I don't think "contributing" a certain number of posts means dividing your response into 3 posts and posting part of it every two minutes. That is called padding your post count. I've made one post out of your comments and deleted the other two.

Regards,

Look for "Debugging Applications" by John Robbins. "Inside MS Windows 2000" by David A. Solomon and Mark E. Russinovich may help you.

SICE's core is a driver

so then if SICE core is kernel driver i think that it can run under ring0 privileges

by u can find some useful thing about Ring mode in very useful virus ezines from 29A labs :)

http://29a.host.sk/

Look for mamaich's BlindStudio debugger with sources on Elicz's site

I don't think it is about whether it is a kernel driver, but rather about when SoftICE loads. SoftICE seems to always start first, and can actually debug other kernel drivers when they load. Just wondering how they manage to do that....

Re: BlindStudio

Thanks a lot!

Intel manuals will be useful as well

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

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.

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.

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)
...and from my own descriptor table dumper:
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:

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.

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.

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

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.