Beta Offline decryption utility

One wonders how much effort becomes too much. Breakfast At Tiffany's was on TV a few times recently, and a friend missed it but wished she hadn't. I had it recorded and was preparing to burn it to DVD when I had a look on eBay... and picked up a 3-DVD set of Audrey Hepburn movies for the princely sum of £2.22 all in.

Nonetheless, if @CharlesW manages to figure out the encryption system for the Foxsat, that will be a significant step forward and is worth pursuing.

CharlesW said:
There are 20^8 combinations and 99 hours to go!
Click to expand...
I'm curious: how are you testing whether the resulting "decryption" is valid?
 
Black Hole said:
A HDMI grabber could not (legitimately) negotiate HDCP.
Click to expand...
You're not legitimately allowed to save the files long-term in the first place, due to copyright.
You can get HDCP strippers, and some of the aforementioned makes probably include them.
 
prpr said:
You can get HDCP strippers, and some of the aforementioned makes probably include them.
Click to expand...
Agreed, but I suggest "might" rather than "probably". Surely a stripper would need to complete a negotiation in the first place, which means access to the encryption details for the secure handshake.

I was only warning that a grabber might not work (and should be factored into any purchase decision), rather than will not work.
 
Black Hole said:
I think I am correct in saying, and I hope I'm not giving away any confidences, that the HDR-FOX key derivation was cracked by hardware inspection and probing (JTAG). Foxsat might be amenable to the same approach, but it seems likely that any more recent models have had that back door closed.
Click to expand...
Can you provide evidence of how the HDR-FOX key derivation was cracked. I would be interested in going through the same process for my FOXSAT HDR.
 
I'm not the person who did it (it is informed hearsay on my part), but I recommend you acquaint yourself with JTAG Boundary Scan Testing. You'll need to locate the JTAG test points on the Foxsat circuit board (presuming there are any), and obtain the appropriate test adapter.

In summary: JTAG enables inspection/stimulation of data paths within ICs, used for production testing and programming but also provides a back door.
 
I've just tried to run stripts on my Linux system (see post 1), and it complains it can't find libcrypto.so.1.0.0. I found a couple of copies (or redirects) of libcrypto.so.1.1 in my /lib folders. What to do?

For the moment, I shall scurry back to Windoze.
 
You need a package such as libssl1.0.0 or libcrypto1.0.0 (Debian-esque) that includes that shared library, or the program has to be rebuilt for OpenSSL 1.1.
 
Black Hole said:
I've just tried to run stripts on my Linux system (see post 1), and it complains it can't find libcrypto.so.1.0.0. I found a couple of copies (or redirects) of libcrypto.so.1.1 in my /lib folders. What to do?

For the moment, I shall scurry back to Windoze.
Click to expand...
If you just want to decrypt on linux using stripts you could use my python script https://hummy.tv/forum/threads/offline-decryption-utility.8676/post-148858
Or is there a specific feature of stripts you need in addition?
 
af123 said:
I've extended the stripts utility with the ability to decrypt Humax recordings directly and would appreciate some wider testing.
Click to expand...

I have just tried it on ts-files extracted from a model YSR-2000, but unfortunately it does not work.

The serial number on these boxes is 30 characters long, which is different from the FOX-model. Does anyone know if there is a workaround for this model?
 
To save anyone else asking "a what?", seeing as there was no qualifying information...
A YSR-2000 would appear to be a Danish YouSee box, which is probably similar to the UK's YouView. As such it is probably encrypted somehow, and definitely different to the HD/HDR Fox T2, so the answer is "no".
 
To agree with the above, in the quoted post, "Humax" should be interpreted as "Humax HD/R Fox-T2". There's no reason why any other model should use a similar encryption system. However, study of this thread might suggest how the YSR-2000 recordings are encrypted. As the encryption in these boxes is handled by a module in the system-on-a-chip, you'd want to check the SoC and see what it supports.

From this forum thread the bootloader only accepts Humax signed firmware, though the OP seems to think its SoC is ARM-based, whereas I would have expected Mipsel for a 2016 Broadcom SoC device. The 4k successor product is ARM-based.
 
/df said:
To agree with the above, in the quoted post, "Humax" should be interpreted as "Humax HD/R Fox-T2". There's no reason why any other model should use a similar encryption system. However, study of this thread might suggest how the YSR-2000 recordings are encrypted. As the encryption in these boxes is handled by a module in the system-on-a-chip, you'd want to check the SoC and see what it supports.

From this forum thread the bootloader only accepts Humax signed firmware, though the OP seems to think its SoC is ARM-based, whereas I would have expected Mipsel for a 2016 Broadcom SoC device. The 4k successor product is ARM-based.
Click to expand...
Thanks for the info - and sorry for not providing info on the box :) It is indeed a Danish Yousee box which has stopped working (probably a faulty power supply). I have taken out the hard drive and am able to extract the files from it, but they are encrypted.

As far as I can tell from other fora, it is impossible to load custom firmware onto the box, which is why I was wondering if there was a way to decrypt the files directly - but this doesn't seem to be the case.
 
Hi,
I have a Humax Fox T2 recorder, and it has now completely failed. I want to recover the files on the disk, but in searching multiple threads, i am unable to determine the encryption used for the ts files.

I was going to use openssl on my Linux PC to decrypt the files. Has anyone tried this at all ?

I have the serial number and MAC for the unit - so i assume that these combined into the relevant password can be used on the command line for either AES or 3DES decryption ?

I assume that the serial number has the ascii characters "3" assigned before each serial number digit, and no conversion to any other format such as base64 is required ?

Thanks and regards,
Shadders.
 
Hi,
Thanks for the wiki link - had not seen that.
What i wanted to do is use openssl - such that the file is not stripped of those aspects that strip removes.

Therefore, is the encryption algorithm stated anywhere, and is the key ascii or does stripts convert to base64 or other ?

Thanks and regards,
Shadders.
 
Shadders said:
such that the file is not stripped of those aspects that strip removes
Click to expand...
What are you talking about?
If openssl could do what you seem to think it can, why would anybody go to the trouble of writing custom tools to do it?
 
prpr said:
What are you talking about?
If openssl could do what you seem to think it can, why would anybody go to the trouble of writing custom tools to do it?
Click to expand...
Hi,
from the wiki link you provided :
"This utility removes portions of a recording (*.TS File) that aren't required and can account for up to 20% of its space,"
I did not want to strip out any information.

If the transport stream is block encoded, the openssl can decrypt. I just checked the linux-stripts in a text editor - seems to use openssl libraries. Nothing about AES, but DES is mentioned, and padding.

If anyone knows if the key (MAC + Serial Number) are used unpadded etc., ascii or base64, then can you let me know.

Thanks and regards,
Shadders.
 
I don't think stripts strips anything other than encryption when the decryption option is used. The top-level description may be misleading, since decryption was a later addition once the scheme was discovered.
 
You must log in or register to reply here.
Back
Top