As penetration testers and security professionals everywhere can attest, extracting firmware from sophisticated hardware can be a formidable challenge: You break open the device, search in vain for debug serial ports and eventually concede that blackbox testing is enough. During my internship at Security Innovation, I chose to replicate a tool for dumping firmware of USB devices created by Micah Elizabeth Scott (Scanlime). The tool is called FaceWhisperer, as an amalgamation of Travis Goodspeed's FaceDancer tool for scriptable USB interaction, and the ChipWhisperer hardware glitching and side channel analysis platform.
Figure 1: The original FaceWhisperer Board
This tool leverages glitching attacks which briefly dump the voltage of the device under test in order to write to memory and change the state of registers. We can inject these glitches during a crucial stage of the USB protocol-when device descriptors are sent to the host. If we glitch the device at the precise moment when device descriptors are being sent, we can overwrite the section of memory which governs the length of data to be sent. This results in an information disclosure which reveals the remainder of the memory section; and because device descriptors are often stored in ROM alongside the firmware, we have a good chance to reveal the entirety of the firmware. It may seem farfetched, but with help from precise power analysis and logic probes, we can glitch at this moment with near certainty. This is accomplished with the FaceWhisperer, a custom USB host to provide repeatability and timing cues which will help instrument the glitching process.
Figure 2: Testing Setup
Building the FaceWhisperer board taught me valuable lessons about the fundamentals of prototyping and manufacturing. During my first attempt at sourcing parts, I realized that part numbers often fail to reflect the package type and size. After reordering and many long evenings soldering and chasing chips across the board, the FaceWhisperer was operational. I hooked up the lab's Saleae logic probes to the D+ and D- lines of the USB cable, and determined the approximate timing of the get descriptor request. Using these timing marks as my guide, I connected the ChipWhisperer's glitching line to my target board and started glitching. The first run of glitching produced no results, and I realized that the decoupling caps on the board were providing power during my glitches, neutralizing any effect. After removing these capacitors, I detected glitches, but none of them extended the length of the device's response.
I needed more insight into the operation of the device under test to determine why my glitches were failing. The easiest way to get this information was to perform power analysis on the device under test. The ChipWhisperer has power analysis capabilities, but in order to utilize them, the power measured must be very clean. This can be achieved with a combination of low and high pass filters implemented with a set of 10uf and 200uf capacitors. With this setup in place, I captured the following power analysis trace.
This trace demonstrated that I was glitching too late, and missing the time period associated with transmission. Moving the glitch backwards produced longer results, but no result was longer than 255 bytes. After reading up on the device under test's chip, I realized that it was using a Harvard architecture which has distinct memory sections for code and working memory. The working memory or RAM of this chip was exactly 255 bytes long, leading me to believe that I was actually revealing all of RAM, not all of ROM. Unfortunately, my internship came to an end so I was unable to analyze this information further; however, as RAM holds temporary variables and other high use memory, this could be an interesting avenue for future research. Examining common usage of RAM during the USB setup process may lead to further vulnerabilities or insight into the chip’s operation.
While this result was not my intended conclusion, it proves that the technique is effective and under the right architecture, can be a relatively low effort technique to obtain previously untouchable firmware. For those interested in attempting to duplicate ScanLime’s work, below are some debugging tips and tricks:
- Test the FaceWhisperer’s board with logic probes before attaching to a device to ensure the board is operating properly.
- When searching for useful glitches on a device under test, try a wide range of glitches with a large number of repeats (5-10) per glitch. I found that emphasising covering a large range was more productive than diving down into sub clock cycle precision.
- If the power analysis you receive from the ChipWhisprer is too noisy, don’t be afraid to add more decoupling caps, both on the chip and power supply side.
I’m extremely grateful to Security Innovation for providing me the opportunity to further my knowledge in hardware exploitation and to ScanLime for putting out such an awesome tool. Hopefully this knowledge can be put to use by security professionals as another tool in the firmware dumping toolkit.
Written by Maxfield Chen, Security Innovation Intern
