MDO3000 hacking

[kilohercas]

Today is a good day, i get my MDO3104 oscilloscope with AFG, SA, and MSO options. Based on my experience with MSO2000 i thought that MDO3000 will use simple 24C04 EEPROM. But this assumption was so wrong.

So first step was to take my hacked DPO2EMBD module, and write MDO3EMBD code. And what do you know, MDO3000 will recognize that i have option installed, but i can't move my license to scope, so i could apply another one. That was very strange. Since i have original MDO3000x series app modules, i simply dissemble it, and was expecting simple EEPROM, but no! It get very strange tek part number. I was trying to read it with STM32F429, but it was unresponsive ( 24C04 will have 0xA0 address ).

Next step , i soldered SDA, and SCL, and ground, so i could probe while MDO3104 will check eeprom. And what do you know, address is 0x8C. I google it, and is is very fancy protected EEPROM from Atmel, with advanced security options :-(

• Secure authentication and validation device
• Integrated capability for both Host and Client operations
• Superior SHA-256 Hash algorithm with Message Authentication Code (MAC) and Hash-Based Message Authentication Code (HMAC) options
• Best-in-class, 256-bit key length; storage for up to 16 keys
• Guaranteed unique 72-bit serial number
• Internal, high-quality Random Number Generator (RNG)
• 4.5Kb EEPROM for keys and data
• 512 OTP (One Time Programmable) bits for fixed information
• Multiple I/O options
• High-Speed, Single-Wire Interface
• 1MHz I2C interface

Part number ATSHA204

[abyrvalg]

A quick look into MDO3k firmware update package (outer .img is Linux EXT3 image file - use any EXT3 tool, inner filesystem.img file is SquashFS image - use 7-zip) reveals many interesting things: /usr_1/local/bin/scopeApp.imx6 is an unstripped ELF executable (all debug info like functions/vars names is there), there are functions like cmdSet_Cfg_fixedLicenseKey, there are some AES keys used to decrypt those LicenseKeys 

[kilohercas]

A quick look into MDO3k firmware update package (outer .img is Linux EXT3 image file - use any EXT3 tool, inner filesystem.img file is SquashFS image - use 7-zip) reveals many interesting things: /usr_1/local/bin/scopeApp.imx6 is an unstripped ELF executable (all debug info like functions/vars names is there), there are functions like cmdSet_Cfg_fixedLicenseKey, there are some AES keys used to decrypt those LicenseKeys 

I am no windows or Linux programmer, i don't know any of this stuff 

[tinhead]

A quick look into MDO3k firmware update package

actually they all (DPO/MSO 2000,3000,4000 x/B, GPIB-USB, more?) Linux based, sure different µC and FPGAs (if any) but executables are always with debug informations and fw contains lot of "tools".

[mikeselectricstuff]

Just because a chip has a load of security features, it doesn't necessarily mean they're all used, or used effectively - it's always worth a closer look....

[abyrvalg]

There is enough data inside the scopeApp to talk to ATSHA chip (there are even some keys to initialize a blank module), but it still requires lots of work to implement the protocol/crypto stuff. I would choose straight attacking the option keys check algo instead - this can be even easier. Quick disassembly suggests something like OptionKeyString=base64encode(AES({InstrumentId,OptionsMask,CRC})) with AES key hardcoded and clearly seen. Does anybody have a working option key sample to try decryption?

[kilohercas]

Does anybody have a working option key sample to try decryption?

I have MDO3PWR module. I can transfer license to scope, and after that, I can do what ever I whant with this module. Data should be the same,only part of data will indicate, that license is transferred.

[abyrvalg]

No, I mean different thing: there is some menu to enter an "option key" into the scope (look for "Please enter a valid option key by using the screen controls or a USB keyboard" text) to enable additional features:

Code: [Select]

Aerospace serial bus
Audio serial bus key
Automotive serial bus
Full Automotive serial bus
Computer serial bus
Embedded serial bus
Ethernet serial bus
FlexRay serial bus
USB serial bus
Limit/Mask test
Power analysis
RF triggering
HD and Custom Video
Calibration bit for manufacturing test
Beta release
Internal demo unit
Distribution Demo Unit
70MHz bandwidth
100MHz bandwidth
200MHz bandwidth
300MHz bandwidth
350MHz bandwidth
500MHz bandwidth
1GHz bandwidth
2GHz bandwidth
Upgrade bandwidth from 70MHz to 100MHz
Upgrade bandwidth from 70MHz to 200MHz
Upgrade bandwidth from 100MHz to 200MHz
Upgrade bandwidth from 100MHz to 300MHz
Upgrade bandwidth from 100MHz to 350MHz
Upgrade bandwidth from 100MHz to 500MHz
Upgrade bandwidth from 200MHz to 350MHz
Upgrade bandwidth from 200MHz to 500MHz
Upgrade bandwidth from 300MHz to 500MHz
Upgrade bandwidth from 350MHz to 500MHz
Upgrade bandwidth from 100MHz to 1GHz
Upgrade bandwidth from 200MHz to 1GHz
Upgrade bandwidth from 350MHz to 1GHz
Upgrade bandwidth from 500MHz to 1GHz
Digital Voltmeter
Arbitrary Function Generator
Mixed Signal Oscilloscope
Spectrum analyzer maximum input frequency
Security lockout
It should be possible to calculate these keys "at home" (symmetric cryptography there, no unknown RSA keys as in Agilent 2k/3k)

[kilohercas]

No, I mean different thing: there is some menu to enter an "option key" into the scope (look for "Please enter a valid option key by using the screen controls or a USB keyboard" text) to enable
It should be possible to calculate these keys "at home" (symmetric cryptography there, no unknown RSA keys as in Agilent 2k/3k)

i could give example related to my serial number and Digital Voltmeter option that is free, and yes, it is enabled by code. But i don't know will all functions will work this way, since application modules is usually needed for activating bus decode and so on. same for logic analyzer, spectrum analyzer, and AFG and yes, i have them all ( because why do they bother to make application module upgrade via eeprom, if they could generate code like Agilent, ok for DM option is obvious, only code for single scope, but bus decode and triggers could be used between different scopes, only tric is not at the same time.)

[abyrvalg]

I've just, ehm, found this link http://rghost.ru/download/57060583/0486bdb3f37075a5e1bb5ef3017f9218eb7c0e67/mdo3kgen.zip in a pastebin entry that had self-destructed on Ctrl-C 

[Carrington]

I've just, ehm, found this link http://rghost.ru/download/57060583/0486bdb3f37075a5e1bb5ef3017f9218eb7c0e67/mdo3kgen.zip in a pastebin entry that had self-destructed on Ctrl-C 

Woow nice discovery! 

[TiN]

I wonder if similar exists for older TDS7000 series or DPO7xxxx

[kilohercas]

And it works

[Le_Bassiste]

And it works 

hmmm...
1) your 1st pic says that  the eval period will expire on aug, 20th. wonder whether  the *options* will survive that date. more so, because these options require a hardware dongle to work. or, did you manage to key in the license numbers instead of using the dongles?

2) the 2nd pic shows all *upgrades* are enabled, which seems plausible. did you manage to check the MSO upgrade for functionality? is it by any means useful without having the dedicated logic probe? or did you buy the probe?


cheers!

[mikeselectricstuff]

And it works 

hmmm...
1) your 1st pic says that  the eval period will expire on aug, 20th. wonder whether  the *options* will survive that date. more so, because these options require a hardware dongle to work. or, did you manage to key in the license numbers instead of using the dongles?

Is that maybe just showing that any options with a "!" next to them are temporary?

[Le_Bassiste]

yes, the exclamation mark at the bottom is meant to be an explanantion for exclamation marks that may exist at the beginning of the lines in the options list (at least so on MSO20xx scopes). i wouldn't take the absence of the exclamation marks as a proof of the hack to work properly, though.

[kilohercas]

Since scope is new, out of the box, it has trial period for all modules. It will show exclamation mark to modules that are not installed, but enabled by trial mode. Since i hacked all of them, it still shows that i have some trial time left, but all modules already enabled, so it can't show exclamation mark



Just example from some forum, exclamation mark is showing not installed, but active trial decode options

For MSO,you can make cable yourself, is similar to PCI connector, and it use 16 micro coax cables to end probes, so you could solder just some wires, it will work, since only one bit of resolution.

[Le_Bassiste]

thx for clarifying kilohercas, especially on the logic probe connector.

[EEVblog]

I've just, ehm, found this link http://rghost.ru/download/57060583/0486bdb3f37075a5e1bb5ef3017f9218eb7c0e67/mdo3kgen.zip in a pastebin entry that had self-destructed on Ctrl-C 

Access to the file is restricted: copyright violation.

That was quick?

[tinhead]

copyright violation? the keygenerator has been NOT developed by Tektronix, so how can they claim that?

The AES key and option keys/values are in clear text visible, there is no need to "reverse" anything, therefore nothing
what one could "protect with anti-reverse copyright" whatsoever crap.

It is funny that Tektronix is veeeeery slow when goes to GPL violation or GPL source publishing, but that fast to claim
copyright on code that they haven't developed. There are keygen sources inside, not a single line belongs to Tektronix.

[HAMERMAN409]

From readme2.txt in the src.zip file:
Use validate.exe to extract options lists from option keys you have
Example: validate.exe 9R66P-69MNQ-7EPRD-PHSQ6-W9DDY-B

Not fully understanding this - seems like "validate.exe" and "gen.exe" are tools you would run on a PC. How would "validate.exe" be able to get data from option keys? Is this assuming the scope is connected to the PC?

[es]

You need to have Python installed on your PC.

Skip the validate.py step, it's unnecessary.

On your PC, use gen.py with, as arguments, your scope model and serial number along with the wanted bandwidth and options.

python gen.py <model> <serial> <bandwidth> <options>

[tmbinc]

Oh, so they finally switched to the AES version now? They've been using their custom "SSC" crapto up until recently.

But - since when did the eevblog forum became a keygen exchange platform?

I think it's one thing to hack around crippled hardware and restore functionality that's existing in hardware, but I distinctively feel that distributing tools that are enabling software features that usually sell for $$$ is not ... right. This may not be a popular opinion, I apologize.

This is not an issue of copyright. It's a matter of publicly supporting and encouraging the usage of unlicensed software. For me that crosses an (admittedly fuzzy) line.

[tinhead]

But - since when did the eevblog forum became a keygen exchange platform?

it's not and it will never be. The attached python script is example script of how something can be evaluated,
it does not use any Tektronix code or what so ever. It does not have keygen look&feel, etc. When i publish
a security hole somewhere, and validation script, then that didn't means that i posted trojan horse, here is similar.

This is not an issue of copyright.

right

It's a matter of publicly supporting and encouraging the usage of unlicensed software.

i think Dave mentioned many times how he think about crippled functions, this is not that the python script will
enable "Tektronix serial decoding module" on an e.g. Lecroy (that would be unlicensed), it will only enable what
already on my Tektronix and what i already paid for.

[tmbinc]

Ah, you paid for the serial decoding feature?

Nevermind then. I thought this script enabled features which were not initially enabled (i.e. you didn't pay for). My bad.