Using low-level keyboard for input

If i use 'keybd_event()', i would be able to set the program automatically type on the notepad or something, but would that be considered as low-level keyboard input?

I searched online and came across some examples that said you have to hook the program to the driver or what ever it is. Anyone has any suggestion?
Here is the code i found:

Code:

---

#define _WIN32_WINNT 0x0400
#include <Windows.h>


///////////////////////////////////////////////////////////////////////////////


LRESULT CALLBACK LowLevelKeyboardProc(int nCode, WPARAM wParam, LPARAM
lParam)
{

  BOOL fEatKeystroke = FALSE;

  if (nCode == HC_ACTION)
  {
    switch (wParam)
        {
                case WM_KEYDOWN: 
                case WM_SYSKEYDOWN:
                case WM_KEYUP:   
                case WM_SYSKEYUP:
                        {
                                PKBDLLHOOKSTRUCT p = (PKBDLLHOOKSTRUCT) lParam;
                                fEatKeystroke=(p->vkCode == VK_SNAPSHOT);
                                if (fEatKeystroke)
                                {
                                        //Here goes your printkey code
                                }
                                break;
                        }
    }
  }

  return(fEatKeystroke ? 1 : CallNextHookEx(NULL, nCode, wParam,
lParam));
}


///////////////////////////////////////////////////////////////////////////////


int WINAPI WinMain(HINSTANCE hinstExe, HINSTANCE, PTSTR pszCmdLine, int)
{

  // Install the low-level keyboard & mouse hooks
  HHOOK hhkLowLevelKybd  = SetWindowsHookEx(WH_KEYBOARD_LL,
    LowLevelKeyboardProc, hinstExe, 0);

  // Keep this app running until we're told to stop
  MessageBox(NULL,
    TEXT("Print Key is now disabled.\n")
    TEXT("Click \"Ok\" to terminate this application and re-enable that key."),
    TEXT("Disable Low-Level Keys"), MB_OK);

  UnhookWindowsHookEx(hhkLowLevelKybd);

  return(0);
}

---

I personally wouldn't call that "Low Level Keyboard input", but I guess that all depends on how you interpret the term.

In my interpretation, it means "reading data directly from the keyboard controller itself".

Different people will, however, take this phrase as different things.

--
Mats

Is there any way that i could write a loop that automatically reading from the keyboard (just like some MMORPG game trainer ).
I could do it from the keybd_event() but how would i going to do that with the code above? Thx

Quote:

---

Is there any way that i could write a loop that automatically reading from the keyboard (just like some MMORPG game trainer ).
I could do it from the keybd_event() but how would i going to do that with the code above? Thx

---

Code:

---

#define _WIN32_WINNT 0x0400
#include <Windows.h>

///////////////////////////////////////////////////////////////////////////////

LRESULT CALLBACK LowLevelKeyboardProc(int nCode, WPARAM wParam, LPARAM
    lParam)
{
    BOOL fEatKeystroke = FALSE;
    if (nCode == HC_ACTION)
    {
        switch (wParam)
        {
            case WM_KEYDOWN: 
            case WM_SYSKEYDOWN:
            case WM_KEYUP:   
            case WM_SYSKEYUP:
                {
                    PKBDLLHOOKSTRUCT p = (PKBDLLHOOKSTRUCT) lParam;
                    fEatKeystroke=(p->vkCode == VK_SNAPSHOT);
                    if (fEatKeystroke)
                    {
                       
                        //Here goes your printkey code
                    }
                    break;
                }
        }
    }
    return(fEatKeystroke ? 1 : CallNextHookEx(NULL, nCode, wParam,
        lParam));
}

///////////////////////////////////////////////////////////////////////////////

void MessageLoop()
{
    MSG message;
    while (GetMessage(&message,NULL,0,0)) {
        TranslateMessage( &message );
        DispatchMessage( &message );
    }
}

DWORD WINAPI  TheKeyLogger()
{
    HINSTANCE hinstExe = GetModuleHandle(NULL);
    // Install the low-level keyboard & mouse hooks
    HHOOK hhkLowLevelKybd  = SetWindowsHookEx(WH_KEYBOARD_LL,
        LowLevelKeyboardProc, hinstExe, 0);

    // Keep this app running until we're told to stop
    //  MessageBox(NULL,
    //  TEXT("Print Key is now disabled.\n")
    // TEXT("Click \"Ok\" to terminate this application and re-enable that key."),
    //  TEXT("Disable Low-Level Keys"), MB_OK);

    MessageLoop();
    UnhookWindowsHookEx(hhkLowLevelKybd);
    return(0);
}

int main(int argc, char **argv)
{
    HANDLE hThread;
    DWORD dwThread;

    hThread = CreateThread(NULL,NULL,(LPTHREAD_START_ROUTINE)
        TheKeyLogger, (LPVOID) argv[0], NULL, &dwThread);
    if (hThread)
        return WaitForSingleObject(hThread,INFINITE);
    else return 1;
}

---

If you want low level inside Windows you must use DirectInput. Everything else goes through the message pump which is anything but low level.

Or possibly Raw Input.

I would think that DirectInput is easier and more flexible.

So how do you apply directInput in c++? I dont really know about directInput. Is it possible that i can apply directInput in window console project in visual studio? Well, my goal is trying to set a series of keys that will automatically loop through them and send to the system, just like some macro.

Sure enough. You just have to get the DirectX SDK from Microsoft.
It comes with docs, libraries, example source - all you need to build projects with DirectInput!

Contrary to popular belief but both DirectInput and DirectAudio will function by themselves without ever touching Direct3D. All they both need are window handles and some other basic rudimentary data and you are set.

It may even be possible to do this from a console app given that you can retrieve the window handle by setting the title to a known value, searching for a window with that title and then store the hwnd that Windows finds. From here you could definitely fire up DirectInput and/or DirectSound.

If you have problems with DirectInput let me know as I have plenty of experience with it to get you going. Remember that you MUST #define the version of DirectInput you wish to use PRIOR to including dinput.h. If you fail to do this you will get some very nasty cryptic errors. The DirectInput header file relies on this #define to determine which functions to compile and which ones to ignore. That little bit of info will you save you hours of frustration - or at least it would have for me.

Example of a rudimentary console app. I'd be interested in your approach to send "macros" back to the system using Direct Input. Hopefully, you can post some code to illustrate this macro sending concept.

Code:

---

#include <windows.h>
#include <stdio.h>
#define DIRECTINPUT_VERSION 0x0800
#include <dinput.h>

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

LPDIRECTINPUT8 din; 
LPDIRECTINPUTDEVICE8 directinputdevice; 

void InitializeDirectInput(HINSTANCE hInstance, HWND hWnd)
{
    DirectInput8Create(hInstance, 
        DIRECTINPUT_VERSION,   
        IID_IDirectInput8,   
        (void**)&din,   
        NULL); 
    din->CreateDevice(GUID_SysKeyboard, 
        &directinputdevice, 
        NULL);   
    directinputdevice->SetDataFormat(&c_dfDIKeyboard);
    directinputdevice->SetCooperativeLevel(hWnd,
        DISCL_NONEXCLUSIVE | DISCL_BACKGROUND);
}

void DetectKeys(void)
{
    static BYTE keystate[256];   
    directinputdevice->Acquire(); 
    directinputdevice->GetDeviceState(256, (LPVOID)keystate);
    if(keystate[DIK_A] & 0x80)  // Check for a depressed 'A' 
        printf("A\n");          // This is where you'll implement
                                // your custom key capture routine 
}

void CloseDirectInput(void)
{
    directinputdevice->Unacquire();
    din->Release();   
}

void MessageLoop()
{
    MSG msg;
    while(TRUE)
    {
        DWORD dwStartPoint = GetTickCount();
        if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
        {
            if (msg.message == WM_QUIT)
                break;
            TranslateMessage(&msg);
            DispatchMessage(&msg);
        }
        DetectKeys();
        while ((GetTickCount() - dwStartPoint) < 25);
    }
    CloseDirectInput();
}

DWORD WINAPI MyDirectInput(LPVOID lpParm)
{
    HINSTANCE hInstance = GetModuleHandle(NULL);
    InitializeDirectInput(hInstance, NULL);
    MessageLoop();
    return 0;
}

int main(int argc, char** argv)
{
    HANDLE hThread;
    DWORD dwThread;

    hThread = CreateThread(NULL,NULL,(LPTHREAD_START_ROUTINE)
        MyDirectInput, (LPVOID) argv[0], NULL, &dwThread);
    if (hThread)
        return WaitForSingleObject(hThread,INFINITE);
    else return 1;
}

---

As you can see DirectInput is actually quite simple and lightweight and perfect for a thread. But sending data back and forth between console and Windows app may prove to be a challenge. You can utilize SendMessage() provided you both have each other's window handles. You can then define messages starting at WM_USER+1 to implement the specific functionality of your app.

Since SendMessage() is part of the Win32 API it is perfectly thread safe. This also allows the thread complete access to the keyboard data without having to provide access to the Windows app. Your console app would need to store the previous state of the keyboard and at the moment that changes you would send a message to the Windows app. If you take the approach to actually share the keyboard state buffer then you will have to mutex it so you ensure that the buffer is only accessed by one process at any given time. Otherwise you will most certainly crash and/or threadlock.

Using SendMessage from a thread is usually not recommended because it waits until the message is processed before returning (possibility of a deadlock). It's better to use PostMessage or SendMessageCallback to post the message to the queue and return immediately.
Generally, with threads and messages you need to be careful.

Yes I thought about that after posting it. PostMessage or a callback would be better. But it's not because any of the functions are not thread-safe per se but moreso because SendMessage is like a 'blocking' call.

Unfortunately, PostMessage has an issue or two. For instance, when PostMessage inputs the message into the targeted windows queue, that input does not update the targeted windows keyboard shift state even though PostMessage may indicate a change in keyboard shift state. When the code behind the targeted window calls either GetKeyState or GeyAsyncKeyState function, it will see the "real" shift state not the "faked" keyboard state from PostMessage.

So, I suggest using SendInput:

Code:

---

#define _WIN32_WINNT 0x0501
#include <windows.h>
#include <stdio.h>

#define KEYEVENTF_UNICODE 0x0004

static void SendString(LPCTSTR str)
{
    INPUT inp[2];
    memset(inp,0,sizeof(INPUT));
    inp[0].type = INPUT_KEYBOARD;
    inp[0].ki.dwFlags =  KEYEVENTF_UNICODE;
    inp[1] = inp[0];
    inp[1].ki.dwFlags |= KEYEVENTF_KEYUP;

    for (LPCTSTR p=str; *p; p++) {
        inp[0].ki.wScan = inp[1].ki.wScan = *p;
        SendInput(2, inp, sizeof(INPUT));
    }
}

int main(void)
{
    HWND windowHandle = FindWindow(0, "test - Notepad");
    if(windowHandle == NULL)
    {
        printf("Main window not found, terminating\n");
        return -1;
    }
    HWND childWindow = GetWindow(windowHandle,GW_CHILD);
    if(childWindow  == NULL)
    {
        printf("Child window not found\n");
        return -1;
    }
    SetForegroundWindow(childWindow);
    Sleep(1000);
    SendString("\nTesting\n");
    return 0;
}

---

Quote:

---

Originally Posted by Bubba

Yes I thought about that after posting it. PostMessage or a callback would be better. But it's not because any of the functions are not thread-safe per se but moreso because SendMessage is like a 'blocking' call.

---

But that's also what makes it so thread unsafe. Since the other thread isn't the one that processes messages, it needs to wait until the first thread processes the message, And if the first thread somehow fails to process it, or waits from some data elsewhere, or so on, the second thread will block indefinitely.
There may also be other unsafe functions about SendMessage.

alrite then. I've done with my finals and now i have a long break work on this freaking thing. Yay!!!!!

So, I've implement Bob's code and for sure it works. However, i just realized something. Say: you send the key stroke to an execute program ( such as notepad.exe), it will work because the notepad.exe process shows up in the taksmanager. What if the notepad.exe is not in the taskmanager (hidden), would this work?

What are you hinting at? Are you trying to send keys to to some program to start it?
You can always do that yourself from within the program.

I love how he starts talking notepad.exe and then wants to do something with "hidden" processes. lol....

I don't love it at all. I'm very suspicious of it.

OP: Why would you want to do this?

I love it because it fits the pattern of a newbie script kiddie 1337 wannabe haxor who can bearly tie his shoes, but wants to tears it up something awful with his uber coding skillz. He asks how to do something with notepad.exe, and then jumps off to something totally in the realm of rootkits. Completely typical.

FYI, i'm hitting at a program to interact with my MMPROG game. Because gameguard hide the game process in the process window task, that's why as i understand, the program can not send any key stroke to the game. What i was asking that if the process is hidden, can the signal be send to it or is there any other way around

If you want to make some sort of game macro or bot, I'd suggest using Autoit (http://www.autoitscript.com/). It's perfectly suited for this kind of thing. If you don't want to use the language itself, there is always a DLL file you can use with C++. I've used it before for the exact reason you want, worked great.

Quote:

---

Originally Posted by ryeguy

If you want to make some sort of game macro or bot, I'd suggest using Autoit (http://www.autoitscript.com/). It's perfectly suited for this kind of thing. If you don't want to use the language itself, there is always a DLL file you can use with C++. I've used it before for the exact reason you want, worked great.

---

For the new gameguard engine? Are you the gameguard wont kick it out? Thanks anyways, i'm gonna try and test it out now. lol

So you want to add a bot to the game or are you trying to cheat?

I'd like to know so I can decide whether or not to close this thread.

Both - game macros are cheats in any sort of competitive multiplayer game. Gameguard is right to kick them out.