[ODIN3] interception

[hypo59]

Hello à tous :hello: !

Aujourd'hui, je pose la question de l'interception de la connexion entre Odin et notre terminal Samsung.

Je m'explique: lorsque nous flashons des fichiers via Odin, des messages apparaissent dans la fenetre en bas à gauche d'Odin (ce qu'on appel le log). Ces messages indiquent si la connection passe bien via le câble USB, et si les flash des différents fichiers se déroulent avec succès/erreur. Il y a donc aller/retour entre Odin et le terminal.

Exemple 1: "Get PIT for mapping" indique qu'Odin interroge le terminal sur la table des partitions, puis le terminal répond ( :arrow: enfin je suppose que cela fonctionne ainsi).

Exemple 2: lorsque nous cochons la case "auto-reboot", le terminal reboot automatiquement à la fin du flash, sans que nous n'intervenions; c'est donc qu'une commande a été envoyée au terminal, pour être exécuté par lui

Ma question est donc la suivant: est-il possible d'intercepter (ou du moins lire) la communication entre Odin et le terminal ? Question sous-jacente: est-il possible, lorsque le terminal est en mode download, d'accéder au terminal (comme si nous étions en mode recovery) ?

Au plaisir de vous lire avec délectation !!!

 

[Valentin]

Salut hypo,

lorsque l'ont clique sur auto-reboot, il garde en mémoire cette valeur et l'écrit dans le fichier de configuration puis ensuite envoie cette commande à la fin du processus.
Pour les logs, je pense que tout est dans le logiciel : il s'agit d'un textarea (similaire html au MVC > interface machine) dans lequel il affiche les étapes de chaque conditions (comme un système de if/else).

Donc je ne pense pas que l'ont puisse récupérer ses logs :roll: mais après je peux me tromper.

 

[hypo59]

puis ensuite envoie cette commande à la fin du processus.

Hello Val ! Merci de ton message. Ma question est bien là : comment Odin envoie-t-il les commandes ?

 

[Valentin]

Lorsque j'étais encore en BTS, à un moment on avais fais plusieurs "trucs" sous du visual composer. En voyant le logo de Odin, je remarque que c'est le même que celui utilisé par défaut donc il se peut que ce soit le même système et donc si c'est cela alors tout se passe en interne, à savoir, des phrases qui sont ajoutées dans le textarea à chaque fin d'une étapes :

S'il vous plaît, Connexion ou S'inscrire to view codes content!

 

[hypo59]

Euh... Je ne comprends pas ce que tu essayes de m'expliquer :? Pour ma décharge je suis dans le gaz today

 

[Valentin]

Je t'ai expliqué comment, selon moi, les logs sont affichés.
Pour faire clair, je ne pense pas qu'il y a moyen de les récupérer.

 

[hypo59]

OK. Bon... Merci Val ! Je reste avec une 'tite frustration leur4:

 

[iDroid]

Salut

Petite note concernant Odin, BL AP CP et CSC ne sont que des décorations.

Tu mets un recovery dans BL, il va tout de même installer le recovery dans le mmcblk correspondant.

 

[hypo59]

Hello iDroid ! Tu peux expliquer davantage, ça m'intéresse ?

 

[iDroid]

Bas en gros, ça rejoint ce que tu disais sur "Get PIT for mapping...".
Sachant qu'une puce flash/eMMC est composée de blocs de plusieurs kilooctets chacun, une table de partition est nécessaire pour savoir qui est où.

Voici le PIT de mon téléphone (vu sur PIT Viewer) :

S'il vous plaît, Connexion ou S'inscrire pour voir le contenu ou les urls !

Dans la colonne "Part name", on a les différentes parties qui composent la puce, entre autre le BIOS, Linux et Android.

Dans un firmware en 4 fichiers, y'a ces fichiers :
• BL -> BcmBoot.img - Le bootloader de Broadcom (sachant que ce téléphone a un SoC Broadcom BCM21664)

• AP
boot.img - Le kernel linux
dt-blob - La réception réseau
param.lfs - Splash screen, paramètres telles que la réso, etc.
recovery.img - Le recovery
sboot.bin - Le bootloader secondaire
system.img - Android

• CP
BcmCP.img - La partie modem

• CSC
cache.img - Script recovery et installation du CSC actif
hidden.img - La plupart des cas, installe Over_the_Horizon.mp3 dans la SD interne

Bien sûr le firmware ne contient pas toutes les partitions, mais je vais expliquer.

Lorsqu'Odin flashe le firmware, il envoi par exemple BcmBoot.img.
Vu qu'il a téléchargé le PIT, il sait, par exemple que BcmBoot.img doit aller dans le bloc début 0 à fin 512, donc c'est un peu une écriture bloc par bloc.

Pareil pour toutes les autres partitions, c'est également pour cette raison que si notre partition hidden, par exemple peut accueillir 500Mo, et que le fichier pèse 512Mo, le terminal le refuse pour éviter de tout décaler -> FAIL.

 

[hypo59]

OK, j'ai compris ta réponse. Mais questions:
- à quoi sert alors les appellations BL, AP, CP et CSC dans Odin3 ?
- est-il possible d'explorer le fichier param.lfs pour le modifier (pour par exemple changer de splashscreen) ?
- sais-tu ce que fait précisément Odin3 quand tu dis "Lorsqu'Odin flashe le firmware, il envoi par exemple BcmBoot.img": quelles(s) commande(s) sont envoyées et où ?

 

[iDroid]

• Honnêtement je ne sais pas :x
• Tu peux ouvrir param.lfs avec 7-Zip. Tu peux changer tous les logos de démarrage, l'avertissement du mode Download, le splash screen du mode Download. Mais un fichier IMG s'y trouve, je pense qu'il contient tout ce qui est résolution, paramètres du CPU, etc...
• Je pense que Samsung s'est basé sur le fastboot pour créer le mode download, je pense que c'est une commande de transfert au téléphone (le mode download, si tu as déjà remarqué est reconnu en tant que Samsung Android USB Modem).

 

[hypo59]

OK pour param.lfs, je vais tester. Est-il possible de le repacker par la suite pour qu'il soit reconnu par Odin3 ? Et si oui, comment ?

OK pour le mode DL, je n'avais jamais prêté attention sur la reconnaissance en tant que Samsung Android USB Modem. Cela voudrait-il dire que l'échange de communication entre Odin3 et le terminal se ferait sur le mode modem ? Si oui, quel lien avec fastboot ?

 

[iDroid]

Alors après assure-toi que ce soit la même résolution XD

Ensuite pour le DL, pour moi c'est un échange simpliste, comme le fastboot. Odin envoie une commande assez simillaire au fastboot.

 

[hypo59]

Et on peut l'intercepter cette commande ?

 

[iDroid]

Sûrement mais par un moyen que je connais pas :x

 

[hypo59]

OK. Je pose la question car je me demandais ceci: flasher un PIT modifié n'est pas possible car non signé Samsung, et si on pouvait intercepter l'échange Odin3<->terminal, on pourrait se passer de la signature Samsung, et ainsi flasher le PIT modifié (et tout autre fichier non signé d'ailleurs).

 

[iDroid]

Il me semble que c'est le téléphone qui check le PIT :x

 

[hypo59]

Ca a toujours été ainsi ? Les téléphones ont toujours checké le PIT ? Je me souviens d'un sujet que j'avais ouvert sur le PIT ou yakapa40 était intervenu en expliquant que le PIT était devenu signé, signifiant qu'auparavant il ne l'était pas.

 

[iDroid]

À quelle époque ça a commencé je ne sais pas :x Peut-être vers le S2

 

[hypo59]

OK merci.

Pour le param.lfs, il n'est présent dans aucun firmware (wipe ou no-wipe). Sais-tu pourquoi ? Et j'ai essayé de l'ouvrir avec 7zip après l'avoir extrait de mon tél via la commande dd, mais 7zip me renvoie l'erreur "Le fichier [...] ne peut être ouvert comme une archive."

 

[iDroid]

Tu as quel modèle ?

 

[hypo59]

s4 i9505

 

[iDroid]

C'est pas une variante ? (param.bin ou autre chose)

 

[hypo59]

Il existe la partition mmcblk0p19 qui se prénomme param, elle fait 6Mo. Je suppose que c'est celle-ci.

 

[iDroid]

Tu as essayé ça :

S'il vous plaît, Connexion ou S'inscrire pour voir le contenu ou les urls !

??

 

[hypo59]

Oui, c'est un sujet que j'avais déjà lu. Et la commande que j'ai utilisée pour extraire la partition est la même. Je vais chercher un peu plus.