Comment obtenir la bonne image boot ou init_boot pour Magisk

La partie difficile dans beaucoup d’installations de Magisk n’est pas d’appuyer sur « patch ». C’est de savoir si le fichier patché correspond bien à ce téléphone.

Une recherche sur votre modèle peut renvoyer des images de régions différentes, de versions mensuelles et de ROM personnalisées. Elles peuvent toutes s’appeler boot.img. Ce nom de fichier ne dit presque rien de la compatibilité.

Récupérez l’image d’origine dans le firmware ou la ROM personnalisée qui correspond au logiciel actuellement installé sur votre appareil. Vérifiez si la procédure Magisk prise en charge utilise boot, init_boot, le recovery ou un autre montage explicitement pris en charge. Gardez l’original intact et patchez sur l’appareil qui s’en servira. Les instructions de Magisk déconseillent d’utiliser l’image patchée d’une autre personne, même pour le même modèle.source 1

Ce guide explique comment identifier et obtenir l’image. Il ne se termine volontairement pas par une commande de flash universelle.

Commencez par une fiche d’identité du firmware

Ouvrez Paramètres > À propos du téléphone et notez le modèle exact et le numéro de build. Notez aussi si le téléphone tourne sous le firmware du fabricant ou sous une ROM personnalisée, et s’il est sur un canal stable ou bêta.

Depuis un ordinateur disposant d’un accès ADB autorisé, ces requêtes en lecture seule aident à relever l’identité du logiciel :

adb shell getprop ro.product.device
adb shell getprop ro.build.display.id
adb shell getprop ro.build.version.incremental
adb shell getprop ro.build.fingerprint

Ce sont des identifiants à comparer, pas une preuve automatique qu’un téléchargement quelconque est compatible. Un fabricant peut employer des libellés différents dans les Paramètres et sur sa page de firmware. Une ROM personnalisée peut aussi renvoyer ces informations autrement.

Gardez cette fiche à côté de chaque téléchargement candidat :

Une image « Android 16 » n’est pas assez précise. « La mise à jour de septembre » non plus. Comparez l’identifiant de build complet.

Une source réelle de confusion : le bon modèle, mais la mauvaise branche de firmware

Dans une discussion XDA sur le Xiaomi 13, un utilisateur cherchant un build EEA précis confondait les paquets de firmware et l’extraction d’images liées à boot depuis une OTA. La leçon utile n’est pas de recopier la commande de flash suivante du fil. C’est d’établir la branche de l’appareil et son build complet avant de choisir une archive.source 8

Un guide écrit pour un build régional peut rester accessible dans les résultats de recherche longtemps après que son téléchargement a cessé de correspondre à votre téléphone.

Déterminez si vous avez besoin de boot.img ou d’init_boot.img

Ne vous fiez pas uniquement à la version d’Android affichée dans les Paramètres.

AOSP a déplacé le ramdisk générique dans une image init_boot distincte pour les appareils lancés avec Android 13. Les appareils mis à niveau depuis des architectures plus anciennes n’étaient pas tous tenus d’adopter cette organisation. C’est pourquoi deux téléphones sous la même version d’Android peuvent exiger des instructions de root différentes.source 2

Appuyez-vous sur les instructions officielles actuelles de Magisk, avec un guide à jour pour l’appareil exact :

La prise en charge de vendor_boot vient du journal des modifications officiel de Magisk.source 3 Les choix d’installation et l’exception Samsung sont décrits dans sa documentation d’installation.source 1

Ne patchez pas toutes les images pour les essayer l’une après l’autre. Un doute sur la partition est une raison de s’arrêter avant de flasher, pas d’expérimenter sur un téléphone principal qui fonctionne.

Choisissez la meilleure source d’origine

Pixel : image d’usine ou OTA complète

Google fournit des images d’usine officielles et des paquets OTA complets. Une archive d’image d’usine peut contenir les images de partition d’origine nécessaires à l’inspection ou à l’extraction. Une OTA complète est un autre type de paquet, destiné au processus d’installation OTA.source 4source 5

Télécharger ou extraire une archive ne flashe pas le téléphone. Lancer un script de flash d’usine est une action distincte, potentiellement destructrice. Google prévient que l’installation d’une image d’usine efface les données ; sa procédure d’OTA complète n’exige en général ni bootloader déverrouillé ni effacement des données.source 4source 5

Ici, vous cherchez à obtenir un fichier. Il n’y a aucune raison d’exécuter flash-all juste pour regarder le contenu d’une archive d’usine.

Autres fabricants : respectez le format réel du paquet

Commencez par le canal de firmware ou d’assistance du fabricant. Si le firmware de votre build exact n’est pas public, cherchez la méthode d’obtention dans un fil à jour propre à l’appareil, et non dans une simple pièce jointe d’un compte inconnu.

Une archive fastboot, un ZIP de mise à jour recovery et une petite mise à jour incrémentale peuvent avoir des contenus très différents. La taille du téléchargement seule n’identifie pas le paquet, et changer son extension ne le convertit pas.

Sur Samsung, le paquet AP et la procédure Odin forment un cas à part. Une image boot isolée extraite de ce paquet ne justifie pas d’appliquer des instructions fastboot génériques.source 1

ROM personnalisée : partez de la version publiée par cette ROM

Quand le logiciel installé est une ROM personnalisée, une image stock du même téléphone n’est pas forcément le bon original. Utilisez les fichiers de version du mainteneur de la ROM et ses consignes d’installation pour cette version exacte.

Notez aussi les changements de kernel personnalisé. « Image stock » peut désigner l’image du fabricant ou l’image non modifiée d’une ROM personnalisée. Ce n’est pas forcément le même fichier.

Méthode 1 : extraire une image déjà présente dans l’archive du firmware

Créez un nouveau dossier nommé d’après l’appareil et le build complet. Gardez-y l’archive téléchargée et inspectez son contenu avec un utilitaire d’archives reconnu.

Certains firmwares contiennent une autre archive d’images dans le ZIP principal. Poursuivez dans l’archive imbriquée adéquate et repérez l’image indiquée par la procédure de root prise en charge pour l’appareil.

Conservez séparément trois éléments :

1. L’archive d’origine téléchargée.
2. L’image extraite non modifiée.
3. Tout résultat ultérieur patché par Magisk.

N’écrasez pas l’original avec le résultat patché. Une image nommée boot.img n’est pas réellement identifiée si son build d’origine n’est pas noté à côté.

Par exemple, votre propre arborescence pourrait ressembler à ceci :

firmware-work/
  device-codename_full-build-id/
    original-download.zip
    source-notes.txt
    original/
      init_boot.img
    patched/
      magisk_patched_actual-filename.img

Les noms ci-dessus illustrent une organisation, ce ne sont pas des fichiers d’un appareil testé.

Méthode 2 : extraire les images boot depuis payload.bin

De nombreuses archives OTA contiennent payload.bin au lieu d’images de partition séparées. Une option open source maintenue est ssut/payload-dumper-go.source 6

Téléchargez la version adaptée depuis le dépôt du projet, respectez les prérequis de votre plateforme et laissez la vérification activée. Le projet actuel documente une dépendance xz et sait lire aussi bien un ZIP contenant un payload qu’un fichier payload séparé.source 6

Une fois l’outil accessible dans votre PATH, listez d’abord les partitions disponibles :

payload-dumper-go -l payload.bin

Si la partition requise est init_boot, extrayez uniquement celle-ci :

payload-dumper-go -p init_boot -o extracted payload.bin

Pour un appareil dont la cible documentée est boot, utilisez :

payload-dumper-go -p boot -o extracted payload.bin

Ce sont deux variantes, pas deux étapes obligatoires. Sous Windows, si vous lancez l’exécutable depuis son propre dossier dans PowerShell, utilisez ./payload-dumper-go.exe à la place du nom de la commande.

Attendez la fin du processus avec succès. Un fichier créé ou une barre de progression à un pourcentage élevé ne remplace pas un code de sortie réussi et une vérification.

Les OTA complètes et incrémentales ne sont pas interchangeables

Une mise à jour incrémentale peut exiger les images du build précédent. L’extracteur actuel gère certaines opérations delta à partir d’images de base, mais documente des opérations non prises en charge, dont PUFFDIFF, ZUCCHINI et LZ4DIFF_*.source 6

Pour une simple préparation au root, préférez un paquet complet disponible pour le build exact. Si l’extraction réclame des images de base que vous n’avez pas, arrêtez-vous. Ne désactivez pas la vérification juste pour obtenir un fichier au nom attendu.

« Un outil d’extraction gère les OTA incrémentales » ne signifie pas que « chaque partition de chaque OTA incrémentale peut être reconstituée sans sa base d’origine ».

Méthode 3 : l’extraction OTA à distance de Magisk 31

Magisk v31.0 introduit l’extraction d’images boot depuis des URL d’OTA distantes. Sa version officielle du 4 septembre 2026 est marquée préversion dans l’état des recherches de ce guide.source 7

Cela peut réduire les contraintes du téléchargement et de la décompression manuels d’une OTA complète. Cela ne dispense pas de choisir le bon appareil, la bonne branche de firmware, le bon build ou la bonne cible de patch.

Utilisez l’URL d’un firmware d’origine, pas un lien « image pré-rootée » au hasard. Vérifiez la provenance de l’image obtenue avec autant de soin que pour un fichier extrait en local. L’annonce de la version n’établit pas la compatibilité avec le conteneur de firmware de chaque fabricant.

Inutile de faire passer une installation stable d’usage quotidien sur une préversion uniquement pour sa fonction d’extraction plus pratique. La procédure manuelle d’obtention puis d’extraction reste utile. Consultez le guide corrigé des versions de Magisk pour la différence entre canaux stable et préversion.

Vérifiez le téléchargement et conservez une somme de contrôle

Quand la page de téléchargement officielle publie une somme de contrôle SHA-256, calculez celle du même fichier téléchargé et comparez la valeur complète.

Sous Windows PowerShell :

Get-FileHash -Algorithm SHA256 .\original-download.zip

Sous macOS :

shasum -a 256 original-download.zip

Sous Linux :

sha256sum original-download.zip

Une somme de contrôle n’a de sens que face à une valeur attendue digne de confiance. Un hash publié à côté d’une image par le même inconnu ne prouve pas qu’elle est officielle.

Vous pouvez aussi noter la somme de contrôle de votre original extrait pour votre propre suivi. Ne comparez pas le hash d’un init_boot.img extrait à la somme publiée pour le ZIP complet : ce sont deux fichiers différents.

Avant de patcher, ajoutez à vos notes l’URL source, la date de téléchargement, l’identifiant de build et la méthode d’extraction. C’est bien plus utile pour une récupération qu’un dossier plein de fichiers nommés new-boot-final.img.

Ne patchez qu’une fois les vérifications d’identité réussies

La procédure de patch de fichier documentée par Magisk s’applique à l’image choisie sur l’appareil cible et produit une sortie patchée distincte. Associez cette sortie au build d’origine et à la version de Magisk qui l’a créée.source 1

Un patch réussi signifie que Magisk a traité le fichier fourni. Cela ne prouve pas que ce fichier a sa place sur votre téléphone.

Ne remplacez pas la compréhension du format d’image par une commande fastboot boot générique. En particulier, une image init_boot réduite au ramdisk n’est pas interchangeable avec une image boot complète.source 2

Si le flash a déjà échoué, faites une pause et consultez le diagnostic d’échec de flash Magisk. Si l’ordinateur ne détecte pas le bootloader, passez au dépannage de la détection fastboot. Aucun de ces problèmes ne se règle en essayant une autre image de firmware au hasard.

N’utilisez pas une ancienne image comme retour arrière improvisé

Une image d’origine qui fonctionne est précieuse, mais les règles de retour arrière s’appliquent quand même. La page des images d’usine de Google documente des avertissements anti-rollback concernant la famille Pixel 6, dont la transition du bootloader de mai 2025.source 4

Ne supposez pas que l’autre slot A/B est sûr, qu’une ancienne image démarre toujours, ni qu’un retour en arrière est anodin parce que le paquet est officiel. Un paquet peut être authentique et pourtant inadapté à l’état actuel du bootloader.

Séparez aussi les mises à jour normales de Magisk des mises à jour OTA d’Android. Ces dernières ont leur propre slot et leur propre séquence d’installation. Notre guide de récupération OTA d’un téléphone rooté traite ce problème distinct.

Questions fréquentes

Puis-je utiliser une image boot du même modèle et de la même version d’Android ?

Pas sur cette seule information. Faites correspondre le build du firmware ou de la ROM installé et la variante applicable. Un nom commercial de modèle et une version majeure d’Android ne suffisent pas à vérifier la compatibilité.

Que faire si mon firmware contient boot.img mais pas init_boot.img ?

Ne le renommez pas. Les appareils n’ont pas tous la même architecture de boot. Vérifiez les instructions à jour pour votre appareil et le contenu réel de l’archive.source 2

L’extraction du firmware efface-t-elle les données ?

Extraire des fichiers sur un ordinateur ne flashe pas le téléphone. Le déverrouillage, l’installation ou l’exécution d’un script de flash d’usine sont des actions distinctes. Ne les faites pas simplement pour obtenir une image.

Quelqu’un peut-il m’envoyer son image patchée ?

Magisk le déconseille expressément, même pour le même modèle.source 1 Procurez-vous votre propre original correspondant et patchez-le sur le téléphone cible.

Et si la version exacte est introuvable ?

Ne prenez pas le nom de fichier le plus proche. Attendez le bon paquet, ou suivez un plan de mise à jour documenté pour l’appareil qui place le téléphone et ses images d’origine disponibles sur le même build pris en charge.

Le point de contrôle qui compte

Avant de flasher, vous devriez pouvoir terminer cette phrase sans deviner :

« Voici l’image d’origine de cet appareil et de ce build installé, voici pourquoi sa partition est la bonne cible de patch, et voici où j’ai conservé l’original intact. »

S’il manque un élément, réglez-le avant de continuer. C’est une meilleure stratégie de récupération que d’espérer qu’une réinitialisation d’usine répare une image boot incompatible.

Sources et périmètre

Recherches vérifiées le 28 septembre 2026. Les commandes d’extraction suivent la syntaxe documentée du projet cité ; aucun paquet de firmware n’a été téléchargé, extrait ni flashé en test pratique pour cet article.

• Source 1 : Magisk, instructions d’installation officielles, dont le patch de fichier, l’avertissement sur l’appareil cible et l’installation propre à Samsung. Consulter la source
• Source 2 : AOSP, « Generic boot partition », dont l’architecture au lancement ou après mise à niveau et le rôle d’init_boot. Consulter la source
• Source 3 : Journal des modifications officiel de Magisk, dont la prise en charge de vendor_boot en v30.3. Consulter la source
• Source 4 : Google, images d’usine des appareils Pixel, avertissements sur l’effacement des données et l’anti-rollback. Consulter la source
• Source 5 : Google, images OTA complètes des appareils Pixel. Consulter la source
• Source 6 : ssut/payload-dumper-go, README du mainteneur, options d’extraction, vérification et limites des opérations incrémentales. Consulter la source
• Source 7 : Préversion officielle de Magisk v31.0, 4 septembre 2026. Consulter la source
• Source 8 : Discussion XDA sur le Xiaomi 13, confusion sur le build exact et l’extraction boot/init_boot. Témoignage communautaire ancien, pas une procédure universelle vérifiée. Consulter la source