The pool allocator, command-line interface (CLI) dispatch tables, rule state changes, scheduler code, and six-phase init sequence are all visible. Reading them together exposes a resource mismatch: the default partition configuration asks for more rule slots than a pool can provide. If partition binding reaches those allocations, the code records an error and continues in degraded mode. That is more useful than accepting a boot complete marker at face value.

Follow along: Use the same firmware.bin from the sample bundle, and run the examples from more_complex_firmware/. Instruction addresses refer to that binary. The boot outcome below follows from its code and configuration; it is not a captured device boot.

The Pool Allocator: Sentinel Values and Three Modes

Finding the Sentinels

Some of the most revealing values in firmware aren’t in .rodata tables – they’re magic constants embedded directly in code. Search the bundled binary’s executable ranges for lui instructions that load 0xDEAD:

from capstone import Cs, CS_ARCH_MIPS, CS_MODE_MIPS32, CS_MODE_LITTLE_ENDIAN

data = open("firmware.bin", "rb").read()
md = Cs(CS_ARCH_MIPS, CS_MODE_MIPS32 | CS_MODE_LITTLE_ENDIAN)
for start, end in [(0x0000, 0x02AC), (0x02B0, 0x7290)]:
    for insn in md.disasm(data[start:end], 0x80000000 + start):
        if insn.mnemonic == "lui" and insn.op_str.endswith(", 0xdead"):
            print(f"{insn.address:08x}:  {insn.mnemonic} {insn.op_str.replace('$', '')}")

80001990:  lui t0, 0xdead
800019d0:  lui v1, 0xdead
80001a50:  lui t0, 0xdead
80001b00:  lui t0, 0xdead
80001b58:  lui t4, 0xdead
80001b98:  lui v1, 0xdead
80001c58:  lui v0, 0xdead
80001cc8:  lui v0, 0xdead
80001cd8:  lui v0, 0xdead
80002068:  lui v1, 0xdead
80002078:  lui v1, 0xdead

The upper-half loads alone do not establish the full values. Follow the surrounding instructions to find 0xDEAD0000 and 0xDEAD0002. These are sentinel values – special markers that the allocator writes to memory slots to track their state. The following instruction excerpts retain their binary addresses; gaps omit unrelated instructions.

# In pool_alloc (windowed mode):
80001b58:  lui   t4, 0xdead          # t4 = 0xDEAD0000 (FREE marker)
  ...
80001b74:  lw    t0, 0x1c(a1)        # Load slot marker
80001b78:  beq   t0, t4, 0x80001b98  # if (slot == DEAD0000) → slot is free
  ...
80001b98:  lui   v1, 0xdead
80001b9c:  addiu v1, v1, 2           # v1 = 0xDEAD0002 (USED marker)
80001ba0:  sw    v1, 0x1c(a1)        # Mark slot as USED

The allocator checks if a slot contains 0xDEAD0000 (free), and if so, overwrites it with 0xDEAD0002 (used). In pool_init, a delay-slot addition constructs a third value:

80001b00:  lui   t0, 0xdead
80001b04:  b     0x80001ab4
80001b08:  addiu t0, t0, 1           # delay slot: 0xDEAD0001

Following the initialization stores and allocation checks gives us:

0xDEAD0000 = FREE     (slot available for allocation)
0xDEAD0001 = BOUNDARY (window boundary, skip during scan)
0xDEAD0002 = USED     (slot currently allocated)

These three sentinel values, together with the indexing code, reveal a windowed structure. Initialization places a boundary marker in the last slot of each window. The compiled allocation loop accepts only FREE markers, so it skips boundaries without a separate comparison against 0xDEAD0001.

The Three-Mode Dispatch

The function at 0x80001B14 (pool_alloc) starts with a mode check:

80001b14:  beqz  a0, 0x80001c98      # NULL check
80001b18:  nop
  ...
80001b24:  lw    t3, 4(a0)           # t3 = pool->mode
80001b28:  addiu v0, zero, 1
80001b2c:  beq   t3, v0, 0x80001c2c  # mode 1: linear scan
80001b30:  addiu v0, zero, 2         # delay slot: prepare next comparison
80001b34:  beq   t3, v0, 0x80001c48  # mode 2: prefer slot zero
80001b38:  nop
80001b3c:  bnez  t3, 0x80001ca0      # unknown mode: error
80001b40:  nop
           # Fall through: mode 0 = windowed scan

Three modes, selected by a field at offset +0x04 in the pool struct:

The three system pools select these modes: AR uses windowed, ID uses linear, and AT uses copy. The copy branch prefers slot zero whenever the cursor is zero and that slot is free; otherwise it uses the linear scan. No rule or 64-bit value is copied by this branch.

Reconstructing the Pool Struct

From the allocator code, we can recover the pool data structure:

typedef struct {
    const char *name;           /* +0x00 */
    uint32_t    mode;           /* +0x04: 0=windowed, 1=linear, 2=copy */
    uint32_t    num_windows;    /* +0x08 */
    uint32_t    total_slots;    /* +0x0C */
    uint32_t    used_count;     /* +0x10 */
    uint32_t    cursor;         /* +0x14: encoded [7:3]=window, [2:0]=slot */
    uint32_t    alloc_fails;    /* +0x18: failed allocations */
    uint32_t    slots[32];      /* +0x1C: sentinel-tagged slot array */
} pool_t;

In windowed mode, the cursor at +0x14 packs the window index into bits [7:3] and the slot index into bits [2:0]. The AR pool spans eight four-slot windows, but the last slot of each window is a boundary marker: 24 allocatable slots, not 32. Linear and copy modes each initialize one four-slot window, so their pools have four allocatable slots each. The 32-element array is storage capacity, not the active size of every pool.

The companion source makes a useful cross-check here. Its ID and AT initialization comments say “32 slots,” but each call initializes one window, and POOL_WINDOW_SIZE is four. The compiled initialization and allocation bounds agree on four. Even with source available, a comment can lose an argument with the instructions.

The CLI Dispatch: Two Command Tables

Finding the Tables

Function pointer tables are RE gold – they map directly to the firmware’s command structure. In our firmware, cli_process starts at 0x8000541C and contains the dispatch logic. Its public-command string comparison loop loads the table base as follows:

# Load table base
8000559c:  lui   s0, 0x8000
800055a0:  addiu s0, s0, 0x78c0      # 0x800078C0 = public_cmds table

At address 0x800078C0, we find an array of 12-byte entries:

$ python3 -c "
import struct
data = open('firmware.bin', 'rb').read()
BASE = 0x80000000
offset = 0x78C0  # public_cmds
for i in range(15):
    name_ptr = struct.unpack('<I', data[offset:offset+4])[0]
    handler  = struct.unpack('<I', data[offset+8:offset+12])[0]
    # Read string at name_ptr
    soff = name_ptr - BASE
    name = ''
    while data[soff] != 0: name += chr(data[soff]); soff += 1
    print(f'  [{i:2d}] \"{name}\"  -> 0x{handler:08X}')
    offset += 12
"

  [ 0] "help"       -> 0x80004BF4
  [ 1] "version"    -> 0x80004BC8
  [ 2] "uptime"     -> 0x8000538C
  [ 3] "status"     -> 0x8000522C
  [ 4] "portdump"   -> 0x80005370
  [ 5] "routedump"  -> 0x80005354
  [ 6] "ruledump"   -> 0x80005104
  [ 7] "pooldump"   -> 0x80005144
  [ 8] "taskdump"   -> 0x80005338
  [ 9] "eventdump"  -> 0x8000531C
  [10] "dmadump"    -> 0x80005300
  [11] "partdump"   -> 0x800052E4
  [12] "timer"      -> 0x800052C8
  [13] "reset"      -> 0x80004BA0
  [14] "log"        -> 0x800051F0

15 public commands. But the dispatch function searches two tables. After the public table check fails, it searches a second table at 0x80007860:

  [0] "$dbglvl"    -> 0x80005194
  [1] "$peek"      -> 0x80004DC8
  [2] "$poke"      -> 0x80004D34
  [3] "$flashid"   -> 0x80004CFC
  [4] "$crashme"   -> 0x80005160
  [5] "$rulestat"  -> 0x80005120
  [6] "$wdgtest"   -> 0x80004B74
  [7] "$crctest"   -> 0x80004E44

Eight hidden commands prefixed with $. In production firmware, hidden debug commands like these are security-relevant – $peek and $poke provide arbitrary memory read/write, $crashme triggers a fatal assert, and $wdgtest shortens the watchdog timeout. The last command returns to the main loop, which continues kicking the watchdog, so the code alone does not establish a reset.

The entries in these two tables use {string_pointer, help_pointer, handler_pointer}. Once we find one table, checking nearby data for another is worth the effort; the entry layout itself depends on the firmware.

The Boot Chain: Six Phases With Error Codes

The Phase Dispatch Table

The firmware_main function at 0x80000540 walks a six-entry function pointer table at file offset 0x7290 (address 0x80007290). The binary stores each handler address as a little-endian word. We can read those words directly:

import struct
data = open('firmware.bin', 'rb').read()
for i in range(6):
    addr = struct.unpack('<I', data[0x7290+i*4:0x7290+i*4+4])[0]
    print(f"Phase {i}: handler at 0x{addr:08X}")

Phase 0: handler at 0x800003BC  # Hardware init
Phase 1: handler at 0x800004BC  # Driver init
Phase 2: handler at 0x8000045C  # Core services
Phase 3: handler at 0x8000042C  # Rule engine
Phase 4: handler at 0x80000324  # Partition binding
Phase 5: handler at 0x800002B0  # Runtime start

The labels come from inspecting each handler; the pointer table itself contains only addresses. Phases 0–2 halt on an error. Phases 3–5 record the error and continue in degraded mode. That difference matters here.

Phase 4 allocates per-partition rule budgets. The pre-check compares requests with rule-table limits: 32 AR, 48 ID, and 24 AT entries. It passes. But the allocator’s active pools are smaller: 24 usable AR slots, four ID slots, and four AT slots. The first partition asks for 12 ID rules. If port binding succeeds, its fifth ID allocation must fail, so phase 4 returns INIT_ERR_RESOURCE (0x0D). The firmware records the failure and still runs phase 5. This is a conclusion from the code path, not a captured boot log.

The Boot Status Marker

Phase 5 writes the boot marker regardless of the earlier phase-4 error:

800002f8:  lui   v0, 0xb803          # System Control base
800002fc:  ori   v1, zero, 0xbeef    # boot complete marker
80000300:  sw    v1, 0x14(v0)        # Write to BOOT_STATUS register

The value 0xBEEF signals that execution reached the runtime-start phase. It does not prove that partition binding succeeded. The phase-4 return code and scratch error register are needed to tell those outcomes apart.

The Rule Engine: Validate, Log, Activate

State Machine

The rule_commit function at 0x8000330C has three stages, but calling it an atomic hardware commit would give it credit it has not earned. From the bitfield analysis in Part 2, the state field lives in bits [15:8] of the flags word:

State transitions:
  FREE (0x00) → ALLOCATED (0x01) → PROGRAMMED (0x02) → COMMITTED (0x03)

The commit function performs:
  1. Validate: require PROGRAMMED state, a valid match range, and nonzero action
  2. Log a would-be hardware shadow write
  3. Lock, mark the entry COMMITTED, unlock, and post EVT_RULE_CHANGE

In C-like reconstruction:

if (!rule_validate(table, index))
    return -1;
rule_write_hw(table, index);         /* logs; no MMIO write in this sample */
rtos_mutex_lock(&table->commit_lock);
rule_activate(table, index);         /* sets state to COMMITTED */
rtos_mutex_unlock(&table->commit_lock);
event_post(EVT_RULE_CHANGE, (type << 16) | index);

The lock/unlock calls surround the state change, but the would-be hardware write happens before them and the event is posted afterward. The return from rtos_mutex_lock is ignored, although that function can return -1 without acquiring the mutex. Even the state change therefore needs a contention check before we claim mutual exclusion. There is no real hardware write in this sample: rule_write_hw only logs a message. These bytes show a state transition and notification, not an atomic update of a device table.

Validation Failure

If validation fails, rule_commit logs an error and returns -1 before the simulated write and state change. The entry remains in its previous state. No rollback operation runs.

Scheduler Code Without Task Switching

The Scheduler Algorithm

From the struct recovery in Part 2, we know that rtos_schedule at 0x80000C10 reads a priority-sorted ready list:

1. Read head of ready list (global at 0x8008008C)
2. If list is empty, return (nothing to schedule)
3. container_of(head, task_t, run_list) → get task pointer
4. If this is already the current task, increment its selection counter
5. Otherwise:
   a. Set old task's state to READY (1)
   b. Set new task's state to RUNNING (2)
   c. Increment new task's run_count
   d. If task has an entry function, call it with task->arg

The field named total_ticks counts scheduler selections, including selections that change the current task. It does not measure elapsed timer ticks. There is no CPU context switch or separate task stack. The function calls an entry directly when it selects a new task. In this sample, initialization adds only the idle task; no caller creates a worker task. The data structures and selection code are still useful to recover, but they do not prove a running multi-task RTOS.

The Unwired Timer Tick

The rtos_tick function at 0x80000CB8 walks the timer list:

1. Increment global tick counter
2. For each task on the timer list:
   a. Decrement ticks_remaining
   b. If zero:
      - Remove from timer list (task pointer = node pointer - 0x28)
      - If state is BLOCKED, remove from the blocked list and set state to READY
      - For that task, insert its run_list node at task pointer + 0x20 into the ready list

The task has two list nodes: timer_list at +0x28 and run_list at +0x20. timer_isr calls rtos_tick, but the exception handler in this sample never dispatches to timer_isr. The function is present; the interrupt path that would run it is not.

Putting It All Together

Here is the architecture the binary exposes, with the configured limits kept separate from usable pool capacity:

Firmware architecture and inferred limits
========================================================

BOOT CHAIN (6 phases)
  Phase 0: Hardware → Version, Watchdog, IntCtrl
  Phase 1: Drivers  → UART, GPIO, Timer, DMA
  Phase 2: Core     → Pools, Events, scheduler structures
  Phase 3: Rules    → Rule entry arrays: AR[32], ID[48], AT[24]
  Phase 4: Partitions → fifth ID allocation would fail (0x0D)
  Phase 5: Runtime  → continues, unmasks UART/timer/DMA, writes BOOT_STATUS=0xBEEF

RUNTIME LOOP
  cli_process()    → UART input → dispatch (15 public + 8 hidden)
  event_dispatch() → FIFO queue → registered handlers
  rtos_schedule()  → ready list contains idle task only
  Watchdog kick    → WDG_KICK = 0x5A5A

MEMORY ARCHITECTURE
  Usable pool slots: AR 24 (windowed), ID 4 (linear), AT 4 (copy)
  Sentinels: 0xDEAD0000=FREE, 0xDEAD0001=BOUNDARY, 0xDEAD0002=USED
  Task structs: 60 bytes, dual list nodes at +0x20 and +0x28
  Rule entries: 24 bytes, packed flags at +0x10
  Port configs: 48 bytes, list node at +0x24

HARDWARE PERIPHERALS (7 blocks @ 0xB80x0000)
  UART, GPIO, Timer, SysCon, DMA, IntCtrl, Watchdog

CRYPTO
  AES-128 ECB (S-box @ 0x7F7C, inv-S-box @ 0x7E7C)
  SHA-256 (K[] @ 0x8080, H0[] inlined in code)
  HMAC-SHA256 (ipad=0x36, opad=0x5C)
  These routines are reached through the hidden CLI self-test
  CRC-32 (table @ 0x7A70), CRC-16 (bit-by-bit, poly 0x8005)
========================================================

The distinction between entry arrays and allocatable slots explains the phase-4 failure. It also shows why a status marker alone is insufficient evidence of a healthy boot.

The Techniques, Summarized

Over five posts, we’ve used a consistent set of techniques:

1. Constant scanning (Post 1): Known byte sequences locate candidate tables. AES S-box (63 7C 77 7B), SHA-256 K[] (0x428A2F98), CRC-32 table (0x77073096). Byte searches need no disassembly; checking the full table and its users supports the algorithm identification.

2. Offset collection (Post 2): Memory access offsets from lw/sw instructions reveal struct layouts. container_of subtractions reveal intrusive list node positions. Bitfield masks reveal packed fields.

3. Tool selection (Post 3): r2 maintains a queryable map in the terminal, Ghidra reconstructs C expressions, and Capstone supplies instruction decoding for custom scripts. Check discovered functions, references, and inferred types against the bytes.

4. MMIO pattern recognition (Part 4): Address construction provides candidates; loads, stores, and surrounding control flow show how each address is used.

5. Architectural inference (Post 5): Sentinel values reveal allocator design. Function pointer tables reveal dispatch systems. State transitions reveal protocols. Boot sequences reveal system dependencies.

The same searches can be applied to larger binaries. The amount of data grows, but the need to check each inference against code and control flow does not change.

From Static Inference to a Runtime Check

The useful result is a chain we can inspect: initialization gives the ID pool four slots, the first partition requests twelve, the fifth allocation fails, and the dispatcher continues to a phase that writes 0xBEEF. Each step has an address, a condition, and a consequence. We can also name the condition still to test: whether execution reaches that allocation path with the expected port state.

The next useful experiment is small. Execute the allocator in isolation, or trace partition initialization with controlled port state, and observe the return values and scratch-register write. Whole-image emulation needs more preparation: a model for the memory map, UART status, and other peripheral behavior. It also needs to account for the missing timer dispatch. Loading the image into an emulator does not supply those devices or repair the interrupt path.

Keep the recovered names, struct definitions, reference sites, and assumptions alongside the binary hash. When another build changes a table or a branch, those notes tell us which conclusions need checking again.

We started with recognizable bytes and ended with an explanation for a misleadingly successful boot marker. The remaining work is specific enough to test. That is a useful place to finish the static analysis.

This is Part 5 (final) of “Crypto Tables, Struct Ghosts, and Other Secrets Hidden in Firmware.” The sample bundle contains the firmware binary, source, and entropy scanner.

With memory-mapped I/O (MMIO), loads and stores access peripheral registers through addresses in the processor’s address space. In this sample, a store to virtual address 0xB8000000 writes UART transmit data. A load from 0xB8020000 reads the timer counter. The nearby address 0xB8020004 holds the timer’s compare value.

The addresses alone do not tell us those meanings. We need to follow the loads, stores, and surrounding control flow.

Follow along: Use firmware.bin from the sample bundle, and run the examples from more_complex_firmware/. The assembly excerpts below were disassembled from that binary with Capstone. Comments explain the instructions; gaps between address ranges omit unrelated instructions. The companion source provides a cross-check after analysis.

How MMIO Looks in MIPS Assembly

In the conventional MIPS32 segment layout used here, KSEG1 is the uncached, unmapped virtual address range 0xA0000000–0xBFFFFFFF. “Unmapped” means that accesses bypass the translation lookaside buffer (TLB). The physical address is virtual_address & 0x1FFFFFFF, so 0xB8000000 accesses physical address 0x18000000.

KSEG1 can address RAM as well as peripherals. For example, 0x80080000 in KSEG0 and 0xA0080000 in KSEG1 alias the same physical RAM at 0x00080000, with different cache attributes. An address in KSEG1 is therefore a clue about access policy, not proof of MMIO. The MIPS32 privileged architecture manual, Section 4.6, describes this mapping.

Our sample’s peripheral accesses cluster around 0xB8000000–0xB8060000. The compiler often constructs a base with lui and then uses it in lw or sw. Here is the actual UART transmit store:

80002140:  lui   v0, 0xb800
80002144:  sw    a0, (v0)           # write character to 0xB8000000

The status read uses a separate register for the base:

80002130:  lui   v1, 0xb800
80002134:  lw    v0, 8(v1)          # read 0xB8000008

A lui 0xB8xx instruction gives us a candidate address construction. We still need to find the load or store that uses it.

Step 1: Find Candidate Peripheral Bases

Start with the executable ranges of the bundled binary. The companion ELF identifies .vectors at file offsets [0x0000, 0x02AC) and .text at [0x02B0, 0x7290). For an unknown image, identifying code ranges is itself part of the analysis; these bounds are specific to this build.

The following scan looks for lui instructions in those ranges whose upper immediate falls in our candidate peripheral window:

from collections import Counter
import struct

data = open("firmware.bin", "rb").read()
code_ranges = [(0x0000, 0x02AC), (0x02B0, 0x7290)]
counts = Counter()

for start, end in code_ranges:
    for offset in range(start, end, 4):
        word = struct.unpack_from("<I", data, offset)[0]
        # LUI opcode, with its required zero rs field.
        if (word & 0xFFE00000) != 0x3C000000:
            continue
        upper = word & 0xFFFF
        if 0xB800 <= upper <= 0xB8FF:
            counts[upper << 16] += 1

for base, count in sorted(counts.items()):
    print(f"0x{base:08X}  {count:2d} LUI instructions")
print(f"Total: {sum(counts.values())} LUI instructions")

0xB8000000   8 LUI instructions
0xB8010000  12 LUI instructions
0xB8020000   6 LUI instructions
0xB8030000   7 LUI instructions
0xB8040000   4 LUI instructions
0xB8050000   3 LUI instructions
0xB8060000   5 LUI instructions
Total: 45 LUI instructions

Seven candidate blocks, with 45 base constructions. This is not a count of register accesses: one base can serve several loads and stores, and a loop can execute one instruction repeatedly.

A broad scan that checks only the LUI opcode and an immediate in 0xA000–0xBFFF across the entire flat file produces 51 candidates across 12 upper-address groups. Some are numeric constants in code, including SHA-256 initial-state values; others are data bytes mistaken for instructions. Restricting the scan to code removes the data candidates, and checking the required zero rs field rejects invalid LUI encodings. Following the constructed values into memory accesses distinguishes addresses from constants.

Step 2: Register Access Pattern Analysis

Different access patterns suggest different register roles:

These are hypotheses to check against callers, diagnostic strings, and other access sites. A write does not establish that a register is write-only, and a store of 1 does not prove write-one-to-clear semantics by itself.

The register tables below list accesses observed in this binary. Names come from instruction behavior and the diagnostic register-dump strings. The companion source confirms the intended bit meanings; it does not make unused hardware behavior visible in the binary.

Block 0: UART (0xB8000000)

The initialization function at 0x800023FC writes three configuration values:

800023fc:  lui   v0, 0xb800
80002400:  addiu v1, zero, 1
80002404:  sw    v1, 0x10(v0)       # BAUD = 1
80002408:  addiu v1, zero, 3
8000240c:  sw    v1, 0xc(v0)        # CTRL = 3
80002410:  addiu v1, zero, 7
80002414:  sw    v1, 0x14(v0)       # FIFO control = 7

The transmit routine at 0x80002130 gives us a stronger behavioral clue:

80002130:  lui   v1, 0xb800
80002134:  lw    v0, 8(v1)          # STATUS
80002138:  andi  v0, v0, 1          # test bit 0
8000213c:  bnez  v0, 0x80002134     # wait while busy
80002140:  lui   v0, 0xb800         # branch delay slot; restore TX base
80002144:  sw    a0, (v0)           # TX data
80002148:  jr    ra
8000214c:  nop

The lui in the branch delay slot executes on both outcomes. Keeping the base in v1 lets the loop overwrite v0 with status; the delay-slot instruction then prepares v0 for the transmit store.

The diagnostic command reads CTRL, BAUD, and FIFO_CTRL, so calling them write-only would contradict the firmware. The exact baud rate still depends on a clock the register writes alone do not establish.

Block 1: GPIO (0xB8010000)

The GPIO initializer at 0x80002420 writes direction, pinmux, data, and interrupt registers. These excerpts retain the original addresses:

80002428:  lui   v0, 0xb801
8000242c:  sw    zero, 4(v0)        # DIR = 0

80002438:  sw    zero, 0x1c(v0)     # PINMUX = 0

80002444:  sw    zero, (v0)         # DATA = 0
80002448:  sw    zero, 8(v0)        # INT_EN = 0
8000244c:  addiu v1, zero, -1
80002450:  sw    v1, 0xc(v0)        # INT_STATUS = 0xFFFFFFFF

Direction changes use a RAM shadow. On the output branch of gpio_set_direction, a0 holds the pin number and v0 initially holds 1:

80002484:  sllv  a0, v0, a0         # mask = 1 << pin
80002488:  lui   v0, 0x8008
8000248c:  lw    v0, 0x6d4(v0)      # read RAM shadow at 0x800806D4
80002490:  or    v0, a0, v0
80002494:  lui   v1, 0x8008
80002498:  sw    v0, 0x6d4(v1)      # update RAM shadow
8000249c:  lui   v1, 0xb801
800024a0:  sw    v0, 4(v1)          # write shadow to GPIO DIR

This is a read-modify-write of the shadow, followed by an MMIO write. The interrupt-enable routines do read-modify-write the hardware register itself. Tracking the address at each access distinguishes the two cases.

The all-ones write during initialization and single-bit writes in gpio_int_clear support the write-one-to-clear interpretation. The companion source states that intent explicitly.

Block 2: Timer (0xB8020000)

The timer initializer at 0x80002610 stops the timer before configuring it:

80002628:  lui   v0, 0xb802
8000262c:  sw    zero, 8(v0)        # stop timer
80002630:  addiu v1, zero, 1
80002634:  sw    v1, 0x10(v0)       # prescaler = 1
80002638:  addiu a0, zero, 0x3e8
8000263c:  sw    a0, 4(v0)          # compare = 1000
80002640:  sw    zero, (v0)         # reset counter
80002644:  sw    v1, 0xc(v0)        # acknowledge pending match
80002648:  addiu v1, zero, 7
8000264c:  sw    v1, 8(v0)          # enable, auto-reload, interrupt enable

The source names the three control bits and intends a 1 ms tick. Establishing the actual period would also require the timer input clock and divider semantics.

The handler at 0x800026E4 acknowledges immediately:

800026ec:  lui   v0, 0xb802
800026f0:  addiu v1, zero, 1
800026f4:  sw    v1, 0xc(v0)        # acknowledge without reading STATUS
800026f8:  lui   v0, 0x8008
800026fc:  lw    v1, 0x6e4(v0)      # software tick counter
80002700:  addiu v1, v1, 1
80002704:  sw    v1, 0x6e4(v0)

80002720:  jal   0x80000cb8         # rtos_tick
80002724:  nop

There is no status read before acknowledgment. Also, the sample’s exception handler never dispatches to this ISR. Finding a handler body and finding a working interrupt path are separate steps.

Block 3: System Control (0xB8030000)

Seven lui instructions construct this base. Their uses include startup markers, version reads, reset, error reporting, and diagnostics.

The reset command writes 1 and then loops:

80004bb4:  lui   v0, 0xb803
80004bb8:  addiu v1, zero, 1
80004bbc:  sw    v1, (v0)
80004bc0:  b     0x80004bc0
80004bc4:  nop

The runtime-start phase writes a different register:

800002f8:  lui   v0, 0xb803
800002fc:  ori   v1, zero, 0xbeef
80000300:  sw    v1, 0x14(v0)       # BOOT_STATUS

That marker means execution reached runtime start. Part 5 will show why it does not prove that all earlier phases succeeded.

The “configuring system clock” log string does not establish a clock-register write. Following its instructions reveals a version read and reset handling instead.

Block 4: DMA Controller (0xB8040000)

The DMA initializer at 0x80003960 prepares a 16-entry descriptor ring. Here a0 already holds the ring address, 0x80081314:

800039bc:  lui   v0, 0xb804
800039c0:  sw    zero, (v0)         # disable during setup
800039c4:  sw    a0, 8(v0)          # descriptor ring address
800039c8:  addiu v1, zero, 0x10
800039cc:  sw    v1, 0xc(v0)        # 16 descriptors
800039d0:  sw    zero, 0x10(v0)     # HEAD_IDX = 0
800039d4:  sw    zero, 0x14(v0)     # TAIL_IDX = 0
800039d8:  addiu v1, zero, -1
800039dc:  sw    v1, 0x18(v0)       # clear interrupt status
800039e0:  addiu v1, zero, 3
800039e4:  sw    v1, (v0)           # enable + interrupt enable

Submission fills a descriptor, advances the producer index, and writes HEAD_IDX at +0x10:

80003a34:  sw    a0, (v1)           # descriptor source
80003a38:  sw    a1, 4(v1)          # destination
80003a3c:  sw    a2, 8(v1)          # length
80003a40:  lui   a0, 0x9000
80003a44:  sw    a0, 0xc(v1)        # OWN | IRQ flags
80003a48:  addiu v0, v0, 1
80003a4c:  andi  v0, v0, 0xf        # producer index wraps modulo 16
80003a50:  sw    v0, 0x1310(t1)     # g_dma_head in RAM

80003a60:  lui   v1, 0xb804
80003a64:  sw    v0, 0x10(v1)       # publish new head to DMA controller

Names alone would have led us astray. In this driver, head is the producer’s next submission slot, and tail is software’s next completion slot. dma_poll reads descriptor flags from RAM:

80003b58:  lw    fp, 0x130c(s1)     # g_dma_tail; s1 = 0x80080000
80003b5c:  sll   v0, fp, 4          # 16-byte descriptor stride
80003b60:  addu  v0, s0, v0         # s0 = descriptor ring base
80003b64:  lw    v0, 0xc(v0)        # descriptor flags
80003b68:  bltz  v0, 0x80003ba4     # bit 31: still owned by DMA, stop
80003b6c:  and   v0, v0, s4         # delay slot; s4 = error-bit mask

Once ownership returns, the routine checks descriptor error/completion bits, clears the descriptor, and advances g_dma_tail in RAM. It does not use DMA_STATUS or the MMIO TAIL_IDX register to detect completion.

This is the same broad producer/consumer idea used by queue doorbells, but head/tail names depend on the interface. In NVMe, host software advances the submission queue’s tail and the completion queue’s head. Here the submission producer is called head. Our firmware initializes the MMIO tail at +0x14 and reads it in diagnostics; it contains no device implementation from which to establish subsequent hardware tail updates.

The ring-address store passes the linked KSEG0 address directly. The sample has no address conversion or cache-maintenance code here, so these instructions do not establish a working physical DMA mapping.

Block 5: Interrupt Controller (0xB8050000)

Hardware initialization masks all sources:

80000410:  lui   v0, 0xb805
80000414:  sw    zero, (v0)

Runtime start selects three sources:

800002d0:  lui   v0, 0xb805
800002d4:  addiu v1, zero, 0xb
800002d8:  sw    v1, (v0)           # bits 0, 1, and 3

The source names those bits UART, timer, and DMA. The mask write configures the controller; it does not establish CPU interrupt enablement or dispatch to a peripheral handler.

The source header also defines ACK at +0x08, but the binary never accesses that address. Leave it out of the recovered map: its presence is knowledge from source.

Block 6: Watchdog (0xB8060000)

Hardware initialization sets a timeout, enables the watchdog, and kicks it:

800003f4:  lui   v0, 0xb806
800003f8:  ori   v1, zero, 0xffff
800003fc:  sw    v1, 8(v0)          # timeout
80000400:  addiu v1, zero, 1
80000404:  sw    v1, (v0)           # enable
80000408:  addiu v1, zero, 0x5a5a
8000040c:  sw    v1, 0xc(v0)        # kick

Runtime start and the main loop repeat the kick. The hidden $wdgtest command shortens the timeout:

80004b88:  lui   v0, 0xb806
80004b8c:  addiu v1, zero, 0x10
80004b90:  sw    v1, 8(v0)

That command returns to the main loop, which continues kicking the watchdog. A short timeout alone does not prove that the device will reset.

Step 3: The Observed Peripheral Map

Following the candidate bases into loads and stores gives this map:

These are distinct addresses used by instructions, not 39 accesses at runtime or a complete hardware specification. Diagnostic strings provide names for many registers; the read/write patterns show how this firmware uses them. Bit semantics such as write-one-to-clear remain interpretations supported by the code and confirmed by the sample source.

Automating the Search

The Step 1 script is a first pass. To turn its candidates into a register map, follow each constructed value through register copies and address arithmetic, then record the effective address of each load or store.

For this build, the distinction matters in several places: one UART base feeds repeated status reads; GPIO direction uses a RAM shadow; DMA completion flags live in RAM. A useful scanner reports instruction addresses and what it counted, so we can inspect those cases. A lui histogram alone cannot recover register ownership or side effects.

When adapting the scan to another firmware, replace the code ranges and candidate address window with evidence from that image. Broadening the search to all KSEG1 immediates is useful for triage, provided the output remains a list of candidates to verify.

Exercises

1. Trace the timer handler: Find the function at 0x800026E4 that writes 1 to 0xB802000C and calls 0x80000CB8. Does the exception handler ever dispatch to it? Distinguish a present ISR body from an active interrupt path.

2. Map the DMA descriptors: From initialization and submission, recover the ring address, entry count, and descriptor stride. Identify the source, destination, length, and flags fields. Which bit makes dma_poll stop, and which MMIO index does submission write?

3. Trace boot markers: Follow writes to system-control offsets +0x0C, +0x10, and +0x14. What do 0xB007, the phase/error encoding, and 0xBEEF tell us about execution?

4. Check the clock claim: Find every reference to 0xB8030004. Is it read or written? Compare the result with the “configuring system clock” log message. What evidence would be needed to recover actual clock configuration?

What’s Next

We’ve mapped the addresses the firmware uses, identified its peripheral access patterns, and seen where the available evidence stops. In the final post, we’ll combine that map with struct recovery and dispatch tables to examine the pool allocator, scheduler code, and rule state transitions during boot.

This is Part 4 of “Crypto Tables, Struct Ghosts, and Other Secrets Hidden in Firmware.”

Next: Part 5 — Sentinel Values, Pool Modes, and Other Clues to Runtime Architecture.

A byte search remains easy in a larger binary. Maintaining function boundaries, references, types, and annotations is where an analysis framework earns its place.

This time we will use radare2 to build that map in a terminal, then inspect the same firmware with Ghidra and Capstone. The tools agree on several useful facts. Their output also gives us a few things to question.

Follow along: Download the sample bundle, extract it, and work from more_complex_firmware/. These examples analyze firmware.bin as a raw image at 0x80000000. The companion ELF and source are used afterward to check the results.

The captured output uses radare2 6.2.4, Ghidra 12.1.4, Capstone 5.0.7, and r2pipe 1.9.6. Ghidra was run headlessly with JDK 25; its native decompiler was built from the release sources for macOS ARM64. Follow the release’s Getting Started instructions, including native components for your platform. The r2ghidra plugin is optional and is not used for the captured results.

Load the Raw Image in Radare2

A flat binary has no header telling r2 its architecture or load address:

r2 -a mips -b 32 -e cfg.bigendian=false -e anal.cc=o32 \
   -m 0x80000000 firmware.bin

The bit width and calling convention are separate settings. Selecting o32 tells analysis how arguments and return values are passed; it does not guarantee that every inferred function signature is correct.

For the plain-text displays below, disable colors and automatic disassembly comments:

[0x80000000]> e scr.color=0
[0x80000000]> e asm.comments=false
[0x80000000]> s 0x80007f7c
[0x80007f7c]> px 64
- offset -  7C7D 7E7F 8081 8283 8485 8687 8889 8A8B  CDEF0123456789AB
0x80007f7c  637c 777b f26b 6fc5 3001 672b fed7 ab76  c|w{.ko.0.g+...v
0x80007f8c  ca82 c97d fa59 47f0 add4 a2af 9ca4 72c0  ...}.YG.......r.
0x80007f9c  b7fd 9326 363f f7cc 34a5 e5f1 71d8 3115  ...&6?..4...q.1.
0x80007fac  04c7 23c3 1896 059a 0712 80e2 eb27 b275  ..#..........'.u

That is the S-box from Part 1. s changes the current address, and px prints bytes. The address in the prompt is the current position in the mapped image.

Run Analysis, Then Check What It Found

Return to the image base and ask r2 to analyze it:

[0x80007f7c]> s 0x80000000
[0x80000000]> aaa
[0x80000000]> aflc
75

aaa runs analysis passes that discover functions, references, and control flow. aflc counts the functions in the current analysis database; afl lists them.

The number 75 is an analysis result, not the number of functions in the firmware. The companion ELF has 155 symbols explicitly typed as functions, plus seven untyped startup/vector labels. Under the raw-import settings used later, Ghidra discovers 108 functions. These counts describe different analysis results; neither automatic pass is a complete inventory.

For a concrete omission, Part 2 located rtos_sem_wait at 0x80000F98. In this fresh r2 session:

[0x80000000]> afij @ 0x80000f98
[]

afij asks for function information as JSON. An empty array means r2 has no function containing that address in this analysis. Inspect the instructions and analyze the known entry explicitly:

[0x80000000]> af @ 0x80000f98
[0x80000000]> afn rtos_sem_wait 0x80000f98

We supply that address from the earlier analysis. The command does not discover the semaphore’s meaning for us.

Find the Tables

Hex searches are short:

[0x80000000]> /x 637c777b
0x80007f7c hit1_0 637c777b
[0x80000000]> /x 982f8a42
0x80008080 hit2_0 982f8a42
[0x80000000]> /x 96300777
0x80007a74 hit3_0 96300777

The last hit is at 0x80007A74, the CRC-32 table’s second entry. The table starts four bytes earlier at 0x80007A70. Hit names and numbering can change as searches accumulate.

These prefixes locate candidates. As in Part 1, check the rest of a table and follow its code references before deciding which algorithm a function implements.

Python can do the byte search just as directly:

data = open("firmware.bin", "rb").read()
offset = data.find(bytes.fromhex("63 7c 77 7b"))
if offset >= 0:
    print(f"S-box candidate at 0x{0x80000000 + offset:08X}")

S-box candidate at 0x80007F7C

This needs no disassembler. The reason to stay in r2 is what we can do with the address next.

Follow References Into Code

axt lists the discovered references to an address:

[0x80000000]> axt 0x80007f7c
fcn.800063ac 0x800063b8 [DATA:r--] addiu a1, a1, 0x7f7c
fcn.80006440 0x80006474 [DATA:r--] addiu t0, t0, 0x7f7c
fcn.80006440 0x80006514 [DATA:r--] lbu v1, (v1)
fcn.80006440 0x80006520 [DATA:r--] lbu t1, (t1)
fcn.80006440 0x8000652c [DATA:r--] lbu a1, (a1)
fcn.80006440 0x80006538 [DATA:r--] lbu v0, (v0)

The output names two containing functions: fcn.800063ac and fcn.80006440. It includes both address construction and indexed table loads. Six reference sites do not mean six different functions.

Inspect the two address constructions:

[0x80000000]> pd 2 @ 0x800063b4
│           0x800063b4      0080053c       lui a1, 0x8000
│           0x800063b8      7c7fa524       addiu a1, a1, 0x7f7c
[0x80000000]> pd 2 @ 0x80006470
│           0x80006470      0080083c       lui t0, 0x8000
│           0x80006474      7c7f0825       addiu t0, t0, 0x7f7c

Both pairs produce 0x80007F7C. From the surrounding code, the first function substitutes bytes in a block; the second uses substitutions during key expansion. We can name them sub_bytes and aes_key_expand.

Now follow the helper’s callers:

[0x80000000]> axt 0x800063ac
fcn.80006558 0x800065d4 [CALL:--x] jal fcn.800063ac
fcn.80006558 0x80006730 [CALL:--x] jal fcn.800063ac

Both calls come from the function at 0x80006558. Following the inverse S-box at 0x80007E7C leads through inv_sub_bytes at 0x800063E0 to decryption at 0x800067F0. Table users and the public block-operation functions are different points in the call graph.

The SHA-256 round table gives another example:

[0x80000000]> axt 0x80008080
fcn.80006c10 0x80006cf8 [DATA:r--] addiu a2, a2, -0x7f80
fcn.80006c10 0x80006d50 [DATA:r--] lw s4, (a2)

Here the reference at 0x80006CF8 completes an address construction. The lui a2, 0x8001 is nine instructions earlier, at 0x80006CD4. The signed addition -0x7F80 produces 0x80008080. A scanner that only accepts adjacent lui/addiu pairs would miss it.

Keep the Names

Once the behavior supports a name, record it:

[0x80000000]> afn aes_encrypt_block 0x80006558
[0x80000000]> afn aes_decrypt_block 0x800067f0
[0x80000000]> afn sha256_transform 0x80006c10
[0x80000000]> afn rtos_schedule 0x80000c10
[0x80000000]> pd 5 @ rtos_schedule
┌ 168: rtos_schedule ();
│ afv: vars(2:sp[0x10..0x14])
│           0x80000c10      0880033c       lui v1, 0x8008
│           0x80000c14      8c00628c       lw v0, 0x8c(v1)
│           0x80000c18      8c006324       addiu v1, v1, 0x8c
│       ┌─< 0x80000c1c      24004310       beq v0, v1, 0x80000cb0
│       │   0x80000c20      e0ff4424       addiu a0, v0, -0x20

The bytes and branch targets are unchanged. We have attached names to the functions that analysis already found. The addiu at 0x80000C20 is the container_of subtraction from Part 2; it also occupies the branch delay slot and executes on both outcomes.

To inspect the control-flow graph, seek to the function and enter visual graph mode:

[0x80000000]> s rtos_schedule
[0x80000c10]> VV

For output that can be captured without an interactive terminal, use agf @ rtos_schedule. Its first block is shown below, with leading padding removed; the rest of the graph is omitted:

┌─────────────────────────────────────────────────┐
│  0x80000c10                                     │
│   ; CALL XREF from fcn.80000540 @ 0x80000724(x) │
│ 168: rtos_schedule ();                          │
│ afv: vars(2:sp[0x10..0x14])                     │
│ lui v1, 0x8008                                  │
│ lw v0, 0x8c(v1)                                 │
│ addiu v1, v1, 0x8c                              │
│ beq v0, v1, 0x80000cb0                          │
│ addiu a0, v0, -0x20                             │
└─────────────────────────────────────────────────┘

Save the analysis and reopen it in another session:

[0x80000c10]> Ps firmware_re
[0x80000c10]> q

r2 -p firmware_re

The four renamed functions survived a save/reopen check with this version. Keep the rename commands too: they are a small, readable record of the conclusions we supplied. A project stores more state, but a script is easier to inspect in a diff.

Automate the Session With r2pipe

r2pipe sends commands to a running r2 process and returns text or JSON. Install the Python binding in your analysis environment; these examples use version 1.9.6.

import r2pipe

r2 = r2pipe.open("firmware.bin", flags=[
    "-a", "mips", "-b", "32",
    "-e", "cfg.bigendian=false", "-e", "anal.cc=o32",
    "-m", "0x80000000",
])
try:
    r2.cmd("aaa")
    for pattern, label in [
        ("637c777b", "AES S-box candidate"),
        ("982f8a42", "SHA-256 K[] candidate"),
        ("96300777", "CRC-32 second-entry candidate"),
    ]:
        hits = r2.cmdj(f"/xj {pattern}")
        for hit in hits:
            print(f"{label}: 0x{hit['addr']:08X}")
    functions = r2.cmdj("aflj")
    print(f"{len(functions)} functions in this analysis")
finally:
    r2.quit()

AES S-box candidate: 0x80007F7C
SHA-256 K[] candidate: 0x80008080
CRC-32 second-entry candidate: 0x80007A74
75 functions in this analysis

The JSON forms (/xj and aflj) avoid parsing display columns. The try/finally closes the child process if a search or later processing fails.

Inspect the Same Image in Ghidra

Import firmware.bin as Raw Binary, choose MIPS:LE:32:default, and set the base address to 0x80000000. Run the default analysis. These are the same image bytes and base address used in r2.

To repeat the S-box search in the GUI, use Search → Memory…, select hex input, and search for 63 7C 77 7B. At the result, References → Show References To opens the discovered reference list. The Ghidra introductory guide documents these actions; the results here were exported through Ghidra’s headless API.

For the S-box, that API reports:

80006514 DATA FUN_80006440
80006520 DATA FUN_80006440
8000652c DATA FUN_80006440
80006538 DATA FUN_80006440
800063c4 DATA FUN_800063ac

These are the same two containing functions r2 found, but the reference sites differ. Ghidra reports the indexed load in sub_bytes at 0x800063C4, while r2 also reports the address-building instruction at 0x800063B8. Agreeing on the table’s users matters more than having identical lists of instruction addresses.

Read the Decompiled Function

Navigate to 0x80006C10 and inspect the Decompiler window. This is an excerpt of the actual Ghidra output before renaming or applying source types:

  local_20 = (int *)local_120;
  local_1c = local_120;
  do {
    *local_1c = (uint)*param_2 << 0x18 | (uint)param_2[1] << 0x10 | (uint)param_2[3] |
                (uint)param_2[2] << 8;
    param_2 = param_2 + 4;
    local_1c = local_1c + 1;
  } while (local_1c != local_e8 + 2);

Each iteration assembles four input bytes into a big-endian word. Ghidra recovers that expression and the loop condition, but it splits the message schedule across several guessed stack arrays: local_120, local_fc, and local_e8. The original source’s single 64-word array has not been recovered cleanly.

Further down, the round loop ends with:

  } while (piVar8 != (int *)s_CLI_initialized_80008180);

The CLI label looks out of place in a SHA-256 loop. The comparison uses address 0x80008180, immediately after the 256-byte K[] table. Ghidra has named that address after the adjacent string. The code is comparing an end pointer; it never reads the string here. Checking the table extent resolves the apparent connection.

This is the useful boundary of decompilation: it can reconstruct expressions and control flow while still giving an address or local variable a misleading name or type.

Compare With r2’s Pseudocode

Run pdc @ sha256_transform in the renamed r2 session. The same input-word loop appears as:

    do {
        // CODE XREF from sha256_transform @ 0x80006c70(x)
        v0 = (unsigned) byte [a1 + 0] // arg2
        v0 <<= 0x18
        v1 = (unsigned) byte [a1 + 1] // arg2
        v1 <<= 0x10
        v0 |= v1
        v1 = (unsigned) byte [a1 + 3] // arg2
        v0 |= v1
        v1 = (unsigned) byte [a1 + 2] // arg2
        v1 <<= 8
        v0 |= v1
        v1 = [sp + 0x104]
        [v1 + 0] = v0
        a1 += 4       // arg2
        v0 = v1 + 4
        [sp + 0x104] = v0
    } while (v0 != a2);

The output retains registers, stack stores, and instruction-like operations. It is useful for following the assembly, while Ghidra’s output combines more operations into C expressions. r2 also inferred a third argument in this function, although the companion source has two. A guessed signature needs the same scrutiny as a guessed struct field.

The optional r2ghidra plugin provides pdg using Ghidra’s decompiler engine inside r2. It was not installed for this comparison. Sharing a decompiler engine does not make the surrounding function discovery, types, and analysis inputs identical.

Rename Functions in Either Framework

A batch rename is straightforward in both tools. In r2, save these commands as renames.r2:

aaa
af @ 0x80006558
afn aes_encrypt_block 0x80006558
af @ 0x800067f0
afn aes_decrypt_block 0x800067f0
af @ 0x80006c10
afn sha256_transform 0x80006c10
af @ 0x80000c10
afn rtos_schedule 0x80000c10
Ps firmware_re

Run them in a fresh session:

r2 -q -a mips -b 32 -e cfg.bigendian=false -e anal.cc=o32 \
   -m 0x80000000 -i renames.r2 firmware.bin

Ghidra can do the same work from the GUI or headlessly. Save this script as RenameFirmware.java:

import ghidra.app.script.GhidraScript;
import ghidra.program.model.listing.Function;
import ghidra.program.model.symbol.SourceType;

public class RenameFirmware extends GhidraScript {
    @Override
    public void run() throws Exception {
        long[] addresses = {0x80006558L, 0x800067f0L, 0x80006c10L, 0x80000c10L};
        String[] names = {"aes_encrypt_block", "aes_decrypt_block",
                          "sha256_transform", "rtos_schedule"};
        for (int i = 0; i < addresses.length; i++) {
            Function function = getFunctionAt(toAddr(addresses[i]));
            if (function == null) {
                throw new IllegalStateException("Analyze the function at " + toAddr(addresses[i]));
            }
            function.setName(names[i], SourceType.USER_DEFINED);
            println(function.getEntryPoint() + " " + function.getName());
        }
    }
}

For a fresh headless import, with GHIDRA_HOME pointing at the extracted Ghidra installation:

mkdir -p ghidra-projects
"$GHIDRA_HOME/support/analyzeHeadless" ghidra-projects firmware_re \
    -import firmware.bin -loader BinaryLoader -loader-baseAddr 0x80000000 \
    -processor MIPS:LE:32:default -cspec default \
    -scriptPath . -postScript RenameFirmware.java

The script’s messages, without the headless logger’s prefixes:

80006558 aes_encrypt_block
800067f0 aes_decrypt_block
80006c10 sha256_transform
80000c10 rtos_schedule

Both frameworks can save names and automate edits. The r2 script uses analysis commands directly; the Java script uses Ghidra’s function API. Choose according to the analysis database you intend to maintain.

Where Capstone Fits

Capstone is the disassembly library we used earlier. It does not maintain a function database or decompile code, but it is useful when we want to control exactly which instructions a script examines.

This scan finds the first SHA-256 initial-state constant load in the code ranges of this build:

from capstone import Cs, CS_ARCH_MIPS, CS_MODE_MIPS32, CS_MODE_LITTLE_ENDIAN

data = open("firmware.bin", "rb").read()
md = Cs(CS_ARCH_MIPS, CS_MODE_MIPS32 | CS_MODE_LITTLE_ENDIAN)
for start, end in [(0x0000, 0x02AC), (0x02B0, 0x7290)]:
    for insn in md.disasm(data[start:end], 0x80000000 + start):
        if insn.mnemonic == "lui" and insn.op_str.endswith(", 0x6a09"):
            print(f"Initial-state constant candidate at 0x{insn.address:08X}")

Initial-state constant candidate at 0x80006E28

The ranges come from the companion ELF and exclude the read-only data. In an unknown image, we would first need evidence for those code bounds. This scan finds a candidate instruction; the following ori and stores establish the full constant and its use.

Building a custom reference finder with Capstone remains possible. We would need to track register values across instruction sequences, account for branch delay slots, and associate references with function boundaries. That work makes sense when the analysis is specialized or needs to run across many images. For ordinary browsing, r2 and Ghidra already maintain those relationships.

Compare the Work, Not the Number of Commands

For this firmware, r2 gives us a compact terminal workflow from a table search to its users, callers, and saved names. Ghidra gives us C expressions and an interface for applying the structs recovered in Part 2. Capstone gives us instruction decoding inside a script we control. The useful distinction is which work each tool maintains for us.

If you prefer a GUI around a terminal-oriented analysis framework, Cutter is another option. Its current backend is Rizin, so r2 commands and project behavior should not be assumed to match.

Exercises

1. Compare references: Collect S-box references in both r2 and Ghidra. Group them by containing function. Which differences are address-construction sites versus actual loads?

2. Question a label: Find s_CLI_initialized_80008180 in the SHA-256 decompilation. Use the K[] start and size to explain the end-pointer comparison. What annotation would make it clearer?

3. Check persistence: Rename the four functions, save the project, close the tool, and reopen it. Verify the names at the same addresses. Export a second map as JSON or text and keep it beside your notes.

4. Find a missed function: Inspect rtos_sem_wait at 0x80000F98 in a fresh r2 analysis. Define it explicitly, then compare its boundaries with the companion ELF. Does adding a known entry change the discovered reference map?

What’s Next

We can now query references, preserve names, and compare decompiled code with the underlying instructions. In Part 4, we will use those capabilities to separate accesses to hardware registers from ordinary memory accesses, then build a map of the seven peripheral blocks used by this firmware.

References

• The Official Radare2 Book: firmware setup — loading a raw image with the correct architecture and mapping.
• The Official Radare2 Book: code analysis — function analysis and cross-reference commands.
• The Official Radare2 Book: projects — saving and restoring analysis.
• Ghidra introductory guide — searching and navigating references.
• Capstone Python tutorial — decoding instructions from Python.

This is Part 3 of “Crypto Tables, Struct Ghosts, and Other Secrets Hidden in Firmware.”

Next: Part 4 — Register Maps, MMIO Blocks, and Other Hardware Buried in Code.

Part 3 measured four candidate generators against a funded-address snapshot. Here I want to connect the small-source problem to documented failures, then show an experiment whose expected match count we can actually observe. The benchmark made 150 billion synthetic probes. Its planted case counted 174 matches against 186.26 expected.

The historical cases fall into four useful groups. These identify failure mechanisms; they do not rank severity or assign a common search cost. The benchmark’s bit widths are experimental choices, separate from those incidents.

Integration bypassed the intended source

Debian’s CVE-2008-0166 record describes predictable key material after a packaging change removed entropy-mixing code. “32,768 possible keys” is an imprecise retelling. Debian’s weak-key guidance identifies 32,767 process-ID-derived streams per architecture; actual key sets also depend on key type and generation parameters. The important change was a collapse to a small, reproducible output family.

Android’s 2013 SecureRandom note describes improper initialization of the underlying pseudorandom number generator (PRNG). This could affect key generation and signing. A weak key and a repeated signing nonce are distinct routes to compromise, even when the same integration fault can contribute to both.

The 2026 Ill Bloom disclosure traced weak BIP39 entropy to a vulnerable CryptoJS.lib.WordArray.random() implementation using a custom Multiply-With-Carry generator. Exposure depended on downstream wallet software using that output for mnemonic generation; including CryptoJS as a dependency was insufficient. The researchers’ chain analysis estimated a $5,690,922 lower bound through July 13, 2026. This was a longstanding randomness weakness disclosed in 2026.

Coinkite’s COLDCARD disclosure is a particularly concrete integration failure. A build and link error routed seed generation through MicroPython’s software PRNG instead of the intended hardware random-number generator (RNG). The hardware source was healthy. The wallet-generation path simply did not use it.

Under its stated attack assumptions, Coinkite estimated about 40 bits of effective search for affected Mk2/Mk3 seeds and about 72 bits for later affected models with additional secure-element input. Those are the vendor’s model-specific estimates. A source-code review that finds the correct RNG implementation still has to establish which symbol the final binary calls. The linker gets a vote.

Startup and hardware interfaces supplied too little entropy

FreeBSD has two separate examples. A 2008 advisory covered insufficient early-boot entropy for arc4random. A 2015 FreeBSD-CURRENT warning concerned a modular RNG change that omitted randomdev_init_reader. The affected read_random(9) and arc4random path could generate predictable keys from revision r273872 until the fix at r278907. The warning called for key regeneration; HardenedBSD reported downstream exposure.

These were separate faults in specific versions. The 2015 bug did not literally return 7, either. Its technical analysis describes a predictable fallback sequence, including a recurrence using 7^5. That is memorable enough without improving the story.

Lenovo’s XClarity Controller advisory reports predictable hardware RNG values for the first 32 draws after startup or draws less than two microseconds apart. The affected component was a baseboard management controller (BMC) in servers. This is evidence about that controller’s entropy interface, with no demonstrated connection to Bitcoin wallet generation.

Bishop Fox’s IoT research shows what happens when callers ignore an RNG error from a hardware abstraction layer. They can proceed with zeroes, partial data, or uninitialized bytes in the output buffer. The study identifies a broad class of possible mistakes; it does not count demonstrated compromises across that entire population. A functioning physical source cannot help code that accepts a failed read.

The generator was unsuitable for secrets

Milk Sad and the Trust Wallet browser-extension investigation describe different wallet-generation paths beginning with a 32-bit PRNG input. A long mnemonic cannot recover the missing input uncertainty. Enumerating that input space is the relevant attack model, with costs set by each wallet’s complete derivation pipeline.

Mersenne Twister also permits a different attack: an observer with 624 consecutive full 32-bit MT19937 outputs can reconstruct its state. This technical demonstration shows the process. Wallet addresses, truncated values, and hashes do not satisfy that observation condition automatically. Small-seed enumeration and state cloning are separate attacks.

Dual_EC_DRBG had a conditional prediction route. The 2007 Shumow–Ferguson presentation showed that knowing a secret relationship between its public elliptic-curve parameters could permit output prediction. NIST removed the algorithm from its recommendations in 2014. The demonstration establishes a possible trapdoor; it does not prove who held the required secret for the standardized points. A bounded small-seed search cannot represent this mechanism.

Clocks and correlations gave the game away

Goldberg and Wagner’s Netscape analysis found that the UNIX browser seeded its SSL PRNG with the time of day, process ID, and parent process ID. An attacker could narrow those inputs. The paper describes different details on Windows and Mac, so there is no single seed formula to apply to every Netscape build.

The PlanetPoker researchers found a bounded, clock-seeded shuffle and demonstrated a real-time deck predictor. They reported no use of the weakness to win money. A deck selected from a narrow seed population cannot provide the uncertainty of all 52! permutations; the timing window and implementation determine the actual search.

Marsaglia’s paper, Random Numbers Fall Mainly in the Planes, illustrates a statistical failure of congruential generators. RANDU is a concrete example: its successive triples fall on only 15 planes. Those correlations matter for simulations that assume independent triples. They do not, by themselves, specify a wallet-search cost or establish a historical Bitcoin compromise.

After generation: signing and disclosure

Reusing a nonce in the Elliptic Curve Digital Signature Algorithm (ECDSA) can expose a key. Two signatures with the right algebraic relationship can expose the signing key without a seed search. Android’s 2013 failure also had a signing consequence. The separate nonce_reuse.py example demonstrates that algebra with synthetic signatures.

The reported implant in Part 0 copied the secret after generation. An ideal RNG cannot protect words read from the display. Both cases belong in the threat model, but neither is a small key-generation space to enumerate.

The strong-source model

BIP39 begins a 12-word mnemonic with 128 bits of entropy and a 24-word mnemonic with 256 bits. For an independently chosen uniform secret, q distinct guesses have success probability at most q/2^128 or q/2^256. A sound source leaves no small initial candidate set for the attacker.

Real devices have to collect and condition entropy to approach that model. Apple’s platform-security guide and Ledger Donjon’s RNG threat model describe designs. NIST SP 800-90B provides entropy-source assessment and health-test guidance. Design documents and finite tests supply evidence about particular properties. They cannot establish that an unknown observer has no predictive information.

Giving the benchmark something to find

The scanner’s zero matches leave a measurement problem: how do we check a matching pipeline when its model predicts almost no matches? I used a separate synthetic-token benchmark, with a known target population large enough to produce observable hits. It generates no Bitcoin keys, mnemonics, addresses, or signatures.

The repository’s illustrative RNG lab is separate. Its supplied fixtures are synthetic; it has no historical wallet fixture corpus or current-holdings matching. Its documentation describes the implemented mappings and their limits. The historical incidents above have their own sources and attack models.

The first benchmark, on October 13, used a fictional fixed-output source and bounded spaces of 2^12, 2^16, 2^20, and 2^23 states. Targets were placed near the 75% rank so that the searches would do substantial work. The 23-bit case found its target after 6,291,457 probes in 3.811 seconds, about 1.65 million tokens/s. Those attempt counts were fixed by construction; the rate was measured. With --random-target, rank is uniform and expected full-search work is (2^b + 1)/2, before any budget truncation.

The retained baseline JSON includes the measured timings and configuration. Its idealized 128- and 256-bit controls each made ten million independent draws with replacement and found zero matches. Their single-target hit-probability bounds were about 2.94 × 10^-32 and 8.64 × 10^-71. These budgets cannot distinguish such tiny rates. Running longer without changing the model would mostly produce a larger zero.

For the checkpointed benchmark, we added 2²⁰ distinct planted targets in a 2⁴⁸-state space. Each candidate is an independent uniform draw with replacement. The benchmark hashes it, looks up the token, and checks the full state. The planted target set remains fixed across chunks and resumes.

For M targets in 2^b states and q probes:

p = M / 2^b
expected matches = q*p
variance = q*p*(1-p)
P(at least one match) = 1 - (1-p)^q

Our density gives p = 2^-28. Repeated probes finding the same target count separately. This is an invented population chosen for measurement; it assigns no target count or entropy value to a historical wallet incident.

Before launch, a denser local check used 1,024 targets in 2^16 states and 200,000 probes per long case. It observed 3,146 planted matches against 3,125 expected, 0.38 standard deviations above expectation. The validation record retains its configuration, implementation hashes, and results.

The completed benchmark

The synthetic benchmark used 32 worker processes and reached the configured probe caps after 7 h 44 min 30 s, before the eight-hour limit.

The bounded calibration targets were uniformly placed on this run:

The three long cases each completed 50 billion probes:

At that planted budget, the model predicts 186.26 matches, with standard deviation 13.65. The observed 174 is 0.90 standard deviations below expectation. That comparison describes the observation against its model; it is not a pass/fail threshold for a random count.

Each strong-control worker subchunk draws a fresh uniform target. The single-target per-probe probability still applies, but these are not 50 billion attempts against one target fixed for the whole run. The probabilities of at least one match are bounded by 1.47 × 10^-28 and 4.32 × 10^-67.

The long cases ran in rotation, so their rates cannot be added as simultaneous throughput. Compared with an earlier interrupted one-worker execution on the same server, they were 20.3–20.7 times faster. Chunk sizes, schema, duration, and runtime conditions differed. This is a descriptive rate comparison, rather than a controlled CPU-scaling study. The linked guide explains the timing limitations and points to the original results and their implementation hashes.

What the measurements support

The planted count is the useful positive evidence. This implementation detected rare planted matches at the measured scale, with an aggregate count close to the model’s expectation. That does not establish correctness for every input path or reproduce a wallet incident. Small-space calibration and retained source identity provide separate checks.

The strong controls have much less statistical power. Their zero counts agree with the ideal models, but cannot establish that a device supplied 128 or 256 bits of entropy. Also, the planted case has a million targets while each strong-control subchunk has one. Space size, target count, and probe count jointly determine the expected count. Here the density 2^20 / 2^48 = 2^-28 made the positive control observable.

More processors let us collect that evidence sooner. For a fixed workload, target count, and time budget, a 20-fold rate improvement buys about log2(20) = 4.3 more bits of searchable space at the same expected match count. Even an ideal 32-fold gain buys five bits. That helps a bounded experiment; it does little to close the gap to a uniformly chosen strong secret. These rates measure synthetic tokens, not Bitcoin address generation.

The series started with a secret reportedly copied from a display. Along the way, we saw small generation spaces, unsuitable algorithms, integration faults, and signing failures. Each has a specific failure point. The benchmark gives us measured search costs for one stated model. The hardware story reminds us that an attacker who can read the secret has no reason to pay those costs.

A lottery with a block reward

Calling random key hunting a “Bitcoin lottery” makes the proposed prize sound rather more innocent than it is. A successful guess against a funded address would give access to somebody else’s coins. There is already a Bitcoin lottery that pays the winner for useful work: solo mining.

Take 1 TH/s of sustained mining and an $80 hardware budget. Solo Satoshi sells small miners in this class; its Bitaxe Gamma listing quotes 1.2 TH/s at $61–$72, depending on options. The $80 is a round-number budget, and I round the rate down to 1 TH/s. Delivery, electricity, and any solo-pool deductions are separate.

Bitcoin’s proof of work asks for a block-header hash below the target. Freeze difficulty at 132.716 trillion, the historical value recorded at block 969,696. At difficulty D, finding a block takes approximately D * 2^32 hashes on average. For h hashes per second and t seconds:

P(at least one block) ≈ 1 - exp(-h*t / (D*2^32))

For the key search, use Part 3’s 27,637 keys/s, with both legacy P2PKH forms checked for every key. Generously count all 21,198,062 legacy-shaped snapshot entries as valid targets. Under the ideal-hash model:

P(at least one snapshot match) ≤ 2 * keys_per_second * t * 21,198,062 / 2^160

Here are the probabilities over the same time windows, with full uptime and unchanging difficulty and targets:

The miner’s annual chance is only 0.0055%. Its mean waiting time at that fixed difficulty is about 18,000 years; a block does not become due when the clock reaches that number. Yet its chance is roughly 2.2 × 10²⁴ times the measured scanner’s upper bound. Even the invented trillion-key rate leaves solo mining about 6 × 10¹⁶ times ahead: sixty quadrillion.

A mining ASIC’s trillion hashes per second cannot be repurposed into a trillion private-key-and-address derivations. That last row deliberately gives the key search an enormous allowance. These are probability comparisons, not a claim that an $80 miner will pay for itself. Mining figures also ignore stale blocks; the address figures concern that fixed legacy snapshot, not every wallet or its later balance. The calculation and inputs are included with the companion scripts.

The failures in this series came from predictable inputs, broken integration, unsafe signing, or a secret being copied. Randomly guessing a sound secret remains a terrible plan. If the attraction is a tiny chance of receiving Bitcoin, solo mining offers much better odds and a reward the protocol actually intends you to collect.

For once, the honest lottery has the better odds.

The question entropy leaves open

The lottery comparison concerns guesses. Bitcoin also gives an attacker mathematical information about the secret: a public key calculated from it.

A private key d determines a public point Q through Q = dG. Here G is a fixed, public base point on the elliptic curve called secp256k1. Multiplication means repeated point addition, computed efficiently. The network uses the public key to verify a transaction signature without being given the private key. Bitcoin’s ECDSA and Schnorr signatures both use this curve.

For the legacy P2PKH addresses checked by our scanner, the diagram separates forward derivation from the two attack routes:

Here the address encodes a hash of the public key. Spending a P2PKH output reveals that public key. Other output types expose different information: Taproot includes an output public key from the start. A fresh receiving address does not automatically mean a hidden public key.

The recent CoinDesk report on Justin Drake’s warning concerns this other route. Drake raised the possibility of an AI-assisted mathematical breakthrough that could make private-key recovery practical from exposed public keys. The report presents a worst-case forecast; it supplies no working attack demonstrating that Bitcoin keys can be recovered this way.

Finding d from Q and G is the elliptic-curve discrete logarithm problem. The security argument in BIP340 explicitly assumes that this problem is hard. A practical method for solving it on secp256k1 would threaten exposed public keys even if their private keys had been generated with perfect randomness.

We have calculated guessing probabilities under stated assumptions and measured a deliberately weakened model. A huge keyspace and 150 billion synthetic probes cannot prove that no mathematical shortcut exists.

Entropy explains the cost of guessing d. The next question is what it would take to recover d from dG.

The scanner in research/ uses four candidate rules: secure random draws, patterned integers, single-word brainwallets, and a synthetic weak pseudorandom number generator (PRNG). For each candidate, it derives compressed and uncompressed legacy Pay-to-Public-Key-Hash (P2PKH) addresses and screens them against a dated funded-address snapshot. It reads public data and never constructs, signs, or broadcasts a transaction.

These runs found zero funded-snapshot matches. Selected known, drained addresses supplied positive controls. The weak-PRNG rule is a small-seed model; it does not reproduce a historical wallet bug.

Tier 0: random control

The baseline generated 1,500,000 cryptographically random keys with os.urandom and derived three million candidate addresses. It screened them against an index of 57,205,029 addresses from the October 13, 2026 snapshot and the scanner’s built-in 16-address control set. Explorer lookups run only after a flag; this control produced none.

Here is the retained output:

tiers        : random_control
screened against: funded-address index 2026-10-13 (57,205,029 addrs) + built-in control set (16 addrs) + online API verification of hits
online lookups: 0 ok, 0 failed
keys checked : 1,500,000  (10^6.2)
hits (ever used) : 0   [control: 0, dump: 0]
hits (funded now): n/a (no online lookups)
elapsed      : 54.3s   rate 27,637 keys/s
projection   : ~10^11.9 keys/year on this core
               to cover the *narrowed* 12-word space (2^128 = 10^38.5): ~10^26.6 years
               (age of universe ~ 10^10.1 years)

The raw-key rate was 27,637 keys/s with the index loaded. The output’s 12-word projection divides the mnemonic space by that rate. It does not measure mnemonic search, which also needs PBKDF2 and BIP32 derivation. Adding those steps to this pipeline adds work.

The run used CPython 3.13 on Linux. Python documents that os.urandom uses blocking getrandom() when available and waits for kernel initialization. This addresses that early-boot handoff; it does not certify the operating system’s entropy source.

What the index checks

The compact index stores 64-bit prefixes of address hashes. At this size, an absent address has a modeled collision probability of about 3.10 × 10⁻¹² per lookup: 9.30 × 10⁻⁶ expected flags over three million lookups. A flag therefore needs an exact full-address check against the original dump. Today’s explorer history cannot prove membership in an earlier snapshot.

There is an open implementation issue here. The scanner retains an index flag as a dump hit even after a negative explorer response. Future positive flags need separate exact confirmation. These runs had zero flags; with a correctly built index, zero flags also means zero exact matches for the tested addresses. The scanner guide documents the prefix index and this verification limitation.

A streaming inventory found these shapes in the same dump:

These are prefix-and-length classifications, without checksum validation. The snapshot date comes from the filename. Its gzip SHA-256 is 7117127c3a0e8276e3c6c4ad8f4fc28fc0498886481f9704edf7877be05a1c02.

Only the 1… records have the form this scanner generates. Even treating all 21,198,062 as valid P2PKH targets, an ideal-hash model gives at most about 4.35 × 10⁻³⁵ probability of an exact address match across the random control’s three million candidates. Per key, checking both forms gives at most about 2.90 × 10⁻⁴¹.

For comparison, zero flags in 1.5 million independent random-key trials gives an approximate 95% upper bound of 2 × 10⁻⁶ per key by the rule of three. That empirical bound is roughly thirty-five orders of magnitude above the ideal-model probability. A short run cannot validate such a tiny rate. This statistical statement applies to the random control; the other tiers enumerate specified sets.

All results below share the same coverage: two legacy P2PKH forms at the snapshot date. The scanner does not generate the other output types in the table or request current balances for offline misses.

Tier 1: patterned integers

Start with small integers, repeated digits, powers of two and ten, and dates. These are the obvious guesses on the first pages of a key directory. Separate explorer checks found the following histories for uncompressed addresses:

Confirmed-chain figures from Blockstream, rechecked October 16, 2026. Received amounts are rounded; the linked explorers show later state.

key = 1 had received about 7.85 BTC. Every address in the table had a transaction history and a zero balance when checked. These figures show that the keys are publicly discoverable; they do not identify who moved the funds or how quickly.

The full patterned run checked 1,007,440 keys: integers from 1 to 1,000,000, plus the other patterns and dates from the genesis block through October 13,

1. It found six control-set addresses, corresponding to keys 1, 2, and 3 in both public-key encodings. The explorer confirmed those were empty. Funded-snapshot flags: zero.

Tier 2: brainwallet phrases

A traditional brainwallet sets private key = SHA-256(passphrase). The hash produces a full-length value. The secret choices still come from the phrase selection process, and familiar phrases are easy to try:

Confirmed-chain figures from Blockstream, rechecked October 16, 2026. Received amounts are rounded; the linked explorers show later state.

The xkcd phrase correct horse battery staple had received nearly 16 BTC. password had 45,028 transactions. A published example phrase has had a rather unfortunate career as a secret. The transaction counts do not let us assign an entropy value to an individual phrase; they show its public history.

The dictionary run hashed all 104,334 words in the system dictionary and checked both P2PKH forms. It found six control-set addresses, confirmed empty, and zero funded-snapshot flags. The later explorer checks above are separate from the run’s October 13 snapshot check.

Tier 3: a synthetic small-seed generator

The weak_rng rule seeds Python’s Mersenne Twister, random.Random, with each integer in a selected range. It is a deliberately constrained model. It does not implement a mnemonic, PBKDF2, or BIP32, and cannot reconstruct the Milk Sad or Trust Wallet candidate sets. Those pipelines have different per-candidate costs and derivation paths.

We exhausted all 16,777,216 seeds in a 24-bit space. Checking both address forms took 675.6 seconds, about 11.3 minutes, at 24,833 keys/s on one core. The run produced zero funded-snapshot flags.

Scaling that indexed workload to all 2³² seeds gives about 48 continuous hours on the same core. This is a projection for the synthetic model, rather than a benchmark of a historical incident. The absence of funded matches does not make a small seed space safe or establish that a real incident had no victims.

Four candidate rules, one snapshot

The control addresses show that the scanner recognizes selected known cases. The snapshot results establish no matches within the coverage defined above. They do not measure how common weak wallets are or whether other output types controlled by these keys hold funds.

The useful distinction is the work required to enumerate each candidate set. A long key can come from a small, searchable source. Good key-generation randomness addresses that risk, while safe signing and private backups address later failures.

Part 4 examines the documented incidents and adds an experiment with a known synthetic target population. That lets us predict an observable match count and compare it with a completed run.

Reproducing the inputs

The scanner guide explains the run options and index construction. The dictionary hash below was captured after the run: the available file has 104,334 lines and predates it, but the original log did not record its hash. That limits what can be established about the original input bytes.

Run these commands from the root of the companion entropy-lab repository. Use a byte-identical wordlist for the same dictionary candidates; the command rejects a hash mismatch. Random draws, timings, and explorer responses will differ.

python -m pip install -r requirements.txt
# Throughput control against the built-in address set; no chain check.
python -m research.scan --tier random_control --count 1500000
# Build and verify the dated snapshot index, then screen both P2PKH forms.
python -m research.snapshot_profile Bitcoin_addresses_October_13_2026.txt.gz
python -m research.index build Bitcoin_addresses_October_13_2026.txt.gz funded_2026-10-13.idx
python -m research.index verify funded_2026-10-13.idx
python -m research.scan --tier random_control --count 1500000 \
    --index funded_2026-10-13.idx --online-verify
# The three enumerated candidate sets.
python -m research.scan --tier patterned --limit 1000000 --end-date 2026-10-13 \
    --index funded_2026-10-13.idx --online-verify
python -m research.scan --tier brainwallet --wordlist /usr/share/dict/words \
    --wordlist-sha256 9e66281f7e51445eab6857488ff6e3d768afffadb7fb1adbef5e4617bee4a53b \
    --index funded_2026-10-13.idx --online-verify
python -m research.scan --tier weak_rng --seed-bits 24 --count 16777216 \
    --index funded_2026-10-13.idx --online-verify
# Check address derivation against known vectors.
python -m research.btckit

To see what those words protect, we need to follow the derivation. Recovering one private key and recovering the root of a wallet are different jobs.

From entropy to a key tree

Bitcoin Improvement Proposal 39 (BIP39) defines a mnemonic that encodes the initial entropy and a checksum. It then feeds a key-derivation function, whose output supplies BIP32’s hierarchical deterministic (HD) key tree:

PBKDF2 is Password-Based Key Derivation Function 2; here it uses HMAC-SHA512. The BIP39 specification defines the conversion, including UTF-8 NFKD normalization of the mnemonic and passphrase before deriving the seed.

A path such as m/44'/0'/0'/0/0 selects one child private key from that tree. Its public key and receiving address follow from that child, using the derivation in Part 1.

Each word selects one of 2,048 entries and therefore encodes 11 bits. The English list runs from abandon to zoo, with unique first four letters. The checksum length is ENT/32, where ENT is the initial entropy length. For BIP39’s allowed 128–256 bits, in steps of 32, the combined bit string gives exactly five supported word counts.

The checksum supplies error detection, not entropy. Only one in 16 uniformly chosen 12-word strings passes it; for 24 words the fraction is one in 256. An enumerator can start with entropy values and calculate the checksum, so these bits do not add secret choices to search.

The optional passphrase changes the seed. It is sometimes called the “25th word,” but can be an arbitrary string. Every passphrase produces a wallet, including a typo. That makes exact recovery of the passphrase part of the backup problem.

The 512-bit output does not add entropy

Hold the passphrase and derivation path fixed. Twelve uniformly generated words supply 2¹²⁸ possible mnemonic inputs, and at most that many values for a particular child key. Twenty-four words supply 2²⁵⁶ inputs. Deterministic mappings can collide, so those counts do not prove that every scalar is reachable. Varying the path changes the question again: one mnemonic generates many child keys.

Both lengths produce a seed in the same 512-bit format. The longer output does not create more input uncertainty. A separately chosen secret passphrase can add uncertainty; more output bytes cannot. The same applies to a broken source: recording 24 words from a generator with only a few predictable inputs does not repair it.

Guessing twelve words

Part 1 used a generous rate of 10¹² raw keys per year per core. If complete mnemonic candidates could be checked at that rate, exhausting the 12-word space would take:

2^128 / 10^12 ≈ 3.4 × 10^26 years

This is a scale comparison, not a mnemonic benchmark. The scanner does not measure PBKDF2 or BIP32, and checking multiple paths adds work. Different implementations and hardware need their own measurements.

Even a trillion-fold speedup over the assumed one-core rate leaves about 3.4 × 10¹⁴ years, more than twenty thousand times the current age of the universe. Twelve uniformly generated words leave a large classical search margin. Twenty-four make root-secret guessing vastly harder still.

Recovering one child key

An exposed secp256k1 public key permits a different attack. Generic discrete-log recovery takes roughly 2¹²⁸ group operations, regardless of mnemonic length. Typical Pay-to-Public-Key-Hash (P2PKH) and Pay-to-Witness-Public-Key-Hash (P2WPKH) spends reveal public keys; Taproot exposes an output public key on receipt. Recovering the corresponding secret can compromise that output. It generally does not reveal the mnemonic or every other key.

BIP32 has a specific exception. A parent extended public key (xpub, including the chain code), together with a descendant private key connected entirely by non-hardened steps, can reveal the parent extended private key and its subtree. Hardened derivation blocks that route across its boundary. Compromising one account therefore does not automatically recover the master seed or other hardened accounts. BIP32 documents the implications.

The curve’s roughly 128-bit classical security describes the individual exposed public key. It does not erase the extra resistance that 24 words give the wallet’s root secret against mnemonic guessing.

Backup length and secret handling

Twenty-four uniformly generated words provide more margin against seed search. Some of that margin may remain after a partial leak, depending on exactly what became known. Twelve words give a shorter backup with a still large classical search space. For either length, a backup has to remain readable, recoverable, and private.

A copied complete mnemonic removes its guessing margin. The reported implant in Part 0 would not need more computing power to copy 24 words instead of 12. A separate, uncompromised passphrase changes what the words alone unlock. Its protection depends on how it was chosen and kept, rather than on calling it another word.

Before seed words: wallet.dat

A Satoshi-era wallet did not use twelve BIP39 words. The standards came later:

A genuine Satoshi-era wallet is a bag of individually generated keys in a wallet.dat. Anyone offering “Satoshi’s 12 words” is selling a story.

Both designs depend on unpredictable generation. Neither excuses unsafe signing or a copied backup. Part 3 tests what happens when the candidate generator starts with small or human-chosen spaces.

The site calculates each page when you ask for it. Understanding that small trick explains why displaying a keyspace is easy and searching it is not.

A private key is a number

A Bitcoin private key is an integer from 1 to:

115792089237316195423570985008687907852837564279074904382605163141518161494336

The upper bound is n − 1, where n is the order of the secp256k1 elliptic curve group. Valid keys satisfy 1 ≤ k < n; the range is just under 2²⁵⁶. Multiply the curve’s generator by that integer to get a public key. Hash and encode the public key to obtain a legacy Pay-to-Public-Key-Hash (P2PKH) address. The forward calculation is cheap. Recovering the secret from a public key or address is computationally infeasible under the usual classical models.

The directory uses the forward calculation. A page number selects a short run of integers, and the server derives their addresses. Every key is “already there” in the same sense that every integer is already on the number line. The site is a pocket calculator wearing a trench coat.

Here is the public-key derivation and the hash used in a legacy address:

import hashlib
from coincurve import PrivateKey


def hash160(data):
    sha256 = hashlib.sha256(data).digest()
    return hashlib.new("ripemd160", sha256).digest()


secret = 1  # Any integer in [1, n).
pub = PrivateKey.from_int(secret).public_key.format(compressed=False)
pubkey_hash = hash160(pub)
# P2PKH address = Base58Check(0x00 || pubkey_hash)

For secret = 1, the uncompressed public-key form gives 1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm. Part 3 checks its rather busy transaction history. The number is a valid key; choosing it as a secret is another matter.

That distinction runs through the series. Uniform selection across the valid range supplies about 256 bits of source entropy. A fixed algorithm starting from a 32-bit seed reaches at most 2^32 outputs, however long the resulting key looks. Part 0 introduces that difference between output length and input uncertainty.

Storing the directory

The range contains about:

2^256 ≈ 1.16 × 10^77 keys

One byte per key would already require about 10⁷⁷ bytes. An actual key-and-address record would need much more. No useful storage plan starts there.

Calculating a requested page avoids the storage problem. It gives no shortcut to finding a particular secret: the server still has to choose which page to calculate. That is where the size of the range becomes inconvenient.

Searching instead

On one laptop core, the companion scanner derives both legacy P2PKH address forms at about 31,000 keys/s. Loading the funded-address index and screening both forms brings the measured control rate to about 28,000 keys/s. Round up generously to 10¹² keys per year per core:

The mnemonic row borrows the raw-key rate to show scale. It assumes uniform generation, a fixed passphrase, and specified derivation paths. A real mnemonic search also performs Password-Based Key Derivation Function 2 (PBKDF2) and BIP32 derivation; this project has not measured that pipeline.

The universe is about 1.4 × 10¹⁰ years old. Exhausting even the 12-word space at this assumed rate takes roughly 10¹⁶ times that long. A million cores and a million-fold speedup remove twelve orders of magnitude. There are still plenty left.

We ran a small random search anyway. The control generated 1,500,000 keys, derived both P2PKH forms, and screened the resulting three million addresses against the 57,205,029-address snapshot dated October 13, 2026. There were zero index flags, so the run made no live explorer lookups.

Of the snapshot entries, 21,198,062 have the legacy 1… prefix. Treat every one as a valid P2PKH target and assume ideal address hashes. The probability of any exact address match is then at most approximately:

3,000,000 × 21,198,062 / 2^160 ≈ 4.35 × 10^-35

Zero is the expected observation. It applies to those two address forms in that snapshot. Part 3 explains the prefix index and why a miss says nothing about other output types or a later balance.

Which secret, and how many targets?

Exhausting a range is only one attack model. Two distinctions affect the cost:

An exposed public key permits a discrete-log attack. A generic attack such as Pollard’s rho needs roughly √n ≈ 2¹²⁸ group operations on secp256k1. That is about 128 bits of classical security for an exposed public key. Recovering that key’s secret generally does not recover its mnemonic or the wallet’s whole key tree. BIP32 treats those properties separately.

Finding any target can be easier than finding one specified target. Suppose there were 2²⁶ distinct, uniformly generated 12-word mnemonics, all using the fixed passphrase and paths under search. Finding any one would take about 2¹²⁸ / 2²⁶ = 2¹⁰² guesses on average, or roughly 10¹⁹ years at our assumed rate. The address dump does not establish that population: an address count tells us neither how many distinct mnemonic-backed wallets exist nor their derivation paths.

For a different example, uniformly generated raw keys matching any of 2²⁶ P2PKH address hashes would take about 2¹⁶⁰ / 2²⁶ = 2¹³⁴ trials. That is an address-hash search. Its work units differ from the group operations in a discrete-log attack and the full derivations in a mnemonic search.

The smaller spaces people actually chose

Real key-guessing attacks exploit secrets drawn from much smaller populations: short seeds, unsuitable pseudorandom generators, and human-chosen phrases. Other failures occur later. A repeated signing nonce can expose a strong key through signature algebra; a copied recovery phrase needs no search at all.

Part 2 follows the normal wallet generation stack and the 12-versus-24-word question. Then Part 3 measures four candidate-generation rules against the snapshot, and Part 4 examines documented randomness failures and a separate synthetic benchmark.

The scanner reads public blockchain data and never constructs or broadcasts a transaction. The other experiments use synthetic data. A funded match would be a statistic to report; it would not authorize spending from that address.

For years, we have heard stories about mysteriously drained wallets: the owner still had the hardware wallet, had not typed the recovery phrase into a website, and could not explain where the coins had gone. A copied backup or a phishing page could explain some cases. It was also easy to assume the owner had simply forgotten, or omitted, a mistake.

That mechanism could explain at least some of those older stories without anyone guessing a private key or the owner entering the phrase on a computer. It does not tell us what happened in any particular earlier case. It does show why “I never typed my seed anywhere” is not the end of the investigation.

After the news, a few colleagues asked me about websites claiming to contain a “database of all Bitcoin private keys.” If every possible key was already on a website, were our wallets safe? Was this how the money had disappeared?

Those questions are why I started this series. Before counting private keys, though, we need to establish what the device checks actually tell us.

What the incident reports establish

Incident account checked on October 15, 2026; the investigation remains open.

The reported losses involved devices bought through CryptoBilis, a Southeast Asian reseller listed in Ledger’s official directory 1, 4. Authorized status had not prevented the reported tampering. Ledger asked the reseller to pause sales and shipments, and the October 13 report describes the company’s findings and advice to affected buyers 1. I have not examined an affected device.

Bitquery’s investigation, marked verified October 15, estimates $102.0 million taken from 324 wallets on six chains, with $10 million in USDT frozen by Tether. These are Bitquery’s attribution and valuation of the flows, rather than a Ledger-confirmed victim count. Transaction traces show where funds went; they cannot establish where a physical device was altered.

Before you initialize the device

Ledger’s buying guide gives a practical starting point:

• Check the seller and package. Verify the seller against the manufacturer’s authorized list. If the package looks opened or altered, stop and contact support.
• Check the setup state. A new device should not arrive with a supplied PIN or recovery phrase. The device should generate the words during your setup; record them privately.
• Use the official software. Download the app from the manufacturer’s site or official app store and run Genuine Check. Never enter the recovery phrase into an app or website.

Genuine Check authenticates the Secure Element. It cannot detect an added spying implant when that original chip remains intact 3. Authorized sourcing, intact-looking packaging, and a passing check do not amount to a hardware audit.

Establishing whether a particular device is trustworthy requires examining its hardware, firmware, and handling of secrets. Here we can work through the wallet derivations and the mathematics of guessing: count the possible inputs, follow how they become keys, and calculate probabilities under stated assumptions. Those calculations do not certify an unknown implementation, but they let us explain precisely what correctly generated secrets protect against.

Randomness, entropy, and keeping a secret

For key generation, randomness has to make the choice unpredictable to an attacker. Appearance is a poor test. A string derived from a clock value can look just as untidy as one drawn from a secure source.

Entropy measures uncertainty. Four fair, independent coin flips have 16 equally likely outcomes: four bits of entropy. Another independent fair flip doubles the possibilities. For N equally likely outcomes, entropy is log2(N) bits:

The qualifications do work here. Biased or dependent flips do not supply one new bit each. Information already available to an attacker reduces the uncertainty that remains. Counting possible outputs can therefore overstate the difficulty of guessing a secret; NIST’s entropy-source guidance uses measures such as min-entropy to account for this 6.

Suppose a fixed algorithm expands a 32-bit seed into a 256-bit key. It can produce at most 2^32 different keys. Hashing the seed, printing more digits, or turning it into words cannot add input possibilities. The next question is how much work the attacker must do to test each possibility.

Deterministic generation is normal in cryptography. A cryptographically secure pseudorandom number generator (CSPRNG) expands secret state into outputs designed to resist prediction, provided the state has enough entropy and the implementation is sound 7. Python’s secrets module uses the operating system’s secure source; random serves simulation 8. Neither can make a small, guessable initial seed impossible to enumerate.

Then there is confidentiality. A correctly generated secret can still be copied from a display, recovery entry, or backup. Once the attacker has it, there is nothing left to guess. The reported implant crossed that boundary without needing to change the key-generation algorithm.

Five posts, three failure stages

I wrote the scripts accompanying this series to put numbers behind that question. The companion repository, entropy-lab, contains the scanner, RNG models, and synthetic benchmarks. The series starts by explaining the key directory, follows the wallet-generation stack, and ends with measured searches:

Keep three stages separate as we go. Weak generation makes a key guessable. A signing failure can expose an otherwise strong key. Copying the recovery secret bypasses both. Calling all three “broken cryptography” hides the part that needs fixing.

Public keys on demand, public addresses on disk

The raw ingredients sound alarming. keys.lol displays private keys and their addresses. The retired directory.io keeps its original first page as a demonstration. Public datasets list funded addresses and historical address use 5. Put a candidate generator on one side and a funded-address list on the other, and you have a search pipeline.

The active directory calculates its pages on demand. It has not obtained anyone’s secret. Part 1 shows the arithmetic; the page count alone needs 75 digits.

For Part 3, the funded-address snapshot contains 57,205,029 entries, dated October 13, 2026. The scanner derives compressed and uncompressed legacy Pay-to-Public-Key-Hash (P2PKH) addresses for each candidate key. Of the snapshot entries, 21,198,062 start with 1, the legacy P2PKH prefix; this count classifies prefixes without validating checksums.

The four runs covered 1.5 million random keys, just over a million patterned integers, 104,334 dictionary brainwallets, and all 16,777,216 seeds in a synthetic 24-bit generator. None produced a funded-snapshot prefix flag. Known, drained addresses served as separate positive controls. Part 3 explains the index, its verification limit, and why this result covers only the tested address forms at that snapshot date.

Protecting the secret after setup

The reported implant gives us a useful way to read the rest of the series. Entropy protects against guessing. Every point where a secret appears needs protection against copying.

Later recovery entries, displays, and backups create further opportunities to copy the phrase. For CryptoBilis purchases, the October reports relay Ledger’s advice to leave unused devices uninitialized and move assets from used devices to a new device with a newly generated phrase 1. Consult current manufacturer guidance before acting on this continuing incident.

Adding words does not protect a complete phrase after someone has copied it. A separately protected BIP39 passphrase changes what those words alone can unlock; Part 2 follows that distinction through the derivation stack.

There is an observable result at the other end of the series. A synthetic benchmark made 50 billion probes against a planted synthetic target set and counted 174 matches, against 186.26 expected. The idealized 128- and 256-bit controls each made 50 billion probes and counted zero. Part 4 explains why the planted count is useful evidence, while the zero counts cannot certify a real entropy source.

First, the website that claims to have all the keys.

Sources

1. CoinDesk, October 13, 2026 — Ledger’s reported findings on the CryptoBilis hardware implant.
2. Bitquery — Ledger CryptoBilis on-chain investigation, figures marked verified October 15, 2026.
3. Ledger — Buying guidance and the limits of Genuine Check.
4. Ledger — Authorized reseller directory, rechecked October 16, 2026.
5. Public address datasets — funded addresses (maintainer’s project thread) and historical address use.
6. NIST — SP 800-90B: entropy-source assessment.
7. NIST — SP 800-90A Rev. 1: deterministic random-bit generators.
8. Python 3.13 — secrets documentation.

Now we need to go deeper. The firmware has scheduler code, mutexes with ownership tracking, a rule engine with allocation, programming, and commit states, and a pool allocator with sentinel values. All of these are built around structs – carefully designed data structures with fields at specific offsets, linked together with embedded list nodes.

The companion RTOS models scheduler data structures but does not save and restore CPU context. Its task entry functions are called directly. That still gives us the list and field-access patterns we need to recover.

But when the compiler strips everything down to a flat binary, all the type information vanishes. The struct names are gone. The field names are gone. The only evidence that a 60-byte task control block ever existed is a pattern of memory accesses: lw v0, 0(a0) … lw v1, 4(a0) … sw v0, 0x20(a0).

Recovering those structs from raw offsets is one of the hardest – and most rewarding – skills in firmware reverse engineering. Let’s work through it systematically.

Follow along: Download the sample firmware and source bundle, then run tar xf advanced-sample.tar.gz and cd more_complex_firmware. Use firmware.bin as the analysis target; the companion source and ELF let you check the recovered layouts and instruction addresses afterward.

The Problem: What Decompilation Leaves Unresolved

Decompilation lifts instructions into C-like code, but it cannot restore the stripped type and field names. Here is a simplified reconstruction of the scheduler in our binary, with anonymous names retained. It is an illustration, not a verbatim Ghidra capture:

void FUN_80000c10(void)
{
    int *piVar1 = *(int **)0x8008008c;
    if (piVar1 == (int *)0x8008008c)
        return;

    int *piVar2 = (int *)((char *)piVar1 - 0x20);
    if (piVar2 != *(int **)0x80080098) {
        /* Other state checks and branches omitted. */
        *(int **)0x80080098 = piVar2;
        *(int *)((char *)piVar1 - 0x1c) = 2;
        ++*(int *)((char *)piVar1 + 0x14);
        ++*(int *)((char *)piVar1 + 0x18);
    }
}

That’s the RTOS scheduler. Can you tell? Probably not. The function name and pointer names convey little, and every struct field access looks like *(ptr + offset). The meaning is still opaque.

But the offsets are real. Each one corresponds to a field in a data structure that the original developer carefully designed. Our job is to collect those offsets and reconstruct the struct definition. Here’s how.

Step 1: Collect Offsets From One Function

Let’s start with the scheduler function at 0x80000C10. From the disassembly:

80000c10:  lui   v1, 0x8008
80000c14:  lw    v0, 140(v1)        # load from global at 0x8008008C
80000c18:  addiu v1, v1, 140        # v1 = &list_head (0x8008008C)
80000c1c:  beq   v0, v1, ...        # if (list.next == &list) → empty
80000c20:  addiu a0, v0, -32        # a0 = list_entry - 0x20 → container!

Stop right there. That addiu a0, v0, -32 is the most important instruction in this function. It’s a container_of operation – subtracting 0x20 from a list node pointer to get back to the containing structure.

This tells us: some struct has a list_node field at offset +0x20. The list node was loaded from a global list head at 0x8008008C, and the function subtracts 32 bytes to get a pointer to the beginning of the struct.

Continuing through the function, we collect more offsets:

# After container_of (a0 points to struct base; v0 still points to its list node)
80000c3c:  lw    a2, 4(v1)          # Read field at +0x04 of current_task
80000c40:  beq   a2, a1, ...        # Compare field +0x04 against 2
80000c54:  sw    v1, -28(v0)        # v0 = struct+0x20, so -28 = +0x04
                                     # Write 2 to field +0x04 (state = RUNNING)
80000c58:  lw    v1, 20(v0)         # v0 = struct+0x20, so 20 = +0x34

This needs careful accounting. The variable v0 still points to the list node at offset +0x20, not the struct base. So:

• sw v1, -28(v0) → writes to struct + 0x20 - 28 = struct + 0x04
• lw v1, 20(v0) → reads from struct + 0x20 + 20 = struct + 0x34
• lw v1, 24(v0) → reads from struct + 0x20 + 24 = struct + 0x38
• lw v1, -20(v0) → reads from struct + 0x20 - 20 = struct + 0x0C
• lw a0, -16(v0) → reads from struct + 0x20 - 16 = struct + 0x10

After one function, we have this partial struct map:

Offset  Access   Operation              Likely meaning
------  ------   ---------              --------------
+0x00   ?        (not accessed here)
+0x04   R/W      compared to 2, set to 1/2   state field (enum?)
+0x0C   R        loaded, then jalr'd    function pointer!
+0x10   R        loaded as arg to jalr  argument to function
+0x20   list_node container_of(-0x20)   linked list node
+0x34   R/W      incremented            counter
+0x38   R/W      incremented            counter

Step 2: Type Inference From Operations

Each offset isn’t just a number – the operations performed on it tell you the field’s type:

Applying these rules to our offsets:

• +0x04: compared to constants 1 and 2, set to 1 or 2 → state enum (1=READY, 2=RUNNING)
• +0x0C: value loaded and used with jalr → function pointer (task entry point)
• +0x10: loaded as argument to the jalr’d function → callback argument (void *arg)
• +0x20: subtracted via container_of → list node (embedded in parent struct)
• +0x34, +0x38: incremented → counters (run_count, total_ticks?)

The counter at +0x34 advances when the selected task changes. The one at +0x38 advances whenever the scheduler selects that task, including repeated selections. These are scheduler counts; the accesses do not establish elapsed timer ticks.

Step 3: Cross-Function Struct Building

One function rarely touches all fields. To complete the picture, we need to look at every function that operates on the same struct. The rtos_task_create function at 0x80000900 is a goldmine – it initializes all fields:

# After finding free slot, s0 = pointer to struct
80000988:  sw    v0, 0(s0)          # +0x00 = task_id
80000990:  sw    v0, 4(s0)          # +0x04 = state (set to 1 = READY)
80000994:  sw    a3, 8(s0)          # +0x08 = priority (from arg)
80000998:  sw    a1, 12(s0)         # +0x0C = entry function pointer
8000099c:  sw    a2, 16(s0)         # +0x10 = argument
800009a0:  sw    zero, 20(s0)       # +0x14 = 0 (purpose unknown here)
800009a8:  sw    v0, 24(s0)         # +0x18 = fifth argument (purpose unknown here)
800009b4:  sw    zero, 28(s0)       # +0x1C = 0 (timer value)
800009c0:  sw    v1, 32(s0)         # +0x20 = run_list.next (list init)
800009c4:  sw    v1, 36(s0)         # +0x24 = run_list.prev (list init)
800009d0:  sw    v0, 40(s0)         # +0x28 = timer_list.next (list init)
800009d4:  sw    v0, 44(s0)         # +0x2C = timer_list.prev (list init)
800009d8:  sw    a0, 48(s0)         # +0x30 = name (string pointer)
800009dc:  sw    zero, 52(s0)       # +0x34 = run_count (init to 0)
800009e0:  sw    zero, 56(s0)       # +0x38 = total_ticks (init to 0)

The timer-tick path gives us evidence for one more field. Here a1 points to the task’s timer_list node at +0x28:

80000d34:  lw    v0, -12(a1)        # +0x28 - 12 = +0x1C
80000d3c:  addiu v0, v0, -1         # decrement timer value
80000d44:  sw    v0, -12(a1)        # write it back

That supports naming +0x1C ticks_remaining. We still cannot establish the meaning of +0x14 or +0x18 from these paths.

Now we can reconstruct the layout. The two list nodes each contain a next and prev pointer, so we can use this working type:

struct list_node {
    struct list_node *next;
    struct list_node *prev;
};

/* Recovered layout; some field names remain tentative. */
typedef struct {
    uint32_t    task_id;            /* +0x00 */
    uint32_t    state;              /* +0x04: 0=idle, 1=ready, 2=running, 3=blocked */
    uint32_t    priority;           /* +0x08: lower = higher priority */
    void       (*entry)(void *);    /* +0x0C: task entry function */
    void       *arg;                /* +0x10: argument to entry */
    uint32_t    field_14;           /* +0x14: initialized to 0 */
    uint32_t    field_18;           /* +0x18: from fifth argument */
    uint32_t    ticks_remaining;    /* +0x1C: decremented by timer tick */
    struct list_node run_list;      /* +0x20: ready/blocked queue link */
    struct list_node timer_list;    /* +0x28: timer queue link */
    const char *name;               /* +0x30: debug name string */
    uint32_t    run_count;          /* +0x34: selections that change current task */
    uint32_t    total_ticks;        /* +0x38: all selections, not elapsed ticks */
} task_t;  /* 60 bytes (0x3C) */

We just recovered a 60-byte task control block from raw memory offsets. No symbol table, debug info, or source code was needed for the layout.

Step 4: The Intrusive Linked List Pattern

Notice something about the list initialization at +0x20 and +0x28:

# Initializing run_list at +0x20:
800009c0:  sw    v1, 32(s0)         # run_list.next = &self.run_list
800009c4:  sw    v1, 36(s0)         # run_list.prev = &self.run_list

# Initializing timer_list at +0x28:
800009d0:  sw    v0, 40(s0)         # timer_list.next = &self.timer_list
800009d4:  sw    v0, 44(s0)         # timer_list.prev = &self.timer_list

Both list nodes are initialized to point to themselves. This is the signature of an intrusive doubly-linked list – the same pattern used by the Linux kernel’s list_head. An empty list node points to itself:

/* List initialization: node->next = node->prev = node */
void list_init(struct list_node *node) {
    node->next = node;
    node->prev = node;
}

The key insight is that the same struct has two different list nodes at different offsets:

• run_list at +0x20 threads the task into the ready queue or blocked queue
• timer_list at +0x28 threads the task into the timer expiry list

This is what makes intrusive lists powerful – and what makes them an RE nightmare. The same task can be on two different lists simultaneously, and each list uses a different container_of offset to get back to the task struct.

When you see addiu a0, v0, -0x20 in the scheduler, it’s doing container_of(node, task_t, run_list). When you see addiu a0, v0, -0x28 in the timer tick handler, it’s doing container_of(node, task_t, timer_list). Different offset, same struct.

Step 5: Another Struct – The Mutex

The mutex lock function at 0x80000DC8 gives us a second struct to reconstruct:

80000dd0:  lw    v0, 0(a0)          # +0x00: locked flag
80000de0:  lw    v0, 152(v0)        # load g_current_task
80000de4:  lw    v1, 4(a0)          # +0x04: owner pointer
80000de8:  bne   v1, v0, ...        # if (owner != current_task)
80000df0:  lw    v0, 8(a0)          # +0x08: nest_count
80000df4:  addiu v0, v0, 1          # nest_count++
80000df8:  sw    v0, 8(a0)          # +0x08: write back
  ...
80000e44:  sw    a1, 16(a0)         # +0x10: wait_list.prev = new_waiter
80000e48:  addiu a0, a0, 12        # +0x0C: &wait_list (list node offset)

The addiu a0, a0, 12 at 0x80000E48 tells us the mutex has a list_node at offset +0x0C. Collecting all the offsets:

typedef struct {
    uint32_t    locked;             /* +0x00: 0=free, 1=locked */
    void       *owner;              /* +0x04: owning task pointer */
    uint32_t    nest_count;         /* +0x08: recursive lock depth */
    struct list_node wait_list;     /* +0x0C: blocked tasks waiting */
    uint32_t    field_14;           /* +0x14: purpose not shown here */
} mutex_t;  /* 24 bytes */

Look at the relationship: the mutex’s wait_list at +0x0C links to the task’s run_list at +0x20. When a task blocks on a mutex, its run_list node is moved from the ready queue to the mutex’s wait list. The container_of offset is still -0x20 because the list node in the task struct is always at +0x20, regardless of which list it’s on.

Step 6: Packed Bitfields – The Rule Engine

Not all struct fields are simple integers. The rule engine uses packed bitfields – multiple values squeezed into a single 32-bit word. Look at this pattern from the rule commit function at 0x8000330C:

# Load field +0x10 of rule entry
80003388:  lw    v1, 16(v0)
# Mask off upper byte: v1 & 0xFF00
8000338c:  andi  v1, v1, 0xFF00
# Compare against 0x0200
80003390:  li    a0, 512
80003394:  bne   v1, a0, error

The code loads a 32-bit word from offset +0x10, masks it with 0xFF00, and compares the result to 0x0200. This means:

• Bits [15:8] of the word at +0x10 encode a state field
• State 0x02 means “PROGRAMMED” (the required state before committing)

Later in the same function:

# Clear bits [15:8] and set new state 0x03
800033f8:  ins   v0, zero, 0x8, 0x8   # Clear bits 15:8
800033fc:  ori   v0, v0, 0x300         # Set bits 15:8 = 0x03
80003400:  sw    v0, 16(v1)            # Write back

The MIPS ins (insert) instruction zeroes bits [15:8], then ori sets them to 0x03 (COMMITTED state). This is a classic read-modify-write on a packed bitfield.

From multiple functions, we can reconstruct the full packing:

Rule flags word at +0x10:
  Bits [2:0]   = partition index (0-7)    mask 0x0007
  Bits [7:3]   = priority (0-31)          mask 0x00F8
  Bits [15:8]  = state                    mask 0xFF00
                  0x00 = FREE
                  0x01 = ALLOCATED
                  0x02 = PROGRAMMED
                  0x03 = COMMITTED

Which gives us this rule entry struct:

typedef struct {
    uint32_t    type;               /* +0x00: AR=0, ID=1, AT=2 */
    uint32_t    match_lo;           /* +0x04: match range low */
    uint32_t    match_hi;           /* +0x08: match range high */
    uint32_t    action;             /* +0x0C: forwarding action */
    uint32_t    flags;              /* +0x10: packed [2:0]=part, [7:3]=pri, [15:8]=state */
    uint32_t    reserved;           /* +0x14 */
} rule_entry_t;  /* 24 bytes (0x18) */

The Method: A Systematic Approach

Let me distill this into a repeatable method:

1. Start with one function

Pick a function that accesses many fields – initializers and dump/debug functions are ideal because they touch every field sequentially.

2. Collect every offset

For each lw/sw instruction, record the base register and offset. Track which register points to the struct base vs. an interior pointer (like a list node). Watch out for compiler tricks like using v0 = struct + 0x20 and then accessing fields relative to that interior pointer.

3. Classify each field by operation

4. Cross-reference across functions

Find every function that accesses the same global array or passes the same struct pointer. Each function reveals different fields. The initializer shows the full layout; the scheduler shows the state transitions; the debug dump shows the display names.

5. Look for embedded list nodes

The container_of subtraction (addiu reg, reg, -N) is the telltale sign. The offset N tells you where the list node sits in the containing struct. If you see two different subtraction values for the same struct, it has two list nodes.

6. Verify struct size

Look for array access patterns. If the code does ptr + index * 60, the struct is 60 bytes. Multiplication by a non-power-of-2 constant is often visible as a shift-add sequence:

# Multiply index by 60 (= 4 * 15 = 4 * (16-1))
sll   v0, a0, 4        # v0 = index * 16
subu  v0, v0, a0       # v0 = index * 15
sll   v0, v0, 2        # v0 = index * 60

Or the compiler might use the mul instruction directly if available:

li    v0, 60
mul   v0, a0, v0       # v0 = index * 60

Either way, the struct size is the multiplication constant.

Recovered Structs: Summary

After analyzing all the RTOS, rule engine, and driver functions in our firmware, here’s what we recover:

/* 60 bytes - RTOS task control block */
typedef struct {
    uint32_t    task_id;            /* +0x00 */
    uint32_t    state;              /* +0x04 */
    uint32_t    priority;           /* +0x08 */
    void       (*entry)(void*);     /* +0x0C */
    void       *arg;                /* +0x10 */
    uint32_t    field_14;           /* +0x14: meaning not established */
    uint32_t    field_18;           /* +0x18: receives fifth argument */
    uint32_t    ticks_remaining;    /* +0x1C */
    struct list_node run_list;      /* +0x20 */
    struct list_node timer_list;    /* +0x28 */
    const char *name;               /* +0x30 */
    uint32_t    run_count;          /* +0x34 */
    uint32_t    total_ticks;        /* +0x38 */
} task_t;

/* 24 bytes - Mutex with ownership */
typedef struct {
    uint32_t    locked;             /* +0x00 */
    task_t     *owner;              /* +0x04 */
    uint32_t    nest_count;         /* +0x08 */
    struct list_node wait_list;     /* +0x0C */
    uint32_t    field_14;           /* +0x14: meaning not established */
} mutex_t;

/* 24 bytes - Rule entry with packed flags */
typedef struct {
    uint32_t    type;               /* +0x00 */
    uint32_t    match_lo;           /* +0x04 */
    uint32_t    match_hi;           /* +0x08 */
    uint32_t    action;             /* +0x0C */
    uint32_t    flags;              /* +0x10: packed bitfield */
    uint32_t    reserved;           /* +0x14 */
} rule_entry_t;

The layouts follow from memory accesses, pointer arithmetic, and how values are used across functions. Field names remain hypotheses until callers, strings, or observed behavior support them.

Exercises

1. Find the semaphore struct: The firmware has rtos_sem_wait at 0x80000F98 and rtos_sem_post at 0x80001034. Disassemble these functions and reconstruct the semaphore struct. (Hint: it’s similar to mutex_t but with a count field instead of an owner.)

2. Recover port_config_t: The port initialization at 0x80002830 sets up an array of 8 port structures with 48-byte stride (see the addiu v0, v0, 48 loop increment). Map all the fields.

3. Map the route entry: The routing module uses structs with a list node at +0x14. Find the container_of subtraction that reveals this offset and reconstruct the full routing entry.

4. Automate offset collection: Write a Python script using Capstone to disassemble a function and collect its lw/sw offsets. Track the struct pointer through copies from $a0-$a3 into other registers and through interior pointers such as struct + 0x20; normalize each access back to the struct base. Report an offset as unknown when register provenance is lost.

What’s Next

We’ve been doing all of this manually – reading disassembly, tracking registers, collecting offsets. It works, but it’s slow. For a 38 KB firmware, manual analysis is feasible. For a 1.5 MB production firmware with 4,000+ functions, you need better tools.

In the next post, we will use radare2 to query table users and callers, save recovered names, and inspect its function boundaries. We will compare its output with Ghidra and Capstone on the same binary, including the functions and types that automatic analysis gets wrong.

This is Part 2 of “Crypto Tables, Struct Ghosts, and Other Secrets Hidden in Firmware.”

Next: Part 3 — Radare2, Ghidra, and Other Ways to Tear Apart a Binary.

The new sample contains AES-128, SHA-256, two CRC routines, pool allocation, rule handling, memory-mapped I/O, and task scheduler code. We will examine the runtime pieces later. First, we can use the bytes in its constant tables to find the algorithm implementations.

Follow along: Download the sample firmware and source bundle, then run tar xf advanced-sample.tar.gz and cd more_complex_firmware. The bundle includes firmware.bin and the tools/entropy_scan.py script used below. The binary is the artifact we analyze; the source is there to check our conclusions afterward.

Tables as Search Clues

Some algorithm implementations leave recognizable tables in the binary. This AES implementation stores a 256-byte S-box, SHA-256 stores 64 round constants, and the CRC-32 routine uses a 1024-byte lookup table. Those bytes remain visible after the linker removes symbols and section headers from the distributed image.

A complete table match gives us a strong lead. We still need code references to establish which functions use it, and a matching table alone does not tell us every parameter of a checksum. Other implementations may calculate the same values at runtime or use hardware instead of storing a table.

Step 1: Scan Entropy

Before searching for a known pattern, we can rank parts of the binary by Shannon entropy. Repeated padding has low entropy; tables, compressed data, and encrypted data can be high. Code and strings vary enough that fixed ranges would be misleading. Entropy gives us places to inspect, not labels for those places.

A complete AES S-box contains every byte value exactly once, so its entropy is 8.0 bits per byte. A 256-byte window that crosses a table boundary measures a mixture and gives a different result.

The bundled tools/entropy_scan.py computes entropy over non-overlapping 256-byte windows:

import math
import sys

def entropy(data):
    """Shannon entropy in bits per byte."""
    freq = [0] * 256
    for b in data:
        freq[b] += 1
    ent = 0.0
    for f in freq:
        if f > 0:
            p = f / len(data)
            ent -= p * math.log2(p)
    return ent

data = open(sys.argv[1], 'rb').read()
window = 256

results = []
for offset in range(0, len(data) - window + 1, window):
    chunk = data[offset:offset + window]
    results.append((offset, entropy(chunk)))

results.sort(key=lambda x: -x[1])

print(f"{'Offset':>10s}  {'Address':>12s}  {'Entropy':>8s}")
print("-" * 36)
for offset, ent in results[:15]:
    addr = 0x80000000 + offset
    print(f"  0x{offset:06X}    0x{addr:08X}    {ent:.4f}")

Running this on our 38 KB firmware:

$ python3 tools/entropy_scan.py firmware.bin

    Offset       Address   Entropy
------------------------------------
  0x007F00    0x80007F00    7.4609
  0x008000    0x80008000    7.3113
  0x007C00    0x80007C00    7.2820
  0x007B00    0x80007B00    7.1560
  0x007A00    0x80007A00    6.3438
  0x008100    0x80008100    6.1394
  0x008E00    0x80008E00    5.6130
  0x006E00    0x80006E00    5.5393
  0x007D00    0x80007D00    5.4905
  0x001800    0x80001800    5.3587
  0x004200    0x80004200    5.3427
  0x008C00    0x80008C00    5.3393
  0x002200    0x80002200    5.3293
  0x001600    0x80001600    5.3251
  0x003300    0x80003300    5.2704

The four highest windows fall between 0x7B00 and 0x80FF. That is a useful place to look for tables. The S-box begins at 0x7F7C, so the window starting at 0x7F00 includes other data; its measured entropy is 7.4609, even though the aligned 256-byte S-box reaches 8.0.

Start with the best-known pattern in that range.

Step 2: Match the AES S-Box

The Rijndael S-box begins with four recognizable bytes:

63 7C 77 7B

These are the substitution values for inputs 0x00 through 0x03. They give us a search pattern, not proof on their own. We will check the whole table after finding a candidate.

Let’s search:

$ xxd firmware.bin | grep "637c 777b"
00007f70: ba77 d626 e169 1463 5521 0c7d 637c 777b  .w.&.i.cU!.}c|w{

One hit at offset 0x7F7C. Let’s look at the full 256-byte table:

$ xxd -s 0x7F7C -l 256 firmware.bin
00007f7c: 637c 777b f26b 6fc5 3001 672b fed7 ab76  c|w{.ko.0.g+...v
00007f8c: ca82 c97d fa59 47f0 add4 a2af 9ca4 72c0  ...}.YG.......r.
00007f9c: b7fd 9326 363f f7cc 34a5 e5f1 71d8 3115  ...&6?..4...q.1.
00007fac: 04c7 23c3 1896 059a 0712 80e2 eb27 b275  ..#..........'.u
00007fbc: 0983 2c1a 1b6e 5aa0 523b d6b3 29e3 2f84  ..,..nZ.R;..)./.
00007fcc: 53d1 00ed 20fc b15b 6acb be39 4a4c 58cf  S... ..[j..9JLX.
00007fdc: d0ef aafb 434d 3385 45f9 027f 503c 9fa8  ....CM3.E...P<..
00007fec: 51a3 408f 929d 38f5 bcb6 da21 10ff f3d2  Q.@...8....!....
00007ffc: cd0c 13ec 5f97 4417 c4a7 7e3d 645d 1973  ...._.D...~=d].s
0000800c: 6081 4fdc 222a 9088 46ee b814 de5e 0bdb  `.O."*..F....^..
0000801c: e032 3a0a 4906 245c c2d3 ac62 9195 e479  .2:.I.$\...b...y
0000802c: e7c8 376d 8dd5 4ea9 6c56 f4ea 657a ae08  ..7m..N.lV..ez..
0000803c: ba78 252e 1ca6 b4c6 e8dd 741f 4bbd 8b8a  .x%.......t.K...
0000804c: 703e b566 4803 f60e 6135 57b9 86c1 1d9e  p>.fH...a5W.....
0000805c: e1f8 9811 69d9 8e94 9b1e 87e9 ce55 28df  ....i........U(.
0000806c: 8ca1 890d bfe6 4268 4199 2d0f b054 bb16  ......BhA.-..T..

The 256 bytes starting at firmware address 0x80007F7C match the Rijndael S-box. The first row is 63 7C 77 7B F2 6B 6F C5 30 01 67 2B FE D7 AB 76, as specified in FIPS 197. Checking all 256 bytes matters more than finding the four-byte prefix.

This implementation also stores an inverse S-box, which can be used for decryption. Its first four bytes are 52 09 6A D5:

$ xxd firmware.bin | grep "5209 6ad5"
00007e7c: 5209 6ad5 3036 a538 bf40 a39e 81f3 d7fb  R.j.06.8.@......

It starts at 0x7E7C, exactly 256 bytes before the forward S-box. This build placed the tables back-to-back.

We can check the relationship without trusting either four-byte prefix:

data = open('firmware.bin', 'rb').read()
inverse = data[0x7E7C:0x7F7C]
forward = data[0x7F7C:0x807C]
assert len(set(forward)) == 256
assert all(inverse[forward[value]] == value for value in range(256))

Without reading a MIPS instruction, we have two full AES table matches at firmware addresses 0x80007E7C (inverse) and 0x80007F7C (forward). That points to AES code with data for both directions. Later we can follow references to confirm how the firmware uses those tables.

Step 3: Locate SHA-256 Constants

SHA-256 uses 64 round constants, each derived from the fractional parts of the cube roots of the first 64 prime numbers. The first is 0x428A2F98. We will check the following values too; one 32-bit word is too short to identify the table reliably.

In a little-endian MIPS binary, 0x428A2F98 is stored as bytes 98 2F 8A 42. Let’s search:

$ xxd firmware.bin | grep "982f 8a42"
00008080: 982f 8a42 9144 3771 cffb c0b5 a5db b5e9  ./.B.D7q........

Offset 0x8080. Let’s verify by checking the first four constants:

import struct

data = open('firmware.bin', 'rb').read()
offset = 0x8080

# Read first 4 SHA-256 round constants
for i in range(4):
    val = struct.unpack('<I', data[offset + i*4 : offset + i*4 + 4])[0]
    print(f"K[{i}] = 0x{val:08X}")

K[0] = 0x428A2F98
K[1] = 0x71374491
K[2] = 0xB5C0FBCF
K[3] = 0xE9B5DBA5

These first four values match the SHA-256 specification. The candidate table occupies 256 bytes (64 constants × 4 bytes each), from 0x8080 to 0x8180. Following references to it will confirm which function uses the values.

SHA-256 also needs initial hash values – eight constants derived from the square roots of the first eight primes. The first is 0x6A09E667. You might expect these to sit right after the K[] table, but let’s search:

target = struct.pack('<II', 0x6A09E667, 0xBB67AE85)
if data.find(target) == -1:
    print("H0[] not found as contiguous table!")

H0[] not found as contiguous table!

Where did the initial hash values go? The source declares an eight-word array, but this build loads its values as immediate instructions. The larger K[] array remains in read-only data. The result depends on the compiler and optimization settings; the absence of a contiguous table does not mean SHA-256 lacks an initial state.

If we disassemble the sha256_init function (at 0x80006E28), we can see why:

80006e28:  lui   v0, 0x6A09        # H0[0] = 0x6A09E667
80006e2c:  ori   v0, v0, 0xE667
80006e30:  sw    v0, 0(a0)
80006e34:  lui   v0, 0xBB67        # H0[1] = 0xBB67AE85
80006e38:  ori   v0, v0, 0xAE85
80006e3c:  sw    v0, 4(a0)
80006e40:  lui   v0, 0x3C6E        # H0[2] = 0x3C6EF372
80006e44:  ori   v0, v0, 0xF372
80006e48:  sw    v0, 8(a0)
  ...and so on for all 8 values

Here the first three constants use lui/ori pairs: load the upper 16 bits, then OR in the lower 16. There is no table reference for these values. They are embedded in the code, not in .rodata.

Table scanning misses constants embedded in instructions. The lui 0x6A09 and ori 0xE667 pair is still searchable, but now we have to read code.

Our crypto map:

Step 4: Identify the CRC-32 Table

CRC-32 is common in firmware for integrity checks. This implementation stores a 1024-byte table for the reflected polynomial 0xEDB88320; its second entry is 0x77073096.

$ xxd firmware.bin | grep "9630 0777"
00007a70: 0000 0000 9630 0777 2c61 0eee ba51 0999  .....0.w,a...Q..

Offset 0x7A70. The first four entries confirm it:

[  0] 0x00000000    <- CRC of 0x00
[  1] 0x77073096    <- CRC of 0x01
[  2] 0xEE0E612C    <- CRC of 0x02
[  3] 0x990951BA    <- CRC of 0x03

You can verify the polynomial by computing entry [1] yourself:

def crc32_single(byte, poly=0xEDB88320):
    """Compute one CRC-32 table entry."""
    crc = byte
    for _ in range(8):
        if crc & 1:
            crc = (crc >> 1) ^ poly
        else:
            crc >>= 1
    return crc

assert crc32_single(0) == 0x00000000
assert crc32_single(1) == 0x77073096
assert crc32_single(2) == 0xEE0E612C

The table identifies the reflected polynomial. It does not identify the initial value or final XOR. In this firmware, inspecting crc32_calc shows 0xFFFFFFFF for both, which matches the CRC-32/ISO-HDLC parameter set used by Ethernet, ZIP, and PNG. The table was the lead; the function settles the variant.

Step 5: Find a CRC Without a Table

Not every algorithm leaves a table. The other CRC routine computes its result bit by bit:

/* C-like reconstruction of the function at 0x80006280 */
uint16_t func_80006280(const void *data, uint32_t length)
{
    const uint8_t *p = (const uint8_t *)data;
    uint16_t crc = 0xFFFF;
    uint32_t i;
    int bit;

    for (i = 0; i < length; i++) {
        crc ^= ((uint16_t)p[i]) << 8;
        for (bit = 0; bit < 8; bit++) {
            if (crc & 0x8000) {
                crc = (crc << 1) ^ 0x8005;
            } else {
                crc <<= 1;
            }
        }
    }
    return crc;
}

No table – you’d need to actually disassemble and decompile to find this one. The XOR constant 0x8005 identifies the polynomial, but not the CRC variant by itself. This function starts with 0xFFFF, processes each byte most-significant bit first, and returns without a final XOR. Those parameters identify CRC-16/CMS: it returns 0xAEE7 for the check string 123456789.

CRC-16/USB uses the same polynomial but reflects input and output and applies a final XOR of 0xFFFF; its check value is 0xB4C8. You can identify the bit-by-bit CRC loop by looking for:

1. A loop of 8 iterations (bit-by-bit processing)
2. A test of the MSB (& 0x8000)
3. An XOR with a constant after the shift

The constant tells you the polynomial. The loop structure tells you it’s CRC. The initial value, bit order, and final XOR distinguish this variant from others that share the polynomial.

When you find a bit-by-bit CRC without a table, match the full parameter set against Greg Cook’s catalogue of CRC algorithms, rather than matching the polynomial alone.

Step 6: Map the Tables

Here is the map of the algorithm tables we found in the firmware’s read-only data:

Firmware address map: algorithm tables in .rodata
============================================================
0x80007A70 - 0x80007E70  CRC-32 lookup table     1024 bytes
0x80007E70 - 0x80007E7B  AES Rcon table             11 bytes
          (gap: 1 padding byte)
0x80007E7C - 0x80007F7C  AES inverse S-box        256 bytes
0x80007F7C - 0x8000807C  AES forward S-box         256 bytes
          (gap: 4 bytes)
0x80008080 - 0x80008180  SHA-256 K[] constants     256 bytes
============================================================
          Total mapped tables:        1,803 bytes
          That's 4.7% of our 38 KB firmware

          SHA-256 H0[]:  inlined as lui/ori immediates in code
============================================================

These tables happen to occupy the 0x7A70-0x8180 range in this build. Their placement is a linker result, not a rule about firmware. Once we find one table, nearby bytes are still worth checking.

The SHA-256 initial values are absent from the map because this build embeds them in instructions. We should inspect both data and code before concluding a constant is missing.

Step 7: Follow Table References

Finding the tables is step one. Step two is finding which functions use them. In this binary, the AES S-box reference uses a lui/addiu instruction pair to load the table address:

80006470:  lui   $t0, 0x8000          # $t0 = 0x80000000
80006474:  addiu $t0, $t0, 0x7F7C   # $t0 = 0x80007F7C

These instructions load the AES S-box address 0x80007F7C. A function that references this address is a candidate for AES processing; the surrounding instructions tell us how it uses the table. Following callers in this sample leads to the hidden $crctest CLI command, which also tests SHA-256. The binary contains both implementations, but it does not show either one protecting management traffic.

We’ll save the full cross-referencing analysis for the next posts, where we’ll use Ghidra’s decompiler and radare2’s axt command. For now, Python can calculate the immediate values to look for:

# AES S-box address we want to find references to
target_addr = 0x80007F7C
target_hi = (target_addr >> 16) & 0xFFFF  # 0x8000
target_lo = target_addr & 0xFFFF          # 0x7F7C (positive)

# In MIPS, if the low 16 bits >= 0x8000, lui loads (hi+1)
# and addiu uses a negative offset
if target_lo >= 0x8000:
    lui_val = (target_hi + 1) & 0xFFFF
    addiu_val = target_lo - 0x10000  # Negative
else:
    lui_val = target_hi
    addiu_val = target_lo

print(f"Looking for: lui $reg, 0x{lui_val:04X}")
print(f"             addiu $reg, $reg, {addiu_val} (0x{addiu_val & 0xFFFF:04X})")
print(f"Target address: 0x{target_addr:08X}")

Looking for: lui $reg, 0x8000
             addiu $reg, $reg, 32636 (0x7F7C)
Target address: 0x80007F7C

Quick Reference: Algorithm Table Signatures

Here are signatures for several algorithms you may encounter. The CRC entries are checksums, not cryptography. A short prefix is a search term; verify more bytes and find code references before assigning a function name.

For big-endian targets (MIPS big-endian, PowerPC, SPARC), the byte order reverses. Our MIPS32 LE firmware stores multi-byte constants in little-endian, so 0x428A2F98 becomes 98 2F 8A 42.

Exercises

1. Verify the S-box: Write a Python script that computes the AES S-box from the mathematical definition (multiplicative inverse in GF(2^8) + affine transform) and compare it against the 256 bytes at offset 0x7F7C in the firmware.

2. Find the Rcon: This build stores the AES key-expansion constants as bytes, with a leading 00. Search for 00 01 02 04 08 10 20 40 80 1B 36 from the firmware directory:

   python3 -c 'from pathlib import Path; data = Path("firmware.bin").read_bytes(); print(hex(data.find(bytes.fromhex("00 01 02 04 08 10 20 40 80 1b 36"))))'
   

Confirm that it prints 0x7e70. One padding byte separates the 11-byte match from the inverse S-box.

1. Entropy histogram: Modify the entropy script to produce a histogram (e.g., using matplotlib) that shows entropy across the entire firmware. The crypto neighborhood should appear as a clear spike.

2. Identify the CRC variant: Check the CRC-16 polynomial, initial value, bit order, and final XOR against the catalogue. Why does this implementation match CRC-16/CMS rather than CRC-16/USB, despite their shared polynomial?

What’s Next

The tables led us to AES, SHA-256, and CRC-32. CRC-16 required a look at code. That is the useful boundary of the method: recognizable data narrows the search, then instructions tell us what the firmware does with it.

In the next post, Ghidra shows *(param_1 + 0x20) where the source had a task control block and a linked-list node. We will use repeated offsets and cross-references to recover that structure from the binary.

This is Part 1 of “Crypto Tables, Struct Ghosts, and Other Secrets Hidden in Firmware.” The sample bundle contains the exact binary, source, and entropy scanner used here.

Next: Part 2 — Offsets, Embedded Nodes, and Other Phantoms of Lost Structs.