If you’re brave enough to have dipped your toes into the Wild West that is cryptocurrency, you probably know that people have long since abandoned trying to mine on their desktop computers. Farms of GPUs are all the rage now, but dedicated mining hardware has also enjoyed a following among those who are serious about their fictitious money. The state-of-the-art for such devices is moving just as rapidly as cryptocurrency itself is, which means older mining gear can now be picked up fairly cheap on the second-hand market. This is an excellent opportunity for those who want to experiment with this type of hardware and potentially utilize it for some other purpose, but first you’ve got to figure out how the thing works.
To that end, [Tomasz Wątorowski] wrote in to the tip line to tell us about the progress he’s made reverse engineering the control protocol for the Antminer S1. As is often the case, the documentation didn’t have all the details he needed, but it did have a schematic of the BM1380 chip at the heart of the device.
The Antminer S1 contains 64 BM1380 chips on an internal UART bus. With the information from the schematic, [Tomasz] was able to tap into this UART bus with a USB adapter and start listening in on the conversation. He compiled a collection of commands and learned enough to be dangerous (which is always the goal here at Hackaday).
For example, he found that the could set the frequency of the BM1380 as high as he wished without any consideration for thermal overload. This could potentially allow somebody to run the hardware to the point of destruction, à la Stuxnet.
Once he figured out how to give the hardware hashes to work on over the UART interface, he setup a little head-to-head competition between the software he wrote to command the Antminer S1 and the official control software. No drop in performance was found between his software and the real deal, which sounds like a win in our book.
[Syonyk] read that you could solder a few wires to a TEC-06 battery capacity tester, connect it to a TTL serial adapter, and it would interface with some Windows software via a serial port. You can buy it already enabled for serial, but since he had the non-connected version, he was interested in trying it. Not only did it work, but he took the time to reverse engineer the protocol and made a detailed write up about his findings and how he attacked the problem.
Around here, we never need an excuse to reverse engineer anything. But [Synonyk] mentions that he didn’t like using Windows-only software from China. If he wants it on Linux, or if Windows compatibility breaks with a new version, or if the software has spyware in it, he wants to be able to continue using the device. Of course, he also admits — and we get it — that he just enjoys doing it, too.
Infusion pumps and other medical devices are not your typical everyday, off-the-shelf embedded system. Best case scenario, you will rarely, if ever, come across one in your life. So for wide-spread exploitation, chances are that they simply seem too exotic for anyone to bother exploring their weaknesses. Yet their impact on a person’s well-being makes potential security holes tremendously more severe in case someone decides to bother one day after all.
[Scott Gayou] is one of those someones, and he didn’t shy away from spending hundreds of hours of his free time inspecting the Smiths Medical Medfusion 4000 infusion pump for any possible security vulnerabilities. Looking at different angles for his threat model, he started with the physical handling of the device’s user interface. This allowed him to enable the external communication protocols settings, which in turn opened to the device’s FTP and Telnet ports. Not to give too much away, but he manages to gain access to both the file system content and — as a result of that — to the system’s login credentials. This alone can be clearly considered a success, but for [Scott], it merely opened a door that eventually resulted in desoldering the memory chips to reverse engineer the bootloader and firmware, and ultimately executing his own code on the device.
Understanding the implications of his discoveries, [Scott] waited long enough to publish his research so the manufacturer could address and handle these security issues. So kudos to him for fighting the good fight. And just in case the thought of someone gaining control over a machine that is crucial to your vitality doesn’t scare you enough yet, go ahead and imagine that device was actually implanted in your body.
Nothing says friendship like a reverse engineering challenge on unknown terrain as a birthday present. When [Rikaard] turned 25 earlier this year, his friend [Veydh] put together a Capture the Flag challenge on an ESP8266 for him. As a software guy with no electronics background, [Rikaard] had no idea what he was presented with, but was eager to find out and to document his journey.
Left without guidance or instructions, [Rikaard] went on to learn more about the ESP8266, with the goal to dump its flash content, hoping to find some clues in it. Discovering the board is running NodeMCU and contains some compiled Lua files, he stepped foot in yet another unknown territory that led him down the Lua bytecode rabbit hole. After a detour describing his adjustments for the ESP’s eLua implementation to the decompiler he uses, his quest to capture the flag began for real.
A few semesters back, [Jordan] was in an Intro to Hardware Security course at CMU. The final project was open ended, and where some students chose projects like implementing a crypto algorithm or designing something on an FPGA, [Jordan] decided to do something a little more ambitious. He wanted to decapsulate and reverse engineer an IC. No, this isn’t taking a peek at billions of transistors — [Jordan] chose a 74-series Quad XOR for this project — but it does show what goes into reverse engineering silicon, and how even simple chips can be maddeningly confusing.
The first step to reverse engineering a chip is decapsulation, and for this [Jordan] had two options. He could drop acid, or he could attack a ceramic package with an endmill. While hot nitric acid is effective and fun, it is a bit scary, so [Jordan] mounted a few chips in a 3D printed holder wedged in the vice on his mill. By slowly bringing the Z axis down a few thou at a time, he was able to find the tiny 1 mm square bit of silicon embedded in this chip. With the help of a grad student and the cleanroom, this square of sand was imaged with a very nice microscope.
Now that [Jordan] had an image of the silicon itself, he had to reverse engineer the chip. You might think that with less than a dozen transistors in there, designing an XOR out of transistors is something anyone with a bit of Minecraft experience can do. This line of thinking proved to be a trap. Technically, this wasn’t an XOR gate. It was a transmission gate XNOR gate with a big inverter on the output. Logically, it’s the same, but when it comes to silicon fabrication, the transmission gate XNORs aren’t able to sink or source a lot of current. By designing the chip as an XNOR with an inverter, the chip designers were able to design a simple chip that could still meet the spec.
While [Jordan] managed to reverse engineer the chip, this was quite possibly the simplest chip he could reverse engineer. The Quad XOR is just the same silicon repeated four times, anyway. This is the baseline for all efforts to reverse engineer silicon, and there were still a few confusing traps.
Opening up things, see how they work, and make them do what you want are just the basic needs of the average hacker. In some cases, a screwdriver and multimeter will do the job, but in other cases a binary blob of random software is all we have to work with. Trying to understand an unknown binary executable is an exciting way to discover a system’s internal functionality.
While the basic principles of software reverse engineering are universal across most platforms, the details can naturally vary for different architectures. In the case of the x86 architecture, [Leo Tindall] felt that most tutorials on the subject focus mostly on 32-bit and not so much on the 64-bit specifics. Determined to change that, [Leo] ended up with an extensive introduction tutorial for reverse engineering x86_64 binaries starting at the very basics, then gradually moving forward using crackme examples. Covering simple string analysis and digging through disassembled binaries to circumvent fictional security, the tutorial later introduces the Radare2 framework.
All example source code is provided in the accompanying GitHub repository, although it is advised to avoid looking at them to keep it more interesting and challenging. And in case you are looking for more challenges later on, or generally prefer a closer connection to the hardware, these MSP430 based capture the flag online challenges might be worth to look at next.
A hackspace discussion of voltage regulators within our earshot touched on the famous μA723, then moved on to its competitors. Kits-of-parts for linear regulators were ten-a-penny in the 1970s, it seems. A rambling tale ensued, involving a Lambda power supply with a blown-up chip, and ended up with a Google search for the unit in question. What it turned up was a hack from 2014 that somehow Hackaday missed at the time, the replication by [Eric Schlaepfer] of an out-of-production regulator chip using surface-mount semiconductors when his Lambda PSU expired.
Lambda were one of those annoying electronics companies with a habit of applying their own part numbers to commonly available chips in an effort to preserve their spares sales. Thus the FBT-031 in this Lambda PSU was in fact a Motorola MC1466, a dirt-cheap common part in the 1970s. Unfortunately though unlike the 723 the MC1466 has long passed out of production, and is rarer than the proverbial hen’s tooth.
Happily, these chips from the early 1970s were often surprisingly simple inside. The MC1466 schematic can be found on its data sheet, and is straightforward enough to replicate with surface-mount discrete components. He thus created a PCB that replicated the original pin layout even though it overlapped the original footprint. A few parts were slightly unusual, dual transistor arrays and a matched triple diode, but the result proved to be a perfect replacement for a real MC1466. Of course a project like this is almost too simple for [Eric], who went on to build the incredible Monster 6502.