iloader iOS 侧载工具能力核验：23 项源码逐项走读与完整差距修复指南

iloader iOS 侧载工具能力核验23 项源码逐项走读与完整差距修复指南【免费下载链接】iloaderUser friendly sideloader项目地址: https://gitcode.com/GitHub_Trending/iloa/iloaderiloader 是一条协议编排很实、语义细节留白的 iOS 侧载把未经 App Store 审核的应用装到 iPhone/iPad 上工具v2.4.1 的 23 个核心能力里链路级功能基本可用但版本判断、进度回报、凭据降级三处关键语义停在半空。本文核验范围是仓库 v2.4.1 的 Rust 后端 src-tauri/src/ 与 React 前端 src/ 两个目录逐文件重建不依赖任何现成审计文档。读完你能做三件事看懂每个状态标记对应的具体文件与函数、按依赖顺序排定自己的修复清单、跑通 4 条核验命令并沿失败链定位一次真实报错。状态图例与口径这篇核验怎么读三档状态的定义与常见误读如下全文所有标记只使用这三档标记命名判定依据常见误读✅完整可用后端命令与前端 UI 两侧都有源码证据通路端到端不等于没有缺陷只代表这条功能当前能用通路在、语义缺代码路径能走通但核心行为未实现常见形态TODO 注释、硬编码替代、降级分支不等于差一点完成缺的往往是核心行为本身❌无实现层找不到对应代码连占位都没有不等于计划中仓库无 roadmap 文档可查本文不提供、也不推断以下内容项目声明就绪度百分比不提供。仓库无任何就绪度数据给出百分比即为编造人时估算不提供。仓库无估算文档测试覆盖 / 基准未测量。src-tauri/src/ 内无#[test]、#[cfg(test)]src/ 内无*.test.*/*.spec.*无 benches 目录性能与成功率未测量。全文唯一量化口径来自 Settings.tsx 注释works ~50% of the time属估算未经实测本文不采信为事实因此全文区分三类陈述①源码可直接证实的事实代码可打开核对②代码注释给出的口径估算性质③未测量无基准无数据缺口明说。CONTRIBUTING.md 第一行写明项目正在大改版含新平台支持与 UI 重构所以本文只审计 v2.4.1 现状不把计划中当结论。能力总表23 项逐条核验结果能力项基准预期现状标记 源码落点设备枚举列出已连接的 iOS 设备✅ device.rslist_devices走 usbmuxdApple 的 USB 设备复用守护进程负责枚举与路由线缆连接的 iOS 设备并行拉取 DeviceName 与 ProductVersion配对文件生成选中设备即取得可用配对文件✅ pairing.rspairing_file17.4 走 RPPairing 并缓存17.4 仅 lockdown传统 USB 配对会话plist版本分叉选择按真实 iOS 版本选链路 后端 17.4 门已落地pairing.rsis_ios_version_below前端建议文本的版本过滤是 TODO 空壳errors.tsx设备断连自动重连线断了自动恢复❌ device.rs 无 usbmuxd 监听逻辑仅手动刷新App.tsx CtrlR / ⌘RWi-Fi 调试设备可选支持 枚举时标记 Network配对时开启EnableWifiDebuggingpairing.rsgenerate_lockdown_plist任意 IPA 导入选文件即装✅ sideload.rssideload()调 isideload外部核心侧载库承担认证与签名的install_appIPA 传输进度回报百分比/速率 进度回调传Nonesideload.rs前端 operations.ts 中 sideload 仅一个步骤SideStore 一条龙下载→安装→投放配对文件分阶段反馈✅install_sidestore_operation三步状态机Operation 逐步 emitsideload.rs operation.rs安装包缓存不重复下载❌ 源码 TODO 注明未做download()整文件读进内存再tokio::fs::write多设备批量安装一次多台❌ 状态是单设备DeviceInfoMutexdevice.rs无批量入口Apple ID 登录含 2FA主流程✅ account.rslogin()用 mpsc 通道收 2FA 验证码120 秒超时Anisette 服务器列表动态获取 Settings.tsx 顶部硬编码 4 台TODO 注明Fetch anisette list from serverAnisetteApple 登录链路中的防重放握手协议客户端指纹由服务端下发 account.rslogin()中set_client_info_override写死 macOS 27.0 字符串注释自称 temporaryTeam 选择多 Team 切换❌ account.rs 第 253 行// TODO: Team SelectionAnisette 失败自动回退自动换源❌ 无回退链只能手动换服务器或reset_anisette_state凭据与状态存储系统钥匙串✅ 默认KeyringStoragesecure_storage.rscreate_sideloading_storagekeyring 不可用降级安全降级 明文FsStorage仅一条 warn 日志注释自认 insecure配对文件缓存按设备缓存✅ 键rppairing1.1_file_{udid}delete_stored_rppairing会轮换 host labelpairing.rs跨机迁移备份/恢复❌ 无迁移机制仅有export_pairing_cmd导出单文件给高级用户错误分类区分根因✅ error.rsAppError23 个变体rootcause 映射 Apple 错误码-20209、1102 等本地化错误建议每类错误多条建议✅ errors.tsxerrorSuggestionKeys变体→建议 key 映射按平台过滤locales/ 提供 30 种语言失败步骤单步重试从断点继续❌ Operation 只 emit started/finished/failed 三种事件operation.rs无重试入口命令面前端可调用的后端命令齐备✅ lib.rsgenerate_handler注册 22 个 Tauri 命令证据卷宗四处值得放大的源码点卷宗 A17.4 之后的两条配对链路与前端版本判断的空壳现状一句话后端按 iOS 版本分叉是显式且完整的但错误建议文案里的按 iOS 版本裁剪这一步还没写。pairing.rs 的pairing_file是分叉的入口注释直接点明版本门// rppairing is 17.4 if is_ios_version_below(device.version.as_str(), 17, 4) { let lockdown_dict lockdown_plist.as_dictionary().cloned().ok_or_else(...)?; return Ok(plist_to_xml_bytes(lockdown_dict)); } let cache_key format!(rppairing1.1_file_{}, device.udid);这段证据链说明的是Remote PairingiOS 17.4 引入的远程配对协议RPPairing 即其配对文件只在 17.4 及以上生成并缓存低版本设备走 lockdown 老链路两条路在同一个函数里并存17.4 设备的缓存键带 udid缓存损坏时重新生成warn!后走generate_rppairing_plist。数据源是 device.rsDeviceInfo的version字段由 lockdown 的ProductVersion取值而来。而同一个版本概念到了前端就是空的errors.tsx 的getSuggestionBlock里平台标记[platform::xxx]做了真实过滤紧随其后的 iOS 标记过滤却是// TODO: actually check ios version加一行正则直接剥掉[ios::xxx]标记——即带版本条件限制的文案建议会被无条件展示或丢弃语义未实现。修复动作动 errors.tsx把getSuggestionBlock的签名加一个iosVersion参数数据源就是DeviceInfo.version前端已有该字段在剥离[ios::...]标记前真正比对版本纯胶水层改动不需要动上游仓库。卷宗 B为什么 IPA 安装只能看到安装中现状一句话装 IPA 的核心一行委托给 isideload本仓库的操作编排缺了进度这一环而且下载环节把整个文件读进内存。sideload.rs 的sideload()里install_app的第四个参数是进度回调当前传的是Nonelet special sideloader .get_mut() .install_app( provider, app_path.into(), true, None::fn(f32) - std::future::Ready(), Some(device.pairing), ) .await?;对照 operations.tssideloadOperation只有install一个步骤而installSideStoreOperation有 download / install / pairing 三步。再对照 sideload.rs 的install_sidestore_operation其中op.move_on(download, install)、op.move_on(install, pairing)是分阶段事件的全部来源。这条证据链说明IPA 导入在 UI 上永远只有安装中一个状态不是 UI 偷懒而是后端把fn(f32)进度回调整个让给了Noneoperation.rs 的OperationUpdate结构里也没有 progress 载荷字段。下载环节同理download()先response.bytes()整体读进内存再tokio::fs::write一次写盘无流式写入、无进度同函数上方压着一条// TODO: Cache check version to avoid re-downloading缓存与版本检查未做属于①类事实TODO 是源码原文。修复动作本仓库内两步——① sideload.rs 把None换成Some回调回调里通过 window emit 进度事件② operation.rs 的OperationUpdate加可选progress: Optionf32字段前端 operations.ts 对应渲染。协议层零改动isideload 的install_app签名本来就预留了fn(f32)。属于胶水层。卷宗 C写死的 Anisette 服务器列表与临时指纹覆盖现状一句话登录、签名、证书 API 全部委托外部 isideload本仓库手写的部分恰好是最脆弱的——服务器列表是静态数组客户端指纹是写死的字符串。Settings.tsx 顶部注释自己承认了现状// TODO: Fetch anisette list from server // new mac/windows servers let anisetteServers [ [mac-ani.jkcoxson.com, Jkcoxson], [ani.iloader.app, iloader], [new.ani.sidestore.io, SideStore (.io)], [ani3.stikstore.app, StikStore], ];数组下方还有两条被注释掉的 Windows 服务器旁边注着works ~50% of the time, and doesnt work with SMS 2FA——这是全文唯一的量化可用率口径属估算未经实测且该服务器当前并未启用。这条证据链说明服务器发现能力缺失列表变更只能靠发版Anisette 握手失败时没有自动换源用户能做的只有手动切换服务器或点 Settings 里的 Reset Anisette State对应 account.rs 的reset_anisette_state删除 keyring 中anisette_state条目。同形的第二处缺口在 account.rs 的login()RemoteV3AnisetteProvider上挂着set_client_info_override写入Mac15,7 macOS;27.0;26A5378j的客户端信息注释原文是just temporary while waiting for the anisette servers to start reporting this——即服务端尚未上报真实 client info 期间的临时方案本仓库只是调用方。修复动作胶水层改 Settings.tsx——把静态数组换成启动时从服务端拉取拉取失败回落到当前硬编码数组作兜底协议层在上游 isideload——客户端指纹何时能由服务端下发取决于 Anisette 服务器侧改造本仓库只能等、然后删掉 override 两行。Team 选择同属上游account.rs 的SideloaderBuilder调用处没有 team 参数可选// TODO: Team Selection的位置正是build()之前要等上游 builder 暴露该能力。卷宗 Dkeyring 降级故障有分级安全没有分级现状一句话密码与 Anisette 状态默认落在系统钥匙串keyring操作 OS 钥匙串的 Rust 库但降级路径是应用数据目录下的明文文件用户侧感知不到。secure_storage.rs 的create_sideloading_storage是唯一的分流点pub fn create_sideloading_storage(app: AppHandle) - ResultBoxdyn SideloadingStorage, AppError { if keyring_available() { Ok(Box::new(KeyringStorage::new(iloader.to_string()))) } else { warn!(Keyring is not available, falling back to filesystem storage for sideloading data. This is insecure!); Ok(Box::new(FsStorage::new( app.path().app_data_dir().map_err(|e| { AppError::Misc(format!(Failed to get app data directory: {:?}, e)) })?, ))) } }这条证据链说明两件事。其一降级是静默的唯一提示是 tracing 的 warn 日志前端设置页只有一个overrideKeyring开关Settings.tsx对应 en.json 的dont_use_keyring文案Dont use keyring用户看不到凭据实际落在钥匙串还是明文文件。其二配对文件缓存走的是另一条更精细的路——pairing.rs 的with_pairing_storage每次访问都重查keyring_available()状态翻转时重建存储后端并打 info 日志故障处理有分级但明文这个安全事实没有同步到任何 UI安全处理没有分级。修复动作胶水层动两处——① secure_storage.rs 降级分支至少加一条对前端的 emit 事件或让keyring_available命令的结果驱动 Settings 页展示当前后端② Settings.tsx 增加当前凭据后端keyring / 明文文件的只读展示。若要更彻底可在降级分支引入本地加密但那需要新依赖超出最小改动。修复路线先修哪条由依赖顺序决定整条链的依赖关系如下上游断了下游全断usbmuxd宿主前提缺了第一步就断 └→ 设备枚举device.rs list_devices └→ [A] Apple 登录链account.rs → isideload 上游 └→ [B] Sideloader 安装sideload.rs └→ [C] 选中设备 配对文件pairing.rs pairing_file └→ [D] 投放配对文件pairing.rs place_fileHouse Arrest 沙盒文件通道usbmuxd 是硬前提device.rs 的get_usbmuxd()是list_devices的第一个调用失败直接返回AppError::Usbmuxd属于 alpha blocker。CONTRIBUTING.md 明确核心侧载功能Apple ID 认证、代码签名在外部 isideload 仓库修 A 链深层问题要跨仓库属于上游维护者决策本仓库能做的只是胶水。本仓库内可改胶水层建议次序iOS 版本判断卷宗 Aerrors.tsx改动最小、同时惠及错误建议与版本分叉的可见性且数据源DeviceInfo.version现成。IPA 进度回报卷宗 Bsideload.rs operation.rs operations.ts上游回调签名已预留纯前端事件管道打通。keyring 降级透明化卷宗 Dsecure_storage.rs Settings.tsx安全可见性问题改动局限在两个文件。Anisette 动态列表卷宗 CSettings.tsx依赖上游提供列表来源本仓库先做拉取 回落框架。失败步骤单步重试总表第 22 行operation.rs需要 Operation 状态机支持从某步重入改动面比前四项大排在后面。需动外部依赖协议层本仓库只能等或提需求Team 选择account.rs 的 TODO 位置能力在上游 isideload 的SideloaderBuilder/DeveloperSession。Anisette 客户端指纹上报等服务器端改造随后删除 account.rs 的 override。Anisette 服务器可用率外部服务属性无本仓库可修。次序理由1→4 按改动面从最小到依赖外部排序且 1 与 2 互不依赖可并行5 最后因为它要等 Operation 事件结构稳定第 2 步会先改它。复现与排查核验命令与失败链清单以下命令均可在仓库根目录直接运行取自 package.json 的 scripts 与 src-tauri/tauri.conf.jsonbun i # 安装前端依赖仓库用 bun有 bun.lock bunx tauri dev # 热重载开发构建验证 UI 与 22 个后端命令是否可通 cargo build --manifest-path src-tauri/Cargo.toml # 单独编译 Rust 后端 git clone https://gitcode.com/GitHub_Trending/iloa/iloader # 需要本地克隆时前两条分别验证依赖可解析与 Tauri 命令注册22 个命令见 lib.rs 的generate_handler第三条验证后端独立编译第四条仅在需要克隆时执行一次。按源码失败链排序的排查清单应用内日志从 Settings 页 View Logs 查看快捷键 CtrlL / ⌘L文件日志按平台在 Windows%APPDATA%、macOS~/Library/Application Support、Linux~/.local/share下me.nabdev.iloader/logs即 lib.rs 中app_data_dir/logs滚动保留 2 个文件usbmuxd 错误先确认宿主 usbmuxd 在跑Windows 需安装 iTunes 提供macOS 自带Linux 走包管理器再确认设备物理连接——get_usbmuxd()是第一条会断的链。device_coms / remote_pairing / lockdown_pairing设备未点信任这台电脑或 17.4 设备首次远程配对未完成先信任再重选设备pairing.rs 的generate_lockdown_plist会同时开启 Wi-Fi 调试。keyring / storage 错误检查 Settings 的 Dont use keyring 是否被勾选对应force_disable_keyring命令再确认系统钥匙串可用注意降级为明文文件时只有 warn 日志无 UI 提示卷宗 D。anisette 错误换 Settings 里的 Anisette 服务器或点 Reset Anisette State 清除本地状态后重登这是唯一无自动回退的环节。not_enough_app_ids / max_apps免费账户的 App ID 配额或设备注册数耗尽error.rs 靠字符串匹配上游错误文案归类属 Apple 侧限制工具无法绕过。account_locked / underage分别是 Apple 锁号错误码 -20209与年龄不符1102需走 Apple 官方流程无工具侧解法。审计自查引用本文前的三条提醒别被 ✅ 的密度误导。本仓库的 ✅ 集中在协议编排——设备枚举、错误分类、步骤状态机、配对文件缓存都是真的真正的拖累在宿主前提usbmuxd、外部依赖Anisette 可用率、isideload 协议层与四条明写的 TODOTeam 选择、iOS 版本过滤、Anisette 列表、安装缓存。判断能不能用要看这三层而不是数表格里的对勾。未测量不等于不行。没有测试套件与基准③类声明意味着本文所有正确性结论都是代码可读证的推断不是运行事实唯一量化口径Anisette ~50%来自注释属②类估算。引用时请把代码证实与注释口径两种表述分开。每个结论都能落到文件、函数、注释。本文不要求读者相信它只要求读者能复核pairing.rs 的 17.4 门、sideload.rs 的None回调、Settings.tsx 的静态数组、secure_storage.rs 的降级 warn、errors.tsx 的 TODO——打开这五个位置四个卷宗即全部自证。【免费下载链接】iloaderUser friendly sideloader项目地址: https://gitcode.com/GitHub_Trending/iloa/iloader创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考