m2dev-client-src/docs/anti-cheat-architecture-2026.md

Anti-Cheat Architecture 2026

This document proposes a practical anti-cheat design for the current Metin2 client and server stack.

Date of analysis: 2026-04-16

Executive Summary

The current client contains only a weak integrity layer:

• src/UserInterface/ProcessCRC.cpp computes CRC values for the running binary.
• src/UserInterface/PythonNetworkStream.cpp calls BuildProcessCRC() when the client enters select phase.
• src/UserInterface/PythonNetworkStreamPhaseGame.cpp injects two CRC bytes into attack packets.
• src/UserInterface/PythonNetworkStreamPhaseGame.cpp contains a CG::HACK reporting path.
• src/UserInterface/ProcessScanner.cpp exists, but it is not wired into the live runtime.
• src/UserInterface/PythonNetworkStreamPhaseGame.cpp::__SendCRCReportPacket() is currently a stub that returns true.

This is not a production-grade anti-cheat. It raises the bar slightly for basic binary tampering, but it does not defend well against modern external tools, automation, packet abuse, or VM-assisted cheats.

The recommended 2026 design is:

1. Make the server authoritative for critical combat and movement rules.
2. Add telemetry and delayed-ban workflows.
3. Add a commercial client anti-cheat as a hardening layer, not as the primary trust model.
4. Treat botting and farming as a separate abuse problem with separate signals.

Goals

• Stop speedhack, combohack, rangehack, teleport, packet spam, and most forms of client-side state forgery.
• Raise the cost of memory editing, DLL injection, and automation.
• Reduce false positives by moving final judgment to server-side evidence.
• Keep the design compatible with a legacy custom client.

Non-Goals

• Absolute cheat prevention.
• Fully trusting a third-party kernel driver to solve game logic abuse.
• Real-time automatic bans on a single weak signal.

Current State

What exists today

• Client self-CRC:
  • src/UserInterface/ProcessCRC.cpp
• CRC pieces attached to outgoing attack packets:
  • src/UserInterface/PythonNetworkStreamPhaseGame.cpp
• Hack message queue and packet transport:
  • src/UserInterface/PythonNetworkStreamPhaseGame.cpp

What is missing today

• No active process blacklist or scanner integration in the runtime path.
• No complete CRC reporting flow to the server.
• No server-authoritative verification model documented in the current client source tree.
• No robust evidence pipeline for review, delayed bans, or behavioral scoring.

Recommended Architecture

Layer 1: Server-Authoritative Core

This is the most important layer. The server must become the source of truth for combat and movement outcomes.

Movement validation

The server should validate:

• maximum velocity by actor state
• acceleration spikes
• position delta against elapsed server time
• warp-only transitions
• path continuity through collision or map rules
• impossible Z transitions and fly transitions

Recommended outputs:

• hard reject for impossible moves
• suspicion score for repeated marginal violations
• session telemetry record

Combat validation

The server should validate:

• attack rate by skill and weapon class
• combo timing windows
• skill cooldowns
• victim distance and angle
• hit count per server tick
• target existence and visibility rules
• animation-independent skill gate timing

This removes most of the value of classic combohack, attack speed manipulation, and packet replay.

State validation

The server should own:

• HP / SP mutation rules
• buff durations
• item use success
• teleport authorization
• quest-critical transitions
• loot generation and pickup eligibility

Layer 2: Telemetry and Evidence

Do not ban on one event unless the event is impossible by design.

Collect per-session evidence for:

• movement violations
• attack interval violations
• repeated rejected packets
• target distance anomalies
• client build mismatch
• CRC mismatch
• anti-cheat vendor verdict
• bot-like repetition and route loops

Recommended workflow:

• score each event
• decay score over time
• trigger thresholds for:
  • silent logging
  • shadow restrictions
  • temporary action blocks
  • GM review
  • delayed ban wave

Delayed bans are important because instant bans teach attackers which checks worked.

Layer 3: Client Integrity

Use client integrity only as a supporting layer.

Recommended client responsibilities:

• verify binary and pack integrity
• report build identifier and signed manifest identity
• detect common injection or patching signals
• report tampering and environment metadata
• protect transport secrets and runtime config

Suggested upgrades to the current client:

• replace the current partial CRC path with a real signed build identity
• sign client packs and executable manifests
• complete __SendCRCReportPacket() and send useful integrity evidence
• remove dead anti-cheat code or wire it fully
• add secure telemetry batching instead of ad hoc string-only hack messages

Layer 4: Commercial Anti-Cheat

Recommended vendor order for this project

1. XIGNCODE3
2. BattlEye
3. Denuvo Anti-Cheat
4. Easy Anti-Cheat

Why this order

XIGNCODE3 looks like the best functional fit for a legacy MMO client:

• public positioning is strongly focused on online PC games
• public feature set includes macro detection, resource protection, and real time pattern updates
• market fit appears closer to older custom launchers and non-mainstream engine stacks

BattlEye is a strong option if you want a more established premium PC anti-cheat and can support tighter integration work.

Denuvo Anti-Cheat is technically strong, but it is likely the heaviest vendor path in both integration and commercial terms.

Easy Anti-Cheat is attractive if budget is the main constraint, but it should not change the core rule: the server must still be authoritative.

Layer 5: Anti-Bot and Economy Abuse

Botting should be treated as a separate control plane.

Recommended controls:

• route repetition heuristics
• farming loop detection
• vendor / warehouse / trade anomaly scoring
• captcha or interaction challenge only after confidence threshold
• account graph analysis for mule and funnel behavior
• hardware and device clustering where legally appropriate

Do not rely on captcha alone. It is only a friction tool.

Proposed Rollout

Phase 1: Fix trust boundaries

• document which outcomes are currently trusted from the client
• move movement and attack legality fully server-side
• add structured telemetry records

Deliverable:

• server can reject impossible movement and impossible attack cadence without any client anti-cheat dependency

Phase 2: Replace weak integrity

• complete binary and pack integrity reporting
• version all reports by client build
• bind reports to account, session, and channel

Deliverable:

• reliable client integrity evidence reaches the server

Phase 3: Vendor pilot

• integrate one commercial anti-cheat in observe mode first
• compare vendor verdicts with server suspicion score
• review false positives before enforcement

Deliverable:

• enforcement policy based on combined evidence

Phase 4: Ban and response pipeline

• implement delayed ban waves
• implement silent risk tiers
• implement GM review tooling

Deliverable:

• repeatable response process instead of ad hoc action

Concrete Changes For This Codebase

Client-side work:

• src/UserInterface/ProcessCRC.cpp
  • replace simple CRC flow with signed manifest and richer integrity report
• src/UserInterface/PythonNetworkStream.cpp
  • send integrity bootstrap at phase transition
• src/UserInterface/PythonNetworkStreamPhaseGame.cpp
  • implement real CRC and integrity packet submission
  • replace free-form hack strings with typed evidence events
• src/UserInterface/ProcessScanner.cpp
  • either remove dead code or reintroduce it as a fully designed subsystem

Server-side work:

• movement validator
• combat cadence validator
• anomaly scoring service
• evidence storage
• review and ban tooling

Design Rules

• Never trust timing sent by the client for legality.
• Never trust client-side cooldown completion.
• Never trust client position as final truth for hit validation.
• Never ban permanently on a single client-only signal.
• Never ship anti-cheat changes without telemetry first.

Success Metrics

• drop in successful speedhack and combohack reports
• drop in impossible movement accepted by the server
• reduced farm bot session length
• reduced economy inflation from automated abuse
• acceptable false positive rate during observe mode

Recommended Next Step

Implement Layer 1 before vendor integration.

If the server still accepts impossible combat or movement, a commercial anti-cheat only increases attacker cost. It does not fix the trust model.

External References

• Unity cheat prevention guidance
• Epic Easy Anti-Cheat public developer material
• BattlEye public developer material
• Wellbia XIGNCODE3 public product material
• Denuvo Anti-Cheat public product material
• Metin2Dev discussions around server-side validation, anti-bot workflows, and weak community anti-cheat releases