Skip to content
HackIndex logo

HackIndex

CGMS Command Enumeration

3 min read Jan 19, 2026

CGMS typically exposes an interactive plaintext session. The goal is to map valid single-word commands, spot privileged/debug paths, and learn parsing rules that affect later input probing.

Interactive session baseline

Open a raw session:

┌──(kali㉿kali)-[~]
└─$ nc -nv $TARGET_IP $PORT

If the prompt is messy or you want history and line editing:

┌──(kali㉿kali)-[~]
└─$ rlwrap -S 'cgms> ' nc -nv $TARGET_IP $PORT

If nothing prints on connect, send a newline to trigger a prompt/banner:

┌──(kali㉿kali)-[~]
└─$ printf '\r\n' | nc -nv -w 5 $TARGET_IP $PORT

What changes your next move:

  • A banner or prompt that includes product/version strings is enough to pivot into targeted research.

  • A silent service that wakes up only after input usually has strict parsing. Do parsing tests early.

High-signal command probes

These tend to exist even on minimal implementations:

help
?
version
commands
help all
help verbose

If any of these return structured output, you’ve got a command surface worth brute-enumerating. If only one works, treat that as the entry point and try variations of that keyword.

Sample decision-driving output patterns:

  • Help lists categories or subcommands: build a quick command list from it and stop guessing.

  • Version returns build or vendor: snapshot it and pivot into known-default creds, config endpoints, or known bad builds.

  • Commands returns a flat list: move straight to privilege/debug checks and input handling tests.

Parsing rules that matter

Case sensitivity

Send the same token with different casing:

help
HELP
Help
version
Version

If only one casing works, your later brute-list must match exact case. If all work, it’s case-insensitive and you can normalize to lowercase.

Whitespace and argument handling

See if it accepts arguments, ignores them, or errors:

help test
version now
commands all

What to do with results:

  • If help <thing> works, it often reveals hidden commands or privilege-only topics.

  • If any argument triggers a distinct error, you’ve learned the parser is tokenizing and validating input, which is useful for later input handling probes.

Unknown command behavior

Throw junk and record how it fails:

test
aaaa
1234
.
/

What you’re looking for:

  • Explicit error strings that mention parsing, invalid tokens, or expected syntax.

  • Echoed input which hints at reflection and later input handling risk.

  • Connection drop on unknown input which tells you it’s brittle and you should keep probes low-noise.

Privileged, admin, and debug surface

Try likely mode switches and info dumps:

debug
verbose
admin
status
config
login
auth
user
pass

How to interpret quickly:

  • If login/auth prompts for username/password, you’ve confirmed an auth gate and can focus on credential paths and lockout behavior.

  • If status/config returns anything without auth, grab it and pivot into environment naming, downstream hosts, paths, or credentials leakage.

  • If debug/verbose toggles output, keep it enabled during later probes. Debug mode often prints extra parse errors, command handlers, or internal paths.

Separator and chaining tests

This checks whether the service supports multiple commands per line or interprets separators.

help;version
help|version
help && version
help version

Results that matter:

  • If any chaining works, later probing needs stricter output parsing because responses can be mixed.

  • If separators trigger distinct errors, that’s still useful input handling signal for the next phase.

Automate command discovery with a wordlist

When help output is weak, brute likely command tokens. Keep it simple and line-based.

┌──(kali㉿kali)-[~]
└─$ cat > cgms_cmds.txt <<'EOF'
help
?
version
commands
status
config
debug
verbose
admin
login
auth
user
pass
EOF

Send each token on its own line:

while IFS= read -r cmd; do
  printf '%s\r\n' "$cmd"
done < cgms_cmds.txt | nc -nv -w 5 $TARGET_IP $PORT

What to do with the output:

  • Pull out commands that produce non-generic responses, prompts, or multi-line blocks.

  • Keep a “confirmed commands” list and stop expanding once responses become repetitive.

Session capture for later parsing

If responses are multi-line or timing-sensitive, log a live session:

┌──(kali㉿kali)-[~]
└─$ script -q -c "nc -nv $TARGET_IP $PORT" cgms_session.log

This makes it easier to grep for keywords like error, unknown, usage, auth, password, admin, debug.

References