BOOT CHAIN LAB
Lab 8 · detection engineering

The landing zone.

An exploit that hijacks execution rarely knows the exact address its payload will land at — stacks shift, heaps move. So it builds a runway: a long stretch of do-nothing instructions, the NOP sled, so an imprecise jump lands somewhere on it and slides down into the real code. You've seen it twice — keyed on in Lab 5's wire signature, found in Lab 6's RAM scan. Here it gets its own lab, because the sled is a gift: a long run of executable-but-inert bytes has no honest reason to exist in a buffer, and that shape is detectable even when the attacker files off the obvious 0x90.

01 — why a runway exists

The tell is the inertness

A sled trades precision for margin. The bigger the run of harmless instructions, the sloppier the jump can be and still work. That trade is exactly what gives it away: the defender doesn't need to decode the exploit, only to notice a long span of bytes that are valid, executable, and do nothing — sitting in a place (a path field, a network buffer, a data region) where executable filler makes no sense.

run lengthThe primary signal. A handful of 0x90 is noise; dozens in a row forming a contiguous inert span is a runway. You measure the length of the longest do-nothing run.
inertness, not 0x90The run doesn't have to be 0x90. Any one-byte instruction with no net effect works — and attackers use that to dodge a naive scanner. You test against the class, not the one byte.
entropy valleyShellcode around it is high-entropy; the sled is a low-entropy executable stretch. A sudden entropy dip inside executable bytes is a corroborating flag.
02 — scan a buffer

Naive vs. shape-aware

Two sample buffers. The classic one is a wall of 0x90. The evasive one is a register-noise sled — a mix of single-byte instructions (inc/dec reg, xchg eax,reg, flag ops) that each do nothing useful but aren't 0x90. Run both detectors and watch the naive one get fooled:

03 — the NOP-equivalent class

It was never just 0x90

A shape-aware scanner keys on run length over a class of one-byte instructions that leave the payload untouched — so a sled built from register noise still lights up. The lab's set:

# single-byte, no net effect on the payload path
0x90                      NOP
0x40-0x47                 INC eAX..eDI
0x48-0x4F                 DEC eAX..eDI
0x91-0x97                 XCHG eAX, reg
0x27 0x2F 0x37 0x3F       DAA DAS AAA AAS
0xF5 0xF8 0xF9 0xFC 0xFD  CMC CLC STC CLD STD

detect: longest contiguous run over this class ≥ threshold (e.g. 16)
         → candidate sled; corroborate with the entropy valley

This is the same move as every lab before it: a literal content match is brittle (Lab 5), so you detect the property — here, “a long inert executable run” — instead of one magic byte. Polymorphic engines can push further (trampoline sleds that jump forward, four-byte-aligned sleds), and the arms race continues; run-length over the equivalence class plus entropy is the durable, cheap first pass.

04 — the hard part

The sled is going extinct

The honest context: the classic sled is a technique in decline, and a detector tuned only for it ages badly.

05 — provenance & citations

Where this comes from

this lab BlueTeamLab — the detection lab this series documents.
github.com/Mik3XC/BlueTeamLab
Closes the sled thread: keyed on in Lab 5, found in Lab 6, cased in Lab 7.
references Toth & Kruegel (2002), “Accurate Buffer Overflow Detection via Abstract Payload Execution,” RAID — sled detection by executable-run length.
Akritidis et al. (2005), STRIDE — sled / shellcode detection.
Fogla & Lee (2006), “Polymorphic Blending Attacks,” USENIX Security — why byte-literal signatures erode.
NOP-equivalent instruction class — the basis of register-noise sleds.

Next: Lab 9 — PE / Mach-O anomaly triage: the static complement to Lab 6, reading a file's own structure for the lie.