Reverse engineers malware binaries using NSA's Ghidra disassembler and decompiler to understand internal logic, cryptographic routines, C2 protocols, and evasion techniques at the assembly and pseudo-C level. Activates for requests involving malware reverse engineering, disassembly analysis, decompilation, binary analysis, or understanding malware internals.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Reverse engineers malware binaries using NSA's Ghidra disassembler and decompiler to understand internal logic, cryptographic routines, C2 protocols, and evasion techniques at the assembly and pseudo-C level. Activates for requests involving malware reverse engineering, disassembly analysis, decompilation, binary analysis, or understanding malware internals.
Static and dynamic analysis have identified suspicious functionality that requires deeper code-level understanding
You need to reverse engineer C2 communication protocols, encryption algorithms, or custom obfuscation
Understanding the exact exploit mechanism or vulnerability targeted by a malware sample
Extracting hardcoded configuration data (C2 addresses, encryption keys, campaign IDs) embedded in compiled code
Developing precise YARA rules or detection signatures based on unique code patterns
Do not use for initial triage of unknown samples; perform static analysis with PEStudio and behavioral analysis with Cuckoo first.
Detection Gaps & Validation
Auto-analysis is not ground truth. Ghidra's analyzer misidentifies function boundaries in obfuscated/packed code, mislabels indirect calls, and leaves data interpreted as code (and vice versa). Disassembling a packed sample reverses the unpacking stub, not the payload — dump the unpacked image from memory (x64dbg at OEP) and import that, or your whole analysis describes the loader.
Indirect control flow hides the real logic. Calls through function pointers, vtables, and dynamically-resolved APIs (hash-based GetProcAddress) leave no XREF, so the C2/inject code looks unreachable. Find the resolver, label the resolved imports, and re-run analysis so cross-references populate.
Decompiler output misleads on optimized/non-C code. Inlined crypto, SIMD, and compiler intrinsics produce confusing pseudo-C; verify against the assembly Listing rather than trusting the decompiler. Use FindCrypt to spot AES S-box/RC4/CRC constants the decompiler obscures.
Static reach has limits. Self-modifying code, runtime-decrypted strings, and conditionally-executed branches won't reveal plaintext C2/keys statically. Confirm by capturing values at runtime in x64dbg (breakpoint after the decrypt routine) — static-only is a common false-negative source.
Confirm cross-tool: corroborate function identification and decompilation with IDA/Binary Ninja, and validate extracted C2/keys by decrypting real captured traffic or files before reporting them as fact.
Benign-lookalike FPs: statically-linked library code (OpenSSL, Boost, Go/Rust runtime) and legitimate packers look "suspicious" — use FLIRT/FID signatures to fold away library code before judging intent.
Navigate the binary to locate critical code sections:
Navigation Strategy:
━━━━━━━━━━━━━━━━━━━
1. Start at entry point (OEP) - follow execution from _start/WinMain
2. Check Symbol Tree for imported functions (Window -> Symbol Tree)
3. Search for cross-references to suspicious APIs:
- VirtualAlloc/VirtualAllocEx (memory allocation for injection)
- CreateRemoteThread (remote thread injection)
- CryptEncrypt/CryptDecrypt (encryption operations)
- InternetOpen/HttpSendRequest (C2 communication)
- RegSetValueEx (persistence via registry)
4. Use Search -> For Strings to find embedded URLs, IPs, and paths
5. Check the Functions window sorted by size (large functions often contain core logic)
Ghidra keyboard shortcuts for efficient navigation:
G - Go to address
Ctrl+E - Search for strings
X - Show cross-references to current location
Ctrl+Shift+F - Search memory for byte patterns
L - Rename label/function
; - Add comment
T - Retype variable
Ctrl+L - Retype return value
Step 3: Analyze Decompiled Code
Use Ghidra's decompiler to understand function logic:
// Example: Ghidra decompiler output for a decryption routine// Analyst renames variables and adds types for clarityvoiddecrypt_config(BYTE *encrypted_data, int data_len, BYTE *key, int key_len) {
// XOR decryption with rolling keyfor (int i = 0; i < data_len; i++) {
encrypted_data[i] = encrypted_data[i] ^ key[i % key_len];
}
return;
}
// Analyst actions in Ghidra:// 1. Right-click parameters -> Retype to correct types (BYTE*, int)// 2. Right-click variables -> Rename to meaningful names// 3. Add comments explaining the algorithm// 4. Set function signature to propagate types to callers
Step 4: Trace C2 Communication Logic
Follow the network communication code path:
Analysis Steps for C2 Protocol Reverse Engineering:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. Find InternetOpenA/WinHttpOpen call -> trace to wrapper function
2. Follow data flow from encrypted config -> URL construction
3. Identify HTTP method (GET/POST), headers, and body format
4. Locate response parsing logic (JSON parsing, custom binary protocol)
5. Map the C2 command dispatcher (switch/case or jump table)
6. Document the command set (download, execute, exfiltrate, update, uninstall)
Ghidra Script for extracting C2 configuration:
# Ghidra Python script: extract_c2_config.py# Run via Script Manager in Ghidrafrom ghidra.program.model.data import StringDataType
from ghidra.program.model.symbol import SourceType
# Search for XOR decryption patterns
listing = currentProgram.getListing()
memory = currentProgram.getMemory()
# Find references to InternetOpenA
symbol_table = currentProgram.getSymbolTable()
for symbol in symbol_table.getExternalSymbols():
if"InternetOpen"in symbol.getName():
refs = getReferencesTo(symbol.getAddress())
for ref in refs:
print("C2 init at: {}".format(ref.getFromAddress()))
Step 5: Analyze Encryption and Obfuscation
Identify and document cryptographic routines:
Common Malware Encryption Patterns:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
XOR Cipher: Loop with XOR operation, often single-byte or rolling key
RC4: Two loops (KSA + PRGA), 256-byte S-box initialization
AES: Look for S-box constants (0x63, 0x7C, 0x77...) or calls to CryptEncrypt
Base64: Lookup table with A-Za-z0-9+/= characters
Custom: Combination of arithmetic operations (ADD, SUB, ROL, ROR with XOR)
Identification Tips:
- Search for constants: AES S-box, CRC32 table, MD5 init values
- Look for loop structures operating on byte arrays
- Check for Windows Crypto API usage (CryptAcquireContext -> CryptCreateHash -> CryptEncrypt)
- FindCrypt Ghidra plugin automatically identifies crypto constants
Step 6: Document Findings and Create Detection Signatures
Produce actionable intelligence from reverse engineering:
# Generate YARA rule from unique code patterns found in Ghidracat << 'EOF' > malware_family_x.yar
rule MalwareFamilyX_Decryptor {
meta:
description = "Detects MalwareX decryption routine"
author = "analyst"date = "2025-09-15"
strings:
// XOR decryption loop with hardcoded key
$decrypt = { 8A 04 0E 32 04 0F 88 04 0E 41 3B CA 7C F3 }
// C2 URL pattern after decryption
$c2_pattern = "/gate.php?id=" ascii
condition:
uint16(0) == 0x5A4D and $decrypt and $c2_pattern
}
EOF
Key Concepts
Term
Definition
Disassembly
Converting machine code bytes into human-readable assembly language instructions; Ghidra's Listing view shows disassembled code
Decompilation
Lifting assembly code to pseudo-C representation for easier analysis; Ghidra's Decompile window provides this view
Cross-Reference (XREF)
Reference showing where a function or data address is called from or used; essential for tracing code execution flow
Control Flow Graph (CFG)
Visual representation of all possible execution paths through a function; reveals branching logic and loops
Original Entry Point (OEP)
The actual start address of the malware code after unpacking; packers redirect execution through an unpacking stub first
Function Signature
The return type, name, and parameter types of a function; applying correct signatures improves decompiler output quality
Ghidra Script
Python or Java automation script executed within Ghidra to perform batch analysis, pattern searching, or data extraction
Tools & Systems
Ghidra: NSA's open-source software reverse engineering suite with disassembler, decompiler, and scripting support for multiple architectures
IDA Pro/Free: Industry-standard interactive disassembler; IDA Free provides x86/x64 cloud-based decompilation
Binary Ninja: Commercial reverse engineering platform with modern UI and extensive API for plugin development
x64dbg: Open-source x64/x32 debugger for Windows used alongside Ghidra for dynamic debugging of malware
FindCrypt (Ghidra Plugin): Plugin that identifies cryptographic constants and algorithms in binary code
Common Scenarios
Scenario: Reversing Custom C2 Protocol
Context: Behavioral analysis shows encrypted traffic to an external IP on a non-standard port. Network signatures cannot detect variants because the protocol is proprietary. Deep reverse engineering is needed to understand the protocol structure.
Approach:
Import the unpacked sample into Ghidra and run full auto-analysis
Locate socket/WinHTTP API calls and trace backwards to the calling function
Identify the encryption routine called before data is sent (follow data flow from send/HttpSendRequest)
