changing the rigol DS1052E to DS1102E using USB , the dummy guide

[joh]

I suggest that Drieg has a full picture of the challenges.

[Mechatrommer]

Is there anyone who has experience in blackfin assembly ?

once i asked the same question. few weeks/months back there is an attempt. pls rewind and read previous posts from this thread.

[maze]

Having a new scope as well, I looked a little into the new firmware headers:
"44 53 31 30 30 30 45 20 20 20 82 85 84 88 C3 7B" (02.05.01.00, first line)
calculates with CRC-32 to C8399247
"47 92 39 C8 7E 60 00 80 FF 04 00 00 00 10 00 AE" (02.05.01.00, second line)
The first four numbers look like the CRC-32.

"44 53 31 30 30 30 45 20 20 20 82 85 82 88 C0 7E" (02.05.02.00, first line)
calculates with CRC-32 to B6156AD7
"D7 6A 15 B6 B6 60 00 80 FF 04 00 00 00 10 00 AE" (02.05.02.00, second line)
The first four numbers look like the CRC-32, again.

Still..I don't know if the 5th number is another checksum, and the version format in the first line.

Maybe someone to play with this info, and figure out more details.

[A Hellene]

This is a newcomer from Hellas, as the screen name reveals. A grateful one, if I might add...

«Εύρηκα!» ("I have found (it)!"; "Eureka" is the English transliteration; from the verb «ευρίσκω», meaning "to find, find out").

«Εύρηκα!» exclaimed Archimedes (287-212 BCE), the ancient Greek scholar from Syracuse, the moment he noticed that the water level rose when he stepped into his bath, suddenly realising that the volume of water displaced had to be equal to the volume of the part of his body he had submerged into the water!
So, «Εύρηκα!» will be the exclamation I will borrow to express my triumphalism. Let me explain myself. I faced the v2.05 SP2 situation, also; and reading maze's excellent observation, above, about the CRC-32 checksum bytes within the header files, I decided to give it a go.

Analysing the headers (the first 21 bytes) of the three known 2.05.xx firmware revisions (yes, I did some digging), the format of the firmware header becomes more obvious, since a third different firmware header confirms maze's speculation. So, here is a summary and some thoughts:

Code: [Select]

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
---------------------------------------------------------------------------
    Fields: |<------ Std. header -------->|<-FW rev.->|<-?->|<- CRC32 ->|??|
---------------------------------------------------------------------------
v2.05.02.01: 44 53 31 30 30 30 45 20 20 20 __ __ __ __ __ __ __ __ __ __ __
---------------------------------------------------------------------------
  Byte(00..09) = Std. header = 0x44533130303045202020
  Byte(0A..0D) = FW rev. = 0x________
  Byte(0E..0F) = ? = 0x____
  Byte(13..10) = CRC-32(00..0F) = 0x________
  Byte(14)     = ?? = 0x__
So, we have five unknown values to figure out, in order to create a header version equal or grater to v2.05.02.01, to trigger a firmware update event. The unknown parts are four, actually, since the Bytes(00..09) are standard in all the firmware revisions.
Based on another observation, the four FW revision bytes could be just remapped to a non humanly readable format (unlike the ASCII string in the pre-v2.05 FW versions) and not necessarily be encrypted --even though the instrument has a number-crunching beast under the hood. Additionally, for backwards compatibility, the absolute hexadecimal value of the four FW revision bytes word should be greater than the corresponding value at any previous revisions.
Finally, since the other two figures at the header positions Byte(0E..0F) and Byte(14) do not seem to be something meaningful like CRC16/ CRC8/ product/ sum/ remainder/ etc., they could just be random values.
So, assuming that the firmware revision number bytes are correctly mapped (0x88 = '0', 0x84 = '1', 0x82 = '2' and 0x85 = '5'), I made the following experiment:

1. I set the <FW rev.> Bytes(0A..0D) equal to: [82 85 82 84], to reflect the desired target revision number: [2.5.2.1].
2. Since it is unknown what the Bytes(0E..0F) and Byte(14) represent, I copied them directly from the firmware header file v2.05.01.00, which are [C3 7B] and [7E] respectively. I think I could just add null bytes at these positions, though I am not sure that these locations can have random values.
3. I created the 2.05.02.01.header with the first 16 bytes of the <Std. header>.
4. I calculated the CRC32 checksum of the incomplete 2.05.02.01.header file, which is 0xE44834FF and reversed its byte order to: [FF 34 48 E4], as this seems to be the case at the original files, above.
5. I edited the 2.05.02.01.header file, adding the CRC32 reversed byte-order word, and also added the Byte(14) mentioned above, which is equal to [7E].
6. Done! the new header file's contents are:

Code: [Select]

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.02.01: 44 53 31 30 30 30 45 20 20 20 82 85 82 84 C3 7B FF 34 48 E4 7E
    Fields: |<------ Std. header -------->|<-FW rev.->|<-?->|<- CRC32 ->|??|
7. Finally, I created a <DS1000EUpdate.RGL> file by joining binary the new 2.05.02.01.header and the 2.02.02.00.rom files, using the following CMD (from darrylp):

Code: [Select]

copy /B 2.05.02.01.header + 2.02.02.00.rom DS1000EUpdate.RGL
The newly created <DS1000EUpdate.RGL> firmware file is v2.02 SP2 actually, which allows the user to change the model and the serial numbers to meet those of DS1052E, DS1102E or DS1152E, using Mechatrommer's (aka: shafri's) USB utility, and to be updated to v2.04 SP1 or even to v2.05 SP2, since it is easy and safe now to be reverting back to v2.02 SP2 over and over!


NOTE 1: I do not encourage anyone to experiment with their instruments' firmware and/or hardware; even though I have been 100% successful in my attempts I described. But, if anyone chooses to, I will strongly suggest them *NOT* to run "Auto-Calibration" on any HW58 models, while a firmware lower than the v2.04 SP1 is loaded.

NOTE 2*: Though I have successfully downgraded my scope's firmware from v2.05 SP2 to v2.02 SP2, changed the model to DS1152E and loaded the firmware v2.04 SP1, I finally chose to update it to v2.05 SP2 since I can undo this action at will, because I assume that v2.05 SP2 must have some improvements over the v2.04 SP1, along with the new "unhackable" format... But I do not really know that.
UPDATE: See: EDIT, 2011.05.14, below.

NOTE 3: I could have done nothing at all of the above, had I not been "standing on the shoulders of giants," meaning all these fine people that have worked and contributed to this project.
__________


A few additional thoughts: This is a dirt cheap and quite noisy oscilloscope --not to mention its audible fan. But, if (and when) I'll find some time, I will try to design a brand new hybrid PSU (a more flexible switching one with fast analog regulators at the outputs) to replace the original one, since the scope has not been measured to consume more than 25VA (NOT Watts!) from 230VAC. Because the PSU does not have a PFC stage (hence, 25VA != 25W) and the huge heatsinks of the linear regulators are getting really hot during operation (meaning that the PSU wastes lots of power), I think that the actual power requirements of the instrument could actually be as low as 10..15W only. But this can be accurately measured when I will decide to break the warranty seal.

This perspective opens the possibility to make the instrument portable, by using a rechargeable battery as an alternative power source, which could be recharged by the new PSU, too --even if this raises the design complexity... I guess that some people see the design challenges rather as a game than as a burden or a waste of time...

Last but not least, I should not forget to thank you all for your courtesy and the contribution to the wider community!


-George



[EDIT, 2011.04.21]: Spelling and additional information.

[EDIT, 2011.04.21]: 2.05.02.01.header file attached (and, of course, even more spelling corrected...)

Code: [Select]

2.05.02.01.header checksums:
CRC32: 719FAB26
MD5:   B058467F61FF6D62712A64B3F8E8D0F8
SHA-1: 54217AFA199A05BBFBC908CE71DD2039D7C1F78A
[EDIT, 2011.05.02]: 2.05 SP2 to 2.02 SP2 (v2.05.02.00 to v2.02.02.00) downgrade firmware attatched!
This is what I should have done in the first place, since I did not foresee the confusion I would stir by firstly posting the HEX string only and, right after that, attaching the *.header file alone... So, here is the whole deal!

Code: [Select]

DS1000EUpdate.RGL checksum & hashes:
CRC32: 0C2CE1E8
MD5:   F7C861576FE9EFEAF08C3E449F3527F0
SHA-1: EA262979BF58A5E758AC827BA187A67355959266
[EDIT, 2011.05.14]: (*) Some additional thoughts regarding my second note, above, about using the FW v2.02 SP2:
It has been reported some kind of screen flickering on the most recently purchased DS1052E's. Since all the firmware revisions after v2.04 SP1 and before 2.05 SP2 have been reported to be buggy (locking up the devices until reboot, under certain circumstances), 2.05 SP2 itself could also be a problematic piece of firmware that probably causes the flickering mentioned before.
Fortunately, screen flickering is reported to disappear when reverting back to FW v2.04 SP1.

[torch]

Boy, that's one hell of a first post!!!

Very nicely done. Only one possible improvement: you could attach the modified file and maybe tell us the MD5 checksum. 

I'm one of the lucky ones with an earlier firmware, but thanks for your contribution to this project. I look forward to seeing your proposed power supply.

I wonder if this thing could be battery operated?

[A Hellene]

Thank you very much, torch

What you asked for, is easy!
I will now edit my message to attach the header file.


Thanks, again,
-George

[fminne]

Hi George,
Congratulations on your work. You make a wish come true for a lot of DS1052E-owners.
With your input, I was able to make the software to "upgrade" the DS1052E from 5.02SP2 to 2.02SP2.
I add the software, so everyone can use it.
Thanks again for all the help from so many people on this forum!

Regards, Frank.

MD5-check: f7c861576fe9efeaf08c3e449f3527f0

[A Hellene]

You are welcome, Frank,

... and thank you, too!
-George

[joh]

Hi George,

I haven't tried it yet but I do so applaud your achievement.

Well done!!!

[Fraser]

Excellent work George.

I am fortunate to have a 2.04SP1 DS1052E but your message still makes facinating reading.
I applaud your achievement and community spirit. 

[A Hellene]

Thank you, joh!
Aurora, thank you, too!

But I did not do it all by myself; not at all! I just added my little piece to the bigger picture.


-George

[joh]

Hi George, you noted:
NOTE 2: Though I have successfully downgraded my scope's firmware from v2.05 SP2 to v2.02 SP2, changed the model to DS1152E and loaded the firmware v2.04 SP1, I finally chose to update it to v2.05 SP2 since I can undo this action at will, because I assume that v2.05 SP2 must have some improvements over the v2.04 SP1 along with the new "unhackable" format... But I do not really know that.

With you approach do you still retain the DS1152E functionality?

[A Hellene]

Oh, yes! Absolutely! Full functionality, no additional noise induced nor any offset, scaling error or mis-calibration; plus the 2.0ns/div timescale and the full 170MHz instrument bandwidth. But the main advantage is the ability to reload the patched v2.02 SP2 at any given time, to reconfigure everything from scratch!


-George

[torch]

I downloaded the file and using HashCalc, came up with an MD5 hash value of:
f7c861576fe9efeaf08c3e449f3527f0
Can you confirm that this is correct?

Checking the MD5 hash of the file before installing it is a good way to avoid bricking the scope by accidentally installing a corrupt firmware.

[A Hellene]

Just downloaded my uploaded file, which is the "2.05.02.01.header.zip"

Code: [Select]

"2.05.02.01.header.zip" file checksums:
CRC32: 32FF29996A
MD5:   DDFC582366294ABC2CBAC0DEC739C2FF
SHA-1: 4AC196839902AD850B2630FBBA7E3BB6205DB7E7

"2.05.02.01.header" file checksums:
CRC32: 719FAB26
MD5:   B058467F61FF6D62712A64B3F8E8D0F8
SHA-1: 54217AFA199A05BBFBC908CE71DD2039D7C1F78A


[EDIT] You can also open the *.header file with a hex editor and confirm that the file contents are the same to those at my first message:

Code: [Select]

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.02.01: 44 53 31 30 30 30 45 20 20 20 82 85 82 84 C3 7B FF 34 48 E4 7E
    Fields: |<------ Std. header -------->|<-FW rev.->|<-?->|<- CRC32 ->|??|

[nixxon]

2. Since it is unknown what the Bytes(0E..0F) and Byte(14) represent, I copied them directly from the firmware header file v2.05.01.00, which are [C3 7B] and [7E] respectively. I think I could just add null bytes at these positions, though I am not sure that these locations can have random values.

Nice progress, community and individuals

How likely is it that the 3 mentioned bytes (that were simply copied from the original firmware) may cause undesired or unknown effects?

I am waiting for my DS1052E from Dealextreme. They informed me a week ago that the item is shipped with FW 02.05 SP1. Even so, I guess it will have 02.05 SP2 as the other buyers write in their reviews. Because of some nice reverse engineering it seems I will be able to upgrade to "DS1102E" even if the scope should arrive with FW 02.05 SP2 

Nixxon

[Fraser]

Nixxon,

I believe the key challenge here was to 'trick' the DS1052E into entering firmware update mode. Once this was achieved and the modified 2.02SP1 firmware loaded to allow the upgrade to 100MHz, the DSO is returned to a known good and unmodified firmware (standard header). The issue of incorrect or unknown bytes in the header of the previous modified 2.02SP1 firmware becomes a moot point. As has been stated several times before, never auto-calibrate a HW58 DSO unless it is running a genuine 2.04SP1 or later firmware.

Rigol have concentrated on trying to prevent users getting the DSO into it's firmware update mode as that is it's Achillies heel for the purposes of hacking. Their header change is quite clever but where there is a will there is often a way, and this thread just proves it  

I never cease to be amazed at the knowledge that can be brought to bear on a challenge by this Forum.... I am an analogue world tech with just enough digital knowledge to stay out of trouble....hacking firmwares and reverse engineering such is beyond me. I salute those with such skills and all who have helped the techie community to extend the capability of this great value DSO.

[bhunting]

I have a scope with the 2.05 SP2 FW so I am going to try George's excellent hack. 

Once I've done the hack how do I get back to 2.05 SP2, or any other particular fw? 

Does anyone have a list of links to the various known good firmwares? 

Can I down load my present firmware out of the scope before the hack? 

I searched Rigol's site and did not see a link to latest firmwares.

thanks for all of the excellent and interesting work

[torch]

MD5:   B058467F61FF6D62712A64B3F8E8D0F8

I saw that and thought "Oh oh, they're different!" Then I realized your file is just the header alone, Frank's file is the entire firmware.

[joh]

Hi George,

Do you have the hash of the full file (header & code) that you actually upgraded your scope with. I would like to double check that everything is as you had it when I upgrade.

Best Regards, John.

[ed06]

f7c861576fe9efeaf08c3e449f3527f0

I just did it by putting the header on the 02.02SP2 firmware. The above is the MD5 of the file.

A few days ago received rigol with this firmware (00.02.05 SP2).
Problems seen with SP1 is not found.
Please give someone got upgraded to 1102 and details.

[joh]

Thanks George, that matches the value calculated by Torch for his file.

[joh]

ed06, have you taken a look at page 1 of this thread?

[joh]

Hi George, sorry to be a pain, fame has it price you now realise!

You note that I finally chose to update it to v2.05 SP2 since I can undo this .... May I asked where you obtained v2.05SP2?

John.

[fminne]

Hi Joh,

According to me, you can find the 2.05SP2 here: https://www.eevblog.com/forum/index.php?topic=553.msg31373#msg31373

Greetings, Frank.