Starting state
You have a sample collected from a host during an engagement, and you have kept it local. Nothing has been uploaded to a sandbox or a third-party service. This matters on air-gapped or no-egress engagements where the sample cannot leave the environment, and Zypheron is built local-first to respect that.
Inputs
- The binary itself, sitting on your local disk.
- The host it came from, so the resulting finding can be tied back to its source.
Key steps
1. Add the sample to Code/RE
Open the Code/RE workspace and add the binary to the project tree. It now lives inside the project alongside any other artifacts from the engagement.
2. Preview before you commit
Use the text and hex preview to get a first read: strings, headers, packing hints, and anything that tells you whether this is worth deeper analysis. This step costs nothing and often answers the question on its own.
3. Submit to a disassembler
Submit the binary to Ghidra, radare2, IDA Pro, or Binary Ninja. The submission runs against your local install, so the bytes never leave the box.
4. Read the recovered code in place
Recovered code lands as a virtual subtree under the original binary in the project tree. You browse the decompiled or disassembled output without juggling separate tool windows or exporting files around.
5. Ask a local model to explain it
In the chat sidebar, @mention the file to ground the prompt on the actual recovered code, then ask a local Ollama model to summarize what it found. Local-AI-first means you can do this with no model-traffic proxy and no egress, which keeps the workflow valid on air-gapped engagements.
@suspicious.bin Summarize what this recovered code does and flag anything that looks like persistence or C2.
Local-first by default
You can point the assistant at your own Anthropic or OpenAI key under Settings > AI, or run entirely local models through Ollama. For a sample you must not exfiltrate, the local path keeps the whole triage on your machine.
Expected outputs
Recovered code in-project
Decompiled or disassembled output sitting as a virtual subtree under the original binary, ready to browse.
An explained summary
A grounded summary from the local model, plus a finding tied back to the source host and persisted to the encrypted local store.
Common operator decisions
Which disassembler. Ghidra is a strong default with full decompilation, radare2 is fast and scriptable for quick triage, and IDA Pro or Binary Ninja fit if that is where your muscle memory lives. The choice does not change where the bytes go: all of it stays local.
Where AI helps, and where it must not. The model is good for orienting you fast and pointing at suspicious functions. Do not trust its read of behavior blindly. Confirm anything load-bearing against the recovered code yourself before it becomes a finding.
Keeping the sample local. On air-gapped or no-egress engagements, stay on Ollama and skip any cloud key. Confirm your AI settings before you @mention the file so nothing about the sample leaves the box.
Get AD security drops in your inbox
Release notes, identity attack-path research, and early access. Low volume, real signal only. Unsubscribe anytime.
