DAP-X1860 reflashing original firmware

Hi, I've installed OpenWrt on my DAP-X1860 repeater, but I would like to test the original firmware again. With OpenWrt installed I do not have access to the DLink recovery mode where I can install the original encrypted firmware directly. I found this youtube video about how to decrypt the official firmware blob, i.e.:

openssl enc -d -md md5 -aes-256-cbc -salt -in FWImage.st2 -out FWImage.st1 -k MB0dBx62oXJXDvt12lETWQ==

and xoring the result:

import itertools
import sys

key = itertools.cycle(b'\x88\x44\xA2\xD1\x68\xB4\x5A\x2D')

with open(sys.argv[1], "rb") as f:
	fw = f.read()

with open(sys.argv[2], "wb") as f:
	for i in range(0, len(fw)):
		f.write(bytes([fw[i] ^ next(key)]))

But comparing the firmware files provided by OpenWrt with it it seems to have a little bit different structure:

$ binwalk kernel_DAP-X1860.bin.decrypted

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
128           0x80            uImage header, header size: 64 bytes, header CRC: 0x3763DB3E, created: 2021-09-30 04:39:45, image size: 5678045 bytes, Data Address: 0x81001000, Entry Point: 0x81009EC0, data CRC: 0x6BB0E4F5, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "Linux Kernel Image"
192           0xC0            LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 24088960 bytes
5767296       0x580080        Squashfs filesystem, little endian, version 4.0, compression:xz, size: 5320630 bytes, 777 inodes, blocksize: 131072 bytes, created: 2021-09-30 04:35:05

I have access to the failsafe mode and OpenWrt's web interface. How do I install the image properly, without bricking the device?

D-Link devices with recovery mode have more than 1 partition.

One partition with a bootloader and another one with the firmware (and then a few more partitions that are not relevant for my argument, with config and calibration data and so on).

If you flash a regular firmware file on such D-Link devices, you overwrite the firmware partition, but not the bootloader partition.

The said recovery mode stuff loads solely from the bootloader partition (and this bootloader with the recovery code is neither overwritten when flashing firmware via the original update function, nor via OpenWRT sysupgrade and also not via recovery).

Thats why D-Link devices are rather difficult to brick.

So you can simply go ahead and try to flash the file: if it is a broken image then the only consequence is that you cannot boot into the (broken) firmware, but you can still boot into recovery again afterwards and retry as often as you want, since the boot loader partition is still sane.

The thing I would avoid is, to blindly execute commandlines for flashing that are posted somewhere on the internet or purposely flash a file that is considerably larger than a typical firmware file for that device, as this could theoretically overwrite some other calibration data partitions.

I only got into the dlink recovery when I flashed the kernel using LuCi, which apparently soft-bricked the device. Interestingly, the dlink recovery only accepted the openssl decrypted the image, de-XORing was not needed. Now its working fine, thank you @Pico

other D-Link devices are affected as well.

Very old D-Link devices always had unencrypted images. Then starting roughly with WiFi AC Wave 2 devices, they came up with encrypted vendor images and the regular update function being the only function to properly decrypt and process them, while the recovery function in the bootloader remained in place, but got never extended to process such encrypted images, while regular vendor releases from now on all were kept encrypted. And not all devices use the same key. Weird strategy. The recovery web page also has this weird unfixed bug to usually fail on Linux clients and certain browsers. The recovery module doesn’t get much love anymore.

I hope they are not planning to fully kill the ease of the recovery option in the long run in future devices, though sadly Secureboot seems to slowly enter the router market now. I always liked the ease of installation of OpenWRT on D-Link devices via recovery.

I guess, the bootloader might be able to detect a broken firmware partition via failed checksum and then automatically load into recovery.
But you should always be able to trigger recovery in D-Link devices manually, by keeping the reset burton pressed and then turning the device on, while keeping the button pressed for around 10 more seconds.