Decompiling an arm64 macOS binary on x86_64 Linux with REA + Ghidra (no-sudo Ubuntu setup)

[mhamzasakhi]

I set up REA on Ubuntu 24.04 (x86_64) with Ghidra as the native engine, entirely in my home directory without sudo. Here is what worked, what tripped me up, and one result I found interesting: decompiling a real arm64 macOS binary on an x86_64 Linux machine.

Setup (no sudo)

Node.js. My system Node was 20, which REA does not support (it needs 22.19+, 24.11+ or 26+). I used nvm:

nvm install 24.18.0

Ghidra 12.1.4 and JDK 21. I extracted both under ~/.local/tools, after checking their published SHA-256 sums:

• Ghidra: the official GitHub release
• JDK: Temurin 21

export GHIDRA_INSTALL_DIR=$HOME/.local/tools/ghidra_12.1.4_PUBLIC
export JAVA_HOME=$HOME/.local/tools/jdk-21.0.12.1+1
rea doctor   # all ghidra-* checks report healthy

The Linux process checks also need a procps-compatible ps. Ubuntu already includes it (procps-ng 4.0.4).

Optional launcher. I added a tiny launcher at ~/.local/bin/rea. It sets those two variables and runs REA with Node 24, so my default Node can stay on 20 for other projects:

#!/usr/bin/env bash
export GHIDRA_INSTALL_DIR="${GHIDRA_INSTALL_DIR:-$HOME/.local/tools/ghidra_12.1.4_PUBLIC}"
export JAVA_HOME="${JAVA_HOME:-$HOME/.local/tools/jdk-21.0.12.1+1}"
exec "$HOME/.nvm/versions/node/v24.18.0/bin/node" /path/to/rea/scripts/rea.mjs "$@"

Gotcha when building from a source checkout. After npm ci, Turborepo's Linux binary was missing ("We did not find any binaries on this system"). Installing the locked platform package without saving fixed it:

npm install --no-save @turbo/linux-64@<turbo version from package.json>

First results

rea decompile /usr/bin/true entry --provider ghidra returned the __libc_start_main entry stub in about 10 s.

rea analyze-javascript-application <dir> --json worked with no native engine at all.

Decompiling an arm64 macOS binary on x86_64 Linux

I cross-compiled the repository's C fixture with zig cc into a real arm64 Mach-O, then wrapped it in a one-slice universal (FAT) container:

zig cc -target aarch64-macos -O0 tests/conformance/c/fixture.c -o thin-arm64

Results:

• Thin arm64 file: admitted.
• Universal container: rejected on current main with target_unavailable: FAT binary has no host-compatible x64 architecture. This is [Bug] list-architectures rejects universal Mach-O files without a host-compatible slice #5404.
• With the fix in fix(native): admit universal Mach-O files without a host slice #5501: rea decompile <universal> _main --provider ghidra returns real pseudo-code from the arm64 slice:

bool entry(void)
{
  int iVar1;
  iVar1 = _rea_entry();
  return iVar1 != 0xc;
}

So static analysis of foreign-architecture Apple binaries works fine from a Linux box, once the container admission no longer requires a host slice.

Contributions from this

• fix(apple): classify keyed-archive objects by declared superclasses #5228: Interface Builder keyed archives now classify UIKit and AppKit objects by their declared superclasses. UINavigationController and similar classes were reported as controls ([Bug] UIKit view-controller subclasses decode as controls #5218).
• fix(native): admit universal Mach-O files without a host slice #5501: universal Mach-O files without a host slice are admitted ([Bug] list-architectures rejects universal Mach-O files without a host-compatible slice #5404).

Happy to answer questions about the Linux setup.