Mysterious Files PH

The RP2350 is actually a pretty secure chip, all things considered. It has secure boot, ARMv8’s TrustZone to split secure and non-secure execution, and you can permanently disable debug — the Pi Foundation even included glitch detection, meaning the traditional ‘zap the chip until it obeys’ technique is blocked. That’s why the [Ledger Donjon] security team went full Bond Villain and strapped everyone’s favourite fruit-flavoured microcontroller to a table with a slowly-approaching laser beam.

Okay — movie clichés aside, the laser was in fact very carefully focused on target before they turned it on. That target was the register that enables the 2350’s debug features. Said register was located by decapsulating the chip and examining the die with photon-emission electron microscopy; the actual attack was carried out on a chip that had been decapped on the back side, with IR shining through the silicon wafer. There was probably more than a little trial-and-error to figure out exactly where on the die adjacent to the register to zap with the laser to flip those bits. But flip they did, restoring the debugger’s access to the secure execution zone. Then, after resetting the chip, [Ledger]’s team read the 128-bit secret the Pi Foundation hid in memory as part of the 2350 hacking challenge.

It’s long been accepted that once the black hats — or white hats, for that matter — have their hands on your hardware, they’re going to find a way in. The effort it takes to break into a simple microcontroller here is actually kind of impressive. We’ve talked about laser fault injection before; ironically, we’ve also featured Pi Pico-powered glitching attacks — the kind that this chip’s glitch detection thwarts.

A Linux handheld computer is, in theory, easy and inexpensive given the availability of single-board computers, but in practice the budget invariably edges well into three figures. There’s an interesting alternative from [bkovac] that won’t break the bank as much, using a cheap 4G wireless hotspot, an iPhone USB keyboard case accessory, and, though a cheaper display could suffice, a fancy Adafruit Sharp memory display.

The hotspot is available from AliExpress for around 20 dollars/Euros/pounds, and it’s referred to by its model number, MF800. It’s powered by a Qualcomm MSM8916, also known as the Snapdragon 410, which you might have found in a budget cellphone early in the last decade. Importantly, though, it’s supported by mainstream Linux, and while it’s by no means the fastest on the block, it can be a poor man’s alternative to a Raspberry Pi. It comes with a small SPI display, but this project replaces it with a much bigger Sharp SPI memory display.

The build walks through a few case mods and a PCB mod on the modem, getting the keyboard to fit, and making a custom power board. Perhaps the software setup is the most interesting part, because this isn’t a simple case of installing a distro. Instead, there’s quite a bit of hackery to get the display working.

We really like this project because while a Linux handheld is nothing new, it’s making one using an unexpected starting point. It reminds us of the old days of running Linux on an old router.

This article is written on an open-source operating system, but not an open-source machine — the BIOS isn’t open-source, and even if it were supported by the coreboot project (formerly LinuxBIOS), there would still be a whole host of binary blobs required to get it to boot. On one vintage architecture, there’s one less blob, as coreboot can now initialize DRAM on Intel Bay Trail SOCs, as [Mate Kukri] presented in a talk at the recent Open Source Firmware Conference.

Bay Trail isn’t exactly cutting-edge hardware, to be sure — the SoCs are over a decade old at this point, and were only used in low-performance mobile applications like Chromebooks. On the other hand, coreboot has been on Chromebooks for at least as long. Getting DRAM set up is difficult because, well, you don’t have any memory to work with until you do. Traditionally, the way you did that was to call on one of the many proprietary ‘binary blobs’ provided with next to no documentation by the manufacturer. Reverse engineering that requires some serious bus-sluthing, which was done in software with the SerialICE debugger and the Unicorn Engine CPU emulator. The talk focused on that technique and how it might be applied more widely, rather than getting into the weeds of how to do DRAM init on one obsolete SOC. At some point the whole thing should be archived on the OFSC website so those of us not lucky enough to attend in person can hear what [Mate] — and all the other speakers — had to say.

Because coreboot is open, you can do a lot more with it than a proprietary UEFI firmware — for example, you can choose not to initialize RAM at all, and run entirely in the CPU’s cache. You can also — of course — run DOOM. If you want to be binary-blob-free, you’ll need to find hardware supported by the more hardcore Libreboot distribution of coreboot, which admits no binary blobs at all. When it comes to Libreboot, it might actually be easier to install than to find compatible hardware these days.

Although it wasn’t apparently designed with this in mind, it seems particularly fortuitous that this walking robotic hand was released in time for Halloween. Designed by researchers from ETH Zurich, the slightly unsettling disembodied hand can use its fingers as legs to traverse terrain, push small objects around, and operate a keyboard.

The researchers started from commercially-available robot hand, equipped it with a battery and Raspberry Pi Zero 2 W, and developed neural net-based software to control it. The hand has twenty joints, four per finger, and the neural net iteratively outputs the next joint state, based on previous movements, the state of the hand, and the hand’s current goal. To train the net, the researchers built a simulated model, then used this for reinforcement learning; this yielded a faster walking speed than an adapted quadrupedal motion model did.

The hand was trained to move in a straight line, turn, recover from a fall, and press the keys of a keyboard (since it doesn’t have a camera, though, it can’t operate a keyboard by itself). The fall recovery is impressive to watch: in 21 out of 25 tests, it was able to right itself within twenty seconds. Due to the hand’s geometry, it drifts to the right while walking, so a constant correction needed to be applied. It did, however, manage to successfully cross fourteen varying surfaces, ranging in roughness from a rubber mat to gravel and grass. It even managed to push light objects toward goals.

The authors envision this kind of autonomous hand enabling greater freedom for a larger robot, such as a robot arm: if it needs to reach something farther away, the hand simply detaches and walks over. Regardless of the use to which they put in, such a project is already within reach of hackers; we’ve seen a few robotic hand projects here over the years.

In the cross-over between the era of tapes into that of MP3s, you’d see quite a few of those special cassette tapes that were actually digital music players inside. Some simply provided a 3.5 mm input, while others were complete MP3 players or Bluetooth receivers that just happened to also output to the magnetic read head of a cassette player. Recently [Jonathan Rowny] decided to make his own version of the latter.

Although getting the actual audio signal into the read head is easy enough – requiring little more than its equivalent being used as a write head on the cassette side – actually interfacing with the player’s mechanisms like auto-stop, reverse and so on requires the use of some gearing that detect motion on what would be the tape spools, as well as transfer the motion from the take-up spool to the other spool so that features like the auto-stop mechanism don’t get triggered.

A lot of inspiration here can be found in e.g. the videos made by [Clint] of [Lazy Game Reviews] who looked at a number of examples – including their internals – over the years, with various levels of functionality. For this particular implementation an ESP32-S3 module is used for the brains, along with a microSD card reader for music and a PCM5102 I2S audio codec to create the analog audio signal.

The gears were printed using an SLA printer and seem to work all right. Unfortunately he didn’t realize the importance of the capstan as the mechanism that actually transports the tape, so its motion was not measured as is done in the better cassette adapters. This will likely be corrected in a future iteration, however.

Before moving to land grid array (LGA) packaging whereby each pin on the substrate is just a copper pad, processors commonly used pin grid array (PGA) packaging, including the still highly relevant AMD AM4 socket. With PGA you get a pin soldered onto the copper pad which inserts into the ZIF socket, rather than a fragile pin on the mainboard side. Repairing a damaged PGA pin can be easy if just the pin broke off at the solder joint, or rough if the pad was destroyed, as in the case of this Pentium III CPU that [Bits und Bolts] recently tried to fix.

In the case of something like a ground pin or similarly unimportant pin you can ignore the damage, but in this case it concerned an important pin for this 1.2 GHz Tualatin PIII core, with the damage consisting of a well and truly destroyed pad. The first step to repair the damage is thus to try and rebuild the pad, which was done using solder mask and solder.

Although a PIII-era Celeron CPU is definitely not a high-value CPU, since they have so few and such large pins they do make for useful test subjects when it comes to PGA repair practicing. In this case the affected data pad and pin appears to have been repaired successfully, with it running overclocked to 1.6 GHz and crushing similarly or higher clocked Pentium 4 and AMD Athlon CPUs of the era.

This week, Hackaday Editors Elliot Williams and Tom Nardi start the episode off by discussing the latest CircuitPython developments before covering some impressive reverse engineering efforts, the benefits of modeling your projects in 3D, and some of the most incredible timepieces that have ever graced the pages of Hackaday.

You’ll also hear about the fascinating potential of combing 3D and UV printing, Linux on the ESP32, and a virtual TV station that pulls from the Internet Archive. The episode wraps up with a Hackaday Europe double-feature: one talk extols the virtues of keeping things simple through bare metal development, while the other covers off-world hacks and fixes that will make you want to sign up for Space Camp.

Check out the links if you want to follow along, and as always, tell us what you think about this episode in the comments!

Direct download, the MP3 way.

Episode 387 Show Notes:

Mailbag:

• Alex is looking for advice on getting an Air Precision APE2650 pulled from an Airbus A310 working.
• Mailbag still needs intro/outro music. Anyone want to whip something up? Send it to mailbag@hackaday.com.

Interesting Hacks of the Week:

• CircuitPython Goes Turbo With Precompiled Functions
• Writing An ESP32 Bluetooth Printer Driver In Two Acts
• Rusting An E-scooter (In A Good Way)
• Tips To Model Your Next CNC Cabinet In CAD Before Buying Anything
• Keeping Time On Tumbling Icosahedra
  • EPTAORA
  • Edgytokei
  • AKUROBATTO
  • Sequino
• Full-Color Looks Great On 3D Printed Sliding Puzzles
  • Hands-On: EufyMake E1 UV Printer
  • UV Printer? 3D Printer? HeyGears Says “Why Not Both”?

Quick Hacks:

• Elliot’s Picks:
  • Round AMOLED Badge Does All Kinds Of Cool Stuff
  • It’s The Speech Synthesiser You Wanted, For The Computer You Had
  • Running Linux 6.11 On The ESP32-S3 With A Few Tweaks
• Tom’s Picks:
  • Purely Random TV In Your Browser
  • An Open Heart Rate Monitor
  • A UPS For Your Pi That’s A Little Different

Can’t-Miss Articles:

• Hackaday Europe 2026: Bare Metal Made Easy
• Hackaday Europe 2026: Space Oddities
• Supercon 2024: Behind the Scenes of Mission Control – Janelle Wellons – YouTube