Sniffing the Rigol's internal I2C bus

[anakron]

Just a kudos and rah rah for the DS2302 upgrade ... DS2072 scope just in, did as I was told and
here are two screenshots of a 150MHz signal with a 300MHz overtone.
One is taken with a Tektronix TDS3032B, which is born as a 300MHz scope - the other one
is taken with the DS2302 which appeared on my desk.

You will note that the TDS3032B actually dampens the 300MHz signal compared to the DS2302.
Both agree there is about 80mV on the BNC ... but the amplitude of the 300MHz on the Tek is smaller.

(DS2072  HW Ver2 scope)

A

[marmad]

To DS2000A model owners:

Did the DSO come with trial minutes on the options (as per the non-A models)? I assume it did, but I can't seem to locate any specific info online about it.

[JDubU]

To DS2000A model owners:

Did the DSO come with trial minutes on the options (as per the non-A models)? I assume it did, but I can't seem to locate any specific info online about it.

I'm not a DS2000A owner but take a look at the second image on this post:
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg336779/#msg336779

[marmad]

I'm not a DS2000A owner but take a look at the second image on this post:
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg336779/#msg336779

Thanks for the info, JDubU.

Now the next question would be, now that we know that the DS2000 FW is compatible across the entire line (DS2000 HW revisions 1/2 & DS2000A), have any A-model owners tried to just downgrade to v.01.01.00.02, use the keygen to enable options, then upgrade back to v.02.01.00.03?

Certainly I can't imagine it can harm their DSOs - since DS2000 HW v.2.0 and DS2000A models are (more or less) physically identical (except perhaps for some jumpers or setting pull-up resistors)  - and the older DSOs have no problem downgrading and upgrading through all the current (and former) FW versions..

[NikWing]

hmmm that partly answers my questions I guess
looks like it's being worked on

but nobody has the A-S version of the DSO yet?

[marmad]

but nobody has the A-S version of the DSO yet?

I've only seen people with DS1000Z-S models posting in the forum so far.

[JDubU]

Now the next question would be, now that we know that the DS2000 FW is compatible across the entire line (DS2000 HW revisions 1/2 & DS2000A), have any A-model owners tried to just downgrade to v.01.01.00.02, use the keygen to enable options, then upgrade back to v.02.01.00.03?

Certainly I can't imagine it can harm their DSOs - since DS2000 HW v.2.0 and DS2000A models are (more or less) physically identical (except perhaps for some jumpers or setting pull-up resistors)  - and the older DSOs have no problem downgrading and upgrading through all the current (and former) FW versions..

It seems like there must be something besides DS2000 HW v.2.0 plus FW v.02.01.00.03 that distinguishes a DS2000 from a DS2000A (jumper settings?).

The control for 50 ohm input termination that is available in hardware on the DS2000 HW v.2.0 and enabled by firmware v.02.01.00.03 on the DS2000A appears not to get enabled:
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg343230/#msg343230

[staze]

Or it's just based on serial number.  :/

[marmad]

Or it's just based on serial number.  :/

Whether the inability of the keygen to work with A-models with v.02 firmware is the result of the firmware - or - the serial number (or other data in NOR Flash) could likely be determined by:

DS2000A owner downgrading then running the keygen with v.01 firmware.
- or -
DS2000 owner upgrading (without enabled options) then running the keygen with v.02 firmware.

[Mark_O]

Now the next question would be, now that we know that the DS2000 FW is compatible across the entire line (DS2000 HW revisions 1/2 & DS2000A), have any A-model owners tried to just downgrade to v.01.01.00.02, use the keygen to enable options, then upgrade back to v.02.01.00.03?

Yes, that's the question I asked 16 days ago, and again 13 days ago:

If it is newer, then that may be the reason the existing hack keys aren't working for you.  If you reflashed back to v1102, then they might.  Since I don't believe the actual hardware in these is different than the Rev2.0 hardware in some older 2072-nonA models, the main firmware would be the first place to look for a hack block/key change (though it could be elsewhere).
--
If you can get ahold of a GEL file for your current software level, then you could try a downgrade to ver1.1.0.2 (may not allow it), run the previous hack, then upgrade back to v2.

Certainly I can't imagine it can harm their DSOs - since DS2000 HW v.2.0 and DS2000A models are (more or less) physically identical (except perhaps for some jumpers or setting pull-up resistors)  - and the older DSOs have no problem downgrading and upgrading through all the current (and former) FW versions.

Not permanently harm, but you pointed out some serious problems with saved option settings being relocated, and screwing up operation/causing lockups, when switching between the two firmwares.  That didn't sound like a pleasant situation.

[g***!]

DS2000 owner upgrading (without enabled options) then running the keygen with v.02 firmware.
[/quote]

Tried this a few minutes ago, successfully.

[marmad]

Yes, that's the question I asked 16 days ago, and again 13 days ago

Kudos for asking it back then, but it was before we had confirmation from a Rigol dealer that firmware was applicable across all DS2000 models (or a copy of the newest FW GEL file - which, BTW, was just released by Rigol 2 days ago). Trying to do it then would have been rather reckless - or at best, left the A owners unable to upgrade their DSOs again.

Not permanently harm, but you pointed out some serious problems with saved option settings being relocated, and screwing up operation/causing lockups, when switching between the two firmwares.  That didn't sound like a pleasant situation.

Not serious problems at all - they were easily resolved with reboots (or once by downgrading). The main problem (as far as I've noticed) is the change in saved WFM format.

Tried this a few minutes ago, successfully.

Thanks! So it seems likely keygen problems (for A owners) is due to serial number (or other NOR data).

[alank2]

They have changed the "A" firmware to make it more difficult.  If you scan the firmware, there are no keys in plaintext any longer.

[marmad]

They have changed the "A" firmware to make it more difficult.  If you scan the firmware, there are no keys in plaintext any longer.

What "A firmware" are you referring to? The recently released v.02.01.00.03? That is FW for both the non-A and A models alike.

[marmad]

Before the keygens or the ATtiny85 hack, the way that many of us owners were getting around the problem of expired options was by using a clock reset/self-cal exploit to restart the trial minutes.

If A-model owners are still unable to use existing keygens after downgrading, this might help them, at least until a permanent solution is found, to continue to have access to the various options. The technique is known to work for sure on FW versions <= v.01.00.00.03, but since the other hacks first started coming out around the time of the release of v.01.01.00.02, I'm not sure if it has ever been tested on that (or any later) version.

If this doesn't work on current versions (>= v.02), an A-model owner could then downgrade and run the technique again, but the question then arises as to whether the change to the structure of unit settings stored in FRAM would allow the trial minutes to be maintained when upgrading back to v.02.01.00.03. Certainly there is no harm in trying - worst case scenario is that trial minutes are lost when upgrading from a v.01 to a v.02 firmware.

Since I got an official key some time ago, it's been quite awhile since I used this technique myself. The latest versions of the technique that I post here are courtesy of forum member Wim13, who did many hours of testing on it. He may have a more updated version which he could post - I'll leave that to him.

The techniques (known to work in versions 00.01.00.02 -> 01.00.00.03 at a minimum) are as follows:

Manual:

Make sure System -> Startup is Default.
Set the clock to 2099, 31 Dec, and 23:58 hour.
Wait a few minutes for the clock to rollover past 00:00 (you can see it in the normal screen at the bottom right),
Put the clock back to the correct date and time.
Reboot
Wait at least 30 minutes for warm-up, then do a self-calibration.
After the scope is finished, it will reboot once.
Make sure System -> Startup is Default.

Then you just have to wait for awhile. The options will come back sometime when you boot up between ~3 to 60 hours later. You don't have to leave the DSO turned on  (you can just use it normally and turn if off when finished), but the best success for getting them back on the next boot-up seems to be if you leave the DSO turned on for another 3-4 hours after the self-cal.

By SCPI via LAN or USB:

:system:pon def
:system:date 2099,12,31
:system:time 23,58,30

Wait 10 minutes
:system:date?

[if date is 2011, then:]
:system:date [whatever the current date is]
:system:time [whatever the current time is]
:system:reset
Reconnect LAN/USB

Wait 30 minutes to warm-up
:calibrate:start
Reconnect LAN/USB (lost connection after reboot)

:system:pon def
Then loop for every hour or so,
:system:reset
Reconnect LAN/USB

According to Wim13, using this technique restarted his options on the 4th reset with 2158 minutes.
Total time from first reset to recovery of options: 270 minutes.

[cybernet]

currently no time to play with the new firmware but what would be good to know is:

does a fully (DSAZ..) unlocked DS2000 (official fw) keep its features on upgrade to latest fw ?
does it "enable" the CAN ? (if DSAZ was used) - my guess is now, as its only evaluated written to NV during key apply.
is downgrading possible or not (on old DS2000's) ? (after latest  fw was flashed) - i didnt see downgrade checks in the old bootldr.

there are no plaintext keys anymore in code - and the GEL format slightly changed (last block has invalid CRC, but only 64 bytes and thus ignored by bootldr update as far as i can tell)
anyhow, i will flash it probably over the xmas holidays - and see what i can find.

the pros are:
* the bootldr on the DS2000 does have no crypto stuff. i suspect the 64 bytes in the end could be a 512bit signing key for the FW for newer bootloaders.
* the "old" bootldr doesnt use the DS2000Update.GEL to update the bootldr itself, thats done via another filename. so they have a hard time rolling out secure updates to the old devices bootldrs (imho !)
   that basically means, whatever they throw at the old devices can be modified, reassembled into a GEL and flashed.
   that goes for model string, type and CAN bus options
* i still saw MIRACL function calls in there, but the structure on the keychecks has changed so it could take some time to find out what they've done.

somebody with JTAG should dump the new bootldr to check if they've gone for signatures

[marmad]

does a fully (DSAZ..) unlocked DS2000 (official fw) keep its features on upgrade to latest fw ?

Mine does (with official options key). Member g***! upgraded - then used the keygen to unlock his DSO while running v.2.

does it "enable" the CAN ? (if DSAZ was used) - my guess is now, as its only evaluated written to NV during key apply.

No one that's upgraded has reported seeing the CAN option appear - perhaps g***! can report if it showed up after entering the code when already running v.2.

is downgrading possible or not (on old DS2000's) ? (after latest  fw was flashed) - i didnt see downgrade checks in the old bootldr.

I've done it many times already - upgrading and downgrading. It works fine as long as you hold in Left-F6 (to clear FRAM) during the first boot after going from v.1 to v.2 or vice-versa.

[alank2]

somebody with JTAG should dump the new bootldr to check if they've gone for signatures

Has someone dumped the old bootldr yet so it can be analyzed?  Any link to this?

[marmad]

does it "enable" the CAN ? (if DSAZ was used) - my guess is now, as its only evaluated written to NV during key apply.

I scoured for information, but there is no actual evidence that the CAN option is (or ever will be) available for non-A models except this line of text at Tequipment, "CAN trigger and decode for DS2000 and DS2000A" - but that text is nowhere else to be found online (and likely a mistake).

In fact, the part number (CAN-DS2000A) tends to indicate that it is, in fact, an A-model only option.

[fcab100]

currently no time to play with the new firmware but what would be good to know is:

does a fully (DSAZ..) unlocked DS2000 (official fw) keep its features on upgrade to latest fw ?
does it "enable" the CAN ? (if DSAZ was used) - my guess is now, as its only evaluated written to NV during key apply.
is downgrading possible or not (on old DS2000's) ? (after latest  fw was flashed) - i didnt see downgrade checks in the old bootldr.

there are no plaintext keys anymore in code - and the GEL format slightly changed (last block has invalid CRC, but only 64 bytes and thus ignored by bootldr update as far as i can tell)
anyhow, i will flash it probably over the xmas holidays - and see what i can find.

the pros are:
* the bootldr on the DS2000 does have no crypto stuff. i suspect the 64 bytes in the end could be a 512bit signing key for the FW for newer bootloaders.
* the "old" bootldr doesnt use the DS2000Update.GEL to update the bootldr itself, thats done via another filename. so they have a hard time rolling out secure updates to the old devices bootldrs (imho !)
   that basically means, whatever they throw at the old devices can be modified, reassembled into a GEL and flashed.
   that goes for model string, type and CAN bus options
* i still saw MIRACL function calls in there, but the structure on the keychecks has changed so it could take some time to find out what they've done.

somebody with JTAG should dump the new bootldr to check if they've gone for signatures

cybernet I went straight from your DS2302 hack fw to the most recent fw (have a ds2072 scope) and the DS2302 name stuck but not 300Mhz only 20Mhz & 100Mhz are there. I was however able to use the key gen to install all options and uninstall them at will. Now that i think about it no can decoding or 50ohm terminator.

I got my DS2072 About 2.5 weeks ago it's Version 2.0 hardware.

Thanks to everyone for your great work so far with hacking this scope.


EDIT:

I do have 1ns TB. With channel 2 on it does not seem to have that weird offset anymore.

[zombie28]

there are no plaintext keys anymore in code - and the GEL format slightly changed

The ECC parameters are still the same, but they are hidden as binary data, encoded with bit shuffling algorithm. The newest firmwares of DP832 and DS2K both contain the following sequences of bytes (in little-endian order):

1F A8 BD F4 B8 C9 55 45
29 B5 66 E6 B8 C9 55 45
93 86 33 C4 88 6A 54 05

which are encoded form of the well known ASCII-HEX strings, respectively:

"AEBF94CEE3E707"
"AEBF94D5C6AA71"
"7A3E808599A525"

Here is unshuffling algorithm that I found in DP832 firmware (each DWORD is being processed separately):

Code: [Select]

DWORD Unshuffle(DWORD x)
{
    x = (x & 0x22222222) << 1 | (x >> 1) & 0x22222222 | x & 0x99999999;
    x = (x & 0x0C0C0C0C) << 2 | (x >> 2) & 0x0C0C0C0C | x & 0xC3C3C3C3;
    x = (x & 0x00F000F0) << 4 | (x >> 4) & 0x00F000F0 | x & 0xF00FF00F;
    x = (x & 0x0000FF00) << 8 | (x >> 8) & 0x0000FF00 | x & 0xFF0000FF;
    return x;
}

In DS2K firmware, just before aforementioned sequences of bytes, you can also find elliptic curve parameters A and B, encoded as big-endian WORDs:
29 82 00 00
34 08 00 00

In DP832 firmware these A and B values are hardcoded directly into a call to mirvar function (during ECC initialization phase).

[cybernet]

very nice find, didnt bother to change the ECC parameters, funny.
i wonder how to enable CAN at the DS2000(A) then ...
did somebody with a DS2000A already try the keygen ? shouldnt fail if the ECC params are the same - unless they changed the hash, and meaning of it.

[zombie28]

very nice find, didnt bother to change the ECC parameters, funny.
i wonder how to enable CAN at the DS2000(A) then ...
did somebody with a DS2000A already try the keygen ? shouldnt fail if the ECC params are the same - unless they changed the hash, and meaning of it.

I didn't find the public key yet, but I expect that Rigol changed it (some people were reporting, that keygen doesn't work for new firmware).

[marmad]

I didn't find the public key yet, but I expect that Rigol changed it (some people were reporting, that keygen doesn't work for new firmware).

People with A-models were reporting that keygen doesn't work with the new firmware, but g***! (with a non-A model) reported that it worked for him.

[zombie28]

People with A-models were reporting that keygen doesn't work with the new firmware, but g***! (with a non-A model) reported that it worked for him.

And now I know why - Rigol didn't bother to change the public key either. I found the old public key in the new firmware (encoded by the same bit shuffling algorithm I described earlier). The sequence of encoded bytes is as follows: 97 58 B9 DE 24 C5 11 10, which obviously translates to "8445B2BE29E5C7". I believe Rigol didn't change the keys to maintain backward compatibility with previously sold license codes. Alternatively they may use two separate keys for 'non-A' and 'A' license codes.