Killaura and reach hacks

Reach: the plain one, with a caveat

A player's arm reaches about three blocks. A hit landed further away than that did not happen, whatever tool is held. That is a single comparison, and it needs one thing the check cannot get from the attacking client: where the target actually was. That comes from the packet stream the server sends, which is why combat detection needs a proxy that reads both directions rather than just the client's side.

The caveat is latency. A player with a slow connection is genuinely swinging at where the target used to be, because that is the only position their client has been told about. The measurement is honest — the distance really is too great — but the player is not cheating. So the tolerance has to be generous and has to widen with the session's round-trip time. A tight reach check is a check that punishes distance from the server, which is a thing players cannot fix and did not choose.

There is a second trap here that has nothing to do with cheating. To know where a target was, the proxy has to parse entity movement packets, and their field layouts change between game versions. A layout parsed wrongly gives a position that is silently wrong — and a wrong position is a reach flag against an innocent player. The correct handling is for every decoder to be length-exact: it must consume exactly the bytes the packet declared, or the entity is dropped and the check simply has no opinion. Degrading to "no position" is safe. Degrading to "a plausible-looking wrong position" is not.

Killaura: the signature is the sweep

Killaura is a module that attacks whatever is near you. What makes it visible is not any single hit — each one may be perfectly legal — but the set of things being hit.

A person fighting a crowd hits two or three entities in a moment, because a hand and a camera can only be pointed at so many things. A module sweeps. A burst of attacks against many distinct entities in a short window is a signature nothing else produces, and it is what separates a killaura from somebody who is simply better at the game than the person reporting them.

Killaura against one target: the camera gives it away

The sweep signature does not fire when a module is locked on a single opponent, which is the common configuration in a duel. The check that catches that one is about the camera.

A real attack begins as a click on a hitbox. The player was looking at the thing they hit — that is physically how the click happened. Killaura sends the attack packet without moving the view, because not having to aim is the entire feature. So the target sits well outside where the crosshair points, and the mismatch is measurable.

The tolerance has to be the target's own angular size — a large mob close up fills a lot more of the screen than a player at distance — plus a wide margin. And it must be a run of misses that accuses, never one: a hit landing on a target that moved between the packet being written and the proxy reading its position is ordinary lag, and it happens to everybody.

Aim: what is checkable and what is not

Two rules on the rotation stream are worth having.

An impossible pitch needs no window. No client can look further than straight up or straight down. A single packet outside that range is conclusive on its own.

A snap is a large jump followed immediately by near-stillness — which is what locking onto a target looks like. One is a coincidence, because players flick to look at things all the time. It is a run of them that accuses.

It is equally worth knowing what does not work, because it is the most commonly proposed aimbot check and it is wrong. The idea: a real mouse reports whole counts scaled by a sensitivity constant, so genuine rotation deltas should all share a common divisor, while an angle computed from a target's position does not. In practice Minecraft's yaw step is a cubic function of the sensitivity setting, and it lands cleanly on the protocol's angular quantum at essentially one sensitivity value and no other. At every other setting the greatest common divisor collapses to the quantum itself and the rule flags nearly every honest player. It is a good reminder that an elegant statistical test is worth nothing until it has been run against real clients at real settings.

Autoclickers: regularity, not rate

The obvious autoclicker check is a click rate no hand sustains, and it is worth having — but it is the weaker of the two rules, because a serious tool caps its rate below anything obviously impossible.

The stronger rule is the spread of the intervals. A human's clicking jitters, because a hand is not a clock. An autoclicker's intervals are near-identical by construction, and no amount of rate-capping changes that. Adding randomness is possible, but it is the thing cheap tools do not do and the thing that makes a tool measurably worse at what it was bought for.

Both rules need enough samples before they mean anything, which is why a verdict has to be withheld until the window is genuinely full. Calling somebody an autoclicker off four clicks is how honest players get kicked mid-fight.

Velocity: the hit that did nothing

When a player is hit, the server sends them a velocity, and a vanilla client applies it — that is knockback. A velocity modifier keeps some fraction of it, usually none, which is what makes a player impossible to combo and is one of the most frustrating cheats to play against.

One ignored knockback proves nothing. A player pressed against a wall, or already moving into the hit, legitimately travels almost nowhere. So each measured knockback is scored, and the accusation only comes once several in a row came to nothing. This is the clearest example in the whole anticheat of why runs beat events.

Why these need a proxy that reads both directions

Every check on this page needs something the attacking client never sends: where the other entities were, and what velocity the server applied. That information is in the server-to-client stream. A plugin has it, of course — but a plugin also spends the server's tick budget to compute all of this, and it is on the machine the attack is trying to overload.

Reading both directions at the proxy gets the same information without spending the server's ticks, and with nothing on the player's machine for a cheat client to interfere with. The trade-off is honest and worth repeating: to read packets rather than relay bytes, the proxy must speak the exact protocol version the client is using, and it must refuse to guess when it does not. See What is a Minecraft anticheat? for the full picture, and fly, speed and timer hacks for the movement side.