ASISARCH — asisctf2026

Description

No separate organizer description was preserved in the local task files.

The challenge ships two artifacts: challenge.rom and qemu-asisarch. The goal is to understand the custom architecture well enough to recover the scoreboard-valid flag, not just any locally accepted collision.

Analysis

Recon and ROM format

The task title already suggests a custom architecture challenge, and the provided emulator confirms it. The important starting point was the ROM loader inside qemu-asisarch.

The emulator main validates the ROM header before execution:

• magic: AARQ
• version: 0x02
• maximum payload size: 0x10000
• checksum: custom checksum over rom[0x20:] seeded with 0x31415926

That immediately shows this is not a normal firmware blob for a known CPU. The ROM payload is copied into a 64 KiB guest memory region and execution begins at guest PC 0x0000.

VM state layout

The recovered machine state layout was:

• 64 KiB guest memory
• 8 general 16-bit registers
• stack pointer at 0x10010
• program counter at 0x10012
• cycle counter at 0x10018
• initial entry PC 0x0000

So the architecture is a compact 16-bit VM implemented inside a stripped x86-64 QEMU binary.

Instruction decryption and dispatch

Instructions are stored in encrypted 4-byte form. The emulator decrypts and dispatches them with three key tables:

• byte permutation table at .rodata+0x140 / VA 0x2140
• 256-byte S-box at .rodata+0x160 / VA 0x2160
• sparse 256-entry opcode jump table in .data.rel.ro

The permutation rows are:

[0,1,2,3]
[2,0,3,1]
[3,2,1,0]
[1,3,0,2]

Recovering the decode path was enough to rebuild the ISA used by the ROM.

Recovered ISA

From the emulator and ROM disassembly, the useful instructions were:

...