Color Buttons

[jj2007]

• delete the font at the end (in WM_DESTROY usually)

Raymond Chen:

The building is being demolished. Don't bother sweeping the floor and emptying the trash cans and erasing the whiteboards

[guga]

Hi HSE

yes, i´m afraid i´ll have to do it on WM_CREATE/WM_INITDIALOG. Somehow windows is changing the font height whenever it calls a msg to WM_GETFONT (call 'USER32.SendMessageA' D@hCtrl, &WM_GETFONT). The original font height is 11 pixels, but after the 2nd time the routine enter on WM_CTLCOLORBTN to colorize other buttons, the font height is changed to 13. Also, the font in the static controls are changed too.

I´ll see what is happenning before trying to put some routines in WM_CREATE/WM_INITDIALOG, because perhaps there are being some changes in WM_FONTCHANGE whenever the gdi handles the font ?

[HSE]

Raymond Chen:

The building is being demolished. Don't bother sweeping the floor and emptying the trash cans and erasing the whiteboards

It's the anti leak protocol to close everything you open

[jj2007]

You close, free or release everything when you no longer need it while the program is running. But there is no need to close anything before calling ExitProcess.

Btw we had a thread over 6 years ago where we launched 1,000 times an application that created 1,000 brushes without freeing them. Test it

[HSE]

Btw we had a thread over 6 years ago where we launched 1,000 times an application that created 1,000 brushes without freeing them. Test it

I follow several thread about same thing, and read the links you post !

But there is no need to close anything before calling ExitProcess.

I know but I think leak detection system don't like that  ( I even remember).
Anyway the API is going to be called by the system.

[guga]

Ok, i succeeded to fix the gdi leaking for the fonts. Now, the font object is deleted on buttons. It does not show on GDIView anylonger.



The only problem is that it works for buttons, only. On static controls, the font  was also messed up.

The font is changed due to a weird behaviour on WM_ACTIVATE. Somehow it increases the height of the font of the controls if we use gdi to paint them and delete the old fonts. The solution was create a new font for each control (with one single function) on WM_CTLCOLORBTN (and probably i´ll have to do the same for WM_CTLCOLORSTATIC).

I don´t know why WM_ACTIVATE behave like that, but it is the cause of the fonts height being messed up.

I´ll clean up the code, fix the same problem for static controls, and restart searching for the other leakings, before posting the result here

[guga]

Oki, guys...

I´m still struggling to understand why it is leaking. I´ll have to do it on the way Steve said, but still it is leaking somewhere.

In the meanwhile i made a routine onto RosAsm debugger to make easier to see those issues and alsso find the exact routine responsible for the leaking or the creation of the object (in RosAsm it should be easier to retrieve the correct label and address of the loaded object, but i didn´t implemented it yet).



It works the same as in GDiView (for 64 Bits, currently . Later i´ll adapt it to make it works on Win32 OS as well. Here i have AMD 64 Bits, so i cannot tests it on my old OS :( )...But...i have a small question concerning this GDIView and the way it get´s the type of objects

I grabbed all the necessary data to see the GDI objects through PE64, reaching the values on NtWow64QueryInformationProcess64 Api inside NTDLL (after adapted RosAsm debugger to work on it). Once i retrieved the PROCESS_BASIC_INFORMATION data, i then passed it through ReadProcessMemory using PEB64 as the parameter of lpBaseAddress member of this Api.

So far, so good. It read the GDITable of PEB64 at PEB64.GdiSharedHandleTable (I updated PEB structure for RosAsm, btw) and i succeeded to get the GDICELL Structure which is formed as:

Code Select Expand


[GDICELL_WOW64:
GDICELL_WOW64.pKernelAddress: Q$ 0
GDICELL_WOW64.wProcessId: W$ 0
GDICELL_WOW64.wCount: W$ 0
GDICELL_WOW64.wUpper: W$ 0
GDICELL_WOW64.wType: W$ 0
GDICELL_WOW64.pUserAddress: Q$ 0]

And the displacement (equates) of the above structure, is:

Code Select Expand


[GDICELL_WOW64.pKernelAddressDis 0
GDICELL_WOW64.wProcessIdDis 8
GDICELL_WOW64.wCountDis 10
GDICELL_WOW64.wUpperDis 12
GDICELL_WOW64.wTypeDis 14
GDICELL_WOW64.pUserAddressDis 16]

[Size_Of_GDICELL_WOW64 24]


To retrieve the handle of the GDI Object and the Type of object all is needed is:

Code Select Expand


            movzx eax W$esi+GDICELL_WOW64.wUpperDis | shl eax 16 | add eax D@iCounter | mov D@GDIHandle eax
            movzx eax W$esi+GDICELL_WOW64.wTypeDis | and eax 07F | mov D@GDIType eax

So, once i succeeded to get the Type, i then created more then 30 different types of GDI Objects to be analyzed, since Brushes, Bitmaps, Fonts (Logical or smaller fonbts etc etc), Colorspaces, directdraw, enhanced metafile, region, clip object, palette, etc etc etc

The problem is.....

On GDIView it displays sometimes extended information of certain types of Objects. For example, when analyzing some Bitmaps it sometimes display it like: "Width: %d, Height: %d, Bits/Pixel: %d"...BUT...it don´t collect the data of all objects that do exists...why is that ???? I mean, once GDIView (and mine) knows that there is a Bitmap object, why it collects info of some of them and other cases it fails miserably ?

I mean, to retrieve the "extended" information GDIView (and mine version) passes the GDiHandle to GetObject Api. So, Once we know the type of object i wrote a function like this:

Code Select Expand



[Size_Of_BITMAP 24]

Proc GDIViewGetBitMapInfo:
    Arguments @GDIHandle, @pOutput
;    Local @NewDC, @NewObject <--- Tried also to create a new DC and select the object trough it, but....nothing happened. Still returning 0
    Structure @BITMAP 24, @BITMAP.bmTypeDis 0, @BITMAP.bmWidthDis 4, @BITMAP.bmHeightDis 8, @BITMAP.bmWidthBytesDis 12, @BITMAP.bmPlanesDis 16, @BITMAP.bmBitsPixelDis 18, @BITMAP.bmBitsDis 20
    Uses edi, ecx, edx

    call 'RosMem.ZeroMemory' D@BITMAP, Size_Of_BITMAP

    call 'GDI32.GetObjectA' D@GDIHandle, Size_Of_BITMAP, D@BITMAP
    On eax = 0, ExitP

    mov edi D@pOutput
    movzx eax W@BITMAP.bmBitsPixelDis
    movzx ecx W@BITMAP.bmPlanesDis
    imul eax ecx
    If eax = 1
        mov eax 1
    Else_If eax <= 4
        mov eax 4
    Else_If eax <= 8
        mov eax 8
    Else_If eax <= 16
        mov eax 16
    Else_If eax <= 24
        mov eax 24
    Else
        mov eax 32
    End_If
    C_call FormatStr edi, {'Width: %d, Height: %d, Bits/Pixel: %d, Format: %d bits', 0}, D@BITMAP.bmWidthDis, D@BITMAP.bmHeightDis, D@BITMAP.bmBitsPixelDis, eax
    add edi eax
    mov B$edi 0

EndP


The main problem is that GetObject constantly returns 0 . In mine version and also in GDIView one. But..why it is returning 0, if we retrieved the GDI Handle of the object ????

Also....is there another way to collect the "extra' info of certain objects directly through one of the PEB structures, rather then using GetObject Api ???


Another question...What is this pUserAddress in GDICELL all about ? It does not seems the same address as it was stored the object inside the App. Someone knows what exactly is this member of the GDICELL structure ?

Note: Later i´ll implement the counter of objects to try seeking for leaking as it have in GDIview, but, i´ll try to see if i can collect the extra info 1st.




Reference of updated PEB/TEB structures in:
http://terminus.rewolf.pl/terminus

Also, more references i used are:

https://codeday.me/es/qa/20190409/458369.html
http://www.siddim.com/archives/7296.html
https://docs.microsoft.com/en-us/previous-versions/bb985767(v=msdn.10)?redirectedfrom=MSDN
http://www.verysource.com/code/5942649_1/PogyGDI.cpp.html
https://docs.microsoft.com/en-us/previous-versions/bb985767(v=msdn.10)?redirectedfrom=MSDN
https://reactos.org/wiki/Techwiki:Win32k/gdiobjects
extended info: https://reactos.org/wiki/Techwiki:Win32k/gdiobjects
https://www.yumpu.com/en/document/read/58026165/lpe-vulnerabilities-exploitation-on-windows-10-anniversary-update/3
https://chromium.googlesource.com/external/github.com/giampaolo/psutil/+/master/psutil/arch/windows/process_info.c
https://wj32.org/processhacker/forums/viewtopic.php?t=181
https://gist.github.com/hasherezade/87158b926e33418f5d3b0a0026d0ccc2
https://chromium.googlesource.com/external/github.com/giampaolo/psutil/+/master/psutil/arch/windows/process_info.c
https://github.com/w4kfu/whook/blob/master/src/include/pestuff.h <-----
from reactOS https://doxygen.reactos.org/df/ddf/ntgdihdl_8h_source.html
https://github.com/sam-b/windows_kernel_address_leaks <----- (GdiSharedHandleTable)
http://bytepointer.com/resources/tebpeb64.htm
http://terminus.rewolf.pl/terminus/structures/ntdll/_PEB_x64.html
https://github.com/securesean/Shim-Process-Scanner/tree/master/Shim-Process-Scanner
http://blog.rewolf.pl/blog/?p=1438#more-1438
https://labs.f-secure.com/archive/a-tale-of-bitmaps/
https://aloiskraus.wordpress.com/2016/06/25/show-gdi-handles-by-type-in-windbg/
https://stackoverflow.com/questions/13905661/how-to-get-list-of-gdi-handles

[guga]

Btw....PEB64 is given like this (Updated to the last Windows 10 version

Code Select Expand


[PEB64:
PEB64.InheritedAddressSpace: B$ 0
PEB64.ReadImageFileExecOptions: B$ 0
PEB64.BeingDebugged: B$ 0
PEB64.SpareBool: B$ 0
PEB64.Padding1: D$ 0
PEB64.Mutant: Q$ 0
PEB64.ImageBaseAddress: Q$ 0
PEB64.LdrData: Q$ 0
PEB64.ProcessParameters: Q$ 0
PEB64.SubSystemData: Q$ 0
PEB64.ProcessHeap: Q$ 0
PEB64.FastPebLock: Q$ 0
PEB64.FastPebLockRoutine: Q$ 0
PEB64.FastPebUnlockRoutine: Q$ 0
PEB64.EnvironmentUpdateCount: Q$ 0
PEB64.KernelCallbackTable: Q$ 0
PEB64.EventLogSection: D$ 0
PEB64.EventLog: D$ 0
PEB64.FreeList: Q$ 0
PEB64.TlsExpansionCounter: Q$ 0
PEB64.TlsBitmap: Q$ 0
PEB64.TlsBitmapBits: D$ 0 #2
PEB64.ReadOnlySharedMemoryBase: Q$ 0
PEB64.ReadOnlySharedMemoryHeap: Q$ 0
PEB64.ReadOnlyStaticServerData: Q$ 0
PEB64.AnsiCodePageData: Q$ 0
PEB64.OemCodePageData: Q$ 0
PEB64.UnicodeCaseTableData: Q$ 0
PEB64.NumberOfProcessors: D$ 0
PEB64.NtGlobalFlag: D$ 0
PEB64.CriticalSectionTimeout: Q$ 0
PEB64.HeapSegmentReserve: Q$ 0
PEB64.HeapSegmentCommit: Q$ 0
PEB64.HeapDeCommitTotalFreeThreshold: Q$ 0
PEB64.HeapDeCommitFreeBlockThreshold: Q$ 0
PEB64.NumberOfHeaps: D$ 0
PEB64.MaximumNumberOfHeaps: D$ 0
PEB64.ProcessHeaps: Q$ 0
PEB64.GdiSharedHandleTable: Q$ 0
PEB64.ProcessStarterHelper: Q$ 0
PEB64.GdiDCAttributeList: Q$ 0
PEB64.LoaderLock: Q$ 0
PEB64.OSMajorVersion: D$ 0
PEB64.OSMinorVersion: D$ 0
PEB64.OSBuildNumber: W$ 0
PEB64.OSCSDVersion: W$ 0
PEB64.OSPlatformId: D$ 0
PEB64.ImageSubSystem: D$ 0
PEB64.ImageSubSystemMajorVersion: D$ 0
PEB64.ImageSubSystemMinorVersion: D$ 0
PEB64.Padding2: D$ 0
PEB64.ImageProcessAffinityMask: Q$ 0
PEB64.GdiHandleBuffer: Q$ 0 #30
PEB64.PostProcessInitRoutine: Q$ 0
PEB64.TlsExpansionBitmap: Q$ 0
PEB64.TlsExpansionBitmapBits: D$ 0 #32
PEB64.SessionId: D$ 0
PEB64.Padding3: D$ 0
PEB64.AppCompatFlags: Q$ 0
PEB64.AppCompatFlagsUser: Q$ 0
PEB64.pShimData: Q$ 0
PEB64.AppCompatInfo: Q$ 0
PEB64.CSDVersion.UnicodeStr64.Length: D$ 0
PEB64.CSDVersion.UnicodeStr64MaximumLength: D$ 0
PEB64.CSDVersion.UnicodeStr64Buffer: Q$ 0
PEB64.ActivationContextData: Q$ 0 ; Points to ACTIVATION_CONTEXT_DATA structure
PEB64.ProcessAssemblyStorageMap: Q$ 0
PEB64.SystemDefaultActivationContextData: Q$ 0 ; Points to ACTIVATION_CONTEXT_DATA structure
PEB64.SystemAssemblyStorageMap: Q$ 0
PEB64.MinimumStackCommit: Q$ 0
PEB64.FlsCallback: Q$ 0
PEB64.FlsListHead.Flink: Q$ 0
PEB64.FlsListHead.Blink: Q$ 0
PEB64.FlsBitmap: Q$ 0
PEB64.FlsBitmapBits: D$ 0 #4
PEB64.FlsHighIndex: Q$ 0
PEB64.WerRegistrationData: Q$ 0
PEB64.WerShipAssertPtr: Q$ 0
PEB64.pContextData: Q$ 0
PEB64.pImageHeaderHash: Q$ 0
PEB64.TracingFlags: D$ 0
PEB64.Padding4: D$ 0
PEB64.CsrServerReadOnlySharedMemoryBase: Q$ 0
PEB64.TppWorkerpListLock: Q$ 0
PEB64.TppWorkerpList.Flink: Q$ 0
PEB64.TppWorkerpList.Blink: Q$ 0
PEB64.WaitOnAddressHashTable: Q$ 0 #128]


and PEB (PEB32) is like:

Code Select Expand


[PEB:
PEB.InheritedAddressSpace: B$ 0
PEB.ReadImageFileExecOptions: B$ 0
PEB.BeingDebugged: B$ 0
PEB.SpareBool: B$ 0
PEB.Mutant: D$ 0
PEB.ImageBaseAddress: D$ 0
PEB.LdrData: D$ 0
PEB.ProcessParameters: D$ 0
PEB.SubSystemData: D$ 0
PEB.ProcessHeap: D$ 0
PEB.FastPebLock: D$ 0
PEB.FastPebLockRoutine: D$ 0
PEB.FastPebUnlockRoutine: D$ 0
PEB.EnvironmentUpdateCount: D$ 0
PEB.KernelCallbackTable: D$ 0
PEB.EventLogSection: D$ 0
PEB.EventLog: D$ 0
PEB.FreeList: D$ 0
PEB.TlsExpansionCounter: D$ 0
PEB.TlsBitmap: D$ 0
PEB.TlsBitmapBits: D$ 0 #2
PEB.ReadOnlySharedMemoryBase: D$ 0
PEB.ReadOnlySharedMemoryHeap: D$ 0
PEB.ReadOnlyStaticServerData: D$ 0
PEB.AnsiCodePageData: D$ 0
PEB.OemCodePageData: D$ 0
PEB.UnicodeCaseTableData: D$ 0
PEB.NumberOfProcessors: D$ 0
PEB.NtGlobalFlag: D$ 0
PEB.Spare2: B$ 0 #4
PEB.CriticalSectionTimeout: Q$ 0
PEB.HeapSegmentReserve: D$ 0
PEB.HeapSegmentCommit: D$ 0
PEB.HeapDeCommitTotalFreeThreshold: D$ 0
PEB.HeapDeCommitFreeBlockThreshold: D$ 0
PEB.NumberOfHeaps: D$ 0
PEB.MaximumNumberOfHeaps: D$ 0
PEB.ProcessHeaps: D$ 0
PEB.GdiSharedHandleTable: D$ 0
PEB.ProcessStarterHelper: D$ 0
PEB.GdiDCAttributeList: D$ 0
PEB.LoaderLock: D$ 0
PEB.OSMajorVersion: D$ 0
PEB.OSMinorVersion: D$ 0
PEB.OSBuildNumber: W$ 0
PEB.OSCSDVersion: W$ 0
PEB.OSPlatformId: D$ 0
PEB.ImageSubSystem: D$ 0
PEB.ImageSubSystemMajorVersion: D$ 0
PEB.ImageSubSystemMinorVersion: D$ 0
PEB.ImageProcessAffinityMask: D$ 0
PEB.GdiDBuffer: D$ 0 #34
PEB.PostProcessInitRoutine: D$ 0
PEB.TlsExpansionBitmap: D$ 0
PEB.TlsExpansionBitmapBits: D$ 0 #32
PEB.SessionId: D$ 0
PEB.AppCompatFlags: Q$ 0
PEB.AppCompatFlagsUser: Q$ 0
PEB.pShimData: D$ 0
PEB.AppCompatInfo: D$ 0
PEB.CSDVersion.UnicodeStr64.Length: W$ 0
PEB.CSDVersion.UnicodeStr64MaximumLength: W$ 0
PEB.CSDVersion.UnicodeStr64Buffer: D$ 0
PEB.ActivationContextData: D$ 0
PEB.ProcessAssemblyStorageMap: D$ 0
PEB.SystemDefaultActivationContextData: D$ 0
PEB.SystemAssemblyStorageMap: D$ 0
PEB.MinimumStackCommit: D$ 0
PEB.FlsCallback: D$ 0
PEB.FlsListHead.Flink: D$ 0
PEB.FlsListHead.Blink: D$ 0
PEB.FlsBitmap: D$ 0
PEB.FlsBitmapBits: D$ 0 #4
PEB.FlsHighIndex: D$ 0
PEB.WerRegistrationData: D$ 0
PEB.WerShipAssertPtr: D$ 0
PEB.pContextData: D$ 0
PEB.pImageHeaderHash: D$ 0
PEB.TracingFlags: D$ 0
PEB.Padding4: D$ 0
PEB.CsrServerReadOnlySharedMemoryBase: Q$ 0
PEB.TppWorkerpListLock: D$ 0
PEB.TppWorkerpList.Flink: D$ 0
PEB.TppWorkerpList.Blink: D$ 0
PEB.WaitOnAddressHashTable: D$ 0 #128]



[guga]

Ok, guys...managed to make RosAsm GDIView work to display some window info. Missing to understand how to do the same for other type of objects