[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.

With modern tools, you have to try very hard to do something stupid, because the tools (rightly) recognize you’re doing something stupid. [Andreas Karlsson] can speak to that first hand as he tried to get four billion if statements to compile.

You may ask what state space requires four billion comparisons to evaluate? The answer is easy: the range of an unsigned 32-bit integer. The whole endeavor started with a simple idea: what if instead of evaluating whether an integer is even or odd with a modulo or bit mask, you just did an if statement for every case? Small ranges like 0-10 are trivial to write out by hand, but you reach for more automated solutions as you pass 8 bits and move towards 16. [Andreas] wrote some Python that outputs a valid C program with all the comparisons. For 16 bits, the source only clocks in at 130k lines with the executable less than 2 MB.

Of course, scaling to 32 bits is a very different problem. The source file balloons to 330 GB, and most compilers barf at that point. Undeterred, [Andreas] modified the Python to output x86_64 assembly instead of C. Of course, the executable format of Windows (PE) only allows executables up to 4 GB, so a helper program mapped the 40 GB generated executable and jumped into it.

What’s incredible about this whole journey is how performant the program is. Even large numbers complete in a few seconds. Considering that it has to thrash 40 GB of an executable through memory, we can’t help but shake our heads at how even terrible solutions can work. We love seeing someone turn a bad idea into an interesting one, like this desoldering setup.

Making something enjoyable often requires a clever trick. It could be a way to cut something funny or abuse some peripheral in a way it was never designed for. Especially good tricks have a funny way of coming up again and again. [DERAILED3D] put a 3d printed benchy in a bottle with one of the best tricks 3d printing has.

The trick is stopping the print part way through and tweaking it. You can add manual supports or throw in some PTFE beads to make a generator. The benchy isn’t the print being paused; the bottle is. The benchy is a standard print, and the bottle is clear resin. Once halfway through, they paused the print, and the benchy was left suspended in the bottle with a bit of wire. Of course, [DERAILED3D] moved quickly as they risked a layer line forming on the delicate resin after a minute or two of pausing. The difficulty and mess of tweaking a gooey half-finished resin print is likely why we haven’t seen many attempts at playing with the trick, but we look forward to more clever hacks as it gets easier.

The real magic is in the post-processing of the bottle to make it look as much like glass as possible. It’s a clever modern twist on the old ship in the bottle that we love. Video after the break.

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.

For many, the voice assistants are helpful listeners. Just shout to the void, and a timer will be set, or Led Zepplin will start playing. For some, the lack of flexibility and reliance on cloud services is a severe drawback. [John Karabudak] is one of those people, and he runs his own voice assistant with an LLM (large language model) brain.

In the mid-2010’s, it seemed like voice assistants would take over the world, and all interfaces were going to NLP (natural language processing). Cracks started to show as these assistants ran into the limits of what NLP could reasonably handle. However, LLMs have breathed some new life into the idea as they can easily handle much more complex ideas and commands. However, running one locally is easier said than done.

A firewall with some muscle (Protectli Vault VP2420) runs a VLAN and NIPS to expose the service to the wider internet. For actually running the LLM, two RTX 4060 Ti cards provide the large VRAM needed to load a decent-sized model at a cheap price point. The AI engine (vLLM) supports dozens of models, but [John] chose a quantized version of Mixtral to fit in the 32GB of VRAM he had available.

However, how do we get the model to control devices in the home? Including the home state in the system portion of the prompt was easy. Getting instructions for HomeAssistant to follow is harder. While other models support “Function calling,” Mixtral does not. [John] tweaked the wrapper connecting vLLM and HomeAssistant to watch for JSON at the end. However, the model liked to output JSON at the end even if it wasn’t asked to. So [John] added a tag that the model adds when the user has a specific intent.

In the end, [John] has an intelligent assistant that controls his home with far more personality and creativity than anything you can buy now. Plus, it runs locally and can be customized to his heart’s content.

It’s a great guide with helpful tips to try something similar. Good hardware for a voice assistant can be hard to come by. Perhaps someday we’ll get custom firmware running on the existing assistants we already have to connect to your local assistant server?

In the wide world of programming, there are a few dark corners that many prefer to avoid and instead leverage the well-vetted libraries that are already there. [Phillip Tennen] is not one of those people, and when the urge came to improve font rendering for his hobby OS, axle, he got to work writing a TrueType font renderer.

For almost a decade, the OS used a map table encoding all characters as 8×8 bitmaps. While scaling works fine, nonfractional scaling values are hard to read, and fractional scaling values are jagged and blocky. TrueType and font rendering, in general, are often considered dark magic. Font files (.ttf) are structured similarly to Mach-O (the binary format for macOS), with sections containing tagged tables. The font has the concept of glyphs and characters. Glyphs show up on the screen, and characters are the UTF/Unicode values that get translated into glyphs by the font. Three critical tables are glyf (the set of points forming the shape for each glyph), hmtx (how to space the characters), and cmap (how to turn Unicode code points into glyphs).

Seeing the curtain pulled back from the format itself makes it seem easy. In reality, there are all sorts of gotchas along the way. There are multiple types of glyphs, such as polygons, blanks, or compound glyphs. Sometimes, control points in the glyphs need to be inferred. Curves need to be interpolated. Enclosed parts of the polygon need to be filled in. And this doesn’t even get to the hinting system.

Inside many fonts are tiny programs that run on the TrueType VM. When a font is rendered at low enough resolutions, the default control points will lose their curves and become blobs. E’s become C, and D’s become O’s. So, the hinting system allows the font to nudge the control points to better fit on the grid. Of course, [Phillip] goes into even more quirks and details in a wonderful write-up about his learnings. Ultimately, axle has a much better-looking renderer, we get a great afternoon read, and fonts seem a little less like forbidden magic.

Maybe someday [Phillip] will implement other font rendering techniques, such as SDF-based text renderers. But for now, it’s quite the upgrade. The source code is available on GitHub.