Most private server downloads are one of two very different things, and the difference decides how much trust you are being asked for.

In the common case, the project distributes nothing that executes and expects you to bring your own client. The emulator, the patch files and the database stay on the operator's side, and the only thing at risk is your account on their realm — which is why our 1.12.1 client checklist can be mostly about version numbers and provenance.

The other case is different in kind. If a project hands you a complete modified game client, then the untrusted part is no longer only the server. It is the archive you are about to extract and run.

Which model are you in?

The second and third rows are where the interesting failures live.

What a download page should publish

Six things. A project that publishes all six is telling you it expects to be checked.

1. A hash for each archive — SHA-256 is the current baseline. No hash means the download is unverifiable by construction.
2. A file manifest or at least the archive's contents, so you know what you are extracting before you extract it.
3. A code signature on any executable the project ships, not just on the installer wrapper.
4. The build number the archive corresponds to. VMaNGOS, for example, documents 5875 as the final 1.12.1 client and states which earlier builds it also supports — that is the level of specificity worth expecting.
5. A versioned release or repository the download can be traced to. A pinned release tag is verifiable; a folder on a file-sharing site is not.
6. A changelog for modified files. "We changed these files and here is why" is the difference between a patched client and an opaque one.

One tracked Wrath realm illustrates what the other end looks like. When it was added to a community directory, its download page offered complete clients at 17.6 GB and 27 GB, both pointing at the same folder on a third-party file host, with no SHA-256 hash, no manifest, no code signature, no published correspondence between its stated build and the archive contents, and no project-specific public source repository. The emulator underneath is a standard open-source core — that part is not the issue. The issue is that the executable payload itself was the unverified component, which is a materially worse position than an ordinary private server puts you in.

How to actually verify a hash

Computing a hash is one command.

# macOS / Linux
shasum -a 256 wow-client.zip

# Windows PowerShell
Get-FileHash .\wow-client.zip -Algorithm SHA256

:: Windows, no PowerShell
certutil -hashfile wow-client.zip SHA256

Then comes the part people skip. Compare it against a hash you got from somewhere other than the download page.

A hash printed next to its own download link proves one thing: your transfer completed without corruption. It does not protect you from a hostile or compromised distribution, because whoever controls the page controls both the link and the number. To get real assurance, the expected hash has to arrive through a second channel — a pinned message in the project's Discord that predates the download, an archived snapshot of the page from before your visit, a release note with a date, or an independent mirror published earlier.

If no hash exists in any channel, the honest conclusion is not "it is probably fine." It is "this cannot be verified," and the rest of this guide is about reducing what that costs you if you proceed anyway.

Run it like you do not trust it

• Leave your operating system's protections switched on. On macOS that means keeping the quarantine attribute intact rather than removing it to silence a Gatekeeper prompt; on Windows it means keeping SmartScreen and Defender active. "Temporarily disable your antivirus" is a request to lower your defences, and it should be treated as a cost, not a step.
• First launch inside a sandbox or a virtual machine. Windows Sandbox is built into Pro and Enterprise editions for exactly this; a throwaway VM works everywhere else. If the client behaves normally there, you have learned something without risking your main install.
• Never grant administrator rights to a launcher that does not explain why. Writing into its own game folder does not require elevation. Installing services or drivers does, and that is a different level of trust.
• Watch what it talks to on first run. A client that starts a session with its own realm's login server is behaving normally. Outbound traffic to unrelated hosts on first launch is worth investigating before you log in anywhere.
• Keep a clean copy of the original client — or at least of the archive — so a patched installation can be thrown away rather than repaired.
• Use unique credentials. A realm-specific username, a password you use nowhere else, and an email you are willing to have leaked. Never a Battle.net password.

Launcher behaviour: normal versus not

The required-addon case is a mild version of the same problem. Some servers depend on one specific addon to drive a custom system — a multiplayer bot framework, for instance — and the documentation for it may point at the addon author's own wiki rather than a pinned release. That is a third party you did not choose, inside a game you are already trusting less than usual.

The ten-minute version

1. Does the download page publish a hash? If not, stop and note that.
2. Does it publish a manifest, a build number, and a changelog of modified files?
3. Is there a source repository, or a pinned release, the download can be traced to?
4. Compute the hash locally and compare it to a value obtained from a second channel.
5. If you cannot obtain a second-channel hash, download it into a sandbox or VM, not your main machine.
6. Do not strip OS protections to make it run; if it needs that, that is the finding.
7. Do not grant elevation to anything that has not explained what the elevation is for.
8. Do not reuse credentials, and assume anything you type into an unverified client is available to whoever built it.
9. Keep your own clean client and your own backups.
10. If a project cannot tell you which files it modifies, treat its client as non-standard — and treat every recommendation it makes about your machine the same way.

This is the same habit of mind as reading a directory entry and checking a population number: not cynicism, just deciding what a claim is worth before you act on it. For the steps that come after you decide to commit, see evaluating a community realm and the shutdown backup checklist.