CalvinBackup/Embedded-Hacking
1
0
Fork 0
mirror of https://github.com/mytechnotalent/Embedded-Hacking.git synced 2026-07-12 23:26:33 +02:00
Code Issues Packages Projects Releases Wiki Activity

Updated WEEK05

Browse Source
This commit is contained in:
Kevin Thomas
2026-05-09 14:35:26 -04:00
parent ee664b6733
commit db4925f4b5
20 changed files with 1256 additions and 403 deletions
Download Patch File Download Diff File Expand all files Collapse all files
WEEK05/WEEK05.md
+256 -297
View File
@@ -1,6 +1,6 @@
?# Week 5: Integers and Floats in Embedded Systems: Debugging and Hacking Integers and Floats w/ Intermediate GPIO Output Assembler Analysis
# 📘 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
## 🎯 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
@@ -25,10 +25,10 @@ In C programming for embedded systems, we have special integer types that tell t
+-----------------------------------------------------------------+
| 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 |
| 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 |
| |
+-----------------------------------------------------------------+
```
@@ -42,83 +42,9 @@ The difference between `uint8_t` and `int8_t` is whether the number can be **neg
| `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 <stdio.h>
#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:
Let's say a program declares two integer variables that demonstrate the difference between **signed** and **unsigned** types:
```c
uint8_t age = 43;
@@ -127,48 +53,6 @@ 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
```
> Tip: **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
@@ -198,13 +82,89 @@ A **float** is a number that can have a decimal point. Unlike integers which can
+-----------------------------------------------------------------+
```
### How to Compute This by Hand (42.5 -> IEEE 754)
Use this exact process any time you need to encode a decimal float manually.
1. Determine the sign bit.
- `42.5` is positive, so `sign = 0`.
2. Convert the number to binary.
- Integer part: `42 = 101010 (base 2)`
- Fractional part: use repeated multiply-by-2 on the fraction.
- Start with `0.5`
- `0.5 * 2 = 1.0` -> integer part is `1` (this is the first binary fractional bit)
- Remaining fractional part is now `0.0`, so we stop.
- Therefore `0.5 = 0.1 (base 2)`.
- Combined: `42.5 = 101010.1 (base 2)`
3. Normalize to the form `1.xxxxx * 2^n`.
- `101010.1 (base 2) = 1.010101 (base 2) * 2^5`
- So the true exponent is `n = 5`.
4. Compute the stored exponent (bias 127 for float).
- `stored exponent = n + 127 = 5 + 127 = 132`
- `132` in binary is `10000100` (8 bits).
> Tip: **Why 127?** The exponent field is 8 bits wide, giving $2^8 = 256$ total values. Half of that range should represent negative exponents and half positive. The midpoint is $(2^8 / 2) - 1 = 127$. So a stored exponent of `127` means a real exponent of **0**, values below `127` are negative exponents, and values above `127` are positive exponents. Doubles use an 11-bit exponent field so their midpoint (bias) is $( 2^{11} / 2) - 1 = 1023$ instead.
5. Build the mantissa (fraction bits).
- Take bits after the leading `1.` from `1.010101` -> `010101`
- Pad with zeros to 23 bits:
- `01010100000000000000000`
6. Assemble all fields.
- `sign | exponent | mantissa`
- `0 | 10000100 | 01010100000000000000000`
- Full 32-bit pattern:
- `01000010001010100000000000000000`
7. Convert the 32-bit binary to hex (group by 4 bits).
- `0100 0010 0010 1010 0000 0000 0000 0000`
- `4 2 2 A 0 0 0 0`
- Final result: `0x422A0000`
Quick decode check (reverse direction, fully expanded):
Given the 32-bit pattern:
- `0 | 10000100 | 01010100000000000000000`
Decode it field by field:
1. Sign bit
- Sign bit is `0` -> number is positive.
- So the sign multiplier is `(+1)`.
2. Exponent field
- Exponent bits are `10000100`.
- Convert to decimal: `10000100 (base 2) = 132`.
- Float bias is `127`, so true exponent is:
- `132 - 127 = 5`.
3. Mantissa field
- Stored mantissa bits are `01010100000000000000000`.
- IEEE 754 normal numbers use an implicit leading `1`, so significand becomes:
- `1.010101 (base 2)`.
4. Rebuild the value
- Formula: `value = (+1) * 1.010101 (base 2) * 2^5`.
- Shift binary point right by 5:
- `1.010101 * 2^5 = 101010.1 (base 2)`.
5. Convert `101010.1 (base 2)` to decimal
- Integer part: `101010 = 32 + 8 + 2 = 42`
- Fraction part: `.1 = 1/2 = 0.5`
- Total: `42 + 0.5 = 42.5`
So the decoded value is exactly `42.5`.
### 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++ |
| **Range** | 0 to 255 | ±3.4 × 10^38 |
| **Encoding** | Direct binary | IEEE 754 (sign/exp/mantissa)|
| **printf** | `%d` | `%f` |
@@ -228,6 +188,10 @@ int main(void) {
}
```
> Note: `fav_num` is declared inside `main`, so by C rules it is an automatic (stack) variable. In optimized embedded builds, the compiler may avoid creating a real stack slot and instead materialize the value from read-only constant storage (typically `.rodata` and/or an ARM literal pool).
>
> An ARM **literal pool** is a small table of constants that the assembler places near code in memory. Instead of encoding a large immediate value directly in an instruction, the CPU executes a load instruction (such as `ldr`) that reads the constant from that nearby table. That is why Ghidra can show constant loads rather than a classic stack local.
**What this code does:**
1. Declares a `float` variable `fav_num` and initializes it to `42.5`
2. Initializes the serial output
@@ -260,7 +224,7 @@ The program is printing `42.500000` because `printf` with `%f` defaults to 6 dec
---
## ? Part 2.5: Setting Up Ghidra for Float Analysis
## 🔧 Part 2.5: Setting Up Ghidra for Float Analysis
### Step 3: Start Ghidra
@@ -313,7 +277,7 @@ Wait for analysis to complete (watch the progress bar in the bottom right).
---
## ? Part 2.6: Navigating and Resolving Functions
## 🔍 Part 2.6: Navigating and Resolving Functions
### Step 8: Find the Functions
@@ -347,7 +311,7 @@ For `main`, let's also fix the return type:
---
## ? Part 2.7: Analyzing the Main Function
## 🔬 Part 2.7: Analyzing the Main Function
### Step 11: Examine Main in Ghidra
@@ -357,6 +321,7 @@ You'll see something like:
```c
int main(void)
{
undefined4 uVar1;
undefined4 extraout_r1;
@@ -384,7 +349,7 @@ int main(void)
1. Click on `FUN_100030ec`
2. Right-click -> **Edit Function Signature**
3. Change to: `int __wrap_printf(char *format,...)`
3. Change to: `int printf(char *format,...)`
4. Check the **Varargs** checkbox (printf takes variable arguments!)
5. Click **OK**
@@ -394,17 +359,18 @@ 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();
stdio_init_all();
uVar1 = DAT_1000024c;
uVar2 = extraout_r1;
do {
FUN_100030ec(DAT_10000250,uVar2,0,uVar1);
printf(DAT_10000250,uVar2,0,uVar1);
uVar2 = extraout_r1_00;
} while( true );
}
@@ -472,7 +438,7 @@ Now let's check it. IEEE 754 uses a simple rule for the sign bit:
```
r3 = 0x40454000 = 0100 0000 0100 0101 0100 0000 0000 0000
^
r3 bit 31 = 0 -> sign = 0 -> Positive number
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`).
@@ -507,35 +473,35 @@ This means the number is scaled by $2^5 = 32$. In other words, the mantissa gets
- **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
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
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) ->
<- 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)
1.010101 00000... (the 1. is implicit, not stored)
```
**4. Reconstruct the value**
$$1.010101_2 \times 2^5$$
$$1.010101\text{ (base 2)} \times 2^5$$
Shift the binary point 5 places right:
$$101010.1_2$$
$$101010.1\text{ (base 2)}$$
Now convert each bit position to decimal:
@@ -547,9 +513,9 @@ Now convert each bit position to decimal:
| `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 |
| `1` (bit -1) | $2^{-1}$ | 0.5 |
$$32 + 8 + 2 + 0.5 = \mathbf{42.5} ?$$
$$32 + 8 + 2 + 0.5 = \mathbf{42.5}$$
### Step 16: Examine the Assembly
@@ -559,49 +525,47 @@ Look at the **Listing** window (assembly view). Find the main function:
*************************************************************
* FUNCTION
*************************************************************
undefined FUN_10000234 ()
undefined <UNASSIGNED> <RETURN>
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
int __stdcall main (void )
int r0:4 <RETURN>
main+1 XREF[1,1]: 1000018c (c) , 1000018a (*)
main
10000234 38 b5 push {r3,r4,r5,lr}
10000236 02 f0 91 fe bl stdio_init_all bool stdio_init_all(void)
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"
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
10000244 02 f0 52 ff bl printf int printf(char * format, ...)
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
DAT_1000024c XREF[1]: main:1000023c (R)
1000024c 00 40 45 40 undefine 40454000h
DAT_10000250 XREF[1]: main: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.
> 💡 **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
s_fav_num:_%f_100034a8 XREF[1]: main: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
## ✏️ Part 2.8: Patching the Float - Changing 42.5 to 99.0
### Step 18: Calculate the New IEEE 754 Encoding
@@ -611,15 +575,15 @@ We want to change `42.5` to `99.0`. First, we need to figure out the double-prec
| 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** |
| 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$
Read remainders bottom-to-top: 99 (base 10) = 1100011 (base 2)
**Step B - Convert the fractional part (.0) to binary:**
@@ -627,18 +591,18 @@ There is no fractional part - `.0` is exactly zero, so the fractional binary is
**Step C - Combine:**
$$99.0_{10} = 1100011.0_2$$
$$99.0\text{ (base 10)} = 1100011.0\text{ (base 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$$
$$1100011.0\text{ (base 2)} = 1.100011\text{ (base 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$
2. **Exponent:** $6 + 1023 = 1029 = 10000000101\text{ (base 2)}$
3. **Mantissa:** `1000110000000000...` (everything after the `1.`, padded with zeros to 52 bits)
4. **Full double:** `0x4058C00000000000`
@@ -654,7 +618,7 @@ Since `r2` stays `0x00000000`, we only need to patch the high word loaded into `
Look in the Listing view for the data that loads the high word of the double:
```
10000248 00 40 45 40 undefined4 40454000h
1000024c 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`.
@@ -662,16 +626,15 @@ This is the 32-bit constant that gets loaded into `r3` - the high word of our do
### 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`
2. Click on the Pencil icon to enable byte editing
3. At address `1000024c`, overwrite `00 40 45 40` with `00 C0 58 40` (little-endian for `0x40454000 -> 0x4058C000`)
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
## 🚀 Part 2.9: Export and Test the Hacked Binary
### Step 21: Export the Patched Binary
@@ -686,7 +649,7 @@ This changes the high word from `0x40454000` (42.5 as double) to `0x4058C000` (9
**Open a terminal and navigate to your project directory:**
```powershell
cd C:\Users\assem.KEVINTHOMAS\OneDrive\Documents\Embedded-Hacking\0x000e_floating-point-data-type
cd C:\Users\flare-vm\Desktop\Embedded-Hacking-main\0x000e_floating-point-data-type
```
**Run the conversion command:**
@@ -710,7 +673,7 @@ fav_num: 99.000000
...
```
? **BOOM! We hacked the float!** The value changed from `42.5` to `99.0`!
🎉 **BOOM! We hacked the float!** The value changed from `42.5` to `99.0`!
---
@@ -748,7 +711,7 @@ A **double** (short for "double-precision floating-point") is like a `float` but
| **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+++? |
| **Range** | ±3.4 × 10^38 | ±1.8 × 10^308 |
| **printf** | `%f` | `%lf` |
| **ARM passing** | Promoted to double | Native in `r2:r3` |
@@ -806,7 +769,7 @@ The program is printing `42.525250` because `printf` with `%lf` defaults to 6 de
---
## ? Part 3.5: Setting Up Ghidra for Double Analysis
## 🔧 Part 3.5: Setting Up Ghidra for Double Analysis
### Step 3: Start Ghidra
@@ -859,7 +822,7 @@ Wait for analysis to complete (watch the progress bar in the bottom right).
---
## ? Part 3.6: Navigating and Resolving Functions
## 🔍 Part 3.6: Navigating and Resolving Functions
### Step 8: Find the Functions
@@ -893,7 +856,7 @@ For `main`, let's also fix the return type:
---
## ? Part 3.7: Analyzing the Main Function
## 🔬 Part 3.7: Analyzing the Main Function
### Step 11: Examine Main in Ghidra
@@ -901,48 +864,9 @@ 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;
@@ -961,6 +885,46 @@ int main(void)
}
```
### 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 to: `int printf(char *format,...)`
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;
stdio_init_all();
uVar3 = extraout_r1;
do {
printf(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.
@@ -974,7 +938,7 @@ A 64-bit double is passed in two 32-bit registers:
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!
> 💡 **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
@@ -992,12 +956,10 @@ Bit: 63 62-52 (11 bits) 51-32 (20 bits) 3
+---+-----------------------+------------------------------------------+------------------------------------------+
| 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)
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**
@@ -1007,7 +969,7 @@ The sign bit is bit 63 of the 64-bit double, which is bit 31 of r3 (the high reg
```
r3 = 0x4045433B = 0100 0000 0100 0101 0100 0011 0011 1011
^
r3 bit 31 = 0 -> sign = 0 -> Positive number ?
r3 bit 31 = 0 -> sign = 0 -> Positive number ✓
```
**2. Exponent - bits 62-52 = bits 30-20 of r3**
@@ -1042,29 +1004,29 @@ 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
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 ->
<- 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)
1.0101010000110011101101100100010110100001110010101100 (the 1. is implicit, not stored)
```
**4. Reconstruct the value**
$$1.0101010000110011101101100100..._2 \times 2^5$$
$$1.0101010000110011101101100100...\text{ (base 2)} \times 2^5$$
Shift the binary point 5 places right:
$$101010.10000110011101101100100010110100001110010101100_2$$
$$101010.10000110011101101100100010110100001110010101100\text{ (base 2)}$$
**Integer part** (`101010`):
@@ -1083,25 +1045,25 @@ $$32 + 8 + 2 = \mathbf{42}$$
| 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 |
| `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} ?$$
$$42 + 0.52525 = \mathbf{42.52525} \checkmark$$
### Step 16: Examine the Assembly
@@ -1111,58 +1073,57 @@ Look at the **Listing** window (assembly view). Find the main function:
*************************************************************
* FUNCTION
*************************************************************
undefined FUN_10000238 ()
undefined <UNASSIGNED> <RETURN>
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
int __stdcall main (void )
int r0:4 <RETURN>
main+1 XREF[1,1]: 1000018c (c) , 1000018a (*)
main
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()
10000240 02 f0 90 fe bl stdio_init_all bool stdio_init_all(void)
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"
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
1000024a 02 f0 53 ff bl printf int printf(char * format, ...)
1000024e f9 e7 b LAB_10000244
DAT_10000250 XREF[1]: main:10000248 (R)
10000250 b0 34 00 10 undefine 100034B0h ? -> 100034b0
DAT_10000254 XREF[1]: main:1000023c (R)
10000254 ac 1c 5a 64 undefine 645A1CACh
DAT_10000258 XREF[1]: main: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.
> 💡 **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
s_fav_num:_%lf_100034b0 XREF[1]: main: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
## ✏️ 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$
1. $99.99 = 1.5623... \times 2^6 = 1.100011111111...\text{ (base 2)} \times 2^6$
2. **Sign:** `0` (positive)
3. **Exponent:** $6 + 1023 = 1029 = 10000000101_2$
4. **Mantissa:** `1000111111010111000010100011110101110000101000111..._2$
3. **Exponent:** $6 + 1023 = 1029 = 10000000101\text{ (base 2)}$
4. **Mantissa:** `1000111111010111000010100011110101110000101000111... (base 2)`
5. **Full double:** `0x4058FF5C28F5C28F`
| Register | Old Value | New Value |
@@ -1178,35 +1139,35 @@ Look in the Listing view for the two data constants:
**Low word (loaded into `r2`):**
```
10000254 ac 1c 5a 64 undefined4 645A1CACh
10000254 ac 1c 5a 64 undefined4 645A1CACh
```
**High word (loaded into `r3`):**
```
10000258 3b 43 45 40 undefined4 4045433Bh
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`
2. Open the Bytes window and enable byte editing (Pencil icon)
3. Overwrite bytes `ac 1c 5a 64` with `8f c2 f5 28` (little-endian for `0x645A1CAC -> 0x28F5C28F`)
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`
2. Keep byte editing enabled in the Bytes window
3. Overwrite bytes `3b 43 45 40` with `5c ff 58 40` (little-endian for `0x4045433B -> 0x4058FF5C`)
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!
> 💡 **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
## 🚀 Part 3.9: Export and Test the Hacked Binary
### Step 21: Export the Patched Binary
@@ -1221,7 +1182,7 @@ This changes the full 64-bit double from `0x4045433B645A1CAC` (42.52525) to `0x4
**Open a terminal and navigate to your project directory:**
```powershell
cd C:\Users\assem.KEVINTHOMAS\OneDrive\Documents\Embedded-Hacking\0x0011_double-floating-point-data-type
cd C:\Users\flare-vm\Desktop\Embedded-Hacking-main\0x0011_double-floating-point-data-type
```
**Run the conversion command:**
@@ -1245,11 +1206,11 @@ fav_num: 99.990000
...
```
? **BOOM! We hacked the double!** The value changed from `42.52525` to `99.99`!
🎉 **BOOM! We hacked the double!** The value changed from `42.52525` to `99.99`!
---
## ? Part 3.95: Summary - Float and Double Analysis
## 📊 Part 3.95: Summary - Float and Double Analysis
### What We Accomplished
@@ -1293,7 +1254,7 @@ fav_num: 99.990000
| - Split into high/low words |
+-----------------------------------------------------------------+
| 5. Patch the constant(s) in Ghidra |
| - Right-click -> Patch Data |
| - Edit bytes in the Bytes window (Pencil mode) |
| - Replace the old encoding with the new one |
+-----------------------------------------------------------------+
| 6. Export -> Convert to UF2 -> Flash -> Verify |
@@ -1307,7 +1268,7 @@ fav_num: 99.990000
---
## ? Key Takeaways
## 💡 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.
@@ -1325,7 +1286,7 @@ fav_num: 99.990000
---
## ? Glossary
## 📖 Glossary
| Term | Definition |
| ----------------------- | ------------------------------------------------------------------------------ |
@@ -1349,7 +1310,7 @@ fav_num: 99.990000
---
## ? Additional Resources
## 📚 Additional Resources
### GPIO Coprocessor Reference
@@ -1388,6 +1349,4 @@ The RP2350 GPIO coprocessor instructions:
**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! ?
Happy hacking! 🎉