Reverse-engineer the Xbox 360 kernel to add native support for new controllers

A Redditor had Claude Code reverse-engineer a modded Xbox 360's USB stack and write a kernel driver so up to four Series X|S controllers work over Microsoft's wireless adapter.

Done withClaude Code· Oct 27, 2026

What they did

The poster, u/Hot-Ad2974, wanted Microsoft's USB wireless adapter for Series X|S controllers to work on a modded Xbox 360, which never supported it. Claude Code was given Ghidra through an MCP server, a PowerPC cross-compiler and the console's debug port. It mapped the 360 kernel's undocumented USB stack and the input path the dashboard uses, ported the open source Linux driver xone (radio setup, pairing, the ECDH handshake and the controller protocol) into portable C, wrote the console side as a kernel-mode system DLL, and added function hooks to feed the controllers into the normal input system. The driver wrote a status block and a log ring into memory, and Claude ran the build, upload and read-logs loop by itself.

How it went

It works: up to four controllers connect wirelessly with rumble and a working Guide button, in the dashboard and in games, loading at boot. Along the way Claude tracked down a register-size mismatch between toolchain and kernel, floating point use in code with no FP context, a deadlock when Guide was pressed, a starved driver thread, and adapters ignored when plugged in before boot. The poster did the physical work: plugging in, pairing, rebooting hung consoles and describing the screen. It is released as GPL-3.0 and others were only starting to test it.

Worth knowing

The poster credits the setup more than the model: give the agent a way to read the target's state after every test, and turn each bug it learns from into a build check so it stays fixed. It needs a modded console on kernel 17559. Early release, so outside reports were still thin.

Try it

With Claude Code· 7 parts to fill in

Help me write a driver for [device] on [target system], which has no support for it. You have [a disassembler via MCP], [the cross-compiler] and [a debug connection to the target]. First map the relevant undocumented parts of the target and write up what you find. Port the protocol logic from [existing open source driver] into portable code. Make the driver write a status block and log into memory you can read after each test, then run build, upload and read-logs yourself. Every time a bug teaches you a rule, add a build check for it. Tell me exactly what to plug in, press or reboot when you need hands, and stop when [the device works end to end].

Square brackets are the parts to fill in. The prompt is ours; the story is theirs.

Where they said it

Related