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.

Reverse-Engineering The Conditional Jump Circuitry In The 8086 Processor

The condition PLA evaluates microcode conditionals.
The condition PLA evaluates microcode conditionals.

As simple as a processor’s instruction set may seem, especially in a 1978-era one like the Intel 8086, there is quite a bit going on to go from something like a conditional jump instruction to a set of operations that the processor can perform. For the CISC 8086 CPU this is detailed in a recent article by [Ken Shirriff], which covers exactly how the instructions with their parameters are broken down into micro-instructions using microcode, which allows the appropriate registers and flags to be updated.

Where the 8086 is interesting compared to modern x86 CPUs is how the microcode is implemented, using gate logic to reduce the complexity of the microcode by for example generic parameter testing when processing a jump instruction. Considering the limitations of 1970s VLSI manufacturing, this was very much a necessary step, and an acceptable trade-off.

Each jump instruction is broken down into a number of micro-instructions that test a range of flags and updates (temporary) registers as well as the program counter as needed. All in all a fascinating look at the efforts put in by Intel engineers over forty years ago on what would become one of the cornerstones of modern day computing.

Inside Globus, A Soviet-Era Analog Space Computer

Whenever [Ken Shirriff] posts something, it ends up being a fascinating read. Usually it’s a piece of computer history, decapped and laid bare under his microscope where it undergoes reverse engineering and analysis to a degree that should be hard to follow, but he still somehow manages to make it understandable. And the same goes for this incredible Soviet analog flight computer, even though there’s barely any silicon inside.

The artifact in question was officially designated the “Индикатор Навигационный Космический,” which roughly translates to “space navigation indicator.” It mercifully earned the nickname “Globus” at some point, understandable given the prominent mechanized globe the device features. Globus wasn’t actually linked to any kind of inertial navigation inputs, but rather was intended to provide cosmonauts with a visual indication of where their spacecraft was relative to the surface of the Earth. As such it depended on inputs from the cosmonauts, like an initial position and orbital altitude. From there, a complicated and absolutely gorgeous gear train featuring multiple differential gears advanced the globe, showing where the spacecraft currently was.

Those of you hoping for a complete teardown will be disappointed; the device, which bears evidence of coming from the time of the Apollo-Soyuz collaboration in 1975, is far too precious to be taken to bits, and certainly looks like it would put up a fight trying to get it back together. But [Ken] still manages to go into great depth, and reveals many of its secrets. Cool features include the geopolitically fixed orbital inclination; the ability to predict a landing point from a deorbit burn, also tinged with Cold War considerations; and the instrument’s limitations, like only supporting circular orbits, which prompted cosmonauts to call for its removal. But versions of Globus nonetheless appeared in pretty much everything the Soviets flew from 1961 to 2002. Talk about staying power!

Sure, the “glass cockpit” of modern space vehicles is more serviceable, but just for aesthetics alone, we think every crewed spacecraft should sport something like Globus. [Ken] did a great job reverse-engineering this, and we really appreciate the tour. And from the sound of it, [Curious Marc] had a hand in the effort, so maybe we’ll get a video too. Fingers crossed.

Thanks to [saintaardvark] for the tip.