赛博防暴演习：C++ 指针完整性加固与 PAC 技术实战指南

各位 C++ 极客们，下午好！

欢迎来到今天这场关于“如何把你的代码锁进保险箱”的讲座。我知道，你们中的很多人，尤其是那些写过一点大型项目的人，都有过那种深夜惊醒的经历：梦里全是 Segmentation Fault，手里还紧紧攥着半杯凉掉的咖啡。

今天我们不聊 std::vector 的扩容策略，也不聊虚函数表的内存布局。今天我们要聊的是更硬核的东西——安全。

具体来说，我们要聊的是如何利用 硬件辅助指针认证 技术，来对付那个在 C++ 内存世界里游荡的幽灵——返回导向编程。

准备好了吗？让我们把安全带系好，这趟旅程可能会稍微有点颠簸，但绝对安全。

---

第一章：幽灵代码与“吃剩饭”的攻击者

首先，我们需要理解我们的敌人是谁。

在 C 语言时代，攻击者要想执行任意代码，通常需要“注入”代码。这就像是你去参加派对，你得把一整瓶酒倒在派对上，然后跳上桌子跳舞。这动静太大了，保安（操作系统）很容易发现。

但是，到了 C++，特别是现代操作系统和编译器开启了 ASLR（地址空间布局随机化）之后，攻击者发现“注入代码”变得非常困难。因为操作系统把代码的地址打乱了，你不知道代码在哪里，怎么注入？

于是，幽灵出现了。这就是 ROP（Return-Oriented Programming，返回导向编程）。

ROP 是怎么工作的？

ROP 的核心思想非常简单，甚至可以说有点“抠门”。它的逻辑是：我不注入新代码，我只利用已经存在于内存里的代码片段。

想象一下，攻击者成功破坏了一个函数的栈帧。他篡改了 ret 指令（返回指令）要跳转的地址。这个地址指向哪里呢？他指向了内存中已经存在的某一段合法代码，我们称之为 Gadget。

举个例子，假设你的程序里有一个函数 int add(int a, int b) { return a + b; }。编译器生成的汇编代码里，肯定有类似这样的指令序列：

add x0, x1, x2   ; 计算 a + b，结果存入 x0
ret              ; 返回

这一小段代码就被称为一个 Gadget。

攻击者的操作流程是这样的：

1. 爆破：通过溢出覆盖栈上的返回地址。
2. 投毒：把返回地址改成指向 add 函数里 ret 之前的那个 Gadget 的地址。
3. 进食：CPU 执行到 ret 时，跳转到 Gadget。Gadget 执行完 add，然后再次执行 ret。
4. 循环：这个 Gadget 的 ret 地址又被攻击者精心设计过，指向另一个 Gadget……如此循环往复，直到攻击者执行了 execve("/bin/sh", 0, 0)，从而获得了一个 Shell。

这就像是去参加自助餐，你不想自己做饭（注入代码），你只想把别人盘子里的菜（已经存在的代码）端走，拼凑成你想要的大餐。

在 C++ 中，这种攻击尤为猖獗。为什么？因为 C++ 有大量的虚函数、函数指针、std::function、回调函数。这些东西本质上都是“指针”。如果这些指针被攻击者篡改了，而 CPU 却傻乎乎地相信它，那么整个程序的地基就塌了。

---

第二章：指针——C++ 的双刃剑

在深入 PAC 之前，我们必须谈谈指针。

在 C++ 里，指针就像是房子的钥匙。如果你把钥匙交给任何人，并且不锁门，那谁都能进。

传统上，我们用 ASLR 来隐藏钥匙插在哪个锁孔里，用 DEP（数据执行保护）来禁止把钥匙插在锁孔里（即禁止代码段可写）。

但是，ROP 攻击者发现了一个致命的漏洞：栈。

在函数调用过程中，返回地址就存储在栈上。虽然 ASLR 随机化了栈的地址，但攻击者可以通过溢出，覆盖掉这个返回地址。因为栈是可写的，攻击者可以随意修改这个“钥匙”。

C++ 的痛点

C++ 的灵活性使得指针管理变得异常复杂。

• 类型转换：reinterpret_cast，void*。这些操作就像是在说：“嘿，我不关心这个指针到底指向谁，我只把它当数字看。” 这给了攻击者可乘之机。
• 内存拷贝：memcpy，std::memcpy。如果你把一段包含指针的数据拷贝到栈上，而这段数据本身被攻击者篡改过，那么栈上的指针就失效了。
• 异常处理：C++ 的异常机制依赖于栈回滚和异常表，这些表里也包含大量指针。如果这些指针被篡改，程序会直接崩掉，或者更糟——被劫持。

所以，我们需要一种机制，不仅仅隐藏地址，还要验证地址的合法性。

---

第三章：PAC 之剑——给指针戴手铐

这就轮到我们的主角登场了：PAC (Pointer Authentication Code，指针认证代码)。

PAC 是 ARMv8.3-A 架构引入的一项硬件特性。它的核心思想非常优雅：给指针加个签名。

想象一下，你有一张身份证。这张身份证上不仅有你的照片和名字（地址），还有一个数字指纹（认证码）。

当你把身份证交给别人时，如果别人把你的名字涂改成“李四”，而指纹对不上，那么系统就会拒绝承认你是“李四”。即使你把“李四”这个名字写在了纸上，只要没有指纹，系统就不认。

PAC 的基本原理

1. 签名生成：在编译或运行时，CPU 会根据一个密钥，对指针地址进行加密运算，生成一个签名，并把签名附加到指针的末尾。
2. 存储：这个带签名的指针被存储在内存（栈或寄存器）中。
3. 使用：当 CPU 读取这个指针时，它会自动提取出原始地址和签名。
4. 验证：CPU 用相同的密钥重新计算签名，并与存储的签名进行比对。如果匹配，指针有效；如果不匹配，触发异常。

这就好比你给指针戴上了一个“魔术贴手铐”。只有持有正确密钥（上下文）的人才能解开它。一旦攻击者试图通过溢出修改指针，手铐就会崩断，CPU 会立刻发现：“嘿，这家伙的手铐断了！”

---

第四章：汇编实战——如何“啪”地一声锁住栈

为了理解 PAC 如何工作，我们不能只看 C++ 代码，必须深入到汇编层面。毕竟，硬件特性是在指令集层面实现的。

在 ARM64 架构下，PAC 主要通过两条指令来完成栈指针的签名和验证。我们假设使用的是 SP Key（栈指针认证）。

1. 保护栈：paciasp 和 autiasp

当一个函数被调用时，我们需要保护栈帧。我们需要告诉 CPU：“嘿，这个栈帧里的返回地址很珍贵，给我签个名！”

my_function:
    paciasp    ; [关键指令] 将 X30 (LR) 的签名附加到 SP 指针上
               ; 结果：SP 指针现在变成了一个“签名指针”

    ; 这里是函数体，我们可以安全地使用栈了
    ; ... 假设发生了一些事情，比如局部变量溢出 ...

    ; 函数返回前，我们需要验证 SP 指针
    autiasp    ; [关键指令] 验证 SP 指针上的签名
               ; 如果签名无效，CPU 会触发 PAC 异常，程序直接 Crash

    ret        ; 如果验证通过，正常返回

详细解读：

• paciasp (PAuth Insert Address Signed with Stack Pointer)：它的全称是“用栈指针插入已签名的地址”。

  • 它读取当前的 x30 寄存器（链接寄存器，里面存着返回地址）。
  • 它读取当前的 sp 寄存器（栈指针）作为密钥/上下文。
  • 它生成一个签名，并将这个签名附加到 x30 的末尾。
  • 最后，它把修改后的 x30 存回 sp 指向的内存位置。
  • 注意：paciasp 通常配合 stp 指令使用，比如 stp x30, x29, [sp, #-16]!; paciasp。这样做的目的是把签名后的返回地址直接压入栈中。

• autiasp (PAuth Authenticate Address Signed with Stack Pointer)：

  • 这是 paciasp 的逆操作。
  • 它从栈上读取指针。
  • 它提取出原始地址和签名。
  • 它使用 sp 作为密钥进行验证。
  • 如果验证失败，CPU 会触发 PACIABSP 异常（具体异常号取决于实现，通常是 0x1E）。
  • 如果验证成功，它将签名剥离，只留下干净的原始地址，存入 x30。
  • 然后执行 ret x30。

2. 通用指针：pacia 和 autia

除了栈指针，C++ 中还有大量的普通指针（指向堆、指向数据段）。ARM64 也支持给这些指针签名。

• pacia x0, x1：将 x0 的签名附加到 x1（上下文寄存器）。
• autia x0, x1：验证 x0，使用 x1 作为上下文。

这在处理函数指针时非常有用。例如，你有一个回调函数 void (*callback)(int)。你可以用 pacia 给它签名，存起来。当调用时，用 autia 验证。如果指针被溢出修改了，验证失败。

3. 签名的“生命周期”

这里有一个非常有趣的细节。PAC 签名通常与 栈指针 的值绑定。

当函数返回时，ret 指令会恢复 sp 指针。此时，栈帧销毁，签名也就随之销毁了。这确保了栈上的指针只能在这个栈帧的生命周期内有效，出了这个函数，栈指针变了，签名也就失效了（除非你用了其他密钥机制）。这大大增加了攻击难度。

---

第五章：C++ 的拥抱——让编译器帮你干活

如果你每次都要手写汇编，那 C++ 的开发效率就太低了。而且，手写汇编很容易出错（比如忘了写 paciasp）。

幸运的是，现代编译器（GCC 和 Clang）已经完全支持 PAC，并且可以通过简单的编译选项自动集成到你的代码中。

1. 编译器标志

要在你的 ARM64 程序上启用 PAC，你只需要在编译时加上 -mbranch-protection=pac-ret 标志。

# 编译你的 C++ 程序
g++ -O2 -mbranch-protection=pac-ret main.cpp -o my_app

• pac-ret：这是最常用的模式。它会在函数返回时验证栈指针。这是防御 ROP 攻击的最主要手段。

2. C++ 属性

你还可以在代码层面使用 GCC/Clang 的属性来强制对特定函数进行保护。

// 强制对函数进行栈指针认证
__attribute__((pac_ret)) void secure_function() {
    // 这里的栈帧会被自动保护
    int x = 10;
    // ...
}

// 强制对函数指针参数进行认证
void callback_handler(void (*func)(int)) __attribute__((pac_ret("a"))); 
// 注意：这里比较高级，涉及 Key 选择，后面细说。

3. 代码示例：C++ 中的 PAC

让我们看一个完整的 C++ 示例，展示 PAC 如何保护我们的代码。

#include <iostream>
#include <cstring>

// 模拟一个可以被溢出的函数
void vulnerable_function(char* buffer, int size) {
    // 假设这里没有检查 size，导致缓冲区溢出
    // 攻击者可以在这里写入超过 buffer 大小的数据
    std::strncpy(buffer, "Hello, World!", size);

    // 如果我们启用了 PAC，返回地址已经被签名了
    // 即使攻击者试图覆盖返回地址，CPU 也会发现签名不匹配
}

// 正常的函数
void safe_function() {
    char stack_buffer[16];
    vulnerable_function(stack_buffer, sizeof(stack_buffer));
}

int main() {
    std::cout << "Program starting..." << std::endl;

    // 正常调用
    safe_function();

    std::cout << "Program ended successfully." << std::endl;
    return 0;
}

发生了什么？

1. 当 vulnerable_function 被调用时，编译器生成的汇编代码会包含 paciasp。
2. 返回地址被签名并存入栈中。
3. vulnerable_function 执行 strncpy。
4. 攻击者试图通过输入超过 16 字节的数据来覆盖返回地址。
5. 攻击者成功覆盖了返回地址的原始值，但他无法正确伪造签名。
6. 当 vulnerable_function 返回时，CPU 执行 autiasp。
7. 验证失败！CPU 触发 PACIABSP 异常，程序终止（通常是 SIGILL 或 SIGSEGV）。

输出结果：

Program starting...
Segmentation fault (core dumped)

等等，这看起来像是崩溃，但这正是我们想要的！这是一个受控的崩溃。相比于攻击者成功执行 system("/bin/sh")，这个崩溃是微不足道的，而且它阻止了攻击者。

---

第六章：进阶玩法——PACIBSP 与 Key 选择

PAC 并不是只有一种玩法。ARM 架构非常强大，提供了多种配置来适应不同的安全需求。

1. PACIBSP：分支时的栈指针验证

pacibsp (Authenticate Branch Signed with Stack Pointer) 是一个更激进的验证机制。

通常，PAC 在 ret 时验证。但攻击者可能会在函数中间修改栈指针，然后跳转。

pacibsp 允许你在执行 bl（分支链接）指令之前，验证栈指针是否被篡改。这相当于在函数入口处就上了一道锁。

pacibsp    ; 验证栈指针
bl        ; 调用子函数

如果栈指针在调用过程中被修改了，pacibsp 会触发异常。

2. Keys（密钥）：K0, K1, K2, K3

PAC 使用 4 个不同的密钥来生成签名。这给了我们极大的灵活性。

• K0 (Key0)：通常是固定的，用于内核模式。
• K1 (Key1)：用户模式，默认用于栈指针认证。
• K2 (Key2)：用于分支链接验证。
• K3 (Key3)：保留给操作系统使用。

在 C++ 中，你可以通过编译选项指定使用哪个 Key。

# 使用 Key2 进行分支验证
g++ -mbranch-protection=pac-ret+leaf -mbranch-protection=bti-key2 ...

3. Context（上下文）

PAC 的验证依赖于上下文。对于栈指针，上下文就是栈指针本身。但对于普通指针，我们需要指定上下文。

在 C++ 中，std::function 的内部实现涉及大量指针。通过正确配置 PAC 的上下文，我们可以确保 std::function 调用时，其内部持有的函数指针是有效的。

---

第七章：防御场景——C++ 中的具体应用

PAC 到底能防住哪些 C++ 特有的攻击？

1. 虚函数表劫持

在 C++ 中，多态是通过虚函数表实现的。虚函数表是一个指针数组。

如果攻击者通过堆溢出修改了虚函数表指针，那么当对象调用虚函数时，程序会跳转到错误的地址。

如果开启了 PAC，并且对对象的虚函数表指针进行了保护，攻击者修改指针后，验证将失败。

2. 异常处理劫持

C++ 的异常处理机制依赖于栈展开。在栈展开过程中，会执行一系列的清理代码，这些代码也包含返回地址。

如果攻击者通过异常抛出溢出栈帧，篡改了这些返回地址，程序可能会跳转到恶意代码。

PAC 确保了栈帧在展开过程中的完整性。

3. 函数指针数组

很多库（如网络库、插件系统）使用函数指针数组来分发任务。

typedef void (*handler_t)(int);

void handler_a(int x) { ... }
void handler_b(int x) { ... }

handler_t handlers[] = { handler_a, handler_b };

void dispatch(int id) {
    handlers[id](id); // 如果 id 被篡改，会调用错误的函数
}

如果开启了 PAC，攻击者可以通过溢出修改 handlers 数组的内容。当 dispatch 调用时，handlers[id] 返回的指针会被验证。如果签名不对，程序就挂了。

---

第八章：陷阱与部署——不要在真空中飞行

虽然 PAC 很强大，但作为一个资深专家，我必须告诉你，部署它不是没有代价的。

1. 兼容性地狱

PAC 是 ARMv8.3-A 及以上架构的特性。

• 如果你的程序运行在旧款 ARM 设备（比如早期的树莓派 Zero 或某些嵌入式芯片）上，硬件不支持 PAC，那么编译器可能会发出警告或错误。
• 你需要使用条件编译（#ifdef __aarch64__）或者链接器脚本（--fix-cortex-a53-843419 这种补丁不适用于 PAC，但类似的兼容性处理是需要的）来处理。

2. 性能开销

PAC 操作虽然只是简单的加密运算，但它们确实需要时间。

• paciasp/autiasp：大约需要 1-2 个 CPU 周期。
• 对于性能敏感的代码（如游戏循环、高频交易），这可能会有一点影响。
• 但是，相比于 ROP 攻击带来的系统崩溃或数据泄露，这点性能损失是值得的。

3. ABI 变更

开启 PAC 后，程序的二进制接口（ABI）发生了变化。栈上存储的数据格式变了（多了签名）。

• 这意味着你不能在开启了 PAC 的程序和没开启的程序之间进行混合调用（除非你通过特定的约定，比如 __attribute__((pcs_"a")) 来指定 PAC 模式）。
• 如果你使用 C 语言编写库，确保所有调用者都开启了 PAC。

---

第九章：总结与展望

好了，各位，我们今天的讲座接近尾声了。

回顾一下：

1. 敌人：ROP 攻击利用栈上的返回地址，通过拼接已有的代码片段来执行恶意操作。
2. 弱点：C++ 的指针是裸露的，容易被溢出修改。
3. 武器：PAC（指针认证）给指针加了指纹，硬件在每次使用前自动验证指纹。
4. 工具：使用编译器标志 -mbranch-protection=pac-ret，或者手写汇编指令 paciasp/autiasp。
5. 效果：一旦指针被篡改，程序立即崩溃，攻击者无法执行任意代码。

PAC 技术代表了现代软件防御的一个新高度。它不再是单纯地“隐藏”数据，而是“证明”数据的完整性。它将安全责任从操作系统/编译器转移到了硬件层面，使得防御更加坚固。

对于 C++ 开发者来说，这不仅仅是一个技术选项，更是一种态度。它提醒我们：在这个充满漏洞的世界里，我们要学会给我们的数据上锁。

希望今天的讲座能让你对 C++ 指针安全有一个全新的认识。下次当你写下一个函数指针，或者在栈上分配内存时，记得想一想那个“魔术贴手铐”。

谢谢大家！如果有问题，欢迎提问。