The Raspberry Pi single board computer has been an astounding success since its launch nearly five years ago, to the extent that as of last autumn it had sold ten million units with no sign of sales abating. It has delivered an extremely affordable and pretty powerful computer into the hands of hobbyists, youngsters, hackers, engineers and thousands of other groups, and its open-source Raspbian operating system has brought a useful Linux environment to places we might once have thought impossible.
The previous paragraph, we have to admit, is almost true. The Pi has sold a lot, it’s really useful and lots of people use it, but is Raspbian open-source? Not strictly. Because the Broadcom silicon that powers the Pi has a significant amount of proprietary tech that the chipmaker has been unwilling to let us peer too closely at, each and every Raspberry Pi operating system has shipped with a precompiled binary blob containing the proprietary Broadcom code, and of course that’s the bit that isn’t open source. It hasn’t been a problem for most Pi users as it’s understood to be part of the trade-off that enabled the board’s creators to bring it to us at an affordable price back in 2012, but for open-source purists it’s been something of a thorn in the side of the little board from Cambridge.
This is not to say that all is lost on the blob-free Pi front. Aided by a partial pulling back of the curtain of secrecy by Broadcom in 2014, work has quietly been progressing, and we now have the announcement from [Kristina Brooks] that a minimal Linux kernel can boot from her latest open firmware efforts. You won’t be booting a blob-free Raspbian any time soon as there are bugs to fix and USB, DMA, and video hardware has still to receive full support, but it’s a significant step. We won’t pretend to be Broadcom firmware gurus as we’re simply reporting the work, but if it’s your specialty you can find the code in its GitHub repository. Meanwhile, we look forward to future progress on this very interesting project.
We reported on the partial Broadcom release back in 2014. At the time, the Raspberry Pi people offered a prize to the first person running a native Quake III game on their hardware, sadly though they note the competition is closed they haven’t linked to the winning entry.
[Huan Truong] was given a WiFi router and thought he’d improve it by installing a free firmware on it. Unfortunately, the router in question is a bit old, and wasn’t ever popular to begin with, which meant that it was unsupported by the usual open firmware suspects. The problem was that it only had a 4 MB flash to boot off of, but [Huan] was determined to make it work. (Spoiler: he did it, and documented it fully.)
The flash workaround consisted basically of repartitioning the space, and then telling u-boot where to find everything. On a router like the WNR2000 that [Huan] had, the flash is memory-mapped, which meant adding an offset to the flash start (0xbf000000 instead of 0x00000000) and remembering to do this consistently so that he doesn’t overwrite things like the MAC address.
[Huan] went for the LEDE fork of OpenWRT, and rebuilt it from source because he needed a small version to fit inside his limited flash. With this task completed, it worked. All done? Nope, [Huan] then submitted a pull request to LEDE, and now you can enjoy the fruits of his labor without replicating it. But if you’ve got another low-flash, obscure router, you’ve got a head start in getting LEDE up and running on it.
Routers are perhaps the most-hacked device that we see here, and they can be made pretty darn useful with the right firmware. Sometimes getting a custom firmware running is relatively easy, as it was here, and sometimes it requires some deep reverse engineering. But it’s good to keep up your router-hacking chops, because they may not always be as open as they are now.
As an Apple user, I’ve become somewhat disillusioned over the past few years. Maybe it’s the spirit of Steve Jobs slowly vanishing from the company, or that Apple seems to care more about keeping up with expensive trends lately rather than setting them, or the nagging notion Apple doesn’t have my best interests as a user in mind.
Whatever it is, I was passively on the hunt for a new laptop with the pipe dream that one day I could junk my Apple for something even better. One that could run a *nix operating system of some sort, be made with quality hardware, and not concern me over privacy issues. I didn’t think that those qualities existed in a laptop at all, and that my 2012 MacBook Pro was the “lesser of evils” that I might as well keep using. But then, we published a ThinkPad think piece that had two words in it that led me on a weeks-long journey to the brand-new, eight-year-old laptop I’m currently working from. Those two words: “install libreboot”.
Libreboot is a piece of free software that replaces proprietary BIOS firmware on some modern computers. This has, surprisingly, become increasingly difficult to do as Intel ramps up deployment of the Intel Management Engine. In a nutshell, the IME is a separate processor that can monitor or even take over everything happening in a computer and send that information out over the network to anyone (or any company) that has control of it. It does so without any knowledge of the user and is (obviously) a huge security vulnerability. Since Intel’s competitors do similar things, there’s almost no escape unless you can replace the IME with something like libreboot or coreboot.
Not as Easy as You’d Think
When I started researching libreboot, I assumed that it would be a simple process: download it and run some installer on my computer that would re-flash the BIOS. It couldn’t take any more than a half hour! Especially since the original article simply said “install libreboot” as if it was something that a child could do in between naps. The reality of what I was about to dive into, however, was much different.
First of all, libreboot only works on a handful of older ThinkPads. Newer models have fallen victim to a new strategy by Intel of checking the firmware loaded on the BIOS chip and disabling the computer if an unapproved firmware is discovered. Apparently Intel thinks that fixing security flaws or modifying something that you own is ridiculous and unacceptable. Anyway, I picked up an eight-year-old X200 on eBay for $65 shipped. I’m a simple guy who enjoys simple but reliable things even if they’re getting along in years, so the age of the computer wasn’t too much of a concern for me. Thinking I was doing pretty well for myself, I took a look at the installation instructions for the new firmware.
Some Disassembly Required
This is a step I probably should have taken before ordering the computer. Not that it would have stopped me from doing this, but it probably would have given me a better expectation of what I should expect from this process. First of all, I found out that to flash the chip, disassembly and soldering would be required. The firmware has to be programmed directly. Anytime something like this is done, bricking the device is a real possibility. At least I would only be out $65.
Then, I learned that the BeagleBone Black is the preferred device to use to flash the new firmware to the ThinkPad. I have three Raspberry Pis lying around, but I went ahead and suspiciously ordered a BeagleBone for $40. Couldn’t hurt, I told myself, and I’ll have a new tool to use for other stuff in the future. But it did seem weird that there wasn’t an option to use a Raspberry Pi.
The next hurdle was figuring out exactly what type of firmware chip I had in my laptop, because there are different SOIC clips for different types of chips, and the only way to find out which sized chip I had was to get the laptop and take it apart. This set me back a few days (and another $10) waiting on the correct clip to arrive. During this process I also learned that there is no free software that will run on Intel’s proprietary WiFi card in these computers, so I also ordered an Atheros card to install ($15) since I had the laptop taken apart already.
Moving along, the BeagleBone had to be configured in a very particular way. I had never interacted with one of these before, and it’s not quite as straightforward as a Raspberry Pi. This process took me a few hours over the course of two days. I also learned through a third-party tutorial that Libreboot actually can be flashed with a Raspberry Pi, but this is one (among many) situations where the libreboot folks will go to great lengths to use free and open source software when they can. The BeagleBone fits their requirements, the Pi does not, and they do not mention this. I could easily have saved myself the $40 and used a Pi, but in the spirit of libreboot (and the fact that I was too far along to switch) I pressed on.
Navigating Libreboot’s Install Process
Most of the problem I had setting up the BeagleBone is with libreboot’s files and instructions. For example, at one point I had to patch the libreboot ROM file with a MAC address descriptor specific to the Ethernet card in my laptop. It wasn’t immediately clear which script out of the many provided would do this. Even then, the different ROMs that are available were all in a single folder, and unless you realize this immediately you’ll fill the memory of the BeagleBone when you unzip the archive. In general, it felt like I needed multiple degrees in computer science to make sense of their instructions on the first try. This can be a common plague of free software: alienating people through documentation that doesn’t relate to those with less knowledge and experience. And I’m not exactly an amateur, either. I have a degree in electrical engineering and passable knowledge of what’s going on, but even then I felt like I was blindly charging through a dark jungle of jargon.
Anyway, the BeagleBone Black I received didn’t have a display output (that I could find; I’ve never used one before and might have been missing something) and I had some difficulty getting it to work over the USB link to my Mac. That meant getting it on the network via Ethernet, and since my router is in the kitchen I set up shop there. After soldering some wires to the SOC clip, I was finally ready to start flashing some firmware. At this point, I’ve had the X200 for almost three weeks, all spent waiting on parts I couldn’t have known I needed and programming the BeagleBone to act as a programmer.
The actual flashing only took me about an hour and a half, though. Once I figured out which ROM to use and hooked up my 3.3V power supply (luckily I had one of these cobbled together already) it was a fairly simple process to back up the factory ROM, verify it, and start flashing libreboot. There was one major hiccup at this point, though. I attempted this process four times, and each time the new firmware couldn’t be verified. Error messages appeared everywhere, which is not something you’d want to see at this point in the process. The BeagleBone wrote the firmware successfully but afterwards, for some reason, couldn’t verify it. After getting a little anxious that I might have failed after all of this work, I decided to stick the battery in the laptop to see if it would boot up. I saw the picture of Tux and Gnu hanging out on my BIOS screen, and made the executive decision that libreboot was successfully installed. I went ahead and installed Ubuntu to make sure everything would work correctly since I already had an Ubuntu live-USB stick lying around. Even the new WiFi card seems to work well (except it doesn’t have a 5 MHz antenna like the Intel card did, but that’s not too big of a deal).
Free software aficionados will note that Ubuntu isn’t really the pinnacle of the free software movement. It’s been criticized for including proprietary software, binary blobs, and other issues. That being said, after the initial Ubuntu test installation, I did try to install Trisquel (crashed during the install because it got confused that the X200 doesn’t have an optical drive), a version of Arch called Parabola (wouldn’t boot from a USB stick) and another Debian-based distribution called gNewSense (you have to chuckle at the terrible name), but I found all of them to be difficult to install, unusable, or both.
For now, I’m happy just to have neutralized Intel’s Big Brother and I’ll probably keep using Ubuntu until the libre distributions have improved a little more (or I get really bored one day and decide to try again). Even though the process to install libreboot was tedious, it is possible. I would recommend having a libreboot computer to anyone who cares about privacy, security, or freedom. Even if you don’t want to throw your Apple in the garbage.
If the headline makes today’s hack sound like it was easy, rest assured that it wasn’t. But if you’re interested in embedded device hacking, read on.
[Andres] wanted to install a custom OS firmware on a cheap home router, so he bought a router known to be reflashable only to find that the newer version of the firmware made that difficult. We’ve all been there. But instead of throwing the device in the closet, [Andres] beat it into submission, discovering a bug in the firmware, exploiting it, and writing it up for the manufacturer.
This is not a weekend hack — this took a professional many hours of serious labor. But it was made a lot easier because TP-Link left a debugging protocol active, listening on the LAN interface, and not requiring authentication. [Andres] found most of the information he needed in patents, and soon had debugging insight into the running device.
After some heavy-duty static reverse engineering based on the firmware that he downloaded from the manufacturer’s website, he found a buffer overflow opportunity in the code, and managed to run his own code over the debugging link.
Because [Andres] is a security professional, he gets paid for finding vulnerabilities like this, but also for making them sound ominous. Still, he notes that you can only reach the debug protocol over the local LAN, and not from the network at large. So it’s much more likely that you’ll use this exploit to flash the firmware of your choice than it is that any baddies would do so. (It’s not a bug, it’s a feature!) But still, this is an awesome hack!
Hackaday SuperConference begins tomorrow and every ticketed attendee will get their hands on this sexy piece of hardware which is the conference badge. Yes, it looks fantastic hanging around your neck, you can play a wicked game of Tetris on it, and it runs a crypto challenge. But badge hacking is a thing and this post is the most concise information you’ll find on hacking on the firmware. Whether this is your first time blinking an LED, or you cut your teeth on PIC assembly, you can make this badge do your bidding with minimal effort.
To run your code on the badge you need a compiler. We recommend you install an IDE and compiler on your computer before arriving at the conference. Download and install both MPLABX and the XC8 compiler (you need both).
The other option is a cloud IDE/compiler in the form of MPLAB Xpress. Normally this is the most convenient option but at a conference, you never know how reliable WiFi will be as hundreds of people try to connect devices to the network.
We’ve set up an example in the C language that demonstrates how to interface with the conference badge. Download this and open in MPLABX (installed on your computer in the previous step) or open the cloud version (look for red button that says “Open in IDE”).
The badge is running some hardware tending that will make your hacking easy. The SuperCon-badge-animate.c file has a simple set of demonstrations that show how to illuminate an LED in the display, how to poll the accelerometer (left or right arrow shown above), how to take input from the buttons (ball moves above), and non-blocking timing (flashing rows at about 1 Hz above).
Flashing Your Code:
Flashing your compiled code to the badge is extremely simple:
Plug your badge in using a USB micro-B cable
Hold the power button and press reset to enter bootloader mode
The badge will appear on your computer as a USB thumb drive. Copy your .hex file to this drive
Press the power button to run your code. You do not need to disconnect the cable (make changes to your code, recompile and just start back at step 2)
Where do you get the .hex file? If you are using MPLABX, clicking the “Clean and Build Main Project” will compile your code and the output window will tell you where it is located. For instance:
Loading code from /home/mike/Downloads/2016-Hackaday-SuperCon-BadgeHack.X/dist/default/production/2016-Hackaday-SuperCon-BadgeHack.X.production.hex...
If you are using MPLAB Xpress, the cloud IDE, clicking the “Make and Program Device” button to compile and automatically download your .hex file.
Going Back to Stock Firmware:
Don’t worry, if you don’t like your hack you can always go back to the stock firmware on the badge. Just download the hex file for the demo from Voja’s badge project page.