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. If the file is too large, the program should receive a segmentation fault during execution.
Otherwise, the program just exits gracefully. 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. Once we got the program running, we have to write the shellcode.
We face two challenges here. We face two challenges here.
@ -35,11 +35,11 @@ Within `gdb`, we then set a breakpoint on the `mystr` function like this:
`break mystr` `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 ### 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 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` `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. 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: When you now try to exploit the program *without* using `gdb`, you will likely observe a segmentation fault like this: