| Products > Test Equipment |
| Sniffing the Rigol's internal I2C bus |
| << < (803/899) > >> |
| smgvbest:
I'm still looking for dumps of a hacked 815 running the latest firware so I can compare to a unhacked 815 and would love a dump of a 832 if someone is willing to provide one. I'm not the best at this but been trying. |
| Asmyldof:
@smgvbest : Not exactly your request, but would a dump of another unhacked "new" DSA815-TG help? Been too busy still to actually open it up (and read all of the first pages to get "a hang"), but willing to let it jump the queue if it helps you at all. |
| longview:
I did an FRAM dump on my DSA815 (latest hardware, unhacked) using SCPI :SYST:FRE? 3145728,1048576 (the lower 3 MB seemed generally uninteresting). My hope was to see if the FWrite command could be used to reset the license status of the trials, but I can't see any of the data changing even between reboots so that's probably a non starter. There was a string repeated two times in the dump in the form of SECRET<14 digit key>. I tried searching for it in the thread but doesn't look like it's been posted before or anywhere online. It's certainly the right length to be a public key, and rigup 0.2 spits out a private key when I feed that into it (not the one used on previous FWs), but the license keys don't work (not entirely unexpected). Being way out of my depth here, I can't say what this is, could be a red herring or a joke left for us by the developers. Any thoughts? |
| Asmyldof:
In my experience with the kind of design or development Rigol uses, I don't think it's a red herring or a joke. I've run across companies with similar tactics and the more general thing to do is change request codes, public keys and their location. So you may well have found half the puzzle, now only need to find the new request codes to apply? Anyway, I have only used the DSA815-TG I have for a few hours to test it, as the project I needed it for got cancelled/postponed (still not clear on which), I could do an FRAM dump this weekend to compare, see if you can divine some meaning from differences. I might be willing to make some time to read up on the relevant threads and join in, but that depends a bit on the result of a customer visit today. I'm even willing to work through Git for anything that can be "scrubbed" of my device's ID and just have it all out on Github in some account or another, let other people follow the steps and results. |
| longview:
Yeah, it would be silly not to pursue the secret. They have probably changed the request codes too, if they've changed the way the cipher is implemented then it becomes more difficult. Some other possible avenues: It seems to be possible to write ASCII text to arbitrary FRAM locations using SCPI commands, but probably not binary values. The license key storage is duplicated in the FRAM, possibly for fault finding or anti-tamper, but depending on how often the checking is done it might be possible to overwrite both stores over SCPI. Assuming the key turns out to be difficult to crack, we know the firmware will keep options already installed using old keys, it could be possible to overwrite the key stores with license information generated from old option keys. Resetting the countdown timer could potentially be quite simple if I can work out where that information is stored in the FRAM. I think the easiest way to work out new option codes is by brute force, the keyspace isn't massive (less than 2 million combinations) and if we can work out the option codes for the trial keys already installed then the full versions should be pretty close (usually at least). Only issue with that is I don't know how to convert the keys I can read on the screen or see in the FRAM into the format used to activate the option. E: some more information, could be useful: Installing and reading installed license keys can be done with these commands: :SYSTem:LKEY? <int between 1-5, 3 is probably 10 Hz RBW and returns nothing for me) My system has two keys installed for EMI and AMK, for those numbers the return is two keys with a 0x0A between :SYSTem:LKEY <key with no spaces> seems to install keys, returns nothing but shows a message on screen if it's wrong The keys seem to be stored in order of entry in the FRAM, presumably the license type is contained in the key or in one of the bytes before or after they key in RAM. |
| Navigation |
| Message Index |
| Next page |
| Previous page |