Root a Carlinkit TBox With Magisk via QFIL

Should you root at all?

Root gives apps full control of the system. On an AI box, owners root for three reasons: Magisk modules (system-wide sound processing, apps installed as system apps), multitouch on older firmware, and settings Android otherwise locks.

It is the riskiest change on this site. You write to the boot partitions with a low-level tool; a mistake leaves a box that does not start, and a firmware update removes root again. Some banking and streaming apps also refuse to run on rooted devices, and a seller or manufacturer may decline warranty service for a box that has been modified.

Check first whether you need it:

• For multitouch alone, the no-root method is shorter, and the 16 Jun 2026 Ultra 3 firmware already includes it.
• For removing bloat or changing settings, ADB is usually enough.

How rooting with Magisk works

Android boots from a boot image that contains the kernel and a small starting file system (the ramdisk). Magisk adds itself to that ramdisk, so it starts before the rest of Android and can grant root to apps you approve. Nothing else on the box changes.

Carlinkit boxes use A/B slots: there are two copies of each boot partition, boot_a and boot_b, and the box can start from either. That is why you patch both. On the TBox Ambient 6225 with Android 13 the ramdisk lives in a separate partition, so you patch init_boot_a and init_boot_b instead.

QFIL reads and writes these partitions over USB while the box is in EDL mode. Reading is harmless; writing is the step that can brick the box.

Which partitions for which box?

Owners confirmed the Ultra and Ambient rows. The TBox Plus row comes from the community FAQ; follow your model’s recovery package instructions for storage type. If you are unsure of your model, check which TBox do I have.

Steps

C:\Users\<your user>\AppData\Roaming\Qualcomm\QFIL\COMPORT_<n>\

Verify it worked

1. Magisk’s home screen shows an installed version, not “N/A”.
2. Install a root-check app or run su from an ADB shell; Magisk asks you to grant access.
3. Connect to the car and check video, sound and SIM as usual. Root should change nothing visible.
4. Reboot twice. The box must boot reliably before you add modules, one at a time, with a reboot after each.

adb shell
su
id

The last command should print uid=0(root) once you grant the request on the box.

Undo / rollback

There are two levels of undo, and the second one always works as long as you kept your dumps:

1. From Magisk: Uninstall → Complete uninstall. Magisk removes its modules, tries to restore the stock boot image and reboots; if it has no backup of the original, it tells you, and you use the QFIL route below. The community FAQ advises this step before every firmware update.
2. From QFIL: write Original\boot_a.bin and Original\boot_b.bin (or the init_boot pair) back as in the undo block of the write step. This restores the boot partitions bit for bit, even if Magisk is broken.
3. Uninstall the Magisk app itself afterwards.

If you updated the firmware since making the dumps, do not write the old dumps back; they would not match the new system. Use Magisk’s uninstall, a FOTA local update of the same build, or the full recovery package instead.

Keeping root through firmware updates

Root lives in the boot partitions, and every firmware update replaces them. Owners settled on one routine:

1. Note which modules you use and export any app settings you care about.
2. In Magisk choose Uninstall → Complete uninstall and let the box reboot unrooted.
3. Install the new build with the FOTA local update.
4. Dump the new boot_a and boot_b (or init_boot) partitions with QFIL and keep them as your new undo set, labelled with the new firmware date.
5. Patch them in Magisk, write them back, finish setup and reinstall your modules.

Some experienced owners skip the uninstall and flash the update over a rooted box, then re-patch; the Magisk app and its modules survive in the data area. It works for them, but one owner who forgot to uninstall ended up with a factory reset, so the routine above is the safer default.

Two things never carry across builds: dumps and patched images. An image patched from the 21 Oct 2025 build does not belong on the 4 Jan 2026 build, even on the same model.

Troubleshooting this guide

Partition Manager does not open. QFIL is not talking to the box. Use the QFIL inside QPST, check the 9008 port, programmer and storage type, and see the Sahara section of the recovery guide.

Magisk cannot patch the image on the box. An Ultra 1 owner had repeated errors with the Magisk version he had. Another owner suggested a current Magisk release (30 or newer) and patching the same .bin on an Android phone instead; both are sound, because patching does not depend on the device that runs it. Do not fall back to images another owner patched.

Only one of the two images patches. Write the patched A image only and leave B as it was; that worked for an Ambient owner.

The box does not boot after writing. Write the original dumps back. If that fails, flash the full recovery package as described in the QFIL recovery guide, which collects the owners who brought an unbootable Ultra back that way.

A firmware update fails, or the box resets after one. An Ultra owner forgot to remove Magisk before updating and had to factory reset afterwards. Run Magisk’s Complete uninstall first, update with FOTA, then dump and patch the new build’s images. If you also disabled verity for other mods, see firmware update fails after disabling verity.

Modules install but do nothing. Check that Zygisk is on if the module needs it, and that the box runs in the protocol the module expects. Multitouch modules work only in Android Auto mode; see enable multitouch.