This is the writeup for CSAPP Attacklab
Tool: IDA/Ghidra, pwndbg, pwntools
Part I: Code Injection Attacks
Simple stack overflow, without the protection of canary and ASLR. Debugger check the stack frame, find out that total 40 bytes offset away from the return address. So make a 40 bytes padding then follow the address of touch1. Done
It checks the argument of touch2 to be the cookie that within the
cookie.txt file. The stack is executable, so inject a shellcode into the stack then return to the stack to execute the shellcode to make
rdi to be the correct cookie.
Level 3 require a pointer to check, however, some part of the stack will be wiped out by the function
touch3, so store the string in somewhere away from the place they wipe out will be fine.
Solution for Part I:
Part II: Return-Oriented Programming
Same with Level 2, but with random memory address. So we are unable to access the code that we inject to the stack. The core part on
touch2 is to make
rdi = cookie. With the help of ROPgadgets, we can find from the
farm.c that there are two place to reach our goal:
Same thing. Try to make
[rdi] = cookie. You may find a gadget in
setval_350 that store
rax. But the hard thing is that if we place where
rsp is pointing to be the cookie value, we are unable to further jump to other places because the cookie take the place that original used for another return address.
So, in order to bypass this issue, we can add an offset to
add_xy function. So that it will point away from current position and we can store cookie string to other places.
Solution for Part II: