• The forum software that supports hummy.tv will be upgraded to XenForo 2.3 on Wednesday the 20th of November 2024 starting at 7pm

    There will be some periods where the forum is unavailable, please bear with us. More details can be found in the upgrade thread.

Beta Offline decryption utility

af123 said:
If you can transfer a recording from the 2000 to a separate machine which can run the utility, it's just a case of getting the serial number and mac address to derive the encryption key, then running the utility on the file, and seeing if you can play it on the separate machine afterwards.
Click to expand...
No such luck. I can transfer to a Windows machine, and you haven't got a utility for that. That was the reason for asking about the method - I might have been able to bodge something to try and decode it myself. But now you have mentioned 2 keys and only described one, I can't see me being able to knock up a test.:confused:
 
You're welcome. You could be 'The Other Dumb One':roflmao:

I'm 'The Other Tired Old Man' on another forum that I frequent.
 
EEPhil said:
But now you have mentioned 2 keys and only described one, I can't see me being able to knock up a test.:confused:
Click to expand...
Look at https://en.wikipedia.org/wiki/Triple_DES#Keying_options - keying option 2.
The relevant 56 bits of the first 8 bytes are K1, the second 8 bytes provide K2.

EEPhil said:
No such luck. I can transfer to a Windows machine, and you haven't got a utility for that.
Click to expand...
I might be able to build a windows version given time but in the meantime, would you be willing to provide a small test recording for me to have a go at?

It's worth mentioning that these keys should be eminently brute-forceable. There are two MAC address prefixes we know of leaving 24 bits unknown there and the serial numbers, at least for the HDR Fox T2s that I have, don't have a lot of variation in the first 10 digits.
 
af123 said:
It's worth mentioning that these keys should be eminently brute-forceable.
Click to expand...
Security has never really been the issue but the requirements imposed on PVR suppliers by the broadcasters.
We have been getting around the encryption without knowing the keys for years so it has never been a security success.
 
It seems to me that the primary normal use-case for this facility (apart from rescuing undecrypted recordings from a dead HDR-FOX) is the HD-FOX. I never managed to make BootHDR work (not that I tried very hard), and this is a means to decrypt on the HD-FOX without having to boot into a different mode and back again.

I made a short test recording (1m29s), then used the stripts -@@ method via webshell, and it completed in 32.33 seconds. The original file was 23.5MB.

I now have a second copy of the recording on the drive, and both copies play on the HD-FOX... but what's more, moving the drive to a HDR-FOX plays the decrypted version, and so does VLC on the PC.

My guide to decryption is now in need of a major revision!

I think it would be very useful, particularly for HD-FOX users, to add non-DLNA decryption to the WebIF media browser file options.

In the absence of a means to disable encryption, this also provides a route to decryption when the HDR-FOX is not connected to a network (or a loop-back stub), or when the DLNA server is turned off.

I also think this may be a better front-end mechanism for detect-ads, or even a general purpose near-real-time decryption.
 
Last edited:
Black Hole said:
It seems to me that the primary normal use-case for this facility (apart from rescuing undecrypted recordings from a dead HDR-FOX) is the HD-FOX.
Click to expand...
I wonder why I didn't think of that... I took a different approach of setting the encryption key on my HD to the same as my main HDR, then I can just rsync the recordings across and watch them on the HDR (or decrypt them there if I want).

Black Hole said:
I think it would be very useful, particularly for HD-FOX users, to add non-DLNA decryption to the WebIF media browser file options.
Click to expand...
Yes, good idea. The hardware accelerated DLNA method is probably always going to be preferable if available - I'll have to think about how to present the option.

Black Hole said:
I made a short test recording (1m29s), then used the stripts -@@ method via webshell, and it completed in 32.33 seconds. The original file was 23.5MB.
Click to expand...

Thanks, that's something I hadn't tried.. much easier than BootHDR.
 
Black Hole said:
I also think this may be a better front-end mechanism for detect-ads, or even a general purpose near-real-time decryption.
Click to expand...
It could conceivably allow detect-ads to operate on the encrypted recording file directly too, although I'm not sure if that's worth pursuing.
 
What I'm thinking now is that a PC boot CD/UPD could be prepared (as a downloadable image) which boots a minimal Linux, looks for a connected drive that is obviously Humax, then seeks out recordings and passes them through the decryption process. It would either have to have the serial number and MAC as inputs (that's more accessible than asking for the key directly), or it would have to be able to hack the key from the encrypted files.

The purpose of this is "The Ultimate Humax Recording File Rescue Utility", which then anyone with a dead HDR-FOX or HD-FOX (and maybe others) can simply boot their PC to the tool and plug the drive from their Humax into to have the recordings bulk-decrypted.

I could offer to have a go at this myself, but it would join a long list of to-dos.
 
af123 said:
It could conceivably allow detect-ads to operate on the encrypted recording file directly too, although I'm not sure if that's worth pursuing.
Click to expand...
It would depend on how stripts handled reaching the end of a still growing file, to remove the need for chaseget it would have to only return end-of-file when the recording actually finished.

What would really make a difference would be the ability to extract the audio to detect the silences without the need for the overhead of ffmpeg but that is something totally different from decryption.
 
I have been contemplating whether it is possible to look at the raw (compressed) audio stream to infer silences rather than decode it first.
 
Presumably it could be possible now to extract the current data from 0.ts, pipe it through a decryption utility (possibly on another box) and then into some streaming server?
 
Black Hole said:
I never managed to make BootHDR work
Click to expand...
BootHDR is a mess. It's clunky and leaves turds where it shouldn't. I half thought about trying to tidy it all up, but have never quite found enough motivation.
My HD-FOX has somehow managed to scramble its disk and /mod has become completely corrupted. BootHDR is not going back on now.
 
prpr said:
BootHDR is a mess. It's clunky and leaves turds where it shouldn't. I half thought about trying to tidy it all up, but have never quite found enough motivation.
My HD-FOX has somehow managed to scramble its disk and /mod has become completely corrupted. BootHDR is not going back on now.
Click to expand...
With this new decryption method and the Youtube-dl package for downloading YouTube and iPlayer, BootHDR will soon be on its way to the package repository in the sky. It may bump into 'unencrypt' when it gets there.
 
prpr said:
Presumably it could be possible now to extract the current data from 0.ts, pipe it through a decryption utility (possibly on another box) and then into some streaming server?
Click to expand...
In as much as decryption seems to be fast enough to keep up (need to test a HiDef), this now seems feasible. I could dedicate a HD-FOX to being a network TV server. There will be some work to do to keep track of the 0.ts write pointer.
 
A word of caution:

If af (or somebody - fat chance) manages to bypass encryption entirely, fancy piping through stripts will become unnecessary overnight (for all applications except recovery). It's no good holding off developments though - if bypass never comes to fruition, progress will have been unnecessarily delayed.

What I am saying is the architecture of any new facilities should accommodate both encrypted and plaintext input. A process should check whether it is necessary to pass the data through stripts before doing so, and stripts should have a flag (or just do it anyway) so that if presented with plaintext it still produces the expected output rather than bombing out.
 
Last edited:
Black Hole said:
In as much as decryption seems to be fast enough to keep up (need to test a HiDef), this now seems feasible. I could dedicate a HD-FOX to being a network TV server. There will be some work to do to keep track of the 0.ts write pointer.
Click to expand...
You could do this using chaseget (although not on an HD-FOX). Chaseget can provide an (almost) realtime decrypted stream for hi def channels
 
af123 said:
I might be able to build a windows version given time but in the meantime, would you be willing to provide a small test recording for me to have a go at?
Click to expand...

A Windows version would be fantastic and it would be interesting to see how fast a high end PC/Workstation could decrypt the recordings
 
You must log in or register to reply here.
Back
Top