IDA PRO Static disassembly and ollydbg dynamic debugging combat Skills Summary



**********************************

case One: Use Ida Pro+ollydbg+peview to track the call procedure for Windows API dynamic link library functions.

First write a C + + source program named StackFrame.cpp with a text editor, the code is as follows:

1

<span style= ' font-family: "Microsoft Jas Black", "Microsoft Yahei";   font-size:20px > #include "stdio.h" <br><br> long Add (long A, long B) <br>{<br> long x = A, y = b;<br> return (x + y);<br>}<br><br> int main (int argc, char * argv[]) <br& Gt {<br> Long A = 1, b = 2;<br> <br> printf ("%d\n", add (A, b));<br><br> Retu RN 0;<br>}<br></span>

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 the Visual C + + compiler implements printf library functions, and whether StackFrame.exe uses static or dynamic linking, and if it is the latter, what Windows API functions in the dynamic link library are called by printf. or "movement" and use.

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 screenshots 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.

Whether the address belongs 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 404063-401000 = 3063, 3063 + = 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 given by ollydbg is accurate, as shown in the following screenshot:

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.

This article is from the "free, equal, sharing, mutual help" blog, please be sure to keep this source http://shayi1983.blog.51cto.com/4681835/1613615