mirror of
https://github.com/alexmi256/rea-agent-docker.git
synced 2026-11-07 09:45:59 -10:00
Hermes Agent
a58f16224c
`make check-updates` failed with BEHIND-REA on both Hopper rows: the vendor's
publisher-signed release feed moved its Ubuntu/Mint entry from Hopper 6.6.1 to
6.6.2 on 2026-11-06 16:22 UTC. REA 6.8.0 admits a Linux Hopper only when the
installed launcher is the feed's *current* main_exe_hash, so the old pin was
already wrong - and the build layer would have refused outright ("Hopper feed
moved: Hopper-6.6.2-Linux-demo.deb is no longer Hopper-6.6.1-Linux-demo.deb").
rea-agents itself is current: 6.8.0 is the newest npm release *and* the newest
github tag (v6.8.0, 2026-10-25), and its release notes list nothing pending for
Hopper beyond the feed-admission rule already implemented. So nothing else moved:
same REA_VERSION, same Node 24.22.1, same bundled skill (v49 / 229 tools), same
Ghidra 12.1.4, same helper tools (unicorn stays held at 2.1.2 because pwntools
4.15.0 excludes 2.1.3/2.1.4; Node 24.22.2, frida 17.26.1, uv 0.13.7,
supergateway 4.2.1, mitmproxy 12.3.1, pwndbg 2026.10.28 and Ghidra 12.2 are
newer upstream but wait for the next REA release per docs/UPDATES.md).
Re-pinned to the feed's row:
HOPPER_DEMO_VERSION 6.6.1 -> 6.6.2
HOPPER_DEB_SHA1 a2c28339..-> 9b46788160ba0b37f9050e0aa23a1372b3ecff53
HOPPER_DEB_BYTES 35749234 -> 35749280
HOPPER_LAUNCHER_SHA256 74b51599..-> 226800f154d766664bad5c45912f3a606ffa894316f97464f3c37f01fab5fb82
None of it was taken on trust: the .deb was downloaded (35,749,280 bytes,
sha1 9b467881...), its detached PGP signature verified against the vendor key
whose primary fingerprint is 7C2D73BAFAF5B9A710A69DA1A26DF815099B1BCD - the one
REA pins as HOPPER_LINUX_PRIMARY_FINGERPRINT - and opt/hopper/bin/Hopper hashed
out of the unpacked package (226800f1...), which is what the feed claims. The
build re-checks all four against the live feed, verifies bytes + SHA-1 and the
installed launcher, and bakes the signed evidence under
/home/rea/.cache/rea/hopper-releases/226800f1.../ (archive, release.json,
public-key.asc) so admission works offline; `rea doctor --provider hopper --json`
reports hopper-version healthy, reported_release_version 6.6.2,
source signed_package_cache.
Verified: scripts/build-all.sh (all four rebuilt; Hopper layer 3 min, the rest
cache hits), scripts/verify-all-engines.sh - all 121/0/3, ghidra 109/0/8, hopper
102/0/7, ida 94/0/11, 0 failures, exit 0 on every image; runs 20261107T091717Z /
20261107T092924Z / 20261107T094115Z / 20261107T094312Z. Counts are identical to
the 6.6.1 round; docs/verify-engines.txt regenerated and the sweep recorded in
docs/VERIFICATION.md. `make check-updates` is back to 0 actionable / 0 unknown /
0 unverifiable.
Docs that name the shipped Hopper build follow the pin (README, ARCHITECTURE,
MULTIARCH, BYO-LICENSES, TROUBLESHOOTING, vendor/README, the checker's header
comment); the 6.6.1 and 6.6.0 records in docs/VERIFICATION.md keep the versions
they actually ran.
5.8 KiB
5.8 KiB
Other architectures: what the container gives you
REA analyses binaries for many architectures; the depth depends on the engine you point it at and on whether you need to run the code or only read it. These images are built so both are possible.
Which engine you have depends on which image you built: Ghidra in rea-agent
and rea-agent-ghidra, Hopper in rea-agent and rea-agent-hopper, none
bundled in rea-agent-ida (see IMAGES.md). The recipes below use
the all-engines service rea-agent; swap in your service name
(rea-ghidra, rea-hopper, rea-ida) if you run a single-engine image.
Architecture coverage of the engines
| Engine | Architectures it can disassemble/decompile | Notes | Image |
|---|---|---|---|
| Ghidra 12.1.4 | x86/x86-64, 16-bit x86 (DOS MZ/COM), ARM/Thumb (32/64), MIPS (32/64, LE/BE, micro), PowerPC, RISC-V, SuperH, 6502/65816, Z80, 68000, Atmel AVR, MSP430, Tricore, ... | The broad engine. The native decompiler for the host (linux_x86_64) is shipped and is what REA requires. |
all, ghidra |
| IDA Pro/Home | 60+ processor modules depending on licence tier | Only via your own IDA + MCP registration. IDA Free = x86/x86-64 only, cloud decompiler, no idalib. | all, ida (BYO) |
| Hopper 6.6.2 | x86/x86-64, ARM/ARM64 (incl. Mach-O, dylibs), and the container formats of Apple platforms | Weaker on MIPS/PPC/RISC-V. macOS .app/FAT binaries and FAT64 are handled by REA's Hopper loader preparation. 6.6.2 is the build the vendor's signed release feed currently authenticates, which is the only Linux build REA 6.6.0+ admits. |
all, hopper |
Practical consequence: Ghidra is the default for anything unusual. REA's
own docs cover the pinned profiles for MIPS (MIPS:<LE|BE>:32:default),
RISC-V (avoids the Andes default pitfall), PSP (Allegrex:LE:32:default
requires the Ghidra PSP extension) and 16-bit DOS; the relevant env knobs are
in docker/rea.env.example.
What is installed for the non-x86-64 work
| Need | Provided |
|---|---|
| Build fixtures for other targets | cross compilers: aarch64, arm (gnueabihf), mips, mipsel, riscv64, powerpc, mingw-w64 (PE32+) |
| Run foreign-architecture Linux binaries | qemu-user-static for every qemu target (also usable as qemu-mips -L /usr/mips-linux-gnu ...) |
| Run Windows PE binaries | wine / wine64 |
| Debug foreign binaries | gdb-multiarch, gdbserver (via gdb-multiarch --args), qemu-* user-mode gdbstub (-g 1234) |
| Emulate instructions statically | Unicorn 2.1.2 inside REA's pwntools venv (used by inspect-binary-layout; held at 2.1.2 because pwntools 4.15.0 excludes 2.1.3/2.1.4) |
| Cross-platform core dumps | inspect-recorded-crash interprets x86-64 and AArch64 ELF64 cores |
| Non-Linux formats | Mach-O/FAT/FAT64, PE/PE32+, DOS MZ/COM, ELF, raw binary imports, Amiga/C64 containers (Ghidra) |
Recipes
Analyse an ARM64 firmware binary with Ghidra
docker compose exec rea-agent rea analyze /targets/router.bin --provider ghidra --json
# raw/headerless images carry no language hint - pin one:
docker compose exec -e REA_GHIDRA_LANGUAGE_ID="ARM:LE:32:Cortex" \
rea-agent rea analyze /targets/blob.bin --provider ghidra --json
rea providers --json and the Ghidra adapter record the effective language and
compiler spec in the analysis profile, and REA fails the session when the
committed profile and the setting disagree - so a mis-pinned language is
reported instead of silently producing wrong pseudocode.
Run a MIPS binary to observe its behaviour
docker compose exec rea-agent bash
$ qemu-mips-static -L /usr/mips-linux-gnu /targets/daemon &
$ rea capture-process ./scenario.json --json # runtime evidence; frida instrumentation
# (list-frida-devices, instrument-with-frida)
# ships with REA 6.5.0
$ gdb-multiarch /targets/daemon -ex 'set sysroot /usr/mips-linux-gnu' ...
For pure static analysis of the same file, nothing extra is needed:
rea decompile /targets/daemon main --provider ghidra --json.
Run a Windows PE
docker compose exec rea-agent bash
$ wine /targets/app.exe
$ rea capture-process ./scenario.json --json # with executable: "wine"
Cross-build a fixture to compare against a vendor binary
aarch64-linux-gnu-gcc -O2 -o /work/fixture-aarch64 /work/fixture.c
mips-linux-gnu-gcc -O2 -static -o /work/fixture-mips /work/fixture.c
The verification harness does exactly this: on the images that carry Ghidra it
analyses x86-64, aarch64, armv7, MIPS32 BE, MIPS32 LE, RISC-V64, PowerPC and a
Windows PE32+ through Ghidra on every run (scripts/verify.sh --only analysis),
and skips the rest with a reason on the other images.
Limits worth knowing
qemu-user-staticdoes not cover every architecture (no PowerPC64LE SPE, no exotic DSPs). Static analysis still works - only execution is limited.winewill not run 16-bit or driver-level Windows code.- REA's dynamic families are Linux-only by design (process capture, packet and
signal decoding use
prlimit); this is a Linux image, so they are available. - Kernel modules, hypervisor-protected code and hardware-backed DRM remain outside any static tool's reach - REA reports unknowns rather than guessing.