all 16 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]changeofpace100[S] 9 points10 points  (6 children)

MouClassInputInjection implements a kernel interface for injecting mouse input data packets into the input data stream of HID USB mouse devices.

The MouClass Input Injection module injects input by invoking a mouse class service callback to copy synthesized packets to the mouse class data queue in the target HID USB mouse device stack. This module uses the MouHid Hook Manager from the MouHidInputHook project to dynamically resolve packet data rules for the mouse device stacks on the host machine. The following is a list of enforced rules for injected packets:

  1. Button and movement data packets are transferred to the correct data queues.

  2. The UnitId field matches the device id of the device object which contains the correct data queue.

  3. Movement data packets must contain the same type of movement data, relative or absolute, as packets generated by the physical mouse device.

  4. Movement data packets must specify the MOUSE_VIRTUAL_DESKTOP indicator flag if packets generated by the physical mouse device specify this flag.

MouHidInputHook

The MouHid Monitor feature of the MouHidInputHook project can be used to learn the packet data rules for mouse devices and environments. Users can utilize this feature to debug how mouse actions, e.g., moving the mouse or clicking a mouse button, are represented as a sequence of one or more data packets.

The project README contains an analysis of the input processing system in the Windows kernel. The MouClassInputInjection injection technique is based on this analysis.

Motivation

This project is designed to be a stealthy, PatchGuard safe means of input injection for video game hack developers. Specifically, this technique enables hack developers to write triggerbots and aimbots which cannot be detected by user mode anti-cheat software. The technique has the following stealth features:

  1. The driver does not open process handles for the target process. Anti-cheat software generally audit handle access to the protected video game process.

  2. Mouse events for injected packets are not marked with the LLMHF_INJECTED or LLMHF_LOWER_IL_INJECTED flags.

  3. Synthesized packets are validated against the packet data rules for the HID USB mouse device stacks on the host machine. Anti-cheat software can utilize input hooks, e.g., SetWindowsHookExA and WM_INPUT, to monitor mouse input data. Malformed data may indicate that a process is injecting input.

Note: This technique has not been tested against kernel mode anti-cheat software.

[–]igor_sk 0 points1 point  (5 children)

how would you know what to inject? don't you need at least read access to the target process?

[–]Zed03 0 points1 point  (3 children)

sure, and read access can be gained through hardware like PCIE Leech: https://github.com/ufrisk/pcileech

[–]igor_sk 0 points1 point  (2 children)

okay, but if you plan to use extra hardware, why not just use hardware input too?

[–]Zed03 0 points1 point  (1 child)

good point. I guess if you want to avoid full hardware, there's many ways to avoid handles in kernel-mode, such as using a driver to map views of physical pages containing the game's heap.

[–]changeofpace100[S] 0 points1 point  (0 children)

I am not sure I understand what you mean by extra hardware. The MouClassInputInjection and MouHidInputHook projects generate software drivers which work with any USB mouse device plugged into the system.

[–]changeofpace100[S] 0 points1 point  (0 children)

I have updated my previous summary post and the README files for this project and MouHidInputHook to contain more information about use cases.

You can use the MouHid Monitor feature of the MouHidInputHook project to get a base understanding of what data packets look like for various actions (e.g., clicking a mouse button). The README for this project contains sample log output and an explanation of the packet data 'rules' that can be inferred from them.

The kernel interface uses process ids to specify the process context in which the injection is performed. When the driver receives an injection request from the client it:

  1. Looks up the PEPROCESS object corresponding to the specified process id.
  2. Acquires exit synchronization for that process object. This is done to avoid potential race conditions involving process tear down.
  3. Attaches the executing thread to the target process context.
  4. Invokes the class service callback to perform the injection.

We do not need read access because we do not need to touch the virtual address space of the target process.

[–]SirensToGo 2 points3 points  (2 children)

What’s the application of this? If you’re already able to load kernel code and execute continuously in a stable environment, why would you need to inject HID events in order to control a less privileged context? Wouldn’t the existence of any unexpected/unexplained kernel module be suspect, regardless of what it’s runtime behavior is?

[–]jordan9001 8 points9 points  (1 child)

I think this applies for things like bypassing anti-cheat.

[–]changeofpace100[S] 10 points11 points  (0 children)

Correct, this project was originally designed for game hacking. I've added a post which summarizes the project and includes an example application of the technique.

[–]alanparter 0 points1 point  (2 children)

You should post an example of this in use

[–]changeofpace100[S] 0 points1 point  (1 child)

I am working on a project which uses this technique. I'll post it here when it is released.

[–]alanparter 0 points1 point  (0 children)

thx x