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.

TL;DR

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

Hardware pron

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:

Background

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:

  1. 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 representative 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 GPL license infringement.

We’ve asked Open Mesh in November 2016 for 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, openwrt.tar.gz, 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 instructions for 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?

Conclusion

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!

Timeline

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 Mesh

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

Changelog

February 15th 2017

October 10th 2017