How to audit suspicious items with SQL in MU Online

Auditing suspicious items is the MU Online administrator's forensic investigation work. While the anti-dupe prevents and automatic detection alerts, manual auditing is where you sit down with the database and ask, item by item: is this one legitimate? A player reported that so-and-so appeared out of nowhere with five perfect Excellent sets. An automatic alert flagged a repeated serial. The market crashed in price overnight. In all those cases, the next step is the same: open SQL and reconstruct the history of each suspicious item — where it came from, where it has been, whether it is what it claims to be. This advanced tutorial shows how to conduct that investigation methodically, turning suspicion into evidence.

The principle that guides every forensic item audit is coherence: a legitimate item is internally coherent and externally traceable. Internally, its options, level and attributes form a combination the game is capable of generating. Externally, it has a recorded origin, an owner, a movement history that makes sense over time. A forged or duplicated item breaks the coherence at some point: an option that doesn't exist in that slot, a serial that repeats, a quantity that exceeds what has been printed, an appearance with no trail. Auditing is the art of finding those breaks.

Prerequisites

• Read access to the server's database (SQL Server, MySQL or your emulator's DBMS).
• A query tool: SSMS, HeidiSQL, DBeaver or equivalent.
• A restored backup or a replica — audit on a copy, never in production at peak hours.
• Knowledge of the emulator's schema: where character, inventory and warehouse live, and how items are encoded (hexadecimal blob or normalized table).
• Your emulator's item format documentation, if items are stored as a blob (to decode bytes into attributes).
• Ideally, access to log tables (drops, trades, GM commands) to cross-reference with the current state.

> Warning: all the table and column names below (Character, warehouse, T_ItemSerial, Serial, ItemOptions, T_DropLog) are examples from the Season 6 line and derivatives. Names and formats vary by season and emulator. Confirm the mapping before running any query, especially those that cross-reference logs.

If you are still structuring the server's database, the guide on how to create a MU Online server covers the DBMS installation and the organization of the tables before you reach the forensic part.

The four axes of suspicion

An efficient audit doesn't look at items one by one at random; it looks for patterns across four axes. Each axis answers a different question.

A good investigation walks all four axes. An item can be unique and coherent, yet appear with no provenance — and that alone is enough to investigate further.

Axis 1: uniqueness — hunting duplicated serials

If your emulator records a serial per item, duplication is trivial to prove: two active items with the same serial are a dupe, full stop.

-- Serials that appear in more than one active copy
SELECT Serial, COUNT(*) AS Copies
FROM T_ItemSerial
WHERE Active = 1
GROUP BY Serial
HAVING COUNT(*) > 1
ORDER BY Copies DESC;

For each serial returned, the next step is to find out who has the copies and when they appeared:

SELECT s.Serial, s.OwnerChar, s.OriginType, s.CreatedAt
FROM T_ItemSerial s
WHERE s.Serial = @suspectSerial
ORDER BY s.CreatedAt;

The CreatedAt of the copies usually tells the story: if two copies are born a few seconds apart, you are looking at a real-time dupe, and the interval points to the exploited operation (a trade, a warehouse move). If the emulator does not use a serial, this axis relies on a fingerprint: rare items with exactly the same option signature in different accounts appearing in the same window.

Axis 2: internal coherence — impossible items

Not every suspicious item is duplicated; many are forged or edited by a hacked client or by an abusive ex-GM. The mark of these items is internal incoherence: a combination of attributes the game is incapable of generating. An item with more Excellent options than the maximum allowed, an Ancient option on an item that belongs to no Ancient set, a refinement level above the ceiling, an option that only exists on another class of item.

If the options are in normalized columns, the query is direct:

-- Items with more Excellent options than the legitimate maximum (e.g., 6)
SELECT CharID, Serial, ItemCode, ExcOptionCount
FROM ItemOptions
WHERE ExcOptionCount > 6;

If the options are encoded in a hexadecimal blob, you need to decode them. Each emulator has its format — the first bytes indicate the item code, the following ones the level (+0 to +15), the Excellent options byte, the Ancient flag, the serial. With the format map in hand, write functions that extract each field from the blob and apply the same coherence rules. The important thing is to have a reference table of what is possible: for each item, how many Excellent options at most, which options are valid, what the refinement ceiling is. Anything that departs from that table is suspicious.

Axis 3: volume — more items than the world generated

This axis applies the principle of conservation: the quantity of an item that exists cannot be larger than the quantity that has been generated minus what was destroyed. If boss X dropped 40 units of the rare Jewel since the server started, and the database shows 180 active units, 140 came out of nowhere.

-- Total of a rare item currently in circulation
SELECT ItemCode, COUNT(*) AS InCirculation
FROM T_ItemSerial
WHERE ItemCode = @rareItem AND Active = 1
GROUP BY ItemCode;

-- Total already dropped according to the log
SELECT ItemCode, COUNT(*) AS AlreadyDropped
FROM T_DropLog
WHERE ItemCode = @rareItem
GROUP BY ItemCode;

When the "in circulation" exceeds the "already dropped" (plus legitimate crafts and events), you have an injection. The volume doesn't say who did it, but it says how much and serves as a general thermometer: run it periodically for all rare items and you will have a map of where the economy was corrupted.

Axis 4: provenance — items with no trail

Every legitimate item should have a recorded origin. An active item whose serial appears in no drop, craft, event or GM-command log is an orphan — and orphans deserve investigation.

-- Active items with no recorded origin in any log
SELECT s.Serial, s.OwnerChar, s.ItemCode, s.CreatedAt
FROM T_ItemSerial s
LEFT JOIN T_DropLog d  ON s.Serial = d.Serial
LEFT JOIN T_CraftLog c ON s.Serial = c.Serial
LEFT JOIN T_GMItemLog g ON s.Serial = g.Serial
WHERE s.Active = 1
  AND d.Serial IS NULL
  AND c.Serial IS NULL
  AND g.Serial IS NULL;

This triple LEFT JOIN cross-references the item with every legitimate source of origin; what is left with no match came from nowhere known. Watch out for false positives here: very old items, predating the implementation of the logs, can appear with no trail without being fraudulent. Filter by CreatedAt later than the date the logging went live.

Building the investigation dossier

Finding a suspicious item is the beginning, not the end. Before any action, build a dossier with all the evidence, because punishing without documented proof is how the problem comes back to haunt you. Export to a custody table:

-- Custody snapshot before any action
SELECT s.Serial, s.OwnerChar, s.ItemCode, s.OriginType, s.CreatedAt,
       GETDATE() AS AuditedAt, @reason AS Reason
INTO T_AuditCustody_20260710
FROM T_ItemSerial s
WHERE s.Serial IN (/* confirmed serials */);

The dossier should contain: the item's serial and complete attributes, the current owner and the ownership history, the creation and movement timestamps, and the related accounts — because dupes rarely involve a single account. Cross-reference the item's owner with accounts that share an IP, hardware ID or login pattern to map the network involved before acting.

Step by step of the audit

1. Restore a backup in an isolated environment or point to a read replica.
2. Run the uniqueness axis: list duplicated serials and order by number of copies.
3. Run the volume axis: compare circulation with the total generated for each rare item.
4. Run the coherence axis: look for items with impossible attributes.
5. Run the provenance axis: list orphans with no recorded origin (filtering by date).
6. Investigate each suspect: reconstruct the ownership history and timestamps.
7. Map the network: cross-reference owners with IP, HWID and login patterns.
8. Build the custody dossier by exporting all the evidence before acting.
9. Decide the action (freeze, remove item, ban) based on the dossier.
10. Document the decision and archive the evidence.

Common errors and fixes

Launch checklist

• Isolated audit environment (backup or replica) prepared
• Emulator's schema and item format mapped
• Uniqueness query (duplicated serials) validated
• Volume query (circulation vs. generated) validated
• Coherence query (impossible attributes) validated
• Provenance query (orphans) validated with a date filter
• Routine for reconstructing ownership history defined
• Cross-referencing of accounts by IP/HWID/login prepared
• Custody table for the dossier created
• Decision and documentation procedure written

Forensic item auditing is what separates a server that reacts to rumors from a server that acts on evidence. Walk the four axes methodically, document before punishing and treat every suspicious item as a case to be proven — not as a conviction decided in advance. That is how you keep the economy clean and the community's trust intact.

Frequently asked questions