DSOX2000 and 3000 series - licence , have anyone tried to hack that scope ?  - Page 1
Forum section: electronics / testgear

author: eevblogfan
author_rank: Frequent Contributor
timestamp: April 08, 2013, 07:22:59 am
content: heyI know it's stupide/newbie question but I'll ask it anyway ,as all knows , you buy the base unit witch in terms of HW it has all , but licence is the big deal witch cost you a-lot , the question is : have anyone tried to write he's own version ? have anyone successfully hack the scope andupgraded the BW to say 200Mhz instead of 70 or so on ? or enable the memory function gen etc ??P.S: I don't know if it's related to here or perhaps projects (?) so please move me if I am wrongthank you in advance

author: EEVblog
author_rank: Unknown
timestamp: April 08, 2013, 08:38:59 am
content: Nope, no one has done it yet.

author: eevblogfan
author_rank: Frequent Contributor
timestamp: April 08, 2013, 08:41:44 am
content: what a bugersince I don't know FPGA and al that sort of stuff I can't even try by my ownit'll be funny if ther's someone who does know how and will manage to do that

author: poorchava
author_rank: Super Contributor
timestamp: April 08, 2013, 09:30:34 am
content: Since only thing you need to do to activate all the options is to input correct code. So everything is in there. But I'm pretty sure that Agilent uses some sort assymetric public key crypto system. And I'm also quite sure that whichever chip in the scope does that, is probably tamper-protected to prevent key extraction.And if you find a way to break/bruteforce that sort of crypto be ready for either of those things to happen:-get a job in CIA/FBI/etc-get shot by CIA/FBI/etc-make it public and get a Nobel prize (and then get shot by CIA/FBI/etc)

author: _Sin
author_rank: Regular Contributor
timestamp: April 08, 2013, 09:40:04 am
content: License hacks were fairly trivial on the earlier scopes as the keys used were accidentally exposed in a firmware update. They're apparently using new keys now, so current scopes aren't vulnerable, but the older ones still are, even with the newly released features.There was quite a discussion about it in the original thread about these scopes.Of course you don't get the probes if you hack increased b/w or MSO features, and they frequently give away the wavegen + dvm features - the serial decode and memory options are more attractive.

author: Someone
author_rank: Super Contributor
timestamp: April 08, 2013, 12:18:58 pm
content: Quote from: _Sin on April 08, 2013, 09:40:04 amReally? I thought most of the options were only embedded in the newer firmware releases?

author: _Sin
author_rank: Regular Contributor
timestamp: April 08, 2013, 02:52:05 pm
content: Quote from: Someone on April 08, 2013, 12:18:58 pmSure, but putting a newer firmware on an older scope does not alter the keys.

author: Someone
author_rank: Super Contributor
timestamp: April 09, 2013, 12:24:06 am
content: Quote from: _Sin on April 08, 2013, 02:52:05 pmBut why would they offer a trial matching the keys on a firmware version that doesnt have that option embedded? As far as I can tell the old firmware simply doenst have some of the options, so they might need to continue offering the trials of the options that were available in the leaked key against it for that odd customer who hasnt done a firmware update, but why would they release trials or licenses for the new options against the old keys? since you'd have to have the new firmware installed to use them.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: April 09, 2013, 12:45:54 am
content: I don't understand why the keys would be persistent in the scope - surely new firmware = (potentially) new keys, if you want a newer option one an old scope you need to update the FW anyway.I think I'd be looking at how easy it is to load a modified firmware image - finding the "If <something> then <enable funtion>" code and patching it out shoudn't be that hard.

author: ve7xen
author_rank: Super Contributor
timestamp: April 09, 2013, 01:26:09 am
content: Quote from: mikeselectricstuff on April 09, 2013, 12:45:54 amI guess if the trusted keys were part of a user-initiated update process they would be much easier to manipulate than if they're stored in some memory that is at least never written from the code, or possibly write-protected or write-once?If they're doing secure boot from a read-only bootloader it's probably pretty hard to circumvent, depending on how secure their 'read only' is. If the code can be modified relatively easily and the 'scope will accept it, well it's kind of pointless, but why make things easy.

author: zibadun
author_rank: Regular Contributor
timestamp: April 09, 2013, 01:45:03 am
content: Actually the private key used to generate the code does not need to be present in the scope at all. Checking validity of the code can be done with a different (public) key. Knowing that key will not help with generating a new code. All this assuming a correctly implemented public key system. Did they bother to do this or used the same key for both encryption and validation? I guess time will tell

author: _Sin
author_rank: Regular Contributor
timestamp: April 09, 2013, 06:10:31 am
content: Quote from: mikeselectricstuff on April 09, 2013, 12:45:54 amIf they did, every single scope in the field would need new licenses issuing for every enabled feature.And it's not clear how they would field upgrade scopes without exposing any new keys in the same way as the old keys were (the leak happened because they left the utility which initialises the scope, including the keys, inside the firmware package).So it may actually involve not only issuing new keys, and new licenses, but recalling every scope so it can be done at the factory...I guess they're happier just to ignore the small number of people who have both an original scope, and the desire to hack around with it. They're not cheap devices, I doubt it's a huge problem for them.

author: eevblogfan
author_rank: Frequent Contributor
timestamp: April 09, 2013, 06:23:26 am
content: heycan you use the 30 day trail and hack the scope to think the 30 day's weren't pass ?thank you in advance

author: _Sin
author_rank: Regular Contributor
timestamp: April 09, 2013, 06:34:01 am
content: Quote from: Someone on April 09, 2013, 12:24:06 amThe don't issue licenses against firmware versions, they issue licenses against a key, which is stored securely on the scope and (so far) is not updated. Old scopes have one key, which was accidentally published, and new scopes have a different key which AFAIK is still secure.They likely won't change the keys in a firmware update, and doing so securely would be expensive and awkward for both them and customers (see my previous reply to Mike on why I think that is the case).They can determine which key your scope uses, presumably just using the serial number, which they need to have in order to issue a license anyway, as it's part of the license string (which is what prevents a license for one scope being any use on another).Certainly to date, an old scope uses the old keys even with the latest firmware, and so licenses for the new features *need* to be issued with those keys.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: April 09, 2013, 09:09:00 am
content: Quote from: _Sin on April 09, 2013, 06:10:31 amThat assumes that installed licenses are stored as-is, and validated at startup, which isn't the only way to do it.One approach would be that 'feature enable' flags are stored in NVRAM or system-writable flash, and get set by entering the license key. So the key is only needed for the process of activating a new feature, and can live in the firmware. Key updates would only affect the process of issuing new licenses, which would be manageable fairly easily, by saying that any new licenses must be installed under the latest FW version.Obviously this assumes a suitably secure nonvolatile store - NVSRAM in a BGA would be pretty effective.It also assumes you can't load unauthorised firmware, but if you could, you could patch out the checks so that's no worse.

author: _Sin
author_rank: Regular Contributor
timestamp: April 09, 2013, 10:12:22 am
content: You'd need to store more than a flag, as the license may also contain an expiry date, and the storage would need to be flexible to store any number of licenses, whereas by only storing the key and the serial#, it's fixed, and quite small. By storing the license and validating, it can be as large as there is ordinary flash storage and forward compatible with any new software feature.And I'm not really making assumptions here - it's been established that license hacking in this way works, so implementation details aside, this is how it is done.So yes, they could have implemented the system differently, but they didn't. It wouldn't have mattered if they hasn't released their own keys.

author: ben_r_
author_rank: Frequent Contributor
timestamp: April 10, 2013, 04:18:39 pm
content: Ha, I almost created the same thread when I started looking at the 2000/3000 X-Series. After quite a bit of searching I was able to find a couple threads that made it sound they had not been hacked. Sort of surprising considering how many very intelligent people buy and use this kind of tool. Oh well, maybe someday. Until then, I guess Agilent just gets more money from me.

author: marmad
author_rank: Super Contributor
timestamp: April 10, 2013, 04:35:07 pm
content: Quote from: ben_r_ on April 10, 2013, 04:18:39 pmI just assumed most of the people/companies who could readily afford that type of tool don't really need to be hacking options.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: April 10, 2013, 04:56:06 pm
content: Quote from: _Sin on April 09, 2013, 10:12:22 amTrue, but I'd guess storing an expiry date still takes less space than a license key, so probably not much difference. Just need to allocate enough fixed locations for the number of envisaged future options, as opposed to the maximum number of keys installable at one time.

author: grego
author_rank: Frequent Contributor
timestamp: April 10, 2013, 05:00:00 pm
content: Quote from: marmad on April 10, 2013, 04:35:07 pmWhat marmad said.We don't need a philosophical argument here but remember that Agilent maintains its cutting edge because its profitable. If it wasn't profitable they wouldn't be in that market. I never understood this really - it's not like Agilent has a lock on the market - if you don't like or can't afford their equipment buy something else. There's plenty of manufacturers out there.

author: ben_r_
author_rank: Frequent Contributor
timestamp: April 10, 2013, 05:22:41 pm
content: Quote from: marmad on April 10, 2013, 04:35:07 pmThats what I would assume as well, but the mere concept of "hacking" did not come about from those trying to save money, but for the challenge of undoing what was done and beating a system. Then they typically just give it to the rest.

author: ben_r_
author_rank: Frequent Contributor
timestamp: April 10, 2013, 05:24:23 pm
content: Quote from: grego on April 10, 2013, 05:00:00 pmYou cant understand the natural desire to get more for less? Everyonewantsthat, we just dont always get it.

author: marmad
author_rank: Super Contributor
timestamp: April 10, 2013, 05:44:04 pm
content: Quote from: ben_r_ on April 10, 2013, 05:22:41 pmIn general that might be true - but in this context - hacking test and measurement gear (which means you might brick the equipment which you use - i.e. much different possible ramifications than mere software hacking), I think the motives would likely be closer to getting bandwidth, options, etc. that you'd like to have for your own use - but can't readily afford to pay for.

author: ben_r_
author_rank: Frequent Contributor
timestamp: April 10, 2013, 06:27:30 pm
content: Quote from: marmad on April 10, 2013, 05:44:04 pmWell I was referring to the real first hacking, back in the hardware, phreaking, etc days before there was "software", but yes I understand your point.

author: Hypernova
author_rank: Unknown
timestamp: April 11, 2013, 08:28:52 am
content: There's no real need to hack them anyway given you can just dial back the clock.