The garage is the ground floor of a residential complex, five apartment blocks joined by an elongated structure, four entrances per block. The garage spans the full length at level zero, open-air in the summer but sealed with roller shutters in winter. Apartments start from the first floor. It's not underground. It's just the bottom of a very long building, and right now every shutter is down because it's December.

This has been my routine for weeks. Come home from work, eat, go down to the garage, sit in the car with a laptop until midnight. Sometimes later. The project doesn't have a deadline or a customer. Nobody asked for it. I'm doing it because the car has a CAN bus with 397 IDs on it and I've decoded 34 of them, and I want to know what the other 363 do.

The problem is where the hours come from.

the feed

I did the math at some point in November. Screen time report: Instagram, 45 minutes a day. Twitter, 30 minutes. That's 75 minutes of scrolling every day, or just over 8 hours a week. I wasn't posting, creating, or networking. I was consuming. Reels, threads, takes, drama. None of it was making me better at anything.

75 minutes a day is exactly one garage session. Every evening I spent on the couch scrolling was an evening I didn't spend in the car with a CAN sniffer.

I didn't delete the apps. I installed One Sec, an app that intercepts the launch and makes you wait before it lets you in. Every time you try to open Instagram, it holds you for a breath. Try again too soon and the wait gets longer. Twitter at thirty minutes a day wasn't the problem; Instagram at two hours was. The friction was enough. Within a week I'd stopped opening Instagram almost entirely. Not because it blocked me, but because the pause made me realize I didn't actually want to be there. I just had a habit of tapping the icon.

what the time bought

The numbers are boring but they're real. In the ten weeks after throttling the feed, I:

• Decoded the full BMS PID set (44 PIDs, 35+ fields)
• Captured and catalogued 37 in-car CAN tests in a single night session
• Cracked the door lock checksum table (three separate CAN channels, weeks of captures)
• Wrote a PID scanner that mapped the BMS address space
• Built a working real-time battery monitor
• Started designing the custom board

All of that happened in evening sessions between 9 PM and midnight. If I'd kept scrolling, maybe I'd have gotten to half of it by February.

The cold helped, weirdly. The garage was uncomfortable enough that there was no temptation to do anything except work. No couch, no TV, no distractions. Just me, the car, and the laptop. The discomfort was a forcing function.

the air

The thing about an EV is that it doesn't produce exhaust. You can sit in it for hours with the windows up and the air is fine. I'd internalized this so completely that I forgot where I was parked.

The garage has a hundred-odd parking spots. Most of the cars in it are petrol or diesel. People come home in the evening, pull in, idle for a minute, shut off. In the summer the shutters are open and none of it matters. In December they're all closed. CO doesn't smell, doesn't sting, doesn't announce itself. It just accumulates.

I noticed it as headaches first. Dull, persistent, worse at the end of a session. I blamed the cold, the posture, staring at hex for three hours. Then one night I got back upstairs and the headache didn't go away. I felt nauseous. My chest was tight. I sat on the bathroom floor for twenty minutes before it passed.

I went to the doctor. Bloodwork came back with elevated carboxyhemoglobin. Carbon monoxide poisoning, not acute enough to land me in a hospital, but enough to show up on a test. The source was obvious once I thought about it: three hours a night in a sealed garage where ICE cars had been running earlier that evening, the CO hanging in the still air with nowhere to go.

After that I started opening the nearest shutter before every session, even when it was freezing. The headaches stopped. I kept going to the garage.

the car survived

I locked and unlocked the car thousands of times over these months. Folded and unfolded the mirrors hundreds of times. Raised and lowered every window. Turned the signals on and off, cycled the ambient lights, toggled the climate. Pressed the brake pedal while monitoring CAN frames. Started and stopped charging sessions to capture state transitions.

The car handled all of it without complaint. No warning lights, no weird behavior, no dealer visit. Hyundai builds these things to take abuse from a factory test line. My garage sessions were gentle by comparison.

Reddit

Around the same time, I started spending more time on Reddit. Different dynamic entirely. Reddit has r/ReverseEngineering, r/embedded, r/esp32, communities where people actually discuss CAN bus protocols and ELM327 quirks and ESP32 memory architectures. The content is technical. The comments are useful. When someone posts a teardown or a reverse engineering writeup, the responses are "what tool did you use" and "have you tried this approach," not heart emojis.

I didn't post much. Mostly lurked and read. But the information density per minute spent was incomparably higher than anything I'd gotten from the feed. I learned about OVMS, about the Hyundai EGMP community's existing PID research, about ISO-TP framing edge cases that would have taken me weeks to discover on my own.

Trading consumption for a technical community wasn't a lateral move. It was an upgrade.

the actual lesson

Throttling social media didn't give me superpowers. It gave me 75 minutes a day. That's it. But 75 minutes a day, applied consistently to a single problem for ten weeks, compounds into something that looks from the outside like obsession or talent. It's neither. It's just time, redirected.

The project is nine months old now. Every feature, the CAN decoder, the custom board, the Go backend, the iOS app, the signed OTA pipeline, was built in reclaimed evenings. Not weekends, not vacations, not sabbaticals. Evenings. The ones that used to belong to the feed.

In the next post: I solder a custom PCB, kill it with a capacitor, and learn that 8 KB of stack is not enough for TLS on an ESP32.

Four days later I'll have decoded 35 fields across 8 PIDs, built a real-time battery monitor, and written a PID scanner that maps the entire BMS address space. A month after that I'll have cracked a door lock checksum and found the CAN channel the BCM uses to lock the car internally, without the key fob.

This is the story of the first two months.

talking to the BMS

The Ioniq 6's diagnostic bus (D-CAN) is accessible through the OBD-II port on pins 3 and 11, not the standard pins 6 and 14. This non-standard assignment is something I'd rediscover the hard way months later when wiring custom hardware. The BMS listens at CAN address 0x7E4 and responds on 0x7EC, at 500 kbps. Communication uses UDS (ISO 14229) over ISO-TP (ISO 15765-2), the same protocol stack that dealer tools and Car Scanner use.

The ELM327 handles the low-level CAN framing. From the Python side, the sequence is:

ATZ          # reset
ATE0         # echo off
ATH1         # show CAN headers
ATSP6        # ISO 15765-4, 500 kbps, 11-bit
ATSH7E4      # set TX header to BMS address
2201 01      # UDS ReadDataByIdentifier, PID 0x0101

The response arrives as a First Frame (10 3E 62 01 01 ...) followed by eight Consecutive Frames (21 ... through 28 ...). After ISO-TP reassembly and stripping the 3-byte UDS header (62 01 01), you get 59 bytes of raw BMS data.

Those 59 bytes contain everything: pack voltage, current, power, state of charge, module voltages, coolant temperatures, operating time, and a set of status flags. The problem is figuring out which bytes mean what.

the XOR method

I had two captures: one with the car idle, one while AC charging. Comparing them byte-by-byte revealed exactly which bytes changed between states.

Byte 4 shifted from 0x32 (50 decimal) to 0x34 (52). Divided by 2: 25.0% to 26.0%. That's SoC, and the formula is byte / 2 = percent. Confirmed against the dashboard.

Byte 11 was the interesting one. Idle: 0x03 (0b00000011). Charging: 0x81 (0b10000001). Bit 7 flipped from 0 to 1 during charging and back to 0 when idle. That's the HV charging flag. Bit 0 toggles independently, BMS ignition/awake status.

byte 11 map:
  bit 7 (0x80): HV_Charging  -- 1 = charging active
  bit 1 (0x02): unknown      -- toggles during idle
  bit 0 (0x01): BMS ignition -- 1 = BMS awake

Bytes 5-8 were all zeros when idle and populated during charging, available charge power and current limits that the BMS only reports when a charger is connected.

This XOR-compare approach turned out to be the single most useful technique in the entire project. Capture two known states, diff the bytes, and the changed ones are your signals. I'd use it hundreds more times over the next nine months.

the PID scanner

The BMS responds to UDS Service 0x22 (ReadDataByIdentifier) with 16-bit PIDs. The address space is 0x0000 to 0xFFFF. I wrote pid_scanner.py to walk through ranges and record which PIDs return a positive response (0x62) versus a Negative Response Code.

Result: 44 responding PIDs out of the ranges I scanned. Most of the interesting ones clustered in the 0x2201xx range:

The cell voltage PIDs contain unsigned 16-bit big-endian values scaled by / 50 to get volts. The 54 kWh pack has 96 cells in series (~3.6V nominal each, ~400V total). Between these three PIDs and a few similarly-sized ones I'd discover later, I could read every cell individually.

cracking the temperature encoding

Module temperatures (PID 0x220133, bytes 4-10) were the hardest to decode. The raw values (117, 118, 119) didn't map to any obvious temperature scale. Not Celsius, not Fahrenheit, not tenths of either.

I worked backwards from Car Scanner. It showed module B01 at 20C. The raw byte was 0x76 (118). The offset: 118 - 98 = 20. I checked the other six modules. All matched with the same -98 offset.

"battery_module_temps": {
    "decode": lambda b: [b[i] - 98 for i in range(4, min(11, len(b))) if b[i] > 50]
}

Car Scanner showed 5 module temperatures. My decoder showed 7. First small win.

what the script could do

By the end of October 26 I had a working real-time BMS monitor that decoded more fields than I expected. The script could read individual cell voltages across multiple PIDs, 7 module temperatures, 28 per-module SoH values, pack-level power limits, cumulative energy counters, and round-trip efficiency, on top of the basics like SoC, voltage, current, and charging status.

The BMS's own charging time predictions came from PID 0x2201F2. Bytes 8-9: time to 80% at 50 kW. Bytes 21-22: time at 100 kW. Bytes 114-115: time at 175 kW. These are the BMS's internal estimates based on battery temperature and SoC, not a simple energy-remaining calculation.

All of this from a $15 dongle and a Python script running on a laptop in an apartment garage. No special hardware, no dealer tools, no leaked documentation.

switching buses

Five days later, October 31. I'd been reading BMS data through UDS queries on the D-CAN bus. But diagnostic queries are request-response, the BMS only talks when you ask. For a telemetry device that monitors the car passively, I needed the body CAN bus (B-CAN), where ECUs broadcast state continuously without being asked.

I wired an ESP32-S3 dev board with a CAN transceiver to the B-CAN lines on the OBD port and started capturing.

The first baseline capture showed 194 unique CAN IDs broadcasting continuously, a mix of standard 11-bit and extended 29-bit identifiers.

That night I sat in the car and ran 37 systematic tests. Turn on the left signal, capture 10 seconds. Turn it off, capture. Lock the doors, capture. Open the trunk, capture. Change the gear. Press the brake. Cycle the ambient lighting. Each test compared against the baseline to find which IDs changed and how.

Three new CAN IDs appeared that weren't in the baseline:

0x4D6 was the most interesting. It appeared only during lock/unlock operations -- an event frame, not a periodic broadcast. That made it a candidate for replay: if the car sends this frame when you press the lock button, maybe sending it yourself would lock the car.

Turn signals decoded cleanly. CAN ID 0x413, byte 2: 0x10 = left, 0x40 = right. Byte 0 is a counter/checksum.

the door lock problem

November 17. I'd been trying to lock the car via CAN injection for three weeks. The first target was 0x4D6, the event frame from the inside door lock button.

The frame format: [checksum] [counter] [command] [0x00 x5]. Counter increments by 0x10 per action (0x00, 0x10, 0x20, ... 0xF0, 0x00). Command 0x01 = lock, 0x04 = unlock. The checksum is a per-counter lookup value, not algorithmic.

I built a lookup table from captured frames, tracked the live counter by monitoring 0x4D6 on the bus, and injected frames with the correct next-counter and checksum.

It worked. The doors locked. But the security system didn't arm. No hazard flash, no mirror fold, no "armed" indicator. Just a mechanical click. For a product, this was useless, you need the alarm armed, not just the latches engaged.

the 0x4E4 dead end

The key fob uses CAN ID 0x4E4. When you press the lock button on the fob, the car locks and the alarm arms. So I went after 0x4E4.

Same approach: capture fob lock/unlock events, build a checksum lookup table, track the counter, inject. I captured 25 out of 48 possible checksums (the table has 16 counter values times 3 commands). Good enough for a test.

I injected a valid frame. Nothing happened. Tried again with a different counter. Nothing. Tried every counter value I had a checksum for. The car ignored all of them.

The 0x4E4 channel requires RF authentication. The BCM checks that the physical key fob is nearby via its 433 MHz radio before accepting lock commands on this CAN ID. No amount of correct checksums will work without the fob present. The CAN frame is a notification from the fob's receiver to the BCM, not a command the BCM blindly executes.

Three weeks of checksum capture, wasted. Or so I thought.

the auto-lock insight

November 18. I was thinking about how aftermarket auto-lock modules work. There are commercial products that plug into the Ioniq's B-CAN and lock the car 10 seconds after the driver exits, without the key fob nearby. They use only CAN-H and CAN-L wires. No RF, no key fob relay, no magic.

Then the obvious question: when does the car lock itself without the fob?

Answer: auto-lock. If you unlock the car with the fob but don't open a door within 30 seconds, the BCM re-locks it automatically. The fob isn't nearby when this happens, you walked away, the car decided to re-lock on its own.

I captured the auto-lock sequence. The BCM sends the lock command on **CAN ID 0x392**, not 0x4E4. Same frame format: [checksum] [counter] [command]. But 0x392 is the BCM's own internal command channel. It doesn't check for RF authentication because it is the BCM, the module that would do the checking.

I searched every capture file I'd accumulated over the previous month. Between fob operations, door button presses, auto-lock events, and baseline captures, I found checksums for 14 out of 16 counter values for the LOCK command. 87.5% coverage from data I already had.

const uint8_t CHECKSUM_TABLE_392[16][3] = {
    //        IDLE   LOCK   UNLOCK
    /* 0x00 */ {0xAC, 0xEA, 0xFF},
    /* 0x10 */ {0xFF, 0x53, 0x10},
    /* 0x20 */ {0xC3, 0x76, 0xC6},
    /* 0x30 */ {0x7A, 0x2F, 0x7F},
    /* 0x40 */ {0x72, 0x96, 0xFF},
    /* 0x50 */ {0xCB, 0xD3, 0xFF},
    /* 0x60 */ {0xFF, 0x6A, 0xFF},
    /* 0x70 */ {0xA4, 0xFF, 0xFF},  // LOCK missing
    /* 0x80 */ {0xFF, 0x4B, 0xFF},
    /* 0x90 */ {0xB4, 0x08, 0xFF},
    /* 0xA0 */ {0xFF, 0x24, 0x67},
    /* 0xB0 */ {0xDB, 0x9D, 0xFF},
    /* 0xC0 */ {0xFF, 0xC4, 0xFF},
    /* 0xD0 */ {0xFF, 0x31, 0xFF},
    /* 0xE0 */ {0xFF, 0xFA, 0xFF},
    /* 0xF0 */ {0xFF, 0xFF, 0xFF},  // all missing
};

I injected a LOCK command on 0x392 with the correct counter and checksum. The doors locked mechanically, same as 0x4D6. I also got mirror folding to work through a combination of 0x392 and 0x4D6. But it wasn't reliable. The full alarm arm (hazard flash, interior indicator, the works) never happened consistently. The BCM accepted the lock command but wouldn't fully arm the security system the way a fob press does.

0x4D6 and 0x392 turned out to be the two most reliably injectable CAN IDs on the bus. Both produce a mechanical lock. Neither reliably arms the alarm. The fob channel (0x4E4) remains gated behind RF authentication. Getting the full "fob-quality" lock from CAN injection alone is still an unsolved problem on this car.

three channels, one lesson

The month-long door lock saga didn't end in a clean victory. But the insight that made 0x392 findable, when does the car do this thing by itself?, turned out to be the most important question of the entire project. Whatever channel the car's own BCM uses internally is the one that doesn't need external authentication. That principle would apply to almost every problem I'd hit later.

By the end of November I had passive CAN decoding of body state, UDS access to the full BMS, and mechanical door locking without the fob. The OBD dongle and Python scripts were about to be replaced by custom hardware. But that's the next post.

In the next post: I solder a custom PCB, kill it with a capacitor, and learn that 8 KB of stack is not enough for TLS on an ESP32.

That gap, and the fact that the head unit runs open-source software, made me curious enough to start poking at the car.

the gap

Remote vehicle access is table stakes now. Tesla set the expectation, and everyone from BMW to BYD followed. How much charge do I have? Are the doors locked? Where did I park? Is a window open? These are questions that most modern EVs answer from a phone. Mine answers none of them unless I'm sitting in it.

The car's CAN buses carry hundreds of signals: individual cell voltages, battery health, coolant temperatures, door states, window positions, charge connector status. The driver's display shows maybe six of these. You can see more with a BLE OBD dongle and an app like Car Scanner, but only while the phone is in Bluetooth range with the ignition on. That's diagnostics, not telemetry.

What I wanted was something closer to what BlueLink would have been: a device that stays in the car, connected over LTE, reporting state whether I'm in the cabin or across the city.

what exists, and why it wasn't enough

OVMS is the closest thing to what I want. Open source, community-driven, supports dozens of vehicles. But there's no Ioniq 6 module, the hardware is a generation behind, and adding a new vehicle means reverse engineering the CAN protocol anyway. If I have to do the RE work regardless, I'd rather build on hardware I control.

Commercial fleet solutions target companies with 500-truck fleets. Priced accordingly, designed accordingly. Individual EV owners are not the customer.

ELM327 dongles are $15 and work well for what they are. But they're passive -- phone must be nearby -- have no LTE, no storage, no autonomy. They're a diagnostic tool, not a telemetry platform.

Nothing I found did what I wanted without requiring either a subscription or my location history sent to someone else's server.

what I'm building

An ESP32-S3 board with a CAN transceiver, LTE modem, and GPS, roughly the size of a phone. It lives behind the dashboard, wired to the OBD port, always on.

The firmware is C on ESP-IDF. The backend is Go. The iOS app talks to the device over BLE when nearby and to the backend over HTTPS when not. OTA firmware updates are signed and delivered over LTE.

The car speaks CAN bus and UDS. Every signal the system decodes was reverse engineered by hand: driving with a laptop, capturing frames, correlating byte changes against physical state, validating against known-good sources. There is no public DBC file for this car. The Ioniq 6's B-CAN carries 397 distinct CAN IDs. The firmware currently decodes 34 of them.

The details of how all of this works are the subject of the rest of this series.

why now

It's been nine months. I started with a $15 BLE dongle and a Python script reading OBD PIDs in a parking lot. That turned into passive CAN decoding, then a custom PCB, then a Go backend, then an iOS app, then signed OTA updates, then a fleet management console, then secure boot with burned eFuses.

Along the way I cracked a CRC polynomial only to have the BCM ignore my injected frames. I desoldered a capacitor to fix a PSRAM bus conflict. I discovered that my car's OBD port has non-standard pin assignments. I mined 2.1 GB of CAN logs with a correlation scanner and found a speed signal with r=0.997. I bricked a board with a bad OTA and watched the boot-loop rollback save it.

The project has been closed source so far. I'm planning to open parts of it up. But first, the story.

In the next post: I sit in my car at night with a terminal full of hex, and by morning I've decoded more battery data than Car Scanner shows.

Target: AudioAccessory5,1, Apple S5 (T8006), board b520ap, audioOS 26.3 (Build 23K620), iBoot-13822.80.422.0.2.

USB reconnaissance

With the HomePod Mini plugged into a Mac via USB-C, ideviceinfo connects over usbmuxd and returns detailed device information. Notably, system_profiler SPUSBDataType returns empty. The Mini communicates exclusively through usbmuxd's TCP-over-USB protocol, not as a raw USB device. Tools like irecovery cannot see it in this state.

Key identifiers from normal-mode enumeration:

The device shows TrustedHostAttached: true, meaning lockdownd services are available. NVRAM was also readable: auto-boot = "true", usbcfwflasherResult = "No errors".

DFU mode attempts

No public method to enter DFU mode on the HomePod Mini has ever been documented. I tried multiple button/power combinations while monitoring USB events:

1. Hold touch surface, plug USB-C, plug power (held 20 seconds)
2. Plug USB-C, plug power, hold touch surface through recovery
3. Rapid power cycling (3x) with USB connected, hold touch surface
4. Touch surface hold before any power with USB connected
5. Holding both + and - volume zones simultaneously during power-on

All attempts resulted in normal boot (white light), recovery mode (orange flashing light), or factory reset (3 beeps). Attempt 3 triggered Siri announcing a WiFi connection issue, confirming it was booting to userspace audioOS.

The orange flashing light during standard Finder restore is not iBoot recovery mode. It's a userspace restore daemon running on minimal audioOS.

Entering iBoot recovery mode

Since lockdownd trusts the host Mac, ideviceenterrecovery can instruct the device to reboot into iBoot recovery mode over usbmuxd:

$ ideviceenterrecovery $(ideviceinfo -k UniqueDeviceID)
Telling device with udid 00008006-000629620103C02E to enter recovery mode.
Device is successfully switching to recovery mode.

The HomePod goes completely dark. No orange light, no white light, total silence. Consistent with every other Apple device's bootloader behavior.

First irecovery session with a HomePod Mini

With the device in iBoot recovery mode, irecovery -q connects:

CPID: 0x8006
CPRV: 0x11
BDID: 0x22
ECID: 0x000629620103c02e
CPFM: 0x03
SCEP: 0x01
IBFL: 0x3d
SRTG: N/A
MODE: Recovery
PRODUCT: AudioAccessory5,1
MODEL: b520ap
NAME: HomePod mini

MODE: Recovery (not DFU). This is iBoot, not SecureROM. SRTG: N/A confirms it; DFU mode would show the SecureROM version tag. CPFM: 0x03 means production fused, both production and security bits set. No debug access.

Interactive iBoot shell

irecovery -s opens an interactive shell:

=======================================
::
:: Supervisor iBoot for b520, Copyright 2007-2025, Apple Inc.
::
::      Local boot, Board 0x22 (b520ap)/Rev 0x3
::
::      BUILD_TAG: iBoot-13822.80.422.0.2
::
::      BUILD_STYLE: RELEASE
::
=======================================
Entering recovery mode, starting command prompt

The shell accepts getenv queries. secure-boot returns 0x1, auto-boot returns false. Most variables return "false" (not found): boot-args, debug-enabled, firmware-version. The help command returns empty. bgcolor, version, meminfo, devicetree all silently fail. reboot works. irecovery -n returns the HomePod to normal operation.

iBoot binary analysis

Firmware acquisition

HomePod Mini IPSW files are standard ZIP archives from ipsw.me. The iBoot binary was decrypted using published firmware keys from The Apple Wiki for audioOS 16.6 (Build 20M73):

• IV: 158dd8de55acbe7f475674aa98af825b
• Key: a1b0fc7917caf43613086e68666139733ceefed3715a0aa4277b986af02118dd

The resulting binary is 1,397,928 bytes, arm64e, virtual base 0x180000000.

Command table

The RELEASE iBoot has an extremely minimal command set. Only infrastructure commands are registered: command, menu_loop, poweroff, idleoff, USB handlers (usb, usb req, usb-hi-current, usb-no-current, usb_serial, vbus poll, usb vbus), and boot flow (main, fsboot, upgrade, recover, recover-once, darkboot).

Dead strings present but unreferenced by code: getenv, setenv, bgcolor, bootx, memboot, reboot, reset, go. These are residual string data from shared object files, compiled out via preprocessor guards.

Completely absent: md (memory dump) and mw (memory write) don't exist as strings at all. Not gated, removed entirely.

Security architecture

A11 vs S5: how Apple killed checkm8

To understand how Apple hardened the S5, I compared the HomePod Mini's iBoot against an iPhone X (A11/T8015) iBoot from the same build train. The A11 is the last checkm8-vulnerable chip.

PAC enabled in iBoot

The A11 supports arm64e but Apple never enabled PAC in its iBoot. The S5 has 1,683 PAC-protected functions, 1,432 authenticated returns, and 244 authenticated indirect branches. In the USB code region alone, 455 TBZ checks on bit 62 (PAC signature region). The A11 has zero.

USB handler shrunk 80x

The A11's monolithic USB request handler spans ~16KB with 470 function calls, handling device tree setup, crypto, display init, and battery management inline. The S5 replaced this with a 196-byte thin wrapper making 4 delegated calls.

function-reset removed

The string function-reset exists in the A11 binary at 0x18004bd8c. This is the USB function reset handler that checkm8 directly exploits (the use-after-free occurs during USB function reset). This string and its associated code are entirely absent from the S5 binary. The functionality was either removed or refactored into a new ausb ctr (audio USB controller) abstraction layer that exists only on S5.

Deterministic stack canary

The iBoot stack canary value is **0x4752440044003631**, and it is deterministic, not random. The canary is initialized at 0x1800021e0, which executes before the SVC handler, before MMU setup, and before any entropy subsystem is available. The random_fill() function at 0x18005022c checks a BSS flag that is guaranteed zero at this point, causing it to fall back to a hardcoded seed value.

The ASCII content (GRD\0D061) confirms this is a build tag, not cryptographic randomness. This value is identical across every HomePod Mini running this iBoot version.

If any stack buffer overflow exists anywhere in this iBoot build, the canary provides zero protection. This reduces the mitigation stack from three layers (canary + PAC + controlled value) to two.

Command parser bounds checking

Initial analysis suggested the command tokenizer at 0x180060288 had an out-of-bounds write. The token counter w21 appeared to increment past a CMP w21, 6 soft limit. Deeper analysis of the CCMP/CSEL pattern disproved this:

CMP   w21, 6           ; compare token count
CCMP  w8, 0, 4, le     ; if w21 <= 6: compare next_byte to null
                        ; if w21 > 6: force flags to nzcv=0100 (Z=1)
CSEL  w8, w25, wzr, eq ; if Z=1: state = 2 (dispatch/exit)

When w21 > 6, the CCMP's le condition fails, forcing Z=1 regardless of w8. The CSEL picks w25 = 2 (command dispatch = function exit). Maximum 7 entries (indices 0-6) are written into a 10-slot array. Well within bounds.

The command parser is correctly bounded. The CMP + CCMP + CSEL pattern creates an effective hard limit.

Exhaustive iBoot attack surface audit

Image4 / DER / ASN.1 parser

The DER/ASN.1 parser at 0x180063e88 is Apple's libDER. Every byte read has pointer range validation (start <= ptr < end), the multi-byte length accumulator has overflow detection at each iteration (LSR + CBNZ), indefinite length forms are rejected, non-minimal encodings are rejected, and the final content_start + content_length addition has an explicit overflow check. Strict mode is set for the DFU input path.

LZFSE / LZSS decompression

Three layers protect against decompression overflow: the IM4P header validation caps uncompressed size at ~190MB, the heap allocator adds 0x200 bytes of headroom, and the LZFSE decoder contains 40+ CMP x20 bounds checks.

ausb ctr USB controller

The S5 USB stack is fundamentally redesigned:

• No use-after-free possible. The 6,144-byte USB transfer buffer is calloc()'d once at 0x180031d94, stored at BSS 0x18015b9a8, and never freed. Only 2 references exist in the entire binary.
• Zero indirect calls. The entire USB region (0x18002f000-0x180033000) contains no BLR, BLRAA, or BRAAZ instructions. All calls are direct BL.
• Fixed sub-buffer layout. 6,144 bytes partitioned at compile-time: EP0 setup 256B, EP0 data out 2048B, EP0 data in 1024B, bulk in 1024B, bulk out 1028B. No dynamic buffer sizing.
• Minimal state machine. Single abort flag byte, single busy flag byte, single-threaded loop.

The bootloader attack surface is effectively closed through static analysis.

audioOS network attack surface

With iBoot exhausted, I shifted to the running audioOS.

The root filesystem contains 254 daemons and 3 apps. Four daemons bind network ports:

Live Bonjour reconnaissance confirmed AirPlay on port 7000 with acl=0 (no access control, any LAN device can connect).

OPACK wire format reverse engineering

Apple's OPACK is a proprietary binary serialization format used by RemoteXPC and remotepairingdeviced. It is parsed before authentication during the pairing handshake. I reverse-engineered it from __OPACKDecodeObject at 0x19380c320 in CoreUtils.framework.

Arrays and dictionaries are recursive, each call using ~0x70 bytes of stack. Recursion depth limit is 32 levels (CMP w8, 0x20 at 0x19380cd74). Tag 0x64 allows a 4-byte length prefix (up to ~4GB), creating potential allocation overflow in the CFStringCreate path.

remotepairingdeviced: less open than advertised

Despite the ExposedToUntrustedDevices: true flag, the daemon has multiple layers of gating:

1. TCP listener disabled by default. The string "Not configuring launchd-managed TCP control channel due to 'deviceAllowTCPControlChannel' not being set to true" reveals the TCP listener requires an explicit flag.
2. Requires prior pairing. TCP channel only activates after at least one host has been paired via USB or Bluetooth.
3. Promptless pairing is USB-only and time-limited. "USB host disconnected; promptless pairing disabled".
4. Network pairing requires consent via the Home app on a paired iPhone.
5. Bluetooth-triggered listener. The primary discovery path is BLE proximity, not an always-on service.

For a LAN-only attacker, the TCP control channel is likely inactive on a stock HomePod Mini. The most promising network target is tvairplayd on port 7000.

AirPlay protocol analysis

Live HTTP probing of tvairplayd:

The /pair-setup endpoint implements HomeKit pair-setup using SRP-3072. Sending a valid M1 message returned a valid M2 response with a 16-byte salt and 384-byte SRP server public key.

The classic SRP-zero bypass (A = 0) was blocked. HTTP 470, Apple validates the SRP public key before computation.

After a single failed M3 message, the HomePod imposed a 64,259-second lockout (~18 hours). Approximately 1.3 attempts per day per HomePod.

/pair-verify: Curve25519 key exchange

To establish a session, I implemented the complete pair-verify protocol. This is the standard AirPlay session establishment flow, documented in the pyatv and pair_ap libraries:

1. M1 to M2: Sent Curve25519 public key, received server's ephemeral key + encrypted data.
2. Shared secret: Curve25519 ECDH exchange computed.
3. Session key: HKDF-SHA-512 with salt "Pair-Verify-Encrypt-Salt" and info "Pair-Verify-Encrypt-Info".
4. M2 decrypted: ChaCha20-Poly1305 with nonce "PV-Msg02" revealed TLV8 containing identifier 16F9D2EF-3E51-49C2-BD7B-2F145D422227 and a 64-byte Ed25519 signature.
5. M3 sent: The server successfully decrypted M3 but rejected with Error=1 because the fabricated identifier was not in its paired peers list.

The /pair-verify endpoint accepts requests with no rate limiting, though the final authorization check (peer identity lookup) prevents unauthorized session establishment.

AirPlay transient pairing: establishing a session

AirPlay 2 has two pairing families: HomeKit-based (SRP via /pair-setup) and legacy PIN (via /pair-pin-start). All prior testing targeted the HomeKit path.

The HomePod Mini in "Anyone on the Same Network" mode accepts transient pairing with PIN 3939. This is documented, intentional behavior for screenless AirPlay devices -- the pair_ap library and pyatv both document it. Screenless devices cannot display a dynamic PIN, so Apple uses a well-known static value. Anyone running Home Assistant connects to their HomePod this way daily.

POST /pair-pin-start         → initiates PIN display (no-op on screenless HomePod)
POST /pair-setup (state=1)   → SRP M1, server returns M2 with salt + public key B
POST /pair-setup (state=3)   → SRP M3 with proof using PIN "3939"
                             → server returns M4, authenticated session established
POST /pair-verify            → derives encrypted session keys

All steps must occur on the same TCP socket. Session state is per-connection. Using separate HTTP requests fails because context is lost between connections. This is the standard mechanism for establishing an AirPlay session from a non-Apple device on the local network.

SendVoiceInput crashes MRP data channel

With the authenticated session, the HomePod exposes a Media Remote Protocol channel. Sending any MRP SendVoiceInput message (type 31), even empty, causes the data channel to terminate immediately.

Root cause: mediaremoted's _handleVoiceDataReceivedMessage:fromClient: calls _MRVirtualVoiceInputProcessAudioData which requires an externalDevice context not initialized for AirPlay MRP tunnel connections. Null-reference bug in the device lookup path.

TLV8 parser truncation

The TLV8 parser returns HTTP 500 on truncated input:

Stable through 100+ consecutive requests. The exception is caught and does not cause memory corruption.

Findings

Every remote vector is either PIN-gated, rate-limited, or requires an established trust relationship. The real bugs are in the post-auth path: the MRP null dereference and the pre-auth parser crashes.

The research is reproducible by anyone with a HomePod Mini, a Mac, and brew install libimobiledevice libirecovery.

Tools