Back to the HCU Papers
Extending NuMega's SoftIce for Windows 95 using Protected Mode
Debugger services API
---------------------
by Iceman
As you all know very well Soft-Ice is the best debugger available on the market. A powerful tool which combined with IDA 3.7+ give you the power to reverse just about anything in this wrold.The idea of extending Soft-Ice is not new , I've seen many implementations of new commands (not so many , in fact) but no one used the mechanism of dot commands which I describe below.
This paper is accompanied by a sample skeleton VxD which implements an extension to Soft-Ice for Windows95.It provides no real functionality at this time , it is designed to illustrate how .dot commands are implememted.The source code is available , too.
You will need at least Windows95 DDK and MASM 6 to build the example VxD , Soft-Ice to see for your own eyes that it's works , IDA 3.7 comes handy to follow chapter 7.No more tools required , a basic knowledge of VxD programming still required.Chapter 6 and 7 are not directly related to dot commands , it is more an introduction to basic reverse engineering techniques for VxD's.Still, it is linked with the general subject , it show you how you can talk to SoftIce from ring3 user code.
The document is structured as below:
Chapter 1: VxD introduction.
Chapter 2: What are dot command's?
Chapter 3: INT 41h - protected mode debugger interface.
Chapter 4: Extending Soft-Ice
Chapter 5: The sample: icecmd.vxd
Chapter 6: Moving to ring 3
Chapter 7: How Numega's Loader works?
Chapter 8: Notes for Windows NT users.
Appendix A: Some useful equates for VxD reverse engineering
Appendix B: INT 22h - Win32 Protected mode interface requests API
Chapter 1: VxD introduction
---------------------------
Virtual device drivers , referred further as VxD , are basically 32 bit executables that
run at the highest privilege level (on ring0).They are used to manage critical system
resources.The executable type is not PE but the older type LE (linear executable).Their
importance becomes higher than Microsoft added to Windows95 the ability to dynamically load
VxD's.In the past , VxD where used almost only for virtualizing hardware devices or to control
hardware periphereals.In this days you can see lot of code who heavily relays on VxD to improve
execution speed , or to gain access to critical system resources.
Now , since the purpose of this material is not to be a VxD programming introductory
material I will jump directly to Chapter2.If you want me to write a introductory material to
VxD programming mail me directly and if I find the number of requests high enough i will write
one.(over 30 requests will do the job)
Chapter 2: What are dot commands?
----------------------------------
The protected mode debugger interface API under Windows 95 class OS provides a very
convenient way for 32 bit system DLL's and VxD to talk to a system debugger.In Windows95 this
interface is accessed via INT 41h.Between other things , INT 41h interface allow a VxD to
provide debug specific routines which can be called from the system level debugger's console.
In theory , any system level debugger can be extended in this way.Care must be taken
because not all the functions provided by INT 41h API are necessary implemented by your debugger.
SoftIce , as well as Microsoft's Wdeb386 supports them.Issueing a dot command is as simple as
breathing.In debugger's console type:
.Command
where command is the command that you want to be executed.By a more technical point of view
two types of dot commands are available.Let's see them:
A.Debug Query dot commands
Now fire up SoftIce and type:
.vmm
Instantly the command window shows you a menu with several debug options what are not
part of SoftIce but implemented through vmm.vxd (Virtual machine manager).What happened behind
our back?When you issue a .VxDname command a Debug_Query message will be sent to the specified
virtual device.If the ControlDispatch procedure of target VxD supports a handler for this
message control will be passed to it.The handler procedure for Debug_Query message must reside
in a looked code segment.If it is in pageable code-segment your system may hang if the handler
procedure is paged to disk.If the target VxD does not handle Debug_Query message nothing bad
happens , so you can experimentate this freely.
B.Registered dot commands
Fire up SoftIce again and type:
.my
(This command should be available even if you don't have the debug version of W95).You
are in reverse engineering business and still using a retail build of your OS? Belief me , you
miss a LOT of cool things.Get a debug build for at least vmm.vxd , vwin386.vxd , vxdldr.vxd ,
and ring3 kernel components.
What you see now on your screen is the valid ranges of physical memory.At this point
is important for us to know how the debugger called this code and not how to get valid
boundaries of physical memory.Things are a little more complicated now.Implementing a dot
command of this type impose a certain architecture to the server VxD.Be careful.Here the dot
command is .M and not .MY. The Y following .M is merely a parameter passed to handler for this
command.When the server VxD is initializing it's debug interface , usually but not necessary
inside the procedure that handles Device_Init message broadcasted by virtual machine manager,
it must call a function called RegisterDotCommand (INT 41h , AX=70h) to register the command in
question to the system debugger (see chapter 3 for details).Basically , registering a dot
command provides the system debugger with an entry point which will be called when that
command will be issued.To see which dot commands are registered in your system simply type
.?
This will show you all the dot commands available , in the order in which they where
registered.
Chapter 3: INT 41h - protected mode debugger interface.
-------------------------------------------------------
The Protected Mode Debugger Interface API is implemented via INT 41h.This interrupt
calls into the system debugger through a 32 bit interrupt gate , directing it to perform
various actions.The called function is identified by the value contained in AX register.
This interface is partial undocumented , you can find some useful things by reading the
debugsys.inc file that comes with Windows 95 DDK.In this file the API is documented at the
bare minimum , but it's better than nothing.Anyway , for those of you who don't posses the
DDK I will list below some of the most useful functions.
AX=00h -- Display character on debug terminal
entry :
AL = character to display
AX=01h -- Read character from debug terminal
returns:
AL = readed char
AX=02h -- Displays a string on debug terminal
entry:
DS:ESI pointer to null terminated string to display
AX=12h -- Displays a string on debug terminal (called by 16 bit code )
entry:
DS:SI pointer to null terminated string to display
AX=40h -- Run debugee until specified CS:IP is reached
entry :
CX = desired CS
BX = desires IP
AX=70h -- Register dot command (32 bit code )
entry:
BL = dot command to register
ESI = linear address of the handler routine
EDI = linear address of the help text
returns:
AX == 0 if successful
AX != 0 if registration failed
AX=71h -- Register dot command (called by 16 bit code )
entry:
BL = dot command to register
CX:SI = linear address of the handler routine
DX:DI = linear address of the help text
returns:
AX == 0 if successful
AX != 0 if registration failed
AX=72h -- Unregister dot command (unregister dot commands registered by both 70h & 71h)
entry:
BL = dot command to de-register
AX=73h -- Debug prinf ( C like printf function >> output on debugger terminal ) 32 bit
entry:
DS:ESI = address of format string
DS:EDI = address of first parameter passed ( all parameter are DWORD's )
returns:
EAX = nr. of characters printed on debug terminal
AX=74h -- Debug printf (C like printf function >> out on debugger terminal) 16 bit
entry:
DS:SI = address of format string
ES:DI = address of the start of the word or dword arguments
returns:
AX = nr of chars outputed
AX=75h -- Get Register Set
entry :
DS:ESI = address of a SaveRegs_Struc type structure
AX=76h -- Set Alternate Register Set
entry:
CX = thread ID (0 for current thread)
DS:ESI = address of a SaveRegs_Struc type structure
AX=77h -- Get Command Line Chararacter
entry:
BL = 0 -> get char , text pointer not incremented , leading space not ignored
= 1 -> get char , increment text pointer , leading blank is skipped
= 2 -? get char , text pointer not incremented ,leading blank is skipped
exit:
AL = command line character retrieved
AH = 0 if EOL encountered , !0 if more characters await parsing
AX=78h -- Evaluate Expression
entry:
ds:esi expression to evaluate
returns:
AX: -> 0, returns a data value
-> !0 returns a linear address
CX = TID
EBX = evaluated value
AX=79h -- Verify Memory
entry:
ECX = length of memory region
DS:ESI = starting address of memory to verify
returns:
AX: -> 0 OK
-> !0 memory range is invalid
AX=7A -- Directs debugger to dump current registers
AX=7b -- Directs debugger to perform a stack dump
entry:
BX: -> 01h - verbose stack dump
-> 02h - 16 bit stack dump
-> 04h - 32 bit stack dump
AX=7dh -- Execute Debugger Command
entry:
DS:ESI = pointer to the command script
CX = size in bytes of script
Some structures:
SaveRegs_Struc struc
Debug_EAX dd ?
Debug_EBX dd ?
Debug_ECX dd ?
Debug_EDX dd ?
Debug_ESP dd ?
Debug_EBP dd ?
Debug_ESI dd ?
Debug_EDI dd ?
Debug_ES dw ?
Debug_SS dw ?
Debug_DS dw ?
Debug_FS dw ?
Debug_GS dw ?
Debug_EIP dd ?
Debug_CS dw ?
dd ?
Debug_EFlags dd ?
Debug_CR0 dd ?
Debug_GDT dq ?
Debug_IDT dq ?
Debug_LDT dw ?
Debug_TR dw ?
Debug_CR2 dd ?
Debug_CR3 dd ?
Debug_DR0 dd ?
Debug_DR1 dd ?
Debug_DR2 dd ?
Debug_DR3 dd ?
Debug_DR6 dd ?
Debug_DR7 dd ?
Debug_DR7_2 dd ?
Debug_TR6 dd ?
Debug_TR7 dd ?
Debug_TrapNumber dw -1
Debug_ErrorCode dw 0
SaveRegs_Struc ends
There are more functions implemented through INT 41h.There is no point in list them
here because those are advanced things and are beyond the purpose of this paper who is
wanted to be a introductory and didactic material.If someone really wants them I suggest
browsing the DDK or directly e-mail me and I will try to help.
Chapter 4: Extending Soft-Ice
-----------------------------
In this chapter you will find some guidelines for writing helper VxD's for extending
Soft-Ice, or other system debuggers (Soft-Ice is the best tool , so don't bother with
other debuggers , does not worth the effort).You can develop those VxD's in assembly language
or in C/C++.If you choose to write them in C I recommend you buying Vtools from Vireo Software,
this is a great tool.It is not very hard to write them totally in assembly , so this is also
a good choice.
In the first place we will need a unique device id.This is not mandatory but in
the sample VxD who accompanies this article I've used this device ID to prevent loading the
VxD if it's already loaded (duplicate init strings in system.ini or registry).
The loading order is not very important as long as you not relay on third-party
VxD's to carry out part of your routines.The only VxD's required to be loaded before our
device are the VMM and the Debug Device.No special precautions required since vmm.vxd and debug
device have Init_Order equal to 0. This number means that the VMM will start loading VxD's
starting with lower values first and finishing with UNDEFINED_INIT_ORDER values last.So simply
specifying UNDEFINED_INIT_ORDER will be OK.
The next thing very important is the Virtual Device's control procedure.You should
always put this procedure in a locked code segment.This routine is a callback who responds
at messages broadcasted by Vmm and directs our VxD to take appropriate measures (generally this
routine merely pass control to user code procedures responsible with managing those messages.
Remember that returning with Carry Flag set from your handlers means that an error occurred ,
and a cleared Carry Flag means that everything went OK.A debug helper VxD should manage at
least two messages.They are Device_Init and Debug_Query.If your plan to write your VxD as a
Dynamic loadable device driver the control procedure is REQUIRED to manage more two messages.
Those are Sys_Dynamic_Device_Init and Sys_Dynamic_Device_Exit.Talking from ring3 user code
to your device is also possible (see Chapter7 for details).In this case I recommend you to use
the DEVICE_IO control mechanism.For this to be possible you must also process W32_DeviceIocontrol
message and write an appropriate handler to dispatch control to your procedures.Please note
that even if your VxD does not handle any messages , a control procedure is still required.
We already said that the Control Procedure must be in a looked code segment.Also
the procedures that handles Debug_Query events and .dot commands are required to be in looked
code segments.This is due to the way in which system debuggers pass control to those handlers.
Also when you build the VxD the debug level passed to MASM must be at least one.This is because
if you do a retail build on a VxD a lots of Debug Macros defined in Vmm.inc becomes unavailable.
Your code will compile and link without any problem , but you will notice that your Trace_Out
messages and other debug macros there stripped out.
If your device provide a handler for Debug_Query message , issuing a type one dot
command ( a dot followed by your VxD name ) will be automatic processed.You can strip this out
if you want , processing Debug_Query is not required.
To use type two dot commands you are required to inform the debugger about their
existence.The best place where you can do this is inside the handler for Device_Init message.
This handler can be safely put in a discardable code segment , so after completely initializing
the device and registering dots this code will be discarded (You never have enough RAM , so
even if you think that several Kb are not much ...).You always must try to keep pagelocked
code and data at the very minimum.
Before you try to register a dot command you should always check if a system debugger
is present.Issueing INT 41h without a system debugger installed cause protection faults.
If such a protection fault occurs inside a Device_Init message handler of a statically loaded
device , not only the device will not complete initialization but also Windows95 itself will
fail initialization.The simplest way to check for a debugger is to use Test_Debug_Installed
provided by vmm (VxdCall Test_Debug_Installed).This will return with zero flag clear if
a debugger is present.If ZF if set the a system level debugger is not present.
If the debugger is not present then you should not load your device.You simply
do this by returning with CF set from the Device_Init message , informing the virtual machine
manager that the initialization procedure failed . The VMM will not load the device.
Once you are sure that a debugger is present you can proceed with registering dot
commands . This is accomplished by INT 41h with Ax set to 70h.The other registers must be set
as following:
BL = dot command to register.Example mov bl , 'z'.Used to inform the debugger
that it should respond at a .Z command transferring control as below.
ESI must contain the linear address of the dot command handler routine.
EDI must contain the linear address of the help string.The help string must
end with a CR
The following special restriction apply to the handler:
1.The handler must stay on the same stack used when called Int41h
2.The handler must not change provided flat CS , DS , and try to access invalid
selectors or memory.
3.The handler is runned on ring0.
After you register the dot command you will can access it from within your debugger.
When you don't wont the command anymore you should de-register it.
If your VxD is statically loaded there is no point in de-registering dot command , since the
code will be there until Windows shuts down. But if your VxD is designed to be a dynamically
loaded VxD care must be take.If you unload the VxD and a de-register of the dot command is
not performed , the dot command will be considerated as available by debugger , and you can
call it.The only problem is that since the VxD who provide the handler is no longer in memory,
control will be passed to garbage instructions,...I think you get my point.So is a very good
idea to de-register dot commands in a dynamic VxD. De-registering is performed calling INT 41h
whit AX set to 72h and BL containing the command you want to de-register.Your best choice is
to this thing inside the handler for Sys_Dynamic_Device_Exit.
Also , while processing a dot or a Debug_Query message , it is not a good idea to
try to leave Soft-Ice by pressing the assigned hot-key.This will hang your machine imediatly.
Now several things about the dot command handler routine.When the debugger calls the
handler it will set DS and CS to a flat selector. Usually the flat CS will be 28h.It also
load the first character of the command line in the AL register.The handler routine must
perform a far return (you must return to the debugger which resides in another code segment).
Note that this is not sensed by assembler so it's your duty to explicitly use RETF.The value
returned in AX register can be 0 , indicating that all went OK , any other value means that
an error occurred (usualy a command line error).The first thing you should do after entering
your handler is to parse the command line. This can be accomplished by using INT 41h , AX=77h
(Get command line character) . A pointer to the current character in command line is
maintained by the debugger.The value specified in BL register choose how this pointer
is managed.Also the flag specified in BL sets the way in which one or more blank spaces are
treated.They can be ignored , the pointer value will be updated to the next valid character
in the command line or you can choose to parse them as well.The GetCommandLine function will
return with AH set to 0 if end of line was encountered , and a value !0 otherwise.The
command line character is retrieved in AL.
Not much things left to say.It's up to you in which way you will used the facilities
presented here.Your code runs on ring 0 , so you can do just about anything you imagine.The
only thing I want to say is that you should take care about what you are doing.Programming
in ring0 requires a very serious understanding of protection mechanism , page-mode memory
management , x86 internal architecture and the way in which Windows'95 virtual memory manager
manages those facilities.Remember , you have absolute power but using it in a wrong way can
cause your machine to hang , and you can cause loose of data from your hard drives.Fair warning!
Chapter 5: The sample: icecmd.vxd
---------------------------------
Accompanying this article there is a sample VxD who employees most of the techniques
described in the pervious chapter.The VxD does not provide any real functionality , it is
intended only for didactic purposes.It implements a new dot command .Z and a DebugQuery
handler routine.The sample dot command .Zs will dump the stack trace on the debug console.
You can accomplish same thing issuing STACK command in Soft-Ice.It also show you very
basic command line parsing.The VxD is implemented as a static VxD.It also present a mechanism
in which a VxD can detect if it was previously loaded , preventing multiple instances.Since
the code is commented I will not insist in presenting it once again inside the article.Read
the source code ,I tryed to keep things easy to understand.
The only thing unexplained is the code what prevents the VxD being loaded twice.
This code resides in VxD_REAL_INIT_SEG code segment.This code is auto called at the time when
the system is still in real mode and the Virtual Device Drivers are loaded.When the system
reach this entrypoint the BX register contain a value that indicates if the device is already
loaded or not.The method requires a unique device Id.To allow loading you must exit with
AX set to a certain value , as shown below.
Abort_Device_Load -- tells to VMM that this VxD should not be loaded
Abort_Win386_Load -- tells to VMM to end Windows loading (WIN 95 itself will
fail loading if this value is passed to AX
Device_Load_Ok -- tells to VMM that al is OK , device can be loaded
No_Fail_Message -- use with Abort_Device_Load and Abort_Device_Load.Instructs
the VMM to not display an error message.If not specified
the VMM will print an error message on screen.
Also , you must return with BX , EDX , SI registers set to the folowing values:
BX --- must contain a pointer to a null terminated page array table
containing the physical pages reserved for VxD own use.Valid adress
ranges are 0 to 100h. (That's it the table must reside in very low
memory.
MUST be set to 0 if no pages are reserved
SI -- must contain a pointer to a null terminated area of data items
MUST be set to 0 if there are no specific instance objects.
EDX -- contain a value who it is passed to the protected mode procedure
what is the handler for Sys_Critical_Init message broadcasted
by VMM.This value is re-loaded in EDX just before the protected mode
init procedure is called
Usualy set to 0 , but it will not harm anything if contain other
values. (This is because it's up to you if the handler for
Sys_Critical_Init will use it or no)
This is not my creation , ive learned this from W. Oney's code.
Download icecmd.zip & source code
Chapter 6: Moving to ring 3
---------------------------
Part of the Protected Mode Debug API is available also on ring3.In fact , some
functions from WIN32 API like OutputDebugString relays on INT 41h to carry out the job.
This opens more interesting possibilities , since you can write ring3 programs that
interacts with a system debugger , retrieving info from it and instructing it to carry
out various actions.
Note that not entire API is disponible on ring3.Generally, experimenting won't
harm as long as you are sure that a system debugger is installed.
Chapter 7: How Numega's Loader works?
-------------------------------------
Although this chapter is not directly related to extending system debuggers under
Windows95 ive decided to present it inside this document because it treats a very important
problem: Talking to VxD's from ring3.The basic problem is the question: How can I call the
code from a VxD and how do I retrieve data from it?Well , there are more than one method
to to this, but I will present only one.This method uses the DEVICE_IO_CONTROL mechanism
to talk to a VxD.It also provides a very convenient way to manipulate complex data structures
between ring3 and ring0.The only downside is that a certain architecture is imposed to the
VxD which will be called using this method.The device driver is required to process the
W32_DeviceIoControl message and to use a table of offsets to dispatch control to desired
procedures.
NuMega's loader uses this method to instruct SoftIce VxD to perform various actions.
The mechanism is implemented within nmtrans.dll. The executable is a simple shell for
an easy user interaction.Now let's see the API used to communicate in this way with a VxD
and then let's look how NuMega's loader use them.Three WIN32 API functions are used:
CreateFile , CloseHandle and DeviceIoControl.
I'm sure that all of you know very well CreateFile & CloseHandle so let's see
DeviceIoControl. The DeviceIoControl function sends a control code directly to a specified
device driver, causing the device to perform the specified operation.
BOOL DeviceIoControl(
HANDLE hDevice, // handle of the device
DWORD dwIoControlCode, // control code of operation to perform
LPVOID lpvInBuffer, // address of buffer for input data
DWORD cbInBuffer, // size of input buffer
LPVOID lpvOutBuffer, // address of output buffer
DWORD cbOutBuffer, // size of output buffer
LPDWORD lpcbBytesReturned, // address of actual bytes of output
LPOVERLAPPED lpoOverlapped // address of overlapped structure
);
DIOCParams STRUC
Internal1 DD ?
VMHandle DD ?
Internal2 DD ?
dwIoControlCode DD ?
lpvInBuffer DD ?
cbInBuffer DD ?
lpvOutBuffer DD ?
cbOutBuffer DD ?
lpcbBytesReturned DD ?
lpoOverlapped DD ?
hDevice DD ?
tagProcess DD ?
DIOCParams ENDS
Hope the structure is self-explanatory , tired of typing.Anyway it is used to pass and retrieve
data to the called VxD service,as well as passing desired code of operation.
How Numega use this functions? First CreateFile is called with LPCSTR lpszName parameter
set to " \\\\.\\SICE".If Softice VxD is loaded this call will return a handle to the virtual
device driver.After that DeviceIoControl is called with HANDLE hDevice set to the value
returned by previously called CreateFile and DWORD dwIoControlCode set to a integer value
which unique identifies what routine we want to be called from VxD.If the function succeeds
the return value is TRUE.
"\\\\.\\SICE" passed to CreateFile is the name of the virtual device we want to
open.You can figure out very easy this name , IDA gives it to you for any VxD.
When DeviceIoControl is called the system wraps to called VxD routine through a
standard Windows95 VxD called vwin32.vxd.A DEVICE_IO_CONTROL message is broadcasted to the
target VxD.In this moment esi register points to a DIOCParams type structure.The VxD code
is responsible to annalize the requested service code ( DWORD dwIoControlCode) and see if
it's a valid one. If it's valid , control is passed to the service routine witch must
return with carry flag cleared to indicate success. If the service code does not exist,
or an error occurs (insufficient nr. of parameters ...and so on ) we must return with
carry flag set to indicate an error.Finally , Close Handle is called to destroy the
handle.
Let's annalize , for example , how the command history is saved to a file (the first listing
is from nmtrans.dll , the second from winice.exe ver 3.22).
A simple quick view in nmtrans.dll shows some interesting names.Two of them are interesting
in our problem. They are DevIO_ConnectToSoftIce and DevIO_CopyLogInfo.Very suggestive names,
isn't it?When we want to save log info control is passed to DevIO_CopyLogInfo.
...............................!!!!SEVERAL LINES STRIPED OUT!!!................................
disasembly listing of nmtrans.dll
DevIO_CopyLogInfo
-------------------
10019999 call DevIO_ConnectToSoftICE // In fact this calls CreateFile
// to open a handle to VxD
1001999E mov [ebp+var_1C], eax
100199A1 cmp eax, 0FFFFFFFFh // If we don't have a valid handle
100199A4 jz short loc_100199EA // jump out of here
100199A6 push 0
100199A8 lea eax, [ebp+var_24]
100199AB push eax
100199AC push 1Ch
100199AE lea eax, [ebp+var_40]
100199B1 push eax
100199B2 push 0
100199B4 push 0
100199B6 push 9C406018h //Push control code of operation
//Remember this , it is a critical
//value.It decides what service
// will eventualy execute winice.
// See below!
100199BB mov eax, [ebp+var_1C]
100199BE push eax //Push the handle to winice VxD on stack
100199BF call ds:DeviceIoControl //Call DeviceIoControl
//At this point control will be passed to
//Soft-Ice VxD.
//Remember that the OS have to execute
// several auxiliary operations , you
// will not land directly in Winice!
100199C5 mov [ebp+var_20], eax
100199C8 lea esi, [ebp+var_40]
100199CB mov edi, ebx
100199CD mov ecx, 7
100199D2 repe movsd
100199D4 jmp short loc_100199EA
So we learned that the dll's call into SoftIce VxD through DeviceIoControl Win32 API
function.To figure out exactly what service will be called from target VxD we have to remember
several things about VxD architecture.First of all we must know that every VxD have a
ControlDispatch routine that receives mesages broadcasted by system.This control block identifies
the messages and call coresponding routines.When this proc. is entered eax contain message code.
Ida Pro 3.7 identifies very well this procedure,giving us a very good starting point.
00000096 Control_0 proc near ; DATA XREF: LCOD:0000055Ao
00000096 ; LCOD:0000407Co
00000096 call sub_7C8BB
0000009B cmp eax, 0 // case SYS_CRITICAL_INIT
0000009E jz loc_93E
000000A4 cmp eax, 1 // case DEVICE_INIT
000000A7 jz short loc_D8
000000A9 cmp eax, 2 // case INIT_COMPLETE
000000AC jz loc_BDC
000000B2 cmp eax, 6 // case SYS_CRITICAL_EXIT
000000B5
000000B5 loc_B5: ; DATA XREF: LCOD:000B4640o
000000B5 jz loc_BDE
000000BB cmp eax, 23h ; '#' // case W32_DEVICEIOCONTROL
//
// Using DeviceIoControl for talking
// to VxD requires that this message
// is processed!
000000BE jz loc_5FD // than jump to this location
000000C4 cmp eax, 0Fh // case SET_DEVICE_FOCUS
000000C7 jz loc_15F
000000CD cmp eax, 0Ch // case DESTROY_VM
000000D0 jz loc_19B
000000D6 clc
000000D7 retn
The control is passed to the handler for W32_DeviceIocontrol message (loc_5FD in this case).
000005FD loc_5FD: ; CODE XREF: Control_0+28
000005FD push ebx //
000005FE push esi //Save those registers
000005FF push edi //
00000600 push 10h // EnterMutex param2
00000602 push ds:dword_40BF // EnterMutex param1
00000608 VMMcall _EnterMutex // Create a mutex to ensure that only
// one thread will acces this code at
// a given time
0000060E add esp, 8 // restore stack as at 5ff
00000611 push esi // save esi
00000612 mov esi, offset dword_40C3 // pointer to an Exception_Handler_Struc
// in this struct are defined the
// type of handler and memory range
// what is guarded
00000617 VMMcall Install_Exception_Handler // install a ring0 exception handler
// if something goes wrong we can
// trap the problem
0000061D pop esi // restore the esi
// esi contain a pointer to a DIOCparams
// struct (All info you pass to ring3
// DeviceIOControl + some not very
// important things for us
0000061E call sub_4B4F5 // ??? unexplored by me
00000623 mov ds:dword_40B7, 1
0000062D push 1
0000062F call sub_8595C // ??? unexplored by me
00000634 push eax
00000635 mov ds:dword_40BB, esp
0000063B mov dword ptr [esi+20h], 0 // set number of bytes returned
// may be modified by the requested
// service
00000642 mov ecx, [esi+0Ch] //load in eax dwIoControlCode
//from DIOCParams.dwIoControlCode
00000645 mov edx, ecx
00000647 shr edx, 10h
0000064A cmp edx, 9C40h // check for validity and reduction
00000650 jnz short loc_672
00000652 mov edx, ecx
00000654 shr edx, 2
00000657 and edx, 0FFFh
0000065D cmp edx, 800h
00000663 jl loc_8BD
00000669 sub edx, 800h
0000066F inc edx
00000670 mov ecx, edx // end check for validity and reduction
// load basic service code in ecx
// maximum value for a valid request
// will be 0xB
00000672
00000672 loc_672: ; CODE XREF: LCOD:00000650
00000672 inc ecx // services are 0 based so increment
00000673 cmp ecx, 0Ch // is service available?
00000679 jnb loc_8BD // if no , Get Out of here!
0000067F jmp ds:off_7584[ecx*4] //else jump to the requested routine
// it's address is stored in a DWORD
// array begining in this case at
// off_7584
// The mutex object is removed elsewhere in the code as well as the exception handler
// Not listed here because it's unimportant for our problem
Remember the control code of operation passed to DeviceIoControl?.This is the moment
then it becomes crucial.As already told , at this moment the ESI register points to
a DIOCParams type structure.This structure contains all info passed to DeviceIoControl.
Now if you watch the code above you will notice that from 0x635 to 0x672 a reduction
of this value to a much smaller one is performed.In fact , the maximum value contained
in ecx at this step is OxB , which BTW is the number of services that SoftIce expose
through this interface. ( in fact , the maximum number of services is 0xC ,but this
contains the default DIOC_GETVERSION service).
At location 673 the code looks if this service is in range (in SICE are implemented 0x0c
services what can be called using this method).If it determines that it's a valid service ,
the code jumps to the start adress of requested service. This adress is stored in a table ,
in our case at ds:off_7584.
00007584 off_7584 dd offset off_686 // if ecx = 0
00007588 dd offset off_68B // if ecx = 1
0000758C dd offset loc_690 // if ecx = 2
00007590 dd offset loc_6E8 // if ecx = 3
00007594 dd offset loc_71C // if ecx = 4
00007598 dd offset loc_7F6 // if ecx = 5
0000759C dd offset loc_825 // if ecx = 6
000075A0 dd offset loc_75C // if ecx = 7
000075A4 dd offset loc_78B // if ecx = 8
000075A8 dd offset loc_7BA // if ecx = 9
000075AC dd offset loc_8B6 // if ecx = A
000075B0 dd offset loc_85D // if ecx = B
ECX == 0 coresponds to a default DIOC_GETVERSION service .All others values between 0x1 and 0xb
at VxD services called by one of the folowing functions:
DevIO_ConnectToSoftICE (00019490)
DevIO_CopyLogInfo (00019940)
DevIO_LoadExports (00019760)
DevIO_LoadNm32SymbolTable (00019630)
DevIO_Nm32QueryTableInfoFirst (00019C50)
DevIO_Nm32QueryTableInfoNext (00019D60)
DevIO_Nm32QueryTables (00019B40)
DevIO_Nm32RemoveSymbolTable (00019E40)
DevIO_Nm32TranslateError (000194F0)
DevIO_Nm32VersionInfo (00019840)
DevIO_SetWLDRBreak (00019A30)
All this functions exported by nmtrans.dll use the same mechanism.Of course , operation
codes ar different , as well as the data passed and retrieved.
Looking at this table we have a clear picture of the starting adress of the VxD routines
what are called from ring3.Pretty interesting , isn't it? And we can call them any time
now , once we figured what code of operation coresponds to it.
Note : al C++ style comments in the listing there are NOT auto generated by IDA.
Chapter 8: Notes for Windows NT users
-------------------------------------
Windows NT does not support the dot commands interface.Anyway , there is a potential
method to extend kernel mode debuggers under NT through so-called bang commands.At least
Microsoft's Windeb can be extended in this way , I know nothing about NTICE at this time.
The method involves building some strange dynamic link libraries and them register
them from debugger's console.If NTICE supports this interface than we have a gold mine
because programing this kind of dll's is not so restrictive as programming VxD's and we
have much more "high level" exposed by Windows NT native API and ntoskernel.exe
Worth a investigation !
Appendix A: Some useful equates for VxD reverse engineering
-----------------------------------------------------------
SYS_CRITICAL_INIT 0000H
DEVICE_INIT 0001H
INIT_COMPLETE 0002H
SYS_VM_INIT 0003H
SYS_VM_TERMINATE 0004H
SYSTEM_EXIT 0005H
SYS_CRITICAL_EXIT 0006H
CREATE_VM 0007H
VM_CRITICAL_INIT 0008H
VM_INIT EQU 0009H
VM_TERMINATE 000AH
VM_NOT_EXECUTEABLE 000BH
DESTROY_VM 000CH
VM_SUSPEND 000DH
VM_RESUME 000EH
SET_DEVICE_FOCUS 000FH
BEGIN_MESSAGE_MODE 0010H
END_MESSAGE_MODE 0011H
REBOOT_PROCESSOR 0012H
QUERY_DESTROY 0013H
DEBUG_QUERY 0014H
BEGIN_PM_APP 0015H
END_PM_APP 0016H
DEVICE_REBOOT_NOTIFY 0017H
CRIT_REBOOT_NOTIFY 0018H
CLOSE_VM_NOTIFY 0019H
POWER_EVENT 001AH
SYS_DYNAMIC_DEVICE_INIT 001BH
SYS_DYNAMIC_DEVICE_EXIT 001CH
CREATE_THREAD 001DH
THREAD_INIT 001EH
TERMINATE_THREAD 001FH
THREAD_Not_Executeable 0020H
DESTROY_THREAD 0021H
PNP_NEW_DEVNODE 0022H
W32_DEVICEIOCONTROL 0023H
Appendix B: INT 22h - Win32 Protected mode interface requests API
-----------------------------------------------------------------
Int this appendix you will find some useful functions that Windows expose through INT 22h.You
can use this to gather data about diferent kernel objects, or to perform Win32 specific debug
operations.
AX=02h -- Converts a physical address to a linear address in curent context
entry:
ECX=phisycal address
returns:
ESI=linear address
AX= 1 if success , otherwise 0
AX=07h -- Check to see if an address is within a VxD object
entry:
DS:ESI = buffer to receive object name
BX = thread number
EDX = linear address to query
returns:
If EAX == 0, EDX = base address of object
If EAX != 0, error
AX=08h -- Get PDE for a specific context
entry:
BX = thread number
EDX = linear address
returns:
if EAX == 0, ECX = PDE
if EAX != 0, error
AX=0Ah -- Get LDT base
entry:
BX = thread number
returns:
if EAX == 0
EDI = pointer to LDT
ECX = LDT limit
if EAX != 0, error
Credits (in alphabetic order)
-----------------------------
This time credits go to:
fravia+, (aot) for hosting my documents :-)
+Mammon, for being a main +HCU backbone
Stone, United Cracking Force 98, (aot) for knowledge
+Undertaker, for
AfterDeath
To all others of you who asked my challenging questions , or gave useful idees,
directly or in wonderful electronic disscussions.
Final notes
-----------
This document is providing " as is " whithout any warranties.It expose some potentialy
dangerous techniques.Incorect use of the interfaces presented may harm the OS integrity , causing
loose of data.Nor I , or fravia+, or any other Web_masters who may host this document and attached
source code can be held responsable for anything this info or code do to you or your's machine.
The present document may not be modified whithout my express permission.Slightly editing
for correcting typos may be done in place , whithout permission from me.
Note that:
Masm 6 and Windows 95 DDK are trademarks of Microsoft Corporation
IDA is a trademark of Data Rescue company
SoftIce is a trademark of NuMega Technologies
You can contact me at ice_man81@hotmail.com".Feedback is always apreciated.