[App] SamyGO NoDRM E/F (MST only)

[sectroyer]

Unfortuntely, that stops me at another stage: Although 99_91_pvr_NoDRM.init requests transition mode, NoDRM.log always reports "Pernament mode!". I did not yet manage to start it in Transition mode, but that would be a different story.

SpoilerShow

Code: Select all

root@(none) init.d $ samyGOso -p $( pidof exeTV || pidof exeDSP ) -r -l /mnt/opt/privateer/usr/libso/libNoDRM.so -d transition
Injecting '/mnt/opt/privateer/usr/libso/libNoDRM.so' resident: '1' mprotect: 0x41e96f80
dlopen: 0x42158c5c
dlclose: 0x42158cf0
dlsymaddr: 0x42158d50
pc=41fc4654 lr=41fc4638 sp=beb75e80 fp=80
r0=3f054a4 r1=80
r2=1 r3=0
stack: 0xbeb56000-0xbeb77000 length = 135168
executing injection code at 0xbeb75d4c
library injection completed!
succeeded.
root@(non) init.d $ cat /dtv/NoDRM.log
[NoDRM] SamyGO NoDRM v0.3.9 - (c) bugficks 2013
[NoDRM] Pernament mode!
[NoDRM] DRM will be enabled only for entries FROM /mtd_rwcommon/NoDRM.db !
[NoDRM] _Z26_SdPVR_Record_HandleStreamhh [0x421e4994].
[NoDRM] _Z27MApi_PVR_Playback_EnableDRMh [0x42ba5e78].
[NoDRM] _Z31MApi_PVR_Playback_SetDRMPlayKeyPhm [0x42ba5e9c].
[NoDRM] _Z28MApi_PVR_Record_SetDRMRecKeyPhm [0x42ba5f9c].
[NoDRM] SdPVR_Record_HandleStream found at: 0x421e4994
[NoDRM] Patching CMP R2, #1 found at 0x421e4a5c
[NoDRM] init done...

(Sorry again, coloring doesn't seem to work in code env. This is just to show that CMD was started with parameter transition, but log states Pernament, anyway.

And of course you ARE using samyGOso 1.2.4 or newer ?

PS, by the way, should someone come across this thread and wonder:
I just noticed that cksum does NOT create a CRC40. It's really a CRC32, but the output isn't in hex; it's in decimal. Hence the longer string.
And: The DRM Key listed in NoDRM.log and in *.key file actually DO match. Just some "reworking" needs to be done, as e.g. "0xac2175d0, 0xcc79bb2e, 0xb4b9963c, 0x5b52021b" becomes d0 75 21 ac 2e bb 79 cc - 3c 96 b9 4b 1b 02 52 5b.

Really, really no fucking idea what you are talking about It IS CRC32 and It IS hex No point in guessing and "reversing" my lib, you have source

[rootmysamynow]

And of course you ARE using samyGOso 1.2.4 or newer ?

I certainly do hope so...
How can I determine to be sure?
In /mnt/samygo.log and /mnt/sam.log, I didn't find a reference, options "--help" or "--version" don't work for SamyGOso, and my search here in this forum did not yield a useful result (that disgraces my search capabilities only, definitely NOT those of this forum!).

After almost two years with a "Skype-like root" that enabled only access for PVRDecoder, I noticed the "new" method in thread viewtopic.php?f=63&t=10705, and applied it last friday with the files attached to that thread's first post.

On my TV, there are in fact two instances of samyGOso:

Code: Select all

root@(none) init.d $ ls -l `find / name samyGOso -print `
-rwxr-xr-x    1 root     0            24329 Sep 13  2013 /mnt/opt/privateer/usr/bin/samyGOso
-rwxr-xr-x    1 root     0            18487 Jan  1 00:16 /mtd_rwcommon/samyGOso

but the first is the active one, I guess:

Code: Select all

root@(none) init.d $ which samyGOso
/mnt/opt/privateer/usr/bin/samyGOso

plus /mtd_rwcommon isn't in $PATH.

Please don't worry about my text regarding CRC32 and so on. I did NOT try to reverse anything or so. I was simply looking for a way to fill the NoDRM.db with correct values for those 120+ existing encrypted recordings, without selecting every single recording in TV's recordings browser, and picking the values from NoDRM.log. For that, I thought that busybox's cksum tool came in quite handy, and did not notice at first that this tool shows the calculated CRC32 in decimal notation.

Anyway:
Thank you so much for all the work you (and others here) put in providing those magical tools that make the S*****g TV set usable for recording in the end!

[zoelechat]

Code: Select all

Sep 13  2013

I can already tell you it's too old. Anyway, don't ask (y)ourself the question and update to latest as advised in EVERY lib procedure.

1. First install latest samyGOso as usual, if needed.

[rootmysamynow]

Oh dear, stupid me...

Thanks for pointing me in the right direction...

The "smaller" one was in fact the most recent one. And with that samyGOso in place (and a TV reboot), NoDRM now is reported in Transition mode, and it actually works perfectly well for old encrypted and recent unencrypted (added to NoDRM.db) recordings.

It was all my fault to expect that recent files downloaded recently from that other rooting thread mentioned would actually provide recent data in them...
That other thread actually did not have the line "install latest samyGOso" , and I therefore assume that lots of other things in the files provided are also not at their latest "state of knowledge", like e.g. the configuration needed to successfully enable ssh access (which still does not work with the "new" samyGOso). This is going to be my next peril (or should I state "endeavour"?).

Perhaps it would be a nice addition to that thread's first post: A note that the contents of samyext4.img.F.zip linked there are utterly outdated, and require a complete rework before they can safely be used for any task other than those implemented (although undocumented) already.

But please don't get me wrong here: This is all MY fault, not the one of any other person.
And please accept my apologies for bothering you with still the same known issue that so many other persons also already encountered.

Yet another PS to those interested:
If the samyGOso does not reveal its version once called with unsupported parameters or with none, and no version information is given, then you can conclude for sure that it's too old. Recent samyGOso builds appear to report their version info in such a case, e.g.

Code: Select all

root@(none) init.d $ samyGOso --version
samyGOso: invalid option -- '-'
usage: samyGOso [-p PID ...
samyGOso v1.2.4 (c) bugficks 2013, sectroyer 2014

[zoelechat]

We're not going to release a new img version each time every little stuff gets an update
Anyway you're right, not our fault if users don't read 1st posts carefully

[keniutek]

I can`t copy libNoDRM.so to /mnt/opt/privateer/usr/libso , i have 553 error.Any ideas ?

[edytibi]

This is not a problem of the App itself, but the resulting TS files, non-encrypted, despite the fact they contain a stream with subtitles, when playing them from another USB storage than the one where they were recorded on (the recording storage is small and I move some of the recordings to a playback storage to make room) the TV will not display the subtitles and all subtitle options from the menu are disabled.
Passing the TS through "TS Doctor" didn't help, neither remuxing the TS to MKV.Media Info reports this:
"
ID : 3436 (0xD6C)
Menu ID : 343 (0x157)
Format : DVB Subtitle
Codec ID : 6
Duration : 1h 31mn
Delay relative to video : 2s 635ms"

I found nothing about this on the forum.How come the TV can play back just fine the subtitles when the TS is on the "Recordings" Storage and it doesn't "see" the subtitles stream when the TS is used from a different USB storage? Is there any fix for this?I'm sick of using an OCR (Subtitle Edit) to convert them to SRT.
The resulting TS file play fine with subtitles on an old and crappy Philips TV that don't even have a PVR function.On the PC there's no problem, either.
Thank you!
TV: UE32F6400 firmware 1113 rooted with donor method.

[sectroyer]

Use bigger recording

[zoelechat]

What's that got to do with the price of tea?
Samsung media player simply doesn't support DVB subtitles, they're supported only in live TV and PVR.

[sectroyer]

What's that got to do with the price of tea?
Samsung media player simply doesn't support DVB subtitles, they're supported only in live TV and PVR.

He said he has to switch usb because of size. Once bigger usb no more problem