Win32 API debugging experience (2)

The previous chapter explains how to use the debugging API to open a program to be debugged and provides a simple example. This chapter will explain in detail the content of the debugging message. similar to the message structure tmessage in message processing, the debugging event also has its own specific event structure, that is, tdebugevent. The tdebugevent is defined in Delphi as: tdebugevent = _ debug_event; _ debug_event = record dwdebugeventcode: DWORD; dwprocessid: DWORD; dwthreadid: DWORD; Case integer of 0: (exception: texceptiondebuginfo); 1: (createthread: Upload); 2: (createprocessinfo: tcreateprocessdebuginfo); 3: (exitthread: texitthreaddebuginfo); 4: (exitprocess: texitthreaddebuginfo); 5: (loaddll: Upload); 6: (unloaddll: Upload); 7: (debugstring: toutputdebugstringinfo); 8: (ripinfo: tripinfo); end; this structure is very complex and contains three basic types and data of a union type. dwprocessid and dwthreadid indicate the ID of the process and thread that generates the debugging event. dwdebugeventcode specifies the debugging event that is generated. The possible values are as follows (from <Win32 Assembler Programming>): 1. create_process_debug_event: the process is created. this event occurs when the debugging process has just been created (not yet running) or our program has just been bound to a running process with debugactiveprocess. this is the first event that our program should obtain. 2. exit_process_debug_event: this message is generated when the debugging process exits. 3. create_thead_debug_event: This event occurs when a new thread is created in the debugging process or our program is bound to a running process for the first time. note that this notification is not received when the main thread of the debugged process is created. 4. exit_thread_debug_event: the current event occurs when the thread in the debugging process exits. this notification is not received when the main thread of the debugging process exits. we can consider the main thread of the process to be debugged as a synonym for the process to be debugged. therefore, when our program sees the create_process_debug_event flag, it is the create_thread_debug_event flag for the main thread. 5. load_dll_debug_event: a DLL is loaded by the debugging process. when the PE Loader breaks down the link pointing to the DLL for the first time, we will receive this event. (When CreateProcess is called to mount the debugged process) and loadlibrary is called by the debugged process. 6. unload_dll_debug_event: This event occurs when a DLL is detached from the debugged process. 7. exception_debug_event: An exception occurred during the debugging process. the exception is actually a debugging interruption (INT 3 H ). to resume the process being debugged, use the dbg_continue flag to call the continuedebugevent function. do not use the dbg_exception_not_handled flag. Otherwise, the debugged process will refuse to run in NT (Win98 runs well ). 8. output_debug_string_event: This event occurs when the debug process calls the debugoutputstring function to send a message string to our program. 9. rip_event: system debugging error. depending on the dwdebugeventcode, call the corresponding structure in the Union to obtain the relevant debugging information. for example, we have a structure named debug tdebguevent. When we receive debugging information after waitfordebugevent (debug, infinite) is called, and the value of dwdebugeventcode is create_process_debug_event, we can run the DEBUG command. createprocessinfo. hprocess to obtain the process handle of the newly created debug process. the following describes the meanings of each structure that may be included in the tdebugevent structure. because there are no relevant details, most of the results are obtained through testing. please correct me if any errors or omissions exist. i. createprocessinfo structure: the corresponding debugging message create_process_debug_event.createprocessinfo.hfile: the EXE file of the debugging process is mapped to the memory file ing handle in the memory. You can open this handle (using openfilemapping and mapviewoffile) to read information about this EXE file. for example, import a table. createprocessinfo. hprocess: Process Handle Of The debugged process. If you want to use functions such as readprocessmemory and writeprocessmemory to modify the debugged process, you need to use this handle. You can save it as a variable for future use. createprocessinfo. hthread: main thread handle. createprocessinfo. lpbaseofimage: the executable file is loaded to the base address in the virtual address space. createprocessinfo. dwdebuginfofileoffset: the offset address of the debugging information in the executable file (usually 0, that is, there is no debugging information ). createprocessinfo. ndebuginfosize: the length of debugging information. createprocessinfo. lpthreadlocalbase: The base address of the main thread. createprocessinfo. lpstartaddress: the address of the main thread's thread function. createprocessinfo. lpimagename: file image name. Note that this is an RVA address (relative virtual address ). createprocessinfo. funicode: if this value is greater than 0, lpimagename points to the Unicode code. II. exitprocess structure: the corresponding debugging message exit_process_debug_event.exitprocess.dwexitcode: the exit code passed in when the debug program calls the exitprocess function. III. createthread structure: the corresponding debugging message create_thead_debug_event.createthread.hthread: the handle of the new thread. thread handle. If subsequent operations on the thread are involved, such as suspending the thread, you can use a tlist to save the process ID (tdebugevent. dwthreadid) and the corresponding handle. when other debugging events occur, obtain the thread Handle Based on the dwthreadid. createthread. lpthreadlocalbase: The base address of the new thread. createthread. lpstartaddress: Address of the thread function of the new thread. 4. exitthread structure: the corresponding debugging message exit_thread_debug_event.exitthread.dwexitcode: indicates the exit code passed in when the exit thread calls the exitthread function. 5. loaddll structure: the corresponding debugging message load_dll_debug_event.loaddll.hfile: The loaded DLL file is mapped to the memory file ing handle in the memory. You can open this handle to read the relevant information of this DLL file. loaddll. lpbaseofdll: The DLL file is loaded to the base address in the virtual address space. this address is the address of the function derived from the DLL file, which is the address of the function in the memory. loaddll. dwdebuginfofileoffset: the offset address of the debugging information in the DLL file. loaddll. ndebuginfosize: the length of debugging information. loaddll. lpimagename: the address of the DLL file name, which is an RVA location. loaddll. funicode: if this value is greater than 0, lpimagename points to the Unicode code. 6. unloaddll structure: the corresponding debugging message unload_dll_debug_event.unloaddll.lpbaseofdll: The base address of the uninstalled DLL file. You can save the DLL information and the corresponding base address in the load_dll_debug_event message to obtain the uninstalled DLL information. 7. exception structure: the corresponding debugging message exception_debug_event.exception.exceptionrecord: This is a texceptionrecord structure that contains information such as the interrupted or abnormal code generated by the debugging program, the interrupted or abnormal address. 8. debugstring structure: the corresponding debug message output_debug_string_event.debugstring.lpdebugstringdata: Address of the message string sent by the debug process by calling the debugoutputstring function. debugstring. ndebugstringlength: the length of the message string sent by the debugoutputstring function called by the debugging process. debugstring. funicode: If the value is greater than 0, the message string is a unicode code. 9. ripinfo structure: the corresponding debugging message rip_event.ripinfo.dwerror: error code. ripinfo. dwtype: Error type. with the above knowledge, we can monitor these debugging messages in the debugger and obtain information we are interested in. however, this only monitors the debugged programs. the next chapter describes how to modify the program to be debugged. appendix: an example of how to start, load, and exit a Monitoring Target Program, and demonstrate how to read the RVA address and obtain the loaded DLL file name. please download at the address below.

http://qxccccc.8u8.com/debug.rar