config: Add rendering for all chapters

- Add all chapters and topics to `config.yaml`
- Fix broken links
- Rename the "Data and Application Lifetime" chapter to "Data"
- Move the "Application Lifetime" topic to "Binary Introduction"
- Add `.output/` to `.gitignore`

Signed-off-by: Teodor Dutu <[email protected]>

.gitignore

@@ -25,3 +25,6 @@ core
 __pycache__/
 *.py[cod]
 *$py.class
+
+# Open Educational Hub
+.output/

chapters/binary-introduction/assembly-language/reading/README.md

@@ -59,7 +59,7 @@ This is because they are stored _on your device's disk_.
 We simply refer to persistent storage as **storage**.
 Take note of the difference between _storage_ and _memory_.
 
-![Memory Hierarchy](./media/memory-hierarchy.png)
+![Memory Hierarchy](../media/memory-hierarchy.png)
 
 In most programming languages you can freely access data everywhere up to and including the memory.
 In assembly however, you also have access to the **registers** and can influence the **cache**.
@@ -124,7 +124,7 @@ This is possible by slightly changing the name of the register like so:
 The bits contained in each of the above subdivisions are shown in the image below.
 It is similar for `rdi` and `r8`, it's just the names that differ.
 
-![rax Subdivisions](./media/rax-subdivisions.svg)
+![rax Subdivisions](../media/rax-subdivisions.svg)
 
 `rbx`, `rcx` and `rdx` have the same subdivisions as `rax`.
 `rsi` has the same subdivision as `rdi`: `esi`, `si` and `sil`.
@@ -181,13 +181,13 @@ The result is always stored in the `destination`
 
 | Instruction          | Description     | Examples                          |
 |:--------------------:|:---------------:|:---------------------------------:|
-| `add <dest>, <src>`  | `dest += src`   | `add rbx, 5`<br>`add r11, 0x99`   |
-| `sub <dest>, <src>`  | `dest -= src`   | `sub ecx, 'a'`<br>`sub r9, r8`    |
-| `shl <dest>, <bits>` | `dest <<= bits` | `shl rax, 3`<br>`shl rdi, cl`     |
-| `shr <dest>, <bits>` | `dest >>= bits` | `shr r15, 5`<br>`shr rsi, cl`     |
-| `and <dest> <src>`   | `dest &= src`   | `and al, ah`<br>`and bx, 13`      |
-| `or <dest> <src>`    | `dest \|= src`  | `or r10b, cl`<br>`or r14, 0x2000` |
-| `xor <dest> <src>`   | `dest ^= src`   | `xor ebx, edx`<br>`xor rcx, 1`    |
+| `add <dest>, <src>`  | `dest += src`   | `add rbx, 5`<br/>`add r11, 0x99`   |
+| `sub <dest>, <src>`  | `dest -= src`   | `sub ecx, 'a'`<br/>`sub r9, r8`    |
+| `shl <dest>, <bits>` | `dest <<= bits` | `shl rax, 3`<br/>`shl rdi, cl`     |
+| `shr <dest>, <bits>` | `dest >>= bits` | `shr r15, 5`<br/>`shr rsi, cl`     |
+| `and <dest> <src>`   | `dest &= src`   | `and al, ah`<br/>`and bx, 13`      |
+| `or <dest> <src>`    | `dest \|= src`  | `or r10b, cl`<br/>`or r14, 0x2000` |
+| `xor <dest> <src>`   | `dest ^= src`   | `xor ebx, edx`<br/>`xor rcx, 1`    |
 | `inc <dest>`         | `dest++`        | `inc rsi`                         |
 | `dec <dest>`         | `dest--`        | `dec r10w`                        |
 
@@ -291,14 +291,14 @@ Now let's have a look at some conditional jumps:
 |:--------------------------:|:-------------------------------------------------------------:|
 | `jz` / `je`                | Jump if the Zero Flag is active                               |
 | `jnz` / `jne`              | Jump if the Zero Flag is not active                           |
-| `cmp rax, rbx`<br>`j[n]g`  | Jump if `rax` is (not) greater (signed) than `rbx`            |
-| `cmp rax, rbx`<br>`j[n]a`  | Jump if `rax` is (not) greater (unsigned) than `rbx`          |
-| `cmp rax, rbx`<br>`j[n]ge` | Jump if `rax` is (not) greater (signed) or equal than `rbx`   |
-| `cmp rax, rbx`<br>`j[n]ae` | Jump if `rax` is (not) greater (unsigned) or equal than `rbx` |
-| `cmp rax, rbx`<br>`j[n]l`  | Jump if `rax` is (not) lower (signed) than `rbx`              |
-| `cmp rax, rbx`<br>`j[n]b`  | Jump if `rax` is (not) lower (unsigned) than `rbx`            |
-| `cmp rax, rbx`<br>`j[n]le` | Jump if `rax` is (not) lower (signed) or equal than `rbx`     |
-| `cmp rax, rbx`<br>`j[n]be` | Jump if `rax` is (not) lower (unsigned) or equal than `rbx`   |
+| `cmp rax, rbx`<br/>`j[n]g`  | Jump if `rax` is (not) greater (signed) than `rbx`            |
+| `cmp rax, rbx`<br/>`j[n]a`  | Jump if `rax` is (not) greater (unsigned) than `rbx`          |
+| `cmp rax, rbx`<br/>`j[n]ge` | Jump if `rax` is (not) greater (signed) or equal than `rbx`   |
+| `cmp rax, rbx`<br/>`j[n]ae` | Jump if `rax` is (not) greater (unsigned) or equal than `rbx` |
+| `cmp rax, rbx`<br/>`j[n]l`  | Jump if `rax` is (not) lower (signed) than `rbx`              |
+| `cmp rax, rbx`<br/>`j[n]b`  | Jump if `rax` is (not) lower (unsigned) than `rbx`            |
+| `cmp rax, rbx`<br/>`j[n]le` | Jump if `rax` is (not) lower (signed) or equal than `rbx`     |
+| `cmp rax, rbx`<br/>`j[n]be` | Jump if `rax` is (not) lower (unsigned) or equal than `rbx`   |
 
 #### Loops
 

chapters/demystifying-web/explaining-the-internet/reading/README.md

@@ -32,7 +32,7 @@ In order to learn how all of this works, let's start from the example below.
 It's generic enough for it to be relatable to most networking scenarios.
 Yet, it encompasses everything we need to talk about.
 
-![Network Stack](./media/network_stack.png)
+![Network Stack](../media/network_stack.png)
 
 So what happens here is that the computer on the left is trying to **send** data to the one on the right.
 We call the left computer **the sender** and the right one **the receiver**.
@@ -45,7 +45,7 @@ We'll see what's with the *TCP/IP* part soon enough.
 Individually, each box is a **layer**.
 Here are the 4 layers of the TCP/IP stack:
 
-![The TCP/IP Network Stack](./media/tcp_ip_network_stack.svg)
+![The TCP/IP Network Stack](../media/tcp_ip_network_stack.svg)
 
 Each layer provides a well-defined set of requirements, which are fulfilled by **protocols**.
 A networking protocol is a set of rules that define the communication (data formatting and processing) between the same two levels of the network stack.
@@ -68,7 +68,7 @@ At the receiving end, the process happens in reverse: each layer accepts data fr
 Data is passed from a sender process to a receiver process by using the services of the layer below.
 It is only the final layer that actually causes the data to be transmitted onto the transmission media (e.g. cable). Below is a representation of this whole mechanism.
 
-![General Workings of a Network Stack Layer](./media/network_layers.png)
+![General Workings of a Network Stack Layer](../media/network_layers.png)
 
 This method of modular communication is called **encapsulation**.
 It can be likened to taking the data from the layer above and placing it in an **envelope**, writing some additional information on the envelope, then passing the envelope to the layer below.
@@ -151,7 +151,7 @@ Back to our example above, you will surely need many routers to get a packet fro
 But how does a router know how where to send a packet?
 Let's say a router R1 connects a laptop with IP 192.168.100.5 and a PC with IP 192.168.100.10 to the external network, as shown in the image below.
 
-![Router in Action](./media/router_in_action.svg)
+![Router in Action](../media/router_in_action.svg)
 
 Now let's look at 2 different scenarios:
 1. If the laptop sends a packet to IP `192.168.100.10`, the router knows this address is part of its **Local Area Network (LAN)** and sends it directly to the PC.
@@ -318,7 +318,7 @@ In the next section, we'll explain all of these components.
 
 The image below summarises the building blocks of a URL
 
-![Anatomy of a URL](./media/url_anatomy.png)
+![Anatomy of a URL](../media/url_anatomy.png)
 
 Let's disect these components:
 - **The scheme** (sometimes called _schema_) indicates the application layer protocol that the browser must use to request the resource.
@@ -408,7 +408,7 @@ The fact that we are able to perform queries in this manner is proof of the hier
 All in all, the DNS lookup for `security-summer-school.github.io` is the one shown below.
 Notice that the Recursive Resolver acts as a mediator between most of the DNS lookups.
 
-![DNS Lookup for security-summer-school.github.io](./media/dns_lookup.png)
+![DNS Lookup for security-summer-school.github.io](../media/dns_lookup.png)
 
 Notice that only the domain of a URL has its name resolved to an IP address.
 The port, path, parameters and anchor are handled by the web server itself.
@@ -487,7 +487,7 @@ Each ACK is sent together with an **ACK number**.
 This number signifies the amount of bytes received so far by the host.
 It is used by the sender to figure out what portion of the data to send as part of the next segment.
 
-![TCP ACKs in Action](./media/tcp_ack_model.webp)
+![TCP ACKs in Action](../media/tcp_ack_model.webp)
 
 In the above diagram we can see that the sender (client) adds some bytes (whose length is specified as `Len`) to those already sent.
 At the same time, the receiver (server) adds the newly arrived bytes to those received previously and sends this number back to the client as the ACK number.
@@ -547,7 +547,7 @@ What you did is you created an SSH conection using a custom port which did not o
 Think of a container as a lighter, albeit less secure VM.
 The architecture looks like this:
 
-![Challenge Hosting Architecture](./media/challenge_hosting_architecture.svg)
+![Challenge Hosting Architecture](../media/challenge_hosting_architecture.svg)
 
 ### UDP
 
@@ -576,7 +576,7 @@ For this reason, UDP is mostly used for streaming services:
 
 Since an image is worth 1000 words, here's a summary of TCP and UDP:
 
-![TCP vs UDP](./media/tcp_vs_udp.jpg)
+![TCP vs UDP](../media/tcp_vs_udp.jpg)
 
 ## The Application Layer
 
@@ -772,7 +772,7 @@ The containers are most importantly separated at the filesystem level.
 They can also be allocated more limited resources.
 Notice that if you were to use a container for the Security Summer School, you couldn't use Kali Linux unless your host OS were also Kali Linux, which would have been pretty pointless.
 
-![Containers vs VMs](./media/containers-vs-virtual-machines.png)
+![Containers vs VMs](../media/containers-vs-virtual-machines.png)
 
 However, we use containers to host challenges because our VMs and containers all use Linux and because we can house more containers on the same host (which is itself a VM) than we could VMs.
 You can learn more about containers and how to manage them using `docker` (we also use it for challenges) [here](https://www.docker.com/resources/what-container/).

chapters/demystifying-web/hacking-the-web/reading/README.md

@@ -66,7 +66,7 @@ An HTTP cookie (also called web cookie, Internet cookie, browser cookie, or simp
 Cookies were designed to be a reliable mechanism for websites to remember stateful information (such as items added in the shopping cart in an online store) or to record the user's browsing activity (including clicking particular buttons, logging in, or recording which pages were visited in the past).
 They can also be used to remember pieces of information that the user previously entered into form fields, such as names, addresses, passwords, and credit card numbers.
 
-![Cookies](./media/cookies.png)
+![Cookies](../media/cookies.png)
 
 They are like ID cards for websites.
 If a browser sends a certain cookie to a web server, the server deduces the identity of said client from that cookie, without requiring authentication.
@@ -107,7 +107,7 @@ All modern browsers have the ability to assist developers in creating, previewin
 This ability comes in the form of the **Developer Tools** suite.
 You can open the Developer Tools by pressing either `F12` or `Ctrl + Shift + c` when browsing through a website.
 
-![Developer Tools - First Sight](./media/developer-tools.png)
+![Developer Tools - First Sight](../media/developer-tools.png)
 
 ### Inspector
 
@@ -116,7 +116,7 @@ It displays the HTML source of the page we are viewing.
 This structure is called the [Document Object Model](../explaining-the-internet#the-document-object-model-dom).
 We can even modify the content of the HTML document
 
-![Modified Title](./media/inspector-modify-title.png)
+![Modified Title](../media/inspector-modify-title.png)
 
 Of course, this modification is only visible to me because I'm modifying my local copy of the `index.html` file.
 
@@ -125,7 +125,7 @@ Of course, this modification is only visible to me because I'm modifying my loca
 This tab is pretty straightforward.
 It is a shell in which we can write JavaScript code.
 
-![Console](./media/console.png)
+![Console](../media/console.png)
 
 ### Debugger
 
@@ -137,13 +137,13 @@ Hence its name: _Debugger_
 The "Sources" sub-tab of the "Debugger" tab shows the hierarchical structure of all files used by the web page.
 These files can be HTML files, CSS files images, videos, JavaScript files, anything.
 
-![Debugger - Source](./media/debugger-sources.png)
+![Debugger - Source](../media/debugger-sources.png)
 
 Notice the file `(index)` is actually the same we saw in [Inspector](#inspector).
 
 ### Network
 
-![Network](./media/network.png)
+![Network](../media/network.png)
 
 The network tab shows detailed information about every file loaded and every request and response made by the page.
 Notice the sub-tabs to the right.
@@ -153,14 +153,14 @@ This is useful for listing all the resources needed by a page, such as if there
 
 Here we can also see the cookies sent with each request.
 
-![Network - Cookies](./media/network-cookies.png)
+![Network - Cookies](../media/network-cookies.png)
 
 ### Storage
 
 Viewing cookies in the "Network" tab is fine, but that only gives us their value.
 If we want to see all their attributes **and change their value**, we need to go over to the "Storage" tab.
 
-![Storage](./media/_ga-cookie.png)
+![Storage](../media/_ga-cookie.png)
 
 Let's take a closer look at one cookie called `_ga`.
 It comes form "Google Analytics".
@@ -171,7 +171,7 @@ Let's troll them by modifying their cookie
 Its contents are explained [here](https://stackoverflow.com/a/16107194).
 But we're just going to mess with it.
 
-![Storage - Modified](./media/_ga-cookie-modified.png)
+![Storage - Modified](../media/_ga-cookie-modified.png)
 
 There!
 We showed Big Tech not to mess with us!
@@ -204,7 +204,7 @@ The basic workflow is:
 For PHP, these variables will become available in the superglobal variable `$_SESSION`.
 1. If the server doesn't find a match, it will create a new session and repeat steps 1-6.
 
-![Session lifecycle](./media/session.jpg)
+![Session lifecycle](../media/session.jpg)
 
 Example of a session in PHP (running on the server):  
 ```php
@@ -370,7 +370,7 @@ That good we are!
 We visit to the URL, open the Developer Tools and go over to the "Storage" tab.
 There we see the server has given ass the cookie `u=guest`.
 
-![Hacky McHack - Initial Cookie](./media/hacky-mchack-cookies.png)
+![Hacky McHack - Initial Cookie](../media/hacky-mchack-cookies.png)
 
 Since the challenge is called "Hacky McHack" we set the cookie value to `hacky mchack`.
 We notice a new tab has appeared at the top of the page or by inspecting the HTML source: **Manage** (`/manage.php`).

chapters/demystifying-web/rediscovering-the-browser/reading/README.md

@@ -29,7 +29,7 @@ So in short, the server waits for clients to come to it.
 The clients are proactive.
 They reach out to the server by initiating connections.
 
-![Web Application Model](./media/client-server.svg)
+![Web Application Model](../media/client-server.svg)
 
 ## Web Security
 
@@ -97,7 +97,7 @@ Thus, the transport-layer protocol used by HTTP is TCP.
 Most websites nowadays use HTTP or HTTPS to transfer data.
 Remember the anatomy of a URL, also from [the previous session](../explaining-the-internet#anatomy-of-a-url).
 
-![Anatomy of a URL](../explaining-the-internet/media/url_anatomy.png)
+![Anatomy of a URL](../media/url_anatomy.png)
 
 The first part of a URL is called the **scheme**.
 It defines the protocol used for interacting with that website.
@@ -157,14 +157,14 @@ Communication between a client and a server usually follows these steps:
 
 ### Requests
 
-![HTTP - Request](./media/http-request.png)
+![HTTP - Request](../media/http-request.png)
 
 Here we have a `GET` request.
 It is made for a file: `/index.html`.
 
 Remember the **path** from the anatomy of a URL:
 
-![Anatomy of a URL Again](../explaining-the-internet/media/url_anatomy.png)
+![Anatomy of a URL Again](../media/url_anatomy.png)
 
 This is the file that you request.
 The path is like a path in the Linux file system.
@@ -198,7 +198,7 @@ It is described in some more detail in [its own section](#request-body).
 
 ### Responses
 
-![HTTP - Response](./media/http-response.png)
+![HTTP - Response](../media/http-response.png)
 
 - `1xx`: informational responses
 - `2xx`: the request was fulfilled successfully.
@@ -224,7 +224,7 @@ What methods does the server support?
 
 This is the last time today that you'll se the image with the anatomy of a URL, we promise.
 
-![Anatomy of a URL Yet Again](../explaining-the-internet/media/url_anatomy.png)
+![Anatomy of a URL Yet Again](../media/url_anatomy.png)
 
 Look at the **parameters** of the URL
 They are highlighted in blue.
@@ -285,7 +285,7 @@ Each branch of the tree ends in a node, and each node contains objects.
 DOM methods allow programmatic access to the tree.
 With them, you can change the document's structure, style, or content.
 
-![DOM](./media/dom.png)
+![DOM](../media/dom.png)
 
 Every element within your document is an object: `\<head\>` or `\<body\>` tags etc.
 DOMs are flexible and allow easy introduction of nodes, as all objects are nodes.
@@ -576,6 +576,6 @@ Imagine a student logging onto his school's/university's website.
 If they log as a student, they can't access teachers' exam solutions.
 But if they could somehow obtain the role of teacher (while using the same account as before), they could view those solutions.
 
-![RBAC](./media/rbac.svg)
+![RBAC](../media/rbac.svg)
 
 This sort of attack is called a **privilege escalation attack** because the student has managed to _elevate_ his default privileges (as a student) to those of a teacher.

chapters/scratch-linux/welcome-to-linux/reading/README.md

@@ -130,7 +130,7 @@ At the same time, `/` is the root of the file system.
 
 The file hierarchy looks like this:
 
-![Sample File Hierarchy](./media/sample_file_hierarchy.svg)
+![Sample File Hierarchy](../media/sample_file_hierarchy.svg)
 
 Going back to the `current_working_directory` in the prompt, the terminal can also be seen as a file walker.
 This means that at each moment it is "placed" in a certain directory, i.e. at some point in the file hierarchy.