OpenRCE Blog Entry

Nagareshwar (tnagareshwar) <tnagareshwar

gmail

com>

Sunday, August 26 2007 06:48.43 CDT

ProcHeapViewer is a fast heap enumeration tool which uses better technique than normal Windows heap API functions. Its very useful tool for anyone involved in analyzing process heaps. Vulnerability researchers can find it useful while working on heap related vulnerabilities.

Traditional Windows heap enumeration functions are slower and takes lot of time while traversing large number of heap blocks. Here is the article which uncovers the reason behind the slower functionality of heap functions. It also explains new efficient way of enumerating process heaps based on reverse engineering of Windows heap API functions.

You can read more interesting details about ProcHeapViewer at following location.
http://securityxploded.com/ProcHeapViewer.php

Note that currently ProcHeapViewer source code is not public, but I am planning to make it public after the second release. I have already got couple of feature requests for this tool. If you have any, then let me know.

Thanks

- Nag

nicowow	Posted: Sunday, August 26 2007 09:06.02 CDT
Nice work man! Our way to do it, is directly using the reversed structures of the heap and list the chunk (aka get the Heap from the PEB, Grab the segments from the PHEAP structure, and transverse the chunks directly by their size)

tnagareshwar	Posted: Sunday, August 26 2007 11:40.12 CDT
Thanks for the new way...I will explore more in that direction

nicowow	Posted: Sunday, August 26 2007 22:04.51 CDT
You can take a look at Immunity Debugger check Libs/libheap.py Here you have our source code (Although, written in python) Cheers

tnagareshwar	Posted: Monday, August 27 2007 00:08.39 CDT
Thanks nicowow, that will be useful.

djnemo	Posted: Monday, August 27 2007 00:54.52 CDT
Thanks about useful tools ,gr8 ,befor you wana release your source code ;may i have some information about how get PEB and Heap Detail (^-^) Soem library or Api mybe you use or ...

nicowow Posted: Monday, August 27 2007 06:32.37 CDT

To get the PEB is easy:



mov eax, fs:[18]

mov eax, [eax+30]    // NOW eax point to the PEB

Now, to get all the heaps from the PEB you go:



mov  ecx, [eax+0x90]  // List of Heaps

mov  edx, [eax+0x88]  // Number of heaps

To do it in C:



(FARPROC) nqip  = GetProcAddress(ntdll,"NtQueryInformationProcess");

 nqip(hp, 0, &info,

           sizeof(PROCESS_BASIC_INFORMATION), &retlen);

 // On the info structure, you grab the PEB like

 info.PebBaseAddress

Cheers

djnemo	Posted: Tuesday, August 28 2007 02:49.59 CDT
TanX dear nicowow it helps so much ,and Special Tanx to tnagareshwar for his good tools and UseFull article

MohammadHosein	Posted: Tuesday, August 28 2007 07:00.16 CDT
on newer windows PEB is no longer located there , its location is randomized

anonymouse	Posted: Tuesday, August 28 2007 12:45.50 CDT
on newer windows PEB is no longer located there , its location is randomized where ? it is still located there but you cannot hardcode the address viz 7ffd0030 iinw what he proposes is finding peb with NtQueryInformation##() not hardcoding 7fffd0030 which used to be the case [url] https://www.openrce.org/blog/view/44/finding_the_peb_of_other_process_in_xp-sp2 [/url]

tnagareshwar	Posted: Tuesday, August 28 2007 13:10.25 CDT
Hi Djnemo, Here is the article which explains the reason and research behind the ProcHeapViewer. http://securityxploded.com/enumheaps.php For the PEB, the method suggested by nicowow is right way to get it even though it randomized. Have a good day

anonymouse Posted: Thursday, September 13 2007 05:35.56 CDT

is it able to enumerate process heaps of application that are spawned under a debugger ??

this always hangs for me with a hung application

here is a minidump details and !analyze -v results from windbg





Microsoft (R) Windows Debugger  Version 6.7.0005.0

Copyright (c) Microsoft Corporation. All rights reserved.





Loading Dump File [C:\ProcHeapViewer.exe.mdmp]

User Mini Dump File: Only registers, stack and portions of memory are available



Symbol search path is: srv*d:\symbols*http://msdl.microsoft.com/download/symbols

Executable search path is: 

Windows XP Version 2600 (Service Pack 1) UP Free x86 compatible

Product: WinNt, suite: SingleUserTS

Debug session time: Thu Sep 13 15:47:38.000 2007 (GMT+5)

System Uptime: not available

Process Uptime: 0 days 0:00:20.000

...............

This dump file has an exception of interest stored in it.

The stored exception information can be accessed via .ecxr.

(c94.c98): Application hang - code cfffffff (first/second chance not available)

eax=0012dad8 ebx=00000000 ecx=00000060 edx=00000000 esi=00980000 edi=00000000

eip=7ffe0304 esp=0012da64 ebp=0012dac8 iopl=0         nv up ei pl nz na po nc

cs=001b  ss=0023  ds=0023  es=0023  fs=0038  gs=0000             efl=00000202

SharedUserData!SystemCallStub+0x4:

7ffe0304 c3              ret

0:000> !analyze -v

*******************************************************************************

*                                                                             *

*                        Exception Analysis                                   *

*                                                                             *

*******************************************************************************



*** ERROR: Module load completed but symbols could not be loaded for ProcHeapViewer.exe



FAULTING_IP: 

SharedUserData!SystemCallStub+4

7ffe0304 c3              ret



EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)

ExceptionAddress: 7ffe0304 (SharedUserData!SystemCallStub+0x00000004)

   ExceptionCode: cfffffff (Application hang)

  ExceptionFlags: 00000000

NumberParameters: 0



BUGCHECK_STR:  HANG



DEFAULT_BUCKET_ID:  APPLICATION_HANG



PROCESS_NAME:  ProcHeapViewer.exe



ERROR_CODE: (NTSTATUS) 0xcfffffff - <Unable to get error code text>



DERIVED_WAIT_CHAIN:  



Dl Eid Cid     WaitType

-- --- ------- --------------------------

   0   c94.c98 Unknown                



WAIT_CHAIN_COMMAND:  ~0s;k;;



UNRESPONSIVE_UI_THREAD:  00000c98



UNRESPONSIVE_UI_PROBLEM_CLASS:  UI_HANG



BLOCKING_THREAD:  00000c98



PRIMARY_PROBLEM_CLASS:  APPLICATION_HANG



LAST_CONTROL_TRANSFER:  from 77f7671a to 7ffe0304



UNRESPONSIVE_UI_SYMBOL_NAME:  ProcHeapViewer



UNRESPONSIVE_UI_FOLLOWUP_NAME:  MachineOwner



FAULTING_THREAD:  00000c98



STACK_TEXT:  

0012da60 77f7671a 77f7f417 00000068 00000001 SharedUserData!SystemCallStub+0x4

0012da64 77f7f417 00000068 00000001 00000000 ntdll!NtWaitForSingleObject+0xc

0012dac8 004029c2 00000060 00000014 00000068 ntdll!RtlQueryProcessDebugInformation+0x15a

WARNING: Stack unwind information not available. Following frames may be wrong.

0012f7a0 00000000 00000000 00000000 00000000 ProcHeapViewer+0x29c2





FOLLOWUP_IP: 

ProcHeapViewer+29c2

004029c2 85c0            test    eax,eax



SYMBOL_STACK_INDEX:  3



FOLLOWUP_NAME:  MachineOwner



MODULE_NAME: ProcHeapViewer



IMAGE_NAME:  ProcHeapViewer.exe



DEBUG_FLR_IMAGE_TIMESTAMP:  4654e7e2



SYMBOL_NAME:  ProcHeapViewer+29c2



STACK_COMMAND:  ~0s ; kb



FAILURE_BUCKET_ID:  HANG_ProcHeapViewer+29c2



BUCKET_ID:  HANG_ProcHeapViewer+29c2



Followup: MachineOwner

---------

disassembly of where it probably hangs is here



0:000> ub 004029c2

ProcHeapViewer+0x29a8:

004029a8 33c0            xor     eax,eax

004029aa e9ab010000      jmp     ProcHeapViewer+0x2b5a (00402b5a)

004029af 8bb424b0130000  mov     esi,dword ptr [esp+13B0h]

004029b6 8b8d5c070000    mov     ecx,dword ptr [ebp+75Ch]

004029bc 53              push    ebx

004029bd 6a14            push    14h

004029bf 56              push    esi

004029c0 ffd1            call    ecx  <-------

0:000> u 004029c2

ProcHeapViewer+0x29c2:

004029c2 85c0            test    eax,eax

004029c4 7442            je      ProcHeapViewer+0x2a08 (00402a08)

004029c6 8b955c070000    mov     edx,dword ptr [ebp+75Ch]

004029cc 53              push    ebx

004029cd 6a04            push    4

004029cf 56              push    esi

004029d0 ffd2            call    edx

004029d2 85c0            test    eax,eax

tnagareshwar	Posted: Monday, September 17 2007 07:58.59 CDT
This scenario is not tested. I will look into this problem. Thanks for posting full details. That will help.