Binary Lab

Move one file through an entire triage workflow

Most browser analysis tools make you re-upload the same sample for every question you ask. Binary Lab holds the artifact once. Drop a file up to 32 MiB, and the workspace records its SHA-256 before anything is stored, then hands those exact bytes to every compatible tool through a session handoff.

The path a triage usually follows looks like this:

1. Open the file in Binary Lab and note the hash.
2. Identify the format with the File Magic Number Checker.
3. Pull indicators with the String Extractor and IOC Extractor.
4. Look for packing or encryption with the Entropy Analyzer.
5. Inspect container structure and signature presence with the Executable & Object Inspector.
6. Decode instructions with the Machine Code Disassembler, or open a module in the WebAssembly Debugger.
7. Write a detection in the YARA-X Rule Workbench.
8. Compare against a known build in Binary Diff & Patch.
9. Export the evidence report.

Every step reads the same stored bytes. You never re-upload, and the hash is re-verified at each handoff, so a report can state which bytes produced which finding.

What the workspace stores

A session is a versioned inventivehq-binary-session/v1 record in IndexedDB. It holds an opaque session ID, the filename, MIME type, byte length, detected kind, SHA-256, the original byte array, an append-only event log, your notes and tags, and any derived artifacts such as patched copies or extracted archive members. Derived artifacts reference their parent rather than duplicating bytes wherever possible.

The URL carries only ?binarySession=<opaque-id>. Sample bytes never appear in a query string, fragment, analytics event, or server log, and no reputation lookup fires without an explicit click.

Findings, notes, and the evidence report

Tools write structured findings back to the session: a severity, a title, supporting detail, and the byte offsets involved. You add your own notes and tags on top. The activity trail shows what ran and in what order.

Export produces either JSON for tooling or Markdown for a ticket. Reports carry hashes, findings, offsets, notes, and the tool sequence, but omit the original bytes unless you deliberately download them. That makes a report safe to paste into a ticket that should not carry a live sample.

Limits worth knowing before you rely on it

• Input ceiling is 32 MiB per artifact, and the workspace retains at most 24 sessions.
• Sessions expire locally after seven days, and deleting one deletes its bytes and metadata together.
• Storage is IndexedDB in one browser profile. It does not sync between machines, and a private window or a browser configured to block site data will fall back to memory and lose the session on close.
• Analyzed code never receives filesystem, network, process, or clipboard capabilities. Nothing in the family instantiates a sample as a running program on your host.

This is convenient investigation state, not a forensic chain-of-custody system and not a hardened malware sandbox. If a sample matters legally, export the report and the original hash into your approved case system and treat that as the record. If a sample is live malware, handle it in an isolated environment; a browser workspace limits what analyzed code can touch, but it is not containment.

Recovering a session you thought you lost

Sessions are keyed to a browser profile, so the usual way to lose one is to open the handoff link somewhere else: a different browser, a private window, or a machine that was not the one holding the bytes. The link carries only the session ID, so it resolves to nothing rather than to someone else's data, and the fix is to reopen the original file in the profile that has it.

Storage pressure is the other cause. Browsers evict IndexedDB under disk pressure without warning, and the seven-day expiry runs regardless. If a session matters beyond the current sitting, export the evidence report while you still have it. The report is the durable artifact; the workspace is scratch space.

When a shared workspace pays off

The handoff model earns its keep on questions that need more than one lens. Deciding whether a stripped ELF is packed means reading entropy and section structure together. Confirming that a patched binary matches a vendor advisory means diffing bytes and then disassembling the changed range. Writing a YARA rule that survives contact with reality means testing it against the exact sample you pulled the strings from. Each of those is three tools and one file, which is the case this workspace is built for.