Identifying Functions and Data

Welcome! In reverse engineering, our goal is to understand how a program works without its source code. A critical first step is to identify its core components: functions and data.

These elements are like the building blocks and raw materials of any software. Learning to spot them quickly will significantly speed up your analysis.

Strings are often the easiest and most valuable clues in a binary. They can reveal a program's purpose, error messages, user prompts, file paths, network addresses, or API calls.

• Error messages: "Error: File not found"
• URLs/Paths: "https://malicious.com/update", "C:\Windows\System32\config.dat"
• User Prompts: "Enter password:"

Finding them is usually the first step for any analyst.

Most disassemblers, like Ghidra or IDA Pro, have a dedicated feature to list all identified strings within a binary. This saves you from manually scanning through raw bytes.

When you find an interesting string, you can usually cross-reference it to see where in the code it's being used. This immediately points you to relevant functions.

A function (or subroutine) is a self-contained block of code designed to perform a specific task. Programs are built from many functions calling each other.

Identifying functions helps you break down a complex program into smaller, manageable pieces, making it easier to understand its overall logic and flow.

Functions often start with a specific sequence of instructions called a prologue. This setup typically prepares the stack for local variables and saves the previous stack frame.

A common x86 prologue looks like this:

push ebp
mov ebp, esp

This sequence pushes the old base pointer onto the stack and sets the current stack pointer as the new base pointer.

Just as functions have entry points, they also have exit points, marked by an epilogue. The epilogue restores the stack to its state before the function call and returns control to the caller.

A typical x86 epilogue might be:

mov esp, ebp
pop ebp
ret

This restores the stack pointer, pops the old base pointer, and returns from the function.

Most programs use functions from system libraries (e.g., for printing to screen, file I/O, network communication). Disassemblers are often smart enough to identify these for you.

They do this by looking at imported symbols (like the Import Address Table in Windows PE files or Procedure Linkage Table in Linux ELF files) or by matching known function signatures.

Beyond code, binaries contain various data sections. Understanding these helps you locate global variables, constants, and other program-wide information:

• .data: Initialized global and static variables.
• .bss: Uninitialized global and static variables (zeroed out at runtime).
• .rdata: Read-only data, such as strings and constants.

These sections are usually clearly labeled in disassemblers.

Distinguishing between global and local variables is key. Global variables are accessible throughout the program and are usually stored in .data or .bss sections.

Local variables, on the other hand, are created on the stack when a function is called and are only accessible within that function. They are typically referenced relative to the stack frame pointer (e.g., [ebp-0x4]).

You are analyzing a binary and see a reference to an address within the .rdata section. What kind of data is most likely stored at this address?

You've learned fundamental techniques for static analysis!

• Strings offer immediate insights into program functionality.
• Function prologues and epilogues help define code boundaries.
• Recognizing library functions speeds up analysis.
• Understanding data sections (.data, .bss, .rdata) helps locate global variables and constants.

These skills are essential for navigating and understanding disassembled binaries.