Paquet 2.0 MITM

Inscrit
31 Mars 2016
Messages
33
Reactions
0
#1
Salut,
Je travaille sur un bot MITM avec 2 listeners (1 pour client local, 1 pour client server).
Je suis actuellement au RawDataMessage après avoir été connecté au server game.

J'ai remarqué que la taille du paquet décodé (> 70.000) est plus grande que la capacité du packet reçu (65.535). Ce qui signifie que le RDM a été envoyé en plusieurs paquets.

D'où ma question, quelles sont les différents cas possibles pour le server?
- 1 paquet => 1 message
- 1 paquet => 1 suite de message
- 1 paquet => 1 suite de message + 1 message
- 1 paquet => 1 suite de message + 1 début de message
- 1 paquet => 1 message + 1 début de message

Et est-ce que le client n'envoi que 1 paquet pour 1 message ? Ou est-ce-qu'il peut aussi envoyer des messages fractionnés dans plusieurs paquets ?
 

zahid98

Membre Actif
Inscrit
13 Decembre 2014
Messages
352
Reactions
2
#2
petite question HS : pourquoi t’intéresses-tu au RawDataMessage ?
 
Inscrit
10 Mai 2015
Messages
357
Reactions
55
#3
Zahid au lieu de poser ta question tu peux directement lui dire, en mitm tu as pas besoin de gerer le RawDataMessage, car le client te l'envoie il te suffit de le renvoyer. Sauf, que lui il veux pas gerer le Rawdatamessage mais adapté son Parser pour qu'il sache lire le paquet car oui il me semble que le RawDataMessage s'envoie en 2 fois.
 
Inscrit
24 Septembre 2016
Messages
17
Reactions
0
#4
Outch
 

zahid98

Membre Actif
Inscrit
13 Decembre 2014
Messages
352
Reactions
2
#5
ça fait un ans qu'il est inscrit sur Cadernis , je crois qu'il sait bien qu'on a pas gérer le RDM dans un MITM d'où vient ma question :) .
 

neross

Membre Actif
Inscrit
20 Decembre 2014
Messages
150
Reactions
0
#6
ça fait un ans qu'il est inscrit sur Cadernis , je crois qu'il sait bien qu'on a pas gérer le RDM dans un MITM d'où vient ma question :) .
Car tu crois que tout le monde lis tout ? Personnellement je ne sais pas du tout comment fonctionne le RawDataMessage d'Ankama malgré les 100 topics qui en parle, juste j'ai lus uniquement le début et j'ai zapper.
 
Inscrit
10 Mai 2015
Messages
357
Reactions
55
#7
Enfaite justement tu as pas bien compris sa question, il veut pas le contourner, il veut traiter le packet car il s'envoie en 2 fois il me semble tellement le packet est gros. et ça en Mitm tu es obligé de le faire. Il souhaite pas le déserialiser.
 

zahid98

Membre Actif
Inscrit
13 Decembre 2014
Messages
352
Reactions
2
#8
Voilà , je savais pas qu'il désire le renvoyer deux parce que de base il y'a une erreur sur son parseur puisque le RDM atteint les 70ko dans son bot alors que sa taille moyenne est de 40Ko .

Car tu crois que tout le monde lis tout ? Personnellement je ne sais pas du tout comment fonctionne le RawDataMessage d'Ankama malgré les 100 topics qui en parle, juste j'ai lus uniquement le début et j'ai zapper.
Tu as raison peut-être , mais mon intuition me dit toujours qu'il sait comment il faut se comporter avec un RDM dans un MITM :3 .
 
Inscrit
31 Mars 2016
Messages
33
Reactions
0
#9
Je suis nouveau sur le dev 2.0 , je travaillais sur du 1.29 avant.

J'ai bien compris que le RDM, c'est un swf compressé et je compte pas perdre du temps la dessus.
Cependant Il pèse lourd.

Pour l'instant j'ai le système minimaliste :
1. je reçois les paquets (client et serveur)
2. j'extrait le ou les messages (id + contenu en byte)
3. je les ré encode
4. je renvois

Je n'ai fais que les deux classes pour rediriger la connexion pour arriver sur le server game (Packet AYK 1.29 même système).

Ainsi je ne déserialize pas les messages, j'affiche juste les id + contenu brut.

Mon problème, c'est qu'avant le premier RDM, tous les packets encapsulent X messages complets.
Je sépare les X messages et je les renvois un par un.
Et arrivé au RDM, le paquet contient un message incomplet. Il faut donc lire le ou les prochain(s) paquet(s) pour finir le RDM.

Ma question principale c'est est-ce-que ce comportement peut arriver avec d'autres types de paquets ? Les paquets lourds que le serveur de D n'aurait pas eu le temps d'envoyer en entier.

Je pense que cela dépend fortement du temps d'attente entre chaque lecture sur les sockets.
Combien me conseillez vous (50, 100, 200 ms) ?

PS : J'utilise la Dll No.Amakna, mais elle fait quoi au juste une fois injectée ? Redirection de flux vers 127.0.0.1:5555 ?
 

Labo

Membre Actif
Inscrit
16 Aout 2013
Messages
799
Reactions
15
#10
En communication réseau, on part du principe que TOUT peut arriver.
Pour cette raison, tu dois TOUJOURS utiliser un buffer.

Je pense que cela dépend fortement du temps d'attente entre chaque lecture sur les sockets.
Combien me conseillez vous (50, 100, 200 ms) ?
Tu n'auras pas ce problème avec un buffer. Cependant, pour éviter le lag, il est préférable d'avoir une petite valeur, mais si elle est trop petite, cela consommera trop de processeur. C'est pour ça qu'il existe :
  1. les primitives select fournies par l'OS si tu es sous UNIX (aucune idée de comment ça marche sous Windaube)
  2. la programmation asynchrone
A priori, tu n'utiliseras pas le 2. Je te conseille donc de faire des boucles infinies avec des sleep de l'ordre de 20 ms, puis de chercher comment tu peux utiliser select ou autre : de l'attente bloquante qui permet de monitorer un descripteur de fichier (ici le socket TCP).

PS : J'utilise la Dll No.Amakna, mais elle fait quoi au juste une fois injectée ? Redirection de flux vers 127.0.0.1:5555 ?
En gros, oui :)
Sous le capot, elle "hooke" (remplace) tous les appels d'une certaine fonction fournie par l'OS pour accéder au réseau.
 
Inscrit
31 Mars 2016
Messages
33
Reactions
0
#11
Oui effectivement je vais utiliser un buffer, je sais pas pourquoi j'y ai pas pensé alors que sur 1.29 j'en utilise aussi :/

Comment ça je n'utilise pas la prog async ? Tu ne peux pas faire sans ?? ^^
Je code en c# et j'utilise les async/await (ça crée des thread à la volé).
 

Labo

Membre Actif
Inscrit
16 Aout 2013
Messages
799
Reactions
15
#12
Euh je m'y connais pas en C#…
Mais quand je parlais de programmation asynchrone, je parlais plus de programmation évènementielle comme en JS où tu coderais juste une méthode onMessage et pas de boucle.
Fais ce qui marche !
 
Haut Bas