From 58d1785333b65e361c1e9dc7830c18c3de89d2a2 Mon Sep 17 00:00:00 2001 From: "christian.rossow" Date: Thu, 7 Nov 2024 15:25:25 +0100 Subject: [PATCH] fixed typo --- lecture-demos/buffer-overflow/README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/lecture-demos/buffer-overflow/README.md b/lecture-demos/buffer-overflow/README.md index 38b2e3a..4a8720c 100644 --- a/lecture-demos/buffer-overflow/README.md +++ b/lecture-demos/buffer-overflow/README.md @@ -15,7 +15,7 @@ To compile the demo, use an x64 system with `gcc` and `nasm` installed and invok If the file is too large, the program should receive a segmentation fault during execution. Otherwise, the program just exits gracefully. -## Exploiting the program within a debugger +## Exploiting the program WITHIN a debugger Once we got the program running, we have to write the shellcode. We face two challenges here. @@ -35,11 +35,11 @@ Within `gdb`, we then set a breakpoint on the `mystr` function like this: `break mystr` -You can then execute the program using the gdb command `run`. The program will execute until hitting the breakpoint. If you don't see registers or assembly you, simply enter `layout asm` and `layout regs`. You should then see the program before executing the `mystr` function prologue. Now, you can single-step using the `gdb` command `ni`. Single-step until after the function prologue (i.e., right after`sub rsp,0x200`). You then see the stack frame looking at `rbp` and `rsp`, where `rsp` points to the top of the stack and thus the single local function variable (the 512B buffer) in our function. Note down this value (in my case, `0x7fffffffe090`) and exit the debugger with SIGINT (i.e., CTRL+D) or using `exit` (noone does that). +You can then execute the program using the gdb command `run`. The program will execute until hitting the breakpoint. If you don't see registers or assembly you, simply enter `layout asm` and `layout regs`. You should then see the program before executing the `mystr` function prologue. Now, you can single-step using the `gdb` command `ni`. Single-step until after the function prologue (i.e., right after`sub rsp,0x200`). You then see the stack frame looking at `rbp` and `rsp`, where `rsp` points to the top of the stack and thus the single local function variable (the 512B buffer) in our function. Note down this value (in my case, `0x7fffffffe090`) and exit the debugger with SIGINT (i.e., CTRL+D) or using `exit` (noone does that). Update the last line of the shellcode accordingly (the `dq` contains the stack pointer). ### Compiling the shellcode -After having writting/adapted the shellcode, compile it using `make`. +After having adapted the shellcode, compile the shellcode using `make`. To double-check if the shellcode was compiled correctly, you can disassemble it using the command `objdump -D -b binary -M intel -d -m i386:x86-64 ./shellcode | less -S` @@ -55,7 +55,7 @@ and then use the `run` command to get your shell. Exit with SIGINT (CTRL+D); the first SIGINT will exit the shell, the second the debugger. -## Shellcode for exploits outside of the debugger +## Shellcode for exploits OUTSIDE OF the debugger When you now try to exploit the program *without* using `gdb`, you will likely observe a segmentation fault like this: