Nim 的 C-FFI 隐身衣

摘要 Nim 语言凭借其接近 C 的性能与 Python 般简洁的语法，正逐渐成为恶意软件开发者的新宠。其独特的编译期代码执行能力，使得恶意代码可以在编译时读取系统信息、生成仅在特定目标环境中激活的分支，并直接绑定 Win32 API——不依赖 LoadLibrary/GetProcAddress 的动态解析，也不在导入表中暴露敏感函数名。与 Go 的 cgo 和 Rust 的 cc crate 不同，Nim 生成的 C 中间产物在最终二进制中几乎不留痕迹，逆向工程师面对的是一张高度定制的“C-FFI 隐身衣”。 Nim编译管道与C-FFI绑定 Nim 编译器的工作流程 Nim 编译器（nim）并非直接生成机器码，而是默认通过 C 后端生成 C 源代码，再调用系统的 C 编译器（GCC、Clang 或 MSVC）完成最终编译。这一设计的核心优势在于：Nim 程序天然具备与 C 语言相同级别的底层访问能力，同时保留了高级语言的类型安全和元编程能力。 编译流程分为四个阶段： Nim 源码解析与语义分析：编译器将 .nim 文件解析为 AST，进行类型推导和宏展开。 中间表示生成：经过语义检查的 AST 被转换为 Nim 虚拟机指令或直接进入代码生成阶段。 C 代码生成：代码生成器遍历中间表示，输出对应的 C 代码。Windows 下通常输出 .nim.c 文件，包含所有函数的 C 实现和 Nim 运行时支持代码。 C…

iBoot SMMU 绕过与 Kernelcache 结构体伪造

摘要 Apple Silicon 的安全启动链从 Boot ROM 到 iBoot 再到 Kernelcache，层层验证，构筑了封闭生态中最坚固的信任根基。然而，iBoot 阶段的系统内存管理单元初始化和设备树解析，依赖一套早于 XNU 内核建立的内存映射机制。攻击者若能在 iBoot 执行阶段污染设备树中的 DART 节点，便可在 SMMU 页表创建之前植入虚假的 IOMMU 映射，使内核在不知情的情况下使用被篡改的 DMA 保护配置。 Apple Silicon 的启动链与信任模型 从 Boot ROM 到 Kernelcache 的信任传递 Apple Silicon Mac 的启动过程分为四个严格校验的阶段： Boot ROM：芯片出厂固化代码，不可修改。验证下一阶段的签名（iBoot），仅在 DFU 模式下可通过外部刷新进行恢复。这是信任的物理根基，也是 checkm8 等永久性漏洞的所在层。 iBoot：Apple 的第二阶段引导加载器，负责初始化硬件（包括 SMMU、内存控制器、PCIe 根复合体），解析设备树并选择启动内核。iBoot 本身由 Boot ROM 验证签名。 Kernelcache：XNU 内核及其扩展的预链接映像，由 iBoot 验证签名后解压加载。内核启动后依赖 iBoot…

通过 AER 滥用和 ECRC 劫持实现 DMA 重定向

摘要 PCI Express 链路上传输的每一条 DMA 读写请求都被封装为 TLP（事务层数据包），携带设备标识符和目标物理地址。IOMMU 通过 BDF 编号和地址转换表对这些请求进行合法性检查，阻止未经授权的内存访问。然而，TLP 层存在一个容易被忽视的攻击面：高级错误报告（AER）允许设备向根复合体报告各类错误，而端到端 CRC（ECRC）本用于检测传输过程中的比特翻转，却可能被恶意设备主动操纵，迫使接收端进入错误恢复流程。在错误恢复的重传机制中，如果攻击者能够制造 TLP 的“合法重放”，并将其中的物理地址字段替换为攻击目标，便能在 IOMMU 检查之前完成 DMA 重定向。 PCIe TLP 与 DMA 的权限模型 TLP 的结构与路由 PCIe 采用分层协议，事务层负责在设备与主机之间传输数据。 每个 TLP 包含： TLP 前缀（可选）：用于扩展头信息。 TLP 头：包含格式（Fmt）和类型（Type）字段，决定 TLP 是存储器读写、配置读写、消息还是完成包。对于存储器写 TLP，头中还有地址字段（32 位或 64 位物理地址）。 数据载荷：实际传输的有效数据。 TLP 摘要：可选字段，包含 32 位的 ECRC，用于检测端到端的比特错误。 在 DMA 操作中，设备主动向主机内存发起读写请求。主机芯片组中的根复合体（Root Complex）根据 TLP 头中的 Requester ID（Bus/Device/Function，BDF）和地址进行路由，并由 IOMMU…

PAC 签名无效引发的域信任降级攻击

摘要 Kerberos 票据中的特权属性证书承载着用户的组成员身份和安全标识符，其完整性由 KDC 的长期密钥签名保护。然而，当 PAC 签名验证失败时，Windows 域控制器的默认行为并非一律拒绝，而是在特定配置下（尤其是跨林信任场景中）采取降级策略——忽略 PAC 签名错误，转而使用 Active Directory 中存储的组成员身份重建用户的访问令牌。攻击者可构造 PAC 被篡改或签名缺失的 TGT，利用跨林信任的 SID 过滤与选择性认证盲区，将低权限用户提升为域管理员。 PAC 签名架构与信任边界 PAC 的双签名体系 Kerberos PAC 是微软对标准 Kerberos 协议的扩展，嵌入在 TGT 和 ST 的授权数据字段中。它包含用户的 SID、组成员身份 SID 列表以及用于权限判断的额外信息。为了防止用户或恶意服务篡改 PAC 内容，微软采用了双签名机制： 服务签名：使用目标服务账户的密钥对 PAC 内容进行签名，验证该 PAC 确由 KDC 为该服务签发。 KDC 签名：使用 KDC 自身密钥对 PAC 进行二次签名，提供额外的完整性保障，防止拥有服务密钥的内部人员伪造 PAC。 这两组签名数据存储在 PAC_SIGNATURE_DATA 结构中，分别包含签名类型（如 Kerberos、HMAC_SHA1_96）、签名算法标识符和签名值本身。 PAC 结构及签名位置:…

CT日志、SCT签发时间与证书透明度的时间回拨攻击

摘要 Certificate Transparency 通过 Merkle Tree 哈希链保证证书的不可抵赖性，SCT 记录了 CA 签发证书的精确时间，二者共同构成了现代 TLS 信任体系的审计根基。然而，CT 日志服务器的时间戳可信吗？如果攻击者能够操控 NTP 同步路径，便可在证书签发时间与 SCT 时间之间制造足以掩盖入侵窗口的差异，使证书吊销检查和 CT 监控双双失效。 Merkle Tree 与 SCT 的时间锚点 Certificate Transparency 的设计初衷 2011 年，荷兰证书颁发机构 DigiNotar 遭入侵，攻击者为其未控制的域名（包括 Google 和 CIA）签发了超过 500 张伪造证书，随后在伊朗用于大规模中间人攻击。事件曝光后，DigiNotar 宣告破产，浏览器厂商紧急撤销其根证书。这一事件暴露了 TLS 信任模型的结构性缺陷：CA 可以为其未被授权的域名签发证书，而依赖方（浏览器）无法实时获知滥用行为。 Certificate Transparency 正是为解决这一“CA 信任无限”问题而生。CT 要求 CA 将签发的每一张证书提交到至少一个公开的 CT 日志服务器，日志服务器将该证书追加到一条仅可追加、不可删除的 Merkle Tree 哈希链中，并返回 Signed Certificate Timestamp（SCT）作为证书已被记录的证明。依赖方（浏览器）在验证证书时检查其是否包含有效的…

UBTI的攻击面测绘与 COM 劫持

摘要 Windows 计划任务早已超越“定时执行脚本”的原始范畴。自 Windows 10 1607 引入统一后台任务基础设施（UBTI）后，大量系统与第三方任务被悄然迁移至 COM 组件驱动的新架构，由 taskhostw.exe 进程承载。这一变革在提升可靠性的同时，也将攻击面从 XML 配置文件扩展到了 COM 注册表与 DLL 加载路径。攻击者不再需要写入恶意脚本，而仅需劫持一个计划任务所引用的 COM CLSID，即可将系统原生的合法任务转化为隐蔽的持久化触发器。 UBTI架构 传统计划任务模型 长久以来，Windows 计划任务的核心引擎是 Schedule 服务（schedsvc.dll），运行在 svchost.exe -k netsvcs 共享进程中。任务定义以 XML 格式存储于 C:WindowsSystem32Tasks 目录，管理员通过 schtasks.exe 命令行工具或任务计划程序 MMC 管理单元进行管理。执行时，传统任务启动一个独立的进程（如 cmd.exe /c script.bat），其生命周期完全可见于进程树中。 这种模型简单明了，但也存在明显局限：失败重试机制脆弱、任务隔离性差、对触发条件的响应不够精细。更关键的是，随着 Windows 向“系统即服务”演进，大量后台维护工作（如磁盘整理、系统诊断、Windows 更新后任务）需要更高级的执行容器。 统一后台任务基础设施 Windows 10 版本 1607 引入了统一后台任务基础设施（Unified Background Task Infrastructure，UBTI），作为“后台任务现代化”工程的核心组件。UBTI 并非替换计划任务调度器，而是为其增加了一套全新的执行路径。 在 UBTI 模型下，一个计划任务可以注册为COM 任务——其操作不是启动一个可执行文件，而是实例化一个实现了 ITaskHandler 接口的 COM 组件。该接口定义了两个核心方法： Start：接收任务触发信息，执行任务逻辑。 Stop：接收任务取消请求，执行清理。 任务的实际执行者不再是 cmd.exe 或用户指定的可执行文件，而是 COM 代理进程 taskhostw.exe。该进程以当前用户的会话权限运行（部分系统任务以 SYSTEM…