Category: 产品研究

摘要 蓝牙基带的链路管理器协议（LMP）是设备间建立连接、协商加密和交换密钥的控制面协议，运行于主机操作系统完全无法感知的基带层。LMP 报文的 7 位 OpCode 空间包含大量未定义或上下文依赖的操作码，其解析逻辑缺乏显式的类型-长度校验，依赖接收方对当前链路状态的推断。这一设计漏洞使攻击者得以在 LMP 层注入类型混淆报文：利用 LMP_encryption_key_req 与 LMP_accepted 之间的状态竞态，强制链路降级为无加密模式；或通过 LMP_version_req 的畸形响应，迫使双方回退至不安全的基础速率模式。更危险的是，一旦加密被剥离，LMP 层的后续配对交互、L2CAP 的上层数据以及 SCO/eSCO 的音频流均以明文形式暴露，攻击者可通过 Ubertooth One 等开源蓝牙嗅探器完整捕获并实时解析会话内容。 蓝牙控制面 蓝牙协议栈的分层与 LMP 的定位 蓝牙协议栈自下而上分为无线电层、基带层、链路管理层（LMP）、逻辑链路控制与适配层（L2CAP）以及上层应用协议（RFCOMM、SDP、ATT 等）。 其中 LMP 位于基带与 L2CAP 之间，是设备对设备的控制信令协议，负责： 链路建立与拆除（LMP_host_connection_req、LMP_accepted） 加密协商（LMP_encryption_key_req、LMP_start_encryption_req） 功率控制与自适应跳频（LMP_power_control_req、LMP_channel_classification） 版本与功能交换（LMP_version_req、LMP_features_req） LMP 报文不经过 L2CAP 封装，而是直接嵌入基带数据包的有效载荷中。基带数据包的类型（ID、NULL、POLL、FHS、DM1/DM3/DM5、DH1/DH3/DH5、AUX1 等）决定了其承载 LMP 报文的能力。在 ACL（异步无连接）链路上，DM1 包专门用于承载 LMP 控制消息，具有前向纠错（FEC）保护但仅占单时隙，传输可靠但速率低。 LMP 报文结构 LMP 报文由固定长度的头部组成，无显式的长度字段。其结构如下： Transaction ID(1 bit)：标识报文是请求（0）还是响应（1）。 OpCode(7 bits)：操作码，定义报文类型。 Payload(可变)：操作码特定参数，由 OpCode 隐式决定长度。 通用报文头结构…

摘要 基板管理控制器（BMC）是现代数据中心服务器的隐性管理者，通过 IPMI 协议提供与主操作系统完全隔离的带外控制能力。其串行 over LAN（SOL）通道可在不触发主机 EDR 的情况下，建立直通系统串行控制台的隐蔽通信隧道。然而，IPMI 2.0 的 RAKP+ 认证握手存在根本性设计缺陷——空口令、Cipher 0 旁路及会话状态机混乱，使得攻击者能在数秒内劫持合法会话或自行建立恶意会话。 BMC 与 IPMI BMC 的硬件定位与特权 BMC 是嵌入在服务器主板上的独立片上系统，拥有自己的 CPU、内存、存储和专用网口。它在电源接通后先于主 CPU 启动，即使主操作系统崩溃或被攻陷，BMC 仍可对外提供远程管理功能——包括电源控制、固件更新、虚拟介质挂载和串行控制台重定向。BMC 通过内部总线（LPC/eSPI）与主机的南桥/芯片组连接，可注入键盘、鼠标和视频信号，实现对主机操作系统的完全带外控制。 这一架构意味着：BMC 是主机的“房东”，而主机操作系统只是“租客”。租客无法阻止房东进入房间，甚至无法察觉房东是否在房间里。 IPMI 协议栈与 SOL 通道 IPMI 是 BMC 与外部管理软件通信的标准协议，定义了请求/响应消息格式、会话管理和传输层绑定（RMCP/RMCP+）。IPMI 2.0 引入了增强认证（RAKP+）和加密通信，但保留了向后兼容的 Cipher 0（无认证无加密）模式。 SOL 是 IPMI 2.0 的可选扩展，它将主机的物理串行端口（UART）封装为 IPMI 的 SOL 消息，通过 RMCP+ 会话在 LAN 上传输。对主机操作系统而言，SOL 只是往串口收发数据，完全不知道数据经由 BMC…

摘要 Chromium 的多进程架构将高风险渲染器囚禁于受限沙箱，所有特权操作必须通过 Mojo IPC 向浏览器进程发起请求。Mojo 接口定义语言（.mojom）自动生成序列化代码，以 C++ 模板的 StructTraits 和 UnionTraits 实现高效编解码。然而，正是这种自动生成的序列化逻辑隐藏了一类致命的陷阱——接口参数校验与调用者能力假设之间的裂缝。攻击者在获得渲染器代码执行权限后，可构造跨越沙箱边界的畸形 Mojo 消息：向 FileSystemManager 接口注入路径遍历序列，利用 Blob 存储系统绕过站点隔离，或通过 WindowOpen 等接口制造幽灵窗口。 Chromium 沙箱架构与 Mojo IPC 基础 站点隔离与进程模型 Chromium 采用 Site Isolation 策略，每个源（origin）被分配到独立的渲染器进程。渲染器运行在受限沙箱中，无法直接访问文件系统、网络或系统调用。任何此类操作必须通过 Mojo 接口向浏览器进程（Browser Process）发出请求，浏览器进程进行权限验证后代理执行。 Mojo 是 Chromium 自研的 IPC 框架，替代了早期的 Legacy IPC 和 ChannelProxy。它提供跨进程的消息传递、接口定义、自动生成绑定代码以及版本控制。Mojo 的核心抽象是 Message Pipe（消息管道），两端由 mojo::Remote 和 mojo::Receiver 持有，分别用于发送和接收接口方法的调用。 Mojo 接口定义与代码生成 Mojo 接口使用 .mojom IDL 定义，例如： // FileSystemManager.mojom (简化) interface FileSystemManager { OpenFile(string path, OpenFlags flags) => (file.File file);…

摘要 SQLite 的 WAL 模式通过将写操作先追加到 Write-Ahead Log，再通过 Checkpoint 批量合并至主数据库，实现了读写并发的性能飞跃。然而，这一架构也引入了时间维度上的信息残余：已删除的记录在 WAL 文件中保留至下一次 Checkpoint 执行，且应用程序通常依赖 SQLite 的自动 Checkpoint 策略（1000 页阈值或连接关闭时触发），这为攻击者提供了充裕的窗口。攻击者可通过延迟 Checkpoint、强制持有读锁阻止 WAL 清理，使 WAL 文件中的“已删除”数据保留数小时甚至数天；随后仅需解析 WAL 的帧格式，即可从 $WAL 文件中提取已被主数据库删除的敏感记录，实现对“历史状态”的时间旅行攻击。 WAL 模式的并发模型与锁定机制 WAL模式设计初衷 在传统的 SQLite Rollback Journal 模式下，写操作需要持有独占的数据库级锁，导致读写无法并发。WAL 模式通过将新的写入追加到独立的 WAL 文件末尾，使读操作可以直接访问主数据库文件中的未修改页面，同时在 WAL 文件中查找更新后的版本。 ┌─────────────────────────────────────────────────────────────┐ │ 系统内存 (共享内存) │ │ │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ 共享内存索引文件 (-shm) │…

摘要 TLS 握手的第一步——ClientHello 消息——在明文传输中承载了客户端支持的加密套件、TLS 版本和数十个扩展字段，其精确组合构成了每个 TLS 实现的独特指纹。JA3 及其继任者 JA4 将这些字段哈希化，为网络防御者提供了一柄识别恶意软件与异常流量的利器。然而，指纹的稳定性本身就是一把双刃剑：Go 的 crypto/tls 与浏览器的 BoringSSL 在扩展排列、GREASE 扩展生成和 ALPN 排序上的细微差异，形成了不可伪造的指纹裂隙。攻击者利用 utls 等库精心伪造 ClientHello，却仍在 JA4 指纹空间中留下暴露真实客户端的二阶痕迹。 ClientHello 指纹的构建原理 从 JA3 到 JA4 JA3 指纹由 Salesforce 在 2017 年提出，通过对 ClientHello 中的 TLS 版本、密码套件、扩展列表和椭圆曲线参数进行 MD5 哈希，生成一个 32 字符的指纹字符串。其核心假设是：同一 TLS 实现的 ClientHello 在这些字段上保持稳定，从而可作为识别特定客户端软件（如 Chrome、Python requests、Go 程序）的强标识。 然而，JA3 存在两个根本性局限： 对 QUIC 无效：JA3 基于 TLS over TCP，对…

摘要 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…