ah, i see. if we just need to get the bootloader to think mtd10 is invalid to force a boot to mtd9, have we tried just mtd erase /dev/mtd10 from exploit shell? then next boot would be from mtd9, from which we can do the ubiformat on mtd10 (no detach necessary since its attached to mtd9)
It did not go that far with chosen:
[ 2.035848] ubi0: background thread "ubi_bgt0d" started, PID 92
[ 2.037097] block ubiblock0_1: created from ubi0:1(rootfs)ý[ 2.057523] UBIFS (ubi0:1): read-only UBI device
[ 2.057598] UBIFS error (ubi0:1 pid 1): ubifs_mount: cannot mount read-write - read-only media
[ 2.061664] mtdblock: MTD device 'rootfs_1' is NAND, please consider using UBI block devices instead.
[ 2.070184] List of all partitions:
i think you were right with your own earlier suggestion that you need to not mark it read-only in dts. how about removing that 'read-only' flag from the partition the dts calls 'partition@3600000 { //10'
if not that, then show full boot log (i made a couple late-edits to different bootarg suggestions and its not obvious from snippet which one you went with)
EDIT TO ADD: oh, im guessing you caught my earlier typo'd version when i had said /dev/mtdblock10 instead of /dev/ubiblock0_1 (cause i copied it from a NOR device with a seperate rootfs mtd partition). see current bootarg guesses above after my edits
This error is with /dev/mtdblock10
Looking at your edits.. shouldn't it be(rootfs_1(mtd10) instead of rootfs(mtd9)):
chosen {
bootargs-append = " root=mtd:rootfs_1";
};
?
no, the mtd name is rootfs_1 (mtd10), but to that mtd we wrote a combined ubi image with three subimages, a kernel (which bootloader finds because we boot it!), a read-only rootfs and a read-write (empty) rootfs_data (its the writeable overlay to the rootfs)
$ ubireader_display_info openwrt-ipq40xx-generic-tplink_deco-m9plus-v2-squashfs-factory.ubi | grep "name:"
name: 'kernel'
name: 'rootfs'
name: 'rootfs_data'
i believe it is the subimage name that we need to specify here, so to correct the bootloaders hardcoded kernel arguements of ubi.mtd=rootfs_1 root=mtd:ubi_rootfs rootfstype=squashfs rootwait, we need to provide the correct subimage name of what openwrt builds which is 'rootfs'. so root=mtd:rootfs (dropping the ubi_ prefix which is what the stock subimage is named)
our 'chosen' arguments will be appended to the kernel arguments (can be verified as its echo'd in first few lines of bootlog) and if all goes well our (second) root=mtd:rootfs arg will override the first root=mtd:ubi_rootfs arg and all will be well
Thanks for the info. I just flashed using /dev/ubiblock0_1 and it seems to have worked. I have rebooted thrice and it always boots openwrt kernel and I see luci.
easy as that 
Is that the end of it?
Should I desolder the wires ? and put it back in the casing ? I am always worried that I am going break the wifi hardware based on how it's been sitting and get beatings from other stuff on my table.
Also If now I build another image can I do a sysupgrade ? where will that write the firmware ? mtd9 or 10 ?
did you do the flashing without hardwire uart intervention from the exploit shell (mtd erase mtd10, reboot into mtd9, ubiformat mtd10) or with hardware uart intervention from uboot (boot initramfs, ubiformat)?
I have not desoldered anything. I think your hardware might be different then.
With uart.
Thanks. I'll need to redo your v2 work now onto v1 - and when that's done I'll look at the one v2 device I have and see how come they seemingly don't have an SPI flash on that revision.
Great work from you and naf getting up and running!
edit: I've screwed up the v1 I have been working on, but I don't know how. It boots from mtd9 and fails to get working IP. If I ping it during boot with ethernet connected I get 1-3 replies and then nothing. No idea what has happened, I'll reflash my SPI backup tomorrow and continue probing. It might be I actually managed to kill something since it's been running without proper cooling for quite a while.
1 Like
i would recommend to leave the uart on until you have a non-hardware method perfected (on behalf of all the fat-fingered bad-soldering folks out there, myself included most of the time)
I guess now I have to then load initramfs and erase mtd10 and then let tp link boot to mtd9 and try your exploit and then try the:
ubiformat /dev/mtd10 -y -f openwrt.ubi
reboot and see if that works too ?
yes i think since we have seen that the bootloader's failover works (on accident), that should be a relatively safe way to do it
EDIT TO ADD: certainly if anyone can think of a smarter way to ubiformat the current mounted ubi rootfs, or if we should just mtd write it instead, im all ears
Also I think one more thing that needs to be done is do something that assigns lan port an ip address and makes sure it's up. Currently every time I have been using the uart to do:
ifconfig wan 192.168.0.1 netmask 255.255.255.0
/etc/init.d/firewall stop
/etc/init.d/dropbear start
/etc/init.d/uhttpd start
I have pushed whatever I have in case you want to take a look. It's nowhere near clean but it works.
1 Like
heres a slightly smarter way: it looks like you should be able to run fw_setenv tp_boot_idx 0 from the exploit shell to force the next boot to come from mtd9 (instead of mtd erasing mtd10 to do the same thing) and then in the mtd9-booted environment make sure to fw_setenv tp_boot_idx 1 to reset it after you ubiformat mtd10 with openwrt
either way if mtd9 is hosed you are gonna need uart to recover, but it seems alot classier to do it via command...
im still not positive we should give up on just figuring out how to overcome the ubidetach/ubiformat error when trying to write to mtd10 from a booted mtd10 though. did we ever see the dmesg for why access was denied?
Writing to mtd10 when booted from mtd10 seems just wrong to me. We could bork anything and get the system in an irrecoverable state. Like a process reads a size to write and the size is overwritten and it wipes something unintended.
It might work just like dd worked for backups but this just feels wrong to even try.
update: My M9 v1 is back in action after having restored the SPI flash. Seems I had borked Wifi from my exploit hunting (other things than naf's) and the failsafe boot didn't initialize any interfaces but lo 
My build issues with OpenWRT came from using clang instead of gcc, so I'm soon at the point where I will test to see how close the v2 work meshing has done is for the v1 as well.
Writing mtd10 after having booted from it clearly needs some sort of jump to exclusive processing from RAM. The trick with reverting to mtd9 for the next boot seems clever. I will look at it though.