themalwareguardian/uefi-security-research-howyar-sysreturn-netcopy针对 CVE-2024-7344 的 Howyar SysReturn NetCopy 事后分析——逆向工程笔记、存在漏洞的二进制文件、与厂商的通信记录，以及针对 CVE-2026-79298（通过 BOOTia32.efi 中的 RxPE 自定义 PE 加载器绕过 IA-32 安全启动）的概念验证工具。
在 Secure Boot 的掩护之下，某些架构沉得比暴露它们的漏洞更深。有些二进制文件被吊销了。有些补丁被发布了。但在水面之下，旧习惯留下了痕迹。这就是当一个漏洞被披露、修补、遗忘之后所残留的东西。
本仓库中记录的发现已被分配 CVE-2026-79298。
在协调披露过程中，厂商确认与 CVE-2024-7344 相关的修复仅处理了 x64 启动路径。IA-32 启动路径——包括作为 SysReturn NetCopy 功能一部分分发的 BOOTia32.efi——从未被纳入最初的修复范围。因此，存在漏洞的 IA-32 组件一直以商业方式分发，直到版本 11.3.034（2026 年 7 月）。
专门的 CVE 仓库链接回此处以获取完整的技术深度内容：逆向工程、二进制分析、厂商往来通信、复现产物以及概念验证工具。
整个 2026 年，我一直深入钻研 UEFI 安全——bootkit 开发、Secure Boot 绕过、固件利用、CVE 分析、开发攻击性工具、发布研究成果。这是我所选择专攻的领域，每周都会带来新的东西。这项工作的一部分涉及利用 UEFI 组件中已知的 CVE。一部分涉及研究那些随附 UEFI 引导加载程序但很少受到公众审视的软件。还有一部分——也就是本仓库所记录的这一部分——涉及提出一个我认为经常被忽视的问题：
一个产品在经历 CVE 之后会是什么样子？
不是在补丁匆忙发布期间。不是在公告发布的那一周。而是在十八个月之后，当压力消失、研究人员已经转向别处、再没有人关注的时候。
本仓库就是我尝试为某一个具体产品回答这个问题的成果：Howyar SysReturn NetCopy。
而且我认为我的发现会让人们感到惊讶。
如果你顺着线索追得足够远，安全研究中的一切都会与其他事物相连。这条特定的线索始于工作。我们的任务是分析 UEFI 和 bootkit 攻击对某一类特定环境的现实风险：教育中心。这听起来很小众。其实并非如此。
以下是该领域之外的大多数人没有充分认识到的现实。在一座中等规模的城市里，学校中部署的共享设备很容易达到 70,000 台甚至更多——供八到十五岁学生使用的笔记本电脑和工作站，运行 Linux 发行版，因为在这个规模上 Windows 的授权费用往往高得令人望而却步。
现在问问你自己：这些机器中有多少正确启用了 Secure Boot？在大多数地方，诚实的答案是很少。原因并非疏忽。而是运维现实。
在 Linux 环境中正确启用 Secure Boot 意味着要对每一个内核进行签名。每一次内核更新——而近年来 Linux 内核漏洞层出不穷——都需要将新的已签名镜像部署到每一台机器上。这意味着需要协调的更新流水线、密钥管理基础设施、受过培训的人员，以及在分布在数十个地点的数千个终端上进行持续维护。
对于拥有这些资源的组织来说，这是可以应付的。对于大多数学区来说，则不然。在那个规模上，根本没有足够的人手、足够的预算和足够的工具来把它做对。所以 Secure Boot 一直处于禁用状态。
BIOS 密码也不会被设置——因为在人手有限的情况下，在 70,000 台机器上轮换密码是不切实际的。于是这些机器就摆在那里，在固件层面完全暴露，每天被数百名学生使用。
从安全角度来看，这实际上意味着，一个懂得 UEFI 利用的攻击者可以在固件层攻陷其中一台机器——在操作系统加载之前，在任何安全软件启动之前，在任何保护机制有机会介入之前。bootkit 可以跨重启、跨操作系统重装、跨一切持久存在。我之所以知道这一点，是因为我自己就开发这类工具。这些技术是存在的。它们并非理论。
这是一个已知问题。它被广泛承认。而且它不会很快消失。
针对该问题的运维应对措施——学校实际部署用来替代正规 Secure Boot 的东西——是还原软件。
其思路很直接：无论学生在一次会话期间做了什么，一切都会在下一次重启后恢复到已知的干净状态。恶意软件、配置更改、损坏的系统文件、意外或故意删除的数据——统统消失。这大幅降低了维护成本，并让管理员有办法管理共享机器，而无需在每台设备上具备完美的固件级安全控制。
当我们开始评估这些环境中正在使用哪些产品时，出现了几个名字。其中之一就是 Howyar SysReturn——一款专为教育部署设计的台湾产品，明确支持学校计算机实验室、共享工作站和大规模受管环境。
我一看到这个名字，就立刻知道自己想做什么。
2025 年 1 月，ESET Research 公开披露了 CVE-2024-7344——一个影响 SysReturn 以及其他几款基于同一代码库构建的还原产品的 Secure Boot 绕过漏洞。
这个漏洞以一种令人深感沮丧的方式显得优雅。一个由 Microsoft 签名的 UEFI 应用程序——被固件信任，即使在启用 Secure Boot 的情况下也能运行——完全从零实现了自己的自定义 PE 加载器。它没有使用会强制执行 Secure Boot 签名验证的标准 UEFI LoadImage 和 StartImage 函数，而是手动从一个名为 cloak.dat 的文件中解析并执行 EFI 二进制文件。使用单字节密钥进行 XOR 加密。没有签名检查。该文件中的任何内容都以完整的固件级信任运行。
Microsoft 在 2025 年 1 月的 Patch Tuesday 更新中吊销了存在漏洞的二进制文件。安全行业转向了下一件事。但我一直在思考它。
不是因为漏洞本身未解决——ESET 已详尽记录了它，吊销也很明确。一直萦绕在我心头的是另一个问题。那种只有随着时间推移才能回答的问题：
他们真的修复了它吗？还是只是绕过了压力？
这两者是有区别的。真正的修复解决根本原因——在本例中，就是使用绕过 Secure Boot 的自定义 PE 加载器。而变通做法则让眼前的问题消失，同时保留底层架构不变。
我想知道 Howyar 做的是哪一种。
我直接联系了 Howyar Technologies，请求提供一份 SysReturn 的评估副本，用于专业采购评估——考虑到最初促成这项研究的专业背景，这完全属实。
厂商很配合，响应也很及时。他们提供了完整的试用许可证、手册、教程视频以及完整的评估包。他们还回答了关于 Secure Boot 兼容性的详细问题，而这些问题后来被证明与我发现的内容直接相关。
所有这些往来通信都未经编辑地收录在本仓库中。
我不打算在这里剧透技术细节——那正是 Vulnerability Research 目录的用途，而且我真心建议完整阅读它。但我会说这么多。
UEFI 是它自己的世界。在其中工作的开发者寥寥无几。为应用软件或 Web 服务而存在的安全审查流程，并不会常规地触及固件组件。不良做法一旦形成，往往会持续存在——并非出于恶意，而是因为生态系统很小，审视很少，而出错的后果往往对除了少数关注它的研究人员之外的每个人都是不可见的。
我在 SysReturn v11.2.031 中发现的——该版本发布于 2026 年 4 月，即 Microsoft 吊销之后超过十五个月——正是这种动态的一个清晰例证。
根本原因没有被修复。存在漏洞的二进制文件没有被替换。改变的是运维层面：为启用 Secure Boot 的系统采用了不同的启动路径，而几乎其他一切原封不动。
自定义 PE 加载器——即 RxPE 组件，在二进制文件自身的调试字符串中被命名——存在于 2026 年 4 月的版本中，其功能与 ESET 在 2024 年分析的那个版本中的功能完全相同。
Howyar 在 2026 年 4 月分发的二进制文件的 Authenticode 哈希，与 Microsoft 在 2025 年 1 月吊销的哈希逐字节完全一致。
我认为这很重要。我认为人们应该知道这件事。而且我认为本仓库中的技术文档足够详尽，任何想要自行验证这些发现的人都可以做到。
| 目录 | 描述 |
|---|
📚 00 Manual | Howyar 提供的厂商手册、宣传册和官方产品文档 |
📦 01 Binaries | 从评估包中提取用于分析的关键二进制文件 |
📬 02 Disclosure | 评估过程中与 Howyar Technologies 的完整电子邮件往来 |
🔬 03 Vulnerability Research | 逆向工程、二进制分析、Authenticode 验证、ALRM 格式分析、脚本以及技术发现 |
技术故事——对 BOOTia32.efi 的完整逆向工程、ALRM 载荷格式、XOR 解密、RxPE 自定义 PE 加载器、与被吊销二进制文件的 Authenticode 哈希匹配，以及对 Howyar 实际改变了什么与留下了什么未动的分析——全部在：
➡️ 漏洞研究
如果你想在深入“补丁后”分析之前了解 CVE 本身的背景，ESET 的公告是一个很好的参考。我还维护着一个记录 CVE-2024-7344 及相关 UEFI 漏洞的仓库，其中有更详细的说明。
开始阅读吧。斗篷仍然在那里。
