Inspect binary layout
Run rea inspect-binary-layout with JSON output on an approved artifact to obtain file layout evidence.
REA
REA gives a coding agent a CLI or MCP interface for inspecting authorized binaries and applications. Start with one artifact and preserve the evidence behind each conclusion.
Inspect an authorized binary with REA
Identify the local artifact and ask a precise question before choosing a static inspection.
Provide an approved file and the expected build target.
Copy the request into a new Floatboat conversation and provide the required material.
Download FloatboatYour request for Floatboat
Preview and copy the request. It is not sent automatically from this page.
Reference: REA https://github.com/morluto/rea Read the original documentation and check the current environment and dependencies. Propose any new installation or tool connection before proceeding. My task: Review REA’s official binary diagnostics. Check whether the REA CLI or MCP is available and show the planned read-only layout inspection for my approved binary. After I approve the command, run the inspection without launching the binary and save the evidence alongside the summary. Expected deliverable: A layout summary with the artifact reference and evidence for each claim.
About REA
REA, short for Reverse Engineer Anything, connects coding agents to tools for inspecting software artifacts. Use the documented Codex plugin, register its MCP server, or call the CLI from an approved terminal.
The reverse-engineering Skill provides the workflow, while the connected REA tools perform the inspection. A plugin can bundle the Skill and server. Installing only the Skill leaves the MCP registration and analysis engines to be configured separately.
Choose the operation based on the artifact and the question. A static layout report can establish architecture or section information, while deeper analysis may need a compatible provider. Keep tool evidence and your interpretation separate.
What REA Can Inspect
First check what the active client can run. Then choose a static or provider-backed operation and record enough evidence for someone else to reproduce the result.
Check provider availability
Use the active MCP session’s binary_session tool to see which analysis tools are available and what blocks the others.
Keep evidence with observations
Record the selected input, operation, and provider when reporting a result. Keep unsupported or incomplete checks visible.
REA Use Cases for Evidence-Based Software Inspection
Use a known local artifact first, then increase scope only when the question calls for it. The workflow can produce a layout report, a version comparison, or an evidence-backed handoff.
Check an internal build artifact
Supply a compiled binary from your own build and its expected target architecture. Ask the agent to inspect the layout without running the binary, then compare the reported architecture and sections with the build configuration.
Inventory a desktop app package
Point REA at a desktop application package your team owns. Request an inventory of executable and resource candidates so a reviewer can select the relevant file and scope the next inspection.
Compare two release artifacts
Collect the two authorized binary artifacts and run the same static inspection against both. Save the separate evidence records and identify changed sections or layout details for the release engineer to confirm.
Diagnose an analysis provider gap
Have the agent inspect tool availability from its connected MCP server. Compare the response with the operation the team needs, record missing prerequisites, and hand off a narrower check if the required provider is unavailable.
What an REA Session Needs
Start with an approved artifact and a clear question. Match the client, platform and optional provider to the operation, then choose where to retain output.
Authorized artifact
Use a file or application your team may inspect. Specify the expected location and keep the first run static.
Working CLI or MCP registration
Follow one official installation path for the chosen client. Verify the plugin or server in that client before starting.
Operation-specific provider
Confirm the requested operation is available in the active client. Install or configure additional analysis tools only if needed.
Related Software Projects
Compare the workflows, operating requirements, and source licenses of these projects.
REA FAQ
Is REA a Skill or a tool?
The project provides a CLI and MCP tooling alongside the workflow Skill. The Skill can guide an agent, while inspection capabilities depend on the installed tools.
Can Codex run REA?
The upstream installation guide documents a native Codex plugin and separate MCP registration. Check the selected route in your Codex client.
Does installing the Skill configure MCP?
A standalone Skill installation adds the guidance and references. Configure the MCP server and relevant engines separately if the selected workflow needs them.
Can I do a static check before running a binary?
Yes. The documented inspect-binary-layout operation returns file layout evidence without launching the inspected program.
How do I check available binary tools?
Ask the connected MCP server for binary_session and inspect its tool_availability output. This reflects the server used by that client.
What belongs in the handoff?
Keep the artifact reference, selected operation, provider and evidence next to each observation. List unresolved questions so a reviewer can repeat the check.