Deep Binary Analysis Loop

Depth-first RE for full understanding of a specific target area. Distinct from breadth-first triage (reverser/triage) — here you don't stop at a signal, you keep iterating until the function is fully understood.

Core Principle: Narrow → Deep

Triage finds the surface; deep-analysis excavates one shaft. Commit to one question at a time. Context-rot (losing track of what you've already renamed or retyped) is the primary failure mode — guard against it explicitly.

1. Entry Point

Before decompiling anything, state the question in writing:

kg_add_node("hypothesis", "deep-analysis target",
  props={"question": "<exact question, e.g. 'what does sub_401A20 do'>",
         "binary": "/workspace/target",
         "entry_function": "<hex addr or name>",
         "key": "deep-analysis:entry"})

Commit to one question. Do not pivot mid-session unless the current function is fully annotated and the answer is "it delegates to X".

2. Decompile→Rename→Retype→Comment Loop

For each function under analysis, follow this cycle exactly:

2a. Decompile

In hosted runs, use ghidra_find_tools(query="decompile") to discover the native decompiler tool and its argument schema, then pass the imported program and target function. Do not infer a decompiler call from a local-only example. Read the full output before touching anything.

2b. Rename all locals and parameters

As soon as you understand a variable's purpose, rename it. Collect related renames and use the native rename tool discovered with ghidra_find_tools(query="rename"); inspect its schema before calling it. Do not leave a decompiled function with placeholder names (param_1, local_8, uVar1) if you know what they are.

2c. Retype parameters and locals

Correct types catch bugs in decompiler reasoning. Discover the native type editing operation with ghidra_find_tools(query="type") and use the returned schema for the active program. Pay special attention to: size_t vs int (sign confusion), pointer-as-int patterns, struct pointer vs void*, callback function pointers.

2d. Add inline comments

At every branch point whose purpose is now understood, add a comment with the native annotation tool discovered by ghidra_find_tools(query="comment").

2e. Re-read the decompilation

After rename+retype, decompile again. The output will often look dramatically cleaner and reveal previously hidden logic.

Repeat 2a–2e until the function's purpose is unambiguous.

3. On-Task Check (every 3–5 tool calls)

After each batch of tool calls, answer explicitly:

1. Is the current function still the right place to dig?
2. Have I renamed every local/param I now understand?
3. Have I documented what this function does (even partially) in the KG?
4. Am I still working toward the original question, or have I drifted?

If you've called into a callee 3+ levels deep without updating the KG, that's context-rot — surface the findings upward before going deeper.

kg_add_node("note", "deep-analysis progress",
  props={"function": "decrypt_config_blob",
         "finding": "RC4 variant — XOR stream cipher, 16-byte key from .rdata:0x40D0C0",
         "status": "complete",
         "key": "deep-analysis:decrypt_config_blob"})

4. Per-Question Strategies

"What does function X do?"

1. Decompile X.
2. List callees with the registered ghidra_get_xrefs_from tool for the imported program; use ghidra_find_tools when another reference view is needed.
3. For each callee, check if it's a library stub (look up import table) or custom code. Library stubs → infer semantics from function name. Custom code → recurse one level.
4. Draw the call path as a KG calls edge chain.
5. Answer: input/output contract, side effects, return value semantics.

"Identify crypto primitive"

High-entropy constants are the fastest path:

# Search for known crypto constants (AES S-box, RC4 init, ChaCha sigma, etc.)
grep -r "0x63636363\|0x6B617479\|0xE2280613\|0xDB3D18\|0x61707865\|0x3320646E" \
  /workspace/target.bin 2>/dev/null || true

# Capa identifies crypto more reliably
capa /workspace/target --json > /workspace/capa_crypto.json
cat /workspace/capa_crypto.json | python3 -c "
import json, sys
d = json.load(sys.stdin)
for r in d.get('rules', {}).values():
    if 'crypto' in r.get('rule',{}).get('namespace','').lower():
        print(r['rule']['name'])
"

Constants to recognize:

Once identified, rename the function accordingly and document the key schedule location if observable.

"Find C2 protocol / config decryption"

1. Start from network sinks: search imports for connect, WSAConnect, send, write, curl_easy_perform.
2. Follow xrefs upward from the sink to find the function that builds the buffer — that's likely the protocol serializer.
3. Look for the decryption stub called at startup or on first network connect — it usually reads from a hardcoded blob in .data or .rdata.
4. Identify config blob location:

   # Find all large-ish .rdata blobs (>16 bytes, high entropy)
   python3 -c "
   import pefile, math
   pe = pefile.PE('/workspace/target.exe')
   for s in pe.sections:
       if b'.rdata' in s.Name:
           data = s.get_data()
           # scan in 16-byte windows
           for off in range(0, len(data)-16, 4):
               chunk = data[off:off+16]
               counts = [chunk.count(bytes([b])) for b in range(256)]
               ent = -sum((c/16)*math.log2(c/16) for c in counts if c)
               if ent > 7.0:
                   print(hex(s.VirtualAddress + off), 'entropy', round(ent,2))
   " 2>/dev/null | head -20

5. Decompile the decrypt stub. Rename it decrypt_c2_config. Document algorithm + key in KG.

5. Struct Recovery

When you see pointer arithmetic into a struct you don't have a definition for:

1. Note the maximum offset accessed (e.g. [param_1 + 0x28]).
2. Discover the available native struct and field operations with ghidra_find_tools(query="struct"); inspect their schemas.
3. Create a struct large enough to contain the greatest field offset plus its width. Add fields only after validating offsets against the binary.
4. Apply the struct type to all uses of param_1.
5. Re-decompile — member names will appear in the pseudocode.

6. Context-Rot Prevention Rules

• Never go more than 3 callees deep without writing a KG note.
• If you have renamed 5+ functions, update the entry hypothesis with a "state_so_far" field.
• If a function's purpose is "unclear after full loop", mark it status:blocked and surface to orchestrator rather than spiraling.
• Keep a breadcrumb: before entering a callee, record the parent and what you expect to learn from the callee.

7. Completion Gate

The deep-analysis session is done when:

• The original question is answered and documented in KG
• All functions touched have at least a rename + one-line comment
• Crypto primitives identified (or confirmed absent)
• C2 config location/format documented (if applicable)
• Struct definitions created for all major data types

kg_add_node("finding", "deep-analysis complete",
  props={"question": "<original question>",
         "answer": "<concise answer>",
         "key_functions": ["decrypt_config_blob", "build_beacon_packet"],
         "crypto": "ChaCha20 — key at .data:0x40E0A0",
         "c2_format": "TLV over TCP port 4444",
         "key": "deep-analysis:complete"})

Tools