SHARE:

My edb and gdb learning to solve an online BO challenge

Spread the love

I was searching through a couple of sites online and I stumbled upon a hacking challenge website (URL: canyouhack.us) that is both fun and a tool for recruitment. After a couple of days between my day job and at night I was able to capture the flag (CTF) for the buffer overflow (BO) challenge this particular site provided. Since I don’t think its a good idea to post the solution I am going to post something similar and more towards my use of edb and gdb.

The BO code is around unsanitized input. Below is a quick and dirty code sample so that I can use it to understand what I should be looking for. (The challenge is kind of similar but not quite, there are more variables that are laid down in the heap bunched up together…)

#include <unistd.h>
#include <stdio.h>
void Test()
{
   char buff[4];
   printf("Some input: ");
   gets(buff);
   puts(buff);
}
int main(int argc, char *argv[ ])
{
   Test();
   return 0;
}

As you can see in the code the “buff” variable can only take a maximum of 4 bytes. I tried to compile this code using gcc but it kept providing me with warnings around my old c style directives but thought nothing of it until I used gdb.

## The above code sample is saved as vuln2.c.

root@kali:~# gcc vuln2.c -o vuln2 -m32 -ggdb -fno-stack-protector

vuln2.c: In function ‘Test’:
vuln2.c:8:4: warning: implicit declaration of function ‘gets’; did you mean ‘fgets’? [-Wimplicit-function-declaration]
    gets(buff);
    ^~~~
    fgets
/tmp/cc5bNHLl.o: In function `Test':
/root/vuln2.c:8: warning: the `gets' function is dangerous and should not be used.

root@kali:~#

On my 32bit Kali linux I kept getting “No such file or directory” around the printf statement. This is a problem because it is where the main input begins, so I tried various other ubuntu linux versions. The versions I tried were Ubuntu 14.04.5-i386, Ubuntu 16.04.4-i386 and Ubuntu 18.04-amd64. The only version that seemed to allow me to step through the code was the 64 bit version.

Example of the errors I was getting.

root@kali:~# gdb vuln2
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from vuln2...done.
(gdb) break main
Breakpoint 1 at 0x5e0: file vuln2.c, line 14.
(gdb) r
Starting program: /root/vuln2 

Breakpoint 1, main (argc=1, argv=0xbffff454) at vuln2.c:14
14	   Test();
(gdb) s
Test () at vuln2.c:7
7	   printf("Some input: ");
(gdb) 
__printf (format=0x80000680 "Some input: ") at printf.c:28
28	printf.c: No such file or directory.
(gdb) q
A debugging session is active.

  Inferior 1 [process 16444] will be killed.

Quit anyway? (y or n) y
root@kali:~# 

What I was able to do using the Ubuntu 18.04-64bit version. Note I changed the name of the executable on the Ubuntu box.

root@ubuntu:~$ gdb testbuff 
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from testbuff...done.
(gdb) break main
Breakpoint 1 at 0x5e0: file testbuff.c, line 14.
(gdb) r
Starting program: /home/gs/testbuff 

Breakpoint 1, main (argc=1, argv=0xffffd244) at testbuff.c:14
14	   Test();
(gdb) s
Test () at testbuff.c:7
7	   printf("Some input: ");
(gdb) 
8	   gets(buff);
(gdb) 
Some input: AAA
9	   puts(buff);
(gdb) x/x $ebp
0xffffd188:	0xffffd198
(gdb) x/x $ebp-4
0xffffd184:	0x00000000
(gdb) x/x $ebp-8
0xffffd180:	0x00000001
(gdb) x/x $ebp-12
0xffffd17c:	0x00414141
(gdb) x/s 0xffffd17c
0xffffd17c:	"AAA"
(gdb) x/x $ebp-16
0xffffd178:	0x4c
(gdb) x/s 0xffffd17c
0xffffd17c:	"AAA"
(gdb) x/s 0xffffd178
0xffffd178:	"L\322\377\377AAA"
(gdb) quit
A debugging session is active.

  Inferior 1 [process 5174] will be killed.

Quit anyway? (y or n) y

So looking at the gdb output you can see that my “AAA” input is found at $ebp-12. Being able to find this took me a bit of time as I don’t disassemble code on a daily basis and this helped me understand what I am looking for and how the stack is setup. As you can see at this point if I had entered “AAAA\n” I would have started to over write addresses in the stack. In this case it would have been this line, ‘0xffffd178: “L\322\377\377AAA”‘.

Moving on to Evans Debugger or edb, it appears to be much easier to manipulate and see registers and dumps. Essentially run the program until the edb console pops up with the input request. At this point stop program execution, enter your inputs and step through the commands. You can right click the base stack pointer to dump things out similar to the above with gdb on the command line.

EDB Output

Using what I learned from both edb and gdb, I was able to craft a small piece of python script to deliver a payload to obtain my flag for the challenge. 

Written by

gseeto

Technology, Science and Philosophy