L'ennemi le plus exaspérant d'un serveur privé qui dure, ce sont les tricheurs, et une stratégie Metin2 anti hack efficace se construit presque entièrement côté serveur. Le client n'est jamais une source fiable : tout ce qui tourne sur la machine du joueur peut être modifié, injecté ou lu directement en mémoire. La vraie protection contre le speedhack, le wallhack et les triches de metins (casse de pierres) vient donc d'un serveur de jeu qui traite chaque paquet entrant avec méfiance et recalcule lui-même les règles du jeu.
Pourquoi la protection côté client ne suffit pas
Beaucoup de nouveaux propriétaires de serveur croient qu'installer GameGuard, XTrap ou un protecteur binaire similaire suffit. Ces outils relèvent le niveau avec le scan mémoire, la détection de débogueur et le blocage d'injection de DLL, mais aucun n'est inviolable. Le tricheur n'a qu'à contourner la protection ; une fois cela fait, si le serveur accepte les fausses données sans broncher, la partie est perdue.
- La protection client est dissuasive, pas un mur ; elle fait gagner du temps.
- La validation serveur est l'autorité finale ; même contournée, elle rejette l'action falsifiée.
- Dans la bonne architecture, le client dit « ce qu'il veut faire » et le serveur répond « peut-il » avec son propre calcul.
La règle d'or est donc simple : ne jamais faire confiance au client, tout revalider.
Validation du mouvement et du temps contre le speedhack
Le speedhack accélère artificiellement la boucle de jeu, déplaçant le personnage plus vite que la normale ou augmentant la vitesse d'attaque. Le client Metin2 envoie régulièrement des paquets de synchronisation (sync) au serveur, portant une position et un horodatage client. Côté serveur, vous devez calculer la distance que le personnage pourrait physiquement parcourir entre deux syncs et la comparer à la distance réelle.
La logique est à peu près celle-ci : la vitesse de déplacement actuelle convertit l'intervalle entre deux paquets en unités de distance. Si la position reçue tombe hors de ce rayon autorisé, le paquet est suspect.
// Pseudo-code : validation du mouvement côté serveur
float dt = now_ms - last_sync_ms; // temps écoulé en ms
float maxDist = (moveSpeed / 100.0f) * dt; // distance autorisée selon la vitesse
float tolerance = 1.15f; // marge pour le jitter réseau
float dist = distance(newPos, lastValidPos);
if (dist > maxDist * tolerance) {
sync_violation_count++;
if (sync_violation_count > THRESHOLD) {
LogHack(ch, "SPEED", dist, maxDist);
WarpToLastValid(ch); // renvoyer en arrière, puis punir si besoin
}
}Deux détails sont critiques ici. D'abord, sans une petite marge de tolérance pour la latence et le jitter, vous punirez à tort des joueurs légitimes. Ensuite, plutôt que de bannir sur une seule infraction, il est bien plus sain de tenir un compteur d'infractions et d'agir seulement quand un seuil est franchi. Ne faites jamais confiance directement à l'horodatage client ; recoupez-le avec l'horloge du serveur, car le temps lui-même peut être manipulé.
Wallhack, téléportation et sauts de distance
Les triches de wallhack et de téléportation contournent les contrôles de collision pour faire traverser les murs au personnage ou le projeter instantanément vers une coordonnée lointaine. La même validation sync en attrape déjà l'essentiel : un saut de position soudain et physiquement impossible dépasse le seuil de distance. Pour renforcer cela :
- Vérifiez les cellules bloquantes avec une carte de hauteur / données d'atlas côté serveur ; si la cellule cible n'est pas praticable, rejetez le mouvement.
- N'autorisez les transitions de carte que par des points de warp définis ; si un joueur tente de passer sur une autre carte depuis une coordonnée interdite, jetez le paquet.
- Validez aussi les sauts sur l'axe Z / hauteur ; les fly hacks se trahissent souvent sur l'axe vertical.
Un point important : conserver les données de collision sur le serveur coûte de la mémoire et du CPU supplémentaires, mais c'est le seul moyen fiable de neutraliser le wallhack. Que le client dise « je suis ici » ne suffit pas ; le serveur doit savoir si ce point est réellement accessible.
Contrôle de portée contre les triches de metins et d'attaque
Le « metin hack » couvre en général deux choses : frapper une pierre metin à distance sans réellement s'en approcher, ou attaquer en boucle à une vitesse impossible. La solution est encore la validation côté serveur. Quand un paquet d'attaque ou de « casse de pierre » arrive, le serveur doit vérifier :
- Portée : si la distance entre l'attaquant et la cible dépasse la portée autorisée de l'arme/attaque, rejeter.
- Validité de la cible : la cible est-elle vraiment sur cette carte, en vue et dans un état attaquable ?
- Vitesse d'attaque (cooldown) : si l'intervalle entre deux attaques est inférieur au cooldown minimal calculé d'après la vitesse d'attaque du personnage, ignorer les coups en trop.
// Pseudo-code : contrôle de portée et de cooldown d'attaque
if (distance(attacker, victim) > weaponRange + RANGE_BUFFER) {
return ATTACK_REJECTED; // hors de portée
}
if (now_ms - lastAttack_ms < minAttackInterval(attacker)) {
attackSpeedViolations++; // frappe trop vite
return ATTACK_REJECTED;
}
lastAttack_ms = now_ms;Comme les bots d'auto-attaque et d'auto-farm poussent eux aussi cette logique de cooldown et de portée, ces mêmes contrôles forment votre première ligne de défense contre les bots de farm. Ne prenez pas non plus la valeur de dégâts depuis le client ; laissez toujours le serveur calculer les dégâts d'après les stats du personnage.
Journalisation, détection d'anomalies et sanction graduée
Un système Metin2 anti hack ne doit pas être qu'un « bloquer » ; il doit aussi être visible. Journalisez chaque infraction avec un horodatage, l'ID du joueur, la carte et les valeurs mesurées. Ces logs servent à trois choses : écarter les faux bans de joueurs légitimes, repérer tôt les nouveaux types de triche et coincer les récidivistes avec des preuves.
- Sanction graduée : avertissement + renvoi en arrière à la première infraction, kick court en cas de répétition, ban temporaire automatique pour les acharnés.
- Décisions par seuil : un seul pic de lag ne doit pas devenir un ban ; déclencher seulement à X infractions dans une fenêtre.
- Rapports d'anomalie : surveillez des métriques comme le nombre de metins tués par minute ou la courbe de gain d'EXP et signalez les valeurs aberrantes.
Une fois ces enregistrements d'infractions écrits en base de données transformés en graphiques dans un simple panneau d'administration, il devient très facile de voir sur quelles cartes et quels types de triche se concentrent.
Questions fréquentes
Installer GameGuard ou XTrap suffit-il ?
Non. Ces outils compliquent la vie côté client et dissuadent, mais ils peuvent être contournés. La vraie sécurité vient du serveur qui revalide chaque mouvement et chaque attaque par lui-même. Utiliser les deux ensemble donne le meilleur résultat : la protection client relève le niveau, la validation serveur est la barrière finale.
La validation côté serveur coûte-t-elle beaucoup en performances ?
Les contrôles de distance et de cooldown sont quelques multiplications-soustractions ; leur coût est négligeable. La vraie charge est de garder les données de collision/atlas en mémoire, ce qui ne pose pas de problème pour un VPS moderne. Un contrôle bien optimisé reste imperceptible même avec des milliers de joueurs.
Comment éviter de bannir des joueurs légitimes par erreur ?
Utilisez le trio marge de tolérance, compteur d'infractions et sanction graduée. Ne bannissez jamais sur une seule mesure ; le jitter réseau et le lag sont normaux. Journalisez et renvoyez en arrière d'abord, et n'appliquez les peines permanentes qu'aux infractions répétées et claires.
Vous voulez nettoyer votre serveur des tricheurs ? De la mise en place des couches de validation speedhack/wallhack/metin dans la source Metin2 jusqu'à l'infrastructure de portée d'attaque et de journalisation, je peux vous aider de bout en bout. Contactez-moi pour parler de votre projet.