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 ?
# Mise à jour
Posté par Linschn . En réponse au message Rétro ingénierie de logiciel propriétaire. Évalué à 1.
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.