Tapping into the potential of Memory Dump Emulation

2024-01-27T00:00:00+00:00

This post summarizes some of the work I’ve been doing for the past few months during my (few) off times. Nothing new, mostly just a structured reminder for my later self.

Introduction</h2>
`What-The-Fuzz</code></a> is one of my favorite tools, and beyond the tool itself I really enjoy the story behind the creation of the tool itself and all of the surrounding libraries` `0vercl0k</a> had to build, including kdmp-parser</code>, symbolizer</code>, leveraged yrp</a>’s underestimated bochs-based emulation library bochscpu</code>. 0vercl0k explained all of this better than I possible could, so if you haven’t read it yet, please stop reading this post now and read the blog post dedicated to WTF: Building a new snapshot fuzzer & fuzzing IDA</a>.`
`I used to use memory dump mostly as a final way to access the crashing condition and execution context of a program before its crash. Dumps are very much used for debugging, fuzzing crash analysis, and sometimes for DFIR (like with the famous - RIP? - Volatility</a> does). But to my knowledge, WTF was the first tool to use them for snapshot-based fuzzing (* if not, please shoot me a remark in the Discussion</a>).`
`Following the well-known Feynman principle that “what you cannot create, you do not understand”</a>, I wanted to see where digging into this topic will lead me. And boy wasn’t I disappointed… But first and before all, I wanted whatever my work to be Python because:`
it is the de-facto language for quick prototyping, comes with an awesome REPL and has a great ecosystem via PyPI</li> has a great capability to interact with lower level machine code</li> I know and like the language</li> </ul> So immediately, I was stopped: originally bochscpu</code> was written in Rust, kdmp-parser</code> and udmp-parser</code> in C++ and only kdmp-parser</code> had an embryo of Python bindings (many API/structures missing, no PyPI). Perfect, so I set myself to completely dive into those libs by creating Python bindings for udmp-parser</code> and bochscpu</code></li> improving the Python bindings kdmp-parser</code> originally had</a>, developed by masthoon</code> </a> </li> </ul> At the time of this article, anyone can pip install</code> any of those packages and start playing directly within the Python interpreter 3.8+ on either Windows, Linux and MacOS (since 0.1.7+) So just in order to reproduce any of the stuff mentioned below, all one would need do is: pip install udmp-parser kdmp-parser bochscpu-python </code></pre> to be fully set to follow along with the experiments below. Having the pre-requisites we can start digging (because yes, all that initial work was only to get start the intended research) by: using udmp-parser</code> to parse user-mode process dumps</li> or using kdmp-parser</code>, to parse kernel memory dumps</li> and use those information to reconstitute a workable environment (memory layout, cpu context, etc.) for bochscpu</code> to run whatever code we choose to.</li> </ul> The best parts (IMO) about all of this was that this whole setup works no matter the process and allow us to get an absolute control over the execution. We will explore each case individually, but first let’s examine a bit more the libraries at hand. Quick lib peek</h2> This part is important as none of what follows would have been possible without those libraries, it is only fair to promote them first. Bochs[1]</code>/BochsCPU[2]</code></h3> It is well-known that the Bochs emulator</a> has incredibly powerful instrumentation capabilities and is regarded as being very faithful to the x86 ABI implementation itself (including the most recent extensions). BochsCPU</code></a> by yrp</a>, on the other hand, is a Rust library that wraps the Bochs CPU code and exposes via Rust API (and C++ via FFI) all the instrumentation points (context switches, interrupts, exceptions, etc) that Bochs does. This makes it a useful tool for tasks such as developing code any X86 mode</a>, dealing with very old, mission-critical software, and assisting in reversing/vulnerability research tasks. And that’s an amazing environment since Bochs is extremely faithful to what the x86 cpu actually executes, it will be merciless should you fail to prepare the CPU state adequately (missing flags when setting long mode, forgot to reset a trap flag, etc.). Even though that could seem tedious, especially if compared to unicorn/qemu</code> for instance, that abstracts everything beforehand to the dev. But I believe such behavior by forcing to read carefully the Intel manuals to have the expected behavior, it only makes you know X86 CPU better. udmp-parser[3]</code>/kdmp-parser[4]</code></h3> udmp-parser</code> and kdmp-parser</code> are both cross-platform C++ parser library written by 0vercl0k</a> for Windows memory dumps, respectively for user-mode (using .dump /m</code> in WinDbg) and kernel-mode (.dump /f|/ka</code> in WinDbg) dumps. And cherry on top, both come with Python3 bindings, allowing for quick prototyping. Windows Kernel-mode emulation</h2> Armed with those libraries, running the emulator from a Windows kernel dump is now “relatively” simple (as opposed to user-mode, we’ll detail why in the next part) because the dump is nothing more but a snapshot of the OS state at a given time. First, always take a solid dump</h3> First from a KdNet session, you can easily create a dump at an interesting point. When looking for interesting attack surface, I like to use my own IRP monitor tool</a> #ShamelessSelfPromo; but for our example really anything would do, like the following: kd> bp /w "@$curprocess.Name == \"explorer.exe\"" nt!NtDeviceIoControlFile [...] Breakpoint 0 hit nt!NtDeviceIoControlFile: fffff807`4f7a4670 4883ec68 sub rsp,68h </code></pre> One way to get the dump would be using .dump</code> command as such kd> .dump /ka c:\temp\ActiveKDump.dmp </code></pre> But a better way would be to use the yrp’s bdump.js</code></a> script kd> .scriptload "C:\bdump\bdump.js" [...] kd> !bdump_active_kernel "C:\\Temp\\ActiveKDump.dmp" [...] [bdump] saving mem, get a coffee or have a smoke, this will probably take around 10-15 minutes... [...] [bdump] Dump successfully written [bdump] done! </code></pre> Build the BochsCPU session</h3> Parsing the dump with kdmp_parser.KernelDumpParser</code> is as simple as it gets so let’s leave it to that. For BochsCPU to run it’s critical to have a PF handler callback, which can be done as a simple on-demand basis: full memory dumps can be several gigabytes in size, so it seems unreasonable to map it all on host, especially since when we probably are going to need a fraction of that. This ended up being relatively elegant and simple: dmp = kdmp_parser.KernelDumpParser(pathlib.Path("/path/to/dumpfile.dmp")) def missing_page_cb(pa: int): gpa = bochscpu.memory.align_address_to_page(pa) if gpa in dmp.pages: # do we already have the page in the dump? # then create & copy the page content, resume execution hva = bochscpu.memory.allocate_host_page() page = dmp.read_physical_page(gpa) bochscpu.memory.page_insert(gpa, hva) bochscpu.memory.phy_write(gpa, page) sess = bochscpu.Session() sess.missing_page_handler = missing_page_cb </code></pre> This gives us a first chance to address missing pages, whereas the PageFault exception triggered by the CPU (i.e PageFault</code> -> BX_PF_EXCEPTION</code> (14) ) will give us a second chance to analyze the page fault, as the error code</code> will be populated, we can check the reason of the fault using the Intel 3A - 4.7 section</a> of the Intel manuals. Next, a bochscpu.State</code> must be given to the CPU indicating the context from which to start including the (extended) CR, GPR, flag registers and segment registers. Note that several helpers can be found in bochscpu.cpu</code> to slightly speed up that process. regs = json.loads(pathlib.Path("/path/to/regs.json").read_text()) state = bochscpu.State() bochscpu.cpu.set_long_mode(state) [...] state.cr3 = int(regs["cr3"], 16) state.cr0 = int(regs["cr0"], 16) state.cr4 = int(regs["cr4"], 16) [...] state.rax = int(regs["rax"], 16) state.rbx = int(regs["rbx"], 16) state.rcx = int(regs["rcx"], 16) state.rdx = int(regs["rdx"], 16) [... snip for brievety] sess.cpu.state = state </code></pre> Last (but technically optionally), define the Bochs callbacks on the plethora of hookable events: def before_execution_cb(sess: bochscpu.Session, cpu_id: int, _: int): state = sess.cpu.state logging.info(f"Executing RIP={state.rip:#016x} on {cpu_id=}") hook = bochscpu.Hook() hook.before_execution = before_execution_cb hooks = [hook,] </code></pre> And finally kick things off with a simple call sess.run(hooks) sess.stop() </code></pre> $ python kdump_runner.py Executing RIP=0xfffff80720a9d4c0 on cpu_id=0 Executing RIP=0xfffff80720a9d4c4 on cpu_id=0 Executing RIP=0xfffff80720a9d4cb on cpu_id=0 Executing RIP=0xfffff80720a9d4d0 on cpu_id=0 Executing RIP=0xfffff80720a9d4d4 on cpu_id=0 Executing RIP=0xfffff80720a9d4dc on cpu_id=0 Executing RIP=0xfffff80720a9d4e1 on cpu_id=0 Executing RIP=0xfffff80720a9d4e8 on cpu_id=0 Executing RIP=0xfffff80720a9d4ec on cpu_id=0 [...] </code></pre> For a complete and more detailed example, the reader can refer to the example in the bochscpu-python</code> repository: examples/long_mode_emulate_windows_kdump.py</a> Windows User-mode emulation</h2> There are way more than one way of snapshotting a process on Windows (like WinDbg, Task Manager, procdump</code>, processhacker</code>, etc.) so I will skip and assume you have a snapshot ready. Emulating usermode code on BochsCPU turned out to be slightly more tricky than kernel mode: the kernel dump includes an almost complete OS snapshot include all the kernel sections required by the MMU to function properly and all what was needed was to map those pages to Bochs whenever they were needed. A user-mode dump on Windows does not include any of those information but only that related to the usermode process itself - which, despite being already a lot of information, is insufficient to simply re-use what was done for kernel mode emulation. And we must remember that BochsCPU is only, well, the CPU: meaning it can execute anything but it needs to have everything set it up, such as the processor mode (real, protected, long), the map pages, etc. But then, if the process runs in protected/long mode, memory accesses via the MMU must also be correctly laid off so ensure the VirtualAddress → PhysicalAddress translation works. We therefore, are required to build own page table for the process. Since this process is documented</a> everywhere</a> on the Internet</a>, I will assume the reader to be familiar and skip this part by mentioning that bochscpu-python</code> provides an easy way to expedite the process of setting things up: dmp = udmp_parser.UserDumpParser() assert dmp.Parse(dmp_path) pt = bochscpu.memory.PageMapLevel4Table() pa = PA_START_ADDRESS # Collect the memory regions from the Windows dump # For each region, insert a new PT entry for _, region in dmp.Memory().items(): if region.State == MEM_FREE or region.Protect == PAGE_NOACCESS: continue start, end = region.BaseAddress, region.BaseAddress + region.RegionSize for va in range(start, end, PAGE_SIZE): flags = convert_region_protection(region.Protect) if flags < 0: break pt.insert(va, pa, flags) hva = bochscpu.memory.allocate_host_page() bochscpu.memory.page_insert(pa, hva) print(f"\bMapped {va=:#x} to {pa=:#x} with {flags=}\r", end="") pa += PAGE_SIZE # Commit all the changes, resulting in a valid PT setup for the VM for hva, gpa in pt.commit(PML4_ADDRESS): bochscpu.memory.page_insert(gpa, hva) </code></pre> A couple of other things are required: the first one is that just like for what was done for kernel dumps, we must import all registers (GPR, flags). Another thing (but related) relies in the thread selection: when the VM execution will resume, the CPU cannot work without relying on the segment registers, which are provided from its state by the values set in the CS, DS, SS segment registers. Thankfully those values can be retrieved straight from the dump: threads = dmp.Threads() tids = list(threads.keys()) tid = tids[0] # whatever teh first thread is, but TID can be hardcoded too switch_to_thread(state, threads[tid]) def switch_to_thread(state: bochscpu.State, thread: udmp_parser.Thread): # build CS _cs = bochscpu.Segment() _cs.base = 0 _cs.limit = 0xFFFF_FFFF _cs.selector = thread.Context.SegCs _cs_attr = bochscpu.cpu.SegmentFlags() _cs_attr.A = True _cs_attr.R = True _cs_attr.E = True _cs_attr.S = True _cs_attr.P = True _cs_attr.L = True _cs.attr = int(_cs_attr) state.cs = _cs # do the same for the others (obvisouly adjusting values/flags) </code></pre> Similarly not the CPU but Windows also requires the FS (for protected and long modes) and the GS registers (in long mode). Ok, now we have built everything need for the emulation to run successfully in a Windows environment. Let’s focus on what could we want to execute next… PGTFO</h3> TL;DR You can predict through emulation the values of Windows PRNG (see examples/long_mode_emulate_windows_udump.py</a>) Coincidentally as part of some research I was doing for work on ransomware, I examined the possibility of retrieving session keys used by ransomware, by snapshotting culprit ransomware processes, and generating a using memory dumps using canary files (the full article is available here</a> if interested). As thoroughly detailed in the article, investigating WANNACRY</code> revealed that it uses Windows PRNG to create the AES128 keys for each file. Which triggered the idea behind that post, which was that by using canary files to detect ransomware encryption early one, and generating a dump of the process at that point, can we retrieve all the subsequent symmetric keys (and essentially making ourselves a free decryptor). Since snapshotting the process gives us the current state of the PRNG for that process, we can now use emulation to discover the following values. A basic PoC for it would be as follow: #include <windows.h> #include <wincrypt.h> #include <stdio.h> #pragma comment(lib, "advapi32.lib") int main() { HCRYPTPROV hCryptProv; CryptAcquireContext(&hCryptProv, NULL, NULL, PROV_RSA_FULL, CRYPT_VERIFYCONTEXT); printf("PID=%lu, hProv=%p\nDump and press enter\n", GetCurrentProcessId(), (void *)hCryptProv); getchar(); // We break here and snapshot the process for (int i = 0; i < 10; i++) { BYTE randomBytes[16] = {0}; CryptGenRandom(hCryptProv, sizeof(randomBytes), randomBytes) printf("Random bytes: "); for (int i = 0; i < sizeof(randomBytes); i++) printf("%02X ", randomBytes[i]); printf("\n"); } CryptReleaseContext(hCryptProv, 0); return 0; } </code></pre> </a> Continuing our emulator from above, we can now invoke directly any function (here we’re interested in cryptbase!SystemFunction036</code>) in the dump: logging.debug(f"Resolving 'cryptbase!SystemFunction036'") fn_start = resolve_function(fn_sym) fn_end = fn_start + 0x1C # hardcode the end address of the function for now state.rcx = temp_buffer_va state.rdx = 16 state.rip = fn_start hook = bochscpu.Hook() hook.before_execution = lambda s, _: s.cpu.state.rip == fn_end and s.stop() sess.run([hook,]) </code></pre> And we can successfully dump all future values: </a> Same values, mission accomplished. Hey, but what about Linux?</h2> Well as the saying goes… </a> using lief</a> we can parse and populate the memory layout /** * For demo purpose, compiled with `-static` / #include <stdlib.h> #include <stdio.h> #include <stdint.h> #include <time.h> void generate_random_buffer(uint8_t buf, size_t sz) { for(int i=0; i<sz; i++) buf[i] = rand() & 0xff; } int main() { srand(time(NULL)); uint8_t buf[0x10] = {0}; generate_random_buffer(buf, sizeof(buf)); getchar(); // get a coredump for(int i=0; i<sizeof(buf); i++) printf("%02x ", buf[i]); puts(""); return 0; } </code></pre> Compile </a> And run </a> and unsurprisingly, same result Similarly the source of this script too was added to the examples/</code> folder of bochscpu-python</code> available here</a> so feel free to try it at home 🙂 BochsPwn (Re-)Reloaded?</h2> BochsPwn</a> (and BochsPwn-Reloaded</a>) is a project developed by j00ru</a> which leveraged Bochs instrumentation capability to detect (among other things) TOCTOU race conditions in the Windows kernel. The brilliance behind that tool can (partially) become relevant again for kernel memory dumps, by simply tracking executions and memory accesses. This can be achieved crudely by extending the kernel dump runner we had earlier, and adding a callback for linear memory accesses in bochscpu</code> as such: @dataclass class TrackedMemoryAccess: timestamp: int pc: int address: int access: bochscpu.memory.AccessType def lin_access_cb( sess: bochscpu.Session, cpu_id: int, lin: int, phy: int, len: int, memtype: int, rw: int, ): global tracked_accesses state = sess.cpu.state if lin >= MAX_USERMODE_ADDRESS: # Ignore accessed linear address as long as it stays in KM return if rw: # Ignore write access (for now) return # Track the current access cur = TrackedMemoryAccess(sess[AUX_INSN_COUNT], sess[AUX_LAST_RIP], lin, bochscpu.memory.AccessType(memtype)) logging.debug(f"{cur.pc=:#x}: {cur.address=:#x} -> {phy=:#x} {len=} {cur.access=}") # Look for previous accesses for old in tracked_accesses: # Any access to the same VA means a match if old.address == cur.address and old.access == cur.access: logging.error( f"Possible usermode {cur.access} double fetch on VA={cur.address:#x}:\n" f"1st access at {old.pc:#x} -> {old.insn(sess)}\n" f"2nd access at {cur.pc:#x} -> {cur.insn(sess)}\n" f"exec distance: {cur.timestamp - old.timestamp} insn(s)" ) raise SuspiciousCrashException tracked_accesses.append(cur) [..snip..] hook.lin_access_cb = lin_access_cb sess.run([hook,]) </code></pre> Testing with HEVD</a> Double-Fetch</a> example, immediately reveals it: ❯ python .\hevd_double_fetch.py X:\hevd_double_fetch_dump\mem.dmp X:\hevd_double_fetch_dump\regs.json INFO:Parsed KernelDumpParser(X:\hevd_double_fetch_dump\mem.dmp, CompleteMemoryDump) ERROR:Possible usermode bochscpu._bochscpu.memory.AccessType.Read double fetch on VA=0x5f0008: 1st access at 0xfffff8071fde68d6 -> mov r9, [rdi+8h] 2nd access at 0xfffff8071fde6905 -> mov r8, [rdi+8h] exec distance: 85 insn(s) ERROR:Exception raised > z:\bochscpu-fun\hevd_double_fetch.py(180)lin_access_cb() -> raise SuspiciousCrashException (Pdb) bochscpu.utils.dump_registers(sess.cpu.state) rax=0000000000000000 rbx=0000000000000000 rdx=0000000000000001 rsi=0000000000000003 rdi=00000000005f0000 rbp=ffff988c2cebae90 rsp=fffffd8650f8e880 rip=fffff8071fde6909 r8=0000000000000008 r9=000000000000004d r10=fffff8071fde5078 r11=fffffd8650f8e878 r12=0000000000000001 r13=ffff988c2d80ee00 r14=000000000000004d r15=0000000000000800 efl=00040206 [ id vip vif AC vm rf nt of df IF tf sf zf af PF cf ] cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b (Pdb) print(utils.hexdump(bochscpu.memory.virt_read(sess.cpu.state.cr3, sess.cpu.state.rdi, 0x10))) 0x0000000000000000 AA AA AA AA AA AA AA AA 10 00 00 00 00 00 00 00 ................ </code></pre> Which we can double-check with a disassembler (highlighted in magenta) </a> Final remark</h2> This article was made an attempt to structure all my notes over the last few months playing with memory dumps, and by no mean any comparison with WTF: WTF goes way further and does it better, with different emulation techniques and therefore should be used for fuzzing at scale. On the other hand having quick ways to re-create a fully working emulation context (whether user or kernel mode) from a process/memory dump with ~50 lines of Python is not without certain advantages. Anyway, as always open for feedback on the discussion feed. Until then see next time, Cheers 🍻 References</h2> Here are the links to those giants referred in the title: bochs-emu/Bochs</code> </a> </li> yrp604/bochscpu</code> </a> </li> 0vercl0k/wtf</code> </a> </li> 0vercl0k/kdmp-parser</code> </a> </li> 0vercl0k/udmp-parser</code> </a> </li> googleprojectzero/bochspwn</code> </a> </li> googleprojectzero/bochspwn-reloaded</code> </a> </li> </ol>

Section Objects as Kernel/User communication mode

2023-04-04T00:00:00+00:00

I’ve recently decided to read cover to cover some Windows Internals books, and currently reading the amazing book “What Makes It Page”</a>, it gave me some ideas to play with Section Objects</a> as they covered in great details. One thought that occurred to me was that even though a section is created from user or kernel land, its mapping can be in user-mode as much as in kernel (when called from the kernel).

Windows Section Objects</h2>

For quick reminder, a Section Object on Windows is a specific type of kernel object (of structure nt!SECTION</code></a>) that represents a block of memory that processes can share between themselves or between a process and the kernel. It can be mapped to the paging file (i.e. backed by memory) or to a file on disk, but either can be handled using the same set of API, and even though they are allocated by the Object Manager, it is one of the many jobs of the Memory Manager to handle their access (handle access, permission, mapping etc.). In usermode the high level API is kernel32!CreateFileMapping</code></a>, which after some hoops into kernelbase</code>, boils down to ntdll!NtCreateSection</code></a> </a>

The signature is as follow:

NTSTATUS
</span>NTAPI
</span>NtCreateSection </span>(
</span>    _Out_ PHANDLE </span>SectionHandle</span>,
</span>    _In_ ACCESS_MASK </span>DesiredAccess</span>,
</span>    _In_opt_ POBJECT_ATTRIBUTES </span>ObjectAttributes</span>,
</span>    _In_opt_ PLARGE_INTEGER </span>MaximumSize</span>,
</span>    _In_ ULONG </span>SectionPageProtection</span>,
</span>    _In_ ULONG </span>AllocationAttributes</span>,
</span>    _In_opt_ HANDLE FileHandle
</span>    );
</span></code></pre>
If successful, the syscall will return a section handle in SectionHandle</code>, which will refer to an instance of a nt!_SECTION</code>. Therefore the handle will be added to the handle table of the calling process, accessible from kernel and user modes unless OBJ_KERNEL_HANDLE</code> is specified in the ObjectAttributes</code>. This will be important for us in the following, because it implies that if the process terminates, so will the section object.</p>
In itself the Section Object doesn’t have a lot going on, unless it is mapped to memory. This is achieved through kernel32!MapViewOfView(Ex)</code> which again, boils down to the syscall ntdll!NtMapViewOfSection</code>, whose signature is as follow:</p>
//
</span>// Syscall entry point
</span>//
</span>NTSTATUS
</span>NTAPI
</span>NtMapViewOfSection</span>(
</span>        HANDLE </span>SectionHandle</span>,
</span>        HANDLE </span>ProcessHandle</span>,
</span>        PVOID *</span>BaseAddress</span>,
</span>        ULONG_PTR </span>ZeroBits</span>,
</span>        SIZE_T </span>CommitSize</span>,
</span>        PLARGE_INTEGER </span>SectionOffset</span>,
</span>        PSIZE_T </span>ViewSize</span>,
</span>        SECTION_INHERIT </span>InheritDisposition</span>,
</span>        ULONG </span>AllocationType</span>,
</span>        ULONG </span>Win32Protect</span>)
</span></code></pre>
Reversing this function is relatively straight forward:</p>
{
</span>  [...]
</span>  </span>if </span>( </span>NT_SUCCESS</span>(</span>MiValidateZeroBits</span>(&ZeroBits)) )
</span>  {
</span>    AccessMode = </span>KeGetCurrentThread</span>()->PreviousMode;
</span>
</span>    </span>//
</span>    </span>// Internal function to the Memory Manager to map a view of a section
</span>    </span>//
</span>    Status = </span>MiMapViewOfSectionCommon</span>(
</span>               ProcessHandle,
</span>               SectionHandle,
</span>               </span>0</span>,
</span>               BaseAddress,
</span>               ViewSize,
</span>               SectionOffset,
</span>               Win32Protect,
</span>               ZeroBits,
</span>               AccessMode,
</span>               &SectionParameter);
</span>[...]
</span></code></pre>
which makes us jump to:</p>
NTSTATUS  </span>MiMapViewOfSectionCommon</span>(
</span>        HANDLE </span>ProcessHandle</span>,
</span>        HANDLE </span>SectionHandle</span>,
</span>        ACCESS_MASK </span>DesiredAccess</span>,
</span>        PVOID </span>BaseAddress</span>,
</span>        uint64_t </span>ViewSize</span>,
</span>        uint64_t </span>SectionOffset</span>,
</span>        uint32_t </span>Win32Protect</span>,
</span>        uint8_t </span>ZeroBits</span>,
</span>        KPROCESSOR_MODE </span>AccessMode</span>,
</span>        SECTION_PARAMETER *</span>SectionParameter</span>)
</span>{
</span>    [...]
</span>    </span>//
</span>    </span>//  Get a reference to the asking process
</span>    </span>//
</span>    Status = </span>ObpReferenceObjectByHandleWithTag</span>(ProcessHandle, (DesiredAccess + </span>8</span>), ProcessType, AccessMode, '</span>MmVw</span>', &SectionParameter->ProcessObject, nullptr, nullptr);
</span>    </span>if </span>(Status >= </span>0</span>)
</span>    {
</span>        PSECTION* SectionObject = nullptr;
</span>        pSectionObject = &SectionObject;
</span>        </span>//
</span>        </span>//  Get a reference to the section
</span>        </span>//
</span>        Status = </span>ObReferenceObjectByHandle</span>(SectionHandle, &MmMakeSectionAccess[((uint64_t)SectionParameter->ProtectMaskForAccess)], MmSectionObjectType, AccessMode, pSectionObject, nullptr);
</span>        SectionParameter->SectionObject = SectionObject;
</span>        </span>if </span>(Status < </span>0</span>)
</span>        {
</span>            </span>ObfDereferenceObjectWithTag</span>(SectionParameter->ProcessObject, '</span>MmVw</span>');
</span>        }
</span>    }
</span>    [...]
</span>
</span>    </span>if </span>(AccessMode == KernelMode)
</span>    {
</span>        </span>//
</span>        </span>//  In KM, do whatever
</span>        </span>//
</span>        ViewSize_1 = ViewSize;
</span>    }
</span>    </span>else
</span>    {
</span>        PVOID* pBaseAddress_1 = BaseAddress;
</span>        </span>//
</span>        </span>//  With a request coming from UM, validate the BaseAddress is within UM bounds
</span>        </span>//
</span>        </span>if </span>(BaseAddress >= </span>0x7fffffff0000</span>)
</span>        {
</span>            pBaseAddress_1 = </span>0x7fffffff0000</span>;
</span>        }
</span>        *(int64_t*)pBaseAddress_1 = *(int64_t*)pBaseAddress_1;
</span>        ViewSize_1 = ViewSize;
</span>        uint64_t r8_2 = ViewSize_1;
</span>        </span>if </span>(ViewSize_1 >= </span>0x7fffffff0000</span>)
</span>        {
</span>            r8_2 = </span>0x7fffffff0000</span>;
</span>        }
</span>        *(int64_t*)r8_2 = *(int64_t*)r8_2;
</span>    }
</span>    SectionParameter->BaseAddress = *(int64_t*)BaseAddress;
</span>    SectionParameter->ViewSize = *(int64_t*)ViewSize_1;
</span>
</span>  [...]
</span>}
</span></code></pre>
What matters the most here would be the BaseAddress</code> argument which will hold the UM address of the mapping. Meaning that Section Objects can be used to create communication channels between kernel <-> user mode (on top of obviously user <-> user). This is particularly nice especially because it allows to control finely the permission to the area: for instance a driver could create a section as read-writable, map its own view as RW, but expose to any process as RO. As a matter of fact, this is exactly how Windows 11 decided to protect the (K)USER_SHARED_DATA</code> memory region, frequently used by kernel exploit since it’s read/writable in ring-0 at a well-known address, making it a perfect way to bypass ALSR. The protection was added in 22H1 global variable which is initialized at boot-time and mapped as RW from the kernel through the nt!MmWriteableUserSharedData</code>; however from user-mode only a read-only view is exposed to processes.  For complete details about that protection, I invite the reader to refer to Connor McGarr’s in-depth excellent blog post</a> on the subject.</p>
Section Object as a Kernel/User Communication Vector</h2>
Purely coincidentally, a colleague of mine stumbled upon a problem where they wanted to be able to capture the user-mode context of a thread from a driver, through PsGetThreadContext</code>. The tricky part here was that PsGetThreadContext()</code> follows the following signature:</p>
NTSTATUS
</span>PSAPI
</span>PsGetThreadContext</span>(
</span>    IN PETHREAD </span>Thread</span>,
</span>    IN OUT PCONTEXT </span>ThreadContext</span>,
</span>    IN KPROCESSOR_MODE PreviousMode
</span>    );
</span></code></pre>
Link</a></p>
Where ThreadContext</code> is the linear address to write the thread CONTEXT</code> passed as first argument. However, the 3rd argument, PreviousMode</code> matters the most: if specified as UserMode</code> (1), the function performs a check to make sure the ThreadContext</code> linear address resides within the usermode address range. Since I really love turning theory into practice, I figured this would be a perfect practice case for the technique mentioned above, so I ended up writing a PoC driver to serve that purpose in a (IMHO) fairly nice way. This actually didn’t take long thanks to my driver template</a> and all I had to do was implement the steps which were:</p>

Create a section in the System</code> process. Why in System</code>? Simply because section handles must be tight to a process: therefore if the section is created in a “normal” process, the handle to it will be close when/if said process terminates, effectively closing the section. So we can use the DriverEntry</code> to make sure the section handle is stored in the System</code> kernel handle table. Save the handle in a global variable.</li>
</ol>
    </span>// create section
</span>    {
</span>        OBJECT_ATTRIBUTES </span>oa </span>{};
</span>        </span>InitializeObjectAttributes</span>(
</span>            &oa,
</span>            </span>nullptr</span>,
</span>            OBJ_EXCLUSIVE | OBJ_KERNEL_HANDLE | OBJ_FORCE_ACCESS_CHECK,
</span>            </span>nullptr</span>,
</span>            </span>nullptr</span>);
</span>        LARGE_INTEGER </span>li </span>{.</span>QuadPart </span>= </span>0x1000</span>};
</span>        Status =
</span>            ::</span>ZwCreateSection</span>(&Globals.</span>SectionHandle</span>, SECTION_MAP_WRITE, &oa, &li, PAGE_READWRITE, SEC_COMMIT, </span>NULL</span>);
</span>        </span>EXIT_IF_FAILED</span>(</span>L</span>"</span>ZwCreateSection</span>");
</span>    }
</span></code></pre>
Link</a></p>
By breakpointing at the end of DriverEntry we confirm that the handle resides in the System process.</p>
[*] Loading CHANGEME
</span>[+] PsGetContextThread = FFFFF8061670B5B0
</span>[+] Section at FFFFFFFF80002FB4
</span>[+] Loaded fs filter CHANGEME
</span>Break instruction exception - code 80000003 (first chance)
</span>MinifilterDriver+0x7275:
</span>fffff806`1aa57275 cc              int     3
</span></code></pre>


</a>

Then I can use any callback (process/image notification, minifilter callbacks etc.) to invoke ZwMapViewOfSection</code>, reusing the section handle from the step earlier, and NtCurrentProcess()</code> as process handle.</li>
</ol>
    NTSTATUS Status = ::</span>ZwMapViewOfSection</span>(
</span>        Globals.</span>SectionHandle</span>,
</span>        </span>NtCurrentProcess</span>(),
</span>        &BaseAddress,
</span>        </span>0</span>L</span>,
</span>        </span>0</span>L</span>,
</span>        </span>NULL</span>,
</span>        &ViewSize,
</span>        ViewUnmap,
</span>        </span>0</span>L</span>,
</span>        PAGE_READWRITE);
</span>    </span>EXIT_IF_FAILED</span>(</span>L</span>"</span>ZwMapViewOfSection</span>");
</span></code></pre>
Link</a></p>
BaseAddress</code> will return an 64KB-aligned address located randomly (ASLR). The best thing here, is that we also control ZeroBits</code>, allowing to (partly) control where that address will land.</p>

We’re free to call PsGetThreadContext()</code> with the returned BaseAddress</code> value.</li>
</ol>
    PCONTEXT ctx      = reinterpret_cast<PCONTEXT>(BaseAddress);
</span>    ctx-></span>ContextFlags </span>= CONTEXT_FULL;
</span>    Status = Globals.</span>PsGetContextThread</span>(</span>PsGetCurrentThread</span>(), ctx, UserMode);
</span>    </span>EXIT_IF_FAILED</span>(</span>L</span>"</span>PsGetContextThread</span>");
</span>
</span>    </span>DbgBreakPoint</span>();
</span></code></pre>
Link</a></p>
To prevent any inadverted permission drop of the view (and therefore BSoD-ing us during the call to PsGetThreadContext</code>), we can secure the location using MmSecureVirtualMemory</code>.</p>
From WinDbg we can confirm the VAD is mapped when the breakpoint is hit:</p>


</a>
And as soon as the syscall returns, we’re unmapped:</p>


</a>

Close the section in the driver unload callback.</li>
</ol>
That’s pretty much it: what we’ve got at the end is kernel driver controlled communication vector to any process in usermode: as the section handle is part of System kernel handle table, it’s untouchable from ring-3 unless the driver dictates otherwise by creating a view (with proper permissions) to it. This approach is great as it allows the driver to control everything, but if we want to give a user-mode process some say into it, it’s also possible simply by turning the anonymous section we created for this PoC into a named one, then call sequentially OpenFileMapping(SectionName)</code> then MapViewOfFile()</code>. In addition, it could very well be ported to a process <-> process communication but here I wanted to play with the minifilter callbacks as an on-demand mechanism.</p>
Side-track</h2>
The careful reader will have notice that the step introduce a tiny race condition window, where another thread can also access the memory region. That bothered me, so I also examined more advanced options relying on the shared section objects. By nature they involve 2 PTEs:</p>

the “real” PTE (hardware PTE), effectively used for VA -> PA translation;</li>
along with a prototype PTE.</li>
</ul>
When the view is created, the memory manager will create empty PTEs but expect a page fault. This is verified quickly by breaking right after the call to ZwMapViewOfSection</code></p>
[*] Loading CHANGEME
</span>[+] PsGetContextThread = FFFFF8061670B5B0
</span>[+] Section at FFFFFFFF800035E4
</span>[+] Loaded fs filter CHANGEME
</span>[+] in PID=3292/TID=4676 , MappedSection=0000018D40BF0000
</span>Break instruction exception - code 80000003 (first chance)
</span>MinifilterDriver+0x17a7:
</span>fffff806`1aa517a7 cc              int     3
</span>kd> !pte2 0x000018D40BF0000
</span>@$pte2(0x000018D40BF0000)
</span>    va               : 0x18d40bf0000
</span>    cr3              : 0x3e64d000
</span>    pml4e_offset     : 0x3
</span>    pdpe_offset      : 0x35
</span>    pde_offset       : 0x5
</span>    cr3_flags        : [- -]
</span>    pml4e            : PDE(PA=3e66d000, PFN=3e66d, Flags=[P RW U - - A D - -])
</span>    pdpe             : PDE(PA=3df0e000, PFN=3df0e, Flags=[P RW U - - A D - -])
</span>    pde              : PDE(PA=d97b6000, PFN=d97b6, Flags=[P RW U - - A D - -])
</span>    pte_offset       : 0x1f0
</span>    pte              : PTE(PA=0, PFN=0, Flags=[- RO K - - - - - -])
</span>    kernel_pxe       : 0xffffeb00c6a05f80
</span>kd> dx -r1 @$pte2(0x000018D40BF0000).pte
</span>@$pte2(0x000018D40BF0000).pte                 : PTE(PA=0, PFN=0, Flags=[- RO K - - - - - -])
</span>    address          : 0xd97b6f80
</span>    value            : 0x0
</span>    [...]
</span>    PhysicalPageAddress : 0x0
</span>    Pte              : 0x0 [Type: _MMPTE *]  <<<<
</span></code></pre>
However, after the call to PsGetThreadContext</code> the entry is correctly populated:</p>
kd> g
</span>[+] Rip=00007ffa42e8d724
</span>[+] Rbp=00000020eccff550
</span>[+] Rsp=00000020eccff448
</span>[+] Rax=0000000000000033
</span>[+] Rbx=0000000000214040
</span>[+] Rcx=00000020eccff490
</span>[+] Rdx=0000000000100080
</span>[+] Rdx=0000000000100080
</span>[+] PsGetContextThread() succeeded
</span>Break instruction exception - code 80000003 (first chance)
</span>MinifilterDriver+0x1936:
</span>fffff806`1aa51936 cc              int     3
</span>kd> dx -r1 @$pte2(0x000018D40BF0000)
</span>@$pte2(0x000018D40BF0000)                 : VA=0x18d40bf0000, PA=0xe23a0000, Offset=0x0
</span>    va               : 0x18d40bf0000
</span>    cr3              : 0x3e64d000
</span>    pml4e_offset     : 0x3
</span>    pdpe_offset      : 0x35
</span>    pde_offset       : 0x5
</span>    cr3_flags        : [- -]
</span>    pml4e            : PDE(PA=3e66d000, PFN=3e66d, Flags=[P RW U - - A D - -])
</span>    pdpe             : PDE(PA=3df0e000, PFN=3df0e, Flags=[P RW U - - A D - -])
</span>    pde              : PDE(PA=d97b6000, PFN=d97b6, Flags=[P RW U - - A D - -])
</span>    pte_offset       : 0x1f0
</span>    pte              : PTE(PA=e23a0000, PFN=e23a0, Flags=[P RW U - - A D - -])
</span>    offset           : 0x0
</span>    pa               : 0xe23a0000
</span>    kernel_pxe       : 0xffffeb00c6a05f80
</span></code></pre>
The PTE is valid:</p>
kd> dx -r1 @$pte2(0x000018D40BF0000).pte
</span>@$pte2(0x000018D40BF0000).pte                 : PTE(PA=e23a0000, PFN=e23a0, Flags=[P RW U - - A D - -])
</span>    address          : 0xd97b6f80
</span>    value            : 0xc0000000e23a0867
</span>    Flags            : Flags=[P RW U - - A D - -]
</span>    PageFrameNumber  : 0xe23a0
</span>    Pfn              [Type: _MMPFN]
</span>    PhysicalPageAddress : 0xe23a0000
</span>    Pte              : 0xffff9480f55f81d0 [Type: _MMPTE *]
</span></code></pre>
So this means we have a great way to determine whether a physical page was accessed, using MmGetPhysicalAddress()</code>. To test this we invoke it after the mapping (where we expect a null value) and a second time after the call to PsGetThreadContext</code>:


</a></p>
The 2nd value for PhyBaseAddress</code> points to the physical address where the function output is stored.
At that point, I thought it would be sufficient to stop because we have an effective way to honeypot potential corruptions attempts:</p>

Create a section with many pages (the more the better)</li>
During the preparation to the invocation of PsGetThreadContext</code>, choose randomly one page that will receive the CONTEXT</code></li>
Map all the pages separately</li>
Call PsGetThreadContext</code></li>
</ul>
Once the call is over, we can use the method above to validate whether any other page than the one we know valid were accessed. If so, discard the result.</p>
Isn’t Windows awesome?</p>
End</h1>
There are a lot of possible fun uses of sections, and since I want to try to document more of my “stuff”. Some offensive cool use case would be for instance, would be to expose code “on-demand” to a specific thread/process, removing the mapped execution page(s) from the process VAD as soon as we’re done.
I’ll try to post follow-up updates.</p>
For those interested in the code, you would find a minifilter driver ready to build & compile on the Github project: 
hugsy/shared-kernel-user-section-driver</code>
</a>
</p>
So, see you next time?</p>
Credits & References:</p>

What Makes It Page</a></li>
Windows Internals 7th edition, Part 1</a></li>
Vergilius Project</a></li>
MSDN - Managing Memory Sections</a></li>
</ul>

Setup KDCOM for 2 Hyper-V VMs

2022-07-14T00:00:00+00:00

How to use Hyper-V to debug using KdCOM from 2 VMs, one debugging the other.

Debuggee</h2>

Follow the setup here</a> to setup a BCD profile for KdCom in the VM. Shutdown the VM and in a privileged prompt on the host (here assigned to COM1):

Set-VMComPort</span> MyDebuggedVM  </span>1</span> \\.\pipe\win7x64-kdcom
</span></code></pre>
Debugger</h2>
Still on a privileged prompt on the host, choose a COM port number and connect it to the same pipe:</p>
Set-VMComPort</span> MyDebuggerVM </span>1</span> \\.\pipe\win7x64-kdcom
</span></code></pre>
Boot the debugger and make WinDbgX listen to that port</p>
windbgx -k com:pipe,port=\\.\com1,resets=</span>0</span>,reconnect
</span></code></pre>
Enjoy</p>


</a>

Browsing the registry in kernel-mode

2021-01-10T00:00:00+00:00

One of Windows kernel subsystem I recently dug into is the Configuration Manager (CM</abbr>), mostly because I found very scarce public resources about it despite its criticality: this subsystem is responsible for managing the configuration of all Windows resources, and in user-land is exposed via a very familiar mechanism, the Windows Registry</a>. It is a pretty well documented user-land mechanism</a>, and so is its kernel driver API</a>. My curiosity was around its inner working, and all the few (but brilliant) resources can be found in the link section below.

What I wondered was: How is the registry handled in the kernel by the CM</abbr>? So in the same way that I explored other</a> Windows</a> subsystems</a>, I tried to keep a practical approach, and the result was this WinDbg Js script, RegistryExplorer.js</code> [1]</a> that’ll be referring to throughout this post. This script allows to browse and query via LINQ the registry in a kernel debugging session.


    
        
This is a collection of notes, do not blindly trust, assume mistakes. Also, you’ll find the KD commands are given to reproduce easily, but your offset/index may vary. Last, everything was done/tested against Windows 10 x64 1909: I assume those findings to be applicable to other versions, but it may not be the case.</p>

        </p>
</div>
Overview</h2>
The Registry consists of a set of regular structures called “Hives”. Off-memory, they live in regular file (usually but not necessarily suffixed as .dat</code> - ex: %USERPROFILE%\NTUSER.dat</code>). Each .dat</code> file operates as a small File System with its own hierarchy and nomenclature:</p>

Registry</strong>: Collection of (2) Hives (+ metadata) → PRIMARY</code> + .LOG</code></li>
Hive</strong>: Collection of Bins (+ metadata), follows a tree structure</li>
Bin</strong>: Collection of Cells (+ metadata), bin size must be aligned to PAGE_SIZE</code></li>
Cell</strong>: Basic unit of allocation for the registry (contains raw data). The Cell size is declared as the 1st ULONG of the memory area. Those are critical, we’ll develop how below.</li>
</ul>
As a tree, a Hive</strong> can be browsed, exposing:</p>

Keys</strong> (or Key Nodes</strong>), comparable to Directories in the traditional FS world</li>
Values</strong> (comparable to Files), each of which can have one of 12 types</a>: REG_NONE</code>, REG_SZ</code>, REG_EXPAND_SZ</code>, REG_BINARY</code>, REG_DWORD_LITTLE_ENDIAN</code>, REG_DWORD</code>, REG_DWORD_BIG_ENDIAN</code>, REG_LINK</code>, REG_MULTI_SZ</code>, REG_RESOURCE_LIST</code>, REG_FULL_RESOURCE_DESCRIPTOR</code>, REG_RESOURCE_REQUIREMENTS_LIST</code>, REG_QWORD_LITTLE_ENDIAN</code>, REG_QWORD</code></li>
</ul>
Therefore a Key can contain Sub-Keys but also Values, just like a folder can contain sub-folders and files. Later on, we’ll explain how to enumerate them, as we must go over some pre-requisites first. It could be noted that the analogy of a typical File System is true to the point where it is possible to abuse some situations via Symbolic Links (exploiting REG_LINK</code> types) but we won’t be covering that today.</p>

    
        
For convenience, the following equivalence will be used throughout this post:</p>

Top-Level Keys = Root Keys</li>
Sub Keys = Keys (as long as they aren’t Root Keys)</li>
</ul>

        </p>
</div>
The best structure definition of a Hive I could find comes from “Windows Kernel Internals NT Registry Implementation”[2]</a></sup> (you’ll find many references to the PDF in this post).</p>


</a>
Some hives are loaded very early in the boot process, as the BCD</abbr> needs to retrieve its configuration settings from it in the CM</abbr> hive; and also during kernel loading, hardware info are exposed from the HARDWARE</code> hive. Once parsed and loaded from file to memory, all the system hives are linked via a LIST_ENTRY</code> whose head is pointed by the exposed symbol nt!CmpHiveListHead</code>, and can be iterated over as a list of nt!_CMHIVE</code> object using the nt!_CMHIVE.HiveList</code> field. Therefore a quick parsing can be done with our best friends WinDbg + DDM, which allows us to do some LINQ magic:</p>
0: kd> dx -s @$hives = Debugger.Utility.Collections.FromListEntry(*(nt!_LIST_ENTRY*)&nt!CmpHiveListHead,"nt!_CMHIVE","HiveList")
</span>
</span>0: kd> dx @$hives.Count()
</span>@$hives.Count()  : 0x1f
</span>
</span>0: kd> dx -g @$hives.Select( x => new { CmHiveAddress= &x, HiveName=x.HiveRootPath} )
</span>====================================================================================================
</span>=           = (+) CmHiveAddress     = (+) HiveName                                                 =
</span>====================================================================================================
</span>= [0x0]     - 0xffffa70284240000    - ""                                                           =
</span>= [0x1]     - 0xffffa702842d2000    - "\REGISTRY\MACHINE\SYSTEM"                                   =
</span>= [0x2]     - 0xffffa70284340000    - "\REGISTRY\MACHINE\HARDWARE"                                 =
</span>= [0x3]     - 0xffffa70284d14000    - "\REGISTRY\MACHINE\BCD00000000"                              =
</span>= [0x4]     - 0xffffa70284cec000    - "\REGISTRY\MACHINE\SOFTWARE"                                 =
</span>= [0x5]     - 0xffffa702848e3000    - "\REGISTRY\USER\.DEFAULT"                                    =
</span>= [0x6]     - 0xffffa70287c43000    - "\REGISTRY\MACHINE\SECURITY"                                 =
</span>= [0x7]     - 0xffffa70287d46000    - "\REGISTRY\MACHINE\SAM"                                      =
</span>= [0x8]     - 0xffffa7028806a000    - "\REGISTRY\USER\S-1-5-20"                                    =
</span>[...]
</span></code></pre>
which looks familiar</a>. This command exposes all the _CMHIVE</code> objects loaded by the kernel, but hives themselves can be manipulated via their handle of type _HHIVE</code> (accessible from nt!_CMHIVE.Hive</code>) which allows, thanks to callback members (i.e. function pointers in the structure), to declare how to get access to data, allocate/free new nodes, etc.</p>
Accessing the registry</h2>
An essential pre-requisite to understand how values are accessed in the kernel, is to understand 2 critical structures: Cells</code> and Key Nodes</code> (for now).</p>
According to “Windows Kernel Internals NT Registry Implementation”[2]</a></sup>, a Cell</code> (p.12) is:</p>

The unit of storage allocation within the hive […]</li>
Used to store raw data, and build up logical data

Keys, values, security descriptors, indexes etc all are made up of cells</li>
Fetching in a key, might involve several faults spread across the hive file</li>
</ul>
</li>
</ul>
A Key Node</code> (of internal type nt!_CM_KEY_NODE</code>) is the structure inside the tree that will allow to access Cells (don’t worry Cells will be amply covered below - for now just think of it as the raw data). For a given key node, its Values (~files) are pointed by the field nt!_CM_KEY_NODE.ValueList</code>, of type nt!_CHILD_LIST</code>; and its subkeys (~sub-folders) via nt!_CM_KEY_NODE.SubkeyLists</code>. This is always true, except for symbolic links (type = REG_LINK</code>), which will dereference the node they point to via the field nt!_CM_KEY_NODE.ChildHiveReference</code>.</p>
So when by browsing a key node, what to pay attention to are:</p>

the SubKey list (i.e. ~subfolders</em>)</li>
</ul>
0: kd> dt _CM_KEY_NODE
</span>nt!_CM_KEY_NODE
</span>   [...]
</span>   +0x014 SubKeyCounts     : [2] Uint4B
</span>   +0x01c SubKeyLists      : [2] Uint4B
</span>   [...]
</span></code></pre>

the Value list (i.e. ~files</em>)</li>
</ul>
0: kd> dt _CM_KEY_NODE
</span>nt!_CM_KEY_NODE
</span>  [...]
</span>   +0x024 ValueList        : _CHILD_LIST
</span>  [...]
</span>
</span>0: kd> dt _CHILD_LIST
</span>nt!_CHILD_LIST
</span>   +0x000 Count            : Uint4B
</span>   +0x004 List             : Uint4B
</span></code></pre>
And looking up a specific Value can be summarized as such:</p>


</a>
Source[2]</a></sup></p>
As we see from the symbols, Value and SubKey lists are not designated by direct pointers in memory, but instead by indexes. Those indexes point to Cells, which contains either the data itself or the next key node to parse to reach the data. We’ve kept mentioning Cells</code> without covering it, it now becomes important to do so, know how Cells are, how they work and how they can be accessed.</p>
Cells</h3>
The Cell</code> is the basic storage unit for a Hive: what this means is that all data</strong> of the hive can be found by knowing 2 pieces of information, a handle to the hive (_HHIVE</code>) and the Cell Index</strong> - a Cell is never pointed to directly. In the PDF by Dr B. Probert, a good technical overview of cells can be found, and the key points are:</p>

Referenced as a ‘cell index’ (HCELL_INDEX)</li>
Cell index is offset within the file (minus 0x1000 – the header) – ULONG</li>
Size rounded at 8 bytes boundary</li>
If Index & 1<<31 , then the cell is Volatile ; Else Permanent</li>
If Cell.Size >= 0 , Cell.Status = Free ; Else Cell.Status = Allocated && Cell.RealSize = -Cell.Size</li>
</ul>
As for the exact type, ReactOS</a> helps us with the exact definition:</p>
    </span>typedef </span>ULONG HCELL_INDEX, *PHCELL_INDEX;
</span></code></pre>
So the cell index is a ULONG, which can be decomposed as a bitmask that allows to determine more information such as the cell Type (Permanent vs Volatile) and the Block; information which can be extracted from the Index as such:</p>
    </span>#define </span>HvGetCellType</span>(</span>Cell</span>)  ((ULONG)(((Cell) & HCELL_TYPE_MASK) >> HCELL_TYPE_SHIFT))
</span>    </span>#define </span>HvGetCellBlock</span>(</span>Cell</span>) ((ULONG)(((Cell) & HCELL_BLOCK_MASK) >> HCELL_BLOCK_SHIFT))
</span></code></pre>
ReactOS</a></p>
Now how do we go from the key node to a cell, assuming we have a hive handle and an index? Remember above when we mentioned that the procedure to get to the cell is a function pointer inside the hive handle: nt!_HHIVE.GetCellRoutine</code>? Well, that’s how. Also interestingly, all the hive handles are pointing to the same function nt!HvpGetCellPaged</code>, although it doesn’t have to be the case:</p>
0: kd> dt _HHIVE
</span>nt!_HHIVE
</span>   +0x000 Signature        : Uint4B    // 0xbee0bee0
</span>   +0x008 GetCellRoutine   : Ptr64     _CELL_DATA*
</span>   +0x010 ReleaseCellRoutine : Ptr64     void
</span>   +0x018 Allocate         : Ptr64     void*
</span>   +0x020 Free             : Ptr64     void
</span>   [...]
</span>
</span>0: kd> dx -g @$hives.Select( h => new { HiveName=h.HiveRootPath, CellRoutine=h.Hive.GetCellRoutine} )
</span>====================================================================================================
</span>=           = (+) HiveName                                                 = (+) CellRoutine       =
</span>====================================================================================================
</span>= [0x0]     - ""                                                           - 0xfffff8054248e880    =
</span>= [0x1]     - "\REGISTRY\MACHINE\SYSTEM"                                   - 0xfffff8054248e880    =
</span>= [0x2]     - "\REGISTRY\MACHINE\HARDWARE"                                 - 0xfffff8054248e880    =
</span>= [0x3]     - "\REGISTRY\MACHINE\SOFTWARE"                                 - 0xfffff8054248e880    =
</span>= [0x4]     - "\REGISTRY\MACHINE\BCD00000000"                              - 0xfffff8054248e880    =
</span>[...]
</span>
</span>0: kd> .printf "%y\n", 0xfffff8054248e880
</span>nt!HvpGetCellPaged (fffff805`4248e880)
</span></code></pre>
By reversing it in IDA, it reveals the exact behavior for fetching cells (below shown in a simplified pseudo-C code):</p>
_CELL_DATA *__fastcall </span>HvpGetCellPaged</span>(_HHIVE *</span>hive</span>, </span>unsigned int </span>CellIndex</span>, _HV_GET_CELL_CONTEXT *</span>ctx</span>)
</span>{
</span>  _HMAP_ENTRY *Entry;
</span>  PVOID BinAddress;
</span>  PVOID CellAddress;
</span>  _CELL_DATA *CellResult;
</span>  [...]
</span>  Entry = &hive->Storage[CellIndex >> </span>31</span>].</span>Map</span>->Directory[(CellIndex >> </span>21</span>) & </span>0x3FF</span>]->Table[(CellIndex >> </span>12</span>) & </span>0x1FF</span>];
</span>  BinAddress = Entry->PermanentBinAddress;
</span>  [...]
</span>  CellAddress = Entry->BlockOffset + (BinAddress & </span>0xFFFFFFFFFFFFFFF0</span>ui64</span>) + (CellIndex & </span>0xFFF</span>);
</span>  [...]
</span>  CellResult = (_CELL_DATA *)(CellAddress + </span>4</span>); </span>// *CellAddress contains the size field as ULONG
</span>  [...]
</span>  </span>return</span> CellResult;
</span>}
</span></code></pre>
With that in mind, we can craft an equivalent function GetCellAddress</code> that we can use in WinDbg, which given a hive handle and an index will return the cell address in memory (in WinDbg JS):</p>
function </span>GetCellAddress</span>(</span>KeyHive</span>, </span>Index</span>)
</span>{
</span>    </span>let </span>Type </span>= </span>GetCellType</span>(</span>Index</span>);
</span>    </span>let </span>Table </span>= </span>GetCellTable</span>(</span>Index</span>);
</span>    </span>let </span>Block </span>= </span>GetCellBlock</span>(</span>Index</span>);
</span>    </span>let </span>Offset </span>= </span>GetCellOffset</span>(</span>Index</span>);
</span>    </span>let </span>MapDirectory </span>= </span>KeyHive</span>.</span>Storage</span>[</span>Type</span>].</span>Map</span>;
</span>    </span>let </span>MapTableEntry </span>= </span>MapDirectory</span>.</span>Directory</span>[</span>Table</span>];
</span>    </span>let </span>Entry </span>= </span>host</span>.</span>createPointerObject</span>(</span>MapTableEntry</span>.</span>address</span>.</span>add</span>(</span>Block </span>* </span>sizeof</span>("</span>nt!_HMAP_ENTRY</span>")), "</span>nt</span>", "</span>_HMAP_ENTRY*</span>");
</span>    </span>let </span>BinAddress </span>= </span>Entry</span>.</span>PermanentBinAddress</span>.</span>bitwiseAnd</span>(~</span>0x0f</span>);
</span>    </span>let </span>CellAddress </span>= </span>BinAddress</span>.</span>add</span>(</span>Entry</span>.</span>BlockOffset</span>).</span>add</span>(</span>Offset</span>);
</span>    </span>return </span>CellAddress</span>;
</span>}
</span></code></pre>
Such function is critical to navigate correctly in the hive, and we’ll refer to it in the rest of the article as GetCellAddress()</code>. If you remember the lookup slide, you’ll realize that the function is “incorrect”: in its state it’ll return the address of the beginning of the Cell, which holds the size (as a ULONG). Therefore to get the address of the data</strong> of the Cell, simply add sizeof(ULONG)</code> (or 4) to the result.</p>
It was interesting to me to find that the engineers behind the CM have decided to go with this function pointer approach for hives, instead of a static one but couldn’t find one (if you know, let me know!). And hey, it makes any form of kernel hooking for the registry a lot easier so it’s great for us!</p>
Enumerating Values</h3>
Now that we’ve understood the logic behind Cells and how to navigate through them, the rest is easier to understand. As we’ve mentioned before, “Key Values” are roughly the equivalent of a regular filesystem files. To get the values of a specific key node, one can use the field nt!_CM_KEY_NODE.ValueList</code> (of type _CHILD_LIST</code>) we’ve briefly discussed above.</p>
0: kd> dt _CHILD_LIST
</span>nt!_CHILD_LIST
</span>   +0x000 Count            : Uint4B
</span>   +0x004 List             : Uint4B
</span></code></pre>
Then it’s as simple as it gets: the structure gives us the number of values and the Cell Index of the array (of the form of an array of size _CHILD_LIST.Count</code> x sizeof(HCELL_INDEX)</code>) of all the values of this key node. Then we simply iterate through the list of HCELL_INDEX using GetCellAddress(KeyHive, Index)</code> to get the Key Nodes of type CM_KEY_VALUE_SIGNATURE</code>: the type CM_KEY_VALUE_SIGNATURE</code> will indicate that the current node has a structure of nt!_CM_KEY_VALUE</code>, where the actual content and content length can be read.</p>
0: kd> dt _CM_KEY_VALUE
</span>nt!_CM_KEY_VALUE
</span>   +0x000 Signature        : Uint2B
</span>   +0x002 NameLength       : Uint2B
</span>   +0x004 DataLength       : Uint4B
</span>   +0x008 Data             : Uint4B
</span>   +0x00c Type             : Uint4B
</span>   +0x010 Flags            : Uint2B
</span>   +0x012 Spare            : Uint2B
</span>   +0x014 Name             : [1] Wchar
</span></code></pre>
_CM_KEY_VALUE.Data</code> doesn’t contain a pointer to the data, but again an HCELL_INDEX</code>: so we need to call again GetCellAddress()</code> on this index (we stay on the same hive), and finally retrieve the data.</p>
Enumerating SubKeys</h3>
By knowing how cells work it is possible to know how subkeys will be linked: subkeys are just _CM_KEY_NODE</code> objects. the structure gives 2 fields</p>
   +0x014 SubKeyCounts     : [2] Uint4B
</span>   +0x01c SubKeyLists      : [2] Uint4B
</span></code></pre>
The important one is SubKeyLists</code> which is an array of 2 (… you guessed it …) Cell Indexes (HCELL_INDEX</code>). The reasons each array has 2 entries, is to differentiate between Permanent SubKeys (at index 0), and Volatile subKeys (at index 1). To iterate through a tree, there needs to be a root. And the hive root node cell index is given by the field RootCell</code> of the _HBASE_BLOCK</code>, which the hive handle always holds a reference to, via the BaseBlock</code> field:</p>

graph LR;
    A[_HHIVE] -- ".BaseBlock" --> B["_HBASE_BLOCK"];
    B -- "GetCellAddress(.RootCell)" --> C["_CM_INDEX[0]"];
    B -- "GetCellAddress(.RootCell)" --> E["_CM_INDEX[1]"];
    B -- "GetCellAddress(.RootCell)" --> F["_CM_INDEX[...]"];
    C -- ".Cell" --> D["_CM_KEY_NODE"];
</div>
As we shown before from the linked list of _CMHIVE</code> from nt!CmpHiveListHead</code> we can iterate through all the system hives. Each hive object has a pointer to a handle of hive (_HHIVE</code>) which exposes a _DUAL</code> field named Storage</code>: the index 0 is used for permanent storage, index 1 for volatile</p>
0: kd> dt _DUAL
</span>nt!_DUAL
</span>   +0x000 Length           : Uint4B
</span>   +0x008 Map              : Ptr64 _HMAP_DIRECTORY
</span>   +0x010 SmallDir         : Ptr64 _HMAP_TABLE
</span>   +0x018 Guard            : Uint4B
</span>   +0x020 FreeDisplay      : [24] _FREE_DISPLAY
</span>   +0x260 FreeBins         : _LIST_ENTRY
</span>   +0x270 FreeSummary      : Uint4B
</span></code></pre>
To summarize more graphically</p>

graph LR;
    Z(nt!CmpHiveListHead) --> X["_CMHIVE"];
    X-- ".Hive" --> Y["_HHIVE"];
    Y-- ".Storage[0=Permanent,1=Volatile]" --> W[_HMAP_DIRECTORY]
</div>
The subkeys will be located in the Map</code> element (of type _HMAP_DIRECTORY</code>). The _HMAP_DIRECTORY</code> structure simply contains 1 element, a table of 1024 _HMAP_TABLE</code>, each of them structured of 1 element: a Table</code> of 512 _HMAP_ENTRY</code>.</p>
0: kd> dt _HMAP_DIRECTORY
</span>nt!_HMAP_DIRECTORY
</span>   +0x000 Directory        : [1024] Ptr64 _HMAP_TABLE
</span>0: kd> dt _HMAP_TABLE
</span>nt!_HMAP_TABLE
</span>   +0x000 Table            : [512] _HMAP_ENTRY
</span>0: kd> dt _HMAP_ENTRY
</span>nt!_HMAP_ENTRY
</span>   +0x000 BlockOffset      : Uint8B
</span>   +0x008 PermanentBinAddress : Uint8B
</span>   +0x010 MemAlloc         : Uint4B
</span></code></pre>

graph LR;
    A[_HMAP_DIRECTORY] --> B["_HMAP_TABLE[0]"];
    A[_HMAP_DIRECTORY] --> C["_HMAP_TABLE[1]"];
    A[_HMAP_DIRECTORY] --> D["_HMAP_TABLE[..]"];
    A[_HMAP_DIRECTORY] --> E["_HMAP_TABLE[1023]"];
    B --> F["_HMAP_ENTRY[0]"];
    B --> G["_HMAP_ENTRY[1]"];
    B --> H["_HMAP_ENTRY[..]"];
    B --> I["_HMAP_ENTRY[511]"];
</div>
The last nibble of PermanentBinAddress</code> is used for meta-data, so we can bitwise AND it with ~0xf</code>. Finally to access the data, we simply must add the BlockOffset value, and the final Offset retrieved from AND-ing the Index to 0xfff. This is a the behavior that the function GetCellAddress()</code> will do for us to painlessly get the virtual address of a cell, just from a hive handle and an Index.</p>
Put it all together</h2>
As a learning exercise, I always try to build a script/tool when digging into a topic, and here the result is another WinDbg JS script, RegistryExplorer.js</code>^{[1]</a></sup> which will allow to navigate through the registry using WinDbg Debugger Data Model (and therefore also query it via LINQ)</p>


</a>}

    
        a better version was done by 
@msuiche</code>
</a>
 here[^3]</p>

        </p>
</div>
Example:</p>
0: kd> dx @$cursession.Registry.Hives
</span>@$cursession.Registry.Hives                 : [object Generator]
</span>    [0x0]            : \REGISTRY\MACHINE\SYSTEM
</span>    [0x1]            : \REGISTRY\MACHINE\HARDWARE
</span>    [0x2]            : \REGISTRY\MACHINE\BCD00000000
</span>    [0x3]            : \REGISTRY\MACHINE\SOFTWARE
</span>    [0x4]            : \REGISTRY\USER\.DEFAULT
</span>    [0x5]            : \REGISTRY\MACHINE\SECURITY
</span>    [...]
</span>
</span>0: kd> dx @$cursession.Registry.Hives.Where( x => x.Name == "HARDWARE" ).First()
</span>@$cursession.Registry.Hives.Where( x => x.Name == "HARDWARE" ).First()             : \REGISTRY\MACHINE\HARDWARE
</span>    HiveObject       [Type: _CMHIVE]
</span>    HiveHandle       [Type: _HHIVE]
</span>    HiveAddress      : 0xffffcf0289744000
</span>    MountPoint       : \REGISTRY\MACHINE\HARDWARE
</span>    RootCellIndex    : 0x20
</span>    RootNode         : HARDWARE
</span>    Name             : HARDWARE
</span></code></pre>
Or the click-friendly version 😀</p>


</a>
Practical Toy Example: dumping SAM</h3>
Any beginner pentester would (should?) know that in user-mode, a local Administrator account has enough privilege to dump the SAM</code> & SYSTEM</code> hives from the command line using reg.exe</code>: (* If you didn’t know, I’d suggest reading this[3]</a></sup> ASAP)</p>
PS C:\WINDOWS\system32> </span>reg</span>.exe save HKLM\SAM C:\Temp\SAM.bkp
</span>The operation completed successfully.
</span></code></pre>
Same goes for SYSTEM</code>.</p>
However, even as Administrator trying to access using regedit.exe</code> the subkeys of HLKM\SECURITY</code> and SAM</code> will be denied as they require NT AUTHORITY\SYSTEM</code> privilege which is only a half protection, as psexec /s</code> would be enough to bypass it. So with that in mind, in theory, RegistryExplorer.js</code> gives us everything we need to fetch those values.</p>
And then real life strikes…</p>
Issue #1</h4>
As I was trying to get those values manually, the initial script failed (crashed) complaining there was an invalid access to user-mode memory:</p>
GetCellDataAddress(Hive=ffffab04d1191000, Index=32): type=0 table=0 block=0 offset=32
</span>    [0x0]            : Unable to read target memory at '0x280f6fa1850' in method 'readMemoryValues' [at registryexplorer (line 20 col 18)]
</span></code></pre>
It seemed that the cells for accessing the SAM were at some points hitting user-mode area, in a process different than System</code>, so the address access walking the wrong page table, and hence the exception from WinDbg. Which got immediately confirmed:</p>
0: kd> dt _hmap_entry ffffab04d1191000
</span>nt!_HMAP_ENTRY
</span>   +0x000 BlockOffset      : 0
</span>   +0x008 PermanentBinAddress : 0x00000280`f6fa1001 <<< yup here, in UM
</span>   +0x010 MemAlloc         : 0x1000
</span></code></pre>
Then how does the kernel know where to fetch this information? Well it turned out that the hive handle can hold reference to a process in its ViewMap.ProcessTuple</code> attribute, of type _CMSI_PROCESS_TUPLE</code> which holds both a handle to the _EPROCESS</code> and a pointer to the _EPROCESS</code>. We can use that information to determine the backing process:</p>
0: kd> dt _hhive ffffab04d1191000 ViewMap.ProcessTuple
</span>nt!_HHIVE
</span>   +0x0d8 ViewMap              :
</span>      +0x018 ProcessTuple         : 0xfffff805`422657c0 _CMSI_PROCESS_TUPLE
</span>
</span>0: kd> dx ((_CMSI_PROCESS_TUPLE*)0xfffff805`422657c0)->ProcessReference
</span>((_CMSI_PROCESS_TUPLE*)0xfffff805`422657c0)->ProcessReference : 0xffff828d85dbd080 [Type: void *]
</span>
</span>0: kd> dx @$cursession.Processes.Where( x => &(x.KernelObject) == (_EPROCESS*)0xffff828d85dbd080)
</span>@$cursession.Processes.Where( x => &(x.KernelObject) == (_EPROCESS*)0xffff828d85dbd080)
</span>    [0x54]           : Registry [Switch To]
</span></code></pre>
It points to the Registry</code> process, which makes sense. To confirm, we can switch to the context of the process, and try to re-access the UM address 0x280f6fa1850</code>:</p>
0: kd> dx -s @$cursession.Processes.Where( x => x.Name == "Registry").First().SwitchTo()
</span>0: kd> db 0x280f6fa1850
</span>00000280`f6fa1850  a8 ff ff ff 6e 6b 20 00-4a 92 fb 8e 6b 38 d5 01  ....nk .J...k8..
</span>00000280`f6fa1860  03 00 00 00 c0 02 00 00-06 00 00 00 00 00 00 00  ................
</span>00000280`f6fa1870  a0 1f 00 00 ff ff ff ff-01 00 00 00 28 2c 00 00  ............(,..
</span>[...]
</span></code></pre>
The signature kn</code> (0x6b6e) at 0x280f6fa1850+sizeof(ULONG)</code> confirms we’re hitting the right spot.</p>
Issue #2</h4>
Now I could access some keys & values but not everything:</p>
0: kd> dx @$SamHive = @$cursession.Registry.Hives.Where( x => x.MountPoint.EndsWith("SAM")).First()
</span>
</span>0: kd> dx @$SamHive.RootNode.Subkeys[0].Subkeys[0].Subkeys.Where(x => x.KeyName == "Account").First().Subkeys
</span>@$SamHive.RootNode.Subkeys[0].Subkeys[0].Subkeys.Where(x => x.KeyName == "Account").First().Subkeys                 : [object Generator]
</span>    [0x0]            : Aliases
</span>    [0x1]            : Groups
</span>    [0x2]            : Users
</span></code></pre>
The 2nd issue faced was that when trying to access some keys in UM for the HKLM\SAM</code> hive, WinDbg would inconsistently return some access violation error. This reason was somewhat easier to figure out the cause, less easy for a programmatic remediation.</p>
0: kd> dx @$cursession.Registry.Hives.Where( x => x.MountPoint.EndsWith("SAM")).First().RootNode.Subkeys[0].Subkeys[0].Subkeys.Where(x => x.KeyName == "Account").First().Subkeys[2].Subkeys
</span>@$cursession.Registry.Hives.Where( x => x.MountPoint.EndsWith("SAM")).First().RootNode.Subkeys[0].Subkeys[0].Subkeys.Where(x => x.KeyName == "Account").First().Subkeys[2].Subkeys                 : [object Generator]
</span>GetCellDataAddress(Hive=ffffab04d1191000, Index=8096) = 280f6fa2fa0
</span>    [0x0]            : Unable to read target memory at '0x280f6fa2fa4' in method 'readMemoryValues' [at registryexplorer (line 20 col 18)]
</span></code></pre>
The cause behind it was not the calculation method of the Cell address but due to the fact that the page was paged out. The clue for me was the fact the missing is usually surrounded by other mapped pages.</p>
0: kd> db 280f6fa2fa0
</span>00000280`f6fa2fa0  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
</span>00000280`f6fa2fb0  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
</span>00000280`f6fa2fc0  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
</span>00000280`f6fa2fd0  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
</span>00000280`f6fa2fe0  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
</span>00000280`f6fa2ff0  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
</span>00000280`f6fa3000  fe a3 d4 01 ff ff ff ff-ff ff ff 7f 57 8a 70 38  ............W.p8
</span>00000280`f6fa3010  c8 b0 d6 01 e9 03 00 00-01 02 00 00 14 02 00 00  ................
</span></code></pre>
I didn’t find a way to solve this programmatically (i.e. force WinDbg to page-in), although just a reboot is enough to make sure the desired pages are still in memory. Then we can finally access the keys and values:</p>
0: kd> dx @$UserEncryptedPasswords = @$cursession.Registry.Hives.Where( x => x.MountPoint.EndsWith("SAM")).First().RootNode.Subkeys[0].Subkeys[0].Subkeys.Where(x => x.KeyName == "Account").First().Subkeys[2].Subkeys
</span>@$cursession.Registry.Hives.Where( x => x.MountPoint.EndsWith("SAM")).First().RootNode.Subkeys[0].Subkeys[0].Subkeys.Where(x => x.KeyName == "Account").First().Subkeys[2].Subkeys                 : [object Generator]
</span>    [0x0]            : 000001F4
</span>    [0x1]            : 000001F5
</span>    [0x2]            : 000001F7
</span>    [0x3]            : 000001F8
</span>    [0x4]            : 000003E9
</span>    [0x5]            : Names
</span></code></pre>
So then to dump the keys for the Administrator</code> (UID=500=0x1f4)</p>
0: kd> dx @$UserEncryptedPasswords[0].Values
</span>@$UserEncryptedPasswords[0].Values                                  : [object Generator]
</span>    [0x0]            : F
</span>    [0x1]            : V
</span>    [0x2]            : SupplementalCredentials
</span>
</span>0: kd> dx @$UserEncryptedPasswords[0].Values[0]
</span>dx @$UserEncryptedPasswords[0].Values[0]                            : F
</span>    KeyHive          [Type: _HHIVE]
</span>    KeyValueObject   : 0x271ee85192c [Type: _CM_KEY_VALUE *]
</span>    KeyName          : F
</span>    KeyDataType      : REG_BINARY
</span>    KeyDataSize      : 0x50
</span>    Type             : CM_KEY_VALUE_SIGNATURE (6b76)
</span>    KeyDataRaw       : 3,0,1,0,0,0,0,0,0,...
</span></code></pre>
And done, we’ve got the data! We can now totally navigate the Registry from a KD session!</p>
Outro</h2>
Understanding those bits of the CM</abbr> took more work than I imagined, but as it was nicely engineered, it was fun to go through. The CM</abbr> is way more complex than that, but this is the basics: we didn’t cover more advanced stuff like the use of the .LOG</code> file, the memory management of the CM</abbr> and other funkiness, but I hope this article was interesting and useful to you and thanks for making it this far.</p>
Peace out ✌</p>
References</h2>


comaeio/SwishDbgExt</code>
</a>
</li>

reactos/reactos</code>
</a>
</li>
Windows Internals 6th - Part 1</a>, Chapter 4: Management Mechanism - The Registry</li>
Enumerating Registry Hives - moyix</a></li>
</ul>


RegistryExplorer.js</a> ↩</a> ↩2</a></p>
</li>

Windows Kernel Internals NT Registry Implementation</a> ↩</a> ↩2</a> ↩3</a></p>
</li>

Dumping Windows Credentials</a> by 
@lanjelot</code>
</a>
 ↩</a></p>
</li>
</ol>

Some toying with the Self-Reference PML4 Entry

2020-06-15T00:00:00+00:00

Sometimes you read about an awesome exploitation technique (#1</a>), so you want to go deeper. So this is my notes about how trying to totally understand the exploitation of CVE-2020-0796 (#2</a>), I ended up struggling finding good explanation about a critical structure of Windows paging mechanism: the “Self-Reference PML4 Entry”. Disclaimer: If you came here for new stuff, so let me put your mind at peace: There’s nothing new here, I don’t claim to find anything what’s being found and said by people way smarter, and I have probably understood it wrong anyway so don’t judge/quote me. Also the post will only talk be about x64 and Windows here (and having a (L)KD open can help to follow along).

MMU 101</h2> Although this post won’t be only about the MDL</abbr> (there’s a book for that #3</a>), some background is required for understanding why there is a need for the so-called Self-Reference PML4 entry. The root question for that is a simple (but not trivial) one: how does the processor read/write a block of physical memory, only by knowing the virtual address, or in layman’s term, how to go from Virtual Address to Physical Address?
Segmentation</h3>
On Intel and AMD processors, a virtual address is a combination of a segment number and a linear address, or segment_number:linear_address</code> and even on 64b architecture segmentation is still necessary. So in long mode, a code virtual address is never just 0xLinearAddress</code> but always cs:0xLinearAddress</code>, data is ds:0xLinearAddress</code>, stack is ss:0xLinearAddress</code>, and so on, where cs</code>, ds</code>, ss</code> register holds a WORD value corresponding to an index (with the 2 least significant bit OR-ed, designating the CPL</abbr>) . The segment number will be added to the value of the register gdtr</code> and will get the segment descriptor:
kd> r cs, rip, gdtr cs=0010 rip=fffff80041e811e0, gdtr=fffff80044b5dfb0 kd> dd @gdtr + @cs l2 fffff800`44b5dfc0 00000000 00209b00 kd> .formats 00209b00 [...] Binary: [..] 00000000 00100000 10011011 00000000 </code></pre> Which we can parse combined with the format given by the AMD manual:
</a> (Src: AMD Programmer’s Manual Volume 2)
0x00209b00 = 0000 0000 ‭ 0010 0000 1001 1011 0000 0000‬ [BaseL ] gdLa P| 1 1CRA [BaseM ] | ↳ DPL=0 0x00000000 = 0000 0000 0000 0000 0000 0000 0000 0000 [ BaseAddress 15:0 ] [ Seg Limit 15:0 ] </code></pre> The CPL</abbr> being given by the 2 lowest bytes of CS, it is now easy to understand how the CPU performs privilege check: by simply comparing the CPL</abbr> from CS register and DPL</abbr> from the segment descriptor, or if you prefer a visual diagram from the AMD manual:
</a> (Src: AMD Programmer’s Manual Volume 2)
As we saw earlier, the Address</code> and Limit</code> parts of the descriptor are equal to 0 in Long-Mode (64-bit) - this may be the source of confusion I read in some blog posts (but no name shaming, it’s not the point 😋).
Also if you’re lazy (like me) and addicted to WinDbg (like me), the dg</code> command will pretty-print all those info for you:
kd> dg @cs P Si Gr Pr Lo Sel Base Limit Type l ze an es ng Flags 0010 00000000`00000000 00000000`00000000 Code RE Ac 0 Nb By P Lo 0000029b kd> dg @ds P Si Gr Pr Lo Sel Base Limit Type l ze an es ng Flags 002B 00000000`00000000 00000000`ffffffff Data RW Ac 3 Bg Pg P Nl 00000cf3 </code></pre> There is plenty more to say about the segmentation mechanism on x86, but for our purpose (reminder: how does the CPU goes from VA to PA?), we’ll stick to those basic highlights.
Paging</h3> Preparing this post, I came across this blog post</a> that @33y0re</code> </a> wrote recently, and where he did a really good job summarizing how paging works on x86-64 long-mode, and how to explore it on Windows. Therefore I will send you reader to his article, and assume from then on you know of PML4, PDPT, PD, PT and what a canonical linear address is.
The best summary can be given by this diagram (again from AMD’s manual)
</a> Source: AMD Programmer’s Manual Volume 2
What & why the hell is “Self-Reference PML4 entry” ?</h2> Back to the problem at hand, i.e. understand how does the CPU go from VA to PA, there is an intrinsic problem: the CPU only uses virtual address so how could the processor manipulates the permissions, flags, etc. of those PTEs which are physical? Simply by mapping the PTE tables in VAS, right? But that creates a recursive problem, because we still don’t know how to go from VA to PA. And that’s precisely where “Self-Reference PML4 entry” comes in. But let’s go back a bit. When a new process is created, a new PML4 is also allocated holding the physical root address for our process address space. From that physical root address and with all the offsets from the VA itself, the MDL</abbr> can crawl down the physical page directories until getting the wanted data (see “Paging” above). This physical address is stored in the nt!_KPROCESS</code></a> structure of the process, precisely in _KPROCESS.DirectoryTableBase</code>. To experiment this behavior, we can create a simple program that will only int3</code> so that KD gets the hand while still in user-mode: void main() {__asm__("int3;"); } </code></pre> Compile and execute, and as expected KD notifies the breakpoint: Break instruction exception - code 80000003 (first chance) int3+0x6d08: 0033:00007ff7`83f26d08 cc int 3 kd> dx @$curprocess.KernelObject.Pcb.DirectoryTableBase @$curprocess.KernelObject.Pcb.DirectoryTableBase : 0x762ec002 [Type: unsigned __int64] kd> dx @$curprocess.KernelObject.Pcb.DirectoryTableBase == @cr3 @$curprocess.KernelObject.Pcb.DirectoryTableBase == @cr3 : true </code></pre> So when a process switch occurs, the kernel can move nt!_EPROCESS.KernelObject.Pcb.DirectoryTableBase</code> into cr3</code> (that mov</code> operation forcing the TLB cache being flushed), given the newly running process the illusion of having a clean full virtual address space, and by the same way physically isolating processes. But we slightly digressed, back to the topic: in order to map in the VAS our PML4 which is in physical address space, the kernel needs a way to always know at least one entry of the PML4: this is the “Self-Reference Entry”. Also seen to be called “auto-entry”, the Self-Reference Entry (or “self-ref entry” for short) is a special PML4 index (so then only 9-bit in size) that only the kernel knows (hence between 0x100-0x1ff), and whose content points the physical address of the PML4 itself. By doing so, Windows kernel gives itself an easy way to reach by a virtual address, any directory (PML4, PDPT, PDE, etc.). On Windows 7, the self-ref entry index is a static value (0x1ed) whereas Windows 10 randomizes it on boot. So to understand why this Self-Reference Entry is helpful, let’s process a virtual address like the MDL</abbr> would: the PML4 index corresponds to the 39:47 bits of a VA, so the value 0x1ed (or 0b111101101) would be as follow: Bi| 6 ... 4444 4444 3333 ... t#| 3 ... 7654 3210 9876 ... Va| 1111 0110 1xxx <<-- 0x1ed lu| </code></pre> So for all Windows from 7 to 10 TH2, the PML4 table of all processes was always mapped at the same range 0xFFFFF680`00000000 → 0xFFFFF6FF`FFFFFFFF. The randomization was added by Windows 10 RS1. So let’s translate a special VA 0xFFFFF6FB`7DBED000‬ to a physical address (PA): by decomposing its indexes we get: * pml4e_offset : 0x1ed * pdpe_offset : 0x1ed * pde_offset : 0x1ed * pte_offset : 0x1ed * offset : 0x000 </code></pre> the output is from my PageExplorer.js</code></a> WinDbg script. </div> The PML4E of the current process can be reached at CR3 + 0x1ed*@$ptrsize</code>: but the content is the base physical address of the PML4 itself again! So the PDPE will itself also translate to the PML4 and so on until we read the PTE+offset</code> which again will return the base address of the PML4 (because offset=0</code>)! So what we get is an easy way to read the content of not just the PML4 itself, but any page directory, and all simply by knowing that 9-bit value (and therefore, calculating the corresponding PXE)! So you can artificially create VA simply by their offset, for instance to read the PageTable instead? * pml4e_offset : 0x1ed * pdpe_offset : 0x000 * pde_offset : 0x000 * pte_offset : 0x000 * offset : 0x000 </code></pre> And build the address as 0xffff<<48 | $pml4e_offset<<39 | $pdpe_offset<<30 | $pde_offset<<21 | $pte_offset<<12 | $offset => 0xffff<<48 | 0x1ed<<39 | 0<<30 | 0<<21 | 0<<12 | 0 </code></pre> And you get the value: 0xFFFFF680`00000000. That’s why older versions of Windows (which did not randomized the Self-Reference entry and had it hardcoded at 0x1ed) offered a great avenue for defeating KASLR even remotely because you knew for sure always where the PageTable was, and there was a way to browse all pages of a process without ever faulting. And even on modern recent Windows 10, it still means with an arbitrary write you can defeat KASLR and SMEP/SMAP together. To summarize (or if you just jumped to the end of this section), what’s awesome about the Self-Reference PML4 Entry is that knowing only 9 bits (for example 0x1ed) we can easily dump physical memory! What about Windows 10 RS1+?</h2> Up until Windows 10 TH2, the magic index for the Self-Reference PML4 entry was 0x1ed as mentioned above. But what about Windows 10 from 1607? Well Microsoft uped their game, as a constant battle for improving Windows security</a> the index is randomized at boot-time, so 0x1ed is now one of the 512 possible values (i.e. 9-bit index) that the Self-Reference entry index can have. And side effect, it also broke some of their own tools, like the !pte2va</code> WinDbg command. On Windows 2004 x64, 0xFFFFF680`00000000 points to nothing (at least most of the times 🤓) kd> db 0xFFFFF680`00000000 l20 fffff680`00000000 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? fffff680`00000010 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? </code></pre> But is it really 512 values for the entry? Well no, because the most significant bit must be set to 1 for the Sign-Extension to properly make it a kernel canonical address. So it is more 256 values (from 0x100 to 0x1ff). If we’re in KD, this index can be retrieved by a new global symbol nt!MmPteBase</code>, and so the self-reference entry can be known as: kd> dq nt!MmPteBase l1 fffff804`29e29388 fffff880`00000000 kd> ? (poi(nt!MmPteBase) >> 0n39) & 0x1ff Evaluate expression: 497 = 00000000`000001f1 </code></pre> In our current KD session on a Windows 2004 (on Hyper-V), the self-reference entry has the index of 0x1f1. So now we have the PML4 index, we can craft the virtual address to get its physical address: calculate the PTE VA</li> </ul> kd> ? 0xffff<<0n48 | 0x1f1<<0n39 | 0x1f1<<0n30 | 0x1f1<<0n21 | 0x1f1<<0n12 | 000 Evaluate expression: -7711643201536 = fffff8fc`7e3f1000 </code></pre> get the entry info</li> </ul> kd> !pte 0xfffff8fc7e3f1000 @$pte(0xfffff8fc7e3f1000) : VA=0xfffff8fc7e3f1000, PA=0x4c7d1000, Offset=0x0 va : -7711643201536 cr3 : 0x4c7d1000 pml4e_offset : 0x1f1 pdpe_offset : 0x1f1 pde_offset : 0x1f1 pte_offset : 0x1f1 offset : 0x0 pml4e : PDE(PA=4c7d1000, PFN=4c7d1, Flags=PRwK--AD-eX) pdpe : PDE(PA=4c7d1000, PFN=4c7d1, Flags=PRwK--AD-eX) pde : PDE(PA=4c7d1000, PFN=4c7d1, Flags=PRwK--AD-eX) pte : PTE(PA=4c7d1000, PFN=4c7d1, Flags=PRwK--AD-eX) pa : 0x4c7d1000 kernel_pxe : 0xfffff8fc7e3f1f88 </code></pre> As we see, for each entry (PML4E, PDPTE, etc.) the base address found is always the same and matches the content of CR3</code>. We can also easily prove this is the self-reference entry index: as stated above, the entry index (in our example 0x1f1) has to be the same for all processes, meaning that if we break into another process context, the kernel PXE will be the same. Let’s try with our int3.exe</code> again: Break instruction exception - code 80000003 (first chance) 0033:00007ff6`2ac36d08 cc int 3 kd> !pte 0xfffff8fc7e3f1000 @$pte(0xfffff8fc7e3f1000) : VA=0xfffff8fc7e3f1000, PA=0x1b1f7000, Offset=0x0 va : -7711643201536 cr3 : 0x1b1f7000 pml4e_offset : 0x1f1 pdpe_offset : 0x1f1 pde_offset : 0x1f1 pte_offset : 0x1f1 offset : 0x0 pml4e : PDE(PA=1b1f7000, PFN=1b1f7, Flags=PRwK--AD-eX) pdpe : PDE(PA=1b1f7000, PFN=1b1f7, Flags=PRwK--AD-eX) pde : PDE(PA=1b1f7000, PFN=1b1f7, Flags=PRwK--AD-eX) pte : PTE(PA=1b1f7000, PFN=1b1f7, Flags=PRwK--AD-eX) pa : 0x1b1f7000 kernel_pxe : 0xfffff8fc7e3f1f88 </code></pre> And to confirm the VA points to the correct PA: kd> db 0xfffff8fc7e3f1000 fffff8fc`7e3f1000 67 28 16 62 00 00 00 8a-67 58 c8 11 00 00 00 8a g(.b....gX...... fffff8fc`7e3f1010 00 00 00 00 00 00 00 00-67 f8 40 77 00 00 00 8a ........g.@w.... kd> !db 0x1b1f7000 l20 #1b1f7000 67 28 16 62 00 00 00 8a-67 58 c8 11 00 00 00 8a g(.b....gX...... #1b1f7010 00 00 00 00 00 00 00 00-67 f8 40 77 00 00 00 8a ........g.@w.... </code></pre> Same data, the VA to PA conversion was successful, and the recursive page entries always point to the same PML4 table, at the physical address 0x1b1f7000. It all goes full circle, pretty nice. Last, one can ask: is there any kind of randomization of the allocation of the physical pages themselves? Legit question, and I experimented using some LINQ querying: kd> dx -g @$cursession.Processes.Select( p => new { ProcessName = p.Name, Pml4Base = p.KernelObject.Pcb.DirectoryTableBase & 0xfffffffffff000}) </code></pre> Across several reboots in my VM labs, only 2 matches are shown consistently Windows 2004 x64 Generation 1 (i.e. BIOS)</li> </ul> PID</th> Process Name</th> Pml4Base</th></tr></thead> 0x0</td> Idle</td> 0x1aa000</td></tr> 0x4</td> System</td> 0x1aa000</td></tr> </tbody></table> Windows 2004 x64 Generation 2 (i.e. UEFI)</li> </ul> PID</th> Process Name</th> Pml4Base</th></tr></thead> 0x0</td> Idle</td> 0x6d4000</td></tr> 0x4</td> System</td> 0x6d4000</td></tr> </tbody></table> 0x1aa000 for the physical address of a Gen1 (BIOS) Hyper-V VM, and 0x6d4000 for a Gen2 (UEFI). This seems to partially coincide with what was said in Ricerca’s article (see #1</a>) about the fact that the PML4 for System is at unrandomized physical address in most cases. From my limited testing the following physical addresses were found consistently (for Windows 2004 x64 with Kd): Platform</th> PML4 Base</th></tr></thead> Native (UEFI)</td> 0x1ba000</td></tr> Hyper-V Gen1 (BIOS)</td> 0x1aa000</td></tr> Hyper-V Gen2 (UEFI)</td> 0x6d4000</td></tr> VirtualBox (BIOS)</td> 0x1aa000</td></tr> VirtualBox (UEFI)</td> 0x1ad000</td></tr> </tbody></table> if you have other values on your environment (Qemu, VMware), feel free to contact me and I’ll update the table with the result of the KD command </div> dx @$cursession.Processes.Where( p => p.Name == "System").First().KernelObject.Pcb.DirectoryTableBase & ~0xfff </code></pre> And this is really the subtlety of Ricerca’s exploit: they showed that only with a fixed physical address (associated to the SYSTEM process), and a fixed virtual area (the nt!_KUSER_SHARED_DATA</code> section at 0xfffff780`00000000) that is always at a known location since NT4, one can create an MDL</abbr> used in Direct Memory Access, and achieve arbitrary read to virtual addresses simply by recursing through the PML4E, the PDPTE, etc. just like the MDL</abbr> does. Since they could read the PML4 entirely at a fixed physical address, say 0x1aa000, they could determine the index of the “Self-Reference Entry” from a simple for-loop going through the PML4 page (very approximate pseudo-code): system_pml4_root = 0x1aa000 size_of_page = 0x1000 size_of_entry = 8 # loop in the PML4 for index in range(system_pml4_root, system_pml4_root+size_of_page, size_of_entry): # get the entry entry = u64( read_physical_memory(index) ) # compare to the root (after trimming the 12 lsb) if (entry >> 12) == (system_pml4_root >> 12): print("self-reference entry is at index: %d" % index) </code></pre> I hope not to make it sound simple, it is not and took me quite some time to figure out, so massive props to @hugeh0ge`](https://twitter.com/hugeh0ge) and [`@_N4NU_</code> </a> for the implementation. This technique provides a somewhat reliable way to defeat KASLR, SMEP & SMAP with no other vulnerability, but by mere knowledge of Intel processors and Windows memory management inner workings, for the vulnerability CVE-2020-0796, which, due to Microsoft’s effort, made it tough. Thanks for reading…✌ Update: A @$selfref()</code> function was added to PageExplorer.js</code>, allowing to easily retrieve the PML4 self-reference (tested 8 -> 11) 0: kd> dx @$selfref() @$selfref() : 0x1ec 0: kd> dx @$ptview().pml4_table[ @$selfref() ].PhysicalPageAddress == @$ptview().pml4_table[ @$selfref() ].Children[ @$selfref() ].PhysicalPageAddress @$ptview().pml4_table[ @$selfref() ].PhysicalPageAddress == @$ptview().pml4_table[ @$selfref() ].Children[ @$selfref() ].PhysicalPageAddress : true 0: kd> dx @$ptview().pml4_table[ @$selfref() ] @$ptview().pml4_table[ @$selfref() ] : PML4 Entry(PA=7d5000, Flags=[P RW K - - A D - -]) address : 0x7d5f60 value : 0x80000000007d5063 Flags : Flags=[P RW K - - A D - -] PageFrameNumber : 0x7d5 Pfn [Type: _MMPFN] PhysicalPageAddress : 0x7d5000 Pte : 0xfffff67b3d9ecf60 [Type: _MMPTE *] Level : PML4 Children </code></pre> Links</h1> What started picking my curiosity: [1] Ricerca Security on exploiting the same bug</a></li> [2] Chompie1337’s CVE-2020-0796 exploit</a></li> </ul> The whole series of “ Getting Physical: Extreme abuse of Intel based Paging Systems“ by N. Economou & E. Nissim (CoreSecurity) is a must read/watch: CoreSecurity Getting Physical: The talk (es)</a> // The slides</a></li> Part 2 - Windows</a></li> Part 3 - Windows HAL’s Heap</a></li> </ul> Other useful resources: [3] “What Makes It Page? The Windows 7 x64 Virtual Memory Manager” - M. Martignetti</a></li> “Gynvael’s Hacking Livestream #30: Windows Kernel Debugging Part III” - A. “honorary_bot” Shishkin</a></li> “Windows 8 Kernel Memory Protections Bypass” - J. Fetiveau</a></li> </ul> Enumerating processes from KD 2020-05-23T00:00:00+00:00 This is tiny Post-It post to remind of different ways to enumerate processes from KD: using nt!PsActiveProcessHead</code></li> </ul> dx Debugger.Utility.Collections.FromListEntry( *(nt!_LIST_ENTRY*)&(nt!PsActiveProcessHead), "nt!_EPROCESS", "ActiveProcessLinks") </code></pre> using afd!AfdEndpointListHead</code></li> </ul> dx Debugger.Utility.Collections.FromListEntry( *(nt!_LIST_ENTRY*)&(afd!AfdEndpointListHead), "nt!_EPROCESS", "ActiveProcessLinks") </code></pre> using nt!KiProcessListHead</code></li> </ul> dx Debugger.Utility.Collections.FromListEntry( *(nt!_LIST_ENTRY*)&(nt!KiProcessListHead), "nt!_KPROCESS", "ProcessListEntry").Select( p => new {Process = (nt!_EPROCESS*)&p ) </code></pre> using nt!HandleTableListHead</code></li> </ul> dx Debugger.Utility.Collections.FromListEntry(*(nt!_LIST_ENTRY*)&nt!HandleTableListHead, "nt!_HANDLE_TABLE", "HandleTableList").Where(h => h.QuotaProcess != 0).Select( qp => new {Process= qp.QuotaProcess} ) </code></pre> An unexpected logic bug on Win32k 2020-03-09T00:00:00+00:00 The short version</h2> The short version is that there’s a small logic bug in user32!EndTask()</code> which doesn’t really check the HWND</code> handle passed when forcefully killing the process, allowing unprivileged process to BSoD the host by killing the critical process csrss</code>. And as a bonus the PoC code #FitsInATweet: int WinMain(HINSTANCE h, HINSTANCE ins, LPSTR cmd, int nb) { EndTask(GetDesktopWindow(), 0, 1); return 0; } </code></pre> Just compile, run (here on a build 19569.1000 x64) and enjoy: </a> The less short version</h2> Reversing Win32k.sys</code> driver has been my hobby lately mostly to understand it (finally) seriously - if there is such a thing. This is a really small funny logic bug I encountered while reversing it, which I don’t feel too bad disclosing since there is no security exploitability</a> (simply annoying your sysadmin). The juicy part</h3> The legacy function EndTask</a> can be used to forcefully close the specific window whose handle is passed as argument, and free all associated resources. Although deprecated according to the MSDN, it is still callable even on the latest Windows versions. The function user32!EndTask()</code> is merely a wrapper designed to forward some specific messages to the CSRSS</a> via an ALPC, using the exported function ntdll!CsrClientCallServer</code> with the ApiNumber 0x30401. Easily enough, the function takes the handle to the window to shut down. The function operates with the thread’s token, and is unprivileged. Starting playing around, I remembered that GetDesktopWindow()</code> will return a valid handle to the desktop window, but has many interesting properties</a> including that that it is owned by csrss.exe</code>. That can be quickly demonstrated using the following code: int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { char msg[1024]={0,}; HWND hwnd = GetDesktopWindow(); DWORD dwProcessId; GetWindowThreadProcessId(hwnd, &dwProcessId); sprintf(msg, "hwnd=%p pid=%lu\n", hwnd, dwProcessId); MessageBoxA(0,msg,0,MB_OK); return 0; } </code></pre> which will output the PID of CSRSS </a> In turn, CSRSS will consume that message and call winsrvext!SrvEndTask()</code> then winsrvext!EndTask()</code>. In this function, in order to determine the process to terminate csrss</code> will invoke GetWindowThreadProcessId()</code> and will use the found process id value to look into the CSR_PROCESS</code></a> linked list (via csrsrv!CsrRootProcess</code>), and find the CSR_PROCESS</code> structure associated to such PID. From winsrvext.dll</code>: _EndTask ; NTSTATUS __fastcall EndTask(HWND hWnd, int a2) _EndTask _EndTask proc near ; CODE XREF: SrvEndTask+119↓p _EndTask ; DATA XREF: .pdata:000000000001D21C↓o [...] _EndTask+A7 lea rdx, [rsp+120h+dwProcessId] ; lpdwProcessId _EndTask+AC mov rcx, rdi ; hWnd _EndTask+AF call cs:__imp_GetWindowThreadProcessId </code></pre> The bug</h3> And therein lied the bug: as shown above with the small C snippet, the owner of GetDesktopWindow()</code> is csrss</code> itself, therefore the lookup will return the CSR_PROCESS</code> structure of CSRSS</code> (which happens to be the first entry in the CsrRootProcess</code> linked list). Finally, winsrvext!EndTask()</code> will proceed to call ntdll!NtTerminateProcess()</code> passing the handle to the process CSRSS</code>, which has the value (HANDLE)-1</code> (i.e. GetCurrentProcess()</code>). WinDbg can be used to confirm that behavior: 0: kd> dps poi( csrsrv!CsrRootProcess ) 00000218`7d004550 00000000`00000c14 <- CSR_PROCESS.ClientId 00000218`7d004558 00000000`00000c18 00000218`7d004560 00000218`7d008bf0 <- CSR_PROCESS.LinkList 00000218`7d004568 00000218`7d04b3a0 <- CSR_PROCESS.ThreadList 00000218`7d004570 00000218`7d005368 [...] 00000218`7d004578 00000218`7d0486b8 00000218`7d004580 00000000`00000000 00000218`7d004588 00000000`00000000 00000218`7d004590 00000000`00000000 00000218`7d004598 00000000`00000000 00000218`7d0045a0 ffffffff`ffffffff <<- CSR_PROCESS.ProcessHandle (i.e. value passed to NtTerminateProcess) 00000218`7d0045a8 00000040`00000005 [...] </code></pre> Therefore, this will make CSRSS</code> killing itself when invoking calling the syscall nt!NtTerminateProcess(GetCurrentProcess(), 0 )</code>. As a critical process, killing CSRSS will immediately result in a BSoD, which BugCheck clearly shows. Also note that this crash can be triggered by any user even with any privilege. In WinDbg the faulting stack trace of our BSoD retraces exactly everything we show: CRITICAL_PROCESS_DIED (ef) A critical system process died [...] Arguments: Arg1: ffffe30f47ce14c0, Process object or thread object Arg2: 0000000000000000, If this is 0, a process died. If this is 1, a thread died. [...] STACK_TEXT: ffff8803`2a71f280 fffff801`795c75c1 : [...] : nt!PspCatchCriticalBreak+0xa9 ffff8803`2a71f320 fffff801`79439fc0 : [...] : nt!PspTerminateAllThreads+0x175e3d ffff8803`2a71f390 fffff801`79439da9 : [...] : nt!PspTerminateProcess+0xe0 ffff8803`2a71f3d0 fffff801`78fd2d15 : [...] : nt!NtTerminateProcess+0xa9 ffff8803`2a71f440 00007ff9`83b5c644 : [...] : nt!KiSystemServiceCopyEnd+0x25 000000b6`d35befd8 00007ff9`809066e5 : [...] : ntdll!NtTerminateProcess+0x14 000000b6`d35befe0 00007ff9`80906bae : [...] : winsrvext!EndTask+0x235 000000b6`d35bf110 00007ff9`80975af4 : [...] : winsrvext!SrvEndTask+0x11e 000000b6`d35bf380 00007ff9`83b2cedf : [...] : CSRSRV!CsrApiRequestThread+0x484 000000b6`d35bf810 00000000`00000000 : [...] : ntdll!RtlUserThreadStart+0x2f </code></pre> Final words</h2> This was a good lesson, mostly because I would never have thought finding a (cheap) logic bug in an API that is around for decades and probably gleaned at many times by people way smarter. Also, I’ve reported more Win32k bugs to MS which I’ll be writing up on soon. That’s all for this quick post! ✌ Disclosure timeline</h2> 2019-12-09 : Bug found</li> 2020-02-08 : Finally found some time to do some analysis</li> 2020-02-09 : Issue submitted to MSRC (case 56511)</li> 2020-03-04 : EWONTFIX</li> </ul> Small dumps in the big pool 2019-03-17T00:00:00+00:00 Or, on how to use the (Windows 10) new field _ETHREAD.ThreadName</code> to stabilize kernel RW primitives SetThreadDescription() as a way to allocate controlled kernel pools</h2> Keeping on with experimenting with Windows 10 I noticed a field part of the nt!_ETHREAD</code> structure, called ThreadName</code>. For a minute, the field name misled me to think threads were now Named Objects</a> on Windows. What it is instead, is a convenient and native way to name a thread, any thread by attaching a UNICODE_STRING</code> structure to it. Thanks to @PetrBenes</code> </a> ’s invaluable ntdiff</code></a> it became clear that this field was introduced with Windows 10, more specifically 1607. </a> Source</a> So how to use it? Is it even reachable? The answer was as immediate as Googling “windows set thread name”</a> which leads to an MSDN article</a>. This article mentions the SetThreadDescription()</code></a> in processthreadsapi.h</code>. Disassembling kernelbase.dll</code> shows that this function is merely a wrapper around the syscall NtSetInformationThread()</code> with a ThreadInformationClass</code> set to 0x26 (ThreadNameInformation</code>). </a> Once in ntoskrnl</code> (IDA), the syscall performs various checks (is the _ETHREAD.ThreadName</code> already allocated, is the input size and buffer correct etc.), and then call ExAllocatePoolWithTag()</code> with a tag of ThNm</code> and as NonPagedPoolNx</code>, and the size provided by the UNICODE_STRING</code> structure, plus sizeof(UNICODE_STRING)</code>. Finally, the user buffer will be memmove</code>-ed into this new pool. </a> Since the unicode buffer and its size are fully user controlled, this means that the syscall NtSetInformationThread(0x26)</code> provides a way to allocate an arbitrary sized pool in the kernel, for each thread we create and/or can open a handle to via OpenThread()</code>. The code was tested on Windows 10 RS5 x64. To work on 32b one might need to adjust the offsets. Also Windows must be at least 1607. </div> The following code is enough to populate the _ETHREAD.ThreadName</code> of a designed thread:

Quick lib peek</h2>
This part is important as none of what follows would have been possible without those libraries, it is only fair to promote them first.</p>

Enumerating processes from KD

An unexpected logic bug on Win32k

Disclosure timeline</h2>

2019-12-09 : Bug found</li>
2020-02-08 : Finally found some time to do some analysis</li>
2020-02-09 : Issue submitted to MSRC (case 56511)</li>
2020-03-04 : EWONTFIX</li> </ul>

Small dumps in the big pool

BlahCats Blog

Tapping into the potential of Memory Dump Emulation

Section Objects as Kernel/User communication mode

Install Hyper-V & Sandbox on Windows 10/11 Home

WinDbgX undocumented workspace options

Setup KDCOM for 2 Hyper-V VMs

Browsing the registry in kernel-mode

Cheap sandboxing with AppContainers

Some toying with the Self-Reference PML4 Entry

BlahCats Blog

Tapping into the potential of Memory Dump Emulation

Quick lib peek</h2> This part is important as none of what follows would have been possible without those libraries, it is only fair to promote them first.</p>

References</h2> Here are the links to those giants referred in the title:</p>

Section Objects as Kernel/User communication mode

Install Hyper-V & Sandbox on Windows 10/11 Home

WinDbgX undocumented workspace options

Workspaces</h2> WinDbgX workspaces (suffixed .debugTargets</code>) are nothing more than XML files that instructs WinDbgX how to process with the current debugging session. Saved workspaces can be found in %LOCALAPPDATA%\DBG\Targets</code></p>

Attach (and auto-elevate) a service by Name</h3> Here with CryptSvc</code>. Also make the border red so we can find the window easily!</p>

Setup KDCOM for 2 Hyper-V VMs

Debugger</h2> Still on a privileged prompt on the host, choose a COM port number and connect it to the same pipe:</p>

Browsing the registry in kernel-mode

Cheap sandboxing with AppContainers

Background</h2> This is a short blog post that I decided to finish recently after looking for a way to sandbox Win32 apps, but lazy as I am, I wanted something that</p>

Some toying with the Self-Reference PML4 Entry

Enumerating processes from KD

An unexpected logic bug on Win32k

Disclosure timeline</h2> 2019-12-09 : Bug found</li> 2020-02-08 : Finally found some time to do some analysis</li> 2020-02-09 : Issue submitted to MSRC (case 56511)</li> 2020-03-04 : EWONTFIX</li> </ul>

Small dumps in the big pool

Quick lib peek</h2>
This part is important as none of what follows would have been possible without those libraries, it is only fair to promote them first.</p>

Disclosure timeline</h2>

2019-12-09 : Bug found</li>
2020-02-08 : Finally found some time to do some analysis</li>
2020-02-09 : Issue submitted to MSRC (case 56511)</li>
2020-03-04 : EWONTFIX</li> </ul>