• 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.

Windows version of offline decryption (HFODU)

From what I can see HFODU currently works on a single (prompted) file. I have a large number of files archived onto a NAS where just potentially the odd file may not have been decrypted. In this case it would be great if HFODU could be given a batch mode (or command line interface?), where multiple files could be processed in one hit and any encrypted files (by checking the HMT flag) automatically decrypted, without having to find them and copy them back to Humax.
 
@sceptic: I note your request - but, as pointed out earlier, I don't have a FOX-T2 and - as yet - we haven't determined the key for a 2000T (which is what I do have). I have only one available FOX file for debugging purposes. I might be able to knock something up eventually, but it wouldn't be tested properly. Doesn't af123 have some command line tools? Or are these for *nix only?
 
Yes, they are for Linux and Mac. I see no difficulty running them in a virtualised environment on any machine you like.
 
@EEPhil No worries, I'll either explore the Linux VM route :eek: or I might have a go at creating a native windows batch decrypter if I can spare the time.
 
sceptic said:
@EEPhil No worries, I'll either explore the Linux VM route :eek: or I might have a go at creating a native windows batch decrypter if I can spare the time.
Click to expand...
I haven't given up on looking at this.
[Thinking out aloud]But the original looks for .ts files only (and processes .hmt if available). To follow your request, I'd be looking for .hmt files and checking for encrypt/decrypt status. That's fine. But what about orphaned .ts files?[/Thinking out aloud]
 
EEPhil said:
I haven't given up on looking at this.
[Thinking out aloud]But the original looks for .ts files only (and processes .hmt if available). To follow your request, I'd be looking for .hmt files and checking for encrypt/decrypt status. That's fine. But what about orphaned .ts files?[/Thinking out aloud]
Click to expand...

Ah OK. I was imagining that it probably traverse the filesystem (from a prompted start location) looking for .ts files and then check for a corresponding .hmt to see if it was encrypted. Any encrypted files would be decrypted with the flag changed in the HMT file. If a TS file is orphaned then is there anyway to tell if is it encrypted or not? ISTR @af123 mentioning somewhere that stripts tries multiple keys so presumably there must be some way to check if the file is encrypted and if the key supplied is actually valid for that file... If that is the case then any orphaned .TS files could still be processed by presumably trying to decrypt them and check the resulting file was valid somehow? Orphaned files should be quite rare though I would have thought...
 
I may have misunderstood af123 (so apologies if this is wrong). My understanding was that stripts attempts a decryption of the .ts file, but checks to see if the first occurance of "stuffing bytes" decrypts properly. These are known values (0xff) in a known place (PID = 0). If this are correct, then decryption is working. If not, decryption has failed either because the key is wrong or the file is already decrypted. I'm fairly sure this is correct. In any case, this is what my utility does. So I think BH is right, sidecar not required.

I think, if I do anything about it, I'll scan for .ts files, check for .hmt, possibly obey enc/dec status in them or try to decrypt anyway.
Edit: Might have to modify where the resulting files go, produce a log file, and remove the option to manually rename the output files if I go down this route.
ie. new directory for output files - otherwise you could have a big mess in one directory. I'm reluctant to modify or delete any user files. You are responsible for losing the originals not me. :p Log file - so that you know which files were processed. Can't pop-up an output name prompt for each file - that isn't an unattended batch. Argh! :coffee: :coffee:
 
Last edited:
It's a bit more robust than that. stripts finds a PAT and reassembles it (it can span multiple packets and not necessarily together in the stream) then decodes it and checks that the table entries look right, that the three bits which are reserved are set to 0 in each case, and that the PMT of the recording itself is present.
Looking at the code now, I wonder why I did not just check that it matched the embedded CRC..
 
af123 said:
It's a bit more robust than that
Click to expand...
You clearly understand the stream better than I do! I'm only using a quick-and-dirty stuffing-bytes test. I'm not sure I could make sense of the PAT, three bits or where the embedded CRC is without far more research! Q&D will do for now - until it goes belly-up! :D
 
Last edited:
@EEPhil Sorry I did not want to give you a headache. If you do go the separate directory route it would be good if the utility could maintain the directory structure of the original files in the output directory, so it would be easy to copy them back over the originals once they had been checked.
 
I was thinking more like create a sub-directory of where the original was. (ie. e:\videos\dump\afile.ts -> e:\video\dump\decrypt\afile_dec.ts) But, perhaps, only if you choose multiple files or a directory. The aim would be to keep the original behaviour for novice users.
This is definately a case of - it might get done when I get a round tuit! It is in the first stage of development - it is tumbling about in my brain as I try to work out the best thing to do next. (That is while I'm multitasking all those other jobs that need doing)
 
Last edited:
sceptic said:
so it would be easy to copy them back over the originals once they had been checked.
Click to expand...
Even in different directories I don't like the idea of two files (or sets of files) with the same name. It only takes a lapse of concentration (or one of my many senior moments) and you end up deleteing (or copying over) something treasured! I might stick to adding _dec to everything as an extra reminder - just in case.
 
af123 said:
Looking at the code now, I wonder why I did not just check that it matched the embedded CRC.
Click to expand...
That's very useful. At least where the PAT is in one packet. I've managed to make sense of this - although I'm sure the start position for the section seems strange. I can also make sense of a PAT split into the next packet. If it can occur at some random later packet I'm screwed! All the tests so far seem to work. And it is only programmes recorded from the SDN multiplex that have big PATs - as far as I can see.
 
I've produced and tested (as far as possible) a revised version that allows input of multiple files from one directory or a directory itself. (I've named this HFODU2 so that you can have the old and the new versions side-by-side if you wish).
I've taken the opportunity to use one of the more robust tests for decryption- as outlined by af123 above. All my testing shows that this works, so I will be dissappointed (and look a bit foolish) if this fails for anyone using the program!
For users who select just one file at a time there should be no change - except the program now produces a log file of the form HFODU2-{date}-{time}.log. There may be the odd message that would have appeared as a pop up window that now goes into the log file instead.
For multiple files: All processed files end up in a subdirectory "decrypt" alongside the input files. Sub-directories of a selected directory are not searched.
When "decrypt" is pressed the files are queued for processing. A message will pop up indicating the status of the decryption (as in single file use). It will only remain visible for two seconds and then the processing will move on to the next file.
The log file contains information that should help you locate which files decrypted properly and where the ouput is.

Code: 
10:20:15 INFO: Humax 'FOX' Offline Decrytion Utility (HFODU V2.0a) - Java Version: 1.8.0_151
10:20:25 INFO: Using MAC: **-**-**-**-**-**, Serial: **************
10:20:25 INFO: Processing 5 files.
10:20:25 INFO: Decrypting: C:\...\testdir\dec_Pointless.ts
10:20:28 WARNING: File not decrypting - check status/MAC/SN
10:20:30 INFO: Decrypting: C:\...\testdir\enc_Pointless.ts
10:20:37 INFO: The file was decrypted successfully.
10:20:37 INFO: Output is C:\...\testdir\decrypt\enc_Pointless_dec.ts
10:20:41 INFO: Decrypting: C:\...\testdir\notts.ts
10:20:43 WARNING: File is not Humax .ts
10:20:43 INFO: Decrypting: C:\...\testdir\Star Trek_ Enterprise_20180826_1358.ts
10:20:43 WARNING: File not decrypting - check status/MAC/SN
10:20:46 INFO: 1 of 4 files successfully decrypted.
10:20:54 INFO: Program exiting normally
I've removed some information from this log (***,...).
I could have checked to see whether the file was already decrypted. I didn't use the .hmt file for this in case there isn't one! I suppose I could have used the same CRC check on the PAT before and after encryption but again, I didn't. Therefore, as it just doesn't decrypt again," check status/MAC/SN".
In the above log - dec_Pointless was already decrypted, enc_Pointless was encrypted and I know the key, notts is not a transport stream file, and Star Trek was encrypted on a 2000T so the key is wrong.
I hope this does what people want it to do - and doesn't crash!
 

Attachments

  • HFODU2.zip
    35.3 KB · Views: 261
Last edited:
@EEPhil - I have tried HFODU2 and it works a treat - thank you.
One thing I would mention. If I open the log in Notepad it appears as one continuous line. If I open it in Notepad++ all is fine. I notice that each line ends with LF (Unix ?) and I believe Windows needs CR & LF.
 
peterworks said:
@EEPhil - I have tried HFODU2 and it works a treat - thank you.
One thing I would mention. If I open the log in Notepad it appears as one continuous line. If I open it in Notepad++ all is fine. I notice that each line ends with LF (Unix ?) and I believe Windows needs CR & LF.
Click to expand...
Argh! I tested with Notepad++ myself - and forgot to check the "show all characters" setting. And the "logging" was a built-in function in the Java library. Might have a look into it later.
 
You must log in or register to reply here.
Back
Top