After reading the << Programmer >> Journal 2001, "Write the Win32 API Hook" article, how to insert the DLL into the five methods summed in other process address spaces, and generate great Interest, especially for the author, the best, but also the fifth way. Through the study, this fifth method is found, that is, uses CreateProcess, WaitFordeBugevent, WriteProcessMemory, LoadLibrary, etc. Inject DLL into the monitored space, which is the "Windows 95 System Programming Secret" Chapter 10 of Matt Pietrek. usage instructions. Read the Tenth chapter of the book, can't help but appreciate the unique brilliance of the technology elaborated by Matt Pietrek. Although the book is very old, its EXE execution procedure and DLL in the floppy disk can still be operated normally in Windows 98, Windows NT4.0. The shortcomings of the United States are the examples of the examples of the book all consisting of C processes and assembly files. Compiling in VC 6.0 However, the reason is that one of the assembly files asmretrn.asm does not know how to compile in VC 6.0. To solve this problem, I have tried the following methods:
1) Use the assembly compiler Masm611 to link AsmRetrn.asm to the .Obj file and link it to other files. Although I can solve the problem, I always feel that it is inconvenient, so I tried to overwrite the asmretrn.asm file into a C file (other files have all been changed to C files). 2) Rewrive the asmretrn.asm file into C file I use the assembly statement in the asmretrn.asm file in the _ASM keyword:
Void asmcommonreturnpoint (void) {_ asm sub eSP, 4; make space for return address_asm pushad ...}
And change asmretrn.asm to Asmretrn.cpp, then compile, although compilation is successful, but the operation failed. After DEBUG and track assembly code, it is found that the C compiler has added the leading and suffix code for protecting the recovery register at the beginning and end of each function. Due to these additional code, the assembler of the original precise control stack is no longer accurate, so the program runs failed. I think maybe this is the reason why Matt Pietrek did not use C. See the original text, Matt Pietrek said in the article "When I write APISPY32, I want to use C. I can't control it, in order to return the stack to us in order to return, I can't write a clear control. C program. ... ". Although the rewriting has been difficult, I have not stopped. After unremitting efforts I found out that the method of solving this difficult: Using the _Declspec (Naked) Declaration. _Declspec (naked) is Microsoft's expansion of C language. The compiler can be suppressed to generate a leading and suffix code (The Compiler Generates Code Without ProLog and Epilog Code.) Has been rewritten:
_Declspec (Naked) Void asmcommonReturnPoint (void) {_ asm sub eSP, 4; make space for return address_asm pushad ...}
Asmretrn.asm changes to the asmretrn.cpp file under precise maintenance of the original function and runs success. At this time, I have transplanted the original program to the VC 60 environment.
Further test, I found that when the tracking target program is normal, the program is running normally. But the tracking target program is a release version, our tracker cannot block the Windows API function call of the target program, which is a serious bug! After many debugging, I finally found the reason. It turns out that in some Release version, the ".IDATA" section (IAT) ".idata" section and other section of the Function Import Table (IAT) are used, and the page properties of the page after the merged data are stored. So when we try to overwrite the function addresses in IAT to our own Stub function, the page access error occurs. I know the reason, the modification is relatively easy. Simply replace the page property of the storage function import table (IAT) ".IDATA" section to be written, replace the function address in the IAT table, restore the page attribute. OK, you can now track the Release version target program. Now there is a multi-platform test. Window 9x, Windows Me, Window NT40 runs normally, but the running of Windows 2000 failed. The reason is that the DLL cannot be injected into the target program. why? It seems to be a problem with LoadLibrary () when it is injected into the DLL, and this issue is now in research. I hope to intercept the technology of Windows API, especially for Matt Pietrek's << Windows 95 System Programming Secret >> The technique used in Chapter 10, can give me some clues guidance, this is also what I wrote One of the purposes of the article. Here, thank all friends, masters, masters that can help me, master, and master. At the same time, I hope to learn skills with more users, interoperability.
Welcome to my m-mail: hanjin@pecan.com.cn.
