How to create GM/Admin accounts securely in MU Online

GM and Admin accounts are the master keys of your MU Online server. A single compromised administrative account lets an attacker create perfect items, inject infinite zen, delete characters, alter rankings and destroy the economy in minutes — and often the server owner only notices when players start complaining. Creating these accounts is not hard; creating them securely takes care with the password, access level, isolation, logging and a revocation plan. This tutorial shows the complete process, from the database INSERT to continuous auditing, always remembering that table names, fields and ctl_code values are examples that vary by season/emulator.

Prerequisites

• Access to the server's database, via SQL Server Management Studio (SSMS) for MSSQL-based emulators or phpMyAdmin/HeidiSQL for MySQL-based ones.
• Knowledge of your emulator's schema: knowing whether the accounts table is MEMB_INFO, accounts or another, and which field controls the level (ctl_code, AccountLevel, etc.).
• A password manager to generate and store strong, unique passwords.
• A test environment to validate the creation before touching production.
• Access to the GameServer's configuration file, in case your emulator uses a GMList in addition to ctl_code.
• A minimal defined policy: who will have access, at what level, and how access will be revoked. If you are still building the server from scratch, start with how to create a MU Online server.

How MU Online defines an administrative account

In most emulators, an account's access level is a number stored in the database. On servers based on the classic schema, the table is MEMB_INFO and the field is ctl_code. The value 0 is a regular player; higher values unlock commands and privileges. The exact scale changes between distributions — in some, 1 is already Admin; in others there is a gradation (1 = GM, 8 = Admin). Some modern emulators ignore ctl_code and use a GMList in the GameServer config, where you map a nickname to a numeric level. Many use both. Before creating any account, find out which model your server uses.

The table below shows a typical example scale:

Step 1 — Generate a strong, unique password

Before the INSERT, generate the password. GM accounts are targets of brute force and social engineering. Minimum rules:

• At least 16 characters, mixing uppercase, lowercase, numbers and symbols.
• Unique — never reused from email, Discord or another server account.
• Generated by a password manager, not made up off the top of your head.
• Stored only in the manager, never in a txt file on the desktop or in Discord chat.

Remember that the password's storage format varies by emulator: some store it in plain text (terrible, but common in old builds), others use MD5, and the newer ones use better hashing. If your emulator has a plain-text password column, treat the whole database as sensitive and restrict SQL access.

Step 2 — Create the account in the database

With the password in hand, create the account. Example in MSSQL for the classic schema (varies by season/emulator):

USE MuOnline;

-- Create a new administrative account
INSERT INTO MEMB_INFO
    (memb___id, memb__passwd, memb_name, sno__numb, bloc_code, ctl_code)
VALUES
    ('adm_bruno', 'S3nh4-F0rt3-Unica!2026', 'Bruno Admin',
     '000-000-000-0000', 0, 8);

-- Confirm creation
SELECT memb___id, memb_name, ctl_code, bloc_code
FROM MEMB_INFO
WHERE memb___id = 'adm_bruno';

Points to watch:

1. sno__numb needs a valid value in the format the emulator expects; some validate the string length.
2. bloc_code = 0 ensures the account is not born blocked.
3. ctl_code defines the level — use the minimum needed for the person's role.
4. If the password is stored hashed, use the emulator's function or panel, not a plain-text value the server won't recognize.

To elevate an existing account instead of creating a new one:

-- Promote an existing account to senior GM
UPDATE MEMB_INFO
SET ctl_code = 2
WHERE memb___id = 'conta_do_moderador';

-- Audit all accounts with administrative access
SELECT memb___id, memb_name, ctl_code
FROM MEMB_INFO
WHERE ctl_code > 0
ORDER BY ctl_code DESC;

Step 3 — Apply the minimum required level

The most common mistake is giving Admin (maximum ctl_code) to everyone on the team. Apply the principle of least privilege: each person gets only what they need for their job. A chat moderator does not need to create items; an event organizer does not need to ban accounts in bulk. The fewer accounts that have full power, the smaller the attack surface and the easier the auditing. Map roles to levels before handing out access, and document that map.

Step 4 — Isolate the administrative account

An Admin account should not mix with the normal life of the server:

• Dedicated nickname and account: don't use the account you play with. If your game account leaks in a Discord phishing attempt, the damage stays contained.
• No participation in the real economy: GM accounts should not buy, sell or trade with players. This avoids suspicion of favoritism and keeps the logs clean.
• Restricted IP when possible: some emulators and panels allow restricting administrative login to known IPs. Combine this with secure remote access to the server.
• A strong recovery email: the email account linked to the administrative account also needs a strong password and two-step verification.

Step 5 — Configure the GMList (if the emulator uses one)

Many modern emulators require the nickname to be in a GMList in the GameServer config, in addition to the ctl_code in the database. Example format (ini):

[GMList]
; nickname = access level (varies by emulator)
adm_bruno   = 8
gm_suporte  = 1
gm_eventos  = 2

[GMConfig]
LogGMCommands   = 1   ; log all GM commands
GMInvisible     = 1   ; allows a GM to go invisible
RestrictByIP    = 0   ; 1 = validate the GM's IP

If the nickname is in the database with a high ctl_code but outside the GMList (or vice versa), access may not work as expected. Keep the two in sync.

Step 6 — Enable logging of every action

No administrative account should act without leaving a trace. Configure the LogServer or the GameServer logs to record the author, action, target and time — especially for item creation, zen/coin delivery, bans and character changes. Beyond the game log, also record who accessed SQL and when. A server without an administrative log is impossible to audit after an incident.

Step 7 — Test the access

After creating it, validate before you trust it:

1. Log in with the new account on a test client.
2. Run a low-impact command compatible with the level (for example, /post on a staging server).
3. Confirm that the log recorded the action.
4. Try a command above the account's level and confirm it is denied.
5. Check in the database that the ctl_code is still what you expect.

Access rotation and revocation

Administrative access is not permanent. Whenever someone leaves the team, or you suspect a leak:

-- Revoke administrative access immediately
UPDATE MEMB_INFO
SET ctl_code = 0
WHERE memb___id = 'gm_que_saiu';

And, if you use a GMList, remove the nickname from there too, and change any password that was shared. Do a quarterly review of all accounts with ctl_code > 0 to eliminate forgotten access — the audit query from Step 2 serves for this.

Common errors and fixes

Security best practices

• One administrative account per person — no account shared by the whole team.
• A unique, strong password per account, stored in a manager, with two-step verification on the associated email.
• Least privilege always: give the minimum level the role requires.
• Never use the Admin account to play or trade.
• Mandatory logging on every value-generating action.
• Periodic auditing of accounts with ctl_code > 0.
• Immediate revocation when any staff member leaves.

Launch checklist

• Emulator access model identified (ctl_code, GMList or both)
• Level scale mapped by team role
• Strong, unique passwords generated in a manager
• Administrative accounts separated from game accounts
• ctl_code applied with the least privilege possible
• GMList synced with the database (if applicable)
• GM command logging enabled and tested
• Access validated in testing, including denial of a command above the level
• Two-step verification on the administrative accounts' emails
• Revocation procedure documented and tested
• Periodic auditing of accounts with access scheduled

Frequently asked questions