Meraki Z3 Support

There is some documentation in the famous deoptim's repository, but this is unlikely to help you. Qualcomm's SB3.0 hasn't been exploited so far, what you can do is look for bugs further in the boot chain, like one that was found (and not tested so far) in Z3. Pin you're referring to is boot_config0 which refers to application code segment, not the boot chain - and IIRC if this configuration is fused, the fused configuration takes precedence.

Don't know it, could you share it?

If you are very, very lucky, it may behave similarly as ipq807x - using atf=1 to circumvent the secure boot check.

That's hot!
I was on a lookout for them on local auction sites, but haven't picked one up yet, prices were quite high. Now it's worth way more :smiley:
What is the way you forced it to boot OpenWrt?

Exactly as described previously. Change the device major in EEPROM, replace on flash with a modified u-boot build packaged as a FIT image:

Format: Log Type - Time(microsec) - Message - Optional Info
Log Type: B - Since Boot(Power On Reset),  D - Delta,  S - Statistic
S - Boot Config, 0x00000025
S - Core 0 Frequency, 0 MHz
B -       261 - PBL, Start
B -      1340 - bootable_media_detect_entry, Start
B -      2615 - bootable_media_detect_success, Start
B -      2629 - elf_loader_entry, Start
B -      7270 - auth_hash_seg_entry, Start
B -   1382352 - auth_hash_seg_exit, Start
B -   1447639 - elf_segs_hash_verify_entry, Start
B -   1569353 - PBL, End
B -   1569377 - SBL1, Start
B -   1658051 - pm_device_init, Start
D -         6 - pm_device_init, Delta
B -   1659570 - boot_flash_init, Start
D -     87594 - boot_flash_init, Delta
B -   1751205 - boot_config_data_table_init, Start
D -     14010 - boot_config_data_table_init, Delta - (419 Bytes)
B -   1767914 - clock_init, Start
D -      7572 - clock_init, Delta
B -   1778887 - CDT version:2,Platform ID:8,Major ID:1,Minor ID:0,Subtype:1
B -   1782376 - sbl1_ddr_set_params, Start
B -   1787361 - cpr_init, Start
D -         2 - cpr_init, Delta
B -   1791851 - Pre_DDR_clock_init, Start
D -         5 - Pre_DDR_clock_init, Delta
D -     13143 - sbl1_ddr_set_params, Delta
B -   1805130 - pm_driver_init, Start
D -         2 - pm_driver_init, Delta
B -   1876340 - sbl1_wait_for_ddr_training, Start
D -        27 - sbl1_wait_for_ddr_training, Delta
B -   1893870 - Image Load, Start
D -   1312117 - QSEE Image Loaded, Delta - (268504 Bytes)
B -   3206486 - Image Load, Start
D -      2118 - SEC Image Loaded, Delta - (2048 Bytes)
B -   3216578 - Image Load, Start
D -   1308369 - APPSBL Image Loaded, Delta - (292616 Bytes)
B -   4525372 - QSEE Execution, Start
D -        56 - QSEE Execution, Delta
B -   4531549 - SBL1, End
D -   2964253 - SBL1, Delta
S - Flash Throughput, 1969 KB/s  (563587 Bytes,  286154 us)
S - DDR Frequency, 672 MHz

U-Boot 2017.07-RELEASE-g39cabb9bf3 (May 24 2018 - 14:07:32 -0700)

DRAM:  242 MiB
machid : 0x8010001
Product: meraki_Stinkbug
NAND:  ONFI device found
ID = 1d80f101
Vendor = 1
Device = f1
128 MiB
Using default environment

In:    serial
Out:   serial
Err:   serial
machid: 8010001
ubi0: attaching mtd1
ubi0: scanning is finished
ubi0: attached mtd1 (name "mtd=0", size 112 MiB)
ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
ubi0: good PEBs: 896, bad PEBs: 0, corrupted PEBs: 0
ubi0: user volume: 5, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 214/99, WL threshold: 4096, image sequence number: 2086049366
ubi0: available PEBs: 0, total reserved PEBs: 896, PEBs reserved for bad PEB handling: 20
Read 0 bytes from volume to 84000000
No size specified -> Using max size (507904)
## Loading kernel from FIT Image at 84000000 ...
   Using 'config@1' configuration
   Trying 'kernel-1' kernel subimage
     Description:  Kernel
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x840000d0
     Data Size:    381216 Bytes = 372.3 KiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x87300000
     Entry Point:  0x87300000
     Hash algo:    sha1
     Hash value:   89c319b76738e71147631f87311fc8f31e8ac8aa
   Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at 84000000 ...
   Using 'config@1' configuration
   Trying 'fdt-1' fdt subimage
     Description:  Insect DTB
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x8405d2d4
     Data Size:    235 Bytes = 235 Bytes
     Architecture: ARM
     Hash algo:    sha1
     Hash value:   86c47255d86f2bd6301e7772ca65b3548493875b
   Verifying Hash Integrity ... sha1+ OK
   Booting using the fdt blob at 0x8405d2d4
   Loading Kernel Image ... OK
   Using Device Tree in place at 8405d2d4, end 840603be
Using machid 0x8010001 from environment

Starting kernel ...

U-Boot 2017.07-DEVEL (Apr 01 2024 - 14:50:01 +0000)

DRAM:  242 MiB
machid : 0x8010001
NAND:  ONFI device found
ID = 1d80f101
Vendor = 1
Device = f1
128 MiB
Using default environment

In:    serial
Out:   serial
Err:   serial
machid: 8010001
Net:   MAC0 addr:e0:cb:bc:11:22:33
PHY ID1: 0x4d
PHY ID2: 0xd0b1
ipq40xx_ess_sw_init done
Autoboot in 5 seconds

In this case, it was that easy. But I am sure Meraki won't make the same mistake twice, so this kind of exploit is only possible for select ipq40xx devices.

Flashing is "pretty easy," you just dump+modify EEPROM, overwrite everything on NAND past 0xc00000 with a dump containing the new u-boot built in a ubivol, tftpboot initramfs and sysupgrade.

Not sure how OpenWrt will feel about adding support since it requires directly flashing both I2C EEPROM and TSOP48 NAND. It also means most users won't be able to flash OpenWrt since it requires a significant investment in hardware flashing tools or very good soldering skills.

I don't think Meraki can patch this, since the QFPROM fuses are blown with their cert and I don't think the SoC has rollback protection. However, this is speculation and I may be wrong.

I will make a PR for support and write documentation soon™.

I'm optimistic about this. We have clips available both for the I2C EEPROM, and this is relatively safe operation, and with used MR33's we have to deal with the same issues as here - so not much changes, really.

Also, since we now know how to chainload U-boot, maybe finally it'll be possible to provide web recovery, as done on GL-iNet devices.

BTW, which power supply is used for Z3? I'm trying to organize some units, but the cheaply-available ones are sans PSU - and IIRC the connector isn't a typical 5,5/2.1mm barrel jack. And genuine Cisco adapters for that cost as much as the device itself.

The original PSU is MA-PWR-50WAC.
Output: 54V 0.92A (centre positive)
Barrel dimensions are approximately 6.3x3.0mm

Blog post with details on how the secure boot bypass works:

BTW, this is also applicable to the Meraki Go GX20 since they are largely the same device (GX20 lacks WiFi radios):