• 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

Sadly our HDR-FOX T2 HDR 500GB which has served us well for years with customised firmware died. However the disk was still good and the label on the bottom gave us the Serial Number and MAC address. So with the Linux version of "stripts "some 200 files of my wife's favourites were recovered and converted to MP4s

A big thank you to AF123 and everyone else that turned an ordinary box into something special and especially for stripts for allowing the recovery of programs when it died.
 
In what way has it "died"? Are you sure it is not recoverable? In any case, it is probably useful for spare parts.

There has been a very recent report of somebody on here picking up a mint 1TB HDR-FOX for only £20, so there is nothing need to rule out getting another one.
 
This is how it died: It became increasingly unreliable with it locking up when viewing a channel and more often than not it would fail in a recording. On a hard re-boot it would go through multiple cycles of loading the firmware in to a green screen until eventually it continued normally. Then one day after a power cut it just refused to stop cycling. I reloaded the firmware without a problem but it still continued to cycle. I took the disk out and checked it for bad sectors but it was clean, unplugged and re-plugged everything that could be with no change, so deduced it was probably a mother board or memory fault and consigned it to recycle minus the disk.
 
Possibly just a PSU fault, maybe repairable (by replacing "blown" electrolytic capacitors). Another test is to try running it without the HDD installed. It's a real shame you junked it without raising the issue here first, or even offered it for somebody to repair or strip.

Commissioning, Disassembling, and Repairing an HDR-FOX (click)

What To Do with a Dead or Unwanted HDR-FOX, HD-FOX, or DTR-T1000 (click)

Both these topic are pinned near the top of the vanilla HDR-FOX section of the forum.
 
Last edited:
I did search the forum when the problem first started and I have seen both those links before. I also checked out the PSU and every other sub-assembly. To me it appeared very much like a PC memory or motherboard fault as it would boot from an external device but not internally. Anyway in the interests of house-hold harmony it went and is now replaced with HTS Tvheadend on a SSD Linux box with 3 DVB tuners and multiple Kodi - LibreElec clients which work both here and abroad. The T2 disk lives on as NAS storage.
 
At risk of labouring the point: even with a failed motherboard there was still a spare PSU, front panel assembly, and fan.

Seabee said:
HTS Tvheadend on a SSD Linux box with 3 DVB tuners and multiple Kodi - LibreElec clients
Click to expand...
Sounds good. 👍
 
Black Hole said:
At risk of labouring the point: even with a failed motherboard there was still a spare PSU, front panel assembly, and fan.
Click to expand...

You don't have to tell me but with a wardrobe full of salvaged parts "that might come in useful" the "house manger" ruled that we were not keeping any more unless it had an immediate use. (In amongst the salvage is a complete functioning custom firmware Humax Foxsat HDR which has been there since they replaced the Astra satellite.)
 
Hi All.

I would like to firstly point out that i want to 'Decrypt Via Remote Only', due to not having internet at home. There may be a suitable decrypt feature on the 'Webif' but as i don't have internet and or a PC regularly, i can't make use of it unfortunately.

Before this post - [https://hummy.tv/forum/threads/hacking-the-on-board-encryption-chip.8217/page-3#post-130865] - has been resolved for future recordings, is there a "magic folder" similar to 'Nicesplice Magic Folders' that i can place my recordings adhoc for decryption at my leisure? ie. offline decrypting without webif or internet.

As mentioned in that post/link, we've tried "decrypting on the fly" but don't like that anymore as it slows the box way too much, and has caused several recordings to fail)!

I'm not looking to copy/decrypt to an external USB-Device - but a special folder in the normal 'My Video' just like the [EDIT] folder from 'Nicesplice Magic Folders'.

I used to use "Virtual-USB" to decrypt/copy which retains the file on the Humax unit, but i've found that option to decrypt isn't accessible once i've used the correct ejection method for removing an external usb drive, as per thread - [https://hummy.tv/forum/threads/hidden-service-menu.471/] - so i need another solution instead that i can use 24/7.

For example can the 'Virtual-USB' be made or kept in the normal 'My Video' instead of the external storage area?

Just to also note, the Virtual-USB being in the external storage area actually doesn't allow you to copy to a real storage device such as an external usb-hdd for archiving anyway....!!

I don't always have access to a usb-hdd to archive off certain recordings for other family members, hence using the virtual one for decrypting purposes and temporary storing.

So just to clarify, for my particular needs, i need a magic folder called: "[DECRYPT]" in the normal 'My Video' - no other solution will suffice.

Many thanks
 
Last edited:
You don't need the internet or access to webif to enable automatic decryption

On one of the occasions you do connect to the webif just enable recursive auto decrypt on My Video and all recordings will be decrypted without you having to do anything in the future
 
Have just discovered the offline decryption utility and I was keen to try it out, but am getting an error message running the utility on Mac (have tried on both High Sierra and Mojave). I have set the permissions to make the file executable, but running it in terminal just outputs "Killed: 9". I can see some errors in the console when this happens "UNIX error exception: 3" followed by "no signature for pid=xxxx (cannot make code: UNIX[No such process])".

I wonder if rebuilding with the latest build tools on Mojave might fix this?
 
conorg said:
...
I wonder if rebuilding with the latest build tools on Mojave might fix this?
Click to expand...
The messages are consistent with an executable that the OS thinks isn't valid, eg using an incompatible version of an executable compressor like upx, running the object file instead of the linker output.

If the same executable works on pre-High Sierra versions or the error persists after downloading again, your suggestion is probably correct, but it depends on @af123 having a suitable XCode.
 
bit late to the party - but wanted to say congrats to af123 and the team for this breakthrough! sold my humax years ago but remember it and this community fondly 🥰 all the best
 
Thanks af123 for the linux (x86_64) version of stripts. I have been able to use it successfully on a Centos 7 system. Your build of stripts was probably done a while ago and it won't run with the current Centos 7 versions of libcrypto and libssl. To get it to run I had to do a source build of an older version of these. Its not a good idea to install an older version, however its quite easy to get a particular programme to run against its own copies of the older .so files using the environment variable LD_LIBRARY_PATH.
 
I have looked through these posts I hope I did not miss the answer.
I have used stripts-linux with the key as the mac address and S/N as one long string, but I get the message "Provided decryption key is too short". Am I missing the obvious.

I have copied the files from the Humax HDR-FOX T2 to my Linus machine HDD.

Thanks
 
mavz3 said:
Am I missing the obvious.
Click to expand...
Yes you are. The key has to be contrived from elements of the MAC and S/N by formula - it would be nice if the software did that for you, but it doesn't. I'm trying to encourage you to do the research instead of me spending time on it.

Black Hole said:
How to compute the key (from https://wiki.hummy.tv/wiki/Custom_Firmware_Package_Notes#Stripts): concatenate the 12 hex digits of the MAC, with 20 hex digits obtained from the S/N by converting the first 10 digits to hex ASCII. Presuming the S/N is purely numeric, this is not so difficult as it sounds because the decimal-to-hexASCII conversion is simply to prefix each digit with "3". Thus, eg: for MAC 00-03-78-bd-11-f3 and S/N 6371044960-1234, the first 12 hex digits of the key will be 000378bd11f3, and the second 20 digits 36333731303434393630, so the whole key is 000378bd11f336333731303434393630.
Click to expand...
 
Last edited:
You must log in or register to reply here.
Back
Top