Sniffing the Rigol's internal I2C bus

[andyturk]

Quick Links:

#2446: buergi's "information needed to memdump [a] DS2KA"


All the talk of Rigol hacks got me curious about what goes on inside my DS1102E's non-volatile RAM. There's a FM24CL04 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:



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:



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.  I suspect they're wired to GND though. I.e., the FRAM will be responsive to addresses like 0b101000XX.

[kfitch42]

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

[ve7xen]

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.

[andyturk]

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. 

[ve7xen]

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.

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. 

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 .

[mojo-chan]

I think the DS2000 has to be the target. It should be possible to enable all the optional features somehow, even if it is just by resetting the time limits on the trial periods.

[andyturk]

I think the DS2000 has to be the target. It should be possible to enable all the optional features somehow, even if it is just by resetting the time limits on the trial periods.

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:

• Is there a CRC in NVRAM? If so, where is it stored and which algorithm?
• What does the firmware do when it detects a bad CRC?
• What's the "spec" for updating a single value?
• Which values are actually stored in NVRAM?
• Can we put together a "memory map" of known values including their offsets and lengths.
• Can the NVRAM chip be written to without removing it from the main board?
• Are any of the programming headers directly attached to the NVRAM?

[cybernet]

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;

[mojo-chan]

It would be really helpful to capture what happens when either a valid code is entered or one of the trial options expires. Having said that it must track the time left on the trials fairly regularly and it must do it in a way that negates the effects of having power removed during an update, i.e. redundant copies.

At the simplest level it is likely to be vulnerable to replay attacks. Even without figuring out how checksums and the like work if we can simply replay the update that writes a large amount of trial time left we can reset the counters any time we like. No free bandwidth upgrades but it would unlock all the options.

[bonanz]

i like where this thread is going

[ve7xen]

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.

Nice work, you've gotten farther than I did with reversing .

[cybernet]

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 ? )

[ikcalB]

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 */

[cybernet]

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 ;-).

[mojo-chan]

I wonder if just breaking the RTC might be enough. Depending on how it works either removing the battery or shorting the crystal might do it. That way the trial options will never expire. A software "fix" would be better though. Just change the code that tracks how long options have left for NOPs.