The provided PoC works for the handful of devices that deploy this specific encrpytion scheme.
The reversing here was done for educational purposes.
If this PoC doesn't work for you and your encrypted firmware does not start with a 4-byte "SHRS" pattern that's expected.
Encryption schemes change over time.

This is the PoC code for my blogpost series about breaking encrypted D-Link firmware samples for further analysis:

• part 1
• part 2
• part 3

• src --> My re-constructed C code from the imgdecrypt disassembly
• bin --> Has compiled x64 versions of the imgdecrypt binary
• DIR_3060 --> Contains public.pem and the imgdecrypt binary from their root fs
• DIR_882 --> Analogous to DIR_3060
• test --> some test binaries for un-/packing

For the basic decryption of a sample you can just invoke the python script as follows:

$ ./dlink-dec.py
Usage: python3 ./dlink-dec.py -i <in> -o <out>

I've also rapidly prototypted a D-Link like encryption that mimics the original one. You can test it by adding a mode flag to the invocation:

$ ./dlink-dec.py
Usage: python3 ./dlink-dec.py -i <in> -o <out> -m enc

As always there is also an alternative way using openssl:

dd if=enc.bin skip=1756 iflag=skip_bytes|openssl aes-128-cbc -d -p -nopad -nosalt -K "c05fbf1936c99429ce2a0781f08d6ad8" -iv "67c6697351ff4aec29cdbaabf2fbe346" --nosalt -in /dev/stdin -out dec.bin