hey
I 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 wrong
thank you in advance
Nope, no one has done it yet.
what a buger
since I don't know FPGA and al that sort of stuff I can't even try by my own
it'll be funny if ther's someone who does know how and will manage to do that
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)
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.
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.
Really? I thought most of the options were only embedded in the newer firmware releases?
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.
Really? I thought most of the options were only embedded in the newer firmware releases?
Sure, but putting a newer firmware on an older scope does not alter the keys.
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.
Really? I thought most of the options were only embedded in the newer firmware releases?
Sure, but putting a newer firmware on an older scope does not alter the keys.
But 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.
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.
I don't understand why the keys would be persistent in the scope - surely new firmware = (potentially) new keys.
I 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
.
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
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.
If 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.
hey
can you use the 30 day trail and hack the scope to think the 30 day's weren't pass ?
thank you in advance
But 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.
The 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.
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.
If they did, every single scope in the field would need new licenses issuing for every enabled feature.
That 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.
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.
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.
Sort of surprising considering how many very intelligent people buy and use this kind of tool.
I just assumed most of the people/companies who could readily afford that type of tool don't really need to be hacking options.
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.
True, 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.
Sort of surprising considering how many very intelligent people buy and use this kind of tool.
I just assumed most of the people/companies who could readily afford that type of tool don't really need to be hacking options.
What 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.
Sort of surprising considering how many very intelligent people buy and use this kind of tool.
I just assumed most of the people/companies who could readily afford that type of tool don't really need to be hacking options.
Thats 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.
Sort of surprising considering how many very intelligent people buy and use this kind of tool.
I just assumed most of the people/companies who could readily afford that type of tool don't really need to be hacking options.
What 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.
You cant understand the natural desire to get more for less? Everyone
wants that, we just dont always get it.
Thats 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.
In 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.
Thats 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.
In 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.
Well 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.
There's no real need to hack them anyway given you can just dial back the clock.