Log in
Register
Menu
Log in
Register
Home
What's new
Latest activity
Authors
Forums
New posts
Search forums
What's new
New posts
Latest activity
Members
Current visitors
New posts
Search forums
Menu
Log in
Register
Install the app
Install
Forums
Satellite TV receivers & systems support forums
Analogue systems
Analogue Nagravision (Syster) encoder
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="homercartman" data-source="post: 1078156" data-attributes="member: 414304"><p>Hi [USER=243342]@Captain Jack[/USER] !</p><p></p><p>Thanks a lot for your reply.</p><p></p><p></p><p></p><p>Maybe with VBI mode bits 0-1 set to b00, the decoder is attempting a specific video processing for SECAM, that doesn't really apply to PAL (hence the red and blue PAL chroma bursts)?</p><p>For example I tried D11 mode in PAL, it doesn't play nicely regarding the PAL color bursts and accentuates similar PAL chroma streaks.</p><p>After all, hacktv's Syster implementation seems only allowed to work with PAL, while studying Syster in SECAM is relevant too.</p><p>Do you know what's currently blocking hacktv --syster to work in SECAM?</p><p></p><p></p><p>That nasty little black box!</p><p>From the video you sent, I think I saw transitions from clear to lineshuffle to cut-and-rotate, but also direct transitions from clear to cut-and-rotate.</p><ul> <li data-xf-list-type="ul">Is it hard for you to reproduce the conditions that trigger the cut-and-rotate (CNR) decoding (like, a few seconds per hour), or is it actually quite easy to trigger? From the same video, it seems quite easy, but I may be wrong.</li> <li data-xf-list-type="ul">Is the decoder asking the plastic key for specific data when decoder does CNR or little time before it does? i.e, is the plastic key also playing a role in decoding CNR?</li> <li data-xf-list-type="ul">Is it already reproducible with a goldcard and your .hex file ? (hope so!)</li> </ul><p>To go further in this investigation, I think the first goal is to make those VBI glitches repeatable, then be able to narrow which VBI minimal sequence is triggering this CNR decoding, and finally further narrow this VBI sequence even more by variable-force experiments (brute and less brute).</p><p></p><p>With two hackrfs, one TX at minimum acceptable sample rate for Syster , one RX at highest possible sample rate, there are chances to achieve that.</p><p>For example:</p><ol> <li data-xf-list-type="ol">The first hackrf does hacktv PAL TX with low gain, as usual</li> <li data-xf-list-type="ol">Split the TX hackrf output in two new output lines with a tee</li> <li data-xf-list-type="ol">One of the 2 split outputs is connected to the tuner / decoder, as usual</li> <li data-xf-list-type="ol">At this stage, make sure the decoder is sometimes triggered in CNR decryption</li> <li data-xf-list-type="ol">The other split output is connected to the second hackrf in RX mode</li> <li data-xf-list-type="ol">Fingers crossed: Assuming the RX hackrf receives a signal very similar to the one received by the tuner, the RX hackrf might be recording the altered VBI data that is responsible to trigger CNR on decoder.</li> <li data-xf-list-type="ol">Just like with a video editor: replay captured PAL and narrow to the smallest possible duration that triggers CNR, dump the corresponding VBI values, progressively nullify / trim selected VBI bits until CNR decoder stops working -> one gets the minimal amount of significant VBI data to trigger CNR on Syster!</li> <li data-xf-list-type="ol">Bonus 1: If the plastic key receives specific questions from decoder when triggered in CNR mode, then with the help of a MITM Smartcard->Phoenix interface, step 7 sequence narrowing / chosen VBI processing might become automatized.</li> <li data-xf-list-type="ol">Bonus 2: with CryptImage, it should be possible to reverse the CNR decoding to deduce the cutpoints over time, and possibly make hacktv encrypt in Nagra-CNR mode at will.</li> </ol><p></p><p>I'm using a goldcard, but I'm not experiencing exactly what your video shows.</p><p>In your video, some frames are 100% decoded, some other remain 100% encrypted, and this is fixed by cycling the key in the reader.</p><p>In my case, if vbi mode bit 3 is enabled, I have ~ 50% decoded frames: each frame is never fully decrypted, but the reordered picture still provides a much better "distinguishable" content than the original unencrypted frame. I can definitely see many lines are landing exactly where they should, and PAL color is almost fully restored. It's like there is still a "veil" of badly reordered lines remaining all over the descrambled picture.</p><p>That's why I was initially wondering if vbi mode bit 3 is somehow invoking another permutation table that is close but not exactly the same as the well known primary table.</p><p>Note: I'm experimenting on a French decoder that might have never known the French permutation table 2.</p><p></p><ul> <li data-xf-list-type="ul">This might be unrelated but: with a goldcard, why did I have to enable [ICODE]#define _OPT_PIC_CARD 1[/ICODE] for my decoder to stably decode over time? If I don't enable this define, decoding only lasts ~0.5s.</li> </ul><p></p><p>The VBI mode bit 4 is controlling the choice between 12.8kHz and the secondary frequency.</p><p>I wonder if this feature was a possible "clear yet painful" VBI countermeasure to defeat the audio part of unofficial decoders that weren't looking at VBI nor had the dual carrier hardware. Supposing Syster encoders could change bit 4 several times per second along with the actual modulated sound carrier, the resulting audio from unofficial decoders (dumb 12.8kHz fixed carrier) would probably not be worth listening to ... just like a radio scanner tuned to a SSB channel, and the operator switching like crazy between LSB and USB modes: funny but barely audible <img src="https://www.satellites.co.uk/styles/default/xenforo/smilies/smile.png" class="smilie" loading="lazy" alt=":)" title="Smile :)" data-shortname=":)" /></p><p></p><p></p><p></p><p>Ok. My environment is Linux. I'll check if my capture hardware provides the /dev/vbi0 device.</p><p></p><p>I'm not sure I have such VCR with integrated TBC and I'm sure I don't have any external TBC box.</p><p>Without TBC, is the output of /dev/vbi0 still worth something?</p><p></p><p>Thanks!</p></blockquote><p></p>
[QUOTE="homercartman, post: 1078156, member: 414304"] Hi [USER=243342]@Captain Jack[/USER] ! Thanks a lot for your reply. Maybe with VBI mode bits 0-1 set to b00, the decoder is attempting a specific video processing for SECAM, that doesn't really apply to PAL (hence the red and blue PAL chroma bursts)? For example I tried D11 mode in PAL, it doesn't play nicely regarding the PAL color bursts and accentuates similar PAL chroma streaks. After all, hacktv's Syster implementation seems only allowed to work with PAL, while studying Syster in SECAM is relevant too. Do you know what's currently blocking hacktv --syster to work in SECAM? That nasty little black box! From the video you sent, I think I saw transitions from clear to lineshuffle to cut-and-rotate, but also direct transitions from clear to cut-and-rotate. [LIST] [*]Is it hard for you to reproduce the conditions that trigger the cut-and-rotate (CNR) decoding (like, a few seconds per hour), or is it actually quite easy to trigger? From the same video, it seems quite easy, but I may be wrong. [*]Is the decoder asking the plastic key for specific data when decoder does CNR or little time before it does? i.e, is the plastic key also playing a role in decoding CNR? [*]Is it already reproducible with a goldcard and your .hex file ? (hope so!) [/LIST] To go further in this investigation, I think the first goal is to make those VBI glitches repeatable, then be able to narrow which VBI minimal sequence is triggering this CNR decoding, and finally further narrow this VBI sequence even more by variable-force experiments (brute and less brute). With two hackrfs, one TX at minimum acceptable sample rate for Syster , one RX at highest possible sample rate, there are chances to achieve that. For example: [LIST=1] [*]The first hackrf does hacktv PAL TX with low gain, as usual [*]Split the TX hackrf output in two new output lines with a tee [*]One of the 2 split outputs is connected to the tuner / decoder, as usual [*]At this stage, make sure the decoder is sometimes triggered in CNR decryption [*]The other split output is connected to the second hackrf in RX mode [*]Fingers crossed: Assuming the RX hackrf receives a signal very similar to the one received by the tuner, the RX hackrf might be recording the altered VBI data that is responsible to trigger CNR on decoder. [*]Just like with a video editor: replay captured PAL and narrow to the smallest possible duration that triggers CNR, dump the corresponding VBI values, progressively nullify / trim selected VBI bits until CNR decoder stops working -> one gets the minimal amount of significant VBI data to trigger CNR on Syster! [*]Bonus 1: If the plastic key receives specific questions from decoder when triggered in CNR mode, then with the help of a MITM Smartcard->Phoenix interface, step 7 sequence narrowing / chosen VBI processing might become automatized. [*]Bonus 2: with CryptImage, it should be possible to reverse the CNR decoding to deduce the cutpoints over time, and possibly make hacktv encrypt in Nagra-CNR mode at will. [/LIST] I'm using a goldcard, but I'm not experiencing exactly what your video shows. In your video, some frames are 100% decoded, some other remain 100% encrypted, and this is fixed by cycling the key in the reader. In my case, if vbi mode bit 3 is enabled, I have ~ 50% decoded frames: each frame is never fully decrypted, but the reordered picture still provides a much better "distinguishable" content than the original unencrypted frame. I can definitely see many lines are landing exactly where they should, and PAL color is almost fully restored. It's like there is still a "veil" of badly reordered lines remaining all over the descrambled picture. That's why I was initially wondering if vbi mode bit 3 is somehow invoking another permutation table that is close but not exactly the same as the well known primary table. Note: I'm experimenting on a French decoder that might have never known the French permutation table 2. [LIST] [*]This might be unrelated but: with a goldcard, why did I have to enable [ICODE]#define _OPT_PIC_CARD 1[/ICODE] for my decoder to stably decode over time? If I don't enable this define, decoding only lasts ~0.5s. [/LIST] The VBI mode bit 4 is controlling the choice between 12.8kHz and the secondary frequency. I wonder if this feature was a possible "clear yet painful" VBI countermeasure to defeat the audio part of unofficial decoders that weren't looking at VBI nor had the dual carrier hardware. Supposing Syster encoders could change bit 4 several times per second along with the actual modulated sound carrier, the resulting audio from unofficial decoders (dumb 12.8kHz fixed carrier) would probably not be worth listening to ... just like a radio scanner tuned to a SSB channel, and the operator switching like crazy between LSB and USB modes: funny but barely audible :) Ok. My environment is Linux. I'll check if my capture hardware provides the /dev/vbi0 device. I'm not sure I have such VCR with integrated TBC and I'm sure I don't have any external TBC box. Without TBC, is the output of /dev/vbi0 still worth something? Thanks! [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
Satellite TV receivers & systems support forums
Analogue systems
Analogue Nagravision (Syster) encoder
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
Accept
Learn more…
Top