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”

Reverse-Engineering Mystery TV Equipment: The Micro-Scan

[VWestlife] ended up with an obscure piece of 80s satellite TV technology, shown above. The Micro-Scan is a fairly plan metal box with a single “Tune” knob on the front. At the back is a power switch and connectors for TV Antenna, TV Set, and “MW” (probably meaning microwave). There’s no other data. What was this, and what was it for?

Satellite TV worked by having a dish receive microwave signals, but televisions could not use those signals directly. A downconverter was needed to turn the signal into something an indoor receiver box (to which the television was attached) could use, allowing the user to select a channel to feed into the TV.

At first, [VWestlife] suspected the Micro-Scan was a form of simple downconverter, but that turned out to not be the case. Testing showed that the box didn’t modify signals at all. Opening it up revealed the Micro-Scan acts as a combination switchbox and variable power supply, sending a regulated 12-16 V (depending on knob position) out the “MW” connector.

So what is it for, and what does that “Tune” knob do? When powered off, the Micro-Scan connected the TV (plugged into the “TV Set” connector) to its normal external antenna (connected to “TV Antenna”) and the TV worked like a normal television. When powered on, the TV would instead be connected to the “MW” connector, probably to a remote downconverter. In addition, the Micro-Scan supplied a voltage (the 12-16 V) on that connector, which was probably a control voltage responsible for tuning the downconverter. The resulting signal was passed unmodified to the TV.

It can be a challenge to investigate vintage equipment modern TV no longer needs, especially hardware that doesn’t fit the usual way things were done, and lacks documentation. If you’d like to see a walkthrough and some hands-on with the Micro-Scan, check out the video (embedded bel0w).

Continue reading “Reverse-Engineering Mystery TV Equipment: The Micro-Scan”

A Label Printer Gets A New Brain

The internals of a printer, whatever technology it may use, are invariably proprietary, with an abstracted more standard language being used to communicate with a host computer. Thus it’s surprisingly rare to see hacks on printers as printers, rather than printer hacks using the parts for some other purpose. This makes [Oelison]’s brain-swap of a Casio thermal label printer a welcome surprise, as it puts an ESP32 in the machine instead of whatever Casio gave it.

The value in the hack lies in the insight it gives into how a thermal printer works as much as it does in the ESP32 and the Casio, as it goes into some detail on the various signals involved. The strobe line for instance to enable the heater is a nuance we were unaware of. The resulting printer will lose its keyboard and display, but  make up for it in connectivity.

Despite what we said earlier this isn’t the first label printer hack we’ve seen. A previous one was Linux-based though.

Why Super Mario 64 Wastes So Much Memory

The Nintendo 64 was an amazing video game console, and alongside consoles like the Sony PlayStation, helped herald in the era of 3D games. That said, it was new hardware, with new development tools, and thus creating those early N64 games was a daunting task. In an in-depth review of Super Mario 64’s code, [Kaze Emanuar] goes over the curious and wasteful memory usage, mostly due to unused memory map sections, unoptimized math look-up tables, and greedy asset loading.

The game as delivered in the Japanese and North-American markets also seems to have been a debug build, with unneeded code everywhere. That said, within the context of the three-year development cycle, it’s not bad at all — with twenty months spent by seven programmers on actual development for a system whose hardware and tooling were still being finalized, with few examples available of how to do aspects like level management, a virtual camera, etc. Over the years [Kaze] has probably spent more time combing over SM64‘s code than the original developers, as evidenced by his other videos.

As noted in the video, later N64 games like Legend of Zelda: Ocarina of Time are massively more optimized and streamlined, as lessons were learned and tooling improved. For the SM64 developers, however, they had a gargantuan 4 MB of fast RDRAM to work with, so optimization and memory management likely got kicked down to the bottom on the priority list. Considering the absolute smash hit that SM64 became, it seems that these priorities were indeed correct.

Continue reading “Why Super Mario 64 Wastes So Much Memory”