Hosting A Website On A Disposable Vape

For the past years people have been collecting disposable vapes primarily for their lithium-ion batteries, but as these disposable vapes have begun to incorporate more elaborate electronics, these too have become an interesting target for reusability. To prove the point of how capable these electronics have become, [BogdanTheGeek] decided to turn one of these vapes into a webserver, appropriately called the vapeserver.

While tearing apart some of the fancier adult pacifiers, [Bogdan] discovered that a number of them feature Puya MCUs, which is a name that some of our esteemed readers may recognize from ‘cheapest MCU’ articles. The target vape has a Puya PY32F002B MCU, which comes with a Cortex-M0+ core at 24 MHz, 3 kB SRAM and 24 kB of Flash. All of which now counts as ‘disposable’ in 2025, it would appear.

Even with a fairly perky MCU, running a webserver with these specs would seem to be a fool’s errand. Getting around the limited hardware involved using the uIP TCP/IP stack, and using SLIP (Serial Line Internet Protocol), along with semihosting to create a serial device that the OS can use like one would a modem and create a visible IP address with the webserver.

The URL to the vapeserver is contained in the article and on the GitHub project page, but out of respect for not melting it down with an unintended DDoS, it isn’t linked here. You are of course totally free to replicate the effort on a disposable adult pacifier of your choice, or other compatible MCU.

Reverse-Engineering Aleratec CD Changers For Archival Use

Handling large volumes of physical media can be a bit of a chore, whether it’s about duplication or archiving. Fortunately this is a perfect excuse for building robotic contraptions, with the robots for handling optical media being both fascinating and mildly frustrating. When [Shelby Jueden] of Tech Tangents fame was looking at using these optical media robots for archival purposes, the biggest hurdle turned out to be with the optical drives, despite these Aleratec units being primarily advertised for disc duplication.

Both of the units are connected to a PC by USB, but operate mostly standalone, with a documented protocol for the basic unit that makes using it quite easy to use for ripping. This is unlike the larger, triple-drive unit, which had no documented protocol. This meant having to sniff the USB traffic that the original, very limited, software sends to the robot. The protocol has now been documented and published on the Tech Tangents Wiki for this Aleratec Auto Publisher LS.

Where [Shelby] hit a bit of a brick wall was with mixed-media discs, which standalone DVD players are fine with, but typical IDE/SATA optical drives often struggle with. During the subsequent search for a better drive, the internals of the robot were upgraded from IDE to SATA, but calibrating the robot for the new drives led [Shelby] down a maddening cascade of issues. Yet even after making one type of drive work, the mixed-media issue reared its head again with mixed audio and data, leaving the drive for now as an imperfect, but very efficient, ripper for game and multimedia content, perhaps until the Perfect Optical Drive can be found.

Continue reading “Reverse-Engineering Aleratec CD Changers For Archival Use”

Reverse-Engineering The Milwaukee M18 Diagnostics Protocol

As is regrettably typical in the cordless tool world, Milwaukee’s M18 batteries are highly proprietary. Consequently, this makes them a welcome target for reverse-engineering of their interfaces and protocols. Most recently the full diagnostic command set for M18 battery packs were reverse-engineered by [ToolScientist] and others, allowing anyone to check useful things like individual cell voltages and a range of statistics without having to crack open the battery case.

These results follow on our previous coverage back in 2023, when the basic interface and poorly checksummed protocol was being explored. At the time basic battery management system (BMS) information could be obtained this way, but now the range of known commands has been massively expanded. This mostly involved just brute-forcing responses from a gaggle of battery pack BMSes.

Interpreting the responses was the next challenge, with responses like cell voltage being deciphered so far, but serial number and the like being harder to determine. As explained in the video below, there are many gotchas that make analyzing these packs significantly harder, such as some reads only working properly if the battery is on a charger, or after an initial read.

Continue reading “Reverse-Engineering The Milwaukee M18 Diagnostics Protocol”

Running Code On A PAX Credit Card Payment Machine

The PAX D177 PoS terminal helpfully tells you which tamper points got triggered. (Credit: Lucas Teske)
The PAX D177 PoS terminal helpfully tells you which tamper points got triggered. (Credit: Lucas Teske)

These days Points of Sale (PoS) usually include a digital payment terminal of some description, some of which are positively small, such as the Mini PoS terminals that PAX sells. Of course, since it has a CPU and a screen it must be hacked to run something else, and maybe discover something fun about the hardware in the process. Thus [Lucas Tuske] set out to do exactly this with a PAX D177 PoS, starting with purchasing three units: one to tear apart, one to bypass tamper protections on and one to keep as intact reference.

As expected, there are a few tamper protections in place, starting with pads that detect when the back cover is removed and a PCB that’s densely covered in fine traces to prevent sneaky drilling. Although tripping the tamper protections does not seem to affect the contents of the Flash, the firmware is signed. Furthermore the secrets like keys that are stored in NVRAM are purged, rendering the device effectively useless to any attacker.

The SoC that forms the brains of the whole operations is the relatively obscure MH1903, which is made by MegaHunt and comes in a dizzying number of variants that are found in applications like these PoS terminals. Fortunately the same SoC is also found on a development board with the AIR105 MCU that turns out to feature the same MH1903 core. These are ARM Cortex-M3 cores, which makes targeting them somewhat easier.

Rather than try to break the secure boot of the existing SoC, [Lucas] opted to replace the SoC package with a brand new one, which was its own adventure. Although one could say that this is cheating, it made getting a PoC of custom code running on one of these devices significantly easier. In a foll0w-up article [Lucas] expects to have Doom running on this device before long.

Using An MCU’s Own Debug Peripheral To Defeat Bootrom Protection

The patient hooked up for some reverse-engineering. (Credit: Caralynx, Twitter)
The patient hooked up for some reverse-engineering. (Credit: Caralynx, Twitter)

Released in July of 2025, the Tamagotchi Paradise may look somewhat like the late 90s toy that terrorized parents and teachers alike for years, but it’s significantly more complex and powerful hardware-wise. This has led many to dig into its ARM Cortex-M3-powered guts, including [Yukai Li] who recently tripped over a hidden section in the bootrom of the dual-core Sonix SNC73410 MCU that makes up most of the smarts inside this new Tamagotchi toy.

Interestingly, [Yukai] did see that the visible part of the bootrom image calls into the addresses that make up the hidden part right in the reset handler, which suggests that after reset this hidden bootrom section is accessible, just not when trying to read it via e.g. SWD as the hiding occurs before the SWD interface becomes active. This led [Yukai] to look at a way to make this ROM section not hidden by using the Cortex-M3’s standard Flash Patch and Breakpoint (FPB) unit. This approach is covered in the project’s source file.

With this code running, the FPB successfully unset the responsible ROM hide bit in the OSC_CTRL register, allowing the full bootrom to be dumped via SWD and thus defeating this copy protection with relatively little effort.

Heading image: PCB and other components of a torn-down Tamagotchi Paradise. (Credit: Tamagotchi Center)

A thick, rectangular device with rounded corners is shown, with a small screen in the upper half, above a set of selection buttons.

Further Adventures In Colorimeter Hacking

One of the great things about sharing hacks is that sometimes one person’s work inspires someone else to take it even further. A case in point is [Ivor]’s colorimeter hacking (parts two and three), which started with some relatively simple request spoofing to install non-stock firmware, and expanded from there until he had complete control over the hardware.

After reading [Adam Zeloof]’s work on replacing the firmware on a cosmetics spectrophotometer with general-purpose firmware, [Ivor] bought two of these colorimeters, one as a backup. He started with [Adam]’s method for updating the firmware by altering the request sent to an update server, but was only able to find the serial number from a quality-control unit. This installed the quality-control firmware, which encountered an error on the device. More searching led [Ivor] to another serial number, which gave him the base firmware, and let him dump and compare the cosmetic, quality-control, and base firmwares.

Continue reading “Further Adventures In Colorimeter Hacking”

Reverse Engineering A (Toy) Fire Engine

Your kid has a toy remote control fire truck. You have an RTL SDR. See where this is going? [Jacob] couldn’t resist tearing into the why and how of the truck’s remote control protocol.

The entire process began with a basic GNU Radio setup to determine the exact frequency of the signal. Then a little analysis suggested that it might be using amplitude shift keying. That is, the information is in the amplitude of the signal, where one possible amplitude is completely off in some cases.

Continue reading “Reverse Engineering A (Toy) Fire Engine”