Have you ever wondered how you could look at a chip and map out its schematic? [Robert Baruch] wants to show you how he does it and he does in a new video (see below). The video assumes you know how to expose the die because he’s made a video about that before.
This video focuses on using his Beaglebone-driven microscope stage to get high-resolution micrographs stitched together from smaller shots. A 3D-printed sample holder keeps the part from moving around. Luckily, there’s software to stitch the images together. Once he has the die photo, he will etch away the metal to remove the passivation, the metal layer, and the silicon dioxide under the metal and takes another set of photos.
Continue reading “How to Reverse Engineer a Chip”
We’ve often heard (and said) if you can’t hack it, you don’t own it. We noticed that [tmbinc] has issued a call for help on his latest project: developing new firmware and an FPGA configuration for the Rigol DS1054Z and similar scopes. It isn’t close to completion, but it isn’t a pipe dream either. [tmbinc] has successfully booted Linux.
There’s plenty left to do, though. He’s loading a boot loader via JTAG and booting Linux from the USB port. Clearly, you’d want to flash all that. Linux gives him use of the USB port, the LCD, the network jack, and the front panel LEDs and buttons. However, all of the actual scope electronics, the FPGA functions, and the communications between the processor and the FPGA are all forward work.
Continue reading “Help Wanted: Open Source Oscilloscope on Rigol Hardware”
The ESP32 is Espressif’s new wonder-chip, and one of the most interesting aspects of its development has been the almost entirely open-source development strategy that they’re taking. But the “almost” in almost entirely open is important — there are still some binary blobs in the system, and some of them are exactly where a hacker wouldn’t want them to be. Case in point: the low-level WiFi firmware.
So that’s where [Jeija]’s reverse engineering work steps in. He’s managed to decode enough of a function called
ieee80211_freedom_output to craft and send apparently arbitrary WiFi data and management frames, and to monitor them as well.
This ability is insanely useful for a WiFi device. With low-level access like this, one can implement custom protocols for mesh networking, low-bandwidth data transfers, or remove the requirement for handshaking entirely. One can also spam a system with so many fake SSIDs that it crashes, deauth everyone, or generally cause mayhem. Snoop on your neighbors, or build something new and cool: with great power comes great responsibility.
Anyway, we reported on [Jeija]’s long distance hack and the post may have read like it was all about the antenna, but that vastly underestimates the role played by this firmware reverse-engineering hack. Indeed, we’re so stoked about the hack that we thought it was worth reiterating: the ESP32 is now a WiFi hacker’s dream.
Integrated circuits are a fundamental part of almost all modern electronics, yet they closely resemble the proverbial “black box” – we may understand the inputs and outputs, but how many of us truly understand what goes on inside? Over the years, the process of decapping ICs has become popular – the removal of the package to enable peeping eyes to glimpse the mysteries inside. It’s an art that requires mastery of chemistry, microscopy and photography on top of the usual physics skills needed to understand electronics. Done properly, it allows an astute mind to reverse engineer the workings of the silicon inside.
There are many out there publishing images of chips they’ve decapped, but [Robert Baruch] wants more. Namely, [Robert] seeks to create a database of die images of all 5400 and 7400 series logic chips – the eponymous Project 54/74.
These chips are the basic building blocks of digital logic – NAND gates, inverters, shift registers, decade counters and more. You can build a CPU with this stuff. These days, you may not be using these chips as often in a production context, but those of you with EE degrees will likely have toyed around a few of these in your early logic classes.
There’s only a handful of images up so far, but they’re of excellent quality, and they’re also annotated. This is a great aid if you’re trying to get to grips with the vagaries of chip design. [Robert] is putting in the hard yards to image as many variations of every chip as possible. There’s also the possibility of comparing the same chip for differences between manufacturers. We particularly like this project, as all too often manufacturing techniques and technologies are lost and forgotten as the march of progress continues on. It looks like it’s going to become a great resource for those looking to learn more about integrated circuit design and manufacture!
Ask any security professional and they’ll tell you, when an attacker has hardware access it’s game over. You would think this easily applies to arcade games too — the very nature of placing the hardware in the wild means you’ve let all your secrets out. Capcom is the exception to this scenario. They developed their arcade boards to die with their secrets through a “suicide” system. All these decades later we’re beginning to get a clear look at the custom silicon that went into Capcom’s coin-op security.
Alas, this is a “part 1” article and like petulant children, we want all of our presents right now! But have patience, [Eduardo Cruz] over at ArcadeHacker is the storyteller you want to listen to on this topic. He is part of the team that figured out how to “de-suicide” the CP2 protections on old arcade games. We learned of that process last September when the guide was put out. [Eduardo] is now going through all the amazing things they learned while figuring out that process.
These machines — which had numerous titles like Super Street Fighter II and Marvel vs. Capcom — used battery-backed ram to store an encryption key. If someone tampered with the system the key would be lost and the code stored within undecipherable thanks to “two four-round Feistel ciphers with a 64-bit key”. The other scenario is that battery’s shelf life simply expires and the code is also lost. This was the real motivation behind the desuicide project.
An overview of the hardware shows that Capcom employed at least 11 types of custom silicon. As the board revisions became more eloquent, the number of chips dropped, but they continued to employ the trick of supplying each with battery power, hiding the actual location of the encryption key, and even the 68000 processor core itself. There is a 6-pin header that also suicides the boards; this has been a head-scratcher for those doing the reverse engineering. We assume it’s for an optional case-switch, a digital way to ensure you void the warranty for looking under the hood.
Thanks for walking us through this hardware [Eduardo], we can’t wait for the next installment in the series!
Admit it, you love looking at silicon die shots, especially when you have help walking through the functionality of all the different sections. This one’s really easy for a couple of reasons. [electronupdate] pointed his microscope at the die on a WS2812.
The WS2812 is an addressible RGB LED that is often called a Neopixel (a brand name assigned to it by Adafruit). The part is packaged in a 5×5 mm housing with a clear window on the front. This lets you easily see the diodes as they are illuminated, but also makes it easy to get a look at the die for the logic circuit controlling the part.
This die is responsible for reading data as it is shifted in, shifting it out to the next LED in the chain, and setting each of the three diodes accordingly. The funcitonality is simple which makes it a lot easier to figure out what each part of the die contributes to the effort. The diode drivers are a dead giveaway because a bonding wire connected to part of their footprint. It’s quite interesting to hear that the fourth footprint was likely used in testing — sound off in the comments if you can speculate on what those tests included.
We had no trouble spotting logic circuitry. This exploration doesn’t drill down to the gate level like a lot of [Ken Shirriff’s] silicon reverse engineering but the process that [electronupdate] uses is equally fun. He grabs a tiny solar cell and scopes it while the diodes are running to pick up on the PWM pattern used to fade each LED. That’s a neat little trick to keep in your back pocket for use in confirming your theories about clock rate and implementation when reverse engineering someone else’s work.
Continue reading “Closer Look at Everyone’s Favorite Blinky”
[James Tate] is starting up a project to make a “Super Reverse-Engineering Tool”. First on his list? A simple NAND flash reader, for exactly the same reason that Willie Sutton robbed banks: because that’s where the binaries are.
As it stands, [James]’s first version of this tool is probably not what you want to use if you’re dumping a lot of NAND flash modules. His Arduino code reads the NAND using the notoriously slow
digital_write() commands and then dumps it over the serial port at 115,200 baud. We’re not sure which is the binding constraint, but neither of these methods are built for speed.
Instead, the code is built for hackability. It’s pretty modular, and if you’ve got a NAND flash that needs other low-level bit twiddling to give up its data, you should be able to get something up and working quickly, start it running, and then go have a coffee for a few days. When you come back, the data will be dumped and you will have only invested a few minutes of human time in the project.
With TSOP breakout boards selling for cheap, all that prevents you from reading out the sweet memory contents of a random device is a few bucks and some patience. If you haven’t ever done so, pull something out of your junk bin and give it a shot! If you’re feeling DIY, or need to read a flash in place, check out this crazy solder-on hack. Or if you can spring for an FTDI FT2233H breakout board, you can read a NAND flash fast using essentially the same techniques as those presented here.