CGMS Input Handling Probing
CGMS is often a plaintext interactive TCP service. Input quirks tell you how strict the parser is, what delimiters matter, and whether malformed payloads trigger leaks or instability. The output differences here decide whether you move into deeper fuzzing or keep it purely as “command surface only”.
Delimiter and argument handling
Send valid commands with extra tokens and watch how it responds.
What changes your next move:
If it returns
usage:orunknown argumentstyle errors, you’ve got structured parsing and likely subcommands or flags worth enumerating.If it ignores the extra token and runs the command anyway, you can be more aggressive with wordlist-based probing.
If it disconnects, treat the service as brittle and keep probes short and low volume.
Empty input and prompt behavior
Some implementations only answer after a newline, or they emit different prompts when idle.
Signal to capture:
prompt changes
hidden banner lines
“invalid input” errors without any token
Newline and CRLF sensitivity
Some services are strict about line endings. Test LF and CRLF explicitly.
Interpretation:
If only CRLF works, keep using
\r\neverywhere (wordlists, fuzzing, scripted loops).If LF works but CRLF changes behavior, you’re likely hitting a different parser path. Keep both variants handy for later probes.
Echo and reflection checks
Send junk and see if the service reflects it back.
What matters:
If your input is echoed verbatim, output parsing gets harder and later payload tests become more meaningful.
If it returns a structured error, mine it for expected syntax and tokenization hints.
Length limits and truncation
Start small to avoid crashing brittle services. Scale only if it stays stable.
If 200 is stable, step up:
What to record:
truncation length (hard limit)
distinct error at a consistent boundary (buffer/validator limit)
disconnect or crash symptoms (candidate DoS or memory-safety bug path)
If you see crashes or repeated disconnects at a specific size, stop scaling and pivot to controlled fuzzing in a separate workflow.
Malformed input probes
These are quick signal checks for dangerous formatting or file/path handling code paths. Run them once, don’t loop them.
Format string markers
What changes your next move:
If you see hex-ish pointers, stack-ish values, or weird substitutions, treat it as a serious vuln lead and move to targeted fuzzing/exploit validation.
If it errors cleanly, it’s still useful: the error text often reveals internal function names or parsing stages.
Path-like payloads
What to look for:
any mention of files, directories, “not found”, “permission”, “open failed”
changes in timing or response size compared to normal invalid tokens
If you see file-oriented errors, prioritize hunting for commands that accept filenames, config paths, exports, or logs.
Capture output for diffing
When responses are noisy or multi-line, log the session and diff results between payloads.
References
-
nc(1) manualman.openbsd.org/nc.1 (opens in new tab)
Netcat flags for TCP connects and timeouts
Was this helpful?
Your feedback helps improve this page.