Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

De l'Analyse des Paquets

Labo

Aujourd'hui, pour mon premier tuto, je vais vous apprendre à analyser les paquets que vous recevez.

Il y a déjà trois principaux tutoriels traitant de cela et qui m'ont servi de sources : https://cadernis.com/d/436-initiation-à-la-communication-avec-d, https://cadernis.com/d/143-[tuto]-identifier-les-packets et le plus ancien https://cadernis.com/d/115-comprendre-le-protocole-de-d20.

J'ai voulu faire le mien pour expliquer avec plus d'exemples (3 détaillés).

Je suis sous Mac OS et j'utilise wireshark comme sniffeur.

I) Capture des paquets

Tout d'abord, sélectionnez l'interface par laquelle vous vous connectez à Internet (dans mon cas, wifi = en1).

Ensuite, pour filtrer les paquets dofus, il va falloir créer un filtre (capture filter). Dans mon cas, je me connecte au port 5555 donc j'ai mis "tcp port 5555", et ça marche pour les serveurs de connexion et de jeu, donc pas besoin de chercher autre chose.

Vous sélectionnez start capture puis stop quand vous avez assez de paquets.

II) Analyse

Tout d'abord, sachez que wireshark intercepte TOUS les paquets, même les vides propres au protocole TCP qui, contrairement à l'UDP, accuse réception de chaque message, ce qui nous fait un PAQUET de paquets :)joke:).

On ne s'intéresse donc qu'aux paquets dont la taille est supérieure à 66 Bytes (taille d'un paquet sans data).

Ensuite, on regarde les deux premiers octets de la partie "Data" du message.

Ils sont sous la forme XX XX en hexadécimal. Pour débuter, je vous conseille http://sebastienguillon.com/test/javasc ... sseur.html pour vous retrouver dans les bases.

Il y a donc 16 bits dans ces 2 octets, mais quand vous convertissez en binaire, vous en aurez sûrement moins, donc considérez que ce sont des zéros qui manquent à gauche. (c'est pareil en base 10, vous allez écrire 42, et pas 042 ou 0042).

Les 14 premiers représentent l'id du paquet et les 2 derniers la taille de la taille du message.

Voici un joli schéma expliquant cela (merci Sorrow) :

[Image Introuvable] Loading Image

En fait, on va prendre un exemple. Si les deux premiers bytes sont 00:7a, on va convertir en binaire (avec le temps, vous apprendrez sans même vous rendre compte les tables de conversion).

0=0000

7=4+2+1=0111

a=10=8+2=1010

donc on a reçu (0000 0000 0)111 1010.

docn l'id est 111 10 en base 2, (je laisse les espaces exprès) ce qui fait 1 1110 = 2+4+8+16 = 30.

La taille est 10 donc 2 en base 10.

Bien sûr, ça va plus vite avec le convertisseur. Mais si le premier octet est nul, voici deux autres méthodes qui permettent de le faire rapidement de tête :

Cliquez pour révéler Cliquez pour masquer

Vous pouvez convertir directement de l'hexadécimal en décimal :

7a = 16*7 + 10 = 122 (il faut savoir multiplier, ou utiliser le convertisseur que j'ai donné).

On effectue ensuite une division euclidienne par 4. Le diviseur sera l'id et le reste la taille de la taille.

122 = 120 + 2 = 4 * 30 + 2 donc on retrouve les mêmes valeurs.

Enfin, méthode la plus rapide :

On multiplie le premier chiffre hexadécimal par 4 et on ajoute le quotient de la division par 4 du second pour obtenir l'id.

Pour la taille de la taille, on prend le reste de la division par 4 du second chiffre.

a= 10 = 4 * 2 + 2

id = 7*4+2 = 30

taille de la taille = 2.

Mais rassurez-vous, dès le prochain tuto, on va commencer à automatiser le processus et vous n'aurez plus à calculer, seulement à coder :D

Ces astuces vous serviront juste si vous êtes un masochiste qui programme en assembleur :twisted:

Après, on prend l'id, on ouvre les sources (pour les obtenir, décompilez DofusInvoker.swf avec JPEXS par exemple) avec un logiciel comme Sublime Text que m'a conseillé le très bienveillant [clignote]Moonlight-Angel[/clignote], que j'embête souvent par Skype avec mes questions, et à qui je dédicace ce tutoriel, et on recherche avec Maj+Cmd+F (ou Maj+ctrl+F sous Windows je suppose), ou encore TextMate que j'utilise, dans l'ensemble des sources le numéro de l'id.

Comme le même nombre peut apparaître ailleurs, je vous conseille de chercher "protocolId:uint = "+ l'id ; dans notre cas, "protocolId:uint = 30;".

Si vous voyez apparaître plusieurs résultats, ne considérez que le fichier situé dans messages, pas celui dans types. Celui dans types correspond à une structure de données, pas à un message.

Puis, intéressez-vous à la méthode de sérialisation pour un paquet envoyé et à la méthode de désérialisation pour un paquet reçu.

STOP, j'ai trop parlé dans le vide, place aux exemples !

III) Exemples

Exemple 1 : (paquet 30 = ServersListMessage)

paquet reçu

Cliquez pour révéler Cliquez pour masquer

00:7a:02:da:00:34:00:13:03:00:01:00:00:00:00:00:00:00:00:00:00:10:03:00:01:00:00:00:00:00:00:00:00:00:13:89:

03:00:00:00:00:00:00:00:00:00:00:00:00:06:03:00:01:00:00:00:00:00:00:00:00:00:00:19:03:00:01:00:00:00:00:00:00:00:

00:00:0f:a3:03:00:00:00:00:00:00:00:00:00:00:00:00:0c:03:00:01:00:00:00:00:00:00:00:00:00:00:1f:03:00:00:00:00:00:00:

00:00:00:00:00:00:12:03:00:01:00:00:00:00:00:00:00:00:00:00:25:03:00:01:05:42:74:40:b7:01:90:e0:00:00:05:03:00:01:

00:00:00:00:00:00:00:00:00:00:18:03:00:01:00:00:00:00:00:00:00:00:00:0f:a2:03:00:00:00:00:00:00:00:00:00:00:00:00:0b

:03:00:01:00:00:00:00:00:00:00:00:00:00:1e:03:00:01:00:00:00:00:00:00:00:00:00:1b:59:03:00:00:00:00:00:00:00:00:00:

00:00:00:11:03:00:01:00:00:00:00:00:00:00:00:00:00:24:03:00:01:00:00:00:00:00:00:00:00:00:00:04:03:00:01:00:00:00:

00:00:00:00:00:00:00:17:03:00:01:00:00:00:00:00:00:00:00:00:0f:a1:03:00:00:00:00:00:00:00:00:00:00:00:00:0a:03:00:01

:00:00:00:00:00:00:00:00:00:00:1d:03:00:01:00:00:00:00:00:00:00:00:00:0f:a7:03:00:00:00:00:00:00:00:00:00:00:00:03:

e9:03:00:00:00:00:00:00:00:00:00:00:00:00:23:03:00:01:00:00:00:00:00:00:00:00:00:17:72:03:00:00:00:00:00:00:00:00:

00:00:00:00:03:03:00:01:00:00:00:00:00:00:00:00:00:00:16:07:00:00:00:00:00:00:00:00:00:00:00:00:29:03:00:00:00:00:

00:00:00:00:00:00:00:00:09:03:00:01:00:00:00:00:00:00:00:00:00:00:1c:03:00:01:00:00:00:00:00:00:00:00:00:23:29:03:

00:00:00:00:00:00:00:00:00:00:00:0f:a6:03:00:00:00:00:00:00:00:00:00:00:00:00:0f:03:00:01:00:00:00:00:00:00:00:00:00:

17:71:03:00:00:00:00:00:00:00:00:00:00:00:00:02:03:00:00:00:00:00:00:00:00:00:00:00:00:15:03:00:01:00:00:00:00:00:

00:00:00:00:00:28:03:00:00:00:00:00:00:00:00:00:00:00:00:08:03:00:00:00:00:00:00:00:00:00:00:00:00:1b:03:00:01:00:

00:00:00:00:00:00:00:00:0b:b9:03:00:00:00:00:00:00:00:00:00:00:00:0f:a5:03:00:00:00:00:00:00:00:00:00:00:00:00:0e:03

:00:01:00:00:00:00:00:00:00:00:00:00:21:03:00:01:00:00:00:00:00:00:00:00:00:00:01:07:00:00:00:00:00:00:00:00:00:00:

00:00:14:03:00:01:00:00:00:00:00:00:00:00:00:00:07:03:00:01:00:00:00:00:00:00:00:00:00:00:1a:03:00:01:00:00:00:00:

00:00:00:00:00:0f:a4:03:00:00:00:00:00:00:00:00:00:00:00:00:0d:03:00:01:00:00:00:00:00:00:00:00:00:00:20:03:00:01:00

:00:00:00:00:00:00:00:00

00 7a : en-tête = 0b1111010 donc paquet 30 et taille sur 2 octets

02 da : taille du message = 730 octets

Source :

public function deserializeAs_ServersListMessage(param1:IDataInput) : void {
         var _loc4_:GameServerInformations = null;
         var _loc2_:uint = param1.readUnsignedShort();
         var _loc3_:uint = 0;
         while(_loc3_ < _loc2_)
         {
            _loc4_ = new GameServerInformations();
            _loc4_.deserialize(param1);
            this.servers.push(_loc4_);
            _loc3_++;
         }

On voit qu'on peut déjà lire la dimension de la liste de serveurs.

00 34 : unsigned short nombre de serveurs = 52

On doit maintenant connaître comment est codée la classe GameServerInformations.

On remarque dans l'en-tête du fichier "import com.ankamagames.dofus.network.types.connection.GameServerInformations"

On regarde donc la source correspondante, spécialement la méthode de désérialisation.

Source :

public function deserializeAs_GameServerInformations(param1:IDataInput) : void {
         this.id = param1.readUnsignedShort();
         if(this.id < 0 || this.id > 65535)
         {
            throw new Error("Forbidden value (" + this.id + ") on element of GameServerInformations.id.");
         }
         else
         {
            this.status = param1.readByte();
            if(this.status < 0)
            {
               throw new Error("Forbidden value (" + this.status + ") on element of GameServerInformations.status.");
            }
            else
            {
               this.completion = param1.readByte();
               if(this.completion < 0)
               {
                  throw new Error("Forbidden value (" + this.completion + ") on element of GameServerInformations.completion.");
               }
               else
               {
                  this.isSelectable = param1.readBoolean();
                  this.charactersCount = param1.readByte();
                  if(this.charactersCount < 0)
                  {
                     throw new Error("Forbidden value (" + this.charactersCount + ") on element of GameServerInformations.charactersCount.");
                  }
                  else
                  {
                     this.date = param1.readDouble();
                     return;
                  }
               }

00 13 : unsigned short id = 19

03 : byte status = 3

00 : byte completion = 0

01 : boolean isSelectable = 1

00 : byte charactersCount = 0

Après, on voit à quel point les programmeurs d'Ank@m@ se foutent d'utiliser des nombres à virgule en informatique.

00:00:00:00:00:00:00:00 : double date = 0

Donc les données de 1 serveur nous prennent 14 octets. Et 14*52=728 et si on ajoute les 2 octets du nombre de serveurs, ça fait bien 730 octets, soit la taille du message !

Je saute plusieurs serveurs pour arriver au serveur d'id 37 (en hexa 00 25)

00:25:03:00:01:05:42:74:40:b7:01:90:e0:00

Je traduis directement l'hexadécimal en décimal

id = 37

status = 3 on remarque presque tous les serveurs on un status de 3 donc ça doit être l'état disponible

completion = 0 je pense que ça veut dire qu'il n'est pas complet

isSelectable = 1

charactersCount = 5 j'ai bien 5 personnages sur ce serveur

La date est pour la première fois non nulle et vaut 42:74:40:b7:01:90:e0:00 = 1391761299726.0

A cette occasion, j'ai du programmer mon propre convertisseur hexa-binary64. Voici sa source en python 3 :

def hexdbl(ch):
    if ':' in ch: ch=''.join(ch.split(':'))
    if ' ' in ch: ch=''.join(ch.split(' '))
    ch=bin(eval('0x'+ch))[2:]
    ch=(64-len(ch))*'0'+ch
    s=eval('0b'+ch[0])
    e=eval('0b'+ch[1])
    m=1+sum(int(ch[12+i])*2**-(i+1) for i in range(52))
    return (-1)**s*m*2**(e-1023)

Exemple 2 : (paquet 40 = ServerSelectionMessage)

paquet envoyé

00:a1:02:00:25

00 a1 : en-tête = 0b10100001 donc paquet 0b101000 = 40 et taille encodée sur 1 octet

02 : taille du message = 2 octets

Source :

public function serializeAs_ServerSelectionMessage(param1:IDataOutput) : void {
         param1.writeShort(this.serverId);
      }

Message

00 25 : short serverId = 37

Exemple 3 : (paquet 42 = SelectedServerDataMessage)

paquet reçu

00:a9:37:00:25:00:0e:32:31:33:2e:32:34:38:2e:31:32:36:2e:38:35:15:b3:00:00:20:30:61:66:36:62:62:64:31:39:65:32:35:33:36:33:34:63:38:39:62:64:33:63:37:66:61:63:35:62:61:32:32

00 a9 : en-tête 0b10101001 donc paquet 0b101010=42 et taille encodée sur un octet

37 : taille du message = 55 octets

Source :

public function deserializeAs_SelectedServerDataMessage(param1:IDataInput) : void {
         this.serverId = param1.readShort();
         this.address = param1.readUTF();
         this.port = param1.readUnsignedShort();
         if(this.port < 0 || this.port > 65535)
         {
            throw new Error("Forbidden value (" + this.port + ") on element of SelectedServerDataMessage.port.");
         }
         else
         {
            this.canCreateNewCharacter = param1.readBoolean();
            this.ticket = param1.readUTF();
            return;
         }
      }

Message

00 25 : short serverId = 37

00 0e : short taille du reader utf = 14

32 31 33 2e 32 34 38 2e 31 32 36 2e 38 35 : utf address = 213.248.126.85

15 b3 : unsigned short port = 5555

00 : boolean canCreateNewCharacter = false

00 20 : short taille du reader utf = 32

30:61:66:36:62:62:64:31:39:65:32:35:33:36:33:34:63:38:39:62:64:33:63:37:66:61:63:35:62:61:32:32 : utf ticket = 0af6bbd19e253634c89bd3c7fac5ba22

Voilà, j'espère que ce tutoriel vous a plu, en tous cas, j'ai été content de l'écrire :)

Je suis par contre désolé de ne pas avoir pu mettre un image de wireshark, je sais pas comment les intégrer DANS le tutoriel.

EDIT : C'est bon, je crois savoir comment les héberger et les afficher dans le même post.

Si vous avez des questions, des remarques, surtout n'hésitez pas à commenter ou à m'envoyer un MP (enfin, pas trop quand même ;) ) !

Pour des explications complémentaires, se reporter à ce sujet : https://cadernis.com/d/1737 :)

BlueDream

Voila un tutoriel très complet sur les paquets, c'est ce qui manquait sur le forum.

Labo

Merci beaucoup !!!

C'est très gentil de ta part :D

Il n'y a pas plus de contenu que dans les autres, mais juste beaucoup plus d'exemple, et plus détaillés. J'avais promis des tutos de qualité pour devenir rédacteur, et j'espère ne pas manquer trop souvent à mes engagements :) .

Je rajouterai des images d'ici les prochaines vacances, et je publierai à ce moment la suite du tuto.

Je ne sais pas encore si je présenterai le principe du MITM, mon parser, que j'espère avoir commencé et fini d'ici là, et la modification du paquet 42 ou alors si j'attaquerai mon UNIQUE classe et le lecteur-convertisseur automatique de sources, dont je n'ai pas totalement besoin vu que je fais du MITM...

BlueDream

N'expliques pas le mitm, il y a beaucoup de postes qui traitent ce sujet. Il ne faut pas trop macher le travail aux gens et les laisser un peu réfléchir avec ce qu'ils ont.

Labo

Oui, je pense que tu as raison. J'aimerais pas que mes tutos créent une nouvelle vague de bots copier-coller...

Dans ce cas, juste mon parser et le paquet 42.

Labo

Merci Geraff pour la coloration syntaxique !!!

badre2dine

l'un des meilleurs tutos merci beaucoup @Labo :inlove::inlove:

kenny94

Quatre ans après, je ne sais pas si le tuto est toujours d'actualité, mais tant pis, je me lance !

Très bon tuto, bien expliqué. Il me sera surement d'une précieuse aide pour mes débuts.

Néanmoins, une partie du tuto reste très obscure pour moi (ça serait trop facile sinon :p)

Je ne comprends pas comment tu déduit la structure du paquet à partir du code source des différentes fonctions.

Je cherche pourtant des mots clés pour faire le lien, mais là je sèche...

Sans le détail de la structure sous le code source, je suis incapable de comprendre quel octet veut dire quoi...

Merci :)

EDIT :

A force de lire le code source, je crois avoir compris le principe.

A chaque fois que je lis this.param1.readXXXX c'est que je dois lire des octets.

Si c'est readShort, je lis 2 octets, readByte, je lis 1 octet, etc...

Maintenant là où ça se complique c'est avec readUTF, où là je lis d'abord la taille du contenu sur 2 octet, puis le contenu.

J'ai bon ?

kenny94

2e question (dites-moi s'il faut que je poste dans la section Question/Réponse) :

Quand je lis le header du message, les 14 premiers bits sont pour l'ID, et les 2 derniers sont pour la taille de la taille du message.

Alors comment ce fait-il que je sniff des paquets de plusieurs centaines d'octets avec une taille de taille = 0b00 ?

De même, j'ai reçu un paquet de 500 octets avec comme taille de taille 0b01. Mais la taille du message dépasse 256, donc elle doit être codé sur 2 octets, soit 0b10 ?

Je précise que ces paquets ont été sniffé par wireshark avec le filtre tcp port 5555 comme précisé dans le tuto.

Et je n'ai pris en compte que la partie "data" du paquet.

Il paraît que le problème viendrait du fait qu'il puisse y avoir plusieurs paquets dofus dans un paquet TCP et inversement. Et que donc le header du paquet dofus ne se trouve pas toujours dans les deux premiers octets du message ??

Voilà où j'en suis dans mon enquête :teeth:

astro05

kenny94
2e question (dites-moi s'il faut que je poste dans la section Question/Réponse) :
Quand je lis le header du message, les 14 premiers bits sont pour l'ID, et les 2 derniers sont pour la taille de la taille du message.
Alors comment ce fait-il que je sniff des paquets de plusieurs centaines d'octets avec une taille de taille = 0b00 ?
De même, j'ai reçu un paquet de 500 octets avec comme taille de taille 0b01. Mais la taille du message dépasse 256, donc elle doit être codé sur 2 octets, soit 0b10 ?
Je précise que ces paquets ont été sniffé par wireshark avec le filtre tcp port 5555 comme précisé dans le tuto.
Et je n'ai pris en compte que la partie "data" du paquet.
Il paraît que le problème viendrait du fait qu'il puisse y avoir plusieurs paquets dofus dans un paquet TCP et inversement. Et que donc le header du paquet dofus ne se trouve pas toujours dans les deux premiers octets du message ??
Voilà où j'en suis dans mon enquête :teeth:

Voici un exemple d'un paquet HelloConnectMessage :

// ID du paquet et nombre d'octets de la taille du paquet (id = 3, nombre d'octets de la taille = 2)
00 0E
// Taille du paquet (sans l'en-tête) = 341
01 55
// Taille du salt (32 octets) :
00 20
// Salt :
6A 62 77 75 70 69 38 30 40 67 4E 4E 75 4A 3D 3D 22 61 65 79 39 4B 25 76 6A 5E 48 51 48 48 29 42
// Octets a fournir à la fonction readVarInt (305 octets) pour obtenir la taille de la clé.
B1 02
// La clé a décrypter qui fait 305 octets
7B DF 5C B1 33 C8 74 CF 2C 51 8F 4F A0 9B 8C 6B B0 D5 81 55 F5 50 F3 41 42 67 A1 EC 1F 3E 24 CB 03 49 46 E7 85 06 DE E0 C3 C4 7E A8 DE B7 16 19 FA 68 F6 89 30 0F AB 42 2E D0 E3 66 5F D2 C1 42 DB D1 7E 74 6A AD 97 88 E7 07 55 99 0D 21 40 F5 85 A9 C5 BE F7 81 96 4B 64 09 70 9B 4A 64 5D 29 5D 02 24 8F 54 61 9C 3A 91 B4 0D 9A AF A2 E7 1B 05 3A 5C 72 1F F9 83 C0 F8 6F 7F 48 37 5B C2 78 BA D3 E3 D4 1B 10 E9 79 95 E4 1D D8 5C E6 42 47 A8 33 A9 86 AC F0 5E 40 9A 9B 1F D6 5F 4C 62 1D 83 B5 B0 42 30 40 0B DA 2E BA D2 4D 7C 67 AD 72 6B E1 BB BA 73 19 29 9F DA F9 87 14 85 23 4F B1 EC 6B 6A DB 6A B9 C8 4C 93 2D BC EF F9 FC 33 DF 87 58 0A F1 E1 6F 30 84 9C 21 CE F1 38 EF 3A CF 72 B5 86 E8 15 96 17 D7 ED 96 D7 10 69 8E 9A 07 E3 1D 78 B0 E1 16 9F A4 67 37 BD C5 64 94 AB A3 58 AB 6F 90 0A DA 61 86 02 72 61 05 F1 CF 3D 11 E5 23 56 F3 0D 63 14 7C 3D FA C7 7D 93 E5 46 37 FA B3 E8 33 52 DD BD 9D 14 4F B8 66 7C 17 04 A6 BE

(J'ai récupéré le message de ce poste : https://cadernis.com/d/2101-lecture-du-helloconnectmessage)

Pour parser le paquet, tu commence par prendre les deux premier octets qui sont 00 0E (dans cet exemple).

Cela donne en binaire : 1110

Les deux bits les plus à droite sont les bits qui indiquent le nombre d'octets qu'il faut lire pour récupérer la taille du message sans les en-tête.

Le reste des octets constitue l'ID du message.

On a donc 10 (en binaire) qui correspond à 2.

Et 11 (en binaire) qui correspond à 3.

Étant donnée que le nombre d'octet permettant de stocker la taille est de 2, il faut lire les deux prochains octets du message qui correspondront cette fois ci à la taille du message sans les en-tête.

Les deux prochains octets sont : 01 55 (en hexa) ce qui correspond à 341 octets.

Le message a donc l'ID 3 et une taille de 341 octets.

Il est possible d'avoir de très grosse tailles (Le RawDataMessage par exemple), dans ce cas, les messages sont séparé dans plusieurs paquets.

Il est également possible d'avoir plusieurs petits messages dans un même paquet comme tu l'as précisé.

Pour en déduire la structure du paquet, il faut juste lire ce que font les méthode de désérialisation dans les sources D2.

C'est simplement des méthodes qui lisent un certains nombre d'octets pour remplir certaines variables ...

Que n'as tu pas compris dans ce fonctionnement ?

kenny94

@astro05

Tout est parfaitement clair dans ton explication.

Tu donnes la réponse à ma question ici :

astro05
[...]
Il est possible d'avoir de très grosse tailles (Le RawDataMessage par exemple), dans ce cas, les messages sont séparé dans plusieurs paquets.
Il est également possible d'avoir plusieurs petits messages dans un même paquet comme tu l'as précisé.
[...]

Je pensais qu'en sniffant les paquets avec wireshark, j'obtiendrais un paquet dofus par paquet TCP. Mais en fait non :/ Parfois un paquet dofus chevauche deux paquets TCP, et parfois il y a plusieurs paquets dofus dans un paquet TCP quand le paquet dofus est très court comme tu dis.

Ce qui veut dire que je n'étais sûrement pas en train de lire un hi-header quand les deux derniers bits étaient nuls (taille de la taille) alors que le message contient bel et bien des octets. A ce moment là, je devais lire la suite d'un paquet dofus qui avait commencé dans le paquet TCP précédent ?

Est-ce correct ?

astro05

kenny94
@astro05
Tout est parfaitement clair dans ton explication.
Tu donnes la réponse à ma question ici :
Je pensais qu'en sniffant les paquets avec wireshark, j'obtiendrais un paquet dofus par paquet TCP. Mais en fait non :/ Parfois un paquet dofus chevauche deux paquets TCP, et parfois il y a plusieurs paquets dofus dans un paquet TCP quand le paquet dofus est très court comme tu dis.
Ce qui veut dire que je n'étais sûrement pas en train de lire un hi-header quand les deux derniers bits étaient nuls (taille de la taille) alors que le message contient bel et bien des octets. A ce moment là, je devais lire la suite d'un paquet dofus qui avait commencé dans le paquet TCP précédent ?
Est-ce correct ?

C'est effectivement possible que ton erreur se situe la. ;)

Pour en être sûr, il m'aurait fallu tes paquets.

Labo

Attention, il y a eu un changement dans le protocole par rapport à mon tuto.

Maintenant, dans les paquets du client, leur numéro est ajouté après le header.

Voilà mon implémentation de la lecture des paquets en Python : https://github.com/louisabraham/LaBot/blob/master/labot/data/msg.py#L31

9True

Pourrions-nous avoir plus d'information sur les changements au niveau du protocole ? Je suis sous C#, et pas si familiariser à Python.

BlueDream

Il n'y eu aucun changement du protocole depuis, peut-être une variable en plus, l'instance_id. Fais une recherche sur le fofo.

Sinon il y a pas mal de sources en C#.

Cedex

Merci beaucoup !