Sniffing the Rigol's internal I2C bus

[geo999]

Hi guys,

I got myself a DSO1074Z-plus thinking the upgrade to 100Mhz is as easy as for DS1054Z.
After introducing the wrong serial codes for a few times I ended up on this page reading tens of pages.

I also did a :SYSTem:OPTion:UNINSTall such that now I'm left without any option that came preinstalled.

In the end the rigol seal lasted for less than 4 hours since it got into my possession .

I hooked up the Olimex-JTAG/OpenOCD and did a dump of the memory.
I double checked that the dump is correct by doing a second dump and comparing md5sums.
The dump was done after the scope completed booting - ready to work.

now for the fun part,
I tried different rigup versions with different results, none of them providing valid keys.


rigup-0.4.zip:

    scan:
        RC5KEY1:        xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        RC5KEY2:        xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        XXTEAKEY:      xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        PUBKEY:         xxxxxxxxxxxxxxxx
        PRIVKEY:        xxxxxxxxxxxxxxxx
    --> SERIAL: this line is not present in the output of the scan command,
    even if I can find the serial in the dump with grep.

    the search command crashes with a segfault.
    after a little debugging it turns out that this is due to the missing SERIAL like in the scan output.
    after adding manually the SERIAL line entry with the serial from the label on the back of the scope the output of search command is:
   
        6 lines with serial numbers all failed
        xxxxxxx-xxxxxxx-xxxxxxx-xxxxxxx                        Failed.

rigup-0.4.1-mso1000z.zip:
    failed: No keys

rigup-0.4.2.zip:
    failed: No keys
   

rig-up from https://www.dropbox.com/sh/1yrh8s90ityn90s/AAA6PXlJk9gGQwoDOwO6TDQua?dl=0,
    failed: No keys

DS1074Z plus
00.04.04.SP4
00.04.04.04.03
Board: 2.1.4

labels on the board:
DS1000Z_MAINBRD_V01.04_20141024
Hardware Version: V[654][32].[10]
SP Version: [987]

a firmware update attempt it's saying that it's already at the same version.
   
question is: what I'm doing wrong here ?
- do I need to do a dump at a different stage ?
- do I need a different rigup tool version ?

later edit:
the serial number starts with: DS1ZC
rigup, compiled on Linux x86-64

thank you

[KK1L]

Hi GEO999,

I would not be surprised if Rigol support wouldn't send you the code to open up the options they now ship with these rigs. It is worth a shot! Tech Support under "Support" on rigolna.com...worked for me!

You have gotten further than me with the memory dump. I think I am going have to buy an ARM ready debugger (like the Olimex) to get past my timeout issue. There is a post maybe in this quite expansive thread where there were a pair of leading zeroes in the keys which needed to be removed. I do not recall if this was automatically handled in rigup.

https://www.eevblog.com/forum/testgear/sniffing-the-rigol_s-internal-i2c-bus/msg3361424/#msg3361424 

[KK1L]

Some success, but ultimately a failure still

I had reported on trouble using the SiSpeed debugger. I ended up buying an Olimex ARM-USB-TINY-H. It is great and worked well the first time...6MHz, 1MHz, whatever. Far superior to the SiSpeed in this application.

That being said...despite getting a clean 64k memory dump I have been unsuccessful finding keys in the file....until!

So it is not exactly true that the DS1074Z-Plus is the same as an MSO1074Z. The signature to find the keys in the binary dump file are the SAME as the DS1074Z. So you need to run the unmodified rigup code to pull out the keys! MSO1000Z look for "01 00 84 00 10 00". DS1000Z look for "02 00 84 00 10 00".

Bottom line is the 1074Z-Plus is a hybrid of sorts. You must use JTAG to pull the memory file, but must use the DS1000 family rigup to pull the keys out!
I used version 0.4 from http://gotroot.ca/rigol...specifically rigup-0.4.zip. However the serial number is in the format of the MSO, so rigup will not extract the serial from the DS1074Z-S Plus. You need to add that with the "serial" option of rigup.

Code: [Select]

./rigup scan keyfile.txt ds1074z-plus.bin
./rigup serial keyfile.txt <your serial number>
./rigup license keyfile.txt DSEA 0x1c0ff 0x1c080You can direct the output of the license generation to a file if you like.

1st keyfile looks like this:
RC5KEY1:        72A369AC1CzipitydodaB9E27EAF0513
RC5KEY2:        582A21C677zipitydodaA302642B08E8
XXTEAKEY:       D07D6B66E6zipitydodaAA551326D9DE
PUBKEY:         005zipitydoda230
PRIVKEY:        009zipitydoda8D0

2nd keyfile looks like this:
RC5KEY1:        72A369AC1CzipitydodaB9E27EAF0513
RC5KEY2:        582A21C677zipitydodaA302642B08E8
XXTEAKEY:       D07D6B66E6zipitydodaAA551326D9DE
PUBKEY:         005zipitydoda230
PRIVKEY:        009zipitydoda8D0
SERIAL:         DS1ZD21xxxxxxx

Okay, so great. Now I have the key file. The bummer is no mater how I generate a license code it will not unlock 100MHz on my DS1074Z-S Plus.
I tried rigup with options DSEA (DS version) and 0x1c080 (MSO version). I tried riglol for grins with the extracted private code. I tried substituting the 16 nibble sequences I found in the memory dump binary just before the serial number into the private key and trying the above again. All no joy.

When I first purchased the scope on clearance from Rigol they gave me the code to unlock the options, and I asked about paying for an upgrade to 100MHz. The rep told me it could not me upgraded. Maybe he really meant it.

I was going to modify the rigup code to work for the DS Plus version, but since the keys don't work anyway it would be pointless. If someone has a clue for me to I will give it a shot.

DS1074Z plus
00.04.04.SP4
00.04.04.04.03
Board: 6.1.4

Board markings look suspiciously like BS...
Hardware Version: [654][32].[10]
SP Version [987]


P.S. At least I am loving my encoder knob upgrade !

[KK1L]

Ok folks with help and some hints from a friendly PM from tv84 the issue is sorted.

The bottom line is the rigup versions from gotroot.ca do not work. I tried all of them (windows exe). The one below does. Funky output for the "search" option when including the dump file, but shows the "ok." for the known good license in my memory dump. It creates the correct unlock code!

http://i-hobby.org/blog/Electronics/60.html

Be sure of the option code used. 0x1C0DF is what I used to open all up except 500uV.

(CSAR = 0x1C001) Triggers
(CSAB = 0x1C002) Decoders
(CSA3 = 0x1C004) Mem-depth
(CSAJ = 0x1C008) Recorder
(CSAS = 0x1C010) DG
(CSRA = 0x1C020) 500uV
(CSBA = 0x1C040) Power Ana.
(CS3A = 0x1C080) Bandwidth (100MHz)
(CSHY = 0x1C0FF) All
(CSGY = 0x1C0DF) All except 500uV

I should have noticed it before, but there is a bit set for each option. You should be able to mix and match. I did an :uninst, then :inst 0x1C0DF and got all but 500uV. Sweet.

[RoGeorge]

Why not enabling the 500uV/div, too?

It won't hurt the scope.  After enabling all the options run a self calibration (from the oscilloscope's menu Utility -> Self-Cal).  And if you decide you don't like the 500uV option, all the options can be removed with the SCPI command ":SYSTem:OPTion:UNINSTall", then re-installed with only the options you like as many times as you want. (the codes doesn't change, you can use the SCPI command ":SYSTem:OPTion:INSTall <license>")

Just FYI, the 500uV/div works very well in my former DS1054Z.
Some are saying in their DS1000Z the trace is out of screen after Self-Cal, or something, therefore religiously advocate that no one should ever dare to enable the 500uV, because "problems", and "useless".   

I found the 500uV/div range very useful when using the oscilloscope as a synchronous detector or as a lock-in amplifier, to measure very small synchronous and repetitive signals, with the oscilloscope's Acquire mode set to (trace) Average mode.

Any internal noise of the DS1054Z (and DS1000Z it is very noisy indeed in its analog front end) doesn't matter when the scope is in Average mode.  Noise averages to zero, so any asynchronous noise(either from the internals of the DS1000Z or from the device under test) will fade out and only the measured signal will remain, with a crisp clean trace on the display.

[KK1L]

Thanks. I have disabled it based on comments of others. Averaging works in many applications to let the true signal show itself.

Yes you are totally correct that it is super easy to enable or disable features via SCPI commands. You can do it with a single :INST command if you formulate the option code correctly. I will put it back to give it a whirl....why not

By the way what is the Power Ana. option?

[colabri]

With the above setting, I was able to dump 1MB flash content.

I was confused by the design.
BF526 supports up to 4 async banks with each has 1MB address. That will only be able to provide 4 MB address in total.
However, they uses a 8 MB flash. Is the reset of the space used by FPGA?

Also, as I mentioned, if A21 ~ A19 are hard coded with 110, BF526 will only be able to access 1MB flash space in this case.
And the size of DSA800_UpdateFile.sys (firmware) is nearly 2.x MB. I believe that A21 ~ A19 must be connect to BF526 in some ways.
Or it won't be able to program the whole content of the firmware update into the flash chip.

Thanks for the information. Since Rigol doesn't provide a built-in backup function and has disabled reading the flash via SCPI I had to resort to reading it via JTAG. Took me a while to figure out the bank switching method but it was an interesting exercise.

There's some component (the ASIC perhaps?) mapped to async mem bank 3, with the relevant functionality starting at offset 0x200 bytes / 0x100 half-words (bus width is 16 bit). For reading flash content via JTAG, the following sequence is sufficient:

• write 0x0000 to address 0x20300202 (only needed once)
• write bank number (0x0000 .. 0x0003) to address 0x20300206
• write 0x0001 to address 0x20300204

E.g. with urjtag (using a BusBlaster for this example):

Code: [Select]

cable KT-LINK pid=0x6010 vid=0x0403 interface=0
frequency 10000000
detect
initbus bf52x
poke 0x20300202 0
poke 0x20300206 0
poke 0x20300204 1
readmem 0x20000000 0x00100000 rigol_dsa815-flash-bank_0.img
poke 0x20300206 1
poke 0x20300204 1
readmem 0x20000000 0x00100000 rigol_dsa815-flash-bank_1.img
poke 0x20300206 2
poke 0x20300204 1
readmem 0x20000000 0x00100000 rigol_dsa815-flash-bank_2.img
poke 0x20300206 3
poke 0x20300204 1
readmem 0x20000000 0x00100000 rigol_dsa815-flash-bank_3.img

I wasn't able to send commands to the flash (which is also why urjtag cannot auto-detect the flash); my guess is that the same component that's handling the bank switching is keeping WE# high by default. The firmware does a lot more writes to async mem bank 3; I haven't tried figuring out which one enables "write" access to the flash.

HTH.

[davorin]

Good afternoon (o;

Just received my DS1074Z Plus today....and after powering up and listing the options I see that all options show as version "Official"....

So does this mean there isn't anything left I can unlock on this scope?
Or what options are left for this scope to add? Only the 100MHz bandwidth?


thanks in advance
richard

[hammy]

Or what options are left for this scope to add? Only the 100MHz bandwidth?

Exactly. That's the only option missing.

[davorin]

Hmm..no luck with J-Link and openocd on Debian linux:

Code: [Select]

me@blender:~/develop/openocd$ sudo openocd -d1  -f  interface/jlink.cfg -c "transport select jtag" -c "adapter speed 6000" -f target/imx28.cfg
Open On-Chip Debugger 0.11.0+dev-00179-g4e872a797-dirty (2021-05-26-11:07)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 1

jtag
adapter speed: 6000 kHz

dcc downloads are enabled

Error: JTAG scan chain interrogation failed: all zeroes
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: imx28.cpu: IR capture error; saw 0x00 not 0x01
Warn : Bypassing JTAG setup events due to errors
Error: unknown EmbeddedICE version (comms ctrl: 0x00000000)


[davorin]

Stupid me (o;

J-Link IO buffers are powered from the Vtarget pin ;-)

Okay..memory dumped...modified src/utils.c for MSO key search and remove the LD option in Makefile as on Debian 10.9 it would always core dump (o;

Installing license via SCPI didn't work...but on the scope it did ;-)

Had to use the serial number returned from *IDN? SCPI command....now I got before and afte without power-cycler:

Code: [Select]

IDN?
RIGOL TECHNOLOGIES,DS1074Z Plus,DS1ZC223303310,00.04.04.SP4
*IDN?
RIGOL TECHNOLOGIES,DS1104Z Plus,DS1ZC223303310,00.04.04.SP4


[ve7xen]

Ok folks with help and some hints from a friendly PM from tv84 the issue is sorted.

The bottom line is the rigup versions from gotroot.ca do not work. I tried all of them (windows exe). The one below does. Funky output for the "search" option when including the dump file, but shows the "ok." for the known good license in my memory dump. It creates the correct unlock code!

http://i-hobby.org/blog/Electronics/60.html

Be sure of the option code used. 0x1C0DF is what I used to open all up except 500uV.

(CSAR = 0x1C001) Triggers
(CSAB = 0x1C002) Decoders
(CSA3 = 0x1C004) Mem-depth
(CSAJ = 0x1C008) Recorder
(CSAS = 0x1C010) DG
(CSRA = 0x1C020) 500uV
(CSBA = 0x1C040) Power Ana.
(CS3A = 0x1C080) Bandwidth (100MHz)
(CSHY = 0x1C0FF) All
(CSGY = 0x1C0DF) All except 500uV

I should have noticed it before, but there is a bit set for each option. You should be able to mix and match. I did an :uninst, then :inst 0x1C0DF and got all but 500uV. Sweet.

Edit: I have reviewed the source code in the i-Hobby zipfile and concluded there isn't any substantive difference (just some standard-C-to-Windows-isms and the like), so either the provided binary doesn't match the source, or there is something wrong/different between the two builds.

Would you be willing to PM me your dumpfile/serial and the working output? I would like to investigate.

In the meantime, I have added the i-Hobby zipfile to the gotroot.ca archive.

[tv84]

I've said this in the past: due to its evolution history, rigup has some coding problems (possibility of buffer overflows, vars not properly freed up, some vars assignments, etc, etc) that require a complete revision of the code. Due to its age and potential targets, it seems that is not an appealing task.

Due to these deficiencies one needs to have "some luck" with the compiling setup (OS, architecture, compiler, etc.) and the running environment.

[rteodor]

Took me a while to figure out the bank switching method but it was an interesting exercise.

I want to do a backup before updating a buggy firmware on a bit different oscilloscope. Only the dump from the first bank came out properly (https://www.eevblog.com/forum/testgear/old-firmware-for-siglent-based-axiomet-oscilloscope/msg4020166/#msg4020166).

I tried to switch to the second bank with your steps. Fortunately nothing bad happened but unfortunately there was no switch.

It may be that the registers are different and right now I have no idea on how to figure them out.
Can you detail a bit on how you figured out the bank switching ?

[s1ic3r]

hello-
I'm getting setup to enable options on my mso1104z, i'm using a seggar j-link programmer with which i'm not all that farmiliar with yet but thanks to this awesome thread I believe i've got most of my ducks in a row.

As I was making my connections j-link-->scope I noticed that the j-link target supply pin is 5V, however the jtag interface on the scope is 3v3/ref, I notice numerous others have used the j-link as well, do I need to use a level shifter? Ive poked around a fair amount of this thread and don't recall any mention of using a level shifter. Not knowing any different i'd have to assume  the 3v3/ref  pin is not 5v tolerant.

I understand this aspect of the scope hack isn't rocket science but im' curious how others worked around this?

thanks

 

[s1ic3r]

Yet another succesful MSO1104Z all options magically turned official hack, i'll take maybe about 4% of the credit. Thank-You, Thank-You, Thank-You for all the hours of work everyone put into this project, you guys enabled a 70+ year old that can't remember what he had for breakfast to (eventually, with the help of a voltage divider, lol) get some extra functionality out of a my scope.

Turns out for some of us it really is rocket science!

Thanks Again

EDIT for a recap, wall of text.


equipment:        mso1104z
firmware:          00.04.04.SP4
board version:   6.1.1

openocd-0.10.0   
Openocd for Windows:https://freddiechopin.info/en/download/category/4-openocd
 
rigup-0.4.1-mso1000z
thanks to ve7xen for hosting rigup tool from here: https://gotroot.ca/rigol/

For a step by step check out smgvbest's excellent post here.

Resources

Main Thread
https://www.eevblog.com/forum/testgear/sniffing-the-rigol_s-internal-i2c-bus/msg233647/#msg233647
Specific Steps
https://www.eevblog.com/forum/testgear/sniffing-the-rigol_s-internal-i2c-bus/msg569236/#msg569236
Related Thread
https://www.eevblog.com/forum/testgear/you-can_t-unlock-a-mso1000z-series-scope-without-a-memory-dump-and-other-lessons/msg772022/#msg772022
Related Thread
https://www.eevblog.com/forum/testgear/mso1104z-hackingpossible/msg862468/#msg862468

Commands are as follows:

C:\openocd-0.8.0\bin-x64\openocd-x64-0.8.0.exe -d1 -f C:\openocd-0.8.0\scripts\interface\ftdi\olimex-arm-usb-ocd-h.cfg -f C:\openocd-0.8.0\scripts\target\imx28.cfg

dump_image your_filename_here.bin 0x40000000 0x3FFFFFF

If you have no build tools in Ubuntu then sudo apt-get install build-essential

./rigup scan mso1074z.bin > mso1074z.txt

./rigup license mso1074z.txt 0x1C0xx

I elected to do the memory dump using windows so after getting my hands on a seggar jlink sat down to get to it.
I used the pinout from most excellent video for reference,

and right at the get go I noticed that the debugger I was using outputs 5v to the target, while the scopes jtag header takes an input of 3.3v. What I ended up doing was soldering together 3ea 1/4 W 1k resistors into a voltage divider. Worked perfectly. I will say at this point that that was the only modification in this project that didn't come directly from the resources above and someone elses hard work and know-how. thanks guys and girls!

Anyone else using the j-link device will need to edit the jlink.cfg file in the scripts/interface folder in openocd with "adapter_khz 4000", just like that (without quotes). I also installed JLink Commander with the intention of making use of the included driver for windows, well that didn't work so I used Zadig to replace the seggar driver with Winusb, after a few false starts the thing was recognized by windows command line at 4000 khz. which translates to about 15 or 20 min for the dump to complete. now I will say I saw where someone else used "adapter_khz 10000" but i'm pretty sure I read somewhere the default speed was adapter_khz 4000 so I went with that. Again, I used the list of commands on the page with the above video, edit as necessary, and thanks to #ElectronicsCreators

Now i'll regress a bit and mention that i've never actually read "sniffing the rigols internal i2c bus" from start to finish, but spent a goodly amount of time cherry picking what I figured was appropriate for what I was trying to accomplish. That didn't work so well. Anyhow, after getting 2-blocked time and again (read generating valid looking codes), after editing this file or that file, that fail to install, so I finally decided I needed to bite the bullet and start on page 1 and just keep reading until something made sense. That happened on page 47.

The first change to the rigup (0.4.1-mso1000z is what I used) code that was suggested (commented in the file) for mso devices was in rigup-0.4.1-mso1047/src/utils.c as follows, line 241 I believe,

EDIT-
 found this post that indicates for the mso1104z at least this edit is dependant on firmware, and or board version. The firmware on my mso1104z is 00.04.04.SP4 and the edit I made is opposite from the edit required by his scope.

Just for clarity, this MSO1104Z with firmware 00.04.04.SP1 uses the sequence 0x02 0x00 0x84 0x00 0x10 0x00.
Fix: if you download the rigup-0.4.1-mso1000z.zip from gotroot.ca, open utils.c, in the function ScanKeys() uncomment the first static const and comment out the second, so it looks like this afterwards:
EDIT/

Code: [Select]

KeyData* ScanKeys(const void *data, size_t datasize)
{
  /*
    Offset Data
      0 02 00 84 00 10 00
      For mso1074z-s, use: 01 00 84 00 10 00
      6 <16 bytes of XXTEAKey>
     22 20 00
     24 <16 bytes of RC5Key1>
     40 <16 bytes of RC5Key2>
     56 08 00
     58 <8 bytes of bit-shuffled ECC public key>
     66 40 00
     68 <64 bytes of some ASCII-HEX data>
    132 <END>
  */

  const unsigned int sequenceSize = 6 + 16 + 2 + 2*16 + 2 + 8 + 2 + 64;
  //static const uint8_t seq_1_ref[] = {0x02, 0x00, 0x84, 0x00, 0x10, 0x00};
  static const uint8_t seq_1_ref[] = {0x01, 0x00, 0x84, 0x00, 0x10, 0x00};

the above is after the edit:

this line was commented out:
//static const uint8_t seq_1_ref[] = {0x02, 0x00, 0x84, 0x00, 0x10, 0x00};

this line was uncommented in:
static const uint8_t seq_1_ref[] = {0x01, 0x00, 0x84, 0x00, 0x10, 0x00};

the second change was made in Makefile, line 7 or so:

from this:

Code: [Select]


LDFLAGS       := -O2 -Wl,-dead_strip


to this:

Code: [Select]


LDFLAGS                := -O2 -Wl,--gc-sections -s



OK, after making the edits and compiling the code and doing a ./rigup scan mso1047x.bin > mso1047.txt, that the serial # on the txt file was not the same as my scope, at this point I got it into my head that until rigup generated a txt file that matched the serial # of the scope that the software wouldn't be able to come up with the correct option codes. I didn't figure out what a dumb assumption that was until I got to page 47, specifically a link to this thread,

You can't unlock a MSO1000Z series scope without a memory dump and other lessons

more specifically, this:

5.You don't need to modify rigup if you have a serial number beginning with DS1ZC Looking at the source code of the patched rigup tool (rigup-0.4.1-mso1000z.zip), I   thought it only worked for oscilloscopes with serial numbers beginning with DS1ZD.   In utils.c, there's this following line:

  if ( serialNumber[4]!='D' && serialNumber[3]!='Z' && serialNumber[2]!='1' &&
  serialNumber[1]!='S' && serialNumber[0]!='D' )

  This got me concerned as my scope's serial number began with DS1ZC. Turns out this   if statement never evaluates true (set a breakpoint, never hit during debug).

 
So i'm thinking to myself it can't be as easy as editing the mso1047x.txt file with the correct ser # could it?

Turns out it could be that easy.

Tried it and almost loaded my pants when the license code generated from:

./rigup license mso1074z.txt 0x1C0FF

enabling all options,

successfully installed!

Thanks Again

[colabri]

I want to do a backup before updating a buggy firmware on a bit different oscilloscope. Only the dump from the first bank came out properly (https://www.eevblog.com/forum/testgear/old-firmware-for-siglent-based-axiomet-oscilloscope/msg4020166/#msg4020166).

I tried to switch to the second bank with your steps. Fortunately nothing bad happened but unfortunately there was no switch.

It may be that the registers are different and right now I have no idea on how to figure them out.
Can you detail a bit on how you figured out the bank switching ?

Bank switching is rather specific to the individual hardware. There's a chance devices from the same vendor use the same (or a similar) method, but between vendors it's rather unlikely.

I had to reverse engineer the Rigol firmware to figure out how the bank switching works on the DSA815. Was the first time I did something like this and took me a couple of weeks (!). Only worth it for learning how to work with Ghidra.

[kimouser6471]

What is the latest firmware version for DS2072 (non-A).

At Rigol page there are only for DS2000A, is the same for non-A version?

FW 3.6 same DS2072A