Autopsy Of A Failed Vintage Carbon Resistor

Detail of the lead connecting to the inner carbon-filled tube. (Credit: CuriousMarc)
Detail of the lead connecting to the inner carbon-filled tube. (Credit: CuriousMarc)

Although resistors are hardly among the most exciting components, they are arguably one of the most important ones, as anyone who has done any amount of circuit design and debugging can attest to. So too with a single carbon resistor in a vintage Metrix oscilloscope that [CuriousMarc] recently repaired. After recapping the board there was still a major issue that got traced down to said resistor. After replacing it with a fresh resistor obviously this meant doing an autopsy to see why the old resistor had failed.

The 20 kOhm-rated resistor looked fine on the outside, with no obvious damage or discoloration, but it measured around 0.843 MOhm. To get to the insides [CuriousMarc] asked his friend [TubeTime] on how to proceed. The answer here was sandpaper and a lot of patience, and thus the experiment to see how much sanding it takes to get to the core of a fairly big resistor commenced.

Ultimately the insides were revealed, and they turned out to be rather interesting, with what looked like a glass tube filled with what would be the carbon-laden material between the two lead terminals. From poking around a bit at these insides it would appear that the failure mode was a degraded contact between these terminals and the carbon material. Considering that this resistor is many decades old and has gone through many thermal cycles and potentially various kinetic events some fractures are probably to be expected.

Perhaps most fascinating is the construction of this carbon resistor that looks to be a step above that of the average carbon resistor that [TubeTime] has taken apart over the years.

Continue reading “Autopsy Of A Failed Vintage Carbon Resistor”

Honeywell X2S Smart Thermostat Firmware Reverse-Engineering

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

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

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

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

Arbitrary command execution with the Wi-Fi password. (Credit: Benn Jordan)
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

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)