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 reviewing a firmware release and an exposed network service needs investigation. You want to understand its request handling, check a suspected weakness, and identify the evidence needed before making a release decision.

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 dnsmasq example below shows the function list, disassembly, decompiled code, and cross-references from an extracted OpenWrt binary. These views let a reviewer inspect the code behind an investigation.

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 a service's request handling while another examines a related binary 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 a firmware service, 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 security teams. The dashboard connects component inventories, SBOM checks, advisory matches, and version changes to the code under investigation. Analysts can inspect that code, write notes, and launch built-in agents in the browser. Analysis, 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.

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 firmware release, 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.