I've had a little experience with patching kernel dll's in XP (64bit).
http://board.flatassembler.net/topic.php?t=4467
Maybe it'll be helpful to you. The thread is in the "blog" format :\

The kernel DLL and EXE have a CRC in the file that needs to be accurate. There's a windows API that will give you the current checksum and the correct checksum (the API's name alludes me at the moment).

I've seen your "system dll patching"... it's a good job. Probably i need to spend more time in this one, before making my kernel hooker.

Hey you all, LISTEN TO ME:
In theese days I tried, another time, the debugging tools for windows xp
(microsoft) because you tell me it's a kernel debugger... yes, it's a kernel
debugger ONLY IF YOU CONNECT IT TO ANOTHER PC USING THE SERIAL PORT (COM1)!

I don't wanna buy another pc for testing its kernel working method!!!
Then: stop thinking the things microsoft writes about its products are good or true!
I told you the debugging tools for Ms isn't ( or aren't ?) a good kernel debugger
and also a good normal debugger! I.D.A. is better, more more better than it.

In any case, thanks, because this forums is here to help us learning more together
about our favourite hobby:

PROGRAMMING!

Yes, for me programming is:

Make every keyboard buttons,
i push into my assembler,
as an alive stuff,
that execute all the instructions i wrote into it,
like an exstension of my will...
...in digital format!

The link I gave you use a VIRTUAL PC, not a real one.

Pirata Derek,

Google for LiveKD. It's excellent tool from Mark Russinovich to use kd on the same machine.

OK, i think K.D. is better to debug in the same machine

Why does Kernel Debugger crash sometimes when i do a STEP on the INT 0x2E ?

I don't modify any registers values.
When i do the STEP, the PC immediatly RESTART!

Is it a BUG or not?

Also is the same if i use the "Sysenter Debugger" (Trial Version)

I think you need a better debugger.

It's strange because 2 different K-Dbg do the same crash!
Sysenter crash more times than the other, in the INT 0x2E

Bah!!!

Pirata Derek,

Do you have "Automatic restart" in system properties' "Startup and Recovery" enabled? Disable and get BSoD, then meditate on that… If it's not enough, get full core dump and analyse it.

Does LiveKD StepInto/StepOver kernel-mode code? Unless I am missing something it only allows you to do live execution of debugging commands (those that allows you to read the page table, read ETHREADS, etc), but by no means it allows you to trace kernel mode code.

Baldr,

Is the same thing without automatic restart turned off.
The only difference is that now, PC stay "Stoned" after INT 0x2E or sometimes it restarts....

I don't understand what it does!

Probably, my computer is exhausted for all my test i do on it !!

LocoDelAssembly,

SPANISH:
El "STEP INTO" en el codigo del kernel lo hago con SYSENTER (debugger por los kerneles), y es Sysenter que me das màs de los problemas que escribì arriba.
Para mi es mejor de K-Dbg del Windows, es màs pratico... pero es TRIAL!

ENGLISH:
I do the "STEP INTO" into the kernel code with SYSENTER Debugger (Kernel mode), and SYSENTER make me the most part of the problems
i wrote before...
I use it because it's more pratic than K-Dbg for windows... but it's trial!

In this month, i've created a little program called "Permanent DLL Injector"
that insert into any target program its DLL, and everytime the target program starts,
it doesn't call the original library.... but the dropped DLL!

The DLL dropped by the injector can do everything before return from the caller.
(example, i can hook all the exported function of the original dll!)

This method lets you to control the target program activity by hooking
its imports without modify directly the original library.

THE TARGET PROGRAM REMAINS HOOKED UNTIL YOU REMODIFY ITS IMPORTS LIBRARY
(For tests use a copy of any original programs)

This is the DLL injector, with its source and a test area,
with a TEST program created by me, where you can test the functionality
of the program....

You can modify the source to change the target program.
(also you have to modify the FAKE DLL Source into the include directory)

If there's a bug, please send me a notify...

Now, i'm going to make a UNIVERSAL DLL that:

- Do what it wants when it is called
- Analyze the called function of the caller program
(library and function name)
- Load the correct library
- Find the virtual address of the original function
- calls the original function
- modify the returns value (optional)

The direct injection on a system DLL like NTdll.dll or kernel32.dll works after system start...
on booting it doesn't work...

Probably because they have a fixed loading area offset when system start.

Can someone find a way to inject them however?

I've a source of a sample program that inject a FAKE DLL (K32Hook!.dll)
on the Kernel32.dll that RE-CALL every API the Kernel32.dll
do to the NTDLL.dll...

You should have a Virtual PC to do these tests....

I'm making another K32Hooker because i think the precedent has a bug... ....

( Sometimes the Hooker Injection Module doesn't want to inject! )

I've created a little tool for network managing that operates in a
remote PC and execute all that i want... like a botnet...
(create, copy, erase, rename files or directory, ect...)
It works in the 27 network port.

You drive this program with a file called REMOTE CONTROLLER,
you connect it in the remote PC on the 27 port, send its instructions
and it executes all. (Digit HELP to get the commands list)
If you want to do a test, run the program and open the controller,
connect it in: 127.0.0.1 at 27 port and send to it some commands.

It can connect at least 65535 differents users and executes their commands.
Also it has a internal PRIVILEGE system for the users, and i'm
implementating a little CHAT function into...

This program IS NOT A VIRUS, infact you can close it with the QUIT
command or using the TASK-MANAGER and killing it.
(See the source code if you want)

I can't find a little BUG:
In all the SHOW-???? commands the MessageBox is inactive!
It doesn't work normally! Why?

Who can help me?

Yes, remote control can be very important in many situations, as long as the installation and runtime capabilities are known to the user of the machine. Virus would use tricks and fool users into running code and then typically hide and protect themselves to prevent removal.

For example if send the command from the controller to the program:

SHOW-MEX this is a test message+test capition

it executes the command and shows the Message Box with the text below,
but the message box is inactive and i can't press the OK button!

The same thing with the others SHOW function...
Maybe a USER32.dll incorrect handle use into the Dialog Box Param?