Humax recording encryption

All of the the decryption tricks for HD files could be done via the web interface I think

Yep, that shouldn't be a problem. Nice work!
I think a separate package might be a good idea to periodically update the dms_cds.db - I presume that database is routinely updated by a background thread so the flags will probably be set back occasionally. auto-unprotect only processes new files and only once.

Any ideas for a package name?
 
I'm not sure it does get updated... certainly a recording I made on the 24th July is still marked as HD in the Humax onscreen "media" GUI, plays back and can be wget'd via the DNLA trick unencrypted - I would guess the db entry is created when the recording starts.. and the only update is when the file is deleted.
 
Right, to have a play I tried this:

Code:
E:\SoftwareVault\Utils>wget http://192.168.1.65:9000/web/media/185.TS
--2011-08-11 20:42:28--  http://192.168.1.65:9000/web/media/185.TS
Connecting to 192.168.1.65:9000... connected.
HTTP request sent, awaiting response...

185 I identified from the SQL dump as being an episode of I'm Sorry I Haven't A Clue. Then it just sits there.

I'm Sorry I Haven't A Clue
 
Right, to have a play I tried this:

Code:
E:\SoftwareVault\Utils>wget http://192.168.1.65:9000/web/media/185.TS
--2011-08-11 20:42:28--  http://192.168.1.65:9000/web/media/185.TS
Connecting to 192.168.1.65:9000... connected.
HTTP request sent, awaiting response...

185 I identified from the SQL dump as being an episode of I'm Sorry I Haven't A Clue. Then it just sits there.

I'm Sorry I Haven't A Clue

That's exactly the same that's been happening to me as well.
 
Cracked it! I got the media ID wrong (it's quite confusing). Once I worked out it should be 184.TS it started downloading like a charm.
 
Cracked it! I got the media ID wrong (it's quite confusing). Once I worked out it should be 184.TS it started downloading like a charm.

What's the issue with the MediaID? How come you ended up downloading 184.TS and not 185.TS?

Another random test worked for me this time and I'm wondering what the problem was.
 
There was no 185.TS. I made a mistake reading the SQL dump. I'm compiling a how-to but I'm hung up on some details - I'm hoping the media ID can be worked out without using the modified software and then the modification-averse brigade have a way in.
 
I have found the DNLA server a bit hit and miss if you've been looking in the sqlite databases - even just taking a dump of the contents via webif - file locking issues? anyway a reboot fixes it I've found.

To move a discussion from another thread back to here: I've tested again decypting a SD ts file and replacing it in place of the original and yup it doesn't play back any more giving a "The channel is scrambled or not available" error. I'm guessing it must be something in the hmt file - I've found this http://foxsatdisk.wikispaces.com/.hmt+file+format breakdown of the file format and 0x368 seems to be be something worth looking at - however the file format seems different on the HDR.

af123 you must have done a lot of the hardwork already in understanding the file format for the hmt tool - is the source code anywhere or a breakdown of the HDR file format?
 
af123 you must have done a lot of the hardwork already in understanding the file format for the hmt tool - is the source code anywhere or a breakdown of the HDR file format?

Raydon did all the hard work, I don't know if he has published his finds anywhere though.

It would be worth copying an SD recording to an external disk (or virtual disk) and seeing what changes in the HMT file.
 
Good thinking! found it... change 0x03 to 0x02 at 0x28E - needed to reboot the Humax but it plays back now - awesome! - do you have any appetite to add this to the hmt util? or do I have to install another toolchain hehe ;)
 
Will do. I should have some time over the weekend to catch up on things. I have a fairly long list of updates to do!
 
Good thinking! found it... change 0x03 to 0x02 at 0x28E - needed to reboot the Humax but it plays back now - awesome! - do you have any appetite to add this to the hmt util? or do I have to install another toolchain hehe ;)
Does that mean you can play back a decrypted file in place?
 
Given that we have (or nearly have) mechanisms for copying files (inc HiDef) across the network and streaming to a DLNA client, I wonder whether we need to decrypt in place? Is this an opportunity to rationalise the provision? Now we have native streaming support, is Mediatomb necessary?

On the same theme, do we need to be running auto-unprotect if the equivalent functionality could be built into the "download" button?

Update: I've convinced myself that auto-unprotect is necessary so that HiDef recordings can be streamed/downloaded to a non-secure client or OPT+ copied to external drive.
 
Good thinking! found it... change 0x03 to 0x02 at 0x28E - needed to reboot the Humax but it plays back now - awesome! - do you have any appetite to add this to the hmt util? or do I have to install another toolchain hehe ;)

I've added this as +/-encrypted in hmt 1.0.7.
 
I've updated auto-unprotect so that in addition to removing the Enc flag from new recordings, it also updates the DLNA server database so that content is streamed without DTCP (thanks to ratx for the method :D)

Just streamed Torchwood in HD to XBMC on my laptop using the stock DLNA server :cool:
 

Will this work retrospectively on files that have already had their enc flags cleared by the previous version of auto-unprotect?
 
I don't think so, as the script won't check files older than the /mod/.unprotect.last and even then, I would expect it to only check files that have still have the enc flag set.

Having updated the auto-unprotect package, I have deleted said dot file. I have then reset the enc flag and waiting to see if it allows HD streaming.

af123 - does the latest webif "download" button do the correct thing now or do we have to use wget?
 
Back
Top