UCR remaps any controller onto a virtual device on Windows

One device, pretending to be another

Universal Control Remapper is a Windows application that allows the end user to remap any inputs from devices, such as keyboards, mice, joysticks, racing wheels and eye trackers, to virtual output devices. Remapping is achieved by transforming inputs through plugins to a desired output device.

That sentence contains the whole product. A user has a physical device, for example a flight stick or a set of keyboard keys, and wants a game to see something else: a virtual Xbox controller, a virtual DirectInput gamepad, a virtual mouse. UCR sits between the two. It reads the real device, applies the transformations the user configured, and emits the result on a virtual device that the game talks to as if it were hardware.

The project is a complete rewrite of the original UCR, created in collaboration with evilC, who is also the author of the IOWrapper library that UCR builds on. The rewrite matters for the plugin model, which is where the extensibility lives.

The feature list spells out what the rewrite bought. You can remap any number of inputs to any number of outputs on emulated output devices, with full analog support. Profiles and nesting allow for easy configuration, so a binding can be a group of mappings that you enable or disable as a unit, and those profiles can be nested. The remapping and the device order persist through reboots and unplugging of devices, which is the detail that separates a tool you use daily from a demo. And profiles can be switched by external programs through command line parameters, so a launcher script or a companion application can change what the game sees.

The audience is the player with unusual hardware, the accessibility user who needs a mouse to look like a controller, and the developer of a peripheral that no game supports. The project labels itself Alpha, and the topics attached to the repository say the same thing: directinput, hid, joystick, keyboard, mouse, vigem, xinput, remapping, plugin, input-output.

The plugin pipeline is the architecture

UCR supports input and output devices through plugins using the IOWrapper backend, and the readme notes the version it was built against in the badge, IOWrapper v0.11.2.

The separation of concerns is clean enough to describe in one line. A provider reads from a device, a plugin transforms what the provider produces, and an output provider writes the transformed result to a virtual device. The plugins in the middle are where a user configures their mappings, and they are also the extension point.

That extension point is the reason the project is worth studying even if you never install it. The readme says UCR is released with standard plugins but can be extended with third party plugins to add additional device support, and the downloads section points at a separate UCR-Plugins repository for extra experimental or niche plugins. And there is a second extension mechanism, which is the reason the feature list includes the line about remapping your own or unsupported input and output devices through extension support for device providers.

So there are two ways in. A plugin adds a new device or a new transformation, and a device provider adds a device that the existing plugin chain can already drive. The first is for the community, the second is for the person with the odd piece of hardware nobody else has.

The readme is also explicit about a practical dependency. You may also need to install other drivers, for example to allow creation of virtual Xbox or DirectInput controllers, and it points at the Providers page in the wiki for the details on these. That page is the one to read before an install, because a virtual output device is a kernel level component and the tool does not ship all of them.

What it reads and what it writes

The device support section is a list of what the standard plugins handle, and it is more interesting than it first looks.

On the input side there are Xbox 360 controllers over XInput, DirectInput controllers which includes gamepads, racing wheels and HOTAS style controllers, the keyboard and the mouse, both through the interception driver, and a Tobii eye tracker. On the output side there is an Xbox 360 controller over ViGEm, a Dualshock 4 over ViGEm, a DirectInput controller over vJoy, and the keyboard and mouse over interception again.

So the same physical device can appear to a game as something else entirely. A racing wheel on DirectInput can be presented as an XInput pad, a keyboard can be presented as a mouse, and an eye tracker can be turned into a stick. That last case is the clearest example of why the tool exists, since no game supports an eye tracker as input.

The driver choice per device is not incidental, because it determines what a game can see. ViGEm produces a virtual Xbox controller, vJoy produces a virtual DirectInput device, and interception is a kernel level driver that can filter and rewrite real keyboard and mouse input. The readme also mentions HidGuardian support through HidCerberus for true HID remapping, which is a different mechanism from the virtual device route, since it hides the real device from a program and presents a modified one in its place.

The cost of all this is a set of drivers that need to be installed and, in the case of interception and HidGuardian, that hook the operating system. The Providers page in the wiki is the reference for that, and it is a page a user will need.

No injection, and why that matters for games

One line in the feature list is the reason to prefer this tool over the other approaches to the same problem, and it is worth pulling out.

The feature list says the application uses no injection, making it compatible with games using anti-tampering technologies, such as Denuvo.

The distinction is architectural. An injector takes over the target process and feeds it input, which is a well known technique and also a well known signature. Anti-tamper systems watch for exactly that, and a tool that injects into a protected game gets the user banned. UCR does not touch the game process at all. It sits below it, at the driver level, and presents a virtual device. The game receives input from a device, the same as it would from a real pad, and there is nothing in the process to detect.

That is why HidGuardian and HidCerberus are in the picture, and why the output providers matter as much as the input providers. The game is not being fooled by a fake message; it is being handed a device that the operating system reports as real.

The trade-off is that the tool now requires kernel level components, which is a heavier install than a userspace remapper and a bigger security surface on the machine. But for the specific case of a protected game, it is the only approach that works at all, and the readme is clear that this is a deliberate design decision rather than an accident.

Building it needs a PowerShell script and an old Visual Studio

The build instructions are short and dated, which is itself a signal.

The readme says it is required to run the build script before building with Visual Studio, and that you should run .\build.ps1 InitProject from powershell to initialize the required dependencies. All subsequent builds can be done from Visual Studio 2017.

So the workflow is a one time dependency initialisation followed by an ordinary IDE build. The repository supports that with build.ps1 for PowerShell, build.cmd and build.sh for the other shells, a build/ directory, and a .nuke file, which is the configuration for the Nuke build tool that the build scripts drive. The .gitmodules and submodules/ directory cover the third party components, and the solution is UCR.sln with UCR.Core, UCR.FileHandler, UCR.Plugins, UCR.Tests and the UCR application itself. Versioning is handled by GitVersion.yml, and the continuous integration is appveyor.yml.

The Visual Studio 2017 instruction is the part to flag. A tool that still says 2017 has not been updated for the current tooling, and on a current machine you will be building a 2019 era .NET Framework or .NET Core solution with a modern toolchain, which may need adjustments nobody has made because there have been no tagged releases since 2020.

The test project, UCR.Tests, and the CI configuration are the reason to think it still works at all. The readme also says that test builds, patches, updated components and new or enhanced plugins are often posted to the UCR channel in the HidWizards Discord server, and that if you encounter problems it is best to check that channel for pinned patches. That is the real distribution channel for anything newer than the last release.

A release history that stopped in 2020

The maintenance picture needs the two facts side by side.

The repository is not archived, and the last push was on 2026-04-29. The release history, on the other hand, is v0.7.0 on 2019-01-03, v0.8.0 on 2019-07-27 and v0.9.0 on 2020-01-02, and every one of those release titles says Alpha. So the code has been touched this year, and the last downloadable build is more than six years old.

That is a normal shape for a desktop utility whose community distributes patched builds through a Discord channel, and the readme supports that reading, telling users that test builds, patches and updated components are often posted to the UCR channel in the HidWizards Discord server, and that the channel is where to look for pinned fixes. The support guidance is the same: raise an issue on the tracker or join the HidWizards chat channel on Discord, and the readme asks people not to use the UCR thread on the AutoHotkey forums, which is a sign of how much traffic that project has absorbed.

So the honest read is that the project is alive in the sense that its code moves, and that the thing you install from the releases page is six years old. Anyone evaluating it should plan to build from source, which means reading the build script and the Providers page rather than trusting the installer.

The licence is MIT, and the readme states plainly that Universal Control Remapper is open source software released under the MIT license.

Editorial conclusion

UCR is worth adopting if you need one device to look like another to a game, particularly for games with anti-tampering that reject injected input, because the no-injection design is the whole point of the tool. It is the wrong choice if you need a maintained release, since the last tagged version is v0.9.0 from 2020-01-02 and the documented build path still says Visual Studio 2017, and it is the wrong choice if you need to remap on Linux or macOS, because it is a Windows application built on DirectInput, XInput and Windows drivers. Before you install it, read the Providers page in the wiki for the driver setup your chosen output needs, and note that the last push was on 2026-04-29.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. Snoothy/UCR on GitHub