2

I'm new to Radare2 so i'm trying to learn it by doing some basic buffer overflows. My problem is that, when i try to load some payloads, the stack seems to fake them in some differents ways...

For example, trying to load the input by invoking a simple python script

import struct

def p (x):
    return struct.pack('<I',x)

param = ""
param += "A"*30

param += p(0xb7e40db0)
param += p(0xb7e349e0)
param += p(0xb7f61b0b)

print param

And using this for run it.

r2 -d bufferoverflow `python payload.py`

I get this stack when overflows.

enter image description here

I don't use to get any problem by running it this way

However, when i've set some breakpoints, customize some views in order to be more confortable, I've try to reload the file by using "dor" and "doo" commands from Radare2

enter image description here

But now Radare2 seems to start faking the stack with some random values...

enter image description here

I'm not sure if it's a problem of mine because i'm doing it the wrong way, or if it's caused by a Radare2 behavior that i don't know.

enter image description here

1 Answer 1

1

I think it's intended behavior as this normal mode (no value prefixes - see later) is probably valid for ascii parameters. Here you are passing a payload that can contain ascii controlling bytes and might cause trouble.

From the broken payload it's clearly visible that there's a missing byte 0x0d and this is causing your problems. But why is it missing?

Let's look at the code that sets the values from the new process from rarun2 profile (so basically from dor command in this case).

The profile is being parsed with the following code (libr\socket\run.c):

R_API bool r_run_parse(RRunProfile *pf, const char *profile) {
    r_return_val_if_fail (pf && profile, false);
    char *p, *o, *str = strdup (profile);
    if (!str) {
        return false;
    }
    r_str_replace_char (str, '\r',0); // <------ (1)
    p = str;
    while (p) {
        if ((o = strchr (p, '\n'))) {
            *o++ = 0;
        }
    r_run_parseline (pf, p);
    p = o;
    }
    free (str);
    return true;
}

str is our rarun2 profile (what is passed to dor) and char '\r' is in fact 0xd. It is being removed from the input on line (1) before it's being passed to r_run_parseline that does parsing and setting process environment variables (like args).

Not sure why the line is there - it might be to unify line endings? (windows/linux)

What can be done to overcome this? Modify your script and use one of the value prefixes. If your script instead of raw bytes prints hexpair strings you can use : to parse it and correctly be passed to your program. So change you script to print like this 41414141.....

and then from r2 use : to indicate that the input is a hexpair string.

dor arg1=:`!python payload.py`
doo
1
  • I appreciate your answer so much. That's just what i was looking about.
    – saltmorejo
    Commented Apr 13, 2021 at 8:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.