OneRP — Zéro endpoint REST et 9 couches de sécurité anti-décompilation

Le contexte : FiveM, un écosystème hostile

Développer pour FiveM c'est développer dans un environnement où tout le monde peut décompiler votre code. Les DLL C# se décompilent en quelques secondes avec ILSpy ou dnSpy. Les joueurs le font. Les concurrents aussi. Comment protéger un logiciel commercial dans ces conditions ?

OneRP est le successeur de SARP/V-Multi — mais avec 9 ans d'expérience en plus. L'architecture a été repensée de A à Z pour résoudre ce problème fondamental.

Zéro endpoint REST

La première décision radicale : éliminer les API REST.

Sur un serveur GTA RP classique, l'architecture type :

1. Le client veut afficher le solde bancaire
2. Il envoie GET /api/bank/balance
3. Le serveur répond avec le JSON
4. Un autre joueur transfère de l'argent → le solde affiché est faux

Avec ActualLab Fusion, les données se synchronisent automatiquement :

[ComputeMethod]
public virtual async Task<decimal> GetBalance(int accountId)
{
    var account = await db.Accounts.FindAsync(accountId);
    return account?.Balance ?? 0;
}

Quand le solde change, tous les clients abonnés sont notifiés en temps réel. Pas de polling. Pas de WebSocket custom. Le framework détecte les dépendances entre méthodes et propage les invalidations automatiquement.

Résultat : 51 ComputeServices Fusion, zéro endpoint REST, 2 048 connexions lock-free en sub-milliseconde. La synchronisation est invisible du code applicatif.

Les 9 couches de sécurité

Dans un monde où le DLL est décompilé dès la première mise à jour, la sécurité ne peut pas reposer sur l'obscurcissement. La stratégie : la défense en profondeur.

Couches 1–3 : Authentification et session

• Signature de session : token cryptographique lié à l'IP, hardware ID et timestamp
• Challenge-response : le serveur envoie des défis que seul le vrai client résout
• Heartbeat versionné : battement de cœur régulier vérifiant l'intégrité du client

Couches 4–6 : Intégrité du code

• Hash de DLL : vérification des assemblies chargées par le client
• Rotation de clés : les clés de chiffrement changent à chaque reboot — un DLL décompilé hier ne fonctionne plus aujourd'hui
• Vérification d'état : comparaison état déclaré vs état calculé côté serveur

Couches 7–9 : Réponse graduée

• Détection statistique : accumulation d'un score de suspicion plutôt que bannissement immédiat
• Dégradation progressive : 4 niveaux de punition probabiliste — le tricheur ne sait jamais si c'est un bug ou une détection
• Audit trail : chaque action suspecte est loguée pour analyse manuelle

Architecture multi-tenant

OneRP est un SaaS : plusieurs serveurs de jeu partagent la même infrastructure. L'isolation garantit qu'un serveur ne peut physiquement jamais accéder aux données d'un autre :

// Chaque requête EF Core est filtrée automatiquement
modelBuilder.Entity<Vehicle>()
    .HasQueryFilter(v => v.TenantId == _currentTenant.Id);

Même avec du code buggy ou compromis, les données ne fuient jamais entre tenants.

39 interfaces React in-game

HUD, inventaire, banque, téléphone, tablette, crafting, administration, éditeur de monde... Chaque interface est du React 19 rendu via un navigateur embarqué dans le client FiveM. Toutes connectées au serveur via le même pipeline Fusion temps réel — pas de requêtes HTTP, pas de polling.

Le stack complet : .NET 9/10, EF Core, MySQL, React 19, Vite 7, Tailwind CSS 4, MessagePack pour la sérialisation, JWT pour l'authentification.

Ce que j'en retiens

1. Le temps réel simplifie le code. Supprimer les API REST a réduit la complexité. Plus de gestion de cache, plus de synchronisation manuelle, plus de bugs de données périmées.

2. La sécurité est un spectre, pas un mur. 9 couches parce qu'aucune n'est imperméable seule. La combinaison rend l'attaque exponentiellement plus coûteuse.

3. L'architecture Fusion est réutilisable. Le même pattern se retrouve maintenant dans SaleCast et PromptVault. L'investissement initial se rentabilise sur chaque nouveau projet.