一、虚函数表劫持：C++世界里最经典的攻击手法
说实话，虚函数表劫持这个技术，我最早是在做游戏外挂分析时接触到的。那时候我还年轻，看到别人能通过修改几个字节就改变程序行为，觉得特别神奇。后来自己做了系统安全相关的工作，才真正理解这背后的原理有多深。
虚函数表劫持，说白了就是攻击者篡改对象的虚函数表指针（vptr），让它指向一个伪造的虚函数表。这样一来，原本调用的是合法函数，实际执行的却是恶意代码。
你想想看，C++的多态机制依赖于运行时查找虚函数表。这个查找过程本身没问题，问题在于——虚函数表指针是存储在对象内存中的。如果攻击者能控制这块内存，那整个多态机制就形同虚设。
1.1 攻击的基本流程
攻击步骤其实不复杂，我拆解给你看：
- 定位vptr：找到目标对象在内存中的位置
- 构造伪造虚表：在可控内存区域创建一个假的虚函数表
- 覆写vptr：把对象头部的vptr指向伪造虚表
- 触发虚函数调用：程序调用虚函数时，就会执行攻击者指定的代码
核心要点：虚函数表劫持的本质是控制流劫持（Control Flow Hijacking）。攻击者不需要修改代码，只需要修改数据——也就是那个指向虚函数表的指针。
1.2 一个简单的攻击示例
来看个例子。假设我们有这样一个类：
class Base {
public:
virtual void safeFunc() {
std::cout << "这是安全函数" << std::endl;
}
virtual void secretFunc() {
std::cout << "这是机密函数" << std::endl;
}
};
class Derived : public Base {
public:
void safeFunc() override {
std::cout << "派生类的安全函数" << std::endl;
}
};正常情况下，通过基类指针调用虚函数，会走虚函数表查找。但如果攻击者能覆写对象的vptr，让它指向一个伪造的虚表——伪造虚表中safeFunc对应的槽位指向secretFunc的地址——那调用safeFunc时，实际执行的就是secretFunc。
注意：这只是一个演示原理的简化例子。实际攻击中，攻击者会让vptr指向包含shellcode地址的伪造虚表，实现任意代码执行。
二、vptr覆写：攻击者是怎么做到的？
我在项目中遇到过好几次类似的安全漏洞。最常见的vptr覆写途径有这么几种：
2.1 缓冲区溢出
这是最经典的方式。如果对象前面有一个缓冲区，而代码没有做边界检查，攻击者就可以通过溢出覆盖掉紧随其后的vptr。
struct Data {
char buffer[64]; // 缓冲区
Base* obj; // 指向多态对象的指针
};
void vulnerableFunc(Data* d, const char* input) {
strcpy(d->buffer, input); // 没有长度检查！
d->obj->safeFunc(); // 如果input覆盖了obj的vptr...
}嗯，这里要注意。strcpy不会检查目标缓冲区大小。如果input超过64字节，就会覆盖后面的内存。如果精心构造input内容，就能把obj指向的对象的vptr改成任意值。
2.2 类型混淆（Type Confusion）
这个稍微隐蔽一些。当程序错误地把一个对象当作另一种类型来使用时，就可能出现vptr被错误解释的情况。
我记得有一次做代码审计，发现一个C风格的强制转换：
void* ptr = getSomeObject();
Base* base = (Base*)ptr; // 危险！如果ptr指向的不是Base或其派生类对象
base->safeFunc(); // vptr可能指向完全错误的位置这种代码在遗留系统里特别常见。开发者图省事，用void*传递对象，然后强制转换回来。一旦类型对不上，vptr就乱套了。
2.3 释放后使用（Use-After-Free）
对象被释放后，vptr指向的内存可能被重新分配给其他用途。如果攻击者能控制这块内存的内容，就能伪造vptr。
我的建议：在涉及安全敏感的场景中，对象释放后最好把指针置空。虽然不能完全防御UAF，但至少能避免一些低级错误。
三、安全防护措施：我们怎么防？
讲完了攻击，咱们聊聊防御。说实话，完全杜绝虚函数表劫持很难，但我们可以大幅提高攻击门槛。
3.1 CFI（控制流完整性）
CFI的核心思想很简单：在程序运行过程中，检查间接跳转的目标地址是否在合法范围内。虚函数调用本质上就是一种间接跳转，所以CFI天然适用于防护虚函数表劫持。
CFI有两种实现方式：
| 类型 | 原理 | 性能开销 | 安全性 |
|---|---|---|---|
| 前向CFI | 检查调用目标是否在合法函数集合中 | 较低（约5-10%） | 中等 |
| 后向CFI | 检查返回地址是否被篡改 | 较低 | 较高 |
| 细粒度CFI | 每个间接调用都有精确的目标集合 | 较高（约20-30%） | 高 |
我个人习惯在性能敏感的场景使用前向CFI，安全优先的场景用细粒度CFI。不过说实话，细粒度CFI的开销确实不小，需要权衡。
3.2 VTGuard
VTGuard是微软在Visual Studio中引入的一种防护机制。它的原理是在每个虚函数表中嵌入一个"守卫值"（guard value），这个值在对象构造时被复制到对象中。每次虚函数调用前，检查虚表中的守卫值是否与对象中存储的一致。
说白了，VTGuard就是在vptr和虚表之间建立了一个关联验证。如果攻击者篡改了vptr，让它指向伪造虚表，那守卫值对不上，程序就会终止。
// VTGuard的简化原理
class Base {
// 编译器生成的代码大致如下：
void* _vptr; // 虚函数表指针
uintptr_t _vtguard; // 守卫值，与虚表中的值匹配
virtual void func() {
// 调用前检查：
if (_vtguard != (*((uintptr_t*)_vptr - 1))) {
__fastfail(FAST_FAIL_VTGUARD_CHECK_FAILURE);
}
// 实际函数调用...
}
};重要：VTGuard只能防护vptr被篡改为指向伪造虚表的情况。如果攻击者修改了原始虚表的内容（比如改写函数指针），VTGuard就无能为力了。
3.3 其他实用防护措施
除了CFI和VTGuard，还有一些实践中很有效的做法：
- ASLR（地址空间布局随机化）：让攻击者难以预测虚函数表的地址。不过ASLR可以被信息泄露漏洞绕过。
- 虚表只读保护：把虚函数表放在只读内存段。这样攻击者无法修改原始虚表，只能尝试替换vptr。
- 安全编码规范：避免使用void*传递对象，减少类型转换，使用智能指针管理生命周期。
避坑指南：我曾经在一个项目中看到团队为了性能，把所有虚函数都改成非虚函数。这其实是因噎废食。正确的做法是：在需要多态的地方用虚函数，同时启用CFI或VTGuard来防护。
四、知识体系总览
下面这张图总结了虚函数表劫持攻击与防护的完整知识体系：
从这张图可以看得很清楚：攻击者通过缓冲区溢出、类型混淆或释放后使用来覆写vptr，最终实现控制流劫持。而防护措施的核心思路，就是在运行时对控制流转移进行合法性检查，阻断非法的跳转。
好了，关于虚函数表劫持攻击与防护，核心内容就这些。记住一点：没有绝对的安全，只有不断演进的安全防护。CFI和VTGuard能挡住大部分攻击，但攻击者也在不断寻找新的绕过方式。作为开发者，保持安全意识，理解底层原理，才是最好的防护。