Trame TCP
cs_Myke
Messages postés
138
Date d'inscription
mercredi 5 février 2003
Statut
Membre
Dernière intervention
2 février 2010
-
23 sept. 2008 à 03:43
cs_Megafan Messages postés 389 Date d'inscription dimanche 7 avril 2002 Statut Membre Dernière intervention 23 septembre 2016 - 2 oct. 2008 à 14:12
cs_Megafan Messages postés 389 Date d'inscription dimanche 7 avril 2002 Statut Membre Dernière intervention 23 septembre 2016 - 2 oct. 2008 à 14:12
4 réponses
cs_Myke
Messages postés
138
Date d'inscription
mercredi 5 février 2003
Statut
Membre
Dernière intervention
2 février 2010
23 sept. 2008 à 03:53
23 sept. 2008 à 03:53
Je galère depuis quelques temps
Je voudrais récuperer les informations d'une trame TCP/IP. Ce que je ne comprends pas c'est les types de données qu'il faut utiliser. Je regarde le RFC du TCP et il me dit que le port source est codé sur 16 bits (2 octet) . J'utilise donc une variable int16 et j'utilise la fonction Me._PortSource = BitConverter.ToInt16(RawBuffer, MyPtrBegin). J'ai ensuite tenté de reorganiser les octet(bytes) avec une fonction BigEndian to Little endian et cela ne fonction toujours pas. Je suis à la bonne position dans le buffer.
J'ai regarder quelques exemples ici. Comme exemple recuperation du numero de sequence la RFC TCP indique 32 bits mais la variable est déclaré long sinon cause un overflow.
Quelques connait-il les réponses à ces question ? Car les quelques un que j'ai essayé retourne des informations éronnés quand je l'ai ai comparé avec d'autres sniffer !
Myke
Je voudrais récuperer les informations d'une trame TCP/IP. Ce que je ne comprends pas c'est les types de données qu'il faut utiliser. Je regarde le RFC du TCP et il me dit que le port source est codé sur 16 bits (2 octet) . J'utilise donc une variable int16 et j'utilise la fonction Me._PortSource = BitConverter.ToInt16(RawBuffer, MyPtrBegin). J'ai ensuite tenté de reorganiser les octet(bytes) avec une fonction BigEndian to Little endian et cela ne fonction toujours pas. Je suis à la bonne position dans le buffer.
J'ai regarder quelques exemples ici. Comme exemple recuperation du numero de sequence la RFC TCP indique 32 bits mais la variable est déclaré long sinon cause un overflow.
Quelques connait-il les réponses à ces question ? Car les quelques un que j'ai essayé retourne des informations éronnés quand je l'ai ai comparé avec d'autres sniffer !
Myke
cs_Megafan
Messages postés
389
Date d'inscription
dimanche 7 avril 2002
Statut
Membre
Dernière intervention
23 septembre 2016
2
23 sept. 2008 à 10:30
23 sept. 2008 à 10:30
Salut,
Regarde dans mes sources, j'ai fait un sniffer réseau, toutes les trames TCP sont decryptées.
@+
Megafan
Regarde dans mes sources, j'ai fait un sniffer réseau, toutes les trames TCP sont decryptées.
@+
Megafan
cs_Myke
Messages postés
138
Date d'inscription
mercredi 5 février 2003
Statut
Membre
Dernière intervention
2 février 2010
23 sept. 2008 à 16:21
23 sept. 2008 à 16:21
Megafan
C'est dans ta source que s'adresse la deuxieme question dans ce cas ! Le NumSeq est declaré long quand la RFC indique que cela prend 32 bits. Pouquoi on ne peut dans ce cas déclaré une variable sur 32 bits comme int32 ?
Myke
C'est dans ta source que s'adresse la deuxieme question dans ce cas ! Le NumSeq est declaré long quand la RFC indique que cela prend 32 bits. Pouquoi on ne peut dans ce cas déclaré une variable sur 32 bits comme int32 ?
Myke
cs_Megafan
Messages postés
389
Date d'inscription
dimanche 7 avril 2002
Statut
Membre
Dernière intervention
23 septembre 2016
2
2 oct. 2008 à 14:12
2 oct. 2008 à 14:12
Myke > oui int32 c'est mieux, long c'est une vielle mauvaise habitude du vb6.
