失落阵列的突袭者：为我的孤立Drobo即兴编写macOS驱动

# 遗失阵列的冒险之旅：为我的孤儿 Drobo 用 vibe-coding 方式编写 macOS 驱动程序（及配套应用） 来源：https://fetzu.ch/blog/20260819_claudevsdrobo/ 免责声明：我不知道我所做的任何事情是否合法。事实上，我也没有任何深入的硬件*破解*知识。 免责声明2：虽然我很笨也很懒，甚至会用大语言模型来自动化冲泡咖啡——（哎呀！）偶尔也用大语言模型写代码；但本文完全由人类撰写，甚至几乎未经大语言模型校对。此免责声明适用于本博客上的所有后续文章。 我在 2021 年建立了这个网站，但一直没花时间在博客上真正写点东西。“迟做总比不做好”我想。那么，现在就开始吧... 今天，我受到 Hacker News 上一篇题为“Claude 为我那个仅支持 Windows 的冷门 HP 打印机编写了一个 macOS 驱动”的提交（https://x.com/kuberwastaken/status/2089377982536388964）的启发，想到了我可靠的 Drobo 5D（https://en.wikipedia.org/wiki/Drobo），这是一个 RAID 阵列，在过去的 14 年里一直在毫无差错地保存和提供我的文件（除了约 2019 年的“电源适配器损坏”事件）。Drobo 公司已经倒闭，而即将发布的 macOS 27 “金门”将是最后一个支持 Rosetta 2 的版本，这意味着软件套件的部分功能将与未来的 macOS 版本不再兼容——而该版本有太多生活质量方面的改进让我无法放弃。因为生病困在家里，我想：“为什么不把问题交给 Claude 处理呢”。于是就有了这次冒险的记录。 ### 首先，有了提示词¶ (https://fetzu.ch/blog/20260819_claudevsdrobo/#first-there-was-the-prompt) > 公司“Drobo”已经倒闭（参见 https://petapixel.com/2023/06/06/drobo-is-officially-done-as-the-company-moves-into-liquidation/）。我拥有一个“Drobo 5D”，它通过 USB 3 连接到我的 Mac（Thunderbolt 2 端口在较新的 Mac 型号上无法工作）——这在我的运行 macOS Ventura (13) 的 2017 年款 iMac 上仍然可以工作。Drobo 本身和 Drobo Dashboard 软件都能运行。在较新的 macOS 版本上，Drobo Dashboard 软件不再兼容，Drobo 只能作为外部驱动器挂载。为了环保，我的目标是尽可能长时间地使用这个设备，但又不想被排除在 macOS（或 Mac 硬件）升级之外。你今天的任务是分析当前的 Drobo 5D 固件以及 Drobo Dashboard 软件，并尝试理解它为何不与更新的 macOS 版本工作，是什么可能阻止硬件在更新的 Mac 硬件上工作，并想出解决这个问题的方案。一切皆有可能：从简单的修复到为现代 Mac/macOS 完全重写驱动和 Drobo Dashboard。注意：我已在 /Users/fetzu/Dev/ReDrobo/ZZ_BUFFER 文件夹中为你提供了一些（直到最新版本的）Drobo 驱动和 Drobo Dashboard。请随意使用，但请尽量避免在此 Mac 上安装它们（我认为你无法安装）。 这个提示词的结构非常简单：我提供了背景（希望能避免被标记为网络安全/逆向工程，我多么天真啊），陈述了任务，并向 Claude 提供了这两个软件的最后 5 个版本（包括单独 PDF 中的发行说明）。感谢这位圣人（https://github.com/dhomas1/DroboApps/），他花时间上传并索引了这些文件。 将提示词输入到 High 级别的 Fable 5（因为，为什么不呢？），结果自动被标记并切换到了 Opus 4.8。我决定在那里中断它，并用 Max 级别的 Opus 5 开启一个新会话——然后我们就开始行动了。 ### 其次，有了计划¶ (https://fetzu.ch/blog/20260819_claudevsdrobo/#second-there-was-a-plan) 经过一点思考以及对驱动/Drobo Dashboard 二进制文件的摆弄，Claude 提出了一个分 5 个阶段的计划。像任何优秀的工程师一样，Claude 从 0 开始计数： 1. “首先保护数据”（废话） 2. “验证协议”（通过比较有驱动设备（我运行 macOS 13 的 2017 年 iMac）和无驱动设备（我运行 macOS 26 的 MacBook Pro M5 Pro）之间的数据输出） 3. “解码记录载荷”（旨在验证并输出协议规范） 4. “交付可用的 CLI”（用于输出 Drobo Dashboard 通常会提供的信息） 5. “实时驱动程序”（一个真正的 Drobo Dashboard 替代品） 这个计划看起来足够可靠，让我们深入探讨... ### 阶段 1：将 Drobo 连接到我的 MacBook Pro¶ (https://fetzu.ch/blog/20260819_claudevsdrobo/#phase-1-hooking-up-the-drobo-to-my-macbook-pro) 我知道这会奏效（卷正确挂载并可读写，但它报告的大小错误，并且不向用户提供关于卷/阵列/驱动器当前状态的任何信息），并且 Claude 编写了一个巧妙的 C 工具叫 droboprobe（https://github.com/fetzu/ReDrobo/blob/main/tools/droboprobe/droboprobe.c）用于在设备插入后探测它。Claude 首先让我截取了 Drobo Dashboard 中 Drobo 5D 当前状态的屏幕截图（好人，我不喜欢打字）。 这个阶段让 Claude 确认了设备正在工作，但确实报告了错误的卷大小。 | | 总计 | 已用 | 空闲 | | --- | --- | --- | --- | | Dashboard (iMac) | 5.42 TB | 4.25 TB | **1.17 TB** | | macOS (此处) | 17.6 TB | 4.7 TB | **12.9 TB** | 但是，也还有一些“坏消息”： > #### 坏消息，而且我弄错了¶ (https://fetzu.ch/blog/20260819_claudevsdrobo/#the-bad-news-and-i-got-this-wrong) `SCSITaskUserClient`**对 Drobo 无效**。`IOCreatePlugInInterfaceForService`返回`kIOReturnUnsupported`。这台 Mac 上没有任何服务发布`SCSITaskDeviceCategory`——初始化器在每个 SCSI nub 上都保留了一个匹配类别，但从未实际启动。原因一直在 Apple 自己的头文件中：SCSITaskLib 为“没有内核驱动”的设备服务，加上光盘刻录机。Drobo 被 Apple 的`IOSCSIPeripheralDeviceType00`所声明，所以它得不到任何东西。我也排除了后门：一个 USB 接口，一个 LUN，都已被声明。 幸运的是，这也带来了一些额外的好消息： > #### 但仍然有一种干净的方式来获取协议¶ (https://fetzu.ch/blog/20260819_claudevsdrobo/#but-theres-a-clean-way-to-still-get-the-protocol) kext 已安装并在 iMac 上工作，其用户客户端是一个普通的`IOUserClient`。我从二进制文件中提取了其完整的调度表：选择器方法形状2 `sGetESAModePage` 2 个标量输入，**1308 字节结构体输出**——读取操作3 `sSetESAModePage` 3 个标量 + 1308 字节结构体输入——写入操作。选择器 0–3 已通过符号表和目标调度位掩码确认。有两个重要的安全属性：我只会调用**选择器 2**，并且 IOKit 会在内核看到任何东西*之前*根据该表验证参数数量和大小，因此错误会被拒绝而不是执行。这正是 Dashboard 的守护进程每隔几秒就会进行的相同调用。这为我们获得了权威的载荷字节，同时 Dashboard 在旁边用于交叉检查，并且没有在任何一台机器上更改安全设置。 ### 阶段 2：转储并解码记录载荷¶ (https://fetzu.ch/blog/20260819_claudevsdrobo/#phase-2-dump-and-decode-the-record-payloads) 然后 Claude 为我提供了另一个巧妙的工具 droboesa（https://github.com/fetzu/ReDrobo/blob/main/tools/droboesa/droboesa.c），让我能够从 iMac 转储 ESA 记录。经过两次尝试（发现 launchctl list 需要 sudo），Claude 能够提出完整的“Drobo 'ESA' 管理协议（https://github.com/fetzu/ReDrobo/blob/main/docs/PROTOCOL.md）”。这意味着我们正在迈向一个功能齐全的驱动... ### 阶段3-4：构建（并测试）驱动（和应用程序）¶ (https://fetzu.ch/blog/20260819_claudevsdrobo/#phase-3-4-building-and-testing-the-driver-and-the-app) 下一个阶段以 Claude 询问我如何进行开始：要么获取一个 Apple 开发者账户（我碰巧已经有一个）以申请 SCSIPeripheralsDriverKit 权限证书（我*可能*永远无法获得，因为我是来自阿尔卑斯山的无名之辈，在逆向工程一个可能受专利保护的产品），要么通过禁用 SIP（暂时？）来直接安装。将无限内核扩展访问权限授予由大语言模型编写的代码，而我没有专业知识来验证它...会出什么问题？ 所以当然，我做了任何（不）理智的人都会做的事：我禁用 SIP 来尝试 Claude 的“DroboDext（https://github.com/fetzu/ReDrobo/tree/main/DroboDext）”和 ReDrobo.app（https://github.com/fetzu/ReDrobo/tree/main/ReDrobo）”。但因为我只是笨而不是胆大妄为，我是在一台运行 macOS 27 开发者测试版的备用 Mac Mini M1 上这样做的。我想知道 Claude 对“移动目标”有何“感觉”。 于是我启动 Mac Mini，禁用 SIP 并启动应用。然后，崩溃了；关于权限证书的问题。然后是扩展未在应用包中找到的问题。然后是关于 dext 包布局的问题。然后是命名的问题。然后是关于 dext 是为`x86_64 arm64e`（带指针认证）而非`arm64`编译的问题。然后是其他代码签名的问题。然后驱动终于能够安装并*几乎*与设备通信了。接着是另一个权限证书问题。然后是“ExtentionNotFound”问题。到这时，Claude 差点要让我放弃（并且“停止折腾”），但我不会那样做的。多次重启后，仍然没有机会。Claude 真的很想让我放弃。 > 完整的报告，包括耗费我们整个下午的八个打包和生命周期陷阱。 – Claude 但我有时间，而且我不认为它会感到疲倦。所以我们坚持了下来。Claude 实际上需要的只是一点坚持、一点推动和一些 Kagi 搜索来找到真正的罪魁祸首：不是权限证书（这次？）而是 IOClass。我有预感，但不想显得自以为是。不，等等，实际上这还是一个权限证书问题；显然我们只能暴力破解。然后，一个**突破**。我的整个灵魂都在崩溃的边缘，在我那根支撑希望的柱子上跳舞，尽可能避免踩到绊脚石。我准备好迎接生活中的任何挑战了。 > 你拒绝放弃是对的。这是一个真正的突破，而我三轮消息前的“最终”结论错了两次。 – Claude 最后，我们终于能够读取设备的全部详细信息：阵列名称、实际可用空间、健康状态、每个连接驱动器的序列号...现在剩下的就是找出我们暴力破解的 12 个权限证书候选者中哪一个是正确的。幸运的是，我和 Claude 都听说过二分查找（https://en.wikipedia.org/wiki/Binary_search），所以最多 4 轮...对吗？对吗？是的。 最终，我们手中有了一个可用的驱动（尽管它仍然需要关闭 SIP）。这正是结束一天工作并——的完美时机 ### 阶段 5：功能蔓延的极致¶ (https://fetzu.ch/blog/20260819_claudevsdrobo/#phase-5-the-epitome-of-feature-creep) 既然我必须对代码库进行一遍检查以使其达到可发布状态，我们不妨为 ReDrobo.app 快速打造一个图形界面，不是吗？ 我确定了我认为对自己有用的最基本功能： - 菜单栏 + 通知（这样我们实际上就知道何时需要注意） - 显示更多驱动信息（健康状态、序列号、固件版本）和阵列的 SMART 数据（剧透：SMART 证明是不可能的） - 支持功能标志（1.0.0 版本为只读） - 支持多设备（在同一台计算机上）——遗憾的是未测试，因为我只有一个阵列 - 支持其他 Drobo 型号——也未测试，因为我只有一个 5D - 诊断导出 - 带有 4 个级别的应用端日志 - 卸载程序（谁喜欢旧驱动残留在系统里？） 在最终确定 ReDrobo 1.0.0 版本之前，我和 Claude 又进行了*多轮*讨论，并进行了更多逆向工程（特别是针对功能标志和其他型号支持）。这就是它的完整样貌： ReDrobo 的概述页面 ### 尾声：诞生之后¶ (https://fetzu.ch/blog/20260819_claudevsdrobo/#epilogue-post-natus) 就是这样。大约一个下午多的工作，我们就有了一个可用的、由 vibe-coding 方式编写的驱动和应用，它将允许我使用我的 Drobo，直到它最终报废。 我的目标不是对大语言模型的使用提供一些发人深省的见解——过去已有更聪明、更清晰的人这样做过，希望未来也会继续如此。我唯一会问（自己）的问题是：我能“独立”完成这个吗？可能不能。在这个时间框架内？绝对不能。我在此过程中学到了什么吗？我必须承认，这个过程有点过于“放手”，我没有从中获得真正的价值。如果我花更多时间来审查每一步和代码，我可能会对 macOS 驱动内部工作原理有更深的了解。我唯一能肯定的是，我现在有一种方法可以更长时间地使用我的硬件，甚至在未来（如果需要）有添加功能标志写入的途径。这已经不算坏了。 我已将源代码和所有文档发布在这个代码库中：fetzu/ReDrobo (https://github.com/fetzu/ReDrobo)。它当然不是一个经过官方公证的应用（因为，再说一次，我不认为 Apple 会给一个随机开发者逆向工程并 vibe-coding 的应用发放所需证书），但如果你愿意承担关闭 SIP 的风险，它就供你使用。也许我不会是唯一一个能从他们可靠的 Drobo 获得更久使用寿命的人。