Architectures and platforms

A vendor firmware image for a Zyxel VMG8825-T50K VDSL2 gateway is a 26 MiB zip. Inside it is a proprietary "2RDH" container, inside that a compressed kernel and a SquashFS root filesystem, and unpacking the lot yields 1,683 files. 538 of them are ELF executables, and every one looks like this:

$ xxd -l 32 bin/busybox
00000000: 7f45 4c46 0102 0100 0000 0000 0000 0000  .ELF............
00000010: 0002 0008 0000 0001 0040 3250 0000 0034  .........@2P...4
          ^^^^ ^^^^           ^^^^^^^^^
          |    e_machine 8    e_entry = 0x00403250
          e_type = 2 (EXEC)   (EM_MIPS)

Byte 5 is 02: big-endian. Byte 4 is 01: 32-bit. file adds "no section header" — the link view was stripped. Nothing in this file is x86, nothing is little-endian, and nothing about it resembles the desktop binaries most tooling is written for. 537 of the 538 are in the fixture corpus, and all 537 decode clean: 9,963,208 instructions across the image, zero unknown opcodes.

The 538th, bin/cfg, is a 53,804-byte MIPS32 big-endian executable that never reaches a decoder. The corpus harvester filters by file extension before it looks at the magic, and takes the last dot-separated component of a name as that extension — for a file with no dot, the whole name. cfg is on its non-binary list, alongside sh, conf, key, out, py, js, lua, ini and md, so bin/cfg and bin/sh — the canonical extensionless binary in any firmware rootfs — are discarded as config files. That absence is a measurement bug, not a decoder limit.

That is the job. A binary announces a format and a machine type, and every analysis downstream — disassembly, control flow, taint, syscall naming, calling convention, argument recovery — is built on getting those two fields right and then having a decoder that actually covers the instruction set behind them.

Format and architecture misrouting

Format and architecture resolution fails quietly: a wrong answer does not throw, it produces plausible garbage.

Routing on bitness. PE routing was once decided on bitness, so every 64-bit PE went through the x86_64 lifter — including ARM64 PEs, which produced a full, confident, entirely fictional call graph. The fix routes on the COFF machine field and returns nothing for machines the pipeline does not fully support, so an unsupported PE yields an honest empty call graph instead of x86-misdecoded output. Honest-empty versus plausible-wrong is the distinction every per-architecture gate exists to enforce.

ARM64X hybrid images. A hybrid ARM64X PE carries ARM64 code and x64 code in one image, described by an IMAGE_ARM64EC_METADATA code map, so there is no single answer to "what architecture is this file" — the same problem made structural. The lifter builds a per-range plan, unions the ARM64 exception directory with the x64 ExtraRFETable, and selects a decoder per address. This is proven against a hand-built hybrid PE only — no real ARM64X binary is in the corpus.

Compile-time format sets. Format and architecture support is a compile-time set, not a runtime one, so a format omitted from a build turns into a refusal at analysis time rather than a link error — the one failure mode that does not even involve a binary. A fleet worker built without the PE option compiled cleanly, passed every lint, and then answered every PE with "the pe Cargo feature is disabled" and every ELF with the equivalent — analysing Mach-O and nothing else. Nothing observable went wrong until something was fed to it. The guard that now exists cannot be a compile-time assertion for the same reason: it executes the built binary once per format, because asking whether a build requested a feature is a different question from whether the thing it runs can read the file.

What a stock build actually contains. Every layer below is a compile-time set except identification, which is never gated.

A binary for an omitted architecture gets a refusal, not a misdecode, and a stock build can name a .dex it cannot open.

Executable formats

58 formats are recognized as loadable images. Six carry a manifest deep enough to describe the structure rather than sample it; 20 more carry a smaller one, several of them bundled so that a single manifest covers a whole console or retro family; the rest are recognized by magic and header validation with no item list behind them. Three have been walked over real binaries — ELF across 584, Mach-O across 9, WASM across 1; the other three are checked against their published specification only. Deprecated items stay in the counts.

Having a manifest is not the same as matching it. Four format targets fall short:

Mach-O is the one to distrust. Lower rates exist among the architecture targets — mcs96, spc700 and w65c816 sit at 0% — but its 193 unmatched items are the largest count anywhere, a quarter of the 789 unmatched across all 104 targets. They cluster:

The figure is a name-match, so it cannot separate an unwired arm from a name spelled differently on the two sides; entitlements and the code-signature SuperBlob read 100% and are demonstrably parsed, while the relocation tables a linked Mach-O never carries read zero. The export trie has no such excuse: it is how a modern Mach-O enumerates what it exports, and none of its 8 flags matches.

Beyond those six, the router recognizes:

Three cases sit across the boundary between a format and an instruction set:

• Recognized as images and lifted as ISAs — Lua luac, Python pyc, Java class files.
• Never a top-level format — CIL rides inside a PE, EBC inside a PE or TE.
• Split before analysis — Mach-O universal binaries are sliced, and each slice is a separate image.

Architectures

72 instruction sets are claimed, in exactly three tiers: 39 lifted, 9 bytecode VMs that also reach IL, and 24 decode-only. A test reads the specification registry and asserts every architecture in it appears in exactly one tier, failing on either an architecture with no tier or a tier naming an architecture with no specification — so a new architecture cannot land unmeasured and the gap list cannot go stale.

Lifted architectures (39) — full IL analysis

A lifted architecture reaches intermediate language, so taint, CWE detectors, the interval domain, call-graph construction and argument recovery all run on it. Manifest items are decoder breadth — for most architectures that is opcodes; for m68k it also counts addressing modes.

Two further properties — that arithmetic lifts at the right operand width, and that the syscall instruction reaches the intrinsic the resolver reads — are asserted per-architecture for only eight of the 39:

Every lifted architecture has a textual disassembler. x86, x86_64, arm64 and arm64e use an edge decoder (iced for the x86 family, bad64 for arm64); the other 35 use a hand-rolled renderer.

Bytecode VMs (9) — decode plus IL

All nine emit real IL, so the standard analyses consume them like native code.

The DEX loader is one of the eight that a stock build leaves out, so a stock analyzer never opens a .dex at all — the Dalvik lifter and its bridge are present, but nothing routes a file to them.

The Dalvik path shows why the container matters as much as the ISA: the register-VM lifter has no DEX context, so an invoke lifts to the opaque token dalvik.method#N and a const-string to dalvik.const_string#N. Every name-keyed detector matches on resolved symbols, so those tokens are invisible to all of them. A separate bridge parses the DEX, walks each class to its method bodies, and rewrites resolvable tokens to their smali names — Ljava/lang/Runtime;->exec(...) — which is what makes the command-execution sink fire. An index that does not resolve, because it is out of range or the app is multidex, keeps its raw token rather than being guessed at.

Decode-only architectures (24) — no IL

These 24 are recognized and disassembled, and nothing else. No taint, no CWE detection, no value-range reasoning, no call graph. Promoting one means writing a lifter.

Five of those numbers are aspiration rather than decoder breadth. For these five, "disassembled" describes an intent, not an output:

Decode results on real binaries

14 of the 104 coverage targets are exercised against fixture binaries; the other 90 have never had a real file fed through them. Fixture counts are not comparable across rows either: the eBPF row is five programs totalling 67 instructions, which is enough to prove the decoder runs and nothing more, and six further rows rest on three fixtures or fewer.

Two architectures are not clean, and the ELF row's 1,845 unknowns are exactly those two summed — 1,755 ARM32 plus 90 RISC-V. Every other architecture in the 584-binary ELF walk decodes completely.

ARM32 is the larger: a glibc-dynamic ARM32 fixture reports 903 unknown slots in 129,878 instructions (0.695%), and the report names the offenders — 764 unnamed, plus 102 b, 31 ldr pc, 6 bx. Branches and PC-relative loads appearing in that list is the ARM/Thumb interworking frontier: the ARM decoder targets the integer core that firmware is built from, and NEON, VFP, coprocessor and Thumb-IT encodings fall back to a raw word rather than a mnemonic.

RISC-V's 90 unknowns across 5 fixtures are a different shape, and a less legible one: they come back as bare riscv.unknown with no mnemonic attached, so unlike ARM32 the report cannot name what failed.

The last row clears the 1%-or-50-unknowns threshold that flags a fixture for investigation, and is a denominator artefact rather than a decoder signal. The manifest is no help in locating any of them either: it is complete against the dispatch source, yet 25 bit-manipulation instructions (rev8, bexti, orc.b, the sh1add.uw family, rori and friends) are dispatched without appearing in it at all, so specification and code have drifted in opposite directions on the same architecture.

537 of the 541 MIPS fixtures are the Zyxel router binaries from the opening; the four remaining are cross-compiled fixtures covering both endiannesses. That one firmware image contributes 9,963,208 of the row's 10,198,938 instructions — more than any other architecture target's whole fixture set, and second overall only to the 584-binary ELF format walk, which contains those same 537 files.

Decoder validation

Decoders are checked three ways: replayed golden vectors from rizin and radare2, a capability matrix driven through the production lift seam, and name inventories cross-referenced against rizin and Ghidra. Across all 104 targets, 12,977 of 13,766 manifest items have a dispatch arm — 94.3%.

Golden vectors

Twelve architectures — sparc, xtensa, avr, h8300, h8500, msp430, superh, v850, z80, tricore, nds32, m68k — replay rizin's assembly corpus, and loongarch replays radare2's ESIL corpus. Each vector is an assembly string and its encoding:

d "movea 0xff, r0, r20"  20a6ff00
d "mov 0xffff, r21"      3506ffff0000
d "mov 0x200000, sp"     230600002000

Two things are asserted per vector: the instruction decodes, and the summed per-instruction lengths equal the hex payload length. Length is the paramount axis — a decoder that gets a mnemonic wrong produces one bad row, but a decoder that gets a length wrong desynchronises the stream and corrupts every basic block after it.

Coverage of the corpus is uneven against the manifest in both directions: h8500 replays golden vectors while only 7 of its 84 manifest items have a dispatch arm, so a green h8500 run says the implemented tenth is right, not that the architecture is covered.

The capability matrix

One table-driven test drives the real production lift seam per architecture and asserts seven properties per chipset. Rows left unset are recorded as unmeasured, never as passing.

A set row is not the same as an executed one: the 25 embedded-ISA lift probes and 23 embedded interval probes compile out unless the build names that architecture, and none of those features is in the lifter crate's own default set, so testing that crate alone runs none of them.

The rendered matrix is a hand-maintained copy of these tables rather than a projection of them, and twelve of its ticks have no asserting row behind them: interval for MSP430, Hexagon, s390x, LoongArch, C166 and V810, and argument recovery for arm64e, eBPF, C166, V810, LM32 and OpenRISC 1000.

Each column exists because it caught something:

• Width caught a 32-bit i386 operation modelled as 64-bit and hidden behind a plausible CFG.
• Syscall caught i386's int 0x80 and RISC-V's ecall decoding as unknown, which made both architectures blind to their entire syscall surface.
• Interval caught MIPS reading $zero as an opaque variable, which left every $zero-derived value at Top and silently disabled value-range analysis for MIPS's canonical constant load.

Cross-tool inventories

Filenames under vendors/rizin/librz/{arch,bin}/p/ and vendors/ghidra/Ghidra/Processors/ are cross-referenced against the manifest names, and one entry in 157 is unshared.

The single Ghidra-only entry is its 68000 tree — m68k is covered, under that name, with a 162-item opcode dimension at full dispatch, but the parity map is keyed on directory name and does not alias the two. The real m68k gap is elsewhere: 2 of 12 addressing modes, IdxAn and IdxPc, are in the manifest with no dispatch arm, so index-register and PC-indexed operands are the frontier.

Calling conventions

48 conventions, selected automatically from the pair (architecture, image format), not from architecture alone. The same x86_64 instruction stream is SysV on ELF and Mach-O and MS_X64 on PE: different argument registers, and 32 bytes of caller-reserved shadow space on Windows against zero on the others. Getting this wrong recovers the wrong arguments for every call in the binary rather than failing outright.

The format half of the pair only bites where more than one convention is reachable. 32-bit x86 resolves to MsX86Stdcall on every format, ELF and Mach-O included, so the other three MS x86 conventions below are never the automatic answer — they are names an analyst or an annotation can select, not routing outcomes.

Every register-argument convention the gate names must declare its integer parameter registers, so an architecture that would silently recover zero arguments fails per-chipset. Stack-argument ABIs — 32-bit x86, m68k — are exempt by construction. The gate is 35 (architecture, format) rows and does not reach the whole table: the six architectures missing an argument-recovery row are named under the capability matrix, and the Swift, Go, BPF-helper and seccomp ABIs are asserted for no architecture at all.

Platforms and syscall tables

A syscall is a number in a register, and the number means nothing without knowing which table to read. Five platform families carry tables here — Linux, Apple, Windows, BSD and Solaris/illumos. Number 59:

x86_64   59 = execve          arm64    59 = pipe2
sparc    59 = execve          ppc      59 = oldolduname
x86_32   59 = olduname        arm32    59 = unassigned

And execve itself is 59 on x86_64 and SPARC, 11 on x86_32, ARM32, PowerPC and s390x, 221 on arm64, 4011 on MIPS o32, and 5057 on MIPS n64. Resolving a direct syscall requires the architecture before it requires the operating system.

Behavioural output uses one 12-term vocabulary across all three platforms — FileIo, Network, ProcessControl, Ipc, Memory, Crypto, Time, Signals, Threading, DynamicCode, SystemInfo, Hardware — so an ELF profile and a PE profile can be compared directly rather than each speaking its own dialect.

Linux

9 tables, 3,619 entries.

Above the syscall layer sit 10 capability domains — Network, Process, Filesystem, Memory, IPC, Crypto, DynamicCode, Time, SystemInfo, Threading — and 57 library families, which is how a statically linked binary with no imports still gets a behavioural reading:

Apple

457 BSD syscalls and 62 Mach traps. Above them sit 1,053 framework and runtime symbols across 52 dimensions — the coverage report's 1,209-across-54 figure counts the same two syscall surfaces again as dimensions of its own, at 101 and 55 entries.

1,105 of the 1,209 are dispatched, and all 104 shortfalls are in three of the framework and runtime dimensions:

Apple hardening posture is thinner than the framework inventory suggests: 3 of 14 keys have a reader, against 9 of 9 each for Linux and Windows. Nothing dispatches PIE, non-executable heap, RWX segments, stack canaries, FORTIFY, pointer authentication, __DATA_CONST, ad-hoc signing, hardened runtime, library validation or FairPlay encryption. This is the same name-match measurement that reads Mach-O relocations as zero, so some may be read under another name — but it is the weakest measured surface on the platform.

Windows

142 NT SSDT entries and 21 win32k.sys entries in the modern table, plus separate Win7-era tables, because the Vista/7/Server 2008 numbering is a different map, not an older prefix of the same one.

On top of those, 57 syscalls carry per-release numbers across six builds. Most are stable, but the ones that move are exactly the ones worth watching:

                          win10   win10   win11   win11   win11   win11
                          1809    22H2    21H2    22H2    23H2    24H2
NtCreateThreadEx          0x00BC  0x00C2  0x00C6  0x00C7  0x00C7  0x00C9
NtCreateUserProcess       0x00C3  0x00C9  0x00CE  0x00CF  0x00CF  0x00D1
NtSuspendProcess          0x01B4  0x01BD  0x01C7  0x01CB  0x01CB  0x01CE
NtSystemDebugControl      0x01B6  0x01BF  0x01C9  0x01CD  0x01CD  0x01D0
NtWriteVirtualMemory      0x003A  0x003A  0x003A  0x003A  0x003A  0x003A

A direct-syscall stub that loads 0xC9 into eax is calling NtCreateThreadEx on Windows 11 24H2 and NtCreateUserProcess on Windows 10 22H2. Low numbers like NtWriteVirtualMemory at 0x3A have not moved across any of the six, which is why the shifting high numbers are where the ambiguity lives.

The stub walk that feeds those tables runs on x86_64 PEs only: an ARM64 or 32-bit PE returns before it starts, so a direct-syscall stub there resolves to nothing rather than to a wrong name.

Which of the six a sample targets is the part a PE cannot answer. Both available signals collapse: any MajorOperatingSystemVersion of 6 or higher resolves to a single baseline, because the MSVC linker default is sticky and 2024-built binaries still declare (10, 0); and the manifest supportedOS GUID {8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a} covers Windows 10 and 11 together, since the schema never split them. So 0xC9 resolves to one name, not two candidates, and the version field is a floor rather than a target.

The rest of the Windows surface:

BSD family

4 tables, 1,423 entries.

Family-specific surfaces matter more than the totals: OpenBSD's pledge and unveil declare a process's own restrictions, and FreeBSD's Capsicum cap_* and jail-control calls do the same.

Solaris and illumos

246 entries, bridged one-to-one into the Linux capability taxonomy. What justifies a separate table are the illumos primitives with no Linux equivalent — door, port, zone, pset, modctl, processor_bind and processor_info. Their userspace wrappers (door_call, port_create, zone_create, pset_bind and siblings) are not in the syscall table; they resolve through the library-symbol catalog, which is what a dynamically linked Solaris binary actually references.

libc flavour

libc flavour is read from the ELF PT_INTERP path, falling back to the DT_NEEDED soname for shared objects, which have no PT_INTERP.

The uClibc row is the weak one: the Zyxel binaries from the opening name /lib/ld-uClibc.so.0 as their interpreter and return unknown, even though the library-identification layer recognizes uClibc by soname and by the __uClibc_main symbol. Embedded Linux is the case this classifier is weakest on, and it supplies 537 of the 584 binaries in the ELF corpus walk.

Containers and unpackers

The identify authority carries 170 format identities, 161 of them backed by a signature-validated magic, and 110 route to a working extractor.

Most of the 60 that do not extract are categories with nothing to descend into.

The four crypto rows that do carve — PEM certificates, private keys, public keys, and OpenSSL blobs — extract because there is an encoded payload to pull out.

Six containers are identified and not extracted. In every case the reason is the same: no extractor has been written, not that the container defeats extraction.

Four compression formats are deliberately excluded from automatic routing — compress (.Z), raw zlib, raw LZMA1 and raw xz streams. Their magics are short enough that scanning for them across a firmware image produces more false positives than payloads: raw LZMA1's "magic" is its one-byte properties value, which matches roughly 24% of random bytes. All four extract by name only, from carrier-aware paths that already know what they are looking at. A stripped-OOB YAFFS2 image takes the same posture for the opposite reason — it cannot reach header-valid confidence, so it is never auto-promoted.

The extractor catalog:

DMG, the dyld cache, MH_FILESET kernel collections and Mach-O universal binaries bypass magic scanning entirely and go to dedicated loaders. UPX is a format-aware static unpacker that reconstructs the original Mach-O, ELF or PE image rather than stripping a header. The recursion mechanics, budgets, and the packed-payload verdict handoff are in Unpacking.

Measured against vendored binwalk (111 formats identified, 72 extracted), every extraction difference runs the same way:

Limits

90 of the 104 coverage targets have no fixture binary at all. For those, the only claim on record is that the manifest and the dispatch source agree — no real file has ever been fed through them. That agreement is not uniform either: 12,977 of 13,766 items overall, but v850 sits at 86 of 111 with its whole load/store group unmatched, and Mach-O — a target that does have fixtures — at 439 of 632.

The measurement is a name-match between specification and dispatch source, so it drifts in both directions and neither direction is proof. RISC-V dispatches 25 bit-manipulation instructions that appear in no manifest. PA-RISC is the clearest case of the drift running the other way: it reports its integer ALU, logical, address-formation and load/store entries as undispatched — only 8 of its 37 items match — while the real Debian-hppa echo and true from coreutils 9.10-1 decode 5,796 and 5,300 four-byte text slots with 419 and 417 unknown (7.2% and 7.9%), both producing a terminated CFG with a call edge. The remaining unknowns there are floating-point, coprocessor, system and privileged operations, which are out of scope by design; the ceiling that would fail the run is 15%, and deleting the integer decode arms pushes the rate to about 19%.

Reference

• Linux syscall tables — the syscall*.tbl files each architecture ships, and the asm-generic unistd.h that newer ports share.
• rizin — librz/arch/p/ and librz/bin/p/, and the test/db/asm/ golden-vector corpus replayed here.
• Ghidra Processors — SLEIGH specifications, the widest published set of processor definitions.
• ARM64EC and ARM64X — Microsoft's description of the hybrid PE layout.
• binwalk — the firmware-carving baseline: 111 formats identified, 72 with an internal extractor.