-
Notifications
You must be signed in to change notification settings - Fork 8
Checks
Detecting autototem usage in Minecraft can be both complex and straightforward. The complexity primarily comes from how Minecraft’s inventory system is designed. Mojang’s implementation does not provide simple packets for key actions such as when a player opens their inventory. This missing link forces developers to rely on indirect methods and careful analysis.
On the other hand, the core detection logic for autototem usage remains fairly uniform across various checks. Once you understand the principles behind one check, you can often apply similar reasoning to other checks with minimal adjustments.
To reduce false positives caused by rapid, yet legitimate totem swapping, the plugin uses a “totem cycle” mechanism.
- Totem Usage: When a player “pops” a totem, the system records the current timestamp.
- Re-Equipment Tracking: The plugin then waits to observe the next time a totem is equipped.
- Analysis: This cycle—from totem pop to totem re-equipment—provides valuable data for multiple checks. By examining timing and patterns, the system can distinguish natural player behavior from that induced by autototem modifications.
This approach helps the plugin accurately identify suspicious patterns while minimizing unintended flags.
Understanding these statistical terms will help you interpret TotemGuard’s data-driven logic. No advanced math is needed—just a willingness to learn the basics.
Definition: The mean is the average value of a group of numbers.
How to Calculate: Add all values, then divide by the total number of values.
Example:
For [1, 2, 3, 4, 5]:
- Sum:
1 + 2 + 3 + 4 + 5 = 15 - Divide by 5:
15 ÷ 5 = 3
The mean is 3.
Definition: The median is the middle value in a sorted list of numbers.
- If there’s an odd number of values, it’s the exact middle value.
- If there’s an even number, it’s the average of the two middle values.
Example:
For [1, 3, 3, 6, 7, 8, 9] (already sorted):
- Middle value:
6
For [1, 2, 3, 4]:
- Middle two values:
2and3 - Median:
(2 + 3) ÷ 2 = 2.5
Definition: Standard deviation measures how much the data values vary from the mean.
- A low standard deviation indicates values are clustered closely around the mean (high consistency).
- A high standard deviation indicates values are widely spread out (low consistency).
In TotemGuard, low standard deviation in totem re-equipment timing suggests a player may be using an autototem hack. Legitimate players rarely maintain perfectly consistent intervals.
Example (High Spread):
[34, 54, 3, 203, 5]
- Mean:
59.8 - Standard Deviation:
78.6(high variation)
Example (Low Spread):
[1, 2, 3, 4, 5]
- Mean:
3 - Standard Deviation:
1.41(low variation, high consistency)
Learn more about standard deviation.
Below is an overview of the checks implemented by TotemGuard. Each check targets specific indicators of autototem usage, from direct client admissions to subtle statistical patterns.
Goal: Identify direct client modifications that reveal autototem usage through anomalous or impossible packet behavior.
- Trigger: Clients (e.g., the AutoTotem Mod) that send a special plugin messaging packet to the server.
- Mechanism: The client explicitly informs the server that it’s using the mod. For an example, see the ServerOptOut class.
- False Positives: None. The client reveals itself directly.
- Trigger: Mods that alter the client’s brand string to include “autototem.”
- Mechanism: The server detects the modified brand info, an intentional signal of autototem usage.
- False Positives: None. This relies on explicit client-side identification.
- Trigger: Duplicate slot change packets that cannot occur in vanilla gameplay.
- Mechanism: Poorly coded hacked clients sometimes resend the exact same slot update multiple times.
- False Positives: Slight. For some reason, some players do trigger this alert, but only once. Put the max VL on 3 for example.
AutoTotem checks focus on analyzing totem cycle data. By examining timings and patterns, these checks detect unnaturally fast or consistent totem re-equipment intervals.
- Trigger: An impossibly short delay between selecting a totem and placing it into the off-hand slot.
- Mechanism: The system measures the elapsed time between totem selection and off-hand equip events. Abnormally quick, repeated timings indicate automation.
- False Positives: Extremely Low. Extensively tested without known false alerts.
- Trigger: Unnaturally low standard deviation in re-equipment timings.
- Mechanism: Uses past totem cycles to determine if the player consistently re-equips totems at nearly identical intervals.
- False Positives: Slight. Highly unlikely but possible if a player attempts to be perfectly consistent while under bizarre conditions.
- Trigger: Impossibly consistent average standard deviations over multiple intervals.
- Mechanism: Checks previous standard deviations for patterns. If timing remains too uniform across multiple attempts, it indicates automation.
- False Positives: Low. Typically, flags only low-quality hacked clients.
- Trigger: Identical packet timing sequences related to re-toteming.
- Mechanism: Monitors if a few specific packets are being sent in an order, with perfect delays in between, purely focussed on re-equipping a new totem.
- False Positives: Extremely Low. This pattern does not occur naturally.
- Trigger: Unrealistically low timing outliers.
- Mechanism: Examines outliers in the data set. Extremely low outliers suggest simplistic, “randomized” bot behavior that isn’t truly random.
- False Positives: Low. Rarely flags legitimate players.
- Trigger: Invalid interactions while the inventory remains open.
- Mechanism: Detects actions that shouldn’t be possible during normal inventory usage, such as interacting with the world while the inventory screen is still displayed.
- False Positives: Medium. Can occasionally flag legitimate players, but when combined with other checks (e.g., Type B), it strongly indicates automation.
Goal: Provide staff with a manual, on-demand check to confirm suspicious behavior.
How It Works:
- An authorized user runs
/tg check <player>. - The system momentarily lowers the target player’s health, forcing a totem pop if the player is holding one.
- Once the totem pops, a timer starts to see how quickly a new totem is equipped.
- If the player equips a new totem within an unrealistically short time frame (configurable in the plugin’s settings), the player is flagged.
- After the test, the player’s original state (health, hunger, inventory, effects) is fully restored.
Caveats:
- Running this check while the target is in active combat can lead to false flags, as a skilled player might genuinely re-totem quickly.
- Certain hacked clients only equip totems when the inventory is open. Without forcing the inventory to open, these clients may appear legitimate. Still, most cheaters are unaware of such nuances and get flagged anyway.