# LOGBOOK 5

## Task 1
- After compiling call_shellcode.c with `make`, 2 binaries were created, a32.out and a64.out, for 32 bit systems and 64 bit systems respectively.
- Both execute a shell, in this case, the zsh shell.
- Both of this shells don't have root privileges.
- These shells don't accept backspaces and arrow keystrokes also create a peculiar behaviour.
- And although they are for different bit systems, they appear to be similar.

## Task 2
- We executed all the commands indicated and now have access to stacks L1, L2, L3 and L4 files and the same files with debugging flag turned on.

## Task 3
- After executing the `p $ebp` the output is `$1 = (void *) 0xffffcde8` wich is the address of the EBP variable. After executing the `p &buffer` command we get `$2 = (char (*)[100]) 0xffffcd7c` which is the address of the buffer. So, the result of the offset is:
R = EBP - buffer + 4 = 0xffffcde8 - 0xffffcd7c + 4 = 0x6C + 4 = 108 + 4 = 112
- We add 4 bytes because the return address is 4 bytes over the edp address.
- By checking the shellcode source code, the actual 32 bits binary code is `"\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f"
"\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x31"
"\xd2\x31\xc0\xb0\x0b\xcd\x80"`, so we changed that in the exploit.py file.
- We added the start value of 490 so the shell code, 27 bytes long, is in the end of the file which is 517 bytes long.
- The content of ebp in the debugger is `0xffffcde8`, so the return adress is ebp + 4. So that the return address points to a NOP instruction in the badfile, we added 200 bytes to the return address, big enough to account for different addresses in a non-debbuger environment, and small enough to not go over the start of the shell code.
- So we changed the `ret = 0xffffcde8 + 4 + 200` in the exploit.py file
- Finally, we executed the exploit.py and running the stack with `./stack-L1` we got access to the shell with root privileges, as we verified by executing `apt upgrade` which is a command that only runs with root privileges.

<figcaption align="center"> Debugger output </figcaption>
<br>

<figcaption align="center"> exploit.py </figcaption>
<br>

<figcaption align="center"> Badfile Contents </figcaption>
<br>

<figcaption align="center"> Shell with root previledges obtained with buffer overflow </figcaption>
<br>

# CTF challenge 1
- After downloading the files and viewing the source code we observe that the program opens and reads a mem.txt file with 8 bytes after reading 20 bytes from the user input.
- By running a checksec on the program we realize that does not exist a cannary to protect the stack, that the stack is not randomized and that we have acess to read, write and execution.
- We can change the file opened from "mem.txt\0" to "flag.txt".
- Since the program reads that input through scanf() that does not have bound checking capability, if the input string is longer than the buffer size, then the characters will overflow. So we can execute a buffer overflow to access memory positions we are not allowed to like the flag.txt file.
- So by running the program and inserting on the input any 20 chars followed by the chars flag.txt we can overflow the input making the program echo the flag.
- Running `nc-fsi.fe.up.pt 4003` followed by:
- `Show me what you got: 11111111111111111111flag.txt`
- The program echos the flag.

# CTF challenge 2
- After downloading the files and viewing the source code we observe that the program reads 24 bytes from the user input and then opens and reads a mem.txt file with 8 bytes.
- By running a checksec on the program we realize that does not exist a cannary to protect the stack, that the stack is not randomized and that we have acess to read, write and execution.
- Since the program reads that input through scanf() that does not have bound checking capability, if the input string is longer than the buffer size, then the characters will overflow. So we can execute a buffer overflow to access memory positions we are not allowed to like the flag.txt file.
- The difference between challenge 1 stands in the condition defined in the main.c file `(*(int*)val == 0xfefc2223)`. To open `flag.txt` file, besides change the file opened from "mem.txt\0" to "flag.txt", also the condition must be satisfy.
- To do that, we had to focus on the content of the val buffer. It represents 'Little Endian Byte Order': The least significant byte of the data is placed at the byte with the lowest address. The rest of the data is placed in order in the next three bytes in memory; for example, the initial content of val buffer `"\xef\xbe\xad\xde"` corresponds to `0xdeadbeef` in hexadecimal.
- So by running the program and inserting on the input any 20 chars followed by the corresponding of `0xfefc2223` in 'Little Endian' notation and and only afterwards the chars "flag.txt", we can overflow the input making the program echo the flag.
- Running `nc-fsi.fe.up.pt 4000` followed by:
- `Show me what you got: 11111111111111111111\x23\x22\xfc\xfeflag.txt`
- The program echos the flag.