Injecting Code Into Mouse Firmware Should Be Your Next Hack

Here’s a DEF CON talk that uses tools you likely have and it should be your next hacking adventure. In their Saturday morning talk [Mark Williams] and [Rob Stanely] walked through the process of adding their own custom code to a gaming mouse. The process is a crash course in altering a stock firmware binary while still retaining the original functionality.

The jumping off point for their work is the esports industry. The scope of esporting events has blown up in recent years. The International 2016 tournament drew 17,000 attendees with 5 million watching online. The prize pool of $20 million ($19 million of that crowdfunded through in-game purchases) is a big incentive to gain a competitive edge to win. Contestants are allowed to bring their own peripherals which begs the questions: can you alter a stock gaming mouse to do interesting things?

The steelseries Sensei mouse was selected for the hack because it has an overpowered mircocontroller: the STM32F103CB. With 128 KB of flash the researchers guessed there would be enough extra room for them to add code. STM32 chips are programmed over ST-Link, which is available very inexpensively through the ST Discovery boards. They chose the STM32F4DISCOVERY which runs around  $20.

Perhaps the biggest leap in this project is that the firmware wasn’t read-protected. Once the data, clock, and ground pads on the underside of the board were connected to the Discovery board the firmware was easy to dump and the real fun began.

They first looked through the binary for a large block of zero values signifying unused space in flash. The injected firmware is designed to enumerate as a USB keyboard, open Notepad, then type out, save, and execute a PowerShell script before throwing back to the stock firmware (ensuring the mouse would still function as a mouse). Basically, this builds a USB Rubber Ducky into stock mouse firmware.

There are a few useful skills that make taking on this project a worthwhile learning experience. To compile your custom code correctly you need to choose the correct offset address for where it will end up once pasted into the firmware binary. The vector table of the original code must be rewritten to jump to the injected code first, and it will need to jump back to the mouse execution once it has run. The program flow on the left shows this. Both of these jumps require the program counter and registers to be saved and restored. The ARM stack is subtractive and the address will need to be updated to work with the added code.

The talk ended with a live demo that worked like a charm. You can check out the code in the MDHomeBrew repo. In this case the PowerShell script adds keyboard shortcuts for DOOM cheats. But like we said before, the experience of getting under the hood with the firmware binary is where the value will be for most people. With this success under your belt you can take on more difficult challenges like [Sprite_TM’s] gaming keyboard hack where the firmware couldn’t easily be dumped and an update binary was quite obsfucated.

18 thoughts on “Injecting Code Into Mouse Firmware Should Be Your Next Hack

    1. You’re confusing write protection with read protection. It’s almost always possible to just wipe the chip and put your own code on it, but it’s a lot harder if you want to reuse the existing firmware – you have to get a copy of it first. Almost no product gets released without read protection enabled.

      1. How exactly does the read protection work? How does the flash memory know if it is being read by an authorized entity (i.e. the peripheral’s processor) vs by an unauthorized entity (i.e. a ‘hacker’ using some flash reading tool)?

        In my Kinect V2 I have some Winbond W25Q64FV:
        3V 64M-BIT
        SERIAL FLASH MEMORY WITH
        DUAL/QUAD SPI & QPI
        I have its datasheet, and was hoping I would be able to extract the contents when I find the time/priority, but from what you say I fear this would be impossible?

        I fail to understand how the flash memory device knows if whatever circuit it is connected in is authorized or not?

        1. The read protection applies to the flash memory INSIDE the microcontroller chip.

          In your case, separate flash chips, there’s no read protection, but there could be encryption.

    2. Okay I can understand your confusion, “locking down the memory” does not prevent you from over writing it, it prevents you from reading it. They “lock down the memory” to prevent people in china from making clones. They don’t give a fuck if you turn a thermostat into an arduino.

      1. I once watched a colleague rip apart a supposedly high security card reader that was read-protected. Ingenious solution, but the short version is that there are other behaviours that you can co-opt into helping you with exfiltration. One keyword would be “stack”. That’s easier than dissolving chip casings and using microscopes and nanowire probes :)

    1. It’s counterintuitive, but sometimes chips that are exactly what you need are more expensive than something vastly more powerful due to the more powerful chips being more widely used. Economy of scale is a hell of a thing.

    2. Evaluating the sensor data does take a bit of doing, it doesn’t ‘magically’ get the position/movement you know.
      Plus people want ‘profiles’ now with gaming mice.

      1. no, sensor evaluates all of this stuff in hardware and outputs processed delta of movement in X/Y axis. Microcontrollers job is just being a glorified serial-to-USB converter.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s