Windows version of offline decryption (HFODU)

This isn't looking promising. I cannot install either the Java runtime or the development kit for either version 191 or 192. The installer crashes with no error message. Now have to look into extracting the contents of the install file and manually doing the update.:frantic: WFT!
I'm going to start agreeing with prpr's opinion of Java.
 
I've managed to "install" version 192. Install is a bit of a laugh. It is a case of using 7z to unpack the installer and then unpack a .cab and unpacking .pack files to .jars :mad:. I had to use the development kit as there seems to be something wrong with the runtime. The file dates on the runtime files for version 191 are 2014 and it returns a version of 20_ea. Whether the updates done the usual way have this problem I don't know.
Java: Wake up and smell the :poop:
:coffee:
If only I had a free compiler for C/C++ with up-to-date libraries covering ftp/dlna/decryption - I'd switch. Unfortunately I've got a very old Borland C++ Builder with none of the required libraries. C# compilers appear to be a pile of doggy do-do as well.

Back to the reported fault. I tried running the version of HFODU2 that is posted here using Java version 1.8.0_192 and I cannot repeat the problem described. I can go up down the filestore no problem. Select an empty directory or one with no .ts files and press decrypt - I get 0 files processed. As expected. I can select multiple directories. Anyone else repeat the fault?
 
Last edited:
I use Visual Studio Express 2013 on W7 (and before that VS2010 Express on XP). It's free and quite easy to get going with.

I have no idea what libraries you mean.
Neither do I :roflmao: which is why I stick with Java because I can find a set of built in functions for ftp and decryption. The DLNA stuff is a bit harder to find but works. I've not been able to find a similar set of functions for Borland C++ or any other C based compiler that I have to hand. VS2010 sound familiar - wonder if I still have it somewhere.
 
I've managed to "install" version 192. Install is a bit of a laugh. It is a case of using 7z to unpack the installer and then unpack a .cab and unpacking .pack files to .jars :mad:. I had to use the development kit as there seems to be something wrong with the runtime. The file dates on the runtime files for version 191 are 2014 and it returns a version of 20_ea. Whether the updates done the usual way have this problem I don't know.

:coffee:
If only I had a free compiler for C/C++ with up-to-date libraries covering ftp/dlna/decryption - I'd switch. Unfortunately I've got a very old Borland C++ Builder with none of the required libraries. C# compilers appear to be a pile of doggy do-do as well.

Back to the reported fault. I tried running the version of HFODU2 that is posted here using Java version 1.8.0_192 and I cannot repeat the problem described. I can go up down the filestore no problem. Select an empty directory or one with no .ts files and press decrypt - I get 0 files processed. As expected. I can select multiple directories. Anyone else repeat the fault?

I'm sorry to say I can't repeat it either:oops: Or rather, I can but I can easily get round it. The issue seems to be that I am using an oldish wheel mouse with the wheel button assigned as a double click. It appears that the file selecter (the built-in Java one?) is very hit and miss (mostly miss) in accepting a wheel click as a double click to open a directory (I have never had this problem with Windows file selecters). I therefore selected the directory I wanted and pressed the Return key, expecting it as in the Windows file selecter to perform the same function as a double click, ie to enter that directory. In this file selecter however it performs the same function as the Open button, ie selects the directory for processing and returns to the main screen with no files selected if that directory contained no TS files. As I said previously I didn't have this problem when I tried it before so either the Java update was an unfortunate coincidence, it introduced changes in processing double clicks or my mouse needs a good clean.

Sorry again to have caused you unnecessary work.
 
It appears that the file selecter (the built-in Java one?) is very hit and miss (mostly miss) in accepting a wheel click as a double click to open a directory
Hmm. Never considered that. I forget that it's possible to click the wheel on my (old) mouse.
Sorry again to have caused you unnecessary work.
Well, you have and you haven't. It's alerted me to problems I have installing new versions of Java. Now that I have a little more information I can have a look at the mouse response in the "built-in Java one" and see if there is anything that can be done. Must admit I find the file selector a bit sluggish.
BTW the program only searches for the .ts files, so if you give it a directory full of (say) .mpg files it should behave as though it was an empty directory and add no files to the processing.
 
This isn't looking promising. I cannot install either the Java runtime or the development kit for either version 191 or 192. The installer crashes with no error message. Now have to look into extracting the contents of the install file and manually doing the update.:frantic: WFT!

If you attempting to install it on XP then I believe 181 is the last version that is supposed to be manually installable, least that is the experience of another project I use that uses Java.

I don't know if there was an official announcement about this, as Java 7 was supposed to be the last supported version for XP, so maybe it is an attempt to stop people manually installing release 8 on XP.
 
I found out that I'm using version 151. Hadn't bothered to update after that. Version 181 (and 171 I think - if it exists!) don't install either. It's the installer that is the problem. The actual Java files contained seem to work. But it's a right pain to un7zip them, put them in the right place, manually unpack the libraries and then get the paths & java_home sorted.
so maybe it is an attempt to stop people manually installing release 8 on XP.
Why bother doing this? Java 8 works on XP (noting prpr's opinion). It wouldn't cause Oracle any problems to allow the installation.

The new Java SE 11.0.1 is impossible for me to use even by the painful method described above - they only supply a 64bit version. :mad:
 
I don't suppose it's possible to use the HFODU2 software to decrypt files made with a humax HB-1000s. This box makes several files (nts, hjm, even png) and includes a very large hts file. My naive efforts to open one results in an error message that the file has already been decrypted (if only ...).
 
I don't suppose it's possible to use the HFODU2 software to decrypt files made with a humax HB-1000s. This box makes several files (nts, hjm, even png) and includes a very large hts file. My naive efforts to open one results in an error message that the file has already been decrypted (if only ...).
You suppose correctly. The thread was placed in the FOX-T2 part of the forum for that reason. (Although it is arguable whether it needs to be in the Customised Firmware section). As far as I'm aware "we" only know how to construct the encryption/decryption keys on the FOX-T2. The only error message that I can see that matches your comment states -"This file is not decrypting. Has the file been decrypted already? Check MAC and Serial Numbers." The program only looks for .ts files so, assuming you really meant to put "hts", you've renamed a file. I'm not surprised the program gave an error message. I may have to look into giving more meaningful error messages. :)
 
Thanks for the quick reply. I got quite excited for a moment getting your software to run (with XP Pro). I didn't rename the file(s) - the large ones in the directory "video" have the affix *.hts. And yes, that was the error message. Thanks again.
 
I didn't rename the file(s) - the large ones in the directory "video" have the affix *.hts.
That suggests that I have a bug in the program. It's only supposed to find .ts not .hts. Oh well. Thanks for spotting that. I'll add it to my list of things to correct at a later date.
 
I just want to thank you guys (and EEPhil in particular) for sharing your work. My Humax HDR-Fox T2 packed in and wouldn't restart. However I found that the disc and recordings were okay, albeit encrypted. I'm now in the process of successfully restoring a few 100 recordings onto a new Humax box. It has taken me a little outside of my technical comfort zone for a while, but well explained and everything seems to be working. Many thanks!

Admin Edit: The off topic discussion has been moved to a new thread HERE.
 
Last edited by a moderator:
HFOEU:
People viewing the thread Crashing and Green Screen" may be aware that it might be possible to use the on-box decryption routines in such a way as to decrypt a file with the wrong key. I'm including a variation of HFODU2 that encrypts rather than decrypts the file. In the few tests I've been able to do I've managed to wrongly decrypt a file and then re-encrypt it using this new tool. That then leaves the file in a state where it can be decrypted properly using the correct key. In all respects, other than it encrypts rather than decrypts, the behaviour is as HFODU2. For these details see post #1. Unzip the attached file and run HFOEU.jar in the same way you would HFODU.jar or HFODU2.jar.
 

Attachments

  • HFOEU.zip
    34.5 KB · Views: 91
Like jim_p, my HDR-Fox T2 has recently packed up. Not able to boot up with the HDD attached.
Just wanted to say a big thank you for the help given to me on this forum to copy the recording files from the T2 disk to my PC, and then decrypt them using this hfodu2 tool. :) :)
 
Back
Top