MontysEvilTwin
Well-Known Member
If your results are correct, the improvement is about 15.5%.
Beta Offline decryption utility
- Thread starter af123
- Start date
EEPhil
Number 28
I think so.
As af123 pointed out 4c4d65d47880c8ef should decrypt to ffffffffffffffff - as can be deduced from the nature of the encryption. There is another repeating pattern from my 2000T and that is a052871b5dce41a2 should decrypt to 0000000000000000 (8 zero bytes). So the simplest test is to decrypt to 8* (0xff) and check if the same key decrypts the other 8 bytes to 8* (0x00). If it does I'd be reasonably confident the key had been found.
EEPhil
Number 28
I have a copy of the dehumidified file structure for the latest 2000T upgrade and have tried poking around in there looking for clues. Not convinced I'm looking in the right place. Of course, not being an expert in the firmware and with no obvious way to do a memory dump, I'm probably widdling in the wind.
OP
stripts 1.4.3 now in the beta repository - somewhere between 6 and 15% faster than the last version!
Will do.
Will do.
Code:
humax# stripts -/ 11111111111111111111111111111111 test/Bargain\ Hunt_20180502_1218
Encryption key is INCORRECT for this recording.
Black Hole
May contain traces of nut
On what basis do you refute my mathematical analysis in post 147? Your assertion has reasonable confidence if the key length is 16 bytes (112 effective bits) but not if it is 24 bytes.
Last edited:
MontysEvilTwin
Well-Known Member
Now that @af123 has figured out encryption works on the HDR-FOX, there is a method to read the key from the internal memory, but I do not know if this is possible without custom firmware.
I have another idea which may or may not be helpful. If you make a brief recording from a high def. channel and copy it over encrypted, then Foxy the hmt file and copy again onto USB to decrypt, won't this give you both samples of cyphertext and the corresponding plaintext?
Black Hole
May contain traces of nut
Obtaining both cyphertext and plaintext is not the problem. The problem is figuring out the key. We (as in af123) have access to the internals of the HDR-FOX that are not afforded to 2000T owners, and observation of the key in HDR-FOX memory revealed the scheme used to derive it from system parameters. The same scheme does not appear to be used for the key in the 2000T. If we were able to examine a few keys for 2000T, we might be able to work out the general scheme for their derivation (although I fear it might be a hashing algorithm, which would obscure the pattern).
af123 believes having a 64-bit sample of the cyphertext and plaintext is sufficient to determine the key by brute force, but I don't agree (see post 147). I believe we need a significant sample of cyphertext and the equivalent plaintext to be able to brute force it (but I'm not making any definite offers). EEPhil has provided another 64-bit sample, which should be sufficient if the key is 112 effective bits, but I don't see why a substantial sample can't be made available for us all to look at - where's the harm?
Update:
af123 believes having a 64-bit sample of the cyphertext and plaintext is sufficient to determine the key by brute force, but I don't agree (see post 147). I believe we need a significant sample of cyphertext and the equivalent plaintext to be able to brute force it (but I'm not making any definite offers). EEPhil has provided another 64-bit sample, which should be sufficient if the key is 112 effective bits, but I don't see why a substantial sample can't be made available for us all to look at - where's the harm?
Update:
Last edited:
Black Hole
May contain traces of nut
...but further research indicates cracking 3DES (when we have no knowledge of how the key is derived so as to be able to reduce the list of candidates) is impractical.
For those interested in the details, in summary:
DES can be cracked (ie the key extracted), if you have a sample of the cyphertext and corresponding plaintext, by building a mega lookup table listing the encryption of the plaintext for every possible key, and then just looking for the one that matches (or a table of every possible decryption of the cyphertext). This table has 2^56 entries, so it's huge and takes a lot of processing to populate, but it is technically feasible to do and the reason DES is now regarded as insecure.
2DES (applying DES using K1 then /DES using K2) would be susceptible to a "meet in the middle" attack: build two of the above tables, one for encryptions of the sample plaintext for all possible K1 and the other for encryptions of the sample cyphertext for all possible K2, and look for a match between the entries in the two tables (the sample plaintext/cyphertext has to be significantly longer than the key, otherwise there could be lots of false matches). This therefore requires memory capacity for two 2^56-entry tables, and processing time to populate them and compare them, but again technically feasible.
However, 2-key 3DES (applying DES using K1, then /DES using K2, then DES using K1) is a clever means to defend against meet-in-the-middle without increasing the overall number of key bits. To build a pair of tables for comparison, the encryption algorithm needs to be split into two parts - one part working forward from the plaintext and the other part working back from the cyphertext. There are three operations in 3DES, so the only way to split it is into one part with one operation and the other part with two operations. That means either DES-K1 + (/DES-K2 + DES-K1) or (DES-K1 + /DES-K2) + DES-K1. Either way, one of the parts has the full 112-bit key space to build a table for.
So instead of having two 2^56-entry tables, the meet-in-the-middle attack needs a 2^56-entry table and a 2^112-entry table. That requires 2^56 times more storage than the (already gigantic) 2^56-entry table, and processing time longer than the age of the universe to populate. If it were feasible, this structure would also crack 3-key 3DES.
Now I have a full appreciation of it, I can see how damned clever this is. I guess we will just have to wait for quantum computing to catch up.
For those interested in the details, in summary:
DES can be cracked (ie the key extracted), if you have a sample of the cyphertext and corresponding plaintext, by building a mega lookup table listing the encryption of the plaintext for every possible key, and then just looking for the one that matches (or a table of every possible decryption of the cyphertext). This table has 2^56 entries, so it's huge and takes a lot of processing to populate, but it is technically feasible to do and the reason DES is now regarded as insecure.
2DES (applying DES using K1 then /DES using K2) would be susceptible to a "meet in the middle" attack: build two of the above tables, one for encryptions of the sample plaintext for all possible K1 and the other for encryptions of the sample cyphertext for all possible K2, and look for a match between the entries in the two tables (the sample plaintext/cyphertext has to be significantly longer than the key, otherwise there could be lots of false matches). This therefore requires memory capacity for two 2^56-entry tables, and processing time to populate them and compare them, but again technically feasible.
However, 2-key 3DES (applying DES using K1, then /DES using K2, then DES using K1) is a clever means to defend against meet-in-the-middle without increasing the overall number of key bits. To build a pair of tables for comparison, the encryption algorithm needs to be split into two parts - one part working forward from the plaintext and the other part working back from the cyphertext. There are three operations in 3DES, so the only way to split it is into one part with one operation and the other part with two operations. That means either DES-K1 + (/DES-K2 + DES-K1) or (DES-K1 + /DES-K2) + DES-K1. Either way, one of the parts has the full 112-bit key space to build a table for.
So instead of having two 2^56-entry tables, the meet-in-the-middle attack needs a 2^56-entry table and a 2^112-entry table. That requires 2^56 times more storage than the (already gigantic) 2^56-entry table, and processing time longer than the age of the universe to populate. If it were feasible, this structure would also crack 3-key 3DES.
Now I have a full appreciation of it, I can see how damned clever this is. I guess we will just have to wait for quantum computing to catch up.
Last edited:
OP
No, you are conflating two of my statements there. I have said that the 64-bit crib is enough to determine whether a key is right and, as you pointed out, I am wrong there - it would only provide a candidate key. I also said that we should be able to brute force the key for a HD/HDR since the key space is much reduced due to the use of digits only in the last 10 places (and only even digits at that due to the parity) and the predictable first three bytes (there are 3 options for MAC address prefix on an HDR and 2 for an HD).. it would still take a while but in the order of days making it practical. That does not make it practical to brute force an arbitrary key.
EEPhil
Number 28
How is this any different from doing the same with a StdDef recording - which is what I have been working with? I ftp'd a StdDef .ts file (encrypted) and streamed the same file (decrypted) and compared the results. af123 has taken an encrypted 2000T recording and deduced (correctly) that a known repeating set of bytes decrypts to 8* (0xff).
I think "refute" and "assertion" are a bit strong.
I did prefix it by "I think so" - which doesn't really lend itself to certainty.
Black Hole
May contain traces of nut
EEPhil
Number 28
Post #171 and what came before having been said - there is still the practical problem of attempting to discover the (whatever size) key for the 2000T.
Poking around in the 2000T update uncovered a couple of oddities - a reference to a MAC address of 00:90:4c:03:21:23 which, I assume, is hard-coded into every updated 2000T; and a reference to a get_secure_serialnumber function. Is that securely get the serial number or get a secure serial number - which isn't the serial number displayed on the back of the device?
Poking around in the 2000T update uncovered a couple of oddities - a reference to a MAC address of 00:90:4c:03:21:23 which, I assume, is hard-coded into every updated 2000T; and a reference to a get_secure_serialnumber function. Is that securely get the serial number or get a secure serial number - which isn't the serial number displayed on the back of the device?
EEPhil
Number 28
I missed this bit. If you think it's worth the effort I can try and put together a small sample of encrypted/decrypted files. (Probably very small, I'm not sure what the upload limit is on here).
Black Hole
May contain traces of nut
No point (as per post 168), and I missed this bit:
I fancy this is a crypto-hash function.a reference to a get_secure_serialnumber function. Is that securely get the serial number or get a secure serial number - which isn't the serial number displayed on the back of the device?
Black Hole
May contain traces of nut
OP
Given the broadcom API, I'm pretty sure it will be 112-bits like the HD/HDR.. the relevant function is NEXUSSecurityLoadClearKey() and it takes a 128-bit argument which can then either be used for AES-128 or 2-key 3DES. There's always a chance that the API has been extended but the Broadcom documentation is not available.
The code is not encrypted? Oh, I'll have a quick look then..
Last edited:
Black Hole
May contain traces of nut
For anyone labouring under the idea they only have Windows and can't run the Linux version of stripts: just boot a Live Linux CD/DVD/USB (it doesn't hurt your PC, and is handy to have around). Here's one for downloading and burning from ISO, or a few quid will get one on the cover of a Linux magazine from a news stand:
https://tutorials.ubuntu.com/tutorial/try-ubuntu-before-you-install
Once you've done what you want, just eject the CD/DVD/USB and reboot - Windows then restarts as normal. (I prefer not to have the system set to boot from USB - it's easy to leave one in there and then have an inadvertent boot from something unauthorised. Less chance with optical.)
(BTW: I'm migrating away from Windows and anything I can only do in Windows will be run under Linux via WINE or a Windows VM. I haven't migrated very far yet though...)
Last edited:
OP
OP
That's in the web browser client code.. The browser provides some methods to the remote web server, one of which is get serial number so I assume this is related.. it seems to RSA encrypt the serial number with a local certificate.
OP
Using a private key that is common across all units, and a shared secret that's also common.. the 2000T code is so much easier to work with than the HDR!