This Week In Security: Pacman, Hertzbleed, And The Death Of Internet Explorer

June 17, 2022 by Jonathan Bennett 25 Comments

There’s not one, but two side-channel attacks to talk about this week. Up first is Pacman, a bypass for ARM’s Pointer Authentication Code. PAC is a protection built into certain ARM Processors, where a cryptographic hash value must be set correctly when pointers are updated. If the hash is not set correctly, the program simply crashes. The idea is that most exploits use pointer manipulation to achieve code execution, and correctly setting the PAC requires an explicit instruction call. The PAC is actually indicated in the unused bits of the pointer itself. The AArch64 architecture uses 64-bit values for addressing, but the address space is much less than 64-bit, usually 53 bits or less. This leaves 11 bits for the PAC value. Keep in mind that the application doesn’t hold the keys and doesn’t calculate this value. 11 bits may not seem like enough to make this secure, but keep in mind that every failed attempt crashes the program, and every application restart regenerate the keys.

What Pacman introduces is an oracle, which is a method to gain insight on data the attacker shouldn’t be able to see. In this case, the oracle works via speculation attacks, very similar to Meltdown and Spectre. The key is to attempt a protected pointer dereference speculatively, and to then observe the change in system state as a result. What you may notice is that this requires an attack to already be running code on the target system, in order to run the PAC oracle technique. Pacman is not a Remote Code Execution flaw, nor is it useful in gaining RCE.

One more important note is that an application has to have PAC support compiled in, in order to benefit from this protection. The platform that has made wide use of PAC is MacOS, as it’s a feature baked in to their M1 processor. The attack chain would likely start with a remote execution bug in an application missing PAC support. Once a foothold is established in uprivileged userspace, Pacman would be used as part of an exploit against the kernel. See the PDF paper for all the details.

Continue reading “This Week In Security: Pacman, Hertzbleed, And The Death Of Internet Explorer” →

An array of open-source clocks that play Pac-Man (or Mrs. Pac-Man).

ESP32 Pac-Man Clock Keeps Track Of How Long You Watch It

November 23, 2021 by Kristina Panos 1 Comment

There are so many elements that make a good clock worth looking at for much longer than necessary. Not only is this clock quite cool to behold, it plays Pac-Man around the time! Yes, of course you can interact with the Pac-Man — touching the edges of the screen will make him go left, right, up, or down accordingly. You can also change to Ms. Pac-Man and make all the animations go normal speed, fast, or crazy-fast.

[TechKiwiGadgets] built a Pac-Man clock a few years ago that was well-received, but not cheap or easy to mimic. Since then, they have ported the code to the ESP32 and made a new version that has fewer and friendlier components. Not only that, they have great instructions for building the ESP32 shield on protoboard and also offer the shield as an open-source fab-able PCB. Still too much work? The complete kit version is available over on Tindie. Be sure to check it out in crazy speed mode action after the break.

Although this isn’t the first Pac-Man clock we’ve seen, it devotes equal attention to the time and the game, whereas this one is more about the game itself.

Continue reading “ESP32 Pac-Man Clock Keeps Track Of How Long You Watch It” →

Pac Man On The Colour Computer 3

September 6, 2017 by Lewin Day 12 Comments

The 1980s were the heyday of the venerable Z80, a processor that found its way into innumerable home computers, industrial systems, and yes — arcade machines. However, not everyone had a Z80 based machine at home, and so sometimes porting is required. [Glen] is tackling this with a port of Pac Man to the Radio Shack Colour Computer 3.

The key to any good arcade port is authenticity – the game should feel as identical to the real thing as possible. The Atari 2600 port got this famously wrong. Porting to the Colour Computer 3 is easier in theory – with more RAM, a Motorola 6809 CPU running at a higher clock rate, and a more powerful graphics subsystem, fewer compromises need to be made to get the game to run at a playable speed.

The way [Glen] tackled the port is quite handy. [Glen] built a utility that would scrape a disassembled version of the original Pac Man Z80 code, look up the equivalent 6809 CPU instruction, and replace it, while placing the original Z80 code to the side as a comment. Having the original code sitting next to the ported instructions makes debugging much easier.

There was plenty of hand tweaking to be done, and special effort was made to make sure all the data the original code was looking for was accessible at the same addresses as before. There was also a lot of work involved in creating a sprite engine that would reliably display the game video at a playable frame rate.

Overall, the port is highly faithful to the original, with the game code being identical at the CPU level. [Glen] reports that the same patterns used on the arcade machine can be used to complete the mazes on the Colour Computer 3 version, and it faithfully recreates the Level 256 bug as well. It’s an impressive piece of work to create such an authentic port on a home computer from 1986.

For another classic port, but with the temporal vectors flipped, check out Portal 2 on the Apple II.

Pacman Proves Due Is More Than Uno

January 30, 2016 by Elliot Williams 28 Comments

If you’re wondering what the difference is between the good ol’ Arduino Uno and one of the new-school Arduinos like the Arduino Due, here’s a very graphic example: [DrNCX] has written a stunning Pacman clone for the Due that seems to play just like the arcade. (Video embedded below the break.)

The comparison between the Uno and Due isn’t quite fair. The Due runs on an 84 MHz, 32 bit ARM Cortex-M3 processor. It’s in a different league from the Uno. Still, we view this as an example of the extended possibilities from stepping up into a significantly faster micro. For instance, the video is output to both an ILI9341 TFT screen and external 8-bit VGA at once.

Besides using some very nice (standard) libraries for the parts, it doesn’t look like [DrNCX] had to resort to any particular trickery — just a lot of gamer-logic coding. All the code is up on GitHub for you to check out.

Can the old Arduinos do this? For comparison, the best Pacman we’ve seen on an AVR platform is the ATmega328-based RetroWiz, although it is clocked twice as fast as a stock Uno. And then there’s Hackaday Editor [Mike Szczys]’s 1-Pixel Pacman, but that’s cheating because it uses a Teensy 3.1, which is another fast ARM chip. People always ask where the boundary between an 8-bit and 32-bit project lies. Is a decent Pacman the litmus test?

Continue reading “Pacman Proves Due Is More Than Uno” →

Pac-Man Clock Eats Time, Not Pellets

February 5, 2015 by Rick Osgood 21 Comments

[Bob’s] Pac-Man clock is sure to appeal to the retro geek inside of us all. With a tiny display for the time, it’s clear that this project is more about the art piece than it is about keeping the time. Pac-Man periodically opens and closes his mouth at random intervals. The EL wire adds a nice glowing touch as well.

The project runs off of a Teensy 2.0. It’s a small and inexpensive microcontroller that’s compatible with Arduino. The Teensy uses an external real-time clock module to keep accurate time. It also connects to a seven segment display board via Serial. This kept the wiring simple and made the display easy to mount. The last major component is the servo. It’s just a standard servo, mounted to a customized 3D printed mounting bracket. When the servo rotates in one direction the mouth opens, and visa versa. The frame is also outlined with blue EL wire, giving that classic Pac-Man look a little something extra.

The physical clock itself is made almost entirely from wood. [Bob] is clearly a skilled wood worker as evidenced in the build video below. The Pac-Man and ghosts are all cut on a scroll saw, although [Bob] mentions that he would have 3D printed them if his printer was large enough. Many of the components are hot glued together. The electronics are also hot glued in place. This is often a convenient mounting solution because it’s relatively strong but only semi-permanent.

[Bob] mentions that he can’t have the EL wire and the servo running at the same time. If he tries this, the Teensy ends up “running haywire” after a few minutes. He’s looking for suggestions, so if you have one be sure to leave a comment. Continue reading “Pac-Man Clock Eats Time, Not Pellets” →

Turning The Wii Classic Controller Into A Gaming Rig

June 21, 2012 by Mike Szczys 3 Comments

A bit of clever design lets you mount a screen and gaming hardware right on this controller. [Valentin Ivanov] had already been using the Wii Classic Controller Pro as an input for his Gadgeteer-based projects. He wanted a way to marry the project board, display, and controller into one single unit.

We’re huge fans the design because it doesn’t require any alteration of the controller. Instead, five carefully designed pieces were cut from some thin plywood. They lock together into an assembly that embraces the top of the controller while providing plenty of mounting options for the prototyping hardware thanks to a large grid of holes. A couple of pieces of bronze rod lock the mounting bracket in place by keying into the screw holes in the bottom of the controller.

In the image above you can see Mini Pacman running on the rig. It’s now nearly portable, only relying on a barrel jack for power but we’re sure a battery pack could stand in if necessary.

AVGA: The AVR Based Video Game Platform

August 12, 2009 by Nick Caiello 16 Comments

avrvideogame

We’ve seen our fair share of AVR projects, but this one’s pretty cool. AVGA is a color video game development platform based on the Atmel AVR family of microcontrollers. As seen in the picture above, one of the AVRs that the project uses is the popular ATMega168. There were several technical hurdles to using the AVRs to run color video games; one of the most difficult problems was figuring out a way to display detailed graphics from AVRs limited onboard RAM. Eventually, the developers figured out a way to display detailed graphics using a TILE-based driver. The TILE driver works by dividing the screen into X and Y coordinates, dividing the graphics into tiles. Then, when a graphic is needed it’s addressed from a reference table that’s stored in the AVR’s onboard RAM, allowing the bitmap graphic to be loaded from a game’s ROM. Currently, the only games available for the platform are a Super Mario clone, a Pacman clone, and a Snake clone. While there are only a few games available, the platform definitely looks promising. If anything, this project serves as a great example for what off the shelf microcontrollers are capable of.