# Cheating detection in Meridian 59

Author: Brian Green Last updated: Sept. 23, 2004
This document explains the various ways the game checks for cheating..

## General Information

Almost all cheating detection shows up in the debug log and begins with the word "ALERT!" in all capitals.

In general, we prefer to detect people instead of simply stopping them. Players that try to abuse the system one way are most likely the same people willing to abuse the system in other ways. In addition, some fixes are imperfect. If we simply stopped people from using the cheat, they would keep working until they found out how they can use the cheat without being stopped. For example, even though Half-Life has a way to detect the speedhack, some people have figured out that if you don't use the speed boost all the time you can avoid detection.

#### Log Limitaions and how to reset them.

Note: The system will only generally track 25 suspected problems. This is to prevent the debug log from overflowing with alerts from a blatant cheater.

An admin can reset the logging restrictions on a player so that a player that has hit the maximum logging can continue to be logged. One way is to manually reset the piCheaterLogs value in a player. The other way is to send the message ResetCheaterLogs to the player object. To do this globally for all players you can issue the command:send class user ResetCheaterLogs in the admin window or server console.

## Speedhack Detection

### What is it?

Speedhack is a program that allows people to move faster than they should. As far as I understand it, the program tricks the computer and client into thinking it is running slower than it really is. The client uses the computer's timing to limit movement, so it tries to speed up movement since it thinks it is running slower. Since the computer is really running at normal speed, this results in super speed for the character.

### What do we detect and how does the game react?

The Meridian 59 client sends a movement update once per second. A client affected by speedhack sends many more updates per second. In addition, the speedhacker travels faster than normal, obviously.

Our first layer of defense is to check for movement packets. As stated, we should get one movement packet per second, even in lag. This means that if the user sends more than one packet per second, they are probably cheating. The game allows the player to send 2 more packets than the duration of movement should expect; this is to allow for some leeway for strange cases of a player lagging a lot.

The second layer of defnese is to detect large movements without the corresponding lag in reporting movements. If a player moves a large distance and it wasn't enough time since the previous movement message, then the player may have teleported in the room. The game considers that a squared distance of 200 or more with the previous message happening less than 3 seconds ago as worthy of flagging.

Note that we ignore any movement that happens between rooms. So, if a player ends up in a different room than the original, there will be no message.

Also, DMs and above will never be checked. Due to their teleportation powers, they would regularly trip the detection mechanism.

The game does not do anything about speedhackers due to the complexity of trying to stop them, not wanting to give them a "test" harness to test alterations to the code, and the likelyhood of punishing false positives.

### What do the detection messages look like?

There are two messages for detecting speedhack use. Note that the examples below may not be exactly as what would show up in the game. For example, line numbers may change with edits. Also, the coordinates and RIDs used may reflect not actual game information.

The first message detects too many movement packets sent on average.

`Mar 2 2003 02:14:50|[user.bof (2461)] ALERT! ,GriEf PkeR!,ACCOUNT 313 OBJECT 6845, is moving too fast. Has moves count of 3, Possible speedhacker.
`

The line indicates how many more packets on average they have sent. In this case, they have sent 3 more packets than the number of seconds they have been moving. A probable speedhacker.
The second message detects speedhack movement that is above and beyond what is expected for the short delay since last update..

`Mar 2 2003 04:14:55|[user.bof (2481)] ALERT! ,GriEf PkeR!,ACCOUNT 313 OBJECT 6845, moved ,221, with only ,1, seconds since last movement update.`
`Mar 2 2003 04:14:55|[user.bof (2482)] Additional: ,GriEf PkeR!, went from (,2,15,) to (,12,15,) in RID ,951, Possible speedhacker.
`

The first line provides the information needed in a nutshell. It provides the name and account/object info of the suspected cheater. It shows the squared distance the character moved as well as the time since the last movement update. In this case, someone moved about three times as fast as they should have moved in one second. Note that this message should not print if the user ends up in the blink position in the room (i.e., has probably just finished casting the "blink" spell.)

The second line provides more information that can be used to see if the person really is a cheater. This includes the starting and ending (row, column) pairs and which RID (by number) the move happened in. This allows administrators to check to see if this would be normally possible due to special conditions in the room, the player ending up in the safe teleport coordinates (an indication they blinked or were teleported there for some reason).

### What about false positives?

NOTE: Currently, the move packet tracking is giving many false positives. For now, this tracking is not trustworthy.
Unfortunately, this is not an exact science. The code can only detect what it is told and sometimes flukes happen. False positives, times when a player is detected as cheating when they most likely are not, exist and must be watched for.

As mentioned above, any movement that happens between rooms is ignored, which cuts down on some false positives. All notifications are for movement made in a single room.

There are certain instances when the cleint sends more than one update per second as part of the game. These include times when the player walks over active items, like firewalls and lightning walls and the hotplates in guild halls. Also, hitting the space bar frequently will send more frequent move updates. A player in these situations may trigger the detection mechanism even though they might not be cheating. The movement counter should compensate for these situations and not give a false high value in most cases. Wall spells have caused problems in the past, so be aware of this situation.

A good administrator should check for special conditions in the teleport checks. Blinking will almost always set it off.

In general, a player that has a lot of log entries in a very short period of time has a higher probability of being a cheater than the player that sets off the detection a few times over a long period of time. It is recommended that you take user complaints into account if there is any doubt if a player is cheating.

### Other Information

#### Squared Distance:

We use squared distances because they are easy to calculate. We use the Pythagorean theorm to detect this. So, if a player moves from (old row, old col) to (new row, new col), we can find the squared distance between the points as:

((old row - new row) * (old row - new row)) + ((old col - new col) * (old col - new col))

Taking a square root is a very expensive operation, so we just use the squared distance.

## Running without Vigor

### What is it?

There is a program that tricks the client into running, even though their vigor is too low. Previously, this was only checked on the client side.

### What do we detect and how does the game react?

We check to see if the client sent a higher speed value than is allowed by vigor. If the player is trying to "run" without the proper vigor, then we flag it. The player is also moved back to the previous location they were at when they tried to run without vigor.

### What do the detection messages look like?

There is only one message associated with this detection:

`Mar 2 2002 10:56:27|[user.bof (4684)] ALERT! Player ,GriEf PkeR!,ACCOUNT 313 OBJECT 6856, was running with no vigor.`

It gives player name and account/object information. Pretty simple.

### What about false positives?

I fear that there may be cases where lag will prevent a client from being properly updated with the amount of vigor a player has but would still allow a player to run. This has not been properly tested, but it should be kept in mind. If this message is repeated many times in rapid order, it is probably a strong indication of a cheater (since the server is getting updates, the client is probably getting the proper updates as well).

## Attacking or casting spells on targets "behind" the player

### What is it?

There is a program that allows the player to attack or cast a spell at any object within the room, even if it is not in the view of the client.

### What do we detect and how does the game react?

The game already checked for range for the weapon or spell, so that is not a concern. However, the server relied on the client for the "field of view" of the player, and what they could hit. The program allows people to hit targets that were not in the client graphic window's view.
"Behind" the player is defined as behind the line defined by the cardinal and in-between directions that are the closest to being perpendicular to the player's direction vector. For example, if the player is facing mostly east, then the cardinal direction direction line runs north/south; in essense, anything that is further west than the layer is "behind" him or her. The more interesting cases are when the player is facing one of the corner directions. The code calculates the equation of the line using the point-slope formula and determines which side of the line the target is. The target must also be at least 1 unit away from the player in order to be considered behind the user.
The server sends a message that appears to be the default "not in view" message that the client gives if you try to attack something that's not in view.

### What do the detection messages look like?

There is only one message associated with this detection:

`Mar 2 2002 10:56:27|[player.bof (3810)] ALERT! Player ,GriEf PkeR!,ACCOUNT 313 OBJECT 6856, at [,34,25,] and angle ,0, tried to hit ,Victim,ACCOUNT 665 OBJECT 31029, at [,34,20,] that was behind them.`

It gives player name and account/object information and the object targetted. We also give the coordinates and the angle of the attacker. Angle in Meridian are as follows: Due East is angle 0, and every 90 degrees is another 1024 angle units going clockwise. Therefore, due south is 1024, and southwest is 1536.

### What about false positives?

There seems to be a good number of false positives generated by the movement lag between the client and the server's positions. This does not look to be a reliable way to find cheaters without further verification.

### Other information

The game penalizes any attack or spell on a target that is not considered in visible range. Currently, the game makes spells fizzle or attacks miss 2/3rds of the time if the target is behind a wall. This is in response to people casting spells on targets from across town. Note that this also hinders "safe spots" that players stand at in order to avoid being hit by enemies. This behavior cannot be completely shut down because of the way players move on fine coordinates and monsters move on the large coordinates, plus the fact that room information does not take movable sectors into consideration for calculating line of sight.

## Forced Offer Detection

### What is it?

There is a program that exploits the Windows foundation of the client and allows people to use normally disabled buttons and messages. Using this program, people were able to force an offer to be finished without the other person accepting the initial offer. This meant that they could force people to take harmful items, such as the amulet of shadows, without consent.

### What do we detect and how does the game react?

We check to see if a player tries to finish an offer without the other player accepting the offer. We accomplish this by flags in the user object.

Once the other person accepts the offer by making a counter offer, a flag is set in the original offerer's user. If this flag is NOT set when the original player tries to finish the offer, the offer is cancelled and not completed. We then write a notice to the debug log.

### What do the detection messages look like?

There is only one message associated with this detection:

`Mar 2 2002 10:56:27|[user.bof (4684)] ALERT! Player ,GriEf PkeR!,ACCOUNT 313 OBJECT 6856, tried complete an offer without the other person accepting.`

It gives player name and account/object information. Pretty simple.

### What about false positives?

There is no chance for a false positive, barring the possibility of bugs in the detection code. Anyone that is caught by this code is most likely a cheater.

## Forced Globe Posting Detection

### What is it?

Using a program similar to the forced offer detection, players can post on globes they would not normally be allowed to. Even though this leaves a telltale message as to who did it, we still log the infraction for later use.

### What do we detect and how does the game react?

We do a double-check for permissions before we allow the article to be written. The game stops any unauthorized posting from going on.

### What do the detection messages look like?

Note: The detection code is currently NOT working, even though posts are stopped.

There is only one message associated with this detection:

`Mar 1 2002 11:36:21|[news.bof (107)] ALERT! Player ,GriEf PkeR!,ACCOUNT 313 OBJECT 6856, tried to write to a newsglobe without permission.`

It gives player name and account/object information.

### What about false positives?

There is no chance for a false positive, barring the possibility of bugs in the detection code. Anyone that is caught by this code is almost certainly a cheater.

## Bad Characters in Character Bios

### What is it?

An old trick. A player tries to trick the server's profanity filter into overloading by using repeated non-standard characters. Enough of these characters would lag the server, and too many of them would crash it entirely.

Note: The server side profanity filter is currently disabled.

### What do we detect and how does the game react?

The client detects if the person tries to set their bio with all the characters. It then sends a "broadcast" message to the server that contains a sequence of color codes that is impossible for the client to send under normal circumstances.

In order to prevent people from flooding the logs, we limit the number of logs to 10. Note that this uses the same log count as the speedhack system above.

The client blocks these changes from happening.

### What do the detection messages look like?

There are a few messages that deal with this cheat, depending on the serverity

The first one is for people that use a small number of characters, generally in order to just lag the server instead of crash it.

`Mar 3 2002 01:06:06|[user.bof (3346)] ALERT! ,GriEf PkeR!,ACCOUNT 313 OBJECT 6856, used more than 20 bad chars in their bio. Watch for multiple occurrences.`

It gives player name and account/object information and a notification of the number of bad characters.

The second message if for more flagrant abusers.

`Mar 3 2002 01:09:26|[user.bof (3351)] ALERT! ,GriEf PkeR!,ACCOUNT 313 OBJECT 6856, used more than 50 bad chars in their bio.`

Again, it gives player name and account/object information and a notification of the number of bad characters.

### What about false positives?

There is no chance for a false positive, barring the possibility of bugs in the detection code. I did not write this code myself, so I do not know the accuracy of it. Anyone that is caught by this code is almost certainly a cheater, however.

## Distance Trading With Players and NPCs

### What is it?

Using a cheat program players were able to trick the client into thinking that some random item was a particular NPC. Players could interact with the NPC as normal, offering them items for sale. This was rather convenient for some players, as they could go to hard-to-reach areas and not have to return for quite some time.

### What do we detect and how does the game react?

We simply detect if the NPC's owner and the player's owner are the same. If not, we flag the interaction. The interaction is also stopped without success.

### What do the detection messages look like?

There are three messages for this, one for offering to NPCs, one for buying from NPCs, and one for offering to players..

`Mar 3 2002 01:06:06|[monster.bof (1891)] ALERT! ,GriEf PkeR!,ACCOUNT 313 OBJECT 6856, offered items to NPC ,Paddock, from distant RID, 828`

`Mar 3 2002 01:06:06|[monster.bof (3092)] ALERT! ,GriEf PkeR!,ACCOUNT 313 OBJECT 6856, tried to buy items from ,Paddock, while in distant RID, 828`

`Mar 3 2002 01:26:06|[user.bof (4424)] ALERT! ,GriEf PkeR!,ACCOUNT 313 OBJECT 6856, in RID ,2, offered items to ,GriEf MUlE!,ACCOUNT 314, object 7841, in distant RID, 828`

It gives player name and account/object information, which NPC or player they tried to interact with, and the RID of the room they were in.

### What about false positives?

There have been a few detections of players offering to other players in adjacent rooms. This could be from players having an offer window open while going to another zone. Players flagged with this message are most likely cheaters if they are not in adjacent zones..

## Distance Trading With Chests

### What is it?

Similar to distance trading with players, some cheaters can make the client think an object is a distant chest to store items in.

### What do we detect and how does the game react?

We detect if the player's owner is the same as the chests's true owner since the server knows the true location of both. If the owners are not the same, then the system flags the user and disallows the transaction.

### What do the detection messages look like?

There are two messages for this, one for taking from, and one for putting stuff into chests..

`Oct 3 2002 09:16:03|[storebox.bof (112)] ALERT!` `GriEf PkeR!,ACCOUNT 313 OBJECT 6856,``in RID ,100, taking from distant chest in RID ,10013`

`Oct 3 2002 11:16:30|[storebox.bof` `(1372)]` `ALERT!` `GriEf PkeR!,ACCOUNT 313 OBJECT 6856,``in RID ,101, putting into distant chest in RID``,10013
`

`The messages show the user and the room IDs of the cheater and the chest.
`

``

### What about false positives?

As with distant trades with players, there may be a few false positives. Check for adjacent room IDs. Otherwise, any player flagged with this message is most likely cheating.

## Putting Objects Directly into Player Inventories

### What is it?

By tricking the client, the cheater makes the game think that an object is a player with the same attributes as a chest. In other words, the cheater can put objects directly into the player's inventory without the regular offer checks.

### What do we detect and how does the game react?

We check to see if the object that the player is putting stuff into is actually a Player. If so, we flag them and disallow the transaction.

### What do the detection messages look like?

There is only one message associated with this detection:

`Mar 2 2002 10:56:27|[user.bof (3215)] ALERT!` `GriEf PkeR!,ACCOUNT 313 OBJECT 6856,``tried to 'put' items into player ,Innocent Victim,Account 101 OBJECT 1343
`

The message gives information about the cheater and the target or victim.

### What about false positives?

There is no chance for a false positive, barring the possibility of bugs in the detection code.

## Duping

### What is it?

Using a cheat, players were able to duplicate any Number Item (also called "stacked items"). They were able to trick the client into offering the same object twice by altering memory addresses. Due to the way the server handled number items the game would add the number of the stack to another stack twice, effectively doubling the stack. This is most commonly used on money since it has no weight.

### What do we detect and how does the game react?

We detect if a player tries to offer the same item or put the same item into a chest multiple times. This is done every offer or "put" command.

### What do the detection messages look like?

There are three messages for this:

`Sep 11 2004 21:26:44|[user.bof (4687)] ALERT! ,GriEf PkeR!,ACCOUNT 313 OBJECT 6856, tried to offer a duplicate item to,Psychochild,ACCOUNT 3 OBJECT 66,.`

`Sep 11 2004 22:29:13|[user.bof (5069)] ALERT! ,GriEf PkeR!,ACCOUNT 313 OBJECT 6856, tried to counter-offer a duplicate item to Paddock,OBJECT 1234,.`

`Sep 11 2004 23:11:04|[user.bof (3665)] ALERT! ,GriEf PkeR!,ACCOUNT 313 OBJECT 6856, tried to put a duplicate item in a chest.`

It gives player name and account/object information, which NPC or player they tried to interact with, and the RID of the room they were in.

### What about false positives?

There should not be false positives for this detection, barring bugs in the detection code.