How to copy from hard disk (in HDR-2000T) to an mp4 file on my PC

[JohnAaronRose]

My HDR-2000T has gone totally dead and I've taken the hard disk out and connected it to my PC using a HD Enclosure & copied the file (.ts etc) from the hard disk to my PC's SSD. However, my PC cannot play the .ts files let alone convert them to .mp4 files. Someone on another forum suggested that this is due to then being Blue Ray & therefore encrypted. Any ideas as to how to play them and/or convert them to .mp4?

 

[Black Hole]

Any ideas as to how to play them and/or convert them to .mp4?

You can't. The recordings are encrypted on disk (nothing to do with Blu-ray), and the only device with the correct algorithm and key is the original HDR-2000T. Had you taken action while the unit was still alive, you could have done something to export the recordings... but not now.

We know the algorithm and how to derive the key for HDR-FOX and HD-FOX, but not for any other unit.

 

[EEPhil]

Any ideas as to how to play them and/or convert them to .mp4?

We know the algorithm and how to derive the key for HDR-FOX and HD-FOX, but not for any other unit.

Quite a while ago I looked into this but no combination of the known key parts worked. We know for the FOX the decryption key is a combination of the device serial number and the MAC number. I tried brute force using various combinations of s/n and MAC but after a while I gave up! Unless someone finds how the decryption key is derived for any other Humax box we’re stuffed!

 

[Black Hole]

Unless someone finds how the decryption key is derived for any other Humax box we’re stuffed!

I believe this was cracked for the HDR-FOX using an open back door in the hardware (manufacturing test port). I wouldn't be surprised if that loop hole has been closed in more recent models, but if anybody has a 2000T (or whatever) and is into JTAG boundary scan... just saying, like.

 

[JohnAaronRose]

Thanks, EEPhil & Black Hole, for info. it looks like I'm stuffed.

 

[EEPhil]

but if anybody has a 2000T (or whatever) and is into JTAG boundary scan... just saying, like.

I have the 2000T but have no idea about JTAG boundary scans - so it won't be me.

 

[Black Hole]

I tried brute force using various combinations of s/n and MAC but after a while I gave up!

That presumed the encryption routine is the same. If it isn't, no amount of brute force would crack it.

Do you have a sample of cyphertext complete with the corresponding plaintext? Quantum computing here we come!

 

[EEPhil]

Do you have a sample of cyphertext complete with the corresponding plaintext? Quantum computing here we come!

It would be easy enough to obtain. But we’ve been down this path before.
I think we looked at the encryption routine and it did seem to be the same.

 

[Black Hole]

I think we looked at the encryption routine and it did seem to be the same.

I'm not sure how one would be able to tell. It might be just the video/audio payload that is encrypted, but short of that it will appear a random scramble of bits whichever form of block cypher is used.

 

[EEPhil]

I'm not sure how one would be able to tell. It might be just the video/audio payload that is encrypted, but short of that it will appear a random scramble of bits whichever form of block cypher is used.

I can't remember now. It's probably four years or more since I looked at this. I seem to remember af123 gave a lot of guidance. There was something about the parts of packets that don't get encrypted and how blocks of 0xff are treated. Beyond that I forget. I'm unlikely to revisit this unless I get some devine inspiration!

The moral of this is to ensure you decrypt anything you want to keep, in advance, using the available techniques, just in case. Of course, I don't practise what I preach!

 

[af123]

I can't remember now. It's probably four years or more since I looked at this. I seem to remember af123 gave a lot of guidance. There was something about the parts of packets that don't get encrypted and how blocks of 0xff are treated. Beyond that I forget. I'm unlikely to revisit this unless I get some devine inspiration!

That's basically the size of it, one can check an encryption key by finding a PAT (programme allocation table) payload start packet and decrypting the block that includes byte 17, which should end up as 0 if the key is right. It is not foolproof but it's a fairly quick way of finding potential keys.

 

[Black Hole]

Sure, but what about the encryption algorithm itself? You have a block of cyphertext and a presumed block cypher algorithm, and can throw keys at it with a 1-in-256 chance of it decrypting byte 17 as "00"... but if the block cypher is the wrong one there is no chance that the decryption will be successful.

For example: the data sheet for the Broadcom BCM7405 (as used in the HDR-FOX) says this:

For copy protection, we support a memory to memory DMA subsystem that can scramble or descramble data. The Mem-to- Mem Security module performs the scrambling/descrambling function of that subsystem. The Mem-to-Mem DMA portion of the subsystem resides outside data transport. This module also supports Transport packet parsing function, so only payload data is scrambled/descrambled.

The Mem-to-Mem Security module may be programmed to perform the following functions:

• ECB mode scrambling/descrambling with 3DES core in ABA or ABC modes (64 bits data, 128/192 bits key).
• CBC mode scrambling/descrambling with 3DES core in ABA or ABC modes (64 bits data, 128/192 bits key).
• ECB mode scrambling/descrambling with DES core (64 bits data, 64 bits key).
• CBC mode scrambling/descrambling with DES core (64 bits data, 64 bits key).
• ECB mode scrambling/descrambling with AES core (128 bits data, 128/192 bits key).
• Counter mode scrambling/descrambling with AES core (128 bits data, 128 bits key).
• ECB mode scrambling/descrambling with C2 core (64 bits data, K bits key).
• C-CBC mode scrambling/descrambling with C2 core (N x 64 bits data, K bits key).
• Sector mode data descramble with CSS core (2048 x 8 bits data, K bit key).
• CBC mode scrambling/descrambling with AES core as defined by AACS and DTCP (128 bit data, 128 bit key).
• Supports 96 x 64 bit key table. Each key set requires one 64 bit mode word. Cores that use longer key length will use multiple keys.
• M6 scrambler/descrambler for DTCP.

...so there's a fair selection of options, and do we know it's the 7504 in the 2000T?

 

[EEPhil]

so there's a fair selection of options, and do we know it's the 7504 in the 2000T?

I don’t.
I’m not sure about your other comments either. (That means I’m not sure, not that you are definitely wrong!) Looks like I need to find the other thread and re-read it plus find my workings if I want to make any useful comments. Don’t hold your breath!

 

[Black Hole]

Looks like I need to find the other thread and re-read it plus find my workings if I want to make any useful comments.

I'm pretty sure there will have been an assumption that the encryption method is the same as for HDR-FOX (triple-DES, IIRC), because the software to decrypt HDR-FOX recordings (embodying the understanding of the payload etc) was made available. All I am saying is that the assumption might not be valid, for example Humax might have switched to AES in CBC mode, which the BCM7504 hardware would make it very easy to do.

Without a back-door examination (oo-er missus!) it will be very hard to confirm one way or the other, and even that could have been closed off by switching on the JTAG security system.

 

[EEPhil]

triple-DES,

Oh no! Not three of our local weather presenters. (Meaningless to anyone who can’t watch ITV Central)

That does sound like the beast - in the Fox case the first and last 8 bytes are the same. I think I tried ignoring this restriction and tried various combinations of s/n and MACs across the full 24 bytes - and got precisely nowhere. We don’t know whether the key is constructed in a similar way or whether The encryption type is the same. To misquote Manuel: “We know nothing”.