Forum général.général Port série et rétro ingénierie.

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
6
6
nov.
2017

Bonjour.
Ayant aujourd'hui un statut de «trouveur de solution originales» en milieux professionnel, on viens de me donner un défi plutôt intéressant à relever, mais sur le quel j'ai aujourd'hui quelques soucis.

Le problème

Nous avons aujourd'hui des armoires à clef électroniques pouvant à la demande délivrer, suivre et réceptionner des clefs. L'armoire communique en série (RS232) avec un ordinateur sur le quel tourne un logiciel (propriétaire et au coût de licence non négligeable) de gestion avancé.

L'idée essentielle serais de pouvoir remplacer toute la partie gestion par quelque chose de plus simple et moins couteux (et si je peu faire plus libre au passage, ça m'arrangerais bien)

J'ai utilisé l'utilitaire «Port Mon» sous Windows pour analyser les trames série entre le logiciel de gestion et le logiciel d'origine, le tout me semblant assez simple et logique.

Gnu/Linux en série

Un peu trop jeune dans le domaine de l'informatique pour avoir massivement bidouillé ces bon vieux ports série, je ne sais pas comment faire pour tester, manuellement, le bout de protocole sur le quel je joue aux devinettes.

Comment faire pour envoyer des trames à cette armoire communiquant en série, et pour recevoir ces réponses ?

Quelle sont les bonnes méthodes pour faire de la rétro-ingénierie sur un protocole série ?

Les quelques méthodes que j'ai essayé jusque ici n'ont rien donné. Mais je suis sur de manquer de bases dans ces domaines.

  • # GtkTerm ?

    Posté par  (site web personnel, Mastodon) . Évalué à 5. Dernière modification le 06 novembre 2017 à 16:11.

    avec un logiciel de terminal série on peut discuter sur un RS-232.
    J'utilise gtkterm pour configurer des switch et routeurs via le port série
    Après une fois que tes commandes fonctionnent tu peut scripter ça avec du python (pyserial)

  • # /dev/ttyS[0-9]

    Posté par  . Évalué à 1.

    Sous unix tout est fichier.

    Ton port série est accessible via un fichier de périphérique /dev/ttyS#. A toi de déterminer lequel si tu en as plusieurs.

    Tu veux envoyer des données dans le port série => tu écris dans ce fichier (avec la commande echo par exemple)
    Tu veux lire les données récupérées => tu lis ce fichier (avec la commande cat par exemple)

    Ca devient un peu plus complexe si ton port série doit utiliser une configuration particulière (vitesse d'envoi, caractères de contrôle), auquel cas il va falloir utiliser la commande stty pour modifier ces paramètres. Mais le principe reste le même.

    Il y a sans doute des utilitaires qui peuvent faire le job plus facilement. Essaie de regarder du côté de socat par exemple.

    • [^] # Re: /dev/ttyUSB0

      Posté par  (site web personnel) . Évalué à 2.

      C'est effectivement la technique que j'avais utilisé, sans grand succès.
      # echo "Bonjour" > /dev/ttyUSB0
      # cat /dev/ttyUSB0

      Le «Echo» ne renvoyais rien (mais ne semblais pas non plus faire réagir le matériel)
      Le «Cat» lançais la commande et laissais une ligne vide sans me rendre la main.

      L'adaptateur USB / RS232 que j'utilise pourrais il être en cause ? (j'ai fait mes quelques essais avec un ordinateur portable récent)

      Je doit avouer que j'ai laissé les paramètres par défaut sur le port série (mais je ne sais pas vraiment ou trouver la bonne configuration à adopter).

      J'essayerais «socat».

      • [^] # Re: /dev/ttyUSB0

        Posté par  . Évalué à 5.

        la commande echo a envoyé ton "Bonjour" sur le port USB0
        si la machine n'est pas censé reagir au mot "Bonjour" il ne se passera rien de plus

        d'ailleurs tu n'ecoutes meme pas sur le port pour recuperer la reponse.

        il te faut un logiciel pour dialoguer de maniere interactive avec ton port USB,
        en ligne de commande, il y a le tres classique minicom
        qui demande de connaitre quelques raccourcis clavier mais qui est alors tres efficace

        sinon les logiciels cités par d'autres me semble une bonne idée (GtkTerm, Putty, etc)

        • [^] # Re: /dev/ttyUSB0

          Posté par  (site web personnel, Mastodon) . Évalué à 3.

          Voilà, 'minicom' est ton ami (c'est le premier nom qui m'a traversé l'esprit en lisant le message, mais il y en a d'autres ; l'idée étant que tu te connectes à une console en RS-232…)

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

          • [^] # Re: /dev/ttyUSB0

            Posté par  (site web personnel) . Évalué à 4.

            Perso, j'ai abandonnée minicom pour le microcom intégré à busybox. J'en avais assez de ne pas avoir le contrôle sur le défilement dans mon terminal. Dans un terminal comme gnome-terminal, qui me donnait entière satisfaction, impossible d'utiliser la barre de défilement pour lire des traces plus haut. Microcom ne fait que le nécessaire, et délègue tout le reste à gnome-terminal. Je peux donc faire du Ctrl+Shift+F pour chercher dans les traces à l'écran.

                microcom [-d DELAY] [-t TIMEOUT] [-s SPEED] [-X] TTY

    Copy bytes for stdin to TTY and from TTY to stdout

    Options:

            -d      Wait up to DELAY ms for TTY output before sending every
                    next byte to it
            -t      Exit if both stdin and TTY are silent for TIMEOUT ms
            -s      Set serial line to SPEED
            -X      Disable special meaning of NUL and Ctrl-X from stdin

            Source: https://busybox.net/BusyBox.html

  • # pyserial?

    Posté par  . Évalué à 6.

    Pour ce genre de cas, écrire un petit script Python en utilisant pyserial est en général relativement facile ;-)

  • # socat

    Posté par  . Évalué à 5.

    Pour des tests simples, avec socat : socat - /dev/ttyS0,raw,echo=0,crnl

    Et pour des tests compliqués, ça fonctionne aussi :) Il suffit de scripter.

    • [^] # Re: socat

      Posté par  . Évalué à 5.

      À savoir que c'est aussi utile pour debugguer, vu que ça peux jouer le rôle d'un sniffer du coup. Hors, ici, on pourrais imaginer une machine avec 2 ports série: un avec le produit propriétaire, l'autre avec le hard, on pilote le hard à partir du proprio, on intercepte les trames et hop, le tour est joué.
      Enfin, il faudrait jouer un peu avec socat, tee et les dumps, mais c'est plus simple que chercher à deviner à partir de fuzzing.

      Le seul problème est que la sortie est brute, et que les convertisseurs que je connais (hd et od) attendent soit d'avoir assez de données, soit un retour chariot… faudrait que j'en implémente un, un jour, me serait utile au taf.

  • # cat + echo ou minicom

    Posté par  (site web personnel) . Évalué à 3.

    Comme dit rien plus haut, la commande cat ne t'affichera que ce que l'armoire te répondra. De plus, je suis suis pas sur que les données reçues soient gardées en mémoire longtemps.
    Je recommande de lancer la commande 'cat' en premier dans un terminal puis d'envoyer tes commandes avec echo depuis un autre terminal. Je pense que lancer 'cat /dev/ttyUSB0 &' puis tes commandes echo pourrait marcher…

    Il faut noter que de cette manière, tu ne configure pas ton port série. Pour cela, il faut lancer la commande stty.

    Le plus simple, c'est vraiment d'utiliser un outil graphique type Minicom. De mon côté, je recommande Cutecom qui ressemble beaucoup à l'hyperterminal de Windows en juste mieux.

  • # allez !

    Posté par  . Évalué à 3.

    bon comme personne ne parle de ce qui est important en port serie, je le fais !!

    il faut les même réglages de transmissions des 2 cotés, ce qui se fait très simplement avec : setserial

    sinon ca a l'air cool comme projet :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.