Surveiller, sniffer, déboguer et enregistrer le port série

Sur cette page, vous apprendrez trois méthodes pour analyser la communication série entre les appareils (PC, contrôleurs, cartes embarquées) et pourquoi Le COM Sniffer de SerialTool est souvent la meilleure solution : uniquement logicielle, sans câblage, transparente, et adaptée à une utilisation en surveillance/sniffing/débogage/enregistrement même pendant plusieurs jours.

Ce que vous trouverez

  • Chapitre 1 : ce que signifie surveiller un port COM, comment les octets/bits sont structurés et comment la transmission série les envoie (start/data/parité/stop), plus TX/RX et le débit baud.
  • Chapitre 2 : la méthode classique de sniffing physique avec deux adaptateurs USB↔série : connectez uniquement le RX aux lignes TX des deux appareils et partagez les masses. Parfait pour un simple surveillant/enregistreur.
  • Chapitre 3 : le même concept appliqué à un PC Maître communiquant avec un Périphérique Cible via des convertisseurs USB↔série/RS-232/RS-485 (même protocole, différents niveaux physiques). Comprend un aperçu de Modbus RTU/ASCII et des cas d'usage industriels/CNC/embarqués (débogage, firmware, reverse engineering).
  • Chapitre 4 : pourquoi il est souvent avantageux d'utiliser le COM Sniffer de SerialTool : un surveillant de port série basé sur un pilote noyau Windows qui intercepte les données, les IOCTL, les signaux, et les paramètres des ports déjà ouverts par d'autres logiciels. Aucun câble, filtres précis, export vers pcap/pcapng (par ex., pour Wireshark), et stabilité pour les captures longues.

Si votre objectif est d'analyser rapidement un logiciel tiers ou de surveiller continuellement votre application, commencez par le Chapitre 4 – COM Sniffer : c'est la façon la plus rapide de surveiller, sniffer, déboguer et enregistrer sans construire un banc d'essai.

Chapitre 1 – Surveillance des données du port COM

1.1 Ce que signifie "surveiller un port série"

Surveiller un port COM (série) signifie observer en temps réel les octets circulant sur les lignes de communication entre le PC et l'appareil. Lors de la surveillance, nous distinguons typiquement les deux directions : TX (transmission du PC vers l'appareil) et RX (réception de l'appareil vers le PC). Un bon surveillant affiche les données à la fois sous forme de texte (interprétation ASCII/UTF-8) et hexadécimale (HEX), c'est-à-dire les octets bruts.

À quoi ça sert
  • Vérifier que TX et RX se produisent avec les paramètres corrects (baud, bits de données, parité, stop).
  • Comprendre ce qui est envoyé/répondu, octet par octet, même lorsque le texte n'est pas lisible.
  • Diagnostiquer des erreurs de configuration ou de protocole (par ex., Modbus/RTU, commandes propriétaires, etc.).

1.2 Octets et bits : représentation logique vs transmission série

Lorsque nous écrivons le texte Hello, les cinq caractères sont convertis en cinq octets ASCII : 48 65 6C 6C 6F en hexadécimal. Un visualiseur d'octets comme celui de SerialTool vous permet de voir la forme d'onde logique des bits individuels within chaque octet.

Forme d'onde des bits pour la chaîne 'Hello' (vue logique dans le Visualiseur d'Octets de SerialTool)

Figure 1 — Représentation « logique » des bits pour Hello

Chaque boîte met en évidence un octet (0x48, 0x65, 0x6C, 0x6C, 0x6F). Sous chaque octet, vous trouverez ASCII, HEX, décimal et binaire. Cette vue est utile pour comprendre le contenu des octets tels qu'ils sont stockés et traités par le logiciel.

Comment lire les octets dans la vue logique

  • Le graphique met en évidence 8 bits de données pour chaque octet (b7…b0). En mémoire, nous pouvons les lister comme MSB→LSB (bit de poids fort à bit de poids faible).
  • Cette représentation n'inclut pas encore les éléments du protocole série (start, parité, stop) et ne reflète pas l'ordre de transmission sur le fil.

Comment les octets sont transmis sur le port série

Sur la ligne physique RS-232/TTL, chaque octet est encapsulé selon la trame série :

Start (1 bit, logique "0")Data (7/8 bits, envoyés LSB-first)Parité (optionnelle)Stop (1 bit ou plus, logique "1").

  • Repos : la ligne TX est stable à l'état logique "1" (marque). Ainsi, le signal reste à 1 jusqu'à l'arrivée du bit de Start.
  • Bit de Start : une transition vers "0" (espace) signale le début de l'octet.
  • Bits de données : les bits de données sont transmis dans l'ordre LSB-first (bit de poids faible en premier).
  • Bit de Stop : retour à "1" pour 1 bit ou plus ; assure le retour à l'état de repos.
  • Débit baud : détermine la durée de chaque bit (par ex., à 9600 baud, chaque bit dure ~104,17 µs).
Forme d'onde des bits pour la chaîne 'Hello' (vue logique dans le Visualiseur d'Octets de SerialTool)

Figure 2 — Les mêmes octets Hello sous forme de trames série sur la ligne : pour chaque octet, vous pouvez voir repos → start → data (LSB first) → stop

Cette vue met en évidence l'ordre de transmission et la temporisation fixe des bits imposée par le débit baud.

Note sur RS-232 vs. TTL

  • Au niveau TTL (UART à 3,3 V/5 V), "1" est haut et "0" est bas.
  • Au niveau RS-232, les niveaux de tension sont inversés (logique "1" ≈ tension négative, logique "0" ≈ tension positive), mais la séquence start/data/stop reste identique.

Exemple rapide : temps de transmission de "Hello"

Avec une configuration 8N1 (1 start, 8 data, 1 stop), chaque octet utilise 10 bits sur la ligne. À 9600 baud, cela fait ~960 octets/s. Pour 5 octets ("Hello"), cela prend ~5,21 ms.

Chapitre 2 – Surveiller/sniffer, déboguer et enregistrer une communication série avec deux adaptateurs USB-série

Câblage physique pour sniffer une communication série avec deux adaptateurs USB-série

Diagramme de branchement passif matériel

Le PC ouvre deux ports (COM5 et COM6). Chaque adaptateur USB-série utilise seulement RX pour « écouter » ce que chaque appareil transmet. Les masses (GND) sont communes. Les lignes violette et bleue représentent la connexion TX↔RX normale entre les deux appareils.

2.1 Objectif

Créer un surveillant/sniffer série non intrusif pour observer, déboguer et enregistrer les octets échangés entre Appareil 1 et Appareil 2 sans interrompre leur communication.

2.2 Connexions électriques (branchement passif)

  • COM5 (USB-série #1) : connectez la broche RX de l'adaptateur au TX de l'Appareil 1 (sniffer les données envoyées par l'Appareil 1).
  • COM6 (USB-série #2) : connectez la broche RX de l'adaptateur au TX de l'Appareil 2 (sniffer les données envoyées par l'Appareil 2).
  • GND commun : connectez la masse des deux adaptateurs USB-série à celle des deux appareils (référence commune pour les niveaux logiques).
  • Ne connectez pas le TX des adapteurs au bus : nous restons en mode "écoute seule" à haute impédance, donc nous ne perturbons pas la ligne.
  • N'alimentez pas les appareils depuis le 5V/3.3V des adaptateurs (VCC non utilisé dans le tapping).

Note sur les niveaux : cette méthode s'applique à l'UART/TTL (3,3/5 V) ou aux bus avec des pilotes compatibles. Pour le RS-232 (±12 V), ne connectez pas directement une entrée RX TTL : vous avez besoin d'un convertisseur RS-232↔USB ou d'un tap/moniteur RS-232 dédié. En d'autres termes, si vous voulez enregistrer une ligne RS-232, utilisez le matériel approprié.

2.3 Trouver et régler le débit baud

Pour décoder correctement les données, le débit baud et les paramètres doivent correspondre à ceux des appareils (par ex., 9600/8N1). S'ils sont inconnus :

  • Consultez la documentation de l'appareil ou du protocole.
  • Essayez les débits baud les plus courants (9600, 19200, 38400, 57600, 115200...).
  • Mesurez avec un oscilloscope/analyseur logique : la durée d'un bit est Tbit=1/baud (par ex., à 9600 baud ≈ 104,17 µs par bit).

2.4 Ouvrir les deux ports COM avec SerialTool

  1. Connectez les adaptateurs : le système verra deux ports (dans cet exemple COM5 et COM6).
  2. Dans SerialTool, ouvrez deux sessions :
    • Session A → COM5, réglez baud/parité/stop comme les appareils (par ex., 115200/8N1).
    • Session B → COM6, mêmes paramètres que la Session A.
  3. Mettez les deux en mode surveillance (RX seulement) : sur COM5, vous verrez les octets envoyés par l'Appareil 1 et sur COM6 ceux de l'Appareil 2.
  4. Pour le débogage, utilisez la vue HEX et les horodatages ; pour l'enregistrement, sauvegardez dans un fichier (CSV/pcap/brut) pour une analyse ultérieure.

Dans ce scénario, vous agissez comme un homme du milieu physique passif : vous surveillez/sniffez les données électriquement sans altérer les signaux.

2.5 Broches de contrôle exclues dans cet exemple

Le diagramme se concentre sur les données TX/RX et ne surveille pas les broches de contrôle (par ex., RTS/CTS, DTR/DSR, DCD, RI). Pour de nombreuses applications, elles sont inutiles ; cependant, si les appareils utilisent un contrôle de flux matériel, vous voudrez peut-être "tapper" ces lignes avec des sondes dédiées.

Pour aller plus loin : RS-232 (Wikipedia), RS-232 – Signaux, Contrôle de flux matériel, UART.

2.6 Conseils pratiques pour un surveillant/sniffer stable

  • Utilisez des câbles courts et une masse commune solide ; évitez les boucles de masse.
  • La plupart des pilotes UART tolèrent deux entrées RX (fan-out) sur une ligne TX, mais évitez une charge inutile.
  • Alignez toujours les paramètres des ports entre les deux sessions (baud, data, parité, stop).
  • Pour le RS-485 ou les bus différentiels, vous avez besoin d'adaptateurs spécifiques et de règles de tapping différentes.

Avec cette technique, vous pouvez surveiller, sniffer, déboguer et enregistrer de manière fiable les communications série entre deux appareils en utilisant des outils courants : deux adaptateurs USB-série + SerialTool.

Chapitre 3 – Sniffing/surveillance de la liaison série entre « PC Maître » et « Périphérique Cible »

Sniffing de la communication entre un PC Maître et un Périphérique Cible avec deux adaptateurs USB-série sur un second PC

Communication entre un appareil matériel et un PC via une liaison série

Le PC Maître (à droite) communique avec le Périphérique Cible par l'intermédiaire d'un Dispositif de Communication Série (généralement un convertisseur USB↔Série : UART/TTL, RS-232 ou RS-485). Le PC de Sniffing (à gauche) ouvre deux ports (COM5 et COM6) et, avec deux adaptateurs USB-série, écoute passivement les lignes : sur COM5, connectez RX au TX du Périphérique, sur COM6, connectez RX au TX du PC. Les masses (GND) sont communes.

3.1 But et concepts

Nous voulons surveiller et sniffer les octets circulant entre le logiciel sur le PC Maître et le Périphérique Cible, sans interférer avec la communication. C'est un typique homme du milieu physique passif : deux adaptateurs USB-série connectés uniquement en RX "lisent" chaque direction. Ceci est utile pour le débogage, l'analyse de protocole et comme enregistreur pour l'audit ou la rétro-ingénierie.

3.2 Connexions (étape par étape)

  1. COM5 (PC de Sniffing) → connectez le RX de l'adaptateur au TX du Périphérique (écoutez ce que la Cible envoie).
  2. COM6 (PC de Sniffing) → connectez le RX de l'adaptateur au TX du PC (écoutez les commandes du PC Maître).
  3. GND commun entre les deux adaptateurs et les deux appareils (référence partagée).
  4. Ne connectez pas le TX des adaptateurs du PC de Sniffing : nous restons en mode écoute seule (haute impédance), sans perturber la ligne.

Dans SerialTool, ouvrez deux sessions : COM5 et COM6. Dans les deux, réglez le débit baud et le format identiques à ceux utilisés par le Maître/le Périphérique (par ex., 115200-8N1). Si vous ne connaissez pas le débit baud, essayez les valeurs courantes ou mesurez la durée du bit avec un oscilloscope/analyseur logique.

3.3 Même protocole, niveaux différents : UART/TTL, RS-232, RS-485

Le protocole série asynchrone (start, 7/8 bits de données envoyés LSB-first, parité optionnelle, 1+ stop) est le même. Seul le niveau physique sur lequel les bits voyagent change :

  • UART/TTL (3,3 V/5 V) : signaux asymétriques, "1" haut / "0" bas.
  • RS-232 : niveaux de tension inversés et ± (généralement ±3…±12 V), toujours asymétriques.
  • RS-485 : différentiel sur une paire A/B, souvent demi-duplex multi-drop ; une masse de référence commune est recommandée.

Utilisez donc l'adaptateur correct : USB↔TTL pour UART, USB↔RS-232 pour RS-232, USB↔RS-485 pour RS-485. La trame reste identique, mais les niveaux électriques et la topologie (différentiel/terminaison) diffèrent.

3.4 Où est-ce utilisé (CNC, industriel, etc.)

Cette configuration est courante en CNC, dans les machines industrielles, les automates/IHM, la robotique, les balances, les TPV, les capteurs, les instruments, la GTC, et en général tout système où un PC/automate contrôle un appareil via une liaison série. La méthode de sniffing décrite ici vous permet de surveiller/sniffer/déboguer/enregistrer le trafic pour l'analyse fonctionnelle, le diagnostic de panne, le traçage des commandes et la validation.

3.5 Modbus sur série

Les ports série transportent souvent Modbus RTU/ASCII, un protocole maître/esclave (maintenant client/serveur) largement utilisé dans l'industrie. Le Maître envoie des requêtes (lecture/écriture de coils et de registres) et le Périphérique répond. SerialTool inclut un client Modbus pour interroger rapidement les registres (diagnostics et tests), ainsi qu'un surveillant/visualiseur hexadécimal utile pour voir les trames brutes (adresse, fonction, données, CRC).

3.6 Mise à jour du firmware et paramétrage

Dans le monde embarqué, la liaison série est largement utilisée pour les mises à jour de firmware ou la transmission de paramètres à la Cible. Exemples : bootloaders sur cartes personnalisées, écosystèmes comme Arduino, divers microcontrôleurs. Ici, un développeur peut avoir deux besoins :

  1. Déboguer l'application qui communique avec la Cible (vérifier les commandes, la temporisation, les erreurs).
  2. Faire de la rétro-ingénierie d'un protocole existant (il existe un logiciel Maître "fermé" parlant à une carte ; je sniff pour comprendre ses messages puis je les réplique avec mon propre logiciel).

3.7 Notes pratiques et outils

  • Cette configuration nécessite typiquement deux PCs (le Maître et le PC de Sniffing) et au moins deux convertisseurs USB-série pour un sniffing bidirectionnel.
  • Pour le RS-232, utilisez un tap/convertisseur RS-232 ; pour le RS-485, connectez une interface réception seule aux bornes A/B (en respectant la terminaison et la polarité). Sur RS-485 demi-duplex, vous déduirez la direction du contexte temporel.
  • Nous excluons les broches de contrôle (RTS/CTS, DTR/DSR, DCD, RI) ; si le système utilise un contrôle de flux matériel, envisagez des sondes dédiées.
  • Dans SerialTool, vous pouvez activer les vues HEX, les horodatages, et enregistrer en tant que logger (texte/CSV/pcap) pour une analyse ultérieure.

En bref : même protocole série (trames asynchrones), différents niveaux physiques (TTL/RS-232/RS-485). Avec un tapping passif à deux RX et un logiciel comme SerialTool, vous pouvez surveiller, sniffer, déboguer et enregistrer de manière fiable la communication entre un PC Maître et un Périphérique Cible.

Chapitre 4 – COM Sniffer : surveiller/sniffer/déboguer/enregistrer sans câblage physique

SerialTool COM Sniffer : surveiller un port série déjà ouvert par un logiciel, sans connexions physiques

COM Sniffer - Surveillant de Port Série

Avec SerialTool – COM Sniffer, vous n'avez pas besoin des connexions du Chap. 3 : le trafic entre le PC Maître (logiciel propriétaire tiers) et le Périphérique Cible est capturé directement par le système, de manière transparente et non intrusive.

4.1 Ce que fait COM Sniffer

COM Sniffer est un surveillant de port série qui intercepte la communication sur un port COM déjà ouvert par un autre programme, vous permettant de surveiller, sniffer, déboguer et enregistrer l'intégralité du trafic (TX/RX) sans toucher aux câbles, sans matériel supplémentaire et sans affecter le fonctionnement du PC Maître ou du Périphérique Cible.

4.2 Comment ça marche : pilote noyau

Le cœur est un pilote noyau pour Windows qui s'insère dans la pile des ports série et observe sélectivement :

  • Les tampons de données lus/écrits (TX ↔ RX) avec une séparation directionnelle claire ;
  • Les IOCTL (Contrôle Entrée/Sortie) : ouvertures/fermetures, réglages de baud/parité/stop, timeouts, signaux de contrôle (RTS/DTR/CTS/DSR/DCD/RI), etc. ;
  • Les événements/SIGNALS et l'état du port (état de ligne, état modem).

Le pilote est puissant mais l'interface est simple : vous pouvez filtrer par type (données uniquement, IOCTL de configuration uniquement, signaux uniquement, etc.) pour vous concentrer sur l'essentiel. Il est conçu pour des captures à long terme (heures/jours) de manière stable, pour surveiller votre application ou un tiers. Note : il fonctionne uniquement sur Windows car il s'appuie sur des pilotes en mode noyau.

4.3 Pourquoi c'est mieux (dans nombreux cas) que le câblage physique

  • Pas de "labo" avec deux PCs + deux USB-série : gagnez du temps et réduisez les points de défaillance.
  • Impact électrique nul : vous ne chargez pas les lignes, pas de risque de boucles de masse.
  • Voyez tout entre l'appli et le pilote : données, IOCTL, signaux, même sur plusieurs ports simultanément.

4.4 Enregistrement et export pour l'analyse de protocole

Vous pouvez enregistrer directement dans un fichier en tant que logger (texte/CSV) ou exporter vers pcap/pcapng pour analyse dans Wireshark. Ceci est extrêmement utile pour les protocoles industriels comme Modbus RTU/ASCII : avec les trames et les horodatages, vous pouvez valider la temporisation, le CRC, les séquences de fonctions, etc.

4.5 Ce que vous pouvez observer

  • Les données TX/RX séparément, en ASCII et HEX, avec horodatages ;
  • Les paramètres de port définis par le logiciel (baud, 7/8 bits, parité, stop, timeouts) ;
  • Les signaux de contrôle et les IOCTL (RTS, DTR, CTS, DSR, DCD, RI) et les changements d'état ;
  • Les événements d'ouverture/fermeture et les erreurs (dépassement, erreur de trame, parité).

4.6 Quand l'utiliser

  • Déboguer votre application série sans changer le code/le câblage ;
  • Surveillance à long terme d'applications tierces pour audit/diagnostics ;
  • Rétro-ingénierie de protocoles propriétaires (lorsque cela est légal) pour répliquer les fonctions avec votre propre logiciel ;
  • Validation de protocoles standard (par ex., Modbus) et des signaux de handshaking.

4.7 Notes et lectures complémentaires

COM Sniffer fonctionne au niveau système avec la logique du protocole série asynchrone (start/data/parité/stop). Si l'application utilise différents niveaux physiques (UART/TTL, RS-232, RS-485), la capture reste identique, car elle se produit au-dessus du niveau électrique, within la pile des ports COM Windows.

Liens utiles : Port série · UART · RS-232 · RS-485 · IOCTL · Pilotes noyau Windows · Wireshark · Modbus.

En bref : COM Sniffer de SerialTool est une solution « uniquement logicielle » pour surveiller, sniffer, déboguer et enregistrer un port série ouvert par d'autres programmes, avec un pilote noyau fiable, des filtres ciblés et l'export pour une analyse avancée.