EEVblog Electronics Community Forum

Products => Test Equipment => Topic started by: andyturk on May 17, 2013, 04:22:20 pm

Title: Sniffing the Rigol's internal I2C bus
Post by: andyturk on May 17, 2013, 04:22:20 pm
Quick Links:

#2446: buergi's "information needed to memdump [a] DS2KA" (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg365951/#msg365951)


All the talk of Rigol hacks got me curious about what goes on inside my DS1102E's non-volatile RAM. There's a FM24CL04 (http://www.ramtron.com/files/datasheets/FM24CL04_ds.pdf) chip on the main board and as a prelude to hacking some more expensive equipment, I thought I'd break out the soldering iron and turn my 1102E into a guinea pig:

(https://lh3.googleusercontent.com/-qp3c8KA38EM/UZZRpcOfrhI/AAAAAAAAABo/N1Ue178NaRE/w506-h750/photo.jpg)

A logic analyzer shows decodable activity on those lines. Here's (the first part) of what happens when I change the timebase from 20ms/div to 50ms/div:

(https://lh5.googleusercontent.com/-SUUhe0zLrgs/UZZUrZCvEsI/AAAAAAAAACc/Bv3t-yaEcsc/w806-h274-no/Screen+Shot+2013-05-17+at+9.01.14+AM.png)

I'm not sure how to decipher it yet, but since the horizontal timebase is restored on power-up, the I2C activity is probably how the mcu saves that particular piece of information.

Attached is a .zip with two logic analyzer (Saleae Logic16) dumps. The small one is when I changed the horiz timebase. The big one is what goes on when the scope boots up.

Does anyone have suggestions on a good way to decode this data? The Saleae app seems OK, but it's hard to see more than a few bytes on the screen at once. It'd be much nicer to get a text dump of reads/writes by address.

PS. I forgot to probe the two address pins on the FRAM chip while I had the case open.  :palm: I suspect they're wired to GND though. I.e., the FRAM will be responsive to addresses like 0b101000XX.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: kfitch42 on May 17, 2013, 05:06:14 pm
Don't have a Salea, never used their software before...
I downloaded it, opened one of the files, clicked on the 'gear' next to I2C, clicked export... The format of the generated text file isn't spectacular (the formatting of the 'data' column is annoyingly inconsistent). But, thats nothing a few lines of python/perl couldn't fix
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ve7xen on May 17, 2013, 05:10:33 pm
Something like a Bus Pirate, or Arduino or whatever that has a hardware I2C interface. As I understand it, most of these USB analyzers rely on buffering and can't do 'realtime' decoding, or store enough samples to capture long or infrequent-ish events.

I would first get a full image of the FRAM, and then decode each change and map controls (e.g. vertical gain) to bytes in the memory. Hopefully you can build a map of what goes where, which will get you started on figuring out what values mean what. If the DS1102 firmware is similar to the DS2000 series, it will read the entire FRAM sequentially at boot.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: andyturk on May 17, 2013, 06:35:26 pm
Something like a Bus Pirate, or Arduino or whatever that has a hardware I2C interface. As I understand it, most of these USB analyzers rely on buffering and can't do 'realtime' decoding, or store enough samples to capture long or infrequent-ish events.

I would first get a full image of the FRAM, and then decode each change and map controls (e.g. vertical gain) to bytes in the memory. Hopefully you can build a map of what goes where, which will get you started on figuring out what values mean what. If the DS1102 firmware is similar to the DS2000 series, it will read the entire FRAM sequentially at boot.
I'll have a Bus Pirate sometime next week.

Just looking at the amount of stuff that goes by at boot, I'd guess that the 1102 is reading the entire FRAM too. Calculating a checksum, maybe?

Has someone done a similar experiment with the DS2000/4000? Ultimately, that's where I'm headed. But if I'm going to brick a scope, I'd rather it be a cheap one.  :P
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ve7xen on May 18, 2013, 12:58:38 am
I'll have a Bus Pirate sometime next week.
When I did this I had to dick around with custom (faster than the firmware lets you set) baud rates to get it to be fast enough during the long initial read. It did end up working well enough to capture the bootup though; a quick Python hack and I had a binary image file.


Just looking at the amount of stuff that goes by at boot, I'd guess that the 1102 is reading the entire FRAM too. Calculating a checksum, maybe?
The DS2000 has a checksum. IIRC it was CRC32 in the last 4 bytes, but whatever it was it was trivial to find. So that's probably a good guess.

Quote
Has someone done a similar experiment with the DS2000/4000? Ultimately, that's where I'm headed. But if I'm going to brick a scope, I'd rather it be a cheap one.  :P
I did, but I just used clip leads and didn't leave it permanently connected. Kept it on for long enough to capture an image but that's about it, I needed to use the scope :P.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: andyturk on May 18, 2013, 11:00:14 pm
Of course, but what's on my bench at the moment is an 1102E. There are already reasons to believe that the non-volatile storage implementations are similar between the different Rigol scope families. So poking around on a cheap unit should make it easier to understand what's happening in the more expensive models.

Questions to be answered:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on May 19, 2013, 10:58:42 pm
anyone yet tried to find out the segmentation of the firmware file for a DS2000 ?
i have compared 00.00.01.00.05 with 00.01.00.00.03 - and in the first chunks there is a large similarity, there is around 0x30000 bytes of blackfin code which is very similar, except a few offset bytes for lower half registers. also in there seem to be the bitstreams for the xilinx fpga (0xAA 0x99 0x55 0x66 header).
it seems to use lwip (there is plenty of AD sample code), embedded GoAhead-webs (Webserver), VDK threads
so far i was unable to get any sense, besides a chunk counter, out of the file headers.

it would be helpfull if somebody could provide a 3rd firmware release
so far no plans in touching the actual hardware. there also seem to be some exploits for the goahead webserver, which might be a way to get remote code execution.

DS2000_1.GEL
============

44 53 32 32 30 32 00 00 00 00 00 00 00 00 00 00 30 30 2E 30 30 2E 30 31 2E 30 30 2E 30 35 00 {VERSION HEADER}

                  number of "simliar" looking chunks
                 /
00 07 00 00 00 11 00 00 00 B4 3D 31 00 04 02 00 00 63 7C 37 17 00 00 00 00 00 00 04
20 01 00 00 00 00 00 00 00 58 BD 17 00 B8 3F 31 00 B6 96 14 05 06 00 00 00 00 00 00
20 05 00 00 00 00 00 00 00 60 0F 01 00 10 FD 48 00 6B A4 C1 52 02 00 00 00 00 00 00
20 0A 00 00 00 00 00 00 00 78 1B 03 00 70 0C 4A 00 CE F9 DD 2B 02 00 00 00 00 00 02
20 0B 00 00 00 00 00 00 00 5A 24 00 00 E8 27 4D 00 25 73 2A CD 02 00 00 00 00 60 0D
20 0C 00 00 00 00 00 00 00 F4 78 00 00 42 4C 4D 00 D5 06 98 0E 04 00 00 00 00 80 0C
20 0E 00 00 00 00 00 00 00 E8 B6 05 00 36 C5 4D 00 74 D1 E8 0E 04 00 00 00 00 A0 0F
20 0F 00 00 00 00 00 00 00 54 1D 00 00 1E 7C 53 00 9E 58 B8 BC 02 00 00 00 00 00 12
20 10 00 00 00 00 00 00 00 68 2E 06 00 72 99 53 00 46 63 39 BB 04 00 00 00 00 00 00
20 11 00 00 00 00 00 00 00 4C 30 00 00 DA C7 59 00 C9 49 90 3B 03 00 00 00 00 00 04
20 13 00 00 00 00 00 00 00 64 0B 00 00 26 F8 59 00 F5 95 B6 D2 05 00 00 00 00 00 00
20 14 00 00 00 00 00 00 00 98 C5 03 00 8A 03 5A 00 CC 1B 1C 3F 05 00 00 00 00 0C 00
20 15 00 00 00 00 00 00 00 18 01 00 00 22 C9 5D 00 9D DF F2 1A 05 00 00 00 00 4C 1E
20 15 00 00 00 00 00 00 00 1C 90 00 00 3A CA 5D 00 39 A5 80 1A 05 00 00 00 00 D4 03
20 15 00 00 00 00 00 00 00 61 16 00 00 56 5A 5E 00 E1 CE 61 51 03 00 00 00 00 D8 1F
20 15 00 00 00 00 00 00 00 08 B8 0B 00 B7 70 5E 00 40 0B 53 4B 03 00 00 00 00 50 04
20 15 00 00 00 00 00 00 00 00 00 00 00 BF 28 6A 00 00 00 00 00 02 00 00 00 00 28 12
20 32 00 00 00 00 00 00 00 06 50 18 AD 00 00 A0 FF 00 00 00 00 BC 00 00 00 06 00 E8
AD 00 80 A0 FF
{BLACKFIN CODE, SDRAM controller init ...}

DS2000_2.GEL
============

44 53 32 32 30 32 00 00 00 00 00 00 00 00 00 00 30 30 2E 30 31 2E 30 30 2E 30 30 2E 30 33 00 {VERSION HEADER}

00 07 00 00 00 12 00 00 00 9C 8F 37 00 20 02 00 00 7E 42 E9 27 00 00 00 00 00 00 04
20 01 00 00 00 00 00 00 00 A8 CC 17 00 BC 91 37 00 C3 C3 3A 5A 06 00 00 00 00 00 00
20 05 00 00 00 00 00 00 00 60 0F 01 00 64 5E 4F 00 6B A4 C1 52 02 00 00 00 00 00 00
20 0A 00 00 00 00 00 00 00 AA 21 03 00 C4 6D 50 00 8A F3 49 6C 02 00 00 00 00 00 02
20 0B 00 00 00 00 00 00 00 5A 24 00 00 6E 8F 53 00 25 73 2A CD 02 00 00 00 00 60 0D
20 0C 00 00 00 00 00 00 00 B4 7F 00 00 C8 B3 53 00 70 78 AC 4C 04 00 00 00 00 80 0C
20 0E 00 00 00 00 00 00 00 F4 63 06 00 7C 33 54 00 80 5A 4D 45 04 00 00 00 00 00 0F
20 0F 00 00 00 00 00 00 00 54 1D 00 00 70 97 5A 00 9E 58 B8 BC 02 00 00 00 00 00 12
20 10 00 00 00 00 00 00 00 62 DC 06 00 C4 B4 5A 00 98 8C 5A 88 04 00 00 00 00 00 00
20 11 00 00 00 00 00 00 00 D8 32 00 00 26 91 61 00 18 1D 48 B7 03 00 00 00 00 00 04
20 13 00 00 00 00 00 00 00 64 0B 00 00 FE C3 61 00 F5 95 B6 D2 05 00 00 00 00 00 00
20 14 00 00 00 00 00 00 00 98 C5 03 00 62 CF 61 00 CC 1B 1C 3F 05 00 00 00 00 0C 00
20 15 00 00 00 00 00 00 00 18 01 00 00 FA 94 65 00 9D DF F2 1A 05 00 00 00 00 4C 1E
20 15 00 00 00 00 00 00 00 10 90 00 00 12 96 65 00 A2 35 07 55 05 00 00 00 00 D4 03
20 15 00 00 00 00 00 00 00 61 16 00 00 22 26 66 00 E1 CE 61 51 03 00 00 00 00 D8 1F
20 15 00 00 00 00 00 00 00 08 B8 0B 00 83 3C 66 00 40 0B 53 4B 03 00 00 00 00 50 04
20 15 00 00 00 00 00 00 00 F0 6E 04 00 8B F4 71 00 FB ED C4 52 07 00 00 00 00 00 10
20 15 00 00 00 00 00 00 00 00 00 00 00 7B 63 76 00 00 00 00 00 02 00 00 00 00 28 12
20 32 00 00 00 00 00 00 00 06 50 18 AD 00 00 A0 FF 00 00 00 00 BC 00 00 00 06 00 E8
AD 00 80 A0 FF 
{BLACKFIN CODE, SDRAM controller init ...}

SDRAM controller init code ... (same for both files)

 21c:   9c 00          RAISE 0xc;
     21e:   00 00          NOP;
     220:   00 00          NOP;
     222:   00 00          NOP;
     224:   66 01          [--SP] = ASTAT;
     226:   67 01          [--SP] = RETS;
     228:   40 05          [--SP] = (R7:0);
     22a:   c0 04          [--SP] = (P5:0);
     22c:   50 01          [--SP] = I0;
     22e:   51 01          [--SP] = I1;
     230:   52 01          [--SP] = I2;
     232:   53 01          [--SP] = I3;
     234:   58 01          [--SP] = B0;
     236:   59 01          [--SP] = B1;
     238:   5a 01          [--SP] = B2;
     23a:   5b 01          [--SP] = B3;
     23c:   54 01          [--SP] = M0;
     23e:   55 01          [--SP] = M1;
     240:   56 01          [--SP] = M2;
     242:   57 01          [--SP] = M3;
     244:   5c 01          [--SP] = L0;
     246:   5d 01          [--SP] = L1;
     248:   5e 01          [--SP] = L2;
     24a:   5f 01          [--SP] = L3;
     24c:   08 e1 18 0a    P0.L = 0xa18;      /* (2584)   P0=0xa18 */
     250:   48 e1 c0 ff    P0.H = 0xffc0;      /* (-64)   P0=0xffc00a18(-4191720) */
     254:   80 e1 ff ff    R0 = 0xffff (Z);      /*      R0=0xffff(65535) */
     258:   00 97          W[P0] = R0;
     25a:   24 00          SSYNC;
     25c:   08 e1 14 0a    P0.L = 0xa14;      /* (2580)   P0=0xffc00a14(-4191724) */
     260:   48 e1 c0 ff    P0.H = 0xffc0;      /* (-64)   P0=0xffc00a14(-4191724) */
     264:   80 e1 13 00    R0 = 0x13 (Z);      /*      R0=0x13( 19) */
     268:   00 93          [P0] = R0;
     26a:   24 00          SSYNC;
     26c:   08 e1 10 0a    P0.L = 0xa10;      /* (2576)   P0=0xffc00a10(-4191728) */
     270:   48 e1 c0 ff    P0.H = 0xffc0;      /* (-64)   P0=0xffc00a10(-4191728) */
     274:   00 e1 8d 99    R0.L = 0x998d;      /* (-26227)   R0=0x998d(39309) */
     278:   40 e1 91 00    R0.H = 0x91;      /* (145)   R0=0x91998d(9542029) */
     27c:   00 93          [P0] = R0;
     27e:   24 00          SSYNC;
     280:   08 e1 00 0a    P0.L = 0xa00;      /* (2560)   P0=0xffc00a00(-4191744) */
     284:   48 e1 c0 ff    P0.H = 0xffc0;      /* (-64)   P0=0xffc00a00(-4191744) */
     288:   00 e1 ff 01    R0.L = 0x1ff;      /* (511)   R0=0x9101ff(9503231) */
     28c:   40 e1 00 00    R0.H = 0x0;      /* (  0)   R0=0x1ff(511) */
     290:   00 93          [P0] = R0;
     292:   24 00          SSYNC;
     294:   1f 01          L3 = [SP++];
     296:   1e 01          L2 = [SP++];
     298:   1d 01          L1 = [SP++];
     29a:   1c 01          L0 = [SP++];
     29c:   17 01          M3 = [SP++];
     29e:   16 01          M2 = [SP++];
     2a0:   15 01          M1 = [SP++];
     2a2:   14 01          M0 = [SP++];
     2a4:   1b 01          B3 = [SP++];
     2a6:   1a 01          B2 = [SP++];
     2a8:   19 01          B1 = [SP++];
     2aa:   18 01          B0 = [SP++];
     2ac:   13 01          I3 = [SP++];
     2ae:   12 01          I2 = [SP++];
     2b0:   11 01          I1 = [SP++];
     2b2:   10 01          I0 = [SP++];
     2b4:   80 04          (P5:0) = [SP++];
     2b6:   00 05          (R7:0) = [SP++];
     2b8:   27 01          RETS = [SP++];
     2ba:   26 01          ASTAT = [SP++];
     2bc:   10 00          RTS;

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bonanz on May 22, 2013, 01:21:33 am
i like where this thread is going :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ve7xen on May 22, 2013, 08:21:08 am
so far i was unable to get any sense, besides a chunk counter, out of the file headers.
If we understand each other, you're referring to the BlackFin bootloader headers which map various flash segments to memory. These are described in the 'Block Headers' section of the BF526 Processor Hardware Reference (http://www.analog.com/static/imported-files/processor_manuals/ADSP-BF52x_hwr_rev1.2.pdf).

Nice work, you've gotten farther than I did with reversing :P.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on May 22, 2013, 03:19:18 pm
thank you ! total oversight of mine, too many pdfs i downloaded i guess ;-) -i'll check if that gets me somewhere.
some guy has done a IDA pro disassembler module for hacking the DS1X series + a loader for those files, i'll try to adapt it for these files, and will come back with any updates.
if someone feels at home in blackfin asm (new to me) the objdump tool from the blackfin uClinux does the job as well (somewhat at least) - i was looking for crc routines, but so far no luck.

does anyone know what the CPLD Mach X02 does ? is it for the display ? - the device is SRAM only but i didnt find any signatures yet ...

and again the question if someone has another fw version, i think the ds4k is similar in hardware so maybe same file format (or at least someone who owns a ds4k could check that pls ? )

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ikcalB on May 26, 2013, 05:32:57 pm
Hi.

I'm a mechatronics student soon finished & up to buy a DS2072 too...

Is progess being made in keeping / extending trial options, BW & other stuff?


Best regards,
Florian

/* typo */
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on May 26, 2013, 09:13:37 pm
still no luck on the loader addresses - for me it doesnt seem they stick with boot headers as defined in the blackfin manuals.
i managed to get the ida pro blackfin decompiler (from rigol homebrew) running, and did some tests with FLAIR libs, but the matching rate on VDSP libs sucks. i'd still love to get more firmware samples from ds2k/4k and does anyone have a trial key ? at least the format of it would be interesting. from a code point of view, i found twi,spi,dma (from/to fpga probably), sports (keyboard as ds1k), and the gpio routines. so far i didnt see any blackfin lockbox related stuff (which is good ;-).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on May 26, 2013, 11:00:24 pm
Having written loads of firmware which keeps track of something which needs to be tied in a tamper-proof way to real time, I can tell you that what you're describing is one of the very first things you would write code to prevent. I can't say for sure that Rigol has done it - but if they didn't, it's rather silly - since it's very easy to do.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on May 27, 2013, 08:14:52 pm
no RTC code in the blackfin so far ... they are not touching any of those registers  :wtf:
but i found the flash write routines outlined in the spansion flash chip datasheet ... dont have a full picture of it yet (thanks to caching  :rant: of the blackfin), but its somewhat decypherable ...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on May 27, 2013, 08:15:27 pm
True. I guess it's worth a try - but:

a) The trial options are a bonus - if the clock is all of a sudden 'seen' by code to have stopped working, why wouldn't the bonus just be 'switched off'?
b) It's still easy, as of the current FW, to restart the trial options over and over again - but you need the clock for that.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on May 29, 2013, 07:31:07 pm
this code reads the ds2k .GEL files, and dumps the DXE streams, and individual blocks - still no clue on the bytes behind the version/hw though ...

currently adding that code to the IDAPro rigol_ldr from rigol homebrew - results are promising, more than 8000 subs autodiscovered by IDA ;-) so something is right here ...

compile with:
Code: [Select]
gcc -funsigned-bitfields reader.c -o reader
Code: [Select]
//////////////////////////////////////////////////////////////
// RIGOL DS2XXX .GEL firmware reader
// (c) cybernet 2013
//////////////////////////////////////////////////////////////

#include<stdio.h>
#include<stdlib.h>
#include<string.h>

typedef unsigned char uchar;
typedef unsigned short int uint16;
typedef unsigned long int uint32;

#define BFLAG_FINAL 0x8000
#define BFLAG_FIRST 0x4000
#define BFLAG_INDIRECT  0x2000
#define BFLAG_IGNORE 0x1000
#define BFLAG_INIT 0x0800
#define BFLAG_CALLBACK 0x0400
#define BFLAG_QUICKBOOT 0x0200
#define BFLAG_FILL 0x0100
#define BFLAG_AUX 0x0020
#define BFLAG_SAVE 0x0010

struct gel_hdr {
   uchar hw[16];
   uchar ver[16];
   uchar         u1[1];
   uint32 recs;
};


struct bfn_hdr {
   uint16  flg;
   uchar   chk;
   uchar   sgn;
   uint32  taddr;
   uint32  count;
   uint32  arg;
};


uchar is_flag(uint32 flag, uchar *buff, uint32 offset)
{
 struct bfn_hdr *h;
 // overlay
 h=(struct bfn_hdr*)(buff+offset);
 return((h->flg & flag) == flag);
}

void print_bfn_hdr(uchar *buff, uint32 offset)
{
 int i;
 unsigned char *c;
 struct bfn_hdr *h;

 // overlay
 h=(struct bfn_hdr*)(buff+offset);

 //for(i=0;i<16;i++)
 // printf("%02X ",(uchar)*(buff+i));
 // printf("\n");   


 printf("\tHeader Sign: %02X - Checksum: %02X\n", h->sgn, h->chk);
 printf("\tFlags: %04X [", h->flg);
 if ((h->flg & BFLAG_FINAL) == BFLAG_FINAL) printf(" FINAL ");
 if ((h->flg & BFLAG_FIRST) == BFLAG_FIRST) printf(" FIRST ");
 if ((h->flg & BFLAG_INDIRECT) == BFLAG_INDIRECT) printf(" INDIRECT ");
 if ((h->flg & BFLAG_IGNORE) == BFLAG_IGNORE) printf(" IGNORE ");
 if ((h->flg & BFLAG_INIT) == BFLAG_INIT) printf(" INIT  ");
 if ((h->flg & BFLAG_CALLBACK) == BFLAG_FIRST) printf(" CALLBACK ");
 if ((h->flg & BFLAG_QUICKBOOT) == BFLAG_QUICKBOOT) printf(" QUICKBOOT ");
 if ((h->flg & BFLAG_FILL) == BFLAG_FILL) printf(" FILL ");
 if ((h->flg & BFLAG_AUX) == BFLAG_AUX) printf(" AUX ");
 if ((h->flg & BFLAG_SAVE) == BFLAG_SAVE) printf(" SAVE ");
 printf("]\n");
 printf("\tTAddr: %08X - Count: %08X - Arg: %08X\n", (uint32)h->taddr, (uint32)h->count, (uint32)h->arg);
}

void main(int argc, char *argv)
{
 uint32 len;
 uint32 buff_offset=0;
 uint32 next_dxe=0;
 uint32 block_offset=0;
 uint32 dxe_count=0;
 uint32 block_count=0;
 uchar *buff;
 FILE *f;
 struct gel_hdr *hdr;
 struct bfn_hdr *bfn;


 f = fopen("DS2000_2.GEL", "rb");
 if (!f)
 {
   fprintf(stderr, "Unable to open file\n");
   return;
 }

 // get size
 fseek(f, 0, SEEK_END);
 len=ftell(f);
 fseek(f, 0, SEEK_SET);

 // alloc buff
 buff=(char*)malloc(len+1);
 if (!buff)
 {
   fprintf(stderr, "Unable to allocate buffer\n");
   return;
 }
 fread(buff, len, 1, f);

 hdr=(struct gel_hdr*)buff;
 printf("hw: %s\n", hdr->hw);
 printf("version: %s\n", hdr->ver);
 printf("recs: %d\n",hdr->recs);
 buff_offset=32+8+(hdr->recs*28);

 while (!is_flag(BFLAG_FINAL, buff, buff_offset))
 {
    printf("\n====================\n");
    printf(" DXE #%d at %08X\n", dxe_count, buff_offset);
    printf("====================\n");
    block_offset=buff_offset;
    while (1)
    {
      printf("\n  BLOCK #%d at %08X\n", block_count, buff_offset);
      print_bfn_hdr(buff, buff_offset);
      bfn=(struct bfn_hdr*)(buff+buff_offset);
 
     // evaluate flags
     if (is_flag(BFLAG_FIRST, buff, buff_offset))
     {
if (!next_dxe)
next_dxe=bfn->arg+sizeof(struct bfn_hdr);
     }
     if (is_flag(BFLAG_FINAL, buff, buff_offset) ||
         is_flag(BFLAG_INIT, buff, buff_offset)
        )
        break;
     if (!is_flag(BFLAG_FILL, buff, buff_offset))
     {
        buff_offset+=bfn->count;
     }
     buff_offset+=sizeof(struct bfn_hdr);
     block_count++;
   }
   buff_offset=next_dxe+block_offset;
   next_dxe=0;
   dxe_count++;
   block_count=0;
 }
 fclose(f);
 free(buff);
}
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ve7xen on May 30, 2013, 12:46:32 am
If you have found where SPI is used in the firmware it may be useful to try to construct the bytes sent and see if you can find where it's sending the commands to limit bandwidth in the LMH6518. Not sure how you might find the decoder/trial options etc., but this should help you find how the bandwidth limit / model number checking is done (or possibly a way to override it).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on May 30, 2013, 07:12:28 am
for now im trying to backtrack the string references and work my way through there ...
so far i have seen spi being used where the fpga is initialized, e.g. to push the bitstream ...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tinhead on May 30, 2013, 05:40:37 pm
Quote
Not sure if this will be enough though. Looking at the table on page 29 of the datasheet I don't see a 70MHz setting, suggesting that there is something else involved in the limiting.

based on the data i collected for my thread

https://www.eevblog.com/forum/testgear/frequency-response-of-your-dso/ (https://www.eevblog.com/forum/testgear/frequency-response-of-your-dso/)

i would say a 70MHz model is using 100MHz as filter setting, and 200MHz model is using 350MHz as filter setting.
There is for sure a bit extra gain loss in input stage, that's why e.g. 200MHz models -3dB is at ~250MHz.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tinhead on May 30, 2013, 09:01:53 pm
Quote
So are you saying that there is no difference between the 70MHz and 100MHz versions? Maybe the 70MHz ones are binned or something?

I wonder how the firmware figures out which version the hardware is.

no idea, i don't have any data from 100MHz models, all i can see (from other users measurments) is that 70MHz model
seems to use 100MHz filter (and seems to have no extra gain loss here) and 200MHz model the 350MHz filter (with lot of
gain loss, so -3dB is at 250MHz). When you look however into the datasheet, then you will see there is an additional
step between, so probably the 100MHz model is using 200MHz filter. Due the fact that there is some extra gain loss in
higher frequencies, i would say the 100MHz bw would be something like 150MHz real -3dB bw.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: andyturk on May 30, 2013, 09:19:18 pm
Quote
I wonder how the firmware figures out which version the hardware is.
It's almost certain that all the DS2K boards are exactly the same.

I'll bet $1 that there's a programming header or serial port somewhere on the factory floor that gives each board it's personality. That'll include things like the serial number and bandwidth limitation (if that's actually a separate value).

They probably store this info in the NOR flash because they're not supposed to change for the life of the product. Things like trial option countdown values probably go into FRAM because they'll change more often and Rigol (hopefully) wouldn't want to have any issues with write endurance on the NOR.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on May 30, 2013, 10:37:37 pm
anyone knows where the FRAM is ? and what type it is ? didnt bother to inspect all the pics/threads yet  8)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tinhead on May 30, 2013, 11:20:55 pm
MB85RC16, it is directly between display connector and DSP
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ve7xen on May 31, 2013, 05:50:33 am
Quote
So are you saying that there is no difference between the 70MHz and 100MHz versions? Maybe the 70MHz ones are binned or something?

I wonder how the firmware figures out which version the hardware is.
Yes. I have sniffed the LMH6518 traffic and the 70MHz scope sets the 100MHz bandwidth limit when 'unlimited' in the firmware and 20MHz when the 20MHz filter is enabled.

I defeated the SPI bus and confirmed somewhere around 300MHz of -3dB bandwidth.

The LMH6518 is the only bandwidth limiter in the scope, as far as I can tell. Putting a second master on the bus after the 33R resistor pack would probably work, reading the commands and then sending them back without the bandwidth limit (unless 20MHz of course). You might need to source some current back into the scope processor but it shouldn't be that bad if you tap the LMH6518 side of the resistor pack. Also the bus is fairly fast (~10MHz), so you won't be able to use a totally bottom of the line uC to do it, but something like an ATtiny45 overclocked a bit could probably handle the task.

Soldering these tiny things is truly a bitch though. I'm tempted to give it a try, but I already bricked the scope once messing around here... I don't think I'll risk it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on May 31, 2013, 05:54:51 am
cool stuff  :) - im reversing SPI, and TWI (FRAM) subs at the moment ...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MrsR on May 31, 2013, 05:11:40 pm
My question is Why does doing a self cal. remove the trial software if that removes it there must be some code activated method of putting it back?

Really good info guys.

Our software division has a LMH6158QN?? sorry didn't write it down as they didn't get it through me it must be a test bed or software/programmer. Will find out in conference Tuesday.
All hardware goes through me unless Head Office by passes me direct to a section and that hasn't happened yet unless their still unhappy with me frying a 7GHz MSO (wasn't my fault honest) ;)
GOOD READ
Rachael :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on May 31, 2013, 09:10:53 pm
my guess is more on the FRAM for serial (which probably determines the bandwidth limit in the preamp) as well as license option storage.
there are 100M/200M string references in the code. as well as input mask for the license key entry page. - so its in there somewhere ...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on June 01, 2013, 02:13:45 pm
I copied the FRAM. I have used an Arduino UNO with level shifter. The trial period is probably stored at 0x7F6 and 0x7F7. There seems to be no checksum.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 01, 2013, 02:14:57 pm
cool stuff :-+ ... working on the TWI sub()'s in IDA pro this comes very handy ! ;-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 01, 2013, 02:30:20 pm
btw there should be a 3rd device on the IIC/TWI bus because the ADSP configures itself also for slave mode operation ... maybe an external RTC - i dont see the internal BF one used at all.

Code: [Select]
def TWI_SLAVE_enable_sub_20568(...):

LINK 0x0;               # R0=TWI SLAVE ADDR
B[FP + 0x8] = R0;
R1 = 0x7f (X);          # R1=0x7f
R0 = R0 & R1;           # discriminate lower 7 bits
P1 = 0x1404 (X);        # P1=0x1404
P1.H = 0xffc0;          # P1=0xffc01404
                      -> TWI_CONTROL
R1 = W[P1] (Z);
R0 = R0 | R1;
W[P1] = R0.L;
R0 = W[P1] (Z);
BITSET (R0, 0x7);       # bit  7
W[P1] = R0.L;           # set TWI slave address bit 7 is *always* high
P1 = 0x1410 (X);        # P1=0x1410
P1.H = 0xffc0;          # P1=0xffc03950
                      -> TWI_SLAVE_ADDR
R0 = W[P1] (Z);
R1 = 0x51 (X);          # R1=0x51
R0 = R0 | R1;
W[P1] = R0.L;           # set TWI slave to R0  / 0x51 (101001b)
P1 = 0x1428 (X);        # P1=0x1428
P1.H = 0xffc0;          # P1=0xffc01428
                      -> TWI_FIFO_CTL
R0.L = 0x1;             # R0=0x10001
W[P1] = R0.L;           # flush receiver FIFO
R0.L = 0x0;             # R0=0x10000
W[P1] = R0.L;           # flush transmitter FIFO
P1 = 0x1424 (X);        # P1=0x1424
P1.H = 0xffc0;          # P1=0xffc01424
                      -> TWI_INT_MASK
R0 = W[P1] (Z);
R1 = 0xc2 (X);          # R1=0xc2
R0 = R0 | R1;
W[P1] = R0.L;           # set TWI interrupt mask to:
                        # -> Receive Fifo SIM (RCVSERVM)
                        # -> Transmit Fifo SIM (XMTSERV)
                        # -> Slave Transfer Complere SIM (SCOMPM)
P1 = 0x1408 (X);        # P1=0x1408
P1.H = 0xffc0;          # P1=0xffc01408
                      -> TWI_SLAVE_CTL
R0 = W[P1] (Z);
BITSET (R0, 0x2);       # bit  2
W[P1] = R0.L;           # STDVAL - enable Slave Transmit Data Value
UNLINK;
RTS;
# end function

Code: [Select]
SDRAM:2162C                 R0 = 0x64 (X);          # R0=0x64
SDRAM:21630                 CALL TWI_SLAVE_Setup_Int_CallBack_sub_2076E;

so the BF is having (0x64 & 0xF7 | 0x80) = 0xE4 as slave address
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 01, 2013, 02:34:43 pm
I copied the FRAM. I have used an Arduino UNO with level shifter. The trial period is probably stored at 0x7F6 and 0x7F7. There seems to be no checksum.

could u also check if u see any matching between your serial number, and values in the FRAM ?

the code makes use of a string reference of:
SDRAM:EFFD94 aDs2a0000000001:ascii "DS2A0000000001",0 # DATA XREF: sub_10C700+48?

my guess would be: DS2A0000000001 + some FRAM value = the serial
and the serial determines the bandwidth limit ...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 01, 2013, 02:41:55 pm
and the serial determines the bandwidth limit ...

I don't think this makes sense, because it's clear from the FW that Rigol have already coded the possibility of BW upgrades as a purchasable option in the future (if they decide they want/need to).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 01, 2013, 02:44:12 pm
what option makes u believe that ? i assume same fw is used for a ds2072 as for a ds2202 - looking at what seems likes options (TRIGGER, MEMORY .. ) i didnt spot something that looks like fw upgrade option.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 01, 2013, 02:48:53 pm
what option makes u believe that ? i assume same fw is used for a ds2072 as for a ds2202 - looking at what seems likes options (TRIGGER, MEMORY .. ) i didnt spot something that looks like fw upgrade option.
"... the possibility of BW upgrades..."

(https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/?action=dlattach;attach=49703)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on June 02, 2013, 08:04:56 am
I have the complete FRAM once overwritten with 0xFF and 0x00. The serial number does not change. The serial number appears to be in Flasch.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on June 02, 2013, 08:14:53 am
I entered a code to renew the trial options. Now my start screen looks like in the picture. It really seems to be bandwidth options in the firmware.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on June 02, 2013, 08:34:26 am
I don't know exactly how the time is calculated. But it is definitely stored in the FRAM at address 0x7F6 and 0x7F7.

Maybe someone finds the exact algorithm.
Here are a few examples:

0x34 0x25 -> 0x2534 -> 926min
0x17 0x25 -> 0x2517 -> 931min
0x00 0x20 -> 0x2000 -> 1165min
0x00 0x1F -> 0x1F00 -> 1210min
0x00 0x10 -> 0x1000 -> 1898min
0x00 0x0F -> 0x0f00 -> 1943min
0x00 0x0D -> 0x0D00 -> 2035min
0x00 0x0B -> 0x0B00 -> 2127min
0x4A 0x0A -> 0x0A4A -> 2159min
0x49 0x0A -> 0x0A49 -> 2160min (max)
0x48 0x0A -> 0x0A48 -> expired
0xFF 0xFF -> 0xFFFF -> expired
0x00 0x00 -> 0x0000 -> expired
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: amyk on June 02, 2013, 08:44:09 am
I copied the FRAM. I have used an Arduino UNO with level shifter. The trial period is probably stored at 0x7F6 and 0x7F7. There seems to be no checksum.
Last 4 bytes look like one to me...

The data value and minutes remaining are nearly perfectly linear correlated. The minutes remaining from data value is -0.179x + 2630.9. This equation is probably clearer in seconds or ms as they're counting ticks of some odd internal clock frequency.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Teneyes on June 02, 2013, 09:14:53 am
The minutes remaining from data value is -0.179x + 2630.9.

I concur with this equation of Options based on run-time and I think the count down time from 2630 to 2160 minutes are to allow for factory Testing and Burn-in , then turn on Trial options
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Pinkus on June 02, 2013, 09:49:35 am
I entered a code to renew the trial options. Now my start screen looks like in the picture. It really seems to be bandwidth options in the firmware.

Mmmhhh - this bring me to the questions:
a) which Rigol Scope do you own (70 / 100 / 200 Mhz)?
b) As now 100/200 Mhz are marked as trial: Do you have 2ns timebase available?

Peter
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on June 02, 2013, 10:01:08 am
a) I have a DS2072.
b) 2ns timebase is not available.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: egonotto on June 02, 2013, 01:25:33 pm
Hello studio25,

when you write the values in FRAM 0x7f6 and 0x7f7 do you have than the corresponding times for the trial options?

Best Regards
egonotto
 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on June 02, 2013, 05:17:33 pm
Quote
when you write the values in FRAM 0x7f6 and 0x7f7 do you have than the corresponding times for the trial options?

I write the values during the boot phase of the oscilloscope.
If they are not too high or too low, the trial time is adjusted.

offset 0x7f6 -> 0x49 and offset 0x7f7 -> 0x0A = 2160min trial time.
More examples in Reply #44
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 02, 2013, 05:22:07 pm
I entered a code to renew the trial options. Now my start screen looks like in the picture. It really seems to be bandwidth options in the firmware.

If you don't have the 2ns time base setting and the 100MHz BW limit per channel, it's unlikely you have the real 200MHz BW - regardless of whatever the option screen says. There are MANY things that exist in the FW that are partially/completely unimplemented. We have no way of knowing if the BW Trial Option is actually fully implemented.

Edit: Also, considering that the BW is a much bigger selling point to Rigol than the options, I suspect it's a bit harder to invoke - and likely keyed to the model number in FW - at least in the current FW versions.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on June 02, 2013, 05:30:49 pm
Quote
If you don't have the 2ns time base setting and the 100MHz BW limit per channel, it's unlikely you have the real 200MHz BW - regardless of whatever the option screen says.

Right. I have a rise time of 3.2ns measured. Which corresponds to approximately 109MHz.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 02, 2013, 05:39:06 pm
Quote
If you don't have the 2ns time base setting and the 100MHz BW limit per channel, it's unlikely you have the real 200MHz BW - regardless of whatever the option screen says.

Right. I have a rise time of 3.2ns measured. Which corresponds to approximately 109MHz.

And from everything we've learned so far, there seems to be absolutely NO difference between the 70MHz and 100MHz models.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 02, 2013, 06:19:13 pm
Quote
If you don't have the 2ns time base setting and the 100MHz BW limit per channel, it's unlikely you have the real 200MHz BW - regardless of whatever the option screen says.

Right. I have a rise time of 3.2ns measured. Which corresponds to approximately 109MHz.

@studio25 - I know it's a stupid question, but I don't see it specifically verified anywhere: you have confirmed that all of the options (except BW) are turned on and working (as opposed to just displayed minutes changed), right?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on June 02, 2013, 06:35:02 pm
Quote
you have confirmed that all of the options (except BW) are turned on and working (as opposed to just displayed minutes changed), right?

Yes.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on June 02, 2013, 06:37:55 pm
Code: [Select]
does counter go to ffff or 0000 after expire?
Do I need to test. Maybe tomorrow or Tuesday.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 02, 2013, 06:41:27 pm
Quote
you have confirmed that all of the options (except BW) are turned on and working (as opposed to just displayed minutes changed), right?

Yes.

Ok, just checking  ;)  But perhaps because of language difficulties, I'm not 100% sure of the sequence of events. It sounds like you entered a new license code  - then that brought the options back - and then you were able to play with the trial minutes.

I guess the question is: if the options are expired when the scope boots - can you cause them to restart only by changing those two values in FRAM? Or is there a flag somewhere else indicating expiration?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Teneyes on June 02, 2013, 06:54:19 pm

I guess the question is: if the options are expired when the scope boots - can you cause them to restart only by changing those two values in FRAM? Or is there a flag somewhere else indicating expiration?
@Studio25

Do you still have the decode option functions as indicated by the decode Menu List.?

When your DSO shows full options on startup.(by patching some Memory) does not indicate that you have that functionality
Show us your Decode menu

What is the real time left on your Options??



Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on June 02, 2013, 06:54:54 pm
Quote
if the options are expired when the scope boots - can you cause them to restart only by changing those two values in FRAM?

Yes.

Sorry for my bad english (google translator).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on June 02, 2013, 08:21:14 pm
Quote
you have confirmed that all of the options (except BW) are turned on and working (as opposed to just displayed minutes changed), right?

Yes.

Ok, just checking  ;)  But perhaps because of language difficulties, I'm not 100% sure of the sequence of events. It sounds like you entered a new license code  - then that brought the options back - and then you were able to play with the trial minutes.

I guess the question is: if the options are expired when the scope boots - can you cause them to restart only by changing those two values in FRAM? Or is there a flag somewhere else indicating expiration?

The counter is always running. Even if the trial is expired. He just runs over.
But once the trial is expired will change the byte at address 0x7F8 from 0x00 to 0x01.
To reset the trial time just change the bytes at offset 0x7F6 to 0x49 0x0A 0x00.

Oh one more thing ....
Rigol DS2000 trial hack (https://www.youtube.com/watch?v=9QhsuKvB9U4#ws)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 02, 2013, 08:49:24 pm
The counter is always running. Even if the trial is expired. He just runs over.
But once the trial is expired will change the byte at address 0x7F8 from 0x00 to 0x01.
To reset the trial time just change the bytes at offset 0x7F6 to 0x49 0x0A 0x00.

Nice video!  :)  Thanks for that.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on June 02, 2013, 08:55:45 pm
The counter is always running. Even if the trial is expired. He just runs over.
But once the trial is expired will change the byte at address 0x7F8 from 0x00 to 0x01.
To reset the trial time just change the bytes at offset 0x7F6 to 0x49 0x0A 0x00.

I think you're responsible for another DS2000 sale.

Good work!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: egonotto on June 02, 2013, 09:05:59 pm
well done
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: andyturk on June 02, 2013, 09:23:14 pm
Oh one more thing ....
Superb!

 :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: monster on June 02, 2013, 09:31:23 pm
The counter is always running. Even if the trial is expired. He just runs over.
But once the trial is expired will change the byte at address 0x7F8 from 0x00 to 0x01.
To reset the trial time just change the bytes at offset 0x7F6 to 0x49 0x0A 0x00.
Oh one more thing ....

Olé! Congratulations, if there wasn't so much to do next week ... well anyway, now I know what to do the week after that 8)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on June 02, 2013, 09:49:53 pm
I'm working on the code for a ATtiny85. Here is the smaller Arduino code.
Code: [Select]
#include <avr/sleep.h>
#include <Wire.h>

void setup() {
  Wire.begin();
}

void loop() {
  // w8 for start
  while (digitalRead(SCL) == HIGH);
  uint16_t startmillis = millis();
  while (digitalRead(SCL) == LOW);
  if (millis()-startmillis > 3000)
  {
    delay(100);

    // patch FRAM
    Wire.beginTransmission(0x57);
    Wire.write(0xF6);
    Wire.write(0x49);
    Wire.write(0x0A);
    Wire.write(0x00);
    Wire.write(0x00);
    Wire.endTransmission();
  }

  // sleepmode
  SMCR = (1<<SM1) | (1<<SE);
  sleep_cpu();
}
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on June 02, 2013, 10:21:28 pm

I think you're responsible for another DS2000 sale.


I think you're responsible for another Arduino UNO sale.  ;D

Seems easy enough to program into an attiny10 or attiny85 which I have lying around... but then:

I'm working on the code for a ATtiny85.

You leave nothing for me to do...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: andyturk on June 02, 2013, 10:39:09 pm
Not that I'm really qualified to do this but...

Is it possible to work backwards from studio25's discovery to find the BlackFin code that determines whether license keys have been installed? It's likely that upon entering a key, there's some "permanent" change made to NOR flash. I.e., license keys aren't entered very often and setting a flag in flash won't cause write endurance issues. In contrast, writing to NOR flash for every tick of the options timer would be a bad idea.

I2C/TWI peripherals live at a fixed location in memory, so it should be possible to dig through the BlackFin's firmware image looking for code that touches the TWI. Now that we know what gets sent over the wire for trial options expiration, it might be easier to look for the code that generates those bytes. Chances are, that same code is going to be related (somehow) in determining whether any license keys have been entered.

Just a thought.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 02, 2013, 10:42:29 pm
Not that I'm really qualified to do this but...

Is it possible to work backwards from studio25's discovery to find the BlackFin code that determines whether license keys have been installed? It's likely that upon entering a key, there's some "permanent" change made to NOR flash. I.e., license keys aren't entered very often and setting a flag in flash won't cause write endurance issues. In contrast, writing to NOR flash for every tick of the options timer would be a bad idea.

I2C/TWI peripherals live at a fixed location in memory, so it should be possible to dig through the BlackFin's firmware image looking for code that touches the TWI. Now that we know what gets sent over the wire for trial options expiration, it might be easier to look for the code that generates those bytes. Chances are, that same code is going to be related (somehow) in determining whether any license keys have been entered.

Just a thought.

doing that since about a week or so - but the discovered TWI functions so far a slave mode, not master mode - a lot of stuff is happening via DMA transfers to from the fpga (assumption). they use VDK and threads, which makes reversing a pain in the ass, 8k subs, thousands of pointers ... im slowly approaching the right subs. if anyone has ida with the blackfin cpu from rigol homebrew, im happy to share my custom GEL loader, and IDA DB.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mikeselectricstuff on June 02, 2013, 10:52:32 pm
I wonder if the I2C lines connect to a device which has JTAG, and is on the chain connected to the header on the back...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 02, 2013, 11:11:08 pm
It's likely that upon entering a key, there's some "permanent" change made to NOR flash. I.e., license keys aren't entered very often and setting a flag in flash won't cause write endurance issues. In contrast, writing to NOR flash for every tick of the options timer would be a bad idea.

But what's odd is that Rigol doesn't seem to write to NOR flash once the 'trial' options expire - which normally should happen just once (or perhaps twice - if you happen to get an extra trial options key); that just seems like such a basic security measure.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mikeselectricstuff on June 02, 2013, 11:42:26 pm
It's likely that upon entering a key, there's some "permanent" change made to NOR flash. I.e., license keys aren't entered very often and setting a flag in flash won't cause write endurance issues. In contrast, writing to NOR flash for every tick of the options timer would be a bad idea.

But what's odd is that Rigol doesn't seem to write to NOR flash once the 'trial' options expire - which normally should happen just once (or perhaps twice - if you happen to get an extra trial options key); that just seems like such a basic security measure.
It's entirely possible, maybe probable,  that trials and full licenses use a completely different mechanism.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JimmyMz on June 02, 2013, 11:44:50 pm
Quote
Have you confirmed that all of the options are working?
Yes.
I hope this ends up benefiting some people. It will be cool to see where this heads. 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on June 02, 2013, 11:51:21 pm
It's likely that upon entering a key, there's some "permanent" change made to NOR flash. I.e., license keys aren't entered very often and setting a flag in flash won't cause write endurance issues. In contrast, writing to NOR flash for every tick of the options timer would be a bad idea.

But what's odd is that Rigol doesn't seem to write to NOR flash once the 'trial' options expire - which normally should happen just once (or perhaps twice - if you happen to get an extra trial options key); that just seems like such a basic security measure.

At least the used license key to reactivate the trial options is stored in flash. I can not use it twice ...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 03, 2013, 12:04:28 am
It's entirely possible, maybe probable,  that trials and full licenses use a completely different mechanism.

But I never doubted that. Nonetheless, it requires virtually no storage space - and very little code - to implement security against trial options being repeatedly restarted without license codes.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MrsR on June 03, 2013, 05:59:41 pm
An answer to a early Question page 2 I think.
The MCU 8051RNL is a USB Serial in out controller it is most likely the point where the SPI code is used.
I am not software only hardware but I have given Teneyes the full data and expect him to post it soon.

Rachael :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 03, 2013, 07:25:34 pm
Just managed to discover the BF526 on the JTAG chain :-DD  >:D

Pinout:

Code: [Select]
   3,3V   (1)   (2) /EMU, /SRST (use a 10k pullup to 3,3V)
   no pin (3)   (4)  unused (seems to be GND)
   nc     (5)   (6) TMS
   GND    (7)   (8) TCK
   GND    (9)   (10) /TRST (use a 10k pullup to 3,3V)
   GND    (11)  (12) TDI
   GND    (13)  (14) TDO

The 14pin header near the Blackfin. I actually think i fried my 3,3V on Pin1 - even if loaded with 10k it drops down to 1V,
so im running the pullup for pin (2) to the 4 pin connector on the opposite side of the PCB labeled VCC (3,3V) instead of pin1

CAUTION: the usual ADI JTAG has pin1 connected to GND (this shorts VCC to GND), which probably killed my VCC there ...
Scope is still fine, so just fried some output stage somewhere i guess ;)

For the jtag adapter itself im using the Amontec JTAG Key Tiny (30$) - TopJTAG eval discovers an Analog Devices BF526 (IDCODE=227E0CBh) ... next up trying urJTAG + bfin-gdb.

JTAG Key: http://www.amontec.com/ (http://www.amontec.com/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 03, 2013, 07:30:45 pm
Code: [Select]
jtag> cable jtagkey
Connected to libftd2xx driver.
jtag> frequency 5000000
Setting TCK frequency to 5000000 Hz
jtag> detect
IR length: 5
Chain length: 1
Device Id: 00100010011111100100000011001011 (0x00000000227E40CB)
  Manufacturer: Analog Devices
  Part(0):         BF526
  Stepping:     2
  Filename:     c:\program files\urjtag\data/analog/bf527/bf527
jtag> print chain
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
-
   0 Analog Devices            BF526                2        BYPASS

Code: [Select]
jtag> get signal BMODE0
BMODE0 = 1
jtag> get signal BMODE1
BMODE1 = 0
jtag> get signal BMODE2
BMODE2 = 0
jtag> get signal BMODE3
BMODE3 = 0
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on June 03, 2013, 08:32:36 pm

@ Studio25,

is it possible to verify , what happens if you do the self-cal, when the options are there,
As you know the self-cal switch off the trail options, so....

Does the self-cal reset the pointer at 7F8 ?
Does the self-cal reset the timer at 7F6 ?

After the self-calibration the counter starts at zero. There seems to be a 32bit counter @ offset 0x7F6 .. 0x7F9.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on June 03, 2013, 10:11:46 pm
All files for download

- Arduino sketch
- ATtiny85 code + hex
- Schematic

http://rapidshare.com/files/418919055/Rigol%20DS2000%20trial%20hack.rar (http://rapidshare.com/files/418919055/Rigol%20DS2000%20trial%20hack.rar)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JimmyMz on June 03, 2013, 10:14:56 pm
All files for download
Thank You   :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on June 03, 2013, 10:28:15 pm

After the self-calibration the counter starts at zero. There seems to be a 32bit counter @ offset 0x7F6 .. 0x7F9.
@Studio25
  Before you stated that after the options expired x07F8 was set to 1 ,
  I guess (x07F6-x07F9) could still be a 32 bit operand,
  but why use part of  the 4 bytes for the Stop Options Flag?
  I you were set the value to the end of options ,maybe you can see what happens after '00 mins ,     ( x3962) 
does it continue to count? ,
 does it freeze?
 does it continue to up to xFFFF  in 7 days

oooo the downloads are up, Thanks Studio25


I tested wrong. |O
0xFF 0xFF 00 -> 0x00 0x00 0x01 test done.

But in reality it is:
0xFF 0xFF 00 00 -> 0x00 0x00 0x01 0x00 -> 0x01 0x00 0x01 0x00 -> 0x02 0x00 0x01 0x00 ... 0xFF 0xFF 0xFF 0x00 -> 0x00 0x00 0x00 0x01 -> 0x01 0x00 0x00 0x01...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: egonotto on June 03, 2013, 10:50:54 pm
Hello studio25,

many thanks.

You wrote
"After the self-calibration the counter starts at zero. There seems to be a 32bit counter @ offset 0x7F6 .. 0x7F9"
and
"The trial period is probably stored at 0x7F6 and 0x7F7"

Is it right, that this explains why after a self cal the trial options expired and after 472 minutes the trial option comes back?

Best Regards
egonotto


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tinhead on June 03, 2013, 11:23:03 pm
An answer to a early Question page 2 I think.
The MCU 8051RNL is a USB Serial in out controller it is most likely the point where the SPI code is used.
I am not software only hardware but I have given Teneyes the full data and expect him to post it soon.

???

KSZ8051RNL have nothing to do with any kind of 8051 MCUs, this is ethernet phy, not MCU.

There is second IC next to KSZ8051RNL , and yes it is 8051 based MCU (CY7C68013A) for USB/GPIO, but here is the 8051
core is not visible for the DSO or USB (more or less).

There is RTC IC on board next to FRAM, sems to be I2C? Anyway.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ve7xen on June 03, 2013, 11:34:33 pm
I have set up some storage on my server for files related to this "investigation", including SPI traffic captures and an I2C dump.

http://gotroot.ca/rigol/ (http://gotroot.ca/rigol/)

I've asked studio25 for permission to mirror his hack archive. Until I get it, it's not downloadable. The other files I have generated myself.

If anyone wants me to host files interesting to this effort, send me a PM and I will happily do so.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: darrylp on June 04, 2013, 10:34:13 am
Hehe, I see Rigol selling a lot more DS2072  in the near future !

--
  Darryl

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Chet T16 on June 04, 2013, 10:45:49 am
Ok perhaps a stupid question but if there is a 200Mhz trial option does this mean you can have a DS2202 indefinitely or has a proper DS2202 got some features the base model doesn't aside from the BW?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 04, 2013, 10:51:46 am
Ok perhaps a stupid question but if there is a 200Mhz trial option does this mean you can have a DS2202 indefinitely or has a proper DS2202 got some features the base model doesn't aside from the BW?

It seems clear from what studio25 has reported that the Trial Options for bandwidth are NOT implemented in the FW (at least, they're not activated by this). So no extra bandwidth from this technique - indefinitely or otherwise.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Chet T16 on June 04, 2013, 11:45:55 am
It seems clear from what studio25 has reported that the Trial Options for bandwidth are NOT implemented in the FW (at least, they're not activated by this). So no extra bandwidth from this technique - indefinitely or otherwise.

Ok thanks, I obviously haven't read the thread well enough! So the scopes are the same bar being software limited? I have no use for a >70MHz scope but I'm curious where this might lead.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MrsR on June 04, 2013, 11:58:21 am
It seems clear from what studio25 has reported that the Trial Options for bandwidth are NOT implemented in the FW (at least, they're not activated by this). So no extra bandwidth from this technique - indefinitely or otherwise.

Ok thanks, I obviously haven't read the thread well enough! So the scopes are the same bar being software limited? I have no use for a >70MHz scope but I'm curious where this might lead.
From what I have seen they have  identical hardware.
Rachael :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on June 04, 2013, 10:03:03 pm
News:

CH1 BW Limit @ offset 0x90 -> 0x00=20Mhz, 0x01=OFF, 0x02=100Mhz, 0x03=200Mhz
CH2 BW Limit @ offset 0xCC -> 0x00=20Mhz, 0x01=OFF, 0x02=100Mhz, 0x03=200Mhz
CRC32 @ offset 0x7FC .. 0X7FF from 0x0 .. 0x7F5

The bandwidth can not be adjusted with the menu. Otherwise, all of your patched bandwidth settings for this channel lost.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JimmyMz on June 04, 2013, 10:15:30 pm
Lookin' good  :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on June 04, 2013, 10:20:21 pm
Great News:
The bandwidth can not be adjusted with the menu. Otherwise, all of your patched bandwidth settings for this channel lost.

  Understandable  that limit checking if menu BW is changed

Did you try 0x05 to see if it stays for 350 MHz  ( the next step up)
as FW is based on DS4000  FW  with more BW than DS2000

No, maybe tomorrow.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on June 04, 2013, 10:23:53 pm
Is there someone with a DS2022 (ideal with all options) who can also dump the FRAM?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mimmus78 on June 04, 2013, 10:31:14 pm
Ohh please don't do it! I don't want to be obligated to buy another scope!

 ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: monster on June 04, 2013, 11:01:46 pm
Is there someone with a DS2022 (ideal with all options) who can also dump the FRAM?

DS2202 yes, but no additional options so far, the decoding features weren't too overwhelming during the the official trial period to be honest. My main constraint is: no spare time this week at all. But since the relatively noisy fan is bugging me anyway, I hope I can do that next week. Would that be soon enough?

Grüße,

Daniel
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on June 04, 2013, 11:10:30 pm
Is there someone with a DS2022 (ideal with all options) who can also dump the FRAM?

DS2202 yes, but no additional options so far, the decoding features weren't too overwhelming during the the official trial period to be honest. My main constraint is: no spare time this week at all. But since the relatively noisy fan is bugging me anyway, I hope I can do that next week. Would that be soon enough?

Grüße,

Daniel

Sure, I look forward to it.  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ve7xen on June 04, 2013, 11:13:08 pm
News:

CH1 BW Limit @ offset 0x90 -> 0x00=20Mhz, 0x01=OFF, 0x02=100Mhz, 0x03=200Mhz
CH2 BW Limit @ offset 0xCC -> 0x00=20Mhz, 0x01=OFF, 0x02=100Mhz, 0x03=200Mhz
CRC32 @ offset 0x7FC .. 0X7FF from 0x0 .. 0x7F5

The bandwidth can not be adjusted with the menu. Otherwise, all of your patched bandwidth settings for this channel lost.

Great work! Maybe it's worth cracking my scope open again after all ;).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: metalphreak on June 05, 2013, 08:44:25 am
Do you guys reckon a similar thing is possible with the new function generators? I wouldn't mind pairing a 60mhz function gen (unlocked to 160mhz) with a 70Mhz 2000 series scope (at 200mhz) :D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Pinkus on June 05, 2013, 09:23:02 am
Do you guys reckon a similar thing is possible with the new function generators? I wouldn't mind pairing a 60mhz function gen (unlocked to 160mhz) with a 70Mhz 2000 series scope (at 200mhz) :D
Yeah that would be great, wouldn't it? I would do my share to make that possible. So if someone need my (limited) help......
As the frequency limitation is probably somewhere buried in the firmware and some Eeprom, it probably won't be possible shortly. But as the rise/fall time is different at the three models (8 / 10 / 12ns), there might be some kind of hardware limiter involved. If this is the case the limitation of the rise/fall time can be overwritten/changed of course - the general frequency limitation might be much more difficult to change. Maybe Rigol at one day will offer an option to expand the bandwidth, but probably not.... even today they are still selling DS1052 and DS1102 without offering a bandwidth expansion for 100 bucks for the 1052 owner.

Peter
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on June 05, 2013, 09:01:00 pm
Great News:
The bandwidth can not be adjusted with the menu. Otherwise, all of your patched bandwidth settings for this channel lost.

  Understandable  that limit checking if menu BW is changed

Did you try 0x04 to see if it stays for 350 MHz  ( the next step up)
as DS2000 FW is based on DS4000  FW  with more BW than DS2000

0x04 = 250Mhz (I can not measure the real bandwidth)
0x05 = no menu text
0x06 = no menu text
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Harvs on June 05, 2013, 10:49:25 pm
@studio25 - did you get the chance to do any test with respect to the bandwidth? i.e. I don't expect you would have completed anything conclusive about actual bandwidth, just wondering if there was a noticeable change in the rise time with the those addresses changed?

Great work by the way :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Harvs on June 06, 2013, 12:07:54 am
@studio25 - did you get the chance to do any test with respect to the bandwidth? i.e. I don't expect you would have completed anything conclusive about actual bandwidth, just wondering if there was a noticeable change in the rise time with the those addresses changed?
@Harvs ,
For what code?
Studio25 did show a rise time of 2nsec for the 200MHz code a few posts back,
and Not knowing the test Pulse risetime,
I think the Test was great and that the BW limiting chip is set for 200MHz,
but does this hardware have any more BW in it, when there is No Limit???

Note 250MHZ prompt in a BW Menu is only on the DS6000
 (same FW for 2000, 4000 & 6000)

Great thanks, I missed that post but looking back I've found it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MrsR on June 07, 2013, 04:24:10 am
IF any interested have a look at these. for tinhead 8051 was developed by INTEL as a MCU the core has been
used by other manufacturers for different components. 
Rachael :-+
NOTE The first PDF is of a component on the front of the main board and is through put for Ch1 (fir) (sec). Ch2 (fir) (sec).
Although the hardware is the same for each Scope it could be modified for each model,The BLACKFIN BF526 has a serial number on it and I was wondering if it is different for each model.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 07, 2013, 03:31:31 pm
could someone pls post a screenshot of the license display screen ?
or confirm that
ROM:143CF2                 R1.L = 0x40a0;          # R1=0x40a0
ROM:143CF6                 R1.H = 0xfa;            # R1=0xfa40a0
ROM:143CF6                       -> unk_FA40A0 => "%d/%d/%d %d:%d:%d"

matches the date & time stamp as its displayed there - trying to id some subs()'s

thx

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jonese on June 07, 2013, 04:14:53 pm
I like where this is going.  Modifying the FRAM is a temporary measure, but of course it leads to pointers in the firmware as to how the values are written/calculated.

Does someone have a repository of the latest firmware for the DS2000 please?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 07, 2013, 07:52:30 pm
switching internal model type to DS2202 (0x1) allows 2ns Timebase (see attachment) - the settings are read in during boot (TWI i guess, but right sub()s still not found), and then the various strings/settings are applied - changeing the model type has immediate effect ;-)

if somebody whats to check if some of those bytes are in the FRAM try to change em to something like:

RAM:E4DD1F                                         # 0x16=DS2072
RAM:E4DD1F                                         # 0x0= DS2102
RAM:E4DD1F                                         # 0x1= DS2202  (2ns timebase avail)
RAM:E4DD1F                                         # 0x2= DS????? (500ps timebase avail)

update: when powercycling in 2ns mode, it comes back in 2ns mode, if u leave it then it wont let u back to 2ns
so that byte should be in FRAM somewhere then ... ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 07, 2013, 08:47:25 pm
update: when powercycling in 2ns mode, it comes back in 2ns mode, if u leave it then it wont let u back to 2ns
so that byte should be in FRAM somewhere then ... ;)

Did you know that you can enter the 2ns time base by loading a Settings file that has 2ns as the time base it was saved at?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 07, 2013, 08:48:30 pm
update: when powercycling in 2ns mode, it comes back in 2ns mode, if u leave it then it wont let u back to 2ns
so that byte should be in FRAM somewhere then ... ;)

Did you know that you could enter the 2ns time base by loading a Settings file that had 2ns as the time base it was saved at?


nope, but guess same issue when u leave 2ns mode, you cant get back ...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on June 07, 2013, 09:08:08 pm
Now I know the offset for the time base. More details in the source code.   ;D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 07, 2013, 09:22:04 pm
500ps  8)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tinhead on June 07, 2013, 09:31:21 pm
for tinhead 8051

ohh don't worry, i know MCS51 (8051) very well.

My comment was to what you posted before :

The MCU 8051RNL is a USB Serial in out controller it is most likely the point where the SPI code is used.

and that was wrong because:

- chip with 8051RNL marking is chip KSZ8051RNL
- this is not MCU
- the "8051" in KSZ8051RNL name have nothing to do with MCS51 platform
- KSZ8051 is a single supply 10Base-T/100Base-TX Ethernet physical layer transceiver
- it does not have anything to do with USB or serial in/out

The USB serial in/out is made with Cypress FX2LP (CY7C68013A) which is the next part KSZ8051RNL to on PCB.
All i said was that the 8051 core in CY7C68013A is not directly accesible from and for DSO hardware.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tinhead on June 07, 2013, 09:33:49 pm
Now I know the offset for the time base. More details in the source code.   ;D

awesome, and did you tried to use even higher values for bandwidth (even if there is no string for menu) ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on June 07, 2013, 09:38:16 pm
Now I know the offset for the time base. More details in the source code.   ;D

awesome, and did you tried to use even higher values for bandwidth (even if there is no string for menu) ?

No, I have neither the equipment to check this nor do I think that the hardware can do more.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Harvs on June 08, 2013, 12:49:01 pm
Do you guys reckon a similar thing is possible with the new function generators? I wouldn't mind pairing a 60mhz function gen (unlocked to 160mhz) with a 70Mhz 2000 series scope (at 200mhz) :D

I've cracked open my DG4062 to have a crack at this.  It's got the same FRAM as the DS2000.  I haven't done a dump yet, but it only does a single large read on boot, then doesn't touch it at all.  So deciphering what's it in could be a challenge, if it's even the right place to be looking.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 08, 2013, 01:12:12 pm
Do you guys reckon a similar thing is possible with the new function generators? I wouldn't mind pairing a 60mhz function gen (unlocked to 160mhz) with a 70Mhz 2000 series scope (at 200mhz) :D

I've cracked open my DG4062 to have a crack at this.  It's got the same FRAM as the DS2000.  I haven't done a dump yet, but it only does a single large read on boot, then doesn't touch it at all.  So deciphering what's it in could be a challenge, if it's even the right place to be looking.

can u share the FW file or at least 0x0 - 0x0FFF of it ? or comment on if my loader addr tool (posted earlier) gives some output.
the fw must be very similiar - i see tons of code for DS4X features in my disassembly. so chances are the use the exact same FRAM mapping.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Harvs on June 08, 2013, 01:35:43 pm
I've cracked open my DG4062 to have a crack at this.  It's got the same FRAM as the DS2000.  I haven't done a dump yet, but it only does a single large read on boot, then doesn't touch it at all.  So deciphering what's it in could be a challenge, if it's even the right place to be looking.

can u share the FW file or at least 0x0 - 0x0FFF of it ? or comment on if my loader addr tool (posted earlier) gives some output.
the fw must be very similiar - i see tons of code for DS4X features in my disassembly. so chances are the use the exact same FRAM mapping.

I've opened the DG4062 function gen, not the DS4xxx scope if that's what you were after?

BTW how do you actually get the firmware file?  Is there a way to read it back out?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 08, 2013, 01:40:40 pm
I've cracked open my DG4062 to have a crack at this.  It's got the same FRAM as the DS2000.  I haven't done a dump yet, but it only does a single large read on boot, then doesn't touch it at all.  So deciphering what's it in could be a challenge, if it's even the right place to be looking.

can u share the FW file or at least 0x0 - 0x0FFF of it ? or comment on if my loader addr tool (posted earlier) gives some output.
the fw must be very similiar - i see tons of code for DS4X features in my disassembly. so chances are the use the exact same FRAM mapping.

I've opened the DG4062 function gen, not the DS4xxx scope if that's what you were after?

BTW how do you actually get the firmware file?  Is there a way to read it back out?

ah i misread that sorry, probably looking at assembly code for too long ;-)
for the DG i have firmware files - rigols content delivery system is not the best ;-) even if its not on the homepage you can still download stuff ... ;-) including internal vids ...  >:D

look for a 14pin header, as described earlier in my post - if its blackfin its there for sure - and get an 30$ amontec jtag key tiny - thats pretty much all u need, besides a few pullup resistors. rest is uclinux-blackfin toolchain ... bfin-jtag as gdb proxy and gdb + your fav. frontend.

alternatively check my fw loader address tool - or get ldrviewer (free tool) + some offset  (check the source)
if that does something usefull, you could use IDA pro + my custom GEL loader - let me know if you find a way.
im only looking after the license keys algos for the DS2k's at the moment ...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Harvs on June 08, 2013, 01:48:12 pm
look for a 14pin header, as described earlier in my post - if its blackfin its there for sure - and get an 30$ amontec jtag key tiny - thats pretty much all u need, besides a few pullup resistors. rest is uclinux-blackfin toolchain ... bfin-jtag as gdb proxy and gdb + your fav. frontend.

alternatively check my fw loader address tool - or get ldrviewer (free tool) + some offset  (check the source)
if that does something usefull, you could use IDA pro + my custom GEL loader - let me know if you find a way.
im only looking after the license keys algos for the DS2k's at the moment ...

Thanks.  Being a DS2072 owner I'm benefiting from all the work on that as well so I'm grateful!

The DG4k is based on the blackfin as well, and that header is there.  There's a lot of similarities with the insides of the DS2k scope at first look.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: andyturk on June 08, 2013, 06:30:38 pm
The DG4k is based on the blackfin as well, and that header is there.  There's a lot of similarities with the insides of the DS2k scope at first look.

Workin' on it...  (it's a DS4014):-/O

(https://lh3.googleusercontent.com/-I9Spswtc__c/UbN3XVLH9WI/AAAAAAAAAFc/8k5Lv8YyzR0/w662-h882-no/IMG_0613.JPG)

(https://lh4.googleusercontent.com/-wZijX5-1u-Q/UbN3Xx9y1hI/AAAAAAAAAFk/NNJav9FKiHE/w662-h882-no/IMG_0614.JPG)

(https://lh4.googleusercontent.com/-LNjEDaC2CzU/UbN3X29lMxI/AAAAAAAAAFg/Myr5hLi1n6Y/w761-h571-no/IMG_0615.JPG)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mikeselectricstuff on June 08, 2013, 08:22:18 pm
Do you guys reckon a similar thing is possible with the new function generators? I wouldn't mind pairing a 60mhz function gen (unlocked to 160mhz) with a 70Mhz 2000 series scope (at 200mhz) :D

I've cracked open my DG4062 to have a crack at this.  It's got the same FRAM as the DS2000.  I haven't done a dump yet, but it only does a single large read on boot, then doesn't touch it at all.  So deciphering what's it in could be a challenge, if it's even the right place to be looking.
I had a quick look at mine before I read this. Chip appeared to be a 24C16  Seems to read the chip at startup, then write 8  bytes to the start of each page, apparently same each startup (only 2 compared).
However I powered it up with the chip removed and it started up as normal...! Didn't check calibration or anything but serial no. was still there.

Code attatched if anyone wants to compare


   
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Harvs on June 09, 2013, 01:16:44 am
Do you guys reckon a similar thing is possible with the new function generators? I wouldn't mind pairing a 60mhz function gen (unlocked to 160mhz) with a 70Mhz 2000 series scope (at 200mhz) :D

I've cracked open my DG4062 to have a crack at this.  It's got the same FRAM as the DS2000.  I haven't done a dump yet, but it only does a single large read on boot, then doesn't touch it at all.  So deciphering what's it in could be a challenge, if it's even the right place to be looking.
I had a quick look at mine before I read this. Chip appeared to be a 24C16  Seems to read the chip at startup, then write 8  bytes to the start of each page, apparently same each startup (only 2 compared).
However I powered it up with the chip removed and it started up as normal...! Didn't check calibration or anything but serial no. was still there.

Code attatched if anyone wants to compare

Thanks Mike.  That's interesting about it still starting and having it's serial #.

I think the firmware's got to be the next place to start.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 09, 2013, 06:00:25 am
bfin has a unique chipid and they use that + a model prefix DSA2<.....>
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MrsR on June 09, 2013, 03:32:28 pm
SORRY TINHEAD, my mistake I looked at the wrong Data sheet although I did post the correct one.
We stock about 30,000 ICs and about 50 Data Sheets came up from the search parameters.
I will make sure I am quoting the right Data Sheet next time.

REGARDS
Rachael :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ftransform on June 09, 2013, 09:56:44 pm
how close is this?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DL5TOR on June 10, 2013, 08:14:20 am
switching internal model type to DS2202 (0x1) allows 2ns Timebase (see attachment) - the settings are read in during boot (TWI i guess, but right sub()s still not found), and then the various strings/settings are applied - changeing the model type has immediate effect ;-)

if somebody whats to check if some of those bytes are in the FRAM try to change em to something like:

RAM:E4DD1F                                         # 0x16=DS2072
RAM:E4DD1F                                         # 0x0= DS2102
RAM:E4DD1F                                         # 0x1= DS2202  (2ns timebase avail)
RAM:E4DD1F                                         # 0x2= DS????? (500ps timebase avail)

update: when powercycling in 2ns mode, it comes back in 2ns mode, if u leave it then it wont let u back to 2ns
so that byte should be in FRAM somewhere then ... ;)



I just checked the hex file that studio25 provided in post on page 4 and the only place that I found the hex digit of 0x16 (for the ds2072) is in the position 0x43c so this is a possible area of attack
I hope this helps

Torsten
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Ruben57 on June 10, 2013, 10:53:08 am
for the DG i have firmware files - rigols content delivery system is not the best ;-) even if its not on the homepage you can still download stuff ... ;-) including internal vids ...  >:D


I took a look and found all the training videos, sales tool kits and other files. However, I could only find one firmware file. It is for the DG4000 series (DG4000_FW_Update.zip).

It can be found via "113" if you know what I mean... >:D

Can you share where the other firmware files are located? :D

The DG4000 firmware zip contains the file DG4000Update.GEL, dated 20/3/2012. There doesn't seem to be a readily identifiable version number in it, other than version 1.2.3a. However, it appears as though it is a generic number as it also has a serial number of 543210.

I have a DG4162 and its details are:

Software: 00.01.07  (suspect there is more to it)
Hardware: 01.03
Keyboard: 04.01

I also have a DS4024 and its details are:

Software: 00.01.00.00.07
Hardware: 0.1.2.3
SPU: 03.00.06
WPU: 00.07.04
CCU: 01.40.05
MCU: 1.3

I can dump the contents of the FRAM if it helps. :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 10, 2013, 02:13:31 pm
yeah, the chinese stuff is funny ;-)  >:D - cant remember the vals, but they had multiple root folders in the cms - so its not just changing the last value ;-)

i will start playing with DG firmware once i have bought a DS4162 - still busy with their ds2XXX license key brainfuck ...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DL5TOR on June 11, 2013, 08:56:47 am
Hi all,

to bad that the license on the dsa815 is different then on the scopes as this is also something of interest.
The way I see it the serial number of the scope is in the key of the scope but in the spectrum analyzer it is not. This is backed up by the fact that when you buy a key from batronix for a scope they need the serial of the scope (as stated there) but on the keys for the dsa there is no mention of the serial number.

Just as an FYI the key format on the dsa815 is: FAQ83TF37A3Y8ST4RA********** if you want I can see if I can get a FRAM image from my dsa815, if needed

73 de DL5TOR
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 11, 2013, 09:17:02 am
can u confirm the following features of the spectrum analyzer license key:

length ?
is it grouped in 4 chunks a 7 chars like the DS2X ? (1234567-1234567-1234567-1234567) ?
no letter I, no letter 0, no 0 (zero), no 1 (one) as input

the lic-functions that i have analyzed so far are 2 categories - kinda prepare the input license key by scrambling/cutting/shifting parts of it around,
they are depending on the length (28/0x1C). but the real deal which does recursive transformations on the key is not length dependent.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DL5TOR on June 11, 2013, 10:08:21 am
ength ?
is it grouped in 4 chunks a 7 chars like the DS2X ? (1234567-1234567-1234567-1234567) ?

Length is 28


no letter I, no letter 0, no 0 (zero), no 1 (one) as input

I do not see one

Id you want, i can send you the key by mail. I also have a firmware file on hand if you need it
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Ruben57 on June 11, 2013, 01:14:38 pm
yeah, the chinese stuff is funny ;-)  >:D - cant remember the vals, but they had multiple root folders in the cms - so its not just changing the last value ;-)


Yes, I see what you mean now... I was wondering what that was about.

I found two other firmware files with unusual file names (eg. "fileCA9NWMFE.zip") but they both contain the same version of DG4000 firmware.

Anyhow, not so interesting anymore so not going to waste anymore time there.  :) 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on June 11, 2013, 07:57:22 pm
Here are the current files. The old files have errors and should be deleted.

2160 min. trials, 250Mhz bandwidth, 1ns time base

http://rapidshare.com/files/2386551592/Rigol%20DS2000%20trial%20hack.rar (http://rapidshare.com/files/2386551592/Rigol%20DS2000%20trial%20hack.rar)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on June 11, 2013, 09:36:30 pm
Hell yeah, modchips for oscilloscopes. I'm not surprised at the lack of protections for this.

I recall you stating that patching the bandwidth would be overridden by the default value for the 'scope if the bandwidth limit was toggled in the menu. Is this still the case with this version, or will it use the modified value provided by the modchip?

Same with the timebase - can you change the timebase and return to 1ns?

Great work studio25. I'll try this out in a couple weeks =)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on June 11, 2013, 09:53:43 pm
Hell yeah, modchips for oscilloscopes. I'm not surprised at the lack of protections for this.

I recall you stating that patching the bandwidth would be overridden by the default value for the 'scope if the bandwidth limit was toggled in the menu. Is this still the case with this version, or will it use the modified value provided by the modchip?

Same with the timebase - can you change the timebase and return to 1ns?

Great work studio25. I'll try this out in a couple weeks =)

Once the bandwidth limit or the time base is adjusted, it is not possible to return to the patched values. It must be done a reboot.
When you reboot, the values ??are changed in the fram. But it only works when under
"UTILITY" -> "System" -> "Power On" "Last" is selected.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jirikv on June 12, 2013, 01:04:24 am
Hi,
I discovered extended system info on DG4062 arb gen.
Go to: Utility-System-Sys Info, then press first, third and fifth softbutton (6 blue/grey side buttons).
It`s only for info.... :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ve7xen on June 12, 2013, 02:59:39 am
I've mirrored the new file at the same location as before: http://www.gotroot.ca/rigol/ (http://www.gotroot.ca/rigol/)

Thanks again for your work studio25, this is great :D.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: max-bit on June 12, 2013, 04:53:06 am
Has anyone tested this hack oscilloscope?
in terms of the rise time (JW Pulse Generator)
screenshots?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Harvs on June 12, 2013, 05:02:56 am
Thanks again studio25.

It would be great though if we could start adding a version number or date to the rar file name. 

It could start getting confusing as to what versions people are using.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Harvs on June 13, 2013, 10:04:57 am
Has anyone tested this hack oscilloscope?
in terms of the rise time (JW Pulse Generator)
screenshots?

I cobbled one together this evening out of parts I had lying around.  It's just using a 2N3904 transistor instead of the proper one, so I'm certainly not claiming anything about how good it is.

However, from the screen grabs below there is a difference pre and post mod.  I don't know what the actual peak voltage of the pulse is, so the rise times can't be used to calculate the BW.  If I get around to it I'll modify it to extend the pulse duration (using coax) and add an attenuator.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: nack on June 13, 2013, 11:04:38 am
Interesting! Keep an eye on this thread to make use of it once my DS2072 arrives.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on June 15, 2013, 05:28:14 pm
I build the ATtiny85 version today, and also tested the rise times. I got very optimistic rise times in the order of 600..800 pSec.
I used an Tektronix Type 284 pulser with a very short cable. This has a spec of 70 pSec rise time @200 mV.

Time base was set to the initial 1 nSec, and 250 MHz BW.

It made me suspicious since this rise time is not really possible with this scope. I did a further check with an 200MHz signal gen. It turns out that the actual timebase setting was 2nSec despite the fact that the setting was indicating 1nSec. All time measurements on screen are based on the 1nSec/div.

I made a new version of the ATtiny85 hack and set it to 2 nSec. This all was tested with the latest firmware 00.01.00.00.03 on a DS2072.

I now have a more realistic rise time of 1.4nSec. (0.33/1.4 = 235MHz)

So it seems that the DS2000 series can handle max 2 nSec.
A big thank you to Studio25 for his nice work.


Update :
Done some more testing by changing the BW settings from 0x04 to 0x05; the result is that the scope shows no BW any longer in the menu, but stays at the 250MHz setting.

Attached are the 1nSec screen shots of a 200 MHz signal. There is a difference in single or dual mode. Single mode seems to be OK.
For the moment I'll keep it 2nSec. Still not bad for a 70MHz model  :)

Perhaps RIGOL can fix this bug for us  ;)

- Orange
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: BlueLaser on June 17, 2013, 09:10:56 pm
So just to clarify, this works on all firmware versions?  Also, has Rigol taken down their firmware download section for the ds2000 series?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on June 18, 2013, 07:38:40 am
So just to clarify, this works on all firmware versions?  Also, has Rigol taken down their firmware download section for the ds2000 series?
I only tested it with 00.1.00.00.03 firmware, but I have no reason to believe it should not work with older versions. Download firmware for the DS2000 ?
I wished Rigol had that...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on June 20, 2013, 01:56:54 pm
Some photos of the ATtiny85 placed on the FRAM
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jamesb on June 20, 2013, 03:46:29 pm
That is just awesome!! :) :)

I bet when Rigol sees this they will be fuming. Almost pin-for-pin!!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: van-c on June 20, 2013, 03:49:34 pm
Some photos of the ATtiny85 placed on the FRAM
That really gets right to the heart of the matter.  Does your ATtiny85 code patch the FRAM every time the DS2000 boots up?

--Van
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on June 20, 2013, 04:24:15 pm
Some photos of the ATtiny85 placed on the FRAM
That really gets right to the heart of the matter.  Does your ATtiny85 code patch the FRAM every time the DS2000 boots up?

--Van
Yes it does; if you power-up the scope, it writes the patched values.
For sure Rigol does not like this, but it's all in the game  :)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 20, 2013, 05:13:12 pm
Yes it does; if you power-up the scope, it writes the patched values.
For sure Rigol does not like this, but it's all in the game  :)

Unfortunately, there's possible downsides to public posting of hacking techniques: longer times between FW updates - and more convoluted (and perhaps buggy) code - or measures (e.g. eliminating trials altogether) to try to prevent it.

I'm not saying I'm against hacking - just trying to be realistic.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jamesb on June 20, 2013, 05:22:44 pm
Unfortunately, there's possible downsides to public posting of hacking techniques: longer times between FW updates - and more convoluted (and perhaps buggy) code - or measures (e.g. eliminating trials altogether) to try to prevent it.

I'm not saying I'm against hacking - just trying to be realistic.

That is a very good point - I just hope that Rigol does not burn their user-base as a result of their very poor implementation (ie. hackability).

I could see trial licenses being completely null in the upcoming FW as a result of efforts such as this. Then again, being able to swap back to an older FW for extra functionality may be a functional reality. Then there is the whole FW hacking effort.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: manticore00 on June 20, 2013, 05:57:51 pm
Rigol's response is probably going to depend a lot on who they sell each SKU to and how cunning their business strategy is...

If the DS2102 and DS2202 aren't big sellers to hobbyists but rather are being used by small shops and other places/people that would be more concerned about maintaining their warranty then they may see that these hacks don't cause cannibalization of the DS2102 and DS2202 sales. Rather the availability of this hack may actually boost sales of DS2072 among folks who were on the fence about buying a new scope but never would've paid for the DS2102 or DS2202 anyway.

My hope is that these hacks don't hit their bottom line enough to warrant them spending the money to significantly address them and instead they turn a blind eye in favor of the added user community enthusiasm and potential for increase DS2072 sales volume... Yes Siglent and Owon's scopes aren't as good but they're significantly cheaper and the thought of this hack might be enough for someone to agree to pony up the extra cash for a Rigol instead of buying a cheaper competitor...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on June 20, 2013, 06:47:33 pm
Yes it does; if you power-up the scope, it writes the patched values.
For sure Rigol does not like this, but it's all in the game  :)

Unfortunately, there's possible downsides to public posting of hacking techniques: longer times between FW updates - and more convoluted (and perhaps buggy) code - or measures (e.g. eliminating trials altogether) to try to prevent it.

I'm not saying I'm against hacking - just trying to be realistic.
Oh I see I forgot to post the 2nSec hex file for the ATtiny85 ;D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: BravoV on June 20, 2013, 07:05:21 pm
Oh I see I forgot to post the 2nSec hex file for the ATtiny85 ;D

Thanks, forwarding this to a friend who just bought a DS2072.  >:D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 20, 2013, 07:08:23 pm
I could see trial licenses being completely null in the upcoming FW as a result of efforts such as this. Then again, being able to swap back to an older FW for extra functionality may be a functional reality. Then there is the whole FW hacking effort.

Unfortunately because of this, Rigol might remove downgradeability at some point (as they did in the DS1000E series).

If the DS2102 and DS2202 aren't big sellers to hobbyists but rather are being used by small shops and other places/people that would be more concerned about maintaining their warranty then they may see that these hacks don't cause cannibalization of the DS2102 and DS2202 sales.

There are many people among the user base here that own DS2102s or DS2202s, so I'm not sure that's the reality.

Quote
My hope is that these hacks don't hit their bottom line enough to warrant them spending the money to significantly address them and instead they turn a blind eye in favor of the added user community enthusiasm and potential for increase DS2072 sales volume... Yes Siglent and Owon's scopes aren't as good but they're significantly cheaper and the thought of this hack might be enough for someone to agree to pony up the extra cash for a Rigol instead of buying a cheaper competitor...

As evidenced by the hack of the DS1000E series, it's unlikely Rigol will turn a blind eye to this. I suspect that hack made them a lot more money than this one will - and they still battled against it (as mentioned above).

As I mentioned in my video - and Dave has mentioned in his - this isn't a question of the DS2000 just being a better - but more expensive - DSO than the cheapest ones. They are WORLDS APART - in the build quality, shielding, UI, features, etc, etc.  I've had four different DSO's in the last 2 years and the DS2000 feels like a low-cost professional instrument - where the others feel like a cheap substitute for something serious.

Oh I see I forgot to post the 2nSec hex file for the ATtiny85 ;D

I guess that was a joke? Oh, yes, nevermind, I just noticed the flag.  :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 20, 2013, 07:44:13 pm
 :blah: downgrading firmware is something they cant prevent with their current firmware architecture, with jtag i can flash whatever i like and without changing the PCB they cant get rid of jtag.
There is already ppl going for the DS4k with the same approach. With the .GEL file reversed, a simple custom bootloader is no big deal - and everybody could install it, then fireing/loading whatever is presented via USB. (=dont care about OTP or lockbox, if they ever go this route, which i doubt given the R&D necessary for such a change )

lastly, even the guys with a DS2102 or DS2202 will benefit from a "keygen" - and again thx to jtag and some mathbrainfu*k, only a matter of time - and rigol cant do anything about it without screwing their existing userbase. and from the looks of it at the moment, the key schema is not only used in the DS2k ;-)

 



Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 20, 2013, 08:46:39 pm
:blah: downgrading firmware is something they cant prevent with their current firmware architecture, with jtag i can flash whatever i like and without changing the PCB they cant get rid of jtag.
There is already ppl going for the DS4k with the same approach. With the .GEL file reversed, a simple custom bootloader is no big deal - and everybody could install it, then fireing/loading whatever is presented via USB. (=dont care about OTP or lockbox, if they ever go this route, which i doubt given the R&D necessary for such a change )

lastly, even the guys with a DS2102 or DS2202 will benefit from a "keygen" - and again thx to jtag and some mathbrainfu*k, only a matter of time - and rigol cant do anything about it without screwing their existing userbase. and from the looks of it at the moment, the key schema is not only used in the DS2k ;-)

Yes, none of this will have any affect on anything Rigol does in the future  ::)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 20, 2013, 08:49:45 pm
Yes, none of this will have any affect on anything Rigol does in the future  ::)

well i hope it does, more fun next time ;-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mikeselectricstuff on June 20, 2013, 09:18:04 pm
It would be interesting to compare revenue lost through lost potential license sales versus extra equipment sales due to it being hackable.
I have little doubt that the publicity around the 1052 hack was a net benefit.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 20, 2013, 09:29:08 pm
It would be interesting to compare revenue lost through lost potential license sales versus extra equipment sales due to it being hackable.
I have little doubt that the publicity around the 1052 hack was a net benefit.

Benefit for whom?

IF Rigol uses zero resources to try to counteract published hacks, then it's possibly a win for both current and future owners. Personally, I'd rather have new features in the FW than more security routines.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mickpah on June 20, 2013, 09:43:47 pm
Quote

Benefit for whom?

IF Rigol uses zero resources to try to counteract published hacks, then it's possibly a win for both current and future owners. Personally, I'd rather have new features in the FW than more security routines.

I kind of agree, but have they ever done this? resources to actually make them available to users would be a first step. If they want to play against the likes of Agilent the big differentiator is becoming support. I own a Rigol and am looking to buy one of their Arb's but having used Agilent received their updates and used their technotes paying a premium is really tempting.

If they want to go after the hobby/low end market a few how-tos for using their "advanced" features would likely generate more sales, time better spent that trying to lock the scope down again. Just my opinion away.  Throwing a keylock product in front of this market is like putting a chess game in front of  kasparov - you know we're going to play.
 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jonese on June 20, 2013, 09:51:21 pm
I know I wouldn't have ordered a DS2102 if the possibility of hacking it didn't exist.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on June 21, 2013, 05:09:35 am
Lets try to avoid morel/ethical/commercial issues in this tread. keep it clean or at least on topic
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 21, 2013, 08:49:06 am
Lets try to avoid morel/ethical/commercial issues in this tread. keep it clean or at least on topic

Uh... sorry, but when you post something like this:

For sure Rigol does not like this, but it's all in the game  :)

...I think it's completely on-topic to discuss exactly if and what this 'game' might cost us long-time owners of the DSO.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: amyk on June 21, 2013, 08:55:30 am
Some photos of the ATtiny85 placed on the FRAM
I haven't looked closely at an AVR in some time, but is that a mil-spec part (the triangle marking)? :o
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on June 21, 2013, 11:40:43 am
Some photos of the ATtiny85 placed on the FRAM
I haven't looked closely at an AVR in some time, but is that a mil-spec part (the triangle marking)? :o
Atmel only makes it in the industrial version (-40..85 deg. C), so nothing special. I think the triangle indicates pin 1 as an extra bonus :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: KuchateK on June 21, 2013, 12:50:06 pm
I understand that in the old scopes some options were a huge modules full of custom expensive chips.

But in the modern scopes all is in the hardware (and you already bought it and paid for it). Maybe its the time to stop outdated model of selling you the car with three forward gears and demanding huge premium for fourth and fifth to let you go to a highway.

People are not stupid, they know they have everything already installed and they want to use it.

Looking at console hacking I bet that Rigol will have a hard time even with very complicated anti-hacking security in their products.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 21, 2013, 01:22:59 pm
I understand that in the old scopes some options were a huge modules full of custom expensive chips.

But in the modern scopes all is in the hardware (and you already bought it and paid for it). Maybe its the time to stop outdated model of selling you the car with three forward gears and demanding huge premium for fourth and fifth to let you go to a highway.

People are not stupid, they know they have everything already installed and they want to use it.

Looking at console hacking I bet that Rigol will have a hard time even with very complicated anti-hacking security in their products.

This topic has been discussed ad infinitum on this forum (i.e. whether you like it or not, this is a method more and more companies are using to recoup development costs) - but wasn't the point of my original post. Nor was I trying to make a moral or ethical point about hacking: I've hacked - and I've benefited from hacking - in the past - and I expect Rigol knows people will do it. And I also wasn't trying to start a debate about whether Rigol will ultimately profit from this (probably they will) - I don't really care about any of these points.

My original comment/question was only about the possible 'cost' to DS2000 owners for PUBLIC posting of hacking information (I know it benefits people 'thinking' about buying the DSO). As I (and other owners here) have posted repeatedly over the last 7 months, the trial options have ALWAYS BEEN restartable - we just haven't posted the precise technique(s) in order to try to prevent Rigol from wasting development time.

So, leaving aside the other issues, the questions are:
1) Does Rigol have a limited amount of resources with which to develop new FW for the DS2000?
2) Will Rigol make any effort to counter publicly posted hacking techniques?

If you believe the answer to both of these questions is yes, then you have to wonder if this will, in any way, stunt FW development - that was my only point.

Pretending that there might be no ramifications just seems rather naïve. :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 21, 2013, 01:57:08 pm
Any delay to FW development will be more than offset by the benefit that users receive from this.

I think you forgot to add "in your opinion" - which it certainly is. I think you're not an owner yet, correct?  :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 21, 2013, 04:15:09 pm
All depends on Rigol market policy, if they dont make any profit anymore on the DS2000,
they leave it. Just sell out your stock and jump to the next. problem solved ( maybe the S series )

As mentioned elsewhere, the security techniques used in the DS2000 stretch across the entire line (UltraVision) and even likely to other current devices (perhaps the DG series?). So I doubt this will solve future potential problems for Rigol.

Quote
There is no need for more R&D on security, much to expensive.
So if there will be an update it will be the last...!!!

I'm not sure what logic you're basing this on. Again, R&D on security will affect MANY product lines. And from what I understand, the DS1000E series had quite a few FW releases after the hack became public - and from what I've read (although anybody who knows the full story can jump in here), they became more buggy up to a point (with more attempts by Rigol to plug the hack). So I seriously doubt that there will be just one more FW update on a product that is approximately 1 year old in Western markets.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: BravoV on June 21, 2013, 04:51:42 pm
Pretending that there might be no ramifications just seems rather naïve. :)

Consequences or not, once the product sucks either no updates for the nasty bugs or the updates actually break up things, then its time to move on to "other" brand, and I'm pretty sure Chinese scope manufacturers will keep evolving and improving at faster pace than now, and its not like they are the only scope maker out there.

C'mon, its just a scope, not the end of the world or like you've sold your soul to them.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: KuchateK on June 21, 2013, 07:34:32 pm
Rigol isn't microsoft or sony, they obviously aren't selling hardware at a loss to make money on options. I bet they also aren't financing development cost just from expensive models. Most markets clearly show that usually the cheapest models sold in large quantities are the best cash cow.

If they'll develop successful lock we are starting to compare unhackable ds2000 with everything else on the market. That $400 extra gets a lot harder to judge because you'll get a lot less. They'll spend money on development of security and in effect they'll have less potential sales because their product won't look as good in comparison to everything else.

They'll have to do something the same way they did on DS1052E. There are bean counters on top who like to count every hacked/pirated thing as lost sale. I have no doubt that US company would simply hunt all hacking efforts the same way RIAA is hunting everyone they can.

It is a hard decision for Rigol. On the one hand I don't think it pays off to fight it. On the other hand allowing it to continue looks bad for the management and investors.

But since Rigol isn't greedy US corporation and so far they thrived on cheap and hackable products I think it would be best to allow it some way or the other. After all its better to sell something than nothing. Greed doesn't pay off.

The answer is somewhere in their books. How many DS1102E were sold and how much sales of DS1052E jumped after the hack?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bluesmoke on June 21, 2013, 08:31:31 pm
I just got my DS2072 and now it's fully potted!  :-DD
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Stonent on June 21, 2013, 08:39:38 pm
Said the Tiny85 to the FRAM chip "Hey baby, mind if I get my leg over?" :-DD
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: c4757p on June 21, 2013, 09:54:06 pm
I just got my DS2072 and now it's fully potted!  :-DD

Damn...  :-DD
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 21, 2013, 11:14:59 pm
I don't know why you are being so cagey about this. Aside from anything else the cat is well out of the bag now, with the method to reset the trial options being easily discoverable via Google. In fact you should prefer people using that method because it doesn't give them a free bandwidth upgrade.

Cagey?
1) Less than a week after getting the DS2000, I figured out how to restart the minutes - it's not rocket science.
2) Any owner that has joined us in the forum and posted a couple of times - and then asked any of the older members about restarting the trials (if they couldn't figure it out themselves) has gotten the info.

And why didn't we publicly post the info 7 or 6 or 5 or 4 or... months ago? Because we wanted Rigol to concentrate on fixing the bugs and issues we had with the DSO instead of focusing on plugging exploits - which is what happened (the exploit still works). Now I'd like to see the remaining bugs handled - and a few major mistakes/missing features of the UI taken care of. Last I heard, Rigol was planning to address the External Trigger complaints I raised in the upcoming release - now I'll just have to wait and see if that's a reality or not.

In fact you should prefer people using that method because it doesn't give them a free bandwidth upgrade.

I'm not sure why I would care if people get free bandwidth upgrade or not - I don't care if people get free stuff - I'm all for free stuff.  :)  My only point was about subtlety in passing around the methods to get the free stuff so that we (all owners of DS2000s) don't lose out on possible future FW enhancements as well.  ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 22, 2013, 10:30:57 am
Cagey?
1) Less than a week after getting the DS2000, I figured out how to restart the minutes - it's not rocket science.
2) Any owner that has joined us in the forum and posted a couple of times - and then asked any of the older members about restarting the trials (if they couldn't figure it out themselves) has gotten the info.
You didn't answer my PM. I had to figure it out myself.
You're not an OWNER - you're just somebody who is 'planning' on buying one. And why don't we give out the info to non-owners? Because, instead of being someone invested in the future of the DSO, they may just turn out to be a petulant teenager with the desire to be cool by posting the info publicly somewhere, such as:

http://pastebin.com/qxSBkfTY (http://pastebin.com/qxSBkfTY)

Oh wait, that wasn't you, was it?  :)

Of course, it's nonsense - if 'the poster' even did the slightest bit of research about the DSO, they'd know that license codes are keyed to individual serial numbers. The pastebin post is worthless - although interesting in the sense that it can be traced back to it's origins.

And BTW, how would you have figured it out if you don't own one of the DSOs?

Quote
Personally I think spending any time on security is a waste. They should just accept that once sold people are going to hack their equipment, but any commercial body will still just buy their options and be done with it. Licensing sounds wonderful on paper but never works properly in real life.
It's meaningless what you think about it; it matters what Rigol thinks. And the previous history (the DS1000 hack) implies that they're not going to 'just accept' it  - and a lot less potential profits were at stake then. It costs them nothing extra to attempt to plug exploits - they just divert allocated FW development costs into that particular area - so they reap the benefit of extra sales while attempting to prevent future hacking. It's a no-brainer for bean-counters.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JimmyMz on June 22, 2013, 01:13:32 pm
Yeah, I don't really care for this moral/ethics debate, as it will amount to nothing in the end. I feel that elitism may be at work in this debate. When the information was given away publicly (Studio25 and Orange), others were stripped of their "judgements" of who gets the information and who doesn't (a.k.a. elitism). I asked Marmad too, but I asked under the assumption that it would amount to nothing. In other words, I was too sharp to think Marmad would deem me acceptable to receive any information regarding how to reset trial options. I mean honestly, what do you need, a picture of me holding the receipt? This isn't about teenagers using pastebin for "shits n' giggles." Elitism, it's a simple word, and it's surely at play. I wish it weren't true.  :phew:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jamesb on June 22, 2013, 01:40:54 pm
I just got my DS2072 and now it's fully potted!  :-DD

AH, there we are - this is Rigol's effort to mitigate physical access, providing a physical tampering indicator (aside from the usual void stickers). Inspection of a more recent version of the scope would immediately show signs of tampering if one were to try to access the FRAM.

Is the potting compound clear / translucent?

This effort suggests that time / effort will be wasted on securing future firmware, delaying more important bug fixes.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 22, 2013, 02:50:56 pm
As you point out the pastebin thing is worthless. I was simply referring to the fact that it is well known that once you have such a code you can use it as many times as you like by re-running the self Cal or firmware update. As I said, this information is just a Google search away, that horse bolted long ago.

I don't know where you're getting your information from, but you're completely wrong. You only have to read posts in the other thread to realize that those Trial License Keys are only usable ONCE. They set a flag in permanent memory - so unless you want to lose your calibration data, there is no way to reuse them. OTOH, the Official License Keys can be uninstalled and reinstalled.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 22, 2013, 02:59:12 pm
Yeah, I don't really care for this moral/ethics debate, as it will amount to nothing in the end. I feel that elitism may be at work in this debate. When the information was given away publicly (Studio25 and Orange), others were stripped of their "judgements" of who gets the information and who doesn't (a.k.a. elitism). I asked Marmad too, but I asked under the assumption that it would amount to nothing. In other words, I was too sharp to think Marmad would deem me acceptable to receive any information regarding how to reset trial options. I mean honestly, what do you need, a picture of me holding the receipt? This isn't about teenagers using pastebin for "shits n' giggles." Elitism, it's a simple word, and it's surely at play. I wish it weren't true.  :phew:

This has nothing to do with morals/ethics/elitism - it has to do with trying to keep an exploit from being plugged by Rigol - period.  I (and other members here) have given the information to MANY other owners - no problems whatsoever (and again - it's NOT HARD to figure out the technique yourself). And what has been the result of this:

Rigol released new FW fixing almost all bugs and issues - but NOT plugging the exploit. What would have happened if the info had been publicly posted back in December?

Go read the original Agilent X-Series thread here when it became known early on that Agilent had inadvertently leaked the private key for creating license codes and see what people posted. Did someone start a new thread saying "How to create License Codes for the new Agilent X-Series" and post the key data. No - people stopped talking about it much publicly - and just wrote things like 'PM me for the data', etc. This also wasn't elitism - it was just trying to keep a good thing going.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bxs on June 22, 2013, 04:32:39 pm
Wow, this thread became huge...

I looked at the thread and have to say, this is a huge shoot at your foot  :o like it or not it's the true.

Showing all the info that way is not productive, actually is really quite counter productive.

Lets see, you make all that public, you enjoy it for a short period of time, but them what?

Instead of make your hack have a good living time, showing it all will make Rigol respond and invalidate it, so not quite a smart thing...

Rigol in the past responded so this time they will do the same.

The worse is that all the people that have been enjoying the hack will also suffer, but thats not all; the thing is that all the owners will also suffer, even those that never hacked it  :(

Rigol will respond, and for that they will use the same staff that are developing/supporting the scope, so those resources will be reallocated to prevent the hack instead of for example fixing bugs or adding new stuff to the scope...  ???

note: I'm not saying that I could not make a similar mistake, we all have done, and will do, thats life  ;)

EDIT:
In the end I have to say that if you have some info, information that is yours, it's up to you know what to do with it, that freedom have to exist.

And when I wrote:
Quote
The worse is that (...); the thing is that all the owners will also suffer, even those that never hacked it  :(

I'm not being fair, if this problem will exist, it is Rigol responsibility.

For people that had/have the hack and can also be affected by a response from Rigol; well the word "HACK" says it all...

I still think that it's a bit "naive" release all the info and don't expect response, but only the future will tell, so let's live the present and wait for what the future will bring us  ::)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on June 22, 2013, 07:04:59 pm
We all be burning in hell forever,


Jeesze what a lot of bullshit is on this forum.

Any good hacks available for the code generators ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 22, 2013, 07:11:39 pm
We all be burning in hell forever,


Jeesze what a lot of bullshit is on this forum.

You really don't understand any of it, do you?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 22, 2013, 07:19:04 pm
Jeesze what a lot of bullshit is on this forum.

 :-DD - kids and their supersecrect "hack"

working on reversing the license key schema - 200+ subs done, but still way to go .. i have "crypto" vector initalization & three rounds (so far) of their code transformations implemented in a bunch of c files.
still missing the final verification, then - reversing the process (math brainfuck  |O) - slowly getting there ..

trigger options are possible by changing retvals from their verification subs (e.g. patch code via jtag)
Code: [Select]
set *0x59a24=0xb0f86018 (changes opcodes to R0=3 in 0x59A24)
one could patch the firmware file with this, given somebody bothers to find the CRC checks in the bootldr.
i found a lot of other stuff on the go, but first things first.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mickpah on June 23, 2013, 12:20:27 am
OK, while we on the off-topic of Rigol support. I bought my DS2072 soon after release in 2012. Emailed the local distributor I purchased it from in October 2012 for an update.
Result , I now receive email catalogues and promotions - not firmware. grrrrr

Questions

1 Who's arse do I kiss to get the update ?
2. WTF should I have to kiss arse when if I have an agilent product I just download it ?
3 Is this the "support" we are jeopardising in this thread ?

I am really considering buying a Rigol DP832 and or and arb.
 Rigol are only in there for because the initial purchase bang per buck equation makes sense. If I factor support they lose. Leaving aside the trial renewal thing, the kind of "self help" happening on EEV forums the makes up for Rigols support apathy.
Marbag, you have done such a great job supporting their stuff, beta testing and writing software we can all use, but really there is another ethical issue here too. Rigol are off loading their responsibility and cost on to people like you. I really hope you are getting something out this because they are profiting by your work.

This is only a semi-troll  :)
I am pissed about Rigol support but am not going to pop an aneurysm
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Stonent on June 23, 2013, 12:24:17 am
OK, while we on the off-topic of Rigol support. I bought my DS2072 soon after release in 2012. Emailed the local distributor I purchased it from in October 2012 for an update.
Result , I now receive email catalogues and promotions - not firmware. grrrrr

Questions

1 Who's arse do I kiss to get the update ?
2. WTF should I have to kiss arse when if I have an agilent product I just download it ?
3 Is this the "support" we are jeopardising in this thread ?

I am really considering buying a Rigol DP832 and or and arb.
 Rigol are only in there for because the initial purchase bang per buck equation makes sense. If I factor support they lose. Leaving aside the trial renewal thing, the kind of "self help" happening on EEV forums the makes up for Rigols support apathy.
Marbag, you have done such a great job supporting their stuff, beta testing and writing software we can all use, but really there is another ethical issue here too. Rigol are off loading their responsibility and cost on to people like you. I really hope you are getting something out this because they are profiting by your work.

This is only a semi-troll  :)
I am pissed about Rigol support but am not going to pop an aneurysm

I a link here:
http://www.rigolna.com/products/digital-oscilloscopes/ds2000/ds2072/ (http://www.rigolna.com/products/digital-oscilloscopes/ds2000/ds2072/)
That takes you here to a form:
http://www.rigolna.com/download/501G0000000TyNXIA0/ (http://www.rigolna.com/download/501G0000000TyNXIA0/)

That's just for the standard firmware.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mickpah on June 23, 2013, 12:31:52 am
OK, while we on the off-topic of Rigol support. I bought my DS2072 soon after release in 2012. Emailed the local distributor I purchased it from in October 2012 for an update.
Result , I now receive email catalogues and promotions - not firmware. grrrrr

Questions

1 Who's arse do I kiss to get the update ?
2. WTF should I have to kiss arse when if I have an agilent product I just download it ?
3 Is this the "support" we are jeopardising in this thread ?

I am really considering buying a Rigol DP832 and or and arb.
 Rigol are only in there for because the initial purchase bang per buck equation makes sense. If I factor support they lose. Leaving aside the trial renewal thing, the kind of "self help" happening on EEV forums the makes up for Rigols support apathy.
Marbag, you have done such a great job supporting their stuff, beta testing and writing software we can all use, but really there is another ethical issue here too. Rigol are off loading their responsibility and cost on to people like you. I really hope you are getting something out this because they are profiting by your work.

This is only a semi-troll  :)
I am pissed about Rigol support but am not going to pop an aneurysm

I a link here:
http://www.rigolna.com/products/digital-oscilloscopes/ds2000/ds2072/ (http://www.rigolna.com/products/digital-oscilloscopes/ds2000/ds2072/)
That takes you here to a form:
http://www.rigolna.com/download/501G0000000TyNXIA0/ (http://www.rigolna.com/download/501G0000000TyNXIA0/)

That's just for the standard firmware.

my point exactly, this is the support for the US, can't even register for the site as I am resident in New South Wales / Australia. There is not even an option for "other"
I guess I could put in a dummy address, but really why the hell should I have to go through so much hassle ?

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: UberSteve on June 23, 2013, 02:41:33 am
I just got my DS2072 and now it's fully potted!  :-DD

Must be heavy!  :-DD

You're kidding right...  :phew:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 23, 2013, 03:16:24 am
OK, while we on the off-topic of Rigol support. I bought my DS2072 soon after release in 2012. Emailed the local distributor I purchased it from in October 2012 for an update.
Result , I now receive email catalogues and promotions - not firmware. grrrrr

Well, your dealer should be able to provide you with FW updates - that seems to be Rigol's preferred route of distribution (yeah, I know, a pain in the ass) - and we all just pass it around among ourselves. Anyway, I got my last copy from Dave here (who got it from his dealer) - if you still don't have a copy of FW 01.00.00.03, send me an email and I'll send it to you.

Quote
3 Is this the "support" we are jeopardising in this thread ?

No, Rigol's support generally sucks - no doubt about it - although they begin to make small baby steps: they've actually started listening to our bug reports/FW complaints and responding with fixes. OTOH, they've made huge improvements in the design, build quality, and workmanship of their instruments in the last 2 years - so hopefully some of that movement will be shifted towards support at some point. But I'm just hoping to get them to still implement a few more sorely missing features in future versions of the FW.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bluesmoke on June 23, 2013, 07:15:18 am
Quote
I just got my DS2072 and now it's fully potted!  :-DD

I was joking... I'm still waiting for mine.. shipping date has been moved from the June 21st to the 26th... I don't hold out much hope.
I just want to get my mitts on one!

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jsykes on June 23, 2013, 07:42:56 am
In other words, Blue smoke was just blowing smoke. :)
I would hate to see them start potting. That news is a relief. I remember back in the day, when they did that with the old C band satellite descramblers in the US and the hackers just carefully chipped away the potting.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jedreg on June 26, 2013, 12:59:40 pm
I did it again, I got another Rigol - DS2102 replacing DS1052E. BW of the first one was enhanced first day of arrival, purchase decision on the new one was also influenced by this forum. Guys, your work is impressive! I am not going to apply any hardware hack soon though, 3y warranty is valuable for me, but I cannot wait for software ways of enhancements!

cheers,
andy.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 28, 2013, 08:24:56 am
small goody discovered.
seems to enable a test mode - full features (+100M/200M Bandwith) - but vanishes on power cycling.
I have no information about any effects on already installed keys - so use at your own risk

LLLLLLL-RLGLLDS-DSARLLL-LLLLLLL

enjoy  >:D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mickpah on June 28, 2013, 08:43:39 am
small goody discovered.
seems to enable a test mode - full features (+100M/200M Bandwith) - but vanishes on power cycling.
I have no information about any effects on already installed keys - so use at your own risk

LLLLLLL-RLGLLDS-DSARLLL-LLLLLLL

enjoy  >:D

simply awesome ;D
Pretty good bet it will be gone in the next update, but that may actually mean they release one - of course they will need to make it attractive to upgrade now. win all round I'd say
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 28, 2013, 08:51:28 am
well maybe its some factory-test thingy that they use ... and i only tried it for FW v.00.01.00.05

LLLLLLL-RLGLLDS-DSA9LLL-LLLLLLL

should also work (this enables all 5 possible features (bitmask 0x1F))

if somebody owns a DS4/6 - let me know if it works there too.
and let me know if works on other fw versions as i will stay on 01.00.05 for a while.

-

while it enables 100M/200M official versions, it does *NOT* allow <5ns TB on the 2072 ... so maybe its not implemented fully in 01.00.05.
changing the model type in memory will allow to go down to 500ps however ...
can someone with the right equipment check if 100M/200M BW is actually working ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ve7xen on June 28, 2013, 09:13:04 am
Awesome work. For me:

a) Confirmed -3dB bandwidth is ~230MHz on my DS2072 with code enabled (just a quick check, not an accurate measurement, it is certainly > 200MHz though)
b) Timebase 2ns works for me

I used the R code, and because of the note about it being removed after power off I did some fiddling in the options menu to see if I could get it to save the state (just trying invalid codes, refreshing everything etc.).

While the option disappears from the options page, the 100MHz filter still appears in CH settings and can be switched on/off, 2ns timebase still works, and I confirm at least 200MHz bandwidth after reboot and changing channel settings. 56M memory option and decoders are disabled. I didn't notice if the advanced triggers were there, but they are not now.

I am on 1.00.00.03.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 28, 2013, 09:18:26 am
Awesome work. For me:

a) Confirmed -3dB bandwidth is ~230MHz on my DS2072 with code enabled (just a quick check, not an accurate measurement, it is certainly > 200MHz though)
b) Timebase 2ns works for me

I used the R code, and because of the note about it being removed after power off I did some fiddling in the options menu to see if I could get it to save the state (just trying invalid codes, refreshing everything etc.).

While the option disappears from the options page, the 100MHz filter still appears in CH settings and can be switched on/off, 2ns timebase still works, and I confirm at least 200MHz bandwidth after reboot and changing channel settings. 56M memory option and decoders are disabled. I didn't notice if the advanced triggers were there, but they are not now.

I am on 1.00.00.03.

thx for reporting back  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: BravoV on June 28, 2013, 09:39:46 am
Thanks Cybernet !

This whole thread's posts saved offline, just in case.  >:D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 28, 2013, 10:41:28 am

Tested in FW 05, you get the options but NOT the bandwidth, not  with the 9 nor the R version of the key.
Tested on a DS 2072

with not the BW i assume u mean the BW limit setting ? (20M) ? because ve7xen tested it for >200MHZ at -3db. (see above)
BW limiter is probably a model specifc setting, and it does not change the model type to a DS2202 - which at least in FW 05 doesnt seem possible without a modified FW itself. anyone fancies some CRC cracking ? i can do the nessecary bfin code ;-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 28, 2013, 10:52:09 am
Awesome work. For me:

a) Confirmed -3dB bandwidth is ~230MHz on my DS2072 with code enabled (just a quick check, not an accurate measurement, it is certainly > 200MHz though)
b) Timebase 2ns works for me

I used the R code, and because of the note about it being removed after power off I did some fiddling in the options menu to see if I could get it to save the state (just trying invalid codes, refreshing everything etc.).

While the option disappears from the options page, the 100MHz filter still appears in CH settings and can be switched on/off, 2ns timebase still works, and I confirm at least 200MHz bandwidth after reboot and changing channel settings. 56M memory option and decoders are disabled. I didn't notice if the advanced triggers were there, but they are not now.

I am on 1.00.00.03.

interesting, on FW 05, i only have 20M BW limit, and 5ns TB - seems like FW 03 is actually making use of it ... talk about "mature code" releases ;-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on June 28, 2013, 11:26:41 am
Great work!

I have done the following:
- Update to FW 03
- Enter code LLLLLLL-RLGLLDS-DSA9LLL-LLLLLLL
- Downgrade to FW 05

Now 20Mhz, 100Mhz and OFF is available in the menu. Also, can I use the 2ns time base.
I see no difference to a DS2202.
Even after rebooting.

A big thank you to cybernet
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 28, 2013, 11:31:04 am
Great work!

I have done the following:
- Update to FW 03
- Enter code LLLLLLL-RLGLLDS-DSA9LLL-LLLLLLL
- Downgrade to FW 05

Now 20Mhz, 100Mhz and OFF is available in the menu. Even after rebooting.

A big thank you to cybernet

could u investigate the FRAM side of things a bit ? especially if u see  "9C007" or "9C01F" somewhere - and what happens when u change that to a "1C007" or "1C01F" ... the 1C is the permanent code, the 9C denotes a temp key ;-) i think u get the idea ...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 28, 2013, 11:50:30 am
I have done the following:
- Update to FW 03
- Enter code LLLLLLL-RLGLLDS-DSA9LLL-LLLLLLL
- Downgrade to FW 05

Now 20Mhz, 100Mhz and OFF is available in the menu. Also, can I use the 2ns time base.
I see no difference to a DS2202.
Even after rebooting.

A big thank you to cybernet

Very interesting. One thing to consider - it would be worthwhile to discover a key to change the model numbers BACK to original numbers (2072 or 2102), since this could clearly be used as an indicator for voided warranty.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 28, 2013, 12:02:54 pm
I have done the following:
- Update to FW 03
- Enter code LLLLLLL-RLGLLDS-DSA9LLL-LLLLLLL
- Downgrade to FW 05

Now 20Mhz, 100Mhz and OFF is available in the menu. Also, can I use the 2ns time base.
I see no difference to a DS2202.
Even after rebooting.

A big thank you to cybernet

Very interesting. One thing to consider - it would be worthwhile to discover a key to change the model numbers BACK to original numbers (2072 or 2102), since this could clearly be used as an indicator for voided warranty.

try DSAA as magic bytes as that will have non of the option bits set, which might reverts it ;-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 28, 2013, 12:05:06 pm
I have done the following:
- Update to FW 03
- Enter code LLLLLLL-RLGLLDS-DSA9LLL-LLLLLLL
- Downgrade to FW 05

Now 20Mhz, 100Mhz and OFF is available in the menu. Also, can I use the 2ns time base.
I see no difference to a DS2202.
Even after rebooting.

A big thank you to cybernet

Very interesting. One thing to consider - it would be worthwhile to discover a key to change the model numbers BACK to original numbers (2072 or 2102), since this could clearly be used as an indicator for voided warranty.


YES it can be deleted..., just tried, do:  uninstall

can u try DSAA too ? (its hours until im at my scope again .. and im curious ;-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on June 28, 2013, 12:24:38 pm
- Update to FW 03
- Enter code LLLLLLL-RLGLLDS-DSA9LLL-LLLLLLL
- Downgrade to FW 05

Why do you say downgrade to FW 05 from FW 03 - would that be upgrade?

Is there somewhere that details the FW release versions and also has them available for download?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: orbiter on June 28, 2013, 12:27:56 pm
- Update to FW 03
- Enter code LLLLLLL-RLGLLDS-DSA9LLL-LLLLLLL
- Downgrade to FW 05

Why do you say downgrade to FW 05 from FW 03 - would that be upgrade?

Is there somewhere that details the FW release versions and also has them available for download?


FW 05 came out first, then a subsequent version was released.. FW 03

I have never seen any details on Rigol's site etc to do with FW releases.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 28, 2013, 12:29:09 pm
cybernet good work - what do you mean by crc cracking?


= bootloader checks a CRC (i assume) -> making it possible to load our own software, with a patched firmware i can boost TB to 500ps ;-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on June 28, 2013, 12:32:41 pm
edited
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 28, 2013, 12:33:01 pm
Why do you say downgrade to FW 05 from FW 03 - would that be upgrade?

Is there somewhere that details the FW release versions and also has them available for download?

Alan - the actual FW version numbers are:

FW#00.00.01.00.05
FW#00.01.00.00.03

People here can give you copies of either FW if/when you need them, but I have to say - I suspect delays of Rigol gear to NA (and elsewhere) are likely to get longer ;D

Edit: The currently known bugs (by FW release) are detailed here. (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on June 28, 2013, 12:34:16 pm
FW 05 came out first, then a subsequent version was released.. FW 03

[sarcasm]that makes sense[/sarcasm]

I know Rigol doesn't have a firmware list/repository - I was hoping we did here someplace.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 28, 2013, 12:36:36 pm
= bootloader checks a CRC (i assume) -> making it possible to load our own software, with a patched firmware i can boost TB to 500ps ;-)

Do you know the location of the CRC?  Is it a CRC32?  Is it encrypted or changed in some way?

nope - when u find it, let us know ;-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on June 28, 2013, 12:37:43 pm
Alan - the actual FW version numbers are:
FW#00.00.01.00.05
FW#00.01.00.00.03

So there have only been two releases then?  Can you PM these to me?  I can PM you my email address if that is easier.

People here can give you copies of either FW if/when you need them, but I have to say - I suspect delays of Rigol gear to NA (and elsewhere) are likely to get longer ;D

TEquipment says they should be receiving some in a couple days, we shall see how long it takes to get the one I ordered.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on June 28, 2013, 12:42:21 pm
nope - when u find it, let us know ;-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 28, 2013, 12:44:14 pm
TEquipment says they should be receiving some in a couple days, we shall see how long it takes to get the one I ordered.
Well, I hope it works out - but as reported by van-c here (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg251734/#msg251734), Tequipment told him 10-12 days on June 25th - and he already had one on order for awhile.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 28, 2013, 01:06:09 pm
So there have only been two releases then?  Can you PM these to me?  I can PM you my email address if that is easier.
Early DS2000s came with FW#00.00.01.00.02 - although I've never seen anyone with a copy of that GEL.

FW#00.00.01.00.05 is here. (http://rapidshare.com/files/2813177036/DS2000Update.GEL)

FW#00.01.00.00.03 is here. (http://rapidshare.com/files/3093405188/DS2000-01_00_00_03.7z)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on June 28, 2013, 01:06:57 pm
Hi!
Get one of the latest models have any advantage?

http://www.batronix.com/shop/index.html (http://www.batronix.com/shop/index.html)
Availability: The supply of this article (DS2072) is expected in approx. 11 to 21 days.

Excellent work, congratulations.  ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 28, 2013, 01:09:59 pm
Availability: The supply of this article (DS2072) is expected in approx. 11 to 21 days.

Translation from Sales-Speak to Human: "We don't know when it will be available. Check back in 3 weeks to see if we know then."  ;D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on June 28, 2013, 01:11:47 pm
Availability: The supply of this article (DS2072) is expected in approx. 11 to 21 days.

Translation from Sales-Speak to Human: "We don't know when it will be available. Check back in 3 weeks to see if we know then."  ;D

I understand, thanks.  ;D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 28, 2013, 01:18:43 pm
Firmware links here. (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg253749/#msg253749)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JohannP on June 28, 2013, 01:22:38 pm
Gentlemen & woman

I am drooling to get a fix like this on the DS4000 series scope's. Has somebody test this and what were the results?

Good work done so far on the DS2000 series.

Best regards.

Johann
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on June 28, 2013, 01:33:18 pm
TEquipment says they should be receiving some in a couple days, we shall see how long it takes to get the one I ordered.
Well, I hope it works out - but as reported by van-c here (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg251734/#msg251734), Tequipment told him 10-12 days on June 25th - and he already had one on order for awhile.

Yesterday I was told by tequipment that they have an order coming in within 2-3 days and that 6 were still not sold from that order...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on June 28, 2013, 01:36:23 pm
So there have only been two releases then?  Can you PM these to me?  I can PM you my email address if that is easier.
Early DS2000s came with FW#00.00.01.00.02 - although I've never seen anyone with a copy of that GEL.

FW#00.00.01.00.05 is here. (http://rapidshare.com/files/2813177036/DS2000Update.GEL)

FW#00.01.00.00.03 is here. (http://rapidshare.com/files/3093405188/DS2000-01_00_00_03.7z)

Thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on June 28, 2013, 01:46:49 pm
What is the size of the eeprom that the firmware lives on?

Is the firmware compressed in any way?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 28, 2013, 01:47:48 pm
What is the size of the eeprom that the firmware lives on?

Is the firmware compressed in any way?

not compressed, check the first pages of this thread its all there what u need to get hints to the CRC.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 28, 2013, 01:55:54 pm
LLLLLLL-RLGLLDS-DSA9LLL-LLLLLLL -> option installed (semi permanent)
LLLLLLL-RLGLLDS-VSA9LLL-LLLLLLL -> trial installed - the "V" denotes the trial option

still, BOTH keys are lost on powercycling with FW 05 ... so its definitly either just a test for their license keys or a field test option ;-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on June 28, 2013, 02:03:06 pm
edited
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 28, 2013, 02:04:05 pm
I scanned the first 3 pages - what happens if you try to modify a single byte you deem safe to modify and load the modified firmware?  Does it reject loading it, or reject booting with it?

dont know ;-) try it and report back ;-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on June 28, 2013, 02:08:55 pm
edited
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: egonotto on June 28, 2013, 03:21:21 pm
Hello Wim13,

you wrote: "YES it can be deleted..., just tried, do:  uninstall"

how can I do an uninstall ?

DSAA does not work. DS2072 does not accept it.

Best regards,
egonotto
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 28, 2013, 03:30:36 pm
Yesterday I was told by tequipment that they have an order coming in within 2-3 days and that 6 were still not sold from that older...

Again, I hope for your sake that's true, but just be aware: since this thread started (May 18th) there hasn't been a single new owner of a DS2072 posting from NA in the main Rigol thread. There have been many new owners posting from the EU (and elsewhere), but it appears even that stock has now dried up.

Edit: I'm very curious as to when this changes.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 28, 2013, 03:34:57 pm
Hello Wim13,

you wrote: "YES it can be deleted..., just tried, do:  uninstall"

how can I do an uninstall ?

DSAA does not work. DS2072 does not accept it.

Best regards,
egonotto

Using a SCPI command via Rigol Ultra Sigma:

Connect DSO via USB; boot the DSO; start Ultra Sigma; open SCPI Control Panel; type (or copy and paste) the following:

:SYSTem:OPTion:INSTall XXXXXXXXXXXXXXXXXXXXXXXXXXX  (the code)

then, if you want to get rid of it, immediately enter (without reboot):

:SYSTem:OPTion:UNINSTall

Edit: Corrected - via information from Wim13.  ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: egonotto on June 28, 2013, 03:48:36 pm
Hello marmad,

thanks.

Best regard,

egonotto
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: f_richter on June 28, 2013, 03:54:34 pm
The code DSA9LLL and VSA9LLL does also work on DS4014.
Thank you!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 28, 2013, 03:57:38 pm
The code DSA9LLL and VSA9LLL does also work on DS4014.
Thank you!

Oh boy! The shit has really hit the fan now  ;D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: f_richter on June 28, 2013, 04:08:20 pm
All options enabled, bandwidth options not avail an DS4000. ?!
The keys are lost on powercycling.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 28, 2013, 04:09:50 pm
Someone who owns a DG4000 series should give it a try it as well.

I just looked at the programming manual for the DG4000, and the INSTALL/UNINSTALL SCPI commands are not listed - but they may be undocumented (since it doesn't have purchasable options).

But it can be tested by just using the sequence I posted above for Ultra Sigma (but without the UNINSTALL command). After running the INSTALL command (if you don't get the 'Unsupported command' message), check the model number in System Info.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 28, 2013, 04:18:35 pm
All options enabled, bandwidth options not avail an DS4000. ?!
The keys are lost on powercycling.

Did you check your model number in System Info after applying the code?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 28, 2013, 04:22:01 pm
All options enabled, bandwidth options not avail an DS4000. ?!
The keys are lost on powercycling.

Did you check your model number in System Info after applying the code?

is the DS4/6 bandwith upgradeable at all ? - "DSA9" enables 5 options, on the ds2 thats the default 3 + 2x bandwith (100+200).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Wim13 on June 28, 2013, 04:23:29 pm
Someone who owns a DG4000 series should give it a try it as well.

I just looked at the programming manual for the DG4000, and the INSTALL/UNINSTALL SCPI commands are not listed - but they may be undocumented (since it doesn't have purchasable options).

But it can be tested by just using the sequence I posted above for Ultra Sigma (but without the UNINSTALL command). After running the INSTALL command, reboot the AWG and check the model number in System Info.

No, does not work, gives remote command error, in the key is has DS twice, so i think it is only for DS...
did change it in DG but no luck
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mikeselectricstuff on June 28, 2013, 04:25:01 pm
Someone who owns a DG4000 series should give it a try it as well.

I just looked at the programming manual for the DG4000, and the INSTALL/UNINSTALL SCPI commands are not listed - but they may be undocumented (since it doesn't have purchasable options).

But it can be tested by just using the sequence I posted above for Ultra Sigma (but without the UNINSTALL command). After running the INSTALL command, reboot the AWG and check the model number in System Info.
Can you clarify which string you propose trying via SCPI on the DG?  With the DG, it's presumably a model no., not a license thing
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 28, 2013, 04:26:32 pm
is the DS4/6 bandwith upgradeable at all ? - "DSA9" enables 5 options, on the ds2 thats the default 3 + 2x bandwith (100+200).

I don't think so - and only fully-implemented on the DS2000 in FW.03.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 28, 2013, 04:26:50 pm
DS4K owners could try

LLLLLLL-RLGLLDS-DSB9LLL-LLLLLLL - enable 6 options
LLLLLLL-RLGLLDS-DSD9LLL-LLLLLLL - enable 7 options
LLLLLLL-RLGLLDS-DSH9LLL-LLLLLLL - enable 8 options

(typos fixed, argh ...)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 28, 2013, 04:28:19 pm
Can you clarify which string you propose trying via SCPI on the DG?  With the DG, it's presumably a model no., not a license thing

No need, it's just been checked on the DG - and doesn't work (SCPI command unsupported). But the code changes the model number on the DS2000 (in FW.03).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: f_richter on June 28, 2013, 04:45:35 pm
All options enabled, bandwidth options not avail an DS4000. ?!
The keys are lost on powercycling.

Did you check your model number in System Info after applying the code?
The modelnumber does not change.
DSB9LLL,DSD9LLL,DSH9LLL code works also.

@cybernet
really nice work !
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 28, 2013, 05:05:15 pm
DSA9 - 5 options is the maximum my DS accepts

as DS4 accepts

LLLLLLL-RLGLLDS-DSB9LLL-LLLLLLL - enable 6 options
LLLLLLL-RLGLLDS-DSD9LLL-LLLLLLL - enable 7 options
LLLLLLL-RLGLLDS-DSH9LLL-LLLLLLL - enable 8 options

you could try

LLLLLLL-RLGLLDS-DSR9LLL-LLLLLLL - enable 9 options
LLLLLLL-RLGLLDS-DS99LLL-LLLLLLL - enable 10 options
LLLLLLL-RLGLLDS-DT99LLL-LLLLLLL - enable 11 options
LLLLLLL-RLGLLDS-DV99LLL-LLLLLLL - enable 12 options

as well - this exhausts the available bits, so imho no more than 12 options are possible with their algos  ...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: f_richter on June 28, 2013, 05:44:49 pm

you could try

LLLLLLL-RLGLLDS-DSR9LLL-LLLLLLL - enable 9 options
LLLLLLL-RLGLLDS-DS99LLL-LLLLLLL - enable 10 options
LLLLLLL-RLGLLDS-DT99LLL-LLLLLLL - enable 11 options
LLLLLLL-RLGLLDS-DV99LLL-LLLLLLL - enable 12 options

as well - this exhausts the available bits, so imho no more than 12 options are possible with their algos  ...
lower codes doesnt work unfortunately.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on June 28, 2013, 08:24:18 pm
I have done the following:
- Update to FW 03
- Enter code LLLLLLL-RLGLLDS-DSA9LLL-LLLLLLL
- Downgrade to FW 05
A big thank you to cybernet

So, does this mean that you can permanently change it to a 2202?

And back again to a 2072?

Does this enable all of the trial options too?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bluesmoke on June 28, 2013, 09:10:03 pm
Looks like Christmas came early this year!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on June 28, 2013, 09:25:27 pm
Another future owner of a DS2072, thanks to your work.
And repentant user of a SDS8102V, thanks to OWON work.  :-DD
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Spark on June 28, 2013, 09:38:28 pm
I have done the following:
- Update to FW 03
- Enter code LLLLLLL-RLGLLDS-DSA9LLL-LLLLLLL
- Downgrade to FW 05

Now 20Mhz, 100Mhz and OFF is available in the menu. Also, can I use the 2ns time base.
I see no difference to a DS2202.
Even after rebooting.

A big thank you to cybernet

Very interesting. One thing to consider - it would be worthwhile to discover a key to change the model numbers BACK to original numbers (2072 or 2102), since this could clearly be used as an indicator for voided warranty.

With firmware 03 on a DS2102 I entered your code and then did a self cal. Change to a 2202 seems to stay after a reboot and tested bandwidth is 200Mhz but the options are not retained.
A very big thank you to you all, although new to posting I have been following the DS2000 threads for a while and learnt a lot.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: orbiter on June 28, 2013, 10:03:54 pm
This is correct, however a simple re-entry of the code will re-enable the option goodness again.

AFAIK the FW code is still being prodded by some awesome people here :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mickpah on June 28, 2013, 11:27:27 pm
Please excuse my total ignorance of SCPI, so I may have this wrong.
It looks like a pretty simple task to make a USB dongle to enter the code a boot.

ie wait 15 sec after powerup for boot to complete send SCPI string - gross over simplification but you get the idea.

I have Tweeny 2.0 sitting here just waiting to do something really useful

http://www.pjrc.com/store/teensy.html (http://www.pjrc.com/store/teensy.html)
 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 28, 2013, 11:41:33 pm
Please excuse my total ignorance of SCPI, so I may have this wrong.
It looks like a pretty simple task to make a USB dongle to enter the code a boot.

ie wait 15 sec after powerup for boot to complete send SCPI string - gross over simplification but you get the idea.

I think some people are still hoping for a hack of the official option keys - thus not requiring anything at boot-up. Meanwhile, I hope to release a version of RUU shortly which will send the code automatically on connect (as one temporary measure).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mickpah on June 28, 2013, 11:58:10 pm
Please excuse my total ignorance of SCPI, so I may have this wrong.
It looks like a pretty simple task to make a USB dongle to enter the code a boot.

ie wait 15 sec after powerup for boot to complete send SCPI string - gross over simplification but you get the idea.

I think some people are still hoping for a hack of the official option keys - thus not requiring anything at boot-up. Meanwhile, I hope to release a version of RUU shortly which will send the code automatically on connect (as one temporary measure).
that would be great ! but as a fall back I could live with a dongle. Rainy weekend here, if I can finish running cables in the ceiling ( ready for the NBN Whoo hooo -100/40 Mb on the way) I will have a hack
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Harvs on June 29, 2013, 01:02:18 am
Please excuse my total ignorance of SCPI, so I may have this wrong.
It looks like a pretty simple task to make a USB dongle to enter the code a boot.

ie wait 15 sec after powerup for boot to complete send SCPI string - gross over simplification but you get the idea.

I have Tweeny 2.0 sitting here just waiting to do something really useful

http://www.pjrc.com/store/teensy.html (http://www.pjrc.com/store/teensy.html)

Actually it's not that much of an over-simplification at all.  I've been using a RPi to control my DS2000 to have a set of extra hot buttons.  I wrote all the comms stuff for it using pyUSB and the USBTMC class is actually very simple to implement.  However I've been using a RPi because I wanted a button to that when pushed, it would dump a BMP to a network drive and record audio from a USB mic until the button was released, and store the MP3 with the BMP.  As a single button record capture if you will.

But it would be basic to port what I've done across to something like the Microchip USB framework, then any PIC with a USB OTG port could do this.  I don't have any experience with the Atmel USB framework, so it's unlikely that I'd port it across to that (and I don't have any usb OTG AVRs.)

Tell you what, I'll add it into my RPi code and post this afternoon.  There's probably way too many RPi's sitting around doing nothing at the moment anyway.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mickpah on June 29, 2013, 01:08:11 am


Actually it's not that much of an over-simplification at all.  I've been using a RPi to control my DS2000 to have a set of extra hot buttons.  I wrote all the comms stuff for it using pyUSB and the USBTMC class is actually very simple to implement.  However I've been using a RPi because I wanted a button to that when pushed, it would dump a BMP to a network drive and record audio from a USB mic until the button was released, and store the MP3 with the BMP.  As a single button record capture if you will.

But it would be basic to port what I've done across to something like the Microchip USB framework, then any PIC with a USB OTG port could do this.  I don't have any experience with the Atmel USB framework, so it's unlikely that I'd port it across to that (and I don't have any usb OTG AVRs.)

Tell you what, I'll add it into my RPi code and post this afternoon.  There's probably way too many RPi's sitting around doing nothing at the moment anyway.

Thanks Harv, I'll have a look when you post. The Tweeny is actually nice in that you can use arduino code for quick prototyping or C, plenty of GPIO for a button. I thnk it may well be overkill even for this. Let's hope I don't get stuck in the ceiling and get to it :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Harvs on June 29, 2013, 05:38:48 am
Attached is the python code for applying the code, using pyUSB.

On a RPi, first install pyUSB
Code: [Select]
sudo apt-get install python-pip
sudo pip install pyusb

Then drop the contents of the zip file in a folder somewhere and run from that folder:
Code: [Select]
sudo python applyCode.py

That'll install the licence code.  You can add that launch on occur on boot, then shutdown the pi afterwards
Code: [Select]
sudo shutdown -h -P nowso that you just need to power up the pi as you power up the scope or before (and you don't need a screen or keyboard connected.)

A rather annoying side effect of applying the code is the scope's setup is restored to default.  I'm 90% of the way to adding reading out the setup data, applying the code, then restoring the setup.  But something isn't quite working, and I have to now go drink beer, so maybe tomorrow I'll finish that bit off.

Edit: See later post for updated files
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: eastonwolfs on June 29, 2013, 07:16:43 am
Attached is the python code for applying the code, using pyUSB.

Harvs - just wanted to say thanks for sharing this.  I am a relatively new DS2102 user, and have a Raspberry Pi sitting in a drawer doing nothing, so this looks very interesting/useful to me!  :-+

Hope you enjoyed your beers, cheers.   :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ajr on June 29, 2013, 09:17:44 am
Works for my DS2072 perfectly, firmware 00.01.00.00.03.
As I still had my trial options available, I was a little hesitant to try this, but they are back to previous values after restart so nothing is lost.

VSA9LLL enabled all options as trial (2100+ minutes were added to remaining time for trigger, 56M and decode options) but 2ns timebase wasn't available.

DSA9LLL enabled 2ns timebase and 100M BW limit.

Great work, thanks  :-+

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 29, 2013, 10:51:19 am
Better not automatically i hope, like a button or something...

INI file, my friend.  ;)

Quote
Because next FW release the code will not be available anymore, even worse Rigol
will brick your DSO on next FW release if you use the code, so you have to send it in for repair.
Then Rigol can still make some money out of it.... >:D

BTW, uninstalling DSA9 on a DS2202 leaves it as a DS2202 - meaning that future FW routines COULD differentiate between an "optioned" DS2202 - and an "official" DS2202.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mickpah on June 29, 2013, 11:12:02 am
I was looking for visa drivers and found this, http://www.rigol.com/account/user.php?act=license (http://www.rigol.com/account/user.php?act=license)
obviously not a key generator , but what , curious!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 29, 2013, 11:23:57 am
I was looking for visa drivers and found this, http://www.rigol.com/account/user.php?act=license (http://www.rigol.com/account/user.php?act=license)
obviously not a key generator , but what , curious!

Interesting - but not related to DS2000 since it will only except 4-character x4 groups - instead of the 7-character x4 groups needed for DS2000 codes.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Harvs on June 29, 2013, 12:52:22 pm
Attached is the updated version of the python script for applying the code.

This will read back the scopes setup information before applying the code, then write it back.  This means it will not end up in a completely default state every time you apply the code (at boot is the assumption.)

Also there's a couple of lines of code in there which you can un-comment, and comment the read-back from the scope to read the setup from a file (which you just save to a USB under the storage menu in the scope.)

However, when the scope is rebooted, any setup that applied to the hacked options will naturally be reset to default (since on boot the options aren't there.)  This is where if you're doing a lot of work with the options, you're better off saving the setup to a file, and changing the script to load from the saved file.

If you've got any questions, just ask.

BTW, while I've talked about the RPi, this is operating system agnostic.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bambam on June 29, 2013, 01:34:30 pm
Better not automatically i hope, like a button or something...

INI file, my friend.  ;)

Quote
Because next FW release the code will not be available anymore, even worse Rigol
will brick your DSO on next FW release if you use the code, so you have to send it in for repair.
Then Rigol can still make some money out of it.... >:D

BTW, uninstalling DSA9 on a DS2202 leaves it as a DS2202 - meaning that future FW routines COULD differentiate between an "optioned" DS2202 - and an "official" DS2202.
Does this apply to the DS2072 as well? If you uninstall the DSA9 code will it then still show as a DS2202 model?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 29, 2013, 01:53:19 pm
Does this apply to the DS2072 as well? If you uninstall the DSA9 code will it then still show as a DS2202 model?

No - it goes back to showing 'DS2072' - it's not a permanent change. Good in terms of possible warranty issues - bad in terms of possible responses in later FW.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bambam on June 29, 2013, 02:08:31 pm
Thanks for replying so quick. is there any where to find documentation on using ultra sigma. I had a quick scan on google to no avail.
I tried this in the scpi box of ultra :SYSTem:SETup? and got a garbled response. scpi is all new to me.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 29, 2013, 02:16:01 pm
Thanks for replying so quick. is there any where to find documentation on using ultra sigma. I had a quick scan on google to no avail.
I tried this in the scpi box of ultra :SYSTem:SETup? and got a garbled response. scpi is all new to me.

No documentation really needed for that - it just sends SCPI commands and receives data back. Tons of information online for using SCPI (it's a standard protocol) and download and refer to the DS2000 Programming Guide for information about specific SCPI commands (and responses) to/from the DSO. Such as the following about :SYSTem:SETup? response:

Description:
Send/read the file data of the system setup.

Explanation:
When sending, the format of the data stream:
The Stream Block Header (::= #NXXXXXX) is used to describe the length of the data stream. Wherein, # is the start denoter of the data stream; N is less than or equal to 9; the N figures following N represents the length of the data stream in bytes. For example, #9000002493, wherein, N is 9 and 000002493 represents that the data stream contains 2493 bytes effective data.
When reading, directly put the data stream at the end of the character string to finish the sending with one operation.
<setup_data> is binary data block.
Make sure that the buffer is large enough to receive the data stream, otherwise the program might be abnormal during the reading.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bambam on June 29, 2013, 03:48:07 pm
thank you marmad bed time reading ahead ;D.

although rigol obviously wont be happy about all this, but do you think if they would also consider the possible negative effects of delaying further support of there products like fw etc would put people off of buying there products. there customer support isn't the best at the moment and if possible buyers think there product wont be supported it could put them off. just a thought
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 29, 2013, 04:49:20 pm
although rigol obviously wont be happy about all this, but do you think if they would also consider the possible negative effects of delaying further support of there products like fw etc would put people off of buying there products.

IMO, no it won't put people off buying the DS2000/DS4000 because they can get stuff for free. Rigol already can't keep up with demand for the DSO as evidenced by the delays happening right now (which are from unanticipated over-demand). But I'm afraid, yes, it will delay FW updates, since Rigol will certainly try to counteract some of this. It's just history (DS1000E) repeating itself.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bambam on June 29, 2013, 07:43:15 pm
I have found if you input> LLLLLLL-RLGLLDS-VSA9LLL-LLLLLLL <after the> LLLLLLL-RLGLLDS-DSA9LLL-LLLLLLL <then on reboot it reset my scope back to DS2072 even the model number changed back from DS2202 to DS2072 I also lost 2ns and the 100mhz BW limit. So that should help with warranty issues.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bambam on June 29, 2013, 08:06:52 pm
I am using the 03 FW. I used the DSA9 key but after reboot my 2ns TB, 100mhz BW limit and DS2202 model No were there but no options. so I tried the VSA9 key and went and checked all was ok and found It had reset my scope back to DS2072 so I did a reboot checked everything and all was as standard DS2072. so I just put back the DSA9 key and if need to use the options ill just pop in the key when I boot its not a problem.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Harvs on June 30, 2013, 12:52:08 am
Attached is the python code for applying the code, using pyUSB.

Harvs - just wanted to say thanks for sharing this.  I am a relatively new DS2102 user, and have a Raspberry Pi sitting in a drawer doing nothing, so this looks very interesting/useful to me!  :-+

Hope you enjoyed your beers, cheers.   :)

No problems mate. Hope it's helpful.

If you're interested in using the RPi with your scope, soon I'll be posting the code and setup for using the RPi to provide extra buttons, but I'll do that in it's own thread since it's not DS2000 specific.  Any instrument that uses the USBTMC class and SCPI commands can be controlled with it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Marc M. on June 30, 2013, 01:21:28 pm
Yesterday I was told by tequipment that they have an order coming in within 2-3 days and that 6 were still not sold from that older...

Again, I hope for your sake that's true, but just be aware: since this thread started (May 18th) there hasn't been a single new owner of a DS2072 posting from NA in the main Rigol thread. There have been many new owners posting from the EU (and elsewhere), but it appears even that stock has now dried up.

Edit: I'm very curious as to when this changes.

I was planning on ordering a DS later in the year, but with all the progress that's been made in this thread, I decided I should try to get one before any countermeasures are taken by Rigol.  I placed an order with TEquipment on June 26th.  I e-mailed them on the  27th regarding the status of a refund on shipping and when the scope would ship.  According to their order status page, my scope shipped on June 21st - 5 days before I placed the order :wtf:  In the reply I received from Dawn she stated the scope was due to ship in 48 hours which should be this Monday.  Time will tell but it appears that they have some stock in.  Dawn has been on top of every issue I've had so far so I hoping she's accurate with this date.  I'll follow up if/when I get the shipping notification.

Update: I received a tracking number from TE on 6/30 so a 2072 should be on its way.  Hopefully this means the lack of availability is due to supply/demand and not re-engineering.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 30, 2013, 02:11:57 pm
I was planning on ordering a DS later in the year, but with all the progress that's been made in this thread, I decided I should try to get one before any countermeasures are taken by Rigol.  I placed an order with TEquipment on June 26th.  I e-mailed them on the  27th regarding the status of a refund on shipping and when the scope would ship.  According to their order status page, my scope shipped on June 21st - 5 days before I placed the order :wtf:  In the reply I received from Dawn she stated the scope was due to ship in 48 hours which should be this Monday.  Time will tell but it appears that they have some stock in.  Dawn has been on top of every issue I've had so far so I hoping she's accurate with this date.  I'll follow up if/when I get the shipping notification.
Marc: as posted in the other thread (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg253940/#msg253940), it appears that shipments have started again - a few people have finally received their orders from TEquipment (although it still seems Rigol is having a hard time keeping up with demand).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on June 30, 2013, 02:14:50 pm
According to their order status page, my scope shipped on June 21st - 5 days before I placed the order :wtf:  In the reply I received from Dawn she stated the scope was due to ship in 48 hours which should be this Monday. 

My order showed it was supposed to ship on 6/21 as well even though it was placed after that date.

I *did* receive a tracking # from them this morning!!!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 30, 2013, 02:44:09 pm
back to topic, anyone with a DS4k firmware file around that is willing to share it with me ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: benemorius on June 30, 2013, 04:38:30 pm
IMO, no it won't put people off buying the DS2000/DS4000 because they can get stuff for free. Rigol already can't keep up with demand for the DSO as evidenced by the delays happening right now (which are from unanticipated over-demand). But I'm afraid, yes, it will delay FW updates, since Rigol will certainly try to counteract some of this. It's just history (DS1000E) repeating itself.

The folks at Rigol have demonstrated that they aren't as daft as some. They will learn the error of their ways; they just need our help.

If you're buying or have bought their stuff because of the value added by hacked features, TELL THEM that's why they're getting your business. If we talk loud enough, the right person at Rigol will eventually cross reference and crunch some numbers, and they'll confirm what we're already suspecting - a small change in strategy could pay off big for them if they would only leave the hacks alone.

Rigol, you're making a lot of extra sales from these hacks. Stop fighting it and learn how to take better advantage of it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Maalobs on June 30, 2013, 06:36:07 pm
Early DS2000s came with FW#00.00.01.00.02 - although I've never seen anyone with a copy of that GEL.

FW#00.00.01.00.05 is here. (http://rapidshare.com/files/2813177036/DS2000Update.GEL)

FW#00.01.00.00.03 is here. (http://rapidshare.com/files/3093405188/DS2000-01_00_00_03.7z)

I'm a little late to this so maybe I'm asking a redundant question, but are those firmware-images common for the entire DS2000-series?
The reason I ask is that I have a DS2102, and the firmware-images above have the strings "DS2072" and "DS2202" in them, but not "DS2102". :)

The System Info menu on my unit shows:
Model: DS2102
Software version: 00.00.01.00.02
Hardware version: 1.1.0
FPGA version:
SPU 03.01.02
WPU 00.06.00
CCU 12.29.00
MCU 00.05

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Wim13 on June 30, 2013, 06:38:01 pm

From the Rigol website , the latest FW versions

Here are the latest Firmware versions by Rigol product family as of July 1, 2013:


DS2000 FW-Version: 00.01.01.00.02
DS4000 FW-Version: 00.01.00.00.07
DS6000 FW-Version: 00.01.04
DSA815 FW-Version: 00.01.07
DSA1000 FW-Version: 00.01.16
DG4000 FW-Version: 00.01.06
DG5000 FW-Version: 01.01.08
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Kobus on July 01, 2013, 05:52:37 pm
The folks at Rigol have demonstrated that they aren't as daft as some. They will learn the error of their ways; they just need our help.

If you're buying or have bought their stuff because of the value added by hacked features, TELL THEM that's why they're getting your business. If we talk loud enough, the right person at Rigol will eventually cross reference and crunch some numbers, and they'll confirm what we're already suspecting - a small change in strategy could pay off big for them if they would only leave the hacks alone.

Rigol, you're making a lot of extra sales from these hacks. Stop fighting it and learn how to take better advantage of it.

I second that. I bought a Rigol because they can and have been hacked.

A quick case study for Rigol - No need to repeat the same mistake.

Linksys made a legendary router called wrt54g. It's rise to fame was quite simple, it got hacked. You could now buy a cheap consumer router and add pro level features.
Thus began the era of 3rd  party router FW. The wrt54g was everywhere. Entire websites and forums were dedicated to these routers.

Linksys, in their infinite wisdom, changed the chipset and OS of the wrt54g. They successfully locked out the hackers from their new HW revision. In addition , they also
slashed their sales. Duh!  I doubt they sold a single extra high end router due to their new hacker proof model.
Hackers want to hack, they want control over their machine, they won't pay $$$ to get an extra feature their hacked version could provide.

What happened, hackers took their business elsewhere. Linksys finally caught on and reissued the old hackable Linux version as the wrt54gl. Since then, they have
always had a linux router on offer for hacking. None of their other routers since then have taken off like the original wrt54g.

Note to forum readers, please don't de-rail this thread. All comments about router hacking should be taken to the appropriate forums or PM. 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 01, 2013, 06:05:09 pm
thx for the history lesson, does this look like linksys router history thread ? ;-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jonese on July 01, 2013, 08:57:09 pm
That's not a correct comparison.  Linksys doesn't sell higher end routers, there was no lost sales.  The chipset, OS, and flash was changed for cost reduction.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: KuchateK on July 02, 2013, 12:34:21 am
That's not a correct comparison.  Linksys doesn't sell higher end routers, there was no lost sales.  The chipset, OS, and flash was changed for cost reduction.

From Wiki:
Quote
Linksys released the WRT54GL in 2005 to support third-party firmware based on Linux, after the original WRT54G line was switched from Linux to VxWorks, starting with version 5. The WRT54GL is technically a reissue of the version 4 WRT54G.
Demand had to be very high to justify such move.

Edit: They were acquired by Cisco in 2003, so I'm sure they lost some sales on the high end.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: BlueLaser on July 02, 2013, 01:32:35 am
So regarding these DSA9 codes, has anyone verified whether the 2nd self-cal event causes the options to be reset or any original options timer values to be zeroed?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Harvs on July 02, 2013, 01:41:45 am
So regarding these DSA9 codes, has anyone verified whether the 2nd self-cal event causes the options to be reset or any original options timer values to be zeroed?

I don't really get what you mean about the second self-cal.  However, yes, when you stick the DSA9 code in, all the trial options are zeroed, since while it's running it believes you have the official version of all the options.  When you reboot, you now have no options at all.  That's why I posted the RPi code to upload the key on boot.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: BlueLaser on July 02, 2013, 01:54:37 am
I was referring to the known issue of FW v.01.00.00.03 (item 6 of the other major ds2072 thread) where the 2nd self-cal expires the trial options.  I did see that the timers temporarily disappear after entering the code showing "official version" but after power cycle, the original time remaining does return to the trial options installed.  (As others have noted, the 2ns time base indeed does remain!  8) )
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zibadun on July 02, 2013, 02:56:58 am
In case somebody uses IP to talk to the scope

found a small VXI-11 module here https://github.com/alexforencich/python-vxi11

After installing the module, a short python script:

import vxi11
rigol = vxi11.Instrument("192.168.x.x")
print(rigol.write(":SYSTem:OPTion:INSTall LLLLLLL<your favorite code>LLLLLLLLLL"))

does the magic.  :)


BTW, on 03 firmware with the "original" trial options looks like the clock is ticking while using the DSA9 code. After the reboot the options remaining time is down, so I expect to lose them forever eventually.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Harvs on July 02, 2013, 04:16:24 am
Nice module I'll keep that in mind for future.

Just keep in mind like I said in an earlier post that installing the option resets the scope to the default state. Personally this would annoy me no end, so I read out the scope's setup first, install the code, then send it back to it.
Title: Sniffing the Rigol's internal I2C bus
Post by: zibadun on July 02, 2013, 05:09:15 am
Nice module I'll keep that in mind for future.

Just keep in mind like I said in an earlier post that installing the option resets the scope to the default state. Personally this would annoy me no end, so I read out the scope's setup first, install the code, then send it back to it.

I saw your script Harvs which is what made me look for the tcp/ip version. Nice work.

I've  never even heard of  vxi-11 protocol until I looked at the ultra sigma scpi packets in wireshark.  What an obscure thing
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Harvs on July 02, 2013, 05:16:36 am
It may look obscure at first, but it's just a specific implementation of Remote Procedural Calls.

I've been looking for a Java implementation, but haven't really found anything great.  So I'm currently building the bare bones of the VXI11 in Java, because I'm building an Android tablet app for the scope.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: darrylp on July 02, 2013, 02:03:29 pm
Okay just received a DS2072 not turned on yet, but rigols packing slip has June 4th 2013.
So in the UK they are fresh stock. Fingers crossed all features still available :-)

--
 Darryl

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on July 02, 2013, 02:10:16 pm
Okay just received a DS2072 not turned on yet, but rigols packing slip has June 4th 2013.
So in the UK they are fresh stock. Fingers crossed all features still available :-)

It will take awhile before any counter-measures Rigol may / may not do to prevent hacking would filter their way down to actual stock (or FW). I don't think it's anything any owner (or prospective owner) would have to even consider for a few months. This latest FW (release date: 28 June) would have been highly unlikely to change anything - since actions would have to be proposed, agreed upon, and then formally stated and passed on to coders.
Title: Re: Re: Sniffing the Rigol's internal I2C bus
Post by: darrylp on July 02, 2013, 06:00:41 pm
Okay just received a DS2072 not turned on yet, but rigols packing slip has June 4th 2013.
So in the UK they are fresh stock. Fingers crossed all features still available :-)

--
 Darryl

Its come with few.03

--
 Darryl

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: gierig on July 02, 2013, 06:17:54 pm
OK here my experience with the DSA9 on my ds2102.

applied with 03 firmware.  update to latest 01.01.00.02 firmware today.
I got still all the settings and functions that a 2202 should have (BW Filter, 2ns/div,)

have somebody already tested the hardware with the new Bandwith Settings ?
I there a Real Increase ? on the Analog AMP ?
Where is the real -3db point with this settings on ? My generators are only up to 20Mhz)









 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: gierig on July 02, 2013, 06:49:13 pm
That looks more like a Compare between  un"modeled" Units. Or how i have to interpret it ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ve7xen on July 02, 2013, 07:01:01 pm
have somebody already tested the hardware with the new Bandwith Settings ?
I there a Real Increase ? on the Analog AMP ?
Where is the real -3db point with this settings on ? My generators are only up to 20Mhz)
Yes, I verified it on an 'optioned' DS2072 in this post (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg253641/#msg253641) as being ~230MHz, which matches Wim13's chart nicely.

The frontend on these scopes is all the same. They are using the programmable filters in the LMH6518 PGA to achieve the bandwidth limiting. Given that I'm surprised to see a difference between DS2102 and DS2072 in Wim's charts, since the PGA doesn't offer a 70MHz filter.

Anyway the code works.
Title: Re: Re: Sniffing the Rigol's internal I2C bus
Post by: darrylp on July 02, 2013, 07:12:05 pm
Given that I'm surprised to see a difference between DS2102 and DS2072 in Wim's charts, since the PGA doesn't offer a 70MHz filter.

I've asked this before with no response, but could it be that these are the bandwidth settings in the LMH6518 for each model?

DS2072 --> 100
DS2102 --> 200
DS2202 --> 350

i'd say very much so.   remember thats the gain limit not  a filter cutoff freq.

the stock 100mhz ds2102 looks to get the most benefit from the three selectable gains above.  the 200mhz option starts hitting other limits in the front end.

--
 Darryl

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Nomen luni on July 02, 2013, 07:42:44 pm
Quote
Quote from: gierig on Today at 04:49:13 AM

    That looks more like a Compare between  un"modeled" Units. Or how i have to interpret it ?

Well if you look at the line for the 2202, you can see the -3 dB point is at 225 Mhz
for the 2072 the -3 dB is at about 115 Mhz..etc...
To ask the question again.. is this a measurement of the hacked or stock DS2072 bandwidth, Wim13? Ve7xen seems to be confirming that the hack 2072 offers a true 200MHz bandwidth.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: gierig on July 02, 2013, 07:58:11 pm
Thanks, so make it sense in my eyes.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: CodyShaw on July 02, 2013, 08:16:29 pm
Can we please get a summary of what each hack in this thread does so far.

There is the FRAM hack - what CAN it enable?

There is the special key hack - what CAN it enable?  Is it permanent in some firmware revisions?

I agree, this would be great.

I ordered a 2072 a few weeks ago from TEquipment, and I have been looking forward to getting my hands dirty hacking it to bits. I saw some hardware hacks coming along when i checked a few weeks ago, this is just fantastic what seems to have popped up in no time.

Very excited! Maybe I can help once I get my scope!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: synapsis on July 02, 2013, 08:25:14 pm
I'm sure someone at Rigol is following this thread: This thread made me purchase a DS2072 this morning. Being hackable is a major selling point when I'm looking for something. (I've been known to use Linksys WRT54GL routers as microcontrollers, etc...)

I ordered from TEquipment, but unfortunately it looks like I'll be waiting awhile. :( I was considering an Agilent 2000 and then saving up for the SPI/I2C ability I need later (for $500?!), but it looks like my first real DSO will be a Rigol.

I learn so much from this site, and appreciate everyone willing to share the information.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: CodyShaw on July 02, 2013, 08:30:05 pm
I just read a few pages back about a few people ordering their scopes on June 26th-28th from TEquipment and already receiving a shipping number...

Not fair! I ordered mine on June 12, here's my status:

To Be Shipped
Estimated Ship Date: 07/02/2013
Note: In Warehouse, Pulled for Shipping

Lousy. This was a birthday gift for myself (June 2nd). Lucky bastards got theirs shipped first!

I also checked my shipping status a hour and a half ago... It said my estimated ship date was a week ago, yet it hadn't shipped. Sent them a message asking what was going on, and now it's been updated to a ship date of today..
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ve7xen on July 03, 2013, 07:08:12 am
Ve7xen seems to be confirming that the hack 2072 offers a true 200MHz bandwidth.
I did some slightly more rigorous measurement tonight. I unfortunately don't have a decent 50R thru to use with this scope, so I am using a cheap T and cheap 50R termination - they are dodgy and probably responsible for some of the rolloff. The signal is 100mV RMS per the generator.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Bitstream on July 03, 2013, 07:13:19 pm
I spent about an hour last night reading through the DS2000 hacks -very interesting and superb work by several people. 

I was going to update the software on my scope and try the license key hacks.  My current firmware is 00.00.01.00.02.  However, when I read the other version information, I noticed that my hardware is newer than what's been reported by others:

Model DS2072
Software =00.00.01.00.02
Hdw =1.1.0.0     <======================
FPGA version:
   SPU 03.01.02
   WPU 00.06.00
   CCU 12.29.00
   MCU 00.05

Others have reported V1.0.1.0 hardware.  Has anybody tried the firmware updates on the version 1.1.0.0 hardware?  Should I be worred it could brick my scope?  I did try all the license key hacks with th 00.00.01.00.02 software but none of them worked.  I'm hoping it's just due to the downlevel software but I'm a bit apprehensive of bricking the scope if the 00.00.01.00.05 and 00.01.00.00.03 firmware levels aren't compatible with the 1.1.0.0 hardware.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 03, 2013, 08:14:23 pm
sry, but its not that simple ;-)
try something like this but reversed.

Code: [Select]

unsigned char codemap_ee00d0[]={ 0x0, 0x0, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f,
                                 0x0, 0x0, 0x0,  0x0,  0x0,  0x0,  0x0,  0x0,  0x1,  0x2,
                                 0x3, 0x4, 0x5,  0x6,  0x7,  0x0,  0x8,  0x9,  0xa,  0xb,
                                 0xc, 0x0, 0xd,  0xe,  0xf,  0x10, 0x11, 0x12, 0x13, 0x14,
                                 0x15,0x16, 0x17 };

unsigned char codemap_20688e[]={ 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30,  /* 0-9 = 0x30 */
                                 0x37, 0x37, 0x37, 0x37, 0x37, 0x37 };                                                             /* A-F = 0x37 */

/*
** Encryption Routine 1
*/
unsigned char *lic_code_map(unsigned char *lic_skipped)
{
 unsigned char lv1,lv2;
 unsigned char b1_mapped, b1_shifted, b1_remapped;
 unsigned char b2_mapped, b2_shifted, b2_remapped;
 unsigned char b3_mapped, b3_shifted, b3_remapped;
 unsigned char b4_mapped, b4_shifted, b4_remapped;
 unsigned char b5_shifted, b5_remapped;
 unsigned char *lic_mapbytes;

 lic_mapbytes=calloc(28, 1);
 if (!lic_mapbytes) return(0);

 lv1=lv2=0;
 while(lv1 < strlen((unsigned char*)lic_skipped))
 {
    b1_mapped =  codemap_ee00d0[ *(lic_skipped+lv1) - 0x30 ];
    b1_shifted = (b1_mapped / 2) & 0xf;
    b1_remapped = b1_shifted + codemap_20688e[b1_shifted];
    lic_mapbytes[lv2++]=b1_remapped;
    b1_mapped = b1_mapped & 0x1;

    b2_mapped =  codemap_ee00d0[ *(lic_skipped+lv1+1) - 0x30 ];
    b2_shifted =  ((b1_mapped << 0x3) | (b2_mapped / 4)) & 0xF;
    b2_remapped = b2_shifted + codemap_20688e[b2_shifted];
    lic_mapbytes[lv2++]=b2_remapped;

    b3_mapped = codemap_ee00d0[ *(lic_skipped+lv1+2) - 0x30 ];
    b3_shifted = ((b3_mapped / 8) | ( (b2_mapped & 0x3) << 2 )) & 0xF;
    b3_remapped = b3_shifted + codemap_20688e[b3_shifted];
    lic_mapbytes[lv2++]=b3_remapped;

    b4_mapped = codemap_ee00d0[ *(lic_skipped+lv1+3) - 0x30 ];
    b4_shifted = ((b4_mapped / 16 ) |((b3_mapped & 0x7) << 0x1)) & 0xf;
    b4_remapped = b4_shifted + codemap_20688e[b4_shifted];
    lic_mapbytes[lv2++]=b4_remapped;

    b5_shifted = b4_mapped & 0xF;
    b5_remapped = b5_shifted + codemap_20688e[b5_shifted];
    lic_mapbytes[lv2++]=b5_remapped;

    lv1 = lv1 + 4;
  }
  return(lic_mapbytes);
}

anyway, all possible option codes have been tried by now, there no more hidden stuff thats reachable via this method.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 03, 2013, 08:33:53 pm
well if u say so ;-)

PDUY9N9-QTS9PQS-WPLAETR-D3UJHYA is a DSAH code,  permanently enabling first 3 options. - if it matches the right serial ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 03, 2013, 08:58:51 pm
Do you have the codemap_20688e - it isn't in your example above - I thought I'd try your function!

updated
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zibadun on July 03, 2013, 11:04:01 pm
Do you have the codemap_20688e - it isn't in your example above - I thought I'd try your function!

updated

it compiled but what string should i pass to it (lic_skipped)?  i tried s/n 20 bytes, getting back 35.  don't think I'm doing it right. 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 03, 2013, 11:10:33 pm
Do you have the codemap_20688e - it isn't in your example above - I thought I'd try your function!

updated

it compiled but what string should i pass to it (lic_skipped)?  i tried s/n 20 bytes, getting back 35.  don't think I'm doing it right.

that would be a bit too easy ;-) this is not a keygen, its a chunk that explains the 4 magic bytes e.g. VSAH, DSAH ... they serial/key algo is magnitudes more complicated/obsfuscated ...
and i leave it as a challenge, so everybody can have a bit fun tinkering with it for now ;-)
Title: Sniffing the Rigol's internal I2C bus
Post by: zibadun on July 04, 2013, 03:32:29 am
that would be a bit too easy ;-) this is not a keygen, its a chunk that explains the 4 magic bytes e.g. VSAH, DSAH ... they serial/key algo is magnitudes more complicated/obsfuscated ...
and i leave it as a challenge, so everybody can have a bit fun tinkering with it for now ;-)

It converts 4 digits of base 32 (5 bits) to 5 digits of base 16 (4 bits)...

dsa9 = 1c01f
dsar = 1c00f
dsaa = 1c000

right?

I don't think so. Look at the calloc call, making a 28 1 byte element array. Must be something to do with the 28 character code. But may be I'm wrong
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: EV on July 04, 2013, 07:11:31 am
Hey Guys ,
I have located this new Firmware has anyone tried it.?

Did you update? :-//
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 04, 2013, 07:26:46 am
that would be a bit too easy ;-) this is not a keygen, its a chunk that explains the 4 magic bytes e.g. VSAH, DSAH ... they serial/key algo is magnitudes more complicated/obsfuscated ...
and i leave it as a challenge, so everybody can have a bit fun tinkering with it for now ;-)

It converts 4 digits of base 32 (5 bits) to 5 digits of base 16 (4 bits)...

dsa9 = 1c01f
dsar = 1c00f
dsaa = 1c000

right?

right - 0x1c = permanent option, 0x9c = temporary option - last 3 nibbles are the bitflags for the options.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ve7xen on July 04, 2013, 07:58:47 am
In case somebody uses IP to talk to the scope

found a small VXI-11 module here https://github.com/alexforencich/python-vxi11

After installing the module, a short python script:

import vxi11
rigol = vxi11.Instrument("192.168.x.x")
print(rigol.write(":SYSTem:OPTion:INSTall LLLLLLL<your favorite code>LLLLLLLLLL"))

Thanks for the heads up on the module. I've combined it with one of my favourite simple tools apinger (https://github.com/Jajcus/apinger) which can execute commands when hosts go up or down (in addition to tracking/acting on latency/loss). In this case I'm triggering my python script within a few seconds of the scope booting up, which then stores the config a la the other script posted above (much simpler with VXI), loads the license key, and restores the config. I just run this on a server that's on anyway and the options will be installed within a few seconds of the scope booting up.

Code: (apinger.conf) [Select]
user "nobody"
group "nogroup"

alarm default {
# When the 'DOWN' alarm state is changed to UP, run this command
command off "/usr/local/bin/ds2000.py %t"
}
alarm down "down" {
time 10s
}
target default {
interval 5s
alarms "down"
}
target "192.168.65.169" {
description "Rigol DS2000";
alarms override "down";
}

Code: (ds2000.py) [Select]
#!/usr/bin/env python

LICENSE = "LLLLLLLRLGLLDSDSA9LLLLLLLLLL"

import vxi11, sys, time

retries = 0
while retries < 30:
try:
rigol = vxi11.Instrument(sys.argv[1])
config = rigol.ask_raw(":SYSTem:SETup?")
rigol.write(":SYSTem:OPTion:INSTall " + LICENSE)
rigol.write_raw(":SYST:SET " + config)
sys.exit(0)
except(SystemExit):
raise
except:
retries = retries + 1
time.sleep(1)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: fqahmad66 on July 04, 2013, 10:17:17 am
Does the hacks works for DSA815 SAs? >:D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: docmandu on July 04, 2013, 12:04:47 pm
sry, but its not that simple ;-)
try something like this but reversed.

Haven't read everything here yet.. but saw this snippet of code.. not sure if you're wondering how to do the reverse, but it's actually very simple. What the code does is basically turn every input character in a 5 bit value.. the entire output is then chopped up in 4 bit nibbles and converted to a hex character for display.

So.. doing the reverse is just writing the entire output value as a binary string, then converting every 5 bits back to a character using codemap_ee00d0.

Code: [Select]
//                               0    1    2     3     4     5     6     7     8     9                               
unsigned char encode_tbl[] =   { 0x0, 0x0, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f,
                             //                                          A     B     C   
                                 0x0, 0x0, 0x0,  0x0,  0x0,  0x0,  0x0,  0x0,  0x1,  0x2,
                             //  D    E    F     G     H     I     J     K     L     M
                                 0x3, 0x4, 0x5,  0x6,  0x7,  0x0,  0x8,  0x9,  0xa,  0xb,
                             //  N    O    P     Q     R     S     T     U     V     W
                                 0xc, 0x0, 0xd,  0xe,  0xf,  0x10, 0x11, 0x12, 0x13, 0x14,
                             //  X     Y     Z
                                 0x15, 0x16, 0x17 };

Ie. PDUY9N9QTS9PQSWPLAETRD3UJHYA code gives 68E56FB3EE8C3ED7428D5009178F3241EC0.
So for example for the first letter doing the reverse, take 68, which is binary 0110 1000, the first 5 bits 01101 = 0xD .. and 0xD in that table is P. Repeat for all the rest.


But like I said.. not sure if this was what you were looking for.


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zibadun on July 04, 2013, 12:16:11 pm
In case somebody uses IP to talk to the scope

found a small VXI-11 module here https://github.com/alexforencich/python-vxi11

After installing the module, a short python script:

import vxi11
rigol = vxi11.Instrument("192.168.x.x")
print(rigol.write(":SYSTem:OPTion:INSTall LLLLLLL<your favorite code>LLLLLLLLLL"))

Thanks for the heads up on the module. I've combined it with one of my favourite simple tools apinger (https://github.com/Jajcus/apinger) which can execute commands when hosts go up or down (in addition to tracking/acting on latency/loss). In this case I'm triggering my python script within a few seconds of the scope booting up, which then stores the config a la the other script posted above (much simpler with VXI), loads the license key, and restores the config. I just run this on a server that's on anyway and the options will be installed within a few seconds of the scope booting up.

Code: (apinger.conf) [Select]
user "nobody"
group "nogroup"

alarm default {
# When the 'DOWN' alarm state is changed to UP, run this command
command off "/usr/local/bin/ds2000.py %t"
}
alarm down "down" {
time 10s
}
target default {
interval 5s
alarms "down"
}
target "192.168.65.169" {
description "Rigol DS2000";
alarms override "down";
}

Code: (ds2000.py) [Select]
#!/usr/bin/env python

LICENSE = "LLLLLLLRLGLLDSDSA9LLLLLLLLLL"

import vxi11, sys, time

retries = 0
while retries < 30:
try:
rigol = vxi11.Instrument(sys.argv[1])
config = rigol.ask_raw(":SYSTem:SETup?")
rigol.write(":SYSTem:OPTion:INSTall " + LICENSE)
rigol.write_raw(":SYST:SET " + config)
sys.exit(0)
except(SystemExit):
raise
except:
retries = retries + 1
time.sleep(1)

Thanks for the code Keenan!  Very cool.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: darrylp on July 04, 2013, 07:09:14 pm
I might have missed it, but the DSA9 code, the one that says official options. Will that work on a scope that has its trial minutes expired ?
For that power cycle of the scope of course I understand.
--
 Darryl

Title: Re: Re: Sniffing the Rigol's internal I2C bus
Post by: darrylp on July 04, 2013, 07:18:34 pm
I might have missed it, but the DSA9 code, the one that says official options. Will that work on a scope that has its trial minutes expired ?
For that power cycle of the scope of course I understand.
--
 Darryl

i could not test that with real trail options, but when trail options where loaded (VSA), the DSA key overwrites
in my test.

I was meaning the trial time expired minute wise. ie I'm down to less than 1800 mins and I've only used the scope for one evening.... Plus a few quick 10 minute play a rounds.


--
 Darryl

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: darrylp on July 04, 2013, 07:51:43 pm
Ahh  very happy to hear that.

--
 Darryl

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: doma on July 04, 2013, 08:29:09 pm
HI All,

I have a DS2072 - I was lucky to have it purchased 4 months ago so before today's "high demand".

Anyway, I had the 0.0.1.0.5 FW installed when it arrived in the box. Today I updated it to the latest FW: 0.1.1.0.2.

Then I applied the

LLLLLLL-RLGLLDS-DSARLLL-LLLLLLL
and
LLLLLLL-RLGLLDS-DSA9LLL-LLLLLLL
codes.

Results:
- It stays on 200 Mhz, with BW limits 20M/100M, and 2ns/div, says it's a DS2202 even after power cycling
- The options are activated only for the current power session, they are gone after reboot.

Thanks for the great work on this, highly appreciated!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: playfsx on July 04, 2013, 10:36:22 pm
Today batronix (the store from i buy the ds2072) sent a e-mail with a firmware update, now im not ask for firmware update and i thing that this is not coincident, isn't it ?
With a hex editor i found that is the version 00.01.01.00.02... did anyone else get similar e-mail ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: gierig on July 04, 2013, 10:47:39 pm
Quote
i found that is the version 00.01.01.00.02... did anyone else get similar e-mail ?

it's allreday link to the bottom of this here:
https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684
 (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684)

And Yes fix some Bugs, and the DSA9xxx Codes are still Valid.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mickpah on July 04, 2013, 10:48:30 pm
So much in this thread now so I hope I not repeating a question.
can some one put  FW: 0.1.1.0.2. up for download please ?

thanks

PS, Rigol DP832 Power supply delivery last week, too busy to tear it apart aside from the excentric keypad and I have to extend my shelve a bit to hold it I'm really happy.
Bonus , it has lots of firmware options to hack  :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mickpah on July 04, 2013, 10:50:31 pm
So much in this thread now so I hope I not repeating a question.
can some one put  FW: 0.1.1.0.2. up for download please ?


don't worry,  as I clicked post gierig answered my question
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: orbiter on July 04, 2013, 10:53:50 pm
Today batronix (the store from i buy the ds2072) sent a e-mail with a firmware update, now im not ask for firmware update and i thing that this is not coincident, isn't it ?
With a hex editor i found that is the version 00.01.01.00.02... did anyone else get similar e-mail ?

Yes I got a FW update email too from Batronix. Which Included a link to the Rigol website so I could request the new FW files 00.01.01.00.02.

However I didn't need the file as I know some friends at a great forum called the EEVBlog :D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: doma on July 05, 2013, 08:21:41 am

tested some codes:

DSA9 is all options VSA9 is same but then with trail options
DSA9 overwrites VSA9, VSA can not overwrite DSA
xSA5 is same as xSA9

xSA2 is only 110 and 200 Mhz options on
xSA3 is Trigger and bandwidth options on
xSA6 is mem56 and bandwidth options on
xSA7 is trigger and mem56 and bandwidth on
xSA8 is decoder and mem56 and bandwidth on

xSAB is only Trigger options on
xSAC is only decode options on
xSAE is only mem56 on

Good job Wim13 - so we know that:

0000x   trigger
000x0   decode
00x00   memory
xx000   200Mhz

Do you have a facility for bandwidth testing?  I wonder what the xx in xx000 correlate to:

00000 - ? could 00 mean the factory setting, a DS2072 would be a DS2072, a DS2102 would be a DS2102, etc.
10000 - Forced DS2072 ???  Can someone verify this one - what does "DSAS" show for a model number?
01000 - Forced DS2102
11000 - Forced DS2202

Thanks,

Alan

How do these make the options across reboots permanent? The DSA9 for me with DS2072- FW  0.1.1.0.2. made 200MHz permanent while leaving the options volatile.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: doma on July 05, 2013, 09:10:26 am

In order to get a Permanent Option Key for your DSO it would have to be generated using your specific DS2000 serial number.
Did you send your Serial number to Someone?? 
Probably not, then do NOT expect to have a Option  Key Code for permanent Options!!

Thanks. I did not expect it to be permanent. However the 200MHz stayed permanent. So do you reckon this is a mere firmware bug - maybe even specific to FW version - , which we should also just enjoy?

Are the "options" keys different than the "type" keys. By looking at the Rigol_DS2000_patch_attiny85.ino (found here (http://gotroot.ca/rigol/) using google - all credit goes to author) they all are just values in FRAM. So do you suggest that the two codes work differently. More specifically they make the FW in case of the 200MHz to _write_ to FRAM (starting at locations 0x4A, 0x56, 0x5A and 0x62), while in case of the options it stays in volatile RAM?

Doma
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Xyphro on July 05, 2013, 10:08:43 am
Windows user can use this Tool here to activate licenses:

https://github.com/xyphro/WinUsbTmc/releases


To enable the license, use this command from the command line:
> WinUsbTmc Rigol ":SYST:OPT:INST LLLLLLLRLGLLDSDSA9LLLLLLLLLL"


Advantage of this WinUsbTmc tool compared to NI or Agilent IVI under windows is, that it is much smaller (No several hundred MB download required), much easier to integrate and... it is open source :-)
It is also possible to integrated it as DLL or static library in your own code.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 05, 2013, 11:57:54 am

In order to get a Permanent Option Key for your DSO it would have to be generated using your specific DS2000 serial number.
Did you send your Serial number to Someone?? 
Probably not, then do NOT expect to have a Option  Key Code for permanent Options!!

Thanks. I did not expect it to be permanent. However the 200MHz stayed permanent. So do you reckon this is a mere firmware bug - maybe even specific to FW version - , which we should also just enjoy?

Are the "options" keys different than the "type" keys. By looking at the Rigol_DS2000_patch_attiny85.ino (found here (http://gotroot.ca/rigol/) using google - all credit goes to author) they all are just values in FRAM. So do you suggest that the two codes work differently. More specifically they make the FW in case of the 200MHz to _write_ to FRAM (starting at locations 0x4A, 0x56, 0x5A and 0x62), while in case of the options it stays in volatile RAM?

Doma

suggest u read the whole thread ...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on July 05, 2013, 04:56:41 pm

tested some codes:

DSA9 is all options VSA9 is same but then with trail options
DSA9 overwrites VSA9, VSA can not overwrite DSA
xSA5 is same as xSA9

xSA2 is only 110 and 200 Mhz options on
xSA3 is Trigger and bandwidth options on
xSA6 is mem56 and bandwidth options on
xSA7 is trigger and mem56 and bandwidth on
xSA8 is decoder and mem56 and bandwidth on

xSAB is only Trigger options on
xSAC is only decode options on
xSAE is only mem56 on

Good job Wim13 - so we know that:

0000x   trigger
000x0   decode
00x00   memory
xx000   200Mhz

Do you have a facility for bandwidth testing?  I wonder what the xx in xx000 correlate to:

00000 - ? could 00 mean the factory setting, a DS2072 would be a DS2072, a DS2102 would be a DS2102, etc.
10000 - Forced DS2072 ???  Can someone verify this one - what does "DSAS" show for a model number?
01000 - Forced DS2102
11000 - Forced DS2202

Thanks,

Alan
Why do you constantly ask other people to do your testing ? Don't you have a DS2000 your self ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 5V on July 05, 2013, 05:57:32 pm
(...)

Then I applied the

LLLLLLL-RLGLLDS-DSARLLL-LLLLLLL
and
LLLLLLL-RLGLLDS-DSA9LLL-LLLLLLL
codes.

Results:
- It stays on 200 Mhz, with BW limits 20M/100M, and 2ns/div, says it's a DS2202 even after power cycling
- The options are activated only for the current power session, they are gone after reboot.

Thanks for the great work on this, highly appreciated!

I did the above and it worked as described (thanks Doma :-+). My DS2072 is converted in a 200MHz/DS2202. It stays as 200MHz/DS2202 mode after reboot. 8)

It may sound a silly question but... is there a way to switch back to 70MHz/DS2072, just in case I need to send the scope back in the warranty period?

Thanks!

Title: Sniffing the Rigol's internal I2C bus
Post by: ddavidebor on July 05, 2013, 06:07:56 pm
I suppose that should be possible to upgrade to 52mb of memory too, but it will need hardware modification
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 5V on July 05, 2013, 06:17:37 pm
(...)

Then I applied the

LLLLLLL-RLGLLDS-DSARLLL-LLLLLLL
and
LLLLLLL-RLGLLDS-DSA9LLL-LLLLLLL
codes.

Results:
- It stays on 200 Mhz, with BW limits 20M/100M, and 2ns/div, says it's a DS2202 even after power cycling
- The options are activated only for the current power session, they are gone after reboot.

Thanks for the great work on this, highly appreciated!

I did the above and it worked as described (thanks Doma :-+). My DS2072 is converted in a 200MHz/DS2202. It stays as 200MHz/DS2202 mode after reboot. 8)

It may sound a silly question but... is there a way to switch back to 70MHz/DS2072, just in case I need to send the scope back in the warranty period?

Thanks!

It is not a silly question, but is asked also several times, and answered several times...Yes it can.

Sorry Wim13, apologies if the answer has already been asked.  :-[

I did look for a code equivalent to the LLLLLLL-RLGLLDS-DSA9LLL-LLLLLLL code but that works in reverse but I couldn't find it  :-//

Perhaps, you can point me in the right direction?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: egonotto on July 05, 2013, 07:48:15 pm
Hello,

if you want back the DS2072 use the ....VSA9.....  option key. Than you have still the bandwith option. Now do a self cal. Than the options are gone and you have your DS2072 back.

Best regards

egonotto
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: doma on July 05, 2013, 08:00:38 pm
suggest u read the whole thread ...

Thanks, I did. Now I understand (volatility of options/type-BW across boot). You even need the first 10 pages to understand that and it is said explicitly nowhere, though it can be deduced from other facts.

Maybe a FAQ thread would be useful to keep guys like me from asking the obvious and take the thread OFF.

I'd do it happily but I'm afraid I'd just ask too much.

Doma
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on July 05, 2013, 08:06:22 pm
I tried with Python. I used Python 2.7.5, since 3.3 does not seem to be compatible with the VXI11 module.
I added a few delays, seems to be more stable when the options are installed.

I have set the scope IP address to fixed (10.0.0.80)
Works under W7  64bit....

Code: [Select]

#Make it a DS2202
LICENSE = "LLLLLLLRLGLLDSDSA9LLLLLLLLLL"
#or
#LICENSE = "LLLLLLLRLGLLDSDSAZLLLLLLLLLL"

#Make it a DS2072
#LICENSE = "LLLLLLLRLGLLDSVSA9LLLLLLLLLL"


import vxi11, sys, time
print("Connecting...")
rigol = vxi11.Instrument("10.0.0.80")
print("Model number before patch:")
print(rigol.ask("*IDN?"))
print("Getting current set-up...")
config = rigol.ask_raw(":SYSTem:SETup?")
time.sleep(3)
print("Writing license key... " + LICENSE)
rigol.write(":SYSTem:OPTion:INSTall " + LICENSE)
time.sleep(5)
print("Restoring set-up")
rigol.write_raw(":SYST:SET " + config)
print("Model number after patch:")
print(rigol.ask("*IDN?"))
time.sleep(5)
sys.exit(0)


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 5V on July 06, 2013, 11:21:37 am
Hello,

if you want back the DS2072 use the ....VSA9.....  option key. Than you have still the bandwith option. Now do a self cal. Than the options are gone and you have your DS2072 back.

Best regards

egonotto

I used the LLLLLLLRLGLLDSVSA9LLLLLLLLLL code. After that, the Utility/Options/Installed showed:

   BANDWIDTH    100M BandWidth    Trial Version   2157Minutes
   BANDWIDTH    200M BandWidth    Trial Version   2157Minutes

I run a self calibration after that but it didn't work:

- I can still set the horizontal scale to 2ns/div
- Utility/System/System_Info still shows "Model: DS2202"
- I lost all trial times (*)

(*) It's not great but it's not the end of the world. Fortunately, I don't need them for what I do anyway. If I need them I can always use the ...DSAR... code.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: egonotto on July 06, 2013, 12:04:33 pm
Hello 5v,

if you have FW 00.01.00.00.03 and still the option:
BANDWIDTH    100M BandWidth    Trial Version   ????Minutes
BANDWIDTH    200M BandWidth    Trial Version   ????Minutes


try a second self cal.

Sometimes it need 2 self cal's that the trial options vanishes

Best Regards,
egonotto
 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 5V on July 06, 2013, 12:25:55 pm
Hi egonotto,

Sorry, I didn’t explain myself clearly.  :(   I should have said "I run a self calibration after that. The 100MHz and 200MHz options disappeared but the reset to DS2072 didn't work"

The 100MHz and 200MHz options disappeared after the calibration. The Utility/option/installed is greyed out as there are no options installed anymore.

However, the Utility/System/System_Info still shows "Model: DS2202" and the horizontal scale can be set to 2nsec/div (200Mhz?)

I did a second self calibration just in case but it had no effect in resetting the scope to DS2072.

In a nutshell, the code ...VSA9... + calibration managed to delete all the trial options but it didn’t do much else.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: egonotto on July 06, 2013, 01:09:12 pm
Hello 5v,

I try it again.
I send via Ultra Sigma over LAN the command:
:SYSTem:OPTion:INSTall LLLLLLLRLGLLDSVSA9LLLLLLLLLL
Than I turn of and on and I got my DS2072 back. I need no self cal.
I got my remaining trial time back.

Best Regards
egonotto
 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 5V on July 06, 2013, 01:44:29 pm
Hello 5v,

I try it again.
I send via Ultra Sigma over LAN the command:
:SYSTem:OPTion:INSTall LLLLLLLRLGLLDSVSA9LLLLLLLLLL
Than I turn of and on and I got my DS2072 back. I need no self cal.
I got my remaining trial time back.

Best Regards
egonotto

Unfortunately, it didn’t work.  :(

The scope answered with "Trial version installed" after I sent the command over the LAN.

I waited for a few seconds, turned off/on the scope. No changes (DS2202, no trial times).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 5V on July 06, 2013, 01:50:40 pm
Hi,

I waited for a few seconds, turned off/on the scope. No changes (DS2202, no trial times).

So you are unable to change your scope back to a DS2072?

Thanks,

Alan

Correct - I'm unable to change the scope back to a DS2072.

I don't know if it is of any help but I'm on firmware 00.01.00.00.03

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on July 06, 2013, 01:55:17 pm
Correct - I'm unable to change the scope back to a DS2072.

I don't know if it is of any help but I'm on firmware 00.01.00.00.03
Man, it doesn't sound like you've read the correct way to do it (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg253823/#msg253823) - even after Wim pointed you to the precise page of this thread that explains how!

Seriously - read that - try it - and then come here to complain you can't do it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: metalphreak on July 06, 2013, 01:57:21 pm
You don't install another code to go back to stock. You use the UNINSTALL command.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 5V on July 06, 2013, 02:24:14 pm
Correct - I'm unable to change the scope back to a DS2072.

I don't know if it is of any help but I'm on firmware 00.01.00.00.03
Man, it doesn't sound like you've read the correct way to do it (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg253823/#msg253823) - even after Wim pointed you to the precise page of this thread that explains how!

Seriously - read that - try it - and then come here to complain you can't do it.

I unknow the page you are referring to (http://url=https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg253823/#msg253823) and, among the other tests, I also I did what the post says.

This what I did.

1.
I used the code LLLLLLL-RLGLLDS-VSA9LLL-LLLLLLL via the scope user interface
Run a self-calibration

2.
With Ultra-Sigma (LAN and USB) I run the command:
   :SYSTem:OPTion:INSTall LLLLLLLRLGLLDSVSA9LLLLLLLLLL

3.
With Ultra-Sigma (LAN and USB) I run the command:
   :SYSTem:OPTion:INSTall LLLLLLLRLGLLDSVSA9LLLLLLLLLL
followed by
   :SYSTem:OPTion:UNINSTall

4.
With Ultra-Sigma (LAN and USB) I run the command:
   :SYSTem:OPTion:INSTall LLLLLLLRLGLLDSDSA9LLLLLLLLLL
followed by
   :SYSTem:OPTion:UNINSTall

5.
With Ultra-Sigma (LAN and USB) I run the command:
   :SYSTem:OPTion:UNINSTall

After each test, I did a power cycle. None of the above worked.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on July 06, 2013, 02:32:38 pm
After each test, I did a power cycle. None of the above worked.
Can you please post a screen image of your full system info (with your serial number blacked out, if you wish)? You get it by using the technique mentioned at the bottom of this post (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 5V on July 06, 2013, 02:41:48 pm
(...) Can you please post a screen image of your full system info (with your serial number blacked out, if you wish)? (...)

As an extra info, if I run the command *IDN? with UltraSigma, I receive the answer:
RIGOL TECHNOLOGIES,DS2202, < serial number> ,00.01.00
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on July 06, 2013, 02:59:47 pm
(...) Can you please post a screen image of your full system info (with your serial number blacked out, if you wish)? (...)

Ok, thanks. Well, here's the thing - you have the exact same hardware that I (and probably everyone else who has bought their DSO between at least 10/2012 - 05/2013) have. Since others with the exact same hardware and firmware as you - have not had any problems resetting their model numbers back to DS2072s, I can only think of two possible reasons why you can't do it:

1) You're doing some part of the sequence incorrectly - but what that could be is hard to say, since we can't look over your shoulder while you do it.

2) Since you're a brand new poster here - who's FIRST post was: "Is there a way to switch back to 70MHz/DS2072, just in case I need to send the scope back in the warranty period?" - and then all your subsequent posts have been how it's IMPOSSIBLE to change it back - well...... I would just have to wonder if you're being completely truthful (for the obvious reason).  ;)

Can you think of another reason I haven't thought of?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on July 06, 2013, 03:03:33 pm
As an extra info, if I run the command *IDN? with UltraSigma, I receive the answer:
RIGOL TECHNOLOGIES,DS2202, < serial number> ,00.01.00

BTW, downgrading your FW to 01.00.05 should definitely reset your model number - since 01.00.05 does NOT have BW options enabled.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 5V on July 06, 2013, 03:30:48 pm
Thanks Wim13,

Quote from: Wim13
1, connect Ultra Sigma,
Done with LAN.

Quote from: Wim13
2. *IDN, send and recieve , to verify you are connected.
Done. Answer: RIGOL TECHNOLOGIES,DS2202, <serial>,00.01.00

Quote from: Wim13
3. send install DSA9 code, ( NOT the VSA code, VSA connot run over DSA !! )
you will see in the bottom of the screen in few seconds, off ..installed
Sent the message:
:SYSTem:OPTion:INSTall LLLLLLL-RLGLLDS-DSA9LLL-LLLLLLL
No message on the scope.

Quote from: Wim13
4 verify on the DSO, that the options are there, ALL options if here are no off. options visible, then you can NOT continue. Also not if there are still trial options.
The Options/Utility/Installed is greyed out. (None of the options are active)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 5V on July 06, 2013, 03:54:38 pm
Did you realy send the dashes in between...??? in the key

The key has to be send with NO dashes , just 28 char on the chain..!!

I'm officially on idiot  |O  Re-tried without the '-':

1. connect Ultra Sigma,
Ok
2. *IDN, send and recieve , to verify you are connected.
Ok
3. send install DSA9 code, ( NOT the VSA code, VSA connot run over DSA !! )
you will see in the bottom of the screen in few seconds, off ..installed

:SYSTem:OPTion:INSTall LLLLLLLRLGLLDSDSA9LLLLLLLLLL
Ok.
4 verify on the DSO, that the options are there, ALL options
Ok. All options are on.
5. send the  uninstall command, ONLY the install command NO keys behind it.
:SYSTem:OPTion:UNINSTall
Ok. All options are gone.
6. you dont have to reboot, to check, after uninstall all should be gone..
All options are gone.

Utility/System Info still shows Model: DS2202 and can set horizontal scale to 2nsec/div.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 5V on July 06, 2013, 03:56:28 pm
(...) Can you please post a screen image of your full system info (with your serial number blacked out, if you wish)? (...)

Ok, thanks. Well, here's the thing - you have the exact same hardware that I (and probably everyone else who has bought their DSO between at least 10/2012 - 05/2013) have. Since others with the exact same hardware and firmware as you - have not had any problems resetting their model numbers back to DS2072s, I can only think of two possible reasons why you can't do it:

1) You're doing some part of the sequence incorrectly - but what that could be is hard to say, since we can't look over your shoulder while you do it.

2) Since you're a brand new poster here - who's FIRST post was: "Is there a way to switch back to 70MHz/DS2072, just in case I need to send the scope back in the warranty period?" - and then all your subsequent posts have been how it's IMPOSSIBLE to change it back - well...... I would just have to wonder if you're being completely truthful (for the obvious reason).  ;)

Can you think of another reason I haven't thought of?

1) This is probably the case. The only thing that might be different is the firmware. I don’t know if this has any impact though.

To answer your last question, it is also possible (although unlikely) that I did something else that put the DS2072 is a status that cannot be converted back. Something that other people didn’t do.

2) I would like to point out that I never said that it’s impossible. I can’t do it probably because of my limited experience.

Having said that, I understand where you came from. I guess there isn’t much I can do on this front to give you absolute proof that my problems are genuine.

I’ll be happy to send you a PM with a photo of my DS2072, my face and my credit card with the number deleted. This should show you (and the other people on the forum that may have doubts) that I don’t have any hidden agenda. Please let me know if you want me to do it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 5V on July 06, 2013, 04:34:00 pm
@5V

Just in case , i just did the same procedure by my self again, and after the uninstall it was back to the 2072
i did not have to reboot. 

So i am lost too..., that would mean that it has changed the model number also on the NOR flash...

If you are lost Wim13, you can imagine how I am :)

I agree - I must have done something that has written the model number in the NOR flash.

It looks like the
:SYSTem:OPTion:INSTall LLLLLLLRLGLLDSDSA9LLLLLLLLLL
:SYSTem:OPTion:UNINSTall
don't reset it back to DS2072

I can't remember doing anything specific that may have triggered that though.

@5V

Can you try the following key: DSA2 key, only Model change, 100 and 200 Mhz option

:system:option:install LLLLLLLRLGLLDSDSA2LLLLLLLLLL   

or the DSAS key, only 2202 key, only 200 Mhz option

:system:option:install LLLLLLLRLGLLDSDSASLLLLLLLLLL

Verify if the options for only bandwidth

and then

:system:option:uninstall

You dont have to reboot, the model change wil be visible if correct of course.


i tested it on my 2072, it changed from 2202 and back to 2072, without rebooting
several times with no problems, tested both keys.



:system:option:install LLLLLLLRLGLLDSDSA2LLLLLLLLLL   
:system:option:uninstall

didn't do anything.

:system:option:install LLLLLLLRLGLLDSDSASLLLLLLLLLL
:system:option:uninstall

created the 200Mhz option and the unstall removed it.

Utility/System Info still shows Model: DS2202 and I can set horizontal scale to 2nsec/div.

I guess the only thing I can do is try to find a Rigol sticker with DS2202 on it  :D

Do you think that upgrading to the latest firmware would help?

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 5V on July 06, 2013, 04:53:52 pm
@ 5V,

Upgrading to the new firmware is a very good thing to do, solved lost of bugs..anyway...

and you never Know..,

One thing we can try, reboot, verify there are no options loaded, and load the trail key

:system:option:install LLLLLLLRLGLLDSVSA9LLLLLLLLLL
 This will also change the model to 2072.

Upgraded to fw 01.01.00.02

:SYSTem:OPTion:INSTall LLLLLLLRLGLLDSDSA9LLLLLLLLLL
:SYSTem:OPTion:UNINSTall


:system:option:install LLLLLLLRLGLLDSVSA9LLLLLLLLLL
:SYSTem:OPTion:UNINSTall


Still DS2202  |O
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 5V on July 06, 2013, 05:13:22 pm

@5V

Well not realy a big problem as long the DSO is keep on working...
And when broken, maybe they never discover, depends on he failure..

Finger crossed, I will keep using it without any problem that requires Rigol's assistance.

BUT , nice thing to find out, what did you do,

how id you put in the code, keyboard ?
how many times did you a self-cal..?
other minor things  you remenber...?

I agree. It would be interesting to know what caused it. I'll be happy to help answering questions or doing tests if it is of any help to others.

Q: how id you put in the code, keyboard ?
A: Using the scope user interface. I applied
  LLLLLLL-RLGLLDS-DSARLLL-LLLLLLL
followed by
  LLLLLLL-RLGLLDS-DSA9LLL-LLLLLLL

Q: how many times did you a self-cal..?
A: I followed this suggestion (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg257587/#msg257587). I did the self cal after I applied the code
  LLLLLLL-RLGLLDS-VSA9LLL-LLLLLLL
using the scope user interface.

Q: ther minor things  you remenber...?
A: Honestly, I can't remember doing anything out of the ordinary. I measured some signals and I took a screenshot or two.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: egonotto on July 06, 2013, 05:35:44 pm
Hello,

perhaps 5V got a real DS2202 with wrong DS2072 sticker

Best Regards
egonotto
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on July 06, 2013, 05:43:34 pm
Having said that, I understand where you came from. I guess there isn’t much I can do on this front to give you absolute proof that my problems are genuine.

I’ll be happy to send you a PM with a photo of my DS2072, my face and my credit card with the number deleted. This should show you (and the other people on the forum that may have doubts) that I don’t have any hidden agenda. Please let me know if you want me to do it.

No credit card or photos needed ;D  But I sent you a PM.  :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 5V on July 06, 2013, 05:47:22 pm
Hello,

perhaps 5V got a real DS2202 with wrong DS2072 sticker

Best Regards
egonotto

 :-DD
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: doma on July 06, 2013, 07:37:57 pm
(...) Can you please post a screen image of your full system info (with your serial number blacked out, if you wish)? (...)


5V got MCU 00.05 - I have 02.12. Maybe that makes a difference. SPU, WPU, CCU are the same.

I don't know if I can uninstall DS2202 - and just I don't want to try it unless I have to ;)

Doma
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: egonotto on July 06, 2013, 08:01:32 pm
Hello,

my DS2072 has also MCU 00.05 and I can switch between DS2202 and DS2072

Best Regards
egonotto
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hl on July 06, 2013, 10:25:02 pm
Hello,

perhaps 5V got a real DS2202 with wrong DS2072 sticker

Best Regards
egonotto

Looks like I need that sticker, too. My DS2072 also completely transformed into a DS2202. I found also no way to get back.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on July 06, 2013, 10:26:42 pm
I found also no way to get back.

Did you try uninstalling the key as others have mentioned above?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hl on July 06, 2013, 10:37:58 pm
I found also no way to get back.

Did you try uninstalling the key as others have mentioned above?

I tried all combinations incl. double self-cal, downgrade to earlier fw, trial code, uninstall and everything mentioned here in this thread on every downloadable fw. Of course in the correct order. No way. The only thing that happened once ... the model number was suddenly DS2022 (no, no typo) and both bandwidth options were gone. But I never got back to the real model number.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: orbiter on July 06, 2013, 11:01:20 pm
Hey guys,

In your scope options.... 

Following the DSA9 serial number input, and the scope showing up as a DS2202. Do you guys still have the 200MHz option still
showing?, or does that disappear once the scope is 'upgraded' as it is effectively a DS2202?

The reason I ask is that I have no options showing at all, however I do still have the 2ns/div timebase and the scope model as a DS2202.

Cheers   
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 5V on July 07, 2013, 11:42:37 am
It gets weirder... this morning I switched on the scope and all the trial times were back. I didn’t do anything (serials, tests, calibration…) beforehand. I simply took it out of the case and I switched it on.  :o

The 100MHz and the 200MHz options are not there but I guess it makes sense as the scope believes it is a DS2202.

Utility/System Info still shows “Model: DS2202”, I can set horizontal scale to 2nsec/div and BW limit to 20MHz or 70MHz.

(...) Following the DSA9 serial number input, and the scope showing up as a DS2202. Do you guys still have the 200MHz option still showing?, or does that disappear once the scope is 'upgraded' as it is effectively a DS2202?

The reason I ask is that I have no options showing at all, however I do still have the 2ns/div timebase and the scope model as a DS2202. (...)

This is what I had yesterday. No options: the Options/Utility/Installed was greyed out.

I tried all combinations incl. double self-cal, downgrade to earlier fw, trial code, uninstall and everything mentioned here in this thread on every downloadable fw. Of course in the correct order. No way. The only thing that happened once ... the model number was suddenly DS2022 (no, no typo) and both bandwidth options were gone. But I never got back to the real model number.

So now we have two people saying they can't get back to DS2072 ???

It looks like it. At least 2 people can't go back to DS2072. Although after this morning my situation is slightly different as I got my trial times back.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 5V on July 07, 2013, 01:53:59 pm
@ 5v, Strange that you are showing 70MHz in BW options, once mine shows up as a DS2202 the BW options are 20 & 100MHz.

Sorry - typo. I can't check the scope right now but I think BW are indeed 20 & 100Mhz.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: doma on July 07, 2013, 04:18:11 pm
I believe the key is in what cybernet is doing. Identifying the subs involved in the mechanism and finding out what and how they do using what information. Until that we're pretty much in the dark :)

 A tough job if you need to fix a screw-up but can be a good challenge for fun. :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: poida_pie on July 08, 2013, 01:44:41 am
I recently used the 2072 trials down to about 1200 minutes. f/w is 03
No self cals have been done since I purchased the unit until...
Then, while it was impersonating a 200 Mhz 2202 only (via one of the service mode keys) I chose to self cal.
After self cal
- no trials any more
- retains model 2202 name but without 200 Mhz bandwidth after a reboot
- still responds to VSAx and DSAx  service mode keys
So I thought, no worries, I'll just send the key needed via USB from now on.
So I have sent various DSAx codes, I like DSA8 since all I want is memory and procol decode.

This morning I started up the 2072 and it retained the trial time limits. No need to re-enter the codes for a while!

So, for those who can't be arsed to read the above I'll say it again:
My trial time was 1200 minutes, self cal killed them. f/w 03
On my 2072 I have re-enabled some of the trials (non-volatile, i.e. retained over power cycles)
by using the DSAx and VSAx codes only. 
Time left on trials now 1800 minutes.
All via USB. No elements of the "special procedure" were employed.



Title: Re: Sniffing the Rigol's internal I2C bus
Post by: orbiter on July 08, 2013, 12:30:42 pm
Another confirmation of being unable to revert to model DS2072.

Tried ALL combinations as mentioned by Wim & other users. No Go... My scope is fixed as a DS2202. Now that in itself is not a bad thing although
on initial boot my scope screen shows up like this :wtf:

(http://img.photobucket.com/albums/v146/orbiter/IMAG0681_zpsf8ceb87d.jpg) (http://smg.photobucket.com/user/orbiter/media/IMAG0681_zpsf8ceb87d.jpg.html)
(http://img.photobucket.com/albums/v146/orbiter/IMAG0678_zps8e897dad.jpg) (http://smg.photobucket.com/user/orbiter/media/IMAG0678_zps8e897dad.jpg.html)
(http://img.photobucket.com/albums/v146/orbiter/DS2_QuickPrint1_zps2012366b.jpg) (http://smg.photobucket.com/user/orbiter/media/DS2_QuickPrint1_zps2012366b.jpg.html)


If I reboot it a second time it boots and works just fine.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on July 08, 2013, 12:57:59 pm
Another confirmation of being unable to revert to model DS2072.

Tried ALL combinations as mentioned by Wim & other users. No Go... My scope is fixed as a DS2202. Now that in itself is not a bad thing although
on cold boot my scope screen shows up like this :wtf:

Did you buy your Rigol through Telonic in the UK?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: orbiter on July 08, 2013, 12:59:12 pm
Another confirmation of being unable to revert to model DS2072.

Tried ALL combinations as mentioned by Wim & other users. No Go... My scope is fixed as a DS2202. Now that in itself is not a bad thing although
on cold boot my scope screen shows up like this :wtf:

Did you buy your Rigol through Telonic in the UK?

No mate.. Batronix.

A good few months ago too.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Marc M. on July 08, 2013, 01:16:05 pm
Another confirmation of being unable to revert to model DS2072...
I just received my 2072 on Friday the 5th from TEquipment.  FW was 05, updated to 02.  I just tried uninstalling the service options via Ultra Sigma and had no issues.  Model switched back to DS2072.  My Serial is: DS2A151200xxx
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: orbiter on July 08, 2013, 02:12:29 pm
Another confirmation of being unable to revert to model DS2072...
I just received my 2072 on Friday the 5th from TEquipment.  FW was 05, updated to 02.  I just tried uninstalling the service options via Ultra Sigma and had no issues.  Model switched back to DS2072.  My Serial is: DS2A151200xxx

This does seem strange... I'm using the correct procedure (below) to switch back using Ultra Sigma v00.01.05.01. Yet nowt happens as regards getting 2702 to show up again.

Connect DSO via USB; boot the DSO; start Ultra Sigma; open SCPI Control Panel; type (or copy and paste) the following:

:SYSTem:OPTion:INSTall XXXXXXXXXXXXXXXXXXXXXXXXXXX  (the code)

then, if you want to get rid of it, immediately enter (without reboot):

:SYSTem:OPTion:UNINSTall


I'm able to install options, uninstall options & change firmwares about how I like between versions (05) (03) (02) even tried simple things like turning
boot configuration option on the scope from 'LAST' to 'DEFAULT' etc. Still no luck.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: orbiter on July 08, 2013, 02:17:16 pm
Quote
So you can now get back to DS2072 orbiter?

No.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: orbiter on July 08, 2013, 02:20:11 pm
No.

I missed the word "nowt"...

lol ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: adcajo on July 09, 2013, 09:18:17 am
Yes - the only key I used is the VSA9 with the behaviour according to alank2 description above (incl "trial"-message). It turned into a DS2202 and it sticks to this model label, regardless power on/off or uninstall options.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: orbiter on July 09, 2013, 09:25:22 am
For you guys who can't return to a DS2072, can you load the VSA9 key successfully?  Do you get a screen message about "trial" or something when you load it?  But yet it stays as DS2202?

Yes Alan. All commands confirmed on the scope, inc trials, options installed & uninstalled etc

I can install/uninstall anything at all regarding the trials/options etc. However the scope will not revert back to a DS2072.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on July 09, 2013, 10:05:20 am
I can install/uninstall anything at all regarding the trials/options etc. However the scope will not revert back to a DS2072.

There is one other thing that might work for those whose model numbers are stuck on a higher number. You want to force the DSO to use the backup copy of the model data by exploiting the firmware upgrade bug.

They only thing is that I'm not sure when that bug was fixed - it definitely existed in FW.00.01.00.02 - but I'm not sure if it was repaired in FW.00.01.00.05 or FW.01.00.00.03. Unfortunately, there aren't any copies of FW.00.01.00.02 floating around (that I'm aware of), but you can give it a try using FW.00.01.00.05 (I think it still exists in that):

1) Downgrade to FW.00.01.00.05
2) Boot the DSO
3) While running the DSO normally, insert a USB stick with FW.01.00.00.03 on it.
4) When you see the message, "A newer firmware detected, update?" press 'OK".
5) a) If the update works normally - then the firmware upgrade bug does not exist in FW.00.01.00.05 - and this method won't work.
    b) If the update process freezes about 60% of the way - then the bug has happened. Continue to next step.
6) Turn off the DSO, then upgrade it using the boot-loader process (the 'Help' button method). The backup copy of model data will be duplicated and used.
7) Boot up and check model number.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: orbiter on July 09, 2013, 10:34:17 am
Hi marmad...

When you say 'the back-up copy will be duplicated and used' (Step 6) what do you mean?

Once the scope is booted and the 'help' button pressed.. What next as regards FW?.. Do you mean just re-install FW01.01.00.02 or press
a sequence of buttons to reload some saved FW etc?

Thanks mate
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on July 09, 2013, 10:47:43 am
When you say 'the back-up copy will be loaded' what do you mean?

There are two copies of all the model data (model number, calibration data, etc): the working copy and the backup copy. I can't say for certain whether the model number has been changed in both copies (for those of you who can't get it back), but in any case, this method, if successful, will restore the backup copy.

Quote
Once the scope is booted and the 'help' button pressed.. What next as regards FW?.. Do you mean just re-install FW01.01.00.02 or press a sequence of buttons to reload some saved FW?

Re-install any FW - if you have gotten to this step (i.e. invoked the firmware upgrade bug by causing it to freeze while upgrading) you can use any version of the FW (00.01.00.05, 01.00.00.03, or 01.01.00.02) because the DSO should automatically use the backup copy of model data while upgrading:

The boot loader upgrade method:
1) Use two hands when booting up - one thumb on the 'Power On' switch - one thumb on the 'Help' button. When you press 'Power On', all of the scope LEDs will light for ONE SECOND - during that brief period, you must PRESS AND LET GO of the 'Help' button. It can be a little tricky, but when it works, bootup will stop before the Rigol logo with the 'SINGLE' button lit (if it doesn't, turn off power and try again until you get it).
2) Then insert the USB stick with whatever FW file you want to use on it. The CH1 LED will start to flash as the DSO loads the file.
3) Once updating is finished, several of the LEDs will light up - and all flashing, etc. will stop.
4) Remove the USB stick and reboot, and check your model number.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: orbiter on July 09, 2013, 10:52:13 am
Hi marmad...

Tried the procedures in sequence as you mentioned....

FW initially downgraded to FW.00.01.00.05

Rebooted and flashed again (USB method) with FW.00.01.00.03, this completed fully and the scope rebooted automatically. Still
as a DS2202.

Re-installed FW 01.01.00.02 on re-boot (help button method)   

Scope is still a DS2202.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on July 09, 2013, 10:56:22 am
Tried the procedures in sequence as you mentioned....

FW initially downgraded to FW.00.01.00.05

Rebooted and flashed again (USB method) with FW.00.01.00.03, this completed fully and the scope rebooted automatically. Still
as a DS2202.

Re-installed FW 01.01.00.02 on re-boot (help button method)   

Scope is still a DS2202.

Well clearly the firmware upgrade bug was not invoked - the update didn't freeze. No reason to use the boot loader process after this since it wouldn't have done anything - and this doesn't answer the question of whether your model number is changed in both copies of memory or not.

It's a pity there isn't a copy of FW 00.01.00.02 around.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: orbiter on July 09, 2013, 11:13:21 am
< agreed mate.

I think something maybe happening in memory before the FW has loaded up fully (see yellow screen previous page) this yellow screen shows on almost every
cold boot for me (although not temperature related.) I get no beeps and the relays don't click either. Only started following FW switching :)

Anyway.. Sometimes (after 20 secs) the relays will click & the screen will show as normal, other times the scope will need a second boot to start normally.

Perhaps for the guys including me that can't go back, a damaged or corrupt piece of left over FW code is trying to load at a boot, before correct FW?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: orbiter on July 09, 2013, 12:17:09 pm
I've given up trying for the moment mate.. I need to use the scope. I may try later.

I could really do with some more help getting it back to a DS2702 though, as I'd like to see if that would clear the error (I believe) regarding my yellow screen on cold boot..
https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/420/. (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/420/.)

Cheers
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: orbiter on July 09, 2013, 12:24:52 pm
Also, have you tried the default settings option?  I think if you press/hold one of the side menu buttons (6th one down?  not sure) it reverts the scope to factory settings.  This might also be worth trying.

Yes tried that a few times mate at various stages with different FW's. That button just resets the scope settings to default. 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: adcajo on July 10, 2013, 07:50:42 am
But - the procedure described above is exactly what made my DS2072 turned into to a DS2202 in the first place...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on July 10, 2013, 09:22:11 am
:system:option:install LLLLLLLRLGLLDSDSARLLLLLLLLLL   ( makes 2102 )
:system:option:install LLLLLLLRLGLLDSDSAZLLLLLLLLLL   ( makes 2202)


Code tabel:

DSAx, 2202, 2102,  mem56, Decode, Trigger

2072

A   none
B   ==   ==   ==   ==   on
C   ==   ==   ==   on   ==
D   ==   ==   ==   on   on
E   ==   ==   on   ==   ==
F   ==   ==   on   ==   on
G   ==   ==   on   on   ==
H   ==   ==   on   on   on

2102

J   ==   on   ==   ==   ==   
K   ==   on   ==   ==   on
L   ==   on   ==   on   ==
M   ==   on   ==   on   on
N   ==   on   on   ==   ==
P   ==   on   on   ==   on
Q   ==   on   on   on   ==
R   ==   on   on   on   on

2202

S   on   ==   ==   ==   ==   
T   on   ==   ==   ==   on
U   on   ==   ==   on   ==
V   on   ==   ==   on   on
W   on   ==   on   ==   ==
X   on   ==   on   ==   on
Y   on   ==   on   on   ==
Z   on   ==   on   on   on

dont use below as activates 2102 and also 2202

2   on   on   ==   ==   ==
3   on   on   ==   ==   on
4   on   on   ==   on   ==
5   on   on   ==   on   on
6   on   on   on   ==   ==
7   on   on   on   ==   on
8   on   on   on   on   ==
9   on   on   on   on   on

According to this table the  "H" should turn it into a 2072. On mine it does not do this (even after a fresh reboot of the scope).
The only way to get back to a 2072 is with the VSA9 key. (on my system at least). I don't make a big deal out of it to use it in 2072 mode. Warranty sticker is voided anyhow.
Using FW 1.1.0.2
It might very well be that there are bugs in the key algorithms  :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MrsR on July 10, 2013, 10:38:37 am
Works for my DS2072 perfectly, firmware 00.01.00.00.03.
As I still had my trial options available, I was a little hesitant to try this, but they are back to previous values after restart so nothing is lost.

VSA9LLL enabled all options as trial (2100+ minutes were added to remaining time for trigger, 56M and decode options) but 2ns timebase wasn't available.

DSA9LLL enabled 2ns timebase and 100M BW limit.

Great work, thanks  :-+

If you have a DS2072 with 56M  loaded (not trial version) would you lose it by putting DSA9LLL in ?????

Mrs R :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on July 10, 2013, 11:29:31 am
Works for my DS2072 perfectly, firmware 00.01.00.00.03.
As I still had my trial options available, I was a little hesitant to try this, but they are back to previous values after restart so nothing is lost.

VSA9LLL enabled all options as trial (2100+ minutes were added to remaining time for trigger, 56M and decode options) but 2ns timebase wasn't available.

DSA9LLL enabled 2ns timebase and 100M BW limit.

Great work, thanks  :-+

If you have a DS2072 with 56M  loaded (not trial version) would you lose it by putting DSA9LLL in ?????

Mrs R :-+

I would not fiddle around with this if not absolutely needed. nobody knows exactly what happens with official keys, because nobody buys them, well at least the members from this forum  ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on July 10, 2013, 12:08:02 pm
If you have a DS2072 with 56M  loaded (not trial version) would you lose it by putting DSA9LLL in ?????

Mrs R :-+

Not a problem. Official keys can be installed or uninstalled at will. If you put a code in which changes an official option to a trial, you can always re-enter the official key again to change it back to official.

nobody knows exactly what happens with official keys, because nobody buys them, well at least the members from this forum  ;)

There are a few of us members here with official keys.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: darrylp on July 10, 2013, 01:26:41 pm
Our very own Mr Jones on here has a fully loaded DS2202 ;-)

So Dave, are you reading ?

--
 Darryl

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Chet T16 on July 10, 2013, 02:01:17 pm
I have a code to unlock 100MHz and serial decode on mine. I thought it was interesting that it was a single code.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on July 10, 2013, 02:56:15 pm
If you have a DS2072 with 56M  loaded (not trial version) would you lose it by putting DSA9LLL in ?????

Mrs R :-+

Not a problem. Official keys can be installed or uninstalled at will. If you put a code in which changes an official option to a trial, you can always re-enter the official key again to change it back to official.

nobody knows exactly what happens with official keys, because nobody buys them, well at least the members from this forum  ;)

There are a few of us members here with official keys.
Yes, there are always exceptions to the rule.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Marc M. on July 12, 2013, 07:54:58 am
Good News Everyone!  I found a nice little stand alone utility for Windows users that will send either the DSAZ key or the VSA9 key to your DS2072 via USB.  It will auto-detect any 2000 series scope attached to the computer and provides a button for either key.  It pulls your current configuration, sends the key, then restores your configuration.  The only files it requires on your system are the NI VISA drivers.  Tested it on my Win 7 system and it works like a charm :-+ :-+ :-+.

Marc -
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on July 12, 2013, 01:07:46 pm
Good News Everyone!  I found a nice little stand alone utility for Windows users that will send either the DSAZ key or the VSA9 key to your DS2072 via USB.  It will auto-detect any 2000 series scope attached to the computer and provides a button for either key.  It pulls your current configuration, sends the key, then restores your configuration.  The only files it requires on your system are the NI VISA drivers.  Tested it on my Win 7 system and it works like a charm :-+ :-+ :-+.

Marc -
You also need to install the RIGOL DS2000 USB driver software....
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on July 12, 2013, 04:44:06 pm
You also need to install the RIGOL DS2000 USB driver software....

Are you sure - I just loaded only the ni visa runtime and nothing else and it worked for me on win7 x64.  The DS2072 was recognized as USB Test and Measurement Device (IVI) so either the driver came with the ni visa runtime or could have been part of windows maybe...
I deinstalled all, and tried it again. Its now OK. NI package contains a generic instrument USB driver.
 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MrsR on July 12, 2013, 08:43:35 pm
The mistake I made in buying the 2072 is the very slow rise time 5ns,I need a faster rise time my cheap Siglant scope that I chucked in a cupboard has a5ns rise time and it cost $270 AU.

A couple of things I found out from RIGOL China is:
/DS2000 can only have a max of 2 trial updates then that's it
/there are at least 2 versions of 03 software.
/a new version of 03 will come out which you will not lose the trial versions when doing a Re Cal.
/I have not found away to put more than 2 Re Cals. in.
/You lose the ability to use Official Trial versions if you do the Trial reload.
RIGOL China is very helpful at first but if (good English used) if they can't solve the problem in 3 emails they start talking pigeon Chinese English. This is used to stop you asking for more Help I think
I am still going to pester them though.

Mrs R :-+
Title: Return to original DS2072 model
Post by: Chalky on July 13, 2013, 10:28:01 am
But - the procedure described above is exactly what made my DS2072 turned into to a DS2202 in the first place...
This worked for me: install the '9' code, then install the '2' code, then do uninstall (no code needed), then reboot (might not be needed).

 My DS2072 was reporting as DS2202, now it is DS2072 again, and all features are as per DS2072.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Chalky on July 13, 2013, 12:29:00 pm
Posted app in the Software for Rigol forum: https://www.eevblog.com/forum/projects/software-tips-and-tricks-for-rigol-ds200040006000-ultravision-dsos/msg261360/#msg261360 (https://www.eevblog.com/forum/projects/software-tips-and-tricks-for-rigol-ds200040006000-ultravision-dsos/msg261360/#msg261360)

Detects Rigol scopes on your local network, or any scope on USB, and auto-sends licence codes, and any other commands to the scope.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MrsR on July 13, 2013, 06:14:21 pm


[/quote]

You could know this, because Rigol tells this in the datasheets, so there is no reason to complain, i think.

The 2072 is to the book 5 nSec, but because its bandwidth is 112 Mhz at 50 ohm, you get 3.2 nSec
And thats is also users here confirm and measure,

if you lower the termination resistor you can get more.

And you can for the time being ( unitl Rigol fixed it in the new FW ), try the test keys from this topic, to try 1.5 nSec

And as here before the latest FW is 00.01.01.00.02
[/quote]

Thanks,
Actually I had a DS2202, I had just hooked it up and it got fried, it lived for about 5 hours.
I didn't have enough money to buy another 200Meg version so got the 72 Meg one.
I didn't read the Spec. Sheet fully so the 5ns mistake.
Yep!!! my fault.
Mrs R :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Chalky on July 13, 2013, 10:10:16 pm
Hi,

From your code, what do these codes do:

                        <string>:SYSTem:OPTion:INSTall EEEEEEEBEBEEBBBBN5EEEEEEEEEE</string>
                        <string>:SYSTem:OPTion:INSTall EEEEEEEBEBEEBBBBN6EEEEEEEEEE</string>
Hi there alank2, they are just examples, you need to replace them with your own codes.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 15, 2013, 10:11:07 pm
"small" update from the key department - i have a fully working (forward) implementation of the license key check.
inputs are serial + license key - out comes valid or not and what features (i already explained that part) ;-) ... was a heavy ride, especially emulating the Blackfin ALU (its behaviour is integral part of their keys) - i almost bet they run the official keygen in an emulator for bfin ;-)

anyhow its now time to analyse input vs. output - and then figure out some shortcuts to a valid key in reverse. bruteforce will probably not work - most values are 2^64 - and if u ever wondered why it takes some time to "process" the input of a key - yes its doing a shitload of stuff with the input ...
if anyone is willing to invest time into reversing parts of their functions let me know, i will post some parts that need work  and some documentation later on. (its quite a brainfuck ;-)

also i only checked it with trial keys for now - no reason to believe that a offical key works otherwise but if someone could share an offical key + serial that would help.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: synapsis on July 16, 2013, 12:25:52 am
Just got my DS2072 from Tequipment today. It's running SW 00.01.00 which was a little surprising to me, because I believe that's the SW that was running on Dave's unit in his review a year ago.

I just want to clarify the Self-cal procedure (my scope is a couple divs off at 500uV.) Does the Self-cal clear the hacked keys? I.e., should I self cal first, then enter the keys?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 16, 2013, 12:54:32 am
https://github.com/CertiVox/MIRACL/tree/master/source

have fun. thats what rigol is using as their crypto engine - mrcore.c is basically what i reversed ...
Title: Sniffing the Rigol's internal I2C bus
Post by: zibadun on July 17, 2013, 03:40:35 am
https://github.com/CertiVox/MIRACL/tree/master/source

have fun. thats what rigol is using as their crypto engine - mrcore.c is basically what i reversed ...

It looks like a very efficient public key encryption method (elliptic curve?).

"The primary benefit promised by ECC is a smaller key size, reducing storage and transmission requirements—i.e., that an elliptic curve group could provide the same level of security afforded by an RSA-based system with a large modulus and correspondingly larger key—e.g., a 256-bit ECC public key should provide comparable security to a 3072-bit RSA public key (see key sizes below)."



And what you did was key validation (I.e. checking the signature).  Do you think this can be taken further and private keys recovered?  That seems like a huge leap in difficulty. On the wikipeadia they talk about successfully using a network of a computers (2600 for 17 months) to recover a moderately sized key. Ouch!

http://en.m.wikipedia.org/wiki/Elliptic_curve_cryptography
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: frenky on July 17, 2013, 06:50:18 am
On the wikipeadia they talk about successfully using a network of a computers (2600 for 17 months) to recover a moderately sized key. Ouch!
That was almost 10 years ago (2004). Perhaps with up-to date computers and with joint efforts from forum members we could recover some keys?
The idea is like searching for bitcoins. Every EEV user could download small piece of software, pick a range of input keys and let the computer do the magic for a few hours/days/months. ;)
Or could it be more efficient to use some microprocessors alike atmel or PIC to do the hard work?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 17, 2013, 11:40:26 am
yes, at the moment thats a bit of a showstopper, to be honest, my mathfoo is not up to ECC (and never will be ;-).
but what they do is take the serial in  <DSA2format>+2nd,10th,18th,26th Char of the license string (e.g. DSA9 = option enable keyword) and build a SHA1 hash out of it. thats the secret message if u will.
that message is then signed using a private key (unknown to us) - and the resulting public key is the license key - from the looks of it the public key is 56bits long.

so without bruteforcing the private key (56bits, not in my lifetime probably ;-) - the only way around this is that we install our own public keys in the GEL file and sign our own licensekeys - this leads to the nessecarity to be able to flash a custom GEL file. (e.g. find bootloader checksums blah) - if they also signed that .. then a software mod only is impossible, and it could only be done via jtag.

the main verification routing is a almost complete ripoff of https://github.com/CertiVox/MIRACL/blob/master/source/ecsver.c (https://github.com/CertiVox/MIRACL/blob/master/source/ecsver.c)
except instead of files, the static parts are values in the firmware - thats the hexnumber like looking strings.
i will post a small c file later on that replays what they do once i come around to rewrite it for the MIRACL library. (reversing that lib still was fun ;-)


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DL5TOR on July 17, 2013, 11:50:05 am

so without bruteforcing the private key (56bits, not in my lifetime probably ;-) - the only way around this is that we install our own public keys in the GEL file and sign our own licensekeys - this leads to the nessecarity to be able to flash a custom GEL file. (e.g. find bootloader checksums blah) - if they also signed that .. then a software mod only is impossible, and it could only be done via jtag.


at 100000 keys / sec that will be in the range of 2000 years
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: M. András on July 17, 2013, 05:36:53 pm
is there a way to download that buttload of files from github?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ve7xen on July 17, 2013, 05:48:00 pm
is there a way to download that buttload of files from github?
https://github.com/CertiVox/MIRACL -> Download ZIP

Or just git clone it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 18, 2013, 12:08:14 am
As promised here is an implementation of what Rigol does in C using MIRACL.
Except a few tiny bits (see code comments) its 100% what they do.

Should compile on any linux box - RTFM -> file header


Code: [Select]
/*
** C implementation of rigol ds2k ECC-112 license key check
** version 0.1
** cybernet, 2013 - <cn@warp.at>
**
**
** to compile this you need MIRACL from [url]https://github.com/CertiVox/MIRACL[/url]
** download the master.zip into a new folder and run 'unzip -j -aa -L master.zip'
** then run 'bash linux' to build the miracle.a library
**
** once done compile this c file with:
**
** gcc main.c -I../MIRACL ../MIRACL/miracl.a -o riglol
**
** adapt -I and path to miracl.a to your environment
**
** RUN:
**
** ./riglol ???????-???????-???????-??????? DSA2Aserial
**
** WHAT THIS IS:
**
** an implementation that matches rigols license key check
** except a few deviations which are not yet reversed fully.
**
** WHAT THIS IS NOT:
**
** a keygen, something for scriptkiddies to ask questions about - RTFM instead
**
**
** more info: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/
**       http://certivox.org/pages/viewpage.action?pageId=7635202
**
**
*/

#include <stdio.h>
#include "miracl.h"
#include <stdlib.h>
#include <string.h>

// primes, ecurve parameters, points from FW v.00.01.00.05 - probably always the same anyhow
unsigned char prime1[]="AEBF94CEE3E707";
unsigned char prime2[]="AEBF94D5C6AA71";
unsigned char curve_a[]="2982";
unsigned char curve_b[]="3408";
unsigned char point1[]="7A3E808599A525";
unsigned char point2[]="8445B2BE29E5C7";

// which chars to skip for option key
char skip_chars[] = { 2, 10, 18, 26 };

// some helper maps to convert key to hex
char map_ee00d0[]={ 0x0, 0x0, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f,
                    0x0, 0x0, 0x0,  0x0,  0x0,  0x0,  0x0,  0x0,  0x1,  0x2,
                    0x3, 0x4, 0x5,  0x6,  0x7,  0x0,  0x8,  0x9,  0xa,  0xb,
                    0xc, 0x0, 0xd,  0xe,  0xf,  0x10, 0x11, 0x12, 0x13, 0x14,
                    0x15,0x16, 0x17 };

char map_20688[]={ 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30,  /* 0-9 = 0x30 */
                   0x37, 0x37, 0x37, 0x37, 0x37, 0x37 };                        /* A-F = 0x37 */

void show_help(void)
{
 printf("\n");
 printf("./riglol <licensekey> <serial>\n\n");
 printf("<licensekey> can be given with or without dashes\n");
 printf("<serial> DSA2...\n");
 printf("\n");
 exit(-1);
}

/*
** convert string to uppercase chars
*/
char *strtoupper(char *str)
{
    char *newstr, *p;
    p = newstr = (char*) strdup((char*)str);
    while((*p++=toupper(*p)));
    return newstr;
}

/*
** skip dashes in input string
*/
char *lic_skip_dash(char *str)
{
 char *out, *c;
 char i=0;

 out=calloc(strlen(str)+1,1);
 if (!out) return(NULL);

 c=str;
 i=0;
 while (*c)
 {
   if (*c != '-')
    out[i++]=*c++;
   else *c++;
 }
 // printf("out: %s\n", out);
 return(out);
}


/*
** return string with skipped 2nd,10th,18th,26th character
*/
char *lic_make_skipped_str(char * lic_raw)
{
 char *c;
 char i,j,k;
 char *lic_skipped;

 if (!lic_raw) return(NULL);
 lic_skipped=calloc(strlen((char*)lic_raw)+1-sizeof(skip_chars), 1);
 if (!lic_skipped) return(NULL);

 c=lic_raw;
 i=j=k=0;
 while (*c)
 {
   j++;
   if (skip_chars[i] == j)
    i++;
   else lic_skipped[k++]=*c;

   c++;
 }
 return(lic_skipped);
}

/*
** return string of the skipped 2nd,10th,18th,26th character
*/
char *lic_make_skipped_chars(char * lic_raw)
{
 char *c;
 char i,j,k;
 char *lic_skipped;

 if (!lic_raw) return(NULL);
 lic_skipped=calloc(sizeof(skip_chars)+1, 1);
 if (!lic_skipped) return(NULL);

 c=lic_raw;
 i=j=k=0;
 while (*c)
 {
   j++;
   if (skip_chars[i] == j)
   {
    lic_skipped[k++]=*c;
    i++;
   }
   c++;
 }
 return(lic_skipped);
}

/*
** conver to hex
*/
char char_to_hex(char i)
{
 if ((i >= 'A') && (i <= 'F')) return(i-0x37);
 if ((i >= '0') && (i <= '9')) return(i-0x30);
 return(0x0);
}

/*
** map the skipped license string into hex bytes
**
*/
char *lic_code_map(char *lic_skipped)
{
 char lv1,lv2;
 char b1_mapped, b1_shifted, b1_remapped;
 char b2_mapped, b2_shifted, b2_remapped;
 char b3_mapped, b3_shifted, b3_remapped;
 char b4_mapped, b4_shifted, b4_remapped;
 char b5_shifted, b5_remapped;
 char *lic_skipped_mapbytes;
 unsigned int c=0;
 lic_skipped_mapbytes=calloc(255, 1);
 if (!lic_skipped_mapbytes) return(0);

 lv1=lv2=0;
 while(lv1 < strlen((char*)lic_skipped))
 {
    b1_mapped =  map_ee00d0[ *(lic_skipped+lv1) - 0x30 ];
    b1_shifted = (b1_mapped / 2) & 0xf;
    b1_remapped = b1_shifted + map_20688[b1_shifted];
    lic_skipped_mapbytes[lv2++]=b1_remapped;
    b1_mapped = b1_mapped & 0x1;

    b2_mapped =  map_ee00d0[ *(lic_skipped+lv1+1) - 0x30 ];
    b2_shifted =  ((b1_mapped << 0x3) | (b2_mapped / 4)) & 0xF;
    b2_remapped = b2_shifted + map_20688[b2_shifted];
    lic_skipped_mapbytes[lv2++]=b2_remapped;

    b3_mapped = map_ee00d0[ *(lic_skipped+lv1+2) - 0x30 ];
    b3_shifted = ((b3_mapped / 8) | ( (b2_mapped & 0x3) << 2 )) & 0xF;
    b3_remapped = b3_shifted + map_20688[b3_shifted];
    lic_skipped_mapbytes[lv2++]=b3_remapped;

    b4_mapped = map_ee00d0[ *(lic_skipped+lv1+3) - 0x30 ];
    b4_shifted = ((b4_mapped / 16 ) |((b3_mapped & 0x7) << 0x1)) & 0xf;
    b4_remapped = b4_shifted + map_20688[b4_shifted];
    lic_skipped_mapbytes[lv2++]=b4_remapped;
    b5_shifted = b4_mapped & 0xF;
    b5_remapped = b5_shifted + map_20688[b5_shifted];
    lic_skipped_mapbytes[lv2++]=b5_remapped;

    lv1 = lv1 + 4;
    c=c+5;
  }
  lic_skipped_mapbytes[c-1]=0;
  return(lic_skipped_mapbytes);
}

/*
** MAIN
*/
int main(int argc, char *argv[0])
{
  miracl *mip;
  big    p1,p2; // primes
  big    c1,c2; // curve parameters (A,B)
  big    tmp; // generic temp bigvar
  big    lic1,lic2; // the two parts of our license key
  epoint *pt1,*pt2; // points on our curve
  sha sh;
  big sha_hash; // sha1 hash of serial + lic_opt
  big    m1,m2; // output from mad() func
  big    v;
  big    g; // gxcd output
  char   *lic_raw,*serial; // cmdline input
  char   *lic_opt,*lic_skipped; // options as given per license key (2nd,10th,18th,26th char)
  char   *lic_opt_mapbytes; // options in hex format - denotes type of option and the bitflags for the options
  char   *lic_skipped_mapbytes; // input into the ECC routines
  char   *lic_hash; // serial + lic_opt string
  char   *lic_1_mapbytes; // split lic_map_bytes on character 0xe (mapped)
  char   *lic_2_mapbytes;  // second half
  int i1,i2;
  char   *p;

  // get our commandline input
  // and do some basic checks
  if (argc!=3) show_help();
  lic_raw=(char*)strtoupper((char*)argv[1]); // make it uppercase
  serial=(char*)strtoupper((char*)argv[2]);             // make it uppercase
  lic_raw=lic_skip_dash(lic_raw); // skip any dashes
  if (strlen(lic_raw)  < 0x1c) { fprintf(stderr, "license key is to short !\n"); exit(-1); }
  if (strlen(lic_raw) > 0x1c) { fprintf(stderr, "license key is to long !\n"); exit(-1); }
  if (strlen(serial) != 0xd) { fprintf(stderr, "serial has invalid length !\n"); exit(-1); }
  // generate the strings and map the license key to hex
  lic_skipped=lic_make_skipped_str(lic_raw); // licensekey minus 2nd,10th,18th,26th char
  lic_opt=lic_make_skipped_chars(lic_raw); // licensekey 2nd,10th,18th,26th char
  lic_skipped_mapbytes=lic_code_map(lic_skipped); // convert to base 16
  lic_opt_mapbytes=lic_code_map(lic_opt); // same for the desired options
  // split the lic_skipped_mapbytes
  lic_1_mapbytes=strdup(lic_skipped_mapbytes);
  i1=(char)(0x0e - char_to_hex(lic_skipped_mapbytes[0xe]));
  if ((0xe < i1) || (i1 < 0)) i1=0;
  lic_1_mapbytes[i1]=0;
  lic_2_mapbytes=strdup(lic_skipped_mapbytes);
  i2=(char)(0x1d-char_to_hex(lic_skipped_mapbytes[0x1d]));
  if ((0x1d < i2) || (i2 < 0)) i2=0xf;
  lic_2_mapbytes[i2]=0;           
  p=strdup(lic_2_mapbytes+0xf);
  lic_2_mapbytes=strdup(p);
  lic_hash=calloc(strlen(serial)+strlen(lic_opt)+1,1);
  strcpy(lic_hash, serial);
  strcat(lic_hash, lic_opt);

  // our strings, inputs to the ECC/sha crypto part
  printf("\nserial:           %s\n", serial);
  printf("license-key:      %s\n", lic_raw);
  printf("license-skipped:  %s (%s)\n", lic_skipped, lic_skipped_mapbytes);
  printf("license-1-mapped: %s\n", lic_1_mapbytes);
  printf("license-2-mapped: %s\n", lic_2_mapbytes);
  printf("license-options:  %s (%s)\n", lic_opt, lic_opt_mapbytes);
  printf("serial&options:   %s\n", lic_hash);
 
  // initialize MIRACL
  mip=mirsys(0x320,0x10); // 800 bit precison, 16=hexmode
  // initialize "big" variables used by MIRACL
  tmp=mirvar(0);
  p1=mirvar(0);
  p2=mirvar(0);
  c1=mirvar(0);
  c2=mirvar(0);
  lic1=mirvar(0);
  lic2=mirvar(0);
  sha_hash=mirvar(0);
  m1=mirvar(0);
  m2=mirvar(0);
  v=mirvar(0);
  g=mirvar(0);
  // initalize the epoints used
  pt1=epoint_init();
  pt2=epoint_init();
  // setup static items like rigol (primes, the elliptic curve)
  instr(p1, prime1);
  instr(p2, prime2);
  instr(c1, curve_a);
  instr(c2, curve_b);
 
  // initialize ecurve and set the 2 points 
  ecurve_init(c1, c2, p1, MR_PROJECTIVE);
  instr(tmp, point1);
  if (!epoint_set(tmp, tmp, 0x0, pt1))
  {
  printf("ERR: '%s' not a point on the given curve\n", point1);
        exit(-1);
  }
  instr(tmp, point2);
  if (!epoint_set(tmp, tmp, 0x1, pt2))
  {
        printf("ERR: '%s' not a point on the given curve\n", point2);
        exit(-1);
  }
  /* 
  * at this point initialization of the ECC crypto system is completed
  ** this is done only once on a rigol per powerup cycle
  **
  ** now comes the part that is run for every key check
  */


  // generate the sha1 hash for the serial+option string
  shs_init(&sh);
  p=lic_hash;
  while(*p)
  {
    shs_process(&sh,*p);
    p++;
  }
  shs_hash(&sh, lic_hash);
  bytes_to_big(20, lic_hash, sha_hash);
  mip->IOBASE = 16;
  printf("sha1(serial&opts) "); cotnum(sha_hash, stdout); printf("\n");

  // convert our 2 halves of the mapped license key into big's
  instr(lic1, lic_1_mapbytes);
  instr(lic2, lic_2_mapbytes);

  // make sure lic1 and lic2 are not our p2 prime ? why ?
  if (mr_compare(lic1, p2) >= 0x0)
  {
  printf("ERR: lic1 compare\n");
  }
  if (mr_compare(lic2, p2) >= 0x0)
  {
        printf("ERR: lic2 compare\n");
  }
  // here should be two unimplemented/unknown test functions again testing lic1/lic2 - tbc.
  // they only seem to check a length nothing super important imho
  // i will add them once i match them to MIRACL
 

  // now the mathfoo starts ...
  xgcd(lic2, p2, lic2, lic2, lic2); // xgcd(x, p, x, x, x,); -> x = 1/x mod p (p is prime)
  copy(lic2,g); // copy output (lic2) to g for simplicity

  mad(sha_hash, g, g, p2, p2, m1); // multiply and add - mad(x, x, x, w, x, x); -> x = x^2 / w
  mad(lic1    , g, g, p2, p2, m2); // multiply and add - mad(x, x, x, w, x, x); -> x = x^2 / w
  ecurve_mult2(m1, pt1, m2, pt2, pt1); // multiply and add - ecurve_mult2(e,p,ea,pa,pt) -> pt== e (x) p + ea (x) pa

  // check if pt1 (output from ecurve_mult2) divided by the prime p2 matches lic1
  // this is actually done slightly differnt in the firmware, but i was unable to find a match in MIRACL so far
  // so i used the method from the ecsver.c example
  epoint_get(pt1,v,v); // epoint_get(p, x, y); // extract x coordinate and lsb of y
  divide(v,p2,p2); // quotient and remainder - divide(x,y,z) ->  x = x (mod y)

  // now we compare v to the first part of our license key (lic1)
  // to give some idea of how the ECC-112 output changes with input print the compared value
  printf("v:    "); cotnum(v, stdout);
  printf("lic1: "); cotnum(lic1, stdout); printf("\n");
 
  if (mr_compare(v, lic1)==0)
  {
  printf(" License Key is VALID\n");
  }
  else
  {
printf(" INVALID License Key\n");
  }
  printf("\n\n");
  exit(0);
}
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on July 18, 2013, 12:23:33 am
Great work cybernet. Runs fine but don't have anything to test =) Thanks for commenting as well.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 18, 2013, 12:30:04 am
maybe someone agrees to post a trial key, the ones that i've gotten i can not post because i promised to keep em private.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 18, 2013, 12:34:48 am
Great work cybernet. Runs fine but don't have anything to test =) Thanks for commenting as well.

well u could try to find a match for your serial - lottery at its best ..  :-DD
just use DSAH for the 2nd,10th,18th,26th char ;-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zibadun on July 18, 2013, 01:43:12 am
as a script kiddie it's my duty to report that cybernet's code works perfectly with my trial key

$ ./riglol RVEblah-blah-blah-blah DS2Afoo

...
license-options:  VSA9 (9C01)
serial&options:   DS2AfooVSA9
sha1(serial&opts) 6AE0077305B7953919FF39181418828E5CA517C4

v:    7BBCFEBAF16BEA
lic1: 7BBCFEBAF16BEA

 License Key is VALID

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DL5TOR on July 18, 2013, 08:33:44 am
at 100000 keys / sec that will be in the range of 2000 years

It's feasible on modern GPUs, in the range of months. The problem is you need a custom implementation in something like OpenCL.

so we have the soruce of the crypto we know how it is used and we have the Hardware to do it. All we need then is someone who can write the program and the CPU/GPU time.

Who is willing to do this??


thanx to all
DL5TOR
Torsten
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: orbiter on July 18, 2013, 09:20:08 am
I'm in..  Just get me a program and it'll give my two GTX295's something to munch on :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: kizzap on July 18, 2013, 01:35:42 pm
The bitcoin guys are getting into ASIC territory for mining. I wonder if something like that could be used for this....

-kizzap
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zibadun on July 18, 2013, 01:58:22 pm
The bitcoin guys are getting into ASIC territory for mining. I wonder if something like that could be used for this....

-kizzap

if my math is right for a 56 bit key we would need aggregate performance of ~10 Gkeys/sec to solve this in a couple of months.  BTW ATI GPUs were much faster than a comparable price NVIDIA for generating bitcoins. or here is another comparison from a known "security" company http://www.elcomsoft.com/news/545.html (http://www.elcomsoft.com/news/545.html).  (I'll donate Radeon HD 5700 time:)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DL5TOR on July 18, 2013, 02:17:24 pm
The bitcoin guys are getting into ASIC territory for mining. I wonder if something like that could be used for this....

-kizzap

if my math is right for a 56 bit key we would need aggregate performance of ~10 Gkeys/sec to solve this in a couple of months.  BTW ATI GPUs were much faster than a comparable price NVIDIA for generating bitcoins. or here is another comparison from a known "security" company http://www.elcomsoft.com/news/545.html (http://www.elcomsoft.com/news/545.html).  (I'll donate Radeon HD 5700 time:)

with 10 GKeys/sec that will be 83,4 days. The math is simple

56 bit = 2^56 posibilts = 72057594037927936

then
72057594037927936 / 10.000.000.000= 7205759,4s = 120095 min = 2001,6h = 83,4 Days


this is max time so in reality it will not be that Long

73
 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: darrylp on July 18, 2013, 02:25:13 pm
Per serial number of each ds2xx2 don't forget !


--
 Darryl

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 18, 2013, 02:46:19 pm
given my lacking math skills - i think what we *would' need to crack is the two prime numbers p1,p2 - which means its a 112 Bit problem.
these prime numbers are the public key, which when cracked lead to the private key - having the private key means we can sign whatever message (serial+opt) we want.

and 112bits of ECC is unbroken as of now (at least i read that somewhere recently).

so we should focus on checking the bootloader + its firmware verification .. hash, crc, whatever - then simply replace the two primes with a public/private key of our own, and flash the GEL file - once done, you can sign your own license keys and voila.

just skipping the checks might prove difficult, because they could get very creative where they do such checks, and it would be hard to find for a new FW version.
compromising the public key (primes) is much easier, and much harder for them to get rid of - unless they start to move the whole ECC framework into the FGPA, because then its game over ;-)

btw - i wonder if they paid for the commercial license of MIRACL ;-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: CodyShaw on July 18, 2013, 03:08:05 pm
given my lacking math skills - i think what we *would' need to crack is the two prime numbers p1,p2 - which means its a 112 Bit problem.
these prime numbers are the public key, which when cracked lead to the private key - having the private key means we can sign whatever message (serial+opt) we want.

and 112bits of ECC is unbroken as of now (at least i read that somewhere recently).

so we should focus on checking the bootloader + its firmware verification .. hash, crc, whatever - then simply replace the two primes with a public/private key of our own, and flash the GEL file - once done, you can sign your own license keys and voila.

just skipping the checks might prove difficult, because they could get very creative where they do such checks, and it would be hard to find for a new FW version.
compromising the public key (primes) is much easier, and much harder for them to get rid of - unless they start to move the whole ECC framework into the FGPA, because then its game over ;-)

btw - i wonder if they paid for the commercial license of MIRACL ;-)

"How to beat encryption:

Screw brute forcing the prime numbers, just hack the damn thing and change them to 5!"
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 18, 2013, 03:13:01 pm
just skipping the checks might prove difficult, because they could get very creative where they do such checks, and it would be hard to find for a new FW version.

Is the license key stored?  Is it validated at startup each and every time or only at the time of entry?  Some may have theorized that the key is stored because a trial extension can't be used multiple times, but there could be an internal counter that tracks how many trial extensions have been issued and only allows so many.

If the key is NOT stored, then it is potentially enter key -> validate as good -> set license mode and features permanently someplace

If this is the case, then a simple opcode modification at the point where it decides if the key is valid or invalid will allow entering a key like this:

xDxxxxx-xxSxxxx-xxxAxxx-xxxxZxx

No matter what the x values or S/N are it would accept the key and enable the features and license mode.

Then you could go to a factory firmware version and no longer be able to enter such a key, but have all features enabled in official license key mode...

i think (didnt look carefully) the option key e.g. 1C0XX or 9C0XX is checked everytime a licensed feature is requested (e.g. menu pops up).
i asked some ppl to check for the encoded option key in the FRAM, but its not there i guess. so probably they store the outcome of the ecurve operations, and then compare it - somebody with FRAM access could check that. because *that* could easily be faked, written to FRAM and will be permanent.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: docmandu on July 18, 2013, 06:15:34 pm
I wonder if Rigol learned from Sony's mistake :-)

http://www.thedistractionnetwork.com/sonys-ecdsa-code/ (http://www.thedistractionnetwork.com/sonys-ecdsa-code/)


Anyway, nice work on the reversing.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 18, 2013, 06:18:31 pm
I wonder if Rigol learned from Sony's mistake :-)

http://www.thedistractionnetwork.com/sonys-ecdsa-code/ (http://www.thedistractionnetwork.com/sonys-ecdsa-code/)


Anyway, nice work on the reversing.

that was about  the first thing i tried, but the private/pub key pair was done on a pc and MIRACL is having a proper RNG ;-) (9 digit seed ... then generating an 800 bit number ..)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: docmandu on July 18, 2013, 09:30:16 pm
Does it? Only had a very quick look at it. It seemed to be using a pseudo number generator, albeit seeded with a 9 digit number in the example code from MIRACL.
Anyway if they used a proper one, then the only options are a buffer overrun somewhere or directly patching the firmware.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 18, 2013, 09:46:36 pm
These are the FW 5 addresses of the MIRACL functions for those who work with JTAG.

Code: [Select]
MIRACL_convert_sub_1FB2E8         ROM 001FB2E8 00000048 R . . . . . .
MIRACL_copy_sub_1FBA4C            ROM 001FBA4C 0000008A R . . . . . .
MIRACL_decr_sub_1F91EE            ROM 001F91EE 0000004A R . . . . . .
MIRACL_divide_sub_1FA2CA          ROM 001FA2CA 00000890 R . . . . . .
MIRACL_ecp_memalloc_1FC2F8        ROM 001FC2F8 00000082 R . . . . . .
MIRACL_ecp_memkill_sub_1FC37A     ROM 001FC37A 0000008A R . . . . . .
MIRACL_ecurve_add_sub_1FD184      ROM 001FD184 0000008E R . . . . . .
MIRACL_ecurve_add_sub_1FD542      ROM 001FD542 000001F2 R . . . . . .
MIRACL_ecurve_double_sub_1FC8B0   ROM 001FC8B0 000004A2 R . . . . . .
MIRACL_ecurve_mult2_sub_1FD734    ROM 001FD734 00000266 R . . . . . .
MIRACL_ecurve_mult_1FD2C6         ROM 001FD2C6 0000027C R . . . . . .
MIRACL_ecurve_padd_sub_1FCD52     ROM 001FCD52 000003E6 R . . . . . .
MIRACL_ecurve_sub_sub_1FD25E      ROM 001FD25E 00000068 R . . . . . .
MIRACL_epoint_copy_sub_1FD138     ROM 001FD138 0000004C R . . . . . .
MIRACL_epoint_init_mem_sub_1FC2C6 ROM 001FC2C6 00000032 R . . . . . .
MIRACL_epoint_negate_sub_1FD212   ROM 001FD212 0000004C R . . . . . .
MIRACL_epoint_norm_sub_1FC5F2     ROM 001FC5F2 000000E4 R . . . . . .
MIRACL_epoint_set_sub_1FC4DE      ROM 001FC4DE 00000114 R . . . . . .
MIRACL_exsign_sub_1FAF32          ROM 001FAF32 00000020 R . . . . . .
MIRACL_insign_sub_1FAF08          ROM 001FAF08 0000002A R . . . . . .
MIRACL_jack_sub_1FDF84            ROM 001FDF84 000001BA R . . . . . .
MIRACL_logb2_sub_1FAC04           ROM 001FAC04 0000006A R . . . . . .
MIRACL_mad_sub_1FAB5A             ROM 001FAB5A 000000A8 R . . . . . .
MIRACL_memkill_sub_1FB8C0         ROM 001FB8C0 00000042 R . . . . . .
MIRACL_mirsys_sub_1FB892          ROM 001FB892 0000002E R . . . . . .
MIRACL_mirsys_sub_1FEE10          ROM 001FEE10 00000168 R . . . . . .
MIRACL_mirvar_mem_sub_1FB3B8      ROM 001FB3B8 00000032 R . . . . . .
MIRACL_mirvar_sub_1FB330          ROM 001FB330 00000088 R . . . . . .
MIRACL_mr_addbit_sub_1FBF66       ROM 001FBF66 0000006E R . . . . . .
MIRACL_mr_berror_sub_1FB0F4       ROM 001FB0F4 00000024 R . . . . . .
MIRACL_mr_compare_sub_1FACD4      ROM 001FACD4 000000B0 R . . . . . .
MIRACL_mr_jsf_sub_1F99B8          ROM 001F99B8 0000021E R . . . . . .
MIRACL_mr_notint_sub_1FADEE       ROM 001FADEE 00000028 R . . . . . .
MIRACL_mr_padd_sub_1F8C60         ROM 001F8C60 00000240 R . . . . . .
MIRACL_mr_pmul_sub_1F9238         ROM 001F9238 000001F0 R . . . . . .
MIRACL_mr_psub_sub_1F8EA0         ROM 001F8EA0 00000138 R . . . . . .
MIRACL_mr_sdiv_sub_1F94A2         ROM 001F94A2 0000017A R . . . . . .
MIRACL_mr_select_sub_1F8FD8       ROM 001F8FD8 0000016C R . . . . . .
MIRACL_mr_select_sub_1F9174       ROM 001F9174 00000030 R . . . . . .
MIRACL_mr_testbit_sub_1FAC6E      ROM 001FAC6E 00000066 R . . . . . .
MIRACL_multiply_sub_1F9C7E        ROM 001F9C7E 0000064C R . . . . . .
MIRACL_negify_sub_1FBAD6          ROM 001FBAD6 00000020 R . . . . . .
MIRACL_normalise_sub_1F9BD8       ROM 001F9BD8 000000A6 R . . . . . .
MIRACL_nres_lucas_1FE140          ROM 001FE140 000001E8 R . . . . . .
MIRACL_nres_moddiv_sub_1FEBCE     ROM 001FEBCE 0000008E R . . . . . .
MIRACL_nres_modmult_sub_1FEB28    ROM 001FEB28 000000A6 R . . . . . .
MIRACL_nres_modsub_sub_1FE97E     ROM 001FE97E 00000054 R . . . . . .
MIRACL_nres_negate_sub_1FE890     ROM 001FE890 0000003E R . . . . . .
MIRACL_nres_premult_sub_1FE9D2    ROM 001FE9D2 00000156 R . . . . . .
MIRACL_nres_sqroot_sub_1FF354     ROM 001FF354 00000250 R . . . . . .
MIRACL_nres_sub_1FE328            ROM 001FE328 000000B2 R . . . . . .
MIRACL_redc_sub_1FE584            ROM 001FE584 0000030C R . . . . . .
MIRACL_remain_sub_1F9786          ROM 001F9786 000000AE R . . . . . .
MIRACL_sha1_sub_1FFFA6            ROM 001FFFA6 000000A2 R . . . . . .
MIRACL_size_sub_1FAD84            ROM 001FAD84 0000006A R . . . . . .
MIRACL_subdiv_sub_1F961C          ROM 001F961C 0000016A R . . . . . .
MIRACL_xgcd_caller_sub_1FFF2A     ROM 001FFF2A 0000001A R . . . . . .
MIRACL_xgcd_sub_1FF790            ROM 001FF790 0000079A R . . . . . .
MIRACL_zero_sub_1FB222            ROM 001FB222 0000003E R . . . . . .

the magic happens in

LIC_HUGE_sub_200048 ROM 00200048 0000031A R . . . . . .

which is basically the riglol.c

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 18, 2013, 09:51:57 pm
Other stuff, with questionable naming from my side .. so rely on that with caution.

Code: [Select]
BOOTLDR_MAIN_?_sub_1FD1632                           ROM    01FD1632 00000096 R . . . . . .
BOOTLDR_send_SPORT_sub_1FD2C2C                       ROM    01FD2C2C 0000002C R . . . . . .
BOOTLDR_sub_1FD107A                                  ROM    01FD107A 000000EE R . . . . . .
BOOTLDR_sub_1FD150E                                  ROM    01FD150E 00000078 R . . . . . .
BOOTLDR_sub_1FD2C58                                  ROM    01FD2C58 000000A4 R . . . . . .
BOOT_sub_20B3A                                       ROM    00020B3A 00000370 R . . . . . .
CALLOC_0x258_Bytes_sub_1F8BE8                        ROM    001F8BE8 00000014 R . . . . . .
CALLOC_unknown_libname_74                            ROM    0020F3C8 00000014 R . L . . . .
CALL_deref_EE0828_sub_20FD54                         ROM    0020FD54 00000026 R . . . . . .
CALL_faa0b3c0_sub_E408                               ROM    0000E408 00000018 R . . . . . .
CAPTURE_FOREVER_sub_FFA045EC                         seg010 FFA045EC 00000006 R . . . . . .
CFG_Save_?_sub_E7D0E                                 ROM    000E7D0E 000003D0 R . . . . . .
CHIP_ID_sub_FFA00D70                                 seg010 FFA00D70 000000C4 R . . . . . .
CODE_MapBytes_sub_206CBE                             ROM    00206CBE 000001D2 R . . . . . .
DATETIME_get_sub_18BA90                              ROM    0018BA90 00000058 R . . . . . .
DISASM_?_sub_13EA92                                  ROM    0013EA92 00000072 R . . . . . .
DISPLAY_UPDATE_?_sub_14875C                          ROM    0014875C 00000276 R . . . . . .
DIS_TWI_XMIT_sub_E090                                ROM    0000E090 0000011E R . . . . . .
DS2000Update_GEL_sub_1FD5F24                         ROM    01FD5F24 000001FC R . . . . . .
Disable_EA041C_sub_DEA48                             ROM    000DEA48 00000016 R . . . . . .
EBIU_sub_1E89F0                                      ROM    001E89F0 0000003C R . . . . . .
Enable_EA041C_sub_DEA5E                              ROM    000DEA5E 00000016 R . . . . . .
FPGA_GetVersion_sub_8A94                             ROM    00008A94 00000018 R . . . . . .
GET_0xEA8EE0_sub_11E7FC                              ROM    0011E7FC 00000014 R . . . . . .
GET_0xEA94B4_sub_139A8A                              ROM    00139A8A 00000014 R . . . . . .
HWSETUP_sub_1E8A2C                                   ROM    001E8A2C 000000A8 R . . . . . .
HWSETUP_sub_1E939A                                   ROM    001E939A 00000010 R . . . . . .
KEYBOARD_POLL_sub_1A7C5A                             ROM    001A7C5A 000000E6 R . . . . . .
KEYBOARD_onPress_sub_1E1B8C                          ROM    001E1B8C 00000048 R . . . . . .
KEYBOARD_sub_1A7B8E                                  ROM    001A7B8E 0000008C R . . . . . .
KEYMAP_?_sub_1D4860                                  ROM    001D4860 000000DE R . . . . . .
KEYMAP_JT_sub_1E45A8                                 ROM    001E45A8 00000128 R . . . . . .
KEYMAP_sub_1E46D0                                    ROM    001E46D0 000000C4 R . . . . . .
KEYPRESS_?_sub_11555E                                ROM    0011555E 00000B00 R . . . . . .
LICENSE_DECODE_Main_sub_1FDEE8                       ROM    001FDEE8 0000009A R . . . . . .
LIC_ALLOC_StrBuffers_sub_1858B2A                     ROM    01858B2A 00000166 R . . . . . .
LIC_ALLOC_StrBuffers_sub_59A2A                       ROM    00059A2A 00000166 R . . . . . .
LIC_ALLOC_calc_sub_1FAF52                            ROM    001FAF52 0000006C R . . . . . .
LIC_ALLOC_struct_sub_1FC14E                          ROM    001FC14E 00000088 R . . . . . .
LIC_AddFuncPtrMain_sub_1A6B82                        ROM    001A6B82 00000118 R . . . . . .
LIC_AddFunctionPtr_sub_5A7BE                         ROM    0005A7BE 00000088 R . . . . . .
LIC_CALLOC_?_sub_1FB3EA                              ROM    001FB3EA 00000040 R . . . . . .
LIC_CALLOC_?_sub_205D78                              ROM    00205D78 0000002A R . . . . . .
LIC_CALLOC_sub_20628A                                ROM    0020628A 0000007A R . . . . . .
LIC_CALLOC_verify_sub_1F8BFC                         ROM    001F8BFC 0000004E R . . . . . .
LIC_CODE_CreateStrings_sub_2070A4                    ROM    002070A4 000000B8 R . . . . . .
LIC_CODE_MapKeyBytesAgain_sub_20688E                 ROM    0020688E 00000036 R . . . . . .
LIC_CODE_StringToHex_sub_206846                      ROM    00206846 00000048 R . . . . . .
LIC_CODE_write_0x19e517e_sub_206FD0                  ROM    00206FD0 00000048 R . . . . . .
LIC_CODE_write_0x19e5183_sub_20715C                  ROM    0020715C 00000060 R . . . . . .
LIC_CODE_write_0x19e519b_sub_207018                  ROM    00207018 0000008C R . . . . . .
LIC_CalledEverySec_sub_1A7640                        ROM    001A7640 0000043C R . . . . . .
LIC_CheckSerialUsed_helper_sub_206A16                ROM    00206A16 0000003C R . . . . . .
LIC_CheckSerialUsed_helper_sub_20A650                ROM    0020A650 0000008C R . . . . . .
LIC_CheckSerialUsed_sub_204060                       ROM    00204060 00000036 R . . . . . .
LIC_Chunk_Copy_sub_59890                             ROM    00059890 00000056 R . . . . . .
LIC_Chunk_Input_sub_5A456                            ROM    0005A456 0000008C R . . . . . .
LIC_Chunk_addChar_sub_5A364                          ROM    0005A364 000000F2 R . . . . . .
LIC_ChunksCopy_sub_134A62                            ROM    00134A62 00000116 R . . . . . .
LIC_ChunksCopy_sub_1858990                           ROM    01858990 00000056 R . . . . . .
LIC_CryptedAccess_?_sub_200362                       ROM    00200362 0000011E R . . . . . .
LIC_DECODE_?_sub_1FDD9C                              ROM    001FDD9C 0000014C R . . . . . .
LIC_DECODE_?_sub_2063DA                              ROM    002063DA 00000024 R . . . . . .
LIC_DECODE_CALC_sub_1FAFD8                           ROM    001FAFD8 000000EE R . . . . . .
LIC_DECODE_CallSubs_?_sub_2040F4                     ROM    002040F4 00000070 R . . . . . .
LIC_DECODE_WORKER_sub_1FD99C                         ROM    001FD99C 00000400 R . . . . . .
LIC_DECODE_slashonly_sub_1FBC3A                      ROM    001FBC3A 0000015A R . . . . . .
LIC_DECODE_sub_1FBD94                                ROM    001FBD94 000000FE R . . . . . .
LIC_DECODE_sub_1FBE92                                ROM    001FBE92 000000D4 R . . . . . .
LIC_DECODE_sub_203F86                                ROM    00203F86 00000026 R . . . . . .
LIC_Decode_?_sub_204440                              ROM    00204440 0000013C R . . . . . .
LIC_Decode_?_sub_204958                              ROM    00204958 000000EC R . . . . . .
LIC_DerefPTR_0x19E4AA0_sub_20617E                    ROM    0020617E 0000001E R . . . . . .
LIC_DerefPTR_0x19E4AB0_sub_20606E                    ROM    0020606E 0000001E R . . . . . .
LIC_DerefPTR_0x19E4ABC_sub_205FC8                    ROM    00205FC8 0000001E R . . . . . .
LIC_DerefPTR_0x19E4AC8_sub_205EFC                    ROM    00205EFC 0000001E R . . . . . .
LIC_DerefPTR_0x19E4AE8_sub_205F40                    ROM    00205F40 0000001E R . . . . . .
LIC_DerefPTR_0x19E4B68_sub_2053EE                    ROM    002053EE 0000001E R . . . . . .
LIC_DerefPTR_0x19E4B7C_sub_2053AA                    ROM    002053AA 0000001E R . . . . . .
LIC_Encode_Create_Strings_sub_206F0E                 ROM    00206F0E 000000C2 R . . . . . .
LIC_EvalKey_?_sub_59B90                              ROM    00059B90 00000320 R . . . . . .
LIC_GetCODEString_?_sub_1FFF44                       ROM    001FFF44 00000062 R . . . . . .
LIC_GetKeyLenSub_0x28_sub_205F84                     ROM    00205F84 0000001E R . . . . . .
LIC_GetKeyLenSub_0x4_sub_2061C2                      ROM    002061C2 0000001E R . . . . . .
LIC_HUGE_sub_200048                                  ROM    00200048 0000031A R . . . . . .
LIC_INIT_sub_1FC404                                  ROM    001FC404 000000DA R . . . . . .
LIC_INIT_sub_1FE3DA                                  ROM    001FE3DA 000001AA R . . . . . .
LIC_INIT_sub_1FE932                                  ROM    001FE932 0000004C R . . . . . .
LIC_Input_?_sub_1483D4                               ROM    001483D4 000000AA R . . . . . .
LIC_Input_JumpChunkBlocks_sub_18589E6                ROM    018589E6 00000048 R . . . . . .
LIC_KeyCheckMaxLen_sub_20400E                        ROM    0020400E 00000026 R . . . . . .
LIC_MAGICKey_Check_sub_5A152                         ROM    0005A152 000001EA R . . . . . .
LIC_MAGICKey_Check_sub_5A33C                         ROM    0005A33C 00000028 R . . . . . .
LIC_MATH_Test_lic_ptr_sub_1FB902                     ROM    001FB902 0000004A R . . . . . .
LIC_MATH_codebytes_sub_1FAE16                        ROM    001FAE16 00000096 R . . . . . .
LIC_MATH_shift_sub_1FB0C6                            ROM    001FB0C6 0000002E R . . . . . .
LIC_MATH_sub_FFA05526                                seg010 FFA05526 00000132 R . . . . . .
LIC_MATH_upd_codebytes_len_sub_1FAEAC                ROM    001FAEAC 0000005C R . . . . . .
LIC_MATH_upd_codebytes_sub_1FB94C                    ROM    001FB94C 00000100 R . . . . . .
LIC_MagicKeyProcessor_sub_2064B8                     ROM    002064B8 00000010 R . . . . . .
LIC_MagicKey_Process4bytes_sub_206E90                ROM    00206E90 0000007E R . . . . . .
LIC_OPT_Test_?_sub_205058                            ROM    00205058 0000004A R . . . . . .
LIC_ProcessKey_sub_20439A                            ROM    0020439A 000000A6 R . . . . . .
LIC_SERIAL_2ndPassScamble_sub_1FEFF0                 ROM    001FEFF0 00000246 R . . . . . .
LIC_Scamble_sub_1F7CB0                               ROM    001F7CB0 00000054 R . . . . . .
LIC_Scamble_sub_206A6E                               ROM    00206A6E 000000E8 R . . . . . .
LIC_SerialVerify_BuildCodeBytes_sub_1FF2A8           ROM    001FF2A8 000000AA R . . . . . .
LIC_SerialVerify_Clear80Bytes_WriteQwords_sub_1FEF78 ROM    001FEF78 00000078 R . . . . . .
LIC_SerialVerify_CollectCodeBytes_sub_1F9834         ROM    001F9834 00000184 R . . . . . .
LIC_SerialVerify_JT_Caller_sub_1F9144                ROM    001F9144 00000030 R . . . . . .
LIC_SerialVerify_JT_Caller_sub_1F91A4                ROM    001F91A4 0000004A R . . . . . .
LIC_SerialVerify_scramble_0x195f7f4_sub_1FF236       ROM    001FF236 00000072 R . . . . . .
LIC_SetupPtr4DECODE_sub_2042AE                       ROM    002042AE 000000EC R . . . . . .
LIC_SetupPtrs_?_sub_2064C8                           ROM    002064C8 0000011A R . . . . . .
LIC_VERIFY_sub_1FC1D6                                ROM    001FC1D6 000000F0 R . . . . . .
LIC_VERIFY_sub_1FE8CE                                ROM    001FE8CE 00000064 R . . . . . .
LIC_checkKeyLen_sub_20424C                           ROM    0020424C 00000062 R . . . . . .
LIC_check_sub_1FF5A4                                 ROM    001FF5A4 000001EC R . . . . . .
LIC_getChunkPtr_sub_18587BE                          ROM    018587BE 0000002A R . . . . . .
LIC_getChunktPtr_sub_596BE                           ROM    000596BE 0000002E R . . . . . .
LIC_getRandVal_R1_sub_5974E                          ROM    0005974E 00000014 R . . . . . .
LIC_get_0xEE0034_sub_1FB20E                          ROM    001FB20E 00000014 R . . . . . .
LIC_init_?_EE0034_sub_1FB42A                         ROM    001FB42A 00000468 R . . . . . .
LIC_shiftcodebytes_1FBAF6                            ROM    001FBAF6 00000144 R . . . . . .
LIC_struct_upd_?_sub_1FB260                          ROM    001FB260 00000088 R . . . . . .
LIC_sub_134A3A                                       ROM    00134A3A 00000028 R . . . . . .
LIC_sub_1859464                                      ROM    01859464 000000EE R . . . . . .
LIC_sub_18595E2                                      ROM    018595E2 000000DA R . . . . . .
LIC_sub_18596C0                                      ROM    018596C0 00000064 R . . . . . .
LIC_sub_1859724                                      ROM    01859724 0000009A R . . . . . .
LIC_sub_1D4478                                       ROM    001D4478 0000004A R . . . . . .
LIC_sub_1EF644                                       ROM    001EF644 0000004C R . . . . . .
LIC_sub_1F0F14                                       ROM    001F0F14 0000005C R . . . . . .
LIC_sub_1F0F94                                       ROM    001F0F94 00000032 R . . . . . .
LIC_sub_204096                                       ROM    00204096 0000005E R . . . . . .
LIC_sub_204C26                                       ROM    00204C26 0000008A R . . . . . .
LIC_sub_2051F8                                       ROM    002051F8 00000024 R . . . . . .
LIC_sub_20562E                                       ROM    0020562E 00000090 R . . . . . .
LIC_sub_206454                                       ROM    00206454 00000010 R . . . . . .
LIC_sub_597AC                                        ROM    000597AC 00000050 R . . . . . .
LIC_sub_5A4E2                                        ROM    0005A4E2 000000DE R . . . . . .
LIC_sub_5A5C0                                        ROM    0005A5C0 00000064 R . . . . . .
LIC_sub_5A624                                        ROM    0005A624 0000009E R . . . . . .
LIC_sub_5A6C2                                        ROM    0005A6C2 000000A0 R . . . . . .
LIC_sub_5A764                                        ROM    0005A764 0000005A R . . . . . .
LIC_verify_sub_1FC6D6                                ROM    001FC6D6 00000098 R . . . . . .
LIC_word_set_sub_203FAC                              ROM    00203FAC 00000062 R . . . . . .
LLIST_sub_125C9C                                     ROM    00125C9C 0000004E R . . . . . .
LLIST_sub_1475A4                                     ROM    001475A4 0000017C R . . . . . .
LOOP_?_sub_1EC826                                    ROM    001EC826 000002F8 R . . . . . .
MAIN_STARTUP_sub_FFA00000                            seg010 FFA00000 00000080 R . . . . . .
MEMCOPY_R1_to_R0_sub_FFA06B5C                        seg010 FFA06B5C 00000052 R . . . . . .
MEMCOPY_sub_F1E9C                                    ROM    000F1E9C 00000036 R . . . . . .
MEMDEPTH_sub_12609C                                  ROM    0012609C 0000032E R . . . . . .
MEMDEPTH_sub_128504                                  ROM    00128504 000000E0 R . . . . . .
MEMSET_sub_20F784                                    ROM    0020F784 0000005E R . . . . . .
MODEL_DSModelType_modify_?_sub_1D6BE2                ROM    001D6BE2 0000005E R . . . . . .
MODEL_MakeDSModelType_sub_9850A                      ROM    0009850A 00000042 R . . . . . .
MODEL_MakeDSXString_sub_F204E                        ROM    000F204E 00000056 R . . . . . .
MODEL_Make_sub_F273C                                 ROM    000F273C 000002CC R . . . . . .
MODEL_and_SERIAL_sub_9731C                           ROM    0009731C 0000005A R . . . . . .
MODEL_createModelTypeString_?_sub_F21BC              ROM    000F21BC 00000116 R . . . . . .
MODEL_getDSModelType_sub_F1DE2                       ROM    000F1DE2 00000014 R . . . . . .
MODEL_getStr_sub_18F0F4E                             ROM    018F0F4E 0000000E R . . . . . .
MODEL_getTypeID_sub_18F0EDE                          ROM    018F0EDE 00000014 R . . . . . .
MODEL_getTypeID_sub_18F0F84                          ROM    018F0F84 00000014 R . . . . . .
MODEL_getVendor_sub_18F0F72                          ROM    018F0F72 0000000E R . . . . . .
MODEL_makeDSModelType_sub_A9760                      ROM    000A9760 0000008C R . . . . . .
MODEL_retDS2XXX_sub_F1E4E                            ROM    000F1E4E 00000012 R . . . . . .
MODEL_setDSModelType_sub_F26DE                       ROM    000F26DE 0000005E R . . . . . .
MODEL_set_DSModel_Type_sub_F1E84                     ROM    000F1E84 00000018 R . . . . . .
MODEL_sub_19D5CDE                                    ROM    019D5CDE 0000005E R . . . . . .
NOTHING_sub_1CD18                                    ROM    0001CD18 0000000A R . . . . . .
OPTIONS_HUGE_JT_sub_193434A                          ROM    0193434A 00000436 R . . . . . .
OPTIONS_Installed_tst_OptionType_sub_135124          ROM    00135124 00000080 R . . . . . .
OPTIONS_ListInstalled_onKeyPress_sub_135C24          ROM    00135C24 0000007C R . . . . . .
OPTIONS_ListInstalled_sub_135098                     ROM    00135098 0000008C R . . . . . .
OPTIONS_ListInstalled_sub_135684                     ROM    00135684 000005A0 R . . . . . .
OPTIONS_ListInstalled_sub_1934194                    ROM    01934194 0000008C R . . . . . .
OPTIONS_ListInstalled_sub_1934780                    ROM    01934780 000005A0 R . . . . . .
OPTIONS_ListInstalled_sub_1934D20                    ROM    01934D20 0000007C R . . . . . .
OPTIONS_getJumpTableOffsetIDX_sub_599CA              ROM    000599CA 00000060 R . . . . . .
OPTION_Status_?_sub_F8618                            ROM    000F8618 00000014 R . . . . . .
OPT_Decode_?_sub_206464                              ROM    00206464 00000046 R . . . . . .
OPT_ModelType_sub_1D6A98                             ROM    001D6A98 0000014A R . . . . . .
OPT_get_R0_0x30_sub_20527C                           ROM    0020527C 0000001E R . . . . . .
OPT_sub_20573A                                       ROM    0020573A 0000001E R . . . . . .
OPT_sub_205A00                                       ROM    00205A00 00000048 R . . . . . .
Options_PrintMainType_?_sub_13524E                   ROM    0013524E 00000436 R . . . . . .
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 18, 2013, 09:52:29 pm
2nd part (20000 bytes is not enough ;-)

Code: [Select]
PLLDIV_sub_1B07FBC                                   ROM    01B07FBC 0000005A R . . . . . .
PLLDIV_sub_FFA001C8                                  seg010 FFA001C8 0000005A R . . . . . .
PRINT_ERR_sub_20CE14                                 ROM    0020CE14 00000054 R . . . . . .
PRINT_NoticePopup_sub_1375A4                         ROM    001375A4 0000015A R . . . . . .
PRINT_NoticePopup_sub_137894                         ROM    00137894 0000015A R . . . . . .
PRINT_Notice_sub_1376FE                              ROM    001376FE 00000130 R . . . . . .
PRINT_Notice_sub_1EF448                              ROM    001EF448 00000028 R . . . . . .
PRINT_TXT_sub_1EE642                                 ROM    001EE642 0000016E R . . . . . .
PRINT_sub_20CE68                                     ROM    0020CE68 00000054 R . . . . . .
PRINT_sub_20CEF8                                     ROM    0020CEF8 0000003A R . . . . . .
QUICKPRINT_sub_FCBCC                                 ROM    000FCBCC 00000298 R . . . . . .
R0_deref_E4E4BC_sub_F7DB0                            ROM    000F7DB0 00000014 R . . . . . .
R0_is_1_sub_20572C                                   ROM    0020572C 0000000E R . . . . . .
R0_is_ZERO_sub_21334                                 ROM    00021334 0000000C R . . . . . .
R0_is_ZERO_sub_F68B4                                 ROM    000F68B4 0000000C R . . . . . .
R0_is_ZERO_sub_FE59C                                 ROM    000FE59C 0000000C R . . . . . .
RANDOM_sub_1F9AE                                     ROM    0001F9AE 0000003C R . . . . . .
RAND_R0R1_sub_205712                                 ROM    00205712 0000001A R . . . . . .
RTS_sub_211E2C                                       ROM    00211E2C 00000002 R . . . . . .
SERIAL_?_sub_F2670                                   ROM    000F2670 0000006E R . . . . . .
SERIAL_Gen?_sub_A8B02                                ROM    000A8B02 00000062 R . . . . . .
SERIAL_Make?_sub_F1ED2                               ROM    000F1ED2 000000DC R . . . . . .
SERIAL_copytoR0_sub_F1FE4                            ROM    000F1FE4 00000020 R . . . . . .
SERIAL_getPtr_sub_F1E60                              ROM    000F1E60 00000012 R . . . . . .
SERIAL_setPtrtoGetSerialSub_sub_206632               ROM    00206632 00000028 R . . . . . .
SERIAL_sub_1A0625C                                   ROM    01A0625C 00000060 R . . . . . .
SPI_Enable_sub_980C                                  ROM    0000980C 0000001A R . . . . . .
SPI_Setup_?_sub_984A                                 ROM    0000984A 000000A4 R . . . . . .
SPI_XMIT_sub_97C6                                    ROM    000097C6 0000002C R . . . . . .
SPI_sub_1E986A                                       ROM    001E986A 000000B0 R . . . . . .
SPI_sub_97B0                                         ROM    000097B0 00000016 R . . . . . .
SPI_sub_97F2                                         ROM    000097F2 0000001A R . . . . . .
SPI_sub_98EE                                         ROM    000098EE 00000110 R . . . . . .
SPORT_Loop_sub_1EB1AE                                ROM    001EB1AE 000002DA R . . . . . .
SPORT_Setup_sub_1CBB0                                ROM    0001CBB0 0000013C R . . . . . .
SPORT_sub_1C57A                                      ROM    0001C57A 00000134 R . . . . . .
STAIR_sub_13EC34                                     ROM    0013EC34 000007F0 R . . . . . .
STAIR_sub_193DD30                                    ROM    0193DD30 000007F0 R . . . . . .
STRCAT_R1_to_R0_sub_20F9D4                           ROM    0020F9D4 00000032 R . . . . . .
STRCAT_sub_1A0EAD4                                   ROM    01A0EAD4 00000034 R . . . . . .
STRCMP_sub_20FA20                                    ROM    0020FA20 00000072 R . . . . . .
STRING_?_sub_20FB20                                  ROM    0020FB20 00000036 R . . . . . .
SoftBUTTON_R_SetCallbacks_sub_1A80BC                 ROM    001A80BC 000023E6 R . . . . . .
SoftButton_R_APPLY_sub_1D4556                        ROM    001D4556 00000056 R . . . . . .
SoftButton_R_BACKSPACE_sub_1D44C2                    ROM    001D44C2 0000004A R . . . . . .
SoftButton_R_CLEAR_sub_1D450C                        ROM    001D450C 0000004A R . . . . . .
SoftButton_Setup_sub_1D493E                          ROM    001D493E 0000004E R . . . . . .
TIMEDATE_GetStr_sub_20F30C                           ROM    0020F30C 00000064 R . . . . . .
TIMEDATE_GetString_unknown_libname_416               ROM    0020F3DC 00000012 R . L . . . .
TIMER0_PWM_Enable_sub_1FD0E4C                        ROM    01FD0E4C 0000007C R . . . . . .
TIMER0_sub_181E9AE                                   ROM    0181E9AE 000000B8 R . . . . . .
TIMER0_sub_1F8B2                                     ROM    0001F8B2 000000C4 R . . . . . .
TIMER_Setup_sub_181E94C                              ROM    0181E94C 00000056 R . . . . . .
TIMER_Setup_sub_1F85C                                ROM    0001F85C 00000056 R . . . . . .
TWI_RECV_sub_DEA8                                    ROM    0000DEA8 000000AA R . . . . . .
TWI_XMIT_R0_sub_1FC1E                                ROM    0001FC1E 00000018 R . . . . . .
TWI_XMIT_sub_D99A                                    ROM    0000D99A 00000064 R . . . . . .
TWI_XMIT_sub_DFBA                                    ROM    0000DFBA 00000084 R . . . . . .
TWI_sub_181EC72                                      ROM    0181EC72 0000009C R . . . . . .
TWI_sub_1FB14                                        ROM    0001FB14 0000006E R . . . . . .
TWI_sub_1FB82                                        ROM    0001FB82 0000009C R . . . . . .
TWI_sub_1FC36                                        ROM    0001FC36 0000001E R . . . . . .
TWI_sub_1FC54                                        ROM    0001FC54 0000001E R . . . . . .
TWI_sub_1FCB6                                        ROM    0001FCB6 00000018 R . . . . . .
TWI_sub_1FCCE                                        ROM    0001FCCE 00000026 R . . . . . .
TWI_sub_1FCF4                                        ROM    0001FCF4 00000026 R . . . . . .
TWI_sub_DBA0                                         ROM    0000DBA0 0000003E R . . . . . .
TWI_sub_DC04                                         ROM    0000DC04 000000D0 R . . . . . .
VERSION_Set_sub_192A74          ROM    00192A74 00000016 R . . . . . .
VER_MODEL_?_sub_21614           ROM    00021614 00000046 R . . . . . .
__Assert                        ROM    0020FCE8 00000040 R . L . . . .
__Assert_0                      ROM    01A0EDE8 00000040 R . L . . . .
__Getmem                        ROM    002106F8 00000020 R . L . . . .
__Getmem_0                      ROM    01A0F7F8 00000020 R . L . . . .
__Getmem_1                      ROM    01FE8C3C 00000020 R . L . . . .
__calloc_sub_FFA03314           seg010 FFA03314 0000008C R . . . . . .
__heap_calloc                   ROM    0020FD28 0000002C R . L . . . .
__heap_calloc_0                 ROM    01A0EE28 0000002A R . L . . . .
_div32__sub_FFA05338            seg010 FFA05338 00000082 R . . . . . .
_divrem_u32_sub_FFA054A8        seg010 FFA054A8 0000007E R . . . . . .
_localtime                      ROM    0020F5F0 00000016 R . L . . . .
_localtime_0                    ROM    01A0E6F0 00000016 R . L . . . .
_lshftli_sub_FFA06114           seg010 FFA06114 00000030 R . . . . . .
_mul64_sub_FFA061E4             seg010 FFA061E4 0000003C R . . . . . .
_rem_s32_sub_FFA066D8           seg010 FFA066D8 0000007A R . . . . . .
_remu32_sub_FFA067CC            seg010 FFA067CC 00000066 R . . . . . .
_strchr                         ROM    0020FA08 00000016 R . L . . . .
_strchr_0                       ROM    01A0EB08 00000016 R . L . . . .
_strchr_1                       ROM    01FE8ACC 00000016 R . L . . . .
_strcpy_0                       ROM    01A0EB94 0000000C R . L . . . .
_strcpy_1                       ROM    01FE8AE4 0000000E R . L . . . .
_strcpy_R1_to_R0                ROM    0020FA94 0000000E R . L . . . .
_strrchr                        ROM    0020FBE8 00000016 R . L . . . .
_strrchr_0                      ROM    01A0ECE8 00000014 R . L . . . .
_strtol                         ROM    00211228 00000012 R . L . . . .
_strtol_0                       ROM    002113E8 00000012 R . L . . . .
_strtol_1                       ROM    002117A6 00000012 R . L . . . .
_strtol_2                       ROM    01A10328 00000012 R . L . . . .
_strtol_3                       ROM    01A104E8 00000012 R . L . . . .
_strtol_4                       ROM    01A108A6 00000012 R . L . . . .
_time                           ROM    0020FCD8 0000000E R . L . . . .
_time_0                         ROM    01A0EDD8 0000000E R . L . . . .
_udiv32_sub_FFA053BC            seg010 FFA053BC 00000068 R . . . . . .
deref_0x19E4A98_sub_20620C      ROM    0020620C 0000001E R . . . . . .
deref_0xEA0428_sub_DEA74        ROM    000DEA74 00000014 R . . . . . .
deref_EE0094_sub_205240         ROM    00205240 0000000E R . L . . . .
deref_EE0094_sub_205268         ROM    00205268 00000014 R . . . . . .
deref_R0_AND_0x7FFF_sub_1FAFBE  ROM    001FAFBE 0000001A R . . . . . .
deref_R0_sub_20503A             ROM    0020503A 0000001E R . . . . . .
getRIGOL_TECHNOLOGIES_sub_F1E72 ROM    000F1E72 00000012 R . . . . . .
get_E_S_sub_192AB6              ROM    00192AB6 00000016 R . . . . . .
heapCALLOC_sub_1A0E4C8          ROM    01A0E4C8 00000014 R . L . . . .
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: docmandu on July 19, 2013, 08:10:16 pm
Does it? Only had a very quick look at it. It seemed to be using a pseudo number generator, albeit seeded with a 9 digit number in the example code from MIRACL.
Anyway if they used a proper one, then the only options are a buffer overrun somewhere or directly patching the firmware.

That ecsgen command in the MIRACL toolkit does always generate the same key when you feed it the same seed. I really wonder if Rigol this code as-is (and maybe it was this toolkit that sony also used?! )

Anyway found a nice and understandable explanation of Elliptic Curve and the Sony / rand() exploit:
  http://www.johannes-bauer.com/compsci/ecc/ (http://www.johannes-bauer.com/compsci/ecc/)

Worth a read for people who are into this stuff.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 19, 2013, 08:35:04 pm
nice read: http://www.reteam.org/papers/e77.pdf (http://www.reteam.org/papers/e77.pdf)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zibadun on July 19, 2013, 08:49:40 pm
Does it? Only had a very quick look at it. It seemed to be using a pseudo number generator, albeit seeded with a 9 digit number in the example code from MIRACL.
Anyway if they used a proper one, then the only options are a buffer overrun somewhere or directly patching the firmware.

That ecsgen command in the MIRACL toolkit does always generate the same key when you feed it the same seed. I really wonder if Rigol this code as-is (and maybe it was this toolkit that sony also used?! )

Anyway found a nice and understandable explanation of Elliptic Curve and the Sony / rand() exploit:
  http://www.johannes-bauer.com/compsci/ecc/ (http://www.johannes-bauer.com/compsci/ecc/)

Worth a read for people who are into this stuff.

is there any way to tell if the curve used by ecsgen (from common.ecs?) match the curve in the firmware? 

from cybernet's code
unsigned char prime1[]="AEBF94CEE3E707";
unsigned char prime2[]="AEBF94D5C6AA71";
unsigned char curve_a[]="2982";
unsigned char curve_b[]="3408";
unsigned char point1[]="7A3E808599A525";
unsigned char point2[]="8445B2BE29E5C7";
 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 19, 2013, 08:56:12 pm
didnt play with it, im currently generating my own common.ecs .. and man, on my trusty old linux box this takes *AGES* - i patched up a ecsign that uses the hash (serial+option code) that we need, idea is to then dump the values into the main.c and see what happens.

i did modify a few bytes in the firmware and flashed it, no probs - verfied with jtag that bytes are indeed in RAM after bootup - so lets see what happens when main.c works with my private/pub key, and when i flash those ;-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: docmandu on July 20, 2013, 09:29:57 am
didnt play with it, im currently generating my own common.ecs .. and man, on my trusty old linux box this takes *AGES* - i patched up a ecsign that uses the hash (serial+option code) that we need, idea is to then dump the values into the main.c and see what happens.

i did modify a few bytes in the firmware and flashed it, no probs - verfied with jtag that bytes are indeed in RAM after bootup - so lets see what happens when main.c works with my private/pub key, and when i flash those ;-)

If you need to patch the firmware, you might aswell patch the verification routine to always return OK.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: docmandu on July 20, 2013, 09:37:44 am
Been reading up on ECC a bit. IF the random function in that toolkit does indeed gives the same value each time for all the keys rigol creates, then the first few letters of the license key should be the same. (ie. the license-1-mapped in cybernet's riglol tool is in fact value R you read about in the ECC literature.)

Since I don't have any license keys, I can't check this. I wonder if there are some people that are willing to post the first few letters of their real license key.. ie the first 3-4 letters (well actually the 2nd letter isn't needed, so letters 1 3 4 should suffice to be able to tell if they are the same).

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 20, 2013, 05:14:57 pm
Forget mr_compare your key  would not pass checks earlier.
The way to go is to search the seed that leads to the pub/priv key
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Chet T16 on July 20, 2013, 05:45:02 pm
I just tried loading some keys to my 2072. I loaded the DSA9 key which worked, i tried to load my official 2 option key and it said "option is installed" different than the usual "option installed" message so i took it to mean that the option was already installed and it rejected the new one. Power cycling left me with just my trials.

Installing my official key first allowed me to load the DSA9 key and power cycling leaves just my 2 options installed.

I done this via the scope as I had no laptop near me so I can't perform an uninstall so the scope is showing as a DS2202
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: docmandu on July 20, 2013, 05:50:16 pm
I've been keeping a log of all keys I've come across and so far and the first few characters seem random enough.

I mean official keys, not LLLL dev keys.

BTW another interesting post:
 http://pastebin.com/tvd65ZsB (http://pastebin.com/tvd65ZsB)

and some more discussion from the author of that pastebin at:
 http://forum.tuts4you.com/topic/23665-problem-with-elliptic-curve-implementation/ (http://forum.tuts4you.com/topic/23665-problem-with-elliptic-curve-implementation/)

Look at the curve params...

Doubt ecctool will be of much use, but might be worth giving it a shot.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zibadun on July 20, 2013, 05:57:55 pm
The way to go is to search the seed that leads to the pub/priv key

are you saying rigol did not generate their own curve?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 20, 2013, 06:05:49 pm
They did but the params used are in riglol.c run schoof with prime1 and a & b vals - the outputted q matches the q value which cant be luck id say.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Chet T16 on July 20, 2013, 06:50:52 pm

You always need to restart before loading any key for it to be effective for certain.  It sounds like you tried:

test key -> restart -> official key -> restart = official key options only
official key -> restart -> test key -> restart = back to trial?

If you want to load VSA9 - I'll bet it will return you to DS2072...

Good luck!!

I didn't restart before entering the second key.

test key -> official key -> before restart = all options; restart = back to trial

official key -> test key -> before restart = all options; restart = official key options

My guess is when trying to enter the official key is seen what it thought was the official options already installed so it rejected it with the "option is installed" message.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: docmandu on July 20, 2013, 09:22:04 pm
k=40228745953163121  (0x8EEBD4D04C3771)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: docmandu on July 20, 2013, 10:07:16 pm
k=40228745953163121  (0x8EEBD4D04C3771)

just double checked with some dummy license string. Took the serial&options value, used ecsign to generate r,s values, then punched them into cybernet's riglol tool and we have a winner:

license-1-mapped (r): 2B2A68B20D8C4F
license-2-mapped (s): 42BCAF5D7B505D
license-options:  VSA9 (9C01)
serial&options:   DSA2567890123VSA9
sha1(serial&opts) BB849270F1CF3F11D6396491163CFAEC986D1A85

v: 2B2A68B20D8C4F
r: 2B2A68B20D8C4F

 License Key is VALID


Bingo!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: docmandu on July 20, 2013, 10:58:38 pm
riglol this FVNXGTN-SPSTTHS-JL8AL8Z-M5LB9Q4 DSA2567890123


$ cat common.ecs
3200
AEBF94CEE3E707
2982
3408
AEBF94D5C6AA71
7A3E808599A525
28BE7FAFD2A052
$ cat private.ecs
8EEBD4D04C3771

Seed is whatever you want.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on July 20, 2013, 11:03:48 pm
k=40228745953163121  (0x8EEBD4D04C3771)

Wow! :clap: Thanks for sharing! How did you found it?
Did you use ECCTool? I tried ECCTool but without success.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zibadun on July 20, 2013, 11:16:50 pm
mine works

$ ./ecsign
Enter 9 digit random number seed  = 809809809
file to be signed = foo
$ cat foo.ecs
46417DA2759BDF
7E6CC78BAE17AE

cat foo
DSA2567890123VSA9

i guess what's left is to reverse map foo.ecs to the key
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: docmandu on July 20, 2013, 11:48:08 pm
There's a bug in the ecsign.cpp file.. remove the mip->IOBASE=10; after reading of the common params.

As for zibadun's output.. it's also incorrect. Your input file shouldn't contain a carriage return, which from looking at your foo.ecs values, it does :P
Proper foo.ecs would be:

$ cat foo.ecs
46417DA2759BDF
A6AB6A16A8D038

or JV3AZ5J-VXSVRRS-W4XAYWF-XJ4A96L DSA2567890123


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: docmandu on July 20, 2013, 11:51:36 pm
riglol this FVNXGTN-SPSTTHS-JL8AL8Z-M5LB9QS DSA2567890123

Last char in your code should be an S.

What seed did you use to make this?

Last char doesn't matter too much S->Z,2->9 will work for what character.

Seed,.. think I used 100000000
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on July 21, 2013, 12:06:33 am
docmandu you are genius...that is all I have to say.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on July 21, 2013, 12:10:45 am
k=40228745953163121  (0x8EEBD4D04C3771)

Wow! :clap: Thanks for sharing! How did you found it?

I will answer myself: ECDLP Solver 0.2a found valid solution in 156ms on my computer!
Rigol engineers did really bad job with license keys protection...

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: docmandu on July 21, 2013, 12:12:14 am
cybernet did all the hard work imho.

Anyway no idea why you have issues, but my guess is that your input file contains CR and/or CR/LF. hexdump -C file  on linux to double check.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: docmandu on July 21, 2013, 12:13:29 am
I will answer myself: ECDLP Solver 0.2a found valid solution in 156ms on my computer!

Slow computer  :-DD
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: synapsis on July 21, 2013, 12:49:12 am
k=40228745953163121  (0x8EEBD4D04C3771)

Wow! :clap: Thanks for sharing! How did you found it?

I will answer myself: ECDLP Solver 0.2a found valid solution in 156ms on my computer!
Rigol engineers did really bad job with license keys protection...

Or they just want to sell a lot more scopes. ;) Great job guys!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on July 21, 2013, 12:53:06 am
Just to satisfy my curiosity, why the seed?  Does this imply there are 999999999 possible valid codes?  I've tried 3 different seeds and two did work while one did not...

ecsign in MIRACL contains a little buggy implementation of ECDSA - it doesn't check for cases that may require restart of the algorithm, so sometimes it can return invalid signature.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DanielR on July 21, 2013, 02:54:26 am
So how do you actually generate the key for the scopes serial?

I have MIRACL and main.c compiled.

Regards
Daniel
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on July 21, 2013, 02:56:19 am
Requires mapping the signed key (serial+opts) to the Rigol license format. It looks like docmandu has done this. I'm working on it now; hopefully someone will paste working code before me. Why not help work on it? Shouldn't take too long.

alan2k: can you stop posting if you are just going to erase the posts?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: BravoV on July 21, 2013, 03:03:36 am
alan2k: can you stop posting if you are just going to erase the posts?

+1, its so fucking annoying to read thru those junks in this really great thread :-- , ignore list updated.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DanielR on July 21, 2013, 03:05:28 am
Requires mapping the signed key (serial+opts) to the Rigol license format. It looks like docmandu has done this. I'm working on it now; hopefully someone will paste working code before me. Why not help work on it? Shouldn't take too long.

alan2k: can you stop posting if you are just going to erase the posts?

Right, well I can certainly can help test with my scope if that helps. Ill keep an eye on this.
If there is some code to write I am pretty good in python, c not at all really.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on July 21, 2013, 03:13:20 am
Language doesn't matter

The only references I have is the rigol-to-hex mapping function in main.c, the valid character list, and some valid mapped keys as listed in this thread

edit: mostly done, I think I still have a bug, but I can't generate to test...same issue that I thought I read before (did alank2 delete it? he ruins the discussion), where seed does vary what I see in signed.ecs.

edit 2: don't know what I did while playing with it, now I can generate the sample listed here.

edit 3: hexkey to rigol key done. but ecsign still doesn't work for any other key/serial other than the demo posted earlier, with the seed posted earlier...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 21, 2013, 10:07:38 am
cool stuff, i have a tool that can generate key strings, will release shortly.
i must admit i got the private key yesterday via mail from a guy already, but my ecs tools where so heavily "recoded", the just outputted crap ;-)

should have something this night (GMT) ;-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: UberSteve on July 21, 2013, 10:10:03 am
Keeping a very close eye on this thread....very exciting! Great work guys!  :clap:  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on July 21, 2013, 10:15:11 am
alright, I found the bug... still not sure what it is, something with how the file is edited... echo -n 'DS2A123456789XXXX' > lic works...

So now I can generate license code strings.

Code: [Select]
$ echo -n "DS2A123456873VSA9" > lic; echo -e "123879325\nlic\n" | ./ecsign | php gen.php; ./riglol `php gen.php`
MVVD4QW-CSSG5HS-GMAAMER-J3VS9L4 DS2A123456873

serial:           DS2A123456873
license-key:      MVVD4QWCSSG5HSGMAAMERJ3VS9L4
license-skipped:  MVD4QWCSG5HSGMAMERJ3VSL4 (5CC7A7505036CF032C0B23D199C15)
license-1-mapped: 5CC7A7505036CF
license-2-mapped: 32C0B23D199C15
license-options:  VSA9 (9C01)
serial&options:   DS2A123456873VSA9
sha1(serial&opts) D3B9717C00057C72EDFD409F62F2F10EE04135F2

v:    5CC7A7505036CF
lic1: 5CC7A7505036CF

 License Key is VALID

Questions for others investigating:
1. Is VSA9 the only code that should / can be used? Other codes don't seem to generate valid keys.
2. I generated a key for my scope that passed riglol, but it didn't work (License is unavailable! error) :( Should I try different seeds since the codes change?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 21, 2013, 11:11:52 am
enjoy ! - now i can finaly put by scope back together ;-)  :-+

UPDATE: for a DS2000 use DSA9 as option key !

Code: [Select]
/*
** rigol ds2000 keygen / cybernet & the-eevblog-users
**
** to compile this you need MIRACL from [url]https://github.com/CertiVox/MIRACL[/url]
** download the master.zip into a new folder and run 'unzip -j -aa -L master.zip'
** then run 'bash linux' to build the miracle.a library
**
** BUILD WITH:
**
** gcc rikey.c -I../MIRACL ../MIRACL/miracl.a -o rikey
**
** adapt -I and path to miracl.a to your environment
**
** more info: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/
**
** then fetch private key from EEV Blog and put into "private_key[]=" below, do not prefix with 0x
** supply your serial and wanted options, and enjoy !
**
**
*/

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <ctype.h>
#include <stdio.h>
#include "miracl.h"

#define RIGOL_DS2000

// START OF SETTINGS FOR ECC
#ifdef RIGOL_DS2000
 unsigned char private_key[]="8.....";   // <- RILOL FILL ME (no 0x prefix !)
 unsigned char prime1[]="AEBF94CEE3E707";
 unsigned char prime2[]="AEBF94D5C6AA71";
 unsigned char curve_a[]="2982";
 unsigned char curve_b[]="3408";
 unsigned char point1[]="7A3E808599A525";
 unsigned char point2[]="28BE7FAFD2A052";
#endif
// END OF SETTINGS FOR ECC

unsigned char codemap_ee00d0[]={ 0x0, 0x0, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f,
                                 0x0, 0x0, 0x0,  0x0,  0x0,  0x0,  0x0,  0x0,  0x1,  0x2,
                                 0x3, 0x4, 0x5,  0x6,  0x7,  0x0,  0x8,  0x9,  0xa,  0xb,
                                 0xc, 0x0, 0xd,  0xe,  0xf,  0x10, 0x11, 0x12, 0x13, 0x14,
                                 0x15,0x16, 0x17 };

unsigned char codemap_20688e[]={ 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30,  /* 0-9 = 0x30 */
                                 0x37, 0x37, 0x37, 0x37, 0x37, 0x37 };                        /* A-F = 0x37 */


unsigned char vb[]={'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'J', 'K', 'L', 'M', 'N', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', '2', '3', '4', '5', '6', '7', '8', '9'};

void show_help(void)
{
 printf("./rikey <DSA2XXXXXXXXX> <OPTS>\n\n");
 printf("<DSA2XXXXXXXXX> -  serial number of device\n");
 printf("<OPTS> - \n");
 printf("\t\tDSA? for permanent options\n");
 printf("\t\tVSA? for temporary options\n");
 printf("\n\n");
}
/*
** take serial and options make sha1 hash out of it
*/
static void hashing(unsigned char *opt_str,big hash)
{ /* compute hash function */
    char *p;
    char h[20];
    int ch;
    sha sh;
    shs_init(&sh);
    p=opt_str;
    while(*p)
    {
       shs_process(&sh,*p);
       p++;
    }
    shs_hash(&sh,h);
    bytes_to_big(20,h,hash);
}
/*
** sign the secret message (serial + opts) with the private key
*/
int ecssign(unsigned char *serial, unsigned char *opt, unsigned char *lic1, unsigned char *lic2)
{
    FILE *fp;
    char ifname[50],ofname[50];
    big a,b,p,q,x,y,d,r,s,k,hash;
    epoint *g;
    long seed;
    int bits;
    miracl *mip;
    unsigned char *serial_options;

/* get public data */
    mip=mirsys(0x320, 0x10);   /* Use Hex internally */
    mip->IOBASE=16;
    a=mirvar(0);
    b=mirvar(0);
    p=mirvar(0);
    q=mirvar(0);
    x=mirvar(0);
    y=mirvar(0);
    d=mirvar(0);
    r=mirvar(0);
    s=mirvar(0);
    k=mirvar(0);
    hash=mirvar(0);

    instr(p,prime1);     /* modulus        */
    instr(a,curve_a);     /* curve parameters */
    instr(b,curve_b);
    instr(q,prime2);     /* order of (x,y) */
    instr(x,point1);     /* (x,y) point on curve of order q */
    instr(y,point2);

/* randomise */
    seed=1;
    irand(seed);

    ecurve_init(a,b,p,MR_PROJECTIVE);  /* initialise curve */
    g=epoint_init();

    if (!epoint_set(x,y,0,g)) /* initialise point of order q */
    {
        printf("1. Problem - point (x,y) is not on the curve\n");
        exit(0);
    }

/* calculate r - this can be done offline,
   and hence amortized to almost nothing   */
    bigrand(q,k);
    ecurve_mult(k,g,g);      /* see ebrick.c for method to speed this up */
    epoint_get(g,r,r);
    divide(r,q,q);

/* get private key of signer */
    instr(d, private_key);

/* calculate message digest */
    serial_options=calloc(128,1);
    strcpy(serial_options, serial);
    strcat(serial_options, opt);
    hashing(serial_options,hash);

/* calculate s */
    xgcd(k,q,k,k,k);
    mad(d,r,hash,q,q,s);
    mad(s,k,k,q,q,s);

    cotstr(r,lic1);
    cotstr(s,lic2);
    return 0;
}


/*
** convert string to uppercase chars
*/
unsigned char *strtoupper(unsigned char *str)
{
    unsigned char *newstr, *p;
    p = newstr = (unsigned char*) strdup((char*)str);
    while((*p++=toupper(*p)));
    return newstr;
}

/*
**
*/
unsigned char code_map_206846(unsigned char i)
{
 if ((i >= 'A') && (i <= 'F')) return(i-0x37);
 if ((i >= '0') && (i <= '9')) return(i-0x30);
 return(0x0);
}

/*
** Encryption Routine 1
*/
unsigned char *lic_code_map(unsigned char *lic_skipped)
{
 unsigned char lv1,lv2;
 unsigned char b1_mapped, b1_shifted, b1_remapped;
 unsigned char b2_mapped, b2_shifted, b2_remapped;
 unsigned char b3_mapped, b3_shifted, b3_remapped;
 unsigned char b4_mapped, b4_shifted, b4_remapped;
 unsigned char b5_shifted, b5_remapped;
 unsigned char *lic_mapbytes;

 lic_mapbytes=calloc(28, 1);
 if (!lic_mapbytes) return(0);
lv1=lv2=0;
 while(lv1 < strlen((unsigned char*)lic_skipped))
 {
    b1_mapped =  codemap_ee00d0[ *(lic_skipped+lv1) - 0x30 ];
    b1_shifted = (b1_mapped / 2) & 0xf;
    b1_remapped = b1_shifted + codemap_20688e[b1_shifted];
    lic_mapbytes[lv2++]=b1_remapped;
    b1_mapped = b1_mapped & 0x1;

    b2_mapped =  codemap_ee00d0[ *(lic_skipped+lv1+1) - 0x30 ];
    b2_shifted =  ((b1_mapped << 0x3) | (b2_mapped / 4)) & 0xF;
    b2_remapped = b2_shifted + codemap_20688e[b2_shifted];
    lic_mapbytes[lv2++]=b2_remapped;

    b3_mapped = codemap_ee00d0[ *(lic_skipped+lv1+2) - 0x30 ];
    b3_shifted = ((b3_mapped / 8) | ( (b2_mapped & 0x3) << 2 )) & 0xF;
    b3_remapped = b3_shifted + codemap_20688e[b3_shifted];
    lic_mapbytes[lv2++]=b3_remapped;

    b4_mapped = codemap_ee00d0[ *(lic_skipped+lv1+3) - 0x30 ];
    b4_shifted = ((b4_mapped / 16 ) |((b3_mapped & 0x7) << 0x1)) & 0xf;
    b4_remapped = b4_shifted + codemap_20688e[b4_shifted];
    lic_mapbytes[lv2++]=b4_remapped;

    b5_shifted = b4_mapped & 0xF;
    b5_remapped = b5_shifted + codemap_20688e[b5_shifted];
    lic_mapbytes[lv2++]=b5_remapped;

    lv1 = lv1 + 4;
  }
  return(lic_mapbytes);
}

unsigned char * find_match5(unsigned char *code5)
{
  unsigned char c1,c2,c3,c4;
  unsigned char *input;
  unsigned char *lic_mapbytes;
  input=calloc(40,1);

  /* lets bruteforce it ;-) */
  for (c1=0;c1<sizeof(vb);c1++) {
   for (c2=0;c2<sizeof(vb);c2++) {
    for (c3=0;c3<sizeof(vb);c3++) {
     for (c4=0;c4<sizeof(vb);c4++) {
      input[0]=vb[c1];
      input[1]=vb[c2];
      input[2]=vb[c3];
      input[3]=vb[c4];
      input[4]='\0';
      lic_mapbytes=lic_code_map(input);
      if (!strcmp(lic_mapbytes, code5))
      {
           return(input);
      }
     }
    }
   }
  }
  return(0); // no match
}

int main(int argc, char *argv[0])
{
 unsigned char *options,*lic1_code, *lic2_code, *lic_all;
 unsigned char *out,*chunk,*temp,*final;
 unsigned char *lic1_key, *lic2_key;
 unsigned char *serial;
 int            v,i=0;

 if (strlen(private_key)<14)
 {
  printf("\n\n");
  printf("set the private_key variable on top of this file\n");
  printf("you can find it here: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg264690/#msg264690\n");
  printf("\n\n");
  exit(-1);
 }

 if (argc != 3)
 {
  show_help();
  exit(-1);
 }
 serial=strtoupper((unsigned char*)argv[1]);
 options=strtoupper((unsigned char*)argv[2]);
 if (strlen(serial)<13)
 {
   printf("\nINVALID SERIAL LENGTH\n");
   show_help();
   exit(-1);
 }
 if (strlen(options)!=4)
 {
   printf("\nINVALID OPTIONS LENGTH\n");
   show_help();
   exit(-1);
 }
printf("serial:           %s\n", serial);
 printf("options:          %s\n", options);
 /* sign the message */
 lic1_code=calloc(64,1);
 lic2_code=calloc(64,1);
 ecssign(serial,options,lic1_code, lic2_code);
 printf("lic1-code:        %s\n", lic1_code);
 printf("lic2-code:        %s\n", lic2_code);

 lic_all=calloc(128,1);
 temp=calloc(128,1);
 chunk=calloc(6,1);
 final=calloc(128,1);
 lic1_key=calloc(20,1);
 lic2_key=calloc(20,1);
 strcpy(lic_all, lic1_code);
 strcat(lic_all, "0");
 strcat(lic_all, lic2_code);
 printf("target-code:      %s\n", lic_all);

 // split in 5 byte groups and run bruteforce
 // run or lic1_code
 strcat(lic1_code,"0");
 while(i<=strlen(lic1_code))
 {
   memcpy(chunk,lic1_code+i,5);
   out=find_match5(chunk);
   if (out)
   {
    strcat(temp, out);
   }
   i=i+5;
 }
 strcpy(lic1_key, temp);

 // run for lic2_code
 strcpy(temp,"");
 i=0;
 while(i<strlen(lic2_code))
 {
   memcpy(chunk,lic2_code+i,5);
   if (strlen(chunk)<5)
   {
    for(v=0;v<5-strlen(chunk);v++)
     strcat(chunk,"0");
   }
   out=find_match5(chunk);
   if (out)
   {
    strcat(temp, out);
   }
   i=i+5;
 }
strcpy(lic2_key, temp);
 strcpy(temp, lic1_key);
 strcat(temp, lic2_key);
 // now add the options
 memcpy(final, temp, 1);
 final[1]=options[0];
 memcpy(final+2, temp+1,7);
 final[9]=options[1];
 memcpy(final+10, temp+8,7);
 final[17]=options[2];
 memcpy(final+18, temp+15,7);
 final[25]=options[3];
 memcpy(final+26, temp+22,4);
 printf("----------------------------------------------------\n");
 printf("your-license-key: ");
 for(i=0;i<strlen(final);i++)
 {
  if (i%7==0 && i>0) printf("-");
  printf("%c", final[i]);
 }
 printf("\n");
 printf("----------------------------------------------------\n");
}
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: BravoV on July 21, 2013, 12:04:13 pm
You guys are awesome , big thank you !   :-+  :-+  :-+  :clap:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 21, 2013, 12:05:23 pm
there is some bug, working in it ... so hold your breath for now ;-)

bug fixed. SERIAL is 14 chars not 13 .. i corrected that - and one word of caution, my SERIAL number has just reverted to DS2A0...1 after playing with FW up/down grades
i give a f*ck - but be carefull ;-)

tested with FW05 and FW02 - works.
as long as you can spot the common.ecs parameters in the firmware (aka riglol.c) it should be fine.

some DS4 user should give it a try and report ;-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on July 21, 2013, 12:15:32 pm
Amazing, very well done!  :)

Has anyone tried to Sniffing the Rigol's internal SPI bus of the LMH6518 to see if it works at 350MHz, or 200MHz?
Cheers.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 21, 2013, 12:25:16 pm
suggest you read the WHOLE thread, your answers are there.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: docmandu on July 21, 2013, 12:26:03 pm
Not at home atm‚ so excuse my terseness.

cybernet, you don't need to brute force to go back to serial format. look at my first post in this thread for the algo.

just need to take 5 bits at a time and convert them back to a character.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 21, 2013, 12:28:11 pm
Not at home atm‚ so excuse my terseness.

cybernet, you don't need to brute force to go back to serial format. look at my first post in this thread for the algo.

just need to take 5 bits at a time and convert them back to a character.

true, but i thought its a tiny bit cooler, if it actually bruteforces SOMETHING in the process ;-)
im sure some windows guys will do a nice .exe for that .. they can do it more elegant then ..  :-DD
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DanielR on July 21, 2013, 12:28:36 pm
Works for me on latest firmware on a 2102.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on July 21, 2013, 12:34:25 pm
suggest you read the WHOLE thread, your answers are there.

Okay, so I will.
Thank you very much.  :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: UberSteve on July 21, 2013, 12:36:21 pm
enjoy ! - now i can finaly put by scope back together ;-)  :-+

Big thanks to all involved!  :-+

I can confirm it worked on my recently purchased DS2072 (shipped with latest 01.01.00.02 fw), using DSAZ. I also had ~1900 minutes on the trials remaining at the time of entering the key. It's now a DS2202 with all options "offcial version" ;D

Edit: Also restarted the scope several times just to make sure the options stuck!

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Chet T16 on July 21, 2013, 12:54:39 pm
Bah, can't get MIRACL to build with cygwin.

Someone make a windows executable. With installer. And an android app  :blah:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: darrylp on July 21, 2013, 12:56:34 pm
Cue, lots of serial numbers being PM'd to a few people on here ! :-)


--
 Darryl

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 21, 2013, 12:58:40 pm
dave should host a keygen ;-) a bit of php and it runs ...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jonese on July 21, 2013, 01:02:05 pm
FYI:  My serial on my new 3 day old DS2102 is 13 chars, not 14

DS2A151900xxx
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 21, 2013, 01:07:06 pm
FYI:  My serial on my new 3 day old DS2102 is 13 chars, not 14

DS2A151900xxx

strange, but as long as the secret message matches, it should work as well - will update above code to also allow 13 then.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alez on July 21, 2013, 01:24:47 pm
Just some quick feedback.

I have a DS2072 with a DS2A1517xxxxx serial. I can generate the license key, but the scope does not accept it. I have used "DSAZ" as the option key.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 21, 2013, 01:28:13 pm
Just some quick feedback.

I have a DS2072 with a DS2A1517xxxxx serial. I can generate the license key, but the scope does not accept it. I have used "DSAZ" as the option key.

use DSA9
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: UberSteve on July 21, 2013, 01:32:29 pm

cybernet, my serial is 13 chars also, DS2A1527XXXXX
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 21, 2013, 01:38:38 pm
Just some quick feedback.

I have a DS2072 with a DS2A1517xxxxx serial. I can generate the license key, but the scope does not accept it. I have used "DSAZ" as the option key.

Did you set the private key value in rikey.c?

cybernet, my serial is 13 chars also, DS2A1527XXXXX

guess all of them are 13, but mine is 14, because its been flushed to 0000001 ;-) code has been updated to accept >=13 as serial.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alez on July 21, 2013, 01:40:21 pm
Just some quick feedback.

I have a DS2072 with a DS2A1517xxxxx serial. I can generate the license key, but the scope does not accept it. I have used "DSAZ" as the option key.

use DSA9

That did the trick! Thank you!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dmginc on July 21, 2013, 01:47:42 pm
there is some bug, working in it ... so hold your breath for now ;-)

bug fixed. SERIAL is 14 chars not 13 .. i corrected that - and one word of caution, my SERIAL number has just reverted to DS2A0...1 after playing with FW up/down grades
i give a f*ck - but be carefull ;-)

tested with FW05 and FW02 - works.
as long as you can spot the common.ecs parameters in the firmware (aka riglol.c) it should be fine.

some DS4 user should give it a try and report ;-)

Indeed! Anyone with a DS4xxx willing to try?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jonese on July 21, 2013, 02:12:18 pm
Just wondering if the key is uninstallable in case of warranty repair?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on July 21, 2013, 02:16:48 pm
Just wondering if the key is uninstallable in case of warranty repair?

yes using the uninstall command - note the programming manual is wrong however on its abbreviation:

Works:

:SYSTem:OPTion:UNINSTall

Does Not Work:

:SYST:OPT:UNINST

Probably Works:

:SYST:OPT:UNIN
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: metalphreak on July 21, 2013, 02:36:45 pm
Pretty easy to compile :)

mkdir MIRACL
cd MIRACL/
wget https://github.com/CertiVox/MIRACL/archive/master.zip
unzip -j -aa -L master.zip
bash linux (or bash linux64 if running 64bit OS)

Paste the code from cybernet into rikey.c (make sure to add in the private key!)

gcc rikey.c -I ./ miracl.a -o rikey

Took less than 5mins. I'm sure someone will package a windows EXE or you can PM someone who has it already compiled with your serial.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jonese on July 21, 2013, 02:42:42 pm
The only problem I had was stub-32.h not being found on my x64 box.  Tried to get the proper devel package installed, but I just reverted to a x32 machine instead.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Chet T16 on July 21, 2013, 02:50:44 pm
Whats the reason for not including the private key?

I got mine working no probs with a virtual machine after giving up on cygwin, thanks to all involved
Title: Re: Re: Sniffing the Rigol's internal I2C bus
Post by: darrylp on July 21, 2013, 02:54:35 pm
Whats the reason for not including the private key?

I got mine working no probs with a virtual machine after giving up on cygwin, thanks to all involved

Cos then, you've not released anything that is "hacking" the system rigol is using to make money. Ie their key gen. Of course if you ( the individual ) decides to finish the puzzle then Rigol will have to come after you the individual directly. Which of course they won't.

--
 Darryl

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: metalphreak on July 21, 2013, 03:33:27 pm
Whats the reason for not including the private key?

I got mine working no probs with a virtual machine after giving up on cygwin, thanks to all involved

Yeah I managed to get an exe from Cygwin, it "appears" to work but the information it outputs is bogus.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on July 21, 2013, 04:59:51 pm
Pretty easy to compile :)

mkdir MIRACL
cd MIRACL/
wget https://github.com/CertiVox/MIRACL/archive/master.zip
unzip -j -aa -L master.zip
bash linux (or bash linux64 if running 64bit OS)

Paste the code from cybernet into rikey.c (make sure to add in the private key!)

gcc rikey.c -I ./ miracl.a -o rikey

Took less than 5mins. I'm sure someone will package a windows EXE or you can PM someone who has it already compiled with your serial.

I'm using Linux Mint 15 Cinnamon, 64 bit. I had to install g++ additionally
sudo apt-get install g++

And maybe a missing bits/predefs.h error
sudo apt-get install gcc-multilib

After that I could build the MIRACL package

The rikey application generates a valid license code, very cool work cybernet et al :)
 :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bmwnomad on July 21, 2013, 05:02:56 pm
Got it working under cygwin.  Default install, then add the gcc, gcc-g++ and unzip packages.

Don't forget to edit the rikey.c and add the private key in the approprate area.

Follow the instructions in the comments of the rikey.c file.

Thanks,
Steve
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on July 21, 2013, 05:09:25 pm
Short summary:


Make the Keygen:

mkdir MIRACL
cd MIRACL/
wget https://github.com/CertiVox/MIRACL/archive/master.zip (https://github.com/CertiVox/MIRACL/archive/master.zip)
unzip -j -aa -L master.zip
bash linux (or bash linux64 if running 64bit OS)

Paste the code from cybernet into rikey.c (make sure to add in the private key!) -> rikey.c code:
https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg264876/#msg264876 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg264876/#msg264876)

gcc rikey.c -I ./ miracl.a -o rikey



How to use it?

./rikey <DSA2XXXXXXXXX> <OPTS>

where:
  <DSA2XXXXXXXXX> = S/N of the device.
  <OPTS> = DSAx for official [Permanent Options] or VSAx for trial [Temporary Options].



All Possible Options:

Code table: Use DSAx for a official key, and use VSAx for a trial key.

x  200, 100, Mem, Dec, Trig

A   none
B   ==   ==   ==   ==   on
C   ==   ==   ==   on   ==
D   ==   ==   ==   on   on
E   ==   ==   on   ==   ==
F   ==   ==   on   ==   on
G   ==   ==   on   on   ==
H   ==   ==   on   on   on

Note: keys A..H wont change the model, only ADD an option.

2102:

J   ==   on   ==   ==   ==   
K   ==   on   ==   ==   on
L   ==   on   ==   on   ==
M   ==   on   ==   on   on
N   ==   on   on   ==   ==
P   ==   on   on   ==   on
Q   ==   on   on   on   ==
R   ==   on   on   on   on   <-  All 2102

2202:

S   on   ==   ==   ==   ==   
T   on   ==   ==   ==   on
U   on   ==   ==   on   ==
V   on   ==   ==   on   on
W   on   ==   on   ==   ==
X   on   ==   on   ==   on
Y   on   ==   on   on   ==
Z   on   ==   on   on   on   <-  All 2202

DONT USE BELOW Not recommended, as activates 2102 and also 2202:

2   on   on   ==   ==   ==
3   on   on   ==   ==   on
4   on   on   ==   on   ==
5   on   on   ==   on   on
6   on   on   on   ==   ==
7   on   on   on   ==   on
8   on   on   on   on   ==
9   on   on   on   on   on



How install/unistall keys?

Using a SCPI command via Rigol Ultra Sigma, connect DSO via USB, boot the DSO, start Ultra Sigma, open SCPI Control Panel, and type the following:

:SYSTem:OPTion:INSTall <GeneratedKey>

Then, if you want to get rid of it, enter:

:SYSTem:OPTion:UNINSTall

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: metalphreak on July 21, 2013, 05:12:41 pm
Cygwin:
options:          DSA9
lic1-code:        42D818229EAE3D
lic2-code:        846DD600607AF4
target-code:      42D818229EAE3D0846DD600607AF4

Linux:
options:          DSA9
lic1-code:        6CDA7B4CFB7267
lic2-code:        46D85196962A32
target-code:      6CDA7B4CFB7267046D85196962A32

lic1 stays the same between different serial numbers. However, is lic1 supposed to be the same for all compiles? If not, and there are multiple valid keys per serial, then my Cygwin compile may be fine, I just don't have a scope to test with. Also, on some serial numbers (randomly generated) the key generated has a few characters at the end missing (both linux and cygwin).

DS2A000000450 for example has characters cutoff under linux, but is fine for cygwin. Maybe a different seed is required for some :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: HK3R on July 21, 2013, 06:09:21 pm
Compiled in a Mac with Mountain Lion using the linux64 script, both kind of keys worked perfect in my DS2072 with latest firmware!! ;D, I entered the keys using the DSO editos not the USB connection.



Thanks for the great work!  :clap:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 21, 2013, 06:23:40 pm
while grabbing some fresh air ...

... i thought it would be very cool, if rigol, as the platform is now somewhat "open" decides to make the DS2K series a real open platform.
just imagine that u have proper input stages, ADC, plenty of memory, FPGA's, a powerful enough DSP to run linux + custom GUI, keypad - mighty display, LAN etc..

i would have been more than happy to pay 1000$ for such a platform - if they release some starter kit with a basic functional scope, that would take the market by storm i think,
and their R&D could be spent on their more high end models, or even transfer features from that platform. it would be no match for the cheap ass arduino + some ADC kits that are out there.
i believe there is no serious project like that in existence ?

it could be done without rigol, but i dont have plans to get in touch with the bootloader anymore, maybe somebody else wants to (he can have my stuff then) - also the fpga part would be hard to
reverse ..
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DL5TOR on July 21, 2013, 06:27:55 pm
one quick question:

is it posible to reverse the Serialnumber used??

why the question: i have a DSA815 the license looks the same but i can not figure out what the serrial is that is used. and if this works then we also have  aworking keygen for the das hihi

thx
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 21, 2013, 06:29:12 pm
one quick question:

is it posible to reverse the Serialnumber used??

why the question: i have a DSA815 the license looks the same but i can not figure out what the serrial is that is used. and if this works then we also have  aworking keygen for the das hihi

thx

dont think so, because its a hash value .... if u have a GEL fiel for the DSA, the answer is in the gel file ... ;-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on July 21, 2013, 06:31:02 pm
Used DSAZ, works fine, had to hard power-cycle the scope though before it would boot again. Serial number has now been set to DS2A0000000001 (might be wrong about the amount of 0's) and model to DS2202.

Should I make a web frontend for this? Can anyone host it?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on July 21, 2013, 06:44:53 pm
Used DSAZ, works fine, had to hard power-cycle the scope though before it would boot again. Serial number has now been set to DS2A0000000001 (might be wrong about the amount of 0's) and model to DS2202.

Does anyone have a theory as to why some serial numbers get reset to the above?  What exactly did you do prior to this happening?  What firmware are you on?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ilya on July 21, 2013, 07:34:11 pm
I have DS2072 with the earliest firmware. The only option set that worked for me was DSAH.

Going to upgrade the FW now  O0
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on July 21, 2013, 07:35:12 pm
Used DSAZ, works fine, had to hard power-cycle the scope though before it would boot again. Serial number has now been set to DS2A0000000001 (might be wrong about the amount of 0's) and model to DS2202.

Does anyone have a theory as to why some serial numbers get reset to the above?  What exactly did you do prior to this happening?  What firmware are you on?

Should I even respond to you? You're just going to delete your post later.

Not sure which FW, haven't even looked. I entered via on-screen keyboard. Accepted, rebooted, hard-power-cycled since it wouldn't boot, checked system info and there it is. I can't remember what I read about this, I think they proper serial comes back if the key is uninstalled, no?

====

I wrote a web front-end for setting options and generating a key, very user-friendly, I just need a place to host it. I could also put in a field for requiring the private key to be put in.

====

edit: added webgen screenshot (again)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ilya on July 21, 2013, 07:55:00 pm
I wrote a web front-end for setting options and generating a key, very user-friendly, I just need a place to host it. I could also put in a field for requiring the private key to be put in.

PM sent

EDIT:

Updated to latest FW and was able to enter DSAR code! Now my 2072 shows that it's 2202 :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Chet T16 on July 21, 2013, 08:24:20 pm
I can host too if a mirror is needed
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: doma on July 21, 2013, 08:28:42 pm

DONT USE BELOW, as activates 2102 and also 2202:

2   on   on   ==   ==   ==
3   on   on   ==   ==   on
4   on   on   ==   on   ==
5   on   on   ==   on   on
6   on   on   on   ==   ==
7   on   on   on   ==   on
8   on   on   on   on   ==
9   on   on   on   on   on


Great work! I used DSA9 as cybernet recommended and it works fine.

Why do you still recommend not to use DSA9?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on July 21, 2013, 08:46:00 pm

DONT USE BELOW, as activates 2102 and also 2202:

2   on   on   ==   ==   ==
3   on   on   ==   ==   on
4   on   on   ==   on   ==
5   on   on   ==   on   on
6   on   on   on   ==   ==
7   on   on   on   ==   on
8   on   on   on   on   ==
9   on   on   on   on   on


Great work! I used DSA9 as cybernet recommended and it works fine.

Why do you still recommend not to use DSA9?

As you can see from your paste, It installs 100M and 200M options, which isn't necessary. 200M supersedes 100M anyway. It likely won't bring any troubles but there's no need for it. DSAZ is equivalent.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on July 21, 2013, 09:30:27 pm
Great work!

And here's a version without brute force.

Code: [Select]

/*
 ** rigol ds2000 keygen / cybernet & the-eevblog-users
 **
 ** to compile this you need MIRACL from [url]https://github.com/CertiVox/MIRACL[/url]
 ** download the master.zip into a new folder and run 'unzip -j -aa -L master.zip'
 ** then run 'bash linux' to build the miracle.a library
 **
 ** BUILD WITH:
 **
 ** gcc rikey.c -I../MIRACL ../MIRACL/miracl.a -o rikey
 **
 ** adapt -I and path to miracl.a to your environment
 **
 ** more info: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/
 **
 ** then fetch private key from EEV Blog and put into "private_key[]=" below, do not prefix with 0x
 ** supply your serial and wanted options, and enjoy !
 **
 **
 */

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <ctype.h>
#include <stdio.h>
#include "miracl.h"

#define RIGOL_DS2000

// START OF SETTINGS FOR ECC
#ifdef RIGOL_DS2000
unsigned char private_key[]="8...";   // <- RILOL FILL ME (no 0x prefix !)
unsigned char prime1[]="AEBF94CEE3E707";
unsigned char prime2[]="AEBF94D5C6AA71";
unsigned char curve_a[]="2982";
unsigned char curve_b[]="3408";
unsigned char point1[]="7A3E808599A525";
unsigned char point2[]="28BE7FAFD2A052";
#endif
// END OF SETTINGS FOR ECC

unsigned char vb[]={'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'J', 'K', 'L', 'M', 'N', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', '2', '3', '4', '5', '6', '7', '8', '9'};

void show_help(void)
{
  printf("./rikey <DSA2XXXXXXXXX> <OPTS>\n\n");
  printf("<DSA2XXXXXXXXX> -  serial number of device\n");
  printf("<OPTS> - \n");
  printf("\t\tDSA? for permanent options\n");
  printf("\t\tVSA? for temporary options\n");
  printf("\n\n");
}
/*
** take serial and options make sha1 hash out of it
 */
static void hashing(unsigned char *opt_str,big hash)
{ /* compute hash function */
  char *p;
  char h[20];
  int ch;
  sha sh;
  shs_init(&sh);
  p=opt_str;
  while(*p)
  {
    shs_process(&sh,*p);
    p++;
  }
  shs_hash(&sh,h);
  bytes_to_big(20,h,hash);
}
/*
** sign the secret message (serial + opts) with the private key
 */
int ecssign(unsigned char *serial, unsigned char *opt, unsigned char *lic1, unsigned char *lic2)
{
  FILE *fp;
  char ifname[50],ofname[50];
  big a,b,p,q,x,y,d,r,s,k,hash;
  epoint *g;
  long seed;
  int bits;
  miracl *mip;
  unsigned char *serial_options;

  /* get public data */
  mip=mirsys(0x320, 0x10);   /* Use Hex internally */
  mip->IOBASE=16;
  a=mirvar(0);
  b=mirvar(0);
  p=mirvar(0);
  q=mirvar(0);
  x=mirvar(0);
  y=mirvar(0);
  d=mirvar(0);
  r=mirvar(0);
  s=mirvar(0);
  k=mirvar(0);
  hash=mirvar(0);

  instr(p,prime1);     /* modulus        */
  instr(a,curve_a);     /* curve parameters */
  instr(b,curve_b);
  instr(q,prime2);     /* order of (x,y) */
  instr(x,point1);     /* (x,y) point on curve of order q */
  instr(y,point2);

  /* randomise */
  seed=1;
  irand(seed);

  ecurve_init(a,b,p,MR_PROJECTIVE);  /* initialise curve */
  g=epoint_init();

  if (!epoint_set(x,y,0,g)) /* initialise point of order q */
  {
    printf("1. Problem - point (x,y) is not on the curve\n");
    exit(0);
  }

  /* calculate r - this can be done offline,
   and hence amortized to almost nothing   */
  bigrand(q,k);
  ecurve_mult(k,g,g);      /* see ebrick.c for method to speed this up */
  epoint_get(g,r,r);
  divide(r,q,q);

  /* get private key of signer */
  instr(d, private_key);

  /* calculate message digest */
  serial_options=calloc(128,1);
  strcpy(serial_options, serial);
  strcat(serial_options, opt);
  hashing(serial_options,hash);

  /* calculate s */
  xgcd(k,q,k,k,k);
  mad(d,r,hash,q,q,s);
  mad(s,k,k,q,q,s);

  cotstr(r,lic1);
  cotstr(s,lic2);
  return 0;
}


/*
** convert string to uppercase chars
 */
unsigned char *strtoupper(unsigned char *str)
{
  unsigned char *newstr, *p;
  p = newstr = (unsigned char*) strdup((char*)str);
  while((*p++=toupper(*p)));
  return newstr;
}

unsigned char * find_match5(unsigned char *code5)
{
  unsigned long long b=0;
  unsigned char *out;
  int i=0;
  out=calloc(5,1);

  // hex2dez
  while (code5[i] != '\0') {
    if (code5[i]>='1' && code5[i]<='9')
      b=b*16+code5[i]-'0';
    else if (code5[i]>='A' && code5[i]<='F')
      b=b*16+code5[i]-'A'+10;
    else if (code5[i]>='a' && code5[i]<='f')
      b=b*16+code5[i]-'a'+10;
    i++;
  }   

  for (i=3;;i--) {
    out[i]=vb[b & 0x1F];
    if (i==0) break;
    b>>=5;
  }
  out[4]='\0';

  return(out);
}

int main(int argc, char *argv[0])
{
  unsigned char *options,*lic1_code, *lic2_code, *lic_all;
  unsigned char *out,*chunk,*temp,*final;
  unsigned char *lic1_key, *lic2_key;
  unsigned char *serial;
  int            v,i=0;

  if (strlen(private_key)<14)
  {
    printf("\n\n");
    printf("set the private_key variable on top of this file\n");
    printf("you can find it here: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg264690/#msg264690\n");
    printf("\n\n");
    exit(-1);
  }

  if (argc != 3)
  {
    show_help();
    exit(-1);
  }
  serial=strtoupper((unsigned char*)argv[1]);
  options=strtoupper((unsigned char*)argv[2]);
  if (strlen(serial)<13)
  {
    printf("\nINVALID SERIAL LENGTH\n");
    show_help();
    exit(-1);
  }
  if (strlen(options)!=4)
  {
    printf("\nINVALID OPTIONS LENGTH\n");
    show_help();
    exit(-1);
  }
  printf("serial:           %s\n", serial);
  printf("options:          %s\n", options);
  /* sign the message */
  lic1_code=calloc(64,1);
  lic2_code=calloc(64,1);
  ecssign(serial,options,lic1_code, lic2_code);
  printf("lic1-code:        %s\n", lic1_code);
  printf("lic2-code:        %s\n", lic2_code);

  lic_all=calloc(128,1);
  temp=calloc(128,1);
  chunk=calloc(6,1);
  final=calloc(128,1);
  lic1_key=calloc(20,1);
  lic2_key=calloc(20,1);
  strcpy(lic_all, lic1_code);
  strcat(lic_all, "0");
  strcat(lic_all, lic2_code);
  printf("target-code:      %s\n", lic_all);

  // split in 5 byte groups
  // run for lic1_code
  strcat(lic1_code,"0");
  while(i<strlen(lic1_code))
  {
    memcpy(chunk,lic1_code+i,5);
    out=find_match5(chunk);
    if (out)
    {
      strcat(temp, out);
    }
    i=i+5;
  }
  strcpy(lic1_key, temp);

  // run for lic2_code
  strcpy(temp,"");
  i=0;
  while(i<strlen(lic2_code))
  {
    memcpy(chunk,lic2_code+i,5);
    if (strlen(chunk)<5)
    {
      for(v=0;v<5-strlen(chunk);v++)
        strcat(chunk,"0");
    }
    out=find_match5(chunk);
    if (out)
    {
      strcat(temp, out);
    }
    i=i+5;
  }
  strcpy(lic2_key, temp);
  strcpy(temp, lic1_key);
  strcat(temp, lic2_key);
  // now add the options
  memcpy(final, temp, 1);
  final[1]=options[0];
  memcpy(final+2, temp+1,7);
  final[9]=options[1];
  memcpy(final+10, temp+8,7);
  final[17]=options[2];
  memcpy(final+18, temp+15,7);
  final[25]=options[3];
  memcpy(final+26, temp+22,4);
  printf("----------------------------------------------------\n");
  printf("your-license-key: ");
  for(i=0;i<strlen(final);i++)
  {
    if (i%7==0 && i>0) printf("-");
    printf("%c", final[i]);
  }
  printf("\n");
  printf("----------------------------------------------------\n");
}

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 21, 2013, 09:31:51 pm
because some have asked for it, and it might prove valueable to other equipment,
here are the basic steps to perform something like this.

1. find a good forum on the internet with clever ppl -> that one here is great  :-+
2. see what others have done, but dont keep that direction (e.g. FRAM, great start but to cumbersome for most)
3. if a device is firmware updateable you own 50% already
4. if u can tinker with a device while its running (memory, cpu, breakpoints, watchpoints) you own another 49% (->JTAG !)
5. study the datasheets, and esp. the engineering notes carefully (know your enemy) - companies rarely dev their own stuff if they have something proven premade available.
    in rigols case thats ethernet, webserver, usb, filesystem thats 100% AD VSDK sourcekit - its damn easy to spot this functions and link em to c files/headers.
6. check if there are copyprotection or "lockbox" features as AD calls it - that could prove a showstopper - but luckly not a single memory reference to those registers
    from that point on i was 100% sure its doable.
7. i choose the path to reverse the crypto stuff instead of googling some obvious numbers, because i thought it was fun to do (and it was, learned a lot - e.g. the AD compiler produces crap code)
8. the real kickoff was when some guy posted that one of the routines is a sha1 hash function (it uses distinct values to initialise), made sense, pasted it into google,
    and what came back as first hit was the MIRACL toolkit, and it was damn f*ck me i've seen that structures before  ->  :-DD
9. i could match the subs almost 1:1 by just looking at them at that point - so this made it clear that they use ECC - which was a bummer because ECC is rather secure if implemented correctly.
10. the A/B curve values looked *tiny* and the 56bits of keys .. are well below standard ... so there was a slim chance that it would lead somebody with more math foo to a private key.
     i played several hours with ecssign,ecsgen, etc swapped keys and primes here and there ,but nothing, maybe i had it but missed it - anyhow a email and pm told me to try another key (the right one)
     and again i could not make it work (i had the wrong Q value as i used the one from ROM, not the one from ./schoof) - that cleared with a look into the forum where ppl where able to get riglol to verify the
     key. so a good chunk of kudos goes to the key finders (there are some ppl who mailed them ! :-+)

im pretty damn sure that the entire lineup of rigol as long as its BFIN based, shares a good deal of common code - so apply the same principles to any other device and u will have success sooner or later.

i plan to get a DG4062 next ;-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 21, 2013, 09:32:53 pm
Great work!

cool stuff ! but now its to quick ;P
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on July 21, 2013, 09:41:22 pm
Great work!

And here's a version without brute force.

--snip--
thanks, saved me some work. put the modified function and line in main() in my modified version, works fast like my php version did. :)

Quote from: cybernet
i plan to get a DG4062 next ;-)
I was thinking of doing the same thing...Rigol might have another sale =)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: synapsis on July 21, 2013, 09:54:56 pm

i plan to get a DG4062 next ;-)

Already ordered my DG4062. ;)

I'm working on a Windows GUI version of your code (gotta give back to the community). I have the miracl lib built. I'm working on the UI, then I'll port your latest code in. If it's not *too* difficult, I'll try and put a button in to send the code over USB to the scope.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 21, 2013, 09:57:25 pm
I'm working on a Windows GUI version of your code (gotta give back to the community). I have the miracl lib built. I'm working on the UI, then I'll port your latest code in. If it's not *too* difficult, I'll try and put a button in to send the code over USB to the scope.
:-+

uninstall would be cool too i guess (if there is a way to enumerate installed stuff via usb ?)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on July 21, 2013, 10:26:07 pm
I still see one issue in that some people's S/N is changing.  This could be caused by either setting both the 100M and 200M flag (DSA"9") instead of DSAZ, or caused by trying the 100M and/or 200M flags on older firmware (<FW02 "00.01.01.00.02").  I recommend upgrading to this firmware version before trying keys and even then sticking with DSAZ and not using DSA9.  For the people who have had their S/N changed, I don't know if an uninstall using the SCPI command will fix it or not.  Hopefully someone will come up with a hack to fix or set their S/N at some point.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on July 21, 2013, 10:27:35 pm
I have the web generator done, just need somewhere to host it.

Quote from: alank2
I still see one issue in that some people's S/N is changing.
I just checked my FW, it is 0.0.1.0.5 old firmware, even though the unit was made in April of 2013. Loaded 0.1.1.0.2, doesn't change the S/N. However, I did lose 2ns timebase and can't see installed options anymore. I can install an option though.

Right now I am setting up the software so I can uninstall the key and see what happens. Honestly I am not too concerned what the serial shows - if there really is a HW problem, Rigol can't (and really probably wouldn't) care about any software crap on it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Maalobs on July 21, 2013, 10:42:26 pm
Truly incredible work! :-+
I can only say a big thank you to everyone involved!

I built the miracl.a lib and the rikey app with the priv key inserted, and ran it on my DS2102's serial with DSAZ as option.
It curiously only produced two characters in the fourth (final) character-group, and it's not accepted by the scope since it lacks the required number of characters.
But using DSAR instead for a maxed out DS2102, did produce a correct license key, and the options-list now shows "Offcial Version" [sic] on every line.

I did this while on 00.00.01.00.05 if it matters.
Afterwards I upgraded to 00.01.01.00.02, and the options-list still shows "Offcial Version" on everything.

My DS2102 serial is 13 characters long btw, and the serial was not changed by entering the DSAR license.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zibadun on July 21, 2013, 10:46:09 pm
I have the web generator done, just need somewhere to host it.

how long before some places start re-badging the scopes and selling them as upgraded models, or selling the keys at a "discount"? 
call me paranoid  :o
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 21, 2013, 10:52:29 pm
I have the web generator done, just need somewhere to host it.

how long before some places start re-badging the scopes and selling them as upgraded models, or selling the keys at a "discount"? 
call me paranoid  :o

if they have a DS2202 sticker for me, i take one ;-)  :-DD
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bluesmoke on July 21, 2013, 11:43:44 pm
It looks like doing this is not without risk!
I also tried the DSAZ key as the DSA9 didn't give a complete code. Scope needed a second cold reboot to start and serial was set to 1 like true and cybernet. I was on firmware 5 so I thought I'd upgrade. If I install 2 or 3 (even by the poweron/help method) the scope hangs and will not boot. Going back to 5 gets it going again. Tried to uninstall the code but it looks like it is permanent....

Any way to reset a serial?

Oh well...C'est la vie!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 21, 2013, 11:52:54 pm
could be that DSAZ/9 cause something to be overwritten in FRAM when on FW05 - i had your issue with FW02, then downgraded to FW05 (released serial is #1) - then applied DSAH code, then back up to FW02 - scope hang *once* after the FW02 firmware flash (right most DOT filled on boot screen iirc), but powercycled and it was ok started several times since then no issues - and serial #1 i dont care about it. i dont plan to touch FRAM, but you could check for your old serial in there, its probably there, has to be ;-) - i *think* there might be an engineering menu hidden somewhere, but the serial port stuff which uses the keypad was to annoying for me to go over. maybe somebody else figures that one out ;-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bluesmoke on July 22, 2013, 12:00:51 am
Thanks Cybernet.... I'll try the DSAH code and see if I can get back to 2 or 3

UPDATE:  Tried a bunch of keys but it refuses to go back to a DS2072. I did eventually get it to accept firmware 3 then 2... now just the serial to  look into.... Fantastic work guys!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on July 22, 2013, 12:05:28 am
When upgrading from the old firmware, the scope reverted to 2072 which is why I lost 2ns timebase.

Since then I can go forward, backward, reboot in the middle, flash with bootloader, install keys, uninstall, install trial or permanent LLLL and power cycle, install trial or permanent LLLL and uninstall, doesn't matter - it's always a 2202 now with sn #1.

Not a big deal, just weird / frustrating trying to change it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: poida_pie on July 22, 2013, 12:08:12 am
works fine using cybernet's code. I tried Studio's modified code but it segfaulted.
Ubuntu 32 bit virtual machine, installed DSAZ code onto a plain old DS2072 with no trials installed or hacked.

(to do this I needed to send a VSA9 code to make everything volatile and so not retained over reboots.
This also removed the persistent DS2202 model description)

After reboot, no trail time reminder, all options installed. The machine's serial number was not altered.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on July 22, 2013, 12:15:26 am
i *think* there might be an engineering menu hidden somewhere, but the serial port stuff which uses the keypad was to annoying for me to go over. maybe somebody else figures that one out ;-)

You would be the person in the know to try to find an engineering menu - they sure love hiding them in odd keystroke sequences...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: darrylp on July 22, 2013, 12:17:52 am
well my DS2072, was using the permanent LLLLL code, and was showing as a DS2202.

anyway, can confirm input the trial key returned mine back to saying it was a DS2072

I built the keygen on a linux64 box,  and it doesnt work using the brute force or the lookup table for the keys on my ubuntu 10.04lts system

so took the same code over to a linux 32bit box, made the library ( .a file ) and the two versions of the keygen, and while both on the 64bit or the 32bit box both gave diffent keys )  the bruteforce on the 32bit box has worked, and given me a DS2202 :-)

survived full power off / on.  am happy.


I see a version to make an ARM code of the library, so will see what codes that comes up with.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on July 22, 2013, 03:31:39 am
Yeah, no choice of codes will get mine back as a 2072...seems completely stuck as a 2202.

I noticed the same problems with the 64 bit and cpp versions of MIRACL (because I was having problems with the non-cpp versions I had to use that one first), the generated values are different and they don't work either. I don't know, not a MIRACL hacker, can't say what is going on and not super interested.

I've got an online generator up; PM me if you need it to generate a code. Still could use a host though since this is on a private personal server. No warranties or guarantees etc.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: roli_bark on July 22, 2013, 06:22:24 am
Assuming that the ECC curve is the same, will "rikey.c" work for the DS4000 series as well ?

No Mem upgrade option there (they all  come the same). But YES, most probably for the options for BW & Serial Decode. They should be upgradable.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dmginc on July 22, 2013, 06:32:59 am
Assuming that the ECC curve is the same, will "rikey.c" work for the DS4000 series as well ?

No Mem upgrade option there (they all  come the same). But YES, most probably for the options for BW & Serial Decode. They should be upgradable.

I'd like to know this as well... Anyone got a DS4xxx to test?  ;D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on July 22, 2013, 06:47:57 am
works fine using cybernet's code. I tried Studio's modified code but it segfaulted.

Should now be fixed.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on July 22, 2013, 07:16:02 am
I have two Linux systems here, a 32bit and a 64bit, both running Linux mint Cinnamon.

Installed the MIRACL on both systems (only difference was the bash linux vs the linux64

Compiled the rikey.c from cybernet on both systems.

I get different results for the key when I run it on a 32 bit or 64bit system. The one on the 64bit system was accepted. I did not dare to try it again with the 32bit version on my scope.

Why would there be a difference between 32bit and 64bit systems ?

ps. the version from studio25 gives also different results even on the same system....
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 22, 2013, 07:25:12 am
I have two Linux systems here, a 32bit and a 64bit, both running Linux mint Cinnamon.

Installed the MIRACL on both systems (only difference was the bash linux vs the linux64

Compiled the rikey.c from cybernet on both systems.

I get different results for the key when I run it on a 32 bit or 64bit system. The one on the 64bit system was accepted. I did not dare to try it again with the 32bit version on my scope.

Why would there be a difference between 32bit and 64bit systems ?

ps. the version from studio25 gives also different results even on the same system....

could be that the bigrand function gets seeded differently on 32 vs 64bit
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: poida_pie on July 22, 2013, 07:32:08 am
Studio25:

I can confirm it works now on my 32bit Ubuntu VM
It yielded a different code compared with  Cybernet's brute force code.

(checks right now....uninstalls already working code from Cybernet
sends ":SYST:OPT:UNINST"+"\n"
yep no options any more ..
sends code generated by your program
"License is unavailable" hmmm
loads code from Cybernet
"option installed")

So there still seems to be problems.
if you like I can PM you my DS2072 serial no. and the two generated codes used.


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: synapsis on July 22, 2013, 07:37:24 am
Ok, I have code running that works on Windows with a GUI. It produces the same key output as cybernet's code. But for some reason on my scope it won't take an official DSAZ code. If I just switch the DSAZ to VSAZ, it resets the trial option time (except the 200M time is different.) 

I've compared the output with a copy running on Ubuntu 32-bit, all the outputs match. I've noticed that when I use DSAZ, my lic2-code is one character short. I'll fiddle with it a bit more in the morning.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on July 22, 2013, 08:09:25 am
Ok, I have code running that works on Windows with a GUI. It produces the same key output as cybernet's code. But for some reason on my scope it won't take an official DSAZ code. If I just switch the DSAZ to VSAZ, it resets the trial option time (except the 200M time is different.) 

I've compared the output with a copy running on Ubuntu 32-bit, all the outputs match. I've noticed that when I use DSAZ, my lic2-code is one character short. I'll fiddle with it a bit more in the morning.

Try changing the seed, that has worked for me and is why the web generator has the seed field.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: synapsis on July 22, 2013, 08:13:27 am
I tried changing the seed a couple times, but my scope was in some kind of lockdown from trying bad keys at the time and I didn't notice. I'll have to try it again tomorrow.

Is there any reason that I shouldn't just generate a psuedorandom seed every time in the app?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on July 22, 2013, 08:44:08 am
I tried changing the seed a couple times, but my scope was in some kind of lockdown from trying bad keys at the time and I didn't notice. I'll have to try it again tomorrow.

Is there any reason that I shouldn't just generate a psuedorandom seed every time in the app?

Repeatability. If you don't care about it you can make it random.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: darrylp on July 22, 2013, 08:59:04 am
okay, can see some code difference between the linux64 and linux32 bit of source that gets copied to mrmuldv.s that would stop it working on the AMD64bit CPU's,  so question is how are people getting their codes to work / load on such machines ?

anyway.  have built a windows command line version ( aka cygwin )  it doesn't need cygwin installed or setup of course, just a normal cmd window.

generates the same codes as cybernets brute force code. which have worked on my scope.

Darryl

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tinhead on July 22, 2013, 09:12:17 am
okay, can see some code difference between the linux64 and linux32 bit of source that gets copied to mrmuldv.s that would stop it working on the AMD64bit CPU's,  so question is how are people getting their codes to work / load on such machines ?

of course there are diffs, they for different CPUs. The mrmuldv.s used on Rigol should be different as well.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: darrylp on July 22, 2013, 09:28:26 am
okay, can see some code difference between the linux64 and linux32 bit of source that gets copied to mrmuldv.s that would stop it working on the AMD64bit CPU's,  so question is how are people getting their codes to work / load on such machines ?

of course there are diffs, they for different CPUs. The mrmuldv.s used on Rigol should be different as well.

no, i'm meaning,the use of mulq, which produces a 64 bit result, the 32bit when doing mull will not produce an overflow of two unsigned uint32_t types, the 64 bit version however can and will return different values. if the X or Y values are too big.

Darryl
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 22, 2013, 10:39:19 am
if somebody wants to fix the lic1/lic2 code, it should be left padded with 0 to size 14 when it comes out of ecssign.
e.g. if its to short, 0<code> ...00<code> ... whatever is missing to make it 14 chars - i was just too lazy for that - that should then provide valid serial all the time.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mickpah on July 22, 2013, 11:06:08 am
HI
looks like I'm one of the lucky or unlucky , can't decide.
I used the LLLLLLL-RLGLLDS-DSA9LLL-LLLLLLL code and now my 2072 is stuck as a 2012.
tired the USB spi uninstall ,rolled back the firmware  generated a new key and they don't install, though this maybe me.
Reading the thread I don't think I'm the only one in this situation ? I'm trying to approach this logically and reading the thread , but there is so much there now, hints appreciated.
PS this is an early scope  delivery was about August 2012
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 22, 2013, 11:08:52 am
your serial is probably DS2A........1 - check in the system info - if so welcome to the club, best serial anyway ;-) - so you need to adapt the serial when generating a key
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: racanu on July 22, 2013, 01:30:52 pm
Good day Sir,

I am a beginner and your thread for me is very tricky.  I have a Rigol DS 2102 oscilloscope. Firstly I would like to activate the option and secondly I want to convert this Rigol into a Rigol DS 2202. Can you tell me very clear what should I do to convert it?

My Firmware is 00.00.01.00.02
Hardware is 1.1.0.0

I bought this item from e-bay one month ago.

Cheers :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Maalobs on July 22, 2013, 01:47:07 pm
if somebody wants to fix the lic1/lic2 code, it should be left padded with 0 to size 14 when it comes out of ecssign.
e.g. if its to short, 0<code> ...00<code> ... whatever is missing to make it 14 chars - i was just too lazy for that - that should then provide valid serial all the time.
Yes, that was the problem, I didn't get a complete license code for the DSAZ option, and in that calculation my lic2 was only 13 chars long.
I did a strrev/strcat/strrev on it and now I got a working DSAZ and my DS2102 became a DS2202. :-+
My serialno is still intact, if someone wonders.

I had the DSAR option installed already, I tried uninstalling it with :SYSTEM:OPTION:UNINSTALL (both with and without the license code as parameter), but nothing happened.
So I have both DSAR and DSAZ activated, and my "Installed Options"-list shows both of these at the bottom of the list:
BANDWIDTH  100M BandWidth  Offcial Version
BANDWIDTH  200M BandWidth  Offcial Version

Is this how it's supposed to show up on a DS2202, or should I do something to make the scope only show the 200M option?
Title: Re: Re: Sniffing the Rigol's internal I2C bus
Post by: darrylp on July 22, 2013, 02:16:48 pm
Is this how it's supposed to show up on a DS2202, or should I do something to make the scope only show the 200M option?

I've seen both listed when using the LLLLL type keys and I was trying the various combinations. But i only "upgraded" my scope so that it only shows the 200 bandwidth line. My testing last evening shows everything functional. Just the installed options don't show the 100 line now, can still bandwidth limit each channel to the 20 & 100 as well as OFF.

--
 Darryl

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 22, 2013, 03:58:04 pm
received yet another mail from "some guy" - thanks when u read this  :-+
he pointed out a reason why some lic codes are failing, and that guy knows what he is talking about ;-)
see below:

Quote
As prime2 is no prime-number (its prime-factors are [17, 53, 905461,
60291817]) it is possible that the generated s (lic2) is divisible
by one of these factors which will lead to an invalid license key.

This can be detected in ecssign with something like:

Code: [Select]
int prime2_factors[] = {17, 53, 905461, 60291817};
int i;
big tmp;

tmp = mirvar(0);
for (i = 0; i < (sizeof(prime2_factors) / sizeof(prime2_factors[0])); i++) {
lgconv(prime2_factors[i], tmp);
if (divisible(s, tmp)) {
//increment seed and redo signing
...
}
}
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: synapsis on July 22, 2013, 06:08:26 pm
Way to go cybernet's secret source and true!

My issue was a combination of the leading zero *and* the seed (everything that can go wrong, will). I'm going to see what it takes to implement a button that applies the key and finish out a couple things.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on July 22, 2013, 06:15:01 pm
Way to go cybernet's secret source and true!

My issue was a combination of the leading zero *and* the seed (everything that can go wrong, will). I'm going to see what it takes to implement a button that applies the key and finish out a couple things.

I would love to see a possibility in your application that leaves the option code open for keys like DSA9....
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: synapsis on July 22, 2013, 06:22:07 pm
I would love to see a possibility in your application that leaves the option code open for keys like DSA9....

Looks like I won't have time to put in the key loading button, but I'll put an option code override in since it makes sense.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on July 22, 2013, 07:06:23 pm
if somebody wants to fix the lic1/lic2 code, it should be left padded with 0 to size 14 when it comes out of ecssign.
e.g. if its to short, 0<code> ...00<code> ... whatever is missing to make it 14 chars - i was just too lazy for that - that should then provide valid serial all the time.
Yes, that was the problem, I didn't get a complete license code for the DSAZ option, and in that calculation my lic2 was only 13 chars long.
I did a strrev/strcat/strrev on it and now I got a working DSAZ and my DS2102 became a DS2202. :-+
My serialno is still intact, if someone wonders.

I had the DSAR option installed already, I tried uninstalling it with :SYSTEM:OPTION:UNINSTALL (both with and without the license code as parameter), but nothing happened.
So I have both DSAR and DSAZ activated, and my "Installed Options"-list shows both of these at the bottom of the list:
BANDWIDTH  100M BandWidth  Offcial Version
BANDWIDTH  200M BandWidth  Offcial Version

Is this how it's supposed to show up on a DS2202, or should I do something to make the scope only show the 200M option?

Here you go Linux adepts!

Code: [Select]
/*
** rigol ds2000 keygen / cybernet & the-eevblog-users
**
** to compile this you need MIRACL from [url]https://github.com/CertiVox/MIRACL[/url]
** download the master.zip into a new folder and run 'unzip -j -aa -L master.zip'
** then run 'bash linux' to build the miracle.a library
**
** BUILD WITH:
**
** gcc rikey.c -I../MIRACL ../MIRACL/miracl.a -o rikey
**
** adapt -I and path to miracl.a to your environment
**
** more info: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/
**
** then fetch private key from EEV Blog and put into "private_key[]=" below, do not prefix with 0x
** supply your serial and wanted options, and enjoy !
**
**
*/

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <ctype.h>
#include <stdio.h>
#include "miracl.h"

#define RIGOL_DS2000

// START OF SETTINGS FOR ECC
#ifdef RIGOL_DS2000
 unsigned char private_key[]="8EE";   // <- RILOL FILL ME (no 0x prefix !)
 unsigned char prime1[]="AEBF94CEE3E707";
 unsigned char prime2[]="AEBF94D5C6AA71";
 unsigned char curve_a[]="2982";
 unsigned char curve_b[]="3408";
 unsigned char point1[]="7A3E808599A525";
 unsigned char point2[]="28BE7FAFD2A052";
#endif
// END OF SETTINGS FOR ECC

unsigned char codemap_ee00d0[]={ 0x0, 0x0, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f,
                                 0x0, 0x0, 0x0,  0x0,  0x0,  0x0,  0x0,  0x0,  0x1,  0x2,
                                 0x3, 0x4, 0x5,  0x6,  0x7,  0x0,  0x8,  0x9,  0xa,  0xb,
                                 0xc, 0x0, 0xd,  0xe,  0xf,  0x10, 0x11, 0x12, 0x13, 0x14,
                                 0x15,0x16, 0x17 };

unsigned char codemap_20688e[]={ 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30,  /* 0-9 = 0x30 */
                                 0x37, 0x37, 0x37, 0x37, 0x37, 0x37 };                        /* A-F = 0x37 */


unsigned char vb[]={'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'J', 'K', 'L', 'M', 'N', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', '2', '3', '4', '5', '6', '7', '8', '9'};

void show_help(void)
{
 printf("./rikey <DSA2XXXXXXXXX> <OPTS>\n\n");
 printf("<DSA2XXXXXXXXX> -  serial number of device\n");
 printf("<OPTS> - \n");
 printf("\t\tDSA? for permanent options\n");
 printf("\t\tVSA? for temporary options\n");
 printf("\n\n");
}
/*
** take serial and options make sha1 hash out of it
*/
static void hashing(unsigned char *opt_str,big hash)
{ /* compute hash function */
    char *p;
    char h[20];
    int ch;
    sha sh;
    shs_init(&sh);
    p=opt_str;
    while(*p)
    {
       shs_process(&sh,*p);
       p++;
    }
    shs_hash(&sh,h);
    bytes_to_big(20,h,hash);
}
/*
** sign the secret message (serial + opts) with the private key
*/
int ecssign(unsigned char *serial, unsigned char *opt, unsigned char *lic1, unsigned char *lic2)
{
    FILE *fp;
    char ifname[50],ofname[50];
    big a,b,p,q,x,y,d,r,s,k,hash;
    epoint *g;
    long seed;
    int bits;
    miracl *mip;
    unsigned char *serial_options;

/* get public data */
    mip=mirsys(0x320, 0x10);   /* Use Hex internally */
    mip->IOBASE=16;
    a=mirvar(0);
    b=mirvar(0);
    p=mirvar(0);
    q=mirvar(0);
    x=mirvar(0);
    y=mirvar(0);
    d=mirvar(0);
    r=mirvar(0);
    s=mirvar(0);
    k=mirvar(0);
    hash=mirvar(0);

    instr(p,prime1);     /* modulus        */
    instr(a,curve_a);     /* curve parameters */
    instr(b,curve_b);
    instr(q,prime2);     /* order of (x,y) */
    instr(x,point1);     /* (x,y) point on curve of order q */
    instr(y,point2);

/* randomise */
    seed=1;
    irand(seed);

    ecurve_init(a,b,p,MR_PROJECTIVE);  /* initialise curve */
    g=epoint_init();

    if (!epoint_set(x,y,0,g)) /* initialise point of order q */
    {
        printf("1. Problem - point (x,y) is not on the curve\n");
        exit(0);
    }

/* calculate r - this can be done offline,
   and hence amortized to almost nothing   */
    bigrand(q,k);
    ecurve_mult(k,g,g);      /* see ebrick.c for method to speed this up */
    epoint_get(g,r,r);
    divide(r,q,q);

/* get private key of signer */
    instr(d, private_key);

/* calculate message digest */
    serial_options=calloc(128,1);
    strcpy(serial_options, serial);
    strcat(serial_options, opt);
    hashing(serial_options,hash);

/* calculate s */
    xgcd(k,q,k,k,k);
    mad(d,r,hash,q,q,s);
    mad(s,k,k,q,q,s);

    cotstr(r,lic1);
    cotstr(s,lic2);
    return 0;
}


/*
** convert string to uppercase chars
*/
unsigned char *strtoupper(unsigned char *str)
{
    unsigned char *newstr, *p;
    p = newstr = (unsigned char*) strdup((char*)str);
    while((*p++=toupper(*p)));
    return newstr;
}

/*
**
*/
unsigned char code_map_206846(unsigned char i)
{
 if ((i >= 'A') && (i <= 'F')) return(i-0x37);
 if ((i >= '0') && (i <= '9')) return(i-0x30);
 return(0x0);
}

/*
** Encryption Routine 1
*/
unsigned char *lic_code_map(unsigned char *lic_skipped)
{
 unsigned char lv1,lv2;
 unsigned char b1_mapped, b1_shifted, b1_remapped;
 unsigned char b2_mapped, b2_shifted, b2_remapped;
 unsigned char b3_mapped, b3_shifted, b3_remapped;
 unsigned char b4_mapped, b4_shifted, b4_remapped;
 unsigned char b5_shifted, b5_remapped;
 unsigned char *lic_mapbytes;

 lic_mapbytes=calloc(28, 1);
 if (!lic_mapbytes) return(0);
lv1=lv2=0;
 while(lv1 < strlen((unsigned char*)lic_skipped))
 {
    b1_mapped =  codemap_ee00d0[ *(lic_skipped+lv1) - 0x30 ];
    b1_shifted = (b1_mapped / 2) & 0xf;
    b1_remapped = b1_shifted + codemap_20688e[b1_shifted];
    lic_mapbytes[lv2++]=b1_remapped;
    b1_mapped = b1_mapped & 0x1;

    b2_mapped =  codemap_ee00d0[ *(lic_skipped+lv1+1) - 0x30 ];
    b2_shifted =  ((b1_mapped << 0x3) | (b2_mapped / 4)) & 0xF;
    b2_remapped = b2_shifted + codemap_20688e[b2_shifted];
    lic_mapbytes[lv2++]=b2_remapped;

    b3_mapped = codemap_ee00d0[ *(lic_skipped+lv1+2) - 0x30 ];
    b3_shifted = ((b3_mapped / 8) | ( (b2_mapped & 0x3) << 2 )) & 0xF;
    b3_remapped = b3_shifted + codemap_20688e[b3_shifted];
    lic_mapbytes[lv2++]=b3_remapped;

    b4_mapped = codemap_ee00d0[ *(lic_skipped+lv1+3) - 0x30 ];
    b4_shifted = ((b4_mapped / 16 ) |((b3_mapped & 0x7) << 0x1)) & 0xf;
    b4_remapped = b4_shifted + codemap_20688e[b4_shifted];
    lic_mapbytes[lv2++]=b4_remapped;

    b5_shifted = b4_mapped & 0xF;
    b5_remapped = b5_shifted + codemap_20688e[b5_shifted];
    lic_mapbytes[lv2++]=b5_remapped;

    lv1 = lv1 + 4;
  }
  return(lic_mapbytes);
}

unsigned char * find_match5(unsigned char *code5)
{
  unsigned char c1,c2,c3,c4;
  unsigned char *input;
  unsigned char *lic_mapbytes;
  input=calloc(40,1);

  /* lets bruteforce it ;-) */
  for (c1=0;c1<sizeof(vb);c1++) {
   for (c2=0;c2<sizeof(vb);c2++) {
    for (c3=0;c3<sizeof(vb);c3++) {
     for (c4=0;c4<sizeof(vb);c4++) {
      input[0]=vb[c1];
      input[1]=vb[c2];
      input[2]=vb[c3];
      input[3]=vb[c4];
      input[4]='\0';
      lic_mapbytes=lic_code_map(input);
      if (!strcmp(lic_mapbytes, code5))
      {
           return(input);
      }
     }
    }
   }
  }
  return(0); // no match
}

char *strrev(char *str)
{
      char *p1, *p2;

      if (! str || ! *str)
            return str;
      for (p1 = str, p2 = str + strlen(str) - 1; p2 > p1; ++p1, --p2)
      {
            *p1 ^= *p2;
            *p2 ^= *p1;
            *p1 ^= *p2;
      }
      return str;
}


int main(int argc, char *argv[0])
{
 unsigned char *options,*lic1_code, *lic2_code, *lic_all;
 unsigned char *out,*chunk,*temp,*final;
 unsigned char *lic1_key, *lic2_key;
 unsigned char *serial;
 int            v,i=0;

 if (strlen(private_key)<14)
 {
  printf("\n\n");
  printf("set the private_key variable on top of this file\n");
  printf("you can find it here: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg264690/#msg264690\n");
  printf("\n\n");
  exit(-1);
 }

 if (argc != 3)
 {
  show_help();
  exit(-1);
 }
 serial=strtoupper((unsigned char*)argv[1]);
 options=strtoupper((unsigned char*)argv[2]);
 if (strlen(serial)<13)
 {
   printf("\nINVALID SERIAL LENGTH\n");
   show_help();
   exit(-1);
 }
 if (strlen(options)!=4)
 {
   printf("\nINVALID OPTIONS LENGTH\n");
   show_help();
   exit(-1);
 }
 printf("serial:           %s\n", serial);
 printf("options:          %s\n", options);
 /* sign the message */
 lic1_code=calloc(64,1);
 lic2_code=calloc(64,1);
 ecssign(serial,options,lic1_code, lic2_code);
 
 if (strlen(lic2_code)==13)
 {
  strrev(lic2_code);
  strcat(lic2_code, "0");
  strrev(lic2_code);
 }
 
 if (strlen(lic1_code)==13)
 {
  strrev(lic1_code);
  strcat(lic1_code, "0");
  strrev(lic1_code);
 }
 
 printf("lic1-code:        %s\n", lic1_code);
 printf("lic2-code:        %s\n", lic2_code);

 lic_all=calloc(128,1);
 temp=calloc(128,1);
 chunk=calloc(6,1);
 final=calloc(128,1);
 lic1_key=calloc(20,1);
 lic2_key=calloc(20,1);
 strcpy(lic_all, lic1_code);
 strcat(lic_all, "0");
 strcat(lic_all, lic2_code);
 printf("target-code:      %s\n", lic_all);

 // split in 5 byte groups and run bruteforce
 // run or lic1_code
 strcat(lic1_code,"0");
 while(i<=strlen(lic1_code))
 {
   memcpy(chunk,lic1_code+i,5);
   out=find_match5(chunk);
   if (out)
   {
    strcat(temp, out);
   }
   i=i+5;
 }
 strcpy(lic1_key, temp);

 // run for lic2_code
 strcpy(temp,"");
 i=0;
 while(i<strlen(lic2_code))
 {
   memcpy(chunk,lic2_code+i,5);
   if (strlen(chunk)<5)
   {
    for(v=0;v<5-strlen(chunk);v++)
     strcat(chunk,"0");
   }
   out=find_match5(chunk);
   if (out)
   {
    strcat(temp, out);
   }
   i=i+5;
 }
 strcpy(lic2_key, temp);
 strcpy(temp, lic1_key);
 strcat(temp, lic2_key);
 // now add the options
 memcpy(final, temp, 1);
 final[1]=options[0];
 memcpy(final+2, temp+1,7);
 final[9]=options[1];
 memcpy(final+10, temp+8,7);
 final[17]=options[2];
 memcpy(final+18, temp+15,7);
 final[25]=options[3];
 memcpy(final+26, temp+22,4);
 printf("----------------------------------------------------\n");
 printf("your-license-key: ");
 for(i=0;i<strlen(final);i++)
 {
  if (i%7==0 && i>0) printf("-");
  printf("%c", final[i]);
 }
 printf("\n");
 printf("----------------------------------------------------\n");
}
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: doma on July 22, 2013, 08:21:22 pm

DONT USE BELOW, as activates 2102 and also 2202:

2   on   on   ==   ==   ==
3   on   on   ==   ==   on
4   on   on   ==   on   ==
5   on   on   ==   on   on
6   on   on   on   ==   ==
7   on   on   on   ==   on
8   on   on   on   on   ==
9   on   on   on   on   on


Great work! I used DSA9 as cybernet recommended and it works fine.

Why do you still recommend not to use DSA9?

As you can see from your paste, It installs 100M and 200M options, which isn't necessary. 200M supersedes 100M anyway. It likely won't bring any troubles but there's no need for it. DSAZ is equivalent.

OK, so having the DSA9 already installed (license key generated with original rikey.c ) - everything Official Version - I sent an UNINSTALL and my scope got back to a normal 2072. I had the serial intact all the time. I had the latest FW installed before initially starting installing licenses.

Then on a 32 bit linux box I created a DSAZ license key with rikey.c - my serial is DS2A...2 and is 13 chars long. I sent it to the scope: verification failed
Then I used the "no_brute_force" version of rikey.c - this created a different license key for DSAZ with the same serial but sending it to the scope yielded: verification failed again

Both lic1 and lic2 keys have always been 14 chars long.

So I stopped here.
Any ideas/explanations/suggestions?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: synapsis on July 22, 2013, 08:31:14 pm
Here's the Windows app.

I tried for quite a while to get it to run under .NET 2.0, but Visual Studio 2010 gimped VC++'s ability to roll back the .NET version. This means it'll require .NET 4.0. 4.0 is 3 years old now, and I've included the web installer in the package.

How to use:
- You enter the private key in the first field. If you don't know where to get it, click the "Information" link.
- Enter the serial number from your scope into the second field.
- Select which options you'd like. The option code will be generated on the fly in the Option Code box. For those of you that want to play with the option codes, you can edit it by hand.
- Click Generate. It will take all the information and generate a key into the textbox.

Note: If User Account Control in Windows complains that it needs permissions, it's because the miracl library and cybernet's part of the code was compiled "unmanaged", and the GUI is "managed." This managed/unmanaged mess is what took so long. :)

Enjoy.  :-+

Edit: I was going to put the source project up on my website, but apparently my site is down. Once I get that figured out, I'll put it up.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 22, 2013, 08:33:32 pm
 :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: orbiter on July 22, 2013, 08:35:12 pm
Thanks very much synapsis, AND to each and every other EEVBee that has made this possible.

Thank You Again
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: doma on July 22, 2013, 08:38:51 pm

DONT USE BELOW, as activates 2102 and also 2202:

2   on   on   ==   ==   ==
3   on   on   ==   ==   on
4   on   on   ==   on   ==
5   on   on   ==   on   on
6   on   on   on   ==   ==
7   on   on   on   ==   on
8   on   on   on   on   ==
9   on   on   on   on   on


Great work! I used DSA9 as cybernet recommended and it works fine.

Why do you still recommend not to use DSA9?

As you can see from your paste, It installs 100M and 200M options, which isn't necessary. 200M supersedes 100M anyway. It likely won't bring any troubles but there's no need for it. DSAZ is equivalent.

OK, so having the DSA9 already installed (license key generated with original rikey.c ) - everything Official Version - I sent an UNINSTALL and my scope got back to a normal 2072. I had the serial intact all the time. I had the latest FW installed before initially starting installing licenses.

Then on a 32 bit linux box I created a DSAZ license key with rikey.c - my serial is DS2A...2 and is 13 chars long. I sent it to the scope: verification failed
Then I used the "no_brute_force" version of rikey.c - this created a different license key for DSAZ with the same serial but sending it to the scope yielded: verification failed again

Both lic1 and lic2 keys have always been 14 chars long.

So I stopped here.
Any ideas/explanations/suggestions?

OK, so I used cybernet's verification routine on all keys generated. And yes, the result is the same. The DSA9 key generated is VALID, while DSAZ key generated is INVALID against my serial.

Edit:
I changed the seed and now it works. Thanks again.

Sorry for talking to myself in the open :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on July 22, 2013, 08:46:59 pm
Try changing the seed; the key generated probably starts with 0, there is a 1 in 16 chance of this. I'll post a version that fixes this (Orange's only looks for len 13, but it could start with 00, it's pretty hackish) and is a little more readable later.

Would still love to use an engineering / service menu... :(
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: synapsis on July 22, 2013, 08:49:33 pm
Here's a snippit of code I used to fix the leading 0 and the reseed issue. You can probably cut/paste the changes into the linux version. Just take out the class names/Windows stuff.

Code: [Select]
void Rikey::Generate(const char* pkey, const char* sn, const char* opts, long seed, System::Windows::Forms::TextBox^ txtout)
{
unsigned char *options, *lic1_code, *lic2_code, *lic_all;
unsigned char *out,*chunk,*temp,*final, *l1_temp, *l2_temp;
unsigned char *lic1_key, *lic2_key;
char conText[255];
int  v,i=0, j = 0;
Random^ rng = gcnew Random();

private_key=(unsigned char*)strtoupper((char*)pkey);
serial=(unsigned char*)strtoupper((char*)sn);
options=(unsigned char*)strtoupper((char*)opts);

sprintf(conText, "serial:           %s\n", serial);
txtout->AppendText( gcnew System::String(conText));

sprintf(conText, "options:          %s\n", options);
txtout->AppendText( gcnew System::String(conText));

/* sign the message */
l1_temp=(unsigned char*)calloc(64,1);
l2_temp=(unsigned char*)calloc(64,1);

do
{
ecssign(serial,options,l1_temp, l2_temp, seed);

sprintf(conText, "Seed: %08x lic1: %014s lic2: %014s\n", seed, l1_temp, l2_temp);
txtout->AppendText( gcnew System::String(conText));

seed = rng->Next();
j++;
if (j > 10)
{
txtout->AppendText(gcnew System::String("Failed to find prime seed.\n"));
return;
}
} while(prime_check(l2_temp));



lic1_code=(unsigned char*)calloc(64,1);
lic2_code=(unsigned char*)calloc(64,1);

sprintf((char*)lic1_code, "%014s", l1_temp);
sprintf((char*)lic2_code, "%014s", l2_temp);

/*sprintf(conText, "lic1-code:        %s\n", lic1_code);
txtout->AppendText( gcnew System::String(conText));

sprintf(conText, "lic2-code:        %s\n", lic2_code);
txtout->AppendText( gcnew System::String(conText));*/

lic_all=(unsigned char*)calloc(128,1);
temp=(unsigned char*)calloc(128,1);
chunk=(unsigned char*)calloc(6,1);
final=(unsigned char*)calloc(128,1);
lic1_key=(unsigned char*)calloc(20,1);
lic2_key=(unsigned char*)calloc(20,1);
strcpy((char*)lic_all, (const char*)lic1_code);
strcat((char*)lic_all, "0");
strcat((char*)lic_all, (const char*)lic2_code);
sprintf(conText, "target-code:      %s\n", lic_all);
txtout->AppendText( gcnew System::String(conText));

// split in 5 byte groups and run bruteforce
// run or lic1_code
strcat((char*)lic1_code,"0");
while(i<strlen((const char*)lic1_code))
{
memcpy(chunk,lic1_code+i,5);
out=find_match5(chunk);
if (out)
{
strcat((char*)temp, (const char*)out);
}
i=i+5;
}
strcpy((char *)lic1_key, (const char*)temp);

// run for lic2_code
strcpy((char *)temp,"");
i=0;
while(i<strlen((const char*)lic2_code))
{
memcpy(chunk,lic2_code+i,5);
if (strlen((const char*)chunk)<5)
{
for(v=0;v<5-strlen((const char*)chunk);v++)
strcat((char*)chunk,"0");
}
out=find_match5(chunk);
if (out)
{
strcat((char*)temp, (const char*)out);
}
i=i+5;
}
strcpy((char*)lic2_key, (const char*)temp);
strcpy((char*)temp, (const char*)lic1_key);
strcat((char*)temp, (const char*)lic2_key);
// now add the options
memcpy(final, temp, 1);
final[1]=options[0];
memcpy(final+2, temp+1,7);
final[9]=options[1];
memcpy(final+10, temp+8,7);
final[17]=options[2];
memcpy(final+18, temp+15,7);
final[25]=options[3];
memcpy(final+26, temp+22,4);

txtout->AppendText( gcnew System::String("----------------------------------------------------\n"));


txtout->AppendText( gcnew System::String("your-license-key: "));

for(i=0;i<strlen((const char*)final);i++)
{
if (i%7==0 && i>0) txtout->AppendText( gcnew System::String("-"));


sprintf(conText, "%c", final[i]);
txtout->AppendText( gcnew System::String(conText));

}
txtout->AppendText( gcnew System::String("\n"));
txtout->AppendText( gcnew System::String("----------------------------------------------------\n"));

}

bool Rikey::prime_check(unsigned char* lic2)
{
int prime2_factors[] = {17, 53, 905461, 60291817};
int i;
big tmp;
big s;


tmp = mirvar(0);
s = mirvar(0);
instr(s,(char*)lic2);

for (i = 0; i < (sizeof(prime2_factors) / sizeof(prime2_factors[0])); i++) {
lgconv(prime2_factors[i], tmp);
if (divisible(s, tmp)) {
return true;
}
}

return false;
}
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on July 22, 2013, 08:51:19 pm
received yet another mail from "some guy" - thanks when u read this  :-+
he pointed out a reason why some lic codes are failing, and that guy knows what he is talking about ;-)
see below:

Quote
As prime2 is no prime-number (its prime-factors are [17, 53, 905461,
60291817]) it is possible that the generated s (lic2) is divisible
by one of these factors which will lead to an invalid license key.

This can be detected in ecssign with something like:

Code: [Select]
int prime2_factors[] = {17, 53, 905461, 60291817};
int i;
big tmp;

tmp = mirvar(0);
for (i = 0; i < (sizeof(prime2_factors) / sizeof(prime2_factors[0])); i++) {
lgconv(prime2_factors[i], tmp);
if (divisible(s, tmp)) {
//increment seed and redo signing
...
}
}

This check is not sufficient. Additionaly you have to ensure, that random value of k is not divisible by above factors of 'prime2' (BTW this will also ensure, that k is not equal to 0, which is required by ECDSA algorithm) and that neither r, nor s are equal to 0 (again - ECDSA requirement). If any of these checks fails, then you need to redo signing with a new value of k (note that in keygen this value doesn't need to be random at all - you can start with k=1 and increment it by 1 if necessary).

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on July 22, 2013, 08:53:53 pm

DONT USE BELOW, as activates 2102 and also 2202:

2   on   on   ==   ==   ==
3   on   on   ==   ==   on
4   on   on   ==   on   ==
5   on   on   ==   on   on
6   on   on   on   ==   ==
7   on   on   on   ==   on
8   on   on   on   on   ==
9   on   on   on   on   on


Great work! I used DSA9 as cybernet recommended and it works fine.

Why do you still recommend not to use DSA9?

As you can see from your paste, It installs 100M and 200M options, which isn't necessary. 200M supersedes 100M anyway. It likely won't bring any troubles but there's no need for it. DSAZ is equivalent.

OK, so having the DSA9 already installed (license key generated with original rikey.c ) - everything Official Version - I sent an UNINSTALL and my scope got back to a normal 2072. I had the serial intact all the time. I had the latest FW installed before initially starting installing licenses.

Then on a 32 bit linux box I created a DSAZ license key with rikey.c - my serial is DS2A...2 and is 13 chars long. I sent it to the scope: verification failed
Then I used the "no_brute_force" version of rikey.c - this created a different license key for DSAZ with the same serial but sending it to the scope yielded: verification failed again

Both lic1 and lic2 keys have always been 14 chars long.

So I stopped here.
Any ideas/explanations/suggestions?

OK, so I used cybernet's verification routine on all keys generated. And yes, the result is the same. The DSA9 key generated is VALID, while DSAZ key generated is INVALID against my serial.

Edit:
I changed the seed and now it works. Thanks again.

Sorry for talking to myself in the open :)

So ?

DSA9 rules !

The quote "dont use below" (DSA9) is misleading ; to many instances with problems using DSAZ
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on July 22, 2013, 09:05:11 pm
So ?

DSA9 rules !

The quote "dont use below" (DSA9) is misleading ; to many instances with problems using DSAZ

Then I remove it?  :-//

Better I change it by: "Not recommended ,as activates 2102 and also 2202:"
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on July 22, 2013, 09:06:04 pm
Here's the Windows app.

:-+ :-+ :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on July 22, 2013, 09:13:25 pm
DSAZ is perfect - if you can't generate one try a different seed value until you can.  You don't want to use DSA9.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on July 22, 2013, 09:16:34 pm
DSAZ is perfect - if you can't generate one try a different seed value until you can.  You don't want to use DSA9.

That's what I was thinking.  :-+

Thanks for the windows APP synapsis.  ^-^
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: doma on July 22, 2013, 09:29:12 pm
Here's the generator code amended with "some guy"'s recommendation. Now it generates a VALID code for me w/o manually fiddling around with the seed.

Code: [Select]
/*
** rigol ds2000 keygen / cybernet & the-eevblog-users
**
** to compile this you need MIRACL from [url]https://github.com/CertiVox/MIRACL[/url]
** download the master.zip into a new folder and run 'unzip -j -aa -L master.zip'
** then run 'bash linux' to build the miracle.a library
**
** BUILD WITH:
**
** gcc rikey.c -I../MIRACL ../MIRACL/miracl.a -o rikey
**
** adapt -I and path to miracl.a to your environment
**
** more info: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/
**
** then fetch private key from EEV Blog and put into "private_key[]=" below, do not prefix with 0x
** supply your serial and wanted options, and enjoy !
**
**
*/

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <ctype.h>
#include <stdio.h>
#include "miracl.h"

#define RIGOL_DS2000

// START OF SETTINGS FOR ECC
#ifdef RIGOL_DS2000
 unsigned char private_key[]="8...";   // <- RILOL FILL ME (no 0x prefix !)
 unsigned char prime1[]="AEBF94CEE3E707";
 unsigned char prime2[]="AEBF94D5C6AA71";
 unsigned char curve_a[]="2982";
 unsigned char curve_b[]="3408";
 unsigned char point1[]="7A3E808599A525";
 unsigned char point2[]="28BE7FAFD2A052";
#endif
// END OF SETTINGS FOR ECC

unsigned char codemap_ee00d0[]={ 0x0, 0x0, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f,
                                 0x0, 0x0, 0x0,  0x0,  0x0,  0x0,  0x0,  0x0,  0x1,  0x2,
                                 0x3, 0x4, 0x5,  0x6,  0x7,  0x0,  0x8,  0x9,  0xa,  0xb,
                                 0xc, 0x0, 0xd,  0xe,  0xf,  0x10, 0x11, 0x12, 0x13, 0x14,
                                 0x15,0x16, 0x17 };

unsigned char codemap_20688e[]={ 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30,  /* 0-9 = 0x30 */
                                 0x37, 0x37, 0x37, 0x37, 0x37, 0x37 };                        /* A-F = 0x37 */


unsigned char vb[]={'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'J', 'K', 'L', 'M', 'N', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', '2', '3', '4', '5', '6', '7', '8', '9'};

void show_help(void)
{
 printf("./rikey <DSA2XXXXXXXXX> <OPTS>\n\n");
 printf("<DSA2XXXXXXXXX> -  serial number of device\n");
 printf("<OPTS> - \n");
 printf("\t\tDSA? for permanent options\n");
 printf("\t\tVSA? for temporary options\n");
 printf("\n\n");
}
/*
** take serial and options make sha1 hash out of it
*/
static void hashing(unsigned char *opt_str,big hash)
{ /* compute hash function */
    char *p;
    char h[20];
    int ch;
    sha sh;
    shs_init(&sh);
    p=opt_str;
    while(*p)
    {
       shs_process(&sh,*p);
       p++;
    }
    shs_hash(&sh,h);
    bytes_to_big(20,h,hash);
}
/*
** sign the secret message (serial + opts) with the private key
*/
int ecssign(unsigned char *serial, unsigned char *opt, unsigned char *lic1, unsigned char *lic2)
{
    FILE *fp;
    char ifname[50],ofname[50];
    big a,b,p,q,x,y,d,r,s,k,hash,temps;
    epoint *g;
    long seed;
    int bits;
    miracl *mip;
    unsigned char *serial_options;
/* Support variables for checking against divisibility */
    int prime2_factors[] = {17, 53, 905461, 60291817};
    int i;
    int passed;
    big tmp;

    /* randomise */
    seed=1;
    srand(seed);

   do {
passed = 1;
    /* get public data */
mip=mirsys(0x320, 0x10);   /* Use Hex internally */
mip->IOBASE=16;
a=mirvar(0);
b=mirvar(0);
p=mirvar(0);
q=mirvar(0);
x=mirvar(0);
y=mirvar(0);
d=mirvar(0);
r=mirvar(0);
s=mirvar(0);
k=mirvar(0);
hash=mirvar(0);

instr(p,prime1);     /* modulus        */
instr(a,curve_a);     /* curve parameters */
instr(b,curve_b);
instr(q,prime2);     /* order of (x,y) */
instr(x,point1);     /* (x,y) point on curve of order q */
instr(y,point2);


ecurve_init(a,b,p,MR_PROJECTIVE);  /* initialise curve */
g=epoint_init();

if (!epoint_set(x,y,0,g)) /* initialise point of order q */
{
    printf("1. Problem - point (x,y) is not on the curve\n");
    exit(0);
}

    /* calculate r - this can be done offline,
      and hence amortized to almost nothing   */
bigrand(q,k);
ecurve_mult(k,g,g);      /* see ebrick.c for method to speed this up */
epoint_get(g,r,r);
divide(r,q,q);

    /* get private key of signer */
instr(d, private_key);

    /* calculate message digest */
serial_options=calloc(128,1);
strcpy(serial_options, serial);
strcat(serial_options, opt);
hashing(serial_options,hash);

    /* calculate s */
xgcd(k,q,k,k,k);
mad(d,r,hash,q,q,s);
mad(s,k,k,q,q,s);

    /* check if we got a valid lic2 (s) */
tmp = mirvar(0);
for (i = 0; i < (sizeof(prime2_factors) / sizeof(prime2_factors[0])); i++) {
    lgconv(prime2_factors[i], tmp);
    if (divisible(s, tmp)) {
    passed = 0;
    srand(++seed);
            break;
    }
}
   } while (!passed);

    cotstr(r,lic1);
    cotstr(s,lic2);

    return 0;
}


/*
** convert string to uppercase chars
*/
unsigned char *strtoupper(unsigned char *str)
{
    unsigned char *newstr, *p;
    p = newstr = (unsigned char*) strdup((char*)str);
    while((*p++=toupper(*p)));
    return newstr;
}

/*
**
*/
unsigned char code_map_206846(unsigned char i)
{
 if ((i >= 'A') && (i <= 'F')) return(i-0x37);
 if ((i >= '0') && (i <= '9')) return(i-0x30);
 return(0x0);
}

/*
** Encryption Routine 1
*/
unsigned char *lic_code_map(unsigned char *lic_skipped)
{
 unsigned char lv1,lv2;
 unsigned char b1_mapped, b1_shifted, b1_remapped;
 unsigned char b2_mapped, b2_shifted, b2_remapped;
 unsigned char b3_mapped, b3_shifted, b3_remapped;
 unsigned char b4_mapped, b4_shifted, b4_remapped;
 unsigned char b5_shifted, b5_remapped;
 unsigned char *lic_mapbytes;

 lic_mapbytes=calloc(28, 1);
 if (!lic_mapbytes) return(0);
lv1=lv2=0;
 while(lv1 < strlen((unsigned char*)lic_skipped))
 {
    b1_mapped =  codemap_ee00d0[ *(lic_skipped+lv1) - 0x30 ];
    b1_shifted = (b1_mapped / 2) & 0xf;
    b1_remapped = b1_shifted + codemap_20688e[b1_shifted];
    lic_mapbytes[lv2++]=b1_remapped;
    b1_mapped = b1_mapped & 0x1;

    b2_mapped =  codemap_ee00d0[ *(lic_skipped+lv1+1) - 0x30 ];
    b2_shifted =  ((b1_mapped << 0x3) | (b2_mapped / 4)) & 0xF;
    b2_remapped = b2_shifted + codemap_20688e[b2_shifted];
    lic_mapbytes[lv2++]=b2_remapped;

    b3_mapped = codemap_ee00d0[ *(lic_skipped+lv1+2) - 0x30 ];
    b3_shifted = ((b3_mapped / 8) | ( (b2_mapped & 0x3) << 2 )) & 0xF;
    b3_remapped = b3_shifted + codemap_20688e[b3_shifted];
    lic_mapbytes[lv2++]=b3_remapped;

    b4_mapped = codemap_ee00d0[ *(lic_skipped+lv1+3) - 0x30 ];
    b4_shifted = ((b4_mapped / 16 ) |((b3_mapped & 0x7) << 0x1)) & 0xf;
    b4_remapped = b4_shifted + codemap_20688e[b4_shifted];
    lic_mapbytes[lv2++]=b4_remapped;

    b5_shifted = b4_mapped & 0xF;
    b5_remapped = b5_shifted + codemap_20688e[b5_shifted];
    lic_mapbytes[lv2++]=b5_remapped;

    lv1 = lv1 + 4;
  }
  return(lic_mapbytes);
}

unsigned char * find_match5(unsigned char *code5)
{
  unsigned char c1,c2,c3,c4;
  unsigned char *input;
  unsigned char *lic_mapbytes;
  input=calloc(40,1);

  /* lets bruteforce it ;-) */
  for (c1=0;c1<sizeof(vb);c1++) {
   for (c2=0;c2<sizeof(vb);c2++) {
    for (c3=0;c3<sizeof(vb);c3++) {
     for (c4=0;c4<sizeof(vb);c4++) {
      input[0]=vb[c1];
      input[1]=vb[c2];
      input[2]=vb[c3];
      input[3]=vb[c4];
      input[4]='\0';
      lic_mapbytes=lic_code_map(input);
      if (!strcmp(lic_mapbytes, code5))
      {
           return(input);
      }
     }
    }
   }
  }
  return(0); // no match
}

int main(int argc, char *argv[0])
{
 unsigned char *options,*lic1_code, *lic2_code, *lic_all;
 unsigned char *out,*chunk,*temp,*final;
 unsigned char *lic1_key, *lic2_key;
 unsigned char *serial;
 int            v,i=0;

 if (strlen(private_key)<14)
 {
  printf("\n\n");
  printf("set the private_key variable on top of this file\n");
  printf("you can find it here: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg264690/#msg264690\n");
  printf("\n\n");
  exit(-1);
 }

 if (argc != 3)
 {
  show_help();
  exit(-1);
 }
 serial=strtoupper((unsigned char*)argv[1]);
 options=strtoupper((unsigned char*)argv[2]);
 if (strlen(serial)<13)
 {
   printf("\nINVALID SERIAL LENGTH\n");
   show_help();
   exit(-1);
 }
 if (strlen(options)!=4)
 {
   printf("\nINVALID OPTIONS LENGTH\n");
   show_help();
   exit(-1);
 }
printf("serial:           %s\n", serial);
 printf("options:          %s\n", options);
 /* sign the message */
 lic1_code=calloc(64,1);
 lic2_code=calloc(64,1);
 ecssign(serial,options,lic1_code, lic2_code);
 printf("lic1-code:        %s\n", lic1_code);
 printf("lic2-code:        %s\n", lic2_code);

 lic_all=calloc(128,1);
 temp=calloc(128,1);
 chunk=calloc(6,1);
 final=calloc(128,1);
 lic1_key=calloc(20,1);
 lic2_key=calloc(20,1);
 strcpy(lic_all, lic1_code);
 strcat(lic_all, "0");
 strcat(lic_all, lic2_code);
 printf("target-code:      %s\n", lic_all);

 // split in 5 byte groups and run bruteforce
 // run or lic1_code
 strcat(lic1_code,"0");
 while(i<=strlen(lic1_code))
 {
   memcpy(chunk,lic1_code+i,5);
   out=find_match5(chunk);
   if (out)
   {
    strcat(temp, out);
   }
   i=i+5;
 }
 strcpy(lic1_key, temp);

 // run for lic2_code
 strcpy(temp,"");
 i=0;
 while(i<strlen(lic2_code))
 {
   memcpy(chunk,lic2_code+i,5);
   if (strlen(chunk)<5)
   {
    for(v=0;v<5-strlen(chunk);v++)
     strcat(chunk,"0");
   }
   out=find_match5(chunk);
   if (out)
   {
    strcat(temp, out);
   }
   i=i+5;
 }
strcpy(lic2_key, temp);
 strcpy(temp, lic1_key);
 strcat(temp, lic2_key);
 // now add the options
 memcpy(final, temp, 1);
 final[1]=options[0];
 memcpy(final+2, temp+1,7);
 final[9]=options[1];
 memcpy(final+10, temp+8,7);
 final[17]=options[2];
 memcpy(final+18, temp+15,7);
 final[25]=options[3];
 memcpy(final+26, temp+22,4);
 printf("----------------------------------------------------\n");
 printf("your-license-key: ");
 for(i=0;i<strlen(final);i++)
 {
  if (i%7==0 && i>0) printf("-");
  printf("%c", final[i]);
 }
 printf("\n");
 printf("----------------------------------------------------\n");
}

So you can spare the seed field on the GUI...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on July 22, 2013, 09:43:06 pm
DSAZ is perfect - if you can't generate one try a different seed value until you can.  You don't want to use DSA9.
Apparently you have not read to all the posts where the DSAZ is giving problems, but no problem, the tools we have are flexible :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on July 22, 2013, 09:44:19 pm
Here is my current state. There are a few checks and simplifications. For me it works perfectly. Still missing something?

Code: [Select]

/*
** rigol ds2000 keygen / cybernet & the-eevblog-users
 **
 ** to compile this you need MIRACL from [url]https://github.com/CertiVox/MIRACL[/url]
 ** download the master.zip into a new folder and run 'unzip -j -aa -L master.zip'
 ** then run 'bash linux' to build the miracle.a library
 **
 ** BUILD WITH:
 **
 ** gcc rikey.c -I../MIRACL ../MIRACL/miracl.a -o rikey
 **
 ** adapt -I and path to miracl.a to your environment
 **
 ** more info: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/
 **
 ** then fetch private key from EEV Blog and put into "private_key[]=" below, do not prefix with 0x
 ** supply your serial and wanted options, and enjoy !
 **
 **
 */

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <ctype.h>
#include <stdio.h>
#include "miracl.h"

#define RIGOL_DS2000

// START OF SETTINGS FOR ECC
#ifdef RIGOL_DS2000
unsigned char private_key[]="8EEBD4D04C3771";   // <- RILOL FILL ME (no 0x prefix !)
unsigned char prime1[]="AEBF94CEE3E707";
unsigned char prime2[]="AEBF94D5C6AA71";
unsigned char curve_a[]="2982";
unsigned char curve_b[]="3408";
unsigned char point1[]="7A3E808599A525";
unsigned char point2[]="28BE7FAFD2A052";
#endif
// END OF SETTINGS FOR ECC

void show_help(void)
{
  printf("./rikey <DSA2XXXXXXXXX> <OPTS>\n\n");
  printf("<DSA2XXXXXXXXX> -  serial number of device\n");
  printf("<OPTS> - \n");
  printf("\t\tDSA? for permanent options\n");
  printf("\t\tVSA? for temporary options\n");
  printf("\n\n");
}
/*
** take serial and options make sha1 hash out of it
 */
static void hashing(unsigned char *opt_str,big hash)
{ /* compute hash function */
  char *p;
  char h[20];
  int ch;
  sha sh;
  shs_init(&sh);
  p=opt_str;
  while(*p)
  {
    shs_process(&sh,*p);
    p++;
  }
  shs_hash(&sh,h);
  bytes_to_big(20,h,hash);
}

/*
** sign the secret message (serial + opts) with the private key
 */
int ecssign(unsigned char *serial, unsigned char *opt, unsigned char *lic1, unsigned char *lic2)
{
  big a,b,p,q,x,y,d,r,s,k,hash,tmp;
  epoint *g;
  int bits,i,fail;
  miracl *mip;
  unsigned char *serial_options;
  long seed=1;
  int prime2_factors[] = {17, 53, 905461, 60291817    };

  do {
    fail=0;

    /* get public data */
    mip=mirsys(0x320, 0x10);   /* Use Hex internally */
    mip->IOBASE=16;
    a=mirvar(0);
    b=mirvar(0);
    p=mirvar(0);
    q=mirvar(0);
    x=mirvar(0);
    y=mirvar(0);
    d=mirvar(0);
    r=mirvar(0);
    s=mirvar(0);
    k=mirvar(0);
    hash=mirvar(0);

    instr(p,prime1);     /* modulus        */
    instr(a,curve_a);     /* curve parameters */
    instr(b,curve_b);
    instr(q,prime2);     /* order of (x,y) */
    instr(x,point1);     /* (x,y) point on curve of order q */
    instr(y,point2);

    /* randomise */
    irand(seed);

    ecurve_init(a,b,p,MR_PROJECTIVE);  /* initialise curve */
    g=epoint_init();

    if (!epoint_set(x,y,0,g)) /* initialise point of order q */
    {
      printf("1. Problem - point (x,y) is not on the curve\n");
      exit(0);
    }

    /* calculate r - this can be done offline,
     and hence amortized to almost nothing   */
    bigrand(q,k);
    ecurve_mult(k,g,g);      /* see ebrick.c for method to speed this up */
    epoint_get(g,r,r);
    divide(r,q,q);

    /* get private key of signer */
    instr(d, private_key);

    /* calculate message digest */
    serial_options=calloc(128,1);
    strcpy(serial_options, serial);
    strcat(serial_options, opt);
    hashing(serial_options,hash);

    /* calculate s */
    xgcd(k,q,k,k,k);
    mad(d,r,hash,q,q,s);
    mad(s,k,k,q,q,s);

    /* some checks */
    tmp = mirvar(0);
    for (i=0; i < (sizeof(prime2_factors) / sizeof(prime2_factors[0])); i++) {
      lgconv(prime2_factors[i], tmp);
      if (divisible(s, tmp)) fail=1;
      if (divisible(k, tmp)) fail=1;
    }
    if (r==0) fail=1;
    if (s==0) fail=1;
    if (fail) seed++;
  }
  while (fail);

  cotstr(r,lic1);
  cotstr(s,lic2);
  return 0;
}

/*
** convert string to uppercase chars
 */
unsigned char *strtoupper(unsigned char *str)
{
  unsigned char *newstr, *p;
  p = newstr = (unsigned char*) strdup((char*)str);
  while((*p++=toupper(*p)));
  return newstr;
}

void find_match5(unsigned char *io)
{
  unsigned char vb[]={'A','B','C','D','E','F','G','H','J','K','L','M','N','P','Q','R','S','T','U','V','W','X','Y','Z','2','3','4','5','6','7','8','9'};
  unsigned long long b=0;
  int i=0;

  // hex2dez
  while (io[i] != '\0') {
    if (io[i]>='0' && io[i]<='9')
      b=b*16+io[i]-'0';
    else if (io[i]>='A' && io[i]<='F')
      b=b*16+io[i]-'A'+10;
    else if (io[i]>='a' && io[i]<='f')
      b=b*16+io[i]-'a'+10;
    i++;
  }   

  for (i=3;;i--) {
    io[i]=vb[b & 0x1F];
    if (i==0) break;
    b>>=5;
  }
  io[4]='\0';
}

char *strrev(char *str)
{
  char *p1, *p2;

  if (! str || ! *str)
    return str;
  for (p1 = str, p2 = str + strlen(str) - 1; p2 > p1; ++p1, --p2)
  {
    *p1 ^= *p2;
    *p2 ^= *p1;
    *p1 ^= *p2;
  }
  return str;
}

int main(int argc, char *argv[0])
{
  unsigned char *options,*lic1_code, *lic2_code, *lic_all;
  unsigned char *chunk,*temp,*final;
  unsigned char *lic1_key, *lic2_key;
  unsigned char *serial;
  int            v,i=0;

  if (strlen(private_key)<14)
  {
    printf("\n\n");
    printf("set the private_key variable on top of this file\n");
    printf("you can find it here: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg264690/#msg264690\n");
    printf("\n\n");
    exit(-1);
  }

  if (argc != 3)
  {
    show_help();
    exit(-1);
  }
  serial=strtoupper((unsigned char*)argv[1]);
  options=strtoupper((unsigned char*)argv[2]);
  if (strlen(serial)<13)
  {
    printf("\nINVALID SERIAL LENGTH\n");
    show_help();
    exit(-1);
  }
  if (strlen(options)!=4)
  {
    printf("\nINVALID OPTIONS LENGTH\n");
    show_help();
    exit(-1);
  }
  printf("serial:           %s\n", serial);
  printf("options:          %s\n", options);

  /* sign the message */
  lic1_code=calloc(64,1);
  lic2_code=calloc(64,1);
  ecssign(serial,options,lic1_code, lic2_code);

  if (strlen(lic2_code)<14)
  {
    strrev(lic2_code);
    while (strlen(lic2_code)<14) strcat(lic2_code, "0");
    strrev(lic2_code);
  }

  if (strlen(lic1_code)<14)
  {
    strrev(lic1_code);
    while (strlen(lic1_code)<14) strcat(lic1_code, "0");
    strrev(lic1_code);
  }

  printf("lic1-code:        %s\n", lic1_code);
  printf("lic2-code:        %s\n", lic2_code);

  lic_all=calloc(128,1);
  temp=calloc(128,1);
  chunk=calloc(6,1);
  final=calloc(128,1);
  lic1_key=calloc(20,1);
  lic2_key=calloc(20,1);
  strcpy(lic_all, lic1_code);
  strcat(lic_all, "0");
  strcat(lic_all, lic2_code);
  printf("target-code:      %s\n", lic_all);

  // split in 5 byte groups
  i=0;
  while(i<strlen(lic_all))
  {
    memcpy(chunk,lic_all+i,5);
    if (strlen(chunk)<5)
    {
      for(v=0;v<5-strlen(chunk);v++)
        strcat(chunk,"0");
    } 
    find_match5(chunk);
    strcat(temp, chunk);
    i=i+5;
  }

  // now add the options
  memcpy(final, temp, 1);
  final[1]=options[0];
  memcpy(final+2, temp+1,7);
  final[9]=options[1];
  memcpy(final+10, temp+8,7);
  final[17]=options[2];
  memcpy(final+18, temp+15,7);
  final[25]=options[3];
  memcpy(final+26, temp+22,4);
  printf("----------------------------------------------------\n");
  printf("your-license-key: ");
  for(i=0;i<strlen(final);i++)
  {
    if (i%7==0 && i>0) printf("-");
    printf("%c", final[i]);
  }
  printf("\n");
  printf("----------------------------------------------------\n");
}

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: doma on July 22, 2013, 09:50:45 pm
Here is my current state. There are a few checks and simplifications. For me it works perfectly. Still missing something?

Code: [Select]

/*
** rigol ds2000 keygen / cybernet & the-eevblog-users
 **
 ** to compile this you need MIRACL from [url]https://github.com/CertiVox/MIRACL[/url]
 ** download the master.zip into a new folder and run 'unzip -j -aa -L master.zip'
 ** then run 'bash linux' to build the miracle.a library
 **
 ** BUILD WITH:
 **
 ** gcc rikey.c -I../MIRACL ../MIRACL/miracl.a -o rikey
 **
 ** adapt -I and path to miracl.a to your environment
 **
 ** more info: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/
 **
 ** then fetch private key from EEV Blog and put into "private_key[]=" below, do not prefix with 0x
 ** supply your serial and wanted options, and enjoy !
 **
 **
 */

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <ctype.h>
#include <stdio.h>
#include "miracl.h"

#define RIGOL_DS2000

// START OF SETTINGS FOR ECC
#ifdef RIGOL_DS2000
unsigned char private_key[]="8...";   // <- RILOL FILL ME (no 0x prefix !)
unsigned char prime1[]="AEBF94CEE3E707";
unsigned char prime2[]="AEBF94D5C6AA71";
unsigned char curve_a[]="2982";
unsigned char curve_b[]="3408";
unsigned char point1[]="7A3E808599A525";
unsigned char point2[]="28BE7FAFD2A052";
#endif
// END OF SETTINGS FOR ECC

void show_help(void)
{
  printf("./rikey <DSA2XXXXXXXXX> <OPTS>\n\n");
  printf("<DSA2XXXXXXXXX> -  serial number of device\n");
  printf("<OPTS> - \n");
  printf("\t\tDSA? for permanent options\n");
  printf("\t\tVSA? for temporary options\n");
  printf("\n\n");
}
/*
** take serial and options make sha1 hash out of it
 */
static void hashing(unsigned char *opt_str,big hash)
{ /* compute hash function */
  char *p;
  char h[20];
  int ch;
  sha sh;
  shs_init(&sh);
  p=opt_str;
  while(*p)
  {
    shs_process(&sh,*p);
    p++;
  }
  shs_hash(&sh,h);
  bytes_to_big(20,h,hash);
}

/*
** sign the secret message (serial + opts) with the private key
 */
int ecssign(unsigned char *serial, unsigned char *opt, unsigned char *lic1, unsigned char *lic2)
{
  big a,b,p,q,x,y,d,r,s,k,hash,tmp;
  epoint *g;
  int bits,i,fail;
  miracl *mip;
  unsigned char *serial_options;
  long seed=1;
  int prime2_factors[] = {17, 53, 905461, 60291817    };

  do {
    fail=0;

    /* get public data */
    mip=mirsys(0x320, 0x10);   /* Use Hex internally */
    mip->IOBASE=16;
    a=mirvar(0);
    b=mirvar(0);
    p=mirvar(0);
    q=mirvar(0);
    x=mirvar(0);
    y=mirvar(0);
    d=mirvar(0);
    r=mirvar(0);
    s=mirvar(0);
    k=mirvar(0);
    hash=mirvar(0);

    instr(p,prime1);     /* modulus        */
    instr(a,curve_a);     /* curve parameters */
    instr(b,curve_b);
    instr(q,prime2);     /* order of (x,y) */
    instr(x,point1);     /* (x,y) point on curve of order q */
    instr(y,point2);

    /* randomise */
    irand(seed);

    ecurve_init(a,b,p,MR_PROJECTIVE);  /* initialise curve */
    g=epoint_init();

    if (!epoint_set(x,y,0,g)) /* initialise point of order q */
    {
      printf("1. Problem - point (x,y) is not on the curve\n");
      exit(0);
    }

    /* calculate r - this can be done offline,
     and hence amortized to almost nothing   */
    bigrand(q,k);
    ecurve_mult(k,g,g);      /* see ebrick.c for method to speed this up */
    epoint_get(g,r,r);
    divide(r,q,q);

    /* get private key of signer */
    instr(d, private_key);

    /* calculate message digest */
    serial_options=calloc(128,1);
    strcpy(serial_options, serial);
    strcat(serial_options, opt);
    hashing(serial_options,hash);

    /* calculate s */
    xgcd(k,q,k,k,k);
    mad(d,r,hash,q,q,s);
    mad(s,k,k,q,q,s);

    /* some checks */
    tmp = mirvar(0);
    for (i=0; i < (sizeof(prime2_factors) / sizeof(prime2_factors[0])); i++) {
      lgconv(prime2_factors[i], tmp);
      if (divisible(s, tmp)) fail=1;
      if (divisible(k, tmp)) fail=1;
    }
    if (r==0) fail=1;
    if (s==0) fail=1;
    if (fail) seed++;
  }
  while (fail);

  cotstr(r,lic1);
  cotstr(s,lic2);
  return 0;
}

/*
** convert string to uppercase chars
 */
unsigned char *strtoupper(unsigned char *str)
{
  unsigned char *newstr, *p;
  p = newstr = (unsigned char*) strdup((char*)str);
  while((*p++=toupper(*p)));
  return newstr;
}

void find_match5(unsigned char *io)
{
  unsigned char vb[]={'A','B','C','D','E','F','G','H','J','K','L','M','N','P','Q','R','S','T','U','V','W','X','Y','Z','2','3','4','5','6','7','8','9'};
  unsigned long long b=0;
  int i=0;

  // hex2dez
  while (io[i] != '\0') {
    if (io[i]>='0' && io[i]<='9')
      b=b*16+io[i]-'0';
    else if (io[i]>='A' && io[i]<='F')
      b=b*16+io[i]-'A'+10;
    else if (io[i]>='a' && io[i]<='f')
      b=b*16+io[i]-'a'+10;
    i++;
  }   

  for (i=3;;i--) {
    io[i]=vb[b & 0x1F];
    if (i==0) break;
    b>>=5;
  }
  io[4]='\0';
}

char *strrev(char *str)
{
  char *p1, *p2;

  if (! str || ! *str)
    return str;
  for (p1 = str, p2 = str + strlen(str) - 1; p2 > p1; ++p1, --p2)
  {
    *p1 ^= *p2;
    *p2 ^= *p1;
    *p1 ^= *p2;
  }
  return str;
}

int main(int argc, char *argv[0])
{
  unsigned char *options,*lic1_code, *lic2_code, *lic_all;
  unsigned char *chunk,*temp,*final;
  unsigned char *lic1_key, *lic2_key;
  unsigned char *serial;
  int            v,i=0;

  if (strlen(private_key)<14)
  {
    printf("\n\n");
    printf("set the private_key variable on top of this file\n");
    printf("you can find it here: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg264690/#msg264690\n");
    printf("\n\n");
    exit(-1);
  }

  if (argc != 3)
  {
    show_help();
    exit(-1);
  }
  serial=strtoupper((unsigned char*)argv[1]);
  options=strtoupper((unsigned char*)argv[2]);
  if (strlen(serial)<13)
  {
    printf("\nINVALID SERIAL LENGTH\n");
    show_help();
    exit(-1);
  }
  if (strlen(options)!=4)
  {
    printf("\nINVALID OPTIONS LENGTH\n");
    show_help();
    exit(-1);
  }
  printf("serial:           %s\n", serial);
  printf("options:          %s\n", options);

  /* sign the message */
  lic1_code=calloc(64,1);
  lic2_code=calloc(64,1);
  ecssign(serial,options,lic1_code, lic2_code);

  if (strlen(lic2_code)<14)
  {
    strrev(lic2_code);
    while (strlen(lic2_code)<14) strcat(lic2_code, "0");
    strrev(lic2_code);
  }

  if (strlen(lic1_code)<14)
  {
    strrev(lic1_code);
    while (strlen(lic1_code)<14) strcat(lic1_code, "0");
    strrev(lic1_code);
  }

  printf("lic1-code:        %s\n", lic1_code);
  printf("lic2-code:        %s\n", lic2_code);

  lic_all=calloc(128,1);
  temp=calloc(128,1);
  chunk=calloc(6,1);
  final=calloc(128,1);
  lic1_key=calloc(20,1);
  lic2_key=calloc(20,1);
  strcpy(lic_all, lic1_code);
  strcat(lic_all, "0");
  strcat(lic_all, lic2_code);
  printf("target-code:      %s\n", lic_all);

  // split in 5 byte groups
  i=0;
  while(i<strlen(lic_all))
  {
    memcpy(chunk,lic_all+i,5);
    if (strlen(chunk)<5)
    {
      for(v=0;v<5-strlen(chunk);v++)
        strcat(chunk,"0");
    } 
    find_match5(chunk);
    strcat(temp, chunk);
    i=i+5;
  }

  // now add the options
  memcpy(final, temp, 1);
  final[1]=options[0];
  memcpy(final+2, temp+1,7);
  final[9]=options[1];
  memcpy(final+10, temp+8,7);
  final[17]=options[2];
  memcpy(final+18, temp+15,7);
  final[25]=options[3];
  memcpy(final+26, temp+22,4);
  printf("----------------------------------------------------\n");
  printf("your-license-key: ");
  for(i=0;i<strlen(final);i++)
  {
    if (i%7==0 && i>0) printf("-");
    printf("%c", final[i]);
  }
  printf("\n");
  printf("----------------------------------------------------\n");
}


1.) I'd use srand instead of irand  and add srand(++seed) instead - as per the manual it should not work at all like this as irand will always use a seed of 1 if no srand is called :)
2.) You could put "break;"s in the check cycle to save some CPU
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on July 22, 2013, 10:22:01 pm
Apparently you have not read to all the posts where the DSAZ is giving problems, but no problem, the tools we have are flexible :)

I think that codes that are failing because of a seed issue.  Keep trying DSAZ with new seeds until a good code is found.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Maalobs on July 22, 2013, 10:52:24 pm
Here's the generator code amended with "some guy"'s recommendation. Now it generates a VALID code for me w/o manually fiddling around with the seed.

So you can spare the seed field on the GUI...

Great work, the math problem was beyond me, but you didn't take into account preceding zeros in lic1 or lic2, which must be nullpadded to keep those variables at 14 characters long each.
I've added it to your code here:
Code: [Select]
/*
** rigol ds2000 keygen / cybernet & the-eevblog-users
**
** to compile this you need MIRACL from [url]https://github.com/CertiVox/MIRACL[/url]
** download the master.zip into a new folder and run 'unzip -j -aa -L master.zip'
** then run 'bash linux' to build the miracle.a library
**
** BUILD WITH:
**
** gcc rikey.c -I../MIRACL ../MIRACL/miracl.a -o rikey
**
** adapt -I and path to miracl.a to your environment
**
** more info: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/
**
** then fetch private key from EEV Blog and put into "private_key[]=" below, do not prefix with 0x
** supply your serial and wanted options, and enjoy !
**
**
*/

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <ctype.h>
#include <stdio.h>
#include "miracl.h"

#define RIGOL_DS2000

// START OF SETTINGS FOR ECC
#ifdef RIGOL_DS2000
 unsigned char private_key[]="8...";   // <- RILOL FILL ME (no 0x prefix !)
 unsigned char prime1[]="AEBF94CEE3E707";
 unsigned char prime2[]="AEBF94D5C6AA71";
 unsigned char curve_a[]="2982";
 unsigned char curve_b[]="3408";
 unsigned char point1[]="7A3E808599A525";
 unsigned char point2[]="28BE7FAFD2A052";
#endif
// END OF SETTINGS FOR ECC

unsigned char codemap_ee00d0[]={ 0x0, 0x0, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f,
                                 0x0, 0x0, 0x0,  0x0,  0x0,  0x0,  0x0,  0x0,  0x1,  0x2,
                                 0x3, 0x4, 0x5,  0x6,  0x7,  0x0,  0x8,  0x9,  0xa,  0xb,
                                 0xc, 0x0, 0xd,  0xe,  0xf,  0x10, 0x11, 0x12, 0x13, 0x14,
                                 0x15,0x16, 0x17 };

unsigned char codemap_20688e[]={ 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30,  /* 0-9 = 0x30 */
                                 0x37, 0x37, 0x37, 0x37, 0x37, 0x37 };                        /* A-F = 0x37 */


unsigned char vb[]={'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'J', 'K', 'L', 'M', 'N', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', '2', '3', '4', '5', '6', '7', '8', '9'};

void show_help(void)
{
 printf("./rikey <DSA2XXXXXXXXX> <OPTS>\n\n");
 printf("<DSA2XXXXXXXXX> -  serial number of device\n");
 printf("<OPTS> - \n");
 printf("\t\tDSA? for permanent options\n");
 printf("\t\tVSA? for temporary options\n");
 printf("\n\n");
}
/*
** take serial and options make sha1 hash out of it
*/
static void hashing(unsigned char *opt_str,big hash)
{ /* compute hash function */
    char *p;
    char h[20];
    int ch;
    sha sh;
    shs_init(&sh);
    p=opt_str;
    while(*p)
    {
       shs_process(&sh,*p);
       p++;
    }
    shs_hash(&sh,h);
    bytes_to_big(20,h,hash);
}
/*
** sign the secret message (serial + opts) with the private key
*/
int ecssign(unsigned char *serial, unsigned char *opt, unsigned char *lic1, unsigned char *lic2)
{
    FILE *fp;
    char ifname[50],ofname[50];
    big a,b,p,q,x,y,d,r,s,k,hash,temps;
    epoint *g;
    long seed;
    int bits;
    miracl *mip;
    unsigned char *serial_options;
/* Support variables for checking against divisibility */
    int prime2_factors[] = {17, 53, 905461, 60291817};
    int i;
    int passed;
    big tmp;

    /* randomise */
    seed=1;
    srand(seed);

    do {
passed = 1;
    /* get public data */
mip=mirsys(0x320, 0x10);   /* Use Hex internally */
mip->IOBASE=16;
a=mirvar(0);
b=mirvar(0);
p=mirvar(0);
q=mirvar(0);
x=mirvar(0);
y=mirvar(0);
d=mirvar(0);
r=mirvar(0);
s=mirvar(0);
k=mirvar(0);
hash=mirvar(0);

instr(p,prime1);     /* modulus        */
instr(a,curve_a);     /* curve parameters */
instr(b,curve_b);
instr(q,prime2);     /* order of (x,y) */
instr(x,point1);     /* (x,y) point on curve of order q */
instr(y,point2);


ecurve_init(a,b,p,MR_PROJECTIVE);  /* initialise curve */
g=epoint_init();

if (!epoint_set(x,y,0,g)) /* initialise point of order q */
{
     printf("1. Problem - point (x,y) is not on the curve\n");
     exit(0);
}

    /* calculate r - this can be done offline,
      and hence amortized to almost nothing   */
bigrand(q,k);
ecurve_mult(k,g,g);      /* see ebrick.c for method to speed this up */
epoint_get(g,r,r);
divide(r,q,q);

    /* get private key of signer */
instr(d, private_key);

    /* calculate message digest */
serial_options=calloc(128,1);
strcpy(serial_options, serial);
strcat(serial_options, opt);
hashing(serial_options,hash);

    /* calculate s */
xgcd(k,q,k,k,k);
mad(d,r,hash,q,q,s);
mad(s,k,k,q,q,s);

    /* check if we got a valid lic2 (s) */
tmp = mirvar(0);
for (i = 0; i < (sizeof(prime2_factors) / sizeof(prime2_factors[0])); i++) {
     lgconv(prime2_factors[i], tmp);
     if (divisible(s, tmp)) {
     passed = 0;
     srand(++seed);
            break;
     }
}
   } while (!passed);

    cotstr(r,lic1);
    cotstr(s,lic2);

    return 0;
}


/*
** convert string to uppercase chars
*/
unsigned char *strtoupper(unsigned char *str)
{
    unsigned char *newstr, *p;
    p = newstr = (unsigned char*) strdup((char*)str);
    while((*p++=toupper(*p)));
    return newstr;
}

/*
**
*/
unsigned char code_map_206846(unsigned char i)
{
 if ((i >= 'A') && (i <= 'F')) return(i-0x37);
 if ((i >= '0') && (i <= '9')) return(i-0x30);
 return(0x0);
}

/*
** Encryption Routine 1
*/
unsigned char *lic_code_map(unsigned char *lic_skipped)
{
 unsigned char lv1,lv2;
 unsigned char b1_mapped, b1_shifted, b1_remapped;
 unsigned char b2_mapped, b2_shifted, b2_remapped;
 unsigned char b3_mapped, b3_shifted, b3_remapped;
 unsigned char b4_mapped, b4_shifted, b4_remapped;
 unsigned char b5_shifted, b5_remapped;
 unsigned char *lic_mapbytes;

 lic_mapbytes=calloc(28, 1);
 if (!lic_mapbytes) return(0);
lv1=lv2=0;
 while(lv1 < strlen((unsigned char*)lic_skipped))
 {
    b1_mapped =  codemap_ee00d0[ *(lic_skipped+lv1) - 0x30 ];
    b1_shifted = (b1_mapped / 2) & 0xf;
    b1_remapped = b1_shifted + codemap_20688e[b1_shifted];
    lic_mapbytes[lv2++]=b1_remapped;
    b1_mapped = b1_mapped & 0x1;

    b2_mapped =  codemap_ee00d0[ *(lic_skipped+lv1+1) - 0x30 ];
    b2_shifted =  ((b1_mapped << 0x3) | (b2_mapped / 4)) & 0xF;
    b2_remapped = b2_shifted + codemap_20688e[b2_shifted];
    lic_mapbytes[lv2++]=b2_remapped;

    b3_mapped = codemap_ee00d0[ *(lic_skipped+lv1+2) - 0x30 ];
    b3_shifted = ((b3_mapped / 8) | ( (b2_mapped & 0x3) << 2 )) & 0xF;
    b3_remapped = b3_shifted + codemap_20688e[b3_shifted];
    lic_mapbytes[lv2++]=b3_remapped;

    b4_mapped = codemap_ee00d0[ *(lic_skipped+lv1+3) - 0x30 ];
    b4_shifted = ((b4_mapped / 16 ) |((b3_mapped & 0x7) << 0x1)) & 0xf;
    b4_remapped = b4_shifted + codemap_20688e[b4_shifted];
    lic_mapbytes[lv2++]=b4_remapped;

    b5_shifted = b4_mapped & 0xF;
    b5_remapped = b5_shifted + codemap_20688e[b5_shifted];
    lic_mapbytes[lv2++]=b5_remapped;

    lv1 = lv1 + 4;
  }
  return(lic_mapbytes);
}

unsigned char * find_match5(unsigned char *code5)
{
  unsigned char c1,c2,c3,c4;
  unsigned char *input;
  unsigned char *lic_mapbytes;
  input=calloc(40,1);

  /* lets bruteforce it ;-) */
  for (c1=0;c1<sizeof(vb);c1++) {
   for (c2=0;c2<sizeof(vb);c2++) {
    for (c3=0;c3<sizeof(vb);c3++) {
     for (c4=0;c4<sizeof(vb);c4++) {
      input[0]=vb[c1];
      input[1]=vb[c2];
      input[2]=vb[c3];
      input[3]=vb[c4];
      input[4]='\0';
      lic_mapbytes=lic_code_map(input);
      if (!strcmp(lic_mapbytes, code5))
      {
           return(input);
      }
     }
    }
   }
  }
  return(0); // no match
}

char *strrev(char *str)
{
      char *p1, *p2;

      if (! str || ! *str)
            return str;
      for (p1 = str, p2 = str + strlen(str) - 1; p2 > p1; ++p1, --p2)
      {
            *p1 ^= *p2;
            *p2 ^= *p1;
            *p1 ^= *p2;
      }
      return str;
}

int main(int argc, char *argv[0])
{
 unsigned char *options,*lic1_code, *lic2_code, *lic_all;
 unsigned char *out,*chunk,*temp,*final;
 unsigned char *lic1_key, *lic2_key;
 unsigned char *serial;
 int            v,i=0;

 if (strlen(private_key)<14)
 {
  printf("\n\n");
  printf("set the private_key variable on top of this file\n");
  printf("you can find it here: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg264690/#msg264690\n");
  printf("\n\n");
  exit(-1);
 }

 if (argc != 3)
 {
  show_help();
  exit(-1);
 }
 serial=strtoupper((unsigned char*)argv[1]);
 options=strtoupper((unsigned char*)argv[2]);
 if (strlen(serial)<13)
 {
   printf("\nINVALID SERIAL LENGTH\n");
   show_help();
   exit(-1);
 }
 if (strlen(options)!=4)
 {
   printf("\nINVALID OPTIONS LENGTH\n");
   show_help();
   exit(-1);
 }
printf("serial:           %s\n", serial);
 printf("options:          %s\n", options);
 /* sign the message */
 lic1_code=calloc(64,1);
 lic2_code=calloc(64,1);
 ecssign(serial,options,lic1_code, lic2_code);

 int diff1 = 14 - strlen(lic1_code);
 while(diff1 > 0) {
  strrev(lic1_code);
  strcat(lic1_code, "0");
  strrev(lic1_code);
  diff1--;
 }

 int diff2 = 14 - strlen(lic2_code);
 while(diff2 > 0) {
  strrev(lic2_code);
  strcat(lic2_code, "0");
  strrev(lic2_code);
  diff2--;
 }

 printf("lic1-code:        %s\n", lic1_code);
 printf("lic2-code:        %s\n", lic2_code);

 lic_all=calloc(128,1);
 temp=calloc(128,1);
 chunk=calloc(6,1);
 final=calloc(128,1);
 lic1_key=calloc(20,1);
 lic2_key=calloc(20,1);
 strcpy(lic_all, lic1_code);
 strcat(lic_all, "0");
 strcat(lic_all, lic2_code);
 printf("target-code:      %s\n", lic_all);

 // split in 5 byte groups and run bruteforce
 // run or lic1_code
 strcat(lic1_code,"0");
 while(i<=strlen(lic1_code))
 {
   memcpy(chunk,lic1_code+i,5);
   out=find_match5(chunk);
   if (out)
   {
    strcat(temp, out);
   }
   i=i+5;
 }
 strcpy(lic1_key, temp);

 // run for lic2_code
 strcpy(temp,"");
 i=0;
 while(i<strlen(lic2_code))
 {
   memcpy(chunk,lic2_code+i,5);
   if (strlen(chunk)<5)
   {
    for(v=0;v<5-strlen(chunk);v++)
     strcat(chunk,"0");
   }
   out=find_match5(chunk);
   if (out)
   {
    strcat(temp, out);
   }
   i=i+5;
 }
strcpy(lic2_key, temp);
 strcpy(temp, lic1_key);
 strcat(temp, lic2_key);
 // now add the options
 memcpy(final, temp, 1);
 final[1]=options[0];
 memcpy(final+2, temp+1,7);
 final[9]=options[1];
 memcpy(final+10, temp+8,7);
 final[17]=options[2];
 memcpy(final+18, temp+15,7);
 final[25]=options[3];
 memcpy(final+26, temp+22,4);
 printf("----------------------------------------------------\n");
 printf("your-license-key: ");
 for(i=0;i<strlen(final);i++)
 {
  if (i%7==0 && i>0) printf("-");
  printf("%c", final[i]);
 }
 printf("\n");
 printf("----------------------------------------------------\n");
}
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Maalobs on July 22, 2013, 11:03:05 pm
DSAZ is perfect - if you can't generate one try a different seed value until you can.  You don't want to use DSA9.
Apparently you have not read to all the posts where the DSAZ is giving problems, but no problem, the tools we have are flexible :)
I think you are focusing on the wrong detail; Using DSA9 is what has resulted in an invalid state in the scope for some people, which in turn resulted in the serialnumbers getting mangled for them.
DSAZ just had a math problem in rikey.c that triggered on some serialnumbers (which may have been fixed now by doma and "some guy"), it had no effect at all on the scopes (as I understood it the license codes weren't even accepted by the scopes, so no effect was possible).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on July 22, 2013, 11:16:51 pm
Too much code fragmentation  |O

Need to get the best parts all put together, maybe I will do this too when I get home
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: UberSteve on July 23, 2013, 12:36:57 am
Too much code fragmentation  |O

Need to get the best parts all put together, maybe I will do this too when I get home

Maybe worth sticking it on GitHub? (Or perhaps that might violate their policies?)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bluesmoke on July 23, 2013, 12:39:22 am
Quote
I think you are focusing on the wrong detail; Using DSA9 is what has resulted in an invalid state in the scope for some people, which in turn resulted in the serialnumbers getting mangled for them.

Actually it was a DSAZ code that locked up my scope on reboot and reset the serial to 1.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: UberSteve on July 23, 2013, 12:40:53 am
DSAZ is perfect - if you can't generate one try a different seed value until you can.  You don't want to use DSA9.
Apparently you have not read to all the posts where the DSAZ is giving problems, but no problem, the tools we have are flexible :)
I think you are focusing on the wrong detail; Using DSA9 is what has resulted in an invalid state in the scope for some people, which in turn resulted in the serialnumbers getting mangled for them.
DSAZ just had a math problem in rikey.c that triggered on some serialnumbers (which may have been fixed now by doma and "some guy"), it had no effect at all on the scopes (as I understood it the license codes weren't even accepted by the scopes, so no effect was possible).

This is my general feeling as well. The reports of serial numbers getting hosed, etc are a little concerning. Assuming the feature table posted earlier is correct, DSAZ would seem to be more "valid" than DSA9.

I used the DSAZ code on my brand new DS2072 (came with latest fw) and it worked perfectly, serial remained, etc.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: UberSteve on July 23, 2013, 12:42:32 am
Quote
I think you are focusing on the wrong detail; Using DSA9 is what has resulted in an invalid state in the scope for some people, which in turn resulted in the serialnumbers getting mangled for them.

Actually it was a DSAZ code that locked up my scope on reboot and reset the serial to 1.

Hmm, well that blows my theory out of the water. Perhaps it was the combination of using the DSAZ code and other previous codes you may(?) have used?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on July 23, 2013, 12:43:13 am
Quote
I think you are focusing on the wrong detail; Using DSA9 is what has resulted in an invalid state in the scope for some people, which in turn resulted in the serialnumbers getting mangled for them.

Actually it was a DSAZ code that locked up my scope on reboot and reset the serial to 1.

The test DSAZ code (LLLLLLL) or a generated DSAZ code?

What FW did you have at the time?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Uup on July 23, 2013, 12:56:30 am
I tried the DSAZ code and the generated licence didn't work on my DS4024.

However, the temporary options key (LLLLLLL-RLGLLDS-DSH9LLL-LLLLLLL) worked. So I tried generating a key with DSH9 and it worked! I have 5 official options now  :)

Serial number is unchanged and options hold after a power cycle. I wonder if it would be possible to increase the bandwidth to 500MHz...   ;D

Thanks guys for the truly awesome work!  :-+

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: BravoV on July 23, 2013, 01:12:32 am
Damn, so this works also at DS4xxx series, great news.  :clap:

Edit : Fyi, I keep saving the offline version of this whole thread, just in case Dave received a cease & desist love letter from Rigol's lawyer.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bluesmoke on July 23, 2013, 01:20:30 am
Quote
Quote from: bluesmoke on Today at 10:39:22 AM

    Quote

        I think you are focusing on the wrong detail; Using DSA9 is what has resulted in an invalid state in the scope for some people, which in turn resulted in the serialnumbers getting mangled for them.


    Actually it was a DSAZ code that locked up my scope on reboot and reset the serial to 1.

Quote
The test DSAZ code (LLLLLLL) or a generated DSAZ code?

What FW did you have at the time?

It was a code generated from my serial... firmware 00.01.00.05
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on July 23, 2013, 01:22:48 am
firmware 00.01.00.05

I think the FW05 is the issue.  I don't advise anyone with FW05 to enter any codes until they upgrade.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on July 23, 2013, 03:44:23 am
Too much code fragmentation  |O

Need to get the best parts all put together, maybe I will do this too when I get home

Maybe worth sticking it on GitHub? (Or perhaps that might violate their policies?)

Not Github, but somewhere.

Anyway here's a cleaned up version, with more verbose help - do you like it? Beautified, fixes bugs (license padding, lic2 prime check, no brute-force). Adds optional run-time requirement for the private key (if not compiled with it, it is required).

EDIT: the single downloader, minor bug! you don't need to redownload, but if you want to send it to others, send this version.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: grego on July 23, 2013, 03:50:19 am
Damn, so this works also at DS4xxx series, great news.  :clap:

Edit : Fyi, I keep saving the offline version of this whole thread, just in case Dave received a cease & desist love letter from Rigol's lawyer.

Seriously?  Confirmed to work on the 4000 series too?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: BravoV on July 23, 2013, 03:53:44 am
Damn, so this works also at DS4xxx series, great news.  :clap:

Edit : Fyi, I keep saving the offline version of this whole thread, just in case Dave received a cease & desist love letter from Rigol's lawyer.

Seriously?  Confirmed to work on the 4000 series too?

One post above me, here re-quoting the photo, it says DS4024.

(https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/?action=dlattach;attach=55608;image)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on July 23, 2013, 04:00:41 am
One post above me, here re-quoting the photo, it says DS4024.
(https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/?action=dlattach;attach=55608;image)
DSA9? Oh wait, I read, DSH9. I'll note that on the webgen.

----

I've updated the webgenerator with the new version so keys should work better. Also have a DS4K version (same thing but you enter you own option characters).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Uup on July 23, 2013, 04:59:56 am
Yes, DSH9 is correct.

I used the last code that cybernet asked DS4k owners to try, in post #259 back on page 18 of this thread. Although he indicates that DSH9 is for 8 options but it actually enables 5 options. I think there are currently only 5 "official" options for the DS4k.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: roli_bark on July 23, 2013, 05:11:36 am
Nice !,
What about the DS4024 500mhz BW option ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Uup on July 23, 2013, 05:29:46 am
Nice !,
What about the DS4024 500mhz BW option ?

I was thinking the same thing. I'm going to experiment with different codes and see if it's possible.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ve7xen on July 23, 2013, 06:34:10 am
Edit : Fyi, I keep saving the offline version of this whole thread, just in case Dave received a cease & desist love letter from Rigol's lawyer.
I've also been mirroring the key files/information at http://www.gotroot.ca/rigol/ (http://www.gotroot.ca/rigol/)

I have also built binaries of true's latest source for i386 and x86_64 Linux and placed them there also, if anyone is too lazy to build it themselves. (And geeze, can't take MIRACL seriously. A crypto library that doesn't even use a Makefile??)

Thanks to everyone that's contributed to this reversing. This is a triumph!  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tinhead on July 23, 2013, 08:18:10 am
time for DSA815?  >:D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mickpah on July 23, 2013, 08:27:25 am
I thought I had this fixed last night , but no.
I have a 2072 now stuck as a 2202, not so bad, original trial licenses still active, but no way any of the key gens seem to work for me.
It is a 13 character serial if this makes a difference.
compiled code myself, ran precompiled incase I couldn't follow simple instructions
getting a bit beyond frustrated now  |O
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: UberSteve on July 23, 2013, 08:50:39 am
getting a bit beyond frustrated now  |O

What firmware are you running? Maybe try upgrading to the latest, if not already running it?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mickpah on July 23, 2013, 08:53:53 am
getting a bit beyond frustrated now  |O

What firmware are you running? Maybe try upgrading to the latest, if not already running it?
yep did that, rolled back two versions and forward again. no change.

just get this when sending the keys with scpi usb or lan

 * Error£¡£¡£¡
VISA:  (Hex 0xBFFF0015) Timeout expired before operation completed.
-> :SYSTem:OPTion:INSTall 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ve7xen on July 23, 2013, 09:04:43 am
The scope will ignore a key if you leave the '-' in there. It should just be the string of characters, if you send via SCPI.

You should get either an Option Installed or some error message on screen shortly after.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Maalobs on July 23, 2013, 09:12:02 am
Or use the on-screen keyboard on the scope to enter your license code, it's actually quite fast to use.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mickpah on July 23, 2013, 09:22:26 am
thanks all, yes I was dropping the  - and even tried via the screen, in the end it worked.
I used a new seed with every attempt, not sure if I struck a lucky seed ?
Bottom line - I'm now  a happy camper, could feel myself getting all OCD.
Now to void the warranty on my DP831 - I haven't seen any internal pic anywhere yet. Really hoping that is blackfin based too..  >:D
Hirez and lan world be nice
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mklimasz on July 23, 2013, 09:28:34 am
I'd like to confirm the gen (Windows version) works perfectly - entered keys via screen, now my 2072 is permanently transformed into 2202 with options installed. Great work!  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on July 23, 2013, 11:46:09 am
I've also been mirroring the key files/information at http://www.gotroot.ca/rigol/ (http://www.gotroot.ca/rigol/)

I love it, it is so much more compact and less confusing.  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Uup on July 23, 2013, 12:35:24 pm
I've also been mirroring the key files/information at http://www.gotroot.ca/rigol/ (http://www.gotroot.ca/rigol/)


It's great to have all that info in the one place for easy access, thanks!  :-+

However, some of the zip files are corrupt... (dstool.zip, RiGen-1.zip, ScopeCommander.zip)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tinhead on July 23, 2013, 12:43:27 pm
However, some of the zip files are corrupt... (dstool.zip, RiGen-1.zip, ScopeCommander.zip)

no, they not
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: roli_bark on July 23, 2013, 12:43:28 pm
Also, I speculate that the keys.txt is different for the DS40xx line.

For example - there's no Mem option - they come all the same - , but there should be 100/200/350/500mhz options.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: XaS on July 23, 2013, 12:46:08 pm
Thank you guys, this is just awesome! I can confirm that the Win GUI (I was lazy this morning  ;) ) worked perfectly on my 2072 with 00.01.00.05. After updating to 01.01.00.02 the options are still enabled. (I didn't try to upgrade to an 2202 yet.)

MfG XaS
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on July 23, 2013, 12:54:40 pm
Wow, I haven't been following this post, but it looks like it might be awesome! So has there been a key generator built for the DSA815? Or does this only work with the DS2000 oscilloscopes?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: colinbeeforth on July 23, 2013, 01:31:25 pm
I had the same experience as Xas, my DS2072 is now far more interesting. Congratulations to those who contributed, you have my gratitude and total admiration for such incredible sleuthing skills.  Brilliant work!

I'll be able to retire my old LeCroy 9310A, I have a reasonable alternative now.

Cheers, Colin
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DL5TOR on July 23, 2013, 01:41:55 pm
Wow, I haven't been following this post, but it looks like it might be awesome! So has there been a key generator built for the DSA815? Or does this only work with the DS2000 oscilloscopes?

As of right now there is no implemetion for the DSA815. But I am working on it
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: metalphreak on July 23, 2013, 02:03:20 pm
Also, I speculate that the keys.txt is different for the DS40xx line.

For example - there's no Mem option - they come all the same - , but there should be 100/200/350/500mhz options.

Has anyone confirmed that all the bandwidth variations of the DS4000 series have the same internals? I wouldn't be surprised if the 350/500mhz models have a different front end to the 100/200mhz models.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: roli_bark on July 23, 2013, 02:26:11 pm
See here:
https://www.eevblog.com/forum/reviews/rigol-ds4014-decided-it-would-be-more-fun-to-be-a-ds4054/

Hench,  it looks like it's the same HW.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Uup on July 23, 2013, 02:48:20 pm
However, some of the zip files are corrupt... (dstool.zip, RiGen-1.zip, ScopeCommander.zip)

no, they not

Really?  :-//

I just tried again now, from a different computer this time as well. Same result, get an 'unexpected error in archive' message when trying to unzip those files.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on July 23, 2013, 02:51:06 pm
Here is optimized signing function with all necessary checks for valid signature generation:

Code: [Select]
char private_key[] = "8..."; <-- fill with valid key
char prime1[] = "AEBF94CEE3E707";
char prime2[] = "AEBF94D5C6AA71";
char curve_a[] = "2982";
char curve_b[] = "3408";
char point1[] = "7A3E808599A525";
char point2[] = "28BE7FAFD2A052";

void ecssign(char *serial, char *options, char *lic1, char *lic2)
{
    mirsys(800, 16)->IOBASE = 16;

    sha sha1;
    shs_init(&sha1);
    char *ptr = serial;
    while(*ptr) shs_process(&sha1, *ptr++);
    ptr = options;
    while(*ptr) shs_process(&sha1, *ptr++);
    char h[20];
    shs_hash(&sha1, h);
    big hash = mirvar(0);
    bytes_to_big(20, h, hash);

    big a = mirvar(0);  instr(a, curve_a);
    big b = mirvar(0);  instr(b, curve_b);
    big p = mirvar(0);  instr(p, prime1);
    big q = mirvar(0);  instr(q, prime2);
    big Gx = mirvar(0); instr(Gx, point1);
    big Gy = mirvar(0); instr(Gy, point2);
    big d = mirvar(0);  instr(d, private_key);
    big k = mirvar(0);
    big r = mirvar(0);
    big s = mirvar(0);
    big k1 = mirvar(0);
    big zero = mirvar(0);

    big f1 = mirvar(17);
    big f2 = mirvar(53);
    big f3 = mirvar(905461);
    big f4 = mirvar(60291817);

    epoint *G = epoint_init();
    epoint *kG = epoint_init();
    ecurve_init(a, b, p, MR_PROJECTIVE);
    epoint_set(Gx, Gy, 0, G);

    for(;;)
    {
        incr(k, 1, k);

        if(divisible(k, f1) || divisible(k, f2) || divisible(k, f3) || divisible(k, f4))
            continue;

        ecurve_mult(k, G, kG);
        epoint_get(kG, r, r);
        divide(r, q, q);
       
        if(mr_compare(r, zero) == 0)
            continue;

        xgcd(k, q, k1, k1, k1);
        mad(d, r, hash, q, q, s);
        mad(s, k1, k1, q, q, s);

        if(!divisible(s, f1) && !divisible(s, f2) && !divisible(s, f3) && !divisible(s, f4))
            break;
    }

    cotstr(r, lic1);
    cotstr(s, lic2);
}
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 23, 2013, 02:53:30 pm
Wow, I haven't been following this post, but it looks like it might be awesome! So has there been a key generator built for the DSA815? Or does this only work with the DS2000 oscilloscopes?

As of right now there is no implemetion for the DSA815. But I am working on it

do you see the ECC parameters in the DSA firmware ? in gel DS2 GEL file its as easy as "strings file|grep ..."
ps: the algo that takes the license string input and converts it to HEX - is more capable than the way its used on the DS2 ... e.g. all kinds of special chars - but i only implemented /reversed what i saw being used by the DS2k.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: synapsis on July 23, 2013, 02:57:28 pm
To help some people out, the MD5 for the Windows app I released (RiGen-1.zip) is:

e5165fee6155ceb9d8cae6176acf4c37
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on July 23, 2013, 03:29:21 pm
Here is my current state. There are a few checks and simplifications. For me it works perfectly. Still missing something?

Code: [Select]
    [...]
    if (r==0) fail=1;
    if (s==0) fail=1;
    [...]

This check won't work - r and s are pointers, so this code checks whether they are NULLs, but doesn't check if their values are equal to zero
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DL5TOR on July 23, 2013, 03:44:22 pm
Wow, I haven't been following this post, but it looks like it might be awesome! So has there been a key generator built for the DSA815? Or does this only work with the DS2000 oscilloscopes?

As of right now there is no implemetion for the DSA815. But I am working on it

do you see the ECC parameters in the DSA firmware ? in gel DS2 GEL file its as easy as "strings file|grep ..."
ps: the algo that takes the license string input and converts it to HEX - is more capable than the way its used on the DS2 ... e.g. all kinds of special chars - but i only implemented /reversed what i saw being used by the DS2k.

That is the point. I can not find them. Also on thwe dsa815 the updatefile is not a gel file it is a sys file that will not load in ida with the gel-plugin.

One thing i did find is that the option is marked as 000# and if i use the segments from the key that i have i get aaab
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on July 23, 2013, 03:54:37 pm
Quote
you see the ECC parameters in the DSA firmware ? in gel DS2 GEL file its as easy as "strings file|grep ..."
ps: the algo that takes the license string input and converts it to HEX - is more capable than the way its used on the DS2 ... e.g. all kinds of special chars - but i only implemented /reversed what i saw being used by the DS2k.

What do these parameters look like (example)? What are you grepping for? Could viewing the .sys file in a hex editor be the key to this one?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ve7xen on July 23, 2013, 04:04:09 pm
Really?  :-//

I just tried again now, from a different computer this time as well. Same result, get an 'unexpected error in archive' message when trying to unzip those files.
Pretty sure you're doing something wrong:

Code: [Select]
$> md5sum RiGen-1.zip
e5165fee6155ceb9d8cae6176acf4c37  RiGen-1.zip
$> unzip -t RiGen-1.zip
Archive:  RiGen-1.zip
    testing: dotNetFx40_Full_setup.exe   OK
    testing: miracl.lib               OK
    testing: msvcp100.dll             OK
    testing: msvcr100.dll             OK
    testing: RiGen.exe                OK
No errors detected in compressed data of RiGen-1.zip.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on July 23, 2013, 04:04:34 pm
Here is my current state. There are a few checks and simplifications. For me it works perfectly. Still missing something?

Code: [Select]
    [...]
    xgcd(k,q,k,k,k);
    [...]
      if (divisible(k, tmp)) fail=1;
    [...]

There is another problem - original value of k gets destroyed during xgcd(...) call, so divisibility check should be done before this call (take a look at my code a few posts above).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DL5TOR on July 23, 2013, 04:30:55 pm
Quote
you see the ECC parameters in the DSA firmware ? in gel DS2 GEL file its as easy as "strings file|grep ..."
ps: the algo that takes the license string input and converts it to HEX - is more capable than the way its used on the DS2 ... e.g. all kinds of special chars - but i only implemented /reversed what i saw being used by the DS2k.

What do these parameters look like (example)? What are you grepping for? Could viewing the .sys file in a hex editor be the key to this one?

I did just that i opend the sys file in a hex editor and did a serch for the keys that are used  in the ds20000 with no result. One  thing that is poitive is that the mcu is the same
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on July 23, 2013, 04:47:05 pm
Quote
you see the ECC parameters in the DSA firmware ? in gel DS2 GEL file its as easy as "strings file|grep ..."
ps: the algo that takes the license string input and converts it to HEX - is more capable than the way its used on the DS2 ... e.g. all kinds of special chars - but i only implemented /reversed what i saw being used by the DS2k.

What do these parameters look like (example)? What are you grepping for? Could viewing the .sys file in a hex editor be the key to this one?

I did just that i opend the sys file in a hex editor and did a serch for the keys that are used  in the ds20000 with no result. One  thing that is poitive is that the mcu is the same
If you boot the DSA815 it says "decompressing...".
Maybe the sys file is compressed ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on July 23, 2013, 04:56:53 pm
Quote
I did just that i opend the sys file in a hex editor and did a serch for the keys that are used  in the ds20000 with no result. One  thing that is poitive is that the mcu is the same

If the .sys file is just the firmware, perhaps hooking said MCU up to a JTAG debugger and downloading the firmware that way would help. I'm look to see if there is anything I can figure out when I get home; I would really like to see this get hacked
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 23, 2013, 04:59:20 pm
if somebody wants me to have a look send me such a file ;-) - DS2 fw contains for example the zlib inflate/deflate algo - but there it only seems to be used by the PNG image format.
jtag is definitly the way to go anyway because it eases the process so much. i recommend 20$ amontec jtag key tiny - best invest ;)


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on July 23, 2013, 05:17:51 pm
DSA815, V1.07
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on July 23, 2013, 06:45:28 pm
@zombie28
Thank you for your feedback. I slept in 48h only 6h. Now I see clearly what crap I've written.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on July 23, 2013, 07:33:08 pm
Here is optimized signing function with all necessary checks for valid signature generation:
That's a bit cleaner, but we're getting to the point of absurdity now, the thing works and is faster than it needs to be. Still, I'll put this in my updated copy, thanks.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on July 23, 2013, 07:50:46 pm
I found this document about clearing/cleaning memory on various Rigol scopes:

http://www.tequipment.net/ProductImages/Rigol/DS1302CA/media/DS1302CA_doc_7.pdf (http://www.tequipment.net/ProductImages/Rigol/DS1302CA/media/DS1302CA_doc_7.pdf)

It mentioned a security clear to clear the NOR FLASH 16MB - I wonder if this could possibly help people with the mangled serial number.  Not likely I realize, but I'll bet that S/N is stored in the NOR FLASH 16MB in some sort of configuration file...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: CodyShaw on July 23, 2013, 08:09:00 pm
So, what are the downsides to using the keygen (2072)? Are there issues on what FW version it works best on, and reverting is not working as of current, or is it all clear for use for new people?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 23, 2013, 08:22:06 pm
attached you will find a FLAIR signature file for IDA pro (you need kraters bfin plugin !) -  it contains around 300 subs that i reversed, (un)fortunately no comments got exported so you are spared by my comments ;-) but it should give a pretty clear indication of MIRACL, Bootloader, USB, the whole ADI stuff, some TWI, SPI routines.

I've tried it with a FW02 file, it gives some results - the blackfin GEL loader is buggy i have to say that, something is not right with the address fixup - so if someone wants to seriously do this i strongly suggest you do a JTAG memory dump - the match rate should then be 100% and u dont have any dead references. for the DG4000 firmware the loader format is slightly different i patched the blackfin loader and i can import it, *but* i will stay put until i get a JTAG memory dump due to above issues. (it is much easier with a memory dump)

i also looked at the DSA file for a couple of hours, not much luck - so far i didnt spot any hidden packed formats, nor any header that looks familiar - i even ran the file completely as it is and ROT13 (they are not *that* stupid ;-) through a disasm, except tons of ILLEGAL opcodes nothing - only thing left thats doable is maybe a filesystem image hidden in there - but binwalk found nothing - so it is packed, crypted etc somehow - im not a DSA owner, but if i were one i would leave the file alone, and do a JTAG dump as well - i saw in daves teardown pics there is a jtag port next to the blackfin - so that should be no issue.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on July 23, 2013, 08:46:20 pm
So, what are the downsides to using the keygen (2072)? Are there issues on what FW version it works best on, and reverting is not working as of current, or is it all clear for use for new people?

Some people have experienced a mangled S/N with it changing from 13 digits to a 14 digit that ends in 0001, but I think these are people who tried bandwidth options on the FW 05.

I can tell you that on the latest firmware FW 02 (00.01.01.00.02) that my experience is that a DSAZ code will install without any issues or changes to the S/N and also that you can even uninstall it with the USB SCPI uninstall command and completely go back to stock.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on July 23, 2013, 08:56:57 pm
I found this document about clearing/cleaning memory on various Rigol scopes:

http://www.tequipment.net/ProductImages/Rigol/DS1302CA/media/DS1302CA_doc_7.pdf (http://www.tequipment.net/ProductImages/Rigol/DS1302CA/media/DS1302CA_doc_7.pdf)

It mentioned a security clear to clear the NOR FLASH 16MB - I wonder if this could possibly help people with the mangled serial number.  Not likely I realize, but I'll bet that S/N is stored in the NOR FLASH 16MB in some sort of configuration file...
Declassification, or clearing test equipment is probably a mandatory thing in the USA. You see this also on Tektronix, Agilent and Fluke equipment. Every vendor has some sort of document to describe how the secret DMM values can (must) be cleared if the thing leaves the office or premises of the CIA :)

On the Scope is does only clear the stored stuff, and hopefully not the serial number, but you never know with RIGOL  :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: M. András on July 23, 2013, 09:01:02 pm
hahh according to that pdf file it have 3 damn 32MB ddr2 memory for aquisition, is that sooo expensive to stick a simple pc memory card in the scope for this purpose? and it costs hundreds of dollar premium? :palm:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: CodyShaw on July 23, 2013, 09:07:17 pm
So, what are the downsides to using the keygen (2072)? Are there issues on what FW version it works best on, and reverting is not working as of current, or is it all clear for use for new people?

Some people have experienced a mangled S/N with it changing from 13 digits to a 14 digit that ends in 0001, but I think these are people who tried bandwidth options on the FW 05.

I can tell you that on the latest firmware FW 02 (00.01.01.00.02) that my experience is that a DSAZ code will install without any issues or changes to the S/N and also that you can even uninstall it with the USB SCPI uninstall command and completely go back to stock.

So what can't the keygen unlock? Is it limited to bandwidth?

Or will the keygen unlock the bandwidth too, as long as you weren't messing around trying to get at it in FW 05?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on July 23, 2013, 09:09:06 pm
hahh according to that pdf file it have 3 damn 32MB ddr2 memory for aquisition, is that sooo expensive to stick a simple pc memory card in the scope for this purpose? and it costs hundreds of dollar premium? :palm:

32MB x 16 bits - so 3x 64MB x 8 bits.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mickpah on July 23, 2013, 09:20:24 pm

jtag is definitly the way to go anyway because it eases the process so much. i recommend 20$ amontec jtag key tiny - best invest ;)

seems a nice little jtag, price is good. Pity they can't find a better shipping solution even the cheapest, slowest shipping to the southern hemisphere is 33 euro - for a 45 gram pcb ??? I hate when suppliers do this
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 23, 2013, 09:27:38 pm
hi mickpah,

check http://urjtag.org/book/_system_requirements.html (http://urjtag.org/book/_system_requirements.html) - as the uclinux jtag proxy is using urjtag i would believe all of them are supported.

a dump from the bfin-jtag tool lists:

Code: [Select]
List of supported cables:
ARCOM           Arcom JTAG Cable
ByteBlaster     Altera ByteBlaster/ByteBlaster II/ByteBlasterMV Parallel Port Download Cable
DLC5            Xilinx DLC5 JTAG Parallel Cable III
EA253           ETC EA253 JTAG Cable
EI012           ETC EI012 JTAG Cable
FT2232          Generic FTDI FT2232 Cable
ARM-USB-OCD     Olimex ARM-USB-OCD[-TINY] (FT2232) Cable
ARM-USB-OCD-H   Olimex ARM-USB-TINY-H (FT2232H) Cable
Flyswatter      TinCanTools Flyswatter (FT2232) Cable
gnICE           Analog Devices Blackfin gnICE (FT2232) Cable (EXPERIMENTAL)
gnICE+          Analog Devices Blackfin gnICE+ (FT2232H) Cable (EXPERIMENTAL)
JTAGkey         Amontec JTAGkey (FT2232) Cable
KT-LINK         KrisTech KT-LINK (FT2232H based) Cable
milkymist       Milkymist JTAG/serial (FT2232) Cable
OOCDLink-s      OOCDLink-s (FT2232) Cable (EXPERIMENTAL)
Signalyzer      Xverve DT-USB-ST Signalyzer Tool (FT2232) Cable (EXPERIMENTAL)
Turtelizer2     Turtelizer 2 Rev. B (FT2232) Cable (EXPERIMENTAL)
USB-JTAG-RS232  USB<=>JTAG&RS232 (FT2232) Cable (EXPERIMENTAL)
usbScarab2      KrisTech usbScarabeus2 (FT2232) Cable
USB-to-JTAG-IF  USB to JTAG Interface (FT2232) Cable (EXPERIMENTAL)
gpio            GPIO JTAG Chain
ICE-100B        Analog Devices ICE-X Cable (0x064B)
IGLOO           Excelpoint IGLOO JTAG Cable
jlink           Segger/IAR J-Link, Atmel SAM-ICE and others.
KeithKoep       Keith & Koep JTAG cable
Lattice         Lattice Parallel Port JTAG Cable
Minimal         Minimal Parallel Port JTAG Cable
MPCBDM          Mpcbdm JTAG cable
TRITON          Ka-Ro TRITON Starterkit II (PXA255/250) JTAG Cable
UsbBlaster      Altera USB-Blaster Cable
vsllink         Versaloon Link -- http://www.versaloon.com.
WIGGLER         Macraigor Wiggler JTAG Cable
WIGGLER2        Modified (with CPU Reset) WIGGLER JTAG Cable
xpc_ext         Xilinx Platform Cable USB external chain
xpc_int         Xilinx Platform Cable USB internal chain

maybe you find a cheaper option, for me it was the amontec ...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on July 23, 2013, 09:29:38 pm
i also looked at the DSA file for a couple of hours, not much luck - so far i didnt spot any hidden packed formats

There is clear text in DSA file: "The length of license key must be less than 20 characters", so they may be using different encoding method than in DS2k.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 23, 2013, 09:32:01 pm
i also looked at the DSA file for a couple of hours, not much luck - so far i didnt spot any hidden packed formats

There is clear text in DSA file: "The length of license key must be less than 20 characters", so they may be using different encoding method than in DS2k.

yes but no code segments, only data stuff - and 2 times magic bytes for the xilinx fpga bitstreams (as in ds2000 files)

Code: [Select]
xilinx fpga offsets - magic bytes: 0xAA 0x99 0x55 0x66

0x76DBB
0x13AD32
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: M. András on July 23, 2013, 09:48:24 pm
hahh according to that pdf file it have 3 damn 32MB ddr2 memory for aquisition, is that sooo expensive to stick a simple pc memory card in the scope for this purpose? and it costs hundreds of dollar premium? :palm:

32MB x 16 bits - so 3x 64MB x 8 bits.
thanks for the correction but the modules themselves still cheap looking at random chips at digikey with the same sizes, 6-9/chip at 1k quantity, thats still doesnt qualify for me not including more memory as standard on every scope unless its already hit the upper limit of that fpga inside the this rigol scope,
sorry for the off topic but i can tear out my hair when i see things like this asking 300bucks for the remaining memory size from that max 30bucks worth of memory
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mickpah on July 23, 2013, 09:56:39 pm

maybe you find a cheaper option, for me it was the amontec ...

thanks, I did in total cost.
It's a bit of sore point here. The media here call it the Australian tax. Companies like MS, apple adobe and others add 15%-20% for no other reason that we are an isolated market and they can. The polite term I think is being rogered
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 23, 2013, 09:58:01 pm
good point is u can use it for other stuff as well ;-) reversed a few other things by now with it, so worth every $ ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: synapsis on July 23, 2013, 09:59:50 pm
sorry for the off topic but i can tear out my hair when i see things like this asking 300bucks for the remaining memory size from that max 30bucks worth of memory

This is why I waited to buy my scope, and partially why I got involved in making an app.

But it did lead to another sale from them, my DG4062 should be here within the week.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: M. András on July 23, 2013, 10:03:09 pm
sorry for the off topic but i can tear out my hair when i see things like this asking 300bucks for the remaining memory size from that max 30bucks worth of memory

This is why I waited to buy my scope, and partially why I got involved in making an app.

But it did lead to another sale from them, my DG4062 should be here within the week.
yeah thats a driving force, i hope i can get enough money to buy the little ds2k in less then 3 months cos im in need of a scope anyway and the agilent 3k 200mhz mso is way out of my paygrade atm (1.5years of salary)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 23, 2013, 10:14:07 pm
Blessed google LOL:

*.pdf site:www.tequipment.net/ProductImages/Rigol/

*Declassification*.pdf site:www.tequipment.net/ProductImages/

http://lmgtfy.com/?q=you+know+how+to+use+google%2C+we+are+impressed+! (http://lmgtfy.com/?q=you+know+how+to+use+google%2C+we+are+impressed+!)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on July 23, 2013, 10:17:13 pm
I deleted my previous message, I consider it inappropriate and does not contribute to anything. Sorry.  :-[

http://www.tequipment.net/ProductImages/Rigol/DSA815/media/DSA815_doc_3.pdf (http://www.tequipment.net/ProductImages/Rigol/DSA815/media/DSA815_doc_3.pdf)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on July 23, 2013, 11:01:33 pm
thanks for the correction but the modules themselves still cheap looking at random chips at digikey with the same sizes, 6-9/chip at 1k quantity, thats still doesnt qualify for me not including more memory as standard on every scope unless its already hit the upper limit of that fpga inside the this rigol scope,
sorry for the off topic but i can tear out my hair when i see things like this asking 300bucks for the remaining memory size from that max 30bucks worth of memory

This is a discussion that has happened dozens of times already on this forum regarding development costs versus option costs. If you tear your hair out about this, what do you do for the cost of software only options (triggers, decodes, etc) which are just unlocked portions of FW code?  :)

BTW, the memory is connected via matched impedance traces to the two FPGAs, so I doubt just sticking a PC memory card in would provide the same performance.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on July 24, 2013, 12:48:50 am
Updated code with zombie28's ecssign, removed seed.

I can confirm during a Security Erase does not revert the model, fix the serial, nor change license options.

EDIT: see my post slightly further ahead for updated code
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jonese on July 24, 2013, 02:17:18 am
One thing to consider that most here won't have noticed because they have a 2072.

I have a 2102.  I, like a lot of people, played originally with the LLLL VSA/DSA keys before the actual algo was discovered.  When I uninstalled those trials before installing the correct key for a 2202, my unit reverted to a 2072 and not it's true 2102 model.  Applying the proper key did pushed it to 2202, my serial number is still valid.

It would seem the steps I took before installing the proper key removed the type of model branding that my unit had from the factory and it looks like it defaulted to the base model of 2072 instead of 2102.  My concern is that if/when the next firmware comes out that changes things around, I will be left with a 2072 base model.

There must be another piece of data that is stored in the unit to tell it what model it actually is.  Would be nice to put that back (even via JTAG if need be).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on July 24, 2013, 04:43:21 am
One thing to consider that most here won't have noticed because they have a 2072.

I have a 2102.  I, like a lot of people, played originally with the LLLL VSA/DSA keys before the actual algo was discovered.  When I uninstalled those trials before installing the correct key for a 2202, my unit reverted to a 2072 and not it's true 2102 model.  Applying the proper key did pushed it to 2202, my serial number is still valid.

What if what we've been calling the test keys are really configuration keys?  Maybe it isn't a bug that the model number STAYS across reboots, but the other options do not.  Maybe this is how they make a 2102 a 2102 at the factory.

I still wonder if there is a risk associated with older firmware (FW05) and setting both the 2102 and 2202 bits at the same time that causes the S/N to get mangled to a 14 digit ending in 00001.  But maybe the factory could set one bit or the other safely even with FW 05.

jonese:  If your unit is back to thinking it is a DS2072, just load the key that will turn it into a DS2102 again:

LLLLLLL-RLGLLDS-DSAJLLL-LLLLLLL
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bleckers on July 24, 2013, 09:10:44 am
Updated code with zombie28's ecssign, removed seed.

I can confirm during a Security Erase does not revert the model, fix the serial, nor change license options.

You need to change your argument check to be the following:
Code: [Select]
if (!((argc == 3 && strlen(private_key)) || argc == 4)) {
show_help(argv[0]);
exit(-1);
}

serial = strtoupper((unsigned char*)argv[1]);
options = strtoupper((unsigned char*)argv[2]);

if (argc == 4) {
priv_key = strtoupper((unsigned char*)argv[3]);
} else {
priv_key = strtoupper((unsigned char*)private_key);
}
Otherwise it doesn't accept the private key correctly and won't run if you don't put the private key in the command line options.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Chalky on July 24, 2013, 09:52:14 am
:SYSTem:OPTion:INSTall LLLLLLLRLGLLDSDSA9LLLLLLLLLL
:SYSTem:OPTion:UNINSTall

:system:option:install LLLLLLLRLGLLDSVSA9LLLLLLLLLL
:SYSTem:OPTion:UNINSTall

Still DS2202  |O
Try without the uninstall, worked for me.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on July 24, 2013, 03:15:01 pm
Going back to the .sys file for updating the DSA815: this file appears to contain the updates for all board components, inclusing the FPGA's as well as the MCU. Perhaps this file is merely a container for individual firmwares?

Does having a serial number and a licence key allow the encryption keys to be reverse engineered, assuming some of the keys/primes from the DS2000 are similar accross all Rigol lines?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Majorstrain on July 24, 2013, 09:03:27 pm
Your famous now 8)
http://hackaday.com/2013/07/24/a-keygen-for-the-rigol-2000-series-scopes/ (http://hackaday.com/2013/07/24/a-keygen-for-the-rigol-2000-series-scopes/)
Can I have your autograph?
;)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Maalobs on July 24, 2013, 09:06:42 pm
Going back to the .sys file for updating the DSA815: this file appears to contain the updates for all board components, inclusing the FPGA's as well as the MCU. Perhaps this file is merely a container for individual firmwares?

I know nothing of it, but I got the impression that the DS2000 GEL-file also contains data for several firmwares in the oscilloscope, because both the software version and SPU/WPU/CCU/MCU version-numbers are changed when the scope is flashed.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: IanJ on July 24, 2013, 09:18:16 pm
Your famous now 8)
http://hackaday.com/2013/07/24/a-keygen-for-the-rigol-2000-series-scopes/ (http://hackaday.com/2013/07/24/a-keygen-for-the-rigol-2000-series-scopes/)
Can I have your autograph?
;)

Don't forget Dave will be lapping this up also......the traffic through eevblog.com will surely increase as a result!

Ian.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 24, 2013, 09:31:00 pm
Going back to the .sys file for updating the DSA815: this file appears to contain the updates for all board components, inclusing the FPGA's as well as the MCU. Perhaps this file is merely a container for individual firmwares?

I know nothing of it, but I got the impression that the DS2000 GEL-file also contains data for several firmwares in the oscilloscope, because both the software version and SP/WPU/CCU/MCU version-numbers are changed when the scope is flashed.

DS2k file contains xilinx fpga streams too - as its 2 i would suspect one for the display fpga one for the sampling fpga
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: benemorius on July 24, 2013, 10:05:39 pm
Your famous now 8)
http://hackaday.com/2013/07/24/a-keygen-for-the-rigol-2000-series-scopes/ (http://hackaday.com/2013/07/24/a-keygen-for-the-rigol-2000-series-scopes/)
Can I have your autograph?
;)

Don't forget Dave will be lapping this up also......the traffic through eevblog.com will surely increase as a result!

Ian.

Don't forget about Rigol either. Sales are going to go through the roof! Hopefully they notice and are able to figure out why. My money says either they will, or they have already. :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on July 25, 2013, 12:21:36 am
I am sure the sales will continue going up, RIGOL have done a good work and, a good machine.  :-+
I hope that in the future RIGOL continue doing so.  ^-^

P. S.: I also want an autograph, in a DS2202 sticker.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on July 25, 2013, 12:26:52 am
Updated code with zombie28's ecssign, removed seed.

I can confirm during a Security Erase does not revert the model, fix the serial, nor change license options.

You need to change your argument check to be the following:
Code: [Select]
if (!((argc == 3 && strlen(private_key)) || argc == 4)) {
show_help(argv[0]);
exit(-1);
}

serial = strtoupper((unsigned char*)argv[1]);
options = strtoupper((unsigned char*)argv[2]);

if (argc == 4) {
priv_key = strtoupper((unsigned char*)argv[3]);
} else {
priv_key = strtoupper((unsigned char*)private_key);
}
Otherwise it doesn't accept the private key correctly and won't run if you don't put the private key in the command line options.

I should have caught that, feel like an idiot, thanks! Fixed version attached.

EDIT: I shouldn't do this when tired. To the 3 who downloaded, please re-download, it was still bugged :(
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on July 25, 2013, 01:06:26 am
Going back to the .sys file for updating the DSA815: this file appears to contain the updates for all board components, inclusing the FPGA's as well as the MCU. Perhaps this file is merely a container for individual firmwares?

I think that I have just discovered structure of this file. It doesn't contain full firmware, it's a patch for NOR flash containing only blocks of bytes that have been modified. The structure is as follows:

- NULL terminated signature 'DSA800'
- string '000000000' - could be internal version of patched firmware
- 4 bytes, maybe dword (= 0x00000001)
- dword containing numer of patching blocks (= 14)
- table of block descriptors (in this case there are 14 descriptors)

each block descriptor contains 3 dwords:
- position of patching block in the file
- length of patching block
- destination address of this block in NOR flash

position of each block in the file is aligned on 4-byte boundary

Quote
Does having a serial number and a licence key allow the encryption keys to be reverse engineered, assuming some of the keys/primes from the DS2000 are similar accross all Rigol lines?

I've sent you PM
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on July 25, 2013, 01:07:22 am
I have tried all options and permutations of LLLLLLL DSAx / VSAx with one+power cycle, two with uninstall in-between+power cycle, both with no uninstall+power cycle and no matter what, I still have 2202. So this does not appear to be a way to change the reported model back (and remove 2ns option added with 2202), only possibly setting the bits and moving it forward.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on July 25, 2013, 01:36:08 am
Quote
I've sent you PM

I replied to this message with the information you need
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bmwnomad on July 25, 2013, 01:44:30 am
I should have caught that, feel like an idiot, thanks! Fixed version attached.

EDIT: I shouldn't do this when tired. To the 3 who downloaded, please re-download, it was still bugged :(

I think its still bugged, the code I generate with this version doesn't match the very first version.  The first version code (brute-forced, no checks, etc.) worked fine on my 2072, I'm just keeping my keygen up to date.

BTW, using Cygwin, so if something broke from the first version to this version and its caused by cygwin, my apologies.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: synapsis on July 25, 2013, 02:00:26 am
Does the Windows version work for you?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bleckers on July 25, 2013, 02:07:06 am
I should have caught that, feel like an idiot, thanks! Fixed version attached.

EDIT: I shouldn't do this when tired. To the 3 who downloaded, please re-download, it was still bugged :(

I think its still bugged, the code I generate with this version doesn't match the very first version.

The current version should just be randomising/changing the seed so you will indeed get different codes on this version. Nothing to be alarmed at, it will still activate correctly.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jonese on July 25, 2013, 02:12:42 am
I have tried all options and permutations of LLLLLLL DSAx / VSAx with one+power cycle, two with uninstall in-between+power cycle, both with no uninstall+power cycle and no matter what, I still have 2202. So this does not appear to be a way to change the reported model back (and remove 2ns option added with 2202), only possibly setting the bits and moving it forward.

What is your native model of your scope?

Are you saying you have a native 2202 and you can't make it a 2072 by any method?
Or are you saying you have a native 2072 and can't revert to back to a 2072?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on July 25, 2013, 03:21:33 am
The latter. Is a 2072, only applied generated valid DSAZ license, turned into 2202 with 14digit SN 0001, upgraded FW set it back to 2072, another DSAZ put it back as a 2202 and it now never changes from being a 2202.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ve7xen on July 25, 2013, 03:34:51 am
I should have caught that, feel like an idiot, thanks! Fixed version attached.

EDIT: I shouldn't do this when tired. To the 3 who downloaded, please re-download, it was still bugged :(
I've updated the binaries at my site as well if anyone has been using those. Not that anyone needs it once you've generated a key :P
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tlu on July 25, 2013, 05:04:36 am
Does the current RiGen-1 for windows in http://gotroot.ca/rigol/ (http://gotroot.ca/rigol/) directory up to date and can we leave seed at 1 when generating?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: synapsis on July 25, 2013, 06:05:56 am
I put the changes people suggested before into the original Rigen before I released it.

You should be able to just leave the seed at 1. If RiGen detects that the seed won't work, it'll automatically choose another one up to 10 times.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: XaS on July 25, 2013, 06:54:47 am
I can confirm at least one additional sale on a DS2072, maybe up to 3 to friends of mine. All thanks to you guys! Rigol should promote the guys responsible for the licence key managment.  :-DD

MfG XaS
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Majorstrain on July 25, 2013, 07:01:14 am
Connor Wolf spreads the word via YouTube. EEVblog gets a mention.
He shows the process on a DS4000  :clap:

http://youtu.be/-Woslp7HXFM (http://youtu.be/-Woslp7HXFM)

Who will be next?

Cheers,
Phil
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: roli_bark on July 25, 2013, 07:18:40 am
So now due to high publicity, I'll bet you, they [R***L] will come up with new FW versions that defeat this R*G**.exe...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ve7xen on July 25, 2013, 07:23:08 am
So now due to high publicity, I'll bet you, they [R***L] will come up with new FW versions that defeat this R*G**.exe...
Who cares! Almost all bugs are fixed in latest version :P

Personally I think this is probably permanently modifying the scope's model, or perhaps the earlier engineer keys do. In which case there will be no way for them to tell between a generated and legitimate key. They may do like Agilent and prevent the *installation* of these keys (by creating a new key or authentication mechanism), but I don't think they can disable existing ones. And they apparently can't prevent downgrading. So I think it's cracked wide open, but I could be wrong. I'm going to let someone else risk their scope when the next firmware update comes out, I took enough risk already :).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: roli_bark on July 25, 2013, 07:42:41 am
Basically you're right. Who cares. But maybe except for new buyers of the same models starting, say, next year...?

Also, you never know what type of serious "bugs"  are still pending to be found & fixed. They may come up with a different curve next FW round, or even a total different crypto algo altogether.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ve7xen on July 25, 2013, 07:44:24 am
They may come up with a different curve next FW round, or even a total different crypto algo altogether.
My point is that I think, based on nothing other than pure speculation and intuition, that they won't be able to do this without forcing all users of anything other than a DS2072 to enter a new key upon upgrade, which Rigol will have to generate and provide to each user. They might consider that worthwhile, but it would be a pretty big PR problem among their 'serious' customers I think.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bleckers on July 25, 2013, 07:46:01 am
The main risk you have is if you brick your scope and Rigol check that your scope has been upgraded by this method (they would have a list of serials that have upgrades), then they might refuse to fix it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on July 25, 2013, 07:56:11 am
The main risk you have is if you brick your scope and Rigol check that your scope has been upgraded by this method (they would have a list of serials that have upgrades), then they might refuse to fix it.
While under warranty, this is illegal in many countries. This includes the US. (I do not know your country of residence.)

If Rigol refused to fix a warranty hardware problem on my 'scope - or any other manufacturer / item for that matter - while under warranty, unrelated to any software or hardware modification, I would sue.

Out of warranty repairs, that's another story =)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bleckers on July 25, 2013, 08:09:23 am
The main risk you have is if you brick your scope and Rigol check that your scope has been upgraded by this method (they would have a list of serials that have upgrades), then they might refuse to fix it.
While under warranty, this is illegal in many countries. This includes the US. (I do not know your country of residence.)

If Rigol refused to fix a warranty hardware problem on my 'scope - or any other manufacturer / item for that matter - while under warranty, unrelated to any software or hardware modification, I would sue.

That is a fair point, I guess it depends on what your country's law is on jailbreaking/reverse engineering (in the same vane as rooting a phone for example). It could be argued that you effectively reverse engineered it to perform the operation (having access to the tools/source). IANAL though.

I guess worst case would be that they load it with a new firmware that you can't downgrade from or something, but that in itself is pretty drastic/paranoia.

The best suggestion for people would be to use the scope for a while, then apply the code when they actually need to use the extra features.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: roli_bark on July 25, 2013, 08:12:06 am
Sue? On what grounds?
I suspect that your warranty automatically expires when they can prove that any part of the product has been tampered with.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: benemorius on July 25, 2013, 08:23:07 am
I wouldn't be too quick to assume that they're going to fix anything. There is a fair chance that they deliberately chose the level of difficulty they wanted us to encounter in hacking these models knowing full well that it would generate extra sales. Too easy could have been embarrassing for them, and too hard might have made it take too long to be hacked. I'm no businessperson but it looks to me like they nailed it.

I recall someone having reasonably well convinced me that there is some evidence to suggest that at least a few people at Rigol are wise enough to do this intentionally, although the details have unfortunately escaped me right now.

Of course, time will tell. I post this not in an attempt to predict the future, but to help create it. I trust that someone at Rigol is reading this thread, and I'm hoping that they have the insight to make profitable decisions, and the influence to see them through.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: benemorius on July 25, 2013, 08:29:55 am
Sue? On what grounds?
I suspect that your warranty automatically expires when they can prove that any part of the product has been tampered with.

On the grounds that they failed to honor a warranty.

I know very little about the legal systems in most countries, but I would lose all faith in any court that allowed a company to void a warranty due to tampering unless the company's engineers could demonstrate that such tampering could in fact reasonably be believed to have caused the observed fault. Hacking a license key magically makes the backlight inverter fail prematurely? Bullshit unless you can prove it, and any country with a court that doesn't agree is in dire trouble.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mickpah on July 25, 2013, 08:32:39 am
Basically you're right. Who cares. But maybe except for new buyers of the same models starting, say, next year...?

Also, you never know what type of serious "bugs"  are still pending to be found & fixed. They may come up with a different curve next FW round, or even a total different crypto algo altogether.

True they might change the crypto, but can you imagine the logistic of reissuing keys, the pissed off customers who loose functionality while this happens ? because to make the change work they would have to make the next fw upgrade irreversible
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on July 25, 2013, 08:34:32 am
Sue? On what grounds?
I suspect that your warranty automatically expires when they can prove that any part of the product has been tampered with.
Your suspicion is not the law. But let's not turn this into a legal thread - the point is, in many countries, installing a key on your scope will not void the warranty.

Quote from: benemorious
There is a fair chance that they deliberately chose the level of difficulty they wanted us to encounter in hacking these models knowing full well that it would generate extra sales.
Have you seen, in general, Chinese programming for consumer devices? It's not very different for special devices, either. This is not the first time such ideas have been brought up in this thread. This is purely a case of ignorance and poor practices.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: benemorius on July 25, 2013, 09:01:43 am
Have you seen, in general, Chinese programming for consumer devices? It's not very different for special devices, either. This is not the first time such ideas have been brought up in this thread. This is purely a case of ignorance and poor practices.

No indeed. I won't deny charges of wishful thinking. I'll try to turn up the evidence to the contrary that I alluded to though. It was by no means conclusive, but it was enough to make me nod and say "hmm... yeah, maybe so". In any case, like I said, I'm trying to help make the future - not predict it. :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on July 25, 2013, 01:09:35 pm
Quote
I've sent you PM

I replied to this message with the information you need

I have analysed your data and I think it is likely that DSA815 uses the same encoding method and elliptic curve as DS2k, but with different keys. However, if all curve parameters are the same, then it will be very easy to find out private key form the public one (which is somewhere in the firmware).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 25, 2013, 01:14:39 pm
is anyone working on gaining JTAG access to a DSA ? i can provide the schematics on how to patch it up ... dump the memory 0x0-0x20000000 with gdb, and then u should have the curve parameters. contact me if u need jtag access guidance.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on July 25, 2013, 01:21:06 pm
Quote
is anyone working on gaining JTAG access to a DSA ? i can provide the schematics on how to patch it up ... dump the memory 0x0-0x20000000 with gdb, and then u should have the curve parameters. contact me if u need jtag access guidance.

Can you tell me if the "ADZS-ICE-100B" emulator can be used for the blackfin MCU in the DSA815? Either way, if there is a cheaper/better alternative, please just name that.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 25, 2013, 01:25:40 pm
Quote
is anyone working on gaining JTAG access to a DSA ? i can provide the schematics on how to patch it up ... dump the memory 0x0-0x20000000 with gdb, and then u should have the curve parameters. contact me if u need jtag access guidance.

Can you tell me if the "ADZS-ICE-100B" emulator can be used for the blackfin MCU in the DSA815? Either way, if there is a cheaper/better alternative, please just name that.

seems like yes - but u can check for urjtag on the bfin uclinux pages to get a list or scroll up - i posted the compatible ones. 150$ sounds rather pricey for a stupid jtag adapter, i would get a cheaper one .. ;-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mickpah on July 25, 2013, 11:08:16 pm
On an Australian Rigol reseller web site

"Due to large requirement reently, all of DS2072 sold before put on the shelf, few ordered units come in stock around 3rd of August, Please contact us early if you need urgently!" - their spelling not mine.

Appears to be stock of other models wonder what happened ?  >:D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jeremy on July 25, 2013, 11:13:46 pm
I just bought one from Emona, hopefully I can get it soon. Which supplier was it?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mickpah on July 25, 2013, 11:21:00 pm
I just bought one from Emona, hopefully I can get it soon. Which supplier was it?
eyou, http://www.eyou.com.au/. (http://www.eyou.com.au/.) got my dp832 there seem pretty good to deal with, notice they are starting to put rigol firmware up on site too for some stuff.
i think Emona is the official distributor, but as they didn't follow up on a promised firmware upgrade for my ds2072 so i moved on. don't believe it's a customer's job to chase sales/support they don't get many chances with this grumpy old man.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bleckers on July 26, 2013, 02:09:35 am
I just bought one from Emona, hopefully I can get it soon. Which supplier was it?
eyou, http://www.eyou.com.au/. (http://www.eyou.com.au/.) got my dp832 there seem pretty good to deal with, notice they are starting to put rigol firmware up on site too for some stuff.

I got mine from eyou just after the test codes got released and they were very fast to deliver. They also offer pickup if you live nearby and give them a call. I don't like anyone's chances of getting one in Aus any time soon.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jeremy on July 26, 2013, 04:15:51 am
ironically enough, I bought one because I needed it, not because I knew about this. jackpot
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bleckers on July 26, 2013, 04:24:29 am
I had an old Tek DSO which I bought from uni when they were clearing surplus about 7 years ago, but one of the inputs had died on it recently. This hack just pushed me to finally upgrade.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Uup on July 26, 2013, 01:13:55 pm
I 've been experimenting with the option codes on my DS4024 and have worked out the various options. However, I was unable to change the model number/bandwidth.  :(  It appears as though it may be done via a different means, such as hardware jumpers or other hardware configuration bits. Not really sure at this point.

Attached, and below, is what I have worked out. I suspect that the only people who will really gain from this information are the dealers who will be able to work out their own option licence keys to sell to customers, instead of getting them from Rigol.   ::)

Anyhow... 

 
DS4000 Series DSO Option Codes:

Licence code string is in the following format:


LLLLLLL-RLGLLDS-****LLL-LLLLLLL
                ABCD


     A       B       C      D
   54321   54321   54321   54321

   x0000   00000   00000   00000   0 = Official, 1 = Trial
   0x000   00000   00000   00000   must = 0
   00x00   00000   00000   00000   See Note(2)
   000x0   00000   00000   00000   Option Bank Selection
   0000x   00000   00000   00000   Option Bank Selection

   00000   x0000   00000   00000   Licence re-application bit
   00000   0x000   00000   00000   must = 0
   00000   00x00   00000   00000   must = 0
   00000   000x0   00000   00000   must = 0
   00000   0000x   00000   00000   must = 0

   00000   00000   x0000   00000   must = 0
   00000   00000   0x000   00000   must = 0
   00000   00000   00x00   00000   See Note(2)
   00000   00000   000x0   00000   See Note(2)
   00000   00000   0000x   00000   See Note(2)

   00000   00000   00000   x0000   FlexRay Decode or alternate option
   00000   00000   00000   0x000   CAN Decode or alternate option
   00000   00000   00000   00x00   I2C Decode or alternate option
   00000   00000   00000   000x0   SPI Decode or alternate option
   00000   00000   00000   0000x   RS232 Decode or alternate option


More Detailed description of Bits:


A - Control Bits

1. Option bank selection: Available options =1 (if = 1 then A.2 should = 0)
2. Option bank selection: Alternate options =1 (if = 1 then A.1 should = 0)
3. See Note(2)
4. Must = 0
5. Trial = 1, See note(1) : Official = 0


B - Control Bits

1. Must = 0
2. Must = 0
3. Must = 0
4. Must = 0
5. Alternating bit allows re-installation of the same licence, without uninstalling it (indicates "Option Installed!")


C - Control Bits

1. See Note(2)
2. See Note(2)
3. See Note(2)
4. Must = 0
5. Must = 0


D - Options (0 = OFF, 1 = ON)

1. RS232 Decode
2. SPI Decode
3. I2C Decode
4. CAN Decode
5. FlexRay Decode

Alternate Options (when A.1 =0 && A.2 =1)

1. Reserved (Empty Option)
2. Reserved (Empty Option)
3. Reserved (Empty Option)
4. Reserved (Empty Option)
5. Reserved (Empty Option)

 
Notes:

(1) Re-applying the same trial licence will extend the trial time by an additional 1932 minutes to a maximum time of 5796 minutes.

(2) If any one of these bits are = 1, then re-applying the same licence will result in the error "Licence Unavailable!"
    If all of these bits are = 0, then re-applying the same licence will result in the message "The Option Has Been Installed!" or, in the case of a trial licence with maximum time reached, the message "Time Trial is Arrived!"
 

To work out the option code, use the following bit-to-code conversion table:

A = 00000
B = 00001
C = 00010
D = 00011
E = 00100
F = 00101
G = 00110
H = 00111
J = 01000
K = 01001
L = 01010
M = 01011
N = 01100
P = 01101
Q = 01110
R = 01111
S = 10000
T = 10001
U = 10010
V = 10011
W = 10100
X = 10101
Y = 10110
Z = 10111
2 = 11000
3 = 11001
4 = 11010
5 = 11011
6 = 11100
7 = 11101
8 = 11110
9 = 11111


Eg.

A) Option code to install SPI and FlexRay Decode Trial Options: 10001 00000 00000 10010 = T A A U
   LLLLLLL-RLGLLDS-TAAULLL-LLLLLLL

B) Option code to install all 5 official options: 00001 00000 00000 11111 = B A A 9
   LLLLLLL-RLGLLDS-BAA9LLL-LLLLLLL

 


Edit: use the above code you work out (eg. BAA9) along with your serial number and the private key to generate (eg. with RiKey) a license key. I only used the test key format above to indicate the placement of the code.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: adh on July 26, 2013, 01:20:12 pm
Quote from: benemorious
There is a fair chance that they deliberately chose the level of difficulty they wanted us to encounter in hacking these models knowing full well that it would generate extra sales.
Have you seen, in general, Chinese programming for consumer devices? It's not very different for special devices, either. This is not the first time such ideas have been brought up in this thread. This is purely a case of ignorance and poor practices.

There is no well-known secure method to generate reasonably short license keys. There is relatively simple modification to their method that would allow to use roughly ~100bit ECC keys that are in the realm of "can be cracked in month with resources of university department" with comparable length of license key you have to type in, but it is not something that is widely recommended by cryptography community.

I would say that this scheme shows that somebody actually thought about security of this scheme but had to weight security against convenience and grossly underestimated the complexity of breaking 56bit ECC. With product keys it is almost standard practice to use ECDSA or RSA with ridiculously short keys, because it allows you to claim to management that it uses "secure asymetric cryptograpy" and nobody then cares about actual security of the used key. On the other hand license keys for most embedded things I've seen are so short that it's clear that they cannot use anything other than some checksum and rely on the assumption that nobody is going to spend time reverse engineering 10kEUR+ piece of hardware to build keygen for it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mikeselectricstuff on July 26, 2013, 03:42:46 pm


There is no well-known secure method to generate reasonably short license keys. There is relatively simple modification to their method that would allow to use roughly ~100bit ECC keys that are in the realm of "can be cracked in month with resources of university department" with comparable length of license key you have to type in, but it is not something that is widely recommended by cryptography community.

I would say that this scheme shows that somebody actually thought about security of this scheme but had to weight security against convenience and grossly underestimated the complexity of breaking 56bit ECC. With product keys it is almost standard practice to use ECDSA or RSA with ridiculously short keys, because it allows you to claim to management that it uses "secure asymetric cryptograpy" and nobody then cares about actual security of the used key. On the other hand license keys for most embedded things I've seen are so short that it's clear that they cannot use anything other than some checksum and rely on the assumption that nobody is going to spend time reverse engineering 10kEUR+ piece of hardware to build keygen for it.

...of course for a product like this there is a really easy, very secure solution.
At manufacture, each unit has a randomly generated key, which is logged along with the serial number in the manufacturer's database. No mathematical relationship between key and serial = no keygen possible. With a timeout etc. to prevent brute-forcing, it doesn't even need to be very long.
Not hard to do, not hard to administer.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JimFouch on July 26, 2013, 03:48:57 pm
Years ago I was the head of a development team that put many man years into a piece of software. We often thought about putting copy protection on it. But, in the end, we decided it was so complicated to get running, that there were only two people on the planet that understood how it worked. We decided that if someone went through the trouble to steal it and *make it work* they deserved to have it for free... lol
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 26, 2013, 05:21:13 pm
...of course for a product like this there is a really easy, very secure solution.
At manufacture, each unit has a randomly generated key, which is logged along with the serial number in the manufacturer's database. No mathematical relationship between key and serial = no keygen possible. With a timeout etc. to prevent brute-forcing, it doesn't even need to be very long.
Not hard to do, not hard to administer.

whatever the secret is, be it a hash, or some mathematical unrelated thing - it has to be stored on the device - and can therefore be found. they just choose a path with "sounds" good (we use ecc crypto and signatures) but given that it took 170ms to find the private key had not much clue of ecc crypto.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on July 26, 2013, 05:31:39 pm
they just choose a path with "sounds" good (we use ecc crypto and signatures) but given that it took 170ms to find the private key had not much clue of ecc crypto.

Was it the private key that was found?  Or the public key.  Since the decryption process occurs on the device, did the device really have the private key for decryption and they use the public key to encrypt.  Is this one of the reasons why it was so easy to find the public key from the private key and not the other way around?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 26, 2013, 05:34:21 pm
Was it the private key that was found?  Or the public key.  Since the decryption process occurs on the device, did the device really have the private key for decryption and they use the public key to encrypt.  Is this one of the reasons why it was so easy to find the public key from the private key and not the other way around?

suggested bed time lecture http://en.wikipedia.org/wiki/Elliptic_Curve_DSA (http://en.wikipedia.org/wiki/Elliptic_Curve_DSA)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tlu on July 26, 2013, 06:41:54 pm
I put the changes people suggested before into the original Rigen before I released it.

You should be able to just leave the seed at 1. If RiGen detects that the seed won't work, it'll automatically choose another one up to 10 times.

Thanks for the info regarding the seeding.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on July 26, 2013, 10:27:36 pm
Was it the private key that was found?  Or the public key.  Since the decryption process occurs on the device, did the device really have the private key for decryption and they use the public key to encrypt.  Is this one of the reasons why it was so easy to find the public key from the private key and not the other way around?

The public key is hardcoded in firmware together with other public ECC domain parameters, and private key is (was  ;)) kept by Rigol in secrecy. This is how assymetric cryptography works. However Rigol used flawed ECC parameters, namely they didn't use prime numer for 'modulus', so it was trivial to compute the private key. It wouldn't be so easy if Rigol used proper modulus.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mikeselectricstuff on July 27, 2013, 12:59:43 am
...of course for a product like this there is a really easy, very secure solution.
At manufacture, each unit has a randomly generated key, which is logged along with the serial number in the manufacturer's database. No mathematical relationship between key and serial = no keygen possible. With a timeout etc. to prevent brute-forcing, it doesn't even need to be very long.
Not hard to do, not hard to administer.

whatever the secret is, be it a hash, or some mathematical unrelated thing - it has to be stored on the device - and can therefore be found.
Yes, but for only one device. Assuming it was stored securely (e.g. battery backed SRAM, BGA flash, protected MCU etc.), and there was no easy way to recover it without surgery, then any hacks would be limited to individual units. 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ve7xen on July 27, 2013, 01:30:40 am
Yes, but for only one device. Assuming it was stored securely (e.g. battery backed SRAM, BGA flash, protected MCU etc.), and there was no easy way to recover it without surgery, then any hacks would be limited to individual units.
Mike, shocked to see you giving up so easily!

It might be more difficult than the current (trivial) approach, but there are doubtless plenty of bugs that can be exploited to dump the key out of memory in that case. For the end user, the hack may be as easy as the current one, it will just take more effort to implement. If that's not feasible, the firmware updates appear to be unsigned...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Marc M. on July 27, 2013, 01:47:49 am
Can't we all agree on the fact the current protection scheme is very secure so there's no need to change it in future products  ;).  We just got lucky and stumbled upon their key!  After all, we certainly don't want to give them advise on how to prevent us from getting 'lucky' with future products do we??  Failing that, can we at least include some anti-Chinese government propaganda in every reply to guarantee that it's blocked??  >:D >:D >:D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: etc6849 on July 27, 2013, 07:30:16 pm
There's a test code for the DP832?  I would definitely buy one if someone could provide more information such as what it unlocks, etc...

Also, my DS2072 arrive this week.  It's a nice looking piece of equipment.  I ordered it a week ago from tequipment.net.  It appears to be from week 17 of 2013, so it came with the RP3300 probes (not the RP3300A probes).

The software version it came with is 00.01.00 and it has a 13 character serial number.  I gather I should update the firmware to the latest version before using the keygen?

I just bought one from Emona, hopefully I can get it soon. Which supplier was it?
eyou, http://www.eyou.com.au/. (http://www.eyou.com.au/.) got my dp832 there seem pretty good to deal with, notice they are starting to put rigol firmware up on site too for some stuff.

I got mine from eyou just after the test codes got released and they were very fast to deliver. They also offer pickup if you live nearby and give them a call. I don't like anyone's chances of getting one in Aus any time soon.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: IanJ on July 27, 2013, 07:56:19 pm
Hi all,

13 char serial here, applied using windows exe today using default settings.................perfect first time. Thanks to all those who worked on this.

Btw, I don't actually like the sprung hooks that came with my DS2072 probes (RP3300), I found they don't attach tightly enough to the probes themselves. Need very little pull and the probe is detached.

Ian.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: brob on July 27, 2013, 07:59:41 pm
IanJ

I had the same problem as you until I realized I was not installing the clip attachments to the probes properly. Try to push them harder together and you should hear a click, very seem very solid to me once I installed them correctly
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: IanJ on July 27, 2013, 08:08:22 pm
IanJ

I had the same problem as you until I realized I was not installing the clip attachments to the probes properly. Try to push them harder together and you should hear a click, very seem very solid to me once I installed them correctly

Aaaaaahhh, yes you are right........ ::)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: H.O on July 27, 2013, 09:11:24 pm
I'd like to thank all the individuals working on this, great stuff!
I can herby confirm it working on a DS4014, Hardware 1.1, Firmware 00.00.03-SP1.

I used the RiGen-1 tool on Windows with the private code found in the thread, a seed of 1 and BAA9 as the option code.
All 5 options now says Official Version, they seem stuck thru soft and hard power cycles and the scopes S/N remained unchanged. And, just in case there are both 13 and 14 char S/N, mine is 13.

The only thing it didn't change was the model number and bandwidth (I didn't expect it to) but I'll keep watching the thread for that  ;)

Again, thanks alot!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: synapsis on July 27, 2013, 10:50:13 pm
If you want RiGen to change your model number, select it in the app. If you select DS2202, it'll become a DS2202.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: H.O on July 28, 2013, 04:14:22 am
Hi,
Thank you. I do realise that but, as wrote I, have a DS4000 series scope - not DS2000.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on July 28, 2013, 04:42:24 am
All 5 options now says Official Version

I think you should take a closer look...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: fake-name on July 28, 2013, 04:46:13 am
All 5 options now says Official Version

I think you should take a closer look...

Whoa, is that typo in the actual firmware, or is it caused by using a keygen-produced key?

Connor Wolf spreads the word via YouTube. EEVblog gets a mention.
He shows the process on a DS4000  :clap:

http://youtu.be/-Woslp7HXFM (http://youtu.be/-Woslp7HXFM)

Who will be next?

Cheers,
Phil

I hope I wasn't stepping on anyone's toes by posting that.  I tried to be really clear that I had nothing to do with the actual work, and all the credit goes to the folks on this forum.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on July 28, 2013, 05:28:18 am
All 5 options now says Official Version
I think you should take a closer look...
Whoa, is that typo in the actual firmware, or is it caused by using a keygen-produced key?
$ strings DS2000Update.GEL | grep Offcial
Offcial Version
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: H.O on July 28, 2013, 06:01:27 am
Quote
I think you should take a closer look...
Ha, I didn't even notice that (apparently)... But if I understand trues latest post correctly it IS misspelled in the actual firmware and not caused by using the keygen. Then again, the file referenced is DS2000Update.gel while I've got a 4000 series scope but they apparently shares quite a bit of code so it's probably (hopefully) fine.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Majorstrain on July 28, 2013, 08:47:36 am
I hope I wasn't stepping on anyone's toes by posting that.  I tried to be really clear that I had nothing to do with the actual work, and all the credit goes to the folks on this forum.

Mate, I very much doubt that you stepped on any toes, sharing info is what forums are all about.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on July 28, 2013, 11:00:13 pm
is anyone going to jtag dump from ds2000 or ds4000? also having problems compiling the bfin stuff for IDA. (I don't do much on Windows...)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Giorg on July 29, 2013, 02:53:29 pm
Two month ago I've decided to buy an owon ds7102 ..then I came accross Dave's review of it and this thead..

And here I am with a shining Ds2072 on my bench completely unlocked.. worth every single cent of my money.. Rigol wins both hands down, absolutly no comparrison between the two instruments.

Thank you all guys for the incredible effort and for making me an happy and not bankrupted student !  :clap: O0

SW 00.01.01.00.02
HW 1.0.2.0.0

SPU 03.01.05
WPU 00.06.05
CCU 12.29.00
MCU 02.12
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bronson on July 30, 2013, 07:04:42 am
Sorry for the huge, unedited post...  Here's the summary: I tried the unlock, rendered my scope unbootable, reflashed the firmware a dozen times, prodded, poked, panicked, wasted an afternoon, and finally got things back in a decent state.  Yay.

Was it worth it?  Well, my DS2072 is fantastic as is -- I haven't needed more bandwidth or crazier triggers yet (I've only had it a few months though).  In retrospect, I probably should have waited.

But, I gotta say, it did eventually work.  This is some goddamn impressive work guys.  I'm just amazed.

And here's the post that I almost had to send...



Well this is not good...   :-BROKE  I thought I followed the instructions carefully but now my DS2072 won't boot.

I keyed in the code and got "Option Installed!".  Then, after soft power off and back on, the scope won't finish booting -- I just get "RIGOL" on the screen forever and the little rectangles underneath quit scrolling.

I tried reflashing 00.00.01 (same as currently installed) and then the newest 00.01.01.  The reflashing succeeds but the scope still won't boot.

Anybody know if I can do a hard reset on a scope that doesn't boot and get a little functionality back?


More detail:

I used
./rikey DS2A1512XXXX3 DSAZ
.  After getting "Option Installed!" I immediately checked the Installed Options screen and everything was listed as "Official Version".  Then I checked System Info and everything looked normal:


   Model:     DS2072                            (unchanged)
   Serial:     DS2A1512XXXX3           (unchanged)
   Software Version: 00.00.01
   Hardware Version: 1.0


Then I soft powered off and back on.  The scope wouldn't boot -- just freezes at the end of the boot sequence.  I tried all combinations of letting it remain frozen for 1/2 hour, hard and soft power offs, etc...  Doesn't make any difference.

FWIW, on 00.00.01 it always freezes on the second to last square whereas 00.01.01 it always freezes on the very last square.  Can't imagine that's important but it's always consistent.

UPDATE:

After another two hours of monkeying, the scope booted!  It was on 00.01.01 at the time, after going back and forth a bunch of times.  No idea why it works now but not before -- I didn't do anything different.

At least now it boots every time.  Alas, it still thinks it's a 2072, the serial number is wiped, and the Options/Installed menu is grayed out so I guess I don't have any options, not even my 1500 remaining trial minutes.

So, shooting in the dark, figure I'll try a Security Clear.  What's the worst that could happen?

That was odd!  Now it reports as a DS2202, and 2ns is available, but the serial number is still wiped and there are still no options.

Firmware is still old so, guess I'll risk another reflash...  That worked, no option changes.

Let's try another unlock, this time with DSA9 instead of DSAZ.

Reflashing with the original serial number fails (makes sense) but ./rikey DS2A0000000001 DSA9 was accepted.  It still thinks it's a 2702 but at least now I have some options!  Guess it's time to reboot, fingers crossed...

Smashing success, it now says it's a 2202 and the 2ns timebase is unlocked.  Boots quick, all options enabled.  Beautiful!!  The serial number is still wiped but I can live with that.  Anyone have any idea what I did wrong?

So, kiss the stars and moon, I got lucky on this one.  Next time I'll read all 150 pages of this stupid thread and the First Impressions thread three times instead of just once and take notes.  Be careful out there!

(edit: split one confusing step into two clear ones)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on July 30, 2013, 07:34:47 am
DSAZ code is questionable. I have used DSA9 with no issues at all.
If you do this make very sure you use it on the latest firmware V 00.01.01.00.02.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: roli_bark on July 30, 2013, 08:19:10 am
bronson,
Seems that you didn't carefully pay attention to the explicit [many] warnings on this thread:
"BEFORE trying the keygen make SURE that your FW is uptodate ..."
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Leonard Tatzig on July 30, 2013, 10:16:42 am
Besides the fact that i just yesterday ordered a Rigol DS2072 thanks to you guys i really try to understand the way which lead to this great hack.
I hope you don't mind if i bothering you with some "beginner" questions, maybe we'll open a new thread in the beginners section for that?!
In theory you just hook up a logic analyzer, dump the ram with trail and with activated options, then use IDA to reverse engineer and hopefully come up with a solution, am i right?
But it wasn't this easy...

Thanks to andyturk, cybernet, marmad,  mojo-chan, studio25, tinhead, ve7xen and many, many more now the community has this wonderful easy solution.

Some readers here are professionals and others are not, but all of us are share the enthusiasm to hack things and i would be very proud if the guys who made this hack for us could share there knowledge, the exact way of doing this so i could write a little DIY guide of reverse engineering the scope for all the beginners who would like to understand how to do this.

Most important question for me: Witch hardware and software did you used? From the older posts i'd gues:
-Bus Pirate (version 3.6, 4?)
-IDA Pro
-Salea Logic, Logic 16? 
-maybe a Open Workbench Logic Sniffer?
-a JTAGkey-Tiny
-Arduino
-Hexeditor
more??
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on July 30, 2013, 01:35:04 pm
Quote
Most important question for me: Witch hardware and software did you used? From the older posts i'd gues:
-Bus Pirate (version 3.6, 4?)
-IDA Pro
-Salea Logic, Logic 16? 
-maybe a Open Workbench Logic Sniffer?
-a JTAGkey-Tiny
-Arduino
-Hexeditor
more??


BRAINZ!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 30, 2013, 02:47:16 pm
BRAINZ!
:-+

not worth summing up, most stuff is dead boring, and the "finale" was somewhat surprising anyway ;-)
already got my DG4062, and i figured 160MHZ would be nize ... will probably start a new thread for it so if somebody wants to join in be there ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bronson on July 30, 2013, 03:17:38 pm
There are posts in this thread saying DSAZ is problematic so definitely use DSA9, and posts saying DSAZ is more correct so don't use DSA9.  I didn't see an definite conclusion so I went with correctness.  Looks like that was a bad guess!  Also, I read on a Rigol supplier's site that my firmware, .05, was the latest so I figured they were numbered like this: 05, 03, 02...  Didn't take long to realize my mistake but by then I'd already tried the unlock.

I tried to understand all 50 pages, I really did!

Thanks Orange.  If only your clear and explicit message had been on page 49.  :)

Not that it matters at this point because everything is hunky dory but, just for curiosity, is there an easy way to restore the serial number?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on July 30, 2013, 04:05:07 pm
not worth summing up, most stuff is dead boring, and the "finale" was somewhat surprising anyway ;-)
already got my DG4062, and i figured 160MHZ would be nize ... will probably start a new thread for it so if somebody wants to join in be there ;)

You can get 200MHz from it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: etc6849 on July 30, 2013, 04:34:06 pm
200MHz from the DG4062?  So this is confirmed (or soon to be)? :)

Is there anyway to unlock the waveform length or is it really only 16kpts?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: synapsis on July 30, 2013, 04:37:16 pm
BRAINZ!
:-+

not worth summing up, most stuff is dead boring, and the "finale" was somewhat surprising anyway ;-)
already got my DG4062, and i figured 160MHZ would be nize ... will probably start a new thread for it so if somebody wants to join in be there ;)

My DG4062 arrived yesterday. There doesn't seem to be a place to enter an upgrade key or anything, but I haven't had much of a chance to mess with it. I've been actually using it. :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: KedasProbe on July 30, 2013, 06:01:00 pm
not worth summing up, most stuff is dead boring, and the "finale" was somewhat surprising anyway ;-)
already got my DG4062, and i figured 160MHZ would be nize ... will probably start a new thread for it so if somebody wants to join in be there ;)
They are not upgradable so there are probably some very small hardware differences, like a different resistor value for ID and/or other output filter.
Anyway I will keep an eye on what you do. (I will not void the warranty of my DG4102 though.)
It's clear that Rigol doesn't document all their SCPI commands.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Wim13 on July 30, 2013, 06:26:12 pm

I have had a topic on this subject of getting 250 Mhz out of a DG4102

https://www.eevblog.com/forum/testgear/250-mhz-out-of-a-rigol-dg4102-a-100-mhz-waveform-generator/ (https://www.eevblog.com/forum/testgear/250-mhz-out-of-a-rigol-dg4102-a-100-mhz-waveform-generator/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on July 30, 2013, 11:21:18 pm
Still having trouble on the blackfin IDA stuff...anyone have binaries?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on July 31, 2013, 12:56:33 am
Something that would still be cool is a firmware hack (now that we know we can load custom firmware) that allows going to 1 nS or even 500 pS timebase.  We know that it is possible from the fram hacking days - now just to find that byte or two in firmware that limits it to 2 nS...
Title: Sniffing the Rigol's internal I2C bus
Post by: zibadun on July 31, 2013, 01:17:12 am
Something that would still be cool is a firmware hack (now that we know we can load custom firmware) that allows going to 1 nS or even 500 pS timebase.  We know that it is possible from the fram hacking days - now just to find that byte or two in firmware that limits it to 2 nS...

Gez you make it sound so easy...
at 500 picosecond you will see exactly one sample per division?  Or do we hack the sampling rate also. Can't be more than a couple of bytes to go to 10 Gsps ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on July 31, 2013, 01:23:31 am
Gez you make it sound so easy...

With the talent here it would be a great tweak!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Leonard Tatzig on July 31, 2013, 10:54:25 am
Ok guys, yesterday it was just to know how to hack this scope.
Today it is a serious problem:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Leonard Tatzig on July 31, 2013, 10:56:32 am
Date of Calibration 09-Jul-2013
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jeremy on July 31, 2013, 10:58:44 am
Hi Leonard,

Have you tried to unlock?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Leonard Tatzig on July 31, 2013, 11:02:11 am
Right now I'm still at work (it's 1 p.m. in Germany). Maybe in the evening when I'm home...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jeremy on July 31, 2013, 11:09:14 am
It would be surprising to see that they have fixed it; this is a hardware revision change and not a software one. If it is indeed related to this, it is probably just the potting of some bits and pieces as well as obfuscation of the jtag port. Seems like not a good enough reason to jump the revision to 2.0 though.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on July 31, 2013, 11:21:13 am
Ok guys, yesterday it was just to know how to hack this scope.
Today it is a serious problem:

I got one yesterday, serial starts the same and I think it is the same batch. Not sure if it was hardware 2.0 but I think so, will check when I get home. Unlocked without a problem  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Leonard Tatzig on July 31, 2013, 11:25:20 am
Ok guys, yesterday it was just to know how to hack this scope.
Today it is a serious problem:

I got one yesterday, serial starts the same and I think it is the same batch. Not sure if it was hardware 2.0 but I think so, will check when I get home. Unlocked without a problem  :-+

Hartstikke bedankt!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on July 31, 2013, 12:38:02 pm
Ok guys, yesterday it was just to know how to hack this scope.
Today it is a serious problem:

Was hoped, but:
I wonder what they changed?  Maybe a board valid for both the DS2000-S version and DS2000? With support for L.A.?
We will have to wait until someone take it apart.  ::)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on July 31, 2013, 12:41:18 pm
Mine will be over 24 hours old when I get home, so if it is 2.0 indeed I might just take a screwdriver and...  :-/O
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on July 31, 2013, 12:45:55 pm
Mine will be over 24 hours old when I get home, so if it is 2.0 indeed I might just take a screwdriver and...  :-/O

Seriously? I'm already impatient.  :scared:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on July 31, 2013, 03:40:01 pm
I just checked and it is hardware version 2.0 indeed. Now I have to eat and go the the gym, so I hope to be able to open it up and make some pictures later this evening.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on July 31, 2013, 05:14:02 pm
I wonder what they changed?  Maybe a board valid for both the DS2000-S version and DS2000? With support for L.A.?

Yes, this is a board with the LA support, but unfortunately it is not populated and one of the things missing is a big BGA.
Pictures after the gym, be patient  ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on July 31, 2013, 05:51:20 pm
I guess it!  8)
Will be the DS2000-[D,Z or ?] (with LA) much more expensive than without LA?
Maybe will be better if you create a new thread for this new revision of HW.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on July 31, 2013, 08:22:54 pm
Maybe will be better if you create a new thread for this new revision of HW.

I did, see https://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0 (https://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: adcajo on August 01, 2013, 03:25:06 pm
Anybody actual verified the 70 -> 200 MHz ? Other turned-on-options are easy to verify, but not everybody has equipment to test the new bandwith...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Wim13 on August 01, 2013, 03:43:53 pm
Yes we did measure the bandwidth...BUT..

For all these new gold diggers, before you turn your gold to lead... >:D

The bandwidth is only valid in the latest Firmware..
See picture of a 2072, measured with different options.


The problem is the frimware versions...

Version 00.00.01.00.05 ONLY supports codes DSAB...DSAH
it does not support bandwidth changes.., YES it shows but is not.

Version 00.01.01.00.02, support codes DSAB...DSAZ

Codes DSA2...9  have no use, they open the model 2102, as also 2202, at the same time, >:D
it is possible that Rigol use these codes for something else, we dont know,
maybe for some other maintenance options. And yes they seems to work oke.

Firmware History:

00.00.01.00.02
00.00.01.00.05

00.01.00.00.03

00.01.01.00.02 Latest.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on August 01, 2013, 05:17:47 pm
Something that would still be cool is a firmware hack (now that we know we can load custom firmware) that allows going to 1 nS or even 500 pS timebase.  We know that it is possible from the fram hacking days - now just to find that byte or two in firmware that limits it to 2 nS...
When I did my initial EEPROM experiments, the 1 nSec containd a nasty bug. please read
https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg247223/#msg247223 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg247223/#msg247223)
Perhaps this is fixed now with the latest FW, but why should they. The 1 nSec is normally not available on the scope
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: trevorklat on August 02, 2013, 12:54:43 am
Brand new DS2072 owner here. Upgraded to latest official Rigol firmware. Used synapsis' Windows-based RiGen-1.zip program to generate license code for a 2202 with all official options (DSAZ). It worked perfectly and now all options are installed and it retained my original S/N. FWIW, I used the input panel on the scope to enter the license code.

I have read this entire thread and I wish to thank everyone who has worked so hard to come up with this ingenious solution.
 :clap:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: etc6849 on August 02, 2013, 01:33:40 am
Wim13: thanks for the bandwidth plot and the post!  I'm a new soon to be gold digger, and this makes me want to try the hack!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: kliklax on August 02, 2013, 04:40:35 am
Brand new DS2072 owner here. Upgraded to latest official Rigol firmware. Used synapsis' Windows-based RiGen-1.zip program to generate license code for a 2202 with all official options (DSAZ). It worked perfectly and now all options are installed and it retained my original S/N. FWIW, I used the input panel on the scope to enter the license code.

I have read this entire thread and I wish to thank everyone who has worked so hard to come up with this ingenious solution.
 :clap:

What version of hardware and software did you start with?  I was wondering if the version 2 hardware is being shipped in the US yet.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Monkey on August 02, 2013, 09:47:14 am
Brand new DS2072 owner here. Upgraded to latest official Rigol firmware. Used synapsis' Windows-based RiGen-1.zip program to generate license code for a 2202 with all official options (DSAZ). It worked perfectly and now all options are installed and it retained my original S/N. FWIW, I used the input panel on the scope to enter the license code.

I have read this entire thread and I wish to thank everyone who has worked so hard to come up with this ingenious solution.
 :clap:

What version of hardware and software did you start with?  I was wondering if the version 2 hardware is being shipped in the US yet.

I'm also a new owner of a DS2072 and done what trevorklat has done above with the new Hardware V2. Everything is working great as far as I know :-+. I have noticed in the Channel Menu there is an selection called "Input" which is greyed out 1M ohms. Does any body knows what this is for? I have a pic below which shows this menu item. The pic below shows a 25Mhz Sinewave with an Amplitude of 4vpp. This is the Maximum Bandwidth I can test with this scope.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: flolic on August 02, 2013, 09:51:27 am

 I have noticed in the Channel Menu there is an selection called "Input" which is greyed out 1M ohms. Does any body knows what this is for?


In version 2 hardware there is possibility to switch input impedance to 50 ohms. But that option is currently not enabled in firmware.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on August 02, 2013, 10:47:57 am
I'm also a new owner of a DS2072 and done what trevorklat has done above with the new Hardware V2.

Sorry, but where trevorklat says that his is the 2.0 version?  :-//
Or what you mean is, that yours DS2072 is 2.0 HW Ver.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Monkey on August 02, 2013, 11:13:47 am
I'm also a new owner of a DS2072 and done what trevorklat has done above with the new Hardware V2.

Sorry, but where trevorklat says that his is the 2.0 version?  :-//
Or what you mean is, that yours DS2072 is 2.0 HW Ver.

Sorry about that, Hope this pic should clarify it |O
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on August 02, 2013, 11:29:18 am
Congratulations, then both are the H.W. version 2.0.  :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tlu on August 03, 2013, 06:08:28 pm
is anyone working on gaining JTAG access to a DSA ? i can provide the schematics on how to patch it up ... dump the memory 0x0-0x20000000 with gdb, and then u should have the curve parameters. contact me if u need jtag access guidance.

I planned on picking up a dsa815-tg and would like to help out on the jtagging process. In Dave's tear-down video, it contains the black fin uC. Will this lead to a potential 3Ghz?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Uup on August 04, 2013, 01:18:00 am

I planned on picking up a dsa815-tg and would like to help out on the jtagging process. In Dave's tear-down video, it contains the black fin uC. Will this lead to a potential 3Ghz?

I doubt it could be done. The next two models up are different instruments. Unfortunately, it appears as though the DSA815 is in a hardware class of its own.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: leafi on August 04, 2013, 01:25:20 am
I would like to thank the team who made this mod possible! I unlocked my DS2072 and it has retained the serial number. If only they would sell it like this for 850 they would sell a ton more. After all I may talk my boss into buying some for work. We have CRAP tektronix scopes... SO pathetic. We purchased one DS1053E for another office and that kicks the butt of all but one tec scope the company owns. It is so funny that a 350 scope will kick the butt of a 1500 scope... so much so he asks me if I think the software engineer could get by with the crappy tek scope and swap the Rigol for it..... WTF the Rigol 1052E is a VERY low end scope, JUST BUY A FEW DS2072s for christ sake! It is insane when you realize that the low end 1052E is better than most of the company equipment in our office. (Does not include my stuff) Get with the program and get the tools you need to do the job!

Thanks Dave for running the forum and making the videos for I would never have known about the Rigol stuff. I very much like watching / listening to your videos while I do my work although it is a bit hard on tear downs as I want to watch but ehhh.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on August 04, 2013, 01:43:33 am
Quote
I doubt it could be done. The next two models up are different instruments. Unfortunately, it appears as though the DSA815 is in a hardware class of its own.

There's no switching to another model, but there exists several software add-ons for the DSA815, including:
              * Advanced Measurement Kit ($499)
              * EMI Filter & Quasi-Peak Detector Kit ($599)
              * VSWR Measurement Kit  ($459)
...and there is a missing space shown in the listed options panel for an additional option which Rigol has not made public yet. It very well could be 10Hz RBW or 3GHz bandwidth
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: leafi on August 04, 2013, 02:08:32 am
How about the DG4000 waveform generators? Are they software unlockable too? I would buy a DG4062 if it can be unlocked to be a DG4162. I just can not justify the extra expense.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on August 04, 2013, 02:31:09 am
How about the DG4000 waveform generators? Are they software unlockable too? I would buy a DG4062 if it can be unlocked to be a DG4162. I just can not justify the extra expense.

There is no serial entry mechanism. It is yet to be determined if there is any other way to unlock or change the model number.

Back to the DG2000, nobody doing JTAG dump? And any help with the blackfin IDA stuff? I still can't get it to compile.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on August 04, 2013, 02:34:01 am
Why do people still care about the DS2000 stuff; it's done isn't it? I mean, it's been unlocked/cracked... why aren't we moving on to other hardware?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on August 04, 2013, 05:26:17 am
Why do people still care about the DS2000 stuff; it's done isn't it? I mean, it's been unlocked/cracked... why aren't we moving on to other hardware?

I'm not done.

"We," meaning you, can move on if you like. But many things from Rigol and others use blackfin so being able to work that in IDA would be nice. And as I said, I'm not done.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tlu on August 04, 2013, 09:38:01 am
Quote
I doubt it could be done. The next two models up are different instruments. Unfortunately, it appears as though the DSA815 is in a hardware class of its own.

There's no switching to another model, but there exists several software add-ons for the DSA815, including:
              * Advanced Measurement Kit ($499)
              * EMI Filter & Quasi-Peak Detector Kit ($599)
              * VSWR Measurement Kit  ($459)
...and there is a missing space shown in the listed options panel for an additional option which Rigol has not made public yet. It very well could be 10Hz RBW or 3GHz bandwidth

Does this mean there is a slight remote chance the dsa815 may be software mod to achieve 10Hz RBW and 3Ghz full span? How is the options entered on the dsa815? Is it just a key entry like the ds2072?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DL5TOR on August 04, 2013, 10:23:07 am
Quote
I doubt it could be done. The next two models up are different instruments. Unfortunately, it appears as though the DSA815 is in a hardware class of its own.

There's no switching to another model, but there exists several software add-ons for the DSA815, including:
              * Advanced Measurement Kit ($499)
              * EMI Filter & Quasi-Peak Detector Kit ($599)
              * VSWR Measurement Kit  ($459)
...and there is a missing space shown in the listed options panel for an additional option which Rigol has not made public yet. It very well could be 10Hz RBW or 3GHz bandwidth

Does this mean there is a slight remote chance the dsa815 may be software mod to achieve 10Hz RBW and 3Ghz full span? How is the options entered on the dsa815? Is it just a key entry like the ds2072?

the Options are enterd jutst with a key similar as the ds2072 there are some differences  to the ds2072 what, that i am checking now. as for the Options there are 4 known Options

TG, AMK, VSWR and EMI

but the Option Screen schows 5 available Options. Option no 3 is unknown.

I have a dump of the Blackfin so if anyone wants it then send me a pm or E-Mail

73 de DL5TOR
Torsten
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tlu on August 04, 2013, 11:45:44 am
Thanks DL5TOR for the provided information. This may be promising? I'm hoping the gurus on here will look into this  :-*.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Spark on August 04, 2013, 01:33:20 pm
From label on box looks like these are the 5 options.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on August 04, 2013, 02:34:40 pm
Bingo!!! 10Hz RBW!

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tlu on August 04, 2013, 03:44:39 pm
Thanks Spark. It looks like 10Hz RBW is software locked (:clap:) but I do not see a bandwidth option (:() so that one maybe a hardware different between the 1.5Ghz and the 3Ghz model.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on August 04, 2013, 05:48:44 pm
10 Hz Resolution Bandwidth (RBW) is a software enhancement to the IF DSP of the DA851. We all have compatible hardware for it, but Rigol China is NOT going to make it available to us. So the ONLY way to get it is to figure out a hack for it. I have the 10 Hz RBW software on my unit (but it is about to expire),  and I understand that there are quite a few others out there that also have it, but just haven't noticed it (?). I kind of wish that I had never seen it, because now I want it permanently.  But it is being saved for the next generation of the DSA800.

The 10 Hz RBW works great and it gives you 10 dB more on sensitivity for seeing the weak signals down in the noise. When measuring IMD of a SSB transmitter the resolution between the two signal and their IMD product is much cleaner, and you can see IMD products that you can't with the 100 HZ RBW. If you are testing for IMD products of -35 dB or better you should be using 10 Hz RBW.

Rigol advertises and spec's that you can differentiate two signal 100 Hz apart. Well this is pushing the reality a bit, but with the 10 Hz RBW it is very easy and clear.
 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jeeff47 on August 04, 2013, 06:12:28 pm
Wow there is a lot of reading here, it took me a few hours to catch up (not looking forward to the other thread with 110 pages, I think I was on page 51 last time I had a chance to jump on here  :P. Great work everyone! I haven't had a chance to try it all out yet and I hope I do it correctly.
Am I able to save an image of my scope onto a flash stick for use at a later time? I thought I read that somewhere way back, (or maybe I'm making it up  ???). Would you then be able to revert it back to how it was originally set from factory? I'm sure if it were possible someone on here would have thought about it already but I figured I would inquire either way.   

Thanks again for everyones hard work and time, its quite impressive what has been done.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on August 04, 2013, 09:25:53 pm
Re. 10 Hz RBW.

I should have clarified that the 10 Hz RBW came on my DSA815-TG as a Trial Option. This of course was an unexpected treat at the time, until I realized that it was a Trial Option that would be gone when all the other Trial Option expired. Except this particular option could not be purchased! (at any price). So what is with this 'Chinese teaser'?

I was told that this option was sold on units at the Dayton Hamfest.  So what is a Hamfest anyway? -  Just kidding!

I purchased my unit directly from a test equipment distributor, and so did some others that were graced with this temporary treat.

If anyone knows how to get an image of my units SSD, and knows what to do with it, please advise how and I will provide a copy of it to you. If it had a removable hard drive, I would already have had made an image of it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jsykes on August 05, 2013, 07:43:38 am
How do you get to the 10Hz option? I purchased my 815 in April SN# DSA8A1444xxxxx. Serial# indicates it was manufactured week 44 of 2012. I have never seen a selection for 10Hz on any menu.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: StubbornGreek on August 05, 2013, 08:16:00 am
I only now realized that I never said thank you to all those involved in this thread for their efforts hard work.  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on August 05, 2013, 12:30:15 pm
Quote of jsykes' question (Reply #800 on: Today at 05:43:38 PM):

How do you get to the 10Hz option? I purchased my 815 in April SN# DSA8A1444xxxxx. Serial# indicates it was manufactured week 44 of 2012. I have never seen a selection for 10Hz on any menu.

---------------------------------------------------------------------------

Answer:

If you have it then it will be listed as a Trial (software) Option (NOT hardware). Then you have it, if NOT then there is no way currently to get, or purchase it.

The guy that can resolve this will be our Super Hero.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on August 05, 2013, 08:57:12 pm
DL5TOR, can you send me that DSA815 Blackfin dump you were talking about? Thanks!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on August 06, 2013, 07:02:51 pm
bfin ida cpu module
be warned however, it has bugs - if aX registers are in use (math heavy stuff) you can not trust the ida output, take it from objdump or gdb bfin if so.
the bfin stuff is kraters work, not mine. those modules where compiled on a x86 32 bit, for ida 6.2 - might not work with other ida versions.

im currently working on enhancing the bfin flirt tools from krater or probably rewrite them because somehow they dont seem to work right.
then it should be possible to get better matchrate for VDSP libraries to the firmwares - which will ease reversing them.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ilya on August 06, 2013, 09:45:37 pm
After installing the keys on my DS2072 and making it 2202 I've got a strange bug that corrupts saved to external USB key images (format independent). Has anybody noticed this?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on August 07, 2013, 02:07:50 am
bfin ida cpu module
be warned however, it has bugs - if aX registers are in use (math heavy stuff) you can not trust the ida output, take it from objdump or gdb bfin if so.
the bfin stuff is kraters work, not mine. those modules where compiled on a x86 32 bit, for ida 6.2 - might not work with other ida versions.

im currently working on enhancing the bfin flirt tools from krater or probably rewrite them because somehow they dont seem to work right.
then it should be possible to get better matchrate for VDSP libraries to the firmwares - which will ease reversing them.
thanks man, it's a start and should be good enough for looking for what I am looking for. much appreciated

After installing the keys on my DS2072 and making it 2202 I've got a strange bug that corrupts saved to external USB key images (format independent). Has anybody noticed this?
nope, haven't tried, but I may do that now. or maybe I tried but didn't notice it, can't remember. any type is corrupted?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Marc M. on August 07, 2013, 02:30:54 am
After installing the keys on my DS2072 and making it 2202 I've got a strange bug that corrupts saved to external USB key images (format independent). Has anybody noticed this?
That's unfortunate :(.  I just checked mine saving a .png and there's no corruption.  I'm running version .02 and had been prior to installing any keys.  Also, I had used both DSA9 and DSAZ keys prior without any issues.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tlu on August 07, 2013, 04:11:49 am
Can someone who recently purchased a dsa815 or dsa815-tg verify that the 10hz RBW is part of the trial option? There seems to be conflicting results at the moment.

If the 10hz RBW is not part of the trial option, does it mean it may actually be hardware specific? Any thoughts on this.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Marc M. on August 07, 2013, 04:53:45 am
Can someone who recently purchased a dsa815 or dsa815-tg verify that the 10hz RBW is part of the trial option? There seems to be conflicting results at the moment.

If the 10hz RBW is not part of the trial option, does it mean it may actually be hardware specific? Any thoughts on this.
Purchased my 815-TG in May of this year.  It came without any trial options installed.  Info as follows:

S/N: DSA8A1449xxxxx
Main Board: 00.04
RF FPGA: 00.04
Digital FPGA: 00.04
Firmware: 00.01.05
Boot: 00.01.02

I doubt there's hardware differences, likely just a marketing decision by Rigol to include teaser options to stimulate sales of them.  I have 5 options listed under Option Info so presumably one is for the 10 Hz RBW. 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ilya on August 07, 2013, 08:23:34 am
That's unfortunate :(.  I just checked mine saving a .png and there's no corruption.  I'm running version .02 and had been prior to installing any keys.  Also, I had used both DSA9 and DSAZ keys prior without any issues.

Yes, all formats are corrupted and look the same. I've noticed that it only happens when the waveform is recorded and the scope is in stop mode (only when there's a lable "Record=xxxx" in place where image is corrupt). In "run" and "stop" modes images come out fine fine. Can you check this on yours please?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Marc M. on August 07, 2013, 08:45:04 am
Yes, all formats are corrupted and look the same. I've noticed that it only happens when the waveform is recorded and the scope is in stop mode (only when there's a lable "Record=xxxx" in place where image is corrupt). In "run" and "stop" modes images come out fine fine. Can you check this on yours please?
I set my scope up as you described and I was able to replicate the problem.  The 'Record = #' display gets corrupted when the image is saved.  I believe Marmad has been keeping track of any bugs discovered in the "REVIEW - Rigol DS2072 First impressions..." thread.  I'll PM him a link to your post to be sure he's aware of it so he can add it to the list.

Re-reading your original post, you mention this happened after installing the 2202 key.  Prior to installing the key did you save any pictures using the same settings that weren't corrupted?  I reverted my scope back to a 2072 and tried saving it again.  It was still corrupting the Record # display portion so I don't think it's related to the keys.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: kosh on August 07, 2013, 11:32:28 am
Re-reading your original post, you mention this happened after installing the 2202 key.  Prior to installing the key did you save any pictures using the same settings that weren't corrupted?  I reverted my scope back to a 2072 and tried saving it again.  It was still corrupting the Record # display portion so I don't think it's related to the keys.

I have tried this on my brand new DS2072 without any key installed yet and I can confirm this behaviour. But it seems this bug only happens when using the storage menu. If I save an image by using the print button there is no corruption.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ilya on August 07, 2013, 07:16:58 pm
Re-reading your original post, you mention this happened after installing the 2202 key.  Prior to installing the key did you save any pictures using the same settings that weren't corrupted?  I reverted my scope back to a 2072 and tried saving it again.  It was still corrupting the Record # display portion so I don't think it's related to the keys.

I'm now starting to doubt if I made the screen copies in that mode. I might've just hit stop and save a picture. So I assume that this issue has no connection to the keys.

Btw, how on earth did you revert your 2072 back to 2072? Mine is stuck in 2202 mode and I can't revert it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sha256 on August 07, 2013, 07:22:44 pm
I have tried this on my brand new DS2072 without any key installed yet and I can confirm this behaviour. But it seems this bug only happens when using the storage menu. If I save an image by using the print button there is no corruption.

I upgraded my DS2072 and can confirm kosh's findings.  If I use the Storage Menu I get the corruption but using the print button seems to work fine.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sha256 on August 07, 2013, 08:16:27 pm
I have an unlocked DS2072 that I do NOT have corrupted images using either method to get a snapshot of the screen.

AFAIK it only does it when using the Storage Menu and the Waveform Record.  The corruption is of the little window that shows what frame/waveform your currently viewing.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ilya on August 07, 2013, 08:30:43 pm
AFAIK it only does it when using the Storage Menu and the Waveform Record.  The corruption is of the little window that shows what frame/waveform your currently viewing.

Correct. This looks like a general bug, that's not connected to keys in any way.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JimFouch on August 07, 2013, 08:46:38 pm
I stand corrected. I DO have the picture corruption on my DS2072 when using the Storage Menu.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Marc M. on August 08, 2013, 12:36:53 am
... how on earth did you revert your 2072 back to 2072? Mine is stuck in 2202 mode and I can't revert it.
I have a couple of Python scripts that I modified (posted earlier in this thread by another user - somewhere ???) on my desktop which will install and uninstall the options.   The uninstall just sends the SCPI command:   ":SYSTem:OPTion:UNINSTall" (the script also preserves the user settings).  I've had no problems with S/N corruption after installing/uninstalling the original temp. DSA9/DSAZ keys or the generated key dozens of times.  You can also send the SCPI command via Rigol Ultra Sigma.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Maalobs on August 08, 2013, 02:08:42 am
Thanks for the tip, I went back and took a closer look at those Python-scripts.
I had tried fiddling with the SCPI control panel in Ultra Sigma before, but never managed to get the :SYSTEM:OPTION:UNINSTALL command to do anything, it just ended in a timeout.
I saw now that one of the Python-routines hammers the SCPI-commands up to 30 times, so that got me thinking about the control panel again.
I started Ultra Sigma and switched the control panel to Advanced Mode, and changed the timeout setting to 10.000ms, but still no dice with the uninstall-command.
Another thing I noticed was that one of the Python-routines does an expect-like check of the "*IDN?"-prompt, while the other does not.
Now I accidentally discovered (duh..) in the control panel that you can actually backspace away the *IDN? part, so I did it, and ran :SYSTEM:OPTION:UNINSTALL without any "prompt" ahead of it.
It took a few seconds, but this time it worked!

The scope made a loud CLICK noise and lit up both channels, and my DS2102 now identified itself as a DS2072! O0
I powercycled and tried installing my DSAZ-code through SCPI, but that still wouldn't work, even with the special settings in the control panel.
So I entered the DSAZ-code through the on-screen keyboard as I had originally done, and it worked.
After another powercycle I had a DS2202 with all options enabled again. :-+

The purpose of my little exercise was that I had originally used a DSAR-code, which enabled 100M in the Options-list.
Later when the complete code-matrix was revealed to us in the thread, I entered the DSAZ-code, and this combination resulted in the Options-list showing both 100M and 200M, much like the DSA9-code I assume.

With the help of another DS2102-owner here at the forum, I was able to surmise that the 100M-option should NOT be displayed when activating a DS2102 to DS2202, so I wanted it gone.
Because who knows what could happen down the line...
First of all it's a clear sign that the options have been tampered with, and I suppose that discovering this state in the instrument could be targeted by Rigol in future firmware-updates in the coming antihack-war. :box:
Not to mention that it's an invalid state in the instrument. I've worked enough with code monkeys in my career to know that it only takes a single if-clause that checks for the bandwidth-options in the wrong order to send me down a code path where I get 100M precision instead of 200M, or whatever else undefined behaviour that could result from something like that.
Maybe I'm too paranoid about this, it's quite possible, but I prefer reducing the risks of possible problems.

Thanks again! :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JimmyMz on August 08, 2013, 02:52:54 am
I tried fiddling with the SCPI control panel in Ultra Sigma, but never managed to get the :SYSTEM:OPTION:UNINSTALL command to work, it always ended in a timeout.
I discovered in the control panel that you can backspace the "*IDN?" typing, so I did, and typed :SYSTEM:OPTION:UNINSTALL without "*IDN?" ahead of it, and this time it worked! The scope made a loud CLICK noise and lit up both channels, and my DS2102 now identified itself as a DS2072.
I also had to erase "*IDN?" but I typed SYSTEM:OPTION:UNINSTALL <---note that there is no colon at the beginning of the word 'SYSTEM,' to make the command work for me. Although, Ultra Sigma gave an error message on this command, the scope carried out the command, posting official options erased (or something of that nature) at the bottom of the DS2102 screen. I suppose I should have reported this information sooner, so I could have saved you some effort.  :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rory on August 08, 2013, 04:17:09 am
Can someone who recently purchased a dsa815 or dsa815-tg verify that the 10hz RBW is part of the trial option? There seems to be conflicting results at the moment.

If the 10hz RBW is not part of the trial option, does it mean it may actually be hardware specific? Any thoughts on this.

My 815-TG came from Tequipment a week ago.

The options listed in the License menu are not labeled but the 30 and 10 hz RBW items show up in the RBW item under the BW/DET menu.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tlu on August 08, 2013, 04:37:48 am
Can someone who recently purchased a dsa815 or dsa815-tg verify that the 10hz RBW is part of the trial option? There seems to be conflicting results at the moment.

If the 10hz RBW is not part of the trial option, does it mean it may actually be hardware specific? Any thoughts on this.

My 815-TG came from Tequipment a week ago.

The options listed in the License menu are not labeled but the 30 and 10 hz RBW items show up in the RBW item under the BW/DET menu.

So I guess it does comes with the 10hz RBW option since I'm assuming you can make that selection under the BW/DET menu. Can you provide an image of what options it did came with? I'm curious as to see what you mean when you say options are not labeled.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Marc M. on August 08, 2013, 07:25:09 am
... I'm curious as to see what you mean when you say options are not labeled.
Under the Options menu, the 5 items are simply numbered 1 to 5 without any labels indicating what each represents.  I know item #1 is the Tracking Generator option because that's the only option enabled on my unit (I wasn't lucky enough to get any trial options  :( ).  Earlier in this thread (#794) Spark posted a picture of a box label listing the included options in a Yes/No format (just like the option screen) with the TG also as the top option.  If we correlate that sequence to the license screen, the option numbers are:

1) Tracking Generator
2) Advanced Measurement Kit
3) 10 Hz RBW
4) EMI/Quasi Peak
5) VSWR

The only options offered so far are 1,2,4, & 5.  Since 5 options are listed on all the 815's, the 5th option they provide space for (presumably option #3) is for the 10 Hz RBW and is available on all 815's with the correct key.  Out of the 5 options, 10 Hz RBW is the one option I probably would have paid for if they had made it available  :-//.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jamesb on August 08, 2013, 01:30:27 pm
The only options offered so far are 1,2,4, & 5.  Since 5 options are listed on all the 815's, the 5th option they provide space for (presumably option #3) is for the 10 Hz RBW and is available on all 815's with the correct key.  Out of the 5 options, 10 Hz RBW is the one option I probably would have paid for if they had made it available  :-//.

You are not alone in this .. there are a growing number of people who are interested in this feature and if Rigol are too pig-headed to provide this as a paid-for option, I imagine that the DSA815-TG hacking effort will grow considerably.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on August 08, 2013, 01:43:54 pm
Quote
You are not alone in this .. there are a growing number of people who are interested in this feature and if Rigol are too pig-headed to provide this as a paid-for option, I imagine that the DSA815-TG hacking effort will grow considerably.

Right now, Rigol doesn't want to compete with itself. By allowing their $1500 DSA to be better in every respect than their $2500 DSA with the exception of being 0.5GHz less in BW, then for all intensive purposes, noone will purchase the more expensive unit. Once Rigol discontinues their next-teir-up spectrum analyzer and releases a new $2500 price range DSA that can topple the DSA815 even with 10HZ RBW, THEN Rigol will offer to sell the 10RBW add-on for the DSA-815.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jamesb on August 08, 2013, 01:47:42 pm
Right now, Rigol doesn't want to compete with itself. By allowing their $1500 DSA to be better in every respect than their $2500 DSA with the exception of being 0.5GHz less in BW, then for all intensive purposes, noone will purchase the more expensive unit. Once Rigol discontinues their next-teir-up spectrum analyzer and releases a new $2500 price range DSA that can topple the DSA815 even with 10HZ RBW, THEN Rigol will offer to sell the 10RBW add-on for the DSA-815.

To be honest, your speculation as to Rigol's motives are rather obvious. I was merely stating that such tactics will only further drive the efforts to see the 10Hz RBW option become permanently available to those who are willing to undertake the effort to hack the DSA815-TG firmware to shreds.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on August 08, 2013, 02:26:26 pm
Quote
To be honest, your speculation as to Rigol's motives are rather obvious. I was merely stating that such tactics will only further drive the efforts to see the 10Hz RBW option become permanently available to those who are willing to undertake the effort to hack the DSA815-TG firmware to shreds.

Since we're being honest, that is something that I hope to see done even if Rigol does release the add-on for a fee :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: etc6849 on August 09, 2013, 02:16:16 am
I really don't know how I sleep at night!?!  Seriously, I just tried the hack last night on my DS2072, works great!  Thanks for all your hard work :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jasonbrent on August 09, 2013, 05:21:55 am
It isn't clear to me from the thread (yes, I've read it all)... does the RiGen generator work with the DP832 Rigol DC power supply to enable options? (and as an aside, if it does, has anyone figured out if the 832's screen is full color or just a couple of different monochrome colors? in other words, do we think it can be turned into a full blown 832A?).

-jbl
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: H.O on August 09, 2013, 05:36:21 am
Hi,
Has anyone tried using the protocol decoders?
My DS4000 series came without any trial licenses (at the time I didn't even know there WAS trial licenses to be had) so I never got to actually try it before installing the "license". Last night I tried the RS232 decoder and it's so PAINFULLY slow it's almost unusable. I don't know if I'm doing it wrong or what (don't think so) but geez, right now I'm SO glad I didn't pay for it.

I wonder if it's a firmware thing.... I'd appreciate if anyone else could report your experience using the RS232 (or any other) decoder, preferably on a DS4000 series (but 2000 would be interesting too) and what firmware version you're running, thanks!

Speaking of firmware, I see that Rigols website (http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm) now lists the latest firmware, as of July 31, for the DS4000 to be 00.02.00 when it just a month ago was 00.01.00.07 or something like that (I'm currently running neither of those). I wonder if they have already implemented a fix for the hack....anyone knows?

Thanks!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tlu on August 09, 2013, 07:39:58 am
... I'm curious as to see what you mean when you say options are not labeled.
Under the Options menu, the 5 items are simply numbered 1 to 5 without any labels indicating what each represents.  I know item #1 is the Tracking Generator option because that's the only option enabled on my unit (I wasn't lucky enough to get any trial options  :( ).  Earlier in this thread (#794) Spark posted a picture of a box label listing the included options in a Yes/No format (just like the option screen) with the TG also as the top option.  If we correlate that sequence to the license screen, the option numbers are:

1) Tracking Generator
2) Advanced Measurement Kit
3) 10 Hz RBW
4) EMI/Quasi Peak
5) VSWR

The only options offered so far are 1,2,4, & 5.  Since 5 options are listed on all the 815's, the 5th option they provide space for (presumably option #3) is for the 10 Hz RBW and is available on all 815's with the correct key.  Out of the 5 options, 10 Hz RBW is the one option I probably would have paid for if they had made it available  :-//.

Thanks for clearing that up Marc. I'm pretty optimistic now that the remaining option would be the 10hz RBW and it pre-built into the dsa815.

Has anyone take a crack at an attempt to see if this option is hidden somewhere in the firmware? It's probably a matter of time before someone will figure out how to enable this option. Can't wait for mine to arrive.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: nedos on August 09, 2013, 03:01:34 pm
Speaking of firmware, I see that Rigols website (http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm) now lists the latest firmware, as of July 31, for the DS4000 to be 00.02.00 when it just a month ago was 00.01.00.07 or something like that (I'm currently running neither of those). I wonder if they have already implemented a fix for the hack....anyone knows?

I just upgraded to 02.00. Everything still works. I entered my option key after upgrading to 02.00.

Thanks for the hard work, guys!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: synapsis on August 09, 2013, 05:07:51 pm
Hi,
Has anyone tried using the protocol decoders?
My DS4000 series came without any trial licenses (at the time I didn't even know there WAS trial licenses to be had) so I never got to actually try it before installing the "license". Last night I tried the RS232 decoder and it's so PAINFULLY slow it's almost unusable. I don't know if I'm doing it wrong or what (don't think so) but geez, right now I'm SO glad I didn't pay for it.

I wonder if it's a firmware thing.... I'd appreciate if anyone else could report your experience using the RS232 (or any other) decoder, preferably on a DS4000 series (but 2000 would be interesting too) and what firmware version you're running, thanks!

Speaking of firmware, I see that Rigols website (http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm) now lists the latest firmware, as of July 31, for the DS4000 to be 00.02.00 when it just a month ago was 00.01.00.07 or something like that (I'm currently running neither of those). I wonder if they have already implemented a fix for the hack....anyone knows?

Thanks!

I've used the RS232 decoder on a DS2000. The only issue I had was that using the preset 57600 baud didn't work correctly, so I went into the user baud rate setting and tweaked the rate on a known packet of data. This was before I upgraded to 05.

Other than that, it didn't have any missing bytes and it ran at whatever timebase I used. The table even updated faster than I could read it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on August 09, 2013, 05:14:45 pm
I've used the RS232 decoder on a DS2000. The only issue I had was that using the preset 57600 baud didn't work correctly, so I went into the user baud rate setting and tweaked the rate on a known packet of data. This was before I upgraded to 05.
Other than that, it didn't have any missing bytes and it ran at whatever timebase I used. The table even updated faster than I could read it.

It seemed like the decoder would only decode from what is visible on the screen and not from the trigger point, has anyone else experienced this?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: H.O on August 09, 2013, 07:14:26 pm
Thanks guys,
In my case I send a string "Test x" where x "counts" from A to Z. I'm sending at 9600baud with 100ms delay between packets. Pretty relaxed if you ask me.

On the scope, set to 1ms/div, triggering on falling edge, I can see the trace and the databits in the last byte "counting", however the decoded data shows A, O, C, Q, E, S, G, U, I, W... as the last byte which tells me there's 1300-1400ms between updates of the decoded data on the screen. And when the decoded data actually IS updated the "sweep" freezes for hundreds of ms. Changing the time/div from 1ms/div to 500us makes it even slower.

Changing the memory depth from Auto to 7kpts (lowering the sample rarte from 2GSa/s to 500k) makes it "a lot" faster but it's still "skipping" (A, D, G, J, M, P...) and now the triggering becomes unstable (which might be "fixable" with some holdoff - didn't try).

If I'm not doing it wrong I'm going to call it on the edge of useless, I really do hope I AM doing something wrong OR that a newer firmware fixes it.

Anyone else with a DS4000 out there that care to try it?

Thanks again!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jasonbrent on August 11, 2013, 05:58:59 am
According to tequipment, my DS2072 (replacing a 3 day old siglent 1102cml that died(!)) should ship on 8/16. I'm hoping it's hardware version 2.0 and that I can squeak 100Mhz+ out of it using the info in this thread.

-jbl
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: fake-name on August 11, 2013, 06:21:37 am
Hi,
Has anyone tried using the protocol decoders?
My DS4000 series came without any trial licenses (at the time I didn't even know there WAS trial licenses to be had) so I never got to actually try it before installing the "license". Last night I tried the RS232 decoder and it's so PAINFULLY slow it's almost unusable. I don't know if I'm doing it wrong or what (don't think so) but geez, right now I'm SO glad I didn't pay for it.

I wonder if it's a firmware thing.... I'd appreciate if anyone else could report your experience using the RS232 (or any other) decoder, preferably on a DS4000 series (but 2000 would be interesting too) and what firmware version you're running, thanks!

Speaking of firmware, I see that Rigols website (http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm) now lists the latest firmware, as of July 31, for the DS4000 to be 00.02.00 when it just a month ago was 00.01.00.07 or something like that (I'm currently running neither of those). I wonder if they have already implemented a fix for the hack....anyone knows?

Thanks!

The decoders on my 4000 series were pretty laggy before I used the trial keys. They don't seem to have changed after installing the key.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DL5TOR on August 11, 2013, 01:49:52 pm
some good News for the DSA815:

The licensekey uses the same algo and keys then the DS2000 but the Serialnumber used is somthing different

also intresting is that i found the srings DSA830A DSA830 DSA820 and DSA815 in there
I am still in the porces of finding the rest

i hope i find somthing
73
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: BravoV on August 11, 2013, 01:53:19 pm
This thread is getting better and better everyday !  :-+  :clap:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on August 11, 2013, 02:06:17 pm
Quote
some good News for the DSA815:

The licensekey uses the same algo and keys then the DS2000 but the Serialnumber used is somthing different

also intresting is that i found the srings DSA830A DSA830 DSA820 and DSA815 in there
I am still in the porces of finding the rest

i hope i find somthing

You are my hero! Please keep all the goods on this forum thread so we can all follow along. All our base are belong to you!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jsykes on August 11, 2013, 07:05:18 pm
Quote
some good News for the DSA815:

The licensekey uses the same algo and keys then the DS2000 but the Serialnumber used is somthing different

also intresting is that i found the srings DSA830A DSA830 DSA820 and DSA815 in there
I am still in the porces of finding the rest

i hope i find somthing

You are my hero! Please keep all the goods on this forum thread so we can all follow along. All our base are belong to you!

 
I second this.
In view of the Rigol model number system format it would seem that the DSA820 would be a 2GHz model and the 830A a 3GHz model with 10Hz RBW but that doesn't seem to make sense since there would seemingly be no difference between those and some of the DSA1000 models. I may be wrong, but I believe the DSA815 was released after the DSA1000 series. Maybe they were being designed at the same time with the 1000's being released first and the thought of 820 and 830 models was dropped in favor of the 1000 models...just a guess.
Thanks for everyone's hard work. 10Hz RBW on the DSA815 would especially be a godsend for us.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: geostep on August 11, 2013, 09:53:25 pm
According to tequipment, my DS2072 (replacing a 3 day old siglent 1102cml that died(!)) should ship on 8/16. I'm hoping it's hardware version 2.0 and that I can squeak 100Mhz+ out of it using the info in this thread.

-jbl

My DS2072 was delivered from tequipment last Thursday the 8th.  Mine came with hardware rev 1.0.1.

The DS2072 started having problems right away.  >:(  The front panel controls started to randomly freeze.  All buttons, knobs and lights became unresponsive.  It's done it several times in the last few days.  Although the display continued to work worked fine and displayed signals no problem.  The only way to unfreeze it was to reboot.    |O

I updated the firmware from 00.01.00.00.03  to  00.01.01.00.02  but that did not help.  Also the select knob was rather touchy and often would overshoot the desired setting by a few, erm, settings.

Needless to say I'm going to have to call tequipment on Monday and see about getting it replaced. *sigh*

- George
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tlu on August 11, 2013, 11:15:14 pm
some good News for the DSA815:

The licensekey uses the same algo and keys then the DS2000 but the Serialnumber used is somthing different

also intresting is that i found the srings DSA830A DSA830 DSA820 and DSA815 in there
I am still in the porces of finding the rest

i hope i find somthing
73

Nice find. Hopefully, this will manifest into a 3Ghz BW and 10Hz RBW. Keep up the good work.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: warp_foo on August 12, 2013, 12:48:17 am
With 57 pages on this topic, has anyone summarized what the current state and process of the DS2000 hack is? I'd like to buy a DS2072, but before pulling the trigger, I'd like to make sure I understand what's been discussed here.  ;)

Thanks,

m
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on August 12, 2013, 01:51:30 am
According to tequipment, my DS2072 (replacing a 3 day old siglent 1102cml that died(!)) should ship on 8/16. I'm hoping it's hardware version 2.0 and that I can squeak 100Mhz+ out of it using the info in this thread.

-jbl

My DS2072 was delivered from tequipment last Thursday the 8th.  Mine came with hardware rev 1.0.1.

The DS2072 started having problems right away.  >:(  The front panel controls started to randomly freeze.  All buttons, knobs and lights became unresponsive.  It's done it several times in the last few days.  Although the display continued to work worked fine and displayed signals no problem.  The only way to unfreeze it was to reboot.    |O

I updated the firmware from 00.01.00.00.03  to  00.01.01.00.02  but that did not help.  Also the select knob was rather touchy and often would overshoot the desired setting by a few, erm, settings.

Needless to say I'm going to have to call tequipment on Monday and see about getting it replaced. *sigh*

- George

My select knob was a bit problematic, I just worked it a bit and now it's fine.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jasonbrent on August 12, 2013, 01:55:29 am
With 57 pages on this topic, has anyone summarized what the current state and process of the DS2000 hack is? I'd like to buy a DS2072, but before pulling the trigger, I'd like to make sure I understand what's been discussed here.  ;)

Thanks,

m

^^ This. I ordered a DS2072 that should ship this coming week... My impression from the thread is that I can turn it into a fully-featured ~200Mhz scope with what was learned in this thread. Or at least a 70Mhz scope with all features enabled. I'm hoping it's the former rather than the latter. :-)

-jbl
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Chalky on August 12, 2013, 02:08:58 am
With 57 pages on this topic, has anyone summarized what the current state and process of the DS2000 hack is? I'd like to buy a DS2072, but before pulling the trigger, I'd like to make sure I understand what's been discussed here.  ;)

Thanks,

m

^^ This. I ordered a DS2072 that should ship this coming week... My impression from the thread is that I can turn it into a fully-featured ~200Mhz scope with what was learned in this thread. Or at least a 70Mhz scope with all features enabled. I'm hoping it's the former rather than the latter. :-)

-jbl
The former!  :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jasonbrent on August 12, 2013, 02:14:37 am
Yay. :-)   :phew:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: warp_foo on August 12, 2013, 02:19:31 am
With 57 pages on this topic, has anyone summarized what the current state and process of the DS2000 hack is? I'd like to buy a DS2072, but before pulling the trigger, I'd like to make sure I understand what's been discussed here.  ;)

Thanks,

m

^^ This. I ordered a DS2072 that should ship this coming week... My impression from the thread is that I can turn it into a fully-featured ~200Mhz scope with what was learned in this thread. Or at least a 70Mhz scope with all features enabled. I'm hoping it's the former rather than the latter. :-)

-jbl
The former!  :)

Awesome. Is there a summary of 'what was learned in this thread' with the relevant bits and the process the hack follows to make a 2072 into a 2202?

Thanks,

m
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tlu on August 12, 2013, 04:26:08 am
Getting back to the dsa815, can the 10Hz RBW be enabled with the other trial options? Just curious as no one has mentioned of being able to enable it since it shows up as an unlabeled option.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: synapsis on August 12, 2013, 06:36:12 am
With 57 pages on this topic, has anyone summarized what the current state and process of the DS2000 hack is? I'd like to buy a DS2072, but before pulling the trigger, I'd like to make sure I understand what's been discussed here.  ;)

Thanks,

m

^^ This. I ordered a DS2072 that should ship this coming week... My impression from the thread is that I can turn it into a fully-featured ~200Mhz scope with what was learned in this thread. Or at least a 70Mhz scope with all features enabled. I'm hoping it's the former rather than the latter. :-)

-jbl
The former!  :)

Awesome. Is there a summary of 'what was learned in this thread' with the relevant bits and the process the hack follows to make a 2072 into a 2202?

Thanks,

m

Reply #572 has (one of the) Linux versions of the keygen, reply #574 has the Windows version. I think it's page 39ish with default forum settings.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: davidefa on August 12, 2013, 08:38:28 am
Thanks guys,
In my case I send a string "Test x" where x "counts" from A to Z. I'm sending at 9600baud with 100ms delay between packets. Pretty relaxed if you ask me.

On the scope, set to 1ms/div, triggering on falling edge, I can see the trace and the databits in the last byte "counting", however the decoded data shows A, O, C, Q, E, S, G, U, I, W... as the last byte which tells me there's 1300-1400ms between updates of the decoded data on the screen. And when the decoded data actually IS updated the "sweep" freezes for hundreds of ms. Changing the time/div from 1ms/div to 500us makes it even slower.

Changing the memory depth from Auto to 7kpts (lowering the sample rarte from 2GSa/s to 500k) makes it "a lot" faster but it's still "skipping" (A, D, G, J, M, P...) and now the triggering becomes unstable (which might be "fixable" with some holdoff - didn't try).

If I'm not doing it wrong I'm going to call it on the edge of useless, I really do hope I AM doing something wrong OR that a newer firmware fixes it.

Anyone else with a DS4000 out there that care to try it?

Thanks again!

I have a DS2072, I have duplicated your setup ( a pc sending 'Test X' at 9600 baud with a 100mS delay between strings ):
- 1mS/div, 1MSa/S, 14K memory
- trigger normal ( I can't get a stable triggering in auto, quite annoying )
- serial decoder enabled

I can see the decoded bus 'changing' on the fly, but I can't see the sequence A B C... ( the letters are changing 10 times a second )
I connect a second scope on the trigger output and I can see a 10Hz stable signal ( so the scope isn't missing any string )
If I record a few seconds of signal ( this is an easy and great feature af this scope, isn't it? ) and later review the recording a can see clearly the sequence of A B C... with no missing letters
Hope this helps

P.S. thanks to everyone for this great tread
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on August 12, 2013, 09:02:06 am
The decoding seems a lot slower than the waveform update speed, if you set your timebase slow enough and send a long string of RS232 characters you can see it building the decode. Not really a problem I think, you are not going to read along real time anyway, at least I'm not. I tested some other stuff too, and found that you can really fill the memory and then 'browse' through and it will decode, but you have to stop the auto triggering. If it is in auto trigger mode you can't even scroll the data: the waveform will scroll but the decoded output will stay in place. And it even shows the decoded data in zoom mode!

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: H.O on August 12, 2013, 10:13:00 am
Thank you,
To clarify, on my DS4000, sending 10 packets/strings per second, the waveform updates properly 10 times per second as expected (running in Normal mode) - EXCEPT when the decoded data is actually updated every 1300-1400ms or so - at that instant the waveform frezzes for a couple of 100ms. I have not checked the trigger output to see if the aquisition stops or if it's just the screen update.

I can capture long events at slower timebase and then scroll thru it, zooming in or use waveform record to capture multiple packets and then scroll thru and decode them, no problems, I just find the actual decoding process painfully slow.

I obviously expect it to fall apart at some point but really, 1300-1400ms to decode a string of 6 chars and display the data seems awfully slow. If it's not decoding the data in "real time" how will it possible to trig on a specific char/byte, something I haven't tried yet?

I know the Agilent 3000x series scope do the decoding in hardware, something Rigol clearly isn't doing so I don't expect the performance to be like what can be seen in this demonstration CAN decoding on Agilent 3000x (https://www.youtube.com/watch?v=Vap6z-3AjkA#ws) but IMHO the Rigol is REALLY slow.

Thanks again!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on August 12, 2013, 10:26:06 am
If it's not decoding the data in "real time" how will it possible to trig on a specific char/byte, something I haven't tried yet?

Is that possible? I have not seen a menu option to do that (DS2000)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: H.O on August 12, 2013, 10:41:09 am
Hi,
Yes, I'm pretty sure you should be able to trig on a specific byte/char, both on the DS2000 (might be an option) and on the DS4000 but again, seeing how slow the decoder is I might have misunderstood it completely....

Take a look at page 5-35 in this DS2000 user guide. (http://www.batronix.com/pdf/Rigol/UserGuide/DS2000_UserGuide_EN.pdf)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on August 12, 2013, 10:53:34 am
Hi,
Yes, I'm pretty sure you should be able to trig on a specific byte/char, both on the DS2000 (might be an option) and on the DS4000 but again, seeing how slow the decoder is I might have misunderstood it completely....

Take a look at page 5-35 in this DS2000 user guide. (http://www.batronix.com/pdf/Rigol/UserGuide/DS2000_UserGuide_EN.pdf)

Ah, I see. Must have skipped that part of the page. I think there's still hope, because the trigger and the decode are different functions.
The RS232 trigger is standard available, and to make it work it must be implemented in hardware. The RS232 decode is an option and by looking at the speed it is implemented in software.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on August 12, 2013, 02:29:05 pm
anyone with a DSA around and willing to test some keys ? ... pm me
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on August 12, 2013, 02:37:55 pm
Quote
anyone with a DSA around and willing to test some keys ? ... pm me

I have a DSA815-TG. What keys do you have for me?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on August 12, 2013, 02:40:20 pm
i dont know ;-) i dont have a DSA, but i believe the i have found the private key for it so i could generate keys, other than option 1 (which i was told is the TG) - pm me with serial if u are willing to try.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on August 12, 2013, 02:43:45 pm
Quote
i dont know ;-) i dont have a DSA, but i believe the i have found the private key for it so i could generate keys, other than option 1 (which i was told is the TG) - pm me with serial if u are willing to try.

I'll message you with the serial number as soon as I get back to my desk. I'm assuming this shouldn't de-activate that option 1? I like my tracking generator :)

Is this a model change, or just activation of the add-ons?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on August 12, 2013, 02:44:51 pm
i dont know because i dont have a DSA - im working from a memory dump - no guarantees, it might blow up or whatever ;-)
no risc no fun.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on August 12, 2013, 02:50:39 pm
i dont know because i dont have a DSA - im working from a memory dump - no guarantees, it might blow up or whatever ;-)
no risk no fun.

somebody took the risk - and has now fun ;-) thanks to the tester !
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: flolic on August 12, 2013, 02:57:53 pm
 :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: H.O on August 12, 2013, 02:59:51 pm
Wow, you guys are great. I don't have a SA and I don't really have a need for one but never the less, I'm impressed! Is anyone looking further into the possibillity of unlocking the BW on the DS4000 series?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JimmyMz on August 12, 2013, 03:00:33 pm
somebody took the risk - and has now fun ;-) thanks to the tester !
WOW  :clap:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on August 12, 2013, 03:26:31 pm
Cybernet: I sent you a PM with my serial number
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on August 12, 2013, 03:47:45 pm
Son of a bitch! IT WORKS!!!! I have 10Hz RBW now. I haven't tested the others yet

Release your work cybernet... you are the man!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dr.diesel on August 12, 2013, 03:51:21 pm
Release your work cybernet... you are the man!

Agreed,

815 powered up and waiting!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Marc M. on August 12, 2013, 03:54:50 pm
Cybernet is the MAN :-+ :-+ :-+
(http://i70.photobucket.com/albums/i89/RatGuru/TESTB_zps6c24658a.png) (http://s70.photobucket.com/user/RatGuru/media/TESTB_zps6c24658a.png.html)

10 Hz RBW!!!  8) 8)   (10 Mhz Sine output from DG4162 @ 400 mVpp)

(http://i70.photobucket.com/albums/i89/RatGuru/VSWR_zpscecc9460.png) (http://s70.photobucket.com/user/RatGuru/media/VSWR_zpscecc9460.png.html)

VSWR Enabled!!!

(http://i70.photobucket.com/albums/i89/RatGuru/AMK_zps3091791c.png) (http://s70.photobucket.com/user/RatGuru/media/AMK_zps3091791c.png.html)

AMK Enabled !!!!

(http://i70.photobucket.com/albums/i89/RatGuru/LIC_zps90ccf1ad.png) (http://s70.photobucket.com/user/RatGuru/media/LIC_zps90ccf1ad.png.html)

It's Official!!!!

And it sticks after power cycling.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on August 12, 2013, 03:59:22 pm
enjoy

http://pastebin.com/ghYHnCfT (http://pastebin.com/ghYHnCfT)

would not have happend without jtag firmware dump from DL5TOR, ecc help from some guy and testing by marc - thanks guys.


PS: the windows tool makers, might want to integrate that into their tool - only the length of the serial & private key differ, rest is the same ! (RILOL !)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JimmyMz on August 12, 2013, 04:12:46 pm
http://pastebin.com/ghYHnCfT (http://pastebin.com/ghYHnCfT)
It would not have happened without:
The jtag firmware dump from DL5TOR
ecc help from some guy
Coding by Cybernet
Testing by Marc M.
I find it very selfless to release all your work for everyone to freely use. Good on all of you  :clap: :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on August 12, 2013, 04:34:46 pm
Now let's just see how long before Rigol is forced to release the 10Hz add-on for sale, haha
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Marc M. on August 12, 2013, 04:40:43 pm
Now let's just see how long before Rigol is forced to release the 10Hz add-on for sale, haha
Since this option isn't available outside of China, I'm also wondering what their reaction is going to be.  They certainly won't be very happy about this  :-DD.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tom66 on August 12, 2013, 05:43:21 pm
Is the method similar for DS2000? Has that been broken already?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dr.diesel on August 12, 2013, 06:09:15 pm
WooHoo!

Note, for whatever reason compiling this on my Fedora 19 box truncates one character on all 3 variables, not sure why.  Anyhow, Mint 15 worked great.

Thanks again to all involved.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jamesb on August 12, 2013, 06:14:56 pm
Since this option isn't available outside of China, I'm also wondering what their reaction is going to be.  They certainly won't be very happy about this  :-DD.

Serves them right quite frankly :)

I wonder what impact the recent success in hacking the protection schema will have on hardware manufacturers deliberately crippling their products for residual sales. Will they strive to further harden their licensing schemes? Or will they abandon the "pay-for-addons" model realizing that the license scheme will be hacked at some point.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on August 12, 2013, 06:18:34 pm
Quote
I  wonder what impact the recent success in hacking the protection schema will have on hardware manufacturers deliberately crippling their products for residual sales. Will they strive to further harden their licensing schemes? Or will they abandon the "pay-for-addons" model realizing that the license scheme will be hacked at some point.

To be fair, most of the people (I imagine) who would have purchased any of these add-ons, still will even though there is an illegal crack available. I think this thread is mostly for us hobbyists who stick to the free-or-nothing model
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dr.diesel on August 12, 2013, 06:21:43 pm
To be fair, most of the people (I imagine) who would have purchased any of these add-ons, still will even though there is an illegal crack available. I think this thread is mostly for us hobbyists who stick to the free-or-nothing model

Agreed, the number of people that find this thread, manage to get it compiled and working are not even a blip on the screen for Rigol.  In-fact, for me, it's a reason to keep buying Rigol equipment, which I'll do unless they get real cranky and mess up our fun.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jasonbrent on August 12, 2013, 06:24:39 pm
To be fair, most of the people (I imagine) who would have purchased any of these add-ons, still will even though there is an illegal crack available. I think this thread is mostly for us hobbyists who stick to the free-or-nothing model

Agreed, the number of people that find this thread, manage to get it compiled and working are not even a blip on the screen for Rigol.  In-fact, for me, it's a reason to keep buying Rigol equipment, which I'll do unless they get real cranky and mess up our fun.

^^ This. I would have just kept "saving" and ordered an Agilent or something if the DS2072 wasn't hackable. :-)

-jbl
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on August 12, 2013, 06:33:30 pm
cybernet:
Congratulations for the new discovery. I only have one question, I hope you can give me a hint:
You have any idea of where is keep the S/N on the DS2000 and, if there is any way to change it?

If you prefer send me a PM, thank you very much.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: chick0n on August 12, 2013, 06:50:45 pm
Soooooo....is the DSA815 Tracking-Gen a Hardware Option, or just a Software Option?  >:D

According to this Teardown:

http://www.eevblog.com/2012/11/28/eevblog-391-rigol-dsa815-spectrum-analyser-teardown/ (http://www.eevblog.com/2012/11/28/eevblog-391-rigol-dsa815-spectrum-analyser-teardown/)

It's all on the same PCB.

Maybe just the N-Connector is missing?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jamesb on August 12, 2013, 07:47:36 pm
To be fair, most of the people (I imagine) who would have purchased any of these add-ons, still will even though there is an illegal crack available. I think this thread is mostly for us hobbyists who stick to the free-or-nothing model
Agreed, the number of people that find this thread, manage to get it compiled and working are not even a blip on the screen for Rigol.  In-fact, for me, it's a reason to keep buying Rigol equipment, which I'll do unless they get real cranky and mess up our fun.

Both excellent points. I do hope that Rigol decides not to scorn the hobbyist / hacker scene - rather I'd hope they would embrace the cult following that they could generate.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tlu on August 12, 2013, 08:00:41 pm
enjoy

http://pastebin.com/ghYHnCfT (http://pastebin.com/ghYHnCfT)

would not have happend without jtag firmware dump from DL5TOR, ecc help from some guy and testing by marc - thanks guys.


PS: the windows tool makers, might want to integrate that into their tool - only the length of the serial & private key differ, rest is the same ! (RILOL !)

Great job cybernet. I was just a matter of time in this case as well.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: videobruce on August 12, 2013, 08:45:52 pm
Ok, other than C&P it somewhere, where and what file name & extension?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: chris petersen on August 12, 2013, 09:01:42 pm
Hi guys, has any of you any compiled version of the Keymaker running the thing under Windows, or how can I get the Keygen, unfortunately, am not a great programmer. Would be very nice if someone could post something here
Chris
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jsykes on August 12, 2013, 09:59:59 pm
Son of a bitch! IT WORKS!!!! I have 10Hz RBW now. I haven't tested the others yet

Release your work cybernet... you are the man!

@olsenn
Is your tracking generator still fully functional?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on August 12, 2013, 10:15:36 pm
Quote
@olsenn
Is your tracking generator still fully functional?

Tracking generator still works! All options are now activated :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: videobruce on August 12, 2013, 10:22:37 pm
What exactly are you suppose to do with the script in that link??  :-//
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dr.diesel on August 12, 2013, 10:24:21 pm
What exactly are you suppose to do with the script in that link??  :-//

Compile and run it!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on August 12, 2013, 10:26:30 pm
What exactly are you suppose to do with the script in that link??  :-//

print it, hold printout in front of DSA (letters facing to DSA), then power cycle it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: videobruce on August 12, 2013, 10:29:39 pm
I'll wait for a intelligent answer. Don't you have some texting to do?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jamesb on August 12, 2013, 10:31:14 pm
I'll wait for a intelligent answer. Don't you have some texting to do?

.... wow ... you do know who you are talking to, right? That would be the guy behind this work you .. f'n tool ...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dr.diesel on August 12, 2013, 10:31:29 pm
I'll wait for a intelligent answer. Don't you have some texting to do?

Not nice to irritate the guy that developed the hack..
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: warp_foo on August 12, 2013, 10:32:53 pm
Reply #572 has (one of the) Linux versions of the keygen, reply #574 has the Windows version. I think it's page 39ish with default forum settings.

Outstanding! Thank you...

m

ETA: 2072 ordered. 9/24 delivery date, oh well.  :'(
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: videobruce on August 12, 2013, 10:35:52 pm
Doesn't matter who he is. His response surely didn't match his work. You expect everyone to know exactly what to do with that script?

If you didn't want to provide a decent non smart ass answer, then why did you bother in the first place?

Moderator: No need for this sort of response. Keep it civil please.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on August 12, 2013, 10:39:43 pm
not irritated, but amused ;-)

if the printout method is nothing for you maybe u should RTFM or wait for someone to come along to make little GUI for you - which u would have known if u had read the last 3 pages ...  :-DD
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tom66 on August 12, 2013, 10:43:49 pm
Excellent work and seriously tempting me to buy a DSA815 (and DS2000 if that gets hacked...)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jamesb on August 12, 2013, 10:48:37 pm
I just tried the code and managed to generate some "test keys" for "educational purposes"  :-DD ... they don't seem to work however ..

I've verified the unit serial number using SCIP (*IDN?) and passed it to the rikey_dsa as such:

Quote
./rikey_dsa DSA8A151###### AAAF

Should I try entering the private key manually? (ie. is 80444DFECE903E valid?)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rufus on August 12, 2013, 10:54:25 pm
Doesn't matter who he is. His response surely didn't match his work. You expect everyone to know exactly what to do with that script?

It isn't a script it is a complete C program with more than adequate information on how to compile it.

The 59 pages of this thread might give you an idea of how much work people put into producing it.

So no I'm sure he doesn't expect everyone to know exactly what to do with it but expecting people to put some effort into trying to find out before they ask questions is reasonable. He (and others) made 'your' job 100,000 times easier than it was 59 pages ago.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tom66 on August 12, 2013, 10:57:51 pm
It was mentioned a while back that this was an "illegal" key, perhaps in the same way as unlocking extra software options, as these are not hardware limits like with the DS1052E/1102E? Also, if the unit has to be returned for service, is there a way of erasing the bogus keys?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jsykes on August 12, 2013, 11:05:25 pm
I'll wait for a intelligent answer. Don't you have some texting to do?

I've been following the work of these amazing programmers for quite some time and have deepest respect for their talents. I specialize in Hardware and RF and am an old guy who's programming talents ended with the demise of DOS so I'm hoping the comment above doesn't discourage someone from developing a Windows GUI. I really need that 10Hz RBW and for me, a GUI to do it. I'm sure there are other old hams out there in the same boat they may be ashmed to admit that.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: grego on August 12, 2013, 11:08:37 pm
Doesn't matter who he is. His response surely didn't match his work. You expect everyone to know exactly what to do with that script?

If you didn't want to provide a decent non smart ass answer, then why did you bother in the first place?

Seriously, you expect to get this stuff spoon fed to you?  Take a little time, read through and figure it out.  If you have a specific question about implementation someone will be happy to help I'm sure.  Not a "what do I do with this" that has been answered a dozen times in the preceding pages.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on August 12, 2013, 11:11:25 pm
bfin ida cpu module
be warned however, it has bugs - if aX registers are in use (math heavy stuff) you can not trust the ida output, take it from objdump or gdb bfin if so.
the bfin stuff is kraters work, not mine. those modules where compiled on a x86 32 bit, for ida 6.2 - might not work with other ida versions.

im currently working on enhancing the bfin flirt tools from krater or probably rewrite them because somehow they dont seem to work right.
then it should be possible to get better matchrate for VDSP libraries to the firmwares - which will ease reversing them.

Hi all!

I opened this "DS2000Update.gel" with ida 6.1 and saved as ida databases (*. id?).  I wonder if all was fine because I used the 6.1 Ver. instead of 6.2. Is there any way to know if everything was okay?
What other interesting things can be found by that?  For example, some hidden menu...

Thanks  ;)



Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jamesb on August 12, 2013, 11:57:14 pm
Should I try entering the private key manually? (ie. is 80444DFECE903E valid?)

I just power-cycled the DSA815 and tried again and everything worked just fine - there was a brief delay after each key entry but the options are now listed as "official".
Now I'll uninstall the keys since the tested software appears to have worked ...  >:D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jamesb on August 12, 2013, 11:58:25 pm
Excellent work and seriously tempting me to buy a DSA815 (and DS2000 if that gets hacked...)

... you are kidding, right?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on August 13, 2013, 12:12:45 am
Quote
Now I'll uninstall the keys since the tested software appears to have worked ... 

Right....... I'm sure you will...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on August 13, 2013, 01:37:43 am
Doesn't matter who he is. His response surely didn't match his work. You expect everyone to know exactly what to do with that script?
If you don't know what to do with that "script", where the instructions are in the file itself, well, maybe you can ask your attitude.


so I'm hoping the comment above doesn't discourage someone from developing a Windows GUI.
lol who takes such a thing serious, I'm sure nobody cares
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ve7xen on August 13, 2013, 04:29:25 am
Wow I go offline for a weekend and more awesomeness!

Don't have the DSA but binaries up at http://gotroot.ca/rigol (http://gotroot.ca/rigol) as usual :).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tlu on August 13, 2013, 04:47:58 am
Nice work with the 10Hz RBW  :-+. Does anyone know if the 3Ghz BW is also software specific? That would be a nice option to go along with the 10Hz RBW.  ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DL5TOR on August 13, 2013, 09:32:09 am
question tool all:

is ther any one with a dsa815 (NON-TG) willing to do a open it out there??

we Need some Fotos of the PCB to see if it is only the N-connector that is missing or what elce is missing.

thanks to all

DL5TOR
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tom66 on August 13, 2013, 10:13:07 am
Excellent work and seriously tempting me to buy a DSA815 (and DS2000 if that gets hacked...)

... you are kidding, right?

Yes. Ha ha. You got me.

 :-//
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mr Simpleton on August 13, 2013, 10:18:32 am
Does the 815 non-TG have the TG N-connector in place?? Oddly the only picture I've seen has been with 2 N-connectors at the front. If so it certainly looks promising for a "software-upgrade".

For those who has dismembered the 815... how about measure the IF filter size, this way we could estimate the IF frequency, and thus see if the 815 is hardware designed for a higher than 1,5 GHz stop frequency. Or even better try to measure the cut-off frequency of the first low-pass filter. But this may be a though job.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tom66 on August 13, 2013, 10:21:06 am
I think the tracking generator is a substantial cost on the unit (if you look at the teardown.) I doubt they are including that with every unit. 3GHz vs. 1.5GHz may also require some changes to the PCB filters?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Uup on August 13, 2013, 11:10:51 am
Excellent work and seriously tempting me to buy a DSA815 (and DS2000 if that gets hacked...)

... you are kidding, right?

Yes. Ha ha. You got me.

 :-//

Looks like you are serious...

Did you read any of the earlier pages in this thread?

Oh wait, of course you didn't! Otherwise you would realise that what you are asking has already been done.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tom66 on August 13, 2013, 11:34:23 am
I didn't read through the thread, not all 60 pages. I didn't realise it had already been hacked. If so, great! Now I have double the reason to get the DS2000.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on August 13, 2013, 11:53:15 am
For the DS2000 I recall it was possible to change a DS2072 into thinking it is a DS2022 to get greater bandwidth. I wonder what happens if that same procedure is done to change the DSA815 into thinking it is a DSA830?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tom66 on August 13, 2013, 11:58:00 am
Is there a dedicated thread on DS2000 hacking, or is it all in this thread?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DL5TOR on August 13, 2013, 12:17:49 pm
Is there a dedicated thread on DS2000 hacking, or is it all in this thread?

it's all in one
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jamesb on August 13, 2013, 12:25:52 pm
Is there a dedicated thread on DS2000 hacking, or is it all in this thread?

You are looking at it.

To be honest, I like the fact that the procedure is a bit convoluted and requires some background research - it should help keep the effort / success a bit more low-key and reward those who are more dedicated than the average script-kiddie type.

Someone is bound to write up a full "how-to" on a blog site somewhere - hell, I was considering an in-depth tutorial until I considered the ramifications.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tom66 on August 13, 2013, 12:32:30 pm
Great. There are already how-tos on the net. And a Windows EXE for the DS2000. I can quite easily compile a linux gcc, if I can find the libraries. First, I need to sell my DS1102E (not hacked, all original) if the DS2072 is to be my next purchase. I am really missing the intensity grading that I get on the uni lab scopes (Agilent DSO4000 IIRC)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: fqahmad66 on August 13, 2013, 12:44:01 pm
Hi,

It seems that there are lots of parts for the TG option input. See attached images of back side of board. The DC block cap at RF input may also limit the analyser range to around 2G.

Regards
F
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jamesb on August 13, 2013, 12:57:51 pm
Wow ... some really scary / poorly done reflow on that board. Good thing it works .. but .. wow ...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PegasusDD on August 13, 2013, 04:20:24 pm
Does the 815 non-TG have the TG N-connector in place?? Oddly the only picture I've seen has been with 2 N-connectors at the front. If so it certainly looks promising for a "software-upgrade".

On the following page is a picture of a DSA815 without TG and with only one N-connector:
http://www.batronix.com/versand/spektrumanalysator/Rigol-DSA815.html (http://www.batronix.com/versand/spektrumanalysator/Rigol-DSA815.html)

and here another one:
http://www.goepe.com/apollo/prodetail-szzydz2-3371161.html (http://www.goepe.com/apollo/prodetail-szzydz2-3371161.html)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dougg on August 13, 2013, 04:36:56 pm
For those trying to build miracl.a on a 64 bit Linux platform (Ubuntu 13.04 in my case), the instructions at the top of rikey_dsa.c (and rikey_true.c) need to be tweaked a bit. I used 'bash linux64' to build miracl.a then '-m64' rather than '-m32' on the link line.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jamesb on August 13, 2013, 06:05:11 pm
For those trying to build miracl.a on a 64 bit Linux platform (Ubuntu 13.04 in my case), the instructions at the top of rikey_dsa.c (and rikey_true.c) need to be tweaked a bit. I used 'bash linux64' to build miracl.a then '-m64' rather than '-m32' on the link line.

Nice catch for the 64bit crowd!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mr Simpleton on August 13, 2013, 07:38:40 pm
Maybe not the correct thread to ask... but looking at the phase noise data on the DSA815 it is not that spectacular at close in, is the 10 Hz RBW really that useful? It seems several forum members mentions that the 10 Hz filter does make a difference when trying to resolve signals. I would love to se a plot showing the improvement. Any taker??  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on August 13, 2013, 07:51:49 pm
i'd recommend -m32 even on a 64bit system - i had several inconsistent builds on 64 bit boxes, maybe invalid type casts on my end or miracl issues. 32bit fallback solved it every time.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on August 13, 2013, 08:15:31 pm
pm me the output (+serial), i can verify it the other way around - so far all error reports where due to typos  :P
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rory on August 13, 2013, 08:40:51 pm
Thanks Cybernet and dr.diesel, I'm up and running on all.

The license info still shows the trial options by their keys and their "left time". I assume the trials will disappear once they expire?

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Wall-E on August 13, 2013, 10:34:35 pm
Re.  'Rory'   « Reply #933 on: Today at 06:40:51 AM »
      Thanks Cybernet and dr.diesel, I'm up and running on all.
      The license info still shows the trial options by their keys and their "left time". I assume the trials will disappear once they expire?
_____________________________________________________________

No, it won't go away, and it is too bad because it says that the options were hacked in. This may be a dead give away when a future firmware version is installed. We should look for a way to clean them out, and of course leave the new option license info in place.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on August 13, 2013, 11:28:52 pm
Quote
Still cannot get :SYST:OPT:INST to work correctly from SCPI command line.

The proper VISA command is, ":SYSTem:LKEY <license key>" without hyphens in the license
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on August 13, 2013, 11:46:40 pm
Quote
Maybe not the correct thread to ask... but looking at the phase noise data on the DSA815 it is not that spectacular at close in, is the 10 Hz RBW really that useful? It seems several forum members mentions that the 10 Hz filter does make a difference when trying to resolve signals. I would love to se a plot showing the improvement. Any taker??

Here is a screenshot showing a typical noise floor for the DSA815 with 10Hz RBW @ a span of 100Hz, with the per-amplifier enabled. Notice that even at a span of 100Hz, the sweep time is 1 second for this RBW.

Also, to illustrate where having such a low RBW can be useful, I have included two captures of an FM modulated signal with sidebands at 30Hz from the carrier frequency. With the 10Hz RBW you can clearly see the two sidebands; however, in the 100Hz RBW shot, only a single dirac can be seen.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rory on August 14, 2013, 03:32:36 am
Quote
Still cannot get :SYST:OPT:INST to work correctly from SCPI command line.

The proper VISA command is, ":SYSTem:LKEY <license key>" without hyphens in the license

That was exactly what I used, did not work for me. Did anyone else have success with this on the DSA815-TG?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Marc M. on August 14, 2013, 06:39:09 am
Quote
Still cannot get :SYST:OPT:INST to work correctly from SCPI command line.

The proper VISA command is, ":SYSTem:LKEY <license key>" without hyphens in the license

That was exactly what I used, did not work for me. Did anyone else have success with this on the DSA815-TG?

I haven't had any luck either.  The key entry dialog box pops up, but no text gets entered.  When I look under SYSTEM/INFORMATION/SYSTEM MSG I get:
"331     Invalid Option Serial Number."
 
Edit:  I found the list of error messages in the back of the manual.  For 331 it states: "The length of option serial number must be less than 20 characters."  The generated keys are 28 characters in length so you can't set it VIA SCPI without triggering this error message.  :-// 
/Edit

I thought that may indicate you need to provide the option number for the key you are entering.  I tried various formats/positions of option numbers and keys with no luck.  I'm not sure if the fact I already have the options enabled is causing issues.  I then tried to uninstall the options but haven't been able to find anything that works for that either.  Has anyone had any success in uninstalling the 815 options?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mr Simpleton on August 14, 2013, 08:53:14 am
Here is a screenshot showing a typical noise floor for the DSA815 with 10Hz RBW @ a span of 100Hz, with the per-amplifier enabled. Notice that even at a span of 100Hz, the sweep time is 1 second for this RBW.

Also, to illustrate where having such a low RBW can be useful, I have included two captures of an FM modulated signal with sidebands at 30Hz from the carrier frequency. With the 10Hz RBW you can clearly see the two sidebands; however, in the 100Hz RBW shot, only a single dirac can be seen.

Thanks for taking the time and to a measurement! Can clearly see the 10 Hz RBW can be useful when looking for 50/60 Hz sidebands!  :clap:

The DSA815 looks more and more like a useful addition to my workbench...  8)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on August 14, 2013, 12:28:36 pm
Is there a Windows Keygen available for the DSA815 Options?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dr.diesel on August 14, 2013, 12:30:06 pm
Is there a Windows Keygen available for the DSA815 Options?

Nope, not yet.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tom66 on August 14, 2013, 12:35:24 pm
Would there be any complaint if I compiled the gcc version of the DSA815 keygen and posted a PHP interface on the 'net? Too easy for "noobs"? 

Was being seriously tempted by DS1000Z vs DS2000 (4channel 100MHz looks very nice) but from what I've read, they aren't yet hackable (no key?), though it does appear to use the same firmware so only a matter of time. If I bought one, I may be tempted to try sniffing the private key, but I only have a basic logic analyser from Seeed, nothing fancy like a Saleae.  Do I need to dump firmware to find the private key?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on August 14, 2013, 01:20:00 pm
Quote
If I bought one, I may be tempted to try sniffing the private key, but I only have a basic logic analyser from Seeed, nothing fancy like a Saleae.  Do I need to dump firmware to find the private key?

A logic analyzer won't help you here; you need to dump the firmware of the Blackfin MCU and extract the keys which are left in plain-text. The private key I believe needs to be brute forced / calculated with a tool on the web. Ask the user, "cybernet" for details; he is the one who knows what to do :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tom66 on August 14, 2013, 01:23:01 pm
One question, from what (little) I know of public-private encryption, why do they make the private key available on the widget which is given to the customer? Or am I missing something? Surely you'd put the public key in the widget, which can only decrypt the option key. The private key, used to generate the option key, can be kept secret in Rigol's head office and used only to generate new option keys. Is it not a little back-asswards?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on August 14, 2013, 01:49:35 pm
One question, from what (little) I know of public-private encryption, why do they make the private key available on the widget which is given to the customer? Or am I missing something? Surely you'd put the public key in the widget, which can only decrypt the option key. The private key, used to generate the option key, can be kept secret in Rigol's head office and used only to generate new option keys. Is it not a little back-asswards?

As far as I followed the discussion the private key is not available in the firmware, the public key is. The way they implemented the encryption makes it relative easy to calculate the private key.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tom66 on August 14, 2013, 01:54:23 pm
Ah OK. So if I were to dump the firmware, and I knew where to look, I could find a public key?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jamesb on August 14, 2013, 02:02:48 pm
Yes, and then knowing the encryption schema and any weaknesses, you can compute the private key knowing the public key and a cypher protected datagram.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tom66 on August 14, 2013, 02:07:08 pm
So... This sounds like a challenge.  :)

Do we need to dump the firmware from the Blackfin, or will Rigol's own "download update" USB files do? They include the FPGA bitstream, main firmware, etc... but I do not know if the crypto is kept on a hidden partition (or similar) on the flash, or perhaps even in on-chip ROM.

Surely one way of doing this would be to replace the public key with one of our own? Thus circumventing the need to break any private key. Are the public keys signed by Rigol?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DL5TOR on August 14, 2013, 04:00:22 pm
So... This sounds like a challenge.  :)

Do we need to dump the firmware from the Blackfin, or will Rigol's own "download update" USB files do? They include the FPGA bitstream, main firmware, etc... but I do not know if the crypto is kept on a hidden partition (or similar) on the flash, or perhaps even in on-chip ROM.

Surely one way of doing this would be to replace the public key with one of our own? Thus circumventing the need to break any private key. Are the public keys signed by Rigol?

if you do a bfin dump then the poblic keys are in there in plain text. all you Need is a jtag cable (20$+) that is compatible with urjtag

sometimes it is also in the updatefile.
- if the file is a *.gel file the  there is a Chance that it is in there.
- if it is a *.sys file then it will not be in there.

Edit:

The keys are in the sdram part of the Firmware (that is how it is in the ds2k and the dsa815)

i hope to help

73 de DL5TOR
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rory on August 14, 2013, 04:21:16 pm
Re.  'Rory'   « Reply #933 on: Today at 06:40:51 AM »
      Thanks Cybernet and dr.diesel, I'm up and running on all.
      The license info still shows the trial options by their keys and their "left time". I assume the trials will disappear once they expire?
_____________________________________________________________

No, it won't go away, and it is too bad because it says that the options were hacked in. This may be a dead give away when a future firmware version is installed. We should look for a way to clean them out, and of course leave the new option license info in place.

The trial key for the VSWR option stayed in after I entered the offical (sic) key I got from RIGOL.  So it's not specific to the hacked keys.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on August 14, 2013, 05:43:07 pm
Was being seriously tempted by DS1000Z

Does anyone have a DS1000Z firmware file yet?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on August 14, 2013, 05:48:49 pm
talking of firmware i would love to get a 2nd DSA firmware (.sys file) if somebody has 2 versions, and is willing to share let me know.
an ida loader for it would help for future updates they might do .
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tom66 on August 14, 2013, 06:04:50 pm
Since the DS1000Z has i.MX processor from Freescale, can the firmware be dumped in the same was as the Blackfin?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on August 14, 2013, 06:07:58 pm
Since the DS1000Z has i.MX processor from Freescale, can the firmware be dumped in the same was as the Blackfin?

yes, but freescale stuff can usually be locked down quite a bit (ECU, Automotive stuff) so somebody would need to try it to be sure.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tom66 on August 14, 2013, 06:13:32 pm
Hmm. May have to see if DS1000Z firmware turns up then e.g. firmware update.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Maalobs on August 14, 2013, 08:12:33 pm
Cybernet, can you describe what hardware- and software-tools you used for finding and dumping the firmware from the DS2072?
I gather that an Amontec JTAGkey-Tiny was involved, but what software did you use to analyse the internals of the scope and dump the firmwares?
Did you use any other resources for that part of the operation?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on August 14, 2013, 08:19:18 pm
Cybernet, can you describe what hardware- and software-tools you used for finding and dumping the firmware from the DS2072?
I gather that an Amontec JTAGkey-Tiny was involved, but what software did you use to analyse the internals of the scope and dump the firmwares?
Did you use any other resources for that part of the operation?

all in the thread ... either the custom rigol .GEL file loader + ida pro (would have worked, but cumbersome to start with) - and jtag + uclinux gdb bridge, memory dumps imported into ida pro - and lots of brain.
jtag has the benefit that you can observe the device ... bp's/wp's,data inspection - the dsa stuff was a quick win, because it was clear after looking at dl5's dump for 10mins that they are using exactly the same setup (however code style s different, they used another compiler or other flags) - finding the parameters or better say verifying them took another 5mins ;-)
thats why im working on flirt signatures for ida, will allow any other bf based rigol device to be investigated much more easily. cracking the bootloader would also be nice - i'd still love to see whats in their flash based filesystem (probably the way to go for the DG4XXX's)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rory on August 14, 2013, 08:34:34 pm
Now if we could figure out how to change the text color on the DS2000 FFT display so you can read it when the noise is behind it...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cosmos on August 14, 2013, 09:13:06 pm
What of the higher BW settings of the DS4000? ideas for a way forward?

First tries (in this tread somewhere) with bits next to decoding options seemed not to work.
From the teardown it seems it uses an ASICs in the frontend, would be strange if it is not ready for the full BW.
Is it the same amplifier (as in DS2000) with selectable BW following the ASIC? That amplifier had settings to go to about 1GHz so it could fit.
One post (not in this tread) claimed to have seen 500MHz pulse response with a DS4000 that got confused about its internal state.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: synapsis on August 14, 2013, 09:44:27 pm
enjoy

http://pastebin.com/ghYHnCfT (http://pastebin.com/ghYHnCfT)

would not have happend without jtag firmware dump from DL5TOR, ecc help from some guy and testing by marc - thanks guys.


PS: the windows tool makers, might want to integrate that into their tool - only the length of the serial & private key differ, rest is the same ! (RILOL !)

The ecssign functions generated different keys between the DS2000 code and your DSA800 release. So there's something else different somewhere. ;)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: synapsis on August 14, 2013, 09:54:16 pm
I was in another city trying to find a job (no luck) and my PMs blow up about cybernet's latest offering.

I don't have a DSA815, so the only way I could test this code is to compare the output to cybernet's Linux code using Dave's demo unit serial number from his video. So, this code is considered beta.

Edit: Oh yeah, this is the Windows version of the keygen with DS2000 and DSA800 generators.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on August 14, 2013, 10:28:35 pm
I was in another city trying to find a job (no luck) and my PMs blow up about cybernet's latest offering.

I don't have a DSA815, so the only way I could test this code is to compare the output to cybernet's Linux code using Dave's demo unit serial number from his video. So, this code is considered beta.

Edit: Oh yeah, this is the Windows version of the keygen with DS2000 and DSA800 generators.


sorry dude didnt mean to blow up your pm's ;-) - verification is rather easy, if u have a copy of riglol (verification part not keygen) and just update the "point2" (which is the public key) to the DSA and a minor update to the serial length check:

Code: [Select]
if (strlen(serial) < 0xd) { fprintf(stderr, "serial has invalid length !\n"); exit(-1); }
you can then verify them as easily as the DS keys.

to the script kiddies: those are not the private keys ...
Code: [Select]
#ifdef RIGOL_KEYS
unsigned char prime1[]="AEBF94CEE3E707";
unsigned char prime2[]="AEBF94D5C6AA71";
unsigned char curve_a[]="2982";
unsigned char curve_b[]="3408";
unsigned char point1[]="7A3E808599A525";
unsigned char point2[]="8445B2BE29E5C7";
#endif
#ifdef RIGOL_DSA_KEYS
unsigned char prime1[]="AEBF94CEE3E707";
unsigned char prime2[]="AEBF94D5C6AA71";
unsigned char curve_a[]="2982";
unsigned char curve_b[]="3408";
unsigned char point1[]="7A3E808599A525";
unsigned char point2[]="691213692D18FA";
#endif

otherwise maybe somebody shares a real code with you DL5TOR has one, but im not doing it without his permission.

IMHO if u just swap in the new private key, and allow the serial to be >= 0xe it should work just fine for the DSA as well.
detection which key to use could be done via the serial format ...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: synapsis on August 14, 2013, 10:32:16 pm
I ended up just replacing the ecssign function with yours. I only had to cast a couple unsigned chars and change a parameter name.  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on August 14, 2013, 10:33:38 pm
I ended up just replacing the ecssign function with yours. I only had to cast a couple unsigned chars and change a parameter name.  :-+

good stuff  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jsykes on August 14, 2013, 10:44:55 pm
I was in another city trying to find a job (no luck) and my PMs blow up about cybernet's latest offering.

I don't have a DSA815, so the only way I could test this code is to compare the output to cybernet's Linux code using Dave's demo unit serial number from his video. So, this code is considered beta.

Edit: Oh yeah, this is the Windows version of the keygen with DS2000 and DSA800 generators.


synapsis
YOU THE MAN!
 
The other day,  jamesb was kind enough to generate keys for me using cybernet's code with his Linux box. I asked him to generate more that one set but he said with the 815 keygen, the other sets generated were exactly the same. For comparison, I used your windows software to generate the keys for my serial number and they all match the keys generated by cybernet's code running on the Linux box. Your Windows software is verified good on the first try. GREAT JOB to you, cybernet, DL5TOR, and all that made this happen.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rufus on August 15, 2013, 07:13:36 am
talking of firmware i would love to get a 2nd DSA firmware (.sys file) if somebody has 2 versions, and is willing to share let me know.

I have 1.05 and 1.07.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: fqahmad66 on August 15, 2013, 09:37:35 am
I was in another city trying to find a job (no luck) and my PMs blow up about cybernet's latest offering.

I don't have a DSA815, so the only way I could test this code is to compare the output to cybernet's Linux code using Dave's demo unit serial number from his video. So, this code is considered beta.

Edit: Oh yeah, this is the Windows version of the keygen with DS2000 and DSA800 generators.


synapsis
YOU THE MAN!
 
The other day,  jamesb was kind enough to generate keys for me using cybernet's code with his Linux box. I asked him to generate more that one set but he said with the 815 keygen, the other sets generated were exactly the same. For comparison, I used your windows software to generate the keys for my serial number and they all match the keys generated by cybernet's code running on the Linux box. Your Windows software is verified good on the first try. GREAT JOB to you, cybernet, DL5TOR, and all that made this happen.


Hi jsykes,

Did you also send the bf dump or just the s.no and licence info? I do not want to open the analyser.


Regards
F
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: fqahmad66 on August 15, 2013, 11:20:59 am
Is it just a myth or real that after three wrong attempts of License Keys entry..the unit is locked and must be sent to China to unlock..
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dr.diesel on August 15, 2013, 11:22:58 am
Is it just a myth or real that after three wrong attempts of License Keys entry..the unit is locked and must be sent to China to unlock..

Myth, at least on the DSA.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: fqahmad66 on August 15, 2013, 11:29:16 am
I have aquestion. My analyser has serial no. starting with DSA8.... but cybernet's keygen wants to put s.no DS2A....

printf("  <sn>       serial number of device (DS2A.........)\n");

Is that OK?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on August 15, 2013, 11:32:07 am
My analyser has serial no. starting with DSA8.... but cybernet's keygen wants to put s.no DS2A....


DS2A is for the DS2000 series of scopes, where the keygen was born.
I think someone just forgot to change that bit.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: fqahmad66 on August 15, 2013, 05:06:19 pm
Re.  'Rory'   « Reply #933 on: Today at 06:40:51 AM »
      Thanks Cybernet and dr.diesel, I'm up and running on all.
      The license info still shows the trial options by their keys and their "left time". I assume the trials will disappear once they expire?
_____________________________________________________________

No, it won't go away, and it is too bad because it says that the options were hacked in. This may be a dead give away when a future firmware version is installed. We should look for a way to clean them out, and of course leave the new option license info in place.

The trial key for the VSWR option stayed in after I entered the offical (sic) key I got from RIGOL.  So it's not specific to the hacked keys.

Hi Rory,

What is official (sic) key? Mine shows as trial.

REgards
F
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on August 15, 2013, 05:08:20 pm
DS2000

Code: [Select]
MODEL_DSModelType_modify_?_sub_1D6BE2                ROM    001D6BE2 0000005E R . . . . . .
MODEL_MakeDSModelType_sub_9850A                      ROM    0009850A 00000042 R . . . . . .
MODEL_MakeDSXString_sub_F204E                        ROM    000F204E 00000056 R . . . . . .
MODEL_Make_sub_F273C                                 ROM    000F273C 000002CC R . . . . . .
MODEL_and_SERIAL_sub_9731C                           ROM    0009731C 0000005A R . . . . . .
MODEL_createModelTypeString_?_sub_F21BC              ROM    000F21BC 00000116 R . . . . . .
MODEL_getDSModelType_sub_F1DE2                       ROM    000F1DE2 00000014 R . . . . . .
MODEL_getStr_sub_18F0F4E                             ROM    018F0F4E 0000000E R . . . . . .
MODEL_getTypeID_sub_18F0EDE                          ROM    018F0EDE 00000014 R . . . . . .
MODEL_getTypeID_sub_18F0F84                          ROM    018F0F84 00000014 R . . . . . .
MODEL_getVendor_sub_18F0F72                          ROM    018F0F72 0000000E R . . . . . .
MODEL_makeDSModelType_sub_A9760                      ROM    000A9760 0000008C R . . . . . .
MODEL_retDS2XXX_sub_F1E4E                            ROM    000F1E4E 00000012 R . . . . . .
MODEL_setDSModelType_sub_F26DE                       ROM    000F26DE 0000005E R . . . . . .
MODEL_set_DSModel_Type_sub_F1E84                     ROM    000F1E84 00000018 R . . . . . .
MODEL_sub_19D5CDE                                    ROM    019D5CDE 0000005E R . . . . . .

Some of these functions are not accessible. Hidden menu? Any ideas?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on August 15, 2013, 06:12:04 pm
Where do these names come from, I don't see them in the .GEL file?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DL5TOR on August 15, 2013, 06:17:16 pm
DS2000

Code: [Select]
MODEL_DSModelType_modify_?_sub_1D6BE2                ROM    001D6BE2 0000005E R . . . . . .
MODEL_MakeDSModelType_sub_9850A                      ROM    0009850A 00000042 R . . . . . .
MODEL_MakeDSXString_sub_F204E                        ROM    000F204E 00000056 R . . . . . .
MODEL_Make_sub_F273C                                 ROM    000F273C 000002CC R . . . . . .
MODEL_and_SERIAL_sub_9731C                           ROM    0009731C 0000005A R . . . . . .
MODEL_createModelTypeString_?_sub_F21BC              ROM    000F21BC 00000116 R . . . . . .
MODEL_getDSModelType_sub_F1DE2                       ROM    000F1DE2 00000014 R . . . . . .
MODEL_getStr_sub_18F0F4E                             ROM    018F0F4E 0000000E R . . . . . .
MODEL_getTypeID_sub_18F0EDE                          ROM    018F0EDE 00000014 R . . . . . .
MODEL_getTypeID_sub_18F0F84                          ROM    018F0F84 00000014 R . . . . . .
MODEL_getVendor_sub_18F0F72                          ROM    018F0F72 0000000E R . . . . . .
MODEL_makeDSModelType_sub_A9760                      ROM    000A9760 0000008C R . . . . . .
MODEL_retDS2XXX_sub_F1E4E                            ROM    000F1E4E 00000012 R . . . . . .
MODEL_setDSModelType_sub_F26DE                       ROM    000F26DE 0000005E R . . . . . .
MODEL_set_DSModel_Type_sub_F1E84                     ROM    000F1E84 00000018 R . . . . . .
MODEL_sub_19D5CDE                                    ROM    019D5CDE 0000005E R . . . . . .

Some of these functions are not accessible. Hidden menu? Any ideas?

Those are no menus These are Subs in the Firmware the Names are added from cybernet  read that post to 100% thén you will know
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on August 15, 2013, 06:17:39 pm
What is official (sic) key? Mine shows as trial.

I guess he bought the official key, and now he's sic(k) of it  ;)

(The official key shows as "offcial" on the screen, so that is what he tried to type but he made a mistake quoting the mistake...)

The Latin adverb sic ("thus"; in full: sic erat scriptum, "thus was it written") added immediately after a quoted word or phrase (or a longer piece of text), indicates that the quotation has been transcribed exactly as found in the original source, complete with any erroneous spelling or other nonstandard presentation.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on August 15, 2013, 06:20:53 pm
Those are no menus These are Subs in the Firmware the Names are added from cybernet  read that post to 100% thén you will know

Is there an IDA database for grabbing somewhere?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rory on August 15, 2013, 06:21:32 pm
Re.  'Rory'   « Reply #933 on: Today at 06:40:51 AM »
      Thanks Cybernet and dr.diesel, I'm up and running on all.
      The license info still shows the trial options by their keys and their "left time". I assume the trials will disappear once they expire?
_____________________________________________________________

No, it won't go away, and it is too bad because it says that the options were hacked in. This may be a dead give away when a future firmware version is installed. We should look for a way to clean them out, and of course leave the new option license info in place.

The trial key for the VSWR option stayed in after I entered the offical (sic) key I got from RIGOL.  So it's not specific to the hacked keys.

Hi Rory,

What is official (sic) key? Mine shows as trial.

REgards
F

offical (sic) was meant as joke to poke fun at Rigol's chinglish spelling of 'official' in the option info screen. (sic) means "this is how they spelled it, don't blame me for it".

Take a look at these two screen shots. One is before the hacked codes, the other after. Note that Option no. 5, which is the VSWR option, has the real official code from Rigol's website key code generator, generated from my unit's serial number and a code on the key certificate they emailed me when I purchased the optional kit which includes hardware.  Notice also that in both instances, the trial key still shows up with "Left Time".
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rory on August 15, 2013, 06:24:47 pm
What is official (sic) key? Mine shows as trial.

I guess he bought the official key, and now he's sic(k) of it  ;)

(The official key shows as "offcial" on the screen, so that is what he tried to type but he made a mistake quoting the mistake...)

The Latin adverb sic ("thus"; in full: sic erat scriptum, "thus was it written") added immediately after a quoted word or phrase (or a longer piece of text), indicates that the quotation has been transcribed exactly as found in the original source, complete with any erroneous spelling or other nonstandard presentation.

Hahaha you're right. I make a lot of mistakes...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on August 15, 2013, 07:02:22 pm
from the list with temp keys .. the temporary editions are SAAB (tm?), SAAC, SAAD, SAAE, SAAF ... .e.g. S=temp, A=perm

temp keys

80001 - SAAB
80002 - SAAC
80003 - SAAD
80004 - SAAE
80005 - SAAF

perm keys

00001 - AAAB
00002 - AAAC
00003 - AAAD
00004 - AAAE
00005 - AAAF

somebody with lxi could test other "bit positions" - to find other stuff ...

here is the not elegant way to come from option code to hexcode used ...
Code: [Select]
/****************************************************
* DS2000 license options reverse bruteforcer
* (c) CyberNet, 2013.
*****************************************************/

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <ctype.h>

unsigned char codemap_ee00d0[]={ 0x0, 0x0, 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f,
0x0, 0x0, 0x0,  0x0,  0x0,  0x0,  0x0,  0x0,  0x1,  0x2,
0x3, 0x4, 0x5,  0x6,  0x7,  0x0,  0x8,  0x9,  0xa,  0xb,
0xc, 0x0, 0xd,  0xe,  0xf,  0x10, 0x11, 0x12, 0x13, 0x14,
0x15,0x16, 0x17 };

unsigned char codemap_20688e[]={ 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30, 0x30,  /* 0-9 = 0x30 */
                                 0x37, 0x37, 0x37, 0x37, 0x37, 0x37 };       /* A-F = 0x37 */


unsigned char vb[]={'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'J', 'K', 'L', 'M', 'N', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', '2', '3', '4', '5', '6', '7', '8', '9'};


/*
** convert string to uppercase chars
*/
unsigned char *strtoupper(unsigned char *str)
{
    unsigned char *newstr, *p;
    p = newstr = (unsigned char*) strdup((char*)str);
    while((*p++=toupper(*p)));
    return newstr;
}

/*
**
*/
unsigned char code_map_206846(unsigned char i)
{
 if ((i >= 'A') && (i <= 'F')) return(i-0x37);
 if ((i >= '0') && (i <= '9')) return(i-0x30);
 return(0x0);
}

/*
** Encryption Routine 1
*/
unsigned char *lic_code_map(unsigned char *lic_skipped)
{
 unsigned char lv1,lv2;
 unsigned char b1_mapped, b1_shifted, b1_remapped;
 unsigned char b2_mapped, b2_shifted, b2_remapped;
 unsigned char b3_mapped, b3_shifted, b3_remapped;
 unsigned char b4_mapped, b4_shifted, b4_remapped;
 unsigned char b5_shifted, b5_remapped;
 unsigned char *lic_mapbytes;

 lic_mapbytes=calloc(28, 1);
 if (!lic_mapbytes) return(0);

 lv1=lv2=0;
 while(lv1 < strlen((unsigned char*)lic_skipped))
 {
    b1_mapped =  codemap_ee00d0[ *(lic_skipped+lv1) - 0x30 ];
    b1_shifted = (b1_mapped / 2) & 0xf;
    b1_remapped = b1_shifted + codemap_20688e[b1_shifted];
    lic_mapbytes[lv2++]=b1_remapped;
    b1_mapped = b1_mapped & 0x1;

    b2_mapped =  codemap_ee00d0[ *(lic_skipped+lv1+1) - 0x30 ];
    b2_shifted =  ((b1_mapped << 0x3) | (b2_mapped / 4)) & 0xF;
    b2_remapped = b2_shifted + codemap_20688e[b2_shifted];
    lic_mapbytes[lv2++]=b2_remapped;

    b3_mapped = codemap_ee00d0[ *(lic_skipped+lv1+2) - 0x30 ];
    b3_shifted = ((b3_mapped / 8) | ( (b2_mapped & 0x3) << 2 )) & 0xF;
    b3_remapped = b3_shifted + codemap_20688e[b3_shifted];
    lic_mapbytes[lv2++]=b3_remapped;

    b4_mapped = codemap_ee00d0[ *(lic_skipped+lv1+3) - 0x30 ];
    b4_shifted = ((b4_mapped / 16 ) |((b3_mapped & 0x7) << 0x1)) & 0xf;
    b4_remapped = b4_shifted + codemap_20688e[b4_shifted];
    lic_mapbytes[lv2++]=b4_remapped;

    b5_shifted = b4_mapped & 0xF;
    b5_remapped = b5_shifted + codemap_20688e[b5_shifted];
    lic_mapbytes[lv2++]=b5_remapped;

    lv1 = lv1 + 4;
  }
  return(lic_mapbytes);
}

unsigned char * find_match5(unsigned char *code5)
{
  unsigned char c1,c2,c3,c4;
  unsigned char *input;
  unsigned char *lic_mapbytes;
  input=calloc(40,1);

  /* lets bruteforce it ;-) */
  for (c1=0;c1<sizeof(vb);c1++) {
   for (c2=0;c2<sizeof(vb);c2++) {
    for (c3=0;c3<sizeof(vb);c3++) {
     for (c4=0;c4<sizeof(vb);c4++) {
      input[0]=vb[c1];
      input[1]=vb[c2];
      input[2]=vb[c3];
      input[3]=vb[c4];
      input[4]='\0';
      lic_mapbytes=lic_code_map(input);
      if (!strcmp(lic_mapbytes, code5))
      {
           printf(" Match found with map bytes: %s\n\n", input);
           return(input);
      }
     }
    }
   }
  }
  return(0); // no match 
}

int main(int argc, char *argv[0])
{
 unsigned char *lic_code;
 unsigned char  lic_code_len;
 unsigned char *lic_mapbytes;
 unsigned char c1,c2,c3,c4;
 unsigned char *input;

 if (argc < 2)
  exit(-1);
 if (argc==2)
   lic_code=strtoupper((unsigned char*)argv[1]);

 printf("target-code:     %s\n", lic_code);
 lic_code_len=strlen((char*)lic_code);
 if (lic_code_len < 5) { fprintf(stderr, "code is to short !\n"); exit(-1); }
 if (lic_code_len > 5) { fprintf(stderr, "code is to long !\n"); exit(-1); }
 

 input=calloc(40,1);
 /* lets bruteforce it ;-) */
 for (c1=0;c1<sizeof(vb);c1++) {
   for (c2=0;c2<sizeof(vb);c2++) {
     for (c3=0;c3<sizeof(vb);c3++) {
       for (c4=0;c4<sizeof(vb);c4++) {
         input[0]=vb[c1];
input[1]=vb[c2];
input[2]=vb[c3];
input[3]=vb[c4];
input[4]='\0';
         lic_mapbytes=lic_code_map(input);
       //  printf("input: %s\tlic_mapbytes: %s\n", input, lic_mapbytes);
if (!strcmp(lic_mapbytes, lic_code))
         {
   printf(" Match found with map bytes: %s\n\n", input);
   return(0);
}
       }
     }
   }
 }
 printf(" No match found\n\n");
 return(-1);
}
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rory on August 15, 2013, 07:50:02 pm
What is official (sic) key? Mine shows as trial.

I guess he bought the official key, and now he's sic(k) of it  ;)

(The official key shows as "offcial" on the screen, so that is what he tried to type but he made a mistake quoting the mistake...)

The Latin adverb sic ("thus"; in full: sic erat scriptum, "thus was it written") added immediately after a quoted word or phrase (or a longer piece of text), indicates that the quotation has been transcribed exactly as found in the original source, complete with any erroneous spelling or other nonstandard presentation.

Hahaha you're right. I make a lot of mistakes...

But not this time. They actually spelt it 'offical'  !
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on August 15, 2013, 08:08:00 pm
But not this time. They actually spelt it 'offical'  !

They keep trying and eventually will get it right, in the DS2000 series it is "offcial" !
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on August 15, 2013, 09:07:04 pm
DS2000

Code: [Select]
MODEL_DSModelType_modify_?_sub_1D6BE2                ROM    001D6BE2 0000005E R . . . . . .
MODEL_MakeDSModelType_sub_9850A                      ROM    0009850A 00000042 R . . . . . .
MODEL_MakeDSXString_sub_F204E                        ROM    000F204E 00000056 R . . . . . .
MODEL_....

                                    ...

Some of these functions are not accessible. Hidden menu? Any ideas?

Sub-algorithms in firmware. Right? I said before functions, no menu.
But I'm sure there is a hidden menu, that use some of this subs, and I think that in this forum only a few guys have the knowledge to find it.
We already know this: "Press the [Menu7][Menu6][Menu7][Utility] buttons one after another quickly."

Cheers.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on August 15, 2013, 11:13:17 pm
Those are no menus These are Subs in the Firmware the Names are added from cybernet  read that post to 100% thén you will know
Is there an IDA database for grabbing somewhere?
no, but there is cybernet's sig and the ida bfin stuff posted in this thread.

After looking at it loading from the GEL is shit (am I right?), having a dump would be nice.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DL5TOR on August 16, 2013, 04:39:17 am
Those are no menus These are Subs in the Firmware the Names are added from cybernet  read that post to 100% thén you will know
Is there an IDA database for grabbing somewhere?
no, but there is cybernet's sig and the ida bfin stuff posted in this thread.

After looking at it loading from the GEL is shit (am I right?), having a dump would be nice.

btw did you get my pm
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on August 16, 2013, 04:41:26 am
no. don't see it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on August 18, 2013, 12:21:42 am
Could someone upload JTAG Dump of a DS2072?
Thanks.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: engr_rf on August 18, 2013, 08:16:54 pm
[quote author=synapsis link=topic=17002.msg276813#msg276813 date=1376517256]
I was in another city trying to find a job (no luck) and my PMs blow up about cybernet's latest offering.

I don't have a DSA815, so the only way I could test this code is to compare the output to cybernet's Linux code using Dave's demo unit serial number from his video. So, this code is considered beta.

Edit: Oh yeah, this is the Windows version of the keygen with DS2000 and DSA800 generators.
[/quote]


Thank you Synapsis, Cybernet, and other contributors for your excellent work in decoding the license key algorithms and developing the keygen programs!

(Synapsis, if you haven't found work yet, have you considered applying to the appropriate government agencies for a position in cryptology? You have certainly demonstrated your abilities and the drive necessary to complete a task.)

Would it be possible (and practical) to develop license codes for Rigol's 'UltraSpectrum' program for the DSA815 that go beyond the 15 day free trial?

Thanks again. 

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on August 18, 2013, 11:34:44 pm
(Synapsis, if you haven't found work yet, have you considered applying to the appropriate government agencies for a position in cryptology? You have certainly demonstrated your abilities and the drive necessary to complete a task.)
He used the MIRACL library and basically copied the code from rigen.c, which was also mostly copied stuff by cybernet. Both readily admit ECC is hard shit and they don't understand it much, same goes for me ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: synapsis on August 19, 2013, 12:07:02 am
(Synapsis, if you haven't found work yet, have you considered applying to the appropriate government agencies for a position in cryptology? You have certainly demonstrated your abilities and the drive necessary to complete a task.)
He used the MIRACL library and basically copied the code from rigen.c, which was also mostly copied stuff by cybernet. Both readily admit ECC is hard shit and they don't understand it much, same goes for me ;)

My crypto-fu is minimal at best, RiGen is basically a Windows wrapper around cybernet's code. It's been years since I've taken my Applied Cryptography book off the shelf. My problem is that I'm a PLC developer in a city without industry.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Boatanchor on August 19, 2013, 11:15:14 am
So, maybe I missed it buried deep within the last 60 odd pages, but was there actually a windows keygen to activate the options in the DSA-815TG?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: engr_rf on August 19, 2013, 01:41:04 pm
Boatanchor, see Reply #955 on page 64 for RiGen-2b1.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: claude3386 on August 19, 2013, 02:41:51 pm
Tried RiGen-2b1 on the new MSO4000, works except that one of the option is not activated: "FlexRay Decode".
And I can't go back to the trial versions, even having selected the trial button in RiGen.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on August 19, 2013, 03:49:39 pm
can u post a screenshot (installed licenses) and let us know your used option code ? guess the number of options is then higher than our current maximum but a new option could should do the trick fine.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: claude3386 on August 20, 2013, 02:14:49 am
It seems that the DSO4000 and MSO4000 series share the same license system.
Here is how I have setup Rigen:
http://atobit.com/wp-content/uploads/2013/08/Rigenv2b1.jpg (http://atobit.com/wp-content/uploads/2013/08/Rigenv2b1.jpg)
As the DSO/MSO4000 series are already fully loaded of options except the decode ones, it could be nice to have a interface just for those models.
Here is what I got on the MSO4014:
http://atobit.com/wp-content/uploads/2013/08/MSO4014_Options.jpg (http://atobit.com/wp-content/uploads/2013/08/MSO4014_Options.jpg)
The FlexRay decode is not activated AND the return to the trial versions doesn't work as well.
As you have mentioned, there are maybe some parameters that need to be adjusted.
I'd like to go back to the trial mode, so I could input the code for the options I purchased with the MSO.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Uup on August 20, 2013, 02:55:51 am
You used the wrong code. The Windows keygen isn't setup for the 4000 series. You will need to work out the code. I posted the info that I worked out on my DS4024 back in post 713 on page 48. Check that table and work out what you want, or just try code BAA9 to turn on all the decode options.

Eg. Enter BAA9 in the code box in the Windows keygen, instead of the value already there, then generate the licence key.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: leafi on August 20, 2013, 02:59:39 am
Where did you get the MSO4014 from? I do not even see that on their website. Is that new?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: claude3386 on August 20, 2013, 04:09:34 am
Thanks Uup! I'll try the proposed option code and I'll looked what you have published.

leafi, I'm living in China, the MSO4000 series is available here, you can get a unit within 4~5 weeks.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on August 20, 2013, 11:24:37 am
Would it be possible (and practical) to develop license codes for Rigol's 'UltraSpectrum' program for the DSA815 that go beyond the 15 day free trial?

I think it's possible. UltraSpectrum binaries contain RigolRunTime.dll that exports two functions: CryptRigolVerifySetPublicKey and CryptRigolVerifyOptionsVerify. There is MIRACL library inside this DLL and - guess what - the same flawed ECC parameters as in DS/DSA firmware. There is reference to this DLL and its functions in RIGOL_DSA_Tools_UltraSpectrum_en.exe, but I don't have DSA815 to check what public key is being used by UltraSpectrum (I didn't find it as plaintext in executables). Alternatively it could be possible to modify CryptRigolVerifyOptionsVerify function so that it always returns TRUE.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on August 20, 2013, 12:00:59 pm
Would it be possible (and practical) to develop license codes for Rigol's 'UltraSpectrum' program for the DSA815 that go beyond the 15 day free trial?

I think it's possible. UltraSpectrum binaries contain RigolRunTime.dll that exports two functions: CryptRigolVerifySetPublicKey and CryptRigolVerifyOptionsVerify. There is MIRACL library inside this DLL and - guess what - the same flawed ECC parameters as in DS/DSA firmware. There is reference to this DLL and its functions in RIGOL_DSA_Tools_UltraSpectrum_en.exe, but I don't have DSA815 to check what public key is being used by UltraSpectrum (I didn't find it as plaintext in executables). Alternatively it could be possible to modify CryptRigolVerifyOptionsVerify function so that it always returns TRUE.

surprise surprise ;-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: claude3386 on August 20, 2013, 12:42:34 pm
I comeback with the options setup on the MSO4014.
I use first BSAT options code: all options installed, including Flexray

I then tried to uninstall all options:
VSAT: said "Fail to install"
AAA9: said "Options installed" but didn't change previous official install
BAA9: same results as AAA9

Can't figure what options code to use to uninstall all options.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on August 20, 2013, 01:32:04 pm
I comeback with the options setup on the MSO4014.
I use first BSAT options code: all options installed, including Flexray

Did you try DSA9 ?
Title: Sniffing the Rigol's internal I2C bus
Post by: claude3386 on August 20, 2013, 02:02:53 pm
Just tried with DSA9, the device said the option is installed but no change, all options still activated.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on August 20, 2013, 02:17:30 pm
Just tried with DSA9, the device said the option is installed but no change, all options still activated.

Are you trying to uninstall the license?  If so, you must use scpi to do this...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: claude3386 on August 20, 2013, 02:30:30 pm
Oh yes, I try to uninstall the license.
The procedure using scpi has been described in the thread?
Maybe this option: ":SYSTem:OPTion:UNINSTall"
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Dave on August 20, 2013, 03:47:54 pm
One thousand replies in this thread! :)
I haven't been following too well... Are you guys planning on cracking the DG4000 series function generators as well?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: claude3386 on August 21, 2013, 11:42:00 am
I'm back again with the options install/uninstall on a MSO4014.

As suggested, the scpi command ":SYSTem:OPTion:UNINSTall" uninstall all options, as well as the command ":SYSTem:OPTion:INSTall <license>" install the options.

All options can be installed with the BSAT and BAA9 options code. Did not yet tested others.

Thanks to all contributors for the help!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Clint on August 22, 2013, 03:31:47 pm
Another Big THANKYOU for all involved  :clap:

(http://media2.turbosport.co.uk/2011/5/2013082217477013407DS2_QuickPrint5.png)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Co6aka on August 22, 2013, 11:34:53 pm
surprise surprise ;-)

Cybernet, PM me with your preferred communications method; have some info that might be useful. ;-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigol-Friend on August 23, 2013, 06:46:29 pm
Hi Ladys and Gentlemen  ;),

at first, please forgive my wrong english. I have never learn this language  :(   here in Germany.

Ok, i have a question, please can onebody help me?

Some days ago I bought a DSA815-TG from Rigol (for me as radio amateur a phantastic instrument) and after that I read the interesst messages here, but I do not understand all (language).

Naturally is it for me nice to open the hidden options, too and so I download the file RiGen-2b1.zip and executed RiGen.exe (a very, very big thanks to Cybernet  ::), who develop it)

But I see I must input a "private key" in this keygenerator. And that is my problem, from where I can get this key? Here I found no information about.

That was my question.


Many thanks for read my crazy english....., sorry i can not better.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on August 23, 2013, 06:51:43 pm
Der gesuchte Schlüssel ist: "80444DFECE903E"
The private key you are searching is: "80444DFECE903E"

Du kannst diesen auch in der Antwort #903 von "jamesb" finden.
You can find this private key in reply #903  from "jamesb".

Schicke mir eine eMail wenn Du noch Fragen hast.
Send me an eMail if you have more questions

73 de Hammy

PS: Thanks a lot to cybernet and dl5tor and all the others! Great work!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigol-Friend on August 23, 2013, 06:59:44 pm
Hallo Hammy,

super, so schnell eine Antwort... Herzlichen Dank, ich werde den Key gleich mal versuchen.
Klasse,  ;D

Hi Hammy,
very fast answer... best thanks for it. I will try this key in the next minutes, phantastic,  ;D


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigol-Friend on August 23, 2013, 07:10:06 pm
Phantastic.....

All options of DSA815 are switcht "forever".
What a great work from Cybernet !!

@Hammy:
Thanks again for this private key. Where you found it?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on August 23, 2013, 07:12:07 pm
Hier im thread war er erwähnt und auch im sourcecode von cybernet:
You can find the private key with the search option and also inside the sourcecode from cybernet:
http://pastebin.com/ghYHnCfT (http://pastebin.com/ghYHnCfT)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigol-Friend on August 23, 2013, 07:19:47 pm
Ja, hattest Du ja auch vorher schon geschrieben (jamesb). Aber ich war eben so aufgeregt, dass ich diesen Hinweis gar nicht beachtet hatte  :-[
Und -ich muss es gestehen- in den C-Quelltext hatte ich gar nicht reingeschaut, da das Programmieren nicht so meine Stärke ist.

Tschüss und nochmals vielen Dank für Deine freundliche und schnelle Hilfe.
Rigol-Friend
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on August 23, 2013, 07:27:49 pm
LOL http://translate.google.es/?hl=es&tab=TT#de/en/Rigol-Friend (http://translate.google.es/?hl=es&tab=TT#de/en/Rigol-Friend)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MaxwellsSilverHammer on August 23, 2013, 07:35:18 pm
I recently updated my options on my DS2202 and noticed the following strange issue under installed options with respect to the BW. Seems I have a 100MHz/200MHz scope now????? Any input would be greatly appreciated.  :-//

(http://www.eevblog.com/Volumes/KINGSTON/DS2_QuickPrint1.png)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: synapsis on August 23, 2013, 07:48:11 pm
The private key is found by following the link in the RiGen app.

Having 100M/200M on the DS2000 scope is from enabling both options at the same time. (I forgot which code that was.) My scope has both options visible and still works fine.

While testing RiGen-1 I installed many keys on my scope.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on August 23, 2013, 08:49:58 pm
LOL http://translate.google.es/?hl=es&tab=TT#de/en/Rigol-Friend (http://translate.google.es/?hl=es&tab=TT#de/en/Rigol-Friend)

Rigol = Atten  :-DD

Sorry folks, for highjacking the language. This was the fastest way to help a fellow ham.  :-//
Title: Sniffing the Rigol's internal I2C bus
Post by: Wim13 on August 24, 2013, 10:46:37 am
I recently updated my options on my DS2202 and noticed the following strange issue under installed options with respect to the BW. Seems I have a 100MHz/200MHz scope now????? Any input would be greatly appreciated.  :-//

(http://www.eevblog.com/Volumes/KINGSTON/DS2_QuickPrint1.png)

Is only à problem with firmware 01.00.05, then bandwidth options are not working
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on August 24, 2013, 03:07:54 pm
I recently updated my options on my DS2202 and noticed the following strange issue under installed options with respect to the BW. Seems I have a 100MHz/200MHz scope now????? Any input would be greatly appreciated.  :-//

(http://www.eevblog.com/Volumes/KINGSTON/DS2_QuickPrint1.png)
Yes, you used the DSA9 option code, if you used the DSAZ code it would have had only the 200MHz BW option.
Both codes work OK (on the new firmware 01.01.00.02)
FIRMWARE LINK :
https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684 (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tlu on August 25, 2013, 07:05:32 am
I recently updated my options on my DS2202 and noticed the following strange issue under installed options with respect to the BW. Seems I have a 100MHz/200MHz scope now????? Any input would be greatly appreciated.  :-//

(http://www.eevblog.com/Volumes/KINGSTON/DS2_QuickPrint1.png)
Yes, you used the DSA9 option code, if you used the DSAZ code it would have had only the 200MHz BW option.
Both codes work OK (on the new firmware 01.01.00.02)
FIRMWARE LINK :
https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684 (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684)

So which code is better?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mickpah on August 25, 2013, 07:31:10 am
I received last week my DP832. Without options. Does anyone know the JTAG pinout?
Is anyone willing to post his serial number and a valid code? I would be interest in a keygen ...
I was just about to be realy lazy and order one of these http://www.grandideastudio.com/portfolio/jtagulator/ (http://www.grandideastudio.com/portfolio/jtagulator/)
out of stock though
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: iceisfun on August 26, 2013, 09:38:37 pm
Is there a problem using this with Software version 00.01.01
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MaxwellsSilverHammer on August 26, 2013, 09:44:38 pm
Is there a problem using this with Software version 00.01.01

only use the latest firmware 01.01.00.02 if you would like to update your options. The latest firmware can be found on another thread. Cheers
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on August 26, 2013, 10:45:42 pm
Those who now have by serial number DS2A0000000001 probably rewrited some other important data, besides the S/N.
But look at the images attached (DSX_QuickPrint1.png and SNumber.JPG). Is as if the loss of such data force to use the data contained in the firmware.

The question is: What S/N have you used to install the options? DS2A0000000001?

It seems that the S/N is write in more places:
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg265211/#msg265211 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg265211/#msg265211)

I attached other curious images. Is impressive all what cybernet has achieved...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: iceisfun on August 27, 2013, 12:16:58 am
Is there a problem using this with Software version 00.01.01

only use the latest firmware 01.01.00.02 if you would like to update your options. The latest firmware can be found on another thread. Cheers

Got it working, had a data entry error - Thanks to everyone who worked on this.

I wish Rigol had sent the trial key as a card with the scope so you could enable them when you wanted, I'm pretty new to scopes and by the time I got familiar with things I burned up most of my trial, I need to mess with some I2C stuff and I have been turning the scope on and off using it as little as possible but now I can just use it normally and not worry about using up my trial time.


I'll be getting other Rigol products crackable or not, the quality (minus spelling errors) seems awesome. All the cheap stuff I've gotten needs replaced like the cheap ebay PSU and sig gen.




Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on August 27, 2013, 01:28:11 am
Those who now have by serial number DS2A0000000001 probably rewrited some other important data, besides the S/N.
What other important bits are there?

If, after self-cal, using standards it measures correctly, what does it matter? It doesn't seem to have changed anything else by outward appearance, and if the unit functions normally, I really don't care what else could have changed, I can't see it anyway.

The only reason I care about SN is if I decide to sell it shortly to upgrade.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on August 27, 2013, 01:45:01 am
The only reason I care about SN is if I decide to sell it shortly to upgrade.
* Then modify/edit the firmware, change "DS2A000 .. 1" string for yours S/N. And re-install it.
You don't lose anything if try it.  ;)

You can use a hex editor, 0xF045B0 see SNumber.JPG attached in my previous message.



Edit:
* It seems that does not work.  :(
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on August 27, 2013, 12:12:46 pm
Those who now have by serial number DS2A0000000001 probably rewrited some other important data, besides the S/N.
But look at the images attached (DSX_QuickPrint1.png and SNumber.JPG). Is as if the loss of such data force to use the data contained in the firmware.

The question is: What S/N have you used to install the options? DS2A0000000001?

It seems that the S/N is write in more places:
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg265211/#msg265211 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg265211/#msg265211)

I attached other curious images. Is impressive all what cybernet has achieved...
It looks like from the screenshot you have found an other hidden menu, where you can enter the scope model, serial number, and fan speed !
Question now is how to get there  ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on August 27, 2013, 12:25:30 pm
It looks like from the screenshot you have found an other hidden menu, where you can enter the scope model, serial number, and fan speed !
Question now is how to get there  ;)
No, I have not found how access to the hidden menu, if it exists. I wish.
Is only that I think there is the possibility to modify the S/N modifying the firmware. And it may only work in some cases, I have not tried.

The capture Hidden_Menu.JPG only shows the ASCII strings of a possible menu.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MaxwellsSilverHammer on August 27, 2013, 03:21:27 pm
It looks like from the screenshot you have found an other hidden menu, where you can enter the scope model, serial number, and fan speed !
Question now is how to get there  ;)
No, I have not found how access to the hidden menu, if it exists. I wish.
Is only that I think there is the possibility to modify the S/N modifying the firmware. And it may only work in some cases, I have not tried.

The capture Hidden_Menu.JPG only shows the ASCII strings of a possible menu.

I thought I read somewhere in this thread where you can access the hidden menu via certain keystrokes. I may be wrong or maybe dreamed it, lol. I will look again and if I find it I will quote/repost here
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on August 27, 2013, 03:28:19 pm
Please someone who has had the problem with the S/N:
 What S/N have you used to install the options, after the "failure", DS2A0...01 or original S/N?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MaxwellsSilverHammer on August 27, 2013, 03:40:27 pm
It looks like from the screenshot you have found an other hidden menu, where you can enter the scope model, serial number, and fan speed !
Question now is how to get there  ;)
No, I have not found how access to the hidden menu, if it exists. I wish.
Is only that I think there is the possibility to modify the S/N modifying the firmware. And it may only work in some cases, I have not tried.

The capture Hidden_Menu.JPG only shows the ASCII strings of a possible menu.

I thought I read somewhere in this thread where you can access the hidden menu via certain keystrokes. I may be wrong or maybe dreamed it, lol. I will look again and if I find it I will quote/repost here

The keystrokes must be simple and accessible by 4 finger press usually from my experience. I will try and hack it and let you know if I am successful. Cheers
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on August 27, 2013, 03:57:17 pm
Ok, I can not wait ...  :scared:
LOL...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on August 27, 2013, 04:35:04 pm
infos there -> https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg282750/#msg282750 (https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg282750/#msg282750)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on August 27, 2013, 10:05:50 pm
Please someone who has had the problem with the S/N:
 What S/N have you used to install the options, after the "failure", DS2A0...01 or original S/N?
after failure, original will no longer work, must use the sn reported on info screen.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on August 27, 2013, 10:43:06 pm
Please someone who has had the problem with the S/N:
 What S/N have you used to install the options, after the "failure", DS2A0...01 or original S/N?
after failure, original will no longer work, must use the sn reported on info screen.

Thank you very much.
Now look at this picture:
(https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/?action=dlattach;attach=58761;image)
EEVBLGTECHNOLOGIES??? DS2A140000000???
cybernet: How did you do that?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on August 27, 2013, 10:52:19 pm
ds1000z seems to use the same ecc parameters and private key as the DS2000, so the rikey.c should work (with the ds2000 priv key).
option bits are unknown as i have not yet seen a trial or official key - somebody should try it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tinhead on August 27, 2013, 10:56:18 pm
ds1000z seems to use the same ecc parameters and private key as the DS2000

where you got that? Not from firmware, so i assume you checed PC sw?
Title: Sniffing the Rigol's internal I2C bus
Post by: Rory on August 27, 2013, 10:56:35 pm
So, can you change the FFT trace color ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on August 27, 2013, 10:59:39 pm
ds1000z seems to use the same ecc parameters and private key as the DS2000

where you got that? Not from firmware, so i assume you checed PC sw?

a user PM'ed strings <firmware.GEL> - curve parameters, primes all the same - public key is different, but derived from the same already known private key, they just used another seed value to generate it - so i believe it will work out of the box with the DS2k keygen.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: nack on August 28, 2013, 03:37:53 pm
Today I've got my stock DS2072 scope and hooked it up to a home build pulse generator which surprised me!

It is bone stock and havent't entered any license codes yet. Having about 2050 trail minutes left, it clearly shows a much higher bandwidth than the claimed 70 MHz. I've measured a risetime of 1.646ns (50 Ohm terminated) which equates to a bandwidth of roughly 210 MHz. It looks like the higher bandwidth 'option' is also active during the trail period?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: darrylp on August 28, 2013, 03:50:30 pm
You need to extend the pulse at its high level. The scope is doing a 10 to 90 measurement on a pulse that no doubt doesn't reach its proper peak.

--
 Darryl

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on August 28, 2013, 05:06:30 pm
Today I've got my stock DS2072 scope and hooked it up to a home build pulse generator which surprised me!

It is bone stock and havent't entered any license codes yet. Having about 2050 trail minutes left, it clearly shows a much higher bandwidth than the claimed 70 MHz. I've measured a risetime of 1.646ns (50 Ohm terminated) which equates to a bandwidth of roughly 210 MHz. It looks like the higher bandwidth 'option' is also active during the trail period?
Is the option screen showing you a 200MHz option ?
Is the system info screen saying it is a DS2072 ?

When I got mine DS2072 there was a standard 4 ns rise time, so I guess Rigol is now giving it away on their 70MHz models, or they made a stupid mistake by configuring it wrongly.

Another possibility is that your scope has been altered by the dealer/seller.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on August 28, 2013, 05:08:54 pm
You need to extend the pulse at its high level. The scope is doing a 10 to 90 measurement on a pulse that no doubt doesn't reach its proper peak.

--
 Darryl
You can clearly see from the picture that the rise time is about 1.5 to max 2 ns. so what the scope indicates is probably OK
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: nack on August 28, 2013, 05:19:30 pm
Is the option screen showing you a 200MHz option ?
Is the system info screen saying it is a DS2072 ?

When I got mine DS2072 there was a standard 4 ns rise time, so I guess Rigol is now giving it away on their 70MHz models, or they made a stupid mistake by configuring it wrongly.

Another possibility is that your scope has been altered by the dealer/seller.

The option screen shows a regular 2072 and I have checked the rise time is calculated correctly at the 10% and 90% limits as shown by the cursors set to Auto.
I doubt the dealer has tweaked anything, initially the DS2072 was sold out and it took another three weeks for mine to arrive.
Title: Re: Re: Sniffing the Rigol's internal I2C bus
Post by: darrylp on August 28, 2013, 05:21:00 pm
You need to extend the pulse at its high level. The scope is doing a 10 to 90 measurement on a pulse that no doubt doesn't reach its proper peak.

--
 Darryl
You can clearly see from the picture that the rise time is about 1.5 to max 2 ns. so what the scope indicates is probably OK

Go watch some Rev blog videos where Dave and others had to extend the pulse width to get a full pulse so that scope will measure / calculate the right rise time ...   And hence lead you to a closer analog bandwidth setting.
--
 Darryl

Title: Re: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on August 28, 2013, 05:40:27 pm
You need to extend the pulse at its high level. The scope is doing a 10 to 90 measurement on a pulse that no doubt doesn't reach its proper peak.

--
 Darryl
You can clearly see from the picture that the rise time is about 1.5 to max 2 ns. so what the scope indicates is probably OK
Go watch some Rev blog videos where Dave and others had to extend the pulse width to get a full pulse so that scope will measure / calculate the right rise time ...   And hence lead you to a closer analog bandwidth setting.
--
 Darryl
I agree with you that the pulser would benefit from a pulse lenght that is longer (replace the capacitor with a open 50 ohms coax of 30 cm), but in this case the pictures from nack leave no room for mis-interpertation, and the measurement is correct !

Title: Re: Re: Re: Sniffing the Rigol's internal I2C bus
Post by: darrylp on August 28, 2013, 05:52:35 pm
You need to extend the pulse at its high level. The scope is doing a 10 to 90 measurement on a pulse that no doubt doesn't reach its proper peak.

--
 Darryl
You can clearly see from the picture that the rise time is about 1.5 to max 2 ns. so what the scope indicates is probably OK
Go watch some Rev blog videos where Dave and others had to extend the pulse width to get a full pulse so that scope will measure / calculate the right rise time ...   And hence lead you to a closer analog bandwidth setting.
--
 Darryl
I agree with you that the pulser would benefit from a pulse lenght that is longer (replace the capacitor with a open 50 ohms coax of 30 cm), but in this case the pictures from nack leave no room for mis-interpertation, and the measurement is correct !

I'd say its measuring 10 to 90% of the pulse it saw, and with a bandwidth most likely closer to 100MHz.
It didn't see all the pulse and as its got a smaller pulse and hence as its a delta. It comes back with a shorter time. Not the real rise time of what the pulse should be to gauge what the bandwidth is.

--
 Darryl

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: darrylp on August 28, 2013, 05:57:09 pm
BTW, I'm not knocking the scope. I have one :-)

But do that plotting points not vectors turn off sin x / x and it shows a different picture.


--
 Darryl

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: warp_foo on August 28, 2013, 05:59:56 pm
Just got notified that my 2072 will be shipped on 8/30 versus 9/24... yay. About the only way I can offer payback for the hack is to provide info. Is anyone looking for info on these units? HW versions, FW versions ...?

Title: Re: Re: Re: Sniffing the Rigol's internal I2C bus
Post by: nack on August 28, 2013, 06:59:47 pm
You need to extend the pulse at its high level. The scope is doing a 10 to 90 measurement on a pulse that no doubt doesn't reach its proper peak.

--
 Darryl
You can clearly see from the picture that the rise time is about 1.5 to max 2 ns. so what the scope indicates is probably OK
Go watch some Rev blog videos where Dave and others had to extend the pulse width to get a full pulse so that scope will measure / calculate the right rise time ...   And hence lead you to a closer analog bandwidth setting.
--
 Darryl
I agree with you that the pulser would benefit from a pulse lenght that is longer (replace the capacitor with a open 50 ohms coax of 30 cm), but in this case the pictures from nack leave no room for mis-interpertation, and the measurement is correct !

I'd say its measuring 10 to 90% of the pulse it saw, and with a bandwidth most likely closer to 100MHz.
It didn't see all the pulse and as its got a smaller pulse and hence as its a delta. It comes back with a shorter time. Not the real rise time of what the pulse should be to gauge what the bandwidth is.

--
 Darryl

When I am thinking about it, you are completely correct. I have added a little capacitance to the main cap to stretch the pulse a little. The risetime is now 2.9ns which equates to about 120 MHz. Much more in line with expectations for a stock 2072.
Title: Re: Re: Re: Re: Sniffing the Rigol's internal I2C bus
Post by: darrylp on August 28, 2013, 07:07:41 pm
You need to extend the pulse at its high level. The scope is doing a 10 to 90 measurement on a pulse that no doubt doesn't reach its proper peak.

--
 Darryl
You can clearly see from the picture that the rise time is about 1.5 to max 2 ns. so what the scope indicates is probably OK
Go watch some Rev blog videos where Dave and others had to extend the pulse width to get a full pulse so that scope will measure / calculate the right rise time ...   And hence lead you to a closer analog bandwidth setting.
--
 Darryl
I agree with you that the pulser would benefit from a pulse lenght that is longer (replace the capacitor with a open 50 ohms coax of 30 cm), but in this case the pictures from nack leave no room for mis-interpertation, and the measurement is correct !

I'd say its measuring 10 to 90% of the pulse it saw, and with a bandwidth most likely closer to 100MHz.
It didn't see all the pulse and as its got a smaller pulse and hence as its a delta. It comes back with a shorter time. Not the real rise time of what the pulse should be to gauge what the bandwidth is.

--
 Darryl

When I am thinking about it, you are completely correct. I have added a little capacitance to the main cap to stretch the pulse a little. The risetime is now 2.9ns which equates to about 120 MHz. Much more in line with expectations for a stock 2072.

Of course a real 200 ~ 225 MHz is only a key gen away :-)

--
 Darryl

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on August 29, 2013, 01:10:28 am
I have come a little further with my DB832. Here ist the JTAG pinout. I have already copied a part of the RAM. Exactly the same ECC parameters as the DS series! Can someone please send me a working serial / license combination? AAAB and DSAB not work...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jasonbrent on August 29, 2013, 01:53:51 am
I have come a little further with my DB832. Here ist the JTAG pinout. I have already copied a part of the RAM. Exactly the same ECC parameters as the DS series! Can someone please send me a working serial / license combination? AAAB and DSAB not work...

Hmm, curious. In Dave's tear down of the DP832, the sticker inside said DP832A. Yours seems to show DP800....

-jbl
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on August 29, 2013, 01:58:16 am
I have come a little further with my DB832. Here ist the JTAG pinout. I have already copied a part of the RAM. Exactly the same ECC parameters as the DS series! Can someone please send me a working serial / license combination? AAAB and DSAB not work...

Hmm, curious. In Dave's tear down of the DP832, the sticker inside said DP832A. Yours seems to show DP800....

-jbl

It's a screenshot from Dave's video @ 19:02.  ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jasonbrent on August 29, 2013, 01:59:20 am
I have come a little further with my DB832. Here ist the JTAG pinout. I have already copied a part of the RAM. Exactly the same ECC parameters as the DS series! Can someone please send me a working serial / license combination? AAAB and DSAB not work...

Hmm, curious. In Dave's tear down of the DP832, the sticker inside said DP832A. Yours seems to show DP800....

-jbl

It's a screenshot from Dave's video @ 19:02.  ;)

Ahhhh... I see.

They must have some that say DP832A and some that say DP800 inside then... </end conspiracy theory>.

:-)

-jbl
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on August 29, 2013, 09:49:51 am
I have come a little further with my DB832. Here ist the JTAG pinout. I have already copied a part of the RAM. Exactly the same ECC parameters as the DS series! Can someone please send me a working serial / license combination? AAAB and DSAB not work...

 :-+ - did u figure out what compiler/libs they used ? - for ARM there should be plenty of FLAIR libs available which might ease the further disassembly.
@ecc params ->  :-DD
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: metalphreak on August 29, 2013, 11:10:31 am
I have come a little further with my DB832. Here ist the JTAG pinout. I have already copied a part of the RAM. Exactly the same ECC parameters as the DS series! Can someone please send me a working serial / license combination? AAAB and DSAB not work...

Hmm, curious. In Dave's tear down of the DP832, the sticker inside said DP832A. Yours seems to show DP800....

-jbl

It's a screenshot from Dave's video @ 19:02.  ;)

Ahhhh... I see.

They must have some that say DP832A and some that say DP800 inside then... </end conspiracy theory>.

:-)

-jbl

The top and bottom boards said DP832A didn't they? That's a photo of the front panel which would be the same for all of them regardless :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mickpah on August 29, 2013, 11:42:18 am

Quote

The top and bottom boards said DP832A didn't they? That's a photo of the front panel which would be the same for all of them regardless :)

photos here

https://www.eevblog.com/forum/testgear/new-rigol-dc-psu's/135/ (https://www.eevblog.com/forum/testgear/new-rigol-dc-psu's/135/)

https://www.eevblog.com/forum/testgear/new-rigol-dc-psu's/msg266949/#msg266949 (https://www.eevblog.com/forum/testgear/new-rigol-dc-psu's/msg266949/#msg266949)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jasonbrent on August 29, 2013, 02:35:17 pm
I just unboxed my DS2102 (got tired of waiting for the 2072) that was a drop ship from Rigol ordered through Tequipment.Net. Out of the box, it came with the RP3300 passive probes (not As) and the DS2102 shipped with:

Software Version: 00.01.00.00.03
Hardware Version: 1.0.1.0.0
FPGA Version:

SPU: 03.01.05
WPU: 00.06.05
CCU: 12.29.00
MCU: 00.05

.... now to find the post in the thread that had the key gen bits... :)

EDIT: And now I have a fully optioned DS2202. Wonder if I can find the 2202 faceplate sticker somehwere...:-)

-jbl
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on August 29, 2013, 03:18:49 pm
I have come a little further with my DB832. Here ist the JTAG pinout. I have already copied a part of the RAM. Exactly the same ECC parameters as the DS series! Can someone please send me a working serial / license combination? AAAB and DSAB not work...

 :-+ - did u figure out what compiler/libs they used ? - for ARM there should be plenty of FLAIR libs available which might ease the further disassembly.
@ecc params ->  :-DD

I only had time to copy the first few Mb. Using grep I have known ECC parameters found. I 'm on vacation until Monday. Hopefully I get a valid license code via PM. Then a decompile would possibly not necessary.
Title: Re: Re: Sniffing the Rigol's internal I2C bus
Post by: darrylp on August 30, 2013, 10:03:50 am
I just unboxed my DS2102 (got tired of waiting for the 2072) that was a drop ship from Rigol ordered through Tequipment.Net. Out of the box, it came with the RP3300 passive probes (not As) and the DS2102 shipped with:

Software Version: 00.01.00.00.03
Hardware Version: 1.0.1.0.0
FPGA Version:

SPU: 03.01.05
WPU: 00.06.05
CCU: 12.29.00
MCU: 00.05

.... now to find the post in the thread that had the key gen bits... :)

EDIT: And now I have a fully optioned DS2202. Wonder if I can find the 2202 faceplate sticker somehwere...:-)

-jbl

What is the leading part of your serial number ?

So we can see date of assembly.

--
 Darryl

Title: Re: Re: Sniffing the Rigol's internal I2C bus
Post by: jasonbrent on August 31, 2013, 04:58:11 am
I just unboxed my DS2102 (got tired of waiting for the 2072) that was a drop ship from Rigol ordered through Tequipment.Net. Out of the box, it came with the RP3300 passive probes (not As) and the DS2102 shipped with:

Software Version: 00.01.00.00.03
Hardware Version: 1.0.1.0.0
FPGA Version:

SPU: 03.01.05
WPU: 00.06.05
CCU: 12.29.00
MCU: 00.05

.... now to find the post in the thread that had the key gen bits... :)

EDIT: And now I have a fully optioned DS2202. Wonder if I can find the 2202 faceplate sticker somehwere...:-)

-jbl

What is the leading part of your serial number ?

So we can see date of assembly.

--
 Darryl

DS2A1517...

How does that decode to assembly date?

-jbl
Title: Re: Re: Re: Sniffing the Rigol's internal I2C bus
Post by: darrylp on August 31, 2013, 03:21:45 pm
I just unboxed my DS2102 (got tired of waiting for the 2072) that was a drop ship from Rigol ordered through Tequipment.Net. Out of the box, it came with the RP3300 passive probes (not As) and the DS2102 shipped with:

Software Version: 00.01.00.00.03
Hardware Version: 1.0.1.0.0
FPGA Version:

SPU: 03.01.05
WPU: 00.06.05
CCU: 12.29.00
MCU: 00.05

.... now to find the post in the thread that had the key gen bits... :)

EDIT: And now I have a fully optioned DS2202. Wonder if I can find the 2202 faceplate sticker somehwere...:-)

-jbl

What is the leading part of your serial number ?

So we can see date of assembly.

--
 Darryl

DS2A1517...

How does that decode to assembly date?

-jbl

I've heard the 15 equates to 2013, 14 to 2012 and so on backwards. The 17 is week 17 of the year. So its older stock before the change. Mine is 1521 and has the A probes ie non switchable. I think its week 20 that they changed. One of the threads here has more info on it. What's your letter of calibration say for the date ?
--
 Darryl

Title: Re: Re: Re: Sniffing the Rigol's internal I2C bus
Post by: jasonbrent on August 31, 2013, 04:14:41 pm
...snipped quotes...

I've heard the 15 equates to 2013, 14 to 2012 and so on backwards. The 17 is week 17 of the year. So its older stock before the change. Mine is 1521 and has the A probes ie non switchable. I think its week 20 that they changed. One of the threads here has more info on it. What's your letter of calibration say for the date ?
--
 Darryl

Regarding the probes, I'm going to go out on a limb and email Rigol NA and ask for the A probes to be sent to me... in part because the printed documentation shipped with my unit suggests the A probes.. long shot, but 0 cost to me to try it.

My calibration letter is from the first week of May.

This unit was a drop ship straight from Rigol to me via Tequipment (there was various confusion in the ordering process with Tequipment where they suggested it was in stock on this past Monday, but by Wednesday they told me it was back ordered and it would be a few weeks... I asked them to contact Rigol about a drop ship and I had it thursday AM at $0 cost shipping to me!).

I guess that means Rigol NA still has plenty of older stock on hand for the DS2102.

Now my goal is to actually learn some stuff about electronics. :-) I'm a hobbyist who goes all in with whatever hobby I pick up at a given point in time... after a few weeks of acquisition, I finally have a decent selection of test equipment and components to learn with.

DS2102, agilent E3610A, UDI DM383 DMM, another cheapo DMM, weller WES51, flux, solder, various tools for cutting, shaping, grabbing, holding, breadboards, ICs, a couple of microprocessors, tons of component grab bags from jameco, wires, and not enough time. :-)

As an aside, anyone know how much I should trust the DS2102's default calibration for voltage readings? The E3610A and the DS2012 agree on voltages  (at least the DS2012s average agrees, the peak is pretty far off sometimes, especially at lower voltages) but both of my DMMs read low. For example, on a 5 volt setting for the E3610A, the DS2012 average is ~= 5.00 volts, but the DM383 and the other cheapo DMM will read ~= 4.85 volts.

-jbl
Title: Re: Re: Re: Sniffing the Rigol's internal I2C bus
Post by: mtdoc on August 31, 2013, 06:46:02 pm
Mucho Kudos to those who did the work that allowed me to turn my DS2072 into a DS2202 with all the options! :clap:

Got mine a couple of weeks ago from Tequipment. Serial no ..1521...  Calibration in June

It came with the non switchable probes which personally I like - I prefer the smaller form factor and I already have a few pairs of cheap switchable probes which are fine for the occasional very low amplitude measurement.


As an aside, anyone know how much I should trust the DS2102's default calibration for voltage readings? The E3610A and the DS2012 agree on voltages  (at least the DS2012s average agrees, the peak is pretty far off sometimes, especially at lower voltages) but both of my DMMs read low. For example, on a 5 volt setting for the E3610A, the DS2012 average is ~= 5.00 volts, but the DM383 and the other cheapo DMM will read ~= 4.85 volts.

-jbl

Mine reads a bit high when measuring DC voltages as well.  :(  It's my  first digital scope so I'm not sure if this is unusual.  No big whoop I guess since it's not meant to used as a precision voltmeter - I already have a few of those. Overall, I'm very happy with it :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marcus on August 31, 2013, 09:39:57 pm
Hi,
i got my DS2072 yesterday and what should i say, AMAZING!!! I made a DS2202 out of it today.

Since i am a Windows user i had to do a lot of troubleshooting with this damn Linux-LIVE-CD, with no results.
So i searched for a .exe and found this FTP-Server with a lot of useful Documents: http://www.gotroot.ca/rigol/ (http://www.gotroot.ca/rigol/)

I thought i may be useful for some people here.

Marcus

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on September 02, 2013, 10:44:17 am
Can someone explain to me how the private key with ECDLP solver v0.2a calculated?
I have read the following constants from my DP832:

prime1 unsigned char [] = "AEBF94CEE3E707";
prime2 unsigned char [] = "AEBF94D5C6AA71";
curve_a unsigned char [] = "2982";
curve_b unsigned char [] = "3408";
point1 unsigned char [] = "7A3E808599A525";
point2 unsigned char [] = "5EC2D25AE85124"; <--- Not sure yet

PS
I still hope for a DP832 option code. I need only the code that is entered on the device.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on September 02, 2013, 03:35:28 pm
Can someone explain to me how the private key with ECDLP solver v0.2a calculated?
I have read the following constants from my DP832:

prime1 unsigned char [] = "AEBF94CEE3E707";
prime2 unsigned char [] = "AEBF94D5C6AA71";
curve_a unsigned char [] = "2982";
curve_b unsigned char [] = "3408";
point1 unsigned char [] = "7A3E808599A525";
point2 unsigned char [] = "5EC2D25AE85124"; <--- Not sure yet

PS
I still hope for a DP832 option code. I need only the code that is entered on the device.


There are 2 possible private keys for these parameters:

5C393C30FACCF4
528658A4CBDD7D

If the key verification method in DP832 is exactly the same as in DS2k, then the first one will be valid.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: docmandu on September 02, 2013, 06:15:38 pm
Can someone explain to me how the private key with ECDLP solver v0.2a calculated?
I have read the following constants from my DP832:

prime1 unsigned char [] = "AEBF94CEE3E707";
prime2 unsigned char [] = "AEBF94D5C6AA71";
curve_a unsigned char [] = "2982";
curve_b unsigned char [] = "3408";
point1 unsigned char [] = "7A3E808599A525";
point2 unsigned char [] = "5EC2D25AE85124"; <--- Not sure yet

PS
I still hope for a DP832 option code. I need only the code that is entered on the device.

---
GF := GF(49187291794761479);
E := EllipticCurve([GF|10626,13320]);
G := E![34408668876875045,11468454688366674];
K := E![26672856534896932,39931304602480539];
/*
FactorCount:=4;
17;
53;
905461;
60291817;
*/
---

GF = prime1
E = curve_a, curve_b
G = uncompressed point1 (Gx, Gy)
K = uncompressed point2 (Rx, Ry)

ECDLP requires them to be in decimal format. Use ECCTOOL by readyu to get the decimal values and to uncompress the points.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on September 02, 2013, 06:24:28 pm
Can someone explain to me how the private key with ECDLP solver v0.2a calculated?
I have read the following constants from my DP832:

prime1 unsigned char [] = "AEBF94CEE3E707";
prime2 unsigned char [] = "AEBF94D5C6AA71";
curve_a unsigned char [] = "2982";
curve_b unsigned char [] = "3408";
point1 unsigned char [] = "7A3E808599A525";
point2 unsigned char [] = "5EC2D25AE85124"; <--- Not sure yet

PS
I still hope for a DP832 option code. I need only the code that is entered on the device.

---
GF := GF(49187291794761479);
E := EllipticCurve([GF|10626,13320]);
G := E![34408668876875045,11468454688366674];
K := E![26672856534896932,39931304602480539];
/*
FactorCount:=4;
17;
53;
905461;
60291817;
*/
---

GF = prime1
E = curve_a, curve_b
G = uncompressed point1 (Gx, Gy)
K = uncompressed point2 (Rx, Ry)

ECDLP requires them to be in decimal format. Use ECCTOOL by readyu to get the decimal values and to uncompress the points.



Thank you very much. I'll test it tonight.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on September 02, 2013, 08:09:58 pm
same results with DLP&ECDLP Solver v0.6 - probably the first one 0x5C393C30FACCF4
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on September 03, 2013, 10:59:33 am
Thanks to all! Maybe someone wants to help.
Here is the DP832 NAND dump.

http://rapidshare.com/files/3695164600/Rigol%20DP832%20dump.rar (http://rapidshare.com/files/3695164600/Rigol%20DP832%20dump.rar)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hmlittle59 on September 04, 2013, 02:35:41 am
Hello All,

Got my Rigol 2102 a couple of weeks ago and still getting use to it.  Up dated the FW from :00.01.00.03 - to - 00.01.00.05. As I stated before, they said it was up to date when I bought it. :-DD Any way, I am lost on how you guys that just got your units and in one day was able to do the upgrades so quickly.  I'm just chasing my tale on trying to figure out the proper steps.  And if I do get that far, will I have to do any HEX adjustments for (Voltage reading/Bandwidth/other things...etc.). 

So my question is,  is there just one(1) file to run that will do these hack or will I have to open it up to attach some wire and hack board?

Thanks for any help and guidance.  And, yes I'm nervous about doing this, I don't want to have a BRICK

Howard


 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tlu on September 04, 2013, 03:12:46 am
Hello All,

Got my Rigol 2102 a couple of weeks ago and still getting use to it.  Up dated the FW from :00.01.00.03 - to - 00.01.00.05. As I stated before, they said it was up to date when I bought it. :-DD Any way, I am lost on how you guys that just got your units and in one day was able to do the upgrades so quickly.  I'm just chasing my tale on trying to figure out the proper steps.  And if I do get that far, will I have to do any HEX adjustments for (Voltage reading/Bandwidth/other things...etc.). 

So my question is,  is there just one(1) file to run that will do these hack or will I have to open it up to attach some wire and hack board?

Thanks for any help and guidance.  And, yes I'm nervous about doing this, I don't want to have a BRICK

Howard

Howard, I believe you have it backwards. Latest should be .02, then .03, and .05 should be the oldest of the three firmware. Update to .02 before implementing the key.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: fqahmad66 on September 04, 2013, 04:11:37 am
[quote author=synapsis link=topic=17002.msg276813#msg276813 date=1376517256]

Would it be possible (and practical) to develop license codes for Rigol's 'UltraSpectrum' program for the DSA815 that go beyond the 15 day free trial?

Thanks again.

Somebody succeeded to generate LC for UltraSpectrum??

Regards
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hmlittle59 on September 04, 2013, 04:41:54 am
Now I'm really confused |O.  I already had FW.xxxxxxx03, I installed FWxxxxxxx05.  Now I must go to FWxxxxxx02 then do the key that I can't find, correct.   After I install FWxxxxxxx02, implement key, then do I do any more FW updates?

Howard
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Marc M. on September 04, 2013, 06:25:56 am
.....then do the key that I can't find....
The key is posted somewhere earlier in this thread.  Spend a little time reading thru it and you'll find the key and lots of other relevant information.  Time well spent. :-+
After I install FWxxxxxxx02, implement key, then do I do any more FW updates?
AFAIK, version 02 is the latest version available so No, after installing the 02 firmware then key(s) you are finished.  Marmad has been keeping track of the revisions in one of the first posts in his review thread: https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/ (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/)  You'll also find the firmware there if you need it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rory on September 04, 2013, 02:06:04 pm
With the DSA815-TG, what is the procedure to uninstall the options?  :SYSTEM:OPTION:UNINSTALL  in various forms did not work for me.

I'm having problem with nonresponsive keyboard.  Is there a way to reset the device to factory state other than *RST?

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Fagear on September 04, 2013, 02:42:40 pm
Now I'm really confused |O.  I already had FW.xxxxxxx03, I installed FWxxxxxxx05.  Now I must go to FWxxxxxx02 then do the key that I can't find, correct.   After I install FWxxxxxxx02, implement key, then do I do any more FW updates?
Look carefully at firmware's order. There are known versions:
- v.00.01.00.02
- v.00.01.00.05
- v.01.00.00.03
- v.01.01.00.02

So, there are TWO .xxxxxx02 versions, and latest one is newer then .xxxxxxx03 and .xxxxxxx05. You need the latest one to apply codes.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on September 05, 2013, 12:29:14 pm
Rigol 3in1 Keygen (includes DP832)

http://pastebin.com/t75UYN3g (http://pastebin.com/t75UYN3g)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on September 05, 2013, 01:01:10 pm
Rigol 3in1 Keygen (includes DP832)

http://pastebin.com/t75UYN3g (http://pastebin.com/t75UYN3g)

 :-+ (and also for DS1000z btw ;-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: BravoV on September 05, 2013, 01:29:30 pm
No doubt, this thread is now standing among legendary discussion threads at this forum, huge props to all contributors.  :clap:

PS : I guess its time to refresh the "offline" version again.  ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on September 05, 2013, 01:50:29 pm
Rigol 3in1 Keygen (includes DP832)

http://pastebin.com/t75UYN3g (http://pastebin.com/t75UYN3g)

 :-+ (and also for DS1000z btw ;-)
Update for DS1000z support. :D
Now we have:
- DS1000z
- DS2000
- DS4000
- DSA815
- DP832

http://pastebin.com/ifTEf2pq (http://pastebin.com/ifTEf2pq)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on September 05, 2013, 03:32:47 pm
Rigol 3in1 Keygen (includes DP832)

http://pastebin.com/t75UYN3g (http://pastebin.com/t75UYN3g)

 :-+ (and also for DS1000z btw ;-)
Update for DS1000z support. :D
Now we have:
- DS1000z
- DS2000
- DS4000
- DSA815
- DP832

http://pastebin.com/ifTEf2pq (http://pastebin.com/ifTEf2pq)

neat now prepare for your inbox to explode  :-DD
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: nack on September 05, 2013, 03:34:51 pm
Amazing stuff by you guys!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on September 05, 2013, 04:02:10 pm
Rigol 3in1 Keygen (includes DP832)

http://pastebin.com/t75UYN3g (http://pastebin.com/t75UYN3g)

 :-+ (and also for DS1000z btw ;-)
Update for DS1000z support. :D
Now we have:
- DS1000z
- DS2000
- DS4000
- DSA815
- DP832

http://pastebin.com/ifTEf2pq (http://pastebin.com/ifTEf2pq)

neat now prepare for your inbox to explode  :-DD

I have created a Windows executable with MinGW.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: lemon on September 05, 2013, 04:15:55 pm
Many thanks for this help.  :-+
It isn't running with XP(32bit). Just I run it, it opens and close immediately!
Any feedback from other member on Win platform?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: TopLoser on September 05, 2013, 04:23:51 pm
Many thanks for this help.  :-+
It isn't running with XP(32bit). Just I run it, it opens and close immediately!
Any feedback from other member on Win platform?
Run it in a DOS window
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: TopLoser on September 05, 2013, 04:41:32 pm
Quote
I have created a Windows executable with MinGW.

Worked perfectly - my DP832 is now all 'Official'

Brilliant, well done  :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: lemon on September 05, 2013, 05:11:18 pm
You had right, with MS-DOS, everything is OK!
Many thanks to all of you  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: stormbr on September 05, 2013, 06:05:01 pm
My dp832 timebomb edition have firmware bellow:

00.01.03

s/n: DP8C1512002xx

Can i update with this old firmware ?

or is better update to 00.01.06 ?

Thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on September 05, 2013, 06:19:18 pm
I've got that same "timebomb" edition, haha. What are the differences between firmware 1.03, and 1.06?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: nack on September 05, 2013, 07:05:01 pm
Mine came with 1.04. Where did you get the newer versions?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: stormbr on September 05, 2013, 07:27:20 pm
http://www.rigolna.com/products/dc-power-supplies/dp800/dp832/ (http://www.rigolna.com/products/dc-power-supplies/dp800/dp832/)

For update the dp832 need send a request form to rigol.

Or pay for increase more licenses.

DP832 License Activation InstructionsThe DP832 Power Supply has a number of upgrades that can be purchased optionally. This document covers how to activate the licenses.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Sparky on September 05, 2013, 07:35:59 pm
My dp832 timebomb edition have firmware bellow:

00.01.03

s/n: DP8C1512002xx

Can i update with this old firmware ?

or is better update to 00.01.06 ?

Thanks

Where did you see this "00.01.06" firmware version for DP832 series?   :-//  The DP832 is not currently listed on Rigol's "Latest firmware page" (see below) and I haven't seen anyone mention Rigol releasing a firmware update for the DP832 yet.

Edit: Nevermind, now I see it mentioned here (https://www.eevblog.com/forum/blog/eevblog-512-rigol-dp832-bad-design-investigation/msg287095/#msg287095).

Hopefully Rigol will make this updated firmware available!


Here are the latest Firmware versions by Rigol product family as of July 31, 2013:

DS2000 FW-Version: 00.01.01
DS4000 FW-Version: 00.02.00
DS6000 FW-Version: 00.01.04
DSA815 FW-Version: 00.01.07
DSA1000 FW-Version: 00.01.16
DG4000 FW-Version: 00.01.06
DG5000 FW-Version: 01.01.08

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: riconette on September 05, 2013, 07:40:23 pm
virtual hugs to all contributors :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on September 05, 2013, 08:35:32 pm
The password for the DP832 "ManualCal" menu is "2012".
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: stormbr on September 05, 2013, 09:29:34 pm
dp832 unlocked.

Thanks Cybernet, Studio25 and all peoples that participated.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Uup on September 05, 2013, 11:32:35 pm
Update for DS1000z support. :D
Now we have:
- DS1000z
- DS2000
- DS4000
- DSA815
- DP832

http://pastebin.com/ifTEf2pq (http://pastebin.com/ifTEf2pq)

Great work studio25!

I like how you provided info for all the supported models. However, the information on the DS4000 series could be improved. See post 713 on page 48 of this thread.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: warp_foo on September 06, 2013, 02:17:40 am
Rigol 3in1 Keygen (includes DP832)

http://pastebin.com/t75UYN3g (http://pastebin.com/t75UYN3g)

 :-+ (and also for DS1000z btw ;-)
Update for DS1000z support. :D
Now we have:
- DS1000z
- DS2000
- DS4000
- DSA815
- DP832

http://pastebin.com/ifTEf2pq (http://pastebin.com/ifTEf2pq)

DS2072
SN DS2A1523012xx
Software 00.01.01

Works perfectly, thanks!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: leafi on September 06, 2013, 02:23:22 am
Does the DS4000 support SW BW upgrades? Last I read it was options for decode and such.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: iloveelectronics on September 06, 2013, 02:45:49 am
WOW! Thanks to all that contributed, especially Cybernet and Studio25 of course! The DOS version works like a charm on my DS1104Z!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: H.O on September 06, 2013, 06:01:18 am
Quote
Does the DS4000 support SW BW upgrades? Last I read it was options for decode and such.
One forum member had his DS4000 magically"revert" to a 500MHz model after some fast power on/off cycle or something (lost the serial number as well IIRC) so it looks like the bandwidth option is indeed in lurking in there somewhere.

To my knowlege the current keygen does not provide means to unlock it though. I'm keeping my fingers crossed that the brilliant people giving us thís will figure out the BW limit of the DS4000 series as well.

Thanks again by the way!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jsykes on September 06, 2013, 07:53:33 am
dp832 unlocked.

Thanks Cybernet, Studio25 and all peoples that participated.

 
Does unlocking the DP832 enable the multicolor and more intuitive GUI that the 832A has? I think Dave mentioned in his video that the TFT hardware is the same.

 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Sparky on September 06, 2013, 08:08:01 am
Does unlocking the DP832 enable the multicolor and more intuitive GUI that the 832A has? I think Dave mentioned in his video that the TFT hardware is the same.

Short answer: NO.  This and many similar questions have already been answered in this thread (https://www.eevblog.com/forum/testgear/new-rigol-dc-psu's/).

As for "more intuitive GUI that the 832A has" -- that is seriously a matter of personal opinion!  I think the 832 is more intuitive with the vertical panels, which match the sequence of Ch1, Ch2, Ch3 on/off buttons.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jsykes on September 06, 2013, 03:38:11 pm
Does unlocking the DP832 enable the multicolor and more intuitive GUI that the 832A has? I think Dave mentioned in his video that the TFT hardware is the same.

Short answer: NO.  This and many similar questions have already been answered in this thread (https://www.eevblog.com/forum/testgear/new-rigol-dc-psu's/).

As for "more intuitive GUI that the 832A has" -- that is seriously a matter of personal opinion!  I think the 832 is more intuitive with the vertical panels, which match the sequence of Ch1, Ch2, Ch3 on/off buttons.

 
Thanks for the link to the other thread...I missed that one.
I agree. The panels make more sense to me. "Intuitive" was their description. Personally, I think that circular arrangement for the keyboard was ugly enough but to mimic it on the screen just adds insult to injury  :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: etc6849 on September 06, 2013, 04:25:59 pm
Awesome work guys!  I just received my DP832.  I'm glad I cancelled the DP832a order now :)

Is there a summary anywhere on the firmware differences for the DP832?  I'm curious how critical it is for me to update (any major bugs?) and if I should do this before applying the hack, etc...

I'm going to guess that the hack will work on any DP832 firmware, but I haven't tried it yet.

EDIT: 
My DP832 has firmware 00.01.04, even though it arrived from tequipment.net this week (after being on back order for while). 

Apparently it's not the newest firmware, but the hack installed just fine.  No need to hunt for the private key.  I used the dos program rigol.exe further up that studio25 compiled for us (thanks :) ), and it has the private key already. 

Looks so much better than the circular triangle display the DP832A has (which is why I cancelled that one and ordered this one).  I typed the keys in manually then toggled power on the DP832 to see the more accurate voltage and current display. 

My board is also the same version as Dave's (rev 2), so it has the same design flaw discussed in the Rigol DC power supply thread.  However, this hack makes up for the design flaw that I'll have to fix at some point down the road.  It's really thanks to you folks that I might buy another piece of Rigol gear in the future.  After the design flaw, I was kind of turned off by it, but all in all, I'm happy with the DP832.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: leafi on September 06, 2013, 10:59:03 pm
I hope you guys do the DG4000 soon! hint hint! ;D

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on September 06, 2013, 11:00:01 pm
I hope you guys do the DG4000 soon! hint hint! ;D

hint hint, read the thread ...  |O
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: leafi on September 07, 2013, 12:56:49 am
Ive read the thread and the DG400 firmware investigation thread. The only thing I see you mentioning (Cybernet) is you can use a Jtag. (which right now I do not have..granted I do not have a DG4000 yet)

Can this be done without opening the case? BTW thank you for your effort on doing this.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: etc6849 on September 07, 2013, 03:41:57 am
How to undue the DP832 hack?  I really should have found the thread below before hacking the thing.  I measured mine LM317's heat sink and it was 200*F+ with the cover on?!?

I tried generating a trial code, but no luck and now I hear they are recalling the POS.  :palm:

https://www.eevblog.com/forum/blog/eevblog-512-rigol-dp832-bad-design-investigation/360/ (https://www.eevblog.com/forum/blog/eevblog-512-rigol-dp832-bad-design-investigation/360/)

PS:  On the bright side "Official" is spelled correctly  :clap:  How about that!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ilya on September 09, 2013, 12:34:11 pm
Has anybody been able to revert DS2202 (made from 2072) back to 2072? What were the exact steps to make this happen?

I'm unable to take my scope back to 2072 state. And it shows both 100MHz and 200MHz options in options list which is not that bad, but obviously not intended and annoying.

So far, I tried uninstalling all options, downgrading to the earliest firmware and uninstalling options from there, entering DSAA key (under all firmwares). Still no luck  :-\
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: darrylp on September 09, 2013, 12:58:57 pm
Yes, steps listed here in this thread worked fine when i tried it.

--
 Darryl

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Wim13 on September 09, 2013, 02:00:26 pm
Has anybody been able to revert DS2202 (made from 2072) back to 2072? What were the exact steps to make this happen?

I'm unable to take my scope back to 2072 state. And it shows both 100MHz and 200MHz options in options list which is not that bad, but obviously not intended and annoying.

So far, I tried uninstalling all options, downgrading to the earliest firmware and uninstalling options from there, entering DSAA key (under all firmwares). Still no luck  :-\

Well by not reading this thread, you did everything wrong that you can do wrong...

DSAA is a do nothing key, so nothing happens, that is correct.

Only use the lates FW because not all keys can be used in all FW versions,
for uninstall use SCPI command uninstall.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on September 09, 2013, 02:44:41 pm
Has anybody been able to revert DS2202 (made from 2072) back to 2072? What were the exact steps to make this happen?

I'm unable to take my scope back to 2072 state. And it shows both 100MHz and 200MHz options in options list which is not that bad, but obviously not intended and annoying.

So far, I tried uninstalling all options, downgrading to the earliest firmware and uninstalling options from there, entering DSAA key (under all firmwares). Still no luck  :-\

First of all, down-grading to the oldest firmware is a bad idea, you might loose your serial number of the scope by simply playing with keys.

Secondly you need to use the latest firmware if you submit keys to the scope, this is 01.01.02

Here is a small Python program that uninstalls keys, it run on Python 2.7 (not 3.0)
Code: [Select]
import vxi11, sys, time
print("Connecting...")
rigol = vxi11.Instrument("10.0.0.80")
print("Model number before patch:")
print(rigol.ask("*IDN?"))
print("Getting current set-up...")
config = rigol.ask_raw(":SYSTem:SETup?")
time.sleep(3)

#print("Writing license key... " + LICENSE)
#rigol.write(":SYSTem:OPTion:INSTall " + LICENSE)

rigol.write(":SYSTem:OPTion:UNINSTall")

time.sleep(5)
print("Restoring set-up")
rigol.write_raw(":SYST:SET " + config)
print("Model number after patch:")
print(rigol.ask("*IDN?"))
time.sleep(5)
sys.exit(0)



Oh forgot to mention, if you use DSAZ, the scope only shows the 200 MHz option
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ilya on September 09, 2013, 03:40:43 pm
Well by not reading this thread, you did everything wrong that you can do wrong...

DSAA is a do nothing key, so nothing happens, that is correct.

Only use the lates FW because not all keys can be used in all FW versions,
for uninstall use SCPI command uninstall.

Maybe I wasn't clear enough. Yes, I HAVE read the whole thread. No, I haven't applied any keys with the earliest software - I've downgraded AFTER I've applied the keys and uninstalled them.

I've made all uninstallations with SCPI command.

Regarding DSAA, I thought that if DSAR updates the model to 2102 and DSAZ to 2202 then DSAA might revert it back to 2072. No dice.

Orange, your Python script is essentialy the same thing as SCPI command.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Maalobs on September 09, 2013, 04:04:37 pm
Has anybody been able to revert DS2202 (made from 2072) back to 2072? What were the exact steps to make this happen?

I'm unable to take my scope back to 2072 state. And it shows both 100MHz and 200MHz options in options list which is not that bad, but obviously not intended and annoying.

So far, I tried uninstalling all options, downgrading to the earliest firmware and uninstalling options from there, entering DSAA key (under all firmwares). Still no luck  :-\
Following this post didn't help you?
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg273558/#msg273558 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg273558/#msg273558)

I had the same situation as you, and wanted the 100M option gone as well.
The trick with SCPI-commands, was to remove the pre-entered prompt first.
The post directly following mine in the above link, suggests that I might have mistakenly added an extra ':' into my description, maybe I did, I dunno.
Try it out and report back with what worked, I'll edit my post accordingly. :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: etc6849 on September 09, 2013, 10:14:55 pm
Any hints on how to uninstall the hacked DP832 options?

I tried using the following from Ultra Sigma under Windows 7 64-bit:

:SYSTem:OPTion:INSTall XXXXXXXXXXXXXXXXXXXXXXXXXXX
:SYSTem:OPTion:UNINSTall

where XXXXXXXXXXXXXXXXXXXXXXXXXXX is the license code without the dashes.

Also tried it without the first colon.  Nothing seemed to work...

The programming guide for the DP800 doesn't seem to list any commands for options (unlike the guide for the DS2000 series).  Maybe I'm SOL on clearing the options before sending the unit it?  Are the codes really unique to where Rigol will not know I hacked the power supply?

How to undue the DP832 hack?  I really should have found the thread below before hacking the thing.  I measured mine LM317's heat sink and it was 200*F+ with the cover on?!?

I tried generating a trial code, but no luck and now I hear they are recalling the POS.  :palm:

https://www.eevblog.com/forum/blog/eevblog-512-rigol-dp832-bad-design-investigation/360/ (https://www.eevblog.com/forum/blog/eevblog-512-rigol-dp832-bad-design-investigation/360/)

PS:  On the bright side "Official" is spelled correctly  :clap:  How about that!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on September 11, 2013, 06:35:18 pm
Quote
It's Official!!!!

Nope, it's Offical!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: flolic on September 11, 2013, 06:37:25 pm
Quote
It's Official!!!!

Nope, it's Offical!

Offcial, to be exact!  :D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rory on September 11, 2013, 07:03:21 pm
Cybernet is the MAN :-+ :-+ :-+

VSWR Enabled!!!

AMK Enabled !!!!

[It's Official!!!!

And it sticks after power cycling.
Marc, please what FW version you have in DSA-815TG??
Kristian

I'd be really cautious about installing the lkeys while the DSA815-TG is under warranty until someone figures out a way to remove them. My 815 quit responding properly to keyboard input and it's on its way to Rigol for repair.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on September 11, 2013, 07:32:44 pm
Warranty from my dealer is 3 years, that means 3 years without 10Hz RBW.

Installing and uninstall via the SCPI commands did not work for me, true. Still you're not hacking the analyser, you simply enter a key, which the analyser accepts, is that not allowed ?  :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Marc M. on September 11, 2013, 09:09:15 pm
Marc, please what FW version you have in DSA-815TG??
I can't remember if/how to get the extended info.  Here's what the  System Info screen displays:

S/N:  DSA8A14490xxxx

Main Board: 00.04
RF Board: 00.04
Digital Board FPGA: 00.04
Firmware: 00.01.05
Boot: 00.01.02

Hope that helps!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jsykes on September 12, 2013, 01:48:21 am
Cybernet is the MAN :-+ :-+ :-+
 
 

VSWR Enabled!!!
 
 

AMK Enabled !!!!
 
 

[It's Official!!!!

And it sticks after power cycling.
Marc, please what FW version you have in DSA-815TG??
Kristian

I'd be really cautious about installing the lkeys while the DSA815-TG is under warranty until someone figures out a way to remove them. My 815 quit responding properly to keyboard input and it's on its way to Rigol for repair.

 
I am considering applying the hack to my DSA815-TG. For those who have done it, has anyone experienced ANY problems related to the hack?  :scared:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Marc M. on September 12, 2013, 04:18:00 am
I am considering applying the hack to my DSA815-TG. For those who have done it, has anyone experienced ANY problems related to the hack?  :scared:
So far the only negative aspect is the inability to remove the keys once installed and how that may affect potential warranty issues.  We will see what Rigol's response to Rory's warranty claim with the unofficial keys installed in this unit. 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rory on September 12, 2013, 03:46:35 pm
RORY....did DSA stop respond in selfcalibrating??
mine was freezing  and stop responding in selfcalibrating but only when enviroment temp was over 32 deg C.
under 32 deg C was perfect...go figure!
it's under warranty and I will post results here when DSA comes back from rigol EU.
Kristian

Kristian - I did not investigate self-calibration. The problem is present at all times, but could it be triggered by self-cal? I do not know.  Room temp 24C and problem occurs right away before unit warms up. 
Rory
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: fqahmad66 on September 13, 2013, 04:12:14 am
It looks like a bad BGA solder..
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Ericho on September 13, 2013, 02:35:09 pm
Woww,

I had some time yesterday and read the hole tread,

My hat off to all participants, this is way out of my leage but non the less very interesting  :-+

Respect  :-+

Next month I will be able to order my ds2072 and my owon is due for a ritual burning in the garden.
 
Kind regards,
Eric
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rory on September 13, 2013, 05:58:06 pm
It looks like a bad BGA solder..
yes thats I am aware of... :(

Rory.....did you see the problem before entering keys for options or after that?
K

Afterward. It failed about 3 weeks after lkeys installed.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: auato on September 13, 2013, 07:19:31 pm
Afterward. It failed about 3 weeks after lkeys installed.
Damn! Rory, what do you think to do now?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: eurofox on September 13, 2013, 07:32:07 pm
Afterward. It failed about 3 weeks after lkeys installed.
Damn! Rory, what do you think to do now?

You guy's really think that service people at Rigol will check if you legally got those key or not?  :-DD

eurofox
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: auato on September 13, 2013, 07:36:59 pm
Afterward. It failed about 3 weeks after lkeys installed.
Damn! Rory, what do you think to do now?

You guy's really think that service people at Rigol will check if you legally got those key or not?  :-DD

eurofox

Yep, I think Rigol's guys will not look into the keys.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rory on September 14, 2013, 05:01:05 am
Afterward. It failed about 3 weeks after lkeys installed.
Damn! Rory, what do you think to do now?

I will wait and see what Rigol does.  They should have it by Tuesday.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Wim13 on September 14, 2013, 10:19:56 am


In the FW ( DS2000 and DG4000) and there are named two TCP-IP ports, 5555 and 5566
Did a port scan and the ports indeed gave an ack. But could not start a comm.
Yet, no idea where they use it for.

Ultra Sigma uses tcp-ip port 4097, for the DS2000 and Sun-rpc port 111,  for the DG4000.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: commongrounder on September 14, 2013, 05:59:45 pm
Wim13:  When I spoke with Rigol NA about the details of the firmware upgrade to my DS4000 series scope, they mentioned that the ver 2.00 firmware has "unlocked"  some ports so that other, non-proprietary, software could access it (no NI drivers?).  I am not at all familiar with this aspect of the network connections to the scope, so I will leave this to others to sort out.  But it sounds like they are loosening up things a bit to allow more flexible machine control.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Wall-E on September 16, 2013, 08:44:58 pm
Rigol has announced that there is very soon going to to be a DS2000A series available that will also include a DS2302A 300 MHz Bandwidth unit.
Re. http://www.rigol.com/prodserv/DS2000A/ (http://www.rigol.com/prodserv/DS2000A/)

There is also going to be a (Vector) Signal Generator DSG3000 Series. This looks like it will be expensive (?) but very nice.
Re. http://www.rigol.com/prodserv/DSG3000/ (http://www.rigol.com/prodserv/DSG3000/)

   Cheers . . .

 

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JDubU on September 16, 2013, 10:24:37 pm
Any chance that
HW version 1 = DS2000
HW version 2 = DS2000A

If so, I wonder if there is a software option that takes HW version 2 up to 300Mhz and 1ns/div?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on September 16, 2013, 10:33:46 pm
Rigol has announced that there is very soon going to to be a DS2000A series available that will also include a DS2302A 300 MHz Bandwidth unit.
Re. http://www.rigol.com/prodserv/DS2000A/ (http://www.rigol.com/prodserv/DS2000A/)

https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg260433/#msg260433 (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg260433/#msg260433)

I am not surprised, just changing a transistor (MMBTH10L by MMBTH10-4L) and done. So easy.
Not need to change the FET, the DS4000 series uses the same and achieves 500MHz.
Since the N-FET work in no gain mode (0dB, only follower) it can go probably until 1GHz.



But where did you read that? For http://www.rigol.com/prodserv/DS2000A/ (http://www.rigol.com/prodserv/DS2000A/)  I get this (see atached image):
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: flolic on September 16, 2013, 11:06:21 pm
http://cn.rigol.com/prodserv/DS2000A/ (http://cn.rigol.com/prodserv/DS2000A/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on September 16, 2013, 11:10:40 pm
http://cn.rigol.com/prodserv/DS2000A/ (http://cn.rigol.com/prodserv/DS2000A/)

OK, now I see.  :-+
Thanks.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Clint on September 17, 2013, 07:07:51 am
300MHz    2    2GSa/s    14Mpts (??) ?56Mpts (??)    50,000 wfms/s    19?800



Right you lazy lot where is my key :)

Only joking, but would be great if this is the same hardware as the rest of the 'A's !
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 1design on September 18, 2013, 06:42:50 am
Is there any chance the DSA1030 will get hacked? With a tracking generation option installed all the others are just SW activated :)

Best Regards!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: elecBlu on September 18, 2013, 06:52:27 pm
Maybe I wasn't clear enough. Yes, I HAVE read the whole thread. No, I haven't applied any keys with the earliest software - I've downgraded AFTER I've applied the keys and uninstalled them.
I've made all uninstallations with SCPI command.
Regarding DSAA, I thought that if DSAR updates the model to 2102 and DSAZ to 2202 then DSAA might revert it back to 2072. No dice.

any news about the problem with uninstall the keys on DS2000 Scope?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on September 19, 2013, 04:47:22 pm
Is there any chance the DSA1030 will get hacked? With a tracking generation option installed all the others are just SW activated :)

Best Regards!

as soon as somebody comes up with a memory dump or a firmware file might also work.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on September 19, 2013, 05:04:58 pm
Cybernet, I do not know if you already know about this, from rigol-new-instruments-coming-soon:
Quote
Comparing data sheets (DS2000A from Rigol's Chinese web site), the only differences that I can see are:

1)  Added model DS2302A with 300MHz BW and 1ns/div horizontal.
2)  Switchable 50 ohm input termination
3)  Optional CAN bus trigger and decode

Another new option to add, CAN bus.  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ilya on September 19, 2013, 06:37:31 pm
any news about the problem with uninstall the keys on DS2000 Scope?

Well, here's the news.
The :SYSTEM:OPTIONS:UNINSTALL string didn't change the scope model, but did removed all licenses ("All licenses deleted"). The :SYStem OPTions:UNINSTall did the same thing but put the trials instead.

However, there was a very strange bug with my scope that did revert it to DS2072 with SN 0000000001. I did the following: connected the scope to the USB port and powered the scope on. It froze during boot-up on the "Rigol" screen. I turned it off and unplugged it from USB. Turned on again - booted fine. Connected the USB and ran the ScopeCommander with :SYSTEM:OPTIONS:UNINSTALL string. After looking at the program output I noticed that the scope was recognized as DS2072 (instead of DS2202) and the serial was 0000000001.

I've generated new licenses for 2202 and installed them. I wasn't able to revert my scope to DS2072 after that.

I'm really stuck. Hope sometimes it would be possible to change the SN...  |O
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: elecBlu on September 19, 2013, 08:27:35 pm
thanks for your reply. Sad to hear you have the problem with the serial number  :(
One thing i notice is that you did the fw-downgrade during your uninstall attempts. Maybe this is the reason, but who knows.

So there is still no approved way for uninstalling all this keygen-enabled software options including reset the scope model for the case of e.g. warranty? A lot of people tell the :SYSTEM:OPTIONS:UNINSTALL would do but i doubt?




Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Marc M. on September 19, 2013, 09:46:36 pm
... there is still no approved way for uninstalling all this keygen-enabled software options including reset the scope model for the case of e.g. warranty? A lot of people tell the :SYSTEM:OPTIONS:UNINSTALL would do but i doubt?
For the vast majority of users, the uninstall works fine.  I've uninstalled/reinstalled options at least a dozen times with no issues.  It reverts back to a 2072 and all options disappear every time I've performed it (via Ethernet and Python scripts).  It still hasn't been determined what the exact process is that caused a few users to have s/n's reset and/or unable to change the model back to a 2072.  It may be connected to older firmware so it's recommended to update to the latest version prior to installing any keys.  Keep in mind that currently there are no known uninstall options for either the DG4000 func. gens., the DSA815 spectrum analyzers or the DP800 series power supplies.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 1design on September 20, 2013, 05:45:15 am
Is there any chance the DSA1030 will get hacked? With a tracking generation option installed all the others are just SW activated :)

Best Regards!

as soon as somebody comes up with a memory dump or a firmware file might also work.

I will try to arrange that, I guess the .GEL is easier to get without loosing the warranty :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on September 21, 2013, 04:20:10 am
any news about the problem with uninstall the keys on DS2000 Scope?

Well, here's the news.
The :SYSTEM:OPTIONS:UNINSTALL string didn't change the scope model, but did removed all licenses ("All licenses deleted"). The :SYStem OPTions:UNINSTall did the same thing but put the trials instead.

However, there was a very strange bug with my scope that did revert it to DS2072 with SN 0000000001. I did the following: connected the scope to the USB port and powered the scope on. It froze during boot-up on the "Rigol" screen. I turned it off and unplugged it from USB. Turned on again - booted fine. Connected the USB and ran the ScopeCommander with :SYSTEM:OPTIONS:UNINSTALL string. After looking at the program output I noticed that the scope was recognized as DS2072 (instead of DS2202) and the serial was 0000000001.

I've generated new licenses for 2202 and installed them. I wasn't able to revert my scope to DS2072 after that.

I'm really stuck. Hope sometimes it would be possible to change the SN...  |O

Once someone uses JTAG to dump the machine and post it here I'll take a look at it to see what can be done. Nobody has done this yet.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Circlotron on September 22, 2013, 12:25:44 pm
I have created a Windows executable with MinGW.
In the options matrix J-R is for 100MHz, S-Z is for 200MHz but 2-9 is for both 100 AND 200MHz.
What is the difference between choosing 200MHz and choosing 100 and 200MHz?

Getting a 2072 in early October.
Woo!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ilya on September 22, 2013, 12:45:04 pm
I have created a Windows executable with MinGW.
In the options matrix J-R is for 100MHz, S-Z is for 200MHz but 2-9 is for both 100 AND 200MHz.
What is the difference between choosing 200MHz and choosing 100 and 200MHz?

Getting a 2072 in early October.
Woo!

100 MHz makes 2102, 200 MHz makes 2202 from 2072. 2-9 activates both options and shows them in the "installed options" screen - not recommended.

Once someone uses JTAG to dump the machine and post it here I'll take a look at it to see what can be done. Nobody has done this yet.

Unfortunately I have neither equipment, nor expertise to make a JTAG dump. Where can I find more info on that subject?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Circlotron on September 22, 2013, 12:59:04 pm
Cool. Thanks ilya.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on September 22, 2013, 05:42:07 pm
Once someone uses JTAG to dump the machine and post it here I'll take a look at it to see what can be done. Nobody has done this yet.

You can buy a cheap jtag here:
http://www.seeedstudio.com/depot/bus-blaster-v3-p-1415.html (http://www.seeedstudio.com/depot/bus-blaster-v3-p-1415.html)
http://www.seeedstudio.com/depot/bus-blaster-v4-p-1416.html (http://www.seeedstudio.com/depot/bus-blaster-v4-p-1416.html)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Krakonos on September 25, 2013, 09:09:12 am
Hi, I've found a bug in your code, here is the patch: http://pastebin.com/92CjSqJv (http://pastebin.com/92CjSqJv)

(Your code ate up first character, since my compiler (reasonably new gcc) optimized a bit and increased p before read. You can't rely on such constructs, beside bad practice I think it violates the C standard and the result is undefined, in your case, different :-))

Anyway, thanks for the keygen, I'll try it soon!

Update for DS1000z support. :D
Now we have:
- DS1000z
- DS2000
- DS4000
- DSA815
- DP832

http://pastebin.com/ifTEf2pq (http://pastebin.com/ifTEf2pq)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bigmessowires on September 30, 2013, 03:42:42 pm
Can anyone confirm what features can be unlocked on the DS1000Z series? I see a note saying the keygen works on those scopes, but no posts from actual DS1000Z owners confirming it or providing details.

Is it only a bandwidth unlock?
Can it unlock the serial decoding, advanced triggers, waveform record/playback, and additional sample memory?

Thanks!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on September 30, 2013, 06:56:44 pm
My understanding so far is:

Is it only a bandwidth unlock?

No.  It would be nice if someone could see how the bandwidth works in the 1000Z - does it have a similar amplifier chip were you can select the bandwidth...

Can it unlock the serial decoding, advanced triggers, waveform record/playback, and additional sample memory?

Yes, Yes, Yes, Yes.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Circlotron on October 02, 2013, 03:13:42 pm
Getting a 2072 in early October.
Woo!
Got it today.
Spent 4 hours and fixed an absolute show-stopper production problem. Everybody is happy. New scope very justified.  :)
Now, do I dare "update" it???  :-BROKE
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on October 02, 2013, 06:44:57 pm
Spent 4 hours and fixed an absolute show-stopper production problem. Everybody is happy. New scope very justified.  :)

Wait, you fixed a show-stopper with the scope or you used the scope to fix a show-stopper somewhere else?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Circlotron on October 02, 2013, 11:29:56 pm
I used the new scope to look at fleeting pulses that happened on many but not all boards at the moment of power up.
Turned out to be previous batch of 1N4148 diodes had enough reverse leakage to mask the problem of 100nA coming out of interrupt pin of micro and charging 10nF cap enough to trigger micro. New batch of diodes were "better" so problem occurred. Cure was to place 4M7 across diode to ground.

Now, back to thread subject.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rory on October 03, 2013, 05:13:08 pm
Got the DSA815-TG back from Rigol, no mention of extra options enabled.  Tech couldn't make the keyboard fail after 2 weeks on the bench...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: auato on October 03, 2013, 09:21:32 pm
Got the DSA815-TG back from Rigol, no mention of extra options enabled.  Tech couldn't make the keyboard fail after 2 weeks on the bench...

@Rory, but did they repair your trouble?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rory on October 03, 2013, 09:34:21 pm
Got the DSA815-TG back from Rigol, no mention of extra options enabled.  Tech couldn't make the keyboard fail after 2 weeks on the bench...

@Rory, but did they repair your trouble?

auato, the direct answer is 'no'. See my separate thread for details.  In this thread, the important point is that they didn't make a deal out of, or possibly even notice the unofficially generated 'offical' option codes.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: auato on October 03, 2013, 10:04:23 pm

auato, the direct answer is 'no'. See my separate thread for details.  In this thread, the important point is that they didn't make a deal out of, or possibly even notice the unofficially generated 'offical' option codes.

Thanks Rory, I have seen your other thread. Now I'll follow the other one too
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on October 06, 2013, 08:15:13 pm
I wish someone would try to look at the bandwidth on the DS1000Z series.  I am interested in getting one, but the decision may rest on whether it can be unlocked from 70 to 100 MHz.  One thing of interest is that of the 4 digit code like DSAZ that the 3rd digit can be used to enable the 500uV mode.  This is an undocumented feature that isn't listed in the license menu.  It makes me wonder if there could be other unlicensed features on other models or a bandwidth feature on the 1000Z model lurking there in other 3rd digit bits...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on October 06, 2013, 09:29:15 pm
Here is an updated Rigol Keygenerator for:
- DS1000Z
- DS2000
- DS4000
- DSA815
- DP832

Also new is a browser version.
Perhaps there is someone who hosts the web version :-)
Corrections are always welcome.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: iceisfun on October 06, 2013, 11:14:27 pm
On the web version, why put the generated key in a alert dialog?

Its better to put it someplace that it can be copied from
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigol-Friend on October 07, 2013, 08:08:40 am
Where is the problem?
Make a sceenshot and store it as JPG for example.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on October 07, 2013, 06:02:36 pm
On the web version, why put the generated key in a alert dialog?

Its better to put it someplace that it can be copied from

Changed as desired.
Someone recommend a good web host?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: lemon on October 07, 2013, 06:58:36 pm
Here is an updated Rigol Keygenerator for:
- DS1000Z
- DS2000
- DS4000
- DSA815
- DP832

Also new is a browser version.
Perhaps there is someone who hosts the web version :-)
Corrections are always welcome.

Many thanks for this support.
What is the changes for DP832 from the previous of https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg287132/#msg287132 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg287132/#msg287132) ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on October 07, 2013, 08:15:10 pm
Here is an updated Rigol Keygenerator for:
- DS1000Z
- DS2000
- DS4000
- DSA815
- DP832

Also new is a browser version.
Perhaps there is someone who hosts the web version :-)
Corrections are always welcome.
Many thanks for this support.
What is the changes for DP832 from the previous of https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg287132/#msg287132 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg287132/#msg287132) ?
Mainly minor bug fixes and cleanup work.
Really new is the web version and the simplified structure.
Basically the same license keys should be generated.
Please only use the files from post #1171.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Circlotron on October 07, 2013, 11:59:46 pm
Changed as desired.
Maybe every time you update it you could make the revision number part of the file name so that sillies like me don't use an old version.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: techydude on October 08, 2013, 05:44:53 am
Is there a TL;DR summary of this mammoth thread? ;)
I started reading form the beginning, but lost the will to live at about page 20...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: darrylp on October 08, 2013, 08:16:04 am
For the pearls of wisdom, and the potential to get a free key for certain bits of hardware from rigol, people can't be bothered to read the whole thread. Strange I find that.

--
 Darryl

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: lemon on October 08, 2013, 08:19:02 am
Here is an updated Rigol Keygenerator for:
- DS1000Z
- DS2000
- DS4000
- DSA815
- DP832

Also new is a browser version.
Perhaps there is someone who hosts the web version :-)
Corrections are always welcome.
Many thanks for this support.
What is the changes for DP832 from the previous of https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg287132/#msg287132 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg287132/#msg287132) ?
Mainly minor bug fixes and cleanup work.
Really new is the web version and the simplified structure.
Basically the same license keys should be generated.
Please only use the files from post #1171.

Many thanks for this quickly respond.
Two questions more:
1) Can I repeat the procedure with the new update, I think there is no any limit to enter the keys.
2) Is there a possibility now, to back up to the original Rigol configuration?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: techydude on October 08, 2013, 12:22:06 pm
For the pearls of wisdom, and the potential to get a free key for certain bits of hardware from rigol, people can't be bothered to read the whole thread. Strange I find that.

Do you insist everyone read the novel before you allow them to see the movie, too, oh great Gatekeeper?
Title: Re: Re: Sniffing the Rigol's internal I2C bus
Post by: darrylp on October 08, 2013, 12:46:10 pm
For the pearls of wisdom, and the potential to get a free key for certain bits of hardware from rigol, people can't be bothered to read the whole thread. Strange I find that.

Do you insist everyone read the novel before you allow them to see the movie, too, oh great Gatekeeper?


Ahh, movies and novels. :-)

I see two generalised types of people reading or following this thread.
1.) Those just interested as a whole of I2c bus protocols, this type I imagine would read each page in detail and then after 20 or so pages have decided to keep reading due to the tech level shown up to that point. Either its still interesting to them or not.
2.) The second type those with a curious interest from seeing rigol  in the title, who after a couple of pages see that maybe free keys ( ie. Unlock features they most likely they haven't paid for ) might be on offer. This type of person in my opinion can have the information and knowledge, and to ensure their hardware doesn't get messed up. Ie. The serial number being zapped on certain DS2xx2 scopes being prime. But as as saying I heard long ago, nothing is ever free, I see the payment you make or should make in my opinion is you read the whole thread. Doing so, you will be for armed with the pitfalls of applying some of the keys to certain rigol supported hardware that can be relieved of locked down features.

The others, can back read the last page or two and decide to maybe use the key gen, and wing it and see what happens on their rigol hardware if they have any. I think that's a suitable novel to movie to adaption that Hollywood often makes.

--
 Darryl

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on October 08, 2013, 02:03:48 pm
For the pearls of wisdom, and the potential to get a free key for certain bits of hardware from rigol, people can't be bothered to read the whole thread. Strange I find that.

Do you insist everyone read the novel before you allow them to see the movie, too, oh great Gatekeeper?

Hey Dude  :)

If you have a DS2000 scope, I would certainly read the whole thread. Yes I know it requires some time, but is worth the time. There is valuable info in this that might you prevent from screwing your scope. (that is loosing your serial number)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndreaEl on October 08, 2013, 03:31:56 pm
On the web version, why put the generated key in a alert dialog?

Its better to put it someplace that it can be copied from

Changed as desired.
Someone recommend a good web host?

You can see about 000webhost
Not a bad service for free
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Teneyes on October 08, 2013, 03:35:08 pm
Do you insist everyone read the novel before you allow them to see the movie, too, oh great Gatekeeper?
@Not 2 Techydude

It is an excellent read, of discovery and intrigue, with exploration first into the hardware and a small bug like hack on top of ROM, then the JTAG spying, and the many players from all around the world, and the success by Cybernet and the opening of many secrets starting on the DS2000, but moving on to the DG4000, the DS4000, the DSA815 and more,
A story that John Le Carré would write :-+ :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: techydude on October 08, 2013, 04:45:12 pm
fiiiiiine.
y'all owe me 4 hours sleep  :=\

ok, you owe me nothing, just don't bitch when i wake up in the morning grumpier than usual.

although despite 4 hours reading, i still haven't found a post describing the distinction between the DS1074Z (70MHz) & DS1104Z (100MHz) - different h/w (unlike the DS2072/2102/2202) ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rory on October 08, 2013, 05:17:57 pm

It is an excellent read, of discovery and intrigue, with exploration first into the hardware and a small bug like hack on top of ROM, then the JTAG spying, and the many players from all around the world, and the success by Cybernet and the opening of many secrets starting on the DS2000, but moving on to the DG4000, the DS4000, the DSA815 and more,
A story that John Le Carré would write :-+ :-+

Yes, only in a fictional universe can one find folks as brilliant as Cybernet and the rest of the guys who contributed their efforts into this. I guess EEVBLOG Dave can be considered the Hugo Gernsback of this genre?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: van-c on October 09, 2013, 01:24:11 am
It is definitely a good read.  One topic still in suspense, though, is the new "A" model scopes, which are now briefly mentioned on the TEquipment web pages.  Has anyone yet verified whether the techniques discussed here for the DS2000 work for the DS2000A?
Title: Model: DS2302
Post by: Niffler on October 15, 2013, 08:33:11 pm
Hi,

I just used the KeyGen (ver 2.0b1) to generate a license key.
Before doing so i made sure i had the latest firmware version 00.01.01.00.02

System information before using license key:

Model:   DS2072
Serial:  DS2A1515xxxxx
Software version:  00.01.01.00.02
Hardware version:  1.0.2.0.0
FPGA version:
                   SPU  03.01.05
                   WPU  00.06.05
                   CCU  12.29.00
                   MCU  00.05

The license key was generated using Option code: DSAZ (all options, DS2202, License Type: Official)
After restart the options page shows all options install and official with 200M BandWidth option.
I can now set horizontal scale down to 1nsec and bandwidth limit to 20M, 100M and 200M.
Se attached image.

It sems like my scope thinks it is a 300 MHz version  :-+  unfortunate i don't have anything to test its bandwidth with.
Have any body seen this before ?

PS, Thanks for all your hard work in this forum, great read.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Fagear on October 15, 2013, 08:55:38 pm
SPU, WPU, CCU, MCU versions look the same. Not HW2.0. What is that? HW 1.0.2.0.0 ?..
That's exactly what the top of DS2000A series should be, not DS2000!
Congratulations, Niffler! :-+ Check maybe there is working 50 ohm option also?  :D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndreaEl on October 15, 2013, 09:00:44 pm
Hardware version is 1.0.2.0.0 because is in "advanced info". in "normal info" are 2.0

I have the same system info in a DS2072 recently bought. But 50ohm not available :(

My system info:

Model:   DS2072
Serial:  DS2A15320xxxx
Software version:  00.01.01.00.02
Hardware version:  1.0.2.0.0
FPGA version:
                   SPU  03.01.05
                   WPU  00.06.05
                   CCU  12.29.00
                   MCU  00.05

Calibration date: 15-Aug-2013


Probe: Rigol RP3300A - Fixed 10:1 Probe
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Fagear on October 15, 2013, 09:04:44 pm
AndreaEl, oh, I see.
So, have you checked - does your device turn into DS2302 or DS2202? You have all verisons the same as Niffler.

Is it version-related or something else, that isn't? Or is it some sort of time-limit (crazy)? What devices can be turned into DS2302?..
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndreaEl on October 15, 2013, 09:07:41 pm
My device now are a DS2202 because i have install the key for 200M BW + All Option. Not DS2302
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Fagear on October 15, 2013, 09:10:59 pm
And the same did Niffler. So this is not version related, that is something else! Did you tried to uninstall all options and install them again? Maybe it is current date related (must be crazy)?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: van-c on October 15, 2013, 09:13:11 pm
Is CAN bus trigger and decode option present?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndreaEl on October 15, 2013, 09:25:32 pm
Sorry but now i can't do and check nothing with oscilloscope. Tomorrow i have to wake up early for university.  :=\

Maybe tomorrow i can return home 1-2 hour and i check for decode option and for reinstall option.
But with the key generator are only possible select 70M/100M/200M. i think that is impossible have a DS2302 (with a DS2072) with the key genrator that are available for now.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Fagear on October 15, 2013, 09:28:32 pm
Sorry but now i can't do and check nothing with oscilloscope.
...
But with the key generator are only possible select 70M/100M/200M. i think that is impossible have a DS2302 (with a DS2072) with the key genrator that are available for now.
No problem, we will wait you here. ;) But as you can see, Niffler used same keygen and set all the same options:
I just used the KeyGen (ver 2.0b1) to generate a license key.
...
The license key was generated using Option code: DSAZ (all options, DS2202, License Type: Official)
After restart the options page shows all options install and official with 200M BandWidth option.
I can now set horizontal scale down to 1nsec and bandwidth limit to 20M, 100M and 200M.
...
It sems like my scope thinks it is a 300 MHz version
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Niffler on October 15, 2013, 09:47:19 pm
I have no CAN bus trigger or decoder.
My installed options page shows the same as others with all options.
I did not have to update the firmware it came with the latest version.
The first time i tried to enter a generated key it was wrong (stupid mistake of not entering the private key).
I have never uninstalled anything on the scope and only entered one accepted key.

When i first discovered that it actually said DS2302 not DS2202 which i had expected i was afraid i had done something wrong and i had/would possibly lose the serial number as have append to others, but my serial number is not changed and everything seems to work perfect.
And it has stayed the same for many restart.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JDubU on October 15, 2013, 09:57:27 pm
I have no CAN bus trigger or decoder.
My installed options page shows the same as others with all options.
I did not have to update the firmware it came with the latest version.
The first time i tried to enter a generated key it was wrong (stupid mistake of not entering the private key).
I have never uninstalled anything on the scope and only entered one accepted key.

When i first discovered that it actually said DS2302 not DS2202 which i had expected i was afraid i had done something wrong and i had/would possibly lose the serial number as have append to others, but my serial number is not changed and everything seems to work perfect.
And it has stayed the same for many restart.

Do you have the 50 ohm input option available on the menu?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: stormbr on October 15, 2013, 11:26:59 pm
My ds2072 arrive here today and was unlocked with sucess.

before update / system info

Model: DS2072
Serial: DS2A15350XXXX
Software version: 00.01.01
Hardware version: 2.0

after update / system info

Model: DS2202
Serial: DS2A15350XXXX
Software version: 00.01.01
Hardware version: 2.0

Special thanks for cybernet and studio25.

Note:

I used the code DSAZ for enabled all options and DSAS to 200MHz.

But for me not show the option 200M on BW Limit into ch1 menu, only the options off, 20M and 100M.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ahnuts72 on October 16, 2013, 01:02:37 am
I don't have one but I would assume off is 200 Mhz it wouldn't show 200 if that was the highest bandwidth.

Sent from my Nook HD

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: stormbr on October 16, 2013, 01:25:54 am
I think that this can mensure 200mhz, but the "bw limit" function (200M) not showed for me (ds2072a).

More info:

Horizontal scale:  2ns up to 1ks
Menu utility/options/installed: all enabled with official version (include 200MHz bandwidth option).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: staze on October 16, 2013, 05:02:42 am
My scope info looks pretty much the same, have the 200mhz hack installed. Obviously not seeing it as a 2302. Wonder if we found some kind of happy "bug" with the keygen? Received mine about a month ago, or so through tequipment.net.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JDubU on October 16, 2013, 05:19:54 am
My scope info looks pretty much the same, have the 200mhz hack installed. Obviously not seeing it as a 2302. Wonder if we found some kind of happy "bug" with the keygen? Received mine about a month ago, or so through tequipment.net.

The curious thing is that Niffler's DS2072 looks to be an earlier release of HW v2.
His serial number begins with DS2A1515 which would have been manufactured the last week of April of 2013.
Your serial number (DS2A1534...) indicates a manufacturing date in mid August 2013.

I wonder if there might be some different non-volatile memory content or hardware jumper settings that make the difference in option availability.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: staze on October 16, 2013, 05:46:35 am

The curious thing is that Niffler's DS2072 looks to be an earlier release of HW v2.
His serial number begins with DS2A1515 which would have been manufactured the last week of April of 2013.
Your serial number (DS2A1534...) indicates a manufacturing date in mid August 2013.

I wonder if there might be some different non-volatile memory content or hardware jumper settings that make the difference in option availability.

Yeah, noticed that. Either it's as you said, or something about the specific seed that he used for his unlock code? I too used DSAZ with Rigen 2b1.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JDubU on October 16, 2013, 05:53:53 am
Yeah, noticed that. Either it's as you said, or something about the specific seed that he used for his unlock code? I too used DSAZ with Rigen 2b1.


Good point.

Niffler:  Did you use a seed different than the default?

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: staze on October 16, 2013, 06:02:45 am
Yeah, noticed that. Either it's as you said, or something about the specific seed that he used for his unlock code? I too used DSAZ with Rigen 2b1.


Good point.

Niffler:  Did you use a seed different than the default?

As a note, I used a different seed... I just hit the generate button a half dozen times before hand. =)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Niffler on October 16, 2013, 11:27:27 am
I generated the license key with the default seed of 1, (having read that it would work with default).
No 50 ohm input option, at least not what i have found yet.
There may be some state that enables that.

I have had the scope for a while, i wanted to test it for a while before i "hacked" it in case there was some problem that popped up (it dying or some thing)
That why my scope is a bit earlier model, i was a bit of a coward for a while.

I will post a picture of the options page when i get home.
Title: Re: Model: DS2302
Post by: gilbjd on October 16, 2013, 12:26:37 pm
Hi,

I just used the KeyGen (ver 2.0b1) to generate a license key.
Before doing so i made sure i had the latest firmware version 00.01.01.00.02

System information before using license key:

Model:   DS2072
Serial:  DS2A1515xxxxx
Software version:  00.01.01.00.02
Hardware version:  1.0.2.0.0
FPGA version:
                   SPU  03.01.05
                   WPU  00.06.05
                   CCU  12.29.00
                   MCU  00.05

The license key was generated using Option code: DSAZ (all options, DS2202, License Type: Official)
After restart the options page shows all options install and official with 200M BandWidth option.
I can now set horizontal scale down to 1nsec and bandwidth limit to 20M, 100M and 200M.
Se attached image.

It sems like my scope thinks it is a 300 MHz version  :-+  unfortunate i don't have anything to test its bandwidth with.
Have any body seen this before ?

PS, Thanks for all your hard work in this forum, great read.


Interesting ... Niffler's DS2072 was manufactured in the 15th week of 2013 and has a Hardware version of 1.0.2.0.0

Mine was manufactured in the 20th week of 2013 yet it only has a Hardware version of 1.0.1.0.0
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JDubU on October 16, 2013, 04:32:39 pm
No 50 ohm input option, at least not what i have found yet.
There may be some state that enables that.

The 50 ohm input option is on the CH1/CH2 menu, fourth entry down, labelled "Input".
It normally shows a grayed out "1Mohm".  Does yours toggle to "50ohm"?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Niffler on October 16, 2013, 06:07:02 pm
My input option is grayed out and fixed to 1Mohm, and i have not be able to make it changeable.

Here is my installed options page.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on October 16, 2013, 06:33:33 pm
The lo-z (50-ohm) input impedance of the 'A' models is actually a hardware change; it cannot be implemented with a firmware upgrade (unless the rev.2 boards already had this in place).

What I'm curious to see is just how good the protection circuitry is, if any, for the 'A' models. With my spectrum analyzer, I know to always double check my signals to make sure it is safe for the device, but a scope I am used to just not worrying about it. Hopfully it has an auto-shutdown feature as well as the intelligence not to engage if selected when the input voltage reads larger than the damage level.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JDubU on October 16, 2013, 06:42:30 pm
The lo-z (50-ohm) input impedance of the 'A' models is actually a hardware change; it cannot be implemented with a firmware upgrade (unless the rev.2 boards already had this in place).
What I'm curious to see is just how good the protection circuitry is, if any, for the 'A' models. With my spectrum analyzer, I know to always double check my signals to make sure it is safe for the device, but a scope I am used to just not worrying about it. Hopfully it has an auto-shutdown feature as well as the intelligence not to engage if selected when the input voltage reads larger than the damage level.

The 50 ohm parallel input resistor plus relay are built into HW v2 hardware that has been shipping with the DS2000 series for most of this year.

See comparison photos:
https://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0 (https://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: staze on October 16, 2013, 06:43:55 pm
The lo-z (50-ohm) input impedance of the 'A' models is actually a hardware change; it cannot be implemented with a firmware upgrade (unless the rev.2 boards already had this in place).

What I'm curious to see is just how good the protection circuitry is, if any, for the 'A' models. With my spectrum analyzer, I know to always double check my signals to make sure it is safe for the device, but a scope I am used to just not worrying about it. Hopfully it has an auto-shutdown feature as well as the intelligence not to engage if selected when the input voltage reads larger than the damage level.

The teardown of the HW2 version elsewhere (https://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0/ (https://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0/)) shows that there is a 50ohm terminator, and it was able to be activated through JTAG... so no, it's just a firmware update that should allow it to be used.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on October 16, 2013, 06:47:00 pm
I stand corrected :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JDubU on October 16, 2013, 06:47:49 pm
My input option is grayed out and fixed to 1Mohm, and i have not be able to make it changeable.

Here is my installed options page.

Interesting that you could get some of the new A series features but not all of them.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Matje on October 16, 2013, 10:42:50 pm
The lo-z (50-ohm) input impedance of the 'A' models is actually a hardware change; it cannot be implemented with a firmware upgrade (unless the rev.2 boards already had this in place).

What I'm curious to see is just how good the protection circuitry is, if any, for the 'A' models. With my spectrum analyzer, I know to always double check my signals to make sure it is safe for the device, but a scope I am used to just not worrying about it. Hopfully it has an auto-shutdown feature as well as the intelligence not to engage if selected when the input voltage reads larger than the damage level.

The teardown of the HW2 version elsewhere (https://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0/ (https://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0/)) shows that there is a 50ohm terminator, and it was able to be activated through JTAG... so no, it's just a firmware update that should allow it to be used.

You can easily enable it now by connecting the scope via USB/Ethernet to a PC and sending the right command - this was shown somewhere else here. Sending e.g. "CHAN1:IMP FIFTY" will switch channel 1 to 50 ohms, "CHAN1:IMP OMEG" (that's not a zero but a letter O) to 1 MOhm. I can confirm that it really does switch input impedance on V2 hardware.

The menu will reflect the current setting but stay grayed out, so a new firmware or a hack is needed for convenient use.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: staze on October 16, 2013, 10:58:15 pm
The teardown of the HW2 version elsewhere (https://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0/ (https://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0/)) shows that there is a 50ohm terminator, and it was able to be activated through JTAG... so no, it's just a firmware update that should allow it to be used.

You can easily enable it now by connecting the scope via USB/Ethernet to a PC and sending the right command - this was shown somewhere else here. Sending e.g. "CHAN1:IMP FIFTY" will switch channel 1 to 50 ohms, "CHAN1:IMP OMEG" (that's not a zero but a letter O) to 1 MOhm. I can confirm that it really does switch input impedance on V2 hardware.

The menu will reflect the current setting but stay grayed out, so a new firmware or a hack is needed for convenient use.

Awesome! Does that stick between reboots?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: staze on October 17, 2013, 04:11:04 am
The teardown of the HW2 version elsewhere (https://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0/ (https://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0/)) shows that there is a 50ohm terminator, and it was able to be activated through JTAG... so no, it's just a firmware update that should allow it to be used.

You can easily enable it now by connecting the scope via USB/Ethernet to a PC and sending the right command - this was shown somewhere else here. Sending e.g. "CHAN1:IMP FIFTY" will switch channel 1 to 50 ohms, "CHAN1:IMP OMEG" (that's not a zero but a letter O) to 1 MOhm. I can confirm that it really does switch input impedance on V2 hardware.

The menu will reflect the current setting but stay grayed out, so a new firmware or a hack is needed for convenient use.

Awesome! Does that stick between reboots?

Just tested this, and it does indeed stick between reboots. Cool!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: lacommtech on October 17, 2013, 05:16:16 am
I recently acquired a DSA815-TG and tried the Windows "riglol" command line program using my unit's serial number, "AAAD", and "80444DFECE903E" as the private key,  to try to generate the 10Hz RBW option. 

Unfortunately, the resulting code reports that it is invalid when I enter it into the 815.

Any suggestions?

Thanks in advance.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Vtech on October 17, 2013, 06:55:33 am
lacommtech I also have DSA815-TG and I've used the same private key as you with riglol v2.0b1. All generated keys were ok including AAAD for 10Hz RBW. My DSA815 is quite new (week 09, 2013, firmware 00.01.06).

BTW. DSA815 with 10Hz RBW has really impressive DANL - I've measured about -145dBm with preamplifier on and tracking generator off. I've also noticed that the lowest value it can measure is -150dBm (it shows flat line at this value).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigol-Friend on October 17, 2013, 09:58:13 am
Cool, I tried to change the impedance. It works fine  ^-^.
Many thanks for this info.

But how did you find 'IMP FIFTY' and 'IMP OMEG' ?
I have read the Rigol Programming Guide, but nothing is written there about these commands.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on October 17, 2013, 10:05:45 am
But how did you find 'IMP FIFTY' and 'IMP OMEG' ?
I have read the Rigol Programming Guide, but nothing is written there about these commands.

It's in the firmware.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigol-Friend on October 17, 2013, 01:28:36 pm
Oh yes I see.  Clever !

Thanks for the info. I think the products from Rigol contain some secrets, is'nt it?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on October 17, 2013, 02:28:23 pm
Quote
Just tested this, and it does indeed stick between reboots. Cool!

This is DANGEROUS! Applying too high of a voltage when 50-ohm input is enabled will destroy the scope. If you forget you turned it off when that mode was enabled, it's likely the next time you power up the scope you will just be assuming it's in hi-z mode.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rory on October 17, 2013, 02:40:50 pm
Quote
Just tested this, and it does indeed stick between reboots. Cool!

This is DANGEROUS! Applying too high of a voltage when 50-ohm input is enabled will destroy the scope. If you forget you turned it off when that mode was enabled, it's likely the next time you power up the scope you will just be assuming it's in hi-z mode.

Would you think that most people would probably use the 10x probe in this scenario, and if so, how much power would terminator dissipate if you apply the maximum rated voltage for the probe?  Understandably a direct cable to the scope would definitely jeopardize the terminator (and the attenuator as well...?)

Personally, I will stick to using an external terminator and a 10:1 attenuator at the input of my scope if I'm measuring 50 ohm systems with it. Easier to replace the attenuator than send the scope in for repair.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on October 17, 2013, 02:46:43 pm
Quote
Would you think that most people would probably use the 10x probe in this scenario, and if so, how much power would terminator dissipate if you apply the maximum rated voltage for the probe?

This wouldn't work. The 10X probe has a very high input impedance, in the order of megaohms. This would be a voltage divider with a 1M+ resistor and a 50-ohm resistor... all of the signal would be lost before getting to the scope. The 50-ohm input is for connecting a (preferably impedance matched) device directly to the scope with a BNC cable.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on October 17, 2013, 02:54:39 pm
The difference between the 1M and 50 ohm input is just that: a 50 ohm resistor switched over the input by a relay. So all you will destroy is the 50 ohm resistor, the rest of the scope should be safe since it is exactly the same circuit. That is of course assuming the dying resistor will not spread a fine carbon layer on top of your input circuitry.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: lacommtech on October 17, 2013, 03:16:01 pm
Vtech, thanks for the response.  I was using the older version of the program and have now installed the new one. 

Works now.  I was entering spaces for the "-" in the generated key.  Entering the key w/o them solved the problem.

Thanks again.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rory on October 17, 2013, 03:42:59 pm
Quote
Would you think that most people would probably use the 10x probe in this scenario, and if so, how much power would terminator dissipate if you apply the maximum rated voltage for the probe?

This wouldn't work. The 10X probe has a very high input impedance, in the order of megaohms. This would be a voltage divider with a 1M+ resistor and a 50-ohm resistor... all of the signal would be lost before getting to the scope. The 50-ohm input is for connecting a (preferably impedance matched) device directly to the scope with a BNC cable.

Precisely the point I'm trying to make. I'm just saying it would be pretty difficult to damage the terminator when the 10x probe is used.  That is all. All bets are off when you attach coax directly to the scope - wouldn't be surprised to see some bonehead apply 100w to the input and let the smoke out.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on October 17, 2013, 03:48:56 pm
Quote
Precisely the point I'm trying to make. I'm just saying it would be pretty difficult to damage the terminator when the 10x probe is used.  That is all. All bets are off when you attach coax directly to the scope - wouldn't be surprised to see some bonehead apply 100w to the input and let the smoke out.

You wouldn't damage the scope, but you also wouldn't see the goddamn signal. Vertical sensitivity is 0.5mV/div. Unless you're measuring a tesla coil, this is pointless
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DL5TOR on October 17, 2013, 04:25:43 pm
Vtech, thanks for the response.  I was using the older version of the program and have now installed the new one. 

Works now.  I was entering spaces for the "-" in the generated key.  Entering the key w/o them solved the problem.

Thanks again.

Enter the key without any spaces or special signs just the plein letters and numebes then it shuld work

73 de dl5tor
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndreaEl on October 17, 2013, 05:04:19 pm
And the same did Niffler. So this is not version related, that is something else! Did you tried to uninstall all options and install them again? Maybe it is current date related (must be crazy)?

I have try but nothing... Only 200M BW.
I have used same Serial(obvious), same priv key and same key generator.



Is CAN bus trigger and decode option present?

CAN trigger/decode not present. Before and after reinstall key.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: lacommtech on October 17, 2013, 06:22:51 pm
"Enter the key without any spaces or special signs just the plein letters and numebes then it shuld work

73 de dl5tor"

Das funktioniert gut.

Vielen Dank.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Bugware on October 18, 2013, 05:16:11 am
Hi folks,

I'm a little confused. There are two ways for Windows to generate license keys. Once with rigol.zip by studio25 for the command line (most recent in reply #1171 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg304450/#msg304450) on page 79) and the other which is RiGen-2b1.zip by synapsis in reply #955 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg276813/#msg276813) on page 64.


1.  Generates both Windows-Apps correct licenses?

So far I understand is that synapsis use the original code by cybernet with some kind of brute force technique and studio25 uses a cleanuped version of the cybernet code.  But by using the same serial number and private key (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg264608/#msg264608) they generate different license keys. In the version of studio25 it is not possible to set a seed. So it try’s with seed of 1? I definitely lost the thread how do both programs work.

In any case, it makes me unsure that two separate programs compute with same inputs different results.  It feels to me (and maybe to others too) not to be stable. But apparently both work properly, many have already been activated their devices with one or another of these programs for Windows. It would be more comprehensible and comparable if both have the same result.

So my question is, can I use both without any risk? (Without risk to lose the serial number for example?  Is now the license uninstallable everytime for sure?)


2. Are there more possible to activate?

Niffler has activated his device with synapsis RiGen-2b1 at random to a DS2302 (reply #1186 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg310675/#msg310675) on page 80). At the very beginning of this thread some had chanced bytes directly in the firmware to get the 1ns option.
Are there maybe other options hidden and secret in the license keys to activate more options like 300MHz BW, CAN trigger/decode and the 50ohm option…? Has somebody take a look at that? What does cybernet says to that? ;)

OR

In the Firmware are clearly stuck parts from other equipment or hardware (-versions). Are there some kind of recognition mechanisms in the firmware that detects which device is operating and then unlock functions? But what criteria recognizes the firmware to unlock features? The serial number? The hardware version? Both together? 

Or are there different firmwares out with the same version number but for each DS2000 series “type”?


3. Does anyone know what the difference is to the MCU 02.12?

Here the System info of my device:

Model: DS2072
Serial: DS2A1527xxxxx
Software Version: 00.01.01  (00.01.01.00.02)
Hardware Version: 2.0       (1.0.2.0.0)
FPGA version:
    SPU  03.01.05
    WPU  00.06.05
    CCU  12.29.00
    MCU  02.12


I've seen only once the MCU version 02.12. What has that probably mean? Is that Microcontroller unit changed in hardware or software version?  Probably not Hardware because it is a part of the FPGA. More recent devices have a MCU 00.05? And older also... Is that not strange?

Does somebody recognize that and know more about the MCU 02.12?


Many questions from me... ;)

But nevertheless kudos and many thanks to all the people who have given so much effort and put in so much work! Incredible!

Thumbs up!  :-+
Bugware


PS @studio25: Is it possible to put a version number to your program? That would make it easier to check if you have the latest version.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: stormbr on October 19, 2013, 02:20:44 am
Hi Bugware,

1.  Generates both Windows-Apps correct licenses?

You can use the synapsis version and hit 300mhz too, as the user Niffler explain. But i have sure that the two versions works fine.

2. Are there more possible to activate?

Others users says for me that private key with 14 digits (8EEBD4D04C3771) not work 100% with ds2072a and i not tried uninstall the update yet (not have sure if i going to do this).

My case - with the same software/hardware/mcu version.

Unlock method: studio25 (last post) by windows prompt.
model: 2202 (after update)
serial number: not change
time base: 2ns
bw filter/limit - options: off - 20m - 100m - (not have 200m)
50ohm option: not unlock

Note:

The keygen of studio25 works well (thanks for your work) with all other options unlocked, but i not hit 300mhz.

3. Does anyone know what the difference is to the MCU 02.12?

I think that it's not important because just the software version (not fpga) is updated.

http://www.gotroot.ca/rigol/ (http://www.gotroot.ca/rigol/)

Good luck.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndreaEl on October 19, 2013, 08:03:27 am
It's normal that my DS2072 when i start it the fan run with low noise, but after 1 min it run at full power and never slow the speed.
Title: Re: Model: DS2302
Post by: Carrington on October 19, 2013, 02:29:25 pm
Hi,

I just used the KeyGen (ver 2.0b1) to generate a license key.
Before doing so i made sure i had the latest firmware version 00.01.01.00.02

System information before using license key:

Model:   DS2072
Serial:  DS2A1515xxxxx
Software version:  00.01.01.00.02
Hardware version:  1.0.2.0.0
FPGA version:
                   SPU  03.01.05
                   WPU  00.06.05
                   CCU  12.29.00
                   MCU  00.05

The license key was generated using Option code: DSAZ (all options, DS2202, License Type: Official)
After restart the options page shows all options install and official with 200M BandWidth option.
I can now set horizontal scale down to 1nsec and bandwidth limit to 20M, 100M and 200M.
Se attached image.

It sems like my scope thinks it is a 300 MHz version  :-+  unfortunate i don't have anything to test its bandwidth with.
Have any body seen this before ?

PS, Thanks for all your hard work in this forum, great read.
All this is very strange, does not match with anything known until now.
https://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0/msg270500/#msg270500 (https://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0/msg270500/#msg270500)
https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg264041/#msg264041 (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg264041/#msg264041)

Range for Probes:
https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg265546/#msg265546 (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg265546/#msg265546)

It is disconcerting, it also becomes in a DS2302...
Niffler, please could you check the BW?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on October 19, 2013, 02:32:47 pm
It's normal that my DS2072 when i start it the fan run with low noise, but after 1 min it run at full power and never slow the speed.
The same thing happens with mine, and I think that with all.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: eurofox on October 19, 2013, 02:45:36 pm
It's normal that my DS2072 when i start it the fan run with low noise, but after 1 min it run at full power and never slow the speed.
The same thing happens with mine, and I think that with all.

The Rigol Hacker virus in action, next step is erase the firmware and destroy all electronics  :-DD :-DD :-DD
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndreaEl on October 19, 2013, 09:55:44 pm
I have try another time for have a DS2302 but nothing...

This time i have install the key from USB connection:
Seed: 1
All Option + 200MHz

After install key i have:
Model: DS2202
time base: 2ns
BW options: off - 20m - 100m (NO 200MHz)
ONLY 1MOhm


we have other ideas for try to have a ds2302??

The people that have a 2302 can explain step by step what they do for have a 2302??
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on October 19, 2013, 10:16:47 pm
http://riglol.3owl.com/ (http://riglol.3owl.com/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndreaEl on October 19, 2013, 10:34:59 pm
http://riglol.3owl.com/ (http://riglol.3owl.com/)

Perfect!!! Any update in this release?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on October 19, 2013, 10:44:49 pm
http://riglol.3owl.com/ (http://riglol.3owl.com/)

Perfect!!! Any update in this release?

No, only minimal changes such as a version number, and minor cleanup.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Bugware on October 20, 2013, 12:23:47 am
Hi to all,

Thank you for reply stormbr.

1.  Generates both Windows-Apps correct licenses?

You can use the synapsis version and hit 300mhz too, as the user Niffler explain. But i have sure that the two versions works fine.
I was not interested in more BW and 50ohm option than more in CAN trigger/decode for the future.
But it is nice to see the challenge how to get maybe all option free. That is like a TV Thriller… ;)

The first question I posed was only because I got my DS2072 only a week ago. So I cannot decide to unlock the licenses immediately or later. I want check the device at first. Or send it back and wait for the DS2072A...


2. Are there more possible to activate?

Others users says for me that private key with 14 digits (8EEBD4D04C3771) not work 100% with ds2072a and i not tried uninstall the update yet (not have sure if i going to do this).

My case - with the same software/hardware/mcu version.

Unlock method: studio25 (last post) by windows prompt.
model: 2202 (after update)
serial number: not change
time base: 2ns
bw filter/limit - options: off - 20m - 100m - (not have 200m)
50ohm option: not unlock

Note:

The keygen of studio25 works well (thanks for your work) with all other options unlocked, but i not hit 300mhz.
The second point I wanted to see how the TV Thriller continues, and perhaps to give some ideas to rekindle the “research fire” to continue.

And it’s true, there was something like 13 and 14 digit of serial numbers with the DS2072 (without the “a”. Or do you get already a new one DS2072A?). I think, that problem was solved in reply#567 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg265461/#msg265461) ff on page 38. But it was not really clear to me, is it a general problem that been solved or the 13/14 chars long serial/lic1/lic2 or whatever problem…? Very confusing.


3. Does anyone know what the difference is to the MCU 02.12?

I think that it's not important because just the software version (not fpga) is updated.
 
The third point was not only to know, what is the change in MCU 02.12. I'm interested in, but also in how the MCU (or even FPGA) can get new Software? With a new Firmware? If the Firmware update 00.01.01.00.02 include the new MCU Version, why nobody get them? My Rigol was shipped with the new Firmware but with MCU 02.12. Where is the difference between the shipped version and the update version of the “same” Firmware (or does the Firmware never change the MCU Version?)? Maybe there are different versions of the same Firmware 00.01.01.00.02? Could I clearly express what I want to say? ;)

This is all very exciting!
Bugware
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Bugware on October 20, 2013, 12:34:21 am
Hi AndreaEl,

I have try another time for have a DS2302 but nothing...

This time i have install the key from USB connection:
Seed: 1
All Option + 200MHz

After install key i have:
Model: DS2202
time base: 2ns
BW options: off - 20m - 100m (NO 200MHz)
ONLY 1MOhm


we have other ideas for try to have a ds2302??

The people that have a 2302 can explain step by step what they do for have a 2302??

I think you can try 100 times but don't get a 2302 with the actual KeyGen. Niffler has only luck by get a DS2302. What conditions enabled that is not clear yet...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Bugware on October 20, 2013, 12:36:33 am
http://riglol.3owl.com/ (http://riglol.3owl.com/)

Perfect!!! Any update in this release?

No, only minimal changes such as a version number, and minor cleanup.

Version number! Nice! Thank you! :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jsykes on October 20, 2013, 06:45:15 am
I just noticed something with the DSA815 KeyGens. Unlike the DS2, the DSA keygen always generates the same key for a particular serial number no matter how many times the generate action is initiated. The keys are the same whether using the Linux, Windows GUI, or the DOS command line versions with the exception of the AAAC (advanced measurement kit) key. The same key is always returned no matter how many times that AAAC key is generated but the DOS command line KeyGen returnes a different key than the Windows or Linux Keygens do only for that adv measurement kit. I'm sure the Windows or Linux keys generated for that function work but I don't know if that different command line generated key does.
I cannot test the web based generator because it doesn't work for me using either Iexplorer or Firefox. In Iexplorer after entering the serial, private key and function, nothing happens when clicking generate. I have enabled active x permissions without success but since the other KeyGens work I don't need it. I'm just wondering if the different AAAC key returned by the command line KeyGen version is valid.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: stormbr on October 20, 2013, 01:03:23 pm

1-) Or send it back and wait for the DS2072A...

DS2072A = DS2072 Hardware version 2.0

Quote
2-)The second point I wanted to see how the TV Thriller continues, and perhaps to give some ideas to rekindle the “research fire” to continue.

And it’s true, there was something like 13 and 14 digit of serial numbers with the DS2072 (without the “a”. Or do you get already a new one DS2072A?). I think, that problem was solved in reply#567 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg265461/#msg265461) ff on page 38. But it was not really clear to me, is it a general problem that been solved or the 13/14 chars long serial/lic1/lic2 or whatever problem…? Very confusing.

I not have any idea about this, prefer leave this question for the hardcore users.

 
Quote
3-) The third point was not only to know, what is the change in MCU 02.12. I'm interested in, but also in how the MCU (or even FPGA) can get new Software? With a new Firmware? If the Firmware update 00.01.01.00.02 include the new MCU Version, why nobody get them? My Rigol was shipped with the new Firmware but with MCU 02.12. Where is the difference between the shipped version and the update version of the “same” Firmware (or does the Firmware never change the MCU Version?)? Maybe there are different versions of the same Firmware 00.01.01.00.02? Could I clearly express what I want to say? ;)

You've need the last firmware for update your device and it's necessary send to rigol a request form for download the new firmware.

I don't know anything about how to do update the firmware to ds2072 and not found the firmware on rigol web site.






Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Pinkus on October 20, 2013, 01:09:23 pm
Quote
Niffler has only luck by get a DS2302. What conditions enabled that is not clear yet...

I assume Niffler does not want to make his serial public but maybe he can send his serial # and the produced license # to Cybernet so he (Cybernet) can find out what specific circumstances are needed to produce exactly this serial #. This might then lead to a revised code which brings all 2072 to 300 Mhz and maybe a CAN bus interpreter.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on October 20, 2013, 04:56:22 pm
...or the DOS command line versions...
...but the DOS command line KeyGen...
lol, who compiled it for DOS?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Bugware on October 21, 2013, 02:13:30 am

1-) Or send it back and wait for the DS2072A...

DS2072A = DS2072 Hardware version 2.0

This is not proven. I don't believe that, until someone makes a teardown of the new model DS2072A. Sure, in the DS2072 HW 2.0 are many new parts, that not be used (e.g. the 50ohm with the relay and other stuff - Yes I've seen the pics of PA0PBZ here (https://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0/msg270218/#msg270218)). But maybe that is only the first step to the DS2072A. Maybe they designed a new PCB and started with the production of the HW 2.0 but after that they found some missing "things" that not sufficient with the requirements of the DS2072A but with DS2027. So they don't change the PCB for the DS2072, because of cost, and we get HW 2.1 with the DS2072A. Why they don't called the HW 2.0 at the very beginning DS2072A?
Maybe there are only some jumpers on the HW 2.0 to change it to the "A"-Model. Maybe they only need new Firmware.

There are too many "Maybe's" so we will wait and see what happen. These are just guesses of some people here that DS2072A = DS2072 Hardware version 2.0, but nobody knows it 100%.

Clearly I would be happy if it is only a Firmware Upgrade and my DS2072 HW 2.0 becomes an A-Model! ;)


3-) The third point was not only to know, what is the change in MCU 02.12. I'm interested in, but also in how the MCU (or even FPGA) can get new Software? With a new Firmware? If the Firmware update 00.01.01.00.02 include the new MCU Version, why nobody get them? My Rigol was shipped with the new Firmware but with MCU 02.12. Where is the difference between the shipped version and the update version of the “same” Firmware (or does the Firmware never change the MCU Version?)? Maybe there are different versions of the same Firmware 00.01.01.00.02? Could I clearly express what I want to say? ;)

You've need the last firmware for update your device and it's necessary send to rigol a request form for download the new firmware.

I don't know anything about how to do update the firmware to ds2072 and not found the firmware on rigol web site.

Yes, normally you need to contact Rigol to get a new Firmware.

But marmad collects the new Firmware in the Review-Thread here (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684). There are also described how the Firmware update works...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: darrylp on October 21, 2013, 09:48:48 am
I did, but sure others did as well. However mine was from the very first few releases of the code base.

Darryl

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on October 21, 2013, 12:32:13 pm
...or the DOS command line versions...
...but the DOS command line KeyGen...
lol, who compiled it for DOS?

Pretty sure that it was compiled for Windows command-line, not DOS.  Some people call this "DOS" even though it isn't DOS.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on October 21, 2013, 01:03:19 pm
So nobody has been able to get the 300MHz bandwidth out of the DS2000 yet?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cosmos on October 21, 2013, 01:32:54 pm
ve7xen seems to have confirmed it?

Link does not work, get the one two posts down.
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg239833/?PHPSESSID=bc172c0d2acb4313d7eea9a94ce57729#msg239833 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg239833/?PHPSESSID=bc172c0d2acb4313d7eea9a94ce57729#msg239833)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on October 21, 2013, 02:12:03 pm
That confirms that the device is capable of having a 300MHz bandwidth, but I'm referring to unlocking the option in the firmware (similar to the 50-ohm input) without hardware modifications
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: arvidj on October 21, 2013, 02:38:21 pm
ve7xen seems to have confirmed it?
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg239833/?PHPSESSID=bc172c0d2acb4313d7eea9a94ce57729#msg239833 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg239833/?PHPSESSID=bc172c0d2acb4313d7eea9a94ce57729#msg239833)

That link did not work for me but I was able to find the message ... https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg239833/#msg239833 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg239833/#msg239833)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jsykes on October 21, 2013, 11:11:05 pm
...or the DOS command line versions...
...but the DOS command line KeyGen...
lol, who compiled it for DOS?

Pretty sure that it was compiled for Windows command-line, not DOS.  Some people call this "DOS" even though it isn't DOS.

 Thanks, Rigby
That's exactly what I was referring to. I'm from the pre-windows generation so I called the windows command line simulation of DOS, just that. Anyway, the subject of the post was about AAAC returning a different key only when generated with the command line version. Just wanted to report that observation.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cosmos on October 22, 2013, 03:12:39 pm
Found something for the DS4000 that was new to me.

The key sequence for getting extended version info also open other stuff.
to enter and exit : Trig menu -> edge. then in one quick sequence  F7 + F6 + F7 + Utililty

EDIT: (Clarification)
to enter and exit :
Trig menu -> edge.
then in one quick sequence  [MENU7_R] + [MENU6_R] + [MENU7_R] + [Utililty]
(from marmads post earlier in tread)
/EDIT

Now I have:
extended version info under Utility -> system -> System info 
extended power info under Utility -> system -> SelftestInfo
a new sub menu under Utility(2) (second screen) called Project
under project there is now

screen #1:
Screentest
Key test
AuxTest
Gain1
Gain2
-
-

screen #2:
-
EqualCal
DealyCal
-
-
Resumecal

screen #3:
Probecal
Factory
-
-
-
-
-
return

I wonder if there might be even more interesting menus to be activated like this ... how did people find the unlocking key sequence in the first place?

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on October 24, 2013, 01:37:26 am
I find this report of 2302 to be quite odd, but looking at the firmware does show a place where it says DS2072 and then has 07, then 10, then 20, then 30.  If you can assume that the 4 two byte sequences replace the 07 in the DS2072 then it is possible that this version of firmware which has been out for awhile does actually support a DS2302.  The question is how to enable it.  Could it be that some bits in the 3rd group are also additional option bits like what was found with the 3rd group for the ds1000z?

Could the firmware on niffler's have the same version, but actually be different than the firmware version we have all upgraded to?  He said he did not have to upgrade it...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Pinkus on October 24, 2013, 06:22:02 pm
I have been told (no I will not tell you who, but it is a very reliable source) that the DS2072 can be enhanced to 50 Ohm termination, 300 Mhz AND also to CAN protocol..... >:D
Though I do not know if this is possible just by entering a code or by writing new stuff through the JTAG into it but I doubt the latter.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on October 24, 2013, 06:42:21 pm
I have been told (no I will not tell you who, but it is a very reliable source) that the DS2072 can be enhanced to 50 Ohm termination, 300 Mhz AND also to CAN protocol..... >:D
Though I do not know if this is possible just by entering a code or by writing new stuff through the JTAG into it but I doubt the latter.
You mean the DS2072A right ?. The DS2072 (HW version 1.0) does not have a 50ohm termination build in  ;D...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on October 24, 2013, 06:43:59 pm
Probably just a firmware update from Rigol once the DS2000A becomes available (same firmware)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: apelly on October 24, 2013, 06:53:50 pm
My 2072A should get here on Tuesday. Monday is a holiday here.

What do you want me to do with it? Aside from pics & firmware version obviously.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on October 24, 2013, 07:29:52 pm
Quote
My 2072A should get here on Tuesday. Monday is a holiday here.

What do you want me to do with it? Aside from pics & firmware version obviously.

(Try to) Hack it! Use the keygen provided on this forum and see if you can successfully turn it into a 200MHz scope with 56MPts memory and all the bells and whistles
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: apelly on October 25, 2013, 06:29:48 am
2072a firmware details...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on October 25, 2013, 01:38:32 pm
Has anyone else besides niffler tried a DSAZ key on a hardware 1.0.2.0.0 version to see if it also shows DS2302?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: davidefa on October 25, 2013, 02:19:10 pm
I think that several of us tried DSAZ.
I have same system info as niffler and AndreaEl ( only 'manufacturing week' is different, week=27 ).
Now my scope is DS2202 ( sticker still DS2072 ;-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: davidefa on October 25, 2013, 02:22:58 pm
Serial of apelly starts with DS2D ( DS2072A ). Our starts with DS2A ( DS2072 )
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rory on October 26, 2013, 02:06:36 am
Primer on elliptic curve cryptograpy...

http://arstechnica.com/security/2013/10/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/ (http://arstechnica.com/security/2013/10/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Circlotron on October 26, 2013, 02:12:49 am
How do you get the extended system information? I read it somewhere but I can't find it now.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JDubU on October 26, 2013, 02:24:55 am
How do you get the extended system information? I read it somewhere but I can't find it now.

From Marmad's post on another thread:

"Go to the Trigger menu and set Edge trigger.
While keeping the Trigger menu open, you are going to use the 6th and 7th right-side menu buttons as follows:
Press the [Menu7][Menu6][Menu7][Utility] buttons one after another quickly.
Then check additional info under System -> System Info."

https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/ (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Circlotron on October 26, 2013, 10:15:29 am
Aha.  :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: engr_rf on October 26, 2013, 03:53:22 pm
Is it possible to get extended system information on the DSA815?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on October 26, 2013, 06:06:05 pm
For god sakes man, can it be hacked?!! Haha, my mouth is watering thinking about this damn scope.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: van-c on October 26, 2013, 11:53:13 pm
Yeah, my sentiments exactly.  In fact, I have an order in for a DS2072 due to ship in a week that I'm trying to decide whether to postpone and wait for the DS2072A.   But once current DS2000 shipments are made, there may no longer be any of the original models. And with the total lack of test results on the "A" models, I'm not willing to take the gamble.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: apelly on October 29, 2013, 02:55:02 pm
At first glance, my new DP832 and DS2072A appear to be immune to the key generators in this thread.

Could have been a typo. Will fool around some more tomorrow.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: iNoxxam on October 29, 2013, 04:42:47 pm
Hi,
I used the keygen to upgrade my DS2072 to a full option DS2022 model, and this works great. Thank you lots guys!
But it also did reset my Serial Number to DS2A000000001. Is there a way to reprogram the original serial (which I know) without actually opening the device and reprogramming the EEPROM directly?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndreaEl on October 29, 2013, 05:05:33 pm
Hi,
I used the keygen to upgrade my DS2072 to a full option DS2022 model, and this works great. Thank you lots guys!
But it also did reset my Serial Number to DS2A000000001. Is there a way to reprogram the original serial (which I know) without actually opening the device and reprogramming the EEPROM directly?

What version of the FW had you before the install of the key? Before install key is better install latest FW for not delete the serial #.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: iNoxxam on October 29, 2013, 05:20:09 pm
Hi,
I used the keygen to upgrade my DS2072 to a full option DS2022 model, and this works great. Thank you lots guys!
But it also did reset my Serial Number to DS2A000000001. Is there a way to reprogram the original serial (which I know) without actually opening the device and reprogramming the EEPROM directly?

What version of the FW had you before the install of the key? Before install key is better install latest FW for not delete the serial #.

I had 00.01.01.00.02, the latest available version. I did the upgrade, then installed keys, and then it did not boot up anymore. So I had to do the upgrade again, and then I had DS2A000000001 serial. I installed the keys again with this serial and everything works OK, but it could be much better if I could recover the original serial, in case Rigol checks that in future upgrades.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PP7BB on October 29, 2013, 06:21:10 pm
May I ask a silly question?

Is HW 2.0 version hackable (DS2072A)?

I am going to buy Rigol, but don't know which version works with hack...

Sorry I am messing in the thread a little bit but most of people forgot to write their HW number.

--------------------------------------------
added

Looks like there are earlier version HW 2 and newer... Am I correct? Which HW revisions are hackable?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndreaEl on October 29, 2013, 11:38:04 pm
May I ask a silly question?

Is HW 2.0 version hackable (DS2072A)?

I am going to buy Rigol, but don't know which version works with hack...

Sorry I am messing in the thread a little bit but most of people forgot to write their HW number.

--------------------------------------------
added

Looks like there are earlier version HW 2 and newer... Am I correct? Which HW revisions are hackable?

There are:

DSDS2XX2 ----- HW 1.0 ----- Hackable with latest FW No sell new
DSDS2XX2 ----- HW 2.0 ----- Hackable with latest FW (I have this one) Can buy NEW

DSDS2XX2A ----- HW 2.0 ----- NOT HACKABLE ----- Can buy NEW ----- See Reply #1275

If someone can confirm this, I'm not sure about DSDS2XX2A, no much people have this. in future maybe can be possible hack this one!!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bobn4burton on October 30, 2013, 12:39:51 am
So I just ordered a DS2072 and am hoping to do the mod to DS2202.  I got a good deal on a refurb unit!  I will admit that I haven't read this whole thread yet...just scanned over parts of it.

I am wondering if there is a good place that compiles all the needed info into a step by step procedure?  I have looked at this:

http://freneticrapport.blogspot.com/2013/07/raspberry-pi-rigol-ds2072-200mhz.html (http://freneticrapport.blogspot.com/2013/07/raspberry-pi-rigol-ds2072-200mhz.html)

Is there a better or more current place to step me through the process?  Maybe even a page/post in this thread I should look at?  Or another web link?

I am a newbie to all this...
Thanks in advance!!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on October 30, 2013, 12:43:55 am
Quote
DSDS2XX2A ----- HW 2.0 ----- NOT HACKABLE ----- Can buy NEW ----- See Reply #1275

If he couldn't get it to work on his DP832 either then I'm guessing he is just using the keygen incorrectly. Not necessarily, but likely. We'll see as more DS2000A units arrive.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: apelly on October 30, 2013, 02:11:56 am
Quote
DSDS2XX2A ----- HW 2.0 ----- NOT HACKABLE ----- Can buy NEW ----- See Reply #1275

If he couldn't get it to work on his DP832 either then I'm guessing he is just using the keygen incorrectly. Not necessarily, but likely. We'll see as more DS2000A units arrive.
Yea. Exactly. Only fooled around for 10 minutes. And only used input directly on the scope. And it was late (very). Chance for error? Well over 50% I reckon.

No time to pick this up right now, but FWIW the firmware version on my 832 is 00.01.06, in case anyone has any ideas in the meantime.

I have not checked which firmware versions the keygen is reported to work with. (or if there is extended system info anywhere)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on October 30, 2013, 01:18:04 pm
Quote
Yea. Exactly. Only fooled around for 10 minutes. And only used input directly on the scope. And it was late (very). Chance for error? Well over 50% I reckon.

No time to pick this up right now, but FWIW the firmware version on my 832 is 00.01.06, in case anyone has any ideas in the meantime.

I have not checked which firmware versions the keygen is reported to work with. (or if there is extended system info anywhere)

Give it another try today and let us know. If you have any questions about how to generate the keys just pm me with the serial of the scope and I'll message you the keys.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tsmith35 on October 30, 2013, 03:37:14 pm
Give it another try today and let us know. If you have any questions about how to generate the keys just pm me with the serial of the scope and I'll message you the keys.
Just out of curiosity, where are the steps for generating keys? I remember seeing something about elliptical encryption, but not any step by step stuff.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on October 30, 2013, 04:45:06 pm
Quote
Just out of curiosity, where are the steps for generating keys? I remember seeing something about elliptical encryption, but not any step by step stuff.

Well, if you're only interested in generating these Rigol keys, then there is a command line utility to do that for you. However, if you are tying to learn the math behind the technology, I'd recommend you Google it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PP7BB on October 30, 2013, 05:16:34 pm
apelly you're our only hope... ;-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JDubU on October 30, 2013, 05:42:19 pm
Quote
Just out of curiosity, where are the steps for generating keys? I remember seeing something about elliptical encryption, but not any step by step stuff.

Well, if you're only interested in generating these Rigol keys, then there is a command line utility to do that for you. However, if you are tying to learn the math behind the technology, I'd recommend you Google it.

Take a look at this link:
http://arstechnica.com/security/2013/10/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/ (http://arstechnica.com/security/2013/10/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cosmos on October 30, 2013, 08:32:56 pm
some findings on the DS4000, sorry no revolution, just gathering background info.

poking around in the latest DS4000 GEL files I find this:

Code: [Select]
seg000:00332EC0  CA B1 BC E4 A3 BA 00 00  4F 70 74 69 6F 6E 20 4E  -¦+õú¦..Option N
seg000:00332ED0  61 6D 65 3A 00 00 00 00  4F 70 74 69 6F 6E 20 54  ame:....Option T
seg000:00332EE0  79 70 65 3A 00 00 00 00  54 69 6D 65 20 4C 65 66  ype:....Time Lef
seg000:00332EF0  74 3A 00 00 6E B8 16 00  70 B8 16 00 6E B8 16 00  t:..n©.p©.n©.
seg000:00332F00  6E B8 16 00 66 B8 16 00  66 B8 16 00 66 B8 16 00  n©.f©.f©.f©.
seg000:00332F10  6E B8 16 00 06 01 5A AD  68 B6 FA 00 1C 00 00 00  n©.Z¡h·....
seg000:00332F20  66 B8 16 00 06 00 2F AD  84 B6 FA 00 4C 00 00 00  f©../¡ä·.L...
seg000:00332F30  00 00 00 00 6E B8 16 00  4F 66 66 63 69 61 6C 20  ....n©.Offcial
seg000:00332F40  56 65 72 73 69 6F 6E 00  F8 B9 16 00 AC BA 16 00  Version.°¦.¼¦.
seg000:00332F50  A0 BB 16 00 68 BC 16 00  52 53 32 33 32 BD E2 C2  á+.h+.RS232¢Ô-
seg000:00332F60  EB 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  Ù...............
seg000:00332F70  00 00 00 00 00 00 53 50  49 BD E2 C2 EB 00 00 00  ......SPI¢Ô-Ù...
seg000:00332F80  06 01 22 AD D0 B6 FA 00  14 00 00 00 00 00 00 00  "¡ð·.¶.......
seg000:00332F90  06 00 0B AD E4 B6 FA 00  08 00 00 00 00 00 00 00  .¡õ·........
seg000:00332FA0  49 32 43 BD E2 C2 EB 00  06 01 1E AD EC B6 FA 00  I2C¢Ô-Ù.¡ý·.
seg000:00332FB0  14 00 00 00 00 00 00 00  06 00 EA AD 00 B7 FA 00  ¶........Û¡.À·.
seg000:00332FC0  0C 00 00 00 00 00 00 00  00 00 43 41 4E BD E2 C2  .........CAN¢Ô-
seg000:00332FD0  EB 00 00 00 06 01 FF AD  0C B7 FA 00 14 00 00 00  Ù... ¡ À·.¶...
seg000:00332FE0  00 00 00 00 06 00 EE AD  20 B7 FA 00 28 00 00 00  .....¯¡ À·.(...
seg000:00332FF0  00 00 00 00 46 6C 65 78  52 61 79 BD E2 C2 EB 00  ....FlexRay¢Ô-Ù.
seg000:00333000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
seg000:00333010  00 00 35 30 30 4D B4 F8  BF ED 00 00 06 01 BB AD  ..500M¦°+Ý..+¡
seg000:00333020  48 B7 FA 00 14 00 00 00  00 00 00 00 06 00 92 AD  HÀ·.¶........Æ¡
seg000:00333030  5C B7 FA 00 28 00 00 00  00 00 00 00 33 35 30 4D  \À·.(.......350M
seg000:00333040  B4 F8 BF ED 00 00 00 00  00 00 00 00 00 00 00 00  ¦°+Ý............
seg000:00333050  00 00 00 00 00 00 00 00  00 00 32 30 30 4D B4 F8  ..........200M¦°
seg000:00333060  BF ED 00 00 06 01 77 AD  84 B7 FA 00 14 00 00 00  +Ý..w¡äÀ·.¶...
seg000:00333070  00 00 00 00 06 00 72 AD  98 B7 FA 00 0C 00 00 00  .....r¡ÿÀ·. ...
seg000:00333080  00 00 00 00 B5 E7 D4 B4  B7 D6 CE F6 00 00 00 00  ....ÁþȦÀÍ+÷....
seg000:00333090  06 01 57 AD A4 B7 FA 00  14 00 00 00 00 00 00 00  W¡ñÀ·.¶.......
seg000:003330A0  06 00 1B AD B8 B7 FA 00  44 01 00 00 00 00 00 00  .¡©À·.D......
seg000:003330B0  52 53 32 33 32 20 44 65  63 6F 64 65 00 00 00 00  RS232 Decode....
seg000:003330C0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 53 50  ..............SP
seg000:003330D0  49 20 44 65 63 6F 64 65  00 00 00 00 00 00 00 00  I Decode........
seg000:003330E0  00 00 00 00 00 00 00 00  00 00 00 00 49 32 43 20  ............I2C
seg000:003330F0  44 65 63 6F 64 65 00 00  00 00 00 00 00 00 00 00  Decode..........
seg000:00333100  00 00 00 00 00 00 00 00  00 00 43 41 4E 20 44 65  ..........CAN De
seg000:00333110  63 6F 64 65 00 00 00 00  00 00 00 00 00 00 00 00  code............
seg000:00333120  00 00 00 00 00 00 00 00  46 6C 65 78 52 61 79 20  ........FlexRay
seg000:00333130  44 65 63 6F 64 65 00 00  00 00 00 00 00 00 00 00  Decode..........
seg000:00333140  00 00 00 00 00 00 42 61  6E 64 77 69 64 74 68 20  ......Bandwidth
seg000:00333150  35 30 30 4D 00 00 00 00  00 00 00 00 00 00 00 00  500M............
seg000:00333160  00 00 00 00 42 61 6E 64  77 69 64 74 68 20 33 35  ....Bandwidth 35
seg000:00333170  30 4D 00 00 00 00 00 00  00 00 00 00 00 00 00 00  0M..............
seg000:00333180  00 00 42 61 6E 64 77 69  64 74 68 20 32 30 30 4D  ..Bandwidth 200M
seg000:00333190  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
seg000:003331A0  50 6F 77 65 72 20 41 6E  61 6C 79 73 69 73 00 00  Power Analysis..
seg000:003331B0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
seg000:003331C0  49 6E 73 74 61 6C 6C 65  64 20 4F 70 74 69 6F 6E  Installed Option
seg000:003331D0  73 00 00 00 04 C2 16 00  08 C2 16 00 04 C2 16 00  s...-.-.-.

I wonder if the options screen on models above DS4014 says the option is enabled or if the model number just enables the right bandwidth.
On the DS4014 only the options that are enabled gets printed, the bandwidth line does not show up.
Looks like they prepared for Bandwidth set as an option, and there is also a possible new option "Power Analysis" that I do not remember hearing about.


*
In case someone wonders: I can confirm that removing the options with :system:option:uninstall worked and it could be set again without problems (serial number stays and so on)


*
I tested several variants of the keys based on what Uup documented without finding anything new.
It still feels like the BW and new Power Analysis options should be just another Serial (Rigol help file uses this name for the key we enter. When I first found it thought it referred to setting the serial number of the unit)


*
I find 4 Xilinx bitstreams in the GEL file, the header info is consistent with the devices all being the same (ID string 02 86 E0 93 = XC5VLX30) where the LX30 is the smallest Virtex 5 device.
The use of Virtex 5 circuits explains the larger heat sinks compared to the DS2000, Virtex 5 are 65nm devices optimized for speed,speed and more speed (newer mind the power consumption and leakage).
Spartan 6 on the other hand are "45 nm process optimized for cost and low power", so assuming we are not running close to the max frequency the Spartan should run cooler. 
There are 5 FPGAs in the DS4000, so one pair should be getting the same config file, my guess is on the pair closest to the ADCs with the trace memory.

*
In Connor Wolfs teardown there is a lasered circuit just next to the Blackfin. If I look closely on mine I can see faintly the logo "Actel", if I compare wiring around this circuit it closely resembles the Actel that can be seen in Daves DS2000 teardown between the Coin battery and the Flash and referred to as glue logic.
In a block diagram I would expect this circuit to sit between the Blackfin bus and the rest of the system, it also could be that it is in charge of configuring the FPGAs since it looks to be directly linked to the Flash.
Nearby is the same programming connector, board version setting resistors, and in both cases the Flash is close to it. I would not be surprised if this circuits config would be the exact same in both models.

*
The fan is this one: Delta AFB1212L
It is the lowest rpm version in the AFB series, seems it should be possible to find a replacement that gets nearly the same flow and pressure with less noise, expecting a possible replacement in the mail tomorrow.
Actually I am a bit surprised the fan is so noisy when the datasheet says it should be 32dBA max at 1900rpm, subjectively it feels like it is over 40dBA.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tsmith35 on October 30, 2013, 10:05:06 pm
Quote
Just out of curiosity, where are the steps for generating keys? I remember seeing something about elliptical encryption, but not any step by step stuff.

Well, if you're only interested in generating these Rigol keys, then there is a command line utility to do that for you. However, if you are tying to learn the math behind the technology, I'd recommend you Google it.

I'd actually read through the elliptical cryptography stuff, but I was curious about locating the private keys and the basic stuff. I'm sure I read it somewhere in the 86 pages of the thread, but I have a short memory... :palm:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Co6aka on October 30, 2013, 10:38:33 pm
I wonder if the options screen on models above DS4014 says the option is enabled or if the model number just enables the right bandwidth.

FWIW, if I were going to code this firmware up, I would embed enabling of tiered features in the model number... Or perhaps in a separate semaphore field -- "tier" -- and then let the unit set the model number and tier-enabled features from it... Because if I was going to sell an "upgrade" then it would include a license key and a new sticker/badge/label/whatever for the face of the instrument.

So... Has anyone figured out where the model number is stored, and perhaps how to change it? I thought there was someone whose DS4000-series lost its mind/memory and "upgraded" itself to a higher tier model...?  (Or... have I been eating waaay too many doggie-biscuits?)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: echen1024 on October 31, 2013, 02:16:28 am
I wonder if the options screen on models above DS4014 says the option is enabled or if the model number just enables the right bandwidth.

FWIW, if I were going to code this firmware up, I would embed enabling of tiered features in the model number... Or perhaps in a separate semaphore field -- "tier" -- and then let the unit set the model number and tier-enabled features from it... Because if I was going to sell an "upgrade" then it would include a license key and a new sticker/badge/label/whatever for the face of the instrument.

So... Has anyone figured out where the model number is stored, and perhaps how to change it? I thought there was someone whose DS4000-series lost its mind/memory and "upgraded" itself to a higher tier model...?  (Or... have I been eating waaay too many doggie-biscuits?)

No, that happened. right here: https://www.eevblog.com/forum/reviews/rigol-ds4014-decided-it-would-be-more-fun-to-be-a-ds4054/ (https://www.eevblog.com/forum/reviews/rigol-ds4014-decided-it-would-be-more-fun-to-be-a-ds4054/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: apelly on October 31, 2013, 02:31:21 am
I hesitate to post this in case I look like a prat later, but I'm pretty confident now that Rigol have changed their private key for the DS2000A.

I've tried a couple of different keygens, all giving the same key, copied and pasted into  and... no worky.

I still haven't compared the firmware version of my DP832 to a known working version. If I do have a later version I might try downgrading. It would seem unlikely that they would change their private key on a current product though.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on October 31, 2013, 02:35:21 am
Did you send the key without the dashes if using scpi?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: apelly on October 31, 2013, 02:55:11 am
Did you send the key without the dashes if using scpi?
Yes
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on October 31, 2013, 03:18:51 am
It will definately work for the DP832 (at least). Try entering the code manually with the keypad on the device (as opposed to the remote commands from a computer)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on October 31, 2013, 12:24:00 pm
About the private key:
Cybernet: "I must admit I got the private key yesterday via mail from a guy"
Sources: https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg264855/#msg264855 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg264855/#msg264855)
               And pages from 30 to 33 of this topic.



We need something like this (fpga bitcoins miner):
(https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/?action=dlattach;attach=65375;image)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on October 31, 2013, 12:41:50 pm
Quote
We need something like this (fpga bitcoins miner):

Hahaha, what a douche-bag! I had a bitcoin miner programmed into my DEO-Nano baodr a while back, and it hashed out keys at 1/100th of the pace of my NVidia (CUDA-enabled) GPU. This guy just wasted a fortune on FPGA dev boards, as well as a room; and he's probably a virgin.

Has Butterfly-Labs ever shipped their ASIC bitcoin miners?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on October 31, 2013, 12:55:23 pm
Quote
We need something like this (fpga bitcoins miner):

Hahaha, what a douche-bag! I had a bitcoin miner programmed into my DEO-Nano baodr a while back, and it hashed out keys at 1/100th of the pace of my NVidia (CUDA-enabled) GPU. This guy just wasted a fortune on FPGA dev boards, as well as a room; and he's probably a virgin.

Has Butterfly-Labs ever shipped their ASIC bitcoin miners?
Well, I have to recognize that about this subject (bitcoins) I know little.
The previous picture I got from here:
http://www.joeydevilla.com/wordpress/wp-content/uploads/2013/04/bitcoin-fpga-mining-rig.jpg-.jpg (http://www.joeydevilla.com/wordpress/wp-content/uploads/2013/04/bitcoin-fpga-mining-rig.jpg-.jpg)

From what you say you are an expert on the subject. How much money do you get per day? I read that up to 130USD.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on October 31, 2013, 02:46:21 pm
Not an expert; not even close. However, I can assure you that the setup you showed below is not generating $130USD/day. Perhaps $20, but this number decreases each day, since bitcoins become more difficult to mine over time. I'm not saying his set-up wont pay for itself in time, just that he shouldn't give up his day job.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Co6aka on October 31, 2013, 06:22:59 pm
No, that happened. right here...

Well... From the second photo in that thread... The model number doesn't match the badge...

(http://i.imgur.com/FsMvvl.jpg) (http://i.imgur.com/FsMvv.jpg)

SO it looks to me like the model number (or tier/whatever) is set in a semaphore, which got changed/set/cleared... Which means it's held in some kind of FLASH/EEPROM... Which means it should be hackable.  >:D
 
Seems that what we need are dumps from two or more different models to compare the NV content.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: apelly on November 01, 2013, 03:27:24 am
Any luck?
No. But I haven't had time to fool around much.

I thought I'd try some of the lesser keys for the 2072 in case they just disabled the model hack.

Still no idea about the 832. You say the keys will definitely work yet this has not been my experience so far. I have tried direct entry and entry via scpi. Only tried direct entry once though and user error is quite likely this way I think.

Also, I haven't gone back to re-read the beginning of the thread, but I don't recall any specifics of how the private keys were originally discovered. If they have changed, and were chosen well, it seems unlikely they will be rediscovered quickly.

I have worked in software design and development for many years, so I am quite confident I am not doing anything stupid, but experience tells me I can not rule it out 100%

I will re-post this reply in the main thread in case it prompts any responses.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: apelly on November 01, 2013, 03:36:53 am
I hesitate to post this in case I look like a prat later, but I'm pretty confident now that Rigol have changed their private key for the DS2000A.

I've tried a couple of different keygens, all giving the same key, copied and pasted into  and... no worky.

I still haven't compared the firmware version of my DP832 to a known working version. If I do have a later version I might try downgrading. It would seem unlikely that they would change their private key on a current product though.
Yes. I do look like a prat. The keygen for the 832 is fine.

Any ideas why the scpi commands wouldn't work? No idea what I was trying before. The commands I just tried now were clearly not recognised. Direct entry on the device worked fine while awake and sober.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tsmith35 on November 01, 2013, 08:25:09 am
Yes. I do look like a prat. The keygen for the 832 is fine.

Any ideas why the scpi commands wouldn't work? No idea what I was trying before. The commands I just tried now were clearly not recognised. Direct entry on the device worked fine while awake and sober.
So the 832 seems to accept the keys, but the 2072A won't, huh?

apelly, don't be too hard on yourself. I learn a lot of stuff nearly everything by making mistakes. :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on November 01, 2013, 01:17:08 pm
Try it again, manually, on the DS2072A. When sober
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: apelly on November 01, 2013, 03:41:09 pm
Try it again, manually, on the DS2072A. When sober
  :D

Did that earlier. Also tried lesser keys. No joy.

Just rereading the first thousand or so posts in this thread for clues about the ECC keys. It starts to get interesting somewhere around post 400. There are some tips there about cracking tools. Looks like the firmware will be needed though and I don't have the gear to extract it. Also rediscovered LLLLLLL-RLGLLDS-DSA9LLL-LLLLLLL in cybernet's post. (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg253631/#msg253631) I'll give that a go later.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DL5TOR on November 01, 2013, 06:33:08 pm
Try it again, manually, on the DS2072A. When sober
  :D

Did that earlier. Also tried lesser keys. No joy.

Just rereading the first thousand or so posts in this thread for clues about the ECC keys. It starts to get interesting somewhere around post 400. There are some tips there about cracking tools. Looks like the firmware will be needed though and I don't have the gear to extract it. Also rediscovered LLLLLLL-RLGLLDS-DSA9LLL-LLLLLLL in cybernet's post. (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg253631/#msg253631) I'll give that a go later.

The way i see it is that the Private key is different. "all" that is neede is a FW dump via jtag and gdb the rest shuld be simple (as seen on the other devices)

so if someone can do a dump i am confident to help with the rest

73 de DL5TOR

Torsten
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tsmith35 on November 01, 2013, 06:37:26 pm
"all" that is neede is a FW dump via jtag and gdb the rest shuld be simple (as seen on the other devices)
Is there a walk-through of how to do this on a Rigol scope? May increase the likelihood of getting a dump. Curiosity for me.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on November 01, 2013, 07:25:55 pm
"all" that is neede is a FW dump via jtag and gdb the rest shuld be simple (as seen on the other devices)
Is there a walk-through of how to do this on a Rigol scope? May increase the likelihood of getting a dump. Curiosity for me.
Read this:
https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg298338/#msg298338 (https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg298338/#msg298338)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tsmith35 on November 01, 2013, 08:42:13 pm
Read this:
https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg298338/#msg298338 (https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg298338/#msg298338)
Thanks! Good material.

On the subject of a potential new private key, what about the possibility of using cloud resources (ala EC2 or similar) to recover the key?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: apelly on November 02, 2013, 12:20:29 am
rediscovered LLLLLLL-RLGLLDS-DSA9LLL-LLLLLLL in cybernet's post. (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg253631/#msg253631) I'll give that a go later.

Nope
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on November 02, 2013, 02:31:56 am
Read this:
https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg298338/#msg298338 (https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg298338/#msg298338)
Thanks! Good material.

On the subject of a potential new private key, what about the possibility of using cloud resources (ala EC2 or similar) to recover the key?
If it's the same as any other Rigol product...absolutely unnecessary.

Not to mention that wouldn't work anyway, mind.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on November 02, 2013, 03:10:25 am
Damn, that is depressing! I was all hyped and ready to buy a DS2072A too. The thought of 300MHz really got me hard.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DL5TOR on November 02, 2013, 07:12:10 am
Damn, that is depressing! I was all hyped and ready to buy a DS2072A too. The thought of 300MHz really got me hard.

no super-compiuter needed the keys for the DSA815 (same System different keys) was generated in 1h after the Firmware was dumped
Btw most of  the info on how to get the keys is in this thread

73 de DL5TOR
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on November 02, 2013, 11:30:36 am
If it's the same as any other Rigol product...absolutely unnecessary.
Not to mention that wouldn't work anyway, mind.
Please be more clear.
  - You mean that now is not so easy to discover the public key.
  - Or that make a dump is not necessary because the private key has not changed.
  -  :wtf:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jeremy on November 02, 2013, 11:53:39 am
If they have changed the key to be based on a prime (like they should have at the start...), then I don't believe it will be as easy as just dumping the firmware. The only reason this hack worked is because rigol picked a silly private key.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on November 02, 2013, 12:02:21 pm
If they have changed the key to be based on a prime (like they should have at the start...), then I don't believe it will be as easy as just dumping the firmware. The only reason this hack worked is because rigol picked a silly private key.
Yes, is very likely, but then the sales of this product will plummet. And more with the series SDS2000 just around the corner.
This is extremely suspicious, seems like they're handing the market. Now for you, now for my...  ???
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jeremy on November 02, 2013, 12:07:41 pm
If they have changed the key to be based on a prime (like they should have at the start...), then I don't believe it will be as easy as just dumping the firmware. The only reason this hack worked is because rigol picked a silly private key.
Yes, is very likely, but then the sales of this product will plummet.
Changing the key seems a bit silly if you still want people to hack it? Why not leave it the same?

They probably have a certain sales distribution of the models that they are trying to achieve to hit R&D payoff and profit goals (otherwise why release more expensive models which have the same hardware?). The naughty forum users around here (myself included) are ruining their forecasts  ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: willb on November 02, 2013, 12:11:16 pm
I just ordered a 2072 a few weeks ago and got a call that it came in yesterday. I'm going to pick it up on Monday. I have no idea if it's the A version though. I'm very anxious to see if the hack will work and what version I got!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on November 02, 2013, 12:26:18 pm
If they have changed the key to be based on a prime (like they should have at the start...), then I don't believe it will be as easy as just dumping the firmware. The only reason this hack worked is because rigol picked a silly private key.
Yes, is very likely, but then the sales of this product will plummet.
Changing the key seems a bit silly if you still want people to hack it? Why not leave it the same?

They probably have a certain sales distribution of the models that they are trying to achieve to hit R&D payoff and profit goals (otherwise why release more expensive models which have the same hardware?). The naughty forum users around here (myself included) are ruining their forecasts  ;)
I don't know if we are right about their intentions. But, I don't think that we are ruining their forecasts (not my intention).
And who knows, for now we just know that for a DS2072A (only one) the keygen not works.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on November 02, 2013, 04:10:07 pm
Quote
Changing the key seems a bit silly if you still want people to hack it? Why not leave it the same?

What makes you think Rigol wants us to hack their scopes? They don't! Trust me, the measly few sales they are getting from eevblog forum members buying their cheapest (least profit-per-sale) DSO is not going to even make a dent in their sales.

The bigger boost in their sales is from Dave and the others releasing positive reviews of the item. Dave reviewed the (unhacked) 200MHz model and said good things about it; the video is on Rigol's website as well as the product description sites of various vendors. Purchasing departments in fortune 500 companies are the ones who make Rigol the big money.

Essentially, I think Rigol is happy to provide a low cost DSO for hobbyists; however, that low cost DSO is their 70MHz version with nothing unlocked.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marshallh on November 02, 2013, 07:29:29 pm
Here's my Rigol experience:

1. Ordered 2072 from Tequipment with discount. Arrived timely, but DOA.

(http://img713.imageshack.us/img713/1157/3xj3.jpg)

Emailed Tequipment. They started a warranty claim(!) and provided Rigol's UPS label. I stuck a photo of the problem in the box.

6 weeks later, I receive out of nowhere the same Rigol cardboard box via Fedex. No email from Rigol or Tequipment.
SN was reset to 0000's and trial options removed (I had not hacked the scope)
However the scope seems to work properly now...


Let's do avalanche pulser comparison, before (70mhz labeled) and after (200mhz labeled) bandwiths.

(http://imageshack.us/a/img4/2739/64mx.png)

(http://imageshack.us/a/img10/2418/zpc5.png)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Dave Turner on November 02, 2013, 07:53:43 pm
Forgive me if I've missed it; this thread is so long that it is easy to miss and/or forget posts.

I seem to recall that the DS1074Z codes were suggested to be similar to the DS2000, but do not recollect whether any tests were made on the DS1074Z-S.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Co6aka on November 02, 2013, 09:31:45 pm
f they have changed the key to be based on a prime...

If the firmware itself can be patched, then it doesn't really matter what the key is. Also, in the process of "sniffing" around, did anyone figure out if they're just setting/clearing option flags somewhere in memory, based upon valid key detections at boot time?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jeremy on November 02, 2013, 11:34:31 pm
Quote
Changing the key seems a bit silly if you still want people to hack it? Why not leave it the same?

What makes you think Rigol wants us to hack their scopes? They don't!

Actually, that was my point  :-//

Modifying the firmware is an option, but it isn't what occurred here. iirc: firmware was dumped via jtag, crypto routines were reversed (and subsequently discovered to be MIRACL), silly private key derived, keygen written. None of this involved modifying the firmware.

Firmware mods are a different can of worms (easy to brick, checksum hunting is hard, no model info is stored in firmware updates, etc)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Sienna on November 03, 2013, 12:32:30 am
Just another confirmation.
I got a DP832 from Tequipment recently (I assume from the batch after the heatsink debacle).  Codes worked fine.

Thanks to everyone in the thread for their hard work!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: arvidj on November 03, 2013, 04:49:58 pm
Just another confirmation.
I got a DP832 from Tequipment recently (I assume from the batch after the heatsink debacle).  ...

I asked TEquipment about the DP832 before I ordered mine and their response was ...

Quote
All the DP800 models that are ordered after 10/14/13 have a newly designed board that solves the the over heating issue. Any ordered before that are in the process of being repaired.

So either way you appear to be covered with the only question being the hassle factor if yours needs to be repaired.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zener on November 03, 2013, 05:54:00 pm
Has the private key changed in the DSA815TG with firmware rev 00.01.06?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 03, 2013, 05:56:50 pm
Has the private key changed in the DSA815TG with firmware rev 00.01.06?
No, the same key still works with 00.01.06: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg311584/#msg311584 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg311584/#msg311584)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 03, 2013, 06:57:06 pm
Awesome work guys, finally made it all the way through this topic.

I'm trying to figure out this code table made by 'Uup' for DS4000:
I 've been experimenting with the option codes on my DS4024 and have worked out the various options. However, I was unable to change the model number/bandwidth.  :(  It appears as though it may be done via a different means, such as hardware jumpers or other hardware configuration bits. Not really sure at this point.

Attached, and below, is what I have worked out. I suspect that the only people who will really gain from this information are the dealers who will be able to work out their own option licence keys to sell to customers, instead of getting them from Rigol.   ::)

Anyhow... 

 
DS4000 Series DSO Option Codes:

Licence code string is in the following format:


LLLLLLL-RLGLLDS-****LLL-LLLLLLL
                ABCD


     A       B       C       D
   54321   54321   54321   54321

   x0000   00000   00000   00000   0 = Official, 1 = Trial
   0x000   00000   00000   00000   must = 0
   00x00   00000   00000   00000   See Note(2)
   000x0   00000   00000   00000   Option Bank Selection
   0000x   00000   00000   00000   Option Bank Selection

   00000   x0000   00000   00000   Licence re-application bit
   00000   0x000   00000   00000   must = 0
   00000   00x00   00000   00000   must = 0
   00000   000x0   00000   00000   must = 0
   00000   0000x   00000   00000   must = 0

   00000   00000   x0000   00000   must = 0
   00000   00000   0x000   00000   must = 0
   00000   00000   00x00   00000   See Note(2)
   00000   00000   000x0   00000   See Note(2)
   00000   00000   0000x   00000   See Note(2)

   00000   00000   00000   x0000   FlexRay Decode or alternate option
   00000   00000   00000   0x000   CAN Decode or alternate option
   00000   00000   00000   00x00   I2C Decode or alternate option
   00000   00000   00000   000x0   SPI Decode or alternate option
   00000   00000   00000   0000x   RS232 Decode or alternate option


More Detailed description of Bits:


A - Control Bits

1. Option bank selection: Available options =1 (if = 1 then A.2 should = 0)
2. Option bank selection: Alternate options =1 (if = 1 then A.1 should = 0)
3. See Note(2)
4. Must = 0
5. Trial = 1, See note(1) : Official = 0


B - Control Bits

1. Must = 0
2. Must = 0
3. Must = 0
4. Must = 0
5. Alternating bit allows re-installation of the same licence, without uninstalling it (indicates "Option Installed!")


C - Control Bits

1. See Note(2)
2. See Note(2)
3. See Note(2)
4. Must = 0
5. Must = 0


D - Options (0 = OFF, 1 = ON)

1. RS232 Decode
2. SPI Decode
3. I2C Decode
4. CAN Decode
5. FlexRay Decode

Alternate Options (when A.1 =0 && A.2 =1)

1. Reserved (Empty Option)
2. Reserved (Empty Option)
3. Reserved (Empty Option)
4. Reserved (Empty Option)
5. Reserved (Empty Option)

 
Notes:

(1) Re-applying the same trial licence will extend the trial time by an additional 1932 minutes to a maximum time of 5796 minutes.

(2) If any one of these bits are = 1, then re-applying the same licence will result in the error "Licence Unavailable!"
     If all of these bits are = 0, then re-applying the same licence will result in the message "The Option Has Been Installed!" or, in the case of a trial licence with maximum time reached, the message "Time Trial is Arrived!"
 

To work out the option code, use the following bit-to-code conversion table:

A = 00000
B = 00001
C = 00010
D = 00011
E = 00100
F = 00101
G = 00110
H = 00111
J = 01000
K = 01001
L = 01010
M = 01011
N = 01100
P = 01101
Q = 01110
R = 01111
S = 10000
T = 10001
U = 10010
V = 10011
W = 10100
X = 10101
Y = 10110
Z = 10111
2 = 11000
3 = 11001
4 = 11010
5 = 11011
6 = 11100
7 = 11101
8 = 11110
9 = 11111


Eg.

A) Option code to install SPI and FlexRay Decode Trial Options: 10001 00000 00000 10010 = T A A U
   LLLLLLL-RLGLLDS-TAAULLL-LLLLLLL

B) Option code to install all 5 official options: 00001 00000 00000 11111 = B A A 9
   LLLLLLL-RLGLLDS-BAA9LLL-LLLLLLL

 


Edit: use the above code you work out (eg. BAA9) along with your serial number and the private key to generate (eg. with RiKey) a license key. I only used the test key format above to indicate the placement of the code.


And compare the above table to this online key generator by 'studio25':
http://riglol.3owl.com/ (http://riglol.3owl.com/)

DS4000 device options:
first character: D = official, V = trial
DSHB - RS232 Decoder
DSHC - SPI Decoder
DSHE - I2C Decoder
DSHJ - CAN Decode
DSHS - FlexRay Decoder
DSA9 - all options
Can anyone explain why the 3rd letter for 'all options' isn't the same as for all the other options? [A vs. H]
Wouldn't DSH9 work to?


Trying to relate the 4 license letters back to the individual options in the table:

       A           B           C           D
   54321   54321   54321   54321

   x0000   00000   00000   00000   0 = Official, 1 = Trial
   0x000   00000   00000   00000   must = 0
   00x00   00000   00000   00000   See Note(2)
   000x0   00000   00000   00000   Option Bank Selection
   0000x   00000   00000   00000   Option Bank Selection
   00011 = D   [3rd digit = 0 means the 1st of 4 "Note(2)" bits = 0]

   00000   x0000   00000   00000   Licence re-application bit
   00000   0x000   00000   00000   must = 0
   00000   00x00   00000   00000   must = 0
   00000   000x0   00000   00000   must = 0
   00000   0000x   00000   00000   must = 0
                10000 = S

   00000   00000   x0000   00000   must = 0
   00000   00000   0x000   00000   must = 0
   00000   00000   00x00   00000   See Note(2)
   00000   00000   000x0   00000   See Note(2)
   00000   00000   0000x   00000   See Note(2)
                             00111 = H   [for the last 3 of 4 "Note(2)" bits = 111]
                         or 00000 = A   [for the last 3 of 4 "Note(2)" bits = 000]

   00000   00000   00000   x0000   FlexRay Decode or alternate option
   00000   00000   00000   0x000   CAN Decode or alternate option
   00000   00000   00000   00x00   I2C Decode or alternate option
   00000   00000   00000   000x0   SPI Decode or alternate option
   00000   00000   00000   0000x   RS232 Decode or alternate option
                                          11111 = 9   [for all 5 options selected]


DSH9 / DSA9


A vs. H changes 3 out of four bits in the "Note(2)":
(2) If any one of these bits are = 1, then re-applying the same licence will result in the error "Licence Unavailable!"
     If all of these bits are = 0, then re-applying the same licence will result in the message "The Option Has Been Installed!" or, in the case of a trial licence with maximum time reached, the message "Time Trial is Arrived!"
D as the 1st letter means the 1st of 4 "Note(2)" bits is always = 0.

H as the 3rd letter means the last 3 of 4 "Note(2)" bits are always = 111. [All 4 "Note(2)" bits combined = 0111].
A as the 3rd letter means the last 3 of 4 "Note(2)" bits are always = 000. [All 4 "Note(2)" bits combined = 0000].
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jsykes on November 04, 2013, 06:18:17 am
Has the private key changed in the DSA815TG with firmware rev 00.01.06?
No, the same key still works with 00.01.06: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg311584/#msg311584 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg311584/#msg311584)

 
Has anyone tried the latest DSA815 firmware 00.01.07 with the same private key ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dr.diesel on November 04, 2013, 10:57:54 am
Has anyone tried the latest DSA815 firmware 00.01.07 with the same private key ?

Yup, works just fine.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on November 04, 2013, 05:07:08 pm
...

Can anyone explain why the 3rd letter for 'DS4000 all options' on http://riglol.3owl.com/ (http://riglol.3owl.com/) isn't the same as for all the other options? [A vs. H]
Wouldn't DSH9 work to?
...

My mistake. Has just been corrected.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 04, 2013, 09:53:08 pm
...

Can anyone explain why the 3rd letter for 'DS4000 all options' on http://riglol.3owl.com/ (http://riglol.3owl.com/) isn't the same as for all the other options? [A vs. H]
Wouldn't DSH9 work to?
...

My mistake. Has just been corrected.
I notice the 500µV option for DS1000z has a different 3rd letter than the other options too.
Is this a mistake too or is it supposed to be this way?
Can't recall if there's a code table for DS1000z earlier in this topic similar to the on above for DS4000? I think I've missed it if there is.

Quote
DS1000z device options:
DSAB - Advanced Triggers
DSAC - Decoders
DSAE - 24M Memory
DSAJ - Recorder
DSBA - 500uV Vertical
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on November 04, 2013, 11:31:02 pm
Has anyone tried the latest DSA815 firmware 00.01.07 with the same private key ?
Yup, works just fine.

My DSA815TG with Firmware 00.01.07 is also happy with the generated license keys.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jsykes on November 05, 2013, 12:27:52 am
Has anyone tried the latest DSA815 firmware 00.01.07 with the same private key ?
Yup, works just fine.

My DSA815TG with Firmware 00.01.07 is also happy with the generated license keys.

Thanks, Dr Diesel & Hammy. Now I can update to 00.01.07 with confidence before implementing the keys.
Title: Sniffing the Rigol's internal I2C bus
Post by: Rory on November 05, 2013, 12:32:40 am

Has anyone tried the latest DSA815 firmware 00.01.07 with the same private key ?
Yup, works just fine.

My DSA815TG with Firmware 00.01.07 is also happy with the generated license keys.

Thanks, Dr Diesel & Hammy. Now I can update to 00.01.07 with confidence before implementing the keys.
Just remember, once you implement the keys on a DSA815-TG, they can't be undone.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: van-c on November 06, 2013, 12:13:31 am
My new DS2072 was delivered from TEquipment today.  It has FW version 0.01.01.00.02 and hardware 1.0.2.0.0.  I haven't tried the keygen or any Ultra Sigma commands yet since I want to become reasonably familiar with basic operation first.  TE had 46 units of DS2072 in stock today, down from 50 yesterday.  They probably won't last very long.

--Van
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: willb on November 06, 2013, 12:15:15 am
I got my 2072 yesterday as well, and I have it already fully unlocked!!!! Thanks so much to all the contributors.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: van-c on November 06, 2013, 01:41:04 am
I got my 2072 yesterday as well, and I have it already fully unlocked!!!! Thanks so much to all the contributors.
Which keygen and parameters did you use?  Have you checked if it uninstalls without issue?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: backflipper on November 06, 2013, 12:04:21 pm
Great work people!

I was wondering if anyone has tried working on the mixed signal oscilloscopes.

Is it possible to unlock all the features on say a ds1052d to become a ds1102d?

This thread is a great read!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dr.diesel on November 06, 2013, 12:09:53 pm

I was wondering if anyone has tried working on the mixed signal oscilloscopes.

Nobody has one yet that I know of.  Mine is scheduled to ship the 11th of this month, we'll know soon enough!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on November 06, 2013, 04:06:59 pm
Is it possible to unlock all the features on say a ds1052d to become a ds1102d?

The DS1052D does not have any locked 'features' - it's an older Rigol product from several years back (and soon to be phased-out by Rigol, I suspect). The thread investigation (and subsequent keygen(s)) is focused on the new Rigol products introduced within the last two years which have purchasable upgrade options - beginning with the DS4000 series.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 06, 2013, 07:48:36 pm
Great work people!

I was wondering if anyone has tried working on the mixed signal oscilloscopes.

Is it possible to unlock all the features on say a ds1052d to become a ds1102d?

This thread is a great read!
Check this topic on how to upgrade the old DS1052D to DS1102D (and DS1052E to DS1102E): https://www.eevblog.com/forum/blog/changing-the-rigol-ds1052e-to-ds1102e-using-usb-the-dummy-guide/ (https://www.eevblog.com/forum/blog/changing-the-rigol-ds1052e-to-ds1102e-using-usb-the-dummy-guide/)
Quote
* To change an DS1052D (the model with Logic Analyser) into an 1102D the steps should be just the same, the serial number however should be changed from DS1ECxxxxxx (1052D model) to DS1EAxxxxxx (1102D model) See here.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bobn4burton on November 06, 2013, 09:09:51 pm
Is there a post number or web page that has a step-by-step procedure with the most up-to-date instructions to unlock the DS2072 (geared toward a newbie)?

The best I've found so far is here:
http://freneticrapport.blogspot.com/2013/07/raspberry-pi-rigol-ds2072-200mhz.html (http://freneticrapport.blogspot.com/2013/07/raspberry-pi-rigol-ds2072-200mhz.html)

But it was posted/updated way back in July...so not sure if there is something better since then...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 06, 2013, 11:32:06 pm
Is there a post number or web page that has a step-by-step procedure with the most up-to-date instructions to unlock the DS2072 (geared toward a newbie)?

The best I've found so far is here:
http://freneticrapport.blogspot.com/2013/07/raspberry-pi-rigol-ds2072-200mhz.html (http://freneticrapport.blogspot.com/2013/07/raspberry-pi-rigol-ds2072-200mhz.html)

But it was posted/updated way back in July...so not sure if there is something better since then...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bobn4burton on November 06, 2013, 11:52:41 pm
Thanks AndersAnd!!

Even easier than I thought it would be...man, really can't wait for my scope to arrive now...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: willb on November 07, 2013, 12:24:24 am
I got my 2072 yesterday as well, and I have it already fully unlocked!!!! Thanks so much to all the contributors.
Which keygen and parameters did you use?  Have you checked if it uninstalls without issue?

I just used studio25's web generator and generated a key for all options. I didn't check to see if they uninstall, cause I don't ever intend to remove these sweet options.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Giggy on November 07, 2013, 03:22:12 am
Hey folks,
Ordered a new rigol ds2072 the other day, spoke to the distributer and apparently it is the A model,
Here's hoping there's a way to hack this new version.

I need to read through this thread to get the procedure and i'll attempt that.

Is this cybernet guy still around?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 07, 2013, 03:27:00 am
Is this cybernet guy still around?
He was at the forum 3½ hours ago as you can see on his profile: https://www.eevblog.com/forum/profile/?u=27189 (https://www.eevblog.com/forum/profile/?u=27189)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on November 07, 2013, 04:39:38 am
Ordered a new rigol ds2072 the other day, spoke to the distributer and apparently it is the A model,
Here's hoping there's a way to hack this new version.

Well, one thing the new A models are advertised to have, which the non-A's lack (at the moment) is a CAN-protocol option.  That's something I'd like to see, since I use it every day.

Possibly there will be a firmware update for the non-A's that makes CAN available there as well, but there's no guarantee.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bobn4burton on November 07, 2013, 05:39:09 pm
So is there no model distinction between the normal DS2072 or the A version?  I had seen it written as DS2072A and figured it would be separate model number.

But I don't see a DS2072A version listed on Rigol's web site, just the DS2072.  So is the A version just a newer hardware version that is still being sold as the DS2072?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 07, 2013, 08:29:54 pm
But I don't see a DS2072A version listed on Rigol's web site, just the DS2072.
Maybe you are looking at Rigol North America's website http://www.rigolna.com (http://www.rigolna.com) or Rigol Europe's website: http://www.eu.rigolna.com (http://www.eu.rigolna.com)

DS2000A is not listed there yet so, switch to the international Rigol website in the top right corner. http://www.rigol.com (http://www.rigol.com) and you will see both a DS2000 series + a Series DS2000A listed.
DS2000: http://www.rigol.com/prodserv/DS2000 (http://www.rigol.com/prodserv/DS2000)
DS2000A: http://www.rigol.com/prodserv/DS2000A (http://www.rigol.com/prodserv/DS2000A)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: iNoxxam on November 08, 2013, 12:12:00 am
Ordered a new rigol ds2072 the other day, spoke to the distributer and apparently it is the A model,
Here's hoping there's a way to hack this new version.

Well, one thing the new A models are advertised to have, which the non-A's lack (at the moment) is a CAN-protocol option.  That's something I'd like to see, since I use it every day.

Possibly there will be a firmware update for the non-A's that makes CAN available there as well, but there's no guarantee.

If not maybe the A model's firmware will be hacked and it'll be possible to use it on non A models.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: evanh on November 08, 2013, 10:18:53 am
Having read none of this topic other than instructions for compiling rigolkey, I'll make a preliminary comment on the DS1000Z's.  I've not been able to get the rigolkey program to generate a usable licence key for my DS1000Z.  Also, my private key is not suitable as it is 16 characters long rather than the 14 for the DS2000's.

I've since successfully used this 16 character private key with Rigol's licence key generator webpage and applied it to my DS1000Z.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tsmith35 on November 08, 2013, 03:06:44 pm

I was wondering if anyone has tried working on the mixed signal oscilloscopes.

Nobody has one yet that I know of.  Mine is scheduled to ship the 11th of this month, we'll know soon enough!
Has it arrived yet? :D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 08, 2013, 04:57:24 pm
Also, my private key is not suitable as it is 16 characters long rather than the 14 for the DS2000's.

I've since successfully used this 16 character private key with Rigol's licence key generator webpage and applied it to my DS1000Z.
What do you mean your private key is longer? Or are you actually talking about your serial number? That's not the same as the private key.
The private key is the same for every DS1000Z.

You can find the 4 different private keys for DP832, DS2000, DSA815 and DS1000Z respectively in riglol.c available in riglol.zip at the bottom of this website http://riglol.3owl.com (http://riglol.3owl.com)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Dave Turner on November 08, 2013, 08:02:32 pm
I have searched this forum for 00.02.00.SP1 which is the software version on my DS1074Z-S to no avail. Has anyone looked at this firmware?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: evanh on November 08, 2013, 08:30:54 pm
What do you mean your private key is longer? Or are you actually talking about your serial number? That's not the same as the private key.
The private key is the same for every DS1000Z.

You can find the 4 different private keys for DP832, DS2000, DSA815 and DS1000Z respectively in riglol.c available in riglol.zip at the bottom of this website http://riglol.3owl.com (http://riglol.3owl.com)

Ah, thanks for the info.  I now realise I'd assumed the product key was the same thing.  I'd just received a product key from Rigol for enabling a feature on my scope.

I also noticed last night riglol is not quite the same as rigolkey ...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 08, 2013, 09:19:36 pm
I also noticed last night riglol is not quite the same as rigolkey ...
Use http://riglol.3owl.com (http://riglol.3owl.com) following the step-by-step guide I wrote here: https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg324768/#msg324768 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg324768/#msg324768)

I think studio25's RigLOL is the only version still maintained. It's also easy to use as you don't need to compile or install anything. As it runs in a web-browser it works on any platform, so you don't have to maintain different versions for Linux, Windows, OS X, Android or whatever.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: seronday on November 08, 2013, 10:00:58 pm

The keys generated by  RiGen.exe   and    riglol.exe,    have both worked successfully in my new DS1074Z to permanently enable all of the options.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dougr on November 08, 2013, 10:21:42 pm
Have not seen that the ds1074z gets 100MHz BW increase with the hack... Is that a TBD at this point, an unknown, or a HW difference?  Weighing options between 1000z-s and 2000a-s.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: evanh on November 08, 2013, 10:24:16 pm
Riglol worked for me.  My scope now has one official key plus one cracked key.

Interestingly, they are totally different code sequences which doesn't seem surprising, I guess, except that all the cracked keys have the same character sequence for the first half of the key code.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: evanh on November 08, 2013, 11:10:57 pm
Have not seen that the ds1074z gets 100MHz BW increase with the hack... Is that a TBD at this point, an unknown, or a HW difference?  Weighing options between 1000z-s and 2000a-s.

I'm gonna guess it's to be discovered.  The diff between 70 and 100 is too small to have different hardware for each, especially given Rigol's history in this area.

Four channels makes a huge diff over two when comparing timings.  My uses cover from signal integrity to both analogue and digital data logging with the occasional bit of high speed logic.  I use it as the jack of all trades.  I've had four channels since 2002, I could never go back.  I was drooling over an eight channel DSO back then but that was way, way, way out of my price bracket.

I purchased the DS1074Z-S, because it's a tenth of the price of what I already have, and to see if it lives up to it's specs and hopefully be able to recommend it.  And I do highly recommend it.

I suspect there will eventually be a four channel DS2000.  But how long can you wait?


I've continued my ramblings about the DS1000Z back in the quick look topic - https://www.eevblog.com/forum/blog/eevblog-522-rigol-ds1000z-oscilloscope-quick-look/msg326311/#msg326311 (https://www.eevblog.com/forum/blog/eevblog-522-rigol-ds1000z-oscilloscope-quick-look/msg326311/#msg326311)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Co6aka on November 09, 2013, 01:39:16 am
Use http://riglol.3owl.com (http://riglol.3owl.com) following the step-by-step guide...

FWIW, seems that site/page is QRT. ("Off the air.")
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Tabs on November 09, 2013, 02:36:05 am
But I don't see a DS2072A version listed on Rigol's web site, just the DS2072.
Maybe you are looking at Rigol North America's website http://www.rigolna.com (http://www.rigolna.com) or Rigol Europe's website: http://www.eu.rigolna.com (http://www.eu.rigolna.com)

DS2000A is not listed there yet so, switch to the international Rigol website in the top right corner. http://www.rigol.com (http://www.rigol.com) and you will see both a DS2000 series + a Series DS2000A listed.
DS2000: http://www.rigol.com/prodserv/DS2000 (http://www.rigol.com/prodserv/DS2000)
DS2000A: http://www.rigol.com/prodserv/DS2000A (http://www.rigol.com/prodserv/DS2000A)

DS2000: http://www.rigol.com/prodserv/DS2000 (http://www.rigol.com/prodserv/DS2000) This link still works but it can not be accessed from the international home page. It seems all links to DS2000 series have been replaced with DS2000A series. This was not case when I looked 2 days ago.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 09, 2013, 02:44:58 am
But I don't see a DS2072A version listed on Rigol's web site, just the DS2072.
Maybe you are looking at Rigol North America's website http://www.rigolna.com (http://www.rigolna.com) or Rigol Europe's website: http://www.eu.rigolna.com (http://www.eu.rigolna.com)

DS2000A is not listed there yet so, switch to the international Rigol website in the top right corner. http://www.rigol.com (http://www.rigol.com) and you will see both a DS2000 series + a Series DS2000A listed.
DS2000: http://www.rigol.com/prodserv/DS2000 (http://www.rigol.com/prodserv/DS2000)
DS2000A: http://www.rigol.com/prodserv/DS2000A (http://www.rigol.com/prodserv/DS2000A)

DS2000: http://www.rigol.com/prodserv/DS2000 (http://www.rigol.com/prodserv/DS2000) This link still works but it can not be accessed from the international home page. It seems all links to DS2000 series have been replaced with DS2000A series. This was not case when I looked 2 days ago.
Both sites still works just fine for me if I use the direct links and shows two different websites, when I select "International" in the top right corner at http://www.rigol.com (http://www.rigol.com).

However the at the DS2000A there's an "Ordering Information" table near the bottom of the page.
This "Ordering Information" table has disappeared from the DS2000 site and the DS2000 link has also disappeared from the drop down menu at the top under Products -> Digial Oscilloscopes.
So you can probably only order the DS2000A model now, once DS2000 stock runs out at dealers.


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 09, 2013, 02:48:01 am
Use http://riglol.3owl.com (http://riglol.3owl.com) following the step-by-step guide...

FWIW, seems that site/page is QRT. ("Off the air.")
Yes, just noticed this. Worked fine some hours ago when I made my post.
Any idea why the site has been taken down? Is it Rigol who has asked 3owl to remove it, or is it taken down by studio25, maybe for an update?
The site just says this now:
Quote
(http://3owl.com/landing/logo.png)

We at 3owl.com offer 100% Free Php Web Hosting. Unlimited Disk and Bandwidth.
Click Signup Now to Get Started!
It says free unlimited bandwidth, so I guess it's not because of too much traffic that it's not available anymore.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Co6aka on November 09, 2013, 04:02:35 am
The Dynasty strikes back...?   :-//
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Co6aka on November 09, 2013, 04:10:55 am
For whatever it's worth... Today I stumbled over the following bit of info:

Supposedly, for the DSA1000-series, the service menu is accessed by pressing: Frequency, Span, Amplitude, Trigger, Bandwidth, Sweep, Single, Continue, Trigger, Trigger. (Whew! Like it's some kind of national secret in there!)

Wondering if it's the same or similar for the DSA8-series...?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: evanh on November 09, 2013, 04:27:17 am
Hehe, a bit more than your average PIN.  I guess the question also falls to all the Rigol equipment.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Co6aka on November 09, 2013, 04:48:07 am
The obsession with "secrecy" smacks of the good ol' cold-war days...   :--   Heck, I'd publish the access sequences and hope to make a mint re-aligning and re-calibrating all the instruments the diddle-dummies mangle!  >:D  Unless of course I was getting a nice kickback from the cal labs. (But then the cal labs wouldn't be telling fellow techies the access sequences...  :-// I dunno...)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 09, 2013, 03:46:44 pm
http://riglol.3owl.com (http://riglol.3owl.com) is online again. Not sure why it was down.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on November 09, 2013, 04:08:49 pm
http://riglol.3owl.com (http://riglol.3owl.com) is online again. Not sure why it was down.

DDOS attack (IP Nullrouted)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Co6aka on November 09, 2013, 06:04:25 pm
DDOS attack (IP Nullrouted)

I smell Chop Phooey! (From "#1 Chinese Kitchen")  :box:

Anyway...

Been looking at other stuff from other places and, unless my doggie-nose has lost the scent trail, am wondering if license codes for the same feature in different versions DS4000-series scopes (DS4014 vs. DS4054 for example) are the same? Also, along the same line, why are the "critical letters" in license codes for different models different, if the option bits are just the lowest order bits? ("MWxx" for DP832, "DSA/Bx" for DS1&2-series, "DSHx" for DS4-series, "AAAx" for DSA8-series.)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: excapealex on November 10, 2013, 10:24:31 am
Hello,
I'm new to the forum.
I wanted to buy a Rigol oscilloscope and I'm curious to know if the DSAZ option of the trick works or can work also on the new DS2072A-S with 2 Ch waveform generator ;)

Someone has already done a test?

Thank you and congratulations for the work you have done. :clap:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Reboot on November 11, 2013, 04:07:28 am
After watching Dave's and marmad's videos of the DS2000 series scopes, i'm pretty much blown away by what it can do.  I have used my trusty Tek TDS3034 scope for years and I like it very much, but it is looking downright crusty compared to Rigol's offering.  The "must have a new one" feature of the rigol is its waveform capture and deep memory, the Tek just doesn't cut it for capturing intermittent problems.

I ordered a DS2072 from Tequipment today, and can't wait to get it.  I wish they made it in 4 channel form, as that is quite useful to me.  I looked at the 4000 series, but it is quite a bit more for the same features really, and I like the front panel layout of the 2000 much better.

I think the lower bandwidth may be a limitation with some of the stuff I do, but I still will have my tek for that...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Dave Turner on November 11, 2013, 11:48:57 pm
On the DS1000Z series has anyone checked to see whether the 500uV range is actually useable after being activated?
 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rory on November 12, 2013, 03:49:07 am
After watching Dave's and marmad's videos of the DS2000 series scopes, i'm pretty much blown away by what it can do.  I have used my trusty Tek TDS3034 scope for years and I like it very much, but it is looking downright crusty compared to Rigol's offering.  The "must have a new one" feature of the rigol is its waveform capture and deep memory, the Tek just doesn't cut it for capturing intermittent problems.

I ordered a DS2072 from Tequipment today, and can't wait to get it.  I wish they made it in 4 channel form, as that is quite useful to me.  I looked at the 4000 series, but it is quite a bit more for the same features really, and I like the front panel layout of the 2000 much better.

I think the lower bandwidth may be a limitation with some of the stuff I do, but I still will have my tek for that...
Are you aware the bandwidth can be increased to 200 MHz among many other options with a simple license key entry? (Hint: read the entire thread here...)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Reboot on November 12, 2013, 04:59:39 am
I have read the entire post(https://www.eevblog.com/forum/Smileys/default/wink.gif)

I'm hoping that I can eventually get the CAN decoding on it as well since it doesn't seem to be a hardware change with the scope.  I have another solution for logging CAN traffic, but having it on the scope as well would be great for initial test of new board designs.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: excapealex on November 12, 2013, 06:57:35 am
Hello,
I'm new to the forum.
I wanted to buy a Rigol oscilloscope and I'm curious to know if the DSAZ option of the trick works or can work also on the new DS2072A-S with 2 Ch waveform generator ;)

Someone has already done a test?

Thank you and congratulations for the work you have done. :clap:

I have read all the posts and threads about it, if I understand it, since the modification for the DS2072 seems to work also on the DS2072A, I think there is good chance that it works also on the DS2072A-S (I just hope that with the version of fw mounted, able to handle even the components for the generation of signals that is missing on other models, they do not have locked the trick).

I said well or you think I'm wrong?

I want an oscilloscope for small home projects, and I would also buy a simple function generator (if possible also  arbitrary), the DS2072A-S has them both.. But the thing that interests me most of all is the possibility to decode serial signals.

Your suggestion is not to take risks and take two separate, a DS2072 and a function generator or groped quietly with the DS2072A-S?

Thanks in advance and sorry for my bad English!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 12, 2013, 03:29:09 pm
I have read the entire post(https://www.eevblog.com/forum/Smileys/default/wink.gif)

I'm hoping that I can eventually get the CAN decoding on it as well since it doesn't seem to be a hardware change with the scope.  I have another solution for logging CAN traffic, but having it on the scope as well would be great for initial test of new board designs.
Wouldn't it be better to cancel the order then and wait for a DS2072A instead? Especially since you already have another scope to use while waiting.
DS2072A comes with CAN from the factory and there's also a 300 MHz version called DS2302A, so you might be able to upgrade to 300 MHz, like the BW of you TEK scope.
There's still no known way to add CAN decoding to the non A DS2000's.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on November 12, 2013, 03:47:41 pm
I have read all the posts and threads about it, if I understand it, since the modification for the DS2072 seems to work also on the DS2072A,

I've seen no confirmation of that anywhere.  Precisely the opposite, in fact.

Quote
I want an oscilloscope for small home projects, and I would also buy a simple function generator (if possible also  arbitrary), the DS2072A-S has them both.. But the thing that interests me most of all is the possibility to decode serial signals.

In that case, get the DS1074Z-S... it's a no-brainer.  Cheaper than the DS2072A-S will be, available immediately, and known to work with the keygens.  Way more than enough capability for "small home projects".  The only constraint I'd mention there would be that if CAN protocol decoding is important to you, the 1074Z-S won't have it, and the 2072A-S will.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on November 12, 2013, 04:01:57 pm
The only constraint I'd mention there would be that if CAN protocol decoding is important to you, the 1074Z-S won't have it, and the 2072A-S will.
For me both, CAN and LIN are important. I have a DS2072. And I'm sure that RIGOL can tune the firmware to be more competitive.
For example: Why not add more features?
We are requesting it, and we are the customer, and if another manufacturer gives more for less, then...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on November 12, 2013, 04:04:39 pm
There's still no known way to add CAN decoding to the non A DS2000's.

I'd also add that while several folks have concluded that since the CAN protocol decoder is "just software" that they'll be able to load the 2072A firmware into their 2072 non-A, and get it that way.  So no biggie.

That may well be true.  However, it's also entirely possible that firmware releases for the 2000A family will be separate from and incompatible with the 2000-series.  Thus no CAN for the 2000-nonA owners.  :(

[And to anticipate those who might say there's no way Rigol would ever do something like this, I have to tell you, they already have.  :o 

Back when the 1000C family was popular, it had a number of problems with it's firmware, which Rigol promised to fix.  Eventually they brought out the also popular 1000E-series, which was essentially the same device with a few tweaks to the hardware (added 1GHz sampling into its short buffer).  And its firmware DID fix those problems.  Unfortunately it could not be loaded into the 1000C-series, and those folks never did get any of the promised fixes to the acknowledged problems with their firmware.  (The Rigol service manager in China who posted those promises did however return to that forum where the public comments were made, and replaced them all to say "hello".   :clap:)

So, the moral is: don't count on something just because you think it would be reasonable.]
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on November 12, 2013, 04:12:24 pm
For me both, CAN and LIN are important.

No argument there.

Quote
I have a DS2072. And I'm sure that RIGOL can tune the firmware to be more competitive.

I'm sure they could too.

Quote
For example: Why not add more features?

Why waste time adding features to yesterday's model, when you have a bright shiny new model you're trying to sell?   :-//

I wouldn't be surprised if once the 2000A-series becomes widely available, we never see anything more than bug-fix releases for the non-A 2000's.  Heck, when was the last time there was even a bug-fix release from Rigol for the DS2000-family?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Reboot on November 12, 2013, 04:16:41 pm
Agree with Mark_O's last posts 100%.  This is why I didn't wait for the "A" model, the scope's functionality is there for what I need minus the CAN decoding.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on November 12, 2013, 04:25:51 pm
Quote
For example: Why not add more features?
Why waste time adding features to yesterday's model, when you have a bright shiny new model you're trying to sell?   :-//
Furthermore, we can not complain, because we have more functionality than we paid. But of course we always want more...

I wouldn't be surprised if once the 2000A-series becomes widely available, we never see anything more than bug-fix releases for the non-A 2000's.  Heck, when was the last time there was even a bug-fix release from Rigol for the DS2000-family?
I suppose they're at it:
https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684 (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684)

By the way, we must thank the great job of Marmad.  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on November 12, 2013, 06:10:35 pm
...when was the last time there was even a bug-fix release from Rigol for the DS2000-family?
I suppose they're at it:
https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684 (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684)
I haven't been following it, but it looks like the last DS2000 update was about 5 months ago... released some time in June, and announced here on July 2.  (00.01.01.00.02).  But AFAICT, there are still some unresolved issues pending?

Quote
By the way, we must thank the great job of Marmad.  :-+
No doubt about that.   :-+ :-+  Mark's done a fabulous job.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on November 12, 2013, 06:54:02 pm
Looking into the latest(?) update .GEL file (00.01.01.00.02) for the DS2000 series, I think the CAN decoder is already present and we just need to find the right bit to enable it:

Press this key or turn the Function knob to setup the CAN trigger's Speed as10kb/s, 20kb/s, 33.3kb/s, 50kb/s, 62.5kb/s, 83.3kb/s, 100kb/s, 125kb/s, 250kb/s, 500kb/s, 800kb/s, 1Mb/s or user.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on November 12, 2013, 07:03:26 pm
Looking into the latest(?) update .GEL file (00.01.01.00.02) for the DS2000 series, I think the CAN decoder is already present and we just need to find the right bit to enable it:

Press this key or turn the Function knob to setup the CAN trigger's Speed as10kb/s, 20kb/s, 33.3kb/s, 50kb/s, 62.5kb/s, 83.3kb/s, 100kb/s, 125kb/s, 250kb/s, 500kb/s, 800kb/s, 1Mb/s or user.

That would be pretty slick if it's been there all along (at least the last 5 months).  :)  As you say, the trick is figuring out how to enable it.  I probably would have bought a 2072 several months ago, if I could have turned CAN on.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on November 12, 2013, 07:39:28 pm
The Saleae Logic has CAN decoding and is pretty freaking cheap.  Not as cheap as a free firmware upgrade or a hack, but cheaper than a new scope by quite a bit.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on November 12, 2013, 10:01:20 pm
The Saleae Logic has CAN decoding and is pretty freaking cheap.

True.  So does the USBee SX, which decodes CAN just fine, and is even cheaper, since I already own one.  ;)

Quote
Not as cheap as a free firmware upgrade or a hack, but cheaper than a new scope by quite a bit.

Also correct.  However, both provide access to the stream only in the Logic domain.  Unlike the DSO, which would also allow the signal to be viewed in the Voltage domain as well, and at the same time.  I would never buy a DSO exclusively for this, but a DS2072 with simultaneous CAN decode (combined with segment-based recording on bus error conditions) would be enough of a value-add to interest me.  That's all I was saying.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sprocket on November 14, 2013, 08:47:11 am
yay.. Just got my brand spanking new Rigol DS2072 yesterday, all options unlocked with no problems. So I would like to say thanks to all the guys that put in alot of work to sniff out the codes and making key gens. If I ever run in to one of you guys I'll definitelyy buy you a couple of rounds of beers.  O0 O0
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on November 14, 2013, 02:38:17 pm
The Saleae Logic has CAN decoding and is pretty freaking cheap.

True.  So does the USBee SX, which decodes CAN just fine, and is even cheaper, since I already own one.  ;)

I had not heard of that one... The software looks much nicer than the Saleae software. 

Quote
Not as cheap as a free firmware upgrade or a hack, but cheaper than a new scope by quite a bit.

Also correct.  However, both provide access to the stream only in the Logic domain.

Excellent point; I'd not thought of that.  Thank you.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 14, 2013, 03:03:28 pm
The Saleae Logic has CAN decoding and is pretty freaking cheap.

True.  So does the USBee SX, which decodes CAN just fine, and is even cheaper, since I already own one.  ;)
I had not heard of that one... The software looks much nicer than the Saleae software.
It's basically identical hardware for Saleae and USBee.
To make hardware from one of the two companies compatible with software from the other you just need to change the VID/PID in the external EEPROM.
Or you can make a device compatible with more than one software package by adding an extra EEPROM.
Or buy a $10 clone on eBay or AliExpress that's already compatible with one or both software packages.
Read here: https://www.eevblog.com/forum/testgear/rigol-new-dg1062z-vs-dg4062/msg326674/#msg326674 (https://www.eevblog.com/forum/testgear/rigol-new-dg1062z-vs-dg4062/msg326674/#msg326674)
There's also open source LA software and firmware for these devices at Sigrok: http://sigrok.org (http://sigrok.org)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: N2tl on November 14, 2013, 04:38:55 pm
Can you report the hardware level and firmware on your new DS2072?
Would be helpful to a continuing assessment of the keygen...
Also, can you confirm that your unit is a DS2072, and not a DS2072A?

Bruce
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sprocket on November 14, 2013, 07:47:44 pm

I can see you're from Denmark too. Did you buy your Rigol in Denmark, or maybe from Germany?

I bought it from batronix in germany, the only reputable distributor that dont rip you off that I have come across. RS and farnell are too expensive, and you need a CVR number to buy from them, and then there is the swedish based "instrumentcenter.se" they are a good 30% more expensive if I recall, and I gave up on UK based as they either want you to contact them for qoutes or the prices are pretty stupid high. Last I tríed to get some thing from the UK was a electronic DC load, after VAT and such, it was twice the price if I imported it directly from the manufacture in china, thats with shipping,import tax and VAT. 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: manzini on November 14, 2013, 08:21:06 pm
I bought it from batronix in germany, the only reputable distributor that dont rip you off....

I bought it from silcon.cz ... very very happy, I think also very reputable and they don't rip you off.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JDubU on November 14, 2013, 09:06:45 pm
I bought it from batronix in germany, the only reputable distributor that dont rip you off that I have come across. RS and farnell are too expensive, and you need a CVR number to buy from them, and then there is the swedish based "instrumentcenter.se" they are a good 30% more expensive if I recall, and I gave up on UK based as they either want you to contact them for qoutes or the prices are pretty stupid high. Last I tríed to get some thing from the UK was a electronic DC load, after VAT and such, it was twice the price if I imported it directly from the manufacture in china, thats with shipping,import tax and VAT.


In the US, I have found TEquipment to be very good and they give a discount for EEVblog members.  Their FAQ says that they do sell and ship internationally but at some added expense.  Might be worth getting a quote from them next time you need something.  http://www.tequipment.net (http://www.tequipment.net)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sprocket on November 15, 2013, 08:18:18 am
I bought it from batronix in germany, the only reputable distributor that dont rip you off....

I bought it from silcon.cz ... very very happy, I think also very reputable and they don't rip you off.

Please, if you are going to qote me for some thing, dont just take snippets so it sounds like I said something that I didnt. I speccificly said " the only reputable distributor that dont rip you off that I have come across"

I bought it from batronix in germany, the only reputable distributor that dont rip you off that I have come across. RS and farnell are too expensive, and you need a CVR number to buy from them, and then there is the swedish based "instrumentcenter.se" they are a good 30% more expensive if I recall, and I gave up on UK based as they either want you to contact them for qoutes or the prices are pretty stupid high. Last I tríed to get some thing from the UK was a electronic DC load, after VAT and such, it was twice the price if I imported it directly from the manufacture in china, thats with shipping,import tax and VAT.


In the US, I have found TEquipment to be very good and they give a discount for EEVblog members.  Their FAQ says that they do sell and ship internationally but at some added expense.  Might be worth getting a quote from them next time you need something.  http://www.tequipment.net (http://www.tequipment.net)




Yea I know them, I havnt bought anything  from them though. The problem is import tax and VAT when you import goods from outside the EU, will basicly nullify any savings you get on the item you buy. If it wasn't for that, I would have no problem buying from tequibment at all.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 15, 2013, 08:31:57 am
I know I started this discussion, but maybe we should continue the discussion about where to buy Rigol in another topic before this topic becomes too much off topic. Maybe there's already another topic about this? I think this discussion could go on for long.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sprocket on November 15, 2013, 09:52:19 am
Probably a good idea.. We are cluttering the thread with unrelated discusions.  :box:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DD4DA on November 15, 2013, 10:50:51 am

I can see you're from Denmark too. Did you buy your Rigol in Denmark, or maybe from Germany?

I bought it from batronix in germany, the only reputable distributor that dont rip you off that I have come across.
AME-Elecronik (Alexander Meier Eletronik) www.ame-engineering.de (http://www.ame-engineering.de) is also a good place to get Rigol Equipment. I brought the DSA815TG, DS2072, and DM3058E from him. Friendly and smart person - i recommend him.

vy 73 de DD4DA
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: manzini on November 15, 2013, 10:59:17 am
Please, if you are going to qote me for some thing, dont just take snippets so it sounds like I said something that I didnt. I speccificly said " the only reputable distributor that dont rip you off that I have come across"

Excuse me, I am little lost in translate.
I want to clarify that, I'm not saying anything with double meaning, the meaning is very simple: if you have not known anything honest that BATRONIX (you said) then if you want to try anothers that you come across, I recommend you to include silconz.cz if you don't know.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on November 15, 2013, 10:25:48 pm
what does the sales talk have to do with "Sniffing the Rigol's internal I2C bus" ?  :-//  |O
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: echen1024 on November 15, 2013, 10:41:58 pm
what does the sales talk have to do with "Sniffing the Rigol's internal I2C bus" ?  :-//  |O
Well, now we know where to go to get a Rigol if we want to sniff its I2C bus.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Co6aka on November 15, 2013, 11:39:25 pm
Well, now we know where to go to get a Rigol if we want to sniff its I2C bus.

Except, it seems some have been sniffing a little too much bus, so... Maybe let's not go there.  8)

Cybernet, did you see my post re accessing the Cal menu of the DSA1000-series? I'm still swamped with nonsense-work so I haven't been able to 'hack on it. (I'm trying to wring out of my cal-lab acquaintance any other Rigol cal access info.) Was also wondering why, if the basic feature bits were mostly/all low-order, why the keys for the different series instruments would be so different (unless of course there's an ID bit/bit-combination,) and if a key for, say a DS4014 and DS4054, for the same options was the same or different.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on November 16, 2013, 12:13:36 am

the bits are different per instrument series, because rigol choose so. that way they can id a license to a instrument type probably the cause for it.
no real logical other reason imho.

Cybernet, did you see my post re accessing the Cal menu of the DSA1000-series? I'm still swamped with nonsense-work so I haven't been able to 'hack on it. (I'm trying to wring out of my cal-lab acquaintance any other Rigol cal access info.) Was also wondering why, if the basic feature bits were mostly/all low-order, why the keys for the different series instruments would be so different (unless of course there's an ID bit/bit-combination,) and if a key for, say a DS4014 and DS4054, for the same options was the same or different.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on November 16, 2013, 12:14:16 am
back to topic on this thread:

an early xmas present for all DG4??? users ...

https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg331486/#msg331486 (https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg331486/#msg331486)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Co6aka on November 16, 2013, 12:58:52 am
A dot-CEN file...  Fascinating! (Somebody's been busy... 8))
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Teneyes on November 16, 2013, 01:10:49 am
an early xmas present for all DG4??? users ...

 :clap:          :clap:

Thanks again , Cybernet, 
another great Detective story,  well Done

  :-+ :-+     :-+ :-+
   
now to compile and build the file.
Thanks Sparky , DG , DS  @200MHz ;D


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tan98010 on November 16, 2013, 09:26:45 am
Can anyone attached the .exe files? thanks.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on November 17, 2013, 06:08:02 am
cybernet, do you think something similar is in DSxxxx series?

Anyone dump DSxxxx yet? If something like this exists on DSxxxx I can write a downgrader...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Giggy on November 18, 2013, 08:52:45 am
Hey guys,
My ds2072A arrived today, looks good, wasn't aware i was receiving 300mhz passive probes (includes compensation adjustment)

Will have to attempt to hack the device once i learn to use it, i would like the ability to downgrade i suppose, for warranty reasons. (hopefully there isn't something set once hacked that cant be undone)

Anyone interested in some information about it?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: apelly on November 18, 2013, 09:07:00 am
Will have to attempt to hack the device
Good luck with that matey
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 18, 2013, 10:51:42 am
cybernet, do you think something similar is in DSxxxx series?

Anyone dump DSxxxx yet? If something like this exists on DSxxxx I can write a downgrader...
https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg331726/#msg331726 (https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg331726/#msg331726)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: danoxx on November 18, 2013, 12:06:45 pm
I have one question, working this combination on DSA815 (maintanance or calibration mode) ? TRACE > TG > MARKER FCTN > MEAS SETUP > SYSTEM > PRINT SETUP > STORAGE

I waiting for early xmas present too (DSA1000)  ::)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on November 18, 2013, 12:19:15 pm
I have one question, working this combination on DSA815 (maintanance or calibration mode) ? TRACE > TG > MARKER FCTN > MEAS SETUP > SYSTEM > PRINT SETUP > STORAGE

I waiting for early xmas present too (DSA1000)  ::)

nobody has yet posted any info about DSA1000, what key format, firmware image etc .. feel free to post it, and i'll have a look.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on November 18, 2013, 12:23:13 pm
cybernet, do you think something similar is in DSxxxx series?

Anyone dump DSxxxx yet? If something like this exists on DSxxxx I can write a downgrader...

something is, probably in the internal filesystem - but not via CEN files unfortunatly.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: danoxx on November 18, 2013, 12:50:47 pm
If I knew how to help... I have only firmware : newest https://www.dropbox.com/s/bw94x4pvcyn3m9b/DSA1000A%28DSP%29update0001160001.rar (https://www.dropbox.com/s/bw94x4pvcyn3m9b/DSA1000A%28DSP%29update0001160001.rar) or older version https://www.dropbox.com/s/zyjhluwdk6k61mr/DSA1000A%28DSP%29update.rar (https://www.dropbox.com/s/zyjhluwdk6k61mr/DSA1000A%28DSP%29update.rar)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on November 18, 2013, 08:54:15 pm
If I knew how to help... I have only firmware : newest https://www.dropbox.com/s/bw94x4pvcyn3m9b/DSA1000A%28DSP%29update0001160001.rar (https://www.dropbox.com/s/bw94x4pvcyn3m9b/DSA1000A%28DSP%29update0001160001.rar) or older version https://www.dropbox.com/s/zyjhluwdk6k61mr/DSA1000A%28DSP%29update.rar (https://www.dropbox.com/s/zyjhluwdk6k61mr/DSA1000A%28DSP%29update.rar)

thx - looks like the same incremential update format than the DSA815 is using, so without an JTAG dump, no luck. some DSA1k users would need to do a jtag dump like it has been done for the DSA815.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cosmos on November 18, 2013, 09:58:54 pm
If we where to work on DS4k ... what would we do next?
We have the GEL files, are they enough or do we need JTAG dumps?

We have indications from GEL file (text strings for printing active options) that there are options for 200Mhz, 350Mhz, 500MHz, and "power analysis" that can be opened.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on November 18, 2013, 10:08:09 pm
If we where to work on DS4k ... what would we do next?
We have the GEL files, are they enough or do we need JTAG dumps?

We have indications from GEL file (text strings for printing active options) that there are options for 200Mhz, 350Mhz, 500MHz, and "power analysis" that can be opened.

can u indicate some of those strings ?
what u would need is a jtag adapter, see the DG thread for details and plenty of time.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cosmos on November 18, 2013, 10:39:21 pm
strings are here
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg319892/#msg319892 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg319892/#msg319892)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 18, 2013, 10:51:39 pm
http://riglol.3owl.com (http://riglol.3owl.com) is online again. Not sure why it was down.

DDOS attack (IP Nullrouted)
http://riglol.3owl.com (http://riglol.3owl.com) is down again.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on November 18, 2013, 11:00:02 pm
this routine seems to build the model type ... DS40XY ....
Title: Hack report - DS2072
Post by: N2tl on November 19, 2013, 12:08:49 am
Device:  DS2072 (not the A version)
As delivered:
S/n: DS2A1537nnnnn
h/w: 1.0.2.0.0 (2.0)
S/w: 00.01.01.00.02
FPGA version:
 SPU 03.01.05
 WPU 00.06.05
 CCU 12.29.00
 MCU 00.05
model: DS2072
All options: trial versions.

Narrative:
The unit was supplied with current firmware and the 2.0 hardware board, but the model number is shown as a straight DS2072. So it is one of the few with the 2.0 hardware, but not the new private key.
After checking the above data, I acquired the license key using the web facility (http://riglolDOT3owlDOTcom/ (http://riglolDOT3owlDOTcom/)), and entered it as documented in the manual. The unit displayed that the license was accepted. Rebooted.
The list of options now has "Official Version" after each feature; the bandwidth is shown as 200 MHz, and the Model field says DS2202. The other "System Information" fields remained unchanged; the serial number remained correct.
Life is good.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on November 19, 2013, 12:17:58 am
here is a little IDC script, that will try to convert anything that starts with "LINK" statement to a sub in IDA.
saves hours of stupid sub creation ...

Code: [Select]
///////////////////////////////////
// Blackfin LINK finder
// (c) cybernet, 2013
///////////////////////////////////

#include <idc.idc>
static main()
{
    auto addr,start,code;
   
    start=0x1;
    addr=FindBinary(start, SEARCH_DOWN, "00 E8");
    Message("checking for function header at %x\n", addr);
    while (addr > -1)
    {
    if (strlen(Name(addr))==0)  // not yet a known location ? (sub_)
      {
    if (MakeCode(addr))  // try to make code out of it
    {
      code=GetDisasm(addr);
      if (strstr(code, "LINK")>-1)   // mnemonic is a LINK ?
              { 
        MakeFunction(addr,-1);
        Message("created function at %x\n", addr);
              }
    }
    }
    addr=addr+4;
    addr=FindBinary(addr, SEARCH_DOWN, "00 E8");
    Message("checking for function header at %x\n", addr);
    }
}
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DL5TOR on November 19, 2013, 02:45:37 pm
If we where to work on DS4k ... what would we do next?
We have the GEL files, are they enough or do we need JTAG dumps?

We have indications from GEL file (text strings for printing active options) that there are options for 200Mhz, 350Mhz, 500MHz, and "power analysis" that can be opened.

the DS4K keygen is also there if you read the thread then you will see (someware at page 30 +- 20). it is the same Pub-key as the 3k but the Option code is different but all dockumented somware in this thread)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 19, 2013, 03:25:20 pm
If we where to work on DS4k ... what would we do next?
We have the GEL files, are they enough or do we need JTAG dumps?

We have indications from GEL file (text strings for printing active options) that there are options for 200Mhz, 350Mhz, 500MHz, and "power analysis" that can be opened.

the DS4K keygen is also there if you read the thread then you will see (someware at page 30 +- 20). it is the same Pub-key as the 3k but the Option code is different but all dockumented somware in this thread)
Yes but you can't change the bandwidth and add "power analysis" with the keygen for DS4k, just like cosmos mentioned.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Co6aka on November 19, 2013, 09:42:23 pm
this routine seems to build the model type...

Sure does!  From the serial number? Or...where (originally) in NV memory? 

(Reminds me of the good 'ol days hacking Motorola radio programming software... 8)  Wish I had time to invest right now.)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gunb on November 20, 2013, 09:04:42 am
If we where to work on DS4k ... what would we do next?
We have the GEL files, are they enough or do we need JTAG dumps?

We have indications from GEL file (text strings for printing active options) that there are options for 200Mhz, 350Mhz, 500MHz, and "power analysis" that can be opened.

the DS4K keygen is also there if you read the thread then you will see (someware at page 30 +- 20). it is the same Pub-key as the 3k but the Option code is different but all dockumented somware in this thread)

Yes but you can't change the bandwidth and add "power analysis" with the keygen for DS4k, just like cosmos mentioned.


Yes, exactly. Would be an interesting to change the bandwidth.
Only for test purposes, of course.  :-DD
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: excapealex on November 20, 2013, 03:51:51 pm
I have read all the posts and threads about it, if I understand it, since the modification for the DS2072 seems to work also on the DS2072A,

I've seen no confirmation of that anywhere.  Precisely the opposite, in fact.

Quote
I want an oscilloscope for small home projects, and I would also buy a simple function generator (if possible also  arbitrary), the DS2072A-S has them both.. But the thing that interests me most of all is the possibility to decode serial signals.

In that case, get the DS1074Z-S... it's a no-brainer.  Cheaper than the DS2072A-S will be, available immediately, and known to work with the keygens.  Way more than enough capability for "small home projects".  The only constraint I'd mention there would be that if CAN protocol decoding is important to you, the 1074Z-S won't have it, and the 2072A-S will.

You are right, I read it quickly and I understood what I wanted to understand .. my fault!

The DS1074Z-S might be sufficient for my needs, 1 GSa / s instead of 2GSa / s are not a problem, as the 24Mpts instead of 56Mpts.

The CAN decoding currently does not interest me at all.

The features that interest me most are instead the Real-time Waveform Record / Replay and RS232/UART, I2C, SPI Trigger and Decoding function.

The function of signal generator would allow me just to avoid the purchase of an additional device.

Another obstacle may be the occasional need to work with signals greater than 70MHz.. On rigloldot3owldotcom I do not see listed a code to bring it to 100MHz.. Should I perhaps consider directly the DS1104Z-S?

Reading the posts, however, I am not able to figure out if for the DS1104Z-S it's also possible to generate valid codes for the various optional features, or if they only work on the DS1074Z/DS1074Z-S as for the DS2072 where is not yet known whether they can operate on the DS2072A-S.

Now I do not know really what to buy. -.- '
Probably the DS1074Z-S or the DS1104Z-S if the functions were certainly unlockable otherwise the DS2072 (not A) and a separate function generator..

All suggestions are welcome!


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on November 21, 2013, 04:33:06 am
What is this "power analysis" I keep reading about in oscilloscopes? Does this just mean measuring the power through a 50-ohm load (input) or do you program in a resistance/impedance and it tells you what power 'would' be dissipated?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gallymimus on November 21, 2013, 04:58:50 am
What is this "power analysis" I keep reading about in oscilloscopes? Does this just mean measuring the power through a 50-ohm load (input) or do you program in a resistance/impedance and it tells you what power 'would' be dissipated?

probably similar to this:

Agilent 3000 Power Analysis Option (https://www.youtube.com/watch?v=eTe3LnDblr8#ws)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on November 21, 2013, 05:12:12 am
cybernet, do you think something similar is in DSxxxx series?

Anyone dump DSxxxx yet? If something like this exists on DSxxxx I can write a downgrader...

something is, probably in the internal filesystem - but not via CEN files unfortunatly.

yes, that's what I was seeing too, but I didn't look hard, been waiting for a fulldump and working on other things beyond full time :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bandgap on November 21, 2013, 09:29:44 am
Yay... DS2302  :clap: (Randomly got it, I guess?) This is a DS2202 unit.


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on November 21, 2013, 12:05:34 pm
@DS4000

i had a look at the bandwidth upgrade possiblities for the DS4k ...
1. the evaluation of the optioncode is very different from the DS2k - without initialized BSS and a real memory dump a lot of guesswork is neede to figure something out.
2. the firmware has the provision to do the bandwidth upgrade - what i cant tell is if the code that triggers it is actually reachable by a valid optioncode

i think Uuup did extensive testing on the option codes, but i think its worth a shot to repeat that with a little bruteforce given the following facts:

there are 8 different options that can be enabled (0-4 = the known ones) 5,6,7 = are bandwidth upgrades (so the bandwidth code should be the 3 bits left to the known codes ... *guessworkhere*)

i can see code that uses the 12 LSB bits of the option code, and does "something" with it - there are code references that then go on to change the model type (=bandwidth change), but without proper BSS setup its not possible to figure it out anymore.
Just probing the indvidiual 5,6,7th bits might not be enough, it could be a "combination" thats needed.

what i would do if i had a DS4k:

use the RLGLLDS keyformat - and bruteforce the remaining possible bits <B>

Code: [Select]
     A       B       C       D
   54321   54321   54321   54321

   10000   000BB   BBBBB   x0000   FlexRay Decode or alternate option
   10000   000BB   BBBBB   0x000   CAN Decode or alternate option
   10000   000BB   BBBBB   00x00   I2C Decode or alternate option
   10000   000BB   BBBBB   000x0   SPI Decode or alternate option
   10000   000BB   BBBBB   0000x   RS232 Decode or alternate option
i guess you could do it with python via LXI easily within a resonable timeframe

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 21, 2013, 12:10:48 pm
Yay... DS2302  :clap: (Randomly got it, I guess?) This is a DS2202 unit.
Did it say DS2302 when you received it, or what did you do to change it from DS2202 to DS2302?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on November 21, 2013, 12:33:02 pm
here is a little IDC script, that will try to convert anything that starts with "LINK" statement to a sub in IDA.
saves hours of stupid sub creation ...
In the latest firmware version (for DS2K) it found a total of 93:
Code: [Select]
Function at 4f276
Function at 4f298
Function at 4f2ba
Function at 4f34a
Function at 4f752
Function at 5007e
Function at 5048a
Function at 50bba
Function at 50c6c
Function at 50c96
Function at 50cbe
Function at 5134e
Function at 5d2f0
Function at ec5ea
Function at ec684
Function at ec694
Function at ec6e2
Function at ec732
Function at ec780
Function at ec8ca
Function at ec8fa
Function at ec92a
Function at ec968
Function at ec97a
Function at ec9b0
Function at ec9ca
Function at ec9dc
Function at ec9ee
Function at eca00
Function at eca12
Function at eca24
Function at eca34
Function at eca6c
Function at ecabc
Function at ecace
Function at ecae2
Function at ecb08
Function at ecb4e
Function at ecbee
Function at ecf02
Function at ecf26
Function at ecfb6
Function at ecfec
Function at ed002
Function at ed058
Function at ed070
Function at ed080
Function at ed090
Function at ed0ae
Function at ed0c2
Function at ed0d8
Function at ed10c
Function at ed280
Function at edf1e
Function at edf30
Function at edf42
Function at edf5e
Function at edf76
Function at edf8a
Function at edf9e
Function at edfb2
Function at edfc6
Function at edfd8
Function at edfea
Function at ee598
Function at ee5aa
Function at ee5be
Function at ee5ce
Function at ee5e0
Function at ee5f2
Function at ee604
Function at ee7e4
Function at ee7fa
Function at ee81a
Function at ee83c
Function at ee84c
Function at ee872
Function at ee88e
Function at f045e
Function at f04e8
Function at f0cb4
Function at f131c
Function at f26ba
Function at f26e6
Function at f2712
Function at f30d2
Function at f33be
Function at f3422
Function at f343a
Function at f3450
Function at 10c562
Function at 10c7b4
Function at 10cb0c
Function at 10d2ec
Function at 10d974
Function at 10d98e
Function at 10dede
Function at 10dfce
Function at 10dfea
Function at 10dffa
Function at 10e0d2
Function at 10e166
Function at 10e2dc
Function at 10e316
Function at 10e3d2
Function at 10ebd4
Function at 10ebea
Function at 22db4e
Function at 22df00
Function at 22f6f6
Function at 22f75c
Function at 22f7fc
Function at 22f81e
Function at 22f88e
Function at 22fc4e
Function at 23006a
Function at 230144
Function at 230476
Function at 2304f4
Function at 230564
Function at 230cde
Function at 230f94
Function at 2362ca
Function at 23919e
Function at 2391f8
Function at 2392e0
Function at 23aeb0
Function at 23aee6
Function at 23b0b6
Function at 23b16e
Function at 23b358
Function at 23b36e
Function at 23b75c
Function at 23d78a
Function at 23d882
Function at 24b8de
Function at 24bd8c
Function at 24beec
Function at 24c6ee
Function at 24c91a
Function at 24ca4e
Function at 24cc0a
Function at 24ccc6
Function at 251852
Function at 251890
Function at 2518be
Function at fd1bf0

I don't understand how you handle all this assembly code so easy. Is amazing...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on November 21, 2013, 12:58:28 pm
Yay... DS2302  :clap: (Randomly got it, I guess?) This is a DS2202 unit.
Did it say DS2302 when you received it, or what did you do to change it from DS2202 to DS2302?
I'm beginning to think that is not necessary to change any trt to reach 300 MHz, i.e. only is necessary send the SPI command (350MHz or 6xxMHz I don't remember exactly) to the LMH6518.
Frequency BW is sent even when you only change the scale for V/DIV.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bandgap on November 21, 2013, 01:05:36 pm
Yay... DS2302  :clap: (Randomly got it, I guess?) This is a DS2202 unit.
Did it say DS2302 when you received it, or what did you do to change it from DS2202 to DS2302?

No, it definitely said DS2202 when I got it. Here are steps that I performed that resulted in this:

1) "Upgraded" to FW#00.00.01.00.05 thinking it was most recent version (already had 0.02, but failed to read properly.)
2) Used RiGen-2b1 in windows to play around with resetting the trial options (worked.)
3) Read more in this thread and realized 0.02 was the most recent FW and re-applied it.
4) Trial options disappeared so used the riglol-x86_64-linux in linux and generated a permanent key (just happened to have a linux machine nearby when I did it this time.)
5) DS2202 became a DS2302 with new BW limit option of 200MHz and new time scale of 1ns/div.

-Clayton
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 21, 2013, 01:37:04 pm
http://riglol.3owl.com (http://riglol.3owl.com) is online again. Not sure why it was down.

DDOS attack (IP Nullrouted)
http://riglol.3owl.com (http://riglol.3owl.com) is down again.
And http://riglol.3owl.com (http://riglol.3owl.com) is down again again.

I have set up some storage on my server for files related to this "investigation", including SPI traffic captures and an I2C dump.

http://gotroot.ca/rigol/ (http://gotroot.ca/rigol/)
I can host too if a mirror is needed
Maybe you guys should mirror studio25's RigLOL web app. http://riglol.3owl.com (http://riglol.3owl.com) seems to be down half the time.

I can see http://gotroot.ca/rigol/ (http://gotroot.ca/rigol/) already has some of studio25's earlier work (Rigol_DS2000_patch.zip and Rigol DS2000 trial hack.rar) but not his latest Riglol web app.

Riglol 1.03c (studio25's latest version) attached in zip folder.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: BitBucket on November 21, 2013, 05:23:48 pm
Hi, I'm new here.


I recently bought a DS2102 (HW 1.0, FW 00.00.01). DS2A........

A Rigol distri techy made me loose my option evaluation times  >:(.
While trying to improve acuracy he advised to start Self Calibration.
Afterwards, option evaluation times were set to 'Expired'.
He admitted that he forgot to warn me about this FW-flaw.
This leaves me no choice than to hack the options back on.

I read related threads partly but quit, they are way too big.

Questions
1. Should I first update to FW 00.01.01.00.02 and then hack the options or the other way around?
2. What is the best option hack tool to use (RiGen 1v/v2, RigLol, dstool, other)?
    I use Windows but we have a MAC too. I do not want the serial# set to ....00000001
3. In case I ever need to return the DSO for repair, how to set all options to 'Expired'?


Thank you,
BitBucket
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 21, 2013, 05:33:32 pm
Questions
1. Should I first update to FW 00.01.01.00.02 and then hack the options or the other way around?
2. What is the best option hack tool to use (RiGen 1v/v2, RigLol, dstool, other)?
    I use Windows but we have a MAC too. I do not want the serial# set too ....00000001
Use http://riglol.3owl.com (http://riglol.3owl.com), I think it's the only tool still maintianed. Read and follow the steps in my post here: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg324768/?topicseen#msg324768 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg324768/?topicseen#msg324768)

3. In case I ever need to return the DSO for repair, how to set all options to 'Expired'?
Use the SCPI command ":SYSTem:OPTion:UNINSTall". Search the topic for :SYSTem:OPTion:UNINSTall for more info.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: BitBucket on November 21, 2013, 10:56:09 pm
@AndersAnd


Thank for replying so quickly. OK, I will use http://riglol.3owl.com (http://riglol.3owl.com).
Weird, that site had an adbanner from the provider today, later content was back.

I'm not familiar with the SCPI-tool. Where can I find it?

I read somewhere that some tools cause a serial# ....00000001. Is the tool at that site safe to use?


Greetz,
BitBucket.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 21, 2013, 11:09:05 pm
I read somewhere that some tools cause a serial# ....00000001. Is the tool at that site safe to use?
Only if you have one of the earliest firmware versions installed while entering the option keys. So update to the latest firmware before entering any option keys top avoid clearing the serial#.

I'm not familiar with the SCPI-tool. Where can I find it?
As I already wrote search the topic for :SYSTem:OPTion:UNINSTall for more info.

And read your scope's user's manual + programming guide, info about SCPI is in both documents.

SCPI = Standard Commands for Programmable Instruments https://en.wikipedia.org/wiki/Standard_Commands_for_Programmable_Instruments

I think you have been spoon fed enough by now.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jamesb on November 22, 2013, 01:11:19 am
I have a feeling that the >200MHz BW is a hardware version limited upgrade.

Ie. I am unable to replicate the results with the following variables:

Base (real) model: DS2202
SW: 00.01.01.00.02
HW: 1.0.1.0.0
FPGA:
 SPU: 03.01.05
 WPU: 00.06.05
 CCU: 12.29.00
 MCU: 00.05

Private key used: 8EEBD4D04C3771
Option code: DSAZ
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 22, 2013, 01:14:51 am
I have a feeling that the >200MHz BW is a hardware version limited upgrade.

Ie. I am unable to replicate the results with the following variables:

Base (real) model: DS2202
SW: 00.01.01.00.02
HW: 1.0.1.0.0
FPGA:
 SPU: 03.01.05
 WPU: 00.06.05
 CCU: 12.29.00
 MCU: 00.05

Private key used: 8EEBD4D04C3771
Option code: DSAZ
But that's the same hardware and software versions Bandgap has:
(https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/?action=dlattach;attach=67931;image)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jamesb on November 22, 2013, 01:21:10 am
Good point  :-DD

I am not sure where I am going wrong then .. I am following the "instructions" to the T and I have yet to achieve the same results.
Perhaps it is just a lucky key?

Has anyone else had any promising results?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bandgap on November 22, 2013, 02:44:26 am
Good point  :-DD

I am not sure where I am going wrong then .. I am following the "instructions" to the T and I have yet to achieve the same results.
Perhaps it is just a lucky key?

Has anyone else had any promising results?

Ok, I have a theory. jamesb said he used option code DSAZ. This turns on all options including 200MHz, but not 100MHz. I used DSA9 which turns on all options including both 100MHz and 200MHz. Maybe turning both of these on with option 9 instead of Z has sort of an additive effect and tells the scope to operate up to 300 MHz.

Just a theory...

So try it and let us know jamesb! You'd be a good test since your scope is identical to mine in hardware and everything.

-Clayton

Title: Sniffing the Rigol's internal I2C bus
Post by: danfloun on November 22, 2013, 10:34:35 pm
I've set a mirror up for both sites above.

Mirrors are updated twice a day but only adding/updating new files so no worry about server impact.

http://rigol.avotronics.co.uk (http://rigol.avotronics.co.uk)

If site owners have issue with this I'll gladly take them down. Just pm me your woes.

Cheers
Danny
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 22, 2013, 10:51:49 pm
I've set a mirror up for both sites above.

Mirrors are updated twice a day but only adding/updating new files so no worry about server impact.

http://rigol.avotronics.co.uk (http://rigol.avotronics.co.uk)

If site owners have issue with this I'll gladly take them down. Just pm me your woes.

Cheers
Danny
:-+

Just added your RigLOL mirror site to my step-by-step guide here: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg324768/#msg324768 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg324768/#msg324768)

Btw. what happens if it mirrors http://riglol.3owl.com (http://riglol.3owl.com) while it's down at redirects to this 3owl landing page:
Quote
(http://3owl.com/landing/logo.png)

We at 3owl.com offer 100% Free Php Web Hosting. Unlimited Disk and Bandwidth.
Click Signup Now to Get Started!
Will it mirror the landing page or keep the original while it's down?
Title: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on November 22, 2013, 11:08:28 pm

I've set a mirror up for both sites above.

Mirrors are updated twice a day but only adding/updating new files so no worry about server impact.

http://rigol.avotronics.co.uk (http://rigol.avotronics.co.uk)

If site owners have issue with this I'll gladly take them down. Just pm me your woes.

Cheers
Danny
:-+

Just added your RigLOL mirror site to my step-by-step guide here: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg324768/#msg324768 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg324768/#msg324768)

Btw. what happens if it mirrors http://riglol.3owl.com (http://riglol.3owl.com) while it's down at redirects to this 3owl landing page:
Quote
(http://3owl.com/landing/logo.png)

We at 3owl.com offer 100% Free Php Web Hosting. Unlimited Disk and Bandwidth.
Click Signup Now to Get Started!
Will it mirror the landing page or keep the original while it's down?

That's a good point. I'll have to add a bit of conditional code somewhere.
Glad you're think straight! :-/
Title: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on November 22, 2013, 11:28:40 pm

I've set a mirror up for both sites above.

Mirrors are updated twice a day but only adding/updating new files so no worry about server impact.

http://rigol.avotronics.co.uk (http://rigol.avotronics.co.uk)

If site owners have issue with this I'll gladly take them down. Just pm me your woes.

Cheers
Danny
:-+

Just added your RigLOL mirror site to my step-by-step guide here: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg324768/#msg324768 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg324768/#msg324768)

Btw. what happens if it mirrors http://riglol.3owl.com (http://riglol.3owl.com) while it's down at redirects to this 3owl landing page:
Quote
(http://3owl.com/landing/logo.png)

We at 3owl.com offer 100% Free Php Web Hosting. Unlimited Disk and Bandwidth.
Click Signup Now to Get Started!
Will it mirror the landing page or keep the original while it's down?

I've just shortened the riglol mirror slightly, you'd better update it on the other page, its: http://rigol.avotronics.co.uk/riglol
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 22, 2013, 11:36:08 pm
I've just shortened the riglol mirror slightly, you'd better update it on the other page, its: http://rigol.avotronics.co.uk/riglol (http://rigol.avotronics.co.uk/riglol)
Done.
Btw I see 2 different usernames, danfloun and Avotronics, is this the same person?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on November 22, 2013, 11:43:27 pm
FWIW I ended up mangling my SN on the latest firmware version, so that is not guaranteed to prevent it from happening.  It was either trying to uninstall a key via SCPI that did it, or attempting to install a key based on s/n DS2A000000000 by mistake (I forgot to paste my SN in before generating it).
Title: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on November 22, 2013, 11:47:47 pm

I've just shortened the riglol mirror slightly, you'd better update it on the other page, its: http://rigol.avotronics.co.uk/riglol (http://rigol.avotronics.co.uk/riglol)
Done.
Btw I see 2 different usernames, danfloun and Avotronics, is this the same person?

Yeah I've just binned danfloun, not using it no more. Sick of all the different forum logins and am trying to keep them all the same.

Danny
Title: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on November 22, 2013, 11:49:30 pm
So how safe is hacking ds2072 up to 100mhz or more? Any bricks?
I'm think of ordering one soon.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 23, 2013, 12:10:14 am
I think the only time you risk bricking it is if something goes wrong while updating the firmware. But that's not directly related to entering option keys. That can happen to anyone updating firmware even if they don't enter any keys.

Entering the keys themselves hasn't bricked any devices from what I've read in this topic. I think the worst thing that has happened is resetting the serial number. But it looks like only people who haven't followed all the steps I described earlier in the right order without any typos, wrong option codes or serials has done that.
But of course it's always on your own risk.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on November 23, 2013, 12:37:31 am
I think the only time you risk bricking it is if something goes wrong while updating the firmware. But that's not directly related to entering option keys. That can happen to anyone updating firmware even if they don't enter any keys.

I think it's virtually impossible to brick these DSOs by updating the firmware (and I've never heard/read of it happening to anyone). The DS2000 has a bootloader (unlike the DS1000E), so in case of a power failure, etc. during firmware update, the unit may not initially start, but you are still able to re-initiate another FW update during the next boot process.

In addition to that, unit-specific data is backed up in another part of memory - so in case it gets corrupted or overwritten, it's restored automatically on the next bootup.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jamesb on November 23, 2013, 01:30:35 am
Ok, I have a theory. jamesb said he used option code DSAZ. This turns on all options including 200MHz, but not 100MHz. I used DSA9 which turns on all options including both 100MHz and 200MHz. Maybe turning both of these on with option 9 instead of Z has sort of an additive effect and tells the scope to operate up to 300 MHz.

Just a theory...

So try it and let us know jamesb! You'd be a good test since your scope is identical to mine in hardware and everything.

-Clayton

I've tried the procedure again, however, I was unable to install trial keys (likely due to my recent second calibration). If this is critical to the procedure, it may not be possible to "work around" into the 300MHz BW without trial licenses installed at the time of firmware upgrade. Having said that, I would have expected to hear more people with 300MHz BW machines simply by upgrading from firmware 00.01.00.05 to 01.01.00.02

My procedure was as follows:

The outstanding variables (aside from trial keys not being accepted/used) as far as I can tell are:

I wonder how we can more directly probe this ... any suggestions?

edit:

If anyone has a method of allowing me to install trial keys again without having to flash a ROM, please PM me so that I can attempt to remove the trial key status as a variable.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 23, 2013, 02:00:42 am
If anyone has a method of allowing me to install trial keys again without having to flash a ROM, please PM me so that I can attempt to remove the trial key status as a variable.
Can't you just uninstall all official keys with the SCPI command :SYSTem:OPTion:UNINSTall and then install the trial keys generated with http://riglol.3owl.com (http://riglol.3owl.com)

To generate trial keys instead of official keys just type V as the first character instead of D.
E.g. VSAZ instead of DSAZ:
Quote
DS2000 device options:
first character: D = official, V = trial
DSAB - Advanced Triggers
DSAC - Decoders
DSAE - 56M Memory
DSAJ - 100MHz
DSAS - 200MHz
DSAZ - all options
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on November 23, 2013, 11:33:29 am
Not sure how getroot.ca operates when it's not accessible, but timeouts and/or redirects to landing pages (i.e. what 3owl.com does) should not affect my mirror. The mirror won't follow temporary or permanent redirects and timeouts will just result in nothing being mirrored, obviously.

I think that covers most situations, but time will tell.

Danny  :clap:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jamesb on November 23, 2013, 01:45:21 pm
To generate trial keys instead of official keys just type V as the first character instead of D.
E.g. VSAZ instead of DSAZ:

As you will note, I did indicate generating a trial key using the VSA9 option key. The oscilloscope said something to the effect of "trial license unavailable"
Having said that, I tried again this morning, but I used a different keygen and was able to install a trial license using VSA9 (as attempted before).

My latest iteration was as follows:


All firmware upgrades were done via safe method (cold boot, press power, press "help" before LEDs turn off, CH1 blinks indicating FW installation) and all key installs were done via SCPI (Ultra Sigma).

So the difference this time is that I was able to install trial keys, however, they did NOT expire when upgrading from FW 00.01.00.05 to 01.01.00.02 as Bandgap experienced. I will try the whole process again, but it would be nice to know what key generating tools were used in the successful method as well as to have the exact FW copies to use.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 23, 2013, 02:04:23 pm
As you will note, I did indicate generating a trial key using the VSA9 option key. The oscilloscope said something to the effect of "trial license unavailable"
Did you uninstall the official keys first before trying to install trial keys?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jamesb on November 23, 2013, 02:09:48 pm
As you will note, I did indicate generating a trial key using the VSA9 option key. The oscilloscope said something to the effect of "trial license unavailable"
Did you uninstall the official keys first before trying to install trial keys?

Yes, I started with what could be described as a "fresh out of the box" approach. Ie. uninstalled all keys, installed new "trial" key and then started the whole procedure.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 23, 2013, 02:18:49 pm
As you will note, I did indicate generating a trial key using the VSA9 option key. The oscilloscope said something to the effect of "trial license unavailable"
Did you uninstall the official keys first before trying to install trial keys?
Yes, I started with what could be described as a "fresh out of the box" approach. Ie. uninstalled all keys, installed new "trial" key and then started the whole procedure.
I don't get it, you just said in your previous post you couldn't install the trial keys (trial license unavailable) and now you say you did install them?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 23, 2013, 02:20:08 pm
Yay... DS2302  :clap: (Randomly got it, I guess?) This is a DS2202 unit.
Do you still have the generated key you entered?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jamesb on November 23, 2013, 02:28:20 pm
I don't get it, you just said in your previous post you couldn't install the trial keys (trial license unavailable) and now you say you did install them?

That is exactly what I said.
I mentioned being given an error message to the effect of "trial key no longer accepted"
Any particular reason why are you getting caught up about this detail?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jamesb on November 23, 2013, 02:37:08 pm
I am beginning to think that getting 300MHz to work is more fluke than anything else.
I've been upgrading and downgrading FW versions, etc, trying to find the exact combination required to make this work and I stumbled onto this:

(http://i.imgur.com/zWXulPX.png)

Notice the trial timers??
And I can not seem to remove the trials now .. I can however get them to reset to their ~4000 minute mark
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on November 23, 2013, 04:26:15 pm
I am beginning to wonder if there is any logic to it at all.  Mine can't return to a DS2072 now either.  So it has the 00001 sn and is stuck in DS2202 mode.  Won't accept any trial licenses either.  Makes me wonder if the trial extension is part of the problem, maybe no one should load V codes.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: darrylp on November 23, 2013, 05:05:12 pm
I think their might be multiple slots in memory so to speak to hold the license keys. I had to use the uninstall Scpi command a couple of times to remove my trial ones I had loaded on top of already loaded trial with a different combo of options.

Worth doing 5 or 6 uninstalls in a row.

--
Darryl

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on November 23, 2013, 05:09:06 pm
I think their might be multiple slots in memory so to speak to hold the license keys. I had to use the uninstall Scpi command a couple of times to remove my trial ones I had loaded on top of already loaded trial with a different combo of options.
Worth doing 5 or 6 uninstalls in a row.

I wonder if loading too many keys is what will overflow their slots and perhaps this is what erases the S/N.  I'm not sure if multiple uninstalls clears the slots or just removes the features.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on November 23, 2013, 05:17:19 pm
When you people keep saying you've turned your DS2072 into a DS2302, do you mean you turned it into a DS2302A?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 23, 2013, 05:31:34 pm
When you people keep saying you've turned your DS2072 into a DS2302, do you mean you turned it into a DS2302A?
I think only one person has successfully upgraded a DS2072 to DS2302 (and not on purpose).
DS2000 and DS2000A seems to be almost the same thing except for this:
Can anybody spot any differences between the DS2000A-Series and the regular DS2000-Series, apart from the inclusion of a 300MHz model and most likely better encryption :)
Comparing data sheets (DS2000A from Rigol's Chinese web site), the only differences that I can see are:

1)  Added model DS2302A with 300MHz BW and 1ns/div horizontal.
2)  Switchable 50 ohm input termination
3)  Optional CAN bus trigger and decode

The odd thing is that if you look at the current product pages for the DS2000 series scopes on the various Rigol web sites, they list DS2000A as the model number in the specifications:
For example:  http://www.rigolna.com/products/digital-oscilloscopes/ds2000/ds2072/ (http://www.rigolna.com/products/digital-oscilloscopes/ds2000/ds2072/)    (click on "Specifications" tab).
And DS2000A also seems to require different option keys than 2000. Nobody has successfully used the DS2000 keygen for a DS2000A.

DS2000A has HW ver. 2. but it's a HW ver. 1 that has been upgraded to DS2302.
Don't think it now has CAN decoder too, but easy to check.
Also easy to check if you can now select 50 termination and if you can if it actually works in the hardware.
Not sure if HW ver. 1 supports 50 ohm termination.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bandgap on November 23, 2013, 06:11:52 pm
Yay... DS2302  :clap: (Randomly got it, I guess?) This is a DS2202 unit.
Do you still have the generated key you entered?

Sorry, I don't (wish I had thought to save it!) I did use the riglol-x86_64-linux binary mirrored here: http://www.gotroot.ca/rigol/. (http://www.gotroot.ca/rigol/.) I used DSA9 and I did not enter the optional private key.

I'm tempted to remove the keys via SCPI and see if I can easily get it back again, but I'm afraid it wouldn't be so easy - especially if there's no rhyme or reason to it!

-Clayton
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 23, 2013, 06:20:58 pm
Yay... DS2302  :clap: (Randomly got it, I guess?) This is a DS2202 unit.
Do you still have the generated key you entered?

Sorry, I don't (wish I had thought to save it!) I did use the riglol-x86_64-linux binary mirrored here: http://www.gotroot.ca/rigol/. (http://www.gotroot.ca/rigol/.) I used DSA9 and I did not enter the optional private key.

I'm tempted to remove the keys via SCPI and see if I can easily get it back again, but I'm afraid it wouldn't be so easy - especially if there's no rhyme or reason to it!

-Clayton
I wonder if a JTAG memory dump of your scope could be helpful in finding an option code for 300 MHz?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on November 23, 2013, 06:33:42 pm
I'm gonna get the DS2072 but can't just at the minute, maybe after xmas.
Just wondering; If I end up with a DS2072A does that mean I'd be currently stuck at 70MHz?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on November 23, 2013, 06:54:57 pm
most likely just another screwup (same like serial reset) due to the fact that temp keys leave traces in the NV memory and shitty chinese programming.
as shown in one of the first pages in this thread, if u change the "model_type_id" (thats what i call it) to a certain value, u get 500ps time resolution (on the screen only obviously).
the actual model type string DS2 .. is generated on the fly. supported characters are 1,2,3,4,5 ... so a DS2502 is probably possible.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 23, 2013, 07:04:16 pm
I'm gonna get the DS2072 but can't just at the minute, maybe after xmas.
Just wondering; If I end up with a DS2072A does that mean I'd be currently stuck at 70MHz?
I think someone needs to upload a JTAG memory dump of JTAG DS2000A series before it can be hacked.
Noone has uploaded a dump from DS2000A yet and only very few has reported getting a DS2000A series yet.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: BitBucket on November 23, 2013, 07:06:18 pm
According to my Rigol distri techy, trial keys are being accepted only once.
You cannot repeatedly set the same option to 'Trial'.
He wasn't clear about trial for 1 option or for all options in general.
I cannot confirm this from own experience.


HTH,
BitBucket
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Teneyes on November 23, 2013, 07:11:47 pm
most likely just another screwup by shitty chinese programming.
Like using 56000 ,instead of 57600 for 56K baud
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Teneyes on November 23, 2013, 07:16:08 pm

Sorry, I don't (wish I had thought to save it!)
I did use the riglol-x86_64-linux binary mirrored here:
-Clayton

@ Bandgap   Did you use that windows Keygen that adds 2 extra Bytes?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on November 23, 2013, 07:26:02 pm
your DS2302 sets the freq to 350Mhz btw ... here is a dump of possible models (taken from the function that builds it)

supported model types:
Code: [Select]
model         freq       type id
-----------------------------------------------
DS2072   70Mhz        0x16
DS2102  100Mhz       0x0
DS2202  200Mhz       0x1
DS2302  350Mhz       0x2
DS2502  500Mhz       0x4
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bandgap on November 23, 2013, 07:39:52 pm

Sorry, I don't (wish I had thought to save it!)
I did use the riglol-x86_64-linux binary mirrored here:
-Clayton

@ Bandgap   Did you use that windows Keygen that adds 2 extra Bytes?

No I did not. When I successfully converted to DS2302, I use the riglol-x86-64-linux binary here: http://www.gotroot.ca/rigol/. (http://www.gotroot.ca/rigol/.)

-Clayton
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 23, 2013, 08:11:30 pm
your DS2302 sets the freq to 350Mhz btw ... here is a dump of possible models (taken from the function that builds it)

supported model types:
Code: [Select]
model         freq       type id
-----------------------------------------------
DS2072   70Mhz        0x16
DS2102  100Mhz       0x0
DS2202  200Mhz       0x1
DS2302  350Mhz       0x2
DS2502  500Mhz       0x4
I guess they have changed 350Mhz to 300 MHz in the DS2000A firmware, as they are now actually selling a DS2302A model with a specified BW of 300 MHz: http://www.rigol.com/prodserv/281/ (http://www.rigol.com/prodserv/281/)

I wonder if the HW is actually capable of a 500 MHz BW.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on November 23, 2013, 08:34:51 pm
my bet is, it sets the LMH6518 - and the timebase - rest is up to "hardware" + selfcal i guess, depending on whats gettind through, but i have nothing that goes over 200Mhz to test it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on November 23, 2013, 08:52:13 pm
Woow 500MHz.

More news:

CAN-DS2000A:
CAN trigger and decode for DS2000 and DS2000A.
Source: http://www.tequipment.net/RigolPricelist.html (http://www.tequipment.net/RigolPricelist.html)
Title: Re: Re: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on November 23, 2013, 09:45:58 pm
I'm gonna get the DS2072 but can't just at the minute, maybe after xmas.
Just wondering; If I end up with a DS2072A does that mean I'd be currently stuck at 70MHz?
I think someone needs to upload a JTAG memory dump of JTAG DS2000A series before it can be hacked.
Noone has uploaded a dump from DS2000A yet and only very few has reported getting a DS2000A series yet.

Hmm. Well I'd provide that if I had the A version. Trouble is I might end up being stuck with 70MHz if its non hackable. Might have to find a non A.

Sent from my Nexus 4 using Tapatalk

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bob11746 on November 24, 2013, 12:49:14 am
I purchased a DS2102 several months ago.  When I first opened the box, the front panel said DS2202.  I said Yippee! they screwed up! ;D  That was short lived :(, the firmware internally said it was a DS2102 as well as the paperwork that went with it.  So with the 2202 moniker on the front, this unit is begging for a hack.

I've been reading these blogs and you guys are great, but there are so many procedures talked about I'm a little confused as to what I need to do, is there anywhere a concise set of instructions on how to hack my 2102 to a 2202?  Is it as simple as using the windows key gen?  Can it be hacked to a 2302?  Do I need that Ultra Sigma software?

Thanks,
Bob
Title: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on November 24, 2013, 01:02:45 am
I purchased a DS2102 several months ago.  When I first opened the box, the front panel said DS2202.  I said Yippee! they screwed up! ;D  That was short lived :(, the firmware internally said it was a DS2102 as well as the paperwork that went with it.  So with the 2202 moniker on the front, this unit is begging for a hack.

I've been reading these blogs and you guys are great, but there are so many procedures talked about I'm a little confused as to what I need to do, is there anywhere a concise set of instructions on how to hack my 2102 to a 2202?  Is it as simple as using the windows key gen?  Can it be hacked to a 2302?  Do I need that Ultra Sigma software?

Thanks,
Bob

Bob, I agree there is a need for clear and concise instructions. Problem is that the hacks don't seem to be providing consistent results. That said, its more likely users are not following the same upgrade path, I.e. following the exact same instructions. If you want the current recommended procedure, its below, but you may wish to have confirmation of those instructions from AndersAnd.

Two thirds of the way down this post.

https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg324768/?topicseen#msg324768 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg324768/?topicseen#msg324768)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 24, 2013, 02:04:10 am
I've been reading these blogs and you guys are great, but there are so many procedures talked about I'm a little confused as to what I need to do, is there anywhere a concise set of instructions on how to hack my 2102 to a 2202?  Is it as simple as using the windows key gen?  Can it be hacked to a 2302?  Do I need that Ultra Sigma software?
Just follow my step-by-step guide methodically here: 
https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg324768/#msg324768 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg324768/#msg324768)

Can it be hacked to a 2302?
No there's no known way to upgrade to DS2302. You can only upgrade to DS2202.
One member somehow ended up with a DS2302 while trying to upgrade to DS2202, but he doesn't know exactly how this happened and noone has been able to replicate it.

Do I need that Ultra Sigma software?
No, just enter the generated key directly in the right scope menu using the scopes knobs and buttons. No softwqre is needed.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mickpah on November 24, 2013, 07:18:11 am
HI
anyone tried entering a key after their DO832 has had the thermal retrofit ?
The job sheet shows new firmware 1.08 was installed as well.
I'm not having much luck. but not sure I'm doing it correctly either, not that there much I can for wrong other than a typo.
getting a sinking feeling Rigol have changed the key algorithm 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bandgap on November 24, 2013, 02:21:10 pm
Can it be hacked to a 2302?
No there's no known way to upgrade to DS2302. You can only upgrade to DS2202.
One member somehow ended up with a DS2302 while trying to upgrade to DS2202, but he doesn't know exactly how this happened and noone has been able to replicate it.

I'm pretty certain a couple of us have been able to get a DS2302. I can't remember the other person, but he's earlier in the thread. I read about his success and then minutes later was successful myself at doing it. The rest of what you say is correct, though. We don't know exactly how it happened.  :-[

-Clayton
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on November 24, 2013, 02:30:25 pm
I'm pretty certain a couple of us have been able to get a DS2302. I can't remember the other person, but he's earlier in the thread. I read about his success and then minutes later was successful myself at doing it. The rest of what you say is correct, though. We don't know exactly how it happened.  :-[

But has anyone actually tested the 300MHz bandwidth as happened after the other 'upgrades'?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on November 24, 2013, 03:21:34 pm
I'm pretty certain a couple of us have been able to get a DS2302. I can't remember the other person, but he's earlier in the thread. I read about his success and then minutes later was successful myself at doing it. The rest of what you say is correct, though. We don't know exactly how it happened.  :-[

But has anyone actually tested the 300MHz bandwidth as happened after the other 'upgrades'?

Good question.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bob11746 on November 24, 2013, 04:28:53 pm
AndersAnd,
Thanks for the reply.  I noticed that you suggest upgrading the firmware to the latest, yet others are concerned that one of these days the latest firmware update will prevent using keys that allow upgrading any farther than the instrument you purchased.  I just requested a firmware update and they asked for my FW#, model, and serial number.  I suspect it's only a matter of time before Rigol takes affirmative action and we're talking about the "good old days" of hacking an upgrade.

My current firmware is 00.01.00 and the HW is 1.0.  These sound pretty early compared to others on this blog, yet I only purchased it April of this year.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on November 24, 2013, 09:10:39 pm
HI
anyone tried entering a key after their DO832 has had the thermal retrofit ?
The job sheet shows new firmware 1.08 was installed as well.
I'm not having much luck. but not sure I'm doing it correctly either, not that there much I can for wrong other than a typo.
getting a sinking feeling Rigol have changed the key algorithm

Rigol has changed the DP832 keys.

How it works:
1 Download firmware at http://www.riglol.3owl.com/firmware/DP832.rar (http://www.riglol.3owl.com/firmware/DP832.rar)
2 Downgrade firmware to 01.06.00
3 Generate Key on riglol.3owl.com
4 Install the keys
5 Upgrade firmware to 01.08.00
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mickpah on November 24, 2013, 09:25:53 pm
thank you !  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: glano on November 25, 2013, 06:13:56 am
Can anyone mirror the DP832.rar?  Seems like http://www.riglol.3owl.com/ (http://www.riglol.3owl.com/) is getting DDOS something fierce.
Title: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on November 25, 2013, 08:48:06 am

Can anyone mirror the DP832.rar?  Seems like http://www.riglol.3owl.com/ (http://www.riglol.3owl.com/) is getting DDOS something fierce.

It's working for me, but I'll mirror the firmwares too here: http://rigol.avotronics.co.uk
I'll get to that later today, for some reason its been mirroring riglol.3.owl main page but not the firmware directory.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on November 25, 2013, 07:31:13 pm
I've mirrored the firmware(s) at http://rigol.avotronics.co.uk (http://rigol.avotronics.co.uk)
For some reason I'm having trouble mirroring subdirectories at 3owl but I'm using a workaround for now.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 25, 2013, 07:35:47 pm
HI
anyone tried entering a key after their DO832 has had the thermal retrofit ?
The job sheet shows new firmware 1.08 was installed as well.
I'm not having much luck. but not sure I'm doing it correctly either, not that there much I can for wrong other than a typo.
getting a sinking feeling Rigol have changed the key algorithm

Rigol has changed the DP832 keys.

How it works:
1 Download firmware at http://www.riglol.3owl.com/firmware/DP832.rar (http://www.riglol.3owl.com/firmware/DP832.rar)
2 Downgrade firmware to 01.06.00
3 Generate Key on riglol.3owl.com
4 Install the keys
5 Upgrade firmware to 01.08.00
I've mirrored the firmware(s) at http://rigol.avotronics.co.uk (http://rigol.avotronics.co.uk)
For some reason I'm having trouble mirroring subdirectories at 3owl but I'm using a workaround for now.
So the mirror link is http://rigol.avotronics.co.uk/riglol/firmware/DP832.rar (http://rigol.avotronics.co.uk/riglol/firmware/DP832.rar)
Maybe add a link to the firmware page/file on this front page: http://www.riglol.3owl.com (http://www.riglol.3owl.com) and add a note about not upgrading to 01.08.00 before entering keys.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tirulerbach on November 25, 2013, 08:33:40 pm
Hello,

I got a brand new unmodified DS2202_A_. So I would like to help to enhance the situation...  :-DD

I don't have mature experience in hacking this sort of stuff. How can I help you guys? Are there any pointers how to create a memory dump from this beast? Where to send the dump?  :-//

Please don't hesitate do contact me with your requests...  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on November 25, 2013, 08:50:42 pm
Hello,

I got a brand new unmodified DS2202_A_. So I would like to help to enhance the situation...  :-DD

I don't have mature experience in hacking this sort of stuff. How can I help you guys? Are there any pointers how to create a memory dump from this beast? Where to send the dump?  :-//

Please don't hesitate do contact me with your requests...  :-+

Where'd you get it?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on November 25, 2013, 09:23:33 pm
Hello,

I got a brand new unmodified DS2202_A_. So I would like to help to enhance the situation...  :-DD

I don't have mature experience in hacking this sort of stuff. How can I help you guys? Are there any pointers how to create a memory dump from this beast? Where to send the dump?  :-//

Please don't hesitate do contact me with your requests...  :-+

cool, can u request a firmware update with your distributor (even if there is none they might send u a current)  ? getting a .GEL file would be nize - other options, see the DG4000 thread - on howto do an JTAG memory dump.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 25, 2013, 09:32:37 pm
I got a brand new unmodified DS2202_A_. So I would like to help to enhance the situation...  :-DD

I don't have mature experience in hacking this sort of stuff. How can I help you guys? Are there any pointers how to create a memory dump from this beast? Where to send the dump?  :-//

Please don't hesitate do contact me with your requests...  :-+
cool, can u request a firmware update with your distributor (even if there is none they might send u a current)  ? getting a .GEL file would be nize - other options, see the DG4000 thread - on howto do an JTAG memory dump.
I saw you mentioned you were going to write a how-to guide for Rigol JTAG memory dumps here Cybernet: https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg298338/#msg298338 (https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg298338/#msg298338)
Did you ever get around to writing one?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tirulerbach on November 25, 2013, 11:06:55 pm

cool, can u request a firmware update with your distributor (even if there is none they might send u a current)  ? getting a .GEL file would be nize - other options, see the DG4000 thread - on howto do an JTAG memory dump.

i'm sorry, but because of different reasons, currently this is not an option...  :( (please, don't ask...) maybe in a few days to weeks this is possible...  ???
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tirulerbach on November 25, 2013, 11:08:37 pm
as requested, the detailed system informations:

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ZeroAviation on November 25, 2013, 11:15:53 pm
Hello,

I got a brand new unmodified DS2202_A_. So I would like to help to enhance the situation...  :-DD

I don't have mature experience in hacking this sort of stuff. How can I help you guys? Are there any pointers how to create a memory dump from this beast? Where to send the dump?  :-//

Please don't hesitate do contact me with your requests...  :-+

Where'd you get it?

Same question! Where did you get it?

CAN is the only thing holding me back on getting the 2000 series.
Title: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on November 25, 2013, 11:27:09 pm

HI
anyone tried entering a key after their DO832 has had the thermal retrofit ?
The job sheet shows new firmware 1.08 was installed as well.
I'm not having much luck. but not sure I'm doing it correctly either, not that there much I can for wrong other than a typo.
getting a sinking feeling Rigol have changed the key algorithm

Rigol has changed the DP832 keys.

How it works:
1 Download firmware at http://www.riglol.3owl.com/firmware/DP832.rar (http://www.riglol.3owl.com/firmware/DP832.rar)
2 Downgrade firmware to 01.06.00
3 Generate Key on riglol.3owl.com
4 Install the keys
5 Upgrade firmware to 01.08.00
I've mirrored the firmware(s) at http://rigol.avotronics.co.uk (http://rigol.avotronics.co.uk)
For some reason I'm having trouble mirroring subdirectories at 3owl but I'm using a workaround for now.
So the mirror link is http://rigol.avotronics.co.uk/riglol/firmware/DP832.rar (http://rigol.avotronics.co.uk/riglol/firmware/DP832.rar)
Maybe add a link to the firmware page/file on this front page: http://www.riglol.3owl.com (http://www.riglol.3owl.com) and add a note about not upgrading to 01.08.00 before entering keys.

Can't do anything about riglol or gotroots pages, but I've updated http://rigol.avotronics.co.uk to be more informative. Bit basic as I'm struggling with stupid ipad till tomorrow/Wednesday. You'd better check it for wrongness, wasn't sure if those instructions were just for dp832.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on November 26, 2013, 02:55:37 am
I got a brand new unmodified DS2202_A_. So I would like to help to enhance the situation...  :-DD

I don't have mature experience in hacking this sort of stuff. How can I help you guys? Are there any pointers how to create a memory dump from this beast? Where to send the dump?  :-//

Please don't hesitate do contact me with your requests...  :-+

cool, can u request a firmware update with your distributor (even if there is none they might send u a current)  ? getting a .GEL file would be nize -

I see the software version has changed to 2 as well.  It would be interesting to see the detailed SysInfo screen, for all the section Versions information.

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.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on November 26, 2013, 02:57:47 am
as requested, the detailed system informations:

Hey!  Where'd that come from?   :-[  Thanks.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: apelly on November 26, 2013, 03:35:51 am
I see the software version has changed to 2 as well.  It would be interesting to see the detailed SysInfo screen, for all the section Versions information.

There's a pic of my 2072a info earlier in the thread too, if you want to compare.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tsmith35 on November 26, 2013, 03:49:14 am
Comparing the two...

tirulerbach's info:
Model: DS2202A
Serial: DS2D.....
Software version: 00.02.00.00.04
Hardware version: 1.0.2.0.2
FPGA version -
SPU: 03.01.09
WPU: 00.07.01
CCU: 12.29.00
MCU: 02.13

apelly's info:
Model: DS2072A
Serial: DS2D15340.....
Software version: 00.02.00.00.04
Hardware version: 1.0.2.0.0
FPGA version -
SPU: 03.01.09
WPU: 00.07.01
CCU: 12.29.00
MCU: 02.13
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on November 26, 2013, 05:01:38 am
here we go - custom DS2000 firmware, based on FW 00.01.01.00.02 (imho latest)
tricked into believing its a 350Mhz model, thus enabling 200M BW limit & 1ns timebase.
i also tried 500Mhz, while this allows 500ps TB, it does not make a difference on screen (probably hitting some hardware limit)
the only thing i dont like is that the model type should be changed too as it still says DS2202.
i also tried options de-install/install - worked fine.


to the best of my knowledge the change does not affect the bootloader, its only a modification of the application payload, so i consider
it safe to play with - there is always the possibility to flash back a standard version. i killed it several times during testing, no problem whatsoever (just flash back another version)

nevertheless - no guarantees  whatsoever if u want to try this ! - no whining if something breaks !

CHG3_RILOL.GEL - > http://www.sendspace.com/file/ybkx21 (http://www.sendspace.com/file/ybkx21)
download, rename to "DS2000Update.GEL" -> put on USB stick -> install via bootldr method (power on + HELP)


Code: [Select]
./geltool -c -f CUSTOM/ASM/CHG4/CHG4_RILOL.GEL

model: DS2202
version: 00.01.01.00.02
bitmask: 0x7
num_of_sections: 0x12


section: #00: CRC:568EAD3C ADDR:20040000 LEN:0037D7DC [VALID CRC]
section: #01: CRC:5A3AC3C3 ADDR:20000000 LEN:0017CCA8 [VALID CRC]
section: #02: CRC:52C1A46B ADDR:20000000 LEN:00010F60 [VALID CRC]
section: #03: CRC:3F65CE51 ADDR:20020000 LEN:000322F6 [VALID CRC]
section: #04: CRC:CD2A7325 ADDR:200D6000 LEN:0000245A [VALID CRC]
section: #05: CRC:4CAC7870 ADDR:200C8000 LEN:00007FB4 [VALID CRC]
section: #06: CRC:454D5A80 ADDR:200F0000 LEN:000663F4 [VALID CRC]
section: #07: CRC:BCB8589E ADDR:20120000 LEN:00001D54 [VALID CRC]
section: #08: CRC:885A8C98 ADDR:20000000 LEN:0006DC62 [VALID CRC]
section: #09: CRC:B7481D18 ADDR:20040000 LEN:000032D8 [VALID CRC]
section: #10: CRC:D2B695F5 ADDR:20000000 LEN:00000B64 [VALID CRC]
section: #11: CRC:3F1C1BCC ADDR:20000C00 LEN:0003C598 [VALID CRC]
section: #12: CRC:1AF2DF9D ADDR:201E4C00 LEN:00000118 [VALID CRC]
section: #13: CRC:550735A2 ADDR:2003D400 LEN:00009010 [VALID CRC]
section: #14: CRC:5161CEE1 ADDR:201FD800 LEN:00001661 [VALID CRC]
section: #15: CRC:4B530B40 ADDR:20045000 LEN:000BB808 [VALID CRC]
section: #16: CRC:52C4EDFB ADDR:20100000 LEN:00046EF0 [VALID CRC]
section: #17: CRC:00000000 ADDR:20122800 LEN:00000000 [VALID CRC]
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mtdoc on November 26, 2013, 05:37:04 am
Holy S#%t!   :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Co6aka on November 26, 2013, 07:05:49 am
But... Where's the Star Trek screensaver...?  :-//

Oh man, I have good-ol-days hacking envy...  :-+



Any clues yet as to what 'n where the model/type byte/word gets built up from?  The model number perhaps, or...?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: poida_pie on November 26, 2013, 07:07:16 am
We need someone here with a fast rise time step signal to load this modified f/w of cybernet's and show us the differences in b/w.
I would load it if I had a decent step signal of about 1ns or a bit less. The fastest I have access to is the trigger out from my DS2072
which seems to be about 1.5ns risetime.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Abdu on November 26, 2013, 07:31:37 am
@ cybernet
Rise time = 0.35/BW
then
rise time (BW=200 MHz) = 1.75 ns (for DS2202 =1.8 ns)
rise time (BW=70 MHz) = 5 ns        (for DS2072 =5 ns)

this means the rise time of that the pulse generator is 5ns or the oscilloscope is 70 MHz.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mtdoc on November 26, 2013, 07:57:59 am
True enough about not drawing any conclusions about actual BW based on the RT  of the displayed pulse - and the need to be tested with a very fast risetime pulse ( or high enough frequency function generator to find the 3 dB limit).  But still, the abilty to change the timebase, BW limit, etc at will is a commendable achievement and (I think) means the only limitation now is the hardware. Way to go cybernet!  :clap:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Harvs on November 26, 2013, 08:01:45 am
A quick "qualitative" assessment from me.

The first overlay of the new firmware vs 200MHz hack, Red trace is the new firmware.  I guess you could argue there's some difference, but it's not conclusive.  Probably the signal being feed in doesn't have a high enough rise time.  I'm seeing around 1.5ns.

What is interesting though, is the second overlay, which is with the 200MHz limit applied.  There is an obvious drop in bandwidth compared to the "200MHz" firmware version without limits applied.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 26, 2013, 08:15:09 am
CHG3_RILOL.GEL - > http://www.sendspace.com/file/ybkx21 (http://www.sendspace.com/file/ybkx21)
download, rename to "DS2000Update.GEL" -> put on USB stick -> install via bootldr method (power on + HELP)

Code: [Select]
./geltool -c -f CUSTOM/ASM/CHG4/CHG4_RILOL.GEL

model: DS2202
version: 00.01.01.00.02
bitmask: 0x7
num_of_sections: 0x12


section: #00: CRC:568EAD3C ADDR:20040000 LEN:0037D7DC [VALID CRC]
section: #01: CRC:5A3AC3C3 ADDR:20000000 LEN:0017CCA8 [VALID CRC]
section: #02: CRC:52C1A46B ADDR:20000000 LEN:00010F60 [VALID CRC]
section: #03: CRC:3F65CE51 ADDR:20020000 LEN:000322F6 [VALID CRC]
section: #04: CRC:CD2A7325 ADDR:200D6000 LEN:0000245A [VALID CRC]
section: #05: CRC:4CAC7870 ADDR:200C8000 LEN:00007FB4 [VALID CRC]
section: #06: CRC:454D5A80 ADDR:200F0000 LEN:000663F4 [VALID CRC]
section: #07: CRC:BCB8589E ADDR:20120000 LEN:00001D54 [VALID CRC]
section: #08: CRC:885A8C98 ADDR:20000000 LEN:0006DC62 [VALID CRC]
section: #09: CRC:B7481D18 ADDR:20040000 LEN:000032D8 [VALID CRC]
section: #10: CRC:D2B695F5 ADDR:20000000 LEN:00000B64 [VALID CRC]
section: #11: CRC:3F1C1BCC ADDR:20000C00 LEN:0003C598 [VALID CRC]
section: #12: CRC:1AF2DF9D ADDR:201E4C00 LEN:00000118 [VALID CRC]
section: #13: CRC:550735A2 ADDR:2003D400 LEN:00009010 [VALID CRC]
section: #14: CRC:5161CEE1 ADDR:201FD800 LEN:00001661 [VALID CRC]
section: #15: CRC:4B530B40 ADDR:20045000 LEN:000BB808 [VALID CRC]
section: #16: CRC:52C4EDFB ADDR:20100000 LEN:00046EF0 [VALID CRC]
section: #17: CRC:00000000 ADDR:20122800 LEN:00000000 [VALID CRC]
Great work.  :-+
I noticed the uploaded filename is CHG3_RILOL.GEL, but the code section below it says CUSTOM/ASM/CHG4/CHG4_RILOL.GEL
Is the code section for a different file than the uploaded one?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on November 26, 2013, 08:21:36 am
Just tried the modified firmware, and have to report that this is not OK.

The system behaves OK in 1 channel mode, rise time is 1.3 nS.... > It measures also correctly in 1 and 2 nS TB setting

In two channel mode (1nS TB), the trigger point shifts about 4 divisions, and measures rise time wrong as 730 pS....

In both modes (1 or 2 ch) there is no significant increase in rise time

This is basically the same behavior as I reported 4 months ago, while we were still playing with the FRAM...... 


Measured with Tek 284 pulser
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on November 26, 2013, 10:14:23 am
The first overlay of the new firmware vs 200MHz hack, Red trace is the new firmware.  I guess you could argue there's some difference, but it's not conclusive.

I'd say not.  The variance is too small.

Quote
What is interesting though, is the second overlay, which is with the 200MHz limit applied.  There is an obvious drop in bandwidth compared to the "200MHz" firmware version without limits applied.

There is an obvious drop.  However, the unit with the 200 MHz hack actually has a BW closer to 230 MHz, with no way to engage filters at 200 MHz.  What you've shown is consistent with a 230/200 difference.  Not 350/200 difference.  To know for sure though (where the limiting factor is), you'd need a source pulse with <1 nS rise time.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on November 26, 2013, 12:50:20 pm
thx for playing with this (it was 6AM .. so i left it at the screenshots) - from the postings above i take:

1. it only changes the TB (to 1ns) but not the bandwidth limit (no 350Mhz).
2. channel 2 is offset - didnt try, but will - maybe a cal helps with that
    2. actually with 500ps TB what u describe happens on CH1 too. (visual resolution of TB is 1ns, and trigger jumps)
3. yes i pasted the wrong log-file, its CHG4 (500mhz) attempt - same principle however ;)
4. testing was DG4202 with 50Mhz Square + Pulse - got nothing faster.

what i changed is what is read from the FRAM during boot - e.g. the function returns a static 0x2 (=DS2302) - but that seems to affect only TB.
there is a strtol based MHZ value to string function which sets other stuff, could be thats what changes the BW filter - will try that one next and post a CHG?_RIGLOL.GEL when its ready.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on November 26, 2013, 12:53:43 pm
Do you have a DSA815-TG or other spectrum analyzer with tracking generator? If so, you could enable the TG at zero-span and turn up the frequency until you reach the calculated -3db point on the DS2000.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on November 26, 2013, 12:55:01 pm
@ cybernet (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/?action=dlattach;attach=68693;image)

Note: Probe used Agilent 10073D (500MHz).
Using a 1K probe the BW must be closer to the real oscilloscope BW.

Set BW to 200MHz:

(https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/?action=dlattach;attach=68689;image)

Set BW no limit:

(https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/?action=dlattach;attach=68691;image)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 26, 2013, 01:07:53 pm
@ cybernet

Note: Probe used Agilent 10073D (500MHz).
So it does change the BW to 350 MHz after all?
What signal did you measure it with and what's it's true rise time? (If you know it).
Have you measured the test signal on an even higher frequency scope?

Using the 10%-90% rise time to frequency conversion formula for Gaussian-response oscilloscopes:
Source:
Agilent Application Note 1420
Understanding Oscilloscope Frequency Response and Its Effect on Rise-Time Accuracy

http://cp.literature.agilent.com/litweb/pdf/5988-8008EN.pdf (http://cp.literature.agilent.com/litweb/pdf/5988-8008EN.pdf)

0.35 / 1.500 ns = 233.3 MHz

0.35 / 1.120 ns = 312.5 MHz

Also a lot of overshoot in 350 MHz mode that you can't see with 200 MHz BW limit because it's filtered out.

@ cybernet
Rise time = 0.35/BW
then
rise time (BW=200 MHz) = 1.75 ns (for DS2202 =1.8 ns)
rise time (BW=70 MHz) = 5 ns        (for DS2072 =5 ns)

this means the rise time of that the pulse generator is 5ns or the oscilloscope is 70 MHz.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on November 26, 2013, 01:11:56 pm
What signal did you measure it with and what's it's true rise time?
Altera cyclone II output.
  - Real oscilloscope BW ~ 900ps.
  - Altera signal rise time ?

Only give me more time to do more tests. (Lunchtime here)  :D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 26, 2013, 01:52:22 pm
  - Real oscilloscope BW ~ 900ps.
What do you mean by this? Is 900 ps the real rise time of the DS2000 series HW? Where did you get that number from?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on November 26, 2013, 01:53:55 pm
Yes. Oscilloscope Real BW is ~ 900ps.

Using my home made1K probe: (correct amplitude x2)
tr varies between 940 and 920ps.

(https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/?action=dlattach;attach=68695;image)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on November 26, 2013, 01:58:51 pm
Other test:
So, oscilloscope real BW is ~ 388MHz -> 350MHz.
https://www.eevblog.com/forum/blog/eevblog-306-jim-williams-pulse-generator/msg126162/#msg126162 (https://www.eevblog.com/forum/blog/eevblog-306-jim-williams-pulse-generator/msg126162/#msg126162)

(https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/?action=dlattach;attach=68697;image)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on November 26, 2013, 02:04:24 pm
Other test:
So, oscilloscope real BW is ~ 388MHz -> 350MHz.
Is channel 2 the same or similar (also 350 MHz BW) ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on November 26, 2013, 02:06:05 pm
Wow!

Carrington:  Why not go to 1ns for those screenshots!  Is this from the CHG3 GEL?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on November 26, 2013, 02:08:43 pm
Other test:
So, oscilloscope real BW is ~ 388MHz -> 350MHz.
Is channel 2 the same or similar (also 350 MHz BW) ?
In theory, yes.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on November 26, 2013, 02:12:43 pm
Wow!

Carrington:  Why not go to 1ns for those screenshots!  Is this from the CHG3 GEL?
Because at 2ns there are more portion of the waveform in the display (especially after the transition) and then the tr estimation is more correct.

(https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/?action=dlattach;attach=68700;image)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on November 26, 2013, 02:17:49 pm
Jim Williams Pulse Generator:

EEVblog #306 - Jim Williams Pulse Generator (https://www.youtube.com/watch?v=F-ZDiGmLvTs#ws)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: seronday on November 26, 2013, 02:31:33 pm

A quick check with an RF signal generator shows 3dB down between 290Mhz and 300Mhz.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on November 26, 2013, 02:35:27 pm

A quick check with an RF signal generator shows 3dB down between 290Mhz and 300Mhz.
No doubt, but I don't have a RF generator.   :-//


My homemade 1k probe:
(https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/?action=dlattach;attach=54975;image)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 26, 2013, 03:14:14 pm
A quick check with an RF signal generator shows 3dB down between 290Mhz and 300Mhz.
What does the same test show with 200 MHz BW limit activated?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on November 26, 2013, 05:56:14 pm
Can I get clarification; Are these all the models that these instructions cover?


DP832
DS1000z
DS2000
DS4000
DSA815

Read this topic, you will probably learn a lot and avoid some mistakes in the updating process. And maybe even be able to help other members out with questions or further hacking. Lazy people will skip this step.
Make sure your have updated your Rigol to the latest firmware version before entering any keys. Except for DP832 where Rigol has changed the keys in 01.08.00, so install firmware 01.06.00 before entering any keys. Then you can upgrade the firmware to 01.08.00 afterwards. Read here.
Go to studio25's RigLOL website: http://riglol.3owl.com (http://riglol.3owl.com) or Avotronics's mirror site: http://rigol.avotronics.co.uk/riglol (http://rigol.avotronics.co.uk/riglol)
Enter the Rigol serial number in the "Serial:" box.
Find the correct 4 letter code for your desired option in the tables at the above website (e.g. DSAZ to enable all options on DS2000 series scopes).
Enter this 4 letter code in the "Options:" box.
Don't enter anything into the "Privatekey:" box, but just hit generate and it will fill out the box automatically and then generate a valid license key in a pop-up window.
Enter this license key in the right menu on your Rigol (check your manual) and hit Apply.
Reboot, verify options installed and enjoy!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 26, 2013, 05:58:27 pm
Can I get clarification; What models do these instructions cover?
It covers all the models mentioned at http://riglol.3owl.com (http://riglol.3owl.com)
DP832; DS1000z; DS2000; DS4000 and DSA815.

DS2000A is not supported (yet).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: engr_rf on November 26, 2013, 06:11:57 pm
An excellent ultra-fast rise time (50ps) pulse generator that uses a readily available ADCMP580 evaluation board is described at http://www.starlino.com/build-a-really-fast-pulse-generator-50ps-rise-time-using-an-ultra-fast-sige-comparator.html. (http://www.starlino.com/build-a-really-fast-pulse-generator-50ps-rise-time-using-an-ultra-fast-sige-comparator.html.)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Co6aka on November 26, 2013, 09:09:00 pm
An excellent ultra-fast rise time (50ps) pulse generator...

Seems to me it's actually an edge-generator, which is what's really needed; a FAST and clean step from one voltage to another.

While not as fast, you can use something like the SN74LVC1G17DBVR to speed up the edges of "slow" logic:

http://www.ti.com/lit/ds/symlink/sn74lvc1g17.pdf (http://www.ti.com/lit/ds/symlink/sn74lvc1g17.pdf)

Got an old-n-slow pulse gen? Splice of of those in there.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jboard146 on November 26, 2013, 09:19:01 pm
Great job cybernet.

Is there a possibility of getting cybernet's BW GEL hack on the DS4014?

What do i need to do to help out to make this happen? I really want to see 500Mhz BW on my DS4014.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on November 26, 2013, 09:24:16 pm
yes i would say possible, i can also modify DS4k firmware now - but i dont have one to play with - so much more trial and error would be needed.
as the firmwares are "cousins" i'd rather figure it out for the DS2k first, and then attempt the DS4k - probably the same routines then that need to be "patched" ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on November 26, 2013, 09:27:36 pm
and if somebody wants to play with it - thats CHG4_RILOL - the 500Mhz attempt - gives 500ps TB - but i noticed odd behaviour (trigger is offset, and no real difference to 1ns)
i didnt do a cal btw (had no time) maybe that improves at least the trigger offset ..

http://www.filedropper.com/chg4rilol (http://www.filedropper.com/chg4rilol)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jboard146 on November 26, 2013, 09:27:52 pm
cybernet you rock.

We can test on my DS4014 once you finish figuring out the DS2k.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on November 26, 2013, 10:28:43 pm
DS1000Z

edit - forget what I said about the 500uV not working here - more to test first.

I also don't think there is a bandwidth difference between the 70MHz and 100Mhz models - my rise test test shows >200MHz.  See post #32 here:

https://www.eevblog.com/forum/testgear/rigol-ds1074z-inside-picture/msg337494/#msg337494 (https://www.eevblog.com/forum/testgear/rigol-ds1074z-inside-picture/msg337494/#msg337494)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on November 26, 2013, 10:59:58 pm
1ns TB, 200M BW Limit, and correct DS2302 Model type *yeah* ;-)

Orange noticed that the trigger is off by 3divs (lags behind) if u enable the 2nd channel - same happening, but only in 1ns mode.
maybe that is the reason why there is no official DS2302 version - anyhow i can live with that small limitation as it vanishes above 1ns TB

here is the version that will take care of model type string

http://www.filedropper.com/ds2302rilol (http://www.filedropper.com/ds2302rilol)

the "recalc" of the string is triggered by option un/install - so flush keys, and reapply them and it will become active.

did a selfcal on top of that - everything good.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on November 26, 2013, 11:14:43 pm
cybernet you rock.

We can test on my DS4014 once you finish figuring out the DS2k.

post me a link pls to the latest DS4k firmware, and i will try to repeat bel^h^h^h above stuff for the DS4k
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Circlotron on November 26, 2013, 11:47:52 pm
Missing the glaringly obvious here!
When you bring up the System Info screen it now ought to show "RIGLOL TECHNOLOGIES"  ^-^
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 26, 2013, 11:49:15 pm
Latest DS4k firmware is still 00.02.00 (00.02.00.00.04) according to Rigol:
http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm (http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm)

DS4k firmware changelog: https://www.eevblog.com/forum/testgear/rigol-ds4000-firmware-version/msg281248/#msg281248 (https://www.eevblog.com/forum/testgear/rigol-ds4000-firmware-version/msg281248/#msg281248)

Don't know if anyone has uploaded it here before, but "H.O" who has posted in this topic earlier, mentioned upgrading to it in this topic: https://www.eevblog.com/forum/testgear/rigol-ds4000-firmware-version/msg281308/#msg281308 (https://www.eevblog.com/forum/testgear/rigol-ds4000-firmware-version/msg281308/#msg281308)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on November 26, 2013, 11:54:12 pm
Missing the glaringly obvious here!
When you bring up the System Info screen it now ought to show "RIGLOL TECHNOLOGIES"  ^-^

guess what was my first attempt in modifying a gel file ;-) - but it really seems to come from the FPGA or something - i replaced every single RIGOL string ... didnt work out.
i rather dig into booting something of my own next - dumping FRAM/FLASH etc .. whatever could be interesting - and last but not least, running a uclinux kernel would be sweet ...
Title: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on November 26, 2013, 11:55:49 pm
I'm going to run something to... away!
This is over my head by a DS2072
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: eV1Te on November 27, 2013, 12:01:12 am
DS1000Z - remove the 500uV option - it does NOT work.  It will let you go to 500uV but will push the signal low off the screen.  I also don't think there is a bandwidth difference between the 70MHz and 100Mhz models - my rise test test shows >200MHz.  See post #32 here:

https://www.eevblog.com/forum/testgear/rigol-ds1074z-inside-picture/msg337494/#msg337494 (https://www.eevblog.com/forum/testgear/rigol-ds1074z-inside-picture/msg337494/#msg337494)

I have not had time to test every feature, just got my DS1084Z-S today. Have you done the Self-Calibration after enabling 500 uV option? My unit had significant DC offset from factory, that disappeared after Self-Calibration.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on November 27, 2013, 12:19:00 am
@ cybernet

CHG4_RILOL seem not work appropriately. If I set 500ps then I press RUN/STOP -> Time base selector can't set 500ps anymore until I return to press RUN/STOP.
And in dots mode, and a base time of 500ps I see two dots per div. with sample at 2Gsa/s (only one chnnel).

1K probe for both:

(https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/?action=dlattach;attach=68758;image)

(https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/?action=dlattach;attach=68756;image)

In my humble opinion for the DS2072 -> 350MHz of BW is more thant enough.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on November 27, 2013, 12:23:02 am
My unit always says DS2202 even with your latest file cybernet.  I tried installing a key with no 100M or 200M, then 200M, then both, all 3 = DS2202.  1ns timebase and BW Limit is Off/20m/100m/200m still though!

Nevermind a key uninstall did move it to DS2302, reinstalled and it stayed.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jboard146 on November 27, 2013, 12:26:48 am
I tried requesting a copy of the firmware from the vendor who I bought my DS4014 from.

I didn't hear back to them today, but I'll call them tomorrow. Hopefully with the holiday in the US on Thursday they will just give it to me to get me off the phone so they can go home early tomorrow.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on November 27, 2013, 12:30:36 am
I'll try the version 2302 now.  :D
It works exactly the same that CHG3_RILOL.GEL . Not a problem for me.

@ cybernet: Thank you very much for your hard work. I envy you, but in a healthy way.  :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on November 27, 2013, 01:19:58 am
DS1000Z - remove the 500uV option - it does NOT work.  It will let you go to 500uV but will push the signal low off the screen.

Alan, did you perform a SelfCal, and that didn't correct the shift?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: stormbr on November 27, 2013, 01:21:44 am
My ds2072 hw2.0 not recognize pendrive@fat32 and the option on menu utility/io settings/usb device/ "auto detect" is unavailable.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on November 27, 2013, 01:26:37 am
Alan, did you perform a SelfCal, and that didn't correct the shift?

That is true, you have a good point, let me try that!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on November 27, 2013, 03:09:08 am
Alan, did you perform a SelfCal, and that didn't correct the shift?

That is true, you have a good point, let me try that!

Nope, still doesn't work after a self cal.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: seronday on November 27, 2013, 04:13:17 am
Frequency Response Plots for DS2000 series 300Mhz firmware.

The measurements were made using a 50 ohm signal source to a "T" piece with a 50 ohm termination on the DSO.
This means that the high frequency response (~150Mhz +) will actually be slightly better than shown in the plot, due to the loading effect of the DSO channel input capacitance.

Unfortunately I do not have access to a measuring head at present, to allow me to compensate for this loading effect.

While doing these measurements I found that with Ch1 and Ch2 turned on, the displayed waveform does not change when switching between 1nS and 2nS/div. It is displayed as 2nS/div. The time/div readout changes but the only change to the displayed wave form is the trigger point.
If there is a frequency measurement active on the screen, it will read double the correct value when on the 1nS/div range.
The hardware freq counter reading remains correct .
With only one Channel turned on, all is well.

Also had a quick look at the 500Mhz firmware ver.
The frequency response is still like a DS2202. (3dB down at ~240Mhz).
The 500pS and 1nS/div behave in the same way as described above for the 300Mhz ver except it now happens with only one channel on.

Thanks for sharing the fruits of your long, busy, sleepless nights cybernet.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on November 27, 2013, 04:41:01 am
Frequency Response Plots for DS2000 series 300Mhz firmware.
Thanks for supplying those. You can also compare yours to plots made by Wim13 last June (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg251044/#msg251044) of DS2072 vs DS2202:

(https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/?action=dlattach;attach=52570)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bandgap on November 27, 2013, 05:03:49 am
While doing these measurements I found that with Ch1 and Ch2 turned on, the displayed waveform does not change when switching between 1nS and 2nS/div. It is displayed as 2nS/div. The time/div readout changes but the only change to the displayed wave form is the trigger point.
If there is a frequency measurement active on the screen, it will read double the correct value when on the 1nS/div range.
The hardware freq counter reading remains correct .
With only one Channel turned on, all is well.

I can confirm that my unit with the official firmware but accidentally upgraded to DS2302 with keys has this same behavior.

-Clayton
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Teneyes on November 27, 2013, 06:16:14 am
@Cybernet     Great Work, 2 cases of Radler for you!   :-+   :-+

Could the CAN decoding feature be in the GEL also??
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: maelli on November 27, 2013, 10:19:30 am
DS7072  HW version 2 (left the factory 2013-09-23)

Rigol RP3300A probe, Jim Williams style pulse generator

So I have a decent scope for less than a thousand....     :)

thanks to everybody who contributed!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: flolic on November 27, 2013, 10:58:05 am

Rigol RP3300A probe, Jim Williams style pulse generator

You really should connect pulse generator directly to scope input, via 50 ohm pass through terminator  ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: stormbr on November 27, 2013, 04:40:08 pm
My ds2072 (hacked to 200mhz) not update to ds2302 (300mhz), i bought other pendrive that was detected, but i haven't success again.

Can anybody help me ?

Thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on November 27, 2013, 04:41:22 pm
My ds2072 (hacked to 200mhz) not update to ds2302 (300mhz), i bought other pendrive that was detected, but i haven't success again.

Can anybody help me ?

Thanks

uninstalled/reinstalled key ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: stormbr on November 27, 2013, 04:46:04 pm
Ok, I'll try uninstall the keys, but i dont know to do this.

I'll research the procedure to uninstall too.

Thanks Cybernet for your help, great work.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on November 27, 2013, 04:53:16 pm
I have not had time to test every feature, just got my DS1084Z-S today. Have you done the Self-Calibration after enabling 500 uV option? My unit had significant DC offset from factory, that disappeared after Self-Calibration.

Interesting.  Even after a self cal switching to 500uV for me pushed the signal off the screen...  Maybe you have hardware that supports it and mine does not...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 27, 2013, 05:01:46 pm
Ok, I'll try uninstall the keys, but i dont know to do this.

I'll research the procedure to uninstall too.

Thanks Cybernet for your help, great work.
Use the SCPI command :SYSTem:OPTion:UNINSTall to uninstall keys.

If you're not familiar with SCPI commands, read your scope's user's manual + programming guide, both documents has info about SCPI commands.

You can search this topic for :SYSTem:OPTion:UNINSTall for more info.

SCPI = Standard Commands for Programmable Instruments https://en.wikipedia.org/wiki/Standard_Commands_for_Programmable_Instruments
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sync on November 27, 2013, 05:11:28 pm
I have not had time to test every feature, just got my DS1084Z-S today. Have you done the Self-Calibration after enabling 500 uV option? My unit had significant DC offset from factory, that disappeared after Self-Calibration.

Interesting.  Even after a self cal switching to 500uV for me pushed the signal off the screen...  Maybe you have hardware that supports it and mine does not...
On my DS1074Z the self calibration doesn't correct the DC offset too. Firmware version 00.02.00.SP1.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: eV1Te on November 27, 2013, 05:20:49 pm
I have not had time to test every feature, just got my DS1084Z-S today. Have you done the Self-Calibration after enabling 500 uV option? My unit had significant DC offset from factory, that disappeared after Self-Calibration.

Interesting.  Even after a self cal switching to 500uV for me pushed the signal off the screen...  Maybe you have hardware that supports it and mine does not...
On my DS1074Z the self calibration doesn't correct the DC offset too. Firmware version 00.02.00.SP1.

Just to clarify, I have not enabled 500 uV/div resolution on my scope. But I had ca. 0.5 div offset on 1 mV/div from factory, and that corrected it self quite well after self cal.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on November 27, 2013, 06:00:48 pm
Just to clarify, I have not enabled 500 uV/div resolution on my scope. But I had ca. 0.5 div offset on 1 mV/div from factory, and that corrected it self quite well after self cal.

I'm with you now.  Given that, I'd say the 500uV option is probably a no go unless someone has it working for them.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on November 27, 2013, 07:30:33 pm

any DS4k volunteers ?
this sets model type 0x4 = 500mhz
(whatever channel#, whatever MSO y/n it leaves that intact)

the approach should be the same as with DS2k - you need to trigger option un/install to make it effective.
it could be that the actual model type string is not updated, but TB upgrade should work.
anyhow no guarantees for anything like always  ...  8)

download, rename to DS4000Update.GEL -> http://www.filedropper.com/ds405xupdate (http://www.filedropper.com/ds405xupdate)

Code: [Select]
[cn@warpnas01 CUSTOM]$ ../../../DS2000_New/gelfile/geltool -f DS405XUpdate.GEL -c

model: DS4064
version: 00.02.00.00.04
bitmask: 0x7
num_of_sections: 0x10

section: #00: CRC:09081ED3 ADDR:20040000 LEN:3511236 OFS:488 [VALID CRC]
section: #01: CRC:D8B156BB ADDR:20000000 LEN:2574652 OFS:3511724 [VALID CRC]
section: #02: CRC:52C1A46B ADDR:20000000 LEN:69472 OFS:6830282 [VALID CRC]
section: #03: CRC:5B8BE417 ADDR:20020000 LEN:216136 OFS:6899754 [VALID CRC]
section: #04: CRC:35E14CB3 ADDR:200D6000 LEN:9434 OFS:7115890 [VALID CRC]
section: #05: CRC:D40982DF ADDR:200C8000 LEN:30964 OFS:7125324 [VALID CRC]
section: #06: CRC:C7AC2358 ADDR:200FA000 LEN:379408 OFS:7156288 [VALID CRC]
section: #07: CRC:694D10C1 ADDR:20120000 LEN:7508 OFS:7535696 [VALID CRC]
section: #08: CRC:E8B07094 ADDR:20000000 LEN:422268 OFS:7543204 [VALID CRC]
section: #09: CRC:3B9049C9 ADDR:20040000 LEN:12364 OFS:7965472 [VALID CRC]
section: #10: CRC:D2B695F5 ADDR:20000000 LEN:2916 OFS:7977836 [VALID CRC]
section: #11: CRC:3F1C1BCC ADDR:20000C00 LEN:247192 OFS:7980752 [VALID CRC]
section: #12: CRC:63503009 ADDR:201E4C00 LEN:10876 OFS:8227944 [VALID CRC]
section: #13: CRC:0A983326 ADDR:2003D400 LEN:37204 OFS:8238820 [VALID CRC]
section: #14: CRC:4B530B40 ADDR:20045000 LEN:768008 OFS:8276024 [VALID CRC]
section: #15: CRC:00000000 ADDR:20122800 LEN:0 OFS:9044032 [VALID CRC]


[cn@warpnas01 CUSTOM]$ ls -l *.GEL
-rwxr-xr-x 1 cn smbusers 9044032 Nov 27 18:15 DS4000Update.GEL
-rw-r--r-- 1 cn smbusers 9044032 Nov 27 18:24 DS405XUpdate.GEL
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gallymimus on November 27, 2013, 08:40:58 pm


Thanks for this cybernet.  I've asked a friend who has a ds4000 to check it out (He might be too afraid to try it though  :-[
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on November 27, 2013, 09:36:08 pm
is that a known menu on the DS2000 ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 27, 2013, 09:44:53 pm
is that a known menu on the DS2000 ?
Not sure if it is for DS2000, but cosmos mentioned very similar [Project screen #1, Project screen #2 and Project screen #3] for DS4000 earlier in this topic:
Found something for the DS4000 that was new to me.

The key sequence for getting extended version info also open other stuff.
to enter and exit : Trig menu -> edge. then in one quick sequence  F7 + F6 + F7 + Utililty

EDIT: (Clarification)
to enter and exit :
Trig menu -> edge.
then in one quick sequence  [MENU7_R] + [MENU6_R] + [MENU7_R] + [Utililty]
(from marmads post earlier in tread)
/EDIT

Now I have:
extended version info under Utility -> system -> System info 
extended power info under Utility -> system -> SelftestInfo
a new sub menu under Utility(2) (second screen) called Project
under project there is now

screen #1:
Screentest
Key test
AuxTest
Gain1
Gain2
-
-

screen #2:
-
EqualCal
DealyCal
-
-
Resumecal

screen #3:
Probecal
Factory
-
-
-
-
-
return

I wonder if there might be even more interesting menus to be activated like this ... how did people find the unlocking key sequence in the first place?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on November 27, 2013, 09:47:03 pm
is that a known menu on the DS2000 ?

Yes - sub-menus of the hidden Utility Menu.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cosmos on November 27, 2013, 09:50:47 pm
One DS4014 volunteer stepping up ...
That worked very well, thank you very much.    :-+  :-+

I now have TB 2ns and 1ns.
Model number did not change.
I kept all the options I had entered earlier (riglol generated).

The fastest FPGA signal (Spartan 6, normal output drive) that I could find in a hurry was reading as 1.9 to 2.1ns rise and fall time before (DS4014) and are now around 1.24ns ...

This is with a 1GHz 1k probe into 50ohm input, the FPGA signal has no GND close by so GND is from the probe lead folded into a 5cm lead and it then does a detour on the PCB as well..

I have seen sub 1ns numbers as fall time but that was with significant undershoot and seemed dependent on the horizontal position so I do not trust it.
I think 1.24ns might be is as fast as the standard IO driver in the FPGA can go.
I need to find myself a better test signal or an RF generator.

This looks very good so far.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on November 27, 2013, 09:54:19 pm
is that a known menu on the DS2000 ?

Yes - sub-menus of the hidden Utility Menu.

seems like that flag is a enabler for a lot of stuff ...  >:D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on November 27, 2013, 09:55:58 pm
One DS4014 volunteer stepping up ...
That worked very well, thank you very much.    :-+  :-+

np, do you also see BW limit options raised for CH1-??? ? like it happend on the DS2000. (if the DS4k has such a setting)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cosmos on November 27, 2013, 10:11:11 pm
yes BW options are now: OFF, 20M, 100M, 200M

selecting 100M I get about the same rise and fall as I had before (~2ns).
selecting 200M I get around 1.5ns
selecting OFF I get mostly 1.28ns rise and 1.16ns fall (for the others it also like that with slightly lower number for fall time)
If I measure with cursors I get the same results (knowing that the IO is driven from 2.5V rails I can set the 10% and 90% referred to that)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigol-Friend on November 27, 2013, 10:23:41 pm
Cybernet:

The second bottle of champain is waiting for you.    :clap:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on November 27, 2013, 10:33:53 pm
Hello,

I got a brand new unmodified DS2202_A_. So I would like to help to enhance the situation...  :-DD

I don't have mature experience in hacking this sort of stuff. How can I help you guys? Are there any pointers how to create a memory dump from this beast? Where to send the dump?  :-//

Please don't hesitate do contact me with your requests...  :-+

cool, can u request a firmware update with your distributor (even if there is none they might send u a current)  ? getting a .GEL file would be nize - other options, see the DG4000 thread - on howto do an JTAG memory dump.

Cyberdude, if it's not too much trouble, can you create an MD5 checksum of any firmwares you modify please?
I'm dumping them on http://rigol.avotronics.co.uk (http://rigol.avotronics.co.uk) and it would be a good idea to have this. Thank AndersAnd for the idea....  :-DD
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cosmos on November 27, 2013, 10:38:40 pm
DS4k:
Found a better ground point where I can use a 1cm spring and now I get rise and fall times in the 800-900ps range.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on November 27, 2013, 10:41:06 pm
by using a decent os, you can do that with ... (for whatever reason ;-)
md5sum <file>


btw - by enabling the project menu - you also enable the :DBGCMD:STAT? RX|TX|CLR|Q|PARSE SCPI commands
i suspect there is more to that, then the debug outputs ... something like reading/writing memory would rock ! ;-)



Code: [Select]
./dbgstat.py 10.146.248.190
(u16HostFetchErr = 0),(u16FifoLenErr = 0),(u32NoDataCnt = 24),(u32WaitDataCnt = 17),(u16FmtDataErr = 0),(u16FmtTypeErr = 0),(u16StateMachineErr = 0),(u16DeadLockCnt = 0),(u16SysFmtErr = 0),(u16AddrAccessErr = 0),(u32TotalTxByte = 7361),(u32CurTxByte = 124)
(u16InteruptCnt = 0),(u16WInQCnt = 0),(u16RxDataCnt = 0),(u16ProCnt = 48),(u16IBFullCnt = 0),
(u16InvalidCharacter = 0),(u16KeywordNotFound = 2),(u16CmdNotFound = 0),(u16TooManyKeyword = 0),(u16LastKeywordOmitted = 0),(u16CmdSNErr = 0),(u16InvalidCallBackFunc = 0),(u16CmdExcuteErr = 0),
(u16NoFreeNode = 0),(u16QIsFull = 0),(u16QIsEmpty = 0),(u16RxBufOverflow = 0),(u16RxDataPtrNull = 0),(u16RxDataLenErr = 0),
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on November 27, 2013, 10:43:53 pm
by using a decent os, you can do that with ... (for whatever reason ;-)

md5sum <file>

Yup, I can produce one no problem, but I figured it should be created on the host system before it got shipped around the net. If you think not, I'll create one.  :-//
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on November 27, 2013, 10:47:45 pm
Yup, I can produce one no problem, but I figured it should be created on the host system before it got shipped around the net. If you think not, I'll create one.  :-//

whats the point in a md5 sum ? if there are checksums in 2 levels all over the GEL file ? try to change byte and flash it ... wont happen ;)
same with whats the point of a website providing a md5 sum on their homepage together with the download link ? - 1 more step for somebody that replaces a download with something evil to tamper with ?
imho completely useless except maybe for a backup software ... ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on November 27, 2013, 10:54:30 pm
Yup, I can produce one no problem, but I figured it should be created on the host system before it got shipped around the net. If you think not, I'll create one.  :-//

whats the point in a md5 sum ? if there are checksums in 2 levels all over the GEL file ? try to change byte and flash it ... wont happen ;)
same with whats the point of a website providing a md5 sum on their homepage together with the download link ? - 1 more step for somebody that replaces a download with something evil to tamper with ?
imho completely useless except maybe for a backup software ... ;)

I see your point. I'm not familiar enough with the concept, but I guess the idea is to make sure that the file one downloads to ones computer has not been damaged in transit? I guess if this ain't possible in this instance, the MD5 is useless yes.

As you also pointed out, you can't flash any modern commercial device without it running checksum validation before flash. So I guess it is pointless... I told you to blame AndersAnd  :-DD
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on November 27, 2013, 11:20:06 pm
DS4k:
Found a better ground point where I can use a 1cm spring and now I get rise and fall times in the 800-900ps range.
Probably the real rise time can reach ~ 650ps (maybe even less).  :)

More fun (make one): http://people.osmocom.org/tnt/hw/pulse_gen/ (http://people.osmocom.org/tnt/hw/pulse_gen/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on November 27, 2013, 11:52:42 pm
Re. cybernet's method for converting a DS2062 to to DS2302:

  1. Is there anyway to retain the original Serial Number, or to re-insert it later?

  2. Is it possible to return to DS2062, or D2202 if we find a significant issue with DS2302 in the future?

Thank you very much CYBERNET for all  of your fantastic tools you have come up with and shared, and for all the very generous help you have provided.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: clifford on November 28, 2013, 12:08:14 am
I see your point. I'm not familiar enough with the concept, but I guess the idea is to make sure that the file one downloads to ones computer has not been damaged in transit? I guess if this ain't possible in this instance, the MD5 is useless yes.

Usually the idea would rather be to make sure that no one has tampered with the file and you are indeed downloading what the original poster uploaded.

But for this purpose at least something like sha256 would be more suited than md5. (Afaik there is still no practical preimage attack on md5, but nevertheless it is not really considered a secure cryptographic hash anymore. But then SHA-2 was developed by NSA, so..)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on November 28, 2013, 12:15:19 am
if i temper with the file, i temper with the website that displays the md5/sha/<otherhash> too -> e.g. useless
Title: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on November 28, 2013, 12:38:46 am

if i temper with the file, i temper with the website that displays the md5/sha/<otherhash> too -> e.g. useless

Not if the hash wasn't available to the tamperererererrrr tamperorrr temperer, what the hell is word lol.

I guess the hash could be stored in another location or auto mailed to the downloader.

I think this isn't useful here, I agree.

Where it is useful is when you're dealing with open source and public contributor servers etc.
But as you say, if the hash is accessible too then its all bollocks.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jboard146 on November 28, 2013, 02:29:36 am
cybernet awesome! It does work!

I don't have anything here to generate signals to measure up to 500Mhz, but on initial look it is somewhere near it.

The sine wave in is 200Mhz at 1Vpp. I'm getting ~1.62db drop at 200Mhz. 8)
The response is flat to about 170Mhz. It just starts to drop off them there.

It is still showing DS4014, but so what.

Between this hack and the decoder options hack I've got a $8-9k scope.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Uup on November 28, 2013, 04:04:46 am
i think Uuup did extensive testing on the option codes, but i think its worth a shot to repeat that with a little bruteforce given the following facts:

there are 8 different options that can be enabled (0-4 = the known ones) 5,6,7 = are bandwidth upgrades (so the bandwidth code should be the 3 bits left to the known codes ... *guessworkhere*)

i can see code that uses the 12 LSB bits of the option code, and does "something" with it - there are code references that then go on to change the model type (=bandwidth change), but without proper BSS setup its not possible to figure it out anymore.
Just probing the indvidiual 5,6,7th bits might not be enough, it could be a "combination" thats needed.

what i would do if i had a DS4k:

use the RLGLLDS keyformat - and bruteforce the remaining possible bits <B>

Code: [Select]
     A       B       C       D
   54321   54321   54321   54321

   10000   000BB   BBBBB   x0000   FlexRay Decode or alternate option
   10000   000BB   BBBBB   0x000   CAN Decode or alternate option
   10000   000BB   BBBBB   00x00   I2C Decode or alternate option
   10000   000BB   BBBBB   000x0   SPI Decode or alternate option
   10000   000BB   BBBBB   0000x   RS232 Decode or alternate option
i guess you could do it with python via LXI easily within a resonable timeframe

I'm quite sure that I had already tried those combinations. However, just in case I missed something, I tried the ones you indicated above again. No change and my DS4024 just responds with a 'Licence invalid - re-enter licence' reply.

I just noticed that you posted a modified firmware, will give that a try now. Awesome work! Thanks Cybernet!

Also, I have the calibration values from my DG4162. I'll start typing them in and PM them to you.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Co6aka on November 28, 2013, 05:03:28 am
Exactly how long is a DS4000 firmware update supposed to take? My 4014 has been at it for about a half hour now.  :-// The activity LED on my USB stick is still blinking away, and the "CH 1" button is illuminated green, the "SINGLE" button is illuminated amber, and the "RUN/STOP" button is illuminated red. What now?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Uup on November 28, 2013, 05:39:07 am
Exactly how long is a DS4000 firmware update supposed to take? My 4014 has been at it for about a half hour now.  :-// The activity LED on my USB stick is still blinking away, and the "CH 1" button is illuminated green, the "SINGLE" button is illuminated amber, and the "RUN/STOP" button is illuminated red. What now?

It should only take a few minutes at most. I think it took my DS4024 about 3 minutes.

Try the following:

Update via boot-up, not via the GUI.

Make sure the name of the GEL file is "DS4000Update.GEL"

Re-format the USB stick and copy the GEL file back.

If it still isn't working then try a different USB stick.


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Co6aka on November 28, 2013, 05:45:42 am
Was updating via bootup... Apparently, although my USB stick is visible and browsable on the DS, the bootup updater is allergic to my USB stick. As per Rigol's recommendations I used a <4GB stick. Also tried reformatting it, etc. The scope just doesn't like that stick.  SO, I used a newer 16GB stick and it just now finished. For future reference, I'm guessing that the red RUN/STOP means there was an error with the bootup updater.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Co6aka on November 28, 2013, 06:31:33 am
Firmwarez flashed in, and gave the scope some funky signals from my E4438C. Looks OK,  :-+, but it's one-bloody-thirty in the AM...  :=\  Gotta climb into my coffin for a while.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: frenky on November 28, 2013, 08:50:24 am
To all of those who don't have a fast signal generator.
How about measuring some signals inside of PC, cellphone, mediaplayer...
Processor clocks go over gigahertz so there should be some really fast signals going around?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on November 28, 2013, 09:01:11 am
 |O Can I get some clarification please:

Is the upgrade valid for all models in the series?

For example; There is DS1074Z & DS1104Z, but also DS1074Z-S & DS1104Z-S.

Then we have DP832 but also the DP832A and DP831A.

The list goes on, there are 8 models in the DS400 series?

Thanks for help, I trying to make a single resource for all this info at rigol.avotronics.co.uk (http://rigol.avotronics.co.uk)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 28, 2013, 09:23:55 am
|O Can I get some clarification please:

Is the upgrade valid for all models in the series?

For example; There is DS1074Z & DS1104Z, but also DS1074Z-S & DS1104Z-S.

...

The list goes on, there are 8 models in the DS400 series?
For DS1000Z series I think it works for both DS1000Z and DS1000Z-S

The DS2000 hacks doesn't work for DS2000A.

For DS4000 series I think it works for all DS4000 and all MSO4000 models too.
cybernet wrote that his modified DS4000 series firmware works with both 2- and 4-channel models and DS4000 and MSO4000 models here:

any DS4k volunteers ?
this sets model type 0x4 = 500mhz
(whatever channel#, whatever MSO y/n it leaves that intact)
So it's really a MSO/DS4000 series hack. Rigol also lists MSO/DS4000 series under one at their site: http://int.rigol.com/prodserv/DS4000/ (http://int.rigol.com/prodserv/DS4000/)
It's the same user's manual and everything.

Then we have DP832 but also the DP832A and DP831A.
There's also DP811A and DP821A models: http://int.rigol.com/prodserv/DP832/property/ (http://int.rigol.com/prodserv/DP832/property/)
But all the DP8xxA models already have the 4 options from the keygen factory enabled. That's why they keygen is for DP832 only.
So far DP832 is the only non-A model released, but if Rigol releases other non-A models these will probably come without the extra options enabled too.

(http://int.rigol.com/upload/13-08/30/1(6).bmp)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on November 28, 2013, 11:30:38 am
|O Can I get some clarification please:

Is the upgrade valid for all models in the series?

For example; There is DS1074Z & DS1104Z, but also DS1074Z-S & DS1104Z-S.

...

The list goes on, there are 8 models in the DS400 series?
For DS1000Z series I think it works for both DS1000Z and DS1000Z-S

The DS2000 hacks doesn't work for DS2000A.

For DS4000 series I think it works for all DS4000 and all MSO4000 models too.
cybernet wrote that his modified DS4000 series firmware works with both 2- and 4-channel models and DS4000 and MSO4000 models here:

any DS4k volunteers ?
this sets model type 0x4 = 500mhz
(whatever channel#, whatever MSO y/n it leaves that intact)
So it's really a MSO/DS4000 series hack. Rigol also lists MSO/DS4000 series under one at their site: http://int.rigol.com/prodserv/DS4000/ (http://int.rigol.com/prodserv/DS4000/)
It's the same user's manual and everything.

Then we have DP832 but also the DP832A and DP831A.
There's also DP811A and DP821A models: http://int.rigol.com/prodserv/DP832/property/ (http://int.rigol.com/prodserv/DP832/property/)
But all the DP8xxA models already have the 4 options from the keygen factory enabled. That's why they keygen is for DP832 only.
So far DP832 is the only non-A model released, but if Rigol releases other non-A models these will probably come without the extra options enabled too.

(http://int.rigol.com/upload/13-08/30/1(6).bmp)

Great thanks.

Do we know about the DSA815-TG and compatability?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DL5TOR on November 28, 2013, 11:57:19 am
Do we know about the DSA815-TG and compatability?

Compatible to what?
 Sorry i am missing somthing

but for info

There are only 2 typs of  DSA815:

The DSA815 9kHz - 1.5GHz no tracking gen
and
The DSA815-TG 9kHz - 1.5 GHz wiht tracking gen
Keygen works on both only it is not Confirmd or tested what is missing (harware) on the non-TG Version. If it is only the N-connector then all you need is the connector and a licens-key

73 de DL5TOR
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on November 28, 2013, 01:48:26 pm
Do we know about the DSA815-TG and compatability?
Compatible to what?
 Sorry i am missing somthing

I think they don't read the thread. They just ask until somebody answers. The search in this forum seems also be broken.  :palm:

I don't think you have read it, otherwise you'd know why I was asking  :-DD
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DL5TOR on November 28, 2013, 02:06:59 pm

I don't think you have read it, otherwise you'd know why I was asking  :-DD

Ok I read your page of the DSA815.

Now the Infos that are related to the Hacks is as follow

the DSA815-TG is confirmd for the keygen by me as I have one with all opitons enabeld the non -TG model i can not confirm alltho this shuld be the same (see my last post).

there is no moded Firmware that i am Aware of

so I hope this info is all that you Need

73 de DL5TOR
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on November 28, 2013, 02:10:17 pm

I don't think you have read it, otherwise you'd know why I was asking  :-DD

Ok I read your page of the DSA815.

Now the Infos that are related to the Hacks is as follow

the DSA815-TG is confirmd for the keygen by me as I have one with all opitons enabeld the non -TG model i can not confirm alltho this shuld be the same (see my last post).

there is no moded Firmware that i am Aware of

so I hope this info is all that you Need

73 de DL5TOR

GREAT! Thank you. That is exactly what I wanted to know  :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on November 28, 2013, 03:19:46 pm
Quote
I think they don't read the thread. They just ask until somebody answers. The search in this forum seems also be broken.  :palm:

I don't think you have read it, otherwise you'd know why I was asking  :-DD

Yeah, ok. You make "the single resource" for the hacks, but you want a verification for the information you have on your website. I finally got it!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Co6aka on November 28, 2013, 03:57:46 pm
Yeah, ok. You make "the single resource" for the hacks, but you want a verification for the information you have on your website.

Measure thrice, cut once; to err is human... :-BROKE  (And to make it utterly FUBAR requires government intervention.)

I finally got it!

Whew!  :clap: Now we can get back to sniffing bus!  O0 (Werd.)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on November 28, 2013, 04:54:40 pm
Yeah, ok. You make "the single resource" for the hacks, but you want a verification for the information you have on your website.

Measure thrice, cut once; to err is human... :-BROKE  (And to make it utterly FUBAR requires government intervention.)

I finally got it!

Whew!  :clap: Now we can get back to sniffing bus!  O0 (Werd.)

lol  :-DD Sniff what you like!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Tasman on November 29, 2013, 10:26:45 am
Unfreezing DS2000.

The method in attached pdf has been proved to unfreeze a locked-up unresponsive scope.  Might be handy if an upgrade goes wrong.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: apelly on November 29, 2013, 10:38:25 am
Ordered a bus blaster tonight. Will be here in a week or so. Plan is to extract the 2072A firmware.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: clifford on November 29, 2013, 12:39:40 pm
if i temper with the file, i temper with the website that displays the md5/sha/<otherhash> too -> e.g. useless

that's why it is important to post the md5/sha/etc. somewhere else (such as this forum).

for example if you have an ftp site with many mirrors, then a user would download the checksum from the primary site and the actual file from the nearest mirror.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on November 29, 2013, 01:03:02 pm
means u trust information in a public non peer reviewed forum when it comes to authenticity of a file ? - i hope u dont end up in a "bad forum" one day, could be surprising .. ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on November 29, 2013, 01:05:42 pm
Ordered a bus blaster tonight. Will be here in a week or so. Plan is to extract the 2072A firmware.
If you use a BusBlaster (as JTAGkey) and TopJTAG also you'll need the datasheet for blackfin and NAND (to define the connection pin to pin blackfin-NAND). And another vital thing is the blackfin's bsdl file.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gunb on November 29, 2013, 01:30:22 pm
@cybernet: many thanks for your efforts! Really an outstanding job you've done! :-+

Do you think that 500MHz bandwidh limit is only an firmware issue or that hardware might also be different within the DS4000 series regarding the bandwidth?

Thx again.


Kind rgds
Gunb
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 29, 2013, 01:50:24 pm
Ordered a bus blaster tonight. Will be here in a week or so. Plan is to extract the 2072A firmware.
If you use a BusBlaster (as JTAGkey) and TopJTAG also you'll need the datasheet for blackfin and NAND (to define the connection pin to pin blackfin-NAND). And another vital thing is the blackfin's bsdl file.
Isn't this cyberCAD® DS2k JTAG pinout schematic enough?

https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg241335/#msg241335 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg241335/#msg241335)

https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/ (https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/)

(https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/?action=dlattach;attach=56217;image)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cosmos on November 29, 2013, 01:59:30 pm
@ Gunb  The DS4014 is already confirmed (by me, using cybernets excelent firmware mod) to have rise and fall times in the area of a DS4054 so I think it is a safe bet that it does have the same HW.

Looking at the specs of DS4000 vs DS6000 it is even tempting to think that they share HW platform, just a small 25% clock increase for frontend and a 1" larger display.

DS6k vs DS4k
5Gs/s vs 4Gs/s
600 and 1000MHz vs up to 500MHz
Same sample memory size (140M)
180k records/s vs 110k (could be partly from 25% clock increase to support 5Gs/s).
The sensitivity specs are also very similar making me think they share frontend and ADC too.
There are references in the DS4k GEL file to DS6k related text strings.
The BW limiting amplifier of the DS4k should on paper be able to reach 1GHz.

Would have been very nice with a DS6k teardown from some brave soul.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gunb on November 29, 2013, 02:07:54 pm
@ Gunb  The DS4014 is already confirmed (by me, using cybernets excelent firmware mod) to have rise and fall times in the area of a DS4054 so I think it is a safe bet that it does have the same HW.

...


OK, thank you!


Kind rgds
Gunb
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on November 29, 2013, 02:09:12 pm
Isn't this cyberCAD® DS2k JTAG pinout schematic enough?
https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/ (https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/)
No with TOPJTAG.

(https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/?action=dlattach;attach=69027;image)

Maybe someone can post how is this pin-to-pin connection, because there are alternative pin for nand in blackfin.

It, is also necessary (so read the datasheet is mandatory):

(https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/?action=dlattach;attach=69029;image)

Fortunately the DS2000's NAND is CFI compliant.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: clifford on November 29, 2013, 02:12:45 pm
means u trust information in a public non peer reviewed forum when it comes to authenticity of a file ? - i hope u dont end up in a "bad forum" one day, could be surprising .. ;)

Well... If your files are malicious in the first place then we are all screwed anyways. ;)

So I guess the question is if I have trust in the security of this forum, and the answer is of course no (the session cookies are all transferred over http, not https, to start with). But I guess this is as good as it gets..

If you'd post checksums here it would be as secure or insecure as if you'd posted the file itself here. Which is, I expect, all I can ask for.

Besides the security concerns, checksums would also provide an easy unique way of referring to a version of a file.

That all being said: If it's all the same for you I'd prefer checksums, and cryptographic signatures, and ..., otherwise I would prefer if you'd spend your time on awesome hacks rather than creating a cryptographically secure distribution chain.

Thanks for all the amazing work!  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on November 29, 2013, 02:16:18 pm
@ clifford: Strongly agree.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on November 29, 2013, 05:22:13 pm
@cybernet: many thanks for your efforts! Really an outstanding job you've done! :-+

Do you think that 500MHz bandwidh limit is only an firmware issue or that hardware might also be different within the DS4000 series regarding the bandwidth?

Thx again.
Kind rgds
Gunb

impossible to say for me because i dont even own a DS4k - but the hardware experts in that forum say its all the same.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: andyturk on November 29, 2013, 06:12:39 pm
Just applied the cybernet magic to my DS4014...

See the attached screen shots for details. Source signal was a Jim Williams pulser (#4 from free_electron).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gunb on November 29, 2013, 06:36:43 pm

impossible to say for me because i dont even own a DS4k - but the hardware experts in that forum say its all the same.

OK. Meanwhile I'm at home and flashed my scope - works fine with 1ns/DIV now. Cool man!

Thank you, mate!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: apelly on November 29, 2013, 07:34:40 pm
Isn't this cyberCAD® DS2k JTAG pinout schematic enough?
https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/ (https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/)
No with TOPJTAG.
Understood.

Didn't want to pay the freight on cybernet's recommended JTAGkey-Tiny, and people seem to have had issues dealing with them.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gallymimus on November 29, 2013, 09:20:33 pm
This is very cool.  I've been holding out on buying a ds4014 until this mod came along.

Really I probably only need a ds1000z!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mtdoc on November 29, 2013, 10:00:18 pm
Did the upgrade and working great.  :-+  But not yet displaying 2302



the "recalc" of the string is triggered by option un/install - so flush keys, and reapply them and it will become active.


OK - stupid question - what exactly do you mean by above?  Do a new kegen and use option code DSAA (or DSAS?)  to clear all options then do it again with DSAZ?  ( I tried just with DSAZ but no luck)

Just wanted to check before I do something stupid ..
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gallymimus on November 29, 2013, 10:31:00 pm
Did the upgrade and working great.  :-+  But not yet displaying 2302



the "recalc" of the string is triggered by option un/install - so flush keys, and reapply them and it will become active.


OK - stupid question - what exactly do you mean by above?  Do a new kegen and use option code DSAA (or DSAS?)  to clear all options then do it again with DSAZ?  ( I tried just with DSAZ but no luck)

Just wanted to check before I do something stupid ..

If not that, it might mean to use the SCPI uninstall function.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on November 29, 2013, 10:47:58 pm
OK - stupid question - what exactly do you mean by above?  Do a new kegen and use option code DSAA (or DSAS?)  to clear all options then do it again with DSAZ?  ( I tried just with DSAZ but no luck)

My theory is that there are both "factory model" and "current operating model" values stored in flash.  When you install/uninstall a key it seems to go back to the "factory model" and then decide what to elevate it to by looking at the key bits, in this case 100M or 200M.  I think cybernet's modded firmware overrides the "factory model" setting with a 2302.  So after flashing it you need to uninstall and reinstall any keys you had to get it to do this "current operating model" calculation process.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Co6aka on November 29, 2013, 11:26:32 pm
i hope u dont end up in a "bad forum" one day, could be surprising .. ;)

Hey wait a minute... Why is my DS4K using up all of my network bandwidth now...?   :-DD

Anyway... So far so good with your patch!  :-+

(Next time you find yourself in Nooh Yawk, there's a few tall-cold-ones waiting! 8) )
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mtdoc on November 30, 2013, 02:08:25 am
Did the upgrade and working great.  :-+  But not yet displaying 2302



the "recalc" of the string is triggered by option un/install - so flush keys, and reapply them and it will become active.


OK - stupid question - what exactly do you mean by above?  Do a new kegen and use option code DSAA (or DSAS?)  to clear all options then do it again with DSAZ?  ( I tried just with DSAZ but no luck)

Just wanted to check before I do something stupid ..

If not that, it might mean to use the SCPI uninstall function.

Yeah, I thought of that possibility. I haven't tried using SCPI commands yet.

So... the answer is???


OK- that was it!  Just used the SCPI uninstall then install commands and it worked!  Thanks.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jamesb on November 30, 2013, 02:10:11 am
Not to be too much of a buzzkill ... however, have a look at the attached images.

(http://i.imgur.com/x68kFvl.png)
10MHz signal generated from DSA815-TG (50ohm output) set to zero-span mode, N-to-BNC cable with 50ohm inline termination to DS2202 (reflashed with modified FW).
Observed waveform shows 74mVpp amplitude.
Bandwidth being -3dB or 0.707.. we find 74mVpp / sqrt(2) = 52.3mVpp (-3dB voltage)

(http://i.imgur.com/PtlgCGQ.png)
At 250MHz zero-span output, the observed amplitude is 52.4mVpp
Thus, it appears that 250MHz is the actual bandwidth of a DS2000 series scope

I do not like the pulse generator method of finding the bandwidth because it appears that there is much confusion as to how to properly measure the pulse width (not the slope of the curve) and even in doing so, 0.1ns can generate a very significant difference in derived BW. It seems this method is more prone to gross systematic errors. Kinds of like the recent speed of light debacle ;)

Would anyone care to further discuss these findings?

edit: spelled pulse as "pule"
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on November 30, 2013, 02:16:30 am
Curiously jamesb, where does it get to the -3 dB point when the 200M bandwidth limit is turned on?  How much lower?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JDubU on November 30, 2013, 02:23:25 am
jamesb:

Which hardware version is your DS2000?

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jamesb on November 30, 2013, 02:32:20 am
Curiously jamesb, where does it get to the -3 dB point when the 200M bandwidth limit is turned on?  How much lower?

180MHz reliably at BW limit = 200MHz
100MHz at BW limit = 100MHz
20MHz at BW limit = 20MHz

edit: added data points
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jamesb on November 30, 2013, 02:34:06 am
jamesb:

Which hardware version is your DS2000?

SW: 00.01.01.00.02 modified version
HW: 1.0.1.0.0
FPGA:
 SPU: 03.01.05
 WPU: 00.06.05
 CCU: 12.29.00
 MCU: 00.05
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on November 30, 2013, 02:58:34 am
@ jamesb:

I have a question: Where do you get the 250 MHz signal?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jamesb on November 30, 2013, 03:19:42 am
@ jamesb:

I have a question: Where do you get the 250 MHz signal?

Tracking generator output from a DSA815-TG set to zero-span mode
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mtdoc on November 30, 2013, 03:45:03 am
@ jamesb:

I have a question: Where do you get the 250 MHz signal?

Tracking generator output from a DSA815-TG set to zero-span mode

Have you checked its output at those frequencies on a known high bandwidth scope?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jamesb on November 30, 2013, 04:25:17 am
Have you checked its output at those frequencies on a known high bandwidth scope?

Fair question, however ..

What is more likely? A 200MHz scope which has been hacked to "allow" 350MHz BW operation ... or a spectrum analyzer with tracking generator whose range is 9kHz to 1.5GHz is not outputting its correct amplitude?

I have verified the linearity of the tracking generator using the spectrum analyzer. To ensure output linearity, I confirmed that the output power was -20dBm for all frequencies prior to checking their amplitude on the oscilloscope. In all cases, the bandwidths reported were at the same (measured) output levels.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mtdoc on November 30, 2013, 04:38:53 am
Have you checked its output at those frequencies on a known high bandwidth scope?

Fair question, however ..

What is more likely? A 200MHz scope which has been hacked to "allow" 350MHz BW operation ... or a spectrum analyzer with tracking generator whose range is 9kHz to 1.5GHz is not outputting its correct amplitude?

No argument at all.  Just covering the bases....  A perusal of the manual of the DSA815-TG shows the tracking generator specs at +/-  3dB output flatness across its range.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on November 30, 2013, 04:47:50 am
Quote
No argument at all.  Just covering the bases....  A perusal of the manual of the DSA815-TG shows the tracking generator specs at +/-  3dB output flatness across its range.

The input of the DSA815 is MUCH more accurate than the output (Tracking Generator), so forget the manual, just connect the TG directly to the input of the SA to see what the amplitude is at your desired frequency. Each DSA815-TG will have a different frequency response for its TG, and although +-3db is the worst case scenario according to the datasheet, I think most units will have much flatter responses than this
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Teneyes on November 30, 2013, 06:38:03 am
@andyturk
All the talk of Rigol hacks got me curious about what goes on inside my DS1102E's non-volatile RAM.
Just applied the Cybernet magic to my DS4014...

Well Andy, you started this back in May, and I would say an excellent, interesting and well participated Topic .  Success to All
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: seronday on November 30, 2013, 07:50:11 am
Not to be too much of a buzzkill ... however, have a look at the attached images.

10MHz signal generated from DSA815-TG (50ohm output) set to zero-span mode, N-to-BNC cable with 50ohm inline termination to DS2202 (reflashed with modified FW).
Observed waveform shows 74mVpp amplitude.
Bandwidth being -3dB or 0.707.. we find 74mVpp / sqrt(2) = 52.3mVpp (-3dB voltage)

At 250MHz zero-span output, the observed amplitude is 52.4mVpp
Thus, it appears that 250MHz is the actual bandwidth of a DS2000 series scope

I do not like the pulse generator method of finding the bandwidth because it appears that there is much confusion as to how to properly measure the pulse width (not the slope of the curve) and even in doing so, 0.1ns can generate a very significant difference in derived BW. It seems this method is more prone to gross systematic errors. Kinds of like the recent speed of light debacle ;)

Would anyone care to further discuss these findings?


The issue that you have run into here is the loading effect due mainly to the input capacitance of the DSO channel.
As an example, the DS2000 series is specified as having approx 16pf input capacitance.
At say 300Mhz, this is approx 33ohms reactance across the 50ohm external termination.

High end oscilloscopes have a correct 50ohm impedance termination built in.

It is possibble to get around this issue by using a suitable high frequency probe. eg. an active probe.

From the point of view of measuring the DSO channel bandwidth, it is possible to do this with a spectrum analyzer and tracking generator.

The idea is to monitor the signal level directly at the input to the DSO and adjust the Generator output to maintain a constant signal level at the DSO input.
Any drop in signal level seen on the DSO screen is then due to frequency response of the internal circuitry after the input connector.
So this is measuring the DSO frequency response only and ignores the effect of changes in the input loading.
 
This can be done as follows:-

Connect the Generator output to the DSO input channel using a BNC "T" piece on the front of the DSO.
The Generator output is connected to one side of the "T" and a 20dB 50ohm inline attenuator to the other side of the "T".
Then from the 20dB inline attenuator connect back to the spectrum analyzer input.
The 20dB attenuator acts as a 50ohm termination for the Generator.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: andyturk on November 30, 2013, 08:15:04 am
Well Andy, you started this back in May, and I would say an excellent, interesting and well participated Topic .  Success to All
Indeed. Many thanks to cybernet and the other rock stars in this thread!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: oe6kyg on November 30, 2013, 08:39:08 am
i have two HP8640B Signal Generators up to 512 MHz
Output ist linear on both measured with HP 70000 Analyser

connected Gen to DS2072(updatet) through a 50 Ohm Termination (which is also linear up to 1 GHZ)
my 3 dB Frequency was 344 Mhz
up from 344 Bandwith goes down dramaticaly and over 380 Mhz Scope does show frozen Signal and Frequency

see att. PIC
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jamesb on November 30, 2013, 02:19:07 pm

My precise procedure was as follows:


My latest iteration comes up with 300MHz as the BW when I corrected for the TG output "flatness" (increased output from -20dBm to -19dBm to achieve same value at SA input). It seems that my own methodology is no better than the pulse width method for systematic error - or I am just so systematically error prone that I am the root cause :)

I lack the two 20dB attenuator pads - however, the SA does have a built-in attenuator and I've got a good 10dB attenuator - I will try seronday's suggestion using 10dB (which I understand will not be the 10x factor I am looking for [20log(v1 / v2)] just to see what I get for values.

It appears that I may have been a bit premature with my nay-saying.
[/s]

This procedure is flawed due to "calibrating" the TG output with the 50ohm termination in place. The results will read artificially high as a result.
I will redo the entire experiment and report back, this time without making the RF newbie error.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on November 30, 2013, 02:57:33 pm
So for people who've installed the custom ds4000 firmware, does your system info show a different model after unloading/reloading a key?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 30, 2013, 04:29:07 pm
connected Gen to DS2072(updatet) through a 50 Ohm Termination (which is also linear up to 1 GHZ)
my 3 dB Frequency was 344 Mhz
up from 344 Bandwith goes down dramaticaly and over 380 Mhz Scope does show frozen Signal and Frequency
What hardware version is your scope?
It would be nice if everyone doing BW tests wrote both hardware and firmware version, to see if there's any differences between for example HW ver. 1.xx and 2.xx.
And for example if they use a modded 350 MHZ or 500 MHz firmware.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: oe6kyg on November 30, 2013, 06:02:33 pm
system info shows  DS2202
Software 00.01.01
Hardware 2.00

did Update to 200mhz
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 30, 2013, 06:06:06 pm
system info shows  DS2202
Software 00.01.01
Hardware 2.00

did Update to 200mhz
So you didn't use any of cybernet's custom firmwares but only did a keygen upgrade to 200 MHz and you measured BW was still 344 Mhz?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cosmos on November 30, 2013, 06:09:51 pm
So for people who've installed the custom ds4000 firmware, does your system info show a different model after unloading/reloading a key?

I did not have to do anything to the installed (riglol generated) keys and they all stayed.
The model number was still DS4014.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on November 30, 2013, 07:25:43 pm
I did not have to do anything to the installed (riglol generated) keys and they all stayed.
The model number was still DS4014.

This may have already been asked - do you see the bandwidth options under each channel now?  (20M, 100M, 200M).

If you unload/reload your key you might possibly get the DS4054 label.  (no guarantees, it might be taking a risk to try).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gallymimus on November 30, 2013, 07:32:26 pm

This may have already been asked - do you see the bandwidth options under each channel now?  (20M, 100M, 200M).

If you unload/reload your key you might possibly get the DS4054 label.  (no guarantees, it might be taking a risk to try).

Yes, asked and answered a few pages ago.

yes BW options are now: OFF, 20M, 100M, 200M

selecting 100M I get about the same rise and fall as I had before (~2ns).
selecting 200M I get around 1.5ns
selecting OFF I get mostly 1.28ns rise and 1.16ns fall (for the others it also like that with slightly lower number for fall time)
If I measure with cursors I get the same results (knowing that the IO is driven from 2.5V rails I can set the 10% and 90% referred to that)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Co6aka on November 30, 2013, 07:35:44 pm
If you unload/reload your key you might possibly get the DS4054 label.

I already did. It (still) doesn't. Not likely possible it seems.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Co6aka on November 30, 2013, 07:55:01 pm
The input of the DSA815 is MUCH more accurate than the output...

FWIW...

I have one of these: http://www.home.agilent.com/en/pd-1000004297%3Aepsg%3Apro-pn-E4438C/esg-vector-signal-generator (http://www.home.agilent.com/en/pd-1000004297%3Aepsg%3Apro-pn-E4438C/esg-vector-signal-generator)
And one of these: http://www.aeroflex.com/ats/products/product/Communications_Test/Radio_Test_Sets_-_PMR_Test/2948B_Comm_Monitor~4.html (http://www.aeroflex.com/ats/products/product/Communications_Test/Radio_Test_Sets_-_PMR_Test/2948B_Comm_Monitor~4.html)
And one of these: http://www.minicircuits.com/pdfs/PWR-4GHS.pdf (http://www.minicircuits.com/pdfs/PWR-4GHS.pdf)

But I'm currently in heavy-construction mode :( otherwise I'd already have posted the verdict. I should be able to run and document some definitive tests by the end of the week. Unless someone beats me to the :box: punch.

Forgot to add: I also have a DSA1030A-TG3, which while an OK piece of kit, wasn't all that accurate out-of-the-box. (At least according to my other big guns, which are all calibrated.)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Co6aka on December 01, 2013, 03:03:26 am
Alright... Curiosity got the better of me, and since most fortunately I don't have to deal with the incessant nagging of a female, I set up some gear on the kitchen table:

Sig-gen: E4438C
RF power meter: PWR-4GHS
Cable: Some kind of funky 6GHz-rated flexible stuff with Huber-Suhner silver/gold connectors.
Unfortunately I don't have a BNC-female to N-female adaptor, so I had to improvise. (Apparent adapter loss, about 0.1dBm at 50 to about 0.2dBm at 1G, is "calibrated out" of my figures.) Everything "warmed up" for about 90 minutes; ambient temp was pretty stable at 22.5 degrees C.

Using a pure unmodulated sine wave carrier, I "calibrated" the E4438C and cable at 50, 100, 200, 300, 400, 500, 600, 700, 800, 900, and 1000MHz, for almost exactly 0dBm. (The smallest steps the E4438C can do is 0.02dBm, so...) Accuracy stats for the power meter are on MiniCircuits site. (FWIW, according to the power meter, the E4438C is "off" +0.08dBm at 50MHz, which gradually changes to +0.22dBm at 1000MHz.)

Set up the DS4014 for 50-Ohm inputs and no BW limit. Here are the measured RMS voltages...

50MHz: 223mV
100MHz: 221mV
200MHz: 219mV
300MHz: 214mV
400MHz: 212mV
500MHz: 207mV
600MHz: 179mV
700MHz: 149mV
800MHz: 121mV
900MHz: 91mV
1000MHz: 58mV

So now yous guyz could do da math, I'm...  :=\  (Fuhgeddaboudit!)

(-3dB point about 650MHz)

PS- All four channels were within a mV of each other.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gallymimus on December 01, 2013, 03:30:04 am
-3db at about 157mV or ~650MHz.  Seems kinda high.

Plot of Co6aka's data for reference attached.  Thanks for taking those measurements man! 

:-+         

edit: fixed incorrect frequency axis label  |O
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigol-Friend on December 01, 2013, 04:58:32 am
Gallymimus:

There is a small mistake in your plot: Frequency...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gallymimus on December 01, 2013, 05:29:10 am
Gallymimus:

There is a small mistake in your plot: Frequency...

Crud, I'll fix that, thanks

edit: Fixed
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Abdu on December 01, 2013, 08:07:05 am
DS4014 frequency response based on Co6aka measurements.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: oe6kyg on December 01, 2013, 08:33:38 am
So you didn't use any of cybernet's custom firmwares but only did a keygen upgrade to 200 MHz and you measured BW was still 344 Mhz?

that is what i measured
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Power Designer on December 01, 2013, 08:43:00 am
Hello,

I got a brand new unmodified DS2202_A_. So I would like to help to enhance the situation...  :-DD

I don't have mature experience in hacking this sort of stuff. How can I help you guys? Are there any pointers how to create a memory dump from this beast? Where to send the dump?  :-//

Please don't hesitate do contact me with your requests...  :-+

I too now have a DS2202_A Rigol Oscilloscope. I purchased this online, was meant to be a DS2202, but I was upgraded to this unit as delivery was taking too long. I suspect this one simply supersedes the DS2202, as it is exactly the same, but includes a 50 Ohm impedance option, and CAN bus decoding! This really tips the scale for me on an already very fine piece of test gear. Being a hobbyist, I could not afford the typically more expensive 'scopes that we use at work (Tektronix) and I am very pleased with this purchase. A very well made scope, along with all the bells and whistles. But enough about that, I have tried to some of the solutions here (IE install NI runtime and DS tools etc) to try and get the options installed but they don't work (doesn't surprise me, the guys here appear to have done such a good job at getting past such measures, some changes by Rigol were inevitable).

Being such a new scope, nobody has probably had the time/opportunity to take a look under the firmware hood of this scope. Has anybody had any success with the option keys on this scope yet? I might have missed something on the forum. If not, can I help in some way? I know you were asking for a .GEL file for the firmware, but I was unsuccessful in locating firmware upgrades on Rigol's scopes. Perhaps I have to work through the dealer. Anyway, assistance is appreciated, I would love to have all the features (especially trigger features) enabled, as they can be extremely useful at times, but my budget is already blown and there is no way I can go parting with hundreds of dollars for these options.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 01, 2013, 09:44:57 am
Being such a new scope, nobody has probably had the time/opportunity to take a look under the firmware hood of this scope. Has anybody had any success with the option keys on this scope yet?
No, as mentioned earlier the private key seems to have been changed for DS2000A, so none of the DS2000 keys works for DS2000A.

If not, can I help in some way?
As mentioned earlier, do a JTAG memory dump.

I know you were asking for a .GEL file for the firmware, but I was unsuccessful in locating firmware upgrades on Rigol's scopes. Perhaps I have to work through the dealer.
As mentioned earlier, there doesn't seem to be any firmware updates available for DS2000A yet, but of course it doesn't hurt to ask again, maybe a new one has come out now.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: StepDIR on December 01, 2013, 05:31:58 pm
Can someone give me step by step instructions for upgrading the firmware on a DS2072?

I am expecting the CH1 light on while upgrading and then all lights on when complete.  My DS2072 goes immediately to all lights on with no upgrade.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 01, 2013, 05:48:25 pm
Can someone give me step by step instructions for upgrading the firmware on a DS2072?

I am expecting the CH1 light on while upgrading and then all lights on when complete.  My DS2072 goes immediately to all lights on with no upgrade.
Bottom of this post. (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: StepDIR on December 01, 2013, 05:54:27 pm
Thanks Marmad but that is what I have been doing and it doesn't load.  I'll keep researching maybe someone else is having this problem.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 01, 2013, 06:00:08 pm
Thanks Marmad but that is what I have been doing and it doesn't load.  I'll keep researching maybe someone else is having this problem.

Reformat the USB stick you're using and/or try a different USB stick.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gallymimus on December 01, 2013, 06:00:43 pm
Thanks Marmad but that is what I have been doing and it doesn't load.  I'll keep researching maybe someone else is having this problem.

Did you try a different flash drive?  Some people have had issues with large drives or certain brands.  You might just try a few different blank drives.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: SeanB on December 01, 2013, 06:06:18 pm
Definitely use a drive under 4G, preferably an older one of under 1G. I keep some older ones around because older firmware will not support large drives reliably or at all.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: staze on December 01, 2013, 06:08:24 pm
Some USB sticks don't work sometimes. I would try another.

Also, as for the checksum question, it would be good to have only to confirm the download and thumbdrive copy are intact. It at least cuts out a sanity question.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: StepDIR on December 01, 2013, 06:29:37 pm
I've tried two different USB sticks.  One is under 1G.
Tried FAT16 and FAT32.

Is the name of the GEL file important or just the fact that it is a GEL file enough?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: andyturk on December 01, 2013, 06:36:25 pm
Is the name of the GEL file important or just the fact that it is a GEL file enough?

The name *is* important. For my scope, it wouldn't recognize the file unless it was named DS4000Update.GEL
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mtdoc on December 01, 2013, 06:38:52 pm
I've tried two different USB sticks.  One is under 1G.
Tried FAT16 and FAT32.

Is the name of the GEL file important or just the fact that it is a GEL file enough?

If you are using cybernet's firmware you must rename the file to DS2000Update.GEL
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: StepDIR on December 01, 2013, 06:48:18 pm
Thanks everyone.

 Yes I am using cybernet's firmware and I had to name my file DS2000Update.GEL since I have a DS2000 series.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Teneyes on December 01, 2013, 07:18:48 pm
Thanks everyone.
 Yes I am using cybernet's firmware and I had to name my file DS2000Update.GEL since I have a DS2000 series.
Just for reference,
I have one USB stick and on loading firmware to a Rigol,
I see the stick LED flash when it is inserted, but no 'Chan 1' flashing !
However,
when I remove and re-insert it a second time, then the 'Chan 1' begins to flash :)
and the new firmware is loaded. :-+

File must be named DS2000update.GEL  , NOT  DS2000update00_01_01_00_01.GEL or whatever
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: stormbr on December 01, 2013, 07:31:48 pm
Solved to me, i haven't renamed to DS2000Update.GEL and dont needed uninstall/reinstall the Keys.

BW Limit - 20M - 100M - 200M
Model Name: 2202 (not change to 2303).
Serial: not change to DS2A00001.
Time base: 1ns

Note:

I used a sandisc 4gb pendrive, black/red and all made in plastic, the same that Dave use in your review.

Thanks to all community.

Cheers.



Title: Re: Sniffing the Rigol's internal I2C bus
Post by: staze on December 01, 2013, 07:35:45 pm
So did your keys from before the hacked firmware stick? Still have decode options, etc?

I guess now all that's left is CAN decode. :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: stormbr on December 01, 2013, 07:40:50 pm
So did your keys from before the hacked firmware stick? Still have decode options, etc?

I guess now all that's left is CAN decode. :)

No problem with keys, all options are official version and not opened "can decode" function.

Just update to cybernet firmware and enjoy.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: flolic on December 01, 2013, 07:59:07 pm
(https://dl.dropboxusercontent.com/u/21387397/slike/eevblog/ds2072_350MHz_fw.png)

JW pulse generator, DS2072 scope with 50ohm pass through terminator. Cybernet's 350MHz modified firmware. Scope HW 1.0
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: maelli on December 01, 2013, 08:35:15 pm
@frolic

some more playing around with 300 and 200Mhz setting.
Williams generator with piece of coax and a trimcap.
Aim was to generate a flat and slightly longer (if 4.5 nanosecs are long)
pulse, since too short pulses show to optimistic rise times.

Still using the 1:10 probe that came with the DS2000.
Shortest possible earth connection (not even the springy thingy).
DS2072 hw version 2, with Cybernet's firmware

Yellow trace full BW, pink trace 200Mhz.
The 200Mhz setting is so much slower ;-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: flolic on December 01, 2013, 08:59:18 pm
@Maelli, yes, you are right ;)
I forgot to adjust trimmer on my pulse generator. Now reading are almost the same as yours ;)

(https://dl.dropboxusercontent.com/u/21387397/slike/Newfile1.png)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Co6aka on December 01, 2013, 09:21:10 pm
DS4014 frequency response based on Co6aka measurements...

Interesting how the knee is right at 500MHz, and the highest BW DS4K is 500MHz.

I forgot to add: I also generated some 95% modulated AM signals at 1GHz which, though attenuated, looked exactly as expected; seems the scope is still usable at 1GHz. When I get an opportunity I'll do some more upper-frequency-limit exploration, and if anyone wants me to also try some specific tests send me a PM with the details.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: andyturk on December 01, 2013, 10:11:14 pm
... I also generated some 95% modulated AM signals at 1GHz which, though attenuated, looked exactly as expected; seems the scope is still usable at 1GHz.
That's the same conclusion that Connor Wolf came to a while back. The info is buried in the thread somewhere, but the input amplifiers are configurable for bandwidth and are spec'd to handle 900MHz, if I remember correctly. It could be that cybernet's DS4K mod simply tricks the scope into thinking it's a 500MHz model, without touching the actual configuration of the input amps. I.e., the DS4054 may still be limiting the bandwidth under software control.

The way to find out would probably be to put a logic analyzer on the SPI lines for those input amps and see what's being sent to them. ve7xen  tried that (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg239833/#msg239833) on his DS2K, and found that the input amps were still limited even when the scope's UI said otherwise.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on December 01, 2013, 10:22:15 pm
im pretty sure the change int he model type id (thats what the firmware file hack does) affects the SPI based filter chip, indirectly.
but: atm i believe the FPGA or a micro core in the FPGA is actually running the SPI bus, the bfin is a slave - so the actual value that gets set in the SPI based filter chip is unknown to me (but it does upgrade, that im pretty certain)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 01, 2013, 10:37:50 pm
Another question: What chip sets the DS4000's BW?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: thetooth on December 03, 2013, 11:55:31 am
At the risk of sounding retarded, is the DS2000A hackable at this point?, i've skimmed backwards through to page 60 where people were talking about it but there wasn't any solution.

My DS2072A arrived today and i've been burning through the trail like anything(2000 minutes is NOTHING), since i really need the 56mp/s option but am flat broke after buying the scope. Of course tried the keygen to no avail using manual input and serial.

I'm willing to do FW dump if its needed, also i have a copy of the latest GEL file.

And somewhat off topic, dose the DS2000 normally crash frequently? i've had it on for probably 4hrs total, and its crashed 5 times so far, 3 when using the decode functions and the others just randomly.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on December 03, 2013, 12:01:52 pm
At the risk of sounding retarded, is the DS2000A hackable at this point?, i've skimmed backwards through to page 60 where people were talking about it but there wasn't any solution.

My DS2072A arrived today and i've been burning through the trail like anything(2000 minutes is NOTHING), since i really need the 56mp/s option but am flat broke after buying the scope. Of course tried the keygen to no avail using manual input and serial.

I'm willing to do FW dump if its needed, also i have a copy of the latest GEL file.

And somewhat off topic, dose the DS2000 normally crash frequently? i've had it on for probably 4hrs total, and its crashed 5 times so far, 3 when using the decode functions and the others just randomly.

DS2000A Hackable yet? No.
But I don't think anyone has supplied jtag dump yet for the A series.
I really want to order a DS2000 while there are still some non-A versions left, unfortunately I'm skint this month.
I'm not convinced that the A version will ever be hackable because I think Rigol have done something to stop (make harder) the hackability of the newer models.  Of course, I could be wrong  :-\

I would suggest you contact the supplier with your crashing problem. But you should check the firmware version in case there is an update.

Someone will be a long shortly who knows more.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 03, 2013, 12:04:54 pm
At the risk of sounding retarded, is the DS2000A hackable at this point?
No, not yet.

I'm willing to do FW dump if its needed, also i have a copy of the latest GEL file.
Uploading a FW dump and GEL file would probably help a lot with hacking it, nobody has uploaded this for DS2000A yet, so nobody without a DS2000A would be able to help with hacking it.
The files are too big to attach at this forum, so you would need to use a 3rd party file hosting site like www.filedropper.com (http://www.filedropper.com) where cybernet has uploaded his custom firmwares, or mail them to the poster above (Avotronics) who hosts files for Rigol hacking on his website here: rigol.avotronics.co.uk (http://rigol.avotronics.co.uk)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Teneyes on December 03, 2013, 12:14:08 pm
dose the DS2000 normally crash frequently? i've had it on for probably 4hrs total, and its crashed 5 times so far, 3 when using the decode functions and the others just randomly.
  NO , I cannot remember if it ever froze, bugs Yes, function failures ( buttons) Yes
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 03, 2013, 12:17:44 pm
And somewhat off topic, dose the DS2000 normally crash frequently? i've had it on for probably 4hrs total, and its crashed 5 times so far, 3 when using the decode functions and the others just randomly.
What's the firmware and hardware versions for your DS2000A?
You said you have the latest GEL file, what version is this and has it been installed yet?
I think you are the first member on here to mention having received a new GEL file for DS2000A.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: apelly on December 03, 2013, 12:47:37 pm
I'm willing to do FW dump if its needed
Do it! My JTAG stuff is still in the mail. Will be more than a week before I get set up and can dump everything.

also i have a copy of the latest GEL file.
Post it already. What's the hold up?  ;D

Also... I've never experienced a crash with mine. Maybe RMA before you open it?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: thetooth on December 03, 2013, 01:26:37 pm
Heres the firmware i got from rigol: http://thetooth.name/dev/DS2000(DSP)update.rar (http://thetooth.name/dev/DS2000(DSP)update.rar) i have not installed it yet because they said it was the same version and i've read before that updating causes you to loose trial, however i don't think its anything new, internal date is 24/06/2013 so i as a wild guess, they're using the same firmware but have changed something else to break the keygen(or the keygen's algo is just incorrect for the newer models :P).

Heres the version info, i'm not sure how to get any extended info like i've seen in other posts, but maybe they were just ds4000's
(http://thetooth.name/images/IMG_9643s.jpg)
(http://thetooth.name/images/IMG_9644s.jpg)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 03, 2013, 01:38:03 pm
Heres the version info, i'm not sure how to get any extended info like i've seen in other posts
Bottom of this post. (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 03, 2013, 01:42:02 pm
thetooth that is the same as the latest non A firmware, so either Rigol gave you the wrong firmware or they are going to use the same firmware for both the A and non A scopes.  Probably they gave you the wrong one though as your scope shows something newer - I wouldn't load it!

Also, it isn't a rar but a zip you've attached.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 03, 2013, 01:48:44 pm
Also, it isn't a rar but a zip you've attached.
I'm surprised WinRAR doesn't complain, regardless if this file ends on .rar or .zip.
It just opens it as if it had the correct extension name, whether you name it .rar or .zip.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: thetooth on December 03, 2013, 02:30:34 pm
thetooth that is the same as the latest non A firmware, so either Rigol gave you the wrong firmware or they are going to use the same firmware for both the A and non A scopes.  Probably they gave you the wrong one though as your scope shows something newer - I wouldn't load it!

Also, it isn't a rar but a zip you've attached.
yeah i gathered, also funnily enough the rigol rep sent me the image as a jpg file with instructions to rename it since he seemed to think it would be eaten.

I sent an email back to ask if they were sure this was for the A version so might see something new after all.

(http://thetooth.name/images/IMG_9646-Edit.jpg)
That sure did take a few attempts, i think the threshold is about 500ms lel
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on December 03, 2013, 04:50:42 pm
Is there an webserver inside this scope? lot of htmlcode inside the gel file?

"RIGOL Web-Enable DS2000 Series"
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JDubU on December 03, 2013, 05:19:07 pm
Is there an webserver inside this scope? lot of htmlcode inside the gel file?

"RIGOL Web-Enable DS2000 Series"

Yes. 
After setting up the LAN IP addressing on the scope, you can access it's internal webserver from the network via a web browser.
It doesn't do very much though.  Just shows things like model number, network addresses, VISA string, firmware revision, etc.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on December 03, 2013, 05:26:28 pm
Also, it isn't a rar but a zip you've attached.
I'm surprised WinRAR doesn't complain, regardless if this file ends on .rar or .zip.
It just opens it as if it had the correct extension name, whether you name it .rar or .zip.

This is what happens when you write your software to avoid clues on how to do things that may be provided by the operating system.  You read the header of the actual file and determine what to do, rather than being told.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jboard146 on December 03, 2013, 05:55:15 pm
Is there an webserver inside this scope? lot of htmlcode inside the gel file?

"RIGOL Web-Enable DS2000 Series"

Yes. 
After setting up the LAN IP addressing on the scope, you can access it's internal webserver from the network via a web browser.
It doesn't do very much though.  Just shows things like model number, network addresses, VISA string, firmware revision, etc.

Does anyone know what the login is? If you click on the Network settings it asks for a login and password.
It would be nice if you could do stuff via the web interface.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 03, 2013, 06:06:00 pm
Is there an webserver inside this scope? lot of htmlcode inside the gel file?

"RIGOL Web-Enable DS2000 Series"
You mean the LXI webpage? It's explained in the DS2000 User's Guide: http://www.rigol.com/download/Oversea/DS/User_guide/DS2000_UserGuide_EN.pdf (http://www.rigol.com/download/Oversea/DS/User_guide/DS2000_UserGuide_EN.pdf)
Quote
Load LXI webpage

As this oscilloscope conforms to LXI-C standards, you can load LXI webpage through Ultra Sigma (right-click the resource name and select LXI-Web; or directly input the IP address in the browser). Various important information about the oscilloscope (including the model number, manufacturer, serial number, description, MAC address and IP address) will be displayed on the webpage as shown in the figure below.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Teneyes on December 03, 2013, 06:23:52 pm
It would be nice if you could do stuff via the web interface.

  I use the USB connection , as Marmad tests show USB is Faster than LAN.
great for RUU, and Ultra sigma. 
1. Power on
2. Load Ultra Sigma
3. Right Click on Device, for SCPI
4. Paste command

see below for RUU display of a sweep in 3-D

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on December 03, 2013, 06:30:03 pm
cool :), that program looks interresting..

Lets hope the A series can be hacked, so it's easier to make a choice.. think I'm going for an ds2072a-s, but if it's not hackable I wonder if I should go for 100 or 200 (not that think I need it, but if I find that I need it and then need to buy another scope is not tempting, it doesnt seem like used scopes are selling here in this country.. atleast I cannot find anyone)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 03, 2013, 06:35:39 pm
...but if it's not hackable I wonder if I should go for 100 or 200

No difference (except front panel sticker and price tag) between DS2072 and DS2102. Both have >100MHz BW.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on December 03, 2013, 06:46:54 pm
But nobody can confirm that for the A series yet?

but what about hw differences in 2102 and 2202? (and now the DS2302a?)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 03, 2013, 07:04:05 pm
But nobody can confirm that for the A series yet?

but what about hw differences in 2102 and 2202? (and now the DS2302a?)

No hardware differences - only software differences (which set BW parameters).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JDubU on December 03, 2013, 07:23:57 pm
But nobody can confirm that for the A series yet?

but what about hw differences in 2102 and 2202? (and now the DS2302a?)

No hardware differences - only software differences (which set BW parameters).

Here is something curious. 
Look at the full hardware versions listed for each of these DS2072A's:

Hardware Version: 1.0.2.0.0
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg316379/#msg316379 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg316379/#msg316379)

Hardware Version: 1.0.2.0.2
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg341494/#msg341494 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg341494/#msg341494)

Firmware and FPGA versions are the same for both though.


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 03, 2013, 07:35:53 pm
Here is something curious. 
Look at the full hardware versions listed for each of these DS2072A's:

Yes, the hardware changes from time to time - but across the entire DS2000 line. Rigol is only manufacturing a single DS2K mainboard (or two - if they still continue to manufacture the non-A version) - then setting the model type via flash memory and front panel sticker.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on December 03, 2013, 08:12:13 pm
But both of these are the A version?, changed hw already?
Or is the hw version changing if the fpga code is changed?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 03, 2013, 10:30:32 pm
Rigol is only manufacturing a single DS2K mainboard (or two - if they still continue to manufacture the non-A version)
I think Rigol has already stopped manufacturing the non-A versions.
Some weeks ago they already removed it from their Oscilloscope models overview here: http://www.rigol.com/prodserv/Digital%20Oscilloscopes/ (http://www.rigol.com/prodserv/Digital%20Oscilloscopes/)
And also revomed from drop-down menu at their frontpage under Products -> Oscilloscopes: http://www.rigol.com (http://www.rigol.com)

Logistically it wouldn't make sense to manufacture and stock both models anyway, the only thing changed for the A model is 50 ohm input termination and a 300 MHz model. (But the non-A version can be hacked to 300 MHz too  :-+ ).
FW vise, they have also added a CAN decoding add-on option, but this can be purchased to the non-A model too according to this http://www.tequipment.net/RigolPricelist.html (http://www.tequipment.net/RigolPricelist.html) so this isn't anything A-model specific.
Quote
CAN-DS2000A   CAN trigger and decode for DS2000 and DS2000A

Even though Rigol.com don't link to the non-A model page anymore, you can still find it by going to the DS2000A site and removing the A at the end of the link, like this: http://www.rigol.com/prodserv/DS2000/ (http://www.rigol.com/prodserv/DS2000/)

Rigol have also removed DS2000 non-A from both of these 2014 PDF brochures released a month ago: http://www.rigol.com/support/prodcatalog/more.html (http://www.rigol.com/support/prodcatalog/more.html)
Code: [Select]
Title                                                       Release Date
Electronic Measurement Instruments Catalog(2014)            2013-11-06
Electronic Measurement Instruments Selection Guide(2014)    2013-11-05

The good old DS1000E/D series scopes are still in the new 2014 brochures.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: thetooth on December 04, 2013, 03:24:18 am
alright, got a reply from rigol regarding the firmware:
Quote
...
Sorry it's not for DS2000A but for old model DS2000 ,we will release new
version for DS2000A this month can you wait for it ?

When I get it will send you soon .
...

@apelly Since you're prepared to do a dump i'll let you do it once you get your kit, i'm going to talk to supplier to see if they can confirm any crashing on A version that way i can rule out or replace a dud scope before opening it.

I'm also having issue with LXI, but i think thats just to do with using windows 8, USB works fine by all accounts.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: apelly on December 04, 2013, 09:41:14 am
Quote
...
we will release new version for DS2000A this month can you wait for it ?
Interesting...
@apelly Since you're prepared to do a dump i'll let you do it once you get your kit, i'm going to talk to supplier to see if they can confirm any crashing on A version that way i can rule out or replace a dud scope before opening it.
Boring, but sensible call. That's what I'd do.
I'm also having issue with LXI, but i think thats just to do with using windows 8, USB works fine by all accounts.
Never used Win8. Probably never will. Works fine in Win7 for me. Haven't tried linux.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on December 04, 2013, 03:07:52 pm
I'm looking into determining what is involved in calibrating the DG4000 to produce a constant (flat) sine wave output level up to 200 MHz.  Although my DG4000 is essentially flat up to about 120 MHz (-1 dB), I would like it ti be flat up through 200 MHz +/- 1 dB or better. And I'm sure others with the DG4000 would also, because currently there is a 4 to 6 dB drop off.

I have provided a listing of all of the Calibration Steps for the DG4000 in the attachment 'DG4000 Calibration Menu Items.doc' (preliminary version).  Hopefully the task can be accomplished primarily by making adjustments to the upper steps in Item 3, High Freq Flat/HFLATth.

For those of you who investigated the DG4000 internal I2C bus: Please, do you have any ides or information related to ANY of the items in my list of Calibration Steps that you may have found during your DG4000 firmware investigation?   It could be very helpful for developing a suitable complete (for all areas) Calibration Procedure for the DG4000.  Thank you for any assistance.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Teneyes on December 04, 2013, 05:50:41 pm
I'm looking into determining what is involved in calibrating the DG4000 to produce a constant (flat) sine wave output level up to 200 MHz.  ,,,,,,,,,,
Thank you for any assistance.

This sound good, As one goes though the steps , can you see the existing values.
Is it good to see the values that an Owner with a DG4162 ca help as a base line values?

Will the procedure  require accurate Test Equipment to varify the setting?
Maybe someone with quality equipment lab can do the base line up to 200Mhz

Does the High range frequency from an ARB function use the same parameters?
Some owner have generated high frequencies with ARB

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on December 04, 2013, 06:27:45 pm
I'm looking into determining what is involved in calibrating the DG4000 to produce a constant (flat) sine wave output level up to 200 MHz.  ,,,,,,,,,,
Thank you for any assistance.
This sound good, As one goes though the steps , can you see the existing values.
Is it good to see the values that an Owner with a DG4162 ca help as a base line values?

Will the procedure  require accurate Test Equipment to varify the setting?
Maybe someone with quality equipment lab can do the base line up to 200Mhz

Does the High range frequency from an ARB function use the same parameters?
Some owner have generated high frequencies with ARB
Yes you can pull up the existing values, and it could help to get data from an original factory supplied DG4162.
My hope is that - i.e. a DSA2202/2302 and/or DSA815 will be Ok to do a decent job, at least a big improvement for the above 60 MHz sine wave frequencies anyway.  Don't know yet about the extended frequency ARB functions yet, but my guess is it will be good enough as is.  As you can see from the list it could end up being a daunting job, although I'm hopeful that it will be manageable, but it will be tedious, and easy to make a 'start over' mistake (with each start over being easier, but very time consuming).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bandgap on December 04, 2013, 07:17:27 pm
I'm looking into determining what is involved in calibrating the DG4000 to produce a constant (flat) sine wave output level up to 200 MHz.  Although my DG4000 is essentially flat up to about 120 MHz (-1 dB), I would like it ti be flat up through 200 MHz +/- 1 dB or better. And I'm sure others with the DG4000 would also, because currently there is a 4 to 6 dB drop off.

What do you want to know? I hacked my DG4102 to a DG4202 and recalibrated reasonably well after that so that it is reasonably flat up to 200 MHz. I only did cal items 1, 2, and 3 for each channel. I didn't bother with the rest. I used a DM3068 to read all voltages except for when frequencies increased beyond 1 MHz (where my DM3068 started to have noticeable falloff). Above 1 MHz, I used my hacked DS2202 ("DS2302") to get a rough voltage value. (You'll want to have your scope connected the whole time you're doing this so that you can be sure of what frequency it is using for each step.) For the high freq flat (item 3), you'll want to use a 50 Ohm through terminator, and calculate dBm for a 50 Ohm termination. (The DM3068 can be setup to show this directly.) I'll check later and see if I still have my before/after spreadsheet. I improved flatness a LOT, though. (Within +/- 1 dB all the way to 200 MHz if I remember correctly.)

I can post more later if needed, but I am late now for an appointment!

-Clayton
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on December 04, 2013, 08:26:34 pm
I'm looking into determining what is involved in calibrating the DG4000 to produce a constant (flat) sine wave output level up to 200 MHz.  Although my DG4000 is essentially flat up to about 120 MHz (-1 dB), I would like it ti be flat up through 200 MHz +/- 1 dB or better. And I'm sure others with the DG4000 would also, because currently there is a 4 to 6 dB drop off.

What do you want to know? I hacked my DG4102 to a DG4202 and recalibrated reasonably well after that so that it is reasonably flat up to 200 MHz. I only did cal items 1, 2, and 3 for each channel. I didn't bother with the rest. I used a DM3068 to read all voltages except for when frequencies increased beyond 1 MHz (where my DM3068 started to have noticeable falloff). Above 1 MHz, I used my hacked DS2202 ("DS2302") to get a rough voltage value. (You'll want to have your scope connected the whole time you're doing this so that you can be sure of what frequency it is using for each step.) For the high freq flat (item 3), you'll want to use a 50 Ohm through terminator, and calculate dBm for a 50 Ohm termination. (The DM3068 can be setup to show this directly.) I'll check later and see if I still have my before/after spreadsheet. I improved flatness a LOT, though. (Within +/- 1 dB all the way to 200 MHz if I remember correctly.)

I can post more later if needed, but I am late now for an appointment!

-Clayton
Well that is great news, congratulations.  I will be going ahead also of course, but I have to wait a few days due to a family medical issue.  In the meantime it would be nice to see your before/after spreadsheet data.  It is encouraging to hear that you were able to successfully complete the process.  Thank you for describing your method and offering to share your data with us.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: nazar404 on December 05, 2013, 01:09:31 am
Hello .. Can anybody help me  with the keygen program as I own the Rigol Ds2072 don't understand the keygen  program..  and don't want to screw up. 

which is the working Keygen Program and does it work with Firmware 01.01.02?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on December 05, 2013, 01:52:46 am
Hello .. Can anybody help me  with the keygen program as I own the Rigol Ds2072 don't understand the keygen  program..  and don't want to screw up. 

which is the working Keygen Program and does it work with Firmware 01.01.02?
Read my attachment to see if this covers your questions. These are Step-By-Step Instructions that I put together. If questions please feel free to ask me.

BTW: The DS2302 is for ~ 300 MHz.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: nazar404 on December 05, 2013, 02:29:00 am
Thank you... for the quick reply...  I will let you know if I can get it to work
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: nazar404 on December 05, 2013, 03:08:37 am
Mr Ted572, Thank you for your great great fix ...  And Thanks to all the people who worked on this project.
I am sure it took many hard hours of work!!! :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on December 05, 2013, 03:50:04 am
Mr Ted572, Thank you for your great great fix ...  And Thanks to all the people who worked on this project.
I am sure it took many hard hours of work!!! :-+
Good job, and congratulations.  All that I did was put together the information I found here.  That is all.  We are all grateful to the people that did all the hard work developing the these upgrades.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bandgap on December 05, 2013, 04:29:30 am
Well that is great news, congratulations.  I will be going ahead also of course, but I have to wait a few days due to a family medical issue.  In the meantime it would be nice to see your before/after spreadsheet data.  It is encouraging to hear that you were able to successfully complete the process.  Thank you for describing your method and offering to share your data with us.

Ted,

As promised, here's a plot of my pre-cal / post-cal (for Channel 1, Channel 2 is similar) after I hacked my DG4102 to a DG4202. As you can see, it looks DANG good after the cal.

Here's a little more description of the steps I did (I didn't do things in the cleanest way, but it gave good results, so...)

1) Set cal item to AC amplitude (all measurements here are at 1kHz if I recall correctly.)
2) Go through and record each voltage value (RMS) using DM3068 and DS2202 ("DS2302"). I set each value in the DG using the DM3068 measurement.
3) Fit a line through DS2302 vs DM3068 measurements (needed to do this so that I could correct my scope measurements since it had a small offset)
4) Save and set cal item to LF flat.
5) Set each point value to the measured value on the DM3068.
6) Save and set cal item to HF flat. (DG will automatically set output to 50-ohm for this cal item.)
7) Connect a 50-ohm through terminator to the scope.
8) Use the corrected RMS value from the DS2302 (using the relationship in step 3) and calculate dBm. dBm=10*LOG10(Vrms^2/(50*0.001))  Record this value into the DG for each point.
9) Save and enjoy flat response from DG.

The only problem I have is that I have quite a bit of drop off when I get to low frequencies, say at 1Hz and below. (Is this normal? - Probably not. I'm redoing my channel 2 to see if this problem exists on channel 2.)

EDIT: Added channel 2 plot. Again, below 10 Hz, I'm seeing rapid fall-off (maybe something wrong with my cal method.)  At 1 Hz, I've got around -4 dB (the plots start at 10 Hz, so this isn't shown.) :-//  10 Hz and above is very flat, though.  :-+

Thanks,
Clayton



Title: CAN protocoll?
Post by: Pinkus on December 05, 2013, 08:18:47 am
Maybe I missed this information in this huge thread:
At a DS2072 (not DS2072A), improved to 200/300 Mhz: can the CAN protocoll analyzer be enabled in any way or not?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Marc M. on December 05, 2013, 11:48:35 am
...see the values that an Owner with a DG4162 can help as a base line values...
I took the time to record the cal values in my DG4162 for the community effort and stuck them in an Excel 97 xls file.  I recorded the values for CH1 first then started to do CH2 and realized they were all identical.  I then did some spot checking of random values and couldn't find any differences between the 2 channels so I didn't spend the time to finish going thru all of CH2. 

I also had a problem reading all the values for LOAD except the first (1-1).  I kept getting a dialog box stating that I needed to remove the 50ohm load.  Both channels were set internally to HI-Z and there were no loads connected to the generator.  I was unable to select any other item under load apart from 1-1. 

I also encountered odd behavior under HFLAT.  When I initially started recording values, the units were in dBm.  At some point I accidentally exited the cal procedure.  When I re-entered it I got a warning dialog that the units were in mVrms :o.  I power cycled the generator and re-entered the HFLAT cal table and it was back to dBm.  I finished recording the dBm values, I jumped out and back in to trigger the mVrms values to record those.  It turns out that they are identical to the dBm values :wtf:  ?? ?? ??

I hope this helps.  If there is anything else I can do to help, feel free to ask.

Marc -
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on December 05, 2013, 02:07:54 pm
Well that is great news, congratulations.  I will be going ahead also of course, but I have to wait a few days due to a family medical issue.  In the meantime it would be nice to see your before/after spreadsheet data.  It is encouraging to hear that you were able to successfully complete the process.  Thank you for describing your method and offering to share your data with us.

Ted,

As promised, here's a plot of my pre-cal / post-cal (for Channel 1, Channel 2 is similar) after I hacked my DG4102 to a DG4202. As you can see, it looks DANG good after the cal.

Here's a little more description of the steps I did (I didn't do things in the cleanest way, but it gave good results, so...)

1) Set cal item to AC amplitude (all measurements here are at 1kHz if I recall correctly.)
2) Go through and record each voltage value (RMS) using DM3068 and DS2202 ("DS2302"). I set each value in the DG using the DM3068 measurement.
3) Fit a line through DS2302 vs DM3068 measurements (needed to do this so that I could correct my scope measurements since it had a small offset)
4) Save and set cal item to LF flat.
5) Set each point value to the measured value on the DM3068.
6) Save and set cal item to HF flat. (DG will automatically set output to 50-ohm for this cal item.)
7) Connect a 50-ohm through terminator to the scope.
8) Use the corrected RMS value from the DS2302 (using the relationship in step 3) and calculate dBm. dBm=10*LOG10(Vrms^2/(50*0.001))  Record this value into the DG for each point.
9) Save and enjoy flat response from DG.

The only problem I have is that I have quite a bit of drop off when I get to low frequencies, say at 1Hz and below. (Is this normal? - Probably not. I'm redoing my channel 2 to see if this problem exists on channel 2.)

EDIT: Added channel 2 plot. Again, below 10 Hz, I'm seeing rapid fall-off (maybe something wrong with my cal method.)  At 1 Hz, I've got around -4 dB (the plots start at 10 Hz, so this isn't shown.) :-//  10 Hz and above is very flat, though.  :-+

Thanks,
Clayton

Thank you very much Clayton.  This is great.

Was it necessary to go through Menu 1 (AC) and 2( LFLAT)? Could you have avoided some of the LF issues (10 Hz and below) by leaving these as they were?

I was assuming before that it may be possible to skip these and just deal with Menu item 3 (HFLAT) (?).

   Thanks for all the info and your help, Ted
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on December 05, 2013, 02:42:29 pm
...see the values that an Owner with a DG4162 can help as a base line values...
I took the time to record the cal values in my DG4162 for the community effort and stuck them in an Excel 97 xls file.  I recorded the values for CH1 first then started to do CH2 and realized they were all identical.  I then did some spot checking of random values and couldn't find any differences between the 2 channels so I didn't spend the time to finish going thru all of CH2. 

I also had a problem reading all the values for LOAD except the first (1-1).  I kept getting a dialog box stating that I needed to remove the 50ohm load.  Both channels were set internally to HI-Z and there were no loads connected to the generator.  I was unable to select any other item under load apart from 1-1. 

I also encountered odd behavior under HFLAT.  When I initially started recording values, the units were in dBm.  At some point I accidentally exited the cal procedure.  When I re-entered it I got a warning dialog that the units were in mVrms :o.  I power cycled the generator and re-entered the HFLAT cal table and it was back to dBm.  I finished recording the dBm values, I jumped out and back in to trigger the mVrms values to record those.  It turns out that they are identical to the dBm values :wtf:  ?? ?? ??

I hope this helps.  If there is anything else I can do to help, feel free to ask.

Marc -

Thank you Marc:  This excel listing is great and will serve as a nice sanity check when we input our data. If something looks off from what you have, then it will at least put up a red flag to reconsider what we are doing.  And your note about HFLAT switching from dBm to Vrms will certainly save us a potential WTF, or worst yet a heart attack.  Hi

I asked Clayton (above) if it was necessary to go thu AC and LFLAT settings. You of course thought it was required also. Is it clear that this is required once you get started? I originally assumed it was required, then later that maybe it could be avoided (?), with just possibly HFLAT having to be done.  Thanks for your assistance, Ted
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bandgap on December 05, 2013, 05:00:04 pm
In the meantime it would be nice to see your before/after spreadsheet data.  It is encouraging to hear that you were able to successfully complete the process.  Thank you for describing your method and offering to share your data with us.

I'll clean up my spreadsheet sometime and upload it in the next day or so. You CAN calibrate the HF flat curve without having going through the AC amplitude and LF flat curve. You might want to start with HF flat and see if that flattens everything up on the high end while keeping your low end in tact. I may even restore my preset values and do the same.

I re-calibrated my LF flat curve very carefully and also did a calibration of the DC offset (very easy to do that one.) However, this didn't fix my drop-off below 10 Hz. The fact that I have the same thing for both channel 1 and 2 suggests that it wasn't just a silly error of entering a number incorrectly.

-Clayton
 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on December 05, 2013, 07:25:22 pm
In the meantime it would be nice to see your before/after spreadsheet data.  It is encouraging to hear that you were able to successfully complete the process.  Thank you for describing your method and offering to share your data with us.

I'll clean up my spreadsheet sometime and upload it in the next day or so. You CAN calibrate the HF flat curve without having going through the AC amplitude and LF flat curve. You might want to start with HF flat and see if that flattens everything up on the high end while keeping your low end in tact. I may even restore my preset values and do the same.

I re-calibrated my LF flat curve very carefully and also did a calibration of the DC offset (very easy to do that one.) However, this didn't fix my drop-off below 10 Hz. The fact that I have the same thing for both channel 1 and 2 suggests that it wasn't just a silly error of entering a number incorrectly.

-Clayton

Clayton:  How are you measuring below 10 Hz?  Isn't that a little tricky, as in, don't you have to use DC coupling in your O'Scope to see it.  And I don't think most DMM's will do very well at this low of a frequency.  Excuse me, I'm sure you know all this, but just in case you forgot it.  Ted
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bandgap on December 05, 2013, 07:32:29 pm
Clayton:  How are you measuring below 10 Hz?  Isn't that a little tricky, as in, don't you have to use DC coupling in your O'Scope to see it.  And I don't think most DMM's will do very well at this low of a frequency.  Excuse me, I'm sure you know all this, but just in case you forgot it.  Ted

Yeah, the DMM certainly can't do it very well. I was using the scope to measure it when I was evaluating the before/after. I don't believe any of the calibration points are at frequencies that low, though.

-Clayton
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Radardude on December 05, 2013, 08:28:03 pm
1ns TB, 200M BW Limit, and correct DS2302 Model type *yeah* ;-)

Orange noticed that the trigger is off by 3divs (lags behind) if u enable the 2nd channel - same happening, but only in 1ns mode.
maybe that is the reason why there is no official DS2302 version - anyhow i can live with that small limitation as it vanishes above 1ns TB

here is the version that will take care of model type string

http://www.filedropper.com/ds2302rilol (http://www.filedropper.com/ds2302rilol)

the "recalc" of the string is triggered by option un/install - so flush keys, and reapply them and it will become active.

did a selfcal on top of that - everything good.

Thanks to everyone who contributed to making the DS2000 series an awesome scope. I was looking at the Hantek until I came across this message board. I'm about to retire from my ATC electronic technician job. So I was in need of a oscope. After reading about DS2072, I purchase one from Tequipment. As we all know that the higher the bandwidth the higher the noise level. So here are some photos confirming the bandwidth increase using cybernet modified firmware ds2302rilol. First photo is using the latest factory firmware and all option installed. The rest of the photos are using cybernet modified firmware. Notice that the DS2202 has 840 uv of noise and the DS2302 has 1.16 mv of noise. :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on December 05, 2013, 09:23:35 pm
In the meantime it would be nice to see your before/after spreadsheet data.  It is encouraging to hear that you were able to successfully complete the process.  Thank you for describing your method and offering to share your data with us.

I'll clean up my spreadsheet sometime and upload it in the next day or so. You CAN calibrate the HF flat curve without having going through the AC amplitude and LF flat curve. You might want to start with HF flat and see if that flattens everything up on the high end while keeping your low end in tact. I may even restore my preset values and do the same.

I re-calibrated my LF flat curve very carefully and also did a calibration of the DC offset (very easy to do that one.) However, this didn't fix my drop-off below 10 Hz. The fact that I have the same thing for both channel 1 and 2 suggests that it wasn't just a silly error of entering a number incorrectly.

-Clayton

Clayton:  I'm looking forward to seeing your spreadsheets when they are done.  Thank you for offering to share them.

I'll do the HFLAT cal. and post the results.  Thank you for suggesting going ahead without doing AC and LFLAT.

Do you think there is anything to be gained by doing the AC and LFLAT calibrations, or do you think we can skip them without loosing something?  Or is it too soon to know?

Ted
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bandgap on December 06, 2013, 01:54:40 am
I'll do the HFLAT cal. and post the results.  Thank you for suggesting going ahead without doing AC and LFLAT.

Do you think there is anything to be gained by doing the AC and LFLAT calibrations, or do you think we can skip them without loosing something?  Or is it too soon to know?

Ted

Well based on your results, we should know! :) I may also reset mine to preset values and just do the HFLAT calibration to see how things turn out.

-Clayton

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: thetooth on December 06, 2013, 06:34:25 am
As promised here is GEL file for DS2000A: http://thetooth.name/dev/DS2000(DSP)update%20(2).rar (http://thetooth.name/dev/DS2000(DSP)update%20(2).rar)

Version is 00.02.01.00.03 November 5th, 2013, i have not tested it but hopefully someone here will find it interesting.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on December 06, 2013, 07:39:46 am
So DS2000 and DS2000A series are the same then, almost?, signature in the top are similar/same? DS2202
00.02.01.00.03


from the file:
DS2072A
DS2102A
DS2202A
DS2302A
MSO2072A
MSO2102A
MSO2202A
MSO2302A
MSO2072
MSO2102
MSO2202
MSO2302

USB
RS232
SPI
I2C
CAN
56M/28M
100M BandWidth
200M BandWidth
300M BandWidth
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Pinkus on December 06, 2013, 08:07:59 am
Well, the firmware also shows these strings:
CAN
LIN
USB

So, how can somebody enable CAN / LIN / USB protocol analyzer at a DS2072??

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on December 06, 2013, 11:46:14 am
Well, the firmware also shows these strings:
CAN
LIN
USB

So, how can somebody enable CAN / LIN / USB protocol analyzer at a DS2072??

The USB may be only for trigger selection, not protocol decoding.

As for LIN, that's not available on either the 4000 or 6000-series, so I doubt that's available in any way.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 06, 2013, 02:09:17 pm
So DS2000 and DS2000A series are the same then, almost?, signature in the top are similar/same? DS2202
00.02.01.00.03...
The .GEL firmware name is also exactly the same for both the DS2000 and DS2000A series: DS2000Update.GEL
So maybe the DS2000 series can also be updated with the DS2000A firmware.

from the file:
DS2072A
DS2102A
DS2202A
DS2302A
MSO2072A
MSO2102A
MSO2202A
MSO2302A
MSO2072
MSO2102
MSO2202
MSO2302
...
From the .GEL file it looks like Rigol has plans to also release a MSO2000/MS2000A series with built-in logic analyzer.
So far they only make MSO4000 and DS1000D series with built-in logic analyzers.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Tom01 on December 06, 2013, 02:12:01 pm
So maybe the DS2000 series can also be updated with the DS2000A firmware.

Is anyone going to risk the upgrade firmware on your DS2000 from DS2000A? ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 06, 2013, 02:14:22 pm
So maybe the DS2000 series can also be updated with the DS2000A firmware.

Is anyone going to risk the upgrade firmware on your DS2000 from DS2000A? ;)
Probably not before the DS2000A firmware has been hacked.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 06, 2013, 02:38:36 pm
Is anyone going to risk the upgrade firmware on your DS2000 from DS2000A? ;)

Since even their dealers/service personnel might mistakenly use the wrong FW file at some point, I would hope Rigol has given some thought to handling this possibility gracefully:
i.e. A-version FW won't load - OR - A-version FW is compatible - OR - A-version FW is not compatible but an older non-A version can just be boot-loaded over it...
- but perhaps I'm giving them too much credit  ;)

I'd give it a try - but am in the middle of a job and can't run even the small risk of down time on the DSO right now. Perhaps in another week or so.

Meanwhile, I'll email Drieg and see if he knows the answer.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 06, 2013, 02:44:46 pm
I'd give it a try - but am in the middle of a job and can't run even the small risk of down time on the DSO right now. Perhaps in another week or so.

You are brave!!!  Given their power on / help button method which seems to invoke some sort of bootloader that does very little (no display, etc.), probably you can *try* it and it will either (1) load the fw or (2) not load it, and then possibly B (1) boot it or (2) not boot it.  If it boots it may be buggy or it may be ok.

With any luck, hopefully no matter what the outcome, you will be able to return to ds2000 firmware using the help button method...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 06, 2013, 02:51:22 pm
I'm going to dig around to see if I can find secret key sequences, like the menu7-menu6-menu7 type thing.  Does anyone know how the control panel connects to the blackfin?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 06, 2013, 03:01:03 pm
Since even their dealers/service personnel might mistakenly use the wrong FW file at some point...
They already have mixed up the firmwares, when they sent the latest DS2000 frimware to "thetooth" when he asked for the latest firmware for DS2000A: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg341839/#msg341839 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg341839/#msg341839)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: g***! on December 06, 2013, 03:37:44 pm
Is anyone going to risk the upgrade firmware on your DS2000 from DS2000A? ;)

Someone had to try running the firmware  ;D Runs fine on my DS2202, but no CAN decoding showing in the options list unfortunately.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Tom01 on December 06, 2013, 03:41:47 pm
Someone had to try running the firmware  ;D Runs fine on my DS2202, but no CAN decoding showing in the options list unfortunately.

So D2000A is different from hardware D2000, right? Someone wrote that it was just a different firmware. Hmmm ....
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 06, 2013, 03:51:45 pm
Someone had to try running the firmware  ;D Runs fine on my DS2202, but no CAN decoding showing in the options list unfortunately.
So D2000A is different from hardware D2000, right?
The only difference is that DS2000A has a 50 ohm input termination option.
But I think the DS2000 non-A version with HW 2.0 has this too, not sure if the PCB is populated with the 50 ohm termination.
Basically DS2000 with HW 2.0 seems to be the same HW as used by DS2000A.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Tom01 on December 06, 2013, 03:55:07 pm
But I think the DS2000 non-A version with HW 2.0 has this too, not sure if the PCB is populated with the 50 ohm termination.
Basically DS2000 with HW 2.0 seems to be the same HW as used by DS2000A.

I understand. We can not unlock version A, shows "only" with another, newer firmware?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 06, 2013, 04:01:01 pm
Someone had to try running the firmware  ;D Runs fine on my DS2202, but no CAN decoding showing in the options list unfortunately.
Nice  :-+

Does the DS2000 device options installed via the keygen still work after the FW upgrade?

Does the FW menu still say DS2202 or does it say DS2202A?

Can you downgrade to an older DS2000 FW again?


CAN Analysis kit does not come pre-installed on DS2000A:
http://www.rigol.com/prodserv/DS2000A/ (http://www.rigol.com/prodserv/DS2000A/)
Quote
Decoding Options
RS232,I2C,SPI Decoding Kit     SD-DS2000A
CAN Analysis kit(Trigger+Decoding)     CAN-DS2000A

It is an optional add-on feature you can purchase for both DS2000 and DS2000A according to Tequipment:
http://www.tequipment.net/RigolPricelist.html (http://www.tequipment.net/RigolPricelist.html)
Quote
CAN-DS2000A   CAN trigger and decode for DS2000 and DS2000A

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: g***! on December 06, 2013, 04:11:46 pm
The model number is still DS2202 (not A), all keys still install/uninstall OK, but I forgot to try going back to a previous FW...Will do that now and report back!

Update: Tried downgrading FW....not working...OOPs

Panic over lol, now sucessfully downgraded again...Did'nt do it correctly first time. |O
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Bugware on December 06, 2013, 04:35:27 pm
So far I understand, there are at least two differences between DS2000 HW2 and DS2000A:


May the Firmware recognize that?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on December 06, 2013, 04:36:05 pm
The model number is still DS2202 (not A), all keys still install/uninstall OK,

Just tried the same on a DS2202 (DS2072) hardware version 2, same result.
No CAN option and the 50 ohm input still greyed out. I wonder if it has something to do with these little jumpers on the pcb.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JDubU on December 06, 2013, 04:40:48 pm
So far I understand, there are at least two differences between DS2000 HW2 and DS2000A:

  • Hardware Version of DS2000 is 1.0.2.0.0 and DS2000A is 1.0.2.0.2
  • The type of the Serial number has changed from DS2Axxxxxxxxx to DS2Dxxxxxxxxx

May the Firmware recognize that?

There are examples of the DS2000A with each of these hardware versions:

Hardware Version: 1.0.2.0.0
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg316379/#msg316379 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg316379/#msg316379)

Hardware Version: 1.0.2.0.2
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg341494/#msg341494 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg341494/#msg341494)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on December 06, 2013, 04:40:55 pm

Hardware Version of DS2000 is 1.0.2.0.0 and DS2000A is 1.0.2.0.2[/li][/list]

FWIW: My DS2000 has hardware version 1.0.2.0.1
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 06, 2013, 04:47:07 pm
As promised here is GEL file for DS2000A: http://thetooth.name/dev/DS2000(DSP)update%20(2).rar (http://thetooth.name/dev/DS2000(DSP)update%20(2).rar)

Version is 00.02.01.00.03 November 5th, 2013, i have not tested it but hopefully someone here will find it interesting.
Have you asked for a changelog?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Bugware on December 06, 2013, 05:00:03 pm
The model number is still DS2202 (not A), all keys still install/uninstall OK, but I forgot to try going back to a previous FW...Will do that now and report back!

Update: Tried downgrading FW....not working...OOPs

So you got a DS2202 with a new Firmware 00.02.01.00.03, right?
What are the FPGA version (SPU, WPU, CCU, MCU)? Any changes?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on December 06, 2013, 05:08:21 pm
DG4000 Calibration Restoration:

I just finished calibrating my DG4000 for Channel 1 and 2, and the frequency response is flat up to 200 MHz and well within +/- 0.8 dB.

I very tediously calibrated channel 1 and recorded all the levels and frequencies for each of the 60 steps for HFLAT Cal.
And HFLAT is the only calibration routine that I did.

When I got done and checked channel 1 the response was great as noted above.  But, I said to myself - WT*.  Why? Because in going through the routine I never saw any frequency above 65 MHz, and therefore I never changed changed any of the levels.

So what is calibration? I have concluded that it is removing the un-calibration that you end up with after you install the firmware patch to extend the frequency!   That's right. . .   Now is that unbelievable, or not.

So to calibrate (or rather restore the previous calibration of) your DG4000:

Press - Utility, Test/Cal, Secure Code, (put in PW) 2010, Enter, Secure OFF, (the result should be) Secure ON, Access gained.
Then for Cal. select HFLAT, Call Point (start at HFLAT 1-1), Measure Value, Input Value, press Save and wait for it to complete (about 3 seconds), select Cal Point for the next step.  Repeat for all 60 steps.  Then your done and you didn't have to make measurements or level changes.  You didn't even have to hook anything up to your DG4000 except for AC power. Hi

Repeat for the remaining channel.

   Cheers, Ted

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: g***! on December 06, 2013, 05:16:51 pm
The model number is still DS2202 (not A), all keys still install/uninstall OK, but I forgot to try going back to a previous FW...Will do that now and report back!

Update: Tried downgrading FW....not working...OOPs

So you got a DS2202 with a new Firmware 00.02.01.00.03, right?
What are the FPGA version (SPU, WPU, CCU, MCU)? Any changes?

SPU  03.01.09
WPU 00.07.01
CCU  12.29.00
MCU  02.12

I think there has been changes, but I dont have a record of the origional data.

The SCPI command no longer switches in the 50 Ohm termination :--
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Bugware on December 06, 2013, 05:22:59 pm

...

SPU  03.01.09
WPU 00.07.01
CCU  12.29.00
MCU  02.12

I think there has been changes, but I dont have a record of the origional data.

Cool, thanx.  :-+

I think only the SPU and WPU were changed.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on December 06, 2013, 05:28:59 pm
does it exist any windows program to take apart the GEL files?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 06, 2013, 05:32:53 pm
The model number is still DS2202 (not A), all keys still install/uninstall OK, but I forgot to try going back to a previous FW...Will do that now and report back!

Update: Tried downgrading FW....not working...OOPs

I didn't have any problems downgrading again - but I did have some problems when running the new FW version on my DS2000.

I had a few complete hangs - some of which I was able to clear by re-booting - and the final one I couldn't get rid of (the DSO would be frozen even after booting) until I downgraded. It's clear the "saved" selections for each menu item (that have more than 2 settings) get out-of-whack and can cause problems. You have to cycle through menu selections to get a feature to operate correctly sometimes.

According to Drieg, they've changed the structure of unit settings stored in FRAM memory - and he mentioned these hints for the update process:

- use boot method to flash it
- you may experience the unit will hang up in splash screen (RIGOL logo) - reseting FRAM to default will help: keep pressing left menu key F6 (sixth)
- load default settings

I couldn't get my DSO to stop hanging by using the F6 method - so I downgraded. But perhaps the best thing (for non-A owners) is to follow these steps:

1) Before upgrading - set 'Default' for System->Power On
2) Upgrade via boot method
3) During first boot up after upgrade, hold in left-menu F6 (sixth gray button) during the boot

Maybe this will prevent hang-ups while running the FW.

More info about any improvements found, bug fixes, or new bugs added since v.01.01.00.02 will be posted over in the DS2000 thread. (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg343485/#msg343485)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on December 06, 2013, 08:47:42 pm
DG4000 Calibration Restoration:
Re. My previous post #1771 above.

I now believe that the Restoration of the DG4000 calibration should be done for AC, LFLAT, and HFLAT to correct some other potential glitches.  Nothing is being changed, or has to be connected to the DG4000, so the process goes fast.  Just bring up and save all the default values for each step, starting with 1, or 1-1 (A/R).
You can also do this for 'Inner Imped' and 'Offset', although I haven't seen a case or benefit for it yet.

I just wouldn't do this for Freq Accuracy, or Counter, unless you see a need for it, and then you should complete this cal. process as prompted.

The calibration restoration is effective for both channels, so it isn't necessary to repeat each cal. routine for the other channel.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Teneyes on December 07, 2013, 11:33:53 am
DG4000 Calibration Restoration:
   So to calibrate (or rather restore the previous calibration of) your DG4000:

Press - Utility, Test/Cal, Secure Code, (put in PW) 2010, Enter, Secure OFF, (the result should be) Secure ON, Access gained.
Then for Cal. select HFLAT, Call Point (start at HFLAT 1-1), Measure Value, Input Value, press Save and wait for it to complete (about 3 seconds), select Cal Point for the next step.  Repeat for all 60 steps.  Then your done and you didn't have to make measurements or level changes.  You didn't even have to hook anything up to your DG4000 except for AC power. Hi


DG4000 Calibration Restoration:
I think the  steps:
   "Measure Value",
   "Input Value",
   "Rotate select next cal Point"
 can be stepped thru the 62 points and then save only once to save time ,

Does anyone else see the output drop-off increases from 160-200 MHz?
or is that just my scope.

or is that why Rigol only offered  up to DG4162

ps should this Discussion be moved to the DG4000 Blog
DG4000-a-firmware-investigation
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on December 07, 2013, 01:34:57 pm
DG4000 Calibration Restoration:
   So to calibrate (or rather restore the previous calibration of) your DG4000:

Press - Utility, Test/Cal, Secure Code, (put in PW) 2010, Enter, Secure OFF, (the result should be) Secure ON, Access gained.
Then for Cal. select HFLAT, Call Point (start at HFLAT 1-1), Measure Value, Input Value, press Save and wait for it to complete (about 3 seconds), select Cal Point for the next step.  Repeat for all 60 steps.  Then your done and you didn't have to make measurements or level changes.  You didn't even have to hook anything up to your DG4000 except for AC power. Hi


DG4000 Calibration Restoration:
I think the  steps:
   "Measure Value",
   "Input Value",
   "Rotate select next cal Point"
 can be stepped thru the 62 points and then save only once to save time ,

Does anyone else see the output drop-off increases from 160-200 MHz?
or is that just my scope.

or is that why Rigol only offered  up to DG4162

ps should this Discussion be moved to the DG4000 Blog
DG4000-a-firmware-investigation

Yes, everyone with the DG4000 freq. expansion patch will have the issue of level drop-off starting somewhere above 120 MHz, although the Calibration Restoration  corrects it.

Thanks for the tip on speeding up the process by Saving at the end.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on December 07, 2013, 03:54:30 pm
had some questions in my inbox, pretty busy atm so not really time to further play with rigols until xmas.

anyhow for those playing with IDA here is an updated bundle of DG/DS flirt signatures for IDA - somehow signatures for bfin suck (cpu module needs updating) but its better than nothing.

http://www.sendspace.com/file/xdvlw2 (http://www.sendspace.com/file/xdvlw2)

and here is a bfin loader/cpu module for ida that supports reading LDR format (extracted dump_00_XXX from GEL files which i postet earlier) - geltool kit will
take some time to release, its to dangerous right now, because u could f***up your bootloader if not careful.

http://www.sendspace.com/file/ymtg9g (http://www.sendspace.com/file/ymtg9g)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on December 07, 2013, 07:26:56 pm
So DS2000 and DS2000A series are the same then, almost?, signature in the top are similar/same? DS2202
00.02.01.00.03...
The .GEL firmware name is also exactly the same for both the DS2000 and DS2000A series: DS2000Update.GEL
So maybe the DS2000 series can also be updated with the DS2000A firmware.

Yes, that is actually a possibility.

Quote
From the .GEL file it looks like Rigol has plans to also release a MSO2000/MS2000A series with built-in logic analyzer.

Yes, this has been known for some time.  Ever since a DS2000 with the Rev2 hardware was opened, and the motherboard revealed spots for the LA FPGA, and the optional SigGen.  They're doing things in stages.  Someday there's likely to be an MSO2xx2A-S too.  What some would like to see is an MSO/DS2xx4A, but no indications of that happening.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on December 07, 2013, 08:25:02 pm
So maybe the DS2000 series can also be updated with the DS2000A firmware.

Yes, that is actually a possibility.


Yesterday in this thread myself and someone else posted that we updated our DS2000 with this software.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on December 07, 2013, 11:20:28 pm
Hello all :)

I was looking around for a new DSO and a colleague pointed me to the Rigol series.
I decided to get a DS2102, did some search about them and found this place after watching the video on youtube :D
Then I found out about a cookie generator to unlock the options.

After reading several postings here on the forum I'm still not sure what to do, especially since I  just found out that now there's a DS2102A and a DS2102A-S a few minutes ago.
And now I have some quick questions, I hope this thread is the correct one to ask (please don't shoot me if not D:)

What  would you suggest me? Is the -S version useful since it has a waveform generator or does the A-version also have this generator but it needs to be unlocked?
Can I unlock the A-version and the A-S-versions without problems at this moment?
The 200 MHz option makes the 2102 into "the same" 2202, that can be bought as an independent device?

Thanks for quick replies and a little help :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jboard146 on December 08, 2013, 12:59:00 am
had some questions in my inbox, pretty busy atm so not really time to further play with rigols until xmas.

anyhow for those playing with IDA here is an updated bundle of DG/DS flirt signatures for IDA - somehow signatures for bfin suck (cpu module needs updating) but its better than nothing.

http://www.sendspace.com/file/xdvlw2 (http://www.sendspace.com/file/xdvlw2)

and here is a bfin loader/cpu module for ida that supports reading LDR format (extracted dump_00_XXX from GEL files which i postet earlier) - geltool kit will
take some time to release, its to dangerous right now, because u could f***up your bootloader if not careful.

http://www.sendspace.com/file/ymtg9g (http://www.sendspace.com/file/ymtg9g)


I may have sometime in the next week or two to use IDA to look at the firmware files. I'm not a IDA guru, but have access to. Do you have some sort quick how-to on how to open the GEL files in IDA?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 08, 2013, 02:18:24 am
and here is a bfin loader/cpu module for ida that supports reading LDR format

Should there be a rigol_ldr.ldw file in that release directory too?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on December 08, 2013, 03:11:36 am
DG4000 Calibration Information is attached that includes the basic factory default level settings:

These documents are preliminary, although they provide a good insight into the DG400 calibration.

Applies to models DG4062 through DG4202.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: anakron on December 08, 2013, 03:35:17 am
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
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 08, 2013, 04:09:46 pm
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.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JDubU on December 08, 2013, 04:27:58 pm
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 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg336779/#msg336779)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 08, 2013, 04:51:47 pm
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 (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..
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on December 08, 2013, 04:54:42 pm
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? :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 08, 2013, 05:01:21 pm
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.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JDubU on December 08, 2013, 05:40:43 pm

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 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg343230/#msg343230)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: staze on December 08, 2013, 06:01:13 pm
Or it's just based on serial number.  :/
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 08, 2013, 06:14:16 pm
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.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on December 08, 2013, 09:17:39 pm
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 (https://www.eevblog.com/forum/testgear/rigol-2072a/msg335063/#msg335063), and again 13 days ago (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg336990/#msg336990):

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.


Quote
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.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: g***! on December 08, 2013, 09:28:36 pm

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

Tried this a few minutes ago, successfully.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 08, 2013, 09:35:43 pm
Yes, that's the question I asked 16 days ago (https://www.eevblog.com/forum/testgear/rigol-2072a/msg335063/#msg335063), and again 13 days ago (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg336990/#msg336990)
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.

Quote
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).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 08, 2013, 09:38:41 pm
They have changed the "A" firmware to make it more difficult.  If you scan the firmware, there are no keys in plaintext any longer.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 08, 2013, 09:50:07 pm
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.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 08, 2013, 10:02:12 pm
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.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on December 09, 2013, 12:45:13 am
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

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 09, 2013, 12:55:19 am
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.

Quote
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.

Quote
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.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 09, 2013, 01:19:52 am
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?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 09, 2013, 03:25:56 am
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.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: fcab100 on December 09, 2013, 08:07:49 am
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.


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on December 09, 2013, 01:13:58 pm
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).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on December 09, 2013, 02:37:15 pm
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.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on December 09, 2013, 03:21:28 pm
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).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 09, 2013, 03:55:18 pm
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. (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg344328/#msg344328)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on December 09, 2013, 04:20:21 pm
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. (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg344328/#msg344328)

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.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on December 09, 2013, 04:54:06 pm
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. (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg344328/#msg344328)

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.

So why isn't the keygen working, then?

Thank you for jumping in and working on this, by the way.  I love it when a community comes together.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 09, 2013, 04:54:25 pm
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.

So the keygen only has to be modified to work with the changed A-model "DS2Dxxxxxxxxx" serial numbers?

Edit: Ahh... I just noticed you edited your post to reflect the possibility of two public keys.

It seems to me that it's likely the presence of a "D" serial number (or jumpers/pull-ups on the PCB) involves using a different public key/technique - and also the availability of the CAN option and 50 Ohm input (which non-A model Hardware v.2 owners are unable to access).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 09, 2013, 04:58:50 pm
There has to be some other cause.  Could they have limited the seed (which has been a wide open int32) to a specific value?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on December 09, 2013, 04:59:40 pm
So why isn't the keygen working, then?

They may use two separate keys or different hashing/encoding algorithms for 'non-A' and 'A' license codes.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on December 09, 2013, 05:54:26 pm
They may use two separate keys or different hashing/encoding algorithms for 'non-A' and 'A' license codes.

that explains why the verification routines look a bit different ... i wish the stupid ida signatures would work better, kinda sick of going over the miracl lib again ;)
given the possibility to patch firmware, it probably easier to override it now, then to update the keygen (if the private key can be found this time)


Code: [Select]
SDRAM:EE7440 ECC_8445B2BE29E5C7:   dd 0xDEB95897           # DATA XREF: sub_71C7E+24?
SDRAM:EE7444                 dd 0x1011C524
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olsenn on December 09, 2013, 06:16:03 pm
I've read several reports that 300MHz has been enabled in the DS2000 (not 'A') scopes, but that it wasn't actually providing 300MHz? Can anybody confirm or deny this? Also, can the lo-z input be toggled from the menu now?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on December 09, 2013, 06:44:00 pm
I've read several reports that 300MHz has been enabled in the DS2000 (not 'A') scopes, but that it wasn't actually providing 300MHz? Can anybody confirm or deny this? Also, can the lo-z input be toggled from the menu now?

Enabled, yes.  Actually 300MHz?  I don't know.  The 50ohm impedance is present only on the A models and I believe this is a change in the actual hardware that is only present on the A models.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mtdoc on December 09, 2013, 06:49:53 pm
I've read several reports that 300MHz has been enabled in the DS2000 (not 'A') scopes, but that it wasn't actually providing 300MHz? Can anybody confirm or deny this? Also, can the lo-z input be toggled from the menu now?

If you look back a few weeks in this thread you'll see that actual 300MHz bandwidth has been confirmed by several posters by both rise time measurements and -3dB frequency testing.

Personally, I don't have the equipment to confirm the actual bandwidth on mine but I can confirm that it is >200MHz.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 09, 2013, 06:54:36 pm
The 50ohm impedance is present only on the A models and I believe this is a change in the actual hardware that is only present on the A models.

I believe the DS2000A is HW identical to the DS2000 HW revision 2.0  - except perhaps for some jumpers or setting pull-up resistors. I think Rigol designed the new PCBs to be able to be used for filling existing DS2000 orders - while starting up production of the new A and A-S models.

I think the ONLY reason 50 Ohm impedance (and CAN trigger/decoding) is not available on non-A HW revision 2.0 models is product differentiation.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on December 09, 2013, 07:08:28 pm
I believe the DS2000A is HW identical to the DS2000 HW revision 2.0  - except perhaps for some jumpers or setting pull-up resistors.

Are you basing that on anything known?  I mean no offense.  You've been saying this for a while, so clearly you're sure.  I've not seen any proof (enable A features on hardware sold as non-A) yet.

I think Rigol designed the new PCBs to be able to be used for filling existing DS2000 orders - while starting up production of the new A and A-S models.

Backward compatibility on new hardware does not necessitate forward compatibility on old hardware.  You're probably right, and I think we'll eventually discover a serial number "line in the sand" or board revision where the inclusion of the 50-ohm option starts.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: staze on December 09, 2013, 07:10:31 pm
[
I think Rigol designed the new PCBs to be able to be used for filling existing DS2000 orders - while starting up production of the new A and A-S models.

Backward compatibility on new hardware does not necessitate forward compatibility on old hardware.  You're probably right, and I think we'll eventually discover a serial number "line in the sand" or board revision where the inclusion of the 50-ohm option starts.

Yes, hardware version 2. It HAS the 50ohm terminator... and can be switched on with SPI. We just need to figure out how to enable it in the GUI.

I still have a feeling this is nothing more than the firmware checking the serial number, and enabling options based on that. It's the simplest way programmatically, and it would seem Rigol is all about simple.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on December 09, 2013, 07:18:50 pm
but the S-version has extra hardware for the waveform gen I guess? (beside the extra BNC connectors on the back side)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: staze on December 09, 2013, 07:19:17 pm
but the S-version has extra hardware for the waveform gen I guess? (beside the extra BNC connectors on the back side)

Correct.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 09, 2013, 07:25:54 pm
Are you basing that on anything known?  I mean no offense.  You've been saying this for a while, so clearly you're sure.  I've not seen any proof (enable A features on hardware sold as non-A) yet.
Well, I always write 'I believe' or 'I think' - so I'm not absolutely sure. But I'm basing it on posted photos of HW revision 2.0 boards (https://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0/msg270218/#msg270218) (showing the areas for AWG module add-on) - as well as other reliable information.

Here is a photo of the input stage of DS2000 HW revision 2.0 and 1.0 compared  (https://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0/msg270243/#msg270243)- with the 50 Ohm input resistor and extra relay clearly visible on 2.0 board.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on December 09, 2013, 07:37:37 pm
I still have a feeling this is nothing more than the firmware checking the serial number, and enabling options based on that. It's the simplest way programmatically, and it would seem Rigol is all about simple.

It is equally simple to check the version of a Rigol ASIC or the firmware revision of some other chip, and those things won't be nearly as easy to change post-manufacture.  Sure, you can change how the firmware does the checking, or change the value the firmware looks for, but if the ASIC itself won't enable 50 ohms, changing the firmware won't do much.

edit: i'm being a debbie downer, sorry.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: staze on December 09, 2013, 07:50:08 pm
I still have a feeling this is nothing more than the firmware checking the serial number, and enabling options based on that. It's the simplest way programmatically, and it would seem Rigol is all about simple.

It is equally simple to check the version of a Rigol ASIC or the firmware revision of some other chip, and those things won't be nearly as easy to change post-manufacture.  Sure, you can change how the firmware does the checking, or change the value the firmware looks for, but if the ASIC itself won't enable 50 ohms, changing the firmware won't do much.

edit: i'm being a debbie downer, sorry.

Yes, but as I mentioned, you can enable 50ohms through SPI... so clearly that's just a GUI thing. =/

But yes, it could be checking something else. I'm just being a Ollie Optimist. =P
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: WVL_KsZeN on December 09, 2013, 09:53:20 pm
Here is another datapoint from a ds2072 after hacking it

"DS2202"
DS2a153602xxx
softw 00.01.01.00.02
hw 1.0.1.0.0
spu 03.01.05
wpu 00.06.05
ccu 12.29.00
mc 00.05

stupid of me, I didnt check the hw version before 'upgrading' to DSAZ with rigen v2.0b1. Seeing the other DS2072's reported with HW 2.0 and considering my serial, i think it's weird that mine is reporting HW1.0. I remember reading somewhere that DS2202 will not report the correct HW version, but I cannot find it back again..

Any clues?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 09, 2013, 10:05:24 pm
Any clues?
Don't turn it on, take it apart, as Dave's motto is. Then you can probably see the HW version on the PCB.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on December 09, 2013, 10:26:37 pm
fully official CAN and 300M Bandwidth on DS2000 (non A) ;-))))) *ole*
will post right option codes in a minute ...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 09, 2013, 10:28:59 pm
fully official CAN and 300M Bandwidth on DS2000 (non A) ;-))))) *ole*
will post right option codes in a minute ...

Wow... fast  ;D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 09, 2013, 10:31:01 pm
fully official CAN and 300M Bandwidth on DS2000 (non A) ;-))))) *ole*
will post right option codes in a minute ...
Great work as always, so Christmas came early this year  :-+
Is the 50 ohm option enabled too for those with a non A model with HW ver. 2 with 50 ohm input already populated?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on December 09, 2013, 10:34:15 pm
for FW 00.02.01.00.03 - on a DS2000 (NON A version only !)

Code: [Select]
0x1C080    - DSEA - PROTOCOL ANALYSIS - CAN
0x1C040    - DSCA - BANDWIDTH - 300M Bandwidth (takes a reboot to show up in System Info)
0x1C020    - DSBA - (installs option, but i dont see it ?)
0x1C010    - DSAS - BANDWIDTH - 200M Bandwidth
<known codes still work - see elsewhere>

enable 0x1C0E7 -> all but 100/200M bandwidth-> DSHH

i wonder if 0x1C020 is the 50Ohm option, which my hw probably doesnt support.

UPDATE: despite being DS2302 model, bw limit option is only NONE,20M,100M - somebody better confirm that NONE = 300M ;-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on December 09, 2013, 10:42:09 pm
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.

they use the same curve parameter, but another point on the curve for the DS2000A - i will see if i can find the new point - if not, patch it so it reverts to the known parameters.
a modified gel will also tell if they use signed code now or not ... thanks for finding the obsfuscation - with that info it wasnt too hard.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: nack on December 09, 2013, 10:48:10 pm
Wow cybernet, you keep blowing my mind with your knowledge and firmware modification skills  :clap:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 09, 2013, 10:49:18 pm
So are you loading these codes with 00.01.01.00.02 and then upgrading to 00.02.01.00.03 to utilize them?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on December 09, 2013, 10:50:31 pm
So are you loading these codes with 00.01.01.00.02 and then upgrading to 00.02.01.00.03 to utilize them?

no, i just upgraded to the new fw, and applied them.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 09, 2013, 10:52:09 pm
no, i just upgraded to the new fw, and applied them.

With a diagnostic key or generated key?  Did you find the new point and crack the new algo?  Does the 00.02.01.00.03 firmware detect a Non-A model and accept normal keys?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 09, 2013, 10:54:11 pm
for FW 00.02.01.00.03 - on a DS2000 (NON A version only !)

Code: [Select]
0x1C080    - DSEA - PROTOCOL ANALYSIS - CAN
0x1C040    - DSCA - BANDWIDTH - 300M Bandwidth (takes a reboot to show up in System Info)
0x1C020    - DSBA - (installs option, but i dont see it ?)
0x1C010    - DSAS - BANDWIDTH - 200M Bandwidth
<known codes still work - see elsewhere>

enable 0x1C0E7 -> all but 100/200M bandwidth-> DSHH
Awesome :-+ DSAS also works with older SW versions according to http://riglol.3owl.com (http://riglol.3owl.com)
Quote
DS2000 device options:
first character: D = official, V = trial
DSAB - Advanced Triggers
DSAC - Decoders
DSAE - 56M Memory
DSAJ - 100MHz
DSAS - 200MHz
DSAZ - all options

i wonder if 0x1C020 is the 50Ohm option, which my hw probably doesnt support.
Can't you tell a difference in the menu if the 50 Ohm option is enabled by a key or not, even if th HW doesn't support it in HW 1 doesn't support it?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 09, 2013, 10:58:47 pm
no, i just upgraded to the new fw, and applied them.
With a diagnostic key or generated key?  Did you find the new point and crack the new algo?  Does the 00.02.01.00.03 firmware detect a Non-A model and accept normal keys?
I beleive you can still use this keygen http://riglol.3owl.com (http://riglol.3owl.com) and then just type DSAR DSHH instead of the usual DSAZ to enable all options on the new FW 00.02.01.00.03 for non-A DS2000, including CAN protocol analysis, 300 MHz BW (and maybe 50 ohm input option?).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: iNoxxam on December 10, 2013, 12:02:14 am
Hello,
I have a DS2072 hardware 1 and can't do the update to http://www.filedropper.com/ds2302rilol (http://www.filedropper.com/ds2302rilol) and therefore no CAN.
The update procedures seems to run like it should, and then, when the scope reboots, everything is just like before. The software version did not move from 01.01.00.00.02.
I have a DS2A0000000001 serial, could that be an issue?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 10, 2013, 12:07:46 am
Keeping trying to update.  I had it not work, blink for just a few seconds then go solid on, but stay on the old version.  I kept at it and finally it blinked for 3-4 minutes or so and worked.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 10, 2013, 12:22:16 am
cybernet do you still have the CH1 200M bandwidth limit?  I can get to the 1ns timebase, but no 200M...

The bit in DSBA was accepted by the older firmware too, it would be nice to figure out what it does.  I find it interesting that they stepped around this bit, so there must be some significance to it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 10, 2013, 12:26:30 am
Hello,
I have a DS2072 hardware 1 and can't do the update to http://www.filedropper.com/ds2302rilol (http://www.filedropper.com/ds2302rilol) and therefore no CAN.
The update procedures seems to run like it should, and then, when the scope reboots, everything is just like before. The software version did not move from 01.01.00.00.02.
I have a DS2A0000000001 serial, could that be an issue?
Did you rename the DS2302_RILOL.GEL file to DS2000Update.GEL first? That's the only way you can load it.

But there seems to be no reason to install this custom firmware anymore after Cybernet's latest posts here (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg344845/#msg344845) with new key options for 300 MHz, CAN etc..
Just download the official firmware 00.02.01.00.03 uploaded here (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg342994/?topicseen#msg342994) instead.
Then un-rar DS2000Update.GEL and load it.
After updating apply a key generated with DSAR DSHH to enable all options.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: iNoxxam on December 10, 2013, 12:44:22 am
Thanks,
I finally managed to get all the options by:
- Updating to 02.01 with the official .GEL (several times, to get it working)
- Installing the key generated with DSAR
- Installing the key generated with DSEA (for CAN)
- Installing the key generated with DSCA (for 300MHz)

My S/N is still DS2A0000000001 though. If someone finds out how to fix it I'll be interested into that.

It is now full option thanks to you... Thanks a lot!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 10, 2013, 12:45:01 am
for FW 00.02.01.00.03 - on a DS2000 (NON A version only !)

Code: [Select]
0x1C080    - DSEA - PROTOCOL ANALYSIS - CAN
0x1C040    - DSCA - BANDWIDTH - 300M Bandwidth (takes a reboot to show up in System Info)
0x1C020    - DSBA - (installs option, but i dont see it ?)
0x1C010    - DSAS - BANDWIDTH - 200M Bandwidth
<known codes still work - see elsewhere>

enable 0x1C0E7 -> all but 100/200M bandwidth-> DSHH

i wonder if 0x1C020 is the 50Ohm option, which my hw probably doesnt support.

UPDATE: despite being DS2302 model, bw limit option is only NONE,20M,100M - somebody better confirm that NONE = 300M ;-)
Are LIN and USB protocol analyzers enabled too like mentioned below? Or maybe they aren't actully implemented in the firmware yet, but they have just reserved key options for it?.
Well, the firmware also shows these strings:
CAN
LIN
USB

So, how can somebody enable CAN / LIN / USB protocol analyzer at a DS2072??
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 10, 2013, 12:49:18 am
Thanks,
I finally managed to get all the options by:
- Updating to 02.01 with the official .GEL (several times, to get it working)
- Installing the key generated with DSAR
- Installing the key generated with DSEA (for CAN)
- Installing the key generated with DSCA (for 300MHz)

My S/N is still DS2A0000000001 though. If someone finds out how to fix it I'll be interested into that.

It is now full option thanks to you... Thanks a lot!
cybernet has changed the enable all option from DSAR to DSHH in his post above.
But did you have to apply DSEA and DSCA afterwards too? This shouldn't be necessary if DSAR / DSHH has already enabled all options including 300 MHz and CAN.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: iNoxxam on December 10, 2013, 12:51:03 am
cybernet has changed the enable all option from DSAR to DSHH in his post above.
But did you have to apply DSEA and DSCA afterwards too? This shouldn't be necessary if DSAR / DSHH has already enabled all options including 300 MHz and CAN.

Yup I had to. Else I would "only" have unlocked a 200MHz BW and no CAN analyzer.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 10, 2013, 12:55:50 am
cybernet has changed the enable all option from DSAR to DSHH in his post above.
But did you have to apply DSEA and DSCA afterwards too? This shouldn't be necessary if DSAR / DSHH has already enabled all options including 300 MHz and CAN.

Yup I had to. Else I would "only" have unlocked a 200MHz BW and no CAN analyzer.
Did you check that before installing the last two keys?
That's not what cybernet wrote. So you're saying DSAR to DSHH doesn't install all options anyway, but only does the same as the already known DSAZ?

Btw. have you tested this:
UPDATE: despite being DS2302 model, bw limit option is only NONE,20M,100M - somebody better confirm that NONE = 300M ;-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: iNoxxam on December 10, 2013, 01:09:15 am
cybernet has changed the enable all option from DSAR to DSHH in his post above.
But did you have to apply DSEA and DSCA afterwards too? This shouldn't be necessary if DSAR / DSHH has already enabled all options including 300 MHz and CAN.

Yup I had to. Else I would "only" have unlocked a 200MHz BW and no CAN analyzer.
Did you check that before installing the last two keys?
That's not what cybernet wrote. So you're saying DSAR to DSHH doesn't install all options anyway, but only does the same as the already known DSAZ?

Btw. have you tested this:
UPDATE: despite being DS2302 model, bw limit option is only NONE,20M,100M - somebody better confirm that NONE = 300M ;-)

Yes I checked right after trying the DSAR.
Finally I uninstalled all options  (using SCPI) and tried with DSHH, this one did actually enable everything.
I did not try the BW limit in "NONE" mode, but as soon as I get my hands on a function generator be sure I will.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 10, 2013, 01:24:22 am
It looks like the 00.02.01.00.03 firmware fixes the both channels on in 1ns timebase issue.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: stormbr on December 10, 2013, 02:49:36 am
Works fine with ds2072 (non a) and hardware 2.0.

Model: DS2302
SW: 00.02.01.00.03
HW: 1.0.2.0.2
FPGA: SPU 03.01.09 / WPU 00.07.01 / CCU 12.29.00 / MCU 02.12

Note:
Need uninstall the old key with ultra sigma.
Option: DSHH + rigen 2b1
Protocol analysis CAN: ok
300MHz BW: ok
BW limit: OFF - 20M - 100M

Thanks Cybernet.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 10, 2013, 03:07:31 am
300MHz BW: ok

Did you test or measure this somehow?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: stormbr on December 10, 2013, 03:15:51 am
No tested this bandwith yet, but some peoples here measure easily 300mhz, in future i'll bought a pulse generator too.

And i'm waiting my dsa815tg arrive, can i generate a 300mhz signal with dsa815?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on December 10, 2013, 03:20:19 am
No tested this bandwith yet, but some peoples here measure easily 300mhz, in future i'll bought a pulse generator too.

And i wait my dsa815tg arrive, can i generate a 300mhz signal with dsa815?

Yes, you will be able to generate 300 MHz (or anything else up to 1.5 GHz) in the Zero Span Mode.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigol-Friend on December 10, 2013, 03:24:11 am
No tested this bandwith yet, but some peoples here measure easily 300mhz, in future i'll bought a pulse generator too.

And i'm waiting my dsa815tg arrive, can i generate a 300mhz signal with dsa815?

Sure, up to 1.5 Ghz (Zero Span).  -20 to 0 dBm in 1 dB steps.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: stormbr on December 10, 2013, 03:28:30 am
Thanks for the info, great instrument !
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: staze on December 10, 2013, 04:51:40 am
anyone with HW 2.0 seeing if 50ohm termination is an option for the new firmware and unlocks?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JDubU on December 10, 2013, 05:05:31 am
Works fine with ds2072 (non a) and hardware 2.0.

Model: DS2302
SW: 00.02.01.00.03
HW: 1.0.2.0.2
FPGA: SPU 03.01.09 / WPU 00.07.01 / CCU 12.29.00 / MCU 02.12

Note:
Need uninstall the old key with ultra sigma.
Option: DSHH + rigen 2b1
Protocol analysis CAN: ok
300MHz BW: ok
BW limit: OFF - 20M - 100M

If the bandwidth is 300MHz, shouldn't the BW limit menu options be:   OFF - 20MHz - 100MHz - 200MHz?
Is the bandwidth actually still 200MHZ and not 300MHz?


Never mind...
The DS2000A User's Guide, page 2-3 says:

"Enable bandwidth limit and limit the bandwidth to 20 MHz or 100 MHz (only applicable to 200 MHz and 300 MHz oscilloscopes), the high frequency components that exceed 20 MHz or 100 MHz are attenuated."
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigol-Friend on December 10, 2013, 06:01:12 am
Hi,

please, can anybody give me the SCPI commands for switching the input impedance to 50 ohms and back to 1 Megaohms of the DS2072?
I done it many weeks ago and it worked fine, but now I can't remember these commands.  :(

Many thanks for your help.

Rigol-Friend
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: gaijin on December 10, 2013, 06:19:20 am
Hi,

please, can anybody give me the SCPI commands for switching the input impedance to 50 ohms and back to 1 Megaohms of the DS2072?

:CHAN1:IMP OMEG
:CHAN1:IMP FIFTY
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigol-Friend on December 10, 2013, 06:25:53 am
Gaijin:

THANKS A LOT, very good !       :clap:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on December 10, 2013, 06:37:38 am
Hi,

please, can anybody give me the SCPI commands for switching the input impedance to 50 ohms and back to 1 Megaohms of the DS2072?

:CHAN1:IMP OMEG
:CHAN1:IMP FIFTY

Does it exist an cheatsheet for such commands?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: gaijin on December 10, 2013, 07:20:45 am
There is a programming guide that lists the SCPI commands.
It's in a pdf on the cd that comes with the scope
or it's here:
rigol.com/download/Oversea/DS/Programming_guide/DS2000_ProgrammingGuide_EN.pdf
It doesn't list the option to change the input impedance, the guide made before the ds2000A.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on December 10, 2013, 08:30:20 am
yes, I downloaded the version for 2000A, but it's 648 pages long, an cheatsheet could be an compilation of the most usefull stuff.. ;)
this thread is way to long to find the nifty pieces now, i have tried a couple of times to go through it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: fcab100 on December 10, 2013, 08:51:12 am
No 50Ohm option here with DSHH. It's still gray out.

wonder What 0x1C020 actually does

ds2072 hw 2
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Teneyes on December 10, 2013, 09:26:20 am
@Cybernet   Great Work, 2 cases of Radler for you!   :-+   :-+
Could the CAN decoding feature be in the GEL also??

Yes He CAN!!!
Fricking Amazing Cybernet  Great Work,
3 more cases of Radler for you!   :-+   :-+

Of coarse, Rigol will be offering Cybernet a contract to Encrypt the next Firmware

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Marchello on December 10, 2013, 09:37:10 am
Now i have DS2302! (in his youth he was a DS2072)

Thanks Cybernet!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on December 10, 2013, 09:44:14 am
@Cybernet   Great Work, 2 cases of Radler for you!   :-+   :-+
Could the CAN decoding feature be in the GEL also??

Yes He CAN!!!
Fricking Amazing Cybernet  Great Work,
3 more cases of Radler for you!   :-+   :-+

Of coarse, Rigol will be offering Cybernet a contract to Encrypt the next Firmware

that goes to zombie28 because he noticed the obsfuscation of keys - the rest was just stupid function name mapping from one version to another and following the trails to the option codes.
i already saw the difference between ds2000a and ds2000 - same keys are used, but the inital epoint_set functionn uses (x,x,0,g) instead of (x,y,0,g) as arguments - doesnt make a difference in the rikey.c,
so im not sure whats going on (my math skills again ...  :palm:) - jtag dump from a ds2000a would be useful.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: A Hellene on December 10, 2013, 11:36:09 am
Kudos, people!

This is what team-work can do!
These are the benefits of the 'us' mentality versus the 'I' mentality!
Kudos to every individual who has been involved in this project!
Also, shame to every one of them for temping me to throw some more cash in to that (https://www.eevblog.com/forum?topic=3738) market (which is killing our market)! :P

Let me throw my two cents in, by treating the thread with some food for thought:

There is an Actel ProASIC3 FPGA on board, hardwired to a twenty-slot ten-resistors network. This resistor network probably constitutes some kind of a revision number word, with each resistor pulling up or down a certain data line if the data word is ten-bits long, or leaving that line tri-stated also if the data word is twenty-bits long. This data word is --most probably-- read by the aforementioned FPGA and reported to the main processor.

This might not be easily spotted in the firmware disassembly listings because that data word is not read by the processor's I/O ports directly, but by the FPGA I/Os and reported via some (DMA, most likely) channel data burst, since the specific FPGA in question seems to be some kind of external memory manger accessing the Spansion FLASH boot and data storage memory chip.

Though I have not yet seen what's inside the DS2000 firmware (nor do I own a DS2000 unit in order to investigate it any further) I would consider the possibility of the FW actively reading that hardware jumpers revision word existing on the PCB in order to decide whether it should enable certain functions (like the 50 Ohm one, for example) or not.

If this is true, it could make it possible for the end user to be reverting their hardware on demand between the various revisions (i.e. non-A/A/AS or whatever) by just modifying the PCB revision number word jumpers (by adding in or by removing the jumper-resisrors that correspond to the data word bits).


-George
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cosmos on December 10, 2013, 11:47:29 am

There is an Actel ProASIC3 FPGA on board, hard wired to a twenty-slot ten-resistors network. This resistor network probably constitutes some kind of a revision number word, with each resistor pulling up or down a certain data line if the data word is ten-bits long, or leaving that line tri-stated also if the data word is twenty-bits long. This data word is --most probably-- read by the aforementioned FPGA and reported to the main processor.


In the ds4k these straps are marked, and they correspond to the reported extended revision number.
Changing the straps had no immediate effect on the BW in a ds4k.
It appears that the proASIC is the same or nearly the same s in the ds2k.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on December 10, 2013, 11:51:41 am
No 50Ohm option here with DSHH. It's still gray out.

wonder What 0x1C020 actually does

ds2072 hw 2

If the DS2000A series has the 50 Ohm as standard, it would not make sense to have an option code for that.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on December 10, 2013, 11:53:14 am
i already saw the difference between ds2000a and ds2000 - same keys are used, but the inital epoint_set functionn uses (x,x,0,g) instead of (x,y,0,g) as arguments - doesnt make a difference in the rikey.c,
so im not sure whats going on (my math skills again ...  :palm:) - jtag dump from a ds2000a would be useful.

For a given elliptic curve and a given value of x, there are at most two values of y that match this curve (let's call them y0 and y1). So to define some point on the curve you need to provide either both coordinates (x, y) or a value of x and a single bit (0 or 1) telling which value of y you chose. In the latter case the actual value of y will be computed by epoint_set function (it's called point decompression). When you call epoint_set(x,x,0,g), then you will get g = (x,y0), when you call epoint_set(x,x,1,g), then you will get g = (x,y1), and when you call epoint_set(x,y,0,g), then you will get g = (x,y), but y must be either y0 or y1 to match the curve.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: A Hellene on December 10, 2013, 12:09:52 pm
In the ds4k these straps are marked, and they correspond to the reported extended revision number.
Thank you for the information. Does the DS4k line have any hardware revisions (other than the basic one) with extended functionality, like the DS2kA and DS2kAS for example?

Quote
It appears that the proASIC is the same or nearly the same s in the ds2k.
In the DS1002 line, the corresponding stage is the Lattice MachXO CPLD (https://www.eevblog.com/forum/blog/rigol-ds1052e-nasty-surprise!/msg62495/#msg62495) (which I called a LUT because it is not exactly a CPLD or an FPGA, but something in between).


-George
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Maurizio on December 10, 2013, 12:17:17 pm
thetooth that is the same as the latest non A firmware, so either Rigol gave you the wrong firmware or they are going to use the same firmware for both the A and non A scopes.  Probably they gave you the wrong one though as your scope shows something newer - I wouldn't load it!

Also, it isn't a rar but a zip you've attached.
yeah i gathered, also funnily enough the rigol rep sent me the image as a jpg file with instructions to rename it since he seemed to think it would be eaten.

I sent an email back to ask if they were sure this was for the A version so might see something new after all.

(http://thetooth.name/images/IMG_9646-Edit.jpg)
That sure did take a few attempts, i think the threshold is about 500ms lel

As reference, if it helps, these are the long infos from my brand new ds2102A just arrived last week.
All infos are the same of the picture of Thetooth except of the model name.
Only my 2 cents.

Maurizio
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 10, 2013, 12:19:08 pm
In the ds4k these straps are marked, and they correspond to the reported extended revision number.
Thank you for the information. Does the DS4k line have any hardware revisions (other than the basic one) with extended functionality, like the DS2kA and DS2kAS for example?
There's both a DS4000 and a MSO4000 HW version. MSO4000 is just a DS4000 with buil-in 16-bit logic analyzer.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: A Hellene on December 10, 2013, 12:27:45 pm
There's both a DS4000 and a MSO4000 HW version. MSO4000 is just a DS4000 with buil-in 16-bit logic analyzer.
Thank you. I suppose that both of these lines share the same PCB, since this way cuts the development and production costs dramatically.


-George
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 10, 2013, 12:32:57 pm
There's both a DS4000 and a MSO4000 HW version. MSO4000 is just a DS4000 with buil-in 16-bit logic analyzer.
Thank you. I suppose that both of these lines share the same PCB, since this way cuts the development and production costs dramatically.


-George
Yes I believe it's the same PCB, just with or without the extra LA components being mounted, and maybe a jumper to tell if it's a DS or MSO version.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: A Hellene on December 10, 2013, 12:39:32 pm
This is exactly what my previous thought (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg345115/#msg345115) was based on.


-George
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on December 10, 2013, 12:49:04 pm
hey all :)

I've just started reading this thread from the beginning. You're really great, wow :)
Thanks to everyone who contributed :)

I'm going to order a DS2102A-S later today or tomorrow, and after reading a bit here I just want to be really sure not to do something wrong.
So please tell me, if I order the 100 MHz DSO, will it be possible to unlock it to 300 MHz?
Despite it has the generator inside, it should be possible to find a way to unlock the other features?

That would really help me.
I also pondered just getting a 2102A without the generator and get a stand-alone device later. But since the A-S versions have one built-in (although it's just 25 MHz), it wouldn't take up extra space etc ...
That's why I'm still not sure if I do the right thing ^^;

Thanks!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cosmos on December 10, 2013, 12:51:23 pm
In the ds4k these straps are marked, and they correspond to the reported extended revision number.
Thank you for the information. Does the DS4k line have any hardware revisions (other than the basic one) with extended functionality, like the DS2kA and DS2kAS for example?

Quote
It appears that the proASIC is the same or nearly the same s in the ds2k.
In the DS1002 line, the corresponding stage is the Lattice MachXO CPLD (https://www.eevblog.com/forum/blog/rigol-ds1052e-nasty-surprise!/msg62495/#msg62495) (which I called a LUT because it is not exactly a CPLD or an FPGA, but something in between).


-George

My ds4k have the same strapping as in the picture and the scope reports extended HW version number: 0.1.2.3 (same access to extended info as on a ds2k).
This corresponds to the straps at the top "xx.xx" being 01.10 (1.2) and the strap field below being 011 (.3) .
Not sure if the singel "ch" strap is the first digit (0.), but it would not be surprising.
Makes me wonder if "ch" relates to the number of scope channels.
Someone with a two channel DS4000 might want to report what number they have.

The LA on MSO4000 looks to be plugged into a connector (not mounted in DS4000) next to the lone (display handling?) FPGA near the Blackfin.
There is a cut out in the PCB with mechanical supports for the probe connector on the front.
Presumably there is a LA board in between with some FPGA on it.
 
EDIT. 
Got info from DS4012 owner,  he have HW version number: 1.1.1.3 
so that looks like it confirms that first digit is 4ch/2ch indication. as the "ch" note on the PCB also suggested.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 10, 2013, 12:53:39 pm
I'm going to order a DS2102A-S later today or tomorrow, and after reading a bit here I just want to be really sure not to do something wrong.
So please tell me, if I order the 100 MHz DSO, will it be possible to unlock it to 300 MHz?
No, the A versions has not been hacked yet.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: A Hellene on December 10, 2013, 01:08:18 pm
Not sure if the singel "ch" strap is the first digit (0.), but it would not be surprising.
Makes me wonder if "ch" relates to the number of scope channels.
*grin*

Quote
The LA on MSO4000 looks to be plugged into a connector (not mounted in DS4000) next to the lone (display handling?) FPGA near the Blackfin.
There is a cut out in the PCB with mechanical supports for the probe connector on the front.
Presumably there is a LA board in between with some FPGA on it.
It seems to be the same design strategy to the older DS1002E/DS1002D models line, which share the same exactly PCB that has headers to carry the 'optional' logic analyzer add-on board the D models include. There are two slightly different firmware update versions though, one for the E model and one for the D one, since there are no HW revision selection switches (the populated/unpopulated resistors network) on board.


-George
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on December 10, 2013, 01:14:03 pm
I'm going to order a DS2102A-S later today or tomorrow, and after reading a bit here I just want to be really sure not to do something wrong.
So please tell me, if I order the 100 MHz DSO, will it be possible to unlock it to 300 MHz?
No, the A versions has not been hacked yet.

but according to recent finds, one should think that is matter of minutes if just someone do an jtag dump of an A serie..
I'm definately going for the A(with s), but 100 or 200... that's the question..
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 10, 2013, 03:16:35 pm
Cybernet has done it, again! *ole*  :-+

Now I'm very busy and I can't test anything (check the BW for example).

Anyway. How is the new table?

Quote
Code table: Use DSAx for a official key, and use VSAx for a trial key.

x  200, 100, Mem, Dec, Trig

A   none
B   ==   ==   ==   ==   on
C   ==   ==   ==   on   ==
D   ==   ==   ==   on   on
E   ==   ==   on   ==   ==
F   ==   ==   on   ==   on
G   ==   ==   on   on   ==
H   ==   ==   on   on   on

Note: keys A..H wont change the model, only ADD an option.

2102:

J   ==   on   ==   ==   ==   
K   ==   on   ==   ==   on
L   ==   on   ==   on   ==
M   ==   on   ==   on   on
N   ==   on   on   ==   ==
P   ==   on   on   ==   on
Q   ==   on   on   on   ==
R   ==   on   on   on   on   <-  All 2102

2202:

S   on   ==   ==   ==   ==   
T   on   ==   ==   ==   on
U   on   ==   ==   on   ==
V   on   ==   ==   on   on
W   on   ==   on   ==   ==
X   on   ==   on   ==   on
Y   on   ==   on   on   ==
Z   on   ==   on   on   on   <-  All 2202

DONT USE BELOW Not recommended, as activates 2102 and also 2202:

2   on   on   ==   ==   ==
3   on   on   ==   ==   on
4   on   on   ==   on   ==
5   on   on   ==   on   on
6   on   on   on   ==   ==
7   on   on   on   ==   on
8   on   on   on   on   ==
9   on   on   on   on   on
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 10, 2013, 03:25:45 pm
I guess I'm not following everything here, has a key been generated that works on an A model yet?

Also, does anyone know HOW the keyboard connects to the blackfin, what pins/registers/interface?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 10, 2013, 03:43:32 pm
I guess I'm not following everything here, has a key been generated that works on an A model yet?
Look 4 posts above your own post: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg345144/#msg345144 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg345144/#msg345144)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 10, 2013, 03:46:41 pm
To sum up:

There is no distinction between 'non-A' and 'A' firmware - Rigol has intended for the latest version to work on all models. So feel free to upgrade and downgrade at will - but, because of changes to FRAM, it's best to do it only with the bootloader - and after switching between the major versions (v.1 to v.2 - or - v.2 to v.1), it's best to hold in the left-menu F6 button on the first boot after loading - or the DSO can hang when switching between various menu items.

The new v.2 FW (unlike older versions) was written to work completely correctly with a 300MHz bandwidth (which is why the 1ns/div TB works fine), so you can be assured that if it's activated, it's working correctly - unless there is something the FW does with the LMH6518 chip specifically to inhibit it on non-A models.

The v.2 FW does NOT have a 200MHz bandwidth limit switch for the channels (as evidenced by the DS2000A User Manual) - so it's correct that the option does not appear in the menus.

As AndersAnd mentioned, there has yet to be a key found for the A-model - and as far as I know, no A-model owner has attempted to just downgrade to a v.1 firmware, run the keygen, and then upgrade back to v.2 (not sure why).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: A Hellene on December 10, 2013, 03:54:18 pm
Also, does anyone know HOW the keyboard connects to the blackfin, what pins/registers/interface?
Though I do not suggest that the circuit is the same in both the designs, in DS1002 the LED indicators serial data comes from the Blackfin SPORT0 primary channel while the keypad/encoders serial data are fed into the SPORT0 secondary channel.

Here are (some of) the DS1002 schematics (https://www.eevblog.com/forum/blog/rigol-ds1052e-nasty-surprise!/msg55197/#msg55197), including the Keypad/Indicators PCB.


-George
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: iNoxxam on December 10, 2013, 04:31:14 pm
Maybe some pins are dedicated to coding the model version (A or non-A). In that case, it may be used to make the software act as a non-A version. Should it work, would it not allow to use the keygen? After what, the correct model version could be reset to A and that's it...
I must be wrong somewhere but I can't see where.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on December 10, 2013, 04:36:06 pm
[My ds4k have the same strapping as in the picture and the scope reports extended HW version number: 0.1.2.3 (same access to extended info as on a ds2k).
This corresponds to the straps at the top "xx.xx" being 01.10 (1.2) and the strap field below being 011 (.3) .
Not sure if the singel "ch" strap is the first digit (0.), but it would not be surprising.
Makes me wonder if "ch" relates to the number of scope channels.
Someone with a two channel DS4000 might want to report what number they have.

not sure how to explain properly, but the model type string gen function does have a dedicated variable for channels, mso y/n, bandwidth - i would expect those to be the external inputs.
cant remember right now where those vars where coming from. i guess there is no way to map those to the BGA pins^h^h^h balls ? (xray anyone ?)
 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: A Hellene on December 10, 2013, 04:49:59 pm
Quote
xray anyone?
An X-ray device or a hot-air rework station (https://www.eevblog.com/forum/blog/rigol-ds1052e-nasty-surprise!/msg62495/#msg62495):

(https://www.eevblog.com/forum/index.php?action=dlattach;topic=3738.0;attach=13262;image)


-George
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Dave Turner on December 10, 2013, 05:03:05 pm
A little while ago it was reported that the 500uV range, whilst possible to enable, doesn't in fact work on the DS1000Z series. Has anything further been discovered about this, or has it been decided that it is a hardware limit?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 10, 2013, 05:06:18 pm
A little while ago it was reported that the 500uV range, whilst possible to enable, doesn't in fact work on the DS1000Z series. Has anything further been discovered about this, or has it been decided that it is a hardware limit?

I reported it; when enabled even after doing a cal, it was not usable.  A disconnected channel would jump high or low off the screen.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on December 10, 2013, 05:10:34 pm
but according to recent finds, one should think that is matter of minutes if just someone do an jtag dump of an A serie..
I'm definately going for the A(with s), but 100 or 200... that's the question..

yeah, that's what I hope and the reason I ask :)
there shouldn't be a difference between 100 and 200, right? since it's software-lock
but I also read about unlocking it to 300, but the bw filter menu won't show that setting, it seems

I can help out with jtag data, if someone tells me exactly what to do (so that I won't fry anything or lose warranty, I don't want to lose 3 years, you know ^^)
I never worked with jtag interface before, but AFAIK we have an atmel one flying around at work and I can use that if needed

but at first I have to get the DSO, one of 2 shops says available next year, the other shop writes something about the 16th this month, but I got no reply yet ...


edit: by the way, if (quoting marmad:) "There is no distinction between 'non-A' and 'A' firmware", what about the S-models? Is the key/button, that enables the waveform generator on the S-model, hidden on the non-S-devices? if it is, what happens, if you trigger it by shorting the contact area on the PCB?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 10, 2013, 05:17:14 pm
but I also read about unlocking it to 300, but the bw filter menu won't show that setting, it seems
It's not supposed to. BW limit filters in scopes are low pass filters you can activate to reduce the full BW of the scope. Without BW limit activated, you get the full specified BW of the scope so there should be no 300 MHz option on a 300 MHz model, just like there's no 200 MHz option on a 200 MHz model or a 100 MHz option on a 100 MHz model. You'll only see selected BW options below the scopes full BW.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on December 10, 2013, 05:20:09 pm
@AndersAnd: ahh, thank you, I misunderstood that then :)
so if a 100 MHz DSO is unlocked to 300, 200/100 and 20 should appear?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on December 10, 2013, 05:24:01 pm
but I also read about unlocking it to 300, but the bw filter menu won't show that setting, it seems
It's not supposed to. BW limit filters in scopes are low pass filters you can activate to reduce the full BW of the scope. Without BW limit activated, you get the full specified BW of the scope so there should be no 300 MHz option on a 300 MHz model, just like there's no 200 MHz option on a 200 MHz model or a 100 MHz option on a 100 MHz model. You'll only see selected BW options below the scopes full BW.

Yeah, but I thougt the issue is that if you get an 2072, hack it to be an 2302, do you then get 100 and 200 as options in that list?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 10, 2013, 05:30:30 pm
@AndersAnd: ahh, thank you, I misunderstood that then :)
so if a 100 MHz DSO is unlocked to 300, 200/100 and 20 should appear?
There's no 200 MHz option on either DS2202A or DS2302A. Only 100 MHz and 20 MHz will appear on these.
On both DS2072A and DS2102A only 20 MHz will appear.
Th 200 MHz BW limit will option will appear on non-A models with an old FW modded to DS2302. (A scope model that has never been released, so 200 MHz BW limit has never been an official option).

This has already been mentioned a couple of times recently in this topic:
Works fine with ds2072 (non a) and hardware 2.0.

Model: DS2302
SW: 00.02.01.00.03
HW: 1.0.2.0.2
FPGA: SPU 03.01.09 / WPU 00.07.01 / CCU 12.29.00 / MCU 02.12

Note:
Need uninstall the old key with ultra sigma.
Option: DSHH + rigen 2b1
Protocol analysis CAN: ok
300MHz BW: ok
BW limit: OFF - 20M - 100M

If the bandwidth is 300MHz, shouldn't the BW limit menu options be:   OFF - 20MHz - 100MHz - 200MHz?
Is the bandwidth actually still 200MHZ and not 300MHz?


Never mind...
The DS2000A User's Guide, page 2-3 says:

"Enable bandwidth limit and limit the bandwidth to 20 MHz or 100 MHz (only applicable to 200 MHz and 300 MHz oscilloscopes), the high frequency components that exceed 20 MHz or 100 MHz are attenuated."
The v.2 FW does NOT have a 200MHz bandwidth limit switch for the channels (as evidenced by the DS2000A User Manual) - so it's correct that the option does not appear in the menus.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: flolic on December 10, 2013, 05:33:11 pm
Yeah, but I thougt the issue is that if you get an 2072, hack it to be an 2302, do you then get 100 and 200 as options in that list?

My hacked 2072 (latest firmware and cybernet's latest license codes) has this options: OFF/20M/100M
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Dave Turner on December 10, 2013, 05:39:53 pm
Alank2 - yes it was your post that I recalled. As a matter of note I discovered that the limit appears to be 800uV. It is below that that the trace either bottoms or tops out.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 10, 2013, 05:48:17 pm
This has already been mentioned a couple of times recently in this topic:

Yes, this thread has turned into a beast which is constantly eating it's own tail ;^)

Perhaps an image will put the question to bed:

(https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/?action=dlattach;attach=70331)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 10, 2013, 06:16:18 pm
Any idea why they dropped the 200M bandwidth limit?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JDubU on December 10, 2013, 06:28:56 pm
To sum up:

There is no distinction between 'non-A' and 'A' firmware - Rigol has intended for the latest version to work on all models. So feel free to upgrade and downgrade at will - but, because of changes to FRAM, it's best to do it only with the bootloader - and after switching between the major versions (v.1 to v.2 - or - v.2 to v.1), it's best to hold in the left-menu F6 button on the first boot after loading - or the DSO can hang when switching between various menu items.

The new v.2 FW (unlike older versions) was written to work completely correctly with a 300MHz bandwidth (which is why the 1ns/div TB works fine), so you can be assured that if it's activated, it's working correctly - unless there is something the FW does with the LMH6518 chip specifically to inhibit it on non-A models.

The v.2 FW does NOT have a 200MHz bandwidth limit switch for the channels (as evidenced by the DS2000A User Manual) - so it's correct that the option does not appear in the menus.

As AndersAnd mentioned, there has yet to be a key found for the A-model - and as far as I know, no A-model owner has attempted to just downgrade to a v.1 firmware, run the keygen, and then upgrade back to v.2 (not sure why).

Here is something a bit odd.
I just upgraded the firmware on my DS2072 from 00.01.01.00.02 (was preinstalled on delivery) to 00.02.01.00.03 using the methods recommended by Marmad.

Extended system info:

Before:
Model: DS2072
SW: 00.01.01.00.02
HW: 1.0.2.0.0
FPGA version:
                   SPU  03.01.05
                   WPU  00.06.05
                   CCU  12.29.00
                   MCU  00.05

After:
Model: DS2072
SW: 00.02.01.00.03
HW: 1.0.2.0.1
FPGA version:
                   SPU  03.01.09
                   WPU  00.07.01
                   CCU  12.29.00
                   MCU  00.05


Note the changes in bold.
The HW version incremented and the MCU version did not change to MCU 02.12!

Any ideas why this is different than what others are seeing?

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on December 10, 2013, 06:30:27 pm
Maybe I confused myself with this and the earlier talk about the LMH6518, I thought that one was not beeing changed on the hacked models, or is that something else or ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 10, 2013, 06:38:45 pm
Any idea why they dropped the 200M bandwidth limit?
Well, they didn't really drop it, per se, since it was never actually officially implemented in any firmware release (just an unused feature) - but perhaps they decided not to finally use it because, if serondays BW-limit chart is accurate (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg337698/#msg337698):

the 100MHz limit gives you a -3dB BW of ~130MHz
the 200MHz limit gives you a -3dB BW of ~185MHz

...so only a ~55MHz difference between the settings.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JDubU on December 10, 2013, 06:39:46 pm
Maybe I confused myself with this and the earlier talk about the LMH6518, I thought that one was not beeing changed on the hacked models, or is that something else or ?

The LMH6518 is the input amplifier IC that can receive commands from the firmware to change both input attenuation and bandwidth.  What commands are available to be sent to this chip by the user interface/firmware is the subject of the hacking efforts.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cosmos on December 10, 2013, 06:45:10 pm
Storing serial number etc:
There is the Actel ProASIC flash based FPGA.
The A3P030 (and the rest of the family) have a small (1024 bits) flash based memory area "FlashROM" that can be accessed both from JTAG and userspace.

cut from Actel document: http://www.microsemi.com/document-portal/doc_download/130889-proasic3-fpga-fabric-user-s-guide (http://www.microsemi.com/document-portal/doc_download/130889-proasic3-fpga-fabric-user-s-guide)
************
The  FlashROM  content  can  be  changed  independently  of  the  FPGA  core  content.  It  can  be  easily
accessed and programmed via JTAG, depending on the security settings of the device. The SmartGen
core generator enables each region to be independently updated (described in the "Programming and
Accessing FlashROM" section on page 124). This enables you to change the FlashROM content on a
per-part basis while keeping some regions "constant" for all parts. These features allow the FlashROM to
be used in diverse system applications. Consider the following possible uses of FlashROM:
•    Internet protocol (IP) addressing (wireless or fixed)
•    System calibration settings
•    Restoring configuration after unpredictable system power-down
•    Device serialization and/or inventory control
•    Subscription-based business models (e.g., set-top boxes)
•    Secure key storage
•    Asset management tracking
•    Date stamping
•    Version management
************

The security settings seems to refer to 128b AES encryption ... but the AES part is missing from the low end devices that Rigol uses.

Both ds4k and ds2k have the same proASIC and it is tasked with reading the board version number too...
would not be so strange if they put the serial number and maybe model number too in there?
Just next to it is a JTAG connector (not the same as used for Xilinx or Blackfin) so it will be easy to find for the person that programs the model type and puts the sticker on...

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on December 10, 2013, 08:04:27 pm
Maybe I confused myself with this and the earlier talk about the LMH6518, I thought that one was not beeing changed on the hacked models, or is that something else or ?

The LMH6518 is the input amplifier IC that can receive commands from the firmware to change both input attenuation and bandwidth.  What commands are available to be sent to this chip by the user interface/firmware is the subject of the hacking efforts.

Ok, so this chip behaves, and is controlled exactly same on all models, so one doesnt need to worry about this one to be handled differently through the 2072 - 2302 models?
If so, that makes it easy to chose which model to buy at least..
The price difference between the 2072a-s and 2202a-s is $940 here, and the $358 between the 2072a-s and the 2102a-s..  (in Norway)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on December 10, 2013, 08:05:52 pm
thx cosmos - will see if i find code for it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: thetooth on December 10, 2013, 08:07:32 pm
Just a thought but since theres so much information around and mostly spread across this forum thread i think its time a lot of the facts are consolidated in same way.

Unless someones already done it i can host a wiki on one of my jap based VPS's, has 2TB/month bandwidth thats mostly unused. I'm not in a position to manage it full time though so if you feel like taking it on send a pm with your email or some form of contact and i'll set you up as an admin.

I can also mirror the keygen since its mostly javascript correct? Then eventually setup a firmware archive of sorts...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 10, 2013, 08:38:26 pm
Just a thought but since theres so much information around and mostly spread across this forum thread i think its time a lot of the facts are consolidated in same way.

Unless someones already done it i can host a wiki on one of my jap based VPS's,...
The member "Avotronics" is already working on somthing like this here http://rigol.avotronics.co.uk (http://rigol.avotronics.co.uk)

I can also mirror the keygen since its mostly javascript correct? Then eventually setup a firmware archive of sorts...
Avotronics has already mirrored the http://riglol.3owl.com (http://riglol.3owl.com) keygen here http://rigol.avotronics.co.uk/mirrors/riglol/ (http://rigol.avotronics.co.uk/mirrors/riglol/)
But of course you could always set up another mirror.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 10, 2013, 08:59:34 pm
thx cosmos - will see if i find code for it.

Can somebody with JTAG query this data to see what is there - that might be pretty enlightening.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cosmos on December 10, 2013, 09:10:03 pm
thx cosmos - will see if i find code for it.

Can somebody with JTAG query this data to see what is there - that might be pretty enlightening.

Keep in mind that this will be accessed trough the FPGA fabric, this means it can easily be obfuscated so it might not be a nice contiguous memory area.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: apelly on December 10, 2013, 10:44:21 pm
and as far as I know, no A-model owner has attempted to just downgrade to a v.1 firmware, run the keygen, and then upgrade back to v.2 (not sure why).
Busy with life. Maybe today.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: apelly on December 10, 2013, 11:00:05 pm
Just a thought but since theres so much information around and mostly spread across this forum thread i think its time a lot of the facts are consolidated in same way.

Unless someones already done it i can host a wiki
There is already a wiki at http://www.eevblog.com/wiki/ (http://www.eevblog.com/wiki/)

I'll help if you like.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 10, 2013, 11:01:27 pm
and as far as I know, no A-model owner has attempted to just downgrade to a v.1 firmware, run the keygen, and then upgrade back to v.2 (not sure why).
Busy with life. Maybe today.
Ordered a bus blaster tonight. Will be here in a week or so. Plan is to extract the 2072A firmware.
Have you received your Dangerous Prototypes Bus Blaster (http://dangerousprototypes.com/category/bus-blaster/) yet? Maybe it would be best to do a JTAG memory dump on your DS2000A scope before modding it?
Noone has posted a JTAG memory dump from DS2000A yet.

Which Bus Blaster version did you order, v3 or v4?
Bus Blaster v3 http://www.seeedstudio.com/depot/bus-blaster-v3-p-1415.html (http://www.seeedstudio.com/depot/bus-blaster-v3-p-1415.html)
Bus Blaster v4 http://www.seeedstudio.com/depot/bus-blaster-v4-p-1416.html (http://www.seeedstudio.com/depot/bus-blaster-v4-p-1416.html)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 10, 2013, 11:10:49 pm
Noone has posted a JTAG memory dump from DS2000A yet.

Is there a JTAG memory dump from the DS2000 somewhere?  Where?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 10, 2013, 11:27:08 pm
Dave's teardown talks about a Lattice Mach IO PLD - any idea what would be the likely way the Blackfin would communicate with this?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 10, 2013, 11:41:48 pm
Noone has posted a JTAG memory dump from DS2000A yet.
Is there a JTAG memory dump from the DS2000 somewhere?  Where?
I think cybernet has done a JTAG dump: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg241335/#msg241335 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg241335/#msg241335)
But I'm not sure he has uploaded it, but you could try to ask him for it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: apelly on December 10, 2013, 11:52:06 pm
Have you received your Dangerous Prototypes Bus Blaster (http://dangerousprototypes.com/category/bus-blaster/) yet? Maybe it would be best to do a JTAG memory dump on your DS2000A scope before modding it?
Noone has posted a JTAG memory dump from DS2000A yet.
Hasn't arrived yet. Did get a shipping note a few days ago. Will check the post box this afternoon.

You raise a good point. I will get what I can with JTAG before I dick around with the firmware.

Which Bus Blaster version did you order, v3 or v4?
Bus Blaster v3 http://www.seeedstudio.com/depot/bus-blaster-v3-p-1415.html (http://www.seeedstudio.com/depot/bus-blaster-v3-p-1415.html)
Bus Blaster v4 http://www.seeedstudio.com/depot/bus-blaster-v4-p-1416.html (http://www.seeedstudio.com/depot/bus-blaster-v4-p-1416.html)
v4

Carrington has given me his notes and data for emulating a JTAGkey, but that might still take a while to set up.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on December 10, 2013, 11:59:05 pm
Dave's teardown talks about a Lattice Mach IO PLD - any idea what would be the likely way the Blackfin would communicate with this?

via SPORT
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 11, 2013, 12:04:31 am
via SPORT

I've decoded the LDR streams and then loaded them into IDA.  I can see about a dozen subs that contain SPORT registers, but no SPORT0_RX or SPORT1_RX...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on December 11, 2013, 12:54:28 am
study the bfin manual with regards to DMA ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cosmos on December 11, 2013, 01:05:45 am
Dave's teardown talks about a Lattice Mach IO PLD - any idea what would be the likely way the Blackfin would communicate with this?

Maybe I am blind but I don't see any candidates for a Lattice PLD (except maybe the small clock generation device next to the ADC and sample FPGA).
When in the teardown was this? and was he talking about the DS2k?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on December 11, 2013, 01:06:34 am
Dave's teardown talks about a Lattice Mach IO PLD - any idea what would be the likely way the Blackfin would communicate with this?

Maybe I am blind but I don't see any candidates for a Lattice PLD (except maybe the small clock generation device next to the ADC and sample FPGA).
When in the teardown was this? and was he talking about the DS2k?

keyboard/leds on the frontpanel
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cosmos on December 11, 2013, 01:11:36 am
Dave's teardown talks about a Lattice Mach IO PLD - any idea what would be the likely way the Blackfin would communicate with this?

Maybe I am blind but I don't see any candidates for a Lattice PLD (except maybe the small clock generation device next to the ADC and sample FPGA).
When in the teardown was this? and was he talking about the DS2k?

keyboard/leds on the frontpanel


Duh... That makes sense yes.
Not so interested in that I guess, must have been absent minded watching that part.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 11, 2013, 01:59:54 am
Is this correct?
IMHO would be interesting know the entire table, and thus activate the desired options with a single key.

Code: [Select]
Code table: Use DSYX for a official key, and use VSYX for a trial key.

Y  CAN, 300, 50ohm

A   none
B   ==   ==   on
C   ==   on   ==
D   ??   ??   ??
E   on   ==   ==
F   ??   ??   ??
G   ??   ??   ??
H   on   on   on
J   ??   ??   ??
K   ??   ??   ??
L   ??   ??   ??
M   ??   ??   ??
N   ??   ??   ??
P   ??   ??   ??
Q   ??   ??   ??
R   ??   ??   ??
S   ??   ??   ??
T   ??   ??   ??
U   ??   ??   ??
V   ??   ??   ??
W   ??   ??   ??
X   ??   ??   ??
Y   ??   ??   ??
Z   ??   ??   ??
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: fcab100 on December 11, 2013, 09:12:07 am
DSA9 through DSH9
=====================================================
D S * 9    AT   DC  CAN  MD  100  200  300   unknown

      A       ON  ON    =    ON   ON   ON    =        =

      B       ON  ON    =    ON   ON   ON    =        *

      C       ON  ON    =    ON   ON   ON   ON       =
     
      D       ON  ON    =    ON   ON   ON   ON       *
                           
      E       ON  ON   ON   ON    ON   ON   =        =

      F       ON  ON   ON   ON    ON   ON   =        *

      G       ON  ON   ON   ON    ON   ON  ON      =

      H       ON  ON   ON   ON    ON   ON   ON     *


--------------------------------------------------------------------------------------------------
I have not found what * dose yet.
The "*" unknown option dose not turn on 50ohm for my DS2072 HW 2. 
-------------------------------------------------------------------------------------
Also tried DSI9 through DSZ9. Got license unavailability.  I'm guessing its not a good idea to use DS*9 option same as before.
-----------------------------------------------------------------------------------------------------------
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: eV1Te on December 11, 2013, 12:35:16 pm
New firmware is out for DS1000Z, version 00.02.01.SP1

It has quite a lot of bug fixes and seems to have faster GUI as well.  :-+

Now its possible to export the full memory of points as wfm files, but I have not found any software that supports these files, either to open or convert them... Does Rigol have any software for this?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 11, 2013, 01:22:56 pm
New firmware is out for DS1000Z, version 00.02.01.SP1
Nice, can you please share the file?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 11, 2013, 02:58:34 pm
@fcab100 I believe that you are mixing tables. X variable was defined in the nex table, so DSY9 enable (200, 100, Men, Dec and Trig).
The table to which I refer is only for Y. If I'm not mistaken Y variable directly affects only to the new features.

Cheers.  :)

Code: [Select]
Code table: Use DSYX for a official key, and use VSYX for a trial key.

X  200, 100, Mem, Dec, Trig

A   none
B   ==   ==   ==   ==   on
C   ==   ==   ==   on   ==
D   ==   ==   ==   on   on
E   ==   ==   on   ==   ==
F   ==   ==   on   ==   on
G   ==   ==   on   on   ==
H   ==   ==   on   on   on

Note: keys A..H wont change the model, only ADD an option.

2102:

J   ==   on   ==   ==   ==   
K   ==   on   ==   ==   on
L   ==   on   ==   on   ==
M   ==   on   ==   on   on
N   ==   on   on   ==   ==
P   ==   on   on   ==   on
Q   ==   on   on   on   ==
R   ==   on   on   on   on   <-  All 2102

2202:

S   on   ==   ==   ==   ==   
T   on   ==   ==   ==   on
U   on   ==   ==   on   ==
V   on   ==   ==   on   on
W   on   ==   on   ==   ==
X   on   ==   on   ==   on
Y   on   ==   on   on   ==
Z   on   ==   on   on   on   <-  All 2202

DONT USE BELOW Not recommended, as activates 2102 and also 2202:

2   on   on   ==   ==   ==
3   on   on   ==   ==   on
4   on   on   ==   on   ==
5   on   on   ==   on   on
6   on   on   on   ==   ==
7   on   on   on   ==   on
8   on   on   on   on   ==
9   on   on   on   on   on
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Git on December 11, 2013, 03:18:25 pm
New firmware is out for DS1000Z, version 00.02.01.SP1

Has the key and/or serial number format changed?

Git
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on December 11, 2013, 03:46:40 pm
does the shop where you bought the DSO send you the updates?

I wonder if the waveform gen in the S version is limited, too
I found little to no information about this new DSO yet ...
and it seems I have to wait until January until I can obtain one :/


btw, just want to say this: I really repect what you people did here ... I wish I would know how cybernet (for example) did all this reverse engineering stuff ... wow :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 11, 2013, 03:53:45 pm
I wonder if the waveform gen in the S version is limited, too
No.

Quote
I found little to no information about this new DSO yet ...
I'm not sure exactly which DSO you mean, but Rigol has published fairly detailed datasheets for both the DS2000A-S series (http://www.rigol.com/download/Oversea/DS/Datasheet/DS2000A_DataSheet_EN.pdf), as well as the DS1000Z-S series (http://www.rigol.com/download/Oversea/DS/Datasheet/DS1000Z_DataSheet_EN.pdf).

Just look for the specs of the waveform generator down near the bottom in the "Signal Source (DSXXXXX-S)" section.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: eV1Te on December 11, 2013, 03:54:24 pm
New firmware is out for DS1000Z, version 00.02.01.SP1
Nice, can you please share the file?

Here is the new firmware for the DS1000Z and DS1000Z-S

Version 00.02.01.SP1

Too large to attach as a single file, so here is link to my FTP:
ftp://eevblog:555@ev1te.myftp.org/DS1000Z(ARM)update00.02.01.rar
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on December 11, 2013, 08:33:45 pm
DS2000/DS2302 with updated  FW 02.01.00.03 falls back to DS2202:

My DS2072 with upgrade DS2302 falls back to DS2202 with max TB of 2 ns when I update FW from 01.01.00.02it to FW 02.01.00.03 per ’cybernet' using the Boot Method (Power ON + Help) as he recommends and describes for updating to this FW.  BTW the S/N is still the original.

Would uninstalling the Options with Ultra Sigma and then reinstalling them with the Keygen possibly help while in this state. (FW 02.01.00.03 and reporting DS2202/2ns max TB)?  This question is a shot in the dark because I'm at wits end.  I must be missing something simple here.

When I reinstall back to FW 01.01.00.02 it reports that it is a DS2301 and the maximum TB is 1 ns as it was originally. Again using the Boot Method (ON + Help).  This even seems strange that it would revert back to DS2303 fully where it was originally.  And the S/N is still the original.

Has anyone else experienced this, or have any idea what I may be doing wrong, or could do differently straighten this out?

History: I originally upgraded my DS0072 with FW 01.01.00.02 to 100 MHz BW, then to 200 MHz (DS2202), and lastly to 300 MHz (DS2302) and it has been working fine.  Now of course I just want to install the latest Firmware 02.01.00.03.  As stated above it goes to this FW OK, but reports being DS2202 with the maximum TB of 2 ns (as is normal for DS2202).

Thank you for any assistance, Ted
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 11, 2013, 08:40:13 pm
DS2000/DS2302 with updated  FW 02.01.00.03 falls back to DS2202:

My DS2072 with upgrade DS2302 falls back to DS2202 with max TB of 2 ns when I update FW from 01.01.00.02it to FW 02.01.00.03 per ’cybernet' using the Boot Method (Power ON + Help) as he recommends and describes for updating to this FW.  BTW the S/N is still the original.

Would uninstalling the Options with Ultra Sigma and then reinstalling them with the Keygen possibly help while in this state. (FW 02.01.00.03 and reporting DS2202/2ns max TB)?  This question is a shot in the dark because I'm at wits end.  I must be missing something simple here.

When I reinstall back to FW 01.01.00.02 it reports that it is a DS2301 and the maximum TB is 1 ns as it was originally. Again using the Boot Method (ON + Help).  This even seems strange that it would revert back to DS2303 fully where it was originally.  And the S/N is still the original.

Has anyone else experienced this, or have any idea what I may be doing wrong, or could do differently straighten this out?

History: I originally upgraded my DS0072 with FW 01.01.00.02 to 100 MHz BW, then to 200 MHz (DS2202), and lastly to 300 MHz (DS2302) and it has been working fine.  Now of course I just want to install the latest Firmware 02.01.00.03.  As stated above it goes to this FW OK, but reports being DS2202 with the maximum TB of 2 ns (as is normal for DS2202).

Thank you for any assistance, Ted

There's no reason for using cybernet's modified FW to achieve 300MHz bandwidth anymore - it's a purchasable and installable option in the newest firmware (as is the CAN trigger/decode). Just look back through the last couple of pages for the keys needed to install either or both options in v.2 firmware.

Here is cybernet's original post with the codes. (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg344845/#msg344845)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 11, 2013, 08:41:52 pm
Ted, you need to use DSHH when generating an all options enabled key for the new firmware instead of DSAZ used on older firmwares.
So before upgrading to the new firmware I would uninstall all keys, then upgade to the new firmware and generate a new key using DSHH.
Don't use any custom firmware to get 300 MHz anymore, you can get that with DSHH.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jonese on December 11, 2013, 09:55:43 pm
There's more going on here they we currently understand (no doubt, to be expected).

I have a real 2102 that I keygen'd to a 2202 many months ago.  Today I uninstalled the options (several times actually) and power cycled and my machine then was a 2072 (remember this is a real 2102).  I then upgraded the firmware to the latest (and also did the FRAM clear on bootup).  The unit then identifies itself as a 2202.  I also uninstalled the options again, but it continued to be a 2202.  Under the options page, there is a 200 bandwidth trial timer-count down.

In the last step, I used the keygen with DSHH and it's reporting as a 2302.  Trial options page still lists the bandwith 200 option has being present, but with a timer-count down (everything else was official).  Also my serial number continues to be proper.

There is something lingering in the options storage that the standard methods are not removing.  I'm also guessing my unit has lost it's 2102 factory identity and is reverting to 2072 in the earlier firmware when I remove the options.

Perhaps there was something permanent done to the machine several months ago with the VSAx (temporary keys) loading?

Not complaining, just noting what I saw.  It's happily pretending to be a 2302.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on December 11, 2013, 09:58:52 pm
this is likely due to rigol changing the addresses & meaning of their NVRAM/FRAM storage between releases + some chinese quality coding
i guess the killer here was that u had a DS2102 and installed a 100M option (which in reality was unneeded) by uninstalling that it fell down to a DS2072.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on December 11, 2013, 10:51:26 pm
[quote from marmad « Reply #1936 on: Today at 07:40:13 AM »

    from: ted572 on Today at 07:33:45 AM    DS2000/DS2302 with updated  FW 02.01.00.03 falls back to DS2202:

        My DS2072 with upgrade DS2302 falls back to DS2202 with max TB of 2 ns when I update FW from 01.01.00.02it to FW 02.01.00.03 per ’cybernet' using the Boot Method (Power ON + Help) as he recommends and describes for updating to this FW.  BTW the S/N is still the original. . . . . . . . . .     

from marmad:  There's no reason for using cybernet's modified FW to achieve 300MHz bandwidth anymore - it's a purchasable and installable option in the newest firmware (as is the CAN trigger/decode). Just look back through the last couple of pages for the keys needed to install either or both options in v.2 firmware.
----------------------------------------------------------------------------------------------------------------------------------------------------------
and

 [Quote from AndersAnd « Reply #1937 on: Today at 07:41:52 AM »
 
Ted, you need to use DSHH when generating an all options enabled key for the new firmware instead of DSAZ used on older firmwares.
So before upgrading to the new firmware I would uninstall all keys, then upgade to the new firmware and generate a new key using DSHH.
Don't use any custom firmware to get 300 MHz anymore, you can get that with DSHH.
-----------------------------------------------------------------------------------------------------------------------------------------

Fantastic !   Thank you both so much.  I don't know how I missed all of this, as I thought that I read everything here.  I didn't have a clue about this.  And it was so easy.  Thanks again, Ted
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: creyc on December 12, 2013, 04:14:06 am

I notice the 500µV option for DS1000z has a different 3rd letter than the other options too.
Is this a mistake too or is it supposed to be this way?
Can't recall if there's a code table for DS1000z earlier in this topic similar to the on above for DS4000? I think I've missed it if there is.

Quote
DS1000z device options:
DSAB - Advanced Triggers
DSAC - Decoders
DSAE - 24M Memory
DSAJ - Recorder
DSBA - 500uV Vertical

Speaking of this 500µV option for the DS1000Z, it doesn't show up in the installed options menu before or after entering.  Additionally, is there a code to remove this option?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: m-joy on December 12, 2013, 08:47:36 am
Hello,
i just bought the DS2072 with 70Mhz. Now i want to have all the cool stuff including maximum bandwidth.
I downloaded the Rigon KeyGen v2.0b1.
I am always reading of an DSHH option, but my keygen has only DSAH  DSAR and DSAZ.
So whats the best way to get this working? Can i easy remove this stuff wo waranty?

Greetings
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 12, 2013, 08:50:19 am
Hello,
i just bought the DS2072 with 70Mhz. Now i want to have all the cool stuff including maximum bandwidth.
I downloaded the Rigon KeyGen v2.0b1.
I am always reading of an DSHH option, but my keygen has only DSAH  DSAR and DSAZ.
So whats the best way to get this working? Can i easy remove this stuff wo waranty?

Greetings
Use this keygen http://riglol.3owl.com (http://riglol.3owl.com) and just type DSHH even though it's not listed as an option. Leave the Privatekey box empty, it will fill out this itself.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: m-joy on December 12, 2013, 08:57:13 am
Hello,
i just bought the DS2072 with 70Mhz. Now i want to have all the cool stuff including maximum bandwidth.
I downloaded the Rigon KeyGen v2.0b1.
I am always reading of an DSHH option, but my keygen has only DSAH  DSAR and DSAZ.
So whats the best way to get this working? Can i easy remove this stuff wo waranty?

Greetings
Use this keygen http://riglol.3owl.com (http://riglol.3owl.com) and just type DSHH even though it's not listed as an option. Leave the Privatekey box empty, it will fill out this itself.

Great!
Going to try that ;) so do i get 300Mhz or 200Mhz? I am a lil bit confused right now ;)
Will that work on the latest firmware? Should i update to further FW in the future?

Greets
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: seronday on December 12, 2013, 01:36:11 pm
Anyone who wants to change their new DS1074Z into a DS1104Z use the following Codes:-

DSHA  makes a  DS1104Z with no options enabled .
DSHR  makes a  DS1104Z with all options enabled .

The 3dB bandwidth for the DS1104Z is approx 160Mhz.
The 3dB bandwidth for the DS1074Z is approx 90Mhz.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: creyc on December 12, 2013, 04:35:51 pm
Anyone who wants to change their new DS1074Z into a DS1104Z use the following Codes:-

DSHA  makes a  DS1104Z with no options enabled .
DSHR  makes a  DS1104Z with all options enabled .

The 3dB bandwidth for the DS1104Z is approx 160Mhz.
The 3dB bandwidth for the DS1074Z is approx 90Mhz.

Anyone tested this yet, or am I the guinea pig tonight?  :-/O

Also, new firmware was released for the DS1000Z scopes a few days ago, any compatibility issues?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 12, 2013, 05:26:04 pm
Going to try that ;) so do i get 300Mhz or 200Mhz? I am a lil bit confused right now ;)
DSHH: 300 MHz an all options according to cybernet. But I don' t think anyone has actually verified if it's 300 MHz BW with DSHH yet.

Will that work on the latest firmware?
DSHH will only work with the latest released DS2000 FW from what I understand. The same with the CAN protocol analyzer option.


Should i update to further FW in the future?
:-// You can try... or ask your crystal ball, nobody else outside Rigol will know anything about their future releases.

Anyone who wants to change their new DS1074Z into a DS1104Z use the following Codes:-

DSHA  makes a  DS1104Z with no options enabled .
DSHR  makes a  DS1104Z with all options enabled .

The 3dB bandwidth for the DS1104Z is approx 160Mhz.
The 3dB bandwidth for the DS1074Z is approx 90Mhz.
Great  :-+ I can see studio25 has now updated the lists at http://riglol.3owl.com (http://riglol.3owl.com) to include the device option codes for DS1000Z an DS2000.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: eV1Te on December 12, 2013, 06:06:30 pm
Anyone who wants to change their new DS1074Z into a DS1104Z use the following Codes:-

DSHA  makes a  DS1104Z with no options enabled .
DSHR  makes a  DS1104Z with all options enabled .

The 3dB bandwidth for the DS1104Z is approx 160Mhz.
The 3dB bandwidth for the DS1074Z is approx 90Mhz.

Anyone tested this yet, or am I the guinea pig tonight?  :-/O

Also, new firmware was released for the DS1000Z scopes a few days ago, any compatibility issues?

I will try it later tonight as well, just need to hack something together that generates a fast rising edges first, to test the 100 MHz with  :)

Edit: It works!
But could hardly see any difference on the rising edge time even though it says DS1104Z-S in the system information. But the fastest edge I had at home was a simple 74HC14 Schmitt trigger that were around 4 ns so that is definitely the limitation and not the scope.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on December 12, 2013, 06:14:11 pm
btw, just out of curiosity: several pages ago I read something like "soon we'll have our own ..." ... was that about an own/altered/open source firmware?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: eltar on December 12, 2013, 06:18:57 pm
I will try it later tonight as well, just need to hack something together that generates a fast rising edges first, to test the 100 MHz with  :)

I can try it too. Is latest DS1000Z firmware 00.02.01.SP1 requested for unlocking 100MHz?
Do we have some info or change list for this firmware? Thanks :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on December 12, 2013, 06:30:58 pm
btw, just out of curiosity: several pages ago I read something like "soon we'll have our own ..." ... was that about an own/altered/open source firmware?

the altered part we have (for DS2k/DS4k) - the own ... yeah maybe if somebody shoves the FPGA through an xray machine ;)
or somebody donates a broken one so i can rip it off. without FPGA traced out, its a bit hard to do.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on December 12, 2013, 06:42:26 pm
hehe ok ok
like someone stated, it's really hard for a noob to read through this thread and sort all the infos :D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: seronday on December 13, 2013, 12:11:50 am
Anyone who wants to change their new DS1074Z into a DS1104Z use the following Codes:-

DSHA  makes a  DS1104Z with no options enabled .
DSHR  makes a  DS1104Z with all options enabled .

The 3dB bandwidth for the DS1104Z is approx 160Mhz.
The 3dB bandwidth for the DS1074Z is approx 90Mhz.



Minor correction to my previous post after some further investigation.

DSHA also enables the 500uV setting and another unknown, (at present), option.

DSEA is the correct code to change to a DS1104Z only. ( no options ). See table below.

 Code      DS1104z    Unknown     500uV setting
DSBA                                               X
DSCA                            X
DSDA                            X                 X
DSEA           X
DSFA           X                                  X
DSGA           X               X
DSHA           X               X                 X

So to change a DS1074Z into a DS1104Z with all options enabled except the 500uV/div (which does not work correctly at present),
the code  will be DSER.

It is possible to revert back to original, by using the SCPI command " :SYSTem:OPTion:UNINSTall " .

As mentioned in my previous post, the measured 3dB down bandwidth after changing to a DS1104Z, is approx 160Mhz.
All the tests were done on a DS1074Z with Ver:00.02.00.SP1.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: eV1Te on December 13, 2013, 01:13:14 am
Nice work with the reverse engineering of the options on the DS1000Z.  :-+

I enabled DSHR today and also noticed that the 500 uV mode is offset outside the screen (but fully functional i I move the trace back into view again). Byt my CH2 happens to have less than 1 div of offset. My guess is that the built in self.cal. does not adjust the 500 uV mode at all. So whatever settings are set by default in the firmware gets loaded, and it's just a matter of luck if that happens to be good or not.

Maybe it would be possible to access the self.cal. variables in memory somewhere and change the 500 uV offset values manually.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sync on December 13, 2013, 01:47:00 am
The DSHA option works on my DS1074Z. It's now a DS1104Z. Thanks! :-+ Unfortunately I don't have a real signal generator. Thus I can't measure the bandwidth. But it has a faster rise time now.

I had the 500uV option installed before. Yes, there is a DC offset which is not adjusted by self-cal.

Edit: I have measurement history now. ;D And i think the region (gated) measuring mode is also new. They are in the 2nd page of the measure menu. Is that the unknown option?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gallymimus on December 13, 2013, 03:42:43 am

Also, new firmware was released for the DS1000Z scopes a few days ago, any compatibility issues?

It works fine, and fixes a lot of bugs.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: creyc on December 13, 2013, 04:52:15 am

Also, new firmware was released for the DS1000Z scopes a few days ago, any compatibility issues?

It works fine, and fixes a lot of bugs.

Thanks, it seems to be working well here, too. :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: skrap on December 13, 2013, 04:55:38 am
The DSHA option works on my DS1074Z. It's now a DS1104Z. Thanks! :-+ Unfortunately I don't have a real signal generator. Thus I can't measure the bandwidth. But it has a faster rise time now.

I had the 500uV option installed before. Yes, there is a DC offset which is not adjusted by self-cal.

Edit: I have measurement history now. ;D And i think the region (gated) measuring mode is also new. They are in the 2nd page of the measure menu. Is that the unknown option?

The features discovered by Sync seems to be available only in the new firmware (00.02.01 SP1).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Marc M. on December 13, 2013, 07:23:23 am
Has anyone had any luck with downgrading the firmware on a 2072 (1.0 H/W) from 00.02.01.00.03 back to 01.01.00.02?  When I plug a flash drive in with the older firmware it doesn't detect it, but it does if I put .03 on the drive via the Boot & Help method.  When I uninstall all the options, my model under system still shows DS2202 not 2072 :(.  This wasn't an issue with the .02 version which allowed downgrading.  It seems Rigol have prevented doing so in the .03 update.
 
Success!  Thanks Marmad for confirming it should work.  For some reason it didn't like the SD card I was using.  It's the same card I've been using with the scope for both firmware and screen shots since I purchased it.  I used a different card and had no problems with the downgrade  :-//.  However, the scope was still showing a 2202 model number even after downgrading and clearing the FRAM (I had all options uninstalled at the time of the downgrade).  I reinstalled the options then uninstalled them via SCPI, power cycled the scope and the model finally reverted back to 2072.  Now I won't have to worry when I send it in for warranty repairs.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: m-joy on December 13, 2013, 08:13:48 am
Huhu, where can i download the latest firmware for my DS2072?

Greets
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Marc M. on December 13, 2013, 08:44:59 am
...where can i download the latest firmware for my DS2072?
It may have been posted somewhere earlier in the thread but this is where I downloaded it from.  See post# 1842.
...Just download the official firmware 00.02.01.00.03 uploaded here (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg342994/?topicseen#msg342994) instead.
Then un-rar DS2000Update.GEL and load it.
After updating apply a key generated with DSAR DSHH to enable all options.
Be aware that so far I haven't been able to downgrade back to .02 from this version.  Refer to my post above regarding the issue.

Success!  Updated the post.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 13, 2013, 09:40:54 am
Be aware that so far I haven't been able to downgrade back to .02 from this version.  Refer to my post above regarding the issue.

As mentioned a few times earlier in this thread (and at the DS2000 Review thread), I (and others) have upgraded and downgraded between the versions several times - always by bootloading, and always taking care to clear the FRAM when next booting.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Tasman on December 13, 2013, 09:42:30 am
Do I need to uninstall my previously applied options before upgrading to the new firmware and applying the DSHH generated key?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 13, 2013, 09:59:33 am
Do I need to uninstall my previously applied options before upgrading to the new firmware and applying the DSHH generated key?
I didn't, although I have an official key for the normal options; I just used cybernets DSEA for CAN decode. (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg344845/#msg344845https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg344845/#msg344845)
So I don't think it's necessary to uninstall and reinstall all (since I don't think the FW can distinguish between official and "non-official" key codes) unless you want to do it that way.

But, more importantly: Rigol has changed the the structure of unit settings stored in FRAM, so if you upgrade/downgrade between the major versions (v.01.XX.XX.XX to v.02.XX.XX.XX - or vice-versa), it's highly recommended to hold in the left-menu F6 button (sixth gray button down on left side of LCD) during the first reboot after loading (to clear FRAM) - otherwise the DSO will hang (often) when switching between various menu items.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: m-joy on December 13, 2013, 10:10:35 am
Quote
Be aware that so far I haven't been able to downgrade back to .02 from this version.  Refer to my post above regarding the issue.

why would i downgrade....? Is 02 better than .03 ? In this case i could directly update to 02 and not to 03....?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Tasman on December 13, 2013, 10:22:53 am
But, more importantly: Rigol has changed the the structure of unit settings stored in FRAM, so if you upgrade/downgrade between the major versions (v.01.XX.XX.XX to v.02.XX.XX.XX - or vice-versa), it's highly recommended to hold in the left-menu F6 button (sixth gray button down on left side of LCD) during the first reboot after loading (to clear FRAM) - otherwise the DSO will hang (often) when switching between various menu items.

Many thanks Marmad; I was wondering about that after seeing it in an earlier post, but didn't get around to investigating further.  You have no doubt saved me from a lot of frustration.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: fcab100 on December 13, 2013, 11:14:08 am
I was messing with the jumpers on my ds2072 hw2 look what i got. Its late need sleep  :=\

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: eV1Te on December 13, 2013, 11:24:24 am
I was messing with the jumpers on my ds2072 hw2 look what i got. Its late need sleep  :=\

Nice find!  :-+
To bad you don't have the hardware for the signal gen though.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on December 13, 2013, 11:39:05 am
To bad you don't have the hardware for the signal gen though.

I wonder what it takes, we really need someone with the S model to have a look  :-/O
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Maalobs on December 13, 2013, 12:00:05 pm
Do I need to uninstall my previously applied options before upgrading to the new firmware and applying the DSHH generated key?
I didn't, although I have an official key for the normal options; I just used cybernets DSEA for CAN decode. (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg344845/#msg344845)
So I don't think it's necessary to uninstall and reinstall all (since I don't think the FW can distinguish between official and "non-official" key codes) unless you want to do it that way.

But, more importantly: Rigol has changed the the structure of unit settings stored in FRAM, so if you upgrade/downgrade between the major versions (v.01.XX.XX.XX to v.02.XX.XX.XX - or vice-versa), it's highly recommended to hold in the left-menu F6 button (sixth gray button down on left side of LCD) during the first reboot after loading (to clear FRAM) - otherwise the DSO will hang (often) when switching between various menu items.
Thanks for the very clear summary.  :-+
Didn't you add the 300M option, though?
Why not, in that case?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: creyc on December 13, 2013, 12:27:45 pm
To bad you don't have the hardware for the signal gen though.

I wonder what it takes, we really need someone with the S model to have a look  :-/O

I've got a DS1074Z-S..
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on December 13, 2013, 03:43:11 pm
I wonder why you want to got back to the original state for RMA ...

what I mean is, what if the PSU has a problem, you can't switch it on then
or something similar, as in loose cooler clips that might shor-circuit something ...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 13, 2013, 04:18:53 pm
Thanks for the very clear summary.  :-+
Didn't you add the 300M option, though?
Why not, in that case?

Happy to help. I haven't installed the 300MHz option yet because:

1) I don't really need the extra bandwidth at this time - although maybe later, in which case I would try it.
2) I'm not 100% sure that HW v.1 fully supports it. Remember, Rigol didn't start offering a 300MHz model until they had developed HW v.2. OTOH, the CAN option is all software.
3) Remember, it's a 2GSa/s scope. The DSO only does sin(x)/x interpolation at 1G & 2GSa/s - everything below that (<= 500MSa/s) uses linear interpolation - which really requires a sample rate >= 8x the highest frequency for a decent reconstruction. SO throwing 300MHz at the DSO, especially at slower sample rates is pushing the envelope. In actual fact, for best reconstruction (and lowest noise), you really should keep the 100MHz bandwidth filter on if you're fairly certain you don't have higher frequencies.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jkw13 on December 13, 2013, 04:34:11 pm
The DP832 downgrade/upgrade for me has made the output meters read wrongly and the
options are lost when going back to v1.08, they're there in v1.06.
Can not change this by re-calibrating (unless I'm doing it in the wrong order?)
Can anyone help? Bricked?
This is the latest model with large heatsink.
Please :-BROKE
Thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Git on December 13, 2013, 04:35:05 pm
All the tests were done on a DS1074Z with Ver:00.02.00.SP1.

What about the ECC private key, has it changed for Ver:00.02.00.SP1 ?>
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sync on December 13, 2013, 04:48:56 pm
Edit: I have measurement history now. ;D And i think the region (gated) measuring mode is also new. They are in the 2nd page of the measure menu. Is that the unknown option?
The unknown option is not the measuring history and region measuring. I removed the options and still have them.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 13, 2013, 05:04:02 pm
Happy to help. I haven't installed the 300MHz option yet because:

1) I don't really need the extra bandwidth at this time - although maybe later, in which case I would try it.
2) I'm not 100% sure that HW v.1 fully supports it. Remember, Rigol didn't start offering a 300MHz model until they had developed HW v.2. OTOH, the CAN option is all software.
3) Remember, it's a 2GSa/s scope. The DSO only does sin(x)/x interpolation at 1G & 2GSa/s - everything below that (<= 500MSa/s) uses linear interpolation - which really requires a sample rate >= 8x the highest frequency for a decent reconstruction. SO throwing 300MHz at the DSO, especially at slower sample rates is pushing the envelope. In actual fact, for best reconstruction (and lowest noise), you really should keep the 100MHz bandwidth filter on if you're fairly certain you don't have higher frequencies.

Well, if Rigol allow 200 MHz BW limit when the option 300MHz is installed, to me it would seem right.

Quote
100MHz limit gives you a -3dB BW of ~130MHz
200MHz limit gives you a -3dB BW of ~185MHz

...so only a ~55MHz difference between the settings.

Yes, not much difference, but adding this option (200MHz BW limit) may be practical, adds another feature and no has HW cost.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 13, 2013, 05:26:00 pm
Well, if Rigol allow 200 MHz BW limit when the option 300MHz is installed, to me it would seem right.

Well, the only way we'll know for sure, unless some owner(s) do a battery of exhaustive tests, is if Rigol starts selling 300MHz BW as an option to HW v.1 owners.

Quote
Yes, not much difference, but adding this option (200MHz BW limit) may be practical, adds another feature and no has HW cost.

True, yet still, it's not an included feature for DS2302A buyers (see the manual).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 13, 2013, 05:54:39 pm
Well, the only way we'll know for sure, unless some owner(s) do a battery of exhaustive tests, is if Rigol starts selling 300MHz BW as an option to HW v.1 owners.
How of exhaustive?
Someone volunteers to do the test?

True, yet still, it's not an included feature for DS2302A buyers (see the manual).
Yes, I know. But maybe they add it in the future.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: EV on December 13, 2013, 06:08:22 pm
 I tried to install this CAN decode option to my DS2202 with FW 02 by entering the code (LLL..) to option install menu. It did not work. Have I missed something or does it not work with DS2202?

I didn't, although I have an official key for the normal options; I just used cybernets DSEA for CAN decode. (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg344845/#msg344845https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg344845/#msg344845)
.
.
.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: EV on December 13, 2013, 07:30:45 pm
I tried again. Code LLLLLLL-RLGLLDS-DSEALLL-LLLLLLL gives message: "Option is unavailable".
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 13, 2013, 08:00:06 pm
I tried again. Code LLLLLLL-RLGLLDS-DSEALLL-LLLLLLL gives message: "Option is unavailable".
That code doesn't look right.

You need to generate a code using DSEA as option and your serial# here: http://riglol.3owl.com (http://riglol.3owl.com)

I tried generating a key using DSA1234567890 as serial# and DSEA as option.
The generated code looks like this: RDJ9JBB-N3SWWUS-R3XENY5-A2Y3A9S
Notice D, S, E and A are not located next to each other.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 13, 2013, 08:02:47 pm
I tried again. Code LLLLLLL-RLGLLDS-DSEALLL-LLLLLLL gives message: "Option is unavailable".

Yes, as AndersAnd wrote, I used my serial number and the code DSEA in the Riglol key generator to generate a CAN license key. I don't believe those old keys are valid in the newest firmware.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: EV on December 13, 2013, 08:26:28 pm
Thanks AndersAnd and marmad! I guessed that I had missed something. I have not read all in this tread because I have the other options.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Pinkus on December 13, 2013, 09:55:51 pm
Just FYI if you have an older HW 1.0 DS2072 and if you are wondering if it works there.
I did upgrade my HW 1.0 DS2072 without any problems (was of course at 200 Mhz etc. before): I did uninstall all options first (SCPI command), then rebooted with pressed F6, then rebooted again with inserted USB stick with latest FW.
After the upgrade I pressed F6 again during the reboot.
Then I entered the new license number generated with DSHH key:
Voilà: 300 Mhz and all options including CAN available and working.

Thank you all!

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: EV on December 13, 2013, 10:15:46 pm
Yes, it works now, Thanks!  :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: UberSteve on December 14, 2013, 12:28:58 am
Just FYI if you have an older HW 1.0 DS2072 and if you are wondering if it works there.
I did upgrade my HW 1.0 DS2072 without any problems (was of course at 200 Mhz etc. before): I did uninstall all options first (SCPI command), then rebooted with pressed F6, then rebooted again with inserted USB stick with latest FW.
After the upgrade I pressed F6 again during the reboot.
Then I entered the new license number generated with DSHH key:
Voilà: 300 Mhz and all options including CAN available and working.

Thank you all!

Just to add another data point, I went through the exact same scenario and now have 300Mhz with all options (inc. CAN), enabled. (serial number still intact also).

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: EV on December 14, 2013, 08:11:25 am
Ok, I installed also BW 300M option to my DS2202. Rise time tests are here:

https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/1860/ (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/1860/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jkw13 on December 14, 2013, 02:07:32 pm
Can I get clarification; Are these all the models that these instructions cover?


DP832
DS1000z
DS2000
DS4000
DSA815

Read this topic, you will probably learn a lot and avoid some mistakes in the updating process. And maybe even be able to help other members out with questions or further hacking. Lazy people will skip this step.
Make sure your have updated your Rigol to the latest firmware version before entering any keys. Except for DP832 where Rigol has changed the keys in 01.08.00, so install firmware 01.06.00 before entering any keys. Then you can upgrade the firmware to 01.08.00 afterwards. Read here.
Go to studio25's RigLOL website: http://riglol.3owl.com (http://riglol.3owl.com) or Avotronics's mirror site: http://rigol.avotronics.co.uk/riglol (http://rigol.avotronics.co.uk/riglol)
Enter the Rigol serial number in the "Serial:" box.
Find the correct 4 letter code for your desired option in the tables at the above website (e.g. DSAZ to enable all options on DS2000 series scopes).
Enter this 4 letter code in the "Options:" box.
Don't enter anything into the "Privatekey:" box, but just hit generate and it will fill out the box automatically and then generate a valid license key in a pop-up window.
Enter this license key in the right menu on your Rigol (check your manual) and hit Apply.
Reboot, verify options installed and enjoy!

I think I've "bricked" my new DP832 by downgrading it to v1.06 and back to v1.08.
ADC cal doesn't work anymore, and the display meters are wrong.
Is there any way to recover from this do you think? Perhaps I did something wrong?
Does anyone know the ManualCal procedure?   :-BROKE
Thanks!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on December 14, 2013, 03:50:25 pm
Quote
I think I've "bricked" my new DP832 by downgrading it to v1.06 and back to v1.08.
ADC cal doesn't work anymore, and the display meters are wrong.
Is there any way to recover from this do you think? Perhaps I did something wrong?
Does anyone know the ManualCal procedure?   :-BROKE
Thanks!

The problem is not the firmware up / downgrade.
There is a bug in the manual calibration.
Only volts and current ADC are affected.
The DAC's are ok.
Rigol knows the problem.
I'm waiting for a new firmware.
Write a mail to the Rigol support.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: m-joy on December 14, 2013, 05:28:23 pm
Hello,

i am currently on software version 00.02.00.
But the thread is talking about an 00.02.01.00.03 Version.
Weird because a lot more numerics... What going on?

Greetings
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 14, 2013, 05:46:32 pm
Hello,

i am currently on software version 00.02.00.
But the thread is talking about an 00.02.01.00.03 Version.
Weird because a lot more numerics... What going on?

Greetings
There's a short version number visible in the regular menu, but there's an extended version number only visible in a hidden menu found as described by marmad here: https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684 (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684)
To get the full firmware version info from the DSO, follow these instructions:

Go to the Trigger menu and set Edge trigger.
While keeping the Trigger menu open, you are going to use the 6th and 7th right-side menu buttons as follows:
Press the [Menu7][Menu6][Menu7][Utility] buttons one after another quickly.
Then check additional info under System -> System Info.
You should see something like:

Software version: 00.00.01.00.05
Hardware version: 1.0.1.0
FPGA version:
SPU 03.01.02
WPU 00.06.00
CCU 12.29.00
MCU 00.05

If you DON'T see this detailed info = start again, and press those 4 buttons faster.

To escape from this mode, press again [Menu7][Menu6][Menu7][Utility] while inside Trigger menu
- or reboot the scope.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: m-joy on December 14, 2013, 06:00:14 pm
Great ! Did not know that... so i am on 00.02.00.00.04 xD
But i have an DS2072A Version. Does the keygen work for me....?
Title: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on December 14, 2013, 06:02:37 pm

Great ! Did not know that... so i am on 00.02.00.00.04 xD
But i have an DS2072A Version. Does the keygen work for me....?

Nope.

We need a jtag dump if you are willing t help, the info is earlier in this thread.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 14, 2013, 06:04:30 pm
The keygen doesn't work for DS2000A series. It only works for the old non-A models so far.

But I would upgrade to FW 00.02.01.00.03 anyway as some bug fixes has been made I believe.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: m-joy on December 14, 2013, 06:04:59 pm

Great ! Did not know that... so i am on 00.02.00.00.04 xD
But i have an DS2072A Version. Does the keygen work for me....?

Nope.

We need a jtag dump if you are willing t help, the info is earlier in this thread.

Damn. I have no clue what an jtag dump is :D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 14, 2013, 06:10:17 pm
Damn. I have no clue what an jtag dump is :D
Let me just tell you, it's not the kind of dump you take on the toilet...  ;D

But "apelly" promised to make a JTAG memory dump on his DS2072A once he receives his Bus Blaster. Read here: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg345470/#msg345470 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg345470/#msg345470)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: EV on December 14, 2013, 06:11:11 pm
This number 00.02.00.00.04 is different from DS2000 FW numbers. Has DS2000A different FW?

Great ! Did not know that... so i am on 00.02.00.00.04 xD
But i have an DS2072A Version. Does the keygen work for me....?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 14, 2013, 06:18:24 pm
This number 00.02.00.00.04 is different from DS2000 FW numbers. Has DS2000A different FW?

Great ! Did not know that... so i am on 00.02.00.00.04 xD
But i have an DS2072A Version. Does the keygen work for me....?
They use the same FW now. You can download the latest FW 00.02.01.00.03 for both DS2000 and DS2000A here: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg342994/?topicseen#msg342994 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg342994/?topicseen#msg342994)

I believe 00.02.00.00.04 was the FW installed on the first DS2000A's shipped and the file has never been sent to customers for either DS2000 or DS2000A, so you can't install it yourself.
The first (and so far only) DS2000A FW send to customers is 00.02.01.00.03. This is the same file they send to DS2000 non-A customers now.

You need to install 00.02.01.00.03 on DS2000 non-A to use the latest key options like CAN, 300 MHz BW etc. published by cybernet.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: elecBlu on December 14, 2013, 06:39:16 pm
some tests of the real-world performance of the 300MHz Hack with Rohde & Schwarz SMS2 Generator (50Ohm).
I followed this procedure: https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg347187/#msg347187 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg347187/#msg347187)
Looks good so far...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 14, 2013, 06:44:22 pm
Nice. Have you measured the 3 dB cutoff frequency?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigol-Friend on December 14, 2013, 07:08:39 pm
Rhode & Schwarz 

I never heard about that factory.     :o   :-DD
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: elecBlu on December 14, 2013, 07:25:42 pm
did only direct comparison at the moment, but i can do some more tests soon.
And oops, little typo it is Rohde & Schwarz of course ;)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: murdok on December 14, 2013, 07:57:04 pm
Followed the thread since it started months ago, but have some questions now:

Can someone confirm that with latest SW (00.02.01.00.03) and enabled options on base of non-A DS2072 (HW v2), the selectable languages increased in count, but activating 50Ohm input option thru SCPI is no more working? (always prints note on screen: "invalid command" - whatever i try to put behind :CHANx:IMP)

Didn't try all combinations but i guess its independent of activated options.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: elecBlu on December 14, 2013, 08:04:28 pm
confirm, no more 50Ohms but extra languages
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigol-Friend on December 14, 2013, 08:36:58 pm
but extra languages

Wow, I never took a look in this language-menu before, thanks for that info. Will inspect later, what the chinese developers
understand about German.   ;D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: apelly on December 14, 2013, 09:03:16 pm
But "apelly" promised to make a JTAG memory dump on his DS2072A once he receives his Bus Blaster.
Still no sign of it. Allegedly shipped on the 4th Dec., but the tracking number doesn't work. WTF? Will give it a few more days before I follow up.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jkw13 on December 14, 2013, 09:22:12 pm
Quote
I think I've "bricked" my new DP832 by downgrading it to v1.06 and back to v1.08.
ADC cal doesn't work anymore, and the display meters are wrong.
Is there any way to recover from this do you think? Perhaps I did something wrong?
Does anyone know the ManualCal procedure?   :-BROKE
Thanks!

The problem is not the firmware up / downgrade.
There is a bug in the manual calibration.
Only volts and current ADC are affected.
The DAC's are ok.
Rigol knows the problem.
I'm waiting for a new firmware.
Write a mail to the Rigol support.


Wow! Many thanks for that, saved me a lot of worry :phew:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on December 14, 2013, 09:56:42 pm
lol, I saw some agilent dx3000 (?) not long ago with German language selected
I don't think I'll ever set the DS to German, it kinda feels weird while using such a device ...
I wonder when it will arrive, if I can trust the shop site, I'll have it next week ...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: thetooth on December 14, 2013, 11:25:00 pm
But "apelly" promised to make a JTAG memory dump on his DS2072A once he receives his Bus Blaster.
Still no sign of it. Allegedly shipped on the 4th Dec., but the tracking number doesn't work. WTF? Will give it a few more days before I follow up.
The postal service has slowed to a crawl, i have a TFT breakout board in the mail shipped from melb on the 9th, ETA is 23rd to January  ::)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Co6aka on December 15, 2013, 01:13:09 am
what the chinese developers understand about German.   ;D

Bier!! und Schnitzel!!!   :-+  JA!!!

Re the 50-Ohm termination and not being able to enable it... Isn't it a standard feature of the "A" model?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: EV on December 15, 2013, 10:28:37 am
It is a little over 300 MHz measured with HP 8642A generator with BNC cable and 50 Ohm feed through terminator. Scope is DS2202 wiith HW1 and 300M option.

In the picture is sweep from 1 MHz to 350 MHz. Sweep time is 14 s, so one horisontal craticule division is 25 MHz. Cursor lines show the 3 dB levels.

Nice. Have you measured the 3 dB cutoff frequency?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: EV on December 15, 2013, 12:56:26 pm
It was about 240 MHz before updates.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on December 15, 2013, 02:23:10 pm
what exactly are you doing?
I mean, what information could I gain from this? :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Marty_MC on December 15, 2013, 04:22:10 pm
Hello!
I am a German amateur radio guy (Ham) and I am looking for a new DSO. For home use.

Now I am in the conflict to go for a 2072 2172A-S.

Generally, I was going to buy a 2072 and "extend" the device with this information of this board here...
For me are important:
- 200 MHz
- More memory for storage
- UART decoding

As far as I understood, the A Version can not be "extended" by simple use the codes of the well know page?
I have the doubt that the new version is more protected as the old one.

However the A versions are able to have a 50 Ohm input and a signal generator. Two nice features.
What I not understand: Suppose I am buying a 2072 and extend it by using these codes of the page. Would it still function with a 2.0 Firmware version?

The next problem is to get a 2072 without A NOW. I am thinking perhaps Conrad.de would have it on stock.


(My wife wants to buy the DSO for my as a Christmas gift. - so I have to decide quick...   :clap:

 What are your suggestions?
Thank you very much!!

Marty_MC

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: elecBlu on December 15, 2013, 04:36:17 pm
look one page back, yesterday i sucessfully unlocked my DS2072 (HW2.0) together with the new firmware (0.2). (Decode incl. CAN, Memory, Trigger, 300MHz).

Sure, 50Ohms is a nice feature, but at the moment i would go for the DS2072 or wait some time until the A Version is unlocked. Nobody knows these days, if this will be possible at all.
Signal Generator is a usefull thing, but you still have to pay some euros extra for that. Maybe you better go for the DG1022 or Siglent SDG10xx Generators instead, brings you the advantage of an extra device. As a Ham radio guy you may prefer a signal generator with more output frequency at sine wave (go for a sine wave generator), so you may don't need the arbitrary functions. It depends on your needs.

Batronix has the DS2072 still on stock, the bigger problem should be to get the A Version on stock at this moment i guess.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigol-Friend on December 15, 2013, 05:07:05 pm
My wife wants to buy the DSO for my


Let's change our wifes...    :P
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: m-joy on December 15, 2013, 05:50:32 pm
But "apelly" promised to make a JTAG memory dump on his DS2072A once he receives his Bus Blaster.
Still no sign of it. Allegedly shipped on the 4th Dec., but the tracking number doesn't work. WTF? Will give it a few more days before I follow up.

Rock on! I am so curious if it s going to work =)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Marty_MC on December 15, 2013, 06:40:00 pm

[/quote]
Let's change our wifes...    :P
[/quote]

Sorry, NEVER. She has also a amateur Radio licence and likes fast cars  :-+. Currently she is driving a Jaguar.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on December 16, 2013, 02:27:40 am
Nobody knows these days, if this will be possible at all.

It is highly unlikely to me that it won't be possible, once a firmware dump is obtained.  Same hardware, same firmware for both DS2XXX and DS2XXX-A models. 

Any of you with -A models that know how to dump via JTAG should probably get a move on if you want to see the hack completed.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Marty_MC on December 16, 2013, 10:56:44 am

Batronix has the DS2072 still on stock, the bigger problem should be to get the A Version on stock at this moment i guess.

Hello!
Does anyone knows a company who has the DS2072 without A on stock in Europe and is able to deliver to Germany?
I have called Batronix, Conrad and so one and no one has the Version without A on stock any more.
It looks like many devices has been sold the last week...
Thanks for replay!
Marty_MC
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: WVL_KsZeN on December 16, 2013, 11:03:29 am
conrad.nl has some in stock : http://www.conrad.nl/ce/nl/product/409743/ (http://www.conrad.nl/ce/nl/product/409743/)

I'm not sure if they'll deliver to Germany (but their warehouse is in the south of Germany already! weirdness.)

I just looked on conrad.de, and they also have them in stock? sofort lieferbar.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 16, 2013, 11:06:29 am
Does anyone knows a company who has the DS2072 without A on stock in Europe and is able to deliver to Germany?
I have called Batronix, Conrad and so one and no one has the Version without A on stock any more.
You might also try Petr Šmíd: info@silcon.cz - www.silcon.cz (http://www.silcon.cz) (he is member Drieg on this forum). I don't know, but maybe he still has non-A in stock. He delivers throughout EU.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: elecBlu on December 16, 2013, 12:01:17 pm
I have called Batronix, Conrad and so one and no one has the Version without A on stock any more.
It looks like many devices has been sold the last week...
very interesting, i just had a quick look at their shop which still says DS2072 on stock. Maybe they think it is okay to ship the newer DS2072A instead, but at the moment this makes a huge difference  |O
Edit: Conrad changed this information today, DS2072 out of stock, DS2072A shipping...

BUT this is not the thread for shipping discussion.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on December 16, 2013, 12:37:49 pm
the shop where I ordered mine still says shipping time "1 week" -_-;
I hope they'll ship it THIS week ...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 16, 2013, 12:38:05 pm
It is a little over 300 MHz measured with HP 8642A generator with BNC cable and 50 Ohm feed through terminator. Scope is DS2202 wiith HW1 and 300M option.

In the picture is sweep from 1 MHz to 350 MHz. Sweep time is 14 s, so one horisontal craticule division is 25 MHz. Cursor lines show the 3 dB levels.

Thanks, EV! So it appears 300MHz BW option is functional for HW v.1 owners. I wonder why Rigol didn't sell 300MHz DS2000s from the beginning?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: EV on December 16, 2013, 01:04:44 pm
Maybe it is too near to 300 MHz as for example it is about 240 MHz for DS2202 with  200 MHz BW.

Thanks, EV! So it appears 300MHz BW option is functional for HW v.1 owners. I wonder why Rigol didn't sell 300MHz DS2000s from the beginning?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 16, 2013, 02:02:00 pm
Maybe it is too near to 300 MHz as for example it is about 240 MHz for DS2202 with  200 MHz BW.

True - perhaps it's closer to 350MHz on HW v.2 DSOs. Anyway, as long as you know the limits...

@EV: BTW, did you run the self-calibration after installing the 300MHz option (or before running the sweep)?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: EV on December 16, 2013, 02:14:57 pm
No,  I run the calibration and then the sweep again. Wait a moment!

@EV: BTW, did you run the self-calibration after installing the 300MHz option (or before running the sweep)?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 16, 2013, 02:23:14 pm
Does anyone knows a company who has the DS2072 without A on stock in Europe and is able to deliver to Germany?
Thanks for replay!
Marty_MC
You might also try Petr Šmíd: info@silcon.cz - www.silcon.cz (http://www.silcon.cz) (he is member Drieg on this forum). I don't know, but maybe he still has non-A in stock. He delivers throughout EU.
I also recommend you silcon. Petr Šmíd is a wonderful person.  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 16, 2013, 02:24:39 pm
No,  I run the calibration and then the sweep again. Wait a moment!
You'll probably have the same results.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 16, 2013, 02:27:12 pm
True - perhaps it's closer to 350MHz on HW v.2 DSOs. Anyway, as long as you know the limits...
I can not be totally sure, but I think that the input stages are the same in both versions (except for 50ohm and associated relay).

I rectified, there are some more changes:

(https://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0/?action=dlattach;attach=56344;image)

Someone can take a better picture of the input stage for the HW.v2.0?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 16, 2013, 02:31:21 pm
I can not be totally sure, but I think that the input stages are the same in both versions (except for 50ohm and associated relay).

Then it seems even more illogical that they didn't sell a 300MHz version DS2000 a year and a half ago - unless it was only because of the lack of 50 Ohm input.

EDIT: BTW, the image you posted is only HW v.2 - we don't know for certain that A-models don't have a slightly more-modified input stage.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 16, 2013, 02:43:24 pm
Then it seems even more illogical that they didn't sell a 300MHz version DS2000 a year and a half ago - unless it was only because of the lack of 50 Ohm input.
True, It seems that there are more changes between version 2 and 1.

EDIT: BTW, the image you posted is only HW v.2 - we don't know for certain that A-models don't have a slightly more-modified input stage.
True.
Someone can take a better picture of the DS2xxxA's input stage?    Apelly for example.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 16, 2013, 02:51:53 pm
At least the transistors seem to be the same. But the compensation stage is certainly different.
Note: I refer to the previous image.



@ Marmad.: You know if there are different 1.0 versions?
For example HW.v.: 1.0.1.0.0 / 1.0.0.0.0 / 1.0.1.0.1 ...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: EV on December 16, 2013, 03:01:04 pm
Ok, I run the self calibration and new sweep. Maybe there is a small improvement. BW seems to be now about 310 MHz.

In the picture is sweep from 1 MHz to 350 MHz. Sweep time is 14 s, so one horisontal craticule division is 25 MHz. Cursor lines show the 3 dB levels.


No,  I run the calibration and then the sweep again. Wait a moment!

@EV: BTW, did you run the self-calibration after installing the 300MHz option (or before running the sweep)?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: EV on December 16, 2013, 03:06:27 pm
The true 50 Ohm input is propably better than this feed through terminator.


Then it seems even more illogical that they didn't sell a 300MHz version DS2000 a year and a half ago - unless it was only because of the lack of 50 Ohm input.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 16, 2013, 03:08:21 pm
The true 50 Ohm input is propably better than this feed through terminator.
I've always thought the opposite.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 16, 2013, 03:22:15 pm
Inverted -> after calibrated.

(https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/?action=dlattach;attach=71376;image)

Where is the difference in BW?  :-//

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 16, 2013, 03:24:10 pm
Ok, I run the self calibration and new sweep. Maybe there is a small improvement. BW seems to be now about 310 MHz.
It looks more like 330MHz 315MHz - although it would be a little easier to read if the full graticule was showing. Of course, there is always some small percentage of +/- error in display, etc.

(https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/?action=dlattach;attach=71379)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 16, 2013, 03:30:29 pm
Inverted -> after calibrated.

The images don't match because EV had statistics ON when doing first sweep - so graticule was reduced to 700x360 - instead of the normal 700x400. One of the images needs to be adjusted for compensation.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 16, 2013, 03:32:17 pm
I've resized it better.

(https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/?action=dlattach;attach=71396;image)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: darrylp on December 16, 2013, 04:24:27 pm
The LMH6518 has bandwidth limits of 20, 100, 200, 350  and 650 750 and unlimited ie 900MHz.

So the 350MHz should be used for the 2302 model I reckon.

--
Darryl

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: EV on December 16, 2013, 04:25:26 pm
Here is one picture more!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on December 16, 2013, 04:33:43 pm
The gain after calibration is very, very small.  Seems like the gain is within measurement noise.  Am I wrong?  I guess I was looking for a huge improvement.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 16, 2013, 04:41:57 pm
The gain after calibration is very, very small.  Seems like the gain is within measurement noise.  Am I wrong?  I guess I was looking for a huge improvement.

It's HW v.1, IMO, to be expected. I imagine HW v.2 and A models are better.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: EV on December 16, 2013, 05:17:01 pm
No, the sweep is from 1 MHz to 350 MHz. I checked my text and picture titles there reads 350 not 300.


EV,

I'm not sure that I understand your measurement.
You said that the signal generator is producing a sine wave sweep between 1MHz and 300MHz over a time span of 14 seconds (24.93MHz per second assuming a linear frequency sweep).

The DS2000 display is showing that it's horizontal time base is set to 1 second per division and we see a waveform covering all 14 horizontal divisions of the display.
We also see that the trigger point is off the left side of the display by 1.5 seconds (display shows trigger delay of 8.5 seconds minus 7 divisions of 1 second each).
Wouldn't that mean that the actual sweep time from the generator is at least 15.5 seconds? 
If so, then the sweep would be 349/15.5 = 22.52MHz per second and the -3db point would be about 342MHz since there is an extra 1.5 seconds of sweep off the left side of the display (assuming the the sweep also ends at exactly the last graticule line of the display).

Or are you manually triggering the scope and then centering the entire sweep on the display?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JDubU on December 16, 2013, 05:23:32 pm
I see now.  I was confused by the offset trigger point.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 16, 2013, 06:04:00 pm
Photo montage 350 MHz BW  :)

(https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/?action=dlattach;attach=71545;image)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mightyzen on December 16, 2013, 08:00:22 pm
I just had to do some testing on the bandwidth of my v2 ds2072. It still runs the original firmware unlocked to 200MHz, simply because I am not ready to lose the 50 ohm termination. May be upgrading it later though.

I have looked at the output of a 125MHz crystal oscillator via:

1. 3300A probe with the ground lead (no bw limit)
2. 3300A probe with spring clip (no bw limit)
3. Coax 20MHz limit
4. Coax 100MHz limit
5. Coax no limit
6. Coax on a crusty hantek dso5072p hacked to 200MHz

The different probing/coax testing was inspired by Mike's excellent video series on the nano lcd reversing. Just shows again that at these frequencies the way you are probing makes a lot of difference.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: m-joy on December 16, 2013, 10:20:24 pm
Is it True that there was an 200Mhz trial on the ds2072?Because i can not Find that on my ds2072A.if this option has been removed, maybe there can not be keys for activating higher bandwidth on A-models...?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JDubU on December 16, 2013, 10:28:50 pm
Is it True that there was an 200Mhz trial on the ds2072?Because i can not Find that on my ds2072A.if this option has been removed, maybe there can not be keys for activating higher bandwidth on A-models...?

There was no 200MHz trial on a new DS2072.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marshallh on December 17, 2013, 01:36:49 am
(http://imageshack.us/a/img802/1701/c7x3.png)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: gaijin on December 17, 2013, 02:41:27 am
I have a 2072 non A 1.0 hardware FW v.02.01.00.03 upgraded to a 2302 with DSHH.
Was wondering if anyone else tried accessing the CAN trigger/decode by SCPI

Querying the current trigger with :TRIGger:MODE? works for all but CAN.
Trying to set the trigger to CAN with :TRIGger:MODE CAN pops a message on the scope "Input is invalid"
:BUS1:MODE? will return CAN and :BUS1:MODE CAN will select CAN.
But I couldn't access anything under :BUS1:CAN like :OFFSet
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JDubU on December 17, 2013, 06:46:21 am
I have a 2072 non A 1.0 hardware FW v.02.01.00.03 upgraded to a 2302 with DSHH.
Was wondering if anyone else tried accessing the CAN trigger/decode by SCPI

Querying the current trigger with :TRIGger:MODE? works for all but CAN.
Trying to set the trigger to CAN with :TRIGger:MODE CAN pops a message on the scope "Input is invalid"
:BUS1:MODE? will return CAN and :BUS1:MODE CAN will select CAN.
But I couldn't access anything under :BUS1:CAN like :OFFSet

There is no mention of CAN specific commands in the DS2000A programming guide:
http://www.rigol.com/prodserv/DS2000A/document/?act=view&itemid=749 (http://www.rigol.com/prodserv/DS2000A/document/?act=view&itemid=749)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 17, 2013, 01:00:42 pm
(http://imageshack.us/a/img802/1701/c7x3.png)
What's this? Looks like snowy mountains.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: m-joy on December 17, 2013, 01:49:05 pm
isnt it currently more efficient to buy an Rigol DS1074Z instead of ds2072A ? Because for the DS1074Z the serials seems to work because there is no A version...?
And with options you have at least 100Mhz and stuff compared to the 70Mhz ds2072A and save money.

Greets
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Marty_MC on December 17, 2013, 01:52:31 pm
Finally I got a DS2072 HW version 1.0 with and version 00.01.01 from a small dealer in south Germany.
I had to drive 100kms one way but it was worth.
 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on December 17, 2013, 02:41:37 pm
isnt it currently more efficient to buy an Rigol DS1074Z instead of ds2072A ? Because for the DS1074Z the serials seems to work because there is no A version...?
And with options you have at least 100Mhz and stuff compared to the 70Mhz ds2072A and save money.

Greets

You have more reading to do.  As soon as someone gets a dump of the firmware on the device of a DS2000A scope, it is very likely that the keygen will be modified to accommodate the newer model.

Just take the time and read this entire thread.  It will take a while, yes.  You will learn many things if you don't rush it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: m-joy on December 17, 2013, 06:02:11 pm
Quote


 As soon as someone gets a dump of the firmware on the device of a DS2000A scope, it is very likely that the keygen will be modified to accommodate the newer model.


Maybe it will, maybe not...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on December 17, 2013, 06:57:30 pm
Maybe it will, maybe not...

http://www.pigpenpoetry.com/ (http://www.pigpenpoetry.com/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: barnacle2k on December 17, 2013, 09:20:54 pm
You have more reading to do.  As soon as someone gets a dump of the firmware on the device of a DS2000A scope, it is very likely that the keygen will be modified to accommodate the newer model.

Just take the time and read this entire thread.  It will take a while, yes.  You will learn many things if you don't rush it.

Rigol DS2072A - check
FTDI JTAG thingy - check

Now if anyone could get me short instructions which SW and commands i should use.
Since i am not sure what exactly gets URJtag or gdb to create the dump you guys need.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: fcab100 on December 17, 2013, 11:17:00 pm
barnacle2k you have a DS2072A congrats on your new scope.  I was wondering if you could tell me what the jumper pins are set to on your scope.  Wanted to know if the its has changed.


Thanks Chris
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bobn4burton on December 18, 2013, 12:13:05 am
So I just got my DS2102 and was preparing to use the keygen and unlock all options to get me to a DS2202.  I noticed that the 'all-options' code is now listed as DSHH??

I must have missed something in the last few weeks...but I believe the previous 'all-options' code was a DSAZ?

Which code should I be using to fully unlock my DS2102?

Also...most people are upgrading from a DS2072...I shouldn't  have any problems starting from a DS2102 should I?

Thanks in advance!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: fcab100 on December 18, 2013, 12:25:14 am
So I just got my DS2102 and was preparing to use the keygen and unlock all options to get me to a DS2202.  I noticed that the 'all-options' code is now listed as DSHH??

I must have missed something in the last few weeks...but I believe the previous 'all-options' code was a DSAZ?

Which code should I be using to fully unlock my DS2102?

Also...most people are upgrading from a DS2072...I shouldn't  have any problems starting from a DS2102 should I?

Thanks in advance!


Use DSHH as it unlocks 300mhz with can decoding  Make sure you have the latest fw update. The Fw (00.02.01.00.03) can be found at https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/ (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Bugware on December 18, 2013, 12:28:18 am
There is no problem to start from DS2102.

Use DSAZ for Firmware 00.01.01.00.02 to get 200MHz and all options.

Use DSHH for the brand new Firmware 00.02.01.00.03 (you can get it from  here (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684) but read careful) to get 300MHz and all Options incl. CAN capability.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bobn4burton on December 18, 2013, 12:32:02 am
WOW...apparently I did miss something!

We can upgrade to 300Mhz now???

Has this been verified to be truly 300Mhz capable?

Sorry if I'm re-hashing...just haven't had to time stay up to date on this thread the last few weeks and thought I better check in before updating.  And good thing I did...as we apparently got an even better upgrade than what I was planning...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 18, 2013, 12:36:37 am
Why not DSGH ?  has anyone found out what the DSBA bit does yet?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MrsR on December 18, 2013, 02:11:17 am
Hi! Guys,
Can someone HELP me.
I went right back through the thread and found the instructions to update my DS2072 to 200mHz.
I had to upgrade my FW used the one on the site and tried to change the trigger and speed it up.
Unfortunately it didn't work Just got incorrect code  at the bottom of the screen on entering APPLY.

I have the memory updated to 56 megs purchased from EMONA before this thread started.
My Hardware Ver. is 1.000
and updated FW from 1.000.05 to 1.000.00.3 Zeros not accurately shown as I didn't copy it down from DSO.
CAN YOU HELP ME
Rachael
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MrsR on December 18, 2013, 02:24:39 am
I forgot to add,
I lost my trial versions I don't know what I did but I didn.t use the scope for about a month and when I switched it back on the Trial versions came back The funny thing is I have used the scope for more than 2 hours and the trial version time hasn't changed started at 2032 and still at 2032.????????

THANKS
Rachael
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cidcorp on December 18, 2013, 03:12:22 am
Well I personally can't explain the suspended time trials, but I'm guessing if you are going to do a full unlock that this isn't going to be an issue.

I have a DS2102, all I did was upgrade to the new 00.02.01.00.03 firmware via the boot upgrade (ie. USB Key, Power, Help Key), not the process where the scope sees the newer firmware
on the USB key and asks if you want to upgrade.  Made sure to reset to factory settings during first boot with newer firmware using the Left F6 key (repetitively pushing during boot).  Then used the CAN & 300Mhz key codes generated by key generator (rigLOL website, you can link from here: http://rigol.avotronics.co.uk/mirrors/riglol/ (http://rigol.avotronics.co.uk/mirrors/riglol/)) to preserve the existing codes I already had (as with your 56M). 

To generate a key, simply add your serial number (for your scope) to the text box called serial: DS12345678901, then add the option you want a key for, let's say DSHH for all options, leave the private key box empty, then hit the GENERATE key - Use this key in the Options Setup Screen on the scope.

I 'assume' you can use the DSHH code with your Scopes serial and be up and running with all the options without having any effect on the 56M option. 

Just my 0.02

Chris
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: staze on December 18, 2013, 04:29:12 am
Okay, just upgrade my formerly 2072->2202 to the 2302 via uninstall, then clear FRAM, upgrade (via help), clear FRAM, install new key.

One thing interesting... I'm seeing weird "glitches" with the 1ns timebase, where it will show persistence, but then every once half second (or less) flick to no persistence for a frame or two, then back to persistence.

Scope is HW2, non-A. Key seemed to work just great. And now that I look at it, several of the timebases are showing this behavior. Looks like it might just be a function of the lower persistence times. Is that what others see? What do others leave their's at normally?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tlu on December 18, 2013, 05:07:52 am
I was have Marmad check it out and send it to Drieg as a bug if this is really the case.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MrsR on December 18, 2013, 06:00:49 am
Well I personally can't explain the suspended time trials, but I'm guessing if you are going to do a full unlock that this isn't going to be an issue.

I have a DS2102, all I did was upgrade to the new 00.02.01.00.03 firmware via the boot upgrade (ie. USB Key, Power, Help Key), not the process where the scope sees the newer firmware
on the USB key and asks if you want to upgrade.  Made sure to reset to factory settings during first boot with newer firmware using the Left F6 key (repetitively pushing during boot).  Then used the CAN & 300Mhz key codes generated by key generator (rigLOL website, you can link from here: http://rigol.avotronics.co.uk/mirrors/riglol/ (http://rigol.avotronics.co.uk/mirrors/riglol/)) to preserve the existing codes I already had (as with your 56M). 

To generate a key, simply add your serial number (for your scope) to the text box called serial: DS12345678901, then add the option you want a key for, let's say DSHH for all options, leave the private key box empty, then hit the GENERATE key - Use this key in the Options Setup Screen on the scope.

I 'assume' you can use the DSHH code with your Scopes serial and be up and running with all the options without having any effect on the 56M option. 

Just my 0.02

Chris

Thanks Chris, Could you tell me where I can get a copy of the FW 00.02.01.00.03.

Rachael :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: staze on December 18, 2013, 06:03:40 am

Thanks Chris, Could you tell me where I can get a copy of the FW 00.02.01.00.03.

Rachael :-+

Bottom of this post: https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684 (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bobn4burton on December 18, 2013, 06:21:06 am
Just updated my DS2102 to the all option DSHH!

Couldn't have been easier...

A HUGE thanks again to all the effort put in from everyone on here.

Now off to enjoy some advanced triggering!!!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: darrylp on December 18, 2013, 05:49:36 pm
can confirm, had left my upgraded 2072 as 2202, updated to the version 2.x.x.x firmware ( did the F6 to clear FRAM on bootup ) was then able to still see my 2202, and apply the 300MHz and CAN option, to turn those features on as well

so i'd say no need to uninstall any keys already applied on an older firmware.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: manticore00 on December 18, 2013, 06:26:58 pm
Just upgraded my DS2072 with the DS2202 options up to the 300MHz and CAN option as well, went perfectly and had zero issues.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cyr on December 18, 2013, 08:14:46 pm
download, rename to DS4000Update.GEL -> http://www.filedropper.com/ds405xupdate (http://www.filedropper.com/ds405xupdate)

This download seems to be broken, anyone have a mirror?

I have had my DS4014 for several hours already, it desperately needs some unauthorized modification  :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 19, 2013, 01:24:58 am
You have more reading to do.  As soon as someone gets a dump of the firmware on the device of a DS2000A scope, it is very likely that the keygen will be modified to accommodate the newer model.

Just take the time and read this entire thread.  It will take a while, yes.  You will learn many things if you don't rush it.

Rigol DS2072A - check
FTDI JTAG thingy - check

Now if anyone could get me short instructions which SW and commands i should use.
Since i am not sure what exactly gets URJtag or gdb to create the dump you guys need.
Try to PM cybernet and ask for instructions.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: barnacle2k on December 19, 2013, 01:39:22 am
You have more reading to do.  As soon as someone gets a dump of the firmware on the device of a DS2000A scope, it is very likely that the keygen will be modified to accommodate the newer model.

Just take the time and read this entire thread.  It will take a while, yes.  You will learn many things if you don't rush it.

Rigol DS2072A - check
FTDI JTAG thingy - check

Now if anyone could get me short instructions which SW and commands i should use.
Since i am not sure what exactly gets URJtag or gdb to create the dump you guys need.
Try to PM cybernet and ask for instructions.

Quote from: cybernet's profile
pm deactivated, use the search function ...

I know how to setup and connect urjtag or gdb but i would need some info on the rest of the process.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on December 19, 2013, 02:39:58 am
use the gdb bfin proxy from bfin uclinux

when u have patched it up (see DG4000 thread, first few posts) - its the same pinout.

start with something like:
Code: [Select]
./bfin-gdbproxy --debug bfin --frequency=6000000(lower frequency might be needed, i kept it very short in terms of cablelength to get 6mhz)

then use the bfin-gdb - connect to remote target (e.g. target remote localhost:2000)
and u should be able to do what u want.

stuff thats needed:
one dump when its sitting in the bootloader (as the booted application image overwrites stuff in RAM)
and one dump when its booted up - it helps if u do that dump once u entered a easy to find license key ala "AAAAAAAAAAA..."

check http://www.analog.com/static/imported-files/processor_manuals/ADSP-BF52x_hwr_rev1.2.pdf (http://www.analog.com/static/imported-files/processor_manuals/ADSP-BF52x_hwr_rev1.2.pdf) page 115&116 - memory map, and dump everything thats listed there with gdb dump ... as binary.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tirulerbach on December 19, 2013, 06:32:24 pm
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.

[...]

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.

This procedure didn't worked for my DS2202_A_. However, I noticed it lost somehow its calibration when the date rolled over. But the trial licences are not reset.

So maybe I made a fault?

However, it would be nice, if a non-A-owner will remove his keys and try this procedure with the newest firmware (which is for both scopes, "a" and "non-a") to check if it still works. Because smashing the trial minutes only to check that the trick will not work for "a"-scopes is a waste...


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 19, 2013, 06:57:53 pm
This procedure didn't worked for my DS2202_A_. However, I noticed it lost somehow its calibration when the date rolled over. But the trial licences are not reset.

It lost it's calibration after you did a self-calibration? Because that's the next step after the date rolls over and you reset the time.

Also, have you waited ~3 days?

Because smashing the trial minutes only to check that the trick will not work for "a"-scopes is a waste...

It would be silly to do it at all until the trial minutes are finished - and you want more trial minutes. Then nothing is lost/wasted either way.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 19, 2013, 07:17:36 pm
However, it would be nice, if a non-A-owner will remove his keys and try this procedure with the newest firmware (which is for both scopes, "a" and "non-a") to check if it still works.

BTW, there's a good chance that it still works - since it was never published before - and the A-models still use trial minutes. It's clearly part of some procedure that Rigol does at the factory to initiate the DSO (setting the clock for the first time, calibrating, initiating trial minutes, etc) which they never thought any owners would stumble upon. We only found it because the early firmware had a bug which reset trial minutes on a self-calibration - and so we thought we might also use it to restart the trial.

But no reason to try until your minutes run out - and hopefully a keygen will come soon anyway.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Pehtoori on December 19, 2013, 10:01:09 pm
Hi everyone! Just read the whole thread, what a journey, my head is bit sore. Not my native language and have dyslexia so took 2 days straight, ok to be honest skipped German parts :D

Planning to buy Rigol DS2072A, but maybe waiting for the hack before ordering or if no one can get that JTAG dumbed try to step in. Would be my first with JTAG so don't hold your breath.

Maybe we should put fundraising to buy one and send it to (cybernet?). 20€/25$ each would take around 40 to donate. After it gets hacked sell it in ebay and funds goes to next target. Or to hacker, but that may make him legal target as hi is profiting from the activity.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MrsR on December 20, 2013, 12:00:05 am
Hi! guys,
Well I have had no luck in updating my DS2072 to a DS 2202.
I have tried 3 FW versions. 1.0.05, 1.0.03 and 2.001.0.03 ( NOT WRITTEN PROPERLY ) but I am sure you's will know what versions I am talking about.

 ON REFLECTION :-//

A)- Has anyone done the upgrades with a RIGOL official upgrade loaded.( mine is the larger memory )

B)- I noticed that the official key has 21 numbers and the NOT official key is 16.

C)- The NOT official generated upgrade is 4 groups of 7 letter/numbers the first two 7 letter/number groups are the same for all the upgrades.

D)- The official 4- 7 letter/number groups for the memory upgrade are completely different to the official ones.

E)- I have been wondering if I used the Key number on the RIGOL upgrade site would it generate the 4-7 letter/number group.

Anyone have any suggestions what to try next.    HELP!!!!! |O
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 20, 2013, 12:13:17 am
@MrsR

Have you tried to uninstall all keys before installing a new one?
What 4 letter option did you use to generate your key?
Did you type in the correct serial number?
What key generator did you use? This one? http://riglol.3owl.com/ (http://riglol.3owl.com/)
Can you post your generated key?

It's easier to help if you post the exact procedure you used.


B)- I noticed that the official key has 21 numbers and the NOT official key is 16.
What do you mean by 16 and 21 numbers? The keys consists of 28 alphanumeric values.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 20, 2013, 12:15:02 am
A)- Has anyone done the upgrades with a RIGOL official upgrade loaded.( mine is the larger memory )

@MrsR: Yes. Upgraded to the new v.2 firmware with my official key for all options already installed - no problem. I used my serial number and the code DSEA in the Riglol key generator to generate a CAN license key. Installed with no problem. A couple of days later I did the same again using DSCA for the 300MHz option to measure waveform update rates at 1ns/div- again installed with no problem.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: van-c on December 20, 2013, 01:30:24 am
A)- Has anyone done the upgrades with a RIGOL official upgrade loaded.( mine is the larger memory )

@MrsR: Yes. Upgraded to the new v.2 firmware with my official key for all options already installed - no problem. I used my serial number and the code DSEA in the Riglol key generator to generate a CAN license key. Installed with no problem. A couple of days later I did the same again using DSCA for the 300MHz option to measure waveform update rates at 1ns/div- again installed with no problem.
Marmad:  Do you know if the firmware keeps a record of what option code (DSAZ, DSEA, DSHH, etc.) was used to enable "official" options, or does it just keep track of what options are enabled and forgets how it got there?  I have a similar case to yours before you upgraded to v.2 firmware and extended your options, except that I have HW version 2.  If I upgraded to FW v.2 and then applied DSHH (instead of DSEA followed by DSCA, as you did) do you think I would end up in essentially the same state as you, except of course for the HW version?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: wilheldp on December 20, 2013, 02:01:08 am
http://riglol.3owl.com/ (http://riglol.3owl.com/)


I've seen that site mentioned a number of times, but I can't ever get it to load.  Am I doing something wrong?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Sparky on December 20, 2013, 02:22:56 am
Rigol have updated their list of current firmware versions on their Firmware Request Page.  If it wasn't obvious that DS2000/DS2000A are going to use the same firmware moving forward, it is now.  Same goes for DS4000/MSO4000.  Would have liked to see DP832 added to this list...

Here are the latest Firmware versions by Rigol product family as of December 16th, 2013:

DS2000/DS2000A FW-Version: 00.02.01
MSO4000/DS4000 FW-Version: 00.02.00
DS6000 FW-Version: 00.01.04
DSA815 FW-Version: 00.01.07
DSA1000 FW-Version: 00.01.16
DG4000 FW-Version: 00.01.07
DG5000 FW-Version: 01.01.08
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 20, 2013, 02:29:43 am
http://riglol.3owl.com/ (http://riglol.3owl.com/)
I've seen that site mentioned a number of times, but I can't ever get it to load.  Am I doing something wrong?
Try this mirror site: http://rigol.avotronics.co.uk/mirrors/riglol/ (http://rigol.avotronics.co.uk/mirrors/riglol/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 20, 2013, 02:36:32 am
Would have liked to see DP832 added to this list...
All DS1000 series scopes are missing too: http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm (http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MrsR on December 20, 2013, 03:14:26 am
Hi! Guys,
Well I went back and tried again. same PRIVATE KEY came up.
TRIED:
DSAB    Adv. Trig.
DSAC    Decoders
DSEA    CAN Decoders
DSAS    200MHz     This is all I wanted to add mainly for the 1ns Time.
Nothing worked so I got a bit frustrated and tried DSHH.

Well I have a 300 MHz DSO with my 1ns.
Also got all the triggers. Decoders, my Trial bits turned into Official and still kept 56M memory.
I guess it was the memory that caused the problems, being overwritten most likely allowed the code to work.
Thanks again guys,

Rachael :-+

............................. 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MrsR on December 20, 2013, 03:38:50 am
 I have the A version FW as I was trying to get the latest FW. for the DS2000. and RIGOL HEAD OFFICE
lied to me and said that the 1000003 was the latest FW and If I wanted to up date I had to have the A version.

I think the A version will stop the theft of the options that we have already paid for. Well it's theft in their eyes. Not mine though I paid over$350 for the extended memory, that was already in my DSO at the time I thought I would get a board to fit into the DSO and then I got a  fancy printed page that left it to me to make sure I got the memory from RIGOL via email.

I better get back to work or I might have to fire my self 8)

CATCH YOU LATER
Rachael :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 20, 2013, 02:50:54 pm
Does anyone know what type of async memory the DS2000 has/uses?  The blackfin manual talks about 4 banks of 1M each at 0x20000000.  They configure the registers for all 4 banks although two are configured the same so I don't know if they use all four banks or not.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MrsR on December 20, 2013, 04:33:21 pm

DSAS    200MHz     This is all I wanted to add mainly for the 1ns Time.
Nothing worked so I got a bit frustrated and tried DSHH.
Hi Rachael (and all)
   Note:  DS2202 --> 200MHz only sets the fastest Timebase limit to 2nSec/Div (NOT 1nSec/div)

Thanks Len I forgot  :o

Rachael :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DL5TOR on December 20, 2013, 05:46:00 pm
Does anyone know what type of async memory the DS2000 has/uses?  The blackfin manual talks about 4 banks of 1M each at 0x20000000.  They configure the registers for all 4 banks although two are configured the same so I don't know if they use all four banks or not.

Use all 4 banks and the other banks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 20, 2013, 06:54:08 pm
Use all 4 banks and the other banks

Any idea what type of memory is attached to these banks or what it is used for?

Pages 7-20 to 7-22 cover the registers and they are set to:

EBIU_AMBCTL0 = 0xbbc3bbc3
EBIU_AMBCTL1 = 0x66ab77c3
EBIU_AMGCTL = 0x0009
Title: Re: Re: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on December 20, 2013, 10:00:54 pm
download, rename to DS4000Update.GEL -> http://www.filedropper.com/ds405xupdate (http://www.filedropper.com/ds405xupdate)

This download seems to be broken, anyone have a mirror?

I have had my DS4014 for several hours already, it desperately needs some unauthorized modification  :)

not sure on versions. Try http://rigol.avotronics.co.uk

Sent from my Nexus 4 using Tapatalk

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: apelly on December 20, 2013, 10:30:23 pm
Someone can take a better picture of the DS2xxxA's input stage?    Apelly for example.
Busy, but I'll take a look in the next 48 hrs.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 21, 2013, 04:11:48 am
If anyone with a jtag can dump 0x201e0000 to 0x20200000, I'd be interested in finding out what is there.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 21, 2013, 07:45:26 pm
Someone can take a better picture of the DS2xxxA's input stage?    Apelly for example.
Busy, but I'll take a look in the next 48 hrs.
Ok, perfect, if you can take pictures of the rest, jumpers, DC / DC ...
Thanks.  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: wilheldp on December 23, 2013, 12:39:47 am
I really apologize if this has been answered already in this thread, but I'm late to the game and pouring over 141 pages of posts is a bit daunting.  But are there firmware limitations on the use of Keygens on Rigol equipment (namely the DP832 and DS1074Z)?  For instance, do the keys not work with newer firmwares, and has anyone lost keygen activated features after upgrading the firmware on the equipment?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on December 23, 2013, 12:42:53 am
I really apologize if this has been answered already in this thread, but I'm late to the game and pouring over 141 pages of posts is a bit daunting.  But are there firmware limitations on the use of Keygens on Rigol equipment (namely the DP832 and DS1074Z)?  For instance, do the keys not work with newer firmwares, and has anyone lost keygen activated features after upgrading the firmware on the equipment?

One of the most commonly stated rules in this thread is that you should update your firmware to the latest release before you apply a keygen-created key.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: wilheldp on December 23, 2013, 01:07:53 am
One of the most commonly stated rules in this thread is that you should update your firmware to the latest release before you apply a keygen-created key.

So it's not a good idea to update the firmware until the sniffers of the I2C have figured out if it borks the keys?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on December 23, 2013, 02:19:42 am
The only firmware that was known to have a problem was the early version of the DS2000, which would cause reset serial numbers (like it did for my unit).

For DP832, I believe I may have (mis?)read that .08 has problems; use .06 to apply the keys then update.

Otherwise, yes, you want to update first.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 23, 2013, 02:23:15 am
The only firmware that was known to have a problem was the early version of the DS2000, which would cause reset serial numbers (like it did for my unit).

I used to believe the S/N could not be mangled with 00.01.01.00.02, but I was wrong.  Not sure how I did it, playing around with keys, but mine did get mangled on 00.01.01.00.02.

Thanks,

Alan
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 23, 2013, 02:30:13 am
Does anyone remember from the teardown how much SDRAM is present?  64M or 128M?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 23, 2013, 03:25:25 am
Does anyone remember from the teardown how much SDRAM is present?  64M or 128M?

(https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/?action=dlattach;attach=72790)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 23, 2013, 04:22:40 am
Thanks marmad, do you know if the teardown is consistent with this information, sometimes their documentation doesn't match up.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JLM on December 23, 2013, 05:45:03 am
Is it really a 300 mHz scope?  My former 2072 tells me it has been transformed into a 2302, but I am wondering if anyone has tested the machine to see if it really performs as a 300 MHz scope?  I find it hard to believe that firmware/software alone can turn an $800 device into one costing nearly triple.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mtdoc on December 23, 2013, 05:52:27 am
Um, read the last few weeks of this thread......

The short answer is yes.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: staze on December 23, 2013, 05:53:22 am
Yes, I has been tested. Yes, they're 300Mhz (if only barely (like, 315Mhz)). Check a few pages back. :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: A Hellene on December 23, 2013, 06:24:23 am
Quote
I find it hard to believe that firmware/software alone can turn an $800 device into one costing nearly triple.
Well, it is a marketing trick, euphemistically called 'scalability' where by changing the product key only, we can have multiple levels of functionality (and cost, of course) from the same product, like the Windows 7 Ultimate/Enterprise/Professional/Home/Starter installations. But, this is more like designing a 6-core i7 CPU and selling the bad i7 chips (with a defective core, for example) as 4-core i7 CPUs after disabling two cores, or as proud 2-core i3 CPUs the even more crippled ones instead of recycling the bad dies...

For example, we design a 300 MHz device using cheap components (to maximise our profits) and by testing each one of these the best performers are labeled 300 MHz units, while the ones that perform up to 200 MHz are labeled 200 MHz units, and so on. Read this message (https://www.eevblog.com/forum/blog/changing-the-rigol-ds1052e-to-ds1102e-using-usb-the-dummy-guide/msg191235/#msg191235) to understand how it works.


-George
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: staze on December 23, 2013, 06:44:28 am
Indeed. Or, you can design to 300Mhz, skip that testing and assume that most users won't hack their devices, and still turn a profit quite easily. The BOM for the 2072 still turns a profit, even more so if people buy the higher versions, or options. Like you say, much like Windows, or Office versions. Heck, AMD and Intel have done this too with chips... Remember the "jumpers" on the CPU substrate? Overclocking was so easy back then. Or just disabling a core or two via software. :/

Given the tests most have done so far, it seems like Rigol are probably skipping that assessment. Just QA, serialize, label, ship. This is much cheaper than doing assessment, and you still turn a profit. The front end filters would seem to indicate that. But, unless someone has a 2072 hacked AND a "real" 2302/2202, it seems unlikely we'll be able to confirm either. :/
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JDubU on December 23, 2013, 07:09:17 am
Another well known example was the multi-million dollar General Electric 600 series mainframe computers in the 1960's.  There were different models, with a significant spread in performance and cost.  The only difference between three of the models was the position of some wire wrapped jumpers on the backplane.

http://en.wikipedia.org/wiki/GE-600_series (http://en.wikipedia.org/wiki/GE-600_series)

"... The 600 line consisted of six models: the 605, 615, 625, 635, 645, and 655.
The 615 was a 635 with Control Unit (CU) and Operations Unit (OU) overlap disabled, and a 36 bit wide memory path. The 625 was a 635 with Control Unit and Operations Unit overlap disabled and 72 bit wide memory path. The 635 had a 72-bit wide memory path and CU/OU overlap enabled. The difference between these models was less than 10 wires on the backplane. Field service could convert a 615 to a 635 or 625 or vice versa in a couple of hours if necessary;other than those few wires, the 615, 625 and 635 were identical. The 605 was used in some realtime/military applications, and was essentially a 615 without the floating point hardware. Programs coded for a 605 would run without any modification on any other 600 line processor"
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: apelly on December 23, 2013, 07:53:08 am
Someone can take a better picture of the DS2xxxA's input stage?    Apelly for example.
Busy, but I'll take a look in the next 48 hrs.
Ok, perfect, if you can take pictures of the rest, jumpers, DC / DC ...
Thanks.  :-+
No susprises.

These will have to do for now... The 'scpoe's still open, so can take more, but even a linux buff like me needed to look up a quick way to resize pics.

Just let me know what you want to see.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: fcab100 on December 23, 2013, 08:45:51 am
Someone can take a better picture of the DS2xxxA's input stage?    Apelly for example.
Busy, but I'll take a look in the next 48 hrs.
Ok, perfect, if you can take pictures of the rest, jumpers, DC / DC ...
Thanks.  :-+
No susprises.

These will have to do for now... The 'scpoe's still open, so can take more, but even a linux buff like me needed to look up a quick way to resize pics.

Just let me know what you want to see.


Can you take pics of the jumper resistor divider just by the battery. Thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: EV on December 23, 2013, 09:12:40 am
The scope I used in the test was originally 200 MHz scope DS2202.

Quote
I find it hard to believe that firmware/software alone can turn an $800 device into one costing nearly triple.
Well, it is a marketing trick, euphemistically called 'scalability' where by changing the product key only, we can have multiple levels of functionality (and cost, of course) from the same product, like the Windows 7 Ultimate/Enterprise/Professional/Home/Starter installations. But, this is more like designing a 6-core i7 CPU and selling the bad i7 chips (with a defective core, for example) as 4-core i7 CPUs after disabling two cores, or as proud 2-core i3 CPUs the even more crippled ones instead of recycling the bad dies...

For example, we design a 300 MHz device using cheap components (to maximise our profits) and by testing each one of these the best performers are labeled 300 MHz units, while the ones that perform up to 200 MHz are labeled 200 MHz units, and so on. Read this message (https://www.eevblog.com/forum/blog/changing-the-rigol-ds1052e-to-ds1102e-using-usb-the-dummy-guide/msg191235/#msg191235) to understand how it works.


-George
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: A Hellene on December 23, 2013, 09:37:37 am
The scope I used in the test was originally 200 MHz scope DS2202.
No doubt about that! I believe that most of the 72 MHz units must be able to display decently any 250-300 MHz signals.

What I said before is that, in order to minimise the development/manufacturing costs, the manufacturer designed one only device and sells it in three or four bandwidth levels. Of course, I am sure that the top-notch 300 MHz models are being tested thoroughly before they get labeled as such; all the rest of devices at the assembly line are being branded depending on the market demands of the time they hit the market. This way, a 72 MHz device can perform decently at higher bandwidths (if hacked, of course).

BUT: At the link in my previous message, the member Alex33 measured a bandwidth of 90 MHz on a 50 MHz device, a DS1052: That would be no problem for a device sold as a 50 MHz bandwidth one; but that limited bandwidth of 90 MHz of that specific device would restrict that very device to be sold as a DS1102 or a DS1152 of 100 or 150 MHz, respectively.


-George
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: elecBlu on December 23, 2013, 11:02:23 am
DS2000 input stage is specified for that 300MHz BW, so there should be no "selection" at all for any Scope Model/BW. The other hardware (ADC) remains at the same specification for all models.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Pehtoori on December 23, 2013, 12:03:12 pm
DS2000 input stage is specified for that 300MHz BW, so there should be no "selection" at all for any Scope Model/BW. The other hardware (ADC) remains at the same specification for all models.

Yes for components and design, but will all DS2072 work as DS2302? There is no guarantee as they might not be tested for 300MHz. What I see "A Hellene" is trying to say. There might be defective soldering, PCB or component and Rigol has noticed this in testing and labelled device as DS2072 if it meets DS2072 specifications.

I'm or "A Hellene" is not saying, that this is the case, but its clearly possibility.

(Note this is only my interpretation of A Hellene, not what she/he says)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on December 23, 2013, 12:12:53 pm
btw, what's the current state of A-model reversing? ^^
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Pehtoori on December 23, 2013, 12:36:24 pm
btw, what's the current state of A-model reversing? ^^

Waiting for JTAG dump...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on December 23, 2013, 12:58:17 pm
so barnacle2k disappeared? ^^;
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 23, 2013, 01:03:45 pm
What I said before is that, in order to minimise the development/manufacturing costs, the manufacturer designed one only device and sells it in three or four bandwidth levels. Of course, I am sure that the top-notch 300 MHz models are being tested thoroughly before they get labeled as such; all the rest of devices at the assembly line are being branded depending on the market demands of the time they hit the market. This way, a 72 MHz device can perform decently at higher bandwidths (if hacked, of course).

BUT: At the link in my previous message, the member Alex33 measured a bandwidth of 90 MHz on a 50 MHz device, a DS1052: That would be no problem for a device sold as a 50 MHz bandwidth one; but that limited bandwidth of 90 MHz of that specific device would restrict that very device to be sold as a DS1102 or a DS1152 of 100 or 150 MHz, respectively.
Yes for components and design, but will all DS2072 work as DS2302? There is no guarantee as they might not be tested for 300MHz. What I see "A Hellene" is trying to say. There might be defective soldering, PCB or component and Rigol has noticed this in testing and labelled device as DS2072 if it meets DS2072 specifications.

I'm or "A Hellene" is not saying, that this is the case, but its clearly possibility.
@George & Pehtoori : But you can't compare the DS2000 series with the old DS1000 series. With the DS2000 series, Rigol has ALWAYS had the intention of selling software bandwidth upgrades for the models. This is evidenced by the fact that Drieg (a Rigol dealer) mentioned that Rigol was planning to do this back in October of 2012 (https://www.eevblog.com/forum/blog/eevblog-360-rigol-ds2000-oscilloscope-teardown/msg154787/#msg154787), and also by the fact that with the FW release 01.00.00.03 (IIRC), the software bandwidth upgrades were functionally operative. As we all know, labor is cheap in China - so with their original intentions plus cheap labor, I can't imagine that all of the DSOs in the series don't go through the exact same testing procedures/standards.

Now why Rigol hasn't actually started selling the bandwidth upgrades is another, perhaps more interesting, question. I suspect it has to do with the relative lack of competition at the DS2000's price point - although perhaps this will change with the full-scale release of the Siglent SDS2000 series in the near future.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JLM on December 23, 2013, 01:32:59 pm
After upgrade, my options list shows both "200 MHz bandwidth" and "300 mhz bandwidth".  Is that normal?  Can I and should I delete the 200, and if so, how?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 23, 2013, 03:57:21 pm
After upgrade, my options list shows both "200 MHz bandwidth" and "300 mhz bandwidth".  Is that normal?  Can I and should I delete the 200, and if so, how?
In my case the same, I do not know if this can be a problem.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 23, 2013, 03:58:50 pm
After upgrade, my options list shows both "200 MHz bandwidth" and "300 mhz bandwidth".  Is that normal?  Can I and should I delete the 200, and if so, how?

Did you use DSGH ?  That should have 300/can/trig/decod/56m
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 23, 2013, 03:59:48 pm
One of the memory registers does confirm 32M of SDRAM for program memory (0x00000000 - 0x01ffffff).

The blackfin also has 4 async memory areas mapped at: 0x20000000-0x200fffff, 0x20100000-0x201fffff, 0x20200000-0x202fffff, 0x20300000-0x203fffff.  I can see some memory pointers pointing to 0x201exxxx, 0x2020xxxx, 0x2024xxxx.

Each of these is only a 1M range.  How are these async memory areas normally used?  When more than 1M is available it is banked somehow?  I don't see any banking capability in the blackfin for this unless I am missing something.

Could the aquire memory (ddr2) also be accessed via this async memory?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 23, 2013, 04:13:31 pm
These will have to do for now... The 'scpoe's still open, so can take more, but even a linux buff like me needed to look up a quick way to resize pics.
Just let me know what you want to see.
Thank you so much, the parts in which I am interested are these:

https://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0/msg270218/#msg270218 (https://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0/msg270218/#msg270218)
https://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0/msg272842/#msg272842 (https://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0/msg272842/#msg272842)

Cheers.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: m-joy on December 23, 2013, 05:48:07 pm


Did you use DSGH ?  That should have 300/can/trig/decod/56m
[/quote]

I thought DSHH should be used...?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 23, 2013, 05:52:36 pm
DSHH includes a bit no one knows what it does.  DSGH is all bits that are known for 300mhz,can,trig,mem,decode

GH = 00110 00111
HH = 00111 00111
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: m-joy on December 23, 2013, 06:02:26 pm
DSHH includes a bit no one knows what it does.  DSGH is all bits that are known for 300mhz,can,trig,mem,decode

GH = 00110 00111
HH = 00111 00111

Lol the magic bit =) and What about 200mhz for the DSGH combination?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 23, 2013, 06:05:19 pm
Lol the magic bit =) and What about 200mhz for the DSGH combination?

Neither the 200m or 100m are set in the final "H".  I'm not so sure it is a good idea to set any of the bandwidth ones together, then again I'm not so sure it matters either.  But 300M on its own works so that is the simplest.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: m-joy on December 23, 2013, 06:10:32 pm
Lol the magic bit =) and What about 200mhz for the DSGH combination?

Neither the 200m or 100m are set in the final "H".  I'm not so sure it is a good idea to set any of the bandwidth ones together, then again I'm not so sure it matters either.  But 300M on its own works so that is the simplest.

Thx. So What is the hex code for all Options and 300mhz but no 200mhz?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 23, 2013, 06:15:10 pm
Thx. So What is the hex code for all Options and 300mhz but no 200mhz?

I'm using DSGH:  00011 10000 00110 00111

Note the 0's between the 3rd and 4th group.  The last 0 of the third group is the unknown bit.  The first two 0's of the fourth group are the 200m and 100m that are not needed.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: m-joy on December 23, 2013, 06:25:17 pm
[Thx. So What is the hex code for all Options and 300mhz but no 200mhz?
SYSTEM:OPTION:UNINSTALL

first
"first"?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: apelly on December 23, 2013, 06:29:56 pm
Thank you so much, the parts in which I am interested are these:

https://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0/msg270218/#msg270218 (https://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0/msg270218/#msg270218)
https://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0/msg272842/#msg272842 (https://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0/msg272842/#msg272842)
Sorry about the quality.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on December 23, 2013, 06:32:03 pm
did you jtag dump the device?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 23, 2013, 06:38:19 pm
Sorry about the quality.
No problem. Thanks again.

In the input stage they also change a bipolar trt!!! What is the SMD marking code? R2W..? -> BFR93A?

(https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/?action=dlattach;attach=72856;image)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 23, 2013, 06:52:44 pm
I think that the input stage was improved, and probably it reach more than 350 MHz.

Will there any v1.0.x.. HW with some of these changes?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: apelly on December 23, 2013, 06:54:28 pm
did you jtag dump the device?
No bus blaster yet. Will check the mail today. Xmas has stuffed postage in this part of the world.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 23, 2013, 06:56:34 pm
Jumpers:

HW v1.0:
(https://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0/?action=dlattach;attach=56798;image)

A or v2.0:
(https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/?action=dlattach;attach=72850;image)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 23, 2013, 06:58:20 pm
Mode 0 and Mode 1?
Also in version 1.0, but for what are they? USB mode? DSP?

(https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/?action=dlattach;attach=72858;image)


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: apelly on December 23, 2013, 07:06:54 pm
In the input stage they also change a bipolar trt!!! What is the SMD marking code? R2W..? -> BFR93A?
This might be a better pic. JPEG compression instead of scaling.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on December 23, 2013, 07:08:11 pm
Oooh, jumpers! Should I?  :-/O
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 23, 2013, 07:09:23 pm
No bus blaster yet. Will check the mail today. Xmas has stuffed postage in this part of the world.

The one you ordered ~4 weeks ago which was supposed to arrive 'in a week or so'?  Somebody is screwing with you... ;)

Then again, perhaps New Zealand is the last stop for Worldwide mail... ;D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 23, 2013, 07:16:04 pm
This might be a better pic. JPEG compression instead of scaling.
A lot better. Thanks.  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 23, 2013, 07:19:16 pm
The one you ordered ~4 weeks ago which was supposed to arrive 'in a week or so'?  Somebody is screwing with you... ;)

Then again, perhaps New Zealand is the last stop for Worldwide mail... ;D
The China-Spain mail takes about 3 weeks to a month.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on December 23, 2013, 07:24:37 pm
same here, my orders from seeed usually takes around 3 weeks to Norway, it's free or almost free, so I don't complain.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: apelly on December 23, 2013, 07:28:50 pm
No bus blaster yet. Will check the mail today. Xmas has stuffed postage in this part of the world.

The one you ordered ~4 weeks ago which was supposed to arrive 'in a week or so'?  Somebody is screwing with you... ;)

Then again, perhaps New Zealand is the last stop for Worldwide mail... ;D
Last time I looked at the tracking number (a week or two ago) the bloody thing was in Europe somewhere. uRuler anyone?

Edit:
Misread last time apparently. Shipped by Swiss post. There seems to be no tracking info available. I will follow up after I have checked the mail today.

And you were correct marmad: I did order the bloody thing around a month ago. Time flies.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 23, 2013, 07:35:47 pm
Another issue:
The oscilloscope flash probably contain calibration values closely associated with all the characteristics of input stage (a kind of fine settings adjustments). Something like the attached file (from Owon SDS oscilloscopes). So, modify the input stage may not be a good idea.

Or am I wrong?  :-//
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 23, 2013, 07:41:13 pm
@ apelly:

Have you read this?
https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg350129/#msg350129 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg350129/#msg350129)

Maybe my method (TopJTAG Flash Programmer) to download the flash is not valid for hacking. Cybernet should know better.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: apelly on December 23, 2013, 07:50:31 pm
Have you read this?
https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg350129/#msg350129 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg350129/#msg350129)

Maybe my method (TopJTAG Flash Programmer) to download the flash is not valid for hacking. Cybernet should know better.
Yes.

Figured I'd cross that bridge when I came to it.

Frankly, I'm surprised nobody else has beaten me to it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 23, 2013, 07:54:33 pm
Have you read this?
https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg350129/#msg350129 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg350129/#msg350129)

Yes.
Figured I'd cross that bridge when I came to it.
Frankly, I'm surprised nobody else has beaten me to it.
LOL...
They are waiting for someone to do it for them.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Pehtoori on December 23, 2013, 09:05:39 pm
Figured I'd cross that bridge when I came to it.
Frankly, I'm surprised nobody else has beaten me to it.
LOL...
They are waiting for someone to do it for them.

Or "they" don't have skill to do it, don't have it yet or don't have job so can't lose warranty from 850€ equipment.
I tick at least last 2 of them atm  :-\
Thats why I suggested fundraising to get one to be hacked. I would happily put >=20€  for it... 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 23, 2013, 09:20:57 pm
Or "they" don't have skill to do it, don't have it yet or don't have job so can't lose warranty from 850€ equipment.
I tick at least last 2 of them atm  :-\
Thats why I suggested fundraising to get one to be hacked. I would happily put >=20€  for it...

Have you just tried downgrading to FW v.01.01.00.02 then using Riglol keygen (for all Trigger, Decode, and Memory options)? The worst that could happen is scope might get frozen - but it's still under warranty (and they would never know what happened). But since the DSO has a bootloader (and since HW v.2 owners have upgraded and downgraded) - and NO ONE has ever managed to brick one of these DSOs (AFAIK) - it's highly unlikely that would happen, so a more likely worst-case scenario is that it just won't downgrade - or the keygen won't work even when downgraded.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: elecBlu on December 23, 2013, 09:28:05 pm
Thats why I suggested fundraising to get one to be hacked. I would happily put >=20€  for it...

not a bad idea, but my guess is that there are way too less people who want to spent >20€/$ for that.
Even the number of guys around here who hacked their scope and still following this thread seems to be relatively small.

I could do some more signal-generator measurements on my 2.0 HW DS2072 (look 10 pages back), but it seems that my generator drops the output amplitude significantly with frequency (compared to 500MHz scope), so it doesn't look that reliable at the moment. Someone with a known-good generator is needed, maybe we can compare directly. I really don't want to publish these cutoff-freqency measurements at that moment, although it looked like 2.0 HW brings way more that the 315MHz at my scope.
Plus, we still need high-res pictures of DS2072 2.0 HW input stages for last proof if it is the same as DS2072A. Maybe I will do this in some time, the thing with the warranty seal seems to be
feasible.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neamyalo on December 23, 2013, 09:59:13 pm
I think I can help out.

I bought a 2072A a couple of weeks ago and thanks to cybernet's JTAG pinout :-+ , I currently have it open on my bench with urjtag connected to the BF256  :D

I should have a memory dump pretty soon...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on December 23, 2013, 10:11:21 pm
that's great :)
I forgot the jtag at work and it also seems like it's not as easy to read out (as I thought ... need of linux, adapter ...)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: apelly on December 23, 2013, 10:15:09 pm
Have you just tried downgrading to FW v.01.01.00.02 then using Riglol keygen (for all Trigger, Decode, and Memory options)? The worst that could happen is scope might get frozen - but it's still under warranty (and they would never know what happened). But since the DSO has a bootloader (and since HW v.2 owners have upgraded and downgraded) - and NO ONE has ever managed to brick one of these DSOs (AFAIK) - it's highly unlikely that would happen, so a more likely worst-case scenario is that it just won't downgrade - or the keygen won't work even when downgraded.
I was going to give this a go, but it was pointed out that a pristine dump might be of more initial value. I'll try once there is a firmware dump.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Pehtoori on December 23, 2013, 11:01:19 pm
Or "they" don't have skill to do it, don't have it yet or don't have job so can't lose warranty from 850€ equipment.
I tick at least last 2 of them atm  :-\

Have you just tried downgrading to FW v.01.01.00.02 then using Riglol keygen (for all Trigger, Decode, and Memory options)?

"I tick at least last 2", one of them was "don't have it (the scope) yet" :-DD (ok bit tired)

But when I get one hopefully in month or two, thats what I'm going to do for it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on December 23, 2013, 11:15:19 pm
Mode 0 and Mode 1?
(https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/?action=dlattach;attach=72858;image)

likely the BMODE pins of the BFIN - toggle between flash/spi boot - where spi is what they use to flash the bootldr - one of my first posts in that thread was regarding bmode pins.
if somebody wants to mess with them with boundary scan u can check the bfin pins logic levels nicely.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neamyalo on December 23, 2013, 11:39:25 pm
I'm getting an error each time I try and dump the memory contents..

Code: [Select]
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i586-mingw32msvc --target=bfin-elf".
(gdb) target remote :2000
Remote debugging using :2000
0x0011debc in ?? ()
(gdb) info mem
Using memory regions provided by the target.
Num Enb Low Addr   High Addr  Attrs
0   y   0x20000000 0x20400000 rw nocache
1   y   0xef000000 0xef008000 ro nocache
2   y   0xff800000 0xff804000 rw nocache
3   y   0xff804000 0xff808000 rw nocache
4   y   0xff900000 0xff904000 rw nocache
5   y   0xff904000 0xff908000 rw nocache
6   y   0xffa00000 0xffa0c000 rw nocache
7   y   0xffa10000 0xffa14000 rw nocache
8   y   0xffb00000 0xffb01000 rw nocache
9   y   0xffc00000 0xffe00000 rw nocache
10  y   0xffe00000 0x100000000 rw nocache
(gdb) dump binary memory dump.bin 0x20000000 0x20400000
Ignoring packet error, continuing...
Reply contains invalid hex digit 116
(gdb)

I've tried reducing the JTAG freq from 6MHz down to 60kHz, but there's no difference..

I'm running 2013R1 release on Windows and I can successfully dump 1K, but >= 2K and I get the error and no dump file.  >:(
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: m-joy on December 23, 2013, 11:50:41 pm
Huhu, maybe the cable lengh too large which might cause data loss? Thats what cybernet state on post 2082
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neamyalo on December 23, 2013, 11:51:46 pm
It looks like setting the remotetimeout to 10 has solved it.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 24, 2013, 12:24:06 am
It looks like setting the remotetimeout to 10 has solved it.

Do you have the dump yet?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 24, 2013, 01:44:56 am
Sorry about the quality.
No problem. Thanks again.

In the input stage they also change a bipolar trt!!! What is the SMD marking code? R2W..? -> BFR93A?

(https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/?action=dlattach;attach=72856;image)

Analog Devices ADR5044A (4.096 V Precision Micropower Shunt Mode Voltage Reference) has a R2W marking on it. (See bottom of page 14): http://www.analog.com/static/imported-files/data_sheets/ADR5040_5041_5043_5044_5045.pdf (http://www.analog.com/static/imported-files/data_sheets/ADR5040_5041_5043_5044_5045.pdf)

http://www.analog.com/ADR5044 (http://www.analog.com/ADR5044)
(http://www.analog.com/static/imported-files/images/pin_diagrams/ADR5040_5041_5043_5044_5045_pcl.png)

Not sure if any other devices has the same R2W marking on them too or not.

(https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/?action=dlattach;attach=72860;image)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neamyalo on December 24, 2013, 11:06:16 am
I'm having a few issues with my JTAG probe and urJtag (using a J-Link on Windows)

I captured the main region from 0x20000000 - 0x20400000, and a few others too, but then the JTAG link hung for some reason and I had to reboot the scope trying to get things talking again, so will need to start again.

Anyway, here is what I managed to get.....

Scope was fully booted and running (its an untouched DS2072A).

SW/FW details are:
- SW 00.02.00.00.04
- HW 1.0.2.0.2
- FPGA:
--- SPU 03.01.09
--- WPU 00.07.01
--- CCU 12.29.00
--- MCU 02.13
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on December 24, 2013, 12:36:31 pm
Well, I changed the jumper settings on my non-A version 2 hardware to reflect the -A settings (moved one resistor from the upper row to the lower row), but I can't find anything that has changed. The 50 Ohm is still greyed out and the model is still non-A. It has the latest software, and I tried booting with left-F6. Maybe it needs a factory reset, but I'm not sure how to do that.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 24, 2013, 01:08:04 pm
neamyalo you have my thanks!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neamyalo on December 24, 2013, 01:20:45 pm
It turns out that my JLink/urjtag connection is not hanging, instead its just going really really slow  :=\
I've set the frequency to 6 MHz, but its so slow its more like a few kHz (I would check with my scope but the CPU is halted....)

The main problem is the SDRAM - I'm currently trying to dump the full SDRAM address space (128 MB) and its only 1% through after 30 minutes - its going to take too long.... (50hrs?)

On the board it looks as though there's only a single 32 MB SDRAM chip connected to the bf526. I'm gonna assume that its address range is 0x0000 0000 to 0x01FF FFFF and limit the SDRAM dump to that instead.

Sorry for the bad news, but I'm goin to persevere and will let you know how it goes.

If anyone has a J-Link running with urjtag at a decent speed let me know!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Fagear on December 24, 2013, 01:51:39 pm
I have something to say here.
Recently I bought my DS2072A (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg349993/#msg349993).

It had FW v00.02.00.00.04. Then I updated it to v00.02.01.00.03.
Today I tried some keygens (three of them), and none worked.

So...
Have you just tried downgrading to FW v.01.01.00.02 then using Riglol keygen (for all Trigger, Decode, and Memory options)? The worst that could happen is scope might get frozen - but it's still under warranty (and they would never know what happened).
I have done it. :-/O
1) Copied v00.01.01.00.02 FW file to USB stick.
2) Reflashed device using Power on -> Help -> USB stick (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684) sequence.
3) Cleared FRAM during first boot.
And got this (serial # stays intact):
(https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/?action=dlattach;attach=72931;image)

Then I used synapsis's Windows GUI keygen. Entered serial # of my device (last letter was left blank) and private key. Randomly generated seed 1333118342.
And generated license key with DSAZ. I have entered license key with on-screen-keyboard (also all of them later).
And TA-DA!!! It worked!  8)
(https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/?action=dlattach;attach=72933;image)

I had rebooted the 'scope and model number changed to DS2202A, I've got 2 ns timebase and all options stayed in place!
(https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/?action=dlattach;attach=72935;image)

But then I tried to generate and enter DSEA and DSCA options (CAN Decoder and 300MHz) it said "Failed to install option,please ensure the License valid!". Then I tried DSHH with the same result. :( I also tried to generate keys with command-line Riglol 1.03c but result was the same.

I decided to switch back to the last v00.02.01.00.03 FW. Reflashed 'scope with same procedure successfully (serial # still intact).
(https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/?action=dlattach;attach=72937;image)

But this action cleared off all of the options! :( "Installed" option is greyed out. And I tried to install all previuosly generated keys and also some generated with another seed. But answer was the same all the time: "License is unavailable!".
But model number DS2202A stayed in place along with 2 ns timebase and "OFF/20M/100M" BW limit option.

Again, I reflashed the device to older v00.01.01.00.02 FW and all options magically apeared again!
But I don't want to use older FW and reflashed the device with v00.02.01.00.03 again, but this time I did it through GUI (inserted USB stick, 'scope asked me if I want to update the FW, I pressed "Update") and did not cleared FRAM during first boot. But options were gone once again (and all of my trial time as well). :(

Channels' "1M/50" input impedance option was always available (as it was when I bought my DS2072A) on all tested FWs and with all options.

Options with v00.01.01.00.02 FW:
(https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/?action=dlattach;attach=72939;image)

Options with v00.02.01.00.03 FW:
(https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/?action=dlattach;attach=72941;image)


So, the conclusion:
1) You can hack your DS2xxxA oscilloscope!
2) To get all options except of 300 MHz and CAN decoding - switch to older FW v00.01.01.00.02 and apply DSAZ key.
3) If you do not want to use old FW all you can get now - BW up to 200 MHz. For it you must go to older FW v00.01.01.00.02, apply code for 200 MHz (I used old "all options" DSAZ) and then switch back to latest FW.

In my case serial # was not damaged.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 24, 2013, 06:10:20 pm
So, the conclusion:
1) You can hack your DS2xxxA oscilloscope!
2) To get all options except of 300 MHz and CAN decoding - switch to older FW v00.01.01.00.02 and apply DSAZ key.
3) If you do not want to use old FW all you can get now - BW up to 200 MHz. For it you must go to older FW v00.01.01.00.02, apply code for 200 MHz (I used old "all options" DSAZ) and then switch back to latest FW.

In my case serial # was not damaged.

Good to know - thanks for all the testing you did. I suspected that was what might happen (i.e. losing the options with the upgrade back to FW v.2), although I never thought you'd keep the 200MHz option - so there was at least one bonus for all the time spent.  :)

BTW, CAN and 300 MHz options are ONLY available in FW >= v.2 - so it will always be impossible for any DS2000 owner (A or non-A) to activate those at FW.01.01.00.02 or below.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 24, 2013, 06:16:45 pm
I want the trial minutes to run out on my scope - what was the method to lose the trial again?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 24, 2013, 06:33:30 pm
What happens if a key created by using DSHH is used with earlier versions of the firmware on a DS2000A?  Does it reject the key?
If it accepts it, are all the options then enabled after updating the firmware to the latest?

It won't accept more than the last 6 bits set (no can, no 300)...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 24, 2013, 06:49:25 pm
I want the trial minutes to run out on my scope - what was the method to lose the trial again?
@alank2
why would you want that?

I was doing some testing and ended up with >6000 trial minutes but I want it out of trial mode now and don't want to wait...

00.01.00.00.03 + self cal did not do it.  Trying 00.00.01.00.05.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Fagear on December 24, 2013, 07:00:33 pm
I want the trial minutes to run out on my scope - what was the method to lose the trial again?
Maybe installing some "official" options and then removing them will do the trick? :-//
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JDubU on December 24, 2013, 07:01:21 pm
I want the trial minutes to run out on my scope - what was the method to lose the trial again?
@alank2
why would you want that?

I was doing some testing and ended up with >6000 trial minutes but I want it out of trial mode now and don't want to wait...

00.01.00.00.03 + self cal did not do it.  Trying 00.00.01.00.05.

Does SCPI command    ":SYSTem:OPTion:UNINSTall"  not work to do that?
 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 24, 2013, 07:03:48 pm
No, if you have an ongoing trial, it will come back (if it hasn't run out) when keys are uninstalled.  I got it, but it took the very old 00.00.01.00.05 + self cal to do it.

I can see from the memory dump where SN is located and it is guarded by a crc32.  My goal is to try to return my unit's SN and correct model, still working on that, but at least I know what needs to change now.

My theory is that the reason the SN is lost is because something buggy happens and the block that contains it has a bad crc and then the scope regenerates the block and rewrites a good one, with the mangled SN.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 25, 2013, 02:52:53 am
Did you notice that  S/N = DS2A0000000001 is one digit longer than normal?
DS2Ayyww123456 is that an Overflow bug error

Absolutely - I've always thought it was likely some sort of bug that they made it one digit longer, but who knows, could be a reason for it.

Interestingly the user's posted memory dump showed 4 recorded keys entered and I wonder if those keys are somehow the method the model and sn are loaded originally.  It records as many as 7 trial keys to prevent the user from entering the same trial extension key more than once.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 25, 2013, 12:51:13 pm
Some changes in the input stage (resistor and trt) from NON-A to A (in Black HW 2.0 NON-A):

(https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/?action=dlattach;attach=73041;image)

I guess that they have also changed some capacitors. Any volunteers to measure their value?
Note: Resistor without marking code -> unknown value.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 25, 2013, 01:04:06 pm
Analog Devices ADR5044A (4.096 V Precision Micropower Shunt Mode Voltage Reference) has a R2W marking on it. (See bottom of page 14):

...

Not sure if any other devices has the same R2W marking on them too or not.


Impossible. Must be a NPN trt. I'm pretty sure that is a BF93A (R2*).

* = p -> made in Hong kong.
* = w -> made in china.




Other possibilities (NPN and SOT23 only):
http://www.ecadata.de/searchnew/index2.html (http://www.ecadata.de/searchnew/index2.html)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 25, 2013, 01:08:25 pm
Mode 0 and Mode 1?

...

Likely the BMODE pins of the BFIN - toggle between flash/spi boot - where spi is what they use to flash the bootldr - one of my first posts in that thread was regarding bmode pins.
if somebody wants to mess with them with boundary scan u can check the bfin pins logic levels nicely.
Maybe I read it. I no longer remember.
Sorry.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Wim13 on December 25, 2013, 04:11:59 pm
Also posted in the main Rigol topic, but for the others, i updated my bandwidth chart with the 300 Mhz option.
There is not much enhancement for the non A models. Even worse, it not very stabel the 300 Mhz
option . That is i think why Rigol never sold 300 Mhz versions of the non A.

Some others also measured, and there are differences around 1 dB, which is normal
for devices at the end of there capabilities. These measurements are all made on the same 2072.

So i will stay for DSEZ, the E for CAN and the Z for DS2202 with al options.

Edit: the bandwidth is measured only on hardware version 1.0.1.0.0
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 25, 2013, 04:19:44 pm
Even worse, it not very stabel the 300 Mhz option.

Can you expand on this a bit?  What was not stable?

I looked at my other 2072 which has been untouched until now.  It has 3 keys VSAB, VSAC, and VSAE to load the trial options, so my theory that the SN/model are loaded with keys is false.  The 4 keys for the unit that was dumped here probably includes a can trial too which explains the extra key.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: m-joy on December 25, 2013, 04:27:45 pm


So i will stay for DSEZ, the E for CAN and the Z for DS2202 with al options.

Huhu. So DSEZ does enable 200Mhz and all options including CAN but no 300Mhz.?

Greets
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: staze on December 25, 2013, 04:29:22 pm
And remind us, is this the 2072 hw 1 or hw 2?

And did you self-cal with each of these bandwidths?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Wim13 on December 25, 2013, 04:57:47 pm

The entry chip LMH6518, has to the datasheet several options, 200 ,350 or 650 Mhz.

as far i can see for 200 Mhz DS2202, it has already open the 350 mode. I dont
think Rigol has used the 650 Mhz option. But only stretched the gain for 350 Mhz to
get the 300 Mhz bandwidth, which gives on the old models not the correct functionality.

See chart below from the datasheet,
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on December 25, 2013, 09:50:59 pm
*bump* Anyone having an idea how to convert a non-A model into an A? I also tried 'samegrading" (using the same latest software update), but again no difference. What I am after is the switchable 50 ohm input, I don't think there is much difference between the A and non-A models apart from that.

Well, I changed the jumper settings on my non-A version 2 hardware to reflect the -A settings (moved one resistor from the upper row to the lower row), but I can't find anything that has changed. The 50 Ohm is still greyed out and the model is still non-A. It has the latest software, and I tried booting with left-F6. Maybe it needs a factory reset, but I'm not sure how to do that.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: elecBlu on December 25, 2013, 10:14:03 pm
Can you expand on this a bit?  What was not stable?

his frequency response of the 300MHz option is not nearly as flat as it could be, look at his chart. But, as far as i remember, he has HW 1.0.
If that chart looks the same for HW 2.0, you better leave it at 200MHz.

Interesting to see that the A Models are not identical with HW2.0. So we have at least 3 different input stages out there.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigol-Friend on December 25, 2013, 11:09:09 pm
is the switchable 50 ohm input

Bad idea:
Quick and dirty you can have 50 ohm impedance by activating the relay for the 50 ohm resistor with a mechanical switch. If your hardware is version 2, relay and resistor are build in.

That will be not elegant, but will work, I think.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: m-joy on December 25, 2013, 11:23:09 pm
I cant understand whats so special about the 50 ohm impedanz. You can easily get a T-connnector with 50ohm Terminator so whats the point.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gallymimus on December 26, 2013, 01:33:54 am
I cant understand whats so special about the 50 ohm impedanz. You can easily get a T-connnector with 50ohm Terminator so whats the point.

It's a lot more convenient than using an external adapter, why are you trolling?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Wim13 on December 26, 2013, 09:10:10 am
I cant understand whats so special about the 50 ohm impedanz. You can easily get a T-connnector with 50ohm Terminator so whats the point.

There is a very big difference, if you terminate directly on the chip entry, or on the BNC connector,
gives a lot of impedance changes.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Wim13 on December 26, 2013, 09:14:59 am

Can you expand on this a bit?  What was not stable?



You can see on 1 nsec the DS2000 hw version 1.01.1 has difficulties display the correct waves,
it also differs when you switch two channels on, the signals changes...so not reliable.

DS2000 old version where never designed to work behind 200 Mhz. The hardware had to be modified,
as they did on later models.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: clifford on December 26, 2013, 10:13:00 am
I cant understand whats so special about the 50 ohm impedanz. You can easily get a T-connnector with 50ohm Terminator so whats the point.

There is a very big difference, if you terminate directly on the chip entry, or on the BNC connector,
gives a lot of impedance changes.

For signals under 300 MHz the few centimeters of transmission line stub should not be an issue. But it nevertheless feels better to have the termination where it belongs: right at the end of the transmission line.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Git on December 26, 2013, 12:45:17 pm
I'm having a few issues with my JTAG probe

Thanks for your efforts on this. Did you manage to do a JTAG verify of dump file against the device?. I'm not very familiar with DS code, but there is a lot of 0xFF empty space in the dump which would make me suspicious if I had dumped it.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bigmarkslp on December 26, 2013, 05:41:00 pm
Does anyone know if the USB port unlock trick works with the A series?  I've been trying to decide between an non-A or A series unit, and the A series seems better from a hardware perspective.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 26, 2013, 06:20:57 pm
For signals under 300 MHz the few centimeters of transmission line stub should not be an issue. But it nevertheless feels better to have the termination where it belongs: right at the end of the transmission line.
And, what about the rise time?



About R2W smd marking code:

Made in China: http://www.chipdip.ru/search/?searchtext=BFR93A+%28SMD%29+SOT23 (http://www.chipdip.ru/search/?searchtext=BFR93A+%28SMD%29+SOT23)
Made in Hong Kong: http://www.soltronik.pl/bfr93a-12v-50ma-6ghz-135db-sot23-tranzystor-npn/p-15171.html?osCsid=7d3806245e986140f752be4951f2c818 (http://www.soltronik.pl/bfr93a-12v-50ma-6ghz-135db-sot23-tranzystor-npn/p-15171.html?osCsid=7d3806245e986140f752be4951f2c818)

(http://lib.chipdip.ru/191/DOC000191577.jpg)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 26, 2013, 06:51:35 pm
Does anyone know if the USB port unlock trick works with the A series? 

What trick is this?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Git on December 26, 2013, 07:04:58 pm
What trick is this?

There's mention of it here :
http://hackaday.com/2013/07/02/unlocking-a-rigol-scope-once-again/ (http://hackaday.com/2013/07/02/unlocking-a-rigol-scope-once-again/)
also there was a Service Mode hack.

Git
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 26, 2013, 07:10:17 pm
There's mention of it here :
http://hackaday.com/2013/07/02/unlocking-a-rigol-scope-once-again/ (http://hackaday.com/2013/07/02/unlocking-a-rigol-scope-once-again/)
also there was a Service Mode hack.

Unlocking as in installing a test key?

Is there a service mode hack for the ds2000 besides the menu7-menu6-menu7 one?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bigmarkslp on December 26, 2013, 09:25:02 pm
also there was a Service Mode hack.

There is studio25's Atiny85 trick too, right?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jkw13 on December 26, 2013, 11:36:48 pm
Quote
I think I've "bricked" my new DP832 by downgrading it to v1.06 and back to v1.08.
ADC cal doesn't work anymore, and the display meters are wrong.
Is there any way to recover from this do you think? Perhaps I did something wrong?
Does anyone know the ManualCal procedure?   :-BROKE
Thanks!

The problem is not the firmware up / downgrade.
There is a bug in the manual calibration.
Only volts and current ADC are affected.
The DAC's are ok.
Rigol knows the problem.
I'm waiting for a new firmware.
Write a mail to the Rigol support.

Is there more to  it than this I wonder?
Rigol say v1.08 is the latest version.
I find it strange that in addition to the ADC problem
that the options are lost after downgrade/upgrade,
including the trial minutes that I had.
I would like to remove the options and try again,
but ":SYSTem:OPTion:UNINSTall" doesn't work in
Ultra Sigma, nor ":Cal:Start 2012,CH1" either |O
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: clifford on December 27, 2013, 12:45:41 am
And, what about the rise time?

I would rather worry about overshoot:

(http://i.imgur.com/qIU7vjb.png)

This is for 0 cm, 1 cm, 5 cm and 10 cm stubs, using vacuum (air) as dielectric. So this should correspond to about 0 cm, 0.5 cm, 2.5 cm and 5 cm stubs for real world dielectrics.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 27, 2013, 12:57:38 am
I would rather worry about overshoot:
Yes, That's what I meant.

I thought that everyone would understand.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jkw13 on December 27, 2013, 10:50:19 am
I tried that also, ("SYSTEM:OPTION:UNINSTALL") just times out with "Remote command is incorrect!" appearing on DP832 screen.
The other thing I notice is that V1.06 has 30 calibration DAC points, V1.08 has only 29 points.
I think there is something sinister going on here, hope to be proved wrong |O

Thanks!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mightyzen on December 27, 2013, 04:29:50 pm
I would rather worry about overshoot:

(http://i.imgur.com/qIU7vjb.png)

This is for 0 cm, 1 cm, 5 cm and 10 cm stubs, using vacuum (air) as dielectric. So this should correspond to about 0 cm, 0.5 cm, 2.5 cm and 5 cm stubs for real world dielectrics.

Very interesting. What program did you use for this?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: EV on December 27, 2013, 05:08:18 pm
Text added!  :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: m-joy on December 27, 2013, 06:09:41 pm
Well this is pretty much theory. This is the case if the coax cable impedanz is perfectly 50ohm which is not the case and if the Transmission line inside is perfectly and if the Terminator is perfectly 50ohm ... I would worry more about tolerances than this line theory
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: clifford on December 27, 2013, 06:27:29 pm
Very interesting. What program did you use for this?

This is Qucs (http://qucs.sourceforge.net (http://qucs.sourceforge.net)).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: clifford on December 27, 2013, 06:57:08 pm
Well this is pretty much theory. This is the case if the coax cable impedanz is perfectly 50ohm which is not the case and if the Transmission line inside is perfectly and if the Terminator is perfectly 50ohm ... I would worry more about tolerances than this line theory

The argument stays the same: It all happens within a few centimeters of the receiver.

But you are right: Screw the theory and lets make a simple experiment. :-/O

(http://i.imgur.com/VMeunx3.png)

This is the fastest rise time I could generate within a few minutes for a simple test (that's the trigger output of my DG1022). So maybe someone with access to a faster rising edge could create a better test case.

The white trace (R1) is with the coax going directly into the scope input. So technically this is unterminated. But there is 50 Ohms termination on the other end, so it should more or less look the same as if we had 50 Ohms termination in the scope. The yellow trace (1) is with a BNC T connector with a 50 Ohms terminator on the second port.

We can see that it wants to overshoot a bit, as we would have expected from the simulation. But because the signal itself rises not fast enough we only end up with a trace slightly above the trace from the first case.

This is on my DS2072 (HW 2.0, SW 00.02.01, "upgraded" to a DS2303) with averaging of 1024 triggers.

PS: Yes, the trigger level is a bit awkward. I only realized that after I have created the screenshot. (I think that is simply the level I had already set and I did not bother to touch it because the trace looked fine.) The behavior does not change if I move the trigger down a bit. I've tried that, I just did not bother to create new screenshot.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: EV on December 27, 2013, 08:45:44 pm
Try scopes trigger out signal. It is very fast


This is the fastest rise time I could generate within a few minutes for a simple test (that's the trigger output of my DG1022). So maybe someone with access to a faster rising edge could create a better test case.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Wim13 on December 28, 2013, 09:04:49 am
Very interesting. What program did you use for this?

This is Qucs (http://qucs.sourceforge.net (http://qucs.sourceforge.net)).

One thing you have to add to your simulation.

The scoop entry is also a low pass filter, in this case a 300 Mhz low pass filter,

thats why signals going to the 300 Mhz always look always like a sine wave, because of the low pass filter.
All the harmonics are gone after 150 Mhz, all is left is a sine wave..

So a scoop of 300 Mhz is usefool to 20 Mhz.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: clifford on December 28, 2013, 12:53:51 pm
One thing you have to add to your simulation.
The scoop entry is also a low pass filter, in this case a 300 Mhz low pass filter,

This is tricky because the 16pF / 1 MOhm scope input is already part of the 300 MHz spec. But I've created bode plots of the original circuit and with an added first order 300 MHz low pass:

http://imgur.com/a/sMYNH (http://imgur.com/a/sMYNH)

This set of images also contains a transient simulation of the circuit with the added additional filter. As you can see, the rise time is slightly lower now but it does not really make any difference regarding the qualitative effect of the short transmission line between the termination resistor and the scope input.

thats why signals going to the 300 Mhz always look always like a sine wave, because of the low pass filter.
All the harmonics are gone after 150 Mhz, all is left is a sine wave..

So a scoop of 300 Mhz is usefool to 20 Mhz.

I think you are confusing bandwidth and sampling frequency here. All DS2000 scopes have a sampling frequency of 2 GHz.

Also: The harmonics above the nyquist frequency (1 GHz in this case) are not gone or magically filtered by the sampling. They show up as aliasing frequencies. You have to actively filter those components out using an anti-aliasing filter. If you sample fast enough you already have significant low pass characteristics on your input path and don't need to build a filter, its just implicitly there. That's the 300 MHz in this case.

But those filters never do have an ideal sinc impulse response. So you will never see a signal just morphing into a pure sine wave when approaching the filter edge frequency. (You can build such filters in a DSP of course: Just perform an FFT, mask out the frequencies you do not want, and run an IFFT. But you will never see the equivalent of that in an analog filter.)

There is this rule of thumb that you should have at least a factor 10 between sampling frequency and bandwidth. It is a good rule of thumb, but it is not the ultimate answer. The minimum factor between sampling frequency an signal bandwidth depends on the kind of signal you are interested in, the kind of aliasing filter you are using and the interpolation method you are using. In most RF applications you can get pretty close to the nyquist frequency, because you have extremely band-limited signals, use high order filters and you effectively use a sin(x)/x interpolation (you will never actually look at the signal in the time domain, but the algorithms work with an equivalent representation).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tirulerbach on December 28, 2013, 02:36:41 pm
Hello,

Just to make sure: Is the JTAG-port on DS2202A at 3.3 Volt?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 28, 2013, 02:57:13 pm
One thing you have to add to your simulation.
The scoop entry is also a low pass filter, in this case a 300 Mhz low pass filter,

This is tricky because the 16pF / 1 MOhm scope input is already part of the 300 MHz spec. But I've created bode plots of the original circuit and with an added first order 300 MHz low pass:

http://imgur.com/a/sMYNH (http://imgur.com/a/sMYNH)

This set of images also contains a transient simulation of the circuit with the added additional filter. As you can see, the rise time is slightly lower now but it does not really make any difference regarding the qualitative effect of the short transmission line between the termination resistor and the scope input.

thats why signals going to the 300 Mhz always look always like a sine wave, because of the low pass filter.
All the harmonics are gone after 150 Mhz, all is left is a sine wave..

So a scoop of 300 Mhz is usefool to 20 Mhz.

I think you are confusing bandwidth and sampling frequency here. All DS2000 scopes have a sampling frequency of 2 GHz.

Also: The harmonics above the nyquist frequency (1 GHz in this case) are not gone or magically filtered by the sampling. They show up as aliasing frequencies. You have to actively filter those components out using an anti-aliasing filter. If you sample fast enough you already have significant low pass characteristics on your input path and don't need to build a filter, its just implicitly there. That's the 300 MHz in this case.

But those filters never do have an ideal sinc impulse response. So you will never see a signal just morphing into a pure sine wave when approaching the filter edge frequency. (You can build such filters in a DSP of course: Just perform an FFT, mask out the frequencies you do not want, and run an IFFT. But you will never see the equivalent of that in an analog filter.)

There is this rule of thumb that you should have at least a factor 10 between sampling frequency and bandwidth. It is a good rule of thumb, but it is not the ultimate answer. The minimum factor between sampling frequency an signal bandwidth depends on the kind of signal you are interested in, the kind of aliasing filter you are using and the interpolation method you are using. In most RF applications you can get pretty close to the nyquist frequency, because you have extremely band-limited signals, use high order filters and you effectively use a sin(x)/x interpolation (you will never actually look at the signal in the time domain, but the algorithms work with an equivalent representation).
@ clifford: I agree, and I add some additional information that is related, read also attached fille:

Highly summarized:
  - For real time sampling acquisition and bandlimited signal: Fs > 2Fmax.
    Now use common sense: Everything depends on the details that you want (I'm not talking about ADC dynamic range), more details -> more frequency components -> more BW, then -> more Fs.
    i.e.: The sampling rate must also be sufficient for an acceptable reconstruction of the signal, for example a square pulse.   

  - For equivalent time sampling acquisition and only periodic bandlimited signal, then Fs can be less than signal's BW. But I think that this is not the case.

An interesting document (211 to 236) [220]:
http://w140.com/Handbook_of_Oscilloscope_Technology.pdf (http://w140.com/Handbook_of_Oscilloscope_Technology.pdf)
For sin(x)/x interpolation, a sampling rate of 2.5x the highest frequency is considered good enough to faithfully reconstruct the signal from the samples. But sin(x)/x is highly susceptible to errors if the original signal contains frequencies higher than the Nyquist frequency.

That is why the Rigol DS2000 series automatically switches from sin(x)/x interpolation to linear interpolation when the sampling rate <= 500MSa/s - because the Nyquist frequency starts to drop too low for reliable reconstruction. For example, @ 200MSa/s the Nyquist frequency is 100MHz - which easily passes through the BW filter.

When you use linear interpolation, it's cruder so it requires a higher sample rate ratio for faithful reconstruction (at least 8x, but 10x is considered the rule of thumb as AndrejaKo mentioned), but it won't introduce false peaks at slower sample rates like sin(x)/x might.

I'm not sure which (or when, if switching between them) interpolation scheme the Owon uses.
Only as complement: pages 260-262 of the previous link.
Thanks marmad.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 28, 2013, 03:01:49 pm
Hello,
Just to make sure: Is the JTAG-port on DS2202A at 3.3 Volt?
Yes, I think.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dtran11 on December 28, 2013, 04:23:30 pm
I will try it later tonight as well, just need to hack something together that generates a fast rising edges first, to test the 100 MHz with  :)

I can try it too. Is latest DS1000Z firmware 00.02.01.SP1 requested for unlocking 100MHz?
Do we have some info or change list for this firmware? Thanks :)

I just got a DS1074Z. Do the keys still work if I upgrade to 00.02.01.SP1? Also is there anyway to revert the options if I need to send in for repair?

Thanks
Title: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on December 28, 2013, 04:44:12 pm

I will try it later tonight as well, just need to hack something together that generates a fast rising edges first, to test the 100 MHz with  :)

I can try it too. Is latest DS1000Z firmware 00.02.01.SP1 requested for unlocking 100MHz?
Do we have some info or change list for this firmware? Thanks :)

I just got a DS1074Z. Do the keys still work if I upgrade to 00.02.01.SP1? Also is there anyway to revert the options if I need to send in for repair?

Thanks

Ifaik the DS1000Z isn't hackable yet.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neamyalo on December 28, 2013, 05:58:14 pm
Finally I have a full memory dump from my DS2072A.

It was taken in a single snapshot, approx 1 min after booting with no user interaction (options details window had timed out/disappeared and CH1/CH2 traces were visible)

https://mega.co.nz/#!rcl23CyD!Pp9LZgukP_k4T2OmqfUtmncP2chWoaGDI0yVS5x5Mis
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neamyalo on December 28, 2013, 06:04:23 pm
I'm having a few issues with my JTAG probe

Thanks for your efforts on this. Did you manage to do a JTAG verify of dump file against the device?. I'm not very familiar with DS code, but there is a lot of 0xFF empty space in the dump which would make me suspicious if I had dumped it.

I haven't been able to verify the dump as my JTAG link is extremely slow (12 hours to dump 32MB of SDRAM), but I've no reason to think it is incorrect (i.e. no error messages etc, and "RIGOL Technology" strings are present in the data)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dtran11 on December 28, 2013, 06:27:42 pm

I will try it later tonight as well, just need to hack something together that generates a fast rising edges first, to test the 100 MHz with  :)

I can try it too. Is latest DS1000Z firmware 00.02.01.SP1 requested for unlocking 100MHz?
Do we have some info or change list for this firmware? Thanks :)

I just got a DS1074Z. Do the keys still work if I upgrade to 00.02.01.SP1? Also is there anyway to revert the options if I need to send in for repair?

Thanks

Ifaik the DS1000Z isn't hackable yet.

There are codes for the ds1000z already in the latest riglol.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: clifford on December 28, 2013, 06:35:04 pm
@ clifford: I agree, and I add some additional information that is related, read also attached fille:
[...]

Wow! The Agilent AppNote is a good read. Thanks!
(Nothing really new but everything in one place.) :-+

I've bookmarked it for future reference, as this is a topic that seams to come up every now and then.

http://cp.literature.agilent.com/litweb/pdf/5988-8008EN.pdf (http://cp.literature.agilent.com/litweb/pdf/5988-8008EN.pdf)

PS: When I said "filters with an ideal sinc impulse response" I was referring to "brick wall" filters of course, but I did not remember the word, so I described it. Fortunately it was mentioned in that AppNote, so at least for today I know the word again.

PPS: I really like the introduction to sin(x)/x interpolation given in the following article. (Nothing new there either, just another nice document that summarizes a topic.) But it is ridiculous that they managed to f*ck up the formulas in the pdf..  :palm:

http://www.eetimes.com/document.asp?doc_id=1272526 (http://www.eetimes.com/document.asp?doc_id=1272526)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Teneyes on December 28, 2013, 07:00:37 pm
PPS: I really like the introduction to sin(x)/x interpolation given in the following article.
@ Clifford and Non "first-impressions" readers
Just a few displays to demo Sin(x)/X on the Rigol DS2000, to help show what happens
1. Display of 1 dot off line,
2. Displayed with Vectors,
3. Display of 2 dots off line,
4. Display of 2 samples in vectors,    ( a bit off topic so I will delete soon 18v)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 28, 2013, 07:03:11 pm
I will try it later tonight as well, just need to hack something together that generates a fast rising edges first, to test the 100 MHz with  :)
I can try it too. Is latest DS1000Z firmware 00.02.01.SP1 requested for unlocking 100MHz?
Do we have some info or change list for this firmware? Thanks :)

I just got a DS1074Z. Do the keys still work if I upgrade to 00.02.01.SP1? Also is there anyway to revert the options if I need to send in for repair?

Thanks
Ifaik the DS1000Z isn't hackable yet.
Yes DS1000Z is hackable: http://riglol.3owl.com (http://riglol.3owl.com)
Quote
DS1000z device options:
DSAB - Advanced Triggers
DSAC - Decoders
DSAE - 24M Memory
DSAJ - Recorder
DSBA - 500uV Vertical
DSEA - 100MHz
DSFR - all options

The hacks are even mirrored at your own website Avotronics ;) :-DD http://rigol.avotronics.co.uk/mirrors/riglol/ (http://rigol.avotronics.co.uk/mirrors/riglol/)


Also is there anyway to revert the options if I need to send in for repair?
Use the SCPI command ":SYSTem:OPTion:UNINSTall" to remove installed option keys again. Search this topic for :SYSTem:OPTion:UNINSTall
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 28, 2013, 07:25:18 pm
@clifford:

Wow! The Agilent AppNote is a good read. Thanks!
(Nothing really new but everything in one place.) :-+

...

The first pages [1-5] have reminded me those days studying signals and systems.
Figure 4 is a point of view very graphic about the aliasing.
Pages 6, 8 and 9 are interesting, too.
I wonder if the DS2000 have the FIR filter implemented in the DSP, or in the FPGA.

Thanks.  ;)



@Teneyes:

Teneyes and its magic.
Lovely sinc...



A few days ago someone mention something about a Tek oscilloscope that in dots mode showed more samples than should be.
It's not magic, are interpolated (maths).
Title: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on December 28, 2013, 08:10:25 pm

I will try it later tonight as well, just need to hack something together that generates a fast rising edges first, to test the 100 MHz with  :)
I can try it too. Is latest DS1000Z firmware 00.02.01.SP1 requested for unlocking 100MHz?
Do we have some info or change list for this firmware? Thanks :)

I just got a DS1074Z. Do the keys still work if I upgrade to 00.02.01.SP1? Also is there anyway to revert the options if I need to send in for repair?

Thanks
Ifaik the DS1000Z isn't hackable yet.
Yes DS1000Z is hackable: http://riglol.3owl.com (http://riglol.3owl.com)
Quote
DS1000z device options:
DSAB - Advanced Triggers
DSAC - Decoders
DSAE - 24M Memory
DSAJ - Recorder
DSBA - 500uV Vertical
DSEA - 100MHz
DSFR - all options

The hacks are even mirrored at your own website Avotronics ;) :-DD http://rigol.avotronics.co.uk/mirrors/riglol/ (http://rigol.avotronics.co.uk/mirrors/riglol/)


Also is there anyway to revert the options if I need to send in for repair?
Use the SCPI command ":SYSTem:OPTion:UNINSTall" to remove installed option keys again. Search this topic for :SYSTem:OPTion:UNINSTall

Bugger! Lol.

That'll teach me. I was certain there were no hacks.
Wonder if I was thinking of another model....

Wait. Wasn't it that, originally, the DS1074Z hacks didn't add 100MHz option? Is that a new addition?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 28, 2013, 08:12:23 pm
neamyalo thank you for your work - would you be willing to upgrade to the latest firmware and repeat the full dump?

Your dump says it is 00.02.00.00.04 and the latest fw I know of is 00.02.01.00.03.

Thanks!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 28, 2013, 08:30:57 pm
Bugger! Lol.

That'll teach me. I was certain there were no hacks.
Wonder if I was thinking of another model....

Wait. Wasn't it that, originally, the DS1074Z hacks didn't add 100MHz option? Is that a new addition?
Yes that's probably what you were thinking of. The 100 MHz option is a relatively new addition posted by seronday on 12 December 2013: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg346786/?topicseen#msg346786 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg346786/?topicseen#msg346786)
Anyone who wants to change their new DS1074Z into a DS1104Z use the following Codes:-

DSHA  makes a  DS1104Z with no options enabled .
DSHR  makes a  DS1104Z with all options enabled .

The 3dB bandwidth for the DS1104Z is approx 160Mhz.
The 3dB bandwidth for the DS1074Z is approx 90Mhz.



Minor correction to my previous post after some further investigation.

DSHA also enables the 500uV setting and another unknown, (at present), option.

DSEA is the correct code to change to a DS1104Z only. ( no options ). See table below.

 Code      DS1104z    Unknown     500uV setting
DSBA                                               X
DSCA                            X
DSDA                            X                 X
DSEA           X
DSFA           X                                  X
DSGA           X               X
DSHA           X               X                 X

So to change a DS1074Z into a DS1104Z with all options enabled except the 500uV/div (which does not work correctly at present),
the code  will be DSER.

It is possible to revert back to original, by using the SCPI command " :SYSTem:OPTion:UNINSTall " .

As mentioned in my previous post, the measured 3dB down bandwidth after changing to a DS1104Z, is approx 160Mhz.
All the tests were done on a DS1074Z with Ver:00.02.00.SP1.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dtran11 on December 28, 2013, 08:34:11 pm
Does anyone know what the unknown option for the DS1000Z is for yet? I just installed it but would like to know what it is for. Also how do I revert back to DS1074Z?

Thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 28, 2013, 08:43:13 pm
Also how do I revert back to DS1074Z?
I already mention that in a previous answer to your question: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg355312/#msg355312 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg355312/#msg355312)
Also is there anyway to revert the options if I need to send in for repair?
Use the SCPI command ":SYSTem:OPTion:UNINSTall" to remove installed option keys again. Search this topic for :SYSTem:OPTion:UNINSTall
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: m-joy on December 28, 2013, 09:14:47 pm
neamyalo thank you for your work - would you be willing to upgrade to the latest firmware and repeat the full dump?

Your dump says it is 00.02.00.00.04 and the latest fw I know of is 00.02.01.00.03.

Thanks!


Does that change anything?where is cybernet btw...
Title: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on December 28, 2013, 09:37:06 pm



Thanks!
[/quote]

where is cybernet btw...
[/quote]

What are we, his nannies? Lol ;-)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tirulerbach on December 28, 2013, 09:52:51 pm
Hello,

I remembered I'm owning a JTAG-Dongle...  :-/O It is an Olimex ARM-USB-OCD. In the meantime I opened my DS2202A, attached the JTAG, downloaded the bfin-uclinux stuff and started urjtag:

Code: [Select]
jtag> cable arm-usb-ocd
Connected to libftdi driver.
jtag> frequency 500000
Setting TCK frequency to 500000 Hz
jtag> detect
warning: TDO seems to be stuck at 0
jtag>

Lower frequencies didn't work either...

So after fiddling a little bit I assume that the Utst  Voltage (3.3V) on Pin 1 on the JTAG header is to weak. According to the schematic posted above it is connected via a pull-up of 10k to 3.3 Volts. The voltage drops to about 1.8V when I connect the JTAG-dongle. That is about 150uA.

So, do you think I just can use an external 3.3V supply for the JTAG-dongle?

Maybe this is the same issue which neamyalo very slow jtag speed? What do you think?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Flipp on December 28, 2013, 09:53:37 pm
Lol:
DS2000 Series is a new generation oscilloscope. It has 2 channels. It has a sibling version with logic analyser DS2000D. The maximum bandwidth is 200M, and the peak sampling rate is up to 1G.
 :-DD
From HTML Page inside Jtag Dump

Flip :wtf:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 28, 2013, 10:01:24 pm
Hello,

I remembered I'm owning a JTAG-Dongle...  :-/O It is an Olimex ARM-USB-OCD. In the meantime I opened my DS2202A, attached the JTAG, downloaded the bfin-uclinux stuff and started urjtag:

Code: [Select]
jtag> cable arm-usb-ocd
Connected to libftdi driver.
jtag> frequency 500000
Setting TCK frequency to 500000 Hz
jtag> detect
warning: TDO seems to be stuck at 0
jtag>

Lower frequencies didn't work either...

So after fiddling a little bit I assume that the Utst  Voltage (3.3V) on Pin 1 on the JTAG header is to weak. According to the schematic posted above it is connected via a pull-up of 10k to 3.3 Volts. The voltage drops to about 1.8V when I connect the JTAG-dongle. That is about 150uA.

So, do you think I just can use an external 3.3V supply for the JTAG-dongle?

Maybe this is the same issue which neamyalo very slow jtag speed? What do you think?
From what I have understood from Cybernet's posts about Rigol JTAG interfacing you have to add the 10k and 3k9 pull-up resistors externally yourself. Did you measure the resistance from SRST [pin 2] and TRST [pin 10] to 3.3V [pin 1]?
Just managed to discover the BF526 on the JTAG chain :-DD  >:D

Pinout:

Quote
   3,3V      (1)   (2) /EMU, /SRST (use a 10k pullup to 3,3V)
   no pin   (3)   (4)  unused (seems to be GND)
   nc         (5)   (6) TMS
   GND      (7)   (8) TCK
   GND      (9)   (10) /TRST (use a 10k pullup to 3,3V)
   GND    (11)  (12) TDI
   GND    (13)  (14) TDO

The 14pin header near the Blackfin. I actually think i fried my 3,3V on Pin1 - even if loaded with 10k it drops down to 1V,
so im running the pullup for pin (2) to the 4 pin connector on the opposite side of the PCB labeled VCC (3,3V) instead of pin1

CAUTION: the usual ADI JTAG has pin1 connected to GND (this shorts VCC to GND), which probably killed my VCC there ...
Scope is still fine, so just fried some output stage somewhere i guess ;)

For the jtag adapter itself im using the Amontec JTAG Key Tiny (30$) - TopJTAG eval discovers an Analog Devices BF526 (IDCODE=227E0CBh) ... next up trying urJTAG + bfin-gdb.

JTAG Key: http://www.amontec.com/ (http://www.amontec.com/)
started dumping memory via JTAG on the DG4000 - no probs at all exact same layout as the DS2000's JTAG - aux 3,3V can be stolen from the header next to it if needed for jtag adapter.

(https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/?action=dlattach;attach=73449;image)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tirulerbach on December 28, 2013, 10:07:32 pm
Code: [Select]
jtag> frequency 5000000
Setting TCK frequency to 5000000 Hz
jtag> detect
IR length: 5
Chain length: 1
Device Id: 00100010011111100100000011001011 (0x227E40CB)
  Manufacturer: Analog Devices, Inc. (0x0CB)
  Part(0):      BF526 (0x27E4)
  Stepping:     2
  Filename:     ./../share/urjtag/analog/bf527/bf527
jtag>

 :-DD No risk no fun... There is a "SPI BOOT" header oh the right side of the PCB. Pin 7 has 3.3 Volts and it works...  8)

So now I'm learning how to dump that beast....
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: m-joy on December 28, 2013, 10:22:09 pm
Dumpy dumpy dooo!
The only Problem that i see is.... Cybernet seems to be the only one that can handle the dump xD
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tirulerbach on December 28, 2013, 10:45:19 pm
Yeah, looks like that dumping works. About 50 KByte/s.  :=\
Results are consistent.  :-+

So, I have questions:  ::)

a.) How large is the RAM? 64 Meg?
b.) How to enter into the boot-loader on startup? I read somewhere the dump in boot-loader mode is also needed?

Title: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on December 28, 2013, 11:10:40 pm
Cybernet surely does love them big fresh dumps :-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neamyalo on December 28, 2013, 11:42:05 pm
a.) How large is the RAM? 64 Meg?

I think the SDRAM is only 32 MB. I could only see one 32 MB IC connected on the PCBA and in a post a while back Alan2k (I think) also mentioned that the register values corresponded with only 32MB of SDRAM, starting at address 0.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Dave Turner on December 28, 2013, 11:45:46 pm
My DS1074Z-S reports a software version - 00.02.00.SP1.

Has anyone seen a later version?

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dtran11 on December 28, 2013, 11:48:50 pm
Also how do I revert back to DS1074Z?
I already mention that in a previous answer to your question: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg355312/#msg355312 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg355312/#msg355312)
Also is there anyway to revert the options if I need to send in for repair?
Use the SCPI command ":SYSTem:OPTion:UNINSTall" to remove installed option keys again. Search this topic for :SYSTem:OPTion:UNINSTall

Sorry, I thought the 100mhz was a different animal. So that command will remove all options (keys) at once? thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neamyalo on December 28, 2013, 11:57:14 pm
neamyalo thank you for your work - would you be willing to upgrade to the latest firmware and repeat the full dump?

Your dump says it is 00.02.00.00.04 and the latest fw I know of is 00.02.01.00.03.

Thanks!

Hi Alan, no problem with the dumps so far - my pleasure - but I'd rather not do another if I can help it - my JTAG link's so slow (its 14 hours of continuous dumping just for one snapshot).

I think S/W 00.02.00.00.04 will be good enough for our purposes  ;) Also, let's see how tirulerbach gets on - it sounds like his link is blazing @ 50 kB/s  8)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 29, 2013, 12:23:47 am
Your dump says it is 00.02.00.00.04 and the latest fw I know of is 00.02.01.00.03.
I think S/W 00.02.00.00.04 will be good enough for our purposes

The only problem is that 00.02.00.00.04 is an unknown one in that nobody has a gel file for it.  I know it is a lot to ask for another dump, but the 00.02.01.00.03 is available in gel and can be analyzed.  If you can at some point that would be appreciated - either way thank you for your work!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tirulerbach on December 29, 2013, 12:33:31 am
My first dump is completed.  :-+

DS2202A unmodified, firmware 00.02.00.00.04 and booted to normal operating mode...

Now, somebody would like to tell me how to enter the boot loader?

Have fun! :-DD

https://mega.co.nz/#!6FcXUKYT!XsgK-3tIaJp2inP6UBlzWXDfs8VIkfkpQJNPXjY5_yA (https://mega.co.nz/#!6FcXUKYT!XsgK-3tIaJp2inP6UBlzWXDfs8VIkfkpQJNPXjY5_yA)

(Sorry for the file hosting...   :-\ Do you have some better site?)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 29, 2013, 12:41:59 am
(Sorry for the file hosting...   :-\ Do you have some better site?)
https://mega.co.nz (https://mega.co.nz) very fast and the same site as neamyalo used to host his dump: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg355266/#msg355266 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg355266/#msg355266)

And you can get the Avotronics who posted in this topic earlier today to host it on his Rigol hacking site: http://rigol.avotronics.co.uk (http://rigol.avotronics.co.uk)
Title: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on December 29, 2013, 01:17:51 am
I'm on ipad now, but tomorrow I'll post them up on rigol.avotronics.co.uk just in case they get removed.
Lot of dumps today... I should lay off the eggs :-/
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 29, 2013, 01:20:07 am
Lot of dumps today...
I blame all the christmas food  :-DD
Title: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on December 29, 2013, 01:31:46 am
true, combined with not knowing when to stop eating ;-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tirulerbach on December 29, 2013, 01:51:44 am
I updated my DS2202A to latest firmware 00.02.01.00.03 and made a new dump (just after reboot from update):  :-DD

https://mega.co.nz/#!uUUBXJQC!U8smoyLwcdVIXXxy82DoGSy457oJDYQhZUIRccF9ZSU (https://mega.co.nz/#!uUUBXJQC!U8smoyLwcdVIXXxy82DoGSy457oJDYQhZUIRccF9ZSU)

Have Fun!  8)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jkw13 on December 29, 2013, 02:09:17 am
I really apologize if this has been answered already in this thread, but I'm late to the game and pouring over 141 pages of posts is a bit daunting.  But are there firmware limitations on the use of Keygens on Rigol equipment (namely the DP832 and DS1074Z)?  For instance, do the keys not work with newer firmwares, and has anyone lost keygen activated features after upgrading the firmware on the equipment?

Well I have lost keygen feaures on DP832 after down/upgrade and ADC not working,
The output meters mean nothing now :scared:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: nerdms on December 29, 2013, 07:20:38 am
Hi, I have the DS2072 with HW version 2.0 and FW version 01_01_00_02.  I used the DSAZ to generate the key and everything seems to have gone fine (all options enabled) but I discovered that the vertical and horizontal position knobs are acting funny.  If I move the vertical knob in one direction then it always moves in that direction no matter which way I rotate the knob and the horizontal always moves in one direction.  I updated the FW to 02_01_00_03 thinking that would fix the issue but nope.  Pushing the knobs centers everything fine.  Has anyone encountered that?  Very weird.

Thanks.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybermaus on December 29, 2013, 09:58:40 am
Hi guys

sorry if I missed it during search, but was any download location or change-list given for the latest DS1000Z (DS1074Z-S) firmware?

Also, if anyone wants to know, the DSAB Adv Trigger / DSAC Decoders / DSAE 24M Memory / DSAJ Recorder features work on the -S model without any apparent side effects.

Did not try the "DSFR All Options" though because it is described as "turns it into a DS1104Z".
I do not want it to turn into a DS1104Z ! Not without the -S !

I wonder if the 'unknown' feature is the signal generator. People without the hardware would not notice it active or missing. Except maybe for the grayed out tabs under the screen.


To be honest, for the stuff I do i do not really need the bandwidth (or any of the other features for that matter). Only two month ago I was still happy with my 20MHz analog.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 29, 2013, 11:05:18 am
Did not try the "DSFR All Options" though because it is described as "turns it into a DS1104Z".
I do not want it to turn into a DS1104Z ! Not without the -S !
Where's DSFR described as turning it into a DS1104Z?
Nono of the option keys doesn't turn an -S model into a non-S model. DSFR just changes add all options including changing the BW from 70 MHz to 100 MHz.
But since you already have all the other options installed you can just use DSEA, all it does is to change the BW from 70 MHz to 100 MHz. http://riglol.3owl.com (http://riglol.3owl.com)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tirulerbach on December 29, 2013, 12:35:42 pm
Hello,

two more dumps...  Both are DS2202A unmodified, firmware 00.02.01.00.03  :-DD

a.) boot-loader mode via the help-key during switch on:
 https://mega.co.nz/#!fY8j2RKJ!EIiEBAYmCJ_4pIpJNB2X7BBpQ30M5BC8-QF3rmoloZ0 (https://mega.co.nz/#!fY8j2RKJ!EIiEBAYmCJ_4pIpJNB2X7BBpQ30M5BC8-QF3rmoloZ0)

b.) normal operating mode, dialog to enter a key open, filled with AAAAAAA BBBBBBB CCCCCCC DDDDDDD and pressed the Apply button once:
 https://mega.co.nz/#!Wd0TDTqT!Zu4l9n1XZETTz39NYvnJ4TpveBUKOquEqPrhOVrCpYI (https://mega.co.nz/#!Wd0TDTqT!Zu4l9n1XZETTz39NYvnJ4TpveBUKOquEqPrhOVrCpYI)

Now somebody should take a look with a debugger...  8)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 29, 2013, 03:18:27 pm
The earlier thing said there was 16mb of flash which is not in the dumps.  Is this memory banked in and out in the async area somehow?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: nerdms on December 29, 2013, 03:56:05 pm
Hi, I have the DS2072 with HW version 2.0 and FW version 01_01_00_02.  I used the DSAZ to generate the key and everything seems to have gone fine (all options enabled) but I discovered that the vertical and horizontal position knobs are acting funny.  If I move the vertical knob in one direction then it always moves in that direction no matter which way I rotate the knob and the horizontal always moves in one direction.  I updated the FW to 02_01_00_03 thinking that would fix the issue but nope.  Pushing the knobs centers everything fine.  Has anyone encountered that?  Very weird.

Thanks.

After sleeping on it I tried it again (resetting by hitting the f6 key, re-installing the 2.0 FW and recreating a key this time with DSHH) and still nothing.  I couldn't figure out why this was occurring since installing an option key should have not caused this.  So I connected my probe to the compensation terminal and started playing with the scales going up and down the ranges.  All of a sudden I noticed that the position knobs were working again!  I can't figure out why this is working now but it is.  Maybe something goes loopy when the options are installed?  Or something in the firmware makes it go off?  I don't know but messing with the scales seems to have fixed it.

So I went to take pictures of my versions and options to post and I guess I'm one of the non A versions to have my scope turn to the 2302 model.  Haven't tested it yet but my option screen does show the 300MHz option.

Sam.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybermaus on December 29, 2013, 06:11:26 pm
Where's DSFR described as turning it into a DS1104Z?
Well, it was this message (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg346786/#msg346786) (if you read it with some paranoia)

I am cautious, because while the DS1000Z seems to be mentioned a lot in this thread, the DS1000Z-S seems less common, and I do not want to be the first to discover how to brick one by carelessly assuming they are the same.

Anyway, I already grabbed and stored the 100MHz code, thanks. I will probably apply it if I either need 100MHz, or if I cannot control the nerd in me, whichever comes first. (probably the latter)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on December 29, 2013, 08:27:59 pm
Hello,

two more dumps...  Both are DS2202A unmodified, firmware 00.02.01.00.03  :-DD

a.) boot-loader mode via the help-key during switch on:
 https://mega.co.nz/#!fY8j2RKJ!EIiEBAYmCJ_4pIpJNB2X7BBpQ30M5BC8-QF3rmoloZ0 (https://mega.co.nz/#!fY8j2RKJ!EIiEBAYmCJ_4pIpJNB2X7BBpQ30M5BC8-QF3rmoloZ0)

b.) normal operating mode, dialog to enter a key open, filled with AAAAAAA BBBBBBB CCCCCCC DDDDDDD and pressed the Apply button once:
 https://mega.co.nz/#!Wd0TDTqT!Zu4l9n1XZETTz39NYvnJ4TpveBUKOquEqPrhOVrCpYI (https://mega.co.nz/#!Wd0TDTqT!Zu4l9n1XZETTz39NYvnJ4TpveBUKOquEqPrhOVrCpYI)

Now somebody should take a look with a debugger...  8)

thx- im going to have a look on various upcoming plane flights ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on December 29, 2013, 11:38:05 pm
I found function that loads alternative public key in DS2K-A firmware. The new public key is 0xA51BF373712F7D and the private key (that matches old Rigol ECC parameters) is 0x888E77EE47C50A. I don't have DS2K-A scope yet, so I can't confirm if this key will work with existing keygens.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 29, 2013, 11:40:42 pm
I found function that loads alternative public key in DS2K-A firmware. The new public key is 0xA51BF373712F7D and the private key (that matches old Rigol ECC parameters) is 0x888E77EE47C50A. I don't have DS2K-A scope yet, so I can't confirm if this key will work with existing keygens.

Nicely done!  ;)  I'm curious as to whether it works.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on December 29, 2013, 11:46:02 pm
is there a way I can test that?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on December 30, 2013, 12:22:48 am
is there a way I can test that?

You can use this site: http://riglol.3owl.com (http://riglol.3owl.com) and check if your DS2K-A scope will accept generated license code.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on December 30, 2013, 12:31:08 am
just to avoid troubles:
all I have to do is entering the private key, serial (of course) and DSHH?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 30, 2013, 12:34:35 am
just to avoid troubles:
all I have to do is entering the private key, serial (of course) and DSHH?
I would think so yes.
And remember leave out 0x part, so just paste 888E77EE47C50A in the private key field.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on December 30, 2013, 12:39:10 am
ok, I found out about the 0x before I read your reply lol

it says licence is unavailable
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MrsR on December 30, 2013, 12:41:52 am
Hi! Guys,
I've been a bit lazy :=\ ( might be all the Turkey I been eating ) anyway I was doing some work with my updated 72 to 302 and found that I couldn't record the waveforms I was working on.
I should add that I had the DSO Band Width set on 20MHz.

Also I don't use AUTO on my scopes, prefer to set the DSO to what I want, anyway I tried to use AUTO and all I got was a blank screen and then after a few tries a menu outline with no instructions. :-//

Has anyone had any problems like that on a modified DS2072 ??.
I have a stack of work to do and will get back to it next weekend I am not really worried about the AUTO part but not being able to record and save the output is a big worry. It isn't a DSO if I can't store on it. It might have been turned into a DO Scope. I can still capture screenshots on USB Sticks but I need the storage so I can study and send the test results to others on the team. Nearly all our work is shared by Video conferencing. Someone said they had problems with adjusting voltage height, I haven't had that problem.
Also has there been other problems after changing from lower Band Width to 300MHz.
Thanks Guys
Rachael :-+ Keeping a positive outlook
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 30, 2013, 12:47:28 am
ok, I found out about the 0x before I read your reply lol

it says licence is unavailable
Try to see if some of the other DSxx codes listed works:
Quote
DS2000 device options:
first character: D = official, V = trial
DSAB - Advanced Triggers
DSAC - I2C, SPI and RS232 Decoders
DSEA - CAN Decoder
DSAE - 56M Memory
DSAJ - 100MHz
DSAS - 200MHz
DSCA - 300MHz
DSHH - all options
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on December 30, 2013, 12:56:08 am
tried DSHH, CAN and advanced triggers, all unavailable

serial is 13 digits, right?

I noticed that only the 3rd and 4th part of the code changes (if I use a different serial and/or option)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 30, 2013, 01:06:04 am
I noticed that only the 3rd and 4th part of the code changes (if I use a different serial and/or option)
That's because the first two letters are always DS. If you change the first two letters to something else the 1st and/or 2nd part of the generated key will change too.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on December 30, 2013, 01:11:25 am
ok, just wanted to make sure that everything is working so far XD
hmm ...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: poida_pie on December 30, 2013, 01:33:26 am
deleted

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 30, 2013, 01:38:56 am
Not sure if this is already known and if this is the thread to post it, but anyway

BUG in latest f/w, 02.01

...
Marmad already keeps track of all DS2k firmware bugs in another topic here: https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684 (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684)
So the best is probably to delete your post in this topic again and post it in the other topic instead.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 30, 2013, 07:45:58 am
Where did the 'Remove' button for messages go?
https://www.eevblog.com/forum/news/deleting-posts/ (https://www.eevblog.com/forum/news/deleting-posts/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Fagear on December 30, 2013, 07:57:28 am
I found function that loads alternative public key in DS2K-A firmware. The new public key is 0xA51BF373712F7D and the private key (that matches old Rigol ECC parameters) is 0x888E77EE47C50A. I don't have DS2K-A scope yet, so I can't confirm if this key will work with existing keygens.
Tried it on my DS2072A, converted to DS2202A with no options (via old FW and old private key).
Generated keys for DSHH and DSAZ - no luck, "License is unavailable!".
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: EV on December 30, 2013, 08:47:39 am
How is it possible to uninstall only one option?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 30, 2013, 12:01:06 pm
How is it possible to uninstall only one option?
I think you have to uninstall all options with ":SYSTem:OPTion:UNINSTall" and then only reinstall the options you want again.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: EV on December 30, 2013, 12:20:01 pm
That's what I was afraid of.  ;D

I think you have to uninstall all options with ":SYSTem:OPTion:UNINSTall" and then only reinstall the options you want again.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: whotopia on December 30, 2013, 01:23:29 pm
Just got a new DS2072A.  I converted to DS2202A with all options (via old FW and old private key).
Will the scope function correctly with the old firmware? Has anyone noted any problems? 

Also, I 'lost' the serial number in the process, and the scope is now using default value.  On the DG4000 via cengen (see elsewhere on this forum) you can generate a license.GEL file through which one can also apparently mod the serial number.  Is such a thing possible for the DS2000?  Is there anyway to restore the serial number ?  Is there any real harm in having the default?
The scope doesn't ever try call Rigol if ethernet connected right?

Thanks
Steven
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on December 30, 2013, 01:29:49 pm
BUG in latest f/w, 02.01

Delayed sweep malfunctions.
To reproduce:
Ch2 must be enabled, Ch1 optional
acquire:  7M samples, normal
trigger: ch1 or not important, Auto or Normal seems to have no effect
main timebase 500us/div, delayed t.b. 100 us/div or something
Then when you move the delayed t.b. towards 1 ns/div all seems well until you select 1 ns/div..
It locks up for about 10 seconds, no waveform update, no response to keys.
Then it comes good and lets you go back to 2ns/div
I see what you're talking about, but as mentioned earlier in the thread in regards to problems with the 1ns time base:

It's another error (and there's a few of them) in an, as yet, officially unimplemented - and perhaps unfinished? - portion of firmware. As far as I know, Rigol has not started selling BW updates - but if/when someone on the forum has a DS2302A (or DS2302A-S), we can find out if the error(s) exist in the 'official' working version - and if so, report it to Rigol.

I suggest disabling 300MHz on non-A HW v.1 models. Not only is it buggy (I've had a couple of crashes from it), but it's not really perfectly implemented in the input stage.
How is it possible to uninstall only BW option?
Do ":SYSTem:OPTion:UNINSTall" and then generate new keys without 300 MHz option (with 200 MHz for example) and install them.
It can be two keys: DSAZ (200 MHz, MEM, DC, AT) then DSEA (CAN).
Or simply use DSEZ instead as the only key, to combine CAN with all the options included in DSAZ (200 Mhz, Mem, Dec and Trig) into a single key.
Combining the two tables below DSEZ should install CAN, 200 Mhz, Mem, Dec and Trig.
So DSEZ should be the one key solution to use for non A DS2000 with HW 1 and the latest FW if you want 200 MHz with all available options including CAN but without 50 ohm which is not implemented on HW 1 anyway.

EZ derived from the two tables for y (3rd letter) and x (4th letter) below (DSyx):
Code: [Select]
y  CAN, 300, 50ohm   |   x  200, 100, Mem, Dec, Trig
E   on   ==   ==     |   Z   on   ==   on   on   on   <-  All 2202

Table for 3rd letter (y):
Is this correct?
IMHO would be interesting know the entire table, and thus activate the desired options with a single key.

Code: [Select]
Code table: Use DSYX for a official key, and use VSYX for a trial key.

Y  CAN, 300, 50ohm

A   none
B   ==   ==   on
C   ==   on   ==
D   ??   ??   ??
E   on   ==   ==
F   ??   ??   ??
G   ??   ??   ??
H   on   on   on
J   ??   ??   ??
K   ??   ??   ??
L   ??   ??   ??
M   ??   ??   ??
N   ??   ??   ??
P   ??   ??   ??
Q   ??   ??   ??
R   ??   ??   ??
S   ??   ??   ??
T   ??   ??   ??
U   ??   ??   ??
V   ??   ??   ??
W   ??   ??   ??
X   ??   ??   ??
Y   ??   ??   ??
Z   ??   ??   ??
E instead of A as 3rd letter enables CAN but still leaves out the 300 MHz BW and 50 ohm which is not implemented on HW 1 anyway.

Table for 4th letter (x):
Cybernet has done it, again! *ole*  :-+

Now I'm very busy and I can't test anything (check the BW for example).

Anyway. How is the new table?

Quote
Code table: Use DSAx for a official key, and use VSAx for a trial key.

x  200, 100, Mem, Dec, Trig

A   none
B   ==   ==   ==   ==   on
C   ==   ==   ==   on   ==
D   ==   ==   ==   on   on
E   ==   ==   on   ==   ==
F   ==   ==   on   ==   on
G   ==   ==   on   on   ==
H   ==   ==   on   on   on

Note: keys A..H wont change the model, only ADD an option.

2102:

J   ==   on   ==   ==   ==   
K   ==   on   ==   ==   on
L   ==   on   ==   on   ==
M   ==   on   ==   on   on
N   ==   on   on   ==   ==
P   ==   on   on   ==   on
Q   ==   on   on   on   ==
R   ==   on   on   on   on   <-  All 2102

2202:

S   on   ==   ==   ==   ==   
T   on   ==   ==   ==   on
U   on   ==   ==   on   ==
V   on   ==   ==   on   on
W   on   ==   on   ==   ==
X   on   ==   on   ==   on
Y   on   ==   on   on   ==
Z   on   ==   on   on   on   <-  All 2202

DONT USE BELOW Not recommended, as activates 2102 and also 2202:

2   on   on   ==   ==   ==
3   on   on   ==   ==   on
4   on   on   ==   on   ==
5   on   on   ==   on   on
6   on   on   on   ==   ==
7   on   on   on   ==   on
8   on   on   on   on   ==
9   on   on   on   on   on
Z as 4th letter for 200 Mhz, Mem, Dec and Trig.


And here's the table to convert between binary values and letters: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg322495/?topicseen#msg322495 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg322495/?topicseen#msg322495)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on December 30, 2013, 03:55:52 pm
ok, I found out about the 0x before I read your reply lol

it says licence is unavailable

It appears that Rigol changed not only ECC keys, but also license code format.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on December 30, 2013, 04:08:03 pm
I tried option DSBA on my non-A model with the latest firmware, it said "option installed" but I can't find any changes, certainly not the 50 Ohm option. Would there be a key for that since it is build into all A models as a standard?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 30, 2013, 04:11:09 pm
I tried option DSBA on my non-A model with the laters firmware, it said "option installed" but I can't find any changes, certainly not the 50 Ohm option. Would there be a key for that since it is build into all A models as a standard?

I think it's unlikely. It's a standard feature on new A-models (and so one of their new selling points vs. non-A models), so it I doubt it would ever be sold as an 'option' specifically for HW v.2 non-A owners - thus no key. But perhaps the FW can be patched to enable it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on December 30, 2013, 04:16:44 pm
I tried option DSBA on my non-A model with the laters firmware, it said "option installed" but I can't find any changes, certainly not the 50 Ohm option. Would there be a key for that since it is build into all A models as a standard?

I think it's unlikely. It's a standard feature on new A-models (and so one of their new selling points vs. non-A models), so it I doubt it would ever be sold as an 'option' specifically for HW v.2 non-A owners - thus no key. But perhaps the FW can be patched to enable it.

I agree, but also wonder what the difference is between the A and non-A models so that the 50 Ohm works on the A but not on the non-A 2.0 hardware. Maybe it is as simple as the model number?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 30, 2013, 04:19:34 pm
I agree, but also wonder what the difference is between the A and non-A models so that the 50 Ohm works on the A but not on the non-A 2.0 hardware. Maybe it is as simple as the model number?

It could be... changing the model number of the DSOs was all was that required to enable the different BW settings on non-A models. OTOH, as zombie28 pointed out, Rigol has changed a few things to 'enhance' security on the A-models - although that might be irrelevant in this case.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on December 30, 2013, 04:45:51 pm
@zombie28: so what to do ... wait for cybernet to find something? ^^
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on December 30, 2013, 04:53:38 pm
OTOH, as zombie28 pointed out, Rigol has changed a few things to 'enhance' security on the A-models - although that might be irrelevant in this case.

It would be interesting to see what they did to enhance the security, because both A and non-A run on the same firmware, and my non-A still responds to the 'old' keys. Maybe the 2 things are related and it is based on the model number.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: staze on December 30, 2013, 05:08:50 pm
Or serial number.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on December 30, 2013, 05:33:02 pm
@zombie28: so what to do ... wait for cybernet to find something? ^^

yeah, for cybernet or for anyone who will analyze the new firmware and write a keygen
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on December 30, 2013, 06:02:44 pm
OTOH, as zombie28 pointed out, Rigol has changed a few things to 'enhance' security on the A-models - although that might be irrelevant in this case.

It would be interesting to see what they did to enhance the security, because both A and non-A run on the same firmware, and my non-A still responds to the 'old' keys. Maybe the 2 things are related and it is based on the model number.

I found function that tells licensing engine which version of keys and decoding subroutines to use. This function checks the 4th character of the serial number (i.e. the character after 'DS2') and when it finds anything except 'A' and 'C', then the new version of decoder will be used. For 'A' and 'C' there are some additional checks, but for now I don't know what they mean.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on December 30, 2013, 06:05:29 pm
I found function that tells licensing engine which version of keys and decoding subroutines to use. This function checks the 4th character of the serial number (i.e. the character after 'DS2') and when it finds anything except 'A' and 'C', then the new version of decoder will be used. For 'A' and 'C' there are some additional checks, but for now I don't know what they mean.

 :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on December 30, 2013, 06:42:57 pm
my serial starts with D (after DS2)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Fagear on December 30, 2013, 07:00:35 pm
I found function that tells licensing engine which version of keys and decoding subroutines to use. This function checks the 4th character of the serial number (i.e. the character after 'DS2') and when it finds anything except 'A' and 'C', then the new version of decoder will be used. For 'A' and 'C' there are some additional checks, but for now I don't know what they mean.
Good news. So, it was one of options - to detect A-version by serial #.
Non-A versions of DS2xxx have 'A' letter in serial # and A-versions have 'D' letter.

I think that 50 ohm "option" is enabled the same way. Regardless of HW version (is there resistor or not).

I see two ways: either somebody can hack the updated algorithm or somehow patch the FW to supress this check.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on December 30, 2013, 07:08:35 pm
currently on another track that will hopefully make stuff easier in the future - esp no need for JTAG anymore ;-)

Code: [Select]
bfin> bdinfo
U-Boot      = U-Boot 2013.10 (Dec 30 2013 - 18:01:24)
CPU         = bf526-0.0
Board       = bf526-ezbrd
VCO         =    400 MHz
CCLK        =    400 MHz
SCLK        =    100 MHz
boot_params = 0x00000000
memstart    = 0x00000000
memsize     = 0x02000000
flashstart  = 0x20000000
flashsize   = 0x01000000
flashoffset = 0x00000000
ethaddr     = 02:80:ad:20:31:e8
ip_addr     = 192.168.0.15
baudrate    = 57600 bps
bfin> flinfo

Bank # 1: CFI conformant flash (16 x 16)  Size: 16 MB in 71 Sectors
  AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x227E2101
  Advanced Sector Protection (PPB) enabled
  Erase timeout: 4096 ms, write timeout: 1 ms
  Buffer write timeout: 3 ms, buffer size: 64 bytes

  Sector Start Addresses:
  20000000   RO   20020000   RO   20040000   RO   20060000   RO   20080000   RO
  200A0000   RO   200C0000        200E0000        20100000        20120000     
  20140000        20160000        20180000        201A0000        201C0000     
  201E0000        20200000        20220000        20240000        20260000     
  20280000        202A0000        202C0000        202E0000        20300000     
  20320000        20340000        20360000        20380000        203A0000     
  203C0000        203E0000   RO   20400000   RO   20420000   RO   20440000   RO
  20460000   RO   20480000   RO   204A0000        204C0000        204E0000     
  20500000        20520000        20540000        20560000        20580000     
  205A0000        205C0000        205E0000        20600000        20620000     
  20640000        20660000        20680000        206A0000        206C0000     
  206E0000        20700000        20720000        20740000        20760000     
  20780000        207A0000        207C0000        207E0000        20800000     
  20820000   RO   20840000   RO   20860000   RO   20880000   RO   208A0000   RO
  208C0000   RO
bfin> reginfo

System Configuration registers

PLL Registers
PLL_DIV:   0x0004   PLL_CTL:      0x2000
PLL_STAT:  0x00a2   PLL_LOCKCNT:  0xffff
VR_CTL:    0x70f0

EBIU AMC Registers
EBIU_AMGCTL:   0x00f9
EBIU_AMBCTL0:  0xbbc3bbc3   EBIU_AMBCTL1:  0xb6ab77c3

EBIU SDC Registers
EBIU_SDRRC:   0x0fff   EBIU_SDBCTL:  0x0013
EBIU_SDSTAT:  0x0000   EBIU_SDGCTL:  0x8011998d

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 30, 2013, 07:29:12 pm
Just to keep owners that aren't reading the DS2000 review thread informed:

More bugs keep getting discovered when running the 300MHz option on HW v.1 DS2000 models (I just posted another here (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg356554/#msg356554)).

Whether those bugs exist for HW v.2 or A-model owners, I couldn't say - but considering that we've found a few of them - and that on HW v.1 models the BW only seems to increase by ~60MHz (to somewhere between ~280 - 300MHz), you might want to consider if the advantages outweigh the disadvantages before installing the option (on HW v.1)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: m-joy on December 30, 2013, 07:42:11 pm
Just to keep owners that aren't reading the DS2000 review thread informed:

More bugs keep getting discovered when running the 300MHz option on HW v.1 DS2000 models (I just posted another here (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg356554/#msg356554)).

Whether those bugs exist for HW v.2 or A-model owners, I couldn't say - but considering that we've found a few of them - and that on HW v.1 models the BW only seems to increase by ~60MHz (to somewhere between ~280 - 300MHz), you might want to consider if the advantages outweigh the disadvantages before installing the option (on HW v.1

But 200MHz works fine?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on December 30, 2013, 07:57:50 pm
But 200MHz works fine?

Sure - every version of the DS2000 hardware has been designed to work to 200MHz-2ns/div.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Git on January 01, 2014, 06:58:01 pm
Hello,
Just to make sure: Is the JTAG-port on DS2202A at 3.3 Volt?
Yes, I think.

It shouldn't matter anyway,  your JTAG box should power its output stage from the target machines supply. Some, if not most, are happy from 1.8V to 5V.

Git
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on January 01, 2014, 07:03:03 pm
currently on another track that will hopefully make stuff easier in the future - esp no need for JTAG anymore ;-)

I'm eagerly awaiting what this track will result in!!!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pascal_sweden on January 01, 2014, 10:38:35 pm
Just got a new DS2072A.  I converted to DS2202A with all options (via old FW and old private key).
Will the scope function correctly with the old firmware? Has anyone noted any problems? 

Also, I 'lost' the serial number in the process, and the scope is now using default value.  On the DG4000 via cengen (see elsewhere on this forum) you can generate a license.GEL file through which one can also apparently mod the serial number.  Is such a thing possible for the DS2000?  Is there anyway to restore the serial number ?  Is there any real harm in having the default?
The scope doesn't ever try call Rigol if ethernet connected right?

Thanks
Steven

What if you upgrade the FW back to the newer A version? Will the options stay?
Are you up to 200MHz? Or did you even manage to get upto 300MHz?
I am interested in DS2072A but want to wait until the hack is confirmed with new FW and all options enabled, including 300MHz and CAN decoding.
Can still get old DS2072 here in Sweden, maybe that is better? But that one does not get up to 300MHz, so maybe better to wait? Do you really need 50 ohm impedance? That you can fix externally with BNC adapter not?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on January 01, 2014, 10:48:39 pm
If you just read some pages of this thread at least, it seems that it's very close to fixing it for the A series
At least I ordered the A series in anticipation of the keygen
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 01, 2014, 10:55:03 pm
What if you upgrade the FW back to the newer A version? Will the options stay?

A is model type - v.2 is the newer FW. But upgrading to v.2 FW with options enabled on A models does not retain the options; there is a different version of the key and decoding for them in v.2 FW.

BTW, I've heard Rigol is working on new security measures for all the devices which have been hacked - so if anyone has been on the fence about purchasing one of them (and you want to be certain you can run the current versions of keygens), it might be best to act soon.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pascal_sweden on January 01, 2014, 11:10:45 pm
Is somebody actively working on this hack for the DS2072A?

Has it been confirmed already that the HW design is identical between DS2072A and DS2302A?

I know that it has been confirmed between DS2072 and DS2202, but not for the A series AFAIK, and especially not for the new 300 MHz variant.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on January 01, 2014, 11:13:18 pm
It have also been christmas holiday, and the jtag dumps are just a few days old..
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 01, 2014, 11:13:54 pm
Is somebody actively working on this hack for the DS2072A?
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg356559/#msg356559 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg356559/#msg356559)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on January 02, 2014, 01:00:10 am
Is somebody actively working on this hack for the DS2072A?

Yes, I have analysed most of the DS2KA license decoder, but still missing a few details, so stay tuned...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on January 02, 2014, 01:06:39 am
played with memory layout and lcd/keypad ..
there is some tricky memory mapping, windowing ongoing using probably the FPGA or some other glue logic to toggle address highlines for various other devices on the EBIU bus.
the keypad and the LEDs use SPORT0 - in SPI mode, 16bit payload - i can switch on/off leds now
keypad reading is done via DMA (sucks) - still not much clue here.
found the LCD routines and somewhat of a mapping, can turn backlight on/off and there is some clue on how pixels are written - anyone got the datasheet for the LCD ? ;-)
while playing with the LCD i found the boot logos etc .. (its all done in the bootldr btw) - and that also explains section#2 gel file content.
the overlapping addresses in the gel file, are okay - because some of the addtional bits toggle the memory window - thats what i will investigate next.

the goal for now is to get u-boot flashed instead of the rigol bootldr and then running a uclinux from the USB stick, or booting the rigol application LDR from flash.
@zombie28 - when u got some spare time and want to play with it, drop me a PM with your email - i will send u a tool to re-assemble GEL files, with that maybe u can force the old keys for A series in the meantime.

section #2 in the GEL file contains 16bit raw images used for the RIGOL & ultravision logo (2 logos) in bootldr.
section: #02:   CRC:52C1A46B ADDR:20000000 LEN:69472 OFS:4861550 [VALID CRC]

some stupid proggy to check concept ...

Code: [Select]
reading: ultravision.bin
len: 6872
height: 34 width: 101
                                                                 X                                   
                                                                XX                                   
                                                               XXXX                                 
                                                               XXXX                                 
                                                              XXXXX                                 
                                               XX             XXXXX                                 
                                              XXX            XXXXXX                                 
                                             XXXX            XXXXXXX                                 
                                            XXXXXX          XXXXXXXX                                 
                                       XXXXXXXXXXX          XXXXXXXX                                 
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX         XXXXXXXXX                                 
     XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX         XXXXXXXXX                                 
            X                   XXXXXXXXXXXXXXXXXXX       XXXXXXXXXX                                 
            X                                 XXXXX       XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
            X     XX                           XXXX      XXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX   
    XX     XX    XXX                           XXXXX     XXXXX   XXXXXXXXXXXX                       
  XXXX     XX    XXX                           XXXXX    XXXXXX   XXXXXX                             
  XXXX    XXX   XXX    XXX                     XXXXX    XXXXX    XXXXX                               
 XXXXX    XXX   XXX   XXXX                      XXXX   XXXXXX    XXXX                               
 XXXXX    XXX  XXX    XXXX                      XXXXX XXXXXX XXX  XX         XXX                     
XXXXXX   XXX   XXX   XXXXXX                     XXXXX XXXXX  XXX       XXX   XXX                     
XXXXX    XXX  XXX XXXXXXXXXXXXX            XX   XXXXXXXXXXX  XXX     XXXXX   XXX    XXXXX    XXXXXXX
XXXXX    XXX  XXXXXXXXXXXXXXX XXXXX      XXXXX  XXXXXXXXXX          XXXXXX         XXXXXXX   XXXXXXXX
XXXXX   XXXX XXX XXXXXXXX    XXXXXXXX   XXXXXXX  XXXXXXXXX   XX    XXXXX     XX    XXXXXXX   XXXXXXXX
XXXX    XXX  XXX  XXXXXX     XXXXXXXX XXXXXXXXX  XXXXXXXX   XXXX   XXXX     XXX   XXXXXXXX  XXXXXXXXX
XXXX    XXX  XXX   XXXXX     XXXX  X XXXX XXXX   XXXXXXXX   XXXX   XXXX    XXXX  XXXXX XXX  XXXX XXXX
XXXX   XXXX  XXX   XXXX     XXXX    XXXXXXXXXX   XXXXXXX   XXXX     XXXX   XXXX  XXXX  XXX  XXXX XXX
XXXXX  XXXX  XX    XXXX     XXX     XXXXXXXXXX    XXXXX    XXXX      XXXX XXXXX  XXXX XXXX  XXX  XXX
XXXXXXXXXXX  XX    XXXX     XXX    XXXXXXXXXX     XXXXX    XXXX      XXXX XXXX   XXX XXXXX XXXX  XXX
 XXXXXXXXX   XXX   XXXXX    XXX    XXXXXX XXX     XXXX     XXXXXXXXXXXXXX XXXX X XXXXXXXXX XXXX  XXX
  XXXXXXXX   XXX   XXXXX    XXX     XXXXX XXX     XXXX     XXXXXXXXXXXXX  XXXXXX XXXXXXXX  XXX   XXX
   XXXXXX     XXXX XXXX     XX       XX   XXX      XX      XXXXX           XXXX  XXXXXXX    XX    XXX
               XX           XX            XXXX     X        XX              XX      X             XXX
                                           XX      X                                                 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 02, 2014, 02:39:23 am
anyone got the datasheet for the LCD ? ;-)
I just skipped through Dave's 39 minute teardown video to find the LCD model number:
https://www.eevblog.com/forum/blog/eevblog-360-rigol-ds2000-oscilloscope-teardown/ (https://www.eevblog.com/forum/blog/eevblog-360-rigol-ds2000-oscilloscope-teardown/)

EEVblog #360 - Rigol DS2000 Oscilloscope Teardown (https://www.youtube.com/watch?v=BWZXGzAVkD8#ws)
@20:04 (http://youtu.be/BWZXGzAVkD8?t=20m4s) it says 20000938-00 on the LCD flex cable:
http://www.flickr.com/photos/eevblog/8022120602/#in/set-72157631618295437/ (http://www.flickr.com/photos/eevblog/8022120602/#in/set-72157631618295437/)
(http://farm9.staticflickr.com/8451/8022120602_51a81159fe.jpg)

I tried googling 20000938-00 and got several hits for InnoLux AT070TN90

Couldn't find the datasheet at: http://www.innolux.com/pages/en/index_en.html (http://www.innolux.com/pages/en/index_en.html)

But I found it here:
InnoLux AT070TN90 datasheet https://www.olimex.com/Products/OLinuXino/A13/A13-LCD7-TS/resources/AT070TN90.pdf (https://www.olimex.com/Products/OLinuXino/A13/A13-LCD7-TS/resources/AT070TN90.pdf)

This is a 7 inch (800x480) display, but Rigol says DS2000 has a "8 inch TFT (800x480) WVGA" display. But the pinout an communication is probably identical since they have the same resolution.

http://www.rigol.com/prodserv/DS2000A/ (http://www.rigol.com/prodserv/DS2000A/) the silkscreen says the LCD flex connector has 50 pins, and the datasheet also says 50 pins and even recommend a Hirose FH12A-50S-0.5SH (http://www.hirose.co.jp/cataloge_hp/e58605370.pdf) connector, similar to the conector used by Rigol.

Edit: I found a 8'' InnoLux AT080TN64 with the same 20000938-00 silkscreen on the LCD flex cable: http://www.aliexpress.com/item/8-lcd-screen-highlight-the-at080tn64-car-screen-qau-1/1179092514.html (http://www.aliexpress.com/item/8-lcd-screen-highlight-the-at080tn64-car-screen-qau-1/1179092514.html)

(http://img01.cp.aliimg.com/bao/uploaded/i1/913129907/T2t2UXXjXXXXXXXXXX_!!913129907.jpg)

(http://img01.cp.aliimg.com/bao/uploaded/i2/913129907/T288MXXcXaXXXXXXXX_!!913129907.jpg)


Same 50-pin connector and both use 3.3V TTL Parallel RGB interfacing.
Here's the datasheet for InnoLux AT080TN64: http://www.nilocom.com/files/AT080TN64.pdf (http://www.nilocom.com/files/AT080TN64.pdf)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on January 02, 2014, 05:35:20 am
BTW, I've heard Rigol is working on new security measures for all the devices which have been hacked - so if anyone has been on the fence about purchasing one of them (and you want to be certain you can run the current versions of keygens), it might be best to act soon.

That's great news.  Perhaps they can manage to kill off their sales to hobbyists and students.  :-DD  It would be nice though if they spent that priority manpower in fixing bugs in their units, first.  Rather than letting them languish for half a year or more without being addressed.

And one thing to keep in mind about buying the current (hackable) products: they have numerous known software problems (and likely others not yet known, or less visible... such as broken/missing SCPI).  Naturally most will want to take advantage of the fixes, but it won't be surprising if there's a price to pay for that.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 02, 2014, 05:53:42 am
That's great news.  Perhaps they can manage to kill off their sales to hobbyists and students.  It would be nice though if they spent that priority manpower in fixing bugs in their units, first.  Rather than letting them languish for half a year or more without being addressed.

This was all inevitable and predicted 6 months ago in this very thread. I'm all for free stuff, but there is just no way a company will ignore this - and you can bet you ass that Agilent is working to stop the hacks published in the other thread here too.

Quote
And one thing to keep in mind about buying the current (hackable) products: they have numerous known software problems (and likely others not yet known, or less visible... such as broken/missing SCPI).  Naturally most will want to take advantage of the fixes, but it won't be surprising if there's a price to pay for that.

Well, no, as shown by the DS2000/DS2000A, they can't stop the hacks working for owners of the current models without voiding all of the legal, paid-for options - they have to release newer/upgraded models. That was my point.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gallymimus on January 02, 2014, 05:53:47 am

That's great news.  Perhaps they can manage to kill off their sales to hobbyists and students.  :-DD  It would be nice though if they spent that priority manpower in fixing bugs in their units, first.  Rather than letting them languish for half a year or more without being addressed.


Really, you think they should not worry about people stealing their products?  They should just focus on fixing bugs while their margins are being damaged?  That's great logic.  |O  Rigol is a business, they have to make some money.  If they think that working on security is going to protect their bottom line better than fixing bugs then it's OUR fault for pushing them to that by hacking their products.  :--

I'm a big fan of altering the function of hardware myself but to act like Rigol should embrace theft because it increases volume on their lowest margin sales and to justify this behavior kinda irritates me.  :palm:.  Rigol likely depends on the adders beyond base to add profit above likely thin margins.  In addition, in a low volume business they have a LOT of non-recurring engineering costs to amortize over the life of the product.

Don't get me wrong.  I read this thread every day (and have read every message in every page), and love the work, ingenuity and features that have been unlocked.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Neomulgus on January 02, 2014, 06:36:05 am
Really, you think they should not worry about people stealing their products?
I'm a big fan of altering the function of hardware myself but to act like Rigol should embrace theft because it increases volume on their lowest margin sales and to justify this behavior kinda irritates me.  :palm:.  Rigol likely depends on the adders beyond base to add profit above likely thin margins.  In addition, in a low volume business they have a LOT of non-recurring engineering costs to amortize over the life of the product.

There are people who bought a 2072 cum 2200 over an alternative scope (or an old beater off Ebay) just because the hack tipped the balance on their buying decision. I find it hard to equate that to "theft" in this instance. They got some money at least, when the alternative was no money at all from that class of buyer.

The question for Rigol is whether those "bottom feeders" are a valuable enough resource to tolerate their antics, even if they cannibalize the professional market a bit. My bet is it's only a little lost lucre versus containerloads of scopes sold as a direct result of threads like this one. Rigol would be best to grin and bear it all the way to the bank.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 02, 2014, 06:42:18 am
The question for Rigol is whether those "bottom feeders" are a valuable enough resource to tolerate their antics, even if they cannibalize the professional market a bit. My bet is it's only a little lost lucre versus containerloads of scopes sold as a direct result of threads like this one. Rigol would be best to grin and bear it all the way to the bank.

This argument has been going on in this forum since 2010 - when the Rigol D1052E was hacked (and Dave published a video about it). Regardless of whatever you think might be best for Rigol to do, the fact of the matter is, they fought against the hacks in 2010 - and they are fighting against the hacks now - just as many of us expected they'd do. And from Rigol's point of view, the stakes are even higher now - with the keygen working not only for DSOs - but other equipment as well.

And just as the hacks of the DS1000E series disrupted bug-fixes and FW releases (and created new bugs), so is it all likely to happen again. But, hey, that's the trade-off - for both us and Rigol.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on January 02, 2014, 07:59:40 am
That's great news.  Perhaps they can manage to kill off their sales to hobbyists and students.  :-DD  It would be nice though if they spent that priority manpower in fixing bugs in their units, first.  Rather than letting them languish for half a year or more without being addressed.

Really, you think they should not worry about people stealing their products?

Hmm.  I can't see where you got that, from what I wrote?  I'd really appreciate it if you wouldn't put words in my mouth.  And I wasn't aware anyone was "stealing" their products!  :o   AFAIK, everyone here was buying their Rigol's.   :-//  Was there a "back of the truck sale" I missed out on?

Presumably you wouldn't consider upgrading the software on a Rigol stealing, since you did so on both your DS1052E and DS1074Z, right?

Quote
Rigol is a business, they have to make some money.

I'm quite sure they're making money.  Let me ask you this, since you were so incensed by my comment... if someone buys a DS2072A and never upgrades the memory capacity option, who's being robbed?  They've already paid for the additional 28 MB of memory, because it's installed in every unit, whether it's ever turned on or not.  But for "only" 40% of the cost of their entire scope, they can enable the memory that's already been paid for.   ???  Certainly seems both fair and logical to me.   ::)

Quote
I'm a big fan of altering the function of hardware myself but...

but, but, but...

Quote
...to act like Rigol should embrace theft because it increases volume on their lowest margin sales and to justify this behavior kinda irritates me.  :palm:. 

Yes, I can see that.  :)  Especially when no one here has been advocating theft.

Look, as marmad has said here, more than once, Rigol isn't particularly happy about this, and has taken steps in the past to rectify it, and will take more steps in the future.  They have a perfect right to do so (i.e., to try to stop hacking).  However, my comment was simply that it's obvious they have limited manpower available.  Otherwise they'd be fixing and improving the software much more quickly than they've ever demonstrated an ability to do so, in all the years they've been in business.  And I questioned whether that's the best use of those limited resources.  IMO, it's not, but in their opinion, it is.  That's fine.

The primary (if not exclusive) impact of locking things down will be reduced sales to folks that have very limited funds to start with.  Meaning hobbyists, beginners, students, etc.  Do you really think that pro's (spending company funds) and engineering firms with $$$ resources are buying Rigol's for cheap and unlocking features w/o paying for them?  I don't.  If they need a 300 MHz scope, they buy one.  Not buy a 70 MHz-rated one, and cross their fingers it will work at 300.  That would be foolish indeed.

But the result of having a pool of hobbyists [or even pro's, with limited funds for a home lab] with access to the technology, and experience with Rigols, will mean that if they're in a position to recommend something, it's that much more likely to be something they're familiar with.  Like... a Rigol.  Or if they bring their Rigol into work one day, or to a client site, Rigol gets exposure they would not have otherwise.  And as a result, increased sales.  So in a very real sense, Rigol could consider these hobbyist sales as "seeds" being planted.  That will bear enhanced fruit later.  And as low-cost promotion and 'advertising' for their brand.

Obviously, these are not important factors to them (or they simply have failed to recognize the potential benefits), and again, that's fine.  I never said, "How dare you?" or "Curse you, Red Baron!"   Or shook my fist at the sky.  :rant:

Quote
Don't get me wrong.  I read this thread every day (and have read every message in every page), and love the work, ingenuity and features that have been unlocked.

And that you've personally benefited from.  Yes, I'll try very hard not to get you wrong.   ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 02, 2014, 08:30:45 am
The primary (if not exclusive) impact of locking things down will be reduced sales to folks that have very limited funds to start with.  Meaning hobbyists, beginners, students, etc.  Do you really think that pro's (spending company funds) and engineering firms with $$$ resources are buying Rigol's for cheap and unlocking features w/o paying for them?  I don't.  If they need a 300 MHz scope, they buy one.  Not buy a 70 MHz-rated one, and cross their fingers it will work at 300.  That would be foolish indeed.

But the result of having a pool of hobbyists [or even pro's, with limited funds for a home lab] with access to the technology, and experience with Rigols, will mean that if they're in a position to recommend something, it's that much more likely to be something they're familiar with.  Like... a Rigol.  Or if they bring their Rigol into work one day, or to a client site, Rigol gets exposure they would not have otherwise.  And as a result, increased sales.  So in a very real sense, Rigol could consider these hobbyist sales as "seeds" being planted.  That will bear enhanced fruit later.  And as low-cost promotion and 'advertising' for their brand.

It wouldn't surprise me if a discussion similar to the one we have here happens between some people in the upper echelons at Rigol. They must consider, at least to some degree, the pros and cons of fighting the hacks. But when hacks are easy and foolproof (like keygens) and begin to get widely published - even owners that would normally buy extra options over time don't. If you spent $2800 or more for one of the DS4000s, you very well might have spent more money later on for one or more of the options - but with a online keygen available, it's not as likely. I'm afraid, from Rigol's point of view, this has gotten out of hand - spreading between the product lines - and they have to at least make an effort to fight it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on January 02, 2014, 09:01:49 am
It wouldn't surprise me if a discussion similar to the one we have here happens between some people in the upper echelons at Rigol. They must consider, at least to some degree, the pros and cons of fighting the hacks.

But when hacks are easy and foolproof (like keygens) and begin to get widely published - even owners that would normally buy extra options over time don't. If you spent $2800 or more for one of the DS4000s, you very well might have spent more money later on for one or more of the options - but with a online keygen available, it's not as likely.

I'm afraid, from Rigol's point of view, this has gotten out of hand - spreading between the product lines - and they have to at least make an effort to fight it.

Good points, and I have to agree with all of them. 

I knew (but hadn't given much thought to), the fact that their keygen's are now cross-product lines.  Scopes, wave gens, power supplies, spectrum analyzers...  So the impact is much larger.  Sales of Options may well be down, across the board.  And their Resellers are likely crying to them, because they love making hundreds of $$$ profit selling pieces of paper with numbers on them.  Nothing to inventory, nothing to ship.  Just rake in the cash.

And your example of the DS4000 owner (with a large initial investment), deferring purchase of some useful options until later, then not doing so because of the publicized hacks, was very apropo.  I could definitely see that happening.

So, yes, you're right.

[Sorry.  Gotta run.  Need to get that DS4014 ordered right away.   8)]
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sync on January 02, 2014, 01:27:07 pm
That's great news.  Perhaps they can manage to kill off their sales to hobbyists and students.
And what scopes do they buy instead?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on January 02, 2014, 01:56:52 pm
Rigol can't afford to ignore the hacks, but they would be wise to view them as an opportunity rather than an attack.

Many of us purchased Rigol equipment solely or primarily because we could hack them.  As stated, once this becomes too easy, a line is crossed: even those that can afford the high-end options will stop paying for them, favoring the hacks.  That is the point where Rigol will really care, as real money starts getting lost.  (Let's assume for a moment that no hobbyist at all will ever buy a high-end scope.)

It would be very wise for us if we did not bite the hand that feeds us by making the hacks too easy to use.  There needs to be a minimum amount of skill required to accomplish the hacks.  I don't know what this skill level should be, but making web apps capable of providing valid keys by providing a serial number and a four character option code is definitely something that I would consider "biting the hand that feeds us."
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ZeroAviation on January 02, 2014, 04:38:27 pm
Many of us purchased Rigol equipment solely or primarily because we could hack them. 

This.

I would much rather have bought a Agilent scope. But I went with the Rigol because I could enable the extra functions. If the hack didnt exsist, I would had saved up for a few more months for the Agilent. They win as far as customer support hands down.

Broke hobbyist like me, can't afford a Agilent $1.2k DSO with another $4k in options. But we can pull of $700~ after several months of saving.

-Matt
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on January 02, 2014, 06:28:04 pm
Many of us purchased Rigol equipment solely or primarily because we could hack them.

Me too. I bought a scope and a spectrum analyzer precisely because there are option hacks. And then I bought a signal generator (without the hack option) because I like their products now.

It would be very wise for us if we did not bite the hand that feeds us by making the hacks too easy to use.  There needs to be a minimum amount of skill required to accomplish the hacks.

The website with this generator is far to easy to use. Maybe Rigol can ignore some source code to compile somewhere in a ee-forum. But a website with a keygen generator for the masses? Seriously?

Tribute to cybernet and the other guys. You all do absolute awesome work!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on January 02, 2014, 07:15:43 pm
some progress - there is another hidden key in the bootloader, that will launch arbitrary LDR files from USB sticks (without flashing anything ;-)
i've got now a partly working u-boot that can load from USB stick - and hence transfer a linux image via tftp .. booting that, is another topic, but its coming along ...

Code: [Select]
## Booting kernel from Legacy Image at 00000100 ...
   Image Name:   bf526-0.0-3.10.10
   Created:      2013-12-30  23:46:15 UTC
   Image Type:   Blackfin Linux Kernel Image (gzip compressed)
   Data Size:    1377250 Bytes = 1.3 MiB
   Load Address: 00001000
   Entry Point:  0024cac0
   Verifying Checksum ... OK
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ZeroAviation on January 02, 2014, 07:20:41 pm

Me too. I bought a scope and a spectrum analyzer precisely because there are option hacks. And then I bought a signal generator (without the hack option) because I like their products now.

Same here I got sucked in on the first DS1052E Hack, now 4 RIGOL products later. ( See Pic )

Rigol, stop worrying about what we do with 'upgrading' your products, and start concentrating on customer support and software bugs.

To be frank, if they close these holes, i'll spend the very small margin extra for Agilent.

On the other side, I wonder what percentage of their customer base realizes these can be 'hacked'

Back on topic.....
Cybernet - Keep up the good work mate.

-Matt

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Wall-E on January 02, 2014, 07:43:39 pm
Re. DP832 Power Supply

Does the 1.03c Keygen still work on the DP832?  I understand that 1. Firmware 01.06.00 should be installed,  2. Install the keys, and then 3. Upgrade the firmware to 01.08.00.
Does this still work Ok?   I seem to recall that someone said they lost everything including the metering accuracy.
Is there anything to this, and if so, can it be prevented?

Thank you for assistance, Wallie
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on January 02, 2014, 08:01:20 pm
cybernet: what are you trying to achieve? unlocking the A-versions or running an edited firmware or something else? :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Teneyes on January 02, 2014, 08:05:47 pm
cybernet: what are you trying to achive?
@NikWing        Teasing You   ;D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on January 02, 2014, 08:08:44 pm
The website with this generator is far to easy to use. Maybe Rigol can ignore some source code to compile somewhere in a ee-forum. But a website with a keygen generator for the masses? Seriously?

This was my point exactly.  I agree with you 100% and we need to carefully watch what we're doing as a community if we're to remain on the good side of the companies whose products we are modifying if we wish to remain outside their sphere of awareness.

The MAME and MESS projects (as crude examples) do an excellent job of this, mainly by not disassembling or reversing ANYTHING released in the previous 5 years.  I'm not saying that we should follow this pattern exactly, but there should be a defined no-man's land in terms of reversing, if we care about avoiding negative attention from the hardware vendors we are "blessing" with our hacking efforts.  (As an aside, I think the MAME & MESS folks should develop for FPGAs rather than software alone, if they truly want to document the hardware of those old systems.  Those of you familiar with this software will know what I mean.)

There are only a few in this thread who do the core contribution to & development of these hacks, and many assists who make things like the precompiled executables and the web pages, and provide the leaps in ease of use.  If the few important folks decide that biting the hand that feeds us is a bad course of action, then they should communicate that and we should all work together and silently cooperate with Rigol by leaving their latest lines alone.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pascal_sweden on January 02, 2014, 09:20:22 pm
Bottom line: is the DS2072A hackable to 300 MHz with all options or not?

I don't mind running a script or compiling a Linux program.
Still it would convince me to buy the unit.

The old unit DS2072 is still available, but I guess it is wise to buy the newer unit from a support perspective, or is there no concern here?

How long does it typically take to come up with a new hack? =)
I need to buy my scope latest next week :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: echen1024 on January 02, 2014, 09:57:07 pm
Bottom line: is the DS2072A hackable to 300 MHz with all options or not?

I don't mind running a script or compiling a Linux program.
Still it would convince me to buy the unit.

The old unit DS2072 is still available, but I guess it is wise to buy the newer unit from a support perspective, or is there no concern here?

How long does it typically take to come up with a new hack? =)
I need to buy my scope latest next week :)
Well, it depends on if they decide to change the encryption algorithm or not.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on January 03, 2014, 01:39:10 am
Bottom line: is the DS2072A hackable to 300 MHz with all options or not?

Not yet, but I believe it will be soon.

I have just finished analysis of license decoder and collected enough information to rewrite it into C. If anyone has A-type license code and doesn't mind sharing it with me, please send me PM. This would speed up the whole process.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 03, 2014, 06:42:21 am
The old unit DS2072 is still available, but I guess it is wise to buy the newer unit from a support perspective, or is there no concern here?

There is no concern that support for non-A models will stop; there have been MANY of them sold - the FW works for both models. It will be a long time until as many A models are sold.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: chebeba on January 03, 2014, 09:35:42 am
I have just finished analysis of license decoder and collected enough information to rewrite it into C.

Just out of curiosity, and maybe because I am looking a little bit at learning to code for CUDA:

Couldn't this be used to brute force the new private key? It's only 48 bits, as far as I can see...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 03, 2014, 09:41:25 am
I have just finished analysis of license decoder and collected enough information to rewrite it into C.
Just out of curiosity, and maybe because I am looking a little bit at learning to code for CUDA:

Couldn't this be used to brute force the new private key? It's only 48 bits, as far as I can see...

zombie28 has already posted the new private key:

I found function that loads alternative public key in DS2K-A firmware. The new public key is 0xA51BF373712F7D and the private key (that matches old Rigol ECC parameters) is 0x888E77EE47C50A. I don't have DS2K-A scope yet, so I can't confirm if this key will work with existing keygens.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on January 03, 2014, 02:18:11 pm
yes, but there's something else missing since this private key doesn't work yet
I think that's what zombie28's working on atm
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Co6aka on January 03, 2014, 06:24:25 pm
Well, it depends on if they decide to change the encryption algorithm or not.

Actually, if code can be "debugged" it can be hacked, so it doesn't really matter what algos are used; at some point (in the code) there's a "BNE" on an invalid key that can be "NOP'ed" out. (Also, the encryption routines can be copied out and reversed, and somewhere has got to be the private key.) They could make life difficult by employing obfuscation, self-decrypting code, anti-debugging, and etc. They could disable/remove debugging support from the hardware, encrypt the firmware and embed decryption in the CPU, pot the whole thing, and require units to be sent in for firmware upgrades... :-DD

Bottom line: It's hackable. Period. Get over it. Let the popularity boost sales and capture market share, bump up prices accordingly, and sell lotsa hardware. Heck, open source the thing, and let the hacker community develop advanced features and bug fixes. Let the staff coders focus on new products, and assign one to "manage" the open source project.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cidcorp on January 03, 2014, 06:33:45 pm
Re. DP832 Power Supply

Does the 1.03c Keygen still work on the DP832?  I understand that 1. Firmware 01.06.00 should be installed,  2. Install the keys, and then 3. Upgrade the firmware to 01.08.00.
Does this still work Ok?   I seem to recall that someone said they lost everything including the metering accuracy.
Is there anything to this, and if so, can it be prevented?

Thank you for assistance, Wallie

Wallie,

I think there's been a couple questions asked regarding the DP832 and using the Keygen, but it appears no one has the answer.

I've been following this thread since the beginning and my head is starting to spin -  :scared:

As a summary to the thread, the DS2000 non A models: HW 1 upgradable (but someone has voiced issues regarding the 300Mhz mod causing issues, so stick to 200Mhz as the max bandwidth upgrade) - 50 Ohm Option doesn't work, HW 2 is upgradable to 300Mhz - 50 Ohm option is working.  The DS2000 A models are currently not hackable but zombie28 is looking close to solving that.

As for the DP832, I seem to remember someone stating the keygen is working, but just a few pages ago someone also said they lost the ADC accuracy (or something like that) after using the keys to upgrade, I'm holding out until someone confirms the key gen isn't causing issues on the DP832.

Edit: Well this thread is becoming a monster - I have checked back in the thread an can't find any confirmation of the 50 ohm termination option on the HW version 2 non-A, so I may be wrong there.


Chris
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on January 03, 2014, 06:47:22 pm
HW 2 is upgradable to 300Mhz - 50 Ohm option is working.

I don't think anyone has the 50 ohm option working on their non A model yet do they?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: m-joy on January 03, 2014, 06:57:20 pm
i thought 300 Mhz is "buggy" on all devices...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 03, 2014, 08:08:03 pm
Heck, open source the thing, and let the hacker community develop advanced features and bug fixes. Let the staff coders focus on new products, and assign one to "manage" the open source project.

Yeah, that's gonna happen  :-DD
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cidcorp on January 04, 2014, 12:53:06 am
i thought 300 Mhz is "buggy" on all devices...

I thought the issues were only with the version 1 HW, which is what I have... 

Chris
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Co6aka on January 04, 2014, 03:44:28 am
:-DD

Exactly... :-DD  (Makes way-way too much sense, so...)


Got a shiny new Amontec JTAGkey2P sitting on my bench right in front of my DSA1030A...  >:D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gallymimus on January 04, 2014, 04:03:52 am


Actually, if code can be "debugged" it can be hacked, so it doesn't really matter what algos are used; at some point (in the code) there's a "BNE" on an invalid key that can be "NOP'ed" out. (Also, the encryption routines can be copied out and reversed, and somewhere has got to be the private key.) They could make life difficult by employing obfuscation, self-decrypting code, anti-debugging, and etc. They could disable/remove debugging support from the hardware, encrypt the firmware and embed decryption in the CPU, pot the whole thing, and require units to be sent in for firmware upgrades... :-DD

Bottom line: It's hackable. Period. Get over it. Let the popularity boost sales and capture market share, bump up prices accordingly, and sell lotsa hardware. Heck, open source the thing, and let the hacker community develop advanced features and bug fixes. Let the staff coders focus on new products, and assign one to "manage" the open source project.

 :-DD |O  NAIVE!  |O :-DD
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on January 04, 2014, 09:52:50 am
Heck, open source the thing, and let the hacker community develop advanced features and bug fixes. Let the staff coders focus on new products, and assign one to "manage" the open source project.

Yeah, that's gonna happen  :-DD

Well, I'm sure other scope companies would appreciate that.   :o  Heck, then even Hantek might have at a chance at halfway decent firmware.  And their scopes would finally support SCPI.

The downside would be that the competition would then lay off their teams of development programmers.  Do you really want that one guy at Hantek to be out of a job?   :'(
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on January 04, 2014, 02:15:22 pm
So here it is, the new license code decoder:

Code: [Select]
//
// Copyright (c) 2013 RIGLOL Technologies, Inc. All Rights Reversed.
// This product includes software developed by the OpenSSL Project
// for use in the OpenSSL Toolkit. (http://www.openssl.org/)
//
#include <string.h>
#include "rc5.h"

typedef unsigned char uint8;
typedef unsigned int uint32;
typedef unsigned long long uint64;

#define LICENSE_CODE_LENGTH 28

static const uint8 RC5Key1[16] = { 0x3F, 0x57, 0x8E, 0x1C, 0x44, 0x18, 0x34, 0xDD, 0xA5, 0x46, 0x21, 0x36, 0x32, 0x81, 0xFB, 0xCF };
static const uint8 RC5Key2[16] = { 0x14, 0xDC, 0x15, 0xAF, 0xA1, 0x48, 0x3D, 0x7D, 0x6A, 0xC1, 0xDC, 0xA1, 0x79, 0x8D, 0xAA, 0x3E };

uint32 DecodeChar(char value)
{
char *charMap = "LRE8YFGHJK9SNBQ36MPVWXAZ2U45TC7D";
char *charPos = strchr(charMap, value);
return charPos == NULL ? 0 : charPos - charMap;
}

uint64 DecodeSignature(uint64 value)
{
uint32 shiftCount = value & 0x0f;
do value >>= 4; while(shiftCount-- > 0);
return value;
}

uint32 DecodeLicenseCode(char *licenseCode, uint64& sig1, uint64& sig2)
{
if(strlen(licenseCode) != LICENSE_CODE_LENGTH)
return 0;

uint8 licenseBits[35];

for(int i = 0, j = 0; i < LICENSE_CODE_LENGTH; i += 4, j += 5)
{
uint32 bitBuffer =
(DecodeChar(licenseCode[i]) << 15) +
(DecodeChar(licenseCode[i+1]) << 10) +
(DecodeChar(licenseCode[i+2]) << 5) +
DecodeChar(licenseCode[i+3]);

licenseBits[j] = bitBuffer >> 16;
licenseBits[j+1] = (bitBuffer >> 12) & 0xf;
licenseBits[j+2] = (bitBuffer >> 8) & 0xf;
licenseBits[j+3] = (bitBuffer >> 4) & 0xf;
licenseBits[j+4] = bitBuffer & 0xf;
}

uint64 RC5Block1 = 0;
uint64 RC5Block2 = 0;

for(int i = 0; i < 16; i++)
{
RC5Block1 |= uint64(licenseBits[i]) << i*4;
RC5Block2 |= uint64(licenseBits[i + 16]) << i*4;
}

RC5_32_KEY RC5Key;

RC5_32_set_key(&RC5Key, 16, RC5Key1, 16);
RC5_32_ecb_encrypt((uint8*)&RC5Block1, (uint8*)&RC5Block1, &RC5Key, 1);

RC5_32_set_key(&RC5Key, 16, RC5Key2, 16);
RC5_32_ecb_encrypt((uint8*)&RC5Block2, (uint8*)&RC5Block2, &RC5Key, 0);

// ECDSA signature
sig1 = DecodeSignature((RC5Block2 >> 8) | (uint64(licenseBits[33]) << 56));
sig2 = DecodeSignature(((RC5Block1 & 0xffffffffffff) << 8) | (RC5Block2 & 0xff) | (uint64(licenseBits[32]) << 56));

// option bits
return uint32(RC5Block1 >> 48) | (uint32(licenseBits[34]) << 16);
}
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on January 04, 2014, 02:36:11 pm
nice :o
and now? :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on January 04, 2014, 02:40:28 pm
nice :o
and now? :)

it's time to reverse
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pascal_sweden on January 04, 2014, 03:08:14 pm
Did you get access to the source code of the license generator?
How did you do that?

Then it should be straightforward to get the keys no?
I need to know about DS2072A within 2 weeks. Then I will order one :)
Pity there is no 4 channel version.

BTW: How does Siglent SDS2000 compare with Rigol DS2000 series?
Siglent has 4 channels, but more expensive?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 04, 2014, 03:29:38 pm
BTW: How does Siglent SDS2000 compare with Rigol DS2000 series?
Siglent has 4 channels, but more expensive?

The fact that the Siglent has not been released yet - and no one knows much about it, or when it will be on sale - has been written about extensively in another thread which you started - plus it's off-topic here. :P
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on January 04, 2014, 03:53:34 pm
So here it is, the new license code decoder:

How do you manage to do this?, decompiling the sources?
Is there a way to take apart the gel files, or are you decompiling from the jtag dumps?
Is this the blackfin thingy that executes this code?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 04, 2014, 04:13:28 pm
Siglent sells the SDS2000 series in Europe through their webshop:
http://www.siglent.eu/oscilloscopes/sds-2000-series.html (http://www.siglent.eu/oscilloscopes/sds-2000-series.html)

So is it available then? :)

Or do I miss something here...
Siglent, like GW-Instek before them (and every other Chinese manufacturer), is late to produce a < $1000 DPO - since Rigol beat everyone to the punch and took over the market share. So they, like Instek before them, are rushing to do anything they can to try to reduce Rigol's share. In GW-Instek's case, it was hurrying out a product which just wasn't competitive enough - in Siglent's case, they are dashing out publicity statements, "for sale" internet ads, and demo models of a product which (although perhaps as nice/nicer than the DS2000) is not ready for market yet. You can read all about it in other threads here.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: andyturk on January 04, 2014, 04:34:39 pm
Code: [Select]
// Copyright (c) 2013 RIGLOL Technologies, Inc. All Rights Reversed.

 :-DD
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on January 04, 2014, 04:36:56 pm
How do you manage to do this?, decompiling the sources?
Is there a way to take apart the gel files, or are you decompiling from the jtag dumps?

I decompiled memory dump provided by tirulerbach (the one after entering 'AAAAAAABBBB...' license code) and after I understood how original decoder worked, I wrote my own version of it.

Quote
Is this the blackfin thingy that executes this code?

Yes, Rigol uses blackfin in DS2K scopes.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on January 04, 2014, 05:26:32 pm
what about the gel files?, what format is that?, not this I guess: http://processors.wiki.ti.com/index.php/GEL (http://processors.wiki.ti.com/index.php/GEL)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: blandin_01 on January 04, 2014, 05:31:19 pm
I'm sorry to have to pass here uint32 DecodeLicenseCode (char * licenseCode, uint64 & sig1, uint64 & sig2)
licenseCode - ?  sig1- ?  sig2 - ? please describe
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on January 04, 2014, 07:56:27 pm
Code: [Select]
// Copyright (c) 2013 RIGLOL Technologies, Inc. All Rights Reversed.

 :-DD

Well, this is my small tribute to cybernet, because without his findings I would have never been able to do this.  ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tirulerbach on January 04, 2014, 08:55:46 pm
So here it is, the new license code decoder:

Great work! Fantastic! :-+

So, a small question: Are you sure DecodeSignature() is correct? Maybe it's a roll instead a shift?  :-//
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: van-c on January 04, 2014, 09:33:13 pm
nice :o
and now? :)

it's time to reverse

So, zombie28, if the correct private key were used in the existing keygen to produce a 28-character license code for a particular option code, then running that license code through your DecodeLicenseCode() function would return the option code back, verifying that the correct private key had been found, correct?  (Assuming the keygen is using an algorithm compatible with the decoder.)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on January 04, 2014, 09:55:35 pm
So here it is, the new license code decoder:
So, a small question: Are you sure DecodeSignature() is correct? Maybe it's a roll instead a shift?  :-//

I'm pretty sure that my code is correct. I have run it with 'AAAAAAABBBBBBBCCCCCCCDDDDDDD' license code and found its output in memory dump:

option bits: 0x000f09f5 (at offset 0x1c3df7c as binary value)
sig1:   0x0000f464e5aebf3e (at offset 0x1c3df80 as hex string)
sig2:   0x000000000000000f (at offset 0x1c3df90 as hex string)

The same technique was used in non-A license decoder (take a look at riglol.c and variables i1 and i2), but instead of shifting binary values to the right, this decoder moves null terminator of hex strings to the left. I think Rigol uses shifting of signature values as a form of padding, to fill all available space in case of leading zeros (padding is often used in digital signature algorithms for security reasons).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on January 05, 2014, 02:13:13 am
So, zombie28, if the correct private key were used in the existing keygen to produce a 28-character license code for a particular option code, then running that license code through your DecodeLicenseCode() function would return the option code back, verifying that the correct private key had been found, correct?  (Assuming the keygen is using an algorithm compatible with the decoder.)

Well, not exactly. After decoding of the license code, the ECDSA algorithm must be used to verify the signature (or the key). But first we need to find out how the signature is being constructed from the scope's serial number and option bits, because there are no explicit option characters in the new code format.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: van-c on January 05, 2014, 05:35:31 am
I had mistakenly thought the option code and serial number were being decrypted from the license code using the public key. Now I see that the algorithm verifies that the signature pairs embedded in the license code are valid before accepting the decoded license.  Was confusing public-private encryption with signature validation.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on January 05, 2014, 12:15:32 pm
DP832 Power Supply with Firmware 08:

Please, has anyone been able to successfully activate the DP832 Options by downgrading to Firmware 06, installing the keys from the Riglol 1.03c Keygen, and then upgrading back to FW 08?

I have seen others ask questions about this, but I haven't seen any replies.

Or, is there a version of a Keygen that will work with a DP832 with Firmware 08?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Sebastian on January 05, 2014, 02:10:24 pm
DP832 Power Supply with Firmware 08:

Please, has anyone been able to successfully activate the DP832 Options by downgrading to Firmware 06, installing the keys from the Riglol 1.0c Keygen, and then upgrading back to FW 08?

I have seen others ask questions about this, but I haven't seen any replies.

Or, is there a version of a Keygen that will work with a DP832 with Firmware 08?

Hi,

I've got the same problem. 06 works no problem at all, when I upgrade to 08 all options are gone. When I downgrade back to 06 everything is official again.
BTW I am using Riglol 1.03c.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 05, 2014, 02:19:49 pm
I've got the same problem. 06 works no problem at all, when I upgrade to 08 all options are gone. When I downgrade back to 06 everything is official again.
BTW I am using Riglol 1.03c.

This seems very odd. Does this mean that people who actually bought options legally from Rigol for the DP832 can't use the newest firmware?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on January 05, 2014, 06:50:54 pm
I've got the same problem. 06 works no problem at all, when I upgrade to 08 all options are gone. When I downgrade back to 06 everything is official again.
BTW I am using Riglol 1.03c.

   Sebastian
[/quote]

I have 1.03c Keygen also, sorry but I left off the 3 from the Keygen number above.  Thank you for your reply.  Now I wonder what alternatives we can find without an updated Keygen for FW 08.

        ted572
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Sparky on January 05, 2014, 07:08:58 pm
I've got the same problem. 06 works no problem at all, when I upgrade to 08 all options are gone. When I downgrade back to 06 everything is official again.
BTW I am using Riglol 1.03c.

I also have the DP832.  My unit is an early one with the small heatsink and it came with firmware 00.01.03.  All options installed fine using Riglol 1.03c keygen.  I have seen photos in other threads showing firmware 06 and 08.  Could someone kindly upload the 06 and 08 firmwares?  I haven't seen downloads for them...and haven't contact Rigol myself yet.

It seems 06 is fine to use, but 08 somehow invalidates options already installed...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jkw13 on January 05, 2014, 07:30:10 pm
On my DP832, not only have the options gone on upgrade, the ADC calibration doesn't work
either (on v1.06 and v1.08) DAC is fine. Did they put a "booby trap" in there?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Wall-E on January 05, 2014, 08:44:30 pm
Same thing here with DP832 and Riglol 1.03c Keygen.  It worked fine on my new DP832 with FW 00.06, but then all the options were gone when I went back to FW 00.08.

I thought that it was just me, but now I don't know of any DP832 owners that were able to get the options to work with FW 00.08.

Can anyone help with this?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Sebastian on January 05, 2014, 09:07:47 pm
I've got the same problem. 06 works no problem at all, when I upgrade to 08 all options are gone. When I downgrade back to 06 everything is official again.
BTW I am using Riglol 1.03c.

I also have the DP832.  My unit is an early one with the small heatsink and it came with firmware 00.01.03.  All options installed fine using Riglol 1.03c keygen.  I have seen photos in other threads showing firmware 06 and 08.  Could someone kindly upload the 06 and 08 firmwares?  I haven't seen downloads for them...and haven't contact Rigol myself yet.

It seems 06 is fine to use, but 08 somehow invalidates options already installed...

If you go to the Riglol site and click on DP832 you get both of the versions, as well as the instructions on how to install them.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 05, 2014, 09:26:00 pm
Same thing here with DP832 and Riglol 1.03c Keygen.  It worked fine on my new DP832 with FW 00.06, but then all the options were gone when I went back to FW 00.08.

I thought that it was just me, but now I don't know of any DP832 owners that were able to get the options to work with FW 00.08.

Can anyone help with this?

IMO, it would be worthwhile for one of you owners to start a separate thread asking if anyone with a purchased option for the DP832 has managed to successfully upgrade to v.08. It's always possible that there's a bug in the FW which affects ALL options (legal or otherwise) - and if so, Rigol can be notified for a fix.

As we know from his video review, Dave has a purchased license key, so perhaps you might find out from him if he's installed v.08 without troubles.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Sparky on January 05, 2014, 09:43:08 pm
I've got the same problem. 06 works no problem at all, when I upgrade to 08 all options are gone. When I downgrade back to 06 everything is official again.
BTW I am using Riglol 1.03c.

I also have the DP832.  My unit is an early one with the small heatsink and it came with firmware 00.01.03.  All options installed fine using Riglol 1.03c keygen.  I have seen photos in other threads showing firmware 06 and 08.  Could someone kindly upload the 06 and 08 firmwares?  I haven't seen downloads for them...and haven't contact Rigol myself yet.

It seems 06 is fine to use, but 08 somehow invalidates options already installed...

If you go to the Riglol site and click on DP832 you get both of the versions, as well as the instructions on how to install them.

I've had a look on www.rigol.com (http://www.rigol.com), www.eu.rigolna.com (http://www.eu.rigolna.com), www.rigolna.com (http://www.rigolna.com) and looked at the DP832 pages, but I can't find anywhere where the firmware is available for direct download.  Are you saying the firmware is somewhere for download, or referring to the "Request the Latest Firmware" page?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 05, 2014, 09:46:51 pm
I also have the DP832... Could someone kindly upload the 06 and 08 firmwares?
If you go to the Riglol site and click on DP832 you get both of the versions, as well as the instructions on how to install them.
I've had a look on www.rigol.com (http://www.rigol.com), www.eu.rigolna.com (http://www.eu.rigolna.com), www.rigolna.com (http://www.rigolna.com) and looked at the DP832 pages, but I can't find anywhere where the firmware is available for direct download.  Are you saying the firmware is somewhere for download, or referring to the "Request the Latest Firmware" page?
You missed the extra 'L' Sebastian wrote in RigLol.

It's this site he was referring to: http://riglol.3owl.com (http://riglol.3owl.com)

Direct link: http://riglol.3owl.com/firmware/DP832.zip (http://riglol.3owl.com/firmware/DP832.zip)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Sparky on January 05, 2014, 09:53:58 pm
If you go to the Riglol site and click on DP832 you get both of the versions, as well as the instructions on how to install them.
I've had a look on www.rigol.com (http://www.rigol.com), www.eu.rigolna.com (http://www.eu.rigolna.com), www.rigolna.com (http://www.rigolna.com) and looked at the DP832 pages, but I can't find anywhere where the firmware is available for direct download.  Are you saying the firmware is somewhere for download, or referring to the "Request the Latest Firmware" page?
You missed the extra 'L' Sebastian wrote in RigLol.

It's this site he was referring to: http://riglol.3owl.com (http://riglol.3owl.com)

Direct link: http://riglol.3owl.com/firmware/DP832.zip (http://riglol.3owl.com/firmware/DP832.zip)

Oh!  Thanks for that!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Sparky on January 05, 2014, 10:24:37 pm
Same thing here with DP832 and Riglol 1.03c Keygen.  It worked fine on my new DP832 with FW 00.06, but then all the options were gone when I went back to FW 00.08.

I thought that it was just me, but now I don't know of any DP832 owners that were able to get the options to work with FW 00.08.

Can anyone help with this?

IMO, it would be worthwhile for one of you owners to start a separate thread asking if anyone with a purchased option for the DP832 has managed to successfully upgrade to v.08. It's always possible that there's a bug in the FW which affects ALL options (legal or otherwise) - and if so, Rigol can be notified for a fix.

As we know from his video review, Dave has a purchased license key, so perhaps you might find out from him if he's installed v.08 without troubles.

Good suggestion marmad; I have done so here (https://www.eevblog.com/forum/testgear/rigol-dp832-firmware-updates-and-bug-list/).  I will try to add more details on which bugs and firmware differences.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: m-joy on January 06, 2014, 10:27:48 am
Hello, 

 I have Hardware Version 1.0.2.0.0.  Can i use 300MHz?

Greetings
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Pehtoori on January 06, 2014, 11:11:53 am
Hello, 

 I have Hardware Version 1.0.2.0.0.  Can i use 300MHz?

Greetings

Yes, but accuracy isn't great. Better limit it to 200MHz
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tirulerbach on January 06, 2014, 06:24:31 pm
So here it is, the new license code decoder:

Thanks again. I' currently working on a keygen for that beast and run into a small issue, regarding the options bits:  :box:

Code: [Select]
uint32 DecodeLicenseCode(char *licenseCode, uint64& sig1, uint64& sig2)
{
[...]

// option bits
return uint32(RC5Block1 >> 48) | (uint32(licenseBits[34]) << 16);
}

How this binary 32 bit return value gets hashed by the ECC-signature verification?

In reality, because of coding techniques used, only the lower 20 bits are valid of this return value. The higher 12 bits are always zero. In the original non-A code these options were an ASCII string which was hashed character wise. But in the A-models it is a 20 bit binary value.

If I don't miss something more, this detail is the remaining issue which holds me back to complete the keygen...  :-DD

As mentioned earlier by zombie28 it would be very helpful if somebody posts an original key for an DS2000-A option. There exists an ambiguity due the license generating. There are about roughly a few dozen possible encoding schemes for a serial and options tuple.  :-/O
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 06, 2014, 06:51:17 pm
As mentioned earlier by zombie28 it would be very helpful if somebody posts an original key for an DS2000-A option.

;D

I seriously doubt anyone (at least reading this blog) HAS an original key for the DS2000A. The trial reset bug  (which allowed many original DS2000 owners to get new Trial keys) no longer exists - and no one is buying options anymore.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Wall-E on January 06, 2014, 09:33:37 pm
DM3058E Benchtop Multimeter:

I understand that the DM3058E hardware is very similar to, or the same as the DM3068.  And it does look like there is room on the DM3058E's LCD for an additional digit as is on the DM3068.

Is it true that the hardware may be the same, and if so, is there anyway (software/firmware/mod) that the DM3058E could incorporate at least some of the advanced features of the DM3068?

      Wallie
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on January 06, 2014, 09:51:41 pm
I seriously doubt anyone (at least reading this blog) HAS an original key for the DS2000A. The trial reset bug  (which allowed many original DS2000 owners to get new Trial keys) no longer exists - and no one is buying options anymore.

If this is true, then...

Quote from: tirulerbach
There exists an ambiguity due the license generating. There are about roughly a few dozen possible encoding schemes for a serial and options tuple.

Assuming the combinations were not too elaborate (i.e. painful to code), it would still be possible to build a license-gen with those S1-S24 schemes, that generated the full set, then try each until you got a hit.  That would then identify it was S17, for example.  In the absence of any original A-keys, brute force may be the only practical option.  If you had a sense of which combinations may be most likely, you could start with those, and do the rest only if they all failed.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Git on January 06, 2014, 10:23:05 pm
Does anybody have IDA sigs for the compiler and maybe crypto libraries used for the DS firmware please?

Git
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on January 06, 2014, 11:22:37 pm
I've got some good and bad news. The good news is that I finished implementation of signature verification algorithm and tested its correctness on some 'A'-type license codes. However the bad news is that encryption keys needed by this algorithm are not consistent among different memory dumps of different scopes. It looks like Rigol uses different key sets in 'A' product line, but I don't have enough memory dumps to tell whether it is per scope model, production week or maybe even per single unit. Even ECC public keys are different, so it requires breaking them every time the new key is issued. Fortunately Rigol didn't change elliptic curve parameters, so finding private key is a matter of milliseconds on a decent computer.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on January 06, 2014, 11:25:23 pm
How this binary 32 bit return value gets hashed by the ECC-signature verification?

I will publish complete algorithm soon.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on January 06, 2014, 11:50:49 pm
So here it is:

Code: [Select]
//
// Copyright (c) 2014 RIGLOL Technologies, Inc. All Rights Reversed.
// This product includes software developed by the OpenSSL Project
// for use in the OpenSSL Toolkit. (http://www.openssl.org/)
//
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <memory.h>
#include "rc5.h"

extern "C"
{
#include "miracl.h"
}

// ECC parameters
char A[] = "2982";
char B[] = "3408";
char P[] = "AEBF94CEE3E707";
char N[] = "AEBF94D5C6AA71";
char Gx[] = "7A3E808599A525";
char Gy[] = "28BE7FAFD2A052";

typedef unsigned char uint8;
typedef unsigned int uint32;
typedef unsigned long long uint64;

#define LICENSE_CODE_LENGTH 28

// sample key sets for different scopes
#if 1
// DS2D1542....
static const uint8 RC5Key1[16] = { 0x3F, 0x57, 0x8E, 0x1C, 0x44, 0x18, 0x34, 0xDD, 0xA5, 0x46, 0x21, 0x36, 0x32, 0x81, 0xFB, 0xCF };
static const uint8 RC5Key2[16] = { 0x14, 0xDC, 0x15, 0xAF, 0xA1, 0x48, 0x3D, 0x7D, 0x6A, 0xC1, 0xDC, 0xA1, 0x79, 0x8D, 0xAA, 0x3E };
static const uint8 XXTEAKey[16] = { 0x39, 0x69, 0xA2, 0x04, 0x55, 0x9C, 0x35, 0x52, 0x90, 0x44, 0xED, 0x85, 0x52, 0x16, 0x13, 0x32 };
char ECCPublicKey[] = "A51BF373712F7D";
#else
// DS2D1543....
static const uint8 RC5Key1[16] = { 0x41, 0x55, 0xBF, 0xD8, 0x2D, 0x42, 0x9E, 0xA6, 0x9B, 0x3E, 0xE7, 0xD7, 0xD5, 0x9C, 0x89, 0x06 };
static const uint8 RC5Key2[16] = { 0xB9, 0xBC, 0x53, 0xD8, 0xB8, 0xCE, 0x6C, 0xE3, 0x59, 0x45, 0x55, 0xAA, 0x89, 0x55, 0x65, 0x43 };
static const uint8 XXTEAKey[16] = { 0x86, 0xF4, 0xA0, 0x93, 0x0B, 0xC7, 0xED, 0x27, 0x6B, 0x2D, 0x6C, 0x2C, 0xE2, 0x93, 0x53, 0x5F };
char ECCPublicKey[] = "A0581020E5C012";
#endif

uint32 DecodeChar(char value)
{
char *charMap = "LRE8YFGHJK9SNBQ36MPVWXAZ2U45TC7D";
char *charPos = strchr(charMap, value);
return charPos == NULL ? 0 : charPos - charMap;
}

uint64 DecodeSignature(uint64 value)
{
uint32 shiftCount = value & 0x0f;
do value >>= 4; while(shiftCount-- > 0);
return value;
}

uint32 DecodeLicenseCode(char *licenseCode, uint64& sig1, uint64& sig2)
{
if(strlen(licenseCode) != LICENSE_CODE_LENGTH)
return 0;

uint8 licenseBits[35];

for(int i = 0, j = 0; i < LICENSE_CODE_LENGTH; i += 4, j += 5)
{
uint32 bitBuffer =
(DecodeChar(licenseCode[i]) << 15) +
(DecodeChar(licenseCode[i+1]) << 10) +
(DecodeChar(licenseCode[i+2]) << 5) +
DecodeChar(licenseCode[i+3]);

licenseBits[j] = bitBuffer >> 16;
licenseBits[j+1] = (bitBuffer >> 12) & 0xf;
licenseBits[j+2] = (bitBuffer >> 8) & 0xf;
licenseBits[j+3] = (bitBuffer >> 4) & 0xf;
licenseBits[j+4] = bitBuffer & 0xf;
}

uint64 RC5Block1 = 0;
uint64 RC5Block2 = 0;

for(int i = 0; i < 16; i++)
{
RC5Block1 |= uint64(licenseBits[i]) << i*4;
RC5Block2 |= uint64(licenseBits[i + 16]) << i*4;
}

RC5_32_KEY RC5Key;

RC5_32_set_key(&RC5Key, 16, RC5Key1, 16);
RC5_32_ecb_encrypt((uint8*)&RC5Block1, (uint8*)&RC5Block1, &RC5Key, 1);

RC5_32_set_key(&RC5Key, 16, RC5Key2, 16);
RC5_32_ecb_encrypt((uint8*)&RC5Block2, (uint8*)&RC5Block2, &RC5Key, 0);

// ECDSA signature
sig1 = DecodeSignature((RC5Block2 >> 8) | (uint64(licenseBits[33]) << 56));
sig2 = DecodeSignature(((RC5Block1 & 0xffffffffffff) << 8) | (RC5Block2 & 0xff) | (uint64(licenseBits[32]) << 56));

// option bits
return uint32(RC5Block1 >> 48) | (uint32(licenseBits[34]) << 16);
}

char* EncodeOptionBits(uint32 optionBits)
{
char *charMap = "XBCNEF8HJ3LMKPZRSAUVWTYQ5D4276G9";
char *optionString = new char[5];

for(int i = 0; i < 4; i++)
optionString[i] = charMap[(optionBits >> ((3-i)*5)) & 0x1f];

optionString[4] = '\0';
return optionString;
}

char* EncodeSerialNumber(char *serialNumber)
{
if(strlen(serialNumber) < 4)
return 0;

uint32 header = *((uint32*)serialNumber);

for(int i = 0; i < 16; i++)
header =
(header << 1) |
(header >> 31) ^
(header >> 30) & 1 ^
(header >> 28) & 1 ^
(header >> 22) & 1 ^
(header >> 13) & 1 ^
(header >> 6) & 1;

char* result = strdup(serialNumber);
*((uint32*)result) = header;
return result;
}

#define DELTA 0x9e3779b9
#define MX (((z>>5^y<<2) + (y>>3^z<<4)) ^ ((sum^y) + (key[(p&3)^e] ^ z)))
 
void XXTEA(uint32 *v, int n, uint32 const key[4])
{
uint32 y, z, sum;
unsigned p, rounds, e;

if (n > 1)
{
rounds = 6 + 52/n;
sum = 0;
z = v[n-1];
do {
sum += DELTA;
e = (sum >> 2) & 3;
for (p=0; p<n-1; p++)
{
y = v[p+1];
z = v[p] += MX;
}
y = v[0];
z = v[n-1] += MX;
} while (--rounds);
}
else if (n < -1)
{
n = -n;
rounds = 6 + 52/n;
sum = rounds*DELTA;
y = v[0];
do {
e = (sum >> 2) & 3;
for (p=n-1; p>0; p--)
{
z = v[p-1];
y = v[p] -= MX;
}
z = v[n-1];
y = v[0] -= MX;
} while ((sum -= DELTA) != 0);
}
}

uint64 ByteSwap64(uint64 value)
{
uint64 result = 0;
for(int i = 0; i < 8; i++)
{
result = (result << 8) | (value & 0xff);
value >>= 8;
}
return result;
}

bool VerifySignature(uint64 sig1, uint64 sig2, uint8 signatureDataHash[20])
{
mirsys(0x320, 16)->IOBASE = 16;

big p = mirvar(0);
big n = mirvar(0);
big a = mirvar(0);
big b = mirvar(0);
big x = mirvar(0);
big y = mirvar(0);
big lic1 = mirvar(0);
big lic2 = mirvar(0);
big hash = mirvar(0);
big m1 = mirvar(0);
big m2 = mirvar(0);
big v = mirvar(0);
big g = mirvar(0);

epoint *pt1 = epoint_init();
epoint *pt2 = epoint_init();

instr(a, A);
instr(b, B);
instr(p, P);
instr(n, N);
 
ecurve_init(a, b, p, MR_PROJECTIVE);

instr(x, Gx);
instr(y, Gy);
if (!epoint_set(x, y, 0, pt1))
{
printf("ERR: Point G is invalid\n");
exit(-1);
}

instr(x, ECCPublicKey);
if (!epoint_set(x, x, 1, pt2))
{
printf("ERR: Public key is invalid\n");
exit(-1);
}
 
bytes_to_big(20, (char*)signatureDataHash, hash);

sig1 = ByteSwap64(sig1);
bytes_to_big(8, (char*)&sig1, lic1);

sig2 = ByteSwap64(sig2);
bytes_to_big(8, (char*)&sig2, lic2);

xgcd(lic2, n, lic2, lic2, lic2);
copy(lic2, g);
mad(hash, g, g, n, n, m1);
mad(lic1, g, g, n, n, m2);
ecurve_mult2(m1, pt1, m2, pt2, pt1);
epoint_get(pt1, v, v);
divide(v, n, n);

return mr_compare(v, lic1) == 0;
}

bool VerifyLicenseCode(char *serialNumber, char *licenseCode)
{
uint64 sig1, sig2;
uint32 optionBits = DecodeLicenseCode(licenseCode, sig1, sig2);

char *optionString = EncodeOptionBits(optionBits);
char *encodedSerialNumber = EncodeSerialNumber(serialNumber);

uint32 optionStringLength = strlen(optionString);
uint32 encodedSerialNumberLength = strlen(encodedSerialNumber);

uint32 signatureDataLength = (encodedSerialNumberLength + optionStringLength + 3) & ~3;
uint8 *signatureData = new uint8[signatureDataLength];

memset(signatureData, 0, signatureDataLength);
memcpy(signatureData, encodedSerialNumber, encodedSerialNumberLength);
memcpy(signatureData + encodedSerialNumberLength, optionString, optionStringLength);

XXTEA((uint32*)signatureData, signatureDataLength >> 2, (uint32*)XXTEAKey);

uint8 hash[20];
sha sh;
shs_init(&sh);
for(int i = 0; i < signatureDataLength; i++)
shs_process(&sh, signatureData[i]);
shs_hash(&sh, (char*)hash);

return VerifySignature(sig1, sig2, hash);
}
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tirulerbach on January 07, 2014, 12:40:38 am
So here it is:

Thank you again, zombie28. Very valuable work.  :-+

So now I have to rework my keygen. I was just to about to release a first shot. It will take some more time. Is anybody else writing a keygen, too?

However the bad news is that encryption keys needed by this algorithm are not consistent among different memory dumps of different scopes. It looks like Rigol uses different key sets in 'A' product line, but I don't have enough memory dumps to tell whether it is per scope model, production week or maybe even per single unit. Even ECC public keys are different, so it requires breaking them every time the new key is issued.

Where are the public keys stored? Flash? Then maybe it's a model dependency.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndreaEl on January 07, 2014, 01:17:17 pm
Are some days that i not follow this topic and i have some question that i have not understand...

I have a Rigol DS2072 (HW 2)
I have a not update firmware and i must update, is right that the last version is: 00.02.01.00.03? (I have read about clear FRAM after update).

With this version is available the 300MHz BW Option, but i have read that 200MHz BW option give more performance in LF than 300MHz in HW 1. Is the same for HW 2 or i can Install 300MHz BW with no problem in my HW 2?

I have read about newest code for enable 300MHz and CAN, but not understand what enable each code. I have read about DSHH, DSGH etc.
I search for: 200MHz + All Option (include CAN), 300MHz + All Option.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on January 07, 2014, 05:02:34 pm
Hm... An DS2202A-S have serial that starts with DS2E...

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: battlefield on January 07, 2014, 05:46:19 pm
I just joined the forums and had a brief read over the last few pages of the topic.
I also just got my rigol DS2072A with serial DS2D1546... I'd love to help you with key breaking but do far as I understand you need memory dumps and for that I have two questions about that, first one is do I need JTAG or something else, second how exactly do I acces these memory dumps.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on January 07, 2014, 06:23:09 pm
you need jtag with a special pin setup/adapter and you have to open the DSO

but cybernet posted something a few days ago, it seemed to me it might be possible to dump via a LAN connection ...
but I dunno XD
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on January 07, 2014, 07:02:10 pm
cybernet choose another path from the beginning, but why? ;D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on January 07, 2014, 10:34:04 pm
No others with the -S version yet?, to see if the E in the serial is due to the signalgen or not?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tirulerbach on January 08, 2014, 12:55:26 pm
I'm making progress with the keygen für the DS2k-A.  :box:

But I need assistance:  :-//
Any help is appreciated. Thank you in advance!   ;D

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tirulerbach on January 08, 2014, 02:29:57 pm
8)  O0  :-DD

My DS2202A:

(https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/?action=dlattach;attach=75419;image)


Crowd: Please be patient! There are still some issues with the keygen. It is not ready for the masses. :-[

In the meantime, please provide memory dumps. Search and read this thread: all information how to do this is in here. No pain, no gain!  >:D

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on January 08, 2014, 02:58:17 pm
My DS2202A:

Interresting!, did you see the thing about that my DS2202A-S have DS2E, not DS2D?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on January 08, 2014, 03:29:24 pm
But I need assistance:  :-//
  • I need some pointer, links, code etc., how to break für the ecc private key given the public key.
  • I need some info how to extract the public key from a memory dump.

PM sent
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on January 08, 2014, 03:35:37 pm
yes, the generator versions seem to have a count up in the serial ...

I'm looking forward to test the stuff you people come up with :D
can't await :D
(though I still have 4000 min left lol)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sled on January 08, 2014, 03:41:13 pm
8)  O0  :-DD

Crowd: Please be patient! There are still some issues with the keygen. It is not ready for the masses. :-[

In the meantime, please provide memory dumps. Search and read this thread: all information how to do this is in here. No pain, no gain!  >:D

congrats! really good work :) it seems like the bandwidth (100/200/300 mhz) is not an option anymore does that mean the bandwidth is dependent on the model number/serial number?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on January 08, 2014, 03:43:00 pm
it seems like the bandwidth (100/200/300 mhz) is not an option anymore

I don't think you can make this assumption, bandwidth upgrades are only displayed in the menu if they are activated.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on January 08, 2014, 03:49:34 pm
My DS2202A:

Interresting!, did you see the thing about that my DS2202A-S have DS2E, not DS2D?

This should not pose any problem - any letter after 'DS2' except 'A' and 'C' should work with the new keygen. It would be interesting to compare keys from your scope to tirulerbach's ones.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: blandin_01 on January 08, 2014, 04:33:22 pm
have a few questions:
1. should enable signals "TRST" and "SRST" in scheme of Cybernet?
2. You can use H-JTAG V2.1 instead http://www.urjtag.org/ (http://www.urjtag.org/)  ?
3. well use jtag-LPT(Parallel-port cables)?
4. dump from (DS2072A) DS2D1546..... need?
(http://pikucha.ru/icu52/thumbnail/DS2k_JTAG.jpeg) (http://pikucha.ru/icu52)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on January 08, 2014, 04:55:59 pm
In order to extract keys from memory dumps you need to search for the following sequence of bytes (in hex):

Code: [Select]
02 00 84 00 10 00 <16 bytes of XXTEAKey> 20 00 <2x16 bytes of RC5Key1 and RC5Key2> 08 00 <8 bytes of bit-shuffled ECC public key> 40 00 <64 bytes of some ASCII-HEX data>

You will need to unshuffle the public key with the algorithm I posted earlier in this thread.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Posterisan on January 08, 2014, 07:06:31 pm
Why are the public keys differ in the A models? As far as I have read it's the same firmware as the non-A models. Or are the public keys stored somewhere else?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tirulerbach on January 08, 2014, 07:15:51 pm
So, now I'm diving into Elliptic Curve Cryptography...  Pretty interesting stuff... :-DD

So I have a question: How do I calculate the Y coordinate of the public key X coordinate out of the ECC curve parameters, base point and order?

Second, the keygen is getting complex and a lot of work. Are there any people out here who can program C and would like to help?  ???

I need:

Code: [Select]
struct KeyData
{
  char RC5Key1[32 + 1]; // hex string
  char RC5Key2[32 + 1]; // hex string
  char XXTEAKey[32 + 1]; // hex string
  char serialNumber[TBD];
  char publicKey[TBD]; // hex string
  char secretKey[TBD];        // hex string
};

struct KeyData * LoadKeyData(char *filename);
int SaveKeyData(char *filename);

char * FormatHex(uint8_t *bytes, unsigned int len);
unsigned int ParseHex(uint8_t *buffer, unsigned int capacity, char *hexstring);

uint8_t * ScanMemoryDump(char *filename);


The Load() and Save() functions should use ASCII-Files. Lines should like something like "serial=DS....." or "RC5Key1: 123456789abcdef...." and so on. Please don't use Windows specific functions, only pure ANSI. The keygen works on linux and windows.

The function FormatHex() should malloc() the string. ParseHex() returns the number of bytes parsed, or zero, if buffer was to small.

ScanMemoryDump() opens a binary file and scans for the pattern zombie28 published.

Any assistance will be useful.  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tirulerbach on January 08, 2014, 07:25:17 pm
Why are the public keys differ in the A models? As far as I have read it's the same firmware as the non-A models. Or are the public keys stored somewhere else?

This is simply currently not known. Maybe they are in someway calculated. But analyzing the firmware is pretty complex, difficult and time consuming. Thanks to zombie28 again for his effort. If we had more memory dumps, a better analysis maybe is possible. But it's the old problem: People are only sitting around and waiting for the keygen and don't would like to break her warranty seal on the scope to provide a memory dump... This is bad indeed...  ::)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neamyalo on January 08, 2014, 07:40:24 pm
tirulerbach,

I can create definitions for those functions tomorrow. I'll be using C++, so let me know if that's a problem for you.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on January 08, 2014, 07:55:53 pm
How do I calculate the Y coordinate of the public key X coordinate out of the ECC curve parameters, base point and order?

Code: [Select]
mirsys(0x320, 16)->IOBASE = 16;

big a = mirvar(0);
big b = mirvar(0);
big p = mirvar(0);
big x = mirvar(0);
big y = mirvar(0);

instr(a, A);
instr(b, B);
instr(p, P);

ecurve_init(a, b, p, MR_PROJECTIVE);
instr(x, ECCPublicKey);

epoint *point = epoint_init();

if (!epoint_set(x, x, 1, point))
{
printf("ERR: Public key is invalid\n");
exit(-1);
}

epoint_get(point, x, y);
cotnum(y, stdout);
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: battlefield on January 08, 2014, 08:14:35 pm
I will get you another memory dump, I just need to wait for my JTAG programmer to arrive(will get it for few € from a friend :D) and read this forum a bit to get the inctructions for getting the memory dumps.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cidcorp on January 08, 2014, 11:35:25 pm

This is not totally related to the thread but the question relates to the options for licenses on the Rigol Scopes.

So (and I apologize in advance if this has already been covered in the thread), assuming that the software utilities that aren't free like
Ultra Power Analyzer (online version) have to have keys that are linked to the equipment that will use it - would the equipment options
that are undefined (like I thought there were some unlocks that no-one knew what they 'unlocked') be the keys for unlocking those pieces
of software, or (wow this is a long questions  :blah:) are they unlocked for ANY equipment when you do?

I don't know if anyone actually understands what I'm trying to ask, but a person with two DS2000 scopes and an unlocked version of
Ultra Power Analyzer be able to use the software with both scopes (or is it serial number locked)?

Just asking because the license keys are in exactly the same format, or at least appear to be.

Chris
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tirulerbach on January 09, 2014, 12:09:58 am
Code: [Select]
if (!epoint_set(x, x, 1, point))

Thanks again and again zombie28. You helped me a lot! Thank you!  :-+

So I learned about ECC point decompression and the result is: ;D

Code: [Select]
$ time ./ecc-smash A05810........
5BCEE4........

real    0m0.076s
user    0m0.072s
sys     0m0.004s



I can create definitions for those functions tomorrow. I'll be using C++, so let me know if that's a problem for you.

Normally I would like stick to C, but the heck: Any help is appreciated! You are welcome. I'm looking forward for your code.  :-+

Btw.: You provided a memory dump of your scope? You should check your PM...   ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dr.diesel on January 09, 2014, 01:40:14 am
Appears a firmware update is available for the DSA815, anyone tried it with hacks installed?

DSA815 FW-Version: 00.01.08
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sled on January 09, 2014, 06:48:56 am
I have implemented your interface in ANSI C, with a Makefile and some basic tests (copy the 0x00000000-0x01ffffff_dram.bin into the same folder to extract the keys).

The only thing that is missing is the descrambling of the public key, but I've added an empty method for it `void DescramblePublicKey(uint8_t bytes[8]);`

The only thing that I'm confused about is whether the public key is 7 or 8 bytes long because we read an 8 byte sequence from the dump file but in your examples the hex string has only 7 bytes.

Have fun and keep us updated  :-DD


Output when running the compiled test binary should look like:

Code: [Select]
--- FormatHex RC5Key1:
4155BFD82D429EA69B3EE7D7D59C8906
--- FormatHex RC5Key2:
B9BC53D8B8CE6CE3594555AA89556543
--- FormatHex XXTEAKey:
86F4A0930BC7ED276B2D6C2CE293535F
--- Compare reconstructed byte arrays from string to original:
RC5Key1: PASS
RC5Key2: PASS
XXTEAKey: PASS
---- PrintKeyData from memory:
RC5KEY1=4155BFD82D429EA69B3EE7D7D59C8906
RC5KEY2=B9BC53D8B8CE6CE3594555AA89556543
XXTEAKEY=86F4A0930BC7ED276B2D6C2CE293535F
PUBKEY=A0581020E5C012
SECKEY=ABCEDFGHIJKLMN
SERIAL=DS2E123456789012
---- SaveKeyData as key.dat ...
---- LoadKeyData from key.dat ...
---- PrintKeyData from file:
RC5KEY1=4155BFD82D429EA69B3EE7D7D59C8906
RC5KEY2=B9BC53D8B8CE6CE3594555AA89556543
XXTEAKEY=86F4A0930BC7ED276B2D6C2CE293535F
PUBKEY=A0581020E5C012
SECKEY=ABCEDFGHIJKLMN
SERIAL=DS2E123456789012
---- Compare KeyData from file with KeyData in memory:
RC5Key1: PASS
RC5Key2: PASS
XXTEAKey: PASS
publicKey: PASS
secretKey: PASS
serialNumber: PASS
---- Scanning Memory Dump
!!! DESCRAMBLE PUBLICK KEY: NOT IMPLEMENTED!
RC5KEY1=3F578E1C441834DDA54621363281FBCF
RC5KEY2=14DC15AFA1483D7D6AC1DCA1798DAA3E
XXTEAKEY=3969A204559C35529044ED8552161332
PUBKEY=
SECKEY=
SERIAL=

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tokugawa on January 09, 2014, 08:34:27 am
Hello guys, i've just bought new Rigol DS1074z and i tried to put key into it. While i was trying different keys i got a message
Installation avoid for 12 hours!
However at the end i've used the web : http://riglol.3owl.com/ (http://riglol.3owl.com/)
and it worked beautifully.

I bought it in Czech Republic (Central Europe) and my sw version is 00.02.01.SP1

Thanks for your great work, wish you all good luck :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on January 09, 2014, 09:38:19 am
The only thing that I'm confused about is whether the public key is 7 or 8 bytes long because we read an 8 byte sequence from the dump file but in your examples the hex string has only 7 bytes.

Rigol uses 56-bit ECC keys, but in scrambled (i.e. bit-shuffled) form they take up 64 bits.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neamyalo on January 09, 2014, 10:13:52 am
This is what tirulerbach has done to my scope with the info in my JTAG dump...   :-DMM

More DS****A memory dumps are needed...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on January 09, 2014, 10:19:41 am
This is awesome!, did the serial change or do you still have one that starts with DS2D?, I didnt find out yet why mine starts with DS2E..
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neamyalo on January 09, 2014, 11:39:18 am
No serial number change  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on January 09, 2014, 12:10:25 pm
I guess it is not possible to jtag dump the scope without taking it apart?, and thus voiding warranty?, since we have good warranty here in Norway, I'm a bit reluctant to destroy the warranty sticker yet
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 09, 2014, 12:52:48 pm
I guess it is not possible to jtag dump the scope without taking it apart?, and thus voiding warranty?, since we have good warranty here in Norway, I'm a bit reluctant to destroy the warranty sticker yet
There are numerous videos about removing warranty stickers without breaking them - such as this one from EEVBlog member mikeselectricstuff.

Dealing with a warranty seal (https://www.youtube.com/watch?v=KGcNS5g9ygg#ws)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on January 09, 2014, 01:03:45 pm
cool, need to check that.
Does it also exists info on how to use tools to do the dump?
I have
FT2232H USB 2.0 Hi-Speed breakout board
http://www.seeedstudio.com/depot/ft2232h-usb-20-hispeed-breakout-board-p-737.html (http://www.seeedstudio.com/depot/ft2232h-usb-20-hispeed-breakout-board-p-737.html)
and
Bus Pirate v3.6 universal serial interface
http://www.seeedstudio.com/depot/bus-pirate-v36-universal-serial-interface-p-609.html (http://www.seeedstudio.com/depot/bus-pirate-v36-universal-serial-interface-p-609.html)

And I guess the firmware 02.01.00.03 is also the same that I can use on my A-S model?, not only for the A models?
Because I guess there is no interrest for dump on the scope how is it right now?  (with 02.00.00.04)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 09, 2014, 02:40:46 pm
I guess it is not possible to jtag dump the scope without taking it apart?, and thus voiding warranty?, since we have good warranty here in Norway, I'm a bit reluctant to destroy the warranty sticker yet
I believe in at least most Western countries you don't void your warranty by opening your product and you don't void your warranty by destroying or removing any warranty sticker. The only thing you void your warranty on is the sticker itself.
But those broken warranty void stickers scare customers away from filing claims, even if the product is still under warranty regardless of any broken or removed stickers. It's a tried and true money saving technique.

In the EU you can even root your device and load a custom firmware without voiding the warranty, unless the new firmware itself is the cause of any hardware defect you have a warranty claim for. So if say a power supply capacitor leaks it's still under warranty even with custom firmware loaded unless the firmware is the cause to the for the leaked capacitor.
http://matija.suklje.name/rooting-and-flashing-your-device-does-not-void-the-warranty-in-eu (http://matija.suklje.name/rooting-and-flashing-your-device-does-not-void-the-warranty-in-eu)
Quote
Rooting and flashing your device does not void the warranty in EU

Just the fact that you modified or changed the software of your device, is not a sufficient reason to void your statutory warranty. As long as you have bought the device as a consumer in the European Union.

...So, we finally come to the question of rooting, flashing and changing the software. Unless the seller can prove that modifying the software, rooting your device or flashing it with some other OS or firmware was the cause for the defect, you are still covered for defects during those 2 years.
The same applies to breaking a warranty void sticker. Simply breaking a warranty sticker will never be the cause of some other hardware of software defect, so your product is still under warranty with a broken sticker except for the sticker itself.

Quote
Many manufacturers of consumer devices write into their warranties a paragraph that by changing the software or “rooting” your device, you void the warranty. You have to understand that in EU we have a “statutory warranty”, which is compulsory that the seller must offer by law (Directive 1999/44/CE, §7.1) and a “voluntary warranty” which the seller or manufacturer can, but does not need to, offer as an additional service to the consumer. Usually the “voluntary warranty” covers a longer period of time or additional accidents not covered by law 6. If though the seller, the manufacturer or anyone else offers a “voluntary warranty”, he is bound to it as well!

So, even if, by any chance your “voluntary warranty” got voided, by European law, you should still have the 2 year “compulsory warranty” as it is described in the Directive and which is the topic of this article.

In case the seller refuses your right to repair or replace the device, you can sue him in a civil litigation and can report the incident to the national authority. In many European countries such action does not even require hiring a lawyer and is most of the time ensured by consumers associations.

The warranty under this Directive is only applicable inside the European Union and only if you bought the device as a consumer.
I know Norway is not part of the EU, but they have very similar laws and cooperate in many areas including consumer rights, so you probably have very similar warranty laws. But try to ask your national Consumer Center: http://www.forbrukerradet.no (http://www.forbrukerradet.no)

http://forbrukereuropa.no/en/ (http://forbrukereuropa.no/en/)
Quote
Forbruker Europa offers free help and advice for consumers on purchasing in EU, Island and Norway.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 09, 2014, 03:07:58 pm
I believe in at least most Western countries you don't void your warranty by opening your product and you don't void your warranty by destroying or removing any warranty sticker.

Nonetheless, it might save you time to remove the sticker without breaking it (which is easy to do), then in possible arguments/discussions with companies and service personnel - which is, after all, the point of Mike's video.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sled on January 09, 2014, 03:16:02 pm
I can't really imagine that RIGOL would supply each device with its own unique private and public key... Simply because it's a nightmare to keep track of all keypairs and if the dataset is lost, no options could be sold anymore...

Maybe there is a universal key that gets shuffled by either the model number or serial number?

Would it be possible to watch the memory address where the keys are and back trace the method that puts them there? Or scanning the dumps for references to this memory address?



Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 09, 2014, 03:19:52 pm
I believe in at least most Western countries you don't void your warranty by opening your product and you don't void your warranty by destroying or removing any warranty sticker.
Nonetheless, it might save you time to remove the sticker without breaking it (which is easy to do), then in possible arguments/discussions with companies and service personnel - which is, after all, the point of Mike's video.
Yes I fully agree with that. If you can open your device without damaging the sticker then by all means do it as it doesn't require much effort. Even if the warranty isn't broken with a broken sticker, the seller might argue otherwise until they are told otherwise by a consumer organisation or court. It could potentially save you a lost of hassle and arguing even if you have the law on your side.

But remember you shouldn't just give up possible future warranty claims just because of a broken or missing "warranty void" sticker - or a custom firmware for that matter.


I have also read (on this forum IIRC) one who completely removed his warranty sticker and all goo traces of it on his Rigol and later sent it to repair under warranty. They repaired it under warranty without complaining of any sticker missing.

I also read about another one who sent a DP832 to have the the PCB replaced with the new improved version with a larger heatsink. When he received it back from repair the warranty void sticker was missing or broken. So what's he supposed to do if he has another warranty claim and the warranty is broken by a missing sticker when he got it back from repair? I'm pretty sure I read it somewhere on this forum and I think it was TEquipment he sent it to.

I've also read of one where the sticker was missing on a device from new. And how can the seller even prove there has ever been a sticker on a device even if there has been? They could also have forgot to put it on during production.
So if you have a broken sticker it's better to just remove it completely and all it's goo traces before sending it to repair. The repairman might not even notice a missing sticker then, but he will notice it if it's broken.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: thetooth on January 09, 2014, 06:54:23 pm
I believe in at least most Western countries you don't void your warranty by opening your product and you don't void your warranty by destroying or removing any warranty sticker.
Nonetheless, it might save you time to remove the sticker without breaking it (which is easy to do), then in possible arguments/discussions with companies and service personnel - which is, after all, the point of Mike's video.
Yes I fully agree with that. If you can open your device without damaging the sticker then by all means do it as it doesn't require much effort. Even if the warranty isn't broken with a broken sticker, the seller might argue otherwise until they are told otherwise by a consumer organisation or court. It could potentially save you a lost of hassle and arguing even if you have the law on your side.

But remember you shouldn't just give up possible future warranty claims just because of a broken or missing "warranty void" sticker - or a custom firmware for that matter.


I have also read (on this forum IIRC) one who completely removed his warranty sticker and all goo traces of it on his Rigol and later sent it to repair under warranty. They repaired it under warranty without complaining of any sticker missing.

I also read about another one who sent a DP832 to have the the PCB replaced with the new improved version with a larger heatsink. When he received it back from repair the warranty void sticker was missing or broken. So what's he supposed to do if he has another warranty claim and the warranty is broken by a missing sticker when he got it back from repair? I'm pretty sure I read it somewhere on this forum and I think it was TEquipment he sent it to.

I've also read of one where the sticker was missing on a device from new. And how can the seller even prove there has ever been a sticker on a device even if there has been? They could also have forgot to put it on during production.
So if you have a broken sticker it's better to just remove it completely and all it's goo traces before sending it to repair. The repairman might not even notice a missing sticker then, but he will notice it if it's broken.
Its only real use for warranty is if you cut the sticker, clearly this means someones opened the device, a removed or partially lifted sticker has no meaning at all because they will detach/become damaged naturally.

In my experience the _only_ people who check those stickers are asshole merchants selling low value items that are too cheap to pay the return shipping, here in Australia i've seen just about every level of stance on warranty from companys like Dell Business who have sent replacement equipment before i even sent the faulty item back based entirely on my word(they did check the item and sent a report confirming the problem), to a computer store that refused to honor basic consumer law until we had police presence.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndreaEl on January 09, 2014, 11:01:30 pm
Are some days that i not follow this topic and i have some question that i have not understand...

I have a Rigol DS2072 (HW 2)
I have a not update firmware and i must update, is right that the last version is: 00.02.01.00.03? (I have read about clear FRAM after update).

With this version is available the 300MHz BW Option, but i have read that 200MHz BW option give more performance in LF than 300MHz in HW 1. Is the same for HW 2 or i can Install 300MHz BW with no problem in my HW 2?

I have read about newest code for enable 300MHz and CAN, but not understand what enable each code. I have read about DSHH, DSGH etc.
I search for: 200MHz + All Option (include CAN), 300MHz + All Option.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on January 09, 2014, 11:28:41 pm
Are some days that i not follow this topic and i have some question that i have not understand…
Deja vu :o  from Reply #2390  :D

I have a Rigol DS2072 (HW 2)
I have a not update firmware and i must update, is right that the last version is: 00.02.01.00.03?
Here are the latest Firmware versions by Rigol product family as of January 7th, 2014:
http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm (http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 10, 2014, 12:02:45 am
I have a Rigol DS2072 (HW 2)

With this version is available the 300MHz BW Option, but i have read that 200MHz BW option give more performance in LF than 300MHz in HW 1. Is the same for HW 2 or i can Install 300MHz BW with no problem in my HW 2?
For HW 2 use 300 MHz.

I have read about newest code for enable 300MHz and CAN, but not understand what enable each code. I have read about DSHH, DSGH etc.
I search for: 200MHz + All Option (include CAN), 300MHz + All Option.
Use DSHH for HW 2 (300 MHz with all options).
Use this keygen http://riglol.3owl.com (http://riglol.3owl.com)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: granz on January 10, 2014, 02:38:41 am
Gentlemen,

I recently purchased a DS2072A from Tequipment and discovered this thread in regards to hacking it (nice work so far!)  I've opened it up and I'm trying to get another dump as it seems like that would be useful to people.  I would have offered to write those C routines but I guess someone beat me to it.  I have two different JTAG interfaces on hand, a Xilinx Platform USB Cable, and an Altera USB Blaster.  I first tried the Xilinx cable under Linux with bfin-jtag with no luck even connecting to it, same with the Altera one.  I decided to give it a try under windows and first tried to generic urjtag package, which works with the Altera cable and I see the BF526 (see image).  Unfortunately bfin-jtag doesn't want to see either interface...  (Both cables work fine with their respective proprietary software.)

It looks like the generic urjtag doesn't have the bus support needed, is this correct?  I see many more options from "help initbus" under bfin-jtag.

I've tried installing different versions of the drivers etc, with no luck, but it looks like maybe bfin-jtag is looking for a different USB VID/PID based on the message.  Anyone have any ideas?  I don't mind ordering yet-another JTAG cable, but I assume the sooner I can post another memory dump the better.

My scope came with software 00.02.00 and I haven't updated it.

(http://)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Posterisan on January 10, 2014, 07:05:43 pm
...
But it's the old problem: People are only sitting around and waiting for the keygen and don't would like to break her warranty seal on the scope to provide a memory dump... This is bad indeed...  ::)

Today I ordered a DS2072A and a Segger J-Link JTAG adapter. I hope I can provide a memory dump next week .
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: nonosoft on January 10, 2014, 08:51:28 pm
Hi,
Today I received my DS2072A, I had ordered a DS2072 non A from Batronix (Germany) but received a A model. I think non-A model are going to be replaced by A.

I'm really insterested by the possibility to unlock decoding options.

Reading this topic I understood that you need memory dump from A model to help decrypt the protection.
I would like to help and I'm ready to open my oscilloscope to make this dump but I'm not very familiar with JTAG, maybe someone could make a small tutorial to explain how to proceed ?

For now I have only a Bus Pirate that can act as a slow JTAG device, but if needed I could buy a real JTAG programmer.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: granz on January 10, 2014, 09:12:56 pm
OK,

I have an update after trying some more today.  I've gotten the Altera USB-Blaster JTAG adapter to work with the blackfin tool chain.  It seems to work fine on a 32-bit Linux box.

I now have a working gdb interface after starting bfin-gdbproxy and connecting to it.  I can freely access memory and registers at this point.

If anyone else is looking for a JTAG interface for this, the knock-off Altera one (called "mini") is < $10 on eBay (US).  Working on memory dump now.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: granz on January 10, 2014, 11:26:42 pm
For now I have only a Bus Pirate that can act as a slow JTAG device, but if needed I could buy a real JTAG programmer.

I don't think it's worth the time to try to use a Bus Pirate.  You need access to all of the memory available to the Blackfin DSP (BF526), so, the software needs to be aware of the specific bus interface (DRAM for example is attached to the BF526 but not directly to JTAG port).  Since JTAG is just a low-level generic interface, there is more involved in accessing the system.  The Blackfin toolchain uses a modified version of UrJTAG.  Have a look here for supported cables:

http://urjtag.org/book/_system_requirements.html#_supported_jtag_adapters_cables (http://urjtag.org/book/_system_requirements.html#_supported_jtag_adapters_cables)

The blackfin-specific tools can be found at blackfin.uclinux.org (http://blackfin.uclinux.org).  For the least headache it probably makes sense to just use the provided dev tools.

Essentially you run a proxy server (bfin-gdbproxy) which uses the physical JTAG cable and is aware of the BF526 and acts as a server for gdb (GNU debugger).  Then you start up gdb and connect to the server (locally, but using TCP/IP).  In case you're not familiar with why this is the way it is: In the UNIX/Linux world it's fairly common practice to run a gdb server on an embedded system and then connect to it from a development host for debugging.  In this case, we just use JTAG for the physical interface and a local server to make gdb happy. 

Hope that helps.

-Chris
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: granz on January 11, 2014, 03:27:27 am
OK, memory dumps complete!

I put everything in the same format that tirulerbach posted and followed the same procedure (only interaction was entering code AAAAAAA BBBBBBB CCCCCCC DDDDDDD and pressing apply once).

For some reason I couldn't get the processor instruction cache locations, but I got all dram, and everything else.  I see the dummy code in there when I look at it with a hex editor and also readable strings).

I did the initial dumps with my original firmware 00.02.00.00.04, then updated to 00.02.01.00.03 and did everything again.

Also, until a few days ago I had no experience with this or any Rigol product so I didn't realize that it didn't display full version number without following the procedure in marmad's thread.  I've done that, and updated the README.txt files in each package to match my information.  It's exactly the same as tirulerbach's except for being a DS2072A instead of a DS2202A.

I'm planning to re-assemble my scope now, because I'd like to use it again.  Before I do that is there anything else that would be useful to folks?

https://mega.co.nz/#!MhE22KKZ!Uj3JHCyWlyoLwRNBRO2QxBr46-9sZ1GlDnYA5A73I1Y

https://mega.co.nz/#!8lk2jDRT!do2XD3qit0R9Je7qBaY9GitFSfFUqG6zPuw5I0dDyaI

https://mega.co.nz/#!MpUTXKTS!X9H7S2fEccgtJ5S_xRhizQqIS2QG4XU8ETlDDqIj_yY

https://mega.co.nz/#!s0tHDKYY!RoQZ1XR5ecREZNLoEFXJkRJ_YFhdCeikPaEczS07pb4


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 11, 2014, 09:59:19 am
I'm planning to re-assemble my scope now, because I'd like to use it again.  Before I do that is there anything else that would be useful to folks?
People have asked for pictures of the  input stage and the SMD jumper settings earlier in this topic: https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg352206/#msg352206 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg352206/#msg352206)
Someone can take a better picture of the DS2xxxA's input stage?    Apelly for example.
Busy, but I'll take a look in the next 48 hrs.
Ok, perfect, if you can take pictures of the rest, jumpers, DC / DC ...
Thanks.  :-+
No susprises.

These will have to do for now... The 'scpoe's still open, so can take more, but even a linux buff like me needed to look up a quick way to resize pics.

Just let me know what you want to see.
Can you take pics of the jumper resistor divider just by the battery. Thanks
Jumpers:

HW v1.0:
(https://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0/?action=dlattach;attach=56798;image)

A or v2.0:
(https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/?action=dlattach;attach=72850;image)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tirulerbach on January 11, 2014, 11:36:28 am
Thank you for the dumps. They look good.

I'm planning to re-assemble my scope now, because I'd like to use it again.  Before I do that is there anything else that would be useful to folks?

People are asking for the JTAG connection and so on. Maybe some photos how and where to connect the JTAG dongle are useful.

Beside this, dumps with the old firmware 00.02.00.00.04 are not needed, as far as I know.

Regarding the keygen: Basically it is finished and work nice. Release date: TBD.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Pehtoori on January 11, 2014, 12:05:39 pm

I don't think it's worth the time to try to use a Bus Pirate.  You need access to all of the memory available to the Blackfin DSP (BF526), so, the software needs to be aware of the specific bus interface (DRAM for example is attached to the BF526 but not directly to JTAG port).  Since JTAG is just a low-level generic interface, there is more involved in accessing the system.  The Blackfin toolchain uses a modified version of UrJTAG.  Have a look here for supported cables:

http://urjtag.org/book/_system_requirements.html#_supported_jtag_adapters_cables (http://urjtag.org/book/_system_requirements.html#_supported_jtag_adapters_cables)

8< snip 8<

Ohh crap  |O


I decided to help and open my upcoming scope. Ordered TIAO USB Multi-Protocol Adapter (JTAG) to get memory dump from it. Now I learn that I need specific adapter for uclinux :(

This is one reason why its hard to get those dumps! Not really good instructions for the noobs (like me).

Had someone writen instructions like:
Order this adapter from here! (check that its available around the world)
And connect it to scope pins like this (pictures and diagram)
Download this software from here
Run these commands
Send this file to here

Yes this information is available here and around the net, but its really hard to noobs (like me) to piece this all together and get the results we need. And yes I have read this thread trough and some others but didn't find single post that describes all needed steps in one post.


Second note: Those pics of all options enabled seem to speed up people getting those dumps done  8)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Pinkus on January 11, 2014, 12:12:02 pm
Pehtoori wrote down my (and probably many others) thoughts.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 11, 2014, 12:33:41 pm
The Blackfin toolchain uses a modified version of UrJTAG.  Have a look here for supported cables:
http://urjtag.org/book/_system_requirements.html#_supported_jtag_adapters_cables (http://urjtag.org/book/_system_requirements.html#_supported_jtag_adapters_cables)
Ohh crap  |O

  • Order scope [check]
  • Order JTAG-adapter [check] (TIAO USB)
  • Learn that you likely ordered wrong adapter [check]

I decided to help and open my upcoming scope. Ordered TIAO USB Multi-Protocol Adapter (JTAG) to get memory dump from it. Now I learn that I need specific adapter for uclinux :(
TIAO USB works with UrJTAG according to this: http://www.tiaowiki.com/w/Program_FPGA_Using_urJTAG (http://www.tiaowiki.com/w/Program_FPGA_Using_urJTAG)
So I think it should work for making a Rigol memory dump.

TIAO USB is based on FTDI FT2232H and most of the FT2232-based JTAG interfaces seems to work with UrJTAG. Not all of them are listed at http://urjtag.org/book/_system_requirements.html#_supported_jtag_adapters_cables (http://urjtag.org/book/_system_requirements.html#_supported_jtag_adapters_cables) but many of them are clones or very similar to each other. UrJTAG just mentions this, to cover FT2232-based USB JTAG adapters not listed:
Quote
Other FT2232-based USB JTAG cables (experimental)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tirulerbach on January 11, 2014, 12:41:32 pm
This is one reason why its hard to get those dumps! Not really good instructions for the noobs (like me).

That's life. No pain no gain. It's your chance to improve the situation: Start a tutorial, you already learned some pieces!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on January 11, 2014, 12:43:02 pm
*looks at tirulerbach with puppy eyes*

^^;
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: battlefield on January 11, 2014, 12:51:08 pm
Ok so I'm getting myself an JTAG cable but its not listed on that page. Mine is Olimex ARM-USB-OCD, now can someone please tell me if it will work or not?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Pehtoori on January 11, 2014, 01:15:36 pm
This is one reason why its hard to get those dumps! Not really good instructions for the noobs (like me).
That's life. No pain no gain.

If you know me, you would not say that  >:D I'm sick, in constant pain and can't work because of it. But np you don't know me.

But you miss the point, what I mean is that many people have written instructions on parts of the process, but there is no complete process collected in one place. Would be much easier to point people to that document than write answers over and over again.

Reduce pain, get more gain.  O0

Quote
It's your chance to improve the situation: Start a tutorial, you already learned some pieces!

Waiting for my scope and JTAG-adapter from customs. If I can make the dump and I have energy (sickness eating it) I will do this.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: buergi on January 11, 2014, 03:59:55 pm
Hey,
as it took me many hours to gather all the information needed to memdump my DS2KA I'd like to give a short summary to lower the pain for the gain. So here we go.

First of all the principles. Rigol implemented a lot of feature in the scopes that are artificially restricted to work only for a 4000 minutes trial period. After that time you have the opportunity reenable them forever by purchasing license keys from Rigol. These license keys are bound to each specific device via its serial number.

License verification mechanism

Thanks to zombie28's great work he managed to reconstruct the way the signature verification works.
To give you a short overview I'll rougly summarize the mechanism in the following for all the details check out zombie28's code (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg362575/#msg362575).
The License Key contains the desired options as well as a signature. With this signature the manufacturer signs that the scope with the serial number the license key was generated for is allowed to use the options. The following diagram depicts the process (I dropped some details for simplicity). For details about ECDSA I recommend you kakaroto's blog post (http://kakaroto.homelinux.net/2012/01/how-the-ecdsa-algorithm-works/).

(https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/?action=dlattach;attach=76008;image)

To verify the signature the scope needs the following information, that thus need to be stored in its memory
For generating signatures we furthermore need the Private key which is not stored in the memory.
Usually the whole sense of public-key crypto algorithms is that you cannot calculate the private from the public key (besides brute force of course). I'm not sure how but it seems tirulerbach has it's tricks: his ecc-smash tool (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg364104/#msg364104) seems to generate the key in milliseconds  (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg362551/#msg362551).

So tirulerbach can now generate valid license codes for us, BUT unfortuately the RC5,XXTEA and public keys differ between the devices (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg362551/#msg362551). It is currently not known if there is some hidden scheme between the different devices. Thats why currently we have to provide memory dumps to tirulerbach (and to zombie28?). But how to get them?

Memory dumping

Fortunatelly Rigol has integrated a fully functional JTAG debug port to the Blackfin BF526 which is responsible for all the crypto stuff. So all we need to do is to connect to it and grab the dump. However not all of as are JTAG-lords and a big question mark hovers over the heads of a lot of us :D So here comes a step by step guide:

Requirements

I'm one of those nerds who owns an OpenMoko phone including debug board and never knew what to do with it now the time has come to brush the dust of my good old OpenMoko Debug Board v3 (http://wiki.openmoko.org/wiki/Debug_Board_v3). It includes a FT2232 compatible JTAG connector with a usual ARM 20 pin connector (http://www.jtagtest.com/pinouts/arm20).

(https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/?action=dlattach;attach=76010;image) (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/?action=dlattach;attach=76010;image)

Step by Step Guide
Code: [Select]
# cd opt/uClinux-45/bfin-uclinux/bin
# sudo ./bfin-gdbproxy --debug bfin --frequency=5000000
Found USB cable: USB-JTAG-RS232
Connected to libftdi driver.
IR length: 5
Chain length: 1
Device Id: 00100010011111100100000011001011 (0x227E40CB)
  Manufacturer: Analog Devices, Inc. (0x0CB)
  Part(0):      BF526 (0x27E4)
  Stepping:     2
  Filename:     ./../share/urjtag/analog/bf527/bf527
warning: USB-JTAG-RS232: untested cable, set wait_clocks to 30
warning:   bfin: no board selected, BF526 is detected
notice:    bfin: jc: waiting on TCP port 2001
notice:    bfin: jc:  (you must connect GDB before using jtag console)
notice:    bfin-gdbproxy: waiting on TCP port 2000

Code: [Select]
# cd opt/uClinux-45/bfin-uclinux/bin
# ./bfin-uclinux-gdb
(gdb) target remote :2000
Remote debugging using :2000
0xffa0142e in ?? ()
(gdb) info mem
Using memory regions provided by the target.
Num Enb Low Addr   High Addr  Attrs
0   y   0x20000000 0x20400000 rw nocache
1   y   0xef000000 0xef008000 ro nocache
2   y   0xff800000 0xff804000 rw nocache
3   y   0xff804000 0xff808000 rw nocache
4   y   0xff900000 0xff904000 rw nocache
5   y   0xff904000 0xff908000 rw nocache
6   y   0xffa00000 0xffa0c000 rw nocache
7   y   0xffa10000 0xffa14000 rw nocache
8   y   0xffb00000 0xffb01000 rw nocache
9   y   0xffc00000 0xffe00000 rw nocache
10  y   0xffe00000 0x100000000 rw nocache

Code: [Select]
target remote :2000
dump binary memory ~/ds2k_00_sdram.bin   0x00000000 0x07FFFFFF
dump binary memory ~/ds2k_01_abank0.bin  0x20000000 0x200FFFFF
dump binary memory ~/ds2k_02_abank1.bin  0x20100000 0x201FFFFF
dump binary memory ~/ds2k_03_abank2.bin  0x20200000 0x202FFFFF
dump binary memory ~/ds2k_04_abank3.bin  0x20300000 0x203FFFFF
dump binary memory ~/ds2k_05_boot.bin    0xEF000000 0xEF007FFF
dump binary memory ~/ds2k_06_dbankA.bin  0xFF800000 0xFF803FFF
dump binary memory ~/ds2k_07_dbankAc.bin 0xFF804000 0xFF807FFF
dump binary memory ~/ds2k_08_dbankB.bin  0xFF900000 0xFF903FFF
dump binary memory ~/ds2k_09_dbankBc.bin 0xFF904000 0xFF907FFF
dump binary memory ~/ds2k_10_ibankA.bin  0xFFA00000 0xFFA07FFF
dump binary memory ~/ds2k_11_ibankB.bin  0xFFA08000 0xFFA0BFFF
dump binary memory ~/ds2k_12_ibankC.bin  0xFFA10000 0xFFA13FFF
dump binary memory ~/ds2k_13_scratch.bin 0xFFB00000 0xFFB00FFF


If you are nice to tirulerbach he'll send you a bunch of license keys which you can enter either directly on the scope via Utility>Options>Setup>Editor ON or using
SCPI :SYSTem:OPTion:INSTall <keyhere>

Hope this guide helped you and you will all diligently commit your memory dumps.
Good luck, have fun with your scopes and happy hacking.

Changelog
2014-01-11 Initial post
2014-01-12 Inline attached images. Add some additional clarifications based on comments. Add list of working JTAG adapters.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tirulerbach on January 11, 2014, 04:33:34 pm
Thank you buergi for your tutorial  :-+

For generating signatures we furthermore need the Private key which is not stored in the memory.
Usually the whole sense of public-key crypto algorithms is that you cannot calculate the private from the public key (besides brute force of course). I'm not sure how but it seems tirulerbach has it's tricks: his ecc-smash tool (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg364104/#msg364104) seems to generate the key in milliseconds (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg362551/#msg362551).
To be precisely, it takes about 70ms on my machine...  :-DD

But that's not the point. I only searched the internet and ripped some tools together. In the meantime, my license generator evolved and is ready. Now it goes to beta test to selected people...  8)

For a appetizer look at the screenshot. Total running time is about 300ms...   O0

(https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/?action=dlattach;attach=76013)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 11, 2014, 04:53:57 pm
Hey,
as it took me many hours to gather all the information needed to memdump my DS2KA I'd like to give a short summary to lower the pain for the gain. So here we go.

Nice summary. andyturk (the OP) should copy and paste a link to this post in the first post of the thread.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: granz on January 11, 2014, 05:05:34 pm
Nice tutorial buergi!  I was going to write something up, but you've saved me the trouble and it looks excellent.

I've reassembled my scope at this point but I took pictures of lots of stuff first, including smd jumpers and the input stage.  As I have a busy weekend, I'll have to unload those and post them tomorrow.

In regards to the JTAG adapters, most any FTDI2232 based atapter *should* work.  I used a cheap knock-off Altera adapter, which is based on that chip (see image).  They've removed the markings for whatever reason (WHY bother on a < $10 imitation product??), but it uses the ftdi driver.

One thing to check with whatever adapter you might have is the signal levels--you don't want to attach a 5V adapter to the board.  There is no real standard for JTAG.  The better adapters (for example, the Amontec JTAGKey) use the the VTref pin to set the signal levels (This is likely the purpose of the 3.3V on the DS2000 JTAG header).  The easiest thing to do is use your scope (before opening it!) to probe the JTAG adapter TCK line and then start up bfin-gdbproxy.  If you get nothing, your adapter might need a VTref input.  No matter what, check the levels on all of the pins before connecting to your scope's header...

Also, you don't absolutely have to connect the target reset and system reset lines to your adapter (nTRST and nSRST), just having the pull-ups on them is fine.  My adapter actually was trying to drive these pins high, so I didn't connect them and just left the pullups to the board's supply.

Happy dumping!

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: thinwire on January 11, 2014, 05:23:18 pm
buergi, excellent summary!  :-+ :-+ :-+
I would have two more questions:
Are still two dumps necessary or is it sufficient to dump after a normal boot?
Is a specific firmware version needed? Will 00.02.00.00.04 be fine?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Pehtoori on January 11, 2014, 05:40:48 pm
Hey,
as it took me many hours to gather all the information needed to memdump my DS2KA I'd like to give a short summary to lower the pain for the gain. So here we go.

Thx buergi this is what I meant! Even shorter text would have done it.

And thx to cybernet, tirulerbach, zombie28, marmad and many more! (Not exhaustive list, sorry, can't remember all)

Now I wait to get my scope and adapter.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: van-c on January 11, 2014, 07:02:53 pm
I have a Rigol DS2072 (HW 2)

With this version is available the 300MHz BW Option, but i have read that 200MHz BW option give more performance in LF than 300MHz in HW 1. Is the same for HW 2 or i can Install 300MHz BW with no problem in my HW 2?
For HW 2 use 300 MHz.

I have read about newest code for enable 300MHz and CAN, but not understand what enable each code. I have read about DSHH, DSGH etc.
I search for: 200MHz + All Option (include CAN), 300MHz + All Option.
Use DSHH for HW 2 (300 MHz with all options).
Use this keygen http://riglol.3owl.com (http://riglol.3owl.com)

Has it actually been verified that the HW 2 version with 300 MHz enabled does not have the overshoot and stability problems demonstrated for HW 1?  Did someone post a graph showing the HW 2 frequency response?  I have re-checked the thread but may have missed it.

--Van
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sled on January 11, 2014, 08:31:50 pm
I have an Arduino Leonardo and a Teensy 3.1 lying around, maybe I can code/build my own urjtag compatible adapter, doesn't seem to be that hard :)

Is anyone else interested in such a thing?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ZeroAviation on January 11, 2014, 08:39:10 pm
@buergi

Epic first post!!!!

Cheers!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tirulerbach on January 11, 2014, 10:17:36 pm
Ok so I'm getting myself an JTAG cable but its not listed on that page. Mine is Olimex ARM-USB-OCD, now can someone please tell me if it will work or not?

Works. I made the dump using this one. The only caveat was the 3.3 Volt reference. The 3.3V reference on the DS2202A JTAG header was to weak for the ARM-USB-OCD. I used 3.3V from a header in the vicinity of the BNC socket:

There is a "SPI BOOT" header oh the right side of the PCB. Pin 7 has 3.3 Volts and it works...

I didn't use any pullup resistors etc. but just connected the ARM-USB-OCD straight to the DS2202A using short (about 6cm) jump-wires and set the JTAG speed to 6 MHz. Dump took about 15 minutes. Too bad, I made no photos.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: elecBlu on January 11, 2014, 10:21:51 pm
Has it actually been verified that the HW 2 version with 300 MHz enabled does not have the overshoot and stability problems demonstrated for HW 1?  Did someone post a graph showing the HW 2 frequency response?  I have re-checked the thread but may have missed it.

--Van

did some tests but i'm not able to do a proper frequency response chart during some problems with my generator. check my older posts for details and 300MHz measurements.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: andyturk on January 12, 2014, 04:09:05 am
Nice summary. andyturk (the OP) should copy and paste a link to this post in the first post of the thread.

Good idea. Done.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybermaus on January 12, 2014, 11:36:23 am
Minor correction to my previous post after some further investigation.

DSHA also enables the 500uV setting and another unknown, (at present), option.

Just a report back in case others DS1074Z users are searching for it: The unknown DSCA option does not seem to be related to the signal generator.

As I had the less common -S model I was thinking (hoping) the unknown option was related to the signal gen, which means most people would not notice its effect. So I memorized all the signal menu and inserted the option. But I found no extra menu or option afterward. (Especially I was hoping for  a SWEEP option, that is a big miss in the SG functionality)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Buzz239 on January 12, 2014, 01:43:26 pm
I've gone through 95 pages of the post to try to find the information for the Rigol DSA815-TG. I downloaded 3 license keys from the key generator at http://rigol.avotronics.co.uk (http://rigol.avotronics.co.uk). I have the firmware to 01.08.00 installed already and
I need to downgrade the firmware to 01.06.00 ( I guess).  When I enter the software key, Is this going to add it to the list of license keys or, will it erase one of the existing keys (see attachment)? The www.riglol.3owl.com (http://www.riglol.3owl.com) site times out every time I try to access it. Where do I get the 01.06.00 firmware for the downgrade? If
someone could please direct me to the information (the search engine stinks) I need it would be greatly appreciated.

TNX, Gary
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: olepr01@gmail.com on January 12, 2014, 01:57:26 pm
Riglol works just fint from here (Northern Europe). The licenses will replace the inactive entries in the list. Don't know about downgrading.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Altemir on January 12, 2014, 02:55:33 pm
Buzz239
If you want, you can find 00.01.06 and 00.01.07 firmwares from this folder (https://www.mediafire.com/folder/wfheqp3cfvnap/DSA815)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Buzz239 on January 12, 2014, 03:05:16 pm
Thanks Guys,
I didn't have to downgrade and every thing works GREAT.

73 Gary,KF9CM
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 12, 2014, 04:41:37 pm
The www.riglol.3owl.com (http://www.riglol.3owl.com) site times out every time I try to access it.
There's a mirror of that site here: http://rigol.avotronics.co.uk/mirrors/riglol/ (http://rigol.avotronics.co.uk/mirrors/riglol/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tsmith35 on January 12, 2014, 11:55:42 pm
The www.riglol.3owl.com (http://www.riglol.3owl.com) site times out every time I try to access it.
Strangely, it's the same for me here. Before the mirror, I just went to the site through a random free proxy.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pascal_sweden on January 13, 2014, 11:58:04 am
Do you need to open the scope to generate the license keys specific to your scope?

Or are they working on finding the private key so that you can generate the license keys without opening the scope?
I don't like the idea of opening up my scope =)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Buzz239 on January 13, 2014, 12:36:50 pm
All I did was go to SYSTEM > 2nd page> license>INSTALL and enter the key code.

73, Gary KF9CM
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gunb on January 13, 2014, 02:22:02 pm
I've gone through 95 pages of the post to try to find the information for the Rigol DSA815-TG. I downloaded 3 license keys from the key generator at http://rigol.avotronics.co.uk (http://rigol.avotronics.co.uk). I have the firmware to 01.08.00 installed already and
I need to downgrade the firmware to 01.06.00 ( I guess).  When I enter the software key, Is this going to add it to the list of license keys or, will it erase one of the existing keys (see attachment)? The www.riglol.3owl.com (http://www.riglol.3owl.com) site times out every time I try to access it. Where do I get the 01.06.00 firmware for the downgrade? If
someone could please direct me to the information (the search engine stinks) I need it would be greatly appreciated.

TNX, Gary

Hi Gary,

short question, didn't follow the thread for a while: why do you need to downgrade? Don't the keys work for V. 01.08.00 anymore?


Kind regards
Gunb
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on January 13, 2014, 02:48:41 pm
Hi Gary,
short question, didn't follow the thread for a while: why do you need to downgrade? Don't the keys work for V. 01.08.00 anymore?
Kind regards
Gunb

He wrote it five messages before. See Reply #2463.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gunb on January 13, 2014, 03:11:30 pm
Hi Gary,
short question, didn't follow the thread for a while: why do you need to downgrade? Don't the keys work for V. 01.08.00 anymore?
Kind regards
Gunb

He wrote it five messages before. See Reply #2463.

OK, thx!

Hmm, slowly this thread seems to need a TOC  ;D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on January 13, 2014, 03:33:30 pm
does the new secret A-version keygen need dumps or will it work without? :o
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: granz on January 13, 2014, 03:44:12 pm
Here are some pictures of the internals of my DS2072A, including images of the input stage under the RF shield, for those interested.

My version info is:

Serial: DS2D....
Hardware version: 1.0.2.0.2
FPGA version:
    SPU: 03.01.09
    WPU: 00.07.01
    CCU: 12.29.00
    MCU: 02.13

Also, I can confirm that tirulerbach's keygen works nicely (scope now thinks it is a DS2202A  :-+).  I'll try to take some bandwidth measurements hopefully soon and report back...

Hopefully the image names make sense (feel free to ask for clarification).  Some of the close-ups are low resolution unfortunately, because I could only get a cheap USB microscope in there without further disassembly.

Another thing I thought of that tirulerbach mentioned about the JTAG connection: You shouldn't need the pull-ups at all as long as your adapter is driving the nTRST and nSRST lines high (my FT2232H-based adapter does that, and I assume almost all would).  If you use the pull-ups you don't need to connect those lines to your adapter at all--just leave them pulled-high for the mem dump.

Hope the images are useful !

(full back image, jumper image, and one input stage image attached, all in .zip)

https://mega.co.nz/#!I89GxaqI!bTPeSVsWpN8jEXoa44ejMDz3aOM5A-zmMqczeo_31c8

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dr.diesel on January 13, 2014, 04:51:37 pm
Keygen worked great for unlocking all decode options on the new MSO4000s.

Thanks again to all involved.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: whotopia on January 13, 2014, 04:54:13 pm
Hi all,
With all the JTAG memory image mining going on has anyone figured out where the serial number is stored in the DS2xxx?  I rolled back my firmware and the serial number was reset to default.  Anyone have any ideas on how to 'fix' this?  Also, has anyone determined if the firmware allows for the serial number to be changed via uploading a file like on the DG4000? 
My JTAG adaptor is in the mail.  I hope to help out soon.
Thanks!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 13, 2014, 05:12:26 pm
Hope the images are useful !

(full back image, jumper image, and one input stage image attached, all in .zip)

https://mega.co.nz/#!s0tHDKYY!RoQZ1XR5ecREZNLoEFXJkRJ_YFhdCeikPaEczS07pb4
Looks like you linked to the wrong file "ds2072a_00.02.01.00.03-enter-key.tar.gz", this looks like memory dumps (.bin files) and not images.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 13, 2014, 05:13:07 pm
With all the JTAG memory image mining going on has anyone figured out where the serial number is stored in the DS2xxx?  I rolled back my firmware and the serial number was reset to default. 

It would be helpful if you posted the following info about your loss of serial number:
a) Exact model and HW revision you have (e.g. non-A, HW v.1.0.1)
b) Which FW versions you rolled back FROM and TO (e.g. FROM: FW v.02.01.00.03 TO: FW v.01.01.00.02)
c) Which FW up/downgrading method you used to roll back the FW (e.g. at boot)
d) If you had any options installed when you rolled back the FW (e.g. all options installed)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: granz on January 13, 2014, 05:16:09 pm

Looks like you linked to the wrong file "ds2072a_00.02.01.00.03-enter-key.tar.gz", this looks like memory dumps (.bin files) and not images.

Weird, I'm like 99% sure I selected the right file in mega.  (Guess I should double check afterwards).  Anyhow, I've fixed the link, thanks for the heads up.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on January 13, 2014, 05:39:44 pm
LOL...  :-DD

Hardware version: 1.0.2.0.2:
(https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/?action=dlattach;attach=76538;image)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tirulerbach on January 13, 2014, 06:15:26 pm
does the new secret A-version keygen need dumps or will it work without? :o

The keygen still need dumps and some developers too to make further investigations.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on January 13, 2014, 06:16:41 pm
ahh darn ... I dun have linux or a USB jtag lol

btw: if not ferrites, are these 0603 resistors?
step by step, they won't print values on resistors anymore to reduce costs
could be the reason, doesn't have to be the reason xD
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: elecBlu on January 13, 2014, 06:32:16 pm
LOL...  :-DD

nothing special about this, there are some unmarked resistor series out there. i doubt they choose this resistors because of the missing value on it, it should be a tolerance/price/availability thing.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tirulerbach on January 13, 2014, 06:42:01 pm
JTAG DS2000A
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: anson80 on January 13, 2014, 07:32:01 pm
I just joined the forums,My English is not good.
 I have a newly purchased DS2102A.Its system info on the picture
 I would like to help and I'm ready to open my oscilloscope to JTAG this dump, but I'm not very familiar with in windows system JTAG,Can some guidance?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on January 13, 2014, 08:20:43 pm
I found function responsible for loading and decrypting keys from flash, so I can confirm that the keys are not generated by the firmware itself (this wouldn't make any sense in case of public key anyway). I have also analyzed a few memory dumps from scopes of the same model (DS2072A), manufactured in consecutive weeks of 2013, and all of them had different key sets. So the keys are changed at least once a week.

Update: Rigol doesn't need to maintain database of all keys, because they can be generated algorithmically from scope's serial number, including ECC private key. However it is practically impossible to find out what algorithm it is, having only the keys.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on January 13, 2014, 08:39:19 pm
But how is the process of buying a key?, what is collected from the scope to enable the correct key to the user?
If they change keys often in the scope, that would make it harder for Rigol, no?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 13, 2014, 08:52:55 pm
But how is the process of buying a key?, what is collected from the scope to enable the correct key to the user?
If they change keys often in the scope, that would make it harder for Rigol, no?
They need your Rigol's serial number when ordering a SW option. Their computer would know what key belongs to what serial numbers. It probably all computer automated so it wouldn't make it harder for them.

The bad thing is for customers is that a SW option is tied to a specific device, so if they break their device and have to buy a replacement, they will also have to pay for all the extra option keys again.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on January 13, 2014, 09:02:15 pm
Zombie28: what "production weeks" do you have atm?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on January 13, 2014, 09:15:21 pm
Zombie28: what "production weeks" do you have atm?

DS2202A: 42
DS2072A: 43, 44, 46
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on January 13, 2014, 09:20:30 pm
that's the 2 digits after the ds2d15, right?
then I also have one from week 46
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on January 13, 2014, 09:41:15 pm
my ds2202a-s is then week 46 if it is digit 7-8 in the serial
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on January 13, 2014, 09:42:45 pm
that's the 2 digits after the ds2d15, right?
then I also have one from week 46

PM sent, let us know if the keys match your scope
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on January 13, 2014, 09:52:59 pm
I would like to help and I'm ready to open my oscilloscope to JTAG this dump, but I'm not very familiar with in windows system JTAG,Can some guidance?

See posting #2447
A excellent tutorial!  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 13, 2014, 09:58:51 pm
I would like to help and I'm ready to open my oscilloscope to JTAG this dump, but I'm not very familiar with in windows system JTAG,Can some guidance?

See posting #2447
A excellent tutorial!  :-+

Also now linked to in the first post of this thread - in case you forget the number ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on January 13, 2014, 10:03:12 pm
Also now linked to in the first post of this thread - in case you forget the number ;)

Good idea! Just answering the obvious questions. ;)
They all want to hack their scope, but don't take the time to read the thread. No pain, no gain!
Sometime the answer its just five messages away.  :scared:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: anson80 on January 13, 2014, 10:47:49 pm
Also now linked to in the first post of this thread - in case you forget the number ;)

Good idea! Just answering the obvious questions. ;)
They all want to hack their scope, but don't take the time to read the thread. No pain, no gain!
Sometime the answer its just five messages away.  :scared:
If I say I almost from the beginning to see in the end, you will believe that?
Please forgive me, I like serious to read all the articles, but my English is not good,I think have A JTAG method different
I have seen posting #2446 , but like Linux operation
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on January 13, 2014, 10:57:25 pm
If I say I almost from the beginning to see in the end, you will believe that?

I believe it.

Please forgive me, I like serious to read all the articles, but my English is not good, I think A and A through the JTAG method is different
I have seenposting #2447A , but like Linux operation

Ok. You only have windows and you want to know how to do the jtag dump with windows?
If someone provided already a dump from a scope from the same week like yours, it is not necessary to do this dump. In this case be nice to tirulerbach or zombie28 and ask for a key. Make more dumps and send the files to them!

This hacking here is an ongoing process. They all do great work. It needs time and a lot of effort!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: anson80 on January 13, 2014, 11:21:59 pm
If I say I almost from the beginning to see in the end, you will believe that?

I believe it.

Please forgive me, I like serious to read all the articles, but my English is not good, I think A and A through the JTAG method is different
I have seenposting #2447A , but like Linux operation

Ok. You only have windows and you want to know how to do the jtag dump with windows?
If someone provided already a dump from a scope from the same week like yours, it is not necessary to do this dump. In this case be nice to tirulerbach or zombie28 and ask for a key.

If not -> just wait patiently. Maybe someday there will be a ready-to-use keygen for your scope.
This hacking here is an ongoing process. They all do great work. It needs time and a lot of effort!
Thank you for your help
I just want to give some help, I don't care whether can get keygen. I don't want to No pain
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: granz on January 14, 2014, 01:24:02 am
Quick bandwidth measurement animation of my DS2072A after the keygen (now shows as DS2202A in system info).   It's a bit course because of the file size limitation.

I'll create a graph in the next few days which is more complete, but I thought I'd post this to help motivate people to provide more memory dumps.

Setup: Signal generator used was a Tektronix SG 503 Leveled Sine Wave Generator which goes up to 250 MHz.  Output was set at 2.00 Vpp (about +/- 5%) and verified with a 500 MHz scope over the frequency range shown.  All images are at the 5ns time base setting.  I'll include data from other time base settings in the graph.  (Obviously, 50 Ohms -to- 50 Ohms w/ 50 Ohm cable--same cable used to verify signal generator output with other scope).

You might notice that I couldn't actually get to the 3 dB point (~1.41 Vpp) with my signal generator due to it's limited output.  I guess I should build myself a fast pulse generator.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 14, 2014, 01:26:50 am
Quick bandwidth measurement animation of my DS2072A after the keygen (now shows as DS2202A in system info).
Any reason why you didn't upgrade to DS2302A instead of DS2202A?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: granz on January 14, 2014, 01:33:01 am
Actually, I tried that first.  It took the key but nothing happened except that the decode options were unlocked.  The model # stayed the same in system info and I didn't get the 2ns time base option, so I assumed it didn't take.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 14, 2014, 01:37:07 am
Actually, I tried that first.  It took the key but nothing happened except that the decode options were unlocked.  The model # stayed the same in system info and I didn't get the 2ns time base option, so I assumed it didn't take.

2ns time base is already available on DS2202 models (as well as 100M BW limit). 1ns time base becomes available when 300MHz is unlocked.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: granz on January 14, 2014, 01:43:59 am
Yes, I understand that 2ns is normally available on DS2202 models, but mine started as a DS2072A with 5ns as the fastest timebase.  What I meant was that I first tried the 300MHz key, but still had only 5ns TB (no 2ns or 1ns) and no model number change (still claimed DS2072A).  When I then tried the 200MHz key it converted to a DS2202A with 2ns TB.  I didn't try the 300MHz key again after already converting it to a DS2202A, but maybe I should?

Tirulerbach can probably comment more, but he did say the 300MHz option was absolutely untested...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 14, 2014, 02:03:10 am
Actually, I tried that first.  It took the key but nothing happened except that the decode options were unlocked.  The model # stayed the same in system info and I didn't get the 2ns time base option, so I assumed it didn't take.
So the 4 letter options you have tried are NSEQ and NSFH?
For a appetizer look at the screenshot. Total running time is about 300ms...   O0

(https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/?action=dlattach;attach=76013)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: granz on January 14, 2014, 02:06:54 am
Exactly.  I went with NSFH first and although it didn't reject the key, nothing happened (no model# change, still stuck at 5ns, no 100 MHz BW limit).  I guess this confirms that it doesn't work at this point?

I then went with NSEQ and that worked as expected (100 MHz BW, 2ns, model# change+plus shows 200MHZ installed option).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 14, 2014, 02:09:23 am
Exactly.  I went with NSFH first and although it didn't reject the key, nothing happened (no model# change, still stuck at 5ns, no 100 MHz BW limit).  I guess this confirms that it doesn't work at this point?
What about all the other options like CAN decoder bigger memory etc.? Were they not enabled with NSFH either?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: granz on January 14, 2014, 02:20:06 am
All trigger/decoder options including CAN were enabled with NSFH, I can't remember about the sample mem (but I think no), but there was definitely no BANDWIDTH option installed like there is now with NSEQ.  Essentially all NSFH did was remove the trial periods which hadn't yet expired.  Looking back I wish I had taken a screenshot.  I was mostly interested in seeing the 2ns and 1ns TBs and the 100 BW limit, which didn't become available until I used NSEQ (but no 1ns TB).

Hope that helps.

Is there anything known about the SMD jumpers and what they effect?  (Sorry if it's listed elsewhere)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: battlefield on January 14, 2014, 04:57:16 pm
So I'm having one problem with my jtag connection. I connect all the wires as shown in the schematic, using Olimex ARM-USB-OCD and then run the command buergi ran (sudo ./bfin-gdbproxy...) and I get the following in my console:
Code: [Select]
debug:     bfin: bfin_open ()
Found USB cable: ARM-USB-OCD
Connected to libftdi driver.
warning: TDO seems to be stuck at 0
error:     bfin: detecting parts failed
debug:     bfin: bfin_open ()
Found USB cable: ARM-USB-OCD
error: Couldn't connect to suitable USB device.
error:     bfin: cable initialization failed

Also when I plug my JTAG cable in my computer the led turns green and as soon as I run the command it turns red. I'm using linux 12.04 LTS x64
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Flipp on January 14, 2014, 05:10:02 pm
So I'm having one problem with my jtag connection. I connect all the wires as shown in the schematic, using Olimex ARM-USB-OCD and then run the command buergi ran (sudo ./bfin-gdbproxy...) and I get the following in my console:
Code: [Select]
debug:     bfin: bfin_open ()
Found USB cable: ARM-USB-OCD
Connected to libftdi driver.
warning: TDO seems to be stuck at 0
error:     bfin: detecting parts failed
debug:     bfin: bfin_open ()
Found USB cable: ARM-USB-OCD
error: Couldn't connect to suitable USB device.
error:     bfin: cable initialization failed

Also when I plug my JTAG cable in my computer the led turns green and as soon as I run the command it turns red. I'm using linux 12.04 LTS x64

Is there any difference, if you do not connect the jtag side of the Olimex to anything? Is it possible to create a "working" jtag chain without any devices by shorting tdi and tdo pins together? Sounds like you have a break in the jtag chain or a fried input chip on your adapter.

Flip
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: battlefield on January 14, 2014, 05:12:47 pm
Nope, all the same no matter what I do -.-

Edit after shorting TDI and TDO and apllying 3.3V to VREF pin I got this
Code: [Select]
debug:     bfin: bfin_open ()
Found USB cable: ARM-USB-OCD
Connected to libftdi driver.
error:     bfin: detecting parts failed
debug:     bfin: bfin_open ()
Found USB cable: ARM-USB-OCD
error: Couldn't connect to suitable USB device.
error:     bfin: cable initialization failed
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Buzz239 on January 14, 2014, 05:28:47 pm
I guess there is nothing that can be done with the DS1102E it seems like it's already a Hacked DS1052E.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: granz on January 14, 2014, 05:47:01 pm
A couple things to check: do you see any clock activity on the TCK line when looking at it with a scope when you start up bfin-gdbproxy?  Also, I just looked at the image of the connected programmer in the tutorial and it looks like he has the 3.3V from the Rigol JTAG header connected directly to the 3.3V from the other header on the Rigol board.  THIS IS A BAD IDEA. These might be different 3.3V supply rails, and this connects the outputs of both regulators together.  Just leave the 3.3V pin on the JTAG header unconnected.  I didn't notice it originally, but this should be corrected in the tutorial.

With your Olimex ARM-USB-OCD you probably need to supply VREF to set the signal levels, otherwise you'll get nothing.

If you want to play it safe, set your DS2000 scope aside and first try just using a bench power supply with 3.3V connected to the VREF pin of your ARM-USB-OCD.  Start up bfin-gdbproxy and look for the TCK signal.  Also, nTRST should go high as soon as you start bfin-gdbproxy.

I took the image of the ARM-USB-OCD connector from the website and annotated it for you.  I don't have the device, so I can't verify the pinout of the connector.

I hope that helps.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Flipp on January 14, 2014, 06:03:08 pm
I guess there is nothing that can be done with the DS1102E it seems like it's already a Hacked DS1052E.

Those days the topic is not really about  the DS1kE  series anymore. It has grown in federal directions over time.

BTW. I just found out that my DS2072A is another 42nd weeks product just like tirolerbachs DS2202A is one. It would be nice to know if the private keys they used are consistent over the DS2kA series within every production week, wouldn`t it?
There are 2 possibilities how they manage their licence key generation:

1. They have a list of their Keys which are random generated by rolling dice. Their license generator chooses the right key by looking at the Build date in the Serial ##

2. They generate the private key for the ECC in their license key generator by using the serial  number and some sort of super-duper-hyperprivate key and a unknown Scramble or encryption algorithm. This would be very clever for them because all of the vulnerability is in their very secret  own piece of software. No risk of loosing a list of private keys, they simply can keep their super-duper-hyperprivate key in a safe place without the need of weekly updates. We can look if there is any simple correlation between the different private keys.

Best way for us would be to have a firmware which overrides the key verification process but this is a very hard way to go since all the reversing takes a lot of efford. Cybernet has already proven the possibility to toggle some functions like the bw. limit by firmware update.

Flip

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: battlefield on January 14, 2014, 06:05:41 pm
Ok as it looks like it only doesn't work using blacfin tools, it works when I'm using urjtag :D Now let's study some docs to get the right commands for memory dumping
Code: [Select]
jtag> cable arm-usb-ocd
Connected to libftdi driver.
jtag> frequency 5000000
Setting TCK frequency to 5000000 Hz
jtag> detect
IR length: 5
Chain length: 1
Device Id: 00100010011111100100000011001011 (0x227E40CB)
  Manufacturer: Analog Devices, Inc. (0x0CB)
  Part(0):      BF526 (0x27E4)
  Stepping:     2
  Filename:     /usr/share/urjtag/analog/bf527/bf527
warning: ARM-USB-OCD: untested cable, set wait_clocks to 30
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: granz on January 14, 2014, 06:11:09 pm
I've been down that road actually.  You can't get the memory dumps from the generic urjtag because it doesn't have the bus support which is added in the bfin toolchain version.  Check "help initbus" from both versions of urjtag and you'll see the difference.  I also couldn't get the bfin-jtag/bfin-gdbproxy versions to work with my adapter under 64-bit Linux.  They worked for me on a 32-bit Linux box.  Something to do with the ftdi driver I believe.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ju1ce on January 14, 2014, 07:42:29 pm
It turns out that my JLink/urjtag connection is not hanging, instead its just going really really slow  :=\
I've set the frequency to 6 MHz, but its so slow its more like a few kHz (I would check with my scope but the CPU is halted....)

The main problem is the SDRAM - I'm currently trying to dump the full SDRAM address space (128 MB) and its only 1% through after 30 minutes - its going to take too long.... (50hrs?)

On the board it looks as though there's only a single 32 MB SDRAM chip connected to the bf526. I'm gonna assume that its address range is 0x0000 0000 to 0x01FF FFFF and limit the SDRAM dump to that instead.

Sorry for the bad news, but I'm goin to persevere and will let you know how it goes.

If anyone has a J-Link running with urjtag at a decent speed let me know!
Any progress in this Segger J-Link speed issue? I started a dump of my DS2072A (serial DS2D1542xxxxx) FW 00.02.01.00.03, and it will be ready tomorrow night at this pace...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tirulerbach on January 14, 2014, 08:18:43 pm
If someone provided already a dump from a scope from the same week like yours, it is not necessary to do this dump.

:wtf:

Clear and brief: Bullshit.  :--

We have only a few f*cking dumps. But we need 20, 30 or even more dumps to build a valuable data basis.

In this case be nice to tirulerbach or zombie28 and ask for a key.

This simply won't work. Begging for keys is wasted time. Show your support by providing dumps or some other help. That's the only way to take part of the game.

When I then tried the 200MHz key it converted to a DS2202A with 2ns TB. 

Did the scope showed the "200 MHz option" or did the scope show really a different model number?  ???
What is the behavior of non-A-models on bandwidth upgrades?

Tirulerbach can probably comment more, but he did say the 300MHz option was absolutely untested...

Don't know anything about the 300 MHz option, but only install one out of the four licenses. So hook up USB to your scope and use a terminal to tidy up. Beyond that, read your PM.

BTW. I just found out that my DS2072A is another 42nd weeks product just like tirolerbachs DS2202A is one. It would be nice to know if the private keys they used are consistent over the DS2kA series within every production week, wouldn`t it?

A dump will help.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on January 14, 2014, 08:47:50 pm
uah ... I'd make a memdump if I had linux (which can be downloaded, windows is not possible, if I got it right), a spare PC to install it on (which I dun have), a USB jtag (only have serial, gah)
beside that, I'm now puzzled about the way to connect after reading the posting above (about the 3V3 connection) -_-;
aaaand I'm kinda scared since I never jtagged something before and might break the DSO and risk warranty of something that costs more than I can afford over 2 months D:

but IF there's a way for me to read out a memdump and real good fool-proof instruction for complete jtag noobs who are scared to break the device, I'll try my best to get one >_>
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on January 14, 2014, 09:22:54 pm
but IF there's a way for me to read out a memdump and real good fool-proof instruction for complete jtag noobs who are scared to break the device, I'll try my best to get one >_>

this? https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg365951/#msg365951 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg365951/#msg365951)

Only thing I need, is to find out which pins on my ftdi2232h breakout (dangerousprototypes) I need to connect to jtag..
and maybe I need linux, but that can be done in an VM using virtualbox or something I guess, no need for an separate computer.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on January 14, 2014, 09:33:56 pm
maybe a linux live dvd works (though I'm no linux guy AT ALL, I dun really like it lol)
yes, I know the how-to, but recent posts were about the 3V3 connection and that it shouldn't be connected to the pin in the DSO
and I only have seen an old atmel AVR jtag at work, no idea if it's broken or compatible, beside the com/sub-d port XD
troubles XD
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on January 14, 2014, 09:35:12 pm
What is the behavior of non-A-models on bandwidth upgrades?

It changes both the model (DS2072->DS2302) and shows the bandwidth option (300M BandWidth), this on rev 2 hardware.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 14, 2014, 09:38:10 pm
and maybe I need linux, but that can be done in an VM using virtualbox or something I guess, no need for an separate computer.
Can't you also just use a Linux Live-CD/DVD like Knoppix (http://www.knoppix.org/) or similar as an alternative? No installation required.

The LiveCD List http://www.livecdlist.com/operating-system/linux (http://www.livecdlist.com/operating-system/linux)

http://en.wikipedia.org/wiki/Live_CD (http://en.wikipedia.org/wiki/Live_CD)
Quote
A live CD, live DVD, or live disc is a complete bootable computer installation including operating system which runs in a computer's memory, rather than loading from a hard disk drive; the CD itself is read-only. It allows users to run an operating system for any purpose without installing it or making any changes to the computer's configuration. Live CDs can run on a computer without secondary storage, such as a hard disk drive, or with a corrupted hard disk drive or file system, allowing data recovery.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Pehtoori on January 14, 2014, 09:41:44 pm
Only thing I need, is to find out which pins on my ftdi2232h breakout (dangerousprototypes) I need to connect to jtag..
and maybe I need linux, but that can be done in an VM using virtualbox or something I guess, no need for an separate computer.

Might be better to use linux live CD, you can install programs to it, they will be installed to ram. And when you power down all will be gone and back to M$ land you go ;) So save the files to usb or other media before shutting down.

Live CD tools that mess around with HDD will make changes to you windows system, so just don't use them. U can't do it by accident.

<dam I'm slow>
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on January 14, 2014, 09:43:30 pm
Probably, the OS is least of my problems, I can use an raspberry, or my olimex a20 for that if an vm is not usable.

this on the other hand:

http://www.seeedstudio.com/depot/ft2232h-usb-20-hispeed-breakout-board-p-737.html?cPath=19_88 (http://www.seeedstudio.com/depot/ft2232h-usb-20-hispeed-breakout-board-p-737.html?cPath=19_88)

I have it lying here, but not sure what of the connections are for jtag, maybe I will find it on the ftdi datasheet though, but many have used it for jtag, so I don't understand why it's so difficult to find the pinout, my google-foo is expiring..
If the card at all is compatible with urjtag though..


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on January 14, 2014, 09:50:01 pm
I can't tell for sure yet since I don't know enough about it: I just tried some keys of a DSO that has the same production week as mine
and I got "license unavailable"
so it seems a memdump IS needed for every a-series DSO
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pascal_sweden on January 14, 2014, 10:03:50 pm
The distributor in Sweden offers both the DS2072 and DS2072A model at this point in time.

In fact they throw in a discount for the old DS2072 version.
But there is no confirmation if it is HW version 2 or not. I could ask them though.

For my understanding, is DS2072A much improved or only improvement on internal impedance switch?
Or is the overall design improved?

I would like to see summary table with difference between DS2072 HW1, DS2072 HW2 and DS2072A to get overall picture all at once.

Can DS2072 HW version 1 be upgraded to 200 MHz only or up to 300MHz? Verified with actual measurements on scope to double check if it really works and not only in GUI?
Which decoding/memory options can be added?

Can DS2072 HW version 2 be upgraded to 200 MHz only or up to 300MHz? Verified with actual measurements on scope to double check if it really works and not only in GUI?
Which decoding/memory options can be added?

Can DS2072A be upgraded to 200 MHz only or up to 300MHz? Verified with actual measurements on scope to double check if it really works and not only in GUI?
Which decoding/memory options can be added?
I understand that DS2072A might require individual memory dump to do actual upgrade for time being, but still I like to know if HW is capable of the upgrade. Then I can wait until the generic hack is in place, as I dont want to open my scope. But I need to know if DS2072A can be made 100% same as DS2302A.

Did anyone do visual inspection of actual PCB boards between DS2072 and DS2302?

Did anyone do visual inspection of actual PCB boards between DS2072A and DS2302A?

Given that people open up their scope for making memory dumps, visual inspection might be done at same time as well :) Of course I realize maybe nobody with a real DS2302 or DS2302A wants to open their big investment :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: battlefield on January 14, 2014, 10:10:58 pm
So after making two memory dumps I'd like to add that if you have 64bit linux stuff has a chance of not wroking. I fixed all of my problems just by putting in live usb with Ubuntu 12.04 32bit and downloaded bfin toolchain, and did the memory dump from ther (with Olimex ARM-USB-OCD it took me about 30 to 45 minutes per dump).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on January 14, 2014, 10:14:52 pm
Q1) For my understanding, is DS2072A much improved or only improvement on internal impedance switch?
Q2) Or is the overall design improved?

Q3) I would like to see summary table with difference between DS2072 HW1, DS2072 HW2 and DS2072A to get overall picture all at once.

Q4) Can DS2072 HW version 1 be upgraded to 200 MHz only or up to 300MHz?
Q5) Verified with actual measurements on scope to double check if it really works and not only in GUI?
Q6) Which decoding/memory options can be added?

Q7) Can DS2072 HW version 2 be upgraded to 200 MHz only or up to 300MHz?
Q8) Verified with actual measurements on scope to double check if it really works and not only in GUI?
Q9) Which decoding/memory options can be added?

Q10) Can DS2072A be upgraded to 200 MHz only or up to 300MHz?
Q11) Verified with actual measurements on scope to double check if it really works and not only in GUI?
Q12) Which decoding/memory options can be added?

Q13) I need to know if DS2072A can be made 100% same as DS2302A.

Q14) Did anyone do visual inspection of actual PCB boards between DS2072 and DS2302?
Q15) Did anyone do visual inspection of actual PCB boards between DS2072A and DS2302A?

 :palm:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 14, 2014, 10:20:53 pm
Given that people open up their scope for making memory dumps, visual inspection might be done at same time as well :) Of course I realize maybe nobody with a real DS2302 or DS2302A wants to open their big investment :)

There are NO DS2302s - of any kind. Neither Rigol - nor any of their distributors - are, at this point in time, selling DS2302As - nor are they selling upgrades to that BW. So we have no way of knowing whether the current hardware revision that ANYONE owns correctly supports (or will EVER correctly support) that BW. You can currently "turn it on" on any non-A model (but it's buggy) and that's about the state of it. Perhaps Rigol is working on a new revision of the hardware right now for future DS2302s - or perhaps they will NEVER sell them.

IMO it's not a good reason to hold off - or make purchasing decisions - since the current DS2000s (v.1 or v.2) have a ~250MHz BW - and the sampling hardware doesn't really support 300MHz well anyway.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pascal_sweden on January 14, 2014, 10:31:59 pm
The Swedish distributor sells the DS2302A:
http://www.instrumentcenter.se/sv/200-500-mhz-bandbredd/rigol-ds2302a-bandbredd-300mhz-2-kanaler-2gsas-minnesdjup-14mpts%28standard%29-56mpts%28option%29-50000-wfmss..php (http://www.instrumentcenter.se/sv/200-500-mhz-bandbredd/rigol-ds2302a-bandbredd-300mhz-2-kanaler-2gsas-minnesdjup-14mpts%28standard%29-56mpts%28option%29-50000-wfmss..php)

Or did I misunderstood your remark about not selling 300MHz version? =)

Note that my questions were just trying to get an overall summary in place on current status of hacks/verifications, as this information is spreaded throughout the forum :)
No need for a hotline :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 14, 2014, 10:47:23 pm
The Swedish distributor sells the DS2302A:
http://www.instrumentcenter.se/sv/200-500-mhz-bandbredd/rigol-ds2302a-bandbredd-300mhz-2-kanaler-2gsas-minnesdjup-14mpts%28standard%29-56mpts%28option%29-50000-wfmss..php (http://www.instrumentcenter.se/sv/200-500-mhz-bandbredd/rigol-ds2302a-bandbredd-300mhz-2-kanaler-2gsas-minnesdjup-14mpts%28standard%29-56mpts%28option%29-50000-wfmss..php)
;D  No - you mean he "advertises" the DS2302A. He'll take your money for one, to be sure! But when will he deliver it? Since none of Rigol's BIG distributors (Tequipment in the US or Batronix here in the EU) - or even Rigol's OWN North American website - are offering them for sale yet, I somehow doubt your Swedish distributor has them in stock. I could be wrong - but if not, you're unlikely to find anyone who has bought one on this board.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pascal_sweden on January 14, 2014, 10:58:19 pm
I have written an email to the distributor to confirm availability =) Will keep you updated!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 14, 2014, 11:06:21 pm
;D  No - you mean he "advertises" the DS2302A. He'll take your money for one, to be sure! But when will he deliver it? Since none of Rigol's BIG distributors (Tequipment in the US or Batronix here in the EU) - or even Rigol's OWN North American website - are offering them for sale yet, I somehow doubt your Swedish distributor has them in stock. I could be wrong - but if not, you're unlikely to find anyone who has bought one on this board.
Batronix has already sold DS2000A models, even though they still only list DS2000 models at their website. I wonder when they will get it updated to say DS2000A.

There's also one in this topic who has already bought a DS2000A-S at a Norwegian distributor, even though this is not listed at Batronix website, let alone the DS2000A models.

So I wouldn't count on Batronix website for info on what available and not available from them, they seem very slow to update their website.

And the Rigol North America website is alo very slow to update info, they don't list andy DS2000A models yet either: http://www.rigolna.com/products/digital-oscilloscopes/ds2000/ (http://www.rigolna.com/products/digital-oscilloscopes/ds2000/)
So I wouldn't trust that website for what's available and what's not available either.

And from what I can tell Tequipment is already offering DS2302A even tough they just write "call us" for price. But their website say they have 3 in stock: http://www.tequipment.net/Rigol/DS2302A/ (http://www.tequipment.net/Rigol/DS2302A/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Flipp on January 14, 2014, 11:08:35 pm

A dump will help.

Im waiting now for my JTAG dongle. Says it has shipped today.

Any other things to do meanwhile?

We´ll have to collect as much keys from mem dumps  as we can. Thats the only chance to find out what scheme is behind the different keys. Uh and we have to give a hell of a lot BRAIN to it. (courageous hero cybernet pronounced many times)

Flip
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 14, 2014, 11:10:32 pm
I have written an email to the distributor to confirm availability =) Will keep you updated!

But you ignored the rest of my point: as mentioned over and over again on these boards, the 2GSa/s rate does not necessarily support 300MHz well - unless Rigol has created a very good Gaussian filter - and there's no evidence that Rigol can do (or has done) this.

People just see "FREE" bandwidth and they think, "Shit, it's free so it has to be good!" But that's not the case - the extra BW can actually cause problems for the fidelity of your instrument. You have to believe that the representation of the waveform that the DSO is presenting is fairly accurate, otherwise what good is it? If the added BW is actually causing interpolation errors at smaller time bases, it's not a help - it's a hindrance.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 14, 2014, 11:11:22 pm
And from what I can tell Tequipment is already offering DS2302A even tough they just write "call us" for price. But their website say they have 3 in stock: http://www.tequipment.net/Rigol/DS2302A/ (http://www.tequipment.net/Rigol/DS2302A/)
Remind me again - which model do you own?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 14, 2014, 11:16:22 pm
Remind me again - which model do you own?
DS1052E  :-[
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 14, 2014, 11:18:53 pm
Remind me again - which model do you own?
DS1052E  :-[

So you can be the first to take the DS2302A plunge? ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 14, 2014, 11:44:54 pm
Just to clarify - here's a chart showing typical BW curves for a 500MHz Nyquist frequency - in other words, the Nyquist frequency of the DS2000 when you have 2 channels ON at max. sampling rate (1GSa/s). Even though most people agree that sin(x)/x should have a sampling rate 2.5x the highest frequency, let's just assume, for simplicity sake, that it can work adequately with 2x. But any frequencies HIGHER than that 2x can cause problems for the interpolation.

The chart shows the hypothetical "brickwall" filter which would be ideal to have (the red line), a maximally flat response curve (the blue line), and a typical Gaussian response curve (the green line). The gray diagonal lines show the area of trouble: where higher-frequency signals can leak through the filter to cause mistakes in the interpolation. With the given response curves, that area is all below -8dB.

On top of this, I've overlaid the results (the yellow line) that someone posted here for the response curve of a 300MHZ "enabled" DS2000 HW v.2.  If these results are correct, the area of filter leakage (the orange diagonal lines) increases to a point above -6dB when using two channels.

I would suggest, for anyone enabling 300MHz on ANY DS2000 - that wants to be certain of signal fidelity (unless/until we see further tests), to use it only with 1 channel @ 2GSa/s (otherwise use the channel BW filter).

(http://www.daysalive.com/share/filter.png)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: George10256 on January 14, 2014, 11:58:22 pm
I think this is an official Rigol shop.  ;)
http://www.rigol-uk.co.uk/Rigol-Digital-Oscilloscopes-DS2302A-p/ds2302a.htm#.UtXHMHmI3E1 (http://www.rigol-uk.co.uk/Rigol-Digital-Oscilloscopes-DS2302A-p/ds2302a.htm#.UtXHMHmI3E1)
And there is one DS2302A in stock.

I have a Rigol DS2072A with serial DS2D1543... seems week 43.
With a Firmware downgrade to 00.01.01. i got a DS2202A with all options using the keygen and DSAZ, so thats no problem.
If i upgrade to Firmware 00.02.01., the scope stay on DS2202A but all options are gone, not even the trial Version remains.

I could check the weekly key for week 43.

I can't tell for sure yet since I don't know enough about it: I just tried some keys of a DSO that has the same production week as mine
and I got "license unavailable"
so it seems a memdump IS needed for every a-series DSO
But it looks like i have to take a memdump. For that i have to order a JTAG dongle, cause i don't have one.
Is there a recommendation for a fast JTAG dongle?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: fqahmad66 on January 15, 2014, 06:13:12 am
Hi,

Can this be used as JTAG dongle?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on January 15, 2014, 06:16:15 am
alright, I'm one step closer ...
I digged in the old hardware oddments of my company's development dept and found an AVR jtag ice mk2
and it's got USB connection, yay (and even an easy to change pinout adapter was attached)
but using google I didn't find any clear information about compatibility with urjtag

can anyone tell me these 2 things: will it work with urjtag and can I safely connect to the DSO's 3V3 pin? (there's also nothing about Vref and Vsupply in the how-to, so I assume they're not connected ... or is UTST or VTST = Vref?)
that would get me a big step closer to dumping the mem ...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on January 15, 2014, 06:38:16 am
alright, I'm one step closer ...
I digged in the old hardware oddments of my company's development dept and found an AVR jtag ice mk2
and it's got USB connection, yay (and even an easy to change pinout adapter was attached)
but using google I didn't find any clear information about compatibility with urjtag

can anyone tell me these 2 things: will it work with urjtag and can I safely connect to the DSO's 3V3 pin? (there's also nothing about Vref and Vsupply in the how-to, so I assume they're not connected)
that would get me a big step closer to dumping the mem ...

http://urjtag.org/book/_system_requirements.html#_supported_jtag_adapters_cables (http://urjtag.org/book/_system_requirements.html#_supported_jtag_adapters_cables)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: poida_pie on January 15, 2014, 07:14:26 am
Marmad, where did you get the DS2000 b/w response data that extends up to 1 GHz? Was this data posted here on this board?


(http://www.daysalive.com/share/filter.png)
[/quote]
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on January 15, 2014, 08:34:03 am
@neslekkim: I've seen that, along with this: http://sourceforge.net/apps/mediawiki/urjtag/index.php?title=Cables (http://sourceforge.net/apps/mediawiki/urjtag/index.php?title=Cables)
but I'm still not smarter than before XD

ok, adapter nearly done, I don't know what the UTST or VTST pin is ... I suppose it's Vref?
(Vref is the name of the pin on the AVR jtag connector)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Pehtoori on January 15, 2014, 09:06:57 am
I would like to see summary table with difference between DS2072 HW1, DS2072 HW2 and DS2072A to get overall picture all at once.
How about you make one and share with us?
Quote
Given that people open up their scope for making memory dumps, visual inspection might be done at same time as well :)
Look pictures and comments in this and other threads
Quote
Note that my questions were just trying to get an overall summary in place on current status of hacks/verifications, as this information is spreaded throughout the forum :)
To get overall summary you need only information of this thread, no other threads needed.
Quote
Then I can wait until the generic hack is in place, as I dont want to open my scope.
???  :palm:

You don't want to read this thread, do the summary table, open your scope. Just to be clear, what will be your contribution?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Pehtoori on January 15, 2014, 09:16:42 am
Got my scope now, waiting for JTAG. Should be in customs atm.

Serial: DS2D1542***** so from week 42.

If dump from this puppy isn't needed, I don't expect free lunch. I can donate 50€ (~65$) before getting the keys. Money can be used towards buying genuine key or something else.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Posterisan on January 15, 2014, 09:55:59 am
Got my scope DS2072A yesterday, Serial # DS2D1542.....

I try to dump with Segger J-Link this evening, but i read the segger jlink is extreme slow  :(
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ju1ce on January 15, 2014, 10:22:58 am
Got my scope DS2072A yesterday, Serial # DS2D1542.....

I try to dump with Segger J-Link this evening, but i read the segger jlink is extreme slow  :(
My J-Link dump is progressing at a whopping 1% per hour at the moment... Oh well, still faster than buying another JTAG tool and waiting for it to arrive.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on January 15, 2014, 11:49:45 am
so, since you're taking dumps (lol) ... where did you connect the UTST/VTST (can't tell if it's U or V lol) to?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on January 15, 2014, 12:06:29 pm
Did you read the guide at all?

"Ignore the confusing pin UTST I guess cybernet used it just to probe the voltage."
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on January 15, 2014, 01:08:38 pm
don't laugh, I stopped reading after "have an ARM 20 pin connector" ...  :-DD

ok, so my cable is done ^^
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sled on January 15, 2014, 01:34:51 pm
Rigol can't afford to ignore the hacks, but they would be wise to view them as an opportunity rather than an attack.

It would be very wise for us if we did not bite the hand that feeds us by making the hacks too easy to use.  There needs to be a minimum amount of skill required to accomplish the hacks.  I don't know what this skill level should be, but making web apps capable of providing valid keys by providing a serial number and a four character option code is definitely something that I would consider "biting the hand that feeds us."

Exactly what happened, the skill level required is to dump the memory via JTAG ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: granz on January 15, 2014, 04:03:24 pm
I'm somewhat amazed at the confusion involving JTAG.  The original DS2k pinout image is confusing.  It makes it look like you need to APPLY 3.3V to what he labeled as UTST (wrong label) from another point on the board.  Do NOT do this, because you may be tying two separate regulated outputs together on the RIGOL board.  I've reworked the JTAG image to show how you should be connecting your JTAG adapter.  If the tutorial author is reading, the tutorial should be corrected.

Be sure to check the signal levels on your JTAG adapter before attaching anything, some don't use a VREF voltage and have a jumper or something instead to set the levels.  Much older JTAG adapters especially might use 5V.  Everyone obviously has a scope, so it only takes a few minutes to be safe if you are just using something you had lying around.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on January 15, 2014, 04:36:15 pm
I still don't understand the connection XD
what's high-Z output and what to attach there?

so I HAVE to connect to Vref from the jtag lik eI thought before?

linux is a PITA atm, it's not that simple to run the bfin program as written in the how-to
it's missing additional software -_-;
glibc, I have 2.13 here ... it needs 2.14 and/or 2.15 -_-
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: granz on January 15, 2014, 04:41:09 pm
See updated attachment.  VREF comes from the board and goes into your adapter.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on January 15, 2014, 04:44:00 pm
ahh, so the difference is that pin 1 will not be connected and trst and tsrt are hard to see now (but still connected?)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Posterisan on January 15, 2014, 04:46:22 pm
I need help with mit Segger j-link.

If i try to run bfin-gdbproxy i got:

Code: [Select]
C:\Program Files (x86)\Analog Devices\GNU Toolchain\2013R1\uclinux\bin>bfin-gdbp
roxy --debug bfin --frequency=5000000

Remote proxy for GDB, v0.7.2, Copyright (C) 1999 Quality Quorum Inc.
MSP430 adaption Copyright (C) 2002 Chris Liechti and Steve Underwood
Blackfin adaption Copyright (C) 2008 Analog Devices, Inc.

GDBproxy comes with ABSOLUTELY NO WARRANTY; for details
use `--warranty' option. This is Open Source software. You are
welcome to redistribute it under certain conditions. Use the
'--copying' option for details.

debug:     bfin: bfin_open ()
Found USB cable: jlink
error:     bfin: cable initialization failed
debug:     bfin: bfin_open ()
Found USB cable: jlink
error:     bfin: cable initialization failed

3.3V from SPI are connected to VRef (Segger Pin 1)
Only TRST and SRST are not connected to the segger jlink.
OS is Windows 8 - 64Bit.

Any ideas?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: granz on January 15, 2014, 04:54:18 pm

3.3V from SPI are connected to VRef (Segger Pin 1)
Only TRST and SRST are not connected to the segger jlink.
OS is Windows 8 - 64Bit.

Any ideas?

Try connecting with the generic UrJTAG from here first: http://sourceforge.net/projects/urjtag/files/urjtag/0.10/ (http://sourceforge.net/projects/urjtag/files/urjtag/0.10/)

If it sees the cable with the generic version then you'll probably have to switch to 32-bit Linux to get the blackfin toolchain version to see it.

Also, TRST and SRST must either be connected to your JTAG adapter or pulled-up with resistors, see diagram above.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Posterisan on January 15, 2014, 05:08:35 pm
Try connecting with the generic UrJTAG from here first: http://sourceforge.net/projects/urjtag/files/urjtag/0.10/ (http://sourceforge.net/projects/urjtag/files/urjtag/0.10/)

If it sees the cable with the generic version then you'll probably have to switch to 32-bit Linux to get the blackfin toolchain version to see it.

Also, TRST and SRST must either be connected to your JTAG adapter or pulled-up with resistors, see diagram above.
TRST and SRST are pulled-up 10k/3k9 to 3.3V.

I tried urjtag - doesnt work :
Code: [Select]
jlink         Segger/IAR J-Link, Atmel SAM-ICE and others.
jtag> cable jlink
Couldn't connect to suitable USB device.
Error: Cable connection failed!
jtag>

if i try the the segge commander i got:
Code: [Select]
SEGGER J-Link Commander V4.80a ('?' for help)
Compiled Jan 10 2014 21:21:55
DLL version V4.80a, compiled Jan 10 2014 21:21:47
Firmware: J-Link ARM V8 compiled Nov 25 2013 19:20:08
Hardware: V8.00
S/N: xxxxxxx
OEM: SEGGER-EDU
Feature(s): FlashBP, GDB
VTarget = 3.377V
Info: TotalIRLen = 5, IRPrint = 0x01
Info: TotalIRLen = 5, IRPrint = 0x01
Info: TotalIRLen = 5, IRPrint = 0x01
No devices found on JTAG chain. Trying to find device on SWD.
No device found on SWD.

i try linux  :(
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on January 15, 2014, 05:31:34 pm
I fail to update the f*cking glibc from 2.13 to something newer (2.18 is current version) -_-
it's not in the repositories ...

wasting hours with linux and stuff gah.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: battlefield on January 15, 2014, 06:23:18 pm
I actually connected pin 1 from the JTAG header with the 3.3V pin from the 4 pin header on the other side of the board and also to my JTAG adapter and it worked perfectly fine and so does the scope (especially now when I have everything unlocked :D)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: granz on January 15, 2014, 06:30:12 pm
Yes, it probably will work.  I'm just saying it's a BAD IDEA.  Just because it happens to work doesn't mean it is correct.  You shouldn't be connecting two separate regulated outputs together.  There is probably just a fairly high value resistor in series with the 3.3V pin on the JTAG header.

See this:

http://electronics.stackexchange.com/questions/55270/is-it-ok-to-connect-the-output-of-buck-regulator-in-parallel (http://electronics.stackexchange.com/questions/55270/is-it-ok-to-connect-the-output-of-buck-regulator-in-parallel)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on January 15, 2014, 07:07:20 pm
ok, please help D:
I'm currently trying to find out if the avr jtagice mk2 can actually be used with blackfin ...
is jtag interface = jtag interface?
or are there special jtag interfaces?
I don't know yet how to connect with the gdbproxy, I read somewhere that WIGGLER is compatible with the avr jtagice mk2, but I don't see anything about how to use it -_-
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pascal_sweden on January 15, 2014, 07:38:17 pm
I have received feedback from the Swedish distributor that the DS2072 which is on sales (special offer as DS2072A replaces the old model) is in fact HW version 2.

Is it worth to buy the HW version 2? Or is the A version even better?
What is missing in the old HW version 2?

I understand that HW version 2 is easy to hack in current FW version, but does only go up to 200MHz.
And in future FW versions it could be as difficult as on the A version, which might go up to 300MHz?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Posterisan on January 15, 2014, 07:44:07 pm
I installed Ubuntu 32-Bit and the blackfin toolchain, still no jtag connection with my segger j-link.

Linux output:

Code: [Select]
debug:     bfin: bfin_open ()
Found USB cable: jlink
J-Link initial read failed, don't worry (result=0)
Vref = 3.371 TCK=0 TDI=0 TDO=1 TMS=0 TRES=1 TRST=0
J-Link JTAG Interface ready
warning: TDO seems to be stuck at 1
error:     bfin: detecting parts failed
debug:     bfin: bfin_open ()
Found USB cable: jlink
error:     bfin: cable initialization failed

double checked all cable connections.  :( i have no idea whats wrong.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on January 15, 2014, 08:01:09 pm
Rigol can't afford to ignore the hacks, but they would be wise to view them as an opportunity rather than an attack.

It would be very wise for us if we did not bite the hand that feeds us by making the hacks too easy to use.  There needs to be a minimum amount of skill required to accomplish the hacks.  I don't know what this skill level should be, but making web apps capable of providing valid keys by providing a serial number and a four character option code is definitely something that I would consider "biting the hand that feeds us."



Exactly what happened, the skill level required is to dump the memory via JTAG ;)

except if there would magically appear a tool to dump stuff without need for jtag ... *cough*
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Pehtoori on January 15, 2014, 08:14:33 pm
I fail to update the f*cking glibc from 2.13 to something newer (2.18 is current version) -_-
it's not in the repositories ...

wasting hours with linux and stuff gah.

Might not be good idea to try upgrade glibc. Kind of fundamental foundation of the system. And you have to maintain binary compatibility.

So use newer live CD and spare your self from trouble.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on January 15, 2014, 08:17:14 pm
Pehtoori: too late XD
but I guess the JTAGICE mk2 is not supported -_-
damn, wasted time :/

cybernet: yeah, send it already ;P
*cough* ^^

I don't find any supported interface in germany
the next I see is the olimex from the UK via ebay ...
or shops want 25+ EUR extra ...
I'll never need a jtag again in the future D:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Pehtoori on January 15, 2014, 08:19:07 pm

Exactly what happened, the skill level required is to dump the memory via JTAG ;)

except if there would magically appear a tool to dump stuff without need for jtag ... *cough*

There is no magic involved, but hard work of respectable guru ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: granz on January 15, 2014, 08:55:33 pm

I don't find any supported interface in germany
the next I see is the olimex from the UK via ebay ...
or shops want 25+ EUR extra ...
I'll never need a jtag again in the future D:


6,99 euro:

http://www.ebay.de/itm/USB-Blaster-Programmer-W-Cable-for-ALTERA-FPGA-CPLD-JTAG-Development-Board-AS-PS-/251282935520?pt=Wissenschaftliche_Ger%C3%A4te&hash=item3a81a14ee0 (http://www.ebay.de/itm/USB-Blaster-Programmer-W-Cable-for-ALTERA-FPGA-CPLD-JTAG-Development-Board-AS-PS-/251282935520?pt=Wissenschaftliche_Ger%C3%A4te&hash=item3a81a14ee0)

Added benefit of allowing you to get started with Altera FPGAs.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on January 15, 2014, 08:56:25 pm
except if there would magically appear a tool to dump stuff without need for jtag ... *cough*

Excellent.   :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on January 15, 2014, 09:02:35 pm
yeah, seen the chinese thing XD look at shipping date :)
oh well, let's wait some more ... :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: granz on January 15, 2014, 09:03:18 pm

On top of this, I've overlaid the results (the yellow line) that someone posted here for the response curve of a 300MHZ "enabled" DS2000 HW v.2.  If these results are correct, the area of filter leakage (the orange diagonal lines) increases to a point above -6dB when using two channels.

I would suggest, for anyone enabling 300MHz on ANY DS2000 - that wants to be certain of signal fidelity (unless/until we see further tests), to use it only with 1 channel @ 2GSa/s (otherwise use the channel BW filter).

(http://www.daysalive.com/share/filter.png)

Marmad, thanks for posting this.  This is what I was concerned about with all the unlocking going on, but I never saw the source of the yellow trace.  Once I find (or borrow) a higher frequency signal generator I'll try to collect some more data from my (now unlocked) DS2072A and post.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 15, 2014, 09:22:24 pm
Marmad, thanks for posting this.  This is what I was concerned about with all the unlocking going on, but I never saw the source of the yellow trace.  Once I find (or borrow) a higher frequency signal generator I'll try to collect some more data from my (now unlocked) DS2072A and post.

No problem. I think it's important to find out how low >= 500MHz signals are when the 300MHz option is enabled. Rigol doesn't have the greatest skills at designing filters - and I have to think market pressures (GW-Instek and Siglent releasing 300MHz low-cost DPO models) and the desire to have "new" features for the A-model were the driving reasons behind the new BW - rather than their touted "New input stage" :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: poida_pie on January 15, 2014, 09:38:25 pm
Marmad, I asked before but maybe you overlooked it, but can you tell me where you got the data for the yellow trace?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on January 15, 2014, 09:52:55 pm

Exactly what happened, the skill level required is to dump the memory via JTAG ;)

except if there would magically appear a tool to dump stuff without need for jtag ... *cough*

That would be great!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on January 15, 2014, 09:56:03 pm
except if there would magically appear a tool to dump stuff without need for jtag ... *cough*

or a firmware that forces A model to use non-A license decoder... *cough cough*
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 15, 2014, 09:59:02 pm
Marmad, I asked before but maybe you overlooked it, but can you tell me where you got the data for the yellow trace?
Sorry - I did miss your previous post - this thread moves so fast sometimes it's hard to keep up ;)  And yes, the info was posted by PA0PBZ over in the DS2000 review thread (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg362940/#msg362940) - but I questioned whether it was accurate or not at the time.

His test(s) indicate a -3dB BW of ~390MHz, but in order to avoid possible interpolation errors, I would hope that Rigol actually tried to get the -3dB BW as close to 300MHz as possible. Of course, he only tested until around ~500MHz - my chart just extrapolates a further Gaussian response based on his numbers - but we certainly need more tests by more people to get a better handle on the situation. More BW above the Nyquist frequency is not a good thing - it's a bad thing.

Here is his chart:

(https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/?action=dlattach;attach=75269)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 15, 2014, 10:16:15 pm
except if there would magically appear a tool to dump stuff without need for jtag ... *cough*
or a firmware that forces A model to use non-A license decoder... *cough cough*
Will the 50 ohm input option still work then as it's only on the A models originally?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on January 16, 2014, 12:56:27 am
Will the 50 ohm input option still work then as it's only on the A models originally?

I think so, because it doesn't change model type, just license decoding method. However, I haven't tested it yet, because I'm still waiting for "A" scope availability in my area.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: poida_pie on January 16, 2014, 01:13:24 am
"More BW above the Nyquist frequency is not a good thing - it's a bad thing."

Totally agree. We need someone to take a DS2000, modded to 300 MHz and check response to 1 GHz (2 channels).
Any signal over Nyquist freq. limits will reappear as an alias. For peace of mind I would also like the test to be done on a 200 Mhz modded unit. We need to see just how steep the dropoff of the LMH6518 is at 500Mhz and above.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 16, 2014, 01:29:00 am
For peace of mind I would also like the test to be done on a 200 Mhz modded unit. We need to see just how steep the dropoff of the LMH6518 is at 500Mhz and above.
Well, there have been a couple of tests done by people with 200Mhz on v.1 HW that indicate that the -3dB point is ~240MHz, with 500MHz about ~15dB down. Even at 300MHz the rolloff looks pretty good (although the v.1 HW might not quite reach 300MHz by -3dB), so I still have doubts as to whether the data I used in my chart is accurate.

(https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/?action=dlattach;attach=73142;image)

(https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/?action=dlattach;attach=72988;image)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on January 16, 2014, 07:14:34 am
We need to see just how steep the dropoff of the LMH6518 is at 500Mhz and above.

The specs for the LH6518 indicate in 350 MHz mode it is down only 10 dB at 960 MHz, -7.5 dB ~750 MHz, -5 dB ~550 MHz, and -3 dB ~380 MHz.  Of course, other components affect the aggregate bandwidth.

For comparison, in 200 MHz mode, it's spec indicates -10 dB ~750 MHz, -5 dB ~300 MHz, and -3 dB ~200 MHz.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Marc M. on January 16, 2014, 08:39:16 am
Good news Everyone!  Attached to this post is a utility to repair corrupted S/N's on DS2000 series scopes!  Someone I know took up the challenge to write a utility to repair corrupted serial numbers as their contribution to all the great work done so far.  It's a simple but very clever Windows .exe file that will ask your model/serial # and modify a .gel file located in the same directory as the executable file.  Note: This utility only works with firmware version 00.01.01.00.02.  If you need a copy of this firmware version, see Marmad's post (Reply #2) in this thread: https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/ (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/)  The locations of the model & S/N change between firmware versions so it will corrupt any other version of firmware so verify that you have firmware version 00.01.01.00.02.  It also requires the ability to send SCPI commands to the scope.


Instructions for Use:
SNMODFIX

Use at your own risk - not sure if safe with A models with unknown model values
It is only advised to use this on scopes with a mangled 14 digit DS2A0000000001
to fix what the scope messed up, your model type might be unknown or wrong and
could be overwritten with the wrong value by doing this.


1.  Requires 00.01.01.00.02 firmware (7777543 bytes, 0xa167ef30 crc32) named
       DS2000Update.gel in same directory as executable
2.  Execute snmodfix and specify serial and model to patch firmware
3.  Flash patched ds2000update.gel using power on help button method
4.  Restart scope
5.  Enable advanced system information menu (press Trigger Menu, Menu 7,
       Menu 6, Menu 7, Utility
very quickly) to enable it
6.  Show system information - serial should be fixed but NOT saved to flash
      yet - some text labels will be missing
7.  Connect using scpi and issue :SYSTem:OPTion:UNINSTall command which will
      uninstall all keys and save to flash
8.  Once settled restart scope
9.  Show system information (not advanced) should now show the correct serial
      and model
10. Update to latest stock unpatched firmware version
11. Storage -> Default
12. Reinstall any key(s)


Tested on several DS2072's w/ original hardware and it works perfectly.  Again, this has not been tested on any hardware versions other than 1.0.  Please don't ask about a Linux version as neither of us are Linux users.  Also, I don't have the source code as the author didn't offer it.  I'm very grateful for his work and won't pester him for the source code.  If you have any issues/suggestions/comments please feel free to contact me.
Edit: Corrected firmware link
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MrKrabs on January 16, 2014, 10:24:17 am
Hey cybernet,

I was reverse engineering your reverse engineering :), trying to port your DS4000 firmware hack which is version 00.02.00.00.04 to the latest version 00.02.01.00.03.

I was able to find the 2 magic bytes to modify (0x4899 into 0x2060) in the new firmware and then recalculated the CRC for section 00.

Then I updated the firmware on my DS4014 with my patched firmware. The update worked fine (I know because I had a 00.01.xx firmware), BUT it didn't enable the BW options neither gave me 1ns TB option.

I then went back to your 00.02.00.00.04 firmware and confirmed it enabled the BW options & 1ns TB, so I know it works on my DS4K.

Do you have any idea what the deal is with the latest DS4K firmware? I found the 0x4899 byte at 0x128a3c. It at least matched the nearby bytes almost perfectly when comparing with your firmware.

There's a big chance, of course, I was just changing the wrong bytes :)

Here's a diff of the hexdumps:

Code: [Select]
$ diff DS4000Update.00.02.01.00.03.orig.GEL.hex DS4000Update.00.02.01.00.03.modified.GEL.hex
4c4
< 00000030  32 62 77 f0 00 00 00 00  00 00 04 20 01 00 00 00  |2bw........ ....|
---
> 00000030  5d 10 2a 87 00 00 00 00  00 00 04 20 01 00 00 00  |].*........ ....|
75940c75940
< 00128a30  00 e8 00 00 09 e1 2d 0d  49 e1 e7 00 48 99 01 e8  |......-.I...H...|
---
> 00128a30  00 e8 00 00 09 e1 2d 0d  49 e1 e7 00 20 60 01 e8  |......-.I... `..|

Cheers!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 16, 2014, 12:45:08 pm
Note: This utility only works with firmware version 00.01.01.00.02.  If you need a copy of this firmware version, see Marmad's post (Reply #2) in this thread: https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/ (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/)
Nice work.

The same FW 00.01.01.00.02 can also be downloaded here: http://rigol.avotronics.co.uk/ds2000-series/ (http://rigol.avotronics.co.uk/ds2000-series/)


Nice summary. andyturk (the OP) should copy and paste a link to this post in the first post of the thread.
Good idea. Done.
@andyturk (the OP) maybe you should also add a link to Marc M's SNMODFIX utility in the OP too, to make it easier to find.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Altemir on January 16, 2014, 01:22:36 pm
MrKrabs
BW options on DS4000?  :wtf: Can you upload screenshots of this options and photo of your DSO? You has got 500MHz on 100MHz DS4014???  :o
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 16, 2014, 01:33:16 pm
MrKrabs
BW options on DS4000?  :wtf: Can you upload screenshots of this options and photo of your DSO? You has got 500MHz on 100MHz DS4014???  :o

It's not actually an "option" - but yes, changing the model number internally on a DS4000 (and all - at least for the initial HW versions - of the other Rigol products in the DS/DG families) changes the bandwidth and/or enabled options. cybernet made a modified FW GEL file for the DS4000 (using FW v.02.00.00.04) which, when loaded, changes the model number - and thus the bandwidth.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Altemir on January 16, 2014, 01:38:35 pm
It's not actually an "option" - but yes, changing the model number internally on a DS4000 (and all - at least for the initial HW releases - of the other Rigol products in the DS/DG families) changes the bandwidth and/or enabled options. cybernet made a modified FW GEL file for the DS4000 (using FW v.02.00.00.04) which, when loaded, changes the model number - and thus the bandwidth.
If I had a custom firmware for the MSO4024, I would be able to measure the frequency response of up to 2GHz.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 16, 2014, 01:47:57 pm
cybernet made a modified FW GEL file for the DS4000 (using FW v.02.00.00.04) which, when loaded, changes the model number - and thus the bandwidth.
The DL link for cybernet's custom DS4000/MSO4000 firmware posted here (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg338111/#msg338111) doesn't work anymore though.

download, rename to DS4000Update.GEL -> http://www.filedropper.com/ds405xupdate (http://www.filedropper.com/ds405xupdate)
Can anyone upload it again, maybe here: https://mega.co.nz (https://mega.co.nz)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cosmos on January 16, 2014, 01:50:06 pm
made a modified FW GEL file for the DS4000 (using FW v.02.00.00.04) which, when loaded, changes the model number - and thus the bandwidth.
The DL link for cybernet's custom firmware posted here (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg338111/#msg338111) doesn't work anymore though.

download, rename to DS4000Update.GEL -> http://www.filedropper.com/ds405xupdate (http://www.filedropper.com/ds405xupdate)
Can anyone upload it again, maybe here: https://mega.co.nz (https://mega.co.nz)

http://wikisend.com/download/134080/DS405XUpdate.zip (http://wikisend.com/download/134080/DS405XUpdate.zip)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 16, 2014, 01:58:21 pm
Thanks cosmos

If I had a custom firmware for the MSO4024, I would be able to measure the frequency response of up to 2GHz.
1) Just download cybernet's custom 00.02.00.00.04 based DS4000/MSO4000 FW [Filename DS405XUpdate_00.02.00.00.04.zip] here: http://rigol.avotronics.co.uk/msods4000-series/ (http://rigol.avotronics.co.uk/msods4000-series/)

2) Then follow the cybernet's instructions posted here (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg338111/#msg338111).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 16, 2014, 02:11:23 pm
1) Just download cybernet's custom 00.02.00.00.04 based DS4000/MSO4000 FW from the link cosmos just provided: http://wikisend.com/download/134080/DS405XUpdate.zip (http://wikisend.com/download/134080/DS405XUpdate.zip)

2) Then follow the cybernet's instructions posted here (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg338111/#msg338111).
Has this been confirmed to work on an MSO4000?

Unless it has, I don't think I'd risk changing my MSO model number into a DS model number.

EDIT: I just saw that in cybernet's original post he mentions that it will leave the 'MSO' part of the number intact - but have there been any MSO users that have used it yet?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on January 16, 2014, 02:19:53 pm
Can I have confirmed please:

Is the DS405XUpdate only for DS405X models or all DS4000.
I'm not reading the whole thread, I just need to know where to put it on my rigol site.

Thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on January 16, 2014, 02:20:48 pm

2) Then follow the cybernet's instructions posted here (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg338111/#msg338111).

There the geltool is mentioned again, where do one find that?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 16, 2014, 02:22:28 pm
Is the DS405XUpdate only for DS405X models or all DS4000.
I'm not reading the whole thread, I just need to know where to put it on my rigol site.

According to cybernet's post, any DS4/MSO4 - changing only the digit of the model number (0x4 = 500mhz) which specifies bandwidth (but no guarantees).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on January 16, 2014, 02:25:22 pm
Is the DS405XUpdate only for DS405X models or all DS4000.
I'm not reading the whole thread, I just need to know where to put it on my rigol site.

According to cybernet's post, any DS4/MSO4 - changing only the digit of the model number (0x4 = 500mhz) which specifies bandwidth (but no guarantees).

Thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on January 16, 2014, 02:33:13 pm
Cybernet's modded firmware can be found here permanently.
Sorry, direct linking isn't available.

http://rigol.avotronics.co.uk/msods4000-series/ (http://rigol.avotronics.co.uk/msods4000-series/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 16, 2014, 02:52:01 pm
Has this been confirmed to work on an MSO4000?
Can't remember if anyone has tested it on an MSO4000, but I'm pretty sure it does work as DS and MSO models use the same firmware.
cybernet also wrote it works with both DS4000 and MSO4000 and also both 2 and 4 channel models:
this sets model type 0x4 = 500mhz
(whatever channel#, whatever MSO y/n it leaves that intact)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 16, 2014, 02:56:09 pm
Cybernet's modded firmware can be found here permanently.
Sorry, direct linking isn't available.

http://rigol.avotronics.co.uk/msods4000-series/ (http://rigol.avotronics.co.uk/msods4000-series/)
Thanks.
You should probably host Marc M's snmodfix.zip and guide for DS2000 S/N restoration too.
And also the JTAG memory dump guide posted earlier.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 16, 2014, 03:09:22 pm
cybernet also wrote it works with both DS4000 and MSO4000 and also both 2 and 4 channel models:

Not quite: cybernet wrote:

anyhow no guarantees for anything like always  ...

You might just mention that when steering people towards something which, as far as I know, is untested on an MSO4. If it goes wrong it can be a costly and/or time-consuming problem to fix - not for you - but for the person you steered.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 16, 2014, 03:15:22 pm
I have received feedback from the Swedish distributor that the DS2072 which is on sales (special offer as DS2072A replaces the old model) is in fact HW version 2.

Is it worth to buy the HW version 2? Or is the A version even better?

As I recommended to you in another thread which you started, unless you want an S-model (with the AWG) - if you can get the non-A HW v.2 model, IMO, that's what you should get. The hardware is the same - and you'll be able to upgrade to any new firmware while keeping all of your unpaid-for options. OTOH, the A-model owners MAY need some new hacking with every new version of FW released to avoid losing their options.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MrKrabs on January 16, 2014, 04:57:18 pm

2) Then follow the cybernet's instructions posted here (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg338111/#msg338111).

There the geltool is mentioned again, where do one find that?

cybernet hasn't released it (yet?). I modified the firmware by hand :(
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MrKrabs on January 16, 2014, 04:59:07 pm
Can I have confirmed please:

Is the DS405XUpdate only for DS405X models or all DS4000.
I'm not reading the whole thread, I just need to know where to put it on my rigol site.

Thanks

Please upload this one too:

http://www.wikisend.com/download/436838/DS4000update_00.02.01.00.03.zip (http://www.wikisend.com/download/436838/DS4000update_00.02.01.00.03.zip) (original firmware, latest version)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Altemir on January 16, 2014, 05:10:37 pm

Please upload this one too:

http://www.wikisend.com/download/436838/DS4000update_00.02.01.00.03.zip (http://www.wikisend.com/download/436838/DS4000update_00.02.01.00.03.zip) (original firmware, latest version)
I have putted it version to first post of topic Rigol MSO4000 and DS4000. Tests, bugs, firmware, questions, etc... (https://www.eevblog.com/forum/testgear/rigol-mso4000-and-ds4000-tests-bugs-firmware-questions-etc/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on January 16, 2014, 06:45:59 pm
One of the forum members tested my DS2k 00.02.01.00.03 firmware patch and reported that it works fine, ie. allows to use the old keygen with A scopes without any problems. This patch is a temporary solution for those who cannot or don't want to do memory dumps (at least until it's possible via USB). Of course extracting keys from memory is still preferred method, because license codes created this way should work even with future official firmware releases.

So, enjoy  ;)
https://mega.co.nz/#!FFk10SCY!UuWPXyqZwmca00pa2clOth1ryh1Z-AAgJg2yibfoUw0
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 16, 2014, 06:50:51 pm
One of the forum members tested my DS2k 00.02.01.00.03 firmware patch and reported that it works fine, ie. allows to use the old keygen with A scopes without any problems.
Nice. And the 50 ohm input option still works?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on January 16, 2014, 06:55:37 pm
One of the forum members tested my DS2k 00.02.01.00.03 firmware patch and reported that it works fine, ie. allows to use the old keygen with A scopes without any problems.

Out of curiosity (don't have an A scope myself), what happens if you load the custom firmware, use a non-A key, then upgrade to stock firmware?  Do the options stay?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on January 16, 2014, 07:01:19 pm
One of the forum members tested my DS2k 00.02.01.00.03 firmware patch and reported that it works fine, ie. allows to use the old keygen with A scopes without any problems.
Nice. And the 50 ohm input option still works?

Here is quote from his mail:

Quote
I did this to verify your patched firmware:

-- Used SYSTEM:UNINSTALL to remove all my current options that I got using tirulerbach's rigup keygen (verified back to trial versions etc.)
-- Flashed your patched GEL
-- Installed DSHH key from riglol 1.03c

50 Ohm option + serial etc. are all intact.  I have 2ns
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: granz on January 16, 2014, 07:25:50 pm

There the geltool is mentioned again, where do one find that?

cybernet hasn't released it (yet?). I modified the firmware by hand :(

Based on my own dissection of the .GEL files I wrote a small "de-GEL-ing" program for my own use (this is unrelated to cybernet's geltool).  I haven't determined what all of the fields are, but the overall structure is correct and it will do CRC-ing for you on the .GEL file.  It's not very sophisticated, as I didn't originally intend to post it.  I've tested on DS2000 and DS4000 .GEL files but nothing else.  After you have the individual sections you can use bfin-objdump to disassemble (see note at top of .c file).

https://mega.co.nz/#!Nx10QALC!ZZ1-0mPUxjAxB0gvgI0YdSzZ-7hJBBUtQPqBR7OYw-s

Here's an example run:

Code: [Select]

$ ./degel DS2000Update_00.02.01.00.03.GEL

Model Name:          DS2202
Software Version:    00.02.01.00.03
Number of Sections:  19

Sec 00: GEL Offset: 0x0000023c (     572) Len: 0x00326e00 ( 3304960) Addr: 0x20040000 [CHECK PASSED]
Sec 01: GEL Offset: 0x0032703c ( 3305532) Len: 0x0017be32 ( 1556018) Addr: 0x20000000 [CHECK PASSED]
Sec 02: GEL Offset: 0x004a2e6e ( 4861550) Len: 0x00010f60 (   69472) Addr: 0x20000000 [CHECK PASSED]
Sec 03: GEL Offset: 0x004b3dce ( 4931022) Len: 0x00035438 (  218168) Addr: 0x20123000 [CHECK PASSED]
Sec 04: GEL Offset: 0x004e9206 ( 5149190) Len: 0x0000245a (    9306) Addr: 0x20173000 [CHECK PASSED]
Sec 05: GEL Offset: 0x004eb660 ( 5158496) Len: 0x000c6c14 (  814100) Addr: 0x20020000 [CHECK PASSED]
Sec 06: GEL Offset: 0x005b2274 ( 5972596) Len: 0x00014d04 (   85252) Addr: 0x200c8000 [CHECK PASSED]
Sec 07: GEL Offset: 0x005c6f78 ( 6057848) Len: 0x000663f4 (  418804) Addr: 0x200f0000 [CHECK PASSED]
Sec 08: GEL Offset: 0x0062d36c ( 6476652) Len: 0x00001d54 (    7508) Addr: 0x20120000 [CHECK PASSED]
Sec 09: GEL Offset: 0x0062f0c0 ( 6484160) Len: 0x0006a30a (  434954) Addr: 0x20000000 [CHECK PASSED]
Sec 10: GEL Offset: 0x006993ca ( 6919114) Len: 0x000032d8 (   13016) Addr: 0x20040000 [CHECK PASSED]
Sec 11: GEL Offset: 0x0069c6a2 ( 6932130) Len: 0x00000b64 (    2916) Addr: 0x20000000 [CHECK PASSED]
Sec 12: GEL Offset: 0x0069d206 ( 6935046) Len: 0x0003c598 (  247192) Addr: 0x20000c00 [CHECK PASSED]
Sec 13: GEL Offset: 0x006d979e ( 7182238) Len: 0x00000118 (     280) Addr: 0x201e4c00 [CHECK PASSED]
Sec 14: GEL Offset: 0x006d98b6 ( 7182518) Len: 0x00009010 (   36880) Addr: 0x2003d400 [CHECK PASSED]
Sec 15: GEL Offset: 0x006e28c6 ( 7219398) Len: 0x00001661 (    5729) Addr: 0x201fd800 [CHECK PASSED]
Sec 16: GEL Offset: 0x006e3f27 ( 7225127) Len: 0x000bb808 (  768008) Addr: 0x20045000 [CHECK PASSED]
Sec 17: GEL Offset: 0x0079f72f ( 7993135) Len: 0x00046ef0 (  290544) Addr: 0x20100000 [CHECK PASSED]
Sec 18: GEL Offset: 0x007e661f ( 8283679) Len: 0x00000040 (      64) Addr: 0x20122800 [CHECK PASSED]

Splitting to 'sec.bin' files...

$


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: granz on January 16, 2014, 07:44:05 pm
One of the forum members tested my DS2k 00.02.01.00.03 firmware patch and reported that it works fine, ie. allows to use the old keygen with A scopes without any problems.
Nice. And the 50 ohm input option still works?

Here is quote from his mail:

Quote
I did this to verify your patched firmware:

-- Used SYSTEM:UNINSTALL to remove all my current options that I got using tirulerbach's rigup keygen (verified back to trial versions etc.)
-- Flashed your patched GEL
-- Installed DSHH key from riglol 1.03c

50 Ohm option + serial etc. are all intact.  I have 2ns

Also 1ns TB, but I guess I left that off by mistake...

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: chebeba on January 16, 2014, 07:52:28 pm
I can confirm that zombie's patched f/w works just fine on my (ex) DS2072A. Hats off.  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Altemir on January 16, 2014, 08:08:42 pm
zombie28 and cybernet
Do You have the opportunity to patch last DS4k firmware 00.02.01.00.03 for MSO4024 to 350 and (or) 500MHz? Thank You in advance.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on January 16, 2014, 09:40:11 pm
So, enjoy  ;)
https://mega.co.nz/#!FFk10SCY!UuWPXyqZwmca00pa2clOth1ryh1Z-AAgJg2yibfoUw0

"Your browser seems a bit outdated."   :wtf:

Is there some reason I'm unaware of that a downloader site would force you to have a recent version of a browser?  So my browser is "outdated".  So what?  It happens to be the last version of Firefox that will run on my older XP system.

I don't get the attitude.  Oh, and it might be worthwhile for the Browser Police at Mega to learn how to spell "Recommended", so they don't look like morons (misspelled it twice, on the same page).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 16, 2014, 09:49:48 pm
So, enjoy  ;)
https://mega.co.nz/#!FFk10SCY!UuWPXyqZwmca00pa2clOth1ryh1Z-AAgJg2yibfoUw0

"Your browser seems a bit outdated."   :wtf:

Is there some reason I'm unaware of that a downloader site would force you to have a recent version of a browser?  So my browser is "outdated".  So what?  It happens to be the last version of Firefox that will run on my older XP system.
Mega has plugins for Chrome and Firefox that quote: "reduces loading times, improve download performance and strengthen security".
I believe you need a recent version of Chrome or Firefox to be able to install these plugins.
You can use Mega without these plugins, but with less security and performance.

Firefox App: https://mega.co.nz/#firefox
Chrome App: https://mega.co.nz/#chrome
Mobile Apps: https://mega.co.nz/#mobile
Sync Client (coming soon): https://mega.co.nz/#sync

Oh, and it might be worthwhile for the Browser Police at Mega to learn how to spell "Recommended", so they don't look like morons (misspelled it twice, on the same page).
Doesn't help much complaining about it here. Report a bug: bug@mega.co.nz
Kim Dotcom (the famous guy behind Mega) is German so his English spelling might not be perfect. ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: George10256 on January 16, 2014, 09:53:09 pm
 :-+ :clap:
Great work! Zombies patched f/w works just fine with my DS2072A.
Thanks a lot.

My jtag adapter is on the way. Soon I can help if more dumps are required.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 16, 2014, 09:53:35 pm
;D

"Your browser seems a bit outdated." = You are: A)  An old, out-of-touch geezer.  B) Completely uncool.  C) Hopelessly untechnical.  D) All of the above.


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Swap_File on January 16, 2014, 10:04:10 pm
I've got a Mini JTAG blaster on the way too, ready to experiment once it arrives.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on January 16, 2014, 11:10:54 pm
;D

"Your browser seems a bit outdated." = You are: A)  An old, out-of-touch geezer.  B) Completely uncool.  C) Hopelessly untechnical.  D) All of the above.

I guess if those are my choices, I'll have to pick...  A.

Can't be B, since it's 60F where I'm sitting right now.  :)  I'm very cool.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on January 16, 2014, 11:21:43 pm
Mega has plugins for Chrome and Firefox that quote: "reduces loading times, improve download performance and strengthen security".
I believe you need a recent version of Chrome or Firefox to be able to install these plugins.

Thanks, Anders.  Another way of saying it is that they've decided to be incompatible with browsers that some (many?) folks are using.  I would have just flipped to my newer version of IE, but I guess that's not worth them "supporting".

Quote
You can use Mega without these plugins, but with less security and performance.

I'd be more than happy to do so.  However, there's no such option available, that I can see.

Quote
Doesn't help much complaining about it here. Report a bug: bug@mega.co.nz

Yeah, I know.  I was just annoyed by what I perceived to be arrogance on their part, and took the opportunity to criticize their spelling.  Very juvenile of me.  :)
Title: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on January 17, 2014, 12:38:04 am
rigol.avotronics.co.uk is down for maintenance. Actually I'm moving to a newer server to please be patient.
Should be back up tomorrow sometime.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bluesmoke on January 17, 2014, 02:12:32 am
Good news Everyone!  Attached to this post is a utility to repair corrupted S/N's on DS2000 series scopes! 

Marc: Tried the SNMODFIX utility and it worked a treat restoring my serial. Been waiting a while for that one!
A BIG thank you to you and your anonymous friend for your great work!!!  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on January 17, 2014, 02:30:56 am
Good news Everyone!  Attached to this post is a utility to repair corrupted S/N's on DS2000 series scopes!  Someone I know took up the challenge to write a utility to repair corrupted serial numbers as their contribution to all the great work done so far.  It's a simple but very clever Windows .exe file that will ask your model/serial # and modify a .gel file located in the same directory as the executable file.  Note: This utility only works with firmware version 00.01.01.00.02.  If you need a copy of this firmware version, see Marmad's post (Reply #2) in this thread: https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/ (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/)  The locations of the model & S/N change between firmware versions so it will corrupt any other version of firmware so verify that you have firmware version 00.01.01.00.02.  It also requires the ability to send SCPI commands to the scope.

BRILLIANT, saved me some work (not like I haven't been not busy enough to do any) - thanks :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigol-Friend on January 17, 2014, 02:46:27 am
Hi Gentlemen,

a question about the Rigol DS2000:
With the left menu-key I can display a lot of selected informations at the bottom of the screen. I meen that what I marked in the attachment with big white points  :D

But I don't find any information how to remove this entries.   :--
My week english don't allow to understand the english manual completly   :-[

Does anybody has a hint for me for removing?

Thanks a lot,
Rigol-Friend
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on January 17, 2014, 03:00:21 am
a question about the Rigol DS2000:
With the left menu-key I can display a lot of selected informations at the bottom of the screen. I meen that what I marked in the attachment with big white points  :D

But I don't find any information how to remove this entries.   :--
My week english don't allow to understand the english manual completly   :-[

Does anybody has a hint for me for removing?

How about:  Measure -> Clear -> Item N  ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigol-Friend on January 17, 2014, 03:09:09 am
@Mark_O:

Phantastic, sometimes I think I'm blind.  :-X

Thank you so much,
Rigol-Friend
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: stuartk on January 17, 2014, 04:11:33 am
Hi all,

I have, I hope a not too distracting question from a newbie. I've purchased a DS2102 some time ago and upgraded using the Keygen on the forum.

Unfortunately, I selected the DS2102 option by mistake. I then re-entered the code using the DS2202 and I have the following installed screen which is somewhat ambiguous as to what the scope bandwidth actually is.

At home I only have a POS AWG that can put out a maximum 25Mhz sine wave. Using a 2v p-p signal, my p-p voltage at 25mhz was 1.92v down from 2.24v. That works out to 1.3 dB loss (I think), which doesn't make sense if the scope were at 200Mhz.

Does anyone have a quick and easy method to ballpark the actual bandwidth with spit and chewing gum? :-[

Should I reset the options by putting the code for the trial options for the DS2102 back in and redo it?

Kudo's to all the very large brains on the forum that made this all possible.  :clap:

Thanks, S.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MrKrabs on January 17, 2014, 04:14:18 am
Hey cybernet,

I was reverse engineering your reverse engineering :), trying to port your DS4000 firmware hack which is version 00.02.00.00.04 to the latest version 00.02.01.00.03.

I was able to find the 2 magic bytes to modify (0x4899 into 0x2060) in the new firmware and then recalculated the CRC for section 00.

Then I updated the firmware on my DS4014 with my patched firmware. The update worked fine (I know because I had a 00.01.xx firmware), BUT it didn't enable the BW options neither gave me 1ns TB option.

I then went back to your 00.02.00.00.04 firmware and confirmed it enabled the BW options & 1ns TB, so I know it works on my DS4K.

Do you have any idea what the deal is with the latest DS4K firmware? I found the 0x4899 byte at 0x128a3c. It at least matched the nearby bytes almost perfectly when comparing with your firmware.

There's a big chance, of course, I was just changing the wrong bytes :)

Here's a diff of the hexdumps:

Code: [Select]
$ diff DS4000Update.00.02.01.00.03.orig.GEL.hex DS4000Update.00.02.01.00.03.modified.GEL.hex
4c4
< 00000030  32 62 77 f0 00 00 00 00  00 00 04 20 01 00 00 00  |2bw........ ....|
---
> 00000030  5d 10 2a 87 00 00 00 00  00 00 04 20 01 00 00 00  |].*........ ....|
75940c75940
< 00128a30  00 e8 00 00 09 e1 2d 0d  49 e1 e7 00 48 99 01 e8  |......-.I...H...|
---
> 00128a30  00 e8 00 00 09 e1 2d 0d  49 e1 e7 00 20 60 01 e8  |......-.I... `..|

Cheers!

Aha! I've got it working now.

 I found the right place to patch it. Here's the diff, for the curious:

Code: [Select]
$ diff DS4000Update.00.02.01.00.03.GEL.hex DS4000Update.00.02.01.00.03.MrKrabs.GEL.hex
4c4
< 00000030  32 62 77 f0 00 00 00 00  00 00 04 20 01 00 00 00  |2bw........ ....|
---
> 00000030  54 8b 5e f6 00 00 00 00  00 00 04 20 01 00 00 00  |T.^........ ....|
79428c79428
< 00136430  48 99 01 e8 00 00 10 00  00 e8 00 00 09 e1 2b 1d  |H.............+.|
---
> 00136430  20 60 01 e8 00 00 10 00  00 e8 00 00 09 e1 2b 1d  | `............+.|

I've successfully tested it on my DS4014. Got the 200MHz, 100MHz and 20MHz BW limit options and 1ns timebase.  :D

Model number remained DS4014. Riglol keys continued to work.

I've uploaded the file here: http://wikisend.com/download/164218/DS4000Update.00.02.01.00.03.MrKrabs.GEL.zip (http://wikisend.com/download/164218/DS4000Update.00.02.01.00.03.MrKrabs.GEL.zip)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MrKrabs on January 17, 2014, 04:50:53 am

There the geltool is mentioned again, where do one find that?

cybernet hasn't released it (yet?). I modified the firmware by hand :(

Based on my own dissection of the .GEL files I wrote a small "de-GEL-ing" program for my own use (this is unrelated to cybernet's geltool).  I haven't determined what all of the fields are, but the overall structure is correct and it will do CRC-ing for you on the .GEL file.  It's not very sophisticated, as I didn't originally intend to post it.  I've tested on DS2000 and DS4000 .GEL files but nothing else.  After you have the individual sections you can use bfin-objdump to disassemble (see note at top of .c file).

https://mega.co.nz/#!Nx10QALC!ZZ1-0mPUxjAxB0gvgI0YdSzZ-7hJBBUtQPqBR7OYw-s

Here's an example run:

Code: [Select]

$ ./degel DS2000Update_00.02.01.00.03.GEL

Model Name:          DS2202
Software Version:    00.02.01.00.03
Number of Sections:  19

Sec 00: GEL Offset: 0x0000023c (     572) Len: 0x00326e00 ( 3304960) Addr: 0x20040000 [CHECK PASSED]
Sec 01: GEL Offset: 0x0032703c ( 3305532) Len: 0x0017be32 ( 1556018) Addr: 0x20000000 [CHECK PASSED]
Sec 02: GEL Offset: 0x004a2e6e ( 4861550) Len: 0x00010f60 (   69472) Addr: 0x20000000 [CHECK PASSED]
Sec 03: GEL Offset: 0x004b3dce ( 4931022) Len: 0x00035438 (  218168) Addr: 0x20123000 [CHECK PASSED]
Sec 04: GEL Offset: 0x004e9206 ( 5149190) Len: 0x0000245a (    9306) Addr: 0x20173000 [CHECK PASSED]
Sec 05: GEL Offset: 0x004eb660 ( 5158496) Len: 0x000c6c14 (  814100) Addr: 0x20020000 [CHECK PASSED]
Sec 06: GEL Offset: 0x005b2274 ( 5972596) Len: 0x00014d04 (   85252) Addr: 0x200c8000 [CHECK PASSED]
Sec 07: GEL Offset: 0x005c6f78 ( 6057848) Len: 0x000663f4 (  418804) Addr: 0x200f0000 [CHECK PASSED]
Sec 08: GEL Offset: 0x0062d36c ( 6476652) Len: 0x00001d54 (    7508) Addr: 0x20120000 [CHECK PASSED]
Sec 09: GEL Offset: 0x0062f0c0 ( 6484160) Len: 0x0006a30a (  434954) Addr: 0x20000000 [CHECK PASSED]
Sec 10: GEL Offset: 0x006993ca ( 6919114) Len: 0x000032d8 (   13016) Addr: 0x20040000 [CHECK PASSED]
Sec 11: GEL Offset: 0x0069c6a2 ( 6932130) Len: 0x00000b64 (    2916) Addr: 0x20000000 [CHECK PASSED]
Sec 12: GEL Offset: 0x0069d206 ( 6935046) Len: 0x0003c598 (  247192) Addr: 0x20000c00 [CHECK PASSED]
Sec 13: GEL Offset: 0x006d979e ( 7182238) Len: 0x00000118 (     280) Addr: 0x201e4c00 [CHECK PASSED]
Sec 14: GEL Offset: 0x006d98b6 ( 7182518) Len: 0x00009010 (   36880) Addr: 0x2003d400 [CHECK PASSED]
Sec 15: GEL Offset: 0x006e28c6 ( 7219398) Len: 0x00001661 (    5729) Addr: 0x201fd800 [CHECK PASSED]
Sec 16: GEL Offset: 0x006e3f27 ( 7225127) Len: 0x000bb808 (  768008) Addr: 0x20045000 [CHECK PASSED]
Sec 17: GEL Offset: 0x0079f72f ( 7993135) Len: 0x00046ef0 (  290544) Addr: 0x20100000 [CHECK PASSED]
Sec 18: GEL Offset: 0x007e661f ( 8283679) Len: 0x00000040 (      64) Addr: 0x20122800 [CHECK PASSED]

Splitting to 'sec.bin' files...

$


Thanks a lot, granz! Your tool made it much easier to recalculate the CRC and get the segment lengths & locations!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on January 17, 2014, 05:03:27 am
Good news Everyone!  Attached to this post is a utility to repair corrupted S/N's on DS2000 series scopes!  Someone I know took up the challenge to write a utility to repair corrupted serial numbers as their contribution to all the great work done so far.  It's a simple but very clever Windows .exe file that will ask your model/serial # and modify a .gel file located in the same directory as the executable file.  Note: This utility only works with firmware version 00.01.01.00.02.  If you need a copy of this firmware version, see Marmad's post (Reply #2) in this thread: https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/ (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/)  The locations of the model & S/N change between firmware versions so it will corrupt any other version of firmware so verify that you have firmware version 00.01.01.00.02.  It also requires the ability to send SCPI commands to the scope.

BRILLIANT, saved me some work (not like I haven't been not busy enough to do any) - thanks :)

Well maybe I was a bit premature. It doesn't work.

After loading the firmware and showing the advanced serial screen, the serial is correct, but the model is still incorrect (showing 2202). After following the instructions I still get DS2202 with 14-digit xx0001 SN. Yes, I selected DS2072 in the tool. Do codes need to be installed before starting this?

I can load new codes for my original SN, so parts of it seem to be working, but the display is still wrong :/

EDIT: I've tried using DS2202 model option, but it still doesn't work.
After rebooting I can't send a code against my serial number until I enable the advanced system info menu, then I can. So it is loading (at least the serial portion), but looks like whatever is supposed to save the serial isn't working or has some other problem.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Altemir on January 17, 2014, 07:08:53 am
MrKrabs
You have got 500MHz DSO with this FW, but SysInfo show DS4014? Do you already have frequency response tests?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: johna on January 17, 2014, 07:30:06 am
Hi,
I've read big part of this thread  and I could understand most of it - I've downloaded and compiled keygen code. I've also downloaded modified firm ware. What I don't understand is:
1. I know you have to change DS2xxxA firmware with 2xxx in order the keygen to work. the most important thing is can this be reversed. It's quite an expensive instrument to risk warranty. Can it go to standard non-options firmware (or with the options you buyed if you had.
1.1. can options be removed?  how?
1.2. will the scope (DS2072A) accept official unpatched firmware upgrade from Rigol after it's flashed with patched DS2072 version. What will happen to installed options if you update it back again to DS2072A. Will there be a trace/log of installed codes (warranty). Or is there any kind of log of what you are trying to put on your scope - firmware, codes ... etc.
2. what does GEL mean? I guess I missed the explanation.
3. Do I have to open my scope in order to upgrade it? I know it would help if I sniff the internal bus and send the results, but I can't afford to risk the warranty.
Most of the people are happy how they are gonna boost their scope and no one asks about warranty. And most of the people can't afford to buy these options, so the loss if the scope brakes and they refuse to fix it/replace it will be quite high.

It might be good if someone (andyturk) puts those in the first post which could be used as a wiki page.

I'm sure Rigol have good reasons to put those prices on the options and I'm sure you haven't already payed for it when you are buying the scope - they probably just lowered the price with the idea to compensate when options are sold. But ... I can't afford them and I don't make tons of money from it so my conscience is clean. So good job and big thanks to all guys making this possible.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bluesmoke on January 17, 2014, 07:41:07 am
Good news Everyone!  Attached to this post is a utility to repair corrupted S/N's on DS2000 series scopes!  Someone I know took up the challenge to write a utility to repair corrupted serial numbers as their contribution to all the great work done so far.  It's a simple but very clever Windows .exe file that will ask your model/serial # and modify a .gel file located in the same directory as the executable file.  Note: This utility only works with firmware version 00.01.01.00.02.  If you need a copy of this firmware version, see Marmad's post (Reply #2) in this thread: https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/ (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/)  The locations of the model & S/N change between firmware versions so it will corrupt any other version of firmware so verify that you have firmware version 00.01.01.00.02.  It also requires the ability to send SCPI commands to the scope.

BRILLIANT, saved me some work (not like I haven't been not busy enough to do any) - thanks :)

Well maybe I was a bit premature. It doesn't work.


Make sure you follow the instructions to the letter.... especially step 7 to anchor the changes to flash...

Quote
7.  Connect using scpi and issue :SYSTem:OPTion:UNINSTall command which will
      uninstall all keys and save to flash

All I did at the end was reinstall the latest firmware and then reinstall the options with DSEZ to give me 200MHz and CAN, Triggers, Decoders and Memory upgrade.
I have cycled the scope a number of times now and it all seems good to go.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MrKrabs on January 17, 2014, 07:54:46 am
MrKrabs
You have got 500MHz DSO with this FW, but SysInfo show DS4014? Do you already have frequency response tests?

That's correct, SysInfo shows DS4014. The 500MHz bandwidth on the hacked DS4014 has been confirmed by many others on this thread and in some Youtube videos.

I don't have anything to test the 500MHz BW, but was thinking of trying to probe Gigabit Ethernet (125MHz) for fun.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pascal_sweden on January 17, 2014, 08:08:27 am
MrKrabs
You have got 500MHz DSO with this FW, but SysInfo show DS4014? Do you already have frequency response tests?

Is it possible to upgrade MSO4014 to MSO4054? Is the HW 100% identical? Has hack confirmed to be working not only in GUI, but also in actual frequency response test?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: johna on January 17, 2014, 08:23:03 am
You can test it with any digital signal that's lower. On 100 MHz scope if you watch 100 MHz square wave it'll look like 2 summed sines:
(http://pages.cpsc.ucalgary.ca/~hill/papers/synthesizer/images/2harsqw.png)
although maybe you can't capture much of the second harmonic.
I think even 40-50 MHz square wave will look that way on 100MHz scope. Maybe the clock output from a microcontroller...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Altemir on January 17, 2014, 09:08:18 am
MrKrabs
Thank you very much! As soon as free time, I will try to do tests on the job's MSO4024 up to 2GHz. Can you make a patch to 350MHz test?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 17, 2014, 09:46:08 am
Should I reset the options by putting the code for the trial options for the DS2102 back in and redo it?
You can't uninstall options by installing other options instead. You need to use the SCPI command :SYSTem:OPTion:UNINSTall command to uninstall keys. This has already been mentioned several times in this topic.

If you're not familiar with SCPI commands, read your scope's user's manual + programming guide, both documents has info about SCPI commands.

You can search this topic for :SYSTem:OPTion:UNINSTall for more info.

SCPI = Standard Commands for Programmable Instruments https://en.wikipedia.org/wiki/Standard_Commands_for_Programmable_Instruments
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ve7xen on January 17, 2014, 10:38:24 am
It's been a while since I've monitored this thread and it appears plenty of progress has been made. Excellent work everyone!

Took the opportunity to mirror a bunch more useful files permanently at http://www.gotroot.ca/rigol (http://www.gotroot.ca/rigol) as well as setting up a cron job to pull down the complete thread every day as well. If there's anything else that should be there, send me files or PMs and I will make it so.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: eliocor on January 17, 2014, 12:27:40 pm
Took the opportunity to mirror a bunch more useful files permanently at http://www.gotroot.ca/rigol (http://www.gotroot.ca/rigol) as well as setting up a cron job to pull down the complete thread every day as well. If there's anything else that should be there, send me files or PMs and I will make it so.
Suggestion: it would be better if you can add date/time file was added to your repository.
Thanks for your work!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Altemir on January 17, 2014, 02:42:43 pm
MrKrabs
I wrote your fw to my MSO4024 for 500MHz and got interesting results. All is good. See my own topic today: many pictures requre processing.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: stuartk on January 17, 2014, 03:04:56 pm

Quote
Posted by: AndersAnd
« on: Yesterday at 08:46:08 PM »


Quote from: stuartk on Yesterday at 03:11:33 PM

    Should I reset the options by putting the code for the trial options for the DS2102 back in and redo it?

You can't uninstall options by installing other options instead. You need to use the SCPI command :SYSTem:OPTion:UNINSTall command to uninstall keys. This has already been mentioned several times in this topic.

If you're not familiar with SCPI commands, read your scope's user's manual + programming guide, both documents has info about SCPI commands.

You can search this topic for :SYSTem:OPTion:UNINSTall for more info.

SCPI = Standard Commands for Programmable Instruments https://en.wikipedia.org/wiki/Standard_Commands_for_Programmable_Instruments


AndersAnd Thanks for pointing me in the right direction. I performed the following proceedure to reset it:

To erase options:

In Ultra Sigma:
Right click on the Scope USB Line
Select SCPI Control Panel
Paste:  SYSTEM:OPTION:UNINSTALL over the *IDN?
Send the command

It erased the options
The scope was back to the trial version even remembering the original number of minutes I had left.

I reapplied the code I used before and all the options vanished with the exception that the scope was now a DS2202 instead of a DS2102.  ???
(Windows even reinstalled the scope as a DS2202)  :-+

I should have checked that the S/N was reset to DS2A0000000001

I reran the KeyGen using the mangled serial number and now it seems to work fine with all options with the exception of the loss of the serial number

The minimum timebase flipped from 5ns to 2ns

I appreciate your help, S.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 17, 2014, 03:31:50 pm
I should have checked that the S/N was reset to DS2A0000000001

I reran the KeyGen using the mangled serial number and now it seems to work fine with all options with the exception of the loss of the serial number
You can restore your DS2000's original serial number following this procedure: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg369122/#msg369122 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg369122/#msg369122)


Btw. What FW version do you have and what 4 letter code did you use to generate your key? I don't see CAN decoder listed?

With the latest FW installed:
Use DSEZ for 200 MHz with all other options enabled including CAN but without 50 ohm option from the A-series. [not listed here: http://riglol.3owl.com (http://riglol.3owl.com) but still works]

Read about DSEZ and other codes here: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg356379/?topicseen#msg356379 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg356379/?topicseen#msg356379)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 17, 2014, 03:47:11 pm
Took the opportunity to mirror a bunch more useful files permanently at http://www.gotroot.ca/rigol (http://www.gotroot.ca/rigol) as well as setting up a cron job to pull down the complete thread every day as well. If there's anything else that should be there, send me files or PMs and I will make it so.
Suggestion: it would be better if you can add date/time file was added to your repository.
Thanks for your work!
Another suggestion: Ad folder for all the different Rigol series DS1000E/D, DS1000Z, DS2000, MS0/DS40000, DS6000, DSA8000, DP8000, DG4000 etc. and put the various files in the correct folders. It would make it much easier to navigate and find the relevant files for a specific Rigol product series.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: stuartk on January 17, 2014, 03:50:59 pm
Hi Anders,

Two questions:

1. Is there any benefit to resetting the serial number to the actual number of the unit? Scope works fine now.

2. I would have to downgrade my FW from 00.00.01.00.05 down to the .02 FW for the patch to work.

Should I leave the FW at the 1.00.02 or upgrade it to the latest 00.02.01.00.03? Does one put the Keygen key in before or after the FW upgrade?

Thanks again, Stuart
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: granz on January 17, 2014, 03:54:16 pm

Thanks a lot, granz! Your tool made it much easier to recalculate the CRC and get the segment lengths & locations!

Glad it was useful.  Do you (or anyone else) happen to know what's missing from my understanding of the GEL file format?  I've only had limited time to spend poking around with a hex editor, but I'd like to fill in the last few gaps.  If I knew what's missing I could create (and post) a pair of tools, one to de-GEL and one to re-GEL with the correct CRCs after any code hacks.

Here's what I have for the segment info blocks currently:

typedef struct
{
    UInt32 Length;
    UInt32 Offset;
    UInt32 Check; // CRC32
    UInt32 UnknownA;
    UInt32 Address;
    UInt32 UnknownB;
    UInt32 UnknownC;
} SectionInfo;


Unknowns A, B, and C seem to be mostly zeroes.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 17, 2014, 03:56:42 pm
1. Is there any benefit to resetting the serial number to the actual number of the unit? Scope works fine now.
Probably not, but I would still do it in case you later have to send it in for a warranty repair or something.


Should I leave the FW at the 1.00.02 or upgrade it to the latest 00.02.01.00.03? Does one put the Keygen key in before or after the FW upgrade?
You should definitely upgrade to the latest FW, som fixes and improvements have been made + support for CAN decoding.
Uninstall all keys before upgrading. First apply new keys after upgrading to the latest FW.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: stuartk on January 17, 2014, 04:00:01 pm
Hi Anders,

I used the windows KeyGen v.2.0b1 by synapsis
which was the most recent one I could find.
the code used was: DSAZ
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on January 17, 2014, 04:01:13 pm
You can restore your DS2000's original serial number following this procedure: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg369122/#msg369122 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg369122/#msg369122)

Excellent; I got my serial number fixed using this!!!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 17, 2014, 04:15:17 pm
Hi Anders,

I used the windows KeyGen v.2.0b1 by synapsis
which was the most recent one I could find.
the code used was: DSAZ
Use this web-based RigLol keygen made by EEVblog member studio25 (https://www.eevblog.com/forum/profile/?u=37760): http://riglol.3owl.com (http://riglol.3owl.com)
UK mirror: http://rigol.avotronics.co.uk/mirrors/riglol/ (http://rigol.avotronics.co.uk/mirrors/riglol/)
Canadian mirror: http://www.gotroot.ca/rigol/riglol/ (http://www.gotroot.ca/rigol/riglol/)

RigLol is the only keygen still maintained it seems, and it works on any operating system without installing anything. So there's no need to maintin different versions for Windows, Linux etc. RigLol is also very easy to use. Some have problems accesing the original site http://riglol.3owl.com (http://riglol.3owl.com), so if you do, try one of the two mirror sites instead.

1) Uninstall all options.

2) Restore serial# using procedure described here (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg369122/#msg369122).

3) Upgrade to the latest FW 00.02.01.00.03.

4) Install DSEZ instead of DSAZ for 200 MHz with all options except for the 50 ohm option from the A-series.
Or instead install DSGH for 300 MHz with all options except for for the 50 ohm option from the A-series.
There's some debate whether 300 MHz works properly. Read marmad's and other's comments on this earlier in this in this topic and in the DS2000 review topic (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/).
DSEZ = DSAZ + CAN decoder option, but only works with the latest FW.
DSGH = same as DSEZ but with 300 MHz instead of 200 MHZ.
Read about DSEZ and how to build other letter combinations here: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg356379/?topicseen#msg356379 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg356379/?topicseen#msg356379)

Code: [Select]
y  CAN, 300, 50ohm   |   x  200, 100, Mem, Dec, Trig
E   on   ==   ==     |   Z   on   ==   on   on   on   <-  All 2202
G   on   on   ==     |   H   ==   ==   on   on   on   <-  All 2302

Where y = 3rd letter and x = 4th letter:
DSyx = DSEZ for 200 MHz with all options except 50 ohm
DSyx = DSGH for 300 MHz with all options except 50 ohm


Read about and download the different DS2000 FW versions in this topic: https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/ (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/)
Title: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on January 17, 2014, 04:57:02 pm
rigol.avotronics.co.uk is still down. I just have to transfer the backend database and it will be live again. Will be up Saturday.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: stuartk on January 17, 2014, 05:46:06 pm
Hi Anders

I followed the procedure exactly to reset my S/N

wiped the keys
I entered my actual S/N
Selected my actual model # DS2102
Applied the patched FW

Now apparently I now own a DS2022 scope, whatever that is, with the S/N unchanged on the basic screen

On the detailed screen the S/N is correct however the model is still DS2022

I'm now unable to print screen from Ultra Sigma to show you, ouch!

Thanks, Stuart
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 17, 2014, 05:53:25 pm
I followed the procedure exactly to reset my S/N

wiped the keys
I entered my actual S/N
Selected my actual model # DS2102
Applied the patched FW

Now apparently I now own a DS2022 scope, whatever that is, with the S/N unchanged on the basic screen
That's not following the procedure exactly, that's only the first 3 steps out of 12. Follow all 12 steps from start to finish to the letter, or at least to step 9 to be able to check correct serial number and model. Where's the steps from 4 and onwards?
"true" only did half the procedure too and had the same problem.
Read his posts: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg369783/#msg369783 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg369783/#msg369783)
And the reply: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg369833/#msg369833 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg369833/#msg369833)

1.  Requires 00.01.01.00.02 firmware (7777543 bytes, 0xa167ef30 crc32) named
       DS2000Update.gel in same directory as executable
2.  Execute snmodfix and specify serial and model to patch firmware
3.  Flash patched ds2000update.gel using power on help button method
4.  Restart scope
5.  Enable advanced system information menu (press Trigger Menu, Menu 7,
       Menu 6, Menu 7, Utility
very quickly) to enable it
6.  Show system information - serial should be fixed but NOT saved to flash
      yet - some text labels will be missing
7.  Connect using scpi and issue :SYSTem:OPTion:UNINSTall command which will
      uninstall all keys and save to flash
8.  Once settled restart scope
9.  Show system information (not advanced) should now show the correct serial
      and model
10. Update to latest stock unpatched firmware version
11. Storage -> Default
12. Reinstall any key(s)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: stuartk on January 17, 2014, 06:25:47 pm
Hi Anders,

I followed all the steps I just didn't write then out to save space.

I did the following:

I did not downgrade my firmware from 00.00.01.00.05, to the stock 00.01.01.00.02 firmware before applying the patched 00.01.01.00.02 firmware. I assumed that it would be redundant.

1.  Requires 00.01.01.00.02 firmware (7777543 bytes, 0xa167ef30 crc32) named
       DS2000Update.gel in same directory as executable

Done

2.  Execute snmodfix and specify serial and model to patch firmware

Done. I used my actual S/N not the DS2A000001
I used my actual Model number DS2102 (option 0)

3.  Flash patched ds2000update.gel using power on help button method

done

4.  Restart scope

done

5.  Enable advanced system information menu (press Trigger Menu, Menu 7,
       Menu 6, Menu 7, Utility very quickly) to enable it

done

6.  Show system information - serial should be fixed but NOT saved to flash
      yet - some text labels will be missing

done

7.  Connect using scpi and issue :SYSTem:OPTion:UNINSTall command which will
      uninstall all keys and save to flash

done

8.  Once settled restart scope

done

9.  Show system information (not advanced) should now show the correct serial
      and model

Everything worked up to step #9.

I stopped there as the serial number and model number were not correct.

True got model # 2202, I have 2022


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on January 17, 2014, 06:30:48 pm
7.  Connect using scpi and issue :SYSTem:OPTion:UNINSTall command which will
      uninstall all keys and save to flash

When you did this, did your scope respond with a message on the screen, something like:

Options of official version have deleted.

I mention this because for a long time I thought I was issuing the ":SYSTem:OPTion:UNINSTall" command, but I was doing it wrong and nothing was happening...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: stuartk on January 17, 2014, 06:35:36 pm
Yep it did.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 17, 2014, 06:44:53 pm
What happens if you follow the last 3 steps and use DSEZ as option? Does the model name change to 2202?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on January 17, 2014, 06:50:33 pm
I stopped there as the serial number and model number were not correct.
True got model # 2202, I have 2022

Odd.  I sure don't get the 2022 thing.  Did the serial stay the common mangled 14 digit 0001 type one?

On my unit when I tried this step 5 fixed the serial, but the model was still wrong until I did a restart and then they were both right in the basic system info menu...

I have a theory that it gets corrupted (maybe this is how the s/n gets mangled in the first place) when you try to do more than one key operation without power cycling.  In other words, to keep a s/n from getting messed up, I would always power cycle after doing a key uninstall, or installing a key.  One operation per reboot.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 17, 2014, 06:54:30 pm
Odd.  I sure don't get the 2022 thing.  Did the serial stay the common mangled 14 digit 0001 type one?
What model# did you select for the custom FW? 2072, 2102, 2202 or 2302? Maybe there's a bug in the FW modification tool that only occurs when selecting 2102?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: stuartk on January 17, 2014, 06:57:22 pm
Yes Alan, the serial stayed as the mangled DS2A0....001

But it's correct on the advanced system info screen.  :-//

Model number is corrupted on both the basic and advanced screens

I haven't done step 10-12 yet. Hope I won't destroy the damned thing.........
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: stuartk on January 17, 2014, 06:58:20 pm
I selected Model 2102. I could retry it from the top with 2202...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on January 17, 2014, 07:01:59 pm
Yes Alan, the serial stayed as the mangled DS2A0....001
But it's correct on the advanced system info screen.  :-//
Model number is corrupted on both the basic and advanced screens
I haven't done step 10-12 yet.

Probably smart to do steps 10 and 11 so you are back to a stock firmware.

Hope I won't destroy the damned thing.........

Maybe you should give up on the serial fix and just use it...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on January 17, 2014, 07:03:47 pm
I selected Model 2102. I could retry it from the top with 2202...

You could.  You might even try the ds2072 choice, that one did work for me, but I do have a ds2072.  Even if you get it to "stick" with a ds2072, you can upgrade it with a key anyway.  The question here is why doesn't it stick after issuing the uninstall and restarting.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: stuartk on January 17, 2014, 07:51:02 pm
OK,

I did it all from the top using the DS2202 as a base in the FW patch

The model number remained at DS2022 with the DS2A000...1 S/N  :(

I update to the latest firmware

I applied the DSGH code (for fun of course!)

And voila it works!!

The Model comes out as DS2302
The S/N remains mangled at DS2A0000000001

I have all the installed options

The minimum time base is now at 1ns.

Most importantly, I no longer have options (most of which I don't need) counting down annoyingly.

The only down side is that my S/N is wrong and I can no longer take a screen shot with Ultra Sigma.

The thing I haven't tried yet is doing the S/N repair set to a DS2072. When I did it as a 2102 and 2202 there were issues.

Thanks Anders and Alan for your help,  :-+

Regards, Stuart
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on January 17, 2014, 07:53:01 pm
Thanks Anders and Alan for your help,  :-+

If you are happy and it is working for you that is the what is important! :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 17, 2014, 10:53:31 pm
I used this one. It unlocked everything but CAN Decoding. CAN decoding is now missing from my available licenses, and is not an option for decoding.

Any Ideas? :/
What 4 letter code did you use to generate the key?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ZeroAviation on January 17, 2014, 10:54:27 pm
I used this one. It unlocked everything but CAN Decoding. CAN decoding is now missing from my available licenses, and is not an option for decoding.

Any Ideas? :/
What 4 letter code did you use to generate the key?

The wrong one lol DSAZ. DSEZ is the correct one I believe.

-Matt
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 17, 2014, 11:04:42 pm
What 4 letter code did you use to generate the key?
The wrong one lol DSAZ. DSEZ is the correct one I believe.
Yes that's exactly the difference between DSAZ and DSEZ. DSEZ has CAN decoding and DSAZ hasn't. Both are 200 MHz.
But please note none of them include the 50 ohm option included in the A-version. So you should probably use DSFZ instead of DSEZ to support the 50 ohm input option. Only difference is that DSFZ includes the 50 ohm option and DSEZ doesn't.

If you want 300 MHz with all options instead of 200 MHz then use DSHH.
The 300 MHz code with all features except the 50 ohm option is DSGH, this would be more correct to use on models that doesn't support 50 ohm input, even though http://riglol.3owl.com (http://riglol.3owl.com) only mentions DSHH for all options.

Read about DSEZ and how to build other letter combinations here: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg356379/?topicseen#msg356379 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg356379/?topicseen#msg356379)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: eevblogee on January 18, 2014, 12:07:22 am
My first post,

I would like to say thank you first of all to amazing forum/folks which let me learn a lot and buy an ds2072a. With the help of you guys i believe Rigol start to sell more devices, just for the records. As a newbie(i got the idea,no pain nogain :) ) i went through old posts and realized for ds2072a dumps are needed. My device is DS2D1547xxxxx 00.02.00 hw2. 47th week :(. I will order an olimex's jtag debugger for dump, afai read it is the fastest, unless somebody comments for better i will go with it. I will also post some pictures when i open it, warranty seal video is really usefull btw. But at the same time  i am also interested in getting dumps from lan port if there is a possibility for future. If we ran a gdbserver on blackfin mpu then will it be possible to get enough info for your investigations? I can help for coding if you guys need help.

Cheers
Newbie
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on January 18, 2014, 04:13:30 am
Good news Everyone!  Attached to this post is a utility to repair corrupted S/N's on DS2000 series scopes!  Someone I know took up the challenge to write a utility to repair corrupted serial numbers as their contribution to all the great work done so far.  It's a simple but very clever Windows .exe file that will ask your model/serial # and modify a .gel file located in the same directory as the executable file.  Note: This utility only works with firmware version 00.01.01.00.02.  If you need a copy of this firmware version, see Marmad's post (Reply #2) in this thread: https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/ (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/)  The locations of the model & S/N change between firmware versions so it will corrupt any other version of firmware so verify that you have firmware version 00.01.01.00.02.  It also requires the ability to send SCPI commands to the scope.

BRILLIANT, saved me some work (not like I haven't been not busy enough to do any) - thanks :)

Well maybe I was a bit premature. It doesn't work.


Make sure you follow the instructions to the letter.... especially step 7 to anchor the changes to flash...

Quote
7.  Connect using scpi and issue :SYSTem:OPTion:UNINSTall command which will
      uninstall all keys and save to flash

All I did at the end was reinstall the latest firmware and then reinstall the options with DSEZ to give me 200MHz and CAN, Triggers, Decoders and Memory upgrade.
I have cycled the scope a number of times now and it all seems good to go.
The first thing I did was follow the instructions to the letter.

The changes never saved.

Quote from: staurtk
I followed the procedure exactly to reset my S/N

...

Now apparently I now own a DS2022 scope, whatever that is, with the S/N unchanged on the basic screen

On the detailed screen the S/N is correct however the model is still DS2022
Yes, same problem here.

Quote from: AndersAnd
"true" only did half the procedure too and had the same problem.
I followed the instructions exactly. Only when it didn't work I tried other things. Obviously you didn't read what I wrote.

Quote from: alan2k
Odd.  I sure don't get the 2022 thing.  Did the serial stay the common mangled 14 digit 0001 type one?
In the normal system info screen, it is the 0001 S/N.
In the special system info screen, it is DS2202 with the entered S/N.

Quote from: AndersAnd
What model# did you select for the custom FW? 2072, 2102, 2202 or 2302?
As written in my post, I tried 2072 and 2202. I also tried 2102 with the same results.

Quote from: alan2k
Maybe you should give up on the serial fix and just use it...
In short, no.
In length, no. I use it and I will fix this issue.

---

Basically I am having the same exact results as stuartk. Obviously this patch doesn't work. As some have stated success I will look into this and work on my own patch or see if there exists a mechanism to do this with the existing scope software.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mamalala on January 18, 2014, 05:39:38 am
Hey,

does anyone have a dump of the flash memory of the DS1/2/4 scopes at hand? Just a linear dump, as seen by the Blackfin. Maybe i missed it, but so far i have seen only RAM memory dumps here. I'd like to peek a bit into the flash mem instead. Since i don't have a Rigol scope myself yet, i ask here ... If you have concerns about putting such a dump online for all to see, because of some serial number fancieness, feel free to let me know by PM instead. Just don't hand me some dump where the potential s/n is modified after the dump, since that would make it pretty much worthless to what i'd like to try.

Greetings,

Chris
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: chebeba on January 18, 2014, 06:04:09 am
i went through old posts and realized for ds2072a dumps are needed.

Not any more. You can flash Zombie's patched firmware (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg369434/#msg369434), which will upgrade you scope to the latest f/w but make it accept pre-A license codes, which means you use the olds keygens to get a license and all works fine.

Only problem with this approach is you will loose your options if you update to stock firmware later.

But please go ahead and do the dumps anyway, to allow more progress. I will as soon as my JTAG arrives.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sigxcpu on January 18, 2014, 08:28:37 am
Good news Everyone!  Attached to this post is a utility to repair corrupted S/N's on DS2000 series scopes! 

....

Tested on several DS2072's w/ original hardware and it works perfectly.  Again, this has not been tested on any hardware versions other than 1.0.  Please don't ask about a Linux version as neither of us are Linux users.  Also, I don't have the source code as the author didn't offer it.  I'm very grateful for his work and won't pester him for the source code.  If you have any issues/suggestions/comments please feel free to contact me.
Edit: Corrected firmware link

Confirmed for HW 2.0. Just recovered my serial number, re-generated the license code and everything is OK.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: eevblogee on January 18, 2014, 10:14:58 am
Did anyone tried connecting a ftdi based serial2usb converter to see if a shell is available, i wish they forget the driver for debugging purposes.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Flipp on January 18, 2014, 10:53:20 am
Patched firmware working, BW confirmed, Serial# still there.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 18, 2014, 10:56:01 am
Patched firmware working, BW confirmed, Serial# still there.
What scope model and HW version is it?
Patched to 200 or 300 MHz?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Flipp on January 18, 2014, 11:00:35 am
It was a DS2072A before.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Avotronics on January 18, 2014, 11:34:08 am
http://rigol.avotronics.co.uk (http://rigol.avotronics.co.uk)

is back up  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: egonotto on January 18, 2014, 01:48:45 pm
Hi,

the restore of SN does by me also not work. It is like by Stuart.

Regards, egonotto


PS:

I have short a timebase of 500ps/DIV
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigol-Friend on January 18, 2014, 02:14:23 pm
I have short a timebase of 500ps/DIV

Yes, but in real this timebase is 1 ns/DIV    :--
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: aadamson on January 18, 2014, 07:08:16 pm
One of the forum members tested my DS2k 00.02.01.00.03 firmware patch and reported that it works fine, ie. allows to use the old keygen with A scopes without any problems. This patch is a temporary solution for those who cannot or don't want to do memory dumps (at least until it's possible via USB). Of course extracting keys from memory is still preferred method, because license codes created this way should work even with future official firmware releases.

So, enjoy  ;)
https://mega.co.nz/#!FFk10SCY!UuWPXyqZwmca00pa2clOth1ryh1Z-AAgJg2yibfoUw0

For the record this worked on a brand new 2072a with 2.0 hardware.  I didn't go up to 300mhz due to the discussion about filter quality, but I did go to the 200mhz and turned back on all the other options...

oh and mine is a week 47 version for the record.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 18, 2014, 07:28:21 pm
I didn't go up to 300mhz due to the discussion about filter quality...

Just for the record: the possible issue with the filter would only be when running @ exactly the 1GSa/s sampling rate with Vectors on - because at that sample rate, the Rigol does sin(x)/x interpolation - which would be susceptible to errors with frequencies above the Nyquist frequency (500MHz) - and it's not clear from tests how well the HW v.2 filter blocks those (when 300MHz BW is activated). Until the issue is completely clarified, if you want to be certain of signal fidelity at smaller time bases (i.e. running a DS2302 @ 1GSa/s), probably best to use the 100MHz BW filter.

At the 2GSa/s sampling rate (single channel), the Nyquist frequency is 1GHz, so the filter is totally fine (those frequencies would be well-attenuated) - and at lower sample rates (<= 500MSa/s) it doesn't matter because the DS2000 stops doing sin(x)/x interpolation and instead does linear interpolation - which is not susceptible to the errors (although it can't reconstruct higher frequencies as well with as few samples).

So if you're willing to put up with the idea of having a single-channel 300MHz DSO combined with a dual-channel 100MHz DSO, you can reliably use it that way. :)  (EDIT: Although I should add that the 1ns time base still seems a little bit buggy).

What we REALLY need is a hack which gives us back the 200MHz BW switch - which would be great to use when running a DS2302 w. 2 channels @ 1GSa/s. I can't understand why Rigol removed that option.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: thetooth on January 19, 2014, 02:12:08 am
I didn't go up to 300mhz due to the discussion about filter quality...

Just for the record: the possible issue with the filter would only be when running @ exactly the 1GSa/s sampling rate with Vectors on - because at that sample rate, the Rigol does sin(x)/x interpolation - which would be susceptible to errors with frequencies above the Nyquist frequency (500MHz) - and it's not clear from tests how well the HW v.2 filter blocks those (when 300MHz BW is activated). Until the issue is completely clarified, if you want to be certain of signal fidelity at smaller time bases (i.e. running a DS2302 @ 1GSa/s), probably best to use the 100MHz BW filter.

At the 2GSa/s sampling rate (single channel), the Nyquist frequency is 1GHz, so the filter is totally fine (those frequencies would be well-attenuated) - and at lower sample rates (<= 500MSa/s) it doesn't matter because the DS2000 stops doing sin(x)/x interpolation and instead does linear interpolation - which is not susceptible to the errors (although it can't reconstruct higher frequencies as well with as few samples).

So if you're willing to put up with the idea of having a single-channel 300MHz DSO combined with a dual-channel 100MHz DSO, you can reliably use it that way. :)  (EDIT: Although I should add that the 1ns time base still seems a little bit buggy).

What we REALLY need is a hack which gives us back the 200MHz BW switch - which would be great to use when running a DS2302 w. 2 channels @ 1GSa/s. I can't understand why Rigol removed that option.
I installed the patch last night to try it and semi bricked my scope(would no longer show logo when you powered on), it came down to using a 4GB SD card in a reader, using a 2GB card or dedicated USB stick works so was able to get the firmware loaded up. lel

As i was about to ask, is it possible to only install the 200Mhz with all the other addons(i am very lazy and hate using that selector knob)? I made the mistake of thinking DSAS was 200Mhz+all options, so now i have installed 200+300+addons options. Would it be fair to say i could remove the 300Mhz option and keep the addons?

Also to note i've managed to keep my serial number and model intact(says 2302A), 50Ohm termination and BW limits(20, 100, 200) are all working as expected. And as a major plus my scope has finally stop crashing if i didn't press any buttons for more than 30 seconds.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 19, 2014, 02:40:52 am
As i was about to ask, is it possible to only install the 200Mhz with all the other addons(i am very lazy and hate using that selector knob)? I made the mistake of thinking DSAS was 200Mhz+all options, so now i have installed 200+300+addons options. Would it be fair to say i could remove the 300Mhz option and keep the addons?

Yes, you should be able to.

Quote
...and BW limits(20, 100, 200) are all working as expected.

Are you sure you have the 200MHz BW limit? Other people (including myself) have not seen it anymore in the latest FW version (when installing the 300MHz option) - and it's not listed in the Model A Owner's Manual or datasheet for the DS2302A.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bluesmoke on January 19, 2014, 04:58:34 am

As i was about to ask, is it possible to only install the 200Mhz with all the other addons(i am very lazy and hate using that selector knob)? I made the mistake of thinking DSAS was 200Mhz+all options, so now i have installed 200+300+addons options. Would it be fair to say i could remove the 300Mhz option and keep the addons?


DSEZ will give you 200MHz, CAN, Triggers, Decoders and Memory upgrade on the latest firmware.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: echen1024 on January 19, 2014, 05:01:29 am
Alright. I won a DS1074Z, and would like to help out here. I have installed the options according to the keygen, but is there anything else regarding the 1000Z that you guys would like help with?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: eevblogee on January 19, 2014, 07:03:36 am
i went through old posts and realized for ds2072a dumps are needed.

Not any more. You can flash Zombie's patched firmware (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg369434/#msg369434), which will upgrade you scope to the latest f/w but make it accept pre-A license codes, which means you use the olds keygens to get a license and all works fine.

Only problem with this approach is you will loose your options if you update to stock firmware later.

But please go ahead and do the dumps anyway, to allow more progress. I will as soon as my JTAG arrives.

One of our forum member took a screenshot after this firmware upgrade which shows hw version different then 2.0 . Is there any possibility this can cause an issue, should i wait for a keygen which works with stock fw or is it a dream.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: eurofox on January 19, 2014, 10:31:50 am
Hi,

If I order a Rigol 815 TG with the supplied firmware can I use the keygen?

Please don't say "read the complete treat", I did but it is hard to find out if yes/no it is possible.

If someone recently bought it and use the keygen it should be easy to answer.

eurofox
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on January 19, 2014, 11:08:34 am
One of our forum member took a screenshot after this firmware upgrade which shows hw version different then 2.0 . Is there any possibility this can cause an issue, should i wait for a keygen which works with stock fw or is it a dream.

AFAIK HW version '2.0' is not Rigol's term, it's just used on this forum to describe new version of DS2k(A) PCB. The newest HW version displayed by DS2kA scopes I've seen so far is 1.0.2.0.2 and it doesn't change after firmware upgrade (take a look at Flipp's screenshots before and after update).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: blandin_01 on January 19, 2014, 11:17:35 am
Simple USB_JTAG on PIC18F14K50 http://sa89a.net (http://sa89a.net)
(http://pikucha.ru/icw9f/thumbnail/sxema.jpeg) (http://pikucha.ru/icw9f)
https://mega.co.nz/# (https://mega.co.nz/#)!NA1HFCLC!BEN1ISNqo1shidG-RP3vKQv9P84lCvcrQMkfYj9x-HQ
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cosmos on January 19, 2014, 12:03:10 pm
One of our forum member took a screenshot after this firmware upgrade which shows hw version different then 2.0 . Is there any possibility this can cause an issue, should i wait for a keygen which works with stock fw or is it a dream.

AFAIK HW version '2.0' is not Rigol's term, it's just used on this forum to describe new version of DS2k(A) PCB. The newest HW version displayed by DS2kA scopes I've seen so far is 1.0.2.0.2 and it doesn't change after firmware upgrade (take a look at Flipp's screenshots before and after update).

The HW version number (at least on DS4k) is set by the array of resistors.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: discopope on January 19, 2014, 12:25:29 pm
Hi,

If I order a Rigol 815 TG with the supplied firmware can I use the keygen?

Please don't say "read the complete treat", I did but it is hard to find out if yes/no it is possible.

If someone recently bought it and use the keygen it should be easy to answer.

eurofox

For mine it worked, but I found no way to remove the trial options, now i have them in addition to the permanent ones.
I dont't know what happens when they expire.
To avoid typing all the keys in I used Ultra Sigma, the system:Lkey command, it ist described in DSA800_ProgrammingGuide_EN.chm.

Title: hacking dp832
Post by: rsivan on January 19, 2014, 10:41:44 pm
Hello to all
I make some try and I done dump of my dp832 I see nand flash + spi flash +24c16 eeprom
I can't find serial number anywhere,24c16 seem to contain some calibration data, spi flash W25X40 some data like encrypted I think is here serial,and in nand flash I see more or less only first 3-4mb filled and seem like the DP800Update.GEL file something interesting found multiple refers to all model of dp800 series so I think changing serial will hack 832 into 832a since all the board same and are marked 832a I post some pictures
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: aadamson on January 20, 2014, 01:04:50 am
One of our forum member took a screenshot after this firmware upgrade which shows hw version different then 2.0 . Is there any possibility this can cause an issue, should i wait for a keygen which works with stock fw or is it a dream.

AFAIK HW version '2.0' is not Rigol's term, it's just used on this forum to describe new version of DS2k(A) PCB. The newest HW version displayed by DS2kA scopes I've seen so far is 1.0.2.0.2 and it doesn't change after firmware upgrade (take a look at Flipp's screenshots before and after update).

Thats not true.

My DS2D1547 serial number DS2072A scope when it was a 2072A from the factory showed hardware as 2.0... After using your old keygen mod with new firmware, it still shows my serial number correctly *and* the Hardware version still shows 2.0.

I don't and never did see anything around the FPGA versions, not sure where or how those exist.

I only went to the 200mhz upgrade with all the options, and so far everything shows up and works just fine.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 20, 2014, 01:10:27 am
Thats not true.

My DS2D1547 serial number DS2072A scope when it was a 2072A from the factory showed hardware as 2.0... After using your old keygen mod with new firmware, it still shows my serial number correctly *and* the Hardware version still shows 2.0.
I'm pretty sure zombie28 is correct. "2.0" is just what you see when you press Utility -> System -> System Info, but it's not the full hardware version number: 1.0.2.0.2 is the actual number. If not, what exactly do you see when you look at the Extended Info (not Standard)? If you don't know how to see it, instructions are here (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684) (you will see your full software and FPGA versions as well).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ArthurK on January 20, 2014, 01:44:16 am
Hey guys, Don't have time to read through 180 pages on this forum. I am an electronics technician by trade  and have just purchased a DS1104Z and am keen to help in any way to hack this thing even if it mean pulling it apart :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 20, 2014, 02:05:59 am
Hey guys, Don't have time to read through 180 pages on this forum. I am an electronics technician by trade  and have just purchased a DS1104Z and am keen to help in any way to hack this thing even if it mean pulling it apart :)
http://riglol.3owl.com/ (http://riglol.3owl.com/)

Scroll down for DS1000Z.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ArthurK on January 20, 2014, 03:09:13 am
Wow that awesome. Sorry bit behind the times have been flat out at work. Just trying to upgrade the firmware but not too sure how? cant find any mention in the user manual.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 20, 2014, 03:15:26 am
Wow that awesome. Sorry bit behind the times have been flat out at work. Just trying to upgrade the firmware but not too sure how? cant find any mention in the user manual.
Bottom of this post. (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ArthurK on January 20, 2014, 03:43:30 am
Cheers thanks heaps worked a treat!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: eevblogee on January 20, 2014, 07:52:59 am
Thats not true.

My DS2D1547 serial number DS2072A scope when it was a 2072A from the factory showed hardware as 2.0... After using your old keygen mod with new firmware, it still shows my serial number correctly *and* the Hardware version still shows 2.0.
I'm pretty sure zombie28 is correct. "2.0" is just what you see when you press Utility -> System -> System Info, but it's not the full hardware version number: 1.0.2.0.2 is the actual number. If not, what exactly do you see when you look at the Extended Info (not Standard)? If you don't know how to see it, instructions are here (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684) (you will see your full software and FPGA versions as well).

My bad, i was not beware of this hidden system info differs then the original.
After doing the hidden menu trick i start to see the info below;
Sw 00.02.00.00.04
Hw 1.0.2.0.2
Spu 03.01.09
Wpu 00.07.01
Ccu 12.29.00
Mcu 02.13
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sigxcpu on January 20, 2014, 08:33:16 am


AFAIK HW version '2.0' is not Rigol's term, it's just used on this forum to describe new version of DS2k(A) PCB. The newest HW version displayed by DS2kA scopes I've seen so far is 1.0.2.0.2 and it doesn't change after firmware upgrade (take a look at Flipp's screenshots before and after update).

It is Rigol's term actually. The normal info screen shows "2.0". The Menu7-6-7 trick shows "1.0.2.0.2".

Edit: Oops, that's for DS2072, without A.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pascal_sweden on January 20, 2014, 09:31:26 am
Has it been confirmed already that the HW design is identical between DS2072A and DS2302A?

I know that it has been confirmed between DS2072 and DS2202, but not for the A series AFAIK, and especially not for the new 300 MHz variant.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on January 20, 2014, 10:16:01 am
It is Rigol's term actually. The normal info screen shows "2.0". The Menu7-6-7 trick shows "1.0.2.0.2".

Yes, Rigol uses inconsistent version names - let's call them 'marketing HW version' and 'technical HW version'. However, the bottom line is that neither of them changes after patched firmware flashing.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: kado on January 20, 2014, 10:34:31 am
Hello to all , my first post:

I want to say many  thanks to zombie28 and cybernet for their great work
at custom FW and keygen!!!
All goes fine after flashing and type in the key (DSHH).

I still have one question:
 - must I recal both channel with the buid in autocal functin?
 - is it recommended to put an 50 Ohm resistorload to the input-bnc?

73's Karsten
Title: Re: hacking dp832
Post by: zombie28 on January 20, 2014, 02:24:35 pm
Hello to all
I make some try and I done dump of my dp832 I see nand flash + spi flash +24c16 eeprom
I can't find serial number anywhere,24c16 seem to contain some calibration data, spi flash W25X40 some data like encrypted I think is here serial,and in nand flash I see more or less only first 3-4mb filled and seem like the DP800Update.GEL file something interesting found multiple refers to all model of dp800 series so I think changing serial will hack 832 into 832a since all the board same and are marked 832a I post some pictures

Will you share your memory dumps with us? If so, what firmware version do you have? I'm analyzing 1.08 GEL atm to find out the new license codes format.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: aadamson on January 20, 2014, 03:05:31 pm
Thats not true.

My DS2D1547 serial number DS2072A scope when it was a 2072A from the factory showed hardware as 2.0... After using your old keygen mod with new firmware, it still shows my serial number correctly *and* the Hardware version still shows 2.0.
I'm pretty sure zombie28 is correct. "2.0" is just what you see when you press Utility -> System -> System Info, but it's not the full hardware version number: 1.0.2.0.2 is the actual number. If not, what exactly do you see when you look at the Extended Info (not Standard)? If you don't know how to see it, instructions are here (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684) (you will see your full software and FPGA versions as well).

Thanks for that... I stand corrected...

originally I thought he was saying that v2 hardware wasn't shown anywhere.  Indeed is it in the *regular* system info menu output.

However after doing as you suggested, I now see the other info.

software 00.02.01.00.03
hardware 1.0.2.0.2
FPGA
    SPU 03.01.09
    WPU 00.07.01
    CCU 12.29.00
    MCU 02.13

Thanks for clarifying and sorry for the confusion.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 20, 2014, 03:15:52 pm
I still have one question:
 - must I recal both channel with the buid in autocal functin?
 - is it recommended to put an 50 Ohm resistorload to the input-bnc?
Read from here onwards https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg371723/#msg371723 (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg371723/#msg371723)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pillex on January 20, 2014, 11:05:02 pm
Hello,

I am new to the forum. Since I have received my DS2202A I am willing to break the waranty seal and contribute by providing the memory dumps using a FT2232 based JTAG.
From the posts begging from page 164 I understood that "tirulerbach" is the man to send the memory dump.

My scope still have a few hours left to test all the nice trigger and decode features.

Question to the experts: Does the fact that the trial is still active will influence the memory dump?

Thanks and cheers,
Pillex
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 20, 2014, 11:30:05 pm
From the posts begging from page 164 I understood that "tirulerbach" is the man to send the memory dump.
Just upload it to a file hosting site and link to the file in the forum so everyone working on it can have a look.
Several members has uploaded to https://mega.co.nz and posted the lniks in this topic.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Git on January 21, 2014, 02:36:25 pm

that's the 2 digits after the ds2d15, right?
then I also have one from week 46

Is it possible they are algorithmically generating ECC keys etc from digits 7 & 8 of the serial number if that is week number?

Git
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cidcorp on January 21, 2014, 02:42:46 pm

Well after receiving my DS1074Z-S (I a DS2102, but really need the extra 2 channels) I decided to try as is out of the box using the riglol keys generated.
Everything installed without a problem - all option installed.  I didn't reread the thread so I missed the little detail about the 500uV Vert unlock not working.
Sooo I installed the DSFR instead of the DSER (which I believe is everything except the 500uV)... if someone can confirm.

I will be doing the uninstall and reinstall with DSER to clear up a trace off set problem (goes to top of display and can't be brought down) when on the lowest vertical setting.

BTW this little guy is sooo cute.  Like a mini-me of the 4000 or 2000 scopes lol.

[1] Two questions though relating to the DS1000Z's - is there an EXTENDED system/info button trick like the DS2000 ie F7-F6-F7-etc (sorry going from memory which is horrible) for
HW revision FW revision info?
[2] Am I missing something or are both Left and Right menus permanently on screen???
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: granz on January 21, 2014, 02:43:55 pm

AFAIK HW version '2.0' is not Rigol's term, it's just used on this forum to describe new version of DS2k(A) PCB. The newest HW version displayed by DS2kA scopes I've seen so far is 1.0.2.0.2 and it doesn't change after firmware upgrade (take a look at Flipp's screenshots before and after update).

Actually, Rigol does use the "2.0" term on the PCB silkscreen, but I assume that is just to specify the PCB revision.  I would guess that the hardware version shown (someone said set by the smd resistors), is based on the populated components.  So, even with the "2.0" PCB you may get different 1.0.2.0.x numbers.  Perhaps this is how they are trying to get away with a DS2302A model when they didn't sell a DS2302 model (tweaked input stage, etc.).  Anyhow, the 1.0.2.0.x number is the one that really matters and as you pointed out, it doesn't change with firmware changes.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on January 21, 2014, 03:01:01 pm
[1] Two questions though relating to the DS1000Z's - is there an EXTENDED system/info button trick like the DS2000 ie F7-F6-F7-etc (sorry going from memory which is horrible) for
HW revision FW revision info?
[2] Am I missing something or are both Left and Right menus permanently on screen???

#1 - I asked this question and no one could answer.  One person was able to do it, but he can't remember exactly how.
#2 - They are permanently on the screen, they don't hide.
Title: Re: hacking dp832
Post by: Wall-E on January 21, 2014, 11:35:25 pm
Will you share your DP832 memory dumps with us? If so, what firmware version do you have? I'm analyzing 1.08 GEL atm to find out the new license codes format.
                   zombie28
[/quote]
It's now Firmware version  00.01.09 for the DP800 Series including the DP832 (non A).  And I understand that it's not good news with all options lost, and no way to go back to FW 06, or 08.

Note: This Firmware has been provided to DP832 (non A) users by Rigol for those that had requested a FW Update for their units.

Ref.  RIGOL DP832 Power Supply - firmware upgrade, « Reply #36 on: Yesterday at 03:38:23 AM »   Although I don't think Rigol supplied this particular person his FW 09.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 21, 2014, 11:51:16 pm
[1] Two questions though relating to the DS1000Z's - is there an EXTENDED system/info button trick like the DS2000 ie F7-F6-F7-etc (sorry going from memory which is horrible) for
HW revision FW revision info?

#1 - I asked this question and no one could answer.  One person was able to do it, but he can't remember exactly how.

Seeing as how the DS2000/DS4000/DS6000 all use the same F7-F6-F7 routine to get to the Project Menu, it seems the DS1000Z (the latest member of the UltraVision line) would do as well.
Title: Re: hacking dp832
Post by: Sparky on January 22, 2014, 06:18:01 am
It's now Firmware version  00.01.09 for the DP800 Series including the DP832 (non A).  And I understand that it's not good news with all options lost, and no way to go back to FW 06, or 08.

Note: This Firmware has been provided to DP832 (non A) users by Rigol for those that had requested a FW Update for their units.

Ref.  RIGOL DP832 Power Supply - firmware upgrade, « Reply #36 on: Yesterday at 03:38:23 AM »   Although I don't think Rigol supplied this particular person his FW 09.

In the post you reference, Sebastian states "the Riglol Keys don't work" --- which is no different from 01.08 where they didn't work either (and why people downgraded to 01.06 to install the keys and then upgraded to 01.08). 

How exactly are you concluding "all options lost"?
Title: Re: hacking dp832
Post by: AndersAnd on January 22, 2014, 08:15:30 am
It's now Firmware version  00.01.09 for the DP800 Series including the DP832 (non A).  And I understand that it's not good news with all options lost, and no way to go back to FW 06, or 08.

Note: This Firmware has been provided to DP832 (non A) users by Rigol for those that had requested a FW Update for their units.

Ref.  RIGOL DP832 Power Supply - firmware upgrade, « Reply #36 on: Yesterday at 03:38:23 AM »   Although I don't think Rigol supplied this particular person his FW 09.
In the post you reference, Sebastian states "the Riglol Keys don't work" --- which is no different from 01.08 where they didn't work either (and why people downgraded to 01.06 to install the keys and then upgraded to 01.08). 

How exactly are you concluding "all options lost"?
He wrote that you can't downgrade to FW 06 or 08 anymore after upgrading to FW 09. So he can't install any options by downgrading to FW 06 like you suggest. So that's probably why he wrote all options lost.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Git on January 22, 2014, 01:36:00 pm

Seeing as how the DS2000/DS4000/DS6000 all use the same F7-F6-F7 routine to get to the Project Menu, it seems the DS1000Z (the latest member of the UltraVision line) would do as well.


Unlikely, the DS1000Z family doesn't have an F7 button, unless that is what you call the 'Next Page' pale blue button at the bottom?

Git
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 22, 2014, 01:50:42 pm
Unlikely, the DS1000Z family doesn't have an F7 button, unless that is what you call the 'Next Page' pale blue button at the bottom?

Possibly. It might also just be the bottom two selection buttons - so F6-F5-F6 on the DS1000Z.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: idpromnut on January 22, 2014, 02:19:59 pm
Here's a question for you all: I just received my DS2070A and I will do a dump of the memory. But, I also ordered the advanced triggering package, but it was installed on the scope when I received it. Is there a way of recovering the license key (in case I do something silly and wipe/uninstall all the options by mistake)?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sled on January 22, 2014, 02:43:37 pm
yay! just received my DS2072A, I'm going to take a dump tonight :P

It's Week 42 :)

Code: [Select]
Model:  DS2072A
Serial:  DS2D1542xxxxx
Software Version: 00.02.00.00.04
Hardware Version: 1.0.2.02
FPGA Version:
   SPU 03.01.09
   WPU 00.07.01
   CCU 12.29.00
   MCU 02.13
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on January 22, 2014, 05:03:32 pm
the 300 MHz option doesn't work I think
at least device doesn't change to 2302 or 1 ns TB

:)


(edit)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on January 22, 2014, 06:41:12 pm
I'm going to take a dump tonight

Same here; Mexican food for lunch.

Anyone have the DP832 00.01.09 firmware?  What does it fix?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 22, 2014, 06:44:51 pm
Anyone have the DP832 00.01.09 firmware?  What does it fix?
Maybe the only thing it fixes is the possibility to downgrade, to stop the keygen hack?
They already stopped the keys from working in 08, but people could still downgrade to 06 and use the keys, so that fix didn't really work for them. So now they have stopped the possibility of downgrading in 09.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on January 22, 2014, 06:51:06 pm
I think you're right.

After looking for about 250ms, I found this thread (https://www.eevblog.com/forum/testgear/rigol-dp832-power-supply-firmware-upgrade/ (https://www.eevblog.com/forum/testgear/rigol-dp832-power-supply-firmware-upgrade/)) which is generally not positive about the 09 firmware.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: rsivan on January 22, 2014, 07:50:36 pm
Hello
If someone can read the spi flash 25x40 of dp832a; I can try to turn my 832 into 832a, because fw is same.
Also other option is a full cloning spi flash + nand flash from 832a to manually program in a 832.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on January 22, 2014, 07:59:57 pm
After looking for about 250ms, I found this thread (https://www.eevblog.com/forum/testgear/rigol-dp832-power-supply-firmware-upgrade/ (https://www.eevblog.com/forum/testgear/rigol-dp832-power-supply-firmware-upgrade/)) which is generally not positive about the 09 firmware.

I would generally be suspicious of any Rigol firmware that comes in two separate sections to load - one following the other: you can pretty much be certain that the bootloader is being changed.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: rsivan on January 22, 2014, 08:09:15 pm
I compared the new 1.09 bootloader of dp800, and almost same file I found in 25x40 spi flash so: bootloader is in 25x40 confirmed!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tirulerbach on January 22, 2014, 09:24:52 pm
yay! just received my DS2072A, I'm going to take a dump tonight :P

Please contact me, if you have your dumps ready...
Title: Re: hacking dp832
Post by: Sebastian on January 22, 2014, 10:13:22 pm
It's now Firmware version  00.01.09 for the DP800 Series including the DP832 (non A).  And I understand that it's not good news with all options lost, and no way to go back to FW 06, or 08.

Note: This Firmware has been provided to DP832 (non A) users by Rigol for those that had requested a FW Update for their units.

Ref.  RIGOL DP832 Power Supply - firmware upgrade, « Reply #36 on: Yesterday at 03:38:23 AM »   Although I don't think Rigol supplied this particular person his FW 09.

In the post you reference, Sebastian states "the Riglol Keys don't work" --- which is no different from 01.08 where they didn't work either (and why people downgraded to 01.06 to install the keys and then upgraded to 01.08). 

How exactly are you concluding "all options lost"?

The trick with getting the options in 1.06 and then upgrading to 1.08 never worked for me. If I would install all the options in 1.06 and upgrade to 1.08 everything would be lost, not just the trigger option as other people here report for there units. If I would then go back to 1.06 the options would be there again without entering the codes again.
FW1.09 is essentially the same as 1.08, none of the bugs are fixed, the only difference is that you can not flash older versions anymore because of the new bootloader,
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on January 23, 2014, 01:30:28 am
After looking for about 250ms, I found this thread (https://www.eevblog.com/forum/testgear/rigol-dp832-power-supply-firmware-upgrade/ (https://www.eevblog.com/forum/testgear/rigol-dp832-power-supply-firmware-upgrade/)) which is generally not positive about the 09 firmware.

I would generally be suspicious of any Rigol firmware that comes in two separate sections to load - one following the other: you can pretty much be certain that the bootloader is being changed.
Yeah, I'm plenty suspicious.  I feel for Rigol; they're in a hard place right now.  I guarantee there is an engineer or two on their staff that raised a bit of a stink about how easy this stuff would be to compromise, and he was probably dismissed out of hand, and laughingly compared to "Dwight" in the local production of "The Office."

I will admit to using the keygens.  I will also admit that if they fix the holes and produce firmware that i can't do without, I will upgrade to that firmware, even if it means losing the options I've hacked for myself.  The thing is, I purchased the options I needed, and hacked the ones I want to play with.  If any of those options I don't need become options I do need, then I'll buy those, too.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: thetooth on January 23, 2014, 10:10:20 am
If any of those options I don't need become options I do need, then I'll buy those, too.
This, i ended up ordering the deep memory option because i do a lot of very large serial captures. I think anyone who uses hacked options at work is just asking for trouble, i'd hate to be the guy who keeps finding "glitches" on a high speed bus because of some ADC error caused by messed up software. :palm:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: diyaudio on January 23, 2014, 08:03:44 pm
Hi all

I just bought a DS2072A (an upgrade from my siglent) and it cost me $1,300 with shipping to south africa, yes it wrecked my wallet.

vie been learning the in and outs of the scope and haven't touched the decoders yet, my time trial is almost over about 3 hours left! can anyone give me a cost breakdown of the decoders ??

why did Rigol not make the time-trial run when in use only.  !!??






Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on January 23, 2014, 09:25:13 pm
that's really odd, my trial time decreased when it was online, not while switched off and with plug removed :o
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on January 23, 2014, 09:53:21 pm
I think he means, in use of the features. Just turn on the scope, leave it on, and your trial will disapear, without using them..
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on January 23, 2014, 10:19:14 pm
ahhh ok :D
misunderstood it then ^^
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: diyaudio on January 23, 2014, 10:30:01 pm
I think he means, in use of the features. Just turn on the scope, leave it on, and your trial will disapear, without using them..

yeah. that's what I meant.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pillex on January 24, 2014, 01:17:17 am
Finally I managed to dump the memory of my DS2202A!
I was using a OpenOCD, FTDI2232D based JTAG device, pulling RDI, TMS, TCK and TDO up with 100k to 3V3.

I have uploaded the files to https://mega.co.nz/#!jkRihazT!L2KUHS3tb9nUPgqU1UBUD5gWXdsmSG4Wht7jS3s_HXo
hoping that the experts can send me some keys to enable all features. Furthermore I hope this post will contribute to a purely SW based unlocking solution in the future.

Cheers
Pillex
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cepphus on January 24, 2014, 11:21:10 am
OK,

I have an update after trying some more today.  I've gotten the Altera USB-Blaster JTAG adapter to work with the blackfin tool chain.  It seems to work fine on a 32-bit Linux box.

I now have a working gdb interface after starting bfin-gdbproxy and connecting to it.  I can freely access memory and registers at this point.

If anyone else is looking for a JTAG interface for this, the knock-off Altera one (called "mini") is < $10 on eBay (US).  Working on memory dump now.

Is this the JTAG that would work? I just got my 2072A and would just love to open it and play

http://www.ebay.com/itm/150943500360 (http://www.ebay.com/itm/150943500360)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Git on January 24, 2014, 01:01:19 pm
Finally I managed to dump the memory of my DS2202A! ...
I have uploaded the files to...

.tar.xz ?. I have seen .tar.gz, but nothing on windows seems to recognize .xz. I tried renaming it to .tar and .tar.gz. What format is the archive please?. A search on google found linux people asking the same question :)

...

Later - 7z opens and extracts it. Should ds2k_00_sdram.bin have length of 128MB ?

Git
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pillex on January 24, 2014, 01:13:46 pm
@Git: xz might be more common in the Linux world --> http://en.wikipedia.org/wiki/Xz (http://en.wikipedia.org/wiki/Xz)

So 7zip should do the job for windows.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: granz on January 24, 2014, 02:26:13 pm

Is this the JTAG that would work? I just got my 2072A and would just love to open it and play

http://www.ebay.com/itm/150943500360 (http://www.ebay.com/itm/150943500360)

Yes, that's the one.  In the JTAG connection diagram posted a little while back I used the second setup (pull-ups on TRST and SRST lines -- don't connect these to the programmer at all), but either way should work for you.

Good luck!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on January 24, 2014, 02:27:59 pm
and that one is fairly fast?
I guess it's better then to buy this, since I dont know how to use my ft2232h card..
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: granz on January 24, 2014, 02:37:56 pm
and that one is fairly fast?
I guess it's better then to buy this, since I dont know how to use my ft2232h card..

If I remember right it took about 15-20 minutes to dump 32MB of DRAM.

For some unknown reason I couldn't communicate with it from the blackfin toolchain on 64-bit Linux or 64-bit Windows 7, so just keep that in mind.  It worked fine once I tried it on a fresh install of Lubuntu 32-bit.  I didn't investigate further after getting the memory dump.  I believe another forum member had a similar issue with a different programmer, so I believe it's something in the blackfin version of UrJTAG.  Just keep it in mind if you want to minimize wasted time.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on January 24, 2014, 02:52:01 pm
good to know, all my computers use 64bit os, so I guess I'll try from an virtualmachine then
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: granz on January 24, 2014, 02:57:52 pm
good to know, all my computers use 64bit os, so I guess I'll try from an virtualmachine then

Good thing to try.  If it works out for you, definitely post about your success, because I'm sure that would make it easier for lots of folks.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Posterisan on January 24, 2014, 05:05:04 pm
Here is my Memory Dump from Rigol DS2072A !

Serial #: DS2D1542.....

https://mega.co.nz/#!IEdgVbiR!7ylPllecGTVCT54WldU8zGFLoa4E1niOeGCFLcnEPfI (https://mega.co.nz/#!IEdgVbiR!7ylPllecGTVCT54WldU8zGFLoa4E1niOeGCFLcnEPfI)

took me hours to get the dump - my segger jlink does not work ;-((

Andre
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on January 24, 2014, 05:11:16 pm
Which firmware version is people having when taking a dump?, I want to upgrade, but not sure if one should dump before and after?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ZeroAviation on January 24, 2014, 05:53:09 pm

Is this the JTAG that would work? I just got my 2072A and would just love to open it and play

http://www.ebay.com/itm/150943500360 (http://www.ebay.com/itm/150943500360)

Yes, that's the one.  In the JTAG connection diagram posted a little while back I used the second setup (pull-ups on TRST and SRST lines -- don't connect these to the programmer at all), but either way should work for you.

Good luck!

Excellent! I'm going to pick one up as well. (2-4 week delivery time sucks)

I assume I should restore factory firmware before doing the dump?

-Matt
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: eurofox on January 24, 2014, 08:52:22 pm
Hi Gary,
short question, didn't follow the thread for a while: why do you need to downgrade? Don't the keys work for V. 01.08.00 anymore?
Kind regards
Gunb

He wrote it five messages before. See Reply #2463.

OK, thx!

Hmm, slowly this thread seems to need a TOC  ;D

Hi,

Got my DSA 815-TG yesterday :)

I'm very happy with it, I upgrade it to the latest firmware version without problem and apply the options with the magic keygen without problems, now I leave it on to "clean" the trial versions, I suppose they will expire and disappear, it will be verified tomorrow.

eurofox
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tirulerbach on January 24, 2014, 09:22:36 pm
Which firmware version is people having when taking a dump?, I want to upgrade, but not sure if one should dump before and after?

First make an upgrade, then make the dump...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on January 25, 2014, 02:33:04 am
Which firmware version is people having when taking a dump?, I want to upgrade, but not sure if one should dump before and after?
I might take a dump before or after the upgrade, just depends on the time of day.
But if you want to know if you should dump before or after, I would say during - get it started then go take a dump.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: gbot on January 25, 2014, 03:02:42 am
Hey All,

I am ready to pull the trigger on a DS2102A. Has anyone confirmed that the innards of the 2072A to the 2202A are identical? Would I be able to view 200MHz signals without issue with the 2102A - assuming the appropriate "patches" have been applied? I would be more than willing to dump the memory to help the cause.


Cheers!

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bluesmoke on January 25, 2014, 10:45:54 am
I would say during - get it started then go take a dump.
... It is hard to resist! :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tirulerbach on January 25, 2014, 12:26:58 pm
good to know, all my computers use 64bit os, so I guess I'll try from an virtualmachine then

Good thing to try.  If it works out for you, definitely post about your success, because I'm sure that would make it easier for lots of folks.

I made my dumps on a 64 bit systems with no problems at all. I even don't think that 32/64 bit host makes any differences for a cross-toolchain. I suppose that the mentioned problems on that particular case had another cause and the conclusion that it is a 64 bit issue is simply wrong.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: granz on January 25, 2014, 02:48:07 pm

I made my dumps on a 64 bit systems with no problems at all. I even don't think that 32/64 bit host makes any differences for a cross-toolchain. I suppose that the mentioned problems on that particular case had another cause and the conclusion that it is a 64 bit issue is simply wrong.

Well, I completely agree that it *shouldn't* make any difference at all.  The blackfin tools are literally the same pre-compiled binaries no matter what host you are on (they are 32-bit binaries).  The USB kernel-space driver could be very slightly different or something stupid with ioctl() is going on (this is my guess).  bfin-jtag/bfin-gdbproxy gets to the USB JTAG-cable device in this order: libftdi(user-space library)--->libusb(user-space library)--->usbfs(kernel-space driver).  Examining the bfin-jtag and bfin-gdbproxy binaries also shows that they have statically linked libusb and libftdi and they may have a problem such as this in the versions they used:

http://stackoverflow.com/questions/9258280/whats-different-between-compiling-in-32bit-mode-and-64bit-mode-on-64bit-os-abou (http://stackoverflow.com/questions/9258280/whats-different-between-compiling-in-32bit-mode-and-64bit-mode-on-64bit-os-abou)

I've had these types of issues in the past with my own software at work.  I guess it's not really fair to say it's a 64/32 bit issue per se, probably more like a kernel compatibility configuration issue.  It's just easier to say 64 or 32-bit.

I'm curious: what variety/version of Linux did you use?

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Co6aka on January 25, 2014, 05:40:05 pm
I suppose that the mentioned problems...had another cause...

FWIW, most of the 32-on-64 issues I've encountered turned out to be multiarch-related, and tracking them down and fixing them was not often straightforward... |O At least one was an upstream issue, which eventually got fixed; stuff just started working one day, immediately following an update. (Sometimes it's the other way around too... |O) Typically stuff just didn't work or worked incorrectly, with no or little indication of why. Sometimes running GUI apps from the terminal provides a hint, as does pouring over the logs.

(One of my favorite source code comment-gems is "Error reporting could be better." :-DD No, REALLY?)

...statically linked libusb and libftdi...

"DLL Hell" of the Linux world.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: thinwire on January 25, 2014, 10:46:32 pm
Rigol DS2000(A) series oscilloscopes: When installing an option with usbtmc :SYSTem:OPTion:INSTall or uninstall all options with :SYSTem:OPTion:UNINSTall I detected that all system settings are reset to the default  :-- . To avoid this I wrote a linux command line utility to install/uninstall options with restoring system settings. It is based on libusb-1.0 and does not need a usbtmc kernel driver.

Install an option:
Code: [Select]
rigoltmc -o XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX

Uninstall all options:
Code: [Select]
rigoltmc -u

Identify the device:
Code: [Select]
rigoltmc -i
This should return something like:

RIGOL TECHNOLOGIES,DS2072A,DS2D15XXXXXXX,00.02.00


Have fun!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pascal_sweden on January 27, 2014, 12:43:40 pm
Hey All,

I am ready to pull the trigger on a DS2102A. Has anyone confirmed that the innards of the 2072A to the 2202A are identical? Would I be able to view 200MHz signals without issue with the 2102A - assuming the appropriate "patches" have been applied? I would be more than willing to dump the memory to help the cause.


Cheers!

Actually would like to know if the DS2072A is identical to DS2302A. But nobody has bought a DS2302A yet to confirm. Who has some money to spare and go buy one? =)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on January 27, 2014, 01:35:24 pm
To bad the distributor here is so secret about pricing, if I had know that the price difference was so low between 2202 and 2302, I would probably go for that instead of the 2202 that I bought, but i had to ask for prices as I found which products was available, was not able to get an complete list, because "dollar could change", yuck...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pascal_sweden on January 27, 2014, 04:19:37 pm
About 340 euro difference on Batronix.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on January 27, 2014, 04:34:12 pm
Well, you listed some swedish company with other prices, like 2k in difference..  i think.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: gbot on January 27, 2014, 05:24:45 pm
I'd be happy to know if the 2202A hardware is identical to the 2072A hardware.

Thanks!



Actually would like to know if the DS2072A is identical to DS2302A. But nobody has bought a DS2302A yet to confirm. Who has some money to spare and go buy one? =)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 27, 2014, 06:08:30 pm
I'd be happy to know if the 2202A hardware is identical to the 2072A hardware.
It is.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: gbot on January 27, 2014, 06:55:45 pm
Thank you!

I'd be happy to know if the 2202A hardware is identical to the 2072A hardware.
It is.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sled on January 28, 2014, 02:41:05 am
Watch out, here comes the dump: https://mega.co.nz/#!wwVi2YSZ!3o7nhjAZQ4RGAE4dks3HVjABZuFwiETEr78_JH2w-7s

Scope: DS2072A, fresh out of the box, produced in week 42.
JTAG Adapter: Altera USB Byteblaster Rev. C
Time to dump the whole memory in one piece: ~2 hours

Interestingly it was much quicker to dump the memory in pieces of 32M (took about 20minutes)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 28, 2014, 07:02:30 am

Is this the JTAG that would work? I just got my 2072A and would just love to open it and play

http://www.ebay.com/itm/150943500360 (http://www.ebay.com/itm/150943500360)

Yes, that's the one.  In the JTAG connection diagram posted a little while back I used the second setup (pull-ups on TRST and SRST lines -- don't connect these to the programmer at all), but either way should work for you.

Good luck!
Altera USB-Blaster plug pinout (update)
http://hackingbtbusinesshub.wordpress.com/2011/09/12/usb-blaster-plug-connection/ (http://hackingbtbusinesshub.wordpress.com/2011/09/12/usb-blaster-plug-connection/)

(http://hackingbtbusinesshub.files.wordpress.com/2011/09/altera_usb-blaster_jtag_pinout.jpg)

(http://hackingbtbusinesshub.files.wordpress.com/2011/09/usb_blaster_1c12_board_schematic_131.png)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sled on January 28, 2014, 01:49:06 pm
here are some pics from my setup with the usb blaster,

Color Coding:

The TRST and SRST (white and violet) are NOT connected to the JTAG cable, they're only pulled high on the breadboard with the pull up resistors)

Gray: TCK
Green: TMS
Blue: TDO
Brown: TDI
Orange & Black: GND
Red: VCC (+3.3V)

(The wire on the breadboard that looks gray, is actually white!)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Flipp on January 28, 2014, 05:02:46 pm
What jtag  speed is possible with the fake altera blaster?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on January 28, 2014, 08:27:42 pm
Watch out, here comes the dump: https://mega.co.nz/#!wwVi2YSZ!3o7nhjAZQ4RGAE4dks3HVjABZuFwiETEr78_JH2w-7s

Scope: DS2072A, fresh out of the box, produced in week 42.

Thank you for your dump - finally we have two dumps from different DS2072A scopes produced in the same week. The keys in these dumps are different, so it seems highly probable that every unit has its own keys. Consequently, it won't be possible to use the new keygen without extracting keys from the scope's memory (either flash or DRAM).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: diyaudio on January 28, 2014, 09:36:07 pm

Is this the JTAG that would work? I just got my 2072A and would just love to open it and play

http://www.ebay.com/itm/150943500360 (http://www.ebay.com/itm/150943500360)

Yes, that's the one.  In the JTAG connection diagram posted a little while back I used the second setup (pull-ups on TRST and SRST lines -- don't connect these to the programmer at all), but either way should work for you.

Good luck!
Altera USB-Blaster plug pinout (update)
http://hackingbtbusinesshub.wordpress.com/2011/09/12/usb-blaster-plug-connection/ (http://hackingbtbusinesshub.wordpress.com/2011/09/12/usb-blaster-plug-connection/)

(http://hackingbtbusinesshub.files.wordpress.com/2011/09/altera_usb-blaster_jtag_pinout.jpg)

(http://hackingbtbusinesshub.files.wordpress.com/2011/09/usb_blaster_1c12_board_schematic_131.png)


bought one. :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: granz on January 28, 2014, 09:36:31 pm
here are some pics from my setup with the usb blaster,

Color Coding:

The TRST and SRST (white and violet) are NOT connected to the JTAG cable, they're only pulled high on the breadboard with the pull up resistors)

Gray: TCK
Green: TMS
Blue: TDO
Brown: TDI
Orange & Black: GND
Red: VCC (+3.3V)

(The wire on the breadboard that looks gray, is actually white!)

Nicely done!  That is great that you posted pictures.  I tried to explain many times that you don't need to (shouldn't!) connect TRST and SRST to the JTAG cable if you have pull-ups on those, so I'm glad you have validated this--there seemed to be a lot of confusion.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: granz on January 28, 2014, 09:38:27 pm
What jtag  speed is possible with the fake altera blaster?

Hardware-wise I believe it's fixed at 12 MHz, but the blackfin UrJTAG stuff says something about inserting wait-states if I remember right...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on January 28, 2014, 09:39:40 pm
Is there any reason why one pull-up resistor is 3k9 and the other 10k, why two different values? Or is this just what cybernet had at hand when he hooked it up?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Co6aka on January 28, 2014, 09:49:32 pm
The keys in these dumps are different, so it seems highly probable that every unit has its own keys.

Generated from the serial number perhaps? Anyway... How does it look patching the firmware to dump the key on the screen? Or out via some other path? Also, wondering how and at what point they load the key (and sernum) because maybe there's some hidden factory function just for that purpose. (Also, as a service issue, how might they deal with a corrupted sernum and/or key?)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: granz on January 28, 2014, 09:51:30 pm
Is there any reason why one pull-up resistor is 3k9 and the other 10k, why two different values? Or is this just what cybernet had at hand when he hooked it up?

I don't remember what I used for pull-ups, might have been two 10k.  It would only matter if that line had a pull-down on it already of something like 10k (think voltage divider etc.) because it is meant to be driven high by the jtag cable.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on January 28, 2014, 10:36:27 pm
The keys in these dumps are different, so it seems highly probable that every unit has its own keys.

Generated from the serial number perhaps?

I think so, but only Rigol knows the algorithm.

Quote
Anyway... How does it look patching the firmware to dump the key on the screen? Or out via some other path?

Yes, I'm thinking about it and cybernet was coughing recently about something like that too...

Quote
Also, wondering how and at what point they load the key (and sernum) because maybe there's some hidden factory function just for that purpose. (Also, as a service issue, how might they deal with a corrupted sernum and/or key?)

IIRC the keys are stored in two flash locations - if one fails, then the second copy is used. The keys are stored in encrypted form (using RC5 algorithm) and protected by ECDSA with quite a long key (256 bits or so).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Co6aka on January 29, 2014, 03:07:05 am
Also, wondering how and at what point they load the key (and sernum) because maybe there's some hidden factory function just for that purpose. (Also, as a service issue, how might they deal with a corrupted sernum and/or key?)

IIRC the keys are stored in two flash locations - if one fails, then the second copy is used. The keys are stored in encrypted form (using RC5 algorithm) and protected by ECDSA with quite a long key (256 bits or so).

I meant, when are they first programmed to the scope during the manufacturing process, and how might they be restored/replaced during servicing... Let's think about this as if we're a manufacturer building them and servicing them. Would we pre-program the SN and KEY into the chips before they're soldered, or after the scope comes out of assembly? If after, how would we program them? Also, if servicing a scope, if we had to do a board swap how would we program the instrument's SN and KEY to the new board? Seems logical that we'd want some straightforward time-efficient way to enter SN and KEY into an instrument, so... :-//
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: poida_pie on January 29, 2014, 04:17:18 am
What chances are there to patch a firmware so that it outputs the key and serial when you send it
"*IDN?". That would be good.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: chebeba on January 29, 2014, 08:29:21 am
Quote from: zombie28
The keys in these dumps are different, so it seems highly probable that every unit has its own keys.

Generated from the serial number perhaps?
I think so, but only Rigol knows the algorithm.

Does http://www.rigol.com/account/user.php?act=license (http://www.rigol.com/account/user.php?act=license) have anything to do with this?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NikWing on January 29, 2014, 08:47:51 pm
Thank you for your dump - finally we have two dumps from different DS2072A scopes produced in the same week. The keys in these dumps are different, so it seems highly probable that every unit has its own keys. Consequently, it won't be possible to use the new keygen without extracting keys from the scope's memory (either flash or DRAM).

I expected that, it proves why it didn't work with mine

btw, sorry if this was explained already, but the 300 MHz (untested) option doesn't seem to work
does it mean that it's not implemented with an option?

somehow 12 MHz JTAG speed feels like the 5 MHz in the how-to, 8 MHz seem faster than 12 (and 5)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Pehtoori on January 29, 2014, 09:28:13 pm
Got TIAO JTAG adapter now. I hope I have time to dump at weekend. One more week 42 dump in making :)

42, 42, 42, something is hidden here ...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: nmz787 on January 31, 2014, 07:43:14 am
Hi, using a site like this, is it possible to disable 500uV mode? I didn't know about the uncalibrated offset.
http://riglol.3owl.com/ (http://riglol.3owl.com/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: nmz787 on January 31, 2014, 08:31:37 am
This and the subsequent post mention an offset that self-cal doesn't fix:
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg346806/#msg346806 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg346806/#msg346806)

I plugged the signal generator into the input, and indeed with 0mV offset on generator and 20mV PP, you can easily see the signal isn't centered on 0 (not just in 500uV mode either).

Edit: I've got a DS1104Z
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on January 31, 2014, 01:56:47 pm
nmz787 - use the scpi uninstall command (somebody posted a tool to do this not long ago) and then reboot your scope.  Then reinstall a new key without the 500uv option.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: RX_Buffer[Broken]; on January 31, 2014, 05:04:29 pm
Hi All, (noob)

I have been watching the DS2xxxn topic for a few weeks , I have Z's Patched F/W on a what was a 2072A.  "Nice Job Z"
However not wanting to turn up to the party empty handed (linux, Jtag & sharing Dumps are not my redeeming features) So I have been investigating other routes.

I have found a DS2xxx  SCPI command that appears un-documented and may be of interest if still supported in f/w.
Having tried on my own unit I get a buss time out error, maybe patched F/W or maybe that all options are already installed, unsure??
It would be interesting to know what reply you get from a standard unit? or if anyone already knows about this CMD already ?

SYSTem:OPTion:VALid?



Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MrsR on January 31, 2014, 11:50:55 pm
Hi! Guys,
I am having problems with my RIGOL 2072 DSO modified to 300MHz.
Is there a way to turn it back into a 70 or even a 200MHz model.
I used the 3owl site.
The fault is that I get  screen messages "Parameter out of Range" when I know it isn't.
I did the same tests with works AGILENT scope no problems.
Also I can't put it into Peak Detect well I can but on using, it jumps to Normal.

Thanks Guys
Rachael :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on February 01, 2014, 12:14:02 am
Hi! Guys,
I am having problems with my RIGOL 2072 DSO modified to 300MHz.
Is there a way to turn it back into a 70 or even a 200MHz model.
I used the 3owl site.
The fault is that I get  screen messages "Parameter out of Range" when I know it isn't.
I did the same tests with works AGILENT scope no problems.
Also I can't put it into Peak Detect well I can but on using, it jumps to Normal.

Thanks Guys
Rachael :-+
Yes just use the SCPI uninstall command as mentioned several times in this topic.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: stuartk on February 01, 2014, 01:01:27 am
I've had an unanticipated error in Ultra Sigma after placing the codes for my DS2102

The print screen function no longer works. I can still communicate by SCPI.

Uninstalling/reinstalling Ultra Sigma - NI  or the scope made no difference.

Has anyone else noticed this behavior? I wonder if it's a consequence of mangled serial number syndrome.

Thanks, Stuart
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Marc M. on February 01, 2014, 11:33:48 am
...if servicing a scope, if we had to do a board swap how would we program the instrument's SN and KEY to the new board?...

In the case of Rigol with hardware V1.0 boards - they don't.  At least not the S/N, I can't say how keys are handled as I didn't have any installed.  A while back I sent my scope in to Rigol NA for warranty work.  When I received the repaired scope back, sure enough I had the dreaded corrupted S/N reset to ...001  :--.  I used the serial/model # file I posted earlier to successfully correct the  S/N. 

While verifying my info was still correct, I happened to notice that my horizontal timebase now topped out at 500ps :-+.  I verified that it was indeed sweeping at 500ps/div by applying a 400 MHz signal and making sure it displayed a period of 5 divisions which it did (naysayers see attached pics).  I then re-applied the 300 MHz codes and it retained the 500ps setting.  Finally, I power cycled the scope and it lost the 500 ps setting.  At that point I again uninstalled the options via SCPI and the 500ps sweep rate returned.  I power cycled the scope again and tried sending the uninstall command again (without any active licenses) and it did not activate the 500ps sweep rate.  I didn't notice this behavior until after correcting my serial # and I see at least one other member mentioning having a 500ps time base setting as well.  Throughout this process, my model # has been stuck as DS2302 regardless of what/any licenses installed.  I was running firmware 00.02.01.00.03 with license code DSHH. 

At this point I removed all licenses and reflashed 00.01.01.00.02 firmware.  After power cycling the scope, my model # reverted back to DS2072.  I then applied the old DSA9 license code, power cycled, and the model changed to DS2202 as expected.  I again uninstalled the options and checked the horizontal timebase and sure enough, I had 500ps again.  However, this time the timebase was actually still running at 1ns even when switched to 500ps, just throwing the trigger point off a couple of divisions.  Once again, the 500ps setting disappeared after power cycling the scope.

Next, I reflashed the 00.02.01.00.03 firmware back onto the scope.  After power cycling the model remained DS2072.  I then installed the DSHH codes.  Although all options were installed, the model # remained DS2072.  The 500ps setting returned but again it was still running at 1ns/div. with the offset trigger.

The only obvious difference between when I had real 500ps horizontal rate and the fake 500ps rate was the model number.  So I took a chance and used the snmodfix.exe utility I posted earlier to forcefully change the model # back to DS2302 to see if it had any effect on the 500ps rate. This time around, I was unable to change the model # - it stayed DS2072 even with DSHH applied. I then tried to change both the S/N and model number.  The S/N changed but the model # didn't - still stuck on 2072.  If I reflash .02 firmware and apply the DSA9 key, it changes to 2202.

I've been too busy with other things lately to play further.  At this point it appears that the model # may affect the behaviour of applied keys inferred from having a real 500ps timebase when it was a DS2302 to a 5ns timebase (even with the DSHH key applied) when it's model # is 2072.  Also, it appears that there are certain circumstances where the utility to alter model/serial numbers will fail to do so as other members have experienced.  So far the author doesn't understand why it's failing to work and hasn't been able to replicate the failure on his scope.  The good news is I've confirmed it's capable of a 500ps horizontal time base if we can just determine the mechanism required to invoke it permanently.  As I get some free time I'll experiment further.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on February 01, 2014, 11:52:27 am
The good news is I've confirmed it's capable of a 500ps horizontal time base if we can just determine the mechanism required to invoke it permanently.  As I get some free time I'll experiment further.

Interesting story - but just because the DSO is capable of being forced into providing a function which isn't listed in the specs, doesn't mean it's advantageous in the grander scheme of things to do so. This is evidenced by the fact that the 1ns time base (which is a by-product of the 300MHz option) is fairly buggy.

During the 15 previous months I owned the DS2000, I found it extremely stable - perhaps locking up (i.e. crashing) 3 or 4 times in total over that period. OTOH, after enabling the 300MHz/1ns option, I had that many crashes within a week. Conclusion: the trouble was not worth the small benefit gained.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on February 01, 2014, 08:10:30 pm
What chances are there to patch a firmware so that it outputs the key and serial when you send it
"*IDN?". That would be good.

Done!

https://mega.co.nz/#!MdcEWTgL!0EEmSr-Q6TxaFSsyEmjhRrgqDvFCoXg9K49BalL5Uxc

No need for JTAG memory dumps anymore, just send *IDN? command and you'll get your license encryption keys in response (tested on my DS2072A that has just arrived).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tiagobaracho on February 01, 2014, 08:16:38 pm
Guys... Sorry to bother..
I bought one Rigol DS2072A
It shows Software version 00.02.00 and Hardware version 2.0... Is that possible to use the 200 mhz and high memory settings ?
I have been reading a lot of pages in this thread but i could not find....
Thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: nmz787 on February 01, 2014, 09:19:04 pm
nmz787 - use the scpi uninstall command (somebody posted a tool to do this not long ago) and then reboot your scope.  Then reinstall a new key without the 500uv option.

alank2,
Can you be a bit more specific about the tool. I'm new around here. I found the RUU tool, downloaded NI VISA 5.4, rebooted my PC, and attempted to connect, but then the RUU tool errored out and then crashed on my with an array-out-of-bounds error. (I was clicking connect too fast or something). After entering the correct IP address with the weird prefix and suffix, the :: stuff, it stopped complaining about not being able to find the instrument, and doesn't ask for the IP anymore upon starting the software and clicking connect. Now it just presents a message box "DSO not responding to query and/or command - RUU closing connection"

I'm downloading the UltraSigma installer now from the DS4000 Rigol page... I can't tell from the 'instructions' on RUU (which of course aren't in a README in the .zip) whether this is needed or not.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on February 01, 2014, 09:25:36 pm
Guys... Sorry to bother..
I bought one Rigol DS2072A
It shows Software version 00.02.00 and Hardware version 2.0... Is that possible to use the 200 mhz and high memory settings ?
I have been reading a lot of pages in this thread but i could not find....
Thanks

You can use either my first firmware patch (https://mega.co.nz/#!FFk10SCY!UuWPXyqZwmca00pa2clOth1ryh1Z-AAgJg2yibfoUw0) with old keygen (riglol.3owl.com) or my newest patch from the post above with the new tirulerbach's keygen (if he decides to publish it).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on February 01, 2014, 09:29:34 pm
alank2, Can you be a bit more specific about the tool. I'm new around here.

https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg375454/#msg375454 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg375454/#msg375454)

I don't know much about it, haven't tested it, but it says it can issue an uninstall command...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tiagobaracho on February 02, 2014, 02:30:35 am
Guys... Sorry to bother..
I bought one Rigol DS2072A
It shows Software version 00.02.00 and Hardware version 2.0... Is that possible to use the 200 mhz and high memory settings ?
I have been reading a lot of pages in this thread but i could not find....
Thanks

You can use either my first firmware patch (https://mega.co.nz/#!FFk10SCY!UuWPXyqZwmca00pa2clOth1ryh1Z-AAgJg2yibfoUw0) with old keygen (riglol.3owl.com) or my newest patch from the post above with the new tirulerbach's keygen (if he decides to publish it).
Thanks man..
Have it been tested on DS2072A with   Hardware version 2.0 ? yours is 2.0 ?
Does its keeps even after reboot? IF i use DSHH ( add all) would it have any negative side ? I just ask because i saw that you can choose fewer options, so i thought " why would someone choose not all options ?
Which difference of both your versions ? the newest and the older ? i cannot use the newest unless tirulerbach's keygen is out right ? (sorry, i am into using it, not the hacking( i have not enough knowledge, but would love to use it and post back the results.
Thanks very much.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: nmz787 on February 02, 2014, 04:40:36 am
alank2, Can you be a bit more specific about the tool. I'm new around here.

https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg375454/#msg375454 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg375454/#msg375454)

I don't know much about it, haven't tested it, but it says it can issue an uninstall command...


I ended up downloading the ~500 Mb Rigol Ultra Sigma software
Code: [Select]
http://us.rigol.com/prodserv/DS4000/software/ and after entering the IP address of the scope, and right-clicking on the unit, I found the SCPI terminal and issued
Code: [Select]
:SYSTem:OPTion:UNINSTall, rebooted the scope, and found all options uninstalled (though I couldn't tell if this 100MHz unit reverted to 70MHz). Then I went back to the own3 site and put in the serial # and the options needed to reinstall. Removed the hyphens (-) from the pop-up messsage code, then pasted that just after this command in the SCPI terminal:
Code: [Select]
:SYSTem:OPTion:INSTall licenseCode
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: poida_pie on February 02, 2014, 05:18:03 am
Good golly man, this sorts out any need to open the 2072A machines now.
I myself have a non A series 2072 so the riglol keygen works fine for me.

But now, the problem for A series owners seems to be sorted thanks to this.

Correct me if I am wrong but the steps to hack an A series  Rigol 2000 DSO is
1 - flash it with attached firmware
2 - connect, issue "*IDN?", write down serial and keys
3 - flash it with current firmware or not, up to you.
4 - find the keygen that you can put in your specific private keys (where would I find that, exactly? I forget.)
5 - generate keys
6 - stuff them into the DSO
7 - get a beer from the fridge, done.

This means no more jtag, no more opening up the new A series DSOs. No more worrying about warranty.
zombie28 you are The Man.
I have a  fridge full of home brew, if ever you are traveling by the way of Melbourne AUS...
P.

What chances are there to patch a firmware so that it outputs the key and serial when you send it
"*IDN?". That would be good.

Done!

https://mega.co.nz/#!MdcEWTgL!0EEmSr-Q6TxaFSsyEmjhRrgqDvFCoXg9K49BalL5Uxc

No need for JTAG memory dumps anymore, just send *IDN? command and you'll get your license encryption keys in response (tested on my DS2072A that has just arrived).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on February 02, 2014, 12:07:35 pm
Have it been tested on DS2072A with   Hardware version 2.0 ? yours is 2.0 ?
Every DS2000A series scope has HW 2.
It's only the older DS2000 non-A series scopes that comes with HW 1, but the newer non-A DS2000 also has HW 2, like the A models.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: diyaudio on February 02, 2014, 01:53:18 pm
What chances are there to patch a firmware so that it outputs the key and serial when you send it
"*IDN?". That would be good.

Done!

https://mega.co.nz/#!MdcEWTgL!0EEmSr-Q6TxaFSsyEmjhRrgqDvFCoXg9K49BalL5Uxc

No need for JTAG memory dumps anymore, just send *IDN? command and you'll get your license encryption keys in response (tested on my DS2072A that has just arrived).


zombie28 ! great work!

Can anyone do a demo and upload to youtube for us. please. 




Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ju1ce on February 02, 2014, 02:51:18 pm
Done!

https://mega.co.nz/#!MdcEWTgL!0EEmSr-Q6TxaFSsyEmjhRrgqDvFCoXg9K49BalL5Uxc

No need for JTAG memory dumps anymore, just send *IDN? command and you'll get your license encryption keys in response (tested on my DS2072A that has just arrived).
Thanks. I tried this and got the keys. I'm afraid I can't do anything with them though unless a keygen is published. I tried earlier to do a memory dump using Segger J-Link, but it failed after about 48 hours...

zombie28 ! great work!

Can anyone do a demo and upload to youtube for us. please.
Install this firmware (you get the update instructions pdf from Rigol if you request a firmware update). Connect the scope to your windows PC using lan or usb and send the IDN command using Rigol's Ultra Sigma software (I'm sure there are other alternatives as well). The keys are in the output as told in the readme file. Anything simpler and it soon becomes too easy...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tirulerbach on February 02, 2014, 03:03:20 pm
You can use either my first firmware patch (https://mega.co.nz/#!FFk10SCY!UuWPXyqZwmca00pa2clOth1ryh1Z-AAgJg2yibfoUw0) with old keygen (riglol.3owl.com) or my newest patch from the post above with the new tirulerbach's keygen (if he decides to publish it).

Decided: https://mega.co.nz/#!qAkUkTZB!XG12bUKhIz4CmQt6DbBnGRMvEe5AvUjEaBxi4R03tw8 (https://mega.co.nz/#!qAkUkTZB!XG12bUKhIz4CmQt6DbBnGRMvEe5AvUjEaBxi4R03tw8)  ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on February 02, 2014, 03:35:00 pm
I tried this and got the keys. I'm afraid I can't do anything with them though unless a keygen is published.

Now you can (thanks tirulerbach!)

The keygen requires memory dump in a binary form, so you will need some hex editor (like HxD) to create one. Just paste the keys as a sequence of bytes, append your scope's serial number as plain text and terminate it with 0. Now you can use the keygen, like this:

Code: [Select]
rigup.exe DS2072A dump.bin
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: diyaudio on February 02, 2014, 03:43:48 pm
Done!

https://mega.co.nz/#!MdcEWTgL!0EEmSr-Q6TxaFSsyEmjhRrgqDvFCoXg9K49BalL5Uxc

No need for JTAG memory dumps anymore, just send *IDN? command and you'll get your license encryption keys in response (tested on my DS2072A that has just arrived).
Thanks. I tried this and got the keys. I'm afraid I can't do anything with them though unless a keygen is published. I tried earlier to do a memory dump using Segger J-Link, but it failed after about 48 hours...

zombie28 ! great work!

Can anyone do a demo and upload to youtube for us. please.
Install this firmware (you get the update instructions pdf from Rigol if you request a firmware update). Connect the scope to your windows PC using lan or usb and send the IDN command using Rigol's Ultra Sigma software (I'm sure there are other alternatives as well). The keys are in the output as told in the readme file. Anything simpler and it soon becomes too easy...

hi ju1ce ! Thanks for those steps.  (Sorry for coming across lazy) will download the software now.


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ju1ce on February 02, 2014, 04:39:26 pm
(http://i60.tinypic.com/f1mrur.jpg)
Decided: https://mega.co.nz/#!qAkUkTZB!XG12bUKhIz4CmQt6DbBnGRMvEe5AvUjEaBxi4R03tw8 (https://mega.co.nz/#!qAkUkTZB!XG12bUKhIz4CmQt6DbBnGRMvEe5AvUjEaBxi4R03tw8)  ;)
Thank you for your work and for releasing this keygen!

Now you can (thanks tirulerbach!)

The keygen requires memory dump in a binary form, so you will need some hex editor (like HxD) to create one. Just paste the keys as a sequence of bytes, append your serial number as plain text and terminate it with 0. Now you can use the keygen, like this:
Got it. Thanks for the instructions and everything you've done for this hack. I successfully installed the options, as you can see.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ZeroAviation on February 02, 2014, 05:33:19 pm
I used the 'special' firmware to dump my keys. Then used the rigup keygen with the following results.

The 100MHZ (NSER) works for me. However the 200MHZ (NSEQ) does not. (Says licenses unavailable on the scope)

Any ideas? Mine is a week 47 scope.

Cheers guys! Thanks for the hard work.
-Matt
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: kado on February 02, 2014, 05:55:57 pm
Hello to all,

i can´t download tirulerbach´s keygen from mega.co.nz. Too much download requests this time or hacked from PRC?

Please can anybody mirror this file?

Thanks,
Karsten

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tiagobaracho on February 02, 2014, 06:24:17 pm
Me too.. i cant donwload..... Please send it to www.yousendit.com (http://www.yousendit.com) it works great
I am Just waiting for it to be able to free my scope ! lol >:D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Pehtoori on February 02, 2014, 06:52:32 pm
Me too.. i cant donwload..... Please send it to www.yousendit.com (http://www.yousendit.com) it works great
I am Just waiting for it to be able to free my scope ! lol >:D

Try again now, should be up

if not:
https://www.hightail.com/download/elNKUXV1dzg5bEJ2TzhUQw (https://www.hightail.com/download/elNKUXV1dzg5bEJ2TzhUQw)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tiagobaracho on February 02, 2014, 07:10:38 pm
Me too.. i cant donwload..... Please send it to www.yousendit.com (http://www.yousendit.com) it works great
I am Just waiting for it to be able to free my scope ! lol >:D

Try again now, should be up

if not:
https://www.hightail.com/download/elNKUXV1dzg5bEJ2TzhUQw (https://www.hightail.com/download/elNKUXV1dzg5bEJ2TzhUQw)
yesssssssssssss o got it now !!!!
Please check if i am right..
all i need to do is :
1 - Copy the DS2000Update.GEL from the DS2000(DSP)update_00.02.01.00.03 (license keys dump) zip file to a fat 32 pendrive.
2 - Press the power on button on the front panel of the instrument. All of the buttons will light. At the same time press two or three times the Help key on the front panel. All buttons will unlight
3- insert the USB stick into the front panel.
4- Wait for the end of the firmware update
5 - all of the buttons on the front panel will be lit.  Turn off the scope. Remove the pendrive
6 - check the new firmware version
7 - Connect to USB cable to PC and open up Ultra Sigma Software 
8 - Send the  *IDN? command. and get the keys back.
9 - write the keys to the HxD editor and get the final serial and input on the DS2072a

Is that right ? If i understood correctly..
Thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: np on February 02, 2014, 07:24:42 pm
You can use either my first firmware patch (https://mega.co.nz/#!FFk10SCY!UuWPXyqZwmca00pa2clOth1ryh1Z-AAgJg2yibfoUw0) with old keygen (riglol.3owl.com) or my newest patch from the post above with the new tirulerbach's keygen (if he decides to publish it).

Decided: https://mega.co.nz/#!qAkUkTZB!XG12bUKhIz4CmQt6DbBnGRMvEe5AvUjEaBxi4R03tw8 (https://mega.co.nz/#!qAkUkTZB!XG12bUKhIz4CmQt6DbBnGRMvEe5AvUjEaBxi4R03tw8)  ;)


Just another generator that I quickly wirte (a bit ugly) as I received my DS2072A yesterday :)  (before catching this message of course)

https://mega.co.nz/#!AcB11JAK!cHpnLrRwE2xJwz-ryTE6-zCXEgfmqlPEMj6AbaBzNmc (https://mega.co.nz/#!AcB11JAK!cHpnLrRwE2xJwz-ryTE6-zCXEgfmqlPEMj6AbaBzNmc)


Usage : ./riglol-np DSHH 'RIGOL TECHNOLOGIES,DS2072A,DS2D123456789,020084001000........'

This should work as I can verify signed keys based on zombie28 code.


@zombie28, it will be cool if you can share the boot trick (magic buttons tricks),  and how to boot from the network (inject ldr  / kernel) and other stuff like compiled blackfin IDA plugin.

Riglol+


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on February 02, 2014, 08:02:28 pm
Usage : ./riglol-np DSHH 'RIGOL TECHNOLOGIES,DS2072A,DS2D123456789,020084001000........'

Don't use DSHH option code with the new DS2kA keygen! This code is valid only for non-A models or firmware patched to use non-A license codes on DS2kA scopes. Take a look at tirulerbach's keygen for valid option codes.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ju1ce on February 02, 2014, 08:19:54 pm
yesssssssssssss o got it now !!!!
Please check if i am right..
all i need to do is :
1 - Copy the DS2000Update.GEL from the DS2000(DSP)update_00.02.01.00.03 (license keys dump) zip file to a fat 32 pendrive.
2 - Press the power on button on the front panel of the instrument. All of the buttons will light. At the same time press two or three times the Help key on the front panel. All buttons will unlight
3- insert the USB stick into the front panel.
4- Wait for the end of the firmware update
5 - all of the buttons on the front panel will be lit.  Turn off the scope. Remove the pendrive
6 - check the new firmware version
7 - Connect to USB cable to PC and open up Ultra Sigma Software 
8 - Send the  *IDN? command. and get the keys back.
9 - write the keys to the HxD editor and get the final serial and input on the DS2072a

Is that right ? If i understood correctly..
Thanks
Yup, you got it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: at2 on February 02, 2014, 09:10:54 pm
Hi zombie 28,
after receiving the long string by sending *IDN? of the encryption free made Ds2072A i tried to put this
string into the HxD editor.
But which is the  final serial ?
I tried also the rigup keygenerator with the so received string from the DS2072A but i always receive the message "no keys in there".
Did i miss something, or did i send the wrong string to the keygenerator?

at2
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: diyaudio on February 02, 2014, 09:21:09 pm
yesssssssssssss o got it now !!!!
Please check if i am right..
all i need to do is :
1 - Copy the DS2000Update.GEL from the DS2000(DSP)update_00.02.01.00.03 (license keys dump) zip file to a fat 32 pendrive.
2 - Press the power on button on the front panel of the instrument. All of the buttons will light. At the same time press two or three times the Help key on the front panel. All buttons will unlight
3- insert the USB stick into the front panel.
4- Wait for the end of the firmware update
5 - all of the buttons on the front panel will be lit.  Turn off the scope. Remove the pendrive
6 - check the new firmware version
7 - Connect to USB cable to PC and open up Ultra Sigma Software 
8 - Send the  *IDN? command. and get the keys back.
9 - write the keys to the HxD editor and get the final serial and input on the DS2072a

Is that right ? If i understood correctly..
Thanks
Yup, you got it.

Fail for me, im using windows 8 X64 and Ultra Sigma crashes every time ! and I didn't even get to install the updated firmware. the label on the cd says for DS2000A V01.02
IVE GOT SOFTWARE VERSION 00.02.00 is this a windows 8 x64 thing ???

Gosh im trying to download latest Ultra Sigma version is downloading so slooow from the rigol server!


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on February 02, 2014, 09:25:18 pm
@zombie28, it will be cool if you can share the boot trick (magic buttons tricks),  and how to boot from the network (inject ldr  / kernel) and other stuff like compiled blackfin IDA plugin.

I attached IDA blackfin plugin, but I don't know anything about the rest - it's cybernet's domain.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tiagobaracho on February 02, 2014, 09:32:18 pm
On the rigup readme it says ( 2.) Once you got a memory dump of your scope, use the tool "rigup" to     create a list of suitable licenses. Example:       rigup ds2072a memory_dump.bin "
how do i do this memory dump ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on February 02, 2014, 09:34:43 pm
Hi zombie 28,
after receiving the long string by sending *IDN? of the encryption free made Ds2072A i tried to put this
string into the HxD editor.
But which is the  final serial ?
I tried also the rigup keygenerator with the so received string from the DS2072A but i always receive the message "no keys in there".
Did i miss something, or did i send the wrong string to the keygenerator?

at2

You need to append your scope's serial number and terminate it with 0 in HxD editor.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on February 02, 2014, 09:39:09 pm
On the rigup readme it says ( 2.) Once you got a memory dump of your scope, use the tool "rigup" to     create a list of suitable licenses. Example:       rigup ds2072a memory_dump.bin "
how do i do this memory dump ?

The answer is here: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg380144/#msg380144 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg380144/#msg380144)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: at2 on February 02, 2014, 09:54:43 pm
Hi zombie28,

i did as you wrote:" you need to append your scope's serial number and terminate it with 0 in HxD editor".

But it comess the same answer, that there will be no keys there inside.
What did i wrong? I copied the whole string beginning with "Rigol.." and put it into the HxD editor with appending the SN and 0.
I did only the numbers following the text string " Rigol..." but i think this would be wrong.

Thank you for your execellent work for encrypting the DS2000A and for your assistance help.

at2
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on February 02, 2014, 10:06:04 pm
i did as you wrote:" you need to append your scope's serial number and terminate it with 0 in HxD editor".

But it comess the same answer, that there will be no keys there inside.
What did i wrong? I copied the whole string beginning with "Rigol.." and put it into the HxD editor with appending the SN and 0.
I did only the numbers following the text string " Rigol..." but i think this would be wrong.

Put the string starting with '02008400...' as binary data, ie. 0x02, 0x00, 0x84, 0x00 and so on, then append your scope's serial number 'DS2D....' as plain ASCII text and then append 0x00 byte.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: diyaudio on February 02, 2014, 10:27:57 pm
still no luck, can anyone please let me know what os system they using and why this software keep crashing on me. :face palm:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: at2 on February 02, 2014, 10:52:32 pm
Hello zombie 28,
i did your helpful assistance but no luck. Yes,  perhaps i`m not so familiar with it. But i did your advice:

"Put the string starting with '02008400...' as binary data, ie. 0x02, 0x00, 0x84, 0x00 and so on, then append your scope's serial number 'DS2D....' as plain ASCII text and then append 0x00 byte."

a) Rigup is running under DOS, so this cannot be the problem.
b) I did the parameters for HxD by: 16, DOS/IBM-ASCII, hex

Is there all be allright up to this?

at2
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tirulerbach on February 02, 2014, 11:01:29 pm
No need for playing with hex editors. You can use keyfiles with rigup, too. They are simple textfiles:

Code: [Select]
RC5KEY1:        88359067012Exxxxxxxxxxxxxxxxxxx
RC5KEY2:        3D44CD4EC48Fxxxxxxxxxxxxxxxxxxx
XXTEAKEY:       95F6CC12864Axxxxxxxxxxxxxxxxxxx
PUBKEY:         006CE7F7xxxxxxxx
PRIVKEY:        008ABBC4xxxxxxxx
SERIAL:         DS2D154xxxxxx

and then:

Code: [Select]
$ rigup license your-keyfile.txt NSEH NSER NSEQ
rigup license - Version 0.1

H8LXHB8-QEXAC7W-ZJMN5KH-APD9CVM    (NSEH = 0x1C087)
W2LAMX2-DBEFZCT-XSND62C-PG8JJVM    (NSER = 0x1C08F)
5CAZKCC-2Z865FH-MQVBXUB-BDV8E8M    (NSEQ = 0x1C097)

NSEH = All options
NSER = All options + 100 MHz
NSEQ = All options + 200 MHz

License-code for 300 MHz is unknown. Thought it could be NSFH but there are reports that it doesn't work.

If you're brave you could play with rigup and license-codes. You could use hex codes, too:

Code: [Select]
$ rigup license your-keyfile.txt 0x1C087 0x1C08F 0x1C097 0x1C0A7
rigup license - Version 0.1

H8LXHB8-QEXAC7W-ZJMN5KH-APD9CVM    (NSEH = 0x1C087)
W2LAMX2-DBEFZCT-XSND62C-PG8JJVM    (NSER = 0x1C08F)
5CAZKCC-2Z865FH-MQVBXUB-BDV8E8M    (NSEQ = 0x1C097)
XYJ69WE-SBZABHL-69FYG4N-W6DH2VM    (NSFH = 0x1C0A7)

I didn't try zombie28's patched firmware. So maybe somebody posts an example how the output looks like and maybe I expand rigup to play nice with zombie28's code...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: diyaudio on February 03, 2014, 12:01:30 am
No need for playing with hex editors. You can use keyfiles with rigup, too. They are simple textfiles:

Code: [Select]
RC5KEY1:        88359067012Exxxxxxxxxxxxxxxxxxx
RC5KEY2:        3D44CD4EC48Fxxxxxxxxxxxxxxxxxxx
XXTEAKEY:       95F6CC12864Axxxxxxxxxxxxxxxxxxx
PUBKEY:         006CE7F7xxxxxxxx
PRIVKEY:        008ABBC4xxxxxxxx
SERIAL:         DS2D154xxxxxx

and then:

Code: [Select]
$ rigup license your-keyfile.txt NSEH NSER NSEQ
rigup license - Version 0.1

H8LXHB8-QEXAC7W-ZJMN5KH-APD9CVM    (NSEH = 0x1C087)
W2LAMX2-DBEFZCT-XSND62C-PG8JJVM    (NSER = 0x1C08F)
5CAZKCC-2Z865FH-MQVBXUB-BDV8E8M    (NSEQ = 0x1C097)

NSEH = All options
NSER = All options + 100 MHz
NSEQ = All options + 200 MHz

License-code for 300 MHz is unknown. Thought it could be NSFH but there are reports that it doesn't work.

If you're brave you could play with rigup and license-codes. You could use hex codes, too:

Code: [Select]
$ rigup license your-keyfile.txt 0x1C087 0x1C08F 0x1C097 0x1C0A7
rigup license - Version 0.1

H8LXHB8-QEXAC7W-ZJMN5KH-APD9CVM    (NSEH = 0x1C087)
W2LAMX2-DBEFZCT-XSND62C-PG8JJVM    (NSER = 0x1C08F)
5CAZKCC-2Z865FH-MQVBXUB-BDV8E8M    (NSEQ = 0x1C097)
XYJ69WE-SBZABHL-69FYG4N-W6DH2VM    (NSFH = 0x1C0A7)

I didn't try zombie28's patched firmware. So maybe somebody posts an example how the output looks like and maybe I expand rigup to play nice with zombie28's code...

The DS2000Update.GEL help says:
Quote
Rigol "DS2000(DSP)update_00.02.01.00.03" firmware modified
to return license encryption keys after sending *IDN? SCPI
command. The keys file is returned instead of "the software
version of the instrument" in the following hex format:

02 00
84 00
10 00 <16 bytes of XXTEAKey>
20 00 <2x16 bytes of RC5Key1 and RC5Key2>
08 00 <8 bytes of bit-shuffled ECC public key>
40 00 <64 bytes of ASCII-HEX verification data>

Note: Use this firmware in DS2000A oscilloscopes only!



the keygen works like this
Quote
rigup - License generator for the Rigol DS2000_A series scopes
==============================================================

Use at your own risk!

1.) You need a memory dump from the scope you wish to upgrade. Read the
    forums how to achieve this.

    Important: ***Read***, not asking the same questions all the time.
    There are all necessary information. No pain, no gain! Just learn
    for your own benefit!

2.) Once you got a memory dump of your scope, use the tool "rigup" to
    create a list of suitable licenses. Example:

        rigup ds2072a memory_dump.bin

    Replace 'ds2072a' with your model number.

3.) Choose a license from the generated list and enter the 28 characters
    in your scope.

4.) Have fun and report success or failure to the forum!


This means we cannot use the patched firmware as you shown with rigup keyfile, the format of the patched firmware is not in the same keyfile format.. right? so we must use the hexeditor.
 
Quote
I expand rigup to play nice with zombie28's code...

please do so it becomes easier
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tirulerbach on February 03, 2014, 12:10:46 am
This means we cannot use the patched firmware as you shown with rigup keyfile, the format of the patched firmware is not in the same keyfile format.. right? so we must use the hexeditor.

Ahh.. Ok. So somebody should send me some "patched firmware keyfiles" and we will see...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: diyaudio on February 03, 2014, 12:16:19 am
yesssssssssssss o got it now !!!!
Please check if i am right..
all i need to do is :
1 - Copy the DS2000Update.GEL from the DS2000(DSP)update_00.02.01.00.03 (license keys dump) zip file to a fat 32 pendrive.
2 - Press the power on button on the front panel of the instrument. All of the buttons will light. At the same time press two or three times the Help key on the front panel. All buttons will unlight
3- insert the USB stick into the front panel.
4- Wait for the end of the firmware update
5 - all of the buttons on the front panel will be lit.  Turn off the scope. Remove the pendrive
6 - check the new firmware version
7 - Connect to USB cable to PC and open up Ultra Sigma Software 
8 - Send the  *IDN? command. and get the keys back.
9 - write the keys to the HxD editor and get the final serial and input on the DS2072a

Is that right ? If i understood correctly..
Thanks
Yup, you got it.

Fail for me, im using windows 8 X64 and Ultra Sigma crashes every time ! and I didn't even get to install the updated firmware. the label on the cd says for DS2000A V01.02
IVE GOT SOFTWARE VERSION 00.02.00 is this a windows 8 x64 thing ???

Gosh im trying to download latest Ultra Sigma version is downloading so slooow from the rigol server!



okay I got the key using *IDN?y. luckily I have a spare notebook with windows 7 x64. :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: at2 on February 03, 2014, 12:36:42 am
So after all trying and erroring:

rigup.exe license dump.bin DSEZ (or something else?)

After enter,  the rigup.exe crashes down.

Now , i don`t know further.

Perhaps any idea?

at2
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on February 03, 2014, 01:09:51 am
rigup.exe license dump.bin DSEZ (or something else?)
Something else! DSEZ is for non-A models. Use  NSEH, NSER or NSEQ as mentioned above.
But you don't have to type any 4-letter code at all.
Just type "rigup ds2072a memory_dump.bin" [replace ds2072a with your specific model name: ds2072a, ds2102a, ds2202a or ds2302a to only generate the codes relevant for your model].
Then it will generate for both NSEH, NSER, NSEQ and NSFH. But NSFH for 300 MHz doesn't seem to be the correct code, so use NSEQ for "All options + 200 MHz".

NSEH = All options
NSER = All options + 100 MHz
NSEQ = All options + 200 MHz

License-code for 300 MHz is unknown. Thought it could be NSFH but there are reports that it doesn't work.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: diyaudio on February 03, 2014, 01:35:12 am
yesssssssssssss o got it now !!!!
Please check if i am right..
all i need to do is :
1 - Copy the DS2000Update.GEL from the DS2000(DSP)update_00.02.01.00.03 (license keys dump) zip file to a fat 32 pendrive.
2 - Press the power on button on the front panel of the instrument. All of the buttons will light. At the same time press two or three times the Help key on the front panel. All buttons will unlight
3- insert the USB stick into the front panel.
4- Wait for the end of the firmware update
5 - all of the buttons on the front panel will be lit.  Turn off the scope. Remove the pendrive
6 - check the new firmware version
7 - Connect to USB cable to PC and open up Ultra Sigma Software 
8 - Send the  *IDN? command. and get the keys back.
9 - write the keys to the HxD editor and get the final serial and input on the DS2072a

Is that right ? If i understood correctly..
Thanks
Yup, you got it.

Quote
9 - write the keys to the HxD editor and get the final serial and input on the DS2072a
im stuck here, ive extracted the various address explained here

02 00
84 00
10 00 <16 bytes of XXTEAKey>
20 00 <2x16 bytes of RC5Key1 and RC5Key2>
08 00 <8 bytes of bit-shuffled ECC public key>
40 00 <64 bytes of ASCII-HEX verification data>

Note: Use this firmware in DS2000A oscilloscopes only!

RC5KEY1:  BCF38C.....   
RC5KEY2:  44A3403....     
XXTEAKEY: 50E3E8B8A71720...   
PUBKEY:   0200840010001809         
PRIVKEY:  04444000424137314533353943394136333435423731353741414432353035334236...   
SERIAL:   DS2D1....

when I map it as above and execute I get this.

rigup license final.txt NSEH NSER NSEQ
rigup license - Version 0.1

Error parsing line: 'RC5KEY1:  BCF38CB....
'
Loading keyfile 'final.txt' failed. uhmm now im officially stuck, :(
 


 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tiagobaracho on February 03, 2014, 01:44:59 am
I GOT IT !!! I will make a how to in details in few minutes to you guys that are having problem as i did!!!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: idpromnut on February 03, 2014, 01:51:13 am
First of all, thank you zombie28 & tirulerbach for your work!  And now, some feedback:

I tried all three codes that were generated (minus NSFH) on a DS2072A:

NSEH: works a beauty.

NSER: seemed to work (i.e. all options enabled, + 100Mhz option + model was not DS2102A) but no 1ns timebase (still at 5ns minimum sweep). I decided to uninstall all the options and after that the 2ns, 1ns and 500ps (uhhh) timebases became available (also the model was reset to DS2072A).  I resintalled the NSER license and the 2ns, 1ns, and 500ps timebases disappear and all the options are enabled again and the model is back to DS2102A.

NSEQ: key was not taken by the scope at all (and no non-bandwidth options were enabled), said that No Licenses were available.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: diyaudio on February 03, 2014, 01:57:16 am
I GOT IT !!! I will make a how to in details in few minutes to you guys that are having problem as i did!!!
please do we will really appreciate it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on February 03, 2014, 02:00:52 am
RC5KEY1:  BCF38C.....   
RC5KEY2:  44A3403....     
XXTEAKEY: 50E3E8B8A71720...   
PUBKEY:   0200840010001809         
PRIVKEY:  04444000424137314533353943394136333435423731353741414432353035334236...   
SERIAL:   DS2D1....
I think your PUBKEY and PRIVKEY looks wrong. Why are these not hexadecimal values?
I have tried to extract the values from one of the .bin memory dumps uploaded here using the "rigup scan" command and it generates a keyfile that looks like this:
Code: [Select]
RC5KEY1:        4155BFD82D429EA69B3EE7D7D59C8906
RC5KEY2:        B9BC53D8B8CE6CE3594555AA89556543
XXTEAKEY:       86F4A0930BC7ED276B2D6C2CE293535F
PUBKEY:         00A0581020E5C012
PRIVKEY:        005BCEE4DD323E4E
SERIAL:         DS2D154300287
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tiagobaracho on February 03, 2014, 02:01:38 am
How to Hack your DS2000 series :

1 - Copy the DS2000Update.GEL from the DS2000(DSP)update_00.02.01.00.03 (license keys dump) zip file to a fat 32 pendrive.
2 - Press the power on button on the front panel of the instrument. All of the buttons will light. At the same time press two or three times the Help key on the front panel. all buttons will unlight.
3- insert the USB stick into the front panel.
4- Wait for the end of the firmware update(may take 1 mins.... be patient)
5 - all of the buttons on the front panel will be lit.  Turn off the scope. Remove the pendrive. Turn on agaion
6 - check the new firmware version , should be now 00.02.01
7 - Connect to USB cable to PC and open up Ultra Sigma Software  ( you may need to install the NI-VISA full driver , google it and will find easy to download, from ni.com)
8 - On the Ultra Sigma software, click with the left button on your scope being listed, click on SCPI Panel Control, then click  Send & Read button (*IDN? command should be already wrote on the SCPI COMMAND, if not, please write it ). It will bring back something like :
RIGOL TECHNOLOGIES,DS2072A,DS2D154700708,020084001000E9BC3D59216F9F9A1DD30EFED1AE20F92000ABC495314FF8236E708F9A2C6E3F6E87D09019C79419FEA9E9F3862A12CA1DE90800819A17FCA12E500540003330313233345645645465333033374342323539363234343535354243343836453538424243353233314631353132443135383035353734463544413334
9- Get from ( 020084 till the end)  Copy and paste on HxD editor on  the middle column  ( which shows 02 00 84 00 10 00 E9 BC 3D 59 21 6F 9F 9A 1D D3..... so on )
10 - now, on the right side of the editor, just append your model serial number( DS2D1....... )  , no spaces, just append, and append more 00 after your model on the middle column.
11 - save the file on you hard drive , same folder as rigup exe, and open command prompt, go to the same folder as rigup and do : rigup ds2072a key.txt ( replace dS2072a  for the model you have, and replace key.txt for the filename you saved.
Now it will show you the serials !!!

No credit for me other the explaning... The guys did here ALL the hard work, but their level where so higher on the understand that for us that just wants to hack the scope, we got a little bit lost right ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on February 03, 2014, 02:16:10 am
RIGOL TECHNOLOGIES,DS2072A,DS2D154700708,020084001000E9BC3D59216F9F9A1DD30EFED1AE20F92000ABC495314FF8236E708F9A2C6E3F6E87D09019C79419FEA9E9F3862A12CA1DE90800819A17FCA12E500540003330313233345645645465333033374342323539363234343535354243343836453538424243353233314631353132443135383035353734463544413334
Does this work with the key values and serial you have posted here? I can't get it to work using these values. I just get this error message when typing rigup ds2072a key.txt after saving the hex file as key.txt:
Scanning 'key.txt' failed: No keys

I have attached the key.txt I generated with HxD for reference.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: diyaudio on February 03, 2014, 02:20:05 am
How to Hack your DS2000 series :

1 - Copy the DS2000Update.GEL from the DS2000(DSP)update_00.02.01.00.03 (license keys dump) zip file to a fat 32 pendrive.
2 - Press the power on button on the front panel of the instrument. All of the buttons will light. At the same time press two or three times the Help key on the front panel. all buttons will unlight.
3- insert the USB stick into the front panel.
4- Wait for the end of the firmware update(may take 1 mins.... be patient)
5 - all of the buttons on the front panel will be lit.  Turn off the scope. Remove the pendrive. Turn on agaion
6 - check the new firmware version , should be now 00.02.01
7 - Connect to USB cable to PC and open up Ultra Sigma Software  ( you may need to install the NI-VISA full driver , google it and will find easy to download, from ni.com)
8 - On the Ultra Sigma software, click with the left button on your scope being listed, click on SCPI Panel Control, then click  Send & Read button (*IDN? command should be already wrote on the SCPI COMMAND, if not, please write it ). It will bring back something like :
RIGOL TECHNOLOGIES,DS2072A,DS2D154700708,020084001000E9BC3D59216F9F9A1DD30EFED1AE20F92000ABC495314FF8236E708F9A2C6E3F6E87D09019C79419FEA9E9F3862A12CA1DE90800819A17FCA12E500540003330313233345645645465333033374342323539363234343535354243343836453538424243353233314631353132443135383035353734463544413334
9- Get from ( 020084 till the end)  Copy and paste on HxD editor on  the middle column  ( which shows 02 00 84 00 10 00 E9 BC 3D 59 21 6F 9F 9A 1D D3..... so on )
10 - now, on the right side of the editor, just append your model serial number( DS2D1....... )  , no spaces, just append, and append more 00 after your model on the middle column.
11 - save the file on you hard drive , same folder as rigup exe, and open command prompt, go to the same folder as rigup and do : rigup ds2072a key.txt ( replace dS2072a  for the model you have, and replace key.txt for the filename you saved.
Now it will show you the serials !!!

No credit for me other the explaning... The guys did here ALL the hard work, but their level where so higher on the understand that for us that just wants to hack the scope, we got a little bit lost right ?

thanks dude, that worked, don't forget when using windows 8 you need to run from the command prompt as administrator  I had an issue not running it as an admin.. Now for the moment of truth try them keys... :)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mrflibble on February 03, 2014, 02:33:53 am
Quick question about the current state of affairs.

DS1074Z and DS2072 ==> hack working for ages, based on common private key.

DS2072A ==> recently hacked, based on seperate key for each scope.

Correct?

Reason I ask .. I'm currently debating DS1074Z vs DS2072(A) and have just about decided in favor of the 1074Z. But whatever it becomes, always good to know what tools are available. ;)

Incidentally, when reading about some older hacks I noticed that one of those used usb-tmc on the front usb port. Does anyone know roughly what the capabilities are of this usb port? Is it just SCPI commands over usb, or some other stuff as well?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: diyaudio on February 03, 2014, 02:34:47 am
okay it works however i did a dumb thing i installed the untested 300Mhz option how do you uninstall the 300Mhz options ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on February 03, 2014, 02:38:03 am
okay it works however i did a dumb thing i installed the untested 300Mhz option how do you uninstall the 300Mhz options ?
https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg375454/#msg375454 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg375454/#msg375454)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on February 03, 2014, 02:40:05 am
Quick question about the current state of affairs.

DS1074Z and DS2072 ==> hack working for ages, based on common private key.

DS2072A ==> recently hacked, based on seperate key for each scope.

Correct?
Correct.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: diyaudio on February 03, 2014, 02:40:56 am
okay it works however i did a dumb thing i installed the untested 300Mhz option how do you uninstall the 300Mhz options ?


okay it works however i did a dumb thing i installed the untested 300Mhz option how do you uninstall the 300Mhz options ?
https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg375454/#msg375454 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg375454/#msg375454)

Thanks
:SYSTem:OPTion:UNINSTall
 
Syntax
:SYSTem:OPTion:UNINSTall
 
Description
Unload the option installed.
 
works
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tiagobaracho on February 03, 2014, 02:57:03 am
The two pictures say it all !!
I am so happy that you guys did... you guys have just "transformed" a 70 mhz oscilloscope on a 200mhz .... Thats on another price class..
Thanks very much once again!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: diyaudio on February 03, 2014, 03:05:23 am
success! Its been a long night for me, I just wanted to give a very humble thank you to everyone that participated, especially to ones who work in the silicon shadows a really big thank you I/we really appreciate this.

 

 
 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tiagobaracho on February 03, 2014, 03:11:50 am
Just to keep complete !

How to Hack your DS2000 series :

Download the firmware: https://mega.co.nz/# (https://mega.co.nz/#)!MdcEWTgL!0EEmSr-Q6TxaFSsyEmjhRrgqDvFCoXg9K49BalL5Uxc
Download the rigup: https://mega.co.nz/# (https://mega.co.nz/#)!qAkUkTZB!XG12bUKhIz4CmQt6DbBnGRMvEe5AvUjEaBxi4R03tw8 or https://www.hightail.com/download/elNKUXV1dzg5bEJ2TzhUQw (https://www.hightail.com/download/elNKUXV1dzg5bEJ2TzhUQw)


1 - Copy the DS2000Update.GEL from the DS2000(DSP)update_00.02.01.00.03 (license keys dump) zip file to a fat 32 pendrive.
2 - Press the power on button on the front panel of the instrument. All of the buttons will light. At the same time press two or three times the Help key on the front panel. all buttons will unlight.
3- insert the USB stick into the front panel.
4- Wait for the end of the firmware update(may take more than 1 min.... be patient)
5 - all of the buttons on the front panel will be lit.  Turn off the scope. Remove the pendrive. Turn on again
6 - check the new firmware version , should be now 00.02.01
7 - Connect to USB cable to PC and open up Ultra Sigma Software  ( you may need to install the NI-VISA full driver , google it and will find easy to download, from ni.com)
8 - On the Ultra Sigma software, click with the left button on your scope being listed, click on SCPI Panel Control, then click  Send & Read button (*IDN? command should be already wrote on the SCPI COMMAND, if not, please write it ). It will bring back something like :
RIGOL TECHNOLOGIES,DS2072A,DS2D154700708,020084001000E9BC3D59216F9F9A1DD30EFED1AE20F92000ABC495314FF8236E708F9A2C6E3F6E87D09019C79419FEA9E9F3862A12CA1DE90800819A17FCA12E500540003330313233345645645465333033374342323539363234343535354243343836453538424243353233314631353132443135383035353734463544413334
9- Get from ( 020084 till the end)  Copy and paste on HxD editor on  the middle column  ( which shows 02 00 84 00 10 00 E9 BC 3D 59 21 6F 9F 9A 1D D3..... so on )
10 - now, on the right side of the editor, just append your model serial number( DS2D1....... )  , no spaces, just append, and append more 00 after your model on the middle column.
11 - save the file on you hard drive , same folder as rigup exe, and open command prompt, go to the same folder as rigup and do : rigup ds2072a key.txt ( replace dS2072a  for the model you have, and replace key.txt for the filename you saved.
Now it will show you the serials !!!

No credit for me other the explaining... The guys did here ALL the hard work!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigol-Friend on February 03, 2014, 03:27:56 am
Hi everybody,

here a small info about Rigol DSA815-TG:

After pressing following keys
TRACE > TG > MARKER FCTN > MEAS SETUP > SYSTEM > PRINT SETUP > STORAGE

you will get a hidden menu called "Service" at the second page of the system-menu. Not permanent, after the next turn-on it's hidden again.

Next days I will examine this new menu, maybe it's helpfull. ???

Have a nice day
Rigol-Friend
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybermaus on February 03, 2014, 08:18:06 am
The two pictures say it all !!

I sometimes see these thanks pictures. I really wonder if the guru's and owners if this thread should not ask the rest of us to tone it down. I do appreciate the wonderful and unbelievable skill and effort of course. And a thank you note is in order.

But its one thing for Rigol to dig through text to count the number people using this. But quite another to give them large screaming visuals they can then use in power-point presentations to their managers. Too much hurrahs, and the firmware will close even more.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MrsR on February 03, 2014, 09:05:03 am
okay it works however i did a dumb thing i installed the untested 300Mhz option how do you uninstall the 300Mhz options ?
https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg375454/#msg375454 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg375454/#msg375454)

You should have given him the information I was given after all it was the same Question
THANKS
Rachael
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on February 03, 2014, 10:40:39 am
Does this work with the key values and serial you have posted here? I can't get it to work using these values. I just get this error message when typing rigup ds2072a key.txt after saving the hex file as key.txt:
Scanning 'key.txt' failed: No keys

I have attached the key.txt I generated with HxD for reference.

This file contains some invalid chars and is too short. Maybe the *IDN? response was distorted during transmission or UltraSigma doesn't expect such a long string and sometimes fails to show it correctly? I don't know, it's just my speculation. However, the last data block starting at offset 0x44 can be fixed manually, provided the rest of the file is correct. It should contain 64 ASCII-HEX digits, but it doesn't matter what data is there, because it's not used by the keygen for computations.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on February 03, 2014, 10:58:07 am
Code: [Select]
$ rigup license your-keyfile.txt NSEH NSER NSEQ
rigup license - Version 0.1

H8LXHB8-QEXAC7W-ZJMN5KH-APD9CVM    (NSEH = 0x1C087)
W2LAMX2-DBEFZCT-XSND62C-PG8JJVM    (NSER = 0x1C08F)
5CAZKCC-2Z865FH-MQVBXUB-BDV8E8M    (NSEQ = 0x1C097)

NSEH = All options
NSER = All options + 100 MHz
NSEQ = All options + 200 MHz

License-code for 300 MHz is unknown. Thought it could be NSFH but there are reports that it doesn't work.

If you're brave you could play with rigup and license-codes. You could use hex codes, too:

Code: [Select]
$ rigup license your-keyfile.txt 0x1C087 0x1C08F 0x1C097 0x1C0A7
rigup license - Version 0.1

H8LXHB8-QEXAC7W-ZJMN5KH-APD9CVM    (NSEH = 0x1C087)
W2LAMX2-DBEFZCT-XSND62C-PG8JJVM    (NSER = 0x1C08F)
5CAZKCC-2Z865FH-MQVBXUB-BDV8E8M    (NSEQ = 0x1C097)
XYJ69WE-SBZABHL-69FYG4N-W6DH2VM    (NSFH = 0x1C0A7)


I didn't check it yet, but I think that 300 MHz + all options should be set by value of 0x1C0C7 (NS8H).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: johna on February 03, 2014, 11:02:33 am
Hi,

1. Is the using DS2000 firmware on DS2000A reversable. Can you just replace it with original firmware later? Where do you get the original firmware. Is it possible backup the firmware?
2. Is this firmware altered or it's just the original non-A firmware?
3. Do you loose trial options? Is it possible after restoring original DS2000A firmware to still have the trial options?
4. I guess firmware updates is not an option when using the 00.02.01.00.03 from non-A series
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: diyaudio on February 03, 2014, 11:31:26 am
okay it works however i did a dumb thing i installed the untested 300Mhz option how do you uninstall the 300Mhz options ?
https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg375454/#msg375454 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg375454/#msg375454)

You should have given him the information I was given after all it was the same Question
THANKS
Rachael

I actually ended up using the rigol command manual before I got the answer in the thread, we use the manuals when we become desperate :D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hari on February 03, 2014, 03:26:35 pm
https://mega.co.nz/#!MdcEWTgL!0EEmSr-Q6TxaFSsyEmjhRrgqDvFCoXg9K49BalL5Uxc

No need for JTAG memory dumps anymore, just send *IDN? command and you'll get your license encryption keys in response (tested on my DS2072A that has just arrived).
Zombie28, may I kindly ask you to provide a md5 or sha sum of your patched firmware file?

thank you very much,
hari
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Spikee on February 03, 2014, 04:50:49 pm
I'm sorry to bother you guys but it is not working with my rigol Ds2072(A?).
I think my key/memory dump is to long:

the dump part: Rigol Ds2072
Code: [Select]
3E3C0E435D39DB813C3CC643093CD6837C7C87C78D0CC3833D0101000000000100000000000000000000000000000000000000000000001E0000006400000000000000001100000012000002130000001400000015000000160000001700000018000000190002001A0000001B0004001C0000001D0000001E0000001F00000020000100My Model number is: DS2A143101119

Could anyone be so kind to try / fix this for me ?

Thanks!
(the idn return count is 305 , i tried several times)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cepphus on February 03, 2014, 05:03:33 pm
What chances are there to patch a firmware so that it outputs the key and serial when you send it
"*IDN?". That would be good.

Done!

https://mega.co.nz/#!MdcEWTgL!0EEmSr-Q6TxaFSsyEmjhRrgqDvFCoXg9K49BalL5Uxc

No need for JTAG memory dumps anymore, just send *IDN? command and you'll get your license encryption keys in response (tested on my DS2072A that has just arrived).

Amazing!
Now, the JTAG adapter I ordered will show up way too late as it seems, or is there still an interest for any of you superhackers to get access to more memory dumps from 2072A scopes? If so, I'll be happy to share mine..
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: np on February 03, 2014, 05:47:28 pm

[/quote]
I didn't check it yet, but I think that 300 MHz + all options should be set by value of 0x1C0C7 (NS8H).
[/quote]

Thanks zombie28 for the IDA plugin ;)

I comfirm, 0x1C0C7 is the good option for permanent 300Mhz + all options (screenshot) Timebase : 1ns


Congratulations for all the team members as done that possible
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on February 03, 2014, 06:03:37 pm
I'm sorry to bother you guys but it is not working with my rigol Ds2072(A?).
[...]
My Model number is: DS2A143101119

Apparently you have non-A model, so there are no keys to dump in your scope. Just use the 'riglol' keygen.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: at2 on February 03, 2014, 06:21:23 pm
Hi zombie 28,tirulerbach and tiagobaracho,

thanks to you all for best help.
For best assistance zombie 28 and tirulerbach and excellent job done by tiagobaracho.

My 2072A  now works perfectly in DS2202A mode with all options.

Great!

at2
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: johna on February 03, 2014, 06:29:55 pm
My Model number is: DS2A143101119

You can try this serial: PDVPHYV-H5SQKVS-RDXABUK-AXYPZPA

Enjoy
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on February 03, 2014, 06:51:55 pm
https://mega.co.nz/#!MdcEWTgL!0EEmSr-Q6TxaFSsyEmjhRrgqDvFCoXg9K49BalL5Uxc

No need for JTAG memory dumps anymore, just send *IDN? command and you'll get your license encryption keys in response (tested on my DS2072A that has just arrived).
Zombie28, may I kindly ask you to provide a md5 or sha sum of your patched firmware file?

Code: [Select]
File: DS2000Update.GEL
MD5:  8d28a810d45a9e8be3095cd312ec57ec
SHA1: 0ed14539d2b81455bb54927c4fc831fa31eccba5
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Spikee on February 03, 2014, 07:14:15 pm
My Model number is: DS2A143101119

You can try this serial: PDVPHYV-H5SQKVS-RDXABUK-AXYPZPA

Enjoy

Thanks!
I have full option Rigol Ds2072 now =)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hari on February 03, 2014, 07:23:31 pm
Code: [Select]
File: DS2000Update.GEL
MD5:  8d28a810d45a9e8be3095cd312ec57ec
SHA1: 0ed14539d2b81455bb54927c4fc831fa31eccba5
Thank you very much!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: excapealex on February 03, 2014, 07:51:49 pm
The new method can also work with the DS2072A-S (with 2 channel function generator  :scared:)? Has anyone tested on it?  :-BROKE

That you know.. there are codes that add functions to the signal generation? (I did a stupid question?  :blah:)

Thanks as always and lots of compliments! :clap:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: johna on February 03, 2014, 09:10:43 pm
Guys, can someone tell me where to find stock firmware. Is it uploaded somewhere? I want to feel a bit safe before I flash to the modified version. I know about request page on rigol, but my scope already has latest version. I can't request firmware upgrade without a reason. My firmware version is 00.02.01.00.03 (DS2072A)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on February 03, 2014, 09:26:01 pm
Guys, can someone tell me where to find stock firmware. Is it uploaded somewhere? I want to feel a bit safe before I flash to the modified version. I know about request page on rigol, but my scope already has latest version. I can't request firmware upgrade without a reason. My firmware version is 00.02.01.00.03 (DS2072A)

https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg342994/#msg342994 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg342994/#msg342994)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: johna on February 03, 2014, 09:54:22 pm
Thanks!

I searched a lot, but I guess there were no words like "stock, original, unmodified"

And if someone points out the post where someone explains how to uninstall features I would be greatful. I see a lot of people mentioning some commands but I don't know how you specify what option to uninstall. I guess the commands are sent to via ultra sigma software.

edit: because it's easy to mix the firmwares here is the sha1 of the original/stock for DS2072A (if I downloaded the correct one) ddf1d511823eaf31f1d05af2ba845543d97c6d3a  DS2000Update.GEL

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: corax on February 03, 2014, 10:14:52 pm
One thing I've noticed on a DS2072A with all features unlocked (using the recent rigup license generator on zombie's 00.02.01.00.03 keydump firmware):
Although the CAN decoder becomes available, it appears not to work correctly.

Watching known good CAN traffic, the decoder attempts to decode, but gets things wrong (the ID, the data length, etc).
Looking a bit closer, it appears to be neglecting to account for CAN stuff bits.

I notice that Rigol doesn't offer the CAN decoder option for purchase for this scope series (as far as I can tell).  This might be why- it's broken.

Has anyone else actually tried out the CAN decoder?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: johna on February 03, 2014, 10:40:09 pm
I haven't tried CAN, but even RS232/SPI doesn't work as expected. Sometimes it doesn't read correct values even though signal on screen is visible and there are multiple points per bit. Also mine doesn't work on recorded data. Can someone confirm that?

And .... BIG THANKS to everyone involved in the keygen. Another success here- my poor DS2072A is now fully upgraded DS2202A. I Installed the 200 MHz option - I was too afraid to install the 300Mz one before I learn how to uninstall options.

Thanks again.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mrflibble on February 04, 2014, 12:26:57 am
I haven't tried CAN, but even RS232/SPI doesn't work as expected. Sometimes it doesn't read correct values even though signal on screen is visible and there are multiple points per bit. Also mine doesn't work on recorded data. Can someone confirm that?
How often does this failure to decode occur? Do you have a screenshot of an example waveform where it doesn't work? And also one where you are using the same settings but it does happen to decode it correctly.

If it really fails to decode that would be bad. So far all the complaint I've read about decoding boiled down to user error. Not that I'm implying (okay yes I am but not the point ;) ) that this is user error, but if Rigol really stuffed up rs232 decoding that would be a bit sad.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Spikee on February 04, 2014, 12:43:46 am
....
. Can someone confirm that?
How often does this failure to decode occur? Do you have a screenshot of an example waveform where it doesn't work? And also one where you are using the same settings but it does happen to decode it correctly.

If it really fails to decode that would be bad. So far all the complaint I've read about decoding boiled down to user error. Not that I'm implying (okay yes I am but not the point ;) ) that this is user error, but if Rigol really stuffed up rs232 decoding that would be a bit sad.


I used it a couple of hours ago (1Mbps SPI) and i can confirm that it won't work sometimes when the traces are clearly visible.
After some fiddling it works again but still there is some kind of bug there.

The decoding was setup correctly.

I use the Rigol Ds2072 using zombie's 00.02.01.00.03 firmware
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: stuartk on February 04, 2014, 02:23:21 am
Slightly off topic;

I noticed that Ultra Sigma stopped being able to print my DS2102's screen a few weeks ago when my model number got corrupted to 2022.

I was eventually able to get the model to stick with 2202 after System:option:uninstall, instead of reverting back to 2022. It's now is at 2302 after the generously supplied keys.

I realize that most of you are using RUU for screen captures, but this error led me to find the following behavior in Ultra Sigma:

DS2022 -- Unable to print screen
DS2202 -- Able to print screen
DS2302 -- Unable to print screen

I believe that it didn't work as DS2302 is not an actual valid model number.

I was able to get it to work by editing the Ultra Sigma Init file in the following manner:

1. Open the Ultra Sigma Folder
2. Make a backup copy of the Init file
3. Open the Init file with word pad
4. Edit the following line to add DS2302 under 'series and model', (or any other model that you have I would expect)

DS2000 = "DS2072,DS2102,DS2202,DS2202-S,DS2102-S,DS2072-S,DS2302"

5. add under [PrintScreenSCPI]

DS2302 = ":DISPlay:DATA?"

You should now be able to print from Ultra Sigma, if before you got a communication error

6. I also added a 'DS2302.rscpi' file in the 'Instrument_Common_RIGOL_SCPI ControlPanel' folder by duplicating a DS2202 file and renaming it. This step seemed to have no effect one way or another.

Cheers to all,

Stuart
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tiagobaracho on February 04, 2014, 02:54:39 am


Thanks zombie28 for the IDA plugin ;)

I comfirm, 0x1C0C7 is the good option for permanent 300Mhz + all options (screenshot) Timebase : 1ns


Congratulations for all the team members as done that possible
HI...
In which model you were able to install the 300mhz?

How did you do to get the NS8H ? when i try rigup license keys.txt 0x1C0C7, windows asks to close..
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: awh4992 on February 04, 2014, 03:07:54 am


Thanks zombie28 for the IDA plugin ;)

I comfirm, 0x1C0C7 is the good option for permanent 300Mhz + all options (screenshot) Timebase : 1ns


Congratulations for all the team members as done that possible
HI...
In which model you were able to install the 300mhz?

How did you do to get the NS8H ? when i try rigup license keys.txt 0x1C0C7, windows asks to close..

rigup spits out a keyfile (saves it to a text file) if you have a memory dump of your scope using the following command: 
Code: [Select]
rigup scan keyfile.txt ds2k_00_sdram.binOnce you have the keyfile, do: 
Code: [Select]
rigup license keyfile.txt 0x1C0C7and that spits out the license key.

I'm pretty sure the stuff spit out by zombie28's firmware via ultra sigma has that keyfile information there too, but ordered differently and whatnot.  I didn't bother to figure it out since I have a dump of my scope.

- Andy
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: idpromnut on February 04, 2014, 03:31:02 am
Confirmed that the NS8H "works" on my scope.  I see the options and timebase, but I am not a believer until I can test it ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tiagobaracho on February 04, 2014, 04:09:36 am
do you know if the hardware is able to do 300mhz ? is it only software limited ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tiagobaracho on February 04, 2014, 04:17:06 am
I just installed the 300mhz... But it now shows two lines...
BANDWIDTH 200M BadnWidth Official Version
                    300M BadnWidth Official Version

Is that all right ? Or do I need to uninstall first  to put the NS8H serial ?


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on February 04, 2014, 05:41:54 am
...but even RS232/SPI doesn't work as expected. Sometimes it doesn't read correct values even though signal on screen is visible and there are multiple points per bit.
If it really fails to decode that would be bad. So far all the complaint I've read about decoding boiled down to user error. Not that I'm implying (okay yes I am but not the point ;) ) that this is user error, but if Rigol really stuffed up rs232 decoding that would be a bit sad.

As far as RS232 is concerned, initially there was one specific baud rate that failed.  That's been fixed.  Also, a few bytes when decoded to ASCII didn't map to the proper characters.  That was also fixed.  So as far as RS232 is concerned, that's been reported to be working properly for quite some time now.

Of course, that was on unhacked units.  Also, "doesn't work as expected" doesn't necessarily mean the Rigol isn't working properly, though that's often the inference drawn.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: johna on February 04, 2014, 08:49:35 am
Of course, that was on unhacked units.  Also, "doesn't work as expected" doesn't necessarily mean the Rigol isn't working properly, though that's often the inference drawn.

My test was on unhacked unit. And you are right - "doesn't work as expected" is not a bug, but if you do not have decode on recorded data the decoding option is not worth the money. And I was about to buy the decoding option before I try to hack it ... because well if they did a great job, they deserve the money. But I tried the trial option and I was not quite happy with it. Decoding seams to be there for the marketing - just an answer to Agilent's decoding option.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Fagear on February 04, 2014, 09:53:25 am
Thank you very much, zombie28 and tirulerbach!
It took some time for me to figure out the right sequence.
So I've managed to write it down.
Code: [Select]
Device: DS2xxxA. No need to open it and buy any other stuff.

1) Flash DS2xxxA with patched FW (license key dumping, from zombie28: https://mega.co.nz/#!FFk10SCY!UuWPXyqZwmca00pa2clOth1ryh1Z-AAgJg2yibfoUw0).
2) Connect DS2xxxA to a PC.
3) In "Rigol Ultra Sigma" open "SCPI Control Panel" and "Send&Read" string "*IDN?"
4) Copy answer to text file.
5) Copy string from comma after serial # of your DS2xxxA to the end ("02008400...").
6) Open HEX editor and paste string as HEX (not ASCII).
7) Copy serial # of your DS2xxxA.
8) Append serial # as ASCII to the data in HEX editor.
9) Append "00" as HEX.
10) Save file as "keyfile.bin" to folder with "rigup" (from tirulerbach: https://mega.co.nz/#!qAkUkTZB!XG12bUKhIz4CmQt6DbBnGRMvEe5AvUjEaBxi4R03tw8).
11) Open command line and navigate to folder with "rigup".
12) Execute "rigup scan keyfile.bin" and get some keys:

RC5KEY1:        88359067012Exxxxxxxxxxxxxxxxxxx
RC5KEY2:        3D44CD4EC48Fxxxxxxxxxxxxxxxxxxx
XXTEAKEY:       95F6CC12864Axxxxxxxxxxxxxxxxxxx
PUBKEY:         006CE7F7xxxxxxxx
PRIVKEY:        008ABBC4xxxxxxxx
SERIAL:         DS2D154xxxxxx

13) Copy them to another text file "keyfile.txt" in "rigup" folder.
14) Execute "rigup license keyfile.txt NSxx", where:

NSEH (0x1C087) - All options
NSER (0x1C08F) - 100 MHz + all options
NSEQ (0x1C097) - 200 MHz + all options
NS8H (0x1C0C7) - 300 MHz + all options

15) Copy license key.
16) In "Rigol Ultra Sigma" "Send&Read" ":SYSTem:OPTion:INSTall YOUR-LICENSE-KEY-WITHOUT-DASHES".

Everything worked fine and now my DS2072A became DS2302A with all options!

After that I reflashed to last original FW (non-modified 00.02.01.00.03) and all options stayed in place.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: EV on February 04, 2014, 10:36:54 am
If you are using AUTO trigger change it to NORMAL and try again.

My test was on unhacked unit. And you are right - "doesn't work as expected" is not a bug, but if you do not have decode on recorded data the decoding option is not worth the money. And I was about to buy the decoding option before I try to hack it ... because well if they did a great job, they deserve the money. But I tried the trial option and I was not quite happy with it. Decoding seams to be there for the marketing - just an answer to Agilent's decoding option.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: excapealex on February 04, 2014, 11:26:12 am
The new method can also work with the DS2072A-S (with 2 channel function generator)? Has anyone tested on it?

That you know.. updating a DS2000A-S with the patched FW there is a risk of losing access to the signal generator?

Having not yet made the purchase..  Do you know how the function generator is managed?
As example: When pressing the source button it switches to a separate management (as a second instrument) or is a more integrated management?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Spikee on February 04, 2014, 12:15:15 pm
If you are using AUTO trigger change it to NORMAL and try again.

...
 But I tried the trial option and I was not quite happy with it. Decoding seams to be there for the marketing - just an answer to Agilent's decoding option.

The normal trigger and spi decoding works quite good , the auto trigger just loses its mind.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mrflibble on February 04, 2014, 01:21:34 pm
My test was on unhacked unit. And you are right - "doesn't work as expected" is not a bug, but if you do not have decode on recorded data the decoding option is not worth the money. And I was about to buy the decoding option before I try to hack it ... because well if they did a great job, they deserve the money. But I tried the trial option and I was not quite happy with it. Decoding seams to be there for the marketing - just an answer to Agilent's decoding option.

Mmmh? I recall reading about the 1000z/2000 series that they can do protocol decoding on both live and recorded data. Or maybe I didn't understand it correctly?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tiagobaracho on February 04, 2014, 02:14:29 pm
Guys...
I had the 200mhz serial installer ...
I generated the 300mhz serial NS8H and installed.... now it shows two lines .. one for the 200mhz and another for the 300 mhz....
Is it wrong ? should i uninstall all options and install the 300 mhz serial again?
I have windows 7.... how do i uninstall ? is there any command to use on the sigma ?
Thanks very much
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tiagobaracho on February 04, 2014, 03:01:37 pm
I was thinking about an way to test around 200-300 mhz ( i don have anything to generate)...
Is there any settings on the scope that we can chose a fixed frequency to scan ?Because if it have, we could be able to see the bandwidth up to 300mhz...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on February 04, 2014, 03:17:39 pm
Guys...
I had the 200mhz serial installer ...
I generated the 300mhz serial NS8H and installed.... now it shows two lines .. one for the 200mhz and another for the 300 mhz....
Is it wrong ? should i uninstall all options and install the 300 mhz serial again?
I have windows 7.... how do i uninstall ? is there any command to use on the sigma ?
Thanks very much

Try some google.. https://www.google.com/search?q=rigol+uninstall+site%3Aeevblog.com#q=rigol+uninstall+site:eevblog.com%2Fforum%2F (https://www.google.com/search?q=rigol+uninstall+site%3Aeevblog.com#q=rigol+uninstall+site:eevblog.com%2Fforum%2F)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: diyaudio on February 04, 2014, 03:43:56 pm
My test was on unhacked unit. And you are right - "doesn't work as expected" is not a bug, but if you do not have decode on recorded data the decoding option is not worth the money. And I was about to buy the decoding option before I try to hack it ... because well if they did a great job, they deserve the money. But I tried the trial option and I was not quite happy with it. Decoding seams to be there for the marketing - just an answer to Agilent's decoding option.

Mmmh? I recall reading about the 1000z/2000 series that they can do protocol decoding on both live and recorded data. Or maybe I didn't understand it correctly?

This have been on my mind for a while now as well, I don't use the more advance protocols like CAN ect but its not the first time I see this heer is one video where someone experience decoding issues. The cost of one decoder can buy you a saleae 8-channel analyser, I never did trust a multifunctional instrument other than a reputable  branded multimeter.   

https://www.youtube.com/watch?v=RxRIX0eFNyw (https://www.youtube.com/watch?v=RxRIX0eFNyw)



 I think we should create a dedicated thread around this . ?



Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hari on February 04, 2014, 03:47:45 pm
https://www.youtube.com/watch?v=RxRIX0eFNyw (https://www.youtube.com/watch?v=RxRIX0eFNyw)

Either he is too stupid to put all scopes to the same sampling settings, or the deliberately wants to make the rigol look bad.

Quote
I think we should create a dedicated thread around this . ?

As you seem to realise that this is off topic here, why do you still post?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: diyaudio on February 04, 2014, 03:49:06 pm
https://www.youtube.com/watch?v=RxRIX0eFNyw (https://www.youtube.com/watch?v=RxRIX0eFNyw)

Either he is too stupid to put all scopes to the same sampling settings, or the deliberately wants to make the rigol look bad.

Quote
I think we should create a dedicated thread around this . ?

As you seem to realise that this is off topic here, why do you still post?

moody today I see ? :)


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on February 04, 2014, 05:22:56 pm
Having not yet made the purchase..  Do you know how the function generator is managed?
As example: When pressing the source button it switches to a separate management (as a second instrument) or is a more integrated management?

On the DS1074Z-S it's a separate "device" inside the unit.  I can generate a signal via one set of menus and view it normally, and all DSO functions work as if the signal were coming from an external generator.

Pushing the "source" button on the front panel brings up menus for configuring the function generator and turning channel 1 & 2 on and off, etc.  Pushing CH1 button puts it back in scope mode and it's like two devices under one UI.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: johna on February 04, 2014, 05:54:24 pm
@neslekkim thanks. I didn't find it first time, but thanks your link I found it:
@tiagobaracho You can uninstall all options by the command:

:SYSTem:OPTion:UNINSTall

And for completeness - to send commands to the scope you can run ultra sigma software and connect using LAN or USB. Then right click ion the device and choose SCPI panel.

To install only the 300Mhz key use:
:SYSTem:OPTion:INSTall XXXXXXXXXXXXXXXXXXXXXXXXXXX

Where XXXXXXXXXXXXXXXXXXXXXXXXXXX is the upgrade key without dashes.

Or you can install the key again using the install menu on the device
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jtizzle on February 04, 2014, 05:56:43 pm
The new method can also work with the DS2072A-S (with 2 channel function generator)? Has anyone tested on it?

That you know.. updating a DS2000A-S with the patched FW there is a risk of losing access to the signal generator?

Having not yet made the purchase..  Do you know how the function generator is managed?
As example: When pressing the source button it switches to a separate management (as a second instrument) or is a more integrated management?

I still have this same question.  I have both scopes in the cart and I'm waiting to pull the trigger on one, but I hate to gamble either way.  I cannot find anyone on the forum that has performed the upgrade on a 2072A-S version.  There is a thread and I've asked, but haven't gotten a solid confirm.  I thought I read that the -S model incorporates additional hardware (daughter board?), it would seem that the SG is separate from the rest of the scope as it has its own output and buttons, but OTOH I think you have to use other dedicated buttons/dials for additional settings, so it could have a different FW.  Flashing to a non -S version could wipe out the ability to select/use the SG.  It would be a real bummer to not get the option (as this is the way I am leaning) because I would really like to have it.... not so much of a bummer though if I were forced to decide between the SG (extra $350) and the patch.  This site and all the work of the super contributors are what put me over the edge for purchasing this brand/model. 

I guess overall 350 is a pretty steep price to have the signal generator integrated.  One can get a really nice SG for a few dollars more... I was just hoping to save a little money and get a better unit later.  Perhaps I have answered my own question as to what to do!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on February 04, 2014, 07:02:09 pm
I have the -S series, not flashed yet, but going to soon.
I don't think there is an problem, if there is firmware for the SG, I guess it's inside the same Gel when it will be updated, atleast, i asked for firmware upgrade, and got the same file as all others, eventhough I have this -S model..

and, which signalgen do you get for $350?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tiagobaracho on February 04, 2014, 07:16:36 pm
@neslekkim thanks. I didn't find it first time, but thanks your link I found it:
@tiagobaracho You can uninstall all options by the command:

:SYSTem:OPTion:UNINSTall

And for completeness - to send commands to the scope you can run ultra sigma software and connect using LAN or USB. Then right click ion the device and choose SCPI panel.

To install only the 300Mhz key use:
:SYSTem:OPTion:INSTall XXXXXXXXXXXXXXXXXXXXXXXXXXX

Where XXXXXXXXXXXXXXXXXXXXXXXXXXX is the upgrade key without dashes.

Or you can install the key again using the install menu on the device

worked like a charm!!!
Now it shows all official Version and only one line with 300m bandwidth

I cant belive it has the same hardware as the 2500 usd with 300mhz... and i paid only 788 USD and you guys from this thread made it happen !
Thanks!
So.. if we need warranty, all need to do is to uninstall the serial and update to stock firmware right ?
And probably those options will work even on future firmware updates ? since its a serial number ?( maybe isnt worthy updating..... the team is winning... why risk , right ?)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on February 04, 2014, 07:21:22 pm
I think you can run stock firmware already, the patched firmware is only for reading out the key's, which probably are not going to change at all.
Title: Sniffing the Rigol's internal I2C bus
Post by: jtizzle on February 04, 2014, 09:53:04 pm

I have the -S series, not flashed yet, but going to soon.

and, which signalgen do you get for $350?
Please post what you find!

I meant ~350 +another 150 or so... i.e. DG1022A (Rigol) is 500 bills. That's nearly there! Honestly though I would rather get something nice in the 800 range (DG4062), but just can't quite swing it. This is why I am really hoping the -s model of this scope will work for a while.... Read-until I can calm my wife down after the buy.
Thanks for the post about the plans to flash.  Please let me know if you hear of any success for this model!


Sent from my iPhone using Tapatalk
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: roket on February 04, 2014, 11:08:57 pm
hi! there is at you file tool generates - ;DG4000 cengen; from cybernet for DG4062? http://pastebin.com/ipkJCxPM (http://pastebin.com/ipkJCxPM)
now it isn't loaded, help please |O
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: anson80 on February 05, 2014, 10:53:05 am
Guys... Sorry to bother..
I bought one Rigol DS2072A
It shows Software version 00.02.00 and Hardware version 2.0... Is that possible to use the 200 mhz and high memory settings ?
I have been reading a lot of pages in this thread but i could not find....
Thanks

You can use either my first firmware patch (https://mega.co.nz/#!FFk10SCY!UuWPXyqZwmca00pa2clOth1ryh1Z-AAgJg2yibfoUw0) with old keygen (riglol.3owl.com) or my newest patch from the post above with the new tirulerbach's keygen (if he decides to publish it).

zombie28 !great!
What is the difference between the first firmware patch and the newest patch?
Just don't need to manually enter the keygen on the oscilloscope?

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hari on February 05, 2014, 02:55:43 pm
What is the difference between the first firmware patch and the newest patch?
As you seem to have missed some of the last posts, let me provide you with a short update: The old patch allows to use the keys from the old keygen, the newest patch will spit out needed key information to generate keys with the new keygen.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: at2 on February 06, 2014, 07:47:01 am
Hi tiagobaracho,

you wrote:
worked like a charm!!!
Now it shows all official Version and only one line with 300m bandwidth

I cant belive it has the same hardware as the 2500 usd with 300mhz... and i paid only 788 USD and you guys from this thread made it happen !
Thanks!
So.. if we need warranty, all need to do is to uninstall the serial and update to stock firmware right ?
And probably those options will work even on future firmware updates ? since its a serial number ?( maybe isnt worthy updating..... the team is winning... why risk , right ?)

My question:

does your DS 2302A work stable as there it is mentioned in this forum not to be. So what is actually right?

at2
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: idpromnut on February 06, 2014, 12:32:52 pm
@at2: I installed the same 300Mhz BW option and then reverted the firmware back to the unlatched version and the scope (with my minimal use) has seemed stable enough. I will continue to do more testing.

As for the DS2072A being the same HW, please remember that no one with a DS2302A (to my knowledge) has posted test results on performance, so there is nothing to compare against just yet.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: at2 on February 06, 2014, 02:23:01 pm
@ispromnut
Thank you for your fast reply.
You are right.Testing this 300MHz mode may be the answer. 

at2
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tiagobaracho on February 06, 2014, 05:46:16 pm
Hi tiagobaracho,

you wrote:
worked like a charm!!!
Now it shows all official Version and only one line with 300m bandwidth

I cant belive it has the same hardware as the 2500 usd with 300mhz... and i paid only 788 USD and you guys from this thread made it happen !
Thanks!
So.. if we need warranty, all need to do is to uninstall the serial and update to stock firmware right ?
And probably those options will work even on future firmware updates ? since its a serial number ?( maybe isnt worthy updating..... the team is winning... why risk , right ?)

My question:

does your DS 2302A work stable as there it is mentioned in this forum not to be. So what is actually right?

at2
I have a DS2072A, not 2302.... its hacked to 300 mhz..
Well... i have tested and not any problem what so ever until now.... And i believe it wont have any problem right ? its just a serial number freeing the functions, not any jailbreak on software really... you can even uninstall everything, update to stock firmware and use the serial that now you have, and it will give you all the options... so, probably just one serial wont give you any instability on the device right ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tiagobaracho on February 06, 2014, 05:48:56 pm
@at2: I installed the same 300Mhz BW option and then reverted the firmware back to the unlatched version and the scope (with my minimal use) has seemed stable enough. I will continue to do more testing.

As for the DS2072A being the same HW, please remember that no one with a DS2302A (to my knowledge) has posted test results on performance, so there is nothing to compare against just yet.
Hi there..
how can we test high frequencies close to 300 ? I dont have any generator.... do you know if i can probe on a computer mainbord something that would be close to those speeds ? like USB port in use, ram memory bus.. i dont know.... what the easiest way to test it at close to 300mhz ?
Thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: at2 on February 06, 2014, 06:43:35 pm
Hi,

i tried to do the 300MZ option, but it failed.
I can only do the upgrade till DS2202A not DS2302A.
After sending the string: rigup ds2072a dump.txt there you receive after the NSFH:xxxxxxx-xxxxxxxx-xxxxxxx-xxxxxx
the question mark *=  untested,unconfirmed.

If i put the NFSH keys into the rigol2072a all options are installed but if stays by DS2072A.
What is wrong?

at2
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on February 06, 2014, 06:55:28 pm
Hi,

i tried to do the 300MZ option, but it failed.
I can only do the upgrade till DS2202A not DS2302A.
After sending the string: rigup ds2072a dump.txt there you receive after the NSFH:xxxxxxx-xxxxxxxx-xxxxxxx-xxxxxx
the question mark *=  untested,unconfirmed.

If i put the NFSH keys into the rigol2072a all options are installed but if stays by DS2072A.
What is wrong?

at2

The NSFH option code turned out to be wrong (read a few pages back). Uninstall all options in your scope and then use NS8H code.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: at2 on February 06, 2014, 07:01:36 pm
Thank you ,

simply question, how do i practice the NS8H ?
Where must i put it in?

at2
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on February 06, 2014, 07:11:13 pm
Thank you ,

simply question, how do i practice the NS8H ?
Where must i put it in?

at2

As said, only two pages back you find this: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg380986/#msg380986 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg380986/#msg380986)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: at2 on February 06, 2014, 07:30:46 pm
Thank you for your best help neslekkim!
It´s working as 300 MHz!

I found the trace two pages before and did it.
Now it`s clear.

at2
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: crmaris on February 06, 2014, 08:10:33 pm
Many thanks to all that contributed in this hack!!!
This is my new DS2072A transformed to a DS2302A.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: at2 on February 06, 2014, 08:12:48 pm
Also thank you Zombie 28!

At2
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: excapealex on February 06, 2014, 09:36:02 pm
Reading the manual I saw this .. (picture attached)
Could you explain me what they intend to?
This has nothing to do with the hardware?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on February 06, 2014, 09:51:03 pm
It means that you can restrict the bandwidth of the scope to either 20MHz or 100MHz when you want to.

So, you buy a 200MHz or 300MHz scope, but you're looking at a signal that is much closer to 20MHz, then you would want to turn on the 20MHz limit and cut out a lot of higher frequency noise.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on February 06, 2014, 10:46:21 pm
It means that you can restrict the bandwidth of the scope to either 20MHz or 100MHz when you want to.

So, you buy a 200MHz or 300MHz scope, but you're looking at a signal that is much closer to 20MHz, then you would want to turn on the 20MHz limit and cut out a lot of higher frequency noise.

Bandwidth limiting will certainly reduce HF noise.  However if that 20MHz signal you're examining happens to be a square wave, you wouldn't want to BW limit it... unless you preferred seeing a sine wave instead.  A 20 MHz BW Limit would be effective at dealing with noise on signals <=5 MHz though.  Without compromising signal integrity too much.

More often, the BW Limiting is used when you reduce the sample rate.  If the Sa-rate is low, any components in your signal >2x Sa will result in aliasing.  BW Limiting knocks those out.   :box:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: excapealex on February 06, 2014, 10:51:22 pm
Ok, but it is just a software filtering not hardware.. Right?
It may not be that the 20MHz filter is hardware and 100MHz filter software (enabled together with the unlock of the bandwith at 300MHz) or both hardware and this is the difference between the 2072A and the 2302A?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Teneyes on February 06, 2014, 11:02:27 pm
Ok, but it is just a software filtering not hardware.. Right?
@Excapealex No , In a past post and Teardown, you can see there is a Hardware variable Bandwidth Amplifier in the DS2000 (4000, 6000) . This hardware has BW filtering Modes selectable by control bits. The modes are 20,100,200, 350, ......MHz.
So it is hardware filtering. In one past version of FW , 20,100 and 200MHz were available.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: excapealex on February 06, 2014, 11:09:01 pm
@Excapealex No , In a past post and Teardown, you can see there is a Hardware variable Bandwidth Amplifier in the DS2000 (4000, 6000) . This hardware has BW filtering Modes selectable by control bits. The modes are 20,100,200, 350, ......MHz.
So it is hardware filtering. In one past version of FW , 20,100 and 200MHz were available.
Excellent, just what I was hoping for!
Thank you!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on February 07, 2014, 02:36:56 am
I have a DS2072A, not 2302.... its hacked to 300 mhz..
Well... i have tested and not any problem what so ever until now.... And i believe it wont have any problem right ? its just a serial number freeing the functions, not any jailbreak on software really... you can even uninstall everything, update to stock firmware and use the serial that now you have, and it will give you all the options... so, probably just one serial wont give you any instability on the device right ?

As posted already in this and the other thread, the 1ns time base - in the current firmware - is buggy. There are a couple of things that can make the DSO freeze or crash when on - or going to - 1ns setting.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: idpromnut on February 07, 2014, 03:20:45 am
how can we test high frequencies close to 300 ? I dont have any generator.... do you know if i can probe on a computer mainbord something that would be close to those speeds ? like USB port in use, ram memory bus.. i dont know.... what the easiest way to test it at close to 300mhz ?

I don't think there is an "easy" way of testing it; a 300Mhz signal is useless unless you know exactly what it looks like so you can judge how well your scope is able to display it.

Also, the probes that come with the 2072A are 300Mhz if I recall, or 350Mhz, which is getting pretty close to any 300Mhz test signal you might try out.

You could build a Jim Williams pulse generator inspired by one of his app notes (AN47 I believe) which would allow you to get a rough measure of the bandwidth of the scope.  Dave did a video on that in fact.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: RX_Buffer[Broken]; on February 07, 2014, 04:03:19 pm
Hi

I was also curious about performance of the DS2702A pushed to 300Mhz so recently I have done some investigating.
Last week I tested My employers 300Mhz (2gsa/s) Agilent Upto  1Ghz, looking at bandwith and Nyquist response.
1 and 2 channels the later at half sample rate.
I wanted to get a feel for what to expect when I repeat this on the Rigol, However ran out of time and didn't want to stay late!
TODO Next week hopefully.

What I do know for sure is that a Hacked ds2072a(2302A) will display a perfect sine from RF Gen. with no impurities upto 450Mhz (at reduced BW obviously).

The notable dropoff @374Mhz this is were the filter Knee appears to be for mine at least.
And that the 300 Mhz BW option "Tested" as having 1/3 greater BW than the 200Mhz Option logically.
I hope to complete testing and publish results soon.......

And yes Marmad the 1nS time base is prone to locking up the scope when other features are implemented.
 
For me it seemed related to the Rotary Encoders ie:  A fast turn of encoder knobs == lockup.
Hope this is fixed in the future. :-DMM
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Tabs on February 07, 2014, 04:55:07 pm
Hi all,

Firstly, thanks to cybernet, zombie28, marmad and all who have contributed to developing the contents of this thread.

I can confirm the following:
DSA815-TG: Preamp, 10Hz RBW & ADV Measurement unlocks work.

cybernets modified DS4k firmware (DS405xUpdate) has upgraded my DS4014 to 500MHz with 1ns timebase. No observed crashes or negative effects.
DS4k all options unlocked works fine.

I used my DSA815-TG to test the 500MHz BW upgrade on the DS4014.

I used a modified setup as described by Dave in
EEVblog #396 - Bode Plotting on Your Osciloscope (https://www.youtube.com/watch?v=uMH2hGvqhlE#ws)

I set my tracking gen to -20dBm, swept from 0Hz to 1.4GHz with a sweep time of 14 seconds. This corresponds to 100MHz/s.
I set the DS4014 to 1sec timebase, 10mv/dev scale. This represented 100MHz/div over the 14 divisions on the DS4014. Additionally, the horizontal reference for the DS4014 was set to 'Trig Pos', and moved to the extreme left
Both instruments were set to external trigger (negative edge on DSA, pulse mode with pulse width > 1.5sec on DS4k). The trigger was a 5V square wave with 15 second period, generated from my DG4062. (at this speed an arduino could produce the trigger)

The results for different BW limits are attached. An envelope detector on the DS4k would have come in useful (If it exists, its bloody hard to find and I've not checked the manual yet). I measured the TG output with the SA side of the DSA815. An excel plot of the extracted CSV data is attached also. For some reason I cant get the DSA to print screen to a USB.

Also, I was not able to figure out how to save CSV data at controlled time intervals on the DS4k or DSA. The two units seem to default to 600 samples (DSA) and 1400 samples (DS4k). This made it difficult for me to align the two data sets in order to subtract the TG output from the frequency response of the DS4k.

You can visually see that at 500MHz, the weird response is linked to the TG output.
Note the black vertical line is just the oscilloscope trace sweeping accross.
SMA cables were used + SMA to BNC adapters. Cables and connectors are good for 12GHz and result in a 1db (tbc) loss at 1G

Regards

Tabs

Edit: I ended up using advanced math> abs(CH1) for envelope detection.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on February 07, 2014, 09:34:34 pm
Ok, so, I have "upgraded" my scope, kept the bandwidth as I had 200mhz, but all options, very nice solution by zombie28 and tirulerbach.

I got it working by using the hexeditor approach, and rigup, but I could not get it working by using the textfile to list the keys, I could not find the privkey, but atleast i'm up now.
Strange though, the ultrasigma times out so you don't know if you are good or not.

What is also interesting, is that ultrasigma only shows my scope as an ds2202a, not -s, not before, or after the update, and the ultrasigma does not to be an useful app at all, other than issuing idn and installing options, how weird.

Ruu on the other hand looks interresting, only if it will talk to my scope (I don't want to use usb), but I guess I only need to read a bit about that to figure it out.

I would guess that the signalgen commands that are in the programming guide are somewhat similar to other signalgens from rigol?, have anyone created an app to control the signalgen from an computer? similar to what Ruu does?, since it seems like it's an addon inside the rigol I guess it would be possible to use it without it interfering with using the scope?






Title: Re: Sniffing the Rigol's internal I2C bus
Post by: swperk on February 08, 2014, 06:44:44 am
Hello all,

Thanks to everyone for all of their hard work on this project. I find this all very fascinating!

I recently bought a DS2072A and used the rigup program along with the patched firmware to try to upgrade my scope to a fully optioned 300 MHz DS2302A (NS8H). Unfortunately, the key that was generated was rejected by the scope with the message "License is unavailable!". I regenerated the key a couple more times and carefully read it and re-read it to make sure I was inputting it correctly, but it never worked.

Undeterred, I then generated the key for a fully optioned 200 MHz DS2202A (NSEQ) and it worked fine. Has anyone else succesfully upgraded their "A" version scope all the way to 300 MHz? If so, how? I must be missing something...

Regards,
Stan
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: corax on February 08, 2014, 07:38:07 am
Undeterred, I then generated the key for a fully optioned 200 MHz DS2202A (NSEQ) and it worked fine. Has anyone else succesfully upgraded their "A" version scope all the way to 300 MHz? If so, how? I must be missing something...

Yes, I have, as well as others.  I used the patched firmware to dump the keys, which I then put into a file with a hex editor, appending the ASCII serial number after the keys, and terminating the file with a zero.  Named this file ds2072a.bin.

Feeding this to rigup:

  ./rigup ds2072a ds2072a.bin

resulted in output of four possible license code combinations, for options NSEH, NSER, NSEQ, and NSFH.

But from the thread, it was found that NSFH wasn't the right code for 300MHz/all options; the correct code was NS8H.
So I edited the rigup source and recompiled it: change the NSFH code to NS8H on line 21 of luxury.c.

Rerunning rigup produced a license code for NS8H that worked for me.
(This was done in Linux.)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pascal_sweden on February 08, 2014, 07:00:24 pm
Does this hack work now on a DS2072A without opening up your actual scope?
300 MHz and all options? Actual tests to verify stability and BW limit?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: SPRX on February 08, 2014, 11:06:57 pm
Great work by the team working on this thread . . !!

It is time to upgrade my DS1102, and this thread is encouraging.

I may convince my pocket for DS4014 over DS2072A if it is really a good investment. I know the price of DS4014 is more than double + in import-duty bracket.

Could you please let me know if the DS4014 is upgradable successfully to 500MHz with options, if you have done an upgrade on DS4K.


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: madcrow on February 08, 2014, 11:38:14 pm
I just don't get it... Some of you (e.g. at2 and crmaris) were able to install the 300MHz (NS8H) option without difficulty. However corax and swperk only managed it by modifying the rigup source files.
How is this possible? Are there multiple paths you can take with the rigup tool to obtain the serial?

@tirulerbach
Is there any chance you could compile a rigup v0.2 which uses the recently discovered NS8H option instead of NSFH? I think a lot of people would be very grateful :)

And one more question: Do I understand correctly that the same code (NS8H) can used for all the models (2072A ...2202A) to unlock all options?

Thanks!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hari on February 08, 2014, 11:50:34 pm
Is there any chance you could compile a rigup v0.2 which uses the recently discovered NS8H option instead of NSFH? I think a lot of people would be very grateful :)
just change the value in src/luxury.c and recompile. You can also scroll back a few pages to see how you can specify any license code on the command line.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: lovro on February 08, 2014, 11:53:20 pm
Hi,
I have managed to do it also. 200MHz with all options.

Thank you all who were all involved in this project.
EEVblog forum has a lot added value  :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: madcrow on February 09, 2014, 12:00:01 am
Is there any chance you could compile a rigup v0.2 which uses the recently discovered NS8H option instead of NSFH? I think a lot of people would be very grateful :)
just change the value in src/luxury.c and recompile. You can also scroll back a few pages to see how you can specify any license code on the command line.

Do you mean:
Code: [Select]
rigup scan keyfile.txt dump.bin
and
Code: [Select]
rigup license keyfile.txt 0x1C0C7?

In the first command line, is dump.bin the file I create using the Hex editor based on the information spat out by Zombie's patched FW?
Would this work even without modifying luxury.c?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: corax on February 09, 2014, 01:23:30 am
I just don't get it... Some of you (e.g. at2 and crmaris) were able to install the 300MHz (NS8H) option without difficulty. However corax and swperk only managed it by modifying the rigup source files.
How is this possible? Are there multiple paths you can take with the rigup tool to obtain the serial?

As has been pointed out, there's apparently a way to specify the code (as 0x1C0C7) on the command-line.

I edited / recompiled because I had to recompile anyhow- the distributed rigup linux executable is 64-bit, and I needed a 32-bit version.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pa3bca on February 09, 2014, 12:21:26 pm
Proud owner of a 2072A with “enhanced features”. (all of them, including 300 MHz). Thanks guys!
To test the scope, I made a quick&dirty Jim Williams pulse generator, directly on a male BNC connector, see attached picture.
Transistor is a BSX20 I had laying around. This puppy avalanches nicely at around 80 Volts.
1 meg to +120 Volts, 22pF on the collector, and 2x100 Ohms parallel from emitter to ground. Also about a meter of RG58 to the collector to lengthen the pulse. This lengthening works quite nice, see the attached screenshots. Yellow is the pulse on the emitter (input 1 meg as there is no cable between the pulse generator and the scope so termination is not an issue?).
Channel 2 is the voltage on the collector, measured with the 1:10 probe.
It _looks_ like the pulse is long enough to give a somewhat reliable indication of the rise time.
Rise time is abt 700 ps which would yield a bandwidth of 0.4/700x10^-12 = 570 MHz (which sounds a bit optimistic), but certainly way better than the original 70 MHz…
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mauroh on February 09, 2014, 06:16:26 pm
A big THANK YOU!! to all the guys that put all this effort to enhance our toys...
My new DS1074Z just became a wonderful DS1104Z with all Official options  :clap:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gallymimus on February 10, 2014, 03:51:53 pm
Great work by the team working on this thread . . !!

It is time to upgrade my DS1102, and this thread is encouraging.

I may convince my pocket for DS4014 over DS2072A if it is really a good investment. I know the price of DS4014 is more than double + in import-duty bracket.

Could you please let me know if the DS4014 is upgradable successfully to 500MHz with options, if you have done an upgrade on DS4K.

Yes, DS4014 DS4000 series upgrades to 500MHz and options turned on using the keygens works great according to many people.

 Why don't you read the thread or search it so we don't clutter things up answering the same questions too many times.  I know it's a lot to read, but it's a small investment to cheat Rigol and save so much money.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tester42 on February 10, 2014, 07:24:00 pm
Hi everybody,

Thanks for a great job with these scopes!
I have just successfully turned my new DS1074-S into a 1104-S with all options enabled.
The firmware version is 00.02.01SP1. The signal generator is as expected still fully functional.

I'd like to add one thing about entering the Riglol code: The upgrade is not possible during the first 40hours of trial period.
You get a "Invalid Code" message during that time.

I have also found an interesting link about DIY probes  that might interest those of you with faster scopes:
http://koti.kapsi.fi/jahonen/Electronics/DIY%201k%20probe/ (http://koti.kapsi.fi/jahonen/Electronics/DIY%201k%20probe/)

/tester42
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pa3bca on February 10, 2014, 08:58:41 pm
Rise time is abt 700 ps which would yield a bandwidth of 0.4/700x10^-12 = 570 MHz (which sounds a bit optimistic), but certainly way better than the original 70 MHz…
“a bit optimistic” is of course an understatement. But I am a bit at a loss as to how to interpret the rise time I measure with the pulse generator. It _looks_ like it meausere the whole pulse, so…
As a check I also tested my 5 year old OWON PDS7102T – a 100 MHz scope. Risetime measured was a bit above 3 ns (A bit difficult to measure, but not far off), resulting in 133 MHz.  Sounds reasonable. (see attachment). So this measurement seems to yield a more trustworthy result.
But: The OWON only rises to 12 Volts, whereas the upgrades 2072A rises to almost 40 Volts (both measurements with the pulse generator directly to the BNC, 1 meg input).
As a check I used the TG output of my 815-TG at various frequencies (0dBm output) and measured the Vrms reported by the scope. See 2nd attachment.
Note: the output of the 815 TG is not very well defined as we know, which explains the bumps and irregularities, but this measurement shows a bandwidth of just below 400 MHz. Sounds legit.
(nb: boy Am I glad I decided to buy the 2072 and not a new OWON.... ^-^ )
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MatCat on February 10, 2014, 09:00:27 pm
I just spent about 45 minutes going through this thread to try to find it but cant... I am considering getting the DS1074Z, and I am curious where is the info to actually hack it in this thread? :)   Also where is the best place to buy it over here in the US?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on February 10, 2014, 09:05:52 pm
I just spent about 45 minutes going through this thread to try to find it but cant... I am considering getting the DS1074Z, and I am curious where is the info to actually hack it in this thread? :)   Also where is the best place to buy it over here in the US?

rly?

https://www.google.no/#q=code+ds1074z+site:eevblog.com%2Fforum%2Ftestgear%2Fsniffing-the-rigol's-internal-i2c-bus (https://www.google.no/#q=code+ds1074z+site:eevblog.com%2Fforum%2Ftestgear%2Fsniffing-the-rigol's-internal-i2c-bus)
and go to: http://riglol.3owl.com/ (http://riglol.3owl.com/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dr.diesel on February 10, 2014, 09:06:02 pm
Also where is the best place to buy it over here in the US?

http://www.tequipment.net/ (http://www.tequipment.net/)

With discount code EEVBLOG, gets you 6%.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MatCat on February 10, 2014, 09:16:44 pm
Anyone who wants to change their new DS1074Z into a DS1104Z use the following Codes:-

DSHA  makes a  DS1104Z with no options enabled .
DSHR  makes a  DS1104Z with all options enabled .

The 3dB bandwidth for the DS1104Z is approx 160Mhz.
The 3dB bandwidth for the DS1074Z is approx 90Mhz.



Minor correction to my previous post after some further investigation.

DSHA also enables the 500uV setting and another unknown, (at present), option.

DSEA is the correct code to change to a DS1104Z only. ( no options ). See table below.

 Code      DS1104z    Unknown     500uV setting
DSBA                                               X
DSCA                            X
DSDA                            X                 X
DSEA           X
DSFA           X                                  X
DSGA           X               X
DSHA           X               X                 X

So to change a DS1074Z into a DS1104Z with all options enabled except the 500uV/div (which does not work correctly at present),
the code  will be DSER.

It is possible to revert back to original, by using the SCPI command " :SYSTem:OPTion:UNINSTall " .

As mentioned in my previous post, the measured 3dB down bandwidth after changing to a DS1104Z, is approx 160Mhz.
All the tests were done on a DS1074Z with Ver:00.02.00.SP1.
Is this entered in on the screen or done some other way? 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MatCat on February 10, 2014, 09:20:53 pm
Also where is the best place to buy it over here in the US?

http://www.tequipment.net/ (http://www.tequipment.net/)

With discount code EEVBLOG, gets you 6%.
Looks like they are sold out ATM...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MatCat on February 10, 2014, 09:27:39 pm
Also http://riglol.3owl.com/ (http://riglol.3owl.com/) does not  seem to work for me.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Sparky on February 10, 2014, 10:13:27 pm
Also http://riglol.3owl.com/ (http://riglol.3owl.com/) does not  seem to work for me.

Go through an EU proxy (http://www.europeanproxy.com/ (http://www.europeanproxy.com/)) or http://rigol.avotronics.co.uk/mirrors/riglol/ (http://rigol.avotronics.co.uk/mirrors/riglol/)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jrgandara on February 11, 2014, 12:28:04 am
tried to test this keys and I don´t see how to insert "-" between the codes generated in the Rigol keypad. Anyone can shed some ligth?
Thank you!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: madcrow on February 11, 2014, 12:32:05 am
AFAIK, you have to enter the keys without the dashes.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: swperk on February 11, 2014, 03:59:57 am
I've been trying to generate the "300 MHz, all options" license key for my DS2072A with the command "rigup license keyfile.txt NS8H" but the license that is returned is not valid. I substituted "0x1C0C7" for "NS8H" and got the identical invalid license. However, I have used the same command with the NSEQ argument to generate a license for "200 MHz, all options" and that key works as it should. Can anyone help me to figure out the problem?

Thanks,
Stan
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on February 11, 2014, 07:49:31 am
I would use an hex editor and create the binary file instead, it didn't work for me to create the license from the textfile (What did you fill into the pub and privkey?)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on February 11, 2014, 05:48:01 pm
Also http://riglol.3owl.com/ (http://riglol.3owl.com/) does not  seem to work for me.

Go through an EU proxy (http://www.europeanproxy.com/ (http://www.europeanproxy.com/)) or http://rigol.avotronics.co.uk/mirrors/riglol/ (http://rigol.avotronics.co.uk/mirrors/riglol/)
There's two mirror sites of studio25's site: http://riglol.3owl.com (http://riglol.3owl.com)
UK mirror: http://rigol.avotronics.co.uk/mirrors/riglol/ (http://rigol.avotronics.co.uk/mirrors/riglol/)
Canadian mirror: http://www.gotroot.ca/rigol/riglol/ (http://www.gotroot.ca/rigol/riglol/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on February 11, 2014, 06:02:37 pm
I have also found an interesting link about DIY probes  that might interest those of you with faster scopes:
http://koti.kapsi.fi/jahonen/Electronics/DIY%201k%20probe/ (http://koti.kapsi.fi/jahonen/Electronics/DIY%201k%20probe/)
Jahonen, the owner of that website is actually a member of this forum.
He created a topic about this probe here, where you can discuss it: https://www.eevblog.com/forum/projects/cheap-wideband-121-oscilloscope-probe-for-logic-signal-applications/ (https://www.eevblog.com/forum/projects/cheap-wideband-121-oscilloscope-probe-for-logic-signal-applications/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: johnny_canuck on February 11, 2014, 09:26:52 pm
I installed options AAAC, AAAD, AAAE and AAAF on my DSA815TG last year using keys generated with KeyGen V2.0b1. They all work fine.
The DOS version of Riglol returns the same keys as KeyGen.
However, the only web version of riglol.3owl.com that returns the correct keys is from the Canadian mirror site at http://www.gotroot.ca/rigol/riglol. (http://www.gotroot.ca/rigol/riglol.)

Any explanation other than you gotta be a Canuck :-)

Also, option AAAB is the factory installed tracking generator. How about AAAA?

Ken
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: johnny_canuck on February 12, 2014, 03:53:19 am
I just answered (one of) my own questions. In riglol.3owl.com, make sure that the serial number field is completely cleared before entering your serial number. Works fine on all sites including http://www.gotroot.ca/rigol/riglol (http://www.gotroot.ca/rigol/riglol) .

Ken
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: n3ix on February 12, 2014, 07:17:00 pm
Also where is the best place to buy it over here in the US?

http://www.tequipment.net/ (http://www.tequipment.net/)

With discount code EEVBLOG, gets you 6%.

FYI the discount code should be EEVBLOG6.

Robin
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MatCat on February 12, 2014, 07:18:52 pm
Ok I thought the first time I asked where else to buy this scope I was losing my mind and thought I dreamed it when I woke up and saw my post was missing, now I know I am not when I see it disappeared a second time, wtf gives with that?!? I don't like being sensored when I ask where to buy something...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on February 12, 2014, 07:22:37 pm
funny, I noticed that there are other post disapearing also, database issues?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MatCat on February 12, 2014, 07:25:52 pm
funny, I noticed that there are other post disapearing also, database issues?
One post disappears sure, 2 of them with 9 hour spread?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on February 12, 2014, 07:35:38 pm
Dave doesn't delete posts unless the poster requests the deletion, or you're attacking him personally in a post.

Database issues don't usually manifest themselves as posts that are there then gone.  Are you sure you actually posted?  If someone posts after you start writing yours, clicking "Post" will only show you a warning message stating that someone posted while you were writing, and not actually post the message.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MatCat on February 12, 2014, 08:32:29 pm
Dave doesn't delete posts unless the poster requests the deletion, or you're attacking him personally in a post.

Database issues don't usually manifest themselves as posts that are there then gone.  Are you sure you actually posted?  If someone posts after you start writing yours, clicking "Post" will only show you a warning message stating that someone posted while you were writing, and not actually post the message.
I don't think asking where to buy the scope is much of an attack, I can't even see it meriting out of topicness considering the 198 pages of not that useful of posts in this thread... I am stumped and a bit upset over it, I just hope it's not commercial sensoring (trying to prevent mention of other vendors besides sponsors), that would sadden me heavily.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on February 12, 2014, 08:38:26 pm
I don't think asking where to buy the scope is much of an attack, I can't even see it meriting out of topicness considering the 198 pages of not that useful of posts in this thread... I am stumped and a bit upset over it, I just hope it's not commercial sensoring (trying to prevent mention of other vendors besides sponsors), that would sadden me heavily.

I doubt highly that this forum is censored that way.  Every brand under the sun is mentioned on here daily and those posts never go away.

It was either a mistake by a moderator, a moderator with a grudge, or a database or software error.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on February 12, 2014, 10:16:51 pm
Ok I thought the first time I asked where else to buy this scope I was losing my mind and thought I dreamed it when I woke up and saw my post was missing, now I know I am not when I see it disappeared a second time, wtf gives with that?!? I don't like being sensored when I ask where to buy something...
I reported it to the moderators because it's off topic and because this type of discussion tends to go on for a long time. So a moderator must have agreed and have deleted it twice. I thought they would either move the discussion to another/seperate topic or notify you on why it was deleted, but I guess you haven't been informed.
Better start a new topic on where to buy Rigol products or use an existing topic where it's on topic.
It doesn't really have anything to do with hacking Rigol, and it can soon become a long discussion and this topic is already way too long, mostly because people are to lazy to read it and ask the same questions again and again. 90% of the questions asked in this topic has already been answered earlier.
One off topic question + one reply might not be too much of an issue. But in my experience discussions on where to buy Rigol or similar products can go on for pages because everyone has their favourite distributor or one they don't like, and where to find the cheapest products and best service etc.

But this isn't the first time a moderator has deleted of split out off topic posts like this in this topic.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sacherjj on February 13, 2014, 12:25:00 pm
DS4054 received from TEquipment on Tuesday has 00.02.00 Firmware and 1.2 Hardware.

I thought I might have to do something different with the latest firmware that I have, but unlocked all options fine.

Also unlocked the options that we did not purchase on the DSA815-TG.  Rigol got the almost $600 on the options we really need, but the others will be fun for my hobby work.

Thanks for all the hard work on this.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jtizzle on February 13, 2014, 05:41:23 pm
Well I finally ordered my DS2072A-S model... now the wait begins.  I'll post specs as soon as it arrives!  Thanks all.  BTW.  Don't let this thread die! 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: lho on February 13, 2014, 09:02:55 pm
Hi,

I have unlocked all the options on a DS1104Z-S Software release 00.02.00.SP1, everything is ok. :-+
I done it with the http://riglol.3owl.com/ (http://riglol.3owl.com/) key generator and the DSFR - all options.

Just the Vertical 500µV/div not activated, I think I will try the DSBA - 500uV Vertical key tomorrow.

Thank you to all the contributor.
Lho

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dr.diesel on February 13, 2014, 09:05:00 pm
Data point: DS4054 received from TEquipment on Tuesday has 00.02.00 Firmware and 1.2 Hardware.

FYI, firmware 2.01 is out, which fixed some protocol decoding issues I was having.
Title: Update your DS2xxx to DS2302 without cable connections or teardown!!!
Post by: asrc1978 on February 14, 2014, 02:42:09 am
Hello everybody,

Below you can find the instructions to migrate from standard DS2102 non A (100MHz) to an oscilloscope of 300MHz (DS2302) without any cable connection or teardown:

1) The original FW of my DS2102 System Information screen was:
Manufacturer:       RIGOL TECHNOLOGIES
Model:          DS2102
Serial:          DS2A#########
Software version:    00.00.01
Hardware version:    1.0
 
2) At the begining I only use the software "Rigol Keygen v2.0b1" to generate the licence key marking/filling the following options in the software:
- Memory (56M)
- Serial Decode
- Advanced Triggers
- DS2202
- Official
- Option code = DSAZ
- Private Key = 8EEBD4D04C3771

The program generate the following licence key (don't use it in your DS2xxx because maybe don't work properly):
----------------------------------------------------
JDMNBSJ-W8SX28S-VLNA5W3-TAVGZYS
----------------------------------------------------

Introduce the licence key using Utility->Options->Setup->Editor (ON).

Link to download the software:
http://www.gotroot.ca/rigol/RiGen-2b1.zip (http://www.gotroot.ca/rigol/RiGen-2b1.zip)

After enter de licence key and accept it you can restart the oscilloscope and observe in the menu "Installed Options" that new characteristics now are enable.

3) After the installation of new characteristics you can migrate the FW to v00.01.01.00.02. One good thing is that the "Installed Options" where there after migration.
Manufacturer:       RIGOL TECHNOLOGIES
Model:          DS2202
Serial:          DS2A#########
Software version:    00.01.01
Hardware version:    1.0

In the "System Info" screen you can see perfectly the new model of the oscilloscope "DS2202" and in the "Installed Options" the following characteristics available:
- 56MB of memory available.
- Advanced Trigger options available (including Windows, NthEdge, HDTV, Delay, Timeout, Dur, USB).
- Decode (RS232, SPI and I2C, until now without CAN protocol).
- Bandwidth 100M and 200M.

4) We will migrate again the FW to the new version 00.02.01.00.03 (last version until February 13th 2014).
In this case the idea is to migrate the oscilloscope to the last version and then generate a new licence key, now using "Riglol 1.03c" web page and not any software.

The link is:
http://riglol.3owl.com (http://riglol.3owl.com)

To do it you will need to complete again the following options:

Serial: DS2A#########
Options: DSCA (here only use the code of 300MHz version because we need only enable this option)
Privatekey: 8EEBD4D04C3771

Press "Generate" and you will obtain the new licence key:
----------------------------------------------------
FD74GJQ-KLSEP6S-RVSCZNN-878KAWA
----------------------------------------------------

Introduce the new licence key using Utility->Options->Setup->Editor (ON).

Restart and "bualá" you will obtain a 300MHz oscilloscope.

Please if you need something write to me!

Best regards,

Seba from Argentina.
Title: Re: Update your DS2xxx to DS2302 without cable connections or teardown!!!
Post by: danb35 on February 14, 2014, 02:48:23 am
...or just install the current firmware, generate and install one license key.  Is there something new that I'm missing here, or is this all documented in the "Rigol I2C bus" thread?
Title: Re: Update your DS2xxx to DS2302 without cable connections or teardown!!!
Post by: true on February 14, 2014, 02:58:35 am
...or is this all documented in the "Rigol I2C bus" thread?
...which has turned into the "I don't computer so help me keygen my scope" thread.

Yeah, all the info is in there, between the "help me" and "another success! I feel important" posts.
Title: Re: Update your DS2xxx to DS2302 without cable connections or teardown!!!
Post by: jorges on February 14, 2014, 03:30:32 am
Off-topic: @Seba, where did you buy your ds2102 from? I'm also in Argentina struggling to find something else than Owon, Siglent and the now-old ds1052e

Jorge
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sacherjj on February 14, 2014, 12:48:00 pm
Data point: DS4054 received from TEquipment on Tuesday has 00.02.00 Firmware and 1.2 Hardware.

FYI, firmware 2.01 is out, which fixed some protocol decoding issues I was having.

Thanks for the heads up. Just submitted a request in highly efficient and easy to use Rigol firmware update retireval system.  ;)

Just realized that my sarcastic post about getting updated Rigol firmware is post 666. Yeah seems appropriate.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on February 14, 2014, 02:40:02 pm
Data point: DS4054 received from TEquipment on Tuesday has 00.02.00 Firmware and 1.2 Hardware.
FYI, firmware 2.01 is out, which fixed some protocol decoding issues I was having.
Thanks for the heads up. Just submitted a request in highly efficient and easy to use Rigol firmware update retireval system.  ;)

Just realized that my sarcastic post about getting updated Rigol firmware is post 666. Yeah seems appropriate.
You can download FW 2.01 fo MSO/DS4000 here: https://www.eevblog.com/forum/testgear/rigol-mso4000-and-ds4000-tests-bugs-firmware-questions-etc/ (https://www.eevblog.com/forum/testgear/rigol-mso4000-and-ds4000-tests-bugs-firmware-questions-etc/)

Link to the DL folder: https://www.mediafire.com/folder/8zmna1c2yaxhx/Firmwares (https://www.mediafire.com/folder/8zmna1c2yaxhx/Firmwares)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: asrc1978 on February 14, 2014, 04:07:19 pm
Hi AndersAnd,

If somebody needs FW v00.01.01.00.02 or v00.02.01.00.03 for DS2xxx oscilloscopes please let me know, maybe there are helpful to perform the upgrading.

Thanks.

Best regards,

Seba from Argentina.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: asrc1978 on February 14, 2014, 04:23:08 pm
Hi everybody,

Here I added two pictures with the results of my migration.

On the other hand I receive and aswer from Rigol China in that they explain that the difference between DS2xxx non A and DS2xxxA is the selectable input impedance between 1Mohms and 50ohms.

Please somebody can explain if it is true or not?

Thanks by the help.

Best regards,

Seba.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on February 14, 2014, 04:31:22 pm
Hi AndersAnd,

Please, can you indicate to me if is possible to create here a link to download the FWs for DS2000?

I have te files of FW v00.01.01.00.02 and v00.02.01.00.03 and maybe it is helpful to perform the upgrading.
These FW files are already available here: https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684 (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: asrc1978 on February 14, 2014, 04:36:49 pm
Thank you AndersAnd!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: stuartk on February 14, 2014, 05:23:44 pm
Quote
On the other hand I receive and aswer from Rigol China in that they explain that the difference between DS2xxx non A and DS2xxxA is the selectable input impedance between 1Mohms and 50ohms.

Yes that's true. The A version has the 50 ohm hardware installed on the board, the non-A version does not. The menu should show 1meg only option which if I remember is greyed out

BTW, I don't think that you should have the 100Mhz BW and 200mhz BW options installed together with the 300Mhz. It probably happened if you installed one key after another. Check  and see if you minimum timebase goes down to 1ns. The 100mhz option goes to 5ns and the 200Mhz option goes to 2ns.

Regards,

Stuart
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: asrc1978 on February 14, 2014, 05:38:35 pm
Quote
On the other hand I receive and aswer from Rigol China in that they explain that the difference between DS2xxx non A and DS2xxxA is the selectable input impedance between 1Mohms and 50ohms.

Yes that's true. The A version has the 50 ohm hardware installed on the board, the non-A version does not. The menu should show 1meg only option which if I remember is greyed out

BTW, I don't think that you should have the 100Mhz BW and 200mhz BW options installed together with the 300Mhz. It probably happened if you installed one key after another. Check  and see if you minimum timebase goes down to 1ns. The 100mhz option goes to 5ns and the 200Mhz option goes to 2ns.

Regards,

Stuart

Hi Stuart,

Below you find that the timebase can achieve 1ns. Can you recommend to me to change the licence key to try to change the "Installed Options" showing only BTW 300MHz?

Thanks by your help.

BR,

Seba.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: asrc1978 on February 14, 2014, 05:46:23 pm
Hi Everybody,

Anyone ever could uninstall options?

For example, in the picture you will see:

BANDWIDTH    100M BandWidth  Official Version
                       200M BandWidth  Official Version
                       300M BandWidth  Official Version

Thanks again by your help!

BR,

Seba.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: stuartk on February 14, 2014, 06:16:03 pm
I had a similar situation and I elected to uninstall my keys using  the SCPI command " :SYSTem:OPTion:UNINSTall
And then did a fresh instal with DSGH for 300 MHz with all options except 50 ohm

Unfortunately I lost my serial number in the process.....
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: asrc1978 on February 14, 2014, 06:27:50 pm
I had a similar situation and I elected to uninstall my keys using  the SCPI command " :SYSTem:OPTion:UNINSTall
And then did a fresh instal with DSGH for 300 MHz with all options except 50 ohm

Unfortunately I lost my serial number in the process.....

Hi Stuart,

Mmmm, maybe a make a mistake because I made the licence code using DSHH option.

On the other hand, to send a SCPI command; what port did you use?

Thanks.

BR,

Seba.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: stuartk on February 14, 2014, 07:18:54 pm
Quote
On the other hand, to send a SCPI command; what port did you use?

You have to right click on your scopes USB connection in the main window of Ultra-Sigma. I doubt the problem was with DSHH. It was likely due to installing several keys on on top of the other.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: asrc1978 on February 14, 2014, 08:20:49 pm
Thanks Stuart!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: asrc1978 on February 14, 2014, 10:37:36 pm
I applied the sentence ":SYSTem:OPTion:UNINSTall" through SCPI Panel Control using the following versions of software and the S/N don't change:

NI VISA V5.4.0
Ultra Sigma V00.01.05.10

After it I generated and loaded a licence key using the code DSGH, now the "Installed Options" screen looks like the picture and the serial number is the same.

Thanks again.

Seba.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on February 14, 2014, 11:51:20 pm
I don't recall that anyone has ever reported that having all 3 BW's listed actually caused any operational problems?  Just uses a bit more screen space, in the list.

I.e., the scope isn't "confused" about it's "true identity", and behaves improperly.  Does it?

I'm just wondering why people care, unless there's a functional disadvantage I missed reading about.  Always a possibility in this thread.

(And yes, I'm aware of the potential issues that can arise, simply by enabling 300 MHz.  And thus why it's not recommended.)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: asrc1978 on February 15, 2014, 12:19:12 am
I don't recall that anyone has ever reported that having all 3 BW's listed actually caused any operational problems?  Just uses a bit more screen space, in the list.

I.e., the scope isn't "confused" about it's "true identity", and behaves improperly.  Does it?

I'm just wondering why people care, unless there's a functional disadvantage I missed reading about.  Always a possibility in this thread.

(And yes, I'm aware of the potential issues that can arise, simply by enabling 300 MHz.  And thus why it's not recommended.)

Hi Mark,

I can tell you that the hardware is the same for 70MHz, 100MHz, 200MHz. In the new models (DS2xxxA) the only one difference is the selectable input impedance (between 50ohm and 1Mohm) and this only to improve the measurement at high frequencies (in the case of DS2303A at 300MHz). In this case the hardware is Rev. 2.

At the end of the day is the same, you can use hardware to achieve BTW of 300MHz using a inpedance of 1Mohm with certain disadvantages in the measurement.

Thanks.

BR.

Seba.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sacherjj on February 15, 2014, 03:48:56 pm
Thanks for the heads up. Just submitted a request in highly efficient and easy to use Rigol firmware update retireval system.  ;)

Just realized that my sarcastic post about getting updated Rigol firmware is post 666. Yeah seems appropriate.

Guess I need to take up for Rigol service, after my snide comment.  Less than 24 hours after asking through the form, I had both DSA815 and DS4k series firmware updates.  Not as good as downloading from a site, but not terrible.  Although, from the future I'll just download from the EEVblog firmware repository.  That seems simpler.   :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ch.onillon on February 15, 2014, 10:56:07 pm
really really excellent this blog ... i never heard about rigol oscilloscope before but since i know we can upgrade it so easilly i want buy the 2072 ... and now up to 300 MHz , it s a must to have. i think since rigol won in delivery ..

the most difficult is now to follow allthe post on this thread .....
i learn Every days on this site.
 
next buy ? one 2072 of course :-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: menkelis on February 16, 2014, 01:31:39 am
Just wanted to say that because of the high level of excellent information in this blog
I just purchased a 2072A (with $50 discount) from TEquipment.

I have been a long time Tektronix user (and ex employee) and was quite impressed
with the comments made. I can also say that the option of 'unlocking' extended options
fits in very well with me, as this is something that even Tek did/does with common hardware.

So now my two Tek digital scopes (222 & 224) have been donated to the Vintage Tek museum
where I volunteer as there IT  administrator.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NYG on February 16, 2014, 02:16:42 am
I bought a DS2072A myself and just received it a few days ago. I really wasn't sure if I should get this or the DS1074z. I'm just a hobbyist getting back into it again. I dusted off my old TWD120 the other day and was surprised the windows '98 laptop that controls it still worked.

In any event the scope looks and feels like a piece of quality gear. A lot more functionality than I'm used to and more than I'm sure I'll ever need.

The last 20 pages or so should really give you all the information you need for plugging a new key in.

Some very smart people on this board. I'm glad to have stumbled upon it and happy to have this as a resource now.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Laertes on February 16, 2014, 03:19:33 am
Please don't shout at me if that's a stupid question, but quick googling turned up nothing much...
Is the DS1000Z-Series hack capable of upgrading a 70MHz-Version to 100MHz or can you not get that?
Otherwise, I probably just have to get the 100MHz version.

Great stuff, though!  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on February 16, 2014, 03:25:33 am
Is the DS1000Z-Series hack capable of upgrading a 70MHz-Version to 100MHz or can you not get that?

Yes.  You cannot later hack in the signal generator, though, so if you'll ever need an entry level signal generator in this scope, get it at purchase-time.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MrAureliusR on February 16, 2014, 03:26:03 am
Yet another sale because of this hack for Rigol --

Going to purchase the DS2072A as soon as possible. I'm assuming that the DS2072A-S (with the signal gen) will work the same? Or is the firmware different enough that it doesn't work?

Thanks a million guys -- let me know if there's somewhere I can contribute to your further work! :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on February 16, 2014, 03:27:30 am
I'm assuming that the DS2072A-S (with the signal gen) will work the same? Or is the firmware different enough that it doesn't work?

On the DS1074Z-S hacking the extra features on (thus making it a DS1104Z) does not disable the signal generator.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Laertes on February 16, 2014, 04:35:46 am
Is the DS1000Z-Series hack capable of upgrading a 70MHz-Version to 100MHz or can you not get that?

Yes.  You cannot later hack in the signal generator, though, so if you'll ever need an entry level signal generator in this scope, get it at purchase-time.

Yay! Thanks a bunch, mighty rigol hacker gods ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on February 16, 2014, 12:50:31 pm
Going to purchase the DS2072A as soon as possible. I'm assuming that the DS2072A-S (with the signal gen) will work the same? Or is the firmware different enough that it doesn't work?
If you had read the topic you would know. They use the same FW and neslekkim has already successfully hacked his DS2202A-S.
Read here: https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg381430/#msg381430 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg381430/#msg381430)
And here: https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg383529/#msg383529 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg383529/#msg383529)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: anson80 on February 16, 2014, 08:00:07 pm
I've been trying to generate the "300 MHz, all options" license key for my DS2072A with the command "rigup license keyfile.txt NS8H" but the license that is returned is not valid. I substituted "0x1C0C7" for "NS8H" and got the identical invalid license. However, I have used the same command with the NSEQ argument to generate a license for "200 MHz, all options" and that key works as it should. Can anyone help me to figure out the problem?

Thanks,
Stan
I have the same problem,You solve the problem?
the rigup license keyfile.txt 0x1C0C7(NS8H) key that was generated was rejected by the scope with the message "License is unavailable!".
the rigup license keyfile.txt 0x1C097(NSEQ) argument to generate a license for "200 MHz, all options" is OK.
I was DS2102A
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NYG on February 17, 2014, 12:24:25 am
I've been trying to generate the "300 MHz, all options" license key for my DS2072A with the command "rigup license keyfile.txt NS8H" but the license that is returned is not valid. I substituted "0x1C0C7" for "NS8H" and got the identical invalid license. However, I have used the same command with the NSEQ argument to generate a license for "200 MHz, all options" and that key works as it should. Can anyone help me to figure out the problem?

Thanks,
Stan
I have the same problem,You solve the problem?
the rigup license keyfile.txt 0x1C0C7(NS8H) key that was generated was rejected by the scope with the message "License is unavailable!".
the rigup license keyfile.txt 0x1C097(NSEQ) argument to generate a license for "200 MHz, all options" is OK.
I was DS2102A

I'm guessing you used the firmware that uses the non-A version key algorithm? There are two versions of keying that can be used. They both work, but I focused on the "A" version so the rigup command I used was different.

I also had to modify the rigup source to have it display the NS8H key. The information on that is on page 195 I believe.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: anson80 on February 17, 2014, 03:53:38 am
I've been trying to generate the "300 MHz, all options" license key for my DS2072A with the command "rigup license keyfile.txt NS8H" but the license that is returned is not valid. I substituted "0x1C0C7" for "NS8H" and got the identical invalid license. However, I have used the same command with the NSEQ argument to generate a license for "200 MHz, all options" and that key works as it should. Can anyone help me to figure out the problem?

Thanks,
Stan
I have the same problem,You solve the problem?
the rigup license keyfile.txt 0x1C0C7(NS8H) key that was generated was rejected by the scope with the message "License is unavailable!".
the rigup license keyfile.txt 0x1C097(NSEQ) argument to generate a license for "200 MHz, all options" is OK.
I was DS2102A

I'm guessing you used the firmware that uses the non-A version key algorithm? There are two versions of keying that can be used. They both work, but I focused on the "A" version so the rigup command I used was different.

I also had to modify the rigup source to have it display the NS8H key. The information on that is on page 195 I believe.
I use the new version of the A firmware,the Rigup license keyfile.txt 0x1C097 (NSEQ) is normal work of the.
I have reference corax articles change the NSFH code to NS8H on line 21 of luxury.c.But no effect under my Windows 7 64 bit
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NYG on February 17, 2014, 04:22:09 am
That's interesting. I'm using the "A" code, but I ran ./rigup ds2072a mykeyfile .
After doing that it just listed the keys for me. The NS8H key installed without a problem.

BTW I used Linux to modify/run rigup but I would expect the same results in windows.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: anson80 on February 17, 2014, 02:15:01 pm
That's interesting. I'm using the "A" code, but I ran ./rigup ds2072a mykeyfile .
After doing that it just listed the keys for me. The NS8H key installed without a problem.

BTW I used Linux to modify/run rigup but I would expect the same results in windows.
Thank you, I will try at Linux :(
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: anson80 on February 18, 2014, 02:47:55 pm
I seem to find NS8H (0x1C0C7) position is not in the correct 300M KEY on my device.
NSEQ (0x1C097) position is correct, and can be used Rigup license keyfile.txt 0x1C097 (NSEQ) is normal work
Its DS2102A sequence number is DS2D1549... Seems to be 49 weeks of products
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MrAureliusR on February 18, 2014, 04:01:38 pm
Just a quick question (I have already read through almost the whole thread)

Has anyone run into problems using the 300MHz unlock?

And is it better to generate all the keys individually instead of just using the "ALL" option? (ie, generate 300MHz, serial, mem, etc and then enter them one by one?)

EDIT: Dear God this thread is confusing. Someone REALLY needs to write a summary. I'm a pretty experienced software guy and I kept getting lost.

It seems there are two different ways to unlock features, depending on whether or not you have the A version. Though I can't find it stated explicitly, I've inferred that if you try to use the keygens with the new A models they won't work unless you first install the patched firmware.

Am I correct in that? When I receive my DS2072A in the next month or so, I should use a USB stick to install the patched firmware, and THEN generate the keys using the keygen, and install? It seems that the patched firmware is an older version -- obviously upgrading to a newer firmware will disable the upgrades, correct? Never mind, apparently it's the latest firmware, but patched.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hari on February 18, 2014, 05:59:18 pm
Just a quick question (I have already read through almost the whole thread)
then you would probably not ask these questions..

Quote
EDIT: Dear God this thread is confusing. Someone REALLY needs to write a summary. I'm a pretty experienced software guy and I kept getting lost.
better read the thread again :-) Scroll back some pages, there is a nice summary.

Quote
It seems there are two different ways to unlock features, depending on whether or not you have the A version. Though I can't find it stated explicitly, I've inferred that if you try to use the keygens with the new A models they won't work unless you first install the patched firmware.
both approaches for the A version involve custom firmware. One allows to use the old keys, and the other spits out the keys needed for the new keygen via SCPI. The latter method allows to use stock firmware after the keys have been extracted.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MrAureliusR on February 18, 2014, 06:01:33 pm
I have read most of the thread, but it's 61 pages!! It's crazy. And where is the summary? I can't find a summary that includes both methods and the steps required.

I'd be happy to write one myself, or even start a separate thread with all the instructions, plus a video showing me doing it with my scope. I just need to understand which method is better, and figure out which firmware is which etc. I guess I'll try and slug through the whole thread.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hari on February 18, 2014, 06:05:10 pm
Summary for the 2xxxA version:

Variant a (patched firmware):

- get the patched firmware that enables to use old keys
- load it onto the scope
- use the old key

Variant b:

- get the patched firmware that reads out the keys from the scope
- load it onto the scope
- use SCPI to read out the keys
- load official firmware on the scope
- use new keygen with the keys extracted via SCPI


ps: the guy who wrote the keygen said "no pain, no gain". The easier this is, the more effort will be taken from rigol to make unlocker's life harder..
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MrAureliusR on February 18, 2014, 06:09:10 pm
That's true. Thanks for the summary though, that's all I needed to understand!

EDIT: Is there a re-host for the official firmware somewhere? I thought I saw a link in the thread but now I can't find it... the Rigol downloads are horrifically slow. I was trying to download the Ultra Sigma software and then realized Batronix not only hosts it but they have a newer version than on the Rigol website!!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hari on February 18, 2014, 06:21:11 pm
you can use telnet on port 5555 to talk SCPI, no need for ultra sigma..

stock firmware: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg342994/#msg342994 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg342994/#msg342994)
sha: ddf1d511823eaf31f1d05af2ba845543d97c6d3a
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MrAureliusR on February 18, 2014, 06:23:21 pm
you can use telnet on port 5555 to talk SCPI, no need for ultra sigma..

another proof that you didn't read the thread :-p

stock firmware: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg342994/#msg342994 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg342994/#msg342994)
sha: ddf1d511823eaf31f1d05af2ba845543d97c6d3a

Actually, I DID READ THE THREAD, it's really annoying that you're trying to 'prove' that I didn't. I know I could use telnet, but I figured I'd end up downloading the Rigol software anyway, and so why not just use it?

If that fails I'll use realterm or PuTTY and use telnet.

Like, why would you assume that because I'm downloading Ultra Sigma I didn't read the thread? They actually mention a couple posts apart both methods.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hari on February 18, 2014, 06:25:51 pm
it's really annoying that you're trying to 'prove' that I didn't.
I realised that this was unqualified right after posting, so I've already edited my post.

Quote
Like, why would you assume that because I'm downloading Ultra Sigma I didn't read the thread?
Just for the records, this was referring to the firmware file, not telnet.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mrflibble on February 18, 2014, 06:44:25 pm
I'd be happy to write one myself, or even start a separate thread with all the instructions, plus a video showing me doing it with my scope. I just need to understand which method is better, and figure out which firmware is which etc. I guess I'll try and slug through the whole thread.

In the interest of future n00bs, please do. Write a summary of the installation procedure that is easy to follow for others I mean. Otherwise you are just another "me too" never to be heard of again after they fixed stuff for themselves. :P See enough of that shit in other threads already. ;) Notably the Flir E4 thread.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on February 18, 2014, 08:13:06 pm
I have read most of the thread, but it's 61 pages!! It's crazy. And where is the summary? I can't find a summary that includes both methods and the steps required.

I'd be happy to write one myself, or even start a separate thread with all the instructions, plus a video showing me doing it with my scope. I just need to understand which method is better, and figure out which firmware is which etc. I guess I'll try and slug through the whole thread.

around the pages here https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/2835/ (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/2835/) there is a good summary.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: GlassFET on February 18, 2014, 08:38:19 pm
New here. I'm an experienced analog engineer, but an IT neophyte, so please go easy on me for what could be a stupid question:

I want to hack a DS2102A. My software version is 00.02.00, never touched. I am nervous about messing up the unit, so I tried to "dry run" some of the procedure WITHOUT first loading the hacked FW, just to get a handle on it before taking that first step. When I perform the "*IDN?" query in UltraSigma, it returns: "RIGOL TECHNOLOGIES,DS2102A,DS2D15xxxxxxx,00.02.00". I do not see the string beginning with "02008400..." that I was expecting.

So, is this simply because I have not yet loaded the hacked FW which would enable the correct response, or something else I'm doing wrong?

Thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: corax on February 18, 2014, 08:41:24 pm
So, is this simply because I have not yet loaded the hacked FW which would enable the correct response, or something else I'm doing wrong?

Yes.  That's the point of the hacked firmware- to add a dump of the keys to that output.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: GlassFET on February 18, 2014, 08:46:27 pm
Corax,

Thanks for answering my simpleton question. OK, I guess I will have to "bite the bullet" and load the revised FW then.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on February 18, 2014, 08:51:25 pm
Read the url I posted right above your question, everything is written there..
you only need the hacked firmware to get the keys out, save them, and use rigup to create the license.
You can choose to revert to latest official firmware, no need to keep the hacked in the scope.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: GlassFET on February 18, 2014, 08:58:13 pm
That's wonderful. Thanks to all.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MrAureliusR on February 18, 2014, 10:33:53 pm
I'd be happy to write one myself, or even start a separate thread with all the instructions, plus a video showing me doing it with my scope. I just need to understand which method is better, and figure out which firmware is which etc. I guess I'll try and slug through the whole thread.

In the interest of future n00bs, please do. Write a summary of the installation procedure that is easy to follow for others I mean. Otherwise you are just another "me too" never to be heard of again after they fixed stuff for themselves. :P See enough of that shit in other threads already. ;) Notably the Flir E4 thread.


That was exactly what I was trying to avoid -- I am not by any means new to forums. I've been using them for almost ten years and I know the etiquette. However, I also know what constitutes a good, well-organized thread -- and this is far from it. I understand that the easier it is, the more Rigol will try and stomp it out, but that will never fully happen. As long as you can update firmware, the hacks we have now will never be undone.

Plus, if I do make a video and instructions, I will re-host all the files myself, and post it elsewhere so it doesn't get fully associated. As soon as I have a walkthrough video done I will let interested parties know.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Nebukad on February 18, 2014, 10:51:07 pm
I've done this Hack on my DS2072A-S, so if it works with this one, it will also work with any other 2xxx.
Here is, what you have to do:

1) Download https://mega.co.nz/#!MdcEWTgL!0EEmSr-Q6TxaFSsyEmjhRrgqDvFCoXg9K49BalL5Uxc
2) Install this firmware during bootup - check Rigol's guide on how to do that
3) Connect the scope to a PC using USB.
4) Install and start "Rigol Ultra Sigma", right click on your scope, open "SCPI Control Panel" and "Send&Read" string "*IDN?"
5) Copy string from comma after serial # of your DS2xxxA to the end ("02008400...").
6) Open HEX editor, create a new file and paste string as HEX (not ASCII).
7) Copy serial # of your DS2xxxA.
8) Append serial # as ASCII to the data in HEX editor.
9) Append "00" as HEX.
10) Save file as "keyfile.bin" to folder with "rigup" (https://mega.co.nz/#!qAkUkTZB!XG12bUKhIz4CmQt6DbBnGRMvEe5AvUjEaBxi4R03tw8).
11) Open command line and navigate to folder with "rigup".
12) Execute "rigup scan keyfile.bin" and get some keys:

RC5KEY1:        88359067012Exxxxxxxxxxxxxxxxxxx
RC5KEY2:        3D44CD4EC48Fxxxxxxxxxxxxxxxxxxx
XXTEAKEY:       95F6CC12864Axxxxxxxxxxxxxxxxxxx
PUBKEY:         006CE7F7xxxxxxxx
PRIVKEY:        008ABBC4xxxxxxxx
SERIAL:         DS2D154xxxxxx

13) Copy them to another text file "keyfile.txt" in "rigup" folder.
14) Execute "rigup license keyfile.txt NSxx", where:

NSEH (0x1C087) - All options
NSER (0x1C08F) - 100 MHz + all options
NSEQ (0x1C097) - 200 MHz + all options
NS8H (0x1C0C7) - 300 MHz + all options

15) Copy license key.
16) In "Rigol Ultra Sigma" -> "SCPI Control Panel"" -> "Send&Read" ":SYSTem:OPTion:INSTall YOURLICENSEKEYWITHOUTDASHES".

This is Variant b.
Thx Fagear for the instructions and of course big thanks to zombie28 and tirulerbach, who made this hack possible!
Title: Re: hacking dp832
Post by: jkw13 on February 19, 2014, 01:22:21 am
It's now Firmware version  00.01.09 for the DP800 Series including the DP832 (non A).  And I understand that it's not good news with all options lost, and no way to go back to FW 06, or 08.

Note: This Firmware has been provided to DP832 (non A) users by Rigol for those that had requested a FW Update for their units.

Ref.  RIGOL DP832 Power Supply - firmware upgrade, « Reply #36 on: Yesterday at 03:38:23 AM »   Although I don't think Rigol supplied this particular person his FW 09.

In the post you reference, Sebastian states "the Riglol Keys don't work" --- which is no different from 01.08 where they didn't work either (and why people downgraded to 01.06 to install the keys and then upgraded to 01.08). 

How exactly are you concluding "all options lost"?

The trick with getting the options in 1.06 and then upgrading to 1.08 never worked for me. If I would install all the options in 1.06 and upgrade to 1.08 everything would be lost, not just the trigger option as other people here report for there units. If I would then go back to 1.06 the options would be there again without entering the codes again.
FW1.09 is essentially the same as 1.08, none of the bugs are fixed, the only difference is that you can not flash older versions anymore because of the new bootloader,


Same thing happened to me, I stupidly did the 1.09 upgrade also :palm:
Had it all calibrated in 1.06, but found the bugs too annoying.
Bu**er :scared:
Maybe one day some brlliant person will find a way around this??


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Giggy on February 19, 2014, 03:18:06 am
Hey Guys,

Finally got around to hacking my oscilloscope (DS2072A) and it went well, I have enabled 300MHz bandwidth with all options.
I decided to document my process with a good amount of detail and have created a PDF. I recommend anyone who would like
to hack their to view this. I had to upload the file elsewhere because of the 2mb imposed on us my eevblog.

The document was generated from information collected from this thread, thanks to all those whom contributed.

If there are any recommendations/revisions for the document let me know.

All the Best.

- Please view revised post on page 204 -

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on February 19, 2014, 02:14:50 pm
by the way, has anyone tried anything (hack/poke around) on the newer DS1xxx series?
Yes.  Please take the time to read the thread.
Title: Now what?
Post by: GlassFET on February 19, 2014, 06:31:59 pm
OK, I flashed my DS2102A with Zombie28's hacked FW. I verified that it had flashed because the system now shows that version 00.02.01 is loaded and it was 00.02.00 before.

When I run Ultra Sigma and do the *IDN? query, I get:

-> *IDN?
<- (Return Count:50)
RIGOL TECHNOLOGIES,DS2102A,DS2D15xxxxxxx,00.02.01

I tried reflashing and was very careful to use the correct DS2000update.gel file. Same result.

This is the same behavior I saw before with my original un-hacked FW. I'm not getting the long string for the key as expected.  Huh?

Any ideas? What am I doing wrong?

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: GlassFET on February 19, 2014, 06:51:57 pm
Re: My prior post just above. I tried re-flashing a third time (same hacked FW file) and this time I got the key string in Ultra Sigma. Strange.

On the prior two attempts I noticed that my free option trials had vanished. Upon rebooting after this third flash, the welcome screen showed my trials again.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: GlassFET on February 19, 2014, 07:31:34 pm
OK, success! 300MHz+ all options. A thanks to all the smart people who made this possible!

A question: I understand that I may still flash new FW without losing these options. But, if I keep Zombie28's FW in the scope, will it perform identically to regular 00.02.01.00.03 FW? In other words, any reason to replace the FW with un-hacked FW? I don't want to tempt fate...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on February 19, 2014, 10:43:40 pm
Read what I wrote to you on the previous page..
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on February 19, 2014, 10:57:29 pm
How many of you are upgrading because you can vs. upgrading for features you need?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: GlassFET on February 19, 2014, 11:12:15 pm
Read what I wrote to you on the previous page..

Yes I did read your post that there is no need to keep the hacked firmware. That's different from my question, which is there any performance limitation in the hacked software that would drive one to replace it with original FW? The flashing process posed me some problems having to do with the USB connector or size of my USB stick. If I don't have to replace it to recover some feature or capability, I'll leave it with the hacked FW.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on February 19, 2014, 11:15:07 pm
If it is the same version as the last, just keep it, but don't let it stop you from upgrading.
I used an 4gb sandisk, worked very good, but the rigol is kinda picky about the usb stick, and that is also documented in the official firmware upgrade doc. (It states that you need to test the usb sticks on the rigol before you attemt to start upgrading)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: GlassFET on February 19, 2014, 11:28:16 pm
If it is the same version as the last, just keep it, but don't let it stop you from upgrading.
I used an 4gb sandisk, worked very good, but the rigol is kinda picky about the usb stick, and that is also documented in the official firmware upgrade doc. (It states that you need to test the usb sticks on the rigol before you attemt to start upgrading)

I think that USB memory stick compatibility must have been the issue, requiring three flashing attempts. The smallest stick I could find around here was 8GB, so that's what I used. I've read that the stick should be less than 4GB, or less than 8GB, depending on which source you read, so I knew I was close to the edge. I did read (some of us actually DO read instructions) about inserting the stick and looking for "USB detected" as a test. That test worked fine, and I was able to print a screen image to the stick, so I thought I was good-to-go. I will have to find a 2GB or 4GB stick someplace. (Perhaps one can't buy them that small anymore?). But in the meantime I wanted to keep Zombie28's FW and use the scope without worrying about performance issues. Thanks.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: commongrounder on February 20, 2014, 12:36:03 am
If it is the same version as the last, just keep it, but don't let it stop you from upgrading.
I used an 4gb sandisk, worked very good, but the rigol is kinda picky about the usb stick, and that is also documented in the official firmware upgrade doc. (It states that you need to test the usb sticks on the rigol before you attemt to start upgrading)

I think that USB memory stick compatibility must have been the issue, requiring three flashing attempts. The smallest stick I could find around here was 8GB, so that's what I used. I've read that the stick should be less than 4GB, or less than 8GB, depending on which source you read, so I knew I was close to the edge. I did read (some of us actually DO read instructions) about inserting the stick and looking for "USB detected" as a test. That test worked fine, and I was able to print a screen image to the stick, so I thought I was good-to-go. I will have to find a 2GB or 4GB stick someplace. (Perhaps one can't buy them that small anymore?). But in the meantime I wanted to keep Zombie28's FW and use the scope without worrying about performance issues. Thanks.

I'm so glad I kept a bunch of those old 1GB USB flash drives around.  They all work perfectly in my DS4000 series 'scope.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Giggy on February 20, 2014, 01:22:20 am
Hey Guys,

Finally got around to hacking my oscilloscope (DS2072A) and it went well, I have enabled 300MHz bandwidth with all options.
I decided to document my process with a good amount of detail and have created a PDF. I recommend anyone who would like
to hack their to view this. I had to upload the file elsewhere because of the 2mb imposed on us my eevblog.

The document was generated from information collected from this thread, thanks to all those whom contributed.

If there are any recommendations/revisions for the document let me know.

All the Best.

http://www.mediafire.com/view/2avoeclmwvvlfsf/DS2072A.pdf (http://www.mediafire.com/view/2avoeclmwvvlfsf/DS2072A.pdf)

mediafire is not happy with me trying to download the PDF ...
will you be so kind to email it to me? 3roomlab at gmail dort com :p

by the way, has anyone tried anything (hack/poke around) on the newer DS1xxx series?

Are you able to view online? It comes up in a pdf reader for me?

Sent it off to you, let me know if you receive it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NYG on February 20, 2014, 04:49:10 am
tnx giggy, got it.
(yes i was able to see it online, but i cant R-click to save as)
(and maybe since im un-decided over which DSO to get, maybe i should just get the one with the better graduation which displays slightly more like an agilent)

When I first saw that video I was concerned so I hooked my new DS2072A up to a video signal. It looks great. No issues.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NYG on February 20, 2014, 06:42:32 am
Not as nice as that Agilent but I'm pleased with it.

Hopefully this works..



Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on February 20, 2014, 06:51:01 am
tnx giggy, got it.
(yes i was able to see it online, but i cant R-click to save as)
Just click the big green download button here: http://www.mediafire.com/download/2avoeclmwvvlfsf/DS2072A.pdf (http://www.mediafire.com/download/2avoeclmwvvlfsf/DS2072A.pdf)
Right-clicking doesn't work.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on February 20, 2014, 06:58:06 am
i am sitting on the fence between 1104ZS and 2072, and so far ive only managed to reach page 18 before i realized i woke up and its morning lol ...

well the reason for the fence sitting is because of this video
Intensity grading comparison of Rigols DS1104Z, DS2202,and Agilent DSOX3404 (https://www.youtube.com/watch?v=nf5QSr4zXHw#ws)

does anyone think that any of the later firmwares have any effect/improvement on the graduation/shades of the 2072? (sorry it may sound like a nitty gritty Qn)
Off topic. Please don't discuss which scope to buy and compare features in this topic. It's about hacking the scopes, not buying advice.

This video comparison has already been discussed here: https://www.eevblog.com/forum/testgear/intensity-grading-comparison-rigol%27s-ds1104z-ds2202-and-agilent-dsox3404/msg350384/#msg350384 (https://www.eevblog.com/forum/testgear/intensity-grading-comparison-rigol%27s-ds1104z-ds2202-and-agilent-dsox3404/msg350384/#msg350384)
and here: https://www.eevblog.com/forum/testgear/rigol-ds1104z-26242/msg379113/#msg379113 (https://www.eevblog.com/forum/testgear/rigol-ds1104z-26242/msg379113/#msg379113)

So please keep this discussion in those topics instead. This hacking topic is already way too long as it is, without all the off topic discussions.

And for discussing features, FW bugs etc. for DS2000 series scopes please also read this topic:
REVIEW - Rigol DS2072 - First Impressions of the DS2000 series from Rigol https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/ (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tom66 on February 20, 2014, 10:34:05 am
Does DS2072A still use DSA9 prefix and option codes?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on February 20, 2014, 06:17:11 pm
It's been a while since I've monitored this thread and it appears plenty of progress has been made. Excellent work everyone!

Took the opportunity to mirror a bunch more useful files permanently at http://www.gotroot.ca/rigol (http://www.gotroot.ca/rigol) as well as setting up a cron job to pull down the complete thread every day as well. If there's anything else that should be there, send me files or PMs and I will make it so.

How do you pull this thread?, Would it be possible to include the messagenr in the postheader or postbody?, when I'm searching in the file now, it's difficult to find the post on the forum, with an id one could construct the url, or maybe include the a-href info which looks like this:

a href="msg391147/#msg391147"



Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on February 20, 2014, 06:29:28 pm
Does DS2072A still use DSA9 prefix and option codes?

It doesn't even use the same keygen, necessarily.

read back several pages.  If you see DS2072A then you need to start further in the past. 

Legwork would save many people many questions.  I know there's a lot to read, but you're potentially saving thousands of dollars, here.  Take the time and read.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: KA3YAN on February 21, 2014, 04:00:43 pm
I can confirm that the process works for unlocking 200MHz and all options on the DS2102A.  I didn't attempt 300MHz because the rigup said that it was untested and unverified (or something to that extent).  If I need 300MHz for something down the line, I'll go back and redo the hack.  I'm happy for now.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on February 21, 2014, 04:49:15 pm
(and yes i am still reading the rest of this thread ... until i reached page 39 ... the sum of 39 pages of hard work of all the super haxors in this community culminated into a windows keygen ... )

The forum software used here makes it a bit difficult to track conversations & offshoots.  No proper threading support.  There are threads, yes, as topics, but not subthreads and branches within a thread.  Not at all Dave's fault; there is no good software out there that actually handles threading properly, we've all just adjusted our expectations and formed habits to accommodate the available software. 

Actually, Discourse (http://www.discourse.org) might be the ticket here, now that I do some googling and take a look at it.  They have the same complaints about forum software that I have.  ... nice to feel validated.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Ivan7enych on February 21, 2014, 04:50:31 pm
Rigol 2072a has been upgraded to 300MHz without problems.
I want to say thank you to everybody, who has made it possible.  :)

When I return home (I live in Russia, but now I'm in California for 2 weeks), I'll try to compare the bandwidth of this unlocked rigol with my old Tek TDS744A (500MHz 4channels).

By the way, transcend 16GB flash card worked fine with 2072a (for upgrading firmware and for the screenshots).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: madcrow on February 21, 2014, 08:33:20 pm
I read in the thread that when a BW-upgrade key is applied, the model number of the device also changes in the system info screen. E.g. "DS2072A" becomes "DS2202A".

Is the response of the *IDN? command adapted, too?
If I upgrade my device to, say, 200MHz, will the above query return "RIGOL TECHNOLOGIES,DS2202A,DS2D..." ?

Thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ch.onillon on February 21, 2014, 08:42:27 pm
[joke mode] because it's not the official rigol support ?  ;)
or rigol sales ? [/joke mode]

need to wait to receive it ...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on February 21, 2014, 09:49:52 pm
I read in the thread that when a BW-upgrade key is applied, the model number of the device also changes in the system info screen. E.g. "DS2072A" becomes "DS2202A".

Is the response of the *IDN? command adapted, too?
If I upgrade my device to, say, 200MHz, will the above query return "RIGOL TECHNOLOGIES,DS2202A,DS2D..." ?

Thanks

yes.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Giggy on February 22, 2014, 05:18:31 am
Interesting, I've had 482 downloads of my 2072A unlocking guide.

Hopefully it is proving useful to people.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on February 22, 2014, 07:19:39 am
Interesting, I've had 482 downloads of my 2072A unlocking guide.

Hopefully it is proving useful to people.

If it is, then good.  Anything that reduces the # of repetitive questions here helps all of us.  Even those who don't have a DS2000.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: GlassFET on February 22, 2014, 01:09:23 pm
Interesting, I've had 482 downloads of my 2072A unlocking guide.

Hopefully it is proving useful to people.

I wanted to thank you for it! I, for one, needed the little bit of additional hand-holding with the hex editor part that you provided. I have convinced four of my pals to buy DS2072As in past few days. These are engineers/hams/audiophiles with decades of experience with Tek and HP equipment. None of us had ever even touched Rigol equipment before. Are you reading that Rigol? Rejoice!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Dave92F1 on February 22, 2014, 06:37:38 pm
Interesting, I've had 482 downloads of my 2072A unlocking guide.

Hopefully it is proving useful to people.

Hey Giggy - thanks indeed for that!  I've been lurking here for years but just got a 2072A based on this thread (TEquipment.net with the EEVBLOG6 discount - great deal). [Compared to my old DS1102E, the DS2072A is light-years ahead.]

In your guide you say to download Ultra Sigma version 00.01.05.10 but the linked Rigol site only offers 00.01.05.09. 

Maybe Rigol pulled the .10 version to make this hack harder?  Anyway, is there a place I can download the .10 version?

EDIT: Nevermind.  The .10 version is on the CD that came with the scope.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Dave92F1 on February 22, 2014, 09:06:34 pm
I successfully updated my DS2072A to 200 MHz and all options following Giggy's summary. 

Like a few others, I can't get 300 MHz to work - NSEQ (200 MHz) works OK, but NS8H doesn't (anybody know how to fix that?)

For others who are going to do this, here are some tips to go along with Giggy's PDF:

1 - When powering-on the scope for the initial firmware installation, you need to press HELP twice in VERY QUICK succession immediately after pressing the power button. If it doesn't work, it's because you didn't press HELP twice quickly enough.

2 - It takes a while for the firmware to update; be prepared to wait for a while (4 or 5 minutes) - the CH 1 light will flash until it's done.

3 - The way to check if the new firmware was installed is UTILITY > SYSTEM > SYSTEM INFO, but that does not give the full detailed info you need.

To get the detailed system info (from the hacked firmware you just installed), Giggy says to press [Menu 7] [Menu 6] [Menu 7] [UTILITY].  (And then SYSTEM > SYSTEM INFO).

On each side of the screen (left and right) there are a row of buttons under the MENU button.  The first one under the MENU button is "1", the next down is "2", etc., to "7" which is the bottom button.

So [Menu 7] [Menu 6] [Menu 7] [UTILITY] means press the bottom right menu button (Menu 7), then the one above it (Menu 6), then the bottom one again (Menu 7), then UTILITY.  Press them one at a time, but VERY QUICKLY.  If you do it slowly it won't work.  Then press SYSTEM > SYSTEM INFO.

5 - The link Giggy gives (to rigol.com) for the Ultra Sigma software goes to version 00.01.05.09.  On the CD that came with the scope the newer version 00.01.05.10 is there (I used that).  Supposedly the newer version is also on the batronix.com website (I didn't try this).  [Also the Rigol website downloads very, very slowly.]

6 - The Rigol documentation README for Ultra Sigma tells you to first install "NIVISAruntime.msi" before trying to install Ultra Sigma.

I'm not sure this is really needed - I think the runtime is now included in the Ultra Sigma installer.

But I installed using "visa520runtime.exe" (from the National Instruments website); that worked fine.

7 - I found Giggy's explanation of using HxD a little confusing. Giggy talks about three "columns"; left, middle, and right. 

The "left column" is the hex offset into the file (the address); this is on the left side of the screen in blue.  The "middle" column is the central area with 16 8-bit hex values in each row.  The "right" column is the right portion of the screen showing the same data in ASCII.

So, paste in the "massive string" that appeared after the serial number (don't paste in the whole message - just the long hex string from after the serial number) into the hex section (middle), then the serial number in ASCII goes after that (on the right), and finally one byte of zeros in the hex area.

8 - When entering the code into Ultra Sigma (Giggy's last step), enter it without quote marks.  For example:

:SYSTem:OPTion:INSTall R939MBGNR63H279H993PXZT49K4M

(don't use that exact code; it's just an example - use the code you got from rigup)

I hope this is helpful to somebody.




Title: Re: Sniffing the Rigol's internal I2C bus
Post by: corax on February 22, 2014, 09:32:30 pm
This was mentioned earlier in the thread, but you don't need to use the Ultra Sigma software to use these hacks.
If you have an ethernet connection to the scope (and the scope's TCP/IP settings are useable), you can use telnet to send SCPI commands:
(utility->I/O Setting->LAN set  for TCP/IP setup and/or to see what DHCP address was assigned)

telnet <scopeaddress> 5555

Once connected, send the SCPI command:
*IDN?

... and you'll get the scope's ID string (and keys in the case of the hacked firmware).

That said, a scan with NMAP shows that the scope is also listening on other TCP ports:

root@raven:~# nmap -sS 192.168.1.198
...
80/tcp   open  http
111/tcp  open  rpcbind
5555/tcp open 
5566/tcp open
6666/tcp open  irc
MAC Address: 00:19:AF:28:17:08 (Rigol Technologies)


Port 80 and 5555 are expected (www and SCPI).
Looks like LXI uses RPC on port 111.
I wonder how ports 5566 and 6666 are used.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tsmith35 on February 22, 2014, 11:51:43 pm
6666/tcp open  irc

Listening on 6666 isn't a good idea. It's a very popular port for malware and hackers to try and gain access to a machine. Strange that Rigol would choose to use that port...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on February 23, 2014, 01:14:41 am
6666/tcp open  irc

Listening on 6666 isn't a good idea. It's a very popular port for malware and hackers to try and gain access to a machine. Strange that Rigol would choose to use that port...

malware often scans all ports, not just the common ones.  besides, vulnerability depends entirely on what has the port open. if you telnet and get a prompt, that's bad. if you telnet and get disconnected, not so bad.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Giggy on February 23, 2014, 05:49:26 am
Thanks for the feedback Dave92F1,

1-3. I've reworded and added some pictures for clarity
4. ???? Haha
5. The link i've provided shows version 01.01.10? They must have updated the page.
6. I installed the program as is, I did see something about an additional runtime, but I don't believe I had to install anything (Although I did have some NI software already?)
7-8. I've also reworded this and added some more information like you have.

Thanks a lot.

Considering the attention and now feedback my upload has had (582 downloads), I've revised the document.

- All word processed (no more hand written notes)
- More illustrations (improved image contrasts)
- Revised structure of document
- Added uninstall command at the end

DS2072A Unlocking Guide rev 1.0
http://www.mediafire.com/view/lk5fla8ib1w2mc1/D2072A_Unlocking_Guide.pdf (http://www.mediafire.com/view/lk5fla8ib1w2mc1/D2072A_Unlocking_Guide.pdf)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on February 23, 2014, 06:25:50 am
SkyDrive/OneDrive
Dropbox
mega.co.nz
Google Drive
...

There are far better free ways to share files than Mediafire.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Giggy on February 23, 2014, 07:37:15 am
SkyDrive/OneDrive
Dropbox
mega.co.nz
Google Drive
...

There are far better free ways to share files than Mediafire.

....
It was just the first thing that came up.

I open my links, I haven't had pop ups or captcha  etc.
What's wrong with it?
I tried mega originally, the website wouldn't work for half an hour so I gave up.

Also, 3foot, I can't see the file on your google drive account?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on February 23, 2014, 08:13:19 am
it was more for future readers than you.  wasn't judging.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Giggy on February 23, 2014, 10:32:53 am
@Rigby, okay no worries.

@ 3foot, Must be different country by country? Your link shows the name Lego_hulk.png but the image doesn't load.

It seems like Mega is the way to go, I haven't read about people having issues with them.
I'll make an attempt with Mega again if I make any more revisions.

Thanks.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on February 23, 2014, 03:57:48 pm
no worries, i think its a regional IP thing. check out the previous post above. it may work

Yes, that last one:

(testing : giggy's rigol guide https://drive.google.com/file/d/0B8yFRtbwGWr5QVBGS2NoMlo2WVU/edit?usp=sharing)

works fine.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Dave92F1 on February 23, 2014, 06:16:16 pm
I got 300 MHz working on my DS2072A (I was only able to get to 200 MHz before; "NS8H" didn't work).

I did it by installing Zombie28's patched firmware (this allows the DS2xxxxA to use the old DS2xxxx option keys):

https://mega.co.nz/# (https://mega.co.nz/#)!FFk10SCY!UuWPXyqZwmca00pa2clOth1ryh1Z-AAgJg2yibfoUw0

Then, instead of rigup, I used the install key generated by http://riglol.3owl.com/ (http://riglol.3owl.com/) (mirrored, I think, at http://www.gotroot.ca/rigol/riglol/ (http://www.gotroot.ca/rigol/riglol/) - note that you can download those web pages and run them locally if you want), using "DSHH" to install "all options".

That worked!

BTW, that patched firmware doesn't recognize any options that were installed with the standard firmware (the options disappear).  Not to worry - you'll get them back when you install the key generated as above.
Title: Hacking DS2072A-S to 200 or maybe even 300 MHz ?
Post by: samertje on February 23, 2014, 11:30:36 pm
Hey guys,

All of this hacking is so awesome! Special thanks to all who did the great work.

After research on this forum, I bought the DS1052E and upgraded the firmware to make a DS1102E. Till this day, the scope is operating perfectly.

My next purchase will be a Rigol DS2xxxA-S series (with waveform generator). Is it possible to hack these as well?
What about the Rigol spectrum analyzers and function generators?

Cheers from Rotterdam,
Sam
Title: Re: Hacking DS2072A-S to 200 or maybe even 300 MHz ?
Post by: hammy on February 24, 2014, 06:00:56 pm
My next purchase will be a Rigol DS2xxxA-S series (with waveform generator). Is it possible to hack these as well?
What about the Rigol spectrum analyzers and function generators?

 :palm:  :o

Use the search, please!
Title: Re: Hacking DS2072A-S to 200 or maybe even 300 MHz ?
Post by: mrflibble on February 24, 2014, 06:43:40 pm
My next purchase will be a Rigol DS2xxxA-S series (with waveform generator). Is it possible to hack these as well?
What about the Rigol spectrum analyzers and function generators?

 :palm:  :o

Use the search, please!
Free service of the day. Use google, and search for: site:www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus <whatever_you_are_looking_for>.

Happy searching. :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hari on February 24, 2014, 07:45:39 pm
rigol ds2xxxa-s? Look here: http://lmgtfy.com/?q=+site%3Awww.eevblog.com%2Fforum%2Ftestgear%2Fsniffing-the-rigol%27s-internal-i2c-bus+ds2072a-s (http://lmgtfy.com/?q=+site%3Awww.eevblog.com%2Fforum%2Ftestgear%2Fsniffing-the-rigol%27s-internal-i2c-bus+ds2072a-s)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: georges80 on February 24, 2014, 09:22:31 pm
[SOLVED] Ok, I must be doing something stupid or missing a step:

VERY recently purchased a DSA815 with the TG option installed. It currently has trial (since it's new) keys for all the options other than 10Hz RBW.

I run the riglol program (also tried the owl website) and they generate the same key for option AAAD using the serial number (DSA8A....) that is on the back of the DSA (which matches the serial number on the System Info screen).

I try to send the key via my lan connection via SCPI as:

syst:lkey RAJ.....

all 28 characters with no spaces or '-' in the key.

The DSA squawks and says invalid key. Running version 00.01.07 firmware.

I've read a lot of this thread and nothing obvious pops up - my brain must be seized up I guess.

So where/what am I messing up? TIA.
[/SOLVED]

AND my mistake - after searching more and more in this thread... Can't use SCPI to send the keys, have to enter them MANUALLY on the front panel. Just activated the 10Hz RBW, yippee. Now to manually enter the other license keys.

Thanks to ALL that contributed to this excellent thread.

cheers,
george.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: KA3YAN on February 25, 2014, 01:55:14 pm
Interesting, I've had 482 downloads of my 2072A unlocking guide.

Hopefully it is proving useful to people.

I'm not sure I could have done it without your help!  Seriously, I was lost trying to follow this forum.  Your guide was exactly what I needed.  Step-by-step.  Thanks dude!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MatCat on February 25, 2014, 04:41:09 pm
Finally got my DS1074Z-S yesterday, put in the proper code, and all works perfectly!  Thanks!

Lisajous with Amplitude Modulation of Sines (https://www.youtube.com/watch?v=d-LNnrZlHPE#ws)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Giggy on February 26, 2014, 08:45:09 am
Interesting, I've had 482 downloads of my 2072A unlocking guide.

Hopefully it is proving useful to people.

I'm not sure I could have done it without your help!  Seriously, I was lost trying to follow this forum.  Your guide was exactly what I needed.  Step-by-step.  Thanks dude!

Cheers man, good to know.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tom66 on February 26, 2014, 03:18:13 pm
Is the procedure for DS1074Z hacking similar to DS2072A? Do you need the modified firmware?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: samertje on February 26, 2014, 03:45:58 pm
So there's nobody who can confirm the upgrade of a DS2072A-S?
Sorry, I always get lost on forums.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ZeroAviation on February 26, 2014, 03:47:42 pm
To the folks that did the work on the keygen and finding the private keys in memory. I'm curious, what are your backgrounds? How did you get to the point to being able to turn HEX into ASM? I'm sure you used IdaPro, but where do you even being to start understanding the different platforms? I'm sure you are professionals in the field.

In short, how do we become like you? :)

-Matt
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: gmb42 on February 26, 2014, 05:11:03 pm
Not related to what happened with the Rigol firmware, but look at https://microcorruption.com/ for an on-line game about cracking firmware with a debugger.

Warning, can be addictive. |O
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybermaus on February 26, 2014, 05:27:38 pm
Which is such an obvious ploy to find talented new hires that it may not be and just be some sort of marketing for wannabees.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on February 26, 2014, 05:50:04 pm
Is the procedure for DS1074Z hacking similar to DS2072A? Do you need the modified firmware?

No, No.

So there's nobody who can confirm the upgrade of a DS2072A-S?
Sorry, I always get lost on forums.

I upgraded my DS1074Z-S and the sig-gen kept right on working.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tom66 on February 26, 2014, 07:50:57 pm
So, it is through the normal Cybernet keygen?
I'll probably place the order tonight for a DS1074Z to be upgraded to 100MHz.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: G4RKO on February 26, 2014, 08:59:14 pm
Just got my DS2072A today - wading through the 286 page user guide before I attempt an upgrade. I have read this thread in its entirety and can only marvel at the fantastic work done by a team of very talented people. One thing occurs, if for any reason my 2072A needs to go back to the supplier for repair is there anyway that the upgrade can be easily reversed? Thanks for any comments.
 A Newbie!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Giggy on February 26, 2014, 11:09:31 pm
Just got my DS2072A today - wading through the 286 page user guide before I attempt an upgrade. I have read this thread in its entirety and can only marvel at the fantastic work done by a team of very talented people. One thing occurs, if for any reason my 2072A needs to go back to the supplier for repair is there anyway that the upgrade can be easily reversed? Thanks for any comments.
 A Newbie!

Theres an uninstall command for options and then you just install regular firmware.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: SteveK on February 27, 2014, 06:39:03 am
First time poster.  Thought I share my observations with the key generators posted here and give another data point.  I have one of the original DS2102s (not the A version).  Details of my scope are:

Model:  DS2102
S/N: DS2A152270xxxx
Software version:  00.01.01.00.02
Hardware version: 1.0.2.0.0
SPU: 03.01.05
WPU: 00.06.05
CCU: 12.29.00
MCU: 00.05

I used the method described in post #1345 to generate the key to unlock the serial decode function (Option code: DSAC) in my scope.  But instead of using this generated key, I decided to actually buy the option from Rigol and activated the option that way. What I found interesting is, the key I got from Rigol was totally different than the key generated by the online generator.

I guess I could of screwed something up, but the impression I got is that while the key generator may work, it doesn't look like it is the same code that Rigol gives outs.  Has anyone else observed this or am I the only one that actually purchased the option?


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on February 27, 2014, 10:29:12 am
I used the method described in post #1345 to generate the key to unlock the serial decode function (Option code: DSAC) in my scope.  But instead of using this generated key, I decided to actually buy the option from Rigol and activated the option that way. What I found interesting is, the key I got from Rigol was totally different than the key generated by the online generator.

This is obvious consequence of using ECDSA algorithm in keygen. This algorithm uses some random value called 'seed', so there are many possible license codes that contain the same option bits (for a given serial number) and each of them is equally valid.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: G4RKO on February 27, 2014, 06:12:38 pm
Just got my DS2072A today - wading through the 286 page user guide before I attempt an upgrade. I have read this thread in its entirety and can only marvel at the fantastic work done by a team of very talented people. One thing occurs, if for any reason my 2072A needs to go back to the supplier for repair is there anyway that the upgrade can be easily reversed? Thanks for any comments.
 A Newbie!

Theres an uninstall command for options and then you just install regular firmware.

Thanks Giggy. It may be a dumb question for which I apologise - where do I source the regular firmware from?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tom66 on February 27, 2014, 06:17:15 pm
Hmm - DS1074Z is nearly out of stock everywhere in UK and Europe. Is this pulling a Flir -- taking back units to update firmware? Or delaying production for fixed firmware?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybermaus on February 27, 2014, 06:25:20 pm
It has been like that for ever, they just cannot supply them fast enough: I watched Batronix every day (probably twice a day) for 4 weeks till they finally had stock, purchased mine one morning, and later that same morning all 4 models were sold out again....
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mrflibble on February 27, 2014, 10:22:11 pm
Indeed, same problem here. Stock just seems to go *poof*. :(
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Giggy on February 28, 2014, 01:49:12 am
Just got my DS2072A today - wading through the 286 page user guide before I attempt an upgrade. I have read this thread in its entirety and can only marvel at the fantastic work done by a team of very talented people. One thing occurs, if for any reason my 2072A needs to go back to the supplier for repair is there anyway that the upgrade can be easily reversed? Thanks for any comments.
 A Newbie!

Theres an uninstall command for options and then you just install regular firmware.

Thanks Giggy. It may be a dumb question for which I apologise - where do I source the regular firmware from?

To get updated firmware just email Rigol (Providing your S/N, there's a form you submit), they send it directly.

A user also posted a link to the original firmware that he uploaded. I think its between this page and ~180
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: G4RKO on February 28, 2014, 05:33:54 pm
Quote
To get updated firmware just email Rigol (Providing your S/N, there's a form you submit), they send it directly.

A user also posted a link to the original firmware that he uploaded. I think its between this page and ~180

Thanks for that. Now running 200MHz with all options!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigol-Friend on March 06, 2014, 06:09:24 pm
Hi everybody,

I have a DS2072 (without A),  hardware version 2, so  50 Ohm input resistors plus relais are build in. I have pimped this scope (thanks, thanks, thanks and much more thanks to cybernet and all other developers !!!) to DS2302 with all available options.

Now my question: Does everyone knows, is it possible to change the inptut impedance like the "A"-Version between 1 Mohm and 50 Ohm directly at the scope??

Thanks a lot for your help....
Rigol-Friiend
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sigxcpu on March 07, 2014, 10:51:16 pm
1ns TB, 200M BW Limit, and correct DS2302 Model type *yeah* ;-)

Orange noticed that the trigger is off by 3divs (lags behind) if u enable the 2nd channel - same happening, but only in 1ns mode.
maybe that is the reason why there is no official DS2302 version - anyhow i can live with that small limitation as it vanishes above 1ns TB

here is the version that will take care of model type string

http://www.filedropper.com/ds2302rilol (http://www.filedropper.com/ds2302rilol)

the "recalc" of the string is triggered by option un/install - so flush keys, and reapply them and it will become active.

did a selfcal on top of that - everything good.

Does anyone has this file anymore?

 I'm pulling my hair to get the 1ns timebase (DS2072, HW 2.0).

If I do option uninstall (and re-install with DSHH, but not mandatory) the scope stays in 500ps timebase until the next reboot. If I leave it at 500ps and reboot, it stays there until I touch the knob. Then it is stuck at 2ns and that's it (nothing below 2ns).

Thanks.
 

LE: It seems that I didn't do my homework well. So the patched firmware is not required and the 1ns timebase should be enabled by 300M option (included in DSHH). Unfortunately, the model stays at DS2202 (I was expecting DS2302, right?) and the timebase doesn't go below 2ns.

Is there something that I do wrong in the following steps?

- uninstall all options (confirmed on-screen)
- power-off
- power-on (tried with F6 and without it, doesn't matter)
- apply license code generated by using DSHH. Confirmed by the scope and checked in options menu (300M is the only bandwidth option there)
- model is DS2202, minimum timebase is 2ns

I'm using a python script for writing the commands through SCPI. If the scopes confirms commands and applies the license, I assume it doesn't matter that I don't use the scope GUI for that.



Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tsmith35 on March 08, 2014, 05:25:10 am
here is the version that will take care of model type string

http://www.filedropper.com/ds2302rilol (http://www.filedropper.com/ds2302rilol)

the "recalc" of the string is triggered by option un/install - so flush keys, and reapply them and it will become active.

did a selfcal on top of that - everything good.

Does anyone has this file anymore?

This file? http://www.filedropper.com/ds2302rilol (http://www.filedropper.com/ds2302rilol)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sigxcpu on March 08, 2014, 07:42:43 am
Did you re-post it? Yesterday it wasn't available.

Thank you.

LE: It seems that this fixed it.

Steps:


Outcome:

Thank you again.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Sir Shagsalot on March 09, 2014, 02:03:14 pm
Hi,

I got 300 MHz working on my DS2072A (I was only able to get to 200 MHz before; "NS8H" didn't work).

I did it by installing Zombie28's patched firmware (this allows the DS2xxxxA to use the old DS2xxxx option keys):

https://mega.co.nz/# (https://mega.co.nz/#)!FFk10SCY!UuWPXyqZwmca00pa2clOth1ryh1Z-AAgJg2yibfoUw0

Then, instead of rigup, I used the install key generated by http://riglol.3owl.com/ (http://riglol.3owl.com/) (mirrored, I think, at http://www.gotroot.ca/rigol/riglol/ (http://www.gotroot.ca/rigol/riglol/) - note that you can download those web pages and run them locally if you want), using "DSHH" to install "all options".

That worked!

BTW, that patched firmware doesn't recognize any options that were installed with the standard firmware (the options disappear).  Not to worry - you'll get them back when you install the key generated as above.

I just wanted to give a shout out to Dave92F1.

Just got a Rigol 2072A.

Followed the guide posted here by Giggy as to how install the firmware from Dave92F1's post, generated the key code. Entered it in the 'scope, rebooted, voila, I have 2302 now.

It is great 'scope for the money, no beef. starting to wonder if it would be worth buying an entry level 6K... For now this one will help a lot though.

FWIW, my 2072A was shipped from the factory in late Dec 2013.

Great stuff, ThanX to Giggy and Dave92F1!

Greez SSAL

Title: Unlocked bandwidth measurements
Post by: GlassFET on March 09, 2014, 06:34:39 pm
Someone asked a while back in this long thread if anyone had tested the bandwidths of unlocked DS2000A scopes to verify that the 300 MHz goal had indeed been achieved. I don't know if anyone responded with results, but here are the results of several BW tests we conducted.

Five of us have unlocked these scopes, four starting with the DS2702A model and one with a DS2102A model. All five of us chose the full "NS8H" 300-MHz-plus-all-options upgrade. Tests were run using an RF signal generator connected to a short (~1M) 50 ohm cable, with the 50 ohm input impedance selected on the scopes.

The -3dB BW results are:

Unit 1: 354 MHz
Unit 2: 408 MHz
Unit 3: 367 MHz
Unit 4: 420 MHz
Unit 5: 480 MHz (?)

Notes: Units 1, 2, 3 were tested with a Wavetek 2510A synthesized signal generator set to 1.0 Vrms (+13 dBm) at 10MHz. The frequency was increased until the scopes read 0.707 Vrms (+10 dBm). Each channel was separately measured one, at a time, and the averages of the two BW results are presented here. Unit 4 was tested similarly with an HP8656A signal generator, except the generator was set to 0.5 Vrms (+7 dBm) at 50 MHz. The set up for Unit 5 is unknown and it might be considered an "outlier".

We didn't observe that BW varied whether two channels were selected or just one, but we could see some aliasing noise in the waveform when two channels were selected, because the 2 Gsa/s maximum sample rate has to be interleaved between channels in the two channel mode, which is typical for DSOs.

Conclusion: All units tested well exceeded the 300 MHz spec of the DS2302A.

Thanks to all here who made this possible!

Title: Re: Unlocked bandwidth measurements
Post by: marmad on March 09, 2014, 07:05:17 pm
Conclusion: All units tested well exceeded the 300 MHz spec of the DS2302A.

As mentioned already many times in this thread (and elsewhere in the forum), the fact that you get more bandwidth, in and of itself, is not necessarily a good thing.

To accurately measure the signal without sampling alias errors, your DSO must have sufficient sample rate. For a Gaussian-response oscilloscope like the Rigol, 4-6 times the bandwidth is typical. The original 200MHz DS2000 has a dual channel sampling rate of 5 times the bandwidth  - which fit the BW filter curve quite well.

Running a DS2000 at 300MHz with both channels on means a sample rate of only 3.3 times the bandwidth; an inadequate amount for the Gaussian filter - and will likely lead to alias errors in certain circumstances. So, IMO, the 300MHz is reliable when only using a single channel - but not both.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: electronics man on March 09, 2014, 07:13:14 pm
What I don't realy understand is why is the bandwidth only limited in softweare, so is rigol actually selling an upgrade.
Title: Re: Unlocked bandwidth measurements
Post by: GlassFET on March 09, 2014, 07:19:43 pm
Conclusion: All units tested well exceeded the 300 MHz spec of the DS2302A.

...So, IMO, the 300MHz is reliable when only using a single channel - but not both.

That was my intended point about aliasing. I concur that only one channel should be used at close to max BW to avoid aliasing. Nothing shameful here; Tek and Agilent face the same physical realities.
Title: Re: Unlocked bandwidth measurements
Post by: Mark_O on March 10, 2014, 03:25:30 am
That was my intended point about aliasing. I concur that only one channel should be used at close to max BW to avoid aliasing. Nothing shameful here; Tek and Agilent face the same physical realities.

That's true, however what is one supposed to do when you have two channels enabled?  You can't just say (as you did)  'don't use both at close to max BW', because you have no reasonable control over the max BW at that point.  I.e., there may be spurious harmonic content you have no knowledge of. 

As marmad pointed out, "The original 200MHz DS2000 has a dual channel sampling rate of 5 times the bandwidth  - which fit the BW filter curve quite well."  i.e., the sample rate was well-matched to the BW (or vice-versa).  So to avoid aliasing with your modded 300 MHZ (or 400!) scope, you must engage a 100 MHz BW limiting filter... which may not be as desirable as the original 200 MHz would have been.

It's really a choice between having 200 MHz at 1 and 2 channels; or 300 MHz at 1 channel, with 100 MHz at 2.  It's a point worth noting, and remembering.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: GlassFET on March 10, 2014, 11:25:30 am
Mark-O,

We only quickly looked at the aliasing effects, but I don't think it's as dire as all that, nor is the 300 MHz option necessarily completely unusable in two channels near max BW. Most, if not all, of the visible aliasing that we saw occurred with a signal well above the specified 300 MHz point at the frequencies mentioned above. Exactly where aliasing became visible in the two cases of channel selection has not yet been evaluated by us. It's also a question of degree, and the specific application of the scope. I don't have a handle on the anti-aliasing filter that Rigol used although there are hints of the initial roll-off points in the measured BWs I provided, but not the steepness of the filter. When we get a chance we will try to more fully check out the aliasing story. Meanwhile others who have measured these scopes might comment.

Nevertheless, it would have been nice if Rigol had provided a 200 MHz analog filter choice in addition to the 20 and 100 MHz filters. We're hardly in a position to complain much!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on March 10, 2014, 12:15:02 pm
Most, if not all, of the visible aliasing that we saw occurred with a signal well above the specified 300 MHz point at the frequencies mentioned above.

Aside from visible aliasing, it's imperative that sin(x)/x interpolation, to reconstruct the waveform faithfully, not receive frequencies greater than the Nyquist frequency. I'm not sure evaluating this with a simple sine or square wave is adequate.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: GlassFET on March 10, 2014, 12:32:28 pm
These are some of the inherent limitations of DSOs and why many of us keep an analog scope on the bench too. Each type has its advantages and disadvantages. It is always necessary to be mindful of the limitations of any kind of test instrument when making measurements. Spectrum analyzers, distortion analyzers, DMMs, whatever - they can all fool you if you haven't considered their limits.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tiagobaracho on March 11, 2014, 01:26:56 pm
Hi guys...
I requested the firmware from rigol and got the DS2000(DSP)update_00.02.01.00.03 from them...
Just one doubt.... since this is the same version as the hack here to get response to the *IDN? command, makes sense to update? will have anything new ?,what i mean is that i dont know if the the hack was made with this firmware that or if the it was another but you guys renamed to .03 to be able to update to a newer version...

I have the 300mhz all options installed.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Arkku on March 11, 2014, 01:30:25 pm
Hi,

I successfully unlocked all the features on my DS2072A with the instructions in this thread. In case it is helpful to others who may have trouble digging up all the relevant info in this long thread (especially since much of it seems Windows-specific), the process I found easiest on the *nix command line (OS X, Linux, BSD, etc) was:


1) Upgrade to the "license keys dump" firmware

• put the DSO2000Update.GEL (md5sum 8d28a810d45a9e8be3095cd312ec57ec ) on a FAT32 USB drive
• start scope and quickly double-tap HELP (screen will be blank, only SINGLE button lit)
• insert USB drive – CH1 should start blinking while the upgrade is in progress (takes several mins)
• When CH1 stops blinking and all buttons light up, turn off scope and remove USB drive

Note: This firmware is needed to get the private keys out of the scope, otherwise the next step won't work. However, once the keys have been extracted, the firmware can be changed back to an official version.


2) Get the identification string over the LAN

• set up the scope on the LAN (easy if router has DHCP server, just find out the scope's IP from LAN settings)
• connect to TCP port 5555 on the scope (replace "scope.localnet" with the IP) type "IDN?" + return, e.g.:

Code: [Select]
$ nc scope.localnet 5555
*IDN?
RIGOL TECHNOLOGIES,DS2072A,DS2…,020……………………………………………………………………………………………………………………………………………………………………

(everything after *IDN? is the reply from the scope, the …'s are replaced by lots of hexadecimal digits)


3) Generate the license key

• compile "rigup" from sources for your platform (should be a simple matter of running "make")
• in the directory with the "rigup" executable:

This is where most of the existing instructions tell you to use a hex editor, but if you've got Ruby installed here's a little oneliner script to do it straight from the command-line:

Code: [Select]
echo "RIGOL …,DS2072A,DS2…,020…" | ruby -e 'f=gets.strip.split(","); print "#{[f[-1]].pack("H*")}#{f[-2]}\0"' >scope.bin

Replace the everything in the double quotes after echo ("RIGOL …" etc) with the whole (long) line you got from the scope in the previous step. This will create the file "scope.bin" in the current directory.

Then you can generate the keyfile (here "scopekey.txt") with:

Code: [Select]
./rigup scan scope.bin >scopekey.txt

And finally generate the license using the keyfile:

Code: [Select]
./rigup license scopekey.txt NS8H

NS8H is the code for 300MHz with all options, you can also use NSEQ for 200MHz with all options.

This will output a key like:

Code: [Select]
rigup license - Version 0.1

ABCDEF0-1234567-1234567-1234567    (NS8H = 0x1C0C7)


4) Install the key

• connect to the scope's TCP port 5555 and type ":SYST:OPT:INST key" + return, where "key" is the key you got from rigup without the dashes, e.g.:

Code: [Select]
$ nc scope.localnet 5555
:SYSTEM:OPTION:INSTALL ABCDEF0123456712345671234567

A progress bar should appear on the scope's screen. Once it's done, restart the scope and verify that Utility -> Options -> Installed shows all options as "Official version":

(https://farm8.staticflickr.com/7058/13669018274_b117b1bc5d_c.jpg) (https://www.flickr.com/gp/arkku/4r3073)

Printing a new label for the scope is optional.


edit: Some people have been having trouble with the license for NS8H (300MHz with all options) being rejected with the message "License unavailable". If you get this problem, try sending the command "SYSTEM:OPTION:UNINSTALL", reboot the scope, install the official firmware, and try again. Also try entering the license manually through the scope's UI instead of over LAN.

If it still won't work for you, try the code NSEQ instead of NS8H when generating the license; this should give 200MHz with all options, and people seem to have more luck with that.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on March 11, 2014, 01:31:23 pm
Just one doubt....

the ISDN command

You're from India.

The *IDN? command should update with the model number the scope believes itself to be.  The serial number should not change unless there is something about the modded firmware I don't know about.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tiagobaracho on March 11, 2014, 05:21:33 pm
Just one doubt....

the ISDN command

You're from India.

The *IDN? command should update with the model number the scope believes itself to be.  The serial number should not change unless there is something about the modded firmware I don't know about.
Just one doubt....

the ISDN command

You're from India.

The *IDN? command should update with the model number the scope believes itself to be.  The serial number should not change unless there is something about the modded firmware I don't know about.

D letter close to S letter + i am not perfect, human being here = sometimes I do mistake ... should had reviewed better... I am far away from india !

What i meant is that now i have the dump key version to the IDN command... hacked here.... and it shows the same version as the rigol guys sent me ...
Since i already have the serials to use the 300Mhz with all options, should I update the firmware to this version they sent me ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on March 11, 2014, 05:34:26 pm
Sorry, I wasn't criticizing.  If you took offense, I apologise.  Very sorry about that.

"Just one doubt" is something I very, very often heard from a lot of my Indian coworkers at a previous job.  I've never heard anyone else say it, so I assumed it was a cultural thing.

I believe the only difference between the hacked firmware and the official firmware is that the hacked firmware reveals the private key for the device.  If you want, you should be able to upgrade, or "side-grade" to the same version of un-hacked firmware and be ok.

If you try it, let us know how it turns out.  Like I said, everything should be fine.

If I'm wrong, someone will likely jump out very quickly and correct me.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tiagobaracho on March 11, 2014, 09:41:48 pm
Sorry, I wasn't criticizing.  If you took offense, I apologise.  Very sorry about that.

"Just one doubt" is something I very, very often heard from a lot of my Indian coworkers at a previous job.  I've never heard anyone else say it, so I assumed it was a cultural thing.

I believe the only difference between the hacked firmware and the official firmware is that the hacked firmware reveals the private key for the device.  If you want, you should be able to upgrade, or "side-grade" to the same version of un-hacked firmware and be ok.

If you try it, let us know how it turns out.  Like I said, everything should be fine.

If I'm wrong, someone will likely jump out very quickly and correct me.
No offense taken.. if i took offense, i would be offending Indians right ? lol

In portuguese we speak exactly like that..... but  i dont know the way it is said in english... i believe is more like " Just one question"

I read few pages back that there was a bug when at  1ns that was fixed with the latest upgrade.... but the latest seems to be the same as the hacked version that dump the keys.... so i was wondering that..
Title: Options for DP832
Post by: ElektronikLabor on March 12, 2014, 03:35:11 pm
Hello folk,
I'm trying to enable some options on my new DP832; i followed this instruction:
Quote
1 Download firmware at http://www.riglol.3owl.com/firmware/DP832.rar (http://www.riglol.3owl.com/firmware/DP832.rar)
2 Downgrade firmware to 00.01.06
3 Generate Key on riglol.3owl.com
4 Install the keys
5 Upgrade firmware to 00.01.08
I always loose all options after upgrading back to 00.01.08.
Is there any trick to prevent ist?

I searched a lot through this thread but didn't find any solution  :-//

Thanks  :)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on March 12, 2014, 04:25:04 pm
I don't think so.  I believe the current notion is to just stay at .06 and not worry about it.  There aren't any significant bug fixes in .08 or .09 (except that hacked keys are lost) so just don't upgrade.

There's a thread about this. (https://www.eevblog.com/forum/testgear/rigol-dp832-firmware-updates-and-bug-list/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ve7xen on March 14, 2014, 07:28:45 pm
It's been a while since I've monitored this thread and it appears plenty of progress has been made. Excellent work everyone!

Took the opportunity to mirror a bunch more useful files permanently at http://www.gotroot.ca/rigol (http://www.gotroot.ca/rigol) as well as setting up a cron job to pull down the complete thread every day as well. If there's anything else that should be there, send me files or PMs and I will make it so.

How do you pull this thread?, Would it be possible to include the messagenr in the postheader or postbody?, when I'm searching in the file now, it's difficult to find the post on the forum, with an id one could construct the url, or maybe include the a-href info which looks like this:

a href="msg391147/#msg391147"

I realize this response is very delayed as I've been on vacation for all of February and haven't had time to catch up on the thread until now, but if anyone is curious I was just archiving the "printpage" URL. There's a link near the top of the thread. Unfortunately, this link no longer works, so for now the archiving is down. I'm not sure if it's intentionally disabled or if it's simply the length of this thread breaking it due to a timeout or memory limit or some such (returns a 500 error).

If the forum administrators are able to fix it, the archive script will resume pulling it daily.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on March 14, 2014, 08:11:27 pm
ah, then it works, on other threads, tested that now, but on this thread, not working.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mrflibble on March 14, 2014, 08:37:24 pm
All the long threads suffer from the same problem. The print view for the Flir E4 thread is also broken. Probably a LIMIT=<nice_number/> in the query would already fix things. :-//

I suspect it is either really really broken in a silly way, or just the usual query takes too long + timeout. And then cache that zero size result. :P But not sure, not familiar with this particular forum software.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on March 14, 2014, 08:55:21 pm
I think you're onto something there.  There is almost always an execution timeout.  It could be a process memory restriction as well.  Or both.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Sparky on March 15, 2014, 12:15:46 am
New DS2000(A) series firmware: v00.03.00.00.00 (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg406174/#msg406174)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tom66 on March 15, 2014, 09:11:54 pm
I have a DS1074Z I'm trying to unlock options on. I can unlock them, but have the broken 500uV range with "DSFR". Is there a code for all options minus 500uV?  I have searched the thread quickly with no obvious hints. Do I have to install separate keys?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on March 15, 2014, 10:53:05 pm
use separate keys.  if the scope UI bothers you, enter them using SCPI.  If you don't know how to do that, it might be quicker just to fight the knob than to figure it out, I don't know.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: seronday on March 15, 2014, 11:29:50 pm
tom66,
   DSER is the code for everything except the 500uV/div.
Uninstall the DSFR key by using the SCPI command " :SYSTem:OPTion:UNINSTall " .
Then generate and install a new key based on DSER.

Refer to this post.  https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/1951/ (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/1951/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tom66 on March 16, 2014, 12:26:48 am
Thanks, I did not see that. It is working now.
Great thanks to all contributors to this most excellent reverse engineering and hacking.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ad0hg on March 18, 2014, 01:00:36 am
My DS1104Z-S arrived on Saturday.  I've been combing the thread but no good working demo bypass keys. (that work it appears they have changed the keys)  Other than that the scope is great works like a charm no issues rock solid.  Worth every hard earned cent. 
Cheers all!
Steve
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gallymimus on March 18, 2014, 05:17:54 am
My DS1104Z-S arrived on Saturday.  I've been combing the thread but no good working demo bypass keys. (that work it appears they have changed the keys)  Other than that the scope is great works like a charm no issues rock solid.  Worth every hard earned cent. 
Cheers all!
Steve

What firmware version is on your scope?   I've had no trouble with several DS1074-S and updated them to the latest firmware (as of a few weeks ago that is)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: eV1Te on March 18, 2014, 07:48:34 pm
My DS1104Z-S arrived on Saturday.  I've been combing the thread but no good working demo bypass keys. (that work it appears they have changed the keys)  Other than that the scope is great works like a charm no issues rock solid.  Worth every hard earned cent. 
Cheers all!
Steve

What firmware version is on your scope?   I've had no trouble with several DS1074-S and updated them to the latest firmware (as of a few weeks ago that is)

Which is the firmware version you have? The one I have at the moment is 00.02.01.SP1

I have not read anything new about the 500 uV option, have the offset calibration issue been solved by now?

And finally is there any tool out there that can read the WFM files from the DS1000Z scopes which allows conversion to CSV? Rigols own software suites can not do it  |O
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: staze on March 19, 2014, 09:30:27 pm
Now my question: Does everyone knows, is it possible to change the inptut impedance like the "A"-Version between 1 Mohm and 50 Ohm directly at the scope??

I have not seen anyway to do this. Just read through the rest of the thread, and not seeing anyone having figured out how to do this. =/
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: greenwk2 on March 19, 2014, 11:26:39 pm
I have a DS2102A-S with serial number DS2E15xxxxxxx.

The code NSEH gives me all options no bandwidth change
The codes NSEQ, NS8H are invalid
The code NSFH gives me all options no bandwidth change
The code NSFQ gives me 200 MHz with all options
The code NS8Q gives me 200 and 300 MHz with all options

Given this information does anyone have an idea what might be the right code to get 300MHz without also having 200 MHz? Does it matter?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NYG on March 20, 2014, 01:21:19 am
I have a DS2102A-S with serial number DS2E15xxxxxxx.

The code NSEH gives me all options no bandwidth change
The codes NSEQ, NS8H are invalid
The code NSFH gives me all options no bandwidth change
The code NSFQ gives me 200 MHz with all options
The code NS8Q gives me 200 and 300 MHz with all options

Given this information does anyone have an idea what might be the right code to get 300MHz without also having 200 MHz? Does it matter?

You would only want to install a single key, that would be the key for 300Mhz. It sounds like you also installed the 200Mhz key. If that's the case you need to uninstall the 200Mhz key.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: greenwk2 on March 20, 2014, 01:23:29 am
I only installed a single key and got both. I can get 200 by itself or the combination of 200 and 300 from a single key. So far I haven't found a key that gives me 300 by itself. I uninstalled and reinstalled a couple of times to be sure.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Arkku on March 20, 2014, 01:32:45 am
I only installed a single key and got both. I can get 200 by itself or the combination of 200 and 300 from a single key. So far I haven't found a key that gives me 300 by itself. I uninstalled and reinstalled a couple of times to be sure.

I get 300MHz + all options with NS8H on DS2072A, don't know why it shows as invalid for you.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NYG on March 20, 2014, 01:37:25 am
I only installed a single key and got both. I can get 200 by itself or the combination of 200 and 300 from a single key. So far I haven't found a key that gives me 300 by itself. I uninstalled and reinstalled a couple of times to be sure.

I get 300MHz + all options with NS8H on DS2072A, don't know why it shows as invalid for you.

That's the key I used too for a ds2072a.

I don't know where development of the rigup tool is right now, but I had to modify the Linux source code to get the NS8H key to show.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: kunc on March 20, 2014, 03:56:17 am

Recompiled NS8H, key or invalid

Change to Onedrive
http://1drv.ms/1epXGdS (http://1drv.ms/1epXGdS)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on March 20, 2014, 01:16:34 pm
Recompiled NS8H, key or invalid
...38hot.net...

Who thinks of these domain names?  This REEKS of spammer/linkblog, to me.

Google Drive, OneDrive, MEGA, ... there's lots of places to host files without making it look like you're trying to infect me.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Pat on March 20, 2014, 07:40:33 pm
Hi guys,

Just to let know that I have updated the DS2072A to 300Mhz full options.
Works just great, thanks to all who participated in this issue, great job.

Pat
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Suffer1981de on March 20, 2014, 08:29:29 pm
Hi Guys,

wanted to say thank you for all the good work.

My DS1074Z is now an 1104Z with all options.

Greetings from Germany

Edith says: firmware is 00.02.03.SP5 with DSER
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: caspencer on March 24, 2014, 03:37:02 pm
Does anyone know if it's possible to update the firmware on the DS2072A (to an official version) after going through the unlocking procedure and still keep the "unlocked" options?

In other words, once you've identified your private key, do you still need to keep the modified "private key dump" firmware on there?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on March 24, 2014, 05:02:04 pm
In other words, once you've identified your private key, do you still need to keep the modified "private key dump" firmware on there?

No.  As already mentioned in this thread more than once.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gallymimus on March 24, 2014, 05:05:48 pm
We really need another thread entitled "I didn't ready every page of the I2C thread and would rather just ask".

Then this one can stay reserved for tech discussion and moving the ball forward and the other one can contain Q/A and spoon feeding.... AND there's nothing wrong with that!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jdoshier on March 27, 2014, 02:14:03 am
Hi Guys,
wanted to say thank you for all the good work.
My DS1074Z is now an 1104Z with all options.
Greetings from Germany
Edith says: firmware is 00.02.03.SP5 with DSER

Please [anyone] post this firmware version for the DS1000Z.  Rigol North America seems to be having major problems identifying which is the latest version.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: LIV2 on March 27, 2014, 08:50:22 am
I thought that was the case, I asked them for the latest fw for my 1074Z and they sent me 00.02.01.SP1 which I'm already running

With this firmware version, the DSER option and the one for the recording functionality don't work, but everything else does.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jdoshier on March 27, 2014, 01:01:27 pm
I thought that was the case, I asked them for the latest fw for my 1074Z and they sent me 00.02.01.SP1 which I'm already running

With this firmware version, the DSER option and the one for the recording functionality don't work, but everything else does.

I have 00.02.01.SP1, too.  Am working with a DS1074Z-S and trying to get the arbitrary generator to work with Rigol's Ultra Station PC software.  It appears Ultra Station is sending the correct data but the DS1074Z-S doesn't store the waveform data.

The DS2000A-S arb function seems to work fine with Ultra Station so I suspect a firmware issue with the DS1000Z-S series.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on March 27, 2014, 04:01:02 pm
I can't even get Ultra-Station to SEE my DS1104Z-S, despite Ultra-Sigma seeing it just fine.

There's a whole lot of crap software coming out of Rigol.  Hackability or not, I won't be buying Rigol in the future, probably.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gallymimus on March 27, 2014, 04:15:36 pm
I can't even get Ultra-Station to SEE my DS1104Z-S, despite Ultra-Sigma seeing it just fine.

There's a whole lot of crap software coming out of Rigol.  Hackability or not, I won't be buying Rigol in the future, probably.

Rigol's PC software is pretty bad in most cases.  Rigol works great with custom VISA software like labview.  We've switched most of our test equipment from Tek TDS3000 series to the DS1074.  That's a 5x savings on the scope.  Rigols hardware is solid, firmware is a little buggy but the PC software is bad.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on March 27, 2014, 05:33:06 pm
Rigols hardware is solid, firmware is a little buggy but the PC software is bad.

Agreed on all points.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jdoshier on March 27, 2014, 06:02:18 pm
I can't even get Ultra-Station to SEE my DS1104Z-S, despite Ultra-Sigma seeing it just fine.
There's a whole lot of crap software coming out of Rigol.  Hackability or not, I won't be buying Rigol in the future, probably.

Rigol's software (and their support in general) is not very good.  Pretty good hardware, though. 

To get Ultra Station to work you need to edit "Ultra Station.ini" located in \Rigol\Ultra Sigma\Instrument Tools\ folder.  Add or edit so you have DS1104Z,DS1074Z listed i.e. without the -S.  Once you do this, you should be able to right-click on the instrument in Ultra Sigma and choose Ultra Station.  Ultra Station must be run from within Ultra Sigma.

The DS1000Z and DS2000 series do not distinguish the -S and non-S models.  As mentioned above, The DS2000 series seems to work OK, but the DS1000Z doesn't process and output the arb data.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on March 27, 2014, 06:02:57 pm
...appears Ultra Station is sending the correct data...

If you could perhaps do a packet capture on the series of commands that gets sent to the scope, I'd sure appreciate it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jdoshier on March 27, 2014, 07:30:34 pm
From NI I/O Trace.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: BeattieBoy on March 27, 2014, 09:22:51 pm
Has anybody hacked a DS2072A with firmware 00.02.01? I've tried using the windows program to get the license keys, but it keeps telling me "License unavailable". I just got it today and have already used up a sizeable portion of my trial licenses playing with it, so I am eager to see them all unlocked.

Scope Specs:
Model: DS2072A
Serial: DS2D1546xxxxx
Software version: 00.02.01
Hardware version: 2.0

Looking at it again though, it seems I have to get my unique private key? I'm slightly lost and this forum thread is way too large to dig through the entirety of...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gallymimus on March 27, 2014, 09:26:57 pm
Has anybody hacked a DS2072A with firmware 00.02.01? I've tried using the windows program to get the license keys, but it keeps telling me "License unavailable". I just got it today and have already used up a sizeable portion of my trial licenses playing with it, so I am eager to see them all unlocked.

Scope Specs:
Model: DS2072A
Serial: DS2D1546xxxxx
Software version: 00.02.01
Hardware version: 2.0

Looking at it again though, it seems I have to get my unique private key? I'm slightly lost and this forum thread is way too large to dig through the entirety of...

YOU CAN DO IT.  Don't get discouraged.  Think of all the money you will save by reading reading reading!  That's how the rest of us got there you can do it too!  Good luck!  You are on the right track.  The A version has some special requirements and you are right you need to get a private key out of it.  Just a little more reading and you will have it!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on March 27, 2014, 09:28:08 pm
From NI I/O Trace.

Ah, it's that #7 that I'm keen to know.  Fully expanded.  Can you export that line only?

Thanks!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mrflibble on March 27, 2014, 09:44:45 pm
From NI I/O Trace.

Ah, it's that #7 that I'm keen to know.  Fully expanded.  Can you export that line only?

*grin*

Now why doesn't that surprise me. ;) Hell, you can probably guess the correct syntax now. Check older PM's, substitute DAC16 where we had DAC (because that's in the DS2000A manual) and you're probably good to go.

As in:
Code: [Select]
TRACE:DATA:DAC16 VOLATILE etcblahblah

<3 Rigol for changing it up for every single instrument. :P The guy responsible for the SCPI commands is probably licking an LSD laced sugar cube before he gets to work on a new instrument.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: thn788 on March 27, 2014, 10:05:03 pm
Hi

After reading in Suffer1981de's post about the DS1000Z firmware 00.02.03.SP5, I e-mailed my scope dealer and immediately received the new firmware. Although "new" is probably relative: seems to have been released on Jan. 26th, already. Haven't yet looked for changes or bug-fixes but noticed that the measurement menu on the left side has gained the 8 new measurements that are documented in the User Guide from Jan 2014, which is online on Rigol's website for quite some time, already.

Here is a link to the firmware:  http://www.filedropper.com/ds1000zupdate-v000203sp5 (http://www.filedropper.com/ds1000zupdate-v000203sp5)

Have fun. :-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Sparky on March 27, 2014, 10:49:46 pm
Perhaps someone with a DS1000Z can create a new thread dedicated to DS1000Z-(A), for tracking firmware, bugs, features, etc.

Suggestion: Use the similar style as marmad created for DS2000 (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/), which I attempted to follow for DP832 (https://www.eevblog.com/forum/testgear/rigol-dp832-firmware-updates-and-bug-list/).  It really helps to keep all matters related to one product (series) of a similar topic in its own thread.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on March 27, 2014, 11:06:04 pm
Code: [Select]
TRACE:DATA:DAC16 VOLATILE etc. blah blah<3 Rigol for changing it up for every single instrument. :P The guy responsible for the SCPI commands is probably licking an LSD laced sugar cube before he gets to work on a new instrument.

Yeah I'll have to give it a shot tonight.

Full string of the command would be nice, if it can be obtained.  Suppose I could edit the .ini file mentioned previously and do it myself, though.  I don't need to be lazy.  I do need to wait for my family to get off my PC though...  Need more computers.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jdoshier on March 28, 2014, 01:18:51 am
Thanks, thn788 !!  That half way fixed the arb.  Ultra Station will now transfer to source1 but not source2.  v00.02.03.SP5 is probably an interim bug fix since Rigol NA hasn't been given notice of it.  At least I can transfer to source1, save a copy on the scope, and then load manually in source2.

Rigby, see attached.  Grab a copy of the DG1000Z programming reference.  It looks like Rigol did a partial implementation of it for the DS1000Z-S and DS2000A-S arb's.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Sparky on March 28, 2014, 01:49:13 am
Thanks, thn788 !!  That half way fixed the arb.  Ultra Station will now transfer to source1 but not source2.  v00.02.03.SP5 is probably an interim bug fix since Rigol NA hasn't been given notice of it.  At least I can transfer to source1, save a copy on the scope, and then load manually in source2.

Rigby, see attached.  Grab a copy of the DG1000Z programming reference.  It looks like Rigol did a partial implementation of it for the DS1000Z-S and DS2000A-S arb's.

This is important stuff, but can you please move this discussion to a new thread as I've suggested above.  Not only is it completely off-topic here (this thread is already difficult to locate on-topic information, and many people cannot be bothered to read it and ask repeated questions), but it will surely serve your investigative work and further discussion better if it has its dedicated "space".

Cheers!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MikeGyver on March 28, 2014, 05:47:01 am
I bought a ds2072A because of this thread, and just received it today.
I sat down to do the 300mhz upgrade process as outlined in the PDF file and was unable to complete the very first step.   :palm: ugh... dammit

The modified firmware file 'DS2000Update.GEL'  @ the link  https://mega.co.nz/#!MdcEWTgL!0EEmSr-Q6TxaFSsyEmjhRrgqDvFCoXg9K49BalL5Uxc
is no longer available.....

can someone with this file send it to me or upload it somewhere more permanent?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on March 28, 2014, 05:55:01 am
I bought a ds2072 because of this thread, and just received it today.
I sat down to do the 300mhz upgrade process as outlined in the PDF file and was unable to complete the very first step.   :palm: ugh... dammit

The modified firmware file 'DS2000Update.GEL'  @ the link  https://mega.co.nz/# (https://mega.co.nz/#)!MdcEWTgL!0EEmSr-Q6TxaFSsyEmjhRrgqDvFCoXg9K49BalL5Uxc
is no longer available.....

can someone with this file send it to me or upload it somewhere more permanent?

check in the mirror here http://www.gotroot.ca/rigol/ (http://www.gotroot.ca/rigol/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MikeGyver on March 28, 2014, 07:01:22 am
check in the mirror here http://www.gotroot.ca/rigol/ (http://www.gotroot.ca/rigol/)

That was some kinda witchcraft...
It is on that link listed as "DS2000(DSP)update_00.02.01.00.03 (license keys dump).zip"

I just successfully updated to 300mhz with all options by following the PDF instruction file!
Thanks guys! :scared:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MikeGyver on March 28, 2014, 07:19:58 am
My original DS2072A firmware versions were:
 Software Version: 00.02.00
 Hardware Version: 2.0

And now now after the 300mhz update my firmware is:
 Software Version: 00.02.01.00.03
 Hardware Version: 1.0.2.0.2


Is it safe to install the latest firmware updates with this hack?
If so does anyone have it? Or do I have to get it through Rigol's website?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: IvoS on March 28, 2014, 07:44:30 pm
I am trying to use this hack but I stall at command promp. I am trying to run the rigup scan key.bin but I get a "rigup is not recognized as an internal or external command, operable program or batch file" message.
All step I have done so far I feel like I did correctly.
Can someone help me with this, thanks.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: IvoS on March 28, 2014, 08:05:08 pm
OK, I made little progress but still have an error message:
Loading memory dump 'key.bin' failed.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: IvoS on March 29, 2014, 01:12:21 am
ALL set. CMD must be launched as system32, otherwise it doesn't work.Lesson learned.  |O
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MikeGyver on March 29, 2014, 06:36:50 am
So it looks like today my firmwares have magically reverted back to the original version 2 on their own. Everything is still unlocked at it still says 300mhz.  :-//
Anyone else have this happen?

*EDIT:
I found out why... When i go into the full firmware version menu using the f7,f6,f7,utility key sequence it lists different firmware versions. Kinda weird...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: IvoS on March 29, 2014, 10:31:40 am
Just checked the hacked scope bandwidth with avalanche pulse generator and I read rising edge as low as 740ps!
This makes the bandwidth around 470MHz. Fantastic. Many thanks to those who made this hack to happen.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: anson80 on March 29, 2014, 06:01:33 pm
Has anybody hacked a DS2072A with firmware 00.02.01? I've tried using the windows program to get the license keys, but it keeps telling me "License unavailable". I just got it today and have already used up a sizeable portion of my trial licenses playing with it, so I am eager to see them all unlocked.

Scope Specs:
Model: DS2072A
Serial: DS2D1546xxxxx
Software version: 00.02.01
Hardware version: 2.0

Looking at it again though, it seems I have to get my unique private key? I'm slightly lost and this forum thread is way too large to dig through the entirety of...
300M KEY License unavailable? Give it a try 200M All KEY
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on March 29, 2014, 07:29:01 pm
Just checked the hacked scope bandwidth with avalanche pulse generator and I read rising edge as low as 740ps!
This makes the bandwidth around 470MHz. Fantastic.

Yes, the BW of this scope is quite wide.  However, as a result of that, one must exercise caution... unless you only use one channel at a time, and sample at the full 2 GSa/s rate.

Ignoring that could lead to wasting time chasing a ghost signal that doesn't exist, but is simply an artifact produced by aliasing.  Also, these aliasing components can distort the waveshape of lower-frequency signals.  If the slope of the skirts on the Rigol filters were steep enough, you could get away with up to 400 MHz inputs, with 2-channels running at 1 GSa/s.  Unfortunately, they're not... and you can't.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: CHaTRail on March 30, 2014, 10:34:42 pm
Hi,

I have tried to download Zombie28's modified FW (with the *IDN? key view mod) but the link to the Mega site in post #2791 just reports the URL as out of date.

Is there an alternate link? Or if Zombie28 reads this can you send me a copy of the GEL file please?

Many Thanks!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mrflibble on March 30, 2014, 11:40:06 pm
Is there an alternate link?
See previous page:
check in the mirror here http://www.gotroot.ca/rigol/ (http://www.gotroot.ca/rigol/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: CHaTRail on March 31, 2014, 08:17:54 am
Ah, sorry didn't spot that.

Perfect - thank you Mrflibble.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on March 31, 2014, 02:25:10 pm
I realize it's a lot to ask, but carefully reading the entire thread will indeed benefit you.

Of course, the people I'm talking to will never read this comment.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gallymimus on March 31, 2014, 02:27:02 pm
I realize it's a lot to ask, but carefully reading the entire thread will indeed benefit you.

Of course, the people I'm talking to will never read this comment.

It's really not that much to ask.  Let's say they spend 10 hours reading the thread to save $2k.  That's a pretty good hourly rate for reading and learning.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Dave Turner on March 31, 2014, 11:10:56 pm
I've read this whole thread several times. (10 hours is far too short an estimate for one read through)

Truth is that it is so long and contains so many comments, thanks, adulation, side issues (such as this post) and repetitions that is almost impossible to make sense of.

I'm not sure what the best way forward is to clarify the current position and allow for future developments. Are sub threads possible? For example - new info, thanks, details of hack etc under the various headings.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jdoshier on April 01, 2014, 12:29:01 am
Truth is that it is so long and contains so many comments, thanks, adulation, side issues (such as this post) and repetitions that is almost impossible to make sense of.

It should be renamed "The Rigol Megathread".
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on April 01, 2014, 12:36:25 am
I'm not sure what the best way forward is to clarify the current position and allow for future developments. Are sub threads possible? For example - new info, thanks, details of hack etc under the various headings.

this thread needs a wiki page that we can refer people to.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on April 01, 2014, 04:02:46 am
I've still got to find time to get a working serial reset procedure, so I can post it and have it get lost in this thread....
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gallymimus on April 01, 2014, 04:57:38 am
I've still got to find time to get a working serial reset procedure, so I can post it and have it get lost in this thread....

Post it in a new thread!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on April 01, 2014, 12:21:20 pm
yeah, this thread is a hell of a mess and needs a curator.  this information needs to go into a wiki somewhere and be maintained, and then that maintainer needs to let this thread know so that we can update the wiki page and/or point question askers to the page for the FAQ and distilled information.

This is another example of why this style of forum software is just so absolutely terrible at information dissemination.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on April 01, 2014, 08:58:35 pm
didnt someone did some kind of blog page? with a guide?
http://rigol.avotronics.co.uk (http://rigol.avotronics.co.uk)

But unfortunately it looks like Avotronics stopped halfway through creating the site. So most upgrade info is still missing.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: madcrow on April 02, 2014, 06:33:34 pm
Hello New Owners of DS2000A DSOs,

If you are searching for an easy way to upgrade your units, take a look at this topic:
https://www.eevblog.com/forum/testgear/ds2000a-upgrade-utility/ (https://www.eevblog.com/forum/testgear/ds2000a-upgrade-utility/)
Enjoy :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Fagear on April 03, 2014, 03:28:55 pm
I have a question. For DS2000A the "new" procesure with uploading modified FW, getting some keys out of it, generating new with NSER/NSEQ/... codes is well known. But for DS2000 there were possibility to turn on "trial" keys (DSAZ -> VSAZ and so on).
Are there any codes for DS2000A (with FW 00.02...) that can add "trial" and not "official" options?

I've tried to add "trial" keys buy downgrading my DS2072A to old FW (00.01...) and applying "old" VSAH/VSAZ - that worked. But after returning to FW 00.02... trial options dissapeared.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Fagear on April 05, 2014, 04:27:09 pm
yes i remember there is a another set of commands that refreshes trial instead of activated "official" ... but im sorry to say ... i cant remember which post it was  |O
If you are talking about "LLLLLLL LLLLLLL-RLGLLDS-VSAZLLL-LLLLLLL" and others - they don't work with FW 00.02...  :-//
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: LIV2 on April 06, 2014, 04:01:06 am
I am unable to activate the recorder feature or use the DSER code on my 1074Z, using these codes i get "Invalid License key"

However I was able to add everything else, Triggers, Decoders, 24M Depth and 100Mhz

I do notice that for the codes that work, the first two sections of the license code are the same, but not for the ones that don't. is that normal?

I'm running Firmware version 00.02.03.SP5 and the riglol key generator
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MTD on April 06, 2014, 04:54:49 am
Hello,

Another happy DS2072A-S owner, unlocked All Options + 300MHz. Not being religious per se, but it must be said, God bless whoever made the pdf Unlocking Guide (hack went smoothly). Also God bless Rigol, they certainly changed the game in favour of the customers, especially those with not a high financial capabilities.

Owner of DS1052E (not being hacked, yet) for few years already, didn't have the best experience with it as it broke down. But it must be said that Rigol did step up. On DS1052E issue, first communication was with Rigol Europe, from there being forwarded to Rigol North America, and from there to Rigol China. The Rigol China was very responsive, DS1052E was send to China where it was fixed and send back.

Considering not having the best experience with DS1052E, compared with scopes used from other vendors (Tektronix and Agilent), I was looking (and saving) into those options (Agilent most likely) for the new scope. During that though, the option for hacking DS2000A was identified, and it was just hard to resist. Now DS2072A-S, upps!!! sorry, DS2302A-S is on the bench, :).

Further, eventual acquiring of Spectrum Analyzer was considered, or more precisely put, wished for. But after the hack of DS2072A-S was done, order for DSA815-TG was put in place. Because of DS2000A, eventual Rigol offering for the spectrum analyzer was checked, and DSA815-TG was discovered. Woow, it was not quite easy to believe what DSA815-TG is offering for the price tag on it. Actually, more precisely, the price tag on DSA815-TG was not quite easy to believe. Looking forward to add it on the bench.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Arkku on April 06, 2014, 03:03:00 pm
I figured my unlocked scope needed a new nameplate to reflect the features…

(https://farm8.staticflickr.com/7058/13669018274_b117b1bc5d_c.jpg) (https://www.flickr.com/gp/arkku/4r3073)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hooverphonique on April 07, 2014, 10:09:05 pm
Hi,

I successfully unlocked all the features on my DS2072A with the instructions in this thread. In case it is helpful to others who may have trouble digging up all the relevant info in this long thread (especially since much of it seems Windows-specific), the process I found easiest on the *nix command line (OS X, Linux, BSD, etc) was:

I tried this (excellent looking) guide, but my scope ends up saying "license is unavailable"..

the scope is a DS2072A and the original fw was 02.01.00.03 and after flashing DS2000(DSP)update_00.02.01.00.03 (license keys dump).zip from gotroot.ca, it spits out a long sequence of bytes after the serial number as expected..

I then used rigup-0.1.zip from the same site on linux to generate the NS8H key using a binary file generated by the ruby script, and I then try to install it using :SYST:OPT:INST EU4PV96RHF3XTUG73KVCCM5FTP8M

any idea what is happening/what I'm doing wrong?

cheers,
hoover
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MTD on April 07, 2014, 11:18:24 pm

any idea what is happening/what I'm doing wrong?

cheers,
hoover

Did you read the DS2072A Unlocking Guide.pdf on that same site: http://www.gotroot.ca/rigol/ (http://www.gotroot.ca/rigol/)

MTD
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Arkku on April 07, 2014, 11:36:39 pm
I then used rigup-0.1.zip from the same site on linux to generate the NS8H key using a binary file generated by the ruby script, and I then try to install it using :SYST:OPT:INST EU4PV96RHF3XTUG73KVCCM5FTP8M

any idea what is happening/what I'm doing wrong?

The guide I wrote on page 208 of this thread is pretty much a direct copypaste of what I did, the only difference being that I've obscured my serial numbers. Check the screen of the scope after you enter the :syst:opt:inst and look for a progress bar. If you don't get one, maybe try and restart the scope… Of course you could just enter the license manually on the scope screen if the :system:option:install doesn't work.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: rowifi on April 08, 2014, 09:36:21 am
DS2000A Firmware update 00.03.00 is available.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hooverphonique on April 08, 2014, 12:02:10 pm
Did you read the DS2072A Unlocking Guide.pdf on that same site: http://www.gotroot.ca/rigol/ (http://www.gotroot.ca/rigol/)
I did.. I just used info from Arkku's guide since it omits installing viva? drivers (I am on linux at the moment) and fiddling with a text editor.

The guide I wrote on page 208 of this thread is pretty much a direct copypaste of what I did, the only difference being that I've obscured my serial numbers. Check the screen of the scope after you enter the :syst:opt:inst and look for a progress bar. If you don't get one, maybe try and restart the scope… Of course you could just enter the license manually on the scope screen if the :system:option:install doesn't work.

The scope says 'license is unavailable!' (no progress bar) when using the onscreen editor as well.. restarting doesn't change anything.. I suspect something is wrong with the generated key.. Why, I don't know... I will see if I can find a windows box and try the precompiled version of rigup  (does anyone know if the 02 version generates the same keys as 01?), because when I compiled it, I got some warnings about uninitialized variables.. otherwise something probably goes wrong when applying the ruby script..
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hooverphonique on April 08, 2014, 01:30:59 pm
I think I've come across some sort of tamper-counter, because now the scope has stopped responding to any license I throw at it, both over LAN and in the user interface (no 'license is unavailable' message anymore, no reaction whatsoever).. power off, etc, doesn't help..

another discovery is that the windows exe from the gotroot.ca rigup02.rar archive does *not* produce the same licenses as the home-built one from rigup-0.1.zip (built just by issuing 'make'), i.e. the two versions produce different output when doing e.g. 'rigup license scopekeys.txt NS8H'.
They do produce the same licenses when invoked using 'rigup ds2072a scope.bin', however..
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gallymimus on April 09, 2014, 04:25:28 am
I think I've come across some sort of tamper-counter, because now the scope has stopped responding to any license I throw at it, both over LAN and in the user interface (no 'license is unavailable' message anymore, no reaction whatsoever).. power off, etc, doesn't help..

another discovery is that the windows exe from the gotroot.ca rigup02.rar archive does *not* produce the same licenses as the home-built one from rigup-0.1.zip (built just by issuing 'make'), i.e. the two versions produce different output when doing e.g. 'rigup license scopekeys.txt NS8H'.
They do produce the same licenses when invoked using 'rigup ds2072a scope.bin', however..

There are multiple solutions to a valid license so it isn't necessarily a big deal that you get two different outputs.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on April 09, 2014, 05:18:55 am
I think I've come across some sort of tamper-counter, ...

Nice way to spread FUD!   :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MTD on April 09, 2014, 05:25:47 am
I think I've come across some sort of tamper-counter, because now the scope has stopped responding to any license I throw at it, both over LAN and in the user interface (no 'license is unavailable' message anymore, no reaction whatsoever).. power off, etc, doesn't help..

Hmm, if you haven't tried already, I'm wondering.
How about uninstalling all the options?
:SYSTem:OPTion:UNINSTall

MTD
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Arkku on April 09, 2014, 07:14:06 am
How about uninstalling all the options?
:SYSTem:OPTion:UNINSTall

In addition to this it might be a good idea to reinstall the firmware (it can even be the official firmware since the keys were already dumped).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hooverphonique on April 09, 2014, 09:40:34 am
Hmm, if you haven't tried already, I'm wondering.
How about uninstalling all the options?
:SYSTem:OPTion:UNINSTall

you mean uninstalling the trial licenses that came with it? because that's all that's installed.. I never succeeded in installing any licenses myself.. It kept saying "license is unavailable" until it stopped reacting at all...

I also tried reflashing it with official firmware, but it still doesn't respond to any license key entry, meaning I can enter the key, but when pushing apply, nothing happens at all, and it's the same using :SYST:OPT:INST over SCPI..

thanks for any suggestions, guys...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hooverphonique on April 09, 2014, 11:46:39 am
so I tried ':SYST:OPT:UNINST', but there was no reaction on the screen (is there supposed to be?) and after reboot, all the trial options is still there and I still can't get a reaction by doing e.g. ':SYST:OPT:INST SY5ZYQFV4KG7DDZXC27D6Q5RU25M' ... It responds to the '*IDN?' command, so the connection should be fine..

is there some sort of master reset one may apply by some magic key combination or something?

this is really puzzling...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on April 09, 2014, 11:52:52 am
I newer got an answer when i did the syst:opt:inst xxx, but when I checked on the scope, everything was ok.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hooverphonique on April 09, 2014, 12:41:08 pm
I newer got an answer when i did the syst:opt:inst xxx, but when I checked on the scope, everything was ok.

hmm... that's funny - everybody else says there's supposed to be a progress bar...

regarding uninstall, I just found that issuing ':SYST:OPT:UNINST' provokes no reaction from the scope, but if I issue ':syst:opt:uninstall', a message appears on screen saying all official licenses have been removed  :o
it doesn't change anything regarding installing licenses, though..
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on April 09, 2014, 01:15:35 pm
I think there may have been a timer added if you try to add too many licenses, at least I saw some evidence of this in some of the text strings in one of the newer firmware versions.  You may have to leave it on for awhile to get out of that timer (which may also deplete your trial options).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mrflibble on April 09, 2014, 02:05:37 pm
I think there may have been a timer added if you try to add too many licenses, at least I saw some evidence of this in some of the text strings in one of the newer firmware versions.  You may have to leave it on for awhile to get out of that timer (which may also deplete your trial options).
And while you are at it ... take notes and write down times and stuff. If in fact Rigol did add some counter measures (unconfirmed hypothesis AFAIK), chances are fairly good that you still have a 100% usable instrument. As alank2 suggests, just leave it powered for a while to let it time out.

Not a direct solution to your problem, but more of a hint when controlling Rigol gear through SCPI. Take both the documentation and implementation with a grain of salt. I like Rigol goodies for the very nice price/performance ratio, but in the department of consistency they are not quite there yet. Basically, don't always belief what the docs say a command should be. In case of doubt best to use the full command in upper case.

And whenever you run into a  :wtf: situation where you are not sure if a command just did what you expected you can check status + logs messages.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Teneyes on April 09, 2014, 03:17:12 pm
I think there may have been a timer added if you try to add too many licenses, at least I saw some evidence of this in some of the text strings in one of the newer firmware versions.  You may have to leave it on for awhile to get out of that timer (which may also deplete your trial options).
Try this old trick ,
Set the System Time  to 2099-12-31   23:59;55   and let the Clock roll over.
Then do a Self-Cal.  ( a state that it is in the Factory)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Tilman on April 09, 2014, 03:39:07 pm
Hello,


300MHZ dosen´t work for my DS2072A only 200MHZ works, any solution?

Thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Teneyes on April 09, 2014, 03:46:00 pm
Hello,
300MHZ dosen´t work for my DS2072A only 200MHZ works, any solution?
Thanks
Do you mean you can not Install 300Mhz option?
Try uninstall first, then just Install  300MHz
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hooverphonique on April 09, 2014, 03:49:40 pm
And whenever you run into a  :wtf: situation where you are not sure if a command just did what you expected you can check status + logs messages.

and where do I find those? the DS2000 programming guide doesn't list commands for that, as far as I could see (I didn't read it fully, though)..

Try this old trick ,
Set the System Time  to 2099-12-31   23:59;55   and let the Clock roll over.
Then do a Self-Cal.  ( a state that it is in the Factory)

Thanks for the suggestion.. unfortunately, it didn't make a difference..
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mrflibble on April 09, 2014, 04:03:37 pm
And whenever you run into a  :wtf: situation where you are not sure if a command just did what you expected you can check status + logs messages.

and where do I find those? the DS2000 programming guide doesn't list commands for that, as far as I could see (I didn't read it fully, though)..
Related SCPI commands :

Code: [Select]
*CLS
*STB?
*SRE?
*SRE <val>
:STATUS
:SYSTEM:ERROR?

Don't have a DS2000. Rigol tends to not document everything, so testing a general SCPI command sometimes gives a useful result, 100% depending on what Rigol decided to implement today.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: amr on April 09, 2014, 08:53:03 pm
Hello

I've just tried these codes with my new DS1074Z:

DSAB - Advanced Triggers
DSAC - Decoders
DSAE - 24M Memory
DSAJ - Recorder
DSEA - 100MHz

All options have been installed successfully, but 100 Mhz bandwidth option (DSEA) is not shown in the "Installed Options" screen. Is it right?
The firmware version is 00.02.03.SP5

Thanks.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Suffer1981de on April 09, 2014, 09:01:13 pm
Look under Utility -> System -> Sytem Info. If it says its a DS1104Z then congratulations. I used the option DSER which gave me all of the options altogether.

Greetings from Germany
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: amr on April 09, 2014, 09:15:52 pm
Look under Utility -> System -> Sytem Info. If it says its a DS1104Z then congratulations. I used the option DSER which gave me all of the options altogether

Yes!!!! DS1104Z  :) :) :)

I have not used DSER because "DSBA - 500uV Vertical" seems that can cause some software problems...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Suffer1981de on April 09, 2014, 09:24:41 pm
DSER is all options without the 500uV.  ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: amr on April 09, 2014, 09:58:03 pm
DSER is all options without the 500uV.  ;)

Sorry, I meant "DSFR - all options". I didn't know that code (DSER)... :palm:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: LIV2 on April 10, 2014, 02:20:30 am
So am I the only one with a 1074z with the inability to use some codes?

Are there any other generators besides the riglol online one perhaps?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: toni31 on April 10, 2014, 03:37:04 am
is there any guide of how i install the DSER code?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: amr on April 10, 2014, 05:46:25 am
Have you tried to install option by option?

I followed these steps (Reply #1345):

https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/1335/ (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/1335/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: LIV2 on April 10, 2014, 09:28:57 am
Yeah, I've installed everything except Recording and the 500uv vertical codes.

Don't want 500v, but do want Recording.

When I enter a code for the Recording it tells me the key is invalid, I also noticed that the first two sections of this key differ from all the others which were the same.

What firmware are you running? Maybe something's been changed by rigol.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: amr on April 10, 2014, 09:59:22 am
When I enter a code for the Recording it tells me the key is invalid, I also noticed that the first two sections of this key differ from all the others which were the same.

In my case I have been able to activate that function.

What firmware are you running? Maybe something's been changed by rigol.

The firmware version is 00.02.03.SP5
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Tilman on April 10, 2014, 11:00:48 am
Hello,
300MHZ dosen´t work for my DS2072A only 200MHZ works, any solution?
Thanks
Do you mean you can not Install 300Mhz option?
Try uninstall first, then just Install  300MHz

Yes it Shows "License unavailable", tried uninstalling an installing too.
Had a second one (had an defect) and there the 300MHZ works like a charm
 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Suffer1981de on April 10, 2014, 11:48:06 am
is there any guide of how i install the DSER code?

It's actually simple.

Take your serial number (should have been printed on a piece of paper that comes with the scope), surf to http://riglol.3owl.com/, (http://riglol.3owl.com/,) punch it into the first field, select DSER in the field "Options", use the private key (can be found in this thread somewhere, i think it's 6F1106DDA994DA) and hit generate. The Key you are getting should make everything official incl. the bandwith upgrade.

Greetings
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on April 10, 2014, 01:11:46 pm
use the private key (can be found in this thread somewhere, i think it's 6F1106DDA994DA) and hit generate.
It's actually much simpler than that. Just leave the the private key field blank instead and it will fill it out automatically when you hit generate, finding the correct private key based on what model your entered serial number is for.

Btw. you link is corrupted as you have included a comma at the end of the link.
Here's the correct link: http://riglol.3owl.com (http://riglol.3owl.com)
Canadian mirror: http://gotroot.ca/rigol/riglol/ (http://gotroot.ca/rigol/riglol/)
UK mirror: http://rigol.avotronics.co.uk/mirrors/riglol/ (http://rigol.avotronics.co.uk/mirrors/riglol/)

Here's part of the source code in riglol.c (source code can be downloaded at the bottom of http://riglol.3owl.com (http://riglol.3owl.com))
Code: [Select]
char DP832_private_key[]   = "5C393C30FACCF4";
char DS2000_private_key[]  = "8EEBD4D04C3771";
char DSA815_private_key[]  = "80444DFECE903E";
char DS1000Z_private_key[] = "6F1106DDA994DA";
char no_private_key[]      = "";
}
char *select_priv_key(char *serial) {
    char *priv_key;
    strtoupper(serial);
    if      (!strncmp(serial, "DS1", 3)) priv_key = DS1000Z_private_key;
    else if (!strncmp(serial, "DS2", 3)) priv_key = DS2000_private_key;
    else if (!strncmp(serial, "DS4", 3)) priv_key = DS2000_private_key;
    else if (!strncmp(serial, "DSA", 3)) priv_key = DSA815_private_key;
    else if (!strncmp(serial, "DP8", 3)) priv_key = DP832_private_key;
    else                                 priv_key = no_private_key;
    return priv_key;
}

As you can see for all entered serial numbers starting with "DS1" it automatically picks the correct private key for DS1000Z.
"DS1" = DS1000Z
"DS2" = DS2000
"DS4" = DS4000 (has the same private key as DS2000)
"DSA" = DSA815
"DP8" = DP832
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Suffer1981de on April 10, 2014, 07:45:38 pm
use the private key (can be found in this thread somewhere, i think it's 6F1106DDA994DA) and hit generate.
It's actually much simpler than that. Just leave the the private key field blank instead and it will fill it out automatically when you hit generate, finding the correct private key based on what model your entered serial number is for.

You Sir, are correct! *bow*
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: toni31 on April 10, 2014, 08:23:15 pm
is there any guide of how i install the DSER code?

It's actually simple.

Take your serial number (should have been printed on a piece of paper that comes with the scope), surf to http://riglol.3owl.com/, (http://riglol.3owl.com/,) punch it into the first field, select DSER in the field "Options", use the private key (can be found in this thread somewhere, i think it's 6F1106DDA994DA) and hit generate. The Key you are getting should make everything official incl. the bandwith upgrade.

Greetings
use the private key (can be found in this thread somewhere, i think it's 6F1106DDA994DA) and hit generate.
It's actually much simpler than that. Just leave the the private key field blank instead and it will fill it out automatically when you hit generate, finding the correct private key based on what model your entered serial number is for.

Btw. you link is corrupted as you have included a comma at the end of the link.
Here's the correct link: http://riglol.3owl.com (http://riglol.3owl.com)
Canadian mirror: http://gotroot.ca/rigol/riglol/ (http://gotroot.ca/rigol/riglol/)
UK mirror: http://rigol.avotronics.co.uk/mirrors/riglol/ (http://rigol.avotronics.co.uk/mirrors/riglol/)

Here's part of the source code in riglol.c (source code can be downloaded at the bottom of http://riglol.3owl.com (http://riglol.3owl.com))
Code: [Select]
char DP832_private_key[]   = "5C393C30FACCF4";
char DS2000_private_key[]  = "8EEBD4D04C3771";
char DSA815_private_key[]  = "80444DFECE903E";
char DS1000Z_private_key[] = "6F1106DDA994DA";
char no_private_key[]      = "";
}
char *select_priv_key(char *serial) {
    char *priv_key;
    strtoupper(serial);
    if      (!strncmp(serial, "DS1", 3)) priv_key = DS1000Z_private_key;
    else if (!strncmp(serial, "DS2", 3)) priv_key = DS2000_private_key;
    else if (!strncmp(serial, "DS4", 3)) priv_key = DS2000_private_key;
    else if (!strncmp(serial, "DSA", 3)) priv_key = DSA815_private_key;
    else if (!strncmp(serial, "DP8", 3)) priv_key = DP832_private_key;
    else                                 priv_key = no_private_key;
    return priv_key;
}

As you can see for all entered serial numbers starting with "DS1" it automatically picks the correct private key for DS1000Z.
"DS1" = DS1000Z
"DS2" = DS2000
"DS4" = DS4000 (has the same private key as DS2000)
"DSA" = DSA815
"DP8" = DP832

Thanks guys
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mike G on April 11, 2014, 07:01:17 am
Unable to generate unlock key, solution at last, phew!!
Hi, this is my first post, wanted to say thanks for all the information in this thread and to offer a little bit to the discussion about the key generator for the DS1000Z scope.
Despite reading everything I could find in this thread I was unable to generate an unlock code. The Riglol key generator would tell me if the private key was the wrong length or if the options field was invalid but with the correct information in all fields flatly refused to do anything.      |O   Anyhow having slept on it I wondered if the Windows OS was causing the problem!  My workshop PC is running XP so I have just fired up my Windows 7 laptop and all now works fine.  Hope this can help someone.
My 1074 should be here later today so will post again as to how the "mod" goes. Have generated the DSER key as I don't need the 500uV range.
Thanks again to you all.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mark03 on April 11, 2014, 03:47:08 pm
I received my DS2072A yesterday, and of course first thing, had to try generating a key for it.  But for some reason, it's not working.  Trying to use NS8H for 300 MHz + all options.  And yes, I have read the entire thread.  |O

Because I don't have Windows at home, I used Arkku's method on Linux (post #3105).  Everything appears fine until code entry, at which point the "unavailable" message appears momentarily on-screen.  I first tried entering the code over SCPI (using telnet), then on the scope's front panel.  No luck.  All of the options are still "trial," and same thing after power cycling. 

Someone else had reported the same problem, but I didn't see negative reports for "following the PDF tutorial" i.e. running the tools on Windows and using a hex editor.  So I went through that process today on a Windows 7 machine, and the proposed license key is exactly the same.  (It is kind of comforting to verify that the two methods for putting together the binary data file---Ruby script and manual hex editing---do in fact match.  The size is 146 bytes which matches the tutorial.)

I noticed that a rigup version 0.4 appeared on the gotroot.ca mirror in the last couple of days (I was using version 0.1), so I tried that as well.  All three workflows result in exactly the same key, the one which isn't working.

Tonight when I get home I will try a few more things:
1) change the firmware back to the non-custom (non-IDN-dumping) version
2) send SCPI "uninstall" command
3) try the key again
4) if that doesn't work, generate a key with NSEQ (200 + options) and try it; some folks reported that it works when NS8H does not.

So a huge thanks to all the folks that worked on this; I've been amazed at the level of effort, and am truely grateful.  But, I am starting to wonder if there are some scopes out there for which the existing hack does not quite work?  Unless someone can find a mistake in the above?  The only "nonconforming" thing I've done AFAIK is to use telnet <scope IP> 5555 for entering my SCPI commands instead of installing the Rigol bloat-ware.  Surely that can't make any difference?  People are using the front panel to enter keys successfully too, aren't they?

In case it matters, the key output:

Code: [Select]
RC5KEY1:    82158CF252D2F8EB573A09E3DB176F65
RC5KEY2:    29640D3EB586CF86D65AB36AF88E3BBB
XXTEAKEY:   B759083BEC0B3807D69980B5136E6D94
PUBKEY:     00163745B6A8327B
PRIVKEY:    001B71CCF74A466E
SERIAL:     DS2D154700xxx



Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mrflibble on April 11, 2014, 04:06:54 pm
One thing I noticed when generating a license key for the DSA815... I used rikey_dsa.c from your local friendy mirror and compiled as per the provided instructions.

Then installed license with :SYSTem:LKEY <lic_key> using alex.forencich's python-vxi11 (https://www.eevblog.com/forum/testgear/python-based-instrument-control/) from a quick script. No need for visa bloatware or windoze. :-+

Anyways, the thing to be aware of: the keys that rikey_dsa spits out have minus characters '-' in it. You have to remove those for that :SYSTem:LKEY <lic_key> scpi command.

I don't have my 1074Z yet (hopefully monday! @_@), so cannot comment on that. But just in case some of you run into something as silly as minus characters messing up the key installation.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mike G on April 11, 2014, 04:09:36 pm
Just a quick update.  My DS1074Z arrived midday, entered the key and now have a nice 1104 with everything other than the 500uV range.  I am a very happy bunny   :-+
I read in the thread that you couldn't enter during the trial period but in my case this wasn't so, it went in without a problem.  Thanks everyone for the info in this lengthy thread.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: BTO on April 11, 2014, 05:37:03 pm
Hello Guys, I'm new to the forum

Just bought My Rigol DS2072A 70MHz Scope about 3 days ago

Recently Discovered that i can upgrade My Scope to 200MHz, Possibly even 300MHz.

I have read the entire threads Post's (Wow, to say the least), I've noticed that a lot of info is everywhere.

i would love to thank Cybernet for all his Hard Work
i would Like to thank Dave from EEV Blog
and everyone else that contributed to the reverse engineering of this.

Now. FOR EVERYONE IN MY POSITION WHO OWNS A RIGOL DS2037A

I'll Sum it up for you


1. I don't have an Actual Solution Just yet
2. this is what you need to do step by step

1. Buy the Scope
2. Ensure you have the latest Firmware Installed
3. Obtain Your Scopes Firmware Details by doing the following (And Post it to the forum if you need to ask a question

in your scope Press the "UTILITY" Button that is located at the top of the scope
Now.. Select the "SYSTEM" option by pressing the button to the right of the word "SYSTEM"

Now. Select "SYSTEM INFO" but pressing the button to the right of the option.

My Sceen output is as follows

==================================================
Manufacturer :  RIGOL TECHNOLOGIES
Model :             DS2072A
Serial :             DS2D1XXXXXXXX              (this is your serial number, You'll need it Later)
Software Version : 00.02.01
Hardware Version : 2.0

(THIS NEXT PART WONT SHOW UP BUY DEFAULT), if you want to see it there is a way to do it, but i forgot how)
FPGA Version:   SPU 03.01.09
                         WPU 00.07.01
                         CCU  12.29.00
                         MCU   00.005
============================================================

Now that you have your System information handy...
You'll need to know how to input the Unlock key, when the time comes.

Here is how you get to the menu to input the unlock key..

in your scope Press the "UTILITY" Button that is located at the top of the scope
Now.. Select the "OPTIONS" option by pressing the button to the right of the word "OPTIONS" (if you can't see "OPTIONS" find the very bottom blue arrow buttons and scroll down to get the option "OPTIONS")

at this stage you have the option to select "INSTALLED" (if you do, this will show you What options are Trial version and how much time is remaining on them.
this is the section that you want to come back to you , later, to confirm that the upgrade worked
FOR NOW
Select "SETUP"
NOW.. on this screen the top option will be called "EDITOR" if Editor is OFF (Switch it on, by Pressing the button to the right of EDITOR)

NOTE: if at any point the Menu Bar dissappears, You can make it re appear by Pressing the BLUE "MENU" Button at the top of all the other buttons on the right side of the screen

and just a quickie (if the menu thing gets annoying, you can set the time at which the menu will dissapear by  selecting..
"DISPLAY" Button at the top
"MENU DISPLAY"
Select the Amount of "S" (Seconds you wish) or "Infinite"

NOW, back to the point

Under Utility/Options/Setup

Use the "Intensity" Knob, that is located at the very top of the Scope, next to the Blue "MENU" button
turn it to select your character that you need to input
Push the knob in until you get a click, this will select your character

THIS IS THE AREA WHERE YOU INSERT YOUR UNLOCK KEY

Now.. Your first need to get the unlock key

You will need to do this first

1. Plug your scope into Windows  (I'm using Windows 7 Ultimate)
2. Go to Device Manager,  You will notice that Windows will require a Driver for your Scope
   (Emona did not bother to supply a disk,  instead they said to download it from rigol's site,  Which honestly , is a frickin headache)

You really need to download Just 2 Things


1. Rigol's Ultra Sigma Software (it's a big download,  about 500 MB or so)
here's the link for the Rigol 2072A

http://www.rigolna.com/products/digital-oscilloscopes/ds2000a/ds2072a/ (http://www.rigolna.com/products/digital-oscilloscopes/ds2000a/ds2072a/)

You will need to scroll down the page to the part that says "
Software Applications"
you will see a bunch of PDF's that dont look to be of much relevance (BUT THEY ARE)

2. go to the PDF that Says "Ultra Sigma" and open it
You will come to a stupid looking page that looks like you hit a speed hump

you will see this

=====================================================

Download
Thank You For your request

Please click the link below to open/download your chosen resource.
If you see an Error below please hit Refresh.

THEN IN BIG LETTERS under that you will see


ULTRA SIGMA  (you need to click on the Word "ULTRA SIGMA"

Apparently someone at Emona thought this was "Obviously" a Hyperlink  LOL

if your download does not start, You need to register for a free account (it's pretty quick and easy)
after you do that, come back to the download page and repeat the process

Now.. make a cup of coffee and pray to god that if you download the file , that it actually isn't corrupted

i had to try 5 Times, Downloading (yes i have a stable and fast internet connection)
When i went to extract the file the last 2 Archives appeared to be corrupted and i had to re download the whole bloody thing

it will happen eventually,

Since the File is a .zip file, you will need Winzip to Extract it
My advise is.. Make a New folder, Place the file in that folder and extract it, to that folder

This software now needs to be installed
upon download it will be called   Ultra Sigma(PC)Installer_00.01.05.10

when you open it, there will be an application file called "Setup"
Obviously,  Run this file as Administrator and install, as you would any other application.
it takes a while

at about 15 % or so, you will notice that it will install the Driver package (so you don't have to do that seperately)

Once it's all installed
You will have 2 New Icons on your desktop
Ni Max    and
Ultra Sigma

if you open Ultra Sigma
Select USB-TMC
and double click on your Scope's Name

this will bring up a  "SCPI" Command
(now, i'm not sure what to enter here, but.. i do know this part is relevant to the solution)

NOW, THIS IS WHERE I'M UP TO

You need 3 Things to get your Scope Unlocked

1. You serial Number,  as stated above (or.. it's on the sticker on the bottom of your scope)
2. You need to know the OPTIONS Key that you need to use
Here they are (Choose what you wish to unlock)
DS2000 device options:
first character: D = official, V = trial
DSAB - Advanced Triggers
DSAC - I2C, SPI and RS232 Decoders
DSEA - CAN Decoder
DSAE - 56M Memory
DSAJ - 100MHz
DSAS - 200MHz
DSCA - 300MHz
DSHH - all options

You will Most likely want all the options and the highest Bandwidth, therefore
you will want to use   "DSHH"  (Remember this)

3. now, you need to the "PRIVATE KEY"

go to this site
http://riglol.3owl.com/ (http://riglol.3owl.com/)

First Enter the OPTION

Then Your "Serial Number"

Then you need to enter the Private Key  (Now. here's the catch)
According to the forum this is the private key

8EEBD4D04C3771  (for this model of Scope)

and the idea is ....
Enter the OPTION
ENTER your serieal Number
Enter the private key

then click  GENERATE

a new window will open and it will display a Key (this is the Unlock key you need to enter into your Scope AS DESCRIBED ABOVE

and the result should be,  you will find that your Trial Options Are not longer trials but fully licensed and you Bandwidth will either go up to 200 Mhz or 300 MHz  (i think it's 300 MHz)

the thing about the private key is ... (it's private)  LOL

so, thanks to CYBERNET  (READ THIS, IT'S HELPFUL)
http://svn.clifford.at/handicraft/2013/rigol-ds2000-shell/rigol-4in1-keygen.c (http://svn.clifford.at/handicraft/2013/rigol-ds2000-shell/rigol-4in1-keygen.c)
and this
http://hackaday.com/2013/07/24/a-keygen-for-the-rigol-2000-series-scopes/ (http://hackaday.com/2013/07/24/a-keygen-for-the-rigol-2000-series-scopes/)

he has issued us this .txt doc
Rigolkey.c

Now. apparently this .txt doc is supposed to be compiled in some way
and then loaded onto a USB stick
and then inserted into the scope upon bootup

Your supposed to Hold down the HELP button and the press the POWER button
then quickly press the Help button twice

and that's supposed to load the firmware from the Stick to unlock your Scope

the other thing is .. You can apparently just enter the number


NOW.. HERE'S MY PROBLEM

AND IF ANYONE CAN HELP, I WOULD GREATLY APPRECIATE IT

Please Note : I have a Rigol DS2072A     Not  DS2072

I'm using this
http://riglol.3owl.com/ (http://riglol.3owl.com/)

in combination with my Serial Number
and i've tried the following Options

DSA9
DSHH

I've tried the following private keys

8EEBD4D04C3771
there was one other
but.. neither one worked

I keep getting the following message

"License is unavailable"    Thus.. it didn't work

Please advise,
what am i doing wrong
What have i overlooked

Thanks ahead of time

Sorry for the length Post
I just thought i would help all the Newbies to the scope out there
and help them overcome the issues i had.

Hope to hear from you guys soon

I would appreciate input from CYBERNET  (he seems to be  "The Man" at this point.

Be Cool Guys,
All Help is greatly appreciated.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hooverphonique on April 11, 2014, 05:45:32 pm
you're mixing up procedures for the A and non-A versions.. the combinations you are listing (DS**) are for the non-A only and for use with the riglol site..

for the A model you need to flash a custom firmware to get access to a blob of data that is needed for input to the rigup program in order for it to generate the licenses...

try reading the thread again... or at least the last handful of pages..
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: BTO on April 11, 2014, 05:46:14 pm
I don't know if this is relevant or not,

but, all of my above attempts to enter the key, were done DURING the Trial Period
I have 743 Minutes left to go

i suppose if i don't find a solution in that time
i will repeat everything that i have tried, after the Trial period and advise the forum if it works

further to that, i think i'm just using the incorrect private key, Perhaps.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: BTO on April 11, 2014, 05:57:31 pm
HELLO hooverphonique
Oh OK
I did notice (of course that some of these entries are a little old and date back to the DS1000 Series, and there was a lot to filter through and decide what was not relevant and what was), I had to piece bits and pieces together and figure it all out.

Now.. i don't mind re reading the whole thing over again
but.. are you referring to that thing that CYBERNET put up about Flashing the Custom Firmware so that when you load it onto the scope the DS2072A will show up as a DS2022

is that what your referring to ?

if so, i then need to build a PC and Load Linux onto it (My linux skills are limited, Probably good enough to Use Basic Shell Commands in Linux, but I'm not  Linux Expert by any means)

the part that confuses me is when we mention the work "compile"

i sort of understand that you need a compiler to (Put together) or "compile" if you will
a script or program
the issue is i don't know how to compile

if it's just an issue of Somehow Getting a .txt file from my PC or from the scope and editing it, using a text editor ... (no worries), i just need to know what line of code to edit

if it's a matter of convert one numbering system to another piece of code,  I'm good with that also

I just need to be pointed in the right direction
i understand the point is not, to hand this to me on a platter,

and in all honesty, i would prefer to learn how this is done
but, at the same time, i would like full access to my scope ASAP

either way, i'm going to go back through the POSTS and read it all again and learn how it was reverse engineered to begin with ,  Reverse engineering is something that i don't understand fully.

so.. What help can you offer me from this point.

thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: BTO on April 11, 2014, 06:31:19 pm
@    hooverphonique

Hey Mate

you had me confused at first

i think i'm on the right track now,
at least that something

thanks for the guidance

I'll keep at it and see where i get to

one problem i have is that most of the download files are no longer at their Download locaitons

anyway, i'll keep at it and when i get a solution i'll post it for other to see.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mark03 on April 11, 2014, 06:54:51 pm
anyway, i'll keep at it and when i get a solution i'll post it for other to see.

A tutorial already exists:
http://gotroot.ca/rigol/D2072A%20Unlocking%20Guide.pdf (http://gotroot.ca/rigol/D2072A%20Unlocking%20Guide.pdf)
and you should find all of your missing links there too.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: GlassFET on April 11, 2014, 08:53:51 pm
A tutorial already exists:
http://gotroot.ca/rigol/D2072A%20Unlocking%20Guide.pdf (http://gotroot.ca/rigol/D2072A%20Unlocking%20Guide.pdf)
and you should find all of your missing links there too.

Five of us have used that same guide to upgrade our DS2000A scopes. Worked each time. Just follow the instructions EXACTLY. If you're using a Mac or Linux, borrow a Windows machine to run the prescribed programs. You can always wash your hands and return safely to your Mac or Linux later... ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mark03 on April 11, 2014, 09:02:05 pm
Five of us have used that same guide to upgrade our DS2000A scopes. Worked each time.

...and one has not.  See my post above.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mark03 on April 12, 2014, 02:05:33 am
Follow-up to my report earlier today (#3228):

I can now confirm that the code NS8H does not work on my DS2072A.  This is after changing the firmware back to stock (00.02.01.00.03), rebooting, sending :SYSTEM:OPTION:UNINSTALL, rebooting again, and trying the key again.  It simply says "License is unavailable!"

However, upon trying code NSEQ, it worked right away the first time.  Surveying the last few months of posts, it seems like many have had the same experience.  Enough not to dismiss them as mistakes (although I admit I did before now).  There really does seem to be something odd about the 300-MHz option, where it works with some serial #'s and not with others, or it depends on some other variable we haven't controlled.

It would sure be nice to understand what is going on; however, I'm happy to declare victory.  Thanks again!  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Arkku on April 12, 2014, 10:37:21 am
Because I don't have Windows at home, I used Arkku's method on Linux (post #3105).



So I went through that process today on a Windows 7 machine, and the proposed license key is exactly the same.  (It is kind of comforting to verify that the two methods for putting together the binary data file---Ruby script and manual hex editing---do in fact match.

Thanks for verifying that, I was worried for a bit that I had messed something up. =)

I updated the Linux/OS X/*nix guide (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg403624/#msg403624) with the suggestion to try NSEQ if NS8H fails.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: BTO on April 13, 2014, 02:05:26 pm
This is Exellent News, I'm just trying to access the download file at the posted location
https://mega.co.nz/#!FFk10SCY!UuWPXyqZwmca00pa2clOth1ryh1Z-AAgJg2yibfoUw0


However the file is no longer available, where can i get another copy

thanks up front
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hooverphonique on April 13, 2014, 05:42:57 pm
This is Exellent News, I'm just trying to access the download file at the posted location
https://mega.co.nz/#!FFk10SCY!UuWPXyqZwmca00pa2clOth1ryh1Z-AAgJg2yibfoUw0


However the file is no longer available, where can i get another copy

thanks up front

the required files should be available at gotroot.ca/rigol
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hooverphonique on April 13, 2014, 05:47:58 pm
I'm considering using the patched firmware to get my scope options licensed as my scope still won't accept any license keys anymore...

Am I correct in saying that the patched firmware is actually a fw for the non-A version, patched to run on the A version, accepting the non-A licenses generated by riglol? will the licenses stay on the scope after reverting back to the original 02.01.00.03 firmware? Are there any downsides to using this approach compared to using the rigup way?


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mrflibble on April 13, 2014, 07:05:31 pm
I'm considering using the patched firmware to get my scope options licensed as my scope still won't accept any license keys anymore...

Am I correct in saying that the patched firmware is actually a fw for the non-A version, patched to run on the A version, accepting the non-A licenses generated by riglol? will the licenses stay on the scope after reverting back to the original 02.01.00.03 firmware? Are there any downsides to using this approach compared to using the rigup way?
As in I think it went like this: rigol original firmware DS2072A ==> creative person => patched firmware to be used on DS2072A.

Anyways, the SOLE purpose of the patched firmware is to extract the private key on a DS2072A. Once you have the priv key, you can restore everything to factory original by restoring original firmware.

After that you have your paws on the private key, plonk that into your favorite keygen to generate license keys. Those license keys should then be viable for a DS2072A with original firmware and also viable for a DS2072A with patched firmware.

Again, once you have the private key for your particular scope you can use rigol original firmware.

And the big-ass disclaimer is that I don't own a DS2072A, but try more or less to keep up with this thread. :P
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hooverphonique on April 13, 2014, 07:39:48 pm
Anyways, the SOLE purpose of the patched firmware is to extract the private key on a DS2072A. Once you have the priv key, you can restore everything to factory original by restoring original firmware.

After that you have your paws on the private key, plonk that into your favorite keygen to generate license keys. Those license keys should then be viable for a DS2072A with original firmware and also viable for a DS2072A with patched firmware.

Again, once you have the private key for your particular scope you can use rigol original firmware.

And the big-ass disclaimer is that I don't own a DS2072A, but try more or less to keep up with this thread. :P

thanks for that, but that's the procedure that doesn't work for me (read my posts from earlier this week)..
I was referring to the firmware on gotroot.ca/rigol by the name of "(patched)", not the license dump one..
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Arkku on April 13, 2014, 07:57:48 pm
Am I correct in saying that the patched firmware is actually a fw for the non-A version, patched to run on the A version, accepting the non-A licenses generated by riglol? will the licenses stay on the scope after reverting back to the original 02.01.00.03 firmware? Are there any downsides to using this approach compared to using the rigup way?

AFAIK there are two patched firmwares, both modified from the A-version firmware:

1) License keys dump firmware
2) A-version firmware that accepts non-A-keys

The first one is used to generate valid A-version license keys, which continue to work on official (non-patched) firmware versions. The second one is used to circumvent the need for A-version keys on that firmware version only. The former is obviously better since the keys will work on official firmware as well, whereas it seems to me that the latter needs someone to patch every new firmware version.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: icaro600 on April 13, 2014, 09:37:03 pm
Hi there, I,m recently discovered this impresive forum, and it is one of the best forums about electronics  I even seen, so congratulations for your job.
My post is because I, thinking about to buy a Rigol DS1074Z, and my question is if the keygen fror DS2000 could be valid also for this DSO, or if there is someone who is working on it.

Thanks

Icaro
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PedroDaGr8 on April 13, 2014, 10:53:35 pm
Hi there, I,m recently discovered this impresive forum, and it is one of the best forums about electronics  I even seen, so congratulations for your job.
My post is because I, thinking about to buy a Rigol DS1074Z, and my question is if the keygen fror DS2000 could be valid also for this DSO, or if there is someone who is working on it.

Thanks

Icaro

Read the thread, it's well discussed.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on April 14, 2014, 12:26:51 pm
Hi there, I,m recently discovered this impresive forum, and it is one of the best forums about electronics  I even seen, so congratulations for your job.
My post is because I, thinking about to buy a Rigol DS1074Z, and my question is if the keygen fror DS2000 could be valid also for this DSO, or if there is someone who is working on it.

Thanks

Icaro
Use one of the On-Line Keygenerator (you want to use it for DS1000z) at* > 
RigLol keygen: http://riglol.3owl.com (http://riglol.3owl.com)
Canadian mirror: http://gotroot.ca/rigol/riglol/ (http://gotroot.ca/rigol/riglol/)
UK mirror: http://rigol.avotronics.co.uk/mirrors/riglol/ (http://rigol.avotronics.co.uk/mirrors/riglol/)

Do NOT install 500uV Vertical Sensitivity, as it doesn't work properly (buggy*).  Therefore do NOT use 'DSBA' - 500uV Vertical, or 'DSFR' - all options.

1. Type in your unit's Serial Number.
2. Type in DSER* for all options without the 500µV. This Option may not be in the Keygen's list, but it will work!
3. Do NOT enter anything for 'Privatekey', it will be inserted automatically for you (based on the DS1000z).
4. Press [GENERATE], and record the resulting Option Code.
5. When you are done enter the Option Code manually in the DS1000z using a single string without using any 'dash' (-) using Rigol's Procedure for activating the Trial Options in the D1000z.  As I recall the procedure is available on Rigol's Web Site under DS1000z.

    Good Luck, and if you have questions please feel free to ask me.

Note: * Edited from information provided by, and thanks to 'AndersAnd' in Reply #3253 below.
    Thank you AndersAnd, Ted

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hooverphonique on April 14, 2014, 01:33:59 pm
I think there may have been a timer added if you try to add too many licenses, at least I saw some evidence of this in some of the text strings in one of the newer firmware versions.  You may have to leave it on for awhile to get out of that timer (which may also deplete your trial options).
And while you are at it ... take notes and write down times and stuff. If in fact Rigol did add some counter measures (unconfirmed hypothesis AFAIK), chances are fairly good that you still have a 100% usable instrument. As alank2 suggests, just leave it powered for a while to let it time out.

Success! I have now installed the 300MHz key generated by rigup 0.1 and all options are now listed as official.. I left the scope powered, but off, for some days and it now reacts to ":SYSTEM:OPT:INSTALL <key>" again..

It seems the timeout is somewhere between 2 and 4 days.. the trial keys still had minutes left, so it doesn't appear to be linked to those..

cheers everyone, and thanks for the great work..
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: BTO on April 14, 2014, 03:05:26 pm
Just thought i would POST the fact that i've managed to upgrade my scope
DS2072A from 70Mhz - 300Mhz

if anyone needs help, let me know
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Wim13 on April 14, 2014, 04:27:46 pm
I think there may have been a timer added if you try to add too many licenses, at least I saw some evidence of this in some of the text strings in one of the newer firmware versions.  You may have to leave it on for awhile to get out of that timer (which may also deplete your trial options).
And while you are at it ... take notes and write down times and stuff. If in fact Rigol did add some counter measures (unconfirmed hypothesis AFAIK), chances are fairly good that you still have a 100% usable instrument. As alank2 suggests, just leave it powered for a while to let it time out.

In the FW there is this text: refused to install, please try again after 12 hours,
and also : interval to short, pls try again after 30 seconds.

so it seems there are some brute force restrictions build in.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on April 14, 2014, 06:10:50 pm
5. Repeat Step 1. through 4. for each Option code (DSAC, DSAE, etc.).
No need to do this. Simply enter DSER as the only option code instead. DSER is all options without the 500µV.
DSFR on the other hand has the buggy 500µV included as well, so only use DSER.
DSER is not listed at the keygen website, but it still works.
I think you should update you post with the guide to use DSER instead.

And while you're at it, http://rigol.avotronics.co.uk/mirrors/riglol/ (http://rigol.avotronics.co.uk/mirrors/riglol/) is just a mirror of the original keygen site http://riglol.3owl.com (http://riglol.3owl.com) there's another mirror at http://gotroot.ca/rigol/riglol/ (http://gotroot.ca/rigol/riglol/)

I think you shopuld mention all three sites (some have problems accessing http://riglol.3owl.com (http://riglol.3owl.com) and the other sites might be down from time to time too, so better mention all 3:

RigLol keygen: http://riglol.3owl.com (http://riglol.3owl.com)
Canadian mirror: http://gotroot.ca/rigol/riglol/ (http://gotroot.ca/rigol/riglol/)
UK mirror: http://rigol.avotronics.co.uk/mirrors/riglol/ (http://rigol.avotronics.co.uk/mirrors/riglol/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: icaro600 on April 15, 2014, 09:09:20 am
Thanks alot PedrodaGr8 and Ted572¡¡.  Just waiting for my DS1074Z, is comming¡¡¡

 :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hans on April 15, 2014, 09:15:24 am
5. Repeat Step 1. through 4. for each Option code (DSAC, DSAE, etc.).
No need to do this. Simply enter DSER as the only option code instead. DSER is all options without the 500µV.
DSFR on the other hand has the buggy 500µV included as well, so only use DSER.
DSER is not listed at the keygen website, but it still works.
I think you should update you post with the guide to use DSER instead.


Indeed, that would have been nice... It's not listed on the page, and blindly entered the "All Options" option. I've tried the 500uV/div setting, and it is indeed very buggy. Now it's annoying to have the bugged range everytime I scroll back to minimum V/div. Is there any way to undo keys?
My scope runs the SP5 firmware at this moment.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on April 15, 2014, 10:37:17 pm
Yes, this is off topic.  I wanted to be sure we have an opportunity to get Rigol Service Guides/Manuals for the following:

1. DM3051,2,4,3061,2,4 Series,  2. DM3058,  3. DM3068,  4. DS1000D,E Series, and  5. DS4000.

https://www.eevblog.com/forum/testgear/rigol-service-manuals-where-to-find/msg426526/#msg426526 (https://www.eevblog.com/forum/testgear/rigol-service-manuals-where-to-find/msg426526/#msg426526)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alexwhittemore on April 16, 2014, 07:33:48 am
Hi

After reading in Suffer1981de's post about the DS1000Z firmware 00.02.03.SP5, I e-mailed my scope dealer and immediately received the new firmware. Although "new" is probably relative: seems to have been released on Jan. 26th, already. Haven't yet looked for changes or bug-fixes but noticed that the measurement menu on the left side has gained the 8 new measurements that are documented in the User Guide from Jan 2014, which is online on Rigol's website for quite some time, already.

Here is a link to the firmware:  http://www.filedropper.com/ds1000zupdate-v000203sp5 (http://www.filedropper.com/ds1000zupdate-v000203sp5)

Have fun. :-)

This link seems dead. Does anyone have a working one? Is this update legit?

EDIT: Also, I know that the 500µV/div option doesn't seem to work for anyone, but my understanding is that you can set it, but the signal is offset wrong. I enabled the option (or, at least, I fed it a code it took that should have), but I can't seem to go down that low, my lowest vertical setting is 500mV. Incidentally, that setting works.

Oh. Duh. Probe attenuation factor. Set to 1, I see 500µV. Okay, so I've definitely noticed the problem where it flies off screen never to return, but depending on tongue angle it seems to work fine.

That said, I don't think there's anything special going on here: I notice that, with my vertical at 500uV, the discrete ADC steps are clearly visible. They look to be about 60µV tall. When I switch to 1mV/div, I still see steps, about half as tall on screen, which is to say they still look to be 60µV tall. It seems that, in both 1mV and 500uV/div modes, the ADC is scaled to 15.36mV p-p full scale, which actually is close enough that it seems believable that the 2mV/div range is the lowest range where full scale is actually all 8 divisions on screen (and the descretization steps are actually 62.5µV and not 60 as I roughly measured with cursors).

Not to say I'm too bummed out about that, a closer view is still helpful. But I don't think your input resolution is actually improving any when lower than 2mV/div, you're just seeing a digitally zoomed-in picture. If that's true, why not 200µV/div as well? Though at that point you'd only be seeing 3.2 steps per division, which would be almost more misleading than useful.

EDIT again: By the same token, I kind of which I had a 1ns/div timebase setting. Though of course it'd only represent one sample per division.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybermaus on April 20, 2014, 06:39:57 am
Hi

After reading in Suffer1981de's post about the DS1000Z firmware 00.02.03.SP5, I e-mailed my scope dealer and immediately received the new firmware. Although "new" is probably relative: seems to have been released on Jan. 26th, already. Haven't yet looked for changes or bug-fixes but noticed that the measurement menu on the left side has gained the 8 new measurements that are documented in the User Guide from Jan 2014, which is online on Rigol's website for quite some time, already.

Here is a link to the firmware:  http://www.filedropper.com/ds1000zupdate-v000203sp5 (http://www.filedropper.com/ds1000zupdate-v000203sp5)

Have fun. :-)

This link seems dead. Does anyone have a working one? Is this update legit?

Indeed. Anyone has a mirror for that firmware?
Thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alexwhittemore on April 20, 2014, 03:47:09 pm
Requested an update from rigol of it exists, but I haven't heard back. Also reported a couple existing firmware bugs, haven't heard back there either yet.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on April 21, 2014, 03:33:14 pm
Sadly, this thread no longer has anything to do with its named Subject.  :'(  And hasn't for some time.  It's now the, "Can someone explain to me again (for the 100th time) how to hack the options on my Rigol" thread.  :rant: 

That's too bad, because it used to be quite interesting.  But as a result, I'm no longer following it, and I suspect many others have dropped out as well.   |O

In retrospect, it would have been wise, once the flood of newbies-without-a-clue arrived, to have spawned off a separate discussion for that.  But I suspect no one anticipated how quickly that would take over.  Someone could still do that, but I'm not sure at this point if there's any hope for recovery in this one.  It's likely permanently polluted.  It's serving two completely different audiences, and as a result, does neither well.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Sparky on April 21, 2014, 05:48:53 pm
Sadly, this thread no longer has anything to do with its named Subject.  :'(  And hasn't for some time....
That's too bad, because it used to be quite interesting.  But as a result, I'm no longer following it, and I suspect many others have dropped out as well.   |O

How about DP832 v01.09 firmware investigation? There has been some change of keys etc after the v01.09 firmware...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alexwhittemore on April 21, 2014, 06:00:39 pm
In retrospect, it would have been wise, once the flood of newbies-without-a-clue arrived, to have spawned off a separate discussion for that.

Newbies without a clue? This thread was off topic as soon as the discussion arose of elliptic curve implementation weakness and the possibility of key generation, and it was already a good 30 pages in at the time. Really, 15 pages before even that with trial keys. Hardly the work of newbies without a clue. Have some perspective and try to be a little less holier-than-thou.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gallymimus on April 21, 2014, 11:36:07 pm
In retrospect, it would have been wise, once the flood of newbies-without-a-clue arrived, to have spawned off a separate discussion for that.

Newbies without a clue? This thread was off topic as soon as the discussion arose of elliptic curve implementation weakness and the possibility of key generation, and it was already a good 30 pages in at the time. Really, 15 pages before even that with trial keys. Hardly the work of newbies without a clue. Have some perspective and try to be a little less holier-than-thou.

Lamenting some level of thread organization in retrospect is far from holier than thou.  What are you smoking?

Even at this stage spinning off threads would probably be sensible.  I'd vote for a new tech discussion thread and leave the "how do I mod my scope" messages here.  The more dedicated technical folks are more likely to embrace a new thread than the 1 post help me'ers
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mrflibble on April 22, 2014, 12:13:36 am
I'd vote for a new tech discussion thread and leave the "how do I mod my scope" messages here.  The more dedicated technical folks are more likely to embrace a new thread than the 1 post help me'ers

Vote with your keyboard. ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gallymimus on April 22, 2014, 12:50:49 am
I'd vote for a new tech discussion thread and leave the "how do I mod my scope" messages here.  The more dedicated technical folks are more likely to embrace a new thread than the 1 post help me'ers

Vote with your keyboard. ;)

I did! +1
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Teneyes on April 22, 2014, 08:06:28 am
Hello All
   I just received  new FW 00.03.00.01.03 for DS2000
   Has anyone got this version???
   It seems to fix bugs I had found, more testing to do.
   See Pic for new Acquire Menu , room for Logic speed setting I wonder???
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on April 22, 2014, 08:23:38 pm
Hello All
   I just received  new FW 00.03.00.01.03 for DS2000
   Has anyone got this version???
   It seems to fix bugs I had found, more testing to do.
   See Pic for new Acquire Menu , room for Logic speed setting I wonder???
Do you still have 200 MHz BW and the all other Options?
  Thank you for the info, Ted572
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Teneyes on April 22, 2014, 09:02:13 pm
 I just install  new FW 00.03.00.01.03 for DS2000
Do you still have 200 MHz BW and the all other Options?
As much as I can check the configuration was Not Changed . all Offcial
To me it looks like a Self-Cal will be required. ( different Cali. from FW00.02......
Easy to go back older FW 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: icaro600 on April 24, 2014, 06:33:31 pm
Use one of the On-Line Keygenerator (you want to use it for DS1000z) at* > 
RigLol keygen: http://riglol.3owl.com (http://riglol.3owl.com)
Canadian mirror: http://gotroot.ca/rigol/riglol/ (http://gotroot.ca/rigol/riglol/)
UK mirror: http://rigol.avotronics.co.uk/mirrors/riglol/ (http://rigol.avotronics.co.uk/mirrors/riglol/)

Do NOT install 500uV Vertical Sensitivity, as it doesn't work properly (buggy*).  Therefore do NOT use 'DSBA' - 500uV Vertical, or 'DSFR' - all options.

1. Type in your unit's Serial Number.
2. Type in DSER* for all options without the 500µV. This Option may not be in the Keygen's list, but it will work!
3. Do NOT enter anything for 'Privatekey', it will be inserted automatically for you (based on the DS1000z).
4. Press [GENERATE], and record the resulting Option Code.
5. When you are done enter the Option Code manually in the DS1000z using a single string without using any 'dash' (-) using Rigol's Procedure for activating the Trial Options in the D1000z.  As I recall the procedure is available on Rigol's Web Site under DS1000z.


Hi all, my new DS1074Z has arrived. Applying the procedure of Ted572 using the code DSER all options ok. But the 100MHz increase has no effect, the minimum setting of the time base still in 5us. After unblock all the features I have typed in the key generated with the code DSEA, reset the Rigol but still in 5us.
Any suggestion? Maybe I,m forgot something?

Thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gallymimus on April 24, 2014, 06:41:06 pm


Hi all, my new DS1074Z has arrived. Applying the procedure of Ted572 using the code DSER all options ok. But the 100MHz increase has no effect, the minimum setting of the time base still in 5us. After unblock all the features I have typed in the key generated with the code DSEA, reset the Rigol but still in 5us.
Any suggestion? Maybe I,m forgot something?

Thanks

Did you check the model number in the settings on the scope?  If it worked it will say DS1104z instead of DS1074z
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: icaro600 on April 24, 2014, 06:46:01 pm
Sorry guys, I have noted the model has changed to DS1104Z in the System Information window, so this is ok
By the way my firmware version is 00.02.03.SP5

Regards
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alexwhittemore on April 24, 2014, 06:49:42 pm
I assume you mean 5ns, not 5µs. That's normal, the lowest timebase even on the 1104z is 5ns. With 100MHz of bandwidth, that's one period of a pure 100MHz signal per two divisions. It'd be nice to get a little more zoom, but eh.

Anyway the proper way to verify that the option is enabled is to put in a 100MHz sine wave and verify that it's no more than 3dB lower in amplitude than the same source generating a much lower frequency at the same amplitude setting. But then, finding a 1GHz bandwidth function generator is a tall order, so the REAL way to do it is to measure the rise time on a sharp-edged signal - a positive going digital edge from an Arduino is probably sufficient, but your function generator isn't: I know my Tek FG503 puts out up to 3MHz signals, but it has an output bandwidth of only around 7MHz so 3MHz square waves are QUITE rounded.

Anyway, once you know the rise time of an edge with assumed infinite bandwidth, rule of thumb is scope bandwidth = .35/(rise time). So if the rise time off my function generator square wave, is, for example, 56ns, .35/(56ns) = 6.25MHz.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: icaro600 on April 24, 2014, 07:42:41 pm
Thanks Alex, your are right I meant 5ns
Thanks for your explanation, I will do it

Regards
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: probez on April 25, 2014, 07:51:20 pm
I just received my DP832. But they shipped it with the new firmware 00.01.09.00.01 there doesn’t support downgrade. So the key generator doesn’t work. I have a DS2072A-s there is total unlocked at 300 MHz. The DP832 may have another protection but if not, it could be nice to have a custom based firmware to reveal a possible internal unique private key like the DS2000A scopes (https://docs.google.com/file/d/0B8yFRtbwGWr5QVBGS2NoMlo2WVU/edit (https://docs.google.com/file/d/0B8yFRtbwGWr5QVBGS2NoMlo2WVU/edit)). I guess the interest in the DS2000A series is more intensive than the DP800 series. But I have search around in the forum and found that I am absolutely not the only one there isn’t able to use the lovely keygens.
P.S. I would possible not need the features, but it would be fantastic to have all the features. I have of cause tried to firmware downgrade anyway but I can confirm it doesn’t work.

Software information
Digital Version: 00.01.09.00.01
Analog version: 01.02.00.01.02.00
Boot version: 01.06
Keyboard version: 01.01
Calibrated the 24th of Feb. at the factory
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on April 30, 2014, 04:23:53 am
GOOD NEWS ON THE SERIAL RESET PROCEDURE

I figured out the trick as to why it wasn't resetting. I could swear I covered this before.

The issue people are having is that they can't reset the SN even after following all the steps. The key (to which I didn't get an answer before but verified) is that there MUST be a valid key installed. Basically it won't work if there are no keys to uninstall. I made an xx0001 key for DSAZ, installed it, rebooted and then it worked :)

Follow these modified snmodfix instructions...

Code: [Select]
1.  Requires 00.01.01.00.02 firmware (7777543 bytes, 0xa167ef30 crc32) named
       DS2000Update.gel in same directory as executable
2.  Execute snmodfix and specify serial and model to patch firmware
3.  Flash patched ds2000update.gel using power on help button method
4.  Restart scope
  4.1 After restarted, make sure a trace is showing
5.  Enable advanced system information menu (press Trigger Menu, Menu 7,
       Menu 6, Menu 7, Utility very quickly) to enable it
6.  Show system information - serial should be fixed but NOT saved to flash
      yet - some text labels will be missing (?)
7.  Connect using scpi and issue :SYSTem:OPTion:UNINSTall command which will
      uninstall all keys and save to flash
  7.1 If the info screen disappeared and the traces flashed, success! Move to step 8
  7.2 You don't have a key installed. Install a key for DS2A0000000001 with :SYSTem:OPTion:INSTall <key> - make sure the key has no dashes
  7.3 The screen should flash and the info screen should disappear along with the License installed message.
        If this happened proceed to step 4, otherwise you have no hope
8.  Once settled and the info screen disappeared restart scope
9.  Show system information (not advanced) should now show the correct serial
      and model
10. Update to latest stock unpatched firmware version
11. Storage -> Default
12. Reinstall any key(s)

If this fails, something else I did was install the latest 3.00.xx.xx firmware - to replicate what I did, install it, at first powerup clear FRAM by holding left F6 (sixth softkey from the top on the left side) before turning on, then follow the instructions above.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: metalphreak on May 03, 2014, 01:33:22 pm
DS1000ZUpdate-v00.02.03.SP5.part1.rar - https://mega.co.nz/#!6RtykAiR!abG81x_vl89xTWZ9noAsmfcTVsWcInlZDdsDwkuOQEo
DS1000ZUpdate-v00.02.03.SP5.part2.rar - https://mega.co.nz/#!bVd32RhS!TqGQmeB6_oQQwMj5OZ9FFVr6ZEy5aVY2vpD0Ip7LWz8

Found on a chinese forum (with a link back to this thread) - clearly they were smart to host it locally ;)

Haven't tested it yet.


Rigol's website contact form is useless. I've asked twice now for firmware updates with no response.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Circlotron on May 05, 2014, 09:02:04 am
But then, finding a 1GHz bandwidth function generator is a tall order, so the REAL way to do it is to measure the rise time on a sharp-edged signal -snip- Anyway, once you know the rise time of an edge with assumed infinite bandwidth, rule of thumb is scope bandwidth = .35/(rise time). So if the rise time off my function generator square wave, is, for example, 56ns, .35/(56ns) = 6.25MHz.
I did it like this -> https://www.eevblog.com/forum/testgear/risetime-of-hacked-ds2072/msg321568/#msg321568 (https://www.eevblog.com/forum/testgear/risetime-of-hacked-ds2072/msg321568/#msg321568)
By that formula I got 243MHz.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: GlassFET on May 05, 2014, 10:37:26 pm
The relationship BW = 0.35/(10-to-90% rise time) only applies to a first-order system (having a single-pole filter, which makes a 6-dB-per-octave roll-off with zero overshoot). The anti-aliasing filters and intrinsic roll-offs of input components in these scopes are likely greater than first-order, rendering this formula inaccurate. The best way to measure BW is to measure it as I described in an earlier post, by using an RF signal generator into 50 ohms. Granted, not everyone has access to these instruments, and I applaud the ingenious idea of discharging a cap. But the 11.44% overshoot demonstrates that the rule of thumb is not accurate for this case. See the response curves for the TI LMH6518 variable gain amplifier, alleged to be used in the DS2000A. The higher bandwidths choices have steeper and more complex roll-offs. Ironically, the rise time formula probably is most accurate when the BW is limited to 20MHz.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on May 06, 2014, 02:29:04 pm
The relationship BW = 0.35/(10-to-90% rise time) only applies to a first-order system (having a single-pole filter, which makes a 6-dB-per-octave roll-off with zero overshoot). The anti-aliasing filters and intrinsic roll-offs of input components in these scopes are likely greater than first-order, rendering this formula inaccurate. The best way to measure BW is to measure it as I described in an earlier post, by using an RF signal generator into 50 ohms. Granted, not everyone has access to these instruments, and I applaud the ingenious idea of discharging a cap. But the 11.44% overshoot demonstrates that the rule of thumb is not accurate for this case. See the response curves for the TI LMH6518 variable gain amplifier, alleged to be used in the DS2000A. The higher bandwidths choices have steeper and more complex roll-offs. Ironically, the rise time formula probably is most accurate when the BW is limited to 20MHz.
HP/Agilent/Keysight has this application note about the relation between BW and rise-time:

http://cp.literature.agilent.com/litweb/pdf/5988-8008EN.pdf (http://cp.literature.agilent.com/litweb/pdf/5988-8008EN.pdf)
Understanding Oscilloscope Frequency Response and Its Effect on Rise-Time Accuracy
Application Note 1420


Introduction

When you combine many circuit elements with similar frequency responses, you get a Gaussian response. Traditional analog oscilloscopes chain many analog amplifiers from the input to the cathode ray tube (CRT) display, and therefore exhibit a Gaussian response. The properties of a Gaussian-response oscilloscope are fairly well understood in the industry.

Less familiar, though, is the flat-response that is now more commonly exhibited by modern, high-bandwidth digital oscilloscopes. A digital oscilloscope has a shorter chain of analog amplifiers, and it can use digital signal processing techniques to optimize the response for accuracy. More importantly, a digital oscilloscope can be subject to sampling alias errors, which is not an issue with analog scopes. Compared to a Gaussian response, a flat response reduces sample alias errors, an important requirement in the design and operation of a digital oscilloscope.

This application note reviews the properties of both Gaussian- and flat-response oscilloscopes, then discusses rise-time accuracy for each response type. It shows that a flat-response oscilloscope gives more accurate rise-time measurements than a Gaussian-response oscilloscope of equal bandwidth, and how you can estimate the oscilloscope bandwidth you need.

This discussion refers to using a 1 GHz oscilloscope, but this analysis is scalable to other bandwidths with the same validity.

Properties of a Gaussian-Response Oscilloscope

Figure 1 depicts a typical Gaussian frequency response for a 1 GHz oscilloscope. A Gaussian-response offers good pulse response without overshoot, regardless of how fast the input signal is. Figure 2 shows the pulse response of a 1 GHz Gaussian-response oscilloscope to a fast step input.

In a Gaussian-response oscilloscope, the oscilloscope's rise time is related to the oscilloscope's bandwidth using
the familiar formula:

Rise time = 0.35/bandwidth

Another common property of Gaussian systems is that the overall system bandwidth of the oscilloscope and its probe is the inverse root mean square (RMS) value of their individual bandwidths. The system bandwidth can be calculated using the familiar relationship:

System bandwidth = 1/(1/BWprobe2 + 1/BWoscilloscope2)0.5

Often oscilloscope probes are designed to have sufficiently higher bandwidth than the oscilloscope bandwidth, so you do not need the above formula for derating the system bandwidth. Inversely, the measured rise time is commonly related to the system rise time and signal rise time using the formula:

Measured rise time = (RTsignal2 + RTsystem2)0.5

Sometimes this relationship is used to estimate the actual signal rise time when the oscilloscope's system rise time is not sufficiently faster than the signal's rise time to make an accurate measurement.

Properties of a Flat-Response Oscilloscope

Figure 1 compares a flat response to a Gaussian response. Note that the frequency response is much flatter below the –3 dB bandwidth, but then drops off very rapidly above the –3 dB bandwidth. This response shape is sometimes referred to as a maximally flat or brick wall response.

There are a couple of advantages to a flat-response. First, the frequency content of the signal below the –3 dB bandwidth is less attenuated, and thus measured more accurately. Secondly, the steeper roll helps reduce sampling alias errors in digital oscilloscopes (more on this later).

In the time domain, a flat response results in a pulse response with overshoot and ringing when the oscilloscope input is driven with a fast step input, as depicted in Figure 2. Such overshoot and ringing is often perceived as an undesirable effect in an oscilloscope. However, this ringing only occurs if the signal rise time is significantly faster than the oscilloscope can measure accurately, in which case you should use a higher-bandwidth oscilloscope.

Unlike Gaussian systems, the system bandwidth of a flat-response oscilloscope is not determined by the inverse RMS value of the sub-system parts. The commonly used bandwidth and rise-time formulas for Gaussian-response oscilloscope systems do not apply to flat-response oscilloscope systems! Instead, you should rely on the oscilloscope vendor to specify the system bandwidth of an oscilloscope/probe combination.

In the case of a flat-response oscilloscope, the rise time is related to the bandwidth, as described in the formula:

Rise time = N/bandwidth
(where N = 0.4 to 0.5)

The larger N is, the steeper the frequency response is, or the more it approaches the "brick wall" configuration shown in Figure 1. The above relationship will sometimes be included in an oscilloscope's specifications, which can give you an indication of what type of response the oscilloscope has...


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: GlassFET on May 06, 2014, 02:39:03 pm
...The commonly used bandwidth and rise-time formulas for Gaussian-response oscilloscope systems do not apply to flat-response oscilloscope systems! Instead, you should rely on the oscilloscope vendor to specify the system bandwidth of an oscilloscope/probe combination.

In the case of a flat-response oscilloscope, the rise time is related to the bandwidth, as described in the formula:

Rise time = N/bandwidth
(where N = 0.4 to 0.5)

The larger N is, the steeper the frequency response is, or the more it approaches the "brick wall" configuration shown in Figure 1. The above relationship will sometimes be included in an oscilloscope's specifications, which can give you an indication of what type of response the oscilloscope has...

Thanks AndersAnd for the further discussion on this topic. For these scopes, I think that a value of 0.4 to 0.5 should be a better approximation for the coefficient relating BW to rise time than the 0.35 value. Using the higher values with Circlotron's rise time pushes the estimated BW to over 300 MHz, as expected.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Boris on May 07, 2014, 01:27:43 am
Just applied it to my scope, works perfectly!! thank you very much!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Malama on May 12, 2014, 10:51:51 am
Oscilloscope Rigol Basic Model : DS2102 (non A version)
SW : 00.02.01.00.03
HW : 1.0.1.0.0

Hi All,

I install all options including 56M Memory and upgrade successively to 200, 300MHz.
I introduced Keys generated by Riglol1.03c. All have been accepted by the scope.

The scope is became DS2302 and operates fine (1 nS time base).

But, how to remove from the scope, one or all options, including Memory or frequency upgrade  ?

I try to use Rigol UltraSigma Sw, but UlraSigma does not recognize the scope, probably due to that DS2302 (non A version)
does not exist.

Is there a specific Key for options removal ?

Do you have an idea ?

Thank you,
JC
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on May 12, 2014, 10:53:56 am
Is there a specific Key for options removal ?

Last paragraph in first post here:
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/3105/ (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/3105/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Malama on May 12, 2014, 12:09:07 pm
I did not used any cable and windows SW to send the Keys to the scope.

Just written Keys directly in the scope generated from Riglol keygen with corresponding Code DSxx.

I search THE code DSxx to generate (via Riglol Keygen) a specific Key to be written in the scope which could be clear partly or all of the options.

Thanks,JC
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Malama on May 12, 2014, 08:00:10 pm
Hi,

Yes of course, I tried to use Ultra Sigma and USB cable connect at the rear of scope.

The scope is recognize by W7, not by Ultra Sigma, this is the problem.
Nothing in Rigol online devices, perhaps due to that DS2302 does not exist (vs DS2302A that exist) , I don't known ?

Impossible to issue SCPI command.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Malama on May 13, 2014, 07:48:52 am
Hi All,

Problem solved !
Just a value to be setup at scope level : in Utility / IO setting / USB Device => Computer instead of Pictbridge.

Ultra Sigma recognizes the scope as DS2302 and then Options removed without problem using corresponding SCPI command.

Thank you all !  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Zone1 on May 17, 2014, 03:54:52 am
Quote
5. When you are done enter the Option Code manually in the DS1000z using a single string without using any 'dash' (-) using Rigol's Procedure for activating the Trial Options in the D1000z.  As I recall the procedure is available on Rigol's Web Site under DS1000z.

I had some difficulty finding the procedures on Rigol's web site for a  DS1074Z can someone help? I could not find that specific model.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on May 17, 2014, 03:15:42 pm
Quote
5. When you are done enter the Option Code manually in the DS1000z using a single string without using any 'dash' (-) using Rigol's Procedure for activating the Trial Options in the D1000z.  As I recall the procedure is available on Rigol's Web Site under DS1000z.

I had some difficulty finding the procedures on Rigol's web site for a  DS1074Z can someone help? I could not find that specific model.

It's also been documented a lot in this thread. Two ways:

1. On-screen input, it's pretty self-explanitory.

2. SCPI with :SYStem:OPTion:INSTall <key-without-dashes>
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Zone1 on May 17, 2014, 10:13:51 pm
Quote
I had some difficulty finding the procedures on Rigol's web site for a  DS1074Z can someone help? I could not find that specific model.

It's also been documented a lot in this thread. Two ways:

1. On-screen input, it's pretty self-explanitory.

2. SCPI with :SYStem:OPTion:INSTall <key-without-dashes>
[/quote]

This is what I found for the On-screen process.   Is this everything?
There is much discussion about finding files, downgrading firmware, copying to usb, loading etc when it appears to be a  simple procedure of going to the riglol.3owl site getting a key and using the procedure below to enter 28 digits .  Am I missing something?

Quote
Now that you have your System information handy...
You'll need to know how to input the Unlock key, when the time comes.

Here is how you get to the menu to input the unlock key..

in your scope Press the "UTILITY" Button that is located at the top of the scope
Now.. Select the "OPTIONS" option by pressing the button to the right of the word "OPTIONS" (if you can't see "OPTIONS" find the very bottom blue arrow buttons and scroll down to get the option "OPTIONS")

at this stage you have the option to select "INSTALLED" (if you do, this will show you What options are Trial version and how much time is remaining on them.
this is the section that you want to come back to you , later, to confirm that the upgrade worked
FOR NOW
Select "SETUP"
NOW.. on this screen the top option will be called "EDITOR" if Editor is OFF (Switch it on, by Pressing the button to the right of EDITOR)

NOTE: if at any point the Menu Bar dissappears, You can make it re appear by Pressing the BLUE "MENU" Button at the top of all the other buttons on the right side of the screen

and just a quickie (if the menu thing gets annoying, you can set the time at which the menu will dissapear by  selecting..
"DISPLAY" Button at the top
"MENU DISPLAY"
Select the Amount of "S" (Seconds you wish) or "Infinite"

NOW, back to the point

Under Utility/Options/Setup

Use the "Intensity" Knob, that is located at the very top of the Scope, next to the Blue "MENU" button
turn it to select your character that you need to input
Push the knob in until you get a click, this will select your character

THIS IS THE AREA WHERE YOU INSERT YOUR UNLOCK KEY

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on May 17, 2014, 11:34:27 pm

I had some difficulty finding the procedures on Rigol's web site for a  DS1074Z can someone help? I could not find that specific model.

Zone1:   Please go to >  https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg425534/#msg425534 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg425534/#msg425534)

If you are still having trouble this should help you.  It is for the DS1074Z and will give you (Sorry - Not 200 MHz - my Error, corrected 5/19/2014) "100 MHz BW", etc., and should get you going.  If not please let me know.   Cheers, Ted
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: linux-works on May 18, 2014, 01:12:14 am
confirmed that the web-based unlock procedure works fine for the latest shipping (from tequipment.net) 1074z.

thanks to everyone's good work on this; its what pushed me into this specific model/brand purchase ;-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on May 18, 2014, 10:40:44 am

I had some difficulty finding the procedures on Rigol's web site for a  DS1074Z can someone help? I could not find that specific model.
Zone1:   Please go to >  https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg425534/#msg425534 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg425534/#msg425534)

If you are still having trouble this should help you.  It is for the DS1074Z and will give you 200 MHz BW, etc., and should get you going.  If not please let me know.   Cheers, Ted
200 MHz? Doesn't DS1000Z only support 70 and 100 MHz options?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on May 18, 2014, 10:51:16 am
5. When you are done enter the Option Code manually in the DS1000z using a single string without using any 'dash' (-) using Rigol's Procedure for activating the Trial Options in the D1000z.  As I recall the procedure is available on Rigol's Web Site under DS1000z.
I don't think it's available at Rigol's website.
But it's available at the North American distributor Rigol NA has documented the update procedure here:

Option license activation process for the DS1000Z, DS2000/A, DS4000, and DS6000 Oscilloscopes
Here are instructions for activating licenses for the DS1000Z, DS2000/A, DS4000, and DS6000 series of oscilloscopes.
http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-01c0/1/-/-/-/-/file.pdf (http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-01c0/1/-/-/-/-/file.pdf)

I think you should update your guide to include the link for this document.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Zone1 on May 18, 2014, 12:29:43 pm

I had some difficulty finding the procedures on Rigol's web site for a  DS1074Z can someone help? I could not find that specific model.

Zone1:   Please go to >  https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg425534/#msg425534 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg425534/#msg425534)

If you are still having trouble this should help you.  It is for the DS1074Z and will give you 200 MHz BW, etc., and should get you going.  If not please let me know.   Cheers, Ted


Keyed in code for DSER key and all options are official!   It now says Model DS1104Z instead of DS1074Z.   Yes procedure was easy and straight forward  :-+.  Thanks Again.  Haven't confirmed that I have 200MHz yet
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on May 18, 2014, 01:33:44 pm
Haven't confirmed that I have 200MHz yet

No, its not possible on a DS1104Z or DS1074Z model :-(
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: linux-works on May 18, 2014, 03:12:12 pm
sad to report, there is no new bandwidth in my 'upgrade'.  I did an informal test before the upgrade using a tektronix sg503 signal generator.  I started at 5mhz then went to 10, 25, 50, 100 and 250.   just a bit beyond the 50 point (low 60's) the signal started to attenuate and was no longer flat.  I'm not talking about 3db point, but the very first point where you can see the signal level drop as you increase freq.

the same basic point before the upgrade was there after the upgrade.  I did not see any increase in where that falloff point came.

the good news is that the signal was easily viewable at 100mhz and even up thru 250mhz (my siggen's max limit).  it was attenuated, sure, but very visible and clear (at least as a sine wave).

so, the decode features will unlock, but I'm not convinced any new speed exists with the unlock and its not really a different model number.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on May 18, 2014, 03:26:14 pm
but I'm not convinced any new speed exists with the unlock and its not really a different model number.
The model number changes from DS1074Z [70 MHz] to DS1104Z [100 MHz] with the upgrade.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Strada916 on May 18, 2014, 03:58:13 pm
Many thanks to the people that made this happen. Learning all the time. DS1074ZS to DS1104ZS.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: linux-works on May 18, 2014, 04:08:16 pm
yes, the model # changes but this does NOT make the scope work any faster.  the bw is still the same, from what I've seen.

I know my sig gen is flat to 250mhz and so doing a test at the 100mhz level is pretty trustworthy.  I just did not see any diff in cutoff from before and after the upgrade.  model # did change, no argument there, but it was a 70mhz scope before and its still a 70mhz scope, now.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Strada916 on May 18, 2014, 04:12:55 pm
yes, the model # changes but this does NOT make the scope work any faster.  the bw is still the same, from what I've seen.

I know my sig gen is flat to 250mhz and so doing a test at the 100mhz level is pretty trustworthy.  I just did not see any diff in cutoff from before and after the upgrade.  model # did change, no argument there, but it was a 70mhz scope before and its still a 70mhz scope, now.

Thanks. I was more after the other options anyways. But thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: linux-works on May 18, 2014, 04:15:05 pm
same here.  I bought the 4ch scope for its proto decode, storage and views.  70 to 100mhz means nothing, especially since I was able to see waveforms at 250mhz very easily.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on May 18, 2014, 04:49:13 pm
I have an original DS1104Z, and the B/W is about 125MHz (-3dB). The build in hardware counter works OK till 110Mhz, if you go higher it gives unreliable results.

Perhaps RIGOL has done some other limiting to prevent B/W upgrades on the 70MHz model.....

I still think this is an amazing piece of test gear for the money....especially if you add the triggers, decoding and memory options :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: linux-works on May 18, 2014, 04:53:35 pm
I did notice the built in counter stopped being reliable at 100mhz or just a bit above that, maybe 110.  it certainly did not count much above that range.

the waves did show up (I did not have square or triable, only sine) well beyond the 100mhz point.

and again, I was not talking about the 3db point, I was referring to a visual drop-off as you slowly bring the freq up and watch for vertical deflection changes.  this will be well below the '3db point' but I wanted to see where any falloff starts to happen.  it was the same point on the pre-mod and post-mod scope.

I'll see if 125mhz ends up being about 3db down.  it may very well be; but if so, then it probably was that way before the mod, as well.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on May 18, 2014, 06:14:01 pm
I did notice the built in counter stopped being reliable at 100mhz or just a bit above that, maybe 110.  it certainly did not count much above that range.

the waves did show up (I did not have square or triable, only sine) well beyond the 100mhz point.

and again, I was not talking about the 3db point, I was referring to a visual drop-off as you slowly bring the freq up and watch for vertical deflection changes.  this will be well below the '3db point' but I wanted to see where any falloff starts to happen.  it was the same point on the pre-mod and post-mod scope.

I'll see if 125mhz ends up being about 3db down.  it may very well be; but if so, then it probably was that way before the mod, as well.

As mentioned many times before in regards to the DS2000 series (and is likely applicable to DS1000Z series as well - unless it's not using the same LMH6518 gain amp), there very well could be ZERO difference between the 70 and 100MHz models (aside from the model number, marketing, and price). There is no 70MHz BW cutoff possible with the LMH6518 chip - only 20, 100, 200, etc...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: linux-works on May 18, 2014, 06:23:16 pm
200+ pages of topic, sorry, can't keep up ;)

are you saying that a stock, out of the box 70mhz scope and the 100mhz version are going to test the same at the falloff point and/or 3db points?

(1000z series; I don't have the 2000 and that's a totally different scope anyway).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on May 18, 2014, 06:25:22 pm
are you saying that a stock, out of the box 70mhz scope and the 100mhz version are going to test the same at the falloff point and/or 3db points?

(1000z series; I don't have the 2000 and that's a totally different scope anyway).

That's my guess, based on what Rigol did with the DS2000. But I don't have one, so I can't test it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Wim13 on May 18, 2014, 06:53:44 pm
I have an original DS1104Z, and the B/W is about 125MHz (-3dB). The build in hardware counter works OK till 110Mhz, if you go higher it gives unreliable results.

Perhaps RIGOL has done some other limiting to prevent B/W upgrades on the 70MHz model.....

I still think this is an amazing piece of test gear for the money....especially if you add the triggers, decoding and memory options :)

I measured an upgraded 1074 ( with Marconi sig.gen. 2019a, level -20 dBm)

 10 Mhz  0 db
 70 Mhz -1.1
 80 Mhz -1.5
 90 Mhz -1.7
100 Mhz -2.0
110 Mhz -2.4
120 Mhz -2.7 counter still working
130 Mhz -3.0 counter not working
160 Mhz -4.0
200 Mhz -5.4

300 Mhz -10 dB
400 Mhz -16 dB

So thats well within specs for a 100 Mhz DSO. no complains.
And seems to be the same as Orange measured on his 1104
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: linux-works on May 18, 2014, 07:08:09 pm
did you do the same test before the upgrade?

can the scope be reverted and then put back again, for a/b testing?

I should have done measurements before I did the upgrade.  damn.  sorry, just didn't think it would be new info so I only visually looked at things before and after rather than writing down actual 3db levels.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Wim13 on May 18, 2014, 07:13:13 pm
Yes , you can uninstall the options, ( via SCPI) and

No , i dont have measured data before upgrade, will see next week if i can get any.

The counter has an other bug, put the DS1000 on AC trigger, and the counter wont work after >50 Mhz..!?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: seronday on May 19, 2014, 12:35:06 am
The Frequency Response plot for un-modified DS1074Z is here.
https://www.eevblog.com/forum/testgear/rigol-ds1074z-inside-picture/msg337710/#msg337710 (https://www.eevblog.com/forum/testgear/rigol-ds1074z-inside-picture/msg337710/#msg337710)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Wim13 on May 19, 2014, 05:17:35 pm
The Frequency Response plot for un-modified DS1074Z is here.
https://www.eevblog.com/forum/testgear/rigol-ds1074z-inside-picture/msg337710/#msg337710 (https://www.eevblog.com/forum/testgear/rigol-ds1074z-inside-picture/msg337710/#msg337710)

That makes the 1104,  + 1 dB better over the whole range.
It is good to see that this + 1 dB is on all measured points for the 1104 compared to the chart mentioned.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mrflibble on May 19, 2014, 06:41:12 pm
That makes the 1104,  + 1 dB better over the whole range.
It is good to see that this + 1 dB is on all measured points for the 1104 compared to the chart mentioned.
Indeed. Same difference on all points makes it much easier to root out systematic error. ;D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on May 19, 2014, 06:52:38 pm
DS1074Z = 90 MHz
DS1104Z = 125MHz

So that means that the myth around the '70MHz / 100MHz scopes are a marketing thing' is busted for the DS1000Z series.

I can tell you also that the DS2000 70 MHz and 100MHz scopes are different, I know this from my own measurements, I have both.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on May 19, 2014, 06:57:55 pm
I can tell you also that the DS2000 70 MHz and 100MHz scopes are different, I know this from my own measurements, I have both.

The 'idea' that the 70MHz DS2000 can do up to at least 100MHz <= 3dB is based on a number of other owners' measurements that were actually posted on this blog.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on May 20, 2014, 06:42:05 am
I can tell you also that the DS2000 70 MHz and 100MHz scopes are different, I know this from my own measurements, I have both.

The 'idea' that the 70MHz DS2000 can do up to at least 100MHz <= 3dB is based on a number of other owners' measurements that were actually posted on this blog.
Yes for sure I agree with you, but the suspicion that a DS2072 is the same as a DS2102 with simply a other sticker on the front is not true.
The DS2102 does out of the box about 150MHz, not so with an stock DS2072.........

I have not tested the A series.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Wim13 on May 20, 2014, 07:59:15 pm

The chip they use has only switches for 20 -100 -200 -350 Mhz etc..

so there is no entry for 70 Mhz, what they do is playing with the gain a little. The differences are small.
You can see that when u do a measurment with a signal generator with a compensating head.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: SiC on May 22, 2014, 12:51:44 pm
Just pumped the generated serial numbers from riglol into my brand new DS1074z - running on software version 00.04.00. They worked perfectly! I also tried uninstalling the keys using the SCPI interface and that works fine too - useful to know in case my 'scope ever needs to go back for repair.

Thanks guys for all the work on this and making it so incredibly easy.   :)
Also thanks Rigol for having a poor key implementation...! ;D

Si.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: SiC on May 22, 2014, 12:53:42 pm
I'll also add that I appear to have the latest version firmware on here. I did read that the 500uV option is buggy. In what way is it buggy?
On mine, the lowest 500uV setting, I get no trace shown at all.

Si.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: max666 on May 22, 2014, 02:31:24 pm
I'll also add that I appear to have the latest version firmware on here. I did read that the 500uV option is buggy. In what way is it buggy?
On mine, the lowest 500uV setting, I get no trace shown at all.

Si.

The offset is way off on the 500uV range, +10mV on mine. But if you don't mind scrolling it down ...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on May 22, 2014, 05:15:47 pm
and self-cal doesn't calibrate it, so it can't really be trusted at all, that kind of thing.  also, enabling it seems to cause other issues in the scope.

500uV is to be avoided on the DS1000Z scopes at this time.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: skytron on May 26, 2014, 10:37:12 pm
Just received a new DS2072A-S with the AWG option installed.

 My question to the experts is:   Can I use the same firmware and upgrade procedure to upgrade this scope?   Has anyone done it?   

 :)
   I'm amazed and impressed with all the hard work done by some very smart people in creating so much value for us.

Thanks All.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tsmith35 on May 27, 2014, 01:27:45 am
Just received a new DS2072A-S with the AWG option installed.
My question to the experts is:   Can I use the same firmware and upgrade procedure to upgrade this scope?   Has anyone done it?

This may help: https://www.google.com/search?q=%22Sniffing+the+Rigol%27s+internal+I2C+bus%22+%22ds2072a-s%22 (https://www.google.com/search?q=%22Sniffing+the+Rigol%27s+internal+I2C+bus%22+%22ds2072a-s%22)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: skytron on May 27, 2014, 11:05:38 pm
Thanks everyone.  Found the information.  Did the upgrade and update.  So far everything works. 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dr.diesel on May 28, 2014, 05:19:06 pm
New FW for the 815 just popped up:

DSA815 FW-Version: 00.01.09

I've requested it, but will probably be ignored as usual.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Wall-E on May 30, 2014, 03:47:45 pm
DSA815 FW 00.01.09 link is available here:  https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg453781/#msg453781 (https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg453781/#msg453781)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ErikI on June 02, 2014, 12:31:01 pm
Received my new DS1104Z-S (FW 00.04.00) and i can confirm that generated unlock codes work on this scope also.  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on June 03, 2014, 01:16:41 am
Received my new DS1104Z-S (FW 00.04.00) and i can confirm that generated unlock codes work on this scope also.  :-+

Does anyone know what's fixed/changed in this version?

Can you post a change log or the release notes or something?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alexwhittemore on June 03, 2014, 03:43:15 am
Received my new DS1104Z-S (FW 00.04.00) and i can confirm that generated unlock codes work on this scope also.  :-+

Does anyone know what's fixed/changed in this version?

Can you post a change log or the release notes or something?

Rigol doesn't keep a change log. Or a version history. Or even a single download link where you can find *any version of the firmware at all*

Yes, I understand the principle that new firmware doesn't add new features and "if it ain't broke for you, don't fix it." Except that it's constantly broken.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on June 03, 2014, 06:27:22 am
Well, when I asked for firmware update through my distributor, I got docs and full version history..

Did you even try to do that?, or just guessing?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alexwhittemore on June 03, 2014, 06:32:18 am
I don't have a distributor, I won the scope straight from rigol. Whenever I want a firmware update, I report a bug and they send a binary. I asked for a change log and they said 'I have no idea, sorry."
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on June 03, 2014, 06:34:54 am
If you are talking to them directly, try to find Chen Rui, he is the author of it.  (For the ds2000/a)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alexwhittemore on June 03, 2014, 06:39:04 am
Ahh, maybe that's the problem. The ds2000 DOES have a defined firmware download page, though you have to submit a request. The ds1000z isn't in that system yet (however that works).

I'll try asking by name next time though to see if he isn't a dedicated ds2000 firmware team member.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sotos on June 03, 2014, 04:24:29 pm
Isn't this much easier? For a DS2202A owner. As he says it’s fully automated.

https://www.eevblog.com/forum/testgear/ds2000a-upgrade-utility/ (https://www.eevblog.com/forum/testgear/ds2000a-upgrade-utility/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on June 03, 2014, 07:34:13 pm
Well, when I asked for firmware update through my distributor, I got docs and full version history..

Did you even try to do that?, or just guessing?

I don't suppose you've tested if this firmware can save waveforms from memory to USB drive?

I'm trying to save a long waveform that I'm viewing via dual time base to disk and it'll only save what's on the screen.   :--  I get "Not Support" when trying to save the memory, rather than the option simply being unavailable.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on June 03, 2014, 07:42:52 pm
Well, when I asked for firmware update through my distributor, I got docs and full version history..

Did you even try to do that?, or just guessing?

I don't suppose you've tested if this firmware can save waveforms from memory to USB drive?

I'm trying to save a long waveform that I'm viewing via dual time base to disk and it'll only save what's on the screen.   :--  I get "Not Support" when trying to save the memory, rather than the option simply being unavailable.

I havent even found out how to record.. :) n00b...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: uski on June 04, 2014, 09:01:39 pm
I just received my DP832. But they shipped it with the new firmware 00.01.09.00.01 there doesn’t support downgrade. So the key generator doesn’t work.

I'm in the same boat. Got a DP832 today.
I'd like to at least get the Accuracy option... if anyone has any clue...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on June 05, 2014, 01:19:59 am
When someone with know-how obtains a DP832, they'll do what they can.  Maybe they'll figure it out, maybe they won't.

In the meantime, you have exactly what you paid for.  If that is not what you wanted to hear, I'm sorry.  Wait, and someone will get to it when they're motivated to.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: GlassFET on June 05, 2014, 12:44:54 pm
Have any of you hacked-DS2000A owners loaded the latest firmware version 00.03.00.01.03 with success? By success I mean verified that the hacked options remain installed? I want to make sure Rigol didn't figure out some way to nullify hacks. I know, I know - the FW upgrades should not impact installed options, but I want to be sure before pulling that trigger. Thanks.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: navzptc on June 05, 2014, 01:15:47 pm
No problems here - Loaded the new firmware and all options still available  :)

Just waiting a while to see if 300MHz is available when demo options run out!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: GlassFET on June 05, 2014, 01:27:17 pm
No problems here - Loaded the new firmware and all options still available  :)

Just waiting a while to see if 300MHz is available when demo options run out!

Thanks for the info. I'm not sure why you're waiting for the 300MHz. That upgrade worked fine for five of us with the DS2000A scopes.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: navzptc on June 05, 2014, 11:23:00 pm

Thanks for the info. I'm not sure why you're waiting for the 300MHz. That upgrade worked fine for five of us with the DS2000A scopes.

It just doesn't want to accept the code at the moment - All options works ok, but trying to get 300MHz and options always says 'Licence Unavailable'.

Have seen somewhere that it maybe related to trial options still being available - Time will tell!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: GlassFET on June 05, 2014, 11:52:56 pm

It just doesn't want to accept the code at the moment - All options works ok, but trying to get 300MHz and options always says 'Licence Unavailable'.

Have seen somewhere that it maybe related to trial options still being available - Time will tell!

Huh. All five of our scopes were upgraded when they were essentially new, with maybe 90% of the trial hours on the options still remaining. I can't understand why you're having that problem.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AintBigAintClever on June 06, 2014, 10:29:06 am
My A-S did the same, so I gave up and switched to the modified 2.x "non-A keys" firmware. All opened up and 300MHz. Not got round to having another go yet.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: navzptc on June 07, 2014, 12:46:32 pm
Might be worth starting a new thread with those of us having this problem to see of it is a board revision problem etc seeing as many have achieved the desired result.
Also handy if those who have got 300MHz post their versions.

Sent from my HTC One using Tapatalk

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on June 08, 2014, 11:38:14 am
Well, when I asked for firmware update through my distributor, I got docs and full version history..

Did you even try to do that?, or just guessing?
I don't suppose you've tested if this firmware can save waveforms from memory to USB drive?

I'm trying to save a long waveform that I'm viewing via dual time base to disk and it'll only save what's on the screen.   :--  I get "Not Support" when trying to save the memory, rather than the option simply being unavailable.
Off topic.
Please discuss firmware changes and bugs in this topic instead: https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684 (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684)
Marmad already keeps track of all DS2000 series bugs in that topic.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sacherjj on June 09, 2014, 09:34:16 pm
When someone with know-how obtains a DP832, they'll do what they can.  Maybe they'll figure it out, maybe they won't.

In the meantime, you have exactly what you paid for.  If that is not what you wanted to hear, I'm sorry.  Wait, and someone will get to it when they're motivated to.

Yep, that is true.  I was hoping all options would come with trials.  I wanted to play with the trigger options to see if it was worth the money.  I can understand not having Accuracy and RS-232 and LAN enabled.  Those could make a user upset if it expired and he wondered why accuracy dropped.  Still a great value for the money.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alexwhittemore on June 09, 2014, 10:44:15 pm
Do they not come with trials? I know on the DS1104z they all came with trials.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sacherjj on June 09, 2014, 11:39:23 pm
Do they not come with trials? I know on the DS1104z they all came with trials.

Only 2 of the 5 options have trials on my DP832.  Monitor and Analyze, I think they were.  Ethernet, RS-232, Digital IO had no trial.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: nack on June 10, 2014, 09:48:18 am
Mine came with all the trail options available. Strange...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: johnlondon on June 12, 2014, 07:18:35 am
I have a brand new DS2072A with software 00.03.00.SP1 and I have generated the key but the DSO reports "licence is unavailable".  Am I right in thinking that the private key that I need to use in rikey.c is the one that is listed here: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/585/ (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/585/)?  Or do I have to enter a different private key?

Is there a way of checking that the tool used to generate the key is doing it correctly, for example by entering a different serial number and comparing it to a known good licence key?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AintBigAintClever on June 12, 2014, 08:04:44 am
I have a brand new DS2072A with software 00.03.00.SP1 and I have generated the key but the DSO reports "licence is unavailable".  Am I right in thinking that the private key that I need to use in rikey.c is the one that is listed here: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/585/ (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/585/)?  Or do I have to enter a different private key?

Is there a way of checking that the tool used to generate the key is doing it correctly, for example by entering a different serial number and comparing it to a known good licence key?
Aren't those instructions for the DS2072? For the DS2072A the instructions are different as the private key is now unique to each scope. Everything you need can be found at http://www.gotroot.ca/rigol/ (http://www.gotroot.ca/rigol/), including instructions.

Basically you've got a choice of:-
1) Flash firmware with a key dump firmware, dump key, generate code, apply code, upgrade to latest firmware.
2) Flash firmware with a "non-A keys" firmware, generate code at http://www.gotroot.ca/rigol/riglol/ (http://www.gotroot.ca/rigol/riglol/), apply code, stay on modified firmware.

If you only have partial success with option 1 (e.g. open up options but stuck at 70MHz) option 2 is a good fallback and is what I did.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on June 12, 2014, 08:56:10 am
I have a brand new DS2072A with software 00.03.00.SP1 and I have generated the key but the DSO reports "licence is unavailable".  Am I right in thinking that the private key that I need to use in rikey.c is the one that is listed here: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/585/ (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/585/)?  Or do I have to enter a different private key?

Is there a way of checking that the tool used to generate the key is doing it correctly, for example by entering a different serial number and comparing it to a known good licence key?
For the DS2000A series just use this DS2000A Upgrade Utility: https://www.eevblog.com/forum/testgear/ds2000a-upgrade-utility/ (https://www.eevblog.com/forum/testgear/ds2000a-upgrade-utility/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: willie on June 12, 2014, 06:12:09 pm
REF # 3337 GLASSFET ----- "Have any of you hacked-DS2000A owners loaded the latest firmware version 00.03.00.01.03 with success? By success I mean verified that the hacked options remain installed? I want to make sure Rigol didn't figure out some way to nullify hacks. I know, I know - the FW upgrades should not impact installed options, but I want to be sure before pulling that trigger. Thanks."

Has anyone updated their firmware on the DS-2000A  that contains the " special " firmware that allowed information to be obtained and create the update codes ?
That process went well , but still running that initial FW , and since 00.03.00.01.03 has been out for at least a month , can you update and still retain all of your BW and options ? ??

 O0
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on June 12, 2014, 06:50:43 pm
I loaded the original untouched firmware after I hacked it, not installed the 03 since I haven't downloaded it yet.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: daemonix on June 12, 2014, 07:14:31 pm
Just pumped the generated serial numbers from riglol into my brand new DS1074z - running on software version 00.04.00. They worked perfectly! I also tried uninstalling the keys using the SCPI interface and that works fine too - useful to know in case my 'scope ever needs to go back for repair.

Thanks guys for all the work on this and making it so incredibly easy.   :)
Also thanks Rigol for having a poor key implementation...! ;D

Si.

I got the 1074z around 15th of april in the UK and I seem to have a very old firmware...

00.02.03.sp5

Any major things Im missing?

It seems that the UK distributor doesn't allow firmware updates or something?! I remember reading something on a paper...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: max666 on June 12, 2014, 09:30:15 pm
I got the 1074z around 15th of april in the UK and I seem to have a very old firmware...

00.02.03.sp5

Any major things Im missing?

It seems that the UK distributor doesn't allow firmware updates or something?! I remember reading something on a paper...

I got my 1074Z on 28.03.2014 and it has firmware version 00.02.01.sp1  ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Codemonkey on June 13, 2014, 01:35:51 pm
I just got a 1104z today, mine also has 00.02.01.sp1
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: daemonix on June 13, 2014, 07:24:01 pm
I just got a 1104z today, mine also has 00.02.01.sp1

From rigol-uk.co..? Did (Will) you call them about updating?

Sound really random.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Codemonkey on June 13, 2014, 07:35:58 pm
no, I got mine from www.rigoloscilloscope.co.uk (http://www.rigoloscilloscope.co.uk). Seems to be some Chinese importer with UK stock. Ordered Sunday and arrived Friday so I'm happy enough!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: daemonix on June 15, 2014, 08:40:05 am
So how many version exist after these? (04.00 is the latest?)
Change logs?

Thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Codemonkey on June 15, 2014, 11:29:47 am
Scope is now running 00.04.00  :) I used the request form on the Rigol website (link in this thread somewhere!). It doesn't list the DS1000Z under the checkbox list, but the text field at the bottom asks for model number and serial number so they can work it out from that. I then received an email with links to download the 2 images. Not really sure what the differences are from the previous version, but I do see more measurement options on the left hand menu.

The instructions stated that it was necessary to first install the bootloader update image, then without rebooting, install the other image. All went well.

No changelog or anything though.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Suffer1981de on June 15, 2014, 08:24:18 pm
Hi Codemonkey,

can you check if the key generator is still working with that version?

Greetings
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Codemonkey on June 16, 2014, 06:22:07 am
I used the DSER key while the scope was still on the older firmware, then after the update to 00.40.00 the options were still showing as official installed. There is a posting from someone else in this thread that the key gen worked for them on a scope they bought new already running 00.40.00.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: TomThomas on June 16, 2014, 07:53:38 am
no, I got mine from www.rigoloscilloscope.co.uk (http://www.rigoloscilloscope.co.uk). Seems to be some Chinese importer with UK stock. Ordered Sunday and arrived Friday so I'm happy enough!

Hi
I didn't find this seller on any Rigol page... seems it is no official Rigol reseller?

Hope this guy offer a good support if needed. Did you at least save some Money?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Codemonkey on June 16, 2014, 08:15:38 am
Rigol uk price £584, I paid £449 so yes, I saved quite a bit. I bought my previous scope (Rigol DS1052E) from deal extreme, not exactly an official Rigol sales channel but cheaper than the uk sellers at the time. Didn't have any problems with that either.

(PS) Thanks to all involved with the RigLol thing, it was the deciding factor on taking the plunge and buying my 2nd Rigol product.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: seronday on June 16, 2014, 11:08:02 pm
Codemonkey,
          Would it be possible for you to make this new firmware version available to other forum members ?
Not everyone gets the same speedy service from Rigol  for firmware updates.

Thanks.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: johnlondon on June 17, 2014, 09:58:15 am
Thanks for the updates re upgrading a DS2072A.  I've tried uploading the replacement hardware but it doesn't seem to have worked.  Worse still, the DSO just loads the RIGOL screen on start and doesn't boot (you don't get the squares/progress bar thingy under the logo).  Is there a way of cleaning up the reboot?  I've tried pressing the 6th button down on the LHS, but perhaps I'm not doing it in the right sequence.  Is there a way to sort this out please?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Codemonkey on June 17, 2014, 10:20:28 am
Codemonkey,
          Would it be possible for you to make this new firmware version available to other forum members ?
Not everyone gets the same speedy service from Rigol  for firmware updates.

Thanks.

I'd rather not share the binaries themselves, but I don't see why I can't pass on the links they sent me to download them:

The following instructions apply, don't hold me responsible if you brick your scope etc etc...

Quote
Links to download the two update files (Bootloader and Firmware update) -> 00.04.00
Be aware that after finishing the update no downgrading is possible.
 
Start with the Bootloader File and follow the instructions. After successfully finishing the bootloader update
do NOT reboot as instructed. Instead, continue with the Firmware update file.
 
Bootloader Update:
https://www.dropbox.com/s/gzhiccqh2jxsdxh/DS1000Z%28Boot%29update.rar (https://www.dropbox.com/s/gzhiccqh2jxsdxh/DS1000Z%28Boot%29update.rar)
 
Firmware Update:
https://www.dropbox.com/s/6fr922u440drfre/DS1000Z%28ARM%29update.rar (https://www.dropbox.com/s/6fr922u440drfre/DS1000Z%28ARM%29update.rar)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: seronday on June 17, 2014, 11:01:41 am
Thanks Codemonkey.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: johnlondon on June 17, 2014, 12:59:09 pm
Fixed the issue with the bricked DS2072A.  It involved reflashing it with the latest firmware (from this site), then attempting it again.  All good now.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: max666 on June 17, 2014, 01:24:58 pm
Firmware update worked like a charm.

Thank you very much, Codemonkey!  (http://i.imgur.com/X1w2UKp.gif)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: andrewwong2000 on June 17, 2014, 02:33:05 pm
Bought a DS1074Z-S and just upgraded to v4 with all the fruit.

Thanks to all for my excuse head back to the lab : )
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Fred27 on June 17, 2014, 03:03:55 pm
Thanks for sharing the firmware link, Codemonkey. I've no idea why they don't just make this easily downloadable.

When you said they asked for your serial number I wondered whether the firmware would have to be compiled/configured for each individual scope. (Yes - that would be a daft way of doing it, but not implausible. I assume that max's and andrewwong200's scopes doesn't now have your serial number showing on screen.)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on June 17, 2014, 03:10:52 pm
They just verify that you actually have a scope.  The firmware is not coded to a particular serial number, just the model.

The links each show a page saying the files have been hosted there for 2 months.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: thn788 on June 19, 2014, 09:37:43 am
For previous updates of DS1000Z firmwares I have been in e-mail contact with both my dealer and some actual Rigol-FAE (both located in Germany) and I asked both, why they provide new firmware only on request and why they need serial numbers for this. Both independently told me, they had problems with firmware updates not working properly on certain serial-number ranges.

Maybe they have different HW-revision "in the field" and some need special firmware or special update procedures?!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mauroh on June 19, 2014, 12:20:25 pm
Maybe they have different HW-revision "in the field" and some need special firmware or special update procedures?!

This is interesting, and could be possible, since i just got my 00.04.00 from Rigol official tech support and it not include the bootloader upgrade.

I did the upgrade and so far my enhanced features are still there.

This is the change log i received from Rigol:


Following is the issue fixed in new version 00.04.00.


      |  Switch the video standard, synchronized automatically                               |  M   
      |  changes all the lines, the trigger status error.                                            |     
------+---------------------------------------------------------------+-----
      |  When you open LA's D8-D15 channel, CH4 pattern can not be  configured.  |  M   
------+---------------------------------------------------------------+-----
      |  The waveform is wrong when the trigger type have two or more      |  M   
      |  trigger signal source.                                                                  |     
------+---------------------------------------------------------------+-----
      |  You can also continue to increase the limit REF channel      |  M   
      |  offset when prompt appears.                                  |     
------+---------------------------------------------------------------+-----
      |  When the LA probe Calibration finish, it should have prompt  |  M   
      |  an operation of next step.                                   |     
------+---------------------------------------------------------------+-----
      |  The LA pop-ups error message prompt when first opening the   |  M   
      |  LA after oscilloscope start.                                 |     
------+---------------------------------------------------------------+-----
      |  The LA time delay didn't work well when restoring factory    |  M   
      |  setting.                                                     |     
------+---------------------------------------------------------------+-----
      |  After the read channel arbitrary waveform switching to a     |  M   
      |  sinusoidal waveform, the amplitude of the first modification |     
      |  is invalid.                                                  |     
------+---------------------------------------------------------------+-----
      |   Sawtooth regulate slow response.                            |  M   
------+---------------------------------------------------------------+-----
      |  Add the remote command of read waveform data of the Logic    |  E   
      |  channel.                                                     |     
------+---------------------------------------------------------------+-----
      |  Add the remote command of measure of "MATH" function.        |  E   
------+---------------------------------------------------------------+-----
      |  Fixed unrecongnizable code bug in text box of update         |  M   
       |  function while the system language is traditioal Chinese.    |     
------+---------------------------------------------------------------+-----
      |  In scan mode and ZOOM on, switch trigger mode cause system   |  M   
      |  crash.                                                       |     
------+---------------------------------------------------------------+-----
      |  There is no help info of Horizontal offset key.              |  M   




Title: Re: Sniffing the Rigol's internal I2C bus
Post by: daemonix on June 19, 2014, 03:21:22 pm
Anyone with a 1074z can confirm that the PNG screenshot have weird dates? 31 Dec 1979 23:03?? LOL
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sfiber on June 19, 2014, 03:29:05 pm
I bought ds1074z and it came with version 04 and key generation work perfect.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Turtle9er on June 19, 2014, 04:24:18 pm
Just tried to get the new firmware, and says files are gone....guess Rigol didn't like ppl just downloading it. Anybody out there willing to share the files?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: max666 on June 19, 2014, 04:24:32 pm
Anyone with a 1074z can confirm that the PNG screenshot have weird dates? 31 Dec 1979 23:03?? LOL

Yes the dates are weird, but that doesn't surprise me, because I think the DS1000Z don't have any clock chip at all. ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: max666 on June 19, 2014, 05:01:34 pm
Just tried to get the new firmware, and says files are gone....guess Rigol didn't like ppl just downloading it. Anybody out there willing to share the files?

Like Codemonkey said: "The following instructions apply, don't hold me responsible if you brick your scope etc etc..."
Quote
Links to download the two update files (Bootloader and Firmware update) -> 00.04.00
Be aware that after finishing the update no downgrading is possible.
 
Start with the Bootloader File and follow the instructions. After successfully finishing the bootloader update
do NOT reboot as instructed. Instead, continue with the Firmware update file.
 
Bootloader Update (new link):
https://www.dropbox.com/s/nteyndjz17dmcmi/DS1000Z%28Boot%29update.rar (https://www.dropbox.com/s/nteyndjz17dmcmi/DS1000Z%28Boot%29update.rar)
 
Firmware Update (new link):
https://www.dropbox.com/s/w9x66ghdhagtsaj/DS1000Z%28ARM%29update.rar (https://www.dropbox.com/s/w9x66ghdhagtsaj/DS1000Z%28ARM%29update.rar)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Wall-E on June 19, 2014, 05:03:15 pm
Anyone with a 1074z can confirm that the PNG screenshot have weird dates? 31 Dec 1979 23:03?? LOL

Yes the dates are weird, but that doesn't surprise me, because I think the DS1000Z don't have any clock chip at all. ;)
No, this date format is NOT weird at all, it is one of the standard date formats.  And the the DS1000z does NOT have a RTC (Real Time Clock) chip.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Turtle9er on June 19, 2014, 07:32:32 pm
Max666....thanks for that. I just update my 1074z-s and all is good. Not sure if people had this issue with the old firmware, but some times my trigger waveforms would not show up, even though it would say triggered....a quick test shows that this is now fixed....so very happy about that. Thanks again.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: max666 on June 19, 2014, 07:50:36 pm
No, this date format is NOT weird at all, it is one of the standard date formats.  And the the DS1000z does have a RTC (Real Time Clock) chip.

Fair enough! So where can I see the system time, where can I set it? huh? huh?   :-//
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: donkey77 on June 20, 2014, 07:52:24 am
Hi,

After following this thread I was about to buy a DS2072A but came across a MSO2072A-S that looked interesting. Does anyone have any knowledge of these, it seems they are quite new. Hopefully the previous upgrades would work for these but I am reluctant to take the plunge without confirmation.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AintBigAintClever on June 20, 2014, 01:39:13 pm
Some people have unlocked DS2072A (and A-S) successfully, but a handful had issues. I've got a recent DS2072A-S that's still on the 2.x "non A keys" firmware as I was able to unlock features but not unlock the bandwidth.

If an MSO does the same then I doubt it would be able to revert to 2.x firmware without either losing all the MSO features or bricking, as someone recently mentioned that MSO support was added in 3.x.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: navzptc on June 20, 2014, 02:40:14 pm
I think that maybe Rigol is restricting the updateability of their units which have just been built, even though the firmware version maybe the same as earlier units.

I could update my DS2202A with  'All Options', but not the 300Mhz bandwidth; also with my recent DG4102 - I could expand it to 160Mhz but not to 200Mhz that a lot of people have  :(

Make the most of what we can achieve now - I feel it will get more difficult in time!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: f1rmb on June 20, 2014, 02:49:39 pm
Hi,

I think that maybe Rigol is restricting the updateability of their units which have just been built, even though the firmware version maybe the same as earlier units.

I could update my DS2202A with  'All Options', but not the 300Mhz bandwidth; also with my recent DG4102 - I could expand it to 160Mhz but not to 200Mhz that a lot of people have  :(

Make the most of what we can achieve now - I feel it will get more difficult in time!

Yesterday I received my DS2072A, and I didn't experienced any problems while "updating". Now I have a full featured, plus 300MHz.

BTW, many thanks to everyone involved in this hack, at any level (also thumbs up to reviewers, that was helpful to make my choice between all available "low cost" DSOs).


Cheers.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Purevector on June 21, 2014, 03:20:57 pm
I think that maybe Rigol is restricting the updateability of their units which have just been built, even though the firmware version maybe the same as earlier units.

I could update my DS2202A with  'All Options', but not the 300Mhz bandwidth; also with my recent DG4102 - I could expand it to 160Mhz but not to 200Mhz that a lot of people have  :(

Make the most of what we can achieve now - I feel it will get more difficult in time!

This is possible.  I just got a new DS2072A from TEquipment from their newest shipment from China.  Using the very easy-to-use Upgrade Utility I was able to unlock all option and 200MHz bandwidth, but not 300MHz.  This is not an user error issue.  Something is certainly going on here.  Maybe some models have been flagged somehow that their front end is not capable of 300MHz (components not to spec)?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 21, 2014, 03:41:50 pm
I think that maybe Rigol is restricting the updateability of their units which have just been built, even though the firmware version maybe the same as earlier units.

I could update my DS2202A with  'All Options', but not the 300Mhz bandwidth; also with my recent DG4102 - I could expand it to 160Mhz but not to 200Mhz that a lot of people have  :(

Make the most of what we can achieve now - I feel it will get more difficult in time!

This is possible.  I just got a new DS2072A from TEquipment from their newest shipment from China.  Using the very easy-to-use Upgrade Utility I was able to unlock all option and 200MHz bandwidth, but not 300MHz.  This is not an user error issue.  Something is certainly going on here.  Maybe some models have been flagged somehow that their front end is not capable of 300MHz (components not to spec)?

I'm not sure how they would accomplish this unless the firmware was changed. Which version are you each using - v.2 or v.3?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Purevector on June 21, 2014, 03:49:34 pm
I'm not sure how they would accomplish this unless the firmware was changed. Which version are you each using - v.2 or v.3?

My unit came with 2.0.1.  Used the utility to upload hacked firmware to grab keys and update.  300MHz did not work, but 200 did.  Upgraded to 3.0.1 and tried again, same result (of course using key dump from hacked firmware).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 21, 2014, 04:03:15 pm
I'm not sure how they would accomplish this unless the firmware was changed. Which version are you each using - v.2 or v.3?

My unit came with 2.0.1.  Used the utility to upload hacked firmware to grab keys and update.  300MHz did not work, but 200 did.  Upgraded to 3.0.1 and tried again, same result (of course using key dump from hacked firmware).

Strange. Then I imagine it might just be a side-effect of the way the keys are generated in lots for the 2000A series. I doubt very much that it's anything specifically intentional by Rigol since, AFAIK, they don't even sell BW upgrades - so if they were going to try to quash illicit BW upgrades, why not all of them?

If it's FW checking a new hardware revision of the board, then they had to code it quite some time ago into the FW since we've been on FW v.2 since last December or January.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Purevector on June 21, 2014, 04:23:58 pm
Strange. Then I imagine it might just be a side-effect of the way the keys are generated in lots for the 2000A series. I doubt very much that it's anything specifically intentional by Rigol since, AFAIK, they don't even sell BW upgrades - so if they were going to try to quash illicit BW upgrades, why not all of them?

If it's FW checking a new hardware revision of the board, then they had to code it quite some time ago into the FW since we've been on FW v.2 since last December or January.

Depending on Rigol's business plan, blocking 300MHz may be a smart marketing move.  I am sure sales of Rigol scopes is greatly enhanced by their reputation of being hackable.  If they clamped down hard on that, I think may people would look elsewhere for budget scopes.  For most people 200MHz and all options is a great hack.  I know I am very happy with what I have.  However, if you are a person who knows they need 300MHz, then you're probably not simply a hobbyist or low-budget lab.  In that performance range, you probably have a budget, and Rigol would want a bite of that.  This way, they still retain the budget crowd, while cashing in on the higher end user.  Also, as I said before, maybe during testing they flag units that are not capable of 300MHz.  This is all conjecture as I am in no way affiliated with Rigol.

If there is some sort of bug with the cryptography, I would be happy to provide any help I can to try and fix it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 21, 2014, 04:34:42 pm
Depending on Rigol's business plan, blocking 300MHz may be a smart marketing move.  I am sure sales of Rigol scopes is greatly enhanced by their reputation of being hackable.  If they clamped down hard on that, I think may people would look elsewhere for budget scopes.  For most people 200MHz and all options is a great hack.  I know I am very happy with what I have.  However, if you are a person who knows they need 300MHz, then you're probably not simply a hobbyist or low-budget lab.  In that performance range, you probably have a budget, and Rigol would want a bite of that.  This way, they still retain the budget crowd, while cashing in on the higher end user.  Also, as I said before, maybe during testing they flag units that are not capable of 300MHz.  This is all conjecture as I am in no way affiliated with Rigol.

You have a point - but honestly, the DS2000 series would not be a great choice if you really need the full 300MHz while using both channels. As many have pointed out here before, trying to squeeze 300MHz out of a machine with only a 1GSa/s maximum sample rate (both channels on) is really pushing the bounds of the input filter and sin(x) interpolation.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: rmawatson on June 21, 2014, 04:35:53 pm
Hello,

So I've just spent best part of £700 on a Rigol 2072A in the hope of being able to unlock it to 300mhz. Is there any way I can know if my unit is locked to 200mhz or will allow the full 300mhz. Is this defined by hardware, or is this something implemented in new firmware revisions ?

Sorry if this is answered, I haven't read all of the last 200 pages of posts.

Cheers

Rob.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 21, 2014, 04:54:08 pm
So I've just spent best part of £700 on a Rigol 2072A in the hope of being able to unlock it to 300mhz. Is there any way I can know if my unit is locked to 200mhz or will allow the full 300mhz. Is this defined by hardware, or is this something implemented in new firmware revisions ?

It's unclear at this time whether it's FW/key related - or related to a new HW revision. Some new owners seem to be able to install the 300MHz option - while others can't.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: rmawatson on June 22, 2014, 02:45:37 pm
Ok, well with luck it will turn up early next week. I'll report on here how it turns out with my scope and any version details I can to help others.

I was however wondering... Is it possible, like with flash/hard drives, that they units are tested prior to being labeled, and perhaps there is variation in the quality of the analog front ends of these scopes. Some work up to 300mhz within some set parameters, others don't perform to the same quality threshold, and they are catagorised as such?

This would make sense when looking at the cost of these scopes. As with most things, making it with tolerance is cheaper, especially if you can rebrand lower quality items as a lower end in the same product range.

This is from a point of view or ignorance on the internals of these scopes, so I have no idea if there are components that have this kind of band of quality, or if its a case of it they work at 300mhz as designed, or not at all?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 22, 2014, 06:31:04 pm
I was however wondering... Is it possible, like with flash/hard drives, that they units are tested prior to being labeled, and perhaps there is variation in the quality of the analog front ends of these scopes. Some work up to 300mhz within some set parameters, others don't perform to the same quality threshold, and they are catagorised as such?

This would make sense when looking at the cost of these scopes. As with most things, making it with tolerance is cheaper, especially if you can rebrand lower quality items as a lower end in the same product range.

This is from a point of view or ignorance on the internals of these scopes, so I have no idea if there are components that have this kind of band of quality, or if its a case of it they work at 300mhz as designed, or not at all?

I don't think that's the answer - since, as far as we've discovered so far, the entire series has always been a single model - although it's possible Rigol has changed something.

As mentioned in my previous post, possible problems with 300MHz could theoretically arise from aliasing caused by a sample rate that's too low. When both channels are on, the max. rate is 1GSa/s - meaning the Nyquist frequency is just 500MHz - and from published BW tests, 500MHz is not attenuated enough by the DS2000 front end. Perhaps this is something that Rigol has tackled in newer DS2302s, although I'm skeptical about it.


EDIT: It just crossed my mind that perhaps there's a new revision of the DS2000A series motherboard because of the recent introduction of the MSO2000A. So maybe some new buyers of the DS series are getting the new revision - which could, in some way, impact the ability to install the 300MHz option.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AintBigAintClever on June 23, 2014, 05:49:21 pm
It just crossed my mind that perhaps there's a new revision of the DS2000A series motherboard because of the recent introduction of the MSO2000A. So maybe some new buyers of the DS series are getting the new revision - which could, in some way, impact the ability to install the 300MHz option.
I can screenshot mine to get the various software/hardware versions and partial serial number if that helps, although it's running modified 2.x (and thinks it's a DS2302 scope).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: daemonix on June 24, 2014, 01:23:44 pm
Just tried to get the new firmware, and says files are gone....guess Rigol didn't like ppl just downloading it. Anybody out there willing to share the files?

Like Codemonkey said: "The following instructions apply, don't hold me responsible if you brick your scope etc etc..."
Quote
Links to download the two update files (Bootloader and Firmware update) -> 00.04.00
Be aware that after finishing the update no downgrading is possible.
 
Start with the Bootloader File and follow the instructions. After successfully finishing the bootloader update
do NOT reboot as instructed. Instead, continue with the Firmware update file.
 
Bootloader Update (new link):
https://www.dropbox.com/s/nteyndjz17dmcmi/DS1000Z%28Boot%29update.rar (https://www.dropbox.com/s/nteyndjz17dmcmi/DS1000Z%28Boot%29update.rar)
 
Firmware Update (new link):
https://www.dropbox.com/s/w9x66ghdhagtsaj/DS1000Z%28ARM%29update.rar (https://www.dropbox.com/s/w9x66ghdhagtsaj/DS1000Z%28ARM%29update.rar)

Hello.

Update file(bootloader)here is same as RIGOL International(China) Update file(MD5 checksum is same).
I don't why some model has to be done like that.
So my concerns,if we update only official update file(same as 1st file here) as usual,whether the options are remained or not.
The firmware here(2nd one) is a bit small file size.But I think,totally the result might be same.
Anybody only updated first file here?and no problem?


Be very careful with these files!!!! Bricking is very easy!!!!
You need to do is in 2 steps without reboot! if you reboot after the first file your are dead! :)

PS: there are some differences between serial numbers too! its better to ask for the right one for your serial number... its free... why download this one?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: rmawatson on June 24, 2014, 03:36:09 pm
Just to follow up,

My new 2072A arrived, and using the Upgrade Utility from madcrow, it took me about 5 minutes to get all the options. Including the 300mhz!

Photos of the HW/SW versions are included.

https://www.eevblog.com/forum/testgear/ds2000a-upgrade-utility/msg467427/#msg467427 (https://www.eevblog.com/forum/testgear/ds2000a-upgrade-utility/msg467427/#msg467427)

Thanks to all who made this possible!

One question. Is it now ok to upgade this to the latest firmware version?




Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Purevector on June 24, 2014, 05:46:47 pm
Just to follow up,

My new 2072A arrived, and using the Upgrade Utility from madcrow, it took me about 5 minutes to get all the options. Including the 300mhz!

Photos of the HW/SW versions are included.

https://www.eevblog.com/forum/testgear/ds2000a-upgrade-utility/msg467427/#msg467427 (https://www.eevblog.com/forum/testgear/ds2000a-upgrade-utility/msg467427/#msg467427)

Thanks to all who made this possible!

One question. Is it now ok to upgade this to the latest firmware version?

So I noticed that your scope came with 3.0.SP1 firmware, whereas mine came with 2.0.1.  When I get home I'll take a screenshot of the detailed system information and post it.  If you could do the same we can compare and see if there is a difference.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: rmawatson on June 24, 2014, 07:24:19 pm
Here is my detailed system information. I am about to try and update the firmware to v.03.00.01.03

from:

https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684 (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684)

Although it doesn't say this is for the 2000A series scopes? Does anyone have the latest firmware for these. I've requested it from rigol, but I have to wait for them to email it over..


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Purevector on June 24, 2014, 10:14:27 pm
Here is my screenshot with the newest firmware:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AintBigAintClever on June 24, 2014, 11:23:17 pm
Here's mine, using non-A-keys firmware 2.x.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: rmawatson on June 24, 2014, 11:33:00 pm
Here is my screenshot with the newest firmware:

So this is firmware for the A version? If so can you post a link to the file?

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Purevector on June 25, 2014, 12:42:59 am
So this is firmware for the A version? If so can you post a link to the file?

I used the firmware from the review thread.  I think the firmware is the same for both A and non-A.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 25, 2014, 12:52:02 am
Although it doesn't say this is for the 2000A series scopes? Does anyone have the latest firmware for these. I've requested it from rigol, but I have to wait for them to email it over..

So far, the firmware has been identical for all models in the DS2000 series: DS2000, DS2000A, DS2000A-S, MSO2000A, MSO2000A-S
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Weisserrabe on June 26, 2014, 02:04:39 pm
my DP832 arrived yesterday, firmware 01.09 and only Analyzer and Monitor options are as trial available :(
also the riglol key generator doesn't work, after entering the generated key it just says "wrong serial number" (I double checked if I entered the correct one)
it seems that it's since v01.09 and so far no working hack?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: samertje on June 26, 2014, 04:27:04 pm
Good day!

We received a Rigol DS4014 yesterday. I scanned and read through this huge thread and also found this directory:
http://www.gotroot.ca/rigol/ (http://www.gotroot.ca/rigol/)

As I understand, to upgrade to 500MHz I need to use the DS2000A upgrade utility and the DS4000update_00.02.01.00.03.GEL
Can anyone confirm this?

Also want to upgrade my DG4062. How to do this?

Cheers
Sam
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: samertje on June 26, 2014, 04:28:02 pm
Will update you guys off course.

Thanks to all the geniuses that worked on this.
Sam
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: daemonix on June 26, 2014, 05:28:42 pm
Which option do we choose for 1000z on the riglol? I remember 500uV is not good. how do you input all but that one?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Codemonkey on June 26, 2014, 05:42:25 pm
Which option do we choose for 1000z on the riglol? I remember 500uV is not good. how do you input all but that one?

DSER gets all but the 500uV option.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: daemonix on June 26, 2014, 08:18:16 pm
Which option do we choose for 1000z on the riglol? I remember 500uV is not good. how do you input all but that one?

DSER gets all but the 500uV option.

thank you!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: KK on June 26, 2014, 08:47:10 pm
Cheers to all that worked on this!

I upgraded a DS2072A first to all options and 200mhz bandwidth but then couldn't get 300mhz with the 300mhz upgrade key provided by the key website or the non-patched PC generator.

I removed the keys and then used the patched key generator linked in this thread and generated a new all options+300mhz key and it worked fine.

I have since upgraded to the latest 03 firmware and all options are intact.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AintBigAintClever on June 27, 2014, 01:18:59 am
Patched key generator? Is there a keygen other than the ones at http://www.gotroot.ca/rigol/ (http://www.gotroot.ca/rigol/) then? I was using rigup 0.4 from there.
Title: 300MHz on ALL DS2000A!!!
Post by: Purevector on June 27, 2014, 02:27:52 am
Ok, I got 300MHz upgrade and all options working on my DS2072A which was not able to upgrade to 300MHz.  Here is what I did:

1-Install all options, no bandwidth upgrade (NSEH) using rigup or the upgrade utility.
2-Use rigup to get license for NS8N (All options - 56M + 300MHz) and install on scope in any of the methods described in this thread.

The result will be a scope with all options AND 300MHz!!!  Success!  :-+

By the way, you can't use the upgrade utility to install NS8N since that program always uninstalls all options before installing new ones.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: samertje on June 27, 2014, 03:55:00 pm
Good day!

We received a Rigol DS4014 yesterday. I scanned and read through this huge thread and also found this directory:
http://www.gotroot.ca/rigol/ (http://www.gotroot.ca/rigol/)

As I understand, to upgrade to 500MHz I need to use the DS2000A upgrade utility and the DS4000update_00.02.01.00.03.GEL
Can anyone confirm this?

Also want to upgrade my DG4062. How to do this?

Cheers
Sam

So I was wrong. I'm not finding the right info in this thread. Anyone please help?
Link to how to upgrade?
Hopless, but happy

Sam
Title: Re: 300MHz on ALL DS2000A!!!
Post by: navzptc on June 27, 2014, 03:55:39 pm

Use rigup to get license for NS8N (All options - 56M + 300MHz) and install on scope in any of the methods described in this thread.


Many thanks for this - It worked a treat  ;D

Now have 300MHz in addition to all other options!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: samertje on June 27, 2014, 04:29:16 pm
Is upgrading DS4000 only possible via JTAG?
Noob wants to know
Title: Re: 300MHz on ALL DS2000A!!!
Post by: AintBigAintClever on June 27, 2014, 09:32:40 pm
Ok, I got 300MHz upgrade and all options working on my DS2072A which was not able to upgrade to 300MHz.  Here is what I did:

1-Install all options, no bandwidth upgrade (NSEH) using rigup or the upgrade utility.
2-Use rigup to get license for NS8N (All options - 56M + 300MHz) and install on scope in any of the methods described in this thread.

The result will be a scope with all options AND 300MHz!!!  Success!  :-+

PERFECT!  :-+
I did it the other way round on mine (NS8N first, then NSEH) and that worked as well. Now got all the goodies on 00.03.00.01.03 firmware. Thank you!  ;D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AintBigAintClever on June 27, 2014, 10:18:28 pm
Is upgrading DS4000 only possible via JTAG?
Noob wants to know
On the 2000 series the code can be entered using RIGOL Ultra Sigma, take a look at the PDF in http://gotroot.ca/rigol/ (http://gotroot.ca/rigol/)
Alternatively the 2000 allows keys to be entered directly into the scope. Utility Menu -> page down -> Options -> Setup -> Editor

There's some 4000 stuff here (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg338111/#msg338111), I don't know if it's been superseded but it refers to "trigger option install" which suggests to me that it too is done via Ultra Sigma.
Lots more DS4000 info at http://rigol.avotronics.co.uk/msods4000-series/ (http://rigol.avotronics.co.uk/msods4000-series/)
Title: Re: 300MHz on ALL DS2000A!!!
Post by: Tilman on June 28, 2014, 09:48:22 am
Ok, I got 300MHz upgrade and all options working on my DS2072A which was not able to upgrade to 300MHz.  Here is what I did:

1-Install all options, no bandwidth upgrade (NSEH) using rigup or the upgrade utility.
2-Use rigup to get license for NS8N (All options - 56M + 300MHz) and install on scope in any of the methods described in this thread.

The result will be a scope with all options AND 300MHz!!!  Success!  :-+

By the way, you can't use the upgrade utility to install NS8N since that program always uninstalls all options before installing new ones.

not working for me, NSEH -> License is unavliable....
only NSEQ works for me... |O
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: BTO on June 28, 2014, 06:11:05 pm
MY God, 229 Pages and counting... I can't believe this thread is still going LOL

It's Alive... Alive.

Ok. to get serious for a second

I have a Rigol DS2072A,
it was loaded with the 2.0 Software from the factory,
it was originally 70 MHz

Now SUCCESSFULLY UPGRADED TO 300MHz
All options Unlocked and 56 Mpt Memory Depth

IF ANYONE NEEDS ANY HELP, I AM HERE TO HELP, and Im happy to do it

So.. Newbies if you have a DS200A
let me know

I know this is a Huge thread,  I've gone through it in great detail

NO NEED TO DOWNLOAD ANYTHING

I'll supply it all From a Cloud

if enough people want it

I'll Just upload it for all of you to have access to , For.. Say,.. a Month or so, if you like

However it's easier if you guys just skype me, that's what a few people have been doing

There's 2 Main Issues that Get everyone

1. Make sure that your Scope is Set to COMPUTER for the USB Port,
   if it's set to PictBridge and considering that the front USB is PictBridge, Your Scope wont detect
   in the computer and you'll be scratching your head as to why

2. Putting the Scope into Firmware Update Mode is a little tricky and takes a correct explanation.
   which is where skype comes in.

the answer to issues 1 is  go to
UTILITY / IO SETUP / USB DEVICE     Make sure the value says COMPUTER

the answer to 2 is
Start with Scope OFF
Now.. before switching it ON

Find the Power Button,  DON'T PRESS IT YET,   Put your left thumb on the power button
Now, with your Right Thumb find the  ORANGE   HELP Button,  Put your thumb on it


Now.. Press the power button and STRAIGHT AWAY Press the HELP button,   
don't wait to see the RIGOL screen

if you see the rigol screen you need to do it quicker

YOU WILL KNOW THAT YOU HAVE DONE IT CORRECTLY  IF.......
the button in the top right corner  labelled   SINGLE   Turns Solid Orange

that means the meter is upgrade Mode

Now pop in your USB stick and the    CH 1 Button should flash Green
this indicates good communication with the USB Device and you just Wait 2 mins and it's done


if anyone needs any further assistance,  Let me know

I'm at
martin@btotechnicalexperts.com.au

be cool guys
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MrKrabs on June 29, 2014, 11:23:45 pm
Good day!

We received a Rigol DS4014 yesterday. I scanned and read through this huge thread and also found this directory:
http://www.gotroot.ca/rigol/ (http://www.gotroot.ca/rigol/)

As I understand, to upgrade to 500MHz I need to use the DS2000A upgrade utility and the DS4000update_00.02.01.00.03.GEL
Can anyone confirm this?

Also want to upgrade my DG4062. How to do this?

Cheers
Sam

So I was wrong. I'm not finding the right info in this thread. Anyone please help?
Link to how to upgrade?
Hopless, but happy

Sam

For the DS4000, you only need MrKrab's firmware at http://www.gotroot.ca/rigol (http://www.gotroot.ca/rigol) :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: samertje on July 01, 2014, 04:58:57 pm

For the DS4000, you only need MrKrab's firmware at http://www.gotroot.ca/rigol (http://www.gotroot.ca/rigol) :)

1. I used MrKrabs firmware on a compatible stick
2. Booted into blackscreen using help button
3. Entered the stick in the USB. Channel 1 didn't blink, but immeadiatly went solid together with run/stop button solid red

After this nothing happens. I hope this helps some of you...
Any help?

Thank you for all replies :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: BloodyCactus on July 01, 2014, 06:56:14 pm
did you test the usb stick by saving a screen image to it to make sure the ds4k can see it properly?

on my ds2k, I had to wait a bit before putting the usb stick in, too quick and it did not seem to load. tried again, waited like 30 seconds after the button presses then put it in and it recognised it correctly right away.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: samertje on July 01, 2014, 09:00:21 pm
did you test the usb stick by saving a screen image to it to make sure the ds4k can see it properly?

on my ds2k, I had to wait a bit before putting the usb stick in, too quick and it did not seem to load. tried again, waited like 30 seconds after the button presses then put it in and it recognised it correctly right away.

The stick works, I saved a png screenshot. I also waited a couple of minutes, still channel one only goes solid without first blinking.

When I used DS4000update_00.02.01.00.03.GEL, the channel 1 LED did blink first and then went solid. After a couple of minutes all lights lit. I restarted and nothing changed in the firmware or TB.

I did use riglol first though. Don't know if thats the wrong order?

In short: DS4000Update.00.02.01.00.03.MrKrabs.GEL on a stick didnt work for me so far...

Cheers
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 01, 2014, 09:01:54 pm
filename has to be  DS4000Update.GEL - and nothing else.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: samertje on July 01, 2014, 10:58:53 pm
DS4014 Upgraded with MrKrabs Firmware
Special thanks to MrKrabs and Cybernet for all work and helpfull comments and feedback.

How to Upgrade DS4014 Firmware 00.02.01

1. Test a USB stick by saving a screenshot on it with the scope

2. Download DS4000Update.00.02.01.00.03.MrKrabs.GEL.zip, rename it DS4000Update.GEL and copy to USB stick
Download the file here: http://www.gotroot.ca/rigol/ (http://www.gotroot.ca/rigol/)

3. Turn on scope and quick after power on press HELP couple of times. You boot into a dark screen, only the SINGLE button is red now. Wait for 30-60 seconds

4. Enter the stick. Channel one starts blinking. After couple of minutes all lights turn on. Turn off scope. Remove USB stick and reboot.

Can someone put this as a DS4000_Guide.txt on http://www.gotroot.ca/rigol/ (http://www.gotroot.ca/rigol/)
I searched for about one week for this  :-DD

Notice the screenshot is set with 5ns/div, but the fall time is 850ps.
I will post some more screenshots soon  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Co6aka on July 02, 2014, 03:11:47 pm
1. Test a USB stick by saving a screenshot on it with the scope

FWIW, I had similar issues installing firmware because the scope "didn't like" the USB stick, even though it could otherwise see/write/read to/from it.  I tried another USB stick and then it worked.  Prolly something in the firmware loader doesn't agree with certain USB interface chips.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: samertje on July 02, 2014, 03:38:28 pm
I will post some more screenshots soon  :-+

780ps fall time
Beauty!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: BTO on July 02, 2014, 04:50:19 pm
Just a Heads up ...

ANY ONE HAVING TROUBLE UPGRADING TO 300MHz With the DS2000A Series

I have just Posted a Summary of this Huge Post Here and will help anyone who wants a hand upgrading
but.. this tutorial should simply cover it for those just wanting a quick upgrade and are confused

https://www.eevblog.com/forum/testgear/unlockinghacking-the-rigol-ds2000a-series-scope-the-short-post/ (https://www.eevblog.com/forum/testgear/unlockinghacking-the-rigol-ds2000a-series-scope-the-short-post/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: miguelvp on July 02, 2014, 04:57:32 pm
Just a Heads up ...

ANY ONE HAVING TROUBLE UPGRADING TO 300MHz With the DS2000A Series

I have just Posted a Summary of this Huge Post Here and will help anyone who wants a hand upgrading
but.. this tutorial should simply cover it for those just wanting a quick upgrade and are confused

https://www.eevblog.com/forum/testgear/unlockinghacking-the-rigol-ds2000a-series-scope-the-short-post/ (https://www.eevblog.com/forum/testgear/unlockinghacking-the-rigol-ds2000a-series-scope-the-short-post/)

Or they can do this:
https://www.eevblog.com/forum/testgear/ds2000a-upgrade-utility/ (https://www.eevblog.com/forum/testgear/ds2000a-upgrade-utility/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mrflibble on July 02, 2014, 05:40:06 pm
I have just Posted a Summary of this Huge Post Here and will help anyone who wants a hand upgrading
but.. this tutorial should simply cover it for those just wanting a quick upgrade and are confused
That is well intended, but you may want to tune your writing style just a wee bit. ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: SittingBear on July 03, 2014, 01:13:20 pm
Just tried to get the new firmware, and says files are gone....guess Rigol didn't like ppl just downloading it. Anybody out there willing to share the files?

Like Codemonkey said: "The following instructions apply, don't hold me responsible if you brick your scope etc etc..."
Quote
Links to download the two update files (Bootloader and Firmware update) -> 00.04.00
Be aware that after finishing the update no downgrading is possible.
 
Start with the Bootloader File and follow the instructions. After successfully finishing the bootloader update
do NOT reboot as instructed. Instead, continue with the Firmware update file.
 
Bootloader Update (new link):
https://www.dropbox.com/s/nteyndjz17dmcmi/DS1000Z%28Boot%29update.rar (https://www.dropbox.com/s/nteyndjz17dmcmi/DS1000Z%28Boot%29update.rar)
 
Firmware Update (new link):
https://www.dropbox.com/s/w9x66ghdhagtsaj/DS1000Z%28ARM%29update.rar (https://www.dropbox.com/s/w9x66ghdhagtsaj/DS1000Z%28ARM%29update.rar)

Hello.

Update file(bootloader)here is same as RIGOL International(China) Update file(MD5 checksum is same).
I don't why some model has to be done like that.
So my concerns,if we update only official update file(same as 1st file here) as usual,whether the options are remained or not.
The firmware here(2nd one) is a bit small file size.But I think,totally the result might be same.
Anybody only updated first file here?and no problem?


Be very careful with these files!!!! Bricking is very easy!!!!
You need to do is in 2 steps without reboot! if you reboot after the first file your are dead! :)

PS: there are some differences between serial numbers too! its better to ask for the right one for your serial number... its free... why download this one?

Thanks for info.
But The firmware which I got directly from the marketing department of RIGOL in China is same as the bootloader file here.
I again ask about it to RIGOL.
(I don't test myself,but others use it,and no report their's dead.)
If I get the useful info,I will up here.

As a noob I would just like to ensure I won't end up bricking my newly bought device. This DS1000Z update will work for the DS1074Z, correct?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Fred27 on July 03, 2014, 03:51:40 pm
There is no DS1000Z - that just refers to the series which is DS1074Z, DS1104Z, DS1074Z-S and DS1104Z-S.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Julian on July 06, 2014, 02:47:20 pm
Hello guys,

I am interested in the MSO4000 series. Is it firmware compatible with the DSO4000 series? Meaning that I can use MrKrabs Frimware form here: http://gotroot.ca/rigol/ (http://gotroot.ca/rigol/) ?
If so do these option codes apply to the MSO4000: http://gotroot.ca/rigol/DS4000%20Series%20Options.txt (http://gotroot.ca/rigol/DS4000%20Series%20Options.txt) ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MarcelM on July 07, 2014, 01:29:20 pm
Hi all,

Got my MSO2072A in last week, running Software version 00.03.00.01.03
Since I already opened up the scope in anticipation of my JTAG interface,
I can take some pictures of the inside, if anyone's interested.

If I understand the previous 230 pages correctly, the safest way for me to unlock features is to collect a memory dump of the BF, and ask one of the software gurus on this forum to extract the private key from that.
(Since the "patched" firmware is apparently not MSO-aware, I don't feel comfortable downgrading to that)

Here's hoping I'll end up with an unlocked MSO2302A    ;)

Best regards,
Marcel
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: adi101 on July 07, 2014, 05:02:25 pm
Hi All,

I have recently acquired my DS2072A scope and I am unable to make the upgrade utility work.

For some reason, the boot loader doesn't accept any older versions other than the latest .GEL file (00.03.00.01.03).
Could I ask one of you gurus to make a new modified FW starting from the latest version available?
Or perhaps, if there is another way, could you please point it to me?

Software version: 00.03.00.01.03 (in short, 00.03.00.SP1)
Hardware version: 1.0.2.0.2 (in short, 2.0)

SPU: 04.00.07
WPU: 01.01.03
CCU: 12.29.00
MCU: 00.06

Many thanks!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hpux735 on July 08, 2014, 08:23:02 pm
my DP832 arrived yesterday, firmware 01.09 and only Analyzer and Monitor options are as trial available :(
also the riglol key generator doesn't work, after entering the generated key it just says "wrong serial number" (I double checked if I entered the correct one)
it seems that it's since v01.09 and so far no working hack?

Same here.  I couldn't downgrade the firmware to 01.06 or 01.08. :(
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: roema on July 09, 2014, 12:29:41 am
I have a DSA815-TG with version 00:01:09.

unfortunately I have seen too late that the keygen does not work with this version. Now I have made a downgrade to version 00:01:05, unfortunately the keygen does not work anyway.

Motherboard: 00:03
Radio Frequency: Board: 0:04
Digital Board: 0:04
Firmware: 00:01:05
Boot: 00:01:02

Maybe someone can give me info.

Downgrade Procedere:

From 09 -> 08 with Power & Preset Button
From 08 -> 06 with normal USB
From 06 -> 05 with normal USB

Thank you so much!

roema
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on July 09, 2014, 01:16:46 am
I have a DSA815-TG with version 00:01:09.

unfortunately I have seen too late that the keygen does not work with this version. Now I have made a downgrade to version 00:01:05, unfortunately the keygen does not work anyway.

roema

roema:

Is it 1.  That the Keygen doesn't  work (as in, it will not generate a key code)?  If this is the case, did you leave an extra space or character (such as a period after the Serial) with the entry for the Serial, or Option? 

or,  2. That the DSA815-TG won't accept the Keygen's resultant key code to open the Option(s) for you?

Please reply here to me, or via a PM.

You also may want to post instead to EEVblog 'Spectrum Analyzer - Rigol DSA815', at the following:
https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg473658/#msg473658 (https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg473658/#msg473658)

    Ted572

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: roema on July 09, 2014, 01:37:50 am
ted572:

It works!
I have found MY error, i have not changed the AAAA in keygen..

Thanks for your post!

roema
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: motocoder on July 09, 2014, 07:18:02 am
Is it possible to update the first post in the thread to be summary with links? I tried to find the info that I needed, but gave up after about 40 pages...

Anyway, I have a Rigol 2072 (NOT the A version), into which I have installed the keys generated by an older version of riglol. I have two problems:

1) I used what was later determined to be an invalid device option code to generate my keys. I'm not sure if that is the cause of #2.
2) The scope is locking up more frequently than I would like. It tends to happen about once every 2 or 3 times I use it.

So I'd like to uninstall the keys an upgrade the firmware to the latest version that still allows me to install the unlock keys. Can someone please give me instructions or pointers to the right posts to:

1) Uninstall the keys.
2) What latest firmware is safe to use and where to get it (I assume if I ask Rigol, they'll send me the latest version which is probably incompatible)

Thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Teneyes on July 09, 2014, 07:35:06 am
1) Uninstall the keys.
2) What latest firmware is safe to use and where to get it (I assume if I ask Rigol, they'll send me the latest version which is probably incompatible)
@Motocoder
#1) To uninstall all options, use SCPI command with Ultra Sigma from Rigol
http://www.rigol.com/prodserv/Waveform%20Generators/software/?act=view&itemid=354
"SYSTEM:OPTION:UNINSTALL"

#2) See:
https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158659/#msg158659
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: motocoder on July 09, 2014, 07:48:29 am
1) Uninstall the keys.
2) What latest firmware is safe to use and where to get it (I assume if I ask Rigol, they'll send me the latest version which is probably incompatible)
@Motocoder
#1) To uninstall all options, use SCPI command with Ultra Sigma from Rigol
http://www.rigol.com/prodserv/Waveform%20Generators/software/?act=view&itemid=354
"SYSTEM:OPTION:UNINSTALL"

#2) See:
https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158659/#msg158659

Thank you, Teneyes. From the link you provided, it looks like FW#00.03.00.01.03 is the latest version. Is this version compatible with the keys generated by Riglol, or do I need to use an older version of the firmware for that?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: motocoder on July 09, 2014, 07:55:44 am
Thank you, Teneyes. From the link you provided, it looks like FW#00.03.00.01.03 is the latest version. Is this version compatible with the keys generated by Riglol, or do I need to use an older version of the firmware for that?
for me  FW#00.03.00.01.03 installed and keeps the options that were installed before, and allows  'CAN'

Ok, so sounds like a safe method would be to uninstall the option keys, generate new keys using the correct option code, install those keys, upgrade the firmware, and do the post-update settings reset mentioned in the post you linked?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: motocoder on July 09, 2014, 08:30:49 am
Thank you, Teneyes. From the link you provided, it looks like FW#00.03.00.01.03 is the latest version. Is this version compatible with the keys generated by Riglol, or do I need to use an older version of the firmware for that?
for me  FW#00.03.00.01.03 installed and keeps the options that were installed before, and allows  'CAN'

Ok, so sounds like a safe method would be to uninstall the option keys, generate new keys using the correct option code, install those keys, upgrade the firmware, and do the post-update settings reset mentioned in the post you linked?

Disregard my last question - I did exactly what I said there, and it is running the latest firmware with the options enabled. Unfortunately, I noticed that it locked up already once (in the System/Info screen, it locked up and wouldn't exit this). I am now wondering if there is some actual hardware issue with my scope...

In any event, thank you for your help.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on July 09, 2014, 10:58:49 am
Re. Post #3442 by 'motocoder':

Disregard my last question - I did exactly what I said there, and it is running the latest firmware with the options enabled. Unfortunately, I noticed that it locked up already once (in the System/Info screen, it locked up and wouldn't exit this). I am now wondering if there is some actual hardware issue with my scope...

In any event, thank you for your help.
[/quote]
---------------------------------------------------------------------------------------------------------------------
Reply from 'Ted572' for 'motocoder'

My recommendation....

1. Your DS2000 settings should be set for Power = 'Default', NOT 'Last'.  This way when you have a lockup, etc. and you reboot (Power cycle Off/On) your issue will be cleared.  Otherwise you can end up in a endless loop of unsuccessful reboots.
2. Clear the DS2000's FRAM to be sue this isn't an issue.  To do this:  Press and hold down the left-hand side F6 key during a reboot.
3. Do Not use the 300MHz BW Option!  If you have it selected for a DS2000 non A (it is OK for the DS2000A) get rid of it.  Uninstall All Options with UltraSigma and then add them back in without 300MHz BW.  If you are not sure how to do this please feel free to ask me for a procedure.

      Regards, Ted572.

Edit: Changed from F7 (wrong) to F6 (correct) in item 2. above.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: motocoder on July 10, 2014, 02:02:01 am
Re. Post #3442 by 'motocoder':

Disregard my last question - I did exactly what I said there, and it is running the latest firmware with the options enabled. Unfortunately, I noticed that it locked up already once (in the System/Info screen, it locked up and wouldn't exit this). I am now wondering if there is some actual hardware issue with my scope...

In any event, thank you for your help.
---------------------------------------------------------------------------------------------------------------------
Reply from 'Ted572' for 'motocoder'

My recommendation....

1. Your DS2000 settings should be set for Power = 'Default', NOT 'Last'.  This way when you have a lockup, etc. and you reboot (Power cycle Off/On) your issue will be cleared.  Otherwise you can end up in a endless loop of unsuccessful reboots.
2. Clear the DS2000's FRAM to be sue this isn't an issue.  To do this:  Press and hold down the left-hand side F7 key during a reboot.
3. Do Not use the 300MHz BW Option!  If you have it selected for a DS2000 non A (it is OK for the DS2000A) get rid of it.  Uninstall All Options with UltraSigma and then add them back in without 300MHz BW.  If you are not sure how to do this please feel free to ask me for a procedure.

      Regards, Ted572.
[/quote]

Thanks, Ted. Did you mean to say clear FRAM by holding the F6 key during boot, or is it actually F7? The instructions that Teneyes linked to above say F6. I didn't notice any messages about clearing FRAM - does it do anything to indicate that's actually happened?

Regarding the 300MHz BW option, I do indeed have that enabled. I even forked over some money for the 300MHz probes, so it is very disappointing to learn that it causes issues...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: motocoder on July 10, 2014, 02:09:27 am
Re. Post #3442 by 'motocoder':

Disregard my last question - I did exactly what I said there, and it is running the latest firmware with the options enabled. Unfortunately, I noticed that it locked up already once (in the System/Info screen, it locked up and wouldn't exit this). I am now wondering if there is some actual hardware issue with my scope...

In any event, thank you for your help.
---------------------------------------------------------------------------------------------------------------------
Reply from 'Ted572' for 'motocoder'

My recommendation....

1. Your DS2000 settings should be set for Power = 'Default', NOT 'Last'.  This way when you have a lockup, etc. and you reboot (Power cycle Off/On) your issue will be cleared.  Otherwise you can end up in a endless loop of unsuccessful reboots.
2. Clear the DS2000's FRAM to be sue this isn't an issue.  To do this:  Press and hold down the left-hand side F7 key during a reboot.
3. Do Not use the 300MHz BW Option!  If you have it selected for a DS2000 non A (it is OK for the DS2000A) get rid of it.  Uninstall All Options with UltraSigma and then add them back in without 300MHz BW.  If you are not sure how to do this please feel free to ask me for a procedure.

      Regards, Ted572.
[/quote]

Also, what is the option code for all options except 300MHz? I used "DSHH" last time, which is all options AND 300 MHz.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: motocoder on July 10, 2014, 02:12:31 am
I uninstalled all options, and was re-entering a code. It locked up while entering the code! So seems my lock-ups are not related to the 300 MHz option...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Sparky on July 10, 2014, 04:33:59 am
Is the DP832 firmware 00.09.01 still un-hackable at this stage?

Sort of correct; the latest firmware is actually 00.01.09.00.01 (date 12/27/2013) and bootloader 01.06 (date 12/27/2013).

Yes, still un-hackable. (No further investigation that I'm aware of since the original hack.)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: josem on July 10, 2014, 06:36:37 am
Is the DP832 firmware 00.09.01 still un-hackable at this stage?

Sort of correct; the latest firmware is actually 00.01.09.00.01 (date 12/27/2013) and bootloader 01.06 (date 12/27/2013).

Telonic in the UK and already listing 00.01.10 as the latest firmware for the DP832.

http://www.rigol-uk.co.uk/ProductDetails.asp?ProductCode=FIRMTEST#.U74xXq5QZ3s (http://www.rigol-uk.co.uk/ProductDetails.asp?ProductCode=FIRMTEST#.U74xXq5QZ3s)

Not sure if this is 100% accurate and what changes it would include...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on July 10, 2014, 11:30:34 am
Re. Post #3442 by 'motocoder':

Thanks, Ted. Did you mean to say clear FRAM by holding the F6 key during boot, or is it actually F7? The instructions that Teneyes linked to above say F6. I didn't notice any messages about clearing FRAM - does it do anything to indicate that's actually happened?

Regarding the 300MHz BW option, I do indeed have that enabled. I even forked over some money for the 300MHz probes, so it is very disappointing to learn that it causes issues...

Yes, you are correct the Clear FRAM key is F6 (not F7).  I'm sorry for the error, and thank you for catching it.  I also edited my information above with the correct key reference.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on July 10, 2014, 01:15:26 pm
Is the DP832 firmware 00.09.01 still un-hackable at this stage?

Sort of correct; the latest firmware is actually 00.01.09.00.01 (date 12/27/2013) and bootloader 01.06 (date 12/27/2013).

Telonic in the UK and already listing 00.01.10 as the latest firmware for the DP832.

http://www.rigol-uk.co.uk/ProductDetails.asp?ProductCode=FIRMTEST#.U74xXq5QZ3s (http://www.rigol-uk.co.uk/ProductDetails.asp?ProductCode=FIRMTEST#.U74xXq5QZ3s)

Not sure if this is 100% accurate and what changes it would include...

Until there is a very good reason to upgrade, I don't think upgrading would be a great idea.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on July 10, 2014, 01:49:03 pm
3. Do Not use the 300MHz BW Option!  If you have it selected for a DS2000 non A (it is OK for the DS2000A) get rid of it.  Uninstall All Options with UltraSigma and then add them back in without 300MHz BW.  If you are not sure how to do this please feel free to ask me for a procedure.

To clarify some things:

First of all - in respect to using the "300MHz" BW option - it makes NO difference if you have a DS2000 or DS/MSO2000A - other than you have the 50 ohm input impedance choice. Aside from that, as far as I've seen, Rigol did not make any major changes to the front-end.

Secondly, to all the people who believe they are magically getting a perfectly-capable "300MHz" DSO just because they put in some option codes: look at all the DSO models from highly-respected test-equipment manufacturers (Agilent, Hameg, Tektronix, etc) - do you see any 2GSa/s DSOs with a higher than 200MHz BW? No, you don't - because there are mathematical reasons why it doesn't really work well. Rigol (and the other Chinese companies) have not invented some new wonderful method for squeezing more BW out of less sample rate - they are, in fact, delivering DSOs that will have problems reproducing those kind of BW waveforms accurately at certain settings (i.e. both channels on) - period.

As long as you understand these problems, fine. But again: they are identical for both DS2000 and DS2000A - it doesn't matter which model you have.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on July 10, 2014, 02:54:17 pm
Re. Post #3442 by 'motocoder':

Disregard my last question - I did exactly what I said there, and it is running the latest firmware with the options enabled. Unfortunately, I noticed that it locked up already once (in the System/Info screen, it locked up and wouldn't exit this). I am now wondering if there is some actual hardware issue with my scope...

In any event, thank you for your help.
---------------------------------------------------------------------------------------------------------------------
Reply from 'Ted572' for 'motocoder'

My recommendation....

1. Your DS2000 settings should be set for Power = 'Default', NOT 'Last'.  This way when you have a lockup, etc. and you reboot (Power cycle Off/On) your issue will be cleared.  Otherwise you can end up in a endless loop of unsuccessful reboots.
2. Clear the DS2000's FRAM to be sue this isn't an issue.  To do this:  Press and hold down the left-hand side F7 key during a reboot.
3. Do Not use the 300MHz BW Option!  If you have it selected for a DS2000 non A (it is OK for the DS2000A) get rid of it.  Uninstall All Options with UltraSigma and then add them back in without 300MHz BW.  If you are not sure how to do this please feel free to ask me for a procedure.

      Regards, Ted572.

Thanks, Ted. Did you mean to say clear FRAM by holding the F6 key during boot, or is it actually F7? The instructions that Teneyes linked to above say F6. I didn't notice any messages about clearing FRAM - does it do anything to indicate that's actually happened?

Regarding the 300MHz BW option, I do indeed have that enabled. I even forked over some money for the 300MHz probes, so it is very disappointing to learn that it causes issues...
[/quote]

Reply rfom Ted572:

Apparently 300MHz BW Option MAY NOT (?) be a problem for the DS2000 as was previously reported.  Anyway I'm going to reinstall the 300MHz BW Option in my unit, as I didn't have any issues with it before, other than the technical BW/2GHz Sampling limitations 'marmad' had previously brought to all of our attention.

DS2000, D2000A Device BW Options:  DSAJ - 100MHz BW,  DSAS - 200MHz BW,  DSEZ - 200MHz BW and all Options,  DSCA - 300MHz BW.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Teneyes on July 10, 2014, 03:29:29 pm
So at this point, it's unknown if it's just a bug that exists in v.3 with certain settings - or is linked to 300MHz option being installed. But I have to say, before I ever used the 300MHz option, I rarely had the DS2000 crash - but it's happened many more times with it installed. But more info is definitely needed to pinpoint the source of the problem.
I agree with Marmad that the accuracy of 300MHz is questionable with only 1GSa/s,

I have installed the 300MHz option.  ( I do like 1nsec/div)
Unlike Marmad, I do not use my DSO very much (retired) and it is not required to be 100% available.
I am willing to use 300MHz in order to isolate the conditions that causes the DSO to HANG. 

I have seen in FW 00.03.00.00.00 where the Math function 'lg(' would HANG the DSO ,but that does not occured (Fixed) in FW 00.03.00.01.03. This does indicate that often Rigol has not tested new firmware changes thoroughly.

PS  , My DSO is back to S/N= DS2A000000001 with DS2302, but easy to reset
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on July 10, 2014, 07:39:20 pm
Install - Uninstall Rigol's Options using UltraSigma
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: motocoder on July 11, 2014, 06:04:06 am
Install - Uninstall Rigol's Options using UltraSigma

Thanks, Ted
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: aurel on July 17, 2014, 06:52:47 pm
Like many of you, I received a brand new DP832 power supply a few weeks ago, with firmware 1.09 installed. Which means no working keygen and no possibility to downgrade...

Well... Not anymore !

I've spent quite some time reverse engineering the new firmware, and I discovered that they didn't change the signing algorithm, and not even the private key. Overall, they only added some bits shuffling (ie. obfuscation) on the final license string and they changed the options coding.

So I took the latest riglol version I found (from http://gotroot.ca/rigol/ (http://gotroot.ca/rigol/)), and added support for generating license for this new DP832 firmware. It works exactly the same as before. You just need to specify different options string depending on your DP832 firmware version. Executing riglol without parameters will list the valid options depending on firmware version.

I also found other valid options strings but they do not seem to have any effect. And as it seems there is no way to uninstall options on the DP832 (am I wrong ?), I can't check if those unknown options actually activates the same features as some other options. Anyway, here is the list of unknown options, if somebody wants to play with: FPLT, FTLT, F2PT, F4PT.

I compiled this new riglol version for linux, osx and windows, as well as the web version. It would be nice if the persons handling http://gotroot.ca/rigol/riglol/ (http://gotroot.ca/rigol/riglol/) and http://riglol.3owl.com/ (http://riglol.3owl.com/) could update their online version.

Enough talk ? You want some action ? Here you go: riglol-20140717.zip (https://mega.co.nz/#!KM9mXBiT!0EwuvQY7hOcZyTOQx53wDiWKwg4PkVT8D7oqDcCRbA8)
SHA1 of this file: 662b9f460eb618856567587e39827104f22049ca

And last but not least, huge thanks to everybody involved in this riglol hack, and especially to cybernet and zombie28 !
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mcinque on July 17, 2014, 07:56:04 pm
I've spent quite some time reverse engineering the new firmware, and I discovered that they didn't change the signing algorithm, and not even the private key.

Nice work!

But by revealing details you're just suggesting them how to improve the next version ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sotos on July 17, 2014, 10:06:46 pm
I've spent quite some time reverse engineering the new firmware, and I discovered that they didn't change the signing algorithm, and not even the private key.

Nice work!

But by revealing details you're just suggesting them how to improve the next version ;)



Maybe, his working for them. ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hematose on July 18, 2014, 01:56:05 pm
Does anyone here know if the same upgrade codes are used for DS1000Z and MSO1000Z units? Would Riglol work for MSO1000Z?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on July 18, 2014, 05:22:11 pm
It would be nice if the persons handling http://gotroot.ca/rigol/riglol/ (http://gotroot.ca/rigol/riglol/) and http://riglol.3owl.com/ (http://riglol.3owl.com/) could update their online version.

I have http://riglol.3owl.com/ (http://riglol.3owl.com/) updatet. Thank you for your work.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: probez on July 18, 2014, 10:37:11 pm
Thanks a lot Aurel, it rocks :-+

Like many of you, I received a brand new DP832 power supply a few weeks ago, with firmware 1.09 installed. Which means no working keygen and no possibility to downgrade...

Well... Not anymore !

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: anson80 on July 21, 2014, 09:49:54 am
Like many of you, I received a brand new DP832 power supply a few weeks ago, with firmware 1.09 installed. Which means no working keygen and no possibility to downgrade...

Well... Not anymore !

I've spent quite some time reverse engineering the new firmware, and I discovered that they didn't change the signing algorithm, and not even the private key. Overall, they only added some bits shuffling (ie. obfuscation) on the final license string and they changed the options coding.

So I took the latest riglol version I found (from http://gotroot.ca/rigol/ (http://gotroot.ca/rigol/)), and added support for generating license for this new DP832 firmware. It works exactly the same as before. You just need to specify different options string depending on your DP832 firmware version. Executing riglol without parameters will list the valid options depending on firmware version.

I also found other valid options strings but they do not seem to have any effect. And as it seems there is no way to uninstall options on the DP832 (am I wrong ?), I can't check if those unknown options actually activates the same features as some other options. Anyway, here is the list of unknown options, if somebody wants to play with: FPLT, FTLT, F2PT, F4PT.

I compiled this new riglol version for linux, osx and windows, as well as the web version. It would be nice if the persons handling http://gotroot.ca/rigol/riglol/ (http://gotroot.ca/rigol/riglol/) and http://riglol.3owl.com/ (http://riglol.3owl.com/) could update their online version.

Enough talk ? You want some action ? Here you go: riglol-20140717.zip (https://mega.co.nz/#!KM9mXBiT!0EwuvQY7hOcZyTOQx53wDiWKwg4PkVT8D7oqDcCRbA8)
SHA1 of this file: 662b9f460eb618856567587e39827104f22049ca

And last but not least, huge thanks to everybody involved in this riglol hack, and especially to cybernet and zombie28 !

Thanks Aurel,This is great :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: rodpp on July 21, 2014, 05:27:11 pm
First, congratulations for all involved in this work, it´s amazing!

Knowing the hack method for Rigol DS1000Z, DS2000, DG4000, DSA800 could this help in hacking the DG1000Z series?

Does anyone tried to hack the Rigol DG1000Z Arbitrary Waveform Function Generators?

EDIT: AWF model number correction DG100Z -> DG1000Z.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ve7xen on July 22, 2014, 04:30:57 am
Enough talk ? You want some action ? Here you go: riglol-20140717.zip (https://mega.co.nz/#!KM9mXBiT!0EwuvQY7hOcZyTOQx53wDiWKwg4PkVT8D7oqDcCRbA8)
SHA1 of this file: 662b9f460eb618856567587e39827104f22049ca

And last but not least, huge thanks to everybody involved in this riglol hack, and especially to cybernet and zombie28 !

Great work! I have updated my mirror at http://gotroot.ca/rigol/ (http://gotroot.ca/rigol/) . The old version also remains for posterity.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Weisserrabe on July 22, 2014, 07:15:42 pm
I've spent quite some time reverse engineering the new firmware...


 :-+ great thanks to you  :clap:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Loeti on July 24, 2014, 08:55:59 pm
Does anyone here know if the same upgrade codes are used for DS1000Z and MSO1000Z units? Would Riglol work for MSO1000Z?

Hello,

I got my MSO1104Z-S today. Even if the Rigol order codes for the options are the same for the DS1000Z and MSO1000Z series,
unfortunately Riglol doesn't work for the MSO1000Z at the moment. The firmware version of the MSO1000Z is also V04.00,
but there must be something different. Different private key, different option code or something like this. I've tried some other
option codes like "MSAB" instead of "DSAB", or "DSBB" or "DSHB" like other models use but I haven't succeeded yet.

Michael
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: trunc71 on July 27, 2014, 07:14:38 pm
My DS2072A will arrive this week and of course I'll give it a try to unlock the added value. The description of the unlock process with the patched firmware 00.02.01.00.03 is pretty straightforward but I have one question left.

On the server http://www.gotroot.ca/rigol/ (http://www.gotroot.ca/rigol/) are three different rigup versions. They have version numbers 0.1, 0.2 and 0.4. Which version is the correct one to upload the binary key file ? The latest which is 0.4 or 0.1 which is the one mentioned in the document "DS2072A Unlocking Guide" on the same server ?

My thanks to all contributors who have spent that much time to look into all this.

Mike
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AintBigAintClever on July 28, 2014, 11:56:27 pm
0.4 should do nicely.
If for some reason your scope rejects the 300MHz+all features code, try creating NS8N and NSEH codes and applying both, as per this (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg468951/#msg468951) post.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: trunc71 on July 29, 2014, 10:02:58 am
OK, thanks. Seems that I'm well prepared now. I'll give it a try tomorrow.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: trunc71 on July 30, 2014, 03:46:51 pm
In the meantime I have successfully unlocked all options of my DS2072A.  :-DD

However it was not that easy as I thought. On my 64-bit Windows 7 none of the keys created with rigup worked. The DS did not respond at all when sending the final key. No error message or whatever. Nevertheless I've seen some messages with similar experience in the forum before. Therefore, I switched to a 32-bit Virtual machine and tadaaa it worked immediately. No idea what's wrong with my 64.bit OS. Finally, I installed the latest firmware and all licenses are still there.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: conte_vlad on July 30, 2014, 03:51:24 pm
great  :)

I ask: what did not worked on 64 version? rigup or else ultra sigma that send serials?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: trunc71 on July 30, 2014, 04:11:02 pm
I cannot say what exactly didn't work on 64-bit. Rigup has created the keys and I tried to send them with ultra sigma and later with Telnet. In both cases I got no response from the DS2072A and the trial licenses were still active. I also tried the update tool which has been programmed by madcrow when I remember correctly. I this case I saw the congratulation screen of the update tool but when I checked the installed licenses I saw the trial ones, only.

On 32-bit I tried the manual procedure first and it worked. Interestingly, the keys created by rigup are exactly the same on both windows versions. It must be another problem, maybe something is wrong with the bus communication. I don't know.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: conte_vlad on July 30, 2014, 04:15:16 pm
thanks for answer  :)

it seems rigup, as you said, works same as the keys are same, may be some comunication problems with 64 version.  I will do some test, I am afraid to open the unit  :-// but I will do
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mrflibble on July 30, 2014, 06:34:39 pm
I ask: what did not worked on 64 version? rigup or else ultra sigma that send serials?

Probably the 64-bit windows version. IIRC the used crypto library had some 32 vs 64-bit issues (on linux as well). So if the windows binary has not been compiled with the correct flags that would indeed cause a mismatch between generated keys on 32-bit vs 64-bit platform.

So when in doubt using a 32-bit VM is a good workaround as already noted.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: trunc71 on July 31, 2014, 06:49:47 am
If that is really the case then I'd expect different keys on both systems. But they are identical what makes perfect sense to me. I have also created the keys with different rigup versions. Also identical. Therefore, when finally transmitting the key to the DOS, the unit cannot know on which system the key was created. But on 64-bit W7 I got no response at all from the DOS whereas on 32-bit I saw the progress bar etc. immediately. I may be completely wrong but at the moment I doubt that the issue has to do with the key calculation.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AintBigAintClever on July 31, 2014, 08:03:30 am
My keys were successfully applied using Ultra Sigma in Win7 64-bit, sounds like you had an issue with either drivers or the Ultra Sigma install. Well done getting it done anyway.  :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: trunc71 on July 31, 2014, 09:40:14 am
That's what I first thought because I know that many people have successfully used W7 64-bit. But others didn't. In my case Ultra Sigma was able to communicate with the DOS and has read out the keys correctly with the *IDN? command. This worked for both 32- and 64-bit without problems. The :SYSTem:OPTion:INSTall command only worked on 32-bit for me. I don't know whether this is due to a driver problem but I do think that this is some kind of a communication problem that arises under not yet known circumstances.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Alex_Ismagilov on August 02, 2014, 09:02:44 pm
Hi all,
I'm very happy :) about upgrading my DS2202A-S to DS2302A-S+AllOptions.
Greetings from Russia

Greatest THANKS for guys who make it possible!

Some details:
Used this guide: http://gotroot.ca/rigol/D2072A%20Unlocking%20Guide.pdf (http://gotroot.ca/rigol/D2072A%20Unlocking%20Guide.pdf)
The wizard "DS2000A Upgrade Utility" - does not work. Can't see after flashing fw.

My device: DS2202A-S
Now DS2302A-S with all options :)

Serial: DS2E15xxxxxx
Software version: 00.02.01.00.03
Hardware version: 1.2.2.0.2

Thanks: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg409142/#msg409142 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg409142/#msg409142)
NSFH - ???? all option and NO CHANGE bandwidth :(
NS8Q - ???? all option and 300mhz

Alex.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sethur on August 03, 2014, 04:06:04 pm
Hi *,

I got an DS1074Z-S, but non of the generated keys worked for me.  :-\

Unfortunately Rigol added a 12h timer when several wrong keys have been entered. :(

I then ripped up the case and read out the W25X40B flash, tried another wrong key and re-read the flash again to find out where the 12h timer is located.
It seems to be a 32bit timer at location 0x78007.

The trail keys start at 0x78027.
Removing them from flash and reentering would give another trail period, I think...

Maybe someone out there has some interest and knowledge on hacking this?

Greets,
sethur



Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PepeK on August 05, 2014, 09:07:04 pm
Do I understand it properly that if DS 2072 A or MSO 2072 A has a hardware version 2.2 it is not possible to downgrade using an USB stick ? (and it works only for HW revision 2.0 ? )
Is the only working way opening the scope and dumping a memory with some JTAG tool as described in this forum ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on August 06, 2014, 04:27:50 pm
It would be nice if the persons handling http://gotroot.ca/rigol/riglol/ (http://gotroot.ca/rigol/riglol/) and http://riglol.3owl.com/ (http://riglol.3owl.com/) could update their online version.

I have http://riglol.3owl.com/ (http://riglol.3owl.com/) updatet. Thank you for your work.
Great work! I have updated my mirror at http://gotroot.ca/rigol/ (http://gotroot.ca/rigol/) . The old version also remains for posterity.
Avotronics's UK mirror has been updated too.

Original made by studio25 (https://www.eevblog.com/forum/profile/?u=37760): http://riglol.3owl.com (http://riglol.3owl.com)
Canadian mirror hosted by ve7xen (https://www.eevblog.com/forum/profile/?u=17762): http://gotroot.ca/rigol/riglol/ (http://gotroot.ca/rigol/riglol/)
UK mirror hosted by Avotronics (https://www.eevblog.com/forum/profile/?u=89989): http://rigol.avotronics.co.uk/mirrors/riglol/ (http://rigol.avotronics.co.uk/mirrors/riglol/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 0xPIT on August 07, 2014, 07:27:05 am
Hi,

I'm new to the forum, thanks for your great work.

So I've got a new 2072A and I am currently trying to dump the beast,
I soldered a cable for my USB Blaster and started Dumping according to
post #2433, the Bfin is recognized nicely.

Dumping seems to work, but when it's finished, gdb spits out
Code: [Select]
dump binary memory ~/sdram.bin 0x00000000 0x07FFFFFF
Ignoring packet error, continuing...
Reply contains invalid hex digit 116

and even as the process takes hours and I can see gdbproxy's debug out
to iterate over the address space, no file is written.

I've already increased gdb's remotetimeout without any change.

As the BF-Toolchain was not available for Mac and did not compile on first try,
I used a current Ubuntu on my old Atom Netbook to do the dump.

Update:
Now also tried with same '116' problem on my MacBook Pro in a Ubuntu 14.04 VirtualBox.
I've even tried several toolchains and gdbproxy/gdb combinations

Update 2 (solved using workaround):
I managed to extract a dump and generate Keys using this workaround:
in gdb, I used
    set debug remote 1
and
    set remotelogfile /tmp/log

Then I started a new dump, which failed at the end with the stated '116' error, but all responses from the Blackfin were logged as ascii hexdump in the logfile.

I then awk'd the logfile to include only lines starting with +r $ and then removed this string using vi (:%s/^r\ +$//g)
Now I used xxd -p -r to convert the hexdump to binary and ran rigup on it, which worked fine.


Greetings,
  - pit
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: asgard20032 on August 08, 2014, 03:04:37 pm
Im about to buy a DS1074z or a MSO1074z (maybe the -s variant), but I want to know if anyone here successfully hacked the MSO one/
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on August 08, 2014, 03:49:01 pm
Im about to buy a DS1074z or a MSO1074z (maybe the -s variant), but I want to know if anyone here successfully hacked the MSO one/
Same firmware. Makes no difference if it's DSO or MSO, or even S variant.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: asgard20032 on August 08, 2014, 03:53:41 pm
Its because of that I ask :

Does anyone here know if the same upgrade codes are used for DS1000Z and MSO1000Z units? Would Riglol work for MSO1000Z?

Hello,

I got my MSO1104Z-S today. Even if the Rigol order codes for the options are the same for the DS1000Z and MSO1000Z series,
unfortunately Riglol doesn't work for the MSO1000Z at the moment. The firmware version of the MSO1000Z is also V04.00,
but there must be something different. Different private key, different option code or something like this. I've tried some other
option codes like "MSAB" instead of "DSAB", or "DSBB" or "DSHB" like other models use but I haven't succeeded yet.

Michael
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PedroDaGr8 on August 09, 2014, 01:02:09 am
Im about to buy a DS1074z or a MSO1074z (maybe the -s variant), but I want to know if anyone here successfully hacked the MSO one/
The search button and/or reading this thread would give you the answer.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: asgard20032 on August 09, 2014, 01:36:20 am
Im about to buy a DS1074z or a MSO1074z (maybe the -s variant), but I want to know if anyone here successfully hacked the MSO one/
The search button and/or reading this thread would give you the answer.

I read over 100 page on this thread, used the search on MSO1074z and MSO1000z, without more result than what I quoted and what we are talking since the last 3 post.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: miguelvp on August 09, 2014, 01:51:33 am
https://www.eevblog.com/forum/testgear/rigol-ds1074z-oscillosope/msg434605/#msg434605 (https://www.eevblog.com/forum/testgear/rigol-ds1074z-oscillosope/msg434605/#msg434605)

utility:
http://riglol.3owl.com/ (http://riglol.3owl.com/)

within utility you will find the following.

DS1000z device options:
DSAB - Advanced Triggers
DSAC - Decoders
DSAE - 24M Memory
DSAJ - Recorder
DSBA - 500uV Vertical
DSEA - 100MHz
DSFR - all options

But I have no idea about the MSO1074z then again you mentioned the DS1074z as well.

Edit: took me under 2 minutes (maybe even under 1 minute) to find it with the search button.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: asgard20032 on August 09, 2014, 04:11:32 am
I know for the DS1074z... im asking about MSO1074z
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Loeti on August 09, 2014, 09:10:23 pm
I tried it with a DS1104Z-S, serial no. starting with "DS1ZB" -> works.
MSO1104Z-S, serial no. starting with "DS1ZD" -> doesn't work.

Maybe they have changed the algorithm or at least the private key and provided downward compatibility for the first DS1000Z scopes with "DS1ZB" serials.

Michael
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: elebot on August 11, 2014, 09:02:07 pm
If both the HW and firmware of the DP832A and DP832 are basically the same, what actually distinguishes the two models?
Serial number range? Or some license key? Is it obvious from the firmware disassembly?

I am curious how feasible would it be to do the full conversion into DP832A as I would love seeing on my DP832 multicolor classic mode and with normal font (not the 7 segment display simulation).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PepeK on August 12, 2014, 09:40:47 am
As the latest DS / MSO 2072 having SW 3.0 SP1 and HW 2.2 refuses patched firmware gel file ver 2, what about modifying the gel file to pretend it is ver 3 ?
Is there something like header / data structure in the first block of the gel file which defines version ?
I am asking because if I open any (2.0 or 3.0) gel file in hex editor, there is a version string at the beginning.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hematose on August 12, 2014, 03:32:13 pm
I can also confirm:

I tried it with a DS1104Z-S, serial no. starting with "DS1ZB" -> works.
MSO1104Z-S, serial no. starting with "DS1ZD" -> doesn't work.

Maybe they have changed the algorithm or at least the private key and provided downward compatibility for the first DS1000Z scopes with "DS1ZB" serials.

Michael

 :--

I tried: http://riglol.3owl.com/ (http://riglol.3owl.com/) with options DSFR, MSAJ, DSAE on MSO1074Z-S, serial no. starting with "DS1ZD" -> doesn't work. I'd love it if anyone else had any thoughts. Could the fact that the scope still has the trial options enabled have an impact?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AintBigAintClever on August 12, 2014, 10:36:33 pm
As the latest DS / MSO 2072 having SW 3.0 SP1 and HW 2.2 refuses patched firmware gel file ver 2, what about modifying the gel file to pretend it is ver 3 ?
Is there something like header / data structure in the first block of the gel file which defines version ?
I am asking because if I open any (2.0 or 3.0) gel file in hex editor, there is a version string at the beginning.
There'll be more to it than that. Version 2.x will know nothing about the MSO features, could end up bricking the scope.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: houly on August 17, 2014, 09:44:57 am
Hello all,
I'm plainning to buy a MSO4000 series wand i would want to know if the hack could work on it (in order to choose the 100 MHz and hope hack it to have more bandwidth)
is it possible ? and how ?

regards
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: salvix on August 17, 2014, 11:27:49 am
Hello all,
I'm plainning to buy a MSO4000 series wand i would want to know if the hack could work on it (in order to choose the 100 MHz and hope hack it to have more bandwidth)
is it possible ? and how ?

regards

Yes. Install MrKrabs firmware from http://gotroot.ca/rigol/.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gandalf_Sr on August 17, 2014, 12:54:00 pm
@0xPIT

I'm having exactly the same issues you described in your reply #3478. 

I'm trying to dump the memory from my MSO2072A using Ubuntu on a Dell Netbook, it always finishes with 'Reply contains invalid hex digit 116'

For us non-Linux literate folks, would you mind expanding on where to find the log file and the exact lines for using the AWK instructions?

Thanks

[Edit] My latest attempt finished as 0xPIT said, again with the 116 error and then I closed the terminal but I can't find the tmp/log file on the drive anywhere.  Any idea where it's supposed to be or how I can find it?

[Edit2] I am thinking of getting a different USB-JTAG debugger.  The Olimex vn seems expensive at $70 given the chip is <$3, any suggestions for a good FT2232-based programmer that is supported by urJTAG?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 0xPIT on August 19, 2014, 08:09:43 pm
@Gandalr_Sr

I described the procedure in my post.

You need to specify the location of the log file in gdb using e.g.
    set remotelogfile /tmp/log
 it will save the log to the file named "log" in the folder /tmp.

Then you need to clean the log file.
First, you want only lines received, which start with "+r $"
   awk '/+r\ $/' /tmp/log > /tmp/filtered.log

Second, we strip all the "+r $"
   cat /tmp/filtered.log | sed 's/^+r\ $//' > /tmp/cleaned.log

then use convert to binary using
   xxd -p -r /tmp/cleaned.log /tmp/dump.bin

If in doubt, consult the man pages (man <command>) or google for it.
Be aware that I'm on the road, you need to double-check escaping of the commands I suggested.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gandalf_Sr on August 21, 2014, 09:35:04 am
@0xPIT

Thanks for the clarifications, I'm now pretty sure that the reason I've failed so far to dump successfully from my MSO2072A is that the cheap $7 'Altera' USB Blaster from eBay only supports a frequency of 12 MHz, (gdb) tell me that after I execute the command that's supposed to set the frequency.

Now I'm waiting for the Sparkfun FT2232-based device to arrive.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: xd1217 on August 23, 2014, 07:17:20 pm
As the latest DS / MSO 2072 having SW 3.0 SP1 and HW 2.2 refuses patched firmware gel file ver 2, what about modifying the gel file to pretend it is ver 3 ?
Is there something like header / data structure in the first block of the gel file which defines version ?
I am asking because if I open any (2.0 or 3.0) gel file in hex editor, there is a version string at the beginning.

Did you sort it out??
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DocSnyder on August 23, 2014, 10:30:47 pm
Hello,

I own a MSO1074Z-S since a few hours. It has software Version 04.00 but the existing license gen doesn't seem to work. Any suggestions? I don't want to brick it.

Thank you
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 1.21gigawatts on August 24, 2014, 08:54:59 pm
OK, So I've read (pretty much) every post in this topic and I'm confused. In recent posts it appears that some people are having problems applying licenses to newer 2000 series scopes. Others say that riglol works straight out of the box to generate licenses while still others are busy doing hex dumps through jtag.

I'm seriously considering (actually more like planning, if I get a good answer to this) to buy (tomorrow) an MSO2072A-S. It's been over 30 years since I bough a new scope for myself, and I figure this one will last until (my) doomsday. But I don't want to make a mistake and be stuck at 70MHz.

I have an Altera USB Blaster Rev C and an assortment of computers running whatever OS one could possibly need, but I don't have a clear path to the upgrade procedure. Don't get me wrong - I have read several procedures and they are pretty clear step-by-step instructions. I'm just concerned about whether they will work on current Rigol production scopes. I know that last time I looked into this (a couple of months ago) there were none of these scopes to be found at US dealers, so I'm assuming that what I buy tomorrow will be from a new production run.

Sooo, is this a purchase I should make, or should I wait a while?

BTW, thanks to all of you who do the work that benefits the rest of us. I just joined eevblog, and I intend to contribute my share of design experience.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Slappy_g on August 24, 2014, 11:58:32 pm
OK, So I've read (pretty much) every post in this topic and I'm confused. In recent posts it appears that some people are having problems applying licenses to newer 2000 series scopes. Others say that riglol works straight out of the box to generate licenses while still others are busy doing hex dumps through jtag.

I'm seriously considering (actually more like planning, if I get a good answer to this) to buy (tomorrow) an MSO2072A-S. It's been over 30 years since I bough a new scope for myself, and I figure this one will last until (my) doomsday. But I don't want to make a mistake and be stuck at 70MHz.

I have an Altera USB Blaster Rev C and an assortment of computers running whatever OS one could possibly need, but I don't have a clear path to the upgrade procedure. Don't get me wrong - I have read several procedures and they are pretty clear step-by-step instructions. I'm just concerned about whether they will work on current Rigol production scopes. I know that last time I looked into this (a couple of months ago) there were none of these scopes to be found at US dealers, so I'm assuming that what I buy tomorrow will be from a new production run.

Sooo, is this a purchase I should make, or should I wait a while?

BTW, thanks to all of you who do the work that benefits the rest of us. I just joined eevblog, and I intend to contribute my share of design experience.
You should be fine, but you'll have to go the JTAG route with the newer devices. ROM downgrade is risky. JTAG is guaranteed.

You may need a new device, though, as that Altera device is locked at 12 MHz. I used the Olimex device from Sparkfun. See my thread about the MSO2000 series for detailed instructions.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Slappy_g on August 24, 2014, 11:59:03 pm
OK, So I've read (pretty much) every post in this topic and I'm confused. In recent posts it appears that some people are having problems applying licenses to newer 2000 series scopes. Others say that riglol works straight out of the box to generate licenses while still others are busy doing hex dumps through jtag.

I'm seriously considering (actually more like planning, if I get a good answer to this) to buy (tomorrow) an MSO2072A-S. It's been over 30 years since I bough a new scope for myself, and I figure this one will last until (my) doomsday. But I don't want to make a mistake and be stuck at 70MHz.

I have an Altera USB Blaster Rev C and an assortment of computers running whatever OS one could possibly need, but I don't have a clear path to the upgrade procedure. Don't get me wrong - I have read several procedures and they are pretty clear step-by-step instructions. I'm just concerned about whether they will work on current Rigol production scopes. I know that last time I looked into this (a couple of months ago) there were none of these scopes to be found at US dealers, so I'm assuming that what I buy tomorrow will be from a new production run.

Sooo, is this a purchase I should make, or should I wait a while?

BTW, thanks to all of you who do the work that benefits the rest of us. I just joined eevblog, and I intend to contribute my share of design experience.
You should be fine, but you'll have to go the JTAG route with the newer devices. ROM downgrade is risky. JTAG is guaranteed.

You may need a new device, though, as that Altera device is locked at 12 MHz. I used the Olimex device from Sparkfun. See my thread about the MSO2000 series for detailed instructions.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DocSnyder on August 25, 2014, 10:57:44 am
Will I have to do the same procedure for the MSO1074Z-S? As much as I understood the private key of the Ds1k has been read out of the firmware. Now it seems that the MSO behaves not the the same.  Will the JTAG method work in the same way as it does for the DS2000? or do I simply have to use other option keys? thank you for your support.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 1.21gigawatts on August 25, 2014, 09:03:43 pm
@Slappy_g: Thanks. I've ordered the scope and it will be here Wednesday. I'm like a kid on (the day before) Christmas eve.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Bukurat on August 26, 2014, 05:33:53 am
Well I followed  the instructions in post #2433, downloaded  blackfin-toolchain-2013R1_45-RC1.x86_64.tar.bz2 and unpacked it into the /opt directory on my ubuntu powered laptop, plugged in the Olimex ARM-USB-OCD adaptor and ran
sudo ./bfin-gdbproxy  --debug bfin --frequency=5000000  while in the appropriate bin directory

the result:  ./bfin-gdbproxy: 3: ./bfin-gdbproxy: Syntax error: Unterminated quoted string
I see the same error message with no arguments.

excuse me while I  |O
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Macman on August 26, 2014, 08:15:44 am
the result:  ./bfin-gdbproxy: 3: ./bfin-gdbproxy: Syntax error: Unterminated quoted string
I see the same error message with no arguments.

You are probably using 32 bit Linux with the 64bit version of the toolchain. Try the 32bit version of the toolchain blackfin-toolchain-2013R1_45-RC1.i386.tar.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Bukurat on August 26, 2014, 10:41:44 am
You are probably using 32 bit Linux with the 64bit version of the toolchain. Try the 32bit version of the toolchain blackfin-toolchain-2013R1_45-RC1.i386.tar.

That was it, Thanks.
Now its found the USB cable and has connected to the libftdi  driver
I don't have it connected to the DSO yet so it's telling me that TDO seems to be stuck at 0. That's the same message I had with the win 7 setup and the ARM-USB-OCD connected to the DSO.

I'll plug it into the DSO tomorrow and see how far I get.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hematose on August 26, 2014, 02:29:23 pm
Will I have to do the same procedure for the MSO1074Z-S? As much as I understood the private key of the Ds1k has been read out of the firmware. Now it seems that the MSO behaves not the the same.  Will the JTAG method work in the same way as it does for the DS2000? or do I simply have to use other option keys? thank you for your support.

If you manage to do this and get the private key, you will have a lot of grateful people here!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DocSnyder on August 26, 2014, 04:26:47 pm
Will I have to do the same procedure for the MSO1074Z-S? As much as I understood the private key of the Ds1k has been read out of the firmware. Now it seems that the MSO behaves not the the same.  Will the JTAG method work in the same way as it does for the DS2000? or do I simply have to use other option keys? thank you for your support.

If you manage to do this and get the private key, you will have a lot of grateful people here!

I am new to that topic. But i do not have fear to go that way. But i would like to get a quote or a hint what way should be the best way to do it. I am aware of the procedure for the DS2000 but i have no clue if this is the same for the MSO1074Z-s. How did they find the key for the DS1000? And how are the option keys to be found? The same way and toolchain as on the DS2000.
Maybe they have only changed the option keys. To many questions.
It would be extremely helpful to get any hints from the pros here.
Thank you in advance
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hematose on August 27, 2014, 09:52:43 pm
k=40228745953163121  (0x8EEBD4D04C3771)

Wow! :clap: Thanks for sharing! How did you found it?

I will answer myself: ECDLP Solver 0.2a found valid solution in 156ms on my computer!
Rigol engineers did really bad job with license keys protection...

I'm trying to read back in the thread to find out how the private keys for the DS1000Z were first found. I'm not sure if we need hardware access or to purchase a genuine key to test it against.

If only Cybernet were still in this thread.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Slappy_g on August 27, 2014, 11:23:59 pm
You are probably using 32 bit Linux with the 64bit version of the toolchain. Try the 32bit version of the toolchain blackfin-toolchain-2013R1_45-RC1.i386.tar.

That was it, Thanks.
Now its found the USB cable and has connected to the libftdi  driver
I don't have it connected to the DSO yet so it's telling me that TDO seems to be stuck at 0. That's the same message I had with the win 7 setup and the ARM-USB-OCD connected to the DSO.

I'll plug it into the DSO tomorrow and see how far I get.

By the way, the stuck pin message is typically from people misinterpreting the USB device pin-outs and flipping it left-to-right.

Sent from my SM-N900T using Tapatalk

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Slappy_g on August 27, 2014, 11:28:02 pm
As requested, here's the step by step instructions for people like me who are not fans of Linux.

https://www.eevblog.com/forum/testgear/rigol-mso2000-series-hacking/msg498454/#msg498454 (https://www.eevblog.com/forum/testgear/rigol-mso2000-series-hacking/msg498454/#msg498454)

Sent from my SM-N900T using Tapatalk

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DocSnyder on August 28, 2014, 08:36:23 pm
Any news on the MSO1074Z-S ? I am considering changing it into a DS2000. But there is a new firmware out there: 00.03.01. Will the known Jtag method work on this firmware.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PepeK on August 28, 2014, 09:23:17 pm
Any news on the MSO1074Z-S ? I am considering changing it into a DS2000. But there is a new firmware out there: 00.03.01. Will the known Jtag method work on this firmware.

Changing 1000 series to 2000 series scope ? It is not possible. You can only enable specific features for every series. It is like you want to change Dacia to Rolls-Royce :-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DocSnyder on August 28, 2014, 09:26:57 pm
I meant taking it back to the dealer...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: elscode on August 29, 2014, 08:48:55 pm
Hello.

I just received my new DSA815-TG Rigol spectrum analyser.
Great device for price.

I have try to unlock options using the keygen. But the keys are consider as invalid  :-//

Version of main board : 00.06
Version of RF FPGA Board : 00.05
Version of digital FPGA Board : 00.04
Version of Firmware : 00.01.09
Version of boot : 00.01.04

Using the sweb interface here : http://rigol.avotronics.co.uk/mirrors/riglol/ (http://rigol.avotronics.co.uk/mirrors/riglol/) and here : http://riglol.3owl.com (http://riglol.3owl.com)

Give me the same key as the one in command line under linux.

Is there any issue ?

Thanks.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pinkman on August 29, 2014, 10:19:26 pm
Hello.

I just received my new DSA815-TG Rigol spectrum analyser.
Great device for price.

I have try to unlock options using the keygen. But the keys are consider as invalid  :-//

Version of main board : 00.06
Version of RF FPGA Board : 00.05
Version of digital FPGA Board : 00.04
Version of Firmware : 00.01.09
Version of boot : 00.01.04

Using the sweb interface here : http://rigol.avotronics.co.uk/mirrors/riglol/ (http://rigol.avotronics.co.uk/mirrors/riglol/) and here : http://riglol.3owl.com (http://riglol.3owl.com)

Give me the same key as the one in command line under linux.

Is there any issue ?

Thanks.

I have also received a DSA815-TG today, my numbers are as follows:

Main board:  00.07
RF FPGA board: 0.05
Digital FPGA board: 0.04
Firmware: 00.01.09
Boot: 00.01.04

The private key (and keygen) for previous versions does not appear to work.

I was looking around, but it seems that noone has the private key for this version yet.  Can anyone confirm this is true?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: elscode on August 29, 2014, 10:21:37 pm
Thanks for your confirmation.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: navzptc on August 29, 2014, 10:31:46 pm
Firmware 01.09 will not let you enter the codes for upgrade options.
Have you tried downgrading to 01.08 which does work on mine - place the firmware on a usb stick which is known to work on your unit (try saving a screen shot to it to make sure it works with your dsa815),  plug the stick in, switch on the unit and hold down the preset button when booting up.
If it does boot into 01.08 then hopefully you can enter the options - bear in mind it might not let you downgrade with the latest boot option, but worth a try.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: elscode on August 29, 2014, 10:54:14 pm
Update File Error!

When trying to boot from usb key including 00.01.08 firmware  :-//

(i have try booting on usb key with 0.01.09 firmware, and flashing firmware works fine. So i presume Rigol do not allow flashing with previous firmware version.  |O )
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sm5uiu on August 30, 2014, 07:12:58 pm
Just bought one 2072A.
Used the D2072A Unlocking Guide
Installed firmware DS2000(DSP)update_00.02.01.00.03 (license keys dump).
The web based keygen does NOT work (even if I enter priv key).
Rigup 0.4 keys work.
However ! Unlocking over SCPI did not work - had to enter keys manually directly on the scope. (just got timeout error)
However ! Guide has wrong unlock "id" - "NS8H - All Options + 300Mhz" YOU SHOULD USE NS8N
I installed all options
Installed 200MHz
And then finnaly figured (found) the NS8N
After unlocking installed firmware DS2000-03_00_01_03

Some say 5 minutes.. well I spent at least 3 hours.. (but it was worth it)

/Sam


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sm5uiu on August 30, 2014, 07:21:18 pm
Just a note. I also bought at 815-TG.. and just used the web based keygen.. unlocked all options.

For that unlock I used 1.03C with priv key (presinstalled) 80444DFECE903E

Entered generated keys directly on the spec ana.

CAPITAL LETTERS AND NO SPACES OR DASHES.

AAAB - Tracking Generator
(0001) DSA800-TG

AAAC - Advnced Measurement Kit
(0002) DSA800-AMK

AAAD - 10Hz RBW
(0003) Is it 10Hz RBW

AAAE - EMI/Quasi Peak
(0004) DSA800-EMI

AAAF - VSWR
(0005) DSA800-VSWR

/Sam
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jc101 on August 30, 2014, 08:25:13 pm
Just a note. I also bought at 815-TG.. and just used the web based keygen.. unlocked all options.

For that unlock I used 1.03C with priv key (presinstalled) 80444DFECE903E

Entered generated keys directly on the spec ana.

CAPITAL LETTERS AND NO SPACES OR DASHES.

AAAB - Tracking Generator
(0001) DSA800-TG

AAAC - Advnced Measurement Kit
(0002) DSA800-AMK

AAAD - 10Hz RBW
(0003) Is it 10Hz RBW

AAAE - EMI/Quasi Peak
(0004) DSA800-EMI

AAAF - VSWR
(0005) DSA800-VSWR

/Sam

Was this with FW 1.09?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: elscode on August 30, 2014, 09:26:10 pm
Testing again with only CAPITAL LETTERS. But keys are not accepted  :-//
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pinkman on August 31, 2014, 12:44:23 am
Just a note. I also bought at 815-TG.. and just used the web based keygen.. unlocked all options.

For that unlock I used 1.03C with priv key (presinstalled) 80444DFECE903E

Entered generated keys directly on the spec ana.

CAPITAL LETTERS AND NO SPACES OR DASHES.

AAAB - Tracking Generator
(0001) DSA800-TG

AAAC - Advnced Measurement Kit
(0002) DSA800-AMK

AAAD - 10Hz RBW
(0003) Is it 10Hz RBW

AAAE - EMI/Quasi Peak
(0004) DSA800-EMI

AAAF - VSWR
(0005) DSA800-VSWR

/Sam

Where did you buy it from?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: trunc71 on August 31, 2014, 08:29:47 am
...
However ! Unlocking over SCPI did not work - had to enter keys manually directly on the scope. (just got timeout error)
However ! Guide has wrong unlock "id" - "NS8H - All Options + 300Mhz" YOU SHOULD USE NS8N

There is still a lot of mystery behind this process that is obviously not fully understood. I also had the problem that unlocking over SCPI didn't work at all on Win 64bit though I can connect to the DSO. On Win 32 no problem at all and the unlocking code passed through. Also the NS8H worked for me so that I had no need to try the NS8N. But others have described that they had to unlock in a two step process by applying two different codes.

On the other hand this unlock procedure comes to an end anyway due to Rigol's FW 03 changes.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DocSnyder on August 31, 2014, 09:52:57 am
Again the MSO1074Z-S. Can anyone give a description how the private key and the option keys for the DS1000Z has ever been found? Maybe they have changed for the MSO.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hematose on August 31, 2014, 11:56:15 am
Just want to echo DocSnyder's request. Is there a keydump firmware for the DS1000Z or was there some other way to get at the private key?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 1.21gigawatts on September 01, 2014, 06:34:40 pm
I have successfully upgraded an MSO2072A-S using an "Altera" bus blaster (which I already had from another project). No problems at all following the instructions in this thread and others. Yes, I got the warning about the fixed frequency, but it worked fine anyway.

One thing, though (and this has nothing to do with the upgrade): I'm having a hell of a time with Ultra Station downloading waveforms to the "-S" part of the instrument. It is recognized by Ultra Sigma (and I have edited the .ini file to apply Ultra Station to this scope). I can edit a wave form and download it, but the only thing that gets set is the frequency. The waveform never actually appears.

Any idea what's going on here? Any better place to ask?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gandalf_Sr on September 02, 2014, 12:39:47 am
I've just successfully 'upgraded' an MSO2072A to a MSO2302A.  I had to go the JTAG dump route because I have the MSO, not the DS.  My cheap 'Altera' USB Blaster didn't work, nor did a Bus Blaster from dangerous prototopyes.  The device that worked was the Olimex ARM-USB-OCD from Sparkfun.

Follow Slappy_g's instructions and you will prevail.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pinkman on September 02, 2014, 09:27:47 pm
Thanks to anyone who can give me advice:

Since I have one of the new DSA815-TG's with the new boot loader/firmware, it sounds like I need to buy a JTAG interface and get busy dumping my memory to hopefully find a new private key.  Is this correct?  I am definitely capable of doing this.  I just would like someone to advise me whether this should help or if Rigol has found some way to make the memory dump useless.  I assume that I'll void my warranty by breaking the silver seals, so I only want to do that if it is necessary :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Bukurat on September 03, 2014, 12:35:45 am
Thanks to anyone who can give me advice:

  I assume that I'll void my warranty by breaking the silver seals, so I only want to do that if it is necessary :)

It's possible to remove the seal without damage if you are careful. There are YouTube  how to videos referenced  somewhere earlier in these threads
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sptm14 on September 03, 2014, 04:49:23 am
Again the MSO1074Z-S. Can anyone give a description how the private key and the option keys for the DS1000Z has ever been found? Maybe they have changed for the MSO.

I don't have time to dig for the algorithm or public key, but enabling all options on MSO1074Z is actually quite easy. All you need to do is patch one function. get_opt_trial_state() must return 0x03. Thank you Rigol for debug info in firmware, totally insecure board configuration, and soldered-in JTAG header.

In OpenOCD for firmware version 04.00, just issue these two commands:

mww 0x40223FF4 0xE3A00003
mww 0x40223FF8 0xE12fff1e

(this translates to mov r0,0x03; bx lr)

Unfortunately, you cannot permanently flash the image back until somebody writes a flash driver for the IMX28 processor. Current version of OpenOCD does no have it. I have not tried patching a firmware update image and flashing it through the update process, considering how insecure the device is, it might work.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: rmd79 on September 03, 2014, 08:08:59 am
Thanks for the info sptm14,

I opened my MSO1074Z-S today to see what the situation was regarding possible candidates for JTAG headers.

I have a 6-pin header and two 10-pin headers on the board.  My guess based on the PCB traces is that the 10-pin header nearest to the Hynix ram is probably the JTAG header, and my hope is that this header follows the usual 10-pin ARM JTAG pinout (I haven't poked around at it yet)

Are you able to confirm if my assumptions are correct?

I've attached a photo from inside my scope for reference.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sptm14a on September 03, 2014, 07:42:46 pm

Are you able to confirm if my assumptions are correct?


Yes, the 10-pin header next to the hynix dram chip is the JTAG you need (there are several jtag interfaces on the board).
Pinout is not standard ARM, here it is, left to right as shown on your picture:

top row: tck,tms,tdi,trst,3.3v
bottom row: XXX,tdo,srst,gnd,gnd
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: rmd79 on September 04, 2014, 01:02:28 am
top row: tck,tms,tdi,trst,3.3v
bottom row: XXX,tdo,srst,gnd,gnd

Thanks for this, really appreciated.  I've got some JTAG adaptors on the way so hopefully I'll be able to play with this really soon :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: rmd79 on September 05, 2014, 01:13:29 pm
Thanks for this, really appreciated.  I've got some JTAG adaptors on the way so hopefully I'll be able to play with this really soon :)

Well I tried the first JTAG adaptor without success (but also no smoke, so thats always nice).  I bought a cheap ST-Link v2 JTAG/SWD dongle, but no luck with that so far.  I'm completely new to JTAG, so I'm not really sure what I'm doing.

I tried to get OpenOCD v0.8.0 working with the ST-Link adaptor connected to the scope.  I made a short cable to convert the standard 20-pin ARM connector to the 10 pin one in the scope, but all I've been able to get OpenOCD to do so far is reset the scope when it tries to connect.  I played around with the reset_config options a little but still had the same results.  OpenOCD can detect the ~3.3v from the scope, so the dongle appears to at least partially work.

I've got an Olimex ARM-USB-OCD-H adaptor on its way, so maybe I'll have better luck with that.  The more I've been reading to try to solve the various problems I've run into so far, the more its becoming clear that the ST-Link adaptors are a little bit "special" (not in a good way).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: radiogeek97 on September 08, 2014, 11:06:52 am
About to pull trigger on a dsa815tg, prob from tequipment, BUT I saw a post by "pinkman"  in this thread that made refrence to a new boot loader/ firmware that may have locked out the "upgrade process"  to turn on options.  Is this true ? ????.   If so could an owner downgrade the FW and then "activate the options"   Any advice would as always be welcomed
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: elscode on September 08, 2014, 11:38:36 am
I have got the brand new version of dsa815. Downgrade to previous firmware version is not possible. Image is considered as invalid and upgrade process aborted  :-//
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: radiogeek97 on September 08, 2014, 11:50:23 am
if this is actually the case what is the last version of the FW where the "upgrades" will work?  The other question i have and i am a total newbie: If i got an 815 with the latest "locked" FW how would that work with the old software licenses for accessories ect, for example  the rigol SWR brige kit comes with the hardware and a software key for $600 usd  if rigol eliminated the "home upgrade" process by another FW revision wouldnt they have to change all the old legacy software license keys?  IF not wouldnt the same KEYGEN software work?  what if i got a brand new up to date dsa815 from rigol and bought a new rigol VSWR bridge/and software license off ebay would the old software license be incompattible?   JUst a few random newbie thoughts
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gandalf_Sr on September 08, 2014, 12:30:20 pm
It seems that all the messing around with holo-stickers and JTAG may no longer be necessary...

Check out this thread https://www.eevblog.com/forum/testgear/rigol-mso2000-series-hacking/180/ (https://www.eevblog.com/forum/testgear/rigol-mso2000-series-hacking/180/) where PeDre has shown that a memory dump can be done using a simple SCPI command over the USB or LAN ports using a free download utility.  That memory dump can then be applied to Rigup in the usual way.  This has been successfully done by at least 3 people so far.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: radiogeek97 on September 08, 2014, 03:48:04 pm
Has anybody purchased a rigol dsa815 with the latest FW and have been Abel to use the rigol key gen utility to upgrade their device successfully ? 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pinkman on September 08, 2014, 07:14:07 pm
Has anybody purchased a rigol dsa815 with the latest FW and have been Abel to use the rigol key gen utility to upgrade their device successfully ?
As myself and another stated on page 236, no, it does not work.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: swanawood on September 09, 2014, 04:17:31 pm
@pinkman
Did you try what suggested by Gandalf_Sr at page 236 ?

Thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: radiogeek97 on September 09, 2014, 04:21:50 pm
folks
    i am totally ignorant when it comes to  simple SCPI  commands.  I have looked thru the threads and havent found any good explanation on how to initiate and run  simple SCPI commands.  If anybody could point me in the right direction ( as far as previous threads ect)  I will educate myself as much as possible so as not to be a burdon on all of you that have been soo helpful

thanks in advance
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gandalf_Sr on September 09, 2014, 10:40:08 pm
folks
    i am totally ignorant when it comes to  simple SCPI  commands.  I have looked thru the threads and havent found any good explanation on how to initiate and run  simple SCPI commands.  If anybody could point me in the right direction ( as far as previous threads ect)  I will educate myself as much as possible so as not to be a burdon on all of you that have been soo helpful

thanks in advance
Follow the link in my post at the end of page 236 of this thread (previous page).  There's not much reading to do.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: flatlander on September 10, 2014, 03:07:15 am
I'm about to pull the trigger on a MSO-1074z and was wondering if anyone has tried the SCPI method to dump this scope's memory and then use 'rigup' to get the keys to unlock the optional features on this model.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: swanawood on September 10, 2014, 08:13:17 am
It would be appriciated if radiogeek97 and pinkman give it a try with the DSA-815 and report back the result.

Personally I havo no Rigol instrument to try with (willing to buy 815TG), so I can't help directly.

Thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: radiogeek97 on September 10, 2014, 11:33:55 am
I will as soon as I get one  ;D

i am an idot compared to some of the talent on here, however I am savvy enough to follow directions once somebody has cracked the problem  :clap:    I "upgraded my rigol 1052e" with directions provided to me by the fine posts on here.  I most certainly will post when I get my dsa815  I just need to figure out how the SCPI commands are imputted ect before I commit my cash

thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sacherjj on September 10, 2014, 03:14:50 pm
It would be appriciated if radiogeek97 and pinkman give it a try with the DSA-815 and report back the result.

Personally I havo no Rigol instrument to try with (willing to buy 815TG), so I can't help directly.

I had no problems with keys on my 815TG, but not sure if firmware has changed.  I've had it about 6 months.  We purchased the features I needed for work, but I unlocked some features I wanted to play with.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: radiogeek97 on September 10, 2014, 04:54:09 pm
Sacherjj
   I am in the same boat getting one for work with LEGIT Vswr from rilgol, but would like to play with a few more options like the EMI.   I contacted a few vendors like Tequipment and they have no way of knowing what FW version they will ship out, most likeley latest due to their high turn over  :palm: 
   I'm hoping somebody can do a step by step how to for the dsa815 with the latest FW version, as I am not up to speed on hacking although I can apply and follow directions.    Thanks again to all on here
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sacherjj on September 10, 2014, 07:02:46 pm
Sacherjj
   I am in the same boat getting one for work with LEGIT Vswr from rilgol, but would like to play with a few more options like the EMI.   I contacted a few vendors like Tequipment and they have no way of knowing what FW version they will ship out, most likeley latest due to their high turn over  :palm: 
   I'm hoping somebody can do a step by step how to for the dsa815 with the latest FW version, as I am not up to speed on hacking although I can apply and follow directions.    Thanks again to all on here

If you are already getting it, then get it.  Go to the various web hosted key gens and try.  I see it as an added bonus, but it wouldn't have stopped us getting the equipment in the first place.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: radiogeek97 on September 10, 2014, 08:46:48 pm
Oh no definitely already got the quote. Just waiting on getting a P.O  :-DMM
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: rmd79 on September 11, 2014, 04:07:48 pm

Flatlander (and everyone else interested in the MSO1000Z series)..

Today I dumped the RAM from my MSO1074Z-S using an Olimex ARM-USB-OCD-H adapter and a JTAG cable I made using the information provided by sptm14.

I ran the "rigup" tool on the memory dump but it didn't find any keys.  However, I then went and manually searched for variations of what rigup was searching for, and found a section of the memory dump that seems to almost exactly match what rigup wants to see in order to extract the keys and resolve the private key.

In the rigup-0.4.zip, /src/ directory, there is a file called utils.c, which contains a function called ScanKeys().  It searches for the following pattern in the memory dump:

(hex):

02 00 84 00 10 00

I changed it to:

01 00 84 00 10 00

and then re-compiled and ran it on my memory dump, then I got this:

root@kali03:/home/rdavidson/rigup-0.4# ./rigup scan /root/mso1074z-s_64M_RAM.bin
rigup scan - Version 0.4

RC5KEY1:        057C2FCEFAD84E75AF393F05A13F8690
RC5KEY2:        23E24CFCA6FA196C89F3A9706BDA3689
XXTEAKEY:       D4AD754E348E9D2BF3C161517AE2CB04
PUBKEY:         005497018B62F230
PRIVKEY:        0099FC5DFBE778D0

I also ran "rigup search /root/mso1074z-s_64M_RAM.bin".  It spat out 6 keys, one of which looks obviously wrong/invalid, but I tried one of the more reasonable looking keys on my scope and got a message saying the key has already been used.  So, I believe I have 1 valid key (which might be a trial key, since my scope still has about 33 hours of its trial period left and I haven't purchased any upgrades, or maybe its a feature key for the Sig Gen or LA.  No idea!).

The key below, VZ2RCVM... is the key that rigup was able to find in my memory dump, and that the scope says has already been used.  This info below, I believe, is rigup validating the key, using the key info above:

root@kali03:/home/rdavidson/rigup-0.4# ./rigup info mso1074z-s.keys VZ2RCVM-ZK8ZY4L-_______-_______
rigup info - Version 0.4

License:        VZ2RCVM-ZK8ZY4L-_______-_______    (V2MP = 0x9ED6D)
Signature 1:    0000000000000000
Signature 2:    0000000000000000
Padding 1:      00000000A0EF87DE
Padding 2:      00000000743732CE
Verify:         Ok

All of the other keys it found do not verify (and I haven't tried inputting them into my scope yet, to see if they work there).

FYI: My MSO1074Z-S runs firmware version 00.04.01.SP2.  In the memory dump, the keys appear to be located at hex address 0x00E063AC.

I have not had any luck generating keys to unlock the features in the scope yet.

If anyone wants to give me a hand or has any ideas, let me know.  I'm not giving up yet, but its 2am here and I'm off to bed.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: conte_vlad on September 11, 2014, 04:33:10 pm
I apologize if I missed something but seems youi are using, that what I understood, the procedure writen for the DS-MSO2000 on DS-MSO1000 and I am not sure it is correct.

Go there

http://www.gotroot.ca/rigol/riglol/ (http://www.gotroot.ca/rigol/riglol/)

fill the field with your requested detail, read on section for DS1000, and try. I don't have the MSO1000 and never used it, but try.... O0
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: rmd79 on September 11, 2014, 04:51:18 pm

Hello conte_vlad,

I'm using a very similar procedure to the others, basically trying to go the route of dumping the memory, getting the keys and then generating licence keys.  There is nothing new about that, but I'm hoping that I've found the private key for the MSO1000Z series and that now I just need to find the 4-character feature codes.

I don't fully understand your post, the link is to a file on your hard drive.  If you are trying to ask me to try using the DS1000Z key generation feature in Riglol, then I can already tell you that it doesn't work with the MSO1000Z series.  I tried that before going the JTAG route.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: conte_vlad on September 11, 2014, 05:15:50 pm
sorry, I corrected the link... :phew:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: rmd79 on September 11, 2014, 05:27:32 pm
sorry, I corrected the link... :phew:

Hello conte_vlad,

I've tried Riglol, but it doesn't produce valid license keys for my MSO1074Z-S.  After I opened up my MSO for the first time and saw that the board was labelled as DS1000Z main board, I tried the Riglol tool, but no luck.  I'm fairly sure that I've read somewhere in this massive thread that the Riglol tool can't produce valid keys for the MSO1000Z series yet, so its no surprise that it didn't work.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hematose on September 12, 2014, 02:18:06 am
rmd,

Thank you very much for taking this important step! The fact that you got one key that didn't error suggests that we really do have the private key now.

I'll try and go back to take a look at the 4-character codes for the other scopes.

Looking forward to hearing more!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: rmd79 on September 12, 2014, 02:45:34 am
Looking forward to hearing more!

Thanks,

I'm still working on this, I have a couple of concerns at the moment.  Those are:

1. Both the PUBKEY and PRIVKEY start with 0x00, which I find odd.  It might be perfectly fine/normal, but I'm not sure yet.  Looks like thats normal based on other posts.

2. The PRIVKEY is 16 characters long, but the web version of Riglol only seems to accept 14-character private keys.  Seems normal, I guess we drop the 0x00 from the beginning of the key.

3. The serial number of my MSO1074Z-S is 14 characters long, the serials of the DS2 series seem to be 13 characters long (going by what I see in the code).

FWIW, I'm working with the rigup-0.4.zip codebase and the riglol that it contains, not the web version.  I'm just noting some issues here that I've come across so far, kind of in the hope that someone can chime in on them and maybe help out a little.

I'm also considering purchasing a license for my scope just to see if I can find the option code and maybe validate that the private key is correct.  The reason I have some concerns is that I can't get Riglol to re-produce this license key:

VZ2RCVM-ZK8ZY4L-_______-_______    (V2MP = 0x9ED6D)

I would have thought that if everything was working correctly, I could run something like:

./rigup riglol DS1ZDxxxxxxxxx V2MP

and then get the same license key as above, however the key that it generates is completely different.

EDIT: I should mention that I've added, what I think may be the private key for the MSO1000Z series into my copy of rigup/riglol, otherwise the above would just error out.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Vtech on September 12, 2014, 06:40:23 am
Hi rmd79,

You won't be able to generate the same license key as original rigol key. Key generation algorithm uses seed number (k_offset in riglol code). Riglol code sets this number to 0 but genuine Rigol licenses seems to be using true random numbers. Two valid licenses for the same option and serial number can have totally different value.

Buying license also wouldn't help because Rigol doesn't give option codes. They give you 16 character code that you have to enter on their website along with serial number of your unit and in response you get the license key.

Hope this helps
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: rmd79 on September 12, 2014, 07:21:41 am
Hi Vtech,

Thanks for the info :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: rmd79 on September 12, 2014, 12:04:51 pm
Vtech,

I forgot to mention, the reason I was thinking about buying an official license for an option in my scope was because I think I might be able to deduce the option code by running the official key through the rigup "info" command, which I've previously done with the official trial key in my scope.  The info command verified the key as OK and also spat out what looks like a option code (V2MP).

So I was thinking I might be able to get a non-trial option code that way, and maybe work from there.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Circlotron on September 12, 2014, 01:31:19 pm
Who here is going to be enterprising enough to produce a front panel RIGLOL sticker available to all of us with suitably hacked scopes?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hematose on September 12, 2014, 09:08:29 pm
I can confirm that using DSAE and other option codes on my MSO1074Z with this private key (trimmed the leading two zeros) does not work.

I'd be surprised if it was the option codes that were the problem though. The format seems to be pretty similar between the other scopes.

Maybe what is going on is that the LA functions are implemented as a special option so that there's another free bit that needs to be set to work with the MSO scopes?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: rmd79 on September 13, 2014, 08:26:50 am

I think its fairly certain that the keys being generated by riglol are not going to work without some further changes somewhere.

Running './rigup info mso1074z-s.keys <key>" on a key that my scope accepts works and the key can be verified as OK.

Running the same command on a key generated by riglol (modified with the private key I found earlier) does not work, and my scope won't accept them either.  So, it looks like the keys can be verified but not created at the moment.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on September 13, 2014, 11:20:12 pm
I posted the following new Rigol 2014 manuals:

  DP800 2014 Calibration Guide.pdf
is at >  https://www.eevblog.com/forum/testgear/rigol-dp832-firmware-updates-and-bug-list/msg512521/#msg512521 (https://www.eevblog.com/forum/testgear/rigol-dp832-firmware-updates-and-bug-list/msg512521/#msg512521)

  DP800 Performance Verification Manual.pdf
is at >  http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-050d/1/-/-/-/-/DP800%20Performance%20Verification%20Guide.pdf (http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-050d/1/-/-/-/-/DP800%20Performance%20Verification%20Guide.pdf)

  DSA800 Programming Guide PDF
ia at >  http://www.filedropper.com/dsa800programmingguidepdf (http://www.filedropper.com/dsa800programmingguidepdf)

  DG4000 Calibration Guide.pdf
is at >  https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg512569/#msg512569 (https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg512569/#msg512569)

  DG4000 Performance Verification Guide.pdf
is at >  https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg512565/#msg512565 (https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg512565/#msg512565)

  DSA815 Service Guide.pdf
is at >  https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg512514/#msg512514 (https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg512514/#msg512514)

  DSA815 Performance Verification Guide.pdf
is at >  https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg512933/#msg512933 (https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg512933/#msg512933)   

  DSA815 10MHz Clock Frequency Adjustment.pdf (10MHz Frequency Standard)  Note: This procedure is not new.
is at >  https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg512575/#msg512575 (https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg512575/#msg512575)

  DS2000 Performance Verification Guide.pdf:
is at >  http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-04ce/1/-/-/-/-/DS2000%20Performance%20Verification%20Guide.pdf (http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-04ce/1/-/-/-/-/DS2000%20Performance%20Verification%20Guide.pdf)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on September 15, 2014, 02:06:54 am
Installing DSA815 Options on units with firmware 00.01.09.00.07 and with BOOT Loader 03.
.
Note:  This will NOT work with units supplied from Rigol with Pre-installed .09 FW and Boot Loader .04.

Go to >  https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg513125/#msg513125 (https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg513125/#msg513125)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Vtech on September 15, 2014, 07:20:53 am
Quote
Running the same command on a key generated by riglol (modified with the private key I found earlier) does not work, and my scope won't accept them either.  So, it looks like the keys can be verified but not created at the moment.

That is very odd. It is basically the same algorithm running in two ways - it encrypts the data when it creates the license key and it decrypts it when it runs the info command on a key. I think it must work. I mean when it produces the key using a set of data (serial number, option code and encryption keys) it has to be able to decrypt it using the same set of encryption keys. If it doesn't it means that something is messed up in riglol code.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: rmd79 on September 15, 2014, 09:57:15 am
Yeah I thought it was odd as well.

I've attached some patches of the rigup-0.4 and riglol-20140717 code that I've been modifying.  Actually, the patches are not the code I've been working on, since thats a bit of a mess now, they are just the basics that would get anyone else to the same point I'm currently at.

So, with the patches you can use "rigup scan" to scan the MSO1000Z memory dump for the keys and generate the key file.  it should find the keys and also the serial number.  The riglol patch just adds the private key into riglol and makes riglol recognise the MSO1000Z serial number (which in my case begins with "DS1ZD", and I'm assuming they all do).

If there is someone here who wants to look further into this, I could provide the portion of my scope's memory dump containing the keys (or the whole thing), as well as the key file generated by "rigup scan", the valid license key that my scope accepts and that "rigup info" can verify as OK, and anything else you need.  Just PM me via the forum.

The point at where things may have gone wrong could be the code that breaks the public key and solves the private key.  I'm thinking that if "rigup info" can decode a valid key using the public key retrieved by "rigup scan", then it would make sense that if the code that calculates the private key is getting it wrong, riglol would not be able to produce a valid key.

I don't know how to go about verifying whether to not thats the case.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ibraheem on September 15, 2014, 08:01:13 pm
Hi! Amazing thread.. I read the first 50 pages or so for an insight, and tried searching through for an answer but I don't think it's been addressed.

Seems like there's a "new" DS1054Z model to the DS1000Z series, cheaper than the DS1074Z, has anyone used one and unlocked the DS1000Z range optional features?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Strada916 on September 15, 2014, 08:49:24 pm
Ds1074z yes.  Find the riglol Web site in this thread. Enter serial number and option and pesto.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ibraheem on September 15, 2014, 09:19:17 pm
Ds1074z yes.  Find the riglol Web site in this thread. Enter serial number and option and pesto.

Yes I saw that, but I'm referring to the "new" DS1054Z (marketed as 50MHz):
http://www.rigol-uk.co.uk/Rigol-Digital-Oscilloscope-DS1054Z-p/ds1054z.htm#.VBcdkvldX_t (http://www.rigol-uk.co.uk/Rigol-Digital-Oscilloscope-DS1054Z-p/ds1054z.htm#.VBcdkvldX_t)

I would think it should work the same as the DS1074Z and the rest of the DS1000Z series (???) but would like to see if anyone has actually tried it?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Strada916 on September 15, 2014, 09:21:58 pm
Since its new. Maybe not.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: leppie on September 16, 2014, 05:19:16 am
At over 100 pounds cheaper (perhaps translated to ~$150) the DS1054Z would be a real bargain if hackable.  :-+

Edit: $399 at tequipment!!! Even cheaper http://www.tequipment.net/Rigol/DS1054Z/Digital-Oscilloscopes/ (http://www.tequipment.net/Rigol/DS1054Z/Digital-Oscilloscopes/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ibraheem on September 16, 2014, 09:51:21 am
At over 100 pounds cheaper (perhaps translated to ~$150) the DS1054Z would be a real bargain if hackable.  :-+

Edit: $399 at tequipment!!! Even cheaper http://www.tequipment.net/Rigol/DS1054Z/Digital-Oscilloscopes/ (http://www.tequipment.net/Rigol/DS1054Z/Digital-Oscilloscopes/)

Yup I think it's worth a punt, going to put in an order and see what happens. This will be my first oscilloscope!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gandalf_Sr on September 16, 2014, 09:55:11 am
At over 100 pounds cheaper (perhaps translated to ~$150) the DS1054Z would be a real bargain if hackable.  :-+

Edit: $399 at tequipment!!! Even cheaper http://www.tequipment.net/Rigol/DS1054Z/Digital-Oscilloscopes/ (http://www.tequipment.net/Rigol/DS1054Z/Digital-Oscilloscopes/)

Don't forget that you can get 6% discount using the EEV Blog code.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: leppie on September 16, 2014, 03:04:41 pm
I just ordered one too :) Even if not hackable, the features will complement my old 200MHz TDS well.  ^-^
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Jog on September 17, 2014, 11:11:10 am
Hello together,

sorry I am absolutly new but I hope I get help here. I bought a new DS2072a and try to "update" it into a ds2302a with all options, but without any success.

a) the firmware is 00.03. sp1 (from delievery on) so I can't downgrade into the 00.02. for the windows based upgrade (*IDN? with all info) = I became only the SN in 13! not 14 digits and nothing else.
b) rigkey under linux can only generate a key with a 14 digit SN (if I add a 0 at the end, it dosn't help and also the option DSA9) will not accepted due to his lenght and that because it fits?!

I work now since 2 days on a possibility and see no further possibilities  :'(

For every hints I'm very thankeful!

many thanks if anybody can help!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on September 17, 2014, 12:34:15 pm
At over 100 pounds cheaper (perhaps translated to ~$150) the DS1054Z would be a real bargain if hackable.  :-+

Edit: $399 at tequipment!!! Even cheaper http://www.tequipment.net/Rigol/DS1054Z/Digital-Oscilloscopes/ (http://www.tequipment.net/Rigol/DS1054Z/Digital-Oscilloscopes/)

A 4-channel scope, especially with the performance of the 1000z-series, is really mind-boggling at that price-point!  That becomes a no-brainer for those on a limited budget, looking for whatever they can find at a low price... unless they're sure they'll never need more than 2-channels, and are strapped for very dinero.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: poorchava on September 20, 2014, 12:01:50 pm
Hi, I'm thinking about purchasing DS1054 or DS1074 and obviously "upgrading" it. I am aware of the Riglol tool, but it needs a private key. I went through all the posts in this topic, but all this is greatly confusing.

In the end: what are the missing steps for upgrading the scope in the sequence below?

-upgrade FW to latest version
-read serial of the device
-get private key
-input serial and desired options into Riglol tool
-enjoy!

Does getting the private key still involve taking scope apart and dumping memory? I haven't seen any post that would say otherwise, but I just wanted to make sure.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: frenky on September 20, 2014, 12:39:32 pm
Quote
1. Type in your unit's Serial Number.
2. Type in DSER for all options without the 500µV. This Option may not be in the Keygen's list, but it will work!
3. Do NOT enter anything for 'Privatekey', it will be inserted automatically for you (based on the DS1000z).
4. Press [GENERATE], and record the resulting Option Code.
5. When you are done enter the Option Code manually in the DS1000z using a single string without using any 'dash' (-) using Rigol's Procedure for activating the Trial Options in the D1000z.
https://www.eevblog.com/forum/testgear/is-rigol-ds1074z-hackable-to-increase-bandwidth-to-100/msg499411/#msg499411 (https://www.eevblog.com/forum/testgear/is-rigol-ds1074z-hackable-to-increase-bandwidth-to-100/msg499411/#msg499411)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PepeK on September 20, 2014, 08:25:31 pm
Hello together,

sorry I am absolutly new but I hope I get help here. I bought a new DS2072a and try to "update" it into a ds2302a with all options, but without any success.

a) the firmware is 00.03. sp1 (from delievery on) so I can't downgrade into the 00.02. for the windows based upgrade (*IDN? with all info) = I became only the SN in 13! not 14 digits and nothing else.
b) rigkey under linux can only generate a key with a 14 digit SN (if I add a 0 at the end, it dosn't help and also the option DSA9) will not accepted due to his lenght and that because it fits?!

I work now since 2 days on a possibility and see no further possibilities  :'(

For every hints I'm very thankeful!

many thanks if anybody can help!

Read this : https://www.eevblog.com/forum/testgear/rigol-mso2000-series-hacking/?topicseen (https://www.eevblog.com/forum/testgear/rigol-mso2000-series-hacking/?topicseen)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: exciler on September 21, 2014, 08:38:31 am
Hi!

Just got a DS1054Z yesterday from Batronix (in Germany) for 299 EUR (excl. Tax). Numbers are working ;)
So I think it is very good value for the money, highly recommend it.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Magnum on September 21, 2014, 03:07:16 pm
Hi!

Just got a DS1054Z yesterday from Batronix (in Germany) for 299 EUR (excl. Tax). Numbers are working ;)
So I think it is very good value for the money, highly recommend it.
I ordered one from Batronix, too. Which firmware version do you have on yours?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: poorchava on September 21, 2014, 06:56:01 pm
So it's upgradeable to 100MHz?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: exciler on September 21, 2014, 10:35:13 pm
So it's upgradeable to 100MHz?
At least it accepts the code, haven´t tested a 100 MHz signal yet.

Hi!

Just got a DS1054Z yesterday from Batronix (in Germany) for 299 EUR (excl. Tax). Numbers are working ;)
So I think it is very good value for the money, highly recommend it.
I ordered one from Batronix, too. Which firmware version do you have on yours?
Need to check that tomorrow, but as the DS1054Z is pretty new, I do not expect any difference.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ibraheem on September 22, 2014, 02:22:47 pm
Brilliant! I should be receiving mine tomorrow so will post up results.

Based on the past few posts I'm under the impression the code to use is still DSER (i.e. it's still not a good idea to install the 500uV option?)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: exciler on September 23, 2014, 06:46:36 am
FYI: My DS1054Z has FW 00.04.01.SP2
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Magnum on September 23, 2014, 12:56:23 pm
FYI: My DS1054Z has FW 00.04.01.SP2
Thanks. Hopefully I'll receive mine tomorrow.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: farzadb82 on September 23, 2014, 02:57:16 pm
FYI: My DS1054Z has FW 00.04.01.SP2

Have you tried using the DS1000z hacks as yet ?  If so, do they work ?

I'm curious because I have the MSO1074Z-S and none of the DS1000Z hacks currently work. Prior to getting the MSO1074Z-S, I had a DS1074Z-S with the older 00.04.00 (I think) firmware and the hacks did work on that scope. I'm suspecting that the firmware image is the same for all DS/MSO1000Z models. From what I can tell, by looking at the firmware image I have, they have changed the way the license keys are generated in 00.04.01.SP2.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Magnum on September 24, 2014, 12:32:17 pm
FYI: My DS1054Z has FW 00.04.01.SP2
Same firmware here, codes work.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: toni31 on September 24, 2014, 01:31:23 pm
i think a new thread for 1054z it helps
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pierre288 on September 25, 2014, 11:31:15 am
Hi,
I recently got a  MSO1074Z-S which is at version 00.04.01.SP2
I tried to add features but did not work either for me.

Any hope to get a rigol utility update soon ?

thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: rmd79 on September 25, 2014, 11:46:17 am
Hi,
I recently got a  MSO1074Z-S which is at version 00.04.01.SP2
I tried to add features but did not work either for me.

Any hope to get a rigol utility update soon ?

thanks

I've got a memory dump of my MSO1074Z-S if anyone wants to have a look into it.  PM me if you're interested.  Its about 8MB compressed.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on September 25, 2014, 09:33:13 pm
There was a time when the DS2302 (300MHz) mode was buggy with the 00.02.01.00.03 firmware.  Did the 00.03.00.01.03 version correct the issues?  Is there a downside to running it as a ds2302 compared to a ds2202 any longer?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on September 26, 2014, 08:26:38 am
I've got a memory dump of my MSO1074Z-S if anyone wants to have a look into it.  PM me if you're interested.  Its about 8MB compressed.

Your serial number starts with "DS1ZD" and my serial with "DS1ZC". The following six numbers are the same, except for the last three numbers.
I suppose the "D" is for the model with the signal generator (MSO1074Z-S) and the "C" is for the model without sig-gen (MSO1074Z).

 :-/O
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gandalf_Sr on September 26, 2014, 01:15:11 pm
There was a time when the DS2302 (300MHz) mode was buggy with the 00.02.01.00.03 firmware.  Did the 00.03.00.01.03 version correct the issues?  Is there a downside to running it as a ds2302 compared to a ds2202 any longer?

I 'upgraded' my MSO2072A to a MSO2302A; so far I have had no issues.  The I2C decode seems slow, you can't look at the decode real time, you have to capture a single shot and then you can see it go past doing the decode.  In this respect, having such a large memory is clearly an advantage, I have a Tektronix MDO2024 at work and it's annoying that you can capture a section of I2C with decode but when you start scrolling through the message chain, it quickly craps out because it's run out of memory.  I'll check on the software versions on my MSO2302A and update this post.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bistopepmol on September 27, 2014, 02:03:11 am
Hey there,

Got my new scope a couple of days ago,  DS2072A ( to replace my Poorly Tektronix 2430a (trig fault) ) Hardware ver 1.0.2.0.2 and firmware 00.03.00.01.03, I followed the great posts on here and now I have a DS2302 and all is well, thank you so much guys for the brilliant posts,  :-+  :-+ 

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on September 27, 2014, 11:47:03 pm
I 'upgraded' my MSO2072A to a MSO2302A; so far I have had no issues.  The I2C decode seems slow, you can't look at the decode real time, you have to capture a single shot and then you can see it go past doing the decode.  In this respect, having such a large memory is clearly an advantage, I have a Tektronix MDO2024 at work and it's annoying that you can capture a section of I2C with decode but when you start scrolling through the message chain, it quickly craps out because it's run out of memory.  I'll check on the software versions on my MSO2302A and update this post.

Thanks for the info, anyone else, especially those running earlier DS2072 hardware versions having good or bad luck with the 2302 mode with FW 00.03.00.01.03?

Also, I thought I saw discussion about upgrading the bootloader and being unable to downgrade below certain firmware or something.  Was that for the DS2000 series or something else?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Jog on September 28, 2014, 09:49:05 am
Hi together,

good news & bad news.... |O

Scope DS2072a FW 03. SP1, HW2.0

Memory dump with: echo :SYST:UTIL:READ? 15441920,13262848 | ncat -i 1 SCOPE_ADDRESS_HERE 5555 > DS2072A_sdram.bin
works fine. 12,9MB. :-+

rigup DS2072A DS2072A_sdram.bin > opt.txt
works also fine and generates 4 different keys (only all options, 100MHz full option, 200 & 300) and I try all but they sems not to fit.
PS: also rigup scan DS2072A_sdram.bin > ec_decoded.txt works also fine an generates valid entries :-+

BUT entering the key over:
a) Scope directly = 0 reaction
b) over Ultra Sigma SCPI command ":SYSTem:OPTion:INSTall key" = 0 reaction
c) over Ncat via LAN "echo :SYST:OPT:INSTALL A_KEY_FROM_OPTIONS_WITHOUT_DASHES | ncat -i 1 SCOPE_ADDRESS_HERE 5555" = also 0 reaction

 :(

Any ideas/hints why it fails?

Update: Scope was blocked by to many false tries to enter unknown Options. After factory reset (multipress left gray button #6 multiple during booting) and retry to enter generated keys

 :D :D :D :D IT works!  ;D ;D ;D ;D

many thanks to all!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gandalf_Sr on September 28, 2014, 11:28:09 am
@Jog

Glad to hear you got your DS2072A 'upgraded', I was unaware of the factory reset procedure until you posted it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: farzadb82 on September 29, 2014, 02:51:21 am
Hi together,

good news & bad news.... |O

Scope DS2072a FW 03. SP1, HW2.0

Memory dump with: echo :SYST:UTIL:READ? 15441920,13262848 | ncat -i 1 SCOPE_ADDRESS_HERE 5555 > DS2072A_sdram.bin
works fine. 12,9MB. :-+

rigup DS2072A DS2072A_sdram.bin > opt.txt
works also fine and generates 4 different keys (only all options, 100MHz full option, 200 & 300) and I try all but they sems not to fit.
PS: also rigup scan DS2072A_sdram.bin > ec_decoded.txt works also fine an generates valid entries :-+

BUT entering the key over:
a) Scope directly = 0 reaction
b) over Ultra Sigma SCPI command ":SYSTem:OPTion:INSTall key" = 0 reaction
c) over Ncat via LAN "echo :SYST:OPT:INSTALL A_KEY_FROM_OPTIONS_WITHOUT_DASHES | ncat -i 1 SCOPE_ADDRESS_HERE 5555" = also 0 reaction

 :(

Any ideas/hints why it fails?

Update: Scope was blocked by to many false tries to enter unknown Options. After factory reset (multipress left gray button #6 multiple during booting) and retry to enter generated keys

 :D :D :D :D IT works!  ;D ;D ;D ;D

many thanks to all!

Hi Jog. Do you know if the factory reset procedure is the same for all Rigol scopes ?  I have a MSO1074Z-S scope and I keep getting a message that states I'm unable to enter any more keys for 12 hours.


-- Farzad
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Jog on September 29, 2014, 02:53:19 pm
Hi, I am not sure but I found it  as pdf on the rigol hp directly. You can search. Rg Jog
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: LoyalServant on September 29, 2014, 06:39:40 pm
This method worked for me with a tweak, see below....

Hi together,

good news & bad news.... |O

Scope DS2072a FW 03. SP1, HW2.0

Memory dump with: echo :SYST:UTIL:READ? 15441920,13262848 | ncat -i 1 SCOPE_ADDRESS_HERE 5555 > DS2072A_sdram.bin
works fine. 12,9MB. :-+

rigup DS2072A DS2072A_sdram.bin > opt.txt
works also fine and generates 4 different keys (only all options, 100MHz full option, 200 & 300) and I try all but they sems not to fit.
PS: also rigup scan DS2072A_sdram.bin > ec_decoded.txt works also fine an generates valid entries :-+

BUT entering the key over:
a) Scope directly = 0 reaction
b) over Ultra Sigma SCPI command ":SYSTem:OPTion:INSTall key" = 0 reaction
c) over Ncat via LAN "echo :SYST:OPT:INSTALL A_KEY_FROM_OPTIONS_WITHOUT_DASHES | ncat -i 1 SCOPE_ADDRESS_HERE 5555" = also 0 reaction

 :(

Any ideas/hints why it fails?

Update: Scope was blocked by to many false tries to enter unknown Options. After factory reset (multipress left gray button #6 multiple during booting) and retry to enter generated keys

 :D :D :D :D IT works!  ;D ;D ;D ;D

many thanks to all!

One small tweak:
I changed...
Quote
echo :SYST:UTIL:READ? 15441920,13262848 | ncat -i 1 SCOPE_ADDRESS_HERE 5555 > DS2072A_sdram.bin
To:
Quote
echo :SYST:UTIL:READ? 15441920,13262848 | ncat -i 1s SCOPE_ADDRESS_HERE 5555 > DS2072A_sdram.bin

The scope is not answering fast enough for some reason so ncat was dropping an empty file.

Confirming the 300Mhz key did NOT work for me.
The output of rigup said it was untested and unconfirmed.. so confirming at least for me it was a no go.
The 200Mhz key did work.

Cheers guys.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Jog on September 30, 2014, 04:26:43 am
Hi Rf, normaly not necessary to change the ncat -i 1 to 1s because -i stands for idle time. For me it was no different because the file size was the same. But know you have a 200mhz. Have fun
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: LoyalServant on September 30, 2014, 04:00:30 pm
Hi Rf, normaly not necessary to change the ncat -i 1 to 1s because -i stands for idle time. For me it was no different because the file size was the same. But know you have a 200mhz. Have fun

Yes, it is the idle time... but the -i option without any additional parameters is assumed to be milliseconds.
That means ncat needs to have some data coming at it within 1 millisecond.... that's cutting it close which is why I had trouble.
Just posted for others that might not know what ncat is or how to use it.

I am curious about the feature that Rigol has in this scope to dump the ram like that...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Fungus on September 30, 2014, 05:30:25 pm
Quote
After factory reset (multipress left gray button #6 multiple during booting) and retry to enter generated keys...

Is there a secret 'reset' button like this for the DS1000Z ?

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: farzadb82 on September 30, 2014, 06:36:26 pm
Quote
After factory reset (multipress left gray button #6 multiple during booting) and retry to enter generated keys...

Is there a secret 'reset' button like this for the DS1000Z ?

Unfortunately, there's nothing "officially" documented, that I was able to find. I attempted the procedure above, but had no success.

Without any official documentation or insider information, I think the only way to discover or find features like this would be to disassemble the firmware image and trace code paths. I'm taking a stab at this right now, but have a steep learning curve ahead.


-- Farzad
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gixy on October 01, 2014, 04:31:27 pm
http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-02f4/1/-/-/-/-/file.pdf (http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-02f4/1/-/-/-/-/file.pdf)

Reset procedure for DS2000/4000/6000, to be confirmed for DS1000 series.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: seronday on October 03, 2014, 12:52:52 pm
DS4000 series Bandwidth (model type) Option Codes.

For those who have an interest in the DS4000, I have found the option codes for selecting the bandwidth .
This also sets the model type.

For example the code FAB9 will select 500Mhz, (DS405x), with all Decoders enabled.

The attached file contains all the details.

There are also two un-documented, possibly future, options called "Power Analysis" and "MA".

The option codes have been tested with firmware ver 00.02.00.00.04 and ver 00.02.01.00.03.

*EDIT*
 Attached updated PDF document to include the option selection codes for LIN and 1553B decode.
Also included are two possible future options,  Power Analysis and I2S decode.
Power Analysis has been listed for some time, but the I2S decode is relatively recent.
The original un-documented "MA" option has become the 1553B decode option.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gallymimus on October 03, 2014, 01:21:52 pm
Well thats cool, how did you find these extra ds4000 options? Why do you think they weren't discovered before?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Fungus on October 03, 2014, 03:58:14 pm
Quote
After factory reset (multipress left gray button #6 multiple during booting) and retry to enter generated keys...

Is there a secret 'reset' button like this for the DS1000Z ?

Unfortunately, there's nothing "officially" documented, that I was able to find. I attempted the procedure above, but had no success.

I tried the above and it reset all the options and went back to Chinese (seems just like "Storage->Default" but it resets the language as well).

Luckily it starts up in a state where it says "Language" on the menu...easy to go to a different language.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: farzadb82 on October 03, 2014, 04:15:42 pm
Quote
After factory reset (multipress left gray button #6 multiple during booting) and retry to enter generated keys...

Is there a secret 'reset' button like this for the DS1000Z ?

Unfortunately, there's nothing "officially" documented, that I was able to find. I attempted the procedure above, but had no success.

I tried the above and it reset all the options and went back to Chinese (seems just like "Storage->Default" but it resets the language as well).

Luckily it starts up in a state where it says "Language" on the menu...easy to go to a different language.

I tried the procedure on my MSO1000Z and ended up with a constant beeping noise (as if I'd pressed the button too many times), but no reset. It's possible that I did something incorrectly. I'll give it another shot tonight after work.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on October 03, 2014, 05:37:51 pm
I tried the procedure on my MSO1000Z and ended up with a constant beeping noise (as if I'd pressed the button too many times), but no reset. It's possible that I did something incorrectly. I'll give it another shot tonight after work.

It is the 5th gray button on the left (not the bottom gray button).  When you press it during power on it will beep a couple of times until the Rigol screen comes up.  Keep pressing it.  You'll know it worked when you see Chinese!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gallymimus on October 03, 2014, 05:59:49 pm
DS4000 series Bandwidth (model type) Option Codes.

For those who have an interest in the DS4000, I have found the option codes for selecting the bandwidth .
This also sets the model type.

For example the code FAB9 will select 500Mhz, (DS405x), with all Decoders enabled.

The attached file contains all the details.

There are also two un-documented, possibly future, options called "Power Analysis" and "MA".

The option codes have been tested with firmware ver 00.02.00.00.04 and ver 00.02.01.00.03.

This was tested and is confirmed working BTW.  You can eliminate the need for Mr Krabs modified firmware and stick with stock stock firmware.  Bandwidth was NOT tested, but time base and system info look correct for 500MHz
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cap4096 on October 04, 2014, 11:09:23 pm
DS4000 series Bandwidth (model type) Option Codes.

For those who have an interest in the DS4000, I have found the option codes for selecting the bandwidth .
This also sets the model type.

For example the code FAB9 will select 500Mhz, (DS405x), with all Decoders enabled.

The attached file contains all the details.

There are also two un-documented, possibly future, options called "Power Analysis" and "MA".

The option codes have been tested with firmware ver 00.02.00.00.04 and ver 00.02.01.00.03.


I have a question: Does this work on a Rigol MSO4014?

/Cap4096

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: seronday on October 04, 2014, 11:58:17 pm
If it is using one of the Firmware versions mentioned, then , Yes.

Try it and report back.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cap4096 on October 05, 2014, 12:41:23 am
If it is using one of the Firmware versions mentioned, then , Yes.

Try it and report back.

Well I have to order it before trying :-) I will probably do that on monday.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on October 08, 2014, 12:20:46 pm
Ultra Power Analyzer software for the DS2000, DS4000, and MSO4000 series O'Scopes: https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg525924/#msg525924 (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg525924/#msg525924)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on October 08, 2014, 05:30:11 pm
Ultra Power Analyzer software for the DS2000, DS4000, and MSO4000 series O'Scopes:
Yes the Software is available, and it looks like there may be a Key to enable it with the dso. Has anyone seen any codes in the firmware???
The "Power Analysis" option is listed in "DS4000 Option Codes.pdf" uploaded to this topic by seronday just a few days ago: https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg523679/#msg523679 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg523679/#msg523679)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Howardlong on October 15, 2014, 06:36:54 pm
I tried the procedure on my MSO1000Z and ended up with a constant beeping noise (as if I'd pressed the button too many times), but no reset. It's possible that I did something incorrectly. I'll give it another shot tonight after work.

It is the 5th gray button on the left (not the bottom gray button).  When you press it during power on it will beep a couple of times until the Rigol screen comes up.  Keep pressing it.  You'll know it worked when you see Chinese!

I confirm that this works, but you need to start pressing the 5th grey button on the left within a few milliseconds after you switch on.

(To change language from Chinese, press the Utility button -> select Language).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: rmd79 on October 17, 2014, 12:09:04 am
Hello,

Could someone please post a key file (without the serial number is fine) generated with "rigup scan ..." from a memory dump of a DS1000Z series scope?

I've tried searching the forum and with Google but haven't had any luck.

Thanks.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: rmd79 on October 17, 2014, 01:15:26 am
Search within eevblog.
https://www.eevblog.com/forum/testgear/ds1000z-serie-unlocking/msg491026/#msg491026 (https://www.eevblog.com/forum/testgear/ds1000z-serie-unlocking/msg491026/#msg491026)

The info I'm looking for doesn't seem to be there.

I'm looking for the DS1000Z equivalent of the key file, so the following info:

RC5KEY1:        ...
RC5KEY2:        ...
XXTEAKEY:       ...
PUBKEY:         ...
PRIVKEY:        ...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: rmd79 on October 17, 2014, 02:57:56 am
Is this search it. maybe not private (scroll)
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg362575/#msg362575 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg362575/#msg362575)

Thats basically what I'm looking for, except for the DS1000Z series (the code you linked to looks like its for the DS2000 series).
Title: DS and MSO1000Z option codes
Post by: sptm14a on October 17, 2014, 04:50:09 am
Here is a list of all 8 option codes for DS/MSO1000Z (firmware 00.04.01.SP2):

CSAR Triggers
CSAB Decoders
CSA3 Memory Depth
CSAJ Recorder
CSRA 500uV Vertical
CSAS ?
CSBA ?
CS3A ?

These are "official" options. "Trial" options start with "V", i.e. VSAR == Triggers trial

Plugging these into current versions of rigup/riglol won't work because Rigol slightly changed license validation/generation algorithm and character translation tables. I updated the algorithm to make it work for me, but but I'd rather not release it untested.


Title: Re: DS and MSO1000Z option codes
Post by: farzadb82 on October 17, 2014, 01:29:39 pm
Here is a list of all 8 option codes for DS/MSO1000Z (firmware 00.04.01.SP2):

CSAR Triggers
CSAB Decoders
CSA3 Memory Depth
CSAJ Recorder
CSRA 500uV Vertical
CSAS ?
CSBA ?
CS3A ?

These are "official" options. "Trial" options start with "V", i.e. VSAR == Triggers trial

Plugging these into current versions of rigup/riglol won't work because Rigol slightly changed license validation/generation algorithm and character translation tables. I updated the algorithm to make it work for me, but but I'd rather not release it untested.

Thank you for passing along this info.

I have the MSO1000Z device and have been (unsuccessfully) trying to work out the new algorithm. I'd love to help test any changes that you may have or alternatively, if you could pass on more details on the algorithm changes, I'd be happy to integrate them into the keygen tools.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NZST205 on October 19, 2014, 06:07:33 pm
Can anyone please help me by advising what format I should be saving the SCPI dump in, should it be ASCII, byte-8bit, byte-16bit or byte-32bit. As ASCII it creates a small (about 200Kb, the other formats create files 300-500+Mb, another is the 28-32 Mb range mentioned.

When I rigup any of the the file it says no keys. perhaps I need to hit the Advanced Tab in Current Return Value screen or something as not matter what file I save they are either 8 or 16 kb, not the 32 Mb file I am expecting. I have tried the scan with both 1,133554432 and 1544190,13262848.

Scope is a DS2072A with 03.01.00.04 and HW 1.02.0.2 Manufactured August 2014.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on October 19, 2014, 08:34:41 pm
There's only four choices.  Try them all. 

It might be mentioned somewhere... Have you read the entire thread?  I know it's very long, but there's like ts of knowledge in it for someone willing to take the time.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NZST205 on October 19, 2014, 08:42:12 pm
Yep, been through it twice, and even downloaded this an other related threads and did a txt search but nothing that says what sort of format the file should be in or if the advanced tab is relevant.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Helder22 on October 19, 2014, 09:09:19 pm
Ok, so I tried unlocking my new MSO2072A (3.00 SP1, HV 2.2, SN DS2F1629*****) using the DS2000A Upgrade Utility, but that did not work, So now I guess I'm gonna have to use the JTAG memory dump method. I really didn't want to because I'm afraid of messing something up permanently, but I as far as I've seen there are currently no alternatives.
I've already read most of this HUGE thread, and I guess I can say I understand the basic logic of it all, but the specifics are a bit over my head.
 
So now I have to order a JTAG adapter (and wait weeks for it to arrive). Is there any difference which one I get? I'm not really looking for the cheapest one, but one that would make the process simpler and therefore reducing the chances of me bricking my beloved new scope.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: navzptc on October 19, 2014, 11:04:13 pm
Have a look at this forum, especially around message no. 189  ::)

You may find something to your advantage!

https://www.eevblog.com/forum/testgear/rigol-mso2000-series-hacking/msg506553/#msg506553 (https://www.eevblog.com/forum/testgear/rigol-mso2000-series-hacking/msg506553/#msg506553)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Helder22 on October 20, 2014, 12:28:04 am
Oh my, I think it worked! Thanks navzptc (and everyone else)!
I have a 32,768KB scpi file now!

 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Helder22 on October 20, 2014, 02:40:38 am
Unlocked!
Thanks to everyone who did all the real work in order to make this possible!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NZST205 on October 22, 2014, 07:58:08 am
Have a look at this forum, especially around message no. 189  ::)

You may find something to your advantage!

https://www.eevblog.com/forum/testgear/rigol-mso2000-series-hacking/msg506553/#msg506553 (https://www.eevblog.com/forum/testgear/rigol-mso2000-series-hacking/msg506553/#msg506553)

I can't seem to find what format to save the SCPI file in (of the 4 options). ASCII creates a 15kb file and the three byte formats saves files all over 200 MBs. Perhaps as I am running Windows 7 Ultimate un Parallels it may be mucking things up. Can anyone please provide me with some guidance ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on October 22, 2014, 08:52:28 am
Have a look at this forum, especially around message no. 189  ::)

You may find something to your advantage!

https://www.eevblog.com/forum/testgear/rigol-mso2000-series-hacking/msg506553/#msg506553 (https://www.eevblog.com/forum/testgear/rigol-mso2000-series-hacking/msg506553/#msg506553)

I can't seem to find what format to save the SCPI file in (of the 4 options). ASCII creates a 15kb file and the three byte formats saves files all over 200 MBs. Perhaps as I am running Windows 7 Ultimate un Parallels it may be mucking things up. Can anyone please provide me with some guidance ?
Probably better to ask in the topic where SCPI memory dump is discussed in detail, to keep the information about this method in one place: https://www.eevblog.com/forum/testgear/rigol-mso2000-series-hacking/msg508898/#msg508898 (https://www.eevblog.com/forum/testgear/rigol-mso2000-series-hacking/msg508898/#msg508898)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: akisnas on October 25, 2014, 09:50:28 am
http://pastebin.com/ghYHnCfT (http://pastebin.com/ghYHnCfT)
It would not have happened without:
The jtag firmware dump from DL5TOR
ecc help from some guy
Coding by Cybernet
Testing by Marc M.
I find it very selfless to release all your work for everyone to freely use. Good on all of you  :clap: :-+

Very nice job guys, I'd like to ask you about this link http://pastebin.com/ghYHnCfT (http://pastebin.com/ghYHnCfT) it's an old & not working, is there anybody can help to find the files, or to help to unlock the options & 10 Hz RBW for a DSA815TG?
Best Regards
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on October 25, 2014, 10:33:29 am
or to help to unlock the options & 10 Hz RBW for a DSA815TG?
Use the online Riglol keygen.

Original: http://riglol.3owl.com (http://riglol.3owl.com)
Canadian mirror: http://gotroot.ca/rigol/riglol/ (http://gotroot.ca/rigol/riglol/)
UK mirror: http://rigol.avotronics.co.uk/mirrors/riglol/ (http://rigol.avotronics.co.uk/mirrors/riglol/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: akisnas on October 25, 2014, 07:26:08 pm
Thanks, I'll Check It, Is It Permanent?
Cheers.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on October 26, 2014, 11:31:44 am
Thanks, I'll Check It, Is It Permanent?
Cheers.
Yes as it says: "first character: A = official, S = trial".
Official = permanent.
Title: Re: DS and MSO1000Z option codes
Post by: hammy on October 26, 2014, 05:16:59 pm
Here is a list of all 8 option codes for DS/MSO1000Z (firmware 00.04.01.SP2):

CSAR Triggers
CSAB Decoders
CSA3 Memory Depth
CSAJ Recorder
CSRA 500uV Vertical
CSAS ?
CSBA ?
CS3A ?

These are "official" options. "Trial" options start with "V", i.e. VSAR == Triggers trial

Plugging these into current versions of rigup/riglol won't work because Rigol slightly changed license validation/generation algorithm and character translation tables. I updated the algorithm to make it work for me, but but I'd rather not release it untested.

Thank you for the info.  :clap: :-+
Is the MSO1000z and the DS1000z really using the same firmware?

Cheers
hammy
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on October 27, 2014, 02:27:48 am
Thanks, I'll Check It, Is It Permanent?
Cheers.

akisnas:

If you have a new DSA815 that you received with Firmware  00.01.09 ( 00.01.09.00.07) then you will NOT be able to install the Options at this time until someone comes up up a revised method for installing the Options.  Although if you have an earlier version Firmware (prior to 00.01.09), then the current Riglol Keygen (version 1.03c or 1.03d) will work fine for you.
You may want to go to  https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg513125/#msg513125 (https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg513125/#msg513125)  and read forward to understand this issue in more detail.  If you have any questions please feel free to contact me via a PM.
 
Title: Re: DS and MSO1000Z option codes
Post by: sptm14a on October 27, 2014, 04:58:43 am
Thank you for the info.  :clap: :-+
Is the MSO1000z and the DS1000z really using the same firmware?


I believe that Rigol uses unified firmware for all 1000 series, including 1104. The firmware behavior is defined by configuration resistors on the board.

The real question is whether or not the firmware validates licenses the same way for all 1000 series.  If somebody can dump memory from DS1074 or DS1054 with newest firmware, run the dump through rigup and PM me its output (or just share the dump), I can check by generating you a license.

Thanks to all MSO1074 testers -- no need for more testing on MSO, it works :)

Title: Re: DS and MSO1000Z option codes
Post by: hammy on October 27, 2014, 12:06:25 pm
Thanks to all MSO1074 testers -- no need for more testing on MSO, it works :)

sounds good!  :clap:
Thank you for the work you put into it!  :-+

This means it is time to make a memory dump and wait for the next riglol version on http://gotroot.ca/rigol/? (http://gotroot.ca/rigol/?)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hematose on October 27, 2014, 05:13:27 pm
So now that sptm14a has managed to upgrade the MSO1000Z, how do we get this into Riglol and the like? sptm14a, you said you didn't want to release it without testing. Would you like someone to test it for you? How can we continue your work?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: akisnas on October 27, 2014, 09:57:54 pm
Thanks, I'll Check It, Is It Permanent?
Cheers.

akisnas:

If you have a new DSA815 that you received with Firmware  00.01.09 ( 00.01.09.00.07) then you will NOT be able to install the Options at this time until someone comes up up a revised method for installing the Options.  Although if you have an earlier version Firmware (prior to 00.01.09), then the current Riglol Keygen (version 1.03c or 1.03d) will work fine for you.
You may want to go to  https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg513125/#msg513125 (https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg513125/#msg513125)  and read forward to understand this issue in more detail.  If you have any questions please feel free to contact me via a PM.
Thank You So Much For Your Reply, It Was Really Informative, I'll Try To Contact With You Via Pm When I'll Go To My Lab At The End Of Next Month.
Thanks All Of You.
Best Regards
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 0xdeadbeef on October 28, 2014, 07:20:35 pm
Just out of curiosity: is it expected that it will be possible to create keys for the MSO1000Z without dumping the flash (i.e. through entering the serial number)?
And if dumping is needed: does it require opening the case for a JTAG connection or is it also possible over SCPI like with the DS2000A/MSO2000A ("Bildschirmkopie")?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Howardlong on October 28, 2014, 08:44:35 pm
I couldn't get the SCPI commands to work on the MSO1000Z, I had to use a JTAG connector.

The process of extracting the dump itself took 15 minutes, once I knew what I was doing. Getting to that stage took an awful lot longer though!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on October 28, 2014, 08:51:18 pm
So now that sptm14a has managed to upgrade the MSO1000Z, how do we get this into Riglol and the like?
Try PM'ing studio25 (https://www.eevblog.com/forum/profile/?u=37760) and ask him nicely. He's the one who created Riglol and hosted it at 3owl.

The two other Riglol sites hosted by other members are just mirrors of studio25's Riglol site at 3owl:

Original made by studio25 (https://www.eevblog.com/forum/profile/?u=37760): http://riglol.3owl.com (http://riglol.3owl.com)
Canadian mirror hosted by ve7xen (https://www.eevblog.com/forum/profile/?u=17762): http://gotroot.ca/rigol/riglol/ (http://gotroot.ca/rigol/riglol/)
UK mirror hosted by Avotronics (https://www.eevblog.com/forum/profile/?u=89989): http://rigol.avotronics.co.uk/mirrors/riglol/ (http://rigol.avotronics.co.uk/mirrors/riglol/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Sparky on October 31, 2014, 07:19:13 am
Dear friends, I have in my possession an MSO2072A which "suffers" the problem of not being able to upgrade to 300 MHz.  When inputting the license key generated by rigup (with option NS8H) the MSO responds "License is unavailable!" (which is the usual message if you enter an incorrect code).  The 200 MHz key works fine.  This issue has been previously reported on DS2072A units; some posts are:
 
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg385319/#msg385319 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg385319/#msg385319)
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg414247/#msg414247 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg414247/#msg414247)
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg388809/#msg388809 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg388809/#msg388809)

I noticed the suggestion to try "all options + 200 MHz" if the 300 MHz doesn't work at the end of this post:
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg403624/#msg403624 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg403624/#msg403624)


To my knowledge we do not know why some units fail to be upgraded to 300 MHz and I decided to investigate.  I corresponded with a few MSO2072A owners here to see what may cause the 300 MHz option to not install by comparing hardware/software versions and the "Hardware Version" resistors.  So far I have found identical hardware/software versions, and resistor settings, which in one case the 300 MHz option can be installed, and in others it can't.

Since the 300 MHz option works for practically everyone, I think we can be confident the algorithm is correct.  I wonder if the scope does a separate check of the key against some other parameter (either resistor setting, or EEPROM values) to see if the key should be accepted.

>> If anyone has ideas about this, please tell!

Does anyone have, or could take high res photo, of the PCB of an MSO2072A unit that successfully upgraded to 300 MHz?  I would like to compare it to the unit I have open at the moment and see if I can spot any difference.

Cheers,
Sparky

EDIT: I received some photos already for comparison purposes...

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: plasijo on October 31, 2014, 11:08:20 am
Dear Sparky,
would you be so kind and could you share these photos with us. They should be definitely interesting for other members.
Thank you in advance, JP.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Sparky on November 01, 2014, 08:09:18 am
Dear Sparky,
would you be so kind and could you share these photos with us. They should be definitely interesting for other members.
Thank you in advance, JP.

I will not post the images, since they are not mine to being with.  There are few alternative sources of images that may suit your needs, however.  See here: https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg427482/#msg427482 (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg427482/#msg427482) or here: https://www.eevblog.com/forum/testgear/experiences-on-mso1074z-and-mso2074a/msg474215/#msg474215 (https://www.eevblog.com/forum/testgear/experiences-on-mso1074z-and-mso2074a/msg474215/#msg474215)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on November 02, 2014, 10:36:02 am
Does anyone have the 00.01.09 firmware (.gel) for the DG4000? If so, can you attach/pm me? I'm trying to see how this version can be upgraded, it doesn't work they way the older firmware did.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: miguelvp on November 02, 2014, 02:27:45 pm
Isn't that for the DSA815?

I know some of the updates are at:
http://gotroot.ca/rigol/ (http://gotroot.ca/rigol/)

But DSA800_FW_00.01.09.zip is not there, and I think the reason is that with  00.01.09.00.07 it won't let you install the options.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on November 02, 2014, 02:39:31 pm
Isn't that for the DSA815?

No, it's for the DG4000 ARB series.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: eV1Te on November 02, 2014, 03:41:54 pm
What is the latest firmware for the DS1000Z-S series of scopes?

I currently have 00.02.01.01 and I have noticed a few bugs in this early version.

Also does the key-generator work for the latest firmware versions?  :)

Edit: I found that the latest version is 00.04.01 via this website (thanks to Orange):
http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm (http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm)

Does all the options stay unlocked after I upgrade?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on November 02, 2014, 03:51:30 pm
Isn't that for the DSA815?

No, it's for the DG4000 ARB series.
If you use this link, you get it quickly is my experience

http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm (http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on November 02, 2014, 04:10:00 pm
If you use this link, you get it quickly is my experience

The problem is that I have to give them the serial #, and they will know that it was shipped with the latest version.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Sparky on November 02, 2014, 11:17:46 pm
To my knowledge we do not know why some units fail to be upgraded to 300 MHz and I decided to investigate.  I corresponded with a few MSO2072A owners here to see what may cause the 300 MHz option to not install by comparing hardware/software versions and the "Hardware Version" resistors.  So far I have found identical hardware/software versions, and resistor settings, which in one case the 300 MHz option can be installed, and in others it can't.

Since the 300 MHz option works for practically everyone, I think we can be confident the algorithm is correct.  I wonder if the scope does a separate check of the key against some other parameter (either resistor setting, or EEPROM values) to see if the key should be accepted.

>> If anyone has ideas about this, please tell!

Following up on my own post, I compared high-res images from MSO2072A that could be updated to 300MHz and also the one I currently have which only allows the 200 MHz option, and I cannot find any differences (e.g. hardware resistor settings).  So I wonder if the license key check withing the firmware is making additional comparisons to validate keys, perhaps against data stored in EEPROM. 

Anyone have thoughts on this?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: msraya on November 03, 2014, 12:55:07 pm
Hello all!

I just received a new MSO1074-S.

Someone know when the new code for the keygen will be avalaible?
The old keygen does not work with firmware 00.04.01.SP2.

Someone can put the new key table for these models to update the keyen?

Thank You All!
Manuel
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: eV1Te on November 03, 2014, 11:56:40 pm
I just received a new MSO1074-S.

Someone know when the new code for the keygen will be avalaible?
The old keygen does not work with firmware 00.04.01.SP2.
I just installed the same firmware on my DS1074Z-S (no the MSO) and the keys I had entered before are still working.

I read a few pages back that someone had managed to make a new version of the keygen work on the MSO, it required a different key if I remember correctly.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: msraya on November 04, 2014, 02:23:16 am
Hello EV1Te and Thank You for you response.  :-+

User rmd79 found the private key for MSO100Z. But it is not enough, We need the OPTIONS CODE which found user SMPT14a.
I tried these private key and CODES in the riglol software but not working.

The user sptm14a also found the way to make it working but yet He not detail the modifications to the algorithm He make.
I sent a PM to him, but has not yet answered.

I will study the source code of the riglol tool to see if I can find something...
As you see there are some info nested inside the thread, HI HI..  |O

Regards
Manuel
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on November 04, 2014, 07:39:43 pm
The user sptm14a also found the way to make it working but yet He not detail the modifications to the algorithm He make.
I sent a PM to him, but has not yet answered.
I've PMed him too on October 30. But according to his profile he hasn't been on the forum since October 27: https://www.eevblog.com/forum/profile/?u=99473 (https://www.eevblog.com/forum/profile/?u=99473)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: eV1Te on November 04, 2014, 09:49:34 pm
Too bad the codes have not been sorted out for the MSO yet.

By the way how good is the decoding function in the MSO?
I was debugging RS232 from a GPS today on my DS1074Z-S, and the decoding function is really terrible, almost unusable.

It only decodes the waveform on the screen at the moment (not outside the screen), so if you scroll (move horizontal) past the beginning of the transmission it losses its sync and interprets the first rising edge that you can see on the screen as the start-bit which scrambles the entire message.

If you "zoom-out" then it can not decode any data at all because the it only decodes whats in the screen buffer (it does not use the large memory capability of the scope), and this data aliases very early on.

Hence it is impossible to to view more than the first ca. 15 bytes/characters of a transmission. If you are lucky and there are gaps between each byte , then you can manually can set the edge of the screen to be in one of the gaps, but if you have a continuous string of bytes then you are out of luck (unless you are lucky and happen to have the first bit just at the left part of the screen).

I  also tried using the event table or single capturing a longer sequence without any luck. Triggering of a character in the middle of the transmission doesn't work either because the decoder scrambles the message anyway (since it can not see the start of the message) even if the trigger stopped at the correct spot.

I watched this video from Rigol demonstrating the decoding function on a DS4000 scope, there they specifically say that you can zoom out and use the event table if your message is long and does not fit on the screen. Apparently the DS1000Z series of scopes has seriously downgraded decoding function and is not comparable to their more expensive scopes.
4_4 How to Trigger and Decode an I2C Bus using a Rigol Oscilloscope (https://www.youtube.com/watch?v=Aa2pcQVPOcU#ws)


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: diyaudio on November 04, 2014, 09:59:22 pm

I was debugging RS232 from a GPS today on my DS1074Z-S, and the decoding function is really terrible, almost unusable.


I decoded data from a ublox GPS, the $GPRMC USART data was decoded pretty well. Sometimes you need to double check your scope setup it happended a few times where i blamed the decoders.

I own a DS2072A using the hacked firmware.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on November 04, 2014, 10:14:02 pm
I think part of getting the decoders to work well is getting the trigger setup properly and also understanding that by default you aren't doing a single capture and review, but by default the scope is trying to trigger as many times as possible so it can provide a gradient display.  I think the result would be better if you (1) setup the trigger to trigger on the even you want to, (2) set the timebase so that you can capture all of the event on one screen, (3) set the trigger mode to normal not auto, and (4) once you have captured then go to stop mode so no more capturing can occur.

Whether or not the decoding stays aligned when you expand the signal and start moving through it I am not certain.  I've had it act like if part of the signal goes off the screen it lost its way and it seems like I've had it handle that properly at other times so I don't know if I was still running or stopped and reviewing the waveform.

edit : I don't see such a great value in the decoders.  I'll use them if convenient, but I much rather use a Saleae Logic or LogicPort.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: eV1Te on November 04, 2014, 10:22:35 pm

I was debugging RS232 from a GPS today on my DS1074Z-S, and the decoding function is really terrible, almost unusable.


I decoded data from a ublox GPS, the $GPRMC USART data was decoded pretty well. Sometimes you need to double check your scope setup it happended a few times where i blamed the decoders.

I own a DS2072A using the hacked firmware.

I am willing to bet that the DS2000 series scopes have a much better debugger in that case. No doubt the DS1000Z only uses the screen buffer for debugging, and that's probably around 1k points or less. Doesn't the DS2000 have 2 FPGAs and the DS1000Z only 1?

The debugger works fine for short transmissions or for the beginning of a transmission, but fails completely for longer messages or when triggering in the middle of a message.

Maybe this will convince me that I "have" to buy a real logic analyzer as an early Christmas gift for my self  ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: msraya on November 05, 2014, 11:52:47 am
Well, yesterday a colleague and I were debugging a FPGA design using I2C serial bus port.

I already knew that the I2C decodification does not work and indeed It was not showing anything in I2C testing close to reality.
Also, as we were doing scroll sideways in the capture zoom, the oscilloscope was completely blocked and We had to restart it.
However, the decoding of serial bus was successful (there was enough space between characters, it was not a data stream)

For the purist this is a serious error and the manufacturers have lied about decoding specifications.
However rethinking it, this equipment can not be compared with the more powerful DS2000 series since it only has a single FPGA for decoding and display.
With this in mind it is questionable the usefulness of decoding and I would not pay 188 euros for it.

In any case, the oscilloscope worked well comparable to Agilent 6000 Series we have as logic analyzer.
We do not use decoding. The scroll is somewhat slow, but it is still usable.

I can not test the SPI bus decoding, but it seems that for others users it decodes correctly.

If I had known before buy this issue, I would have perhaps opted to buy a MSO2000 series.
However for the price and the features I'm happy.
I have made also testing with the generator and FFT and it is working properly.

It's a shame that the Ultravision software made by user marmad does not support the model MSO1000Z.
I have contacted the author but I have not gotten any response yet. 

Regards
Manuel
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Howardlong on November 05, 2014, 12:10:17 pm
I have the MSO1074Z-S and I agree with your comments Manuel. The I2C decoding is almost not worth having at all, and certainly as a paid for option I'd feel short-changed.

Over all, like you, I do consider it good value for money though, there's a lot of functionality in that box when you include 4 channels, the LA and the dual signal generator.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on November 05, 2014, 01:27:26 pm
Forget using a cheap scope for protocol debugging.  Get a Saleae product and live happier.  I'm not shilling for them, just a very happy customer.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: miguelvp on November 05, 2014, 04:18:58 pm
I agree with Rigby, if you are measuring an already working protocol, a protocol analyzer is your thing.

If however you are prototyping a board that uses i2c, you need the scope to make sure your signals are good. The protocol analyzer will only work on clean signals.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: eV1Te on November 05, 2014, 08:21:27 pm
Forget using a cheap scope for protocol debugging.  Get a Saleae product and live happier.  I'm not shilling for them, just a very happy customer.

How good is the analog mode on the Saleae analyzers, is it just a gimmic or is it eqvivalent to usb-oscilloscope with lower bandwidth?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: miguelvp on November 05, 2014, 08:35:35 pm
I guess you made your point :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on November 05, 2014, 08:59:40 pm
Rigby - the pro models (usb3) do -10V to +10V analog.

Their logic 8 model ($199) does 0V to +5V analog.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on November 05, 2014, 09:01:04 pm
It's not too bad.  I have a Logic 16 Pro and it's a great scope when you remember the device is a logic analyzer first. 

I mean it only does 5V max and they aren't true scope probes, but if you want to see the shape of a TTL waveform, the Logic 16 Pro will get you what you need.

It is not a replacement for even a cheap eBay CRT scope, so always have a real scope on hand.

edit: sorry, phone lied to me and said it couldn't connect a few times.  it DID!  d'oh
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on November 05, 2014, 09:04:02 pm
I guess you made your point :)

Hah!  technology failed me.  This time.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on November 05, 2014, 09:05:17 pm
Rigby - the pro models (usb3) do -10V to +10V analog.

Their logic 8 model ($199) does 0V to +5V analog.

Thank you for the correction.  I was going off memory from the settings in the software.  I recall it only going to 5V, and I guess I was wrong.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dewey on November 05, 2014, 11:52:26 pm
Quick question, please redirect me if this isn't the place for it.  This seems like the ultimate thread for such matters:

Hypothetically, how much of a chance would one be taking by trying to "mod" a DS4014 to a DS4054?  How big a possibility is there of owning a $2300 brick?  Has it happened to anyone here?

Thanks
-Dewey
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: extide on November 07, 2014, 01:53:27 am
Depends on how you mod it.


So, I have a question of my own. Has anyone actually done quantitative tests on the DS4000 series regarding upgraded b/w? Has anyone looked at the mobo in a DS4014 vs a DS4024/DS4034/DS4054 to see if they are actually the same or any different? I think I saw some rise time tests on a modded DS4k, but I can;t remember, and is that really sufficient enough?

I am going to be getting a DS4014 here in the next few weeks, and will probably hack to unlock the decoding options and whatnot, but I am a bit iffy on upgrading the b/w .. Plus, 100Mhz is plenty for what I am doing at the moment anyways so I will probably leave the b/w alone.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on November 07, 2014, 10:15:15 pm
Free EMI Software for the DSA815 and other Rigol Spectrum Analyzers.  And of course provides for a Linear or Log frequency display (as required for EMI reports):  https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg545685/#msg545685 (https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg545685/#msg545685)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: EE-digger on November 10, 2014, 07:10:17 pm
Depends on how you mod it.


So, I have a question of my own. Has anyone actually done quantitative tests on the DS4000 series regarding upgraded b/w? Has anyone looked at the mobo in a DS4014 vs a DS4024/DS4034/DS4054 to see if they are actually the same or any different? I think I saw some rise time tests on a modded DS4k, but I can;t remember, and is that really sufficient enough?

I am going to be getting a DS4014 here in the next few weeks, and will probably hack to unlock the decoding options and whatnot, but I am a bit iffy on upgrading the b/w .. Plus, 100Mhz is plenty for what I am doing at the moment anyways so I will probably leave the b/w alone.

I'm interested in the answer to this also.  The minimum timebase changes across these models from 5ns to 2ns to 1ns.  Getting the 2ns or 1ns would be a definite plus (if you need it).

Den
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: H.O on November 10, 2014, 08:16:37 pm
Hi,
When I upgraded my unit I did some very rudimentary tests - please take it for what it is.

Using a DG4162 to generate and feed a 100MHz, 100mVp-p sinewave my Tekronix 2465B (400MHz bandwidth) measured the signal (using cursors) to 100.5mV while the DS4014 reported 85mV - which is well above the 100MHz bandwidth specification of the DS4014.

After uppgrading the DS4k measured the exact same 100MHz 100mVp-p signal as 98mV.



Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Sparky on November 11, 2014, 07:10:15 am
In this post (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg541236/#msg541236) I reiterated the "License is unavailable!" message that sometimes accompanies attempts to install 300 MHz keys on Rigol DS2072A or MSO2072A models.  I have been attempting to install the 300MHz "NS8H" key on an MSO2072A without success, and called out to some folks here for info, insight and testing.  So far my tests and outcomes are:

1) Look for physical differences (e.g. "Hardware revision" resistor settings on the mainboard (DS2000_MB_V02.02)) between identical MSO2072A units (same hardware/firmware revisions from factory), of which one unit would and the other would not accept a 300 MHz key.  No differences could be found.
2) Recompile rigup 0.4 from source code (on Linux machine) to see if any keys generated were different.  Identical keys were generated.
3) Recompile rigup 0.4 with different (non-zero) "k_offset" so as to generate different valid keys.  200 MHz key can install.  300 MHz cannot install and gives the same "License is unavailable!" message.
4) Compare keys generated on my system with those generated by someone else (and for which the 300 MHz key did work) for the same memory dump.  Differences in the PCs (32-bit and 64-bit) did not yield any differences in the keys.  The above few tests effectively ruled out operator error, 32-bit/64-bit machine differences, or other similar issues.

The last outcome is that there are several license related messages stored in the firmware:

License invalid
License had installed
License has been used
License has been expried      << yes, "expried" and not "expired"
License is unavailable!
License is none!

Despite the range of messages, the only message displayed when an invalid license is entered is "License is unavailable!".  Given the range of messages available Rigol could check and distinguish between "invalid" and "unavailable" keys.  But, as the same message is always returned (for an invalid key) it is not possible be sure the reason the license was rejected.

It is possible there is a firmware level check that detects the 300 MHz key and rejects it, but if this were true the 300 MHz key would be rejected on all MSO2072A units.  Furthermore, whatever the type of check in place (firmware or hardware), it would seem Rigol could duplicate it for rejecting 200 MHz and other options, but this hasn't been done.  So, a firmware or hardware related check doesn't seem likely.

I can think of two possibilities:

1) The 300 MHz key is sometimes incorrect, and the DS/MSO detects and rejects it as such, just like any "made up" (wrong) license key.  That is, there is a "fence-post" type bug somewhere in rigup/riglol/miracl etc. or a misunderstanding with some aspect of the key generation that is occasionally exposed.

2) There is a bug in the scope firmware, causing sometimes valid 300 MHz keys to be rejected.

Anyone have further thoughts?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: EE-digger on November 11, 2014, 05:48:09 pm
My thought could be out in left field but who knows ...
During production test, hardware could be "marked" as to its bandwidth and rise time capabilities.  During final production configuration, units can be configured for the highest level product they can meet, or a lower level if sales demands more lower level units.
I've never been in a production environment where the required performance was not designed in but perhaps in higher volumes, and in China, final designation occurs sort of the way pistons, pins and connecting arms were mated in the earlier days of automobile production, prior to the discovery of design for mass production.
Just my $0.02

Den
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: EE-digger on November 11, 2014, 06:17:33 pm
Here are some bandwidth and risetime numbers I measured on an MSO1104Z that I received two days ago.

There is a twist in bandwidth measurement that I noticed and may be of help to others.  I apologize if this exists elsewhere.

While measuring bandwidth with an Agilent source (50 ohm output) and precision in-line termination at the scope, I found bandwidth to be much higher that expected (i.e. 3dB point around 190MHz or more).  Too good to be true  :)

On a Tek TDS784D (1GHz) with the same external termination, I noticed that the source appears to peak as you go above 120MHz.  I knew the generator was flat (into a proper load) so repeated with the internal 50 ohm Tek setting.  This I know to have very good return loss.

The source, as I expected, was flat.  It turns out that with the 50 ohm external termination, with either the expensive Tek scope or the Rigol, you end up with peaking, probably caused by the scope input impedance (cap + inductance).

So, the numbers shown here were measured with the amplitude verified first into an internal 50 ohm scope.

Bandwidth:  (all without any aliasing effects)

-3dB :   155 MHz
-6dB :   280 MHz
-9dB :   380 Mhz

Risetime:   (measured with avalanche pulse source, 180ps rise time)

Rigol reports :   1.2ns
correcting for the avalanche pulse rise time :   1.18ns

In addition to the beautiful graphic presentation of the Rigol scopes (for any money as far as i can see, having handled recent vintage Tek, LeCroy and Agilent),  what impresses me is that the Rigols do not "fall apart" until you are up around 4X the bandwidth (from aliasing and other DSP related issues).

But now, I can't wait until mods are available for this MSO.

The I2C and SPI, while not real time, appear to work fairly well but I only have 12 hours left  :'(  On I2C at least, you can take a sweep at a long horizontal time, the stop the scope and zoom in, whereupon you will get the decoded values as soon as a packet or packets are fully on screen, as observed by others.  I2C was at 100kHz and SPI was at 500kHz.

Den
Title: Is the process for the DS4014 still the same?
Post by: dewey on November 11, 2014, 09:25:55 pm
To upgrade a DS4014 appears to involve putting a firmware update on a USB stick, booting from it and restarting.  (instructions thread here) (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg471913/?topicseen#msg471913)

I just ordered a DS4014, and would like to experiment with its bandwidth.  However, I don't want to be the proud owner of a $2300 brick.  From the above thread, it sounds as if perhaps the poster above me here is experiencing what might be a change in the DS2072A's ability to be upgraded, perhaps due to hardware level changes made by Rigol?

Does anyone know if Mr. Kreb's tool (here) (http://www.gotroot.ca/rigol/) will still work on a DS4014, as delivered today, November 2014?  Has the firmware changed at all since the tool was written, or will that matter?  Any reports of hardware changes made by Rigol?

I'd really appreciate anyone's input.

Thanks
-Dewey
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: H.O on November 11, 2014, 09:40:45 pm
There's no longer any need to apply the modified firmware since seronday found/figured out the option codes for bandwidth selection on the DS4k. See reply #3607 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg523679/#msg523679) in this thread. It's been verified to work with the latest firmware available today (00.02.02.01.01). You can use Riglol 1.03d (http://gotroot.ca/rigol/riglol-103d/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Bud on November 12, 2014, 02:33:12 am
1) The 300 MHz key is sometimes incorrect, and the DS/MSO detects and rejects it as such,

Just had a DS2072A updated to 300MHz. FW 00.03.00.SP1, HW 2.0

Used Bildschirmkopie to dump data from the scope via a SCPI command
:SYST:UTIL:READ? 15441920,13262848
then goes rigup-0.4 to generate the keys
then again Bildschirmkopie to install a key
:SYSTem:OPTion:INSTall A_KEY_WITHOUT_DASHES

Bildschirmkopie : http://peter.dreisiebner.at/rigol-bildschirmkopie-lan/download.htm (http://peter.dreisiebner.at/rigol-bildschirmkopie-lan/download.htm)
rigup-0.4:  http://gotroot.ca/rigol/ (http://gotroot.ca/rigol/)

I am not sure why bother changing the scope firmware via a USB stick risking to brick the device, unless it is because of other goodies that I am not aware of. If all you want is options and bandwidth, the above procedure is non-intrusive and safe.


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Tilman on November 12, 2014, 09:35:59 am
@Bud: not working for me, only the 200MHz is working  |O

@Sparky: i tried 3 Laptop running Win 8.1 x64 and one Win7 32bit, no Change  :wtf:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: danander11 on November 12, 2014, 10:56:06 am
1) The 300 MHz key is sometimes incorrect, and the DS/MSO detects and rejects it as such,

Just had a DS2072A updated to 300MHz. FW 00.03.00.SP1, HW 2.0

Used Bildschirmkopie to dump data from the scope via a SCPI command
:SYST:UTIL:READ? 15441920,13262848
then goes rigup-0.4 to generate the keys
then again Bildschirmkopie to install a key
:SYSTem:OPTion:INSTall A_KEY_WITHOUT_DASHES

Bildschirmkopie : http://peter.dreisiebner.at/rigol-bildschirmkopie-lan/download.htm (http://peter.dreisiebner.at/rigol-bildschirmkopie-lan/download.htm)
rigup-0.4:  http://gotroot.ca/rigol/ (http://gotroot.ca/rigol/)

I am not sure why bother changing the scope firmware via a USB stick risking to brick the device, unless it is because of other goodies that I am not aware of. If all you want is options and bandwidth, the above procedure is non-intrusive and safe.

Is there some trick in getting Bildschirmkopie to see the DS2072A?  I've tried the utility method but that didn't work..  (I think something to do with the fact that I cannot get it to reset on startup), but the utility sees it just fine...  I just get a length error message and cannot get past that point.

So I'm trying the Bildschirmkopie method...  It does not see the scope via LAN, (I pull up the IP on the DO and enter it into the search feature), nor does it see it on USB...

The one difference I note from others on here is that I have SW Version 00.03.01...

Frustrating.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: TheBay on November 12, 2014, 11:39:20 am
Instead of starting a new topic I thought I would post here.

Just bought a DS2072 non A model. From Toploser (Topbloke more like  :-+)

I have read pages and pages and pages on hacks for this model, things have changed a few times over the time it's been out so have a few questions.

Firstly I want to reset it back to defaults, remove all hacks (300mhz is enabled)
Update firmware (Not sure which is the best version?)

And enable all the options/hacks, but can someone please tell me what the best options are to enable and does 300mhz work on the non A correctly?
Apart from the 1m/50k switch do we now know any different between the A and Non A from a hardware point of view?

Any advice with the above will be gratefully appreciated.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Bud on November 12, 2014, 02:07:56 pm
Is there some trick in getting Bildschirmkopie to see the DS2072A?

No, I just ran the program and it worked by either search on the LAN or manual entering the scope IP.

Do you have a DHCP server/router on your LAN? Make sure the scope gets a correct IP that belongs to your LAN subnet and the proper default gateway. Try to ping the scope's IP from your computer, if you cannot reach it by ping then programs will not find it on the LAN.

I did not try Bildschirmkopie in USB mode, in fact I have not ever connected my scope to USB. But I'd guess when you plug it in you could check in Device Manager (if you are on Windows) that it shows up there in the list of USB devices.

Let us know if any progress.

EDIT: make sure you trying to connect  using a single method, i.e. unplug the USB when trying by LAN, see if this helps.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: plasijo on November 12, 2014, 03:56:46 pm
Hi,
I used the following steps:
:SYST:UTIL:READ? 1,33554432
"Senden und Empfangen" button - the result is file with huge amount of data (32MB), but I was definetely succesful. Be patient, the read process is long (approx. 5 minutes) and during this time "Bildschirmkopie" seems to be non-working.
"Speichern" button ... save the file for rigup.
I hope everything is clear after that.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Bud on November 12, 2014, 04:22:55 pm
For the purpose of extracting necessary data it is sufficient to run
:SYST:UTIL:READ? 15441920,13262848

which is a smaller 13Mb data dump.

The copy of Bildschirmkopie I am using can 'speak' English (v0.6.5.767)

Anyway, I tried Bildschirmkopie with USB, it can see the device in the Search screen, but sending commands did not work. So for me it only worked via LAN to my DS2072A.

danander11: When I connected the updated scope to USB before I installed Rigol's Ultra Sigma software, the scope popped up in  Windows Device Manager as "Other Device - DS2302" with a question mark, but at least it was an indication Windows could see the device, was just missing proper device drivers. I then installed Ultra Sigma and after that the scope appeared as a USB Test and Measurement Device, see the picture.

I could also get the data from the scope using Ultra Sigma program but could not figure out how to save in binary, so for the purpose of getting the data out to unlock the scope, Bildschirmkopie via LAN is the way to go.



Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cap4096 on November 12, 2014, 06:11:58 pm
If it is using one of the Firmware versions mentioned, then , Yes.

Try it and report back.

It seams to work!

/Cap4096
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: danander11 on November 13, 2014, 12:11:56 am
For the purpose of extracting necessary data it is sufficient to run
:SYST:UTIL:READ? 15441920,13262848

which is a smaller 13Mb data dump.

The copy of Bildschirmkopie I am using can 'speak' English (v0.6.5.767)

Anyway, I tried Bildschirmkopie with USB, it can see the device in the Search screen, but sending commands did not work. So for me it only worked via LAN to my DS2072A.

danander11: When I connected the updated scope to USB before I installed Rigol's Ultra Sigma software, the scope popped up in  Windows Device Manager as "Other Device - DS2302" with a question mark, but at least it was an indication Windows could see the device, was just missing proper device drivers. I then installed Ultra Sigma and after that the scope appeared as a USB Test and Measurement Device, see the picture.

I could also get the data from the scope using Ultra Sigma program but could not figure out how to save in binary, so for the purpose of getting the data out to unlock the scope, Bildschirmkopie via LAN is the way to go.

Thanks Gents...

One of my issues was that I was trying to connect via Win8.1....  which decided to give me grief.  I've installed everything on a Win7 box and it connects right up via LAN.  I've used Bildschirmkopie to send and read using :SYST:UTIL:READ? 15441920,13262848 and have gotten my 13mb scpi file...

From here I've decided to stop and read until I understand the process a bit better...  rigup won't look at the scpi file so I've installed HxD to look at the file..  but from there I'm not quite sure what to do.   So I'll read a bit more.  There seems to be a few divergent paths that folks have taken and I don't want to get caught out changing horses in the middle of the stream, as it were... and brick the scope.

I appreciate all of your help so far!

Cheers!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Bud on November 13, 2014, 01:41:14 am
OK so you have done the heavy lifting and got your scpi data, say the file name is mydata.scpi . Next steps are:

- copy the .scpi file to rigup folder
- open a command line window and from rigup folder run

   rigup scan mydata.scpi > EC-keys.txt
   rigup DS2072A mydata.scpi > Options.txt

this will create two files with keys and options

- open options.txt in a text editor, copy paste the desired option key to  Bildschirmkopie (remove dashes)
:SYSTem:OPTion:INSTall A_KEY_FROM_OPTIONS_WITHOUT_DASHES

Press Send button and watch the scope screen, it should beep and show a progress bar for a few seconds. Once done you are good to go!
verify in Utility -> Options -> Installed what you got
 ;)


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: danander11 on November 13, 2014, 02:26:19 am
OK so you have done the heavy lifting and got your scpi data, say the file name is mydata.scpi . Next steps are:

- copy the .scpi file to rigup folder
- open a command line window and from rigup folder run

   rigup scan mydata.scpi > EC-keys.txt
   rigup DS2072A mydata.scpi > Options.txt

this will create two files with keys and options

- open options.txt in a text editor, copy paste the desired option key to  Bildschirmkopie (remove dashes)
:SYSTem:OPTion:INSTall A_KEY_FROM_OPTIONS_WITHOUT_DASHES

Press Send button and watch the scope screen, it should beep and show a progress bar for a few seconds. Once done you are good to go!
verify in Utility -> Options -> Installed what you got
 ;)

Once again I have to say thanks a million!   

It's not working for me though as the EC-keys.txt and Options.txt are both empty.  Not sure why that is...  I ran Bildschirmkopie again to see if maybe I had a corrupt scpi file but got the same result.  I'll dig into it later tonight or tomorrow and see if I can sort out why... 

I have to write a paper on sustainability that's due tomorrow..  yee haa   :o
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Bud on November 13, 2014, 02:45:07 am
I see.  Just in case, worked on my Win 7 x64. May be you could check if the rigup folder in not read-only, and may be try running a command prompt as Administrator.

Also may try to extract the whole 32Mb data from the scope and run rigup against it, who knows.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: danander11 on November 13, 2014, 04:29:46 am
A million thanks to all of you...

Turns out that with the 00.03.01 firmware, I had to use the 32MB dump to get it to work...

Also, The win7 box would always show a blank txt file with  0kb size.  I copied the two txt files to a stick and opened them in a win8 box and there they were.

It now seems that I now have a fully functional 2302.

I'm a happy-chappy indeed....

Cheers everyone.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sptm14a on November 13, 2014, 06:11:35 am
I just received a new MSO1074-S.

Someone know when the new code for the keygen will be avalaible?
The old keygen does not work with firmware 00.04.01.SP2.

Someone can put the new key table for these models to update the keyen?

riglol uses a hardcoded set of keys which makes it rather useless for MSO1000. The problem is that some of the keys that MSO uses for license validation are different for each device. A modified rigup can be used to generate valid licenses, but it needs a list of keys that can only be dumped via JTAG. Unfortunately, unlike 2000 series, DS/MSO1000 does not seem to have a way to dump memory by any means other than opening the scope and connecting a jtag. I am trying to find a way to not require memory dump for license generation, no luck so far.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: msraya on November 13, 2014, 11:05:20 am
Thank You for share your knowledge!

So, I want to know how you modificated the rigup code.
You use more characters in the serial number, or only change the private key, or what?

Regards
Manuel
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on November 15, 2014, 01:30:26 pm
There is a new issue with 'Rigol DS1000Z & DS2000 Oscilloscope Jitter' related to the Trigger mode/method.    See ->  https://www.eevblog.com/forum/blog/eevblog-683-rigol-ds1000z-ds2000-oscilloscope-jitter-problems/msg550964/#msg550964 (https://www.eevblog.com/forum/blog/eevblog-683-rigol-ds1000z-ds2000-oscilloscope-jitter-problems/msg550964/#msg550964)   This is already up to 12 pages in only two days.  I'm posting this alert here because we should all at least be advised that this issue is being discussed. I also believe that some DS4000 users are experiencing the trigger jitter issue (with the AC trigger mode).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Matthias Toussaint on November 15, 2014, 07:31:00 pm
DS4000 series Bandwidth (model type) Option Codes.

For those who have an interest in the DS4000, I have found the option codes for selecting the bandwidth .
This also sets the model type.

For example the code FAB9 will select 500Mhz, (DS405x), with all Decoders enabled.

The attached file contains all the details.

There are also two un-documented, possibly future, options called "Power Analysis" and "MA".

The option codes have been tested with firmware ver 00.02.00.00.04 and ver 00.02.01.00.03.

I first thought that this is too good to be true, but I couldn't resist to try it out. It actually works like a charm :) After upgrade I measured the bandwidth in comparison with my good old trusty Tektronix 2465A (350MHz model). The plot shows a BW of 600Mhz for the RIGOL DS4054. My confidence in the measurement is reasonably high. The plot makes sense and clearly shows the flat resonse of the RIGOL (typical for modern scopes) vs. the gaussian response of the Tek. I'm a very happy camper now! The bandwidth really increases. Before upgrade I made a quick measurement with a 400MHz sinewave and repeated the measurement after the procedure. The difference could be clearly seen (sorry, no screenshots. My thumbdrive failed and the pictures got lost)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Sparky on November 16, 2014, 07:58:06 am
During production test, hardware could be "marked" as to its bandwidth and rise time capabilities.  During final production configuration, units can be configured for the highest level product they can meet, or a lower level if sales demands more lower level units.

Hi Den,

Thanks for your comment!  I agree that the hardware could be tested and "binned"/"marked" according to performance tests during manufacturer, however I could not find physical evidence (e.g. pull up/down resistors setting version or other info).  Still, there could be something written to EEPROM and checked by the firmware, but we have no knowledge of such checks being done.

Sparky
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Sparky on November 16, 2014, 08:05:09 am
@Bud: not working for me, only the 200MHz is working  |O

@Sparky: i tried 3 Laptop running Win 8.1 x64 and one Win7 32bit, no Change  :wtf:

Thanks for further acknowledgement of this issue.  It is a mystery that this only occurs on 300 MHz and not 200 MHz or other options...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: levstic on November 16, 2014, 12:29:08 pm
For the purpose of extracting necessary data it is sufficient to run
:SYST:UTIL:READ? 15441920,13262848

which is a smaller 13Mb data dump.

The copy of Bildschirmkopie I am using can 'speak' English (v0.6.5.767)

Anyway, I tried Bildschirmkopie with USB, it can see the device in the Search screen, but sending commands did not work. So for me it only worked via LAN to my DS2072A.

danander11: When I connected the updated scope to USB before I installed Rigol's Ultra Sigma software, the scope popped up in  Windows Device Manager as "Other Device - DS2302" with a question mark, but at least it was an indication Windows could see the device, was just missing proper device drivers. I then installed Ultra Sigma and after that the scope appeared as a USB Test and Measurement Device, see the picture.

I could also get the data from the scope using Ultra Sigma program but could not figure out how to save in binary, so for the purpose of getting the data out to unlock the scope, Bildschirmkopie via LAN is the way to go.

I have written a small program in LabView (you need labview at least 2012, NI VISA driver) that can dump the memory to the binary file using a USB connection. See attached image, the step is follow:
1. Turn on the oscilloscope and connect to the computer via USB, make sure it is recognized.
2. Open the LabView file, select the Rigol ID from the list of "VISA resource name", should be something like:  USB0::0x1AB1::0x04B0::DS2D123456789::INSTR,
you don't need to change the command, and then select the destination folder of the dump file.
3. Run the program (click play button) and then click "Send & Read".
4. Wait for about 20 ~ 30 seconds until it finishes, the complete light should be on and the file will be saved automatically (about 13 MB).
5. You can use the file with rigup-0.4 to generate the unlock code. For example in this case: "rigup ds2072a ds2072a.bin"

Tested on Windows 7 64 bit and Rigol DS2072A, upgraded to DS2302A.
(Rigol DS2072A, software version 00.03.00.SP1, hardware 2.0)

Edit:Executable file
If you don't have Labview, you can use an executable file "Rigol USB.exe" in the zip file attached.
This file requires two components to be installed before hand:
- Labview Runtime Engine 2013  Download here ! (http://www.ni.com/download/labview-run-time-engine-2013/4059/en/)
- NI VISA Runtime (you may already have this)

levstic

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: daemonix on November 16, 2014, 08:45:58 pm
Question! I have a 1074z hacked with all apart from 500u addons. (Identified as 1104) im using the 2.xx firmware and im thinking about getting the later firmware. (I have the 4.00 as an install file but i think there is a 4.0x now.) i think the menus got a lot of updates since my version as i saw in the latest episode's 1054.

Any problems with the update? Will the hack work?
Thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on November 17, 2014, 01:31:34 pm
I have written a small program in LabView (you need labview at least 2012, NI VISA driver) that can dump the memory to the binary file using a USB connection. See attached image, the step is follow:
1. Turn on the oscilloscope and connect to the computer via USB, make sure it is recognized.
2. Open the LabView file, select the Rigol ID from the list of "VISA resource name", should be something like:  USB0::0x1AB1::0x04B0::DS2D123456789::INSTR,
you don't need to change the command, and then select the destination folder of the dump file.
3. Run the program (click play button) and then click "Send & Read".
4. Wait for about 20 ~ 30 seconds until it finishes, the complete light should be on and the file will be saved automatically (about 13 MB).
5. You can use the file with rigup-0.4 to generate the unlock code. For example in this case: "rigup ds2072a ds2072a.bin"

Tested on Windows 7 64 bit and Rigol DS2072A, upgraded to DS2302A.
(Rigol DS2072A, software version 00.03.00.SP1, hardware 2.0)

For those who want to give LabView a shot for their own reasons, you can buy it with an Arduino UNO on Sparkfun.com for $50, I think.  It is WIDELY used in industry and would be a good tool to learn.  https://www.sparkfun.com/products/11225 (https://www.sparkfun.com/products/11225)

Fear not the export warning; you would know if you life in a place that this can't be shipped to.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: miguelvp on November 17, 2014, 06:04:35 pm
Thanks Rigby, I don't have an Arduino and never saw the need for it, but LabView got my interest :)
I do have some shields since a lot of dev kits come with Arduino headers.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dudarobe on November 21, 2014, 10:54:03 am
Hello,
Is there a chance to unlock the DSA-815-TG with software 1.09 and 1.04 bootloader ??

thanks for reply.
Robert
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mauroh on November 21, 2014, 11:14:14 am
Question! I have a 1074z hacked with all apart from 500u addons. (Identified as 1104) im using the 2.xx firmware and im thinking about getting the later firmware. (I have the 4.00 as an install file but i think there is a 4.0x now.) i think the menus got a lot of updates since my version as i saw in the latest episode's 1054.

Any problems with the update? Will the hack work?
Thanks

I have a DS1074z bought one year ago with firmware 2.xx
Hacked to DS1104z full option (no 500u) and upgraded several times up to the latest 4.xx without any problems to the hack!

In case i need to send it back for repair, I don't know if it is possible to revert the oscilloscope to it's original configuration (I know this part is possible, read the rest of the sentence :)) and use the same keys previously generated on the repaired/firmware upgraded oscilloscope.

Mauro

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Edgar Amalyan on November 21, 2014, 11:32:52 am
This has pobably been asked a million times so sorry in advance. Can a new ds2072a be hacked to enable the extra options? And if so what are the most updated methods to doing so. I saw the riglol site a few pages back, do you just enter the generated key into the oscillosope? Thanks  :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dudarobe on November 21, 2014, 12:09:51 pm
This has pobably been asked a million times so sorry in advance. Can a new ds2072a be hacked to enable the extra options? And if so what are the most updated methods to doing so. I saw the riglol site a few pages back, do you just enter the generated key into the oscillosope? Thanks  :)

Hello, 4 days ago I bought a new ds2072a at www.conrad.de (http://www.conrad.de), the hardware 2.0, without any problem after the procedure from post # 3705, after 3 minutes I was overjoyed oscilloscope with installed full options to 300MHz.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Edgar Amalyan on November 22, 2014, 01:25:50 am
Hello, 4 days ago I bought a new ds2072a at www.conrad.de (http://www.conrad.de), the hardware 2.0, without any problem after the procedure from post # 3705, after 3 minutes I was overjoyed oscilloscope with installed full options to 300MHz.

That's great, for around $800 with the free options I think the DS2072 is the scope to get. Have you tested 300MHz on the scope? Rigol says the scope can be unlocked up to 200MHz through the keys.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Alexcn on November 26, 2014, 01:52:08 am
Dear All

I would like to thank each of you that made this upgrade possible.

As a student having a DS2072A upgraded to 300mhz oscilloscope is something that makes me more motivated!

A few notes on my experience.

DS2072A bought in March
Windows 8.1
Original firmware 02.00 - I have to update to 03.01.04 (before I was unable to read the memory)
I have to use the 32M dump files (12M and 16M doesn't work)
I use LAN port (It doesn't work by USB)


All the best for all of you and for RIGOL!!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: BTO on November 26, 2014, 03:05:23 pm
My God
248 Pages

is this post still going

@ Edgar

Mate, if your still having issues
i have exactly the same scope and i've upgraded it to 300MHz

YES .. IT WORKS

contact me directly
and as i've done for so many others
we can skype and i'll show you how to do it all

if you want to read it for yourself

LET ME SAVE YOU THE PAIN OF READING THIS ENTIRE UNCONTROLLABLE MONSTER OF A POST

I've created a summary of this post
SPECIFIC FOR THE DS 2072A

HERE YOU GO

https://www.eevblog.com/forum/testgear/unlockinghacking-the-rigol-ds2000a-series-scope-the-short-post/ (https://www.eevblog.com/forum/testgear/unlockinghacking-the-rigol-ds2000a-series-scope-the-short-post/)

IF YOU STILL HAVE ISSUES
PM me and i'll help you out
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: BTO on November 26, 2014, 03:08:44 pm
Just so there's no confusion

The Rigol DS2072A Unlocks TO 300MHz   not 200

however, it's optional to go to 200, but, why would you
if your unlocking features , unlock them all

it's 300MHz  and 56Mpts Memory Depth

TRUST ME
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Edgar Amalyan on November 27, 2014, 12:33:09 am
Thanks for the info. I haven't purchased the DS2072 yet but will do so in a month. Anyway, your guide looks simple enough, will do the unlock and message you if I encounter problems.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Eray on November 29, 2014, 12:58:14 pm
anyone, please dont leave me to read 248 pages of this thread and point to DSA815 hack stuff :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Lupini on December 01, 2014, 11:22:03 am
Hello,

I'm very happy : my MSO2072A is became a MSO20302A  :-+

My version : (http://img4.hostingpics.net/pics/399575IMG9049.jpg) (http://www.hostingpics.net/viewer.php?id=399575IMG9049.jpg)

Before : (http://img4.hostingpics.net/pics/594459IMG9052.jpg) (http://www.hostingpics.net/viewer.php?id=594459IMG9052.jpg)

After : (http://img4.hostingpics.net/pics/648833IMG9053.jpg) (http://www.hostingpics.net/viewer.php?id=648833IMG9053.jpg)

Thanks all
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: rednax on December 03, 2014, 01:05:30 pm
Hi everyone,

Is there any progress in unlocking the MSO1104z?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 0ff on December 03, 2014, 01:08:15 pm
Hey rednax,

in fact rmd79 and myself are looking into it.
We've found a temporary unlock, i.e. jtag-based and not surviving reboots, but apart from that we're basically stepping through disassemblies hoping for a magic insight :D

If you'd like to join our efforts, just PM me :)

Regards
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Trax on December 06, 2014, 05:08:02 pm
Hi everyone,

Is there any progress in unlocking the MSO1104z?

I would also be very interested in an option to unlock all features of a MSO1074z, its essential for my decision if to buy one or not.

Trax
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: amor4ti on December 07, 2014, 05:51:36 pm
Hi..

Any luck with hacking MSO1104Z & DG1000Z (memory option)?

Thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: remilton on December 09, 2014, 06:02:23 am
I can confirm that Rigup 0.04 is not working for the latest batch of ds2072a scopes.  I received mine last week and received the 'upgrade unavailable' message on ver 3 firmware and ver 2 hardware.  I tried for 300mhz and 200mhz with no joy.  I think we are going to need a new keygen.

By the way, the page at http://gotroot.ca/rigol/riglol/ (http://gotroot.ca/rigol/riglol/) , what is that very long key it generates after you enter your serial, option, and private key and what are you supposed to do with it?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 0ff on December 09, 2014, 10:41:24 pm
To all you MSO1000Z Owners: It's done, we found what Rigol changed for the MSO1k and we patched rigup to generate working keys.

Usage: Well, get the file, compile the source, call rigup like this:
Code: [Select]
./rigup license mso1074z.txt 0x1C0FFNote: The License option *must* be supplied as hex, these are valid values:
0x1C001 - TRIGGER
0x1C002 - DECODER
0x1C004 - MEM-DEPTH
0x1C008 - RECORDER
0x1C00F - All of the above

There are also these options, but they will modify your scope into a MSO1000Z. They are mostly untested and might harm your children.
0x1C010 -
0x1C020 -
0x1C040 -
0x1C080 -
0x1C0FF - all Options

Generate the mso1074z.txt like this:
Code: [Select]
./rigup scan YourDump.bin > mso1074z.txt
Note: You will need to open the scope to get a dump. I'm not going to change that, but if anyone of you would like to reverse the firmware signing process, there is a hidden DBGCMD that might provide useful as an entry point for custom SCPI logic.

I want to thank rmd79 for his continuing efforts as well as all original authors of the rigup tool! You guys are the one who deserve any credit!
Also, thanks to sptm14 for you keeping all the info from the public. This motivated me to actually walk through their code!

Best regards,
Fabian
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: rmd79 on December 09, 2014, 10:55:49 pm

Great work :)

The only thing I had to do was edit the main "Makefile" and change:

Quote
LDFLAGS                 := -O2 -Wl,-dead_strip

back to the original line:

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

Otherwise when running rigup license I would get the command-line help screen and then a segfault.

Other than that issue, its generating valid keys for my MSO1074Z-S.

Thanks heaps for your help,
Rob.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 0ff on December 09, 2014, 10:59:39 pm
Uh, sorry for that! I needed it to get rigup running on OS X.

Also as a general note: This is probably the most dirty version of rigup out there. I didn't take the time to clean things up, if anyone wants to do this, feel free!
Most important changes are probably in the charmaps, encode.c + decode.c + rmd79's patches.

Everything else was just me testing stuff.

I don't think it's worth the effort to make a single version of rigup, as this would need multiple checks on the model. But if you think otherwise: be my guest :)

Best regards,
Fabian
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Howardlong on December 09, 2014, 11:10:53 pm
Agreed, great work, I can confirm this worked on an MSO1074Z-S.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: BloodyCactus on December 10, 2014, 12:23:30 am
there is a hidden DBGCMD that might provide useful as an entry point for custom SCPI logic.

interesting that DBGCMD is still there in DG1032Z.. shame :FRE does not work tho :( I dont get the dbgcmd rx/tx outputs but maybe need to do some more poking around..

SCP Module Ver : 00.02.03.00.

hmm
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 0ff on December 10, 2014, 04:50:13 pm
Hey rednax, which kind of hack are you looking for?
The keygen should actually work for your MSO1104Z, too - with that you can enable all official options.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: rednax on December 10, 2014, 04:53:22 pm
Hey rednax, which kind of hack are you looking for?
The keygen should actually work for your MSO1104Z, too - with that you can enable all official options.

Hi 0ff,

I just didn't notice the lasted developments! Great work guys!
(I deleted my previous post)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Trax on December 10, 2014, 06:54:59 pm
To all you MSO1000Z Owners: It's done, we found what Rigol changed for the MSO1k and we patched rigup to generate working keys.

Usage: Well, get the file, compile the source, call rigup like this:
Code: [Select]
./rigup license mso1074z.txt 0x1C0FFNote: The License option *must* be supplied as hex, these are valid values:
0x1C001 - TRIGGER
0x1C002 - DECODER
0x1C004 - MEM-DEPTH
0x1C008 - RECORDER
0x1C00F - All of the above

There are also these options, but they will modify your scope into a MSO1000Z. They are mostly untested and might harm your children.
0x1C010 -
0x1C020 -
0x1C040 -
0x1C080 -
0x1C0FF - all Options

Generate the mso1074z.txt like this:
Code: [Select]
./rigup scan YourDump.bin > mso1074z.txt
Note: You will need to open the scope to get a dump. I'm not going to change that, but if anyone of you would like to reverse the firmware signing process, there is a hidden DBGCMD that might provide useful as an entry point for custom SCPI logic.

I want to thank rmd79 for his continuing efforts as well as all original authors of the rigup tool! You guys are the one who deserve any credit!
Also, thanks to sptm14 for you keeping all the info from the public. This motivated me to actually walk through their code!

Best regards,
Fabian

wow so just to clarify this with this tool I can unlock all features of a MSO1074z scope if I buy one for Xmas? is that right?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Howardlong on December 10, 2014, 07:10:48 pm
FWIW here is what I understand to be the list of options:

(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

I don't know what "DG" or "Power Ana" is.

As with the DS1000Z series, 500uV doesn't work properly. Here is my understanding. On ch2, 3, 4 was tried, the traces for those channels went off the top of the screen and they couldn't be retrieved without dropping back to 1mV/div. Ch1 worked at 500uV on the example I am aware of but had about -400uV of DC offset. A self calibration was run, but it made no difference.

The bandwidth on this example before applying the CS3A 100MHz option, measured with an HP 8656B 50 ohm terminated RF signal generator, was 91MHz and after it was 141MHz.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: msraya on December 10, 2014, 07:35:23 pm
Hello!

Good work and thank you to share knowledge!  :-+

I have in the lab a ICEbear Blackfin JTAG debugger (http://www.section5.ch/icebear (http://www.section5.ch/icebear)) that I have never used :-// .
You do think it is possible to use this tool to dump the memory?
Someone use it for that purpose?

Regards
Manuel
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 0ff on December 10, 2014, 07:40:10 pm
Hey Manuel,

that depends on your scope.
My MSO1074z is not built around a blackfin, but rather the freescale iMX28.
It's really only important to have an adapter that's compatible with openOCD, that's all that matters.

Oh an Howard: Thanks for your input with completing the license codes, this is just awesome :)

Regards
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: swanawood on December 10, 2014, 09:27:57 pm
Hi folks!

My new DS1054Z has just arrived; I am trying to dum mem via SCPI command (windoz).
I got no success:

with Rigol Bildschirmkopie LAN When I send(&receive) the dump command:
:SYST:UTIL:READ? 1,33554432

I get the error "There was an error when sending the SCPI command."
Other commands via Bildschirmkopie works (for example ":SYSTem:LANGuage?" gives "ENG")


With the netcat via command prompt (192.168.200.22 is the rigol IP address):

echo :SYST:UTIL:READ? 1,33554432 | ncat -i 1 192.168.200.22 5555 > memory.dump

the file is created but inside there is "command error"

My versions:
sw ver: 00.04.02.SP3
board ver: 0.1.1


Any idea ? does someone has the same versions and able to dump ?


p.s.
Anyway I succeded in installing options via caroot k**gen, but I would like to be able to dump memory.

Thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Howardlong on December 10, 2014, 10:22:54 pm
I don't think the SCPI READ works on the DS/MSO1000Z series scopes, you're going to need to open it up and pop a JTAG adapter on there like an OpenOCD.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: swanawood on December 11, 2014, 08:20:22 am
I don't think the SCPI READ works on the DS/MSO1000Z series scopes, you're going to need to open it up and pop a JTAG adapter on there like an OpenOCD.

Oh ! I didn't catch that before ....

Ok, can you (or somebody else) confirm that the Jtag connector is the one in picture at post #3530 by rmd79 , also for DS1054Z ? (in the reply he speaks over "MSO1074Z-S") ....

And also that the correct jtag is this ? :

https://www.olimex.com/Products/ARM/JTAG/ARM-USB-OCD-H/ (https://www.olimex.com/Products/ARM/JTAG/ARM-USB-OCD-H/)

Thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 0ff on December 11, 2014, 09:16:17 am
Yes, I can confirm that.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: swanawood on December 11, 2014, 09:20:06 am
Yes, I can confirm that.

Thank you sir.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Howardlong on December 11, 2014, 09:28:22 am
I don't think the SCPI READ works on the DS/MSO1000Z series scopes, you're going to need to open it up and pop a JTAG adapter on there like an OpenOCD.

Oh ! I didn't catch that before ....

Ok, can you (or somebody else) confirm that the Jtag connector is the one in picture at post #3530 by rmd79 , also for DS1054Z ? (in the reply he speaks over "MSO1074Z-S") ....

And also that the correct jtag is this ? :

https://www.olimex.com/Products/ARM/JTAG/ARM-USB-OCD-H/ (https://www.olimex.com/Products/ARM/JTAG/ARM-USB-OCD-H/)

Thanks

That is the one, FWIW Farnell part number 2279910 is what I have.

You'll need to make up an adapter from the 20 pin cable of the debugger to the 10 pin header on the board.

The pinout presented in the following post from sptm14 appears correct.

Quote
top row: tck,tms,tdi,trst,3.3v
bottom row: XXX,tdo,srst,gnd,gnd

Here is mine...

(http://i34.photobucket.com/albums/d123/photobucket391/92886E96-5A87-4C49-BA7F-EFB53CC19961_zpscosbqguv.jpg) (http://s34.photobucket.com/user/photobucket391/media/92886E96-5A87-4C49-BA7F-EFB53CC19961_zpscosbqguv.jpg.html)

The "TL" written above on the DIY adapter board indicates "Top Left" for orientation mating with the header on the board.

(http://i34.photobucket.com/albums/d123/photobucket391/5F5E1C27-CEF8-4D28-9839-B781350C8F7B_zpskrnditet.jpg) (http://s34.photobucket.com/user/photobucket391/media/5F5E1C27-CEF8-4D28-9839-B781350C8F7B_zpskrnditet.jpg.html)

Pin 1 of the 20 pin is on the upper left of that connector in the second image.

The RAM in the memory map is 0x40000000 to 0x43ffffff, and it takes about 20 minutes or so to dump. I found I had to specify the jtag speed (adapter_khz) to make it work. In addition, you must stop the CPU before taking the RAM dump. It's been a few months since it so I'm afraid I'm a bit rusty as to the exact steps to take.

I ran openocd in Windows, together with gdb in a VMWare Ubuntu guest. Here is the command line I used:

Code: [Select]
G:\source\rigol\openocd-0.8.0\openocd-0.8.0>bin-x64\openocd-x64-0.8.0.exe -f ./interface/ftdi/olimex-arm-usb-ocd-h-hl.cfg -f ./target/imx28.cfg
Contents of ./interface/ftdi/olimex-arm-usb-ocd-h-hl.cfg

Code: [Select]
#
# Olimex ARM-USB-OCD-H
#
# http://www.olimex.com/dev/arm-usb-ocd-h.html
#

interface ftdi
ftdi_device_desc "Olimex OpenOCD JTAG ARM-USB-OCD-H"
ftdi_vid_pid 0x15ba 0x002b
adapter_khz 6000

ftdi_layout_init 0x0c08 0x0f1b
ftdi_layout_signal nSRST -oe 0x0200
ftdi_layout_signal nTRST -data 0x0100 -noe 0x0400
ftdi_layout_signal LED -data 0x0800


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 0ff on December 11, 2014, 09:50:49 am
Howard, thank you for your writeup, this is really helpful!

I only have 2 additions: You can vastly shorten your config to a single file like this: (and note the increased kHz, the olimex and scope can handle this without any error).
Code: [Select]
source [find interface/ftdi/olimex-arm-usb-ocd-h.cfg]
source [find target/imx28.cfg]
adapter_khz 20000

Then you run it as you said, but for dumping the memory there's no need at all to use gdb. Instead, you can dump it from the openOCD Telnet session like this:
Code: [Select]
$ telnet 127.0.0.1 4444
> halt
> dump_image your_filename_here.bin 0x40000000 0x3FFFFFF

It should take about ~7min to complete at the higher adapter speed.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: swanawood on December 11, 2014, 10:18:55 am
WOW!

Thank you so much for the info!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Howardlong on December 11, 2014, 10:24:55 am
Howard, thank you for your writeup, this is really helpful!

I only have 2 additions: You can vastly shorten your config to a single file like this: (and note the increased kHz, the olimex and scope can handle this without any error).
Code: [Select]
source [find interface/ftdi/olimex-arm-usb-ocd-h.cfg]
source [find target/imx28.cfg]
adapter_khz 20000

Then you run it as you said, but for dumping the memory there's no need at all to use gdb. Instead, you can dump it from the openOCD Telnet session like this:
Code: [Select]
$ telnet 127.0.0.1 4444
> halt
> dump_image your_filename_here.bin 0x40000000 0x3FFFFFF

It should take about ~7min to complete at the higher adapter speed.

That rings a bell, forget what I said about gdb, sorry for the bum steer, the old memory ain't what it used to be! I can't remember what I had to do to stop the CPU I'm afraid, but you do need to do it or the dump won't work.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 0ff on December 11, 2014, 10:25:54 am
Well, you can halt it by just saying "halt" :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Howardlong on December 11, 2014, 10:45:27 am
Oh, you mean like you wrote then. Doh! Sorry, hadn't noticed your halt command. I'll just settle back to my demented old self!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: swanawood on December 11, 2014, 11:09:50 am
Well, you can halt it by just saying "halt" :)

YEP,

as we use to say : "the devil is in details..."

ahah !
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: swanawood on December 11, 2014, 01:33:28 pm
I have a doubt:

the SRST and TRST are cross connected ?

i overlayed the picture with labels, and following the wires, this is what I am ending up... Is it correct ?
(follow the wire going from 10pin connector SRST that seems to go to TRST pin into 20pin connector...)

Thanks

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 0ff on December 11, 2014, 01:35:02 pm
In fact you can just leave SRST unconnected on the scope.
It will power on on it's own.

You just can't reset it from openOCD in this configuration.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: rmd79 on December 11, 2014, 01:39:48 pm
I have a doubt:

the SRST and TRST are cross connected ?

If it helps, here's a picture (attached) of the cable I use with my MSO1074Z-S and OpenOCD.  I can reset from within OpenOCD.  If I remember correctly, I just connected the signals straight through.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: swanawood on December 11, 2014, 01:42:30 pm
In fact you can just leave SRST unconnected on the scope.
It will power on on it's own.

You just can't reset it from openOCD in this configuration.

So , to recap :

to be able to reset from openOCD I need to cut the wire going to pin SRST of the 10 pi header ? (and the TRST is still connected from 10 pin header to SRST of 20 pin header)

Correct ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: soft4gsm on December 11, 2014, 09:45:35 pm
Hello,
I plan to buy one of the following oscilloscopes:
MSO2072A, DS2072A. I'm not sure which one, prefer MSO, but DS is fine too.
1. If it comes with latest software / hardware version, can I use JTAG and memory dump method? Is it working or not?
2. I have SEGGER J-link JTAG. Is it fine, or I should buy other one like olimex for example?
Help me please.
Thank You!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: thn788 on December 12, 2014, 10:33:19 am
Don't worry about JTAG.

I just bought an MSO2000, HW Version 2.2, shipped with firmware 00.03.00 and the SCPI-method posted by HiassofT here https://www.eevblog.com/forum/testgear/rigol-mso2000-series-hacking/msg508992/#msg508992 (https://www.eevblog.com/forum/testgear/rigol-mso2000-series-hacking/msg508992/#msg508992) together with rigup v0.4 still works just fine. No need for scredrivers, soldering irons, JTAG-adapters, other software or anything. Done in 2 minutes (and most of the time you'll need for entering the option key, if you use the scope's GUI... ;-) )
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: radiogeek97 on December 13, 2014, 02:45:43 am
has anybody tryied this update meathod with the latest dsa815's with the 109 firmware and latest bootloader?   im still waiting on buying one
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on December 13, 2014, 11:24:12 am
Thank you rmd79, 0ff and Howardlong!  :-+
The procedure worked flawless with my MSO1074z.  :clap:

It took more time to get the ARM-USB-OCD-H running with Windows 8.1 than doing the memory dump.  :palm:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: rmd79 on December 13, 2014, 11:27:55 am
Thank you rmd79, 0ff and Howardlong!  :-+
The procedure worked flawless with my MSO1074z.  :clap:

It took more time to get the ARM-USB-OCD-H running with Windows 8.1 than doing the memory dump.  :palm:

Haha, I had trouble on Windows 7 with the drivers.. got there in the end.

Good to hear you had success :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on December 13, 2014, 11:58:39 am
Haha, I had trouble on Windows 7 with the drivers.. got there in the end.
Good to hear you had success :)

Thank you for the work you put into this!  :-+

My firmware version: 00.04.01.SP2
Board version: 2.1.1

Cheers
hammy
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Howardlong on December 13, 2014, 09:32:47 pm
Regarding the DSA815 with bootloader 1.04 and firmware 1.09, here is a possible temporary solution...

Firstly, these are not the words of a JTAG god, some other folks clever in that department can look for a less intrusive way to what's proposed here.

You need to have a some trial period left for this: it's dependent on taking back a timer when the unit is switched on - look out Marty. Enabling the write protect on the FRAM (U1105) which appears to be a Fujitsu MB85RC16 seems to make this timer reset at each boot. The WP pin is adjacent to VCC, and it's active high, so you can lift pin 7 from the pad carefully and pop a link to pin 8 (VCC).

It may be that pin 7 is left floating or has a weak pull down other than what's in the chip itself, but equally it could well go off somewhere else, so unless there is evidence otherwise, it's probably better to lift the leg off the board rather than just botch solder across the two pins.

Perhaps a microscope should have been used for this, it's not as neat as it looked under the illuminated magnifier apparently.

(http://i34.photobucket.com/albums/d123/photobucket391/fram_zps26f613ad.jpg) (http://s34.photobucket.com/user/photobucket391/media/fram_zps26f613ad.jpg.html)

Notes...

The way it appears to work is that every 10 seconds when it's on it writes to address 0x200 eight consecutive bytes in little endian format. This appears to be a ticker related to a 400MHz clock, so every ten seconds it's incremented by as near as damn it 4 billion. I guess that's why they use an FRAM and not an EEPROM, the endurance of FRAMs can usually be considered infinite for practical purposes. With an endurance of 10^10 write operations per bit, and one write every 10 seconds, it'll last over 3,000 years by my maths.

The way this FRAM works is a bit different to EEPROMS in the way it's addressed, which confused things a little. There is no pin addressing on the FRAM, it responds to all addresses 50 thru 57, and uses these three bits as the MSBs of the 11 bit address required for addressing purposes.

Perhaps by design (i.e., to stop hacking), unusually the I2C SCL is held low by the master during idle time. This prevents a second master jumping in.

Note that there is more than one I2C bus. The test points marked on the board SCL and SDA are for something else completely, don't waste any time looking at these.

It may be also possible to do some microcontroller thing, and indeed that was the original intention, to auto-sniff the I2C bus and pull down SDA at the appropriate time: being an open drain bus, this is entirely reasonable from an engineering perspective.

Folks may be interested to know that I used an MSO1074Z-S to trigger and decode the I2S, and I take back some of the negative comments I've said before about the decoding feature of this series of scopes. Once you've got your head around its limitations, it's not that bad in practice. The event table though, remains useless due to the limited amount of decode it displays.

Caveats: this may well mean that other things like re-calibration or network settings et al won't save, so I suggest you cal and configure the unit first. I haven't tried changing any non-volatile settings yet. If you're really handy, make an externally accessible jumper. Irrespective, anything that breaks is your responsibility.



Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on December 15, 2014, 08:07:57 am
The way it appears to work is that every 10 seconds when it's on it writes to address 0x200 eight consecutive bytes in little endian format.

...

Caveats: this may well mean that other things like re-calibration or network settings et al won't save, so I suggest you cal and configure the unit first. I haven't tried changing any non-volatile settings yet.

With only 8 bytes, there's no way there's any Cal data there. 

In fact, if each Option had its own independent Trial-time Remaining, I can't see that there would be enough room even for just them in 8B.  I suspect though that each Option is either Unlocked or Trial, and all the Trials are on the same timeout clock?  I don't recall ever seeing differing Time-Remaining values in any of the screen shots posted here, but I may have missed it.

It may be that only 4B of the 8 is used for the Trial-Remaining, and the other 4B being for a Powered-On Time counter (if the Rigols support those).  Otherwise it's likely to be a 2nd copy for validity checking.  (I.e., in the extremely rare case where the power shuts off just as it's writing a new value in, it always has one good copy to fall back on at restart.)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Howardlong on December 15, 2014, 10:32:33 am
I'm pretty sure it's simply a 64 bit counter running at 400MHz.

Here's what I understand happens:

o SA is switched on
o Sets 64 bit 400MHz hardware counter to the 8 bytes read from address 0x200
o Every 10 seconds, 64 bit hardware counter is written back at address 0x200

There is almost certainly other areas of the FRAM used for other things. The trial times I'm aware of are not necessarily the same on the same unit.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on December 15, 2014, 11:08:22 am
There is almost certainly other areas of the FRAM used for other things. The trial times I'm aware of are not necessarily the same on the same unit.

Thanks, Howard.  Yes, you're right.  I had overlooked that you had simply identified a single Option (SA), on the 815.  My mistake.  (For some reason, I was thinking option-block.)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Howardlong on December 15, 2014, 11:43:07 am
Not sure I've explained this very well.

As I understand it, this covers all options with trial time available. There is only one counter, each of the trial times will be a constant, each set when each trial license is installed, and set relative to the single counter (and possibly stored in the FRAM too somewhere). Only that single counter changes. There isn't one counter for each license as I understand it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on December 15, 2014, 06:33:49 pm
Is there an extended system or version info for the ds1000z series?

Cheers
hammy
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on December 15, 2014, 06:55:45 pm
Is there an extended system or version info for the ds1000z series?

There is and there has been a picture to prove it, but he couldn't remember how he got into it and I don't think anyone knows how.  I tried a ton of different key sequences to see if I could get into it but none worked...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on December 15, 2014, 07:35:48 pm
I tried a ton of different key sequences to see if I could get into it but none worked...

The sequence with the "menu" button, right? Didn't worked for me either.  :-//
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: seronday on December 15, 2014, 10:45:08 pm
You can get more detailed information from a saved Parameters Text File.
Press the Storage button, set Storage type to Param, Save to USB drive.
The start of the Parameters Txt file contains the additional info.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on December 16, 2014, 03:42:17 am
Hi
I wanted to share my attempt at using rigup on my MSO1074Z-S with some images to go along
First my Thanks to all for getting this working and a special thanks to rmd79 for his help.  I'm a hobbyist so this was a major purchase and my nerves on end opening my scope up to dump the memory.    The quick of it is I had no problems doing this following the instructions.

I created a pin-out drawing to help me hook things up and is below.   maybe some others will find it helpful

I should have taken more dis-assembly photo's but forgot so the ones I have are after it was disassembled.
I used the tips on YouTube to cleanly remove the warranty sticker which works just as described.

All the screws are star screw and there was a bunch of them including the 4 for the outer case. 

I then hooked up my old Amontec JTAGKey-Tiny (FTDI Based).  I did have some problems with drivers for it under windows 7 but once I got the libusb drivers installed all went well

Connected my JTAG Device to the the scopes header.  I made mine by simply using 10 male to female jumper wires.  plugged them into my header on my JTAG Device and then shrink wrapped it together.
this is the Amontec device (now out of business)

(http://kbobs.org/gallery/albums/userpics/10001/jtagkey_sm.jpg)

and the cable

(http://kbobs.org/gallery/albums/userpics/10001/jtagkey_cable.jpg)
I powered on the scope then pluged in my JTAG device to the PC and Fired up OpenOCD for windows


Code: [Select]
C:\openocd-0.8.0>C:\openocd-0.8.0\bin-x64\openocd-x64-0.8.0.exe -d1 -f C:\openoc
d-0.8.0\scripts\interface\ftdi\jtagkey.cfg -f C:\openocd-0.8.0\scripts\target\im
x28.cfg
Open On-Chip Debugger 0.8.0 (2014-04-28-08:42)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.sourceforge.net/doc/doxygen/bugs.html
debug_level: 1
adapter speed: 6000 kHz
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_de
assert_srst
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
dcc downloads are enabled
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x20000013 pc: 0x40302764
MMU: enabled, D-Cache: enabled, I-Cache: enabled
dumped 67108863 bytes in 1642.825684s (39.892 KiB/s)

I followed that by connecting via putty to 127.0.0.1 4444. Once I had the console typed

Code: [Select]
halt
dump_image mso1074zs.bin 0x40000000 0x3FFFFFF

I probably could have run my Amontec device faster as it's the same chip as the Olimex one is but I choose to run it a 6Mhz which took about 21 minutes to dump

I then ran rigup on the output file on a VM Linux instance
Code: [Select]
./rigup scan mso1074zs.bin > mso1074zs.txt[/td]
then generated all licenses with
Code: [Select]
for code in 0x1C001 0x1C002 0x1C004 0x1C008 0x1C010 0x1C020 0x1C040 0x1C080 0x1C0FF
do
echo "Generating $code License"
./rigup license mso1074zs.txt $code
done > mylicenses.txt

Everything else was by the book to apply the codes

Here are all the images I took.  Hope you do not mind the long post

JTAG Header with Pinout.  I hope this one helps some others in the future doing this

(http://kbobs.org/gallery/albums/userpics/10001/MSO1074Z-S-JTAGPORT.jpg)

Showing Upgraded to MSO1104Z-S

(http://kbobs.org/gallery/albums/userpics/10001/MSO1074Z-S_025.png)

All Licenses Applied

(http://kbobs.org/gallery/albums/userpics/10001/MSO1074Z-S_026.png)

Checking out the Rise Time

(http://kbobs.org/gallery/albums/userpics/10001/MSO1074Z-S_028.png)

Source Generator BNC Connectors (these are the ones Dave was wondering how they added the Source Generator)

(http://kbobs.org/gallery/albums/userpics/10001/MSO1074Z-S_007_sm.jpg)

Source Generator Daughter Board (and here's the Answer, It's a daughter board way on the other side of the PCB)

(http://kbobs.org/gallery/albums/userpics/10001/MSO1074Z-S_006_sm.jpg)

Main Board

(http://kbobs.org/gallery/albums/userpics/10001/MSO1074Z-S_003_sm.jpg)

Quote
EDIT:  I added the openocd console output,  thought some might like to see it
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mark_O on December 16, 2014, 06:43:12 am
Thanks, smgvbest.  That was nicely done.   :-+  Pictures are always welcome, so don't fret about the length.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JBR48 on December 16, 2014, 07:58:27 am
A very clear exposition of all the steps. Very helpful!
Thank you smgvbest.


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: msraya on December 16, 2014, 08:16:06 am
My Hat's Off to You Mr Smgvbest!!  :clap:

I am afraid of break the sticker, but now I will go!!  :-DD
You makes the process look simple and self-explained.

Thank You!
Manuel
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on December 16, 2014, 08:23:34 am
Actually is Ms. 

Sandra   
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: msraya on December 16, 2014, 01:39:10 pm
Oh! I'm sorry Sandra  :palm:

The rate of women/men EEngineering students at my University, here in Spain is very bad indeed.
So I suppose the wrong.

I will try to use the JTAG with my oscilloscope and will update when it succeeds.
Regards
Manuel
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on December 16, 2014, 01:43:12 pm
Actually is Ms. 

Sandra

Awesome!

I hate that folks here are always assumed to be men.  I have four daughters who all show promise in being engineers of one type or another.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on December 16, 2014, 02:24:58 pm
I actually wanted to be a computer engineer specially designing CPU's but just could not pull of the finances so ended up going the electronics technician route right when they were a dine a dozen in Calif so ended up of all things a mainframe system programmer but have kept my electronics training alive as my hobby.  but still have allot to learn
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Howardlong on December 16, 2014, 02:46:32 pm
My Hat's Off to You Mr Smgvbest!!  :clap:

I am afraid of break the sticker, but now I will go!!  :-DD
You makes the process look simple and self-explained.

Thank You!
Manuel

Manuel, if you follow Mike's instructions here http://youtu.be/KGcNS5g9ygg (http://youtu.be/KGcNS5g9ygg) you won't break the sticker. The trick is to be patient, it might take five or ten minutes. I then also protect the loose end and its adhesive with some of the sticker backing paper and a little DIY paper envelope taped to the enclosure.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on December 16, 2014, 04:10:36 pm
My Hat's Off to You Mr Smgvbest!!  :clap:

I am afraid of break the sticker, but now I will go!!  :-DD
You makes the process look simple and self-explained.

Thank You!
Manuel

Manuel, if you follow Mike's instructions here http://youtu.be/KGcNS5g9ygg (http://youtu.be/KGcNS5g9ygg) you won't break the sticker. The trick is to be patient, it might take five or ten minutes. I then also protect the loose end and its adhesive with some of the sticker backing paper and a little DIY paper envelope taped to the enclosure.

That's the one I followed and it works fine.   Thanks for posting the link
Patients is definitely the key to removing it intact.  It took me closer to 10 minutes to remove mine.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rigby on December 16, 2014, 04:21:09 pm
I actually wanted to be a computer engineer specially designing CPU's but just could not pull of the finances so ended up going the electronics technician route right when they were a dine a dozen in Calif so ended up of all things a mainframe system programmer but have kept my electronics training alive as my hobby.  but still have allot to learn

get into FPGAs.  you can design CPUs all day long, and FPGAs are how CPUs are designed & prototyped nowadays.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on December 16, 2014, 07:11:29 pm
0,35 / (2,450s x 10^-9) = 142,85 MHz

 :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on December 16, 2014, 10:19:05 pm
I actually wanted to be a computer engineer specially designing CPU's but just could not pull of the finances so ended up going the electronics technician route right when they were a dine a dozen in Calif so ended up of all things a mainframe system programmer but have kept my electronics training alive as my hobby.  but still have allot to learn

get into FPGAs.  you can design CPUs all day long, and FPGAs are how CPUs are designed & prototyped nowadays.

I had thought about that.   IBM has been designing mainframes that way since the late 90's early 2K's I believe.   When In poughkeepsie where IBM does hardware development I got to see the next gen mainframe at that time and they basically said the entire box was nothing but a programmable array. 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on December 16, 2014, 10:44:02 pm
...

I hate that folks here are always assumed to be men.
Well, but clearly is not very common, unfortunately.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on December 17, 2014, 12:58:01 am
...

I hate that folks here are always assumed to be men.
Well, but clearly is not very common, unfortunately.

I'm sure if guys where called Ms all the time they'd see it differently  ;)
I will say this.  back in 1985 when I was in tech school (AS degree in electronics, far as i was able to get) in my graduation class of about 97 students,  about 30 where women it's not have but its not a small amount either

I edited this slightly to help people understand my comment was meant in fun. i.e. the wink
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Leiothrix on December 17, 2014, 03:20:24 am
I'm sure if guys where called Ms all the time they'd see it differently

I'm a guy and I don't particularly care.

It just depends on the gender balance of where you are (whether IRL or online), it doesn't mean anything.  Depending on the maturity level of the place it's probably better to be lumped in with the majority by assumption.

If you want to avoid (most) wrongly gendered pronouns you can pick a strongly gendered name.  That has it's own problems in some places, but I don't think this board is one of them where gender matters.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Howardlong on December 21, 2014, 05:23:50 pm
Here are some further notes regarding the DSA815 with bootloader 1.04 and firmware 1.09.

If the WP on the FRAM is disabled, I understand that the network parameters and startup parameters can't be changed.

The WP does not connect to anything, it has a weak pull down internally, so it would appear that just shorting pins 7 & 8 (WP & VDD) would stop the FRAM being updated with the time-on-since-new every 10 seconds, suggesting that there is no need to lift pin 7.

Furthermore, although the I2C SCL line is held low, there is a short period at power up time, about 400ms, when the SCL line is pulled high to VDD with a standard I2C pullup. Both SCL and SDA are open drain high at this point.

By performing a re-write of the time-on-since-new within this 400ms timeframe apparently it is possible to reset the time without disabling the updating of non-volatile parameters.

(http://i34.photobucket.com/albums/d123/photobucket391/P1040196-Copy_zps47b3d4ae.jpg) (http://s34.photobucket.com/user/photobucket391/media/P1040196-Copy_zps47b3d4ae.jpg.html)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: kwass on December 21, 2014, 05:35:44 pm
That's the one I followed and it works fine.   Thanks for posting the link
Patients is definitely the key to removing it intact.  It took me closer to 10 minutes to remove mine.

Sandra,

I used a heat gun from a few inches away and the sticker peeled away in seconds, then stuck back on like new.  I just went inside this machine to change the noisy fan to something I could tolerate, nothing so elaborate as you did.  Nice work!

-Katie

(p.s.  I too had a lot of women in my computer science graduate school class of 1985, but it's gotten really bad since then.)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: phersus on December 21, 2014, 07:20:00 pm
Hello Guys,

Incredible and fantastic job, congrats to all who participated directly or indirectly to this success.  :clap:

I am, as many here, a hobbyist. I also have an MSO1074z and want to go through the unlocking process.
After many tries under mac OS X all of them unsuccessful (openocdb works but the Olimex Jtag adapater not being recognised) I decided to try it under Windows.

Under Windows I could go a little farther, however still stuck and want to ask the ones who have been playing with this if when plugging the Jtag adapter to the PC the target device needs to be connected as well. The reason I'm asking is that I've not yet opened the oscilloscope; I wanted to test that openocd and the Olimex Jtag adapter are working first.

Any guidance would be really appreciated.

Thanks a lot,
Gus
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on December 21, 2014, 07:31:35 pm
Hi,

yes, the device needs to be connected to the ARM-USB-OCD-H jtag port first. Then you can plug it into the pc and start openocd and it will open the device. If nothing is connected some message like "open device failed" shows up.

Cheers
hammy
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: phersus on December 21, 2014, 08:54:54 pm
Thank you hammy,

In that case ... I will open the oscilloscope and move forward.

Cheers,
Gus
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Howardlong on December 21, 2014, 09:11:43 pm
Here are some further notes regarding the DSA815 with bootloader 1.04 and firmware 1.09.

If the WP on the FRAM is disabled, I understand that the network parameters and startup parameters can't be changed.

The WP does not connect to anything, it has a weak pull down internally, so it would appear that just shorting pins 7 & 8 (WP & VDD) would stop the FRAM being updated with the time-on-since-new every 10 seconds, suggesting that there is no need to lift pin 7.

Furthermore, although the I2C SCL line is held low, there is a short period at power up time, about 400ms, when the SCL line is pulled high to VDD with a standard I2C pullup. Both SCL and SDA are open drain high at this point.

By performing a re-write of the time-on-since-new within this 400ms timeframe apparently it is possible to reset the time without disabling the updating of non-volatile parameters

Howardlong:

What are the consequences of disabling updating of the non-volatile memory for the Start-Up Parameters?  Does this just mean that we can't - 1. change the SA815's network address from its default, and/or 2. change the Power ON from its Default (vs. the 'Last configuration settings')?

If we don't care about these two things, then would it be Ok to just solder Pin 7 and 8 of the FRAM (U1105) together. or is there something else that could also be affected?

The FRAM was lifted and WP pad was visually inspected, and also mesured for any protection diodes to both Vss and Vdd. There was no indication that the WP pad was connected to anything.

The consequences are unknown other than that documented already.

What should be noted though is that very early on in the initialisation, there is a test write of 0x01 to address 0x0A of the FRAM at I2C address 0x50, and it is read back. In a non-write protected scenario, it reads back 0x01, and immediately re-writes 0x00. In a write protected scenario, the read back is 0x00, and it doesn't try to write back anything at that stage. What happens as a result of that is unknown as I understand it.

There may indeed be other consequences.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Howardlong on December 21, 2014, 09:26:46 pm
Sorry, to add, there was not a large amount of testing, other than to note that on a brief test it was noted that left as a DHCP client all was fine. Attempting to change to a fixed IP address failed with WP on. With WP off a fixed IP addres was fine.

Regarding the power on settings, little testing was done other than to note that the unit would no return to the same state when powered off and the power up setting requested it to do so. Being able to restore state from a file (internal, USB not tested) still functioned correctly.

It is unclear what, if any, calibration settings are saved in FRAM, or indeed anything else.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on December 22, 2014, 07:57:31 pm
I've patched with these files, the FRAM of the DS2000. Seems to be similar to the DSA815...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Howardlong on December 22, 2014, 10:22:38 pm
I was aware of your work, although the FRAM chip in the DAsA815 is not quite the same as I understand it. The I2C and byte addressing is a little different, and the "window of opportunity" isn't the same. Also the development expertise in the DSA815 shown here is in PICs and not Arduino, and the PICs don't have that semi compatible footprint.

Were you resetting the time-since-on or something else?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: phersus on December 23, 2014, 11:36:51 am
Hello Guys,

Anyone who can show me what does the imx28.cfg file contain ? Or point me where I can find it ?

If the context is not clear I'm talking about the command to launch openocd, something like:

G:\openocd-x64-0.8.0.exe -f ./interface/ftdi/olimex-arm-usb-ocd-h-hl.cfg -f ./target/imx28.cfg

Thanks,
Gus
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MadDog on December 23, 2014, 11:53:54 am
Hi Gus,

imx28.cfg is a part of openocd. Create your own *.cfg file like "Off" has shown in reply #3740:

source [find interface/ftdi/olimex-arm-usb-ocd-h.cfg]
source [find target/imx28.cfg]
adapter_khz 20000

I have done this some days ago with a non -H olimex adapter (olimex-arm-usb-ocd.cfg), I had to reduce the frequency to 5000kHz.

Many thanks to those who have made this possible and who have shared their knowledge!  :clap:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: phersus on December 23, 2014, 11:58:24 am
Hi again,

Thank you MadDog,

Now it makes more sense those commands, I've seen them but didn't understand why they were there  :palm:
OK, if they are part of the openocd install it is clear.

I will give them a try now,

Cheers.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dr.diesel on December 25, 2014, 11:05:12 pm
Looks like a new firmware available for the 815:

DSA815: 00.01.12

From:

http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm (http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: msraya on December 26, 2014, 11:08:12 pm
No luck with the icebear JTAG  :( ...

The memory dump stop at 6542Kb, the openocd 0.8.0 output is: timeout waiting for syscomp & dbgack last dbg_status: 4
And rigup does not find any keys.

I do not have idea, I will find a solution when I have time....
The cfg files:

Code: [Select]
interface ftdi
ftdi_device_desc "ICEbear JTAG adapter"
ftdi_vid_pid 0x0403 0xc140

ftdi_layout_init 0x0028 0x002b
ftdi_layout_signal nTRST -data 0x0010 -oe 0x0010
ftdi_layout_signal nSRST -data 0x0020

adapter_khz 5000

# i.MX28 config file.
# based off of the imx21.cfg file.

reset_config trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst

#jtag nTRST and nSRST delay
adapter_nsrst_delay 100
jtag_ntrst_delay 100

if { [info exists CHIPNAME] } {
   set  _CHIPNAME $CHIPNAME
} else {
   set  _CHIPNAME imx28
}

if { [info exists ENDIAN] } {
   set  _ENDIAN $ENDIAN
} else {
   set  _ENDIAN little
}


# Note above there is 1 tap

# The CPU tap
if { [info exists CPUTAPID] } {
   set _CPUTAPID $CPUTAPID
} else {
   set _CPUTAPID 0x079264f3
}
jtag newtap $_CHIPNAME cpu  -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID


# Create the GDB Target.
set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME arm926ejs -endian $_ENDIAN -chain-position $_TARGETNAME -variant arm926ejs

arm7_9 dcc_downloads enable


Regards
Manuel
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on December 27, 2014, 05:35:31 am
I can not see the im28.cnf being an issue as that is processor specific where as the ICEBear itself is not.
I did see in the icebear.cfg file that they warn it is not tested on actual hardware.

Code: [Select]
#
# Section5 ICEBear
#
# http://section5.ch/icebear
#

[b]echo "WARNING!"
echo "This file was not tested with real interface, it is based on code in ft2232.c."
echo "Please report your experience with this file to openocd-devel mailing list,"
echo "so it could be marked as working or fixed."[/b]

interface ftdi
ftdi_device_desc "ICEbear JTAG adapter"
ftdi_vid_pid 0x0403 0xc140

ftdi_layout_init 0x0028 0x002b
ftdi_layout_signal nTRST -data 0x0010 -oe 0x0010
ftdi_layout_signal nSRST -data 0x0020

I found this and maybe you want to give this config a try

Create your own icebear.cfg file with these contents and use it instead of the supplied one.

Code: [Select]
#
# Section5 ICEBear
#
# http://section5.ch/icebear
#
 
interface ft2232
ft2232_device_desc "ICEbear JTAG adapter"
ft2232_layout icebear
ft2232_vid_pid 0x0403 0xc140

I hope it works for you
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mythbu on December 27, 2014, 09:43:02 am
Hi Guys,

I don't want to disturb, but I have bought me my first oscilloscope - a Rigol MSO1074Z. Yesterday I discovered that the ability of decoding RS232 information is only trial. But the advertisement said, that this is a feature. So I tried to generate a key with the software from "http://gotroot.ca/rigol/". But no success yet. When I now enter a key it displays a message that installation is blocked for 12 hours (also mentioned on page ~ 126 of this thread). So I interpret this as a "NO" and retry in 12 hours. The numbers are:

Model: MSO1074Z
Serial: DS1ZC1xxxxxxxx
Firmware: 00.04.01.SP2
Board: 2.1.1

I've tried the private key 0x6f1106... for DS1000Z series with options DSFR and CSAR without success. I need to retest the private key 0x99fc5... MSO1000Z series for CSAR but I don't think that this will work (because I have possibly tested this).

So could you provide me some help. Do I have the right private key and/or "feature" codes (DSFR, CSAR, ...)? Isn't there a reset possibility to bypass the 12 hour waiting time?

Greetings from Germany,
mythbu
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: msraya on December 27, 2014, 10:32:34 am
Thank You , Sandra.

I have no time right now to again disassemble the scope, I will test it within several weeks.
I compiled the openocd 0.8.0 with new ftdi library, so old interface ft2232 i think not work anymore. However i will try.

I think that slow down the interface can be the solution.

Mythbu, you must get a JTAG adapter, install openocd, dissasemble the scope and follow the Sandra's Tutorial back in 252 page of thread. Good Luck!  :-//

Happy new year!!
Manuel
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on December 27, 2014, 10:39:42 am
So could you provide me some help. Do I have the right private key and/or "feature" codes (DSFR, CSAR, ...)? Isn't there a reset possibility to bypass the 12 hour waiting time?

Look starting at the message from 0ff
msg565557 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg565557/#msg565557) and from that message forward several of us discussed and detailed how to do it.

Basically you have to open your scope up and use a JTAG programmer to dump memory then use rigup to get the private key then use rigup again to generate the keys.  riglol does not work for the MSO1000Z series.
I posted here where I did this for reference. msg569236 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg569236/#msg569236)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: KD0RC on December 27, 2014, 09:11:03 pm
Looks like a new firmware available for the 815:

DSA815: 00.01.12

From:

http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm (http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm)
So has anyone tried this yet?  I am on 01.09, bootloader 01.03.  I am afraid to try it until I know it will not 'un-hack' the box...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Howardlong on December 27, 2014, 11:32:38 pm
I doubt you are alone...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mhwlng on December 28, 2014, 09:30:04 am
All my license settings (VSWR etc.) were preserved when I updated from 01.09 -> 01.12
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dr.diesel on December 28, 2014, 12:28:48 pm
All my license settings (VSWR etc.) were preserved when I updated from 01.09 -> 01.12

Any chance you got a change log with your update?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mhwlng on December 28, 2014, 12:47:26 pm
Quote
Any chance you got a change log with your update?

no, sorry...

I think that one new feature may be that the x-axis can now be logarithmic ? (span button -> x scale -> log)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NortliW on December 28, 2014, 03:38:33 pm
Is there already any progress on the DSA1030? I can post f.w.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: calunga on December 28, 2014, 06:28:09 pm
Ufa !!! at last able to get until I come accompanied this topic from page 160 and personnel bought the DS2072A in October this year and would like to unlock it possible for all functions see that it came with a new firmware Caribe; the question this if there is possibility of release via solft connected by USB or network port or use will be necessary for a w JTAG interface before hand bought a USB AMENDING interface and even the time has not yet arrived but with the ALTERA not serve'll buy the ARM-USB-OCD-H I see comments from friends to be the best interface in order to make this service tale with the help of this wonderful forum friends ... Thanks !!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: KD0RC on December 29, 2014, 04:31:46 pm
All my license settings (VSWR etc.) were preserved when I updated from 01.09 -> 01.12

Any chance you got a change log with your update?
I just got the upgrade, but there was no change log.  I sent an e-mail to see if I can get one, and if so, I will post it here.  I am not going to upgrade until I have a better feel for this...  The log frequency scale sounds cool although most of my work is done in narrow enough chunks of spectrum to not really need it.

@mhwlng, did the bootloader version change with this upgrade?  Mine is still at 01.03.

Len
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Pasky on December 29, 2014, 04:59:53 pm
Apologies in advance if this was answered somewhere in this large thread, but is there any work on a firmware upgrade for the DG4xxx (4062, 4102, 4162) signal generators?  All three models appear to use the same hardware and it looks like it's just the firmware keeping them from higher bandwidths.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mhwlng on December 29, 2014, 06:32:58 pm
Quote
@mhwlng, did the bootloader version change with this upgrade?  Mine is still at 01.03.
bootloader is still 01.03

Quote
Any chance you got a change log with your update?
change log : DSA800(DSP)Version Notes.doc
Version 00.01.12.00.02
Date 2014-11-10

Increase the frequency offset function.
Increase the switch between local and remote command.
Increase the frequency of logarithmic function
Increase the key lock function.
Increase the traditional Chinese features.
Increased access to frequency reference the status of a remote command.
Increase sanitation function.
Increase in Peak List can turn off the display line.
Modify the option name information directly display option.
Modify the Trace preservation order in CSV format, from a list of changes to the three column.
To improve the quality of AM demodulation.
Modify the “Clear All” for “Blank All”, and redefine the “Clear Write”.
To solve the problem of inaccurate measurement of N dB.
To solve the problem of freq Count is not accurate.
To solve the problem of error loading an State file
To solve the problem TX1000 instrument connection after the crash.
The lower limit of TG range from -30dBm to -20dBm.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: KD0RC on December 29, 2014, 07:30:23 pm
Chinglish at its best - 'Increase the sanitation function'...  Does this mean an upgrade to the flush handle?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Howardlong on December 29, 2014, 08:04:34 pm
Increasing the lower TG limit from -30dBm to -20dBm is a downgrade in my eyes.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: KD0RC on December 29, 2014, 09:02:27 pm
Chinglish at its best - 'Increase the sanitation function'...  Does this mean an upgrade to the flush handle?

KD0RC:

In a way you are correct, but it means that the next time you click on 'Clr Int Cal' you are going to loose the TG completely, NOT just its Calibration.  BTW did you ever get your TG Calibration back?
Well, I see the X Scale (Log Lin) function when I hit the Span button, and that seems to work.
If I hit the System button and go to page two, I see a new function, 'Sanitation'.  Press it, and you get two options, OK and Cancel.  Anyone have any idea what that does?  (Anyone brave enough to click OK?)
The tracking Generator output now goes from 0 to -20 dBm.  Not sure why they changed this from -30 dBm.

Wall-E - no, I do not have my TG cal back.  I am hoping someone figures out a way to do the cal.  Nothing that I have played with seems to have any effect.  Service mode looks like it works the same - I don't see any new functions that look like they let you do a TG cal manually.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mhwlng on December 29, 2014, 09:11:22 pm
Quote
'santitation function' Anyone have any idea what that does? 
According to this manual (july 2014) :
http://www.ame-hft.de/pdf/dsa800_userguide.pdf (http://www.ame-hft.de/pdf/dsa800_userguide.pdf)

Press Sanitation to clear all data set by user and restore them to factory settings.
The user data saved in the NVRAM and NorFlash are restored to factory settings.
HOST NAME, IP address and password in LXI are restored to factory settings.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Howardlong on December 29, 2014, 09:52:22 pm
Increasing the lower TG limit from -30dBm to -20dBm is a downgrade in my eyes.

This is kind of like RPN (Reverse Polish Notaion) because I believe they meant to say that the TG Output lower limit was changed from -20dBm to -30dBm.

...except that the default TG setting on the example I have here without the "upgrade" is already -30dBm, so I fear they're heading in the wrong direction. For some high gain low noise preamps, -20dBm will be a very strong signal indeed. Yet more external attenuation I guess!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: phersus on December 30, 2014, 01:12:27 pm
Hello Guys,

First of all: Happy New Year ... a little in advance but as many, family will keep me away from the forum for a while so ...  ^-^

I've been trying the memory dump of my MSO1074Z, I'm using an OLIMEX JTAG header (the same model as referenced here by different members), I use MAC OS X and Windows 7 (Enterprise, 32 bits) without success (so far).

Some of you have helped me to do some progress (thank you for that!), however still stuck; I should be doing some stupid thing I think  |O

I wanted to confirm with you, I was wondering if I should turn the oscilloscope ON when trying the dump (?)

My problem seems to come from the USB driver for the OLIMEX header (in both MAC OS X and Windows)
I used the zadig (ver 2.1.1) tool (in the Windows environment, which is a real one not a virtual machine) to install the drivers (tried the three proposed by the tool) and I had the same error message: no device found.

In the MAC is not any better, I installed and locally compiled several tools without any success.

Any suggestion ? I really don't care which OS can make it, I'm using these two basically because is what I have at home, I could even use Linux virtual machines (I have Debian and Fedora already installed and running) but considered that if with the real hardware I'm not getting good results adding and extra layer of complexity wouldn't help at all.

Any advice will be appreciated!

Gus

 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Howardlong on December 30, 2014, 01:45:38 pm
Yes, the scope should be on and booted. The dump process will freeze the scope though.

FWIW, the dump I had was on a Mac Mini 2012 Server running Windows 8.1 x64 which has its own problems, not least that as I remember I had to switch off enforced driver signing.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: phersus on December 30, 2014, 02:21:55 pm
Thank you Howardlong,

I got the same result in Windows and MAC OS X (at least the error is coherent  :P )

This is the error message I'm getting:

phersus@MacBooKs-MBP:~$ openocd -d1 -f ./interface/olimex-arm-usb-ocd-h.cfg -f ./target/imx28.cfg
Open On-Chip Debugger 0.8.0 (2014-12-23-13:24)
Licensed under GNU GPL v2
For bug reports, read
   http://openocd.sourceforge.net/doc/doxygen/bugs.html (http://openocd.sourceforge.net/doc/doxygen/bugs.html)
debug_level: 1
adapter speed: 20000 kHz
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
dcc downloads are enabled
Error: no device found
Error: unable to open ftdi device with vid 15ba, pid 002b, description 'Olimex OpenOCD JTAG ARM-USB-OCD-H' and serial '*'
in procedure 'init'

Any suggestion on what to try next ?

Gus
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Wall-E on December 30, 2014, 06:37:59 pm
Quote
@mhwlng, did the bootloader version change with this upgrade?  Mine is still at 01.03.
bootloader is still 01.03
mhwlng:
Re DSA815 with firmware 00.01.12.00.02:  Can you please show us, or describe what the Full Scan (on initial boot-up, or after pressing the Preset button) looks like with the Scan set to to X = Log (for the Log. Frequency display).  Thank you in advance.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mhwlng on December 30, 2014, 07:13:17 pm
mhwlng:
Re DSA815 with firmware 00.01.12.00.02:  Can you please show us, or describe what the Full Scan (on initial boot-up, or after pressing the Preset button) looks like with the Scan set to to X = Log (for the Log. Frequency display).  Thank you in advance.

As requested, see attached :
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Wall-E on December 30, 2014, 07:54:22 pm
mhwlng:
Re DSA815 with firmware 00.01.12.00.02:  Can you please show us, or describe what the Full Scan (on initial boot-up, or after pressing the Preset button) looks like with the Scan set to to X = Log (for the Log. Frequency display).  Thank you in advance.
As requested, see attached :
Thank you 'mhwlng', we are both seeing the same results.  I thought that this was Ok, and I feel better confirming it.  The Rigol DSA815 also works well down to 9kHz as long as you set the Freq. Span., RBW, etc. for the appropriate Log. Freq. measurements.   Thank you, Wall-E
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pa3bca on December 30, 2014, 08:12:06 pm
I know I can request the latest DSA815-TG firmware (00.01.12.00.02) from Rigol, but, but...
Is there anyplace I can download this version directly?
I really would like to have that Log x-axis.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hpux735 on December 31, 2014, 02:37:04 am
Increasing the lower TG limit from -30dBm to -20dBm is a downgrade in my eyes.

This is kind of like RPN (Reverse Polish Notaion) because I believe they meant to say that the TG Output lower limit was changed from -20dBm to -30dBm.

...except that the default TG setting on the example I have here without the "upgrade" is already -30dBm, so I fear they're heading in the wrong direction. For some high gain low noise preamps, -20dBm will be a very strong signal indeed. Yet more external attenuation I guess!

I just checked on mine.  I have 01.08 and my TG only goes down to -20dBm.  What firmware are you running?  The extra 10dB of attenuation would be more valuable to me than a logarithmic x axis (though, I wouldn't turn it down).  Is there any definitive word on TG amplitude in 01.12 and whether all the riglol hacks still work?

Thanks!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Howardlong on December 31, 2014, 02:55:53 am
It's 1.09.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Teneyes on December 31, 2014, 11:55:34 pm
New Firmware for DS1000Z and MSO/DS2000 Here
 (https://www.eevblog.com/forum/blog/eevblog-683-rigol-ds1000z-ds2000-oscilloscope-jitter-problems/msg578208/#msg578208)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: KD0RC on January 01, 2015, 08:26:21 pm

I just checked on mine.  I have 01.08 and my TG only goes down to -20dBm.  What firmware are you running?  The extra 10dB of attenuation would be more valuable to me than a logarithmic x axis (though, I wouldn't turn it down).  Is there any definitive word on TG amplitude in 01.12 and whether all the riglol hacks still work?

Thanks!

TG output now definitely goes from 0 to -20 dBm with firmware version 01.12.00.02 and all hacks stay in place.

Len
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Sparky on January 01, 2015, 09:07:11 pm
To those experiencing the "License is unavailable!" message that appears on some MSO/DS2000A series scopes when trying to install bandwidth options (200 or 300MHz), it turns out that a solution to this problem has been known since late June 2014!  Read on...

I encountered the above error a couple of months ago (read here (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg541236/#msg541236)) and searched the forums but didn't find any solution (must have been poor searching on my part...), and so started an investigation into the obvious possibilities of hardware differences, key generator differences, etc. Read here (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg542780/#msg542780) and here (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg547665/#msg547665).

Yesterday I read this post (https://www.eevblog.com/forum/testgear/rigol-mso2000-series-hacking/msg578014/#msg578014) regarding the same problem which mentions "NS8N" code for the key generation.  As far as I could find, NS8N was discovered way back on June 25 2014 by Purevector (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg467781/#msg467781). 

I found a few other references to use of NS8N related to 300 MHz bandwidth unlocking:
June 27 2014 by KK (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg468842/#msg468842) (mentions "patched key generator" but not NS8N)
June 27 2014 by Purevector (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg468951/#msg468951)
July 8 2014 by AintBigAintClever (https://www.eevblog.com/forum/testgear/ds2072a-s-hackable-or-not/msg475696/#msg475696)
August 31 2014 by sm5uiu (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg504647/#msg504647)

I applied an NS8N generated key (for the MSO2072A which gave the "License is unavailable!" message for an NS8H generated key, as output by rigup by default), and it worked.  See below for details.

So, there's definitely some mystery surrounding option keys, and why some MSO/DS2072A units need to use different codes for bandwidth, but not other options (memory, decodes, etc).

Edit: Added following details:

You can use the precompiled rigup 0.4 to generate license codes for keys other than the default NS8H, etc. as follows.

Code: [Select]
C:\Users\Me\Desktop\rigup-0.4>rigup scan 32M_MemDump.scpi > keys.txt

C:\Users\Me\Desktop\rigup-0.4>rigup license keys.txt NSEH
rigup license - Version 0.4
ABCEEFG-ABCEEFG-ABCEEFG-ABCEEFG    (NSEH = 0x1C087)

C:\Users\Me\Desktop\rigup-0.4>rigup license keys.txt NS8N
rigup license - Version 0.4
ABCEEFG-ABCEEFG-ABCEEFG-ABCEEFG    (NS8N = 0x1C0C3)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: TitusPullo on January 02, 2015, 09:11:24 am
Yes Sparky, I can confirm that. I tried the suggested codes from rigup, but only one (the 100MHz) worked.
By using NS8N instead of NS8H I could activate the 300MHz. From what I gather these codes were "guessed" by trial and error (didn't cybernet write a short routine for that?).
I believe some small detail may be still missing there.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: whotopia on January 04, 2015, 02:42:34 pm
I have a DS2072A with the latest firmware (with the jitter patch).  I cleared out all the options but due to previous efforts have serial number of DS2A0000000001.   Is there guidance on how to restore this in the FRAM to the correct value? e.g. in case I want to sell the unit? 

DS2A0000000001> *IDN?
RIGOL TECHNOLOGIES,DS2072A,DS2A0000000001,00.03.03.SP1


More details on the scope:

Model: DS2072A
Serial: DS2A0000000001
Software Version: 00.03.03.01.00

FPGA Version:
  SPU: 04.01.04
  WPU: 01.01.03
  CCU: 12.29.00
  MCU: 02.13


I should add that I've tried older howtos on this board via the SNMODFIX program / firmware downgrade.  This works, until I flash to new firmware and then I loose the Serial Number again, the default value as above appears along with the correct model, DS2072A.   One other question I have is that I am choosing Model 16 - ds2072 when I patch the .GEL file.   However, I actually have a DS2072A.  Does anyone know what the model code 0-127 is for my model?    Oh, also, my actual serial number starts with DS2D.........  .

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: radiogeek97 on January 06, 2015, 01:14:31 am
As I promised in previous pages of this thread.  I finally purchased a dsa815tg  from t-equipment, that being said I am willing to experiment and post in the forum for those that want to work around the locked bootloader issue and some others.  I will post all the hardware information when i recieve the unit later.  if folks want to PM me or post in this thread on things they would like to try, i will do my best to help everybody
thanks again
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on January 06, 2015, 11:41:57 am
after some quiet xmas holidays ....

u-boot preliminary support is done.
linux 3.17 is also booting (tftpboot), but no framebuffer driver (yet) - working on it.

TODO:

fix USB support in kernel/uboot - to support keyboard on the host port
add framebuffer driver to linux
start playing with the hardware, reversing the FPGA interface would be nice to get some samples from the AD
play with DSA815, DG4XXX

DONE:

LCD interface (in part)
Keyboard
LED Front Panel

some IDEAS:
FRAM backup/restore via U-Boot Command
FLASH backup via U-Boot Command
use u-boot to start the rigol LDR instead of their crappy bootloader - then patch it on the fly (e.g. overwrite ECC keys/funcs or model strings etc ..)
reverse engineer the FPGAs and use the board as an open source oscilloscope platform

if somebody wants to test or join development let me know. i will update my wiki the next few days and put u-boot and a linux kernel online (+ patches).
for now i only work with the DS2000 because that allows booting a custom LDR without any hardware mods or even the need to open the device.

Code: [Select]
bfin> bootm
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   bf526-0.0-3.16.0-ADI-2014R1-prec
   Created:      2015-01-05   2:54:11 UTC
   Image Type:   Blackfin Linux Kernel Image (gzip compressed)
   Data Size:    4415220 Bytes = 4.2 MiB
   Load Address: 00001000
   Entry Point:  0028cdc0
   Verifying Checksum ... OK
Linux version 3.16.0-ADI-2014R1-precybernet-00397-g4d88578-dirty (cn@cynlaptop) (gcc version 4.3.5 (ADI-2013R1-RC1) ) #15 Mon Jan 5 03:54:08 CET 2015
register early platform devices
bootconsole [early_shadow0] enabled
Board Memory: 32MB
Kernel Managed Memory: 32MB
Memory map:
  fixedcode = 0x00000400-0x00000490
  text      = 0x00001000-0x001b6b68
  rodata    = 0x001b6b68-0x0024939c
  bss       = 0x0024a000-0x002604e8
  data      = 0x00260500-0x00284000
    stack   = 0x00282000-0x00284000
  init      = 0x00284000-0x00573000
  available = 0x00573000-0x01f00000
  DMA Zone  = 0x01f00000-0x02000000
Hardware Trace active and enabled
Boot Mode: 1
Blackfin support (C) 2004-2010 Analog Devices, Inc.
Compiled for ADSP-BF526 Rev 0.0
Warning: Compiled for Rev 0, but running on Rev 2
Blackfin Linux support by http://blackfin.uclinux.org/
Processor Speed: 400 MHz core clock and 100 MHz System Clock
 boot memmap: 0000000000573000 - 0000000001f00000 (usable)
On node 0 totalpages: 7936
free_area_init_node: node 0, pgdat 00281350, node_mem_map 00575000
  DMA zone: 62 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 7936 pages, LIFO batch:0
NOMPU: setting up cplb tables
Instruction Cache Enabled for CPU0
  External memory: cacheable in instruction cache
Data Cache Enabled for CPU0
  External memory: cacheable (write-back) in data cache
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0
Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 7874
Kernel command line: netconsole=6666@10.146.248.28/eth0,6666@10.146.248.20/0:30:48:db:6:6 mem=32M
PID hash table entries: 128 (order: -3, 512 bytes)
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Kernel managed physical pages: 7936
Memory: 25836K/31744K available (1750K kernel code, 142K rwdata, 586K rodata, 3004K init, 89K bss, 5908K reserved, 1024K DMA)
NR_IRQS:159
Configuring Blackfin Priority Driven Interrupts
Console: colour dummy device 80x25
console [tty0] enabled
bootconsole [early_shadow0] disabled
Calibrating delay loop... 792.57 BogoMIPS (lpj=1585152)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
devtmpfs: initialized
Blackfin Scratchpad data SRAM: 4 KB
Blackfin L1 Data A SRAM: 16 KB (16 KB free)
Blackfin L1 Data B SRAM: 16 KB (16 KB free)
Blackfin L1 Instruction SRAM: 48 KB (42 KB free)
NET: Registered protocol family 16
Blackfin DMA Controller
ezbrd_init(): registering device resources
SCSI subsystem initialized
bfin-spi bfin-spi.0: master is unqueued, this is deprecated
bfin-spi bfin-spi.0: Blackfin on-chip SPI Controller Driver, Version 1.0, regs@ffc00500, dma channel@7
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
i2c-bfin-twi i2c-bfin-twi.0: Blackfin on-chip I2C TWI Contoller, regs_base@ffc01400
NET: Registered protocol family 2
TCP established hash table entries: 1024 (order: 0, 4096 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
TCP: reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
debug-mmrs: setting up Blackfin MMR debugfs
msgmni has been set to 50
io scheduler noop registered (default)
bfin-uart: Blackfin serial driver
bfin-uart.1: ttyBF1 at MMIO 0xffc02000 (irq = 31, base_baud = 6250000) is a BFIN-UART
bfin-otp: initialized
brd: module loaded
physmap platform flash device: 00400000 at 20000000
physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x000001 Chip ID 0x002101
NOR chip too large to fit in mapping. Attempting to cope...
Support for command set 0002 not present
gen_probe: No supported Vendor Command Set found
Creating 3 MTD partitions on "physmap-flash.0":
0x000000000000-0x000000040000 : "bootloader(nor)"
0x000000040000-0x000000200000 : "linux kernel(nor)"
0x000000200000-0x000000400000 : "file system(nor)"
m25p80 spi0.1: unrecognized JEDEC id ffffff
libphy: bfin_mii_bus: probed
bfin_mac: attached PHY driver [Generic PHY] (mii_bus:phy_addr=bfin_mii_bus-0:00, irq=-1, mdc_clk=2500000Hz(mdc_div=19)@sclk=100MHz)
bfin_mac bfin_mac.0 eth0: Blackfin on-chip Ethernet MAC driver, Version 1.1
usbcore: registered new interface driver usb-storage
musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
platform musb-hdrc.0.auto: Driver musb-hdrc requests probe deferral
rtc (null): invalid alarm value: 1900-1-14 0:0:0
rtc-bfin rtc-bfin: rtc core: registered rtc-bfin as rtc0
bfin_wdt: initialized: timeout=20 sec (nowayout=0)
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
TCP: cubic registered
NET: Registered protocol family 17
musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
platform musb-hdrc.0.auto: Driver musb-hdrc requests probe deferral
rtc-bfin rtc-bfin: setting system clock to 1989-09-14 07:46:22 UTC (621762382)
Freeing unused kernel memory: 3004K (00284000 - 00573000)
dma_alloc_init: dma_page @ 0x008ea000 - 256 pages at 0x01f00000
bfin_mac bfin_mac.0 eth0: Link is Up - 100Mbps/Full - flow control off
random: nonblocking pool is initialized
buildroot login: root

                           _______________________________________
        a8888b.           / Welcome to the buildroot distribution \
       d888888b.         /       _     _                           \
       8P"YP"Y88        /       | |   |_|            __  __ (TM)   |
       8|o||o|88  _____/        | |    _ ____  _   _ \ \/ /        |
       8'    .88       \        | |   | |  _ \| | | | \  /         |
       8`._.' Y8.       \       | |__ | | | | | |_| | /  \         |
      d/      `8b.       \      \____||_|_| |_|\____|/_/\_\        |
     dP   .    Y8b.       \   For embedded processors including    |
    d8:'  "  `::88b        \    the Analog Devices Blackfin        /
   d8"         'Y88b        \_____________________________________/
  :8P    '      :888
   8a.   :     _a88P         For further information, check out:
 ._/"Yaa_:   .| 88P|            - http://blackfin.uclinux.org/
 \    YP"    `| 8P  `.          - http://docs.blackfin.uclinux.org/
 /     \.___.d|    .'           - http://www.uclinux.org/
 `--..__)8888P`._.'  jgs/a:f    - http://buildroot.org/

Have a lot of fun...


BusyBox v1.22.1 (2015-01-05 01:17:41 CET) hush - the humble shell

root:~> cat /proc/cpuinfo
processor       : 0
vendor_id       : Analog Devices
cpu family      : 0x27e4
model name      : ADSP-BF526 400(MHz CCLK) 100(MHz SCLK) (mpu off)
stepping        : 2 (Compiled for Rev 0)
cpu MHz         : 400.000000/100.000000
bogomips        : 792.57
Calibration     : 396288000 loops
cache size      : 16 KB(L1 icache) 32 KB(L1 dcache) 0 KB(L2 cache)
dbank-A/B       : cache/cache
external memory : cacheable in instruction cache
external memory : cacheable (write-back) in data cache
icache setup    : 4 Sub-banks/4 Ways, 32 Lines/Way
dcache setup    : 2 Super-banks/4 Sub-banks/2 Ways, 64 Lines/Way

board name      : ADI BF526-EZBRD
board memory    : 32768 kB (0x00000000 -> 0x02000000)
kernel memory   : 31740 kB (0x00001000 -> 0x01f00000)
root:~> free
             total         used         free       shared      buffers
Mem:         28840        18284        10556            0            0
-/+ buffers:              18284        10556
root:~> ps
  PID USER       VSZ STAT COMMAND
    1 root       592 S    init
    2 root         0 SW   [kthreadd]
    3 root         0 SW   [ksoftirqd/0]
    4 root         0 SW   [kworker/0:0]
    5 root         0 SW<  [kworker/0:0H]
    6 root         0 SW   [kworker/u2:0]
    7 root         0 SW<  [khelper]
    8 root         0 SW   [kdevtmpfs]
   59 root         0 SW   [khungtaskd]
   60 root         0 SW<  [writeback]
   61 root         0 SW<  [bioset]
   62 root         0 SW<  [kblockd]
   64 root         0 SW<  [bfin-spi.0]
   66 root         0 SW   [kworker/u2:2]
   97 root         0 SW   [khubd]
  201 root         0 SW   [kworker/0:1]
  210 root         0 SW   [kswapd0]
  211 root         0 SW   [fsnotify_mark]
  325 root         0 SW<  [deferwq]
  359 root       596 R    {busybox} /sbin/telnetd -p 23
  365 root       592 S    /sbin/inetd -f
  366 root       588 S    /sbin/watchdog -F -T 20 -t 10 /dev/watchdog
  367 root       600 S    -/bin/sh
  368 root       592 S    /sbin/syslogd -n -m 0
  369 root       588 S    /sbin/klogd -n
  370 root       624 S    -sh
  377 root       592 R    ps


(http://i.imgur.com/MNKW8yi.jpg)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mrflibble on January 06, 2015, 07:40:47 pm
Hey, nicely done! :-+

Only have a DS1000Z, so can't test the blackfin goodness there. But regarding the DSA815, do you think Rigol uses a similar bootloader for DS2000 and DSA815? I'd be up for some linux experimentation on the DSA815. Any particular links + hints as a starting point?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on January 06, 2015, 10:33:21 pm
currently im only focusing on the DS because i have fully reversed the bootloader there and it has support for loading a LDR and executing it out of the box (thanks rigol ;-)
for the DSA i never saw the bootloader afaicr - for the DG it was similar at least.
but its pretty simple to get your hands on it when u have JTAG access

just put the device in bootldr fw upgrade mode (HELP button) and let it sit there then attach with gdb and have
a look around:

 Sector Start Addresses:
  20000000   RO   20020000   RO   20040000   RO   20060000   RO   20080000   RO
  200A0000   RO   200C0000        200E0000        20100000        20120000     

0x20000000 is where external memory starts on the blackfin, and on the DS2000 thats where the flash is mapped too.
there is one caveat and that is rigol seems to switch some flash address lines with the fpga (or some other latching device) so its all shadowed.

the mapping on the DS is

0x20340000.w - set by ASYNC3_SelectBank (16bit write + SSYNC !!)
0x0000 - boot LDR
0x0100 - app LDR (oscilloscope software)
0x0200 - boot LDR images (ultravision and rigol logo)
0x0600 - fpga ?

there is probably more to it, but setting 0x20340000.w = 0x0 will let u read out the LDR stream of the Boot LDR.
id definitely be interested if somebody has the time to fetch a DG and DSA bootloader with this method.
the size of the DS LDR is exactly 0x40000 or 256kbytes - LDRs are easily spotted because they have a distinct header
check: http://www.analog.com/static/imported-files/application_notes/EE-240_Rev4.pdf (http://www.analog.com/static/imported-files/application_notes/EE-240_Rev4.pdf)
and: http://www.dolomitics.com/downloads/ldrviewer.html (http://www.dolomitics.com/downloads/ldrviewer.html) to test extracted data
i also have a custom tool that i will release shortly.






Title: Re: Sniffing the Rigol's internal I2C bus
Post by: benscammell on January 07, 2015, 03:32:34 pm
I have just taken delivery of a MSO2102A-S.

Can I unlock all the options? If so, how?

THanks, Ben
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Jonson.poisk on January 10, 2015, 07:57:46 am
Hello!
I purchased a new DSA815-TG, but he base the latest firmware, read thread, I understand that there is no solution to the licenses for these models?
Also a question about a 10Hz RBW, this option is not even officially on sale, and it is needed. These analyzers are doomed? Only sell and change to the old model? Are there any solutions?  |O :palm:
thanks in advance
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on January 10, 2015, 12:04:14 pm
Hello!
I purchased a new DSA815-TG, but he base the latest firmware, read thread, I understand that there is no solution to the licenses for these models?
Also a question about a 10Hz RBW, this option is not even officially on sale, and it is needed. These analyzers are doomed? Only sell and change to the old model? Are there any solutions?  |O :palm:
thanks in advance

See ->  https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg583763/#msg583763 (https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg583763/#msg583763)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: radiogeek97 on January 10, 2015, 01:32:20 pm
I think i am more worried about breaking the warranty tag than taking a soldering iron to a new DSA  :-BROKE   Too bad there was not a software way to short pins 7/8   
     Howard any more  pics available of the inside of your dsa815 I think those of us with new machines will be staring at that warrant void sticker armed with your discovery and going for it  >:D   
    One thought on the dhcp thing If I want a fixed IP address ect what if i change to the fixed IP address that I want then perform your upgrade Will the default dhcp address be overwritten ontop of the manual address?  just wondering
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Howardlong on January 10, 2015, 02:20:39 pm
I think the example I'm familiar with has been apart enough for now! But if it's disassembled again I'll organise some new pics.

Not sure about whether the IP address fixes after shorting pins 7 & 8, I was happy to live with DHCP. You definitely cannot change network settings after the pin 7&8 short mod though. However, you can if you're brave enough to do the PIC mod.

Links by the way are here:

https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg567821/#msg567821 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg567821/#msg567821)
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg572507/#msg572507 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg572507/#msg572507)

Here's a DaveCAD of that PIC mod BTW.

(http://i34.photobucket.com/albums/d123/photobucket391/img057_zps62b760af.jpg) (http://s34.photobucket.com/user/photobucket391/media/img057_zps62b760af.jpg.html)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: roema on January 10, 2015, 03:20:34 pm
Hi!

Has anyone a dump from DSA815 Bootloader?

Thanks!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: radiogeek97 on January 10, 2015, 04:49:30 pm
Howard thanks
   I am going to study up on how to remove the warranty void sticker and make sure I dont have a dissaster there.  I think My skill level is more suited to Jumping pins 7,8 than the pic route. Thanks for all that you and the rest have done ! While the lower RBW would be great and may get "hacked" on the 1.04 bootloader some day, folks like you who take the chance to help the rest are Appreciated.   

big thanks from Boston, Ma
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: N8AUM on January 11, 2015, 02:05:14 am
Hello all, damn I wish I would have had the $$$ and purchased the DSA815-TG before they came out with this last rev that wont allow any of the hacks to work! Now am debating whether or not to install the latest firmware or wait hoping the hack gurus will come come up with a fix ?
Is anyone looking into a fix for the 815 ?

73  N8AUM
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 3s1d on January 11, 2015, 02:39:06 am
Hi

first of all I'd like to thank everyone here for their great work.

I have a small problem with my MSO1074Z. I dumped the 64M image using my PI and generated the license codes using the rigup-0.4.1 tool posted in #7323 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg565557/#msg565557 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg565557/#msg565557)). I had no errors during this process. I can confirm that the serial number in the TXT file (after the scan command) is the same as display by the device itself. I tried to enter the generated codes for 0x1C00F and 0x1C001, but had no luck. The MSO always responds: "Invalid license".

I was so frustrated that I pushed the apply-button a little bit too often. Now I have to wait at least 12h before I can continue.  |O

What did I wrong? Is the firmware too old? My firmware version is 00.04.00. To which version should I upgrade? Do I have to redump the image again after the upgrade?

Many thanks in advance.
Juergen
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 3s1d on January 11, 2015, 06:10:42 pm
Hi
I have upgraded to 00.04.02.SP4 and tried to reenter the already obtained codes. It still fails. Do I have to re-dump the binary again in order to get new(??) keys?

Regards
Juergen


PS: The scope is only a few hours old. The trail versions are still going. Could this be an issue?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 3s1d on January 11, 2015, 07:26:34 pm
Hi guys,

I figured it out... I initially compiled it on my OSX machine. As I switched to Ubuntu the keys changed and now everything works fine.

I so far only applied 0x1C00F and 0x1C080. Those are missing:
(CSAS = 0x1C010) DG
(CSRA = 0x1C020) 500uV
(CSBA = 0x1C040) Power Ana.

As I understand 500uV is useless (see #3731), but what about the other 2? What are they for? Are they "harmful" (as noted here #3723)??

Regards,
Juergen
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bigone5500 on January 11, 2015, 10:28:57 pm
What chances are there to patch a firmware so that it outputs the key and serial when you send it
"*IDN?". That would be good.

Done!

https://mega.co.nz/#!MdcEWTgL!0EEmSr-Q6TxaFSsyEmjhRrgqDvFCoXg9K49BalL5Uxc

No need for JTAG memory dumps anymore, just send *IDN? command and you'll get your license encryption keys in response (tested on my DS2072A that has just arrived).

This file is no longer available. Can someone please direct me to the file?

Thanks.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: phersus on January 12, 2015, 10:16:14 pm
Hello Guys,

Just a message to report another MSO1074Z unlocked  :)

Thank you to all the people contributing with their knowledge, effort, time, energy ... It's good to know that sharing is a good path to success.

Special thanks to rmd79, 0ff, Hammy, Howardlong and the guys who discovered and shared the hack in the first place sptm14, Slappy_g and for sure all the others I'm forgetting ... sorry, the thread is very long and many have contributed.

For those interested this is how I did it:

- First I tried with an Olimex JTAG header but neither Windows (7 32-bits), nor MAC OS X (Yosemite), nor Linux recognised it.
- I decided to try with the Bus Pirate V3.6 (BP) from Dangerous Prototypes and this worked at the first try (I think I got a defective Olimex  :-//).
- I did the memory dump using Linux (only because I was doing something in that machine and decided to try the BP, but I think it would have worked with the MAC as well, I did't tried).
- I used openocd and the result was a binary file of 67108863 Bytes.
- I used the updated version of rigup tool that takes into account the MSO1074Z and get the private key
- I used again rigup tool and generate the licenses
- I used the SCPI commands to enter the licenses and voila !!

The only thing I can contribute with since I haven't seen it here, is the use of the BP (Bus Pirate), the rest is according to the information given in the forum, so here it goes:

If someone is interested this guide was really helpful in putting Bus Pirate to work with openocd (under linux):

http://cybermashup.com/2014/05/01/jtag-debugging-made-easy-with-bus-pirate-and-openocd/ (http://cybermashup.com/2014/05/01/jtag-debugging-made-easy-with-bus-pirate-and-openocd/)

First a little disclaimer: This interface is really slow, when the guys from Dangerous Prototypes say that this is a human speed tool they are not kidding, it took several hours (25+) to get the dump done.

The cabling was pretty straight forward:

Oscilloscope        BusPirate
TDO <------------> MISO (According to the label in the PCB, however when in JTAG mode it is TDO as it is supposed to be)
TCK <------------> CLK (Again in JTAG mode this is TCK)
TMS <------------> CS (Which is TMS in JTAG mode)
TDI <------------> MOSI (TDI in JTAG mode)
3.3V <-----------> 3.3V
GND  <-----------> GND

I didn't use the other pins.

The openocd command line:

user@system:/home/user#openocd -f mybuspirate.cfg

File: mybuspirate.cfg
Code: [Select]

source [find interface/buspirate.cfg]
source [find target/imx28cfg]

buspirate_mode normal
buspirate_pullup 0
buspirate_speed fast
buspirate_port /dev/ttyUSB0


/!\ The port where the Bus Pirate was detected in my computer was /dev/ttyUSB0, you must change the previous line according to whatever it is in your case!

once the interface was reporting this:

Info : Buspirate Interface ready!
Info : This adapter does not support configurable speed
Info : JTAG tap: imx28.cpu tap/device found: 0x079264f3 (mfg: 0x279 part: 0x7926, ver: 0x0)
Info : Embedded ICE version 6
Info : imx28.cpu: hardware has two breakpoint/watchpoint units
Info : Accepting 'telnet' connection on tcp/4444

I did the telnet to tcp port 4444

Code: [Select]
user@system:/home/user#telnet localhost 4444
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> halt
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x40000013 pc: 0x401e1104
MMU: enabled, D-Cache: enabled, I-Cache: enabled
> dump_image mso1074z.bin 0x40000000 0x3FFFFFF
dumped 67108863 bytes in 91906.320312s (0.713 KiB/s)
target state: halted
target halted in ARM state due to debug-request, current mode: IRQ
cpsr: 0x40000092 pc: 0x001c17a0
MMU: enabled, D-Cache: enabled, I-Cache: enabled

Then I ran the rigup tool with the dump file as parameter

Code: [Select]
user@system:/home/user#./rigup scan mso1074z.bin > mso1074z.txt

which generated the private key/public key/RC5 keys/Serial Number

After with the latter file I ran again the rigup tool to generate the licenses:

Code: [Select]
user@system:/home/user#./rigup license mso1074z.txt 0x1C001

or as Sandra suggested in her post "Reply #3765" page 252 of this thread

This is a summary of the found options as far as I know:

(CSAR = 0x1C001) TRIGGER             --> Applied
(CSAB = 0x1C002) DECODER             --> Applied
(CSA3 = 0x1C004) MEM-DEPTH           --> Applied
(CSAJ = 0x1C008) RECORDER            --> Applied
(CSAS = 0x1C010) DG                --> Not clear yet on what this option does
(CSRA = 0x1C020) 500uV             --> Reported not to work correctly
(CSBA = 0x1C040) Power Ana.          --> Not clear yet on what this option does
(CS3A = 0x1C080) Bandwidth (100MHz)  --> Applied
(CSHY = 0x1C0FF)                 --> Kind of APPLY ALL!

And finally to apply the generated licences the easiest way is to use the scope's SCPI interface:

Configure the LAN interface of the MSO1074Z:
Code: [Select]
Utility —> IO Setting —> LAN Conf.

You can connect the scope through a switch or back to back to your PC in any case this is the setup:

[Oscilloscope] --- straight Cable -----[Switch] ------ straight Cable ------- [PC]
 or
[Oscilloscope] ------------- Crossed Cable ---------------- [PC]

Code: [Select]
user@system:/home/user#telnet <Oscilloscope LAN IP Address> 5555

:SYSTem:OPTion:INSTall <The Activation Code WITHOUT the dashes or spaces>

I hope this will help someone, I tried to complete with some information that was spread in several posts; if you want to see some pictures go to Sandra's post which have some very useful ones (notably for the Oscilloscope JTAG interface).

Cheers,
Gus
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on January 12, 2015, 11:48:35 pm
Congrats pherseus!  :-+

25+ hours dump with the BusPirate  :phew:  :-+ :-+ :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: phersus on January 13, 2015, 10:48:07 am
Thank you Hammy,

Actually, to be fair I think the BP is not that slow, what happened was that after some hours (8+) my computer went to sleep and the dump just stopped, the day after I thought the dump was finished because the USB led in the BP was not blinking, but when I woke up the computer the USB led got blinking again.

Anyway it was really slow,

Cheers,
Gus
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: radiogeek97 on January 13, 2015, 12:45:26 pm
Could we use this latest meathod on the dsa815, or is the unit and or keygen sufficiently different that it wont work.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Howardlong on January 13, 2015, 12:54:22 pm
I did try it on a RAM dump, but I couldn't get it to work, it wouldn't find a key, but I am no expert at this level.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: aviphysics on January 20, 2015, 08:18:23 pm
Could I get a quick recommendation for a Jtag that will work with one of the guides in this thread, and might be good to use for other things later? Preferably one that I won't have to fight with to get it working.

Thank you in advance for the answer. Sorry for not digging through the thread.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: aviphysics on January 20, 2015, 10:31:34 pm
New Firmware for DS1000Z and MSO/DS2000 Here
 (https://www.eevblog.com/forum/blog/eevblog-683-rigol-ds1000z-ds2000-oscilloscope-jitter-problems/msg578208/#msg578208)

Do these updates on the MSO1000Z series interfere with the JTAG hack?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Howardlong on January 20, 2015, 10:36:56 pm
New Firmware for DS1000Z and MSO/DS2000 Here
 (https://www.eevblog.com/forum/blog/eevblog-683-rigol-ds1000z-ds2000-oscilloscope-jitter-problems/msg578208/#msg578208)

Do these updates on the MSO1000Z series interfere with the JTAG hack?

Nope.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: msraya on January 29, 2015, 01:55:27 pm
Hello All!!

Yet not working,  >:(

I make the dump, problem was excessive length of cable.
Then the new released rigup 0.4.1 modified for MSO1000Z generate the keys and license codes, no problem.
I compiled rigup under Ubuntu, only problem a linker warning and core dump with -dead-strip  option.
After I remove this option it compiles and work well.

The license codes does not work. The oscilloscope claim "invalid license" all the time.
I try to enter codes both via SCPI and keyboard with not luck.

I don't know were is the problem..
Perhaps can be a problem during program build... I see some warnings..
Can Someone send me the ubuntu 64 bits binary for rigup program to test is against mine for key generation?? 
Please send me personal message.
Thank You!

Regards
Manuel
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Rory on January 29, 2015, 04:07:44 pm
Any news on the DG4000 series after v1.09?

(Edit on advice of Teneyes...)
After forgetting to revert to DG4162 from DG4202 before update, I'm stuck with DG4062 at v1.10.  Is there any hope?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: msraya on January 30, 2015, 11:35:15 am
Hey!! 
My MSO1074Z-S got now all options Official!!  8)

I managed to discover the problem..
In the new version of rigup, When I use "rigup serial keys.txt MSZ..." to update the serial number, it solves the problem.... 
Then some of preinstalled licenses with rigup search test Ok. Previously they test Fail.

Then I regenerate the licenses and now they test also Ok with "rigup info" command..  Previously they test Fail.
Also i update the firmware after apply licenses and no problem.

Thank You All, specially to users smgvbest for her tutorial at page 252 and to rmd79 for the rigup application.
Regards
Manuel
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Sparky on January 30, 2015, 07:01:23 pm
After forgetting to revert to DG4162 from DG4202 before update, I'm stuck with DG4062 at v1.12.  Is there any hope?

Perhaps you mean DG4062 with v01.10?  There is no v01.12 for DG4000 series yet.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on January 31, 2015, 06:05:44 am
Hey!! 
My MSO1074Z-S got now all options Official!!  8)

Regards
Manuel

Glad you got it
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: suds on February 01, 2015, 07:36:45 pm
Yeah, I got a license OFFICIAL for my MSO1074z  ;) !

I used Olimex adapter https://www.olimex.com/Products/ARM/JTAG/ARM-USB-TINY/ (https://www.olimex.com/Products/ARM/JTAG/ARM-USB-TINY/) , but it is not connected to the scope port :( I do not know why, probably there is a problem with the drivers Windows 7 and Linux (Ubuntu x64).

I asked at the local forum another adapter from a friend. It was a cheap Chinese Segger J-link adapter for $ 20 :)
Next I used https://www.segger.com/jlink-software.html?step=1&file=JLink_496d (https://www.segger.com/jlink-software.html?step=1&file=JLink_496d) to communicate with the "segger" adapter.

(http://s013.radikal.ru/i322/1502/f0/9bb86e067ec2.jpg)

To dump commands are used Halt "h" and "savebin" commands. I also increased the speed of the bus to 6MHz ("speed 6000" command). The 64 MB memory dump copied 8 minutes.

Then I used rigup 0.4.1 under Debian Linux i386, but I changed the Makefile "LDFLAGS: = -O2 -Wl, - gc-sections c" as written here on the forum.

Rigup generated correct keys for my scope :)

Thank you  ALL !!!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: radiogeek97 on February 03, 2015, 08:25:47 pm
Do any of you folks this will work with the DSA815tg's ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: donmr on February 05, 2015, 03:48:54 am

Here's part of the source code in riglol.c (source code can be downloaded at the bottom of http://riglol.3owl.com (http://riglol.3owl.com))

I don't know who wrote/maintains this code, but I found a small bug that I want to report.
There is a line which may or may not function as desired depending on the compiler.
Here is my simple fix:
Code: [Select]
--- riglol_orig.c 2015-02-03 12:53:18.659248144 -0800
+++ riglol.c 2015-02-03 12:54:16.283267920 -0800
@@ -141,7 +141,7 @@
 char * strtoupper(char *str) {
     char *newstr, *p;
     p = newstr = (char*) strdup((char*)str);
-    while ((*p++ = toupper(*p)));
+    while (*p = toupper(*p)) { p++; }
     return newstr;
 }
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Jacobs on February 05, 2015, 08:04:53 pm
Hi guys!

I have an idea to solve license problem in new DSA815. Has somebody tried to change S/N in DSA815? If earlier devices can work correctly with firmware 00.01.09 and installed licences I suppose that the key to "upgrade" DSA815 is S/N. I read on the forum that in S/N is coded date of production. Firmware 00.01.09 probably use this coded date to verification installed licences. Know somebady way to change S/N?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on February 05, 2015, 08:18:58 pm
Hi guys!

I have an idea to solve license problem in new DSA815. Has somebody tried to change S/N in DSA815? If earlier devices can work correctly with firmware 00.01.09 and installed licences I suppose that the key to "upgrade" DSA815 is S/N. I read on the forum that in S/N is coded date of production. Firmware 00.01.09 probably use this coded date to verification installed licences. Know somebady way to change S/N?

I suggest NOT changing the S/N.  It won't help, and you would be sorry!

Edit:  It is the BootLoader .04 that was supplied with the new factory DSA815's with Firmware .09 and .12 that is the problem.  If the BootLoader can be changed back to version .03 (or .02) then you will be able to down grade to a earlier Firmware version.  Then use the Riglol 1.03c or 1.03d Keygen to add the Options in the DSA.  And finally upgrade to Firmware .12 to get all the new features. BTW BootLoader .03 was incorporated with Firmware .06.   Or, wait for someone to possibly develop a new Riglol Keygen to work with the current version of .12 Firmware.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: SteveyG on February 08, 2015, 01:06:50 pm
Another happy MSO1074Z user :) Thanks to rmd79 and 0ff!. I documented my steps here:

https://www.youtube.com/watch?v=OvcGn_ScG5w (https://www.youtube.com/watch?v=OvcGn_ScG5w#ws)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: McBryce on February 12, 2015, 04:02:35 pm
Hi,
    first post here on the eevblog. First off, really great work guys (and gal), and nice video Stevey. Took a while to read all 258 pages of this thread, but I've still got a few questions:

I've been asked to "liberate" the features on an MSO1074z-s for someone. It seems that the hack for this is still a "work in progress". I don't fancy trying to remove the waranty seal from this guys scope. Is it just a matter of time before the Key has been found so that this scope can be hacked with Riglol like the other scopes, or is there some factor that means it will always require a RAM dump to get the license info?
If it will always require a RAM dump: I don't have an Olimex, but I do have a Chinese clone Xilinx USB Blaster USB-JTAG. This one I think: http://www.ebay.de/itm/171008779562 (http://www.ebay.de/itm/171008779562) . Does anyone know if this will work with Openocd / imx28 ? Or will I have to buy an Olimex for this?

Thanks
McBryce.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on February 13, 2015, 01:33:50 pm

Here's part of the source code in riglol.c (source code can be downloaded at the bottom of http://riglol.3owl.com (http://riglol.3owl.com))

I don't know who wrote/maintains this code, but I found a small bug that I want to report.
There is a line which may or may not function as desired depending on the compiler.
Here is my simple fix:
Code: [Select]
--- riglol_orig.c 2015-02-03 12:53:18.659248144 -0800
+++ riglol.c 2015-02-03 12:54:16.283267920 -0800
@@ -141,7 +141,7 @@
 char * strtoupper(char *str) {
     char *newstr, *p;
     p = newstr = (char*) strdup((char*)str);
-    while ((*p++ = toupper(*p)));
+    while (*p = toupper(*p)) { p++; }
     return newstr;
 }

studio25 (https://www.eevblog.com/forum/profile/?u=37760) wrote/maintains this code and host it it at 3owl. So try PM'ing  your modifications to him.

The two other Riglol sites hosted by other members are just mirrors of studio25's Riglol site at 3owl:

Original made by studio25 (https://www.eevblog.com/forum/profile/?u=37760): http://riglol.3owl.com (http://riglol.3owl.com)
Canadian mirror hosted by ve7xen (https://www.eevblog.com/forum/profile/?u=17762): http://gotroot.ca/rigol/riglol/ (http://gotroot.ca/rigol/riglol/)
UK mirror hosted by Avotronics (https://www.eevblog.com/forum/profile/?u=89989): http://rigol.avotronics.co.uk/mirrors/riglol/ (http://rigol.avotronics.co.uk/mirrors/riglol/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: SteveyG on February 13, 2015, 10:31:03 pm
Hi,
    first post here on the eevblog. First off, really great work guys (and gal), and nice video Stevey. Took a while to read all 258 pages of this thread, but I've still got a few questions:

I've been asked to "liberate" the features on an MSO1074z-s for someone. It seems that the hack for this is still a "work in progress". I don't fancy trying to remove the waranty seal from this guys scope. Is it just a matter of time before the Key has been found so that this scope can be hacked with Riglol like the other scopes, or is there some factor that means it will always require a RAM dump to get the license info?
If it will always require a RAM dump: I don't have an Olimex, but I do have a Chinese clone Xilinx USB Blaster USB-JTAG. This one I think: http://www.ebay.de/itm/171008779562 (http://www.ebay.de/itm/171008779562) . Does anyone know if this will work with Openocd / imx28 ? Or will I have to buy an Olimex for this?

Thanks
McBryce.

Hi,

Essentially the JTAG interface has to be compatible with the ARM processor and with openocd.

This should work, although you'd have to wait for shipping http://www.ebay.de/itm/JLINK-J-LINK-V8-Emulator-ARM-4-74B-MDK5-0-PRTR5V0U4D-JTAG-Interface-Auto-Update-/271596747000 (http://www.ebay.de/itm/JLINK-J-LINK-V8-Emulator-ARM-4-74B-MDK5-0-PRTR5V0U4D-JTAG-Interface-Auto-Update-/271596747000)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: metRo_ on February 18, 2015, 01:41:34 pm
If it will always require a RAM dump: I don't have an Olimex, but I do have a Chinese clone Xilinx USB Blaster USB-JTAG. This one I think: http://www.ebay.de/itm/171008779562 (http://www.ebay.de/itm/171008779562) . Does anyone know if this will work with Openocd / imx28 ? Or will I have to buy an Olimex for this?
USB Blaster should work.

To unlock the 1054Z can I use the website with the keygen, can't I? It is possible to reverse the process if for some reason I need to send it to warranty?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: aveekbh on February 18, 2015, 04:24:50 pm
It is possible to reverse the process if for some reason I need to send it to warranty?
I believe you can uninstall all the options by issuing the SCPI command :SYSTem:OPTion:UNINSTall over LXI or USBTMC.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on February 18, 2015, 06:04:06 pm
If it will always require a RAM dump: I don't have an Olimex, but I do have a Chinese clone Xilinx USB Blaster USB-JTAG. This one I think: http://www.ebay.de/itm/171008779562 (http://www.ebay.de/itm/171008779562) . Does anyone know if this will work with Openocd / imx28 ? Or will I have to buy an Olimex for this?
USB Blaster should work.

To unlock the 1054Z can I use the website with the keygen, can't I? It is possible to reverse the process if for some reason I need to send it to warranty?

I thought the DS1000Z did not need to dump memory.  Only the MSO1000Z's needed that.
I would try using the site or rigup first before doing a dump.  no sense in opening it up if you do not have to
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Zandor on February 18, 2015, 08:28:54 pm
If it will always require a RAM dump: I don't have an Olimex, but I do have a Chinese clone Xilinx USB Blaster USB-JTAG. This one I think: http://www.ebay.de/itm/171008779562 (http://www.ebay.de/itm/171008779562) . Does anyone know if this will work with Openocd / imx28 ? Or will I have to buy an Olimex for this?
USB Blaster should work.

To unlock the 1054Z can I use the website with the keygen, can't I? It is possible to reverse the process if for some reason I need to send it to warranty?

I thought the DS1000Z did not need to dump memory.  Only the MSO1000Z's needed that.
I would try using the site or rigup first before doing a dump.  no sense in opening it up if you do not have to

Correct, the 1054Z does not need to be opened up.  Just use the website or download the executable and run it on your system.

I have heard you should run it several times if using the website as it sometimes has problems giving a correct key.  Run it until you get the same key several times.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: McBryce on February 19, 2015, 10:45:03 am
In my case it's an MSO. However, the owner hasn't made up his mind yet, whether he wants to risk messing with the Warranty Seal yet. In the meantime, I've noticed that ebay has been purged of all dodgy Chinese Segger devices (including the one that SteveyG linked to). If he does decide to go ahead with the "liberation" I'll try my Xilinx J-Tag programmer first.

McBryce.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on February 22, 2015, 07:44:31 am
In my case it's an MSO. However, the owner hasn't made up his mind yet, whether he wants to risk messing with the Warranty Seal yet. In the meantime, I've noticed that ebay has been purged of all dodgy Chinese Segger devices (including the one that SteveyG linked to). If he does decide to go ahead with the "liberation" I'll try my Xilinx J-Tag programmer first.

McBryce.

You can remove the warrany sticker without voiding it.  Check it out here if you have not seen it https://www.youtube.com/watch?v=KGcNS5g9ygg (https://www.youtube.com/watch?v=KGcNS5g9ygg)

I did my MSO1074Z-S and it's actually pretty easy to do.  I have an Old Amontec JTAG-Key I use based on the FTDI2232 which allot are based on now and it works create.  As long as OpenOCD supports it you should be fine so Instead of buying one you might get OpenOCD and see which ones it's supports then get one it supports   I know OpenOCD supports some of the Xilinx ones so just check yours is supported.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: McBryce on February 22, 2015, 12:06:46 pm
Yes you can, but it's not 100% garanteed that you manage it. Even watching the video, you only get one chance and if it goes wrong then... I'm not sure I want to offer this service, especially as the owner isn't all that confident/happy with the prospect either.
I've also checked and the Xilinx Jtag I have isn't compatible with OpenOCD (yet). So it looks like the guy is just going to have to buy the licenses if he wants the functions or live without them (as it's supposed to be done anyway) :)

McBryce.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: SteveyG on February 22, 2015, 12:23:42 pm
I wonder if there are some warranty stickers on eBay that match those used on the Rigol  :-//
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on February 23, 2015, 06:21:36 am
Havent' seen a match yet
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Howardlong on February 23, 2015, 09:08:50 am
While I understand the reticence to fiddle with the warranty sticker, I agree with smgvbest, it's not actually that hard, probably the most important skill you need is patience, maybe ten minutes of your time the first time you do it, although once you've done one subsequent efforts seem quicker. The first one I did was on the MSO1074Z-S, and I must've tackled half a dozen others since watching Mike's vid. I used to just cut them, assuming that they really were tamper-proof.

Maybe try it with something that's already out of warranty first?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on February 24, 2015, 01:14:53 am
I also did it on my MSO1074Z-S like Howardlong did and while it was nerve wrecking the first time now it's not bad at all.
I realize the OP is doing this for someone else and that add's to the stress but if he wants it done it really is not a big deal.  Patience is key.  if you think your pushing to fast you probably are.  it took me maybe 10-15 minutes with as Dave say tongue at the right angle but it came off fine.  Used some additional slick paper and taped it back just like he does in the video and it just works.

If the guy asking to do it wants it done personally now after doing it I'd say don't worry about it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on February 27, 2015, 12:30:23 am
I also did it on my MSO1074Z-S like Howardlong did and while it was nerve wrecking the first time now it's not bad at all.

Ladies First  :)
Already went, who's next??
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dkozel on March 03, 2015, 09:20:04 am
Hello,

My DS2072 is currently bricked and not booting. I'd like to try reflashing the firmware and do have an OpenOCD JTAG device. Cybernet, you seem to be the guru of this, could you (or anyone else  :)) share any gottchas around flashing the bootloader/firmware?

Thanks!

Please forgive the poor choice of title, its not inaccurate, but is likely misleading.
https://www.eevblog.com/forum/testgear/rigol-ds2074-no-longer-boots-after-fixing-broken-heatsink-clip/ (https://www.eevblog.com/forum/testgear/rigol-ds2074-no-longer-boots-after-fixing-broken-heatsink-clip/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: NortliW on March 03, 2015, 11:49:50 pm
Any Riglol progress on the DSA-1030? Would like it with some options......TNX.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ytsejam on March 07, 2015, 05:09:21 am
Has anyone successfully dumped the flash content of DSA815 ?
Just got a tiny progress, hope to see if anyone can share their finding?

I tried to dump BF526's async banks (0x20000000 ~ 0x203FFFFF) with bfin toolchain and ARM-USB-OCD-H cable,
however I found that the dump files are inconsistent, results are not the same.
(Tried on both DSA815 with bootloader 1.03  and 1.04)

Since TopJTAG was mentioned previously, I decided to give it a try.
The flash chip on DSA815 is Spansion S29GL064N90TFI04 (TSOP48 package, 8MB Parallel NOR flash, CFI compiant).
I used Segger J-LINK v9 as the JTAG cable.
I managed to figure out the setting for TopJTAG Flash Programmer:

------------------------------
1. BSDL for BF526 is attached.
2. Data bus is 16-bit wide with 16-bit maximum capable data
3. Signal pins:

CE = AMS0, active = low
OE = AOE  , active = low
WE = AWE , active = low


A0 ~ A18 = ADDR1 ~ ADDR19
(A21 ~ A19 seem to be hardcoded as 110 or controlled by other device, FPGA?)

D0 ~ D15 = DATA0 ~ DATA15

4. Static pins

No static pins defined.

-------------------------------

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

My intention was to dump the flash content of a DSA815 with bootloader 1.03 and restore it on my DSA815 with bootloader 1.04.
I was able to dump 1MB binary files from each.

However when I tried to restore the dump from 1.03 to my 1.04 DSA815, the program and verification process was completed successfully.
But when I rebooted my DSA815, the bootloader remains 1.04 and everything is unchanged. (WP# was hardcoded at VIH, maybe there is some dynamic write protections?)

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.

According to past experience, usually flash will maintain multiple copies of firmware (I've seen the case with 4 copies), and the content will be checked during boot. Maybe I was just updated one of them?

Appreciate if anyone with similar experience can share your finding.

UPDATE
The setup profile for TopJTAG Flash Programmer is attached. Remove the suffix .txt before use.
BDSL file needs to be placed in the same folder with the setup profile.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ytsejam on March 07, 2015, 04:28:01 pm
UPDATE: the above method actually works.

Previously, I tried to program my DSA815 (bootloader 01.04, FW 01.09, RF FPGA FW 00.05, Digital FPGA FW 00.04) with the flash dump from another DSA815 (bootloader 01.03, FW 01.07, RF FPGA FW 00.05, Digital FPGA FW 00.04). I didn't notice any change.

Next, I tried to upgrade my DSA815 to FW 01.12, after upgrade, the sysinfo shows: bootloader 01.04, FW 01.12, RF FPGA FW 00.05, Digital FPGA FW 00.05
Then I Programmed the flash with the dump file from the old DSA815. Once I reboot my DSA815, the bootloader prompts something like "Factory Boot".
Which means, the bootloader cannot boot into the firmware on the flash. Obviously, this is because the bootloader is not able to recognise part of the code on the flash. I think this is due to the version of Digital FPGA FW version mismatch. I guess the portion I write into the flash was the Digital FPGA FW.

The factory boot mode can be recovered by pressing PRESET to load a FW version 01.12.

Though no immediate success, but this might give me a clue that if I can dump the correct portion of the flash, I should be able to "restore" the bootloader back to 01.03.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: guiasse on March 16, 2015, 11:24:23 am
Hello,
I'm trapped on a firmware 1.12 / boot 1.04. There is no way to downgrade firmware.
Does anybody have a way to do that ?
Best regards,
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: N8AUM on March 17, 2015, 06:45:52 am
Hello,
I'm trapped on a firmware 1.12 / boot 1.04. There is no way to downgrade firmware.
Does anybody have a way to do that ?
Best regards,

I wonder how many of us are in the same boat ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: guiasse on March 17, 2015, 07:12:41 am
If i'm right the only way for the moment is to use a pic over Fram to reset time trial at each boot.
Did somebody try that with last realease ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Garnet on March 17, 2015, 01:06:05 pm
If i'm right the only way for the moment is to use a pic over Fram to reset time trial at each boot.
Did somebody try that with last realease ?

The "Howardlong" method of shorting the two pins together is still a viable option on the latest units. I have:

Main board: 00.08
RF board: 00.05
Digital board: 00.04
F/W Ver: 00.01.09
Boot Ver: 00.01 04

that arrived on March 4th and can attest to the validity of the above statement.

https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg584818/#msg584818 (https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg584818/#msg584818)

Follow the warranty sticker preservation method shown here:

https://www.youtube.com/watch?v=KGcNS5g9ygg (https://www.youtube.com/watch?v=KGcNS5g9ygg)

G
Title: YET ANOTHER HACK SUMMARY POST
Post by: Dave92F1 on March 19, 2015, 07:53:40 pm
YET ANOTHER HACK SUMMARY

I had all options + 300 MHz on my DS2072A, then I upgraded to the latest firmware, and lost all the hacks. It took me some time to figure out how to get them back.

This is my summary (should work for a new out-of-the-box DS2072A as well):

1 - Download & unzip the latest "Rigol Bildschirmkopie LAN/USB" from http://peter.dreisiebner.at/rigol-bildschirmkopie-lan/ (http://peter.dreisiebner.at/rigol-bildschirmkopie-lan/)

2 - Connect scope to LAN.

3 - Run the RigolBildschirmkopie.exe, click Device>Select>Search>Select.

4 - Do Device>SCPI-Command, then  Send & receive ":SYST:UTIL:READ? 1,33554432".
 
     Wait a long time (~5 to 10 min) for it to complete.
     
     Click Save, save it as "memoryDump.scpi" (save this file for future use!!)

5 - Download and unzip Rigup 0.4 (or later) from http://gotroot.ca/rigol/. (http://gotroot.ca/rigol/.)

6 - Open a command window where you unzipped Rigup 0.4, copy memoryDump.scpi into the same folder.

7 - In the command window do: "rigup ds2072a memoryDump.scpi"

      This will produce an output something like:

rigup ds2072a - Version 0.4

Serial number: DSxxxxx

NSEH:  JPJQLFK-G3QNRLU-WFFFZMD-xxxxxxx    All options, no bandwidth upgrade
NSER:  8NXBL2U-JE2LZL7-9NEN5XK-xxxxxxx   All options, bandwidth 100 MHz
NSEQ:  R939MMG-NR63H25-9H993PX-xxxxxxx    All options, bandwidth 200 MHz
NS8H:  G2YRFYX-D589HNR-4K8YW3H-xxxxxxx    All options, bandwidth 300 MHz

8 - rigup scan MyKeys memoryDump.scpi

This will write your keys to the file "MyKeys".

9 - rigup license MyKeys NS8N

This produces an output something like:

5P89ZX7-LYMCTCS-P4PQ792-xxxxxxx   (NS8N = 0x1C0C3)

10 - Run RigolBildschirmkopie.exe again, click Device>Select>Search>Select (again).

11 - Click Device>SCPI-Command, then send & receive:
       :SYSTem:OPTion:INSTall <key to the right of NSEQ in step 7>

       The key (from step 7) MUST have the dashes removed.

       For example:
       :SYSTem:OPTion:INSTall R939MMGNR63H259H993PXxxxxxxx
       
At this point you should have all options + 200 MHz.

12 - Click Device>SCPI-Command, then send & receive:

       :SYSTem:OPTion:INSTall <key from step 9>

       Again, the key must have all dashes removed.

       For example:
       :SYSTem:OPTion:INSTall 5P89ZX7LYMCTCSP4PQ792xxxxxxx

That's it; you should have 300 MHz + all options now.

Maybe you can skip step 11 - I haven't tried it that way.

If you mess up, no problem. Just send ":SYSTem:OPTion:UNINSTall" and start over.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: guiasse on March 22, 2015, 08:42:06 am
How does it works with DP832 power supply ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Blitzbirnep on March 23, 2015, 01:34:43 pm
Does anyone tried the
- DS2000A_Upgrade_Utility_1_0_0_1_Portable.zip on http://gotroot.ca/rigol/ (http://gotroot.ca/rigol/) Or
- the webbased tool which was posted by norkimo on http://www.sonsivri.to/forum/index.php?topic=53230.25 (http://www.sonsivri.to/forum/index.php?topic=53230.25)

and could tell me his experience with them?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: OldNeurons on March 23, 2015, 04:53:40 pm
Does anyone tried the
- DS2000A_Upgrade_Utility_1_0_0_1_Portable.zip on http://gotroot.ca/rigol/ (http://gotroot.ca/rigol/) Or
- the webbased tool which was posted by norkimo on http://www.sonsivri.to/forum/index.php?topic=53230.25 (http://www.sonsivri.to/forum/index.php?topic=53230.25)

and could tell me his experience with them?

I have been using "DS2000A_Upgrade_Utility_1_0_0_1_Portable.zip" to unlock all options of my DS2102A.
No pain !
I just experienced troubles finding a USB stick which was supported. Before the 'upgrade' I had been using several models for data, or screen copy export without any problem, but all these sticks did not work for the firmware flash.
I was finally successfull with an old USB 1.0 32Mo stick ..!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dadler on March 23, 2015, 05:37:29 pm
How does it works with DP832 power supply ?

Just use the website.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: OldNeurons on March 23, 2015, 06:17:27 pm
How does it works with DP832 power supply ?

Just use the website.

I tried for my DP832, firmware rev. 00.01.13, with no luck.
I send the command :SYSTem:OPTion:INSTall MxxxxxxxxxxxxxxxxxxxxxxT, but no message on the DP832 screen, no error from Ultra Sigma...
Anybody successfull with 00.01.13 ?

Thanks for your feedback.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dadler on March 23, 2015, 06:41:14 pm
How does it works with DP832 power supply ?

Just use the website.

I tried for my DP832, firmware rev. 00.01.13, with no luck.
I send the command :SYSTem:OPTion:INSTall MxxxxxxxxxxxxxxxxxxxxxxT, but no message on the DP832 screen, no error from Ultra Sigma...
Anybody successfull with 00.01.13 ?

Thanks for your feedback.

Try entering the code via the UI. I've had bad luck installing options on the DP832 via SCPI. Took a while, but I was able to unlock all options on my DP832, latest hardware and firmware.

Also note there is a 12 hour (run-time) lock out period if an invalid code is entered too many times. Also, no dashes. Your code doesn't look long enough either, mine on the DP832 were 28 characters long.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: OldNeurons on March 23, 2015, 06:50:09 pm
How does it works with DP832 power supply ?

Just use the website.

I tried for my DP832, firmware rev. 00.01.13, with no luck.
I send the command :SYSTem:OPTion:INSTall MxxxxxxxxxxxxxxxxxxxxxxT, but no message on the DP832 screen, no error from Ultra Sigma...
Anybody successfull with 00.01.13 ?

Thanks for your feedback.

Try entering the code via the UI. I've had bad luck installing options on the DP832 via SCPI. Took a while, but I was able to unlock all options on my DP832, latest hardware and firmware.

Also note there is a 12 hour (run-time) lock out period if an invalid code is entered too many times.

Thank you very much !!!  :-+
I just unlocked the High Res option by manually entering the code.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: guiasse on March 24, 2015, 07:14:03 am
You just have to copy SN on label and copy Key given by the tool.
This is incredible how easy it is. I will buy a ds812 to try it.
Many thanks !
Gui
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Blitzbirnep on March 24, 2015, 10:48:46 am
Does anyone tried the
- DS2000A_Upgrade_Utility_1_0_0_1_Portable.zip on http://gotroot.ca/rigol/ (http://gotroot.ca/rigol/) Or
- the webbased tool which was posted by norkimo on http://www.sonsivri.to/forum/index.php?topic=53230.25 (http://www.sonsivri.to/forum/index.php?topic=53230.25)

and could tell me his experience with them?

I have been using "DS2000A_Upgrade_Utility_1_0_0_1_Portable.zip" to unlock all options of my DS2102A.
No pain !
I just experienced troubles finding a USB stick which was supported. Before the 'upgrade' I had been using several models for data, or screen copy export without any problem, but all these sticks did not work for the firmware flash.
I was finally successfull with an old USB 1.0 32Mo stick ..!

thanks for your feedback i will buy a ds2072 in a few days and than i will report my tries.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: remilton on March 24, 2015, 01:02:39 pm
Does anyone tried the
- DS2000A_Upgrade_Utility_1_0_0_1_Portable.zip on http://gotroot.ca/rigol/ (http://gotroot.ca/rigol/) Or
- the webbased tool which was posted by norkimo on http://www.sonsivri.to/forum/index.php?topic=53230.25 (http://www.sonsivri.to/forum/index.php?topic=53230.25)

and could tell me his experience with them?

I have been using "DS2000A_Upgrade_Utility_1_0_0_1_Portable.zip" to unlock all options of my DS2102A.
No pain !
I just experienced troubles finding a USB stick which was supported. Before the 'upgrade' I had been using several models for data, or screen copy export without any problem, but all these sticks did not work for the firmware flash.
I was finally successfull with an old USB 1.0 32Mo stick ..!

thanks for your feedback i will buy a ds2072 in a few days and than i will report my tries.

I'll be interested to know if you succeed as I think that is the method of flashing back to an older firmware and as far as I know that does not work with the last few versions of firmware.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: OldNeurons on March 24, 2015, 04:25:36 pm
Does anyone tried the
- DS2000A_Upgrade_Utility_1_0_0_1_Portable.zip on http://gotroot.ca/rigol/ (http://gotroot.ca/rigol/) Or
- the webbased tool which was posted by norkimo on http://www.sonsivri.to/forum/index.php?topic=53230.25 (http://www.sonsivri.to/forum/index.php?topic=53230.25)

and could tell me his experience with them?

I have been using "DS2000A_Upgrade_Utility_1_0_0_1_Portable.zip" to unlock all options of my DS2102A.
No pain !
I just experienced troubles finding a USB stick which was supported. Before the 'upgrade' I had been using several models for data, or screen copy export without any problem, but all these sticks did not work for the firmware flash.
I was finally successfull with an old USB 1.0 32Mo stick ..!

thanks for your feedback i will buy a ds2072 in a few days and than i will report my tries.

I'll be interested to know if you succeed as I think that is the method of flashing back to an older firmware and as far as I know that does not work with the last few versions of firmware.
That's correct. I am afraid that "DS2000A_Upgrade_Utility_1_0_0_1_Portable.zip" will not work with the latest FW revisions. Have a look in that forum for further details.

Edit: Have a look here:
https://www.eevblog.com/forum/testgear/2072a-question-oddity/msg632955/#msg632955 (https://www.eevblog.com/forum/testgear/2072a-question-oddity/msg632955/#msg632955)
Seems Wmacky recently unlocked a DS2072A.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JBR48 on March 25, 2015, 09:58:24 pm

Error: no device found
Error: unable to open ftdi device with vid 15ba, pid 002b, description 'Olimex OpenOCD JTAG ARM-USB-OCD-H' and serial '*'
in procedure 'init'

Any suggestion on what to try next ?

Gus

Hello Gus,

Did you resolve this problem? I saw no further replies.

I have the same issue. I run Win7 64 bit.
Title: Re: YET ANOTHER HACK SUMMARY POST
Post by: ciborgue on March 28, 2015, 03:40:13 am
Dave92F1 excellent post. Confirmed for 00.03.03.01 (latest FW for 03/25/15).

I had to use LAN connection; USB didn't work for me.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jmccorison on April 02, 2015, 09:13:09 pm
Dave92F1, Thanks for a great post on unlocking the DS2072A.

Some observations about it. I first performed the unlock on firmware 00.03.00.SP1 and it worked like a champ. I missed step 11 as it was so similar to step 12, so you are correct that step 11 doesn't need to be performed. I then upgraded to firmware 00.03.03.01 and the previous unlock was still in effect.

When I check installed options all options show as "official version" except for the MEM_DEPTH which stills shows as trial. I can live with that.

When I installed the new key the RigolBildschirmkopie.exe tool displayed an error "There was an error when sending the SCPI command." However it still performed the desired action.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Pacif13r on April 03, 2015, 03:11:46 am
Hi all,

I recently got myself a DS2072A over the 1000Z with the plan of doing the hack to add bandwidth and features. I chose to go down the route of a JTAG memory dump to minimize my chances of doing damage. To this end I got myself a Olimex ARM-USB-OCD-H and made up a cable. As everyone has acknowledged this topic is a monster and a half to follow with myriad sub topics having sprung up. Luckily I chanced upon beurgi's #2431 summary of what had been learned. Following those instructions I've got as far as trying to get a memdump...

This has been problematic as rigup is unable to find keys so I've looked at the dump files and I'm certainly not getting anything like what I would have expected (without knowing what to expect in this scopes ram). I've confirmed my results are odd by locating some dumps for the DS2072A which people have uploaded and having a look at these.

Everything appears to work but the resulting dump is around 130MB looks to be 98% full of long runs of FF bytes and then long runs of 00 bytes with the very occasional and sporadic exceptions which tend to be limited to repeated and limited selection of bytes

First image is that it seems to start off ok for a couple of dozen bytes and then...
Second image is a randomly selected island of non FF/00 bytes.

I'm using Ubuntu x64 in a VMware host on my Win7 x64 laptop but I guess I'd think that if that were a factor I wouldn't be able to get as far as I do.
Model: DS2072A
Serial: DS2D16535XXXX
SW Ver: 00.03.03.SP1
HW Ver: 2.0

Code: [Select]
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=bfin-uclinux".
(gdb) target remote :2000
Remote debugging using :2000
0x00000000 in ?? ()
(gdb) info mem
Using memory regions provided by the target.
Num Enb Low Addr   High Addr  Attrs
0   y  0x20000000 0x20400000 rw nocache
1   y  0xef000000 0xef008000 ro nocache
2   y  0xff800000 0xff804000 rw nocache
3   y  0xff804000 0xff808000 rw nocache
4   y  0xff900000 0xff904000 rw nocache
5   y  0xff904000 0xff908000 rw nocache
6   y  0xffa00000 0xffa0c000 rw nocache
7   y  0xffa10000 0xffa14000 rw nocache
8   y  0xffb00000 0xffb01000 rw nocache
9   y  0xffc00000 0xffe00000 rw nocache
10  y  0xffe00000 0x100000000 rw nocache
(gdb) dump binary memory ~/electronics/ds2k_00_sdram.bin   0x00000000 0x07FFFFFF
Any thoughts gratefully appreciated if anyone has come across this before?  :-//

Thanks,
Justin
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: CustomEngineerer on April 03, 2015, 06:53:47 am
While opening up your scope so you can hook up JTAG shouldn't be too terribly risky, its still far more risky than just hooking up a network or usb cable to the ports on the outside of the case. There should be no reason to need to open up the scope at all. When I first tried the hack I was having a hard time getting a full dump, I can't remember which SPCI program I was using at the time (probably UltraSigma) but once I switched over to using Bildschirmkopie to get the dump it worked first time. And it has also worked several times since when I lost the original memory dump and generated keys and wanted to try playing around with other options.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Pacif13r on April 03, 2015, 08:21:45 am
While opening up your scope so you can hook up JTAG shouldn't be too terribly risky, its still far more risky than just hooking up a network or usb cable to the ports on the outside of the case. There should be no reason to need to open up the scope at all. When I first tried the hack I was having a hard time getting a full dump, I can't remember which SPCI program I was using at the time (probably UltraSigma) but once I switched over to using Bildschirmkopie to get the dump it worked first time. And it has also worked several times since when I lost the original memory dump and generated keys and wanted to try playing around with other options.

Thanks, I was under the impression, that this required a custom firmware flash? I've enjoyed a couple of bricking experiences over the years so I'm super wary with high ticket items...  ::)
Still if there are no horror stories with the technique on here perhaps I should reconsider given my lack of JTAG success unless someone has some insight to share on my problem.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: CustomEngineerer on April 03, 2015, 08:50:54 am
There is no longer a need for the custom firmware flash. The current way works with the latests firmware. I believe it was first reported around Aug - Sept 2014. Sorry I dont remember exactly where the steps are in this thread (they are also listed in plenty of other threads, there was a much more recent thread on hacking the rigol scopes from I think Feb 2015). I would go back in this thread to Aug 2014 and go forward from there, or try to find one of the more recently created threads.

1) Use RigolBildschirmkopie program to issue SCPI command to have scope dump memory. My memory dump was only the first 32MB.
2) Use rigup program on dump from step 1 to generate the key codes.
3) Use RigolBildschirmkopie/UltraSigma or any SCPI program to send the key code to the scope. You can also manually add the key code through the scopes interface just like you would if you had purchased an upgrade from Rigol.

Thats it, no opening scope, no flashing custom firmware, no need to downgrade firmware. Once you get it the whole process takes less than 5 minutes.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: CustomEngineerer on April 03, 2015, 08:59:53 am
I found one of the shorter to the point threads on hacking the DS2000A series. This link goes straight to reply #44, the replies before that are talking about the older ways to do the hack so you shouldn't need to look back any further.
https://www.eevblog.com/forum/testgear/unlockinghacking-the-rigol-ds2000a-series-scope-the-short-post/msg559767/#msg559767 (https://www.eevblog.com/forum/testgear/unlockinghacking-the-rigol-ds2000a-series-scope-the-short-post/msg559767/#msg559767)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jmccorison on April 03, 2015, 03:09:53 pm
Or, for a slightly more detailed description you can go back one page in this thread to Dave92F1's excellent write up:
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg633003/#msg633003 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg633003/#msg633003)

In that post he comments that step 11 might not be needed which my recent experience confirms, at least for version 00.03.00.SP1.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Pacif13r on April 03, 2015, 07:37:05 pm
I found one of the shorter to the point threads on hacking the DS2000A series. This link goes straight to reply #44, the replies before that are talking about the older ways to do the hack so you shouldn't need to look back any further.
https://www.eevblog.com/forum/testgear/unlockinghacking-the-rigol-ds2000a-series-scope-the-short-post/msg559767/#msg559767 (https://www.eevblog.com/forum/testgear/unlockinghacking-the-rigol-ds2000a-series-scope-the-short-post/msg559767/#msg559767)

Arrghhh. What  a waste of time on a day trying different combinations of jtag / bluefin drivers / memory ranges / speeds / checking and rechecking my cable  :palm:

This did the trick wonderfully, thanks so much. I will put in here as a warning for others that I did then waste about 2 hours trying different combo's of memory dump via the USB & LAN cable because rigup would not find keys in my dump. It turns out that rigup 1.4.1 despite the sequence indicating a later version of 1.4 might be an entirely different branch which caters only for 1000Z's :( I went back and got 1.4(.0) and it worked straight away on my (ex)DS2072A.

Thanks again for your help! and Thanks for your link too jmccorison it was useful to see the unabridged version when it came to figuring out how to get the code in without manually entering it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dagg on April 05, 2015, 08:51:23 pm
Dave92F1, Thanks for a great post on unlocking the DS2072A.

Some observations about it. I first performed the unlock on firmware 00.03.00.SP1 and it worked like a champ. I missed step 11 as it was so similar to step 12, so you are correct that step 11 doesn't need to be performed. I then upgraded to firmware 00.03.03.01 and the previous unlock was still in effect.

When I check installed options all options show as "official version" except for the MEM_DEPTH which stills shows as trial. I can live with that.

When I installed the new key the RigolBildschirmkopie.exe tool displayed an error "There was an error when sending the SCPI command." However it still performed the desired action.

Forgetting step 11 is exactly causing the mem-depth option to stay on trial, please redo step 11 (only) and it will be ok too, so even after the omission.

Cheers, Jan.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dadler on April 06, 2015, 09:22:54 pm
Wow the non-intrusive nature of the latest DS2000 upgrades almost has me convinced I "need" a DS2000 series scope in addition to my 1054z. The DS2000 series has been out for a few years though, kinda concerned that a new model will be released in the not-too-distant future.

Does Rigol have an average/typical release cadence for new/replacement products?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: guiasse on April 07, 2015, 10:24:41 am
I have followed the tutorial on a MSO2072A it works perfectly. ;D My firmware is 3.03.sp1.
Thanks a lot for that ! That's a really nice work.


Gui
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: milow on April 09, 2015, 02:18:23 pm
For curiosity, I want to understand the details of these hacks, but this thread is huge. I've already read the first 40 pages and want to summarize only the technical details without all the chatter. Or just extract the relevant threads. Is there anyone else who want's to join me?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Dave92F1 on April 09, 2015, 04:55:45 pm
The DS2000 series has been out for a few years though, kinda concerned that a new model will be released in the not-too-distant future.

Does Rigol have an average/typical release cadence for new/replacement products?
The DS2000 is still one of their newer series. I'd be very surprised to see a replacement line before 2018 or so.

That's not to say there might not be a model introduced with some minor tweaks (like the change for DS2000 to DS2000A, which added the 50 ohm input, or the -S version with the AWG added - at extra cost).

But the DS2000 series is still extremely competitive, I'd expect Rigol to be working on other things - for example their DMMs are getting old (much older than the DS2000). Compare to the latest Siglent and Agilent...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: rpb1 on April 10, 2015, 10:28:27 pm
for my DS4024 I see options for enabling decoders.  However, are there known ways to increase BW? 

don't see discussion of that in the thread (I didn't read all 262 posts tho) and gotroot only shows non BW related option enablement.

will DSH9 "all options" also bump bandwidth? to what?

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: electricMN on April 14, 2015, 02:37:10 pm
This worked for me: https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg633003/#msg633003 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg633003/#msg633003)

I have an MSO2072A with firmware version 00.03.00 SP1 and hardware version 2.2.

I tried the USB port but it wouldn't work so I tried the LAN connection and that did the trick.  :)
When sending the commands using RigolBildschirmkopie.exe it said "There was an error when sending the SCPI command." but it worked anyway.
Looking at the installed options, it says I have both the 200MHz and the 300MHz options installed, along with all of the rest of the options.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dadler on April 16, 2015, 06:38:43 am
This worked for me: [url]https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg633003/#msg633003[/url] ([url]https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg633003/#msg633003[/url])

I have an MSO2072A with firmware version 00.03.00 SP1 and hardware version 2.2.

I tried the USB port but it wouldn't work so I tried the LAN connection and that did the trick.  :)
When sending the commands using RigolBildschirmkopie.exe it said "There was an error when sending the SCPI command." but it worked anyway.
Looking at the installed options, it says I have both the 200MHz and the 300MHz options installed, along with all of the rest of the options.


I can also confirm that this works great. Only tried LAN using "RigolBildschirmkopie", which I guess means RigolScreenshot?  :P

Brand new DS2072A from tequipment.

It came with:

Software version 00.03.01.00.04
Hardware version 1.0.2.0.2
FPGA Version:
  SPU: 04.00.09
  WPU: 01.01.03
  CCU: 12.29.00
  MCU: 00.06

Shows manufacturer date of Aug 4th, 2014 (I guess these have been in stock for a while?).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gunb on April 16, 2015, 09:16:55 am
for my DS4024 I see options for enabling decoders.  However, are there known ways to increase BW? 

don't see discussion of that in the thread (I didn't read all 262 posts tho) and gotroot only shows non BW related option enablement.

will DSH9 "all options" also bump bandwidth? to what?

Cannot be done by option, you'll have to flash special adapted firmware for this purpose. Search for the link for the Rigol files and then for 2.01 from Mr. Krabs.  That'll release 500MHz bandwidth.

Gunb
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: H.O on April 16, 2015, 09:56:33 am
That (too) has changed, some 6 months ago.
See this post (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg523679/#msg523679) and the .pdf attached to it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gunb on April 16, 2015, 07:22:46 pm
That (too) has changed, some 6 months ago.
See this post (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg523679/#msg523679) and the .pdf attached to it.

Thx guy! Did not follow the thread for a while.

Any idea how to unlock latest Ultra Power Analyzer?
Asks me for a key with 4 fields but generating it the same way as described shows that it does not work.

Seems that there's missing a character in the 1st and 3rd field.


Rgds
Gunb
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: H.O on April 16, 2015, 08:29:11 pm
Not sure I understand what you mean.
Is it missing a character in the 1st and 3rd field of the generated code or what?

Looking at the .pdf I'd try FAK9 which would be 500MHz, Power Analzer and all decoder options but no the MA option as I don't know what that is. Punching that into Riglol 1.03d (http://gotroot.ca/rigol/riglol/) gives me key containing 4 groups of 7 characters each. I didn't try it my scope though.

Apparently they've added support for 1553 bus decoding and triggering in the latest version, that's an option which isn't covered in the .pdf
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gunb on April 16, 2015, 09:40:26 pm
Not sure I understand what you mean.
Is it missing a character in the 1st and 3rd field of the generated code or what?

Exactly. You've understood me right.

Looking at the .pdf I'd try FAK9 which would be 500MHz, Power Analzer and all decoder options but no the MA option as I don't know what that is. Punching that into Riglol 1.03d (http://gotroot.ca/rigol/riglol/) gives me key containing 4 groups of 7 characters each. I didn't try it my scope though.

Exactly what I've done before. Exactly the same code I've used. Got also the 4 groups of 7 characters. Did not work. Tried a few times.

Is there a way to see which Ultra Power Version is used?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: electricMN on April 16, 2015, 11:13:14 pm
I can also confirm that this works great. Only tried LAN using "RigolBildschirmkopie", which I guess means RigolScreenshot?  :P

Brand new DS2072A from tequipment.

It came with:

Software version 00.03.01.00.04
Hardware version 1.0.2.0.2
FPGA Version:
  SPU: 04.00.09
  WPU: 01.01.03
  CCU: 12.29.00
  MCU: 00.06

Shows manufacturer date of Aug 4th, 2014 (I guess these have been in stock for a while?).

I requested the latest firmware from Rigol and installed it without loosing my options so that worked out well also.  ;)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: H.O on April 17, 2015, 05:14:58 am
GunB,
I'm sorry, I don't know why it doesn't work for you. Firmware version?
And, just so there's no misunderstanding, I don't have the Power Analyzer option on mine either, all I did yesterday was verify that Riglol did in fact produce a 4x7 character key string - which you said you didn't get but now saying you did.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gunb on April 17, 2015, 06:19:00 am
GunB,
I'm sorry, I don't know why it doesn't work for you. Firmware version?
And, just so there's no misunderstanding, I don't have the Power Analyzer option on mine either, all I did yesterday was verify that Riglol did in fact produce a 4x7 character key string - which you said you didn't get but now saying you did.

Latest firmware, see
https://www.eevblog.com/forum/testgear/rigol-mso4000-and-ds4000-tests-bugs-firmware-questions-etc/255/ (https://www.eevblog.com/forum/testgear/rigol-mso4000-and-ds4000-tests-bugs-firmware-questions-etc/255/)

I got the 4x7 character key produced by Riglol but after installing Power Analyzer and starting the app it asks me for a 15 days trial or entering a key. After I've entered the produced key it says that it does not match.

I've related the missing characters to the fields of the Power Analyzer application where I could enter 8 instead of 7 characters in the 1st and 3rd field ot jump to the next field. Maybe that this is not important, I' don't know. Maybe they've simply changed the keys?


Kind rgds
Gunb
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: H.O on April 17, 2015, 08:40:35 am
So you're saying it's the key for the PC application and not the scopes option code you're talking about?
If that's the case then I'm not sure you can even use Riglol to generate a key, I would suspect not but who am I...
I guess what I'm trying to say is that I don't know I currently don't have a need for the power analyzer so I'm not going to mess around with it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gunb on April 17, 2015, 09:54:44 am
So you're saying it's the key for the PC application and not the scopes option code you're talking about?
If that's the case then I'm not sure you can even use Riglol to generate a key, I would suspect not but who am I...
I guess what I'm trying to say is that I don't know I currently don't have a need for the power analyzer so I'm not going to mess around with it.

Yes.

The scope options I've enabled long ago but I switched back to the default 100MHz of the DS4012.
Yesterday I've tried the first time to go back to 500MHz after I've installed the latest firmware by using Ultra Sigma as described in the PDF you've attached. That works fine! Thank you for that.

Then I've thought to download Ultra Power Analyzer. Done so.

Ultra Power Analyzer can be set "online", which connects to the scope and identifies its serial number. Either the 15 days trial is working or a 4x7 key has to be entered. Thought you've meant that also. And when entering the key there likewise it replies with the message that it does not match.

Well, it's not so important but would be an interesting tool. I can't see any Power option on the scope as the other options like RS232, SPI,.... so I was thinking that the key would only make sense to be used with the PC application itself.


Kind rgds
Gunb
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: commongrounder on April 17, 2015, 02:32:07 pm
I am wondering if the Power Analysis option for the Rigol scopes and the Power Analysis PC software are two unrelated things.  I can't see why there would need to be two separate (and presumably purchased) keys, one for the scope and the other for the PC software, to get PA running.  I would like to think that the PA option for the scope (once implemented) would be a self-contained  mode, and the PC software (I guess once tied to a specific scope) would just analyze data dumps from the scope memory.  :-//
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gunb on April 17, 2015, 05:32:54 pm
Any idea how to unlock latest Ultra Power Analyzer?
Asks me for a key with 4 fields but generating it the same way as described shows that it does not work.
Seems that there's missing a character in the 1st and 3rd field.
Gunb
You may wish to check the DS2000 UPA discussion Here  (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg525924/#msg525924)

Hmm, that's where I've started. Does not help, or did I understand something wrong?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gunb on April 17, 2015, 05:38:45 pm
I am wondering if the Power Analysis option for the Rigol scopes and the Power Analysis PC software are two unrelated things.  I can't see why there would need to be two separate (and presumably purchased) keys, one for the scope and the other for the PC software, to get PA running.  I would like to think that the PA option for the scope (once implemented) would be a self-contained  mode, and the PC software (I guess once tied to a specific scope) would just analyze data dumps from the scope memory.  :-//

That was my thinking, too.

That's why I've understood it that way, that the keys generated with the same characters as for the scope have to be used for unlocking the PC app, too.

The only possible answer for the question would be that the scope as well as the PC software have to be unlocked to communicate afterwards. But that would imply that both exchange the confirmation about the unlocked option.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gunb on April 17, 2015, 06:07:09 pm
 :-+

Well guys,

the key does not work, but I've checked the registry in between. Ultra Power follows the same concept as Ultra Spectrum for the DSA815 which I have got, too.
Under [-HKEY_LOCAL_MACHINE\SOFTWARE\RIGOL Technologies, Inc\Ultra Sigma\Tools] there are 2 entries now which let me come to the conclusion, that after
15 days both can be reset with the registry hack used only for Ultra Spectrum before.
So I've set the date to the next month, and as expected Ultra Power asked me for the key to be activated. I've used the registry hack and voila - worked fine again!

So. there's a way for using Ultra Power unlimited as Ultra Spectrum before  :) :) :)

Rgds
Gunb
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: H.O on April 18, 2015, 08:38:20 am
I agree, why is there a need for a PC software key when you must have a scope with the PA option enabled connected to the PC in order to actually use the software?

Anyway, have you tried generating a key (for the PC) with somethig like AAJA or BAJA?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on April 29, 2015, 01:07:45 am
I'm getting ready to do the U1105 Pin 7&8 hack on my DSA815-TG and while it's open I'd like to dump memory to look at things like has the serial changed? or would the same hacks that got the MSO1000's going work on the DSA815 with the 1.04 boot loader

Does anyone know which JTAG header I need to plug into and what I need to dump memory wise?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on April 29, 2015, 12:26:49 pm
Does anyone know which JTAG header I need to plug into and what I need to dump memory wise?
You do not have to do a memory dump to see the current Serial Number.  Simply go to DSA System Info and compare the S/N here to the Rear Panel S/N Label.  They should be the same.
JTAG Connections:  Once you remove the DSA815's Rear Plastic Cover you will see the two connectors.  You will NOT have to remove the metal shield, just the rear plastic cover!  The upper connector is the 8 Pin 'SPI' Interface for VREF, and the lower connector is the 14 Pin (Blackfin) 'JTAG' Interface.
Do NOT connect Pin 7 (3.3 VDC) of the 'SPI' (8 Pin) Connector to Pin 1 of the (14 Pin) 'JTAG' connector.  It won't hurt anything, except the DSA815 will not initialize and Power up.
Reference this -> https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg522376/#msg522376 (https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg522376/#msg522376)  for the Pin-out details.
Note: You may be able to use this application here ->  http://peter.dreisiebner.at/rigol-bildschirmkopie-lan/ (http://peter.dreisiebner.at/rigol-bildschirmkopie-lan/)  without needing to go to the trouble of doing a JTAG Memory Dump.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on April 30, 2015, 06:31:10 am
Does anyone know which JTAG header I need to plug into and what I need to dump memory wise?
By the way:  You do not have to do a memory dump to see the current Serial Number.  Simply go to DSA System Info and compare the S/N here to the Rear Panel S/N Label.  They should be the same.

I meant Private Key not serial number, sorry about that.

Thanks for the rest.  not sure how I missed the JTAG Header info in that thread
I think I also saw the range to dump in it and that it could be dump via SCPI
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dadler on May 24, 2015, 10:15:17 pm
Does anyone know which JTAG header I need to plug into and what I need to dump memory wise?
By the way:  You do not have to do a memory dump to see the current Serial Number.  Simply go to DSA System Info and compare the S/N here to the Rear Panel S/N Label.  They should be the same.

I meant Private Key not serial number, sorry about that.

Thanks for the rest.  not sure how I missed the JTAG Header info in that thread
I think I also saw the range to dump in it and that it could be dump via SCPI

Were you ever able to dump the memory via JTAG?

SCPI READ seems to not be implemented on my DSA815, or I am doing something wrong.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jouyang3 on May 24, 2015, 11:52:57 pm
Hello guys, does anyone know how shall I connect to the Blackfin JTag via Altera USB-Blaster? (I am hacking DS2072A with v3 kernel). I have connected to the board through the description from Analog's and Altera's datasheet yet bfin-debug complains about device not found. The TRST and SRST pins are not present in the usb-blaster, is it required to get a memory dump? One last thing, do I have to use the external circuit to make the signal recognizable through usb? If so, can anyone provide me with the schematics? (The image for the connection in previous post is no longer valid) Thank you everyone! Have a nice day!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pascal_sweden on May 25, 2015, 03:32:06 pm
Why are people still opening up their scopes and doing all sorts of tricks with JTAG to hack their scope, while you can simply send SCPI commands to enable all the options for free?

https://www.eevblog.com/forum/testgear/unlockinghacking-the-rigol-ds2000a-series-scope-the-short-post/msg559767/#msg559767 (https://www.eevblog.com/forum/testgear/unlockinghacking-the-rigol-ds2000a-series-scope-the-short-post/msg559767/#msg559767)

Or does that SCPI hack not work on all Rigol models? Which models work? Which models don't work?
Does it still work in the newer firmware versions?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: miguelvp on May 25, 2015, 05:26:06 pm
Simple, some people are curious on how things really work inside, maybe just to get a better understanding on how it's done or maybe because they want to do their own custom firmware for whatever they think they can add into the scope that is not there.

Maybe as simple as being able to play pong on it :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pascal_sweden on May 25, 2015, 07:20:54 pm
Isn't the scope protected with a secure bootloader?

Usually the firmware contains an RBL part and a DBL part: Resident Boot Loader and Dynamic Boot Loader.

The RBL part is stored in the One-Time-Progammable OTP area of the flash and can not be changed.
It only accepts secure (signed) boot images in the DBL part, to prevent that unauthorized software can be installed on the device.

This is at least how we did it in Motorola STB products :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jouyang3 on May 25, 2015, 10:54:37 pm
Why are people still opening up their scopes and doing all sorts of tricks with JTAG to hack their scope, while you can simply send SCPI commands to enable all the options for free?

https://www.eevblog.com/forum/testgear/unlockinghacking-the-rigol-ds2000a-series-scope-the-short-post/msg559767/#msg559767 (https://www.eevblog.com/forum/testgear/unlockinghacking-the-rigol-ds2000a-series-scope-the-short-post/msg559767/#msg559767)

Or does that SCPI hack not work on all Rigol models? Which models work? Which models don't work?
Does it still work in the newer firmware versions?

The SCPI hack works. But I just want to see how people actually did it with JTag + USB Blaster. I think this will help me understand the interface better.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dadler on May 26, 2015, 12:00:23 am
Why are people still opening up their scopes and doing all sorts of tricks with JTAG to hack their scope, while you can simply send SCPI commands to enable all the options for free?

https://www.eevblog.com/forum/testgear/unlockinghacking-the-rigol-ds2000a-series-scope-the-short-post/msg559767/#msg559767 (https://www.eevblog.com/forum/testgear/unlockinghacking-the-rigol-ds2000a-series-scope-the-short-post/msg559767/#msg559767)

Or does that SCPI hack not work on all Rigol models? Which models work? Which models don't work?
Does it still work in the newer firmware versions?

As far as I know, the only option right now with the DSA815 is pulling the write protect pin on the FRAM chip high to extend the trials indefinitely. The newer bootloader disallows installation of older firmware, and nobody has cracked the newer firmware yet.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on May 27, 2015, 12:08:59 pm
Why are people still opening up their scopes and doing all sorts of tricks with JTAG to hack their scope, while you can simply send SCPI commands to enable all the options for free?

https://www.eevblog.com/forum/testgear/unlockinghacking-the-rigol-ds2000a-series-scope-the-short-post/msg559767/#msg559767 (https://www.eevblog.com/forum/testgear/unlockinghacking-the-rigol-ds2000a-series-scope-the-short-post/msg559767/#msg559767)

Or does that SCPI hack not work on all Rigol models? Which models work? Which models don't work?
Does it still work in the newer firmware versions?

It varies by product.   The DS1000Z/MSO1000Z don't support the SCPI reads for example.   and while the DS1000Z do work with gen software the MSO you have to open to dump the memory to get the gen to work.   So its a 'it depends' on the  product as to why some are using JTAG.  plus if you want to enjoy and have some fun there's nothing like opening your own up.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: BloodyCactus on May 28, 2015, 05:53:16 pm
the 1032Z AWG does not support dumping the memory over SCPI read command either.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pascal_sweden on May 29, 2015, 12:24:05 pm
On the website of the tool Rigol Bildschirmkopie LAN/USB it says MSO1104Z:
http://peter.dreisiebner.at/rigol-bildschirmkopie-lan/#screenshot (http://peter.dreisiebner.at/rigol-bildschirmkopie-lan/#screenshot)

Benutzer konnten das Programm mit folgenden Geräten verwenden:

    DSA815 - LAN/USB
    DSA1030A - LAN/?
    DS1074Z-S - LAN/USB
    DS1104Z-S - LAN/USB
    DS2202 - LAN/USB
    DS4054 - LAN/?
    MSO1104Z - ?/USB
    MSO2072A - LAN/USB
    MSO2302A - LAN/USB
    MSO4024 - LAN/?
    DM3068 - -/USB


Does that mean that for MSO1104Z in particular it works and not for MSO1074Z?
Or does it mean that it works for all MSO1000 series, but only via USB and not via LAN?

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: shrek on May 29, 2015, 01:01:13 pm
Has anyone tried to hack the DP832's ANALOG board? Any luck with JTAG and full memory dump of the controller?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pascal_sweden on May 29, 2015, 01:27:43 pm
Some people wrote a few entries earlier in this forum post that DS1000Z and MSO1000Z series don't support SCPI commands to read out memory, and that this is the reason why you need to open up your scope and use JTAG to read out the memory.

Apparently you don't need memory dump for DS1000Z series, as it will work with Riglol and serial number.

But for MSO1000Z series you need memory dump, and there is where JTAG comes into picture, as SCPI does not work.

Would be nice to really get this confirmed? I really hope SCPI works on both DS1000Z and MSO1000Z series.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pascal_sweden on May 29, 2015, 03:25:28 pm
So this confirms that the Bildschirm tool does not work on DS1000Z and MSO1000Z scopes?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: miguelvp on May 29, 2015, 03:51:13 pm
Would be nice to really get this confirmed? I really hope SCPI works on both DS1000Z and MSO1000Z series.

Here are the SCPI commands of the firmware 00.04.02.SP4 (DS1074Z-S). I have not found any commands for reading the memory.

Peter

Strange no one looks for the programming manual:

http://www.batronix.com/pdf/Rigol/ProgrammingGuide/MSO1000Z_DS1000Z_ProgrammingGuide_EN.pdf (http://www.batronix.com/pdf/Rigol/ProgrammingGuide/MSO1000Z_DS1000Z_ProgrammingGuide_EN.pdf)

You are looking for WAVeform:DATA? (lowercase optional WAV:DATA? will work as well)
but you need to set things up first

Also there are ways to talk to the Rigol without the NI-VISA library.

Same thing for the DS2000 but that one doesn't support telnet access but the DS/MSO1000Z series does.

Programming manual for the DS2000 if your google fu is not strong enough
http://www.tequipment.net/assets/1/26/Documents/Rigol/DS2072/ds2072_doc_5.pdf (http://www.tequipment.net/assets/1/26/Documents/Rigol/DS2072/ds2072_doc_5.pdf)


But if you mean the actual programming memory then no dice as far as I know.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ebastler on May 29, 2015, 03:59:03 pm
So this confirms that the Bildschirm tool does not work on DS1000Z and MSO1000Z scopes?

You mean this tool? http://peter.dreisiebner.at/rigol-bildschirmkopie-lan/ (http://peter.dreisiebner.at/rigol-bildschirmkopie-lan/)

Why would the SCPI command list imply that it does not work? On his web page, the author of the Bildschirmkopie software explicitly confirms that it works for the DS1000Z as well as the MSO1000Z, both via LAN and USB.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pascal_sweden on May 29, 2015, 04:22:43 pm
So if I get it right: DS1000Z and MSO1000Z can be hacked through Bildschirmkopie tool after all, and there is no need to open up the scope and use JTAG. The people who open up their scope and use JTAG, just like to do it the hard way.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pascal_sweden on May 29, 2015, 05:50:36 pm
Okey I think that I get it. You can use the tool to issue SCPI commands to the scope in general.
This works for all Rigol scopes, including the DS1000Z and MSO1000Z series. However the SCPI command in particular which you need to hack the scope is the memory read SCPI command, and this command in particular is not implemented in the DS1000Z and MSO1000Z SCPI command set.

Still the tool is useful for the DS1000Z and MSO1000Z series, for other actions, like making a screen capture of the displayed waveform, etc.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: d6diesel on May 31, 2015, 02:35:22 pm
It seems Dave92F1 has provided a superb method while we all stand on the shoulders of giants (Peter, rigup).

Dave's method:

YET ANOTHER HACK SUMMARY

I had all options + 300 MHz on my DS2072A, then I upgraded to the latest firmware, and lost all the hacks. It took me some time to figure out how to get them back.

This is my summary (should work for a new out-of-the-box DS2072A as well):

1 - Download & unzip the latest "Rigol Bildschirmkopie LAN/USB" from http://peter.dreisiebner.at/rigol-bildschirmkopie-lan/ (http://peter.dreisiebner.at/rigol-bildschirmkopie-lan/)

2 - Connect scope to LAN.

3 - Run the RigolBildschirmkopie.exe, click Device>Select>Search>Select.

4 - Do Device>SCPI-Command, then  Send & receive ":SYST:UTIL:READ? 1,33554432".
 
     Wait a long time (~5 to 10 min) for it to complete.
     
     Click Save, save it as "memoryDump.scpi" (save this file for future use!!)

5 - Download and unzip Rigup 0.4 (or later) from http://gotroot.ca/rigol/. (http://gotroot.ca/rigol/.)

6 - Open a command window where you unzipped Rigup 0.4, copy memoryDump.scpi into the same folder.

7 - In the command window do: "rigup ds2072a memoryDump.scpi"

      This will produce an output something like:

rigup ds2072a - Version 0.4

Serial number: DSxxxxx

NSEH:  JPJQLFK-G3QNRLU-WFFFZMD-xxxxxxx    All options, no bandwidth upgrade
NSER:  8NXBL2U-JE2LZL7-9NEN5XK-xxxxxxx   All options, bandwidth 100 MHz
NSEQ:  R939MMG-NR63H25-9H993PX-xxxxxxx    All options, bandwidth 200 MHz
NS8H:  G2YRFYX-D589HNR-4K8YW3H-xxxxxxx    All options, bandwidth 300 MHz

8 - rigup scan MyKeys memoryDump.scpi

This will write your keys to the file "MyKeys".

9 - rigup license MyKeys NS8N

This produces an output something like:

5P89ZX7-LYMCTCS-P4PQ792-xxxxxxx   (NS8N = 0x1C0C3)

10 - Run RigolBildschirmkopie.exe again, click Device>Select>Search>Select (again).

11 - Click Device>SCPI-Command, then send & receive:
       :SYSTem:OPTion:INSTall <key to the right of NSEQ in step 7>

       The key (from step 7) MUST have the dashes removed.

       For example:
       :SYSTem:OPTion:INSTall R939MMGNR63H259H993PXxxxxxxx
       
At this point you should have all options + 200 MHz.

12 - Click Device>SCPI-Command, then send & receive:

       :SYSTem:OPTion:INSTall <key from step 9>

       Again, the key must have all dashes removed.

       For example:
       :SYSTem:OPTion:INSTall 5P89ZX7LYMCTCSP4PQ792xxxxxxx

That's it; you should have 300 MHz + all options now.

Maybe you can skip step 11 - I haven't tried it that way.

If you mess up, no problem. Just send ":SYSTem:OPTion:UNINSTall" and start over.


Only minor tweaks I can add are :
   Step 2 : Connect to lan  so the scope can obtain an IP address and be recognized on your ethernet.

   Step 4 : Do Device>SCPI-Command, then  Send & receive
                 ":SYST:UTIL:READ? 1,33554432".   Remove the first colon  so that it now  reads
                  Do Device>SCPI-Command, then  Send & receive
                  "SYST:UTIL:READ? 1,33554432".  Make sure there is a space after the question
                      mark.
   Step 6 : After the command window is  open use  DOS commands "CD" to  change the directory until you are in the correct one.

   Step 11 : Do this step  just  as he  notes.  He  suggests an  option to leave it out, but others did not get a complete install unless they did step 11 and then step 12.


Minor tweaks really from this newbie.  Can't say enough about the knowledge brought together at the eevblog.  As Dave Jones would say : AWESOME !!
     
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Ivan on June 01, 2015, 05:53:34 pm
Hello.
1) I have a problem with MSO1104Z.
2) I updated the program to 4.3 from the site.
3) I downloaded memory with 0x40000000 to 0x43ffffff
4) I downloaded rigup-0.4.1-mso1000z.zip archive from the site http://gotroot (http://gotroot) .ca/rigol/
and make all near Ubunta.
5) rigup scan gave out RC5KEY1 etc. SERIAL - coincided with my number.
6) rigup license gave out with 0x1C001 and 0x1C010 and 0x1C0FF keys and any doesn't approach.

It isn't sure, but during copying of jtag the oscilloscope blocked input of the password for 12 hours.

There can be in it a reason of failure and it is necessary to copy memory anew?

Memory 3 hours by means of ULINK were copied.

Please help to generate keys. The packed dump of memory is only 5 Mb.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: BloodyCactus on June 01, 2015, 07:39:32 pm
Would be nice to really get this confirmed? I really hope SCPI works on both DS1000Z and MSO1000Z series.

Here are the SCPI commands of the firmware 00.04.02.SP4 (DS1074Z-S). I have not found any commands for reading the memory.

Peter

Strange no one looks for the programming manual:

http://www.batronix.com/pdf/Rigol/ProgrammingGuide/MSO1000Z_DS1000Z_ProgrammingGuide_EN.pdf (http://www.batronix.com/pdf/Rigol/ProgrammingGuide/MSO1000Z_DS1000Z_ProgrammingGuide_EN.pdf)

You are looking for WAVeform:DATA? (lowercase optional WAV:DATA? will work as well)
but you need to set things up first

thats because were not talking about SCPI commands to get waveform data, but the commands to read the system memory and basically do a raw dump of its internals.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Ivan on June 01, 2015, 08:08:27 pm

thats because were not talking about SCPI commands to get waveform data, but the commands to read the system memory and basically do a raw dump of its internals.

100% - not work. MS1104z isn't present the response on: SYST:UTIL:READ?



But I found out that it is possible to prolong a trial till 62 o'clock for all options rigup license 0x9C001 ... 0x9C004  as 0x1C001 doesn't work for me.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Ivan on June 01, 2015, 09:18:06 pm
Hey!! 
My MSO1074Z-S got now all options Official!!  8)

I managed to discover the problem..
In the new version of rigup, When I use "rigup serial keys.txt MSZ..." to update the serial number, it solves the problem.... 
Then some of preinstalled licenses with rigup search test Ok. Previously they test Fail.

Then I regenerate the licenses and now they test also Ok with "rigup info" command..  Previously they test Fail.
Also i update the firmware after apply licenses and no problem.

Thank You All, specially to users smgvbest for her tutorial at page 252 and to rmd79 for the rigup application.
Regards
Manuel

At whom every time password different.
These actions help. 0x1C0FF works.

And experiences with license 0x9C001 - 0x9C00F add time of 36 hours on one and then 0x9C00F together.

Limit trial of time of 100 hours.

Thanks to all creators of the rigup program.

Hi from Belarus.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: miguelvp on June 01, 2015, 09:55:10 pm
Would be nice to really get this confirmed? I really hope SCPI works on both DS1000Z and MSO1000Z series.

Here are the SCPI commands of the firmware 00.04.02.SP4 (DS1074Z-S). I have not found any commands for reading the memory.

Peter

Strange no one looks for the programming manual:

http://www.batronix.com/pdf/Rigol/ProgrammingGuide/MSO1000Z_DS1000Z_ProgrammingGuide_EN.pdf (http://www.batronix.com/pdf/Rigol/ProgrammingGuide/MSO1000Z_DS1000Z_ProgrammingGuide_EN.pdf)

You are looking for WAVeform:DATA? (lowercase optional WAV:DATA? will work as well)
but you need to set things up first

thats because were not talking about SCPI commands to get waveform data, but the commands to read the system memory and basically do a raw dump of its internals.

I also said:

But if you mean the actual programming memory then no dice as far as I know.

at the end.

Edit: But thanks for the clarification.
Title: Re: Sniffing the Rigol's internal I2C bus...PSE help with MSO1074z
Post by: pierre288 on June 04, 2015, 07:39:26 pm
Hi,

sorry to ask as I presume answer is somewhere within this fabulous thread (thanks for your hard work).
but I need help to solve my problem with MSO1074z-S...
I tried many permutation using rigup without success..

Original firmware was 0.4.1 and I upgraded it to latest 0.4.3...both versions give same results.
I used a Segger J-tag interface to get a memory dump file (address 0x40000000, 3ffffff bytes).
Running rigup 0.4 I scan, I consistently get following error:
     Scanning "memorydump.bin" file failed: No keys

with rigup serial I was able to produce a serial number file.
with rigup search I produced a keyfile (at least I think).
I then merged both text files into a new keyfile.
I then tried to run rigup license...
I get set of license numbers (??) generated but if I repeat this, different numbers are always produced..!!???
I tried two of these numbers which MSO did not accept and madly locked out for 12 hours each time.

At last I retried rigup scan but same results (No keys error)
info does not work either.

What do I do wrong ?
Is there a standard format to produce a compatible blank keyfile.txt file ?
I see no place where to enter model number...is it required and how to do it ?
...need help

thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: McBryce on June 04, 2015, 08:03:34 pm
There's a patched version of rigup for the MSOs are you using the right one?

McBryce.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pierre288 on June 04, 2015, 08:57:52 pm
Hi McBryce,

you got a point there...
I'm using regular 0.4 version.
I noticed there is an other version (rigup-0.4.1-mso1000z) you probably refer too
the only problem is this does not include executable file and I don't have required setup to compile it to run under Windows' Command session.

Anyone has the executable file ?

thanks
pierre
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: McBryce on June 04, 2015, 09:02:57 pm
That's the one :)

Sorry I don't have a windows executable, I compiled it on SuSE 13.2.

McBryce.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on June 04, 2015, 09:12:27 pm
I noticed there is an other version (rigup-0.4.1-mso1000z) you probably refer too
the only problem is this does not include executable file and I don't have required setup to compile it to run under Windows' Command session.
Anyone has the executable file ?

~250 posts ago (Reply #3754) I used this rigup-0.4.1 version to extract the keys for my MSO-1074z ...
I made the memory dump with windows 8.1 but I compiled the rigup with Linux on my RasPi. (Any other Ubuntu Linux running in a VirtualBox should do the job.)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pierre288 on June 04, 2015, 09:32:54 pm
Hi Hammy,
thanks for info...

well I've been thinking to get a Pi for long.
now have a good motivation to move...hi
I expect a fairly long learning curve though but I guess I need to start somewhere.

thanks
pierre288
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Vtech on June 10, 2015, 10:23:45 am
Hi,

I've found some interesting SCPI commands for the 1000Z series.

SYST:BW
SYST:BW?

The most interesting one is SYST:BW <70 or 100>. Judging from the rise time it actually changes the bandwidth of the scope. Sending SYST:BW 100 switches bandwidth of my MSO1074Z-S to 100MHz. Unfortunately it doesn't give 2ns time base nor changes model to MSO1104. It also doesn't last after cycling the power. Still it may have some small usage. Unfortunately it is not possible to change bandwidth to 50MHz (it would be useful for me). Trying to set 50MHz gives 70MHz.
It is also possible to check current bandwidth using SYST:BW? It returns "70" or "100".

I've also checked some other hidden options but I wasn't able to figure them out:

SYST:PRESs
SYST:UDEVice
SYST:UDEVice? (this returns "COMP")
SYST:FLASh:WRITe (this one looks interesting unfortunately there is no READ command)
SYST:KEY:INCRease
SYST:KEY:DECRease

Edit:
I forgot to mention that I've used command list posted by PeDre (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg682648/#msg682648 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg682648/#msg682648))
My firmware is 04.01SP2

SYST:UDEV command switches USB device port between computer and PictBridge.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Trax on June 13, 2015, 12:50:27 pm
If one gets the "Rigol MSO1104Z-S" are there any things to be unlocked? Or is that the full version?
And if this is not the full version than I guess one can go directly for the cheaper "Rigol MSO1074Z-S" and unlock one more thing afterwards?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Trax on June 14, 2015, 06:30:17 am
com on answer!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: miguelvp on June 14, 2015, 06:33:36 am
there are still options unless you get them all.

lookup the model at tequipment.net and see what options can be purchased.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: AndersAnd on June 14, 2015, 06:39:10 am
If one gets the "Rigol MSO1104Z-S" are there any things to be unlocked? Or is that the full version?
And if this is not the full version than I guess one can go directly for the cheaper "Rigol MSO1074Z-S" and unlock one more thing afterwards?
There's no full versions out of the box. Extra options are listed here:
http://www.rigol.com/prodserv/DS1000Z/ (http://www.rigol.com/prodserv/DS1000Z/)
Code: [Select]
Deep Memory Option 24Mpts (1 CH)/12Mpts (2 CH)/6Mpts (4 CH)Memory MEM-DS1000Z
Waveform record option Real Time Waveform Record and Replay function REC-DS1000Z
Advanced Trigger option RS232/UART,I2C,SPI,Runt,Windows,Nth Edge, Delay,Time Out AT-DS1000Z
Serial Analysis  Option RS232/UART,I2C,SPI trigger and decoding functions SA-DS1000Z
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: m-joy on June 14, 2015, 07:17:31 pm
Hi guys, can i update from 2.x version of my Rigol DS2072 (non A Version) which is patched to all options to version 00.03.03.01 without loosing stuff?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on June 14, 2015, 07:48:45 pm
Hi guys, can i update from 2.x version of my Rigol DS2072 (non A Version) which is patched to all options to version 00.03.03.01 without loosing stuff?
Yes, no problem at all.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: m-joy on June 14, 2015, 09:16:20 pm
strange i can not install update on my ds2072.
i took the file from here: http://beyondmeasure.rigoltech.com/acton/fs/blocks/showLandingPage/a/1579/p/p-001a/t/page/fm/0 (http://beyondmeasure.rigoltech.com/acton/fs/blocks/showLandingPage/a/1579/p/p-001a/t/page/fm/0)
then i followed the pdf instruction.
First i checked if the stick is recongnized...check....
I get into the menu where the SINGLE light is activ....check...
Then i put in the stick when the SINGLE light is activ. But nothing happns then. The CH1 light does not light up....
I already tried 3 different ups sticks ^^

---- update: waiting 1min before inserting the stick did the trick...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on June 14, 2015, 09:31:36 pm
. . . I get into the menu where the SINGLE light is activ....check...  Then i put in the stick when the SINGLE light is activ. But nothing happns then. The CH1 light does not light up....   I already tried 3 different ups sticks ^^
Is your USB Flash Drive formatted with FAT32?  Is it empty except for the Firmware update in the root directory?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: daemonix on June 14, 2015, 10:16:13 pm
Hi all,

I have a 1074z unlocked. What is the latest update of firmware i can go without losing the unlocks?!?

I see the new firmwares have some nice with gui updates.

Thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on June 14, 2015, 10:33:56 pm
Hi all,

I have a 1074z unlocked. What is the latest update of firmware i can go without losing the unlocks?!?

I see the new firmwares have some nice with gui updates.

Thanks
You can safely install the latest Firmware.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: daemonix on June 14, 2015, 11:06:19 pm
I remember at some point they pached the online key generator. Is there a new one? (I think it was because they changer the 'master key')

Thnaks a lot mate
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on June 15, 2015, 05:41:01 pm
I remember at some point they pached the online key generator. Is there a new one? (I think it was because they changer the 'master key')

Thnaks a lot mate
The current Keygen is 'Riglol Keygen 1.03d', previously it was version 1.33c.  It was only updated from 1.03c, to 1.03d for the DP832 Series Power Supplies with Firmware version 1.08 and above.  Version 1.03c still works fine for everything else that is listed in the Keygen.
Edit: Added the text in BOLD above.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: McBryce on June 15, 2015, 07:47:08 pm
I remember at some point they pached the online key generator. Is there a new one? (I think it was because they changer the 'master key')

Thnaks a lot mate
The current Keygen is 'Riglol Keygen 1.03d', previously it was version 1.33c.  It was only updated from 1.03c, to 1.03d for the DP832 Series Power Supplies with Firmware version 1.08 and above.  Version 1.03c still works fine for everything else.

Except the MSO1xxx devices which have their own patched version of Riglol and need to be JTAGed to get a memory dump.

McBryce.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on June 15, 2015, 08:30:38 pm
I remember at some point they pached the online key generator. Is there a new one? (I think it was because they changer the 'master key')

Thnaks a lot mate
The current Keygen is 'Riglol Keygen 1.03d', previously it was version 1.33c.  It was only updated from 1.03c, to 1.03d for the DP832 Series Power Supplies with Firmware version 1.08 and above.  Version 1.03c still works fine for everything else.

Except the MSO1xxx devices which have their own patched version of Riglol and need to be JTAGed to get a memory dump.

McBryce.
Everything else, is everything else listed in the Keygen, and yes the MSO01xxx is NOT listed or covered by either or any Keygen version to date. 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: daemonix on June 15, 2015, 09:04:25 pm
I remember at some point they pached the online key generator. Is there a new one? (I think it was because they changer the 'master key')

Thnaks a lot mate
The current Keygen is 'Riglol Keygen 1.03d', previously it was version 1.33c.  It was only updated from 1.03c, to 1.03d for the DP832 Series Power Supplies with Firmware version 1.08 and above.  Version 1.03c still works fine for everything else.

Except the MSO1xxx devices which have their own patched version of Riglol and need to be JTAGed to get a memory dump.

McBryce.
Everything else, is everything else listed in the Keygen, and yes the MSO01xxx is NOT listed or covered by either or any Keygen version to date.


Thank you all
Ill ask for the latest firmware from rigoluk

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on June 15, 2015, 09:31:15 pm

Ill ask for the latest firmware from rigoluk
I asked here http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm?id=0012 (http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm?id=0012)
and got the firmware couple of hours later. (that was for ds2 series though.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on June 15, 2015, 09:34:44 pm
Suggestion: Do NOT remove Options before updating Firmware!  We have never seen new Firmware that we installed remove the Options, although we have seen instances where when Firmware has been updated we were NOT able to install, or re-install the Options.

Please feel free to check this out with others here on the forum if you have doubts.

But to be safe I would NOT remove any Option unless you want to return your unit for Rigol factory repair, which by the way is very seldom ever required.  If your unit works for the first 30 days Ok it will probably last much longer than 3 years (if you don't seriously abuse it yourself).

Generally when someone returns an item for Rigol factory repair they will remove the Options for you, and in general you will never be able to re-install them yourself.  But then how bad can that be, because the Rigol gear is awesome for the price we pay for it even without the Options hijacked in.  And, you can still buy the Options if you want them bad enough.

Please don't ask me how to remove Options.  You can search for this information here in the EEVblog.  And by the way the Options Can NOT be removed by us in the 'DSA800 Series.  But don't worry, Rigol knows how to do it.  Hi Hi
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: McBryce on June 15, 2015, 09:35:39 pm

Except the MSO1xxx devices which have their own patched version of Riglol and need to be JTAGed to get a memory dump.

McBryce.
Everything else, is everything else listed in the Keygen, and yes the MSO01xxx is NOT listed or covered by either or any Keygen version to date.

Ah ok, I didn't understand it that way. However, many people seem to mistakenly think that the DSO1xxx hacks will work on the MSO. I've seen many comments (on this blog and others) assuming that that's the case.

McBryce.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Trax on June 18, 2015, 06:18:51 pm
Is the only difference with regard to hacking between the MSO01xxx and the DSO01xxx that for the MSO a J-Tag memory dump is needed?
Or is there something else thats different?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: BloodyCactus on June 18, 2015, 07:26:12 pm
Suggestion: Do NOT remove Options before updating Firmware!  We have never seen new Firmware that we installed remove the Options, although we have seen instances where when Firmware has been updated we were NOT able to install, or re-install the Options.

except the new firmware for the AWG DG4062, if you set to 200mhz (a model they didnt sell) the new firmware reverts it to 60mhz, if you set it to 150mhz it will stay.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on June 18, 2015, 08:21:33 pm
Suggestion: Do NOT remove Options before updating Firmware!  We have never seen new Firmware that we installed remove the Options, although we have seen instances where when Firmware has been updated we were NOT able to install, or re-install the Options.

except the new firmware for the AWG DG4062, if you set to 200mhz (a model they didnt sell) {Because it was never even offered by Rigol; *Ted5472} the new firmware reverts it to 60mhz, if you set it to 150mhz (correction - 160MHz*) it will stay.
This was an exception, because this was never a Rigol offered capability (or as we incorrectly referred to it, a Option).  See -> https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg581608/#msg581608 (https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg581608/#msg581608)  (DG4000 Firmware thread, Post #270)
It still stands that 'We have never seen new Firmware that we installed remove the Hacked in Options'.  Again, 160MHz was never an Option, although the capability was discovered and found how to get it, it was not fully functional to the Rigol, i.e. the amplitude flatness specifications as were the valid frequency BWs that were available from Rigol.  And it took some special tricks with the DG4000 calibration to get it to be decent.  Which is also documented by me and others in the DG4000 Firmware thread.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Trax on June 20, 2015, 09:15:16 am
I found oen guid from ike how to remove this damn waranty stickers,
are there any more or other methods?
He used a waxy paper to slide it under the sticker very very gently.
can this be simplifyed may be got air and if so how hot?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on June 20, 2015, 10:40:56 pm
I used my Rework Gun set to 200c at about 6-8in and kept it moving plus some backing paper for a cdrom label and it was off in a few minutes.  the heat really made it easy.  previously I just used the paper and it was more stressfull and took 10minutes

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Trax on June 21, 2015, 11:58:13 am
I have one of those, thats a good idea the temp info is the important part, 200°C sounds good :D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on June 23, 2015, 07:25:09 pm
There is new Firmware for the DS2000/DS2000A here -> https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg698800/#msg698800 (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg698800/#msg698800)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on June 24, 2015, 01:22:17 pm
I have one of those, thats a good idea the temp info is the important part, 200°C sounds good :D
Re. Reply #3995 and #3996 above:  I would suggest simply using a Hair Dryer.  With the Hot Air of a Soldering/Rework Tool putting out 200° C (Ouch) you have the potential for doing some serious damage to the label and/or plastic case if you aren't VERY, VERY careful.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on June 24, 2015, 05:43:57 pm
I have one of those, thats a good idea the temp info is the important part, 200°C sounds good :D
Re. Reply #3995 and #3996 above:  I would suggest simply using a Hair Dryer.  With the Hot Air of a Soldering/Rework Tool putting out 200° C (Ouch) you have the potential for doing some serious damage to the label and/or plastic case if you aren't VERY, VERY careful.

That's why 6-8 inches and keep it moving.  plus I would hope anyone using a rework station knows how you use one,  just like it intended use
Drop it down if you want it closer to hair dryer temp,  mine will go to 90C that's still about 60F above a hair dryer
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: TopLoser on June 24, 2015, 05:54:10 pm
Quote
That's why 6-8 inches and keep it moving.

 :-DD
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: McBryce on June 24, 2015, 08:05:45 pm
I used a hair dryer on the last device I "liberated" and even with that I thought the plastic got very hot. The label peeled off almost by itself though :)

McBryce.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on June 25, 2015, 12:59:33 am
Quote
That's why 6-8 inches and keep it moving.

 :-DD

Glad you got a laugh out of if

I should also note I had the airflow way down,  case cut warm not hot and label came up really easy
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dadler on June 25, 2015, 01:55:30 am
I think some innuendo was intended. ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on June 25, 2015, 05:35:08 pm
we play it nice and try to ignore things and the room falls apart   ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jrmymllr on June 27, 2015, 01:55:39 pm
To all you MSO1000Z Owners: It's done, we found what Rigol changed for the MSO1k and we patched rigup to generate working keys.


Another successful hack here on a MSO1104Z.  I used a JTAG interface I had from a Luminary Micro (now TI) ARM eval board.  The dump took around 56 minutes as I didn't try anything to speed it up, but I got rigup compiled under Ubuntu during that time.  No problems at all.  I just couldn't telnet to it like someone has suggested, so entering the keys were a bit tedious. 

While I had the scope open I noticed the cover on the metal can was not all the way down on one corner because a tab was stuck inside instead of on the outside, so I fixed that.  One other suggestion for anyone doing this:  Be careful of the power button.  Mine got scratched slightly (very slightly, hard to see even if you know it), so take care when pulling it apart and reassembling.  The switch goes through a hole in sheet metal, so the edges are sharp.

I also removed the sticker using a heat gun and label backing.  Very slick.  I won't bother reapplying, but am keeping it stuck on label backing just in case.

Thanks also to those (especially smgvbest) for pictures and exact instructions, and of course those who came up with the hack.

I don't know how some of you figure this stuff out.  I develop embedded systems, but reverse engineering crypto seems difficult to me.  At any rate, thanks a bunch.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Trax on June 27, 2015, 08:12:44 pm
has anyone used the "bus pirate" to dump the scope?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pierre288 on June 27, 2015, 10:56:21 pm
Hi all,
Anyone have experience using rigup on a MSO1000z
at the latest firmware version 00.04.03 (June 2015) ..???

Mine was originally at 00.04.01 SP2
I Updated it to 00.04.03 prior to try rigup-mso1000z.
Options do not install...

Could it be that latest version has modifications voiding rigup ?
Any hints ?

Thanks

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jrmymllr on June 28, 2015, 12:13:15 am
Hi all,
Anyone have experience using rigup on a MSO1000z
at the latest firmware version 00.04.03 (June 2015) ..???

Mine was originally at 00.04.01 SP2
I Updated it to 00.04.03 prior to try rigup-mso1000z.
Options do not install...

Could it be that latest version has modifications voiding rigup ?
Any hints ?

Thanks

I don't have 00.04.03, but rather have 00.04.02.SP4 and that worked fine.  This probably doesn't help you much but who knows. 

BTW how did you get new F/W, did you have to request from Rigol or is there there a direct download?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MarkF on June 28, 2015, 12:33:33 am
The upgraded firmware for a DS1Z (00.04.03.SP1) can be found here DS1Z firmware (http://beyondmeasure.rigoltech.com/acton/fs/blocks/showLandingPage/a/1579/p/p-0019/t/page/fm/0).  Rigol has not been updating the zip filename.  See the directory name inside.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on June 28, 2015, 12:43:20 am
Hi all,
Anyone have experience using rigup on a MSO1000z
at the latest firmware version 00.04.03 (June 2015) ..???

Mine was originally at 00.04.01 SP2
I Updated it to 00.04.03 prior to try rigup-mso1000z.
Options do not install...

Could it be that latest version has modifications voiding rigup ?
Any hints ?

Thanks
Is this the one you used
http://gotroot.ca/rigol/rigup-0.4.1-mso1000z.zip (http://gotroot.ca/rigol/rigup-0.4.1-mso1000z.zip)
Just making sure you use the correct one.
there's another one on the site and it does not work
this one once you compile it worked fine but I did not upgrade mine before testing

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jrmymllr on June 28, 2015, 12:58:57 am
The upgraded firmware for a DS1Z (00.04.03.SP1) can be found here DS1Z firmware (http://beyondmeasure.rigoltech.com/acton/fs/blocks/showLandingPage/a/1579/p/p-0019/t/page/fm/0).  Rigol has not been updating the zip filename.  See the directory name inside.

Any idea what this one fixes?  There doesn't seem to be release notes so probably who knows....
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MarkF on June 28, 2015, 04:52:04 am
The upgraded firmware for a DS1Z (00.04.03.SP1) can be found here DS1Z firmware (http://beyondmeasure.rigoltech.com/acton/fs/blocks/showLandingPage/a/1579/p/p-0019/t/page/fm/0).  Rigol has not been updating the zip filename.  See the directory name inside.

Any idea what this one fixes?  There doesn't seem to be release notes so probably who knows....

Release Notes here (http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-05ba/1/-/-/-/-/DS1000Z%20Firmware%20Release%20Notes.pdf?sid=ErJFAfDAl).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Trax on June 28, 2015, 05:48:39 am
Simple question but:
When you got your scope how long have you waited before installing the hacked options?
In order to test if its running ok, etc...

And what happens if the scope would fail and be in need of repair while having hacked options? I guess as long as it boots the options could be simply removed before sending it in, but what if the scope wouldn't boot at all?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Trax on June 28, 2015, 07:59:00 am

Oscilloscope        BusPirate
TDO <------------> MISO (According to the label in the PCB, however when in JTAG mode it is TDO as it is supposed to be)
TCK <------------> CLK (Again in JTAG mode this is TCK)
TMS <------------> CS (Which is TMS in JTAG mode)
TDI <------------> MOSI (TDI in JTAG mode)
3.3V <-----------> 3.3V
GND  <-----------> GND


why is it needed to connect the 3.3v line? shouldn't booth devices have their own 3.3v?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Karel on June 28, 2015, 08:00:24 am
Simple question but:
When you got your scope how long have you waited before installing the hacked options?
In order to test if its running ok, etc...

One day.

And what happens if the scope would fail and be in need of repair while having hacked options? I guess as long as it boots the options could be simply removed before sending it in, but what if the scope wouldn't boot at all?

I don't understand the question. What is the relation between entering a bunch of codes  and a warranty claim?
Maybe in the states this is illegal but where I come from it's completely fine.


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Trax on June 28, 2015, 08:14:09 am
I don't understand the question. What is the relation between entering a bunch of codes  and a warranty claim?
Maybe in the states this is illegal but where I come from it's completely fine.
The question is what would Rigol do if you send in a scope for repair where you installed options that ware not bought from them, a.k.a. hacked.

Would they repair it? Imho they would know that the scope was opened as to hack it a memory dump is needed.

Or would they do something to disable the options permanently, setting/breaking some jumper, burning an eFuse or writing to some read only memory, etc...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Karel on June 28, 2015, 08:19:38 am
Would they repair it? Imho they would know that the scope was opened as to hack it a memory dump is needed.

I see what you mean. Yes, opening is risky. I didn't open it. I just entered the codes on the screen.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Trax on June 28, 2015, 08:32:49 am
Would they repair it? Imho they would know that the scope was opened as to hack it a memory dump is needed.

I see what you mean. Yes, opening is risky. I didn't open it. I just entered the codes on the screen.
Yea, I have the MSO and this requiters the memory dump over J-Tag...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Icchan on June 28, 2015, 10:55:54 am
250+ posts... is there any source that has gathered all this information in one place in more concise manner? Or do I have to read up everything on a forum before knowing what to do if I get MSO4000 series and wish to upgrade it? :D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Trax on June 29, 2015, 06:16:34 am
I'm affraid there is no collected info source for this, someone needs th read the whole thread and make one.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: TomThomas on June 29, 2015, 12:07:51 pm
Simple question but:
When you got your scope how long have you waited before installing the hacked options?
In order to test if its running ok, etc...

One day.

And what happens if the scope would fail and be in need of repair while having hacked options? I guess as long as it boots the options could be simply removed before sending it in, but what if the scope wouldn't boot at all?

I don't understand the question. What is the relation between entering a bunch of codes  and a warranty claim?
Maybe in the states this is illegal but where I come from it's completely fine.

I don't know where you come from, but have you ever heard about  intellectual property? I don't think so!
This is valid worldwide.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Trax on June 29, 2015, 12:15:55 pm
Simple question but:
When you got your scope how long have you waited before installing the hacked options?
In order to test if its running ok, etc...

One day.

And what happens if the scope would fail and be in need of repair while having hacked options? I guess as long as it boots the options could be simply removed before sending it in, but what if the scope wouldn't boot at all?

I don't understand the question. What is the relation between entering a bunch of codes  and a warranty claim?
Maybe in the states this is illegal but where I come from it's completely fine.

I don't know where you come from, but have you ever heard about  intellectual property? I don't think so!
This is valid worldwide.

I don't think this falls under intellectual property, you are not duplicating anything. At least its a gray area.

Besides they would not legally have the right to deny a warranty claim, they may try to sue you independently (in reality the could not probably as the damage is not high enough).

But since this is a gray area they are most likely to eider do nothing or try to do some extrajudicial punishment, and than you would need to sue them such that they will repair it. But well if they are china based that may be a problem.

My question goes more in the direction of has anyone send in their scope for rapier with hacks and what was the outcome?

Trax
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pierre288 on June 29, 2015, 01:41:12 pm
Hi all,
Anyone have experience using rigup on a MSO1000z
at the latest firmware version 00.04.03 (June 2015) ..???

Mine was originally at 00.04.01 SP2
I Updated it to 00.04.03 prior to try rigup-mso1000z.
Options do not install...

Could it be that latest version has modifications voiding rigup ?
Any hints ?

Thanks
Is this the one you used
http://gotroot.ca/rigol/rigup-0.4.1-mso1000z.zip (http://gotroot.ca/rigol/rigup-0.4.1-mso1000z.zip)
Just making sure you use the correct one.
there's another one on the site and it does not work
this one once you compile it worked fine but I did not upgrade mine before testing

Hi Sarah,
yes I used version you indicate...
I am concluding I should not have update firmware before "rigup"

thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pierre288 on June 29, 2015, 01:43:36 pm
Hi all,
Anyone have experience using rigup on a MSO1000z
at the latest firmware version 00.04.03 (June 2015) ..???

Mine was originally at 00.04.01 SP2
I Updated it to 00.04.03 prior to try rigup-mso1000z.
Options do not install...

Could it be that latest version has modifications voiding rigup ?
Any hints ?

Thanks

I don't have 00.04.03, but rather have 00.04.02.SP4 and that worked fine.  This probably doesn't help you much but who knows. 

BTW how did you get new F/W, did you have to request from Rigol or is there there a direct download?

FYI I got update via a reqest to Rigol...
cheers
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: farzadb82 on June 29, 2015, 02:16:14 pm
Hi Guys,

Does anyone have a link to download the DS/MSO1000Z firmware v00.04.03 ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Trax on June 29, 2015, 03:36:22 pm
I'm wondering why is it that rigup can hack the DSO model based only on the serial but not the MSO and needs here a memory dump.
Is the private key for the DSO's all the same while for the MSO each different? Or is there just some code not discovered that woudl allow to generate all data for the MSO also only based on the serial?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on June 29, 2015, 03:49:54 pm
Hi Guys,

Does anyone have a link to download the DS/MSO1000Z firmware v00.04.03 ?

Go here -> http://beyondmeasure.rigoltech.com/acton/ct/1579/p-0019/Bct/l-3f49/l-3f49:ee3/ct1_0/1?sid=5QnnsxcKo (http://beyondmeasure.rigoltech.com/acton/ct/1579/p-0019/Bct/l-3f49/l-3f49:ee3/ct1_0/1?sid=5QnnsxcKo)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: farzadb82 on June 29, 2015, 04:04:11 pm
Hi Guys,

Does anyone have a link to download the DS/MSO1000Z firmware v00.04.03 ?

Go here -> http://beyondmeasure.rigoltech.com/acton/ct/1579/p-0019/Bct/l-3f49/l-3f49:ee3/ct1_0/1?sid=5QnnsxcKo (http://beyondmeasure.rigoltech.com/acton/ct/1579/p-0019/Bct/l-3f49/l-3f49:ee3/ct1_0/1?sid=5QnnsxcKo)

Fantasic!  Thanks.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neki on June 29, 2015, 06:55:31 pm
enjoy

http://pastebin.com/ghYHnCfT (http://pastebin.com/ghYHnCfT)



The above link is not working anymore. Does anybody have those files (DSA815 options hack)? Thanks in advance.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on June 29, 2015, 07:18:39 pm
enjoy
http://pastebin.com/ghYHnCfT (http://pastebin.com/ghYHnCfT)
The above link is not working anymore. Does anybody have those files (DSA815 options hack)? Thanks in advance.
neki:  I suggest browsing back through here -> https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg683215/#msg683215 (https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg683215/#msg683215)  This is simply the last post, but you will be able to learn a lot about the DSA815/815-TG here.  If you currently have a DSA815, what Firmware version and Boot version does it have?  Perhaps we can save you some time researching.  In any case this is a better place to look for answers and ask DSA815 questions.

Edit:  Re. your DSA815 Firmware and Boot version, if you reply please do it on the EEVblog 'Spectrum Analyzer-Rigol DSA815' thread. 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: McBryce on June 30, 2015, 12:09:38 pm
Hi Guys,

Does anyone have a link to download the DS/MSO1000Z firmware v00.04.03 ?

Go here -> http://beyondmeasure.rigoltech.com/acton/ct/1579/p-0019/Bct/l-3f49/l-3f49:ee3/ct1_0/1?sid=5QnnsxcKo (http://beyondmeasure.rigoltech.com/acton/ct/1579/p-0019/Bct/l-3f49/l-3f49:ee3/ct1_0/1?sid=5QnnsxcKo)

Are you sure that that Firmware is valid for the MSO series too? I was under the impression that the firmware differed between the MSO and DSO.

McBryce.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jrmymllr on June 30, 2015, 12:13:04 pm
Hi Guys,

Does anyone have a link to download the DS/MSO1000Z firmware v00.04.03 ?

Go here -> http://beyondmeasure.rigoltech.com/acton/ct/1579/p-0019/Bct/l-3f49/l-3f49:ee3/ct1_0/1?sid=5QnnsxcKo (http://beyondmeasure.rigoltech.com/acton/ct/1579/p-0019/Bct/l-3f49/l-3f49:ee3/ct1_0/1?sid=5QnnsxcKo)

Are you sure that that Firmware is valid for the MSO series too? I was under the impression that the firmware differed between the MSO and DSO.

McBryce.

I installed that one on my MSO1104Z.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: McBryce on June 30, 2015, 12:16:21 pm
Hi Guys,

Does anyone have a link to download the DS/MSO1000Z firmware v00.04.03 ?

Go here -> http://beyondmeasure.rigoltech.com/acton/ct/1579/p-0019/Bct/l-3f49/l-3f49:ee3/ct1_0/1?sid=5QnnsxcKo (http://beyondmeasure.rigoltech.com/acton/ct/1579/p-0019/Bct/l-3f49/l-3f49:ee3/ct1_0/1?sid=5QnnsxcKo)

Are you sure that that Firmware is valid for the MSO series too? I was under the impression that the firmware differed between the MSO and DSO.

McBryce.

I installed that one on my MSO1104Z.

And how were the results? Hacks still there? Any noticable improvements?

McBryce.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jrmymllr on June 30, 2015, 12:48:14 pm
Hi Guys,

Does anyone have a link to download the DS/MSO1000Z firmware v00.04.03 ?

Go here -> http://beyondmeasure.rigoltech.com/acton/ct/1579/p-0019/Bct/l-3f49/l-3f49:ee3/ct1_0/1?sid=5QnnsxcKo (http://beyondmeasure.rigoltech.com/acton/ct/1579/p-0019/Bct/l-3f49/l-3f49:ee3/ct1_0/1?sid=5QnnsxcKo)

Are you sure that that Firmware is valid for the MSO series too? I was under the impression that the firmware differed between the MSO and DSO.

McBryce.

I installed that one on my MSO1104Z.

And how were the results? Hacks still there? Any noticable improvements?

McBryce.

Yes, it was hacked previously(trigger, decode, segmented memory, memory), and they are still there after flashing to 00.4.03.  I haven't noticed any differences, but I haven't used it extensively yet. 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: TheSteve on July 01, 2015, 06:53:29 pm
Recently purchased a DSA815-TG. UPS claims it will arrive tomorrow.
Just wondering if anyone has put any effort into enabling the options on the newer units with the updated bootloader. I'd really like to know if Rigol updated the public/private keys and/or did they change the option codes themselves.
I can probably do a jtag dump at some point if that is what is needed.

Also can anyone confirm if the hardware has been updated in the newer production units, I have read mention of a lower noise floor.


PS to Rigol - I bought the DSA815-TG because I am pleased with my DS1054Z that is now fully optioned out. If you remove the ability to enable features on all products people like myself will buy from another company. :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DG5SAY on July 01, 2015, 07:40:26 pm
PS to Rigol - I bought the DSA815-TG because I am pleased with my DS1054Z that is now fully optioned out. If you remove the ability to enable features on all products people like myself will buy from another company. :)

100 %  ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: dadler on July 01, 2015, 08:28:59 pm
Recently purchased a DSA815-TG. UPS claims it will arrive tomorrow.
Just wondering if anyone has put any effort into enabling the options on the newer units with the updated bootloader. I'd really like to know if Rigol updated the public/private keys and/or did they change the option codes themselves.
I can probably do a jtag dump at some point if that is what is needed.

Also can anyone confirm if the hardware has been updated in the newer production units, I have read mention of a lower noise floor.


PS to Rigol - I bought the DSA815-TG because I am pleased with my DS1054Z that is now fully optioned out. If you remove the ability to enable features on all products people like myself will buy from another company. :)

Get ready to buy from another company. The only current hack for the DSA815 involves opening the device up and bridging the write protect pin on the FRAM chip to Vdd, pulling it high. This seems to persist the trial options indefinitely. No 10hz RBW though.

I am holding out on opening up my unit, hoping someone finds a soft-hack. I still have option time left and turn the DSA off when not on use. If I get low on option time, I will reconsider.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: TheSteve on July 01, 2015, 09:47:19 pm
Recently purchased a DSA815-TG. UPS claims it will arrive tomorrow.
Just wondering if anyone has put any effort into enabling the options on the newer units with the updated bootloader. I'd really like to know if Rigol updated the public/private keys and/or did they change the option codes themselves.
I can probably do a jtag dump at some point if that is what is needed.

Also can anyone confirm if the hardware has been updated in the newer production units, I have read mention of a lower noise floor.


PS to Rigol - I bought the DSA815-TG because I am pleased with my DS1054Z that is now fully optioned out. If you remove the ability to enable features on all products people like myself will buy from another company. :)

Get ready to buy from another company. The only current hack for the DSA815 involves opening the device up and bridging the write protect pin on the FRAM chip to Vdd, pulling it high. This seems to persist the trial options indefinitely. No 10hz RBW though.

I am holding out on opening up my unit, hoping someone finds a soft-hack. I still have option time left and turn the DSA off when not on use. If I get low on option time, I will reconsider.

Considering I am willing to open it to JTAG it I have no problem shorting pins 7 and 8 of the FRAM for now - I'll verify it works first!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ademuth93 on July 02, 2015, 03:45:22 am
Hello all,

Sorry if this is the wrong place - first time forum user just looking for some help.
I've been attempting to unlock the options on my DS2072A (SW version 3.01, HW 2.0) using the RigolBildschirmkopie program to dump 32MB of the scope's memory. The only problem is that when I use the command ":SYST:UTIL:READ? 1,33554432" I get an "Out of Bounds" exception. I'm able to send commands that return smaller amounts of data to the computer (getting the system time on the scope works, for example). I can run the read command up to about 100 kB and not much more.

Is this a bug in the program, or is it some kind of id-10t error on my end? I noticed the most recent build was on June 29, so it could perhaps be a new bug. Does someone have an older version of this program I could try, or any other suggestions?

Thanks for your help!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ademuth93 on July 02, 2015, 02:08:42 pm
Please send me an e-mail or use the contact form on my website. Describe what operating system you use and the type of connection LAN or USB.
Screen capture of the error message would also be good.

Peter

Peter,
I've sent an email to you with the information you requested as well as some screenshots.

"For those playing along at home," I've tried this on windows 7, windows 8.1, and Mac OS 10.10 using a LAN connection.

UPDATE:
Peter was kind enough to update his program to fix the error I was getting. It now works as intended! Thanks!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: TheSteve on July 04, 2015, 05:10:56 pm
I am wondering if someone out there would be willing to make a custom version of riglol.c for some DSA815 testing.
When Rigol changed the firmware which broke riglol they either changed the public/private keys, changed the option codes, or both. On the long shot chance they only changed the option codes(which is what they did with the DP832) I'd like to try to "brute force" some keys that match my DSA815. I'd like riglol.c modified to loop through option codes AAAA to 9999(including mixed alpha and numeric) automatically and output all of the possible result keys to a file.  The results could then be compared to the existing options keys which can be viewed on the screen of a DSA815-TG. For a specific serial number we could see if a match was obtained for the tracking generator and the three trial options.
If any match is obtained we know the keys have not changed and will also have enough information to then generate permanent codes for every option but the 10 Hz RBW. We can then likely determine the 10 Hz RBW option(if it still exists) with some trial and and error as well. All of this without evening opening a DSA815 up.

I did some C programming 20 years ago, it would take a lot of time to get back up to speed to start making changes, so if someone would be willing to give it a go it could really benefit a lot of people.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Asmyldof on July 11, 2015, 09:27:55 pm
Hey Guys,

I'm wondering, has anyone tried any evil tricks on a DG5 series Rigol toy? Bought a very discounted DG5072 (70MHz limit) and it does all I need in my freelance work for the next 12 to 24 months, which is good. But I wonder whether I'm right in suspecting its output bandwidth is limited in hardware as well, looking at the "square wave" at 70MHz on a 500MHz scope. Might be they are just playing tricks on me in FW of course, but it doesn't really look like it.

If anyone knows of any tricks that could be tried or need verification, I'm happy to play along up to a certain degree of risk (the replacement will cost full price). If not I may at some time next year just start poking around in it myself, see if I can find a JTAG header.

Hugs and cuddles :-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: SmokenJoe on July 20, 2015, 04:24:01 am
I just received my DS2072A 2 days ago. I wanted to do a memory dump so I purchased an Olimex ARM-USB-OCD-H and hooked it up to the JTAG port using instructions from this thread. I downloaded blackfin toolchain and installed it. I am running Ubuntu 15. When I run bfin-gdbproxy I always get the following error.


Code: [Select]
./bfin-gdbproxy

Remote proxy for GDB, v0.7.2, Copyright (C) 1999 Quality Quorum Inc.
MSP430 adaption Copyright (C) 2002 Chris Liechti and Steve Underwood
Blackfin adaption Copyright (C) 2008 Analog Devices, Inc.

GDBproxy comes with ABSOLUTELY NO WARRANTY; for details
use `--warranty' option. This is Open Source software. You are
welcome to redistribute it under certain conditions. Use the
'--copying' option for details.

Found USB cable: ARM-USB-OCD-H
Connected to libftdi driver.
warning: TDO seems to be stuck at 1
error:     bfin: detecting parts failed
Found USB cable: ARM-USB-OCD-H
error: Couldn't connect to suitable USB device.
error:     bfin: cable initialization failed

I have double checked all the connections. Can anyone help me with this.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gandalf_Sr on July 22, 2015, 02:40:27 pm
I don't know if it still works but have you tried the SCPI system that's mentioned in this thread https://www.eevblog.com/forum/testgear/rigol-mso2000-series-hacking/msg657936/#msg657936 (https://www.eevblog.com/forum/testgear/rigol-mso2000-series-hacking/msg657936/#msg657936) It's only 17 pages to read.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: chbrules on July 24, 2015, 08:28:14 am
I've been trying to do some research, and it appears you can still hack the Rigol DS2072A no problem? Questions:

1) Is any special hardware required? I saw a .pdf guide (http://gotroot.ca/rigol/D2072A%20Unlocking%20Guide.pdf (http://gotroot.ca/rigol/D2072A%20Unlocking%20Guide.pdf)) on gotroot.ca that says you can just hook it to your PC via USB and run some apps to get the private key with modified firmware.

2) Can you still use this modified firmware to do the hack? Or is there an updated version?

3) If that guide isn't accurate anymore, is there a new guide?

Anything else I should know? I'm new to this. Thanks!  :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PE1DHI on July 26, 2015, 10:56:51 pm
Hello Rigol stars!  :-+

I'am the owner from a brand new DSA832-TG and wonderd if someone can tell or has already hacked it or set free the options?

DSA832-TG
DSA8F1701xxxxx
Firmware 00.01.00

I read this long thread with pleasure, go on!  :)
With regards, Jugo

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Crille77 on July 30, 2015, 07:13:26 pm
Yeeehaaaa! I now have hacked my MSO1104Z-S with full options using USBBlaster.
(http://i60.tinypic.com/v7vc44.jpg)

USBBlaster can be used BUT it is slow as a old modem for the PC!!!! I'm not kidding... But it works! ;-)
When I dumped my memory, I made copies of my dumpfile during the dump and tested rigup to see if it could find any kees in it. When I found keys, I aborted the dump. It took a awful lot of time but now I'm a happy owner of a fully unlocked scope.

I just wanted to share some pinouts and findings to all you out there to make it easier for you if you also will use the USB blaster...
And a HUGE thank you to all the people that made all of this work! You are awesome!

Pinout:
(http://i59.tinypic.com/2ro3jbn.jpg)
Connect 2 & 10 from the JTAG and both GND from the scope to the breadboard so they are connected!

When you have connected the scope with the JTag and connected the powersupply again, be careful not to damage the cables and close the two parts together as tight as possible to make shure the cooling works. This is how it looked for me:
(http://i61.tinypic.com/2418a4w.jpg)

Use a breadboard and connect all GND connections together! (here is a picture of my scope open with the JTAG and breadboard connected.
(http://i60.tinypic.com/xnwzmr.jpg)

One other thing that needs to be done if you are using Linux as rmd79 wrote in a previous post, is to modify the Makefile for the patched rigup tool.
Change the following line from:
Quote
LDFLAGS                 := -O2 -Wl,-dead_strip
To:
Quote
LDFLAGS                 := -O2 -Wl,--gc-sections -s

Again... A HUGE thank you to all that made this possible!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: McBryce on July 30, 2015, 08:10:55 pm
Nice pics.

If you had used the "speed 6000" command (increases connection speed to 6Mhz) before doing the savebin it would have sped the process up considerably. The entire dump takes about 7 or 8 minutes at 6Mhz.

McBryce.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Crille77 on July 30, 2015, 08:22:56 pm
Nice pics.

If you had used the "speed 6000" command (increases connection speed to 6Mhz) before doing the savebin it would have sped the process up considerably. The entire dump takes about 7 or 8 minutes at 6Mhz.

McBryce.
Thanks!

I used openocd and that doesn't recognize speed for the USBBlaster... I tried every command related to speed without any luck... Maybe it would work with the "genuine" USBBlaster and not the cheep ebay version that I got.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: McBryce on July 30, 2015, 08:30:24 pm
Not sure about that. I used a Segger with the J-Link software.

McBryce.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Fluxx1122 on September 19, 2015, 04:38:54 pm
Hey Guys,

nice work ;)

since I saw Crille77s post, I remembered I got a genuine USB-Blaster myself. I thought I would give it a try myself and unlock my MSO1104z.
So far, unfortunately, it hasn't worked ;(
First I tried Win7 (vm) and openocd in different configs, reinstalled usbblaster driver and ftdi multiple times.
PID/VID are default (checked), still openocd reports
Code: [Select]
Error: unable to open ftdi device: usb_open() failed in procedure 'init'
So far so good, thought maybe it is about the Windows being a VM, so I tried Linux Ubuntu 14.04.
On Linux I can get access to the JTAG and openocd 0.7.0 recognizes the usbblaster.
Code: [Select]
openocd -d2 -f interface/altera-usb-blaster.cfg -f target/imx28.cfg
Open On-Chip Debugger 0.7.0 (2013-10-22-08:31)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
debug_level: 2
Warn : Adapter driver 'usb_blaster' did not declare which transports it allows; assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
dcc downloads are enabled
Which looks good so far, but a few seconds after it outputs;
Code: [Select]
Info : This adapter doesn't support configurable speed
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: imx28.cpu: IR capture error; saw 0x0f not 0x01
Warn : Bypassing JTAG setup events due to errors
Info : Embedded ICE version 15
Error: unknown EmbeddedICE version (comms ctrl: 0xffffffff)
Info : imx28.cpu: hardware has 2 breakpoint/watchpoint units
Warn : WARNING: unknown debug reason: 0xf
Warn : ThumbEE -- incomplete support

Anyone any idea how to solve it?
Since it reports "all ones", I figuered that there may be pullups/pulldowns required, but in the post it did't look like it?

Regards
Fluxx1122
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Fluxx1122 on September 20, 2015, 05:28:29 am
Ok, I got it!
using the newer ocd seems to fix it.

Now unlocked with all options ;)

But Crille77 got it right, it's got glacial speed, took about 10h for the 34MB needed to get the keys.

Thanks to all contributers who made this possible ;)

Regards
Fluxx1122
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: uski on September 20, 2015, 01:02:30 pm
I'am the owner from a brand new DSA832-TG and wonderd if someone can tell or has already hacked it or set free the options?

DSA832-TG
DSA8F1701xxxxx
Firmware 00.01.00

As far as I know the newest DSA815 are not hacked yet. I didn't read anything about the DSA832. Maybe you can dump its memory and post it, it may help (but it may expose your S/N depending on what part of the memory you are dumping)

I might buy a DSA832 if it becomes hacked -  otherwise it's just too expensive with no options.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on September 20, 2015, 07:45:54 pm
I'm still looking for dumps of a hacked 815 running the latest firware so I can compare to a unhacked 815 and would love a dump of a 832 if someone is willing to provide one.    I'm not the best at this but been trying.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Asmyldof on September 21, 2015, 04:31:28 pm
@smgvbest : Not exactly your request, but would a dump of another unhacked "new" DSA815-TG help?

Been too busy still to actually open it up (and read all of the first pages to get "a hang"), but willing to let it jump the queue if it helps you at all.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: longview on September 23, 2015, 09:02:42 pm
I did an FRAM dump on my DSA815 (latest hardware, unhacked) using SCPI :SYST:FRE? 3145728,1048576 (the lower 3 MB seemed generally uninteresting).
My hope was to see if the FWrite command could be used to reset the license status of the trials, but I can't see any of the data changing even between reboots so that's probably a non starter.

There was a string repeated two times in the dump in the form of SECRET<14 digit key>.
I tried searching for it in the thread but doesn't look like it's been posted before or anywhere online. It's certainly the right length to be a public key, and rigup 0.2 spits out a private key when I feed that into it (not the one used on previous FWs), but the license keys don't work (not entirely unexpected).

Being way out of my depth here, I can't say what this is, could be a red herring or a joke left for us by the developers. Any thoughts?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Asmyldof on September 24, 2015, 08:02:32 am
In my experience with the kind of design or development Rigol uses, I don't think it's a red herring or a joke. I've run across companies with similar tactics and the more general thing to do is change request codes, public keys and their location. So you may well have found half the puzzle, now only need to find the new request codes to apply?

Anyway, I have only used the DSA815-TG I have for a few hours to test it, as the project I needed it for got cancelled/postponed (still not clear on which), I could do an FRAM dump this weekend to compare, see if you can divine some meaning from differences. I might be willing to make some time to read up on the relevant threads and join in, but that depends a bit on the result of a customer visit today.

I'm even willing to work through Git for anything that can be "scrubbed" of my device's ID and just have it all out on Github in some account or another, let other people follow the steps and results.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: longview on September 24, 2015, 03:22:18 pm
Yeah, it would be silly not to pursue the secret. They have probably changed the request codes too, if they've changed the way the cipher is implemented then it becomes more difficult.

Some other possible avenues:
It seems to be possible to write ASCII text to arbitrary FRAM locations using SCPI commands, but probably not binary values. The license key storage is duplicated in the FRAM, possibly for fault finding or anti-tamper, but depending on how often the checking is done it might be possible to overwrite both stores over SCPI.

Assuming the key turns out to be difficult to crack, we know the firmware will keep options already installed using old keys, it could be possible to overwrite the key stores with license information generated from old option keys.
Resetting the countdown timer could potentially be quite simple if I can work out where that information is stored in the FRAM.

I think the easiest way to work out new option codes is by brute force, the keyspace isn't massive (less than 2 million combinations) and if we can work out the option codes for the trial keys already installed then the full versions should be pretty close (usually at least).
Only issue with that is I don't know how to convert the keys I can read on the screen or see in the FRAM into the format used to activate the option.

E: some more information, could be useful:
Installing and reading installed license keys can be done with these commands:
:SYSTem:LKEY? <int between 1-5, 3 is probably 10 Hz RBW and returns nothing for me)
My system has two keys installed for EMI and AMK, for those numbers the return is two keys with a 0x0A between

:SYSTem:LKEY <key with no spaces> seems to install keys, returns nothing but shows a message on screen if it's wrong

The keys seem to be stored in order of entry in the FRAM, presumably the license type is contained in the key or in one of the bytes before or after they key in RAM.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Asmyldof on September 24, 2015, 09:37:57 pm
Well, it is absolutely certain that the keys are of the same format, we know that, we also know that the options are kept between upgrades, so that seriously limits the changes they could have made.

90/10 likelihood they only changed the parameters to the key system and not the actual key system itself.

I did see a topic chain a while ago about someone making a PIC add-on (I think it was PIC) on the I2C to the FRAM that kept resetting the time-out on the trial options, as an alternative to making the entire FRAM write protected. I'm thinking of applying that until I manage to re-hack the new HW/FW/FlashLoader.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: TheSteve on September 24, 2015, 09:53:52 pm
Don't forget the potential option of finding a way to install the older firmware just long enough to enable the features and then upgrading to current firmware.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Asmyldof on September 24, 2015, 09:55:46 pm
I have a feeling reverting the flashery-upery-datery thing is either more tiresome, or more risky than finding the new hack.

But I may be wrong. Not vested deep enough in the detailed matter of hacking Rigols yet. Once I am, I'm going to look into the DG series as well.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Howardlong on September 24, 2015, 10:06:50 pm
Well, it is absolutely certain that the keys are of the same format, we know that, we also know that the options are kept between upgrades, so that seriously limits the changes they could have made.

90/10 likelihood they only changed the parameters to the key system and not the actual key system itself.

I did see a topic chain a while ago about someone making a PIC add-on (I think it was PIC) on the I2C to the FRAM that kept resetting the time-out on the trial options, as an alternative to making the entire FRAM write protected. I'm thinking of applying that until I manage to re-hack the new HW/FW/FlashLoader.

If that's for the 815, that was a feature I put forward here (as was the pins 7&8 trick). The PIC mod only reset the FRAM "clock" (not the RTCC), but allowed other updates to happen like static LAN config that was disabled by simple shorting of 7&8.

I have the complete FRAM dump somewhere if you need it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Asmyldof on September 24, 2015, 10:08:53 pm
Ah yes, the name rings bells :-)

I'm not very PICcy, so I hadn't checked it yet. Working on the Freelance assignment from hell right now, so it feels like I'm constantly out of time. But one way or another that's about to change soon.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Howardlong on September 24, 2015, 10:17:21 pm
Ah yes, the name rings bells :-)

I'm not very PICcy, so I hadn't checked it yet. Working on the Freelance assignment from hell right now, so it feels like I'm constantly out of time. But one way or another that's about to change soon.

There was someone else who did a similar thing early on on the 2000 series scopes based on another device, an AVR perhaps, I can't remember, but like many of us, we feel at home in our own comfort zones, and PIC has been mine for a very long time, with occasional dalliances elsewhere as necessary. The PIC solution I am sure is one of very many that could be used.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Asmyldof on September 24, 2015, 10:23:01 pm
Oh I'm happy using the PIC as well. Just too rusty to just download and get going with what little tools I have for them.

I do like the AVR better. Fits my personal taste better, but I'm not without TI/Freescale/NXP experience either. Or 68000/ix86/8080 for that matter.


Worst case I can always improvise a simple PIC programmer with an AVR :-P
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on September 25, 2015, 12:17:21 am
If that's for the 815, that was a feature I put forward here (as was the pins 7&8 trick). The PIC mod only reset the FRAM "clock" (not the RTCC), but allowed other updates to happen like static LAN config that was disabled by simple shorting of 7&8.

I have the complete FRAM dump somewhere if you need it.

@Howardlong,   could I get a copy of that FRAM dump? please?????
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Howardlong on September 25, 2015, 09:57:29 pm
If that's for the 815, that was a feature I put forward here (as was the pins 7&8 trick). The PIC mod only reset the FRAM "clock" (not the RTCC), but allowed other updates to happen like static LAN config that was disabled by simple shorting of 7&8.

I have the complete FRAM dump somewhere if you need it.

@Howardlong,   could I get a copy of that FRAM dump? please?????

PM'd.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on September 25, 2015, 10:12:01 pm
If that's for the 815, that was a feature I put forward here (as was the pins 7&8 trick). The PIC mod only reset the FRAM "clock" (not the RTCC), but allowed other updates to happen like static LAN config that was disabled by simple shorting of 7&8.

I have the complete FRAM dump somewhere if you need it.

@Howardlong,   could I get a copy of that FRAM dump? please?????

PM'd.

Got it
Thank you
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Jonson.poisk on September 26, 2015, 01:34:47 pm
Hello dear!
You could help me?
Are there any have this firmware unlocking methods other than soldering pins FRAM?
Analyzer DSA815-TG

Firmware 00.01.09
Boot 00.01.04
Mainboard 00.07
Radio board 00.05
FPGA 00.04

Thank you
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on September 26, 2015, 11:13:38 pm
Hello dear!
You could help me?
Are there any have this firmware unlocking methods other than soldering pins FRAM?
Analyzer DSA815-TG

Firmware 00.01.09
Boot 00.01.04
Mainboard 00.07
Radio board 00.05
FPGA 00.04

Thank you

Currently the U1105 hack is the only way to keep you're features enabled on the DSA815
I'm trying to figure it out but am new to this so my approach is to educate myself but I am missing one thing
I'm looking for a memory dump of a DSA815 with the boot 1.03 when it it was possible.   I want to trace exactly what rigup did to find the private key then see if I can duplicate with boot 1.04 but so far no one has offered up a dump with boot 1.03 so nothing is is happening for now.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MiataMuc on September 27, 2015, 02:22:45 pm
Hi
I have a DSA 815, Bootloader 00.01.03, Firmware 00.01.12, all options enabled..
I'd be willing to help you. Do I have to read the flash by network or by an adapter?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: longview on September 27, 2015, 04:19:08 pm
FRAM can be read out over USB/Network, at least part of it.

I use Rigol Bildschirmkopie to send commands, mostly for convenience:
:SYST:FRE? 0,1048576
:SYST:FRE? 1048576,1048576
:SYST:FRE? 2097152,1048576
:SYST:FRE? 3145728,1048576

I've got an Atmel ICE coming soon, can I use the JTAG in that to do an SDRAM dump?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Jonson.poisk on September 27, 2015, 05:44:04 pm
Well, that have proposed the post above  ;D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on September 27, 2015, 07:31:33 pm
FRAM can be read out over USB/Network, at least part of it.

I use Rigol Bildschirmkopie to send commands, mostly for convenience:
:SYST:FRE? 0,1048576
:SYST:FRE? 1048576,1048576
:SYST:FRE? 2097152,1048576
:SYST:FRE? 3145728,1048576

I've got an Atmel ICE coming soon, can I use the JTAG in that to do an SDRAM dump?

FTI

Tha'ts a SDRAM dump not a fram dump.    the first 8M of memory in the Blackfin is from 0000 0000 - 007F FFFF and only 4M is used.  the 2nd 4M is a copy of the first 4.

FRAM is not memory mapped into the address space of blackfin from what I can tell.  the FRAM is a I2C device and would have to be read out directly    Howardlong can correct me if I'm wrong

If someone can get me the first 4Mb of SDRAM using this commands who has a boot 1.03 It would help allot.
:SYST:FRE? 0,1048576
:SYST:FRE? 1048576,1048576
:SYST:FRE? 2097152,1048576
:SYST:FRE? 3145728,1048576

you can save each memory block then combine them at either a dos prompt or linux commandline and let me know how to get it
right now I've dumped 1.14 with boot 1.04 and looking at it I see nothing that look like the same eye catchers
rigup used this
      0      02 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>

for the MSO1000Z the only change was offset zero for the eye catcher
      0      01 00 84 00 10 00
then a change to how things are encrypted.

I see nothing like that in the dump I have so they could have simple bit shifted things to scramble them for example.
That's why I want to see a dump of boot 1.03 SDRAM


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MiataMuc on September 28, 2015, 07:00:47 pm
pm
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on September 29, 2015, 12:48:46 am
pm

Thank you.   this confirms to me that the keys for the DSA815 where found in another manner.  the eye catchers are not there in your dump or mine with V1.14 and boot 1.04 which means to me they where found in another way
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on September 29, 2015, 08:42:18 am
pm

Thank you.   this confirms to me that the keys for the DSA815 where found in another manner.  the eye catchers are not there in your dump or mine with V1.14 and boot 1.04 which means to me they where found in another way
On the DS2000 the change came when a new hardware revision was introduced. With new hardware on the DS2000A RIGOL also introduced customized encryption parameters for each unit. Perhaps they did the same on the DS815. I don't think the boot code plays a role here, apart from the fact that you cannot downgrade.

Have you tried scanning the dumps for license keys with 'rigup search [KEYFILE] DUMPFILE'

BTW on a DS2000A you need at least 32Meg to get results
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on September 30, 2015, 01:07:44 am
pm

Thank you.   this confirms to me that the keys for the DSA815 where found in another manner.  the eye catchers are not there in your dump or mine with V1.14 and boot 1.04 which means to me they where found in another way
On the DS2000 the change came when a new hardware revision was introduced. With new hardware on the DS2000A RIGOL also introduced customized encryption parameters for each unit. Perhaps they did the same on the DS815. I don't think the boot code plays a role here, apart from the fact that you cannot downgrade.

Have you tried scanning the dumps for license keys with 'rigup search [KEYFILE] DUMPFILE'

BTW on a DS2000A you need at least 32Meg to get results

Yes I did,  I also tried a 8MB dump on mine and neither found anything.   I also tried dumping over SCPI the first 32Meg and it could not find anything either

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on September 30, 2015, 08:34:39 am
pm

Thank you.   this confirms to me that the keys for the DSA815 where found in another manner.  the eye catchers are not there in your dump or mine with V1.14 and boot 1.04 which means to me they where found in another way
On the DS2000 the change came when a new hardware revision was introduced. With new hardware on the DS2000A RIGOL also introduced customized encryption parameters for each unit. Perhaps they did the same on the DS815. I don't think the boot code plays a role here, apart from the fact that you cannot downgrade.

Have you tried scanning the dumps for license keys with 'rigup search [KEYFILE] DUMPFILE'

BTW on a DS2000A you need at least 32Meg to get results

Yes I did,  I also tried a 8MB dump on mine and neither found anything.   I also tried dumping over SCPI the first 32Meg and it could not find anything either
I scanned my DSA815 via dumping over SCPI, it is an early one.

Boot is 01.02
Version of main board is 00.04
Firmware is 1.09
 
I found 5 license keys in the lower part of the flash memory, basically the four I put in myself, and there was already one present, probably for the tracking gen.

Also i tried to find the known private key in the flash (32 meg) and did not find it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on September 30, 2015, 10:40:46 am
Yes,  Looking at a pre boot 1.04 I was able to find the same in even a 4Meg dump but in mine at 1.04 a search turned up nothing at all.
The eye catcher bytes seem to typically be there but not on the DSA's.  I manually went through the 32Meg dump and saw nothing that looked familiar
I do have one throught and maybe something that's been tried before but I was thinking if I went into the licensing screen and entered even a bad key it would maybe have a deciphered bit strings in memory at that point so I'm going to try that out next
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on October 10, 2015, 11:30:08 pm
if u are after the bootloader for the DSA than i would assume that it is located at 0x2000 0000 in the Flash as a LDR stream. (thats how the DS2x does it)
0x2000 0004 contains the length of the LDR stream for the bootloader

try to dump that and use a tool like ldrviewer to see if it actually contains a LDR stream if so - i have a nice LDR loader for ida pro that i can share.
usually the bootldr (again DS2x knowledge) then loads yet another LDR which is the actual APP image.
dumping from 0x0 onwards is RAM - which gets overwritten by the bootloader with the APP image, so i doubt u get that data out with SCPI.

best to use gdb, and break the boot process before the APP image gets executed.

from my old notes

Code: [Select]
BootMode (BMODE) is 0001b

The kernel boots from address 0x20000000 in asynchronous memory bank 0.
The first byte of the boot stream contains further instructions whether the memory is eight or 16 bits wide.
BootLoader takes care of:

bfin init (EBIU, PLL, PORTS, DMA, SPORT)
fpga init
lcd init and displaying ultravision & rigol logo
load the application image LDR from flash @0x20040000+0x4 (first 4 bytes contain length of LDR stream)
optionally firmware upgrade via DS2000Update.GEL
run bfin executable from RigolDsExe.ldr (you need to disable any interrupts quickly or it will crash)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Macbeth on October 11, 2015, 06:50:53 pm
try to dump that and use a tool like ldrviewer to see if it actually contains a LDR stream if so - i have a nice LDR loader for ida pro that i can share.

Hi cybernet,

Please share... anything about Rigol and Blackfin. I'm quickly learning about it as I just bricked my DM3058E doing a firmware downgrade using the Rigol method of a supplied file on a USB stick plugged into it. I've flashed these firmwares before and not had a problem, but this time Murphy got me :(

I've been reading up on the ADSP-BF531 documentation and the Rigol binary file appears to follow the LDR format, just prefixed with a null terminated RIGOL firmware ID string. An example is the previous DM3058 firmware available here (https://www.dropbox.com/s/5imyz0pn22jyrxl/DM3058(DSP)UPDATE.rar?dl=0).

I've got the 90 day trial of VisualDSP running and tried that LDRViewer application, but it doesn't seem to like the Rigol files even when I strip the header firmware string out and start on the 4 byte address, 4 byte count, and 2 byte flag immediately after it. But following the headers and blocks manually in a hex editor it seems ok.

Now, I have to re-flash using the JTAG port. I'm guessing the supplied rigol firmware minus the id string is probably ok. I only have an Altera USB blaster so had a look at the official tools and nearly had a heart attack at the prices  :-DD - is it possible to flash with the USB blaster? I also noticed an Olimex ARM-USB-OCD tool that looks reasonably priced and supports debugging so would be worthwhile for me to have a go at reversing this thing and fixing bugs that Rigol are so slow to...

I've also got an, ahem, evaluation version of IDA Pro 6.6+SDK and found a Blackfin module but haven't had much luck getting it to work, it seems to be for an earlier version :(

Anyway, any help much appreciated ;)

Sorry to move off track from the DSA guys, but there is a lot of info here relevant to my DMM. Why do Rigol love the Blackfin DSP so much? It seems like total overkill for a simple DMM  :-// Though I guess if they paid for all the licensed tools for their scopes and stuff... and their devs are used to it... maybe it makes sense?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Asmyldof on October 17, 2015, 10:46:49 pm
Hey Guys and Gals,

I want to aware-nize you all of this post I made in chat:
New Bootloaders for DG5 and DP800 (https://www.eevblog.com/forum/chat/rigol-dg5-dp800-and-possibly-others-to-get-new-bootloader-again/)

Also, @smgvbest, once I have time again from the freelance assignment from hell (should be soon), as I am interested in hacking the DS815 myself as well, I could look into the rigup code, possibly confer about what I see and how that fits the "old dump" you have and how that might be adapted to the new one.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on October 18, 2015, 10:35:08 pm
Thank you cybernet
I need to get a header on my JTAG port as I looks like mine was no populated then I will try that
I'm sure others have noticed but the newer keys seem to be mixed case vs. uppercase.
not sure what that implies though.

if u are after the bootloader for the DSA than i would assume that it is located at 0x2000 0000 in the Flash as a LDR stream. (thats how the DS2x does it)
0x2000 0004 contains the length of the LDR stream for the bootloader

try to dump that and use a tool like ldrviewer to see if it actually contains a LDR stream if so - i have a nice LDR loader for ida pro that i can share.
usually the bootldr (again DS2x knowledge) then loads yet another LDR which is the actual APP image.
dumping from 0x0 onwards is RAM - which gets overwritten by the bootloader with the APP image, so i doubt u get that data out with SCPI.

best to use gdb, and break the boot process before the APP image gets executed.

from my old notes

Code: [Select]
BootMode (BMODE) is 0001b

The kernel boots from address 0x20000000 in asynchronous memory bank 0.
The first byte of the boot stream contains further instructions whether the memory is eight or 16 bits wide.
BootLoader takes care of:

bfin init (EBIU, PLL, PORTS, DMA, SPORT)
fpga init
lcd init and displaying ultravision & rigol logo
load the application image LDR from flash @0x20040000+0x4 (first 4 bytes contain length of LDR stream)
optionally firmware upgrade via DS2000Update.GEL
run bfin executable from RigolDsExe.ldr (you need to disable any interrupts quickly or it will crash)
Title: private key for rigol ds4000
Post by: JHERCULEES1 on October 21, 2015, 09:42:59 pm
DS4000 series Bandwidth (model type) Option Codes.

For those who have an interest in the DS4000, I have found the option codes for selecting the bandwidth .
This also sets the model type.

For example the code FAB9 will select 500Mhz, (DS405x), with all Decoders enabled.

The attached file contains all the details.

There are also two un-documented, possibly future, options called "Power Analysis" and "MA".

The option codes have been tested with firmware ver 00.02.00.00.04 and ver 00.02.01.00.03.

here he mentions unlocking the options in the rigol 4000 series but no mention of the private key that is needed for the tool to work ?

does anyone know what posts talk about the private key for the 4000 series , i located the private keys for both the 1000 and 2000 series but no 4000  private key
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Macbeth on October 21, 2015, 10:14:26 pm
Re: Dead Rigol DM3058. Thanks to a lot of pointers in this thread I've managed to fix my DMMs corrupt flash.  :-+ Rigol wanted me to send it to them for some weird reason. Other manufacturers like Keithley have not had issue sending me raw chip level firmware files so I can hardware flash my own, but Rigol wouldn't. Sorry, but I prefer to DIY.

Oh. Windows 10 appears to be rubbish with this sort of stuff. BSOD's constantly since trying to get drivers to work with Olimex and Altera Blaster. The absurd driver protection scheme rules out most FTDI based devices. Linux is a far more sensible environment. Dual Boot FTW (with the grub loader remembering what OS I last booted)  :-+
Title: Re: private key for rigol ds4000
Post by: MarkF on October 21, 2015, 11:56:38 pm
here he mentions unlocking the options in the rigol 4000 series but no mention of the private key that is needed for the tool to work ?

does anyone know what posts talk about the private key for the 4000 series , i located the private keys for both the 1000 and 2000 series but no 4000  private key

I have a DS1000Z series scope.  However, if the DS4000 series is the same, the Riglol key generator will fill in the private key after you enter your serial number..
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: nbritton on October 22, 2015, 09:03:32 pm
What is the DS4064? I did a strings dump on the firmware update and that was in there.

Code: [Select]
$ strings DS4000Update.GEL | grep DS406
DS4064

Given Rigol's model naming system that would imply a 600 MHz DS4000 exists.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: wyx on October 31, 2015, 04:20:31 pm
Hi, I am a EE student in US. I recently purchased a MSO2072scope and I follow the hack instruction using ubuntu to unlock my scope feature. However, there's always some error message while compiling the code from github. Can anyone help me with that? My scope is running software 03.01 and hardware 2.2 is it able to be upgraded using that hack??
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: nbritton on November 01, 2015, 06:48:41 pm
Hi, I am a EE student in US. I recently purchased a MSO2072scope and I follow the hack instruction using ubuntu to unlock my scope feature. However, there's always some error message while compiling the code from github. Can anyone help me with that? My scope is running software 03.01 and hardware 2.2 is it able to be upgraded using that hack??

What is the error message? What version of Ubuntu are you using, I would recommend the 14.04 LTS release.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Macbeth on November 01, 2015, 10:41:30 pm
Just remember with Ubuntu you often have to use sudo to do stuff. Like when compiling something you need to do sudo make install rather than make install.

I know obvious, but I wasted a whole day when I didn't realise that just accessing serial ports or USB also requires root privilege!  :palm:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: farzadb82 on November 02, 2015, 01:38:46 am
Just remember with Ubuntu you often have to use sudo to do stuff. Like when compiling something you need to do sudo make install rather than make install.

I know obvious, but I wasted a whole day when I didn't realise that just accessing serial ports or USB also requires root privilege!  :palm:

It sounds like you need to create a udev rule for your device. You should really avoid running things as sudo when possible. The only time you'd absolutely have to is when you're installing something into the system. Other than that, you shouldn't have to run commands using sudo.

Here's a good reference for creating udev rules (http://ubuntuforums.org/showthread.php?t=168221 (http://ubuntuforums.org/showthread.php?t=168221)). It talks specifically about creating rules for external media, but the same concepts can be applied to any usb device.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Macbeth on November 02, 2015, 05:31:05 am
Just remember with Ubuntu you often have to use sudo to do stuff. Like when compiling something you need to do sudo make install rather than make install.

I know obvious, but I wasted a whole day when I didn't realise that just accessing serial ports or USB also requires root privilege!  :palm:

It sounds like you need to create a udev rule for your device. You should really avoid running things as sudo when possible. The only time you'd absolutely have to is when you're installing something into the system. Other than that, you shouldn't have to run commands using sudo.

Here's a good reference for creating udev rules (http://ubuntuforums.org/showthread.php?t=168221 (http://ubuntuforums.org/showthread.php?t=168221)). It talks specifically about creating rules for external media, but the same concepts can be applied to any usb device.
Yes, that is exactly what I ended up doing. Thanks for reminding me!

I also had to add my account to the dialout group to allow me to use /dev/ttyUSBx

Oh, one thing that bugs me. I've installed the blackfin toolchain and whenever I am using UrJTAG (bfin-jtag) I've found the cursor keys seem to be mapped to something strange and so I just get things like "[]]]" output when I press a key. It makes recalling command history a PITA. I've also tried UrJTAG from the official repo using apt-get-install and with that version the command history and editing using cursor keys works as expected.  :-//
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: whotopia on November 03, 2015, 02:06:55 pm
Can someone advise if it is possible to restore the serial number of a DS2072A ?
I tried to do some of the hacks in the past and this lead me to a unit with serial number DS2A0000000001.  The MAC address on the LAN interface is also wrong.  It's 46:46:46:46:46:46.  I assume the MAC must be uniquely generated from the serial number somehow.
The device is currently at firmware DS2000(DSP)Update_00.03.04.01.00
What can I do?

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on November 03, 2015, 02:20:43 pm
RE: DSA815 Hack
Still working on the traditional way of do this but I had a thought and wanted to see if anyone thought this was remotely possible.
We know prior to boot loader 1.04 that the rigup could create codes that worked and those where stored in memory on the DSA815.
After updating to boot loader you could not enter new codes but those with existing codes still work.

So maybe a little backwards thinking but.  What if we generated licenses for boot 1.03 and wrote them directly to memory then rebooted (may not be needed) the unit.  this would need of course to know where the licenses are stored in memory.  we know a SDRAM dump isn't what's needed and they don't appear to be stored in the FRAM chip either.   So the question is where are the licenses stored?

I know it's far fetched but is there any merit in it the thought?
Just thought I would through this out there. 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on November 03, 2015, 09:54:27 pm
I am one of the people looking at redoing the keygen but I am far out of my comfort zone in doing so. I had the thought that I posted and was looking for feedback on that question, not clarification on where the issue is boot loader or firmware.   I only state that as it is often the pointed question of which boot loader do you have not which FW version do you have when find out if the user can use the keygen.

My question was around an alternative method of doing this.  If it was possible then it gives us a way to get keys installed and isn't that the point.  The method doesn't mater as long as it works.   

So my question is still does anyone think that might be a viable way around the issue or is it a waste of time to pursue?

It is NOT the BootLoader that is preventing the Riglol Keygen results from working, it is the Firmware (FW). You need to go back to a previous FW such as 00.01.06, but the BootLoader is preventing you from going back to the earlier FW.

It is possible that someone could come up with a Riglol Keygen that would work with the newer version of FW, but it seems that no one has been able to do it.

So those with the newer DSA815 FW should at least for now solder pins 7 and 8 together on U1105 while the Trial Options are still current.   If you want to play Russian Roulette with your DSA815, then wrap a wire between these two pins as some others have suggested.  I say this because you will most likely end up sooner or later with some oxidation between the connections and lose the Trial Options without having any warning.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: geggi1 on November 03, 2015, 09:55:15 pm
Might it be as simple as some checsum stuff to be able to use a older FW?
Add some lines with empty code to get the correc checsum?
Have anybody compared the files size and other features before upgrading FW?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on November 03, 2015, 11:49:38 pm
  Re: Sniffing the Rigol's internal I2C bus
« Reply #4063 on: Today at 06:54:27 PM »

I think that the easiest thing to do would be to replace BootLoader .04 with .03 (not that this will necessarily be that easy to do) although it seems like it could be done, and I would think easier than figuring out how to crack the new FW.  Then you would be able to use Riglol Keygen 1.03c or 1.03d to generate the Option codes.

I previously posted in the EEVblog 'DSA815 Spectrum Analyzer' thread on how to downgrade the FW when you have BootLoader .02 or .03.  And BTW I have .14 FW installed, and because I have BootLoader .03 I can still downgrade back to .06 FW and use the Keygen successfully.  And then of course reinstall .14 FW.

Suggestion:  You may want to check who the DSA815 FW gurus are and ask them via PMs for advice on how to/what to look for/etc.  Although, now and then some new guy shows up with actual answers to things like this, but not very often.  That is why I would go to the guys here that have done these things before with the DSA815.

Good Luck and Cheers. . . 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: omegat on November 04, 2015, 03:14:17 pm
Hi guys,

I just successfully dumped and unlocked my brand new MSO1104Z-S! Thank you all for your outstanding work!!

I did some things differently, namely I did not use openOCD (simply because I couldn't be bothered to actually make it
work with Win7 and my JLink...). So I opted for Jlink Commander (which is nice because it auto-detects the target -
and I had it installed anyway...) using the following commands:
h     /* for HALT (the Target)*/
speed 4800     /* pimp the JTAG frequency to 4.8MHz, you can probably go even higher, but my cable was a bit long...*/
savebin <yourfilename.bin> 0x40000000 0x3FFFFFF    /*actually dump 64MB of Firmware; it took less than ~ 5 Minutes*/
g    /*GO?? -> resumes target*/

Next thing was a problem with rigup: I kept getting segfaults. After some rigorous searching, I found that it had to do with some statically linked (??) libraries. The there mentioned fix worked (Ubuntu 15.10): Remove all LDFLAGS except -O2: LDFLAGS  := -O2
It then compiled nicely and successfully generated the magic letters...

Thanks again, keep up the awesome work!!
Tobi
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on November 06, 2015, 01:50:04 am
zapping a memory location with a serial would to seem to be easier than getting the bootloader downgraded. 
Only way I can think is the program the bootloader directly bypassing rigols loader.   I've actually asked that as well.
if anyone knows if the bootloader gel file can be programmed directly using JTAG.   Have not hear any reply to that either.

the original people who found the private keys have not appeared to express interest in working through this again.  cybernet did post some information to help and I'm thankfull for his help.




  Re: Sniffing the Rigol's internal I2C bus
« Reply #4063 on: Today at 06:54:27 PM »

I think that the easiest thing to do would be to replace BootLoader .04 with .03 (not that this will necessarily be that easy to do) although it seems like it could be done, and I would think easier than figuring out how to crack the new FW.  Then you would be able to use Riglol Keygen 1.03c or 1.03d to generate the Option codes.

I previously posted in the EEVblog 'DSA815 Spectrum Analyzer' thread on how to downgrade the FW when you have BootLoader .02 or .03.  And BTW I have .14 FW installed, and because I have BootLoader .03 I can still downgrade back to .06 FW and use the Keygen successfully.  And then of course reinstall .14 FW.

Suggestion:  You may want to check who the DSA815 FW gurus are and ask them via PMs for advice on how to/what to look for/etc.  Although, now and then some new guy shows up with actual answers to things like this, but not very often.  That is why I would go to the guys here that have done these things before with the DSA815.

Good Luck and Cheers. . .
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 9a4wy on November 06, 2015, 12:15:40 pm
Just an update...
My dsa-815tg came with FW 01.09.

Model : DSA815Serial Number : DSA8A144xxxx


Version of Main Board : 00.04
Version of Radio Frequency Board FPGA : 00.05

Version of Digital Board FPGA : 00.04

Version of Firmware : 00.01.09
Version of Boot : 00.01.02

I tried to downgrade to FW 00.01.08.03 and then install all keys...all keys accepted.
then back to 00.01.09 and all keys dissapear!
installing official key for TG restores normal operation.
Is there any other way to upgrade and keep the keys??? It's strange because I have boot 00.01.02.
Did I do something wrong???Maybe trying to downgrade to 01.06 and repeat all???
please info..tnx
K
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: McBryce on November 06, 2015, 12:53:20 pm
Did you cycle the power before you upgraded back up to 1.09?

McBryce.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 9a4wy on November 06, 2015, 01:35:52 pm
yes.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Neuro on November 06, 2015, 11:38:39 pm
Yesterday I succesfully hacked my Rigol MSO1074Z.
Thanks to the modification of the procedure now there is no need to use two OS (Windows and Linux).
Debugger, that was used, is Jet-Link Pro.
Details are here:
Code: [Select]
https://www.youtube.com/watch?v=zhVHj5GTOxY
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MiataMuc on November 06, 2015, 11:48:26 pm
yes, if anyone knows if one can downgrade the bootlader via JTAG.. I have a DG4062 with the same problem..
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 9a4wy on November 08, 2015, 07:43:45 pm
Just an update...
My dsa-815tg came with FW 01.09.

Model : DSA815Serial Number : DSA8A144xxxx


Version of Main Board : 00.04
Version of Radio Frequency Board FPGA : 00.05

Version of Digital Board FPGA : 00.04

Version of Firmware : 00.01.09
Version of Boot : 00.01.02

I tried to downgrade to FW 00.01.08.03 and then install all keys...all keys accepted.
then back to 00.01.09 and all keys dissapear!
installing official key for TG restores normal operation.
Is there any other way to upgrade and keep the keys??? It's strange because I have boot 00.01.02.
Did I do something wrong???Maybe trying to downgrade to 01.06 and repeat all???
please info..tnx
K

Just tried to dowgrade DSA-815TG from present 01.08. to 01.06 and all licenses still active....then upgrade to newest 01.14 and all options dissapear again! BOOT 01.02 AND LICENSES DISSAPEAR WITH UPGRADE FW  TO 01.09 OR HIGHER!
Downgraded to 01.08 and install all licenses again.
Stucked with FW01.08 for now  :( .
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: agronaught on November 11, 2015, 02:09:05 am
So am I right in what I've read that one of the 'new' dsa-815's will lose the presumably unpurchasable 10Hz RBW bandwidth when the trial timers expire ?

I just took delivery of a new unit and I'm not all that keen on opening it up immediately.  If the 10Hz RBW breaks than I see no alternative but to bridge the pins on the fram.

J.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: TheSteve on November 11, 2015, 02:33:17 am
New units don't have 10 Hz RBW anyway. While the option exists it isn't official and doesn't exist according to Rigol. Unless your unit is special 100 Hz will be the minimum RBW.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: agronaught on November 11, 2015, 07:18:55 am
New units don't have 10 Hz RBW anyway. While the option exists it isn't official and doesn't exist according to Rigol. Unless your unit is special 100 Hz will be the minimum RBW.

Just got home and... your right.   Ah well, it is what it is.

Thanks.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: TheSteve on November 11, 2015, 09:03:57 am
New units don't have 10 Hz RBW anyway. While the option exists it isn't official and doesn't exist according to Rigol. Unless your unit is special 100 Hz will be the minimum RBW.

Just got home and... your right.   Ah well, it is what it is.

Thanks.

Should someone figure out the new keys needed to enable features it can still likely be enabled. It's not often needed but is still nice to have.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on November 15, 2015, 12:39:37 pm
Hi...
Is there any news on how to unlock the features on Rigol MSO1104Z model?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on November 15, 2015, 06:29:14 pm
Hi...
Is there any news on how to unlock the features on Rigol MSO1104Z model?

I don't think any one is looking at doing anything beyond what's been done.   open it up,   jtag dump the SDRAM and run the keygen.  it works fine.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on November 15, 2015, 07:05:38 pm
Hi...
Is there any news on how to unlock the features on Rigol MSO1104Z model?

I don't think any one is looking at doing anything beyond what's been done.   open it up,   jtag dump the SDRAM and run the keygen.  it works fine.

I just bought the scope. I'm still not prepared to void the warranty! :) I'll wait and maybe someone can do that for those who have yet a valid warranty!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on November 15, 2015, 10:37:37 pm
I'll wait and maybe someone can do that for those who have yet a valid warranty!

You need your own dump for the keygen.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zsidoz on November 20, 2015, 12:52:20 pm
Yesterday I succesfully hacked my Rigol MSO1074Z.
Thanks to the modification of the procedure now there is no need to use two OS (Windows and Linux).
Debugger, that was used, is Jet-Link Pro.
Details are here:
Code: [Select]
https://www.youtube.com/watch?v=zhVHj5GTOxY

Hello Neuro,
I followed the link you supplied, made the memory dump of MSO1074Z and run the rigup tool. I got this output:
rigup license - Version 0.4.1-mso1000z

        Hacked up for MSO1000Z(-S) rmd79, 0ff eevblog.com

Invalid Hexstring given:
Invalid Hexstring given:
Invalid Hexstring given:
HG7ZVYU-RNH93DR-HU6E4P6-UY4FJ6M    (CSAR = 0x1C001)

The code I got is invalid. When I run the tool again I always get different codes but they are also invalid.
Any idea? Thanks.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: McBryce on November 20, 2015, 01:39:05 pm
There's a special patched version of the rigup tool for the MSO, are you using this or did you use the standard rigup tool?

McBryce.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on November 20, 2015, 10:14:06 pm
What are you using as the License code you want to enable?
The message you're getting would indicate you're using CSAR for the license code and in the hacked version for the MSO1000Z's  you have to use the HEX value such as 0x1C001.

Also did you run it though and create the key file that has the private key in it? that's what you feed into riglol to get your license codes.

Sorry for the basic questions but there's actually little information on what you did to know where it went wrong.

Sandra

Hello Neuro,
I followed the link you supplied, made the memory dump of MSO1074Z and run the rigup tool. I got this output:
rigup license - Version 0.4.1-mso1000z

        Hacked up for MSO1000Z(-S) rmd79, 0ff eevblog.com

Invalid Hexstring given:
Invalid Hexstring given:
Invalid Hexstring given:
HG7ZVYU-RNH93DR-HU6E4P6-UY4FJ6M    (CSAR = 0x1C001)

The code I got is invalid. When I run the tool again I always get different codes but they are also invalid.
Any idea? Thanks.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zsidoz on November 23, 2015, 06:56:00 am
@ Sandra,

I followed the video on https://www.youtube.com/watch?v=zhVHj5GTOxY (https://www.youtube.com/watch?v=zhVHj5GTOxY) and downloaded the windows version of rigup from here http://tqfp.org/attachments/get/1 (http://tqfp.org/attachments/get/1)
I called the tool with this command line: "rigup license mso1074z_dump.bin 0x1C001", where the bin file is what I saved from the scope memory.

@ McBryc,
What is that "special patched version" and where can I find it?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: McBryce on November 23, 2015, 09:21:07 am
It's the MSO version that you can find here: http://www.gotroot.ca/rigol/ (http://www.gotroot.ca/rigol/) but after rereading your post, I think you are using the right one already.

McBryce.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on November 23, 2015, 02:33:53 pm
Ah,
Maybe it's this
you're doing a rigup license mso1074z_dump.bin 0x1C001
but the input to license is the output of the scan

rigup scan mso1074zs.bin > mso1074zs.txt    // This reads your dump and writes your public/private key to the output file mso1074zs.txt in this case
rigup license mso1074zs.txt 0x1C001             // this reads the mso1074zs.txt file you created above and requests the license for 0x1C001

See if that helps

you're using the patched version of rigup  the "Hacked up for MSO1000Z(-S) rmd79, 0ff eevblog.com" says that.   rmd79, 0ff hacked it to work with the MSO line



@ Sandra,
I called the tool with this command line: "rigup license mso1074z_dump.bin 0x1C001", where the bin file is what I saved from the scope memory.

@ McBryc,
What is that "special patched version" and where can I find it?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Neuro on November 23, 2015, 03:10:45 pm
2 zsidoz:
Could you please write exactly the command string, that you have used to extract the serial number from the dump?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zsidoz on November 24, 2015, 08:39:33 am
Sandra pointed out the missing step:
rigup scan mso1074zs.bin > mso1074zs.txt

After that I got the correct license keys and the scope is successfully hacked.

Thanks for the awesome support from all of you!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on November 24, 2015, 06:23:05 pm
Glad to hear that was it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: staze on November 30, 2015, 09:46:00 pm
Quick question, and a search didn't seem to turn anything up. Has anyone figured out key generation for the DG1032Z? Thanks!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: whotopia on December 09, 2015, 08:59:18 pm
Can someone advise if it is possible to restore the serial number of a DS2072A ?
I tried to do some of the hacks in the past and this lead me to a unit with serial number DS2A0000000001.  The MAC address on the LAN interface is also wrong.  It's 46:46:46:46:46:46.  I assume the MAC must be uniquely generated from the serial number somehow.
The device is currently at firmware DS2000(DSP)Update_00.03.04.01.00
What can I do?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: largosoft on December 24, 2015, 02:52:17 pm
Hello everyone, I have a spectrum analyzer DSA815-TG and I try to update blockade, got it working again Through his advice.
the problem is that I delete the model, serial number and licenses had. Also, calibration data is erased.
lei so the only way to regain full functionality of the analyzer firmware is reinstalled complete with JTAG.
Someone could spend the entire firmware (approximately 5 Megas) and information to enter the serial number of my scanner.
from already very grateful. Excuse my English, use a translator, I'm from Argentina.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on December 30, 2015, 10:42:49 pm
Hello everyone, I have a spectrum analyzer DSA815-TG and I try to update blockade, got it working again Through his advice.
the problem is that I delete the model, serial number and licenses had. Also, calibration data is erased.
lei so the only way to regain full functionality of the analyzer firmware is reinstalled complete with JTAG.
Someone could spend the entire firmware (approximately 5 Megas) and information to enter the serial number of my scanner.
from already very grateful. Excuse my English, use a translator, I'm from Argentina.

See -  https://www.eevblog.com/forum/testgear/dsa815-tg-calibration-data-of-tg-lost/msg802901/#msg802901 (https://www.eevblog.com/forum/testgear/dsa815-tg-calibration-data-of-tg-lost/msg802901/#msg802901)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: geralex on January 09, 2016, 02:24:34 pm
After that I got the correct license keys and the scope is successfully hacked.
Which firmware version do you have?  I have the MSO1074Z-S with the firmware 00.04.03.SP1. I think I´ve done all steps right, used the special 0.4.1-mso-version, first rigup scan, then rigup license and also get every time and both on debian and windows the same serials. But though non of the license keys work, I only get 'Invalid license' :(
Does someone have some ideas?

Edit:
Ok, just got it, now also here all "official" :) Don`t know what was wrong. Possibly it depends on what time after startup of the oscilloscope you do the dump. At first time I`ve done it half a minute after it showed the options screen. It worked when I had done it still shows the Rigol startup screen. As seen above I have the FW 4.3.SP1. I needn`t modify any files (such as the serial number as mentiones in a post above)
So thanks to Off and all the other users that have contributed to the thread :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: daemonix on January 17, 2016, 06:02:03 pm
hi everyone,

I need a bit of up to date help! :)
I haven't look around for new info for quite some time!!!

Im still on 00.02.03.SP5 on my DS1074Z. With all the hacks (NOT the 500us something). 100mhz etc.

1)Which firmware I can load without messing with the hacks etc??
2)Where should I get it from? UK telocin for example?

thanks a lot!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Spork Schivago on January 17, 2016, 11:51:05 pm
Does anyone have a copy of the flash that they dumped on the DP832 / DP832A?   I've been researching how to dump it, and it looks like my only options might be to actually remove the flash and read it out of circuit.   I seen someone did this earlier on but never got a response when I contacted them.   If anyone did actually dump anything from the Rigol DP832 / DP832A, would you mind sharing with me what you got please?   Thank you!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: technokratos on January 24, 2016, 03:34:16 pm
Hi guys,

I would, quite humbly, like to ask you for a small clarification for me. I am not a pro and I wouldn't like to fry my new MSO1104Z-S. I saw Crille77's howto but this is what I do not get:
1) can I use this j-link to connect to JTAG port? http://www.ebay.com/itm/J-Link-OB-ARM-Debugger-Programmer-Downloader-replace-v8-SWD-M74-New-/221808339497 (http://www.ebay.com/itm/J-Link-OB-ARM-Debugger-Programmer-Downloader-replace-v8-SWD-M74-New-/221808339497)
2) can I use the same cable connection schema Crille77 posted? If not, could someone offer connection details?

Thanks a bunch guys! Wonderful work. Wish I could buy you a beer :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on January 24, 2016, 07:55:56 pm
If not, could someone offer connection details?

Have a look at reply #3731. The picture with the header...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: technokratos on February 14, 2016, 09:50:22 am
Just a little intro for newbies like me:

I can confirm the process works flawlessly with Altera USBblaster. To speed up the dump, I modified openocd config file for usbblaster in scripts/interfaces and added the line:
Code: [Select]
adapter_khz 6000
The whole dump was then completed in approx. 3 hours.

Here I share OpenOCD 0.9.0 for Windows (use 32 bit executable, 64bit didn't work for me - probably doesn't play nice with usbblaster's 32 bit driver). The configuration change I made is included in the .rar file. Also in the folder drivers you can find a nifty UsbDriverTool.exe to install signed certificate for usbblaster (instead of Altera's original one - didn't work for me on win 8.1 64bit). It will replace the driver with signed generic libusb driver so you don't have to go through the stupid process of enabling unsigned certificates in Win 8)

The command is:
openocd.exe -d1 -f C:\path\to\openocd-0.9.0\scripts\interface\altera-usb-blaster.cfg -f C:\path\to\openocd-0.9.0\scripts\target\imx28.cfg

http://www26.zippyshare.com/v/Z88EL5Jr/file.html (http://www26.zippyshare.com/v/Z88EL5Jr/file.html)

Newest OpenOCD build for Windows can be found at Freddie's website: http://www.freddiechopin.info/en/download/category/4-openocd (http://www.freddiechopin.info/en/download/category/4-openocd)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Neuro on March 05, 2016, 11:24:11 am
My Web-site is moved to http://i-hobby.org (http://i-hobby.org)
Thats why Windows-version of rigup software for unlocking options of MSO1074 is now available at http://i-hobby.org/blog/60.html (http://i-hobby.org/blog/60.html)
Direkt download link is here: http://i-hobby.org/file/go/60/ (http://i-hobby.org/file/go/60/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Engineer1 on March 09, 2016, 01:26:11 pm
Hi,

I've successfully unlocked the options on my DS-4024 (for which, huge thanks for all the hard work on the decoding!), which has given the power analysis option. However, it seems that this needs their Ultra Power software, which I downloaded from their site. But, it reports that it's only a trial, that'll run for 15 days, and asks for an unlock key. So, is there a way to use the power analysis function directly on the 'scope, or does it also need the Ultra Power software? If so then I'll need to be pretty quick with testing it out.

Cheers.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on March 09, 2016, 06:57:03 pm
My Web-site is moved to http://i-hobby.org (http://i-hobby.org)
Thats why Windows-version of rigup software for unlocking options of MSO1074 is now available at http://i-hobby.org/blog/60.html (http://i-hobby.org/blog/60.html)
Direkt download link is here: http://i-hobby.org/file/go/60/ (http://i-hobby.org/file/go/60/)

1.) 3 posts at all
2.) Website with russian content
3.) Windows software for direct download
( 4.) superfluous software )

 :palm:

Nice try, young whippersnapper!  :-DD
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Neuro on March 10, 2016, 01:03:49 am
My Web-site is moved to http://i-hobby.org (http://i-hobby.org)
Thats why Windows-version of rigup software for unlocking options of MSO1074 is now available at http://i-hobby.org/blog/60.html (http://i-hobby.org/blog/60.html)
Direkt download link is here: http://i-hobby.org/file/go/60/ (http://i-hobby.org/file/go/60/)

1.) 3 posts at all
2.) Website with russian content
3.) Windows software for direct download
( 4.) superfluous software )

 :palm:

Nice try, young whippersnapper!  :-DD

Well, if you don't need that software - that doesn't mean that it's useless!

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: CustomEngineerer on March 10, 2016, 02:58:34 am
Are we supposed to have known what your previous website was?  I don't see any posts where you mention it. Got to agree with hammy, even if that was something I needed there is no way I would download it from that site. Sorry if you are legit and trying to help but that just sounds insanely fishy. Now if you happen to be a Nigerian Prince, that might make me feel safer.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on March 10, 2016, 06:55:15 am
My Web-site is moved to http://i-hobby.org (http://i-hobby.org)
Thats why Windows-version of rigup software for unlocking options of MSO1074 is now available at http://i-hobby.org/blog/60.html (http://i-hobby.org/blog/60.html)
Direkt download link is here: http://i-hobby.org/file/go/60/ (http://i-hobby.org/file/go/60/)

1.) 3 posts at all
2.) Website with russian content
3.) Windows software for direct download
( 4.) superfluous software )

 :palm:

Nice try, young whippersnapper!  :-DD

Well, if you don't need that software - that doesn't mean that it's useless!
Why do you post a link which contains ONLY Russian content ? Do you really think this will be useful here ?.
Why is you country flag in your profile German ?.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Neuro on March 10, 2016, 11:42:03 am
My Web-site is moved to http://i-hobby.org (http://i-hobby.org)
Thats why Windows-version of rigup software for unlocking options of MSO1074 is now available at http://i-hobby.org/blog/60.html (http://i-hobby.org/blog/60.html)
Direkt download link is here: http://i-hobby.org/file/go/60/ (http://i-hobby.org/file/go/60/)

1.) 3 posts at all
2.) Website with russian content
3.) Windows software for direct download
( 4.) superfluous software )

 :palm:

Nice try, young whippersnapper!  :-DD

Well, if you don't need that software - that doesn't mean that it's useless!
Why do you post a link which contains ONLY Russian content ? Do you really think this will be useful here ?.
Why is you country flag in your profile German ?.

Video for unlock of features of MSO1074 is in English. Software is in English too and it could be usefull here.   
I think that it doesn't matter in what language is the rest of content on my web-site. And I don't propose
somebody here to read my posts in Russian. Not all of content on my web-site is in Russian - there are some posts and videos in
English and in German.
I live in Germany and i speak 6 languages: Russian, English, German, Spanish, Ukrainian and Arabic.
What's the problem with a flag and with a language?  :wtf:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Neuro on March 10, 2016, 11:47:25 am
Are we supposed to have known what your previous website was?  I don't see any posts where you mention it. Got to agree with hammy, even if that was something I needed there is no way I would download it from that site. Sorry if you are legit and trying to help but that just sounds insanely fishy. Now if you happen to be a Nigerian Prince, that might make me feel safer.
Test Equipment / Re: Sniffing the Rigol's internal I2C bus
« on: November 07, 2015, 10:38:39 AM »
Yesterday I succesfully hacked my Rigol MSO1074Z.
Thanks to the modification of the procedure now there is no need to use two OS (Windows and Linux).
Debugger, that was used, is Jet-Link Pro.
Details are here:
https://www.youtube.com/watch?v=zhVHj5GTOxY (https://www.youtube.com/watch?v=zhVHj5GTOxY)

That was my post at the 7-th of November 2015.
If your have an opinion, that this software is useless, then never mind.  :-//
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on March 10, 2016, 12:27:49 pm

What's the problem with a flag and with a language?  :wtf:
Mind your Language a bit will you. Your posts with a funny URL look suspicious.
A lot of hackers come from Russia or from that region, so it is not so strange that people start asking questions. If then your language flag is set to German, your profile becomes even more strange.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: apelly on March 10, 2016, 07:33:49 pm
What's the problem with a flag and with a language?  :wtf:
Don't worry about it.

I haven't looked at your website, but here are some thoughts:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zeratul42 on March 21, 2016, 10:08:55 pm
Hello,
I've a DSA815TG with boot 1.04, to get all licenses i had to solder write pin on Fram.
Does anybody have a way to get private key and generate License ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Neuro on March 26, 2016, 10:47:02 pm
  • If the source is available that can help with trust issues (but nobody will take the time to compile it, and 80% of those that do will hassle you about where to get missing libraries)
For those, who are afraid of russian hackers, I've updated a zip-archive.  :-DD Now it consist of exe-file and sources. You are free to use or compile it.  ;)
The link is: http://i-hobby.org/file/go/60/  (http://i-hobby.org/file/go/60/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Macbeth on March 26, 2016, 11:55:52 pm
For those, who are afraid of russian hackers, I've updated a zip-archive.  :-DD Now it consist of exe-file and sources. You are free to use or compile it.  ;)
The link is: http://i-hobby.org/file/go/60/  (http://i-hobby.org/file/go/60/)

Yeah. But No..

??????: 404

(Error: 404 - will the forum finally allow Cyrillic characters?)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mosaic on April 09, 2016, 08:52:43 am
Just an FYI of the bandwidth of the 'unlocked DS2072a - DS2302A' .

With well calibrated leveled sine wave gens, SG503 and SG504 (TEK) using my custom made remote head for flatness <0.1dB I re-evaluated the Rigol bandwidth.

Figures of merit:

150Mhz - Rigol is still accurate  matching the Vpp of the signal.

300Mhz - Rigol is down 2dB in amplitude.

400 Mhz - Rigol is down 3dB in amplitude.

I'd go with using it to 175Mhz max as reasonably accurate. Start factoring in losses past that.

This cross refernce check matches quite well with my VNA test results on the scope.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zibadun on April 10, 2016, 03:50:33 pm

What's the problem with a flag and with a language?  :wtf:
Mind your Language a bit will you. Your posts with a funny URL look suspicious.
A lot of hackers come from Russia or from that region, so it is not so strange that people start asking questions. If then your language flag is set to German, your profile becomes even more strange.

This guy does not appear to be a "hacker" in a malicious context..  He is a physician from Ukraine who moved to Germany after "the revolution".  He was employed in Crimea at the time of the putsch,  when the newly formed Ukrainian government banned him from continuing work in the occupied territory.  From what I understand he is now a licensed MD in Germany.  I don't think his profile matches a 'script kiddie' who wants to crack your PC.   Just saying...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on April 12, 2016, 12:13:11 am
it is in spec for a 300Mhz scope though..  The 3db point is at 400Mhz
just putting it out there that the behavior is not unexpected for this or any scope.

Just an FYI of the bandwidth of the 'unlocked DS2072a - DS2302A' .

With well calibrated leveled sine wave gens, SG503 and SG504 (TEK) using my custom made remote head for flatness <0.1dB I re-evaluated the Rigol bandwidth.

Figures of merit:

150Mhz - Rigol is still accurate  matching the Vpp of the signal.

300Mhz - Rigol is down 2dB in amplitude.

400 Mhz - Rigol is down 3dB in amplitude.

I'd go with using it to 175Mhz max as reasonably accurate. Start factoring in losses past that.

This cross refernce check matches quite well with my VNA test results on the scope.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: CustomEngineerer on April 12, 2016, 12:45:01 am
This guy does not appear to be a "hacker" in a malicious context..  He is a physician from Ukraine who moved to Germany after "the revolution".  He was employed in Crimea at the time of the putsch,  when the newly formed Ukrainian government banned him from continuing work in the occupied territory.  From what I understand he is now a licensed MD in Germany.  I don't think his profile matches a 'script kiddie' who wants to crack your PC.   Just saying...

Thats exactly what I'd expect a Ukrainian hacker's German accomplice to say.

Sorry, couldn't resist.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zibadun on April 12, 2016, 12:53:41 am
Thats exactly what I'd expect a Ukrainian hacker's German accomplice to say.

Sorry, couldn't resist.

Bad joke pal.  I spent some time on Neuro's web site, looked at the content, watched some of his youtube videos, translated his story for you so that *you* can sleep well and not be afraid.  and you thanked by calling me a hacker's accomplice?  GFY
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Neuro on April 12, 2016, 03:11:56 pm
For those, who are afraid of russian hackers, I've updated a zip-archive.  :-DD Now it consist of exe-file and sources. You are free to use or compile it.  ;)
The link is: http://i-hobby.org/file/go/60/  (http://i-hobby.org/file/go/60/)

Yeah. But No..

??????: 404

I've fixed that problem. Now the sources are available.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: timofonic on April 12, 2016, 10:56:14 pm
Thats exactly what I'd expect a Ukrainian hacker's German accomplice to say.

Sorry, couldn't resist.

Bad joke pal.  I spent some time on Neuro's web site, looked at the content, watched some of his youtube videos, translated his story for you so that *you* can sleep well and not be afraid.  and you thanked by calling me a hacker's accomplice?  GFY
Hey, please check your notes about acid humor! There's a risk of Asperger issues here, I think.

I just see it as joking about stereotypes. It's true some homebrew attitudes make is suspicious too, but sometimes people lived to joke about it.

What can be more funnier than being someone like...

Linus Torovoldos: A technology genius since very early age (he learnt C++ and assembly at 5yo) and physician from ex-USSR that lived in Crimea (even the name is cool, it sounds s crime in English).

- He got involved in a very highly experimental cyberpunk project, it seems he applied it to his own brain in order to augment his cognitive skills (he's fluent in six human languages at least).

- He escaped to Germany and is hidden as a MD.


This could be the next James Bond movie! Please make it happen! :D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DaBone_206 on April 29, 2016, 12:49:56 pm
Hello everybody,
i have a Problem with my Rigol MSO1074zs. I want to unlock all functions but it doesn't works.
I run the Load Dump with an SEGGER ARM Flascher and I use this Rigup Software http://gotroot.ca/rigol/rigup-0.4.1-mso1000z.zip (http://gotroot.ca/rigol/rigup-0.4.1-mso1000z.zip) to unlock. But my generated Keys goes wrong.  :-\

What can i do?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on April 29, 2016, 03:35:46 pm
I run the Load Dump with an SEGGER ARM Flascher and I use this Rigup Software ...

How big is the dump file and how long you dumped it? My dumpfile had a size of roundabout 65MB.

The first command was:
"./rigup scan mso1074z-s_RAM.bin > mso1074s.txt"

After that I generated the keys with these commands:
"./rigup license mso1074s.txt 0x1C001"
"./rigup license mso1074s.txt 0x1C002"
"./rigup license mso1074s.txt 0x1C004"
"./rigup license mso1074s.txt 0x1C008"
"./rigup license mso1074s.txt 0x1C080"

After that I entered the licenses.

HTH!

Cheers
hammy


List of hex values:
(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

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DaBone_206 on April 29, 2016, 09:04:53 pm

How big is the dump file and how long you dumped it? My dumpfile had a size of roundabout 65MB.


The dump file had a size of 65.536KB and i loaded it from 0x40000000 to 0x3FFFFFF with 4800 kHz.
I have already tried the hex values 0x1C001, 0x1C002 0x1C0FF but unfortunately without success.

Perhaps it may be a problem with the current firmware?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Prax on May 02, 2016, 09:49:27 am

How big is the dump file and how long you dumped it? My dumpfile had a size of roundabout 65MB.


The dump file had a size of 65.536KB and i loaded it from 0x40000000 to 0x3FFFFFF with 4800 kHz.
I have already tried the hex values 0x1C001, 0x1C002 0x1C0FF but unfortunately without success.

Perhaps it may be a problem with the current firmware?

I am having similar issues as well. Firmware 04.03 SP2 (and on SP1) Rigup 0.41 (MSO1000Z Edition) no longer seems to generate valid option keys. I continue to get "Invalid License" on the unit.

On a slightly different note: In this firmware revision, it seems they moved the offset for the keys back to  "02 00 84 00 10 00"  Rigup 0.41 is currently looking for keys at  "01 00 84 00 10 00" which is no longer the case for the MSO1074Z-S. Anyone attempting to use previously compiled rigup for windows or compile without modifying "utils.c" will likely get  "Scanning 'mso1074z.bin' failed: No keys"

Attemping to use rigup info mso1074z.txt [LICENSE KEY] generates a "--- FAILED ---" on verify. It does seem to know which option it is from the license key.

Example (Rigup 0.41 MSO1000Z Edition): ./rigup info mso1074z.txt XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX
XXXXXXX-XXXXXXX-XXXXXXX-XXXXXXX    (CSA3 = 0x1C004)
Signature 1:    000000008599XXXX
Signature 2:    00000000877dXXXX
Padding 1:      0000000000000000
Padding 2:      0000000000000000
Verify:         --- FAILED ---
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Prax on May 02, 2016, 10:12:16 am
I run the Load Dump with an SEGGER ARM Flascher and I use this Rigup Software ...

How big is the dump file and how long you dumped it? My dumpfile had a size of roundabout 65MB.

The first command was:
"./rigup scan mso1074z-s_RAM.bin > mso1074s.txt"

After that I generated the keys with these commands:
"./rigup license mso1074s.txt 0x1C001"
"./rigup license mso1074s.txt 0x1C002"
"./rigup license mso1074s.txt 0x1C004"
"./rigup license mso1074s.txt 0x1C008"
"./rigup license mso1074s.txt 0x1C080"

After that I entered the licenses.

HTH!

Cheers
hammy


List of hex values:
(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

What is your firmware version? A few of us are not getting any success on the new firmware. Unfortunately, my unit was new and had 04.03 from factory. If you didn't modify utils.c on rigup 0.41 to change offset, I surmise that it is below that.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Macbeth on May 02, 2016, 10:19:57 am
Can you not flash an old firmware then activate the keys on that before upgrading back to the latest?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Prax on May 02, 2016, 10:38:34 am
Can you not flash an old firmware then activate the keys on that before upgrading back to the latest?
I didn't think downgrading was possible.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on May 02, 2016, 11:31:35 am
Can you not flash an old firmware then activate the keys on that before upgrading back to the latest?
I didn't think downgrading was possible.

If your dump is 16Kb it's too small.
a 0x3FFFFFF is 67108863 bytes
The openocd command is
dump_image mso1074zs.bin 0x40000000 0x3FFFFFF
Thats start at address 0x40000000 and dump 0x3FFFFFF bytes  so if you have a 16Kb dump it's not going to work
If that is a typo and even if you meant Mb it's still too small to be sure you got everything.

If you do have a 64MB dump please ignore this, otherwise if you truly have a 16Kb dump, please try it again and be sure you get the full 64Mb+ dump

What boot loader do you have?  has it been upgraded to a newer boot?
if not, try downgrading as MacBeth stated.

Downgrading isnt' possible with the DSA815 I've not heard anyone say the MS01074 wasn't down gradeable.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Prax on May 02, 2016, 12:15:22 pm
Can you not flash an old firmware then activate the keys on that before upgrading back to the latest?
I didn't think downgrading was possible.

If your dump is 16Kb it's too small.
a 0x3FFFFFF is 67108863 bytes
The openocd command is
dump_image mso1074zs.bin 0x40000000 0x3FFFFFF
Thats start at address 0x40000000 and dump 0x3FFFFFF bytes  so if you have a 16Kb dump it's not going to work
If that is a typo and even if you meant Mb it's still too small to be sure you got everything.

If you do have a 64MB dump please ignore this, otherwise if you truly have a 16Kb dump, please try it again and be sure you get the full 64Mb+ dump

What boot loader do you have?  has it been upgraded to a newer boot?
if not, try downgrading as MacBeth stated.

Downgrading isnt' possible with the DSA815 I've not heard anyone say the MS01074 wasn't down gradeable.
The memdump was 64MB. I never said anything about a 16Kb dump, plus I have isolated where the keys are in the memdump, it is in a different location than what rigup 0.41 is scanning for with the new firmware. (See the top of this page)

According to this thread https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-firmware-downgrade-*is*-possible-and-here-is-how/ (https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-firmware-downgrade-*is*-possible-and-here-is-how/) downgrading only works on a very old bootloader version. My Boot version is 0.0.1.3. Only versions 0.0.0.11 and 0.0.0.13 allowed downgrading it would seem.

*EDIT* Okay. I tried the downgrade process doing the press help 3 times method and it just beeped and blinked at me until I turned the unit off. Trying to downgrade the traditional way also ended in failure.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on May 02, 2016, 07:15:44 pm
What is your firmware version?

It was a previous firmware version, more than a year ago.

Cheers
hammy
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on May 05, 2016, 07:06:03 pm
Are current version DP832's hackable?  If so, where is the keygen for them?  How long do they take to power on in seconds?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Prax on May 05, 2016, 07:44:11 pm
Are current version DP832's hackable?  If so, where is the keygen for them?  How long do they take to power on in seconds?
Yes the DP832 is hackable (up to the latest firmware). Do a search on google for "Riglol". Power up time is about 4-5 seconds.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on May 05, 2016, 08:15:30 pm
Thank you Prax - I appreciate it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on May 05, 2016, 09:51:32 pm
Riglol shows individual options, but no letter code for all options.  Do you have to load the options one a a time or something?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: CustomEngineerer on May 06, 2016, 12:22:03 am
Yes, you have to enter each option's code individually. As far as I know there is no combination codes like you find for the Rigol scopes.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Prax on May 06, 2016, 10:16:04 am
Riglol shows individual options, but no letter code for all options.  Do you have to load the options one a a time or something?
Yes, it's individual. No bundle codes. It's also unfortunate that there are no SCPI commands for setting licenses with the DP series. Unlike the scopes where you can use SYSTem:OPTion:INSTall [LICENSE KEY]
It can be pretty tedious entering codes on Rigol products with their poor interfaces.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on May 09, 2016, 10:52:26 am
New DS4000 Firmware, Version 00.02.03.00.03, 3 MB, Released 2016-05-05:

http://int.rigol.com/File/ProductSoftWare/20160505/DS4000(DSP)update.zip (http://int.rigol.com/File/ProductSoftWare/20160505/DS4000(DSP)update.zip)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: OsiViper on May 30, 2016, 01:09:19 am
Was curious if anyone was able to get this to work with a Atmel ICE. I have the ICE and a new MSO2072A that I wanna unlock the upgrades on and I am wondering if anyone has gotten it to work with the iCE or if I am just better off getting a different tool for the JTAG. And if so, which one is good (doesn't take years to finish)?

Thanks!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: SupraWez on May 31, 2016, 02:13:37 pm
Hey All,

Great info  :-+

I see the DP832 is mentioned a lot, does anyone know if the DP811 will also work with Riglol?

Thanks
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: TurboTom on May 31, 2016, 06:33:41 pm
The DP811 definitely works as well. Just a week ago I tested it with a unit produced november 2015.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: SupraWez on June 01, 2016, 08:20:30 pm
The DP811 definitely works as well. Just a week ago I tested it with a unit produced november 2015.

Thanks  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: OsiViper on June 03, 2016, 06:31:07 pm
I got the Olimex ARM-USB-OCD JTAG Adapter and I am using Win7 64 bit. I got the Blackfin toolchain and I try running "bfin-gdbproxy.exe --debug bfin --frequency=5000000" and all it returns is "debug: bfin: bfin_open ()", "error: bfin: cable initialization failed"

I have tried different USB ports, using Zadig to use a WinUSB Driver instead, but I cannot get past the cable initialization failed.

Any help would be great since I got my scope torn apart on the desk.

Thanks!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: CustomEngineerer on June 03, 2016, 09:24:08 pm
Did you try different cables? Some USB cables are just crap and can give you real problems. Try a short, quality USB cable if all else fails.

Edit: By quality I don't mean a $50 1 foot gold plated monster cable or anything like that, just a cable from a reputable company.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: OsiViper on June 03, 2016, 10:18:57 pm
Yea. Tried 3 different cables, none wanna work.

Tried wiring it up using the pull-up resistors as well as wiring TRST and SRST right in instead and nothing seems to make any difference .
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: OsiViper on June 03, 2016, 11:35:11 pm
Well. It wasn't an adapter problem or my wiring. Was something with the drivers in Windows. Had been meaning to install Ubuntu on a external hard drive, so just did that, got Blackfin for Linux and ran it. Working just fine now, doing the dump right now.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Macbeth on June 04, 2016, 12:36:16 am
I had a whale of a time trying to get Blackfin toolchain working with Olimex ARM-USB-OCD on Win 8/10. I gave up.

I did get it running on Ubuntu, though for some reason when using the bfin-* commands like bfin-urjtag vs the plain old urjtag found in the Ubuntu repositories, I find all my cursor keys and history turn into escape characters instead of working normally. It's really annoying!

I also have to run everything using sudo. I've seen some workarounds for this, using udev rules, but they don't seem to work with newer Ubuntu versions. :(

Any hints on getting it working seamlessly with Ubuntu 16.04 LTS?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: OsiViper on June 04, 2016, 01:54:37 am
I got this one "blackfin-toolchain-2014R1_45-RC2.x86_64.tar.bz2" , and I use the tools under /opt/uClinux/bfin-uclinux/bin and it seems to work just fine for me. The dumping that is.

I am having a problem though, I have done 3 dumps and when I do "sudo ./rigup scan ds2k_00_sdram.bin" it tells me that there are no keys found.

Code: [Select]
:~$ sudo ./rigup scan ds2k_00_sdram.bin
rigup scan - Version 0.4.1

        Hacked up for MSO1000Z(-S) rmd79, 0ff eevblog.com

Scanning 'ds2k_00_sdram.bin' failed: No keys
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: OsiViper on June 04, 2016, 02:48:34 am
Well, I learned something.. I got it working for the MSO2072A.. Aparently Rigup 0.4.1 will not work for it, I downloaded Rigup 0.4.0 and it generated the keys just fine. Got a 200 MHz scope now with all the options.. Thanks everyone for the info here
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pvico on June 05, 2016, 02:39:31 pm
Did anybody have any luck with the DS1xxxZ Plus?

I have a very recent DS1104Z Plus with SN DS1ZCxxxxxxxxx, software 00.04.03 SP2, board 2.1.1 & boot loader 0.0.1.4.

I spent more than 2 full days doing the following:
I obtained the dump file with an Olimex ARM-USB-OCD-H.
I compiled rigup-0.4.1-mso1000z (I did it both on Mac OS X and Ubuntu 14, they give the same results).
A rigup scan of the dump file gives apparently correct keys and the SN is correct, but the licenses generated with 0x1C00x are all invalid.

Looking into my dump file, the only long string that could be a character map is "ABCDEFGH234JKLMNPQR567STUVWXYZ89", so I replaced all instances of charMapDecode and charMapEncode in encode.c and decode.c with that string. The licenses are still invalid.

IMHO, the causes could be:
- Codes other than 0x1C00x are needed
- The private key is not correct. This is a bit scary: the code to transform the public key into a private key is quite complex (using of the MIRACL library) and there are a lot of 'magic' values involved (the ECC parameters in solver.c). Is there any way to verify if these values are still ok?
- A completely different encoding method has been used for this model (I hope not)

In the dump file, there are a few 28 character strings (with characters in ABCDEFGHJKLMNPQRSTUVWXYZ23456789) which are, I guess, the trial licenses.
Should they verify with rigup info (they don't)?

I played a bit with rigup-0.4.0, tried to apply the patches but that did not work either.

Many thanks to anybody who could answer some of these questions.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: arobincaron on June 05, 2016, 07:08:12 pm
Here's my experience "testing" the ability to setup MSO1074z scope option capabilities:

I do not have a JTAG cable to get a memory dump. I researched alternatives (USB Blaster, Bus Pirate, etc) and I saw the following: https://github.com/synthetos/PiOCD/wiki/Using-a-Raspberry-Pi-as-a-JTAG-Dongle (https://github.com/synthetos/PiOCD/wiki/Using-a-Raspberry-Pi-as-a-JTAG-Dongle).  As I use Windows 10 I liked the idea of avoiding driver issues by using openocd on Linux.

I purchased a Raspberry Pi 3 (thanks Amazon for same day delivery!).  I hooked it up and followed the instructions from the article to get openocd compiled. I removed the 2 references to "--enable-ft2232_libftdi" as "configure" indicated that that driver is obsolete and I wasn't planning on using it anyway. I stopped following the instructions where downloading of the tcl script (i.e. "sudo wget https://gist.github (https://gist.github)...") is indicated as from there the instructions are for connecting the Pi to an Arduino Due.

With the Raspberry Pi and openocd ready I proceeded to open the scope as documented by others. I initially attempted to remove the warranty sticker using a plastic instrument only. After seeing some label separation I used a heat gun on low heat to soften the glue. It was much easier that way. I highly recommend using heat!

To figure out how to connect the Raspberry Pi GPIO pins to the scope JTAG port I used info from the article above, the scope JTAG information in https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg720691/#msg720691 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg720691/#msg720691), reviewed the sysfsgpio-raspberrypi.cfg interface file and http://pinout.xyz/pinout/uart (http://pinout.xyz/pinout/uart).  Here's what I came up with:

JTAG signal
Scope Header Pin
Pi GPIO Signal
Pi Header Pin
TCK
1
11
23
TMS
3
25
22
TDI
5
10
19
TDO
4
9
21
TRST
7
11
26
Gnd
8
Gnd
25

I used very short cables (~6 inches) and quadrupled checked my connections as I was a bit paranoid about wrecking the scope processor. You should verify yours too  :)

I started openocd using the following command line:

openocd -d2 -f interface/sysfsgpio-raspberrypi.cfg -f target/imx28.cfg

I installed telnet (sudo apt-get install telnet) and connected to openocd using:

telnet localhost 4444

Next turned the scope on. Once I saw the scope options screen I tried to halt the processor from the telnet session (i.e. "halt") but got an error saying that openocd could not communicate with the target.  I checked the scope and it was clearly not stopped.  I turned off the scope, reviewed my wiring. Everything was ok so I reviewed the openocd output and noticed an error in the openocd logging during startup indicating that it couldn't setup events. I surmised that openocd expected to be able to communicate with the target right from the get go so I decided to start the scope first and then start openocd.

That sequence worked and I was able to halt the processor. I did a small (4KB) memory dumps. The contents looked binary so I figured it was probably ok. The download rate was 6KB/s. I tried using various commands I found to turn up the speed (e.g. adapter_khz) but it appeared that those are not implemented by the Raspberry PI GPIO interface. I tried a larger dump of 1MB and found the rate consistent. That meant the required 64MB dump was going to take 3 hours.

I started the dump. As the scope case was not closed I decided to check whether anything was running hot.  The device with a heatsink was running at ~130F so I hooked up a case fan to push air towards it and it cooled to ~90F.  After ~3 hours the dump completed.

I built rigup 0.4.1 for the MSO1000Z using the content at http://gotroot.ca/rigol/rigup-0.4.1-mso1000z.zip (http://gotroot.ca/rigol/rigup-0.4.1-mso1000z.zip). Note that you need to change the makefile replacing "-dead_strip" with "--gc-sections -s".  I used make clean to remove the existing/prebuild objects.  I then used rigup to scan for the various keys.  That worked! Next I generated a key for the triggers option (0x1c001). I double checked the key and input it in the scope. The scope accepted the key -- those options now showed "Official".  I generated the other keys (0x1c002, 0x1c004, 0x1c008 and 0x1c080) and input them.  I made a few mistakes inputting the keys in the scope so some were initially rejected but after correction all were accepted. I restarted after adding the last one (0x1c080 - Bandwidth) and now the scope reported itself as an MSO1104z with all options "Official".

I am thankful for all those who figured out the JTAG pin out, how to get the keys from the dump, wrote rigup.  Thank you also to all who documented their experience to make mine possible -- it's great that this community exists!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Macbeth on June 07, 2016, 10:16:28 pm
Very nice writeup on how you used a Pi to JTAG instead of the usual suspects  ;)

However, I'm not sure your pinouts will work  :-// That's a lot of signals all going to ground on pin 23  ;)
 
JTAG signal
Scope Header Pin
Pi GPIO Signal
Pi Header Pin
TCK
1
11
23
TMS
3
25
23
TDI
5
10
23
TDO
4
9
23
TRST
7
11
23
Gnd
8
11
23
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: arobincaron on June 07, 2016, 11:57:13 pm
However, I'm not sure your pinouts will work  :-// That's a lot of signals all going to ground on pin 23  ;)

:palm:  I corrected the table.

BTW I'm not sure about the scope header connector numbering -- I didn't see a pin 1 designation. The picture in msg 720691 is clear though as to the correct location for each signal.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: whotopia on June 18, 2016, 08:44:59 pm
Can someone help me out to restore the serial number of a DS2072A ?
I tried to do some of the hacks in the distant past and this lead me to a unit with serial number DS2A0000000001.
The MAC address on the LAN interface is also screwed up.  It's 46:46:46:46:46:46.  I assume this must be uniquely generated from the serial number somehow.
The device is currently at firmware DS2000(DSP)Update_00.03.04.01.00

I think if I could get hold of a memory dump from someone with a working unit (and what their serial number is) I could write back correct values into the scope with my own number.   Thanks!

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: progfin on June 26, 2016, 05:23:38 pm
Can someone help me to define options bits for DG1000Z?
Device has Arb16M option - how to enable it?
Thanks!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Noize on August 12, 2016, 01:24:49 pm
I have just bought Rigol MSO1074Z plus. It has operating system 0.4.4.

Does that mean I can't upgrade it with the JTAG method anymore?

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Prax on August 13, 2016, 11:01:35 am
I have just bought Rigol MSO1074Z plus. It has operating system 0.4.4.

Does that mean I can't upgrade it with the JTAG method anymore?

I've made several posts about not being able to unlock the later versions of the MSO1074Z-S. Riglol (gotroot.ca) hasn't been updated to reflect this; nor has there been any discussion aside from me making a fuss.
I suspect something has changed around version 04.03. Even the modified serial generator for the MSO1000 series on Riglol fails to find keys if you don't modify the offset to the new location where the keys are stored. Even after making the modification and generating the keys. I get a verification fail on the key signature.

As it stands, it will take several more new owners of the MSO1000 series before we will begin to see any action. It's unfortunate.

Previous Posts:
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg931770/#msg931770 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg931770/#msg931770)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: qwertymodo on September 16, 2016, 08:29:15 pm
Just bought a MSO1074Z-S, and unfortunately it came with firmware 4.03.SP2.  Board revision is 6.1.2, if that makes any difference.  Obviously, me asking when riglol/rigup will support the new firmware is of no use to anybody, but is there anything I can do that would be helpful at this point?  I haven't managed to grab the memory dump yet, but I do have the tools to do so, and I'll try to get that done this weekend.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on September 17, 2016, 11:52:56 am
What about unlocking the options for the MSO1104Z model? Is there any developments???
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on September 18, 2016, 08:28:27 pm
Is any of these devices suitable to do the memory dump of my Rigol MSO1104Z

http://www.ebay.com/itm/Bus-Blaster-v3-high-speed-JTAG-debugger-FT2232H-high-speed-USB-2-0-DIY-Maker-/302046697470?hash=item465362d7fe:g:GtUAAOSwawpXtVMX (http://www.ebay.com/itm/Bus-Blaster-v3-high-speed-JTAG-debugger-FT2232H-high-speed-USB-2-0-DIY-Maker-/302046697470?hash=item465362d7fe:g:GtUAAOSwawpXtVMX)

or this:

http://www.ebay.com/itm/Bus-Pirate-v3-6-Universal-Serial-Interface-/201191425175?hash=item2ed7f18497:g:afwAAOSwWKtUr3dy (http://www.ebay.com/itm/Bus-Pirate-v3-6-Universal-Serial-Interface-/201191425175?hash=item2ed7f18497:g:afwAAOSwWKtUr3dy)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on September 18, 2016, 08:40:33 pm
Compatible JTAG adapters are listed in message #2413 in this thread or do a search on the main page for "memory dump jtag" ...  :-//
Have a look for the descriptions of the mentioned debuggers and do a comparison.
I dumped the mem in the past with this one: Olimex ARM-USB-OCD-H

Have fun!

Cheers
hammy
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Howardlong on September 19, 2016, 12:20:10 am
Just bought a MSO1074Z-S, and unfortunately it came with firmware 4.03.SP2.  Board revision is 6.1.2, if that makes any difference.  Obviously, me asking when riglol/rigup will support the new firmware is of no use to anybody, but is there anything I can do that would be helpful at this point?  I haven't managed to grab the memory dump yet, but I do have the tools to do so, and I'll try to get that done this weekend.

It's definitely worth doing, I have the same model, it's my go-to field scope. It just takes a little patience, and care with the warranty sticker.

My main negatives are the screen-only serial decodes, cluttered screen and slow UI, but for the money I'm certainly not going to complain, it gets the job done in a very compact and usable package
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: qwertymodo on September 19, 2016, 07:01:29 am
I have my memory dumps if they are of any use to anybody with the know-how to work toward updating rigup. There was a message somewhere earlier in this thread where somebody claimed to have gotten working licenses on 4.03.SP1 by dumping the memory while the Rigol logo was on-screen, so I took one then too.

I'm willing to do anything else that might be useful. I already have a DS1054Z fully unlocked, so I'm not in any huge rush (though I would like to sell the '54 once I get the MSO unlocked).

Sent from my m8wl using Tapatalk

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on September 19, 2016, 07:59:19 am
Just bought a MSO1074Z-S, and unfortunately it came with firmware 4.03.SP2.  Board revision is 6.1.2, if that makes any difference.  Obviously, me asking when riglol/rigup will support the new firmware is of no use to anybody, but is there anything I can do that would be helpful at this point?  I haven't managed to grab the memory dump yet, but I do have the tools to do so, and I'll try to get that done this weekend.

It's definitely worth doing, I have the same model, it's my go-to field scope. It just takes a little patience, and care with the warranty sticker.

My main negatives are the screen-only serial decodes, cluttered screen and slow UI, but for the money I'm certainly not going to complain, it gets the job done in a very compact and usable package

Are you sure the list of compatible JTAG adapters are in message #2413??? On page 97??? I found that message but it has no list of JTAG adapters. Anyway, I'm trying to find something cheaper than the Olimex LTD ARM-USB-OCD-H . This is quite expensive!

I was thinking about this one which is a lot cheaper:
http://dangerousprototypes.com/docs/Bus_Pirate_v3.6 (http://dangerousprototypes.com/docs/Bus_Pirate_v3.6)

Is this one suitable for this job?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on September 19, 2016, 10:12:43 am
Are you sure the list of compatible JTAG adapters are in message #2413??? On page 97??? I found that message but it has no list of JTAG adapters.

Yes, I'm sure, it was the first message from buergi: "Reply #2413 on: 11-01-2014, 18:59:55"
There are also several other messages in this thread from various people with various jtag adapters. Just do a search inside this thread.
Or do it the other way around. You found a cheap adapter? Search the forum if someone used this model before.

Cheers
hammy
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on September 19, 2016, 10:30:19 am
Are you sure the list of compatible JTAG adapters are in message #2413??? On page 97??? I found that message but it has no list of JTAG adapters.

Yes, I'm sure, it was the first message from buergi: "Reply #2413 on: 11-01-2014, 18:59:55"
There are also several other messages in this thread from various people with various jtag adapters. Just do a search inside this thread.
Or do it the other way around. You found a cheap adapter? Search the forum if someone used this model before.

Cheers
hammy

This is what I find in this thread at pos #2413. But I'll search by the date!
See attachment
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on September 19, 2016, 10:37:24 am
That's strange!  :-// I'm sorry.  :scared: The message from your screenshot is #2414 for me.

BTW there was someone in this thread using a BusPirate - if I remember correct - and it took him hours to extract the dump. But I'm not sure.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on September 19, 2016, 10:42:53 am
That's strange!  :-// I'm sorry.  :scared: The message from your screenshot is #2414 for me.

Yes quite weird... Though, you have nothing to sorry... It's not your fault! ;)

Anyway, I think I get the post you mentioned!

I suppose you mean this one:
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg365951/#msg365951 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg365951/#msg365951)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on September 19, 2016, 11:03:46 am
Yes!  :-+
There are some adapters mentioned, used by member of this forum.
And there is a link inside this message for a general list: http://urjtag.org/book/_system_requirements.html#_supported_jtag_adapters_cables (http://urjtag.org/book/_system_requirements.html#_supported_jtag_adapters_cables)
And there was this guy, using a raspi: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg955873/?topicseen#msg955873 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg955873/?topicseen#msg955873)
Here we are, a BusPirate: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg585831/?topicseen#msg585831 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg585831/?topicseen#msg585831)

It's all inside this thread ...

Have fun! Good luck!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: McBryce on September 19, 2016, 11:20:37 am
The cheapest I've found that works are these Chinese J-Link knock-offs: http://www.ebay.de/itm/ARM7-ARM9-ARM11-J-link-V8-ARM-Emulator-Cortex-M3-ADS-IAR-STM32-JTAG-Interface-/272345346913 (http://www.ebay.de/itm/ARM7-ARM9-ARM11-J-link-V8-ARM-Emulator-Cortex-M3-ADS-IAR-STM32-JTAG-Interface-/272345346913)
Work fine, just remember to click "no" if the J-Link software offers to upgrade the firmware.

McBryce.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on September 19, 2016, 11:24:19 am
Looks like Bus Pirate is really slow! And all the devices stated around here are quite expensive!

I would like some help to try to figure out if some other devices are likely to work. For instance, would any of this work:

http://www.ebay.com/itm/FPU1-FTDI-FT2232-USB-JTAG-XILINX-FPGA-CPLD-programmer-cable-/181635528314?hash=item2a4a52367a:g:tJMAAOSwygJXgP4d (http://www.ebay.com/itm/FPU1-FTDI-FT2232-USB-JTAG-XILINX-FPGA-CPLD-programmer-cable-/181635528314?hash=item2a4a52367a:g:tJMAAOSwygJXgP4d)

http://www.ebay.com/itm/FT2232-USB-DIP-module-for-FTDI-FT2232D-dual-UART-FIFO-JTAG-SPI-/162159976456?hash=item25c17ce008:g:JesAAOSwwpdW4SrL (http://www.ebay.com/itm/FT2232-USB-DIP-module-for-FTDI-FT2232D-dual-UART-FIFO-JTAG-SPI-/162159976456?hash=item25c17ce008:g:JesAAOSwwpdW4SrL)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on September 19, 2016, 11:26:25 am
The cheapest I've found that works are these Chinese J-Link knock-offs: http://www.ebay.de/itm/ARM7-ARM9-ARM11-J-link-V8-ARM-Emulator-Cortex-M3-ADS-IAR-STM32-JTAG-Interface-/272345346913 (http://www.ebay.de/itm/ARM7-ARM9-ARM11-J-link-V8-ARM-Emulator-Cortex-M3-ADS-IAR-STM32-JTAG-Interface-/272345346913)
Work fine, just remember to click "no" if the J-Link software offers to upgrade the firmware.

McBryce.

Well, that is an affordable one indeed!!! If I find no one else, I'll purchase that one!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: McBryce on September 19, 2016, 11:28:43 am
Yup (I assume you meant to quote my post?). I've been using it quite a bit since I bought it about 2 years ago and it's never given problems yet.

McBryce.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on September 19, 2016, 11:31:27 am
Yup (I assume you meant to quote my post?). I've been using it quite a bit since I bought it about 2 years ago and it's never given problems yet.

McBryce.

Yes I meant to quote your post! :p

That's good news...

And is there any way of knowing how much time these devices takes to perform the memory dump?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: McBryce on September 19, 2016, 11:38:13 am
It's been a while since I dumped the memory from my MSO1104Z-S, but I think it took about 6 minutes. I used the "Speed 6000" command first of course, otherwise it uses some snail-paced default that takes forever.

Here's a post where someone else used exactly the same method, with full instructions on what to do: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg599846/#msg599846 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg599846/#msg599846)

McBryce.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on September 19, 2016, 12:44:06 pm
It's been a while since I dumped the memory from my MSO1104Z-S, but I think it took about 6 minutes. I used the "Speed 6000" command first of course, otherwise it uses some snail-paced default that takes forever.

Here's a post where someone else used exactly the same method, with full instructions on what to do: https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg599846/#msg599846 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg599846/#msg599846)

McBryce.

Nice... I'm going to order one of those and when I get it, I'll ask for help here if I need!
Also need to save these links that will be of great help when I'm about to perform the memory dump!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on September 19, 2016, 01:42:21 pm
I just bought the named device (ARM7 ARM9 ARM11 J link V8 ARM Emulator Cortex-M3 ADS IAR STM32 JTAG Interface)! Now, it's a desperation wait!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: qwertymodo on September 19, 2016, 06:31:58 pm
I used a Raspberry Pi, as described a few pages back.  However, I used the native config, which is a lot faster on the GPIO's than the generic config.  Still took 45 minutes, but that's better than 3 hours.

Edit: I just successfully generated a license for my MS01074S on firmware 4.03.SP2 using rigup 0.4.1-mso1000z.  Based on a previous comment earlier in this thread that I can't seem to find now, it might make a difference when you start the memory dump relative to the boot time.  The dump that I used that worked was halted almost immediately upon the options dialog appearing (immediately after the Rigol logo disappears).  I used option CSGY = 0x1C0DF to generate the license for everything except the 5uV, and that worked.

(http://i.imgur.com/VeAGQh2l.jpg) (http://i.imgur.com/VeAGQh2.jpg)
(http://i.imgur.com/yPS9vzxl.jpg) (http://i.imgur.com/yPS9vzx.jpg)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on September 20, 2016, 07:50:15 am
Has anyone managed to unlock the features of any MSO using the latest firmware?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: qwertymodo on September 20, 2016, 04:15:00 pm
I'm not sure what the latest firmware version is, but I just did on the 1074 I bought just a week ago, which came from the factory with 4.0.3.SP2.

Sent from my m8wl using Tapatalk

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on September 20, 2016, 09:55:04 pm
I'm not sure what the latest firmware version is, but I just did on the 1074 I bought just a week ago, which came from the factory with 4.0.3.SP2.

Sent from my m8wl using Tapatalk

I also have that same version of firmware and this last week I requested the latest firmware update and that version was the one they sent me!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: qwertymodo on September 20, 2016, 10:02:29 pm
Ok, then yes, fully unlocked MSO1074Z-S on the latest firmware.

Sent from my m8wl using Tapatalk

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on September 20, 2016, 10:37:21 pm
@qwertymodo
@psysc0rpi0n
It doesn't make a difference, but the latest firmware version is "00.04.04.00.07" from July 26, 2016.
The official download page for the MSO/DS1000z is http://int.rigol.com/Product/Index/4 (http://int.rigol.com/Product/Index/4)
The mentioned firmware shows up in system info with "00.04.04.SP1"

Cheers
hammy
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on September 20, 2016, 11:12:34 pm
@qwertymodo
@psysc0rpi0n
It doesn't make a difference, but the latest firmware version is "00.04.04.00.07" from July 26, 2016.
The official download page for the MSO/DS1000z is http://int.rigol.com/Product/Index/4 (http://int.rigol.com/Product/Index/4)
The mentioned firmware shows up in system info with "00.04.04.SP1"

Cheers
hammy

Ok, I misread the version they sent me in 17/09/2016 which in fact was DS1000Z(ARM)Update_00_04_04_00_07.
So this means that an update already came out after my request, I suppose!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: qwertymodo on September 20, 2016, 11:44:36 pm
Well, in that case, I have no idea if you can dump the keys on 4.04.SP1.  However, I CAN confirm that licenses installed on 4.03.SP2 survive the upgrade to 4.04.SP1 just fine.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on September 21, 2016, 07:40:57 am
Well, in that case, I have no idea if you can dump the keys on 4.04.SP1.  However, I CAN confirm that licenses installed on 4.03.SP2 survive the upgrade to 4.04.SP1 just fine.

The version firmware version I actually have is 4.03.SP2 because when I received the last update I requested (which was 00.04.04.00.07), I thought it was the same as the one in the scope so I didn't upgrade it!

But once more, I didn't know another piece of information. 00.04.04.00.07 shows up in System Info as 00.04.04.SP1. So, I still don't have the latest firmware!

And is it possible to downgrade firmware???
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: McBryce on September 21, 2016, 08:05:44 am
Downgrading isn't possible.

McBryce.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: qwertymodo on September 21, 2016, 08:15:16 am
4.04.00.07 is the same as 4.04.SP1, that's just how it's displayed in the menu vs how the file is named in the download package. And looking at the site, that is the latest version.

Also, no downgrading.

Sent from my m8wl using Tapatalk

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on September 21, 2016, 08:22:43 am
Ok, so as I have the 4.0.3.SP2, I hope to be able to successfully dump the memory and generate the correct keys!

And if I accomplish it successfully, can I later upgrade the firmware without loosing the licenses, Is that what you meant by "surviving the upgrade"?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: qwertymodo on September 21, 2016, 08:27:13 am
When you go to do the memory dump, try to halt the scope immediately after the Rigol logo disappears, that's what worked for me.

And yes, I upgraded my scope to 4.04 after installing the keys, and they're all still installed.

Sent from my m8wl using Tapatalk

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on September 21, 2016, 08:35:24 am
When you go to do the memory dump, try to halt the scope immediately after the Rigol logo disappears, that's what worked for me.

And yes, I upgraded my scope to 4.04 after installing the keys, and they're all still installed.

Sent from my m8wl using Tapatalk

Ah yes, that was one other question I would like to ask about the correct timing to dump the memory...
When you guys say to halt the scope immediately after the Rigol logo disappears, I' not sure when does this happens! Is when I turn on the scope or do I need to do anything on the scope to make the logo appear and then disappear?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: qwertymodo on September 21, 2016, 08:44:30 am
It halts when you send the halt command to openocd. Basically, you turn on the scope, then start openocd, then you send commands to openocd (or if you set up an openocd.cfg file, it will execute the commands in the config file when you run it, so it's useful to put the halt command in the config file). You want to execute the halt command immediately after the logo disappears and the options menu appears, showing you how long you have left on the trial features.

My suspicion is that they added code that after it checks the status of the licenses, it clears the keys from memory, so if you let the scope sit idle for awhile, when you do the memory dump, you won't be able to generate licenses from it, but if you take the memory dump right away as soon as that screen comes up, it won't have run that cleanup code yet and the memory dump will be useable. That's just speculation on my part, but it seems like a reasonable enough theory.

Sent from my m8wl using Tapatalk

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on September 21, 2016, 10:14:00 am
It halts when you send the halt command to openocd. Basically, you turn on the scope, then start openocd, then you send commands to openocd (or if you set up an openocd.cfg file, it will execute the commands in the config file when you run it, so it's useful to put the halt command in the config file). You want to execute the halt command immediately after the logo disappears and the options menu appears, showing you how long you have left on the trial features.

My suspicion is that they added code that after it checks the status of the licenses, it clears the keys from memory, so if you let the scope sit idle for awhile, when you do the memory dump, you won't be able to generate licenses from it, but if you take the memory dump right away as soon as that screen comes up, it won't have run that cleanup code yet and the memory dump will be useable. That's just speculation on my part, but it seems like a reasonable enough theory.

Sent from my m8wl using Tapatalk

Hum, something is worrying me now! You say that the right timing is when the logo goes away and the screen with the trial options left time comes up with the remaining time! But I think my scope is not showing that screen anymore because all the remaining time is already gone! So I have all those options already expired! I remember that screen appears on all boots but before the remaining times are out!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: qwertymodo on September 21, 2016, 05:11:03 pm
That's probably still fine.  Another guy earlier in the thread was successful with his memory dump taken while the Rigol logo was still on screen, so the timing isn't super exact.  I tried doing it then, but wasn't successful, I probably tried too early.  In any case, it's probably going to be a matter of trial and error at this point, unless somebody can disassemble the firmware and determine exactly where to set a breakpoint.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on September 22, 2016, 07:06:29 am
That's probably still fine.  Another guy earlier in the thread was successful with his memory dump taken while the Rigol logo was still on screen, so the timing isn't super exact.  I tried doing it then, but wasn't successful, I probably tried too early.  In any case, it's probably going to be a matter of trial and error at this point, unless somebody can disassemble the firmware and determine exactly where to set a breakpoint.

Ok, I hope I can still be in the game!
I'm not sure if anyone besides McBryce was able to dump it. The guy you say had an MSO or a DSO? I have an MSO1104Z. I've not being paying attention to what exactly are the models of scopes that people have been successful dumping the memory.

I wouldn't mind to learn how to do the firmware disassemble but obviously it's not an easy job, so probably I'm useless to that purpose unless someone wants to work with me! I'm also feeling that the MSO series, namely the 1000 series, are not widely spread among users, so probably not many people having one!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: qwertymodo on September 22, 2016, 07:15:56 am
The guy I was referring to had the same model as me, MSO1074Z (not sure if his was -S or not), sorry I can't find the post. The DS1000 series doesn't require a memory dump, all you need is the serial number.

Sent from my m8wl using Tapatalk

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on September 22, 2016, 07:52:15 am
The guy I was referring to had the same model as me, MSO1074Z (not sure if his was -S or not), sorry I can't find the post. The DS1000 series doesn't require a memory dump, all you need is the serial number.

Sent from my m8wl using Tapatalk

Yeah, hope I can do the same for the MSO1104Z. I think the only guy that has the same model has me was McBryce but I think he used an earlier version of the firmware than the one I have!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: McBryce on September 22, 2016, 09:30:40 am
Yup mine is an MSO1104Z-S and had a much older Firmware installed when I did the memory dump. I didn't have to worry about getting the timing correct.

McBryce.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on September 22, 2016, 09:40:42 am
Yup mine is an MSO1104Z-S and had a much older Firmware installed when I did the memory dump. I didn't have to worry about getting the timing correct.

McBryce.

McBryce, these 2 models, MSO1104Z and MSO1104Z-S, are probably not the case that they are precisely the same, regarding hardware, but one of them has firmware limitation, right?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: McBryce on September 22, 2016, 10:14:47 am
The "S" has an additional PCB as far as I can remember from Daves teardown. The Firmware is the same for all DSO1xxx and MSO1xxx as far as I know.

McBryce.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: qwertymodo on September 22, 2016, 05:03:28 pm
Correct, there is an additional hardware board inside the -S model for the signal generator DAC hardware, but they are running the same firmware.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on September 23, 2016, 11:42:17 am
There is NEW Firmware available now for the MSO/DS1000Z Oscilloscopes
FW Version: 00.04.04.01.01
Released: 2016/09/14
 o  Added support for the multi-inteface of LXI
 o  Fixed bugs with Auto-Measurement functions

http://int.rigol.com/File/ProductSoftWare/20160914/DS1000Z(ARM)update.rar (http://int.rigol.com/File/ProductSoftWare/20160914/DS1000Z(ARM)update.rar)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on September 23, 2016, 05:29:30 pm
Just for curiosity...

Will I get anything from the scope's JTAG port if I connect there a Logic Analyser?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on September 23, 2016, 06:36:45 pm
Ok, but the Logic Analyser won't be able to pick up anything there?

Sent from my GT-I9505 using Tapatalk

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: qwertymodo on September 23, 2016, 06:47:30 pm
If you mean that you want to connect a logic analyzer to sniff the JTAG port, sure you could do that, but what would be the point?  All you would see is a logic analyzer dump of the JTAG activity.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on September 23, 2016, 07:24:54 pm
If you mean that you want to connect a logic analyzer to sniff the JTAG port, sure you could do that, but what would be the point?  All you would see is a logic analyzer dump of the JTAG activity.

Yes, that's it! Well, I know I'll only get a bunch of 0's and 1's of maybe different frequencies... It was just for the fun! But I'm not sure how should I configure the Logic Analyser! Like what sample rate to choose and how many samples to collect, and that kind of stuff!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: qwertymodo on September 23, 2016, 07:38:47 pm
That depends entirely on how fast you set your JTAG dongle to communicate.  You need the LA to be set to at least twice as fast as the JTAG bit rate, ideally more like 4-8x, and then number of samples really comes down to the memory limitations and how much data you want to sift through.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on September 23, 2016, 07:43:07 pm
That depends entirely on how fast you set your JTAG dongle to communicate.  You need the LA to be set to at least twice as fast as the JTAG bit rate, ideally more like 4-8x, and then number of samples really comes down to the memory limitations and how much data you want to sift through.

And how do I know JTAG speed? Where do I set it?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: qwertymodo on September 23, 2016, 07:48:26 pm
There's an openocd command for setting the speed.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on September 23, 2016, 07:59:17 pm
There's an openocd command for setting the speed.

But can I use my Logic Analyser to set the speed of JTAG or if I use J_Link/OpenOCD and run it, will it detect the JTAG and be able to set the speed? Sorry, I'm just starting with this! It's the first time I deal with JTAG!

I have some doubts about how to connect the LA to the JTAG header.
I have this clone of Saleae Logic:
http://www.ebay.co.uk/itm/USB-saleae-Logic-Analyzer-Device-Set-USB-Cable-24MHz-8CH-24MHz-MCU-ARM-FPGA-/141694353386 (http://www.ebay.co.uk/itm/USB-saleae-Logic-Analyzer-Device-Set-USB-Cable-24MHz-8CH-24MHz-MCU-ARM-FPGA-/141694353386)

It has 8 channels plus 2 GNDs.
I connected it like this:

Channel 0 --- TCK
Channel 1 --- TMS
Channel 2 --- TDI
Channel 3 --- TRST
Channel 4 --- 3V3/VREF (probably not needed)
Channel 5 --- TDO
Channel 6 --- SRST
Channel 7 --- Not Connected
Channel 8 --- GND
Channel 9 --- GND

But in the software, the SRST is not detected as the others are with the name of each pin. I'm not sure if it's normal...
Here is a picture of Saleae Logic Software:
(http://i.imgur.com/caBAt4g.png)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: qwertymodo on September 23, 2016, 08:29:15 pm
The logic analyser won't control anything, it's just a passive listener, you need a jtag dongle compatible with openocd, which will control the actual jtag communication.

Sent from my m8wl using Tapatalk

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on September 23, 2016, 08:33:32 pm
The logic analyser won't control anything, it's just a passive listener, you need a jtag dongle compatible with openocd, which will control the actual jtag communication.

Sent from my m8wl using Tapatalk

Yes, I understood that since the other post you said the only thing I could see with the LA was a dump of the JTAG port activity. And it's exactly that I was trying to see but I'm not sure of how the setp should be done in Saleae Logic software to be able to pick up the JTAG port activity...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: qwertymodo on September 23, 2016, 10:58:54 pm
You don't need to connect SRST, that's for resetting the host system.  The logic analyzer just needs TRST to reset the internal JTAG state machine.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on September 24, 2016, 01:08:40 am
What about TDI and  TDO?

Sent from my GT-I9505 using Tapatalk

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on September 25, 2016, 01:37:48 am
Looks like I managed to use an Arduino to get some info from the JTAG of my scope!

I'm not sure if I can do anything else but I used a library available here (https://github.com/sowbug/JTAGWhisperer) I managed to pick up some bits of info, using "minicom" or the serial monitor of Arduino:

At boot time, I try to interrogate the JTAG interface to find all the connected devices (chips). It lists their built-in identification codes which take the form of 32 bits in four groups,and i get this:

03c93279  [0000 0011110010010011 00100111100 1]

Quote from: http://www.khjk.org/log/2013/aug.html
The groups are, from most to least significant bit: 4-bit product version (0), 16-bit product code (3c93), 11-bit manufacturer code (279), and one bit that is always 1 for thaumaturgic reasons.

After the boot, if I interrogate the JTAG interface again, I get different results:

079264f3  [0000 0111100100100110 01001111001 1]

Does this means that there are at least 2 memories being used by the scope?


Edited;
I need to make a correction...
No matter what, the first time I interrogate the JTAG interface, I get the 03c93279 code, and the second time I interrogate it, I get 079264f3. Then if I try again, I always get the 079264f3 code.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Pinkus on September 27, 2016, 09:21:26 am
Hello
If someone can read the spi flash 25x40 of dp832a; I can try to turn my 832 into 832a, because fw is same.
Also other option is a full cloning spi flash + nand flash from 832a to manually program in a 832.
I know, the above it is quite old, but did rsivan or somebody else tried this?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on September 30, 2016, 05:24:41 pm
Is it need anything special to connect the J-Link device to the PC?? (I'm using Debian Jessie). I can't make J-Link software to connect with the device.

After connected the device to the USB port, if I start the software only with "./JLinkEXE" I get this error:

Code: [Select]
SEGGER J-Link Commander V6.10a (Compiled Sep 19 2016 20:08:32)
DLL version V6.10a, compiled Sep 19 2016 20:08:23

Connecting to J-Link via USB...FAILED: Can not connect to J-Link via USB.

If I use sudo prior to the launch I get this error:

Code: [Select]
SEGGER J-Link Commander V6.10a (Compiled Sep 19 2016 20:08:32)
DLL version V6.10a, compiled Sep 19 2016 20:08:23

Connecting to J-Link via USB...

*** J-Link V6.10a Error ***
The connected emulator can not be used with this software.

Reason:
"Broken. No longer used"
*** J-Link V6.10a Error ***

FAILED: Can not connect to J-Link via USB.

What is wrong???
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: McBryce on September 30, 2016, 07:44:14 pm
The first error is due to the user permissions being set wrong for USB. Not sure about the second sudo error. Do you have a Windows PC that you could try?

McBryce.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on September 30, 2016, 08:57:03 pm
I'm now checking and redoing the wiring but I have a question about the pin out of the J-Link device. I'm following J-Link site to plug some wires, but I'm used to see around the internet the following:

TCK, TMS, TDI, TRST, TDO and SRST

The J-Link site has:
TDI, TMS, TCK, RTCK, TDO and RESET.

I'm wondering which one, RTCK or RESET, matches the SRST...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on September 30, 2016, 09:20:51 pm
Ok, I got it...

SRST is RESET I guess...

Anyway I issued the following command

Code: [Select]
sudo openocd -d1  -f  interface/jlink.cfg -c "transport select jtag" -c "adapter_khz 6000" -f board/imx28evk.cfg -l ~/openocd_log
and the first time I got this:
Code: [Select]
Open On-Chip Debugger 0.9.0 (2016-09-30-19:43)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Error: Invalid command argument
new_level option value ('l') is not valid

jtag
adapter speed: 6000 kHz
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
dcc downloads are enabled
imx28evk_init
Info : J-Link ARM V8 compiled Nov 28 2014 13:44:46
Info : J-Link caps 0xb9ff7bbf
Info : J-Link hw version 80000
Info : J-Link hw type J-Link
Info : J-Link max mem block 9224
Info : J-Link configuration
Info : USB-Address: 0x0
Info : Kickstart power on JTAG-pin 19: 0xffffffff
Info : Vref = 3.448 TCK = 1 TDI = 1 TDO = 0 TMS = 1 SRST = 1 TRST = 1
Info : J-Link JTAG Interface ready
Info : clock speed 6000 kHz
Info : JTAG tap: imx28.cpu tap/device found: 0x079264f3 (mfg: 0x279, part: 0x7926, ver: 0x0)
Info : Embedded ICE version 6
Info : imx28.cpu: hardware has 2 breakpoint/watchpoint units
Info : accepting 'telnet' connection on tcp/4444


I mistyped -dl instead of -d1... Then I did the telnet connection and it worked!

Then I trid again the connection but added a new option, to save the output log of openOCD like this:

Code: [Select]
sudo openocd -d1  -f  interface/jlink.cfg -c "transport select jtag" -c "adapter_khz 6000" -f board/imx28evk.cfg -l ~/openocd_log
and I got this:

Code: [Select]
Open On-Chip Debugger 0.9.0 (2016-09-30-19:43)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 1

I hope this is OK...

Now I'm going foe the telnet connection again...

But before I want to ask another question:
What I'm doing is just a memory dump, right? Is this anyway dangerous to the scope? Can I brick the scope?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on September 30, 2016, 09:47:36 pm
I tried to halt the scope a few seconds after powering it up while the Rigol logo is still on the screen but I always get "time out"...
When I issue the "reset" command i get this:

Code: [Select]
Error: IR capture error at bit 4, saw 0x21 not 0x...3
Warn : Bypassing JTAG setup events due to errors
Warn : ThumbEE -- incomplete support
Error: cp15 read operation timed out
in procedure 'reset'
in procedure 'ocd_bouncer'
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on October 01, 2016, 12:59:45 am
Well, I was able to do the memory dump and generate the license keys but none was valid until I was banned of installing licenses for 12 hours! And I did 2 memory dumps. The first one didn't found any keys!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: McBryce on October 01, 2016, 09:45:49 am
And you're definitely using the MSO version of riglol not the standard version?

McBryce.

Gesendet von meinem Motorola DynaTEC 8000X mit Tapatalk.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on October 01, 2016, 09:55:12 am
And you're definitely using the MSO version of riglol not the standard version?

McBryce.

Gesendet von meinem Motorola DynaTEC 8000X mit Tapatalk.

Yes, I used this one:
http://www.gotroot.ca/rigol/rigup-0.4.1-mso1000z.zip (http://www.gotroot.ca/rigol/rigup-0.4.1-mso1000z.zip)

There are patches in the same folder but I don't know if I should use them or even how to apply them.
http://www.gotroot.ca/rigol/mso1000z-patches.zip (http://www.gotroot.ca/rigol/mso1000z-patches.zip)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: qwertymodo on October 02, 2016, 12:59:29 am
I was successful using rigup-0.4.1-mso1000z exactly as it was provided in that package (no patches), using a memory dump taken immediately after the Rigol logo disappeared and the options dialog appeared on screen, using option code 0x1C0DF for a single license to unlock everything except the non-functional 5uV option (so you only have to type in one code). Give that a try.

Sent from my m8wl using Tapatalk
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on October 02, 2016, 02:17:30 am
I was successful using rigup-0.4.1-mso1000z exactly as it was provided in that package (no patches), using a memory dump taken immediately after the Rigol logo disappeared and the options dialog appeared on screen, using option code 0x1C0DF for a single license to unlock everything except the non-functional 5uV option (so you only have to type in one code). Give that a try.

Sent from my m8wl using Tapatalk

Ok, but when I power on my scope, I don't see anymore the options window because the trial time is already over, so I'm not sure when I should issue the halt! But I'll try that hex code with rigup!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: qwertymodo on October 02, 2016, 02:21:21 am
Just do it right after the Rigol logo disappears.

Sent from my m8wl using Tapatalk

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on October 02, 2016, 02:25:36 am
Just do it right after the Rigol logo disappears.

Sent from my m8wl using Tapatalk

Ok. In the mwantime, I generated a license key for that code but it didn't worked either! Now, for each wrong key inserted, I got blocked for 12 hours!

Tomorrow I'll try to do that dump right after the logo disappear! Today is already too late! My dump takes about 30 minutes. It's 67MB at about 47KB/s. I set the speed to 6MHz but it's slow as this!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on October 02, 2016, 03:09:49 pm
I have tried once more but no good... The memory dump is successful but the keys are invalid! I think my hope has now ended!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Daruosha on October 15, 2016, 05:25:27 pm
I've bought a new MSO1104Z  and silly me upgraded to latest version immediately when I got home.

I have no experience with JTAG yet and ordered a knock off Altera USB blaster to follow memory dump instructions. However I'm not sure with the new version, extraction of private keys from memory dump will be successful at all.

psysc0rpi0n, do you have any news?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: pascal_sweden on October 15, 2016, 05:52:54 pm
I see you are based in Sweden. Did you buy from InstrumentCenter AB?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on October 15, 2016, 05:55:22 pm
The memory dump is successful but the keys are invalid! I think my hope has now ended!

You doublechecked the other side? Is your compiled binary from "[url´=http://gotroot.ca/rigol/rigup-0.4.1-mso1000z.zip]rigup-0.4.1-mso1000z[/url]" ok?
You tried also the provided binary (http://gotroot.ca/rigol/rigup-0.4.1-x86_64-linux.gz)?

I created my keys in December 2014 and I compiled the binary on my RasPi running raspian (https://www.raspbian.org/). My firmware version was 00.04.01.SP2.

What I read here ist querymodo was able to create the keys (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg1039228/#msg1039228). Maybe something in your procedure is not working the right way. If you are sure about the dump, please check the other end of your workchain, aka the binary you compiled.

Good luck!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on October 15, 2016, 05:59:09 pm
The memory dump is successful but the keys are invalid! I think my hope has now ended!

You doublechecked the other side? Is your compiled binary from "[url´=http://gotroot.ca/rigol/rigup-0.4.1-mso1000z.zip]rigup-0.4.1-mso1000z[/url]" ok?
You tried also the provided binary (http://gotroot.ca/rigol/rigup-0.4.1-x86_64-linux.gz)?

I created my keys in December 2014 and I compiled the binary on my RasPi running raspian (https://www.raspbian.org/). My firmware version was 00.04.01.SP2.

What I read here ist querymodo was able to create the keys (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg1039228/#msg1039228). Maybe something in your procedure is not working the right way. If you are sure about the dump, please check the other end of your workchain, aka the binary you compiled.

Good luck!

What can I do to check if the binary is correctly compiled? I think I didn't need to compile anything. The binary was ready-to-use, I guess!

The binary link for 64bit is not working... Or better, the file can't extract... It returns an error!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on October 15, 2016, 06:04:52 pm
I think I didn't need to compile anything. The binary was ready-to-use, I guess!

Ok, I see. This means you had used the provided binary for the key generation, right?

Do you asked someone, maybe querymondo, to generate you keys? Obviously he was able to generate the license-keys.

If you transfer your dump to another person who already generated working license-keys, maybe this person could generate your license keys as well.

Can you provide your dump via a download link?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on October 15, 2016, 06:07:38 pm
I think I didn't need to compile anything. The binary was ready-to-use, I guess!

Ok, I see. This means you had used the provided binary for the key generation, right?

Do you asked someone, maybe querymondo, to generate you keys? Obviously he was able to gernerate the license-keys.

If you transfer your dump to another person who already generated working license-keys, maybe this person could generate your license keys as well.

Can you provide your dump via a download link?

I haven't asked anyone to generate license keys. If anyone is kind enough to do that, I can provide a link to my memory dump!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on October 15, 2016, 06:13:16 pm
I haven't asked anyone to generate license keys. If anyone is kind enough to do that, I can provide a link to my memory dump!

Excellent!  :-+ Please prepare that link.
Ok, I reinstalled my raspi some time ago, but I can setup this stuff again. I get in touch with you tomorrow via pm ...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on October 15, 2016, 06:18:02 pm
I haven't asked anyone to generate license keys. If anyone is kind enough to do that, I can provide a link to my memory dump!

Excellent!  :-+ Please prepare that link.
Ok, I reinstalled my raspi some time ago, but I can setup this stuff again. I get in touch with you tomorrow via pm ...

Many thanks... The link is ready. Let me tell you that I was able to generate the keys but none was accepted by the scope! Not sure if this changes anything!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on October 15, 2016, 10:14:48 pm
I tried to generate license-keys for psysc0rpi0n. Unfortunately they are not valid.  :-//
Is anyone out there who was successful to generate these license-keys with a recent MSO? Maybe anyone would be so kind to give it a try with psysc0rpi0n's dump?

Cheers
hammy

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: qwertymodo on October 15, 2016, 10:32:19 pm
The problem is likely with the dump itself. As I stated before, my suspicion is that they added code to clear the memory after verifying the installed keys, which is why the timing of the dump affects the results (you need to halt the scope after the keys are loaded but before they are cleared). If that is the case, it's not going to matter how many people try with the same dump, because the dump itself is no good.

Sent from my m8wl using Tapatalk

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on October 16, 2016, 12:22:32 am
The problem is likely with the dump itself. As I stated before, my suspicion is that they added code to clear the memory after verifying the installed keys, which is why the timing of the dump affects the results (you need to halt the scope after the keys are loaded but before they are cleared). If that is the case, it's not going to matter how many people try with the same dump, because the dump itself is no good.

Sent from my m8wl using Tapatalk
And is that timing known? The dump I have was taken right after the Rigol logo disappear...  Was this the timing you talked about?
If I try to take the dump at any other timing, rigol tool will find no keys...

Sent from my GT-I9505 using Tapatalk
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: qwertymodo on October 16, 2016, 01:21:04 am
No, the timing is not known, and I'm only guessing about that even being how it works. Sorry.

Sent from my m8wl using Tapatalk

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Edinson on October 16, 2016, 11:33:49 am
Hi,
I am struggling to get the memory dump of my DS1074Z Plus.
I am using an Olimex ARM-USB-OCD-H Adapter with OpenOCD in a Win7 32bit VM. I am not able to halt the CPU as I get the following error message. Has anyone an idea how to solve it.

Thanks in Advance
Edi


Code: [Select]
C:\>c:\Rigol\openocd-0.9.0\bin\openocd.exe -f c:\Rigol\Olimex.cfg
Open On-Chip Debugger 0.8.0 (2014-04-28-08:39)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_de
assert_srst
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
dcc downloads are enabled
adapter speed: 6000 kHz
Info : clock speed 6000 kHz
Info : JTAG tap: imx28.cpu tap/device found: 0x079264f3 (mfg: 0x279, part: 0x792
6, ver: 0x0)
Info : Embedded ICE version 15
Error: unknown EmbeddedICE version (comms ctrl: 0xfffffffe)
Info : imx28.cpu: hardware has 2 breakpoint/watchpoint units
Info : accepting 'telnet' connection from 4444
Info : Halt timed out, wake up GDB.
Error: timed out while waiting for target halted
in procedure 'halt'

The Olimex.cfg file is
Code: [Select]
source [find interface/ftdi/olimex-arm-usb-ocd-h.cfg]
source [find target/imx28.cfg]
adapter_khz 6000


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Strada916 on October 16, 2016, 11:36:33 am
Edinson. Pretty sure you don't need to do a memory dump on ds1074 just use the generator.

Sent from my SM-G925I using Tapatalk
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Edinson on October 16, 2016, 11:58:51 am
It's the Plus-Version with MSO-Option, so I guess I need to do the memory dump.
I tried the kexgen before, it didn't work.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Strada916 on October 16, 2016, 12:03:30 pm
Ok soz

Sent from my SM-G925I using Tapatalk

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Edinson on October 16, 2016, 01:18:51 pm
I tried with OCD 0.8 and 0.9 and different config files for the adapter (exchanging) the configs of OCD0.8 and 0.9 as well. Driver were installed using Zadig. Nothing worked.  :(
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Edinson on October 16, 2016, 03:50:53 pm
Peter, thank you for your support.

The connection is basically the same as mine. I had additionally connected the SRS: Scope 6 - Olimex 15.
I will change it according your setup and retry.

Edi
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Edinson on October 16, 2016, 04:34:24 pm
No change.
Still the Error with the EmbeddedICE version and I can't halt the CPU.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Edinson on October 16, 2016, 08:30:25 pm
Finally I got it. It was probably a connection problem   |O
I did it exactly as shown in the picture of PeDre... and it worked. Thank you PeDre for sharing.

I halted when the logo disappeared and did the dump.
Then I generated the keys with the compiled windows version of rigup (post #4113). Thank you Neuro

And now I have an unlocked DS1074Z-Plus.

Edi
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on October 16, 2016, 10:47:11 pm
Finally I got it. It was probably a connection problem   |O
I did it exactly as shown in the picture of PeDre... and it worked. Thank you PeDre for sharing.

I halted when the logo disappeared and did the dump.
Then I generated the keys with the compiled windows version of rigup (post #4113). Thank you Neuro

And now I have an unlocked DS1074Z-Plus.

Edi

Nice one! Lucky guy! I didn't have such luck! My Rigol still's locked!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Daruosha on October 17, 2016, 10:29:33 am
I'm sure my question has been answered somewhere, but I cannot find it. My USB Blaster in JTAG mode has TCK,  TDO, TDI, TMS, Vcc and GND, But in the apparently the JTAG port on the scope has more pins like SRST and a few more? Anyone kind enough to help me with the wiring?

(I really need to read a bit about JTAG, stupid questions)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on October 17, 2016, 10:35:03 am
I'm sure my question has been answered somewhere, but I cannot find it. My USB Blaster in JTAG mode has TCK,  TDO, TDI, TMS, Vcc and GND, But in the apparently the JTAG port on the scope has more pins like SRST and a few more? Anyone kind enough to help me with the wiring?

(I really need to read a bit about JTAG, stupid questions)

Page 150 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/3725/) of this thread! I think that is what you need!

You might also need to see this link (https://www.segger.com/interface-description.html) if you ever need to match pins names if they are named different.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: nctnico on October 17, 2016, 07:33:06 pm
Just out of curiosity: what is different about the MSO1000Z which makes it difficult to hack? Can't it be upgraded using a license key? If it can be upgraded using a license key then I guess someone needs to figure out what Rigol has changed in their key generation algorithm.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Fungus on October 17, 2016, 08:10:58 pm
Can the "soft" items (eg. advanced triggers) be upgraded with a keygen and entering a code on the front panel?

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Howardlong on October 17, 2016, 08:45:46 pm
Just out of curiosity: what is different about the MSO1000Z which makes it difficult to hack? Can't it be upgraded using a license key? If it can be upgraded using a license key then I guess someone needs to figure out what Rigol has changed in their key generation algorithm.

Pretty much. There's a change to the algorithm/key stuff in the MSO, and as I understand it no one with the right skills (and the scope) has had that most valuable of assets, enough time, to invest to come up with a less intrusive method. When I did it as a script monkey guinea pig some time ago, it took about half a day, but we didn't have it quite so well documented back then.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Daruosha on October 18, 2016, 02:52:44 pm
I'm sure my question has been answered somewhere, but I cannot find it. My USB Blaster in JTAG mode has TCK,  TDO, TDI, TMS, Vcc and GND, But in the apparently the JTAG port on the scope has more pins like SRST and a few more? Anyone kind enough to help me with the wiring?

(I really need to read a bit about JTAG, stupid questions)

Page 150 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/3725/) of this thread! I think that is what you need!

You might also need to see this link (https://www.segger.com/interface-description.html) if you ever need to match pins names if they are named different.
any news about your situation? could you manage to make successful dump and generate keys?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on October 18, 2016, 05:30:31 pm
I'm sure my question has been answered somewhere, but I cannot find it. My USB Blaster in JTAG mode has TCK,  TDO, TDI, TMS, Vcc and GND, But in the apparently the JTAG port on the scope has more pins like SRST and a few more? Anyone kind enough to help me with the wiring?

(I really need to read a bit about JTAG, stupid questions)

Page 150 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/3725/) of this thread! I think that is what you need!

You might also need to see this link (https://www.segger.com/interface-description.html) if you ever need to match pins names if they are named different.
any news about your situation? could you manage to make successful dump and generate keys?
I'm able to make the memory dump and  generate the keys, but the scope rejects all of the generated keys...

Sent from my GT-I9505 using Tapatalk

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: carl_lab on October 20, 2016, 01:23:17 pm
I 'm going to buy a new MSO 4/16ch ~100MHz in the next months.
Rigol MSO1074Z or MSO1104Z fits very close to my specs...

So anyone got these models with current firmware revision successfully hacked?

I'm still hoping anyone will write a working keygen for the MSO models to activate upgrades with no need for a JTAG adaptor and opening the case ...

@Edinson
Have you thought about upgrading your DS1074Z-Plus to an MSO?
I'm not sure the LA probe has an active head or is it just a flat cable?

Who is the importer for Rigol in Germany?
Batronix?
Do they sell used demo models?
 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: RoGeorge on October 20, 2016, 04:59:04 pm
This post is just to easily follow the subject.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Edinson on October 20, 2016, 07:32:44 pm
Quote
@Edinson
Have you thought about upgrading your DS1074Z-Plus to an MSO?
I'm not sure the LA probe has an active head or is it just a flat cable?

I am considering it and wanted to have this option. The LA probe is from my understanding the same as for the MSO's. My DS1074Z-Plus has firmware version 04.03.SP2.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: carl_lab on October 21, 2016, 10:32:52 am
Quote
@Edinson
Have you thought about upgrading your DS1074Z-Plus to an MSO?
I'm not sure the LA probe has an active head or is it just a flat cable?

I am considering it and wanted to have this option. The LA probe is from my understanding the same as for the MSO's. My DS1074Z-Plus has firmware version 04.03.SP2.
The LA probe kit + MSO license is a little bit expensive (about 300€ incl. VAT).
Price difference between MSO and DS-plus is about 170€, that's why I probably go for the MSO.
I think hacking this feature only makes sense, if you could get a cheap probe set.


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Daruosha on October 23, 2016, 04:29:42 pm
What I'm concerned about is the possibility of a successful memory dump and keys extraction with the lastes published firmware. It seems i have to try it myself rather than relying on other experiences. Having all options worths loosing the warranty (i don't have the patience to peel off the warranty label properly), but loosing warranty and gaining nothing is not the best option i guess.

However, i think I'm going to take the risk and let it go as an experience.

In the men time I'd appreciate any suggestions and recommendations :-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: TurboTom on October 23, 2016, 04:54:17 pm
Peeling off the sticker really isn't troublesome at all if you gently heat it with a hair dryer or a reflow hot air blower at low low temperature setting (<100°C). This softens the glue of the sticker so much that wax paper (or whatever that stuff is called that nothing sticks to) more or less just slides underneath it. A job of a minute or so.

Cheers,
Tom
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Daruosha on November 01, 2016, 07:10:49 pm
Guess what?!?!

I took apart the scope and found the JTAG pin headers on the main board were gone. Just 10 unpopulated solder pads :( DAMN :(
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: qwertymodo on November 01, 2016, 08:19:06 pm
It's not hard to solder on a standard 2x5x0.1" pin strip, or just get a press-fit header from Samtec.

Sent from my m8wl using Tapatalk

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Spinwing on November 01, 2016, 09:06:06 pm
Guess what?!?!

I took apart the scope and found the JTAG pin headers on the main board were gone. Just 10 unpopulated solder pads :( DAMN :(

I just went through the process of unlocking everything on my MSO1104Z-S here, and I found the same thing when I opened it up. I ended up soldering in a header, but it does take a little bit of work since you have to fully disassemble the scope. And no point bothering to keep the warranty sticker after that :)

However the process worked fine. I used an Altera USB Blaster clone I got from eBay, wired it up according the JTAG pinouts specified here:

https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/ug/ug_usb_blstr.pdf (https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/ug/ug_usb_blstr.pdf)

For reference, here are the USB blaster pin assignments for JTAG mode:

USB Blaster PinSignal
1TCK
2GND
3TDO
4VCC
5TMS
6N/C
7N/C
8N/C
9TDI
10GND

When I was hooking it up I just ignored any signals that aren't on that list.

I used OpenOCD 0.9.0 on Windows. My scope had firmware 4.03.SP2 installed, and I still had some time left on the feature trial licenses so I just halted the processor while the trial time remaining screen was showing and dumped the image.

I got bored after about an hour and wanted to see if I was getting anything, so I stopped the process with about 16MB dumped and used rigup 0.4.1 (the mso1000z version, no patches or anything applied). It found the keys and the generated license worked fine.

As a side note, I briefly tried building and running rigup using the bash shell support in Windows 10, but it faulted with a failed assertion that I didn't look into. Instead I built it in Visual Studio and it ran fine with just a couple of very minor tweaks to change a couple of POSIX specific calls.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: qwertymodo on November 01, 2016, 09:49:33 pm
I used OpenOCD 0.9.0 on Windows. My scope had firmware 4.03.SP2 installed, and I still had some time left on the feature trial licenses so I just halted the processor while the trial time remaining screen was showing and dumped the image.

Glad to hear that worked for somebody else.  Looks like the timing of the dump really is (at least part of) the issue.  Not sure what that means for people whose trials have expired.  Maybe in that case, it might be possible to open the Options>Installed menu where it lists the trial options that have expired and try taking a dump while that dialog is displayed.  psysc0rpi0n, maybe can you try that?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Daruosha on November 03, 2016, 02:52:47 pm
No change.
Still the Error with the EmbeddedICE version and I can't halt the CPU.


I have the same problem and everything i did, couldn't figure it out.

What did you?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Edinson on November 03, 2016, 07:12:50 pm
In my case it was most likely a wiring problem.
As soon as I did like shown in reply #4248 it worked without any issues.
My adapter is an Olimex ARM-USB-OCD-H and I had an additional pin (#3 at both ends) connected.
Others in this forum have used an Altera as well as far as I have read, maybe one of these may share how they did it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Edinson on November 03, 2016, 07:47:29 pm
Look at reply #4013
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Daruosha on November 04, 2016, 11:13:09 am
My JTAG adaptor is Altera USB blaster and I checked the wiring several times. I just left the SRST and TRSTS and ignored them, since my Altera blaster does't have those pins. Do you think that could be the issue?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Daruosha on November 04, 2016, 04:21:13 pm
I ordered an Olimex USB-OCD-H. Let see does that work or not.

On things i was wondering could cause connection problem was the way i connected the pin hearders. Since i didn't want to fully disassemble the scope, i put 2 rows of 5pin so called "military" headers on the scope pcb and put an IDC cable and put rather heavy thing on the idc connector to keep the pin headers straight on the PCB.  It sounds very stupid and rather idiotic, but i think the pin headers make a reasonable connection with pads. I couldn't find pres fit headers and i cannot think of any other solderless solution.

Any suggestions?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: qwertymodo on November 04, 2016, 06:24:04 pm
That could work, but I'd never trust it for something that takes this long. I've done exactly that for reprogramming micros, and sometimes it'll take 2-3 tries, which isn't a big deal when the whole thing takes 10 seconds, but do you really want it to come loose 40 minutes in and have to start all over?

Here are Samtec's press-fit series, you can get the exact 2x5 header you need: https://www.samtec.com/products/pht

Sent from my m8wl using Tapatalk

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on November 06, 2016, 10:28:58 pm
I used OpenOCD 0.9.0 on Windows. My scope had firmware 4.03.SP2 installed, and I still had some time left on the feature trial licenses so I just halted the processor while the trial time remaining screen was showing and dumped the image.

Glad to hear that worked for somebody else.  Looks like the timing of the dump really is (at least part of) the issue.  Not sure what that means for people whose trials have expired.  Maybe in that case, it might be possible to open the Options>Installed menu where it lists the trial options that have expired and try taking a dump while that dialog is displayed.  psysc0rpi0n, maybe can you try that?

I didn't checked this thread for a few days... I'll try it right away!


Edited;
Ok, the generated keys were the same as the previous attempts so they were a no go! I halted the scope with the board of the installed option on the screen but no good!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Daruosha on November 09, 2016, 02:28:15 am
Let's assume I have the codes for 2000 minutes trial license keys. Can I uninstall them when it's close to expiration and re-install them (with SCPI commands of course)?
Is there anyway to completely factory reset the scope?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: manu on November 10, 2016, 01:25:44 pm
DS4000 series Bandwidth (model type) Option Codes.

For those who have an interest in the DS4000, I have found the option codes for selecting the bandwidth .
This also sets the model type.

For example the code FAB9 will select 500Mhz, (DS405x), with all Decoders enabled.

The attached file contains all the details.

There are also two un-documented, possibly future, options called "Power Analysis" and "MA".

The option codes have been tested with firmware ver 00.02.00.00.04 and ver 00.02.01.00.03.

*EDIT*
 Attached updated PDF document to include the option selection codes for LIN and 1553B decode.
Also included are two possible future options,  Power Analysis and I2S decode.
Power Analysis has been listed for some time, but the I2S decode is relatively recent.
The original un-documented "MA" option has become the 1553B decode option.

Hello,

I successfully added decoders option to my MSO4024.
soft ver 00.02.03.00.03
hard ver 0.1.3.1
The 4-letter parameter to add decoders permanently: BAA9 (RS232, SPI, I2C, CAN, FlexRay, LIN decoders)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tom66 on November 11, 2016, 06:57:56 pm
I'm curious. When you buy a licence key from Rigol (or a distributor) you just provide them with your serial number, right? Does Rigol also know the private key of every scope, or is it just different for the MSO series?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Daruosha on November 11, 2016, 07:00:48 pm
Yes, all they need is the serial number of the device.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Fungus on November 12, 2016, 06:13:19 pm
Quote
I'm curious. When you buy a licence key from Rigol (or a distributor) you just provide them with your serial number, right?
Right.

Quote
Does Rigol also know the private key of every scope
They could easily generate keys at the factory and store them in a database keyed to the serial number.

Or maybe the private key is simply derived in some way from the serial number (using a private Rigol key).

Does anybody know how the dealers generate the keys? I think Rigol doesn't generate them directly so the dealers must have software to generate keys. Do they have to go to a special Rigol website or something? Anybody know?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: BravoV on November 12, 2016, 06:47:36 pm
Quote
Does Rigol also know the private key of every scope
They could easily generate keys at the factory and store them in a database keyed to the serial number.

Or maybe the private key is simply derived in some way from the serial number (using a private Rigol key).

Does anybody know how the dealers generate the keys? I think Rigol doesn't generate them directly so the dealers must have software to generate keys. Do they have to go to a special Rigol website or something? Anybody know?

Once you purchased the option, Rigol or dealers will send you Software License Certificate with an initial product key (not for keying into the scope though , and then you will need to point your browser to -> http://int.rigol.com/CustomerService/ProductRight (http://int.rigol.com/CustomerService/ProductRight) , then you key in the "product key" provided in the certificate AND your scope's serial number to generate the real key for user to enable it at the scope.

The most important fact , the generated key is NOT identical from the one generated by riglol.  ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: fab13 on November 14, 2016, 09:24:16 pm
hi I can not see option install on mine DS 2102A  what i am doing wrong ?

I can only see System info , but no detail , can some one help ?

thx
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: RebornGeek on November 14, 2016, 09:42:37 pm
Thanks for the great posts. 

I've used a couple of the license-key-generator sites (http://gotroot.ca/rigol/riglol/ (http://gotroot.ca/rigol/riglol/)) and used the key on my 1074S Scope.  Keep getting invalid license.

So:

1. Does this hack still work?  Seems that maybe Rigol has caught on.
2. Should the license key change?  I keep getting the same key trying different website, clearing my cache, etc.

Many thanks for any help.
RebornGeek
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: manu on November 14, 2016, 10:33:18 pm
Thanks for the great posts. 

I've used a couple of the license-key-generator sites (http://gotroot.ca/rigol/riglol/ (http://gotroot.ca/rigol/riglol/)) and used the key on my 1074S Scope.  Keep getting invalid license.

So:

1. Does this hack still work?  Seems that maybe Rigol has caught on.

I tried with a ds1054z this week-end to activate:
- advanced triggers: DSAB
- decoders: DSAC
- 24M memory: DSAE
- recorder: DSAJ
Use your scope serial number to generate the license key(s).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cypcyp on November 17, 2016, 06:02:04 pm
Hello, i received my DS1074-S-Z a few days ago with the free DECODER-Option. The official application of that option via Rigol website went fine. But unfortunately the keys generated by riglol_1.03d for the advanced trigger failed, now i'm locked out for the 12 hrs period every time i enter a wrong key.

Do you have any idea why the keygen doesn't work? Sysinfo says DS1074Z Plus Firmware 00.04.03.SP2 Board Version 6.1.1.
Were other attempts successful on that model? Or am i too stupid to understand the procedure?
I enter my serial Nr, the Option-select DSAB, the private key is generated by the keygen and then dial in the 4*7 char key.

 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Daruosha on November 18, 2016, 01:25:29 pm
Hello, i received my DS1074-S-Z a few days ago with the free DECODER-Option. The official application of that option via Rigol website went fine. But unfortunately the keys generated by riglol_1.03d for the advanced trigger failed, now i'm locked out for the 12 hrs period every time i enter a wrong key.

Do you have any idea why the keygen doesn't work? Sysinfo says DS1074Z Plus Firmware 00.04.03.SP2 Board Version 6.1.1.
Were other attempts successful on that model? Or am i too stupid to understand the procedure?
I enter my serial Nr, the Option-select DSAB, the private key is generated by the keygen and then dial in the 4*7 char key.

Have you tried to generate the keys on a different browser or even a different machine?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MarkF on November 18, 2016, 04:30:18 pm
Let's assume I have the codes for 2000 minutes trial license keys. Can I uninstall them when it's close to expiration and re-install them (with SCPI commands of course)?
Is there anyway to completely factory reset the scope?

Maybe someone else can verify this. But, there are NO codes for the trial licenses.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Daruosha on November 18, 2016, 06:38:00 pm
I have the codes :-) will confirm it soon myself  ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cypcyp on November 18, 2016, 06:47:23 pm
Thanks for answering. Unfortunately both hints - other browser, other machine - give me the same "wrong" key I already had tried.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: MarkF on November 18, 2016, 11:25:31 pm
I have the codes :-) will confirm it soon myself  ;)
I would be interested in what you have and how Rigol implemented it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Daruosha on November 18, 2016, 11:56:58 pm
I have the codes :-) will confirm it soon myself  ;)
I would be interested in what you have and how Rigol implemented it.

All I have is the trial license keys for my MSO1104z (all options excluding bandwidth upgrade and 500uV resolution) which Rigol kindly sent me as some sore of student bonus. I entered the keys through SCPI commands into the scope and they added 36 more hours to the remaining trial time. I wondered since the scope has no RTC and permanent license storage (not sure about this one yet), i can uninstall and then re-install the same trial licenses and achieve 36 trial hours cycles forever. 

RIGOL please don't read this post :D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: loaderr on November 21, 2016, 09:00:58 am
Hi all,
I'm trying to unlock MSO1074Z with expired trial license with no luck so far.
A while ago quertymodo had a theory that keys are get locked some time after logo disappears which sounds credible to me.
If someone still has a correct dump could you please try to compare relevant info from it (136 bytes starting at "01 00 84 00 10 00") with unsuccessful dump or just some other dump made later to prove the theory?
Thanks.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on November 21, 2016, 08:21:02 pm
Hi all,
I'm trying to unlock MSO1074Z with expired trial license with no luck so far.
A while ago quertymodo had a theory that keys are get locked some time after logo disappears which sounds credible to me.
If someone still has a correct dump could you please try to compare relevant info from it (136 bytes starting at "01 00 84 00 10 00") with unsuccessful dump or just some other dump made later to prove the theory?
Thanks.

What you mean with "unsuccessful dump"? A dump that generated keys but which keys didn't worked? I can provide such dump but I cannot provide a successful where keys has been generated and worked!   
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: loaderr on November 22, 2016, 11:22:00 am
That's exactly what I meant! Dump that generates license which doesn't pass validation. If we compare it with one that generate correct license than we will know if problem is in scrambled keys or something else. But we need 2 from the same device. I have the same problem - I have "bad" one but no good one. We need to wait for guy who where able to unlock their devices.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Iakabos on November 22, 2016, 11:09:11 pm
Has anyone tried messing around with the new dg1022z function generator yet to see if it's possible to unlock other options? It does have the option to purchase increased memory depth, which leads me to believe it's made similarly to their other products with frequency limited by software. I would be very interested if 60MHz could be unlocked, as the 25MHz model sells for $360 and the 60MHz sells for $860.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on November 24, 2016, 08:32:58 am
That's exactly what I meant! Dump that generates license which doesn't pass validation. If we compare it with one that generate correct license than we will know if problem is in scrambled keys or something else. But we need 2 from the same device. I have the same problem - I have "bad" one but no good one. We need to wait for guy who where able to unlock their devices.

Ah ok... that's not my case! I can only dump memory and generate "bad keys"!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on November 25, 2016, 03:13:40 pm
Ok, I just got a new licence key (trial) for the scope. Should I do anything before/after/between applying the key and making a new dump file of my scope's memory? Someone said to try to compare the memory dumps of someone with working and non-working licence keys! I have now the possibility of having the options with Trial time again, make a new dump and try to generate new keys!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on November 25, 2016, 08:05:18 pm
Looks line I'm not lucky! I tried twice the memory dump right after the Rigol logo disappears and the Options screen show up but the generated keys are the same as before!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: loaderr on November 26, 2016, 08:13:54 am
Yes, I found the same. FYI trial license is stored in memory starting at 0x43ee0058, you can dump if JTAG is still connected (small dump of 64Kb). Then run for some time and dump again - somewhere there should be counter that expires trial license. If we can roll it back trial will never expire :)

What I found so far is that option string is not decoded properly for some reason and on top of that public key is not decoded properly as well - trying to figure out why. Rigup does number of strange things that looks suspicious. If someone with knowledge why things were done in such way can contact me it would be really helpful.

In the mean time you can do a simple test - run rigup info with you trial license and see if it passes of fails - also check if options string is correct.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: loaderr on November 27, 2016, 10:21:38 am
Good news guys - I was finally able to unlock my 1074.  :)
I can confirm that there are no good or bad images - all are good but there is a subtle bug in rigup (actually it's a bug in FW :) ) that leads to incorrect hash calculation - if you are unlucky. If your XXTEAKEY ends in couple or more zeros you will hit this bug for sure. Tested on 04.03.SP2.
I fixed rigup, who needs sources - please email me.

Big thanks to original developers of rigup - they probably spent many days creating it. It took me the whole weekend together with IDA and debugger to figure out why it doesn't work - Rigol FW is bloody convoluted.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on November 27, 2016, 11:00:08 am
Good news guys - I was finally able to unlock my 1074.  :)
I can confirm that there are no good or bad images - all are good but there is a subtle bug in rigup (actually it's a bug in FW :) ) that leads to incorrect hash calculation - if you are unlucky. If your XXTEAKEY ends in couple or more zeros you will hit this bug for sure. Tested on 04.03.SP2.
I fixed rigup, who needs sources - please email me.

Big thanks to original developers of rigup - they probably spent many days creating it. It took me the whole weekend together with IDA and debugger to figure out why it doesn't work - Rigol FW is bloody convoluted.

My XXTEAKEY ends up in 000... So I'm affected by it, no? Is that rigup fix going to work to MSO1000 series?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: janekivi on November 27, 2016, 01:17:24 pm
I have made some memory dumps from DS1045Z when updating firmware and entering keys.
In my case most of stuff is driving randomly in memory. At the end are licenses and keys and
serial which are always at there. Somewhere I found 5 licenses, last was my DSER. They can
be trial licenses from factory. All said "License is already used" when I was trying to enter them.
So, they can't be entered again without deleting them from eeprom...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Daruosha on November 27, 2016, 04:48:18 pm
I have made some memory dumps from DS1045Z when updating firmware and entering keys.
In my case most of stuff is driving randomly in memory. At the end are licenses and keys and
serial which are always at there. Somewhere I found 5 licenses, last was my DSER. They can
be trial licenses from factory. All said "License is already used" when I was trying to enter them.
So, they can't be entered again without deleting them from eeprom...

Have you tried to uninstall trial keys with SYSTem: OPTion:INSTall commamd ?

BTW, you can generate the keys simply by using the famous rigol keygen, no JTAG dump hassles.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: janekivi on November 27, 2016, 07:50:52 pm
 :) I don't have problems with that. I try other things actually.
https://www.eevblog.com/forum/testgear/rigol-dsxxxx-gel-firmware-file-format/ (https://www.eevblog.com/forum/testgear/rigol-dsxxxx-gel-firmware-file-format/)
But there was talk about using trial keys.
Uninstall doesn't delete trial keys as I see from dump. After uninstalling Your
generated key there is "Trial is over" text after every option too.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: janekivi on November 28, 2016, 04:59:56 pm
SYSTem: OPTion:UNINSTall is deleting "All official options removed" or something like this.
But after some mem dumps I found 36 Hours Trial License Key ... key. Like for DP832
there is the same for DS1054Z too in here http://www.gotroot.ca/rigol/riglol/ (http://www.gotroot.ca/rigol/riglol/)
And this is V for generating trial keys for DS1054Z
Option VSER is all  options like DSER but 36 hours trial version.
So others can be

DS1000z device options:
first character: D = official, V = trial

DSAB - Advanced Triggers
DSAC - Decoders
DSAE - 24M Memory
DSAJ - Recorder
DSBA - 500uV Vertical
DSEA - 100MHz
DSFR - all options
DSER - all options - 500uV Vertical

Currently I have DS1000Z-00.04.04.00.07 firmware.
Now if I add official license, all options are official and after delete
all options continue trial time. (and mem dump is messier at key regions
like he is generating all separate trial keys but factory ones are there too. )
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: loaderr on November 28, 2016, 11:57:55 pm
Hi all,
I uploaded fixed rigup sources to https://www.dropbox.com/sh/1yrh8s90ityn90s/AAA6PXlJk9gGQwoDOwO6TDQua?dl=0, (https://www.dropbox.com/sh/1yrh8s90ityn90s/AAA6PXlJk9gGQwoDOwO6TDQua?dl=0,) feel free to use.
There are still some bugs as psysc0rpi0n was unable to unlock so far so use cautiously :)
I did some investigation how licenses are stored and it looks like they just programmed to flash and never erased. On startup FW scans all of them to decide which one to use. As longs as rigup works no need to worry about trials.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on November 30, 2016, 10:36:38 am
Hi all,
I uploaded fixed rigup sources to https://www.dropbox.com/sh/1yrh8s90ityn90s/AAA6PXlJk9gGQwoDOwO6TDQua?dl=0, (https://www.dropbox.com/sh/1yrh8s90ityn90s/AAA6PXlJk9gGQwoDOwO6TDQua?dl=0,) feel free to use.
There are still some bugs as psysc0rpi0n was unable to unlock so far so use cautiously :)
I did some investigation how licenses are stored and it looks like they just programmed to flash and never erased. On startup FW scans all of them to decide which one to use. As longs as rigup works no need to worry about trials.

Thanks for sharing the semi-fixed rigol tool. Though I still have the MEM DEPTH locked! So, could you explain to us all how to generate the correct keys?? I have tried your tool but I could not generate correct keys, but somehow you achieved it!

It would be nice to know with some detail the steps you took to generate the keys using your semi-fixed version of rigup!

Cheers
Psy
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Smokey on December 01, 2016, 12:15:51 am
Curious why the DP831 power supply wasn't worked on here.  Are the keys actually implemented differently?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Twingy on December 08, 2016, 06:21:39 am
Downloaded the 64MB image from MSO1074Z using Olimex JTAG USB-OCD-H.  Generated the license file using rigup scan, serial number is correct from JTAG image, other licenses including tea key look valid.  Attempted to generate a triggers key (CSAR=0x1C001) with from license file using rigup license.  Invalid license! for the generated key.  Tried 0x1C002, invalid license as well.  Tried the updated rigup source from loaderr and generates the same keys, nothing different.  Firmware is 00.04.03.SP2 BOARD 2.1.4.  Any help is appreciated.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Twingy on December 10, 2016, 03:58:32 pm
Another short update.  I changed the adapter_khz from 400 khz to 3000 (3 MHz) but the transfer speed off the mso1074 still appears to be limited to 25kB/sec, for ~45 min transfer period.  I performed all of the same steps using this new .bin image file and get same results, so I'm fairly certain the bin file is valid.

Additional Notes: On my mso1074z the jtag male header is missing.  Rather than try to solder on the header by removing the board/voiding the warranty etc, I used a male header and light force so as to avoid modifying the hardware in any way.  I also use rubber gloves to avoid getting finger prints all over the internals.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 2N3055 on December 10, 2016, 04:39:12 pm
Curious why the DP831 power supply wasn't worked on here.  Are the keys actually implemented differently?

For the 831 you just generate keys for 832, put your serial and go.. Worked fine on mine 831... I also made changes on one of the member DP832 python calibration script to work with DP831 and DM3068..
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Smokey on December 11, 2016, 01:43:26 am
Curious why the DP831 power supply wasn't worked on here.  Are the keys actually implemented differently?

For the 831 you just generate keys for 832, put your serial and go.. Worked fine on mine 831... I also made changes on one of the member DP832 python calibration script to work with DP831 and DM3068..

Sweet.  Good to know.  I didn't see that actually stated anywhere before.  Thanks!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: loaderr on December 13, 2016, 09:47:17 am
2twingy: check if your keys start from 0's and do they have proper length (should be 8 or 16 hexadecimal digits), if not append 0 in front of key like 0x001234. Otherwise fixed Rigup should just work for you.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Twingy on December 13, 2016, 03:24:13 pm
Hello loaderr, I've attached a copy of my output from rigup, do you see anything that looks out of the ordinary?  Thanks.
(https://s23.postimg.org/8kfpwhlvv/keys.png)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Daruosha on December 13, 2016, 05:50:18 pm
Since public and private keys are same across MSO-1000z models, is there anyway to calculate XXTEA and RC5 keys from serial number? I have the trial codes and looking for a solution to solve these keys from serial number and trial codes. Any suggestions?

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jckz82 on December 20, 2016, 04:50:00 pm
I'm in the same situation as Twingy.

- MSO1074Z bought in Dec 2016
- Software V04.03.SP2
- Board 2.1.4
- JTAG header absent from board
- Ran memory dump immediately after logo disappears (did three dumps with the same results)
- Used loaderr's fixed version of rigup

Generated licenses are invalid. 

Any files or information I can upload that would help solve this?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Noize on December 20, 2016, 06:07:56 pm
I had success upgrading my mso1074z-s  8)

Software version 00.04.04
Board version 6.1.1


I compiled loaderr's version of rigup with VS 2013
Used a Chinese knockoff jtag dongle firmware: J-Link ARM V8 compiled 1 Dec 2009.    Hardware version: V8.00

Turned on the oscilloscope then plugged j-link into the computer
Started J-link commander from the command line>JLink.exe -speed 100

J-Link>connect
......
Device>arm9
.......
JTAGConf> (just press enter)

J-Link>h (press enter when license screen appears)

J-Link>speed 4600

J-Link>savebin mso1074z.bin 0x40000000 0x3FFFFFF

J-Link>g

Use Loaderr's file as per usual.

I bought my scope from Rigol 3 months ago with the latest firmware installed, the jtag header was still present.

Thank you to everyone who contributed  :clap: I am now able to continue electronics thank god! Ha
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jlm1 on January 01, 2017, 07:37:30 pm
result same as Twingy. Generated license invalid
MSO1047Z-S
DS1ZDxxxxxxxxx (15 total chars)
Software 4.03.SP2
Board 6.1.4
JTAG header not populated. Note that cardboard box indicates manufacture date in July 2016.

First...
Memory dumped using Segger J-Link Pro. I used J-link commander, set the device to IMX28 (which selected ARM9), halted, and dumped using savebin.  I don't think it took much longer than five minutes.

Then...
Compiled Rigup in Visual Studio 2015 from the above posed modified source. It complied without any issues but then rigup scan crashed on a call to IsDigit(...) with a negative value. I debugged figured out that VS was using signed char. It was necessary to add the /J flag to VS to force the compiler to use unsigned char. Then Rigup scan worked and found the correct serial number and possibly reasonable looking keys.

I generated DSAB (advanced trigger) license, entered it, and got invalid license.
--
If someone wants to double check my work and see if you get the same license codes from my memory dump, email me.  I would like to rule out a bug from compiling in visual studio.
---
Update: Another member generated keys with his complied code and everything worked. So I was doing something wrong or my compiled rigup didn't work. so Yes, rigup still works for Software 4.03.SP2, Board 6.1.4, without JTAG header.


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: enry68 on January 03, 2017, 02:08:29 pm
Hi guys.

How can I get the fabrication date of my Rigol 1054Z ?

many thanks,
Enrico.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jlm1 on January 04, 2017, 04:47:20 am
I think the date is on the calibration certificate
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Andrew8086 on January 04, 2017, 10:52:38 am
It is also coded into the serial number:

Manufacture date code in serial no.:
DS1ZA yy ww xxxxx
yy: 15=2013, 16=2014, 17=2015, 18=2016
ww: week no. in indicated year
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Teneyes on January 07, 2017, 07:04:46 am
Manufacture date code in serial no.:
DS1ZA yy ww xxxxx
There was a time when there was a Hack to change the Serial Number  :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Noize on January 07, 2017, 02:56:04 pm
Quote from: jlm1 on January 01, 2017, 07:37:30 PM (https://www.eevblog.com/forum/index.php?topic=17002.msg1103995#msg1103995)>Quote
Update: Another member generated keys with his complied code and everything worked. So I was doing something wrong or my compiled rigup didn't work. so Yes, rigup still works for Software 4.03.SP2, Board 6.1.4, without JTAG header.Quote

It was actually loaderr's version from Reply #4308 compiled with VS2013 Just to clarify.

The file I have attached was compiled on a windows 7 machine.
Use Rigol instead of rigup for the commands.





Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ve7xen on January 11, 2017, 01:22:51 am
Hi all,
I uploaded fixed rigup sources to https://www.dropbox.com/sh/1yrh8s90ityn90s/AAA6PXlJk9gGQwoDOwO6TDQua?dl=0, (https://www.dropbox.com/sh/1yrh8s90ityn90s/AAA6PXlJk9gGQwoDOwO6TDQua?dl=0,) feel free to use.
There are still some bugs as psysc0rpi0n was unable to unlock so far so use cautiously :)
I did some investigation how licenses are stored and it looks like they just programmed to flash and never erased. On startup FW scans all of them to decide which one to use. As longs as rigup works no need to worry about trials.

Great work, thanks!

I have ported the build back to original POSIX build environment (just copied the new source into the old build directory), added some attribution for your work and bumped the version to 0.4.2, and packaged it up as rigup-0.4.2 (http://gotroot.ca/rigol/rigup-0.4.2.zip) and built a Linux x86_64 binary here (http://gotroot.ca/rigol/rigup-0.4.2-x86_64-linux.gz).

I also decided to get MingW and try building for Windows. Seems to build with some warnings, but bails without outputting anything on the console. Not sure what that's about. I might spend a few minutes debugging, but it's not a platform I care about ;).

Edit: Build problem was -Wl,-dead_strip. Removing this linker option builds working Windows binaries. All builds now:

Linux x64 (http://gotroot.ca/rigol/rigup-0.4.2-x86_64-linux.gz) i686 (http://gotroot.ca/rigol/rigup-0.4.2-i686-linux.gz)
Windows x64 (http://gotroot.ca/rigol/rigup-0.4.2-x86_64-win.zip) i686 (http://gotroot.ca/rigol/rigup-0.4.2-i686-win.zip)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mikehs on January 26, 2017, 04:36:03 am
SYSTem: OPTion:UNINSTall is deleting "All official options removed" or something like this.
But after some mem dumps I found 36 Hours Trial License Key ... key. Like for DP832
there is the same for DS1054Z too in here http://www.gotroot.ca/rigol/riglol/ (http://www.gotroot.ca/rigol/riglol/)
And this is V for generating trial keys for DS1054Z
Option VSER is all  options like DSER but 36 hours trial version.
So others can be

DS1000z device options:
first character: D = official, V = trial

DSAB - Advanced Triggers
DSAC - Decoders
DSAE - 24M Memory
DSAJ - Recorder
DSBA - 500uV Vertical
DSEA - 100MHz
DSFR - all options
DSER - all options - 500uV Vertical

Currently I have DS1000Z-00.04.04.00.07 firmware.
Now if I add official license, all options are official and after delete
all options continue trial time. (and mem dump is messier at key regions
like he is generating all separate trial keys but factory ones are there too. )

Sorry if this should have been clear after reading the last 10 pages...
I am just trying to understand if the www.gotroot.ca/rigol/riglol (http://www.gotroot.ca/rigol/riglol) generated key still works for the newer DS1054Z?
software version: 00:04:04
board version: 0.1.4

I tried it, but no love.

Thanks for any help!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mikehs on January 27, 2017, 12:17:17 am
SYSTem: OPTion:UNINSTall is deleting "All official options removed" or something like this.
But after some mem dumps I found 36 Hours Trial License Key ... key. Like for DP832
there is the same for DS1054Z too in here http://www.gotroot.ca/rigol/riglol/ (http://www.gotroot.ca/rigol/riglol/)
And this is V for generating trial keys for DS1054Z
Option VSER is all  options like DSER but 36 hours trial version.
So others can be

DS1000z device options:
first character: D = official, V = trial

DSAB - Advanced Triggers
DSAC - Decoders
DSAE - 24M Memory
DSAJ - Recorder
DSBA - 500uV Vertical
DSEA - 100MHz
DSFR - all options
DSER - all options - 500uV Vertical

Currently I have DS1000Z-00.04.04.00.07 firmware.
Now if I add official license, all options are official and after delete
all options continue trial time. (and mem dump is messier at key regions
like he is generating all separate trial keys but factory ones are there too. )

Sorry if this should have been clear after reading the last 10 pages...
I am just trying to understand if the www.gotroot.ca/rigol/riglol (http://www.gotroot.ca/rigol/riglol) generated key still works for the newer DS1054Z?
software version: 00:04:04
board version: 0.1.4

I tried it, but no love.

Thanks for any help!

Sorry for bothering you all with that newbee Q. I got it working!

Turns out that you need to delete all the characters in the SN entry dialog before entering your SN.  I deleted up to the 'D' and that apparently does not work.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: FT952 on January 29, 2017, 07:02:16 pm
I bought a MSO2072A.
Software version 00.03.04.SP2
Hardware version 2.2

I read eevblog from 'Reply #3668' and tried 'Rigol USB' as well as 'Peter Dreisiebner.at - Rigol Bildschirmkopie'.
I dumped 13MB, 32MB and even 64MB (with Bildschirmkopie).
When I try to find the keys with rigup, I always get the message 'No keys'.   :-\

Even in the following replies I didn't find any solution.
I think I somewhere saw that MSO2072A would need a differnt kind of unlocking.

Any suggestions ?
Thanks
R.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: FT952 on January 31, 2017, 06:08:20 pm
With some help, I used rigol 4.0 and entered the key in manually on the scope's key entry screen.
Usage of Bildschirmkopie didn't work.

Now its a 2302A with all protocolls enabled. :-+

Thanks for your great work and support guys!
Really well done.

Also in https://www.eevblog.com/forum/testgear/rigol-mso2000-series-hacking/msg1105561/#msg1105561 (https://www.eevblog.com/forum/testgear/rigol-mso2000-series-hacking/msg1105561/#msg1105561) I found a solution like mine.

Best regards
R.
Title: DP711 unlock hires option
Post by: Eric-H on February 01, 2017, 03:44:36 pm
I recently bought the Rigol DP711 power supply. Nice device (although the fan is a bit loud).

It has three options: HIRES, Trigger and timer. Does anyone know which device option codes (the four characters) and private key to use for the DP711 with the Riglol generator?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Solder_Junkie on February 23, 2017, 05:28:01 pm
Now the later firmware for the DSA815 includes 10 Hz resolution, rendering the most useful hack obsolete, did anyone work out how to remove licence keys from an 815?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on February 23, 2017, 06:15:26 pm
Now the later firmware for the DSA815 includes 10 Hz resolution, rendering the most useful hack obsolete, did anyone work out how to remove licence keys from an 815?
No, we still do not know how to remove any previously installed option license.  But, it is not necessary to remove the license key.  The 10 Hz RBW will work fine now with, or without the license {option 3} activated.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Solder_Junkie on February 23, 2017, 07:06:51 pm
It would be nice to remove the licence keys in case it ever needs repair, the only hack that is useful to me is the 10Hz b/w one and that's now included.

No worries, I'll cross my fingers that it keeps working.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Mike_H on March 08, 2017, 03:13:11 pm
A quick post to say thank you to all the hard work that this thread represents.

After 3 days of reading and play, I was able to enable the options I wanted on my new to me 2302A.
For the record my firmware is 3.05

Thanks again!  :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on March 10, 2017, 01:02:01 am
fun to see that this rigol hacking is still going on ;-) :-DD
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gennady on March 11, 2017, 11:48:04 am
Hi all,
who used J-Link (J-Link V8 ARM USB-JTAG) to download memory dump from MSO1074Z, tell me please pinouts connection. TCK, TMS, TDI, TDO it's clear. But where to connect TRST, VREF, SRST (what pins of J-Link)?

Thanks for any help!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Co6aka on March 11, 2017, 03:23:25 pm
fun to see that this rigol hacking is still going on ;-) :-DD

Reminds me of "i aM eLiTe!!!! gIvE mE wArEz D00dZ!!!!!!!!!!"  :-DD

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mightyzen on April 01, 2017, 09:26:04 am
doing that since about a week or so - but the discovered TWI functions so far a slave mode, not master mode - a lot of stuff is happening via DMA transfers to from the fpga (assumption). they use VDK and threads, which makes reversing a pain in the ass, 8k subs, thousands of pointers ... im slowly approaching the right subs. if anyone has ida with the blackfin cpu from rigol homebrew, im happy to share my custom GEL loader, and IDA DB.

I'm looking into the firmware for the past weeks or so to try and enable the 50ohm option on a non-A ds2k model with v2 hardware. I would except this to be a simple enough patch as long I could find the handling of the scpi "CHAN1:IMP FIFTY" command.

I'm just lost in those 8k of subs and simply fail to find the references to the "FIFTY" and "OMEG" strings. Could some one please point me in the right direction?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DoMaLo on April 03, 2017, 10:32:49 am
Hello everybody. I have MSO1104z, board version: 2.1.4, SV: 00.04.04.SP1. I took a dump using JLink Ultra + in JLink Commander and OpenOCD. Rigup 0.4.1 (MSO1000z) and 0.4.2 print "No keys" for both of dumps. What's can i do for unlocking my oscilloscope?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gluk on April 05, 2017, 10:24:39 pm
What do you think about resistors near 3k \$\Omega\$  near by FPGA and JTAG header in the  :-BROKE MSO1074z? May be is it  config divider?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DoMaLo on April 07, 2017, 08:22:14 am
I think that these are resistors for pull-up and pull-down JTAG chain. Because I was working with Actel FPGA and typical JTAG chain
ProASIC3E Flash Family for FlashPro has resistors. Circuit that I used for my project in attachment.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gluk on April 07, 2017, 12:39:43 pm
Friends, yes! resistors near JTAG header set the config. They has title "hardware version" and "sp version". Upper resistor line is pull-up, lower - is pull-down.

Do somebody want to play with this pull-up-down? $)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gluk on April 07, 2017, 01:48:05 pm
Quote
the JTAG pullup/down resistors are there purely to enable robust JTAG data transfer.

This resistors not connected to the jtag pins!

(http://kbobs.org/gallery/albums/userpics/10001/MSO1074Z-S-JTAGPORT.jpg)

It connected to the pins near JTAG. And it has title!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ebastler on April 07, 2017, 02:03:42 pm
This resistors not connected to the jtag pins!
It connected to the pins near JTAG. And it has title!

Yes, I realized that and pulled my earlier post in the meantime. But I am afraid the "version" resistors are there simply to let the software know about different historical board revisions, which may require slightly different software control. I don't think these will enable any options.

After all, one can buy software upgrade codes for the MSO scopes, right? As these upgrades do not require the user to re-solder any internal resistors, I believe that the options are enabled and disabled purely based on keys stored in EEPROM.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ebastler on April 07, 2017, 02:05:42 pm
On a more general note, I must admit that I have lost track of this thread. Is there a proven method for enabling options on the MSO1000Z and DS1000Z-plus scopes? If so, could someone post a summary or a link please? Many thanks!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gluk on April 07, 2017, 03:20:05 pm
ebastler, Yes! Now I'm doing it. Some later I can post summary.
Or just see page #150, post by smgvbest
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ebastler on April 07, 2017, 05:32:43 pm
ebastler, Yes! Now I'm doing it. Some later I can post summary.
Or just see page #150, post by smgvbest

Ahhh, that indeed looks like step-by-step instructions, and nicely illustrated too!
Wow, how did you find that post in the 174-page thread?  :-+

Once you have confirmed that this works, maybe we can ask andyturk (who started this thread) to include a link in the first post.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: McBryce on April 09, 2017, 11:23:31 am
ebastler, Yes! Now I'm doing it. Some later I can post summary.
Or just see page #150, post by smgvbest

Ahhh, that indeed looks like step-by-step instructions, and nicely illustrated too!
Wow, how did you find that post in the 174-page thread?  :-+

Once you have confirmed that this works, maybe we can ask andyturk (who started this thread) to include a link in the first post.

I used the method on page 150 from smgvbest to "liberate" my MSO1104z-s and can confirm that it works.

McBryce.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: edgelog on April 20, 2017, 04:58:50 pm
I have the exact same version as DoMaLo (v00.04.04.SP1, board 2.1.4. Tried with Olimex, dumping the memory during the bootup logo and after at various intervals. All the dump files look good, as judged by all the strings in there looking reasonable (there's a lot of them, HTML pages, CSS files, a lot of help strings), but rigup 0.4.1 for MSO1000z says "no keys".

I also looked through the dump file for anything similar to the pattern given in rigup utils.c, in the ScanKeys function, and I can find nothing that matches the length of the keys or the hex prefix of the block.

It looks to me as if the keys simply aren't there anymore.  :palm:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gluk on April 21, 2017, 09:25:18 am
I have the exact same version as DoMaLo (v00.04.04.SP1, board 2.1.4. Tried with Olimex, dumping the memory during the bootup logo and after at various intervals. All the dump files look good, as judged by all the strings in there looking reasonable (there's a lot of them, HTML pages, CSS files, a lot of help strings), but rigup 0.4.1 for MSO1000z says "no keys".

Make dump after boot complete! Early dump don't has keys. I used rigup-0.4.2-x86_64-win and got keys, and hacked it complitely.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: edgelog on April 21, 2017, 05:59:44 pm
Make dump after boot complete! Early dump don't has keys. I used rigup-0.4.2-x86_64-win and got keys, and hacked it complitely.

I have tried rigup-0.4.2-x86_64-win.exe with 6 different file dumps taken at varying points in time, all the way from during the logo to more than five minutes after the boot completed, and nothing but "no keys". What version of firmware do you have? Same as mine (00.04.04.SP1)?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: edgelog on April 21, 2017, 07:29:09 pm
Ok, found the problem. Rigup was modified to work with the MSO1000z series by looking for a block of bytes beginning with the sequence 01 00 84 00 10 00, while the DS1000z (and other models?) use 02 00 84 00 10 00. By poking around with a hex editor in the dump files, I found that for my scope at least, that sequence is 02 00 84 00 10 00, which you're not supposed to see in an MSO. So not all MSOs are alike.

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:

Code: [Select]
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};

Then recompile:

Code: [Select]
make clean
make all

After this, I got all the keys, could generate all licenses, and all of them were accepted. Yay!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gluk on April 21, 2017, 09:17:58 pm
edgelog, is it a joke from Rigol with latest firmware?  :phew:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: edgelog on April 21, 2017, 09:28:38 pm
Maybe, but it did have me worried for a while.
I think  maybe the solution would be for rigup to accept 0x01 and 0x02 in that sequence. It's unique anyway.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mightyzen on April 22, 2017, 12:36:36 pm
doing that since about a week or so - but the discovered TWI functions so far a slave mode, not master mode - a lot of stuff is happening via DMA transfers to from the fpga (assumption). they use VDK and threads, which makes reversing a pain in the ass, 8k subs, thousands of pointers ... im slowly approaching the right subs. if anyone has ida with the blackfin cpu from rigol homebrew, im happy to share my custom GEL loader, and IDA DB.

Any one got that IDA DB (*.idb) from Cybernet back in 2013?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Blisk on April 25, 2017, 07:55:46 am
Is there a list which oscilloscope is hackable and can be upgraded??
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: lifeclock on April 28, 2017, 07:47:20 pm
Just want to confirm the hack still works on the scope below with a raspberry pi as the JTAG probe.

DS1074z-Plus
Software Version: 00.04.04.SP1
Board Version: 6.1.4

The jtag connector was missing on my board so I had to solder a connector in.
Memory dump took 4-5 hours, but beats spend money and waiting on shipping for a proper jtag probe.

Steps Followed


Good luck! And thanks to everyone that made this possible!

(http://i.imgur.com/Oapog3Dl.jpg) (http://i.imgur.com/bkiaDlil.jpg)
(http://i.imgur.com/MbCf735l.jpg) (http://i.imgur.com/8Owd3JBl.jpg)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: kattyil on April 29, 2017, 09:30:56 am
Good day everyone,

my DSA-815TG runs with the current Firmware 1.18 under Hardware 0.04 and boot loader 1.03. Generating keys with RIGLOL and activating the same under 1.18 works perfectly fine, the 10Hz RBW option was accepted but obviously has no effect as this option is available per default these days. All other options except for the last one are active as expected.

The new option SSC-DSA is shown as inactive and has no trial license. Experimenting with code AAAG in Riglol has no effect.

Any thoughts? Where does the code sequence (AAAE or SAAE come from?)

Raj



Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on May 07, 2017, 10:01:20 pm
Good day everyone,
My DSA-815TG runs with the current Firmware 1.18 under Hardware 0.04 and boot loader 1.03. Generating keys with RIGLOL and activating the same under 1.18 works perfectly fine, the 10Hz RBW option was accepted but obviously has no effect as this option is available per default these days. All other options except for the last one are active as expected.
Raj
Hello Raj: I understand from reading your post that you installed the Rigol Options with firmware 00.01.18 installed.
Although this is the first time that I have heard of anyone being able to use the Riglol Keygenerator for installing Option License Codes on the DSA815 with firmware 00.01.09 and above, on any hardware (old/new) version.
To follow this go to ->   https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg1203247/#msg1203247 (https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg1203247/#msg1203247) 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on May 11, 2017, 10:36:54 am
Good day everyone,
My DSA-815TG runs with the current Firmware 1.18 under Hardware 0.04 and boot loader 1.03. Generating keys with RIGLOL and activating the same under 1.18 works perfectly fine, the 10Hz RBW option was accepted but obviously has no effect as this option is available per default these days. All other options except for the last one are active as expected.
Raj
Hello Raj: I understand from reading your post that you installed the Rigol Options with firmware 00.01.18 installed.
Although this is the first time that I have heard of anyone being able to use the Riglol Keygenerator for installing Option License Codes on the DSA815 with firmware 00.01.09 and above, on any hardware (old/new) version.
To follow this go to ->   https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg1203247/#msg1203247 (https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg1203247/#msg1203247)

Ted,
I firmly believe the bootloader is the key here not the FW version or the combination of bootloader and firmware.   note his bootloader is
Quote
my DSA-815TG runs with the current Firmware 1.18 under Hardware 0.04 and boot loader 1.03
all having problems are using boot loader 1.04 such as myself.   I do not know what the interaction is with the boot loader but having followed this endless thread FOREVER it is more in common than anything else.

Has anyone looked at re-flashing bootloader 1.03 onto a DSA815?
does anyone know which bootloader they are using?

also note the new key format
old keys looked like
RUZ9H-5RUJKS-USSAW-23VUTY  (made up)
new look like
4f5RbEMlOl93wo5IOyoLWiYGR6jjUo (again made up)

and FWIW, those new keys don't work on Boot1.04, HW08,FW.18 even when supplied by rigol. :-// 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on May 11, 2017, 12:22:16 pm
Ted, I firmly believe the bootloader is the key here not the FW version or the combination of bootloader and firmware.   note his bootloader is
Quote
my DSA-815TG runs with the current Firmware 1.18 under Hardware 0.04 and boot loader 1.03
all having problems are using boot loader 1.04 such as myself.   I do not know what the interaction is with the boot loader but having followed this endless thread FOREVER it is more in common than anything else.

Has anyone looked at re-flashing bootloader 1.03 onto a DSA815?
does anyone know which bootloader they are using?

also note the new key format
old keys looked like
RUZ9H-5RUJKS-USSAW-23VUTY  (made up)
new look like
4f5RbEMlOl93wo5IOyoLWiYGR6jjUo (again made up)

and FWIW, those new keys don't work on Boot1.04, HW08,FW.18 even when supplied by rigol. :-//

1. No one currently has been able to install or flash in a old/new/replacement/etc BootLoader.
2. I have a older DSA815 with Main Board 4 and BootLoader 3.  So I'm not having any issue here, just trying to aid others.
3. When Rigole released firmware (FW) 00.01.09 we all, with either the Older or the Newer DSA815 hardware were NO LONGER able to install previous/older FW.
4. Although, those of us with BootLoader 2 or 3 could/can still revert to the older/previous firmware and consequently activate the FW embedded Options using the RigLoL Keygenerator.  And it doesn't matter if the Trials are still there or not, the Options will be activated.  After all they are still there in the FW, and then we can re-install the newest FW update.  And all is still there.
5. Re. Your -> RUZ9H-5RUJKS-USSAW-23VUTY  (made up), where new look like -> 4f5RbEMlOl93wo5IOyoLWiYGR6jjUo (again made up).  This is not actually the case, you have to enter the code without any 'dashes' (hyphens) when you Activate a Option in either a Old or Newer DSA815.  This has always been true (no Change here what-so-ever).
6. I don't think that the version 4 BootLoader has anything to do with not being able to Activate the Option (hey, I could be wrong).
7. Although if you could get BootLoader 2 or 3 in your Newer DSA815, then you also would be able to downgrade to FW00.01.08, or earlier (with the FW Install Boot Method) and Activate the Options, and then install the very latest FW again.
8. If you are not familiar with the DSA815 'FW Install Boot Method' I posted it below (Reply #4355).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on May 11, 2017, 12:50:46 pm
The DSA815 'FW Install Boot Method'
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on May 12, 2017, 05:17:30 pm
1. No one currently has been able to install or flash in a old/new/replacement/etc BootLoader.
understood, but I have seen no one try to flash (via jtag) a bootloader, and that is my comment
3. When Rigole released firmware (FW) 00.01.09 we all, with either the Older or the Newer DSA815 hardware were NO LONGER able to install previous/older FW.
again, understood
5. Re. Your -> RUZ9H-5RUJKS-USSAW-23VUTY  (made up), where new look like -> 4f5RbEMlOl93wo5IOyoLWiYGR6jjUo (again made up).  This is not actually the case, you have to enter the code without any 'dashes' (hyphens) when you Activate a Option in either a Old or Newer DSA815.  This has always been true (no Change here what-so-ever).
simply forgot the remove the dashes when I pasted it in from riglol
6. I don't think that the version 4 BootLoader has anything to do with not being able to Activate the Option (hey, I could be wrong).
my assertion is that the bootloader is an obstacle to being able to do this and finding a way to reflash to v1.03 may help
7. Although if you could get BootLoader 2 or 3 in your Newer DSA815, then you also would be able to downgrade to FW00.01.08, or earlier (with the FW Install Boot Method) and Activate the Options, and then install the very latest FW again.exactly
8. If you are not familiar with the DSA815 'FW Install Boot Method' I posted it below (Reply #4355).
one of the first things I tried when i got my DSA815

so as I understand the blackfin processor the boot loader exists at 0x20000000 (may have the number of 0's incorrect there)
if we have a dump (via jtag) of that area, from a 1.03 bootloader. we can try to flash that 1.03 version in and see if we can then revert back using the post you mention above.
once back, install the keys via riglol, then upgrade back to current version.
yes its risky,  but if it works we might have a path to applying keys on newer units.

the other comment on key format was to point out the very differ format of the keys between <FW1.09 and >FW1.09
and the fact that rigol can not generate a trial key that even works.   they broke thier own system.  that's a bug they should fix.
i for example can not trial the SSC-DSA even though they provided the key.  I would have to purchase it and hope it worked which they assure me the real keys work.   well if the real keys work, fix the trial keys.  since its obviously possible to do so.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on May 13, 2017, 02:13:48 pm
DSA800 Boot Loader:    It is customary for electronic equipment manufacturers to store their Boot Loader in ROM, EROM, ERAM, etc;  in a form of Protected Memory.  Not necessarily to prevent hacking, but to safe guard it from corruption.  Because once corrupted (and it has to be retained for the Life Of The Equipment) the unit is dead in its tracks, and re-installation of firmware isn’t generally possible.  So then,  >  Back To The Factory.  That’s why I said the changing the firmware will probably be tricky.  The task of the Boot Loader is primarily to just boot up the system firmware upon equipment power up, to check and control firmware updates, changes, and installation methods.  Not to prevent alterations of installed firmware.  The firmware, its checksum(s), etc, do that job.  So the Boot Loader doesn’t itself prevent someone from hacking the Rigol Options.

We know that the Rigol DP800 Series is an exception to using protected memory for the Boot Loader.  Because Rigol provided a new Boot Loader along with at least one of its firmware updates.

Hopefully someone can figure out how to go back to a earlier Boot Loader in the DSA815.  Although if its protected, and very likely it is, especially in the newer hardware Main Boards, then it may not be easy at all.  It would have been very easy for Rigol to add a Boot ROM in the newer boards (v. 7 and above), and then it would be much more difficult to change, But Not Impossible.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: smgvbest on May 13, 2017, 03:37:22 pm
DSA800 Boot Loader:    It is customary for electronic equipment manufacturers to store their Boot Loader in ROM, EROM, ERAM, etc;  in a form of Protected Memory.  Not necessarily to prevent hacking, but to safe guard it from corruption.  Because once corrupted (and it has to be retained for the Life Of The Equipment) the unit is dead in its tracks, and re-installation of firmware isn’t generally possible.  So then,  >  Back To The Factory.  That’s why I said the changing the firmware will probably be tricky.  The task of the Boot Loader is primarily to just boot up the system firmware upon equipment power up, to check and control firmware updates, changes, and installation methods.  Not to prevent alterations of installed firmware.  The firmware, its checksum(s), etc, do that job.  So the Boot Loader doesn’t itself prevent someone from hacking the Rigol Options.

We know that the Rigol DP800 Series is an exception to using protected memory for the Boot Loader.  Because Rigol provided a new Boot Loader along with at least one of its firmware updates.

Hopefully someone can figure out how to go back to a earlier Boot Loader in the DSA815.  Although if its protected, and very likely it is, especially in the newer hardware Main Boards, then it may not be easy at all.  It would have been very easy for Rigol to add a Boot ROM in the newer boards (v. 7 and above), and then it would be much more difficult to change, But Not Impossible.

granted, however the DSA815 support boot from USB and the blackfin supports uart boot.  so if we have the boot code in LDR format and put that on a USB drive or load via uart to get 1.03 in then could we not backload FW1.0x then?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on May 13, 2017, 09:13:28 pm
granted, however the DSA815 support boot from USB and the blackfin supports uart boot.  so if we have the boot code in LDR format and put that on a USB drive or load via uart to get 1.03 in then could we not backload FW1.0x then?
Hi Sandra:  The Blackfin's interface capability can be limited/overridden by the instructions from the Boot Loader. Or purposely left out by the hardware designer for expediency because it wasn't required for the task.  I think that the current .04 Boot Loader most likely preempts doing this, so I think someone will have to directly force a .03 Boot Loader (or equivalent) in place of the .04.
I don't have any vested interest here, because I have the original hardware with all of the permanent Options (so far anyway).  If I had the newer unit I would be charging into this relentlessly with a DSA815 open on my bench, to try to at least understand high level system architecture used.  I did this for my units Front End, LOs, Mixers, and IFs through to the DSP.  https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg1059060/#msg1059060 (https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg1059060/#msg1059060)
You may want to consider sketching out your units digital control logic surrounding the firmware and its management.  This should help shed more light on all this.  I believe that all of the involved ICs have vendor P/Ns, and a few may have SMT Codes.  Doing this with Peter's info may help pull it together.
EOT and Cheers, Ted

Edit:  I think that this discussion should moved back here ->  'Re: Spectrum Analyzer - Rigol DSA815'  to get all the interested and knowledgeable parties in this matter involved.

Please go to  'Re: Spectrum Analyzer - Rigol DSA815'  to follow this subject:  https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg1207904/#msg1207904 (https://www.eevblog.com/forum/testgear/spectrum-analyzer-rigol-dsa815/msg1207904/#msg1207904)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on May 17, 2017, 09:41:46 pm
some ppl asked for it, finally found that stuff again:

DS2000 stuff:

IDA Pro Signatures: http://www.filedropper.com/showdownload.php/ds2000cybernet23072013 (http://www.filedropper.com/showdownload.php/ds2000cybernet23072013)
LDR Tool: http://www.filedropper.com/geltoolsrctar (http://www.filedropper.com/geltoolsrctar)
Custom LDR binary: http://www.filedropper.com/rigolds2000customlcdtar (http://www.filedropper.com/rigolds2000customlcdtar)
UBOOT Custom: http://www.filedropper.com/uboot-201404ds2000tar (http://www.filedropper.com/uboot-201404ds2000tar)


DG4000 stuff:

Firmwares, CEN, IDB files: http://www.filedropper.com/dg4000tar_1 (http://www.filedropper.com/dg4000tar_1)

DS815 stuff:

DSA815 Dump + IDA: http://www.filedropper.com/dsa815 (http://www.filedropper.com/dsa815)


have fun


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: RoGeorge on May 18, 2017, 06:37:59 am
...
DG4000 stuff:
Firmwares, CEN, IDB files: http://www.filedropper.com/dg4000tar (http://www.filedropper.com/dg4000tar)
...

Thank you, but this download didn't worked for me. I tried with 2 different computers, and they both say "unexpected end of archive", "file is broken".

Could you check, please?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on May 19, 2017, 12:47:52 am
reup'ed and updated the link, try that one.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: RoGeorge on May 19, 2017, 07:52:34 am
Thank you for re-uploading, but still not working for me.

In Win10 the 7zip gives "unexpected end of archive" then hang.
In Debian 8, the same:
Code: [Select]
rogeorge@debian80:~$ cd Downloads/
rogeorge@debian80:~/Downloads$ gunzip -t DG4000.tar.gz

gzip: DG4000.tar.gz: not in gzip format
rogeorge@debian80:~/Downloads$ tar -xvzf DG4000.tar.gz -O > /dev/null

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
rogeorge@debian80:~/Downloads$ md5sum DG4000.tar.gz
74fa6a60981025eee721ae1bc76d8054  DG4000.tar.gz
rogeorge@debian80:~/Downloads$ sha1sum DG4000.tar.gz
30aa545b6339e51e03db70b29b91ada9dea60cf1  DG4000.tar.gz
rogeorge@debian80:~/Downloads$ file DG4000.tar.gz
DG4000.tar.gz: POSIX tar archive (GNU)
rogeorge@debian80:~/Downloads$ cp DG4000.tar.gz DG4000.tar
rogeorge@debian80:~/Downloads$ tar xvf DG4000.tar
DG4000/
DG4000/license_gen/
DG4000/license_gen/cengen
DG4000/license_gen/cengen.zip
DG4000/license_gen/cengen.c
DG4000/license_gen/license.zip
DG4000/license_gen/.DS_Store
DG4000/license_gen/build.sh
DG4000/license_gen/license.CEN
DG4000/license_gen/diff
DG4000/license_gen/._.DS_Store
DG4000/license_gen/work1/
DG4000/license_gen/work1/main.c
DG4000/license_gen/ix
DG4000/lxi_test/
DG4000/lxi_test/dbgcmd.bin
DG4000/lxi_test/._dbgcmd.bin
DG4000/lxi_test/my_lxi_command.bin
DG4000/mem_dump/
DG4000/mem_dump/dg4000_async0.bin
DG4000/mem_dump/._dg4000_lo1.bin
DG4000/mem_dump/dg4000_memdump.tar.gz
DG4000/mem_dump/dg4000_scratch.bin
DG4000/mem_dump/ivt.bin
DG4000/mem_dump/dg4000_data_a.bin
DG4000/mem_dump/kkkkk.bin
DG4000/mem_dump/dg4000_lo1.bin
tar: Unexpected EOF in archive
tar: rmtlseek not stopped at a record boundary
tar: Error is not recoverable: exiting now
rogeorge@debian80:~/Downloads$ gunzip DG4000.tar.gz

gzip: DG4000.tar.gz: not in gzip format
rogeorge@debian80:~/Downloads$ gunzip DG4000.tar
gzip: DG4000.tar: unknown suffix -- ignored
rogeorge@debian80:~/Downloads$

Do you have the same md5 or sha1 checksum on your PC, please?
Am I doing something wrong?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: McBryce on May 19, 2017, 08:02:18 am
I tried downloading it (windows 7). I get the same "unexpected end of archive", but it still allows me to extract all the files and they seem to be ok.

McBryce.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on May 19, 2017, 11:49:25 pm
Code: [Select]
sha1sum DG4000.tar.gz
ea51691d00365fe47bc3cf081667c47f8699526d  DG4000.tar.gz
Code: [Select]
gzip -dc DG4000.tar.gz |tar -vxf -
DG4000/
DG4000/license_gen/
DG4000/license_gen/cengen
DG4000/license_gen/cengen.zip
DG4000/license_gen/cengen.c
DG4000/license_gen/license.zip
DG4000/license_gen/.DS_Store
DG4000/license_gen/build.sh
DG4000/license_gen/license.CEN
DG4000/license_gen/diff
DG4000/license_gen/._.DS_Store
DG4000/license_gen/work1/
DG4000/license_gen/work1/main.c
DG4000/license_gen/ix
DG4000/lxi_test/
DG4000/lxi_test/dbgcmd.bin
DG4000/lxi_test/._dbgcmd.bin
DG4000/lxi_test/my_lxi_command.bin
DG4000/mem_dump/
DG4000/mem_dump/dg4000_async0.bin
DG4000/mem_dump/._dg4000_lo1.bin
DG4000/mem_dump/dg4000_memdump.tar.gz
DG4000/mem_dump/dg4000_scratch.bin
DG4000/mem_dump/ivt.bin
DG4000/mem_dump/dg4000_data_a.bin
DG4000/mem_dump/kkkkk.bin
DG4000/mem_dump/dg4000_lo1.bin
DG4000/mem_dump/dg4062.idb
DG4000/mem_dump/dg4000_async2.bin
DG4000/mem_dump/dg4062.map
DG4000/mem_dump/dg4000_data_b.bin
DG4000/mem_dump/iar
DG4000/mem_dump/dg4000_async1.bin
DG4000/mem_dump/secure_code.txt
DG4000/mem_dump/dg4000_sysmmr.bin
DG4000/mem_dump/dg4000_inst_ab.bin
DG4000/mem_dump/dg4000_inst_c.bin
DG4000/mem_dump/license.CEN
DG4000/mem_dump/dg4000_async3.bin
DG4000/mem_dump/dg4000_coremmr.bin
DG4000/mem_dump/facts.txt
DG4000/mem_dump/aaaaa.bin
DG4000/mem_dump/dg4062.rar
DG4000/dumpeth.txt
DG4000/model_sub/
DG4000/model_sub/dg4162.asm
DG4000/model_sub/dg4102.clean
DG4000/model_sub/dg4102.asm
DG4000/model_sub/dg4162.clean
DG4000/.DS_Store
DG4000/._DG4000Update.GEL
DG4000/FW0.7/
DG4000/FW0.7/._DG4000Update.GEL
DG4000/FW0.7/DG4000Update.GEL-FW0.7.zip
DG4000/FW0.7/DG4000Update.GEL
DG4000/gelfile/
DG4000/gelfile/dump_20400000.bin
DG4000/gelfile/dump_20470000.bin
DG4000/gelfile/dump_20300000.bin
DG4000/gelfile/crc_table.h
DG4000/gelfile/dump_2046fc00.bin
DG4000/gelfile/dump_209b0000.bin
DG4000/gelfile/dump_20440000.bin
DG4000/gelfile/dump_20440400.bin
DG4000/gelfile/dump_20460000.bin
DG4000/gelfile/dump_20460400.bin
DG4000/gelfile/dump_20db0000.bin
DG4000/gelfile/dump_20830000.bin
DG4000/gelfile/dump_205b0000.bin
DG4000/gelfile/dump_20040000.bin
DG4000/gelfile/dump_20443800.bin
DG4000/gelfile/gelfile.c
DG4000/gelfile/build.sh
DG4000/gelfile/dump_20443400.bin
DG4000/gelfile/gelfile
DG4000/gelfile/dump_20bb0000.bin
DG4000/gelfile/DG4000Update.GEL
DG4000/gelfile/dump_207b0000.bin
DG4000/license.CEN
DG4000/lxi.py
DG4000/test.RAF
DG4000/bootld/
DG4000/bootld/dg4062_boot_async3.bin
DG4000/bootld/dg4062_boot_ram.bin
DG4000/bootld/dg4062_boot_async2.bin
DG4000/bootld/dg4062_boot_srama.bin
DG4000/bootld/dg4062_boot_smmr.bin
DG4000/bootld/dump.txt
DG4000/bootld/dg4062_boot_cmmr.bin
DG4000/bootld/dg4062_boot_ram.idb
DG4000/bootld/dg4062_boot_dump.zip
DG4000/bootld/dg4062_boot_instab.bin
DG4000/bootld/dg4062_boot_instc.bin
DG4000/bootld/dg4062_boot_async1.bin
DG4000/bootld/dg4062_boot_async0.bin
DG4000/bootld/dg4062_boot_sramb.bin
DG4000/addr_0.3.txt
DG4000/._.DS_Store
DG4000/newoffset
DG4000/._license.CEN
DG4000/DG4000Update.GEL
DG4000/FW0.6/
DG4000/FW0.6/DG4000Update.GEL-FW0.6.zip
DG4000/FW0.6/._DG4000Update.GEL
DG4000/FW0.6/DG4000Update.GEL
DG4000/test.ldr
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: RoGeorge on May 20, 2017, 05:42:27 am
My download doesn't have the same checksum as your file. I tried also resetting my router, getting a new IP, fire up a clean Debian VMware machine, download without any addblockers, and I still get the same wrong checksum:
Code: [Select]
sha1sum DG4000.tar.gz
30aa545b6339e51e03db70b29b91ada9dea60cf1  DG4000.tar.gz

Thank you for your patience cybernet, but please don't waste any more time with this. I give up.

I guess something is wrong with that file sharing site.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: neslekkim on May 21, 2017, 12:25:35 pm

...
DG4000 stuff:
Firmwares, CEN, IDB files: http://www.filedropper.com/dg4000tar (http://www.filedropper.com/dg4000tar)
...

Same for me, this file is corrupt.

DG4000 stuff:

Firmwares, CEN, IDB files: http://www.filedropper.com/dg4000tar_1 (http://www.filedropper.com/dg4000tar_1)


And this one doesn't even start to download on chrome, but with IE I got an corrupt file, smaller than from the previous link.


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: PA0PBZ on May 21, 2017, 01:05:12 pm
Same here, 153MB first file, 113MB the second one.
Also, if I can trust the catalog the contents of the mem_dump folder are different, the 2nd one has more bin files but the idb is missing.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: phy14 on June 12, 2017, 06:05:23 pm
thanks!! :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 26, 2017, 09:20:23 pm
some stuff that had issues:

https://workupload.com/file/tqpFggS
https://workupload.com/file/ffShyMm
https://workupload.com/file/XAuFL37
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on July 08, 2017, 12:32:02 pm
Guys, I can't find the link to generate Serial Keys for the MSO1074Z scope... That rigup tool online site!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sokoloff on July 08, 2017, 01:07:18 pm
Guys, I can't find the link to generate Serial Keys for the MSO1074Z scope... That rigup tool online site!
google for "riglol" (yes, with the extra "l")
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on July 08, 2017, 01:29:07 pm
Guys, I can't find the link to generate Serial Keys for the MSO1074Z scope... That rigup tool online site!
google for "riglol" (yes, with the extra "l")

I found the site. Thanks!

But where do I see my Private Key in order to be able to generate the keys?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sokoloff on July 08, 2017, 02:27:46 pm
I found the site. Thanks!

But where do I see my Private Key in order to be able to generate the keys?
The site generates the private key. You enter your serial number and the 4 alpha code of the options you want to enable and you get a private key out. (Yeah, the web UI makes it look like you need to enter something there. You don't.)

Also note: I found it way easier to hook the Rigol up to my network and telnet into it and do the upgrade via the command line (where I could easily copy/paste the serial number and the private key). When you do that, do not enter the dashes.

Code: [Select]
:SYST:OPT:INST <private key without dashes>
is the command you need.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ebastler on July 08, 2017, 02:32:01 pm
I found the site. Thanks!
But where do I see my Private Key in order to be able to generate the keys?

Not sure whether you are "1337" enough for this...  ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on July 08, 2017, 06:49:28 pm
I found the site. Thanks!
But where do I see my Private Key in order to be able to generate the keys?

Not sure whether you are "1337" enough for this...  ;)

What you mean?
I have already dumped my Rigol memory and generated the Serial Keys to my model. And I could not use that site because the tool was buggy and some member from here fixed that bug somehow and generated the keys to my model. But I'm helping a friend of mine has just bought an MSO1074Z.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ebastler on July 08, 2017, 07:54:38 pm
What you mean?

Just kidding, since you asked several questions about the most simple step in this "hacking" process.
No offense was intended!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: psysc0rpi0n on July 14, 2017, 10:02:28 pm
What you mean?

Just kidding, since you asked several questions about the most simple step in this "hacking" process.
No offense was intended!

I couldn't even understood it so no offence could be taken! Just that I'm still in ignorance!  :-// ::)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: SkyMaster on July 14, 2017, 11:50:36 pm

I couldn't even understood it so no offence could be taken! Just that I'm still in ignorance!  :-// ::)

ebastler was pulling your leg when making reference to "1337"

https://en.wikipedia.org/wiki/Leet

He was not serious

:)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ivi_yak on July 27, 2017, 11:57:06 pm
hi, what kind of software you use?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: LeoIt on August 20, 2017, 10:16:30 pm
Hello everybody,

I have a question about DSA815....

I searched a lot in the forum to get information about the component U1220 it is a SOIC8 marked as MQD2C.... I didn't find what is it, somebody out there could help, it seems connected to the 4 pins strip near to the power supply connector, I suppose it it something controlled by TWI or SPI ?

May be it is a serial flash that contains some calibration or configuration data ?

Any help is much appreciated !

Many Thanks.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: TurboTom on August 20, 2017, 11:40:25 pm
This chip appears to be an 8 bit microcontroller, MC9S08QD2, see the datasheet here: http://www.nxp.com/docs/en/data-sheet/MC9S08QD4.pdf (http://www.nxp.com/docs/en/data-sheet/MC9S08QD4.pdf).

If the 2k of memory that it contains is enough for calibration data is something I'ld doubt. But it chould well be involved in license management. Yet more probable is that it's used for something much more mundane, like generating a power good signal/reset circuitry as it features four A/D channels. Food for thought...

Cheers,
Thomas
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: LeoIt on August 21, 2017, 07:58:12 pm
Thank you very much TurboTom !

You are right, it sould be HCS08 Micro, the Power supply pins are quite strange, not much used (+3 and -4)  and are compatible, also the strip connectio to pin 1 - Reset and  2 - BKGD are conneted to the strip (probably used to pogram o configuration and.... Single wire "debugging" ;-).....

I agree with you, its memory (2K Flash) is too small for DSA calibration data.....

Because its power supply seems separated from the main DSP and related chips, I think it will be used to power up the instruments....
I mean to make the fading blink of the ON/OFF button and to check its status to turn ON and OFF the entire system.

I hope, but not sure, it is not used like a sort of harware key to identify each device.
Or used to store the MAC address and other unique information of the instrument (but for this they should use the U1105 FRAM .... ? ).

Thank you again for your help....

Bye...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: TurboTom on August 22, 2017, 05:10:45 pm
You're most probably right: The HCS08 variant appears to be part of several of Rigol's designs that feature the BlackFin processor as the digital core and a soft power button, see here the DS2000 (as per Dave's teardown photos, in the lower right corner, yet here it's the 4kB variant):
https://www.flickr.com/photos/eevblog/8022098878/in/album-72157631618295437 (https://www.flickr.com/photos/eevblog/8022098878/in/album-72157631618295437)

Similar situation for the DM3068, the DG4000 series and also the DS4000, yet in the latter Rigol uses a higher pin count / memory variant of the HCS08 series, the MC9S08JM60.

In contrary, the DS1000Z series doesn't seem to contain the HCS08 controller and this instrument features a "hard" power switch, so the usage of the controller for the soft power circuitry is very likely.

Cheers.
Thomas
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: chevdor on August 23, 2017, 09:48:19 pm
I have seen some questions several times (while searching myself) so I will try to provide a few facts based on my trials.

Using a Mac with an Olimex ARM-USB-OCH-H does work.
Just don´t expect to see anything in /dev/cu*. This is OK so.

My scope is a MSO1104Z-S. This is a recently purchased (2017-08) scope with the latest firmware (00.04.04.SP3).
The board shows version v01.04_20141024 on the PCB.

You guys probably saw the great video at: https://www.youtube.com/watch?time_continue=7&v=OvcGn_ScG5w (https://www.youtube.com/watch?time_continue=7&v=OvcGn_ScG5w)
This video helps a lot if you take your time. Highly recommended. Yes, you will need to open your scope.

A little surprise though, the JTAG headers are not longer part of the board. You still have the holes and traces in the PCB but no header. Surprising but not really an issue.

New comers will probably miss the openocd config files. They are here:
https://raw.githubusercontent.com/arduino/OpenOCD/master/tcl/target/imx28.cfg (https://raw.githubusercontent.com/arduino/OpenOCD/master/tcl/target/imx28.cfg)
https://raw.githubusercontent.com/arduino/OpenOCD/master/tcl/interface/ftdi/olimex-arm-usb-ocd-h.cfg (https://raw.githubusercontent.com/arduino/OpenOCD/master/tcl/interface/ftdi/olimex-arm-usb-ocd-h.cfg)

Compiling rigup on a Mac is a breeze. Follow the guides.

You may get an error when running openocd:
Error: An adapter speed is not selected in the init script. Insert a call to adapter_khz or jtag_rclk to proceed.

No panic, you can add the following line:
Code: [Select]
adapter_khz 5000as line 34 in imx28.cfg

I did a few tests regarding the speed. Some failed, I am not sure whether it was due to the speed or the temperature.
I used a few fans during the process...

adapter_khz 1000 => works, just damn slow. Expect a dump in around 40-50 minutes. I did not wait...
adapter_khz 5000 => works. Around 10:30 minutes for the dump.
adapter_khz 8000 => failed me, the scope rebooted
adapter_khz 10000 => failed me, the scope rebooted

With
Code: [Select]
adapter_khz 5000, the dump will take about 10:30 minutes. I got it to work 2/2 times with pins simply hanging around in the PCB holes... Do not shake your desk  :-DD and make sure your fan does not move things around too much.

I did not apply the 0x1C080 (100 MHz) obviously.

Respect to the team who put that together.  :-+

Rigol plays it smart on that one as I am sure they are aware that they end up selling more of there 'hackable' scopes, thus making more $$$ than selling a few software options that are anyway harder to buy on their site than it is to find this thread!

A little warning though, you do need a few tools to get this to work:
- TX10 screwdriver
- 14mm flat wrench helps
- a fan is probably recommended
- a good lamp :)
- some stickers (not for the sticker, but for the waxed paper supporting them)
- clean headers (2x 5 pins). Those won´t be soldered so clean them up or use new ones. Forget those 5 years old headers you used 20 times...
- a few clean cables: if you start messy, chances of success will decrease...

Good luck

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: El Viking on September 02, 2017, 01:39:33 pm
hi,

On a MSO1074z, software version 00.04.04.SP1, board version 2.1.4 a very new scope, delivery this week. Jtag was not populated.
I use a PC on W10-64-pro.
I setup olimex arm...h (some problems with driver solve with zadig).
I use rigup w64 version 0.4.2 from
I dump memory with openocd 0.10.0

first time I have used rigup-0.4.2-x86_64-win.zip  ==>good txt file, with good serial number, but license number don't run==>invalide licence
I made many dump.... same txt file, same key...
Second time I try with rigup-0.4.2-i686-win.zip==> same txt file, but license key accepted by the scope...
Now MSO is full option, I have all ready testing the RS232 decode, it run correctly.

Many thankssss to the working team!!!!


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ironcurtain on November 08, 2017, 05:33:52 am
I'm really considering getting a Rigol since I have to diagnose some RFI issues in some projects and it will come handy for lots of stuff down the line. I have IDA 6.X with the decompilers (did not pay for the last upgrade haha!) and can do reversing if needed.

What is the status of the hack right now? Is there a bandwidth upgrade from 70 to 100 or 100 to 200 as it used to be? How about options?
If I end up getting a Rigol I will likely buy off Baronix since I'm in Europe... so I'm limited to whatever they are shipping right now.

Luckily it seems you can downgrade FW since they don't use any sort of e-fuses...

Cheers!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: H.O on November 10, 2017, 04:28:39 pm
"A Rigol" is pretty vague since they have at least 4 different series of scopes and DSO/MSO models in each series (except possibly the DS6000 series). If I'm not mistaken the unlock process is a bit different on different models. For some you might need to dump the firwmware while on other all you need to do is generate an option key and install it.

I'm not up to speed on it all but if you specify which model you're considering someone might give you a better answer.

With that said, their Ultra Vision platform is >5 years old now and depending on your needs there might be other suitable options.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: wldshy on November 13, 2017, 02:00:36 pm
hi,
I really wanna know, whether the new Rigol DS2000E/4000E series can be hacked. especially the DS4014E is a very affordable choice, only if can be hacked to 500MHz BW.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ironcurtain on November 18, 2017, 03:02:11 am
"A Rigol" is pretty vague since they have at least 4 different series of scopes and DSO/MSO models in each series (except possibly the DS6000 series). If I'm not mistaken the unlock process is a bit different on different models. For some you might need to dump the firwmware while on other all you need to do is generate an option key and install it.

I'm not up to speed on it all but if you specify which model you're considering someone might give you a better answer.

With that said, their Ultra Vision platform is >5 years old now and depending on your needs there might be other suitable options.

Thanks a lot for responding. I should have been more specific:

- I would like at least 200MHz achievable bandwidth either thru hacks or off the shelf. If I can score a DSO going higher than that through hacks, that would be great.
- Use will be debugging, looking at unknown signals from MCUs, diagnosing issues with resonators and some RF work, mostly repairs and such.
- I would love to have the ability to get FFTs and other math transformations. If it has a built-in decoder for signals... that would even be better!

I was looking at this Siglent unit:
https://www.batronix.com/shop/oscilloscopes/Siglent-SDS1202X+.html (https://www.batronix.com/shop/oscilloscopes/Siglent-SDS1202X+.html)

But Rigol seems a lot more geared towards hobbyists, so I will definitely appreciate your suggestions.  Either way I have reverse engineering experience and got the necessary tools at hand including a (legitimate) pro licensed IDA with decompilers :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: H.O on November 18, 2017, 12:50:03 pm
FFT is not something I personally use but from what I understand Rigol isn't doing very well in that department (you can Always export the data and perform the FFT on the PC if needed).

Since you're considering the Siglent SDS1202X I'm guessing 2 channels is "all you need"? If that's the case and 200MHz is "enough" then there's a lot to choose from but I'd personally put 4 channels way above good FFT functionality and I would not spend money on a built in function gen, I think it's better to have a separate unit. But that's me.

Take a look at the Siglent SDS1202X-E, and if you need four channels wait for the four channel version in that series (I hear Dave has one for teardown/Review so it'll probably show up sooner than later).

I don't know about hacks on anything except Rigol and I don't know if the new DS2000E and DS4000E series are hackable and if so to what extent. All I can really say from personal experience is that the DS4000 series ARE (closed case) hackable to enable full bandwidth (500MHz) and all the options (which you now get for free now anyway).

There are SO many considerations to make (which is shown again and again and again in all the "which scope is right for me threads") but, as was said in another thread if you want 4 channels and lot bandwidth then a DS4014 probably STILL is a good option despite it being 5-6 years old now.

For a general purpose scope, today, I'd want the R&S RTB2000 and I probably would've gotten one if the bastards would have offered the introductor deal in Europe and not only in the US.

And at the lower end the upcoming 4 channel Siglent is going to be interesting, since you mention 200MHz that might just be the unit for you.

But comparing a $400-500 Siglent SDS1202X-E to a $2000 Rigol DS4000 or a $3000 RTB2004 (200MHz) isn't really "fair" from any perspective.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sebastos08 on December 18, 2017, 01:16:23 pm
Hi all,

any chance to receive a "riglol" item extension or any tips to crack my options for my new dl3021?

thanks in advance
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: gantarone on January 03, 2018, 07:32:29 pm
Hi,
rigol  DS1074Z Plus (S series)
Software Version 00.04.04.SP3
Board Version  6.1.4
I tried using Jtag but with no success.....
after the dump (with sagger JLINK)  file size around 67,1MB
after command:
./rigup scan mio.bin > mio.txt
Scanning 'mio.bin' failed: No keys
Please Help!!!

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: edgelog on January 04, 2018, 05:57:34 am
Hi,
rigol  DS1074Z Plus (S series)
Software Version 00.04.04.SP3
Board Version  6.1.4
I tried using Jtag but with no success.....
after the dump (with sagger JLINK)  file size around 67,1MB
after command:
./rigup scan mio.bin > mio.txt
Scanning 'mio.bin' failed: No keys
Please Help!!!

I found that in my scope the code sequence was different. I thought that was just the MSO, but it's worth a try. Look for 0x02 0x00 0x84 0x00 0x10 0x00 with a hex editor.

See my description at:

https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg1191044/#msg1191044 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg1191044/#msg1191044)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: gantarone on January 04, 2018, 01:37:33 pm
Thanks edgelog, I had already tried,
but I probably did not clean up the old compilation,,,,
I tried again now and bamm found the codes !!!!THANKS!!!!!
For now I can not try the codes I have to wait 12h .....(too many try)

I discovered other 5 codes in my dump!!!!,
using the simple command(on OSX, but i think is the same on Linux):
strings -n 28 dump.bin >> dumpoutput.txt
you will find so many text (in dumpoutput.txt), but if you have patience you will find other codes without use rigup (two at the end of file (dumpoutput.txt) other in the middle)
I tried just one and in one shot enabled all the options except 100M bandwidth !!!!!! :-+ :-+ :-+ :-+

PS Thanks Again edgelog!!!!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: gantarone on January 05, 2018, 10:28:21 am
Thanks edgelog!!!
it works!!!
before
model: 1074z Plus S

Now:
all option plus 100Mhz!!! and function generator ok!!! have not tried MSO  but it seems to work.
model :DS1104Z Plus
Software Version : 00.04.04.SP3
Board Version 6.1.4
 :) :) :) :) :) :) :) :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: edgelog on January 05, 2018, 05:00:40 pm
Thanks edgelog!!!
it works!!!

Glad I could help!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: metalmanbaris on March 19, 2018, 07:42:39 pm

I know it has bees asked million times... I read all posts but I didn't find my answer ...

I have a DS1104Z Plus.. Version 04.04 SP3
I did the memory dump.. I scanned the keys..
But when I use the rigup and use the keys on the scope I got "invalid license key" error.

I used 0.4.1 and 0.4.2 of rigup   (Hacked up for MSO1000Z(-S) rmd79, 0ff eevblog.com)

What am I doing wrong...? Isn't the DS1104Z Plus hackable.... Should I use a different rigup tool ?

Thanks
Baris (TA7W)



 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: edgelog on March 19, 2018, 08:45:45 pm

I have a DS1104Z Plus.. Version 04.04 SP3
I did the memory dump.. I scanned the keys..
But when I use the rigup and use the keys on the scope I got "invalid license key" error.

I used 0.4.1 and 0.4.2 of rigup   (Hacked up for MSO1000Z(-S) rmd79, 0ff eevblog.com)

What am I doing wrong...? Isn't the DS1104Z Plus hackable.... Should I use a different rigup tool ?

The MSO1000 and the DS1000 are not exactly the same. The rigup you should use is not the MSO one, but the DS one. There's a small difference in the string it's looking for in the memory dump. OTOH, if you used the wrong rigup, I would have expected it not to find any keys, and that's not your case, it seems.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: edgelog on March 19, 2018, 08:49:04 pm
I have a DS1104Z Plus.. Version 04.04 SP3
I did the memory dump.. I scanned the keys..
But when I use the rigup and use the keys on the scope I got "invalid license key" error.

I also seem to have a vague memory of others with that problem if they cut/pasted the codes into the scope using the terminal interface. Some hidden characters got copied along. Have you tried entering the codes by hand through the scope's own interface?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: metalmanbaris on March 20, 2018, 07:56:58 pm
Have you tried entering the codes by hand through the scope's own interface?

Yes I did...same error.. "invalidlicense"

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: metalmanbaris on March 20, 2018, 08:04:21 pm
The MSO1000 and the DS1000 are not exactly the same. The rigup you should use is not the MSO one, but the DS one. There's a small difference in the string it's looking for in the memory dump. OTOH, if you used the wrong rigup, I would have expected it not to find any keys, and that's not your case, it seems.
Yes you're right but I got the result with the MSO (maybe it is because my DS is a PLUS version... maybe)
But the keys generated with rigup license are invalid....

Do people managed to pull out the right KEYS for DS1104Z-Plus ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: edgelog on March 20, 2018, 08:46:12 pm
Do people managed to pull out the right KEYS for DS1104Z-Plus ?

Good question. I really don't know if anyone did it with that specific version.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: edgelog on March 20, 2018, 08:49:27 pm
Have you tried entering the codes by hand through the scope's own interface?

Yes I did...same error.. "invalidlicense"

Ok, one more thing to try. I have a vague recollection that someone had a problem entering the keys into rigup. Something with the fields not being really empty even though they look blank. Backspace first, or select all and delete, then enter the keys.

I'm sorry my recollections aren't any sharper, but it's worth trying.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Daruosha on April 15, 2018, 06:07:27 am
With the help of new patched firmware developed by our forum member, @konnor,  you can take the memory dump of MSO1000z series scopes and extract the keys from the dump, no JTAG adaptor or any hardware effort or taking the scope apart is required anymore.

1- Download the pathed firmware from the first post of the this thread:
https://www.eevblog.com/forum/testgear/rigol-ds1000z-firmware-patch-plugins/msg1467130/#msg1467130 (https://www.eevblog.com/forum/testgear/rigol-ds1000z-firmware-patch-plugins/msg1467130/#msg1467130) . 
You have to download the two splited files, rename their extension to “rar” and extract the DS1000ZUpdate.GEL file out of the archive.

2- Copy the patched firmware file into a 4GB FAT32 formatted USB disk and put in to the scope,. After inserting the flash drive, scope prompts you to upgrade to firmware (into the same version if you have the latest version).

3- Once the patched firmware installation is done, connect your scope to your local network with an ethernet cable and make sure it's been connected and obtained an IP address. (if you don't have a DHCP server, you can manually assign a proper IP address from the menu). In order to make sure the scope is connected and reachable from your PC, try to ping its IP address and check the scope is responding.

4- For this step you need a windows machine, I used VirtualBox to host a new windows VM and run the utility. Download the required utility from this post:
https://www.eevblog.com/forum/testgear/rigol-ds1000z-firmware-patch-plugins/msg1478726/#msg1478726 (https://www.eevblog.com/forum/testgear/rigol-ds1000z-firmware-patch-plugins/msg1478726/#msg1478726)
and then extract it on your computer. Next from the “release” folder run the following command:

rigolif.exe r -ffw.bin -l0x3FFFFFF -a0x40000000

this command dumps the memory contents of your scope in to a file named “fw.bin”
During the memory dump process you may see a few errors, generally it's not a problem, but if in the next step you couldn't extract the keys, repeat the process from this step (step 4) again and continue.

5- Download the rigup tool from this URL: http://gotroot.ca/rigol/rigup-0.4.1-mso1000z.zip (http://gotroot.ca/rigol/rigup-0.4.1-mso1000z.zip) . For this step I used my MacOS X machine and simply build the executable file from the source code by running this command in the same folder which the downloaded file has been extracted:

make

if you have a windows machine, you have to compile the file yourself (I don't know which compiler and which settings is required). You can extract the keys from the dump file with this tool as well:
http://gotroot.ca/rigol/rigup-0.4.2-x86_64-win.zip (http://gotroot.ca/rigol/rigup-0.4.2-x86_64-win.zip)
(this is just extraction, to generate the license keys, you have to use the MSO1000z version of rigup).

6- Copy the fw.bin file (obtained from step 4) in to the same folder which you have extracted the rupup tool and run the following command:

rigup-0.4.2-x86_64-win.exe scan fw.bin > keys.txt

(of course you may need to modify the command, correct executable file name and paths and etc…)

Once the command finishes, you can check the extracted keys with this command:

type keys.txt

You must have a file contains something like this:

        Hacked up for MSO1000Z(-S) rmd79, 0ff eevblog.com

RC5KEY1:        6CDBAC1CCE16B5048F2425237A8A0EF4
RC5KEY2:        CFFED4830820DAA382AE39E5ACCDA639
XXTEAKEY:       E141B9AE1AA4773F5CF9B5B9341DB788
PUBKEY:         005497018B62F230
PRIVKEY:        0099FC5DFBE778D0
SERIAL:         DS1ZC182871920


If you have a generated file like this, bingo, you're almost done. The rest is generating the license keys. I assume generating the license codes are well documented and it's not required to mention it again here. However if you had any problem, please let us know and we'd help.
Title: Sniffing the Rigol DP711's flash (may apply to DP712 too)
Post by: borisbees on May 08, 2018, 04:47:25 am
I bought a Rigol DP711 power supply recently and came across this thread while researching. It looks like no-one has published anything about this model yet, so I'm taking a shot.

The DP711 uses a Winbond W25Q128FV (16MB) SPI flash chip to store its firmware and user settings. This chip supports Dual and Quad SPI, but it's hard-wired for standard SPI operation - HOLD/RESET, and WP (write protect) are directly connected to VCC. It's located on the digital board behind the screen, under the screen's flat-flex connector, and it's an easy-to-probe VSOP package.

Initially I used a logic analyzer to watch reads and writes during startup and various operations, but I've recently dumped the whole flash contents via a microcontroller. Conveniently, the Winbond chip lets you issue a single read command for address 0x0 and proceed to clock out its entire memory. The DP711 doesn't appear to touch the flash when left idling on the main screen, but it has a fairly strong pull-up on the chip-select pin of the flash when idle. Connecting CS to ground through a 100 ohm resistor was enough to overcome this without issue for an extended period of time.

I've only had a cursory look at the full firmware dump at this time. The rigup scan tool didn't find anything, so Rigol may have changed something in this model... One thing that stuck out like a sore thumb however was this:


000ce00a  00 00 00 00 00 31 32 33  34 35 36 00 00 00 01 05  |.....123456.....|


It shouldn't have needed a logic analyzer to find, but that's the System -> Calibration screen password  :palm:

I'll post more once I've had a better look at the flash dump.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DaBone_206 on July 15, 2018, 08:46:07 pm
Hello everybody,
I own a Rigol MSO1074Z-S. All attempts to hack, have failed so far  :scared:.
System Information:
SW. V.: 00.04.04.SP3
Board Version: 6.1.1

I used all the rigup versions that are available, but none leads to success.
For example, with option 0x1C001, I always get the following license key: AQSNGP3-JGLNNNH-ZDW33MA-WEX59CM
Since 2 years I try again and again to hack my Oszi so far without success. What am I doing wrong?
I have attached my dump maybe one gets another license key
https://www.dropbox.com/s/5ct1bipb1pdexnc/mso1074z.bin?dl=1 (https://www.dropbox.com/s/5ct1bipb1pdexnc/mso1074z.bin?dl=1)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DaBone_206 on July 16, 2018, 06:17:36 pm
what does these strange characters mean in the hashing?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: djdanielb on October 19, 2018, 08:56:12 am
Hi at all I'm DjDaniel.

I've just bought a DP711 power
Is there some solution to activate the extra features ?

Thank you a lot
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: entropie on November 09, 2018, 07:36:33 am
However if you had any problem, please let us know and we'd help.

hi there,
I own a Rigol MSO1074Z.

post #4400
1)-5) works fine for me,
i get a dump file from oszi (256mb)

6) the is a problem...
rigup-0.4.2-x86_64-win.exe scan fw.bin > keys.txt

gives me a "failed, No keys"

tryed with many dumps, what is going wrong?

please help a newcomer ;)
thanx..............
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: McBryce on November 09, 2018, 07:45:14 am
hi there,
I own a Rigol MSO1074Z.

#4400
1)-5) works fine for me,
i get a dump file from oszi (256mb)

6) the is a problem...
rigup-0.4.2-x86_64-win.exe scan fw.bin > keys.txt

gives me a "failed, No keys"

tryed with many dumps, what is going wrong?

please help a newcomer ;)
thanx..............

Are you definitely using the MSO rigup? There's a specific version of rigup for the MSO that's different to the DSO version.

McBryce.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: entropie on November 09, 2018, 07:56:59 am
i used this :

You can extract the keys from the dump file with this tool as well:
http://gotroot.ca/rigol/rigup-0.4.2-x86_64-win.zip (http://gotroot.ca/rigol/rigup-0.4.2-x86_64-win.zip)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: McBryce on November 09, 2018, 09:23:29 am
Use the MSO specific one he links to here:

5- Download the rigup tool from this URL: http://gotroot.ca/rigol/rigup-0.4.1-mso1000z.zip (http://gotroot.ca/rigol/rigup-0.4.1-mso1000z.zip) . For this step I used my MacOS X machine and simply build the executable file from the source code by running this command in the same folder which the downloaded file has been extracted:

McBryce.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: entropie on November 09, 2018, 10:41:42 am
ok,
got the keys :)

but now I stuck here..........

If you have a generated file like this, bingo, you're almost done. The rest is generating the license keys. I assume generating the license codes are well documented and it's not required to mention it again here.

I can not find a working license generator.
please be patient with me.............. :palm:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: entropie on November 09, 2018, 03:42:28 pm
At this point I am very confused and can not continue.
All generated licenses do not work

for example:
9CL3SZS-EWH9JYW-RRNXMYP-4D5PMSM    (NSH9 = 0x1C0FF)
That should not be (CSHY = 0x1C0FF) ??

I ask for help, otherwise I send the oszi into hell ... >:D

please....... :scared:

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: entropie on November 10, 2018, 08:23:53 am
finaly...........

got it to work with the right software,
many thanks to all supporters....:clap:
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ebastler on November 10, 2018, 11:44:33 am
got it to work with the right software,
many thanks to all supporters....:clap:

So, for the benefit of others who might read this later -- could you briefly summarize what you got wrong initially, and what constitutes "the right software"? Thanks!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ab#FFFF on January 26, 2019, 06:13:21 am
Can some1 please help me?

I have a MSO1104 scope and i tried to enable all features over LAN. Following Daruosha procedure, I upgrade the scope then I dump the fw.bin (~260Megs) a few times but the for some reason the tool rig 0.4.1 is unable to find the keys (I compile the tool under OSX with make clean/ make all). I tried the windows tool 0.4.2 but with same result.
The keys.txt look like this:

rigup scan - Version 0.4.1

        Hacked up for MSO1000Z(-S) rmd79, 0ff eevblog.com

I'm wondering what is wrong? Can some1 help?
thanks,
-a
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Daruosha on January 26, 2019, 06:22:09 am
Can some1 please help me?

I have a MSO1104 scope and i tried to enable all features over LAN. Following Daruosha procedure, I upgrade the scope then I dump the fw.bin (~260Megs) a few times but the for some reason the tool rig 0.4.1 is unable to find the keys (I compile the tool under OSX with make clean/ make all). I tried the windows tool 0.4.2 but with same result.
The keys.txt look like this:

rigup scan - Version 0.4.1

        Hacked up for MSO1000Z(-S) rmd79, 0ff eevblog.com

I'm wondering what is wrong? Can some1 help?
thanks,
-a

There's a bug in rigup scan tool. I don't remember what was the exact bug and where it was, but i remember you can fix it easily in the source code and build it yourself. Contact me over PM and send me your dump fie. I'll try to help you extract the keys.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ab#FFFF on January 26, 2019, 03:35:27 pm
Thanks Daruosha for your help.

... the last step seems to be to generate the keys by running rigup (0.4.1) with license option then use the serials for activation:

rigup license keys.txt option (ex.: rigup license keys.txt 0x1C001)

option (list of hex values):
(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
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ab#FFFF on January 26, 2019, 03:45:39 pm
rigup utility needs to be tweaked to work with some of MSO1000Z for a correct keys extractions; so, before compiling rigup 0.4.1 check below posting and modify eventually utils.c accordingly:
https://www.eevblog.com/forum/testgear/sniffing-the-rigol_s-internal-i2c-bus/msg1191044/#msg1191044 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol_s-internal-i2c-bus/msg1191044/#msg1191044)

hope helps,
-a
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sv1eia on January 27, 2019, 12:34:13 pm
With the help of new patched firmware developed by our forum member, @konnor,  you can take the memory dump of MSO1000z series scopes and extract the keys from the dump, no JTAG adaptor or any hardware effort or taking the scope apart is required anymore.

1- Download the pathed firmware from the first post of the this thread:
https://www.eevblog.com/forum/testgear/rigol-ds1000z-firmware-patch-plugins/msg1467130/#msg1467130 (https://www.eevblog.com/forum/testgear/rigol-ds1000z-firmware-patch-plugins/msg1467130/#msg1467130) . 
You have to download the two splited files, rename their extension to “rar” and extract the DS1000ZUpdate.GEL file out of the archive.

..

Hi,

My DS1104ZPlus has fw version 00.04.04.03.05 and the patched firmware is 00.04.04.03.02 so I think the instrument do not allow to downgrade, right?
How can we overcome this?

Or am I missing something?

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Daruosha on January 27, 2019, 01:00:11 pm
With the help of new patched firmware developed by our forum member, @konnor,  you can take the memory dump of MSO1000z series scopes and extract the keys from the dump, no JTAG adaptor or any hardware effort or taking the scope apart is required anymore.

1- Download the pathed firmware from the first post of the this thread:
https://www.eevblog.com/forum/testgear/rigol-ds1000z-firmware-patch-plugins/msg1467130/#msg1467130 (https://www.eevblog.com/forum/testgear/rigol-ds1000z-firmware-patch-plugins/msg1467130/#msg1467130) . 
You have to download the two splited files, rename their extension to “rar” and extract the DS1000ZUpdate.GEL file out of the archive.

..

Hi,

My DS1104ZPlus has fw version 00.04.04.03.05 and the patched firmware is 00.04.04.03.02 so I think the instrument do not allow to downgrade, right?
How can we overcome this?

Or am I missing something?

You can change the patched firmware version code and its CRC value to match the new version number. The details are all in a separate topic about Rigol .GEL file reverse engineering.


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sv1eia on January 27, 2019, 01:15:48 pm

You can change the patched firmware version code and its CRC value to match the new version number. The details are all in a separate topic about Rigol .GEL file reverse engineering.


Thanks but that is pretty much difficult for me to figure out how to do it without any other info.
Any link? or even the topic's name?

Even though, IMHO if that is the only solution, then there is indeed a major problem if we want to move on with konnor's solution.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Daruosha on January 27, 2019, 01:25:12 pm

You can change the patched firmware version code and its CRC value to match the new version number. The details are all in a separate topic about Rigol .GEL file reverse engineering.


Thanks but that is pretty much difficult for me to figure out how to do it without any other info.
Any link? or even the topic's name?

Even though, IMHO if that is the only solution, then there is indeed a major problem if we want to move on with konnor's solution.

You can find the details here:
https://www.eevblog.com/forum/testgear/rigol-dsxxxx-gel-firmware-file-format/ (https://www.eevblog.com/forum/testgear/rigol-dsxxxx-gel-firmware-file-format/)

However I'll try to patch the latest version with konnor's stuff and post it on the same thread.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sv1eia on January 27, 2019, 01:29:26 pm

However I'll try to patch the latest version with konnor's stuff and post it on the same thread.

Thats nice, this will certainly help many.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: N2tl on July 17, 2019, 01:50:25 am
I don’t think the DS2000 (non-A version) has hardware support for 50-ohm termination, does it?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ted572 on July 17, 2019, 02:27:48 am
I don’t think the DS2000 (non-A version) has hardware support for 50-ohm termination, does it?
You are correct, there isn't any 50 ohm termination capability in the DS2000 (non A).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JDubU on July 17, 2019, 05:33:49 am
Actually, there was a brief overlap in hardware versions between the DS2000 and DS2000A.  DS2000 started with hardware v1.xx but transitioned to hardware v2.xx just before the DS2000A was announced.  DS2000A only uses v2.xx hardware.  The relay controlled 50 ohm input terminator is implemented on hardware v2.xx but only the DS2000A allows it to be enabled from the front panel.  It can be enabled on a DS2000 (that has v2.xx hardware) only via SCPI command.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: RetroDan™ on February 27, 2020, 03:06:28 am
Successfully hacked my MSO1074Z-S.  If I upgrade the firmware to the most recent, will I lose my hacks?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: McBryce on February 27, 2020, 07:26:21 am
Successfully hacked my MSO1074Z-S.  If I upgrade the firmware to the most recent, will I lose my hacks?

I can't say 100% for the MSO1074Z-S, but for other devices including my MSO-1104-Z the hacks are still there after several FW updates.

McBryce.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Daruosha on February 27, 2020, 09:18:48 am
Updates do not interfere with your installed licenses.
How did you generate the keys? JTAG dump?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: RetroDan™ on February 27, 2020, 12:54:49 pm
Generated them with the Altered firmware - LAN mem dump - rigup method.  Took a chance and updated.  No issues whatsoever!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Fungus on February 28, 2020, 02:49:16 pm
Successfully hacked my MSO1074Z-S.  If I upgrade the firmware to the most recent, will I lose my hacks?

No, because you didn't "hack" anything. All you did was enter a key - exactly the same as a paying customer would do.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ebastler on February 28, 2020, 03:47:01 pm
Fungus, this is about an MSO. Not quite as straightforward.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tv84 on February 28, 2020, 04:04:23 pm
Fungus, this is about an MSO. Not quite as straightforward.

Sure it is. All the same. The only difference is which private key used BUT once private keys are known, the generated licenses are as "official" as it gets!

For all Rigol equipments.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Fungus on February 28, 2020, 05:40:18 pm
Fungus, this is about an MSO. Not quite as straightforward.

It's exactly the same.

Would a customer expect all his paid-for options to vanish if he did a firmware update? Of course not.

Riglol-generated keys are no different from "official" ones.


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ebastler on February 28, 2020, 08:11:44 pm
Ok, agree. The process is a bit more involved for the MSOs and the -Plus version, but the result is the same.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: RetroDan™ on March 01, 2020, 09:00:32 pm
Successfully hacked my MSO1074Z-S.  If I upgrade the firmware to the most recent, will I lose my hacks?

No, because you didn't "hack" anything. All you did was enter a key - exactly the same as a paying customer would do.

Are you really going to get that bent out of shape over semantics?  Fine.  I utilized an altered firmware to allow me to dump the contents of my scope's memory and then used a community-created piece of software to generate license keys so that I could unlock, without paying, features available for my MSO1074Z-S.

Isn't it just easier to say 'hacked'?  The precision of the term may be lacking, but the implication is certainly there.  Loosen your necktie, mate; nobody's grading you on this.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ebastler on March 01, 2020, 10:39:09 pm
Are you really going to get that bent out of shape over semantics?  [...]
Isn't it just easier to say 'hacked'?  The precision of the term may be lacking, but the implication is certainly there.  Loosen your necktie, mate; nobody's grading you on this.

Fungus' comment was not about your choice of words, but about the underlying mechanism to enable the additional scope features. And his comment was a pertinent answer to your original question whether your new features would survive a firmware udate:

You had to jump through a few hoops to get information from the scope and generate keys. But in the end, you generated the same keys which Rigol would have generated for you if you had bought these features. The scope accepts them since they look correct to its internal checking algorithm -- just as correct as the Rigol-generated keys. So any future firmware will need to accept these keys too.

So yes, please relax and loosen your necktie.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: aristarchus on March 01, 2020, 10:54:42 pm
From what I understand, the license codes generated via the 'hacked' method are exactly the same digit-by-digit with what someone would get officially for the same option on the same serial number device.
So, eventually they have to survive any FW upgrade.

(loose neckties everywhere..)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tv84 on March 02, 2020, 04:58:20 pm
From what I understand, the license codes generated via the 'hacked' method are exactly the same digit-by-digit with what someone would get officially for the same option on the same serial number device.
So, eventually they have to survive any FW upgrade.

(loose neckties everywhere..)

Well, let's get loose-necktie techie for a bit: the licenses are not exactly the same digit-by-digit because they are dependent on a k-factor (usually random). So, they can be different but the achieve the same goal.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: aristarchus on March 02, 2020, 05:07:12 pm
Well, let's get loose-necktie techie for a bit: the licenses are not exactly the same digit-by-digit because they are dependent on a k-factor (usually random). So, they can be different but the achieve the same goal.

Thanks tv84 for clearing this, interesting.
(I have to review the riglol sources and see how this plays out)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ve7xen on March 03, 2020, 12:07:39 am
It's also very unlikely but not completely outside the realm of possibility that Rigol revokes the existing keys, and issues new licenses to legitimate customers.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: McBryce on March 03, 2020, 06:28:11 am
It's also very unlikely but not completely outside the realm of possibility that Rigol revokes the existing keys, and issues new licenses to legitimate customers.

So annoy all the paid customers, making them enter new codes for the products they already paid for, just to remove a few users that "libereated" their scope themselves?? Extremely unlikely I'd say.

McBryce.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: 2N3055 on March 03, 2020, 08:50:31 am
It's also very unlikely but not completely outside the realm of possibility that Rigol revokes the existing keys, and issues new licenses to legitimate customers.
And why would they do that when, for a year now, all options are free and unlocked...?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ve7xen on March 03, 2020, 09:20:27 am
It's also very unlikely but not completely outside the realm of possibility that Rigol revokes the existing keys, and issues new licenses to legitimate customers.
And why would they do that when, for a year now, all options are free and unlocked...?

They're not going to. But let's not say it's impossible.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tv84 on March 03, 2020, 10:17:38 am
They're not going to. But let's not say it's impossible.

I will.  That's impossible as the software has no revoke mechanisms. That's a totally different ballgame.

Develop that at this stage would be economically prohibitive for this kind of equipment. 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ve7xen on March 03, 2020, 10:27:08 am
They're not going to. But let's not say it's impossible.

I will.  That's impossible as the software has no revoke mechanisms. That's a totally different ballgame.

Develop that at this stage would be economically prohibitive for this kind of equipment.

From a software engineering point of view it's trivial, just change the trusted key on the scope. To do so in a manner that wouldn't be easy to hack again wouldn't be, but this kind of thing is always an arms race and it wouldn't be the first time a company saw value in throwing up some meaningless barriers. I'd actually call the MSO's unique keys a step in this direction.

The difficulty actually doing it would be the business ramifications of making all issued licenses not forward compatible to the new software, and the realization that it wouldn't actually achieve anything. It's a matter of the business impact of causing all those support issues and bad juju from paying customers that is stopping them. And probably they recognize that the hacking is good for the popularity of their products and aren't going to spend good will to try to stop it.

What they can't do is go all FTDI and start bricking stuff.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Fungus on March 03, 2020, 10:27:52 am
They're not going to. But let's not say it's impossible.

Pigs could also evolve wings, but...
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ve7xen on March 03, 2020, 10:28:50 am
They're not going to. But let's not say it's impossible.

Pigs could also evolve wings, but...

I feel like we're engineers here and should hold ourselves to the most basic standard of accuracy. If, on an engineering forum, you say something can't be done, I take it to mean that it can't be done, not that it won't be.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Fungus on March 03, 2020, 10:36:45 am
Pigs could also evolve wings, but...

I feel like we're engineers here and should hold ourselves to the most basic standard of accuracy. If, on an engineering forum, you say something can't be done, I take it to mean that it can't be done, not that it won't be.

Spending time discussing how we're going to deal with pesky flying pigs doesn't seem like a productive use of our engineering talents.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tv84 on March 03, 2020, 10:43:45 am
I feel like we're engineers here and should hold ourselves to the most basic standard of accuracy. If, on an engineering forum, you say something can't be done, I take it to mean that it can't be done, not that it won't be.

Totally agree with you. Let's stay that way. BUT, we earthling engineers should also have in mind that we are bound by the economics of the world we live in.  Or else, we can say that they could do all that doesn't break the laws of physics.

Changing the pubkey in their flagship product, as has been done in the past with others, HAS TO involve migrating all the licenses that are currently working in the equipment. As such, once that FW upgrade is installed all "official" and "unofficial" licenses will be happily upgraded (because ANY upgrade program will have no way to differentiate both types of licenses) and what once was a "official/virtual unofficial" situation becomes an "all official" situation.

So, everyone stays licensed and only the new guys must redo riglol with a new private key.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Fungus on March 03, 2020, 01:38:17 pm
They might have a database of all the legal keys that they could include in the firmware update to keep them working, sure.

OTOH no company is that competent and it's probably too big to fit in memory anyway.

Plus: We all know that hacking is part of their marketing strategy. They still made money on all those hacked 'scopes and they've sold millions of them because of it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ilya on March 16, 2020, 03:49:53 pm
Can someone help me out to restore the serial number of a DS2072A ?
I tried to do some of the hacks in the distant past and this lead me to a unit with serial number DS2A0000000001.
The MAC address on the LAN interface is also screwed up.  It's 46:46:46:46:46:46.  I assume this must be uniquely generated from the serial number somehow.
The device is currently at firmware DS2000(DSP)Update_00.03.04.01.00

I think if I could get hold of a memory dump from someone with a working unit (and what their serial number is) I could write back correct values into the scope with my own number.   Thanks!

I don't know if this is still relevant, but I had the same issue and was struggling with it since 2013-2014. Finally the solution was found. Read this post:
https://www.eevblog.com/forum/testgear/sniffing-the-rigol_s-internal-i2c-bus/msg369122/#msg369122 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol_s-internal-i2c-bus/msg369122/#msg369122)

And follow the steps exactly as described. This is very important since when you flash the patched firmware, the serial is stored in RAM only. And you HAVE to uninstall all options in order to write your serial into the flash.
Hope that this will help people with the same problem. And kudos to people who made this solution available.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ossilampe on April 13, 2020, 01:58:52 pm
Hi there

my English is not so good, I have a DS2072A and would like to unlock it on a DS2302, according to this manual http://gotroot.ca/rigol/D2072A%20Unlocking%20Guide.pdf (http://gotroot.ca/rigol/D2072A%20Unlocking%20Guide.pdf)

FW is 03_06_00_00

unfortunately no modifidy software can be installed
not even the downgrade to FW 03_05_04_00

I can only install the original one from boot mode, can someone help me ..

Greetings and happy Easter
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: sorin on April 13, 2020, 02:18:13 pm
Where did you find 03_06_00_00 ?
The last version on Rigol website is 03.05.04.00.
Did the Oscilloscope arrived with 03.06.00.00 preinstalled?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ossilampe on April 13, 2020, 02:37:53 pm
Hello sorin

I bought the device for use approx. 650 € Unfortunately all decoders are locked and I have to be able to use them


here is the 00_03_06_00

http://gotroot.ca/rigol/ (http://gotroot.ca/rigol/)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bigboss59 on April 15, 2020, 07:47:52 pm
Hello,

Is there any other method than the rigup one to unlock a DS1074Z plus ?
If not do you know if it will work with :
FW 4.04.SP4
board version 2.1.4

The last success I can found is in 2017 (lifeclock) with :
Software Version: 00.04.04.SP1
Board Version: 6.1.4

Best regards
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gixy on April 16, 2020, 07:21:56 am
I saw that this 00.03.06.00 release is available, but didn't install it as I could'nt find any release notes. The .zip file contains only the binary and nobody knows anything about this release.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: xyybob on May 08, 2020, 11:54:29 pm
I've just got myself a DS1074Z Plus and try as I might I cannot get the 'hack' to work. I've read out the memory dump with a USB Blaster clone and scanned the dump for the keys etc. but rigup just seems to produce invalid licenses.

Software is 00.04.04.SP4
Board is 2.1.4
Rigup versions 0.1, 0.4, 0.4.2

The keys produced by the scan look fair enough and are consistent across versions of rigup so I have to assume they're ok.

Does anyone know if this still works?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tv84 on May 09, 2020, 08:50:10 am
Everything still works.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gandalf_Sr on May 09, 2020, 08:53:09 am
Everything still works.
Is the Riglol web page here (http://gotroot.ca/rigol/riglol/) still working properly? I heard a while back that some people had issues with it.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tv84 on May 09, 2020, 08:54:28 am
I read the host had made some corrections. It was in the webpages, not the algo in itself.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: xyybob on May 09, 2020, 11:12:06 am
Glad to hear it still works - however not for me so far!

Please could you point me to the specific version of rigup that does work. Bear in mind that its for the DS1074Z Plus and I understand that there may be different versions for MSO etc. As you can see in previous post I've tried a few but I think I'm missing something there.

Also, I've tried running it like this:

'rigup license <my_scanned_keys_file.txt> DSEA', (for the DS version)

and like this:

'rigup license <my_scanned_keys_file.txt> 0x1C080' (for the MSO version)

neither produced a valid response.

Please, If anyone could point out where I'm going wrong I'd be very grateful.

Thanks for helping me out
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: xyybob on May 11, 2020, 11:21:14 am
Sorry about this, very noob question - apologies in advance. How do I get the links inserted into these posts that go to previous replies in the thread (or other threads...) to work?

e.g. if I click on:
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg432125/#msg432125 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg432125/#msg432125)
I get dumped back to the main list of topics!

Or alternatively, how do I decode the message number? e.g., in the link above 'msg432125', there aren't 432125 messages in the thread so how do I get to that message?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: JDubU on May 11, 2020, 12:36:16 pm
You have an apostrophe in "rigol's":
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg432125/#msg432125 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg432125/#msg432125)

The link should be:
https://www.eevblog.com/forum/testgear/sniffing-the-rigol_s-internal-i2c-bus/msg432125/#msg432125 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol_s-internal-i2c-bus/msg432125/#msg432125)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Gandalf_Sr on May 14, 2020, 02:14:11 pm
Sorry about this, very noob question - apologies in advance. How do I get the links inserted into these posts that go to previous replies in the thread (or other threads...) to work?

e.g. if I click on:
https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg432125/#msg432125 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/msg432125/#msg432125)
I get dumped back to the main list of topics!

Or alternatively, how do I decode the message number? e.g., in the link above 'msg432125', there aren't 432125 messages in the thread so how do I get to that message?
Find the message that you want to link to on any given page and click on the bold heading; that message will move to the top of your browser window and you will see a URL in your browser that ends in #msg43215.  Highlight and copy that whole URL.

You can just paste the URL into your message but there's a cleaner way:
1. With a previously copied URL in the clipboard, write the text you want to use as the link and then highlight using the cursor
2. Click the 'Insert Hyperlink' button (the one under italics); now you'll see {url=}text you highighted{/url} (I've used curly rather than square brackets so I can show you the method)
3. Position your cursor immediately after the '=' sign and paste in your URL.
4. Hit [Preview] to check that it looks OK.

You can also type in the URL codes in square brackets to achieve the same effect but I think it's easier to use the button.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: xyybob on May 14, 2020, 08:15:20 pm
Sorry, but I was trying to click on existing links in previous messages, not trying to add links in. I was getting nowhere with it and I didn't notice the typos.

However, thanks for the help - much appreciated!

EDIT:
This was the particular message that I was referring to:
https://www.eevblog.com/forum/testgear/ds1000z-serie-unlocking/msg491026/#msg491026 (https://www.eevblog.com/forum/testgear/ds1000z-serie-unlocking/msg491026/#msg491026)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Dolence on September 11, 2020, 05:57:21 pm
Just got a DS1074Z PLUS (not S version) for myself. After much reading I have some questions.

1) The modified fw method described by the user Daruosha would apply to this unit? Reading some more I understood it's for DS and Plus is actually an MSO. I gues DS1074Z PPLUS is actually an MSO1074Z, is it right?
2) If not, would an Atmel JTAG ICE MKII or XLINX Platform Cable USB JTAG work for jtag dumping?
3) It's still doable?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Dolence on September 16, 2020, 03:43:15 pm
Is this topic dead?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Dolence on September 16, 2020, 06:03:19 pm
Mine come with packages unlocked from factory(no time restriction). Is there any benefit from this? Like upgrade from 70mhz to 100mhz?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: xyybob on October 28, 2020, 03:47:15 pm
I have worked with members of this site to try to unlock the DS1074Zplus but not been able to do it. Looks like it can't be done!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: S. Petrukhin on November 02, 2020, 12:16:09 am
Hold on... In one of the topics here, a person asked for the source codes of Rigol scope based on the GPL license...  :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: joezilla86 on December 07, 2020, 05:14:48 pm
I have worked with members of this site to try to unlock the DS1074Zplus but not been able to do it. Looks like it can't be done!

Sure, it can. You have to use rigup, not riglol.

I'm in a similar boat to xyybob. I have a DS1104Z Plus, I've done the memory dump using konnor's firmware, I've scanned the bin file and generated a keys.txt, but all of the license codes I generate say they are invalid. Someone up above said there's something you need to change in rigup prior to compiling, but I must be missing where to do that. I didn't compile rigup anyway, I used http://gotroot.ca/rigol/rigup-0.4-mso1000z-with-bins.zip (http://gotroot.ca/rigol/rigup-0.4-mso1000z-with-bins.zip) which was the which was the version most recently posted on the site.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tv84 on December 09, 2020, 01:13:12 pm
XMAS 2020 GIFT to the whole RIGUP community    :D

There is a bug in the rigup source code that makes certain scopes to not accept the licenses generated by any rigup version.

(I know this is pretty old stuff but the error is there... has always been.)

The option licenses are based on a hash of a string that has this format:  SERIAL_NUM + OPTION_CODE + XXTEA_KEY

The problem is with the XXTEA_KEY. Certain XXTEA keys contain NULL bytes. Current rigup source code always concatenates the 16 bytes of the XXTEA but that is wrong!

All 00s should be removed from the hash buffer when adding the XXTEA key (and the hash buffer size adjusted accordingly).

All those who have problems licensing, MS1000Z+, etc. please check your XXTEA keys (to see if you have 00s) and you'll be able to verify this.

Now it's up to rigup hosts to correct the available software versions.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Bicurico on December 10, 2020, 07:59:27 am
 :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: joezilla86 on December 12, 2020, 08:36:01 pm
Thanks tv84 for your help! My XXTEA_KEY did have an occurrence of a 00 and was generating invalid keys until tv84 took a look and was able to get me a valid unlock key.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: KK1L on December 21, 2020, 03:44:39 pm
Just got a DS1074Z PLUS (not S version) for myself. After much reading I have some questions.

1) The modified fw method described by the user Daruosha would apply to this unit? Reading some more I understood it's for DS and Plus is actually an MSO. I gues DS1074Z PPLUS is actually an MSO1074Z, is it right?

Yes. The MSO1074Z comes with the logic probes included. The DS1074Z Plus does not. Only difference is the branding.


Title: Re: Sniffing the Rigol's internal I2C bus
Post by: KK1L on January 05, 2021, 10:55:10 pm
I have been trying to get a memory dump of my DS1074Z-S Plus through the JTAG port having given up getting a back level firmware loaded to access via SCPI on the LAN. I hesitate to ask here, but I am at my wits end. I have learned a great deal about OCD, JTAG access, etc in the many days I have dedicated to this endeavor. And am grateful for the all the great information especially on EEVBLOG which has allowed me to make the progress I have.

Using SiSpeed dongle with FT2232 with TMS/TCK/TDI/TDO and RST. RST is connected to SRST on the 1074Z. There is only the one reset signal, so I have to soft reset the TAP.
I seem have the interface signals defined correctly (finally!) as I can reset the scope with a reset command, and jtag arp_init comes back clean.
My problem is that I eventually get a timeout error "waiting for SYSCOMP & DBGACK". I have gotten as large as a 2MB file or so, and as small as 8k. Driving me nuts.

> jtag init
> halt
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x20000013 pc: 0x4003957c
MMU: enabled, D-Cache: enabled, I-Cache: enabled
> dump_image mso1074z.bin 0x40000000 0x3FFFFFF
timeout waiting for SYSCOMP & DBGACK, last DBG_STATUS: 4


I have been trying a variety of adapter speeds, delay and timing configurations, TDO clocking edge rise/fall, etc. I do not rely on a reset command between tries. I will power cycle both the dongle and the 1074Z.

Is there a clue someone might have for me? Happy to share more detail about what I have tried.

Thanks!

73 es God Bless, KK1L Ron <><
 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: up8051 on January 07, 2021, 05:25:02 pm
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?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: geo999 on January 12, 2021, 04:29:22 pm
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, (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

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: KK1L on January 14, 2021, 08:58:42 pm
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 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol_s-internal-i2c-bus/msg3361424/#msg3361424) 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: KK1L on March 05, 2021, 02:52:22 pm
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 (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 0x1c080
You 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 :) !
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: KK1L on March 06, 2021, 02:45:13 am
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 (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.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: RoGeorge on March 06, 2021, 10:07:12 am
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.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: KK1L on March 06, 2021, 03:25:16 pm
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?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: colabri on May 12, 2021, 12:53:44 pm
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:

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.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: davorin on May 25, 2021, 10:21:57 am
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
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: hammy on May 25, 2021, 08:42:01 pm
Or what options are left for this scope to add? Only the 100MHz bandwidth?

Exactly. That's the only option missing.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: davorin on May 26, 2021, 10:11:13 am
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)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: davorin on May 26, 2021, 11:35:50 am
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

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ve7xen on June 14, 2021, 09:28:20 pm
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 (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.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tv84 on June 15, 2021, 08:01:58 am
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.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: rteodor on February 20, 2022, 08:08:28 pm
Quote from: colabri
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 (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 ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: s1ic3r on April 26, 2022, 05:10:03 pm
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

 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: s1ic3r on April 30, 2022, 08:02:27 pm
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 (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/ (http://)

For a step by step check out smgvbest's excellent post here. (https://www.eevblog.com/forum/testgear/sniffing-the-rigol_s-internal-i2c-bus/msg569236/#msg569236)

Resources

Main Thread
https://www.eevblog.com/forum/testgear/sniffing-the-rigol_s-internal-i2c-bus/msg233647/#msg233647 (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 (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 (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 (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,

this (https://www.youtube.com/watch?v=OvcGn_ScG5w&t=7s)

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 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol_s-internal-i2c-bus/msg1191044/#msg1191044) 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 (https://www.eevblog.com/forum/testgear/you-can_t-unlock-a-mso1000z-series-scope-without-a-memory-dump-and-other-lessons/msg772022/#msg772022) thread,

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

more specifically, this:

Quote
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

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: colabri on June 22, 2022, 06:54:29 pm

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 (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.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: kimouser6471 on July 29, 2022, 12:36:25 pm
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