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: 1078167" data-attributes="member: 414304"><p>Hi [USER=410643]@fsphil[/USER] ,</p><p></p><p>Thanks for your message.</p><p></p><p></p><p></p><p>Well, I have two problems, the second might be caused by the first.</p><p></p><p>First problem: on my 2010 core i5 PC, whatever standard I use, I can't go beyond 10-13Msps if I'm lucky. If I go above this threshold, even with the test pattern, the video signal is not stable and the decoder can't lock. I suspect my USB2 is not working real fast. My hackrf is directly connected to the USB ports, no hub. Even with a hub, I see the same issue. I can't figure what's happening. On a beefier PC with USB3 controller, 16 Msps runs smoothly.</p><p></p><p>Second problem: Using [USER=243342]@Captain Jack[/USER]'s fork, while sending syster in SECAM through the decoder, the encrypted image looks fine, but the decoded image is strongly tainted in green (as if chroma almost disappeared). This doesn't happen in PAL even with my Msps limitation (I noticed the decoder can lock as low as 8Msps input). I'm using a French decoder with a French written EURODEC label at the rear.</p><p></p><p></p><p>Oh, really? Could this explain the greenish tainted picture I observed?</p><p></p><p></p><p></p><p>Preamble: the following reasoning may be totally wrong, given the experience both [USER=243342]@Captain Jack[/USER] and you have in VBI hunting, that I clearly don't. You are the bosses, I'm just a semi-noob suggesting things <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>To me, it seems that the feasibility of randomizing the VBI data from scratch, depends on the amount of bits to shuffle and if a result can actually be seen, ie: generating a randomized bitstream that is "valid enough" both in space and time. This might lead to a fair amount of combinations to explore.</p><p></p><p>Intuitively, the simplest analogy I can think of is: if I were digging a mine, I would pickax where and when gold was last seen.</p><p></p><p>In the case of qualifying the VBI bitstream that triggers SmartCrypt decoding , I'd start looking at a captured VBI sequence that is "known to work, yet for unknown reasons". I would trim it left and right until it doesn't work anymore. This would delimit the time axis to investigate.</p><p>Then, knowing the overall syntax of Nagravision VBI, I would crudely probe bit fields sections (ie set them all ones or all zeros) of this working VBI sequence to check which of them are 100% required to engage SmartCrypt. This would delimit the space axis to investigate.</p><p>Finally, with a reduced time-space "known to work" VBI bitstream, I would start a finer observation with selected randomization, to hopefully qualify the role of each bit.</p><p></p><p>Is this approach reasonable to you?</p><p></p><p></p><p></p><p>Unfortunately, I think it's something different.</p><p>I already tried to replicate s,r from first field to second field, one way or the other, without success. it doesn't look like a frame/field s,r repeat (which I believe either Leitch or Videocrypt S can do).</p><p></p><p>To illustrate my findings, I just did a capture of the decoder scart output with syster.c vbi[5] bit 3 forced to 1 ( [ICODE] |= 0x8 [/ICODE]).</p><p>Both fields of a same frame are still out of order but each of them has a better chroma and looks more intelligible than the encrypted output.</p><p>Please see below.</p><p>command line: [ICODE]./hacktv -f 503250000 test -g 30 -m g -s 10000000 --syster [/ICODE]</p><p></p><p>Encrypted input is :</p><p>[ATTACH=full]126769[/ATTACH]</p><p></p><p>As fields:</p><p></p><p>[ATTACH=full]126770[/ATTACH]</p><p></p><p>"Not quite decrypted output" with vbi mode bit 3 forced to 1:</p><p>[ATTACH=full]126771[/ATTACH]</p><p></p><p>Which is more intelligible than the encrypted frame.</p><p></p><p>Then, as fields:</p><p></p><p>[ATTACH=full]126772[/ATTACH]</p><p></p><p></p><p>Each field is still partly scrambled, but the chroma consistency is stronger and the readability of "HACKTV" + time has increased, compared to the encrypted fields. Overall, the line order feels "better" than in the encrypted input.</p><p>I'm still wondering if this bit is invoking a particular permutation table I don't know of, or a particular way of using the existing permutation table.</p><p></p><p>Great, I will give it a shot!</p><p>By the way, do you have an example of valid vbidata.dat ? So I can compare with my own output and be sure I'm producing relevant data.</p><p></p><p>Thanks!</p></blockquote><p></p>
[QUOTE="homercartman, post: 1078167, member: 414304"] Hi [USER=410643]@fsphil[/USER] , Thanks for your message. Well, I have two problems, the second might be caused by the first. First problem: on my 2010 core i5 PC, whatever standard I use, I can't go beyond 10-13Msps if I'm lucky. If I go above this threshold, even with the test pattern, the video signal is not stable and the decoder can't lock. I suspect my USB2 is not working real fast. My hackrf is directly connected to the USB ports, no hub. Even with a hub, I see the same issue. I can't figure what's happening. On a beefier PC with USB3 controller, 16 Msps runs smoothly. Second problem: Using [USER=243342]@Captain Jack[/USER]'s fork, while sending syster in SECAM through the decoder, the encrypted image looks fine, but the decoded image is strongly tainted in green (as if chroma almost disappeared). This doesn't happen in PAL even with my Msps limitation (I noticed the decoder can lock as low as 8Msps input). I'm using a French decoder with a French written EURODEC label at the rear. Oh, really? Could this explain the greenish tainted picture I observed? Preamble: the following reasoning may be totally wrong, given the experience both [USER=243342]@Captain Jack[/USER] and you have in VBI hunting, that I clearly don't. You are the bosses, I'm just a semi-noob suggesting things :) To me, it seems that the feasibility of randomizing the VBI data from scratch, depends on the amount of bits to shuffle and if a result can actually be seen, ie: generating a randomized bitstream that is "valid enough" both in space and time. This might lead to a fair amount of combinations to explore. Intuitively, the simplest analogy I can think of is: if I were digging a mine, I would pickax where and when gold was last seen. In the case of qualifying the VBI bitstream that triggers SmartCrypt decoding , I'd start looking at a captured VBI sequence that is "known to work, yet for unknown reasons". I would trim it left and right until it doesn't work anymore. This would delimit the time axis to investigate. Then, knowing the overall syntax of Nagravision VBI, I would crudely probe bit fields sections (ie set them all ones or all zeros) of this working VBI sequence to check which of them are 100% required to engage SmartCrypt. This would delimit the space axis to investigate. Finally, with a reduced time-space "known to work" VBI bitstream, I would start a finer observation with selected randomization, to hopefully qualify the role of each bit. Is this approach reasonable to you? Unfortunately, I think it's something different. I already tried to replicate s,r from first field to second field, one way or the other, without success. it doesn't look like a frame/field s,r repeat (which I believe either Leitch or Videocrypt S can do). To illustrate my findings, I just did a capture of the decoder scart output with syster.c vbi[5] bit 3 forced to 1 ( [ICODE] |= 0x8 [/ICODE]). Both fields of a same frame are still out of order but each of them has a better chroma and looks more intelligible than the encrypted output. Please see below. command line: [ICODE]./hacktv -f 503250000 test -g 30 -m g -s 10000000 --syster [/ICODE] Encrypted input is : [ATTACH type="full"]126769[/ATTACH] As fields: [ATTACH type="full"]126770[/ATTACH] "Not quite decrypted output" with vbi mode bit 3 forced to 1: [ATTACH type="full"]126771[/ATTACH] Which is more intelligible than the encrypted frame. Then, as fields: [ATTACH type="full"]126772[/ATTACH] Each field is still partly scrambled, but the chroma consistency is stronger and the readability of "HACKTV" + time has increased, compared to the encrypted fields. Overall, the line order feels "better" than in the encrypted input. I'm still wondering if this bit is invoking a particular permutation table I don't know of, or a particular way of using the existing permutation table. Great, I will give it a shot! By the way, do you have an example of valid vbidata.dat ? So I can compare with my own output and be sure I'm producing relevant data. 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