Who am I? And What is this?

I'm 5alv1, this is a small project that I'll use to keep track of what I learn, what are my ideas for projects, and the CTFs challenges I participate in.

My real (and complete) name is Cristian Salvi, I was born in december 2003. I'm a Computer Science student at Università degli studi di Milano, I'm passionate about software security and I hope I can start doing research some day!

That's it for this introduction! Check out my writeups and my school notes.

Contribution instructions

These are the instructions that you need to read before contributing to any of my sites. first of all you need to be familiar with markdown files. You don't need any other technology to contribute, since I use mdbook to render my posts.

There are a few rules you need to respect in order to contribute:

  1. Your folder names must not contain spaces
  2. Always state your github tag/nickname either in or right after the title
  3. Make all your changes in folders dedicated to external contributions, unless you're adding new assets.
  4. Don't try to push directly into this repo.

The first rule is enforced due to the process I use to generate the file SUMMARY.md, since it's an automated method I would need to change all the entries with spaces in the names whenever I need to deploy. This could be fixed in a future project, maybe I'll create my own generator for this file, but as of now, this is the situation.

The second rule is just a matter of clarity, there is a folder dedicated to external contributions (if there isn't you can create it) and you can either create a subfolder that will be reserved to you and only you named after your nick, or you can specify said nickname at the beginning of your post.

The third rule is actually an exception of the second, you can contribute to the assets folder, create a folder named after your post's title, so that it won't overlap with other files no matter what. The assets folder must be in the src folder, if there isn't an asset folder, create it. In order to use your image in the markdown file you can do something like this (say you're working on notes)

![Placeholder text](https://5alv1.github.io/notes/assets/relative_path_to_image)

The fourth rule is actually a well known convention, you must fork this repository using the button fork you can see in the right high corner when you see the repo.

Image

This will create a copy in your own github account, after you're done with your contribution, on your forked repo you must press contribute and then open pull request.

N

Of course you'll have to know how pushing on a github repository works. But you can learn that on your own can't you? ;P

Deploying

Deploy isn't completely automatic, I need to run a script before deploying, do not touch or execute that script.

If any of these rules is broken I will likely not merge your pull request.

This is a series of lessons I will entertain to discuss the pwn category, I'm doing these lessons while I'm affiliated with K!nd4SUS

IMPORTANT: This is an useful link to learn to use the pwntools library.

Placeholder text We started with an overview of this very picture, we talked mainly about these topics:

  • Buffer overflow
  • ret2win
  • Stack canaries
  • ROP
  • ASLR
  • Heap overflow
  • ARM PAC (mini review)
  • CFI (Shadow Stack)

Buffer overflow (stack)

It's a vulnerability that allows you to write over a buffer's end, that could result into data corruption and/or in the program crashing. Here is an example of a simple C program vulnerable to buffer overflow:

#include <stdio.h>
#include <stdlib.h>

int main() {
char name[16];

printf("Tell me your name!\n");

gets(name);
printf("Hi, %s", name);

// exit(0);
return 0;
}

Placeholder text This is approximately the memory layout we have when we're executing a process. The stack is that part of the memory where we put all the local variables (it's sometimes referred as static memory), the peculiar thing about it is that it also contains all the return addresses we need so basically when we have

01: call rax
02: ; code...

After we call rax the return address will be store in the stack and when we have 

; ...something
ret

in the function we called, we're returning to the address 01. We're effectively doing:

01: push 02
    jmp rax
02: ; code...

and

; ...something
pop rip

(You can't actually edit rip manually, the example is for clarity)

Since the stack has return addresses in it, having control over the stack content means having control over what code will be executed, if you override the current function's return address, you can call an arbitrary function, as long as you know where it is in the memory and it doesn't need any parameters to work (This will be important later). This technique is called ret2win, and originally, what you had to do was to write machine code in the stack, and write the address of your code's beginning where the return address is located; this is now impossible in most cases, because of NX (Non executable stack), so you are forced to reuse code.

ROP (Return Oriented Programming)

This is not a vulnerability, but a technique we use to exploit one. It's an extension of ret2win where you jump to little pre-existing code snippets (called gadgets) that end with ret, you achieve this by writing multiple return addresses instead of just one; so basically at the end of one snippet ret is executed and rip will have the next gadget's address in it. We call these return addresses a ROP chain.

Back in my day, we could put parameters in the stack

ROP is great for a few reasons, (among all, it's Turing complete) but it was certainly easier to exploit back when 32-bit CPUs dominated, that's because the calling convention in x86 for C was to put all the parameters you needed in the stack, well that was convenient, a simple buffer overflow could have resulted in an arbitrary function call with arbitrary parameters; the dream!

It's slightly harder to put parameters in functions on x86-64, we just need a few additional gadgets. Generally, what we want when we need to fill a register reg is a gadget that does pop reg, if the gadget is at some fixed address, we can just put its address in the chain, followed by the value we need in the register.

Bibliography

This paper contains most informations about the buffer overflow part ROP paper About ROP being Turing complete and some techniques to use it Calling conventions for x86