Image

Coreboot Hikes The Bay Trail To DRAM Initialization

This article is written on an open-source operating system, but not an open-source machine — the BIOS isn’t open-source, and even if it were supported by the coreboot project (formerly LinuxBIOS), there would still be a whole host of binary blobs required to get it to boot. On one vintage architecture, there’s one less blob, as coreboot can now initialize DRAM on Intel Bay Trail SOCs, as [Mate Kukri] presented in a talk at the recent Open Source Firmware Conference.

Bay Trail isn’t exactly cutting-edge hardware, to be sure — the SoCs are over a decade old at this point, and were only used in low-performance mobile applications like Chromebooks. On the other hand, coreboot has been on Chromebooks for at least as long. Getting DRAM set up is difficult because, well, you don’t have any memory to work with until you do. Traditionally, the way you did that was to call on one of the many proprietary ‘binary blobs’ provided with next to no documentation by the manufacturer. Reverse engineering that requires some serious bus-sluthing, which was done in software with the SerialICE debugger and the Unicorn Engine CPU emulator. The talk focused on that technique and how it might be applied more widely, rather than getting into the weeds of how to do DRAM init on one obsolete SOC. At some point the whole thing should be archived on the OFSC website so those of us not lucky enough to attend in person can hear what [Mate] — and all the other speakers — had to say.

Continue reading “Coreboot Hikes The Bay Trail To DRAM Initialization”

Image

Reverse-Engineering The ESP32’s WiFi Binary Blob With A Faraday Cage

The Faraday cage constructed by Jasper Devreker.
The Faraday cage constructed by Jasper Devreker.

As part of a team reverse-engineering the binary blob driver for the ESP32’s WiFi feature at Ghent University, [Jasper Devreker] saw himself faced with the need to better isolate the network packets coming from the ESP32-under-test. This is a tough call in today’s WiFi and 2.4 GHz flooded airwaves. To eliminate all this noise, [Jasper] had to build a Faraday cage, but ideally without racking up a massive invoice and/or relying on second-hand parts scavenged from eBay.

We previously reported on this reverse-engineering project, which has since seen an update. Although progress has been made, filtering out just the packets they were interested in was a big challenge. The solution was a Faraday cage, but on a tight budget.

Rather than relying on exotic power filters, [Jasper] put a battery inside a Faraday cage he constructed out of wood and conductive fabric. To get Ethernet data in and out, a fiber link was used inside a copper tube. Initial testing was done using a Raspberry Pi running usbip and a WiFi dongle.  The Faraday cage provided enough attenuation that the dongle couldn’t pick up any external WiFi signals in listening mode.

The total cost of this build came down to a hair over €291, which makes it feasible for a lot of RF experiments by hobbyists and others. We wish [Jasper] and the rest of the team a lot of luck in figuring out the remaining secrets of Espressif’s binary WiFi blob using this new tool.

Image

One Less Binary Blob

Open-source software has gone a long way into making modern technology the way it is today. The Linux kernel alone is almost single-handedly holding up the entire Internet, and various other open-source projects allow for more access to computing resources not just because the software is often free, but because it’s possible to look under the hood and modify it for specific needs. Without open-source software available we often run into problems both expected, such as software licensing costs, and unexpected, which often come up because a developer can’t or won’t fix issues or add features. To that end, a group at Ghent University in Belgium are attempting to rectify a problem with the ESP32 by eliminating one of its binary blobs and replacing it with an open source driver.

The ESP32 is famously a low-cost microcontroller with on-board wireless capabilities, but its Wi-Fi functionality currently relies on closed-source software from Espressif. The team is currently working on building a fully working open-source networking stack with the hopes of enabling greater flexibility of these devices but also making things like security auditing possible. The other major goal is to improve low-cost mesh networking which is currently not available with the proprietary driver. Reverse engineering is the name of the game here, both from a hardware and a software level, but current versions of the software already able to send and receive packets.

The source code for the project is available on the team’s GitHub page for any open-source aficionados to take a look at. We certainly hope the project gains some steam, as any new open source project helps all of us using the platform. Open source projects frequently get stymied by a single or small handful of binary blobs too, often with little hope for recourse. Examples include Android being an open-source operating system but generally using the closed-source Google Play suite in practice, or Firefox including support for Adobe Flash. Another great example is that even computers running 100% open-source code once they boot their operating systems, there’s still some black boxes running in the background few of us think about.

Thanks to [Crote] for the tip!