christian.rossow
/
sfl-examples
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

fixed typo

This commit is contained in:
christian.rossow 2024-11-07 15:25:25 +01:00
parent e97c155816
commit 58d1785333
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
lecture-demos/buffer-overflow/README.md
View File

@ -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: