From 6b3a4057beea62cfc98e1cb65b274f5364352f87 Mon Sep 17 00:00:00 2001 From: neckfire Date: Fri, 17 Jul 2026 00:17:07 +0200 Subject: [PATCH] =?UTF-8?q?docs(netcode):=20VERDICT=20=E2=80=94=20le=20cli?= =?UTF-8?q?ent=20n'entame=20jamais=20son=20handshake=20DTLS=20(r=C3=A9solu?= =?UTF-8?q?tion=20de=20cl=C3=A9=20c=C3=B4t=C3=A9=20client),=20mur=20dur=20?= =?UTF-8?q?ind=C3=A9pendant=20du=20serveur?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- NETCODE-RND.md | 29 ++++++++++++++++++++++++++--- 1 file changed, 26 insertions(+), 3 deletions(-) diff --git a/NETCODE-RND.md b/NETCODE-RND.md index 41c65c5..4cf5bf5 100644 --- a/NETCODE-RND.md +++ b/NETCODE-RND.md @@ -191,6 +191,29 @@ de clé côté client** (le vrai client shipping attend peut-être la clé de SO 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é en cours** : `EncryptionAck` seul (clair, sans payload) + DTLS **accept** (attente) + -**PAS de Challenge** → observer si le client envoie enfin un ClientHello `16 fe fd`. Si oui → progrès ; -si non → mur « résolution de clé côté 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.