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??
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).
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 ....
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!
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
I'm working on the code for a ATtiny85. Here is the smaller Arduino code.
#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();
}
I think you're responsible for another DS2000 sale.
I think you're responsible for another Arduino UNO sale.
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...
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.
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.
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...
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 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.
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.
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 ...
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.
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
Just managed to discover the BF526 on the JTAG chain
Pinout:
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/
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
jtag> get signal BMODE0
BMODE0 = 1
jtag> get signal BMODE1
BMODE1 = 0
jtag> get signal BMODE2
BMODE2 = 0
jtag> get signal BMODE3
BMODE3 = 0
@ 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.
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.
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...