
Exporté automatiquement depuis code.google.com/p/firmware-mod-kit
Exporté automatiquement depuis code.google.com/p/firmware-mod-kit
Kit de modification de firmware
Ce kit est un ensemble de scripts et d'utilitaires pour extraire et reconstruire des images de firmware basées sur Linux.
Extraire une image de firmware en ses composants
L'utilisateur effectue les modifications souhaitées sur le système de fichiers du firmware ou l'interface Web (webif)
Reconstruire le firmware
Flasher le firmware modifié sur l'appareil et le bricker (ha)
ATTENTION : Vous allez bricker votre appareil en utilisant ce kit (peut-être pas, mais mieux vaut dire que vous le ferez). Bricker signifie le transformer en une 'brique' non fonctionnelle. La récupération est parfois possible sans modifications matérielles. Parfois, elle nécessite des modifications matérielles (par exemple, des connecteurs série ou JTAG soudés sur le circuit imprimé). Parfois, elle n'est tout simplement pas réalisable, ou coûterait plus cher en récupération que la valeur de l'unité.
N'utilisez PAS ce kit si vous n'êtes pas prêt à voir votre routeur brické !
CLUF : En téléchargeant ou en utilisant ce kit, vous acceptez d'assumer la responsabilité des conséquences de l'utilisation ou de la mauvaise utilisation du Firmware Mod Kit. Celles-ci incluent le brickage de votre appareil. Les auteurs de ce kit vous ont dûment averti. Ce kit est destiné uniquement aux ingénieurs logiciels de systèmes embarqués.
Le Firmware Mod Kit permet une déconstruction et reconstruction faciles des images de firmware pour divers appareils embarqués. Bien qu'il cible principalement les routeurs basés sur Linux, il devrait être compatible avec la plupart des firmwares utilisant des formats de firmware et des systèmes de fichiers courants tels que TRX/uImage et SquashFS/CramFS.
Pour utiliser le Firmware Mod Kit, vous devez disposer d'un client subversion, des outils de développement Linux standard (gcc, make, etc.), du module python-magic, ainsi que des paquets de développement zlib et lzma. Si vous utilisez une distribution Linux qui utilise apt-get, par exemple Ubuntu ou Debian, utilisez :
Pour Ubuntu 18.04 et plus ancien :
sudo apt-get install git build-essential zlib1g-dev liblzma-dev python-magic autoconf
Pour Ubuntu 20.04 et plus récent :
sudo apt-get install git build-essential zlib1g-dev liblzma-dev python3-magic autoconf python-is-python3
Pour RedHat :
yum groupinstall "Development Tools"
yum install git zlib1g-dev xz-devel python-magic zlib-devel util-linux
Pour Arch Linux :
Il existe un paquet AUR pour https://aur.archlinux.org/packages/firmware-mod-kit/
Pour les autres distributions, vous devez installer les paquets équivalents à l'aide du gestionnaire de paquets de votre distribution.
git clone https://github.com/rampageX/firmware-mod-kit.git
cd firmware-mod-kit/src
make
Binwalk 2.1.1
[De retour dans le répertoire firmware-mod-kit]
cd src/binwalk-2.1.1
sudo python2 setup.py install
Le Firmware Mod Kit est uniquement supporté sur la plateforme Linux. Avec quelques petites modifications, il devrait fonctionner sur d'autres plateformes POSIX.
Clonez le dépôt du Firmware Modification Kit avec Git.
Le Firmware Mod Kit est un ensemble d'utilitaires et de scripts shell. Les utilitaires peuvent être utilisés directement, ou les scripts shell peuvent être utilisés pour automatiser et combiner des opérations courantes sur les firmwares (par exemple, extraction et reconstruction). Les scripts de base pour faciliter les opérations sur les firmwares sont listés ci-dessous.
Scripts principaux :
| Script | Description |
|---|---|
| extract-firmware.sh | Script d'extraction du firmware |
| build-firmware.sh | Script de reconstruction du firmware |
Scripts secondaires :
| ddwrt-gui-extract.sh | Extrait les fichiers de l'interface Web GUI du firmware DD-WRT extrait. |
|---|---|
| ddwrt-gui-rebuild.sh | Restaure les fichiers modifiés de l'interface Web GUI dans le firmware DD-WRT extrait. |
Le Firmware Mod Kit utilise un répertoire de travail 'codé en dur' nommé 'fmk'. Le script d'extraction extrait dans ce dossier, et le script de reconstruction reconstruit à partir de ce dossier. La tolérance de répertoires de travail alternatifs est prise en charge pour certaines opérations, mais pas toutes. Nous étendrons cela à l'avenir. Pour l'instant, si vous avez plusieurs répertoires de travail, nous vous suggérons de renommer ceux sur lesquels vous n'opérez pas actuellement.
L'extraction automatisée du firmware fonctionne généralement avec la plupart des images de firmware qui utilisent des en-têtes uImage/TRX et des systèmes de fichiers SquashFS ou CramFS. Actuellement, extract-firmware.sh est la méthode d'extraction préférée car elle prend en charge plus de types de firmware que l'ancien script old-extract.sh. Cependant, old-extract.sh est toujours inclus et fonctionne avec de nombreux formats de firmware.
L'utilisation des deux scripts extract-firmware.sh et build-firmware.sh est simple :
./extract-firmware.sh firmware.bin
Par défaut, la sortie de extract-firmware.sh se trouvera dans le répertoire 'fmk', tandis que old-extract.sh placera les données extraites dans le répertoire de travail spécifié.
Le script de reconstruction à utiliser dépend du script d'extraction utilisé. Si vous avez extrait une image de firmware avec extract-firmware.sh, vous devez utiliser build-firmware.sh pour la reconstruire. De même, si old-extract.sh a été utilisé, alors old-build.sh doit être invoqué lors de la reconstruction d'une image :
./build-firmware.sh [-nopad] [-min]
Le nouveau firmware généré par build-firmware.sh se trouvera dans 'fmk/new-firmware.bin', tandis que old-build.sh générera des images de firmware dans plusieurs formats différents et les sauvegardera dans le répertoire de sortie spécifié.
Le paramètre optionnel -nopad indiquera à build-firmware.sh de NE PAS remplir le firmware jusqu'à sa taille d'origine.
Le paramètre optionnel -min utilisera la taille de bloc squashfs maximale de 1 Mo. Cela réduira la taille de l'image du firmware au prix de ressources CPU et RAM supplémentaires utilisées sur l'appareil cible. N'utilisez ce paramètre que si vous y êtes obligé. Il s'agit d'une taille de bloc très grande pour les systèmes embarqués. La taille de bloc squashfs d'origine du firmware est conservée lors de la reconstruction, et la taille de bloc d'origine doit être celle utilisée, sauf si vous êtes sûr de ce que vous faites. Une taille de bloc trop grande peut sembler fonctionner correctement, mais les performances du firmware en cours d'exécution peuvent souffrir dans toutes ou certaines charges.
Une fonctionnalité très unique du Firmware Mod Kit est sa capacité à extraire et reconstruire les fichiers de l'interface Web GUI de DD-WRT. Cela est automatisé par les scripts ddwrt-gui-extract.sh et ddwrt-gui-restore.sh.