-
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.
Beta Offline decryption utility
- Thread starter af123
- Start date
Black Hole
May contain traces of nut
stripts is a multi-function tool. If you just ask it to decrypt, it will just decrypt.
There's nothing stopping you installing the appropriate libraries. Don't go reinventing the wheel.
If you have too much trouble with Linux, you could try the Windows version... or even stripts on another HDR-FOX.
Ezra Pound
Well-Known Member
Hi,
I examined the scripts-linux executable code using a text editor, and it seems some of the text present refers to :
DES_ECB
DES_EDE_ECB
I tried both and that which did not raise an error was :
Previous errors were the library problem and "hex string too long" if the "-nopad" switch is not used, or "bad decrypt".
Using VLAN the decrypted file did not run as expected, but i assume this is due to the extra 20% information which is not MPEG2 ts related as per the stripts wiki.
The decryption was 20 seconds for a 0.5GByte file.
Regards,
Shadders.
I examined the scripts-linux executable code using a text editor, and it seems some of the text present refers to :
DES_ECB
DES_EDE_ECB
I tried both and that which did not raise an error was :
Code:
openssl enc -d -nopad -des-ede -K "key" -in ***.ts -out ***_dec.tsPrevious errors were the library problem and "hex string too long" if the "-nopad" switch is not used, or "bad decrypt".
Using VLAN the decrypted file did not run as expected, but i assume this is due to the extra 20% information which is not MPEG2 ts related as per the stripts wiki.
The decryption was 20 seconds for a 0.5GByte file.
Regards,
Shadders.
prpr
Well-Known Member
I presume you mean VLC or Videolan. VLAN is something quite different.
The extra 20% is MPEG .ts related - it's the EIT data (EPG etc.) on PID 18.
Anyway, what you are trying won't work, as you have it, as the first 8 bytes of each 192 byte packet are not encrypted, and so don't need to be decrypted.
Had you read back 3 pages, you might have found this post, which may answer your questions.
Hi,
Thanks - yes, meant VLC.
I have been searching and reading most posts, but i never got to page 18 on this thread. There are many threads on this subject.
Looks like the python code is exactly what i need. Thanks for pointing me to it. Much appreciated.
Regards,
Shadders.
Hi,
Just ran the code as per page 18 - and as per same page changed :
To
Converted the file and plays via VLC - and can now watch American Dad and others i missed. 
Should be able to run this on the recovered Humax hard disk.
One question i have - if the other files are not modified such as the HMT (?) or other, then will my new Humax DVR unit still play the files as if the HMT file (?) indicates the file is encrypted, when i have decrypted it ?
Thanks and regards,
Shadders.
Just ran the code as per page 18 - and as per same page changed :
Python:
key = bytearray.fromhex("00000000....")
Python:
key = bytes.fromhex("000000000...")Should be able to run this on the recovered Humax hard disk.
One question i have - if the other files are not modified such as the HMT (?) or other, then will my new Humax DVR unit still play the files as if the HMT file (?) indicates the file is encrypted, when i have decrypted it ?
Thanks and regards,
Shadders.
prpr
Well-Known Member
If the .hmt says it's encrypted when it isn't, what do you think the native software is going to do? Might it apply the decryption algorithm to an already decrypted file? With the result that...?
Hi,
Thanks - just checking. I will attempt to edit it manually. There are many recordings don't want to lose.
Regards,
Shadders.
MymsMan
Ad detector
What model of Humax, I don't think they all use the same hmt format and anyway all of the sidecar files are optional.
If it does use the same sidecar files the hmt utility can be used to tweak the various hmt flags or the file layout is on the wiki if you wanted to resort to hex editing
Hi,
I had the Fox HDR T2 and now have the HDR-1800T (i selected that one as it had the lowest power consumption).
If the files are optional, then i will just copy across the unencrypted TS files. Thanks for the link to the HMT format - will see how it goes without those files, reducing the need to edit.
Regards,
Shadders.
EEPhil
Number 28
The format for the encryption key for this model is not known. No existing tools can decrypt the file off the box. You will need to copy and patch the htm file and return it to the Humax to allow the decryption of HiDef files by copying to USB or streaming via the DLNA server. The 1800T nts and thm files seem to be the same format as the Fox, the hmt file is nearly the same - there is additional information at the end of the file. The important locations are the same as for the Fox. The external tool Foxy for the Fox HDR T2 will correctly patch the file. Or you can use a hex editor.
Hi,
The FOX HDR T2 failed, so i am decrypting those programmes i had not seen, are not available on internet (officially), or those i want to keep, such as documentaries and science programmes.
I will transfer them across to the HDR-1800T and see how it handles them with the modified HMT file, but i will not change the NTS file. I don't record high definition programmes, so the python script as previous is more than adequate for what i need. If the HDR-1800T has any issues i can play the decrypted files on my set top box.
Thanks and regards,
Shadders.
EEPhil
Number 28
If you decrypt the Fox files and keep all the sidecar files they can be loaded onto the 1800T and behave just like newly recorded ones.
Black Hole
May contain traces of nut
The python script doesn't care whether a recording was HiDef or StDef. However, the "encrypted" flag in the .HMT must be correct – otherwise the player device (be that HDR-FOX or HDR-1800T) will try to decrypt something which isn't encrypted (or vice versa).
Black Hole
May contain traces of nut
What is the status of this? Has the mainstream stripts "acquired" decryption capability?
prpr
Well-Known Member
What "this" are you referring to? The mainstream stripts has had decryption capability for years.
And, because it was fairly easy to do, I've just added encryption capability to it.
You might think this is pointless, but it's useful for testing stuff, and if you had a file that had been accidentally double-decrypted then you can undo the double decryption by encrypting it and make it just single-decrypted.
I hope to update the Linux build as well, although thus far I've only built it on the HDR.
And, because it was fairly easy to do, I've just added encryption capability to it.
You might think this is pointless, but it's useful for testing stuff, and if you had a file that had been accidentally double-decrypted then you can undo the double decryption by encrypting it and make it just single-decrypted.
I hope to update the Linux build as well, although thus far I've only built it on the HDR.
EEPhil
Number 28
I think I created (and put on the relevant thread) a Java tool that encrypted for the same reason.
Black Hole
May contain traces of nut
I'm referring to stripts, yes. So far as I can see, there has been no formal migration of stripts out of beta, and yet the mainstream WebIF is (I think) dependent on it.
Perusing the WebIF package management, it seems to me the beta tag has been quietly dropped on a number of packages, so it would be useful if their relevant threads were moved to the main forum or closed to make the status clear. It's a pain when I'm trying to keep definitive records.
Perusing the WebIF package management, it seems to me the beta tag has been quietly dropped on a number of packages, so it would be useful if their relevant threads were moved to the main forum or closed to make the status clear. It's a pain when I'm trying to keep definitive records.