j'ai analysé d'un peu plus près le contenu du fichier...
Il y a effectivement un fichier M_*****.signature qui semble contenir une clé assez longue (base64 je suppose...)
La question est, cette clé est-t-elle une signature (genre RSA/DSA ou autre), et donc, impossible a reconstruire sans la clé privé, soit c'est un hash (checkum, genre sha1, md5...), et dans ce cas, on est capable de re-calculer le nouveau checksum après modification des fichiers...
Le truc, c'est que si c'était une signature, il faudrait que ETS connaisse la clé publique pour valider la signature, et donc, contienne la liste complète des fabricant (ce qui est possible), mais surtout nécessiterait une mise a jour, chaque fois qu'un nouveau fabricant apparaîtrait (et donc, ajouter une nouvelle clé public dans ETS), or il ne me semble pas qu'une vielle version d'ETS4 ne puisse pas ouvrir un fichier d'un nouveau constructeur, donc, il faut trouver la clé public autrement.
Dans le fichier knx_master.xml de chaque .knxprog, il y a effectivement la liste complète des fabriquant et certain on une clé RSA attaché.
Mais ça ne concerne que certains fabricant (Zennio, VIMAR et Buch dans mon fichier), et donc, tout les autres n'en ont pas.
Je pense donc que la "signature" n'est qu'un checksum, il faut donc trouver quel algo a été utilisé... et on pourrais refaire le fichier signature après ajout de la nouvelle traduction.
Et si c'est une signature, et qu'elle utilise la clé public du knx_master.xml, qu'est ce qui nous empêche de changer la clé public dans ce fichier ?
Bref, il faut que je creuse un peu plus, mais ça ne me semble pas infaisable...
Sinon, autre piste, quelqu'un a-t-il croisé un jour une documentation quelconque sur le format .knxprod, si ça se trouve, c'est documenté et normalisé...
Il y a effectivement un fichier M_*****.signature qui semble contenir une clé assez longue (base64 je suppose...)
La question est, cette clé est-t-elle une signature (genre RSA/DSA ou autre), et donc, impossible a reconstruire sans la clé privé, soit c'est un hash (checkum, genre sha1, md5...), et dans ce cas, on est capable de re-calculer le nouveau checksum après modification des fichiers...
Le truc, c'est que si c'était une signature, il faudrait que ETS connaisse la clé publique pour valider la signature, et donc, contienne la liste complète des fabricant (ce qui est possible), mais surtout nécessiterait une mise a jour, chaque fois qu'un nouveau fabricant apparaîtrait (et donc, ajouter une nouvelle clé public dans ETS), or il ne me semble pas qu'une vielle version d'ETS4 ne puisse pas ouvrir un fichier d'un nouveau constructeur, donc, il faut trouver la clé public autrement.
Dans le fichier knx_master.xml de chaque .knxprog, il y a effectivement la liste complète des fabriquant et certain on une clé RSA attaché.
Mais ça ne concerne que certains fabricant (Zennio, VIMAR et Buch dans mon fichier), et donc, tout les autres n'en ont pas.
Je pense donc que la "signature" n'est qu'un checksum, il faut donc trouver quel algo a été utilisé... et on pourrais refaire le fichier signature après ajout de la nouvelle traduction.
Et si c'est une signature, et qu'elle utilise la clé public du knx_master.xml, qu'est ce qui nous empêche de changer la clé public dans ce fichier ?
Bref, il faut que je creuse un peu plus, mais ça ne me semble pas infaisable...
Sinon, autre piste, quelqu'un a-t-il croisé un jour une documentation quelconque sur le format .knxprod, si ça se trouve, c'est documenté et normalisé...