Shall We Hack A Game?

A fantastic summertime game has consumed many of the kids in my neighborhood. It’s basically a treasure hunt, but the treasures are all shoebox-sized NFC readers that are “easily” findable on a map. Players all have a smart card and run around from box to box, collecting points that depend on how far apart the boxes are from each other. Walk, skate, or bike 1 km between check-ins, and ten points show up on the e-paper screen.

It’s been going on for a few weeks now, and it’s not uncommon to see a line of two or three kids at any given box, all with the purple lanyards and smart cards around their necks. So far, the highest-rated plausible single efforts have 450 km (280 miles) under their belt. My son’s grade-school average is 45 km (28 miles) over three weeks. The goal is getting kids out on the early summer afternoons, and that seems to be working!

Of course I had to reverse engineer the infrastructure, so here’s what I started with. Each box knows your point standing as soon as you tap the card, with a small delay. Scores appear online about every four hours. And the boxes are all ~1 km from each other or less.

My first thought was some kind of mesh network – that would be by far the coolest solution. Each box could simply report your card number to a central database, and the rest is a simple matter of software. LoRa radios rounded out my fantasy design.

But the length of time between getting the points and their appearance online suggests otherwise. And, a little bit of playing around with my cellphone’s NFC reader gives up the juice – they are MiFare Classic cards with data storage. So I got my own card, ran around town, and diffed the results. I haven’t cracked the location/time-stamping yet, but I know exactly where my total points are stored.

I’m going to keep observing until I’ve got it figured out completely, but I’m so tempted to tweak the points and see what happens. Are some of the digits in what I think are a timestamp in reality a checksum? Will I get disqualified? Or worse, what if I make a mistake and get myself publicly into first place? OK, better to sit this one out on the sidelines – I really don’t want to be the jerk who crashes a fantastic kid’s game. Sometimes you’ve gotta know when not to hack.

Reverse Engineering A Better Night’s Sleep

All you want is a decent night’s sleep, so you decide to invest in one of those fancy adjustable beds. At first, it’s fine — being able to adjust the mattress to your needs on the fly is a joy, and yet…something isn’t quite right. Something nags at you every night, thwarting your slumber and turning your dreams of peaceful sleep into a nightmare once you realize your bed has locked you into a vertically integrated software ecosystem from which there’s no escape.

Or is there? That’s what [Chris Laplante] wanted to know, and why he reverse-engineered his Tempur-Pedic remote control. As many products these days do, his bed was touted as having an Android application for smartphone adjustability, but alas, the app hasn’t been updated since 2014 (!) and doesn’t appear to work on modern phones. [Chris] decided to take matters into his own hands and build a gateway to talk to the bed using its native RF protocol.

Most good reverse engineering stories start with research, and this one is no exception. Digging into the FCC database revealed a wealth of clues, such as the frequency — 433-MHz ISM band, no surprise — and even spectrum analyzer screenshots of the remote’s signals. A HackRF One revealed more about the signals, but it turned out that sniffing in on the SPI bus between the microcontroller and the Si4431 RF transceiver with a Salae logic analyzer was more fruitful, allowing him to dig into the packet structure.

The engineers at Tempur-Pedic threw quite a few challenges at [Chris], like an application-level CRC in addition to the CRC used by the Si4431, and interesting complications to control the massage features of the bed. In the end, [Chris] managed to get a pretty complete snapshot of the conversation between the bed and the remote, and is now in the process of building a gateway that’ll actually connect to his phone, plus integrate into his home automation system. We’re looking forward to updates on that.

Reverse Engineering An Oil Burner Comms Board, With A Few Lucky Breaks

Here’s a question for you: How do you reverse engineer a circuit when you don’t even have it in hand? It’s an interesting problem, and it adds a level of difficulty to the already iffy proposition that reverse engineering generally presents. And yet, not only did [themole] find a way to replicate a comms board for his oil burner, he extended and enhanced the circuit for integration into his home automation network.

By way of backstory, [themole] has a wonky Buderus oil burner, which occasionally goes into safety mode and shuts down. With one too many cold showers as a result, he looked for ways to communicate with the burner controller. Luckily, Buderus sells just the thing — a serial port module that plugs into a spare slot in the controller. Unluckily, the board costs a bundle, and that’s even if you can find it. So armed with nothing but photos of the front and back of the board, the finding of which was a true stroke of luck, he set about figuring out the circuit.

With only a dozen components or so and a couple of connectors, the OEM board gave up its secrets pretty easily; it’s really just a level shifter to make the boiler talk RS-232. But that’s a little passé these days, and [the78mole] was more interested in a WiFi connection. So his version of the card includes an ESP32 module, which handles wireless duties as well as the logic needed to talk to the burner using the Buderus proprietary protocol. The module plugs right into the burner controller and connects it to ESPHome, so no more cold showers for [themole].

We thought this one was pretty cool, especially the way [themole] used the online photos of the board to not only trace the circuit but to get accurate — mostly — measurements of the board using an online measuring tool. That’s a tip we’ll keep in our back pocket.

Thanks to [Jieffe] for the tip.

[Bunnie] Peeks Inside ICs With IR

If you want to see inside an integrated circuit (IC), you generally have to take the die out of the package, which can be technically challenging and often destroys the device. Looking to improve the situation, [Bunnie] has been working on Infra-Red, In Situ (IRIS) inspection of silicon devices. The technique relies on the fact that newer packages expose the backside of the silicon die and that silicon is invisible to IR light. The IR reflects off the bottom metalization layer and you can get a pretty good idea of what’s going on inside the chip, under the right circumstances.

As you might expect, the resolution isn’t what you’d get from, say, a scanning electron microscope or other techniques. However, using IR is reasonably cheap and doesn’t require removal from the PCB. That means you can image exactly the part that is in the device, without removing it. Of course, you need an IR-sensitive camera, which is about any camera these days if you remove the IR filter from it. You also need an IR source which isn’t very hard to do these days, either.

Do you need the capability to peer inside your ICs? You might not. But if you do and you can live with the limitations of this method, it would be a very inexpensive way to get a glimpse behind the curtain.

If you want to try the old-fashioned way, we can help. Just don’t expect to be as good as [Ken] at doing it right away.

Continue reading “[Bunnie] Peeks Inside ICs With IR”

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”

Dumping script window, showing the bytes being dumped one by one from the STM chip

Need To Dump A Protected STM32F0x? Use Your Pico!

Sometimes, security mechanisms can be bypassed if you just do things slightly out of the ordinary. For instance, readout protection on microcontrollers is a given nowadays, to the point where it’s intentionally enabled and relied upon as a major technical measure to protect intellectual property. The gist is — when you connect to a microcontroller over its debug interface and then ask to read its flash memory, it will politely refuse. However, [Racerxdl] shows us that in practice, it’s not flawless protection – for certain chips, you just need to be a little quicker than usual.

Usually, flashing and debugging software will chat with the microcontroller for a bit, and probe parameters before going for any direct requests. However, if you skip the courtesy and bluntly get to the point immediately right after power is applied to the microcontroller, you can intimidate them just enough to give you one byte of its memory before it refuses to cooperate further. Since that can be any byte you wish, you can read the entire flash — one byte at a time.

You need to power cycle the chip before you can progress, so the hardware does involve a bit more than just an SWD interface, and it will take a fair bit more time than reading out a non-protected chip the usual way; plus, of course, the debugging interface needs to be active for this in the first place, which isn’t always the case. However, it still beats paying a few thousand dollars for a factory in China to decap your chip and read it out using a fancy machine.

[Racerxdl] didn’t just write a proof-of-concept for this attack – they implemented it for one of our favourite chips, the RP2040. As such, you no longer need an unobtainium STM32 to dump an unobtainium STM32.

To be clear, [Racerxdl] didn’t design this attack — it’s been around for some time now. Credit for that goes to Johanes Obermaier. All in all, this is a wonderful reminder that seemingly reliable security mechanisms can be foiled by the simplest tricks. For instance, if your chip erases the flash when you unlock its protection, you can just tell it not to.

The Chipwhisperer adapter plugged into a ChipWhisperer, with the STM chip mentiuoned soldered on

ChipWhisperer Adapter Helps Reverse-Engineer A Controversial Game Cartridge

The ChipWhisperer has been a breakthrough in hobbyist use of power analysis and glitching attacks on embedded hardware. If you own one, you surely have seen the IDC and SMA sockets on it – usable for connecting custom breakouts housing a chip you’re currently probing. Today, [MAVProxyUser] brings us a ChipWhisperer adapter for STM32F446ZEJx, which comes in a UFBGA144 package – and the adapter has quite a backstory to it.

In retro gaming world, a crowdfunding campaign for a game called PAPRIUM has seen a huge success getting funded in 2017. However, the campaign has grossly underdelivered throughout the last five years, and out of those rare cartridges delivered to backers, quite a few have faulty hardware. Getting replacements isn’t realistic at this point, so the repair attempts and game preservation efforts have been ongoing. Trouble is – there are protection mechanisms against dumping the cartridges, and one of the protection mechanisms is the built-in flash read protection of the aforementioned STM32 found on the cartridge. This board adapts the chip to a ChipWhisperer interface for protection bypass exploration, and has quite a few configuration jumpers anyone facing a similar chip is able to use – Eagle files are out there as well, in case your chip needs a slightly different approach.

With reverse-engineering underway, are we likely to see this cartridge’s defenses fall? Our assessment is ‘yes’ – it’s not like there’s a shortage of mechanisms for bypassing security ; from modchips to EMP attacks to blasting the die with a laser, hardware-reliant security is, still, quite bypassable. All in all, despite the drama around the project, this is one more reference design for the ChipWhisperer, and a fun journey to look forward to.