Malware triage has an awkward constraint: the most useful AI assistance arrives right when uploading the sample is least acceptable. You are looking at a binary pulled off a compromised host. Shipping it to a hosted model is a data-handling decision you probably cannot make, and definitely cannot make quickly. The usual outcome is that the AI help simply does not happen.
The workspace already has the file
In Zypheron Desktop the artifact is already a project object: file tree, binary summary, hex preview, ASCII sketch, detected kind. From there you trigger a headless Ghidra run in place. The output — functions, imports, warnings, parsed structure — lands back in the same inspector. Nothing left the machine.
kind: ELF · size: 25.8 MB · reason: null bytes detected
> analyze with ghidra (headless)
findings: 2 · functions: parsed · imports: parsed
Why the copilot being local matters
A local model via Ollama reads the Ghidra output and the hex context that already lives in the workspace and answers the questions you actually have: what is this function doing, which imports look like anti-analysis, where is the interesting branch. Same machine, no egress, no data-handling exception to file. Pull the network cable and the workflow is identical.
Shared context is the whole point: the copilot reasons over the parsed binary as a workspace object, not a screenshot you pasted into a chat box.
Honest about failure
- Headless Ghidra can abort — lock conflicts, syntax errors in scripts. The inspector surfaces the real error instead of hiding it.
- A failed analysis is a state you can act on, not a dead end the UI pretends did not happen.
- Re-run, swap the model, or drop to the terminal — same project, no context lost.
That is the series. The thesis, the AD/cloud graph, and RE all lean on one idea: shared context beats stitched tools. Next post: it is shipping.