[Principle Analysis] Stack overflow case analysis under Linux-gdb Debug Drills-Enhanced Edition

Summary:

Original version:http://blog.csdn.net/bigbug_zju/article/details/39892129

In the original version of the problem is mainly in the debugging process, the traces of brute force is too heavy, does not well reflect the common debugging guidelines; This article is based on the original version of Incorporating the references to the Debug principle, re-examine and practice the problem, Want to try to reflect the usual rules of thought in debugging.

Platform for testing:
1. Ubuntu 9;   GCC 4.4.1; Gdb 7.0-ubuntu
2. The Ubuntu system is installed on virtual box 3.2.8 VMS;

Restatement of the problem:

Here is a brief description of the original problem, detailed view of the original, we would like to use StackOverflow aaaabbbbccccddddeeee The value of eeee in the StackOverflow overflow to the return address of the main function, and when the call overflow returns to the main function, controls EIP, the value of which is 0x63636363; but the problem in the actual process is that the value of EIP is not the 0x63636363 of imagination, but 0x61616161;

Why?

Debugging process:

Debugging Principle 1: To see, not to think;

at first, we could not assume that the problem was in the process of overflow returning to main (since there was a problem, the system's behavior It's a big difference from what you think, and it's not surprising where the problem happened . and should actually be run under one step look and see Where exactly is the problem? by setting breakpoints and stepping, we find that the control of the EIP does not appear in the process of overflow returning to main, but rather the main function exits.

Process

Debugging Principle 2: Understanding the System

according to the calling procedure of the function, the next sentence address of the current main function is stacked before call. after entering the function, first execute: Push EBP; mov ebp, esp;

exit Function, MOV esp, EBP; pop ebp. Finally, when the RET instruction is called, the next address that the call instruction presses into is popped into the EIP. Depending on the system model described above, the branches you might want to see are:

1. The address returned by the main function is modified (that is, the address at which the function is pressed when call main), that is, the content of the return address that the ESP points to is changed;

2. Also, the contents of the return address are unchanged, and the return address that the ESP points to is changed;

Debugging principle 3: First to exclude easy to verify the branch;

Debugging principle 4: Abnormal situation compared with normal situation;

The above two debugging branches, the exclusion of the degree of difficulty similar, we randomly choose 1 to start.

.... to is done.

Reference documents:

Debug Nine method: The troubleshooting of hardware and software errors, David J. Agans, Zhaoli, People's post and telecommunications publishing house.

[Analysis of stack Overflow case Analysis]linux-gdb debug Drills-Enhanced Edition