La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Linux => Discussion démarrée par: aljarreau le 08 mai 2021 à 22:02:26
-
Bonsoir,
j'ai un souci pour le repack d'un firmware avec la commande dd
À partir du fichier firmware.bin qui contient le le bootoader, le header ,des fichiers compressés en Zlib et 2 image system (image montée au boot et image backup), j'ai extrait avec dd la première image (compressée en cramfs big endian), je l'ai décompressée, j'ai fait la modification que je voulais sur un fichier (sys.cfg) et j'ai recompressé l'image comme elle l'était avant l'extraction. Maintenant, je ne sais pas comment faire pour la remettre dans le fichier firmware.bin, pour remplacer l'ancienne.
Je ne suis pas très calé en commandes linux, j'apprends sur le tas, au fur et à mesure.
Si ça peut aider pour l'extraction, j'ai utilisé les outils de "Firmware mod Kit" (https://github.com/rampageX/firmware-mod-kit/wiki), mais le script de repack ne marche pas.
à l'extraction, j'ai obtenu un fichier header.bin (avec tout les fichiers sauf le fichier rootfs.img) et le fichier rootfs.img sur lequel j'ai travaillé pour pouvoir le remettre.
Pour y voir plus clair je post ici les sorties binwalk des fichiers que j'ai utilisé.
Pour le fichier firmware.bin:
boubou@MacBook-Pro transfer % binwalk firmware.bin
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
1028 0x404 Copyright string: "Copyright 2008, Cambridge Industry Group(CIG), All Rights Reserved."
1933 0x78D Unix path: /home/taojipeng/prj/bootload_rtl_9601b_nor
106944 0x1A1C0 uImage header, header size: 64 bytes, header CRC: 0x56E2162D, created: 2016-01-15 09:00:54, image size: 82086 bytes, Data Address: 0x80F00000, Entry Point: 0x80F00000, data CRC: 0xE1D0FA23, OS: Firmware, CPU: MIPS, image type: Firmware Image, compression type: lzma, image name: "U-Boot 2011.12.NA-svn94986 for r"
107008 0x1A200 LZMA compressed data, properties: 0x5D, dictionary size: 16777216 bytes, uncompressed size: 217360 bytes
524288 0x80000 JFFS2 filesystem, big endian
655440 0xA0050 Zlib compressed data, compressed
656112 0xA02F0 Zlib compressed data, compressed
657368 0xA07D8 Zlib compressed data, compressed
658820 0xA0D84 Zlib compressed data, compressed
660008 0xA1228 Zlib compressed data, compressed
660904 0xA15A8 Zlib compressed data, compressed
662260 0xA1AF4 Zlib compressed data, compressed
663516 0xA1FDC Zlib compressed data, compressed
664968 0xA2588 Zlib compressed data, compressed
666156 0xA2A2C Zlib compressed data, compressed
667052 0xA2DAC Zlib compressed data, compressed
668408 0xA32F8 Zlib compressed data, compressed
669664 0xA37E0 Zlib compressed data, compressed
671116 0xA3D8C Zlib compressed data, compressed
672304 0xA4230 Zlib compressed data, compressed
673200 0xA45B0 Zlib compressed data, compressed
674556 0xA4AFC Zlib compressed data, compressed
675812 0xA4FE4 Zlib compressed data, compressed
677264 0xA5590 Zlib compressed data, compressed
678452 0xA5A34 Zlib compressed data, compressed
679352 0xA5DB8 Zlib compressed data, compressed
680708 0xA6304 Zlib compressed data, compressed
681964 0xA67EC Zlib compressed data, compressed
683416 0xA6D98 Zlib compressed data, compressed
684604 0xA723C Zlib compressed data, compressed
685504 0xA75C0 Zlib compressed data, compressed
686860 0xA7B0C Zlib compressed data, compressed
688116 0xA7FF4 Zlib compressed data, compressed
689568 0xA85A0 Zlib compressed data, compressed
690756 0xA8A44 Zlib compressed data, compressed
691656 0xA8DC8 Zlib compressed data, compressed
693012 0xA9314 Zlib compressed data, compressed
694268 0xA97FC Zlib compressed data, compressed
695720 0xA9DA8 Zlib compressed data, compressed
696908 0xAA24C Zlib compressed data, compressed
697804 0xAA5CC Zlib compressed data, compressed
699160 0xAAB18 Zlib compressed data, compressed
700416 0xAB000 Zlib compressed data, compressed
701868 0xAB5AC Zlib compressed data, compressed
703056 0xABA50 Zlib compressed data, compressed
703952 0xABDD0 Zlib compressed data, compressed
705308 0xAC31C Zlib compressed data, compressed
706564 0xAC804 Zlib compressed data, compressed
708016 0xACDB0 Zlib compressed data, compressed
709204 0xAD254 Zlib compressed data, compressed
710100 0xAD5D4 Zlib compressed data, compressed
711456 0xADB20 Zlib compressed data, compressed
712712 0xAE008 Zlib compressed data, compressed
714164 0xAE5B4 Zlib compressed data, compressed
715352 0xAEA58 Zlib compressed data, compressed
716112 0xAED50 JFFS2 filesystem, big endian
.....
.....[b]plein de lignes Zlib[/b]
2059548 0x1F6D1C Zlib compressed data, compressed
2060312 0x1F7018 JFFS2 filesystem, big endian
2097152 0x200000 CramFS filesystem, big endian, size 6500352, version 2, sorted_dirs, CRC 0xEF794412, edition 0, 3942 blocks, 717 files
9437184 0x900000 CramFS filesystem, big endian, size 6389760, version 2, sorted_dirs, CRC 0x2E192AFD, edition 0, 3869 blocks, 715 files
à l'extraction le binwalk du fichier header.bin donne la même chose sans la dernière ligne (9437184 0x900000) que l'on retrouve dans le fichier extrait rootfs.img à l'identique.
Alors je souhaiterai savoir comment faire pour remettre ce fichier frootfs.img (manipulé), soit dans le header.bin qui sera le nouveau firmware, soit dans le fichier firmware.bin, et remplacer l'original.
Merci pour votre aide et Bon Weekend.
-
C'est une image de l'ensemble de la mémoire flash, est-ce qu'il faut vraiment le firmware.bin complet pour reflasher, et pas uniquement une des partitions ?
Il y a quelque chose que je ne comprends pas :
- "un fichier header.bin (avec tout les fichiers sauf le fichier rootfs.img)" => rootfs.img est la 2ème image
- "le fichier rootfs.img sur lequel j'ai travaillé pour pouvoir le remettre"
- "j'ai extrait avec dd la première image (compressée en cramfs big endian), je l'ai décompressée, j'ai fait la modification que je voulais sur un fichier (sys.cfg) et j'ai recompressé"
Est-ce la 1ère ou la 2ème image CramFS qui a été modifiée ?
Pour remplacer la 1ère image, on écrit par dessus à partir de la bonne position :
cp firmware.bin firmware-mod.bin
dd if=frootfs.img of=firmware-mod.bin bs=1024 seek=2048 conv=notrunc
Pour remplacer la 2ème image, c'est plus simple.
Puisque header.bin contient déjà tout le reste, il suffit de concaténer le rootfs, et d'agrandir le fichier pour arriver aux 16Mo si c'est nécessaire.
cat header.bin frootfs.img > firmware-mod.bin
truncate -s 16M firmware-mod.bin
-
Bonsoir @hwti
Et bien la 2° solution (la plus simple a marché du premier coup. ;) :)
Et pas besoin de concaténer, puisque le fichier de sortie puisque celui-ci fait exactement la même taille que le fichier d'origine
Il ne reste plus qu'à croiser les doigts et flasher ce fichier pour vois le résultat.
Merci beaucoup @hwti je boirai un grand Sprite à ta santé. Bo Weekend
-
Malheureusement, ça n'a pas marché. Après injection du firmware modifié, l'ONT n'a pas voulu démarrer.
J'ai exactement suivi la méthode que tu m'as montré. Pour info, je n'ai changé que la version du SW sur un ficher sys.cfg qui se trouve dans /etc et rien d'autre. j'ai fait une comparaison à la volé des 2 firmwares avec binwalk et tous semble identique.
Alors, y at-il un moyen plus radical de comparer 2 ficher .bin, en l'occurence le firmware d'origine avec celui modifié?
Merci
P.S. Le but de cette manip était de faire correspondre la version du Software de l'ONT avec celle de celui qui m'a été fourni par l'opérateur. Car, bizarrement, l'ONT est bien registered (05) et donc Led Vert, mais la connexion Pppoe ne se fait pas si la version du Software n'est pas la bonne. L'ONT se bloque et on y a plus accès.
J'ai fait des test avec un autre ONT (TP-Link TX-6610) que je connais bien est qui est configurable à souhait, pour arriver à cette conclusion.
-
Sans savoir plus de choses sur l'ONT, c'est difficile.
Si binwalk dit bien que le CramFS est toujours big endian et version 2, je ne vois pas pourquoi il ne serait pas chargé.
Là je suppose qu'il doit booter avec root=/dev/mtdblockX, auquel cas la taille exacte du CramFS importe peu, tant qu'il rentre dans la zone prévue pour.
Avec juste la sortie de binwalk, je ne sais pas où est le kernel.
Je vois un premier bootloader, qui charge une image contenant à priori u-boot (utilisé donc en second bootloader).
Quelque part entre 0x2E2A6 (fin de l'image "U-Boot 2011.12.NA-svn94986 for r") et 0x80000, il devrait y avoir une zone avec l'environnement de u-boot (avec des bouts de texte de la forme variable=valeur).
L'environnement de u-boot devrait permettre de savoir où il trouve le kernel, et quelle ligne de commande il lui-donne (ou s'il n'y en a pas, il faut regarder celle par défaut dans le kernel).
Est-ce qu'il est rooté ? C'est souvent plus simple de récupérer des informations dessus, et même si tout est en lecture-seule, pour un test il est parfois possible de "modifier" des fichiers sans changer l'image.
Comment a-t-il été reflashé ?
-
Est-ce qu'il est rooté ? C'est souvent plus simple de récupérer des informations dessus, et même si tout est en lecture-seule, pour un test il est parfois possible de "modifier" des fichiers sans changer l'image.
apparement oui, puisque j'arrive à accéder en telnet et en ssh au system de fichiers montés (donc, je peux voir et lire tout ce qu'il contient dans le shell), mais oui, tou est en lecture seule.
Il est possible de faire beaucoup de chose dessus par telnet (changer de SN, SLID, ONT ID...), il est même possible de flasher l'image de backup, alors j'i bien tenter de le faire mais j'ai l'erruer suivante:
#ONT/system/fs>supgrade
Starting download 'rootfs.img' from Ftp server'192.168.100.3' ... Done.
Starting save 'rootfs.img' to Flash Partition 3 ...
file[/tmp/temp] length=7340032
Image length check failed
ERROR: Fail to write.
Error code = 1
J'ai bien pris soin de faire un erase de la partition mtd3 sur laquelle était l'ancien image pour libérer de l'espace mais rien à faire. j'ai même essayer une autre image d'une autre taille... Rien, Walou ;) :)
Comment a-t-il été reflashé ?
Avec un programmeur, mais ce n'est pas moi qui ai fait le flash
(https://zupimages.net/up/21/19/uld9.jpeg)
Just pour info voici le binwalk du ficher bin original et du bin modifié:
https://code.empreintesduweb.com/14624.html (https://code.empreintesduweb.com/14624.html)
Merci beaucoup pour ton aide
P.S. si tu veux, je peux t'envoyer le fichier d'origine et le et le N° de version du Software à changer. Bonne semaine
Enfin le voici, à toute fin utile:
https://we.tl/t-bSEVmHutNn
-
De mes vagues souvenirs de modification de firmware en héxa (tout dépends de comment cela a été modifié).
il y a les CRC à vérifier (header CRC: 0x56E2162D) etc.
-
#ONT/system/fs>supgrade
Starting download 'rootfs.img' from Ftp server'192.168.100.3' ... Done.
Starting save 'rootfs.img' to Flash Partition 3 ...
file[/tmp/temp] length=7340032
Image length check failed
ERROR: Fail to write.
Error code = 1
file[/tmp/temp] length=7340032
Image length check failed
Cela a l'air d'être cela le problème, un pb de CRC
-
file[/tmp/temp] length=7340032
Image length check failed
Cela a l'air d'être cela le problème, un pb de CRC
Merci @Anonyme
Ya-t-il un moyen d'y remédier Please? Ce serait l'idéal et ça m'éviterai de faire appel à une tierce personne pour reflasher le firmware (non maitrise de la chaîne de transformation ;) :) )
-
"#ONT/system/fs>" c'est une vraie ligne de commande Linux ?
Si c'est un shell limité, ce n'est pas ce que j'appelle rooté.
Les CRC des deux CramFS ont été modifiés, c'est bizarre.
Normalement une seule des deux images aurait dû changer.
Ou alors le header.bin n'est pas identique au début de l'image d'origine, mais a été modifié :-\
Pour l'outil supgrade, il faut plutôt regarder ce qu'il attend.
Peut-être qu'il faut des entêtes devant les 7Mo, ou que la partition fait en fait légèrement moins de 7Mo (cat /proc/cmd, ou ligne de commande du kernel pour voir).
Effacer une mtd, ça ne libère pas de place, c'est juste une étape nécessaire avant une écriture (mais en général c'est pris en charge par les outils).
Si on fait écrire une partition manuellement dans une mtd, c'est souvent flashcp, ou "mtd write".
-
file[/tmp/temp] length=7340032
Image length check failed
Cela a l'air d'être cela le problème, un pb de CRC
Le CRC semble être dans les entêtes CramFS, ce qui suppose que les fichiers ont été modifiés et l'image a été régénérée.
Puisque c'est compressé, il est peu probable d'avoir pu modifier directement à l'éditeur hexa.
-
Enfin le voici, à toute fin utile:
https://we.tl/t-bSEVmHutNn
C'est l'image d'origine, il faudrait aussi l'image modifiée pour essayer de comprendre ce qui s'est passé afin de ne pas recommencer.
-
Il y a donc un shell de configuration spécifique (à voir les nuances entre supgrade, flash, et upgrade), mais qui heureusement semble pouvoir lancer des commandes shell normales (ou un sh complet, le prompt "#ONT/system/shell>" reste étrange).
-
#ONT/system/shell>cat cmdline
console=ttyS0,115200 mem=31M root=/dev/mtdblock2 mtdparts=sflash:512K@0x0(Boot),0x180000@0x80000(Config),7M@0x200000(ImageA),7M@0x900000(ImageB) rootfstype=cramfs hasEeprom=0 5srst=0
Il y a des données (de configuration ?) en 0x60000, et répétées en 0x70000.
C'est dans la mtd "Boot" bizarrement.
J'ignore s'il y a des CRC, ce n'est pas forcément modifiable directement, mais ça peut être intéressant.
00060000 31 35 47 2d 30 30 30 31 34 2d 31 31 30 38 31 37 |15G-00014-110817|
00060010 33 30 32 30 35 35 30 38 30 31 57 43 37 31 30 38 |3020550801WC7108|
00060020 46 39 31 33 30 39 4d 00 00 00 9c 50 ee a8 0b fc |F91309M....P....|
00060030 9c 50 ee a8 0b ff 00 03 10 00 00 00 00 00 00 00 |.P..............|
00060040 00 00 00 00 41 4c 43 4c 46 38 34 44 38 38 33 34 |....ALCLF84D8834|
00060050 00 00 00 00 00 00 00 00 00 a9 01 01 00 00 00 00 |................|
00060060 41 4c 43 4c 41 4c 43 4c f8 4d 88 34 33 46 45 34 |ALCLALCL.M.43FE4|
00060070 35 34 35 38 41 44 41 41 30 34 5f 5f 5f 5f 5f 5f |5458ADAA04______|
00060080 5f 5f 5f 5f 47 2d 30 31 30 47 2d 50 5f 5f 6f 6e |____G-010G-P__on|
00060090 74 2e 7a 00 00 00 00 00 00 00 00 00 c0 a8 64 01 |t.z...........d.|
000600a0 ff ff ff 00 c0 a8 01 fd 00 00 00 00 6f 6e 74 00 |............ont.|
000600b0 00 00 00 00 6f 6e 74 00 00 00 00 00 00 02 00 00 |....ont.........|
000600c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000600d0 00 00 00 00 00 00 00 00 00 00 f2 01 80 08 45 80 |..............E.|
000600e0 34 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |4...............|
000600f0 00 00 00 00 00 00 00 00 00 00 00 00 12 f0 d6 e4 |................|
00060100 30 02 db 00 00 01 00 00 00 00 00 00 00 00 00 00 |0...............|
00060110 00 a9 03 23 00 24 05 19 02 70 00 66 03 fd 00 80 |...#.$...p.f....|
00060120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00060130 00 00 00 00 00 00 17 02 dd 00 00 00 00 00 00 00 |................|
00060140 00 1e 00 31 00 00 00 00 00 00 00 00 01 00 00 00 |...1............|
00060150 00 00 00 00 00 00 00 00 00 00 00 00 00 01 30 00 |..............0.|
00060160 00 00 00 00 00 00 01 9a 04 cc 05 30 00 00 00 00 |...........0....|
00060170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00060190 00 00 00 00 00 00 01 7e 00 2b 67 16 00 0a b5 06 |.......~.+g.....|
000601a0 00 2c 18 9a 36 33 48 12 00 00 00 00 00 00 00 00 |.,..63H.........|
000601b0 64 64 64 64 27 d8 00 be a5 5a 00 09 fc f2 00 03 |dddd'....Z......|
000601c0 c1 c1 19 c0 bd 9a 05 36 8d 44 10 e8 90 6c 00 00 |.......6.D...l..|
000601d0 00 00 27 d8 00 be a5 5a 00 09 fc f2 00 03 c1 c1 |..'....Z........|
000601e0 19 c0 bd 9a 05 36 8d 44 10 e8 90 6c 00 00 00 00 |.....6.D...l....|
000601f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00060200 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
-
De ce que je comprends, il y a un pb sur rootfs.img à la demande de faire un supgrade, et c'est sur la taille de rootfs.img.
Fonction de comment cela a été modifié ( je sais pas) il faut recalculer les CRC.
Cela peut être fait par des outils de manipulation des fichiers et de reconstruction du file system.
Mon intervention s'arrête à ce niveau là, pour le reste, je vous laisse poursuivre vos investigations, vous avez une indication de la source du problème c'est déjà pas mal. :)
-
De ce que je comprends, il y a un pb sur rootfs.img à la demande de faire un supgrade, et c'est sur la taille de rootfs.img.
Fonction de comment cela a été modifié ( je sais pas) il faut recalculer les CRC.
Cela peut être fait par des outils de manipulation des fichiers et de reconstruction du file system.
Mon intervention s'arrête à ce niveau là, pour le reste, je vous laisse poursuivre vos investigations, vous avez une indication de la source du problème c'est déjà pas mal. :)
Merci @Anonyme
-
"0x180000@0x80000(Config)" => /dev/mtd1, un JFFS2 qui doit être monté quelque part (avec accès en écriture).
Les versions (HW 3FE45458ADAA04, SW 3FE45655AOCK88 et 3FE45655AOCK31) sont présentes dans le ont.mib qui est dans le JFFS2.
Peut-être que le modifier (soit à la main, soit s'il y a des commandes pour ça) serait suffisant pour que l'OLT soit content.
Il y a saveconfig et loadconfig, ce serait à tester pour voir ce que ça permet de changer.
Dans les deux CramFS, il y a un /bootimg/00a9_01_01 qui correspond au début de la flash (la taille utile de la parition de boot, à part les deux zones en 0x60000 et 0x70000).
Je suppose que ça doit être flashé en deux fois.
binwalk lance cramfsck pour extraire, mais s'il n'est pas lancé en root ça s'arrête en plein milieu, mais binwalk masque l'erreur >:(
-
Il est clair que les deux images CramFS ont été régénérées.
Peut-être que la génération n'est pas reproductible, je ne sais pas si c'est gênant en soi.
En revanche, au offsets 0x200030 et 0x900030 on a une ligne de 16 octets qui est différente.
Les images régénérées ont "Compressed", alors que les deux images de départ ont "UCIG" ou "UUAL" et 4 octets de binaire.
Je me demande ce que c'est, https://f.zz.de/posts/201204191137.gpl_-_ach_quatsch_.../ mentionne "actImage[1], PartId[3], custom[UUAL] sys_cfg[/etc/sys.cfg.alu]".
Le bootloader regarde peut-être ces informations.
En tout cas il regarde probablement le contenu du CramFS, puisque le kernel est dedans, dans /uImage !
-
Voilà je viens de trouver le fichier ont.mib, il est dans /mnt/rwdir, je vais voir ce que je peux en faire
Il doit être écrit quand on change certaines valeurs.
Peut-être qu'en le modifiant plus ou moins manuellement, on peut effectivement changer des valeurs pour lesquelles il n'y a pas de commande (peut-être tant qu'on ne fait pas quelque chose qui provoque une régénération du fichier).
-
Le fichier est en binaire, il ne faut pas utiliser vi.
-
Le fichier est en binaire, il ne faut pas utiliser vi.
Donc, c'est fichu?
-
Le /sbin/setup.sh est très intéressant :
#for cramfs debug interface, you can do all like this:
#1. copy /sbin/setup.sh to /mnt/rwdir
#then modify /mnt/rwdir/setup.sh
#2. delete flash_erase /dev/mtd1
#3. delete [ -f /mnt/rwdir/setup.sh ] && /mnt/rwdir/setup.sh && exit
[ -f /mnt/rwdir/setup.sh ] && /mnt/rwdir/setup.sh && exit
Ca nous permet donc de remplacer toute la seconde partie du script, ou juste d'insérer quelques commandes :D
J'ai une idée pour modifier sys.cfg, à condition que "mount --bind" soit supporté.
Ensuite, je ne sais pas si le SWVER qu'il y a dedans sert bien, et si c'est à chaque boot, mais déjà c'est bien mieux que de devoir reflasher.
On peut créer un /mnt/rwdir/setup.sh (qui sera lancé par le /sbin/setup.sh) :
#!/bin/sh
# Allow to replace /etc/sys.cfg
[ -e /mnt/rwdir/sys.cfg ] && mount --bind /mnt/rwdir/sys.cfg /etc/sys.cfg
# make sure /sbin/setup.sh continues, instead of doing "exit"
exit 1
Ne pas oublier de rendre le fichier exécutable : "chmod 0777 /mnt/rwdir/setup.sh"
Ensuite, il suffit de copier /etc/sys.cfg dans /mnt/rwdir/sys.cfg, et le modifier.
Après un reboot, pour tout ce qui est exécuté dans le setup.sh et après, c'est comme si on avait modifié /etc/sys.cfg