`seama`: the D-Link DIR-300's firmware seal, recovered byte-for-byte from one MIPS applet

A stock D-Link DIR-300 rev B5 firmware opens with a 12-byte magic header nobody documents in the GUI. Following it into the rootfs leads to a single multi-call MIPS binary whose seama_main defines the whole integrity scheme — a two-record container with an MD5 over only the image body. This is the full reconstruction: the SEAMA layout, the annotated MIPS, and a Python port that re-seals the real image to the exact same bytes, digest included.

The target

I pulled the pristine vendor image straight from a public firmware-analysis repo (only the .BIN; I deliberately did not read the repo's own notes, to keep the analysis my own):

file:   DIR-300_REVB5_FIRMWARE_2.15.B01_WW.BIN
size:   3,641,484 bytes (0x37908c)
sha256: 36c427ab89f09cd192047542b1a697ea6b6cba61ff8d98c1ca8f970af68e670c
file(1): data        # no ELF/uImage/TRX magic at offset 0

file calls it "data" because byte 0 isn't any container libmagic knows. The first 0x70 bytes (xxd) tell a different story:

00000000: 5ea3 a417 0000 0020 0000 0000 7369 676e  ^...... ....sign
00000010: 6174 7572 653d 7772 676e 3439 5f64 6c6f  ature=wrgn49_dlo
00000020: 625f 6469 7233 3030 6235 0000 5ea3 a417  b_dir300b5..^...
00000030: 0000 0024 0037 9020 6285 c9c4 564e 76fc  ...$.7. b...VNv.
00000040: 1288 58ed e524 7b1f 6465 763d 2f64 6576  ..X..${.dev=/dev
00000050: 2f6d 7464 626c 6f63 6b2f 3200 7479 7065  /mtdblock/2.type
00000060: 3d66 6972 6d77 6172 6500 0000 5d00 0000  =firmware...]...

Two things jump out. 5e a3 a4 17 appears twice — at 0x00 and again at 0x2c — and the ASCII reads signature=wrgn49_dlob_dir300b5, then dev=/dev/mtdblock/2, type=firmware. 0x5ea3a417 is SEAMA — "SEt Aside MAgic", the container Alpha Networks used across many D-Link/SerComm devices. The 16 bytes at 0x34 (6285 c9c4 …) have the texture of an MD5 digest. The job: prove that, and recover exactly which bytes it covers and how — from the code, not from folklore.

binwalk said nothing — so I wrote my own scanner

The sandbox ships binwalk 2.4.3, but its signature engine came up empty here:

$ binwalk dir300.bin              # (no output)
$ binwalk --signature --term dir300.bin   # (still nothing)
$ python3 -c "import binwalk; print(binwalk.__version__)"
2.4.3

The module imports fine; the magic database just isn't wired up in this build. Rather than fight it, I scanned for the handful of signatures I cared about directly. scan.py walks the file, lists every hit, then parses the SEAMA chain as a length-prefixed structure:

#!/usr/bin/env python3
import struct, hashlib
data = open('/tmp/dir300.bin','rb').read()
print(f"total size: {len(data)} (0x{len(data):x})")
sigs = {
    b'\x5e\xa3\xa4\x17': 'SEAMA magic', b'hsqs': 'SquashFS LE (sqsh)',
    b'\x1f\x8b\x08': 'gzip', b'\x5d\x00\x00': 'LZMA (lc=3,lp=0,pb=2)',
}
for sig, name in sigs.items():
    off, hits = 0, []
    while True:
        i = data.find(sig, off)
        if i < 0: break
        hits.append(i); off = i + 1
    if hits: print(f"  {name:28s}: " + ", ".join(f"0x{h:x}" for h in hits[:12]))

print("\n=== SEAMA parse ===")
off = blk = 0
while off < len(data) and data[off:off+4] == b'\x5e\xa3\xa4\x17':
    magic, reserved, metasize, imgsize = struct.unpack('>IHHI', data[off:off+12])
    print(f"block {blk} @0x{off:x}: metasize={metasize} imgsize=0x{imgsize:x}")
    p = off + 12
    md5 = data[p:p+16] if imgsize else b''; p += len(md5)
    meta = data[p:p+metasize]; p += metasize
    print(f"   meta={meta!r}")
    if imgsize:
        body = data[p:p+imgsize]
        print(f"   stored md5     = {md5.hex()}")
        print(f"   md5(body)      = {hashlib.md5(body).hexdigest()}")
        print(f"   md5(meta+body) = {hashlib.md5(meta+body).hexdigest()}")
    off = p + imgsize; blk += 1

Output:

total size: 3641484 (0x37908c)
  SEAMA magic                 : 0x0, 0x2c
  SquashFS LE (sqsh)          : 0x12008c
  LZMA (lc=3,lp=0,pb=2)       : 0x6c

=== SEAMA parse ===
block 0 @0x0: metasize=32 imgsize=0x0
   meta=b'signature=wrgn49_dlob_dir300b5\x00\x00'
block 1 @0x2c: metasize=36 imgsize=0x379020
   meta=b'dev=/dev/mtdblock/2\x00type=firmware\x00\x00\x00'
   stored md5     = 6285c9c4564e76fc128858ede5247b1f
   md5(body)      = 6285c9c4564e76fc128858ede5247b1f
   md5(meta+body) = db3263bcb8dbdae0b3620f8cd84f5a59

That already answers the central question empirically. The stored digest equals md5(body) — MD5 over the imgsize image bytes only. The obvious alternative, md5(meta+body), gives db3263bc…, which does not match — so the metadata is excluded from the hash. Hold that result; the disassembly has to agree with it or one of us is wrong.

The structure map:

File offset	Size	Contents
0x00	44	SEAMA record #0 — seal (imgsize=0, signature only)
0x2c	28	SEAMA record #1 header + 16-byte MD5
0x48	36	record #1 metadata (dev=…, type=firmware)
0x6c	—	LZMA-compressed kernel (5d 00 00 …)
0x12008c	—	SquashFS rootfs (hsqs, inside the body)
0x37908c	—	EOF

So one SEAMA "firmware" record wraps the entire kernel+rootfs blob as a single image, and the MD5 at 0x34 is supposed to cover all 0x379020 bytes of it. Record #0 is a degenerate SEAMA with no image at all — just a signed name string.

Architecture detection, and a SquashFS-LZMA detour

The body at 0x6c is a standard .lzma alone stream (props 0x5d = lc3/lp0/pb2, 8-byte size field). Decompressing it confirms the platform:

$ python3 - (lzma.FORMAT_ALONE on body @0x6c)
kernel decompressed bytes: 3479564
Linux version -> Linux version 2.6.33.2 ([email protected]) (gcc 4.3.3) #1 ...
MIPS          -> MIPS32_R2 32BIT

Linux 2.6.33.2 on MIPS32_R2. The rootfs at 0x12008c is SquashFS 4.0, and its superblock is where embedded RE bites you:

hsqs  inode_count=1473  block_size=131072
compression=2 (LZMA)  block_log=17  version=4.0

Compression id 2 = LZMA — not XZ (id 4). SquashFS 4.0 + LZMA1 is a vendor patch; mainline dropped it. There's no unsquashfs in the sandbox, and the pure-Python reader I reached for refused outright:

$ python3 sqfs_list.py
ValueError: Unknown compression method 2

So I plugged a decompressor into PySquashfsImage. First attempt — treat each block as a .lzma alone stream by synthesizing the 13-byte header (props + dict + 8-byte size):

header = src[:5] + struct.pack('<Q', outsize)   # props+dict, then size
out = lzma.LZMADecompressor(format=lzma.FORMAT_ALONE).decompress(header + src[5:])
# -> _lzma.LZMAError: Corrupt input data

That failed. So I dumped the raw bytes of the first inode-table metadata block to see what the framing actually is:

first inode metadata block @0x2522e7: size=1548
first 24 bytes: 6d 00 00 80 00 00 01 00 19 a0 10 07 ea 05 dc a9 ...

The block begins 6d 00 00 80 00 — a 5-byte LZMA header (props=0x6d, dict_size=0x00800000) followed immediately by raw LZMA1 data, with no uncompressed-size field. (Note 0x6d decodes to lc=1, lp=2, pb=2 — a different tuning than the kernel's 0x5d; two LZMA flavours in one image.) Second attempt — parse those props and feed only the payload into a FORMAT_RAW LZMA1 decoder with the known output size:

class LZMA1Compressor(C.Compressor):
    name = "lzma"
    def uncompress(self, src, size, outsize):
        props = src[0]
        dictsize = struct.unpack('<I', src[1:5])[0]
        lc = props % 9; t = props // 9; lp = t % 5; pb = t // 5
        filt = [{"id": lzma.FILTER_LZMA1, "lc": lc, "lp": lp, "pb": pb, "dict_size": dictsize}]
        dec = lzma.LZMADecompressor(format=lzma.FORMAT_RAW, filters=filt)
        return dec.decompress(src[5:], outsize)

C.compressors[2] = LZMA1Compressor

props=0x6d -> lc=1 lp=2 pb=2  dict=0x800000
decoded len: 8192
extracted files: 1169

1169 files out. The rootfs is a textbook Realtek/Alpha-Networks D-Link userland:

bin/   busybox msh sh ...        sbin/  httpd init insmod ...
usr/sbin/  seama  fwupdater  rgbin  xmldb  devdata  ...

usr/sbin/seama is a symlink to rgbin, a busybox-style multi-call binary. grep across the tree for the keyword points at exactly that binary's strings plus the web upgrade scripts:

./usr/sbin/rgbin        ← seama_main lives here
./htdocs/webinc/.../tools_fw_rlt.php
./etc/config/image_sign  → "wrgn49_dlob_dir300b5"
./etc/config/fw_sign     → "wrgn49_dlob_dir300b5"

etc/config/image_sign contains wrgn49_dlob_dir300b5 — the same string the SEAMA seal record carries at 0x0c. That's the upgrade path's product-lock: the seal's signature= must match this file, or the image is rejected as belonging to a different model. The integrity (MD5) and the identity (signature) are separate mechanisms in the same container.

The binary: rgbin and seama_main

$ readelf -h usr/sbin/rgbin
Class: ELF32   Data: little endian   Machine: MIPS R3000
Flags: 0x50001007, noreorder, pic, cpic, o32, mips32
sha256: 6afed736e1defc91c5fd32d05b664786d63b2eac6c0c2258fad21ae3b574fd2e

MIPS32, little-endian (MIPSEL), o32 ABI, dynamically linked against uClibc, stripped. radare2 6.1.7 still resolves sym.seama_main (the dispatch table maps the string "seama" to it). I loaded with r2 -e bin.relocs.apply=true -c 'aaa' rgbin; the strings inside seama_main lay out the whole feature set:

seama version 0.20
  -d {file}     dump the info of the seama file.
  -i {file}     image file name.
  -s {file}     Seal the images to the seama file.
  -x {seama}    Extract the seama file.
MD5Init  MD5Update  MD5Final

seama_main is a getopt loop over "hvd:s:i:m:x:" that dispatches to four helpers. The two that matter:

; sym.seama_main @ 0x409444 — option -d (dump/validate)
0x00409444  jal fcn.00408408      ; fcn.00408408(filename, mode=1)
0x00409448  addiu a1, zero, 1     ; a1 = 1  => verbose dump
; @0x40947c — option -s (seal) validates each input the same way
0x0040947c  jal fcn.00408408      ; fcn.00408408(filename, mode=0)  (quiet)

So fcn.00408408 is the single parse-and-verify routine, used both to dump (-d, mode=1) and to validate inputs before sealing (mode=0). Reverse that one function and you have the reader. The writer lives in fcn.004088b8. Let me take them in turn.

The verify routine: fcn.00408408

The function fstats and fopens the file "r+", then enters a loop that reads one SEAMA record per iteration until EOF. The header read is a single 12-byte fread:

0x004084dc  jalr  fread           ; fread(buf = sp+0x18, size = 1, nmemb = 12, fp)
0x004084fc  bne   s1, v0, 0x408840 ; s1 (==1) must equal records-read, else stop
0x00408500  lui   v1, 0x17a4
0x00408504  lw    v0, (sp+0x18)    ; v0 = *(u32*)header  (magic, read host-endian)
0x00408508  ori   v1, v1, 0xa35e   ; v1 = 0x17a4a35e == on-disk bytes 5e a3 a4 17
0x0040850c  beq   v0, v1, 0x408528 ; magic matches -> continue
0x00408524  ...   "Invalid SEAMA magic. Probably no more SEAMA!"

The constant 0x17a4a35e is the little-endian load of the four on-disk bytes 5e a3 a4 17, so the comparison is byte-exact for magic 0x5EA3A417. When the magic doesn't match it isn't always an error — at EOF (or a trailing partial record) the loop just stops, which is how the same routine cleanly walks the seal record followed by the firmware record.

Header fields imgsize (offset +8) and metasize (offset +6) are stored big-endian on disk, so the code byte-swaps them by hand:

0x00408528  lw   v0, (sp+0x20)     ; v0 = header+8 = imgsize (big-endian)
0x0040852c  lhu  s0, 0x1e(sp)      ; s0 = header+6 = metasize (big-endian, u16)
0x00408530  sll  a0, v0, 0x18      ; ---- bswap32(imgsize) ----
0x00408534  srl  a1, v0, 0x18
0x00408538  srl  v1, v0, 8
0x0040853c  or   a0, a0, a1
0x00408540  andi v1, v1, 0xff00
0x00408544  andi v0, v0, 0xff00
0x00408548  or   a0, a0, v1
0x0040854c  sll  v0, v0, 8
0x00408550  or   s4, a0, v0        ; s4 = imgsize, host byte order

With imgsize in s4, the digest is read only when there's an image to cover — this is exactly the branch that makes the seal record (record #0, imgsize=0) carry no MD5:

0x00408554  beqz s4, 0x408594      ; imgsize == 0  -> skip digest entirely
0x0040855c  jalr fread             ; fread(sp+0x24, size=0x10, 1, fp) -> stored MD5
0x00408560  addiu a0, sp, 0x24     ;   16-byte digest buffer at sp+0x24
0x00408564  addiu a1, zero, 0x10
0x00408578  beq  v0, s1, 0x408594  ; read one 16-byte record? else "Error reading checksum!"

Then metasize is byte-swapped, range-checked against 1024, and the metadata is read into a separate buffer:

0x00408594  andi  v0, v0, 0xffff   ; ---- bswap16(metasize) -> s0 ----
0x0040859c  or    s0, v0, v1
0x004085a0  sltiu v0, s0, 0x401    ; metasize < 0x401 (1025) ?
0x004085a4  bnez  v0, 0x4085c0     ; ok, else "META data in SEAMA header is too large!"
0x004085c0  jalr  fread            ; fread(sp+0xe0, size=1, nmemb=metasize, fp)
0x004085dc  beq   v0, s0, 0x408608 ; read all metasize bytes? else "Unable to read META"

Note the cap: metasize ≤ 1024. The buffer at sp+0xe0 is sized for it. The file pointer is now positioned exactly at the start of the image body — which is what the digest routine consumes. Verification is two calls:

0x00408740  move a1, s4            ; a1 = imgsize
0x00408744  move a0, s3            ; a0 = FILE*
0x0040874c  move a2, s0            ; a2 = out buffer (sp+0x34)
0x00408748  jal  fcn.004082bc      ; computed = md5_of_file(fp, imgsize, out)
;   ...
0x004087b0  jalr memcmp            ; memcmp(stored@sp+0x24, computed@sp+0x34, 0x10)
0x004087c8  bnez v0, 0x4087d8      ; differ -> "!!ERROR!! checksum error !!"
0x004087d0  b    0x408808          ; equal  -> s7 = 0 (success), loop to next record

The verdict is a 16-byte memcmp between the stored digest (sp+0x24) and the freshly computed one (sp+0x34). Mismatch prints !!ERROR!! checksum error !!.

The MD5 framing: fcn.004082bc

fcn.004082bc(fp, length, out) is the piece that decides which bytes get hashed. It is a clean streaming MD5:

0x00408308  jal   MD5Init         ; MD5Init(ctx = sp+0x18)
0x00408328  addiu s5, sp, 0x70    ; s5 = 1024-byte staging buffer
; loop:
0x0040832c  bnez  v1, 0x408338    ; chunk = (remaining <= 0x400) ? remaining : 0x400
0x00408334  addiu a2, zero, 0x400
0x00408338  jalr  fread           ; n = fread(buf, 1, chunk, fp)
0x0040834c  lw    t9, MD5Update
0x00408358  move  a2, v0          ; MD5Update(ctx, buf, n)
0x00408360  addu  s2, s2, v0      ; total += n
0x00408370  subu  s1, s1, s0      ; remaining -= n   (only when length != 0)
;   ... until feof / ferror / remaining == 0 ...
0x004083c4  jal   MD5Final        ; MD5Final(out, ctx)

It hashes exactly length bytes, in 1024-byte chunks, starting from the current file position — and the caller left that position right after the metadata. So the digest covers the image body and nothing else: not the header, not the digest field, not the metadata. That is precisely what the empirical md5(body) match told us, now confirmed from the control flow. (MD5Init/Update/Final are the stock RFC-1321 routines; the hashlib.md5 match below is the proof — I didn't need to re-reverse the compression function.)

The writer: fcn.004088b8

To be sure I understood the format and not just one direction of it, I read the seal path. fcn.004088b8(fp, meta[], count, imgsize) computes the padded metasize and emits the 12-byte header:

; loop @0x408900: s0 += strlen(meta[i]) + 1   for each of `count` strings
0x0040892c  addiu s0, s0, 3
0x00408930  andi  s0, s0, 0xfffc   ; metasize = (Σ(strlen+1) + 3) & ~3   (round up to 4)
;   ... byte-swap imgsize -> v1, metasize -> s0 ...
0x00408974  lui   v0, 0x17a4
0x00408980  ori   v0, v0, 0xa35e   ; magic bytes 5e a3 a4 17
0x00408984  sh    s0, (sp+0x1e)    ; metasize (BE)  at header +6
0x00408988  sw    v0, (sp+0x18)    ; magic          at header +0
0x0040898c  sw    v1, (sp+0x20)    ; imgsize  (BE)  at header +8
0x00408990  sh    zero, (sp+0x1c)  ; reserved = 0   at header +4
0x0040899c  addiu a1, zero, 0xc    ; fwrite(hdr, 1, 12, fp)

This pins down every field. metasize is (Σ(strlen(kv)+1) + 3) & ~3 — the sum of each NUL-terminated key=value string's length, rounded up to a multiple of 4. Check it against the real image: record #0's lone string signature=wrgn49_dlob_dir300b5 is 30 chars → 31 with NUL → rounds to 32 (0x20). Record #1's dev=/dev/mtdblock/2\0 (20) + type=firmware\0 (14) = 34 → rounds to 36 (0x24). Both match the header bytes exactly.

The SEAMA container, fully specified

Putting the reader and writer together, the on-disk record is:

Offset	Size	Field	Endian	Notes
0x00	4	magic	BE	always 0x5EA3A417
0x04	2	reserved	—	written as 0x0000
0x06	2	metasize	BE	(Σ(strlen(kv)+1)+3) & ~3, ≤ 1024
0x08	4	imgsize	BE	image body length; 0 ⇒ no body, no digest
0x0C	16	md5	—	present iff imgsize ≠ 0; MD5 of the body
0x0C/0x1C	metasize	meta	—	NUL-terminated key=value strings, 4-byte padded
…	imgsize	image	—	the bytes MD5 covers

And the file is a chain of these records read until the magic stops matching. This image holds two:

#	offset	metasize	imgsize	meta	digest
0	0x00	32	0	signature=wrgn49_dlob_dir300b5	— (seal)
1	0x2c	36	3,641,376	dev=/dev/mtdblock/2, type=firmware	6285c9c4…7b1f

The split mirrors how the device flashes: the seal authenticates the product (its signature is matched against /etc/config/image_sign), while the firmware record names a destination (dev=/dev/mtdblock/2) and protects the payload with MD5.

To make the parser's loop concrete, here is its state machine — one pass per record, looping back on a good magic and stopping when the magic runs out:

A worked example: tracing the firmware record

Take record #1 at 0x2c. The header reader does fread(buf, 1, 12, fp) and gets these twelve bytes:

5e a3 a4 17 | 00 00 | 00 24 | 00 37 90 20

Step the decode the way fcn.00408408 does:

1. *(u32*)buf loaded little-endian = 0x17a4a35e; compared to the immediate 0x17a4a35e ⇒ magic OK.
2. imgsize = bswap32(0x20903700) = 0x00379020 = 3,641,376. Non-zero ⇒ a digest follows.
3. fread(sp+0x24, 0x10, 1, fp) ⇒ stored digest 62 85 c9 c4 56 4e 76 fc 12 88 58 ed e5 24 7b 1f.
4. metasize = bswap16(0x2400) = 0x0024 = 36; 36 < 1025 ⇒ OK. fread(sp+0xe0, 1, 36, fp) ⇒ dev=/dev/mtdblock/2\0type=firmware\0\0\0.
5. File pointer is now at 0x2c + 12 + 16 + 36 = 0x6c. md5_of_file(fp, 3641376, out) streams 0x379020 bytes in 1024-byte chunks (3555 full chunks + a 1056-byte tail) and finalizes.
6. memcmp(stored, computed, 16).

My roundtrip.py reproduces exactly this trace from the real file:

=== worked example: 12 header bytes @0x2c ===
raw      : 5ea3a4170000002400379020
magic    : 5ea3a417 -> 0x5ea3a417
reserved : 0000 -> 0
metasize : 0024 -> 36
imgsize  : 00379020 -> 3641376
md5[16]  : 6285c9c4564e76fc128858ede5247b1f
meta     : b'dev=/dev/mtdblock/2\x00type=firmware\x00\x00\x00'
body @   : 0x6c  len 0x379020

The first 1024-byte chunk fed to MD5Update begins at 0x6c with the LZMA kernel's 5d 00 00 00 02 …. The final MD5Final yields 6285c9c4564e76fc128858ede5247b1f, and the memcmp against the stored digest returns 0. Verified.

Python re-implementation

seama.py is the ground-truth port. iter_entities mirrors fcn.00408408's loop; md5_of_body mirrors fcn.004082bc; seal_header/seal mirror fcn.004088b8 and the pack path:

#!/usr/bin/env python3
import struct, hashlib, sys
SEAMA_MAGIC = 0x5EA3A417

def parse_meta(meta: bytes):
    return [c.decode("latin1") for c in meta.split(b"\x00") if c]

def iter_entities(data: bytes):
    """Yield each SEAMA entity, mirroring fcn.00408408's read loop."""
    off = 0
    while off + 12 <= len(data):
        magic, reserved, metasize, imgsize = struct.unpack_from(">IHHI", data, off)
        if magic != SEAMA_MAGIC:          # "Invalid SEAMA magic. Probably no more SEAMA!"
            break
        if metasize > 1024:
            raise ValueError("META data in SEAMA header is too large!")
        p = off + 12
        md5 = None
        if imgsize != 0:                  # @0x408554: digest only when imgsize != 0
            md5 = data[p:p + 16]; p += 16
        meta = data[p:p + metasize];      p += metasize
        body = data[p:p + imgsize] if imgsize else b""; p += imgsize
        yield {"offset": off, "magic": magic, "reserved": reserved,
               "metasize": metasize, "imgsize": imgsize, "md5": md5,
               "meta": meta,
               "body_off": off + 12 + (16 if imgsize else 0) + metasize, "body": body}
        off = p

def md5_of_body(body: bytes) -> bytes:
    """fcn.004082bc: MD5Init / MD5Update in 1024-byte chunks / MD5Final."""
    h = hashlib.md5()
    for i in range(0, len(body), 1024):
        h.update(body[i:i + 1024])
    return h.digest()

def dump(data: bytes):
    ok = True
    for e in iter_entities(data):
        print("SEAMA ==========================================")
        print(f"  offset     : 0x{e['offset']:x}")
        print(f"  magic      : {e['magic']:08x}")
        print(f"  meta size  : {e['metasize']} bytes")
        print(f"  meta data  : {' | '.join(parse_meta(e['meta']))}")
        print(f"  image size : {e['imgsize']} bytes")
        if e["imgsize"]:
            stored = e["md5"].hex(); calc = md5_of_body(e["body"]).hex()
            verdict = "MATCH" if stored == calc else "!!ERROR!! checksum error !!"
            print(f"  checksum   : {stored}   (stored digest)")
            print(f"  digest     : {calc}   (recomputed) -> {verdict}")
            ok = ok and (stored == calc)
        print("================================================")
    return ok

def seal_header(metas, imgsize):
    """fcn.004088b8: 12-byte header. metas = list of 'k=v' strings."""
    total = sum(len(m) + 1 for m in metas)        # strlen()+1 per string
    metasize = (total + 3) & ~3                    # round up to a multiple of 4
    return struct.pack(">IHHI", SEAMA_MAGIC, 0, metasize, imgsize), metasize

def seal(metas, body):
    hdr, metasize = seal_header(metas, len(body))
    meta = b"".join(m.encode("latin1") + b"\x00" for m in metas)
    meta += b"\x00" * (metasize - len(meta))
    return hdr + md5_of_body(body) + meta + body

if __name__ == "__main__":
    blob = open(sys.argv[1], "rb").read()
    print(f"file: {sys.argv[1]}  ({len(blob)} bytes)\n")
    print(f"\nALL DIGESTS VALID: {dump(blob)}")

Running it against the untouched vendor image:

$ python3 seama.py dir300.bin
file: dir300.bin  (3641484 bytes)

SEAMA ==========================================
  offset     : 0x0
  magic      : 5ea3a417
  meta size  : 32 bytes
  meta data  : signature=wrgn49_dlob_dir300b5
  image size : 0 bytes
================================================
SEAMA ==========================================
  offset     : 0x2c
  magic      : 5ea3a417
  meta size  : 36 bytes
  meta data  : dev=/dev/mtdblock/2 | type=firmware
  image size : 3641376 bytes
  checksum   : 6285c9c4564e76fc128858ede5247b1f   (stored digest)
  digest     : 6285c9c4564e76fc128858ede5247b1f   (recomputed) -> MATCH
================================================

ALL DIGESTS VALID: True

The reader reproduces seama -d and the digest verifies. The stronger test is the writer: re-seal both records from their meta + body and compare to the original file, byte for byte. roundtrip.py:

#!/usr/bin/env python3
import struct, sys
sys.path.insert(0, "/labs-output")
import seama

blob = open("/tmp/dir300.bin", "rb").read()
ents = list(seama.iter_entities(blob))

e = ents[1]; off = e["offset"]; raw = blob[off:off + 12]
print("=== worked example: 12 header bytes @0x%x ===" % off)
print("raw      :", raw.hex())
print("magic    : %s -> 0x%08x" % (raw[0:4].hex(), struct.unpack('>I', raw[0:4])[0]))
print("reserved : %s -> %d" % (raw[4:6].hex(), struct.unpack('>H', raw[4:6])[0]))
print("metasize : %s -> %d" % (raw[6:8].hex(), struct.unpack('>H', raw[6:8])[0]))
print("imgsize  : %s -> %d" % (raw[8:12].hex(), struct.unpack('>I', raw[8:12])[0]))
print("md5[16]  :", blob[off + 12:off + 28].hex())
print("meta     :", blob[off + 28:off + 28 + e["metasize"]])
print("body @   : 0x%x  len 0x%x" % (e["body_off"], e["imgsize"]))

print("\n=== writer round-trip (fcn.004088b8 reconstruction) ===")
metas0 = seama.parse_meta(ents[0]["meta"])
hdr0, ms0 = seama.seal_header(metas0, 0)
seal0 = hdr0 + b"".join(m.encode() + b"\x00" for m in metas0)
seal0 += b"\x00" * (ms0 - (len(seal0) - 12))
print("entity0 (seal) reproduced exactly:", seal0 == blob[0:0x2c], "(%d bytes)" % len(seal0))

rebuilt = seama.seal(seama.parse_meta(ents[1]["meta"]), ents[1]["body"])
print("entity1 (firmware) reproduced exactly:", rebuilt == blob[0x2c:], "(%d bytes)" % len(rebuilt))
print("  header+md5 bytes match:", rebuilt[:28] == blob[0x2c:0x2c+28], rebuilt[:28].hex())

=== writer round-trip (fcn.004088b8 reconstruction) ===
entity0 (seal) reproduced exactly: True (44 bytes)
entity1 (firmware) reproduced exactly: True (3641440 bytes)
  header+md5 bytes match: True 5ea3a41700000024003790206285c9c4564e76fc128858ede5247b1f

Both records — all 3,641,484 bytes — are reproduced exactly, digest included. The port isn't merely compatible with the format; it is bit-identical to what the vendor's rgbin emitted.

What I deliberately left alone

A few honest boundaries on scope:

• The 1-byte checksum is a different applet. rgbin also contains fcn.004055e0/fcn.00405430 ("write checksum = 0x%x" / "read checksum = 0x%02x"). Following the call graph, those belong to devdata_main — the factory/NVRAM block serializer, a separate key=value container with its own single-byte checksum. It is not part of SEAMA, so I left it out rather than conflate two formats. It would make a fine standalone post.
• MD5 internals. MD5Init/Update/Final are statically linked into rgbin. I treated them as the stock RFC-1321 MD5 and validated that assumption by matching hashlib.md5 against the on-disk digest and reproducing the whole image. I did not re-derive the 64 round constants; the byte-exact round-trip is stronger evidence than staring at the compression function would be.
• Integrity ≠ authenticity. SEAMA's MD5 detects accidental corruption; it is not a signature. Anyone who can recompute MD5 (i.e., anyone) can re-seal a modified image and it will verify — which is exactly what roundtrip.py demonstrates. The only model-lock is the seal's signature= string compared against /etc/config/image_sign, and that string is plaintext in the header. This is consistent with the era (2010, Linux 2.6.33): a structural checksum, not a cryptographic one. I'm noting the property, not shipping a flashing tool — there is no payload here to weaponize, just the container math.

Re-implementing from this post alone

You have everything needed to write a SEAMA tool in any language without the binary:

1. Read 12 bytes. Interpret as big-endian magic(4) reserved(2) metasize(2) imgsize(4). Stop if magic != 0x5EA3A417.
2. If imgsize != 0, read 16 bytes of MD5.
3. Read metasize bytes of metadata (key=value\0…, padded to a multiple of 4; reject metasize > 1024).
4. The next imgsize bytes are the image; its MD5 must equal the stored digest.
5. Advance past the image and repeat — files chain multiple records (seal first, then firmware).
6. To create one: metasize = (Σ(len(kv)+1) + 3) & ~3; lay out header, then (for a body) the MD5 of the body, then padded metadata, then the body.

References

• Target: D-Link DIR-300 rev B5 stock firmware 2.15.B01_WW (the .BIN only), sourced via the topics/firmware neighbourhood on GitHub. SHA-256 36c427ab…e670c.
• Binary analyzed: usr/sbin/rgbin (MIPS32EL, uClibc, stripped), SHA-256 6afed736…fd2e; SEAMA logic in seama_main, fcn.00408408, fcn.004082bc, fcn.004088b8.
• Tools: radare2 6.1.7 (aaa, pdf, axt), Python 3 lzma/hashlib/struct, PySquashfsImage 0.9.0 (patched with an LZMA1 id-2 backend), readelf, xxd. binwalk 2.4.3 was present but produced no signatures in this build — hence the hand-rolled scanner.
• Format lineage: SEAMA ("SEt Aside MAgic") is the Alpha-Networks/SerComm container also recognised by OpenWrt's seama image splitter; this analysis was done from the binary, then cross-checked against the image bytes.

Artefacts

In the download tarball: DIR-300_REVB5_2.15.B01_WW.bin (the vendor image), rgbin (the analyzed MIPS binary), rootfs.sqsh (the carved SquashFS), and the scripts shown in full above — scan.py, sqfs_extract.py, seama.py, roundtrip.py. Everything in this post reproduces from those four scripts and the image; no tarball download is required to follow the reasoning.