Reverse engineering d'un clone de l'interface XS evolution pour reflash n° de série

[_nlc_]

Voilà l'objectif du topic va être de réussir à reflasher l'eeprom SPI de l'interface sans avoir à la dessouder, afin de changer le n° de série pour rendre l'interface fonctionnelle avec les dernières version soft PSA.

J'ai reçu mon interface clone, elle ne contient pas le connecteur de programmation (J1), mais je pense que ça ne doit pas empêcher le flash du MCU.
L'idée dans un 1er temps serait donc de flasher un firmware maison dans le MCU (j'ai tout les outils de développements, compilateurs C, etc... pour développer sur ce micro car je l'utilise au boulot), qui permettrait de reflasher l'eeprom SPI grâce à un petit utilitaire PC.
Et donc une fois l'opération faite, de reflasher le firmware normal dans l'interface.

J'ai quand même été surpris à réception de l'interface qu'ils aient utilisé un DB15 pour se connecter au PC en USB, car l'usb n'a besoin que de 4 broches. Je pensais vraiment qu'il pouvait y avoir des signaux interessant à disposition sur ce DB15 (genre les signaux qui permettrait de programmer l'eeprom depuis l'extérieur), mais en fait non, mes mesures n'ont rien donné, le brochage est le suivant :

1 gnd
2 ?
3 ?
4 ?
5 ?
6 gnd
7 usb d+
8 +5V
9 usd d-
10 ?
11 gnd
12 ?
13 ?
14 ?
15 gnd

J'ai mis des points d'interrogation car si ça se trouve il y a quand même des signaux qui arrivent sur certaines broches mais je n'ai pas encore trouvé lesquels.

[Tomtom71]

Je sens que ce post a de l'avenir !!!!

[_nlc_]

Je pars en vacance toute la semaine prochaine, je vais en profiter pour cogiter un peu là dessus, faut pas que j'oublie l'interface et le multimètre, je crois que ma femme va me tuer

[cchristr]

J'ai quand même été surpris à réception de l'interface qu'ils aient utilisé un DB15 pour se connecter au PC en USB, car l'usb n'a besoin que de 4 broches.

le DB15 est une évolution par rapport au premier modèle.
sur ces derniers le port était USB des deux cotés, mais c’était le point faible, le port USB coté interface cassait, il a donc été remplacé par un port plus solide.

[_nlc_]

Ok je vois, information très intéressante !
Donc peu de chance d'avoir des signaux supplémentaires dessus....

[jarod54190]

ce qui est sur, c'est qu'il n'y a pas de lien direct entre les pins du connecteur DB15 et les pins permettant le flash du MCU

[riton88]

Je sens que ce post a de l'avenir !!!!

- Bonjour a vous Amis du diag -
je rejoint Tomtom71 et confirme le spot est tres tres tres suivi par le membres est fait coulé beaucoup d ancre en coulisse !

- Bonjour a NLC et bienvenue sur le meilleur forum du net !!!

- Hein; c est vrai GEGE29 .. !!

[gege29]

bonjour a tous !
he oui je savais que notre ami NLC allait être suivi par beaucoup d'entre nous ; de part son savoir en la matière et le bon vouloir du partage
"madame nlc un peu d'indulgence " nous attendons beaucoup de lui
salut !

[Tomtom71]

Bonne vacances l'ami , reviens nous vite avec des infos positives ;-)
Et pour madame bein courage a elle :-) Quoi c'est pas cool des vacances avec son homme et son multimètre

[_nlc_]

Bonsoir,

Hier soir j'étais en chat avec Admin, et la discussion a été très enrichissante car il m'a expliqué que le logiciel de scary pour reflasher les interfaces utilise en fait tout simplement en arrière plan les utilitaires de téléchargement utilisés par les softs lexia/pp2000 lorsqu'ils mettent à jour les interfaces !!
C'est donc une très bonne nouvelle car les firmware étant de simple fichiers binaires (les fichiers en extension .com), on "devrait" donc être en mesure de flasher facilement un firmware maison dans la sonde. J'ai mis "devrait" car il n'est exclu que leur utilitaire de téléchargement vérifie quand même qu'il s'agisse bien d'un firmware ACTIA valide avant de procéder au téléchargement. En tout cas moi c'est ce que j'aurais fait !!

C'est la première chose que je vais avoir à tester. Si ça fonctionne, la 2eme étape c'est d'écrire un firmware spécial qui contiendrait au tout début du fichier binaire par exemple le n° de série qu'on désire (du coup facile à modifier avec un éditeur hexa ou par le petit soft de téléchargement modifié de scary qui pourrait demander quel n° de série on veut mettre et modifierait le fichier binaire automatiquement).
Une fois le firmware flashé, quand le bootloader lui passe la main, sa mission serait juste de mettre à jour l'eeprom avec le n° de série renseigné, et c'est tout. La sonde ne serait donc pas fonctionnelle évidemment, mais le bootloader étant toujours présent, en principe il doit y avoir moyen de reprendre la main sur l'interface pour lui réinjecter le firrmware officiel.

La difficulté pour la réalisation de ce firmware spécial, c'est de trouver l'adresse du point d'entrée de l'application. C'est en fait l'adresse sur laquelle le bootloader fait le "jump" pour passer la main à l'application. J'ai trouvé les points d'entrée de chaque vecteurs d'interruption, mais pas encore le point d'entrée de l'applicatif

[_nlc_]

Est-ce que par hasard quelqu'un aurait le fichier officiel .com correspondant à la dernière version firmware 4.3.0 ?
Il vous faut regarder dans le dossier C:/applic/lexia/MajAppCom/APPLI Software
Moi j'ai le APPLI 4.2.9 DB.com mais pas le 4.3.0.

Si quelqu'un l'a ça m'intéresse, je voudrais vérifier à quoi ressemble le binaire pour le comparer au dump d'une interface qui embarque cette version firmware.

[jarod54190]

Je n'ai pas non plus le 4.3.0 dans ce répertoire et je suis en diagbox 7.07

[_nlc_]

Je pense que ça doit correspondre à une version trop récente des softs.
Alors dans ce cas est-ce quelqu'un aurait un dump des 256Ko du MCU d'une interface en 4.2.9, ou même d'une version antérieure (dès l'instant où il existe le fichier correspondant en .com dans ce répertoire ça me va) ?

[jarod54190]

voici le dump d'une interface en 4.2.8 : 4.2.8.bin (256,00 KB) - uploaded.net

[_nlc_]

Excellent merci !!!!!!!!!!!!!!!!!!

- - - Mis à jour - - -

Bon ! Ca va pas être si simple que ça, en fait les fichier .com ne sont pas des simples binaires, il y a à la fois les données binaires du MCU, mais aussi des informations supplémentaires.
Si vous ouvrez avec un éditeur hexa le fichier APPLI 4.2.8 DB.com, et également le dump correspondant de l'interface, c'est flagrant :
A l'offset 0x20000 du dump, c'est le début de la zone applicative, on voit la version soft en ascii.
Et dans le fichier .com, le début de la zone applicative est à l'offset 0x200A8, et en plus la zone des données ascii est vierge (que des 0xFF) !!

Il y a donc des données supplémentaires dans le fichier .com, et des zones vierges qui sont renseignées après coup, par leur programme de téléchargement sans doute.
Déjà au tout début des fichiers il y a un décalage de 8 octets :

dans le dump, ça commence par :
41 50 50 4C 49 5F 58 53 5F 46 75 6A ---> APPLI_XS_Fuj
alors que dans le fichier .com on a :
00 00 00 00 00 FC 00 00 41 50 50 4C ........APPL

Donc des données supplémentaires dans le fichier .com, c'est pas un simple binaire.
Pour ces 8 premiers octets supplémentaires en tout début de fichier, les 4 0x00 je sais pas ce que c'est, pas contre le 0xFC0000 ça je sais, c'est l'adresse physique en flash où doit être injecté le firmware (la flash commence à l'adresse 0xFC0000 dans ce micro).

Il faudrait avancer petit à petit dans la comparaison des 2 fichiers pour trouver tous les blocs d'octets supplémentaires du fichier .com afin de comprendre à quoi ils servent, pour ensuite pouvoir générer un fichier .com à partir du firmware spécial que je compte écrire, sans ça il sera impossible de le flasher correctement dans le MCU :/
S'il y en a qui sont chaud pour faire la comparaison des fichiers !!! Il faudrait indiquer à partir de quels offsets il y a des octets supplémentaires, et indiquer combien d'octet en plus il y a.
Pour ces 8 octets par exemple dans le listing ça donnerait ceci :
Offset 0x000000, 8 octets en trop
Je suis sûr qu'il existe des outils qui pourraient faire ça facilement, notamment sous linux !