mirror of
https://github.com/mytechnotalent/Embedded-Hacking.git
synced 2026-04-01 17:10:20 +02:00
72 lines
2.4 KiB
Markdown
72 lines
2.4 KiB
Markdown
# Embedded Systems Reverse Engineering
|
|
[Repository](https://github.com/mytechnotalent/Embedded-Hacking)
|
|
|
|
## Week 2
|
|
Hello, World - Debugging and Hacking Basics: Debugging and Hacking a Basic Program for the Pico 2
|
|
|
|
### Non-Credit Practice Exercise 4: Automate the Hack
|
|
|
|
#### Objective
|
|
Create a reusable GDB command that injects a string into SRAM, repoints `r0`, and resumes execution with a single call.
|
|
|
|
#### Prerequisites
|
|
- Pico 2 connected with OpenOCD, GDB, and serial monitor ready
|
|
- `build\0x0001_hello-world.elf` available
|
|
- Familiarity with breaking at `0x1000023c` and injecting strings from prior exercises
|
|
|
|
#### Task Description
|
|
You will define a custom GDB command `hack` that writes a payload to `0x20000000`, repoints `r0`, and continues execution automatically.
|
|
|
|
#### Step-by-Step Instructions
|
|
|
|
##### Step 1: Connect, Halt, and Break
|
|
|
|
```gdb
|
|
(gdb) target extended-remote :3333
|
|
(gdb) monitor reset halt
|
|
(gdb) b *0x1000023c
|
|
(gdb) c
|
|
```
|
|
|
|
##### Step 2: Define the `hack` Command
|
|
|
|
```gdb
|
|
(gdb) define hack
|
|
> set {char[14]} 0x20000000 = {'h','a','c','k','y',',',' ','w','o','r','l','d','\r','\0'}
|
|
> set $r0 = 0x20000000
|
|
> c
|
|
> end
|
|
```
|
|
|
|
##### Step 3: Invoke the Command
|
|
|
|
```gdb
|
|
(gdb) hack
|
|
```
|
|
|
|
##### Step 4: Observe Output
|
|
- PuTTY should immediately show your injected string after the command runs.
|
|
- The breakpoint will be re-hit on the next loop iteration; rerun `hack` if you want to reapply after changes.
|
|
|
|
#### Expected Output
|
|
- `hack` executes without errors, writes the payload, updates `r0`, and resumes execution.
|
|
- Serial output reflects the injected message.
|
|
|
|
#### Questions for Reflection
|
|
|
|
###### Question 1: How could you parameterize the command to accept different strings or addresses?
|
|
|
|
###### Question 2: What happens if you define `hack` before setting the breakpoint—will it still work as expected?
|
|
|
|
###### Question 3: How would you adapt this pattern for multi-step routines (e.g., patch, dump, continue)?
|
|
|
|
#### Tips and Hints
|
|
- Redefine `hack` any time you want a different payload; GDB will overwrite the prior definition.
|
|
- Keep the payload length aligned with the buffer size to avoid stray bytes.
|
|
- If the target keeps running past the breakpoint, ensure hardware breakpoints are available and set correctly.
|
|
|
|
#### Next Steps
|
|
- Create additional helper commands (e.g., `dumpstr`, `retarget`) to streamline experiments.
|
|
- Explore GDB scripting files (`.gdbinit`) to auto-load your helpers on startup.
|
|
- Try combining `hack` with watchpoints to observe memory changes live.
|