Practical Advice For The Hardware Security Community

Researchers should emulate device firmware in order to study how devices work and look into their vulnerabilities.

Ta-Lun Yen Leave a Comment
Practical Advice For The Hardware Security Community

As hardware can be costly and difficult to obtain, it is paramount that researchers have methods to emulate device firmware in order to study how devices work and look into their vulnerabilities. For firmware analysis, there are a couple of tools for hardware emulation and extraction, but these tools either only support recent firmware (Linux-based firmware, for example), or are not easy to obtain in the first place, as they’re most likely hidden behind NDAs. For Windows CE environments it was previously only possible to extract binaries and analyze them in disassemblers, as the CE (6) kernel is very different from Windows NT’s kernel and very difficult to analyze dynamically.

While Microsoft phased out Windows CE 6 a long while ago, it is still used commonly, and some vendors including Siemens and GE still use them in their products.

One straightforward method of accomplishing this is to emulate the device directly, for example by running it in commonly seen emulation software (QEMU). However, because vendors usually build their software closely bundled to their custom-made hardware, this can be very difficult to achieve as it requires a very deep knowledge of said device and its inner workings. We made repeated attempts to emulate our target device using this method. While we achieved partial success, we decided to not to go with this route as we found it to be impractical – this method requires modification on a by-device basis, which quickly becomes time-consuming.

Read Next: Report: 83 Million Cameras, Other Devices Prone to IoT Vulnerability

After abandoning our initial approach, we found another way to achieve firmware emulation – building our own firmware with files extracted as-is from the target firmware. There are a couple of open-source projects that can do this, but due to how CE6 bundles its image files, the files aren’t immediately ready for use after extraction. To get around this we proposed a new method, “Static Reconstruction of Relocation Information”. It enables researchers to “transplant” CE6 binaries to any environment they have direct control over, allowing the use of custom-built images with instrumentation and debug tools.

The method was achieved by extracting the firmware and analyzing it as-is. By re-building the parts stripped from the firmware building process and writing them back into the binary, the firmware can be deployed and used based on the way vendors would build these images normally.

In our testing environment, we successfully emulated a famous vendor’s HMI runtime in our own environment. We had full control over it, unlike our previous setup for hardware research which came with many more restrictions. This is particularly powerful for research because in most scenarios devices being sold on market and used in production will not have a debug port and serial outputs open to anyone with access to the hardware like ordinary IoT devices.

Our research liberates researchers by allowing them to run CE6 binaries dynamically outside their original environment. We plan to extend this research further, as the method has still not been employed in our formal engagements. While similar methods have previously not been workable, our method is differentiated in that it only uses static reconstruction, which simplifies the process of emulation considerably.

If you enjoyed this article and want to receive more valuable industry content like this, click here to sign up for our digital newsletters!