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

[_nlc_]

Bon l'outil cmp de linux est pas mal, j'ai trouvé une logique :
Hormis les 8 premiers octets de décalage, dans le fichier .com il y a 12 octets supplémentaires tous les 8002 octets.
Reste à comprendre à quoi il servent

- - - Mis à jour - - -

Bon c'est bon
Le premier bloc de 12 octets supplémentaire dans le .com c'est à l'offset 0x1F48. Les 12 octets supplémentaires sont : 00F2A7F8 00000000 00FC1F42
Le 0xFC1F42 correspond en fait à l'adresse en flash où il faut flasher le bloc suivant ! Pourquoi des blocs de 8002 octets pas contre là j'en sais rien, curieux comme choix, mais il doit y avoir une raison !?
Et le 0xF2A7F8 je sais pas ce que c'est, mais probablement un checksum du bloc précédent, ce qui expliquerait pourquoi au tout début du fichier .com il n'y a que 8 octets en trop, il n'y a pas de bloc précédent donc pas besoin de checksum !?

Bon allez dodo !!

[_nlc_]

Bon je continue à creuser mais je coince :

En fait le fichier .com est formaté comme suit :
- 8 octets formats, 8000 octets données binaire
- 12 octets formats, 8000 octets données binaires
- 12 octets format, etc...

Pour qu'il y ait une logique dans le découpage, le checksum d'un bloc de donnée devrait être à la fin du bloc, donc le découpage deviendrait :

- 8 octets format (adresse du bloc en flash), 8000 octets données binaires, 4 octets format (checksum du bloc !?)
- 8 octets format (adresse du bloc en flash), 8000 octets données binaires, 4 octets format (checksum du bloc !?)
- 8 octets format (adresse du bloc en flash), 8000 octets données binaires, 4 octets format (checksum du bloc !?)
etc...

Sauf que non :/
Car le dernier bloc binaire est incomplet et ne respecte pas la logique, le voici :

0000000000fe0002 --> 8 octets format, adresse ou flasher les données qui suivent (l'adresse 0xFE0002 correspond à l'offset 0x20002 dans le dump puisque la flash débute à 0xFC0000)

4150504c495f58535f46756a695f0050313036313338412000 56342e322e38004041435449410033312e30332e313100 --> 48 octets de données (en fait la chaine XS_Fuji_.P106138A [email protected] que l'on retrouve à l'offset 0x20002 du dump)

270b --> 2 octets de format (checksum), et non pas 4 !!! Il aurait fallu 4 octets pour que la logique soit bonne !!
Du coup sur les blocs de données précédents il y a 2 octets en trop dans la logique et je vois pas à quoi ils servent

[_nlc_]

Bon j'ai trouvé comment se calcule le checksum 16 bits sur le dernier bloc incomplet, mais ça marche pas sur les autres blocs, bizarre :/

[_nlc_]

Pfff quel ane
En fait le checksum est toujours en 16 bits, et le format et le suivant :

8 octets emplacement du bloc en flash - 8002 octets de données binaires - 2 octets checkum
8 octets emplacement du bloc en flash - 8002 octets de données binaires - 2 octets checkum
8 octets emplacement du bloc en flash - 8002 octets de données binaires - 2 octets checkum
etc...
puis le dernier bloc, plus court, mais toujours de la même taille, 48 octets, c'est la chaine de caractère de version, qui est placé à l'offset 0x20002 :
8 octets emplacement du bloc en flash - 48 octets de données binaires - 2 octets checkum

Mais j'ai toujours le même souci, j'arrive à calculer le checksum pour le dernier bloc mais pas encore ceux d'avant, je comprends pas pourquoi le calcul n'est pas le même !!

[Tomtom71]

Perso je ne comprends rien mais bon courage on te soutient à fond :-)

[_nlc_]

Ouf, ça y est c'est bon !!

En fait dans le checksum il ne prennent pas en compte les 8 octets de format qui précède le bloc de donnée !! Ils ne prennent donc en compte dans le checksum que les données binaires, pas l'adresse à laquelle elles doivent être injectées. C'est totalement absurde car le but d'un checksum c'est de voir si les données sont valides, et là il ne prend pas en compte les adresses, si le fichier .com est vérolé sur un octet d'adresse par exemple le bloc de donnée sera flashé à une mauvaise addresse....
C'est tellement idiot que c'est ça qui m'a fait perdre du temps Car ça me semblait tellement logique de prendre en compte les 8 octets d'adresse...

Bref donc c'est OK, à partir d'un firmware binaire brut il y a moyen de générer facilement un fichier .com, utilisable par les utilitaires de téléchargement officiels

Reste maintenant à trouver le point d'entrée de l'applicatif afin de pouvoir écrire le firmware spécial qui permettra de flasher l'eeprom...

[jarod54190]

mes encouragements pour ton travail qui va surement nous faciliter la tâche

[cuistots]

bravo encore pour cette avancée, je suis de tout coeur avec toi.
si tu y arrive , ce que je doute pas avec l'aide d'autre personne sur le forum, cela nous sera d'un grand service a tous.

et bon courage pour la suite.

[_nlc_]

Merci

Justement là je vais avoir besoin d'un coup main pour avancer !
D'une personne qui a la possibilité de reprogrammer un dump de firmware officiel dans le MCU avec la prise de programmation 12 broches si par hasard il n'y a pas moyen de reprendre la main par le bootloader.

Voici les choses qu'il faut effectuer (je ne peux le faire moi même je suis à 800km de chez moi et j'ai pas le matos à disposition pour reflasher le MCU si besoin !!) :

1) Récupérer le firmware bidon qui est en pièce jointe. J'ai donc écrit un petit utilitaire pour fabriquer automatiquement des fichiers .com

2) Utiliser le programme PSAIterfaceChecker pour flasher ce firmware dans l'interface XS. L'objectif c'est de voir si on est capable de flasher ce qu'on veut ou si le programme de téléchargement PSA fait une vérification plus poussée de la validité du firmware. Si le flashage s'effectue sans erreur, c'est déjà très bon signe !!

3) A ce stade, l'idéal serait d'utiliser le connecteur 12 points pour faire une lecture et un dump complet du MCU, et de m'envoyer le binaire, afin que je puisse vérifier si l'écriture a vraiment bien complètement marché.

4) Le firmware étant bidon, l'interface ne peut plus fonctionner correctement, la seule chose de valide dans la mémoire du MCU c'est sa zone bootloader. Du coup il faudrait maintenant essayer de reflasher un firmware officiel avec le programme PSAIterfaceChecker. L'objectif étant de voir si on peut reprendre la main par l'usb pour reflasher un firmware officiel dans l'interface alors qu'il y a un firmware non officiel dedans. En théorie si ACTIA a bien fait son travail ça doit être possible, afin que les utilisateurs ne se retrouvent pas avec une interface inutilisable en cas d'echec de la procédure de flash (lors d'un reflash automatique vers une version supérieure par exemple), s'il y a une coupure de courant ou un plantage windows par exemple pendant la mise à jour.

Sinon pour info avec Admin on a trouvé l'explication hier soir du pourquoi des blocs de données de 8002 octets dans les fichiers .com
C'est en fait parce qu'au niveau du driver USB la taille maximale des blocs transférable c'est 8012 octets (voir dans le fichier gescom.ini), et du coup 8 octets d'adresse + 8002 octets de données + 2 octets de checksum ça fait 8012 octets
En fait c'est pour exploiter au maximum le taux de transfert de l'usb en faisant des blocs de données les plus gros possibles

[Winbond45]

Salut _nlc_
J'ai regardé ton fichier fake, il est vraiment fake en regardant de plus près !
Que vient faire ton samsung galaxy S3 dans ce firmware !

[_nlc_]

hehe
Il me fallait 216Ko de données binaires, j'ai pris la première image jpeg qui m'est tombée sous la main, prise depuis mon téléphone donc

[Winbond45]

Ha ok..! donc démasqué !! cette image et si je la re-compile je verrai quoi ?

[Admin]

Ha ok..! donc démasqué !! cette image et si je la re-compile je verrai quoi ?

Windbond45, montrez-nous donc vos talents si souvent ventés :

Que donne l'injection de ce firmware fake avec PSA Interface Checker ?
Pouvez vous ensuite nous fournir le dump du MCU flashé avec le firmware fake via PSA Interface Checker ?
Puis pour finir pouvez-vous avec PSA Interface checker verifier que vous pouvez reinjecter un .com d'origine par dessus le Fake?

Merci d'avance

[Winbond45]

Voila Monsieur l'admin

Réponse négative je suis en train de vérifier tout cela autrement !
Un petit thank d'un admin pour l'encourager

[Admin]

Pouvez-vous fournir le dump du MCU ?
Que donne le reflashage par dessus ?

Merci