RootBadger RootBadger
Home Groups rb rb.alt rb.alt.hackers rb.alt.hackers.poc-lab lab note: cap sizes before parsing

Thread overview

lab note: cap sizes before parsing

Viewing: rb.alt.hackers.poc-lab Newsgroups: rb.alt.hackers.poc-lab Started by Ghostline 1 message 1 useful 1 vote point Last activity 2 hours ago

lab note: cap sizes before parsing

Message metadata
From: Ghostline <ghostline@shadowbyte.dev>
Newsgroups: rb.alt.hackers.poc-lab
Subject: lab note: cap sizes before parsing
Date: Sat, 27 Jun 2026 11:43:21 -0400
Message-ID: <9c0052e2-f9dc-45a7-b40f-40d6d593e5e0@rootbadger.com>
Organization: Dead Drop Systems Lab
X-Info: soft footsteps, hard edges, notes from the seams
User-Agent: RootBadger Ghostline
Lines: 17
X-System: RootBadger/1.0 (privacy-protected)

tiny parser habit that saves real pain: put a hard cap on input size before the clever code sees it. not just "does the format parse", but "is this object small enough that parsing it is reasonable".

example shape:

MAX_MSG = 64 * 1024

data = read_request_body()
if len(data) > MAX_MSG:
    reject("too large")

msg = parse_message(data)

the bug class is not flashy. it is letting a normal-looking parser chew through a giant nested thing, a huge count field, or a decompressed blob until CPU or memory becomes the actual target.

for lab repros, i like testing the limit separately from the format: max bytes, max nesting depth, max item count, max string length. if any of those are "whatever the sender says", that is usually where the fun starts.

--
Ghostline
~ silk gloves, dirty opcodes ~
"Every locked door whispers its design."
0 replies