对CFG漏洞缓解机制的分析研究

控制流保护(CFG)是Windows的一种安全机制，其目的是通过检查间接调用的目标地址是否是有效的函数来减轻执行流的重定向，我们可以用这个例子作分析。

0x01 CFG是怎样工作的

通过这个例子，我们用MSVC编译器编译一个exe文件，看看在调用main()之前生成和执行了什么代码：

函数scrt_get_dyn_tls_init_callback得到一个指向TLS回调表的指针，以调用第一个条目，回调的函数受到CFG的保护，因此编译器在执行ESI中的目标地址之前添加代码以检查函数地址是否有效。

随后执行：

retn可以绕过，为什么？ 这样程序就可以在不支持CFG的旧操作系统版本中运行 。 在支持它的系统中 ，

_guard_check_icall_nop地址会被NT DLL中的Ldrp验证用户调用目标替换：

0x02 Bitmap简介

对于CFG，他们在Load Config目录中的PE中添加了一堆新字段 ： Guard CF Check 函 数 指 针 ， 该 指 针 指向guard_check_icall_ptr，是要替换的函数地址和Guard CF函数表，该表包含所有要设置为有效目标的函数的RVA，在加载PE时创建的Bitmap中。

验证用户调用目标的Ldrp从该第一指令中的LdrSystemDllInit块+0xb0获取Bitmap的地址。Bitmap包含整个过程中每16个字节的“状态”， 当加载PE时，表中的RVAs被转换为偏移量， 然后相应地设置该偏移量处的状态。

0x03 传送 Bitmap

我的想法是使用Guard CFFunction表填充具有选定状态的Bitmap，并在其中重新生成我们的代码，然后在入口点将其复制到Bitmap中并执行它。由于 Alex Ionescu 在WindowsInternals中的研究，我能够找出一些以前的文档：

假设我们代码中的第一个字节是0x10(010000b)，我们从Bitmap传输代码的区域从0x402000(RVA：0x2000)开始，为了清晰起见，我们将使用相同的区域来处理假RVA。要生成 0x10，我们只需要表中的1个条目：0x2020，跳过前32个字节，使状态设置为0000b，0x2020将下一个状态设置为01b，Bitmap变为010000b。现在要得到状态11b，假设我们想要字节0x1D(011101b)，我们使用未对齐的RVA，表将变成：0x2000(设置为01b)， 0x2012(设置为11b)，0x2020(设置为01b)。

要获得10b，我们需要使用带有元数据的特殊类型的 RVA，但很简单，我们将一个字节附加到用于生成10b的 RVA 中 。

元数据是一个标 志： IMAGE_GUARD_FLAG_FID_SUPPRESSED (1) 或

IMAGE_GUARD_FLAG_EXPORT_SUPPRESSED（2）。所以我们说要生成0x86(10000110b)，使用：0x2000与0x2(设置为10b)，0x2010(设置为01b)，0x2030与0x2(设置为10b)。

0x04 Bitmap 转换

我们让加载程序将0DEADH替换为LDRP验证用户调用目标的地址，从中可以得到Bitmap的地址，我们计算Bitmap(0x402000)中区域的偏移量，并从它复制再生代码。

0x05分析总结

那么，当检测到无效地址时会发生什么呢？ 程序被终止了。 因为大多数改变PE文件的工具或代码不支持CFG：更改以在其他地方执行代码的任何地址，都必须在表中。这会杀死许多病毒改变入口点地址，或使用入口点Fuzzing(EPO)技术的效果。 但是，如果在PE中禁用CFG，可以用自己的地址替换Guard CFCheck函数指针，以获得EPO。