[Ryan Miceli] had spent a few years poring over and reverse-engineering Halo 2 when a friend asked for a favor. His friend created an improved Xbox with significant overclocks, RAM upgrades, BIOS hacks, and a processor swap. The goal was simple: patch the hardcoded maximum resolution from 480p to 720p and maybe even 1080p. With double the CPU clock speed but only a 15% overclock on the GPU, [Ryan] got to work.

Step one was to increase the size of the DirectX framebuffers. Increasing the output resolution introduced severe graphical glitches and rendering bugs. The game reuses the framebuffers multiple times as memory views, and each view encodes a header at the top with helpful information like width, height, and tiling. After patching that, [Ryan] had something more legible, but some models weren’t loading (particularly the water in the title screen). The answer was the texture accumulation layer. The Xbox has a hardware limitation of only sampling four textures per shader pass, which means you need a buffer the size of the render resolution to accumulate the textures if you want to sample more than four textures. Trying to boot the game resulted in an out-of-memory crash. The Xbox [Ryan] was working on had been upgraded with an additional 64MB of RAM, but the memory allocator in Halo 2 wasn’t taking advantage of it. Yet.

To see where the memory was going, [Ryan] wrote a new tool called XboxImageGrabber to show where memory was allocated and by whom. Most games make a few substantial initial allocations from the native allocator, then toss it over to a custom allocator tuned for their game. However, the extra 64MB of RAM was in dev consoles and meant as debug RAM, which meant the GPU couldn’t properly access it. Additionally, between the lower 64MB and upper is the Xbox kernel. Now, it became an exercise of patching the allocator to work with two blobs of memory instead of one contiguous one. It also moved runtime data into the upper 64MB while keeping video allocations in the lower. Ultimately, [Ryan] found it easier to patch the kernel to allow memory allocations the GPU could use in the upper 64MB of memory. Running the game at 720p resulted in only a semi-playable framerate, dropping to 10fps in a few scenes.

After some initial tests, [Ryan] concluded that it wasn’t the GPU or the CPU that was the bottleneck but the swap chain. Halo 2 turns VSync on by default, meaning it has to wait until a blank period before swapping between its two framebuffers. A simple tweak is to add a third frame buffer. The average FPS jumped 10%, and the GPU became the next bottleneck to tweak. With a light GPU overclock, the game was getting very close to 30fps. Luckily for [Ryan], no BIOS tweak was needed as the GPU clock hardware can be mapped and tweaked as an MMIO. After reverse engineering, a debugging feature to visual cache evictions, [Ryan] tuned the texture and geometry cache to minimize pop-ins that the original game was infamous for.

Overall, it’s an incredible hack with months of hard work behind it. The code for the patch is on Github, and there’s a video after the break comparing the patched and unpatched games. If you still need more Halo in your life, why not make yourself a realistic battle rifle from the game?

[Ryan Miceli] wanted to build some reverse engineering skills by finding a new exploit for an original Xbox. Where he ended up was an exploit that worked across the network, across several games, and several different consoles. But it all started with an unbounded strcpy in Tony Hawk Pro Skater (THPS).

Xbox, PlayStation 2, and Gamecube (often referred to as the sixth generation) are wonderful hacking targets as they don’t possess many of the security enhancements of the seventh generation, like hypervisors, privilege levels, and hardware executability protections. The console launches the game, and control is fully within the game, so once you get your code executing, you’re done. The exploit started with a feature in many Tony Hawk games, the custom map editor. In the editor, you can create gaps between jumps with a name so that when a player completes the gap, it can flash “you jumped x” in big letters. However, on Xbox, the gap name is copied with an unbounded strcpy to the stack, meaning you can overwrite the return pointer. Additionally, there are no stack cookies for THPS, which meant nothing stopped [Ryan] from smashing his way through. He includes a small memcpy stub in the header of the level, which the gap name jumps to, which then copies and executes his full payload.

The other games in the series, like Tony Hawk’s Pro Skater 3 (THPS3), had the bug, but the gap name was copied to the heap, not the stack. However, he could overflow into a vtable of the next object that would call his code when the object was freed. However, the level save data wasn’t an executable region of memory, which meant he needed ROP (return-oriented programming). Just a few gadgets later, and [Ryan] had another exploit working.

Tony Hawk’s Underground 1 and 2 had stack cookies turned on. This meant a random value was placed on the stack before a function, then popped off and checked. This meant the program could check if its stack had been smashed. Unfortunately for [Ryan], this proved to be a major roadblock. However, the PC and PS2 versions of these games do not have stack cookies, which means they can be exploited in the same manner.

The beauty of the exploit is that the game allows you to invite a friend to play a custom level. This means once the level is transferred over the network, their console is hacked as well. However, the full payload wasn’t sent to the client console, which meant the exploit had to send the payload to the other console using the game’s existing net code. The exploit sets up an asynchronous file transfer then hands control back to the game. Of course, there was a memory leak in the netcode, because the game had never sent large amounts of data over the network before. So, part of the exploit was a hot patch for a memory leak.

As a last hurrah, [Ryan] ported the hack to Gamecube, PS2, and PC. The code is on GitHub, and the video is after the break. We love the attention the Xbox has been getting, and if you’re curious about a hardware hack, this 256MB ROM mod goes deep into the internals.

It has been two years, but the slow and steady progress that [Doug Brown] has been making towards bringing a modern Linux kernel to the Chumby has approached the point that it could be called done. In his final blog post of the series, [Doug] walks through the highs and lows of the whole process.

Many of the changes [Doug] and others have made are already upstream in the Linux mainline. However, some will likely remain in private branches for a few reasons that [Doug] gets into. The blog post covers every commit needed to turn a Chumby or other Marvell ARMADA-powered widget into a working device. At the end of the day, what does [Doug] have to show? He can turn it on, see a boot logo, and then see an indefinite white screen. While underwhelming to most of the world, an X server is coming up, Wi-fi is online, the time syncs from an NTP server, and the touchscreen is ready to be tapped. A white screen, yes, but a white screen of potential. [Doug] has to decide what to launch after boot.

However, the future of the Chumby and other older devices is still on the chopping block of progress. Compiler writers want to drop support for platforms that nobody uses anymore, and the Chumby is ARMv5. With many changes destined to languish, [Doug] still considers it a huge success, and we do too. The whole series represents a journey with beautiful lessons about the power of the Linux device tree, making the dark and scary world of Linux kernel drivers seem a little more approachable.

We’ve covered the first post and when graphics started coming along. We salute the mighty Chumby and the idea it stood for. Of course, the idea of a handy screen displaying information is still alive and well. This handy e-paper HomeAssistant display is just one of many examples.