Nytro Posted August 7, 2016 Report Posted August 7, 2016 Windows 10 x86/wow64 Userland heap Published July 5, 2016 | By Corelan Team (corelanc0d3r) Introduction Hi all, Over the course of the past few weeks ago, I received a number of "emergency" calls from some relatives, asking me to look at their computer because "things were broken", "things looked different" and "I think my computer got hacked". I quickly realized that their computers got upgraded to Windows 10. We could have a lengthy discussion about the strategy to force upgrades onto people, but in any case it is clear that Windows 10 is gaining market share. This also means that it has become a Windows version that is relevant enough to investigate. In this post, I have gathered some notes on how the userland heap manager behaves for 32bit processes in Windows 10. The main focus of my investigation is to document the similarities and differences with Windows 7, and hopefully present some ideas on how to manipulate the heap to increase predictability of its behavior. More specifically, aside from documenting behavior, I am particularly interested in getting answers to the following questions: How does the back-end allocator behave? What does it take to activate the LFH? What are the differences in terms of LFH behavior between Win7 and Win10, if any? What options do we have to create a specific heap layout that involves certain objects to be adjacent in memory? (objects of the same size, objects of different sizes) Can we perform a "reliable" and precise heap spray? As I am a terrible reverse engineer, it’s worth noting that the notes below are merely a transcript of my observations, and not backed by disassembling/decompiling/reverse engineering ntdll.dll. Furthermore, as the number of tests were limited (far below what would be needed to provide some level of statistical certainty), I am not 100% sure that my descriptions can be considered a true representation of reality. In any case, I hope the notes will inspire people to do more tests, to perform reverse engineering on some of the heap management related code, and share more details on how things were implemented. This post assumes that you already have experience with the Windows 7 heap and its front-end and back-end allocators, and that you understand the output of various !heap commands. In my test applications, I’ll be using the default process heap. It would be fair to assume that the notes below apply to all windows heaps and applications that rely on the windows heap management system. Throughout this post, I will use the following terminology: chunk: a contiguous piece of memory block: size unit, referring to 8 bytes of memory. (Don’t be confused when you see the word "block" in WinDBG output. WinDBG uses the term "block" to reference a chunk. I am using different terminology. virtualallocdblock: a chunk that was allocated through RtlAllocateHeap, but is larger than the VirtualMemoryTHreshold (and thus is not stored inside a segment, but rather as a separate chunk in memory), and managed through the VirtualAllocdBlocks list. (offset 0x9c in the heap header) segment: the heap management unit, managed by a heap, used to allocate & manage chunks. The segment list is managed inside the heap header (offset 0xa4) SubSegment: the LFH management unit used to manage LFH chunks Articol complet: https://www.corelan.be/index.php/2016/07/05/windows-10-x86wow64-userland-heap/ Quote
