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 0x20001000 instead of 0x20000000 to demonstrate that multiple safe SRAM locations can be used for injection.

GDB Commands

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