Windows Defender Exploit Protection affecting callbacks?

Is anyone aware of any Windows Defender Exploit Protection (all settings on except ASLR for the program so it can be debugged by the clarion debugger) affecting callbacks like EnumWindow or EnumDesktopWindows, the problem I’m seeing is the lParam isnt being passed into the callback procedure EnumWindowsProc and what I get is a value looking like a hWnd being passed to the EnumWindowsProcCallBackProcedure.

My thinking is the callback procedure is probably in some windows context and not my app context so maybe there are is/are some security restrictions I need to account for, changing the manifest elevation from asInvoker to highestAvailable doesnt change anything.

EnumWindows function (winuser.h) - Win32 apps | Microsoft Docs
EnumDesktopWindows function (winuser.h) - Win32 apps | Microsoft Docs
EnumWindowsProc callback function (Windows) | Microsoft Docs

EnumWindowsProcCallBackProcedure         Procedure(Long hWnd,Long lParam),Bool

Loc:EnumWindowsProcCallBackProcedureAddress     = Address(EnumWindowsProcCallBackProcedure)`

    Loc:ReturnValueBool     = IS_EnumDesktopWindows(0,|

Loc:ReturnValueBool     = IS_EnumWindows(   Loc:EnumWindowsProcCallBackProcedureAddress,|

EnumWindowsProcCallBackProcedure     Procedure(Long hWnd,Long lParam) 
!Some code
!Some DebugView Strings
Return 1

So it doesnt matter if a I pass a value (Loc:hProcessID) in the Long lParam or a valid memory address (Loc:lphProcessID),

Loc:hProcessID      = Loc:ProcessInformation.hProcess
IS_DebugView('Loc:hProcessID =' & Loc:hProcessID)
Loc:lphProcessID    = Address(Loc:hProcessID)
IS_DebugView('Loc:lphProcessID =' & Loc:lphProcessID)

all I get from the call back procedure lParam is an incrementing index starting at 0.

Debugview snapshot

[6140] 28/03/2022,10:27:38,Thread:2,Library,Library073.clw,RunProcess,Loc:hProcessID =1100
[6140] 28/03/2022,10:27:38,Thread:2,Library,Library073.clw,RunProcess,Loc:lphProcessID =91422304
[6140] 28/03/2022,10:27:38,Thread:2,Library,Library001.clw,Main,20271584,0 : 0,20271584,91421672
[6140] 28/03/2022,10:27:38,Thread:2,Library,Library001.clw,Main,20223248,1 : 0,20223248,91421664
[6140] 28/03/2022,10:27:38,Thread:2,Library,Library001.clw,Main,20242320,2 : 0,20242320,91421656
[6140] 28/03/2022,10:27:38,Thread:2,Library,Library001.clw,Main,20239488,3 : 0,20239488,91421648

Main is the global debugview procedure being called from EnumWindowsProcCallBackProcedure

The debugview values are

Callback params        : GetWindowThreadProcessID params 
hWnd,     lParam       : ThreadIdentifier, hWnd,              lpProcessID
20271584, 0            :  0,               20271584,          91421672

GetWindowThreadProcessId function (winuser.h) - Win32 apps | Microsoft Docs
is being used inside EnumWindowsProcCallBackProcedure

This is why I’m wondering if its exploit protection, havent seen any mention of the lParam returning an index number in the docs and it doesnt matter if lparam is a value or a genuine memory address it just returns an incrementing index number, but I dont even know if MS can check if lParam is a genuine memory address internally.

So I checked the clarion app/exe I’m working on in the Windows Exploit Protection override list and it turns out I had all exploit protection settings switched off for this clarion app so its currently looking like its a windows security/access rights restriction with the call back procedures EnumDesktopWindows and EnumWindows.

Changing the manifest from asInvoker (basic user) to highestAvailable (UAC popup) or requireAdministrator (UAC popup) doesnt seem to matter with these two call back procedures.

Bit concerned at this stage as to what other code might not be working that I’ve yet to test.
Bring back XP!

1 Like