Claude Code Reverse-Engineers Xbox 360 Kernel, Writes Native Driver for Next-Gen Controller Compatibility

In the console modding community, getting Xbox Series X|S controllers to work natively on the Xbox 360 was long considered a daunting challenge. Microsoft's own Xbox Wireless Adapter (the USB receiver for Series X|S controllers) has never supported the Xbox 360, because its core is a MediaTek Wi-Fi chip that relies on the host console to handle firmware upload, RF configuration, pairing, the ECDH security handshake, and Microsoft's GIP controller protocol. There's a Microsoft driver on PC, xone on Linux, and nothing at all on Xbox 360.

A developer (Reddit user Jacckii) shared his results in the r/360hacks community: using Claude Code, he reverse-engineered the Xbox 360 kernel's USB stack and XAM input path, and wrote a native driver that lets up to four Series X|S controllers work wirelessly on the Xbox 360 as ordinary controllers, with rumble and Guide button support, functioning correctly in both the dashboard and games. The project is open-sourced under GPL-3.0, with the code published on GitHub.

Technical Challenge: Building Wireless Controller Support from Scratch

The Xbox 360 (kernel version 17559) has no support whatsoever for Series X|S controllers. The developer needed to implement the complete wireless communication stack, including the MT76 RF driver, pairing, the ECDH P-256 handshake, and the GIP protocol. Ready-made solutions exist on PC and Linux (such as xone), but the Xbox 360's kernel environment is entirely different: it's a PowerPC architecture, resource-constrained, and poorly documented closed-source system.

Claude Code first analyzed the undocumented USB stack (Usbd) and XAM input path in the 360 kernel at the disassembly level through a Ghidra MCP server, identifying the runtime USB class driver list, the transfer block layout, which DPC the callbacks execute on, and the callback table XAM uses for the Guide button. It then ported the MT76 RF code, pairing, ECDH handshake, and GIP protocol from xone into portable C code, and wrote a kernel-mode system DLL as the 360-side implementation. Finally, it wrote PowerPC function hooks that relocate instructions via trampolines to feed controller input into XInput.

The entire process was debugged on real hardware, reading memory through a debug monitor and verifying functionality step by step.

ECDH P-256 handshake: ECDH (Elliptic Curve Diffie-Hellman) is a key agreement protocol that allows two parties to generate a shared secret over an insecure channel. P-256 refers to the elliptic curve used (secp256r1), providing roughly 128-bit security strength. In the Xbox wireless controller scenario, the controller and console establish an encrypted link through the ECDH handshake to ensure that pairing and input data aren't eavesdropped on or tampered with. Since the Xbox 360 never supported this protocol, the developer had to fully implement the curve arithmetic and handshake state machine in the driver, which was one of the core difficulties when porting the xone code.

GIP protocol: GIP (Game Input Protocol) is Microsoft's proprietary protocol for communication between Xbox One and later controllers and the console, encapsulating input reports, rumble commands, Guide button events, and more. It runs on top of USB or wireless links, with specific packet formats and state machines. The Xbox 360 uses the earlier XInput protocol, so the driver needs to translate GIP packets into XInput-compatible input reports and handle the differences between the two in button mapping and rumble intensity ranges.

XAM and XInput: XAM (Xbox Application Manager) is the core component of the Xbox 360 system software responsible for the user interface, input routing, and system notifications; the Guide button's global response is handled by XAM. XInput, meanwhile, is the lightweight input API used by games, providing standardized controller state. The driver needs to interface with both: injecting controller data into XInput for games to read, and simulating the input events XAM expects to trigger the Guide menu. Understanding XAM's callback table structure was the key breakthrough in the reverse engineering.

PowerPC function hooks and trampolines: The Xbox 360 kernel runs on the PowerPC architecture. A function hook modifies the instructions at the target function's entry point to jump to custom code. A trampoline is a small piece of intermediate code responsible for saving the original instructions, relocating relative jumps, and then jumping back to the original function, thereby inserting new functionality without breaking the original logic. The driver uses trampolines to feed the controller input stream into the XInput call chain, a classic technique for kernel-level modifications.

Debugging Challenges: Hidden Traps in the Kernel Environment

During development, Claude Code tracked down and fixed several deep-seated bugs that reflect the peculiarities of the Xbox 360 kernel:

• Register width mismatch: The toolchain saved registers as 32-bit values, while the kernel expected 64-bit, requiring assembly thunks around every kernel callback.
• Missing floating-point context: Kernel DPCs have no floating-point context, but variadic functions still spill floating-point registers; the solution was to use soft floats and add build checks so that any floating-point instruction fails the build.
• Guide button deadlock: Pressing the Guide button caused the console to deadlock, because the thread supplying input to XAM was also calling XAM. The fix was to move each XAM call to a separate thread on another hardware thread.
• Driver thread starvation: The driver thread starved when the Guide was open; it turned out the kernel caps system thread priority at 9, so the driver's priority was raised to that value.
• Adapter inserted before boot ignored: The kernel maintains a list of unclaimed USB devices and has a routine that re-offers them to drivers; leveraging that mechanism solved the problem.

These fixes not only made the driver run stably but also revealed undocumented behaviors in the Xbox 360 kernel's USB and input handling.

A Human-AI Collaborative Workflow

The developer emphasizes that Claude Code was not fully autonomous but worked in close collaboration with a human. He summarized several key practices:

• Give the target "eyes": The driver writes state blocks and log rings to memory, and Claude Code reads them over the network after each test.
• Provide the right tools: Ghidra MCP for kernel analysis, a cross-compiler, and a console debug port. Claude Code autonomously runs the "build → upload → read logs" loop.
• Make errors fail at build time: Every hard-learned rule became a check in the build script, ensuring fixed bugs don't regress.
• The human as executor: The developer handles plugging in the adapter, pairing controllers, rebooting when the console hangs, and describing what's on screen.

This division of labor lets Claude Code focus on reverse engineering and code generation while the human handles physical operations and visual feedback, forming an efficient iterative loop.

Open Source and Community Feedback

Within hours of the project being posted on r/360hacks, users had already ordered adapters to test it. The developer says the project is still at an early stage and welcomes feedback. The open-source repository is on GitHub: Jacckii/Xbox360-Series-Controllers-Native.

This case demonstrates the potential of AI programming tools in reverse engineering and system-level development: Claude Code doesn't just generate code—through toolchain integration and automated test loops, it solves low-level problems that traditionally require extensive expert experience. For the console modding community, it means more old consoles can be brought back to life; for the field of AI-assisted development, it provides a model of human-AI collaboration tackling complex system tasks.

One-line Summary

A developer used Claude Code to reverse-engineer the Xbox 360 kernel and wrote a native driver that lets Series X|S controllers run wirelessly.