New Agilent scopes

[EEVblog]

Sounds easy. Does the machine have external RTC chip or integrated into uC?
Does we have any hi-res pictures from the motherboard?

http://www.flickr.com/photos/eevblog/sets/72157626755861230/
and
http://www.flickr.com/photos/eevblog/sets/72157626631250619/

Dave.

[EEVblog]

It's this photo here:
http://www.flickr.com/photos/eevblog/5736595148/#sizes/o/in/set-72157626755861230/
An M41T82R RTC chip
And you can see the xtal here:
http://www.flickr.com/photos/eevblog/5736041287/#sizes/l/in/set-72157626755861230/

Dave.

[ferkapu]

It's this photo here:
http://www.flickr.com/photos/eevblog/5736595148/#sizes/o/in/set-72157626755861230/
An M41T82R RTC chip
And you can see the xtal here:
http://www.flickr.com/photos/eevblog/5736041287/#sizes/l/in/set-72157626755861230/

Dave.

Great work.

But may not easy as I thought. The RTC has some tricky features like oscillator fail interrupt,  frequency test output pin, and watchdog that are used or not by the master device... So simply removing(even pulling) crystal may not works...

Needs another solution.

[EEVblog]

But may not easy as I thought. The RTC has some tricky features like oscillator fail interrupt,  frequency test output pin, and watchdog that are used or not by the master device... So simply removing(even pulling) crystal may not works...
Needs another solution.

Maybe, but worth a shot first.
If not, an add-on board that replaces the chip and generates the required old date. Or break onto the I2C(?) bus and write your own date.

Dave.

[ferkapu]

But may not easy as I thought. The RTC has some tricky features like oscillator fail interrupt,  frequency test output pin, and watchdog that are used or not by the master device... So simply removing(even pulling) crystal may not works...
Needs another solution.

Maybe, but worth a shot first.
If not, an add-on board that replaces the chip and generates the required old date. Or break onto the I2C(?) bus and write your own date.

Dave.

Yes it should work. I'll give it a try, but first I need the fw upgrade.

In case of problems a backdoor needed if any above not works: going back to my actual fw1.20 with the existing trials.

Dave, do you have version 1.2? Would you share it?

[mikeselectricstuff]

But may not easy as I thought. The RTC has some tricky features like oscillator fail interrupt,  frequency test output pin, and watchdog that are used or not by the master device... So simply removing(even pulling) crystal may not works...
Needs another solution.

I wonder if it is the case that maybe the only limitation is on setting the RTC, not what the time it is indicating. In which case maybe you could use I2C to set the time. 

[ferkapu]

But may not easy as I thought. The RTC has some tricky features like oscillator fail interrupt,  frequency test output pin, and watchdog that are used or not by the master device... So simply removing(even pulling) crystal may not works...
Needs another solution.

I wonder if it is the case that maybe the only limitation is on setting the RTC, not what the time it is indicating. In which case maybe you could use I2C to set the time.

A simple routine will set back the time to the firmware's release date at every startup...

So doubtless only a custom made RTC helps.
Or a license keygenerator.
Or little firmware modification.

[_Sin]

It would be trivial for Agilent to check licenses against the firmware-date as well as the RTC. So I wouldn't spend a lot of effort hacking the RTC when, even if it works in the current version, it would be trivial for them to cut that route off in the next update.

However given that the keys leaked with the first release, they can only really secure their licensing system by changing the keys, which in turn would mean re-issuing every single license currently in the field.

And that also assumes that there is no way to simply inject code into the scope which just ignores the license check.

If you're actually going to open the scope and muck about with the internals, you'd probably get more mileage out of reading/writing the flash and just patching code.

[ferkapu]

It would be trivial for Agilent to check licenses against the firmware-date as well as the RTC. So I wouldn't spend a lot of effort hacking the RTC when, even if it works in the current version, it would be trivial for them to cut that route off in the next update.

However given that the keys leaked with the first release, they can only really secure their licensing system by changing the keys, which in turn would mean re-issuing every single license currently in the field.

And that also assumes that there is no way to simply inject code into the scope which just ignores the license check.

If you're actually going to open the scope and muck about with the internals, you'd probably get more mileage out of reading/writing the flash and just patching code.

Where do those keys leaked?

I think there is no need to read/write the flash directly. Only the base date needs to be modified in the .bin files somewhere that sets the "minimal" date set. Isn't it?

[_Sin]

Where do those keys leaked?

I think there is no need to read/write the flash directly. Only the base date needs to be modified in the .bin files somewhere that sets the "minimal" date set. Isn't it?

The keys were in the original firmware update, they left them in by mistake. I don't know if anyone openly posted them, but how/where to find them was widely discussed (if you want a more specific answer, don't look at me - I think it's actually in an earlier post in this thread).

I'm not sure if it's possible to modify a file before updating the scope, or to write to the scope's filesystem. I'd imagine they might at least have check-summed / signed the update package, in which case you'd be out of luck. Worst case you might brick the scope, which is why I'm not going to be trying it on mine any time soon.

However if you *could* modify the files on the device, either by changing the update package or writing to the flash, it would be easier to just take out the license check than to piss about with dates and trial licenses.

[ferkapu]

The answer about keys are in this topic Reply #536.

So what if we have the keys? We put the keys, the ser.no. the required option, and the expirity date into a black box, and it will tell the lic.nr. Uhhh... that is not the way... this is out of my boundaries...

[_Sin]

The answer about keys are in this topic Reply #536.

So what if we have the keys? We put the keys, the ser.no. the required option, and the expirity date into a black box, and it will tell the lic.nr. Uhhh... that is not the way... this is out of my boundaries...

The 'black box' is pretty much fully documented back in post #177.

But yeah, no-one seems terribly inclined to actually fully implement and post a working solution. I don't blame them - I wouldn't.

[SrS]

This scope came with v1.x firmware installed and allowed to sign your own license files using the leaked key
In v2.x Agilent.Cdf.Api.dll has been updated and has some interesting strings:
SecureDataTool_DTDLeaked
SecureDataTool_DTD2
So new scope's probably use a different keyset

[benemorius]

Unfortunately I have the displeasure of reporting that our friends at Agilent have indeed updated the rsa keys since the original private key was leaked. Newer versions of the firmware (2.0 and up, I believe) have a total of three keys (the leaked one plus two new ones) and the key which is used is determined by the serial number of the scope. So it would seem that those who were lucky enough to get one of the first models produced will be able to use the leaked key indefinitely, while anyone with a later model is out of luck unless it is possible to change the serial number of the scope without breaking anything else.

I'm not sure how old a scope has to be to use the old key. Mine came with firmware 2.00 and it uses one of the new keys. I haven't looked in to changing the serial number, but this seems worthy of some investigation.

[_Sin]

This scope came with v1.x firmware installed and allowed to sign your own license files using the leaked key
In v2.x Agilent.Cdf.Api.dll has been updated and has some interesting strings:
SecureDataTool_DTDLeaked
SecureDataTool_DTD2
So new scope's probably use a different keyset

It occurred to me that they might do that, but I hadn't realised they had rolled it out already.

In some ways I'm glad they have. If it was wide open I could see them being reluctant to add new options like the serial decode on the 2k series.

I'm also glad I bought one of the original models.

I guess there's a chance that they might only offer some new features on sufficiently new scopes, but that could be confusing for buyers who had no idea that their serial number would be important...

[ferkapu]

Summarizing the above: is it possible to use trials forever on fw2.0 and above or not?

[benemorius]

Summarizing the above: is it possible to use trials forever on fw2.0 and above or not?

Yes, as long as your trials expire on a date after the compile date of the firmware version you have installed.

[ferkapu]

Summarizing the above: is it possible to use trials forever on fw2.0 and above or not?

Yes, as long as your trials expire on a date after the compile date of the firmware version you have installed.

Only once, or many times? I mean if suddenly trials removed by the machine because the clock forgot to set back, can they be reinstalled again, after set back the date?

[ferkapu]

Let we complete the 3000 firmware line.

Here are the fw1.10, 2.12, 2.20: http://s3.toldacuccot.hu/dl.php?sid=7f8145a7a2dbaa324d84d44e5d01216a&file=1.10_2.12_2.20.7z

Please share the other ones.

[Hypernova]

For those interested:

Just tried on mine, even if your clock was set to the compile date of the previous FW (Apr 18th) after updating it will force you to the new date.

[benemorius]

For those interested:

Just tried on mine, even if your clock was set to the compile date of the previous FW (Apr 18th) after updating it will force you to the new date.

Thanks. You updated from 2.12 to 2.20? Some of us are also interested to know if downgrading is prevented. Can you see whether it will let you install 2.12 again?

[Hypernova]

Nop, it will unpack the .cab but then declare that there's something wrong with it.

[benemorius]

Nop, it will unpack the .cab but then declare that there's something wrong with it.

Well that sucks a lot. Thanks for checking. Can you confirm that you upgraded from 2.12 to 2.20, and then tried and failed to downgrade to 2.12?

[Hypernova]

The help menu says 2.20 and I've been playing with the modulation all morning.

Curiously the expired trial Flexray license disappeared from the list.

[ferkapu]

So no way to go back to 1.xx from 2.xx. That's not a good news...