Bonjour à tous,Je ne vais pas souvent sur ce forum mais je devrais :pC'est surement le seul forum publique où il y a des vrais programmeurs, qui ont de l'ambition et qui ont envie d'apprendre.C'est pourquoi j'ai décidé de poster ici mon tutoriel sur le protocole de dofus 2.0 qui explique en détails comment l'exploiter, tutoriel qui n'était jusqu'a maintenant que sur mon forum privé.J'espère que ça vous aidera et donnera envie d'exploiter dofus 2.0 ;)Bonjour à tous,Je vais vous présenter le protocole de dofus en détail pour pouvoir correctement l'exploiter. Un sujet du même genre a déjà été fait par **Lorrio **mais c'est plus un complément et de plus il est pour pimper :pPour ceux qui ont déjà connu le protocole **1.29** je vais vous expliquer les nuances entre les 2.Ce qu'il faut savoir tout d'abords est que le protocole de **Dofus 1.29** a été fait comme de la me***. Complètement fait à l'arrache. Donc forcément le protocole de Dofus 2.0 est bien plus **rapide**. (Je ferais une comparaison après)Le 1er protocole est basé sur des **chaînes de caractères**. C'est à dire que pour envoyer un paquet avec comme info _"Bonjour"_ et le nombre **123 **il va écrire quelque chose de ce genre_ "Bonjour|123"_ (j'ai omis le **header**). Décortiquons un peu :Il faut savoir qu’une chaîne de caractères c'est un **tableau d’octets** (bytes). Chaque octet correspond à un **caractère**. Exemple le caractère **A **correspond à **65 **(B à 66, etc.).Donc pour écrire la chaîne _"123"_ on aura dans le buffer (tampon) 3 octets : **49 50 51** (ou en hexa 0x31 0x32 0x33). Notez que je sépare chaque octet par un espace.Donc pour écrire _"Bonjour|123"_ on aura dans notre paquet **11** octets : **66 78 78 74 79 85 82 124 49 50 51**Comparons avec le protocole de **Dofus 2**Celui-ci n'est plus basé sur des chaînes de caractères et est nettement plus efficace. **Il n'est pas crypté non plus attention **! (chose que je vois souvent).Ce qu'il faut comprendre c'est qu’au lieu de transcrire chaque caractère en octet (1 caractère par octet) il les encode selon la technique de **stockage native**._Qu'est ce que ça veut dire _?Et bien un exemple permettra de comprendre. Un nombre courant est un **int **(**integer**), il est encodé sur** 4 octets**. Je ne vais pas vous expliquer en détail comment c'est encodé, mais voici quelques exemplesUn integer de valeur **1 **sera encodé de cette manière : **0 0 0 1** (**4 octets dans tous les cas**), **256 **de cette manière : **0 0 1 0**, et **255** de celle-ci** 0 0 0 255**. Le nombre maximum est donc **4 294 967 295** (en hex 0xFFFFFFFF) soit **255 255 255 255**.Et donc dofus va envoyer l'integer **directement **sous forme d'octets. De cette manière au lieu d'envoyer **49 50 51** pour envoyer 123 il enverra **0 0 0 123**.Ici ce n'est pas avantageux niveau taille naturellement, mais pour envoyer par exemple 4 294 967 295 au lieu d'envoyer **10 octets** (10 caractères) il en enverra que **4 **(255 255 255 255). Ce qui est déjà nettement avantageux.Bien sûr l'avantage majeur est dans la conversion, convertir _"123"_ (chaîne de caractères) en integer est beaucoup plus **long** que de dire que les 4 octets correspondent à un integer (juste à **copier** dans la mémoire).L'autre avantage est qu'il n'y a plus besoin de **séparateur **tel que "|" vu qu’il sait qu'un integer est sur 4 octets, il lira juste 4 octets. (Je reviendrai sur ce point après)Maintenant que vous avez compris le système, vous aurez besoin de comprendre comment est formée une **chaîne de caractères** avec le **nouveau protocole **. Car s’il n'y a plus de délimiteur et qu’une chaîne de caractères peut naturellement être sur un nombre **inconnue** d'octets. Il faut donc le mentionner avant.C'est pourquoi avant toute chaîne de caractères la taille de celle-ci est encodée en temps que **short **(sur **2 **octets)_"Abc"_ sera encodé de la manière suivante : **00 03 (taille) 65 66 67 (chaîne)**Notre paquet de départ _"Bonjour|123"_ sera donc encodé de cette manière au final : **00 07 66 78 78 74 79 85 82 00 00 00 123**Vous remarquerez qu'il n'y a **pas de délimiteur **, le programme sait que juste après la chaîne il y a un integer, inutile de séparer. **Il n'y a plus de split !**En **code **ça donne quoi ?Et bien on utilise (sous .net) les classes **BinaryWriter **et **BinaryReader **(en faite non, mais j'expliquerai après) pour écrire le paquet. C'est ces classes qui se chargent d'écrire/lire les octets (comme quoi c'est plus facile hein ;))Par exemple``` var buffer = new byte[128]; // attention je mets 128 en taille, mais il ne faut SURTOUT pas faire comme ça, il faut un buffer dynamique pour éviter de prendre de la mémoire inutilement var writer = new BinaryWriter(new MemoryStream(buffer)); // il va écrire dans le flux de mémoire qui va écrire dans le buffer writer.Write("Bonjour"); writer.Write(123); /*...*/ var reader = new BinaryReader(new MemoryStream(buffer)); // cette fois-ci le flux lit le buffer seulement string bonjour = reader.ReadString(); int nombre = reader.ReadInt32(); // bonjour contient "bonjour" et nombre contient 123 ```Voilà vous avez tout compris sur l'encodage.Désormais je vais vous faire remarquer une petite nuance qui est toujours source de bugs au début. Il y a 2 manières de stocker un nombre en mémoire. En vérité il y a **2 sens**. Sois remplir de **gauche à droite** soit de **droite à gauche**. Exemple **0 0 0 1** ou **1 0 0 0**, c'est 2 fois le nombre 1, mais si on lit dans le mauvais sens on aura pas **1 **mais **268 435 456**Ce sens on l'appelle **l'endianness **(de l'anglais). Il peut être petit (**Little**) ou grand (**Big**). Le grand endian place le plus grand nombre en tête c'est-à-dire à droite, l'inverse pour le petit**Big **: 00 00 00 01**Little **: 01 00 00 00Problème Dofus 2.0 utilise un grand endian alors qu’en .net tous les lecteurs binaires sont en petit endian (BinaryReader/Writer en autres). De base il n'y en a pas qui supporte les 2 modes.Résultat nous devons impérativement exporter une librairie tierce pour pouvoir lire/écrire en **Big Endian**. Je n'ai pas de conseil spécial à ce sujet, à vous de trouver la bonne ;)Attaquons maintenant la structure concrète d'un paquet dofus 2.0 :**[HEADER:[HI-HEADER:2 bytes (PacketId 6 bits + LengthType 2 bits)][LENGTH:LengthType (1/2/3) bytes]][MESSAGE:LENGTH bytes]**Le header donne des infos sur le paquet : - l'**id du paquet** (qui permet de déterminer de quel paquet il s'agit) - sur combien d'octets la taille est encodée (le **type de taille**) - sa **taille **(la taille du contenu, header exclu)L'id du paquet et l'information sur le nombre d'octets sur lesquels la taille est encodée, sont encodés sur **2 octets confondus**. Je les ai nommés Hi-Header (pour header de tête)C'est-à-dire que l'id est en vérité encodée sur **8+6 bits** (1 octet + 3 quarts) et le type de taille sur **2 bits** (il peut donc contenir le nombre 0, 1, 2 ou 3)Cela permet sans doute de raccourcir un peu la taille du header.Il faut donc lire un **short **(2 octets) et séparer les 2 premiers bits du nombre. Pour cela nous faisons un** décalage de 2 bits vers la droite** (noté >>) (ce qui supprime les bits) pour obtenir l'id du paquet, et appliqué un "**mask**" (masque --") en utilisant l'opérateur **AND **sur **les 2 premiers bits** pour avoir 2 bits seulement.En détail voici la démarcheJ'ai un paquet d'id **2** (en binaire **10**) et avec un type de taille **1 **(**01**) égalementJe vais avoir donc (en bits) **0000 0000 0000 1001**Ce qui correspond au chiffre 5 (mais on s'en fiche)En appliquant l'opérateur >> 2 on obtiendra **0000 0000 0000 0010** -> soit 2 (notre id)En appliquant l'opérateur & (AND) avec le chiffre 3 ( soit & 3) on obtiendra **0000 0000 0000 0001**En faite **3 **correspond à **0111**, l'opérateur AND garde que les bits lorsqu’ils valent tous les deux 1 et non 0.Exemple **2 & 3 0010 & 0011 => 0010** (soit 2)Ou plus utile **7 & 3 1110 & 0011 => 0010** (soit 2)Donc AND permet de **tronquer **en quelque sorte le nombre et ignorer des bits.En **code **nous aurons ça``` short hiheader = reader.ReadInt16(); short packetId = hiheader >> 2; short lenType = hiheader & 3; ```Maintenant la **taille**. La taille est **encodée sur 1, 2 ou 3 octets (s)** suivant la taille du paquet (un paquet de plus de 255 octets aura une taille sur 2 octets minimum). C'est "_lenType_" qui informe, combien d'octets on doit lire.Si lenType vaut **1 **on lit un seul octet (ReadByte())Si lenType vaut **2 **on lit 2 octets (ReadInt16())Si lenType vaut **3 **on lit 3 octets, et c'est là que ça se complique. La technique est de en faites faire un integer (donc 4 octets) et de remplir que 3 octets de ce integer. Je ne vais pas m'enfoncer là dedans voici le code``` switch (lenType) { case 0: { length = 0; } case 1: { length = m_buffer.ReadByte(); } case 2: { length = m_buffer.ReadUShort(); } case 3: { length = (uint)(((m_buffer.ReadByte() & 255)

**Re: Comprendre le protocole de Dofus 2.0**Merci Bouh2, un retour aux sources ne peut pas faire de mal ;)Un petit détail m'intrigue, car j'ai retrouvé cette lourdeur un peu partout (de qui l'oeuf ou la poule...). Dans :``` length = (uint)(((m_buffer.ReadByte() & 255)

**Re: Comprendre le protocole de Dofus 2.0**Je suis entrain de lire et écoute je vais adorer je le sens merci beaucoup ! De nous faire partager ton savoir et ton temps !

**Re: Comprendre le protocole de Dofus 2.0**Merci beaucoup !! n'ayant pas fait de socket sur D2.0 je n'ai pas tout tout compris, à toi de me dire si c'est normal ^^.

**Re: Comprendre le protocole de Dofus 2.0**> FastFrench a dit : "Merci Bouh2, un retour aux sources ne peut pas faire de mal ;)Un petit détail m'intrigue, car j'ai retrouvé cette lourdeur un peu partout (de qui l'oeuf ou la poule...). Dans :``` length = (uint)(((m_buffer.ReadByte() & 255)

**Re: Comprendre le protocole de Dofus 2.0**Si juste tu pouvait enlever le mot D. :) Pour le référencement

**Re: Comprendre le protocole de Dofus 2.0**> Osefdetonsite a dit : "Si juste tu pouvait enlever le mot D. :) Pour le référencement"Deuxieme fois que l'on te fais la remarque, que le forum auto-censure le nom du jeu en question

**Re: Comprendre le protocole de Dofus 2.0**Ah ben on est rendu avec de la grande posture sur cardenis! Good good good :)Bon tuto en passant, tu m'aurais sauver des heures de travail si j'avais eu ca avant!Pour les autres, lisez bien ce tuto, c'est vraiment une excellente base pour commencer.

J'ai rectifié mon message, c'est sur 2.0 que je n'ai pas prog.Pour l'auto-censure elle va revenir donc laissez comme ça pour l'instant.J'ai commencé à etre paumé à partir de la.Notre paquet de départ "Bonjour|123" sera donc encodé de cette manière au final : 00 07 66 78 78 74 79 85 82 00 00 00 123Je n'y comprend pas grand chose, et en plus je ne comprends pas pourquoi ya 2 fois 78 sachant qu'il n'y a aucun caractère en double cote à cote.Puis c'est quoi les 00 00 00 avant 123 et puis pourquoi 123 n'est en packet de 2 octets? Et puis comment on fait les bébés?

> Geraff a dit : "Notre paquet de départ "Bonjour|123" sera donc encodé de cette manière au final : 00 07 66 78 78 74 79 85 82 00 00 00 123Je n'y comprend pas grand chose, et en plus je ne comprends pas pourquoi ya 2 fois 78 sachant qu'il n'y a aucun caractère en double cote à cote."Tu as remarqué les 3 bouteilles à côté du PC de bouh2 ? Et bien elles sont vides, l'explication doit être là je pense...00 07 correspond à la longueur de la chaîne. Les 7 caractères suivants sont les codes Ascii (UTF8 en fait, mais là c'est pareil) des caractères de la chaîne. > Geraff a dit : "Puis c'est quoi les 00 00 00 avant 123 et puis pourquoi 123 n'est en packet de 2 octets?"Parce qu'un int est codé sur 4 octets. 123, ça donne, en hexa : 0x0000007B. Les 3 octets de poids fort sont à 0. > Geraff a dit : "Et puis comment on fait les bébés?"Pour ça il vaut mieux le découvrir par toi-même, c'est beaucoup plus intéressant ainsi... :ugeek:

Les deux 78 c'est une coquille en effet :x

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

Comprendre le protocole de Dofus

Kyu

Le RDM doit dépasser cette taille.

BlueDream

@decompo Quel est le numéro du message que tu souhaites analyser ?

Le RawDataMessage, l'InventoryContentMessage (et ses dérivés) ou encore le mapComplementaryDataMessage sont susceptibles de dépasser cette taille en effet.

Unnomcommun

bouh2
Donc pour écrire "Bonjour|123" on aura dans notre paquet 11 octets : 66 78 78 74 79 85 82 124 49 50 51

Personne à relever l'erreur depuis le temps, "Bonjour" ne prendrait pas "78 78" car aucune lettre en double, ce serait donc "66 79 78 74 79 85 82" et cela partout dans le code ^^

Sinon merci beaucoup pour ce sujet, j'aimerais savoir, c'est de l'AMF en gros?

BlueDream

@Unnomcommun Si par AMF, tu veux dire, Action Message Format, inspiré de SOAP, oui c'est le cas.

Chaque message est constitué d'une enveloppe et d'un modèle de données.

Après je ne pense que Ankama ait respecté toute les normes, en général SOAP est utilisé pour facilité la communication en HTTP et il reprend le format XML qui alourdit énormément les échanges ce qui n'est pas un problème quand les volumes de données transitées sont faibles, mais dans le cadre d'un jeu, ce n'est pas très optimisé.

Ankama s'en est inspiré mais leur protocole reste très lend, exemple avec le MapComplementaryInformationsDataMessage, ou le RawDataMessage, les paquets sont très lourds, et mettent parfois plusieurs secondes à être traités.

Unnomcommun

Bonjour @BlueDream je te remercie de ta réponse, je me doutes bien qu'ils ont pas repris le protocole AMF, ce serait trop simple il y à des DLL pour traduire dans les deux sens, ce serait bien trop facile ! :D

Jean-Kev

Bonsoir tout le monde,

En me lançant dans l'analyse du protocole D2, je me retrouve avec des paquets comme celui-ci :

Test de déplacement d'une cellule

0e d9 00 00 00 b4 3e 00 02 01 7f 01 80 41 94 00 00 28 00 00 00 97 46 e2 b6 ca ff dd 68 25 2f fa bf 22 94 58 58 c3 9d 67 28 8f d5 05 86 82 1d cc 97 c8 65 45 b2 b7 2b 54 17 ed 43 41 0d 6f 08 74 2e 16 6e da db

Avec 0e d9 je retrouve bien ID 950, et taille de la taille = 1

Sauf que l'octet suivant... Bah c'est 00. Mon paquet ne fait pas 0 de taille.

Il m'est même arrivé de trouve dans les 2 premiers octets une taille de taille de 0.

Le protocole aurait-il changé ou bien je passe à côté de quelquechose?

Merci pour vos réponse,

Jean-Kev

Brasvengeur

Il a change pour les messages ENVOYÉ AU SERVEUR , il y a un id d increment , comptant chaque message envoyé.

Je ne sais pas si le 950 est envoye au serveur mais ça pourrait expliquer !

Jean-Kev

Salut @Brasvengeur ! Merci pour ta réponse, je viens de me rendre compte de cela, et effectivement le nombre incrémente en fonction du nombre d'échanges avec le serveur, lors de l'envoi.

Pour prendre un autre exemple, pour la réception cette fois!

La réponse du 950 (déplacement cellule) est un paquet d'ID 951:

0e dd 10 00 02 01 7f 01 80 00 05 42 06 0b 00 06 78 00 00 02 c0

La taille devrait être 10, soit 16 octets, hors il y en a bien 18!

Une idée de pourquoi la taille semble erronée?

Je n'ai pas ce problème avec tous les paquets, la réception des messages canal commerce fonctionne bien par exemple..

Brasvengeur

Un packet TCP peut contenir de 0 a x packets DOFUS entier.

Concretement avec le 951 tu recois aussi le 226 , je ne sais pas compter les octets ect mais le compte doit y etre sachant que le 226 est vide !

En resume ta taille est bonne donc tu peux couper ton packet dofus et lire le suivant avec la fin de ton packet tcp !

DrBrooklyn

Brasvengeur
Un packet TCP peut contenir de 0 a x packets DOFUS entier.
Concretement avec le 951 tu recois aussi le 226 , je ne sais pas compter les octets ect mais le compte doit y etre sachant que le 226 est vide !
En resume ta taille est bonne donc tu peux couper ton packet dofus et lire le suivant avec la fin de ton packet tcp !

TCP n'est pas un protocole orienté paquet/message, c'est un protocole orienté flux/stream, il n'y a donc pas de "paquet TCP"

De plus, la fragmentation TCP est aléatoire et dépend des différents algorithmes implémentées dans les cartes réseaux et de la configuration du socket (nagle, etc..)

Unnomcommun

DrBrooklyn
TCP n'est pas un protocole orienté paquet/message, c'est un protocole orienté flux/stream, il n'y a donc pas de "paquet TCP"
De plus, la fragmentation TCP est aléatoire et dépend des différents algorithmes implémentées dans les cartes réseaux et de la configuration du socket (nagle, etc..)

(J'espère pas dire n'importe quoi) c'est pour ça que dès le départ il faut développer quelque chose qui va "lire" ce qui est reçu et découper par "paquets" de façon à garder les autres paquets reçu dans le flux et pouvoir lire un par un les paquets et garder le reste qui peut être qu'une partie de paquet (il me semble qu'on peut recevoir parfois un paquet en plusieurs flux, même si c'est bien souvent l'inverse).

Donc il faut faire une fonction qui dans tout les cas pourra tenir son compte et gérer le paquet entier tout en gardant le surplus pour le traiter par la suite.

Par "paquet" j'entends plus les groupes formant une entité.

DrBrooklyn

Unnomcommun
(J'espère pas dire n'importe quoi) c'est pour ça que dès le départ il faut développer quelque chose qui va "lire" ce qui est reçu et découper par "paquets" de façon à garder les autres paquets reçu dans le flux et pouvoir lire un par un les paquets et garder le reste qui peut être qu'une partie de paquet (il me semble qu'on peut recevoir parfois un paquet en plusieurs flux, même si c'est bien souvent l'inverse).
Donc il faut faire une fonction qui dans tout les cas pourra tenir son compte et gérer le paquet entier tout en gardant le surplus pour le traiter par la suite.
Par "paquet" j'entends plus les groupes formant une entité.

https://devblogs.microsoft.com/dotnet/system-io-pipelines-high-performance-io-in-net/

Un article qui liste les problématiques et comment les résoudre, en C# mais applicable à n'importe quel langage

Itexe

Bonjour voilà un méga up mdr j'ai sniffer un packet du canal recrutement (je débute l'apprentisage) j'ai un packet commençant par :

3C 91 80 je vous passe en binaire : 0011 1100 1001 0001 1000 0000

SI je suis le tuto :

0011 1100 1001 0001 1000 0000

En rouge j'ai mon ID = 3876

En bleu j'ai ma taille = 1

Bon alors voici un image du packet :

Donc je me suis fais un tool qui parcours les fichiers de dofusinvoker et j'ai aucun truc qui a un protocole d'id 3876 pour commencer

de plus il me dise que la lentaille est 1 si je lit sur 1 octet il me dise qu'il faut lire sur 128 bits or le message fait bien plus que 128 bits je coince peut être et surement un soucis de compréhension de ma part en espérant que certaine personne puisse m'aiguiller

9True

Le paquet que tu as sélectionné dans l'image n'est pas le même que tu as inscrit dans ton post; vérifie cela, tu vas pouvoir ensuite retrouver cet ID dans le protocol (ChatServerMessage)

Itexe

9True
Le paquet que tu as sélectionné dans l'image n'est pas le même que tu as inscrit dans ton post; vérifie cela, tu vas pouvoir ensuite retrouver cet ID dans le protocol (ChatServerMessage)

Salut merci beaucoup te ta réponse !

Dans mon packet que j'ai envoyé je commence bien par 3C 91 80 ou je doit commencer par : 0d c5 c2 ?

Je vais surement allez suivre un tuto wireshark avant de continué a sniffer les packets dofus mdr.

Merci encore pour m'avoir donné le fichier ou se trouve l'id du protocole que je cherche !

KingOfGobballs

Tu dois prendre la partie

data

des packets TCP. Donc dans ton cas c'est bien le

0dc5

ton header dofus

Itexe

KingOfGobballs

Tu dois prendre la partie

data

des packets TCP. Donc dans ton cas c'est bien le

0dc5

ton header dofus

Je viens de capter merci beaucoup ! Encore désolé du up ahah !

Unnomcommun

Ne pas confondre la structure du socket et les informations contenu dans le message en effet.

killjulien

Bonjour à tous, je me permets d'up un petit peut le sujet !

Je me suis rendu compte en parcourant les différents sujets du forum qu'il était possible qu'un message soit séparé en plusieurs parties.

Ma question est : comment détecter un tel cas, et ensuite comment concaténer les 2 messages et être sûr que le paquet suivant contient bien la suite du message et n'est pas un message qu'on ne voudrait pas traiter ?

Claudine

Tout dépend du langage/lib que tu vas utiliser, dans certain c'est géré automatiquement par le langage, si tu utilises une lib de bas niveau (c'est-à-dire au niveau du procole TCP) tu vas devoir récupérer la taille du packet total dans l'header de ta requête, et récupérer chaque chunk de données jusqu'à atteindre la taille indiquée.

« Page précédente Page suivante »