taming-the-stack: Add session content

chapters/binary-introduction/taming-the-stack/guides/function-calls/README.md

@@ -0,0 +1,46 @@
+# Function Calls
+
+Use `objdump` to investigate the prologue of the `read_array()` and `print_array()` functions.
+
+```console
+root@kali:~$ objdump -d -M intel main
+```
+
+Notice how in the prologue, `ebp` saves the `esp` value before the local variables are stored on stack:
+
+```asm
+080491a6 <read_array>:
+ 80491a6:       55                      push   ebp
+ 80491a7:       89 e5                   mov    ebp,esp
+ 80491a9:       83 ec 18                sub    esp,0x18
+ 80491ac:       83 ec 08                sub    esp,0x8
+```
+
+What's more, take a closer look at how the parameters are handled:
+
+```asm
+ 80491af:       ff 75 0c                push   DWORD PTR [ebp+0xc] ; the second argument of read_array()
+ 80491b2:       68 08 a0 04 08          push   0x804a008
+ 80491b7:       e8 c4 fe ff ff          call   8049080 <__isoc99_scanf@plt>
+
+ 8049213:       8b 45 08                mov    eax,DWORD PTR [ebp+0x8] ; the first argument of print_array()
+```
+
+Now, inside `gdb`, let's take a look at where the return address is saved:
+
+```console
+pwndbg> info frame
+Stack level 0, frame at 0xffffcd30:
+ eip = 0x80491ac in read_array (main.c:5); saved eip = 0x8049273
+ Saved registers:
+  ebp at 0xffffcd28, eip at 0xffffcd2c
+
+pwndbg> x 0xffffcd2c
+0xffffcd2c:     0x08049273
+```
+
+Let's do the math:
+
+- `ebp` points at `0xffffcd28`
+- `ebp + 4` will then point at `0xffffcd2c`
+- the value stored at `0xffffcd2c` is `0x08049273`, the same as the one from the saved `eip`

chapters/binary-introduction/taming-the-stack/guides/function-calls/support/Makefile

@@ -0,0 +1,15 @@
+CFLAGS = -m32 -Wall -fno-PIC -g -O0
+LDFLAGS = -m32 -no-pie
+
+.PHONY: all clean
+
+all: main
+
+main: main.o
+
+main.o: main.c
+
+clean:
+	-rm -f main.o
+	-rm -f main
+	-rm -f *~

chapters/binary-introduction/taming-the-stack/guides/function-calls/support/main.c

@@ -0,0 +1,57 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright 2023 University POLITEHNICA of Bucharest
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright notice, this
+ *    list of conditions and the following disclaimer.
+ *
+ * 2. Redistributions in binary form must reproduce the above copyright notice,
+ *    this list of conditions and the following disclaimer in the documentation
+ *    and/or other materials provided with the distribution.
+ *
+ * 3. Neither the name of the copyright holder nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+ * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+ * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+ * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include <stdio.h>
+
+void read_array(int *v, int *n)
+{
+	scanf("%d", n);
+
+	for (int i = 0; i < *n; ++i)
+		scanf("%d", &v[i]);
+}
+
+void print_array(int *v, int n)
+{
+	for (int i = 0; i < n; ++i)
+		printf("%d ", v[i]);
+
+	printf("\n");
+}
+
+int main(void)
+{
+	int v[16], n;
+
+	read_array(v, &n);
+	print_array(v, n);
+
+	return 0;
+}

chapters/binary-introduction/taming-the-stack/reading/data-data-everywhere.md

@@ -0,0 +1,13 @@
+# Data, Data Everywhere
+
+Up until now, we've learnt that our application (or program) is made out of data and code.
+While the code is the engine of the process, as it obviously tells the processor the work that it should do, data is the most interesting (and dangerous) part when it comes to changing the execution of an app.
+Why, you might ask?
+Well, because it's modifiable;
+the majority of the data contained by your program lays around in the `.stack`, `.heap` or `.data` sections of the executable, which makes it **writable**.
+And therefore, even more appealing to the attackers.
+
+Attacks on `.rodata` variables are rarely possible due to the protections enforced by the permissions, or lack thereof.
+Even though less protected, the `.text` section also gets fewer attacks, as the `W ^ X` security feature becomes the norm.
+
+The gate remains open for malicious endeavours on the `.stack`, `.heap` and `.data` sections, and, today, we'll discuss the most prolific one: the stack.

chapters/binary-introduction/taming-the-stack/reading/functions-and-the-stack.md

@@ -0,0 +1,61 @@
+# Functions and the Stack
+
+Every function has two classes of values, usually stored on stack, extremely important for its well-being:
+
+1. the return address
+
+1. the parameters / arguments
+
+Meddling with these might get you to a big fat **SEGFAULT** or to great power.
+
+## `ebp`, the Stack Frame
+
+But before discussing that, we have to bring light to another obscure register, `ebp`.
+We kind of used it before, in our journey, as it has a great advantage.
+It stores the stack pointer value right before the stack begins to hold local variables and preserved register values.
+In other words, it keeps a pointer to the stack at the beginning of the function, enabling us to actually move freely through the stack.
+We will, now, refer to values stored on it, even though they are not the last ones.
+
+```asm
+push ebp
+mov ebp, esp
+
+push dword 3
+push dword 4
+push dword 5
+
+; at this point esp decreased its value with 3 * 4 = 12 bytes
+; traditionally we can access the last value only,
+; however the stack is like an array, so we will use the pointers
+; it offers us
+
+mov eax, [esp + 8] ; eax = 3
+mov eax, [ebp - 4] ; eax = 3
+```
+
+## The Return Address
+
+The return address of a function is one of the **most targeted** piece of information in an attack.
+There is even a special class of attacks that takes its name from it, [ROP](https://security-summer-school.github.io/binary/return-oriented-programming/) (Return Oriented Programming).
+Moreover, the return address can also be defined as a **code pointer**, a pointer that stores the address of an instruction.
+Remember how the instructions were stored in the code or text section, hence the **code pointer** label.
+
+The reason for this kind of popularity is obvious: it represents one of the rare instances when the program **performs a jump to a code pointer saved on stack**, which, combined with the stupidity or the laziness of the programmer, can result in a nasty backdoor to the system.
+
+The address at which the return address is usually stored on x86 systems is `[ebp + 4]`.
+
+## The Parameters
+
+The parameters follow a similar story to that of the return address, with a slight modification, though.
+On 64-bit x86 they are placed in special registers, if possible.
+If the number of parameters is high, they would get transmitted using the stack, just as it happens, on 32-bit x86.
+
+The address at which the first parameter gets stored on 32-bit x86 systems is `ebp + 8`.
+
+The address at which the second parameter gets stored on 32-bit x86 systems is `ebp + 12`.
+
+The address at which the third parameter gets stored on 32-bit x86 systems is `ebp + 16`.
+
+And so on.
+
+![parameters and ebp](../media/function-stack.jpg)

chapters/binary-introduction/taming-the-stack/reading/further-reading.md

@@ -0,0 +1,7 @@
+# Further Reading
+
+[Stack Immersion](https://github.com/systems-cs-pub-ro/iocla/blob/master/laborator/content/stiva/README.md)
+
+[Function Calls Immersion](https://github.com/systems-cs-pub-ro/iocla/blob/master/laborator/content/apel-functii/README.md)
+
+[ROP attacks](https://resources.infosecinstitute.com/topics/hacking/return-oriented-programming-rop-attacks/)

chapters/binary-introduction/taming-the-stack/reading/introduction.md

@@ -0,0 +1,10 @@
+# Introduction
+
+While the last three sessions introduced concepts regarding processes, executables and the means to investigate them, this session will, **finally**, focus on how to manipulate apps to do strange and (sometimes) undesired behaviour.
+
+## Reminders and Prerequisites
+
+- hexadecimal representation
+- process address space
+- x86 Assembly knowledge: memory addressing and basic commands
+- `Ghidra`, `objdump`, `nm`, `gdb`