HowTo: Hack into any Executable using GDB

GDB, the GNU Project debugger, allows you to see

`inside’ another program while it executes
what another program was doing at the moment it crashed.


GDB can do four main kinds of things (plus other things in support of these)
to help you catch bugs in the act:

  • Start your program, specifying anything that might affect its behavior.
  • Make your program stop on specified conditions.
  • Examine what has happened, when your program has stopped.
  • Change things in your program, so you can experiment with correcting the effects of one bug and go on to learn about another.

The program being debugged can be written in ADA, C, C++, Objective-C, Pascal (and many other languages). Those programs might be executing on the same machine as GDB (native) or on another machine (remote). GDB can run on most popular UNIX and Microsoft Windows variants.


Now, Lets Hack into the following program and
figure out why it causes a segmentation fault.

The program is meant to read in a line of text from the user and print it. However, we will see that in it’s current state it doesn’t work as expected…

File: segfault.c

1 : #include <stdio.h>
2 : #include <stdlib.h>

3 : int main(int argc, char **argv)
4 : {
5 : char *buf;
6 :
7 : buf = malloc(1<<31);
8 :
9 : fgets(buf, 1024, stdin);
10: printf(“%s\n”, buf);
12: return 1;
13: }

The first step is to compile the program with debugging flags. If compiled normally, then GDB will NOT be able to show the exact line no.s during Debugging. Hence the -g flag :

prompt> gcc -g segfault.c

Now we  fire up gdb:

prompt > gdb a.out
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type “show copying” to see the conditions.
There is absolutely no warranty for GDB. Type “show warranty” for details.
This GDB was configured as “i686-pc-linux-gnu”…

We’ll just run it and see what happens:

(gdb) run
Starting program: /home/dgawd/cpsc/363/a.out
test string

Program received signal SIGSEGV, Segmentation fault.
0x4007fc13 in _IO_getline_info () from /lib/

So we received the SIGSEGV signal from the operating system. This means that we tried to access an invalid memory address.
Let’s take a backtrace:

(gdb) backtrace
#0 0x4007fc13 in _IO_getline_info () from /lib/
#1 0x4007fb6c in _IO_getline () from /lib/
#2 0x4007ef51 in fgets () from /lib/
#3 0x80484b2 in main (argc=1, argv=0xbffffaf4) at segfault.c:10
#4 0x40037f5c in __libc_start_main () from /lib/

We are only interested in our own code here, so we want to switch to stack frame 3 and see where the program crashed:

(gdb) frame 3
#3 0x80484b2 in main (argc=1, argv=0xbffffaf4) at segfault.c:10
10 fgets(buf, 1024, stdin)

We crashed inside the call to fgets. In general, we can assume that library functions such as fgets work properly (if this isn’t the case, we are in a lot of trouble). So the problem must be one of our arguments. You may not know that ‘stdin’ is a global variable that is created by the stdio libraries. So we can assume this one is ok. That leaves us with ‘buf’:

(gdb) print buf
$1 = 0x0

The value of buf is 0x0, which is the NULL pointer. This is not what we want – buf should point to the memory we allocated on line 8. So we’re going to have to find out what happened there. First we want to kill the currently-running invocation of our program:

(gdb) kill
Kill the program being debugged? (y or n) y

Now set a breakpoint on line 8:

(gdb) break segfault.c:8
Breakpoint 1 at 0x8048486: file segfault.c, line 8.

Now run the program again:

(gdb) run
Starting program: /home/dgawd/cpsc/363/a.out
Breakpoint 1, main (argc=1, argv=0xbffffaf4) at segfault.c:8
8 buf = malloc(1<<31);

We’re going to check the value of buf before the malloc call. Since buf wasn’t initialized, the value should be garbage, and it is:

(gdb) print buf
$2 = 0xbffffaa8 “Èúÿ¿#\17703@t`01@01”

Now step over the malloc call and examine buf again:

(gdb) next
10 fgets(buf, 1024, stdin);
(gdb) print buf
$3 = 0x0

After the call to malloc, buf is NULL. If you were to go check the man page for malloc, you would discover that malloc returns NULL when it cannot allocate the amount of memory requested. So our malloc must have failed. Let’s go back and look at it again:

7 : buf = malloc(1<<31);

Well, the value of the expression 1 << 31 (the integer 1 right-shifted 31 times) is 429497295, or 4GB (gigabytes). Very few machines have this kind of memory – mine only has 256MB. So of cousre malloc would fail. Furthermore, we are only reading in 1024 bytes in the fgets call. All that extra space would be wasted, even if we could allocate it. Change the 1<<31 to 1024 (or 1<<9), and the program will work as expected.

Congratulations!! U now know how to hack into any executable using GDB.


To summarize:-

gdb <executable name>
frame < N from one of the displayed frame no.s>
break <file:linenumber>
print <variable-name>
next <single-stepping> step-over functions
step <single-stepping> step-into functions
list <
set modifying values during runtime (debug). For Ex. set variable x = 26
call <function-name> for calling functions (logging functions etc.)

Step: The next pause will be at the first line of the function; if you use Next, then the next pause will be at the line following the function call (the function will be single-step executed, but there will be no pauses within it). This can save you a lot of time; If you think the bug does not lie within the function, then use next, so that you don’t waste a lot of time single-stepping within the function itself.

Also Step at a function call, gdb will also tell you the values of the function parameters.

Enjoy 😉 Have a Gr8 day Hacking into Executables using GDB !! 😉

Tutorial Courtesy:

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to Yahoo BuzzAdd to Newsvine


~ by CVS268 on Thu, 14 Jan, 2010.

One Response to “HowTo: Hack into any Executable using GDB”

  1. […] inizio di un hacking pag. 21 arte dell hacking dell apogeo esercizio analogo: […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s