i want to know some knowledge about kernel debugger just like softice who can debug the whole system . how to do such debugger ?
any reply wil be ok.

Make sure you have more than a passing knowledge of:

1. OS internals
2. Driver models
3. Assembly Code and C

Maybe in about 6-7 months time we can subsequently think of implementing a kernel debugger.

Alternatively, if you are really getting impatient, I'd suggest you move to:

http://www.microsoft.com/ddk

and download the example code. One of the codes is for building a very simplistic kernel debugger.

Have Phun

Wouldn't a device-level debugger be even better? (lower level)

Or get a custom-made CMOS chip that can hold a debugger. (lowest possible level)

Thanks for all relpy ,first
I think I am good at c and assemble ,but i have no experience in Driver Model . I think it is a better way to learn from Example code .
thanks

Hi

An interesting endeavour. A couple of things that might be of interest,

Inside kernel debugging support - an interesting in-depth paper that discusses kernel debugger internals from the WinDbg/KD perspective:
(I've attached the article for preservation)

http://www.vsj.co.uk/articles/display.asp?id=265


Also, if, hypothetically, one had the 'leaked' MS code that was going around a few months ago, then, again hypothetically, one would have a good portion if not all of the source from WinDbg64, in a folder of the same name, which might be of some use (hypothetically speaking of course, heheh



Oooh, my ears perked up...


I'd like to buy a vowel please...

I spent quite some time there yesterday but seem to have missed this example code, any other clues come with this tip?


Cheers,
Kayaker

From a quote from AQUATIC:

Wouldn't a device-level debugger be even better? (lower level)

Or get a custom-made CMOS chip that can hold a debugger. (lowest possible level)

Device level debuggers do exist.
And they are the lowest possible level (Not the CMOS chip statement).

These debuggers are referred to as ice boxes.
They are typically used to debug processors and chipsets, and are also extremely good for debugging code.

Periscope used to sell a redimentary ice box at one time.


Just a little info to hrow into the frey!

TGODD

(1) have a look at BlindStudio: incomplete sources for a kernel debugger from Mamaich. The project is dead, and currently available only from Elicz homepage: h..p://www.anticracking.sk/EliCZ/import/Build3.rar

(2) search Google for [Nt/Zw]SystemDebugControl: the API is available on Windows XP (very limited on Windows 2K) and is very powerful... I think that the best of it has not yet been discovered...

Have phun, Bilbo

Cool, finally I get to know where the hell Numega got the name "Softice" from! (I'd assume it refers to it being a software debugger that's [almost] as good as one of these hardware "ice boxes"

But an integrated CMOS debugger would be better than an ice box.

Look I found one: http://www.gensw.com/pages/prod/bios/debug.htm

Here is giant documentation on an integrated BIOS debugger: http://www.embeddedx86.com/downloads/Manuals/EBIOS-UM.PDF (Page 33)



About Softice.
The 'Soft' refers to 'software' version of the icebox. But I think you figure that out.

There are no anti-debugger tricks for these hardware debuggers, are there?

I don't know if any prot/packer/... uses them, but check
http://www.x86.org/secrets/intelsecrets.htm (check the undocumented opcodes sections)

Check the facilities that the chip provides for debugging with an ice. Then it's fairly easy to think of a few anti-debug tricks.
I haven't been there for a while, but I think some flags in Dr7 and some undocumented opcodes are useful to ice debuggers.

Well, here is a picture: http://www.embeddedx86.com/epc/ts5400-spec.php

16 MBytes of High Speed SDRAM
(32 or 64 MB RAM optional)
2 MByte Flash disk with full BIOS suppport
(4 or 8 MByte Flash optional )

Hey doug, those undocumented opcodes look pretty useful.