Embedded-Hacking/WEEK02/WEEK02-02-S.md

Embedded Systems Reverse Engineering

Repository

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) 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) 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.