Suis-je sur la bonne voie ?

Inscrit
6 Aout 2017
Messages
14
Reactions
0
#1
Bonjour à tous.

J'aimerais savoir si je suis sur la bonne voie de compréhension du protocole D.2.

Tout d'abord, le client D2 se sert d'un protocole qui lui ait spécifique pour communiquer avec son serveur sur une Ip de plage 213.248.126.0/24 et de port 444 ou 5555. Celui-ci utilise un protocole divisé en deux parties l'id du paquet codé sur 2 octets ( qui inclue l'id du paquet cod.é sur 6 bits et la taille de celui-ci codé sur 2 bits et 2 autres bits qui servent à défini la taille de la taille de l'ID) l'autre partie du paquet est le contenu de celui-ci codé sur n octets + n octets(la taille du message).

Avant toute chose il nous est primordial de développer les READERS/WRITER, car DOTNET ne nous fournis pas des classes permettant de lire des octets avec le bon format qui est de base "LITTLE ENDIAN" mais Ankama pas décidé d'écrire son protocole en "BIG ENDIAN" donc deux possibilités s'offrent à nous sois, nous re-codons, une classe spécifique pour ce format de lecture/ecriture soit-on ce sert d'une bibliotheque thiers.

Une fois ceci fait, nous devons extraire les classes des packets contenue dans le DofusInvoker avec JPEX (par exemple) pour comprendre comment sérialiser et désérialiser un paquet. Sérialiser un paquet veut ici dire, comment constitue un tableau dynamique d'octet afin que celui-ci corresponde à ce que le serveur attend pour un paquet défini , et désérialiser veut dire comment extraire les informations d'un tableau dynamique d'octets afin de comprendre ce que ces informations signifient.

Il est conseillé pour le développement de bot de créer deux frameworks un framwork "protocole" qui comporte l'ensemble des paquets que nous avons besoin pour réaliser les actions souhaité dans le jeu ( ces classes contiennent 2 informations essentielles l'id du paquet pour toutes les classes et un sérializer pour les classes qui contiennent un paquet émis par le client et un désérializer pour les classes qui contiennent un paquet émis par le serveur). Et un framework "network" qui va gérer toutes les communications avec le serveur qui contiendra (classe qui crée la communication avec le serveur , READERS , WRITER).

Je pense pour ma part que nous devrions développer un troisième framework "manager" qui va agir comme un contrôleur pour diriger les deux frameworks de données et interagir avec la vue de notre application (je me trompe?) ce framework contiendra selon moi plusieurs events qui lui fourniront des informations de la part du framework network sur les paquets émis du serveur ce troisième framework interrogera le framework protocole pour savoir à quoi correspondent ces informations, et en fonction du paquet celui-ci va décider d'éventuellement de répondre au serveur ou mettre à jour l'interface graphique en fonction des données reçu et interpreter.

Voici ce que j'ai réussi à comprendre des magnifiques <3 tutoriels fournis sur CADERNIS en en 2 jours d'étude.J'aimerais savoir si je suis sur la bonne voie pour vous, ou si je suis en train de partir en vrille ^^.

J'ai également quelques questions à vous pausé :

Dans le tutoriel bots sockets les fondamentaux ont nous dits à un moment que :
5) Les Types

Notre lib va également contenir les typee, on va donc choisir également une structure à respecter pour ceci, elle va être très semblable à celle que nous avons vue précédemment.
sans nous expliquer ce qu'est un types dans notre cas donc qu'es ce que c'est?

On parle souvent ici de fichier d2o/d2i & d2p que représente-t-il?

AmaknaCore sniffeur développé par Alexandre1004 est-il une alternative pertinente à l'utilisation de WPE PRO?

WPE PRO nous fournirait-t-il des information nécéssaire à la création de bot qu'AmaknaCore ne nous fournirait pas?

Dernière question qui peut paraître bête, mais je me lance quand même ;) Comment effectuons nous des recherchés de paquets dans le logiciel JPEX, j'ai cherché pendant plusieurs dizaines de minutes sans succès.

Merci de m'avoir lu jusqu'au bout , merci d'être une communauté aussi passionnée et compétente, merci pour tout !

Ps : pardonnait moi d'avance pour l'orthographe .. ;)
 
Inscrit
16 Mars 2014
Messages
214
Reactions
30
#2
J'ai pas lu le début mais je vais répondre aux questions du bas

Les types sont utilisés et ce retrouvent dans certains packets (sur JPEXS tu vas ici : com/ankamagames/dofus/network/types) et c'est comme pour les class des packets tu retrouves leur Id et comment les serialize/ deserialize

Les fichiers:
d2o = contient des informations statiques du jeu (id des monstres, items, sorts, effets etc..)
d2i = contient tous les textes du jeu
d2p = archive qui contient des images (png, jpeg ou swf, swl) tu peux aussi trouver dans les d2p des maps des .dml
dlm = contient les informations d'une map

Le sniffer d'alex va afficher exactement la même chose que WPE Pro sauf que les données sont directe interprété et sont affichés en "clair" alors que sur WPE pro t'aura que la suite de bytes

Pour chercher un packet sur JPEX si ta pas le nom exacte ou le début je ne pense pas que tu puisses le trouver mais tous les packets du jeu se trouve ici com/ankamagames/dofus/network tu peux exporter le dossier network de JPEXS sur ton bureau et après tu peux chercher dans le dossier ton packet via le nom / id
 
Inscrit
6 Aout 2017
Messages
14
Reactions
0
#3
[/QUOTE]ai pas lu le début mais je vais répondre aux questions du bas[/QUOTE]
Dommage j'aurais apprécié avoir ton retour.

Les types sont utilisés et ce retrouvent dans certains packets (sur JPEXS tu vas ici : com/ankamagames/dofus/network/types) et c'est comme pour les class des packets tu retrouves leur Id et comment les serialize/ deserialize
Merci pour ta réponse mais j'ai encore un peut de mal à comprendre ce que c'est .. Je sais ou il ce situe je comprend comment les développé en classe du même genre que les paquets , mais pas à quoi ils servent.

d2o = contient des informations statiques du jeu (id des monstres, items, sorts, effets etc..)
d2i = contient tous les textes du jeu
d2p = archive qui contient des images (png, jpeg ou swf, swl) tu peux aussi trouver dans les d2p des maps des .dml
dlm = contient les informations d'une map
Merci pour le complément d'information. Mais d2i , d2p en quoi sont t'ils indispensable pour le développement d'un bot , ces éléments apporte un confort visuel à l'utilisateur qui utilise le client officiel , mais pour un bot socket récupérer les images on ne s'en préoccupe pas si ?
Même les DLM , à quoi peuvent t'il bien servir pour la création d'un bot socket?

Le sniffer d'alex va afficher exactement la même chose que WPE Pro sauf que les données sont directe interprété et sont affichés en "clair" alors que sur WPE pro t'aura que la suite de bytes
Ok merci pour l'info !

Pour chercher un packet sur JPEX si ta pas le nom exacte ou le début je ne pense pas que tu puisses le trouver mais tous les packets du jeu se trouve ici com/ankamagames/dofus/network tu peux exporter le dossier network de JPEXS sur ton bureau et après tu peux chercher dans le dossier ton packet via le nom / id
JPEX est vraiment super lourd / lent comme programme il réussi à me faire rammer un MacBook Pro 2017 8GO ram ! ^^

Merci pour ta réponse en tous cas ! :)
 

BlueDream

Administrateur
Membre du personnel
Inscrit
8 Decembre 2012
Messages
2 010
Reactions
149
#4
AmaknaCore sniffeur développé par Alexandre1004 est-il une alternative pertinente à l'utilisation de WPE PRO?

WPE PRO nous fournirait-t-il des information nécéssaire à la création de bot qu'AmaknaCore ne nous fournirait pas?
Le sniffer te mâche totalement le boulot, il lit les paquets échangés, distingue leur provenance ( Client / Serveur ), associe l'ID du paquet à sa classe dans le protocole, et liste les variables et leurs valeurs. Tout ça pour te permettre très facilement de comprendre comment le jeu est structuré et comment les données sont traitées.
Avec WPE Pro tu n'auras rien de plus que des données encodées, je te recommande de faire un tour sur ce sujet: https://cadernis.fr/index.php?threads/comprendre-le-protocole-de-dofus.115/
 
Inscrit
6 Aout 2017
Messages
14
Reactions
0
#5
Inscrit
19 Juillet 2017
Messages
18
Reactions
1
#6
Merci pour le complément d'information. Mais d2i , d2p en quoi sont t'ils indispensable pour le développement d'un bot , ces éléments apporte un confort visuel à l'utilisateur qui utilise le client officiel , mais pour un bot socket récupérer les images on ne s'en préoccupe pas si ?
Bonsoir

Une fois que tu as lu les fichiers d2o, tu vas te rendre compte que tu as que le nameId.
Si tu veux le nom, tu devra regarder dans le fichier d2i la value associée a la clé : nameId que tu as trouvé.

Ca peut être utile dans certain cas, imaginons que tu veuilles trouver le nameId de l'amulette strigide dans le fichier Items,
Tu fait une recherche de "amulette strigide" dans le fichier d2i :
"278083": "Amulette du Strigide",

et tu as donc ici l'id de l'item dans le fichier Items : 278083
 
Dernière édition:
Inscrit
6 Aout 2017
Messages
14
Reactions
0
#7
Bonsoir Towseur,

Merci pour ta réponse !
Prenons un exemple pour voir si j'ai bien compris :
ExchangeObjectMoveMessage d'id 5518 demande une quantité et un l'id de l'object.
Si l'utilisateur veut mettre en banque via le bot l'amulette strigide par exemple nous devrions allez chercher dans le d2i l'id 278083

Ou encore si le client veut voir tout le contenue de ça banque StorageInventoryContentMessage nous fournis une liste d'Id nous pourrions ainsi grâce au d2i lui afficher en "claire" le contenue de ça banque?

Si c'est bien ça grâce à toi tout me paraît beaucoup plus claire ! :)
 
Inscrit
19 Juillet 2017
Messages
18
Reactions
1
#8
Ouip c'est ça !
Si on reprends l'exemple du ExchangeObjectMoveMessage, si on transfert par exemple un anneau brouce, (j'ai pas d'amu stri en stock xD )
ce paquet envoie comme information :

5518 ExchangeObjectMoveMessage:
- objectUID = 164621426
- quantity = -1

puis le serveur met à jour les informations et ajoute, par exemple, l'item dans l'inventaire:

3025 ObjectAddedMessage :
- position = 63
- objectGID = 13115
- effects = AmaknaCore.Protocol.Types.ObjectItem
- objectUID = 164621426
- quantity 1

Si tu regarde dans le fichier Items parmis les fichier d2o à l'id 13115,
tu vas trouver :
{
"id": 13115,
"nameId": 98101,
"typeId": 9,
"descriptionId": 98819,
"iconId": 9249,
"level": 198,
"realWeight": 10,
"cursed": false,
"useAnimationId": 0,
"usable": false,
"targetable": false,
"exchangeable": true,
"price": 19800.0,
"twoHanded": false,
"etheral": false,
"itemSetId": 240,
"criteria": "null",
"criteriaTarget": "null",
"hideEffects": false,
"enhanceable": true,
"nonUsableOnAnother": false,
"appearanceId": 0,
"secretRecipe": false,
"recipeSlots": 8,
"recipeIds": [],
"dropMonsterIds": [],
"bonusIsSecret": false,
"possibleEffects": [
{
"targetMask": "",
"diceNum": 251,
"visibleInBuffUi": true,
"visibleInFightLog": true,
"targetId": 0,
"effectElement": -1,
"effectUid": 0,
"triggers": "",
"duration": 0,
"random": 0,
"effectId": 125,
"delay": 0,
"diceSide": 300,
"visibleInTooltip": true,
"rawZone": "C",
"value": 0,
"group": 0
},
{
"targetMask": "",
"diceNum": 51,
"visibleInBuffUi": true,
"visibleInFightLog": true,
"targetId": 0,
"effectElement": -1,
"effectUid": 0,
"triggers": "",
"duration": 0,
"random": 0,
"effectId": 118,
"delay": 0,
"diceSide": 70,
"visibleInTooltip": true,
"rawZone": "C",
"value": 0,
"group": 0
},
{
"targetMask": "",
"diceNum": 21,
"visibleInBuffUi": true,
"visibleInFightLog": true,
"targetId": 0,
"effectElement": -1,
"effectUid": 0,
"triggers": "",
"duration": 0,
"random": 0,
"effectId": 124,
"delay": 0,
"diceSide": 30,
"visibleInTooltip": true,
"rawZone": "C",
"value": 0,
"group": 0
},
{
"targetMask": "",
"diceNum": 1,
"visibleInBuffUi": true,
"visibleInFightLog": true,
"targetId": 0,
"effectElement": -1,
"effectUid": 0,
"triggers": "",
"duration": 0,
"random": 0,
"effectId": 117,
"delay": 0,
"diceSide": 0,
"visibleInTooltip": true,
"rawZone": "C",
"value": 0,
"group": 0
},
{
"targetMask": "",
"diceNum": 11,
"visibleInBuffUi": true,
"visibleInFightLog": true,
"targetId": 0,
"effectElement": -1,
"effectUid": 0,
"triggers": "",
"duration": 0,
"random": 0,
"effectId": 430,
"delay": 0,
"diceSide": 15,
"visibleInTooltip": true,
"rawZone": "C",
"value": 0,
"group": 0
},
{
"targetMask": "",
"diceNum": 11,
"visibleInBuffUi": true,
"visibleInFightLog": true,
"targetId": 0,
"effectElement": -1,
"effectUid": 0,
"triggers": "",
"duration": 0,
"random": 0,
"effectId": 422,
"delay": 0,
"diceSide": 15,
"visibleInTooltip": true,
"rawZone": "C",
"value": 0,
"group": 0
},
{
"targetMask": "",
"diceNum": 7,
"visibleInBuffUi": true,
"visibleInFightLog": true,
"targetId": 0,
"effectElement": -1,
"effectUid": 0,
"triggers": "",
"duration": 0,
"random": 0,
"effectId": 213,
"delay": 0,
"diceSide": 10,
"visibleInTooltip": true,
"rawZone": "C",
"value": 0,
"group": 0
},
{
"targetMask": "",
"diceNum": 5,
"visibleInBuffUi": true,
"visibleInFightLog": true,
"targetId": 0,
"effectElement": -1,
"effectUid": 0,
"triggers": "",
"duration": 0,
"random": 0,
"effectId": 161,
"delay": 0,
"diceSide": 7,
"visibleInTooltip": true,
"rawZone": "C",
"value": 0,
"group": 0
},
{
"targetMask": "",
"diceNum": 4,
"visibleInBuffUi": true,
"visibleInFightLog": true,
"targetId": 0,
"effectElement": -1,
"effectUid": 0,
"triggers": "",
"duration": 0,
"random": 0,
"effectId": 752,
"delay": 0,
"diceSide": 5,
"visibleInTooltip": true,
"rawZone": "C",
"value": 0,
"group": 0
}
],
"favoriteSubAreas": [],
"favoriteSubAreasBonus": 0,
"craftXpRatio": -1,
"needUseConfirm": false,
"isDestructible": true,
"nuggetsBySubarea": [
[
54.0,
375.0
],
[
55.0,
44.699996948242188
],
[
181.0,
51.75
],
[
455.0,
115.34999847412109
],
[
464.0,
35.21875
],
[
472.0,
35.21875
],
[
605.0,
65.79998779296875
],
[
608.0,
86.924995422363281
],
[
652.0,
110.84062194824219
]
],
"containerIds": [],
"resourcesBySubarea": []
},

donc le nameId de l'anneau brouce est 98101
on regarde dans le fichier d2i cette fois :

"98101": "Anneau de Brouce",

Dans ce cas la c'est pas très pertinent puisque on sait au debut de quel item il sagit.
Par contre c'est plus intéressant dans le deuxième cas.

Ou encore si le client veut voir tout le contenue de ça banque StorageInventoryContentMessage nous fournis une liste d'Id nous pourrions ainsi grâce au d2i lui afficher en "claire" le contenue de ça banque?
ce paquet renvoie quelque chose du style :

5646 StorageInventoryContentMessage:
- objects = ObjectItem[]
- kamas = 0

ObjectItem contient des classe object qui ont pour attribut :
- postion
- objectGID
- effects
- objectUID
- quantity

http://prntscr.com/g8y9bk

Donc si on veut savoir à quel item correspond l'element 0,
on prend objectGID : 301

puis on va regarder dans les d2o le fichier Items
{
"id": 301,
"nameId": 53493,
"typeId": 53,
"descriptionId": 428379,
"iconId": 53014,
"level": 14,
"realWeight": 1,
"cursed": false,
"useAnimationId": -1,
"usable": false,
"targetable": false,
"exchangeable": true,
"price": 10.0,
"twoHanded": false,
"etheral": false,
"itemSetId": -1,
"criteria": "null",
"criteriaTarget": "null",
"hideEffects": false,
"enhanceable": true,
"nonUsableOnAnother": false,
"appearanceId": 0,
"secretRecipe": false,
"recipeSlots": 0,
"recipeIds": [
1116,
8108,
1700,
8111,
849,
8114,
11981,
185,
953,
8110,
8112,
8113,
8109,
6600,
8142,
1093,
1092,
1094,
1095,
6724,
10974,
11082,
779,
2412,
2534,
6756,
6909,
6757,
12731,
7921,
1698,
1703,
708
],
"dropMonsterIds": [
794,
382,
801,
805,
1011,
1012,
1013,
2355,
98
],
"bonusIsSecret": false,
"possibleEffects": [],
"favoriteSubAreas": [],
"favoriteSubAreasBonus": 0,
"craftXpRatio": -1,
"needUseConfirm": false,
"isDestructible": true,
"nuggetsBySubarea": [
[
3.0,
0.0028760333079844713
],
[
30.0,
0.0028760333079844713
],
[
44.0,
0.0028760333079844713
],
[
780.0,
0.0028760333079844713
]
],
"containerIds": [],
"resourcesBySubarea": []
},

on trouve pour nameId 53493
et enfin on va regarde à quoi ça correspond dans le fichier d2i
Suspence ...

"53493": "Plumes de Tofu",

Je vais vérifier en banque si j'ai bien 111 plumes de tofu
http://prntscr.com/g8ybtf

Tout est bon :)

Voila en espérant avoir été assez clair.
Je suis pas non plus expert dedans donc, si je me suis trompé quelque part, n'hesiter pas à me corriger .
Bonne soirée

Edit : j'ai oublier de parler du GID vs UID
le UID c'est un id propre à chaque item qui permet de rendre unique chaque item (donc liée au serveur)
 
Inscrit
6 Aout 2017
Messages
14
Reactions
0
#9
(j'ai pas d'amu stri en stock xD )
Haha on à pas tous les même valeurs :p

puis on va regarder dans les d2o le fichier Items
Niquel en plus je savais pas comment extraire ces informations mais la je me rend compte que c'est un sérialisé en JSON donc j'aurais qu'a récupérer un tableau d'object :) avec un truc du style :
private string GetObjectNameFromId(int id){
if(id <= 0){
return "ID NULL";
}

string myId = id.ToString();
string objectName = string.empty;

for(int ï = 0 ; ï < _d2oArray.length() ; ï++){
if(_d2oArray[ï].id == myId){
string nameId = __d2oArray[ï].nameId;
objectName = _d2iArray[nameId];
}
}

if(objectName == null){
return "OBJECT NAME NOT FOUND.";
}

return objectName;
avec à la place de ces vieux return un jolie système d'exception ;).

Edit : j'ai oublier de parler du GID vs UID
le UID c'est un id propre à chaque item qui permet de rendre unique chaque item (donc liée au serveur)
ça me paraissait logique sinon comment le serveur aurais pu différencier 2 amulette strigide dans l'inventaire par exemple :p Mais merci de m'avoir éclairer sur ce qu'étais l'identifiant unique et l'identifiant universel !

Il est quand même exceptionnel le parseur d'Alexandre !

Merci beaucoup tu m'as énormément éclairer !! :)

Je vais en profité pour
posé une petite dernière question ^^ : Pourquoi dans les quelques code sources que j'ai analysé disponible sur le site tous propose deux classe d'encryption (AES,RSA)
alors que Bouh2 dans son tutoriel nous explique que justement le protocole n'est pas encrypté (d'ailleurs si Ankama voudrais faire en sorte qu'il n'y ai plus de bot ils n'auraient qu'à encrypté leur protocole non ?^^).
 
Dernière édition:
Inscrit
19 Juillet 2017
Messages
18
Reactions
1
#10
Niquel en plus je savais pas comment extraire ces informations mais la je me rend compte que c'est un sérialisé en JSON donc j'aurais qu'a récupérer un tableau d'object
Malheuresement c'est pas aussi simple ^^.
Pour lire les fichiers d2o, je crois qu'il faut aller voir comment les lire via le fichier :
com\ankamagames\jerakine\data\GameDataFileAccessor.as

pour les d2i il faut celui ci
com\ankamagames\jerakine\data\I18nFileAccessor.as

"La lecture se trouve dans ce fichier principalement.
Le reste des fichiers aux alentours permettent de traiter les résultats."

Voila d'ou je tiens ces infos :

https://cadernis.fr/index.php?threads/que-contiennent-les-fichiers-d2o-concrètement.1989/#post-21643
https://cadernis.fr/index.php?threads/resolu-c-help-d20.1051/#post-12162
https://cadernis.fr/index.php?threads/comment-lire-les-fichier-d2i-d2o-et-d2p.963/
https://cadernis.fr/index.php?threads/où-se-trouvent-les-images-des-ressources.1539/#post-17382

Après si tu veux pas te casser la tête, tu peux utiliser l'excellent outil en python fait par LuaxY:

lien pour dl :
https://github.com/balciseri/PyDofus

lien du partage:
https://cadernis.fr/index.php?threads/pydofus-pack-unpack-dofus-files.1242/
 
Dernière édition:
Inscrit
6 Aout 2017
Messages
3
Reactions
0
#11
(d'ailleurs si Ankama voudrais faire en sorte qu'il n'y ai plus de bot ils n'auraient qu'à encrypté leur protocole non ?^^).
En fait non. Le chiffrement, a pour but de sécuriser une conversation de bout à bout.

Etant donné que tu es un des bout, tu as et aura toujours les outils nécessaires pour déchiffrer le protocole.


Maintenant ça peut le rendre *beaucoup* plus compliqué si par exemple ils utilisaient du SSL qui possède un handshake (très court) avant l'établissement d'une clé partagée. Il faudrait alors venir se placer entre le client et le serveur au moment de cette négociation. C'est pas impossible mais ça compliquerait grandement la tâche du MITM. Pour ce qui est du bot socket, ça changerait pas grand chose, il suffirait de faire le handshake soi même et le serveur nous fournirait la clé partagée...

Au mieux ça rendrait inutiles les sniffers de packets style WireShark, ...
 
Inscrit
6 Aout 2017
Messages
14
Reactions
0
#12
Après si tu veux pas te casser la tête, tu peux utiliser l'excellent outil en python fait par LuaxY:

lien pour dl :
https://github.com/balciseri/PyDofus
Ah oui tu m'étonnes je ne vais pas me gêner si je peut avoir un fichier json au lieu d'un fichier difficilement lisible je ne vais pas m'en priver ^^.

Maintenant ça peut le rendre *beaucoup* plus compliqué si par exemple ils utilisaient du SSL qui possède un handshake (très court) avant l'établissement d'une clé partagée. Il faudrait alors venir se placer entre le client et le serveur au moment de cette négociation. C'est pas impossible mais ça compliquerait grandement la tâche du MITM. Pour ce qui est du bot socket, ça changerait pas grand chose, il suffirait de faire le handshake soi même et le serveur nous fournirait la clé partagée...
Je sais pas vraiment comment fonctionne le DofusInvoker mais si le code à l'intérieur de celui ci était obfu alors ça rendrais les tâches de sérialisation et de désérialisation beaucoup plus compliqué les devs non ? Ils auraient du analysé avec un sniffer le contenue de chaque packet alors que maintenant la seul chose qui nous intéresse avec un sniffer c'est l'id du paquet le reste nous ai fournis dans le DofusInvoker.

Merci pour vos retour les mecs ça fais vraiment plaisir !
Vous seriez pourquoi la plupart des bots possèdent des classes de cryptographie (RSA,AES)?
Et quelqu'un serais éventuellement ce que représente les "Types" qui sont accessible dans com/ankamagames/network/types ?
 
Inscrit
19 Juillet 2017
Messages
18
Reactions
1
#13
Etquelqu'un serais éventuellement ce que représente les "Types" qui sont accessible dans com/ankamagames/network/types ?
Je crois que c'est ce qu'on appelle les Frames et c'est justement ce qui permet de différencier chaque paquet et de savoir
comment on le forge ( avec la méthode serialize) et comment on lit le paquets (deserialize)

Quand tu reçois un paquet, tu vas d'abord lire le header pour obtenir le protocolId (ainsi que la taille de la taille puis la taille) ensuite tu vas instancier la frame qui a le bon protocolId.

Reste plus qu'à appeler la méthode deserialize.

Je te renvoie au tuto de Labo qui détaille bien le processus :
https://cadernis.fr/index.php?threads/de-lanalyse-des-paquets.1056/
 
Inscrit
6 Aout 2017
Messages
3
Reactions
0
#14
Chiffrer la conversation n'a rien à voir avec l'obfuscation du code :p

Effectivement le couple des deux : obfusquer le code et chiffrer la conversation aurait rendu le process beaucoup plus compliqué pour les premiers explorateurs !

Maintenant, obfusquer ça reste quelque chose de réversible, c'est juste "compliqué"
 
Inscrit
6 Aout 2017
Messages
14
Reactions
0
#15
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();
Quand je regarde la fonction de deserialisation j'en conclu que les types sont des classes que nous avons besoin pour désérialisé ou sérialisé notre paquet ^^ qui son appelé ou non en fonction des packets à sérialisé.
Chiffrer la conversation n'a rien à voir avec l'obfuscation du code :p

Effectivement le couple des deux : obfusquer le code et chiffrer la conversation aurait rendu le process beaucoup plus compliqué pour les premiers explorateurs !

Maintenant, obfusquer ça reste quelque chose de réversible, c'est juste "compliqué"
Oui c'est ce que je voulais dire ! On peut soit encrypté le protocole et/ou obfu les sources du programme ! ^^.

Franchement avec du recul , des tutoriels , des sniffers , le tout est encore compliqué à comprendre et à prendre en main ... Alors chapeau aux premiers qui ont réussi à tout comprendre et tout interpréter, il y à vraiment des génies dans les joueurs de Dofus :p

Personne ne me répond sur les classes de cryptographie (je suppose que c'est pour encrypté les NDC & MDP lors de la connection du client?).

Dans ce cas tous s'explique dofus se sert de RSA qui est un algorithme de cryptage asymétrique la clef publique nous suffis donc pour encrypté les données et les envoyer au serveur.
 
Inscrit
25 Novembre 2015
Messages
169
Reactions
20
#16
Avant toute chose il nous est primordial de développer les READERS/WRITER, car DOTNET ne nous fournis pas des classes permettant de lire des octets avec le bon format qui est de base "LITTLE ENDIAN" mais Ankama pas décidé d'écrire son protocole en "BIG ENDIAN" donc deux possibilités s'offrent à nous sois, nous re-codons, une classe spécifique pour ce format de lecture/ecriture soit-on ce sert d'une bibliotheque thiers.
En fait, de nos jours la plupart des architectures des processeurs sont du little-endian, le binary writer tel que défini en .NET write selon ton achitecture, si ton processeur a une archi big-endian tu write en big-endian xd
Mais le BinaryWriter en AS3 a été défini en big endian, ankama ne l'a pas décidé d'eux même.

Par contre il faut savoir que les décalages sur les bits pour passer du little au big sont assez couteux, dans le cadre du C# il faudrait songer à utiliser le code dit "unsafe" afin d'avoir des IO les plus performants possible (puisqu'ils sont à la base de toute communication, c'est l'élément clé d'une architecture propre et performante).

(cf. https://github.com/jamesqo/Be.IO qui constitue un bon point d'entrée, si les IO t'intéressent d'avantage)
 
Inscrit
6 Aout 2017
Messages
14
Reactions
0
#17
En fait, de nos jours la plupart des architectures des processeurs sont du little-endian, le binary writer tel que défini en .NET write selon ton achitecture, si ton processeur a une archi big-endian tu write en big-endian xd
Mais le BinaryWriter en AS3 a été défini en big endian, ankama ne l'a pas décidé d'eux même.

Par contre il faut savoir que les décalages sur les bits pour passer du little au big sont assez couteux, dans le cadre du C# il faudrait songer à utiliser le code dit "unsafe" afin d'avoir des IO les plus performants possible (puisqu'ils sont à la base de toute communication, c'est l'élément clé d'une architecture propre et performante).

(cf. https://github.com/jamesqo/Be.IO qui constitue un bon point d'entrée, si les IO t'intéressent d'avantage)
Bonjour Nameless,
Merci pour ce complément d'information ! Actuellement je commence à peine à entreprendre le développement d'un bot pour les IO je pense me contenter pour l'instant de MiscUtils , si j'arrive à en apprendre assez pour ne serais-ce que réussir à me connecté et déplacé mon personnage ce sera déjà merveilleux ^^ et dans une optique d'optimisation par la suite j'incorporerai surement à mon bot un meilleur IO.
Tu pense que cette IO est beaucoup plus rapide que MiscUtils ?

Juste pour ma culture personnel ( j'ai une énorme soif d'apprendre :p) quand j'entend parler de "unsafe" j'entend que ce genre de code non managé par le compilateur atteint des vitesses "astronomique" inateignable par du code managé , mais je suppose qu'il y à des inconvénients à ce style de programmation sinon toutes les classes DOTNET du monde serais "unsafe" afin de gagner en rapidité non?

Petite dernière question toi qui à lu mon long monologue sur ma compréhension des différents tutoriel tu pense que je suis dans le vrai ou qu'il y à pas mal d'endroit mal comprise ?

Merci beaucoup ;)
 
Inscrit
25 Novembre 2015
Messages
169
Reactions
20
#18
Bien sûr, jusqu'à 22x plus rapide que ce genre de class, sur une seul opération de lecture.

Le code unsafe est managé anyway, c'est pour ça qu'on fais appel au bloc fixed() pour fixer l'adresse du pointeur en mémoire, afin d'éviter qu'elle soit déplacé via une collection du garbage collector. M'enfin, l'appel à ce bloc est plutôt coûteux dans le cadre d'appels successif (lecture d'un message ig par exemple). C'est donc à double tranchant, bien que cela reste la meilleure solution. Il existe également des solutions pour contourner ces appels répétitifs, mais c'est pas le sujet.

Par ailleurs, cette classe, du même auteur, est une bien meilleure implémentation que la précédente, mais il manque le writer qui lui demande d'avoir un pré-sizer de message, et c'est pas un travail facile pour un novice.

J'ai pas lu en entier, mais je te déconseille de te baser sur ce qui existe déjà.
 
Inscrit
6 Aout 2017
Messages
14
Reactions
0
#19
Le code unsafe est managé anyway, c'est pour ça qu'on fais appel au bloc fixed() pour fixer l'adresse du pointeur en mémoire, afin d'éviter qu'elle soit déplacé via une collection du garbage collector. M'enfin, l'appel à ce bloc est plutôt coûteux dans le cadre d'appels successif (lecture d'un message ig par exemple)...
Ok merci pour l'information , je savais que le code unsafe étais souvent utilisé pour manipuler les pointeurs j'ai étudié un code avec et sans unsafe c'était impressionnant quelque seconde pour filtrer une image la transformer en noir et blanc avec unsafe une méthode standard managé par le CLR prenait quant à elle plusieurs minute.. Mais je ne savais pas que fixed() empêcher les fuites de mémoire (en gros c'est ça nan?).

Par ailleurs, cette classe, du même auteur, est une bien meilleure implémentation que la précédente, mais il manque le writer qui lui demande d'avoir un pré-sizer de message, et c'est pas un travail facile pour un novice.
Pas vraiment compris mais je suis novice en la matière donc bon..

J'ai pas lu en entier
Je suis bien obligé à un moment ou à un autre de me basé sur ce qui existe déjà le protocole d2o existe et son tutoriel pour le comprendre aussi je ne vois pas pourquoi ne pas m'en servir.
Quant au reste de mon text que tu n'as pas lu il portais sur l'organisation d'un projet comme celui ci en gros j'expliqué qu'au vu de ce que j'ai lu créer 3 frameworks 1 qui communique avec le serveur, 1 qui contient tout les paquets du jeux et un autre qui contrôle l'ensemble en gros n'étais pas une mauvaise idée.

, mais je te déconseille de te baser sur ce qui existe déjà.
Puis voila la programmation c'est génial c'est sûre mais en tant que "novice" on nous apprend rarement à manipuler bit à bit des tableau d'octets afin d'en extraire des informations la plupart du temps c'est pré-mâché par des couches d'abstraction .. C'est aussi cela que je trouve intéressent mais il faut avouer que c'est assez inaccessible sans explications un code comme celui ci par exemple :
Code:
short hiheader = reader.ReadInt16();
short packetId = hiheader >> 2;
short lenType = hiheader & 3;
Ne seras jamais compris par un débutant en développement de bot qu'importe son niveau initiale en programmation si il ne c'est jamais servis d'opérateur bit à bit auparavant , et celui ci ne pourras encore moins trouvé c'est information tous seuls à partir d'un packet D2o sniffé avec WPE pro par exemple..

Je pense que chaque débutant doit partir sur une base aussi mauvaise soit t'elle tant qu'elle fonctionne , il (je) pourras/pourrais toujours s'appuyait sur des bienfaiteurs pour les remettre dans le droit chemin en cas de déviance absolue ;)

Si je parle trop dis moi ou tu as arrêté lire ce com haha :p
 
Inscrit
25 Novembre 2015
Messages
169
Reactions
20
#20
Nan, y a aucun bienfaiteur qui te remettra dans un quelconque "droit chemin" ici, bonne chance pour ton projet.
 
Haut Bas