I’ve just realised that I should have done the atbt 1 and atsw from uboot and not from linux. I guess that explains why they did not work
I finally managed to get OpenWrt installed on a router running zyxel firmware even when mtk_uartboot is blocked and the firmware upload does not accept an image. It is based on the info from https://hack-gpon.org/zyxel/
Steps are as follows:
Interrupt uboot and issue the command atgu
When the router resets do the same thing a 2nd time and you should drop into a uboot command line.
Set the tftp server ip
MT7986> setenv serverip 192.168.1.254
tftpboot the openwrt-ubootmod-initramfs file and boot openwrt
MT7986> tftpboot openwrt.bin
MT7986> bootm 0x46000000
Now OpenWrt-ubootmod is running in memory and the rest of the steps are the same as the normal ubootmod install.
1 Like
which UK ISP was this ?
I don’t know. This router did not have any markings / stickers.
my bad, didn't catch the "unbranded".
Currently hacking a related Zyxel device and spent some time figuring out a couple of things which might interest EX5601-T0 users too:
a tool for creating zyfwinfo files. Yes, I realise that you have workarounds. But I wanted to keep the original bootloader, and I can't modify zloader on my device (FIT)
a tool for setting the EngDebugFlag using the Multiboot protocol. I.e. without knowing any password! After this you can read out the passwords using ATCK
These are unfinished hacks. You are warned.
Note that it should be possible to make zycast work too. But they have changed more than just the header size, and I haven't yet figured out all the bits. Don't want to fry anything I'd like to keep.
EDIT: Sample log when running zyeng eth1 on a directly connected Linux laptop (where "eth1" obviously is the ethernet interface on the laptop):
Loading Environment from UBI... Read 524288 bytes from volume u-boot-env to 000000007f77aa00
OK
In: serial@11000000
Out: serial@11000000
Err: serial@11000000
Net: mtk-eth ethernet@15110200: Firmware date code: 2024/10/30, version: 10.0
mtk-eth ethernet@15110200: Firmware loading/trigger ok.
eth0: ethernet@15110200
ZYXEL zloader v3.2.9 (11/17/2025 - 14:16:25)
Read 256 bytes from volume zyfwinfo to 000000007fa5ca10
ubi: Unable to retrieve the data size of kernel & rootfs.
Current bootflag is 0
Multiboot clinent version: 2.9
ethernet@15110200 Waiting for PHY auto negotiation to complete....... done
Hit any key to stop autoboot: 1
Multiboot server is available for download firmware image!
Be patient, it should be finish in 12 minutes...
No file need to download, stop multiboot service!
Update conuntry code!
'spi-nand0' is now active device
Reading from 0x180000 to 0x1bffff, size 0x40000 ...
Succeeded
Saving Environment to UBI... UBI partition 'ubi' already selected
done
OK
Update engineer debug flag!
Reading from 0x180000 to 0x1bffff, size 0x40000 ...
Succeeded
Saving Environment to UBI... UBI partition 'ubi' already selected
done
OK
I believe this might work on the EX5601-T0 too, but I have no device for testing. But if it works, then that's a single udp packet replacing all the web gui javascript hacking. And even better: It would work even when all local management is disabled.
Note that this doesn't take 12 minutes like suggested by zloader. It's pretty instant, and the boot continues as normal as soon as the flag is set
6 Likes
Got a possibly working zycast here now:
To get the new header type behaviour, run it with the -c EE4600 parameter:
zycast -c EE4600 -i eth1 -f /tmp/openwrt.bin
The final clue for these new devices was to send constant sized frames, even for the last one. I have disabled all images types except "rasimage" for now, as the image flags have changed and I have no idea which partitions or volumes they are mapped to.
EDIT: "rasimage" now works for me. After eliminating zycast unrelated FIT signature errors, I finally got
RAS: download to address 0x0000000050000000, size=43797571
!!! Firmware download success !!!
FIT Image is signed with correct key
FWIMAGE_INFO metadata found
Verified checksum of ras image successfully
Verified model id successfully
Verified blocksize successfully
Current bootflag is 0!
Upgrading image slot 1 ...
UBI partition 'ubi' already selected
Volume firmware2 not found!
Remove UBI volume kernel2 (id 6)
Creating dynamic volume kernel2 of size 3767161
Updating volume 'kernel2' from 0x50000800, size 0x397b79 ... OK
Remove UBI volume rootfs2 (id 5)
Creating dynamic volume rootfs2 of size 39985152
Updating volume 'rootfs2' from 0x50398600, size 0x2622000 ... OK
Remove UBI volume zyfwinfo2 (id 7)
Creating dynamic volume zyfwinfo2 of size 256
Updating volume 'zyfwinfo2' from 0x529c2a00, size 0x100 ... OK
Remove UBI volume zydefault2 (id 8)
Creating dynamic volume zydefault2 of size 32403
Updating volume 'zydefault2' from 0x529ba800, size 0x7e93 ... OK
Saving Environment to UBI... UBI partition 'ubi' already selected
done
OK
Succeed to writing 43797571 bytes data into partition ubi
!!! Firmware upgrade success !!!
!!! Force doing reset to default !!!
Remove UBI volume data (id 4)
UBI partition 'zyubi' already selected
Remove UBI volume misc (id 6)
UBI partition 'zyubi' already selected
Remove UBI volume syslog (id 5)
Update engineer debug flag!
'spi-nand0' is now active device
Reading from 0x180000 to 0x1bffff, size 0x40000 ...
Succeeded
Saving Environment to UBI... done
OK
Reset your board! system halt...
2 Likes
Interesting!
I'm guessing you need to run zyeng on a *nix host and connect to the router using serial, at the same time, right ?
I can try this, but my both units are already "liberated" and running ubootmod, so I'm not sure if it's of any use to you.
Serial is not needed for running it. But it is needed to do anything useful with the result, I believe. And certainly for observing what it does, if anything at all.
I have only tried on Linux, but I don't think there is anything *nix specfic here. Just sending a single(!) udp packet over and over again. Should work on any system with IP support. Which includes Windows after they invented the Internet in 1995. If not, it should be pretty easy to fix.
In fact, I wonder if my latest zycast changes also removed the Linuxisms there? I added a packet buffer since the fixed size requirement meant that I sometimes had to send data which isn't backed by a file. So I dropped the Linux specific MSG_MORE hack and just copied every packet via the buffer.
FWIW, I have now done a successful OpenWrt install on my WE4600-01 using zycast. That does not require console or any passwords. I have some hope that same should be possible on EX5601-T0. But we need to build an image with some Zyxel specific metadata (the checksums in the zyfwinfo file must be valid, and the sysupdate json must have a zyfwinfo node). Working on a PoC. I also needed to include a signature node in the kernel FIT image, but this is probably specific to newer devices. Looks like they tried to add a validation chain. And failed 
I haven't compiled anything on a Microsoft platform since Borland C++ was a "thing".
It would just be easier for me to run it on Win, but it's simpler to compile on *nix.
Do you want/need me to do/test anything now, or later when you've worked on your code some more ?
The concept is ready for testing. But be warned that being the first one testing this on a device is risky. I was lucky. You might not be
There is not much failsafe built into the protocol. There is one bit in the header telling the client what type of image to expect. The client has hardcoded knowledge like "bit 2, then erase and write to partition X". The client does some sanity checking, but it is far from foolproof. This is vendor code....
Adding to that problem is the fact that Zyxel changes the meaning of those bits from device to device. So we cannot safely assume that something which worked on one device is harmless on another. Everything has to be tested on every device. And hard bricking is not completely unlikely, although it hasn't happened yet to my knowledge.
2 Likes
@Ols12 do you still own that EX5601 with crippled wifi ?
Interested in donating it to science ?
I’m a sucker for science so bring it on! I was able to reverse from ubootmod, via Zyxel fw to stock layout openwrt. I think I have mtd backups as well. I did read your post last night, so I’m guessing restore backups, compile new version of zycast and attempt a push?
1 Like
I don't think you need to restore anything, but you need to hook it up using Ethernet and serial at the same time.
Post the output from serial and zycast (not sure the latter actually produces any useful info though), and keep your fingers crossed
@bmork any additional instructions ?
I should mention that I have a untouched 5401 as well, not as nice and maybe different chipset. Where did you source the EE/BE units??
5401 is EcoNet AFAIK, diff SoC, not supported by Linux, at least not yet.
Zycast might work there too, but it's of no real use to us.
I bought my T-56's from wifilinks in NL, on BF a year ago.
1 Like
Thanks, that’s what I thought. Regarding the sourcing, I was wondering about the units @bmork appears to be testing (referenced in the sourcecode)
No, not really. Original Zyxel FIP and zyloader is required, but IIUC that has been restored?
Then it's just
zycast -c EE4600 -i eth1 -f /tmp/openwrt.bin
using the proper interface and image of course. The -c EE4600 should be exact like that, though. This is NOT naming a device, just a protocol variant. Couldn't figure out a proper name, so that's it for now.
At this point I'd say that any reaction from the zloader Multiboot client would be a success. So it doesn't even have to be a valid image, although that's probably safest.
The client will most likely attempt to validate the image, looking at the Zyxel specific metadata they add. So I expect OpenWrt images to be rejected.
2 Likes
Will publish more about those when I get all the loose ends sorted. There's still a lot of work to do.
There are some advantages working for an ISP. Early access to new hardware is one of them. Don't know if you can find these devices in any shop yet. But I expect them to becore very common in the near future, as second hand operator branded devices. Just like the EX5601-T0. Hopefully with full OpenWrt support from day one
The hardware should not surprise anyone: Mediatek MT7988D, triple radio, a couple of 2.5G phys. There will probably be several variations, with or without SFP+ etc, depending on different operator requirements.
1 Like
In a bit of a hurry, I will post logs tomorrow, but long story short: it works. OpenWRT initramfs image fails verification after loading, but flashing factory firmware works just as expected.
1 Like