Forum général.général Rétro ingénierie de logiciel propriétaire

Posté par  .
Étiquettes : aucune
6
17
mar.
2010
Bonjour à tous.

Je vous plante le décor :
Je travaille dans un laboratoire de recherche, sur un projet à moyen/court terme (quelques mois).

J'utilise un système embarqué.
Ce système fait tourner une distribution Linux.
Le logiciel qui permet d'exploiter les fonctionnalités de ce système embarqué est un logiciel propriétaire écrit par le constructeur du système.
Le constructeur du système est d'assez mauvaise volonté, il n'a pas encore publié les sources du Linux qu'il utilise, ne répond pas au demandes de clarification de sa licence (très restrictive), et présente lorsqu'on lui demande de l'aide ou de la documentation des délais qui font exploser les deadlines du projet.

J'ai besoin de disposer d'un accès bas niveau sur le système embarqué. Cela se résume grosso modo à deux types d'appels : get et set, sur les différents actuateurs et capteurs du système. Le fabricant ne fournit pas cet accès, et à mon avis ne le fournira pas de bonne grâce dans des délais raisonnables. Tous les accès au matériel se font via l'exécutable propriétaire qui tourne en permanence sur le système embarqué.

Je peux faire en sorte, via l'API du fabricant, que l'exécutable propriétaire exécute les requêtes get et set dont je parle plus haut. J'ignore tout de la rétro ingénierie, mais je me suis dit qu'un bon moyen de court circuiter l'exécutable du fabricant serait de lister les appels systèmes de celui-ci.

D'où ma question : est-il possible de tracer les appels systèmes effectués par un exécutable dont on ne possède pas le code source ?

  • # strace

    Posté par  . Évalué à 6.

    Depuis, j'ai appris l'existence de strace. Je vais voir ce que ça donne.

    • [^] # Re: strace

      Posté par  . Évalué à 10.

      Histoire de résoudre le problème à plus long terme, tu peux aussi faire le tour des softs sous GPL qu'il semble utiliser, et informer les développeurs ;+)

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

  • # gdb, HT Editor

    Posté par  . Évalué à 3.

    Parfois strace ne suffit pas, alors il faudra peut-être sortir gdb (en local ou à distance avec gdbserver sur la cible).
    HT editor permet de désassembler du ARM également.

    • [^] # Re: gdb, HT Editor

      Posté par  . Évalué à 2.

      Merci pour HT Editor, je ne connaissais pas. J'ai tenté d'utiliser dissy, mais cela n'a pas été d'une grande aide car je ne sais pas où se trouve la partie de code qui fait ce qui m'intéresse.
      J'ai vu passer des open sur des fichiers .so au cours de mes investigations d'aujourd'hui, je pense que si la piste ioctl ne donne rien, j'analyserai ces fichiers avec HT Editor.

  • # Mise à jour

    Posté par  . Évalué à 1.

    Voici une petite mise à jour quant à l'avancement des travaux :
    J'ai perdu beaucoup de temps car je pensais que déclencher une action du type : get capteur allait faire en sorte que l'exécutable propriétaire aille effectivement chercher la valeur.
    En réalité, il y a une boucle qui accède en quasi permanence au device file qui représente le pont usb vers les capteurs, et déclencher une action du type get capteur renvoie la valeur dès que la boucle a fini son exécution en cours.

    Le truc moche, c'est que toutes les communications avec le pont usb se font via l'appel système ioctl, qui à ce que j'ai compris est l'appel système poubelle, où l'on fourre tout ce qui n'a pu rentrer ailleurs. Pas pratique pour comprendre ce qu'il fait.

    Je n'arrive pas à déterminer quel driver gère le device file concerné.
    lsusb -v m'indique que le fabricant du périphérique est le fabricant du système embarqué. Jusque là tout va bien.
    udevinfo m'indique que le driver est usb, ce qui n'est pas très loquace.
    Parmi les modules chargés, il y a usbserial et ftdi_sio, peut-être une piste ?

    Où pensez-vous que je puisse trouver le code chargé de gérer ces appels à ioctl ?

    Le noyau apparaît comme non-tainted. Pensez vous qu'ils auraient quand même osé glisser un driver propriétaire dans le noyau ?

    Je continuerai mes investigations demain.

    • [^] # Re: Mise à jour

      Posté par  . Évalué à 3.

      un port USB ca reste une port SERIE...

      donc une fois le driver USB chargé, suffit d'avoir un programme qui va lire/ecrire sur le port "SERIE"

      pkoi voudrais-tu qu'il y ait un driver en PLUS du programme propriétaire ?

      • [^] # Re: Mise à jour

        Posté par  . Évalué à 2.

        Comme ce sont eux qui ont conçu la carte qui se cache derrière le port USB, je n'ai pas la moindre idée de comment ils la pilotent.
        J'ai remarqué la présence du module FTDI, peut-être l'utilisent-ils pour parler avec leur carte. Dans le cas contraire, comme je ne sais pas quel driver a créé le fichier de périphérique, j'imagine les autres possibilités.

        Quelqu'un sait-il comment je pourrais intercepter les communications entre leur programme et le périphérique ? Même si leur protocole est complètement cryptique, comme je sais quelles sont les valeurs qui doivent sortir, et comme je sais sur combien d'octets elles sont codées, j'ai peut-être une chance de comprendre deux/trois trucs.

Suivre le flux des commentaires

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