Thanks, in the Release Notes it states:
Disable FW manual version downgrade
Do we have to update some version number in the factory image header here? Maybe use some very high number to be future-proof, if people one day want to update their devices from a later OEM version.
// edit: wait, it also states Add FW AES-128 Encryption so this is already the version we have here?
Dual images are indeed annoying, not sure how to proceed from here with ubi0 vs ubi1 
@Pondera : Thanks for the information
I have to check if this is affected. But as long as there is no solution for the dual partition boot, factory images don't make sense in my opinion.
I was able do decrypt the image with the current version of dlink-ai-firmware-tool without changing anything, not sure what they mean until now. Also flashing the decrypted image from the recovery web interface works as usual.
The problem I currently have is that I cannot flash OpenWrt recovery images anymore. I have to ivestigate if I bricked my router with the OEM web interface flash tests or if the update changed something in the bootloader which causes the problem.
How far does it get, is an image flashed but not booting, or is the flashing no longer working? (any Linux updates in the meantime? maybe try the script from the COVR-P2500 wiki page for uploading).
I wouldn't believe they updated the bootloader, but maybe some environment variables
I had to adapt the DTS, initially there were two partitions ubi and ubi1. OpenWrt was running in ubi until now.
But with my device, the recovery web interface loaded OpenWrt in ubi1 all the time. So I had so rename ubi to ubi_bak and ubi1 to ubi. Now OpenWrt is up and running again.
Similar to the issue with dual boot and the factory images. So I have to search for a way to select the correct UBI partition during startup 
Maybe that can be done somehow in target/linux/mediatek/filogic/base-files/lib/preinit/75_rootfs_prepare, similar to creating the rootfs_data partitions during first boot. But never did it before...
Some background to the boot procedure of the device:
There are two partitions in the OEM firmware:
There are three U-Boot environment variables involved:
bootpart (0: Boot from UBI0, 1: Boot from UBI1)sw_active (1: Active SW in UBI0, 2: Active SW in UBI1)sw_tryactive (0: Try to boot from UBI0, 1: Try to boot from UBI1: 2: normal boot based on variable bootpart)U-Boot checks during boot if sw_tryactive == 2, in this case a "normal" boot is performed:
bootpart == 0,set sw_active = 1 (if not alredy set). Set bootpart = 0, boot from UBI0bootpart != 0, set sw_active = 2 (if not already set). Set bootpart = 1, boot from UBI1If sw_tryacitve != 2, try the new firmware:
sw_tryactive == 0: set sw_tryactive = 2 and sw_active = 1, boot from UBI0sw_tryactive != 0: set sw_tryactive = 2 and sw_active = 2, boot from UBI1If the software is running in mtd5, the following variables are set:
cat /proc/cmdline contains bootpart=ubi0sw_active=1sw_tryactive=2bootpart=0sw_tryactive is set to 1If the software is running in mtd6, the following environment is set:
cat /proc/cmdline contains bootpart=ubi1sw_active=2sw_tryactive=2bootpart=1sw_tryactive is set to 0So OpenWrt has to set bootpart after flashing:
cat /proc/cmdline contains bootpart=ubi0 and bootpart==1, bootpart must be set to 0cat /proc/cmdline contains bootpart=ubi1 and bootpart==0, bootpart must be set to 1The problem is that the U-Boot recovery web interface always flashes to the active partition. Current workaround:
There is also an open PR which addresses the dual boot issue: https://github.com/openwrt/openwrt/pull/10674
Maybe this would help not requiring the workaround anymore
I tried to build OpenWrt 23.05 for this device, works in general but WAN Is not working. I see the port in luci but I don’t get a link. The problem doesn’t exist in the snapshot builds.
Does anyone know what is missing here or where I can start searching?
In the boot log, I see that the following lines are not present in 23.05:
[ 2.688493] mtk_soc_eth 15100000.ethernet internet: renamed from eth1
...
[ 18.679775] mtk_soc_eth 15100000.ethernet internet: PHY [mdio-bus:00] driver [MediaTek MT7981 PHY] (irq=POLL)
[ 18.689743] mtk_soc_eth 15100000.ethernet internet: configuring for phy/gmii link mode
[ 18.709513] mtk_soc_eth 15100000.ethernet internet: Link is Up - 1Gbps/Full - flow control off
[ 18.718191] IPv6: ADDRCONF(NETDEV_CHANGE): internet: link becomes ready
Update:
Looks like the following line in target/linux/mediatek/filogic/base-files/etc/board.d
ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4" internet
must be replaced with
ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4" eth1
Which means that label = "internet"; in the gmac1 node of the DTS is not used in 23.05.
Any status on the E30? I just realized the E30 and M30 have the same device name but I already got the E30 expecting to put openwrt on it.
Very interesting, where did you get the E30? It is not yet available in Germany.
Do you have a serial log for it? I would be interested in porting OpenWrt to this device
I had a short look at the GPL sources of E30 and if I understood correctly it should be quite similar to the M30 (MT7981, LEDs controlled via I2C, same image crypto).
Unfortunately there is currently no OEM firmware to download to check my assumptions.
I updated the firmware tool to support E30:
I also created a branch for E30 support based on M30 and GPL information:
LAN probably won't work yet because there is only one port and no switch.
E30 looks interesting indeed, the 180 days short term confidentiality for the FCC filings for KA2E30A1 is over since 2024-04-25, so we can finally see internal photos (only on the FCC website for now, fccid.io is not yet updated).
Although the case design looks similar to DAP-X1860 (by Acelink/Edimax), it was to be expected this device is completely different. Only MT7976CN can be seen in the pictures, not sure what the other chip is (one of them might be RAM?). Or are they really using a wireless SoC as a peripheral here to a main MCU? But it's probably just RAM and eMMC.
Would love to see a bootlog as well 
Indeed no firmware on any of the international ftps or the tsd center...
Well, probably there is a switch indeed, as the Ethernet lines definitely go to the unknown chip in the picture, so it might as well be a switch then Makes no sense with one port of course, but then again that was probably the working software package they had, so... 
@knuxyl Could you open the device and take a better picture? (If there's no heatsink connection to be destroyed there)
Do you mean https://device.report/m/1cbc71a87aab5851c5b3ebc5f62836d3282772b3b0d06968944e924ea54aa22d.pdf page 3?
As far as I understood, in the bottom, there is the MT7976CN for wireless, above would be MT7981 and RAM/FLASH, similar to what we have in the M30 shown here Add support for D-Link M30 (AQUILA PRO AI AX3000 Smart Mesh Router) - #10 by frollic.
I think for the M30, the switch is the chip covered with the gray pad. I don't see something similar in the E30.
And at page 2 of the PDF, I assume the chip on the left side is the LED controller.
UART is probably the pin header on the left side page 3. From top to bottom GND, TX, RX and VCC. I assume it's not populated by default.
So they do indeed use a separate Wireless and SoC here, as with other devices.
Where did you find the GPL sources, on some ftp maybe?
Could you check if meta-myproject/recipes-dlink/fota/files/ contains anything interesting (at least for M32 this was the folder), technically they should at least have their firmware updated on the FOTA servers if not on TSD (although most D-Link devices would successfully display "you already have the latest firmware" when there is not even connectivity to check for updates in the first place, so they're probably not in a rush to supply firmware there either before shipping a new model).
It's for example available here: https://ftp.dlink.de/e/e30/driver_software/
This folder contains the "usual" fota files, including keys and a script to decypt the firmware.
I was not able to find it, but also didn't invest a lot of time to figure out the structure of the FOTA server. In the M30 OEM firmware logs, I saw that it downloads this file:
https://fw.fota.dlink.com/COVR/M30/Ax/Default/stable.bin
But until now I wasn't able to figure out the URL for the E30 firmware. Any idea how to find the E30 file?
Indeed, the full URL is not part of the FOTA software package. I looked at the fota binary in ghidra, there is a function get_fota_url (at 0x001063b0) that calls read_csman, i.e. it would read stuff from the odm partition.
The string behind the ODM key 0x8015003b contains Default for e.g. my dump of E32, the E30 FOTA compares this to be either CN or not, then uses different hostnames to compose the URL (either api.fota.dlink.com or prepended with cn), the rest of the URL is taken from ODM key 0x801501e0, which is not even in the M32 dump (would have to check others though).
So yes, we have a bootstrapping problem here, we need to dump the flash from a real device first to get the encrypted firmware URL from ODM partition 
The first firmware for E30 is available:
https://support.dlink.com/resource/products/E30/REVA1/
Unfortunately, compared to M30, they changed the encryption (similar to M60).
There is also an update firmware for the M30, there the encryption is unchanged.
Some more investigation required to support the new firmware encryption.
Update: Also looks like the firmware crypto for M30 was changed. I cannot decrypt the images anymore. Tried my firmware utility and the scripts from D-Link in the GPL package, same result.
According to the release notes, it affects multiple devices: R12, R15, R32, M15, M32, E15, M30, M60 and E30.
The new format is somehow also reported in the release notes:
Problems Resolved:
- FOTA upgrade failure/loop
Enhancements:
- Enhance security.
Known issues:
- This firmware version cannot be downgraded to previous versions.
What this means for OpenWrt:
are they actually updating the bootloader, or could we technically flash an old (decrypted) OEM version via recovery and then upgrade to newer OEM?
The user would need to know about the decrypted OEM images of course.
Maybe we were too quick this time, supporting devices in OpenWrt that are still actively supported by the ODM, so they can force them to change firmware encryption once again 
(However, it's also still on my bucket list to see some OEM, intentionally or accidentally, actually use the crypto code from OpenWrt for their devices when they release new versions or new devices from the same family )
Thanks, I'll have a look at the new format.
// edit: the only relevant publication I found from D-Link was on the Realtek devices from this series, also made by AMIT and apparently sharing lots of higher level software. Maybe they reproduced this also with the MediaTek models?
https://supportannouncement.us.dlink.com/security/publication.aspx?name=SAP10394
So I downloaded M32A1_FW110B02_revise from that support page, could not decrypt it manually using the IV from the header (I think it's called revise for this device since there was a previous release called "HOTFIX" for M32 already; in any case it also contains the same release notes document as the others).
However, it was also not flashable from older versions 1.0x via OEM Web.
Also found a version FW110B02 on the tsd site (same number but without the revise), and it turns out that this serves as an intermediate firmware, from which the revise can be flashed.
After upgrading, the key in the ODM partition has changed from 6b29f1d663a21b35fb45b69a42649f5e to 1bfb1004e29f9eb76dbe26eb0dd87cd1, and using the latter I can successfully decrypt the firmware file.
So this is how they claim that reverting is impossible (which is already stated in the release notes for the FW110B02, which was also released on May 29th).
Will have to check M30 and other devices as well, but it's probably the same for those here - they just changed the key and updated the ODM partition.
But factory for the new AES key is probably not happening since we'd also need the RSA key for signing, and the initial attept of flashing revise over the very old one failed due to signature 2 mismatch already (printed to serial console), so they also changed that one, but now probably learned not to publish it anymore
// edit: ok this was just the change within the "old" format, but E30 indeed uses something different, not the MH01 amit-split encapsulation, but just the DLK6E header. So the first part is 0x200 in size, maybe the signture? and the rest is a high-entropy file, so maybe they use constant IV for those devices and something yet different?
There is also E30A1_FW110B02 on the TSD website, which is not identical to the hotfix variant, but same format. So the hotfix change might be somewhat unrelated to the format change? Or maybe they just didn't feel like changing the new E30 format was necessary yet...
I guess we'll have to obtain a device first for further investigation
Probably same as for M60.
Unfortunately the E30 and M60 are not (yet) available in Germany. For me it’s not yet clear based on which information/decision the devices are available in which country
For the R32, the boot loader version didn’t change after updating to the latest firmware.
Seems like there is another update:
https://nvd.nist.gov/vuln/detail/CVE-2024-6045