16.1 Reverse Engineering & Password Cracking: Ghidra, IDA Pro, Hashcat & John the Ripper

16.1 Reverse Engineering & Password Cracking: Ghidra, IDA Pro, Hashcat & John the Ripper

Quick Answer: In digital forensics, reverse engineering toolkits like NSA Ghidra and Hex-Rays IDA Pro enable examiners to perform deep static analysis of unknown binaries, disassembling machine code and decompiling it into human-readable C pseudocode to uncover malicious payloads, evasion mechanisms, and command-and-control (C2) channels. Concurrently, password recovery tools resolve access barriers presented by encrypted containers, locked user accounts, and password-protected files. Hashcat provides massively parallel GPU-accelerated hash cracking across hundreds of hash types (-m 1000 NTLM, -m 3200 bcrypt, -m 13100 Kerberoast, -m 22000 WPA-PBKDF2) utilizing dictionary, rule-based, and mask attacks (-a 3). Complementing this, John the Ripper (JtR) offers flexible CPU-based cracking and essential hash extraction utilities (zip2john, rar2john, pdf2john, bitlocker2john) to convert encrypted container headers into crackable targets.

---

Binary Reverse Engineering in Digital Forensics

Digital forensic investigators frequently encounter compiled binaries whose provenance, intent, and operational mechanics cannot be determined solely through dynamic sandbox execution. Malware authors frequently implement anti-analysis techniques, sandbox evasion routines, and environment-checking conditional branches (such as validating Active Directory domain membership, hypervisor detection, or sleep-timing thresholds) that prevent the binary from executing its malicious payload in automated sandbox environments.

Under such circumstances, examiners must transition to static binary analysis and software reverse engineering (SRE). Reverse engineering allows the investigator to inspect the internal structure, control flow logic, imported API functions, and embedded cryptographic keys of an executable without running it.

Disassembly vs. Decompilation

Understanding the distinction between disassembly and decompilation is fundamental to forensic analysis:

• Disassembly: The process of translating raw binary machine code (hexadecimal opcodes) into human-readable assembly language mnemonics (such as x86, x86-64, or ARM instructions: MOV, PUSH, CALL, JMP, XOR). While disassembly preserves 100% of the instruction-level logic and architectural operations, it requires extensive knowledge of hardware registers, calling conventions, stack frames, and assembly-level branching.
• Decompilation: The process of taking machine code or intermediate representations and reconstructing high-level, structured source code—most commonly C pseudocode. Decompilation abstracts away register allocations, stack manipulation, and low-level calling conventions into standard programming constructs (if/else conditionals, while loops, structure definitions, and function prototypes). This dramatically accelerates forensic review.

+-----------------------+       Disassembly        +---------------------------+
| Raw Machine Code      | -----------------------> | Low-Level Assembly Code   |
| (e.g., 55 48 89 E5)   |                          | (e.g., push rbp; mov ...) |
+-----------------------+                          +---------------------------+
            |                                                    |
            |                     Decompilation                  |
            +----------------------------------------------------+ 
                                      |
                                      v
                         +---------------------------+
                         | High-Level C Pseudocode   |
                         | int decrypt_payload(...)  |
                         +---------------------------+

Core Analytical Constructs in Reverse Engineering

1. Graph View and Control Flow Graphs (CFGs): Rather than reading a linear listing of instructions, modern disassemblers render binary logic as a directed graph. Basic blocks of instructions (sequences of instructions with a single entry point and a single exit point) are displayed as nodes, connected by conditional edges (green for condition met / true, red for condition unmet / false, and blue for unconditional jumps). This enables investigators to map out decision branches, such as anti-debugging checks or command-dispatch tables.
2. Cross-References (XREFs): Cross-references identify every location in the binary where a specific function, variable, memory address, or string is accessed or invoked:
   • Code XREFs: Reveal all caller functions that execute a CALL or JMP instruction to a targeted subroutine (e.g., finding all locations where VirtualAlloc or CreateRemoteThread is called).
   • Data XREFs: Reveal where hardcoded strings (e.g., URLs, registry keys, C2 IP addresses, encryption passwords) or global variables are referenced in memory.
3. Symbol Identification & Type Recovery: Binary executables stripped of debugging symbols (such as Microsoft PDB files or DWARF symbols) lack human-readable function and variable names. Investigators must reconstruct data structures (e.g., PEB, IMAGE_NT_HEADERS, custom network protocol structures) to understand data flow.

---

NSA Ghidra vs. Hex-Rays IDA Pro: Forensic Comparison

Two enterprise platforms dominate software reverse engineering: Hex-Rays IDA Pro (Interactive DisAssembler) and NSA Ghidra.

Hex-Rays IDA Pro Architecture & FLIRT Signatures

IDA Pro is widely recognized for its robust disassembly analysis engine and deterministic control flow recovery. A pivotal capability of IDA Pro in forensic malware analysis is FLIRT (Fast Library Identification and Recognition Technology):

• When standard programs are compiled with static runtime libraries (e.g., Microsoft Visual C++ runtime, OpenSSL, zlib), the compiled binary includes tens of thousands of bytes of standard library code that the developer did not write.
• FLIRT scans the binary against databases of known compiler library signatures. When a match is found, IDA Pro automatically renames the subroutine (e.g., sub_4011A0 becomes _strcpy, _malloc, or AES_encrypt).
• This eliminates thousands of lines of boilerplate code from the investigator's review, allowing the examiner to focus exclusively on the author's custom malicious logic.

NSA Ghidra Architecture & Forensic Capabilities

Released open-source in 2019, Ghidra has become a critical asset for law enforcement and corporate incident response teams:

• The Sleigh Processor Modeling Language: Ghidra separates the disassembly and decompilation engine from processor architectures using Sleigh, a domain-specific language used to describe the semantics of target processors. When analyzing esoteric firmware, IoT botnets, or embedded controllers, analysts can define custom processor modules without modifying core Ghidra code.
• P-Code Intermediate Representation: Ghidra translates all machine instructions into P-code operations (e.g., INT_ADD, LOAD, STORE, BRANCH). The decompiler analyzes P-code rather than CPU-specific assembly, performing dead-code elimination, type propagation, and control-flow restructuring to produce clean C pseudocode.
• Native Ghidra Server: Forensic laboratories investigating advanced persistent threats (APTs) often deploy multiple examiners across a single malware campaign. Ghidra includes a multi-user server allowing examiners to check out files, view concurrent changes, merge function annotations, and bookmark evidentiary strings in real time.
• Headless Analyzer: For incident triage, Ghidra's analyzeHeadless utility allows investigators to automate binary ingestion, run auto-analysis scripts, extract embedded strings, and output decompiled functions directly from command-line pipelines without launching the GUI.

[!NOTE] While IDA Pro remains an industry standard in commercial malware labs, Ghidra's zero-cost decompiler, native multi-user repository server, and extensible Sleigh architecture make it a primary subject of modern forensic certification exams.

---

Forensic Password Recovery & Hash Extraction

During a forensic examination, critical evidence is frequently locked behind user account passwords, full-disk encryption (BitLocker, FileVault, LUKS), encrypted archives (ZIP, RAR, 7-Zip), or password-protected office documents (PDF, DOCX, XLSX). In such cases, investigators must extract the underlying cryptographic hashes or iteration parameters and perform targeted offline recovery.

Sources of Cryptographic Hashes in Windows Forensics

+-----------------------------------------------------------------------------+
|                        Evidentiary Hash Extraction Sources                  |
+-----------------------------------------------------------------------------+
| 1. SAM Registry Hive        | C:\\Windows\\System32\\config\\SAM            |
|    SYSTEM Registry Hive     | C:\\Windows\\System32\\config\\SYSTEM (Syskey)|
|    Target Hashes            | Local User Account NTLM Hashes                |
+-----------------------------+-----------------------------------------------+
| 2. Active Directory NTDS    | C:\\Windows\\NTDS\\ntds.dit                   |
|    SYSTEM Registry Hive     | Extracted from Volume Shadow Copy (VSS)       |
|    Target Hashes            | Enterprise Domain User NTLM Hashes & Kerberos |
+-----------------------------+-----------------------------------------------+
| 3. Volatile Memory (LSASS)  | lsass.exe process address space               |
|    Acquisition Technique    | comsvcs.dll, ProcDump, WinPmem, Mimikatz      |
|    Target Artifacts         | Plaintext passwords, NTLM hashes, Kerberos    |
|                             | tickets (TGT/TGS), DPAPI master keys          |
+-----------------------------------------------------------------------------+

1. The SAM and SYSTEM Hives:
   • Local user account credentials on Windows systems reside in the Security Account Manager (SAM) hive (C:\\Windows\\System32\\config\\SAM).
   • However, modern Windows systems encrypt the password hashes stored in the SAM hive using a cryptographic key known as the Syskey (or Boot Key). The Syskey is derived from four keys stored across the SYSTEM hive (C:\\Windows\\System32\\config\\SYSTEM).
   • To dump local NTLM hashes offline, the investigator must acquire both the SAM and SYSTEM hives from the forensic image and parse them using tools like secretsdump.py or samdump2.
2. Active Directory ntds.dit:
   • On Windows Domain Controllers, enterprise user credentials reside within the Extensible Storage Engine (ESE) database file: C:\\Windows\\NTDS\\ntds.dit.
   • The database is encrypted using the Password Encryption Key (PEK), which is stored within the domain controller's SYSTEM registry hive.
   • Because ntds.dit is continuously locked by the Active Directory Domain Services (NTDS) engine, forensic acquisition requires capturing it via the Volume Shadow Copy Service (VSS) (vssadmin create shadow /for=C:), invoking ntdsutil, or performing live DCSync attacks via the Microsoft Directory Replication Service Remote Protocol (MS-DRSR).
3. LSASS Process Memory:
   • The Local Security Authority Subsystem Service (lsass.exe) manages user authentication, security tokens, and active logon sessions.
   • When a user logs on interactively, via RDP, or through network services, credential material is cached within LSASS memory space.
   • Investigators can extract LSASS memory from live triage images or memory dumps (memdump.raw) using native utilities (rundll32.exe C:\\windows\\System32\\comsvcs.dll, MiniDump <lsass_pid> lsass.dmp full), Sysinternals procdump.exe, or offline Volatility plugins (windows.lsass).
   • LSASS dumps yield NTLM password hashes, Kerberos Ticket Granting Tickets (TGTs), Ticket Granting Services (TGSs), and DPAPI master keys used to decrypt stored browser credentials and encrypted file systems.

---

Password Cracking Methodologies & Attack Types

Forensic password cracking is an offline, non-destructive mathematical process where candidate plaintexts are transformed using the target cryptographic algorithm and compared against the recovered evidentiary hash.

Candidate Word ----> [ Hash Algorithm (e.g. NTLM, SHA-256) ] ----> Computed Hash
                                                                          |
                                                                          v
Target Evidence Hash <============================================= [ Match? ]
                                                                      /      \
                                                            Yes: Recovered!   No: Continue

Detailed Taxonomy of Password Attacks

1. Dictionary Attack:
   • The cracker reads candidate words sequentially from a precompiled wordlist (such as the standard rockyou.txt or breach-derived password lists).
   • Strengths: Extremely rapid; exploits human tendency to choose common dictionary words.
   • Limitations: Ineffective against non-dictionary passphrases or passwords modified with numbers, leetspeak, or special symbols.
2. Rule-Based Attack:
   • Applies deterministic mutation rules to each word in a dictionary list.
   • Common mutation rules include: capitalizing the first letter (password -> Password), leetspeak substitutions (e -> 3, a -> @, o -> 0), appending common numeric patterns (such as years 2024 or sequences 123!), and reversing strings.
   • Popular rule sets include Hashcat's best64.rule and OneRuleToRuleThemAll.rule.
3. Brute-Force Attack (Exhaustive Keyspace Search):
   • Tests every possible combination of characters across a defined character set (lowercase, uppercase, numbers, symbols) up to a specified maximum length.
   • The total keyspace search size is governed by the formula K = C^L, where C is the character set size and L is the password length. For an 8-character password containing all 95 printable ASCII characters, the keyspace is 95^8 ≈ 6.63 × 10^15 combinations.
   • Forensic application: Impractical for long passphrases, but viable for short numeric PINs (e.g., 4-digit to 6-digit PINs, 10^4 to 10^6 combinations) or short alphanumeric tokens.
4. Mask Attack (Targeted Positional Search):
   • A refined, highly efficient variant of the brute-force attack where the investigator configures specific character sets for specific character positions based on known organization password complexity policies.
   • For example, if a corporate policy mandates an 8-character password starting with one uppercase letter, followed by five lowercase letters, and ending with two digits, a pure brute-force attack would require searching 95^8 combinations. A mask attack restricts the search to: ?u?l?l?l?l?l?d?d (26 × 26^5 × 10^2 ≈ 3.09 × 10^9 combinations), reducing the required cracking time by over six orders of magnitude.
5. Combinator Attack:
   • Takes two separate wordlists and combines them sequentially (word from list 1 + word from list 2).
   • Effective against compound passwords (e.g., Summer + Coffee = SummerCoffee).
6. Hybrid Attack:
   • Combines a dictionary wordlist with a mask attack.
   • Mode 6 (Wordlist + Mask): Appends mask characters to dictionary words (e.g., word + ?d?d?s -> password99!).
   • Mode 7 (Mask + Wordlist): Prepends mask characters before dictionary words (e.g., ?d?d + word -> 01password).
7. Rainbow Table Attack:
   • A precomputed time-memory tradeoff technique. Rainbow tables pre-calculate chains of hashes from plaintexts using alternating hash functions and reduction functions, storing only the starting plaintext and ending hash of each chain.
   • Critical Forensic Constraint: Rainbow tables are effective only against unsalted hashes (such as legacy LM hashes, raw MD5, or unsalted NTLM). When a cryptographic salt is introduced (e.g., in bcrypt, PBKDF2, or Argon2), every unique salt requires an entirely new, independently precomputed multi-gigabyte rainbow table, rendering rainbow table attacks mathematically useless against modern salted credentials.

---

Hashcat: High-Performance GPU-Accelerated Cracking

Hashcat is the industry standard for high-performance, GPU-accelerated hash recovery. While CPUs are optimized for low-latency, complex branching logic, modern Graphics Processing Units (GPUs) contain thousands of Arithmetic Logic Units (ALUs) running on Single Instruction, Multiple Threads (SIMT) architectures. This massively parallel architecture enables GPUs to compute millions or billions of cryptographic hash evaluations per second.

Essential Hashcat Parameters & Hash Types

Hashcat execution requires two primary configuration parameters:

1. -m [mode]: Specifies the target cryptographic hash type.
2. -a [mode]: Specifies the attack methodology.

Hashcat Built-in Character Charsets for Mask Attacks

• ?l: Lowercase alphabetic characters (abcdefghijklmnopqrstuvwxyz)
• ?u: Uppercase alphabetic characters (ABCDEFGHIJKLMNOPQRSTUVWXYZ)
• ?d: Decimal digits (0123456789)
• ?s: Special symbols (printable symbols including punctuation and space)
• ?a: All printable ASCII characters (combination of ?l, ?u, ?d, and ?s)
• ?b: All 256 binary byte values (0x00 through 0xff)

Practical Forensic Hashcat Commands

# Scenario 1: Rule-based attack on Windows NTLM hashes extracted from SAM hive
# Uses rockyou.txt wordlist and the best64 mangling rule set
hashcat -m 1000 -a 0 ntlm_hashes.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule -o cracked_ntlm.txt

# Scenario 2: Positional mask attack on an 8-character corporate password
# Mask: 1 Uppercase, 5 Lowercase, 2 Digits (e.g., Summer24)
hashcat -m 1000 -a 3 ntlm_hashes.txt ?u?l?l?l?l?l?d?d -o cracked_mask.txt

# Scenario 3: Cracking Kerberoast TGS-REP hashes using an enterprise wordlist
hashcat -m 13100 -a 0 kerberoast_tgs.txt /usr/share/wordlists/passwords.txt -r /usr/share/hashcat/rules/d3ad0ne.rule

[!TIP] In forensic investigations where evidentiary hashes must be cracked against strict deadlines, always execute an initial pass using -a 0 with a focused breach wordlist, followed by a targeted -a 3 mask attack reflecting the suspect's known password complexity requirements before committing computational resources to long-running rule-based attacks.

---

John the Ripper (JtR) & Evidentiary Container Hash Extraction

While Hashcat is engineered primarily for GPU-based dictionary and mask operations, John the Ripper (JtR), maintained by the Openwall project (specifically the community-enhanced JtR Jumbo suite), remains a premier CPU-based and OpenCL-capable cracking framework. JtR is distinguished by its automated cracking modes and its collection of container hash extraction utilities.

Core John the Ripper Cracking Modes

1. Single Crack Mode (--single):
   • The fastest initial cracking mode. JtR inspects the metadata associated with the target hash—such as the user's login name, GECOS field (full name, phone number, office location), home directory path, and email address.
   • It applies a specialized set of built-in mangling rules to these metadata strings (e.g., testing John, nhoJ, John123, JSmith).
   • Exam Tip: In security and forensic exams, Single Crack mode is cited as the mandatory first step when cracking Unix/Linux shadow files because it tests account-specific permutations before consuming time on general dictionaries.
2. Wordlist Mode (--wordlist=[file]):
   • Standard dictionary processing. Can be combined with JtR's internal rule engine (--rules) to apply leetspeak, truncation, and character casing transformations.
3. Incremental Mode (--incremental):
   • JtR's most powerful exhaustive cracking mode. Unlike naive brute-force attacks that test permutations sequentially (aaaa, aaab, aaac), Incremental mode uses statistical character frequency tables (.chr files) derived from millions of analyzed passwords.
   • It attempts the most statistically probable letter and digraph combinations first, maximizing the likelihood of cracking within finite timeframes.
4. External Mode (--external=[mode]):
   • Allows examiners to write custom C-like filter and generation routines executed by JtR's internal virtual compiler at runtime.

The *2john Tool Suite: Extracting Evidentiary Container Hashes

Encrypted containers (ZIP archives, RAR files, PDFs, BitLocker volumes) cannot be fed directly into Hashcat or JtR as raw binary files. The cryptographic parameters—such as the salt, iteration count, initialization vector (IV), and encrypted verification payload—must first be parsed from the file's container header.

JtR Jumbo provides specialized Perl and Python extractors named *2john that output standardized hash strings suitable for cracking:

+----------------------------+     *2john Utility      +-------------------------------+
| Encrypted Evidence File    | ----------------------> | Standardized Hash String      |
| (.zip, .rar, .pdf, volume) |                         | ($zip$*0*1*... / $pdf$*4*...) |
+----------------------------+                         +-------------------------------+
                                                                       |
                                                                       v
                                                        +-----------------------------+
                                                        | John the Ripper / Hashcat   |
                                                        | Offline Recovery Engine     |
                                                        +-----------------------------+

1. zip2john (Encrypted ZIP Archives)

Extracts the encryption header from legacy PKZIP stream-encrypted archives or modern WinZip AES-128/256 containers:

zip2john evidence_archive.zip > zip.hash
john --format=zip zip.hash --wordlist=/usr/share/wordlists/rockyou.txt

2. rar2john (Encrypted RAR Archives)

Parses encryption metadata from RAR3 (AES-128, 262,144 SHA-1 iterations) and RAR5 (AES-256, PBKDF2 with HMAC-SHA256):

rar2john financial_records.rar > rar.hash
john --format=rar rar.hash --wordlist=/usr/share/wordlists/rockyou.txt

3. pdf2john (Password-Protected Adobe PDF Documents)

Extracts revision data, permission bytes, and User Password hash strings across standard PDF encryption revisions (Revision 2 [40-bit RC4], Revision 3 [128-bit RC4], Revision 4 [128-bit AES], and Revision 5/6 [256-bit AES]):

pdf2john sensitive_contract.pdf > pdf.hash
john --format=pdf pdf.hash --wordlist=/usr/share/wordlists/rockyou.txt

4. bitlocker2john (Windows BitLocker Encrypted Volumes)

Extracts the BitLocker Volume Master Key (VMK) encrypted header, Salt, and user password / recovery password hashes from raw disk partitions:

bitlocker2john -i /dev/sdb1 > bitlocker.hash
# The output hash can be cracked using JtR or passed to Hashcat using mode -m 22100
hashcat -m 22100 -a 0 bitlocker.hash /usr/share/wordlists/rockyou.txt

[!WARNING] Password cracking on forensic evidence must never be performed directly against the original physical media. Hashes must be extracted from verified bit-stream forensic images (.E01 or .raw), and cracking activities must take place on dedicated analysis workstations equipped with adequate GPU cooling and secure storage for recovered plaintexts.