Sleeeee · Sleeeee · Apr 6, 2026 · Feb 21, 2026 · Mar 6, 2026 · Mar 7, 2026
diff --git a/docs/images/i2c_coffee_facts.png b/docs/images/i2c_coffee_facts.png
diff --git a/docs/images/i2c_eeprom_addressing.png b/docs/images/i2c_eeprom_addressing.png
diff --git a/docs/images/i2c_eeprom_dump.png b/docs/images/i2c_eeprom_dump.png
diff --git a/docs/images/i2c_eeprom_wc.png b/docs/images/i2c_eeprom_wc.png
diff --git a/docs/images/i2c_eeprom_writefail.png b/docs/images/i2c_eeprom_writefail.png
diff --git a/docs/images/i2c_eeprom_writesuccess.png b/docs/images/i2c_eeprom_writesuccess.png
diff --git a/docs/images/i2c_pulseview_channel.png b/docs/images/i2c_pulseview_channel.png
diff --git a/docs/images/i2c_pulseview_decoder.png b/docs/images/i2c_pulseview_decoder.png
diff --git a/docs/images/i2c_pulseview_read.png b/docs/images/i2c_pulseview_read.png
diff --git a/docs/images/i2c_pulseview_samplerate.png b/docs/images/i2c_pulseview_samplerate.png
diff --git a/docs/images/i2c_pulseview_trace.png b/docs/images/i2c_pulseview_trace.png
diff --git a/docs/images/i2c_root_attempt.png b/docs/images/i2c_root_attempt.png
diff --git a/docs/images/i2c_root_login.png b/docs/images/i2c_root_login.png
diff --git a/docs/images/i2c_shell.png b/docs/images/i2c_shell.png
diff --git a/docs/images/i2c_user_attempt.png b/docs/images/i2c_user_attempt.png
diff --git a/docs/images/i2c_user_login.png b/docs/images/i2c_user_login.png
diff --git a/docs/images/logicanalyzer_firmware.png b/docs/images/logicanalyzer_firmware.png
diff --git a/docs/images/logicanalyzer_pulseview_channel.png b/docs/images/logicanalyzer_pulseview_channel.png
diff --git a/docs/images/logicanalyzer_pulseview_connect.png b/docs/images/logicanalyzer_pulseview_connect.png
diff --git a/docs/images/logicanalyzer_pulseview_decoder.png b/docs/images/logicanalyzer_pulseview_decoder.png
diff --git a/docs/images/logicanalyzer_pulseview_home.png b/docs/images/logicanalyzer_pulseview_home.png
diff --git a/docs/labs/00_swd/instructions.md b/docs/labs/00_swd/instructions.md
@@ -14,8 +14,8 @@ Below is a check list of all the tools and skills that you need in order to perf
 - DVH board with latest firmware (if not, you will need to [flash](../../tools/flash.md) it).
 - Debugger ([debugprobe](../../tools/debugprobe.md), ST-Link or something else)
 - Micro-USB cable and 5-12V power supply
-- Micro-USB to USB/USB-C cable (depending on your computer's ports)
-- 3 Dupont cables (recommended) or regular wires
+- Micro-USB to USB/USB-C cable (depending on available ports)
+- Dupont cables (recommended) or regular wires
 
 ### Software
 

diff --git a/docs/labs/00_swd/walkthrough.md b/docs/labs/00_swd/walkthrough.md
@@ -16,7 +16,7 @@ Also, it is important to note that the screenshots may have been taken on a prev
 
 If this has not been done yet, we will install and configure OpenOCD, as explained [here](../../tools/flash.md). We will not dive into much explanation here, but feel free to read the dedicated document. You can install OpenOCD with `sudo apt install openocd` then paste this configuration into a file named `openocd.cfg` :
 
-```
+```bash
 # Source debugprobe interface config file
 source /usr/share/openocd/scripts/interface/cmsis-dap.cfg
 transport select swd
@@ -30,12 +30,16 @@ adapter speed 5000
 
 We can now wire the [Debugprobe](../../tools/debugprobe.md) to the SWD interface of DVH board. They need three wires as mentioned before, SWDCLK, SWDIO and a common ground :
 
+<div align="center">
+
 | DVH    | Pico |
 |--------|------|
 | SWDCLK | GP2  |
 | SWDIO  | GP3  |
 | GND    | GND  |
 
+</div>
+
 You may need to take a look at the pinout for both the DVH board and the [Raspberry Pi Pico](https://www.raspberrypi.com/documentation/microcontrollers/pico-series.html).
 
 <p align="center">
@@ -48,15 +52,15 @@ Once you have set up the boards, you can power them on, while connecting the deb
 
 In order to dump the firmware, we can execute this OpenOCD command :
 
-```
+```bash
 openocd -f openocd.cfg -c "init; reset halt; dump_image firmware.bin 0x08000000 0x10000; exit"
 ```
 
 This command initiates a connection with the STM32 chip, tells it to reset and freeze instantaneously. This is very important because it allows the Debugprobe to correctly read the data from the chip. A running MCU would throw errors or incomplete/corrupt data. The command asks to dump the running image to a local file named `firmware.bin`, starting from address `0x08000000` with a flash size of `0x10000` (64kB).
 
 If the dumping executed successfully, you should see a new file `firmware.bin` in your working directory, as well as a similar output tail :
 
-```
+```bash
 [stm32f1x.cpu] halted due to debug-request, current mode: Thread
 xPSR: 0x01000000 pc: 0x08000544 msp: 0x20005000
 ```
@@ -71,7 +75,7 @@ Now that we have extracted the firmware, we can use a couple command line tools
 
 The first tool is the `file` utility. It prints out interesting pieces of information, such at the processor infrastructure and interesting addresses (exception vector table).
 
-```
+```bash
 $ file firmware.bin
 firmware.bin: ARM Cortex-M firmware, initial SP at 0x20005000, reset at 0x08000544, NMI at 0x08000368, HardFault at 0x0800036a, SVCall at 0x08000372, PendSV at 0x08000376
 ```
@@ -82,7 +86,7 @@ As you can see in this output, the architecture is `ARM Cortex-M` and for exampl
 
 We can also use another interesting utility to gather more information on our binary file, the `strings` command. This tool will read the binary data, and print out the ASCII characters that it finds. Since the firmware is machine code, most of it will be gibberish, but you will often encounter some interesting strings :
 
-```
+```bash
 $ strings firmware.bin
 L#x3
 iQHB
@@ -92,7 +96,7 @@ iQHB
 
 There will often be random characters because occasionnally, hexadecimal values in the machine code will actually form strings. By default, `strings` prints any sequence of at least 4 characters, but to filter some of the randomness, we can manually set a higher threshold :
 
-```
+```bash
 $ strings -n 10 firmware.bin
 FpGDVH{...............................}
 ```

diff --git a/docs/labs/01_uart/instructions.md b/docs/labs/01_uart/instructions.md
@@ -11,11 +11,11 @@ Below is a check list of all the tools and skills that you need in order to perf
 ### Materials and equipment
 
 - Computer
-- DVH board with latest firmware (if not, you will need to [flash](../../tools/flash.md) it).
+- DVH board with latest firmware (if not, you will need to [flash](../../tools/flash.md) it)
 - UART bridge ([debugprobe](../../tools/debugprobe.md) for example)
 - Micro-USB cable and 5-12V power supply
-- Micro-USB to USB/USB-C cable (depending on your computer's ports)
-- 3 Dupont cables (recommended) or regular wires
+- Micro-USB to USB/USB-C cable (depending on available ports)
+- Dupont cables (recommended) or regular wires
 
 ### Software
 

diff --git a/docs/labs/01_uart/walkthrough.md b/docs/labs/01_uart/walkthrough.md
@@ -2,6 +2,10 @@
 
 ## Overview
 
+This is a complete walkthrough of the UART lab, that is meant to guide you through every step of the way. You can read through this document to perform the lab, but for educational purposes, it is strongly suggested to use the [instructions](./instructions.md) as a main roadmap, and come back here whenever you feel stuck or need a sanity check.
+
+> By this point, I assume that you have read through the instructions and understood the goal of this lab.
+
 ## Walkthrough
 
 ### Set up
@@ -10,12 +14,16 @@ Before starting the lab, you will need to have a functional [Debugprobe](../../t
 
 We will have to connect the DVH board's UART interface with the corresponding Raspberry Pi Pico to allow them to communicate accordingly :
 
+<div align="center">
+
 | DVH     | Pico |
 |---------|------|
 | UART_RX | GP4  |
 | UART_TX | GP5  |
 | GND     | GND  |
 
+</div>
+
 You may need to take a look at the pinout for both the DVH board and the [Raspberry Pi Pico](https://www.raspberrypi.com/documentation/microcontrollers/pico-series.html). As per UART standards, a circuit sends data through its `TX` pin, which is received by the other circuit on its `RX` pin.
 
 <p align="center">
@@ -28,15 +36,15 @@ You may need to take a look at the pinout for both the DVH board and the [Raspbe
 
 In order to establish a serial communication over UART, we will start by installing `minicom` :
 
-```
+```bash
 sudo apt install minicom
 ```
 
 > Feel free to choose any other alternative such as PuTTY for example.
 
 You can now power on the Pico and the DVH board, then open the serial port using `minicom` :
 
-```
+```bash
 minicom -b 115200 -o -D /dev/ttyACM0
 ```
 
@@ -108,22 +116,22 @@ Unfortunately, we were not able to retrieve plain passwords, but we managed to g
 
 By inspecting the hash format, we can see it is formatted like a [Linux password](https://man7.org/linux/man-pages/man3/crypt.3.html), which typically looks like this :
 
-```
+```bash
 $id$salt$hashed
 ```
 
 From there, we can identify the hashing function corresponding to ID 7. According to `libxcrypt`, the modern Linux hashing library ([source](https://github.com/besser82/libxcrypt/blob/develop/lib/hashes.conf)), we find that this value corresponds to `scrypt`.
 
 Unfortunately, unlike some obsolete hashing functions like MD5, `scrypt` is considered safe and cannot be broken. However, even if we cannot reverse the hash, nothing is preventing us from brute-forcing it, by computing the hash for common passwords and seeing if any of them matches ! To help us with that, we will swap over to our Linux machine and install John The Ripper, a handy password cracking tool :
 
-```
+```bash
 sudo apt update
 sudo apt install john
 ```
 
 John expects hashes to be inside a file, so we can paste our hash into a new `hash.txt` file (you will need to escape the `$` signs by placing a `\` before each of them). We also know the hashing function is `scrypt`. The only thing that is left is to find a wordlist, containing common passwords that will be tested against the hash. The one we will use is one of the most famous wordlists, which comes from a huge data breach from [RockYou](https://github.com/zacheller/rockyou) :
 
-```
+```bash
 wget https://raw.githubusercontent.com/zacheller/rockyou/master/rockyou.txt.tar.gz
 tar -xzvf rockyou.txt.tar.gz
 ```

diff --git a/docs/labs/02_i2c/README.md b/docs/labs/02_i2c/README.md
@@ -0,0 +1,46 @@
+# Inter-Integrated Circuit (I²C)
+
+## Overview
+
+I²C (pronounced "I-squared-C" or "I-two-C") is a serial communication bus that is used to send data between integrated circuits in a master-slave architecture. This type of interface is implemented on most microcontrollers that can act as either a master or a slave, and a lot of chips such as sensors, ROMs, transmitters, and so many more, can act as an I²C slave and receive commands from a master using their custom protocol lying on top of the I²C communication bus.
+
+One advantage of I²C is that it only needs two signal lines :
+
+- SCL : Serial Clock line
+- SDA : Serial Data line
+
+Multiple slaves can be wired on the same I²C bus. Because there is no dedicated Chip Select (CS) signal, the I²C master starts the communication by sending a message containing the slave address (7 bits) and the requested operation type (Read/Write - 1 bit). All slaves listen, but only respond if the slave address transmitted corresponds to their own.
+
+> All slaves should have different identifiers to avoid collisions.
+
+### M24C02
+
+In the case of this lab, we will be looking at a specific I²C implementation : the M24C02 EEPROM. An EEPROM, or Electrically Erasable Programmable Read-Only Memory, is a simple data storage device. The M24 family are tiny chips (designed by ST Microelectronics, the same company behind STM32 microcontrollers) that can be placed in IOT systems to store hardcoded data (a password for example).
+
+> To get a deeper understanding of the M24C02, please read the [datasheet](https://www.st.com/en/memories/m24c02-w.html).
+
+## Exploit
+
+Because I²C enables communication between circuits by exposing an unencrypted bus, the attack surface is quite large, and can be exploited by attackers in multiple ways, for example :
+
+- Sniff communications to reverse engineer the system's behavior.
+- Impersonate the master and control the slave.
+- Impersonate the slave and give wrong data to the master.
+- Replay arbitrary communications.
+
+Depending on the application, exploits can become very specific. For example, with an EEPROM, we could read the stored data to discover sensitive strings or values.
+
+## Mitigations
+
+Although the I²C bus itself is inherently insecure, there are some techniques that can help reduce the attack surface :
+
+- Encrypt the payloads (you cannot encrypt the I²C transport itself, but you can encrypt the data it transports).
+- Authenticate messages (MAC) to validate integrity and sender validity.
+- Include a nonce against replay attacks.
+- Avoid exposing easily accessed sensitive I²C lines.
+
+In IOT, targets implement their own commmunication protocol over I²C by defining how they should process the payloads transported by I²C. This means that the security of the communications will highly depend on the target model.
+
+## Practice
+
+You can now gain hands-on experience with I²C and the EEPROM by completing the [lab](./instructions.md) for this section.
diff --git a/docs/labs/02_i2c/instructions.md b/docs/labs/02_i2c/instructions.md
@@ -0,0 +1,44 @@
+# I²C lab instructions
+
+## Overview
+
+Here are the top-level instructions required to perform the I²C lab. They are meant to give you the necessary information to get you started by yourself. If you ever feel stuck or need any help, you can read the lab's complete [walkthrough](./walkthrough.md) that will provide step-by-step instructions.
+
+## Requirements
+
+Below is a check list of all the tools and skills that you need in order to perform the lab. Everything is mandatory unless stated otherwise, except the skill set items. It is absolutely not a problem if you do not have some of the listed skills, but fundamentals of these topics is always nice to have. Anyway, you will learn more about those in the context of the lab. Feel free to do your own research whenever you lack understanding of any of the topics.
+
+### Materials and equipment
+
+- Computer
+- DVH board with latest firmware (if not, you will need to [flash](../../tools/flash.md) it)
+- UART bridge ([debugprobe](../../tools/debugprobe.md) for example)
+- Logic analyzer (can be set up on a [Pico](../../tools/logic_analyzer.md))
+- MicroPython board (can be set up on a [Pico](../../tools/micropython.md))
+- Micro-USB cable and 5-12V power supply
+- Micro-USB to USB/USB-C cable (depending on available ports)
+- Dupont cables (recommended) or regular wires
+
+> Note that completing this lab requires a UART bridge, a logic analyzer, and a MicroPython board, which can all be set up on a Raspberry Pi Pico, but not at the same time (with official firmware). This will require switching Pico firmware back and forth, but the lab is entirely doable with a single Pico. Acquiring standalone tools, or using multiple Pico boards can be an option for comfort.
+
+### Software
+
+- Serial terminal emulator ([Minicom](https://man7.org/linux/man-pages/man1/minicom.1.html) is the alternative used in the [walkthrough](./walkthrough.md))
+- Logic analyzer software ([PulseView](https://sigrok.org/wiki/PulseView) recommended, setup is included in the logic analyzer [setup](../../tools/logic_analyzer.md))
+- Linux Physical or Virtual Machine (recommended)
+
+### Skill set
+
+
+
+## Objective
+
+
+
+## Instructions
+
+### Reset the lab
+
+> This step is off-limits in the scope of the lab.
+
+Since the EEPROM is independent from the STM32, it needs to go through an initialization process to make sure the environment is properly setup, and the EEPROM is in a valid state. In order to initialize or reset the lab, press the reset button while powering on the board. The LED will blink, and if everything goes smoothly, it will turn off. If it stays on, an error has occured, meaning the reset has not been completed. Please retry until you end up with an LED turned off.