Not working on U-Boot 2017.07-RELEASE-g78ed34f31579 (Sep 29 2017 - 07:43:44 -0700)

[0xFelix]

Seems like Cisco blocks the old method of getting a serial prompt in this uboot version?

The ubootwrite.py script is sending xyzzy, but no prompt appears.

Maybe CONFIG_AUTOBOOT_STOP_STR was changed?

Where can one obtain the latest GPL sources of Meraki's uboot?

[0xFelix]

Update:

I tried pressing space instead on boot...
Resulted in the device saying:

Secure boot NOT enabled! Blowing fuses... Resetting now.

It is dead now, won't boot and the orange LED stays lit.

Maybe Cisco is not so keen on replacing this device's firmware afterall.

[Ordspilleren]

Looks like this is now reflected in the flashing documentation in Google Drive. Is there any chance this will be solved, and is there something we can do to help?

[riptidewave93]

@Ordspilleren best thing to do at this point is to request the latest u-boot GPL source from Meraki. This should hopefully show us what Blowing fuses... Resetting now. actually does to the device.

[Ordspilleren]

I got the U-boot source from Meraki. From at quick look at the code, the whole Blowing fuses... Resetting now. ordeal seems to be related to the Qualcomm QFPROM. I am not qualified enough to figure out much more, or the solution for that matter.
Here's a link for the source: https://drive.google.com/file/d/1fIs0rZI2a6UOqal6JS4nxI-Ld4co0O_B/view

[argentdeux]

My Meraki licence expires this year, I wait hopeful that the 2017.07 version of U-Boot is able to be flashed before then! Unfortunately this is beyond my ability.

[Flole998]

Looks like what you're doing there is enabling secureboot. xyzzy should still work (with secureboot disabled) though, at least it seems like that in the code/config, I only had a brief look at the source though.

Some fuses are write once and can never be deactivated (at least not in software), I don't know if that fuse is one of those.

[0xFelix]

In the 20170427 u-boot sources the file include/configs/ipq40xx_cdp.h contains CONFIG_AUTOBOOT_STOP_STR set to xyzzy and in the newer u-boot sources of @Ordspilleren CONFIG_AUTOBOOT_STOP_STR is completely absent. So I guess they disabled it on purpose.

Instead the newer ipq40xx_cdp.h file defines new u-boot commands including boot_meraki_qca. This function forces secure boot and also "blew" the fuse on my device. (Looking at the code this should make no difference and it should already have been blown on my device, maybe for devices upgrading from older u-boot versions?) Devices with 20170427 u-boot seemingly do not use secure boot and are therefore able to run arbitrary code while devices with the newer u-boot only run signed code?

[Richy78]

any news on the issue? I'm stuck on"uploading image" no prompt...

[Flole998]

If it's really an efuse then you blow it once and that's it, no way to recover.

What you can always do when secureboot is inactive is desolder the flash and replace the uboot.

[ajkenah]

I found this document on Secure boot :https://www.qualcomm.com/media/documents/files/secure-boot-and-image-authentication-technical-overview.pdf
Looks like secure boot has a efuse location for a root certificate hash to validate boot images. When you fail to boot a secure image it blows the fuses with the root cert.. or thats how i read the above.
Not sure if Cisco even uses it though as it seems to mention that you can store certificates in ROM as well.

[ajkenah]

Has anyone managed to JTAG the MR33? I've got a couple of fresh ones and I would like to backup the firmware so that I can "roll-back" the Meraki bootloader later when it gets updated.. I suspect that the pinout is the 10x2 holes on the side, but I'm getting weird readings on my multi-meter and the traces don't seem to line up whats specified in the standard ARM 20-pin JTAG Layout...

[satis4action]

Guys, any news?
My version is: U-Boot 2017.07-RELEASE-g78ed34f31579 (Sep 29 2017 - 07:43:44 -0700)

[Flole998]

What did you do so far? Already pressed space and seen Secure boot NOT enabled! Blowing fuses... Resetting now.? In that case its already bricked, most likely forever. If you havent seen that yet the easiest way is most likely to replace uboot.

[shanehull]

any news on the issue? I'm stuck on"uploading image" no prompt...

Did you work this out?

I have the same issue. Verbose mode gives me "Waiting for prompt.." then nothing.

I've tried setting the baud rate, data bits and stop bit, but still nothing. Have verified that I have a working serial connection in/out.

[ajkenah]

I never got this working. I blew two rasperryPi's and then the AP itself trying to JTAG in and dump the memory so that I could flash it back if necessacary... Not that it means it doesn't work, jus tthat im not very good at soldering and double checking cable pinouts :(

[owenashurst]

Any update on this?

[Flole998]

The method I mentioned above still works. Desolder flash, replace uboot, solder it on again.

[owenashurst]

The method I mentioned above still works. Desolder flash, replace uboot, solder it on again.

@Flole998 are there any instructions on this? I've never flashed a NAND flash chip before, removing it should be ok, I have a heat gun but only really done this many years ago. Also, is it the chip under the tape?

[Flole998]

There are datasheets available that tell you everything you need to know about that flash. The basic steps are dump, seperate OOB/ECC, modify, calculate new ECC and write back.

What might work aswell is to short the flash when uboot tries to load the kernel, depending on it's configuration it might fall back to a console.

[kitor]

Was this tested anywhere?

As I'm not familiar with how wear leveling, etc works. But I have two MR33 - one running OpenWRT, one on stock software (fortunately still 2y of license to wait for any developments).

I thought about booting modded one into initrd and then hot-swapping flash and reflashing it from linux - would this work? (let's skip physical part of swapping flash in the answer)

If I understand correctly, in this kind of environment software (uboot/linux kernel) is responsible for all the leveling/ecc stuff, not memory controller like on flash drives?

[Flole998]

Actually I've done it before, it's been quite some time ago though. I'm not sure if someone else has done it or if this is documented somewhere.

I've heard of hot-swapping flash causing a brick before, however that was on a different device.

What could work is cloning the other NAND if you don't want to do the modifications manually, if it contains calibration data though that would need to be written back afterwards.

[owenashurst]

The thing is, I've waited until the boot process finishes and I accidentally tried to exit out of screen using CTRL+C, and this gave me a Meraki> prompt. Now I don't know at which step that it causes the fuse to blow. Is it once it reboots with the uploaded openwrt u-boot and realises it's not signed or something? Because I've replicated what I've done on the same device over several reboots and I always get the prompt.

Also, I took a full back up when I successfully flashed another MR33 yesterday of MTD. Is this useful for the MR33 with the newer firmware?

[satis4action]

@Flole998
sorry to bothering you, can I use mr33-uboo.bin from this source? https://drive.google.com/drive/folders/1jJa8LzYnY830v3nBZdOgAk0YQK6OdbSS
address should be ?
0x000000700000-0x000000900000 : "u-boot"
or gerneric processes can be the same?

1.Create a full dump of the SPI Flash, and store it in a safe place
2.Erase and Clear 0x0-0x3ffff on the SPI Flash
3.Flash U-Boot to 0x0
4.Proceed to the OpenWRT Install Procedure

referrer : https://openwrt.org/toh/aruba/aruba_ap-105

[Flole998]

The basic process is the same, yes. Just that this is not a SPI Flash and the address is obviously different. But dumping, replacing and writing back are the correct steps, just that in this case I desoldered the Flash because I don't want the CPU to interfere with my programming operation.

[owenashurst]

If you observe the boot process when you're connected via UART, it will tell you

…

On Wed, 15 Jan 2020, 12:27 Richard L. Alhama, ***@***.***> wrote: hi how would you determine the uboot version without running ubootwrite.py? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#13?email_source=notifications&email_token=ABBTB3CX4PL2IUH65CHMJO3Q536KTA5CNFSM4GMEISR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJAEQDI#issuecomment-574638093>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABBTB3CBZO2SKL2HZVVJC5LQ536KTANCNFSM4GMEISRQ> .

[satis4action]

connect terminal to uart port and you must see on the begining of the boot process, like this

"U-Boot 2012.07-g97ab7f1 [local,local] (Oct 06 2016 - 13:07:25)"
...

[kechie]

If you observe the boot process when you're connected via UART, it will tell you
…
On Wed, 15 Jan 2020, 12:27 Richard L. Alhama, @.***> wrote: hi how would you determine

I have U-Boot 2017.07-RELEASE-g78ed34f31579 (Sep 29 2017). Guess I have to hone my soldering skills then.

Thanks

[cryptage21]

Hi guys,

Is there a way to know the bootloader version (without opening) by booting the MR33 and checking firmware version by example ?

Thanks

[urbaniak]

I've tried even unsoldering the flash chip, but without success - looks like it's glued and then soldered.

So the only idea I've got is clamp on tsop-48 (https://www.aliexpress.com/item/32838230005.html?spm=a2g0s.9042311.0.0.27424c4dsE1VcC) and then writing old uboot.

[Flole998]

If it's glued down and they didn't put too much glue on it you can just remove it with a heatgun.

The problem with those clamps is that the CPU must be held in reset and the pins for the flash must not be pulled in either direction (low or high), otherwise the CPU will interfere and you will get weird results.

[Leo-PL]

It is strictly the kernel size, not just the rest of image.

[Flole998]

I did reduce the kernel size, i believe i removed USB support and also emmc support.

[Leo-PL]

By any chance, do you have any boot log of such image? My devices froze right after "Starting kernel", showing no further activity.

Regardless of the cause, the issue is still there - I believe the images should be disabled until the root cause is at least known.

[Flole998]

I'm seeing exactly the same thing, no further output.

[Leo-PL]

Could you do tar tvf on your shrinkened sysupgrade image?
I can try to start analyzing the issue with more depth after the weekend - I need my units working until then.

[Flole998]

I no longer have those images, I've deleted them since I considered them broken

[sijans]

What do you think is the limit for the kernel size?
I'm currently running an image with 4221132 bytes kernel size, even a snapshot release with 4442372 bytes was working fine a few weeks ago. But I had the issue with a 4200157 bytes kernel.

[Flole998]

That's basically consistent with what I was seeing, some builds were working, others weren't, the size doesn't seem to matter.

[Leo-PL]

@sijans do you know from which lines were the working and non-working kernels? i.e. 5.10 or 5.15? Maybe there is a regression blocking boot.

[sijans]

Both 5.15. 5.15.111 was not working, 5.15.113 boots fine, but I need to check what is installed currently. Maybe even a newer version. Edit: It's a gluon build with 5.15.111 that runs fine again.

[Leo-PL]

Now I wonder how to use the Meraki's dual boot scheme with OpenWrt, to get some kind of recovery in case the boot fail. I'd be grateful for any documentation. Going to dig through U-boot sources to get some information on that, because debricking the unit is royal PITA.
Edit; Just checked the GPL dump for 2021.07 release and it has no fall-back mechanism present - just as if this all was an afterthought. Though, analyzing default U-boot environment from the binary itself may help.

[sijans]

@Leo-PL You need access to the serial console and have an initramfs image in the second partition "part.old".

If you enter
STINKBUG # run set_ubi
STINKBUG # run bootkernel2
you can boot the second partition and then write a new image to the first partition with sysupgrade.

Default boot command is meraki_boot=run set_ubi; run bootkernel1; run bootkernel2, I think it will only fallback if bootkernel1 is really corrupt and not freezing.

[Leo-PL]

I made some progress investigating the booting issue here: openwrt/openwrt#12953
TL;DR the build system seems non-deterministic, I was able to get booting and non-booting images on the same commit, with minor differences inside the kernel binary, after unpacking. I can upload the images somewhere, for further analysis. I need to compare expanded kernel configurations before going with Ghidra.

[halmartin]

I had to flash an MR33 recently, and since python2 is no longer packaged for many distributions, I migrated ubootwrite.py to python3.

Fork is here: https://github.com/halmartin/mr33-openwrt-flash

Tested on Arch Linux with python 3.11.5, no warranty provided 😄

[asleepynerd]

Does anyone have a 2017 uboot dump? I want to look into a file and see whether i can find anything that can be exploited into writing, or at least getting shell access without bricking the board.

[halmartin]

Does anyone have a 2017 uboot dump? I want to look into a file and see whether i can find anything that can be exploited into writing, or at least getting shell access without bricking the board.

You don't need a dump, the source code for 2017.07 is available.

You can find the function that enables secure boot, bricking the device, right here: https://github.com/riptidewave93/meraki-uboot/blob/mr33-20190225/board/qca/arm/common/meraki_rel_boot.c#L107-L135

You can dig through the u-boot source code for vulns, but I hope you have a large stack of devices you don't mind bricking if you plan to test it...

[rileyg98]

Maybe I'm being naive, but wouldn't Josh be able to patch the fuse burn out of a u-boot build, load it with a NAND clip, and then be able to test possible vulns against this 'neutered' build? I know it's not ideal, but it's better than bricking boards en-masse.

…

On Sun, Apr 21, 2024 at 6:44 AM Hal Martin ***@***.***> wrote: Does anyone have a 2017 uboot dump? I want to look into a file and see whether i can find anything that can be exploited into writing, or at least getting shell access without bricking the board. You don't need a dump, the source code for 2017.07 is available. You can find the function that bricks the device right here: https://github.com/riptidewave93/meraki-uboot/blob/mr33-20190225/board/qca/arm/common/meraki_rel_boot.c#L107-L135 You can dig through the u-boot source code for vulns, but I hope you have a large stack of devices you don't mind bricking if you plan to test it... — Reply to this email directly, view it on GitHub <#13 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACSLB44S63JABWYRHPHUVA3Y6LHS3AVCNFSM4GMEISR2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBWG43TONZRGU3Q> . You are receiving this because you commented.Message ID: ***@***.***>

[halmartin]

If anyone still has an MR33 which had the fuses blown, and you have a NAND programmer, please get in touch.

I recently came into possession of the signed u-boot for insect and would like a device to test it on, especially as it has the same secure boot bypass the Z3 does 😄

[Leo-PL]

It turned out, that I destroyed the chip from fused unit from Felix in the process of trying to reball it 5 times, so I'll have to try with my spare IPQ4019 desoldered from different unit. @kosma helped me out to resolder the replacement chip, but it didn't even start booting - I replaced the NAND contents back to stock MR33 for the test. I suspect some kind of another hardware failure - worst case, I still have one more IPQ4019 to try - I'm willing to fuse it for the cause.

[Leo-PL]

Also @DariuszJJ still have that fused unit? I might need another one to test image from @halmartin if I don't get mine back up running, because that's just a matter of rewriting NAND.

[ziswiler]

BTW: I would have like half a dozen of such units just lying around if anybody needs any. They could be had for just the shipping fee. I even still have the clip-on NAND programmer. I moved on to Wi-Fi 6E equipment: a few Acer Predator Connect W6 and Verizon CR1000A units (;-p).

[Leo-PL]

But... these are still working units?
In which country do you live? :-D
Edit: nevermind, postage from Switzerland to Poland shouldn't be extra expensive ;-]

[ziswiler]

But... these are still working units?

Yes, of course, they worked fine for me for many years.

In which country do you live? :-D
Edit: nevermind, postage from Switzerland to Poland shouldn't be extra expensive ;-]

Not sure what is expensive for you but one piece could probably be shipped for as little as EUR 15. Plus maybe there are also other ways to pass them on towards Poland (;-p).

[Leo-PL]

EUR 15 is still way less than the "360 clip" itself - OTOH it feels wasteful to purposefully brick a fully working unit for such experiment. Let's wait a little while to see if something bricked shows up - I'll have that offer in the back of my head ;-]

As for other ways - yeah, I know a guy from Zurich, but I'm not sure if it's worth to bother him for 15EUR.

[Leo-PL]

@ziswiler by any chance, are you going to 38C3? I'm thinking about buying the MR33s from you and putting them to use in and around my local hackerspace.

[DariuszJJ]

Also @DariuszJJ still have that fused unit? I might need another one to test image from @halmartin if I don't get mine back up running, because that's just a matter of rewriting NAND.

I ask my friend from Łódź and i think still have one with blowed fuses

[ziswiler]

@ziswiler by any chance, are you going to 38C3? I'm thinking about buying the MR33s from you and putting them to use in and around my local hackerspace.

@Leo-PL No, sorry. But I will be speaking at FOSDEM 2025 in Brussels Feb 1+2.

[Leo-PL]

@Leo-PL No, sorry. But I will be speaking at FOSDEM 2025 in Brussels Feb 1+2.

That's a great reason to finally come to FOSDEM, then!

I ask my friend from Łódź and i think still have one with blowed fuses

Great, I'm waiting eagerly for the reply. I'll cover the shipping as well.

[Leo-PL]

@ziswiler I likely won't make it to the FOSDEM, but a friend will do, so he can pick the stuff up for me. Please contact me via email (searchable in OpenWrt's repository). How much would you like for those MR33's and the clip?