• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

Custom Firmware on HDR-2000T

To add to my above message (#31). While we know that the 2000T won't serve HiDef content by DLNA, removing file protections (as the auto-unprotect package does on the HDR-FOX) may enable DLNA streaming by the same protocol as used for StDef programmes. If this is the case the automated decryption method should work. Anyway, until someone can open up the hood and start tinkering, we won't know for sure.

I can confirm the 2000T does serve up HiDef content via DLNA after Foxy is used to first update the associated HMT file and the recording is moved to another folder (no additional partition required). I know this because I have two 2000T's on my home network and I stream recordings from one to the other.
StDef always works without any changes required. For HiDef this is my quickest method of decrypting.
1. Create a folder called Decrypt on the 2000T that holds the HiDef recording you want to decrypt.
2. Using FTP client copy the associated HMT file to a PC.
3. Using Foxy process the HMT file.
4. Using FTP cilent copy the updated HMT file back to the 2000T and overwrite the original.
5. Using the 2000T remote select the HiDef recording and move it to the Decrypt folder (this happens immediately with no waiting required).
6. The recording in the Decrypt folder is now decrypted. Move it back to the original folder if you want. This recording will now stream to another 2000T (or other DLNA device) or copy it off to a USB drive to play elsewhere.

Hope this helps.

I also have a Synology NAS on my home network and happy to help with any testing (that won't brick my devices ;)).
 
I think your terminology is probably incorrect: the recording becomes unprotected, not unencrypted. Clearing the flag in the .hmt file normally only enables decrypt-on-copy-by-OPT+, there is another flag held in the DLNA database preventing HiDef recordings being served to non-HDCP devices (in the case of HDR-FOX; in the case of 2000T HiDef don't seem to make it to the DLNA index at all).

What you seem to be doing is clearing the flag in the .hmt file and then moving the recording so that the DLNA index gets updated - and the recording is treated as if it were StDef and gets indexed and made available for streaming. This opens the possibility of accessing it via a wget command (on another computer) and thus downloading a decrypted HiDef recording over the home network. This is an enhancement to the method I documented previously for non-CF users to download StDef recordings.

I think this would probably also work in the HDR-FOX - although it has never been spotted or reported. With CF at our disposal the DLNA database was simply tweaked to clear that flag too (the auto-unprotect utility).
 
@Culbin. This is very interesting. What happens if you use Foxy to unprotect the HMT file without moving the recording to another folder? Will it still play on another machine by DLNA or is the file not listed? If the recording needs to be moved to another folder (after using Foxy) to play (presumably as suggested by Black Hole to update the DLNA database) what happens if you use Foxy immediately after the recording has finished? The auto-unprotect package on the HDR-FOX is essentially instantaneous, removing the HMT flag etc. as soon as the recording is finished: DLNA indexing typically takes a few minutes. What I'm getting at is that when an update to the HDR-2000T is available and custom firmware has been created (from reading other posts, I think that af123 will be up for the challenge) a version of the auto-unprotect package may be sufficient to allow automatic decryption in the same way as is done on the HDR-FOX.
 
I tried this out on a HDR-FOX (with custom firmware). I removed the auto-unprotect package and recorded two hi def programmes. After DLNA indexing (green circular symbol present in Web-If) I used Foxy to remove the 'enc' flags. Then I moved one of the files to a different location. The moved file was decrypted by Web-If, the unmoved file was not decrypted. From the auto.log file, Web-If started the decryption process on the unmoved file but it did not succeed. After rebooting and moving this programme to a different folder, it was decrypted by Web-If after re-indexing by the DLNA server.
The HDR-FOX and the HDR-2000T seem to behave in a similar fashion with respect to DLNA, with one significant difference*. If the hi def files are indexed after 'Foxy' deprotection they are served by the DLNA server with on the fly decryption. *On the HDR-FOX, protected hi-def content is served as a protected stream to a client that can negotiate the DTCP-IP protocol, on the HDR-2000T, such content is not served at all. However, it seems likely that automatic decryption, as occurs on the HDR-FOX with custom firmware, would also work on the HDR-2000T, were custom firmware to become available, of course.
 
6. The recording in the Decrypt folder is now decrypted. Move it back to the original folder if you want. This recording will now stream to another 2000T (or other DLNA device) or copy it off to a USB drive to play elsewhere.
To be completely clear about this:

The recording (in the Decrypt folder) is not decrypted by this process. Clearing the ENC flag in the .hmt file using Foxy fools the HDR-FOX/1800T/2000T into treating the recording as if it were StDef - ie it will be decrypted if copied to another drive using the OPT+ button on the handset. Having moved the recording after clearing the ENC flag, the DLNA index entry is rebuilt as if the recording is StDef and the recording becomes available for streaming (HDR-1800T/2000T) or streaming without DTCP (HDR-FOX) - the streamed recording is decrypted on the fly, and a streamed recording can be captured bit-for-bit into a file.

Clearing the ENC flag makes the recording decryptable on copy, rebuilding the DLNA index entry (with the ENC flag cleared) makes the recording streamable. Neither operation results in a decrypted recording on the internal HDD.
 
Thanks to both of you for your patience, I'm fairly new to this.

What Black Hole stated in the last post seems true from the testing I've just done with my two machines.
Clearing the ENC flag in the .hmt file using Foxy tools makes absolutely no difference to the ability to stream that recording until the file is moved/copied. I even tried clearing the ENC flag immediately after a recording finished (hoping to catch it before the index updated) with the same result.
 
I'm sure I speak for the community by saying we are grateful for your input - even if it did need refining by those of us with more experience. As you may have noticed I have already built it into the standard references (with credit to you) and spread the word around.
 
V1.01.16 (filename hdr2000t_upgrade.hdf) available to download at humaxdigital.com

Software Details & Release Notes
- Application version : UKTFAC 1.01.16
- Loader version : UKTFAC 1.04
- System id : 80BC.7E10
- Update Date : 12 AUG 2015
- Micom version : 12.4

Can anyone look at that to see how it fits with custom software aspirations?
 
Nothing has changed. As far as I know, nobody has expended any effort in trying to defeat the security protection on the 1800/2000T firmware.
 
Just an additional observation on the Foxy thing. As has been mentioned, once the decrypt flag has been changed on the .hmt file, if the programme is moved to another folder using OPT+, it is reindexed and available on DLNA.

An alternative method of forcing reindexing (which I used with my Mac app) is to rename all four files, (hmt, ts, thm, nts) over FTP by adding a letter. All the programmes are then reindexed when the Humax restarts and are available on DLNA.
 
Back
Top