AI reverse engineering with byte-identical verification

relumea analyzes stripped binaries with an AI agent, then recompiles each recovered function with the original toolchain and compares it with the binary, so you know which results are exact.

Create account How verification works

60 / 60 bytes identical · EXACTcrc32_update, sample function

Try an approval decision

Choose whether the agent may rename this function.

call 07 of 09rename_functiongated

The agent called a tool that changes data, so the run is paused until you decide.

{ "function_id": 3, "name": "decode_config", "actor": "agent" }
→ rename_function

Nothing is written while it waits.

Illustrative. The run is a sample, not a capture.

Start with the binary you have

Inspect how it works, recover the source that matters, and verify the result against the original bytes. Your findings, code and change history stay together in one workspace.

Triage to detection rules on a stripped binary

Identify what a binary does, recover its functions and turn the findings into detection rules.

Agentic malware analysis: Identity, imports, capabilities, protocols and ATT&CK mapping in one run, with a threat score, family detection against your own reference samples and a written summary.
Function matching: Match functions against your own corpus, compare candidates side by side and carry names across to the binary you are working on.
AI decompilation: Decompiler output with model-proposed names, comments and types, with journaled edits and conditional recovery.
Detection rules and reports: A YARA rule, Snort 2 rules per network indicator, a STIX 2.1 bundle, an SBOM and a PDF report, generated from the same scans.

Source recovery and verification

Byte-identical verification
Recovered source is recompiled with the target’s own toolchain and compared with the original bytes.
The original compilers
272 compiler toolchains in the catalog. Establish the exact version and flags for each target.
Flag search and equivalence proofs
Near matches can be retried across compiler flags and source variants. Where bytes still differ, a scoped equivalence proof can be attempted; failed and inconclusive results remain visible.
Decompilation projects
Reconstruction projects retain recovered source, build inputs and per-function verdicts, including failed and unattempted work.

Works with your tools

Ghidra: renames as a runnable Python script
IDA Pro: renames as an IDA Python script
Binary Ninja: renames as a JSON document
MCP: every registry tool, for agent clients
REST API: the API the web workspace uses
CLI: relumea, from a terminal
SBOM: CycloneDX, SPDX or CSV per artifact
Detection: YARA, Snort 2 and STIX 2.1

When the source is missing

For teams that need to understand, maintain or rebuild software from the binaries they have.

Game preservation and porting: Recover source from back-catalog executables and verify it against the shipped game before adapting it for a new platform.
Industrial and OT software: Understand and maintain control software after the original source, build environment or vendor support is gone.
Patching without source: Inspect a vulnerable function, recover editable source and use the byte diff to review the scope of a change.
Binary software inventories: Identify library code and its provenance in third-party binaries, then export the findings as CycloneDX or SPDX.
Medical-device security: Inspect aging device software and retain evidence for patch review. Engineering evidence supports the separate clinical validation process.
Defense and avionics sustainment: Check recovered source against the fielded binary and preserve the compiler version and flags used to rebuild it.
Government and enterprise legacy: Investigate Windows clients and utilities that still support daily operations when their source is lost or incomplete.
Escrow, interoperability and forensics: Test whether supplied source rebuilds a delivered binary, or recover the functions needed to understand its behavior and interfaces.

One triage run, call by call

The agent runs triage tools in order and cites the evidence for each finding. In this run 8 read-only calls ran without asking; the rename waited for an analyst's approval.

Illustrative sample · updater_svc.exe

Task: Triage updater_svc.exe: find the persistence mechanism and the C2 send routine.
Target: PE · x86_32 · mingw-14.2.0-win32 · 412 functions · sha256 a7ed6974787de73373b3ca48d32faaf6611b6745ed362e85599282d68c1489d4

01get_pe_inforead-only
{ "binary_id": 1 }
PE · x86_32 · 4 sections · 196,608 bytes
02get_importsread-only
{ "binary_id": 1 }
106 imports from 5 libraries
03get_capabilitiesread-only
{ "binary_id": 1 }
networking · persistence · process-injection
04get_protocols_scanread-only
{ "binary_id": 1 }
http
05get_threat_reportread-only
{ "binary_id": 1 }
3 ATT&CK techniques · software type · threat score
06get_decompilationread-only
{ "function_id": 3 }
fcn.00401a20 · 10 lines of C
07rename_functiongated
{ "function_id": 3, "name": "decode_config", "actor": "agent" }
journal_action 31 · name_history row written
The run paused here until an analyst approved the rename.
08get_matchesread-only
{ "function_id": 3 }
8 candidates from your corpus
09get_remediationread-only
{ "binary_id": 1 }
YARA rule

Findings

From the import table and strings. Each finding lists the import that triggered it.

networkinghigh
capabilities · WinHttpSendRequest
persistencehigh
capabilities · RegSetValueExA
process-injectionhigh
capabilities · CreateRemoteThread
anti-debug-apihigh
hardening · IsDebuggerPresent
httphigh
protocols · WinHttpOpen
T1071 Application Layer Protocolhigh
threat · WinHttp* + WS2_32
T1547 Boot or Logon Autostartmedium
threat · RegSetValueExA on a Run key
T1055 Process Injectionhigh
threat · CreateRemoteThread

Byte-identical verification

Function matching and AI decompilation give you a likely answer. relumea checks it: the recovered source is compiled with the same compiler and flags as the target, and the output is compared with the original bytes. Point at a line on either side to see how source and instructions correspond.

Illustrative sample · updater_svc.exe

Recovered source

cfg/decode.c

Line 6 → 8 instructions, 22 bytes

00401a3089d1mov ecx, edx
00401a328b742414mov esi, dword ptr [esp + 0x14]
00401a3683e103and ecx, 3
00401a39c1e103shl ecx, 3
00401a3cd3eeshr esi, cl
00401a3e89f1mov ecx, esi
00401a40320c13xor cl, byte ptr [ebx + edx]
00401a43880c13mov byte ptr [ebx + edx], cl

Original bytes

mingw-14.2.0-win32

54 / 54 bytes identical · EXACTdecode_config · 0x00401a20

From stripped binary to verified source

One stripped PE function, four recorded outputs. Select a line to trace it.

Original assembly

0x00401000 · 60 bytes · no symbols

Decompiler output

Ghidra (rz-ghidra)

Corrected C

names, types and structure

Names: fcn.00401000 → crc32_update, arg_4h and uVar2 → crc, arg_8h → buf, arg_ch → len, iVar3 → bit
Types: int32_t → uint32_t, char * → const uint8_t *, int32_t → size_t
Structure: end-pointer loop → while (len--), countdown do/while → for over 8 bits, uVar1 and puVar4 dropped

Recompiled assembly

mingw-w64 gcc 16.2.0 -Os

60 / 60 bytes identical · EXACTcrc32_update · 0x00401000

Decompilation projects

Each binary becomes a project: a tree of recovered source files that builds with the original toolchain, and a verdict for every function. This project covers all 412 functions, including the ones that do not match yet.

Illustrative sample · updater_svc.exe

85.2%

matched or proven · 351 of 412 functions

EXACT198: Recompiled bytes identical to the original.
RELOC141: Identical except for addresses the linker fills in.
PROVEN12: Bytes differ; equivalence proven within the proof's assumptions and checked scope.
NEAR2: At least 60% of bytes match; the rest is usually register allocation, instruction order or a compiler flag.
STUB3: Under 60% of bytes match: not implemented yet, or control flow differs.
SIZE_MISMATCH4: Compiles, but the rebuilt function has a different length.
LIBRARY12: Attributed to a library. Its byte-verification result is a separate finding.
unattempted40: Not attempted yet. Counted in the total.

When a function is close, relumea can search compiler flags and source variants for an exact match or attempt a scoped equivalence proof. Failed and inconclusive results stay in the project.

Function ledger
Address	Name	Size	Verdict	Source
0x00401020	svc_Main	1,842	STUB	svc/main.c
0x00401840	cfg_LoadEncrypted	412	RELOC	cfg/load.c
0x00401a20	decode_config	54	EXACT	cfg/decode.c
0x00401c80	net_OpenSession	288	RELOC	net/session.c
0x00402210	http_SendBeacon	640	NEAR	net/beacon.c
0x00402a90	reg_PersistRunKey	196	EXACT	persist/runkey.c
0x00403100	inj_WriteRemote	720	PROVEN	inj/remote.c
0x004038c0	anti_IsDebugged	48	EXACT	anti/debug.c

Data handling and control

What the workspace does with your binaries, and what the agent is allowed to change.

Stored by content hash: Each binary is kept under its sha256 in your workspace.
Model features are opt-in: AI routes stay off until the workspace configures a model.
Built-in agent approval: The built-in agent pauses state-changing tool calls for approval. External MCP clients apply their own approval policy.
Journaled changes and recovery: Supported changes retain prior values for conditional recovery. External effects cannot be undone; recovery may be partial.

Frequently asked questions

The hosted service, matching, languages, the model, packers and the tools you already use.

What does the hosted service include?

The hosted service supports upload and static inspection. Analysis is not hosted yet. Paid checkout is closed. Free-plan uploads are shared with approved signed-in users. Each uploaded binary shows its format, architecture, pointer size, language, sections and exports.

How is this different from similarity-based function matching?

Similarity matching suggests what a function probably is. relumea uses it as a starting point, then recompiles the recovered source and compares it with the original, so each function ends with a verdict instead of a score.

Does relumea depend on an LLM?

The capability, protocol, hardening and secrets scans, the ATT&CK mapping, the matching and the byte comparison run without a model. The model is opt-in: it drives the agent and proposes names, comments and types for stored decompilation.

What happens when a function does not match?

Its verdict records how close it got (NEAR or STUB), and it stays in the project and in the coverage figure.

How do you handle packed malware?

Filetype detection names the packer from section names, entry-point bytes, constants and entropy. LZEXE and UPX can be unpacked on request; a packer that rewrites its own stub is not identified.

Does it work with Ghidra, IDA Pro and Binary Ninja?

Yes. Renames export as a Python script for Ghidra or IDA and as a JSON document for Binary Ninja.

Can it match across architectures and file formats?

Only coarsely. Platform and architecture scope is inferred from the stored fingerprint, and results say it is inferred.

Which source languages does it handle?

Analysis identifies C, C++, Visual Basic, Delphi, Go, Rust, Swift, packaged Python, AutoIt and Electron. Go metadata includes compiler version, main module and build settings. Byte-identical verification currently recompiles C and C++.

Do you support firmware?

Yes. Firmware has its own extraction and scanning pipeline, separate from PE analysis.

Get product updates

Get product news and updates by email. The hosted service supports upload and static inspection. Analysis is not hosted yet. Paid checkout is closed. Free-plan uploads are shared with approved signed-in users.

Ready to create your account? Create account