How to Get the Correct Boot or Init_Boot Image for Magisk

The difficult part of many Magisk installations is not pressing “patch.” It is knowing whether the file being patched belongs on that phone.

A search for your model can produce images from different regions, monthly builds and custom ROMs. They may all be named boot.img. That filename tells you almost nothing about compatibility.

Get the original image from the firmware or custom ROM that matches the software currently installed on your device. Confirm whether its supported Magisk procedure uses boot, init_boot, recovery or another explicitly supported arrangement. Keep the original untouched, and patch on the device that will use it. Magisk's own instructions warn against using another person's patched image, even for the same model.source 1

This guide is about identifying and obtaining the image. It deliberately does not end with a universal flashing command.

Build a firmware identity record first

Open Settings > About phone and record the exact model and build number. Also record whether the phone is running manufacturer firmware or a custom ROM, and whether it is on a stable or beta channel.

On a computer with authorized ADB access, these read-only queries can help collect the software identity:

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

These are identifiers to compare, not automatic proof that an arbitrary download is compatible. An OEM can use different labels in Settings and on its firmware page. A custom ROM can also report information differently.

Use this record beside every candidate download:

An image from “Android 16” is not specific enough. Neither is “the September update.” Compare the full build identifier.

A real source of confusion: the right model, wrong firmware branch

In an XDA Xiaomi 13 discussion, a user trying to locate an exact EEA build described confusion between firmware packages and extracting boot-related images from an OTA. The useful lesson is not to copy the next flashing command in the thread. It is to establish the device's branch and complete build before selecting an archive.source 8

A guide written for one regional build can remain searchable long after its download stops matching your phone.

Decide whether you need boot.img or init_boot.img

Do not decide solely from the Android version shown in Settings.

AOSP moved the generic ramdisk into a separate init_boot image for devices launching with Android 13. Devices upgraded from older architectures were not universally required to adopt that layout. This is why two phones running the same Android release can need different rooting instructions.source 2

Use the current official Magisk instructions together with a maintained guide for the exact device:

The vendor_boot support point comes from Magisk's official changelog.source 3 The installation choices and Samsung exception are covered in its installation documentation.source 1

Do not patch every image and try them one after another. Uncertainty about the partition is a reason to stop before flashing, not a reason to experiment on a working primary phone.

Choose the best original source

Pixel: factory image or full OTA

Google provides official factory images and full OTA packages. A factory image archive can contain the original partition images needed for inspection or extraction. A full OTA is a different package type intended for the OTA installation process.source 4source 5

Downloading or extracting an archive does not itself flash the phone. Running a factory flashing script is a separate, potentially destructive action. Google warns that factory-image installation erases data; its full OTA procedure generally does not require an unlocked bootloader or data wipe.source 4source 5

For this task, you are obtaining a file. There is no reason to run flash-all just to look inside a factory archive.

Other manufacturers: match the actual package format

Start at the manufacturer's firmware or support channel. When firmware is not publicly available for your exact build, check a maintained device-specific thread for the acquisition method, not just a direct attachment from an unknown account.

A fastboot archive, a recovery update ZIP and a small incremental update may have very different contents. Download size alone does not identify the package, and renaming its extension does not convert it.

On Samsung, the AP package and Odin workflow are a distinct case. A standalone boot image extracted from that package is not permission to substitute generic fastboot instructions.source 1

Custom ROM: start with that ROM's own release

When the installed software is a custom ROM, a stock image for the same phone is not automatically the right original. Use the ROM maintainer's release files and installation guidance for that exact version.

Keep custom-kernel changes in your record too. “Stock image” can mean the manufacturer's image or the unmodified image from a custom ROM. Those are not necessarily the same file.

Method 1: extract an image already inside the firmware archive

Create a new folder named after the device and full build. Keep the downloaded archive in that folder and inspect its contents with a reputable archive utility.

Some firmware downloads contain another image archive inside the outer ZIP. Continue into the appropriate nested archive and locate the image identified by the device's supported rooting procedure.

Preserve three things separately:

1. The original downloaded archive.
2. The unmodified extracted image.
3. Any later Magisk-patched output.

Do not overwrite the original with the patched result. An image named boot.img is not meaningfully identified unless its source build is recorded beside it.

For example, your own folder structure could look like this:

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

The names above illustrate organization, not files from a tested device.

Method 2: extract boot images from payload.bin

Many OTA archives contain payload.bin instead of loose partition images. One maintained open-source option is ssut/payload-dumper-go.source 6

Download the appropriate release from that project's repository, follow its platform prerequisites and keep verification enabled. The current project documents an xz dependency and supports reading a ZIP containing a payload directly as well as a separate payload file.source 6

With the tool installed in your command path, first list the available partitions:

payload-dumper-go -l payload.bin

If the required partition is init_boot, extract only that partition:

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

For a device whose documented target is boot, use:

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

These are alternatives, not two mandatory steps. On Windows, when running the executable from its own folder in PowerShell, use ./payload-dumper-go.exe in place of the command name.

Wait for the process to finish successfully. A created output file or a progress bar reaching a high percentage is not a substitute for a successful exit and verification.

Full and incremental OTAs are not interchangeable

An incremental update can require images from the preceding build. The current extractor supports some delta operations using base images, but documents unsupported operations including PUFFDIFF, ZUCCHINI and LZ4DIFF_*.source 6

For a straightforward rooting preparation task, prefer an available full package for the exact build. If extraction asks for base images you do not have, stop. Do not disable verification merely to get a file with the expected name.

“An extraction tool supports incremental OTAs” is not the same as “every partition in every incremental OTA can be reconstructed without its original base.”

Method 3: Magisk 31's remote OTA extraction

Magisk v31.0 introduces extraction of boot images from remote OTA URLs. Its official September 4, 2026 release is marked prerelease in the research snapshot for this guide.source 7

This can reduce the inconvenience of downloading and unpacking a complete OTA manually. It does not remove the need to choose the correct device, firmware branch, build or patch target.

Use an original firmware URL, not a random “pre-rooted image” link. Check the resulting image's provenance just as carefully as a locally extracted file. The release announcement does not establish compatibility with every manufacturer's firmware container.

There is no need to move a stable daily-use installation onto a prerelease solely because it has a more convenient extraction feature. The manual source-and-extract workflow remains useful. See the corrected Magisk release guide for the distinction between stable and prerelease channels.

Verify the download and preserve a checksum

When the official download page publishes a SHA-256 checksum, calculate the checksum of the same downloaded file and compare the full value.

On Windows PowerShell:

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

On macOS:

shasum -a 256 original-download.zip

On Linux:

sha256sum original-download.zip

A checksum is meaningful only relative to a trustworthy expected value. A hash posted beside an image by the same unknown uploader does not establish that it is official.

You can also record a checksum of your extracted original for your own change tracking. Do not compare an extracted init_boot.img hash with the checksum published for the complete ZIP; they are different files.

Before patching, add the source URL, download date, build identifier and extraction method to your notes. This is much more useful during recovery than a folder full of files named new-boot-final.img.

Patch only after the identity checks pass

Magisk's documented file-patching workflow operates on the chosen image on the target device and produces a separate patched output. Keep that output associated with both the original build and the Magisk version that created it.source 1

A successful patch means Magisk processed the input. It does not independently prove that the input belongs on your phone.

Do not substitute a generic fastboot boot command for understanding the image format. In particular, a ramdisk-only init_boot image is not interchangeable with a complete boot image.source 2

If flashing has already failed, pause here and use Magisk flash-failure diagnosis. If the computer cannot detect the bootloader, use fastboot device detection troubleshooting. Neither problem is solved by guessing another firmware image.

Do not use an older image as an improvised rollback

A working original image is valuable, but rollback rules still apply. Google's factory-image page documents anti-rollback warnings affecting the Pixel 6 family, including the May 2025 bootloader transition.source 4

Do not assume the other A/B slot is safe, that an old image can always boot, or that a downgrade is harmless because the package is official. An official package can be authentic and still be inappropriate for the current bootloader state.

Also keep normal Magisk updates separate from Android OTA updates. The latter have their own slot and installation sequence. Our rooted-phone OTA recovery guide covers that different problem.

Frequently asked questions

Can I use a boot image from the same model and Android version?

Not on that information alone. Match the installed firmware or ROM build and applicable variant. A marketing model name and an Android major version are not a complete compatibility check.

What if my firmware has boot.img but no init_boot.img?

Do not rename it. Devices have different boot architectures. Confirm the maintained instructions for your device and the actual archive contents.source 2

Does extracting firmware wipe data?

Extracting files on a computer does not flash the phone. Unlocking, installing or running a factory flashing script is separate. Do not perform those actions merely to obtain an image.

Can someone send me their patched image?

Magisk specifically warns against that approach, even for the same model.source 1 Obtain your own matching original and patch it on the target phone.

What if the exact build is unavailable?

Do not choose the nearest filename. Wait for the correct package or follow a documented device-specific update plan that puts the phone and its available original images on the same supported build.

The checkpoint that matters

Before flashing, you should be able to finish this sentence without guessing:

“This is the original image for this device and this installed build, this is why its partition is the correct patch target, and this is where I kept the untouched original.”

If one part is missing, resolve it before proceeding. That is a better recovery strategy than hoping a factory reset will repair a mismatched boot image.

Sources and scope

Research checked September 28, 2026. Extraction commands follow the named project's documented syntax; no firmware package was downloaded, extracted or flashed as a hands-on test for this article.

• Source 1: Magisk, official installation instructions, including file patching, target-device warning and Samsung-specific installation. Open source
• Source 2: AOSP, “Generic boot partition,” including launch-versus-upgrade architecture and the role of init_boot. Open source
• Source 3: Magisk official changelog, including v30.3 vendor_boot support. Open source
• Source 4: Google, factory images for Pixel devices, data-wipe and anti-rollback warnings. Open source
• Source 5: Google, full OTA images for Pixel devices. Open source
• Source 6: ssut/payload-dumper-go, maintainer README, extraction options, verification and incremental-operation limitations. Open source
• Source 7: Magisk v31.0 official prerelease, September 4, 2026. Open source
• Source 8: XDA Xiaomi 13 discussion, exact-build and boot/init_boot extraction confusion. Historical community account, not a verified universal procedure. Open source