Beta Offline decryption utility

[EEPhil]

If there are example encrypted and decrypted versions of the same file available it should be possible to see if they have used the same approach at least. i.e. only encrypt part of each packet.

I can’t speak for other people or the FOXSAT, but I know when I was looking into providing an offline program for the FOX boxes, your observation is correct. (With thanks to af123 for providing the files). I’m surprised that it hasn’t been done for the FOXSAT. If prpr is suggesting that there is no known way of saving a decrypted file from a FOXSAT then this would be impossible.
Having said that, I can obtain encrypted and decrypted files for the 5000T and I’m non the wiser!

 

[prpr]

If prpr is suggesting that there is no known way of saving a decrypted file from a FOXSAT

Perhaps there is now I think about it. I guess you can export (SD) to USB and it decrypts it? I'm not very familiar with the actual standard operation of these boxes.

 

[CharlesW]

I don't think it's necessary to have entire encrypted/decrypted versions of the same file. Looking at an encrypted file with a Hex editor, I see the same sequences of 8 bytes repeated many times - e.g. Ü-C#F¿ÁqÜ-C#F¿ÁqÜ-C#F¿ÁqÜ-C#F¿Áq. This can only come from FFFFFFFF... or similar (perhaps 04040404 etc.) in the original, and it is only necessary to focus on those 8 bytes. My key can be found above.

I'll keep digging!

Am I correct in thinking that when the key entered into the python fromhex function is 16 bytes, keying option 2 is used, and when 24 bytes, keying option 3 is used?

 

[CharlesW]

Towards the end of two unrelated .ts files (one encrypted, the other not) I get the sequences as shown in the attached files. It is therefore highly probable that
FF FF FF FF FF FF FF FF maps to C3 47 BA 87 C4 23 CE DB using some variant of MAC address:- dc-d3-21-3c-c7-d2 & s/n:- 637105084007084.

 

[MartinLiddle]

Perhaps there is now I think about it. I guess you can export (SD) to USB and it decrypts it?

I don't think SD is encrypted on the FOXSAT.

 

[/df]

Thanks. It was the 'bytes.fromhex' vs 'bytearray.fromhex' issue that I was puzzled by. It works with the former, but throws an error for the latter.
...

bytes.fromhex() doesn't exist in Py2, so it must be Py3.

Is the Crypto.Cipher module on the system from PyCrypto rather than the newer PyCryptodome? It seems that the former expects a bytes (== str in Py2) rather than a bytearray object to be passed as the key.

 

[CharlesW]

Is the Crypto.Cipher module on the system from PyCrypto rather than the newer PyCryptodome? It seems that the former expects a bytes (== str in Py2) rather than a bytearray object to be passed as the key.

I hope we are not moving off-topic here, but I have done

sudo apt-get remove python-crypto

followed by

pip install pycryptodome

but still get

Traceback (most recent call last):
  File "./decrypt.py", line 9, in <module>
    des = DES3.new(key,DES3.MODE_ECB)
  File "/usr/lib/python3/dist-packages/Crypto/Cipher/DES3.py", line 113, in new
    return DES3Cipher(key, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/Crypto/Cipher/DES3.py", line 76, in __init__
    blockalgo.BlockAlgo.__init__(self, _DES3, key, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/Crypto/Cipher/blockalgo.py", line 141, in __init__
    self._cipher = factory.new(key, *args, **kwargs)
TypeError: argument 1 must be read-only bytes-like object, not bytearray

after changing to

key = bytearray.fromhex("dcd3213cc7d236333731303530383430")

Changing back to

key = bytes.fromhex("dcd3213cc7d236333731303530383430")

works.

 

[/df]

The DES3 that's running is in dist-packages. I don't think that would have come from pip. But PyCryptodome seems only to be in PPAs.

 

[CharlesW]

An update on my post of the 22nd October...

The FOXSAT-HDR appears to have the libcrypt, not the libgcrypt libraries (libcrypt-0.9.28.so) installed. Am I correct in thinking that this allows DES (but not DES3) encryption? This means the key is 8 bytes long giving "only" 2^56 possibilities (the last bit of each byte is gnored). I have tried various keys involving the MAC address, but to no avail. It is possible that the key involves the motherboard serial number. I'm not sure how to find that, since busybox only offers a limited set of linux commands.

 

[Black Hole]

It is possible that the key involves the motherboard serial number. I'm not sure how to find that, since busybox only offers a limited set of linux commands.

I think I am correct in saying, and I hope I'm not giving away any confidences, that the HDR-FOX key derivation was cracked by hardware inspection and probing (JTAG). Foxsat might be amenable to the same approach, but it seems likely that any more recent models have had that back door closed.

 

[CharlesW]

My FOXSAT-HDR is now ten years old. Are you saying that nobody is really interested in cracking older models, because there are not so many of them around? I think I am at the stage of "hardware inspection", but finding that difficult. You have already replied to my other post about opkg, so you can see what I am trying to do!

 

[CharlesW]

My real concern, which started all this off is that my old FOXSAT will not last forever, and I'm looking at ways to recover HD recordings saved to my NAS pre-Nowster.

 

[Black Hole]

Are you saying that nobody is really interested in cracking older models, because there are not so many of them around?

It requires a convergence of:

• Knowledge;
• Skill;
• Equipment (test gear and test subject);
• Motivation;
• Tuit.

When all these align, much can be achieved... but I can only tick some of those boxes. What's more, when they do align it might only be temporarily. Further: with a declining population of the specific models in question, the pool from which the necessary contributions might be obtained is also declining.

 

[prpr]

I'm looking at ways to recover HD recordings saved to my NAS pre-Nowster

You are probably better off looking at HDMI to USB capture devices. e.g. stuff made by the likes of Lindy or Atomos, and then for more pro. use there are devices from AJA, Startech, Osprey, Blackmagic etc.

 

[CharlesW]

Yes, I've thought of that if all else fails - connect the hdmi output from the FOXSAT to my laptop. I think windows already comes with a generic video capture utility for recording games.

 

[Ezra Pound]

Generally speaking the HDMI connector on a laptop will only output video / audio, it isn't an input as well

 

[CharlesW]

You can get HDMI to USB converter cables.

 

[Black Hole]

You are probably better off looking at HDMI to USB capture devices. e.g. stuff made by the likes of Lindy or Atomos, and then for more pro. use there are devices from AJA, Startech, Osprey, Blackmagic etc.

There is a potential "gotcha" with that approach. I have no knowledge of Foxsat other than my readings on this forum, but taking HDR-FOX as a prototype: the HDMI output is protected by HDCP*, regardless of whether the source is HiDef or StDef.

A HDMI grabber could not (legitimately) negotiate HDCP. The primary market for HDMI video grabbers is for capturing original content (eg games play, software use demos), not pirating Blu-rays and broadcast TV.

* Glossary: HDCP (click)

 

[CharlesW]

So, it's back to the sledgehammer! Assuming it's DES (not DES3 - see above), and assuming the key is some sort of 8 character serial number, I am cranking through all possible combinations of integer and upper-case letter (plus ':' and '-'). This is made 'easier' by the fact that only seven bits of each byte are used. There are 20^8 combinations and 99 hours to go!

I may have an HDMI to USB cable kicking about somewhere, so should be easy to check if HDCP is an issue.

 

[Black Hole]

HDMI to USB cable

I presume you mean a grabber box with an HDMI input at one end and a USB connection at the other. A passive cable won't do anything (and believe me: I have come across cables supposed to be adapters for interfaces which would be electrically incompatible!).

Spoiler: Data Bandwidth Required For HDMI Video Grabbing

Even setting a low bar of 576i (8-bit RGB 1024x576@25fps), and ignoring the audio, that's 3x8x1024x576x25 = 354Mbps... just about within USB2 capability, but it also has to be sustained and not just in bursts so it would impose a huge overhead on the host computer. A video grabber worth its salt is (hopefully) running some real-time video encoding in hardware to produce a .mp4 (or something).

Even without video encoding, the three serial data channels of HDMI have to be multiplexed into the single serial data channel of USB, so there will always be some electronics in the mix (not just wires).

Assuming it's DES

With no specific knowledge, I hope this isn't a red herring. I can't see why there should be software libraries installed to handle the encryption/decryption when the cryptosystem is implemented in the video routing hardware (as it has to be to handle the bandwidth).