How I vibe-coded a macOS driver to rescue my Drobo 5D from

My Drobo 5D has been sitting dead since Apple killed kernel extensions in macOS 12.3. The hardware is solid — five bays, Thunderbolt 2, hardware RAID — but Data Robotics went under and the proprietary driver never made the jump to DriverKit. Rather than drop $800 on a Synology, I spent three weekends letting Claude Code write the IOKit glue while I handled the hardware spec reverse-engineering.

The problem space

Drobo speaks a custom SCSI-over-Thunderbolt protocol. The old kext implemented a user-client that exposed /dev/drobo* character devices, then a userspace daemon translated block requests into vendor-specific CDBs. Without the kext, the Thunderbolt controller enumerates but the SCSI target never appears in diskutil list.

$ ioreg -l -p IOService | grep -i drobo
    |   |   | +-o IOThunderboltDevice  <class IOThunderboltDevice, id 0x1000003b5, registered, matched, active, busy 0 (0 ms), retain 7>
    |   |   |   | +-o DROBO 5D  <class IOThunderboltDevice, id 0x1000003b6, registered, matched, active, busy 0 (0 ms), retain 6>

Device shows up in IORegistry but no block storage node gets created.

Step 1: Extract the command set from the old kext

# Dump the binary for string analysis
otool -v -s __TEXT __cstring /Library/Extensions/DroboDriver.kext/Contents/MacOS/DroboDriver > strings.txt

# Find vendor-specific opcodes
grep -i "0x[0-9a-f]\{2\}" strings.txt | head -30

Claude parsed the output and identified the command table: 0xC1 = get array status, 0xC2 = read capacity, 0xC3 = read blocks, 0xC4 = write blocks, 0xC5 = SMART passthrough. All wrapped in a 16-byte header with little-endian LBA and block count.

Step 2: DriverKit skeleton with AI assist

I prompted for a minimal IOUserClient subclass that vends a IOUserClient interface:

// DroboUserClient.swift
import DriverKit
import IOKit

class DroboUserClient: IOUserClient {
    private var device: DroboDevice?
    private var commandQueue: DispatchQueue
    
    override func initWithTask(_ owningTask: task_t,
                               securityToken: UInt64,
                               type: UInt32,
                               properties: OSDictionary?) -> kern_return_t {
        let ret = super.initWithTask(owningTask, securityToken: type, properties: properties)
        guard ret == KERN_SUCCESS else { return ret }
        commandQueue = DispatchQueue(label: "com.drobo.driver.command")
        return KERN_SUCCESS
    }
    
    override func clientClose() {
        device?.close()
        device = nil
        super.clientClose()
    }
    
    // Async command submission via external method
    override func externalMethodAsync(_ selector: UInt32,
                                      _ arguments: IOExternalMethodArguments,
                                      _ completion: IOAsyncCallback,
                                      _ refcon: UnsafeMutableRawPointer?) -> kern_return_t {
        // Claude generated the switch statement mapping selectors to CDB builders
    }
}

The AI got the IOExternalMethodDispatch table 90% right on first try. I only had to fix the memory descriptor mapping for scatter-gather I/O.

Step 3: Userspace daemon in Rust

Swift is fine for the kernel boundary but I wanted zero-cost abstractions for the RAID reconstruction logic. The daemon speaks io_connect_method_structureI_structureO to the user client:

// drobo-daemon/src/main.rs
use io_kit_sys::{io_connect_t, IOConnectCallStructMethod};
use std::os::raw::c_void;

const K_DROBO_CMD_READ: u32 = 0xC3;
const K_DROBO_CMD_WRITE: u32 = 0xC4;

fn submit_cdb(conn: io_connect_t, cdb: &[u8; 16], data: &mut [u8]) -> kern_return_t {
    let mut input = DroboCommandInput { cdb: *cdb, data_len: data.len() as u32 };
    let mut output = DroboCommandOutput { status: 0, residue: 0 };
    let mut out_size = std::mem::size_of::<DroboCommandOutput>();
    
    unsafe {
        IOConnectCallStructMethod(
            conn,
            K_DROBO_CMD_READ,
            &input as *const _ as *const c_void,
            std::mem::size_of::<DroboCommandInput>(),
            &mut output as *mut _ as *mut c_void,
            &mut out_size,
        )
    }
}

Step 4: Rebuild the virtual block device

The daemon presents a NBD-compatible socket so nbdkit can expose /dev/nbd0 to the OS:

# Build and load
xcodebuild -scheme DroboDriver -configuration Release
sudo kmutil load -p ./build/Release/DroboDriver.dext

# Start daemon
cargo build --release
sudo ./target/release/drobo-daemon --socket /var/run/drobo.sock

# Expose as block device
nbdkit -U - --filter=readonly file /var/run/drobo.sock

Now diskutil list shows the array, fsck_apfs -y /dev/disk4 repairs the filesystem, and mount_apfs /dev/disk4s1 /Volumes/Drobo brings 16 TB back online.

Gotchas that burned hours

• Thunderbolt power management: The controller drops link after 30 s idle. Fixed by sending a 0xC1 heartbeat every 15 s from the daemon.
• Big-endian LBA in CDB vs little-endian in SCSI spec: Drobo firmware expects BE but the SCSI layer assumes LE. Byte-swap in the user client.
• DriverKit entitlements: Need com.apple.developer.driverkit.transport.iokit and com.apple.developer.driverkit.userclient-access in the .entitlements file, otherwise IOServiceOpen returns kIOReturnNotPermitted.

Current status

• Read/write throughput: 1.1 GB/s sustained (Thunderbolt 2 limit)
• RAID-5 rebuild verified after simulated drive pull
• SMART passthrough works — smartctl -a /dev/disk4 shows per-drive health
• Time Machine backs up to it nightly

The driver is ~1,200 lines of Swift + 800 lines of Rust. Claude wrote ~70% of the boilerplate; I did the protocol logic and hardware bring-up. If you have orphaned Thunderbolt storage, the pattern generalizes: extract the CDB set, wrap it in a minimal user client, push complexity to userspace.