租台 MacBook 线下带，Qwen 3.8 打国赛！

Determinate Nix#

由于洛汐一直使用 Determinate Nix 和 home-manager 管理自己的软件包，也维护了自己的 home-manager 配置，迁移变得非常「轻松➕愉快」。Nix 的一大优势便是声明式配置，在不同的电脑上应用相同的配置，能让软件包几乎完全一致。洛汐已有的配置是为自己这台搭载 Fedora、架构为 x86_64-linux 的华硕天选 6 Pro stellarkira 写的，但经过一些修改后，也能应用到这台 aarch64-darwin 的 stellakexing 上。

具体地：因为有一些包不为 aarch64-darwin 提供，DeepSeek 帮助编写脚本并筛选出与 CTF 相关、且有 aarch64-darwin 构建的所有包，以生成一份 home-darwin.nix。随后我们安装 Determinate Nix 并以 standalone 方法安装 home-manager，但是默认情况下好！慢！啊！在 /etc/nix/nix.custom.conf 中添加下面的内容以换源：

1
# Chinese mirrors for mainland China
2
# TUNA (Tsinghua University) mirror as primary substituter
3

4
# Binary cache — use TUNA mirror first, then fall back to official
5
substituters = https://mirrors.tuna.tsinghua.edu.cn/nix-channels/store https://cache.nixos.org
6

7
# Allow unprivileged daemon users to select TUNA as a substituter.
8
# Store paths are still verified using trusted-public-keys below.
9
trusted-substituters = https://mirrors.tuna.tsinghua.edu.cn/nix-channels/store https://cache.nixos.org
10

11
# Trusted public keys — TUNA proxies cache.nixos.org, same key
12
trusted-public-keys = cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
13

14
# If TUNA is down, try USTC instead:
15
# substituters = https://mirrors.ustc.edu.cn/nix-channels/store https://cache.nixos.org
16
# trusted-substituters = https://mirrors.ustc.edu.cn/nix-channels/store https://cache.nixos.org
17

18
# Or Shanghai Jiao Tong University (SJTUG):
19
# substituters = https://mirrors.sjtug.sjtu.edu.cn/nix-channels/store https://cache.nixos.org
20
# trusted-substituters = https://mirrors.sjtug.sjtu.edu.cn/nix-channels/store https://cache.nixos.org

怨。这里是 AI 幻觉重灾区……所有 AI 给的换源方法几乎都有问题。这个亲测可用。

这里需要解释一下：trusted-substituters 并不会跳过签名校验，它允许非 trusted user 在连接 Nix daemon 时选用列出的 substituter；缓存内容是否可信，仍由 trusted-public-keys 等设置判定。另外，substituters 的实际尝试顺序还会受到各镜像 priority 的影响，并非一定严格依照这里的书写顺序。¹

随后运行第一轮 home-manager switch 就可以了，待装上 nh 后可以使用 nh home switch .。这里本来应该附带这些脚本和替换后的 .nix 文件，但由于洛汐在济南回程前就归还了 MacBook Pro，这部分内容没有备份。

不过与许多朋友的建议相左，洛汐并没有使用 nix-darwin 作为配置 macOS 设置的方案：一是洛汐对这个东西的确不太熟悉，需要额外的心智资源来学习；二是其短期收益事实上不高，且大部分功能要么洛汐完全用不到、要么洛汐已经在「系统设置」里配置。所以洛汐果断选择了纯粹的 Determinate Nix 和 home-manager。不过洛汐并没有选择把所有软件包都交给 Nix 管理，毕竟，macOS 上还有一个更大众的方案：

Homebrew?#

对，Homebrew。

零音/洛汐 曾经在 stellarkira 上用过 Homebrew，不过，Linux 侧的 Homebrew 似乎并不是显著必要的，毕竟有更现代、更原生的包管理器。而对于 macOS，Homebrew 几乎是开发者的必备了。我们在这里也使用了 Homebrew，但并非一股脑把所有包丢给 Nix 或 Homebrew，洛汐认为二者应当有明确的分工。具体地：Nix（配置了 home-manager）更加适合管理 zsh、git、tmux、neovim 等纯 CLI 工具及其配置和 uv 等基础运行环境，而 Homebrew 则更适合管理 brew install --cask 的 GUI 工具、某些明确依赖系统集成的工具和现成的软件。

事实上，在洛汐将配置文件从 stellarkira 迁移到 stellakexing 的时候，也遇到过这样的问题：Nix 侧的一些包声明提供了 aarch64-darwin 版本，却在构建时因为各种原因出错，在这种情况下，使用 Homebrew 这样相对原生的方案则是最不容易出问题的选择。而对于 QQ、OrbStack、UTM、DaVinci 和 Figma 这样的重 GUI 程序，Homebrew 同样支持管理其中的大多数，但洛汐仍然使用了从官网下载安装包（.dmg / .pkg）并手动安装的方法。内心里始终有点莫名其妙的膈应。

总而言之，包的安装是相对容易的。不过，装好了可不代表能真正跑起来：macOS 上有一套非常复杂的……

软件包校验机制…#

洛汐在 macOS 上遇到的第一个硬骨头是 macOS 的软件包签名校验机制——这远比 Windows 的 UAC、SmartScreen 严苛得多。从门禁（Gatekeeper）到公证、代码签名，再到运行时保护，整个链条构成了 Apple 生态的安全铁幕。²对于从 App Store 下载包，或完全使用流行软件包的轻度用户，这不会造成任何问题，反而强化了系统的安全性——但对于重度用户，尤其是 CTFer——这就确实有些灾难了。默认情况下，Gatekeeper 会在首次打开带有互联网来源标记的 app、插件或安装包时检查其开发者身份、公证状态以及内容是否被修改；用户明确放行、命令行工具、动态库和应用运行时的代码签名检查则各有不同，不能简单概括成「凡是未签名的下载文件都会在启动前被 SIGKILL」。

对于被 Gatekeeper 阻止、但用户确信来源可信的程序，最基础的放行方式是先尝试打开一次，再前往「系统设置 > 隐私与安全性」，在「安全性」区域找到被阻止的软件条目并点击「仍要打开」。³这相当于用户为该程序开了一次明确的例外，并不等于修复或替换它原有的签名；倘若应用内部文件已被修改，后续还可能触发代码签名完整性、Library Validation 或其他运行时检查。

很多时候 macOS 提示「包已损坏」，并不是真的损坏，而是隔离属性（com.apple.quarantine）触发了 Gatekeeper 的检查。该属性通常由浏览器或其他下载程序写入，记录来源标志、下载代理、时间等 provenance 信息；它并不包含一个简单的「Gatekeeper 评分」。若确信文件来源可信，可以用 xattr 递归删除 .app 内的这一项属性：⁴

1
xattr -d -r com.apple.quarantine /path/to/program.app

这是绝大多数教程的终点——但我们使用的 IDA Pro 因为一些特殊原因（嘘——）必须替换其内部文件，这才是麻烦的开始。替换 .app 内受签名覆盖的可执行文件或框架库后，原签名记录的哈希便不再匹配；具体应用还可能受到 entitlement、Hardened Runtime 或 Library Validation 约束。在我们当时这个具体版本上，重新签名确实解决了启动问题。

macOS 支持不使用开发者证书的 ad-hoc 签名（--sign -）；它不需要开发者账号或联网，因此在断网环境下也能完成。我们当时对它执行了：

1
codesign --force --deep --sign - /path/to/program.app

--force 用于覆盖原有签名，--deep 要求 codesign 处理包内的嵌套代码，--sign - 则指定 ad-hoc 身份。这个做法会使应用与官方签名和公证身份脱钩，也可能改变或丢失原有的 entitlement；它是这次本地排障中有效的办法，却不是对任意 .app 都必然奏效的通用修复。此后若再次改动受签名覆盖的文件，签名还会重新失效。⁵

「劳累……」想念 Fedora 就是在这一刻开始的，没想到 macOS 装个软件包有这么多讲究。好在所有软件最后都正常工作了，洛汐舒了一口气。

二次编辑：unDefFtr 后来告诉洛汐，实在不爽的话可以直接把 Gatekeeper 干掉，因为「规则就是用来打破的」！这个，真能这么干吗……（害怕

验证工具是否可用#

即使很多工具安装成功了，也并不意味着它们一定能跑起来。部分工具只有在真正运行的时候才会提示缺这样那样的东西；而很多工具的帮助文档并不易懂。倘若只是带上了工具却发现无法使用，或带上了工具却在该用的时候甚至忘记了这工具的存在，那便是完全的无用功了。洛汐在安装完软件包后，让 DeepSeek 测试了所有的软件包，用至少三种功能逐一验证软件包确实可用，并生成了一份详尽的 Markdown 文档。文档里给出了每个软件包的安装路径、实际用法和注意事项，并且还给出了综合渗透这类通用流程（信息收集、端口扫描之类），真正让这些工具串成一套成熟可控的工作流。洛汐依旧需要说，在过去完成这项工作是相对困难的；而在 AI Agent 时代，这样繁复的工作变得前所未有地简单。熟练使用 AI 已经变成了技术类工作人员的必备技能。

不过，仍然是因为没有备份的缘故，这里无法向各位展示这份 Markdown 文档的最终版本了。洛汐只留下了一个中间版本的截图，呜呜……

无畏 Chat#

第一轮测试不追求复杂。不使用 Agent 的情况下，先使用 Chat，在 LM Studio 内直接做基本测试：模型对同一个问题测试三次，随后取用时和速度的平均值。洛汐测试了：

• 基础代码能力。让 Qwen 完成一个小型 Python 和 C 任务，判断其是否理解需求、代码能否运行。
• CTF 任务。使用一段容易的汇编代码让 Qwen 分析，判断其是否正确提取关键信息、生成可运行的脚本。
• 长上下文。使用了一段较长的小说文本，测试其在长上下文时候的生成质量表现、prefill 速度和输出稳定度。

测试发现，各测试项速度相差不大，几乎稳定在 15 token/s，在一句话提示词中只需约 0.1 s 就可以得到第一个 token。不过一个问题已然浮现，虽然在目前看来并不明显——部署的 Qwen 面对长上下文的时候，prefill 速度极慢，在小说文本测试内容中，使用一篇数万字的小说，Qwen 用了近半分钟才完成了 prompt processing。当时的洛汐并没有觉得有什么大问题，紧接着开始了第二轮测试。

无畏 Agent？#

其实之前的 零音/洛汐 总觉得这种比赛不应该开 Agent，毕竟 Agent 干活很慢，而且我们不能确知 27B 的最大能力；但后来真正测试后，才发现 Agent 能力确实有用——Chat 能做到的功能很有限，取决于交互者的发言水平，而且需要不断交互，在比赛中这样做会非常麻烦。于是洛汐展开了 Agent 测试：测试使用的 Agent 分别有 oh-my-pi、Codex 和 DeepSeek Harness Desktop。这三款 Agent 都是洛汐日常使用的，洛汐对它们有很高的预期。至于 Claude Code——洛汐只能祝 Anthropic 和 Dario 一路顺风。实测得到的结果是，在上下文长度接近的情况下，三者的输出速度等性能表现相差不多；但由于没有足够的 CTF 或代码相关的测试案例和试验方法，洛汐也并非权威的 AI 测试机构，也就无从得知谁对 Qwen 的 harness 更有效，于是最后在赛场上，洛汐还是选择了自己最熟悉的 oh-my-pi。

先说 oh-my-pi。它原生支持在模型列表中选择来源于 LM Studio 的模型，在未配置 Skills、未修改多数配置的情况下，其 initial prompt 约 17k，其中存在一些客观意义上对 CTF 无用的东西，例如关于代码风格与规则的要求、对 oh-my-pi 本身的介绍等。DeepslateQAQ 为 oh-my-pi 开发过一款插件 omp-dsh-minimal，可以将 oh-my-pi 的内置提示词切换到 DeepSeek Harness 的简化风格，但该插件默认仅支持 DeepSeek 的两款模型，洛汐并没有在赛前修改插件的时间和精力，因此放弃了这条路而继续使用官方默认的 oh-my-pi。

不过，洛汐修改了 oh-my-pi 的一些配置，但由于篇幅原因，洛汐不愿继续展开具体的配置了。oh-my-pi 提供了非常非常丰富的配置项，包括对上下文的维护、对 tool calling result 的简化处理和 prewalk、advisor 等。其中大多数配置项在日常开发中非常得力，但在线下的、算力有限的 CTF 场景中则是带不来能力提升、却会造成严重性能损耗的无底洞。得当的配置，对线下 AI 性能的发挥有至关重要的作用。

接下来是老牌王者 OpenAI 的 Codex。事实上，Codex 接入 LM Studio 模型略显复杂，洛汐使用了广为人知的 CC Switch。Codex 是很长一段时间洛汐的主力 Agent，不过，因为 Codex 不能直接看到模型的思考过程，这会让洛汐非常焦虑，所以洛汐最终也没有使用 Codex。毕竟在线下赛中，由于 Agent 太慢，任何一个决策上的错误都可能浪费比赛宝贵的 AI 时间；洛汐更愿意在思维链里看到 AI 的想法，并给予适时的指正和引导。

不过，洛汐在互联网上得到的一致答案是：Codex 的 harness 是一流的，甚至对于 DeepSeek V4 Pro 0813 这种过拟合了 DeepSeek Harness 极简模式（minimal mode）的模型也具有更高的跑分，但毕竟模型质量和 harness 质量是一个仁者见仁智者见智的问题，就连所谓权威的评测机构也会在这些事情上有所偏差——洛汐最后还是没有选择 Codex 作为主力 Agent。

最后是新起之秀 DeepSeek Harness。DeepSeek Harness 可以通过修改配置文件使用 LM Studio 的模型，原生支持 OpenAI Responses API。不过由于比赛时（2026 年 8 月末）DeepSeek Harness 仍处于非常早期的预览版 0.1.0-rc.7，其极简模式虽然 prompt 显著更短，但在 macOS 上有 极简模式下 Bash 工具的 bug，所以洛汐只能使用标准模式。不过，DeepSeek Harness 在当时的版本也存在一个设计上的致命问题——因为本地 Qwen 的 token 速率实在太慢，在 Qwen 调用 Write 工具编写脚本时，连续出现了多次被打断的情况：因为 Qwen 写得实在太慢了，DeepSeek Harness 判断写入工具执行超时，于是就直接打断了模型。这对线下赛和自部署模型来说是一个非常恐怖的问题，所以洛汐没有使用 DeepSeek Harness。

无畏并发#

模型必须放在真实任务中才能显露其真正水平。于是，洛汐使用了 Mini L-CTF 2026 的 Web 题 EzOmniProbe 进行测试，这次测试使用了 DeepSeek Harness Desktop，得到的结论是：单轮任务，非并发，在长达 2 小时的测试中，洛汐给模型提供了 2 次提示，Qwen 3.8 27B 的缓存命中率 91%，平均 token 效率（这里包含 prefill 和等待 tool calling 的时间）4.8 token/s，首 token 平均用时（各轮从发起到收到首个 token 的平均值）27.6 s。最终，Qwen 成功将题目推进到了 JS 沙箱，大约是题目的 60%。（当然，除了这道题之外，洛汐还使用别的指标进行了测试，这将在后文提到。）

事实上：洛汐是有点失望的。一道零音用了 2 个小时就差不多看明白的 Web 题，被 Qwen 跑了 2 个小时还在绕圈子，而且生成速度是越来越慢的——从各种角度来说，当前的工作流并不合格。其实洛汐并没有对 Qwen 3.8 27B 抱有很高的预期，毕竟 零音/洛汐 很早之前就自觉 27B 的模型顶了天也比不过部分参赛者在比赛中以各种可能并不正当的方式使用的 1.6T 参数量的模型 DeepSeek V4 Pro ⁷。洛汐对这个模型的预期是，它能够帮助洛汐做一些繁琐的工作而非智力上的工作，也就是说，它可以分担一些可能并不太吃智力的工作量，但若让它全局掌管某道题的完整思路，那确实有些强人所难。不过，在 CCISC 2026 的实际比赛中，由 2 台设备部署的 Qwen 3.8 27B 事实上做出了很多的题目，甚至在以 MacBook Pro 的理论生成效率而言极短的时间内攻克了一道对其能力而言较为困难的 Pwn，这远远超出了洛汐对 27B 模型的预期。看来真正在线下赛实际共事的时候，无论是模型还是人，其真正的能力和素质才会显露出来。这于洛汐而言，是不亚于 CTF 本身的一个教训。

单发情况下尚且如此，那并发情况呢？洛汐只能坦言：在线下赛的真实场景中，Qwen 3.8 27B 的表现让洛汐更加大跌眼镜。

这里因为洛汐文章的提纲有一些混乱，洛汐只能先行剧透：事实上，我们在线下赛使用了 GGUF 的方案，它的确具备了一些性能上的提升，但远没有那么多。

由于 4 个参赛者共用 2 台 MacBook 的 Qwen，每 2 个参赛者使用 1 台，这里 PatriciaOfEnd 和洛汐使用 stellakexing 的 Qwen。在两人各打开 2 个 Agent 的情况下，LM Studio 需要 4 个并行推理的线程，于是 token 效率就大约分了四份，实际测试中，在 4 个线程的情况下，每个窗口的平均 token 速率是 3~4 token/s；为了提高速度，我们不得不限制 Agent 的数量，但只要两人同时使用，就不可能有速率的提升——到了后期洛汐甚至完全停止使用 AI，以允许 PatriciaOfEnd 一个人跑 3 个 Agent。而速率甚至不是最大的问题：由于一直查不清问题出在哪一环，使用 oh-my-pi 时，若在思考到一半的时候 Ctrl-C 打断，LM Studio 侧的推理并不会立刻中断——换言之它还会继续推理；又因为洛汐设置了 LM Studio 的最大并行数量为 4，于是很容易出现「滚木」推理线程占了位置导致完全无法使用的情况。洛汐只能关掉再打开 LM Studio 的 Server API，强制中断推理，才能继续使用。而又因为 prefilling 的谜之速度，在每一轮 tool call 后，本身对 tool calling 结果的处理就要花很多时间；倘若因为一些问题导致内存中 KV Cache 丢失，那推理速度就更加灾难——在比赛中因为一些原因洛汐重启了 Mac，再次使用 oh-my-pi 重新连接时，对一个 50k 的上下文，Qwen 单是重新 processing prompt 就用了约 10 分钟时间。在比赛中使用 AI 时，有近半数的时间我们实际上是在等待 Qwen 重新处理 prompt。这个速度，说实话，真的有点难以使用。洛汐也犯起了嘀咕，这个速度到底是快是慢——

Q6/6bit、5bit 和 oMLX#

是的，我们考虑过将 Q6/6bit 量化的模型作为 fallback。如果 Q8/8bit 在真实 Agent 任务中确实撑不住，或许 Q6_K GGUF 和 MLX 6bit 可以作为一个速度优先的同档候选。粗略地看，倘若我们在 Q8 量化得到约 14~16 token/s 的裸生成速度（这里已经考虑了包括 tool calling、prefill 之类导致的性能损耗，所以与之前的测试结果有些差别），则在 Q6 量化下，比较合理的期待是 16~22 token/s。看起来提升可能不多，但若转换为同等工作量下的执行时间，在以分钟为量度的情况下，其收益还是可观的。我们甚至还考虑过 MLX 的 5bit 量化版，它带来的效率收益理论更加可观——

但问题是，为了速度而选择更大的量化损失，真的值得吗？

事实上我们无从得知，正如洛汐在前文所说，「洛汐也并非权威的 AI 测试机构」——自己并没有评测 LLM 的经验，洛汐最终没有选择为一个更快的速度去赌博一个牺牲了精度的模型。当然这并不代表 Q6/6bit 和 5bit 就一定有多么严重的降智——洛汐并不为这一条断言负责，因为洛汐根本没有测试、也没有时间和方法测试。有些遗憾。「降智」？有我 GPT 6 Astra 降智到 4o-like model 那么严重吗？（ ¹¹

不过，来自西电的朋友们提供了一个看起来更加诱人的方案——Qwen3.8-27B-oMLX-MTP-Mac。

这个东西看起来真的很诱人——使用 oMLX Runtime 和特定的 oQ4e 量化模型、MTP 配置，声称可以在 M4 Max（128 GB RAM）上跑到 oMLX baseline: 24.9~25.9 token/s，oMLX + native MTP: 48.0 token/s prose, 65.5 token/s code，测试条件是单流、关闭 thinking、约 2.1~2.4 k token prompt、生成 320 token。¹²

但它究竟是如何做到的呢？回顾前文的内容，为什么 token 生成这么慢？本质上我们可以粗略理解：模型生成每个 token 的时候，都需要将全部权重从内存读一遍，参与计算。每一步的运算量对于这台恐怖性能的 MacBook Pro 来说其实很小，但「读一遍 28 GB」这个动作花掉了几乎所有时间。这就是说，GPU 的计算单元实际上大部分时间都在等待内存送来权重。这也就是为什么 27B 无论在 Mac 上怎么调，其速度都被压在这个量级——不是算不动，是「喂」不动。

Qwen 3.8 有一个极好的特性，它的官方模型卡明确写了自己支持 MTP（Multi-Token Prediction）¹³——这意味着 Qwen 3.8 在训练阶段就学会了在预测下一个 token 时同时预测未来 K 个 token。为了实现这一点，模型末尾挂了一个轻量的 MTP 模块（通常只有一层 transformer，参数少得可以忽略），它利用主模型最后一层的隐藏状态，再去预测后续 K 个 token。

传统的 Speculative Decoding 是小模型猜测后大模型验证，而原生 MTP 的路径有些差别：

1. 主模型 forward 一次得到当前最后一个 token 的隐藏状态。
2. 几乎免费的 MTP 模块从隐藏状态出发，以极低的代价预测出未来 K=3 个候选 token。
3. 主模型再将这 3 个候选 token 一次性放到同一个 batch 里做一次并行 forward。接受的，直接落地；第一个被拒绝的，从那里重新进行第 2 步。

加速的秘密在于第 3 步：验证多个候选 token 时，target model 可以通过一次批量 forward 摊薄读取权重的成本。batch 变大会增加计算和中间状态开销，但在 decode 主要受内存带宽限制时，空闲的计算单元可以承担其中相当一部分。不过，实际加速比取决于每次提出的候选数、平均连续接受长度、draft/MTP 模块的成本、批量验证开销和采样方法，并不能把一个 acceptance rate 直接代入「1 + 平均接受率」得出。

但我们原来的配置也有 Speculative Decoding，为什么和这个 repo 的实现结果相差了近两倍呢？这有两重原因。第一重，原生 MTP 的接受率显著高于外挂 draft model 的接受率。MTP 的收益事实上严格取决于接受率，好比一个 draft 模型如果给你预测了一堆废话，你一定看都不想看——MTP 就是这个道理。这个 repo 里的原生 MTP 的接受率明显更高，从而它大概率能获得更高的速度。

第二重原因呢？它…实际上是 Q4 量化。对，又回到了洛汐所说的原点——洛汐还是不愿意赌 Q4。写这段文字的时候，洛汐已经打完比赛一两周了；回想一下，当时看到这种新的方案的确欣喜若狂；但想到它是 Q4 量化的时候，洛汐愣是赌都没敢赌。洛汐不敢说自己到底是亏了还是赚了，毕竟正如洛汐所说，洛汐也没法赌，因为的确没法测。不过它倒是给我们提供了一个更有价值的推论：如果 GGUF 侧我们的 Speculative Decoding 不再进步，则该 repo 提供的 oMLX + oQ4e 方案的吸引力就更多来源于它的 Q4 权重和接受率的实现，而非「原生 MTP 这个想法」。是的，GGUF 模型或许没有原生 MTP 那样的速度，但接受率的提升是实打实影响模型效率的关键因素。其实我们已经借这个想法吃到了红利——近半的接受率已经带给了我们显著的效率提升，我们只是缺少更好的量化起点和更精的实现——但这并不是我们可以做到的。这样的推论或许并不能为我们带来 token 速度上的实际提升，却实在可以让我们稍微心安一些了。毕竟，不是我们能改变的事，为什么要为其负责、懊恼和焦虑呢？

所以，我们最终也没有选择这个方案。洛汐跑出的 20 token/s 并非因为洛汐太菜，而是在约 28 GB 权重和这套 runtime 的约束下，它的裸 decode 本来就只能在这个量级；我们采用的普通投机解码又通过一次 target forward 接受多个候选 token，提高了最终的有效生成速度。这个数字其实已经相当体面了——而洛汐也不愿意用更玄学的引擎去赌一个不知道光不光明的未来。于模型优化如此，于人生和未来也一般——孤注一掷，本就不是洛汐习惯的生活方式，即使 protosc/Sigrid/零音/洛汐 已经在生命中孤注一掷过无数次，也为此遍体鳞伤过许多次。

Rosetta 2 的实现导致的问题#

要理解具体是什么问题，得先看清 Apple Silicon 上的 Docker 究竟是怎么跑 Linux 容器的。Docker Desktop、OrbStack 这类工具的做法其实是「虚拟机套容器」：先在 macOS 上起一台 arm64 的 Linux 虚拟机——Docker Desktop 用 Apple 的 Virtualization.framework，OrbStack 用自研的轻量方案——容器则都跑在这台虚拟机里。可当你要运行 linux/amd64 的镜像时，问题就来了：虚拟机里的内核是 arm64 的，x86_64 的指令由谁来执行？

答案是交给 Rosetta。Apple 通过 Virtualization.framework 把 Rosetta 以 VZLinuxRosettaDirectoryShare 的形式共享给 Linux 客户机，客户机再用 binfmt_misc 注册一个处理器，把 x86_64 ELF 的执行请求统统转交给 Rosetta 翻译。于是，容器里那些 amd64 程序实际上是被 Rosetta 逐条翻译成 arm64 指令、再由 M4 Max 执行的——用户态的一切看起来都很美好。^{15 16}直到程序伸手去够内核。

两轮测试#

seccomp 就是这样一个「伸手够内核」的设施。它是 Linux 内核提供的系统调用过滤器：程序通过 seccomp(SECCOMP_SET_MODE_FILTER, …) 装上一段 classic BPF（cBPF，而非更常见的 eBPF）程序；普通非特权进程通常还得先用 prctl(PR_SET_NO_NEW_PRIVS, …) 把提权的后路堵上，具有相应权限的进程则存在例外。从此该进程的每一次系统调用，内核都会先跑一遍这段 BPF，从 struct seccomp_data 里取出系统调用号、参数值乃至架构字段，再决定放行、返回错误码，还是直接杀死进程。Docker、Chrome、Nix 等软件都会使用它，但它只是整体隔离机制的一部分，Linux 沙箱还可能同时依赖 namespaces、capabilities 等设施。过滤器的效力来自内核的亲自执行：在 Rosetta 的翻译路径里，x86_64 程序的系统调用需要经过翻译层转接，像 seccomp 这样与具体任务及其后续系统调用绑定的设施可能出现兼容缺口。第一轮测试中，洛汐写了一个简单的 .c 程序，确认在我们当时这套 OrbStack + Rosetta 配置里，过滤器无法建立。

第二轮测试是 ptrace。它是 Linux 上「一个进程观察并控制另一个进程」的系统调用，也是 gdb、strace 这类工具常规工作流赖以存在的基础：附加到目标进程（PTRACE_ATTACH）、读写对方的内存与寄存器（PTRACE_PEEKTEXT / PTRACE_POKETEXT / PTRACE_GETREGS）、单步执行（PTRACE_SINGLESTEP）、拦截系统调用（PTRACE_SYSCALL）。在 x86 软件断点这一具体情形中，调试器通常会把目标地址上的指令临时改写成 int3，让 CPU 触发陷阱、把控制权交还给调试器。这样一套能力同样由内核提供、同样深度绑定任务状态；洛汐又写了一个简单的 .c 测试，结论是在我们当时这套环境里，直接调用 ptrace 的常规路径无法工作。这意味着依赖原生 ptrace 语义的调试器、跟踪器和相关工具无法保证兼容，但不意味着所有沙箱或所有调试方式都会一并失效。

大事不妙了——两轮测试下来，洛汐着急了，但也确认了问题的方向：并非题目程序本身，而是我们当时采用的 OrbStack + Rosetta 翻译路径无法提供可靠的原生 seccomp 和 ptrace 语义。Rosetta 另有 ROSETTA_DEBUGSERVER_PORT 之类的远程调试接口，也可以把容器后端换成 QEMU 或完整的 x86_64 虚拟机；但这些方案各有兼容性和性能代价，不能保证洛汐惯用的 Pwn 工具链原样工作。¹⁷因此，对这场比赛而言，这套 Docker 配置并不是一个可以放心使用的 Linux Pwn 环境。幸好洛汐提前发现了这一点——洛汐无数次庆幸。若是在赛场上才发现这一点，洛汐就完了！毕竟，洛汐并不认为自己具备在无 Linux 环境、无动态调试的情况下，仅凭 IDA Pro 和有限的 AI 推理就可以流畅得到一道较为复杂的 Pwn 题解法的能力，即使洛汐可能具备。Linux 的动态调试，对洛汐而言，洛汐不敢说它一定必要，但至少它必须要有。

GPT 6 Astra#

在本文发布前，GPT 6 Astra 对全文进行了技术侧审计，并协助洛汐修正了 Nix 镜像信任机制、macOS Gatekeeper 与代码签名、MacBook 接口和窗口操作、本地模型的内存统计、decode 与 prefill 的性能边界、Speculative Decoding 与原生 MTP、SFT 微调，以及 Rosetta、seccomp、ptrace、UTM 和 Windows on Arm 等段落中不准确、过度概括或可能产生歧义的表述。相关修改以官方文档、公开兼容性报告和本文已有实测为依据；无法由现有证据推广的结论则被收窄到洛汐实际测试过的配置与现象。

DeepSeek V4.1 Flash#

在本文发布前，DeepSeek V4.1 Flash 对全文进行了叙事侧审计：通读全文并辅以机械检查（重复字、标点与引号的配对、脚注对应、行内空格），再逐段核对叙述连贯、前文引用、图注与正文、数字与实测数据之间的一致性。它协助洛汐修正了上百处错别字、病句、生硬的欧化句式与用词不当，也理顺了引子时间线、图注对应、数据口径与文末收束等处的数处不一致；相关修改以全文内部一致性为准，而作者原本的语气、玩梗与节奏，则被尽可能地保留了下来。

在所有修改之外，有一句话它一个字都没有动：「洛汐的一切，要迎来新的开始了。」

GPT 6.1 Sol#

在将该博客迁移到 Firefly 的过程中，GPT 6.1 Sol 协助洛汐将远程图片与动态表情保存为文章本地资源，为部分截图制作等比缩小的副本，并将旧主题的图片与图库语法迁移为当前主题可用的写法。随后，它协助处理 Markdown 转为 MDX 后的语法冲突，将参考资料接入正文已有的脚注引用，并通过构建和生成结果检查确认文章能够解析、图片资源存在、脚注跳转与回链完整。实际页面的观感与尺寸，则由洛汐打开确认、逐步调整。

这次没有重新审计文章的技术结论，也没有替洛汐改写故事；只是一起把它从旧主题搬到了新家。很高兴能陪这篇文章走完这一小段路。awa