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!

A picture showing acupuncture needles wedged into the inside of the payment terminal

Aaron Christophel Brings DOOM To Payment Terminal

Payment terminals might feel intimidating — they’re generally manufactured with security in mind, with all manner of anti-tamper protections in place to prevent you from poking around in the hardware too much. But [Aaron Christophel] thinks that level of security isn’t aren’t always in practice however, and on his journey towards repurposing devices of all kinds, has stumbled upon just the terminal that will give up its secrets easily. The device in question is Sumup Solo terminal, a small handheld with a battery, LTE connection and a payment card slot – helping you accept card payments even if you’re on the go.

Now, this terminal has security features like the anti-tamper shield over the crucial parts of the device, leading to payment processing-related keys being erased when lifted. However, acupuncture needles, a tool firmly in [Aaron]’s arsenal, helped him reach two UART testpoints that were meant to be located under that shield, and they turned out to be all that a hacker needed to access the Linux system powering this terminal. Not just that, but the UART drops you right into the root shell, which [Aaron] dutifully explored — and after some cross–compilation and Linux tinkering, he got the terminal to, naturally, run Doom.

The video shows you even more, including the responsible disclosure process that he went through with Sumup, resulting in some patches and, we hope, even hardware improvements down the line. Now, the payment processing keys aren’t accessible from the Linux environment — however, [Aaron] notes that this doesn’t exclude attacks like changing the amount of money displayed while the customer is using such a terminal to pay.

If you’d like to take a closer look at some of the hardware tricks used in these secure devices, we did a teardown on one back in 2019 that should prove interesting.

Continue reading “Aaron Christophel Brings DOOM To Payment Terminal”

Reverse Engineering The Apple Lightning Connector

A frequent contributor to the hacker community, [stacksmashing] has prepared an excellent instructional video on reverse engineering Apple’s Lighting connector proprietary protocol. The video begins by showing how to gain physical access to the signals and hooking them up to a logic analyzer. He then notes that the handshaking uses only a single signal and proposes that Apple isn’t going to re-invent the wheel (perhaps a risky assumption). Using a ChatGPT search, obligatory these days, we learn that Dallas Semiconductor / Microchip 1-wire is probably the protocol employed.

Which embedded single-wire busses exist that encode bits with different lengths of low and high signals?

At the basic level, 1-wire and protocols like Texas Instruments SDQ operate in a similar manner. It turns out that [stacksmashing] already wrote a SDQ analyzer module for the Saleae logic analyzer. Aided by this tool, he digs deeper and learns more about the kinds of messages and their contents. For example, upon being plugged in, the host system queries the accessory’s serial number, manufacturer, model number, and product description. Finally, he introduces the CRC reverse engineering tool reveng to determine which CRC polynomial and algorithm the protocol uses to frame each packet.

Even if you have no interest in Lightning cables, this video is a great tutorial on the types of things you need to do in order to make sense of an unknown communications protocol. Gather what information you can, make some educated guesses, observe the signals, revise your guesses, and repeat. In part two, [stacksmashing] will show how to build a homemade iPhone JTAG cable.

We wrote in more detail about cracking the Lightning interface back in 2015. The Lightning interface may have been a good solution in its day, foreshadowing some of the features we now have in USB-C. But its proprietary and closed nature meant it wasn’t used outside of the Apple ecosystem. With the proliferation and capabilities of USB-C, not to mention various legislative edicts, Lightning’s days seem numbered. Is the industry finally settling on one interface? Let us know your thoughts in the comments below.

Continue reading “Reverse Engineering The Apple Lightning Connector”