Reduce Repeated Reverse Engineering. Keep the Evidence.

Leave an AI agent investigating a binary overnight. It follows references, examines functions, tests explanations, and records findings.

By morning, I want to see what it examined, where it got stuck, and which claims I can verify. If another researcher ran an agent too, I want to see how our findings connect.

That requires a shared investigation: code, changes, and evidence that outlast any one conversation.

Get a second opinion without rebuilding the investigation

Suppose you're examining a signed Windows driver found during a malware investigation. You're checking for possible BYOVD abuse: malware taking advantage of a vulnerability in an otherwise legitimate driver.

You've annotated its request handler and written notes about a suspicious code path. Before calling it a vulnerability, you want another researcher to check whether you've missed an access check.

Sending a database is a lot of setup for that question. The other person may need to download it, open it in a compatible tool, and find the functions you mean. A screenshot is easier, until they want to follow a reference or inspect something just outside the frame.

I'd rather send one URL.

They open the research notes alongside the disassembly and decompilation in their browser. They can follow the addresses in the notes, inspect the caller, and look beyond the functions I highlighted. No database download, decompiler installation, or account needed for the read-only view.

We can get straight to the question: "Have I missed a check here?" The notes don't have to be a finished report. They can include what I've ruled out and what I still don't understand.

The screenshot below shows the shared view: research notes, disassembly, decompiled code, and cross-references remain together for review.

Delegate routine analysis without tying up your laptop

The other thing I want is fairly mundane: to close my laptop while the work carries on.

One binary might be manageable locally. Several related binaries, analysis databases, debug symbols, and agent workers can take a lot more memory and compute. I want to try those jobs without keeping my everyday computer occupied.

That's why I put the setup in the cloud. I can allocate larger machines and more workers when the work calls for them. The agent runner lives there as well as the analysis tools. Moving just the decompiler wouldn't help if the agent deciding what to do next still stopped with my laptop.

A lab server could do this too. The important part is that the job has its own resources and doesn't depend on someone's desktop session staying open.

It also gives other people somewhere to launch their own agents. One person can trace the driver's request handling while another examines a related driver or tries a different explanation. Independent jobs can run alongside each other. If one step needs the previous step's answer, extra machines won't change that.

I still want limits on how much a run can spend and what it's allowed to change. Some jobs should stop and ask for a review. Leaving something running overnight shouldn't mean giving it permission to do anything it wants.

Keep corrections and evidence ready for the next analyst

In Reverser Space, the shared URL opens the investigation rather than an exported copy. If I add an explanation to the notes while you're reading, the update stays in the same session. Analysis changes and agent activity are kept there too. I don't have to send another file or ask you to open a newer version.

It has the familiar feel of a shared Google Doc: you can see who's there and work together while the research is changing. A read-only link lets someone watch. Inviting them as an editor lets them contribute to the analysis and notes.

For the driver, that might mean discussing a check in the caller while an agent examines another path. The correction stays beside the code it refers to, where the next person can find it.

We still have to verify the finding. Two agents can agree because they're both reading the same wrong type or misleading name. Decompilation depends on types, function boundaries, and calling conventions, as Ghidra's advanced analysis material illustrates. A shared view makes that discussion easier; it doesn't settle whether the suspected vulnerability is real.

Review supplier software in the same workspace

I am building Reverser Space for firmware and binary supply chain security. The dashboard brings together component inventory, supplier SBOM checks, disclosed vulnerabilities, and version changes. When a finding needs deeper investigation, this shared workspace is where analysts inspect the code. It runs in the browser: upload a binary, inspect the analysis, write notes, and launch built-in agents. There's no local decompiler, plugin, or MCP server to install for that workflow. The analysis, notes, findings, and run history stay with the shared session.

An agent can trace references and annotate functions while an analyst checks a suspected behavior. When another researcher joins, the names, comments, and notes are already there. They can see which paths were checked and what remains unresolved. The agent still needs limits on its permissions and spending.

The built-in agents run on the server. Different users' missions can run concurrently within the configured limits; tasks inside each mission run in order. If the server restarts, queued work stays queued. Work that was running is marked interrupted and can be retried. I don't want a task shown as finished just because the process that was doing it disappeared.

Ghidra is the current backend. IDA or Binary Ninja would need their own adapters. I think of the workspace as separate from that choice: changing the analysis engine shouldn't mean throwing away the surrounding investigation. Results still need to say which engine and state they came from. If an old state can't be recovered, that needs to be visible too.

If you're working with one agent on your own machine, integrations such as GhidraMCP or Binary Ninja's MCP servers may be all you need. I'm building for the point where you want to leave several jobs running, bring other people in, and not spend the next morning explaining what happened in each chat.

For that driver, I'd want to come back to the paths we've checked, the access checks we've found, and the questions still open. If another researcher has time to help, I can send them the link. They can see the work so far and, with editor access, pick up a thread themselves.

The same saved investigation can support a malware escalation, a vendor-software review, or a product-security decision. Analysts still verify the conclusions. The goal is to spend less specialist time repeating analysis and collecting evidence when another researcher or customer needs to review the work.