0

I can see in the windbg disassembly the handle to the process heap on, allocated by the Windows (WINDOWS 10) for my process:

0:000> dt nt!_PEB 0106c000
ntdll!_PEB
   +0x000 InheritedAddressSpace : 0 ''
   +0x001 ReadImageFileExecOptions : 0 ''
   +0x002 BeingDebugged    : 0x1 ''
   +0x003 BitField         : 0x4 ''
   +0x003 ImageUsesLargePages : 0y0
   +0x003 IsProtectedProcess : 0y0
   +0x003 IsImageDynamicallyRelocated : 0y1
   +0x003 SkipPatchingUser32Forwarders : 0y0
   +0x003 IsPackagedProcess : 0y0
   +0x003 IsAppContainer   : 0y0
   +0x003 IsProtectedProcessLight : 0y0
   +0x003 IsLongPathAwareProcess : 0y0
   +0x004 Mutant           : 0xffffffff Void
   +0x008 ImageBaseAddress : 0x00840000 Void
   +0x00c Ldr              : 0x77a4ebe0 _PEB_LDR_DATA
   +0x010 ProcessParameters : 0x03b885e0 _RTL_USER_PROCESS_PARAMETERS
   +0x014 SubSystemData    : (null) 
   +0x018 ProcessHeap      : 0x03b70000 Void

Now i want to examine the heap header, and apply the dt !_HEAP to the ProcessHeap : 0x03b70000, but i can see that i get totaly invalid data in result. !heap -s gives me totally different results for the heap,

LFH Key                   : 0xd5ec6951
Termination on corruption : ENABLED
  Heap     Flags   Reserv  Commit  Virt   Free  List   UCR  Virt  Lock  Fast 
                    (k)     (k)    (k)     (k) length      blocks cont. heap 
-----------------------------------------------------------------------------
05e90000 00000002    1020      4   1020      2     1     1    0      0      
00ff0000 00001002      60      4     60      2     1     1    0      0     

I understand, that the address where the heap header starts must be calculated from this handle, ProcessHeap : 0x03b70000 Void but i don't understand how it is calculated. its not a va, because 00840000 + 03b70000 != 05e90000 , so how to get from the heap handle, to the actual address of _HEAP structure header?

1

this is from win7 but that shouldn't matter much

ProcessHeap From Peb of current Process

0:000> dt ntdll!_PEB ProcessHeap @$proc 
   +0x018 ProcessHeap : 0x00430000 Void

heap Stat For the same

0:000> !heap -s @$proc->ProcessHeap


****************************************************************************
                                              NT HEAP STATS BELOW
****************************************************************************
NtGlobalFlag enables following debugging aids for new heaps:
    tail checking
    free checking
    validate parameters
LFH Key                   : 0x20cb0363
Termination on corruption : ENABLED
  Heap     Flags   Reserv  Commit  Virt   Free  List   UCR  Virt  Lock  Fast 
                    (k)     (k)    (k)     (k) length      blocks cont. heap 
-----------------------------------------------------------------------------
00430000 40000062    1024     24   1024      3     7     1    0      0      
00010000 40008060      64      4     64      2     1     1    0      0      
-----------------------------------------------------------------------------

HeapEntryStructure

0:000> dt nt!_Heap Entry.* @@(@$proc->ProcessHeap)
ntdll!_HEAP
   +0x000 Entry  : 
      +0x000 Size   : 0xda5a
      +0x002 Flags  : 0x5b '['
      +0x003 SmallTagIndex : 0xa9 ''
      +0x000 SubSegmentCode : 0xa95bda5a Void
      +0x004 PreviousSize : 0x2d79
      +0x006 SegmentOffset : 0 ''
      +0x006 LFHFlags : 0 ''
      +0x007 UnusedBytes : 0x1 ''
      +0x000 FunctionIndex : 0xda5a
      +0x002 ContextValue : 0xa95b
      +0x000 InterceptorValue : 0xa95bda5a
      +0x004 UnusedBytesLength : 0x2d79
      +0x006 EntryOffset : 0 ''
      +0x007 ExtendedBlockSignature : 0x1 ''
      +0x000 Code1  : 0xa95bda5a
      +0x004 Code2  : 0x2d79
      +0x006 Code3  : 0 ''
      +0x007 Code4  : 0x1 ''
      +0x000 AgregateCode : 0x01002d79`a95bda5a
  • This is really weird... for some reason my heaps doesnt match, i think this is because no CRT is used in application. I just created the default c console application and there is exactly 1 heap by !heap -s @$proc->ProcessHeap which does match dt ntdll!_PEB ProcessHeap @$proc value. So crt does setup the heaps properly.. But isnt the process supposed to have the default heap header already created by the OS? – Vlad Oct 16 '16 at 19:35
  • Nevermind, it was my fault. The Page heap verifier messed with the PEB's heap handle – Vlad Oct 16 '16 at 20:02
0

The problem was due to the Page Heap verification, enabled by Gflags. I forgot about that, and the heap verifier was messing with the heap handles. When i disabled it, the handle at the PEB became valid.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.