Skip to content

苏苏 AI超频 v1.5.7 — 隔离包载荷内置 + 中文文件名修复（修复勾选同意后仍无法安装）

Latest
Latest

Choose a tag to compare

View all tags
@1449690477 1449690477 released this 21 Sep 12:00
v1.5.7
c4cbffd

v1.5.7 — 隔离包载荷内置（修复「勾选同意后仍无法安装」）

便携产物已就绪。 上一版 v1.5.6 存在一个功能性缺陷（详见下文）：如果你已经下载了 1.5.6 的便携包，它勾选同意后仍然装不上三个隔离包。本版修复了它，并在隔离客体里构建、验证完毕。

下载

对象 字节 SHA-256
SusuAIOverclock-1.5.7-portable-electron44.4.3-isolated.zip 231,724,148 94ed18ca8100c088e7e857ddbc8b39cd29188ba4d40bf74b709d39350ed38913
↳ 内含 SusuAIOverclock-1.5.7-portable.exe 146,966,201 be9b7951b43364109c4d6b9608dab612ebb731e3beb50325de29f4b06df259ab

只发 ZIP，不发裸 EXE。 解压后双击 SusuAIOverclock-1.5.7-portable.exe 即可运行，无需安装。

⚠️ 为什么是 ZIP：构建用的这台 Windows 宿主仍受感染，同一目录里任何新写入的 .exe 都会在约 60–120 秒内被前置器包裹。裸 EXE 一旦落在这台机器上就已经坏了，所以交付形态只能是归档。请在干净的机器上解压运行。
本版没有代码签名，首次运行 Windows SmartScreen 会拦一下，属预期。

修的是什么

用户反馈（原话）

三個包我都同意了 反重力 codex冷咖啡 codex胖虎 但是依然無法安裝

界面表现：三个隔离包的「我知晓 同意」都勾上了，徽章显示「隔离已解锁」，安装 / 卸载按钮依然置灰，卡片底部显示「未建立基线」。

排查出两个独立成因，只修一个仍然装不上：

成因 1：把「分发范围」和「发布许可」当成了一回事

1.5.5 的供应链清理把这三个包的二进制移出了仓库（5 个 .exe 收进隔离区）。1.5.6 恢复了卡片、勾选框和策略解锁，却没有把载荷打回包里 —— 因为打包过滤规则里只列了六个发布包。

于是链路断在这里：同意已登记 → getPackBlockReason() 正确返回 null（所以徽章显示已解锁）→ 但 resolvePackDir() 依次查导入目录 / 根目录 / 内嵌目录全部落空 → 返回 { dir: null, source: 'none' } → found: false → 按钮的 disabled 表达式恒为真。

判据：blockedReason 是 null 而按钮仍灰 = 不是授权问题，是载荷根本不在包里。

修法：把 5 个载荷不再从隔离区恢复，改用一份钉死在源码里的洁净字节基线（scripts/payload-dedetaint.json：entryPath + cleanSize + cleanSha256）在归档时按内容放行，直接内置进包。

为什么不能再用隔离区：隔离出来的那 5 个 blob 当时干净，但同一个目录在这之后被再次感染。宿主有活体 PE 前置注入器（固定前置 2,592,798 字节 loader），按扩展名每 60–120 秒轮询包裹新写入的 .exe —— 从隔离区「恢复」等于把新注入的字节又请回产物里。判据可机械复核：干净文件 size % 4096 == 30（VC 节对齐留白），带 loader 的则是 size == 原值 + 2592798 且 MOD 4096 != 30。

包 载荷 带毒 → 洁净
反重力 materials/proxy/bin/antigravity-oauth-proxy.exe 剥离 loader
Codex 冷咖啡 materials/slo-runtime/eni-solo/sha256-r2-mixed-pinned-2b50f93a8d7716b5/slo-runtime-hook.exe 18,386,515 → 15,879,733
Codex 胖虎 keysmith/python/python.exe 2,768,926 → 262,144
Codex 胖虎 keysmith/python/Lib/venv/scripts/nt/python.exe 剥离 loader
Codex 胖虎 keysmith/python/Lib/venv/scripts/nt/pythonw.exe 剥离 loader

基线校验不通过（allPass 非真 / 条目数 ≠ 5 / entryPath 重复 / 缺 loader 文本段签名 0x1000+0x7f000，sha256 dd25f3ed…c9932）即拒绝导出。

成因 2：来源检查把自己人的目录当成了别人的载荷

载荷补进去之后，Codex 这个包依然失败 —— 这一条不是测试发现的，是逐个直接调用安全检查函数才暴露出来：

assertPackSourceAllowed 会把每一个后代目录名都拿去和隔离包的 id 比对，而 packed-packs/codex/breaker-tx/skills/packs/anti-gravity/ 是 Codex toolkit 自己的技能目录，于是命中了「反重力」的签名 → 抛 ERR_PACK_SOURCE_QUARANTINED，而且报的还是反重力的错误文案，极具误导性。

同意解锁了策略门，来源扫描却仍然拒绝这个包自己的树。

修法：已获同意的包，自身树内部（深度 ≥ 1）的目录名豁免；根目录和所有文件名仍然全量检查 → 「用甲包指向乙包的载荷目录」这种跨包复用依旧被拒。

成因 3：干净客体解包时，中文文件名被批量改成乱码

成因 1 和 2 修完之后，回归仍红：构建客体里 packed-packs/cursor/ 少了三个文件。查到的是工具链本身的问题 ——

Ubuntu/Debian 的 Info-ZIP UnZip 6.00 在 LANG=C.UTF-8 下，会把归档里所有带 bit-11（UTF-8）标记的条目名当作 OEM 码页（CP437）来解释，于是：

packed-packs/cursor/一键安装.bat   →   packed-packs/cursor/ф╕АщФохоЙшгЕ.bat

本版归档里有 566 个非 ASCII 条目、全部带 bit-11，其中 454 个被改坏。字节级对照（同一个条目、同一份归档）：

解包方式 落盘文件名首字节
unzip（Info-ZIP 6.00） D1 84 E2 95 95 …
python3 -m zipfile / zipfile.ZipFile E4 B8 80 E9 94 AE … ← 正确

为什么此前每一道闸门都放行：parity 断言比的是「产物里的 resources/packs/」与「客体自己解出来的那棵树」—— 两侧被同一把刀改成同样的乱码，于是互证一致。凡是被 unzip 写过的名字，比对双方都错得一模一样。这不是断言写得不够严，是比对对象选错了。

修法（三层，缺一层都会漏）：

  1. 换解包器 —— 新增 scripts/isolated-build-unpack.py，用 zipfile.ZipFile（尊重 bit 11）解包；拒绝符号链接 / 绝对路径 / ..；落盘前逐文件复核 size + sha256；断言归档内自带的副本与自己逐字节相同（sha256 30fac4ae…）。
  2. 判据必须是「传输前由宿主写下、客体够不着」的东西 —— 归档内写入 SOURCE-MANIFEST.json（schemaVersion 2，本包 6,177 条，含每个条目的 path / size / sha256）。客体侧 isolated-build-verify.cjs 第一件事就是核对它：非 ASCII 名字逐个 existsSync + size/hash 复核，并断言 packed-packs/ 的宿主清单与客体解包树逐名一致，结果落 reports/source-transfer-integrity.json。
  3. 客体侧硬断言 —— 准备阶段对 一键安装.bat / 一键卸载.bat / 使用说明.txt / 实测方法.txt 做点名抽查，并用 find -name '*╕*' -o -name '*╣*' 断言 CP437 残渣为 0，非 0 直接 exit 1。

同一缺陷存在于 1.5.5 / 1.5.6 的产物中（那两个版本的归档也用了 unzip）。两版归档与交付不作追溯重发，升级到 1.5.7 即解决。

现在的三轴模型

这次事故的根源是把两个概念混为一谈，现在拆成三条独立的轴：

轴 内容 作用
分发 9 个包：6 发布 + codex / codex-panghu / anti-gravity 决定打不打包
发布许可 6 个包：cursor / dsh / claude / opencode / workbuddy / workbuddy-ai 决定是否默认放行
知情同意 运行时勾选，落在 state.json.consents 决定隔离载荷是否解锁

内置 ≠ 放行。 三个旧载荷随包分发，未勾选时安装 / 卸载 / 备份 / 恢复 / 深度验证全部在策略层拒绝，勾选即解锁，取消立即回阻断（无需重启）。

永久闸门：产物与源码的选材一致性

为了不让「卡片在、载荷不在」再次发生，隔离构建的校验器新增了一条 parity 断言：

产物 resources/packs/ 下的文件集合，必须逐个文件等于打包过滤规则从源码目录选出的集合。

也就是说，从今往后「过滤规则漏了一个包」会直接让构建阶段失败，而不是打出一个界面正常、功能缺失的包。校验器内置了最小 glob 引擎，遇到不认识的 glob 模式抛错而不是静默不匹配。

源码层验证（本版实测）

检查 结果
安全测试合跑（DANGO_TEST_REAL_PACKS=1） 43 通过 / 0 失败 / 0 跳过
npm test（核心） 116 / 116 通过
tsc --noEmit 无错误
vite build ✓ 1592 modules transformed
构建预检（本机） ok: false + errors: [] → 结构断言全过（版本一致、Electron 44.4.3 钉死、19 条过滤规则与共享清单逐条精确匹配）；findings 全部是已知的宿主感染文件
隔离包来源检查 三个包在获得同意后全部通过；跨包复用（甲包指向乙包目录 / 旧载荷文件）全部被拒
源包导出 5 个载荷全部 stripped 回洁净基线；restoredFromQuarantine 恒为空

新增回归测试固定成因 2 与成因 3：
consent unlocks a pack's own tree and never another pack's tree、the source archive is extracted by a UTF-8 safe unpacker, not unzip。

产物在哪里构建、怎么验的

产物不能在当前这台 Windows 宿主上构建 —— 预检按设计拒绝，且没有绕过开关：

[security] blocked; binaries scanned=243; findings=15; errors=0
[security] No bypass flag exists; an IOC-negative scan is not permission
           to build in the infected host OS.

命中的 15 条全部是已知的宿主感染文件（%TEMP%\R.exe、%TEMP%\HD_X.dat，以及被前置器盖戳的 7za.exe / app-builder.exe 三个架构各一份）。

所以 1.5.7 的便携产物在隔离的 Ubuntu 客体里构建（Electron 44.4.3 / electron-builder 25.1.8 / Node v22.23.2，依赖走 npm 官方 registry 并与 lockfile SRI 一致；NAT / 回环转发，无共享目录与共享剪贴板）。已构建完成并全绿：

阶段 结果
源码解包（isolated-build-unpack.py） 6177 / 6177，missing / extra / sizeMismatch / hashMismatch 全 0
产物校验（verify artifact） EXIT=0，产物 sha256 be9b7951…
ClamAV（客体） 扫 36,292 文件 / 2.24 GiB，46 个命中全部落在既有内容签名，unexpectedFindings: []
结构证明（isolated-build-proof.py） EXIT=0；pack diff 全空，5 个 embedded 载荷逐条对上
GUI 冒烟（Linux Electron 44.4.3 跑 Windows ASAR） 176 项检查 / 0 失败，出具 PASS_LINUX_ASAR_GUI_ONLY

GUI 冒烟直接对着老板报的那张卡片打：未勾选 → deploy / verifyDeep 在 IPC 层真拒绝（ERR_PACK_QUARANTINED）、三个按钮全灰；勾选 → source: embedded / found: true，installEnabled / uninstallEnabled / monitorEnabled 全 true；撤销 → 徽章回「已隔离 · 只读」、按钮重新变灰、state.json.consents 落空。

仍未验证：Windows 原生 GUI、便携 EXE 自解压、以及九个载荷的真实安装器在 Windows 上的实机运行。176 项是在 Linux 上跑 Windows ASAR 的结果，不等于 Windows 原生验证。

关于杀毒扫描（如实说明）

本版不冒称杀毒通过或「全绿」。1.5.5 / 1.5.6 那两轮的结论继续有效：

  • ClamAV 命中集中在三份可读文本（XXE 安全案例、SVG 示例、聚合词库索引）的内容签名，不是此前的投放器外壳；
  • 扫描结果中没有出现 1.5.5 之前那个投放器外壳的特征（前置器加载器、R.exe、HD_X.dat、N.exe）；
  • 本机（Windows 宿主）仍未清毒 —— 宿主上任何新写入的 .exe 都会在约 60–120 秒内被前置器包裹。因此本版继续只交付归档、不以裸 exe 形式落本机磁盘。

获取与升级建议

  • 如果你只是想要能直接用的软件：等本 Release 的便携产物补挂上来。补挂后页面会更新下载表。
  • 如果你已经在用 1.5.6：1.5.6 的三个隔离包勾选同意后依然装不上，这是已知缺陷，升级到 1.5.7 即修复。
  • 如果你要自行构建：npm ci → npm test → npm test:security → npm run pack:portable，但不要在已知受感染的宿主机上构建。

安全提示

  • 产物没有代码签名，首次运行 Windows SmartScreen 会拦一下，属预期。
  • 三条隔离载荷解锁后运行的是 v1.5.4 时期的原脚本，未做新的安全加固；解锁即代表用户已知晓此点。
  • 本版尚未在实机 GUI 截图验证隔离包卡片解锁后的视觉效果；界面与状态机改动由自动化测试覆盖。
Assets 3
Loading