Sniffing the Rigol's internal I2C bus

[zombie28]

Bottom line: is the DS2072A hackable to 300 MHz with all options or not?

Not yet, but I believe it will be soon.

I have just finished analysis of license decoder and collected enough information to rewrite it into C. If anyone has A-type license code and doesn't mind sharing it with me, please send me PM. This would speed up the whole process.

[marmad]

The old unit DS2072 is still available, but I guess it is wise to buy the newer unit from a support perspective, or is there no concern here?

There is no concern that support for non-A models will stop; there have been MANY of them sold - the FW works for both models. It will be a long time until as many A models are sold.

[chebeba]

I have just finished analysis of license decoder and collected enough information to rewrite it into C.

Just out of curiosity, and maybe because I am looking a little bit at learning to code for CUDA:

Couldn't this be used to brute force the new private key? It's only 48 bits, as far as I can see...

[AndersAnd]

I have just finished analysis of license decoder and collected enough information to rewrite it into C.

Just out of curiosity, and maybe because I am looking a little bit at learning to code for CUDA:

Couldn't this be used to brute force the new private key? It's only 48 bits, as far as I can see...

zombie28 has already posted the new private key:

I found function that loads alternative public key in DS2K-A firmware. The new public key is 0xA51BF373712F7D and the private key (that matches old Rigol ECC parameters) is 0x888E77EE47C50A. I don't have DS2K-A scope yet, so I can't confirm if this key will work with existing keygens.

[NikWing]

yes, but there's something else missing since this private key doesn't work yet
I think that's what zombie28's working on atm

[Co6aka]

Well, it depends on if they decide to change the encryption algorithm or not.

Actually, if code can be "debugged" it can be hacked, so it doesn't really matter what algos are used; at some point (in the code) there's a "BNE" on an invalid key that can be "NOP'ed" out. (Also, the encryption routines can be copied out and reversed, and somewhere has got to be the private key.) They could make life difficult by employing obfuscation, self-decrypting code, anti-debugging, and etc. They could disable/remove debugging support from the hardware, encrypt the firmware and embed decryption in the CPU, pot the whole thing, and require units to be sent in for firmware upgrades...

Bottom line: It's hackable. Period. Get over it. Let the popularity boost sales and capture market share, bump up prices accordingly, and sell lotsa hardware. Heck, open source the thing, and let the hacker community develop advanced features and bug fixes. Let the staff coders focus on new products, and assign one to "manage" the open source project.

[cidcorp]

Re. DP832 Power Supply

Does the 1.03c Keygen still work on the DP832?  I understand that 1. Firmware 01.06.00 should be installed,  2. Install the keys, and then 3. Upgrade the firmware to 01.08.00.
Does this still work Ok?   I seem to recall that someone said they lost everything including the metering accuracy.
Is there anything to this, and if so, can it be prevented?

Thank you for assistance, Wallie

Wallie,

I think there's been a couple questions asked regarding the DP832 and using the Keygen, but it appears no one has the answer.

I've been following this thread since the beginning and my head is starting to spin - 

As a summary to the thread, the DS2000 non A models: HW 1 upgradable (but someone has voiced issues regarding the 300Mhz mod causing issues, so stick to 200Mhz as the max bandwidth upgrade) - 50 Ohm Option doesn't work, HW 2 is upgradable to 300Mhz - 50 Ohm option is working.  The DS2000 A models are currently not hackable but zombie28 is looking close to solving that.

As for the DP832, I seem to remember someone stating the keygen is working, but just a few pages ago someone also said they lost the ADC accuracy (or something like that) after using the keys to upgrade, I'm holding out until someone confirms the key gen isn't causing issues on the DP832.

Edit: Well this thread is becoming a monster - I have checked back in the thread an can't find any confirmation of the 50 ohm termination option on the HW version 2 non-A, so I may be wrong there.


Chris

[alank2]

HW 2 is upgradable to 300Mhz - 50 Ohm option is working.

I don't think anyone has the 50 ohm option working on their non A model yet do they?

[m-joy]

i thought 300 Mhz is "buggy" on all devices...

[marmad]

Heck, open source the thing, and let the hacker community develop advanced features and bug fixes. Let the staff coders focus on new products, and assign one to "manage" the open source project.

Yeah, that's gonna happen 

[cidcorp]

i thought 300 Mhz is "buggy" on all devices...

I thought the issues were only with the version 1 HW, which is what I have... 

Chris

[Co6aka]

Exactly...   (Makes way-way too much sense, so...)


Got a shiny new Amontec JTAGkey2P sitting on my bench right in front of my DSA1030A... 

[Gallymimus]

Actually, if code can be "debugged" it can be hacked, so it doesn't really matter what algos are used; at some point (in the code) there's a "BNE" on an invalid key that can be "NOP'ed" out. (Also, the encryption routines can be copied out and reversed, and somewhere has got to be the private key.) They could make life difficult by employing obfuscation, self-decrypting code, anti-debugging, and etc. They could disable/remove debugging support from the hardware, encrypt the firmware and embed decryption in the CPU, pot the whole thing, and require units to be sent in for firmware upgrades...

Bottom line: It's hackable. Period. Get over it. Let the popularity boost sales and capture market share, bump up prices accordingly, and sell lotsa hardware. Heck, open source the thing, and let the hacker community develop advanced features and bug fixes. Let the staff coders focus on new products, and assign one to "manage" the open source project.

    NAIVE! 

[Mark_O]

Heck, open source the thing, and let the hacker community develop advanced features and bug fixes. Let the staff coders focus on new products, and assign one to "manage" the open source project.

Yeah, that's gonna happen 

Well, I'm sure other scope companies would appreciate that.     Heck, then even Hantek might have at a chance at halfway decent firmware.  And their scopes would finally support SCPI.

The downside would be that the competition would then lay off their teams of development programmers.  Do you really want that one guy at Hantek to be out of a job?   

[zombie28]

So here it is, the new license code decoder:

Code: [Select]

//
// Copyright (c) 2013 RIGLOL Technologies, Inc. All Rights Reversed.
// This product includes software developed by the OpenSSL Project
// for use in the OpenSSL Toolkit. (http://www.openssl.org/)
//
#include <string.h>
#include "rc5.h"

typedef unsigned char uint8;
typedef unsigned int uint32;
typedef unsigned long long uint64;

#define LICENSE_CODE_LENGTH 28

static const uint8 RC5Key1[16] = { 0x3F, 0x57, 0x8E, 0x1C, 0x44, 0x18, 0x34, 0xDD, 0xA5, 0x46, 0x21, 0x36, 0x32, 0x81, 0xFB, 0xCF };
static const uint8 RC5Key2[16] = { 0x14, 0xDC, 0x15, 0xAF, 0xA1, 0x48, 0x3D, 0x7D, 0x6A, 0xC1, 0xDC, 0xA1, 0x79, 0x8D, 0xAA, 0x3E };

uint32 DecodeChar(char value)
{
char *charMap = "LRE8YFGHJK9SNBQ36MPVWXAZ2U45TC7D";
char *charPos = strchr(charMap, value);
return charPos == NULL ? 0 : charPos - charMap;
}

uint64 DecodeSignature(uint64 value)
{
uint32 shiftCount = value & 0x0f;
do value >>= 4; while(shiftCount-- > 0);
return value;
}

uint32 DecodeLicenseCode(char *licenseCode, uint64& sig1, uint64& sig2)
{
if(strlen(licenseCode) != LICENSE_CODE_LENGTH)
return 0;

uint8 licenseBits[35];

for(int i = 0, j = 0; i < LICENSE_CODE_LENGTH; i += 4, j += 5)
{
uint32 bitBuffer =
(DecodeChar(licenseCode[i]) << 15) +
(DecodeChar(licenseCode[i+1]) << 10) +
(DecodeChar(licenseCode[i+2]) << 5) +
DecodeChar(licenseCode[i+3]);

licenseBits[j] = bitBuffer >> 16;
licenseBits[j+1] = (bitBuffer >> 12) & 0xf;
licenseBits[j+2] = (bitBuffer >> 8) & 0xf;
licenseBits[j+3] = (bitBuffer >> 4) & 0xf;
licenseBits[j+4] = bitBuffer & 0xf;
}

uint64 RC5Block1 = 0;
uint64 RC5Block2 = 0;

for(int i = 0; i < 16; i++)
{
RC5Block1 |= uint64(licenseBits[i]) << i*4;
RC5Block2 |= uint64(licenseBits[i + 16]) << i*4;
}

RC5_32_KEY RC5Key;

RC5_32_set_key(&RC5Key, 16, RC5Key1, 16);
RC5_32_ecb_encrypt((uint8*)&RC5Block1, (uint8*)&RC5Block1, &RC5Key, 1);

RC5_32_set_key(&RC5Key, 16, RC5Key2, 16);
RC5_32_ecb_encrypt((uint8*)&RC5Block2, (uint8*)&RC5Block2, &RC5Key, 0);

// ECDSA signature
sig1 = DecodeSignature((RC5Block2 >> 8) | (uint64(licenseBits[33]) << 56));
sig2 = DecodeSignature(((RC5Block1 & 0xffffffffffff) << 8) | (RC5Block2 & 0xff) | (uint64(licenseBits[32]) << 56));

// option bits
return uint32(RC5Block1 >> 48) | (uint32(licenseBits[34]) << 16);
}


[NikWing]

nice
and now?

[zombie28]

nice
and now?

it's time to reverse

[pascal_sweden]

Did you get access to the source code of the license generator?
How did you do that?

Then it should be straightforward to get the keys no?
I need to know about DS2072A within 2 weeks. Then I will order one
Pity there is no 4 channel version.

BTW: How does Siglent SDS2000 compare with Rigol DS2000 series?
Siglent has 4 channels, but more expensive?

[marmad]

BTW: How does Siglent SDS2000 compare with Rigol DS2000 series?
Siglent has 4 channels, but more expensive?

The fact that the Siglent has not been released yet - and no one knows much about it, or when it will be on sale - has been written about extensively in another thread which you started - plus it's off-topic here.

[neslekkim]

So here it is, the new license code decoder:

How do you manage to do this?, decompiling the sources?
Is there a way to take apart the gel files, or are you decompiling from the jtag dumps?
Is this the blackfin thingy that executes this code?

[marmad]

Siglent sells the SDS2000 series in Europe through their webshop:
http://www.siglent.eu/oscilloscopes/sds-2000-series.html

So is it available then?

Or do I miss something here...

Siglent, like GW-Instek before them (and every other Chinese manufacturer), is late to produce a < $1000 DPO - since Rigol beat everyone to the punch and took over the market share. So they, like Instek before them, are rushing to do anything they can to try to reduce Rigol's share. In GW-Instek's case, it was hurrying out a product which just wasn't competitive enough - in Siglent's case, they are dashing out publicity statements, "for sale" internet ads, and demo models of a product which (although perhaps as nice/nicer than the DS2000) is not ready for market yet. You can read all about it in other threads here.

[andyturk]

Code: [Select]

// Copyright (c) 2013 RIGLOL Technologies, Inc. All Rights Reversed.

 

[zombie28]

How do you manage to do this?, decompiling the sources?
Is there a way to take apart the gel files, or are you decompiling from the jtag dumps?

I decompiled memory dump provided by tirulerbach (the one after entering 'AAAAAAABBBB...' license code) and after I understood how original decoder worked, I wrote my own version of it.

Is this the blackfin thingy that executes this code?

Yes, Rigol uses blackfin in DS2K scopes.

[neslekkim]

what about the gel files?, what format is that?, not this I guess: http://processors.wiki.ti.com/index.php/GEL

[blandin_01]

I'm sorry to have to pass here uint32 DecodeLicenseCode (char * licenseCode, uint64 & sig1, uint64 & sig2)
licenseCode - ?  sig1- ?  sig2 - ? please describe