The B-2 Bomber: Those Who Forget History Are Doomed To Reverse Engineer It

The Drive had an interesting post recently, about someone noticed a procurement from the U. S. Air Force to reverse engineer the B-2 bomber’s Load Heat Exchanger (whatever that is). You’d think if the Air Force wanted to reverse engineer something, they’d be looking at another country’s aircraft. What can this mean?

Presumably, the original plans for the system have been lost, or maybe the company who made them is long gone and the tooling to create new ones along with it. Then again, maybe the assembly needs parts that you can no longer get. The Drive has another interesting speculation: perhaps the plans were so secret that were accidentally destroyed.

You don’t hear much about the B-2. There are only 20 left of the 21 built, at least that we know about. Original plans in the 1980s called for 132, but the end of the Cold War spelled the end for the stealth bomber. They get an overhaul every nine years. The Drive also speculates that this may be part of the Air Force’s desire to digitize spare parts and use 3D printing, but — honestly — it doesn’t sound that way to us. Especially since the fleet will retire no later than 2032, so whatever is replaced is only needed for a decade.

If you think you want to have a go, here’s the help wanted ad from the Air Force. If you read the text, it’s pretty clear they have some defective units that need replacement and it sounds like no one knows how to do it with existing materials. Not many of us get to design things that are still working nearly three decades later. Keeping a supply of parts and even know-how for something built in the 1990s isn’t trivial. Something to think about if you design something with a long service life.

The B-2 is a stealth bomber and while one did crash, it wasn’t shot down. The F-117A — the stealth fighter — was shot down against all odds, though. While the B-2 appears to be quite a plane, we prefer our bombers a little bit older. Still, you might enjoy the video below about the B-2’s chief engineer, although he doesn’t mention the Load Heat Exchanger.

Continue reading “The B-2 Bomber: Those Who Forget History Are Doomed To Reverse Engineer It”

Software Challenge’s Solution Shows Reverse Engineering In Action

[0xricksanchez] participated in a software reverse-engineering challenge and recently wrote up the solution, and in so doing also documented the process used to discover it. The challenge was called Devil’s Swapper, and consisted of a small binary blob that output a short message when executed. The goal of the challenge? Discover the secret key and the secret message within. [0xricksanchez]’s writeup, originally intended just as a personal record, ended up doing an excellent job of showing how a lot of reverse engineering tools and processes get applied to software in a practical way.

What’s also great about [0xricksanchez]’s writeup is that it uses standard tools and plenty of screenshots to show what is being done, while also explaining why those actions are being chosen and what is being learned. It’s easy to follow the thought process as things progress from gathering information, to chasing leads, and finally leveraging what’s been learned. It’s a fascinating look into the process of applying the reverse engineering mindset to software, and a good demonstration of the tools. Give it a read, and see how far you can follow along before learning something new. Want more? Make sure you have checked out the Hackaday 2020 Remoticon videos on reverse engineering firmware, and doing the same for PCBs.

Reverse Engineering USB Protocols On A Function Generator

When working with test equipment such as oscilloscopes and function generators, it can be useful to take a screen capture. Historically this was done with Polaroid cameras that were bolted in place, but these days it can be done over a simple USB connection. [Majenko] didn’t like the Windows-only software that shipped with their Tenma 72-14110 function generator, however, and set about reverse engineering the USB protocol to create their own.

The hack was pulled off by running the original software in a Windows VM, while running Wireshark in the host Linux OS to capture the USB traffic. Once enough data had been captured, [Majenko] set about figuring out how the function generator formatted the screen data when sending it to the PC. Based on the fact that the data changed in length depending on what was on the display, it was surmised that the data was not raw, but compressed somehow. A hunch suggested it was probably some form of Run-Length Encoding, and this proved to be correct. With a little more digging and experimentation, [Majenko] was able to put together some code that netted a clear image from the device.

It’s a useful guide for reverse engineering image data, one that could prove useful if you’re tackling a similar problem on other hardware. We’ve seen some great reverse engineering efforts over the years, on everything from old video hardware to the Sega Saturn. If you’ve been diving deep into the secrets of software or hardware yourself, be sure to drop us a line.

Motor Controller Reverse Engineering Releases Smoke

It may have been designed for a sewing machine, but [Haris Andrianakis] found his imported DC brushed motor was more than up to the challenge of powering his mini lathe. Of course there’s always room for improvement, so he set out to reverse engineer the motor’s controller to implement a few tweaks he had in mind. Unfortunately, things took an unexpected turn when plugging his AVR programmer into the board’s ISP socket not only released the dreaded Magic Smoke, but actually tripped the breaker and plunged his bench into darkness.

Studying how the Hall-effect sensors in the motor are wired.

Upon closer inspection, it turned out the board has no isolation between the high voltage side and its digital logic. When [Haris] connected his computer to it via the programmer, the 330 VDC coming from the controller’s rectifier shorted through the USB bus and tripped the Earth-leakage circuit breaker (ELCB). The good news is that his computer survived the ordeal, and even the board itself seemed intact. But the shock must have been too much for the microcontroller he was attempting to interface with, as the controller no longer functioned.

Now fully committed, [Haris] started mapping out the rest of the controller section by section. In the write-up on his blog, he visually masks off the various areas of the PCB so readers have an easier time following along and understanding how the schematics relate to the physical board. It’s a nice touch, and a trick worth keeping in mind during your own reverse engineering adventures.

In the end, [Haris] seems to have a good handle on what the majority of the components are up to on the board. Which is good, since getting it working again now means replacing the MCU and writing new firmware from scratch. Or perhaps he’ll just take the lessons learned from this controller and spin up his own custom hardware. In either event, we’ll be keeping an eye out for his next post on the subject.

Reverse-Engineering An Elevator Control Panel Results In Clicky Goodness

We have to admit that in the hardware hacking universe, there aren’t generally too many chances to hack elevators. Well, at least not opportunities that don’t also include the risk of incarceration. But fortune favors the bold, and when he found the remains of an elevator control panel in an abandoned Croatian resort hotel, [Davor Cihlar] undertook an extensive and instructive reverse-engineering of the panel.

The video below highlights his efforts, which were considerable given the age and state of the panel. This is a relay-only control panel, after all, with most of the relays missing and a rat’s nest of wires connecting the sockets. So [Davor] put his “RevIng” concept to work. This uses a custom PCB with a microcontroller on-board that plugs into each relay socket and probes the connections between it and every other socket. Very clever stuff, and it presented him with the data needed to develop a ladder-logic diagram of the board, with the help of some custom software.

With the original logic in hand, [Davor] set about building a simulator for the panel. It’s a lovely piece of work, with buttons and lights to mimic the control panel inside the elevator car, as well as the call stations that would have graced each lobby of the hotel. Interestingly, he found logic that prevented the elevator from being called to some floors from anywhere but inside the car. The reason remains a mystery, but we suppose that a hotel built by Penthouse publisher [Bob Guccione] would have plenty of secrets.

We love the supremely satisfying clickiness of this build, and the reverse engineering prowess on display, but we can’t find much practical use for something like this. Then again, DIY elevators are a thing.

Continue reading “Reverse-Engineering An Elevator Control Panel Results In Clicky Goodness”

Nissan Gives Up Root Shell Thanks To Hacked USB Drive

For the impatient Nissan owners who may be joining us from Google, a hacker by the name of [ea] has figured out how to get a root shell on the Bosch LCN2kai head unit of their 2015 Xterra, and it looks like the process should be the same for other vehicles in the Nissan family such as the Rogue, Sentra, Altima, and Frontier. If you want to play along at home, all you have to do is write the provided image to a USB flash drive and insert it.

Now for those of us who are a more interested in how this whole process works, [ea] was kind of enough to provide a very detailed account of how the exploit was discovered. Starting with getting a spare Linux-powered head unit out of a crashed Xterra to experiment with, the write-up takes the reader through each discovery and privilege escalation that ultimately leads to the development of a non-invasive hack that doesn’t require the user to pull their whole dashboard apart to run.

The early stages of the process will look familiar to anyone who’s messed with embedded Linux hacking. The first step was to locate the board’s serial port and connect it to the computer. From there, [ea] was able to change the kernel parameters in the bootloader to spawn an interactive shell. To make things a little easier, the boot scripts were then modified so the system would start up an SSH server accessible over a USB Ethernet adapter. With full access to the system, the search for exploits could begin.

A simple script on the flash drive enables the SSH server.

After some poking, [ea] discovered the script designed to mount USB storage devices had a potential flaw in it. The script was written in such a way that the filesystem label of the device would be used to create the mount point, but there were no checks in place to prevent a directory traversal attack. By crafting a label that read ../../usr/bin/ and placing a Bash script on the drive, it’s possible to run arbitrary commands on the head unit. The provided script permanently adds SSHd to the startup process, so when the system reboots, you’ll be able to log in and explore.

So what does [ea] want to do with this new-found exploit? It looks like the goal is to eventually come up with some custom programs that extend the functionality of the in-dash Linux system. As it seems like these “infotainment” systems are now an inescapable feature of modern automobiles, we’re certainly excited to see projects that aim to keep them under the consumer’s control.

Learning To Speak Peloton

Recently [Imran Haque]’s family bought the quite popular Peloton bike. After his initial skepticism melted to a quiet enthusiasm, [Imran] felt his hacker curiosity begin to probe the head unit on the bike. Which despite being a lightly skinned android tablet, has a reputation for being rather locked down. The Peloton bike will happily collect data such as heart rate from other devices but is rather reticent to broadcast any data it generates such as cadence and power. [Imran] set out to decode and liberate the Peleton’s data by creating a device he has dubbed PeloMon. He credits the inspiration for his journey to another hacker who connected a Raspberry Pi to their bricked exercise bike.

As a first step, [Imran] step began with decoding the TRRS connector that connects the bike to the head unit. With the help of a multi-meter and a logic analyzer, two 19200bps 8N1 RS-232 channels (TX and RX) were identified. Once the basic transport layer was established, he next set to work decoding the packets. By plotting the bytes in the packets and applying deductive reasoning, a rough spec was defined. The head unit requested updates every 100ms and the bike responded with cadence, power, and resistance data depending on the request type (the head unit did a round-robin through the three data types).

Once the protocol was decoded, the next step for [Imran] was to code up an emulator. It seems a strange decision to write an emulator for a device with a simple protocol, but the reasoning is quite sound. It avoids a 20-minute bike ride every time a code change needs to be tested. [Imran] wrote both an event-driven and a timing-accurate emulator. The former runs on the same board as the PeloMon and the latter runs on a separate board (an Arduino).

The hardware chosen for the PeloMon was an Adafruit Feather 32u4 Bluefruit LE. It was chosen for supporting Bluetooth LE as well as having onboard EEPROM. A level shifter allows the microcontroller to talk directly to the RS-323 on the bike. After a few pull requests to the Adafruit Bluetooth libraries and a fair bit of head-banging, [Imran] has code that advertises two Bluetooth services, one for speed and another for power. A Bluetooth serial console is also included for debugging without having to pull the circuit out.

The code, schematics, emulators, and research notes are all available on GitHub.