CFG是微软提供的运行时控制流完整性保护机制，专门防范virtual call、function pointer call和indirect jmp被劫持，通过校验目标地址是否为合法函数入口来实现防护。
CFG 是什么，它到底防什么
Control Flow Guard（CFG）是 MSVC 提供的运行时控制流完整性保护机制，主要防范 virtual call、function pointer call 和 indirect jmp 这三类间接跳转被劫持——比如攻击者覆盖虚表指针或函数指针后跳转到 gadget 或 shellcode。
它不防栈溢出、堆喷、UAF，也不拦 ret 指令本身（那是 /GS 或 Shadow Stack 的事），只校验「目标地址是不是合法函数入口」。
/guard:cf 编译开关必须全程开启
仅在链接器加 /guard:cf 不够，编译器也得参与：每个源文件需用 /guard:cf 编译，否则生成的 CFG 表不全，运行时校验会漏掉未标记的函数。
- VS 项目里要同时勾选「启用控制流防护」（对应编译器 + 链接器两处）
- 手动调 cl.exe 时，不能只给 link.exe 加
/guard:cf，cl.exe 也得带/guard:cf - 第三方静态库若没开 CFG，链接后整个模块 CFG 失效——MSVC 不会报错，但
__guard_check_icall_fptr查不到那些函数地址
CFG 对虚函数和函数指针的校验逻辑
MSVC 在每次间接调用前插入 __guard_check_icall_fptr 调用，该函数查一张全局只读的位图（CFG bitmap），判断目标地址是否落在已知函数范围内，并且对齐到函数起始（不是任意偏移）。
立即学习“C++免费学习笔记（深入）”；
常见失效场景：
- 手动构造
vtable或 patch 虚表：新填的函数地址若不在 CFG bitmap 中，直接触发异常（0xC0000409 STATUS_STACK_BUFFER_OVERRUN） - 把函数指针转成
void*再加偏移跳转：CFG 拒绝非函数起始地址，哪怕偏移为 0 也不行（除非是 naked 函数且显式标注__declspec(guard(nocf))） - 使用
SetThreadContext修改 RIP 到非函数头：不经过__guard_check_icall_fptr，但 CFG 不管这个——它只守 indirect call/jmp
绕过 CFG 的现实路径和应对暗示
CFG 本身不加密、不混淆，位图地址可泄露（如通过信息泄漏漏洞），攻击者能 dump 出所有合法函数地址。所以它防不住有任意地址读能力的攻击者。
真正增加利用门槛的是组合防御：
- 必须配合
/DYNAMICBASE（ASLR），否则 CFG bitmap 地址固定，一泄全泄 - 建议启用
/CETREPORT（如果目标系统支持 CET），让硬件级间接分支验证补上 CFG 的软件层盲区 - 慎用
__declspec(guard(nocf))：它会让函数从 CFG bitmap 中剔除，等于主动开后门，只应在极少数必须动态生成代码的场景下用
CFG 不是银弹，但它确实抬高了常见 exploit chain 的成本——尤其是那些依赖覆盖虚表或回调函数指针的漏洞利用。一旦你发现 crash 在 __guard_check_icall_fptr，大概率说明控制流已被篡改，而不是程序逻辑错误。
