Il y a aussi Sorcery, le gestionnaire de paquets de SourceMage Linux.
Je pense que cette fonctionnalité a été développé dans Sorcery et dans Portage car le temps d'attente est centuplé par la nécessité de compiler les paquets.
Une fois installé sur une machine, le système XtreemOS offre pour la grille ce qu'un système d'exploitation offre pour un seul ordinateur : abstraction du matériel et partage sécurisé des ressources entre les différents utilisateurs.
Cela ressemble furieusement à Plan 9 from Bell Labs.
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.
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.
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 ?
[^] # Re: Installation des paquets et des dépendances
Posté par Linschn . En réponse à la dépêche CUDF, ou la résolution de dépendances universelle. Évalué à 2.
Je pense que cette fonctionnalité a été développé dans Sorcery et dans Portage car le temps d'attente est centuplé par la nécessité de compiler les paquets.
# Plan 9 ?
Posté par Linschn . En réponse à la dépêche Sortie de XtreemOS 2.1. Évalué à 4.
Cela ressemble furieusement à Plan 9 from Bell Labs.
[^] # Re: Mise à jour
Posté par Linschn . En réponse au message Rétro ingénierie de logiciel propriétaire. Évalué à 2.
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.
[^] # Re: gdb, HT Editor
Posté par Linschn . En réponse au message Rétro ingénierie de logiciel propriétaire. Évalué à 2.
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 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.
# strace
Posté par Linschn . En réponse au message Rétro ingénierie de logiciel propriétaire. Évalué à 6.