Inside the Carlinkit wireless CarPlay dongle: same silicon, different label

An i.MX6 UltraLite wearing a fake AT91SAM9260 marking

The hardware table at the top of the repository is the most useful single artefact, because it establishes what the dongle actually is. The SoC is a Freescale i.MX6 UltraLite with an ARM Cortex-A7 core on ARMv7, and the CPU line records a fake ATMEL AT91SAM9260 marking, which means the product presents itself as a much older and much weaker chip than it is.

Memory is a Macronix 25L12835F 16MB flash part and Micron or SK Hynix 1Gb RAM running as 64x16. The radio section is the interesting part, because it lists a set of possible Wi-Fi and Bluetooth chips: RTL8822BS, RTL8822CS and RTL8733BS from Realtek, the Fn-Link L287B-SR from Marvell, LGX4358 and LGX8354S from Broadcom, and IW416 from NXP.

The README states the hardware base has stayed almost exactly the same since the beginning, with only the case and design changing, such as thermal pads on the V4 and holes for air flow on the V5. Whatever Wi-Fi chip is fitted, it is connected over the SDIO protocol as a high speed 4-bit SD link at 50MHz, for a maximum of 25MB/s, or 200Mbps.

So the device is one board with a variable radio, and the radio part number is the variable that decides what firmware will run on it. The repository is organised around that fact, with directories for Custom_Firmware, Datasheets, Debug_Tools, Extracted, Firmware, Firmware_Tools, Flash_Dump, IMX_eFuses, Kernel, Nulled, Pictures, U-Boot and the Updater-App notes.

U2W, U2AW and U2AC are marketing names, not hardware

The product names map to software capabilities rather than to different boards. Carlinkit created its own segmentation mainly for marketing using different softwares, and the README lists the tiers.

The 1.0, 2.0 and 3.0 boxes are U2W, meaning CarPlay Wired OEM for Wireless CarPlay. The 4.0 box is U2AW, meaning Carplay Wired OEM for Wireless CarPlay plus Wireless Android Auto. The 5.0 box is U2AC, meaning Carplay Wired OEM or Android Auto Wired OEM for both Wireless CarPlay and Wireless Android Auto.

Read that list closely and the shape of the market becomes clear. The difference between a 1.0 and a 5.0 dongle is which protocol stack the firmware enables, on a platform whose hardware the README says barely changed. A buyer paying for a 5.0 is paying for a firmware capability that could, in principle, be enabled on a cheaper unit by the vendor at any time.

That is the context for the rest of the repository. The work is not about different chips, it is about finding out which firmware image the hardware will accept, and the author has done that by dumping and comparing images across units.

Obfuscated tarballs stopped being usable in 2021.03.06

The repository started when the author gained root access by flashing a custom image back in 2020. The firmware images at that point were just obfuscated tarball archives, and unpacking and repacking them needed nothing more than building a dictionary of the obfuscation.

That did not last. The README states that Carlinkit was made aware of the repository, changed the firmware image packing in the 2021.03.06 firmware with a new binary, and that binary was pwned in 2025. In later firmwares the kernel was hardened to block usage of strace, which is the standard tool for following syscalls into a binary, and that hardening is specifically what closes off reversing the binaries that way.

Two things follow. First, the unpacking work in the repository applies to the older image format, so a tool written for it will not work against current firmware without the later binary being understood. Second, the strace blocking shows the direction of travel: each time the format is broken open, the vendor changes the format again. A reverse engineering project in this space is a moving target rather than a solved problem, and the 2025 pwn of the newer binary is a data point about how much work each round takes.

Firmware conversion is a matrix, and most of it does not boot

The most concrete thing the repository contains is a table of which firmware can be written onto which device, tested against real hardware. The method is to rewrite the flash chip using a programmer, with ASProgrammer, XGEcu devices and a Raspberry Pi all listed, or to gain root access through software by flashing any Custom Firmware that is available.

The results are not uniformly positive. Converting 1.0, 2.0 and 3.0 units to U2AW is marked as working, with firmware limits listed per Wi-Fi chip, and the Fn-Link L287B-SR accepts any firmware. Converting 4.0 to U2W and 5.0 to U2W is also marked as working, with the Realtek RTL8733BS explicitly excluded as not possible. Going to U2AC is where it fails: 2.0 to U2AC does not boot, 3.0 to U2AC is marked as possibly working with the 2023.10.14.1711 firmware, and 4.0 to U2AW and 5.0 to U2AW are both marked as not booting.

The pattern in the notes is that the working conversions are constrained by the radio, with firmware dates such as 2023.10.16.0952 for the RTL8822CS and 2022.07.29.1635 for the RTL8822BS, so a conversion is a function of board generation, radio part number and firmware date together.

The README closes this section with the warning that matters most: save your original flash in a safe place before trying any of this, because the flash is the only copy of the device's identity.

The running system is a jffs2 root on QSPI NAND

The filesystem section is short and it gives the exact memory layout of the running device, which is what you need to reason about a flash dump. The kernel command line shows a QSPI partition scheme, with 256k for u-boot, 3328K for the kernel and 12800K for the rootfs, on a jffs2 root.

$ cat /proc/cmdline
console=ttyLogFile0 root=/dev/mtdblock2 rootfstype=jffs2 mtdparts=21e0000.qspi:256k(uboot),3328K(kernel),12800K(rootfs) rootwait quiet rw

The partition table is confirmed by the mtd listing, which shows the three regions with their erase sizes.

$ cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00040000 00010000 "uboot"
mtd1: 00340000 00010000 "kernel"
mtd2: 00c80000 00010000 "rootfs"

The disk usage output is also telling, because the root filesystem is at 85 percent used with 1860K available, and there is a large vfat partition mounted at /mnt/UPAN with almost nothing on it. Whatever else the device does, it was built with a tight root and a separate storage area, which is exactly the kind of constraint that decides whether a firmware image fits at all.

The rooting path is documented in two halves. For a dump, the Flash_Dump directory and a Raspberry Pi or another programmer with a clip are used, and Flash_Dump/Tools covers rootfs extraction. Once custom firmware behaviour is restored, Dropbear for SSH can be installed and root access obtained.

A custom u-boot can be built, but it cannot be signed

The repository includes a U-Boot directory and documents the build, which is a level deeper than most users of the dongle ever need to go. The toolchain is a Debian style apt install with an ARM cross compiler, and the build uses the i.MX6ULL evaluation kit configuration from the upstream ARM software u-boot tree.

apt-get install device-tree-compiler gcc-arm-linux-gnueabihf
export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabihf-
git clone https://github.com/ARM-software/u-boot.git
make mx6ull_14x14_evk_defconfig
make all

The wall comes immediately after. The device enumerates as SP Blank 6ULL when powered by USB-OTG, and the README states that it is not possible to flash a custom u-boot using imx_usb because it is signed. The secure boot chain is closed at the very first stage, and everything in the Kernel and IMX_eFuses directories exists because the boundary is at the boot ROM and the e-fuses rather than in the Linux kernel.

The practical reading is that the u-boot build is useful for reading and understanding the boot chain, not for replacing it. Any firmware change therefore has to happen at the flash level, through a programmer, which is the reason the Flash_Dump and Firmware_Tools work is the centre of gravity of the project.

Activation is the vendor's to grant, not yours to flash

The most important line in the README is a caveat rather than a feature. Carlinkit controls device activation through a file at /etc/uuid_sign, so a device will work but be blocked in activation mode, and new activations now require a login and password that nobody has.

That sentence changes what this repository is for. Flashing a newer firmware does not grant a paid feature, because the licence state lives on the device and the vendor issues the credentials. The repository does not document a way around that, and nothing here should be read as one.

The corollary for a reader is straightforward. If you own a dongle and it works, flashing the wrong image is the only real risk, and the table of conversions exists so you can check first. If you want wireless CarPlay and do not own a dongle, this repository will not get you one, and the activation state of any unit you acquire will still be set by the vendor.

The licence field on the repository says GPL-3.0, which covers the documentation and any code in it, and it says nothing about the firmware images, the datasheets or the vendor's activation terms, which are separate matters. The repository also links to a small set of related projects for people who want to go further, including catplay-labs/catplay, described as an open source complete rewrite in Rust for the Carlinkit Mini Ultra Dongle, plus carlinkit-modding, an Unbrik-Carlinkit-V3 project, and a CPC200-CCPA firmware dump.

Editorial conclusion

Use this repository if you own a Carlinkit dongle and need to understand its hardware, its firmware packaging or why a firmware swap does not boot, since the conversion matrix and the filesystem layout are the concrete value it holds. Do not treat it as a way to obtain a paid feature: the vendor controls device activation through /etc/uuid_sign, so a flashed device can still sit in activation mode and new activations require a login and password that the author says nobody has. Before rewriting the flash, dump and keep your original image, and check the matrix row for your exact Wi-Fi chip, since several conversions are marked as not booting and one is marked as not possible for the Realtek RTL8733BS.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. ludwig-v/wireless-carplay-dongle-reverse-engineering on GitHub
4. README