Hi Guys,
I've recently decommissioned a Cisco Meraki MX68W and was hoping to see the state of Open-WRT for this device. I found this in reference to the MX60 (https://github.com/openwrt/openwrt/pull/3996)
Can anybody tell me if they know any more, for the MX68W specifically e.g. will an open-wrt build work? If not can i provide any info (as i have the device) to the community to help with the creation of an image or support for Open-WRT.
thanks
Hi, this is not a currently supported platform and from a quick search online there are no available specs.
This means there is no existing image and it's not possible to say if the platform is supportable. You will need to identify the SOC and all supporting components to begin building an image.
As you have the device you will need to do the image creation yourself. Start with a similar device if one exists.
The platform is Freescale's Layerscape ARM - I think LS1043. Secure Boot is enabled, but that hasn't stopped others in other situations.
I have an MX67. In FCC filings, the MX68W has much more stuff on it. @coliflower88, could you please tear down your board and give us some more detailed photos than those from the FCC release?
Other notes:
There's an FPGA on the MX6{7,8}{,W}, which it shares with the MS120. It looks like this is used to verify flash? This might be the way "in" to the platform, though it may also be why the platform will be difficult to defeat.
Here's a reddit thread examining this series.
The FPGA and its role on these boards are called "Aikido" by Cisco (not just Meraki). This FPGA ("SmartFusion2 Aikido Security Chip") is integral in securing the boot process.
You can read about Aikido on the MS120-8 -- "Kelpie" -- here.
You can compare Meraki's MS120 U-Boot with the u-boot-marvell release they forked from for details about what's changed; this'll include the implementation of Aikido.
You can read Microsemi's documentation on the use of this Microsemi FPGA for implementing Secure Boot.
You can read Microsemi's documentation on best-practices for the SmartFusion2 line of FPGA SoCs; it does discuss potential attacks.
You can read Microsemi's documentation about the "Tamper" tamper-detection core available on the M2S005. Perhaps they haven't configured the Tamper core.
You can read Microsemi's documentation about the JTAG interface present and available for these SmartFusion2 FPGA SoCs.
You can read this EmbeddedComputing article to better understand the role this Microsemi SmartFusion2 FPGA SoC has in securing the boot chain.
Microsemi on the contrary offers non-volatile FPGA SoCs, which means that the FPGA is ready to be used directly after power-up and there is no configuration of the FPGA from external memory as is the case with standard SRAM-based FPGA SoCs from Xilinx and Altera. Hence, the threat [posed by a compromise FPGA] is imminent from the very start of the system.
To summarize the above cases, whenever the FPGA is configured early during the boot sequence, and this is often the case, a secure boot process can be compromised by a malicious core in the FPGA ...
Hi, thanks for the responses - i've taken some internal shots of the board which might help the community. So what would the logical next steps be, to try similar access methods that were used on earlier models? Due to restrictions apparently I can only post 1 image per post, so will upload each one individually
It looks like this is used to verify flash? This might be the way "in" to the platform, though it may also be why the platform will be difficult to defeat.
On the MS120 series, the Microsemi FPGA is used to serve the DRAM training code to the SoC, as described in the README you find in the repository. This acts as an SPL after the SoC BootROM, and also verifies the signature of later bootloader stages (u-boot in this case).
If the secure boot fuses have been blown, then the only chance is to find a vulnerability in u-boot that allows you to execute your own payload, because everything up to that point in the boot chain is signed and validated.
I have yet to see a Meraki device that does not compile in the u-boot environment, so modifying that is out of the question.
