I tried with web browsers. I don't see why curl would make any difference, as I did manage to successfully get a "double signature" image uploaded.
As these are d-link images, I don't think I can upload them publicly, but perhaps I can privately share them with you?
I thought you mentionned that you couldn't upload even the images from the dlink ftp server. But It's fine it was just curiosity really.
For the router that I have dlink encrypts the whole firmware. I found by chancethe binary they use to encrypt the firmware in the one of the source code tree so I was able to encrypt the firmware in a single command.
I actually thought Dlink russia used non encrypted firmware and just relied on the header for checking but I guess I was wrong lol.
Hi,
I did mention that. For some reason the Failsafe UI does not recognize those images. It seems that it requires two suffix signatures.
The full image encryption (which was recently broken) appears not to apply to these Russian images.
I'm happy to see it works
you can only submit a pull request for a device when you have that device
so someone whit one has to check it over & submit it
you can do this yourself if you like
Hi Pyckle,
How did you manage to get a full dump and flash openwrt please? apparently with SSH you only get user access with admin/admin
Hi kar200,
In the older firmware image that was originally installed on the device, there is a utility called fw_updater that flashes the firmware without any verification checks. In this older image, admin has uid 0, and has permissions to do "dd if=/dev/mtdX of=/mnt/usb_X/mtdX bs=1M"
In any case, I am working on understanding the checks on the 0x00C0FFEE signature present on the manufacturer firmwares from the bootloader dump. I will post back if I am successful.
Edit: This clearly is older than your firmware image, This firmware didn't support SSH. Only telnet.
I see. So if you install the older image back admin should have root privleges. Thanks for the tip.
I asked because someone contacted me directly to build an image for the DIR-853 R1. Although I don't have access to the device and he might end up with a brick it seems he still wants to try. When I asked him to get a full dump (with dd) it came back with an access error.
I had noob look at the 853 vs 882 and if you pick the exact version they have the same leading and trailing bytes (as you already mentionned) ie: 001.001.000 and 0x00c0ffee.
As you said that means there is a 16 byte checksum in between but good luck with the rest.
By the way I did email dlink for uboot source code for my device and they basically said "no". This is because for some reason my device does not have the emergency room working with the reset button (which does on other devices). But I also noticed that the reset GPIO number is different on mine compared to all the others that use the same 160byte header.
@Kar200
if you friend has serial access to his DIR-853-R1
he should be able to load that DIR-882-R1 inframs Image straight into ram via tftp
& dump his flash hoping it's the same flash chip
ether way it should not brake anything even if it wont run
the partitions may be out but he should be able to construct a full flash dump
Thanks @Lucky1 but he doesn't have access to the serial. and since this is done blind I am just making sure he can recover his router through web recovery first before I send him anything.
my experience with the boot loader from a DIR-882-r1 in my DIR-878-A1
is that it just excepts the Russian firmware
just needs an image with valid header & checksums
& I do note that the Russian Firmware has a boot.img file in it & if the boot loader differs
it updates it or at some point maybe factory erase maybe just updating
you can easily get a copy as Kar200 showed me by using 7zip & extracting it from the firmware file
I agree can't do anything without serial access with untested files
For what it's worth, I figured out the magic 00c0ffee signing algorithm. It's nothing more than a salted md5 hash of the firmware followed by the magic 00c0ffee bytes. A bash script that sign images with the "secret" salts present in my bootloader image is here: https://pastebin.com/5wGYjTsn
I tested that it signs the firmware images that the bootloader accepted correctly, but I have not yet tried uploading any signed OpenWRT firmware images to it, as I have already configured my router. I didn't verify, but I suspect that the checks that kar200 was referring to are done too.
Although the single signatures present on the Russian FTP site do not match the signatures that my scripts produces, the images that my scripts probably are compatible. The Russian FTP server hosts firmware images that are signed with the second salt, so most likely signing with both will pass the validation for this.
I will try to find time to make a Pull Request to get support for the R1 revision to upstream sometime in the near future.
I just had a look in a hex editor & compared you uboot.img with the uboot.img
In the latest Russian Version it is different
I do see added errors "Wrong magic or version" "Wrong signature!" & "Wrong second signature!"
I did use the Russian uboot.img when I tested uploading that openwrt image
It seem that the Russian version is testing for these things
if you did upload this Russian versions the same way as you did openwrt
I think it would chnage the Uboot to the non checking version
I'm not sure if this it a good or bad thing but something to note
As far as I can tell, none of the Russian firmware images update or change the bootloader. Why do you suspect otherwise?
The model which I purchased was purchased in Israel. Perhaps there are different bootloader images for different regions? The router box does have a sticker that was added that indicates the firmware was bumped to 1.0.3 and says "/IL/R1B"
I am reluctant to update or change the bootloader because I lack the tools to unbrick the router if things go awry.
Where do you see this latest bootloader, and how are you sure it is newer than the one on my model? A non-scientific check indicates the following likely build date for the bootloader on my router:
$ strings mtd1 |grep 2018
U-Boot 1.1.3 (Mar 21 2018 - 11:11:47)
Date:Mar 21 2018 Time:11:11:47
I got a boot load a while go i think it was for the DIR-882-R1
I have a DIR-878 so when i put the DIR-878-R1 firmware on it
I believe it changed I'm not sure when but i do remember reading the flash chip
and in comparison it had changed
tho when look at the versions in the ru web site all the 878 have the same & the 882 has the same
but different to each other
V3.5.0 to V4.0 of the 882s are dated Jul 3 2017 Time:13:54:00
Lucky1 - you do pay careful attention 
My bootloader in fact did change slightly from when I first dumped it to what's there now. There is now different data in offsets 0x20C30-0x21408. Seems like mostly string constants, and perhaps a bit of code. Perhaps I'll look at what it changed if I have some time.
I tested and verified that signing a built image with my script works with the Failsafe UI.
I opened a PR here: https://github.com/openwrt/openwrt/pull/3468
The one thing that I'm wondering - is there a better place to put this bash script that signs the firmware images for the Failsafe UI? Also, would a language other than bash be preferable to write it in? I am happy to rewrite it in perl or python if that is preferred.
Nice work.
I noticed that most of the factory images modifications are done through this file.
It seems that most of them (if not all) arw written in C and placed in
https://github.com/openwrt/openwrt/tree/master/tools/firmware-utils/src
so you script is something you have ran after on the compiled image ?
I think the normal thing to do is add code that is ran during image creation
so I think it's like uimage_padhdr.c witch is in openwrt/tools/firmware-utils/src/
this was run to adjust the header for the DIR-878 with the extra 96 byte & recalculate the checksum
after the basic image was created
Kar200 could also be right that looks like custom firmware image creation
I'm not sure there will be another step added in MT7621.mk to the image build
as language I would think C but have a look at others as long the the build bots will build it
Thanks for the feedback. Here's the issue - I suspect that it would be challenging to write the signing algorithm inline into a Makefile. It's not difficult in C with an md5 library, however, I think that it should be in a separate executable. This signing scheme seems only to be on the RU version of dlink routers, and as such, it seems weird to put it in a tool that is necessary for all D-Link routers. Perhaps it should be a separate tool on its own that runs after uimage_padhdr.c? Perhaps sign_dlink_ru_img.c ?
I'm still a little confused as the uboot/bootloader inside the Russian Firmware has not got this check
I somehow think there are different versions yours being the /IL/R1B another being just R1
I have used the failsafe interface many times with needing to add a signature
can you send me a link to firmware that uploads & works on you version
and i'll have a play
I'm starting to think if your firmware works on the R1 bootload maybe changing to that is an option