mirror of
https://github.com/mytechnotalent/Embedded-Hacking.git
synced 2026-06-11 00:27:48 +02:00
Overhall w/ slides
This commit is contained in:
+10
-10
@@ -1,4 +1,4 @@
|
||||
# Embedded Systems Reverse Engineering
|
||||
# Embedded Systems Reverse Engineering
|
||||
[Repository](https://github.com/mytechnotalent/Embedded-Hacking)
|
||||
|
||||
## Week 1
|
||||
@@ -99,7 +99,7 @@ Based on what you found:
|
||||
- Is each character one byte or more? __________
|
||||
- What does `\r` and `\n` represent? (Hint: `\r` = carriage return, `\n` = newline)
|
||||
|
||||
## Expected Output
|
||||
#### Expected Output
|
||||
|
||||
You should be able to fill in a summary like:
|
||||
|
||||
@@ -112,40 +112,40 @@ Referenced by: [Function names]
|
||||
Used in: [How the program uses it]
|
||||
```
|
||||
|
||||
## Deeper Exploration (Optional Challenge)
|
||||
#### Deeper Exploration (Optional Challenge)
|
||||
|
||||
### Challenge 1: Follow the String Usage
|
||||
##### Challenge 1: Follow the String Usage
|
||||
1. From the cross-references you found, click on the instruction that uses the string
|
||||
2. You should navigate to the `ldr` (load) instruction that loads the string's address into register `r0`
|
||||
3. This is how the `printf` function gets the pointer to the string!
|
||||
|
||||
### Challenge 2: Find Other Strings
|
||||
##### Challenge 2: Find Other Strings
|
||||
1. Go back to the Defined Strings window
|
||||
2. Look for other strings in the binary
|
||||
3. Are there any other text strings besides "hello, world"?
|
||||
4. If yes, where are they and what are they used for?
|
||||
|
||||
### Challenge 3: Understand Little-Endian
|
||||
##### Challenge 3: Understand Little-Endian
|
||||
1. When Ghidra shows the string address in the `ldr` instruction, it's showing a number
|
||||
2. Look at the raw bytes of that address value
|
||||
3. Notice how the bytes are stored in "backwards" order? That's little-endian!
|
||||
4. Can you convert the hex bytes to the actual address?
|
||||
|
||||
## Questions for Reflection
|
||||
#### Questions for Reflection
|
||||
|
||||
1. **Why is the string stored in Flash memory?** Why not in RAM?
|
||||
2. **How does `printf()` know where to find the string?** (Hint: The address is loaded into `r0`)
|
||||
3. **What would happen if we didn't have the `\r\n` at the end?** How would the output look?
|
||||
4. **Could we modify this string at runtime?** Why or why not?
|
||||
|
||||
## Tips and Hints
|
||||
#### Tips and Hints
|
||||
|
||||
- Strings in compiled binaries are often stored in read-only memory (Flash) to save RAM
|
||||
- The `\r` and `\n` characters are special: they're single bytes (0x0D and 0x0A in hex)
|
||||
- When you see a string in Ghidra's listing, the ASCII representation is shown on the right side
|
||||
- You can scroll left/right in the Listing view to see different representations (hex, ASCII, disassembly)
|
||||
|
||||
## Real-World Application
|
||||
#### Real-World Application
|
||||
|
||||
Understanding where strings are stored is crucial for:
|
||||
- **Firmware modification**: Finding text messages to modify
|
||||
@@ -153,7 +153,7 @@ Understanding where strings are stored is crucial for:
|
||||
- **Vulnerability analysis**: Finding format string bugs or hardcoded credentials
|
||||
- **Localization**: Finding where text needs to be translated
|
||||
|
||||
## Summary
|
||||
#### Summary
|
||||
|
||||
By completing this exercise, you've learned:
|
||||
1. How to find strings in a binary using Ghidra's Defined Strings window
|
||||
|
||||
+13
-13
@@ -1,4 +1,4 @@
|
||||
# Embedded Systems Reverse Engineering
|
||||
# Embedded Systems Reverse Engineering
|
||||
[Repository](https://github.com/mytechnotalent/Embedded-Hacking)
|
||||
|
||||
## Week 1
|
||||
@@ -31,7 +31,7 @@ A **cross-reference** is a link between different parts of the code:
|
||||
|
||||
In this exercise, we're tracking **code → data** references to understand where and how the program uses the "hello, world" string.
|
||||
|
||||
## Step-by-Step Instructions
|
||||
#### Step-by-Step Instructions
|
||||
|
||||
##### Step 1: Navigate to the main Function
|
||||
|
||||
@@ -94,13 +94,13 @@ This means:
|
||||
- What is the address of the data reference you found? (e.g., `DAT_10000244`)
|
||||
- __________
|
||||
|
||||
#### Question 2: Referenced By
|
||||
###### Question 2: Referenced By
|
||||
- How many places reference this data?
|
||||
- __________
|
||||
- Which function(s) use it?
|
||||
- __________
|
||||
|
||||
#### Question 3: Reference Type
|
||||
###### Question 3: Reference Type
|
||||
- Is it a read or write operation?
|
||||
- __________
|
||||
- Why? (What's the program doing with this data?)
|
||||
@@ -119,9 +119,9 @@ This means:
|
||||
- Then a function (probably `printf` or `puts`) is called with `r0` as the argument
|
||||
- Can you trace this complete flow?
|
||||
|
||||
## Deeper Analysis (Optional Challenge)
|
||||
#### Deeper Analysis (Optional Challenge)
|
||||
|
||||
### Challenge 1: Find the Actual String Address
|
||||
##### Challenge 1: Find the Actual String Address
|
||||
1. Navigate to the `DAT_10000244` location
|
||||
2. Look at the value stored there
|
||||
3. Can you decode the hex bytes and find the actual address of "hello, world"?
|
||||
@@ -131,7 +131,7 @@ This means:
|
||||
If you see bytes: `CC 19 00 10`
|
||||
Read backwards: `10 00 19 CC` = `0x100019CC`
|
||||
|
||||
### Challenge 2: Understand the Indirection
|
||||
##### Challenge 2: Understand the Indirection
|
||||
1. In C, if we want to load an address, we do: `char *ptr = &some_string;`
|
||||
2. Then to use it: `printf(ptr);`
|
||||
3. In assembly, this becomes:
|
||||
@@ -139,12 +139,12 @@ Read backwards: `10 00 19 CC` = `0x100019CC`
|
||||
- Call the function: `bl printf`
|
||||
4. Can you see this pattern in the assembly?
|
||||
|
||||
### Challenge 3: Follow Multiple References
|
||||
##### Challenge 3: Follow Multiple References
|
||||
1. Try this with different data items in the binary
|
||||
2. Find a data reference that has **multiple** cross-references
|
||||
3. What data is used in more than one place?
|
||||
|
||||
## Questions for Reflection
|
||||
#### Questions for Reflection
|
||||
|
||||
1. **Why does the code need to load an address from memory?**
|
||||
- Why can't it just use the address directly?
|
||||
@@ -164,14 +164,14 @@ Read backwards: `10 00 19 CC` = `0x100019CC`
|
||||
- Data section (constants/strings)
|
||||
- Is everything at different addresses for a reason?
|
||||
|
||||
## Tips and Hints
|
||||
#### Tips and Hints
|
||||
|
||||
- If you right-click and don't see "References", try right-clicking directly on the instruction address instead
|
||||
- You can also use **Search → For Cross References** from the menu for a more advanced search
|
||||
- In the Decompile view (right side), cross-references may be shown in a different format or with different colors
|
||||
- Multi-level references: You can right-click on a data item and then follow the chain to another data item
|
||||
|
||||
## Real-World Applications
|
||||
#### Real-World Applications
|
||||
|
||||
Understanding cross-references is crucial for:
|
||||
- **Vulnerability hunting**: Finding where user input flows through the code
|
||||
@@ -179,7 +179,7 @@ Understanding cross-references is crucial for:
|
||||
- **Malware analysis**: Tracking command-and-control server addresses or encryption keys
|
||||
- **Reverse engineering**: Understanding program logic by following data dependencies
|
||||
|
||||
## Summary
|
||||
#### Summary
|
||||
|
||||
By completing this exercise, you've learned:
|
||||
1. How to find and interpret cross-references in Ghidra
|
||||
@@ -188,7 +188,7 @@ By completing this exercise, you've learned:
|
||||
4. The relationship between high-level C code and assembly-level data flow
|
||||
5. How addresses are indirectly referenced in position-independent code
|
||||
|
||||
## Expected Final Understanding
|
||||
#### Expected Final Understanding
|
||||
|
||||
You should now understand this flow:
|
||||
```
|
||||
|
||||
+18
-18
@@ -1,4 +1,4 @@
|
||||
# Embedded Systems Reverse Engineering
|
||||
# Embedded Systems Reverse Engineering
|
||||
[Repository](https://github.com/mytechnotalent/Embedded-Hacking)
|
||||
|
||||
## Week 1
|
||||
@@ -33,7 +33,7 @@ Before you start, make sure:
|
||||
- You have **GDB** (specifically `arm-none-eabi-gdb`) installed
|
||||
- Your binary file (`0x0001_hello-world.elf`) is available in the `build/` directory
|
||||
|
||||
## Step-by-Step Instructions
|
||||
#### Step-by-Step Instructions
|
||||
|
||||
##### Step 1: Start OpenOCD in Terminal 1
|
||||
|
||||
@@ -64,12 +64,12 @@ Info : accepting 'gdb' connection on tcp/3333
|
||||
Open a **second terminal window** and navigate to your project directory:
|
||||
|
||||
```
|
||||
arm-none-eabi-gdb -q build/0x0001_hello-world.elf
|
||||
arm-none-eabi-gdb build\0x0001_hello-world.elf
|
||||
```
|
||||
|
||||
**Expected Output:**
|
||||
```
|
||||
Reading symbols from build/0x0001_hello-world.elf...
|
||||
Reading symbols from build\0x0001_hello-world.elf...
|
||||
(gdb)
|
||||
```
|
||||
|
||||
@@ -257,37 +257,37 @@ Based on what you've observed:
|
||||
- Are they the same?
|
||||
- __________
|
||||
|
||||
## Deeper Exploration (Optional Challenge)
|
||||
#### Deeper Exploration (Optional Challenge)
|
||||
|
||||
### Challenge 1: Step Through stdio_init_all
|
||||
##### Challenge 1: Step Through stdio_init_all
|
||||
1. Continue stepping: `si` (step into) or `ni` (next instruction)
|
||||
2. Eventually, you'll reach `bl 0x1000156c <stdio_init_all>`
|
||||
3. Use `si` to step **into** that function
|
||||
4. What instructions do you see?
|
||||
5. What registers are being modified?
|
||||
|
||||
### Challenge 2: View Specific Registers
|
||||
##### Challenge 2: View Specific Registers
|
||||
Instead of viewing all registers, you can view just a few:
|
||||
```gdb
|
||||
i r pc sp lr r0 r1 r2
|
||||
```
|
||||
This shows only the registers you care about.
|
||||
|
||||
### Challenge 3: Examine Memory
|
||||
##### Challenge 3: Examine Memory
|
||||
To examine memory at a specific address (e.g., where the string is):
|
||||
```gdb
|
||||
x/16b 0x100019cc
|
||||
```
|
||||
This displays 16 bytes (`b` = byte) starting at address `0x100019cc`. Can you see the "hello, world" string?
|
||||
|
||||
### Challenge 4: Set a Conditional Breakpoint
|
||||
##### Challenge 4: Set a Conditional Breakpoint
|
||||
Set a breakpoint that only triggers after a certain condition:
|
||||
```gdb
|
||||
b *0x1000023a if $r0 != 0
|
||||
```
|
||||
This is useful when you want to break on a condition rather than every time.
|
||||
|
||||
## Questions for Reflection
|
||||
#### Questions for Reflection
|
||||
|
||||
1. **Why does GDB show both the C source line AND the assembly?**
|
||||
- This is because the .elf file contains debug symbols
|
||||
@@ -304,7 +304,7 @@ This is useful when you want to break on a condition rather than every time.
|
||||
- `si` steps into function calls
|
||||
- `ni` executes entire functions without stopping inside them
|
||||
|
||||
## Important GDB Commands Reference
|
||||
#### Important GDB Commands Reference
|
||||
|
||||
| Command | Short Form | What It Does |
|
||||
| ---------------------- | ---------- | ------------------------------------ |
|
||||
@@ -324,30 +324,30 @@ This is useful when you want to break on a condition rather than every time.
|
||||
- `x/16b 0x20000000` - examine 16 bytes starting at RAM address
|
||||
- `x/4w 0x10000000` - examine 4 words (4-byte values) starting at Flash address
|
||||
|
||||
## Troubleshooting
|
||||
#### Troubleshooting
|
||||
|
||||
### Problem: "OpenOCD not found"
|
||||
##### Problem: "OpenOCD not found"
|
||||
**Solution:** Make sure OpenOCD is in your PATH or use the full path to the executable
|
||||
|
||||
### Problem: "Target not responding"
|
||||
##### Problem: "Target not responding"
|
||||
**Solution:**
|
||||
- Check that your Pico 2 is properly connected
|
||||
- Make sure OpenOCD is running and shows "accepting 'gdb' connection"
|
||||
- Restart both OpenOCD and GDB
|
||||
|
||||
### Problem: "Cannot find breakpoint at main"
|
||||
##### Problem: "Cannot find breakpoint at main"
|
||||
**Solution:**
|
||||
- Make sure you compiled with debug symbols
|
||||
- The .elf file must include symbol information
|
||||
- Try breaking at an address instead: `b *0x10000234`
|
||||
|
||||
### Problem: GDB shows "No source available"
|
||||
##### Problem: GDB shows "No source available"
|
||||
**Solution:**
|
||||
- This happens with stripped binaries
|
||||
- You can still see assembly with `disas`
|
||||
- You can still examine memory and registers
|
||||
|
||||
## Summary
|
||||
#### Summary
|
||||
|
||||
By completing this exercise, you've:
|
||||
1. ✅ Set up OpenOCD as a debug server
|
||||
@@ -363,7 +363,7 @@ You're now ready for Week 2, where you'll:
|
||||
- Understand program flow in detail
|
||||
- Use this knowledge to modify running code
|
||||
|
||||
## Next Steps
|
||||
#### Next Steps
|
||||
|
||||
1. **Close GDB**: Type `quit` or `q` to exit
|
||||
2. **Close OpenOCD**: Type `Ctrl+C` in the OpenOCD terminal
|
||||
|
||||
Binary file not shown.
+41
-44
@@ -1,9 +1,6 @@
|
||||
# Embedded Systems Reverse Engineering
|
||||
[Repository](https://github.com/mytechnotalent/Embedded-Hacking)
|
||||
# Week 1: Introduction and Overview of Embedded Reverse Engineering: Ethics, Scoping, and Basic Concepts
|
||||
|
||||
## Week 1: Introduction and Overview of Embedded Reverse Engineering: Ethics, Scoping, and Basic Concepts
|
||||
|
||||
### 🎯 What You'll Learn This Week
|
||||
## 🎯 What You'll Learn This Week
|
||||
|
||||
By the end of this week, you will be able to:
|
||||
- Understand what a microcontroller is and how it works
|
||||
@@ -16,17 +13,17 @@ By the end of this week, you will be able to:
|
||||
|
||||
---
|
||||
|
||||
### 📚 Part 1: Understanding the Basics
|
||||
## 📚 Part 1: Understanding the Basics
|
||||
|
||||
#### What is a Microcontroller?
|
||||
### What is a Microcontroller?
|
||||
|
||||
Think of a microcontroller as a tiny computer on a single chip. Just like your laptop has a processor, memory, and storage, a microcontroller has all of these packed into one small chip. The **RP2350** is the microcontroller chip that powers the **Raspberry Pi Pico 2**.
|
||||
|
||||
#### What is the ARM Cortex-M33?
|
||||
### What is the ARM Cortex-M33?
|
||||
|
||||
The RP2350 has two "brains" inside it - we call these **cores**. One brain uses ARM Cortex-M33 instructions, and the other can use RISC-V instructions. In this course, we'll focus on the **ARM Cortex-M33** core because it's more commonly used in the industry.
|
||||
|
||||
#### What is Reverse Engineering?
|
||||
### What is Reverse Engineering?
|
||||
|
||||
Reverse engineering is like being a detective for code. Instead of writing code and compiling it, we take compiled code (the 1s and 0s that the computer actually runs) and figure out what it does. This is useful for:
|
||||
- Understanding how things work
|
||||
@@ -35,13 +32,13 @@ Reverse engineering is like being a detective for code. Instead of writing code
|
||||
|
||||
---
|
||||
|
||||
### 📚 Part 2: Understanding Processor Registers
|
||||
## 📚 Part 2: Understanding Processor Registers
|
||||
|
||||
#### What is a Register?
|
||||
### What is a Register?
|
||||
|
||||
A **register** is like a tiny, super-fast storage box inside the processor. The processor uses registers to hold numbers while it's doing calculations. Think of them like the short-term memory your brain uses when doing math in your head.
|
||||
|
||||
#### The ARM Cortex-M33 Registers
|
||||
### The ARM Cortex-M33 Registers
|
||||
|
||||
The ARM Cortex-M33 has several important registers:
|
||||
|
||||
@@ -104,9 +101,9 @@ The Program Counter always points to the **next instruction** the processor will
|
||||
|
||||
---
|
||||
|
||||
### 📚 Part 3: Understanding Memory Layout
|
||||
## 📚 Part 3: Understanding Memory Layout
|
||||
|
||||
#### XIP - Execute In Place
|
||||
### XIP - Execute In Place
|
||||
|
||||
The RP2350 uses something called **XIP (Execute In Place)**. This means the processor can run code directly from the flash memory (where your program is stored) without copying it to RAM first.
|
||||
|
||||
@@ -114,7 +111,7 @@ The RP2350 uses something called **XIP (Execute In Place)**. This means the proc
|
||||
|
||||
This is where your program code starts in flash memory. Remember this address - we'll use it a lot!
|
||||
|
||||
#### Memory Map Overview
|
||||
### Memory Map Overview
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────┐
|
||||
@@ -128,7 +125,7 @@ This is where your program code starts in flash memory. Remember this address -
|
||||
└─────────────────────────────────────┘
|
||||
```
|
||||
|
||||
#### Stack vs Heap
|
||||
### Stack vs Heap
|
||||
|
||||
| Stack | Heap |
|
||||
| ---------------------------------------- | ---------------------------------- |
|
||||
@@ -140,7 +137,7 @@ This is where your program code starts in flash memory. Remember this address -
|
||||
|
||||
---
|
||||
|
||||
### 📚 Part 3.5: Reviewing Our Hello World Code
|
||||
## 📚 Part 3.5: Reviewing Our Hello World Code
|
||||
|
||||
Before we start debugging, let's understand the code we'll be working with. Here's our `0x0001_hello-world.c` program:
|
||||
|
||||
@@ -156,7 +153,7 @@ int main(void) {
|
||||
}
|
||||
```
|
||||
|
||||
#### Breaking Down the Code
|
||||
### Breaking Down the Code
|
||||
|
||||
##### The Includes
|
||||
|
||||
@@ -202,14 +199,14 @@ while (true)
|
||||
>
|
||||
> In embedded systems, we often use both carriage return (`\r`) and newline (`\n`) together. The `\r` moves the cursor back to the beginning of the line, and `\n` moves to the next line. This ensures proper display across different terminal programs.
|
||||
|
||||
#### What Happens When This Runs?
|
||||
### What Happens When This Runs?
|
||||
|
||||
1. **Power on** - The Pico boots up and starts executing code from flash memory
|
||||
2. **`stdio_init_all()`** - Sets up USB and/or UART for communication
|
||||
3. **Infinite loop begins** - The program enters the `while(true)` loop
|
||||
4. **Print forever** - "hello, world" is sent over and over as fast as possible
|
||||
|
||||
#### Why This Code is Perfect for Learning
|
||||
### Why This Code is Perfect for Learning
|
||||
|
||||
This simple program is ideal for reverse engineering practice because:
|
||||
- It has a clear, recognizable function call (`printf`)
|
||||
@@ -219,7 +216,7 @@ This simple program is ideal for reverse engineering practice because:
|
||||
|
||||
When we debug this code, we'll be able to see how the C code translates to ARM assembly instructions!
|
||||
|
||||
#### Compiling and Flashing to the Pico 2
|
||||
### Compiling and Flashing to the Pico 2
|
||||
|
||||
Now that we understand the code, let's get it running on our hardware:
|
||||
|
||||
@@ -252,9 +249,9 @@ Once flashed, your Pico 2 will immediately start executing the hello-world progr
|
||||
|
||||
---
|
||||
|
||||
### 📚 Part 4: Dynamic Analysis with GDB
|
||||
## 📚 Part 4: Dynamic Analysis with GDB
|
||||
|
||||
#### Prerequisites
|
||||
### Prerequisites
|
||||
|
||||
Before we start, make sure you have:
|
||||
1. A Raspberry Pi Pico 2 board
|
||||
@@ -262,11 +259,11 @@ Before we start, make sure you have:
|
||||
3. OpenOCD or another debug probe connection
|
||||
4. The sample "hello-world" binary loaded on your Pico 2
|
||||
|
||||
#### Connecting to Your Pico 2 with OpenOCD
|
||||
### Connecting to Your Pico 2 with OpenOCD
|
||||
|
||||
Open a terminal and start OpenOCD:
|
||||
|
||||
```bash
|
||||
```powershell
|
||||
openocd ^
|
||||
-s "C:\Users\flare-vm\.pico-sdk\openocd\0.12.0+dev\scripts" ^
|
||||
-f interface/cmsis-dap.cfg ^
|
||||
@@ -274,22 +271,22 @@ openocd ^
|
||||
-c "adapter speed 5000"
|
||||
```
|
||||
|
||||
#### Connecting to Your Pico 2 with GDB
|
||||
### Connecting to Your Pico 2 with GDB
|
||||
|
||||
Open another terminal and start GDB with your binary:
|
||||
|
||||
```bash
|
||||
arm-none-eabi-gdb -q build/0x0001_hello-world.elf
|
||||
```powershell
|
||||
arm-none-eabi-gdb build\0x0001_hello-world.elf
|
||||
```
|
||||
|
||||
Connect to your target:
|
||||
|
||||
```bash
|
||||
```powershell
|
||||
(gdb) target extended-remote localhost:3333
|
||||
(gdb) monitor reset halt
|
||||
```
|
||||
|
||||
#### Basic GDB Commands: Your First Steps
|
||||
### Basic GDB Commands: Your First Steps
|
||||
|
||||
Now that we're connected, let's learn three essential GDB commands that you'll use constantly in embedded reverse engineering.
|
||||
|
||||
@@ -378,7 +375,7 @@ xpsr 0x69000000 1761607680
|
||||
|
||||
> 💡 **Tip:** You can also use `i r pc sp lr` to show only specific registers you care about.
|
||||
|
||||
#### Quick Reference: Essential GDB Commands
|
||||
### Quick Reference: Essential GDB Commands
|
||||
|
||||
| Command | Short Form | What It Does |
|
||||
| --------------------- | ---------- | ------------------------------------ |
|
||||
@@ -397,9 +394,9 @@ xpsr 0x69000000 1761607680
|
||||
|
||||
---
|
||||
|
||||
### 🔬 Part 5: Static Analysis with Ghidra
|
||||
## 🔬 Part 5: Static Analysis with Ghidra
|
||||
|
||||
#### Setting Up Your First Ghidra Project
|
||||
### Setting Up Your First Ghidra Project
|
||||
|
||||
Before we dive into GDB debugging, let's set up Ghidra to analyze our hello-world binary. Ghidra is a powerful reverse engineering tool that will help us visualize the disassembly and decompiled code.
|
||||
|
||||
@@ -435,7 +432,7 @@ When prompted, click **Yes** to auto-analyze the binary. Accept the default anal
|
||||
|
||||
Ghidra will now process the binary, identifying functions, strings, and cross-references. This may take a moment.
|
||||
|
||||
#### Reviewing the Main Function in Ghidra
|
||||
### Reviewing the Main Function in Ghidra
|
||||
|
||||
Once analysis is complete, let's find our `main` function:
|
||||
|
||||
@@ -502,9 +499,9 @@ In future weeks, we'll work with `.bin` files that have been stripped of symbols
|
||||
|
||||
---
|
||||
|
||||
### 📊 Part 6: Summary and Review
|
||||
## 📊 Part 6: Summary and Review
|
||||
|
||||
#### What We Learned
|
||||
### What We Learned
|
||||
|
||||
1. **Registers**: The ARM Cortex-M33 has 13 general-purpose registers (`r0`-`r12`), plus special registers for the stack pointer (`r13`/SP), link register (`r14`/LR), and program counter (`r15`/PC).
|
||||
|
||||
@@ -537,7 +534,7 @@ In future weeks, we'll work with `.bin` files that have been stripped of symbols
|
||||
|
||||
6. **Little-Endian**: The RP2350 stores multi-byte values with the least significant byte at the lowest address, making them appear "backwards" when viewed as a single value.
|
||||
|
||||
#### The Program Flow
|
||||
### The Program Flow
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────┐
|
||||
@@ -560,27 +557,27 @@ In future weeks, we'll work with `.bin` files that have been stripped of symbols
|
||||
|
||||
---
|
||||
|
||||
### ✅ Practice Exercises
|
||||
## ✅ Practice Exercises
|
||||
|
||||
Try these on your own to reinforce what you learned:
|
||||
|
||||
#### Exercise 1: Explore in Ghidra
|
||||
### Exercise 1: Explore in Ghidra
|
||||
1. Open your `0x0001_hello-world` project in Ghidra
|
||||
2. Find the `stdio_init_all` function in the Symbol Tree
|
||||
3. Look at its decompiled code - can you understand what it's setting up?
|
||||
|
||||
#### Exercise 2: Find Strings in Ghidra
|
||||
### Exercise 2: Find Strings in Ghidra
|
||||
1. In Ghidra, go to **Window → Defined Strings**
|
||||
2. Look for `"hello, world"` - what address is it at?
|
||||
3. Double-click to navigate to it in the listing
|
||||
|
||||
#### Exercise 3: Cross-References
|
||||
### Exercise 3: Cross-References
|
||||
1. In Ghidra, navigate to the `main` function
|
||||
2. Find the `ldr r0, [DAT_...]` instruction that loads the string
|
||||
3. Right-click on `DAT_10000244` and select **References → Show References to**
|
||||
4. This shows you where this data is used!
|
||||
|
||||
#### Exercise 4: Connect GDB (Preparation for Week 2)
|
||||
### Exercise 4: Connect GDB (Preparation for Week 2)
|
||||
1. Start OpenOCD and connect GDB as shown in Part 4
|
||||
2. Set a breakpoint at main: `b main`
|
||||
3. Continue: `c`
|
||||
@@ -591,7 +588,7 @@ Try these on your own to reinforce what you learned:
|
||||
|
||||
---
|
||||
|
||||
### 🎓 Key Takeaways
|
||||
## 🎓 Key Takeaways
|
||||
|
||||
1. **Reverse engineering combines static and dynamic analysis** - we look at the code (static with Ghidra) and run it to see what happens (dynamic with GDB).
|
||||
|
||||
@@ -605,7 +602,7 @@ Try these on your own to reinforce what you learned:
|
||||
|
||||
---
|
||||
|
||||
### 📖 Glossary
|
||||
## 📖 Glossary
|
||||
|
||||
| Term | Definition |
|
||||
| ------------------- | --------------------------------------------------------- |
|
||||
|
||||
Binary file not shown.
Reference in New Issue
Block a user