mirror of
https://github.com/mytechnotalent/Embedded-Hacking.git
synced 2026-07-17 01:17:28 +02:00
Added WEEK06 and WEEK07
This commit is contained in:
Kevin Thomas
@@ -0,0 +1,157 @@
|
||||
# Embedded Systems Reverse Engineering
|
||||
[Repository](https://github.com/mytechnotalent/Embedded-Hacking)
|
||||
|
||||
## Week 7
|
||||
Constants in Embedded Systems: Debugging and Hacking Constants w/ 1602 LCD I2C Basics
|
||||
|
||||
### Exercise 2: Find All String Literals in the Binary
|
||||
|
||||
#### Objective
|
||||
Systematically search through the `0x0017_constants` binary using GDB and a hex editor to locate every human-readable string literal, catalog their addresses, contents, and purposes, and gain experience identifying data structures in compiled binaries.
|
||||
|
||||
#### Prerequisites
|
||||
- Completed Week 7 tutorial (GDB section)
|
||||
- `0x0017_constants.elf` and `0x0017_constants.bin` available in your build directory
|
||||
- GDB (`arm-none-eabi-gdb`) and OpenOCD installed
|
||||
- A hex editor (HxD, ImHex, or similar)
|
||||
|
||||
#### Task Description
|
||||
Compiled binaries contain string literals in the `.rodata` section — format strings for `printf`, LCD messages, library strings, and more. You will use two techniques to find them: (1) searching with GDB's `x/s` command to examine suspected string regions, and (2) visually scanning the binary in a hex editor for ASCII sequences. You will document every string you find, its address, and its likely purpose.
|
||||
|
||||
#### Step-by-Step Instructions
|
||||
|
||||
##### Step 1: Start the Debug Session
|
||||
|
||||
**Terminal 1 - Start OpenOCD:**
|
||||
|
||||
```bash
|
||||
openocd ^
|
||||
-s "C:\Users\flare-vm\.pico-sdk\openocd\0.12.0+dev\scripts" ^
|
||||
-f interface/cmsis-dap.cfg ^
|
||||
-f target/rp2350.cfg ^
|
||||
-c "adapter speed 5000"
|
||||
```
|
||||
|
||||
**Terminal 2 - Start GDB:**
|
||||
|
||||
```bash
|
||||
arm-none-eabi-gdb build/0x0017_constants.elf
|
||||
```
|
||||
|
||||
**Connect to target:**
|
||||
|
||||
```gdb
|
||||
(gdb) target remote :3333
|
||||
(gdb) monitor reset halt
|
||||
```
|
||||
|
||||
##### Step 2: Locate the Known Strings
|
||||
|
||||
We already know about these strings from the tutorial:
|
||||
|
||||
```gdb
|
||||
(gdb) x/s 0x10003ee8
|
||||
0x10003ee8: "Reverse"
|
||||
|
||||
(gdb) x/s 0x10003ef0
|
||||
0x10003ef0: "Engineering"
|
||||
```
|
||||
|
||||
These are the LCD display strings. Now let's find more.
|
||||
|
||||
##### Step 3: Find printf Format Strings
|
||||
|
||||
The program uses `printf("FAV_NUM: %d\r\n", ...)` and `printf("OTHER_FAV_NUM: %d\r\n", ...)`. These format strings must be somewhere in flash. Look in the `.rodata` section near the LCD strings:
|
||||
|
||||
```gdb
|
||||
(gdb) x/10s 0x10003ec0
|
||||
```
|
||||
|
||||
This displays 10 consecutive strings starting from that address. Examine the output — you should find the `printf` format strings. Try different starting addresses if needed:
|
||||
|
||||
```gdb
|
||||
(gdb) x/20s 0x10003e00
|
||||
```
|
||||
|
||||
##### Step 4: Search the Binary Systematically
|
||||
|
||||
Use GDB to scan through flash memory in large chunks, looking for readable strings:
|
||||
|
||||
```gdb
|
||||
(gdb) x/50s 0x10003d00
|
||||
```
|
||||
|
||||
Many results will be garbage (non-ASCII data interpreted as text), but real strings will stand out. Look for:
|
||||
- Format strings containing `%d`, `%s`, `%f`, `\r\n`
|
||||
- Error messages from the Pico SDK
|
||||
- Function names or debug info
|
||||
|
||||
##### Step 5: Open the Binary in a Hex Editor
|
||||
|
||||
1. Open `0x0017_constants.bin` in HxD
|
||||
2. Switch to the "Text" pane (right side) to see ASCII representation
|
||||
3. Scroll through the binary and look for readable text sequences
|
||||
|
||||
In HxD, printable ASCII characters (0x20–0x7E) are displayed as text; non-printable bytes appear as dots.
|
||||
|
||||
##### Step 6: Use Hex Editor Search
|
||||
|
||||
Most hex editors can search for ASCII text:
|
||||
|
||||
1. Press **Ctrl+F** (Find)
|
||||
2. Switch to "Text" or "String" search mode
|
||||
3. Search for known strings like `Reverse`, `FAV_NUM`, `Engineering`
|
||||
4. For each hit, note the file offset
|
||||
|
||||
##### Step 7: Catalog Your Findings
|
||||
|
||||
Create a table of all strings you find:
|
||||
|
||||
| Address | File Offset | String Content | Purpose |
|
||||
| -------------- | ----------- | ----------------------- | --------------------------- |
|
||||
| `0x10003ee8` | `0x3EE8` | "Reverse" | LCD line 1 text |
|
||||
| `0x10003ef0` | `0x3EF0` | "Engineering" | LCD line 2 text |
|
||||
| `0x10003eXX` | `0x3EXX` | "FAV_NUM: %d\r\n" | printf format string |
|
||||
| `0x10003eXX` | `0x3EXX` | "OTHER_FAV_NUM: %d\r\n" | printf format string |
|
||||
| ... | ... | ... | ... |
|
||||
|
||||
Fill in the actual addresses you discover.
|
||||
|
||||
##### Step 8: Identify SDK and Library Strings
|
||||
|
||||
The Pico SDK may include additional strings (error messages, assert messages, etc.). Look for text patterns like:
|
||||
- "panic" or "assert"
|
||||
- File paths (e.g., paths from the SDK source)
|
||||
- Function names
|
||||
|
||||
These strings reveal internal SDK behavior that isn't visible in the source code.
|
||||
|
||||
#### Expected Output
|
||||
|
||||
After completing this exercise, you should be able to:
|
||||
- Systematically enumerate string literals in a compiled binary
|
||||
- Use both GDB (`x/s`) and hex editor text view to find strings
|
||||
- Distinguish between application strings, format strings, and SDK/library strings
|
||||
- Understand that string literals reveal program functionality to a reverse engineer
|
||||
|
||||
#### Questions for Reflection
|
||||
|
||||
###### Question 1: How many distinct strings did you find? Were any of them surprising or unexpected?
|
||||
|
||||
###### Question 2: Why are strings so valuable to a reverse engineer? What can an attacker learn about a program just from its strings?
|
||||
|
||||
###### Question 3: What technique could a developer use to make strings harder to find in a binary? (Think about what the strings look like in memory.)
|
||||
|
||||
###### Question 4: The `printf` format strings contain `\r\n`. In the binary, these appear as two bytes: `0x0D 0x0A`. Why two bytes instead of the four characters `\`, `r`, `\`, `n`?
|
||||
|
||||
#### Tips and Hints
|
||||
- In GDB, `x/s` treats any address as the start of a null-terminated string — it will print garbage if the address isn't really a string
|
||||
- Use `x/Ns address` where N is a number to print N consecutive strings (useful for scanning regions)
|
||||
- In HxD, use **Edit** → **Select Block** to highlight a region and examine the text pane
|
||||
- Real strings are typically 4+ printable ASCII characters followed by a null byte (`0x00`)
|
||||
- The `.rodata` section is usually located after the `.text` (code) section in the binary
|
||||
|
||||
#### Next Steps
|
||||
- Proceed to Exercise 3 to trace the I²C struct pointer chain
|
||||
- Try the `strings` command if available: `strings 0x0017_constants.bin` will extract all printable character sequences
|
||||
- Consider: if you found a password string in an embedded device binary, what security implications would that have?
|
||||
Reference in New Issue
Block a user