Mikrotik RouterOS v7.x and OpenWrt sysupgrade

There actually is a magic value like for LZOR, after you get the dump there is LZ77 is ASCII

Hi John,

This is my factory hard_config for the Chateau 12(LZ77):

I never used a decompiler, so it might be more efficient if you can take a look at it :wink:

MOD: I upgraded my device to ROS7.7/routerboot7.7 and John's method still works: I can boot initramfs then sysupgrade to Openwrt.

1 Like

I wonder if anyone has other RoS7 only devices, it would be interesting to see how widespread this LZ77 issue is. @robimarko do you happen to have any such devices? Even if it is ipq60xx, it might worth to take a look at them. I have a feeling that this is going to be widespread....

@johnth I tried to look at this and I can see that the current LZOR method uses the in-kenrel functions. As much as I understand LZ77 is LZ2, but I am not sure if LZ4 is compatible or if it can be used with the LZ4.h methods. If not, then there is the problem of external dependencies like zlib in order to do the decompress.

you probably know this but just in case.
was experimenting a bit with a board from a Mtik SXTsq 5 ac that I had bricked and opened. Accessing NOR with a SOP8 clip and programmer.
To restore a working ROS unit two things that are unique to the device are needed: the mtd1 partition and the license file. Apart from the bootloaders and its three config data internal mtds, mtd1 contains a header before the first bootloader with a.o. serial number and mac address, and a string near 0x20000 from dtb1 start that probably relates to the license. That string remains unaltered when bootloader version changes. mtd0 also needs to be there but is not unique to the device and common for the ipq40xx devices I could test (hAPac2, SXTsq 5ac, LHG 5 ac).

I was wondering whether it would be possible to install OpenWrt by just abandoning the entire Mtik boot process after backup of the first 1 MB of flash (mtd0 & 1), and install e.g. uboot in mtd0, followed by kernel and rootfs in mtd5. Essentially mtd1,2,3,4 would remain untouched, with hard_config and soft_config used by OpenWrt.
Could mtd0, pretty useless for OpenWrt anyway, with its 524288 bytes fit a bootloader that would allow tftp and bootp to still function? Returning to ROS would imply putting back mtd0, and using MTik's netinstall.
With an open source bootloader we would not have to spend time on anything MTik engineers are changing in the boot process.
Only worry would be changes in the hard_config and soft_config format

I dont have any ROSv7 only devices currently, not really keen on getting ipq60xx ones are they are overpriced.

But you are right that they are gonna move to LZ77 only, and I dont think that kernel provides a way to decompress LZ77 currently

1 Like

Two things:

  1. As much as I understand, we have no issues with booting and installing Openwrt on factory bootloader since John's work seems to work. So replacing the bootloader has no good reason and in general we try to avoid that (unless it is not possible to get around it).

  2. No matter if you replace the bootloader, the hard_config extract method will be needed to get the BDF/Cal specific to the device.

yes, hard_config will be needed, but that would be all. No need to figure out other changes to RB. But it would only be a 'simple' fix when 512kB is enough for an alternative bootloader that offers basic functionality via ethernet. If not, the partitioning would have to be changed and compatibility with the original system would be lost.

I checked the RB_config part on my Chateau 12LTE, and it seems besides the compression change, the rest is intact. So at the moment the only issue is the LZ77 compression of the BDF. Of course with ipq60xx that can change, that is one of the reason I asked if someone can provide hard_configs of other ROS7-only devices :slight_smile:

I wonder if we can "patch" the current linux/lz4.h to provide support for LZ2/LZ77, as much as it seems LZ4 is a more complex version of LZ2, so maybe the diff is not that big. I would assume that adding external dependency (zlib fox example) to this process is the least favorable.