Alright, my fellow EEVBloggers!
I would be happy to post the new hacked firmware that downgrades every FW revision up to v2.06 SP0 included, down to v2.02 SP2 along with the original FW v2.06 SP0 (2.06.00.01).
But, given that
all the "illegal" firmware attachments were removed from this blog at some point, makes obvious that posting the FW files above puts the blog at risk.
Let's review some facts:
I still haven't heard of anyone downgrading the 2.06 firmware. As far as I know, no-one has even posted a copy of the 2.06 firmware anywhere yet.
Well, I have done it, Richard! And reverted back to v2.04 SP1.
Drieg led the way, providing us with some valuable information:
...don't waste your time, seems that Rigol made a stupid mistake and forgot to prevent a FW "upgrade" to the same version 
Besides that, I didn't notice any difference between v2.5 and v2.6, at least the menu is very same.
The fact that v2.06 can "upgrade" itself is the key!
A. Hellene cracked the header code in this post: https://www.eevblog.com/forum/index.php?topic=553.msg42404#msg42404
Theoretically, the same approach can be used to modify the 2.06 header
Exactly, Torch! The method remains the same.
Recently, I posted the header of FW v2.06 SP0 (2.06.00.01) along with other ones
at this message:
---------------------------------------------------------------------------
HEX Address: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14
---------------------------------------------------------------------------
v2.05.01.00: 44 53 31 30 30 30 45 20 20 20 82 85 84 88 C3 7B 47 92 39 C8 7E
v2.05.01.02: 44 53 31 30 30 30 45 20 20 20 82 85 84 82 8B B8 96 41 63 FF 33
v2.05.02.00: 44 53 31 30 30 30 45 20 20 20 82 85 82 88 C0 7E D7 6A 15 B6 B6
v2.06.00.01: 4A E3 3E 5E 1C EA 8D 39 9A 23 82 86 88 84 02 8C E9 A6 50 D0 BC
---------------------------------------------------------------------------
The steps to take are the following:
1. Find the original v2.02 SP2 (v2.02.02.00).
Original v2.02 SP2 file CRC32 checksum: A3370F0E
Original v2.02 SP2 file MD5 hash: 272086B2037231C62446617436544A77
2. Open it with a hex editor and replace the first 21 bytes of the header with the 21 bytes of the v2.06 SP0 (2.06.00.01) header, posted above.
3. Save the new file, which is recognised by the DS1000E as v2.06 (2.06.00.01) but it actually is v2.02 SP2 (2.02.02.00) and can change the model and the serial number of the device.
Hacked v2.02 SP2 file CRC32 checksum: 0C83CBD6
Hacked v2.02 SP2 file MD5 hash: 19EB82AB1FA4FE57CC9410F2074E9E67
Note that changing only the model will not work after a reboot. In order to save the model permanently it will also be needed to re-enter the serial number. Enter the serial number the device will return after the ":INFO:SERIAL?" command, or as it is displayed in the sticker at the back of the device; there is no need to change the model letter (D/B/F) within.
4. Change your device's model & serial number and upgrade your firmware to v2.04 SP1 (2.04.01.02), or higher,
immediately!
DO NOT operate any further the HW58 devices with the hacked firmware or with any other firmware of a revision lower to v2.04 SP1.
Try also to avoid all the v2.05 revisions that introduced flickering or other bugs.
5. Done! Enjoy your crime!

P.S. The files mentioned above can be found online. So, please, do not start asking me to be sending or emailing them individually...
[EDIT]: All the files needed can be found
here and
here.
Something different, now:
[...]
I did come across someone who has written a dissembler for the Rigol DS1052E Blackfin processor, in case anyone wants to start poking around:
http://codenaschen.de/tichyblog/?action=blog&entry=1_Blackfin%20Disassembler%20Processor%20IDA%20Pro%20Plugin
https://github.com/krater/Blackfin-IDA-Pro-Plugin
It includes the sourcecode for the Rigol firmware file loader.
[...]
Richard
Ah, this is a very nice finding! Thank you, Richard.
I do not know what the main plug-in is able to do. There are listed a few bugs at the included README file, though.
Having spent some time on the BlackFin documentation, this is what I've quickly found in the
rigol_ldr.h:
struct rgl_hdr {
uchar name[10];
uchar version[4];
uchar dummy1[2];
uint32 crc32;
uchar dummy2;
};
struct ldr_hdr {
uint32 addr;
uint32 size;
uint16 flags;
};
Well, according to the BlackFin "Loader and Utilities Manual" rev. 2.2, page 3-5:
"The boot ROM evaluates the first byte of the boot stream at address 0x2000 0000.
If it is 0x40, eight-bit boot is performed.
A 0x60 byte assumes a 16-bit memory device and performs eight-bit DMA.
A 0x20 byte also assumes 16-bit memory but performs 16-bit DMA.".Since there is such an entry (with a value equal to 0x60) at all the .RGL firmware upgrade files (right after the 21-byte revision header and before the 10-byte bootloader header) I think that the source file above should rather read something in the lines of:struct rgl_hdr {
uchar name[10];
uchar version[4];
uchar dummy1[2];
uint32 crc32;
uchar dummy2;
};
struct ldr_hdr {
uint16 bmode;
uint32 addr;
uint32 size;
uint16 flags;
};
[EDIT] I was wrong: Actually, the first boot Byte in the ldr_hdr (the 0x60 one in the DS1000 firmware upgrade files case) is the LSB of the first firmware file dword after the 21 bytes version header.
[/EDIT]I am also not sure how dummy the
dummyX entries are...
Yet, I welcome and applaud any such efforts!
-George