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

Bytes en trop dans mes paquets

Towzeur

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 !

IceRhal

L'instanceid ?

Towzeur

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)

IceRhal
L'instanceid ?

dans le fichier NetworkMessage

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.

BlueDream

Fort probable sinon c'est leur HASH_FUNCTION à la con.


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);
      }

IceRhal

Dans mes souvenirs la hash fonction est à la fin

BlueDream

Le HASH_FUNCTION chiffre toutes les données et il s'applique sur le BasicLatencyStatsMessage et le GameMapMovementRequestMessage.

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:

[Image Introuvable] Loading Image

Brizze

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

Certes mais la on ne cherche pas à l'appliquer mais juste à comprendre si je ne me trompe pas :p

Labo

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.

Towzeur

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 :


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

neross

Towzeur

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

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 ... ??? ... ????

IceRhal

Towzeur
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)

Towzeur

Ouip, excusez mon impolitesse.

Merci à IceRhal , BlueDream, Brizze et Labo pour leurs aides également !