Hopper MCP

Use only for an explicit Hopper/binary-inspection request. Generic words such as reverse engineering, decompilation, interoperability, app behavior, or binary format are not enough to activate this skill.

Hopper's tools navigate an analysis database the user has open. The job is to locate relevant code quickly, interpret lossy output without being seduced by plausible pseudo-code, and separate confirmed behavior from attractive guesses.

Establish the target

1. Confirm the binary/bundle, architecture, provenance, and question.
2. Use list_documents to identify the open documents and select the exact target by name. Use current_document only when the foreground GUI document matters; focus is not a reliable substitute for choosing a target.
3. Pass that document name in the document argument of every document-scoped tool call. Wait for each target's initial analysis to finish; partial analysis produces false absences.
4. For an app bundle, determine whether the behavior lives in the main executable, XPC service, login item, helper, framework, or extension before interpreting a missing result. The main executable is often only the UI shell.

Inspect and compare multiple open documents when the question spans components. Keep addresses, search results, annotations, and conclusions labeled with their document; an address in one document does not identify the same code in another. Recheck the selected document and analysis state whenever results appear inconsistent.

Search broad, trace narrow

Read references/tool-workflow.md.

• Start with targeted strings, names, selectors, classes, URLs, paths, and error text. Avoid dumping global procedure/string tables.
• Follow cross-references to candidate functions, then use callers to find how a feature is reached and callees to find what it can affect. A feature's shape is often visible in the call graph before its pseudo-code is readable.
• Inspect function size/blocks before decompiling. Use assembly when pseudo-code loses control flow, constants, dispatch, or pointer indirection.
• Read bundle metadata, entitlements, linked libraries, and exports as capability context—not proof that a path executes.
• For static pointer tables and chained fixups, use platform tooling that resolves encoded on-disk pointers; raw bytes may not be addresses.

Annotate or rename inside Hopper only when useful and within the user's request. Prefer comments that state evidence and uncertainty. Do not turn a tentative hypothesis into a persistent symbol name.

Evidence discipline

Separate:

• present: code/data exists in this binary;
• reachable: a known entry path can call it;
• observed: runtime evidence shows it executed;
• inferred: the best explanation, not yet corroborated.

Corroborate material findings with independent signals such as string + xref + caller/callee, metadata + implementation, or static path + runtime observation. One suggestive name is a lead, not a finding. Hopper pseudo-code and symbol recovery are lossy.

Read references/binary-reading.md for Objective-C, Swift, Mach-O, and terminal details. Read references/scenarios.md for common investigations.

Report behavior first

Lead with behavior in plain language, then supply mechanism where it explains the result. “It scans this directory on launch” is usually more useful than opening with an objc_msgSend signature. State target binary/architecture, evidence grade, path to the relevant code, corroborating signals, uncertainty, and the next check that would upgrade confidence. Distinguish what the app can do from what it does in normal use—the classic overclaim is finding an upload path and reporting that normal use uploads data without proving reachability or observation.

When documenting a format or interface for interoperability, separate observed bytes/calls from proposed semantics and preserve representative hashes/offsets so another analyst can reproduce the claim.