The CS 1.6 scene runs on decades of re-uploaded "ready servers", forum attachments and mystery archives, and a large share of them carry a backdoor — an RCON stealer, a remote amx_rcon hook, a plugin that phones home your rcon_password, or a compiled .amxx that opens a socket. You cannot audit a stripped-down engine binary by eye, so the only real defence is sourcing. This guide is about where files should come from and how to check the ones you cannot avoid trusting.
1. Get the base server from SteamCMD, never a pack
The Counter-Strike server (App 90) has exactly one legitimate source: Valve's own content delivery via SteamCMD with login anonymous. A "full CS 1.6 server download, plugins included" from a file host is the worst possible starting point — you inherit every modification the uploader made, visible or not.
./steamcmd.sh +force_install_dir /home/steam/hlds +login anonymous +app_update 90 validate +quit
Follow the SteamCMD install. This gives you a pristine Valve base you can diff everything else against.
2. Engine and game libraries from the named GitHub orgs
ReHLDS, ReGameDLL_CS, Metamod-r, ReAPI, Reunion and AMX Mod X are all open source with official release pages. Take binaries only from the project's own GitHub releases:
- ReHLDS and Metamod-r — the
rehldsorganisation. - ReGameDLL_CS and ReAPI — the maintainer's repositories under that org's ecosystem.
- AMX Mod X — the official AMX Mod X project releases.
If you want zero ambiguity, build ReHLDS from source and ReGameDLL from source in a container — then the binary is one you produced from a pinned commit.
3. Plugins: prefer source you can compile
A .sma is readable Pawn; a bare .amxx is compiled bytecode you cannot easily inspect. The rule that removes most risk: never run an .amxx you cannot produce from source. Download the .sma, read it, and compile it yourself.
cd addons/amxmodx/scripting ./amxxpc myplugin.sma # produces myplugin.amxx you actually trust
On this site every plugin ships as source and is compiled on demand, precisely so there is no opaque binary to trust.
4. How to audit a plugin you cannot avoid
If you are handed a .sma, grep it for the primitives a backdoor needs before you compile it:
grep -Ein "server_cmd|amx_rcon|rcon|socket_open|dbi_|sql|system\(|exec|set_localinfo|geoip" myplugin.sma
Legitimate plugins use some of these. What should make you stop: a plugin that has no business touching RCON calling server_cmd("amx_rcon ..."), any socket_open to a hard-coded external host, or a plugin writing your rcon_password into a message. For a compiled-only .amxx, dump printable strings and look for URLs, IPs and command names:
strings myplugin.amxx | grep -Ei "http|\.com|amx_rcon|socket|rcon_password"
A clean plugin has nothing alarming here; a stealer usually leaves its callback host in plain text.
5. Diff any "modified" base against the Valve original
If you were given a full server tree, compare it against a fresh SteamCMD install:
diff -rq /home/steam/hlds_clean/cstrike /home/steam/hlds_suspect/cstrike
Every file that differs is something the uploader changed. Config differences are expected; an altered cs.so, an extra .so in addons/, or an unexplained binary is a reason to throw the whole tree away and start from SteamCMD.
Common traps
- "Anti-backdoor" plugins — several advertised backdoor removers are themselves the backdoor. Do not install a binary whose only job is to be trusted.
- YouTube-description mega packs — bundled engine + plugins + "config" archives are unauditable by construction. Rebuild from clean sources instead.
- Cracked "premium" plugins — the crack is the payload often enough that it is not worth the gamble.
- An
.amxxwith no matching.sma— treat as hostile until proven otherwise.
Verification
After building a server only from vetted sources, prove nothing is calling out. With the server running:
ss -tunp | grep hlds_linux
You should see only the UDP listener on 27015 (and RCON). An unexplained outbound TCP connection from the server process is exactly what a stealer looks like — investigate it before the server goes public. Then rotate secrets: set a long rcon_password and, if any suspect file ever touched the box, treat that password as already leaked. Continue with a clean plugin install.
Run the whole thing unprivileged
Sourcing is your first line of defence; containment is your second. Even a vetted stack can have a real, unpatched exploit — this is twenty-year-old netcode. Run the server as an unprivileged user, never root, so that a compromise is confined to that account rather than the whole box:
sudo adduser --disabled-password --gecos "" steam sudo su - steam # install and run everything as this user
Keep the game files owned by that user and not world-writable, so a plugin that is later found to be hostile cannot rewrite your engine or other plugins on disk:
chmod -R o-w /home/steam/hlds find /home/steam/hlds -name "*.so" -perm -o+w
The find should return nothing. Combined with clean sourcing, an unprivileged runtime, and no opaque binaries you cannot reproduce, you have removed the three ways a "ready server" pack usually ends badly: an engine you cannot audit, a plugin phoning home, and a compromise that reaches root. That is the whole game — there is no antivirus for CS 1.6, only provenance and least privilege.
