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/
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";
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 ;-)
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.
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).
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
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
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?
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.
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.
k=40228745953163121 (0x8EEBD4D04C3771)
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!
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.
k=40228745953163121 (0x8EEBD4D04C3771)
Wow!
Thanks for sharing! How did you found it?
Did you use ECCTool? I tried ECCTool but without success.
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
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
Proper foo.ecs would be:
$ cat foo.ecs
46417DA2759BDF
A6AB6A16A8D038
or JV3AZ5J-VXSVRRS-W4XAYWF-XJ4A96L DSA2567890123
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
docmandu you are genius...that is all I have to say.
k=40228745953163121 (0x8EEBD4D04C3771)
Wow! 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...
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.
k=40228745953163121 (0x8EEBD4D04C3771)
Wow! 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!
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.
So how do you actually generate the key for the scopes serial?
I have MIRACL and main.c compiled.
Regards
Daniel