Bricked Itel A18 After Flashing VBMeta, I Can't Access Recovery or Bootloader. Please
Bricked Itel A18 After Flashing VBMeta, I Can't Access Recovery or Bootloader. Please
22-04-2026, 07:29 PM
Hi Hovatek and everyone,
I'm hoping you can assist me with my bricked Itel A18. Here's what happened:
I unlocked the bootloader using the token identifier method.
I then signed the VBMeta using your tutorial.
I flashed the custom signed VBMeta image using the command:
fastboot flash vbmeta vbmeta_custom.img
in FastbootD mode. Fastboot confirmed that it was flashed to the vbmeta_b partition.
Now, my phone won't boot past the Itel logo, and I can’t access either recovery mode or the bootloader (since on this model, the bootloader is accessed via recovery).
I’ve tried flashing the stock ROM and stock VBMeta image using multiple versions of the SP Research Download Tool and Upgrade and Factory tools, but nothing works. After downloading fdl1-sign.bin and fdl2-sign.bin, some tools give an "Input Time" error after 32 seconds, while others throw an "Incompatible Partition" error. I've installed the correct drivers and have the exact ROM version for my device. I've even tried multiple versions of the Itel A18 ROM, but the same errors continue to occur.
Some additional questions I have:
Should I have flashed to vbmeta_a as well?
Or should I have flashed the signed Magisk-patched boot image immediately after flashing the VBMeta, before issuing the fastboot reboot command?
Do the fdl1-sign and fdl2-sign files check the firmware being flashed? Could this be causing the issue, preventing the stock VBMeta and ROM from being restored?
Any help or suggestions would be greatly appreciated. Thank you in advance for your assistance
Attached Files
22-04-2026, 07:33 PM
I'm hoping you can assist me with my bricked Itel A18. Here's what happened:
I unlocked the bootloader using the token identifier method.
I then signed the VBMeta using your tutorial.
I flashed the custom signed VBMeta image using the command:
fastboot flash vbmeta vbmeta_custom.img
in FastbootD mode. Fastboot confirmed that it was flashed to the vbmeta_b partition.
Now, my phone won't boot past the Itel logo, and I can’t access either recovery mode or the bootloader (since on this model, the bootloader is accessed via recovery).
I’ve tried flashing the stock ROM and stock VBMeta image using multiple versions of the SP Research Download Tool and Upgrade and Factory tools, but nothing works. After downloading fdl1-sign.bin and fdl2-sign.bin, some tools give an "Input Time" error after 32 seconds, while others throw an "Incompatible Partition" error. I've installed the correct drivers and have the exact ROM version for my device. I've even tried multiple versions of the Itel A18 ROM, but the same errors continue to occur.
Some additional questions I have:
Should I have flashed to vbmeta_a as well?
Or should I have flashed the signed Magisk-patched boot image immediately after flashing the VBMeta, before issuing the fastboot reboot command?
Do the fdl1-sign and fdl2-sign files check the firmware being flashed? Could this be causing the issue, preventing the stock VBMeta and ROM from being restored?
Any help or suggestions would be greatly appreciated. Thank you in advance for your assistance!
Attached Files
23-04-2026, 05:02 PM
(22-04-2026, 07:33 PM)t3chJunki3 Should I have flashed to vbmeta_a as well?
Or should I have flashed the signed Magisk-patched boot image immediately after flashing the VBMeta, before issuing the fastboot reboot command?
You definitely made a mistake when building your custom vbmeta.
You should ideally first build a replica of the stock vbmeta to be sure everything works fine before you consider swapping flags or keys. What you flash along with the custom vbmeta depends on the configurations you set when building the custom vbmeta
As things stand, you'll need a paid Unisoc tool to flash the pac file.
This post was last modified: 23-04-2026, 05:03 PM by hovatek.
Learn MediaTek, Unisoc / Spreadtrum (SPD) and Qualcomm Software Repairs @ https://www.hovatek.com/training
Note!
We have a reply schedule for Forum Support. Please try Private Support if you can't wait.
23-04-2026, 05:37 PM
(23-04-2026, 05:02 PM)hovatek(22-04-2026, 07:33 PM)t3chJunki3 Should I have flashed to vbmeta_a as well?
Or should I have flashed the signed Magisk-patched boot image immediately after flashing the VBMeta, before issuing the fastboot reboot command?
You definitely made a mistake when building your custom vbmeta.
You should ideally first build a replica of the stock vbmeta to be sure everything works fine before you consider swapping flags or keys. What you flash along with the custom vbmeta depends on the configurations you set when building the custom vbmeta
As things stand, you'll need a paid Unisoc tool to flash the pac file.
I followed the tutorial and can’t think of where I might have gone wrong. When you say “build a replica of the stock vbmeta,” what exactly do you mean? When building my custom vbmeta, I used the newly generated public key for the boot partition and used the same key to sign my patched boot.img.
Also, what are some examples of the paid UniSoc tools, and where can I get them?
24-04-2026, 04:24 PM
(23-04-2026, 05:37 PM)t3chJunki3 ..
I followed the tutorial and can’t think of where I might have gone wrong. When you say “build a replica of the stock vbmeta,” what exactly do you mean? When building my custom vbmeta, I used the newly generated public key for the boot partition and used the same key to sign my patched boot.img.
First, you build a custom-stock-vbmeta.img. When you run python3 avbtool.py info_image on this vbmeta and stock vbmeta, their outputs should be 100% identical. You must also check for the DHTB in the hex editor.
The reason for this custom stock image is to confirm that all your keys (private and public) are correct/compatible. If it boots fine, then you can proceed with swapping public keys etc.
*Note that some models don't support changing the --flag from 0 to anything else
(23-04-2026, 05:37 PM)t3chJunki3 Also, what are some examples of the paid UniSoc tools, and where can I get them?
Cheetah tool, Hydra, CM2, UnlockTool, Pandora etc
You can check their official websites
This post was last modified: 24-04-2026, 04:24 PM by hovatek.
Learn MediaTek, Unisoc / Spreadtrum (SPD) and Qualcomm Software Repairs @ https://www.hovatek.com/training
Note!
We have a reply schedule for Forum Support. Please try Private Support if you can't wait.
04-05-2026, 08:13 AM
(24-04-2026, 04:24 PM)hovatekQuote:First, you build a custom-stock-vbmeta.img. When you run python3 avbtool.py info_image on this vbmeta and stock vbmeta, their outputs should be 100% identical. You must also check for the DHTB in the hex editor.
The reason for this custom stock image is to confirm that all your keys (private and public) are correct/compatible. If it boots fine, then you can proceed with swapping public keys etc.
*Note that some models don't support changing the --flag from 0 to anything else
I ran info_image on my custom and stock vbmeta images, and they are nearly identical. The only difference is that the custom vbmeta has a flags value of 2 and a different key for boot. I also noticed that on the stock vbmeta, dtbo and boot share the same public key, if that’s relevant. So, if I have a device that doesn’t support changing the flag value to 2, would that mean changing the key for the boot partition while leaving the flag value at 0? What’s the difference between paid tools and free flash tools that allows them to flash my phone? And what is a legitimate site I can rent from?
This post was last modified: 04-05-2026, 08:16 AM by t3chJunki3.
05-05-2026, 09:01 AM
(23-04-2026, 05:02 PM)hovatek You definitely made a mistake when building your custom vbmeta. You should ideally first build a replica of the stock vbmeta to be sure everything works fine before you consider swapping flags or keys. What you flash along with the custom vbmeta depends on the configurations you set when building the custom vbmeta. As things stand, you'll need a paid Unisoc tool to flash the pac file.
After further research, it seems the issue is most likely a verified boot failure caused either by a mismatch between the vbmeta files in the _a and _b partitions, or by a boot key mismatch between the custom vbmeta and the stock boot.img, since I hadn’t flashed the patched, signed one. Would you mind taking a look at my vbmeta images to confirm whether I built the custom one correctly?
Attached Files
Users browsing this thread:
1 Guest(s)
1 Guest(s)
Users browsing this thread:
1 Guest(s)
1 Guest(s)
