You both will need the: EIAOSI DFN8 QFN8 WSON8 Adapter, I bought it from Amazon.de!
Best Regards,
1 Like
I wonder if any of you with a flash clip would be willing to test out if zycast can be used to flash these routers? If it works, then that would help others coming after you since we'd have a way in without the flash clip. See Method to flash any NR7101 for code pointer and the instructions we got.
Sill risky without bootloader access for backup, of course. But I believe it's slightly better than having to replace the bootloader.
I blindly assumed this device support zycast - most ZyXEL bootloaders do. My EX5700 is quite similar, but unfortunately not running ZyXEL firmware or bootloader from stock.
Note that using zycast might overwrite both system partitions in one go, so there is no way back to original firmware unless you can download that somewhere or created a backup using a flash clip.
I've compiled your branch Bmork. I'm waiting for a friend of mine to get back to me as he has a bricked ex5601 (loads zloader but when trying to boot ubi there is no kernel volume found) and I have a factory/initramfs and sysupgrade compiled from zyxel source.
Just thinking that maybe I'll have to change the "magic" to zyxe (as found into the zyfwinfo analisys).
Yes, this is probably verified by the bootloader. It's obviously hard to test such things blind. Having serial console while running the tool will help. Even if we can't control the bootloader we can at least see if it complains or get stuck somewhere.
You should also be able to verify the process if you have a valid ZyXEL image. It doesn't have to be OpenWrt 
ok guys I give up. From what I understand, this involves desoldering and soldering of a QFN / DFN package chip. This is beyond my skills.
You can still try what Bmork suggested.
Compile zycast from the repo he linked and try it.
I still haven't had the possibility to disconnect mine from the network and try.
As far as I understood you simply have to do the following:
launch the zycast command
zycast -i ethX -f sysupgradefile.bin
connect the serial adapter to read the console
connect the ethX interface with a cable to lan 1 2 or 3 (lan4 and wan are not working when booting)
power up the router.
See if it flashes or not
I could but then there’s the risk bricking it. The problem is that it’s a lease device from the provider and I want to keep it in case I need to troubleshoot my line as they ask for it in such cases.
I’ll try to get hold of another one here on the local marketplace
Ok, in the meantime I'll test zycast asap and let you know
1 Like
Will give it a try "zycast"
When I clone the repo https://github.com/bmork/firmware-utils.git there is no file zycast.c in folder /firmware-utils/src/.
After that downloaded the raw version from github and compiled with: gcc zycast.c -o zycast
chmod +x zycast
./zycast -i eth0 -f ras.bin
2nd terminal: connected the serial adapter to read the console
power up the router.
and is not flashing the firmware
part of the logfile:
Multiboot client version: 1.6
Hit any key to stop autoboot:000
Booting from latest image (address 0x07600000, flash offset 0x07600000) ...
Verifying Digital Signature...........!
Start block 472-End block 943
First Block 472 is skip
Block 473 is empty 4096, skip
Block 474 is empty 4096, skip
Block 475 is empty 4096, skip
Block 476 is empty 4096, skip
Block 477 is empty 4096, skip
Block 478 is empty 4096, skip
Block 479 is empty 4096, skip
Block 480 is empty 4096, skip
Found the DIGITAL SIGN HEADER
tested with a DX5401-B1
I bet that just like ex5601 the dx5401-b1 has different magic code to be pushed via multiboot client.
the zycast.c actually is using "zyx" which probably doesn't work with ex5601 (where i suspect the magic is "zyxe") and the dx5401-b1...
@bmork probably it makes sense to bring this discussion about zycast on a dedicated thread where we could possibly collect multiple device tests...
@nvl try to run strings or ghidra on your ras image and see if you find anything related to multiboot magic in hex or plain text. (try with 0x2BADB002 or 0x1BADB002 too )
Why do you suspect the magic is different? This is not the image magic, which obviously is device specific. It's the packet header. That's protocol specific, and changing it from device to device seems counter productive. That doesn't mean it can't happen. Vendors do stupid things. And we have seen a device with an OS implementation of the protocol where they changed the size of the bitfields.
/* magic number for multiboot header */
#define MULTIBOOT_HEADER_MAGIC 0x1BADB002
I don't know probably they update it based on the vendor too...
the dx5401 is broadcom... the ex5601-t is mediatek... or simply changed with revisions
dx5401 uses 1.6 version
ex5601 mentions 2.7 in the bootlog
Where do have this from? Do you have the zloader source for this device? ("bad boot" - funny
One of the nice things about this protocol is that ZyXEL have implemented it across their product line, regardless of soc/platform. But it looks like they've reimplemented it, so there are variations. Like the supported features. Or the stupid dual image flashing of the NR7101. The protocol supports separate flashing of the two firmware images but this is not implemented on the NR7101
@bmork i extracted zloader.bin from EX5601.
If you need i can share the file with you or you can share some info about Ghidra/Ida debugging of this file
I can confirm ( branded t-mobile NL), dx5401 aka T54 is a broadcom device and ex5601-txx aka T56 is a mediatek based device.
I'm no reverse engineering expert. I just loaded it in ghidra and tried to correlate with what I already knew. Actually converting it to readable code is simply a lot of hard work. For me at least. The compiler will move blocks around and combine them in interesting ways. I have to manually revert all those optimisations to be able to follow the code flow.
Just tested on mine ex5601-t0 and is not working.
Tried with lowering the delay (-t) to 4 and 2 with no success.
Tried with EXYZ (0x4558595A) too and with zyxe (0x7A797865) and is not working
I guess the only way to find the magic or the logic itself is to decompile zloader.bin 
@ftp21
Just to be sure...@bmork in the comments section of the zycast.c you metion the 6531 port.
In the code itself instead it's 5631... just checking if the comment is wrong or if the correct port is 6531
Argh. Typing is hard
The code is tested, so the code is correct. This is the destination port test from the decompiled WAP6805 zyloader:
if (dest_port != 0x15ff) {
return;
}
BTW, wrt the packet header magic. I see that the zyloader code I have looked at would actually accept "zyxe". So it's quite possible you are right this is the correct magic. My problem was that the code only checked the 3 first bytes so Ihad to guess the 4th. "e" is just as likely as \0 here.
This is the ghidra generated signature check:
iVar6 = memcmp(pkt,&DAT_81e065cc,3);
if (iVar6 != 0) {
__format = "The signature is %s, wrong signature\n";
puVar7 = pkt;
LAB_81e039f0:
printf(__format,puVar7);
return;
}
Not obvious, but point is that it only does a 3-byte memcmp() on the beginning og the packet. This code will accept anything in the 4th byte, but other implemetations could be stricter.
EDIT: except that the error message will explode unless the 4th byte is zero. But that's the code running when the signature is wrong.... Which is the sort of crazy stuff we have here. No one in their right mind would write something like that.
1 Like
Strings on the ras.bin image file give nothing but standard text related to multiboot or magic.
And tryed with 0x2BADB002 or 0x1BADB002 to, but nothing happen.
eth0 from laptop is down when this starts;
Multiboot client version: 1.6
Hit any key to stop autoboot:000
have to look in to this first.....