Listen to this Post
Introduction:
When reverse engineering binaries, analysts often overlook a subtle but powerful artifact: compilers typically preserve the original source code’s order for functions and global variables. This means developers’ logical grouping – encryption next to decryption, C2 handlers adjacent to parsers – survives compilation, turning your disassembler into a map of the programmer’s mind. By leveraging this predictable layout, you can rapidly pivot between related routines, cut hours of tedious analysis, and uncover hidden malicious workflows without ever touching a debugger.
Learning Objectives:
- Recognize how different compilers (GCC, Clang, MSVC) arrange functions and variables in memory based on source code order.
- Apply proximity analysis to identify encryption/decryption pairs, C2 request parsers, and variable dependencies in malware samples.
- Use command-line tools (objdump, dumpbin) and disassemblers (Ghidra, IDA, radare2) to exploit compiler layout for faster reverse engineering.
You Should Know:
- Understanding Compiler Code Layout and How to Verify It
Most compilers output object code in the same sequence as the source file’s top‑down declarations – unless link‑time optimization (LTO) or function reordering flags are used. This means if a developer wrote `encrypt()` then `decrypt()` in the source, the binary likely places `encrypt` at a lower address (or higher, depending on architecture) than decrypt. To verify this behavior on a known binary, you can compile a simple test:
// test.c
void first() {}
void second() {}
void third() {}
int main() { return 0; }
Linux / macOS (using GCC/Clang)
gcc -c test.c -o test.o objdump -t test.o | grep -E 'first|second|third'
Expected output shows symbols in source order: first, second, third.
For a full executable, use `objdump -t a.out | sort -k4` to see addresses – they will ascend (or descend) according to the linker script, but relative order is retained.
Windows (MSVC)
cl /c test.c dumpbin /symbols test.obj | findstr "first second third"
If a binary is stripped, you can still observe ordering via function entry points in a disassembler’s function list (e.g., Ghidra’s Symbol Tree sorted by address).
Why this matters for malware analysis
Malware authors rarely randomize function order. By expecting logical grouping, you can guess the location of the encryption function once you find decryption – simply look at the adjacent function in the disassembler.
2. Pivoting Between Encryption and Decryption Functions
In ransomware or spyware, encryption and decryption routines are often placed together in the source. After identifying a decryption function (e.g., by spotting a loop with XOR or AES calls), open the disassembler’s function list sorted by address. The function directly above or below is a strong candidate for the complementary encryption routine.
Step‑by‑step guide using Ghidra (free, cross‑platform)
- Load the malware binary into Ghidra and run initial analysis.
- Navigate to the decryption function (search for constants like
0x80,0x1F, or API calls likeCryptDecrypt). - Open the “Symbol Tree” → “Functions” → sort by “Address”.
- Click the function immediately before and after the decryption function.
- Look for loops with
CryptEncrypt, AES key schedules, or hardcoded keys. - Rename both functions – you’ve likely found the pair.
Using radare2 (command line)
r2 ./malware [0x...]> afl ~decrypt list functions, grep for decrypt [0x...]> s sym.decrypt_func [0x...]> pdf print disassembly [0x...]> s sym.decrypt_func - 0x10 go to previous function offset [0x...]> af analyze function at that address
This workflow reduces guesswork and accelerates unpacking custom crypto.
3. Locating C2 Request Parsers and Encoding Logic
Command‑and‑control (C2) functions usually sit next to helper routines that encode, decode, or parse network responses. If you identify a function that sends data to a remote server (send, WSASend, curl_easy_perform), the functions directly above/below likely handle JSON/XML parsing, Base64 encoding, or XOR obfuscation of the beacon data.
Step‑by‑step with IDA Pro (or freeware version)
- Find cross‑references to socket/winhttp APIs to locate the main C2 function.
- Open the “Functions window” and sort by “Start address”.
- Right‑click on the C2 function → “Near functions” (or visually inspect adjacent entries).
- Examine each neighbor for loops, string operations (
strcpy,memcpy), or calls toatoi, `strtok` – these indicate parsing logic. - To confirm, trace a sample network capture: the parser’s input should match the C2 function’s received buffer.
Linux command‑line alternative
Use `objdump` to extract all function addresses, then manually check the surroundings:
objdump -d ./c2_binary | grep -E '^[0-9a-f]+ <' | awk '{print $1, $2}' > funcs.txt
Suppose C2 function is at 0x401234 – look for entries at 0x401220 and 0x401250
This technique is especially effective against modular malware (e.g., Qakbot, TrickBot) where developers naturally keep related logic together.
- Global Variable Proximity: From Variables to Functions and Back
Just like functions, global variables retain source order. If you discover a suspicious global (e.g., a decryption key buffer, a command string), the variables declared before and after it in the binary often serve the same high‑level purpose. You can then pivot from those variables to the functions that access them.
Step‑by‑step using Ghidra’s cross‑reference (XREF) system
1. In the Listing view, locate a global variable (.data section).
2. Press `Ctrl+Shift+F` to find references to this variable (XREF to).
3. Examine the surrounding variables by looking at the addresses directly below/above in the Data window.
4. For each adjacent variable, check its XREFs – they will lead to related functions (e.g., the encryption function that uses the same key buffer).
5. Create a graph of these relationships to reveal entire malicious modules.
Using `objdump` to list global variables
objdump -t malware | grep -E '.data|.bss' | sort -k4
Then pick an address and manually inspect nearby entries. In stripped binaries where variable names are missing, this still works because the compiler preserves order.
Windows PowerShell with dumpbin
dumpbin /symbols malware.exe | Select-String "External" | sort
- Practical Workflow: Linux / Unix Environment with objdump and grep
For quick triage of an ELF malware sample, you can extract function ordering without a full GUI disassembler.
Step‑by‑step
1. Extract all function symbols (if not stripped):
objdump -t sample | grep 'F .text' | awk '{print $5, $1}' | sort -k2
(Output format: function_name address)
- If stripped, use `objdump -d` and extract function boundaries via heuristics (e.g., `call` followed by
ret):objdump -d stripped_malware | grep -E '^[0-9a-f]+ <' | awk '{print $1, $2}' > functions.txt -
Identify a known function (e.g., one that calls
socket).objdump -d stripped_malware | grep -A20 'socket' | grep -E '^[0-9a-f]+ <'
-
Calculate surrounding addresses – add or subtract 0x200 bytes and look for function entries in that range.
5. Disassemble those candidate addresses to verify relationship:
objdump -d --start-address=0x401100 --stop-address=0x401300 stripped_malware
This method requires no installation of heavy tools and works on any Linux live CD or remote server.
- Windows Workflow: Using dumpbin and a Lightweight Disassembler
On Windows, after extracting a malicious PE file, you can use native tools plus a portable disassembler like CFF Explorer or x64dbg.
Step‑by‑step
- List all functions (if PDB not stripped, but often stripped in malware):
dumpbin /symbols malware.exe | find "SECTx" > symbols.txt
For stripped binaries, use a disassembler like `x64dbg` – load the malware, view the “Symbols” tab, sort by “Address”.
-
Find the function you care about (e.g., one that calls
InternetOpenA).
Set a breakpoint on `InternetOpenA` and trace back to the caller. -
Check the function list around that address – the previous 2–3 functions and next 2–3 functions are likely related.
-
Rapidly annotate using x64dbg’s comment feature: label them as “C2_send”, “C2_parse_json”, “C2_base64_encode”.
-
Export the function addresses and use a script to generate a proximity map:
$funcs = @(0x401000, 0x401120, 0x401250) example for ($i=0; $i -lt $funcs.Count-1; $i++) { Write-Host "Check between $($funcs[$i]) and $($funcs[$i+1])" }
This workflow is especially useful for memory‑constrained analysis where Ghidra is overkill.
7. Limitations and Exceptions: When Ordering Fails
Not all binaries preserve source order. Be aware of these cases to avoid false leads.
When the technique fails
- Link‑time optimization (LTO) with `-flto` (GCC/Clang) can reorder functions.
- Profile‑guided optimization (PGO) may move frequently called functions together.
- Obfuscators (e.g., VMProtect, Themida) randomize layout.
- Hand‑written assembly or compiler flags like `-ffunction-sections -Wl,–gc-sections` can reorder.
- Stripped binaries without function boundaries – you need heuristics.
Step‑by‑step to detect unreliable ordering
- Check for LTO: run `readelf -p .comment` on Linux – look for
-flto. - Look for section merging: `objdump -h sample | grep .text` – many small sections indicate
-ffunction-sections. - Test with a known function pair: If you find two functions that should be related (e.g., both call
malloc), but they are far apart in memory, ordering may be scrambled. - Fallback to cross‑references: Use `objdump -d | grep call` to build a call graph instead of relying on proximity.
In these scenarios, supplement with dynamic analysis or debugging to confirm relationships.
What Undercode Say:
- Key Takeaway 1: Compiler‑preserved source order is a free intelligence source – always check above and below a suspicious function before diving into deep cross‑reference graphs.
- Key Takeaway 2: This technique works across architectures (x86, ARM, MIPS) and most compilers (GCC, MSVC, Clang), making it a universal reverse engineering shortcut.
- Key Takeaway 3: Combine function proximity with global variable ordering to rapidly reconstruct malware modules (e.g., decrypt → decode → C2 send) in minutes instead of hours.
Analysis: Marcus Hutchins’ tip is deceptively simple yet profoundly practical. Many reverse engineers spend time building complex call graphs or dynamic traces when a quick glance at the disassembler’s function list would suffice. The underlying principle – that developers think in logical blocks and compilers rarely disrupt that order without reason – turns a blind spot into a force multiplier. For malware analysts, adopting this “if I were the developer” mindset cuts through obfuscation that isn’t explicitly anti‑disassembly. It also highlights a broader lesson: understanding compiler internals (even basic layout rules) pays dividends in threat intelligence. When teaching reverse engineering, this should be a day‑one heuristic, not a forgotten afterthought.
Prediction:
As malware authors increasingly adopt advanced obfuscation and randomized linker techniques (e.g., shuffling functions with custom scripts or using LLVM’s -frandomize-layout), the reliability of source‑order pivoting will decline over the next 2–3 years. However, for the vast majority of current commodity malware – including ransomware, stealers, and botnets – this method remains highly effective. In response, defenders will build automated plugins for Ghidra and IDA that highlight “neighbor functions” based on address proximity, turning this manual trick into a one‑click feature. Conversely, advanced threat actors will start inserting dummy functions and reordering symbols to mislead analysts, creating a cat‑and‑mouse game around an otherwise elegant heuristic. Until then, treat every function’s neighbors as prime suspects.
▶️ Related Video (82% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Malwaretech A – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
