I used to own an all-transistor, single channel 10 MHz analog oscilloscope. While it was not adequate by nowadays standard, it served me quite well for many years. The scope was later sold and I had been thinking about getting a new oscilloscope for quite a while. This time around though, I wanted to get a digital storage oscilloscope (DSO) since in many cases, it is a lot more convenient to use. After reading about some rave reviews on Dave Jone’s EEVBlog about this Rigol DS1052E scope, it became apparent that this would be the ideal scope for my workshop. So without much hesitation, I ordered one.

Of course, as many people have already known, this scope is known not only for its build quality and versatility but for its hack-ability as well. In many cases this scope’s 50Mhz bandwidth can be changed to 100Mhz without too much effort. For those who do not know, here is a little bit of the history:

It all started sometime in early Feburary when someone with a screen name of rossmofett posted a simple hardware based hack on EEVBlog. Since then there have been a lot of discussions on how to modify this scope to unlock its bandwidth potentials. But it was not until the software based hack came out before it was easy enough for anyone who was interested to perform such hack. The software based modification may have started from this thread, but the first one who had successfully upgraded his scope using pure software method goes with the screen name JimBeam sometime in mid March, and since then we have seen several modified and improved methods.

Apparently, Rigol has known about this hack for a while and had released several firmware revisions trying to stop the hacking. But so far, the firmware updates has not been able to totally stop the hack but only managed to make it more difficult.

In any event, the scope I ordered came with firmware version If you read through the postings on EEVBlog, you will know that after firmware version 02.02.SP2, the commands used for changing the firmware version and the serial number had been disabled at the firmware level and the solution was to downgrade the firmware first and then change the version settings. Rigol later ( and higher) disabled the ability to downgrade to lower firmware versions altogether. But this problem is only superficial since the version check is performed against a fixed clear text string stored in the firmware, chaning the version string to something higher (say would solve the firmware downgrade issue.

The steps I took are largely the same compared to what forum user polossatik had detailed on the EEVBlog site, except I elaborated on a few steps and steps mentioned here are more geared towards this specific firmware version ( I have on hand. As has been discussed in other forums, this particular hacking method is only confirmed to work for firmware versions and below, and for hardware version 57 and below. There maybe some issues with the latest firmware version and hardware version 58 and the issues may have resulted from a hardware change but I have not seen any confirmations on this. Also keep in mind that there is no guarantee that the suggested hack would work in every scenario and performing such a hack voids Rigol’s warranty.

So unless you are comfortable with the method mentioned below and understand the ramifications of the hack, I would recommend you not to proceed.

The Steps

Before we continue, I would recommend that you read through the forum entries on the EEVBlog, where they are updated on a regular basis as more information emerge. I would also recommend watching Dave’s video so that you are more familiar with the concepts and general procedures. Without further due, let’s take a look at the steps.

1. Prior to performing the hack, check to make sure that the firmware version is at or below and the hardware version is 57 or lower.

This information can be obtained by press the following keys in sequence while at the system information screen (CH1 twice, CH2 twice and then MATH. Do not touch any other buttons as it was reported that some system information can be changed if other buttons are pressed in this mode). Or you can obtain this information by issuing the *IDN? command in the serial console (pick your favorite one, GtkTerm and cutecom are pretty good to use under Linux, and if you are using Windows, the default Hyper terminal should be sufficient).

If you do not have a serial port or serial/USB adapter, you can use the USB method mentioned in polossatik’s instructions by installing National Instrument’s VISA runtime engine. I have tried both methods and either one should work. While some claims that the USB method is safer, the fact is that both methods are pretty much the same (except when you are using the Windows Hyper terminal where the commands are sent in real time) and the same caution needs to be taken to prevent any mistakes.

Also, you may want to plug the scope into a UPS to prevent possible power interruptions during the firmware flashing. Most of the firmware failures (including computer BIOSes) during upgrades are due to some kind of power events and could be easily prevented by taking some precautions.

2. Cycle the power (turn it off and then on again) to ensure that the system is in a well known state. While this may not be totally necessary, it is suggested since we are dealing with software here after all and not all software is well tested for all situations. It is always a good idea to bring the system to a well known state before performing unfamiliar tasks to avoid running into untested bugs.

3. Load a USB memory stick with 02.02.SP2 firmware (with the version number modified to or higher) and plug into the USB port on the scope.

As of this writing, the 2.02.SP2 firmware is still available on Rigol’s website. After downloading, it is strongly recommended that you check the file integrity. The original SP2’s MD5 Hash (use md5sum command under Linux) is 272086b2037231c62446617436544a77.

The patch provided by polossatik simply changed the version number from to (see below)

The original firmware:

00000000  44 53 31 30 30 30 45 20  20 20 30 32 2e 30 32 2e  |DS1000E   02.02.|
00000010  30 32 2e 30 30 60 00 80  ff 04 00 00 00 10 00 ae  |02.00`..........|
00000020  00 00 00 00 80 a0 ff 98  00 00 00 00 00 66 01 67  |.............f.g|
Patched firmware:

00000000  44 53 31 30 30 30 45 20  20 20 30 32 2e 30 34 2e  |DS1000E   02.04.|
00000010  30 32 2e 30 30 60 00 80  ff 04 00 00 00 10 00 ae  |02.00`..........|
00000020  00 00 00 00 80 a0 ff 98  00 00 00 00 00 66 01 67  |.............f.g|

And if your SP2 firmware is patched as above, the MD5 hash should be 8cd4e61ce6128b55ab18fc83fa756e34. But in general, you should be able to downgrade from to any version that begins with 02.04.

The scope should recognize the USB device and when prompted, you can press the button to upgrade the firmware. Since this is the riskiest part of the whole process, you need to be absolutely certain about the version and the integrity of the firmware loaded onto the memory stick.

This process takes about two minutes and do nottouch the scope when it is re-flashing the firmware. Don’t touch the scope while the firmware is being upgraded, the environmental EM interference could also cause firmware corruption problems. When the process is done, you should see a message box indicating that the update has been successful.

4. Cycle the power again after the 02.02.SP2 firmware has been installed. The system info page should confirm that you have the 02.02 version of the firmware. should something go wrong in step 3, don’t turn off the power. As you maynot be able to start the scope again. But you may be able to reflash the content if you have to.

5. After you have downgraded to 02.02.SP2, you can use the the following commands via either a serial console or the USB program as mentioned in polossatik’s post.

:INFO:SERIAL DS1EB000000000 (put your actual serial number instead of 000000000)

Note that the original serial number begins with DS1ED and the new serial number is largely identical except it begins with DS1EB. If you have a hardware serial port and are comfortable with serial terminals, then you can just follow Dave’s video to do this. A good terminal program might make the process easier. If you don’t have a serial port, you could either use a USB-Serial adapter or use the USB based method mentioned in the EEVBlog I referenced earlier. Whichever way you chose, the idea is the same. The first INFO command sets the model number to 1102e and next one changes the serial number to be consistent with the model number.

6. Cycle the power again to see if you have successfully modified the scope. You can verify this by probing a fast rising signal if you have a signal generator, or you could simply just try to set the horizontal time limit to see if you could reach 2ns. Don’t calibrate the scope just yet, as now you are running on a different version of the firmware.

7. If everything went as planned, it is then time to upgrade the firmware back to the original version. This is similar to step 3 and the same precautions apply.

8. Power off and then power on the scope, you should be back to firmware version, except this time the model number has been changed to 1102e. You should now do a calibration (after the scope has been on for more than 30 minutes).

Here is a picture I took after the successful hack showing the system information:

System Information
System Information

And this picture shows a bit more information (press CH1 twice, CH2 twice and then MATH):

System Information (Detailed)
System Information (Detailed)

The following pictures give you an idea what the improvement you can expect from this modification.

109MHz Carrier (Before)
109MHz Carrier (After)

109MHz Carrier
109MHz Carrier

The first screenshot shows a RC oscillator at roughly 109MHz using the unmodified scope (the RC oscillator is not very stable and tend to drift quite a bit as you can see from the frequency measured). And the latter two show the same signal viewed on the modified scope. As you can see in the second and the third screenshot, the attenuation improved significantly and you can zoom in much further due to the improved 2ns horizontal limit.

And those are pretty much the steps you would need to take to change your 1052e to a 1102e. One important thing to remember is to double check the firmware version prior to upgrading and in case step 3 or step 7 fails, do not turn off the oscilloscope. Keep it powered on until you have a thorough understanding of what went wrong and you maybe able to re-flash the current firmware version when the scope is still up and running. Once you powered the scope off with incorrect or corrupted firmware on it, you will not be able to power up again unless you have the equipment to re-program the memory chip via the JTAG interface.


So from the information available so far, we can infer how that Rigol might have organized the none-volatile memory in 1052e. A simplified view of the memory organization may look like this:

None-Volatile Memory Layout
None-Volatile Memory Layout

This hack is possible because the version and calibration information are stored separately, presumably to make it easier for Rigol to decide which scope is badged for which version. And the reason I said in step 3 not to re-calibrate under a different firmware version is because there might be a difference in how the calibration data is handled under different versions and doing a calibration under the wrong version could corrupt the calibration data.

As long as the hardware remains the same, it would be very difficult for Rigol to prevent similar modifications, even with updated firmware. There are a few methods Rigol can employee to make future hacking more difficult. One such methods is to employee some additional information to identify the version number. For instance, a hash algorithm can be applied to the code section, and since the code from different firmware versions have different hash values, hash values can be checked to identify the version number. If this method is used, we would not be able to simply change the version number to downgrade the firmware. Another way Rigol could take is to use some kind of version dependent signature in the calibration data region and would only boot when the signature information matches the firmware version. This information can be further encrypted to make hacking even harder. But it may not be in Rigol’s best interests to go with either route as it would increase the complexity of the software significantly and making firmware compatibility testing a nightmare and may even cut into its bottom line due to the increased cost in R&D and possibly in support.

Of course, for the general users there is a point of diminishing return as the methods used increase in complexity due to the reasons mentioned above. But for those dedicated hackers, it would only be a matter of when and not if.

Be Sociable, Share!