Fake keystrokes to another process

Hi all!

I've been dealing with the task of sending fake keystrokes from my process to windows of other processes. I can send messages such like minimize or close. But when i try to send WM_KEYDOWN or WM_CHAR messages to microsoft programs (notepad is the one i've been working with), nothing happens!!!!

Found a thread in this forum (2002) which tries to solve it, but no solution appears.

So, I've done a little program to show messages so that i can send exactly the same messages, with the same wParam and lParam than Windows do when a key is pressed.

And think i found the following problem (hope sbdy could confirm):

When i send a message, it's sent directly to windowproc, while when a key is really pressed, it's sent to the messages loop (GetMessage(..) function) where it's translated, dispatched and whatever..

So, if, as i suspect, microsoft programs translate WM_KEYDOWN and/or WM_CHAR messages to another WM_USER+n message which is unknown for external users, i find myself with no more ideas to go on.... :S

Does anybody have some info about this?? Do i have to send keystrokes at a lower level??

Thanks in advance!!

keybd_event

http://msdn.microsoft.com/en-us/libr...04(VS.85).aspx

Quote:

---

Found a thread in this forum (2002) which tries to solve it, but no solution appears.

---

One possible solution.....

Code:

---

#include <windows.h>
#include <stdio.h>

#define VK_A 0x41
#define VK_B 0x42
#define VK_E 0x45
#define VK_H 0x48
#define VK_O 0x4F
#define VK_R 0x52
#define VK_S 0x53
#define VK_W 0x57

int main(void)
{
    HWND hWnd=NULL;
    HWND hWndEdit=NULL;

    hWnd=FindWindow("Notepad",NULL);
    if(hWnd==NULL)
    {
        printf("Error: Can't find Notepad, aborting\n");
        return 0;
    }
    hWndEdit=FindWindowEx(hWnd,NULL,"Edit",NULL);
    if(hWndEdit==NULL)
    {
        printf("Error: Can't find Notepad Edit, aborting\n");
        return 0;
    }
    PostMessage(hWndEdit,WM_KEYDOWN,VK_B,1);
    PostMessage(hWndEdit,WM_KEYDOWN,VK_O,1);
    PostMessage(hWndEdit,WM_KEYDOWN,VK_B,1);
    PostMessage(hWndEdit,WM_KEYDOWN,VK_SPACE,1);
    PostMessage(hWndEdit,WM_KEYDOWN,VK_W,1);
    PostMessage(hWndEdit,WM_KEYDOWN,VK_A,1);
    PostMessage(hWndEdit,WM_KEYDOWN,VK_S,1);
    PostMessage(hWndEdit,WM_KEYDOWN,VK_SPACE,1);
    PostMessage(hWndEdit,WM_KEYDOWN,VK_H,1);
    PostMessage(hWndEdit,WM_KEYDOWN,VK_E,1);
    PostMessage(hWndEdit,WM_KEYDOWN,VK_R,1);
    PostMessage(hWndEdit,WM_KEYDOWN,VK_E,1);
    return 0;
}

---

Assuming of course that DXInput or some other method isn't used...

Quote:

---

Originally Posted by BobS0327

One possible solution.....

---

No, wrong method (Win32 FAQ)

Quote:

---

Originally Posted by Alex31

No, wrong method (Win32 FAQ)

---

There are a gazillion Win32 FAQ's all over the 'net. How about posting a specific link so that we may debate the issue?

Quote:

---

Assuming of course that DXInput or some other method isn't used...

---

DirectInput is not suited nor designed for this type of task.

and yet my posted solution works perfectly at producing the keystroke...

Quote:

---

Originally Posted by Bubba

DirectInput is not suited nor designed for this type of task.

---

Yes I'm aware of that... I meant provided the process doesn't use DirectInput or some other method to catch key strokes.

Thank u all for your help! Specially to abachler and BobS0327

abachler, keyb_event works fine, thank you a lot!, but i find that, before calling the function, i must set focus on the application I want it to write in.
It's ok to use WM_SETFOCUS, which i tried with non-microsoft programs (e.g. matlab, openoffice.org writer), but i get no result with microsoft programs. With these, y use WM_MAXIMIZE, which works fine, but is quite annoying.
Anyway, is it possible to use keybd_event with a program A and let the user work with other program B without being bothered with focus issues??


BobS0327, thank you very much for your help, it worked fine too, and i avoid focus problems. However, when i use it with other programs, do you know how can i get the name of the child window classes in it, in case they're not predefined like "Edit"? And what if there are several controls of the same class?
By the way, (in case you're still with forces to help me!), why, as it is in your code, does PostMessage(hWndEdit, ...) works, and not (as i tried too) PostMessage(hWnd, ...)? PostMessage sends the message to the owner thread, and the thread seems to be the same for hWnd and hWndEdit, doesn't it?

Thank you again

Quote:

---

However, when i use it with other programs, do you know how can i get the name of the child window classes in it, in case they're not predefined like "Edit"? And what if there are several controls of the same class?

---

Code:

---

#include <stdio.h>
#include <windows.h>

void ListChildWindows(HWND hWnd, DWORD dwPIDCheck)
{
    DWORD dwPID;   
    char szBuffer[1000] = {0};
    GetWindowThreadProcessId(hWnd, &dwPID);
    GetWindowText(hWnd, szBuffer, 1000);
    if(dwPID == dwPIDCheck)
        printf("%-8X %-40s %-8d\n", hWnd, szBuffer,dwPID);
    for(hWnd = GetWindow(hWnd, GW_CHILD); hWnd != NULL; hWnd = GetWindow(hWnd, GW_HWNDNEXT))
        ListChildWindows(hWnd, dwPIDCheck);
}

int main(int argc, char **argv)
{
    HWND hDesktopWindow = NULL;
    if(argc == 1)
    {
        printf("Invalid  arguments\n");
        return 0;
    }
    hDesktopWindow = GetDesktopWindow();
    ListChildWindows(hDesktopWindow, atoi(argv[1]));
    return 0;
}

---

The process ID is the input for the above snippet. It will list all the windows for a particular process.

Quote:

---

By the way, (in case you're still with forces to help me!), why, as it is in your code, does PostMessage(hWndEdit, ...) works, and not (as i tried too) PostMessage(hWnd, ...)? PostMessage sends the message to the owner thread, and the thread seems to be the same for hWnd and hWndEdit, doesn't it?

---

Because you want to send (post) a message to the actual EDIT window not the window that "contains" the EDIT window. We're not working with threads but rather working with windows. I hope that makes sense.

Quote:

---

Because you want to send (post) a message to the actual EDIT window not the window that "contains" the EDIT window. We're not working with threads but rather working with windows. I hope that makes sense.

---

Yap, that's what i thought first too, but then i went into winapi documentation. http://msdn.microsoft.com/en-us/libr...44(VS.85).aspx It seems to work with threads, so... I'm lost.
By the way, who is the owner thread of a window? The main thread in the process, or the one which calls CreateWindow()?Thx!!

Thank you for the code!

Quote:

---

Originally Posted by BobS0327

Code:

---

    for(hWnd = GetWindow(hWnd, GW_CHILD); hWnd != NULL; hWnd = GetWindow(hWnd, GW_HWNDNEXT))
        ListChildWindows(hWnd, dwPIDCheck);

---

---

Quote:

---

Originally Posted by http://msdn.microsoft.com/en-us/library/ms633515(VS.85).aspx GetWindow Function

The EnumChildWindows function is more reliable than calling GetWindow in a loop. An application that calls GetWindow to perform this task risks being caught in an infinite loop or referencing a handle to a window that has been destroyed.

---

Quote:

---

Originally Posted by Nota

It seems to work with threads, so... I'm lost.

---

Windows are created by threads, which then run in the Get/PeekMessage loop to retrieve and process the messages directed towards these windows. PostMessage puts the message in this queue for the thread to deal with as and when it is retrieved from the queue. This is in direct contrast to SendMessage, which bypasses the message queue completely and calls the window procedure directly. The owner thread is the one which called CreateWindow(Ex). This happens to be the main thread in the majority of applications but that's just a convention, not a hard and fast rule.

Quote:

---

The EnumChildWindows function is more reliable than calling GetWindow in a loop. An application that calls GetWindow to perform this task risks being caught in an infinite loop or referencing a handle to a window that has been destroyed.

---

How about posting a complete working example of using EnumChildWindows as needed in the context of this thread? I'm sure we'll all benefit from it . Especially, the OP.

Quote:

---

Originally Posted by Nota

Yap, that's what i thought first too, but then i went into winapi documentation. http://msdn.microsoft.com/en-us/libr...44(VS.85).aspx It seems to work with threads, so... I'm lost.
By the way, who is the owner thread of a window? The main thread in the process, or the one which calls CreateWindow()?Thx!!

Thank you for the code!

---

I decided to approach this from the thread point of view with the following code:

Code:

---

#include <windows.h>
#include <stdio.h>

#define VK_B 0x42
#define VK_O 0x4F

int main(int argc, char *argv[])
{
    HWND hWnd, hWndEdit;
    unsigned long ulProc;
    HANDLE hThread, hThreadEdit;

    hWnd=FindWindow("Notepad",NULL);
    if(hWnd==NULL)
    {
        printf("Error: Can't find Notepad, aborting\n");
        return 0;
    }
    hWndEdit=FindWindowEx(hWnd,NULL,"Edit",NULL);
    if(hWndEdit==NULL)
    {
        printf("Error: Can't find Notepad Edit, aborting\n");
        return 0;
    }
    printf("Found Notepad Window At...0x%xh\n",hWnd);
    printf("Found Notepad Edit Window At...0x%xh\n",hWndEdit);
    hThreadEdit = (void *)GetWindowThreadProcessId(hWndEdit,&ulProc);
    if(hThreadEdit  == NULL)
    {
        printf("Search for Edit thread failed\n");
        return 0;
    }
    else
    {
        printf("PostThreadMessage to EDIT window: TID 0x%xh  PID 0x%xh\n",hThreadEdit,ulProc);
        PostThreadMessage((DWORD) hThreadEdit,(UINT) WM_KEYDOWN,VK_B,1);
        PostThreadMessage((DWORD) hThreadEdit,(UINT) WM_KEYDOWN,VK_O,1);
        PostThreadMessage((DWORD) hThreadEdit,(UINT) WM_KEYDOWN,VK_B,1);
    }
#ifdef SHUTNOTEPAD
    hThread = (void *)GetWindowThreadProcessId(hWnd,&ulProc);
    if(hThread  == NULL)
    {
        printf("Search for Notepad main thread failed\n");
        return 0;
    }
    else
    {
        PostThreadMessage((DWORD) hThread,(UINT) WM_QUIT,0,0);
    }
#endif 
    return 0;
}

---

Unfortunately, I could not get PostThreadMessage to work. I used WinId to verify that my handle and thread ID's were correct. And they were. This problem was really stumping me. So, I searched Safari and all I found were statements indicating that PostThreadMessage would not work under the above circumstances and that PostMessage should be used. But no one indicated WHY it wouldn't work. Now I googled and only found this link. Well, we all know that there's a lot of misinformation on the net. Thus, I wasn't going to take this link on face value and started OllyDbg to verify the statemenst on the link. Lo and behold, the PostThreadMessage message was not getting to the local loop.

Also, it's interesteing to note that PostThreadMessage does make it to the main loop. This is illustrated by the commented out code. If you uncomment the code, you can terminate notepad.

Finally, if you aren't already using Ollydbg, I would strongly suggest that you start. IMHO, it's the greatest thing since sliced bread.

Quote:

---

Originally Posted by BobS0327

Unfortunately, I could not get PostThreadMessage to work. This problem was really stumping me.

---

Quote:

---

Originally Posted by PostThreadMessage

Messages sent by PostThreadMessage are not associated with a window. As a general rule, messages that are not associated with a window cannot be dispatched by the DispatchMessage function

---

While that suggests there are exceptions, WM_KEYDOWN doesn't seem to be one. Without a window handle, who is it going to dispatch the (apparent) keystroke to? On XP SP3, the answer is no one, so nothing happens. It is removed from the message queue with no visible effect that it ever made it to its destination. WM_QUIT works because it causes GetMessage to return 0 which stops the message loop.

Quote:

---

How about posting a complete working example of using EnumChildWindows as needed in the context of this thread? I'm sure we'll all benefit from it . Especially, the OP.

---

This is an extended version of yours

Code:

---

#undef UNICODE
#undef _UNICODE
#define WIN32_LEAN_AND_MEAN
#define _WIN32_WINNT 0x0500

#include <windows.h>
#include <iostream>
#include <shlwapi.h>
#include <sstream>
#include <iostream>

#pragma comment(lib, "shlwapi.lib")

// our enumerators
BOOL WINAPI ChildEnumerator(HWND hwnd, LPARAM lParam);
BOOL WINAPI ParentEnumerator(HWND hwnd, LPARAM lParam);

// Struct masquerading as a text sink
struct Buffer
{
    // constructor sets up where to dump the final buffer, defaults to cout
    inline Buffer(std::ostream& out = std::cout) : out(out){}

    // destructor dumps it
    inline ~Buffer()
    {
        Dump();
    }

    // this allows nicer syntax for print operations, similar to printf.
    // Less typing required both here and invocation than operator()
    // with no real loss IMHO
    template<class T>
    Buffer& operator,(const T& data)
    {
        buf << data;
        return *this;
    }

    // this is retained from cout syntax, so we can see where the
    // data is being streamed to just by looking at the first output
    // it's usage is not necessary
    template<class T>
    Buffer& operator<<(const T& data)
    {
        buf << data;
        return *this;
    }

    // dumps the text to the output stream specified in the constructor
    inline void Dump()
    {
        out << buf.str();
        out << std::endl;
    }

    // the ultimate output stream, and our buffer
private:
    std::ostream& out;
    std::ostringstream buf;
};

void OutputWindowProperties(HWND hwnd, Buffer& printer)
{
    char winText[512] = {0};
    // Get the text it's displaying
    if(SendMessage(hwnd, WM_GETTEXT, 512, reinterpret_cast<LPARAM>(winText)))
    {
        printer << "\tText: ", winText, '\n';
    }
    // Find out which file created it
    if(GetWindowModuleFileName(hwnd, winText, 512))
    {
        printer << "\tCreated by: ", PathFindFileName(winText), '\n';
    }

    // see what thread/process it came from
    DWORD procID = 0;
    DWORD threadID = GetWindowThreadProcessId(hwnd, &procID);
    printer << "\tOwning Process ID: ", procID, " Thread ID: ", threadID, '\n';

    // get some misc info
    WINDOWINFO wInfo = {sizeof(wInfo), 0};
    GetWindowInfo(hwnd, &wInfo);

    // se if we can get the class it belongs to
    WNDCLASSEX wcl = {sizeof(wcl), 0};
    if(GetClassInfoEx(reinterpret_cast<HINSTANCE>(GetWindowLongPtr(hwnd, GWLP_HINSTANCE)),
      reinterpret_cast<LPCSTR>(wInfo.atomWindowType), &wcl))
    {
        printer << "\tClassInfo:\n\t\tName: ";
        // try and get the name of the class
        if(GetAtomName(wInfo.atomWindowType, winText, 512))
        {
            printer << winText, '\n';
        }
        // if we can't, see if the class belongs to the current process
        // if it does, we can dereference the string
        else if(GetCurrentProcessId() == procID)
        {
            printer << wcl.lpszClassName, '\n';
        }
        // otherwise, just print the class id
        else
        {
            printer << wInfo.atomWindowType, '\n';
        }
        // output the wndproc address in hex
        printer << "\t\tWndProc at address: ", std::hex, wcl.lpfnWndProc, std::dec, '\n';
    }
    // finally the window X/Y location
    printer << "\tX Location: ", wInfo.rcWindow.left, ", Y Location: ", wInfo.rcWindow.top, '\n';
}

// called for each top level window
BOOL WINAPI ParentEnumerator(HWND hwnd, LPARAM lParam)
{
    // our dumping ground
    Buffer printer;
    // output window handles in hex, then change the number format back to decimal
    printer << "Top-Level Window - ", std::hex, hwnd, std::dec, '\n';
    // Get its' properties
    OutputWindowProperties(hwnd, printer);
    // go through any children and do the same, passing in the text buffer
    // so we can have a roughly hierachichal structure to the output
    EnumChildWindows(hwnd, ChildEnumerator, reinterpret_cast<LPARAM>(&printer));
    // keep calling us for windows we haven't encountered yet
    return TRUE;
}

// called for each child window
BOOL WINAPI ChildEnumerator(HWND hwnd, LPARAM lParam)
{
    // get the text buffer we passed in
    Buffer& printer = *(reinterpret_cast<Buffer*>(lParam));
    // everything else is the same as the one above
    printer << "\n  Child Window ", std::hex, hwnd, std::dec, '\n';
    OutputWindowProperties(hwnd, printer);
    return TRUE;
}

int main(int argc, char *argv[])
{
    // start the chain of window enumeration
    // warning, will spew out lots of data
    EnumWindows(ParentEnumerator, 0);
}

---

Quote:

---

Messages sent by PostThreadMessage are not associated with a window. As a general rule, messages that are not associated with a window cannot be dispatched by the DispatchMessage function

---

They are associated to the thread assigned to window since my previous example illustrated how to send a WM_QUIT message to a window via a thread. This also can be demonstrated by executing the WinId util I previously referenced and finding the Notepad - Untitled window. You'll see a thread ID attached to that window. Thus, you can send a PostThreadMessage to that thread without any issues whatsover. The problem lies with trying to send a PostThreadMessage to a child window with a local message loop. This, also can be demontrated by opening up a text document in Notepad,and then executing WinId, finding the thread id of the child edit window and sending a PostThreadMessage to that thread. Using Ollydbg shows that the message gets "lost". I have a couple of theories as to why it gets lost. But I can't post post my theories until I can find some authoritatative references to substantiate my posts.

Quote:

---

This is an extended version of yours

---

No. it's not even close since it doesn't provide the required info that the original poster needs to complete his task. Execute my snippet and you'll see the information that he needs.

You don't need any authorative sources, a simple program will suffice.

Code:

---

#define _UNICODE
#define UNICODE
#include <windows.h>
#include <iostream>

LRESULT WINAPI MsgProc( HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam )
{
    switch( msg )
    {
        case WM_DESTROY:
        {
            DestroyWindow(hWnd);
            PostQuitMessage( 0 );
            return 0;
        }
        case WM_KEYDOWN:
        {
            std::cout << "WM_KEYDOWN received with key: " << static_cast<char>(wParam) << '\n';
        }
        break;
        case WM_CHAR: // TranslateMessage will produce one for a WM_KEYDOWN
        {
            std::wcout << L"WM_CHAR received with key: " << static_cast<WCHAR>(wParam) << L'\n';
        }
        break;
    }
    return DefWindowProc( hWnd, msg, wParam, lParam );
}

struct ThreadParams
{
    DWORD threadId;
    HANDLE hEvent;
};

DWORD WINAPI ThreadFunc(LPVOID lpParam)
{
    ThreadParams* tp = static_cast<ThreadParams*>(lpParam);
    while(WaitForSingleObject(tp->hEvent, 500) != WAIT_OBJECT_0)
    {
        PostThreadMessage(tp->threadId, WM_KEYDOWN, 'L', 0);
    }
    return 0;
}

INT WINAPI wWinMain( HINSTANCE hInst, HINSTANCE, LPWSTR, INT )
{
    // Register the window class
    WNDCLASSEX wc = { sizeof(WNDCLASSEX), CS_CLASSDC, MsgProc, 0L, 0L,
                      GetModuleHandle(NULL), NULL, NULL, NULL, NULL,
                      L"D3D Tutorial", NULL };
    if(RegisterClassEx( &wc ))
    {
        // Create the application's window
        HWND hWnd = CreateWindow( L"D3D Tutorial", L"D3D Tutorial 03: Matrices",
                                  WS_OVERLAPPEDWINDOW, 100, 100, 256, 256,
                                  NULL, NULL, wc.hInstance, NULL );
        if(hWnd)
        {
            HANDLE hThreadExitEvent = CreateEvent(NULL, TRUE, FALSE, L"ExitEvent");
            if(hThreadExitEvent)
            {
                ShowWindow( hWnd, SW_SHOWDEFAULT );
                UpdateWindow( hWnd );

                ThreadParams tp = {GetCurrentThreadId(), hThreadExitEvent};

                HANDLE hThread = CreateThread(NULL, 0, &ThreadFunc, &tp, 0, NULL);
                if(hThread)
                {
                    MSG msg = {0};
                    while( GetMessage( &msg, NULL, 0U, 0U) )
                    {
                        std::cout << "GetMessage retrieved message 0x" << std::hex << msg.message << '\n';
                        if(TranslateMessage( &msg ))
                        {
                            std::cout << "TranslateMessage success ";
                        }
                        DispatchMessage( &msg );
                    }
                    SetEvent(hThreadExitEvent);
                    WaitForSingleObject(hThread, INFINITE);
                    CloseHandle(hThread);
                }
                else DestroyWindow(hWnd);
                CloseHandle(hThreadExitEvent);
            }
        }
    }
    return 0;
}

int wmain()
{
    return wWinMain(GetModuleHandle(NULL), NULL, NULL, SW_SHOW);
}

---

The WM_KEYDOWN's (0x100) are received with GetMessage but never sent on to the WndProc because there is no HWND set in the message struct. Attach a debugger and step through DispatchMessage. On my XP SP3, without a window its worker func checks if the message is WM_USER, WM_DEVICECHANGE, WM_TIMER, or the undocumented message 0x0118 before ultimately returning without calling anybody. Close the window shows that WM_QUIT never makes it into the loop because it causes GetMessage to return 0 which ends the loop, as the docs for GetMessage state.

In the case of notepad, all 3 of its windows belong to the same thread. It doesn't matter which windows' thread id you post to as they're all identical (if they're not then that app has a bug or you're using some funky version of notepad) and processed by the same loop, which shows identical behaviour to the program above.

The issue with PostThreadMessage is that it will work in the main "root" window because a message queue is available. That has been demonstrated in the code above using WM_QUIT message. In a child window, there isn't necesarily a message queue. But the bottom line is if a message queue is available, PostThreadMessage will work. Otherwise, it will fail. Also, the OP was referring to remote processes such as Notepad. Heck, with a app where the source code is available such as the above listing, the sky's the limit. Anything is possible. I'm basing my stuff on remote apps such as Notepad, MSWord etc.

The reason why I wish to have an authoritative source or at least proof of concept code is because the above statements may just be pure BULL. Just because I can post "star wars" statements" doesn't necessarily make them true statements. How do you know that I really know what I'm talking about or whether it's just BULL? Case in point CloakDll which is a worthless piece of excrement.

EDIT. There are actually 5 windows opened when notepad starts.

Quote:

---

Originally Posted by BobS0327

How do you know that I really know what I'm talking about or whether it's just BULL?

---

That's the thing, there's a blockage somewhere and you don't know in anyway I interpret it. I'm not sure whether it's just a fundemental misunderstanding or I'm not explaining things clearly but whatever. It takes about 5 minutes to attach to notepad and seen for yourself that it does exactly the same as the app above. PostMessage and PostThreadMessage are one and the same except one fills in the HWND member of the message struct retrieved by Get\PeekMessage, one doesn't. That's the entirety of the difference as to why one will "type" in notepad while the other doesn't. There's a mapping between HWNDs and WndProcs, not between threads and WndProcs.

Quote:

---

In a child window, there isn't necesarily a message queue.

---

Of course not since both queues and windows belong to threads. A thread creates a window, a thread pumps messages for that window; that's how it is and knowing MS that's how it will always be. Notepad has one thread and creates 3 windows -> the single thread pumps messages for all 3 windows. If you really wanted to you could spawn a thread to create an edit control for the app above, if that thread doesn't go into its own message loop the edit window will do nothing, the Get/PeekMessage docs spell this out.

Quote:

---

I'm basing my stuff on remote apps such as Notepad, MSWord etc.

---

The above paragraph contains the rules for everybody, it's not one rule for them and one for us. Again, 5 minutes in a disassembler and debugger shows you haven't quite got the concept right in some shape or form.

Quote:

---

Case in point CloakDll which is a worthless piece of excrement.
EDIT. There are actually 5 windows opened when notepad starts.

---

Oh the irony here is delicious, I welcome attempts to show me where I've gone wrong but that's just laughable.