CRACKEDONTITI.DEV

All selected work

VigilanSee

Server-side behavioural anti-cheat and community moderation, CS2 first, designed to be game-agnostic. Nothing is installed on the player's machine.

Role
Modelling maths and project engineering
Team
Team of 4
When
In progress
  • Rust
  • PostgreSQL
  • Docker
  • REST API

Problem

Detect cheating without a kernel-level, client-side anti-cheat. Everything runs on the server side, and nothing is installed on the player’s machine.

What I built

VigilanSee is our Epitech end-of-studies project (EIP), built by a team of four and planned to continue as a business. My parts:

  • the modelling maths, based on shrinkage-based optimisation;
  • project engineering: CI, Docker build checks, Dependabot, architecture decision records (ADRs) and weekly devlogs.

How it works

VigilanSee analysis pipelineRaw replay data (CS2 .dem files and match records) goes to a high-frequency parser that reads 128 ticks per second. A neural and algorithmic audit then runs biometric vector analysis of aim and movement, plus physics-based sabotage detection. The output is a forensic verdict: a risk score from 0 to 100 and an evidence-ready report.Raw replay dataCS2 .dem files + match recordsHigh-frequency parser128 ticks per secondNeural and algorithmic auditbiometric vector analysis of aimand movement + physics-basedsabotage detectionForensic verdictrisk score 0–100 + evidence-readyreport
Everything runs on the server side; nothing is installed on the player’s machine.

The idea is to build a behavioural fingerprint for each player that survives team changes, and to detect cheating from behaviour rather than from the cheat binary. A player who aim-locks all game and then empties a magazine into a wall stands out; so does one who pre-aims through walls and skips the corner checks everyone else makes.

The same signals catch griefing, such as deliberately flashing or molotoving teammates, and coordinated trolling.

Dynamic risk-factor attribution

Dynamic risk-factor attributionA suspicion, from player reports or automatic detection, goes to the AI. The AI picks its tools through a light overview analysis, then assigns a risk factor that sets the analysis intensity: nothing, light, medium or heavy. The results feed back to the AI so it improves its choices.Suspicionplayer reports or automaticdetectionAIpicks tools via a lightoverview analysisrisk factorAnalysis intensitynothing · light · medium ·heavyResultsimproves its choices
Heavy analysis only for players who warrant it.

Not every player gets the same scrutiny. A suspicion, from player reports or automatic detection, goes to the AI, which picks its tools through a light overview analysis and assigns a risk factor. That factor sets how hard the analysis looks: nothing, light, medium or heavy. The results feed back to the AI so its choices improve over time.

Results

In progress. The weekly devlogs track where the project stands.

Design

Diagram of dynamic risk-factor attribution: (1) a suspicion from player reports or automatic detection goes to the AI; (2, 3) the AI selects its tools through a light overview analysis; (4) it attributes a risk factor that sets the analysis intensity: nothing, light, medium or heavy; (5) the results feed back to the AI.
Dynamic risk-factor attribution.

Links