-2

I am learning Assembly Processor architecture and exploit development when I came across this tutorial for x68_64 bufferOverFlows, so i copied the vuln code and compiled it using gcc. My compiled binary does not let me set breakpoints but when i downloaded the binary from the website("I did not want to do this ") it worked fine and memory address were normal

But when i dump main in my compiled program with gdb my memory addresses look like this: 0x000000000000085e <+83>: lea -0xd0(%rbp),%rax

End of assembler dump.

When i try to set a Break poing after the scanf function: (gdb) break *0x000000000000085e Breakpoint 1 at 0x85e (gdb) run 

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

void validate(char *pass) {
   if (strcmp(pass, "[REDACTED]") == 0) {
        printf("ACCESS GRANTED!");
        printf("Oh that's just idio... Oh my god!\n");
    } else {
        printf("Damn it, I had something for this...\n");
    }
}

int main(int argc, char **argv) {
    char password[200];
    printf("C:/ENTER PASSWORD: ");
    scanf("%s", password);
    validate(password);
   return 0;
}
zeroskilz
  • 1
  • 4
  • regarding: `scanf("%s", password);`, 1) always check the returned value (not the parameter values) to assure the operation was successful. In the current scenario, any returned value other than 1 indicates an error occurred. 2) when using the input format specifier '%s' and/or '%[...]', always include a MAX CHARACTERS modifier that is one less than the length of the input buffer, to avoid buffer overflow and the resulting undefined behavior. Suggest: `if( 1 != scanf("%199s", password) ) { fprintf( stderr, "scanf for password failed" ); exit( EXIT_FAILURE ); }` – user3629249 Jan 26 '18 at 04:06
  • 1
    when the parameters to the function: `main()` are not going to be used, then suggest using the signature: `int main( void )` – user3629249 Jan 26 '18 at 04:07
  • 1
    Okay thanks, This program is supposed to be vulnerable though and im just a beginner. basically i copy and pasted this then compiled it using gcc and my memory addresses come out weird i dont know where to begin to look for this answer or word it my memory addresses look as so 0x6c5 weird missing a digit. – zeroskilz Jan 26 '18 at 04:14
  • also when i donwloaded the program from the tutorial website and checked the addresses his came out to look as so 0x6a84 – zeroskilz Jan 26 '18 at 04:15

1 Answers1

2

You can set breakpoints on virtual addresses, but objdump doesn't know where your PIE executable will be mapped into memory, so it uses 0 as a base address. To make things simpler, disable PIE (which your distro apparently enables by default). Presumably your tutorial was written before this was common. Use gcc -fno-pie -no-pie -g foo.c -o foo. Then addresses you see in objdump -drwC -Mintel will match run-time addresses.

But IDK why you want numeric addresses; use b main and single-step from there. Even if you leave out -g, you'll still have symbol names for functions.

To solve the question as asked, see Stopping at the first machine code instruction in GDB and Set a breakpoint on GDB entry point for stripped PIE binaries without disabling ASLR.

Once you have a running process from your executable, you can p &main or disas main to find the actual runtime address of main. But note that gdb disables ASLR, so if you use code addresses you find with GDB in your exploit against a PIE executable, they will only work when run under GDB. Running it "normally" will randomize the virtual address where your executable is mapped. (This is why I suggested building a position-dependent executable). But more likely you just want to return to executable code on an executable stack, in which case it's stack ASLR that matters, and stack-ASLR still happens in plain old position-dependent executables (unless you disable it too, like gdb does).

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847