The most frustrating enemy of any long-lived private server is cheaters, and an effective Metin2 anti hack strategy is built almost entirely on the server side. The client is never a trustworthy source: anything running on the player's machine can be modified, injected into, or read straight from memory. Real protection against speedhack, wallhack and metin (stone-breaking) cheats therefore comes from a game server that treats every incoming packet with suspicion and recomputes the rules of the game for itself.
Why client-side protection isn't enough
Many new server owners assume that installing GameGuard, XTrap or a similar binary protector is enough. These tools raise the bar with memory scanning, debugger detection and DLL-injection blocking, but none of them are unbreakable. All a cheater has to do is bypass the protection; once they manage that, if the server accepts fake data without question, the game is over.
- Client protection is a deterrent, not a wall; it buys time.
- Server validation is the final authority; even if bypassed, it rejects the fake action.
- In the right architecture the client says "what it wants to do," and the server answers "can it" using its own calculation.
So the golden rule is simple: never trust the client, revalidate everything.
Movement and timing validation against speedhack
Speedhack artificially accelerates the game loop, moving the character faster than normal or raising attack speed. The Metin2 client regularly sends synchronization (sync) packets to the server carrying position and a client timestamp. What you must do server-side is compute how far the character could physically travel in the time between two syncs and compare it against the real distance.
The logic is roughly this: the character's current movement speed converts the interval between two packets into units of distance. If the incoming position falls outside that allowed radius, the packet is suspicious.
// Pseudo-code: server-side movement validation
float dt = now_ms - last_sync_ms; // elapsed time in ms
float maxDist = (moveSpeed / 100.0f) * dt; // allowed distance from speed
float tolerance = 1.15f; // margin for network jitter
float dist = distance(newPos, lastValidPos);
if (dist > maxDist * tolerance) {
sync_violation_count++;
if (sync_violation_count > THRESHOLD) {
LogHack(ch, "SPEED", dist, maxDist);
WarpToLastValid(ch); // warp back, then punish if needed
}
}Two details are critical here. First, without a small tolerance margin for latency and jitter, you will wrongly punish legitimate players. Second, instead of banning on a single violation, it is far healthier to keep a violation counter and act only once a threshold is crossed. Never trust the client timestamp directly; cross-check it against the server's own clock, because time itself can be manipulated.
Wallhack, teleport and distance jumps
Wallhack and teleport cheats bypass collision checks to push the character through walls or jump it to a distant coordinate instantly. The same sync validation already catches most of this: a sudden, physically impossible position jump blows past the distance threshold. To reinforce it:
- Check blocking cells with a server-side height map / atlas data; if the target cell is not walkable, reject the movement.
- Allow map transitions only through defined warp points; if a player tries to cross to another map from a forbidden coordinate, drop the packet.
- Validate Z-axis / height jumps as well; fly hacks usually give themselves away on the vertical axis.
One important point: keeping collision data on the server costs extra memory and CPU, but it is the only reliable way to shut down wallhack. The client saying "I'm here" is not enough; the server must know whether that point is actually reachable.
Range checks against metin stone and attack cheats
"Metin hack" usually covers two things: a player hitting a metin stone from a distance without actually approaching it, or attacking repeatedly at an impossible speed. The solution is again server-side validation. When an attack or "break stone" packet arrives, the server must check:
- Range: if the distance between attacker and target exceeds the weapon's/attack's allowed range, reject.
- Target validity: is the target really on that map, in view, and in an attackable state?
- Attack speed (cooldown): if the interval between two attacks is shorter than the minimum cooldown computed from the character's attack speed, ignore the excess hits.
// Pseudo-code: attack range and cooldown check
if (distance(attacker, victim) > weaponRange + RANGE_BUFFER) {
return ATTACK_REJECTED; // out of range
}
if (now_ms - lastAttack_ms < minAttackInterval(attacker)) {
attackSpeedViolations++; // hitting too fast
return ATTACK_REJECTED;
}
lastAttack_ms = now_ms;Because auto-attack and auto-farm bots also push this cooldown and range logic, the same checks form your first line of defense against farm bots too. Never take the damage value from the client either; always let the server compute damage from the character's own stats.
Logging, anomaly detection and graduated punishment
A Metin2 anti hack system should not be just "block"; it should also be visible. Log every violation with a timestamp, player ID, map and the measured values. These logs serve three purposes: filtering out false bans of legitimate players, spotting new cheat types early, and catching repeat offenders with evidence.
- Graduated punishment: warning + warp-back on the first violation, a short kick on repeats, an automatic temporary ban for the persistent.
- Threshold-based decisions: a single lag spike must not turn into a ban; trigger only at X violations within a window.
- Anomaly reports: watch metrics like metins killed per minute or the EXP gain curve and flag outliers.
Once these violation records written to the database are turned into charts in a simple admin panel, it becomes very easy to see which maps and which cheat types are spiking.
Frequently Asked Questions
Is installing GameGuard or XTrap enough?
No. These tools make life harder on the client side and act as a deterrent, but they can be bypassed. Real security comes from the server revalidating every move and attack on its own. Using both together gives the best result: client protection raises the bar, server validation is the final barrier.
Does server-side validation cost a lot of performance?
Distance and cooldown checks are a few multiply-subtract operations; their cost is negligible. The real load is keeping collision/atlas data in memory, which is no problem for a modern VPS. A properly optimized check is unnoticeable even with thousands of players.
How do I avoid banning legitimate players by mistake?
Use the trio of tolerance margin, violation counter and graduated punishment. Never ban on a single measurement; network jitter and lag are normal. Log and warp back first, and apply permanent penalties only to repeated, clear violations.
Want to clean cheaters off your server? From building speedhack/wallhack/metin validation layers in the Metin2 source to attack-range and logging infrastructure, I can help end to end. Get in touch to talk about your project.