These findings document the specific vulnerabilities confirmed in the original Director/Shockwave First Star Online system. Every finding below is backed by preserved source evidence — the legacy client scripts and server Lingo scripts that make up the primary evidence base. The goal is not to criticize the legacy system: it operated at a different time under different constraints. The goal is to make sure the rewrite preserves gameplay and content without accidentally recreating any of the trust model problems, file handling patterns, credential handling, or privileged control paths that would be unacceptable in a modern public service.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/TaylorZaneKirk/MMO-Project/llms.txt
Use this file to discover all available pages before exploring further.
Authentication vulnerabilities
The legacy authentication model couples credential storage directly to gameplay persistence in several unsafe ways. Plaintext password handling. The client sends a raw#password field in the login payload. The server loads the character file and compares the provided password directly to a stored field inside that file. Character creation writes the client-provided packed character payload directly to disk. This means password handling is tightly coupled to a mutable gameplay file format rather than to a dedicated account system. Evidence: casts/Internal/BehaviorScript 26 - connectToNetServer button.ls:38-46; fsoserver/Scripts/GlobalScripts.ls:171-205.
Static shared encryption material embedded in the client. The client ships hard-coded secret-like values used during connection setup, including TheKey = "%!!@*8675309(!)#&" and a fixed "nopass" bootstrap value. Any secret shipped in the client must be treated as public. If these values influence trust, encryption, or protocol admission, the model is fundamentally unsafe. Evidence: casts/Internal/BehaviorScript 26 - connectToNetServer button.ls:37-46.
Client-selected account names used without server-side validation. The login flow accepts client-assembled character payloads that include identity fields without independent server-side verification of the claimed identity. The character record itself acts as the authentication store, making it impossible to safely separate account ownership from gameplay state.
Client-authoritative trust model
The legacy system accepts mutable gameplay state directly from the client in multiple critical paths. Client-supplied bank names, inventory values, and currency changes accepted by the server. The client assembles a packedCharFile string from local runtime fields — including stats, gold, spells, skills, guild, and hunger — and sends that blob using subject cq1. The server writes the received payload directly to DAT\CHAR\<user>.txt after only a narrow name check. This is a strongly client-authoritative persistence path. Evidence: casts/Scripts/MovieScript 16.ls:84-217; fsoserver/Scripts/GlobalScripts.ls:290-310.
Privileged behavior protected only by hidden UI or client-side flags. The server returns flags like ImTrue and ModTrue to the client during login to signal administrator or moderator status. Enforcement of those roles depends on client-visible booleans and flat-file role lists rather than on a separate admin trust boundary. Evidence: fsoserver/Scripts/GlobalScripts.ls:217-228.
Transport and update vulnerabilities
Unauthenticated admin and content-editing messages. Privileged commands includingSupaWarp, KickTheDOOD, BanPlayer, SaveTheBigMap, FileTransToMe, and FileTransToYou are all handled inside the same IncomingMessage switch as ordinary player actions. Privilege checks rely on entries in flat files like immortals.txt and File Admins.txt rather than on a separate administrative trust boundary. Evidence: fsoserver/Scripts/GlobalScripts.ls:72-98 and 241-287.
Executable updates downloaded over unencrypted HTTP. The client downloads an executable update and fetches server/IP discovery text from plain HTTP. No signature verification is performed on the downloaded binary. The client only compares a server-provided version string and directs the user to a website on mismatch. Evidence: casts/DBAdmin/CastScript 44.ls:1-5; casts/Internal/BehaviorScript 149.ls:1-3.
Writes into Windows system directories. The file-transfer and update paths include references to Windows system-level directory structures, meaning corrupted or malicious payloads could affect the host operating system rather than being contained to the game installation.
Economy and transaction risks
Economy-changing operations throughout the legacy server follow a non-transactional pattern: read one or more text files, mutate packed string fields in memory, write one file, then write another. There is no transactional boundary across these multi-step operations. This pattern appears in shop register payouts (NPC and player files written separately,fsoserver/Scripts/shop.ls:124-167), player-to-player gold transfer (loser file then winner file, fsoserver/Scripts/quests.ls:86-114), player-to-player item trade (recipient file then sender file, fsoserver/Scripts/quests.ls:3-79), blackjack outcomes (loser then winner, fsoserver/Scripts/games.ls:1-29), and vault and chest operations. A partial write, overlapping request, or server interruption at any of these points could leave economy state permanently inconsistent and enable item or currency duplication.
Admin command surface
The following privileged message subjects are accessible over the standard game transport with no proper authentication boundary separating them from ordinary player actions:KickTheDOOD— forcibly disconnects a named playerBanPlayer— applies a ban by mutating the target’s character save file with aBANNED!!!!!!!!!!!prefixSupaWarp— teleports a player to an arbitrary map coordinateFileTransToMe— downloads a file from the server using a client-supplied folder and filenameFileTransToYou— uploads a file to the server underC:\FSOServer\DAT\using a client-supplied path
SaveGuild) and item saves (SaveItems), writing directly under DAT\GUILDS\ and adjacent directories using the filename fragment from the client payload. Evidence: casts/Internal/CastScript 292 - exileguild.ls:22-24; fsoserver/Scripts/GlobalScripts.ls:315-330.
Rewrite remediation
The modern backend addresses each finding category through the following architectural requirements:Passwords: bcrypt via ASP.NET Identity PasswordHasher
All passwords are stored only as salted hashes using
PasswordHasher<T> from ASP.NET Identity. No plaintext storage, no reversible encoding, and no credential-bearing payloads echoed to the client. Accounts are separated from characters in the database schema, so credential handling is entirely independent of gameplay persistence.Trust model: server-authoritative, clients send intent only
All mutations to character state, inventory, equipment, currency, guild membership, and economy-affecting values are performed exclusively by the server. Clients send player intent — move, equip, buy, cast, chat — and the server validates, applies, and persists the result. No client-assembled save blobs are accepted.
Transport: WebSocket over TLS; no executable update paths
The planned session transport is WebSocket over TLS. No executable content is downloaded through the game client. No HTTP discovery or update flows are used. Shared secrets and signing keys are kept server-side only; the client ships no trust material.
Economy: PostgreSQL transactions for all inventory and equipment mutations
Every economy-changing operation — inventory changes, equipment changes, trade, banking, vault access, NPC shop transactions, and loot drops — runs inside a PostgreSQL transaction with row-level locking. Partial writes and duplicate requests cannot leave economy state inconsistent. All economy operations are auditable.
Admin: separate authenticated tooling built in Phase 6
Moderation, content publishing, map editing, NPC management, and file operations are built as separate authenticated admin services with role-based access control in Phase 6. None of these actions are accessible over the gameplay transport. Every privileged action is logged with actor, target, timestamp, and before/after state.
The legacy system’s security posture is the primary reason the rewrite uses a server-authoritative architecture from Phase 2 onward. The client-authoritative persistence path, the embedded trust material, and the non-transactional economy updates are not incidental flaws — they are structural properties of the original stack that make it impossible to safely extend for a modern public service.