Free Your Router, Again!
One of our long time customers from continental Europe, who is providing Wi-Fi and related services for various venues, has approched us recently with a huge concern. This concern was related to the recent rise of the Wi-Fi access points (AP) devices locked down done by the manufacturers.
For their entry level service which is targeted at small venues like cafés, they’re simply buying SOHO (Small Office/Home Office) Wi-Fi Open Mesh OM2P APs. All Open Mesh devices are shipped by default with the Open Mesh firmware called CloudTrax preinstalled. This firmware is 95% based on the well-known Open Source project OpenWrt, with about 5% proprietary additions for cloud management etc.
Our customer doesn’t use this preinstalled CloudTrax firmware, so once the devices arrive, they simply flash (or rather reprogram) them with their custom built firmware, which is BTW also based on OpenWrt.
Some of their customers started asking for 802.11ac Wi-Fi service, so naturally they’ve bought Open Mesh OM5P-AC access points and as usual, once the APs had arrived to the office, they’ve tried to flash them with their custom built firmware. But this time, the flashing procedure of the custom firmware failed, something has apparently changed…
Connecting to the affected OM5P-AC v2 AP using serial console, we’ve quickly found out, that indeed the U-Boot bootloader seems to be updated, and that the new version of flashing procedure is now expecting part of the firmware images to be signed with some kind of cryptographic signature. Open Mesh has also disabled access to the U-Boot CLI from serial console.
You need to “unlock” the U-Boot in the access point in order to flash the custom firmware. You can find detailed How-To and other details in the Wiki as well.
And for very impatient:
$ git clone https://github.com/true-systems/om5p-ac-v2-unlocker $ less README.md
Photo of Open Mesh OM5P-AC v2 (top of the PCB)
Curious observer of the top PCB photo above, might have noticed, that there’s SOIC8 adapter soldered on, in the middle of the picture. To make it clear, it’s adapter used for faster and easier access to SPI EEPROM flash chip memory, and the adapter is not installed there by the Open Mesh by default :-)
High resolution pictures of the OM5P-AC v2 access point:
You might have noticed this alarming trend, that some manufactures of Wi-Fi routers in SOHO market segment started locking down their devices. By locking down, we mean implementation of various ways to prevent flashing of any 3rd party firmware to their devices.
We’ve noticed this lockdown attempts in products from Ubiquity, TP-Link and Open Mesh to just give you some examples. But the list is much longer.
It has all probably started in March 2014, when the US Federal Communications Commision (FCC) has updated the software security requirements for devices operating in the 5GHz wireless band:
Manufacturers must implement security features in any digitally modulated devices capable of operating in any of the U-NII bands, so that third parties are not able to reprogram the device to operate outside the parameters for which the device was certified.
For interested readers, there’s a nice compilation of all relevant information on FCC’s new regulations regarding 5GHz wireless band at PRPL’s Wiki page Complying with FCC rules on Wifi.
So, according to this updated FCC regulations, somewhere in the middle of the year 2016, the Open Mesh announced lock down of their 5GHz capable APs, including the OM5P-AC access point:
The restrictions are the same as those on the OM5P-AC device, and include:
- Custom firmware versions can no longer be loaded onto the device.
That’s it, no custom firmware on the Open Mesh APs anymore, right? No.
Simply said, it’s impossible task for this kind of low cost hardware. Or do
you expect, that sub $1 SPI EEPROM flash chip has some cryptography features
cooked in? The same applies to the QCA955x WiSoC used in OM5P-AC device. It’s
mission impossible, but even
the Open Mesh
someone using @open-mesh.com email address
thinks, that locked down U-Boot is a reasonable and solid lockdown solution:
swapping the u-boot is not so trivial, at least without opening/soldering/modifying the flash from outside, which is considered a reasonable hurdle.
Motivation behind the OM5P-AC unlocker solution
We love embedded hardware of all kinds and we like to have everything under our control, probably as you do. If we can’t build complete software stack from scratch, from bootloader to the user space applications, we simply don’t use it and move on.
We’re users and supporters of open source, so we take it almost personally
if some vendors like Open Mesh (BTW since February 2017 it’s
Datto company), which are using
open source software in their products and benefit from it to a great extent,
don’t play nice with the open source community and even violates the copyright
law. Yep, the usual GNU
infringement. We’ve asked Open Mesh in November
sources of U-Boot (GPLv2 license) for OM5P-AC device, but we didn’t received
the sources till today, as of Sunday February 12th, 2017.
Update on February 15th 2017: In December 2016 we’ve received three files
via Open Mesh support,
MR900,MR1750 source code.zip and
ELX_Uboot_sdk_20161201.tar.bz2, which we’ve put immediately under our
GitHub account. Today we’ve received the
information, that the sources for OM5P-AC-v2 are located inside the
ELX_Uboot_sdk_20161201.tar.bz2 file. We even got the build
building U-Boot for OM5P-AC-v2 from sources! Kuddos to Open Mesh for this.
We could probably make our customer happy with simple shell unlocking solution we’ve found using JTAG and bit of luck within few days. This solution is based on the fact, that the RSA public key used for signature verification of the firmware is written in part of the SPI EEPROM flash, which is writtable by the system. So you can just login to the router using SSH (LAN connection) and then just zero out the header of the RSA public key.
This few shell commands are all you need to execute on your AP, in order to “unlock” the U-Boot bootloader, because if the U-Boot doesn’t find a valid RSA key in the flash, it simply disables the firmware signature verification code path.
Well, to execute the shell commands you need access to the router over the SSH connection, right. Open Mesh users located within USA or Canada are treated with more love in the CloudTrax cloud system and as a reward for their customer loyalty?, they nowadays can’t even connect to their access points with SSH. How long it’s going to take Open Mesh to treat all customers equally? When they start rewarding them all with no SSH access?
It was clear, that we needed a better solution then unlocking with SSH. We were also aware of the fact, that there’s not much information about similar unlocking processes publicly available. You can find some bits on the Chinese and Russian speaking parts of Internet, but that’s all about it. Not much information about this subject at one place.
So we took this Open Mesh unlocking project as an example, we wanted to create some kind of the basic starter guide, guide which might help you in similar situations.
The more such guides, the more such low level details, the better. We encourage everyone to document their findings and share them. There’s always someone like us, who might need your precious information and findings one day. We’re even happy to read about the failed attempts - we don’t like to explore the roads with dead ends :-)
This blog post would be very long if we would try to explain everything here. So this blog post is just an overview, mainly to answer the “why?” question, provide some background information and a way to help spread the word out.
We’ve prepared all the details on project’s Wiki, so you can find there all the details about OM5P-AC v2 hardware, very detailed overview of the Open Mesh approach to lock down of their devices, and mainly some information about actual exploit.
The most important detail at the end, all the sources for the OMP5-AC v2 unlocker.
Enjoy. Now go and free your router, again!
November 18th 2016 - Contacted Open Mesh regarding the GPL source code
November 19th 2016 - Asked our contacts in the country, where everything is possible, for help with documentation for QCA955x WiSoCs
November 25th 2016 - We’ve received the datasheets for QCA955x WiSoCs
November 29th 2016 - Ordered 8Devices Rambutan Devkits as the hardware is very similar to OM5P-AC v2 and has JTAG available
December 15th 2016 - Started playing with U-Boot from OMP5-AC v2 device on Rambutan board and fiddling with JTAG
December 15th 2016 - We had some luck finally and we’ve found the RSA public key in the ART MTD partition and were able to unlock the U-Boot for the first time!
December 19th 2016 - Received the link with U-Boot sources for MR1750
AP from Open
December 19th 2016 - Received the link with U-Boot sources for MR1750, MR900, OM5P-AC-v2 and sources for OpenWrt from Open Mesh
December 21th 2016 - We’ve found out, that it’s possible to overwrite the U-Boot stack with big enough file
December 22th 2016 - We’re able to jump into the custom RAM loadable U-Boot sent as fwupgrade.cfg
December 30th 2016 - First version of working U-Boot exploit was tested
January 2017 - Polishing of the sources, writing documentation and preparation for public release
February 14th 2017 - Valentine’s Day, public release :-)
October 7th 2017 - Uploaded U-Boot sources for om2pv2 om2p-hsv2 mr900 mr900v2 om5p-acv2 om5p-an mr1750 a40 a60 devices
February 15th 2017
Open Mesh representativelink as Simon is not Open Mesh representative, he has to only use @open-mesh.com email for contributions related to Open Mesh products
removed wrong claim about the GPL copyright infringement of Open Mesh because it’s not true, we got all the sources as requested from Open Mesh support in December 2016, we just didn’t get the accurate information about the contents of every tarball
- corrected the
December 19th 2016on the timeline to reflect this new information
- corrected the
October 10th 2017
- added to the timeline information about upload of U-Boot source code for 9 Open Mesh devices