Reverse-engineerer le protocole du projecteur couleur ?
Posté le 12/05/2018 20:07
Cake m'a demandé de faire quelques tests pour reverse-engineerer le protocole utilisé par la Graph 90 pour le projecteur couleur. Ça demande un peu de travail et ça ne marche pas encore, mais il faut bien un topic pour garder les infos !
Niveau Wireshark
J'ai réussi à faire des captures de mon canal USB avec Wireshark, notamment d'un
p7screen sur la Graph 75+E ; Cake, si tu pouvais confirmer que ça correspond bien à tes connaissances du protocole 7, ce serait pas mal. J'ai vu des bulks de 1024 octets et des
TYP01 donc je suis confiant.
p7screen-fx9860g.pcapng (41 ko)
Niveau drivers
J'ai installé un configuré une machine virtuelle (Windows 7) sur laquelle j'ai installé le CG-Manager Plus, le Screen Receiver et FA-124. Le dernier fournit, comme à l'accoutumée, le driver CESG502. Cependant quand j'ai connecté la Graph 90 à VirtualBox, Windows a fait mine de chercher un driver CESG502 dans la base de données de Microsoft. Est-ce bien le même ?
Niveau résultats
Pas grand-chose pour l'instant, vraiment. FA-124 reconnaît ma Graph 35+ SH3 et ma Graph 75+E. Le Screen Receiver, qui est daté de 2013 (!), ne reconnaît ni rien ni personne, que je le démarre avant de connecter la machine ou après.
Voilà où j'en suis, c'est pas très loin encore mais donne un début pour travailler. Je vais essayer de chercher une version plus récente ou un manuel d'utilisation du Screen Receiver. Si tu as d'autres infos Cake, je suis preneur !
Citer : Posté le 12/05/2018 20:39 | #
Retournement de situation !
J'ai réussi à faire coopérer le Screen Receiver pour les deux modèles : la Graph 75+E et la Graph 90, en utilisant deux versions différentes dédiées. Le truc triste c'est que sur Graph 90 les add-ins ne sont pas compatibles par défaut avec le Screen Receiver donc on ne peut pas les voir à l’œuvre à l'écran.
Je n'ai pas encore de capture à présenter parce que visiblement VirtualBox « redirige » le flux USB et du coup je ne le vois plus sur les canaux de capture de Wireshark sous Linux. Je vais creuser un peu ça et au pire je ferai tourner Wireshark dans la machine virtuelle !
Ajouté le 12/05/2018 à 21:19 :
Okay, j'ai réussi à faire les captures ! En voilà deux.
La seconde est plus longue et comporte normalement la séquence d'initialisation, tandis que la première a été prise en plein milieu. Je recommande plutôt de tester la seconde.
Notez que ça fait lagger à la fois la calculatrice et le Screen Receiver de mettre Wireshark sur la connexion. Le soft a eu un mal fou à afficher peut-être 6 frames à l'écran de la machine virtuelle pendant la capture (qui a duré 90 secondes), mais je pense que les données pour tous les frames ont été envoyées à Wireshark.
Je connais pas trop le format, mais dans le précédent (tu peux me confirmer que c'est bien un Screen Receiver normal pour la Graph 75+E d'ailleurs ?) il y avait les habituels TYP01, là j'ai plutôt des USBS et USBC... j'espère que tout y est !
Je précise quand même que p7screen fonctionne avec le Projecteur tandis que mes captures sont issues exclusivement du Screen Receiver. Là encore, si je pouvais avoir des infos, ce serait pas de refus.
Allez enjoy, et on compte sur toi Cake !
Citer : Posté le 12/05/2018 21:44 | #
Pour répondre à tes interrogations :
J'ai installé un configuré une machine virtuelle (Windows 7) sur laquelle j'ai installé le CG-Manager Plus, le Screen Receiver et FA-124. Le dernier fournit, comme à l'accoutumée, le driver CESG502. Cependant quand j'ai connecté la Graph 90 à VirtualBox, Windows a fait mine de chercher un driver CESG502 dans la base de données de Microsoft. Est-ce bien le même ?
Je ne pense pas. C'est simplement que dans le paquet de mise en place (setup) en USB, il y a une foule d'informations concernant l'appareil, y compris un champ qui s'appelle iManufacturer (en USB, tout est désigné avec la notation hongroise) et qui mène à une chaîne de caractères dépendant du couple PID/VID, ou dans la norme USB, idVendor et idProduct. Ça doit être « CESG502 » pour les deux appareils mais ce n'est pas le même driver, mais je n'ai pas pu trouver la référence qu'utilise par exemple la libusb donc je ne saurais l'affirmer.
Je connais pas trop le format, mais dans le précédent (tu peux me confirmer que c'est bien un Screen Receiver normal pour la Graph 75+E d'ailleurs ?) il y avait les habituels TYP01, là j'ai plutôt des USBS et USBC... j'espère que tout y est !
Tu te demandais pourquoi tu trouvais ça via le chat, et à ça, j'ai une explication : parmi les informations de mise en place dont je parlais tout à l'heure, il y a également un champ de classe. En gros, c'est un champ qui désigne comment communiquer avec l'appareil (ou le « gadget » comme c'est appelé dans le noyau Linux si j'ai bien compris). On a deux cas pour nos chères calculatrices :
- pour la fx-9860G et dérivées, on a la classe « device specific », qui correspond au Protocole 7, et qui dit qu'en gros on s'échange les informations via des paquets Bulk ;
- pour la Prizm et dérivées, on a la classe « USB Mass Storage ».
Concernant ces dernières, on va utiliser du « Bulk Only Transport », en gros, du SCSI over USB. Pour ceux qui n'ont pas les bases en SCSI, en gros, ça fonctionne plus ou moins sur le modèle requête/réponse sur du Bulk :
- requête (command block, ou « CDB »), avec une quantité de données à transférer (pouvant être nulle) et la direction dans laquelle transférer ces données (hôte à l'appareil ou inversement) ;
- transfert de données sans réponse ;
- récupération d'un statut.
En USB, c'est alourdi un peu : la requête est mise dans un wrapper nommé « CBW » et dont le magic est « USBC » et le statut est mis dans un wrapper « CSW » dont le magic est « USBS ». Pour les données, je t'avoue que je ne sais pas encore bien comment c'est transféré comme ça ou non.
Ce système est connu par les utilisateurs, qui peut utiliser les commandes standard décrites ici, ce qui permet à tout PC qui supporte l'USB et suffisamment moderne pour connaître tout ça. Mais pour la Prizm, CASIO utilise des commandes dites « vendor-specific », autrement dit dans une zone prévue pour que les développeurs fassent ce qu'ils veulent, soit les commandes dont le code est supérieur ou égal à 0xC0.
De ce que j'ai compris, CASIO utilise ces commandes pour envoyer et recevoir des données arbitraire en utilisant un protocole particulier, probablement une évolution incompatible du Protocole 7 (de ce que j'avais trouvé jusque là ça ne différait que d'un octet). Et c'est ce qui est échangé sur ces commandes qui m'intéresse, et que j'espère trouver dans tes captures ! Donc merci de ta participation, et je regarde ça
Mon blog ⋅ Mes autres projets
Citer : Posté le 12/05/2018 21:58 | #
Oooh ! Je comprends pourquoi dans le cas de la Graph 90 les données brutes sont dans des packets SCSI: Data In et peu d'informations transitent dans les URB_BULK alors que pour la Graph 75+E tout passe par les bulks.
Tu m'apprends beaucoup de choses sur l'USB, merci !
Citer : Posté le 12/05/2018 22:49 | #
Je commence à explorer ce que tu as mis, et je remarque qu'il y a quelques trucs en plus (une souris sans fil par exemple). J'ai donc mis le filtre suivant dans Wireshark, qui a l'air de fonctionner pas trop mal :
Aussi, les commandes propriétaires sont documentées sur Cemetech.
Ajouté le 13/05/2018 à 01:48 :
Bon, donc effectivement, le paquet envoyé est de la forme :
J'ai strictement aucune idée de ce que sont les deux caractères '0' et '1' rajoutés, et pourquoi le ACK avec sous-type 0x02 (qui est normalement réservé à l'envoi de caractères) est envoyé. C'est un mystère pour moi, et pour BrandonW dans son code aussi : « I don't know, just go with it for now »
Là où il y a des choses bizarres par rapport à la commande 0xC0, c'est sur l'activité en AA AA et la signification que BrandonW lui donne. Tout d'abord, l'hôte a choisi d'envoyer des données avec la commande C2 alors que la calculatrice donnait un champ d'activité de 10 00, et le fait qu'après l'envoi de la commande ci-dessus, qui fait huit octets, ce champ d'activité vale 0f f8, soit 1000 - ff8, puis au bout de deux commandes C0 on voit que c'est revenu à 10 00. Donc ça doit correspondre à la taille du buffer d'entrée, i.e. à ce que la calculatrice peut accepter en entrée. Ce que je pense en revanche c'est que l'hôte n'envoie les données que s'il n'y a pas de données disponibles pour la lecture, et que c'est pour ça qu'il faut faire des commandes C0 pour voir. Aussi, au niveau du format des commandes C1 il s'est planté d'un octet je pense, le champ SS est un octet plus à gauche (ce qui est plus logique niveau alignement soit dit en passant) :
Après concernant ce que j'ai sur le retour, ça a l'air de plutôt être ce que j'avais en tête : des préfixes en CAL00D0 qu'il suffit de skip, puis le 0B, type du screenstreaming (aussi nommé « OHP » par SimLo), puis le header en TYPZ2 (la différence avec un TYPZ1 est minime, c'est juste un champ qui occupe deux octets de plus je crois) et les données.
Concernant le préfixe CAL00D0, c'est envoyé avant même la commande C2, ça fait penser à quelque chose qui est systématiquement envoyé tant que l'envoi réel de données n'est pas activé, un peu comme un compteur électrique qui n'envoie que son ADCO en boucle sans les données de consommation parce que le téléinfo n'est pas activé. Je ne saisis pas l'utilité de ce champ, il paraît safe de l'ignorer, et il est même envoyé sur du protocole 7 (VID/PID d'une fx-9860G) par les Prizm et autres en mode « compatibilité » (?). Le D0 fait possiblement référence au premier octet de la réponse à une commande C0, pour indiquer les champs après, pour mettre ce qui décode dans un certain mode (compatibilité avec le protocole 7, en quelque sorte ?), donc il faudrait, dans la libcasio, que quand je reçois ça, je décode les paquets « normaux » en prenant en compte les deux octets supplémentaires entre le checksum et les données.
Sinon, et ça je pense que je vais finir par faire un patch de snippets trouvés sur le net, faut que je réimplémente tout ça (du moins, ce qu'il me faut) avec la libusb dans la libcasio pour pouvoir tester tout ça. En vrai ça devrait pas être compliqué, c'est juste comme tout le reste, time-consuming
Désolé du vrac, il est presque deux heures du matin et je galère déjà à aligner mes pensées.
Mon blog ⋅ Mes autres projets
Citer : Posté le 13/05/2018 09:14 | #
Je commence à explorer ce que tu as mis, et je remarque qu'il y a quelques trucs en plus (une souris sans fil par exemple).
Aha oui, je voulais le dire mais j'ai oublié de le préciser : il peut y avoir des interférences. x_x
Quand j'ai pris la capture je n'avais de branché que mon alimentation, la calculatrice, ma souris USB et un écran VGA donc je pense que tu n'auras rien de plus qui gêne. Bien joué pour l'avoir trouvé direct !
Ça fait de plus une taille de buffer de 4 ko donc c'est raisonnable. Et comme on pourrait utiliser uniquement les bits SS pour décider comment agir, ça se tient :
- Si la calculatrice veut envoyer, on se met en réception
- Sinon, s'il y a assez de place dans le buffer pour notre envoi, on envoie
- Sinon, on attend que la place se libère
Ce qui n'empêche pas a priori l'hôte d'envoyer que si le buffer est vide.
J'ai regardé dans les gros paquets (transferts de plus de 4000 octets), j'ai rarement vu plus que des ff ff et des 00 00, et ça n'avait pas l'air d'être du full 16-bit. Pourrait-il y avoir de la compression ou quelque chose dans le tas ?
Citer : Posté le 13/05/2018 11:30 | # |
Fichier joint
Pas de compression, non. En descendant j'ai pu voir des données donc je ne sais pas ce qui t'a donné cette impression. Exemple :
Le « RC2 » dans le header TYPZ indique que c'est du 16-bit, soit du R5G6B5. (plus de détails)
Et sinon, je suis arrivé aux mêmes conclusions concernant le packet flow. Va falloir que j'adapte la libcasio d'ailleurs, puisqu'elle ne fait pas ça actuellement (y avait pas besoin de traiter absolument ce qui arrivait à la réception sur le série et l'USB direct en même temps) >_>
Mon blog ⋅ Mes autres projets
Citer : Posté le 13/05/2018 11:46 | #
Je suis tombé sur ces exemples-là mais il y a ben peu de couleurs différentes, peut-être 16 ou 32 au total ? Alors qu'il y a des dégradés sur quasiment tous les écrans.
J'espère me tromper, dans tous les cas.