Redmi Note 12 Pro 5G Rooting: MTKClient and FolkTool

While using crDroid on my Redmi Note 12 Pro 5G, I wanted to keep root access under my own control as well. To do that, I backed up the device's original boot partitions with MTKClient, then patched the boot image with FolkTool and flashed it to the phone through Fastboot.

I paid particular attention to the A/B partition layout during this process because the device has two separate boot partitions, boot_a and boot_b. To avoid using the wrong image or working on the wrong slot, I first inspected the partition table, then backed up both images separately.

I previously described the steps I followed to install crDroid on my device in the Redmi Note 12 Pro 5G crDroid installation guide. This article covers rooting after installing the ROM.

Device and tools I used#

I performed this procedure on a Xiaomi Redmi Note 12 Pro 5G (ruby).

Links to the projects I used:

• MTKClient GitHub repository
• FolkTool GitHub repository
• FolkTool 1.7.1 release page

The FolkTool 1.7.1 release notes mention the KernelPatch 0.13.3 adaptation and the process of obtaining root through FolkPatch/APatch. I used this version to patch the boot image.

1. Viewing the partition table with MTKClient#

First, I viewed the device's partition table through MTKClient:

python mtk.py printgpt

The command listed the partitions on the device. What stood out was that there were two partitions, boot_a and boot_b, instead of a single boot partition. The vendor_boot_a and vendor_boot_b partitions were also listed.

This layout showed that the device used an A/B partition scheme. So, rather than backing up just one boot image, I decided to save both slots as separate files.

2. Backing up the original partitions#

Before patching, I copied the original files to my computer. I gathered the backups in a folder named IMEI_Yedek.

These are the backups I made:

The command I used to back up the boot partitions:

python mtk.py r boot_a,boot_b .\IMEI_Yedek\boot_a.img,.\IMEI_Yedek\boot_b.img

The operation completed successfully. Both boot images were 128 MiB.

I backed up the preloader with this command:

python mtk.py dumppreloader

At this stage, I did not write to or erase any partition with MTKClient. I only viewed the partition table and made backups.

For MTKClient commands and other usage examples, see the project's usage documentation.

3. Checking the active boot slot#

After completing the backups, I checked with ADB which slot the device was booted from:

adb shell getprop ro.boot.slot_suffix

Output:

_a

That meant the device was running from slot A.

This was important because the file I selected for patching would be boot_a.img. I first made sure I had backed up the correct image, then gave that file to FolkTool.

4. Patching the boot image with FolkTool 1.7.1#

After opening FolkTool, I selected the boot_a.img file backed up with MTKClient as the input file.

The source file used in the operation log appeared at this location:

C:\Users\baba\Desktop\Work\mtkclient\IMEI_Yedek\boot_a.img

FolkTool unpacked the kernel, detected the GZIP-format kernel, and patched it. It then repackaged the image.

The log included these messages:

Kernel patched successfully
Patch complete

The file it created:

C:\Users\baba\Documents\FolkTool\patched\boot_patched_2026-10-24 21-46-46.img

According to the FolkTool log, the created image was 128 MiB.

The important point here is that the source for the patch was the original boot_a.img I had taken directly from the device. This meant I did not use an image taken from another firmware package whose compatibility with the software currently on the device was uncertain.

5. Flashing the patched image with Fastboot#

After patching was complete, FolkTool put the device into Fastboot mode and flashed the image it had created to the phone.

The command used in the log was:

fastboot flash boot "C:\Users\baba\Documents\FolkTool\patched\boot_patched_2026-10-24 21-46-46.img"

The tool reported that the flash operation had completed:

Flash completed successfully
Flash successful
fastboot reboot
Device rebooted successfully
One-click flash completed!

The phone restarted and Android booted normally.

However, I also wanted to verify which slot the operation had written to, because the command explicitly said boot, not boot_a.

Verifying the Fastboot target slot#

After the phone started, I used ADB to put the device back into Fastboot mode:

adb reboot bootloader

Then I ran these commands:

fastboot getvar current-slot
fastboot getvar has-slot:boot

Outputs:

current-slot: a
Finished. Total time: 0.000s

has-slot:boot: yes
Finished. Total time: 0.000s

These results confirmed that slot A was active and that the boot partition supported slots.

In Android's A/B system, Fastboot targets the currently active slot unless another slot is explicitly specified. Therefore, considering the device's slot information, the fastboot flash boot command in the operation log targeted the boot_a partition.

For details about this behavior, see the Android Open Source Project A/B system documentation.

After checking, I restarted the device:

fastboot reboot

The phone returned to Android normally.

6. Verifying root access through ADB#

After the phone started, I wanted to check root access.

First, I connected to the ADB shell:

adb shell

Then:

su

On my first attempt, I did not get the result I expected and saw this error:

/system/bin/sh: su: inaccessible or not found

On a later check, the su command worked and the terminal prompt switched to a root shell:

ruby:/ $
ruby:/ #

Still, rather than relying only on the changed prompt, I queried the root identity directly. For that, I ran this command in the computer's terminal:

adb shell su -c id

Output:

uid=0(root) gid=0(root) groups=0(root) context=u:r:magisk:s0

The uid=0(root) value clearly shows that the command ran with root privileges. This way, I did not rely only on FolkTool reporting a successful flash; I verified root access directly on the device.

I cannot determine from the available output exactly why the first su attempt failed. So rather than attribute a cause to that error, I rely on the later successful check.

Conclusion#

I completed the rooting process on my Xiaomi Redmi Note 12 Pro 5G (ruby) using MTKClient and FolkTool 1.7.1.

First, I viewed the partition table with MTKClient and backed up the boot_a and boot_b images. Then I patched boot_a.img with FolkTool and flashed the resulting image to the device through Fastboot.

After the operation, the phone booted normally. Fastboot checks showed that slot A was active and that the boot partition supported slots. Finally, the adb shell su -c id command returned uid=0(root).

The most important things for me in this process were backing up the original images before the operation and verifying the result directly on the device afterward. A tool reporting "Flash successful" does not, by itself, prove that root access is working.

I also covered another issue I encountered while using crDroid on the Redmi Note 12 Pro 5G. I described my experience with the e-Devlet app's NFC access and MIUI permission controls in my article about the e-Devlet NFC issue and MIUI permission problem on crDroid.

If you're considering a similar procedure, don't skip the backup step. Especially on devices with an A/B partition layout, you need to use the correct image, check the target slot, and actually verify root access.

Sources#

• MTKClient GitHub repository
• MTKClient usage documentation
• FolkTool GitHub repository
• FolkTool 1.7.1 release and change notes