Hacking Hard Drive Firmware

May 15, 2026 by Al Williams 18 Comments

You probably flash new firmware on a variety of devices regularly, even though that’s rare for non-technical types. But what about your hard drive firmware? Most of us don’t want to touch our operating drives, so unless you are dealing with surplus drives or have a special project in mind, you may not think much about the firmware running your spinning rust storage. [I Code 4 Coffee] uses hard drives in an unusual way to exploit Xbox 360s, and wound up reverse engineering some drive firmware with an eye to making changes.

The analysis started with three hard drives and an SSD. Looking for people who’ve done similar work wasn’t as productive as you might think. There isn’t much call for modifying hard drive firmware, and what data there is can be outdated.

One thing that was available was firmware dumps taken with a PC-3000 data recovery tool. What follows is a deep dive down the hard drive rabbit hole. There are backdoor vendor commands and connections to the diagnostic RS-232 port on some drives. You can find the technical artifacts on GitHub.

We learned a few things, and we bet you will too. Another way to get into the hard drive’s firmware is via JTAG.

The Dark Side Of Unitree Robot Dogs

May 12, 2026 by Maya Posch 31 Comments

Arbitrary command execution with the Wi-Fi password. (Credit: Benn Jordan)

Continuing on his quest to expose the dark underbelly of modern technology, [Benn Jordan] recently did a deep-dive into the rise of so-called robot dogs. Although their most striking resemblance with biological dogs is that they also have four legs and generally follow commands, [Benn] found many issues with them that range from safety issues due to limited sensory capabilities, to basic security vulnerabilities, all the way to suspicious network traffic from Unitree’s robot dog firmware.

Although not the only seller of this type of quadruped robot, Unitree Robotics has made a name for itself by offering very capable and yet very cheap products. Their basic quadruped robot costs only a few thousand clams and features Lidar and heaps of processing power, all of which should make it a pretty useful device.

Despite this, [Benn] found that the original task that he’d envisioned for the robot, as in protecting his chickens from uninvited visitors, wouldn’t quite work as the robot is rather blind. The reason for this is the placement of the Lidar below the head, which obscures most of what’s behind and around the robot. Rather than risk trampled chickens and chicks, this plan was thus abandoned.

When digging further into the robot, he found an easy to exploit arbitrary command execution flaw via the Wi-Fi password entry field, a year-old CVE-2025-2894 exploit, as well as highly suspicious traffic to Chinese servers whenever the robot’s software figured that it was not being watched. It’s not just their dogs either: UniTree’s humanoid robots are also succeptible.

Although much of this can be circumvented with hacks, issues like the sensory limitations and general distrust of firmware updates makes using these robots a rather daunting and often ill-advised proposition.

Continue reading “The Dark Side Of Unitree Robot Dogs” →

Reverse-Engineering And Documenting The Fisher Price Pixter

May 11, 2026 by Maya Posch 8 Comments

Between 2000 and 2002 the Fisher Price Pixter was sold to children as an educational handheld toy with a touch screen that enabled drawing and listening to music in addition to cartridge-based games and more. It was followed up by multiple new iterations of the system, but as an ecosystem didn’t last beyond 2007. This has left much of the system in obscurity, with people like [Dmitry] doing their best to reverse-engineer, dump and document what they can, such as recently for the entire range of Pixter devices and most of the games.

One of the reasons why [Dmitri] got interested in the second-generation Pixter Color originally was as a potential PalmOS porting target, which gives somewhat of an idea of how these devices were meant to be used.

With absolutely no remaining known official documentation on how to develop software for the hardware reverse-engineering posed somewhat of a challenge. Fortunately this was made somewhat easier by the Pixter Color using the ARM-based LH7541, but worse by just how much of a minimal ARM7 implementation the SoC is. This was meant to go into a cheap-ish kid’s toy after all.

Where things got wild was that the firmware implements a 16-bit stack-based virtual machine, possibly due to initially having selected a completely different SoC. From here things get even crazier with how audio output is implemented, with [Dmitry] descending into a long-winded rant on this and all the weird things encountered during reverse-engineering.

After the Color Pixter its Multimedia sibling with slightly better SoC was also reverse-engineered, as well as the Classic device that started it all. This particular device uses an 8-bit VM, but a black-blob 6502 processor, which is rather astounding for a 2000-era device, but then again it was meant to be a toy.

In addition to getting a lot of reverse-engineering woes off his chest, [Dmitri] also details how he reverse-engineered and dumped the cartridges, as well as writing emulators to ensure that the Pixter legacy will endure, for better or worse.

Top image: Pixter with opened case. (Credit: Raimond Spekking, Wikimedia)

Reverse-engineering The 1998 Ultima Online Demo Server

May 8, 2026 by Maya Posch 5 Comments

In any MMORPG, the average user will generally only encounter the client side of the system. This makes building a compatible open source version of the proprietary server into a bit of a chore. Of course, sometimes you get a bit of a break, such as with the – still active – MMORPG Ultima Online, when the disc for the 1998 The Second Age expansion contained a stand-alone demo. This also meant a (stripped-down) server which has been gratefully reverse-engineered by the community, with [draxinar] now claiming to have made the most complete server based on this demo server.

To make things extra challenging, the originally written in C++ server binary was reverse-engineered into C99 code, meaning that the use of classes and associated vtables had to be left intact, just without the critter comforts provided by C++.

The total process took about a decade with occasional progress, with the current server binary being mostly identical to a 1998-era Ultima Online server. Some features that were stubbed out or disabled in the demo server had to be re-enabled or reimplemented, including the user account system.

Features that were left out of the final release like the ecology system were also enabled in so far as they were implemented. Although there is probably still a lot more work to be done on the code, [draxinar] reckons that this is a good point for the community to get involved to do some testing and provide feedback. There are also some missing server-related resource files that may still be saved somewhere.

Thanks to [adistuder] for the tip.

Running DOOM On A Travel Router With Touch Screen

May 1, 2026 by Maya Posch 11 Comments

Continuing his quest to put DOOM on literally everything that has a capable enough processor and a screen, [Aaron Christophel]’s most recent target is a Slate 7 Pro travel router. With a generous 2.8″ touch screen and a lot of onboard processing power to handle all the advertised networking and routing features via its WAN and (W)LAN interfaces, it should be able to run the game really quite well. As usual the main question is how to get the game to run on it first.

The port of choice is fbdoom, with instructions on how to run it on this router provided on the GitHub project page. The reason for the touch screen is so that you can see the status of interfaces and interact with it without having to open the web interface. Boringly, this router has an SSH daemon ready to connect to, giving you full root access to the Linux-based firmware.

It’s just your typical AArch64 ARM-based system, with the gl_screen process running for the touch screen display. From there it was easy enough to deduce the settings to jot into fbdoom so that it too could use the same screen and touch inputs. After copying the compiled binary with SCP over to the router, it can then be started like any application. With touch inputs somewhat awkwardly mapped to certain areas of the touch screen, it’d be nice to see the USB 2.0 port used for USB HID inputs, but it does show how easy things can be when it runs something like Linux and you got full root access.

Incidentally this also heavily blurs the lines between something like a Valve Steamdeck and a router, with the latter just missing some gamepad controls on the side to do some on-the-go gaming when you’re not using it for routing network traffic.

Continue reading “Running DOOM On A Travel Router With Touch Screen” →

How Pizza Tycoon Simulates Traffic On A 25 MHz CPU

April 27, 2026 by Maya Posch 20 Comments

Although the game Pizza Tycoon – known as Pizza Connection in Europe – probably doesn’t ring a bell for many folk, this 1994 DOS title is special enough for [cowomaly] to write an open source engine to bring it into the modern age as Pizza Legacy. Along the way, some questions popped up, such as how to animate the little cars that you see driving around in the simulated city and how the heck this was done back in the day on a 25 MHz 386 CPU.

Continue reading “How Pizza Tycoon Simulates Traffic On A 25 MHz CPU” →

The Electromechanical Computer Of The B-52’s Star Tracker

April 21, 2026 by Maya Posch 22 Comments

The Angle Computer of the B-52, opened. (Credit: Ken Shirriff)

In the ages before convenient global positioning satellites to query for one’s current location military aircraft required dedicated navigators in order to not get lost. This changed with increasing automation, including the arrival of increasingly more sophisticated electromechanical computers, such as the angle computer in the B-52 bomber’s star tracker that [Ken Shirriff] recently had a poke at.

We covered star trackers before, with this devices enabling the automation of celestial navigation. In effect, as long as you have a map of the visible stars and an accurate time source you will never get lost on Earth, or a few kilometers above its surface as the case may be.

The B-52’s Angle Computer is part of the Astro Compass, which is the star tracker device that locks onto a star and outputs a heading that’s accurate to a tenth of a degree, while also allowing for position to be calculated from it. Inside the device a lot of calculations are being performed as explained in the article, though the full equations are quite complex.

Not burdening the navigator of a B-52 with having to ogle stars themselves with an instrument and scribbling down calculations on paper is a good idea, of course. Instead the Angle Computer solves the navigational triangle mechanically, essentially by modelling the celestial sphere with a metal half-sphere. The solving is thus done using this physical representation, involving numerous gears and other parts that are detailed in the article.

In addition to the mechanical components there are of course the motors driving it, feedback mechanisms and ways to interface with the instruments. For the 1950s this was definitely the way to design a computer like this, but of course as semiconductor transistors swept the computing landscape, this marvel of engineering would before long find itself too replaced with a fully digital version.