Add 3 tutorials (3 files)
Browse Source
Daemon666 committed
parent 94ca0920f9
commit 7c60ac4d66a700e50ee5712da2c9c7d2ce04f1da
3 changed files
with 196 additions and 0 deletions
A
download-cs16-server-files-safely/en.md
+65 -0
A
fix-amxx-run-time-error-4/en.md
+48 -0
A
install-cs16-server-docker/en.md
+83 -0
download-cs16-server-files-safely/en.md
A
| @@ -0,0 +1,65 @@ | ||
| 1 | +--- | |
| 2 | +title: "Where to Download CS 1.6 Server Files Safely (No Backdoors)" | |
| 3 | +excerpt: "How to source CS 1.6 server files, plugins and mods without inheriting someone else's backdoor: trust SteamCMD and named GitHub orgs, and how to audit a suspicious .amxx." | |
| 4 | +category: "installation" | |
| 5 | +tags: "download, security" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>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 <code>amx_rcon</code> hook, a plugin that phones home your <code>rcon_password</code>, or a compiled <code>.amxx</code> 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.</p> | |
| 10 | + | |
| 11 | +<h2>1. Get the base server from SteamCMD, never a pack</h2> | |
| 12 | +<p>The Counter-Strike server (App 90) has exactly one legitimate source: Valve's own content delivery via SteamCMD with <code>login anonymous</code>. 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.</p> | |
| 13 | +<pre>./steamcmd.sh +force_install_dir /home/steam/hlds +login anonymous +app_update 90 validate +quit</pre> | |
| 14 | +<p>Follow <a href="/tutorials/install-cs16-dedicated-server-linux-steamcmd">the SteamCMD install</a>. This gives you a pristine Valve base you can diff everything else against.</p> | |
| 15 | + | |
| 16 | +<h2>2. Engine and game libraries from the named GitHub orgs</h2> | |
| 17 | +<p>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:</p> | |
| 18 | +<ul> | |
| 19 | +<li>ReHLDS and Metamod-r — the <code>rehlds</code> organisation.</li> | |
| 20 | +<li>ReGameDLL_CS and ReAPI — the maintainer's repositories under that org's ecosystem.</li> | |
| 21 | +<li>AMX Mod X — the official AMX Mod X project releases.</li> | |
| 22 | +</ul> | |
| 23 | +<p>If you want zero ambiguity, <a href="/tutorials/build-rehlds-from-source">build ReHLDS from source</a> and <a href="/tutorials/build-regamedll-from-source">ReGameDLL from source</a> in a container — then the binary is one you produced from a pinned commit.</p> | |
| 24 | + | |
| 25 | +<h2>3. Plugins: prefer source you can compile</h2> | |
| 26 | +<p>A <code>.sma</code> is readable Pawn; a bare <code>.amxx</code> is compiled bytecode you cannot easily inspect. The rule that removes most risk: <strong>never run an <code>.amxx</code> you cannot produce from source.</strong> Download the <code>.sma</code>, read it, and compile it yourself.</p> | |
| 27 | +<pre>cd addons/amxmodx/scripting | |
| 28 | +./amxxpc myplugin.sma | |
| 29 | +# produces myplugin.amxx you actually trust</pre> | |
| 30 | +<p>On this site every plugin ships as source and is compiled on demand, precisely so there is no opaque binary to trust.</p> | |
| 31 | + | |
| 32 | +<h2>4. How to audit a plugin you cannot avoid</h2> | |
| 33 | +<p>If you are handed a <code>.sma</code>, grep it for the primitives a backdoor needs before you compile it:</p> | |
| 34 | +<pre>grep -Ein "server_cmd|amx_rcon|rcon|socket_open|dbi_|sql|system\(|exec|set_localinfo|geoip" myplugin.sma</pre> | |
| 35 | +<p>Legitimate plugins use some of these. What should make you stop: a plugin that has no business touching RCON calling <code>server_cmd("amx_rcon ...")</code>, any <code>socket_open</code> to a hard-coded external host, or a plugin writing your <code>rcon_password</code> into a message. For a compiled-only <code>.amxx</code>, dump printable strings and look for URLs, IPs and command names:</p> | |
| 36 | +<pre>strings myplugin.amxx | grep -Ei "http|\.com|amx_rcon|socket|rcon_password"</pre> | |
| 37 | +<p>A clean plugin has nothing alarming here; a stealer usually leaves its callback host in plain text.</p> | |
| 38 | + | |
| 39 | +<h2>5. Diff any "modified" base against the Valve original</h2> | |
| 40 | +<p>If you were given a full server tree, compare it against a fresh SteamCMD install:</p> | |
| 41 | +<pre>diff -rq /home/steam/hlds_clean/cstrike /home/steam/hlds_suspect/cstrike</pre> | |
| 42 | +<p>Every file that differs is something the uploader changed. Config differences are expected; an altered <code>cs.so</code>, an extra <code>.so</code> in <code>addons/</code>, or an unexplained binary is a reason to throw the whole tree away and start from SteamCMD.</p> | |
| 43 | + | |
| 44 | +<h2>Common traps</h2> | |
| 45 | +<ul> | |
| 46 | +<li><strong>"Anti-backdoor" plugins</strong> — several advertised backdoor removers are themselves the backdoor. Do not install a binary whose only job is to be trusted.</li> | |
| 47 | +<li><strong>YouTube-description mega packs</strong> — bundled engine + plugins + "config" archives are unauditable by construction. Rebuild from clean sources instead.</li> | |
| 48 | +<li><strong>Cracked "premium" plugins</strong> — the crack is the payload often enough that it is not worth the gamble.</li> | |
| 49 | +<li><strong>An <code>.amxx</code> with no matching <code>.sma</code></strong> — treat as hostile until proven otherwise.</li> | |
| 50 | +</ul> | |
| 51 | + | |
| 52 | +<h2>Verification</h2> | |
| 53 | +<p>After building a server only from vetted sources, prove nothing is calling out. With the server running:</p> | |
| 54 | +<pre>ss -tunp | grep hlds_linux</pre> | |
| 55 | +<p>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 <code>rcon_password</code> and, if any suspect file ever touched the box, treat that password as already leaked. Continue with a clean <a href="/tutorials/install-amxx-plugin-files">plugin install</a>.</p> | |
| 56 | + | |
| 57 | +<h2>Run the whole thing unprivileged</h2> | |
| 58 | +<p>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:</p> | |
| 59 | +<pre>sudo adduser --disabled-password --gecos "" steam | |
| 60 | +sudo su - steam | |
| 61 | +# install and run everything as this user</pre> | |
| 62 | +<p>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:</p> | |
| 63 | +<pre>chmod -R o-w /home/steam/hlds | |
| 64 | +find /home/steam/hlds -name "*.so" -perm -o+w</pre> | |
| 65 | +<p>The <code>find</code> 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.</p> |
fix-amxx-run-time-error-4/en.md
A
| @@ -0,0 +1,48 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: Run time error 4: index out of bounds (AMX Mod X)" | |
| 3 | +excerpt: "Decode AMX Mod X 'Run time error 4: index out of bounds', read the debug trace to find the exact plugin and line, and fix the array bounds bug behind it." | |
| 4 | +category: "errors" | |
| 5 | +tags: "amxmodx, runtime-error" | |
| 6 | +image: "" | |
| 7 | +read_time: "7 min read" | |
| 8 | +--- | |
| 9 | +<p><code>Run time error 4: index out of bounds</code> is Pawn telling you a plugin read or wrote past the end of an array. In AMX Mod X that array is almost always indexed by a player id, and the value that blew the bounds is almost always <code>0</code> (world) or <code>33</code>+ (past the last valid client). The error does not crash the server, but the plugin's execution is aborted at that point, so whatever it was doing — awarding a kill, saving stats, printing a message — silently does not happen. This guide gets you from the log line to the offending source line.</p> | |
| 10 | + | |
| 11 | +<h2>1. Turn on the debug trace</h2> | |
| 12 | +<p>By default AMXX prints the error but not the line number. You need the trace. Add the <code>debug</code> flag to the plugin in <code>addons/amxmodx/configs/plugins.ini</code>:</p> | |
| 13 | +<pre>mystats.amxx debug</pre> | |
| 14 | +<p>Restart or <code>amxx reload</code>. Now the log carries a full call stack. Traces only exist if the plugin was compiled with debug info (it usually is); if you see <code>Debug info not available</code>, recompile the <code>.sma</code> without stripping symbols.</p> | |
| 15 | + | |
| 16 | +<h2>2. Read the trace</h2> | |
| 17 | +<p>The message lands in <code>addons/amxmodx/logs/L*.log</code> (dated files), and looks like this:</p> | |
| 18 | +<pre>L 07/14/2026 - 21:14:03: Run time error 4 (index out of bounds) | |
| 19 | +L 07/14/2026 - 21:14:03: [0] mystats.amxx::save_frags (line 214) | |
| 20 | +L 07/14/2026 - 21:14:03: [1] mystats.amxx::event_death (line 88)</pre> | |
| 21 | +<p>Read it top-down: the crash is at <code>save_frags</code>, <strong>line 214</strong>, of <code>mystats.sma</code>, called from <code>event_death</code>. That is the exact location. You do not need to guess.</p> | |
| 22 | + | |
| 23 | +<h2>3. Fix the bounds</h2> | |
| 24 | +<p>Open the source at that line. The overwhelmingly common cause is a per-player array declared one slot too small, or indexed by an id the code never validated. Player arrays must hold indices <code>0</code> through <code>32</code>, so they need <strong>33</strong> slots:</p> | |
| 25 | +<pre>new g_frags[33] // correct: indices 0..32 | |
| 26 | +// new g_frags[32] // wrong: index 32 is out of bounds</pre> | |
| 27 | +<p>The second common cause is using an attacker or victim id that can legitimately be <code>0</code> (the world, e.g. fall damage or a map trigger) without checking:</p> | |
| 28 | +<pre>new attacker = read_data(1) | |
| 29 | +if (attacker < 1 || attacker > get_maxplayers()) return PLUGIN_CONTINUE | |
| 30 | +g_frags[attacker]++</pre> | |
| 31 | +<p>Any event that reports a killer — <code>DeathMsg</code>, damage hooks — can hand you <code>0</code>. Guard every id before you index with it.</p> | |
| 32 | + | |
| 33 | +<h2>4. If it is not your plugin</h2> | |
| 34 | +<p>When the trace names a third-party plugin you did not write, you have three honest options: update it to a version that fixed the bug, report the line number upstream (you now have the exact one), or unload it. Do not "fix" it by widening an array blindly if you do not understand why the index went out of range — you will convert a clean abort into corrupted stats.</p> | |
| 35 | +<p>One more diagnostic habit worth keeping: note <em>what the player was doing</em> when the error fired. Error 4 is deterministic — the same action (a specific grenade, a knife kill, a fall death, a spectator switch) reproduces it. If your log shows the error only ever fires right after a round restart, or only when someone connects into slot 32, that pattern is a direct pointer at whether the bug is an off-by-one array size or an unvalidated id. The context around the trace is as useful as the line number.</p> | |
| 36 | + | |
| 37 | +<h2>Common errors</h2> | |
| 38 | +<ul> | |
| 39 | +<li><strong>Trace shows <code><no debug></code> instead of line numbers</strong> — you forgot the <code>debug</code> flag in <code>plugins.ini</code>, or the plugin was compiled with debug info stripped. Add the flag; recompile if needed.</li> | |
| 40 | +<li><strong>Error 4 fires only with a full server</strong> — a strong sign of a <code>[32]</code>-sized array: it never overflows until index 32 is actually used, which only happens when the 33rd slot fills.</li> | |
| 41 | +<li><strong>You confused it with error 10</strong> — <code>Run time error 10 (native error)</code> is a different failure (a native was called with bad arguments). See <a href="/tutorials/fix-amxx-run-time-error-10">that fix</a>. Error 4 is purely an array-index problem in Pawn.</li> | |
| 42 | +<li><strong>Index is a huge number like 2293</strong> — you are indexing with an entity id (a weapon, a grenade) into a player-sized array. Those are not the same id space; index a <code>[2048]</code> array or map entity ids separately.</li> | |
| 43 | +</ul> | |
| 44 | + | |
| 45 | +<h2>Verification</h2> | |
| 46 | +<p>After the fix, reload the plugin with the <code>debug</code> flag still on and reproduce the exact situation that triggered it — the same weapon, the same fall-damage death, the same full server. Watch the current log file:</p> | |
| 47 | +<pre>tail -f addons/amxmodx/logs/L$(date +%m%d)*.log</pre> | |
| 48 | +<p>No new error 4 across a full map, with the plugin actually doing its job (stats saved, message printed), means it is fixed. Once you are satisfied, you can drop the <code>debug</code> flag again for a small performance gain, though on most servers leaving it on is fine. For the wider picture of reading AMXX logs, see <a href="/tutorials/find-crashing-plugin">tracking down a bad plugin</a>.</p> |
install-cs16-server-docker/en.md
A
| @@ -0,0 +1,83 @@ | ||
| 1 | +--- | |
| 2 | +title: "How to Run a CS 1.6 Server in Docker" | |
| 3 | +excerpt: "Package a CS 1.6 dedicated server as a Docker container with the 32-bit runtime baked in, and get the UDP networking right so the master list can actually see it." | |
| 4 | +category: "installation" | |
| 5 | +tags: "docker, containers" | |
| 6 | +image: "" | |
| 7 | +read_time: "9 min read" | |
| 8 | +--- | |
| 9 | +<p>Docker is a genuinely good fit for CS 1.6: the engine is a fixed 32-bit binary with a small, well-known set of dependencies, so an image is reproducible and disposable in a way a hand-built VPS install never is. The one thing that trips people up is networking — a game server that answers A2S queries does not behave like a web app behind a port map, and getting that wrong is why a container "runs fine" but never shows in the server list.</p> | |
| 10 | + | |
| 11 | +<h2>1. A Dockerfile with the 32-bit runtime baked in</h2> | |
| 12 | +<p>HLDS is a 32-bit ELF binary, so the image must carry the i386 runtime. Build on a slim Debian base:</p> | |
| 13 | +<pre>FROM debian:12-slim | |
| 14 | + | |
| 15 | +RUN dpkg --add-architecture i386 \ | |
| 16 | + && apt-get update \ | |
| 17 | + && apt-get install -y --no-install-recommends \ | |
| 18 | + lib32gcc-s1 lib32stdc++6 libc6:i386 libncurses6:i386 \ | |
| 19 | + libcurl4:i386 ca-certificates tar wget \ | |
| 20 | + && rm -rf /var/lib/apt/lists/* | |
| 21 | + | |
| 22 | +RUN useradd -m -u 1000 steam | |
| 23 | +USER steam | |
| 24 | +WORKDIR /home/steam | |
| 25 | + | |
| 26 | +RUN mkdir -p steamcmd && cd steamcmd \ | |
| 27 | + && wget -q https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz \ | |
| 28 | + && tar -xzf steamcmd_linux.tar.gz && rm steamcmd_linux.tar.gz</pre> | |
| 29 | +<p>The exact i386 package names are the same ones covered in <a href="/tutorials/install-32bit-libraries-cs16-linux">the 32-bit library guide</a>; if a base image is newer or older, that guide lists the alternates.</p> | |
| 30 | + | |
| 31 | +<h2>2. Install App 90 at build time or on a volume</h2> | |
| 32 | +<p>You can bake the game into the image, but the cleaner pattern is to install it onto a named volume the first time the container runs, so image rebuilds do not re-download several hundred megabytes. Add an entrypoint script:</p> | |
| 33 | +<pre>#!/bin/sh | |
| 34 | +set -e | |
| 35 | +cd /home/steam/steamcmd | |
| 36 | +if [ ! -f /home/steam/hlds/cstrike/liblist.gam ]; then | |
| 37 | + ./steamcmd.sh +force_install_dir /home/steam/hlds \ | |
| 38 | + +login anonymous +app_set_config 90 mod cstrike \ | |
| 39 | + +app_update 90 validate +quit | |
| 40 | +fi | |
| 41 | +exec /home/steam/hlds/hlds_run -game cstrike \ | |
| 42 | + -ip 0.0.0.0 -port 27015 +sv_lan 0 \ | |
| 43 | + +map de_dust2 +maxplayers "${MAXPLAYERS:-20}"</pre> | |
| 44 | +<p>App 90's anonymous download often needs a second pass; if <code>cstrike/</code> is incomplete after the first run, delete the volume's marker and let it re-validate. This is the same quirk described in <a href="/tutorials/install-cs16-dedicated-server-linux-steamcmd">the SteamCMD guide</a>.</p> | |
| 45 | + | |
| 46 | +<h2>3. Get the networking right — use host networking</h2> | |
| 47 | +<p>This is the part that actually matters. CS 1.6 answers Steam A2S queries and heartbeats the master list from the same UDP socket it serves game traffic on. Under Docker's default bridge network with a published port, the source address/port of the server's <em>outbound</em> replies gets rewritten by the NAT layer, and the master server and some clients then see a mismatch and drop the server from the list. The reliable fix is host networking:</p> | |
| 48 | +<pre>docker run -d --name cs16 \ | |
| 49 | + --network host \ | |
| 50 | + -e MAXPLAYERS=20 \ | |
| 51 | + -v cs16-data:/home/steam/hlds \ | |
| 52 | + cs16-server</pre> | |
| 53 | +<p>With <code>--network host</code> the container shares the host's network stack, UDP 27015 is bound directly, and A2S/heartbeat traffic has the correct source. If you cannot use host networking (for example on a platform that forbids it), you must publish UDP <strong>and</strong> keep the same internal and external port number, and expect to fight master-list visibility:</p> | |
| 54 | +<pre>docker run -d --name cs16 \ | |
| 55 | + -p 27015:27015/udp -p 27015:27015/tcp \ | |
| 56 | + -v cs16-data:/home/steam/hlds \ | |
| 57 | + cs16-server</pre> | |
| 58 | + | |
| 59 | +<h2>4. docker-compose for something you will keep</h2> | |
| 60 | +<pre>services: | |
| 61 | + cs16: | |
| 62 | + build: . | |
| 63 | + network_mode: host | |
| 64 | + environment: | |
| 65 | + - MAXPLAYERS=20 | |
| 66 | + volumes: | |
| 67 | + - cs16-data:/home/steam/hlds | |
| 68 | + restart: unless-stopped | |
| 69 | +volumes: | |
| 70 | + cs16-data:</pre> | |
| 71 | +<p><code>restart: unless-stopped</code> replaces the <a href="/tutorials/hlds-systemd-service">systemd unit</a> you would otherwise write on bare metal.</p> | |
| 72 | + | |
| 73 | +<h2>Common errors</h2> | |
| 74 | +<ul> | |
| 75 | +<li><strong>Container runs, server never appears in the internet list</strong> — you are on bridge networking with port publishing. Switch to <code>--network host</code>. This is the single most common Docker-specific failure.</li> | |
| 76 | +<li><strong><code>./hlds_linux: No such file or directory</code></strong> — the i386 runtime is missing from the image. That ELF-interpreter error means <code>/lib/ld-linux.so.2</code> is absent; add the i386 packages to the Dockerfile.</li> | |
| 77 | +<li><strong>Players connect but the server ignores <code>rcon</code></strong> — RCON is TCP; under bridge networking you only published UDP. Publish TCP 27015 too, or use host networking.</li> | |
| 78 | +<li><strong>Re-downloads the game every start</strong> — you baked the install into the image layer instead of a volume, or the entrypoint's "already installed" check does not match your path.</li> | |
| 79 | +</ul> | |
| 80 | + | |
| 81 | +<h2>Verification</h2> | |
| 82 | +<pre>docker logs -f cs16</pre> | |
| 83 | +<p>Watch for the map load and the <code>Connection to Steam servers successful</code> line. Then from outside the host, query it and connect with a client to <code>HOST_IP:27015</code>. If it answers A2S but does not list, revisit networking — with host mode it will list. From there, layer on <a href="/tutorials/install-rehlds-on-linux">ReHLDS</a> by building it into the image instead of the stock engine.</p> | |
| 0 | 84 |
