Using Ida Pro+ollydbg+peview to track the call procedure for Windows API dynamic link library functions

http://bbs.pediy.com/showthread.php?p=1354999

Title:"Original" uses Ida Pro+ollydbg+peview to track the call procedure for Windows API dynamic link library functions. Author: Shayi Time: 2015-02-12,05:19:54 Links: http://bbs.pediy.com/showthread.php?t=197829 use Ida Pro+ollydbg+peview to track the call procedure for Windows API dynamic link library functions. (This article is updated to my 51blog, I was originally published there, because the reference to the image, so with a watermark, the original source of the post is as follows: http://shayi1983.blog.51cto.com/4681835/1613615 ） First write a C + + source program named StackFrame.cpp with a text editor, the code is as follows: Code: #include "stdio.h" long add(long a, long b) {     long x = a, y = b;     return (x + y); } int main(int argc, char* argv[]) {     long a = 1, b = 2;          printf("%d\n", add(a, b));     return 0; } Use the Visual C + + IDE to compile, assemble, and link a series of operations to the source file, resulting in the resulting binary executable (PE format) named StackFrame.exe Recalling the above source code, the main function called the standard C library function printf printing information, we want to know, How does the Visual C + + compiler implement printf library functions, and does StackFrame.exe use static or dynamic linking, and if it is the latter, which Windows API functions in the dynamic link library are called by printf? Or is it a "movement" for both? To answer these questions, first use Ida Pro to open StackFrame.exe, which automatically looks for the program entry point, which is the startup code generated automatically by the compiler to initialize the environment we wrote before the main function executes, and to perform the finishing touches after the main function exits. In general, IDA Pro can easily identify the program entry point and main function, as long as the disassembled object is not shell-or-insert, and in order to simplify the parsing process, we go directly to the disassembly code snippet of the main function, as follows: We can see from the above series of IDA Pro that the call instruction at address 0x00404063 wants to invoke the EnterCriticalSection function, and the address of the latter attempt is given by the number of calls 0x0040a018, but the value at this address That is, the final address of the EnterCriticalSection function, which needs to be determined by the operating system loader to load the StackFrame.exe file, we cannot determine the address of the function in the dynamic link library when we disassemble the file on disk. Below is the Peview tool to see the "real" look of StackFrame.exe on disk (not the runtime address space of the IDA PRO "simulation") The reason to use the Peview tool first is because in the later dynamic debugging, it is compared with the information here, to deepen the understanding of the program on disk and in memory similarities and differences. Using the Peview tool to open StackFrame.exe, our focus is to locate the import table in the PE file, because both the operating system loader, the disassembler, and the dynamic debugger rely on the table to parse the imported dynamic-link library with its functions. We tried to calculate and find the byte sequence corresponding to the call ds:entercriticalsection instruction in the original PE file, which is not difficult to imagine, and the reason for the calculation method here is that The same computational technique is used to determine the actual address of the EnterCriticalSection function traced to the ollydbg. Does the address belong to Kernel32.dll or Ntdll.dll? (because sometimes the information given by ollydbg is not very accurate), the following calculation method will be used. First, go back to Ida PRO and open the StackFrame.exe Program Segment window as follows: As noted earlier, the call instruction at address 0x00404063 wants to invoke the EnterCriticalSection function, so the calculation is 404063-401000 = 3063, 3063 + 400 = 3463 3463 This value is the location of the instruction bytecode at StackFrame.exe, which is verified below: Next, using ollydbg to open StackFrame.exe for dynamic debugging, our goal is to locate the EnterCriticalSection function at the entrance, and step through, look at the machine code in it, and then use the Peview tool to calculate the above method, Verify that the dynamic-link library file information that the function belongs to is accurate as shown in ollydbg, as follows: This verifies that the shared library function called by StackFrame.exe at run time is consistent with the behavior that it describes in the import table on the disk file. Finally, we verify that entercriticalsection this Windows API letter is indeed located in Ntdll.dll, the dynamic link library, as the end of this case. First, you can visit the Microsoft MSDN site to find information about the EnterCriticalSection function: https://msdn.microsoft.com/zh-cn/library/windows/desktop/ms682608 (v=vs.85). aspx Finally, summarize: Stack.exe uses "partial" static links, where most of the code is library code, This includes the code that was added by the compiler library, the startup code for the handler initialization, and the end of the program exit. and the code for functions called in the program, such as printf. Because the printf function needs to print information on the screen, involving more underlying system I/O operations, it needs to invoke the Windows API functions that encapsulate these system functions, In addition to the DLL (Kernel32.dll,ntdll.dll) where the Windows API functions are loaded as a dynamic-link library at run time, The binary target code for all other called functions is copied by the linker and then linked to the final executable file, Stack.exe. As a result, Stack.exe contains far more library code than the programmer has written for itself. Using statically linked programs, it is easy to identify them through the global function call topology diagram of Ida Pro, as follows: The above is just a point, similar to the Ida Pro,ollydbg,peview, and even Winhex,peid and other tools combined application, cross-validation examples abound, through the skilled use of these tools, not only to improve the efficiency and accuracy of reverse engineering, more importantly, Our understanding of the system's underlying mechanism, such as the processor instruction set architecture, operating system memory management, and dynamic linkage mechanism, compiler, linker operation principle, etc., has also improved a notch. Finally, limited to the level of personal knowledge, if there are errors and misleading in the text, please also make corrections, greatly appreciated. Have any questions, views, and also welcome the discussion. * Reprint Please specify from the Snow forum @pediy.com

This post was Shayi last edited by 2015-02-12 16:03:59 [Announcement] If you think someone is language provocative, please click the "Report" button in the top right corner of each post!

Total 8 Members Thanks to Shayi's article:

Dolphinzhu (2015-03-03), HBCLD (2015-02-27), Hrpirip (2015-02-26), Lnairan (2015-02-25), SPRINGKANG[DFCG (2015-03-14), Learn GG (2015-02-23), Snow Sweater (2015-03-04), Malay (2015-06-07)

Lihuakx Junior Members Information:Registration date: Feb 2015 posts: 1 Essence: 0 Cash: The number of acknowledgements: 0 Thanks article number: 0 Number of members appreciated: 0	2 2015-02-12, 07:31:13 It's very clearly written.
	[Admissions]15PB software security training begins to accept the NO. 009 phase of Enrollment (10.06 classes)!

Shayi General Membership Information:Registration Date: Jul 2012 Posts: 99 Elite: 1 Cash: The number of acknowledgements of KX: 0 Thanks article number: 7 Number of members appreciated: 28	3 2015-02-14, 00:05:54 To add, before looking at most of the programs that use static linking, the entire function's call topology is very messy, and we can't even find the main function and the final DLL function entry Here's a recursive call graph for functions from IDA PRO that narrows it down to the entire process we traced from main () to EnterCriticalSection (), validating the previous lookup work in the StackFrame Code section:
	This post was Shayi last edited by 2015-02-14 00:16:50 [Admissions]15PB software security training begins to accept the NO. 009 phase of Enrollment (10.06 classes)!

Shayi General Membership Information:Registration Date: Jul 2012 Posts: 99 Elite: 1 Cash: The number of acknowledgements of KX: 0 Thanks article number: 7 Number of members appreciated: 28

4 2015-02-14, 00:20:10 The following figure is the function call setting for the build:

Using Ida Pro+ollydbg+peview to track the call procedure for Windows API dynamic link library functions