Patching DLLs in general, and specifically user32.dll to prevent FlashWindow(Ex) on Windows 10?

[Ciantic]

Has anyone patched DLLs in this era where Windows includes anti-malware and other measures to prevent tampering?

My problem is that on Windows 10 the Flashing taskbar buttons appear on all virtual desktops, and interrupts my work on another virtual desktop. https://www.neowin.net/forum/topic/1276378-windows-10-virtual-desktops-and-flashing-taskbar-buttons-on-all-virtual-desktops-still-on-insider-builds/ 

I can't come up a better solution than preventing whole flash window thing happening, I have not yet tried to patch this, I have ran dumpbin for the user32.dll and original code for FlashWindow(Ex) function is following, if I'm not mistaken:

user32.dll
10.0.10240.16384

1776  10C 0004C7F0 FlashWindow
1777  10D 000333C0 FlashWindowEx


Function Table (3186)
         Begin    End      Info     
0000729C 0004C7F0 0004C828 0008F3C4
0000510C 000333C0 000333CB 000951B0

FlashWindow
00000001800333C0: 4C 8B D1           mov         r10,rcx
00000001800333C3: B8 7A 13 00 00     mov         eax,137Ah
00000001800333C8: 0F 05              syscall
00000001800333CA: C3                 ret
  
FlashWindowEx
000000018004C7F0: 48 83 EC 48        sub         rsp,48h
000000018004C7F4: F7 DA              neg         edx
000000018004C7F6: 48 89 4C 24 28     mov         qword ptr [rsp+28h],rcx
000000018004C7FB: 48 8D 4C 24 20     lea         rcx,[rsp+20h]
000000018004C800: C7 44 24 20 20 00  mov         dword ptr [rsp+20h],20h
                  00 00
000000018004C808: 1B C0              sbb         eax,eax
000000018004C80A: C7 44 24 34 01 00  mov         dword ptr [rsp+34h],1
                  00 00
000000018004C812: 83 64 24 38 00     and         dword ptr [rsp+38h],0
000000018004C817: 83 E0 03           and         eax,3
000000018004C81A: 89 44 24 30        mov         dword ptr [rsp+30h],eax
000000018004C81E: E8 9D 6B FE FF     call        00000001800333C0 (FlashWindow)
000000018004C823: 48 83 C4 48        add         rsp,48h
000000018004C827: C3                 ret

 

[Ace]

Would it be possible to patch the .dll in memory? e.g. via memorpy

[Ciantic]

  On 27/10/2015 at 06:19, Ace said:

Would it be possible to patch the .dll in memory? e.g. via memorpy

 

Thanks, I'll look into this. Though, I don't know what is the program that causes random programs (e.g. Chrome or Gimp or Visual Studio window) to flash a window when I quickly switch between apps or desktops. That is the most common cause for flashes.

I wonder can I memory patch all programs, maybe then it would work on all times?

Edit: Maybe I can memory patch the Virtual Desktop program in the shell directly? Will that cause problems with anti-malware executables? I have not disassembled that, so finding it will be a task in itself.

[Ciantic]

Truly interesting, microsoft has just added something to the FlashWindowEx in build 10565:

FlashWindowEx (build 10565):
0000000180039210: 4C 8B D1           mov         r10,rcx
0000000180039213: B8 7D 13 00 00     mov         eax,137Dh
0000000180039218: F6 04 25 08 03 FE  test        byte ptr [000000007FFE0308h],1
                  7F 01
0000000180039220: 75 03              jne         0000000180039225
0000000180039222: 0F 05              syscall
0000000180039224: C3                 ret
0000000180039225: CD 2E              int         2Eh
0000000180039227: C3                 ret

 

And in old one: 

FlashWindowEx (build 10240):
00000001800333C0: 4C 8B D1           mov         r10,rcx
00000001800333C3: B8 7A 13 00 00     mov         eax,137Ah
00000001800333C8: 0F 05              syscall
00000001800333CA: C3                 ret

 

I wish it's some registry thing so we could turn the whole damn thing off. Must study this change more.

(Notice that in my parent post I had typed the FlashWindowEx and FlashWindow function names incorrectly.)

Edit: I notice this comparing address 000000007FFE0308h appears in all places where there is a syscall, maybe it's not flashwindowEx specific after all, darn.

Edited October 27, 2015 by Ciantic

[mrexodia]

It can quite easily be done with a global AppInit_DLLs hook and some memory patching. Your AV might go crazy but compile for yourself and create an exception if you really want to disable flashing windows.

 

Code:

#include <windows.h>

static void DisableFlashWindow()
{
    HINSTANCE hUser32 = GetModuleHandleW(L"user32.dll");
    if (!hUser32)
    {
        OutputDebugStringW(L"[NoFlashWindow] GetModuleHandleW failed for user32.dll...");
        return;
    }

    PVOID pFlashWindow = (PVOID)GetProcAddress(hUser32, "FlashWindow");
    if (pFlashWindow)
    {
        BYTE ret4[] = { 0xC2, 0x04, 0x00 };
        if (WriteProcessMemory(GetCurrentProcess(), pFlashWindow, ret4, sizeof(ret4), NULL))
            OutputDebugStringW(L"[NoFlashWindow] FlashWindow disabled!");
        else
            OutputDebugStringW(L"[NoFlashWindow] WriteProcessMemory failed for FlashWindow...");
    }
    else
        OutputDebugStringW(L"[NoFlashWindow] GetProcAddress failed for FlashWindow...");

    PVOID pFlashWindowEx = (PVOID)GetProcAddress(hUser32, "FlashWindowEx");
    if (pFlashWindowEx)
    {
        BYTE ret8[] = { 0xC2, 0x08, 0x00 };
        if (WriteProcessMemory(GetCurrentProcess(), pFlashWindowEx, ret8, sizeof(ret8), NULL))
            OutputDebugStringW(L"[NoFlashWindow] FlashWindowEx disabled!");
        else
            OutputDebugStringW(L"[NoFlashWindow] WriteProcessMemory failed for FlashWindowEx...");
    }
    else
        OutputDebugStringW(L"[NoFlashWindow] GetProcAddress failed for FlashWindowEx...");
}

extern "C" __declspec(dllexport) BOOL APIENTRY DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
    switch (fdwReason)
    {
    case DLL_PROCESS_ATTACH:
        DisableFlashWindow();
        break;
    }
    return TRUE; // succesful
}

GitHub:

https://github.com/mrexodia/NoFlashWindow/releases

 

Duncan