SamyGO

you can't download it from this post?
viewtopic.php?f=22&t=2820&start=200#p34737

NeoMoucha wrote:you can't download it from this post?
viewtopic.php?f=22&t=2820&start=200#p34737

uh havnt saw this one . trying to do this now. thanks for now :9

wow. it works... cant believe its so fn easy. i spent nights on this... finding a solution. many thanks!

andi wrote:An updated version of DeSTRoi is available.
Changes in version 1.3.3:
- Re-enabled and fixed on the fly FTP decoding (now using small memory buffer)
- Added an option to preserve the original filename that some find it useful
- Various GUI tweaks and minor bugfixes

Annoying bug: even if DeSTRoi says it didn't find any key in MDB (because the recording is unencrypted), it still "decrypts" it ==> resulting file is corrupt and unusable.
Expected behavior: it should skip decrypting and just download the file as is

My settings:
- key retrieval: MDB
- decrypt AF: ON
- decrypt on the fly: ON

Spoza wrote: Annoying bug: even if DeSTRoi says it didn't find any key in MDB (because the recording is unencrypted), it still "decrypts" it ==> resulting file is corrupt and unusable.
Expected behavior: it should skip decrypting and just download the file as is

Something is wrong with your files. According to transport stream specification, the first two bits of the fourth byte in the header indicate encryption. '00' means it is unencrypted. I have checked the source code and DeSTRoi decrypts only if those two bits are non-zero:
if ((input[3] & 0xC0) != 0x00)
{
...
So, the behaviour is correct. Anyway, why do you need DeSTRoi at all? You have unencrypted files and you wish to keep original names! Just use FTP client.

Blame Samsung(*) for incompatibility of the files, not me... (it's the same situation with the Adaptation Field - it's not supposed to be scrambled according to the spec, but my files do have the field scrambled...hence the extra "decrypt AF" option for owners of such TVs).
So, please add a second check: if there is no key found, do not try to decrypt even if it may look like it should be done.

And why do I use DeSTRoi?
Because I often have a MIXTURE of encrypted and unencrypted recordings - some recordings are made during the day when TV is off (i.e. those are recorded scrambled) and some are made when TV is on, i.e. SamyGO was started ==> those recordings are unencrypted. And since there is no way to distinguish between encrypted and unencrypted recording, I select ALL new recordings in DeSTRoi and copy them all at once, expecting that the encrypted ones (i.e. where key is found in their MDB) will be decrypted; the rest should be just copied 1:1.

(*)
Maybe it's not Samsung, but SamyGO... the unencrypted recordings are result of a SamyGO patch, so maybe the TV probably still thinks that it records with encryption, hence the two non-zero bits...
That's a question for the makers of the "unencrypted recordings patch".

I haven't checked if the 2 bits are cleared, but apparently, after having decrypted a file with DRMDecrypt (not Destroi, that I haven't tried), and replaced the unencrypted file on the TV, the TV can't play it, and says it is encrypted for another TV! I have to also remove the key from the MDB file (fill the 16 bytes of the key with nulls) and the TV accepts to play the unencrypted file. So, obviously, the TV tries to decrypt the file anyway, at least if the MDB file has not been patched. I'm not sure, but I wouldn't be surprised if it decrypts it anyway, but the decrypting has no effect when the key is null.

rol wrote:I haven't checked if the 2 bits are cleared, but apparently, after having decrypted a file with DRMDecrypt (not Destroi, that I haven't tried), and replaced the unencrypted file on the TV, the TV can't play it, and says it is encrypted for another TV! I have to also remove the key from the MDB file (fill the 16 bytes of the key with nulls) and the TV accepts to play the unencrypted file. So, obviously, the TV tries to decrypt the file anyway, at least if the MDB file has not been patched. I'm not sure, but I wouldn't be surprised if it decrypts it anyway, but the decrypting has no effect when the key is null.

Please check the 2 bits. In my case, when using the SamyGO patch to disable encryption on the device directly, the recorded file is unencrypted, the 2 bits are zero and it plays fine. However, the 16 bytes of the key in MDB file are not nulls.

Just to complete the picture:
On my TV the unencrypted recording
- the 2 bits are non-zero (thanks andi for finding out)
- the 16-byte key in MDB is zero

There is SO MUCH confusion... why the makers of the patch just don't properly document in details what it does and how it works?!

Spoza wrote:Just to complete the picture:
There is SO MUCH confusion... why the makers of the patch just don't properly document in details what it does and how it works?!

You should better ask why Samsung force us to use such patches