Exploit 编写系列教程第11篇：堆喷射技术揭秘(下).docVIP

Exploit编写系列教程第十一篇：堆喷射技术揭秘(下) 【作者】：Peter Van Eeckhoutte 【译者】：hellok Heaplib Cache Plunger技术 – oleaut32.dll 正如Alexander Sotirov 在上文中说的，申请字符串（通过SysAllocString）不总是从系统堆里面申请的，而是通常被一个oleaut32中的堆管理引擎来处理。 这个引擎管理内存，以方便快速分配/再分配。还记得我们前面看到的堆栈跟踪吗？ （要做到这一点，需要满足几个条件，但这些条件都不）这些指针指向在堆中的任何位置，当一个新的分配情况，缓存系统会看它是否有一大块所要求的大小，可以直接返回。 这将提高性能，并在一定程度上也阻止了碎片。 32767 “bin” 在缓存表里可以保存堆块的数值。有4种“bin” : Bin Size of blocks this bin can hold 0 1 to 32 bytes 1 33 to 64 bytes 2 65 to 256 bytes 3 257 to 32768 bytes 每一个bin可以保存6个指针。 理想的情况下，做堆喷雾时，我们要确保我们的分配是由系统堆处理。通过这种方式，基于堆的可预测性的特点，连续申请会导致在同一内存地点的连续内存空间。缓存管理器返回的地址可以在堆里面的任何地方，所以地址将是不可靠的。 由于缓存中每个bin只能容纳6个地址，mr. Sotirov提出了“plunger”的技术，其刷新缓存中的所有块，并让他们空下来。如果缓存中没有块，缓存不能分配任何块还给你，所以确保你的内存申请使用的是系统堆，而不是oleaut32中的堆。这将增加获得连续内存块的可预见性。 为了做到这一点，因为他在他的论文中解释说，他只是试图申请缓存列表中的6块（1和32之间的大小的内存块申请6块，6块大小33和64之间，并为每个bin依此类推，如上表）。这样一来，他确保了缓存是空的。“刷新”后发生的分配，将由系统堆处理。 垃圾回收（Garbage Collector） 如果我们要提高堆的布局，我们也需要能够调用垃圾收集器，当我们需要它（而不是等待它运行）。幸运的是，在Internet Explorer中的JavaScript引擎暴露了CollectGarbage（）函数，heaplib来调用它。 使用分配大小大于32676字节在堆喷雾时，你甚至可能不会需要担心调用gc（）函数。 情况下重新分配一个特定的缓存块，您可能需要调用，以确保您重新分配正确的块。 分配和碎片整理Allocations Defragmentation） 结合“plunger”技术，我们可以在任意时刻根据我们的需求调用GC，申请给定大小的内存块，进一步，可以尝试整理堆。通过继续分配我们所需要的确切大小的块，堆布局中的所有可能的孔将被填补。一旦我们打破了碎片，分配将是连续的。 他们的实现在下面2个文件中： lib/rex/exploitation/heaplib.js.b64 lib/rex/exploitation/heaplib.rb 第二个就是简单的加载/解码 base64编码了的javascript库（heaplib.js.b64），并且添加了一些混淆。 如果逆向查看javascript代码，只需简单的base64解码下就可以。这里，我们使用linux环境下的base64命令来： base64 -d heaplib.js.b64 heaplib.js 在heaplib中，申请是下面这个函数来实现的： heapLtotype.allocOleaut32 = function(arg, tag) { var size; // Calculate the allocation size if (typeof arg == string || arg instanceof String) size = 4 + arg.length*2 + 2; // len + string data + null terminator else size = arg; // Make sure that the size is valid if ((size 0xf) != 0) throw Allocation size + size + must be a multiple of 16; // Create an array for this tag if doesnt already exist if (this.mem[tag] === undefi