Files
Embedded-Hacking/WEEK02/WEEK02-02-S.md
T
2026-03-19 15:01:07 -04:00

39 lines
1.8 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 `0x20001000` instead of `0x20000000` to demonstrate that multiple safe SRAM locations can be used for injection.
##### GDB Commands
```gdb
(gdb) b *0x1000023c
(gdb) c
(gdb) set {char[14]} 0x20001000 = {'h','a','c','k','e','d','!','!','!','\r','\0'}
(gdb) set $r0 = 0x20001000
(gdb) c
```
##### Verification
```gdb
(gdb) x/s 0x20001000 # Shows "hacked!!!\r"
```
#### Reflection Answers
1. **How can you ensure `0x20001000` does not collide with stack usage?**
The stack pointer was observed at `0x20082000` (top of stack) and grows downward. Since `0x20001000` is far below the stack region, there is substantial separation. Use `info registers sp` in GDB to verify the current stack pointer is well 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?**
Start from the bottom of SRAM (`0x20000000`) for small static payloads, working upward. Check the linker script to understand memory regions. In this simple program with no heap allocations, both `0x20000000` and `0x20001000` are safe. In larger programs, examine the `.bss` and `.data` section boundaries.