Beta Offline decryption utility

af123

Administrator
Staff member
I've extended the stripts utility with the ability to decrypt Humax recordings directly and would appreciate some wider testing.

The utility can be downloaded from:

- https://hpkg.tv/misc/stripts-linux (for Linux systems);​
- https://hpkg.tv/misc/stripts-omnios (for OmniOS/OpenIndiana/SmartOS/Solaris x86 systems);​
- https://hpkg.tv/misc/stripts-macosx (for MacOSX systems);​
- The on-box stripts will also be updated with this feature but is much slower than the DLNA method we already have, taking around 30s for each minute of recording.​

You need to extract the decryption key from your box which (for now with underlying 1.03.12) can be done via:
Code:
humax# nugget dump 0x0dadd58 0x10
00dadd58: 00 03 78 bd 11 f3 36 33 37 31 30 34 34 39 36 30  ..x...6371044960
In this example, the encryption key is 000378bd11f336333731303434393630 - the eagle eyed amongst you will spot that it's the box MAC address + the first 10 digits of the serial number, although not all bits are actually used.

Then, to decrypt - stripts -@ <key> <input recording> <output recording>

Code:
omniosce# chmod +x stripts-omnios
omniosce# ./stripts-omnios -@ 000378bd11f336333731303434393630 "800 Words_20180418_1434" "800 Words_20180418_1434_dec"
Processed in: 6.98s
That test recording is 5 minutes from BBC ONE today.

I discovered a few anomalies (bugs!) in the Humax DLNA decryption implementation along the way but this utility replicates those so should produce a file which is identical to one decrypted in the current way.
 
Last edited:
Once you are past the testing phase it would be nice to display the key on the Diag page and upload it to RS so that it is available for recovery after a motherboard failure.
A windows version of stripts might also be useful.
 
Once you are past the testing phase it would be nice to display the key on the Diag page and upload it to RS so that it is available for recovery after a motherboard failure.
I've already added a {system encryptionkey} method to my web interface tree so will show it somewhere (diagnostics most likely). I think the box MAC address & serial number are actually printed on the case or sticker so that would be a way to get the key following failure.
I don't know how people would feel about even a partial serial number being uploaded to RS, although it would certainly be a useful backup.
A windows version of stripts might also be useful.
Yes....
 
Last edited:
it's the box MAC address + the first 10 digits of the serial number, although not all bits are actually used.
I wonder how many other Humax models this applies to and which ones. Presumably the freeview 2000T/1800Ts but possibly other newer models.
 
I wonder how many other Humax models this applies to and which ones. Presumably the freeview 2000T/1800Ts but possibly other newer models.
It would be interesting if somebody with a 2000 could give it a spin too.
 
Another Milestone utility from af123 and definately one for the Wiki Timeline, I couldn't find the Mac address on the HDR-Fox T2 box but the 14 digit serial number (containing the same 10 digits from the nugget dump) is definately there, And before someone asks, yes I still have the original box for my Humax, I've have had things stored in it for over 7 Years :)
 
Last edited:
, yes I still have the original box for my Humax, I've have had things stored in it for 13 Years and 9 Days :)
Presumably not human years (too long) or dog years (too short). Would they be hippopotamus or perhaps horse years?
 
Last edited:
I've uploaded a new webif version to the beta repository that shows the system encryption key on the diagnostics page (and in the output from version on the CLI). There's also an updated stripts package which has the new decryption function in it. To just use the native key from the box you can use stripts -@@ <input> <output> but of course that only works for the Humax version of the utility.
 
It would be interesting if somebody with a 2000 could give it a spin too.
I'd be quite happy to look into this - but given that this thread is in the CF section of the FOX T2 - it might be beyond my understanding!
A windows version of stripts might also be useful.
If there is a source code, or an explanation of the method, and a defininitive description of how to obtain the encryption key ( "the eagle eyed amongst you will spot that it's the box MAC address + the first 10 digits of the serial number, although not all bits are actually used." - confuses me!) - bearing in mind that there is no CF for the 2000T - I might be able to give it a go.
Is it as simple as using the key to decode each 188 byte packet? (Yes I know the Humax uses 192 byte packets, but 4 of the bytes are not encrypted as far as I can tell). If it is, what is the encryption type?
 
Last edited:
I've uploaded a new webif version to the beta repository that shows the system encryption key on the diagnostics page (and in the output from version on the CLI). There's also an updated stripts package which has the new decryption function in it. To just use the native key from the box you can use stripts -@@ <input> <output> but of course that only works for the Humax version of the utility.
I have just noticed that while the Mac address is shown in the RS device details it does not appear to be shown in the System Information box on the webif
I have never needed to know the address so it is no big deal but just seemed a little odd that is on RS Settings page but not Diag page.
 
Last edited:
I've extended the stripts utility with the ability to decrypt Humax recordings directly and would appreciate some wider testing.
Works for me on a quick test (Linux version). I just copied the .ts file and set it going. It complained about a missing .hmt file. I fabricated one with sidecar and it then decrypted OK. It'd be nice if it could fabricate the .hmt (and .nts used by other operations - sidecar just generates a 0 byte file) internally rather than complaining about (mostly unnecessary) missing files.
 
Last edited:
If there is a source code, or an explanation of the method, and a defininitive description of how to obtain the encryption key ( "the eagle eyed amongst you will spot that it's the box MAC address + the first 10 digits of the serial number, although not all bits are actually used." - confuses me!) - bearing in mind that there is no CF for the 2000T - I might be able to give it a go.
Is it as simple as using the key to decode each 188 byte packet? (Yes I know the Humax uses 192 byte packets, but 4 of the bytes are not encrypted as far as I can tell). If it is, what is the encryption type?

The algorithm is 2-key 3DES with ECB. The input key is 128-bits but includes parity so really only 112-bits are important. I tested and you can set the remaining bits to anything you want and still get a successful decryption. In fact, the way that Humax generate the key means it has bad parity from the start (each byte should have an odd number of set bits).

For the simple case, each 184 byte packet just needs decrypting - the 8 byte header is always unencrypted. If the packet has adaptation set then only the payload is encrypted but only up to a multiple of 8 bytes. Any trailing bytes are copied as-is and presumably were never encrypted in the first place.
 
I have never needed to know the address so it is no big deal but just seemed a little odd that is on RS Settings page but not Diag page.
RS uses the MAC address for the box identifier.. could easily add the MAC address to the diagnostics page too though.
 
If there is a source code, or an explanation of the method, and a defininitive description of how to obtain the encryption key... I might be able to give it a go
If you can transfer a recording from the 2000 to a separate machine which can run the utility, it's just a case of getting the serial number and mac address to derive the encryption key, then running the utility on the file, and seeing if you can play it on the separate machine afterwards.
 
t'd be nice if it could fabricate the .hmt (and .nts used by other operations - sidecar just generates a 0 byte file) internally rather than complaining about (mostly unnecessary) missing files.
That should be possible - it's hooked into stripts because that already had a lot of the required parsing logic in it, but does expect to find a recording file set at the moment.
 
Back
Top