Author Topic: Sniffing the Rigol's internal I2C bus  (Read 1467791 times)

0 Members and 4 Guests are viewing this topic.

Offline Teneyes

  • Frequent Contributor
  • **
  • Posts: 495
  • Country: ca
Re: Sniffing the Rigol's internal I2C bus
« Reply #50 on: June 02, 2013, 06:54:19 pm »

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

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

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

What is the real time left on your Options??



IiIiIiIiIi  --  curiosity killed the cat but, satisfaction brought it back
 

studio25

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

Yes.

Sorry for my bad english (google translator).
 

studio25

  • Guest
Re: Sniffing the Rigol's internal I2C bus
« Reply #52 on: June 02, 2013, 08:21:14 pm »
Quote
you have confirmed that all of the options (except BW) are turned on and working (as opposed to just displayed minutes changed), right?

Yes.

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

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

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

Oh one more thing ....
 

Offline marmad

  • Super Contributor
  • ***
  • Posts: 2979
  • Country: aq
    • DaysAlive
Re: Sniffing the Rigol's internal I2C bus
« Reply #53 on: June 02, 2013, 08:49:24 pm »
The counter is always running. Even if the trial is expired. He just runs over.
But once the trial is expired will change the byte at address 0x7F8 from 0x00 to 0x01.
To reset the trial time just change the bytes at offset 0x7F6 to 0x49 0x0A 0x00.

Nice video!  :)  Thanks for that.
 

Offline true

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: us
  • INTERNET
Re: Sniffing the Rigol's internal I2C bus
« Reply #54 on: June 02, 2013, 08:55:45 pm »
The counter is always running. Even if the trial is expired. He just runs over.
But once the trial is expired will change the byte at address 0x7F8 from 0x00 to 0x01.
To reset the trial time just change the bytes at offset 0x7F6 to 0x49 0x0A 0x00.

I think you're responsible for another DS2000 sale.

Good work!
 

Offline egonotto

  • Regular Contributor
  • *
  • Posts: 220
Re: Sniffing the Rigol's internal I2C bus
« Reply #55 on: June 02, 2013, 09:05:59 pm »
well done
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 892
  • Country: us
Re: Sniffing the Rigol's internal I2C bus
« Reply #56 on: June 02, 2013, 09:23:14 pm »
 

Offline monster

  • Contributor
  • Posts: 5
Re: Sniffing the Rigol's internal I2C bus
« Reply #57 on: June 02, 2013, 09:31:23 pm »
The counter is always running. Even if the trial is expired. He just runs over.
But once the trial is expired will change the byte at address 0x7F8 from 0x00 to 0x01.
To reset the trial time just change the bytes at offset 0x7F6 to 0x49 0x0A 0x00.
Oh one more thing ....

Olé! Congratulations, if there wasn't so much to do next week ... well anyway, now I know what to do the week after that 8)
 

studio25

  • Guest
Re: Sniffing the Rigol's internal I2C bus
« Reply #58 on: June 02, 2013, 09:49:53 pm »
I'm working on the code for a ATtiny85. Here is the smaller Arduino code.
Code: [Select]
#include <avr/sleep.h>
 #include <Wire.h>

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

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

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

  // sleepmode
  SMCR = (1<<SM1) | (1<<SE);
  sleep_cpu();
}
« Last Edit: June 03, 2013, 08:21:55 pm by studio25 »
 

Offline true

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: us
  • INTERNET
Re: Sniffing the Rigol's internal I2C bus
« Reply #59 on: June 02, 2013, 10:21:28 pm »

I think you're responsible for another DS2000 sale.


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

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

I'm working on the code for a ATtiny85.

You leave nothing for me to do...
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 892
  • Country: us
Re: Sniffing the Rigol's internal I2C bus
« Reply #60 on: June 02, 2013, 10:39:09 pm »
Not that I'm really qualified to do this but...

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

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

Just a thought.
 

Offline cybernet

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: Sniffing the Rigol's internal I2C bus
« Reply #61 on: June 02, 2013, 10:42:29 pm »
Not that I'm really qualified to do this but...

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

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

Just a thought.

doing that since about a week or so - but the discovered TWI functions so far a slave mode, not master mode - a lot of stuff is happening via DMA transfers to from the fpga (assumption). they use VDK and threads, which makes reversing a pain in the ass, 8k subs, thousands of pointers ... im slowly approaching the right subs. if anyone has ida with the blackfin cpu from rigol homebrew, im happy to share my custom GEL loader, and IDA DB.
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12001
  • Country: gb
    • Mike's Electric Stuff
Re: Sniffing the Rigol's internal I2C bus
« Reply #62 on: June 02, 2013, 10:52:32 pm »
I wonder if the I2C lines connect to a device which has JTAG, and is on the chain connected to the header on the back...
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline marmad

  • Super Contributor
  • ***
  • Posts: 2979
  • Country: aq
    • DaysAlive
Re: Sniffing the Rigol's internal I2C bus
« Reply #63 on: June 02, 2013, 11:11:08 pm »
It's likely that upon entering a key, there's some "permanent" change made to NOR flash. I.e., license keys aren't entered very often and setting a flag in flash won't cause write endurance issues. In contrast, writing to NOR flash for every tick of the options timer would be a bad idea.

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

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12001
  • Country: gb
    • Mike's Electric Stuff
Re: Sniffing the Rigol's internal I2C bus
« Reply #64 on: June 02, 2013, 11:42:26 pm »
It's likely that upon entering a key, there's some "permanent" change made to NOR flash. I.e., license keys aren't entered very often and setting a flag in flash won't cause write endurance issues. In contrast, writing to NOR flash for every tick of the options timer would be a bad idea.

But what's odd is that Rigol doesn't seem to write to NOR flash once the 'trial' options expire - which normally should happen just once (or perhaps twice - if you happen to get an extra trial options key); that just seems like such a basic security measure.
It's entirely possible, maybe probable,  that trials and full licenses use a completely different mechanism.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline JimmyMz

  • Regular Contributor
  • *
  • Posts: 56
  • Country: us
Re: Sniffing the Rigol's internal I2C bus
« Reply #65 on: June 02, 2013, 11:44:50 pm »
Quote
Have you confirmed that all of the options are working?
Yes.
I hope this ends up benefiting some people. It will be cool to see where this heads. 
« Last Edit: June 03, 2013, 08:09:31 pm by JimmyMz »
If you didn't get this message, let me know, and I'll get you another.
 

studio25

  • Guest
Re: Sniffing the Rigol's internal I2C bus
« Reply #66 on: June 02, 2013, 11:51:21 pm »
It's likely that upon entering a key, there's some "permanent" change made to NOR flash. I.e., license keys aren't entered very often and setting a flag in flash won't cause write endurance issues. In contrast, writing to NOR flash for every tick of the options timer would be a bad idea.

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

At least the used license key to reactivate the trial options is stored in flash. I can not use it twice ...
 

Offline marmad

  • Super Contributor
  • ***
  • Posts: 2979
  • Country: aq
    • DaysAlive
Re: Sniffing the Rigol's internal I2C bus
« Reply #67 on: June 03, 2013, 12:04:28 am »
It's entirely possible, maybe probable,  that trials and full licenses use a completely different mechanism.

But I never doubted that. Nonetheless, it requires virtually no storage space - and very little code - to implement security against trial options being repeatedly restarted without license codes.
« Last Edit: June 03, 2013, 12:36:59 am by marmad »
 

Offline MrsR

  • Regular Contributor
  • *
  • Posts: 118
  • Country: au
Re: Sniffing the Rigol's internal I2C bus
« Reply #68 on: June 03, 2013, 05:59:41 pm »
An answer to a early Question page 2 I think.
The MCU 8051RNL is a USB Serial in out controller it is most likely the point where the SPI code is used.
I am not software only hardware but I have given Teneyes the full data and expect him to post it soon.

Rachael :-+
 

Offline cybernet

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: Sniffing the Rigol's internal I2C bus
« Reply #69 on: June 03, 2013, 07:25:34 pm »
Just managed to discover the BF526 on the JTAG chain :-DD  >:D

Pinout:

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

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

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

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

JTAG Key: http://www.amontec.com/
« Last Edit: June 03, 2013, 08:21:55 pm by cybernet »
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

Offline cybernet

  • Regular Contributor
  • *
  • Posts: 247
  • Country: 00
  • pm deactivated, use the search function ...
Re: Sniffing the Rigol's internal I2C bus
« Reply #70 on: June 03, 2013, 07:30:45 pm »
Code: [Select]
jtag> cable jtagkey
Connected to libftd2xx driver.
jtag> frequency 5000000
Setting TCK frequency to 5000000 Hz
jtag> detect
IR length: 5
Chain length: 1
Device Id: 00100010011111100100000011001011 (0x00000000227E40CB)
  Manufacturer: Analog Devices
  Part(0):         BF526
  Stepping:     2
  Filename:     c:\program files\urjtag\data/analog/bf527/bf527
jtag> print chain
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
-
   0 Analog Devices            BF526                2        BYPASS

Code: [Select]
jtag> get signal BMODE0
BMODE0 = 1
jtag> get signal BMODE1
BMODE1 = 0
jtag> get signal BMODE2
BMODE2 = 0
jtag> get signal BMODE3
BMODE3 = 0
« Last Edit: June 03, 2013, 08:36:00 pm by cybernet »
___________________
"all rights reversed :-)"
R0=-0x18;
UNLINK;
RTS;
 

studio25

  • Guest
Re: Sniffing the Rigol's internal I2C bus
« Reply #71 on: June 03, 2013, 08:32:36 pm »

@ Studio25,

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

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

After the self-calibration the counter starts at zero. There seems to be a 32bit counter @ offset 0x7F6 .. 0x7F9.
 

studio25

  • Guest
Re: Sniffing the Rigol's internal I2C bus
« Reply #72 on: June 03, 2013, 10:11:46 pm »
All files for download

- Arduino sketch
- ATtiny85 code + hex
- Schematic

http://rapidshare.com/files/418919055/Rigol%20DS2000%20trial%20hack.rar
 

Offline JimmyMz

  • Regular Contributor
  • *
  • Posts: 56
  • Country: us
Re: Sniffing the Rigol's internal I2C bus
« Reply #73 on: June 03, 2013, 10:14:56 pm »
All files for download
Thank You   :-+
If you didn't get this message, let me know, and I'll get you another.
 

studio25

  • Guest
Re: Sniffing the Rigol's internal I2C bus
« Reply #74 on: June 03, 2013, 10:28:15 pm »

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

oooo the downloads are up, Thanks Studio25


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

But in reality it is:
0xFF 0xFF 00 00 -> 0x00 0x00 0x01 0x00 -> 0x01 0x00 0x01 0x00 -> 0x02 0x00 0x01 0x00 ... 0xFF 0xFF 0xFF 0x00 -> 0x00 0x00 0x00 0x01 -> 0x01 0x00 0x00 0x01...
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf