Honeywell X2S Smart Thermostat Firmware Reverse-Engineering

May 26, 2026 by Maya Posch 10 Comments

The Honeywell X2S Smart Thermostat is a Wi-Fi-enabled thermostat that is meant to integrate with your typical ‘smart home’ setup, with mobile app control available as well. Of course, just using it as-is would be extremely boring, so fortunately we have [author0] to take it apart and reverse-engineer its encrypted firmware.

Of the two brains in this thermostat the first is a succinctly named Renesas R7FA6M4AF3CFP MCU containing a 200 MHz Cortex-M33 core with TrustZone features to theoretically keep out any firmware hackers. Handling the wireless side is a Realtek RTL8721DM Wi-Fi/BLE 5.0 SoC. There are also two Winbond Flash chips connected to these two main chips, with their contents of course encrypted.

Fortunately there are plenty of test points to connect to, for which a custom pogo-pin equipped breakout board was created. Cracking the encryption for the Realtek turned out to be as simple as using its RSIP decrypt-on-the-fly feature. From there exploring the firmware was the next step, with a TLS issue pertaining to certificates found to make man-in-the-middle attacks easy, along with a seeding bug that makes recovering session keys possible.

Although the Renesas MCU firmware still has to be decrypted and the full wireless handshake reverse-engineered, these do seem to be solid steps towards fully reverse-engineering this thermostat. It also makes it very clear once again that the ‘S’ in IoT absolutely stands for ‘security’. Maybe that’s why the smart home bubble popped.

Hacking A Video Walkie Talkie’s TXW818 MCU And Running DOOM

May 24, 2026 by Maya Posch 10 Comments

Recently cheapo video walkie-talkies popped up on everyone’s favorite online retailers, which naturally lured in the usual gaggle of reverse-engineering enthusiasts of cheap tat to see what’s inside these devices, as well as what more they can be made to do. Cue [Aaron Christophel] doing just that, with the typical DOOM demo as proof of concept.

Inside these cheerful little devices is a TXW818 MCU, made by TaiXin Semiconductor. It provides its own CK803 CPU core at 240 MHz with 272 kB of SRAM, as well as BLE and 2.4 GHz Wi-Fi support. For these walkie-talkies an additional 4 MB of PSRAM is provided as well as 2-4 MB of SPI Flash.

The display is a glorious 240×320 LCD, which actually fits rather well with a game like DOOM. As also explained on the GitHub project page, to build the project you simply have to fetch the CDK IDE and build the binary. After that it can be flashed with an STM32F103 ‘Blue Pill’ based board.

According to [Aaron] the SDK is rather convoluted and not that nice to work with, so it’s not a sleeper ESP32 alternative, but these cheap walkie-talkies could be nice to tinker with anyway. Other than playing games, of course, as the side buttons aren’t very conducive to gaming, and the limited Flash space required compressing the WAD game file.

Continue reading “Hacking A Video Walkie Talkie’s TXW818 MCU And Running DOOM“ →

Unitree GO-M8018-6 Motor Reverse Engineering

May 23, 2026 by Maya Posch 10 Comments

People seem to be rather into the Unitree Go2 quadruped robot, if only for the low price tag. But perhaps more interesting are the motors that propel it — they appear to be similar to the Go1’s GO-M8010-6 motors that Unitree also sells, with [Thomas Flayols] currently working on reverse-engineering its proprietary driver using the publicly available documentation for that motor and some reverse-engineering.

These motors are an assembly that includes a reducer, magnetic encoder, 3-phase inverter, current sensing, an RS-485 bus and a Cortex-M0-based CMS32M57xx MCU, all in a very capable package intended for robotics applications where a compact actuator is needed.

The first step of reverse-engineering involved the physical PCB, made all the more difficult as Unitree was so kind as to remove all markings on the ICs. Fortunately using an X-ray machine and some sleuthing it was possible to deduce the MCU and other components. Following this SWD/OpenOCD access to the MCU could be established and the firmware key extracted from the bootloader SRAM.

Although the firmware was encrypted, a locally recovered key was found to decrypt it. This allowed for an initial custom firmware to be developed, which [Thomas] hopes to develop into a fully featured open source firmware. Doing so would obviously open these motors to a larger audience outside of Unitree’s ecosystem, as they are pretty good value for what they offer mechanically.

It might give the associated Go2 robot a new life too considering the serious malware accusations and security issues pertaining to its firmware.

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.