[PC] SamyGO PVRDecoder for E/F/H series - Version 1.8.2.53

[Lordbyte]

@JamesZ,

I believe you have a very valid point here.
It is me that wrote that guide on forum, that made you install that Linux Reader.
In my defence, I had no idea it was bugged. I will consider removing that part of the guide.
You will notice in the guide that I offer an "alternative" link ..
Could you try all your operations using that one, and see if that will fail after 5 GB too ?

[JamesZ]

You're welcome, and I will try to do this alternative test. Could you provide the link near here? I think I found the Guide but not the link. The forum is big and I'm not good at finding things.

[zoelechat]

Second link in first post: http://driesve.tumblr.com/post/15607941 ... -windows-7
No idea if it will work on Win 8.1 (to be confirmed). Otherwise there are other alternatives, such as UFS explorer (confirmed) or Ext2Read (to be confirmed?), and probably more (Paragon ExtFS...)

[sectroyer]

I agree, of course. But LinuxReader was mentioned in this forum for use of the PVRDecoder offline method. I think I downloaded it from an official site.
Don't you think, programs should handle bad data gracefully, without crashing?

Well LordByte can easily detect that and display "Your input file as incorrect. App will do NOTHING! No decryption will be performed:)"... But for me (even when I was still a noob) such information wouldn't be very helpful and in essence meant the same thing as CRASH

[JamesZ]

Installed Ext2Fsd-0.53.exe on Windows 7 and Windows Vista, retrieved >9GB .srf and .key file, and it was successfully decrypted by drmdecrypt, and both results were playable with Windows Media Player on Windows 7 (WMP on Vista could not play .ts). It is easy to install and easy to use. No patches are needed for this version, at least for the tested readonly access. The link above refers to an outdated version. The Samsung formatted stick is recognized as EXT3 (my QNAP NAS says its EXT4).

I had also installed fsproxy-1.0rc2_setup.exe on a different Windows 7 installation when I tried to read a Samsung VFAT formatted stick that seams to be in some XFS format. This did not recognize the stick from the F-Series, nor from the LT27A750 Monitor (seems to contain D-Series FW), or I did not understand how to configure it.

This is for information only! I have been asked for this test and the purpose of my effort is to help the developers and their users (and customers aka donors). My final entry in this thread.

[Lordbyte]

@JamesZ
Thank you for services performed for this team.

The PVRDecoder will now compare recieved filesize with expected filesize, and report size mismatch, as pr. your suggestion.
Your contribution will also result in an updated guide for EXT(n) windows drivers (still first post here in thread).
In other news, - the PVRDecoder will support H-series after this Christmas update
This update will happen just around Christmas (this year).

[ScepticFan]

Maybe a clue to Key generation of F-Series? Has anybody tried this?

I deleted all .mdb files (and the dropped .key files) on a usb stick with no longer needed data.

The TV marks the files as unusable. It can't play them anymore.

A logical conclusion is that (only?) the .mdb files are used for key generation. May try key dropping for .srf file with invalid data but valid .mdb.
Maybe there is just one more encryption step from .mdb to .key.
But some TV specific data will still be involved, maybe it is e.g. the MAC address.
So root access and key dropping is still required, unless this master key is known and same aes encryption used.

[Lordbyte]

I deleted all .mdb files (and the dropped .key files) on a usb stick with no longer needed data.
The TV marks the files as unusable. It can't play them anymore.

I suspect TV is bothered by the missing *.inf that contain needed information .. such as title, for example.
The PVRDecoder would have same problem. No .inf, no recording

A logical conclusion is that (only?) the .mdb files are used for key generation. May try key dropping for .srf file with invalid data but valid .mdb.

No, actually, the *.mdb does NOT contain the key (anymore). As Samsung launched the E(S)-model, they changed the game entirely.
The key is now placed in a file with extension .ss (secure storage) !

This .ss file is then encrypted by another key derived from some SECURE function inside TV.
This secure function inside TV use some internal hardware-module (as i understand it), and extracting
the algorithm and masterkey from the TV is currently considered impossible !

So, the only way to get keys for decryption of individual recordings, is to "cheat" TV into thinking that the
user just ordered a playback of a recording, and the TV will produce the key needed, and THEN the key is up for grabs in TV memory.
At that point the key gets copied to a .key file, and we are good to go .. But to trick TV into producing key, and allow the key to be
extracted requires "total" control with the software running on TV ... hence the requirement for "root".

Maybe there is just one more encryption step from .mdb to .key.

Nope, sorry ... .mdb contain absolutely NO key .. Samsung got wiser .. now using secure storage (.ss)

But some TV specific data will still be involved, maybe it is e.g. the MAC address.
So root access and key dropping is still required, unless this master key is known and same aes encryption used.

Nice theory, but no cigar .. sorry

[sectroyer]

Good that on H there will be absolutely NO problems with offline decoding

[ScepticFan]

Hi Lordbyte and sectroyer, thanks for the replies.

.mdb, .ss and .inf are needed to be present for successful key dropping.

no .mta -> sound only on TV, black video, key dropped is valid
no .cip -> TV play only ~1sec, key dropped is valid
no .inf -> TV play fails, key dropped is empty
no .srf -> not checked, key can't depend on it because would be circular dependency

I deleted all .mdb files (and the dropped .key files) on a usb stick with no longer needed data.
The TV marks the files as unusable. It can't play them anymore.

I suspect TV is bothered by the missing *.inf that contain needed information .. such as title, for example.
The PVRDecoder would have same problem. No .inf, no recording

A logical conclusion is that (only?) the .mdb files are used for key generation. May try key dropping for .srf file with invalid data but valid .mdb.

No, actually, the *.mdb does NOT contain the key (anymore). As Samsung launched the E(S)-model, they changed the game entirely.
The key is now placed in a file with extension .ss (secure storage) !

This .ss file is then encrypted by another key derived from some SECURE function inside TV.
This secure function inside TV use some internal hardware-module (as i understand it), and extracting
the algorithm and masterkey from the TV is currently considered impossible !

So, the only way to get keys for decryption of individual recordings, is to "cheat" TV into thinking that the
user just ordered a playback of a recording, and the TV will produce the key needed, and THEN the key is up for grabs in TV memory.
At that point the key gets copied to a .key file, and we are good to go .. But to trick TV into producing key, and allow the key to be
extracted requires "total" control with the software running on TV ... hence the requirement for "root".

Maybe there is just one more encryption step from .mdb to .key.

Nope, sorry ... .mdb contain absolutely NO key .. Samsung got wiser .. now using secure storage (.ss)

But some TV specific data will still be involved, maybe it is e.g. the MAC address.
So root access and key dropping is still required, unless this master key is known and same aes encryption used.

Nice theory, but no cigar .. sorry

Seems I have triggered a response that reveals information I was curious about: how key dropping is done.

I won't go any further, because Samsung certainly is observing this forum.
I like Samsung devices, have ~8 of them, but neither their support nor their priorities (hampering your work).
I understand they have obligations because of HDMI/HCCP and CI+, but fortunately they are mostly lazy.
Full compliance is theoretically impossible to my believe, would require devices to be strengthened like military crypto gear.

I love your work!