Thread: How to remove LLMHF_INJECTED flag

1. Registered User
Join Date
Oct 2017
Posts
3
Mentioned
0 Post(s)
Quoted
3 Post(s)

How to remove LLMHF_INJECTED flag

Hello all!

Sorry for the noodish post, but I was wondering how this can be done. I have written an application that moves the mouse towards certain colors, but its flags the LLMHF_INJECTED...

Any ideas?

But I am not sure how to implement it

2. Originally Posted by carrumbum
Hello all!

Sorry for the noodish post, but I was wondering how this can be done. I have written an application that moves the mouse towards certain colors, but its flags the LLMHF_INJECTED...

Any ideas?

But I am not sure how to implement it
You can always use a VM. Anything sent to the VM from the host will register as hardware input to the guest OS.

3. There are only a couple of lines of code that you need to change. While it isn't spoonfed in the thread, it is certainly being spelled out in the thread how to accomplish it.

4. Registered User
Join Date
Oct 2017
Posts
3
Mentioned
0 Post(s)
Quoted
3 Post(s)
Originally Posted by Joopi
There are only a couple of lines of code that you need to change. While it isn't spoonfed in the thread, it is certainly being spelled out in the thread how to accomplish it.
I've got the code, just don't know how to execute it. I can get the code to run in console that shows the mouse and keyboard logs and message box that shows when artificial movement is detected(still doesn't block the injected flag), but the compiled blocker is a .DLL and I have no idea how to attach a DLL file to user32
Last edited by carrumbum; 10-23-2017 at 12:06 AM.

5. Where did you find a compiled blocker lol?

6. Registered User
Join Date
Apr 2017
Posts
11
Mentioned
1 Post(s)
Quoted
5 Post(s)
It's been a long time since I've done Windows programming, but I believe:

1) The hook procedure needs to be resident in a DLL.
2) In the host process, load the DLL (via LoadLibrary, getting an HINSTANCE) and get the hook procedure (via GetProcAddress).
3) Pass the HINSTANCE and HHOOK to SetWindowsHookEx.

So you'd need two binaries: the DLL containing the exported hook method (let's call this "hook.dll"), and the host program that installs the hook (let's call this "host.exe").

The hook method would be exported from the DLL something like this:

Code:
extern "C" dllspec(dllexport) LRESULT CALLBACK RemoveFlag(int nCode, WPARAM wParam, LPARAM lParam) { /* code to unset desired bit */ }
The hook process would do something like this:

Code:
auto hook_library = LoadLibrary("hook.dll");
SetWindowsHookEx(WH_KEYBOARD_LL, (HOOKPROC)hook_proc, hook_library, 0);

/* message loop */
You would execute "host.exe" prior to opening RuneScape. You can insert code to print diagnostics from DllMain, and then open RuneScape from the command line: you should see said diagnostics printed to the terminal.

edit

It appears you have Brandon's executable from post 12 and want to inject it into a process. I can't post links, but there's a project called apitrace that that has an injection binary. You could look at how they do it. It's a combination of OpenProcess/VirtualAllocEx/CreateRemoteThread/LoadLibrary.
Last edited by Kompromaus; 10-24-2017 at 11:43 PM. Reason: calrification

7. @Kompromaus;

Thought i'd clear up some of what you said.

The callback only needs to exist in the same context if you're using WH_MOUSE, WH_KEYBOARD (IE non-lowlevel versions, hence DLL injection). If using WH_MOUSE_LL, you do not need to export or inject anything, only create a message pump in that context. *_LL are system-wide hooks and do not need to be running in the same address space or context of the application you're trying to monitor. Whilst it's fine to generally have your callback and your installation code in different DLLs (granted they are in the same address space). It's generally more work.

Originally Posted by Kompromaus
You would execute "host.exe" prior to opening RuneScape.
This is incorrect. SetWindowsHookEx is a FILO system. The first hook to be installed is generally the last hook to receive the callback, (i assumed you're talking about WH_*_LL since you can't install a hook in an application which isn't running yet). This is important because the application's installed hook could get the callback/event before your hook does. Read into hook chains, it's fairly undocumented but there's some info around on how it works:
https://zairon.wordpress.com/2006/12...on-my-machine/
https://shiftlock.wordpress.com/2011...ooks-detector/

There are a few ways around this. The most simplest would be to detour SetWindowsHookEx so that the application does not install any hooks after yours. i guess you could also read the hook chain (inside an application's TEB) coupled with UnhookWindowsHookEx if required, or even swap the order.

Finally, if you're injecting a DLL. Might as well just manually spawn a console on load rather than messing around with running your application through console.
Last edited by Kasi; 10-25-2017 at 07:47 AM.

8. Registered User
Join Date
Apr 2017
Posts
11
Mentioned
1 Post(s)
Quoted
5 Post(s)
That's what I get for going off memory and a brief skim of SetWindowsHookEx on MSDN. I double-checked and was able to verify everything you said (it's very clearly stated in the low-level hook callback pages). Woops. Thanks for clarifying!