1.

2 Dynamic Reverse Engineering

Key Terminology and Their Meanings (GDB and Ghidra)

Debugging Terminology

Software Breakpoints

A debugger replaces an instruction with a breakpoint, causing the CPU to raise a trap when it is
encountered. The original instruction is restored once the breakpoint is handled.

Hardware Breakpoints

These breakpoints are set using CPU debug registers and allow monitoring of memory or
instruction execution without modifying the code. They are limited in number but more stealthy.

Data Watchpoints

Used to track changes to memory locations and notify the debugger when specific data is
accessed or modified.

Stepping

Allows controlled execution of a program, moving step-by-step through machine instructions or

source code lines.

Process Control

Provides the ability to start, stop, suspend, and resume execution of the debugged program or its
threads.

Inspection & Modification

Debuggers can inspect and modify the program’s memory and registers, enabling runtime
manipulation of values.

Signal/Exception Interception

The debugger can catch signals or exceptions generated by the program, helping to analyze
faults or unexpected behaviors.

Checkpointing
Saves the process state at a specific point, allowing rollback and analysis without restarting from
scratch.

Anti-Debugging Techniques

1. Direct Evidence Detection

The program checks for debugger-related artifacts in its memory or environment, such as
querying OS structures (e.g., Windows PEB, Linux /proc/status ) or searching for known
debugger processes.

2. Behavior and Timing-Based Detection

Debuggers introduce execution delays. Programs measure execution times of specific

operations or exceptions to detect interference.

3. Debugger Blocking Techniques

Some programs prevent debugger attachment by self-debugging or using a circular

debugging setup, where multiple processes monitor each other to prevent intrusion.

Sniffing with strace and ltrace

Overview

Both strace and ltrace are command-line tools used in reverse engineering to monitor an
application's interactions with the system. They help in understanding how a program behaves
without modifying its execution.

strace – System Call Monitoring

strace captures and displays system calls made by a running process, including their
arguments and return values. It provides insights into how a program interacts with the operating
system.

Use Cases
 Tracking file operations ( open , read , write ).
Monitoring memory allocation ( mmap , brk ).
Analyzing process management ( fork , execve ).

Example Usage

strace ls

This command traces all system calls made by the ls command.

ltrace – Library Call Monitoring

ltrace monitors library function calls made by a program to dynamically linked libraries (e.g.,
libc ). It helps to identify how an application interacts with external libraries.

Use Cases

Observing calls to standard C library functions ( printf , malloc ).

Understanding program logic based on API usage.
Debugging dynamically linked binaries.

Example Usage

ltrace ls

This command traces all library function calls made by the ls command.

Comparison of strace vs ltrace

Feature strace ltrace

Focus System calls Library function calls
Purpose OS interaction monitoring API usage tracking
Dependency None Requires .plt relocations

Q&A part

Non-Determinism and Record-Replay (Slide 6)

Common Sources of Non-Deterministic Behavior

1. Environment dependencies:
Factors like disk space, network availability, time, and random number generators affect
execution.
2. Security mechanisms:
Techniques like Address Space Layout Randomization (ASLR) change memory
addresses on each execution.
3. Multithreading behavior:
Thread synchronization introduces timing variations, making program behavior
unpredictable.

Impact on Dynamic Analysis

Non-determinism hampers debugging by making program behavior inconsistent across runs,

leading to difficulties in reproducing issues.

Role of Record-Replay

Record-replay captures execution traces during a run, allowing reverse engineers to

deterministically reproduce the exact same execution, enabling effective debugging and script
development.

Instrumentation (Slides 7-14)

What is Instrumentation?

Instrumentation is the insertion of code snippets into a program to collect execution data.

Goals of Instrumentation

Tracing – Monitoring function calls and data flows.

Security enforcement – Detecting suspicious behavior.
Performance analysis – Collecting runtime statistics.

Different Software Representations for Injection

Instrumentation can be applied at:

Source code level (before compilation).

Binary level (modifying compiled executables).
Intermediate representations (during compilation).
Abstraction Levels of Reporting

Instrumentation can report at different levels:

Instruction-level: Individual operations.

Basic block-level: Code sequences without branching.
Function-level: Entry and exit of functions.

Configuration of PIN-Like Instrumentation

Instrumentation code: Specifies where and how code is injected.

Analysis code: Defines what data is collected at runtime.

PIN instruments code at runtime using a virtual machine, JIT compiler, and code cache,
ensuring minimal performance overhead.

Dynamic Crypto Key Localization Attack (Slides 18, 19, 21, 22, 23)

Steps of the Attack

1. Identify Crypto Basic Blocks

Use heuristics like instruction patterns (bitwise operations) and execution count scaling.
2. Expand Detected Blocks
Analyze data dependencies to identify memory load operations.
3. Differentiate Key and Data Loading
Consider source (e.g., files vs. random number generators), buffer sizes, and value
consistency across runs.
4. Extract Key Values
Set breakpoints in a debugger and retrieve operand values during execution.

Emulation vs. Other Dynamic Analysis Techniques (Slide 27)

Emulation is preferred when:

The original environment is unavailable.

Fine-grained control over execution is required.
Avoiding detection by anti-debugging mechanisms is needed.

Differential Analysis (Slide 30)

Definition

Compares different executions of a program under varying conditions to detect differences.

Targets of Analysis

Input variations: Analyze how input changes affect behavior.

Execution environment: Observe effects of system-level differences.

Examples

Identifying control flow changes based on input.

Comparing binaries before and after patching.

Inputs for Disassemblers (Slide 31)

Disassemblers can take the following inputs:

Executable binaries (e.g., ELF, PE).

Memory dumps captured from a running process.
Partial binary code extracted from firmware or disk images.

Fuzzing (Slide 32)

Definition

Fuzzing involves providing random or semi-random inputs to a program to discover

vulnerabilities.

Types of Fuzzing

1. Black-box fuzzing: No prior knowledge of the application.

2. White-box fuzzing: Uses program structure knowledge.
3. Grey-box fuzzing: A hybrid approach leveraging partial knowledge.

Symbolic and Concolic Execution (Slides 33-36)

Core Concepts

Path conditions: Mathematical constraints representing program execution paths.

 Path exploration: Attempting to cover all possible execution paths.

Path Explosion Problem

The number of paths grows exponentially, making exhaustive analysis impractical.

Mitigating Path Explosion

Using concrete inputs to guide execution along selected paths while maintaining symbolic
tracking.

Limitations of Static and Dynamic Analysis (Slide 39)

Analysis Type Limitations

Static Analysis Cannot capture runtime behavior, limited by obfuscation.
Dynamic Analysis Limited to observed execution paths, performance overhead.

Hybrid Analysis

Combining both methods to leverage the strengths of each, such as running static analysis for
structural insights and dynamic analysis for runtime behavior validation.

Example: Using static analysis to identify critical functions and dynamic analysis to monitor their
runtime execution.