Reverse Engineering a legacy MMO private server

When a highly anticipated private server for a legacy MMO (codenamed "Horse Museum") finally dropped, the community's excitement quickly turned into a panic. Security vendors were throwing generic flags, automated scanners were detecting massive encrypted payloads originating from rotating IP addresses, and rumors of a "Russian botnet" and "Tor spyware" spread like wildfire.

Horse Museum was another Star Stable private server, that closed around the end of October. Star Stable (officially Star Stable Online, or SSO) is a 3D MMORPG focused on horses, adventure, friends and magic. The first server opened around 2011.
Altough the game is gone, I still wanted to post my findings here. Maybe this is going to help someone, or clear the smoke a little bit.

I have been playing this game since 2012, and seeing all that misinformation caused me physical pain. I’m not supporting this project, but calling it malware without any proper research is not okay.

Tools used: Ghidra, Wireshark, UniExtract.

Dropper, network analysis

The first step was analyzing the setup.exe installer. A quick SHA-256 hash check on VirusTotal returned a 0/60 detection score. However, a clean score on an installer wrapper just means the outer shell hasn't been fingerprinted yet.

Using UniExtract, I unpacked the executable. It contained no actual game assets, only standard Nullsoft Scriptable Install System (NSIS) components:

• modern-wizard.bmp (UI graphics)

• nsDialogs.dll (Custom dialog interfaces)

• System.dll (System-level command execution)

The setup.exe is a lightweight dropper stub programmed to reach out to a remote server and inject the 1GB payload directly into the disk only when actively running.

To see where the dropper was communicating, I loaded up Wireshark and applied a tcp.flags.syn == 1 && tcp.flags.ack == 0 filter. The session captured 936,308 packets. Summing the transmitted bytes from the top six external IPs equaled exactly 956 MB.

Pulling 150 MB chunks from six completely random IP addresses simultaneously mimics the behavior of Peer-to-Peer (P2P) swarms or botnets, which triggered the community's malware alarms. Also, the launcher utilized Tor routing protocols to obscure its initial backend handshake.

Why use Tor? Copyright evasion.

Tor tunneling hides the backend authentication server's IP address from corporate lawyers attempting to send automated Cease and Desist letters. The developers are using malware obfuscation techniques to survive DMCA takedowns.

However, the bulk payload itself is not distributed via Tor. I inspected the TLSv1.2 Client Hello packets, and they revealed the true source in the Server Name Indication (SNI): SNI=gfs204n315.userstorage.mega.co.nz

The installer is simply establishing an encrypted HTTPS connection to MEGA.nz, which natively splits large downloads across multiple Content Delivery Network (CDN) servers to maximize speed. It isn't a botnet.

DLL hijack

Once the files were downloaded, looking at the root game folder revealed exactly how the developers intended to bypass the game's original DRM without permanently cracking the copyrighted .exe (which carries heavier legal penalties).

Right next to the legit executable (PXStudioRuntimeMMO.exe) was a tiny 50 KB winmm.dll.

winmm.dll is a standard Windows multimedia library that belongs inside C:\Windows\System32. Because Windows prioritizes local directory files over system-level files during execution, the game unknowingly loads this custom 50 KB proxy instead of the safe Windows library.

This is a what we call a DLL Hijack.

Decompiling this fake winmm.dll in Ghidra shows a small script that side-loads a secondary custom payload called patch.dll into the game's active memory, and then quietly passes all actual multimedia requests back to the real Windows system.

Static analysis

patch.dll is where the magic happens. It overwrites the game's network functions in real-time, redirecting login attempts away from the official servers and pointing them toward the private server's backend.

Tracing its execution from the entry point in Ghidra, I located a hooking engine utilizing the Windows API VirtualProtect to unlock memory pages. It physically overwrites the first few bytes of the game's legitimate networking functions with the 0xE9 (JMP) assembly instruction.

By following the function cross-references backward, I found the master setup function passing specific hexadecimal target offsets into this engine.
The private server targets the offset 0x1D690.
By loading the legacy game client into Ghidra and adding the standard base memory address, we find the exact injection point:
0x00400000 + 0x1D690 = 0x0041D690

Jumping to 0x0041D690 in the original executable reveals the game's native XOR decryption loop. The developers intentionally detoured the execution flow right before the game attempts to read its proprietary .cch archive files.

DRM bypass

By returning to patch.dll and following the JMP detour destination, I found the custom memory parser the developers wrote to replace the game's original cryptography.

In legacy MMOs, network packets and game archive headers are often read in fixed-size structures.
The decompiled code utilizes a modulo operation pointing to 0x3c (equals to 60 in decimal), strongly suggesting that the custom .hors archive files downloaded from MEGA contain headers that are exactly 60 bytes long.

Inside this parser (labeled FUN_10002a20), I found the final nail in the coffin.

• uVar5 is seeded with 0x811c9dc5,
• the loop XORs a byte of the file against the seed,
• it multiplies the result by 0x1000193.

FNV-1a is a standard, incredibly fast hashing algorithm used to verify file integrity. It is not encryption. The developers completely gutted the original proprietary DRM and replaced it with a simple FNV-1a checksum to prevent players from modding the private server's files to cheat.

Because the official game client doesn't know how to read this custom 60-byte FNV-1a header, it crashes immediately if developers try to inspect the .hors files using official internal tools.

At the very end of the function, a "trampoline" pointer (DAT_101068cc)(param_3) jumps back into the game's original code so the boot sequence can continue natively:

Conclusion

The malware panic was a false positive. The private server developers are simply utilizing aggressive evasion techniques (Tor tunneling, DLL hijacking, and inline hooking) to bypass corporate DRM and network checks without distributing a permanently cracked executable.

Because there is no actual encryption, extracting the proprietary assets is trivial. The .hors files are just standard game archives with 60 bytes of FNV-1a junk data tacked onto the beginning.

That's all from me, stay curious and don't let others fool you.
With love... from Navier