Horse Museum installer is not malware. It is a false positive triggered by aggressive DRM-bypass techniques. To play on a private server without permanently modifying the original game executable, they built a custom engine that mimics malicious behavior.

Tools used: UniExtract, Ghidra, Procmoc, Wireshark.
All of this took me around 4 hours to find.

English is not my first language and I don't want it to be. Any mistakes are made out of pure hatred and disrespect for this language.

Hashes

The first thing I did was to calculate the file's SHA-256 hash and search for it on VirusTotal. If security vendors have already flagged it, we will see exactly what signatures tripped the alarms.

Get-FileHash -Algorithm SHA256 

The setup.exe:
33F12A3D861B8E6857E854C35FFB2E219DCE95A6E5FC2230D260B58A74FDFBB9

The config:
3E9EA7959C73F059742C9BDB552D9310BC629E548F8AC4883DB112B3832CE542

The setup.exe and the config went undetected.

Installer extraction

Putting setup.exe directly into Ghidra will likely waste your time. Because setup.exe is an installer (a "dropper" or "wrapper" if you fancy), Ghidra will only decompile the generic installation software (like Inno Setup or NSIS) rather than the actual game engine or the hidden payload.

A 0/60 detection score on the wrapper simply means the outer shell hasn't been fingerprinted by vendors yet.

UniExtract

With UniExtract I extracted the setup.exe to prove my point.

The files are standard components of the Nullsoft Scriptable Install System (NSIS):

• modern-wizard.bmp: a standard image file used for the installer's graphical UI wizard.

• nsDialogs.dll: an NSIS plugin utilized for creating custom dialog interfaces.

• System.dll: a standard NSIS plugin used to execute system-level commands during installation.

The setup.exe is a lightweight "stub" that contains no game files internally. Instead, it is programmed to reach out to a remote server and download the malicious (wow scary big word) payload directly into memory or a hidden folder only when the executable is actively running.

Network analysis

Since I was stupid enough to download it on my main computer, I grabbed WireShark next. ANY.RUN would have been better, because it provides an isolated environment that safely runs the file for you, while Wireshark only listens to the network traffic on the machine it is currently running on. On the serious note, don't download random goop from the internet unless you 100% know it doesn't contain anything malicious. I only happened to be lucky. Grab a VM or your friends computer to stay safe.

Come fight me, so-called suspicious horse game virus.

I opened WireShark and started downloading the game. Once the installation finished, I stopped the Wireshark capture and applied a tcp.flags.syn == 1 && tcp.flags.ack == 0 filter to see the raw list of external IP addresses the installer actually contacted during the unpacking phase.

If we look at the status bar at the bottom right, it shows that 936,308 packets were captured during this session. A normal Windows (VM) sitting idle or just running a local installer might generate a few thousand packets of background noise. Almost a million packets means the installer was aggressively communicating with the internet and downloading a massive payload.

After opening the Endpoints Menu, I found 7 IP adresses that has massive payload.

If we add up the Transmitted bytes from those top 6 external IPs (top row is your IP), it equals exactly 956 MB. They all teamed up to send you the payload.

If we look at the Info column for the TLSv1.2 packets, specifically the ones labeled Client Hello. Inside those parentheses is the SNI, which reads: SNI=gfs204n315.userstorage.mega.co.nz

The installer is not tunneling through Tor, nor is it connecting to a Russian botnet or a P2P swarm. It is simply establishing an encrypted HTTPS connection (Port 443) to MEGA.nz.
When you download a massive 1GB file from MEGA, their network splits the download across multiple Content Delivery Network (CDN) servers simultaneously to maximize your download speed. This perfectly explains the six different IP addresses transferring large chunks of data in the Endpoints list.

The IP address 193.109.100.204 that the community (?) flagged wasn't a malicious Tor node.
It was just a random Content Delivery Network (CDN) server. When you install the game, the setup.exe acts as a hidden download manager, pulling the private server files directly from a MEGA folder. Because MEGA splits the download across multiple servers to maximize speed, automated scanners see a massive, encrypted payload coming from multiple rotating IP addresses and assume the worst.

The game files

I have the 2014 version downloaded, I am using that next as an example.

The core executable and the fmod.dll audio libraries are completely legitimate, the presence of two specific files in this folder reveals exactly how the private server works.

winmm.dll is a standard Windows multimedia library that is supposed to live deep inside the C:\Windows\System32 folder. By placing a tiny, custom 50 KB version of it right next to the game executable, the developers are executing a classic DLL hijack.

When the PXStudioRuntimeMMO.exe game boots up, it automatically asks Windows for the winmm library. Because Windows prioritizes local files first, the game unknowingly loads the fake 50 KB file instead of the safe system file.
Once this fake winmm.dll has loaded, it almost certainly forces the game to inject the custom patch.dll directly into its active memory.

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

This entirely explains the memory injection rumors. The developers are using malware techniques to hijack the legacy client dynamically, bypassing the original DRM and server checks without having to permanently alter the copyrighted .exe file itself.

Memory injection

I dropped both the original game executable (PXStudioRuntimeMMO.exe) and patch.dll into Ghidra.

patch.dll
I traced its execution from the initial entry point. I located a hooking engine actively using Windows APIs (VirtualProtect) to unlock memory and write 0xE9 (JMP) instructions to detour code. By following the function cross-references backward, I found the master setup function passing specific hexadecimal target offsets (like 0x1D690) into this engine. I also analyzed the custom code the game gets detoured to, discovering a custom memory parser that calculates an FNV-1a checksum for 60-byte file headers.

PXStudioRuntimeMMO.exe

I loaded the legacy game client next, added the standard 0x00400000 base memory address to the 0x1D690 offset, and jumped to that exact location (0x0041D690).

By returning to the patch.dll file and jumping to that detour destination, we can see the exact custom code the private server developers wrote to bypass the original game's cryptography.

At the very end on line 26, you see (*DAT_101068cc)(param_3). This is a function pointer. In hooking development, this is called a "trampoline." After the DLL finishes doing its custom 60-byte math, it likely uses this pointer to jump back into the game's original code so the game can continue booting up normally without crashing.

What this means for us?
In legacy MMOs, network packets or game archive headers (like the ones on .cch files) are often read in fixed-size structures. This code strongly suggests that the .hors files downloaded from MEGA contain headers or data chunks that are exactly 60 bytes long.

Because the original game used an XOR algorithm (at 0x0041D690) to read official Star Stable files, the game would crash if it tried to read the modified .hors files. This detour intercepts the data, parses the custom 60-byte chunks using FUN_10002a20, and feeds the results back to the game.

The final nail in the coffin

Look at lines 46 and 51. The developers calculated a digital fingerprint. On line 46, the variable uVar4 is seeded with the exact hexadecimal value 0x811c9dc5. On line 51, the loop takes a byte of the file, XORs it against the seed (^), and then multiplies it by 0x1000193.

This specific combination of numbers and operations is the undeniable signature of a 32-bit FNV-1a hash. FNV-1a is a standard, incredibly fast hashing algorithm used to verify file integrity, not to encrypt secrets.

Conclusion

The developers completely gutted Star Stable's proprietary DRM and replaced it with a simple FNV-1a checksum.

The private server developers took standard game data and slapped a custom 60-byte header onto the very front of the file. When the hijacked legacy client tries to load a .hors file, this custom DLL intercepts it, locks the thread, and calculates the FNV-1a hash of the file. If the hash matches the header, the game accepts the file. It prevents players from modding the private server's files to cheat and because the official Star Stable client doesn't know how to read that 60-byte FNV-1a header, it crashes immediately if official developers try to inspect the .hors files using their internal tools. Because there is no actual encryption, extracting the assets is trivial. The .hors files are almost certainly just standard archives (like .zip or .cch files) with 60 bytes of junk data tacked onto the beginning.