EEVblog Electronics Community Forum

Products => Test Equipment => Topic started by: andyturk on May 18, 2013, 02:22:20 AM

Title: Sniffing the Rigol's internal I2C bus
Post by: andyturk on May 18, 2013, 02:22:20 AM
Quick Links:

#2446: buergi's "information needed to memdump [a] DS2KA" (http://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 18, 2013, 03:06:14 AM
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 18, 2013, 03:10:33 AM
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 18, 2013, 04:35:26 AM
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, 10: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 19, 2013, 09:00:14 AM
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 20, 2013, 08:58:42 AM
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, 11: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, 06:21:08 PM
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 23, 2013, 01:19:18 AM
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 27, 2013, 03:32:57 AM
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 27, 2013, 07:13:37 AM
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 27, 2013, 09:00:24 AM
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 28, 2013, 06:14:52 AM
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 28, 2013, 06:15:27 AM
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 30, 2013, 05:31:07 AM
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, 10: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, 05:12:28 PM
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 31, 2013, 03:40:37 AM
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

http://www.eevblog.com/forum/testgear/frequency-response-of-your-dso/ (http://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 31, 2013, 07:01:53 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.

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 31, 2013, 07:19:18 AM
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 31, 2013, 08:37:37 AM
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 31, 2013, 09:20:55 AM
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, 03:50:33 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.
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, 03:54:51 PM
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 June 01, 2013, 03:11:40 AM
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 June 01, 2013, 07:10:53 AM
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 02, 2013, 12:13:45 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.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 02, 2013, 12:14:57 AM
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 02, 2013, 12:30:20 AM
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 02, 2013, 12:34:43 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.

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 02, 2013, 12:41:55 AM
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 02, 2013, 12:44:12 AM
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 02, 2013, 12:48:53 AM
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..."

(http://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, 06:04:56 PM
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, 06:14:53 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.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on June 02, 2013, 06:34:26 PM
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, 06:44:09 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.
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, 07:14:53 PM
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, 07:49:35 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.

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, 08:01:08 PM
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, 11: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 03, 2013, 03:17:33 AM
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 03, 2013, 03:22:07 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.

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 03, 2013, 03:30:49 AM
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 03, 2013, 03:39:06 AM
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 03, 2013, 04:19:13 AM
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 03, 2013, 04:35:02 AM
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 03, 2013, 04:37:55 AM
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 03, 2013, 04:41:27 AM
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 03, 2013, 04:54:19 AM

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 03, 2013, 04:54:54 AM
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 03, 2013, 06:21:14 AM
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 (http://www.youtube.com/watch?v=9QhsuKvB9U4#ws)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 03, 2013, 06:49:24 AM
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 03, 2013, 06:55:45 AM
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 03, 2013, 07:05:59 AM
well done
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: andyturk on June 03, 2013, 07:23:14 AM
Oh one more thing ....
Superb!

 :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: monster on June 03, 2013, 07:31:23 AM
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 03, 2013, 07:49:53 AM
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 03, 2013, 08:21:28 AM

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 03, 2013, 08:39:09 AM
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 03, 2013, 08:42:29 AM
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 03, 2013, 08:52:32 AM
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 03, 2013, 09:11:08 AM
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 03, 2013, 09:42:26 AM
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 03, 2013, 09:44:50 AM
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 03, 2013, 09:51:21 AM
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, 10: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 04, 2013, 03:59:41 AM
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 04, 2013, 05:25:34 AM
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 04, 2013, 05:30:45 AM
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 04, 2013, 06:32:36 AM

@ 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 04, 2013, 08:11:46 AM
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 04, 2013, 08:14:56 AM
All files for download
Thank You   :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on June 04, 2013, 08:28:15 AM

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 04, 2013, 08:50:54 AM
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 04, 2013, 09:23:03 AM
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 04, 2013, 09:34:33 AM
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, 08:34:13 PM
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, 08:45:49 PM
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, 08:51:46 PM
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, 09:45:55 PM
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, 09:58:21 PM
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 05, 2013, 08:03:03 AM
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 05, 2013, 08:15:30 AM
Lookin' good  :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on June 05, 2013, 08:20:21 AM
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 05, 2013, 08:23:53 AM
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 05, 2013, 08:31:14 AM
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 05, 2013, 09:01:46 AM
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 05, 2013, 09:10:30 AM
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 05, 2013, 09:13:08 AM
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, 06:44:25 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
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Pinkus on June 05, 2013, 07:23:02 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
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 06, 2013, 07:01:00 AM
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 06, 2013, 08:49:25 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?

Great work by the way :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Harvs on June 06, 2013, 10: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, 02:24:10 PM
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 08, 2013, 01:31:31 AM
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 08, 2013, 02:14:53 AM
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 08, 2013, 05:52:30 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 ... ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 08, 2013, 06:47:25 AM
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 08, 2013, 06:48:30 AM
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 08, 2013, 07:08:08 AM
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 08, 2013, 07:22:04 AM
500ps  8)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tinhead on June 08, 2013, 07:31:21 AM
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 08, 2013, 07:33:49 AM
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 08, 2013, 07:38:16 AM
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, 10: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, 11: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, 11: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, 11: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, 11: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 09, 2013, 04:30:38 AM
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 09, 2013, 06:22:18 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


   
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Harvs on June 09, 2013, 11: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, 04:00:25 PM
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 10, 2013, 01:32:28 AM
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 10, 2013, 07:56:44 AM
how close is this?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: DL5TOR on June 10, 2013, 06:14:20 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 ... ;)



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, 08:53:08 PM
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 11, 2013, 12:13:31 AM
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, 06:56:47 PM
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, 07:17:02 PM
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, 08:08:21 PM
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, 11: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 12, 2013, 05:57:22 AM
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 12, 2013, 07:36:30 AM
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 12, 2013, 07:53:43 AM
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, 11: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, 12:59:39 PM
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, 02:53:06 PM
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, 03:02:56 PM
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, 08:04:57 PM
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, 09:04:38 PM
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 16, 2013, 03:28:14 AM
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 18, 2013, 07:10:56 AM
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, 05:38:40 PM
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, 11: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 21, 2013, 01:46:29 AM
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 21, 2013, 01:49:34 AM
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 21, 2013, 02:24:15 AM
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 21, 2013, 03:13:12 AM
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 21, 2013, 03:22:44 AM
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 21, 2013, 03:57:51 AM
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 21, 2013, 04:47:33 AM
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 21, 2013, 05:05:21 AM
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 21, 2013, 05:08:23 AM
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 21, 2013, 05:44:13 AM
 :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 21, 2013, 06:46:39 AM
: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 21, 2013, 06:49:45 AM
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 21, 2013, 07:18:04 AM
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 21, 2013, 07:29:08 AM
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 21, 2013, 07:43:47 AM
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 21, 2013, 07:51:21 AM
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, 03:09:35 PM
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, 06:49:06 PM
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, 06:55:30 PM
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, 09:40:43 PM
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, 10: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, 11: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, 11: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 22, 2013, 02:15:09 AM
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 22, 2013, 02:51:42 AM
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 22, 2013, 05:34:32 AM
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 22, 2013, 06:31:31 AM
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 22, 2013, 06:39:38 AM
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 22, 2013, 07:54:06 AM
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 22, 2013, 09:14:59 AM
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, 08:30:57 PM
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, 11: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, 11: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 23, 2013, 12:50:56 AM
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 23, 2013, 12:59:12 AM
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 23, 2013, 02:32:39 AM
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 23, 2013, 05:04:59 AM
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 23, 2013, 05:11:39 AM
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 23, 2013, 05:19:04 AM
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, 10: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, 10: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, 10: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, 12:41:33 PM
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, 01:16:24 PM
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, 05:15:18 PM
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, 05:42:56 PM
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, 10: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, 06:24:56 PM
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, 06:43:39 PM
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, 06:51:28 PM
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, 07:13:04 PM
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, 07:18:26 PM
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, 07:39:46 PM
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, 08:41:28 PM

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, 08:52:09 PM
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, 09:26:41 PM
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, 09:31:04 PM
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, 09:50:30 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.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 28, 2013, 10: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, 10: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, 10: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, 10: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, 10: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, 10:32:41 PM
edited
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 28, 2013, 10: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. (http://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, 10: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, 10: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, 10: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, 10: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, 10: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 (http://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, 11: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, 11: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, 11: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, 11: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, 11:18:43 PM
Firmware links here. (http://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, 11: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, 11: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 (http://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, 11: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, 11: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, 11: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, 11: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 29, 2013, 12:03:06 AM
edited
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on June 29, 2013, 12:04:05 AM
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 29, 2013, 12:08:55 AM
edited
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: egonotto on June 29, 2013, 01:21:21 AM
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 29, 2013, 01:30:36 AM
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 29, 2013, 01:34:57 AM
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 29, 2013, 01:48:36 AM
Hello marmad,

thanks.

Best regard,

egonotto
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: f_richter on June 29, 2013, 01:54:34 AM
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 29, 2013, 01:57:38 AM
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 29, 2013, 02:08:20 AM
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 29, 2013, 02:09:50 AM
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 29, 2013, 02:18:35 AM
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 29, 2013, 02:22:01 AM
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 29, 2013, 02:23:29 AM
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 29, 2013, 02:25:01 AM
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 29, 2013, 02:26:32 AM
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 29, 2013, 02:26:50 AM
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 29, 2013, 02:28:19 AM
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 29, 2013, 02:45:35 AM
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 29, 2013, 03:05:15 AM
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 29, 2013, 03:44:49 AM

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 29, 2013, 06:24:18 AM
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 29, 2013, 07:10:03 AM
Looks like Christmas came early this year!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on June 29, 2013, 07:25:27 AM
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 29, 2013, 07:38:28 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.

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 29, 2013, 08:03:54 AM
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 29, 2013, 09:27:27 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)
 
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: marmad on June 29, 2013, 09:41:33 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 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 29, 2013, 09:58:10 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 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, 11: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, 11: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, 03:38:48 PM
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, 05:16:43 PM
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, 07:17:44 PM
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, 08:51:19 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.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mickpah on June 29, 2013, 09:12:02 PM
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, 09:23:57 PM
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, 10: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, 11: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, 11: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 30, 2013, 12:08:31 AM
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 30, 2013, 12:16:01 AM
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 30, 2013, 01:48:07 AM
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 30, 2013, 02:49:20 AM
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 30, 2013, 05:43:15 AM
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 30, 2013, 06:06:52 AM
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, 10: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, 11: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 July 01, 2013, 12:11:57 AM
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 (http://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 July 01, 2013, 12:14:50 AM
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 July 01, 2013, 12:44:09 AM
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 July 01, 2013, 02:38:30 AM
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 July 01, 2013, 04:36:07 AM
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 July 01, 2013, 04:38:01 AM

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 02, 2013, 03:52:37 AM
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 02, 2013, 04:05:09 AM
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 02, 2013, 06:57:09 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.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: KuchateK on July 02, 2013, 10: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, 11: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, 11: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, 11: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, 12:56:58 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"))

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, 02:16:24 PM
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, 03:09:15 PM
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, 03:16:36 PM
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 03, 2013, 12:03:29 AM
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 03, 2013, 12:10:16 AM
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 03, 2013, 04:00:41 AM
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 03, 2013, 04:17:54 AM
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 03, 2013, 04:49:13 AM
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 03, 2013, 05:01:01 AM
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 (http://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 03, 2013, 05:12:05 AM
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 03, 2013, 05:42:44 AM
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 03, 2013, 05:58:11 AM
Thanks, so make it sense in my eyes.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: CodyShaw on July 03, 2013, 06:16:29 AM
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 03, 2013, 06:25:14 AM
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 03, 2013, 06:30:05 AM
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, 05:08:12 PM
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 04, 2013, 05:13:19 AM
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 04, 2013, 06:14:23 AM
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 04, 2013, 06:33:53 AM
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 04, 2013, 06:58:51 AM
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 04, 2013, 09:04:01 AM
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 04, 2013, 09:10:33 AM
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, 01:32:29 PM
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, 05:11:31 PM
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, 05:26:46 PM
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, 05:58:47 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)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: fqahmad66 on July 04, 2013, 08:17:17 PM
Does the hacks works for DSA815 SAs? >:D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: docmandu on July 04, 2013, 10: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, 10: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 05, 2013, 05:09:14 AM
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 05, 2013, 05:18:34 AM
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 05, 2013, 05:51:43 AM
Ahh  very happy to hear that.

--
 Darryl

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: doma on July 05, 2013, 06:29:09 AM
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 05, 2013, 08:36:22 AM
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 05, 2013, 08:47:39 AM
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:
http://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684
 (http://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 05, 2013, 08:48:30 AM
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 05, 2013, 08:50:31 AM
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 05, 2013, 08:53:50 AM
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, 06:21: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

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, 07:10:26 PM

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, 08:08:43 PM
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, 09:57:54 PM

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 06, 2013, 02:56: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
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 06, 2013, 03:57:32 AM
(...)

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 06, 2013, 04:07:56 AM
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 06, 2013, 04:17:37 AM
(...)

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 06, 2013, 05:48:15 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
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: doma on July 06, 2013, 06:00:38 AM
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 06, 2013, 06:06:22 AM
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, 09:21:37 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

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, 10: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, 10: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, 11: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, 11: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, 11: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, 11: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 (http://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, 11: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 07, 2013, 12:24:14 AM
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 (http://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=http://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 07, 2013, 12:32:38 AM
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 (http://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 07, 2013, 12:41:48 AM
(...) 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 07, 2013, 12:59:47 AM
(...) 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 07, 2013, 01:03:33 AM
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 07, 2013, 01:30:48 AM
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 07, 2013, 01:54:38 AM
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 07, 2013, 01:56:28 AM
(...) 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 07, 2013, 02:34:00 AM
@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 07, 2013, 02:53:52 AM
@ 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 07, 2013, 03:13:22 AM

@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 (http://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 07, 2013, 03:35:44 AM
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 07, 2013, 03:43:34 AM
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 07, 2013, 03:47:22 AM
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 07, 2013, 05:37:57 AM
(...) 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 07, 2013, 06:01:32 AM
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 07, 2013, 08:25:02 AM
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 07, 2013, 08:26:42 AM
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 07, 2013, 08:37:58 AM
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 07, 2013, 09:01:20 AM
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, 09:42:37 PM
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, 11: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 08, 2013, 02:18:11 AM
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, 11: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, 10: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, 10: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, 10: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, 11: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 09, 2013, 12:12:29 AM
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 09, 2013, 12:17:16 AM
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 09, 2013, 12:20:11 AM
No.

I missed the word "nowt"...

lol ;)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: adcajo on July 09, 2013, 07:18:17 PM
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, 07:25:22 PM
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, 08:05:20 PM
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, 08:34:17 PM
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, 08:47:43 PM
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, 08:52:13 PM
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, 08:56:22 PM
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, 09:13:21 PM
< 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, 10: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..
http://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/420/. (http://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, 10: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, 05:50:42 PM
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, 07:22:11 PM
: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, 08:38:37 PM
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, 09:29:31 PM
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, 10: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, 11: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 11, 2013, 12:01:17 AM
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 11, 2013, 12:56:15 AM
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, 05:54:58 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 -
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Orange on July 12, 2013, 11: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 13, 2013, 02:44:06 AM
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 13, 2013, 06:43:35 AM
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, 08:28:01 PM
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, 10:29:00 PM
Posted app in the Software for Rigol forum: http://www.eevblog.com/forum/projects/software-tips-and-tricks-for-rigol-ds200040006000-ultravision-dsos/msg261360/#msg261360 (http://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 14, 2013, 04:14:21 AM


[/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 14, 2013, 08:10:16 AM
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 16, 2013, 08:11:07 AM
"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, 10: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, 10: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, 01:40:35 PM
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, 04:50:18 PM
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, 09:40:26 PM
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, 09:50:05 PM

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 18, 2013, 03:36:53 AM
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 18, 2013, 03:48:00 AM
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, 10: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 - <[email protected]>
**
**
** 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: http://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, 10: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, 10: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, 10: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, 11: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, 06:33:44 PM
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, 07:20:08 PM
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, 11: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, 11: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 19, 2013, 12:17:24 AM
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 19, 2013, 12:25:13 AM
Per serial number of each ds2xx2 don't forget !


--
 Darryl

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: cybernet on July 19, 2013, 12:46:19 AM
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 19, 2013, 01:08:05 AM
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 19, 2013, 01:13:01 AM
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 19, 2013, 04:15:34 AM
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 19, 2013, 04:18:31 AM
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 19, 2013, 07:30:16 AM
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 19, 2013, 07:46:36 AM
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 19, 2013, 07:51:57 AM
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 19, 2013, 07:52:29 AM
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 20, 2013, 06:10:16 AM
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 20, 2013, 06:35:04 AM
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 20, 2013, 06:49:40 AM
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 20, 2013, 06:56:12 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 ;-)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: docmandu on July 20, 2013, 07:29:57 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 ;-)

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, 07:37:44 PM
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 21, 2013, 03:14:57 AM
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 21, 2013, 03:45:02 AM
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 21, 2013, 03:50:16 AM
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 21, 2013, 03:57:55 AM
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 21, 2013, 04:05:49 AM
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 21, 2013, 04:50:52 AM

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 21, 2013, 07:22:04 AM
k=40228745953163121  (0x8EEBD4D04C3771)

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: docmandu on July 21, 2013, 08:07:16 AM
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 21, 2013, 08:58:38 AM
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 21, 2013, 09:03:48 AM
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 21, 2013, 09:16:50 AM
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 21, 2013, 09:48:08 AM
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 21, 2013, 09:51:36 AM
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, 10: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, 10: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, 10: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, 10: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, 10: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, 10: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, 12:54:26 PM
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, 12:56:19 PM
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, 01:03:36 PM
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, 01:05:28 PM
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, 01:13:20 PM
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, 08:07:38 PM
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, 08:10:03 PM
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, 08:15:11 PM
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, 09:11:52 PM
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: http://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: http://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, 10: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, 10: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, 10: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, 10: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, 10: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, 10: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, 10: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, 10: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, 10: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, 10: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, 10: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, 10: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, 11: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, 11: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, 11: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, 11: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, 11: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, 11: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, 11: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, 11: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 22, 2013, 12:12:18 AM
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 22, 2013, 12:16:48 AM
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 22, 2013, 12:36:45 AM
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 22, 2013, 12:42:42 AM
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 22, 2013, 12:50:44 AM
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 22, 2013, 12:54:35 AM
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 22, 2013, 01:33:27 AM
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 22, 2013, 02:59:51 AM
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 22, 2013, 03:02:56 AM
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 22, 2013, 03:09:25 AM
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:
http://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg264876/#msg264876 (http://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 22, 2013, 03:12:41 AM
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 22, 2013, 04:09:21 AM
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 22, 2013, 04:23:40 AM
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 22, 2013, 04:27:55 AM
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 22, 2013, 04:29:12 AM
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 22, 2013, 04:31:02 AM
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 22, 2013, 04:44:53 AM
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 22, 2013, 05:34:11 AM
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 22, 2013, 05:35:12 AM
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 22, 2013, 05:55:00 AM
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 22, 2013, 06:24:20 AM
I can host too if a mirror is needed
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: doma on July 22, 2013, 06:28:42 AM

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 22, 2013, 06:46:00 AM

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 22, 2013, 07:30:27 AM
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: http://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: http://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 22, 2013, 07:31:51 AM
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 22, 2013, 07:32:53 AM
Great work!

cool stuff ! but now its to quick ;P
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on July 22, 2013, 07:41:22 AM
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 22, 2013, 07:54:56 AM

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 22, 2013, 07:57:25 AM
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 22, 2013, 08:26:07 AM
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 22, 2013, 08:27:35 AM
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 22, 2013, 08:42:26 AM
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 22, 2013, 08:46:09 AM
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 22, 2013, 08:52:29 AM
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 22, 2013, 09:43:44 AM
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 22, 2013, 09:52:54 AM
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, 10: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, 10: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, 10: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, 10: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, 10: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, 01:31:39 PM
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, 04:22:24 PM
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, 04:32:59 PM
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, 04:47:57 PM
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, 05:16:02 PM
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, 05:25:12 PM
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, 05:32:08 PM
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, 05:37:24 PM
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, 06:09:25 PM
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, 06:13:27 PM
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, 06:44:08 PM
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, 06:59:04 PM
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, 07:12:17 PM
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, 07:28:26 PM
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, 08:39:19 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.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mickpah on July 22, 2013, 09:06:08 PM
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, 09:08:52 PM
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, 11: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, 11: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 23, 2013, 12:16:48 AM
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 23, 2013, 01:58:04 AM
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 23, 2013, 04:08:26 AM
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 23, 2013, 04:15:01 AM
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 23, 2013, 04:22:07 AM
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 23, 2013, 05:06:23 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.
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: http://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: http://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 23, 2013, 06:21:22 AM

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 23, 2013, 06:31:14 AM
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 23, 2013, 06:33:32 AM
 :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: orbiter on July 23, 2013, 06:35:12 AM
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 23, 2013, 06:38:51 AM

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 23, 2013, 06:46:59 AM
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 23, 2013, 06:49:33 AM
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 23, 2013, 06:51:19 AM
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 23, 2013, 06:53:53 AM

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 23, 2013, 07:05:11 AM
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 23, 2013, 07:06:04 AM
Here's the Windows app.

:-+ :-+ :-+
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: alank2 on July 23, 2013, 07:13:25 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.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Carrington on July 23, 2013, 07:16:34 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.

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 23, 2013, 07:29:12 AM
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: http://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: http://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 23, 2013, 07:43:06 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 :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on July 23, 2013, 07:44:19 AM
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: http://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: http://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 23, 2013, 07:50:45 AM
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: http://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: http://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 23, 2013, 08:22:01 AM
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 23, 2013, 08:52:24 AM
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: http://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: http://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 23, 2013, 09:03:05 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).
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on July 23, 2013, 09:16:51 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
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: UberSteve on July 23, 2013, 10: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, 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.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: UberSteve on July 23, 2013, 10: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, 10: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, 10: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, 10: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, 11: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, 11: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, 11: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, 01:44:23 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

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, 01:50:19 PM
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, 01:53:44 PM
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.

(http://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, 02:00:41 PM
One post above me, here re-quoting the photo, it says DS4024.
(http://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, 02:59:56 PM
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, 03:11:36 PM
Nice !,
What about the DS4024 500mhz BW option ?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Uup on July 23, 2013, 03:29:46 PM
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, 04:34:10 PM
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, 06:18:10 PM
time for DSA815?  >:D
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: mickpah on July 23, 2013, 06:27:25 PM
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, 06:50:39 PM
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, 06:53:53 PM
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, 07:04:43 PM
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, 07:12:02 PM
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, 07:22:26 PM
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, 07:28:34 PM
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, 09:46:09 PM
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, 10: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, 10: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, 10: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, 10: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, 10: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, 11: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, 11: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 24, 2013, 12:03:20 AM
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 24, 2013, 12:26:11 AM
See here:
http://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 24, 2013, 12:48:20 AM
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 24, 2013, 12:51:06 AM
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 24, 2013, 12:53:30 AM
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 24, 2013, 12:57:28 AM
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 24, 2013, 01:29:21 AM
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 24, 2013, 01:44:22 AM
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 24, 2013, 01:54:37 AM
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 24, 2013, 02:04:09 AM
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 24, 2013, 02:04:34 AM
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 24, 2013, 02:30:55 AM
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 24, 2013, 02:47:05 AM
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 24, 2013, 02:56:53 AM
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 24, 2013, 02:59:20 AM
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 24, 2013, 03:17:51 AM
DSA815, V1.07
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: studio25 on July 24, 2013, 04:45:28 AM
@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 24, 2013, 05:33:08 AM
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 24, 2013, 05:50:46 AM
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 24, 2013, 06:09:00 AM
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 24, 2013, 06:22:06 AM
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 24, 2013, 06:46:20 AM
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 24, 2013, 06:56:57 AM
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 24, 2013, 07:01:02 AM
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 24, 2013, 07:07:17 AM
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 24, 2013, 07:09:06 AM
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 24, 2013, 07:20:24 AM

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 24, 2013, 07:27:38 AM
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 24, 2013, 07:29:38 AM
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 24, 2013, 07:32:01 AM
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 24, 2013, 07:48:24 AM
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 24, 2013, 07:56:39 AM

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 24, 2013, 07:58:01 AM
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 24, 2013, 07:59:50 AM
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 24, 2013, 08:03:09 AM
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 24, 2013, 08:14:07 AM
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 24, 2013, 08:17:13 AM
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 24, 2013, 09:01:33 AM
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, 10: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, 12:17:18 PM
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, 02:43:21 PM
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, 07:10:44 PM
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, 07:52:14 PM
: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 25, 2013, 01:15:01 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?

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 25, 2013, 07:03:27 AM
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 25, 2013, 07:06:42 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 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 25, 2013, 07:18:16 AM
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 25, 2013, 07:31:00 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 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 25, 2013, 08:05:39 AM
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, 10: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, 10: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, 11: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, 11: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, 11: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, 11: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, 12:00:26 PM
Does the Windows version work for you?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: bleckers on July 25, 2013, 12:07:06 PM
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, 12:12:42 PM
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, 01:21:33 PM
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, 01:34:51 PM
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, 03:04:36 PM
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, 04:05:56 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.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: XaS on July 25, 2013, 04:54:47 PM
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, 05:01:14 PM
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, 05:18:40 PM
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, 05:23:08 PM
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, 05:42:41 PM
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, 05:44:24 PM
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, 05:46:01 PM
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, 05:56:11 PM
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, 06:09:23 PM
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, 06:12:06 PM
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, 06:23:07 PM
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, 06:29:55 PM
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, 06:32:39 PM
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, 06:34:32 PM
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, 07:01:43 PM
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, 11: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, 11: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, 11: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, 11: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 26, 2013, 09:08:16 AM
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 26, 2013, 09:13:46 AM
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 26, 2013, 09:21:00 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 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, 12:09:35 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 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, 02:15:51 PM
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, 02:24:29 PM
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, 11: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, 11: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 27, 2013, 01:42:46 AM


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 27, 2013, 01:48:57 AM
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 27, 2013, 03:21:13 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. 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 27, 2013, 03:31:39 AM
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 27, 2013, 03:34:21 AM
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 27, 2013, 04:41:54 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.

Thanks for the info regarding the seeding.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: zombie28 on July 27, 2013, 08:27:36 AM
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, 10: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, 11: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, 11: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 28, 2013, 05:30:16 AM
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 28, 2013, 05:56:19 AM
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 28, 2013, 05:59:41 AM
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 28, 2013, 06:08:22 AM
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 28, 2013, 07:11:24 AM
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 28, 2013, 08:50:13 AM
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, 02:14:22 PM
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, 02:42:24 PM
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, 02:46:13 PM
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, 03:28:18 PM
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, 04:01:27 PM
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, 06:47:36 PM
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 29, 2013, 09:00:13 AM
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 30, 2013, 12:53:29 AM
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, 05:04:42 PM
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, 05:34:47 PM
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, 06:19:10 PM
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, 08:16:42 PM
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, 11: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 31, 2013, 12:47:16 AM
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 31, 2013, 01:17:38 AM
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 31, 2013, 02:05:07 AM
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 31, 2013, 02:34:06 AM
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 31, 2013, 02:37:16 AM
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 31, 2013, 04:01:00 AM
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 31, 2013, 04:26:12 AM

I have had a topic on this subject of getting 250 Mhz out of a DG4102

http://www.eevblog.com/forum/testgear/250-mhz-out-of-a-rigol-dg4102-a-100-mhz-waveform-generator/ (http://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 31, 2013, 09:21:18 AM
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, 10: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, 11: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, 11: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, 08:54:25 PM
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, 08:56:32 PM
Date of Calibration 09-Jul-2013
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: jeremy on July 31, 2013, 08:58:44 PM
Hi Leonard,

Have you tried to unlock?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: Leonard Tatzig on July 31, 2013, 09:02:11 PM
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, 09:09:14 PM
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, 09:21:13 PM
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, 09:25:20 PM
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, 10: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, 10: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, 10: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 August 01, 2013, 01:40:01 AM
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 August 01, 2013, 03:14:02 AM
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 August 01, 2013, 03:51:20 AM
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 August 01, 2013, 06:22:54 AM
Maybe will be better if you create a new thread for this new revision of HW.

I did, see http://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0 (http://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 02, 2013, 01:25:06 AM
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 02, 2013, 01:43:53 AM
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 02, 2013, 03:17:47 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...
When I did my initial EEPROM experiments, the 1 nSec containd a nasty bug. please read
http://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg247223/#msg247223 (http://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, 10: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, 11: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, 02:40:35 PM
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, 07:47:14 PM
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, 07:51:27 PM

 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, 08:47:57 PM
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, 09:13:47 PM
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, 09:29:18 PM
Congratulations, then both are the H.W. version 2.0.  :)
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tlu on August 04, 2013, 04:08:28 AM
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, 11: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, 11: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, 11: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, 12:08:32 PM
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, 12:31:09 PM
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, 12:34:01 PM
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, 03:26:17 PM
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, 07:38:01 PM
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, 08:23:07 PM
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, 09:45:44 PM
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, 11: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 05, 2013, 12:34:40 AM
Bingo!!! 10Hz RBW!

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tlu on August 05, 2013, 01:44:39 AM
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 05, 2013, 03:48:44 AM
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 05, 2013, 04:12:28 AM
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 05, 2013, 07:25:53 AM
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, 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.
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: StubbornGreek on August 05, 2013, 06:16:00 PM
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, 10: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 06, 2013, 06:57:12 AM
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 07, 2013, 05:02:51 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.

Title: Re: Sniffing the Rigol's internal I2C bus
Post by: ilya on August 07, 2013, 07:45:37 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?
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: true on August 07, 2013, 12:07:50 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.
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, 12:30:54 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?
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, 02:11:49 PM
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, 02:53:45 PM
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, 06:23:34 PM
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, 06:45:04 PM
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, 09:32:28 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 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 08, 2013, 05:16:58 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'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 08, 2013, 05:22:44 AM
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 08, 2013, 06:16:27 AM
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 08, 2013, 06:30:43 AM
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 08, 2013, 06:46:38 AM
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, 10: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, 12:08:42 PM
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, 12:52:54 PM
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, 02:17:09 PM
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, 02:37:48 PM
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, 05:25:09 PM
... 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, 11: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, 11: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, 11: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 09, 2013, 12:26:26 AM
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, 12:16:16 PM
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, 03:21:55 PM
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, 03:36:21 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!
Title: Re: Sniffing the Rigol's internal I2C bus
Post by: tlu on August 09, 2013, 05:39:58 PM
... 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 10, 2013, 01:01:34 AM
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 10, 2013, 03:07:51 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!

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. Th