Compilation Tutorial: Win32 Debugging API (2)

We continue to Win32 the topic of debugging APIs. In this chapter, we will learn how to modify the debugger.

Theory:

In the previous chapter, we learned how to load the process being debugged and how to handle events that occurred in the process. For practical purposes, our program should have the ability to modify the program being debugged. There are several API functions for this purpose.

ReadProcessMemory This function allows you to read the memory of the specified process. The function prototype is as follows:

ReadProcessMemory Proto Hprocess:dword, Lpbaseaddress:dword, Lpbuffer:dword, Nsize:dword, LpNumberOfBytesRead:DWORD

Hprocess the handle of the process to be read.

Lpbaseaddress the memory start address to be read in the target process. For example, if you want to read 4 bytes from address 401000h in the target process, the parameter value should be set to 401000h.

Lpbuffer Receive buffer Address

Nsize the number of bytes you want to read.

Lpnumberofbytesread the variable address that records the number of bytes actually read. If you don't care about this value, fill in the null.

WriteProcessMemory is a function corresponding to the readprocessmemory that can write the memory of the target process. The parameters are the same as the readprocessmemory.

Understanding the next two functions requires some background knowledge of the process context. In a multitasking operating system like windows, several programs may run at the same time. Windows assigns a time slice to each thread, and when the time slice is finished, Windows freezes the current thread and switches to the next thread with the highest priority. Before switching, Windows saves the contents of the current process's registers so that when the thread resumes running again, Windows can restore the last thread-running * environment *. The contents of a saved register are always referred to as the process context.

Now back to our subject. When a debug event occurs, Windows pauses the process from being debugged and saves its process context. Because the process is paused, we can be sure that its process context content will remain unchanged. You can use GetThreadContext to get process context content, and you can also use GetThreadContext to modify process context content.
These two functions are powerful. With them, you have the ability to have a VxD in the process of being debugged: changing the contents of its registers, which will be written back to the register before the debugger resumes running. Any changes made in the context of the process will be reflected in the program being debugged. Imagine: You can even change the contents of the EIP register so that you can get the program to run anywhere you want! Under normal circumstances it is impossible to do this.

GetThreadContext Proto Hthread:dword, Lpcontext:dword

Hthread you want to get the thread handle of the context

The structure pointer used to hold the context content when the Lpcontext function returns successfully.

The SetThreadContext parameter is the same. Let's look at the structure of the context:

Context STRUCT
Contextflags DD?
;----------------------------------------------------------------------------------------------------------
; When Contextflags contains Context_debug_registers, return to this section
;-----------------------------------------------------------------------------------------------------------
IDR0 DD?
IDR1 DD?
IDR2 DD?
IDR3 DD?
IDR6 DD?
IDR7 DD?
;----------------------------------------------------------------------------------------------------------
; When Contextflags contains Context_floating_point, return to this section
;-----------------------------------------------------------------------------------------------------------
Floatsave Floating_save_area <>
;----------------------------------------------------------------------------------------------------------
; When Contextflags contains context_segments, return to this section
;-----------------------------------------------------------------------------------------------------------
Reggs DD?
REGFS DD?
Reges DD?
REGDS DD?
;----------------------------------------------------------------------------------------------------------
; When Contextflags contains Context_integer, return to this section
;-----------------------------------------------------------------------------------------------------------
Regedi DD?
Regesi DD?
REGEBX DD?
Regedx DD?
REGECX DD?
REGEAX DD?
;----------------------------------------------------------------------------------------------------------
; When Contextflags contains Context_control, return to this section
;-----------------------------------------------------------------------------------------------------------
REGEBP DD?
REGEIP DD?
Regcs DD?
Regflag DD?
REGESP DD?
REGSS DD?
;----------------------------------------------------------------------------------------------------------
; When Contextflags contains Context_extended_registers, return to this section
;-----------------------------------------------------------------------------------------------------------
Extendedregisters db maximum_supported_extension dup (?) Context ENDS
As you can see, the members of the structure are imitations of the registers of the actual processors. Specify which register groups are used to read and write in Contextflags before using this structure. To access all the registers, you can set Contextflags as Context_full. or only visit regebp, Regeip, Regcs, Regflag, Regesp or REGSS, contextflags as Context_control.

Also remember when using the structure context: it must be two-word aligned, otherwise it will get strange results under NT. You can add "align DWORD" before the definition. For example:

Align DWORD
Mycontext Context <>