# CGMS Command Enumeration

- **URL:** https://hackindex.io/services/cgms/enumeration/cgms-command-enumeration
- **Path:** CGMS > Enumeration
- **Up:** [Enumeration](https://hackindex.io/services/cgms/enumeration.md)
- **Published:** 2026-01-04
- **Updated:** 2026-01-19

## CGMS Command Enumeration

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:

```bash
nc -nv $TARGET_IP $PORT
```

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

```bash
rlwrap -S 'cgms> ' nc -nv $TARGET_IP $PORT
```

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

```bash
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.

```bash
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:

```bash
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:

```bash
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

- [Ncat](https://nmap.org/ncat/) - Netcat-compatible client included with Nmap (useful alternative to nc)
- [nc(1) manual](https://man.openbsd.org/nc.1) - Netcat flags and behavior for interactive TCP sessions
- [rlwrap](https://manpages.debian.org/rlwrap) - Readline wrapper for interactive TCP sessions (history/editing)