A solution to the problem of local variable address and direct running program for GDB dynamic debugging in Linux environment

The underlying buffer overflow practice usually needs to determine the address of some local variables in the running state of the program, such as the start address of the input buffer that needs to be determined to obtain the start address of the machine instruction in the injected buffer. In the Linux environment, the program can be dynamically debugged through GDB to obtain information under the program running state (close the ALSR mechanism), the underlying GDB operation can be found in the author's article Linux edit, compile, Debug command summary--gcc and GDB description. GDB is a convenient way to get the information in the dynamic state of the program, but information such as the starting address of the buffer obtained through GDB dynamic debugging may not be the same as the information that the program actually runs , which affects the effect of buffer overflow practice.

Problem description

The memory layout of a program running through GDB may be slightly different than the memory layout of a program running alone. Simple validation through the following instance program.

#include <stdio.h> int main (int argc, char *argv[], char *envp[]) { char buff[8];
printf ("address of the buff:%p \ n"
　　　　
return 0; }

After closing the ALSR mechanism, generate the executable hello via Gcc-m32-o hello-g-fno-stack-protector hello.c compilation. Run the executable program directly and get the starting address of the buffer to 0XFFFFCFA8.

　　

Using GDB to dynamically debug the Hello file, get the start address of the buffer as 0xffffcf88. You can see that there is a 32-byte gap between the two addresses.

When the normal program runs, an array of environment variable strings and command-line argument strings are placed at the top of the stack, and data such as the local variables used by the program are located behind these string arrays. An environment variable string array records environmental information such as the current user name, terminal type, search path, and so on. When the program runs directly, the program process inherits the environment variables that run its shell, and when the program runs through GDB, the program process inherits the GDB environment variable, which is different, which causes the address of the local variable on the stack to change. The user can run the show Environment command in GDB to get the environment variable parameters.

    Show Environment    // Get environment variables for current program running in GDB 

　　

The environment variable at the top of the stack has the following changes, compared to the direct operation of the program:

(1) _ The content of the environment variable changes , when the program runs directly, _ variables are stored in the program's execution path, while running the program through GDB, _ variables are stored in the GDB execution path.

When you run a program using GDB, the value of the environment variable is/usr/bin/gdb. When the program runs directly, the value of the environment variable should be the execution path of the program, such as./hello.

　　

(2) The debug program run by GDB inherits the GDB environment variable, which includes the newly added environment variables LINES and COLUMNS.

　　

(3) The parameter list on the stack may also be different when the user runs the program directly in the shell through./hello, the first item in the parameter array argv[0] content is "./hello", and when the user runs the Hello program through GDB, the first item of the program's parameter list argv[ 0] is the absolute path "/home/yh/hello" of the program, which also causes differences in local variable addresses when the program is run. It is recommended to use an absolute path to run the program in the terminal environment to avoid this difference.

　　

Feature Support

In order to solve the differences in the address of the program local variables resulting from the different environment variables, we need to do some operation before using GDB to run the program, GDB provides the following functions for user debugging.

(1) GDB provides commands to manipulate and modify the environment variables passed to the debugging process.

    Show paths        // Display the search path of the executable (that is, the contents of the path variable)    show environment [varname]    // show GDB when starting the debugger The value of the environment variable passed to it, when no specific variable name is specified, all environment variables are displayed, and Env is used as the shorthand set for environment    environment varname [= value]    ///// setting environment variables that are not passed to the debugger      　　　　　　　　

Users can use the unset env LINES and unset env COLUMNS commands to make the debug program stack without adding additional environment variables LINES and COLUMNS.

(2) The Linux platform provides the standard wrapper program env to set the environment variables that are ultimately passed to the program. The detailed usage of Env can be viewed through the man Env, whose simple parameters are as follows.

    env [Options] [-] [name=value] [command [args] ...]  
The command specifies the program that is started by Env, and when you do not specify a command, the environment specified by the current env is output, such as running Env directly, and the output is the options for all current environment variables:-I               / //// function Same as      -I

(3) GDB can run the debug program through the wrapper function. When the wrapper program is set, GDB starts the debugger in the form of the exec wrapper Hello Shell command hello,wrapper The program runs first and eventually starts the debugging process, which is then controlled by GDB. You can control the environment variables passed to the debugging process through the wrapper program.

    Set wrapper program for wrapper show      exec-wrapper    // show current wrapper program    // Cancel settings for wrapper program 　　　

You can use the standard wrapper program env to control the environment variables that are passed to the debug process.

Solution Solutions

With these features, you can solve the problem of changing the address of local variables when GDB runs the debugger with the following scenarios.

A. Do not pass an array of environment variables to the debugger.

(1) Run GDB through Env and set the environment variable passed to GDB to null. In this case, the environment variables contained in the GDB environment are only their newly added LINES and COLUMNS.

    Env-gdb/home/yh/hello    // Settings The environment variable passed to GDB is empty, note that the full pathname of the program to be debugged is used 

At this point, the list of environment variables in gdb displayed by show Env is as follows

　　　　　　

(2) through the GDB environment variable setting command unset env, set not to pass the above two environment variables to the debugger, so that the final run of the debugger, there will be no environment variables to be inherited by the debugger program.

    Env LINES     Env COLUMNS

After two steps, the address of the local variable for the debugger running through GDB is consistent with the address of the Hello program running through env-/home/yh/hello (both the process stack does not contain an array of environment variables, and argv[0] are absolute path addresses). when the program to be debugged needs to use the values of some environment variables, it is only necessary to specify the environment variables required by the ENV program , instead of introducing the different environment variables such as _.

　　

B. Based on the same principle, GDB can be started normally, but the wrapper program is set.

   GDB Hello // normal start gdb   env -    // set wrapper program in GDB to Env-
   
    r                      
    // 
    start debugging, the Hello program does not inherit any of GDB's environment variables with the functionality of the wrapper program set
   

The debugger does not inherit the GDB environment variable when running the program through GDB, so the address of the program local variable is the same as the local variable address of the Hello program that was launched by Env-/home/yh/hello.

Resources

1.Debugging with Gdb:environment

2.Debugging with Gdb:starting

3.Buffer Overflow works in gdb and not without it- Stack overflow

4. How topredict address space layout differences between real and gdb-controlled executions? -Stackexchange

A solution to the problem of local variable address and direct running program for GDB dynamic debugging in Linux environment