Ah, je me souviens avoir fait la même chose il n'y a pas si longtemps. Mais bon, ça fait longtemps, et j'ai pu d'accès à un videoprojecteur EPSON, du coup mon code pourri à l'air libre.
Par contre, j'avais été un peu plus loin : certains des vidéoprojecteurs ont du code en GPL, et donc il y a du code source disponible sur le site d'EPSON. Le code ne compile pas (il en manque la moitié), mais fourni quelques informations intéressantes. Sinon je crois que j'avais cherché des chaînes de caractères dans les binaires officiels, et j'avais eu quelques informations.
Mais bon, le fait qu'il y ai un client VNC et un vieuw ffmpeg m'avais pas mal aidé, j'ai pas eu à découvrir qu'il y avais du VNC en dessous.
Faudrai peut-être que je te sorte le code crade que j'avais fait, peu importe dans quel état déplorable c'est. J'avais même écrit un petit analyseur pour wireshark pour m'aider un peu.
Mais bon, de ce que je souviens :
Les segments envoyés en unicast diffèrent des segments envoyés en broadcast puisque le dernier caractère avant la suite de caractères nuls est un STX (0x02). Ce mot permet certainement au vidéoprojecteur de savoir si le segment reçu lui est destiné ou si il a été envoyé en broadcast.
Si je me souviens bien, y en a un qui s'appelle 'easysearch' (le 0x01, celui en broadcast) et l'autre qui s'apelle 'ipsearch' (le 0x02). T'a peut-être du remarquer que si dans l'interface tu lui demande de choisir une IP à la main, il utilise le 0x02.
Le client envoie un segment UDP au vidéo projecteur : le code c'est 4. Plein de nombres dans ce message de 74 octets, je ne reconnais rien, il y a une suite de nombre (ascii), mais je ne vois pas ce que cela peut représenter (ni même si ça a bel et bien un sens).
Dans ce message, je me souviens avoir reconnu un morceau de protocole RFB, la partie qui permet au serveur d'indiquer au client quel est sa résolution, son nombre de bit par pixel, d'indiquer que la valeur max du rouge c'est 0xff avec un décalage de 16 bit pour y accéder …
Par contre, je vois une adresse IP un peu après. Pas la mienne, ni celle du vidéo projecteur. Par contre, c'est l'IP du routeur de ma route par défaut. Je me demande bien pourquoi le vidéo projecteur a besoin de ça … et de toutes façons, il la connait déja puisqu'il obtient son IP via le DHCP. Peut être que c'est une manière de vérifier que l'on soit bien sur le même réseau ? Bon, bah du coup, il m'a suffit de relire le segment pour voir que juste avant la passerelle par défaut, j'envoie le netmask du réseau ! Merci au réseau de l'école, sans le netmask un peu bizarre (255.255.252.0) je crois que j'aurais vraiment eu du mal à le trouver, même si il était facile à deviner. On continue la lecture et on voit que le message se termine par l'IP du vidéoprojecteur. Ah, encore dans le message, je retrouve une suite de 4 nombres qui m'avaient intrigués. Je ne sais toujours pas ce que c'est, peut être un identifiant du vidéo projecteur ? En tous cas, ça ne doit pas coder d'information dans les messages de code 3 (ça aurait pu être par exemple l'état du vidéo projecteur).
Ce qui est encore plus bizarre, c'est que dans les sources, c'est plus présenté comme une modification de la configuration IP qu'autre chose, sauf que si j'essaye de mettre d'autres adresses, ça marchai pas, ça modifiait pas la conf du vidéoproj…
En regardant un peu la conversation dans sa globalité, je remarque, de temps à autre, des messages "traditionnels" : un message de 8 octets (EPRD0600), suivie de l'IP source, le type du message est 0, et est suivi par un nombre de 32bits
Moi ce qui m'avais aussi surpris, c'est que dans le code source, il y avais du code pour chercher "EPRD0600" arbitrairement dans le flux … mais bon comme il en manquait la moitié du code …
Ce canal a l'air d'être ouvert en permanence. Je ne sais pas à quoi il sert mais peut être qu'il est utile pour l'utilisation de la télécommande. On verra ça plus tard.
Non, il sert pas à grand chose … Pour la télécommande, c'est le proto ESC/VP.net sur le port 3629. Y a une doc trouvable facilement qui spécifie les échanges, mais pas l'initialization, mais bon, c'est pas compliqué, juste un échange UDP et une ouverture de session TCP ou tu fait un échange similaire. J'ai pas les détails en tête, mais mon vieux code, si.
Avec ça, tu peut simuler un appui sur toutes les touches de la télécommande infrarouge.
Maintenant que ce canal est ouvert, je vais voir pour ouvrir le canal qui nous intéresse pour le moment : celui qui nous permet d'envoyer les images que le vidéo projecteur va afficher. Peut être que le canal coté projecteur (je vais l'appeler comme ça parce que c'est lui qui initialise la connexion) permet aussi de maintenir la connexion (avec un keep alive -like (type 0x0A ?).
oui, le 0x0a est un keepalive. j'ai cru un moment que c'était un "displayrefresh", sauf que ça correspondait à rien.
De plus, on peut supposer que si le protocole utilise un algorithme de chiffrement, celui-ci est connu et ouvert (AES, Serpent, 3DES…).
Je n'ai pas recherché de ce coté là (si tu parle de la case "crypter les communications", mais je vais te décevoir (ou te faire rire) : EPSON utilise du DES, ou alors de l'AES64. Qu'est ce que l'AES64 ? C'est de l'AES128, sauf que la clef de départ n'a que 64bit, et tu la répète deux fois pour avoir une clef de 128bit. C'est pratique AES64, c'est la même taille de clef que DES…
Ah, et il y a (peut-être) un champ dans le message 0x04 qui s'apelle 'encryption_key'. Et j'ai pas envie de vérifier si la clef est effectivement envoyée en clair.
Fin bon, moi mon but, c'était surtout d'envoyer de la vidéo au videoproj. Mais le meilleur truc que j'ai eu, ça n'était que du son… et j'ai jamais réussi à reproduire.
# Bienvenue au club
Posté par Batchyx . En réponse au journal Rétro ingénierie Epson. Évalué à 10.
Ah, je me souviens avoir fait la même chose il n'y a pas si longtemps. Mais bon, ça fait longtemps, et j'ai pu d'accès à un videoprojecteur EPSON, du coup mon code pourri à l'air libre.
Par contre, j'avais été un peu plus loin : certains des vidéoprojecteurs ont du code en GPL, et donc il y a du code source disponible sur le site d'EPSON. Le code ne compile pas (il en manque la moitié), mais fourni quelques informations intéressantes. Sinon je crois que j'avais cherché des chaînes de caractères dans les binaires officiels, et j'avais eu quelques informations.
Mais bon, le fait qu'il y ai un client VNC et un vieuw ffmpeg m'avais pas mal aidé, j'ai pas eu à découvrir qu'il y avais du VNC en dessous.
Faudrai peut-être que je te sorte le code crade que j'avais fait, peu importe dans quel état déplorable c'est. J'avais même écrit un petit analyseur pour wireshark pour m'aider un peu.
Mais bon, de ce que je souviens :
Si je me souviens bien, y en a un qui s'appelle 'easysearch' (le 0x01, celui en broadcast) et l'autre qui s'apelle 'ipsearch' (le 0x02). T'a peut-être du remarquer que si dans l'interface tu lui demande de choisir une IP à la main, il utilise le 0x02.
Dans ce message, je me souviens avoir reconnu un morceau de protocole RFB, la partie qui permet au serveur d'indiquer au client quel est sa résolution, son nombre de bit par pixel, d'indiquer que la valeur max du rouge c'est 0xff avec un décalage de 16 bit pour y accéder …
Ce qui est encore plus bizarre, c'est que dans les sources, c'est plus présenté comme une modification de la configuration IP qu'autre chose, sauf que si j'essaye de mettre d'autres adresses, ça marchai pas, ça modifiait pas la conf du vidéoproj…
Moi ce qui m'avais aussi surpris, c'est que dans le code source, il y avais du code pour chercher "EPRD0600" arbitrairement dans le flux … mais bon comme il en manquait la moitié du code …
Non, il sert pas à grand chose … Pour la télécommande, c'est le proto ESC/VP.net sur le port 3629. Y a une doc trouvable facilement qui spécifie les échanges, mais pas l'initialization, mais bon, c'est pas compliqué, juste un échange UDP et une ouverture de session TCP ou tu fait un échange similaire. J'ai pas les détails en tête, mais mon vieux code, si.
Avec ça, tu peut simuler un appui sur toutes les touches de la télécommande infrarouge.
oui, le 0x0a est un keepalive. j'ai cru un moment que c'était un "displayrefresh", sauf que ça correspondait à rien.
Je n'ai pas recherché de ce coté là (si tu parle de la case "crypter les communications", mais je vais te décevoir (ou te faire rire) : EPSON utilise du DES, ou alors de l'AES64. Qu'est ce que l'AES64 ? C'est de l'AES128, sauf que la clef de départ n'a que 64bit, et tu la répète deux fois pour avoir une clef de 128bit. C'est pratique AES64, c'est la même taille de clef que DES…
Ah, et il y a (peut-être) un champ dans le message 0x04 qui s'apelle 'encryption_key'. Et j'ai pas envie de vérifier si la clef est effectivement envoyée en clair.
Fin bon, moi mon but, c'était surtout d'envoyer de la vidéo au videoproj. Mais le meilleur truc que j'ai eu, ça n'était que du son… et j'ai jamais réussi à reproduire.