A white, house-shaped clock with the words "TEMPUS NECTIT" written in faux Roman script in black on a strip of silver at the base of the "roof." a white power cord extends from the left of the enclosure, and the center of the clock is a 22 pin knitting machine wheel with one pin covered in silver metalic. A white plastic peg extends from the bottom right of the enclosure to hold the feedstock yarn.

Tempus Nectit, A DIY Knitting Clock With Instructions

We’re no strangers to unusual clocks here at Hackaday, and some of our favorites make time a little more tangible like [Kyle Rankin]’s knitting clock.

Inspired by our coverage of [Siren Elise Wilhelmsen]’s knitting clock, [Rankin] decided to build one of his own. Since details on the build from the original artist were sparse, he had to reverse engineer how the device worked. He identified that a knitting clock is essentially a knitting machine with a stepper motor replacing the hand crank.

Using a Raspberry Pi with an Adafruit motor hat connected to a stepper motor and a 3D printed motor adapter, [Rankin] was able to drive the knitting machine to do a complete round of knitting every twelve hours. By marking one of the knitting pegs as an hour hand, the clock works as a traditional clock in addition to its year-long knitting task. [Rankin] says he still has some fine tuning to work on, but that he’s happy to have had the chance to combine so many of his interests into a single project.

If you’re looking for more knitting hacks, check out this knitted keyboard instrument or a knitted circuit board.

Continue reading “Tempus Nectit, A DIY Knitting Clock With Instructions”

Debugging And Analyzing Real-Mode 16-Bit X86 Code With Fresh Bread

Running a debugger like gdb with real-mode 16-bit code on the x86 platform is not the easiest thing to do, but incredibly useful when it comes to analyzing BIOS firmware and DOS software. Although it’s possible to analyze a BIOS image after running it through a disassembler, there is a lot that can only be done when the software is running on the real hardware. This is where [Davidson Francis] decided that some BREAD would be useful, as in BIOS Reverse Engineering & Advanced Debugging.

What BREAD does is provide some injectable code that with e.g. a BIOS replaces the normal boot logo with the debugger stub. This stub communicates with a bridge via the serial port, with the gdb client connecting to this bridge. Since DOS programs are also often 16-bit real-mode, these can be similarly modified to provide light-weight in-situ debugging and analysis. We imagine that this software can be very useful both for software archaeology and embedded purposes.

Thanks to [Rodrigo Laneth] for the tip.

Creating A Game Boy ROM From Pictures

There are very few legal ways of obtaining ROM files for video games, and Nintendo’s lawyers are extremely keen on at least reminding you of the fact that you need to own the game cart before obtaining the ROM. With cart in hand, though, most will grab a cart reader to download the game files. While this is a tried-and-true method, for GameBoy games this extra piece of hardware isn’t strictly required. [Travis Goodspeed] is here to show us a method of obtaining ROM files from photographs of the game itself.

Bits can be manually edited to fix detection errors.

Of course, the chips inside the game cart will need to be decapped in order to obtain the pictures, and the pictures will need to be of high quality in order to grab the information. [Travis] is more than capable of this task in his home lab, but some work is still required after this step.

The individual bits in the Game Boy cartridges are created by metal vias on the chip, which are extremely small, but still visible under a microscope. He also has a CAD program that he developed to take this visual information and extract the data from it, which creates a ROM file that’s just as good as any obtained with a cart reader.

This might end up being slightly more work especially if you have to decap the chips and take the photographs yourself, but it’s nonetheless a clever way of obtaining ROM files due to this quirk of Game Boy technology. Encoding data into physical hardware like this is also an excellent way of ensuring that it doesn’t degrade over time. Here are some other methods for long-term data storage.

Screenshot of ImHex hex editor, with the MOC3 file structure being reverse-engineered inside of it

Live2D: Silently Subverting Threat Models

In online spaces, VTubers have been steadily growing in popularity in the past few years – they are entertainers using motion capture tech to animate a special-sauce 2D or 3D model, typically livestreaming it as their avatar to an audience. The tech in question is pretty fun, lively communities tend to form around the entertainers and artists involved, and there’s loads of room for creativity in the VTuber format; as for viewers, there’s a VTuber for anyone’s taste out there – what’s not to like? On the tech side of making everything work, most creators in the VTubing space currently go with a software suite from a company called Live2D – which is where today’s investigation comes in. Continue reading “Live2D: Silently Subverting Threat Models”

Customizing The Start-Up Chime On A 1999 G3 IMac

The start-up chime on Macs is probably as recognizable as the default Nokia ringtone in this day and age. Yet much like a ringtone, so too one might want to change the start-up chime on a Mac. This is something which [Doug Brown] has done in the past already on a Power Mac G3 in 2012, which made him instantly an expert on the topic in the eyes of a reader who wanted to know how to change the chime on a 1999 iMac. While the firmware on both these systems is written in Forth, it did take a bit of sleuthing to figure out where the chime was hiding in the firmware image, and how to change it.

The target iMac is somewhat unique in that it has a G4 PPC CPU rather than the more common G3. The firmware is similar enough that it was a snap to simply search the newer iMac’s firmware for the signature of the chime sound data. This turned out to be the identical QuickTime IMA ADPCM format-encoded data, yet what was different was how this data was integrated into the firmware image. Key is finding the area in the firmware where not only the address of the chime data’s start is defined, but also its length. Finally, the checksums in the firmware image have to be updated so that it matches the patched data.

Reverse-engineering the checksum calculation in the Forth code turned out to be fairly straightforward, but getting the new firmware on the iMac turned out to be the biggest struggle, as [Doug] didn’t want to inflict running a manual firmware update onto this reader he was doing all this work for. This led [Doug] to do some more reverse-engineering using Ghidra to enable the use of the automatic updater like a regular firmware update.

In the end it all worked out great, and now another iMac no longer has the Mac chime on start-up.

Screenshot from the presentation, showing the datalogger product image next to the datalogger specs stated. The specs are suspiciously similar to those of a Raspberry Pi 3.

Reclaiming A Pi-Based Solar Datalogger

There’s quite a few devices on the market that contain a Raspberry Pi as their core, and after becoming a proud owner of a solar roof, [Paolo Bonzini] has found himself with an Entrade ENR-DTLA04DN datalogger which – let’s just say, it had some of the signs, and at FOSDEM 2023, he told us all about it. Installed under the promise of local-only logging, the datalogger gave away its nature with a Raspberry Pi logo-emblazoned power brick, a spec sheet identical to that of a Pi 3, and a MAC address belonging to the Raspberry Pi Foundation. That spec sheet also mentioned a MicroSD card – which eventually died, prompting [Paolo] to take the cover off. He dumped the faulty SD card, then replaced it – and put his own SSH keys on the device while at it.

At this point, Entrade no longer offered devices with local logging, only the option of cloud logging – free, but only for five years, clearly not an option if you like your home cloud-free; the local logging was not flawless either, and thus, the device was worth exploring. A quick peek at the filesystem netted him two large statically-compiled binaries, and strace gave him a way to snoop on RS485 communications between the datalogger and the solar roof-paired inverter. Next, he dug into the binaries, collecting information on how this device did its work. Previously, he found that the device provided an undocumented API over HTTP while connected to his network, and comparing the API’s workings to the data inside the binary netted him some good results – but not enough.

The main binary was identified to be Go code, and [Paolo] shows us a walkthrough on how to reverse-engineer such binaries in radare2, with a small collection of tricks to boot – for instance, grepping the output of strings for GitHub URLs in order to find out the libraries being used. In the end, having reverse-engineered the protocol, he fully rewrote the software, without the annoying bugs of the previous one, and integrated it into his home MQTT network powered by HomeAssistant. As a bonus, he also shows us the datalogger’s main PCB, which turned out to be a peculiar creation – not to spoil the surprise!

We imagine this research isn’t just useful for when you face a similar datalogger’s death, but is also quite handy for those who find themselves at the mercy of the pseudo-free cloud logging plan and would like to opt out. Solar tech seems to be an area where Raspberry Pi boards and proprietary interfaces aren’t uncommon, which is why we see hackers reverse-engineer solar power-related devices – for instance, check out this exploration of a solar inverter’s proprietary protocol to get data out of it, or reverse-engineering an end-of-life decommissioned but perfectly healthy solar inverter’s software to get the service menu password.

Screenshot of the code decompiled after these patches are applied, showing that all the register writes are nicely decompiled and appropriate register names are shown in the code

Making Ghidra Play Nice With RP2040

Developing firmware for RP2040 is undeniably fun, what’s with all these PIOs. However, sometimes you will want to switch it around and reverse-engineer some RP2040 firmware instead. If you’ve ever tried using Ghidra for that, your experience might have been seriously lackluster due to the decompiled output not making sense when it comes to addresses – thankfully, [Wejn] has now released patches for Ghidra’s companion, SVD-Loader, that turn it all around, and there’s a blog post to go with these.

SVD-Loader, while an indispensable tool for ARM work, didn’t work at all with the RP2040 due to a bug – fixed foremost. Then, [Wejn] turned to a pecularity of the RP2040 – Atomic Register Access, that changes addressing in a way where the usual decompile flow will result in nonsense addresses. Having brought a ton of memory map data into the equation, [Wejn] rewrote the decoding and got it to a point where peripheral accesses now map to nicely readable register writes in decompiled code – an entirely different picture!

You can already apply the patches yourself if you desire. As usual, there’s still things left in TODO for proper quality of life during your Ghidra dive, but the decompiled code makes way more sense now than it did before. Now, if you ever encounter a RP2040-powered water cooler or an air quality meter, you are ready to take a stab at its flash contents. Not yet familiar with the Ghidra life? Well, our own HackadayU has just the learning course for you!