How to investigate trade and drop logs in MU Online

When a player opens a ticket saying another is "selling a dropped item that does not exist", or when ten identical Excellents suddenly appear on the server market, the answer is not in your hunch — it is in the logs. Investigating trade and drop logs in MU Online is detective work: you gather records from different sources, synchronize the clocks, cross the database inventory with the recorded events, and build a defensible timeline before punishing any account. This guide shows the complete method, from what must be enabled before the incident to how to close the case without committing injustice. The file, table and column names cited are examples that vary by season/emulator; the method, however, is the same in any version.

Prerequisites

To run a serious investigation you need:

• Administrative access to the server (RDP/SSH) and to the database (SQL Server, MySQL or your emulator's DBMS) with read permission on the item, account and trade tables.
• Trade, drop and database logs already active and retained — this is non-negotiable. If they were off during the incident, no investigation is possible.
• Synchronized clocks across the GameServer, the database and the operating system (ideally with NTP), so the timestamps line up.
• A read-only copy of the logs to work on without risking altering the originals (chain of custody matters if the case becomes a public dispute).
• Basic SQL knowledge to query inventory and transaction history.
• A spreadsheet or simple tool to build the timeline by cross-referencing events.

If your server does not yet have structured logs, fix that first; then come back to investigate. And if you are still building the server from scratch, start with how to create a MU Online server.

Understand the log sources before opening any file

A good investigation starts by knowing which records exist and what each one proves. In a typical MU Online you deal with three major sources:

• Drop log (ItemLog / DropLog) — records when an item is born into the world: which monster/map generated it, which player picked it up, the timestamp and, if the emulator supports it, the item serial. It is the item's "birth certificate".
• Trade log (TradeLog) — records transfers between players: who gave, who received, which items, the amount of zen involved and the timestamp. It is the "record of ownership transfer".
• Database log/state (inventory and history) — the current inventory of each character, the warehouse and, depending on the emulator, audit tables. It is the "snapshot of the present".

The mental rule: drop says where the item came from, trade says where it passed through, the database says where it is now. Fraud appears when these three sources contradict each other — an item that shows up in an inventory with no drop certificate, or the same serial in two places at once.

Map of the sources and what each one proves

The connection log comes in as a valuable auxiliary source: crossing the login IP with the trade times reveals when two "different accounts" are operated by the same person.

Step 1 — Freeze the scene and preserve the evidence

Before you query anything:

1. Do not warn the suspect. If they notice, the items vanish (chained trades, warehouse, alt accounts).
2. Copy the relevant logs from the day of the incident and the neighboring days into a separate working folder. Work on the copy.
3. Take a snapshot of the database or at least export the inventory of the involved accounts at that instant. The item can move while you investigate.
4. Note the case's origin: who reported it, what they claimed, screenshots. It is the starting point of the timeline.

Preserving before investigating prevents the investigation itself from altering the evidence.

Step 2 — Synchronize the clocks and normalize the timestamps

The mistake that ruins the most investigations is a misaligned timestamp. If the GameServer writes in local time and the database in UTC, the same event appears three hours apart and you "prove" an impossibility that does not exist.

• Confirm the time zone of each source (OS, GameServer, database).
• Choose a reference time zone for the investigation and convert everything to it in the spreadsheet.
• If possible, turn on NTP for future cases — continuous synchronization prevents the problem at the source.

Only after normalizing the times does the timeline have any value.

Step 3 — Reconstruct the item's timeline

Here is the heart of the method. Take the disputed item or serial and reconstruct its history in chronological order:

1. Birth: find the drop event. Which monster/map, who picked it up, when.
2. Transit: list all the trades involving that item/serial, in order.
3. Current state: confirm in the database where the item is now.

A legitimate chain is continuous: it is born with player A, is traded A→B, and is now with B. A fraudulent chain has a gap or a fork: the item shows up with B without ever having been dropped, or the same serial is with B and with C simultaneously (classic duplication).

Illustrative query to find items with a repeated serial in the inventory (example, varies by season/emulator):

-- Look for the same item serial across more than one owner
SELECT ItemSerial, COUNT(*) AS ocorrencias
FROM CharacterItems
GROUP BY ItemSerial
HAVING COUNT(*) > 1
ORDER BY ocorrencias DESC;

If the result brings serials with ocorrencias > 1, you have a strong hint of duplication — the same item existing in two places.

Step 4 — Read the trade log with an investigator's eyes

A suspicious trade is rarely a single glaring event; it is a pattern. When sweeping the TradeLog, look for:

• Anomalous repetition: the same account receiving expensive items from several different accounts within a few minutes ("mule" pattern collecting from disposable accounts).
• One-sided trade: a valuable item going out for zero or a symbolic zen, repeatedly — typical of a transfer to an alt, not a real sale.
• Freshly created accounts: a donor or receiver with an account only hours old taking part in top-tier item trades.
• Time burst: dozens of trades in the same second/minute, suggesting automation.

Example query for high-value trades in a short window:

-- Trades above a threshold within a time window
SELECT FromAccount, ToAccount, ItemName, Zen, TradeTime
FROM TradeLog
WHERE TradeTime BETWEEN '2026-07-10 21:00' AND '2026-07-10 23:00'
  AND (Zen = 0 OR ItemGrade >= 3)      -- high-grade items or a trade with no zen
ORDER BY TradeTime;

Notice that none of these patterns proves fraud on its own. The player's own secondary account produces a legitimate one-sided trade. The pattern raises the hypothesis; the cross-referencing confirms it.

Step 5 — Cross-reference with the drop log and the database

Now tie the ends together. For each suspicious item in the timeline:

• Does it have a drop certificate? If the item appeared in a trade but never shows up in the DropLog or any legitimate origin (quest, event, shop), it is a strong sign of an injected or duplicated item.
• Do the quantities add up? If the DropLog records that only one Excellent of that type dropped that day, but there are five identical ones circulating, four came from nowhere.
• Does the IP match? Cross the connection log: if the donor and receiver log in from the same IP at the same times, "two accounts" become one person moving items between alts — which changes how the case reads.

This three-source cross-reference is what separates a solid accusation from a guess. Never close the case with a single source.

Step 6 — Distinguish fraud from legitimate behavior

Before any punishment, actively rule out the innocent explanations:

• A real gift between friends or guild members.
• The same player's secondary account (internal sale, not fraud).
• An agreed sale with payment on the side (the log shows a trade with no zen because the zen went through another transaction).
• An event or system bug that generated the item legitimately in that period.

If, after ruling all these out, the chain still has a gap or the serial is still duplicated, then you have a case. The burden is on you to prove it, not on the player to defend against a loose screenshot.

Step 7 — Document the case and act proportionally

Close the investigation with a dossier:

1. Summary: what was alleged and what was found.
2. Timeline: events in order, with the source and normalized timestamp of each.
3. Key evidence: the duplicated serial, the gap in the chain, the mule pattern — with the query or log excerpt that supports it.
4. Ruled-out explanations: why it is not a gift/alt/bug.
5. Action: the proportional punishment (item rollback, removal of the duplicate, suspension or ban), with the date.

Documenting protects you when the player contests it publicly and creates internal precedent for future cases.

Common errors and fixes

Launch checklist

• Drop, trade and database logs confirmed active and retained
• OS, GameServer and database clocks synchronized (NTP ideally)
• Log copy/preservation routine defined for future cases
• Read access to the database and the item/account tables secured
• Template queries (duplicate serial, high-value trades) ready and tested
• Scene-freezing procedure documented (snapshot before reviewing)
• Cross-referencing with the connection/IP log built into the flow
• Case dossier template created (summary, timeline, evidence, action)
• Proportional punishment policy defined and communicated to the team
• GM team trained not to accuse on a single source

Investigating trade and drop is not a witch hunt — it is building an honest timeline from sources that confirm each other. With the logs on before the incident, the clocks synchronized and the cross-referencing of drop, trade and database, you trade "I think" for "the records show", and that is what supports a fair decision before the community.

Frequently asked questions