Black Hole
May contain traces of nut
Next project: demux the audio stream locally and download the MP2. Pretty Please.
Humax recording encryption
- Thread starter af123
- Start date
OP
Yes it will. It processes any DTCP protected entries in the database every time it runs. Slightly different mechanism to the enc flag removal.
OP
It does the right thing now although the downloaded file is called 123.TS or similar, something I might be able to fix. With auto unprotect you can download decrypted HD content too.
Black Hole
May contain traces of nut
Presumably that's the mediaID string? I can live with that!
Here's my breakdown the HMT format for anyone interested. It's not 100% complete and there may be errors. That said, feel free to use it as you wish.
Trevor Jasper
Member
The download button only does the correct thing if the DLNA server is running!
I also can't get this to work, however I have a HD and have to load the HDR elf, I've enabled the file sharing options in the menu but don't think the DLNA server is running. I've tried connecting to the T2 as a DLNA device in XMBC but it does not detect it. Does the DLNA server have its own process or is it part of humaxtv?
My current method to copy off is to load HDR elf, mount a Samba share (on my PC) and copy the recording on to this using the OPT menu, would be nice to get the above working to save going back and forth from TV to PC.
OP
I don't think it will work on the HD yet. The DNLA server is part of the humaxtv binary rather than being a separate process.
Just trying it out at the moment. Good work. I can now stream anything to VLC. I'm just testing the download button but some items I try give the following error:
Doesn't seem to be a pattern, I thought it was items with underscore in the folder name but I think I have ruled that out. Seems to work well as long as the download starts though!
Code:
Error 500: Internal Server Error
CGI program sent malformed HTTP headers: []Doesn't seem to be a pattern, I thought it was items with underscore in the folder name but I think I have ruled that out. Seems to work well as long as the download starts though!
Black Hole
May contain traces of nut
I don't recall seeing this mentioned before: as I understand it, people with HD-FOX can decrypt-copy if they boot to HDR-FOX code. That means the keys used to encrypt the recording by the HD, and decrypt it on playback, must be preserved when the HDR code is booted or even (in Drutt's case) flashed, and they must be in the same place for both HD and HDR.
I'm willing to contribute dumps from my HDR and (when I get around to it) my HD, and there is another HD I can scrounge info from.
I'm willing to contribute dumps from my HDR and (when I get around to it) my HD, and there is another HD I can scrounge info from.
Black Hole
May contain traces of nut
Thinking about it, the most likely location for the keys is buried in the Broadcomm chip. Is that where you've been looking?
David_Brown_UK
Member
This for me was ' in the folder or file name. af123 says he has fixed this in the latest version (0.64-1) of webif.
When I try to download 'T2 - HMT Format.txt' I get message 'This attachment cannot be shown at this time. Please try back later.' Is this me or the server?
Sam Widges
Active Member
I'd be surprised if 3DES was in use because that would result in a lot of encryption processing. It's much more likely that AES is being used as that was designed to use less processing power.
Black Hole
May contain traces of nut
Such "processing power" arguments are irrelevant because it's all done in specifically designed hardware. However, I agree triple-DES seems like a sledge-hammer. It will be whatever the rights holders have negotiated into the DRM agreements.
Fortunately "we" now have this licked (for the HDR-FOX) in the form of decrypt-in-place, which leverages the on-the-fly decryption ability of the DLNA server to provide our own decryption path through the crypto hardware. It's a shame the same isn't possible for HD-FOX users, who would still benefit from software decryption (although they can use HDR mode).
Fortunately "we" now have this licked (for the HDR-FOX) in the form of decrypt-in-place, which leverages the on-the-fly decryption ability of the DLNA server to provide our own decryption path through the crypto hardware. It's a shame the same isn't possible for HD-FOX users, who would still benefit from software decryption (although they can use HDR mode).
Sam Widges
Active Member
It was great to solve the decryption issue through the crafty use of database manipulation, DLNA and wget, but I have a nagging worry that this is something that Humax might want to lock down at a later date. I'd still love to find out how to do the decryption the 'proper' way.
ChrisDaniels
Well-Known Member
Or indeed turn it off 