diff --git a/README.md b/README.md
index 16b11e2..6f36900 100644
--- a/README.md
+++ b/README.md
@@ -149,6 +149,16 @@ This chapter covers hacking uninitialized variables as well as an intro to GPIO
## Week 5
Integers and Floats in Embedded Systems: Debugging and Hacking Integers and Floats w/ Intermediate GPIO Output Assembler Analysis
+### Week 5 Notebook [HERE](https://github.com/mytechnotalent/Embedded-Hacking/blob/main/WEEK05/WEEK05.md)
+
+#### Exercise 1: Analyze the Float Binary in Ghidra [HERE](https://github.com/mytechnotalent/Embedded-Hacking/blob/main/WEEK05/WEEK05-01.md)
+
+#### Exercise 2: Patch the Float Binary — Changing 42.5 to 99.0 [HERE](https://github.com/mytechnotalent/Embedded-Hacking/blob/main/WEEK05/WEEK05-02.md)
+
+#### Exercise 3: Analyze the Double Binary in Ghidra [HERE](https://github.com/mytechnotalent/Embedded-Hacking/blob/main/WEEK05/WEEK05-03.md)
+
+#### Exercise 4: Patch the Double Binary — Changing 42.52525 to 99.99 [HERE](https://github.com/mytechnotalent/Embedded-Hacking/blob/main/WEEK05/WEEK05-04.md)
+
### Chapter 11: Integer Data Type
This chapter covers the integer data type in addition to a deeper assembler dive into GPIO outputs as it relates to embedded development on the Pico 2.
@@ -229,8 +239,7 @@ This chapter covers debugging constants as well as an intro to I2C as we work a
This chapter covers hacking constants as well as an intro to I2C as we work a 1602 LCD as it relates to embedded development on the Pico 2.
## Week 8
-### Midterm Project: The InfuSafe Pro Incident
-In the aftermath of a catastrophic medical device failure, you are thrust into the role of an FDA forensic investigator facing an impossible crisis: 23 patients dead, 100 million recalled insulin pumps sitting in warehouses worldwide, and 2.3 million lives hanging in the balance all while the only evidence remaining is raw binary firmware after a rogue engineer destroyed every line of source code before fleeing to Montenegro. Armed only with GDB, Ghidra, and the reverse engineering skills honed over the first seven weeks of this course, you must excavate the truth from machine code, identify the lethal bugs spawned by an AI code generator called "OopsieGPT," and determine whether these devices can be salvaged to save millions in underserved communities or if $4.7 billion in humanitarian medical technology must be incinerated. This is not a simulation; this is triage at the intersection of embedded systems security and human survival.
+### Midterm Exam
## Week 9
Operators in Embedded Systems: Debugging and Hacking Operators w/ DHT11 Temperature & Humidity Sensor Single-Wire Protocol Basics.
@@ -325,7 +334,10 @@ Unknown Firmware Debugging and Hacking
Final Review – Embedded Debugging and Hacking Techniques w/ Advanced Firmware Analysis Q&A
## Week 14
-### Final Project: Operation Dark Eclipse
+### Final Project Option 1: The InfuSafe Pro Incident
+In the aftermath of a catastrophic medical device failure, you are thrust into the role of an FDA forensic investigator facing an impossible crisis: 23 patients dead, 100 million recalled insulin pumps sitting in warehouses worldwide, and 2.3 million lives hanging in the balance all while the only evidence remaining is raw binary firmware after a rogue engineer destroyed every line of source code before fleeing to Montenegro. Armed only with GDB, Ghidra, and the reverse engineering skills honed over the first seven weeks of this course, you must excavate the truth from machine code, identify the lethal bugs spawned by an AI code generator called "OopsieGPT," and determine whether these devices can be salvaged to save millions in underserved communities or if $4.7 billion in humanitarian medical technology must be incinerated. This is not a simulation; this is triage at the intersection of embedded systems security and human survival.
+
+### Final Project Option 2: Operation Dark Eclipse
Forty-two stories beneath frozen tundra, a shadow intelligence alliance called Dark Eyes operates centrifuges enriching weapons-grade material for a first strike against Washington, D.C. and Agent NIGHTINGALE gave her life to extract the single firmware file that now sits before you. Conventional warfare cannot reach this fortress buried beneath rock and concrete, but you can: as the architect of a precision cyber weapon in the tradition of Stuxnet, you must reverse engineer the RP2350-based centrifuge controller, craft binary patches that double the spin speed while falsifying every sensor readout to show nominal operation, and execute the sabotage that will cascade-destroy their enrichment program and set their nuclear ambitions back a decade. Every skill from the entire semester ARM assembly, Ghidra analysis, IEEE-754 floating-point manipulation, branch modification, log desynchronization converges in this final mission. Agent NIGHTINGALE's seven-year-old daughter still watches the driveway, waiting for a mother who will never return. Honor that sacrifice. Complete the mission. Do not fail.
diff --git a/WEEK05/WEEK05-01.md b/WEEK05/WEEK05-01.md
new file mode 100644
index 0000000..6fd7fb8
--- /dev/null
+++ b/WEEK05/WEEK05-01.md
@@ -0,0 +1,271 @@
+# Embedded Systems Reverse Engineering
+[Repository](https://github.com/mytechnotalent/Embedded-Hacking)
+
+## Week 5
+Integers and Floats in Embedded Systems: Debugging and Hacking Integers and Floats w/ Intermediate GPIO Output Assembler Analysis
+
+### Exercise 1: Analyze the Float Binary in Ghidra
+
+#### Objective
+Import and analyze the `0x000e_floating-point-data-type.bin` binary in Ghidra to understand how the compiler handles floating-point variables, discover float-to-double promotion, and decode the IEEE 754 double-precision encoding of `42.5` from two 32-bit registers.
+
+#### Prerequisites
+- Ghidra installed and configured
+- `0x000e_floating-point-data-type.bin` binary available in your build directory
+- Understanding of IEEE 754 encoding from Week 5 Part 2
+- Basic Ghidra navigation skills from Weeks 3 and 4
+
+#### Task Description
+You will import the float binary into Ghidra, configure it for ARM Cortex-M33, resolve function names, discover that the compiler promotes `float` to `double` when passing to `printf`, and manually decode the 64-bit double `0x4045400000000000` field by field to confirm it represents `42.5`.
+
+#### Step-by-Step Instructions
+
+##### Step 1: Start Ghidra and Create New Project
+
+```bash
+ghidraRun
+```
+
+1. Click **File** → **New Project**
+2. Select **Non-Shared Project**
+3. Click **Next**
+4. Enter Project Name: `week05-ex01-floating-point`
+5. Choose a project directory
+6. Click **Finish**
+
+##### Step 2: Import the Binary
+
+1. Navigate to your file explorer
+2. Find `Embedded-Hacking/0x000e_floating-point-data-type/build/0x000e_floating-point-data-type.bin`
+3. **Drag and drop** the `.bin` file into Ghidra's project window
+
+##### Step 3: Configure Import Settings
+
+When the import dialog appears:
+
+1. Click the three dots (**…**) next to **Language**
+2. Search for: `Cortex`
+3. Select: **ARM Cortex 32 little endian default**
+4. Click **OK**
+
+Now click **Options…** button:
+1. Change **Block Name** to: `.text`
+2. Change **Base Address** to: `10000000` (XIP flash base)
+3. Click **OK**
+
+Then click **OK** on the main import dialog.
+
+##### Step 4: Analyze the Binary
+
+1. Double-click the imported file in the project window
+2. When prompted "Analyze now?" click **Yes**
+3. Leave all default analysis options selected
+4. Click **Analyze**
+5. Wait for analysis to complete (watch bottom-right progress bar)
+
+##### Step 5: Locate and Rename the Main Function
+
+Look at the **Symbol Tree** panel on the left. Expand **Functions**.
+
+From previous weeks, we know the boot sequence leads to `main()`:
+
+1. Click on `FUN_10000234`
+2. Right-click → **Edit Function Signature**
+3. Change to: `int main(void)`
+4. Click **OK**
+
+##### Step 6: Resolve stdio_init_all and printf
+
+**Rename stdio_init_all:**
+1. Click on `FUN_10002f5c` in the decompile window
+2. Right-click → **Edit Function Signature**
+3. Change to: `bool stdio_init_all(void)`
+4. Click **OK**
+
+**Rename printf:**
+1. Click on `FUN_100030ec`
+2. Right-click → **Edit Function Signature**
+3. Change to: `int __wrap_printf(char *format,...)`
+4. Check the **Varargs** checkbox
+5. Click **OK**
+
+##### Step 7: Observe the Decompiled Code
+
+After resolving, the decompiled `main` should look like:
+
+```c
+int main(void)
+{
+ undefined4 uVar1;
+ undefined4 extraout_r1;
+ undefined4 uVar2;
+ undefined4 extraout_r1_00;
+
+ stdio_init_all();
+ uVar1 = DAT_1000024c;
+ uVar2 = extraout_r1;
+ do {
+ __wrap_printf(DAT_10000250,uVar2,0,uVar1);
+ uVar2 = extraout_r1_00;
+ } while( true );
+}
+```
+
+**Critical observation:** Where is `float fav_num = 42.5`? The compiler optimized it into constants!
+
+##### Step 8: Identify the Register Pair
+
+Look at the **Listing** window (assembly view) for `main`:
+
+```assembly
+1000023a 00 24 movs r4, #0x0
+1000023c 03 4d ldr r5, [DAT_1000024c] = 40454000h
+```
+
+Two values are being passed to `printf`:
+- `r2 = 0x00000000` (low 32 bits)
+- `r3 = 0x40454000` (high 32 bits)
+
+Together they form a 64-bit double: `0x4045400000000000`
+
+**Why a double?** The C standard requires that `float` arguments to variadic functions like `printf` are **promoted to `double`**. So even though our variable is declared as `float fav_num = 42.5`, `printf` always receives a 64-bit double.
+
+##### Step 9: Write Out the Binary Layout
+
+Convert both registers to binary:
+
+```
+r3 (high 32 bits): 0x40454000 = 0100 0000 0100 0101 0100 0000 0000 0000
+r2 (low 32 bits): 0x00000000 = 0000 0000 0000 0000 0000 0000 0000 0000
+```
+
+Map the 64-bit IEEE 754 fields:
+
+```
+Bit 63 (sign): 0
+Bits 62–52 (exponent): 10000000100
+Bits 51–0 (mantissa): 0101010000000000...0000
+```
+
+##### Step 10: Decode the Sign Bit
+
+Bit 63 of the double = bit 31 of r3:
+
+```
+r3 = 0x40454000 = 0100 0000 0100 0101 0100 0000 0000 0000
+ ^
+ bit 31 = 0 → Positive number
+```
+
+IEEE 754 sign rule: `0` = Positive, `1` = Negative.
+
+##### Step 11: Decode the Exponent
+
+Extract bits 30–20 from r3:
+
+```
+0x40454000: 0 10000000100 01010100000000000000
+ ^ ^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^
+ sign exponent mantissa (top 20)
+```
+
+Exponent bits: `10000000100` = 2¹⁰ + 2² = 1024 + 4 = **1028**
+
+Subtract the double-precision bias (1023):
+
+$$\text{real exponent} = 1028 - 1023 = \mathbf{5}$$
+
+##### Step 12: Decode the Mantissa
+
+High 20 bits of mantissa (from r3 bits 19–0):
+```
+0 1 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
+```
+
+Low 32 bits of mantissa (from r2):
+```
+0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
+```
+
+With the implied leading `1`:
+```
+1.010101 00000...
+```
+
+##### Step 13: Reconstruct the Final Value
+
+$$1.010101_2 \times 2^5 = 101010.1_2$$
+
+Convert to decimal:
+
+| Bit | Power | Value |
+|-----|-------|-------|
+| 1 | 2⁵ | 32 |
+| 0 | 2⁴ | 0 |
+| 1 | 2³ | 8 |
+| 0 | 2² | 0 |
+| 1 | 2¹ | 2 |
+| 0 | 2⁰ | 0 |
+| 1 | 2⁻¹ | 0.5 |
+
+$$32 + 8 + 2 + 0.5 = \mathbf{42.5} ✓$$
+
+##### Step 14: Find the Format String
+
+In the Listing view, click on the data reference to locate:
+
+```
+s_fav_num:_%f_100034a8 ds "fav_num: %f\r\n"
+```
+
+Note that the format specifier is `%f`, confirming this is a floating-point print call.
+
+##### Step 15: Document Your Findings
+
+Create a table of your observations:
+
+| Item | Value | Notes |
+| ------------------------- | ------------------ | ---------------------------------- |
+| Main function address | `0x10000234` | Entry point of program |
+| Float value (original) | `42.5` | Declared as `float` |
+| Double hex encoding | `0x4045400000000000` | Promoted to double for printf |
+| r3 (high word) | `0x40454000` | Contains sign + exponent + mantissa top bits |
+| r2 (low word) | `0x00000000` | All zeros — clean fractional part |
+| Exponent (stored) | 1028 | Biased value |
+| Exponent (real) | 5 | After subtracting bias 1023 |
+| Format string | `"fav_num: %f\r\n"` | Located at `0x100034a8` |
+| Float-to-double promotion | Yes | C standard for variadic functions |
+
+#### Expected Output
+
+After completing this exercise, you should be able to:
+- Import and configure ARM binaries in Ghidra for float analysis
+- Explain why `printf` receives a `double` even when the variable is a `float`
+- Identify the register pair `r2:r3` that holds a 64-bit double
+- Manually decode an IEEE 754 double from hex to decimal
+- Locate format strings in the binary
+
+#### Questions for Reflection
+
+###### Question 1: Why does the compiler promote a `float` to a `double` when passing it to `printf`?
+
+###### Question 2: The low word (`r2`) is `0x00000000`. What does this tell you about the fractional part of `42.5`?
+
+###### Question 3: What is the purpose of the exponent bias (1023) in IEEE 754 double-precision?
+
+###### Question 4: If the sign bit (bit 63) were `1` instead of `0`, what value would the double represent?
+
+#### Tips and Hints
+- The **Listing** window shows raw assembly; the **Decompile** window shows reconstructed C
+- Double-click on a `DAT_` reference to jump to the data constant
+- Use Python to verify: `import struct; struct.pack('>d', 42.5).hex()` gives `4045400000000000`
+- Remember: r3 = high 32 bits (sign + exponent + top mantissa), r2 = low 32 bits (bottom mantissa)
+- The bias for doubles is always 1023; for floats it's 127
+
+#### Next Steps
+- Proceed to Exercise 2 to patch this float value in Ghidra
+- Try computing the IEEE 754 encoding of other values like `3.14` or `100.0` by hand
+- Compare the 32-bit float encoding `0x422A0000` with the 64-bit double encoding `0x4045400000000000` — both represent `42.5`
+
+#### Additional Challenge
+Find the data constant `DAT_1000024c` in the Listing view. What raw bytes are stored there? Remember that ARM is little-endian — the bytes in memory are in reverse order. Write out the byte order as it appears in memory vs. as a 32-bit value.
diff --git a/WEEK05/WEEK05-02.md b/WEEK05/WEEK05-02.md
new file mode 100644
index 0000000..5e23479
--- /dev/null
+++ b/WEEK05/WEEK05-02.md
@@ -0,0 +1,173 @@
+# Embedded Systems Reverse Engineering
+[Repository](https://github.com/mytechnotalent/Embedded-Hacking)
+
+## Week 5
+Integers and Floats in Embedded Systems: Debugging and Hacking Integers and Floats w/ Intermediate GPIO Output Assembler Analysis
+
+### Exercise 2: Patch the Float Binary — Changing 42.5 to 99.0
+
+#### Objective
+Calculate the IEEE 754 double-precision encoding of `99.0`, patch the float binary in Ghidra to change the printed value from `42.5` to `99.0`, export the patched binary, convert it to UF2 format, and flash it to the Pico 2 to verify the change.
+
+#### Prerequisites
+- Completed Exercise 1 (float binary imported and analyzed in Ghidra)
+- Understanding of IEEE 754 double-precision encoding from Week 5 Part 2.7
+- Python installed for UF2 conversion
+- `uf2conv.py` script available in your project directory
+- Raspberry Pi Pico 2 connected via USB
+- Serial monitor software (PuTTY, minicom, or screen)
+
+#### Task Description
+You will convert `99.0` to its IEEE 754 double-precision encoding by hand (integer-to-binary conversion, normalization, field extraction), determine which register words need to change, patch the data constant in Ghidra, and verify on hardware that the serial output now prints `99.000000`.
+
+#### Step-by-Step Instructions
+
+##### Step 1: Convert 99 to Binary
+
+Use repeated division by 2:
+
+| Division | Quotient | Remainder |
+|----------|----------|-----------|
+| 99 ÷ 2 | 49 | **1** |
+| 49 ÷ 2 | 24 | **1** |
+| 24 ÷ 2 | 12 | **0** |
+| 12 ÷ 2 | 6 | **0** |
+| 6 ÷ 2 | 3 | **0** |
+| 3 ÷ 2 | 1 | **1** |
+| 1 ÷ 2 | 0 | **1** |
+
+Read remainders bottom-to-top: $99_{10} = 1100011_2$
+
+##### Step 2: Handle the Fractional Part
+
+The fractional part of `99.0` is `.0` — exactly zero. There are no fractional bits.
+
+$$99.0_{10} = 1100011.0_2$$
+
+##### Step 3: Normalize to IEEE 754 Form
+
+Move the binary point so there is exactly one `1` before it:
+
+$$1100011.0_2 = 1.100011_2 \times 2^6$$
+
+We shifted the binary point 6 places left, so the exponent is **6**.
+
+##### Step 4: Extract the IEEE 754 Fields
+
+1. **Sign:** `0` (positive)
+2. **Exponent:** $6 + 1023 = 1029 = 10000000101_2$
+3. **Mantissa:** `100011` followed by 46 zeros (everything after the `1.`, padded to 52 bits)
+4. **Full double:** `0x4058C00000000000`
+
+Split into register words:
+- **r3 (high word):** `0x4058C000`
+- **r2 (low word):** `0x00000000`
+
+##### Step 5: Determine What to Patch
+
+Compare old vs. new:
+
+| Register | Old Value | New Value | Changed? |
+| -------- | ------------ | ------------ | -------- |
+| `r2` | `0x00000000` | `0x00000000` | No |
+| `r3` | `0x40454000` | `0x4058C000` | **Yes** |
+
+Since `r2` stays all zeros, we only need to patch the high word in `r3`.
+
+##### Step 6: Locate the Data Constant in Ghidra
+
+Open your Ghidra project from Exercise 1. In the Listing view, find the data constant that loads into `r3`:
+
+```
+ DAT_1000024c
+10000248 00 40 45 40 undefined4 40454000h
+```
+
+This is the 32-bit constant `0x40454000` — the high word of the double `42.5`.
+
+##### Step 7: Patch the Constant
+
+1. Click on **Window** → **Bytes** to open the Bytes Editor
+2. Click the **Pencil Icon** to enable editing
+3. Navigate to the data at `DAT_1000024c`
+4. The bytes in memory (little-endian) read: `00 40 45 40`
+5. Change them to: `00 C0 58 40` (which is `0x4058C000` in little-endian)
+6. Press **Enter**
+
+**Verify** in the Listing view — the data should now show `4058C000h`.
+
+##### Step 8: Verify the Patch in the Decompile Window
+
+The decompiled code should now reference the new constant. The value loaded into `r3` should be `0x4058C000`.
+
+##### Step 9: Export the Patched Binary
+
+1. Click **File** → **Export Program**
+2. Set **Format** to **Raw Bytes**
+3. Navigate to your build directory
+4. Name the file: `0x000e_floating-point-data-type-h.bin`
+5. Click **OK**
+
+##### Step 10: Convert to UF2 Format
+
+Open a terminal and navigate to your project directory:
+
+```powershell
+cd Embedded-Hacking-main\0x000e_floating-point-data-type
+```
+
+Run the conversion:
+
+```powershell
+python ..\uf2conv.py build\0x000e_floating-point-data-type-h.bin --base 0x10000000 --family 0xe48bff59 --output build\hacked.uf2
+```
+
+##### Step 11: Flash and Verify
+
+1. Hold **BOOTSEL** and plug in your Pico 2
+2. Drag and drop `hacked.uf2` onto the RPI-RP2 drive
+3. Open your serial monitor
+
+**Expected output:**
+
+```
+fav_num: 99.000000
+fav_num: 99.000000
+fav_num: 99.000000
+...
+```
+
+🎉 **Success!** The value changed from `42.5` to `99.0`!
+
+#### Expected Output
+
+After completing this exercise, you should:
+- See `fav_num: 99.000000` printing instead of `fav_num: 42.500000`
+- Have a patched binary file (`0x000e_floating-point-data-type-h.bin`)
+- Have a UF2 file (`hacked.uf2`)
+- Understand the complete IEEE 754 encoding and patching workflow for floats
+
+#### Questions for Reflection
+
+###### Question 1: Why did we only need to patch r3 (the high word) and not r2 (the low word)?
+
+###### Question 2: What would the high word be if we wanted to patch the value to `-99.0` instead? (Hint: which bit controls the sign?)
+
+###### Question 3: Walk through the encoding of `100.0` as a double. What are the high and low words?
+
+###### Question 4: Why do we need the `--family 0xe48bff59` flag when converting to UF2?
+
+#### Tips and Hints
+- Always verify your encoding with Python: `import struct; struct.pack('>d', 99.0).hex()`
+- Little-endian means the bytes in memory are reversed: `0x4058C000` is stored as `00 C0 58 40`
+- If you patch the wrong bytes, use **File** → **Undo** in Ghidra (or re-import the original binary)
+- The bias for double-precision is always 1023; for single-precision it's 127
+- A clean fractional part (like `.0` or `.5`) means the low word (`r2`) is all zeros
+
+#### Next Steps
+- Proceed to Exercise 3 to analyze the double-precision binary
+- Try patching to different values: `3.14`, `100.0`, `255.0`
+- Compare how many register words change for clean vs. messy fractions
+
+#### Additional Challenge
+Patch the float to `3.14` instead of `99.0`. Since `3.14` has a repeating binary fraction, the low word will **not** be zero. This means you need to modify the assembly to load a non-zero value into `r2` as well. Can you figure out where `r2` gets its zero value (`movs r4, #0x0`) and change it?
diff --git a/WEEK05/WEEK05-03.md b/WEEK05/WEEK05-03.md
new file mode 100644
index 0000000..3824411
--- /dev/null
+++ b/WEEK05/WEEK05-03.md
@@ -0,0 +1,277 @@
+# Embedded Systems Reverse Engineering
+[Repository](https://github.com/mytechnotalent/Embedded-Hacking)
+
+## Week 5
+Integers and Floats in Embedded Systems: Debugging and Hacking Integers and Floats w/ Intermediate GPIO Output Assembler Analysis
+
+### Exercise 3: Analyze the Double Binary in Ghidra
+
+#### Objective
+Import and analyze the `0x0011_double-floating-point-data-type.bin` binary in Ghidra to understand how doubles differ from floats at the binary level, observe that **both** register words carry non-zero data when the fractional part is complex, and decode the IEEE 754 double-precision encoding of `42.52525` from two 32-bit registers.
+
+#### Prerequisites
+- Completed Exercises 1 and 2 (float analysis and patching)
+- Understanding of IEEE 754 double-precision format from Week 5 Part 3
+- Understanding of register pairs (`r2:r3`) from Exercise 1
+- Basic Ghidra navigation skills
+
+#### Task Description
+You will import the double binary into Ghidra, resolve function names, identify that `42.52525` requires non-zero data in **both** r2 and r3 (unlike `42.5` which had r2 = 0), and decode the full 64-bit double `0x4045433B645A1CAC` field by field to confirm it represents `42.52525`.
+
+#### Step-by-Step Instructions
+
+##### Step 1: Flash the Original Binary
+
+Before analysis, verify the program works:
+
+1. Hold **BOOTSEL** and plug in your Pico 2
+2. Flash `0x0011_double-floating-point-data-type.uf2` to the RPI-RP2 drive
+3. Open your serial monitor
+
+**Expected output:**
+```
+fav_num: 42.525250
+fav_num: 42.525250
+fav_num: 42.525250
+...
+```
+
+##### Step 2: Create a New Ghidra Project
+
+1. Launch Ghidra: `ghidraRun`
+2. Click **File** → **New Project**
+3. Select **Non-Shared Project**
+4. Project Name: `week05-ex03-double-analysis`
+5. Click **Finish**
+
+##### Step 3: Import and Configure the Binary
+
+1. Drag and drop `0x0011_double-floating-point-data-type.bin` into Ghidra
+2. Set Language: **ARM Cortex 32 little endian default**
+3. Click **Options…**
+ - Block Name: `.text`
+ - Base Address: `10000000`
+4. Click **OK** on all dialogs
+5. Double-click the file and click **Yes** to analyze
+
+##### Step 4: Locate and Rename Functions
+
+Identify the main function and standard library calls:
+
+**Rename main:**
+1. Click on `FUN_10000238`
+2. Right-click → **Edit Function Signature**
+3. Change to: `int main(void)`
+4. Click **OK**
+
+**Rename stdio_init_all:**
+1. Click on `FUN_10002f64`
+2. Right-click → **Edit Function Signature**
+3. Change to: `bool stdio_init_all(void)`
+4. Click **OK**
+
+**Rename printf:**
+1. Click on `FUN_100030f4`
+2. Right-click → **Edit Function Signature**
+3. Change to: `int printf(char *format,...)`
+4. Check the **Varargs** checkbox
+5. Click **OK**
+
+##### Step 5: Observe the Decompiled Code
+
+After renaming, the decompiled `main` should look like:
+
+```c
+int main(void)
+{
+ undefined4 uVar1;
+ undefined4 uVar2;
+ undefined4 extraout_r1;
+ undefined4 uVar3;
+ undefined4 extraout_r1_00;
+
+ uVar2 = DAT_10000258;
+ uVar1 = DAT_10000254;
+ stdio_init_all();
+ uVar3 = extraout_r1;
+ do {
+ printf(DAT_10000250,uVar3,uVar1,uVar2);
+ uVar3 = extraout_r1_00;
+ } while( true );
+}
+```
+
+**Critical observation:** There are now **two** non-zero data constants — `DAT_10000254` and `DAT_10000258`. This is the key difference from the float exercise!
+
+##### Step 6: Examine the Assembly Listing
+
+Click on the **Listing** window and find the main function assembly:
+
+```assembly
+10000238 push {r3,r4,r5,lr}
+1000023a adr r5, [0x10000254]
+1000023c ldrd r4, r5, [r5, #0x0] = 645A1CACh / 4045433Bh
+10000240 bl stdio_init_all
+```
+
+**Key instruction: `ldrd r4, r5, [r5, #0x0]`**
+
+This is a **load register double** instruction — it loads two consecutive 32-bit words in a single instruction:
+- `r4` gets the low word: `0x645A1CAC`
+- `r5` gets the high word: `0x4045433B`
+
+Later in the loop:
+```assembly
+10000244 mov r2, r4 ; r2 = 0x645A1CAC (low)
+10000246 mov r3, r5 ; r3 = 0x4045433B (high)
+```
+
+##### Step 7: Identify the Register Pair
+
+| Register | Value | Role |
+| -------- | ------------ | ------------ |
+| `r2` | `0x645A1CAC` | Low 32 bits |
+| `r3` | `0x4045433B` | High 32 bits |
+
+Together: `0x4045433B645A1CAC`
+
+**Compare to the float exercise:**
+- Float `42.5`: r2 = `0x00000000`, r3 = `0x40454000` — low word is all zeros
+- Double `42.52525`: r2 = `0x645A1CAC`, r3 = `0x4045433B` — **both words are non-zero!**
+
+This happens because `42.52525` has a repeating binary fraction that needs all 52 mantissa bits.
+
+##### Step 8: Decode the Sign Bit
+
+Convert r3 to binary and check bit 31:
+
+```
+r3 = 0x4045433B = 0100 0000 0100 0101 0100 0011 0011 1011
+ ^
+ bit 31 = 0 → Positive number ✓
+```
+
+##### Step 9: Decode the Exponent
+
+Extract bits 30–20 from r3:
+
+```
+0x4045433B: 0 10000000100 01010100001100111011
+ ^ ^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^
+ sign exponent mantissa (top 20)
+```
+
+Exponent bits: `10000000100` = 2¹⁰ + 2² = 1024 + 4 = **1028**
+
+$$\text{real exponent} = 1028 - 1023 = \mathbf{5}$$
+
+##### Step 10: Decode the Mantissa
+
+**High 20 bits** (r3 bits 19–0):
+```
+0 1 0 1 0 1 0 0 0 0 1 1 0 0 1 1 1 0 1 1
+```
+
+**Low 32 bits** (all of r2 = `0x645A1CAC`):
+```
+0 1 1 0 0 1 0 0 0 1 0 1 1 0 1 0 0 0 0 1 1 1 0 0 1 0 1 0 1 1 0 0
+```
+
+With the implied leading `1`:
+```
+1.0101010000110011101101100100010110100001110010101100
+```
+
+##### Step 11: Reconstruct the Integer Part
+
+$$1.0101010000110011..._2 \times 2^5$$
+
+Shift the binary point 5 places right → `101010.1000011001110110...`
+
+Integer part `101010`:
+
+| Bit | Power | Value |
+|-----|-------|-------|
+| 1 | 2⁵ | 32 |
+| 0 | 2⁴ | 0 |
+| 1 | 2³ | 8 |
+| 0 | 2² | 0 |
+| 1 | 2¹ | 2 |
+| 0 | 2⁰ | 0 |
+
+$$32 + 8 + 2 = \mathbf{42}$$
+
+##### Step 12: Approximate the Fractional Part
+
+The first few fractional bits `.10000110011...`:
+
+| Bit | Power | Decimal |
+|------|--------|---------------|
+| 1 | 2⁻¹ | 0.5 |
+| 0 | 2⁻² | 0 |
+| 0 | 2⁻³ | 0 |
+| 0 | 2⁻⁴ | 0 |
+| 0 | 2⁻⁵ | 0 |
+| 1 | 2⁻⁶ | 0.015625 |
+| 1 | 2⁻⁷ | 0.0078125 |
+| 0 | 2⁻⁸ | 0 |
+| 0 | 2⁻⁹ | 0 |
+| 1 | 2⁻¹⁰ | 0.0009765625 |
+| 1 | 2⁻¹¹ | 0.00048828125 |
+
+First 11 bits sum ≈ 0.5249. The remaining 36 fractional bits refine this to ≈ 0.52525.
+
+$$42 + 0.52525 = \mathbf{42.52525} ✓$$
+
+##### Step 13: Find the Format String
+
+In the Listing view, locate:
+
+```
+s_fav_num:_%lf_100034b0 ds "fav_num: %lf\r\n"
+```
+
+Note the `%lf` format specifier — this program explicitly uses `double`, unlike the float program which used `%f`.
+
+##### Step 14: Document Your Findings
+
+| Item | Float (`42.5`) | Double (`42.52525`) |
+| ------------------------- | -------------------- | ------------------------ |
+| r2 (low word) | `0x00000000` | `0x645A1CAC` |
+| r3 (high word) | `0x40454000` | `0x4045433B` |
+| Low word is zero? | Yes | **No** |
+| Words to patch | 1 (r3 only) | **2 (both r2 and r3)** |
+| Format specifier | `%f` | `%lf` |
+| Assembly load instruction | `movs` + `ldr` | `ldrd` (load double) |
+
+#### Expected Output
+
+After completing this exercise, you should understand:
+- How the compiler loads a 64-bit double using `ldrd` (load register double)
+- Why `42.52525` requires non-zero data in both registers while `42.5` does not
+- How to decode a complex IEEE 754 double with a repeating binary fraction
+- The differences between float and double handling at the assembly level
+
+#### Questions for Reflection
+
+###### Question 1: Why does `42.5` have a zero low word but `42.52525` does not?
+
+###### Question 2: The assembly uses `ldrd r4, r5, [r5, #0x0]` instead of two separate `ldr` instructions. What is the advantage?
+
+###### Question 3: Both the float and double programs have the same exponent (stored as 1028, real exponent 5). Why?
+
+###### Question 4: If you were patching this double, how many data constants would you need to modify compared to the float exercise?
+
+#### Tips and Hints
+- Use Python to verify: `import struct; struct.pack('>d', 42.52525).hex()` gives `4045433b645a1cac`
+- The `ldrd` instruction always loads the lower-addressed word into the first register
+- A repeating binary fraction (like `0.52525`) can never be represented exactly — double precision uses the closest 52-bit approximation
+- Compare data addresses: the float binary has one `DAT_` constant; the double binary has two consecutive ones
+
+#### Next Steps
+- Proceed to Exercise 4 to patch both register words
+- Compare the mantissa of `42.5` (clean: `010101 000...`) vs. `42.52525` (complex: `0101010000110011...`)
+- Think about what values would have a zero low word (hint: powers of 2, halves, quarters)
+
+#### Additional Challenge
+Using the 52-bit mantissa `0101010000110011101101100100010110100001110010101100`, manually sum the first 20 fractional bits to see how close you get to `0.52525`. How many bits of precision does it take to get within 0.001 of the true value?
diff --git a/WEEK05/WEEK05-04.md b/WEEK05/WEEK05-04.md
new file mode 100644
index 0000000..042b019
--- /dev/null
+++ b/WEEK05/WEEK05-04.md
@@ -0,0 +1,217 @@
+# Embedded Systems Reverse Engineering
+[Repository](https://github.com/mytechnotalent/Embedded-Hacking)
+
+## Week 5
+Integers and Floats in Embedded Systems: Debugging and Hacking Integers and Floats w/ Intermediate GPIO Output Assembler Analysis
+
+### Exercise 4: Patch the Double Binary — Changing 42.52525 to 99.99
+
+#### Objective
+Calculate the IEEE 754 double-precision encoding of `99.99`, patch **both** register words in the double binary in Ghidra, export the patched binary, convert it to UF2 format, and flash it to the Pico 2 to verify the change.
+
+#### Prerequisites
+- Completed Exercise 3 (double binary imported and analyzed in Ghidra)
+- Understanding of IEEE 754 double-precision encoding from Week 5 Parts 2.7 and 3.7
+- Knowledge of integer-to-binary conversion and the multiply-by-2 method for fractions
+- Python installed for UF2 conversion and verification
+- Raspberry Pi Pico 2 connected via USB
+
+#### Task Description
+You will derive the IEEE 754 encoding of `99.99` step by step (integer part, fractional part, normalization, field extraction), patch both the low word and high word data constants in Ghidra, and verify on hardware that the serial output now prints `99.990000`. Unlike Exercise 2 where only one word changed, this exercise requires patching **both** registers.
+
+#### Step-by-Step Instructions
+
+##### Step 1: Convert the Integer Part (99) to Binary
+
+Use repeated division by 2:
+
+| Division | Quotient | Remainder |
+|----------|----------|-----------|
+| 99 ÷ 2 | 49 | **1** |
+| 49 ÷ 2 | 24 | **1** |
+| 24 ÷ 2 | 12 | **0** |
+| 12 ÷ 2 | 6 | **0** |
+| 6 ÷ 2 | 3 | **0** |
+| 3 ÷ 2 | 1 | **1** |
+| 1 ÷ 2 | 0 | **1** |
+
+Read remainders bottom-to-top: $99_{10} = 1100011_2$
+
+##### Step 2: Convert the Fractional Part (.99) to Binary
+
+Use the multiply-by-2 method:
+
+| Multiply | Result | Integer part | Remaining fraction |
+|----------------|--------|--------------|-------------------|
+| 0.99 × 2 | 1.98 | **1** | 0.98 |
+| 0.98 × 2 | 1.96 | **1** | 0.96 |
+| 0.96 × 2 | 1.92 | **1** | 0.92 |
+| 0.92 × 2 | 1.84 | **1** | 0.84 |
+| 0.84 × 2 | 1.68 | **1** | 0.68 |
+| 0.68 × 2 | 1.36 | **1** | 0.36 |
+| 0.36 × 2 | 0.72 | **0** | 0.72 |
+| 0.72 × 2 | 1.44 | **1** | 0.44 |
+| 0.44 × 2 | 0.88 | **0** | 0.88 |
+| 0.88 × 2 | 1.76 | **1** | 0.76 |
+| 0.76 × 2 | 1.52 | **1** | 0.52 |
+| 0.52 × 2 | 1.04 | **1** | 0.04 |
+| ... | ... | ... | *(continues — repeating fraction)* |
+
+Reading the integer parts top-to-bottom: $0.99_{10} \approx 0.111111010111..._2$
+
+This is a **repeating fraction** — it never terminates in binary.
+
+##### Step 3: Combine Integer and Fractional Parts
+
+$$99.99_{10} = 1100011.111111010111..._2$$
+
+##### Step 4: Normalize to IEEE 754 Form
+
+Move the binary point so there is exactly one `1` before it:
+
+$$1100011.111111010111..._2 = 1.100011111111010111..._2 \times 2^6$$
+
+We shifted the binary point 6 places left, so the exponent is **6**.
+
+##### Step 5: Extract the IEEE 754 Fields
+
+1. **Sign:** `0` (positive)
+2. **Exponent:** $6 + 1023 = 1029 = 10000000101_2$
+3. **Mantissa:** `1000111111110101110000101000111101011100001010001111...` (52 bits after the `1.`)
+4. **Full double:** `0x4058FF5C28F5C28F`
+
+**Verify with Python:**
+```python
+>>> import struct
+>>> struct.pack('>d', 99.99).hex()
+'4058ff5c28f5c28f'
+```
+
+##### Step 6: Split into Register Words
+
+| Register | Old Value | New Value | Changed? |
+| -------- | ------------ | ------------ | -------- |
+| `r2` | `0x645A1CAC` | `0x28F5C28F` | **Yes** |
+| `r3` | `0x4045433B` | `0x4058FF5C` | **Yes** |
+
+**Both registers change!** This is the key difference from Exercise 2 where only r3 changed.
+
+##### Step 7: Locate the Data Constants in Ghidra
+
+Open your Ghidra project from Exercise 3. In the Listing view, find the two data constants:
+
+**Low word (loaded into r2):**
+```
+ DAT_10000254
+10000254 ac 1c 5a 64 undefined4 645A1CACh
+```
+
+**High word (loaded into r3):**
+```
+ DAT_10000258
+10000258 3b 43 45 40 undefined4 4045433Bh
+```
+
+##### Step 8: Patch the Low Word
+
+1. Click on **Window** → **Bytes** to open the Bytes Editor
+2. Click the **Pencil Icon** to enable editing
+3. Navigate to address `10000254`
+4. The bytes read: `AC 1C 5A 64` (little-endian for `0x645A1CAC`)
+5. Change to: `8F C2 F5 28` (little-endian for `0x28F5C28F`)
+6. Press **Enter**
+
+##### Step 9: Patch the High Word
+
+1. Navigate to address `10000258`
+2. The bytes read: `3B 43 45 40` (little-endian for `0x4045433B`)
+3. Change to: `5C FF 58 40` (little-endian for `0x4058FF5C`)
+4. Press **Enter**
+
+**Verify** in the Listing view:
+- `DAT_10000254` should show `28F5C28Fh`
+- `DAT_10000258` should show `4058FF5Ch`
+
+Together: `0x4058FF5C28F5C28F` = `99.99` as a double ✓
+
+##### Step 10: Export the Patched Binary
+
+1. Click **File** → **Export Program**
+2. Set **Format** to **Raw Bytes**
+3. Navigate to your build directory
+4. Name the file: `0x0011_double-floating-point-data-type-h.bin`
+5. Click **OK**
+
+##### Step 11: Convert to UF2 Format
+
+Open a terminal:
+
+```powershell
+cd Embedded-Hacking-main\0x0011_double-floating-point-data-type
+```
+
+```powershell
+python ..\uf2conv.py build\0x0011_double-floating-point-data-type-h.bin --base 0x10000000 --family 0xe48bff59 --output build\hacked.uf2
+```
+
+##### Step 12: Flash and Verify
+
+1. Hold **BOOTSEL** and plug in your Pico 2
+2. Drag and drop `hacked.uf2` onto the RPI-RP2 drive
+3. Open your serial monitor
+
+**Expected output:**
+
+```
+fav_num: 99.990000
+fav_num: 99.990000
+fav_num: 99.990000
+...
+```
+
+🎉 **Success!** The value changed from `42.52525` to `99.99`!
+
+#### Expected Output
+
+After completing this exercise, you should:
+- See `fav_num: 99.990000` printing instead of `fav_num: 42.525250`
+- Have a patched binary file (`0x0011_double-floating-point-data-type-h.bin`)
+- Have a UF2 file (`hacked.uf2`)
+- Understand that patching doubles with repeating fractions requires modifying **both** register words
+
+#### Questions for Reflection
+
+###### Question 1: Why did both r2 and r3 change when patching 42.52525 → 99.99, but only r3 changed when patching 42.5 → 99.0?
+
+###### Question 2: The multiply-by-2 method for 0.99 produces a repeating pattern. What does this mean for the precision of the stored value?
+
+###### Question 3: If you wanted to patch the double to `100.0` instead of `99.99`, how many data constants would need to change?
+
+###### Question 4: Compare the Ghidra Listing for the float binary (Exercise 1) and the double binary (Exercise 3). How does the compiler load the double differently?
+
+#### Tips and Hints
+- Always verify your encoding with Python before patching
+- Little-endian byte order: `0x28F5C28F` is stored as `8F C2 F5 28` in memory
+- Use Ghidra's **Bytes** window (Window → Bytes) for precise hex editing
+- If `r2` was zero before and needs to be non-zero after, you need to patch the data constant — not the `movs r4, #0x0` instruction
+- The `ldrd` instruction loads r4 and r5 from two consecutive memory addresses — both must be correct
+
+#### Next Steps
+- Review the complete patching workflow diagram in Week 5 Part 3.95
+- Try patching to `100.0` — since it has a zero low word, you'll need to change `r2` from non-zero to zero
+- Attempt the practice exercises at the end of Week 5
+
+#### Additional Challenge
+Patch the double to `3.14159265358979` (pi). This requires extreme precision in all 52 mantissa bits. Use Python to get the exact encoding, then patch both words. Verify the output prints at least 6 correct decimal places. What happens to the precision if you only patch the high word and leave the low word as `0x645A1CAC`?
+
+#### Verification Checklist
+
+Before moving on, confirm:
+- [ ] Serial output shows `fav_num: 99.990000`
+- [ ] Both data constants were patched (low word and high word)
+- [ ] You can derive the IEEE 754 encoding of `99.99` from scratch
+- [ ] You understand why messy fractions require patching both register words
+- [ ] You can explain the difference between the float and double patching workflows
+- [ ] You successfully converted and flashed the UF2
+
+**Congratulations!** You've completed all Week 5 exercises and mastered floating-point analysis, IEEE 754 decoding, and double-precision binary patching!
diff --git a/WEEK05/WEEK05.md b/WEEK05/WEEK05.md
new file mode 100644
index 0000000..2405fbe
--- /dev/null
+++ b/WEEK05/WEEK05.md
@@ -0,0 +1,1417 @@
+# Embedded Systems Reverse Engineering
+[Repository](https://github.com/mytechnotalent/Embedded-Hacking)
+
+## Week 5
+Integers and Floats in Embedded Systems: Debugging and Hacking Integers and Floats w/ Intermediate GPIO Output Assembler Analysis
+
+### 🎯 What You'll Learn This Week
+
+By the end of this tutorial, you will be able to:
+- Understand how integers and floating-point numbers are stored in memory
+- Know the difference between signed and unsigned integers (`uint8_t` vs `int8_t`)
+- Understand how floats and doubles are represented using IEEE 754 encoding
+- Use inline assembly to control GPIO pins directly at the hardware level
+- Debug numeric data types using GDB and the OpenOCD debugger
+- Hack integer values by modifying registers at runtime
+- Hack floating-point values by understanding and manipulating their binary representation
+- Reconstruct 64-bit doubles from two 32-bit registers
+---
+
+## 📚 Part 1: Understanding Integer Data Types
+
+### What is an Integer?
+
+An **integer** is a whole number without any decimal point. Think of it like counting apples: you can have 0 apples, 1 apple, 42 apples, but you can't have 3.5 apples (that would be a fraction!).
+
+In C programming for embedded systems, we have special integer types that tell the compiler exactly how much memory to use:
+
+```
+┌─────────────────────────────────────────────────────────────────┐
+│ Integer Types - Different Sizes for Different Needs │
+│ │
+│ uint8_t: 1 byte (0 to 255) - like a small box │
+│ int8_t: 1 byte (-128 to 127) - can hold negatives! │
+│ uint16_t: 2 bytes (0 to 65,535) - medium box │
+│ uint32_t: 4 bytes (0 to 4 billion) - big box │
+│ │
+└─────────────────────────────────────────────────────────────────┘
+```
+
+### Signed vs Unsigned Integers
+
+The difference between `uint8_t` and `int8_t` is whether the number can be **negative**:
+
+| Type | Prefix | Range | Use Case |
+| --------- | ------ | ----------- | ----------------------------- |
+| `uint8_t` | `u` | 0 to 255 | Ages, counts, always positive |
+| `int8_t` | none | -128 to 127 | Temperature, can be negative |
+
+Let's review the code in `0x000b_integer-data-type`.
+
+```assembly
+#include
+#include "pico/stdlib.h"
+
+int main(void) {
+ uint8_t age = 43;
+ int8_t range = -42;
+
+ stdio_init_all();
+
+ __asm volatile (
+ "ldr r3, =0x40038000\n" // address of PADS_BANK0_BASE
+ "ldr r2, =0x40028004\n" // address of IO_BANK0 GPIO0.ctrl
+ "movs r0, #16\n" // GPIO16 (start pin)
+
+ "init_loop:\n" // loop start
+ "lsls r1, r0, #2\n" // pin * 4 (pad offset)
+ "adds r4, r3, r1\n" // PADS base + offset
+ "ldr r5, [r4]\n" // load current config
+ "bic r5, r5, #0x180\n" // clear OD+ISO
+ "orr r5, r5, #0x40\n" // set IE
+ "str r5, [r4]\n" // store updated config
+
+ "lsls r1, r0, #3\n" // pin * 8 (ctrl offset)
+ "adds r4, r2, r1\n" // IO_BANK0 base + offset
+ "ldr r5, [r4]\n" // load current config
+ "bic r5, r5, #0x1f\n" // clear FUNCSEL bits [4:0]
+ "orr r5, r5, #5\n" // set FUNCSEL = 5 (SIO)
+ "str r5, [r4]\n" // store updated config
+
+ "mov r4, r0\n" // pin
+ "movs r5, #1\n" // bit 1; used for OUT/OE writes
+ "mcrr p0, #4, r4, r5, c4\n" // gpioc_bit_oe_put(pin,1)
+ "adds r0, r0, #1\n" // increment pin
+ "cmp r0, #20\n" // stop after pin 18
+ "blt init_loop\n" // loop until r0 == 20
+ );
+
+ uint8_t pin = 16;
+
+ while (1) {
+ __asm volatile (
+ "mov r4, %0\n" // pin
+ "movs r5, #0x01\n" // bit 1; used for OUT/OE writes
+ "mcrr p0, #4, r4, r5, c0\n" // gpioc_bit_out_put(16, 1)
+ :
+ : "r"(pin)
+ : "r4","r5"
+ );
+ sleep_ms(500);
+
+ __asm volatile (
+ "mov r4, %0\n" // pin
+ "movs r5, #0\n" // bit 0; used for OUT/OE writes
+ "mcrr p0, #4, r4, r5, c0\n" // gpioc_bit_out_put(16, 0)
+ :
+ : "r"(pin)
+ : "r4","r5"
+ );
+ sleep_ms(500);
+
+ pin++;
+ if (pin > 18) pin = 16;
+
+ printf("age: %d\r\n", age);
+ printf("range: %d\r\n", range);
+ }
+}
+```
+
+### Breaking Down the Code
+
+#### The Integer Variables
+
+This program declares two integer variables that demonstrate the difference between **signed** and **unsigned** types:
+
+```c
+uint8_t age = 43;
+int8_t range = -42;
+```
+
+The variable `age` is a `uint8_t` — an **unsigned** 8-bit integer that can only hold values from `0` to `255`. Since age is always a positive number, unsigned is the right choice. The variable `range` is an `int8_t` — a **signed** 8-bit integer that can hold values from `-128` to `127`. The signed type allows it to represent negative numbers like `-42`. Under the hood, negative values are stored using **two's complement** encoding: the CPU flips all the bits of `42` (`0x2A`) and adds `1`, producing `0xD6`, which is how `-42` lives in a single byte of memory.
+
+#### GPIO Initialization with Inline Assembly
+
+Instead of using the Pico SDK's `gpio_init()`, `gpio_set_dir()`, and `gpio_set_function()` helpers, this program configures GPIO pins **directly at the register level** using inline assembly. This gives us a window into how the hardware actually works on the RP2350.
+
+The initialization loop configures GPIO pins 16 through 19 (our red, green, blue, and yellow LEDs) in three steps per pin:
+
+**Step 1 — Configure the pad.** Each GPIO pin has a pad control register in `PADS_BANK0` starting at base address `0x40038000`. The code calculates the offset as `pin * 4`, loads the current register value, clears the **OD** (output disable) and **ISO** (isolation) bits with `bic r5, r5, #0x180`, and sets the **IE** (input enable) bit with `orr r5, r5, #0x40`. This ensures the pad is electrically active and ready to drive output.
+
+**Step 2 — Set the pin function.** Each GPIO pin has a control register in `IO_BANK0` starting at `0x40028004`. The offset is `pin * 8` because each pin's control block is 8 bytes wide. The code clears the `FUNCSEL` field (bits `[4:0]`) and sets it to `5`, which selects the **SIO** (Single-cycle I/O) function. SIO is the mode that lets software directly control pin state through the GPIO coprocessor.
+
+**Step 3 — Enable the output driver.** The instruction `mcrr p0, #4, r4, r5, c4` writes to the RP2350's GPIO coprocessor. Coprocessor register `c4` controls the **output enable** — with `r4` holding the pin number and `r5` set to `1`, this tells the hardware "this pin is an output." The `mcrr` (Move to Coprocessor from two ARM Registers) instruction is how the Cortex-M33 on the RP2350 talks to its dedicated GPIO coprocessor, bypassing the normal memory-mapped I/O path for single-cycle pin control.
+
+#### The Blink Loop with Inline Assembly
+
+Inside the `while (1)` loop, the program uses two inline assembly blocks to toggle the current LED on and off:
+
+```c
+"mcrr p0, #4, r4, r5, c0\n" // gpioc_bit_out_put(pin, 1)
+```
+
+This time the coprocessor register is `c0` instead of `c4`. Register `c0` controls the **output value** — setting `r5 = 1` drives the pin HIGH (LED on), and `r5 = 0` drives it LOW (LED off). Each toggle is followed by `sleep_ms(500)` for a half-second delay, creating a visible blink.
+
+The GCC extended assembly syntax `"r"(pin)` tells the compiler to load the C variable `pin` into a general-purpose register and make it available as `%0` inside the assembly block. The clobber list `"r4","r5"` warns the compiler that those registers are modified, so it won't store anything important there.
+
+#### The Pin Cycling and Print Statements
+
+After each on/off cycle, the program increments `pin` and wraps it back to `16` when it exceeds `18`:
+
+```c
+pin++;
+if (pin > 18) pin = 16;
+```
+
+This cycles through GPIO 16, 17, and 18 — red, green, and blue LEDs — creating a rotating blink pattern. Finally, `printf` prints both integer variables over UART so we can observe their values on the serial terminal:
+
+```
+age: 43
+range: -42
+```
+
+> 💡 **Why use inline assembly instead of the SDK?** This program is designed to teach you what happens *beneath* the SDK. When you call `gpio_put(16, 1)` in normal Pico code, the SDK ultimately does the same coprocessor write — `mcrr p0, #4, r4, r5, c0`. By writing the assembly directly, you can see exactly how the RP2350 hardware is controlled, which is essential knowledge for reverse engineering and binary patching.
+
+---
+
+## 📚 Part 2: Understanding Floating-Point Data Types
+
+### What is a Float?
+
+A **float** is a number that can have a decimal point. Unlike integers which can only hold whole numbers like `42`, a float can hold values like `42.5`, `3.14`, or `-0.001`. In C, the `float` type uses **32 bits (4 bytes)** to store a number using the **IEEE 754** standard.
+
+```
+┌─────────────────────────────────────────────────────────────────┐
+│ IEEE 754 Single-Precision (32-bit float) │
+│ │
+│ ┌──────┬──────────┬───────────────────────────┐ │
+│ │ Sign │ Exponent │ Mantissa (Fraction) │ │
+│ │ 1bit │ 8 bits │ 23 bits │ │
+│ └──────┴──────────┴───────────────────────────┘ │
+│ │
+│ Value = (-1)^sign × 2^(exponent-127) × 1.mantissa │
+│ │
+│ Example: 42.5 │
+│ Sign: 0 (positive) │
+│ Exponent: 10000100 (132 - 127 = 5) │
+│ Mantissa: 01010100000000000000000 │
+│ Full: 0 10000100 01010100000000000000000 │
+│ Hex: 0x422A0000 │
+│ │
+└─────────────────────────────────────────────────────────────────┘
+```
+
+### Float vs Integer - Key Differences
+
+| Property | Integer (`uint8_t`) | Float (`float`) |
+| -------------- | ---------------------- | --------------------------- |
+| **Size** | 1 byte | 4 bytes |
+| **Precision** | Exact | ~7 decimal digits |
+| **Range** | 0 to 255 | ±3.4 × 10³⁸ |
+| **Encoding** | Direct binary | IEEE 754 (sign/exp/mantissa)|
+| **printf** | `%d` | `%f` |
+
+### Our Floating-Point Program
+
+Let's look at a simple program that uses a `float` variable:
+
+**File: `0x000e_floating-point-data-type.c`**
+
+```c
+#include
+#include "pico/stdlib.h"
+
+int main(void) {
+ float fav_num = 42.5;
+
+ stdio_init_all();
+
+ while (true)
+ printf("fav_num: %f\r\n", fav_num);
+}
+```
+
+**What this code does:**
+1. Declares a `float` variable `fav_num` and initializes it to `42.5`
+2. Initializes the serial output
+3. Prints `fav_num` forever in a loop using the `%f` format specifier
+
+> 💡 **Why `%f` instead of `%d`?** The `%d` format specifier tells `printf` to expect an integer. The `%f` specifier tells it to expect a floating-point number. Using the wrong one would print garbage!
+
+### Step 1: Flash the Binary to Your Pico 2
+
+1. Hold the BOOTSEL button on your Pico 2
+2. Plug in the USB cable (while holding BOOTSEL)
+3. Release BOOTSEL - a drive called "RPI-RP2" appears
+4. Drag and drop `0x000e_floating-point-data-type.uf2` onto the drive
+5. The Pico will reboot and start running!
+
+### Step 2: Verify It's Working
+
+Open your serial monitor (PuTTY) and you should see:
+
+**You should see:**
+
+```
+fav_num: 42.500000
+fav_num: 42.500000
+fav_num: 42.500000
+...
+```
+
+The program is printing `42.500000` because `printf` with `%f` defaults to 6 decimal places.
+
+---
+
+## 🔬 Part 2.5: Setting Up Ghidra for Float Analysis
+
+### Step 3: Start Ghidra
+
+**Open a terminal and type:**
+
+```bash
+ghidraRun
+```
+
+Ghidra will open. Now we need to create a new project.
+
+### Step 4: Create a New Project
+
+1. Click **File** → **New Project**
+2. Select **Non-Shared Project**
+3. Click **Next**
+4. Enter Project Name: `0x000e_floating-point-data-type`
+5. Click **Finish**
+
+### Step 5: Import the Binary
+
+1. Open your file explorer
+2. Navigate to the `Embedded-Hacking` folder
+3. Find `0x000e_floating-point-data-type.bin`
+4. Select Cortex M Little Endian 32
+5. Select Options and set up the .text and offset 10000000
+6. **Drag and drop** the `.bin` file into Ghidra's project window
+
+### Step 6: Configure the Binary Format
+
+A dialog appears. The file is identified as a "BIN" (raw binary without debug symbols).
+
+**Click the three dots (…) next to "Language" and:**
+1. Search for "Cortex"
+2. Select **ARM Cortex 32 little endian default**
+3. Click **OK**
+
+**Click the "Options…" button and:**
+1. Change **Block Name** to `.text`
+2. Change **Base Address** to `10000000` (the XIP address!)
+3. Click **OK**
+
+### Step 7: Open and Analyze
+
+1. Double-click on the file in the project window
+2. A dialog asks "Analyze now?" - Click **Yes**
+3. Use default analysis options and click **Analyze**
+
+Wait for analysis to complete (watch the progress bar in the bottom right).
+
+---
+
+## 🔬 Part 2.6: Navigating and Resolving Functions
+
+### Step 8: Find the Functions
+
+Look at the **Symbol Tree** panel on the left. Expand **Functions**.
+
+You'll see function names like:
+- `FUN_1000019a`
+- `FUN_10000210`
+- `FUN_10000234`
+
+These are auto-generated names because we imported a raw binary without symbols!
+
+### Step 9: Resolve Known Functions
+
+From our previous chapters, we know what some of these functions are:
+
+| Ghidra Name | Actual Name | How We Know |
+| -------------- | ------------- | -------------------------- |
+| `FUN_1000019a` | `data_cpy` | From Week 3 boot analysis |
+| `FUN_10000210` | `frame_dummy` | From Week 3 boot analysis |
+| `FUN_10000234` | `main` | This is where our code is! |
+
+### Step 10: Update Main's Signature
+
+For `main`, let's also fix the return type:
+
+1. Right-click on `main` in the Decompile window
+2. Select **Edit Function Signature**
+3. Change to: `int main(void)`
+4. Click **OK**
+
+---
+
+## 🔬 Part 2.7: Analyzing the Main Function
+
+### Step 11: Examine Main in Ghidra
+
+Click on `main` (or `FUN_10000234`). Look at the **Decompile** window:
+
+You'll see something like:
+
+```c
+int main(void)
+{
+ undefined4 uVar1;
+ undefined4 extraout_r1;
+ undefined4 uVar2;
+ undefined4 extraout_r1_00;
+
+ FUN_10002f5c();
+ uVar1 = DAT_1000024c;
+ uVar2 = extraout_r1;
+ do {
+ FUN_100030ec(DAT_10000250,uVar2,0,uVar1);
+ uVar2 = extraout_r1_00;
+ } while( true );
+}
+```
+
+### Step 12: Resolve stdio_init_all
+
+1. Click on `FUN_10002f5c`
+2. Right-click → **Edit Function Signature**
+3. Change to: `bool stdio_init_all(void)`
+4. Click **OK**
+
+### Step 13: Resolve printf
+
+1. Click on `FUN_100030ec`
+2. Right-click → **Edit Function Signature**
+3. Change to: `int __wrap_printf(char *format,...)`
+4. Check the **Varargs** checkbox (printf takes variable arguments!)
+5. Click **OK**
+
+### Step 14: Understand the Float Encoding
+
+Look at the decompiled code after resolving functions:
+
+```c
+int main(void)
+{
+ undefined4 uVar1;
+ undefined4 extraout_r1;
+ undefined4 uVar2;
+ undefined4 extraout_r1_00;
+
+ FUN_10002f5c();
+ uVar1 = DAT_1000024c;
+ uVar2 = extraout_r1;
+ do {
+ FUN_100030ec(DAT_10000250,uVar2,0,uVar1);
+ uVar2 = extraout_r1_00;
+ } while( true );
+}
+```
+
+**Where's `float fav_num = 42.5`?** It's been optimized into an immediate value!
+
+The compiler replaced our float variable with constants passed directly to `printf`. But wait — we see **two** values: `0x0`, in `r2` and `DAT_1000024c` or `0x40454000`, in `r3`. That's because `printf` with `%f` always receives a **double** (64-bit), not a `float` (32-bit). The C standard requires that `float` arguments to variadic functions like `printf` are **promoted to `double`**.
+
+A 64-bit double is passed in two 32-bit registers:
+
+| Register | Value | Role |
+| -------- | ------------ | ------------ |
+| `r2` | `0x00000000` | Low 32 bits |
+| `r3` | `0x40454000` | High 32 bits |
+
+Together they form `0x40454000_00000000` — the IEEE 754 **double-precision** encoding of `42.5`.
+
+### Step 15: Verify the Double Encoding
+
+We need to decode `0x4045400000000000` field by field. The two registers give us the full 64-bit value:
+
+```
+r3 (high 32 bits): 0x40454000 = 0100 0000 0100 0101 0100 0000 0000 0000
+r2 (low 32 bits): 0x00000000 = 0000 0000 0000 0000 0000 0000 0000 0000
+```
+
+Laid out as a single 64-bit value with every bit numbered:
+
+```
+Bit: 63 62-52 (11 bits) 51-32 (20 bits) 31-0 (32 bits)
+ ┌───┬───────────────────────┬──────────────────────────────────────────┬──────────────────────────────────┐
+ │ 0 │ 1 0 0 0 0 0 0 0 1 0 0 │ 0 1 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 │ 00000000000000000000000000000000 │
+ └───┴───────────────────────┴──────────────────────────────────────────┴──────────────────────────────────┘
+ Sign Exponent (11) Mantissa high 20 bits Mantissa low 32 bits
+ (from r3 bits 19–0) (from r2, all zero)
+```
+
+**Step-by-step field extraction:**
+
+**1. Sign bit**
+
+In IEEE 754, the **sign bit** is the very first (leftmost) bit of the 64-bit double. In the full 64-bit layout we call it **bit 63**:
+
+```
+64-bit double: [bit 63] [bit 62 ... bit 0]
+ ^
+ sign bit
+```
+
+But we don't have a single 64-bit register — we have **two** 32-bit registers. The high register `r3` holds bits 63–32 of the double. So bit 63 of the double is the same physical bit as **bit 31 of r3** (the topmost bit of r3):
+
+```
+r3 holds bits 63–32 of the double
+r2 holds bits 31–0 of the double
+```
+
+Now let's check it. IEEE 754 uses a simple rule for the sign bit:
+
+| Sign bit | Meaning |
+|----------|----------|
+| `0` | Positive |
+| `1` | Negative |
+
+```
+r3 = 0x40454000 = 0100 0000 0100 0101 0100 0000 0000 0000
+ ^
+ r3 bit 31 = 0 → sign = 0 → Positive number
+```
+
+The topmost bit of r3 is `0`, so the number is **positive**. If that bit were `1` instead (e.g. `0xC0454000`), the number would be negative (`-42.5`).
+
+**2. Exponent — bits 62–52 of the 64-bit value = bits 30–20 of r3**
+
+Extract bits 30–20 from `0x40454000`:
+
+```
+0x40454000 in binary: 0 10000000100 01010100000000000000
+ sign exponent mantissa (top 20 bits)
+```
+
+Exponent bits: `10000000100`
+
+Convert to decimal: $2^{10} + 2^{2} = 1024 + 4 = 1028$
+
+But `1028` is **not** the actual power of 2 yet. IEEE 754 stores exponents with a **bias** — a fixed number that gets added during encoding so that the stored value is always positive (no sign bit needed for the exponent). For doubles, the bias is **1023**.
+
+> 💡 **Why 1023?** The exponent field is 11 bits wide, giving $2^{11} = 2048$ total values. Half of that range should represent negative exponents and half positive. The midpoint is $(2^{11} / 2) - 1 = 1023$. So a stored exponent of `1023` means a real exponent of **0**, values below `1023` are negative exponents, and values above `1023` are positive exponents.
+
+To recover the real exponent, we subtract the bias:
+
+$$\text{real exponent} = \text{stored exponent} - \text{bias}$$
+
+$$\text{real exponent} = 1028 - 1023 = \mathbf{5}$$
+
+This means the number is scaled by $2^5 = 32$. In other words, the mantissa gets shifted left by 5 binary places.
+
+**3. Mantissa — bits 51–0 of the 64-bit value**
+
+- **High 20 bits of mantissa** (bits 51–32) = bits 19–0 of r3:
+
+```
+r3 bits 19–0: 0 1 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
+```
+
+- **Low 32 bits of mantissa** (bits 31–0) = all of r2:
+
+```
+r2 = 0x00000000 → 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
+```
+
+Full 52-bit mantissa:
+
+```
+0 1 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
+ ← top 20 bits from r3 → ← bottom 32 bits from r2 (all zero) →
+```
+
+IEEE 754 always prepends an **implied leading `1`**, so the actual value represented is:
+
+```
+1.010101 00000... (the 1. is implicit, not stored)
+```
+
+**4. Reconstruct the value**
+
+$$1.010101_2 \times 2^5$$
+
+Shift the binary point 5 places right:
+
+$$101010.1_2$$
+
+Now convert each bit position to decimal:
+
+| Bit position | Power of 2 | Value |
+|---|---|---|
+| `1` (bit 5) | $2^5$ | 32 |
+| `0` (bit 4) | $2^4$ | 0 |
+| `1` (bit 3) | $2^3$ | 8 |
+| `0` (bit 2) | $2^2$ | 0 |
+| `1` (bit 1) | $2^1$ | 2 |
+| `0` (bit 0) | $2^0$ | 0 |
+| `1` (bit −1) | $2^{-1}$ | 0.5 |
+
+$$32 + 8 + 2 + 0.5 = \mathbf{42.5} ✓$$
+
+### Step 16: Examine the Assembly
+
+Look at the **Listing** window (assembly view). Find the main function:
+
+```
+ *************************************************************
+ * FUNCTION
+ *************************************************************
+ undefined FUN_10000234 ()
+ undefined
+ FUN_10000234+1 XREF[1,1]: 1000018c (c) , 1000018a (*)
+ FUN_10000234
+ 10000234 38 b5 push {r3,r4,r5,lr}
+ 10000236 02 f0 91 fe bl FUN_10002f5c undefined FUN_10002f5c()
+ 1000023a 00 24 movs r4,#0x0
+ 1000023c 03 4d ldr r5,[DAT_1000024c ] = 40454000h
+ LAB_1000023e XREF[1]: 10000248 (j)
+ 1000023e 22 46 mov r2,r4
+ 10000240 2b 46 mov r3,r5
+ 10000242 03 48 ldr r0=>s_fav_num:_%f_100034a8 ,[DAT_10000250 ] = "fav_num: %f\r\n"
+ = 100034A8h
+ 10000244 02 f0 52 ff bl FUN_100030ec undefined FUN_100030ec()
+ 10000248 f9 e7 b LAB_1000023e
+ 1000024a 00 ?? 00h
+ 1000024b bf ?? BFh
+ DAT_1000024c XREF[1]: FUN_10000234:1000023c (R)
+ 1000024c 00 40 45 40 undefine 40454000h
+ DAT_10000250 XREF[1]: FUN_10000234:10000242 (R)
+ 10000250 a8 34 00 10 undefine 100034A8h ? -> 100034a8
+
+```
+
+> 🎯 **Key Insight:** The `mov.w r2, #0x0` loads the low 32 bits (all zeros) and `ldr r3, [DAT_...]` loads the high 32 bits (`0x40454000`) of the double. Together, `r2:r3` = `0x40454000_00000000` = `42.5` as a double.
+
+### Step 17: Find the Format String
+
+In the Listing view, click on the data reference to find the format string:
+
+```
+ s_fav_num:_%f_100034a8 XREF[1]: FUN_10000234:10000242 (*)
+ 100034a8 66 61 76 ds "fav_num: %f\r\n"
+ 5f 6e 75
+ 6d 3a 20
+
+```
+
+This confirms `printf` is called with the format string `"fav_num: %f\r\n"` and the double-precision value of `42.5`.
+
+---
+
+## 🔬 Part 2.8: Patching the Float - Changing 42.5 to 99.0
+
+### Step 18: Calculate the New IEEE 754 Encoding
+
+We want to change `42.5` to `99.0`. First, we need to figure out the double-precision encoding of `99.0`:
+
+**Step A — Convert the integer part (99) to binary:**
+
+| Division | Quotient | Remainder |
+|---------------|----------|-----------|
+| 99 ÷ 2 | 49 | **1** |
+| 49 ÷ 2 | 24 | **1** |
+| 24 ÷ 2 | 12 | **0** |
+| 12 ÷ 2 | 6 | **0** |
+| 6 ÷ 2 | 3 | **0** |
+| 3 ÷ 2 | 1 | **1** |
+| 1 ÷ 2 | 0 | **1** |
+
+Read remainders bottom-to-top: $99_{10} = 1100011_2$
+
+**Step B — Convert the fractional part (.0) to binary:**
+
+There is no fractional part — `.0` is exactly zero, so the fractional binary is just `0`.
+
+**Step C — Combine:**
+
+$$99.0_{10} = 1100011.0_2$$
+
+**Step D — Normalize to IEEE 754 form** (move the binary point so there's exactly one `1` before it):
+
+$$1100011.0_2 = 1.100011_2 \times 2^6$$
+
+We shifted the binary point 6 places left, so the exponent is **6**.
+
+**Step E — Extract the IEEE 754 fields:**
+
+1. **Sign:** `0` (positive)
+2. **Exponent:** $6 + 1023 = 1029 = 10000000101_2$
+3. **Mantissa:** `1000110000000000...` (everything after the `1.`, padded with zeros to 52 bits)
+4. **Full double:** `0x4058C00000000000`
+
+| Register | Old Value | New Value |
+| -------- | ------------ | ------------ |
+| `r2` | `0x00000000` | `0x00000000` |
+| `r3` | `0x40454000` | `0x4058C000` |
+
+Since `r2` stays `0x00000000`, we only need to patch the high word loaded into `r3`.
+
+### Step 19: Find the Value to Patch
+
+Look in the Listing view for the data that loads the high word of the double:
+
+```
+ 10000248 00 40 45 40 undefined4 40454000h
+```
+
+This is the 32-bit constant that gets loaded into `r3` — the high word of our double `42.5`.
+
+### Step 20: Patch the Constant
+
+1. Click on Window -> Bytes
+2. Click on Pencil Icon in Bytes Editor
+2. Right-click and select **Patch Data**
+3. Change `00404540` to `00C05840`
+4. Press Enter
+
+This changes the high word from `0x40454000` (42.5 as double) to `0x4058C000` (99.0 as double).
+
+---
+
+## 🔬 Part 2.9: Export and Test the Hacked Binary
+
+### Step 21: Export the Patched Binary
+
+1. Click **File** → **Export Program**
+2. Set **Format** to **Raw Bytes**
+3. Navigate to your build directory
+4. Name the file `0x000e_floating-point-data-type-h.bin`
+5. Click **OK**
+
+### Step 22: Convert to UF2 Format
+
+**Open a terminal and navigate to your project directory:**
+
+```bash
+cd Embedded-Hacking-main\0x000e_floating-point-data-type
+```
+
+**Run the conversion command:**
+
+```bash
+python ../uf2conv.py build/0x000e_floating-point-data-type-h.bin --base 0x10000000 --family 0xe48bff59 --output build/hacked.uf2
+```
+
+### Step 23: Flash the Hacked Binary
+
+1. Hold BOOTSEL and plug in your Pico 2
+2. Drag and drop `hacked.uf2` onto the RPI-RP2 drive
+3. Open your serial monitor
+
+**You should see:**
+
+```
+fav_num: 99.000000
+fav_num: 99.000000
+fav_num: 99.000000
+...
+```
+
+🎉 **BOOM! We hacked the float!** The value changed from `42.5` to `99.0`!
+
+---
+
+## 📚 Part 3: Understanding Double-Precision Floating-Point Data Types
+
+### What is a Double?
+
+A **double** (short for "double-precision floating-point") is like a `float` but with **twice the precision**. While a `float` uses 32 bits, a `double` uses **64 bits (8 bytes)**, giving it roughly **15–16 significant decimal digits** of precision compared to a float's ~7.
+
+```
+┌─────────────────────────────────────────────────────────────────┐
+│ IEEE 754 Double-Precision (64-bit double) │
+│ │
+│ ┌──────┬───────────┬──────────────────────────────────────┐ │
+│ │ Sign │ Exponent │ Mantissa (Fraction) │ │
+│ │ 1bit │ 11 bits │ 52 bits │ │
+│ └──────┴───────────┴──────────────────────────────────────┘ │
+│ │
+│ Value = (-1)^sign × 2^(exponent-1023) × 1.mantissa │
+│ │
+│ Example: 42.52525 │
+│ Sign: 0 (positive) │
+│ Exponent: 10000000100 (1028 - 1023 = 5) │
+│ Mantissa: 0101010000110011101101100100010110100001110010101100 │
+│ Hex: 0x4045433B645A1CAC │
+│ │
+└─────────────────────────────────────────────────────────────────┘
+```
+
+### Float vs Double - Key Differences
+
+| Property | Float (`float`) | Double (`double`) |
+| --------------- | ---------------------- | --------------------------- |
+| **Size** | 4 bytes (32 bits) | 8 bytes (64 bits) |
+| **Precision** | ~7 decimal digits | ~15 decimal digits |
+| **Exponent** | 8 bits (bias 127) | 11 bits (bias 1023) |
+| **Mantissa** | 23 bits | 52 bits |
+| **Range** | ±3.4 × 10³⁸ | ±1.8 × 10³⁰⁸ |
+| **printf** | `%f` | `%lf` |
+| **ARM passing** | Promoted to double | Native in `r2:r3` |
+
+> 💡 **Why does precision matter?** With a `float`, the value `42.52525` might be stored as `42.525249` due to rounding. A `double` can represent it as `42.525250` with much higher fidelity. For scientific or financial applications, that extra precision is critical!
+
+### Our Double-Precision Program
+
+Let's look at a program that uses a `double` variable:
+
+**File: `0x0011_double-floating-point-data-type.c`**
+
+```c
+#include
+#include "pico/stdlib.h"
+
+int main(void) {
+ double fav_num = 42.52525;
+
+ stdio_init_all();
+
+ while (true)
+ printf("fav_num: %lf\r\n", fav_num);
+}
+```
+
+**What this code does:**
+1. Declares a `double` variable `fav_num` and initializes it to `42.52525`
+2. Initializes the serial output
+3. Prints `fav_num` forever in a loop using the `%lf` format specifier
+
+> 💡 **`%lf` vs `%f`:** While `printf` actually treats `%f` and `%lf` identically (both expect a `double`), using `%lf` makes your intent clear — you're explicitly working with a `double`, not a `float`. It's good practice to match the format specifier to your variable type.
+
+### Step 1: Flash the Binary to Your Pico 2
+
+1. Hold the BOOTSEL button on your Pico 2
+2. Plug in the USB cable (while holding BOOTSEL)
+3. Release BOOTSEL - a drive called "RPI-RP2" appears
+4. Drag and drop `0x000A_intro-to-doubles.uf2` onto the drive
+5. The Pico will reboot and start running!
+
+### Step 2: Verify It's Working
+
+Open your serial monitor (PuTTY) and you should see:
+
+**You should see:**
+
+```
+fav_num: 42.525250
+fav_num: 42.525250
+fav_num: 42.525250
+...
+```
+
+The program is printing `42.525250` because `printf` with `%lf` defaults to 6 decimal places.
+
+---
+
+## 🔬 Part 3.5: Setting Up Ghidra for Double Analysis
+
+### Step 3: Start Ghidra
+
+**Open a terminal and type:**
+
+```bash
+ghidraRun
+```
+
+Ghidra will open. Now we need to create a new project.
+
+### Step 4: Create a New Project
+
+1. Click **File** → **New Project**
+2. Select **Non-Shared Project**
+3. Click **Next**
+4. Enter Project Name: `0x000A_intro-to-doubles`
+5. Click **Finish**
+
+### Step 5: Import the Binary
+
+1. Open your file explorer
+2. Navigate to the `Embedded-Hacking` folder
+3. Find `0x0011_double-floating-point-data-type.bin`
+4. Select Cortex M Little Endian 32
+5. Select Options and set up the .text and offset 10000000
+6. **Drag and drop** the `.bin` file into Ghidra's project window
+
+### Step 6: Configure the Binary Format
+
+A dialog appears. The file is identified as a "BIN" (raw binary without debug symbols).
+
+**Click the three dots (…) next to "Language" and:**
+1. Search for "Cortex"
+2. Select **ARM Cortex 32 little endian default**
+3. Click **OK**
+
+**Click the "Options…" button and:**
+1. Change **Block Name** to `.text`
+2. Change **Base Address** to `10000000` (the XIP address!)
+3. Click **OK**
+
+### Step 7: Open and Analyze
+
+1. Double-click on the file in the project window
+2. A dialog asks "Analyze now?" - Click **Yes**
+3. Use default analysis options and click **Analyze**
+
+Wait for analysis to complete (watch the progress bar in the bottom right).
+
+---
+
+## 🔬 Part 3.6: Navigating and Resolving Functions
+
+### Step 8: Find the Functions
+
+Look at the **Symbol Tree** panel on the left. Expand **Functions**.
+
+You'll see function names like:
+- `FUN_1000019a`
+- `FUN_10000210`
+- `FUN_10000238`
+
+These are auto-generated names because we imported a raw binary without symbols!
+
+### Step 9: Resolve Known Functions
+
+From our previous chapters, we know what some of these functions are:
+
+| Ghidra Name | Actual Name | How We Know |
+| -------------- | ------------- | -------------------------- |
+| `FUN_1000019a` | `data_cpy` | From Week 3 boot analysis |
+| `FUN_10000210` | `frame_dummy` | From Week 3 boot analysis |
+| `FUN_10000238` | `main` | This is where our code is! |
+
+### Step 10: Update Main's Signature
+
+For `main`, let's also fix the return type:
+
+1. Right-click on `main` in the Decompile window
+2. Select **Edit Function Signature**
+3. Change to: `int main(void)`
+4. Click **OK**
+
+---
+
+## 🔬 Part 3.7: Analyzing the Main Function
+
+### Step 11: Examine Main in Ghidra
+
+Click on `main` (or `FUN_10000234`). Look at the **Decompile** window:
+
+You'll see something like:
+
+```c
+void FUN_10000238(void)
+{
+ undefined4 uVar1;
+ undefined4 uVar2;
+ undefined4 extraout_r1;
+ undefined4 uVar3;
+ undefined4 extraout_r1_00;
+ undefined4 in_r3;
+
+ uVar2 = DAT_10000258;
+ uVar1 = DAT_10000254;
+ FUN_10002f64();
+ uVar3 = extraout_r1;
+ do {
+ FUN_100030f4(DAT_10000250,uVar3,uVar1,uVar2,in_r3);
+ uVar3 = extraout_r1_00;
+ } while( true );
+}
+```
+
+### Step 12: Resolve stdio_init_all
+
+1. Click on `FUN_10002f64`
+2. Right-click → **Edit Function Signature**
+3. Change to: `bool stdio_init_all(void)`
+4. Click **OK**
+
+### Step 13: Resolve printf
+
+1. Click on `FUN_100030f4`
+2. Right-click → **Edit Function Signature**
+3. Change the name to `printf`
+4. Check the **Varargs** checkbox (printf takes variable arguments!)
+5. Click **OK**
+
+### Step 14: Understand the Double Encoding
+
+Look at the decompiled code after resolving functions:
+
+```c
+int main(void)
+{
+ undefined4 uVar1;
+ undefined4 uVar2;
+ undefined4 extraout_r1;
+ undefined4 uVar3;
+ undefined4 extraout_r1_00;
+
+ uVar2 = DAT_10000258;
+ uVar1 = DAT_10000254;
+ FUN_10002f64();
+ uVar3 = extraout_r1;
+ do {
+ FUN_100030f4(DAT_10000250,uVar3,uVar1,uVar2);
+ uVar3 = extraout_r1_00;
+ } while( true );
+}
+```
+
+**Where's `double fav_num = 42.52525`?** It's been optimized into immediate values!
+
+This time we see **two** non-zero values: `0x645a1cac` and `0x4045433b`. Unlike the float example where the low word was `0x0`, a double with a fractional part like `42.52525` needs **all 52 mantissa bits** — so both halves carry data.
+
+A 64-bit double is passed in two 32-bit registers:
+
+| Register | Value | Role |
+| -------- | ------------ | ------------ |
+| `r2` | `0x645A1CAC` | Low 32 bits |
+| `r3` | `0x4045433B` | High 32 bits |
+
+Together they form `0x4045433B645A1CAC` — the IEEE 754 **double-precision** encoding of `42.52525`.
+
+> 🎯 **Key Difference from Float:** In the float example, `r2` was `0x00000000` because `42.5` has a clean fractional part. But `42.52525` has a repeating binary fraction, so the low 32 bits are non-zero (`0x645A1CAC`). This means **both** registers matter when patching doubles with complex fractional values!
+
+### Step 15: Verify the Double Encoding
+
+We need to decode `0x4045433B645A1CAC` field by field. The two registers give us the full 64-bit value:
+
+```
+r3 (high 32 bits): 0x4045433B = 0100 0000 0100 0101 0100 0011 0011 1011
+r2 (low 32 bits): 0x645A1CAC = 0110 0100 0101 1010 0001 1100 1010 1100
+```
+
+Laid out as a single 64-bit value with every bit numbered:
+
+```
+Bit: 63 62-52 (11 bits) 51-32 (20 bits) 31-0 (32 bits)
+ ┌───┬───────────────────────┬──────────────────────────────────────────┬──────────────────────────────────────────┐
+ │ 0 │ 1 0 0 0 0 0 0 0 1 0 0 │ 0 1 0 1 0 1 0 0 0 0 1 1 0 0 1 1 1 0 1 1 │ 01100100010110100001110010101100 │
+ └───┴───────────────────────┴──────────────────────────────────────────┴──────────────────────────────────────────┘
+ Sign Exponent (11) Mantissa high 20 bits Mantissa low 32 bits
+ (from r3 bits 19–0) (from r2)
+```
+
+> 🎯 **Key Difference from 42.5:** In the `42.5` example, r2 was `0x00000000` because `42.5` has a clean fractional part (`.5` = exactly one binary digit). But `42.52525` has a repeating binary fraction, so the low 32 bits are **non-zero** (`0x645A1CAC`). Every bit of both registers matters here!
+
+**Step-by-step field extraction:**
+
+**1. Sign bit**
+
+The sign bit is bit 63 of the 64-bit double, which is bit 31 of r3 (the high register holds bits 63–32):
+
+```
+r3 = 0x4045433B = 0100 0000 0100 0101 0100 0011 0011 1011
+ ^
+ r3 bit 31 = 0 → sign = 0 → Positive number ✓
+```
+
+**2. Exponent — bits 62–52 = bits 30–20 of r3**
+
+Extract bits 30–20 from `0x4045433B`:
+
+```
+0x4045433B in binary: 0 10000000100 01010100001100111011
+ sign exponent mantissa (top 20 bits)
+```
+
+Exponent bits: `10000000100`
+
+Convert to decimal: $2^{10} + 2^{2} = 1024 + 4 = 1028$
+
+Subtract the bias (same formula as Part 2 — the bias is 1023 for all doubles):
+
+$$\text{real exponent} = 1028 - 1023 = \mathbf{5}$$
+
+This means the mantissa gets shifted left by 5 binary places (i.e. multiplied by $2^5 = 32$).
+
+**3. Mantissa — bits 51–0**
+
+Unlike the `42.5` example where r2 was all zeros, **both registers contribute non-zero bits** here:
+
+- **High 20 bits of mantissa** (bits 51–32) = bits 19–0 of r3:
+
+```
+r3 bits 19–0: 0 1 0 1 0 1 0 0 0 0 1 1 0 0 1 1 1 0 1 1
+```
+
+- **Low 32 bits of mantissa** (bits 31–0) = all of r2:
+
+```
+r2 = 0x645A1CAC → 0 1 1 0 0 1 0 0 0 1 0 1 1 0 1 0 0 0 0 1 1 1 0 0 1 0 1 0 1 1 0 0
+```
+
+Full 52-bit mantissa:
+
+```
+0 1 0 1 0 1 0 0 0 0 1 1 0 0 1 1 1 0 1 1 | 0 1 1 0 0 1 0 0 0 1 0 1 1 0 1 0 0 0 0 1 1 1 0 0 1 0 1 0 1 1 0 0
+ ← top 20 bits from r3 → ← bottom 32 bits from r2 →
+```
+
+IEEE 754 always prepends an **implied leading `1`**, so the actual value represented is:
+
+```
+1.0101010000110011101101100100010110100001110010101100 (the 1. is implicit, not stored)
+```
+
+**4. Reconstruct the value**
+
+$$1.0101010000110011101101100100..._2 \times 2^5$$
+
+Shift the binary point 5 places right:
+
+$$101010.10000110011101101100100010110100001110010101100_2$$
+
+**Integer part** (`101010`):
+
+| Bit position | Power of 2 | Value |
+|---|---|---|
+| `1` (bit 5) | $2^5$ | 32 |
+| `0` (bit 4) | $2^4$ | 0 |
+| `1` (bit 3) | $2^3$ | 8 |
+| `0` (bit 2) | $2^2$ | 0 |
+| `1` (bit 1) | $2^1$ | 2 |
+| `0` (bit 0) | $2^0$ | 0 |
+
+$$32 + 8 + 2 = \mathbf{42}$$
+
+**Fractional part** (`.10000110011101101...`):
+
+| Bit position | Power of 2 | Decimal value |
+|---|---|---|
+| `1` (bit −1) | $2^{-1}$ | 0.5 |
+| `0` (bit −2) | $2^{-2}$ | 0 |
+| `0` (bit −3) | $2^{-3}$ | 0 |
+| `0` (bit −4) | $2^{-4}$ | 0 |
+| `0` (bit −5) | $2^{-5}$ | 0 |
+| `1` (bit −6) | $2^{-6}$ | 0.015625 |
+| `1` (bit −7) | $2^{-7}$ | 0.0078125 |
+| `0` (bit −8) | $2^{-8}$ | 0 |
+| `0` (bit −9) | $2^{-9}$ | 0 |
+| `1` (bit −10) | $2^{-10}$ | 0.0009765625 |
+| `1` (bit −11) | $2^{-11}$ | 0.00048828125 |
+| `1` (bit −12) | $2^{-12}$ | 0.000244140625 |
+| ... | ... | *(remaining 35 bits add smaller and smaller fractions)* |
+
+First 12 fractional bits sum: $0.5 + 0.015625 + 0.0078125 + 0.0009765625 + 0.00048828125 + 0.000244140625 \approx 0.5251$
+
+The remaining 35 fractional bits refine this to $\approx 0.52525$. This is because `0.52525` is a **repeating fraction** in binary — it can never be represented with a finite number of bits, so double precision stores the closest possible 52-bit approximation.
+
+$$42 + 0.52525 = \mathbf{42.52525} ✓$$
+
+### Step 16: Examine the Assembly
+
+Look at the **Listing** window (assembly view). Find the main function:
+
+```
+ *************************************************************
+ * FUNCTION
+ *************************************************************
+ undefined FUN_10000238 ()
+ undefined
+ FUN_10000238+1 XREF[1,1]: 1000018c (c) , 1000018a (*)
+ FUN_10000238
+ 10000238 38 b5 push {r3,r4,r5,lr}
+ 1000023a 06 a5 adr r5,[0x10000254 ]
+ 1000023c d5 e9 00 45 ldrd r4,r5,[r5,#0x0 ]=>DAT_10000254 = 645A1CACh
+ = 4045433Bh
+ 10000240 02 f0 90 fe bl FUN_10002f64 undefined FUN_10002f64()
+ LAB_10000244 XREF[1]: 1000024e (j)
+ 10000244 22 46 mov r2,r4
+ 10000246 2b 46 mov r3,r5
+ 10000248 01 48 ldr r0=>s_fav_num:_%lf_100034b0 ,[DAT_10000250 ] = "fav_num: %lf\r\n"
+ = 100034B0h
+ 1000024a 02 f0 53 ff bl FUN_100030f4 undefined FUN_100030f4()
+ 1000024e f9 e7 b LAB_10000244
+ DAT_10000250 XREF[1]: FUN_10000238:10000248 (R)
+ 10000250 b0 34 00 10 undefine 100034B0h ? -> 100034b0
+ DAT_10000254 XREF[1]: FUN_10000238:1000023c (R)
+ 10000254 ac 1c 5a 64 undefine 645A1CACh
+ DAT_10000258 XREF[1]: FUN_10000238:1000023c (R)
+ 10000258 3b 43 45 40 undefine 4045433Bh
+```
+
+> 🎯 **Key Insight:** Notice that **both** `r2` and `r3` are loaded from data constants using `ldr`. Compare this to the float example where `r2` was loaded with `mov.w r2, #0x0`. Because `42.52525` requires all 52 mantissa bits, neither word can be zero — the compiler must store both halves as separate data constants.
+
+### Step 17: Find the Format String
+
+In the Listing view, click on the data reference to find the format string:
+
+```
+ s_fav_num:_%lf_100034b0 XREF[1]: FUN_10000238:10000248 (*)
+ 100034b0 66 61 76 ds "fav_num: %lf\r\n"
+ 5f 6e 75
+ 6d 3a 20
+
+```
+
+This confirms `printf` is called with the format string `"fav_num: %lf\r\n"` and the double-precision value of `42.52525`.
+
+---
+
+## 🔬 Part 3.8: Patching the Double - Changing 42.52525 to 99.99
+
+### Step 18: Calculate the New IEEE 754 Encoding
+
+We want to change `42.52525` to `99.99`. First, we need to figure out the double-precision encoding of `99.99`:
+
+1. $99.99 = 1.5623... \times 2^6 = 1.100011111111..._2 \times 2^6$
+2. **Sign:** `0` (positive)
+3. **Exponent:** $6 + 1023 = 1029 = 10000000101_2$
+4. **Mantissa:** `1000111111010111000010100011110101110000101000111..._2$
+5. **Full double:** `0x4058FF5C28F5C28F`
+
+| Register | Old Value | New Value |
+| -------- | ------------ | ------------ |
+| `r2` | `0x645A1CAC` | `0x28F5C28F` |
+| `r3` | `0x4045433B` | `0x4058FF5C` |
+
+Unlike the float example, **both** registers change! The value `99.99` has a repeating binary fraction, so both the high and low words are different.
+
+### Step 19: Find the Values to Patch
+
+Look in the Listing view for the two data constants:
+
+**Low word (loaded into `r2`):**
+```
+ 10000254 ac 1c 5a 64 undefined4 645A1CACh
+```
+
+**High word (loaded into `r3`):**
+```
+ 10000258 3b 43 45 40 undefined4 4045433Bh
+```
+
+### Step 20: Patch Both Constants
+
+**Patch the low word:**
+1. Click on the data at address `10000254` containing `645A1CAC`
+2. Right-click and select **Patch Data**
+3. Change `645A1CAC` to `28F5C28F` -> `8FC2F528`
+4. Press Enter
+
+**Patch the high word:**
+1. Click on the data at address `10000258` containing `4045433B`
+2. Right-click and select **Patch Data**
+3. Change `4045433B` to `4058FF5C` -> `5CFF5840`
+4. Press Enter
+
+This changes the full 64-bit double from `0x4045433B645A1CAC` (42.52525) to `0x4058FF5C28F5C28F` (99.99).
+
+> 🎯 **Key Difference from Float Patching:** When we patched the float `42.5`, we only needed to change one word (the high word in `r3`) because the low word was all zeros. With `42.52525 → 99.99`, **both** words change. Always check whether the low word is non-zero before patching!
+
+---
+
+## 🔬 Part 3.9: Export and Test the Hacked Binary
+
+### Step 21: Export the Patched Binary
+
+1. Click **File** → **Export Program**
+2. Set **Format** to **Raw Bytes**
+3. Navigate to your build directory
+4. Name the file `0x0011_double-floating-point-data-type-h.bin`
+5. Click **OK**
+
+### Step 22: Convert to UF2 Format
+
+**Open a terminal and navigate to your project directory:**
+
+```bash
+cd Embedded-Hacking-main\0x0011_double-floating-point-data-type
+```
+
+**Run the conversion command:**
+
+```bash
+python ../uf2conv.py build/0x0011_double-floating-point-data-type-h.bin --base 0x10000000 --family 0xe48bff59 --output build/hacked.uf2
+```
+
+### Step 23: Flash the Hacked Binary
+
+1. Hold BOOTSEL and plug in your Pico 2
+2. Drag and drop `hacked.uf2` onto the RPI-RP2 drive
+3. Open your serial monitor
+
+**You should see:**
+
+```
+fav_num: 99.990000
+fav_num: 99.990000
+fav_num: 99.990000
+...
+```
+
+🎉 **BOOM! We hacked the double!** The value changed from `42.52525` to `99.99`!
+
+---
+
+## 📊 Part 3.95: Summary - Float and Double Analysis
+
+### What We Accomplished
+
+1. **Learned about IEEE 754** - How floating-point numbers are encoded in 32-bit (float) and 64-bit (double) formats
+2. **Discovered float-to-double promotion** - `printf` with `%f` always receives a `double`, even when you pass a `float`
+3. **Decoded register pairs** - 64-bit doubles are split across `r2` (low) and `r3` (high)
+4. **Patched a float value** - Changed `42.5` to `99.0` by modifying only the high word
+5. **Patched a double value** - Changed `42.52525` to `99.99` by modifying **both** words
+6. **Understood the key difference** - Clean fractions (like `42.5`) have a zero low word; complex fractions (like `42.52525`) require patching both words
+
+### IEEE 754 Quick Reference for Common Values
+
+| Value | Double Hex | High Word (r3) | Low Word (r2) |
+| -------- | ------------------------ | --------------- | -------------- |
+| 42.0 | `0x4045000000000000` | `0x40450000` | `0x00000000` |
+| 42.5 | `0x4045400000000000` | `0x40454000` | `0x00000000` |
+| 42.52525 | `0x4045433B645A1CAC` | `0x4045433B` | `0x645A1CAC` |
+| 43.0 | `0x4045800000000000` | `0x40458000` | `0x00000000` |
+| 99.0 | `0x4058C00000000000` | `0x4058C000` | `0x00000000` |
+| 99.99 | `0x4058FF5C28F5C28F` | `0x4058FF5C` | `0x28F5C28F` |
+| 100.0 | `0x4059000000000000` | `0x40590000` | `0x00000000` |
+| 3.14 | `0x40091EB851EB851F` | `0x40091EB8` | `0x51EB851F` |
+
+### The Float/Double Patching Workflow
+
+```
+┌─────────────────────────────────────────────────────────────────┐
+│ 1. Identify the float/double value in the decompiled view │
+│ - Look for hex constants like 0x40454000 or 0x4045433B │
+├─────────────────────────────────────────────────────────────────┤
+│ 2. Determine if it's float (32-bit) or double (64-bit) │
+│ - printf promotes floats to doubles! │
+│ - Check if value spans r2:r3 (double) or just r0 (float) │
+├─────────────────────────────────────────────────────────────────┤
+│ 3. Check if the low word (r2) is zero or non-zero │
+│ - Zero low word = only patch the high word │
+│ - Non-zero low word = patch BOTH words │
+├─────────────────────────────────────────────────────────────────┤
+│ 4. Calculate the new IEEE 754 encoding │
+│ - Convert your desired value to IEEE 754 │
+│ - Split into high/low words │
+├─────────────────────────────────────────────────────────────────┤
+│ 5. Patch the constant(s) in Ghidra │
+│ - Right-click → Patch Data │
+│ - Replace the old encoding with the new one │
+├─────────────────────────────────────────────────────────────────┤
+│ 6. Export → Convert to UF2 → Flash → Verify │
+│ - Same workflow as integer patching │
+└─────────────────────────────────────────────────────────────────┘
+```
+
+> 💡 **Key takeaway:** Hacking doubles is the same process as hacking floats — find the IEEE 754 constant, calculate the new encoding, patch it. The only extra step is checking whether the **low word** (`r2`) is also non-zero. Clean values like `42.5` only need one patch; messy fractions like `42.52525` need two!
+
+---
+
+## ✅ Practice Exercises
+
+### Exercise 1: Patch the Float to Pi
+The float program stores `42.5`. Patch it in Ghidra so the serial output prints `3.14` instead.
+
+**Hint:** `3.14` as a double is `0x40091EB851EB851F` — the high word is `0x40091EB8` and the low word is `0x51EB851F`. You'll need to patch **both** words since the low word is non-zero!
+
+### Exercise 2: Patch the Double to a Whole Number
+The double program stores `42.52525`. Instead of patching it to `99.99` (as we did in the chapter), patch it to `100.0`.
+
+**Hint:** `100.0` as a double is `0x4059000000000000` — high word `0x40590000`, low word `0x00000000`. Notice the low word is all zeros this time — but the original low word (`0x645A1CAC`) is non-zero, so you still need to patch it to `0x00000000`!
+
+### Exercise 3: Change the Blink Speed
+The LED blinks every 500ms. Find the `sleep_ms(500)` calls in the binary and change them to `sleep_ms(100)` for faster blinking.
+
+**Hint:** Look for the value `0x1F4` (500 in hex) being loaded into a register before the delay call.
+
+### Exercise 4: Find the Format Strings
+Both programs use format strings (`"fav_num: %f\r\n"` and `"fav_num: %lf\r\n"`). Can you find these strings in Ghidra and determine where they're stored?
+
+**Hint:** Look in the `.rodata` section. Try pressing `S` in Ghidra to search for strings, or navigate to addresses near `0x10003xxx`.
+
+---
+
+## 🎓 Key Takeaways
+
+1. **Integers have fixed sizes** - `uint8_t` is 1 byte (0–255), `int8_t` is 1 byte (-128 to 127). The `u` prefix means unsigned.
+
+2. **IEEE 754 encodes floats in binary** - Sign bit, exponent (with bias), and mantissa form the encoding for both 32-bit floats and 64-bit doubles.
+
+3. **printf promotes floats to doubles** - Even when you pass a `float`, `printf` receives a 64-bit `double` due to C's variadic function rules.
+
+4. **64-bit values span two registers** - On ARM Cortex-M33, doubles use `r2` (low 32 bits) and `r3` (high 32 bits).
+
+5. **Clean fractions have zero low words** - Values like `42.5` have `0x00000000` in the low word; complex fractions like `42.52525` have non-zero low words.
+
+6. **Inline assembly controls hardware directly** - The `mcrr` coprocessor instruction talks to the GPIO block without any SDK overhead.
+
+7. **Binary patching works on any data type** - Integers, floats, and doubles can all be patched in Ghidra using the same workflow.
+
+---
+
+## 📖 Glossary
+
+| Term | Definition |
+| ----------------------- | ------------------------------------------------------------------------------ |
+| **Bias** | Constant added to the exponent in IEEE 754 (127 for float, 1023 for double) |
+| **Double** | 64-bit floating-point type following IEEE 754 double-precision format |
+| **Exponent** | Part of IEEE 754 encoding that determines the magnitude of the number |
+| **Float** | 32-bit floating-point type following IEEE 754 single-precision format |
+| **FUNCSEL** | Function Select - register field that assigns a GPIO pin's function (e.g., SIO)|
+| **GPIO** | General Purpose Input/Output - controllable pins on a microcontroller |
+| **IEEE 754** | International standard for floating-point arithmetic and binary encoding |
+| **Inline Assembly** | Assembly code embedded directly within C source using `__asm volatile` |
+| **int8_t** | Signed 8-bit integer type (-128 to 127) |
+| **IO_BANK0** | Register block at `0x40028000` that controls GPIO pin function selection |
+| **Mantissa** | Fractional part of IEEE 754 encoding (23 bits for float, 52 bits for double) |
+| **mcrr** | ARM coprocessor register transfer instruction used for GPIO control |
+| **PADS_BANK0** | Register block at `0x40038000` that controls GPIO pad electrical properties |
+| **Promotion** | Automatic conversion of a smaller type to a larger type (float → double) |
+| **Register Pair** | Two 32-bit registers (r2:r3) used together to hold a 64-bit value |
+| **UF2** | USB Flashing Format - file format for Pico 2 firmware |
+| **uint8_t** | Unsigned 8-bit integer type (0 to 255) |
+
+---
+
+## 🔗 Additional Resources
+
+### GPIO Coprocessor Reference
+
+The RP2350 GPIO coprocessor instructions:
+
+| Instruction | Description |
+| --------------------------- | ---------------------------- |
+| `mcrr p0, #4, Rt, Rt2, c0` | Set/clear GPIO output |
+| `mcrr p0, #4, Rt, Rt2, c4` | Set/clear GPIO output enable |
+
+### RP2350 Memory Map Quick Reference
+
+| Address | Description |
+| ------------ | ------------------------ |
+| `0x10000000` | XIP Flash (code) |
+| `0x20000000` | SRAM (data) |
+| `0x40028000` | IO_BANK0 (GPIO control) |
+| `0x40038000` | PADS_BANK0 (pad control) |
+| `0xd0000000` | SIO (single-cycle I/O) |
+
+### IEEE 754 Encoding Formula
+
+```
+┌─────────────────────────────────────────────────────────────────┐
+│ Float (32-bit): [1 sign] [8 exponent] [23 mantissa] │
+│ Double (64-bit): [1 sign] [11 exponent] [52 mantissa] │
+│ │
+│ Value = (-1)^sign × 2^(exponent - bias) × (1 + mantissa) │
+│ │
+│ Float bias: 127 │
+│ Double bias: 1023 │
+└─────────────────────────────────────────────────────────────────┘
+```
+
+---
+
+**Remember:** Every binary you encounter in the real world can be analyzed and understood using these same techniques. Whether it's an integer, a float, or a double — it's all just bits waiting to be decoded. Practice makes perfect!
+
+Happy hacking! 🔧
\ No newline at end of file