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”.
Continue reading “Harrowing Story of Installing Libreboot on ThinkPad”
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. (And just as we’re going to press: posting the code for the downgrade exploit here.)
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.
Continue reading “TP-Link Debug Protocol Gives Up Keys To Kingdom”
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.
Continue reading “The Fastest Path to SuperCon Badge Firmware Hacking”
Last year, the Federal Communications Commission proposed a rule governing the certification of RF equipment, specifically wireless routers. This proposed rule required router manufacturers to implement security on the radio module inside these routers. Although this rule is fairly limited in scope – the regulation only covers the 5GHz U-NII bands, and only applies to the radio subsystem of a router, the law of unintended consequences reared its ugly head. The simplest way to lock down a radio module is to lock down the entire router, and this is exactly what a few large router manufacturers did. Under this rule, open source, third-party firmwares such as OpenWRT are impossible.
Now, router manufacturer TP-Link has reached an agreement with the FCC to allow third-party firmware. Under the agreement, TP-Link will pay a $200,000 fine for shipping routers that could be configured to run above the permitted power limits.
This agreement is in stark contrast to TP-Link’s earlier policy of shipping routers with signed, locked firmware, in keeping with the FCC’s rule.
This is a huge success for the entire open source movement. Instead of doing the easy thing – locking down a router’s firmware and sending it out the door – TP-Link has chosen to take a hit to their pocketbook. That’s great news for any of the dozens of projects experimenting with mesh networking, amateur radio, or any other wireless networking protocol, and imparts a massive amount of goodwill onto TP-Link.
Thanks [Maave] for the tip.
Microchip just published their USB-MSD Programmer firmware. This open source project allows a board to enumerate as a USB Mass Storage device. Programming is as simple as copying a .hex file to the “drive”.
This code is what’s running on the $10 Xpress board that they released last month which includes a PIC18F25K50 to serve as a PICkit On Board (PKOB) programmer for the actual target micro; a PIC16F18855. In its stock version, the XPRESS-Loader firmware programs any PIC16F188xx chips that have a row size of 32 words. But it should be possible to tweak this package to program any chips that use the 8-bit LVP-ICSP protocol.
Now, this may seem like small potatoes at first look: it requires two microcontrollers on your board and is capable of programming just a small subset of the vast PIC inventory. But in our minds it’s the USB-MSD that is killer since it doesn’t require any software or drivers on the computer side of things. That’s a big invitation for all kinds of hacks. But there should be even more on the way from the Xpress team before too long.
It turns out the microcontroller [Voja Antonic] chose to use on the Hackaday | Belgrade badge is the 25k50. Since hearing about the Xpress board we’ve been talking to some of the PIC engineers and they are exploring a loader that will program onto the same chip. This means device upgrades without special hardware or drivers – perfect for badge hacking at a conference. This can be done with a precompiled hex, one created on MPLAB X, MPLAB Xpress, or others. We’ll keep you updated if we hear more on that part of the project.