Which "utility" do you mean? Are you talking about decryption in general? Did you read my updated post 34 above or something else? This thread is about off-line decryption (the ability to decrypt recordings not using a HDR-FOX), and this is all a bit of a detour.
If you want to understand decryption in general:
* For HiDef recordings, you need to clear the "do not decrypt" protection flag. That is the job of the "
auto-unprotect" package (if you don't know what packages are, you need to get familiar with the custom firmware - see
Quick Guide to Custom Firmware [click]).
* There are numerous ways of triggering decryption, the most commonly used one being to configure the WebIF to trigger it automatically shortly after the recording is complete. It is also available via the WebIF media browser on the OPT+ menu for each recording listed. See
Decryption Guide (click).
The ability to change the HDR-FOX's decryption key to your own custom value (for example to make multiple HD/HDR-FOXes all have the same key, convenient for content sharing without needing to decrypt) has been built into the WebIF for several months. This is not a separate package, but unless you are running the latest versions of packages in your custom firmware (the WebIF is just another package), you may not have it available. In your case: you will be configuring the decryption key to match that of your old HDR-FOX, and then the new HDR-FOX will be able to decrypt the old recordings without any further alterations. It won't then be able to decrypt its own existing recordings until you restore the original key.
Note that the
stripts command line utility (now including software decryption capability) is able to try several keys to find one that works (including the custom key and the original key) - but that does not apply to hardware decryption (which can only use the current configured key) or off-box decryption (where you have to specify the key). Note also that these facilities
might only be available if you enable beta packages.
With regard to defeating encryption entirely: this will require reprogramming the actual Humax hardware so that the native operations which send the data to the HDD via the encryption unit bypass it instead. As we have no documentation on the internal structure of the SoC (System on Chip - in other words practically and entire computer and peripherals all built into one configurable and programmable chip), and only access to the binary code (no source code or even commented assembly code): (1) somebody needs to find the section(s) of code that route data through the encryption unit, without prior knowledge of where the encryption unit is; (2) having found the relevant code, somebody needs to figure how it works and how it can be modified to bypass encryption.
I don't know about you, but to me that sounds like a pretty tall order. The hope is that there already exists a flag which Humax may have incorporated to select behaviour (encrypt or don't encrypt), and if that proves to be the case it would be much easier just to turn it off. But it is still necessary to locate that flag, and looking for it may be a wild goose chase (ie a complete waste of valuable time if such a flag does not exist).
The point is that however much we may
like recordings not to be encrypted in the first place, we don't
need them not to be encrypted because we have work-arounds, and the effort involved is too great to be worth it. With off-line decryption available, it is now even less of an issue (because now recordings can still be recovered, even if the HDR-FOX dies - with the HDD still intact of course).
- i have zero knowledge of coding but i can follow simple step-by-step instructions if someone is patient enough to "hold my hand" ?
