Bytes en trop dans mes paquets

Inscrit
19 Juillet 2017
Messages
18
Reactions
1
#1
Bonjour,
j'arrive à sniffer mes paquets, mais le problème est lors de la lecture de certain d'entre eux :
En effet, j'arrive à lire l'id et la taille de la taille mais la ou ça coince est pour la taille, meme si la taille est pas nulle, j'obtiens,
une taille de data nulle ...

Je pense pas que c'est un problème de la classe de lecture car j'ai aucun problèmes avec les autres paquets.
J'ai donc penser à un problème de sniffer, du coup j'ai tester avec l'outil proposer par le forum (AmaknaCore.Sniffer) et aussi avec WPE.

Ensuite j'ai comparer les résultat obtenues avec mon sniffer (fait en python).

Premièrement je vois que j'ai les mêmes paquets recu/envoyer et dans tous les cas niveau id tout est bon. (ex : http://prntscr.com/fzs1dq)

Je me suis donc concentré sur les paquets qui posé problème (ceux qui ont un lenType différent de 0 mais qui affiche quand même comme taille de data)

Voici quelque exemple de ces paquets :
--------
la première ligne est le paquet recu par mon algorithme en hexa (j'ai espacé pour plus de lisibilité)
la deuxième ligne correspond au traitement par mon algorithme

en bleu j'ai comparer avec le champ data vu par AmaknaCore.Sniffer (ex : http://prntscr.com/fzw6kf ) et j'ai vu que cette chaine était présente dans les paquets que j'ai via mon algorithme

en noir il s'agit du hi-header ( id + lenType )

en vert il s'agit donc de la taille que j'ai déduit grâce à la longueur de la chaine bleu qui correspond au data.
exemple avec le premiers paquet : la longueur de la chaine bleu len(00193232d81dbe23f136cade98b3b9ff64b5aea43ef28574f7d27ba4e1a2764e14a2b59ebe69359f4a390e87a9ab80f 9a6b60d39)
= 104 donc 104/2 = 52 octets
puis j'ai converti en hexa 52 (b10) = 34 (b16)

--------
587d 00000c7 34 00193232d81dbe23f136cade98b3b9ff64b5aea43ef28574f7d27ba4e1a2764e14a2b59ebe69359f4a390e87a9ab80f 9a6b60d39
id : 5663 nom : BasicLatencyStatsMessage lenType : 1 lenData : 0

0ed9 0000043d 40 000540c230bd20e6111e112c00022e257cee5b0fc186f171df3dd63eb1279ba613f36ce9d2f294ec76bb053612cf0b1 5ec05796240de640e0afbc28fc12a1f24
id : 950 / nom : GameMapMovementRequestMessage / lenType : 1 / lenData : 0 /

02d9 000000a7 01 01
id : 182 / nom : BasicPingMessage / lenType : 1 / lenData : 0

58d5 000000b1 01 16
id : 5685 / nom : EmotePlayRequestMessage / lenType : 1 / lenData : 0

02d9 000000b7 01 01
04:55:38 / id : 182 / nom : BasicPingMessage / lenType : 1 / lenData : 0

62b5 000000bc 02 0002
04:55:45 / id : 6317 / nom : SequenceNumberMessage / lenType : 1 / lenData : 0
--------

J'en conclu donc que c'est ces blocs restants en rouge qui posent problème :
Je ne sais pas du tout ce que ça viens faire ici (peut être un protocol ?) et c'est pourquoi j'aimerai avoir de l'aide.
Merci d'avance !
 
Dernière édition:

BlueDream

Administrateur
Membre du personnel
Inscrit
8 Decembre 2012
Messages
2 010
Reactions
149
#3
Fort probable sinon c'est leur HASH_FUNCTION à la con.

Code:
public function writePacket(param1:ICustomDataOutput, param2:int, param3:ByteArray) : void
      {
         var _loc5_:uint = 0;
         var _loc6_:uint = 0;
         var _loc4_:uint = computeTypeLen(param3.length);
         param1.writeShort(subComputeStaticHeader(param2,_loc4_));
         param1.writeUnsignedInt(this._instance_id);
         switch(_loc4_)
         {
            case 0:
               return;
            case 1:
               param1.writeByte(param3.length);
               break;
            case 2:
               param1.writeShort(param3.length);
               break;
            case 3:
               _loc5_ = param3.length >> 16 & 255;
               _loc6_ = param3.length & 65535;
               param1.writeByte(_loc5_);
               param1.writeShort(_loc6_);
               break;
         }
         param1.writeBytes(param3,0,param3.length);
      }
 
Inscrit
20 Juin 2016
Messages
41
Reactions
2
#4
Dans mes souvenirs la hash fonction est à la fin
 

BlueDream

Administrateur
Membre du personnel
Inscrit
8 Decembre 2012
Messages
2 010
Reactions
149
#5
Le HASH_FUNCTION chiffre toutes les données et il s'applique sur le BasicLatencyStatsMessage et le GameMapMovementRequestMessage.

Code:
override public function pack(param1:ICustomDataOutput) : void
      {
         var _loc2_:ByteArray = new ByteArray();
         this.serialize(new CustomDataWrapper(_loc2_));
         if(HASH_FUNCTION != null)
         {
            HASH_FUNCTION(_loc2_);
         }
         writePacket(param1,this.getMessageId(),_loc2_);
      }
Voici la liste des paquets concernés:

 
Inscrit
10 Mai 2015
Messages
357
Reactions
55
#6
Ce n'est pas le Hash_function car si vous aviez essayé de comprendre son fonctionnement, il n'influence en rien la lecture du packet car il effectue un Hash du packet et l'ajoute packet après l'écriture du packet. Donc mis à part être utile au serveur pour voir si tu envoies le Hash il ne sert à rien.
 

BlueDream

Administrateur
Membre du personnel
Inscrit
8 Decembre 2012
Messages
2 010
Reactions
149
#7
Certes mais la on ne cherche pas à l'appliquer mais juste à comprendre si je ne me trompe pas :p
 

Labo

Membre Actif
Inscrit
16 Aout 2013
Messages
799
Reactions
15
#8
C'est etrange, tous les messages de @Towzeur ne sont pas dans la liste de @BlueDream.
En plus, dans le premier, l'en-tete bizarre a pas un nombre entier d'octets, mais c'est peut-etre une erreur de sa part.
 
Inscrit
19 Juillet 2017
Messages
18
Reactions
1
#9
Merci à tous pour vos réponses !

@Labo pour le premier exemple, je l'avais aussi remarquer mais je pense qu'il s'agit effectivement d'une erreur de ma part.

À défaut d'avoir identifier l'origine de ces paquet j'ai trouver une solution temporaire.

D'après mes observations, ces octets viennent au nombre de 4 après la lendata (et toujours avec des 00 au debut)

quand je lis une lenData différente de 0 et que la lenData vaut 0, je décale de 4-lenType pour sauter tous ces bytes gênants)

Code en Python :

Python:
if self.lenType != 0:

    self.lenData = int.from_bytes(self.buffer.read(self.lenType), byteorder='big', signed=False)

    if self.lenData == 0: # si on a le pb
        self.buffer.reset(4 - self.lenType)
        self.lenData = int.from_bytes(self.buffer.read(self.lenType), byteorder='big', signed=False)
Après plusieurs test cette solution semble posée aucun problème :

http://prntscr.com/g1o7q2
 
Dernière édition:
Inscrit
19 Juillet 2017
Messages
18
Reactions
1
#10
Nouveau message pour conclure le topic et pour apporter la solution aux lecteurs qui auraient le même 'soucis' on sait jamais.
(Merci à Arth pour son aide sur discord)

dans le fichier NetworkMessage
Code:
public function writePacket(param1:ICustomDataOutput, param2:int, param3:ByteArray) : void
      {
         var _loc5_:uint = 0;
         var _loc6_:uint = 0;
         var _loc4_:uint = computeTypeLen(param3.length);
         param1.writeShort(subComputeStaticHeader(param2,_loc4_));
         param1.writeUnsignedInt(this._instance_id);
         switch(_loc4_)
         {
            case 0:
               return;
            case 1:
               param1.writeByte(param3.length);
               break;
            case 2:
               param1.writeShort(param3.length);
               break;
            case 3:
               _loc5_ = param3.length >> 16 & 255;
               _loc6_ = param3.length & 65535;
               param1.writeByte(_loc5_);
               param1.writeShort(_loc6_);
         }
Il faut donc lire un UnsignedInt lors de la réception de paquet du client et pour tenir à jour ce nombre il faut l'incrémenter
lors de la réception de paquet du serveur.
 

neross

Membre Actif
Inscrit
20 Decembre 2014
Messages
150
Reactions
0
#11
Nouveau message pour conclure le topic et pour apporter la solution aux lecteurs qui auraient le même 'soucis' on sait jamais.
(Merci à Arth pour son aide sur discord)



dans le fichier NetworkMessage
Code:
public function writePacket(param1:ICustomDataOutput, param2:int, param3:ByteArray) : void
      {
         var _loc5_:uint = 0;
         var _loc6_:uint = 0;
         var _loc4_:uint = computeTypeLen(param3.length);
         param1.writeShort(subComputeStaticHeader(param2,_loc4_));
         param1.writeUnsignedInt(this._instance_id);
         switch(_loc4_)
         {
            case 0:
               return;
            case 1:
               param1.writeByte(param3.length);
               break;
            case 2:
               param1.writeShort(param3.length);
               break;
            case 3:
               _loc5_ = param3.length >> 16 & 255;
               _loc6_ = param3.length & 65535;
               param1.writeByte(_loc5_);
               param1.writeShort(_loc6_);
         }
Il faut donc lire un UnsignedInt lors de la réception de paquet du client et pour tenir à jour ce nombre il faut l'incrémenter
lors de la réception de paquet du serveur.
Et le merci a BlueDream qui ta donner la solution a ton problème dans la deuxième réponse que tu a reçus ... ??? ... ????
 
Inscrit
19 Juillet 2017
Messages
18
Reactions
1
#12
Ouip, excusez mon impolitesse.
Merci à IceRhal , BlueDream, Brizze et Labo pour leurs aides également !
 
Inscrit
20 Juin 2016
Messages
41
Reactions
2
#13
Il faut donc lire un UnsignedInt lors de la réception de paquet du client et pour tenir à jour ce nombre il faut l'incrémenter
lors de la réception de paquet du serveur.
J'ai pu remarquer que l'incrémentation (à vérifier) se faisait pas à chaque réception / envoie de paquet (les NetworkMessage) mais plutôt à chaque réception de séquence TCP (en gros chaque paquet de donnée pouvant contenir plusieurs NetworkMessage)
 
Haut Bas