mirror of
https://github.com/mytechnotalent/Embedded-Hacking.git
synced 2026-08-14 23:20:27 +02:00
39 lines
1.7 KiB
Markdown
39 lines
1.7 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 2 Solution: Use a Different SRAM Address
|
|
|
|
#### Answers
|
|
|
|
##### Attack Summary
|
|
Write the payload to `0x20041000` instead of `0x20040000` to demonstrate that multiple safe SRAM locations can be used for injection.
|
|
|
|
##### GDB Commands
|
|
|
|
```gdb
|
|
(gdb) b *0x1000023c
|
|
(gdb) c
|
|
(gdb) set {char[14]} 0x20041000 = {'h','a','c','k','e','d','!','!','!','\r','\0'}
|
|
(gdb) set $r0 = 0x20041000
|
|
(gdb) c
|
|
```
|
|
|
|
##### Verification
|
|
```gdb
|
|
(gdb) x/s 0x20041000 # Shows "hacked!!!\r"
|
|
```
|
|
|
|
#### Reflection Answers
|
|
|
|
1. **How can you ensure `0x20041000` does not collide with stack usage?**
|
|
The stack pointer was observed at `0x20082000` (top of stack) and grows downward. Since `0x20041000` is well below the stack region, there is substantial separation. Use `info registers sp` in GDB to verify the current stack pointer is above your injection address.
|
|
|
|
2. **What symptoms would indicate you overwrote an active stack frame?**
|
|
The program would crash when attempting to return from a function. Symptoms include: unexpected address exceptions, invalid memory access faults, or the program jumping to random addresses. The Link Register return path gets corrupted.
|
|
|
|
3. **How would you pick a safe SRAM offset in a larger program with dynamic allocations?**
|
|
Choose a region with clear separation from vectors, stack growth, and active data. In this simple program, `0x20040000` and `0x20041000` are practical safe offsets. In larger programs, inspect linker sections (`.data`, `.bss`, heap) and validate with runtime `sp` checks.
|