How Sidekick Analyzes Binaries¶

Sidekick is not a chatbot that answers questions about assembly. It is an agent that plans its approach to your request, changes the binary database as its understanding develops, and records persistent findings. Understanding how it plans and executes makes it much easier to steer.

This tutorial explains the agentic architecture behind Sidekick: the specialist modes it draws on, the persistent structures it keeps, and the decision points that shape how it handles a given request.

Reading versus editing¶

Sidekick's actions fall into two groups:

Reading and analysis — reading, querying, searching, running read-only scripts. The database does not change.
Edits — writing names, types, comments, structure layouts. The database changes.

Sidekick reads the relevant code before editing it. It verifies that a reference you provide (a function, address, or variable) exists in the database before acting on it. If a reference does not resolve, it reports the mismatch rather than guessing a likely substitute.

The two places understanding lives¶

Sidekick keeps its understanding in two different structures, each with a different lifespan and purpose.

The binary database¶

Binary Ninja's representation of the binary: functions, basic blocks, IL instructions, data variables, types, strings, symbols, comments. Dense, concrete, and closed — it contains only what is in the binary itself.

Sidekick's edits — new names, type definitions, comments, structure layouts — land here, applied atomically and grouped into transactions visible in the Transaction Log.

The Notebook¶

Where Sidekick tracks goals and outcomes across turns. An entry represents a goal being pursued. Within an entry:

Tasks — forward-looking steps Sidekick intends to do (tasks are plans, never backfilled as progress logs).
Outcomes — persistent results anchored to evidence. Two kinds:
Finding — an anchored fact ("the function at 0x401500 decrypts config using XOR with key 0x3A")
Artifact — a concrete file-shaped deliverable (a YARA rule, a report, a PoC)
Blockers — an obstacle that needs outside input before work can continue (missing symbols, unavailable runtime). A prerequisite Sidekick can satisfy itself is a task, not a blocker. A blocker is open, resolved, or withdrawn.

Outcomes carry a status (draft, verified, rejected) and are re-checked automatically when their evidence changes. If an outcome gets invalidated, dependent outcomes are revisited too.

Sidekick reuses an existing entry for an ongoing goal, or opens a minimal entry before substantive investigation. Incidental quick lookups don't open another entry.

How Sidekick plans a request¶

Sidekick first establishes your goal, the binary and addresses involved, what a useful result looks like, and any constraints. It then selects methods (skills) that fit, such as capability assessment, vulnerability-class hunting, or challenge solving. You do not need to name a mode or a skill.

A pointed question ("what does decrypt_string take as arguments?") is answered directly from database queries.
A broad goal ("reverse engineer the crypto subsystem") gets a notebook entry and multi-turn execution.
Cleanup requests (rename, retype, annotate) are applied to the database: directly for a small established change, or through the Editing and Annotating specialists for larger passes.
Binary Ninja or Sidekick product and API questions are answered from the documentation.

You can steer this explicitly: "just answer the question" pulls Sidekick toward quick action; "investigate systematically" pushes it toward a tracked effort.

The lead agent and work chats¶

The Workspace Chat is a brief, always-current router for the workspace. It references transactions, notebook outcomes, and work chats rather than reciting them, and it does not start a substantive investigation itself. Tracked investigations, recovery, annotation, research, and similar work run in separate work chats that you can open from the Chats sidebar.

Specialist modes¶

Sidekick keeps the analytical judgment to itself but delegates mechanical work to specialist modes. Each specialist has a narrow scope and a bounded posture — they do one kind of thing well and stop cleanly when they are done. When Sidekick delegates, you see a named tool call in chat with a structured result.

Research — answers a specific missing-fact question that needs a broad search across code, data, documents, or execution evidence: graph walks through unnamed code, semantic pattern queries, searches through repositories and docs. It never changes the database or publishes notebook findings, though it can save a requested report or a collection (a semantic index or code map). It returns the answer first, with the supporting observations and their addresses or sources, and what remains uncertain. It can ask the Debugger for a runtime observation when the answer needs one.

Editing — completes or corrects Binary Ninja decompilation: recovers and applies types, class layouts, and function signatures, and diagnoses and repairs inaccurate local analysis (wrong function boundaries, bad signatures, unresolved indirect calls, stack or analysis errors). It reads before writing, verifies each change, and reports applied transactions and any targets that remain unresolved. It does not patch program bytes unless you explicitly ask. In chat it appears as a Start agent call.

Annotating — improves names and comments on existing analysis without changing its shape: no types, signatures, or layout. It re-checks each target against the current database, can consume results recorded in the Notebook, leaves uncertain targets unchanged, and reports the transactions it applied and the targets it skipped. If broken analysis prevents a defensible annotation, it reports the dependency for Editing. Sidekick applies small, established edits itself and delegates larger recovery to Editing and coherent rename or comment passes to Annotating.

Modeling — builds a bounded, executable or formal model of a specific piece of behavior (a state machine, parser, protocol, or constraint system) from binary evidence. Use it when you want a runnable or solver-checkable artifact rather than prose. It writes source code (Python by default; SMT or Datalog when the question calls for it) plus a manifest tying each rule to addresses, and saves them in the workspace's __models__ repository. It does not modify the database or Notebook and does not run the target. Ordinary behavioral explanations stay in Chat and the Notebook.

Debugger — drives Binary Ninja's debugger to observe runtime behavior: breakpoints at targeted addresses, register and memory inspection, steered execution to reach an observation goal, extraction of runtime data (decrypted buffers, resolved API tables). Mutation is minimized — each one potentially changes the behavior being observed. Every mutation has a stated observational goal.

Authoring — creates reusable analysis capabilities as Library items (Python scripts, local agents, skills, bundles) and validates what it writes. It can hand off to Research when it needs more facts about the binary, and to Debugging when it needs to observe the program running.

Automation — a narrower variant of Authoring. It saves and validates a Library item (a Python script, local agent, skill, or small bundle), but it does not hand work to other agents and does not run the result on the binary. Use this when an analysis should be repeatable, parameterized, or iterated across multiple binaries.

Sidekick delegates only when it gains one of three benefits: context isolation (the specialist absorbs a lot of reads the root does not need to keep), specialization (the specialist's posture differs materially from general-purpose handling), or parallelism (independent subtasks run concurrently). Otherwise Sidekick handles work inline — a single targeted query does not need a research delegation.

Resumable sessions¶

Specialists keep their own thread, and Sidekick continues the same thread for follow-up work instead of starting over:

Debugger sessions hold breakpoints, process state, and observations.
Editing and Annotating threads hold the targets, transactions, and unresolved items of a recovery or annotation pass.
Authoring and Automation threads hold an in-progress Library item, so follow-ups revise the same artifact.
Research and Modeling threads keep their evidence and artifacts.

Ask Sidekick to continue a specific line of work ("continue the debugger session and capture what happens after the bind call") and Sidekick resumes that work rather than starting fresh.

The Suggest operations¶

Alongside Chat, Sidekick exposes single-shot operations at the cursor through the Suggest items in the Plugins > Sidekick menu. Each one fixes goal and scope in advance, then runs a focused agent workflow over the containing function (or, outside a function, a small data window around the cursor). Suggest Imported Types is scoped differently: inside a function it covers the imports that function calls; on an import table entry it covers up to 20 nearby unresolved imports:

Suggest Repairs — diagnoses and repairs inaccurate local analysis around the cursor, then verifies whether the original symptom is resolved.
Suggest Names — recovers meaningful names for default-named identifiers in the containing function, its default-named callees, and the data variables it references. Changes names only; skips uncertain names rather than guessing.
Suggest Types — recovers structure definitions, field names, and applies types. Infers structures from pointer arithmetic, allocation patterns, and library function parameters.
Suggest Imported Types — fills in signatures for imported symbols that have no matching type library loaded, using curated type libraries first and call-site evidence second.
Suggest Comments — adds comments for non-obvious code patterns. Only comments genuinely non-obvious things — over-commenting is worse than under-commenting. Changes comments only.

Each operation launches one focused workflow with a narrow scope. Suggest Names and Suggest Comments only change names or comments and do not repair analysis; if broken analysis blocks a name or comment, that target is left unchanged and reported. Suggest Types repairs a local analysis defect only when it is needed to recover the types in its scope. Run Suggest Repairs first when the decompilation itself looks wrong.

Suggest Imported Types checks curated type libraries first, then infers signatures from known APIs (POSIX libc, Win32, OpenSSL, zlib, etc.) by validating against call-site usage. Recovered types are applied at a confidence level that lets a later-loaded curated type library still override them.

The investigation cycle¶

Within any non-trivial task, Sidekick works in a disciplined loop:

Read — read the relevant code, resolve names, find callers and callees.
Assess blockers — identify missing types, unresolved references, or a concrete analysis defect that actually blocks the goal. A Health warning is only a lead.
Reason — form conclusions about what the code does and what the next step should be.
Improve — apply supported database changes (types, signatures, and, when useful, names and comments): inline for small established edits, or through Editing or Annotating for larger ones.
Record — add outcomes to the notebook when they pass three tests: reuse (will a future turn reference this?), anchor (does it tie to an address or URI?), non-redundancy (is it already carried by a database change or chat reply?).
Continuation check — before ending the turn, ask whether anything is known but not yet persisted, and whether the goal is actually satisfied.

Sidekick does not treat renaming as a prerequisite for reasoning. It reasons over the code as it is, recovers types early when a layout or signature would clarify the dataflow, and applies names and comments once the conclusions are recorded: small established ones inline, larger coherent passes through Annotating.

Skills: reusable playbooks¶

A skill is a reusable procedure keyed to a goal and an artifact kind — "assess a binary's capabilities," "find buffer-overflow sinks," "recover Go function names from pclntab." Skills live in a curated catalog and carry checklists, tactical patterns, and decision points specific to that combination.

Each agent has a set of skills it can draw on. Some are always available to it (for example the recovery methods for types, names, and comments); others become available only when your wording or the evidence matches the skill (for example, mentioning a buffer overflow, a Go binary, or a firmware image). The agent uses a skill when its next step needs that method. Being specific about what you are analyzing therefore changes which skills are available, which in turn shapes how every specialist approaches the work.

The same skill can run inside Chat or inside a specialist — skills are portable procedure; specialists are execution harnesses that host them.

Continuity across turns¶

Sidekick tries to feel like one continuous analyst, not a fresh conversation every time.

Briefing — each new chat starts with the current Session Briefing (goal, status, key findings, current focus, open questions, and wayfinding landmarks), so you do not have to re-explain context.
Notebook — outcomes carry across turns and sessions. Validation runs in the background, so a finding that gets contradicted by later evidence transitions to rejected rather than silently staying true.
Skills — chosen per conversation based on the goal and your wording; they are not carried as a persistent workspace list.

When Sidekick has the context it needs, it uses it. When it doesn't (new workspace, fresh binary, first conversation), it builds it.

The Transaction Log¶

Every database change is a transaction. The Transaction Log lists them, shows what each one modified, and offers Revert for committed analysis updates that recorded their previous values (see Transaction Log). Transaction entries also appear in chat next to the agent action that produced them, so you can audit exactly what a Suggest operation or an Editing or Annotating pass did.

Working with Sidekick effectively¶

Talking to Sidekick vs. Suggest operations¶

Talking to Sidekick invokes the agentic workflows. In the Sidekick tab, each workspace's Chat tab is that workspace's lead agent (the Workspace Chat): it answers quick questions directly, applies small established edits, and routes substantial work to the workflow that owns it — a tracked investigation (planning, notebook, continuation), Editing, Annotating, Research, Authoring or Automation, Debugging, or Validation — which runs as its own work chat you can open. A new chat started in the Chats sidebar talks to the investigation agent directly, with the same planning, delegation, notebook, and continuation behavior. Talk to Sidekick when:

You want to understand what a function or subsystem does
You are investigating a specific behavior or vulnerability class
You want to ask follow-up questions and steer the analysis
You need Sidekick to cross-reference findings across multiple functions

Suggest operations are fixed-scope, single-shot. Use them when:

You want quick coverage of the function you are currently looking at
You want to apply names, types, or comments without opening a full investigation
The decompilation around the cursor looks broken and you want to fix the analysis before doing other recovery work

References and @-mentions¶

Sidekick resolves references you provide before acting on them. Refer to functions by name or address:

"What does sub_401200 do?"
"Trace the call chain from 0x401000 to any network I/O."
"Rename everything reachable from parse_config."

Default-named functions are valid references. If the reference does not resolve, Sidekick reports the mismatch rather than guessing a similar name.

Steering scope¶

You can guide the quick-action vs. tracked-effort decision:

For a broad investigation, expect a notebook entry and multi-turn execution: "reverse engineer the crypto subsystem end-to-end."
For a targeted lookup, expect a direct answer: "what's the third argument to send_packet?"
Mid-investigation, narrow or widen: "focus only on the decryption routine, skip everything else," or "expand this to cover all callers of process_message."

Continuing sessions¶

When a specialist such as the Debugger, Editing, or Authoring has an ongoing thread, ask Sidekick to continue it in follow-ups rather than starting over:

"Continue the debugger session — let the network call complete and capture the response."
"Update the automation to also handle indirect calls."
"Revise the plugin to also register a string renderer for wide strings."

Combining specialists¶

The most effective pattern is often: ask Sidekick to recover types and signatures on the region you care about (Editing), fix any broken local analysis it surfaces (or run Suggest Repairs), have it apply names and comments once the conclusions are recorded (Annotating), then use Chat to reason about what the cleaned-up code reveals. The specialists handle mechanical recovery; Chat handles interpretation.

Tip

Tell Sidekick what you're looking at. "This is a Linux malware sample, likely a cryptominer" or "I'm reversing a custom parser for a proprietary file format" steers skill selection and scopes the analysis far more effectively than a generic "analyze this binary."