That was already the discussion in https://github.com/openwrt/openwrt/pull/3109, I think we called it factory-recovery and factory-webflash initially, but later changed it to just factory and recovery. Probably the topic would arise again (especially since the devices are currently supported with an image called factory, and changing this to recovery with future versions of OpenWrt might confuse people, but that's hopefully a minor issue (those who had their devices flashed already will use sysupgrade anyways).
Regarding DIR-853, I looked through imgdecrypt from the GPL release in ghidra, and it looked just like the same vendor key... turns out I had the path for that image file wrong in my test script, so that one did not decrypt successfully... However DIR-2640 need some attention, will have a look later in the evening.
Maybe for a first iteration, we could just support the legacy keys + the new COVR-X1860, if there really are more keys that suddenly show up in GPL tarballs, they could be added later.
But at least I want to test COVR-C1200 before submitting this. Turns out the "gzip-based signature" (as I called it back then) is actually nothing but crc32, but for some reason they used the gzip utility on the router and then just parse the crc32 field out of the resulting .gz file
sounds good I can test most of them by loading the unencrypted firmware & trying to install openwrt from that
I have not seen the dir-1960 key but i'll look in the 3060 stuff & try it soon
weird, DIR-2640 uses the same vendor key, so we can decrypt, digest before and digest post are matching, but digest_vendor does not match the vendor digest field from the SHRS header (which is why my decryption returned error, although decryption itself was successful),
Also there is a public key in the 2640 tarball, which only works for DIR-2640. So even if we have a private key one day, it would not be the same as for the others (which was my hope initially, that some day that key will leak and work for all of those remaining devices )
DIR-3060 will not be flashable via OEM I guess, at least from trying to verify the image using the old RSA key pair (the private.pem files actually include the public exponent, so the public key can be derived from the private.pem, this is why I also dropped the public keys from the tool, since the OpenSSL API can use the private.pem for verification as well. So if a firmware does not verify against a known key, there is no use in testing. However, being able to verify it on the other hand does not yet guarantee the device would also accept the image, so this will need testing.
For curiosity, I will further look at DIR-2640 and see how the heck that vendor digest can be different here
I do think the keys would be different for most models and each have there own private/public key set
but it is up to the creator
we need the private key to generate the firmware
that will validate with the public key
so given we only have the public key
we can only check if it's valid for the device
and not create a file that will validate
I'm sure I used to be able to extract the file system
from the oem unencrypted firmware with 7zip
but I have forgotten how or 7zip has changed
This is something that confused me as well, since going through the GPL tarballs did not reveal so much in terms of private keys, the firmware images themselves are now the last thing to check.
It's curious there seems to be no rootfs that could be extracted with binwalk, it just finds the kernel lzma at A0. Even tools like sasquatch won't help as there is not even as hsqs magic for the squashfs.
I was wondering if access via serial console could be a way of searching through the file system, there seems to be a default password for many devices based on the user-set web password + @twsz2018, according to Adding OpenWrt support for DIR-3060 - #24 by kar200.
Also there were several security vulnerabilities foudn recently for these devices, that could allow enabling telnet access to the device: https://www.tenable.com/security/research/tra-2022-09
I think I currently only have DIR-2660 and DIR-878 devices in my pile, I guess the 2660 (using NAND) could work for flashing a DIR-3060 image?
Just ignoring the public keys for now, only included those where we also have the private key.
Squashed everything, polished comments and usage output, rebased to firmware-utils master, pushed as separate branch. Cloned once again to /tmp folder just to make sure it all builds and works perfectly:
git clone https://github.com/s-2/firmware-utils.git
cd firmware-utils
git checkout dlink-sge-image_2k23
cmake .
make dlink-sge-image
no errors, no warnings, everything's looking fine.
Tried to edit tools/firmware-utils/Makefile to include the hash and remote repo, building openwrt, and guess what - it fails:
.../firmware-utils-2023-06-20-a6cd8ce0/src/dlink-sge-image.c:87:18: warning: implicit declaration of function 'EVP_MD_fetch'; did you mean 'EVP_MD_flags'?
.../firmware-utils-2023-06-20-a6cd8ce0/src/dlink-sge-image.c:100:9: warning: implicit declaration of function 'EVP_EncryptInit_ex2'; did you mean 'EVP_EncryptInit_ex'?
.../firmware-utils-2023-06-20-a6cd8ce0/src/dlink-sge-image.c:262:9: warning: implicit declaration of function 'EVP_DecryptInit_ex2'; did you mean 'EVP_DecryptInit_ex'?
.../firmware-utils-2023-06-20-a6cd8ce0/src/dlink-sge-image.c:455:18: warning: implicit declaration of function 'EVP_CIPHER_fetch'; did you mean 'EVP_CIPHER_flags'?
and a few more warnings regarding pointer types as a result (since the function declarations were not found at all), finally the linker failing to find the source of these functions will stop the build.
Great, so I've spent several days migrating this old thing to current OpenSSL, to get rid of all the deprecation warnings, now I shall backport it again to something in between, since what my host uses to build firmware-utils as a standalone package is apparently too new again?
I'm done working on this for today, maybe by the end of the week...
sound like you have been having lots of fun
you have the same as me my 1960 may as well be the 2660
just sold as a ac1900 with ac3200 hardware
I'm trying to remember how this all works
& get my linux pc up to date
wait, so they waste unused RF chains just for marketing purposes? I see that the PCB of DIR-2660 allows for multiple populations though, e.g. there are 8 antenna connector footprints, but only 4 populated.
Maybe Mediatek just sell different versions of their wifi chipsets in the same package, so the footprint would remain pin-compatible regardless of the number of spatial streams / antennas supported, I haven't looked so closely at what's actually written on the chips though.
Migrating back to slightly older OpenSSL was less of an issue than expected, also fixed warnings about fread() output being unused (i.e. implemented proper error handling if input file is too short).
Updated branch dlink-sge-image_2k23, also including key for DIR-2150 as mentioned in a current PR for that device.
It is now part of my local build system, next step: rebase some old PR for COVR-C1200 to master for final testing, also COVR-X1860 of course. This should now allow us to build images that are accepted by the OEM webinterface, if all goes well, I will send a PR for this tool to the mailing list
Finally, tests with COVR-C1200 and COVR-X1860 were successful, the latter was quite annoying though in terms of trying to login to the web interface... Using Chromium in Incognito mode eventually worked, even Firefox didn't do it for me anymore, kept getting the "invalid password" message.
Curiously, the whole webinterface is a static web application that uses HNAP to login and configure the router, it seems the implementation of the challenge/response login stuff might not be working correctly?
It seems kind of ironic to put so much effort in getting rid of the bootloader recovery for flashing, just to treat the user to a different set of browser-induced flashing troubles instead
Added a new branch, not yet squashed:
But first, we need the tool in firmware-utils, I will send a patch to the mailing list @Lucky1 can I add your Tested-By to the commit message for the patch?
yes the DIR-878 & the DIR-1960 are the same both ac3200 at lest the ones I have
but the 867 had some transistors removed
that's not to say that there are all like that tho
but as they all use the same PCB just with different loading had to same
both of mine do have 4 steams on 2.4 & 5G in it's factory config
I'm making the presumption that the 867 has only 3's in there not 4's
once I'm happy my Linux pc is set-up & working I'll test & note etc
I don't think it's an absolute requirement to test further if this is inconvenient to you at the moment, I just wanted to offer adding your name to the commit, since you've helped a lot in working on this series of devices. Just let me know whether I shall wait for your test, or send a patch to the list already? A few days won't make any difference here, so feel free to take you time, e.g. over the weekend.
I'm having another look at C1200 / P2500, time to replace the gzip-signature (which is actually just crc32 as it turned out) with a build recipe, and get rid of the Python script.
all good here now I'm more up to date now
I have tested the current version on the current master
on the DIR-867-878-882-A1's and all work fine from web install to openwrt
can add away only tested in encode mode all works great
For those located in Germany:
MediaMarkt / Saturn currently offer 19% off until sunday, making the total price for the pack of two devices € 33,61 with shipping included.
Some of the Gluon devs have commit rights and you could ask them to review and merge your commits, this would speed up the process of getting support for these into Gluon. Especially the covr-x186x.
I just bought two of them at Mediamarkt. They are a great alternative for the dap-x1860 which apparently just went out of stock at the same vendor.
It's also a great timing, the covr-x186x just dropped from 100€ to 40€ at the start of June (even before the sale at Mediamarkt). So this is probably an EoL-sale (last stock they have available) like they did for the dap-x1860, we could take advantage of that if we can provide support now.
Hey @s_2 - amazing work! I'm having troubling building the covrx1860_sgeimage branch, but I suspect it might be me - I had built your covrx1860_master branch previously, but I can't get that to work now either! Just in case it isn't me, I've attached the build failure here: https://pastebin.com/jYS6yarw
I should have mentioned that the covrx1860_sgeimage branch assumes a bump of firmware-utils to a version containing the patch I had sent to the mailing list, which needs to be done locally (as it's not in public OpenWrt yet), but your problem is not even related to that, even the toolchain build seems to fail.
You could try make distclean (or even make dirclean if it still doesn't work), but it will take some time to rebuild everything.
However DIR-2640 need some attention, will have a look later in the evening.
)
