Can I use kaeru on my device?

This section of the wiki explains how to determine whether your device is eligible to run kaeru.

Background

Note

DO NOT skip this section. This is IMPORTANT INFORMATION and not reading it could potentially lead to UNEXPECTED BRICKS!

As stated in the project's initial README, this payload only supports ARMv7 MediaTek bootloaders. Before proceeding to the next page, which explains how to set up a development environment for kaeru, it’s important to first confirm whether your device can boot unsigned bootloaders. This will help prevent the risk of bricking your device and save you time.

To understand how this works, we need to know how, why, and when LK is verified, and by whom. This is where knowledge of the MediaTek bootchain becomes useful.

On MediaTek devices, the Preloader (primary bootloader) is responsible for loading and verifying the integrity of the LK image. On non-legacy MediaTek devices, the LK partition contains two headers, cert1 and cert2, which the Preloader uses to verify the image. On most devices, if the LK partition is altered, the Preloader refuses to boot the image, and the device falls back to BootROM mode (if available).

Whether or not images are verified is controlled by something called the sec policy, which is bundled into the Preloader itself. I'm not 100% sure, but I believe the Preloader's verification process works differently. The BootROM will attempt to verify the Preloader if the SBC fuse is blown; otherwise, it will accept any Preloader image.

As far as I can tell, the security policy supports three different modes (or at least, these are the ones I've identified so far):

• (1) Never verify: Images are never verified, even if the bootloader is locked. This mode is quite rare but still present on quite a few Chinesebrand phone(s).
• (2) Verify only when the bootloader is locked: Images are verified as long as the bootloader's unlock status is set to false in seccfg (locked bootloader).
• (3) Always verify, no matter what: As the name implies, images are always verified regardless of the bootloader state. If your device uses this policy for LK, you can forget about using kaeru.

These security policies are usually determined by the ODM (Original Design Manufacturer) of the device, rather than the brand itself. For example, many Nokia phones use Type 1, while others use Type 3. The key difference lies in the company that actually manufactured the phone, such as Huaqin, Longcheer, Tinno, and others.

(these numbers were added by me and are not directly associated with the policies, they're just for reference while reading this wiki.)

Verifying if I can use kaeru

As you might have guessed already, the easiest way to check which security policy your device has (and thus know whether you should proceed) is to make a small edit to your stock LK image to invalidate its signature and then flash it back to the device. On most devices, LK can be flashed using mtkclient.

To make it easy to confirm whether the device is actually booting the modified bootloader, you should change something that gets printed to the screen, such as the generic => FASTBOOT mode... message. As explained in my post, I typically modify it to => SLOWBOOT mode... (pun intended). After flashing it, I boot directly into fastboot mode and check the screen.

You can accomplish this either by using the UNIX sed command or by manually editing the string with a hex editor of your choice (I personally recommend ImHex).

The following example demonstrates how to do it with sed:

r0rt1z2@r0rt1z2 $ sha1sum lk.bin && strings lk.bin | grep "=> FASTBOOT"
94f51bb62f635a885c00c7b5fd34d83faf2f4b80  lk.bin
 => FASTBOOT mode...
r0rt1z2@r0rt1z2 $ sed -i 's|=> FASTBOOT mode...|=> SLOWBOOT mode...|g' lk.bin                        
r0rt1z2@r0rt1z2 $ sha1sum lk.bin && strings lk.bin | grep "=> SLOWBOOT"
1b9a901d98ced599d9a83e1f30aabaf83c099a83  lk.bin
 => SLOWBOOT mode...
r0rt1z2@r0rt1z2 $

As you can see, the hash of the image has changed, which means its signature has been invalidated as well.

Caution

If your device uses the third security policy type, THE FOLLOWING STEP WILL MOST LIKELY BRICK IT, so make sure you have a reliable way to recover it.

Warning

Since you still don't know what type of security policy your device uses, it's highly recommended to unlock the bootloader (if possible) before proceeding to the next step. This way, if your device uses the second type, it won’t brick and will be able to load the unsigned image.

Now, simply flash the modified LK image back to the device and try to boot into fastboot mode. If the device boots and you see the modified text on the screen, congratulations! YOUR DEVICE IS COMPATIBLE WITH KAERU. You can skip over to the next section of the wiki!

If your device refuses to boot, it most likely failed to verify the integrity of the modified image and, as a result, won't boot. To fully confirm that your device uses a strict security policy, you can dump expdb using mtkclient or any other tool of your choice, and then run UNIX strings on it.

Devices where the Preloader attempts to verify the integrity of the modified bootloader will display something like this:

[SEC_POLICY] reached the end, use default policy
[SBC] cert verify, part = lk, img = lk...ok
[PART] part: lk img: lk cert vfy(17 ms)
[PART] load speed: 10254KB/s, 1081700 bytes, 103ms
[SBC] img auth fail(0x101004)
fail(0x101004)
<ASSERT> .../platform/mtxxx/src/core/partition.c:line XXX X
PL fatal error...
PL delay for Long Press Reboot

If this is the case for you, you're out of luck and should stop reading here. Restore your original LK image to recover your device's functionality.

Continue here

The next page explains how to add support for a new device to kaeru.

Continue: Porting kaeru to a new device