comparing the original mtd6 ("tplink") with the one with the 3.0.3 problem, I found
< 00030800: 0000 0010 0000 0000 736f 6674 5f76 6572 ........soft_ver
< 00030810: 3a33 2e30 2e33 0a00 0069 6c64 2032 3032 :3.0.3...ild 202
---
> 00030800: 0000 0051 0000 0000 736f 6674 5f76 6572 ...Q....soft_ver
> 00030810: 3a31 2e31 2e30 2042 7569 6c64 2032 3032 :1.1.0 Build 202
Unfortunately I have hit a roadblock, for some reason my Malta Debian-Mips VM is getting a exec format error while trying to chroot into stock firmware.
Perhaps @frollic could give it a shot straight on the device without having to go through all the virtualization jargen?
where did you get the binary ?
Never mind, I think I know why it failed ...
Use binwalk on the bin file inside the download, want me to send it here?
yes please, it would mean one less thing I need to do ...
Don't think you'll be able to fit it, why do you need the bin? You can use the crypto.lua already there.
Why was that?
https://files.catbox.moe/ouzzrc.gz
Here is the extracted squashfs which I have compressed to a tar.gz for easy sharing
Although, following the guide I linked above, you can use the crypto.lua already on your stock firmware to decrypt the backup, enable ssh and renecrypt it.
This is mtd6 from OpenWrt, I assume? If you modified those bytes with "3.0.3" to contain "1.1.0" before converting back to stock, you should have the correct version number again when running stock.
Once you have confirmed that you can properly revert after fixing the version number, you could try other version numbers to see what the firmware checks for to verify it can support the features broken with "3.0.3". Does "1.1.9" work? What about "1.9.9"? We could update the safeloader tool to have a higher version than the latest available stock, while still maintaining the option to go back and use the original FW with full functionality.
Note that going from stock to OpenWrt with "1.1.9" and back to stock would be a thing a user can only do once! As soon as stock thinks it is already at version 1.1.9, I don't think it will let you upgrade to OpenWrt again.
The 3.0.3 is post revert to stock.
That was my plan, but I need to figure out how to dd the 11 bytes of data
correctly to /dev/mtd6, seek= doesn't seem to be enough, since it appears
to cut off the rest of the file (I tried it on a mtd6 dump file).
Since I discovered it the hard way, I also need to figure out (the syntax) how to mtd write the old dump back 
You will need both seek= and conv=notrunc
You can write back the modified dump with mtd. Is this helpful? https://openwrt.org/docs/techref/mtd
Could someone help me understand this?
Openwrt is at 23.5, won't it always be higher than whatever number we set it as?
Edit - Do you mean that we will "change" the openwrt version to 1.1.9 for this device?
The OpenWrt release number is indeed 23.05 (or whatever future version), but that's not the version that is reported to the stock firmware in the OpenWrt factory image.
TP-Link has a bit of flash storage carved out to store release info: a version number, a build date, a build number. Any images provided for upgrading the device (vendor or OpenWrt) must also contain this bit of data with release info.
On upgrade, the stock FW will replace the stored version info with the one from the upgrade image.
OpenWrt factory images currently pretend to be a TP-Link image with version 3.0.3. It could pretend to be any version, such as 1.1.9 or 0.1.2, but the firmware apparently refuses to install images with lower version numbers.
The "3.0.3 problem" arises because because OpenWrt doesn't otherwise care or know about this bit of release info. When reverting from OpenWrt back to stock, only the 'runtime data' is installed again, but the release info is left untouched. So that's how you end up with a firmware expecting to be v1.y.z, but seeing 3.0.3 stored in its release info.
Right got it.
While installing openwrt i am assuming this bit gets checked again, but since with a patch it will be lets say 1.1.9, I have reverted once, so its 1.1.9 and on trying to install openwrt again it will fail because the part which checks for the versions says that both images are the same, is that right?
Would users be able to look at the patch, incrementally change it to whatever highest version we find that doesnt have anything broken?
Edit - Q2, Can we not do what was suggested a little up, that we change the version to let's say 1.0.0 while on openwrt with ssh access, install stock, then if need be we can reinstall openwrt.
They do not pretend to be 3.0.3
It's read as 23.05.3 when you flash back to stock.
I've yet to read of anyone who has flashed from master SNAPSHOT to Stock firmware, and the number in brackets differs on different ax23s.
Ok, it seems to have worked...
Creating the text file vers.ion, and writing it to mtd6
root@OpenWrt:/tmp# cat vers.ion
1.1.0 Build
root@OpenWrt:/tmp# dd if=vers.ion of=/dev/mtd6 seek=198673 count=11 bs=1 conv=notrunc
The TP-Link firmware said it's version was 1.0.0 (4555) (sorry forgot to make a screen shot), when I booted what previously claimed to be 3.0.3.
When I clicked the "Check for Updates" button, it said it was up to date, but
it'd still let me flash the most recent EU fw available from TP-Link.
now I'm back at
root@OpenWrt:/tmp# dd of=/tmp/a if=/dev/mtd6 skip=198673 count=11 bs=1
11+0 records in
11+0 records out
root@OpenWrt:/tmp# cat /tmp/a
1.1.0 Build
root@OpenWrt:/tmp#
Nice!
We just need to figure out uptill what version does everything work.
Currently, reset, easy mesh and speed control(whatever that is) should be broken.
Would need to check if the last digit is checked for those features, 2nd last or the first one.
Edit - You ran this while using openwrt? This could be a good revert procedure without the catch the dev mentioned above, right?
I'm not entirely sure how the version is read, keep in mind I wrote 1.1.0 to the mtd, but it came out as 1.0.0 in the stock fw.
I did if from an initramfs, but I see no reason why it wouldn't work from within vanilla openwrt.
You'll however need to install kmod-mtd-rw 1st, then insmod it.
root@OpenWrt:/tmp# insmod mtd-rw.ko i_want_a_brick=1
This applies to the initramfs too.
Roger.
Could you perhaps give it a go with sysupgrade file of stock? Initramfs should be the same information functionality but I have 0 idea how openwrt and embedded devices work...
Edit- Do the US and the EU versions have similar flash layouts aswell? I know it says identical on the wiki, is that hardware wise?