Anti-Cheat Testing Report: LiquidBounce Speed Hack vs.

Grim and
Vulcan Anti-Cheats

DEMO
Testing Environment:
 Minecraft Server Version: Paper 1.20.1
 Anti-Cheat Plugins: Grim AntiCheat, Vulcan AntiCheat
 Cheat Client: LiquidBounce

Objective:
The objective of this initial test was to evaluate how effectively Grim and Vulcan
anti-cheats detect hacks implemented through the LiquidBounce client on a
Minecraft server. This report focuses exclusively on testing with hacks enabled.

Test Setup:
1. Anti-Cheat Configurations:
o Grim AntiCheat: Alerts and verbose logging enabled to capture
detailed responses to abnormal patterns.
o Vulcan AntiCheat: Alerts and verbose logging enabled to monitor
any violations.
2. Cheat Client Configuration:
o Enabled the LiquidBounce client with custom hacks enabled.
3. Testing Process:
o Joined the Minecraft server using LiquidBounce and activated the
hacks.
 o Monitored both Grim and Vulcan anti-cheat systems to observe their
responses to the hacks.

Observations and Findings:

I. SPEED

EXPLANATION FOR EACH SPEED HACK

1. Y Port Speed Hack:
o This hack manipulates the player's position by forcing high-speed
vertical movement, often causing them to "teleport" to specific heights
or locations. It bypasses normal physics checks by rapidly adjusting
the player's Y-coordinate, which can confuse anti-cheats.
o Movement Impact: The player appears to "skip" through blocks or
terrain, and may seem to jump or fall instantly between locations
without the usual fluid motion.
2. LegitHop:
o This hack is designed to allow the player to jump higher or more
frequently than is possible under normal game mechanics, while
mimicking legitimate player behavior. It often simulates small jumps
but with increased velocity.
o Movement Impact: Players using LegitHop might appear to jump
unnaturally high or frequently, giving them the ability to bypass
obstacles that would normally be too high or far to reach.
3. GrimCollide:
o Typically, this hack manipulates player collision, allowing the user to
pass through blocks or other entities without being affected by them.
 This allows the player to travel through walls or other solid objects at
high speeds.
o Movement Impact: The player may move through solid objects,
bypassing barriers in the environment, or travel unnaturally quickly
due to reduced friction and collision checks.
4. Vulcan 286 and 288 (Speed hacks related to bypassing Vulcan):
o These variants of speed hacks work by bypassing the anti-cheat’s
movement checks and physics, often involving sudden bursts of speed
or erratic movement patterns. In the case of Vulcan 286, there’s an
attempt to manipulate motion for rapid travel, while Vulcan 288 does
the same, but with slight adjustments to the timing and velocity for
additional evasion.
o Movement Impact: Both Vulcan speed hacks enable players to move
far beyond the usual constraints of the game’s normal speed limits.
Players will notice fast, jerky movements that differ from regular
sprinting or flying mechanics, often with quick, repeated speed boosts.
These hacks interfere with how the game expects player movement to behave,
creating inconsistencies in the game's physics or player position checks, which
in turn allows users to bypass various detection mechanisms put in place by
anti-cheat systems. When anti-cheat systems like Grim and Vulcan detect such
movements, they often block or slow down the player to prevent further
exploitation.

ANTI-CHEAT DETECTION (SPEED)

1. Y Port Speed Hack (Used for testing packets)
 Hack Description: The Y Port Speed Hack slightly teleports players
forward, bypassing normal movement limits. It uses teleportation-like
behavior to move the player in quick, short bursts.
 Grim AntiCheat:
 o Detection Method: Grim uses simulation-based checks to predict
movement paths. When a player deviates from this predicted path (due
to speed hacks), Grim flags the anomaly.
o Alerts: Grim immediately flagged the hack, generating "failed
Simulation" messages for the player.
 Example Log Entries:
 "Grim zenerity failed Simulation (x10) [.152800 / gl
48]"
 "Grim zenerity failed Simulation (x15) [.153050 / gl
49]"

o Effectiveness: Grim detected and immediately stopped the player

from continuing the speed hack. It blocked the movement effectively
in real-time.

 Vulcan AntiCheat:
o Detection Method: Vulcan focuses on detecting abnormal movement
over time. However, it does not flag anomalies in real-time but rather
logs them for further review.
o Alerts: Vulcan detected the Y Port Speed Hack as MotionB, which
refers to suspicious player motion behavior.
 Example Log Entries:
 "Vulcan zenerity verbosed Motion (B) [50.00%]"
 "Vulcan zenerity verbosed Motion (B) [68.75%]"
 o Effectiveness: Vulcan did not immediately stop the hack. It detected
the anomaly (MotionB) but did not take action to block it at the time.

2. Legit Hop
 Hack Description: A subtle speed hack that mimics legitimate movement by
slightly enhancing jump speed. The intention is to make the movement seem
natural and avoid detection.
 Grim AntiCheat:
o Detection Method: Grim’s simulation checks are designed to detect
significant deviations from natural movement. However, the subtlety
of Legit Hop was enough to bypass these checks.
o Alerts: No alerts were generated for Legit Hop.
o Effectiveness: Both Grim and Vulcan failed to detect Legit Hop
because its changes were too subtle.
 Vulcan AntiCheat:
o Detection Method: Vulcan relies on tracking movement over time,
but it was unable to detect the small changes caused by Legit Hop.
o Alerts: No alerts were generated for Legit Hop.
o Effectiveness: Vulcan also failed to detect the subtle hack.

3. Grim Collide (Designed for Grim)

 Hack Description: This hack manipulates player velocity in a way that is
intended to bypass Grim’s detection. It works by making subtle adjustments
to movement that are hard to detect.
 Grim AntiCheat:
o Detection Method: Grim’s simulation-based checks failed to detect
the minor deviations created by Grim Collide, which was specifically
designed to avoid triggering these checks.
o Alerts: No alerts or detections were made by Grim during this test.
 o Effectiveness: Grim did not detect or stop Grim Collide, likely due
to its subtlety.
 Vulcan AntiCheat:
o Detection Method: Vulcan failed to detect the subtle changes caused
by Grim Collide, as it relies on time-based analysis of movement that
doesn't account for small shifts.
o Alerts: No alerts were made by Vulcan for Grim Collide.
o Effectiveness: Both anti-cheats failed to detect Grim Collide.

4. Vulcan 286 Speed Hack (Designed for Vulcan)

 Hack Description: Vulcan 286 is a speed hack designed to evade Vulcan’s
own detection by altering player movement. It is typically used to bypass the
Vulcan AntiCheat system.
 Grim AntiCheat:
o Detection Method: Grim uses simulation checks to detect speed
hacks, but Vulcan 286 was not flagged by Grim.
o Alerts: Grim generated logs for "failed Simulation", indicating the
system recognized an anomaly but did not take immediate action to
block it.
 Example Log Entries:
 "Grim zenerity failed Simulation (x10) [.152800 / gl
48]"
 "Grim zenerity failed Simulation (x12) [.153050 / gl
49]"

o Effectiveness: Grim detected the movement as suspicious but did

not stop the player completely from continuing the hack.
 Vulcan AntiCheat:
 o Detection Method: Vulcan’s verbose mode logged movement
irregularities, including "verbosed Jump" alerts. However, Vulcan
did not stop the hack immediately but slowed down the player's
movement instead.
o Alerts: Vulcan logged entries such as:
 "Vulcan zenerity verbosed Jump (A) [50%]"
 "Vulcan zenerity verbosed Jump (A) [100%]"

o Effectiveness: Vulcan slowed down the player but did not block the
hack completely. It detected the anomaly but failed to take full action

5. Vulcan 288 Speed Hack (Designed for Vulcan)

 Hack Description: Vulcan 288 is designed to bypass Vulcan AntiCheat by
increasing movement speed significantly, making it easier for Grim to
detect.
 Grim AntiCheat:
o Detection Method: Grim flagged the Vulcan 288 hack through
simulation checks, detecting significant movement discrepancies.
o Alerts: Grim logged the “failed Simulation” message, indicating the
irregularities in the player’s movement.
 Example Log Entries:
 "Grim zenerity failed Simulation (x10) [152800 / gl
48]"
 "Grim zenerity failed Simulation (x15) [153050 / gl
49]"
 o Effectiveness: Grim completely stopped the player after detecting
the hack. The movement was flagged as highly irregular, and Grim
took immediate action to block it.
 Vulcan AntiCheat:
o Detection Method: No detection. Vulcan did not log or flag any
abnormal movement.
o Alerts: None
o Effectiveness: Vulcan did not stop the movement and allowed the
hack to proceed without interference.

6. Vulcan Ground 286 Speed Hack (Designed for Vulcan)

 Hack Description: Vulcan Ground 286 targets grounded movement to
bypass Vulcan’s checks, making it a challenge for Vulcan AntiCheat to
detect.
 Grim AntiCheat:
o Detection Method: Grim’s simulation-based checks flagged the
Vulcan Ground 286 hack through discrepancies in player movement.
Additional checks like BadPacketsN, Timer, and GroundProof were
triggered.
o Alerts: Grim logged entries such as:
 "Grim zenerity failed Simulation (x10) [.152800 / gl 48]"
 "Grim zenerity failed GroundProof (x35) claimed true
 "Grim zenerity failed BadPacketsN (x12)"
 "Grim zenerity failed Timer (x10)"
 "Grim zenerity failed NoFall (x4)"
 o Effectiveness: Grim was able to detect and block the movement
entirely. Grim took immediate action to stop the Vulcan Ground 286
speed hack.
 Vulcan AntiCheat:
o Detection Method: Vulcan was unable to detect the Vulcan Ground
286 hack, as it failed to log sufficient alerts or take action against the
irregularities.
o Alerts: No alerts were logged for Vulcan Ground 286 in Vulcan’s
verbose mode.
o Effectiveness: Vulcan did not detect the hack, allowing the player to
bypass the checks without any restriction.

Summary:
 Grim AntiCheat consistently outperformed Vulcan AntiCheat, detecting
and stopping Vulcan 288 and Vulcan Ground 286 effectively, as well as
 responding to Y Port Speed Hack. Grim flagged almost all of the hacks,
except for Legit Hop and Grim Collide.
 Vulcan AntiCheat displayed a slower response to many hacks. It detected
but did not act on Vulcan 286 and Y Port hacks, only slowing movement. It
did not detect Legit Hop or Grim Collide.

II. PVP HACKS (KILLAURA)

EXPLANATION FOR EACH KILLAURA TYPE
1. Stabilized KillAura:
o Hack Description: This version of KillAura focuses on maintaining
stable, consistent attacks. It automates hitting nearby players or
entities while ensuring the player's movements appear legitimate to
anti-cheats. It avoids rapid actions that could trigger basic detection
mechanisms.
o Impact: Players can land consistent hits without aiming, giving them
a significant advantage in combat. The player appears to aim
naturally, but attacks are unnaturally precise and timed.
2. Spamming KillAura:
o Hack Description: This aggressive version sends rapid attack packets
to nearby players or entities. The goal is to overwhelm opponents with
rapid hits, making it harder for them to react. It sacrifices subtlety for
raw attack speed.
o Impact: Opponents are often knocked back or killed rapidly, and the
attacking player seems to "spam" hits unrealistically fast. This can
trigger anti-cheat flags for excessive packet rates or movement
inconsistencies.
3. Double-Click KillAura:
 o Hack Description: This version exploits double-click detection
mechanisms, sending multiple attack packets for a single input. It
mimics legitimate high-speed clicking but automates it for consistent
attack boosts.
o Impact: Players appear to click abnormally fast, leading to multiple
hits in quick succession. This can bypass basic click-speed detection if
not configured to catch small timing variations.

ANTI-CHEAT DETECTION (KILLAURA)

Stabilized KillAura
Grim AntiCheat:
 Detection Method:
o Simulation: Compares player actions against expected behaviors,
particularly looking for natural-looking attack timings.
o AimDuplicateLook: Flags automated and duplicated aiming angles,
which occur during consistent bot-like aiming.
o Timer: Detects timing anomalies, such as irregular intervals between
actions.
 Alerts:
o Logs when the player’s aim behavior doesn’t match expected human
patterns.
o Flags when actions are triggered too quickly.

 Effectiveness:
 o Moderate; Grim AntiCheat can detect most stabilized hacks but may
struggle with subtle automation due to incomplete coverage of
simulation-based actions.
Vulcan AntiCheat:
 Detection Method:
o Autoclicker (C): Detects suspiciously consistent and fast clicking
patterns.
o Aim (E): Identifies aim-related irregularities, such as robotic aim-lock
behavior.
o KillAura (K): Specifically flags repetitive attack patterns linked to
KillAura hacks.
o Criticals (B): Detects illegitimate critical hits, often used in
conjunction with spamming attacks.
 Alerts:
o Issues warnings for click-speed anomalies.
o Flags aim inconsistencies indicative of stabilization cheats.
  Effectiveness:
o High; Vulcan excels in detecting subtle combat automation by
combining multiple aim and click-related checks.
Conclusion: Vulcan is better than Grim at detecting Stabilized KillAura due to its
focus on Autoclicker and Aim modules.

Spamming KillAura
Grim AntiCheat:
 Detection Method:
o Simulation: Monitors attack patterns against expected behavior
thresholds.
o AimDuplicateLook: Flags repetitive aiming angles resulting from
bot-like aiming behaviors.
 o Timer: Identifies timing irregularities, such as extremely rapid or
inconsistent actions.
 Alerts:
o Logs excessively rapid attack patterns or unnatural aiming behavior.

 Effectiveness:
o Moderate; Grim AntiCheat detects obvious spamming but struggles
with advanced packet optimization cheats.
Vulcan AntiCheat:
 Detection Method:
o Velocity (A): Flags abnormal movement behavior, such as
unreasonably fast attack-induced velocity changes.
o Criticals (B): Detects illegitimate critical hits, often used in
conjunction with spamming attacks.
o Autoclicker (J): Identifies rapid clicking actions associated with
spamming.
o Aim (S): Monitors for erratic or bot-like aim adjustments.
 Alerts:
o Flags excessive attack rates, illegitimate critical hits, or movement
inconsistencies.
  Effectiveness:
o High; Vulcan’s multi-layered detection for spamming behavior makes
it far more effective than Grim.
Conclusion: Vulcan effectively detects Spamming KillAura by focusing on rapid
attack, movement, and critical hit anomalies.

Double-Click KillAura (Used for testing packets)

Grim AntiCheat:
 Detection Method:
o AimDuplicateLook: Tracks repeated and automated aiming angles
caused by double-click-induced bots.
o Simulation: Identifies discrepancies between expected and actual
player behavior during rapid attacks.
o Timer: Flags timing anomalies caused by automated rapid double-
clicking.
 Alerts:
o Logs abnormal timing between attack packets or irregular aiming
adjustments.
  Effectiveness:
o Moderate; Grim AntiCheat identifies some double-clicking behavior
but lacks comprehensive coverage for advanced exploits.
Vulcan AntiCheat:
 Detection Method:
o KillAura (K) : Specifically identifies behaviors tied to double-click
bots.
o Criticals (B): Detects unauthorized critical hits, which often
accompany double-click cheats.
o Aim (S): Monitors robotic or overly consistent aiming patterns linked
to double-clicking.
o Velocity (A): Flags unusual movement patterns caused by abnormal
rapid attack actions.
o Autoclicker (J): Identifies excessively high click rates associated
with double-clicking behavior.
  Alerts:
o Flags double-click attack behaviors, irregular aiming patterns, or rapid
critical hits.

 Effectiveness:
o High; Vulcan’s specialized modules for KillAura and critical hits
make it highly effective against double-click cheats.
Conclusion: Vulcan far outperforms Grim in detecting Double-Click KillAura, as
it targets specific attack and movement irregularities that Grim overlooks.

Overall Assessment
 Grim AntiCheat:
o Strength: Simulation-based checks like AimDuplicateLook and Timer
help detect timing and aiming anomalies.
o Weakness: Lacks coverage for critical hits, velocity-based anomalies,
and precise aim tracking.
 Vulcan AntiCheat:
o Strength: Covers a broader range of behaviors, including clicking,
aiming, movement, and combat-related irregularities.
 o Weakness: May require fine-tuning thresholds to prevent false
positives.
Vulcan’s broader detection capabilities and precision make it the better choice for
identifying all three types of KillAura.

SOURCE CODE
1. Prepare a Comprehensive Demonstration Plan
Objective:
To demonstrate:
1. How cheats operate: Behavior manipulation (e.g., KillAura, Speed).
2. How anti-cheats detect cheats: Alert mechanisms and logic in Grim and
Vulcan.
3. How the source code supports the detection: Proof of understanding
through live coding, testing, and explaining detection mechanisms.
Preparation:
 Environment Setup:
o A Minecraft server with Grim and Vulcan AntiCheat installed.
o Two clients:
 One with legitimate behavior.
 One running cheating software (e.g., KillAura, Speed hacks).
o A proxy (e.g., HAProxy) with Wireshark monitoring traffic.
 Tools:
o A debugger (e.g., IntelliJ IDEA, Eclipse) to step through the anti-cheat
source code in real-time.
o Wireshark to capture packet anomalies caused by cheats.
2. Demonstration Steps
A. Explain the Cheat
1. Overview:
o Describe how cheats like KillAura and Speed manipulate gameplay
mechanics.
o Use visuals or diagrams to show packet flow, such as:
arduino
Copy code
Legitimate Client → Proxy → Server
Cheating Client → Proxy → Server (Automated, Abnormal Packets)
2. Live Demonstration:
o Enable KillAura on the cheating client.
o Show:
 How the client automates attacks with impossible
speed/precision.
 Packet patterns (e.g., repetitive UseEntity commands or
excessive CPS).
o Enable Speed hack:
 Show unnatural movement patterns (e.g., constant
PlayerPosition packets with rapid coordinate changes).
3. Technical Insight:
o Explain what abnormal data looks like:
 KillAura: High CPS, perfect aim.
 Speed: Sudden and large velocity changes, abnormal Y-
coordinates.
o Highlight how cheats bypass server rules.
B. Explain the Anti-Cheat’s Role
1. Overview:
o Show Grim and Vulcan’s detection goals: flagging and mitigating
cheats using simulations, velocity checks, and packet analysis.
2. Live Alert Demonstration:
o Trigger the anti-cheat while running the cheats:
 Grim: Demonstrate how Simulation flags mismatched
movement.
 Vulcan: Show alerts like KillAura (K) or Velocity (A) for
abnormal patterns.

C. Prove Source Code Understanding

Here’s how to prove understanding of the anti-cheat code in action.
1. Open the Source Code in a Debugger:
o Use an IDE (e.g., IntelliJ) to step through the detection logic as cheats
run.
o Place breakpoints in key methods (e.g., Grim’s checkSimulation or
Vulcan’s detectAutoclicker).
2. Show Detection in Real-Time:
o Execute a cheating action (e.g., attacking with KillAura).
o In the debugger:
 Pause at the detection logic.
 Walk through each line of code to explain how the cheat is
identified.
3. Detailed Explanation:
Grim AntiCheat
Grim focuses on simulation and packet validation to detect cheats by
comparing player actions with expected behavior based on Minecraft’s game
mechanics.
1. Simulation
 Purpose: Detects anomalies in player movement by predicting their position
using physics and comparing it to actual data.
 Code Breakdown:

o calculateExpectedPosition: Uses velocity, momentum, and collision

logic to predict where the player should be.
o How It Works:
 Predicts movement (e.g., based on jump height or sprint speed).
 Flags deviations, such as Speed hacks or Fly cheats, where
positions do not align with physics.

2. GroundProof
 Purpose: Detects illegal vertical movements (e.g., Fly cheats, NoFall).
 Code Breakdown:

o isOnGround: Checks if the player is standing on a valid block.

o How It Works:
 Verifies if the player correctly interacts with the ground.
  Flags players hovering mid-air without triggering fall damage.

3. BadPacketsN
 Purpose: Inspects malformed or contradictory packet data sent by the client.
 Code Breakdown:

o How It Works:
 Detects packets with impossible timestamps, positions, or
rotations.
 Targets cheats that modify packets to spoof legitimate behavior.

4. Timer
 Purpose: Detects irregular action intervals (e.g., Speed or Timer cheats).
 Code Breakdown:

o How It Works:
 Monitors the time gap between actions.
 Flags rapid actions, such as attacking faster than the game's
CPS limit.

5. NoFall
 Purpose: Detects cheats that suppress fall damage.
 Code Breakdown:
 o How It Works:
 Verifies if the player took fall damage after a significant drop.
 Flags players bypassing fall mechanics.

6. AimDuplicateLook
 Purpose: Detects automated aiming behaviors (e.g., KillAura aim-lock).
 Code Breakdown:

o How It Works:
 Compares the player’s aim rotation between consecutive
packets.
 Flags perfect aim, which is humanly impossible.

Vulcan AntiCheat
Vulcan uses modular detection to track nuanced patterns in player behavior
over time. Below are detailed explanations of its modules.

1. Motion (B)
 Purpose: Detects Speed cheats or inconsistent motion behavior.
 Code Breakdown:
How It Works:
 Tracks player velocity and acceleration.
 Flags unnatural spikes caused by Speed or Fly cheats.

2. Jump (A)
 Purpose: Detects abnormal jump heights.
 Code Breakdown:

o How It Works:
 Compares player jump height to Minecraft's natural jump
limits.
 Flags cheats that modify jump mechanics (e.g., Fly or
BunnyHop).

3. Criticals (B)
 Purpose: Detects unauthorized critical hits.
 Code Breakdown:

o How It Works:
 Verifies if critical hits occur only during valid mid-air
conditions.
  Flags invalid hits triggered by cheat tools.

4. Autoclicker (C, J)
 Purpose: Detects automated or macro-based clicking.
 Code Breakdown:

o How It Works:
 Tracks the time between clicks.
 Flags repetitive clicking patterns exceeding CPS limits.

5. Aim (L, S)
 Purpose: Detects aim-assist or bot-like aiming patterns.
 Code Breakdown:

o How It Works:
 Tracks player aim adjustments during combat.
 Flags perfect aim changes or erratic snaps to targets.

6. KillAura (K)
 Purpose: Detects repeated attack patterns associated with combat cheats.
 Code Breakdown:
 o How It Works:
 Combines attack patterns with aim data.
 Flags attacks that exceed human reaction capabilities.

7. Velocity (A)
 Purpose: Detects unnatural knockback reduction.
 Code Breakdown:

o How It Works:
 Verifies knockback is within expected limits.
 Flags players modifying velocity to resist knockback.

8. Hitbox (A)
 Purpose: Detects illegal hitbox interactions.
 Code Breakdown:

o How It Works:
 Checks if the player’s hits align with valid hitbox ranges.
 Flags cheats extending attack range or bypassing hitboxes.
Summary
Grim and Vulcan use distinct approaches:
1. Grim: Focuses on packet validation and simulation-based checks.
2. Vulcan: Employs modular analysis for nuanced patterns over time.

3. Address Questions and Challenges

Prepare for Common Questions:
 What are the limitations of these anti-cheats?
o Grim: May miss subtle cheats mimicking legitimate play.
o Vulcan: Requires tuning to balance false positives and false negatives.
 How would you improve the anti-cheat?
o Combine simulation and modular detection.
o Use machine learning to analyze long-term behavior patterns.
Propose Improvements:
 Implement additional detection mechanisms (e.g., trajectory analysis for
KillAura).
 Integrate traffic analysis (e.g., detecting burst packet rates for Speed cheats).

4. Supporting Materials
Documentation:
 Provide annotated copies of the Grim and Vulcan source code.
 Highlight:
o Key methods responsible for detecting KillAura, Speed, and other
cheats.
 o Logs showing how alerts are generated.
Traffic Analysis:
 Include Wireshark logs showing differences between legitimate and cheating
clients.

TRI DUC

Theory
Information
Proxy used: HAProxy.
192.168.1.215: Proxy server (is used to capture both PC and Laptop
data).
192.168.1.87: Cheating client (PC).
192.168.1.88: Vanilla client (Laptop).
Vanilla client use Optifine 1.21.1.
Cheating client is in 1.21.1 version.
Minecraft’s server is in 1.21.1 version.
Tool used to analyze: Wireshark.

Network protocols
TCP
In Minecraft, TCP (Transmission Control Protocol) is used for most of
Minecraft's communication, particularly in server-client interactions for
gameplay (Player movement, chat messages, block updates, and
inventory management are sent as TCP packets).
Its features like reliability, sequencing, and error-checking are crucial for
consistent gameplay experiences.
TCP ensures that all packets are delivered and arrive in order, which is
crucial for synchronization between players and the server. For example,
when a player moves, the server must receive that data in the correct
sequence to update the game state accurately.
TCP can introduce latency due to its strict error-checking and
retransmission mechanisms, which can affect gameplay responsiveness
in high-latency or packet-loss environments.

UDP
UDP (User Datagram Protocol) is less commonly used in Minecraft but
is critical for certain features and mods that prioritize speed over
reliability. For example, the Minecraft client pings the server using UDP
to fetch server information (Message of the Day, player count).
Futhermore, Minecraft servers are frequent targets of UDP-based
Distributed Denial of Service (DDoS) attacks due to UDP’s
connectionless nature. Security measures like rate-limiting and packet
filtering are often employed to mitigate this risk.
However, UDP does not guarantee packet delivery or order, which
makes it less suitable for Minecraft’s core gameplay mechanics where
synchronization is critical.

Comparison of TCP vs. UDP in Minecraft

 Feature TCP UDP
Guarantees delivery and
Reliability No delivery guarantee
order
Higher due to error- Lower due to minimal
Latency
checking overhead
Usage in Core gameplay
Ping requests, mods
Gameplay communication
MITM attacks, session
Security Risks DDoS, spoofing
hijacking
Mitigation for
Encryption, validation Rate-limiting, filtering
Risks

Killaura from Liquidbounce

Spamming "Double click" method while standing still.

Spamming method while moving.

Y Port Speed Hack

This hack manipulates the player's position by forcing high-speed

vertical movement, often causing them to "teleport" to specific heights
or locations. It bypasses normal physics checks by rapidly adjusting the
player's Y-coordinate, which can confuse anti-cheats.

Analysis of Killaura
Open Wireshark and load the file containing the captured data
“SuccessKillaura”.
Filter traffic to focus on packets involving the Minecraft server
(103.110.32.47) and the proxy (192.168.1.215):
ip.addr == 192.168.1.215 && tcp.port == 25565.
Running default (no Anti-Cheat)
Plugin Anti-Cheat of Minecraft (Vulcan and Grim) is offline during this
analysis.
Packet Rate
Go to Statistics > IO Graphs:
Set the Y-axis unit to Packets/Tick.
Use ip.src == 192.168.1.87 (cheating client) and ip.src == 192.168.1.88
(vanilla client) as separate filters.
Compare the packet rate over time.

The cheating client (red line) send packets at a similar rate to the vanilla
client (green line) since the cheating client tried to disguise as a normal
client, make it harder for server to detect the cheating client.

Packet Size
Go to Statistics > Packet Lengths.
Compare the distribution of packet sizes for both clients.
Use ip.src == 192.168.1.87 (cheating client) and ip.src == 192.168.1.88
(vanilla client) as separate filters.
1. Cheating Client:
Cheating clients will often have a spike at specific lengths.
Cheating actions often generate smaller, repetitive packets.
Cheating clients have consistent sizes in the payload (attacks).

The cheating client sends far more packets than the vanilla client in the
same timeframe, indicating higher activity. This behavior is consistent
with cheats like KillAura or speed cheats that send numerous packets to
simulate actions like rapid attacks or excessive movement.
The presence of these larger packets (160 - 319 and 320 - 639 bytes
ranges) suggests the client is performing operations that involve
additional or modified data, such as attack combinations or other cheats
generating non-standard packets.
Burst Rate: 0.2800 (compared to 0.1500 for the vanilla client). The
cheating client exhibits a significantly higher burst rate, indicating
periods of rapid packet generation. This can occur when the cheat client
sends multiple attack or movement commands in quick succession,
overwhelming the server.

2. Vanilla Client:
Packet sizes will vary based on legitimate actions like movement, chat,
or interaction.
The vanilla client sends packets at a steady and predictable rate, aligning
with standard player actions in Minecraft (normal movement, block
placement).
Most packets fall into the 40-79 bytes (67.37%) and 80-159 bytes
(32.63%) ranges, with no packets in higher ranges. This clean
distribution is typical of normal gameplay traffic without additional data
modifications or excessive packet sizes.

Packet Timing
Add a filter to separate traffic for the cheating and vanilla clients: ip.src
== 192.168.1.87 || ip.src == 192.168.1.88.
Right-click on a packet, select Follow > TCP Stream.

Navigate to View > Time Display Format > Seconds Since Previous
Displayed Packet. This adjusts the Time column in the Packet List
Pane to show the time elapsed since the last displayed packet, helping
you detect gaps or bursts in communication.
Note the time delta between packets in the stream.

1. Cheating Client:
Packet timing is vary based on player actions, resulting in an uneven
pattern, similar to Vanilla client since the cheating client need to disguise
to fool the server.
There are repeated TCP Retransmissions and duplicate
acknowledgments (duplicate ACKs).
Retransmissions occur when the original packet is either lost or not
acknowledged, while duplicate ACKs occur when the server
acknowledges the same sequence number multiple times, indicating that
packets are arriving out of order or are being retransmitted excessively.
While some retransmissions are normal in a network with packet loss,
the high frequency here suggests that the server is deliberately ignoring
certain packets due to protocol violations or detected cheating behavior
or the client is sending packets too fast, overwhelming the connection.
This is suspicious given that many cheating clients attempt to exploit the
protocol by:
- Sending malformed packets to bypass checks.
- Spamming high-frequency packets to overwhelm the server or gain
an advantage (speed or teleport cheats).
Retransmissions and duplicate ACKs might result from cheats
generating packets faster than the server can handle.

2. Vanilla Client:
Packet timing is vary based on player actions, resulting in an uneven
pattern.
The MCJE protocol (likely referring to Minecraft Java Edition) shows
Invalid Protocol data is not compatible with the current plugin version.
This suggests the client might be sending malformed or non-standard
packets, which is unusual for a legitimate client. This could be due to:
- A modification or "cheat client" generating non-standard protocol
packets.
 - A version mismatch or intentional exploitation of protocol
incompatibilities.
Since Vanilla client uses Optifine 1.21.1, it might be because the
Optifine have an outdated protocols that have not yet removed.

Conclusion
Cheating clients often modify packet behavior in the following ways:
1. Increased Packet Volume:
o Cheats like KillAura or speed cheats send a large number of
packets in a short time to simulate rapid actions, such as
attacking multiple entities or moving at unnatural speeds.
2. Modified Packet Lengths:
o Larger packets may include additional or manipulated data to
bypass server-side anti-cheat mechanisms or exploit
vulnerabilities in the protocol.
3. Higher Burst Rates:
o Cheating clients often produce bursts of packets during
specific actions (e.g., rapid attacks), which deviate from the
steady packet flow of a vanilla client.
4. Irregular Packet Distribution:
o The packet length distribution from the cheating client
indicates non-standard operations, whereas the vanilla client
has a predictable range of packet sizes.
The cheating client's increased packet count, higher burst rate, and non-
standard packet lengths suggest it is performing automated or unnatural
actions beyond what a normal player could input.
The vanilla Minecraft protocol is designed to handle steady player inputs
and actions. Excessive or unusually large packets from a client can
disrupt gameplay and indicate exploitation.

The cheating client's behavior is unusual and indicative of automated

actions or protocol exploitation. This is evidenced by:
1. High Packet Volume: Over 3x the packets sent by the vanilla
client.
2. Irregular Packet Lengths: Larger packets likely contain cheat-
specific data.
3. Higher Burst Rate: Indicative of rapid, automated actions (e.g.,
KillAura attacks).
These patterns strongly suggest that the client is using cheats or
modifications to gain an unfair advantage in the game.

Running Anti-Cheat
Plugin Anti-Cheat of Minecraft (Vulcan and Grim) is online during this
analysis.

Packet Rate
Go to Statistics > IO Graphs:
Set the Y-axis unit to Packets/Tick.
Use ip.src == 192.168.1.87 (cheating client) and ip.src == 192.168.1.88
(vanilla client) as separate filters.

Compare the packet rate over time.

 1. Cheating Client (red line):
Cheating clients (KillAura) send packets at a high rate due to automated
actions (continuous attacking) that get detected and interrupted by Anti-
Cheat, which caused the client keep resending the packet.
Cheating clients have an unusually high number of packets per second
(pps).

2. Vanilla Client (green line):

Vanilla clients generate traffic at a slower, more natural rate.

Packet Size
Go to Statistics > Packet Lengths.
Compare the distribution of packet sizes for both clients.
Use ip.src == 192.168.1.87 (cheating client) and ip.src == 192.168.1.88
(vanilla client) as separate filters.
3. Cheating Client:
Cheating clients will often have a spike at specific lengths.
Cheating actions often generate smaller, repetitive packets.
Cheating clients have consistent sizes in the payload (attacks).

Same reason when not running Anti-Cheat.

4. Vanilla Client:

Packet sizes will vary based on legitimate actions like movement, chat,
or interaction.
Same reason when not running Anti-Cheat.

Packet Timing
Add a filter to separate traffic for the cheating and vanilla clients: ip.src
== 192.168.1.87 || ip.src == 192.168.1.88.
Right-click on a packet, select Follow > TCP Stream.

Navigate to View > Time Display Format > Seconds Since Previous
Displayed Packet. This adjusts the Time column in the Packet List
Pane to show the time elapsed since the last displayed packet, helping
you detect gaps or bursts in communication.
Note the time delta between packets in the stream.

3. Cheating Client:
Cheating clients send packets at consistent, rapid intervals (attacking
every 50ms).

Same reason when not running Anti-Cheat, but it happened in a

consistent, rapid intervals because that is the same rate of Anti-Cheat
detect and stop packet.

4. Vanilla Client:
Packet timing will vary based on player actions, resulting in an uneven
pattern.
Same reason when not running Anti-Cheat.

Conclusion
After we analyzed packet rates, sizes, timing, and contents when running
Anti-Cheat, we compare the differences:
1. Cheating Client:
 - High packet rates.
- Consistent packet sizes.
- Repetitive patterns in payloads.

2. Vanilla Client:
- Moderate or varied packet rates.
- Mixed packet sizes.
- Non-repetitive payloads reflecting natural actions.

Analysis of Y Port speed cheating

Open Wireshark and load the file containing the captured data
“SpeedSuccess2”.

Not Running Anti-Cheat

Packet Rate
Go to Statistics > IO Graphs:
Set the Y-axis unit to Packets/Tick.
Use ip.src == 192.168.1.87 (cheating client) and ip.src == 192.168.1.88
(vanilla client) as separate filters.
Go to Statistics > I/O Graph > Interval and reduce it (e.g., 0.1s) for a
more granular view of bursty traffic.

Compare the packet rate over time.

 1. Cheating Client (red line):
The red line (cheating client) could reflect bursty behavior, where high
packet rates occur in short timeframes but fewer packets are sent during
other intervals.
Cheating clients using speed cheats often rely on irregular packet bursts
to simulate accelerated movement. These bursts can temporarily
overwhelm the server or client but might not span the entire duration of
the capture.

2. Vanilla Client (green line):

Vanilla clients, on the other hand, send packets at a more predictable rate
(regular movement updates or keep-alive packets).

Packet Size
Go to Statistics > Packet Lengths.
Compare the distribution of packet sizes for both clients.
Use ip.src == 192.168.1.87 (cheating client) and ip.src == 192.168.1.88
(vanilla client) as separate filters.
1. Cheating Client:
Cheating clients have consistent sizes in the payload (attacks).

Same explaination in killaura cheat.

2. Vanilla Client:

Packet sizes will vary based on legitimate actions like movement, chat,
or interaction. During the analyzing, the Vanilla client was lagging,
leading to a spike in packet size.

Same explaination in killaura cheat.

Packet Timing
Add a filter to separate traffic for the cheating and vanilla clients: ip.src
== 192.168.1.87 || ip.src == 192.168.1.88.
Right-click on a packet, select Follow > TCP Stream.

Navigate to View > Time Display Format > Seconds Since Previous
Displayed Packet. This adjusts the Time column in the Packet List
Pane to show the time elapsed since the last displayed packet, helping
you detect gaps or bursts in communication.
Note the time delta between packets in the stream.

1. Cheating Client:
Cheating clients send packets at consistent, rapid intervals.

Same explaination in killaura cheat.

2. Vanilla Client:
Packet timing will vary based on player actions, resulting in an uneven
pattern.

Same explaination in killaura cheat.

Conclusion
After we analyzed packet rates, sizes, timing, and contents, we noticed
that the cheating client likely sent more packets overall but in bursts
rather than consistently over time while the vanilla client might send
packets at a steady rate. This leads to the misleading results in the I/O
Graph due to its time-based sampling intervals.

Running Anti-Cheat
Packet Rate
Go to Statistics > IO Graphs:
Set the Y-axis unit to Packets/Tick.
Use ip.src == 192.168.1.87 (cheating client) and ip.src == 192.168.1.88
(vanilla client) as separate filters.

Go to Statistics > I/O Graph > Interval and reduce it (e.g., 0.1s) for a
more granular view of bursty traffic.
Compare the packet rate over time.
1. Cheating Client (red line):
The red line (cheating client) could reflect bursty behavior, where high
packet rates occur in short timeframes but fewer packets are sent during
other intervals.
Cheating clients using speed cheats often rely on irregular packet bursts
to simulate accelerated movement. These bursts can temporarily
overwhelm the server or client but might not span the entire duration of
the capture.

2. Vanilla Client (green line):

Vanilla clients, on the other hand, send packets at a more predictable rate
(regular movement updates or keep-alive packets).
Packet Size
Go to Statistics > Packet Lengths.

Compare the distribution of packet sizes for both clients.

Use ip.src == 192.168.1.87 (cheating client) and ip.src == 192.168.1.88
(vanilla client) as separate filters.
1. Cheating Client:
Cheating clients have consistent sizes in the payload (attacks).

Same explaination in killaura cheat.

2. Vanilla Client:

Packet sizes will vary based on legitimate actions like movement, chat,
or interaction.

Same explaination in killaura cheat.

Packet Timing
Add a filter to separate traffic for the cheating and vanilla clients: ip.src
== 192.168.1.87 || ip.src == 192.168.1.88.
Right-click on a packet, select Follow > TCP Stream.

Navigate to View > Time Display Format > Seconds Since Previous
Displayed Packet. This adjusts the Time column in the Packet List
Pane to show the time elapsed since the last displayed packet, helping
you detect gaps or bursts in communication.
Note the time delta between packets in the stream.

1. Cheating Client:
Cheating clients send packets at consistent, rapid intervals.

2. Vanilla Client:
Packet timing will vary based on player actions, resulting in an uneven
pattern.

Same explaination in killaura cheat.

Conclusion
After we analyzed packet rates, sizes, timing, and contents, we noticed
that the cheating client likely sent more packets overall but in bursts
rather than consistently over time while the vanilla client might send
packets at a steady rate. This leads to the misleading results in the I/O
Graph due to its time-based sampling intervals.