Binary Reverse Engineering
Analyzing compiled binaries and firmware to understand functionality, discover vulnerabilities, and extract embedded data. Covers file identification, disassembly, decompilation, dynamic debugging, and cryptographic analysis for applications ranging from malware to IoT firmware.
File Identification and Initial Triage
Identify the binary's format, architecture, compiler, and any packing or protection mechanisms before diving into analysis. Determine whether it's a PE, ELF, Mach-O, or firmware image. Check for known packers, protectors, or obfuscation. Extract metadata including compilation timestamps, debug symbols, and embedded strings. This initial triage determines your analysis strategy.
Tools for this step
Detect It Easy
ImHexTip: Detect It Easy identifies file types, packers, compilers, and linkers with high accuracy. ImHex lets you inspect the raw file structure with pattern highlighting and custom data type definitions. If the binary is packed, you'll need to unpack it before meaningful static analysis. Check for debug symbols - if present, they make analysis dramatically easier.
String and Import Analysis
Extract all readable strings and analyze imported functions to get a quick understanding of the binary's capabilities. Strings reveal file paths, URLs, error messages, registry keys, and sometimes hardcoded credentials. Import tables show which system APIs the binary calls, indicating its functionality - network communication, file operations, cryptography, process manipulation, and more.
Radare2
GhidraTip: Use rabin2 (part of Radare2) for fast string and import extraction from the command line. Ghidra's defined strings window filters noise effectively. Look for strings that suggest C2 communication (URLs, IP addresses), persistence (registry paths, service names), or anti-analysis (debugger detection strings). Encrypted or encoded strings that don't make sense are worth investigating.
Disassembly and Control Flow Analysis
Load the binary into a disassembler and analyze the assembly code. Map the program's control flow, identify key functions (main, network handlers, encryption routines), and understand the overall program structure. Cross-reference strings and imports to their usage locations. Focus on functions that handle user input, network data, or security-sensitive operations.
CutterTip: Ghidra's auto-analysis handles most binaries well and produces navigable cross-references. Cutter provides a modern GUI for Radare2's analysis engine. Start by finding main() or the entry point and work outward. Rename functions and variables as you understand them - this makes complex binaries manageable. Use cross-references to trace how data flows through the program.
Decompilation and Source-Level Analysis
Use decompilation to lift assembly back to a C-like representation for faster analysis. Modern decompilers produce readable pseudo-code for most architectures. Analyze the decompiled output for logic errors, buffer handling issues, authentication bypasses, and hardcoded secrets. Compare the decompiler output with the disassembly when the decompiler's interpretation looks wrong.
Tip: Ghidra's decompiler handles x86, x64, ARM, and MIPS well. Apply type information and rename variables to improve decompiler output - it gets progressively more readable as you add context. Don't trust the decompiler blindly for security analysis - check the actual assembly for edge cases around integer overflow, signedness, and pointer arithmetic.
Dynamic Debugging and Runtime Analysis
Run the binary under a debugger to observe its actual behavior. Set breakpoints on interesting functions, trace execution flow, inspect memory contents at runtime, and modify execution to explore different code paths. Dynamic analysis resolves ambiguities from static analysis - you can see actual values in registers and memory rather than reasoning about possibilities.
pwndbgTip: pwndbg enhances GDB with context displays, heap analysis, and exploit development features. Use hardware breakpoints when software breakpoints are detected by anti-debug checks. Trace system calls with strace (Linux) or API Monitor (Windows) for a high-level view of program behavior. Set memory watchpoints to catch when specific data is read or written.
Cryptographic and Protocol Analysis
Identify and analyze any cryptographic operations or custom protocols in the binary. Look for standard crypto constants (AES S-box, SHA magic numbers, RSA operations) and trace how keys are derived, stored, and used. For custom protocols, capture network traffic while debugging to correlate code paths with wire format. Weak or custom cryptography is a common vulnerability in proprietary software.
angr
CapstoneTip: angr's symbolic execution can automatically explore code paths and solve for input values that reach specific program states. Capstone provides a disassembly library for scripted analysis of crypto routines. Look for standard crypto library calls first (OpenSSL, CryptoAPI) before assuming custom implementations. XOR-based 'encryption' with static keys is still extremely common in malware.
Firmware-Specific Analysis (if applicable)
For firmware images, extract the filesystem, identify the bootloader, and analyze device-specific binaries. Look for hardcoded credentials, debug interfaces (UART, JTAG), and unprotected update mechanisms. Firmware often runs with elevated privileges and limited security controls, making vulnerabilities particularly impactful on IoT and embedded devices.
Tools for this step
EMBATip: EMBA automates firmware security analysis including filesystem extraction, vulnerability scanning, and hardcoded credential detection. Check for telnet and SSH services with default credentials. Look for unsigned firmware update mechanisms that allow malicious firmware installation. Analyze the bootloader for debug access that persists across firmware updates.
Document Findings and Vulnerability Report
Document your reverse engineering findings in a structured report. For vulnerability research, include the root cause, trigger conditions, exploitability assessment, and proof-of-concept. For malware analysis, include capabilities, IOCs, and detection signatures. Include annotated disassembly or decompiler output for key functions to support your findings.
Tip: Include annotated screenshots from Ghidra or your debugger showing the vulnerability or key functionality. For vulnerability reports, provide a minimal proof-of-concept that demonstrates the issue. Map malware capabilities to MITRE ATT&CK techniques. If the binary uses anti-analysis techniques, document what you encountered and how you bypassed each one.
Other Workflows
OSINT Investigation Workflow
A structured approach to open-source intelligence gathering, from target identification through to reporting. Covers passive reconnaissance, social media analysis, email and phone lookups, and data correlation.
Web Application Penetration Test
A systematic approach to testing web applications for security vulnerabilities. Covers reconnaissance, mapping, vulnerability discovery, exploitation, and reporting.
Active Directory Attack Path
From initial foothold to domain admin. A step-by-step approach to enumerating and attacking Active Directory environments during authorized penetration tests.