BOOT CHAIN LAB
Lab 4B · detection engineering · companion to Lab 4

What a partial capture can prove.

TCP-transit SIEM · binary bit-field · polynomial-array scanner

Lab 4 scored the shape of traffic. This is the layer underneath: the bytes themselves, in transit, arriving chunked and often incomplete. The analyzer answers one disciplined question — what can I actually conclude from the bytes I have? — and refuses to invent the ones I don't. It reconstructs missing pieces only when the math genuinely permits, scans for known content at the bit/byte level, and never pretends a gap is clean.

01 — the evidence model

Coverage is not completeness

Data in transit arrives as chunks, out of order, sometimes dropped. The analyzer takes an explicit JSONL envelope — each event carries stream_id, index, data_chunks, a base64 payload and the chunk's SHA-256 — and treats every anomaly as preserved evidence rather than a number to smooth over.

S1 · hash mismatchA chunk whose bytes don't match its declared SHA-256. High severity — the chunk is corrupt or altered in transit.
S2 · conflictingTwo different payloads claim the same index. High severity — someone's story doesn't add up.
S3 · denylisted hashA completed whole-stream hash matches a known-bad list. Critical.
S5 · known contentA byte window matches a canonical reference (section 04). Severity depends entirely on the reference's class.

The load-bearing idea: with four of five ordinary chunks, coverage is 80% — but the whole-file SHA-256 is null. A cryptographic signature cannot be derived from bytes you never saw. The verdict is inconclusive, not clean. That distinction is the whole lab.

02 — reconstruct, honestly

4 + 2 over GF(256)

When a protocol sends four data shares plus two parity shares (the RedTail-X 4+2 model), any four surviving shares reconstruct the stripe — because every 4-of-6 selection of the generator matrix is invertible over the finite field. Drop shares below and watch: four or more left, it rebuilds exactly and re-verifies the hash; only three, it refuses. This runs a real GF(256) solve in your browser — field polynomial 0x11d, primitive element 2.

Click shares to mark them lost in transit, then reconstruct.

The original stripe is DE AD BE EF; parity is computed, not stored as plaintext. With 3 shares the analyzer reports inconclusive and computes no whole-file hash — it does not guess unknown bytes.

03 — the polynomial array

One array, measured — not scored

The reconstruction is driven by a persisted codec_formula: the GF(256) field polynomial 0x11d, a six-row systematic generator matrix G0…G5 (first four rows are the identity, so data passes through unchanged), zero_elimination: false — zero bytes stay part of the protected input — and a SHA-256 over the canonical formula definition so the array itself is tamper-evident. The analyzer rejects a matrix that is absent, malformed, singular, or changed.

Two candidate parity rows were compared on a 16,936-byte inert fixture. The honest result:

variantG4G51-share rebuilds2-share rebuilds
daybreak-powers[1,1,1,1][1,2,4,8]6/6 exact15/15 exact
darkrock-custom[1,1,1,1][1,2,3,4]6/6 exact15/15 exact

The two produce different parity hashes and differ in 339 parity bytes / 1,273 parity bits, yet both reconstruct every tested one- and two-share loss exactly. That establishes functional equivalence for the erasure contract — not wire compatibility between their parity. The discipline worth stealing: a finite-field erasure code has no meaningful floating-point “sensitivity” score. The real measurements are rank, exact recovery, hashes, and bit-level diffusion — and the audit keeps four different mechanisms (the codec formula, routing/path selection, the compression gate, and the witness ceiling) from ever being logged as if they were one equation. Undefined control arms are reported undefined, never backfilled with an inferred formula.

04 — the bit-field scanner

Known content, without the content

A partial stream can't yield a whole-file hash, but it can still carry strong evidence from a known reference. The scanner builds a canonical database: a BLAKE2b-128 digest of every 32-byte window at one-byte stride, plus each reference's class and whole-file SHA-256. It stores digests, never the executable bytes. A match needs a continuous 64-byte aligned run — a single window is never a signature (256 values per byte would false-positive endlessly), and any window seen more than 64 times across the reference set is kept for coverage but excluded from scoring, so a long zero-filled section can't manufacture an alert.

And the rule that keeps it honest — a match never supplies its own hostility. The verdict comes from how the reference was classified, not from the fact that bytes matched:

test→ informational, school_control, containment none. The default class.
benign→ informational, inclusion_only, containment none.
malicious→ high severity, suspicious status, containment endpoint policy required — only for an authorized malicious reference set.

The synthetic fixture is a harmless ARM64 Mach-O carrying the marker strings MALWARE PAYLOAD CARRIER HERE / NULL PAYLOAD with sixteen null callback slots — it opens no socket, loads no payload, calls nothing. Source is committed beside the binary so it can be audited and rebuilt. The policy layer never infers hostility from matching bytes.

05 — the honest boundary

The SIEM observes; the endpoint enforces

SCP rides inside encrypted SSH. A passive sensor sees the flow — endpoints, timing, byte counts, SSH fingerprints — but cannot reconstruct the transferred program or compute its plaintext hash. Pretending otherwise would be the dishonest move. The deployable control is correlation across layers:

# the chain that actually contains something
1  network sensor     records the SSH flow (metadata only)
2  endpoint telemetry sshd / scp / sftp process + file writes
3  EDR                hashes the completed file, checks allow/deny
4  SIEM                correlates flow + process + path + hash + exec
5  EDR                quarantine / prevention — the SIEM only records

Output stays payload-free and routable: a normalized siem-json event or an RFC 5424 syslog line (facility local0) an administrator can forward to an approved collector such as Falcon LogScale. Exit codes carry the verdict — 0 complete/recovered, 1 evidence gap (parse the JSON, it's not a crash), 2 usage/input error, 3 suspicious or denylisted finding.

The throughline: the 4+2 GF(256) algebra here is the same erasure math from the RedTail-X / ROS storage work — repurposed. There it protects data at rest; here it becomes evidence of exactly what a partial capture can and cannot prove. Red-side R&D, read in blue.

06 — provenance & citations

Where this comes from

implementation (this lab) BlueTeamLab / detection-lab
lab/stream.py — the analyzer (1,066 lines)
docs/STREAM_ANALYZER.md — evidence model
docs/FORMULA_ARRAY_AUDIT.md — the matrix audit
docs/DAYBREAK_BLUE_LAB_REPORT.md — report (77 tests passing, 2026-10-04)
samples/synthetic/ — auditable fixture
github.com/Mik3XC/BlueTeamLab
RedTail-X (DarkRock VLFSC-RDTX) — the 4+2 erasure scheme, from the ROS storage R&D.
standards & references Reed & Solomon (1960), “Polynomial Codes over Certain Finite Fields,” J. SIAM 8(2) — MDS codes.
GF(2⁸), reducing polynomial 0x11D (x⁸+x⁴+x³+x²+1), primitive element 2.
BLAKE2b — RFC 7693.
SHA-256 — FIPS 180-4.
Syslog protocol — RFC 5424.
Falcon LogScale — CrowdStrike (structured JSON / syslog ingest).

Next: Lab 6 — memory forensics: the one place an implant must stop being a stream and become real.