How to integrate a third-party anti-cheat into MU Online

Integrating a third-party anti-cheat into your MU Online server is one of the most delicate administration steps: done well, it closes holes the emulator's native protection doesn't cover; done poorly, it kicks legitimate players en masse and stains the server's reputation on day one. The difference between the two scenarios is the process. This guide shows how to bolt on an external solution in a controlled way — loading the module in the client, validating its presence on the server via a heartbeat, maintaining a whitelist and a rollback plan — so the protection goes into production without becoming a headache. The file names, keys, and thresholds cited here are examples that vary by season/emulator; use them as a concept reference, not as absolute values.

Prerequisites

Before touching any configuration, have these on hand:

• Administrative access to the server (RDP on the Windows VPS or SSH on Linux) and permission to restart the GameServer, ConnectServer, and the anti-cheat service.
• A mirror test environment — same season, same client files, and same emulator version as what runs in production. Never test an anti-cheat directly on the public server.
• A full backup of the client (Main.exe and the data folder) and of the server's configuration files (GameServerInfo.ini, CSConfig.ini, or equivalents).
• The third-party anti-cheat package with its official documentation: the module's DLL/executable, the license key (if any), and the vendor's integration guide.
• An alert channel already working (centralized log, Discord webhook, or email) to receive the anti-cheat events.
• Basic knowledge of hex editing or patching Main.exe, since many integrations require injecting the load call into the client.

If you don't have the server base set up yet, start with the guide on how to create a MU Online server and come back here once the environment is stable.

How a third-party anti-cheat fits into the architecture

MU Online is a client-server game with a notoriously fragile client: Main.exe runs on the player's machine, which has full control over memory, files, and traffic. A third-party anti-cheat works precisely in that hostile territory, usually fulfilling four functions:

1. File integrity — hashes the critical client files and detects a modified Main.exe, injected DLLs, or tampered data files.
2. Memory protection — monitors the game process against external read/write, DLL injection, and API hooks used by trainers and speed hacks.
3. Behavioral detection — observes patterns (impossible speed, teleport, out-of-range attacks) and flags them.
4. Link with the server — sends a periodic signal (the heartbeat) proving the module is alive and intact; without that signal, the server drops the session.

The point almost every beginner administrator gets wrong is thinking it's enough for the client to load the anti-cheat. Without the server-side link, the player simply closes the anti-cheat process and plays freely. The real integration is a two-way street: the client runs the module and the server demands proof that it's running.

Protection layers and where the third party comes in

The third-party anti-cheat shines in the last two rows — memory protection and attestation — which are exactly the hardest to do with the emulator alone. The first layers remain the server's responsibility. Don't disable anything native when adding the third party; add, don't replace.

Stage 1 — Prepare the mirror test environment

Never integrate an anti-cheat directly in production. Set up a mirror:

1. Provision a VPS or a separate machine with the same Windows Server and the same season as the real server.
2. Copy the server binaries and a recent snapshot of the database (it can be reduced, with a few test accounts).
3. Adjust the test client's ConnectServer to point to the mirror's IP, not the public one.
4. Create three to five test accounts: one "clean" (intact client), one with an altered Main.exe, one without the anti-cheat module, and one with a known trainer, if you have one to test detection.

This mirror is where every threshold adjustment happens before it gets anywhere near real players.

Stage 2 — Load the module in the client

The anti-cheat needs to start together with the game. There are three common approaches, from cleanest to most invasive:

• Via the launcher: the updater/launcher starts the anti-cheat process and only then brings up Main.exe. It's the preferred approach because it doesn't touch the game binary.
• Injection through Main.exe: you patch the client to load the anti-cheat DLL at startup. Requires a backup and careful hex editing.
• Wrapper/bootstrap: an intermediate executable starts the anti-cheat, validates, and hands execution over to the game.

Example configuration on the launcher side (illustrative keys, they vary by season/emulator):

; launcher.ini
[AntiCheat]
Enabled=1
ModulePath=.\anticheat\acmod.exe
StartBeforeClient=1
LicenseKey=YOUR-KEY-HERE
FailIfMissing=1     ; don't launch the game if the module fails to start

If FailIfMissing is on, a client without the module won't even open the game — which is good, but it requires the updater to actually distribute the module to everyone. That's why the launcher and the anti-cheat go together.

Stage 3 — Configure the anti-cheat service on the server

Most third-party solutions run a service/daemon on the server side that receives the clients' reports and exposes the verdict. Configure it before enabling any blocking:

; acserver.conf (example — varies by vendor/season)
listen_port = 44405
heartbeat_interval = 15      ; seconds between client signals
heartbeat_grace = 45         ; tolerance before considering it dead
mode = log_only              ; start WITHOUT kick/ban
report_endpoint = http://127.0.0.1:8080/ac/report
webhook_alert = https://discord.com/api/webhooks/...

Notice mode = log_only. This is the single most important point in the whole guide. You start by only logging, never punishing. Only after observing the real data do you raise the severity.

Stage 4 — Tie the heartbeat to the GameServer

The heartbeat is what stops the player from closing the anti-cheat and continuing to play. The logic is:

1. The client module sends a signed signal every N seconds to the anti-cheat service.
2. The service marks the session as "alive" and intact.
3. The GameServer, on each maintenance tick, checks whether each logged-in session has a valid heartbeat within the tolerance window.
4. A session without a valid heartbeat within the window is dropped (kicked).

If you have the GameServer source, tie the check into the connection-maintenance loop. If you don't, operate via an external query: a small service reads the anti-cheat status and issues a kick via a GM command/API for the accounts without a signal. Pseudocode for the check:

for each active session in the GameServer:
    status = anticheat.query(session.account, session.ip)
    if status.last_heartbeat > now - heartbeat_grace:
        continue        # ok, module alive
    else:
        log_alert(session, "heartbeat missing")
        if mode != log_only:
            kick(session, reason="anti-cheat inactive")

Note again the if mode != log_only. While in log mode, you only collect — no one is dropped by mistake.

Stage 5 — Whitelist and exception handling

Every integration needs escape valves so it doesn't punish those it shouldn't:

• Account whitelist: GM, tester, and support-team accounts should not be dropped by behavioral rules during maintenance.
• Module/process whitelist: legitimate overlays (recorders, accessibility tools) can trigger memory protection. Document and allow the known ones.
• Client hash whitelist: when you release a new patch, the Main.exe hash changes; update the list of valid hashes before publishing, or everyone becomes a false positive.

Example:

[Whitelist]
accounts = admin, gm_bruno, tester01
processes = obs64.exe, nvidia_share.exe
client_hashes = 9f2a...c1, a70b...44   ; hash of the current patch and the previous one

Keeping the previous patch's hash for a few days avoids dropping those who haven't updated yet.

Stage 6 — Raise the severity gradually

With log data in hand, raise the severity in steps, never all at once:

1. Days 1–3: log_only. Collect alerts, identify false positives, adjust whitelists and thresholds.
2. Days 4–6: kick. Start dropping sessions that violate clear rules (no heartbeat, invalid hash), but still without banning.
3. Day 7+: selective ban. Only for high-confidence violations (detected DLL injection, known trainer). Keep the behavioral rules on kick for longer, since that's where false positives are born.

At each step, watch the event volume. A spike of kicks right after raising the severity almost always means a poorly calibrated threshold, not a horde of cheaters.

Stage 7 — Alerts and observability

Turn on the alerts from log mode:

• A Discord/email webhook for each high-severity event.
• A centralized log with account, IP, violation type, and timestamp for later investigation.
• A count panel (even a simple one) showing events per hour — anomalous spikes help distinguish a real attack from a config bug.

Cross-referencing the anti-cheat events with the GameServer's native logs is what turns a loose alert into an investigable case.

Common errors and fixes

Launch checklist

• Full backup of the client and server configs taken and tested
• Mirror environment set up with the same season/emulator
• Module loading via the launcher (or patch applied with a backup)
• Anti-cheat service running in log_only
• Heartbeat tied to the GameServer and tested (closing the module drops the session on the mirror)
• Whitelist of accounts, processes, and hashes filled in
• Alerts (Discord/email) receiving test events
• Test scenarios validated: clean client, altered hash, no module, no heartbeat
• Rollback plan documented (how to return to the no-anti-cheat state in minutes)
• Severity-raising schedule defined (log → kick → ban)
• Emulator's native layers confirmed active (they weren't disabled)
• Notice to players published about the new protection and possible early instability

Rollback plan

Have the way back ready before enabling any blocking. A well-done rollback is: putting the service in log_only (or turning it off), removing the heartbeat requirement in the GameServer, republishing the launcher without FailIfMissing, and restoring Main.exe from backup if you applied a patch. Document each step with the exact command so that, under the pressure of a packed Saturday night, you execute it in minutes and not in a panic.

Integrating a third-party anti-cheat is less about the tool and more about process discipline: mirror, log mode, whitelist, gradual escalation, and a ready rollback. Do it in that order and the protection goes into production protecting the server — not the cheaters from your reputation.

Frequently asked questions