DLL 注入两个进程

Question

I am trying to build a dll (in order to inject in a process) and am having some issues with it.

Let me explain:

When I inject my dll in my target, Everything works perfectly. Once I add another target (the same executable) while the first one is still running, there will be some conflicts.

To be fair, I think there is "only" one conflict. Here is the code.

DWORD WINAPI MainThread(LPVOID param)
{
    // Same behaviour with GetKeyState
    while (!GetAsyncKeyState(VK_F9)) // While F9 is not pressed, do nothing
        Sleep(5);
    fprintf(stdout, "Clicked !"); // Print Clicked when F9 is pressed
    while(true); // Just to stop.
    return false;
}

BOOL APIENTRY DllMain(HMODULE hModule,DWORD  ul_reason_for_call,LPVOID lpReserved)
{
    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH: // Gets ran when injected
        AllocConsole(); // Enable the console
        freopen_s((FILE**)stdout, "CONOUT$", "w", stdout);
        freopen_s((FILE**)stdin, "CONIN$", "r", stdin);
        CreateThread(0, 0, MainThread, hModule, 0, 0); // Creates our thread 
        break;
    }
    return TRUE;
}

This sample will do the following: I start Target.exe, I inject Inject.dll into it, I press F9, "Clicked" appears. Expected.
Now, I start Target.exe, I inject Indect.dll, I don't press F9. Instead, I start another Target.exe, I inject Inject.dll into it, and now, if I press F9, Clicked will be printed on both consoles. Unexpected.

Why?

I read on https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getasynckeystate the following

Although the least significant bit of the return value indicates whether the key has been pressed since the last query, due to the pre-emptive multitasking nature of Windows, another application can call GetAsyncKeyState and receive the "recently pressed" bit instead of your application. The behavior of the least significant bit of the return value is retained strictly for compatibility with 16-bit My Windows applications (which are non-preemptive) and should not be relied upon.

Target.exe and Inject.dll are both 32 bits, so I guess I do not need to be bothered by that quote, so I am really clueless on what is causing it.

Note that I also tested with getchar, but since it is console-related, I can not use it, even if it does not print on the second console.

Answer 1

Well, as I stated in my last comment

Tried with SetWindowsHook, same behaviour. Came up with a window rename + name comparison. Works perfectly ! Thanks for your help

I used rename + name comparison. Others issues came out, so I had to rethink my way of achieving it. Here is the final version:

bool isSameProcess(HWND window, DWORD pid)
{
    DWORD activePId;
    DWORD activeThreadId = GetWindowThreadProcessId(window, &activePId);
    return activePId == pid;
}

Explaination: window is the active window, pid our own process id. we will check if our pid is equal to active window's process id. If it is, we return true, else, false.

So this way, you can use it like that:

if ((GetAsyncKeyState(VK_F9) & 0x8000))
{
    window = GetForegroundWindow();
    if(isSameProcess(window, pid))
    {/* Whatever you want to do */}
}