Forum Linux.embarqué Etude d'un système ARM et reverse

Posté par  . Licence CC By‑SA.
Étiquettes :
2
27
mar.
2018

Bonjour à tous,
Alors je me permets de venir sur ce forum car je suis a la recherche d'information sur les systèmes embarqués d'un point de vue "reverse" a titre d'apprentissage. Je m’intéresse au monde du libre depuis quelques années et maintenant j'aimerai approfondir mes connaissances en reverse.
Je cherche a faire fonctionner un "ancien" système (fonctionnant sur ARM) pour l'adapter sur RPI, par exemple mais ce n'est pas important pour le moment.
J'ai en ma possession
- U-boot.bin
- uImage (+vmlinux, +zImage, +system.map) > type little endians
- le système de fichier complet (qui était au format jffs2.img que j'ai extrait)

J'aimerai comprendre comment travailler les fichiers u-boot.bin, uImage afin de comprendre leurs fonctionnement et donc par conséquence, comprendre comment s'amorce ce système embarqué et l'adapter sur une autre plateforme ARM

Je ne sais pas trop comment continué, j'ai déjà commencé a analyser a l'aide de binwalk par exemple mais je ne sais pas qu'elles informations j'ai besoin pour comprendre, analyser ces fichiers

je fais un peu mes premiers pas à ce niveau là d'un système, je travail dans le développement en système embarqué (mais pas à ce niveau)

je sais que RPI ne fonctionne pas sur ce principe (u-boot) donc pour le moment le but est de comprendre comment est fait le noyaux, ce qu'il fait. Cela me permettrai d'adapter un nouveau noyaux par exemple en fin de phase

Pour le moment, quelles sont les informations nécessaires pour débuter ?

Si vous avez le temps de me conseiller :)

Merci d'avance et bonne journée

Cordialement,
Kriss

  • # POR->Boot process->Running

    Posté par  . Évalué à 5. Dernière modification le 27/03/18 à 19:00.

    Ton CPU reset, en général suivant l'état de certaines pins il exécute (grace à une rom interne) un chargement de binaire dans un format spécifique (contenant un en-tête indiquant l'adresse mémoire destination et la longueur du flux binaire au minimum). Les pins indique que le flux binaire est lu sur une flash spi, carte sd, usb ou encore uart.
    Ce flux binaire est ton fichier u-boot.bin (et par exemple doit être en offset 0 de la carte SD ).
    Ce U-Boot procèdes à l’initialisation d'unes partie des périphériques de ton micro (définitions des horloges de la DRAM par exemple) et en général à l'initialisation d'un uart pour avoir des traces, voir une interaction (mini terminal).
    Il permet aussi des de pouvoir "mounter" un fs présent sur une emmc ou sdcard pour charger une image bootable d'un kernel linux et lui passer des paramètres (comme en ligne de commande) c'est ton fichier uImage (qui peut tout aussi bien avoir été stocké dans une flash spi, je dis juste "mounter" dans un sens très large du terme)
    A tout système linux qui boot il faut un système de fichier pour lire/stocker les applications plus lourde,les lib systèmes etc… c'est le reste de ton jffs2.img

    En bref,
    La rom de ton cpu permet de charger et lancer u-boot
    U-Boot demarre le minimum de chose pour charger (en mémoire ou execute in place)/démarrer le kernel linux
    Le kernel initialise le reste et rend les services nécessaire aux applications
    Nota : U boot est spécifique à chaque micro (car lié aux périphérique présent, controleur dram uart etc) il n'est pas transposable facilement du RPI à autre chose sans bien être sur que le micro cible n'est pas celui du RPI.

  • # J'ai envie de dire ... tu t'en fous

    Posté par  (site Web personnel) . Évalué à 2.

    Que cherches-tu à faire concrètement ?
    Remplacer to ancien système par un rpi ?
    Quel service rendait cet ancien système ?
    Faire booter un kernel opérationnel sur un rpi n'est pas vraiment le problème à mon avis, je me concentrerais d'abord sur l'analyse du user space, voir ce qui est lancé dans l'init, etc …

  • # Un lien sur ARM et reverse

    Posté par  (site Web personnel) . Évalué à 1.

    https://azeria-labs.com/

    ウィズコロナ

  • # Insertion rootfs dans rom

    Posté par  . Évalué à 1.

    Pourquoi veux-tu conserver ton ancien système ? Il y a peut être une alternative…

    Cela dit U-Boot et le kernel devront probablement être recompilés spécifiquement pour la RPi. Comme la Raspberry Pi dispose de son propre bootloader intégré, seul le kernel sera réellement nécessaire.

    Selon l'ancienneté et les particularités du vieux système il te faudra soit simplement trouver ou compiler un nouveau noyau (quitte à récupérer les sources de la même version du kernel compatible avec la RPi) ou faire d'autres adaptations.

    Si j'étais toi je commencerais par essayer d'insérer mon rootfs dans une rom existante, probablement construite avec buildroot pour avoir quelque chose de relativement simple, puis à modifier les paramètres de boot et les fichiers de /etc si besoin est.

  • # réponse aux questions

    Posté par  . Évalué à 1.

    Bonjour et merci à tous d'avoir pris le temps de me répondre.
    Je vais essayé de répondre à tous le monde:

    @TheBreton
    Merci pour ces explications, c'est l'idée générale que j'avais, que vous me confirmez.
    La carte ayant cramée, il n'est plus possible de récupérer le contenu de la ROM.
    L'idée n'est donc pas de réinventer l'eau chaude.
    Ayant en ma disposition u-boot, uImage (zImage + vmlinux), j'aimerai, à l'aide de ces fichiers, comprendre ce qu'il se passe pendant le boot, cad ce qu'ils font exactement, ce qu'ils chargent. Pour pouvoir après modifier un kernel déjà existant (RPI par exemple, simplement celle que j'ai dans mon tiroir) et de "merger/adapter" certaines fonctions spécifiques qui seraient chargé en bas niveau.
    Donc je ne cherche pas a adapter u-boot et uImage sur RPI (qui fonctionnent spécifiquement sur la carte HS) a un autre système (ARM de même type); mais a l'aide de ces fichiers, comprendre ce qu'ils se passe et créer une alternative. + de précision dans la suite :

    @Mali et @Arvil
    Oui en réalité on s'en fou, plus ou moins, j'aime juste comprendre ce qu'il ce passe, comprendre les choses, la curiosité en fait.
    Pour répondre à tes questions :
    -J'ai en ma possession l'ensemble des fichier système rootFS et certaines parties des fichier du noyau, je cherche donc a analyser ce qu'il se passait en bas niveau qui permettait de rendre fonctionnel le système : ce que chargeait le noyau par exemple, ce qui etait spécifique a ce materiel pour merger/adapter
    ces modif a un autre noyau prévu pour une architecture cible (ex RPI)
    -L'ancien système fonctionnait avec une carte capteur : qui transmettait par bus SPI des données au cpu qui les traitait en temps réel. (Interface graphique couleur, un petit clavier avec quelques bouton pour se déplacer)
    La carte capteur est intacte, je cherche donc a refaire fonctionner cette carte. Pourquoi sur l'ancien système ? car tout est déjà créer, interface, analyse, menu, fonction spécifique de mesure etc.
    -Effectivement, l'analyse du système de fichier est ce que je fais depuis quelques jours pour comprendre ce qui boot en premier etc… mais je manque d'experience. Donc je cherche sans trop savoir ce que je cherche. J'analyse les dossier /bin et /sbin et le dossier /boot

    De manière générale, le point d'entrée est situé sur le raccourci "init" ? Cad uImage vient tapé dans Init ?

    Pour rejoindre ce que dit Arvil, au final, si je charge le kernel du RPI, standard, (qui englobe plus de fonctionnalités que nécessaire pour mon ancien système donc), cela peut il fonctionner avec mon ancien rootFS ? En mode dégrader probablement? Ce qui m'évite de "decompiler" le l'ancien noyau… (j'allais essayé dans la semaine

    Est il possible, d'émuler un noyau et d'avoir une trace log de ce qu'il fait ? par exemple dans un dossier ou une partition y collé le uboot et uimage et emuler le machin pour voir ce que fait uimage (je regarde du coté de qemu pour ceci, sans succés)

    J'espère avoir été assez clair,sinon n'hésitez pas à me le dire.
    Grosso modo, c'est plus un defi pour moi qu'autre chose car je pourrai faire plus simple probablement effectivement. Mais j'aimerai comprendre le bas niveau de l'ancien système
    L'ancien système était logiciellement parlant stable et terminé, donc pour moi l’intérêt est de la garder et de lui donner une 2nd vie sur RPI (par exemple)
    Les deux systèmes sont basé sur ARM ARM1136JF-S v6 pour l'ancien et ARM1176JZF-S (ARMv6) pour la PI version A, d'ou mon intêret pour celle ci

    Merci et bonne journée
    Cordialement

    • [^] # Re: réponse aux questions

      Posté par  . Évalué à 2.

      De manière générale, le point d'entrée est situé sur le raccourci "init" ? Cad uImage vient tapé dans Init ?

      Je ne suis pas sûr pour les architectures ARM, mais à priori ça doit être la même chose.
      Voici, (à peu près, j'essaie d'être générique, et vu mon niveau c'est évident que malgré mes efforts il y a des choses erronées dans ce laïus), ce qui se passe à partir de la mise sous tension d'un système:

      1. Le système démarre un firmware à partir d'une ROM. Dans les architectures «traditionnelles» ou en tout cas les seules que j'aie connues (i386 et x86_64) ces firmwares sont divisés en (au moins) 2 familles: BIOS et UEFI.
      2. Ces firmware passent la main à un programme appelé gestionnaire de boot. Windows en à un qui n'est pas trop nommé, sous Linux on a traditionnellement utilisé Lilo et Grub sur les disques durs, tandis que les installateurs CDs ont tendance à utiliser syslinux. Ce gestionnaire de boot permets d'une part de choisir le noyau à lancer, mais aussi quels paramètres lui donner (typiquement avec les distributions linux classiques: chemin de la partition racine, binaire qui contiendra le PID (appelé init)).
      3. Ce gestionnaire de boot charge un programme en mémoire et lui passe la main. Ce programme, dans les systèmes Linux traditionnels, est en fait une image disque minimaliste qui contiens 1 noyau linux, des modules à charger (les pilotes des systèmes de fichiers, le nécessaire pour un éventuel déchiffrement de ceux-ci, les pilotes de clavier, souris… en restant le plus minimaliste possible). Il s'agit de l'«initramfs».
      4. L'initramfs à pour rôle de pré-initialiser le «système matériel», je ne connais pas trop les détails, mais je sais que cette phase n'est pas vitale, on peut démarrer un kernel directement) pour pouvoir charger le noyau réel,
      5. le noyau charge le premier processus, appelé l'init. Il en existe plusieurs, mais les plus célèbres sont sysVinit, systemd et openrc. Le plus utilisé par les distributions de nos jours est systemd.
      6. le processus d'init démarre les divers services nécessaires à la machine pour être plus qu'un tas de silicium et de cuivre. Généralement, tu vas avoir udev (qui va exposer les informations au sujet du matériel provenant du noyau dans /dev), quelques terminaux virtuels (les fameux /dev/tty*), un gestionnaire de réseau, openssh, ton gestionnaire de session (lightdm, gdm, kdm, slime,…)…
      7. le gestionnaire de session ainsi que les tty sont traditionnellement les outils qui permettent à l'utilisateur final d'utiliser physiquement la machine (openssh aussi, mais c'est à travers le réseau), ils te demandent donc habituellement un login et un mot de passe, puis te laissent la main.

      PS: il y a un bouton répondre en dessous des commentaires, afin de répondre à une personne cible, ça rend les échanges plus faciles, et cerise sur le gateau, ça évite de réecrire un titre ;)
      J'imagine qu'il faudrait voir pour améliorer la visibilité d'ailleurs, ça arrive régulièrement qu'un nouveau ne le remarque pas.

    • [^] # Re: réponse aux questions

      Posté par  (site Web personnel) . Évalué à 3.

      Ayant en ma disposition u-boot, uImage (zImage + vmlinux), j'aimerai, à l'aide de ces fichiers, comprendre ce qu'il se passe pendant le boot, cad ce qu'ils font exactement, ce qu'ils chargent. Pour pouvoir après modifier un kernel déjà existant (RPI par exemple, simplement celle que j'ai dans mon tiroir) et de "merger/adapter" certaines fonctions spécifiques qui seraient chargé en bas niveau.

      Tu peux lire le code source du noyau ou de u-boot (et éventuellement leur doc ou des livres à ce sujet), ce sera plus digeste que d'essayer de décompiler pour comprendre.

      De plus, le vendeur de ta carte doit te mettre à disposition les correctifs qu'ils ont apporté à U-boot et au noyau pour le rendre utilisable sur la carte. Donc tu pourrais voir ce qui est réellement liée à la plateforme que tu utilises.

      De manière générale, le point d'entrée est situé sur le raccourci "init" ? Cad uImage vient tapé dans Init ?

      Oui, cela peut être changé au démarrage en envoyant un paramètre au noyau pour lui demander de lire un autre logiciel par défaut. Mais en général c'est le programme "init".

      Dans le noyau 4.7 tu peux le voir par exemple ce qu'il cherche par défaut : https://elixir.bootlin.com/linux/v4.7/source/init/main.c#L969

      Pour rejoindre ce que dit Arvil, au final, si je charge le kernel du RPI, standard, (qui englobe plus de fonctionnalités que nécessaire pour mon ancien système donc), cela peut il fonctionner avec mon ancien rootFS ? En mode dégrader probablement? Ce qui m'évite de "decompiler" le l'ancien noyau… (j'allais essayé dans la semaine

      Ça peut fonctionner, oui.
      Globalement le seul risque est que le logiciel que tu cherches à utiliser dépende trop du matériel, et donc éventuellement de certains pilotes qui n'existent plus ou qui ont changé.

      Si c'est le cas, le noyau plus récent et différent du RPi peut le rendre peu fonctionnel. Sinon pas de raisons particulières que cela ne fonctionne pas.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.