the-cycle/NETCODE-RND.md

The Cycle: Frontier — serveur dédié gameplay (R&D netcode)

Branche game-server. Objectif : un serveur de jeu autoritatif écrit from scratch (Prospect.Unreal, réimplémentation C# du netcode Unreal) pour du vrai co-op, sans passer par un client-hôte P2P. Statut : bloqué au chiffrement (voir plus bas).

Client cible : UE4 build R3.5.0 (4.27.2 netcode), Steam depot 868271.

Ce qui fonctionne (murs franchis)

La connexion d'un vrai client va jusqu'à l'entrée du login :

Handshake stateless UDP (cookie/challenge)        ✅
Reconstruction du paquet (PacketHandler)          ✅
Séquençage des paquets (adopt des seq client)     ✅
Alignement des bunches                             ✅  ← percée
Canal de contrôle ouvert                           ✅
NMT_Hello reçu et parsé                            ✅
Transition login Hello → Login                     ✅
Chiffrement DTLS-PSK                               ❌  ← mur final

Percée : le bit de header spécifique R3.5.0

Le client écrit un bit de plus entre l'historique d'ack du FNetPacketNotify et le payload packet-info, que l'UE 4.27 stock (EngineNetVer 16) n'a pas. Décodage bit-à-bit d'un vrai paquet : l'en-tête fait 65 bits, pas 64. En consommant ce bit (bCycleExtraHeaderBit dans UNetConnection.ReceivedPacket), tout se réaligne : bHasPacketInfoPayload, l'horloge jitter (10 bits) et bHasServerFrameTime tombent juste, et le premier bunch du canal de contrôle parse proprement (ChIndex 0, bOpen, bReliable = NMT_Hello). Sans ce fix, le ChIndex sortait en vrac (~1 049 000) et le serveur droppait/plantait.

Le mur final : chiffrement DTLS-PSK

Le client exige le chiffrement. Établi par reverse-engineering :

• NMT_Hello porte EncryptionToken = le PlayFab user_id du joueur (ex. 92EBCFE8C3EAF3AC). Vu dans l'URL de connexion du client : ...?EntityToken=<JWT>?EncryptionToken=92EBCFE8C3EAF3AC.
• Pile PacketHandler du client (ses propres logs) : [DTLSHandlerComponent, StatelessConnectHandlerComponent].
• Le exe embarque les suites ECDHE-PSK-AES256-*, DHE-PSK-AES256-GCM-SHA384, la cvar DTLS.PreSharedKeys, et DTLSPSKClientCallback / DTLSPSKServerCallback → DTLS en mode PSK (clé pré-partagée 32 octets, identité = user_id).
• Compression : OodleNetwork compilé, mais aucun dictionnaire .udic → pass-through (les paquets ne sont ni compressés ni chiffrés au niveau paquet ; entropie faible + longues suites de zéros le confirment).

Proposer un challenge en clair (sans NMT_EncryptionAck) ne marche pas : le client ferme le canal de contrôle juste après.

Pour finir il faudrait : (1) un serveur DTLS-PSK collé au framing du DTLSHandlerComponent d'UE, et (2) la PSK de 32 octets dérivée par le client à partir du user_id/EntityToken.

Pourquoi la clé est inaccessible (statique)

L'exe Prospect-Win64-Shipping.exe est packé/chiffré (protection anti-triche, BattlEye) :

• Entropie de .text = 8.000 (maximum = aléatoire/chiffré ; du code normal ≈ 6.3).
• .rdata = 4.96 (normal → les strings restent lisibles, d'où les découvertes ci-dessus).
• Un scan brut du .text (76 Mo) ne trouve que ~76 instructions → niveau du bruit : ce n'est pas du code sur disque, c'est du chiffré déchiffré au runtime.

Conséquence : Ghidra / radare2 n'analysent que du ciphertext ; aucune référence aux fonctions de chiffrement n'est trouvable statiquement. La dérivation de la PSK vit dans ce code chiffré.

Seule voie restante (non tentée) : dump mémoire au runtime. Le jeu tourne sous Proton/Linux (BattlEye n'a pas de driver kernel sous Linux) → un autre process Linux peut lire /proc/<pid>/mem et récupérer le .text déchiffré, puis l'analyser dans Ghidra pour retrouver la dérivation. Zone grise ToS, plusieurs étapes.

Fichiers clés

• src/Prospect.Server.Game/Program.cs — hôte du serveur de jeu (map Station, GameSession).
• src/Prospect.Unreal/Net/UNetConnection.cs — ReceivedPacket : fix du bit de header (bCycleExtraHeaderBit), adopt des séquences client, drop gracieux des bunches.
• src/Prospect.Unreal/Runtime/UWorld.cs — NotifyControlMessage : Hello/Login ; le else du bloc NMT.Hello documente le mur DTLS-PSK.

Verdict

On a amené un serveur dédié gameplay The Cycle plus loin qu'aucun projet public connu (le projet communautaire deiteris/Prospect n'émule que les services en ligne, pas le netcode de jeu). Le mur restant — DTLS-PSK dont la clé est derrière un packer anti-triche — est un chantier crypto + RE dynamique d'un autre ordre de grandeur.

MAJ (2026-07-16) — mur DTLS franchi (côté serveur)

• PSK récupérée : la clé 32 octets a été obtenue au runtime (dump du .text déchiffré du client via /proc/<pid>/mem sous Proton — BattlEye n'a pas de driver kernel sous Linux). Stockée dans Vault (secret/the-cycle, clé GAMESERVER_DTLS_PSKS, format user_id:hex32), jamais dans le repo.
• Serveur DTLS-PSK implémenté (BouncyCastle) :
  • DtlsPskStore (env PROSPECT_DTLS_PSKS), DtlsPacketTransport (pont bloquant→paquet), ProspectPskTlsServer (DTLS 1.2, identité=user_id), DTLSHandlerComponent (pipeline).
  • UWorld sur NMT_Hello chiffré : PSK connue → NMT_EncryptionAck + handshake.
  • Compile (0 erreur). Non validé en live.
• Reste (itération live obligatoire, invalidable hors client) :
  1. ordre exact du pipeline [DTLS, Stateless] et routage des records de handshake (émis via LowLevelSend — doivent porter le framing stateless attendu) ;
  2. framing DTLS-sur-PacketHandler d'UE (record layer, cookie DTLS éventuel) ;
  3. bascule handshake→données applicatives. Méthode : lancer Prospect.Server.Game avec la PSK, diriger le client dessus, itérer sur les logs serveur.

MAJ (2026-07-16, soir) — test LIVE contre le vrai client (preprod multi)

Setup : preprod multi (the-cycle-api-rd2, GAMESERVER_ADDRESS=192.168.1.136:7777) → le client voyage vers the-cycle-game (branche game-server, PSK via PROSPECT_DTLS_PSKS). user_id preprod = prod = 92EBCFE8C3EAF3AC (même DB ? non, ProspectDb_rd, mais même Id).

Observé (séquence réelle) :

1. Handshake stateless : ✅ complet (challenge/cookie/ack, connexion acceptée).
2. NMT_Hello reçu EN CLAIR avec EncryptionToken=92EBCFE8C3EAF3AC → PSK reconnue.
3. On envoie NMT_EncryptionAck + NMT_Challenge. Le client NE ferme plus tout de suite (progrès vs l'état documenté « ferme après challenge sans ack »).
4. Le client n'envoie JAMAIS de ClientHello DTLS (16 fe fd). Aucun record DTLS.
5. Le paquet suivant du client (~18 o, ex. 80E82AC4…5F00000C) parse en clair comme un bunch bClose=true sur le canal de contrôle (ChIndex 0) → le client FERME.

Interprétation : après NMT_EncryptionAck, le client attend que les paquets serveur suivants soient chiffrés ; on lui renvoie le Challenge en clair → il abandonne. Donc l'EncryptionAck seul ne suffit pas : il faut réellement chiffrer la voie serveur après l'ack (le mur crypto de fond, inchangé). Activer notre composant DTLS ne sert à rien tant que le client ne fait pas de handshake DTLS de son côté — piste à creuser : est-ce de l'AES-GCM keyé par la PSK (SetEncryptionData/EnableEncryption d'UE) plutôt que du DTLS-handshake ?

Bug serveur concret trouvé : UChannel.ConditionalCleanUp (Prospect.Unreal, ~l.822) = throw new NotImplementedException() → crash du tick dès qu'un canal se ferme (bClose). À implémenter (indépendant du crypto).

Acquis réutilisables : on passe le handshake + le Hello + l'EncryptionAck est accepté ; la PSK par user_id est branchée bout-en-bout (Vault → env → serveur). Le blocage net = chiffrement de la voie serveur post-ack.

MAJ (2026-07-16, nuit) — tentative AES-256-GCM keyé par la PSK

Implémenté AesGcmHandlerComponent (System.Security.Cryptography.AesGcm, format [IV 12o][ciphertext][tag 16o]), activé après l'EncryptionAck (ack en clair → activation → Challenge chiffré). Corrigé aussi l'ordre du pipeline : Incoming doit itérer en sens INVERSE d'Outgoing (PacketHandler.Incoming_Internal) — sinon, avec 2 composants actifs (stateless + AES), le stateless tente de parser des octets chiffrés. (Les deux étaient en avant ; n'avait jamais compté car un seul composant actif jusqu'ici.)

Observé (test live) : notre Challenge part bien chiffré ([AES] Outgoing 30o→58o), mais le client répond toujours par un paquet plaintext de ~18 o de structure constante (…41 00 XX FF 5F 00 00 0C) = un bClose du canal de contrôle, jamais rien qui ressemble à de l'AES (haute entropie ≥28o). Le client ne chiffre jamais son côté.

Conclusion : quelle que soit notre réponse au Hello (challenge clair, chiffré AES, ou tentative DTLS), le client ferme systématiquement le canal de contrôle en clair juste après. L'AES-GCM tel qu'implémenté ne le fait pas basculer en chiffré. Pistes restantes (deep RE, non tranchées) : (a) framing AES-GCM exact d'UE (schéma d'IV/nonce, AAD, position) ≠ notre IV aléatoire préfixé ; (b) c'est bien du DTLS-handshake et le client attend un ServerHello DTLS ; (c) notre réponse au Hello est incomplète (ordre/contenu des NMT) indépendamment du chiffrement. Chaque test = ~4 min (CI + redeploy). Bugs serveur secondaires à corriger : ConditionalCleanUp (stub) + ArgumentOutOfRangeException quand on vide un paquet trop court.

Décision : checkpoint. Tout est commité/documenté. La suite = RE netcode profonde multi-session ; et même résolue, ce n'est que le login — la simulation gameplay reste hors de portée réaliste.

Flux de chiffrement DTLS d'UE 4.27 (recherche, 2026-07-17)

Sources : KB Epic « Enable Encryption via Packet Handler Components », doc API (EnableEncryptionServer/SetEncryptionData/FEncryptionData), UE-95508 (ack chiffré si renvoyé), UE-171638 (module DTLS exige OpenSSL), logs DTLS/PSK réels (Satisfactory #453). Le source du plugin DTLS est gated (points reconstruits signalés).

Corrections clés :

• Le CLIENT envoie le ClientHello ; le serveur ATTEND (accept), ne parle jamais en premier. Donc l'AES-GCM autonome = impasse (c'est bien du DTLS, records 16 fe fd standard OpenSSL).
• NMT_EncryptionAck ne porte AUCUNE clé. À sa réception, le client appelle ReceivedNetworkEncryptionAck → résout lui-même sa FEncryptionData (Key + Identifier) → appelle EnableEncryption côté client → c'est CE qui déclenche son ClientHello.
• Séquence serveur : SetEncryptionData(Key,Identifier) → NMT_EncryptionAck en clair, sans payload → puis EnableEncryption (mode accept). Ne jamais chiffrer l'ack.
• Le NMT_Challenge doit être DIFFÉRÉ : le handler DTLS met les bunches applicatifs en file jusqu'à Handshaking completed. (Notre impl l'envoyait tout de suite → à corriger.)
• PSK : PSK = FEncryptionData.Key, identité PSK = FEncryptionData.Identifier ; ressortie via DTLSPSKServerCallback (hook OpenSSL) quand le ClientHello arrive. Le serveur n'envoie jamais la clé.
• Couches : DTLS sous le stateless (entrée : retirer stateless puis déchiffrer DTLS ; Outgoing forward / Incoming reverse).

Si le client ferme SANS ClientHello (notre cas) → cause la plus probable = échec de résolution de clé côté client (le vrai client shipping attend peut-être la clé de SON backend/matchmaking, non émulé — ou dérivation/Identifier différents), pas notre framing DTLS. C'est potentiellement un mur dur (dépend du backend réel du client).

Test informé RÉALISÉ (2026-07-17) : EncryptionAck seul (clair, sans payload) + DTLS accept + PAS de Challenge. Résultat : le client n'envoie TOUJOURS pas de ClientHello (zéro 16 fe fd dans les datagrammes bruts) et ferme avec le bClose plaintext habituel.

VERDICT (mur confirmé) — résolution de clé CÔTÉ CLIENT

Le blocage n'est pas notre framing serveur (DTLS ou AES) : le client n'entame jamais son handshake DTLS. Séquence définitive observée, quel que soit ce qu'on renvoie : stateless OK → NMT_Hello (clair) → notre NMT_EncryptionAck → client ferme (bClose), pas de ClientHello.

D'après la recherche du flux UE : le ClientHello n'est émis que si le client, dans ReceivedNetworkEncryptionAck, résout une FEncryptionData valide et appelle EnableEncryption côté client. Ici il ne le fait pas → il ferme. On ne peut pas forcer ça depuis le serveur.

Cause la plus probable : le vrai client shipping attend sa clé/identité de SON backend (réponse matchmaking/PlayFab), non émulée — ou une dérivation/Identifier qu'on ne fournit pas au bon endroit. La PSK a été récupérée (dump mémoire) mais ça ne suffit pas : c'est la décision client d'activer le chiffrement qui manque, et sa logique vit dans le binaire packé.

Pour aller plus loin il faudrait : RE de la fonction ReceivedNetworkEncryptionAck/résolution de clé du client (dans le .text déchiffré, même méthode que pour la PSK) pour savoir d'où il attend sa clé, puis la lui fournir (probablement côté backend rd2). Chantier RE profond, incertain.

Statut : mur dur, checkpoint. Acquis solides et réutilisables : handshake + Hello + EncryptionAck ; serveur DTLS-PSK ET AES-GCM implémentés ; ordre pipeline corrigé (Incoming inverse d'Outgoing) ; flux UE documenté. Le verrou restant dépend du client, pas du serveur.