Cisco Meraki MX68W

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 (

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.


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.

Microsemi M2S005 FPGA = "Aikido" (合気道)

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.

Attacking "Aikido"

  • Here is a paper from 2017 discussing some methods of attack against platforms which implement Secure Boot using an FPGA. Note that it doesn't provide a proof-of-concept for our Microsemi FPGA, but it discusses that:

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

1 Like

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.