Analogue Nagravision (Syster) encoder

Captain Jack

Captain Jack

Модератор
Staff member
Messages
11,013
My Satellite Setup
See signature
My Location
North Somerset
Splitting off from the MAC resurrection thread where there was a short of Videocrypt and Nagravision encryption, I thought it would be a good idea to actually decrypt the transmission!

Having tried various software Nagravision descramblers, I found that none at all were even thinking about decoding it. This is because the line shuffling that I was doing was completely random, whereas software decoders relied on a real known substitution table along with initial trial-and-error line comparison to find two randomly generated values at the encoder end.

Following the document here, along with some source codes available elsewhere, I managed to recreate a semi-working encoder, which follows the steps of the real one - using the substitution table. Ran the encrypted (in real time) stream through HackRF and captured it with a capture card through the likes of MoreTV and ... it worked! It's not 100% decryption (or rather encryption) as I am only encrypting a single frame at a time, whereas in a real encoder, the top 32 lines (or 64 counting odd and even fields) from the previous frame are shifted to the bottom of the existing frame. The decoder then rearranges that into a single frame through the use of buffers. As a result, the top part of the image is still encrypted but is still very watchable.

Getting close for Sats UK's own channel - subscription only £99.99 per month :D

Here's the result. Top image is the encrypted transmission from HackRF and bottom is the decrypted one.

Screenshot 2017-06-29 06.56.13.jpg

Would be great to actually have it working on a real decoder but without access to one, it will be tricky.

Hoping to potentially recreate it with Videocrypt though...
 
Captain Jack

Captain Jack

Модератор
Staff member
Messages
11,013
My Satellite Setup
See signature
My Location
North Somerset
Been working some more on the 'encoder' (yes, bored...). Have now managed to get the encoded image to display near perfect (ignoring the colour). Still have one or two stray lines from somewhere but it would be very watchable :)

nagra.jpg
 
Analoguesat

Analoguesat

Administrator
Staff member
Messages
48,064
Location
Scottish Borders
My Satellite Setup
TM 5402HD
Skybox F3
Sky+ UK.
My Location
Scottish Borders
Excellent.

5 years after analogue satellite closed down we still have interesting threads popping up in the section! :D
 
2cvbloke

2cvbloke

Bulbs need shelter too...
Messages
9,756
My Satellite Setup
No satellite stuff for the moment (aside from a 43cm minidish that was on the house already), Samsung SyncMaster T27B550 Smart TV & Monitor, and a few computers...
My Location
Near Pontop Pike, Co. Durham
Analogue never dies, it just becomes an amateur entertainment medium... :D
 
Analoguesat

Analoguesat

Administrator
Staff member
Messages
48,064
Location
Scottish Borders
My Satellite Setup
TM 5402HD
Skybox F3
Sky+ UK.
My Location
Scottish Borders
Analoguesat

Analoguesat

Administrator
Staff member
Messages
48,064
Location
Scottish Borders
My Satellite Setup
TM 5402HD
Skybox F3
Sky+ UK.
My Location
Scottish Borders
I was looking at the tp lists for 70W Star C2 om Lyngsat earlier - shes still carrying quite a few analogue C-band tps!
 
Captain Jack

Captain Jack

Модератор
Staff member
Messages
11,013
My Satellite Setup
See signature
My Location
North Somerset
Yep, sadly pointing nowhere near the UK. Even though I can "see" it...
 
Captain Jack

Captain Jack

Модератор
Staff member
Messages
11,013
My Satellite Setup
See signature
My Location
North Somerset
Been playing some more over the weekend to get the colour encoded correctly, or rather not touch it at all. The burst signals are not affected by Nagravision, only visible lines, which become out of phase with colour information and hence looking black and white. Restoring the lines to their original order restores colour.

Also had to get the 32 line buffer working correctly (the bit that's seen at the bottom of the encrypted video) else it was looking all out. Still a couple of stray lines but nothing major.

The decoder used is one of many software ones, which were used to decrypt real transmissions back in the day (hence the need to use Windows XP!):

 
Captain Jack

Captain Jack

Модератор
Staff member
Messages
11,013
My Satellite Setup
See signature
My Location
North Somerset
There we go... almost perfect.

 
Dave5118

Dave5118

Member
Messages
259
My Satellite Setup
1.5m Gibertini with IBU Twin
TBS 6903/6922 with EBSPro
Gigablue Quad 4K(S2X)
Edision OS Nino Pro
Starsat 2000HD Hyper
Sky Q Silver
Sky minidish with Sky Q Hybrid LNB
My Location
Nr Manchester UK
Have you tried this on the C+ channel on the 5w multistream, or do you need info int was encrypted with? I believe cryptimage is supposed to try all the permutations to rearrange the picture, but I've never tried it, plus I doubt it would work quick enough on Live TV.

Only just realised where you got your avatar from now :D
 
Captain Jack

Captain Jack

Модератор
Staff member
Messages
11,013
My Satellite Setup
See signature
My Location
North Somerset
Cryptimage still relies on a real known permutation table, which cuts down the guesswork significantly. The 5w stream is difficult to decode as only half of the screen is visible and it's too overcompressed. And they probably use an unknown permutation table (there were two known ones in existence).
 
Captain Jack

Captain Jack

Модератор
Staff member
Messages
11,013
My Satellite Setup
See signature
My Location
North Somerset
Thanks to @fsphil, there's now a partially working encoder that works with real hardware decoders. Code hasn't been committed yet but I expect it will happen fairly soon.

 
H

homercartman

Member
Messages
39
My Satellite Setup
Cubsat 50, DVBSky S960, RPi3
My Location
France
Hi @Captain Jack

Long time lurker, I've recently taken the leap and invested in a hackRF One.
I extensively tested your branch of hacktv in D11 and Nagravision mode with a Syster decoder.

There are chance all possible superlatives have already been expressed about this truly wonderful piece of software.
Both fsphil and you are one of a kind team.

Regarding Nagravision, I looked at the code and observed funny things on the decoder while experimenting on the vbi[5] (mode) bits.
Just wanted to know if this forum the right place to discuss some tech details ?

Thanks!
 
Captain Jack

Captain Jack

Модератор
Staff member
Messages
11,013
My Satellite Setup
See signature
My Location
North Somerset
Ask away!

Syster VBI is one of the least understood despite some decent documentation around (mainly from French sources). Decoders from different countries behave differently given the same data stream.

The mode byte is interesting as it determines which visual encryption to use (Syster or Discret11) as well as which sound modulation to use. There are two modes of spectrum inversion that, from what I understand, differ in what frequency to use.

Of course, the latter has little effect on decoders without audio inversion circuitry (German Premiere ones).

The rest of VBI data is also a bit of a mystery especially around which decoders and keys it likes. The code as is works well enough on French and German boxes with either a Premiere key or a pic card. It does not work as well on Polish decoders and it doesn't work at all on Russian NTV ones...
 
H

homercartman

Member
Messages
39
My Satellite Setup
Cubsat 50, DVBSky S960, RPi3
My Location
France
Hi Captain Jack

Thanks for your reply.

Indeed I wanted to get some certainties regarding the mode bytes, whether it was a blind enum or a bitfield. And a bitfield it is.

This is what I noticed:

C-like:
        //vbi[5] bits 0-1 choose encryption mode 1: d11, 2: nagra, 0:?, 3:?
        //vbi[5] bit 2: unknown / untested
        //vbi[5] bit 3 seems to say: if enc is nagravision, s,r are different ... Is it selecting another permutation table?
        //vbi[5] bit 4: if 1, inverts audio at 12.8kHz, else ? KHz if 0
        //vbi[5] bit 5: seems to ask for video decryption or not (unencrypted)
        //vbi[5] bit 6: unknown / untested
        //vbi[5] bit 7: unknown / untested
        //vbi[5] bit 8: unknown / untested
Regarding bit 3:
* with legacy permutation table, if enabled, then on my decoder, it seems part of the image is decrypted, part of the image is not. Some permutations are valid but not all. PAL color is globally restored, though.
* it doesn't look like a field-repeated "s,r" mode, where each field uses the same "s,r" list
* I tried to inject the French permutation table phase 2 in syster.c (the one that +/- kept the SECAM color line order, starting 1998), to see if it would work better with bit 3. No success.

So if bit 3 is a selection of permutation tables, my decoder seems not to be updated to table phase 2.
-> Was there another, pre-1998 French second permutation table?

Regarding bit 4:
-> Do you know what is the suppressed carrier frequency?
* It would be fun to see if the decoder is realtime responsive to this audio carrier bit. If so, this was maybe a possible countermeasure to defeat "dumb" unofficial descramblers that weren't looking at VBI anyway. In the mid 90's, I heard from somebody who was involved in its conception, that syster was highly prepared for countermeasures.

Regarding bits 0 and 1:
* If both set 0, it seems the decoder does something to the chroma. In PAL, red and blue bursts are more visible.
* I wonder if this decoder can also do other descrambling methods, such as cut and rotate with the "seemingly random" VBI fields. From the same source, 23 years ago, I was told it could.

By the way, I have several hours of tapes recorded with 1995-ish French C+ Nagra programmes, if this can help your investigations.

Clarifications:
  • Was there another, pre-1998 French second permutation table? -> I mean: Assuming bit 3 selects which permutation table to use, besides the 2nd one used in France starting 1998, was there any other known secondary permutation table in syster decoders (Premiere, C+ Spain)?
  • Would you like to get VBI dumps and if so, could you tell me how to proceed? -> I mean: If already available, a simple link describing the procedure and required hardware would suffice.
Thanks!
 
Last edited:
Captain Jack

Captain Jack

Модератор
Staff member
Messages
11,013
My Satellite Setup
See signature
My Location
North Somerset
C-like:
        //vbi[5] bits 0-1 choose encryption mode 1: d11, 2: nagra, 0:?, 3:?
Regarding bits 0 and 1:
* If both set 0, it seems the decoder does something to the chroma. In PAL, red and blue bursts are more visible.
Yes, I did notice that as well - I've no idea why it does this.
* I wonder if this decoder can also do other descrambling methods, such as cut and rotate with the "seemingly random" VBI fields. From the same source, 23 years ago, I was told it could.
I am pretty sure there's another hidden descrambler available in that box. It's probably Smartcrypt - this was used by RTL9 I think. Cut and rotate...

At 2:38.

I can even very briefly activate it by having a weaker signal to TV/decoder, which spontaneously scrambles the picture (while already decoding Syster).


Beyond that, I don't know how else it works - I cycled 0x00 > 0xFF on the mode byte and didn't see anything beyond what you describe.
C-like:
        //vbi[5] bit 3 seems to say: if enc is nagravision, s,r are different ... Is it selecting another permutation table?
Regarding bit 3:
* with legacy permutation table, if enabled, then on my decoder, it seems part of the image is decrypted, part of the image is not. Some permutations are valid but not all. PAL color is globally restored, though.
What hardware are you using? I've seen this before with a 'pirate' card but simply removing it and putting it back in sorts it. I never got to the bottom of it (though I never really investigated).


So if bit 3 is a selection of permutation tables, my decoder seems not to be updated to table phase 2.
-> Was there another, pre-1998 French second permutation table?
AFAIK, there were only two. One used by everyone before 1998 and then another one used by France post 1998 to combat pirate decoders. I don't think I ever managed to select this second table through VBI.

C-like:
        //vbi[5] bit 4: if 1, inverts audio at 12.8kHz, else ? KHz if 0
Regarding bit 4:
-> Do you know what is the suppressed carrier frequency?
* It would be fun to see if the decoder is real-time responsive to this audio carrier bit. If so, this was maybe a possible countermeasure to defeat "dumb" unofficial descramblers that weren't looking at VBI anyway.
I did know the second frequency but cannot remember it. It's certainly not controlled by encryption. In fact, there's a pin on the TDA8xxx(?) chip in the decoder that you can set to high, which will enable this audio inversion.
By the way, I have several hours of tapes recorded with 1995-ish French C+ Nagra programmes, if this can help your investigations.
I have been looking for French C+ tapes for ages! We have C+ Poland dumps and Premiere Germany, though @fsphil, the main man behind this work, did not see many differences.

That said there definitely are as C+ Poland VBI never activates Premiere key and vice versa. I traced it down to ATR sent by the card during initialisation (02 00 command).

Premiere ATR:
(14:27:54) Q :02 00
(14:27:54) R :02 1C381405FF14E1E5 00

C+ France:
(14:30:39) Q :02 00
(14:30:39) R :02 18381200FF148083 00

C+ Poland:
(14:33:12) Q :02 00
(14:33:12) R :02 1CE00C01FF14E1E5 00

NTV+:
(14:31:07) Q :02 00
(14:31:07) R :02 22E01600FF14E1E5 00

However, I have not traced it down to which part of this data actually determines whether the key is correct for the transmission.

If I have any time at all (difficult these days), I will investigate this further again.
  • Would you like to get VBI dumps and if so, could you tell me how to proceed? -> I mean: If already available, a simple link describing the procedure and required hardware would suffice.
It's fairly simple to get the dump. You just need a capture device and preferably a Linux OS to make this easier. Then just run $ cat /dev/vbi0 > vbidata.dat for a few minutes.

The key to success is a good quality recording and a VCR with preferably TBC (timebase correction) function. This allows to stabilise a relatively fast data rate of Syster VBI.

The other mystery is how does the decoder work out what s,r values to use given an 8-bit seed that it gets from the card. I am sure there is some LFSR shifting going on in multiple registers but, again, haven't looked at it in great detail. Pretty sure it does not rely on permutation tables for this.

If you have any info on the above, do let me know.
 
H

homercartman

Member
Messages
39
My Satellite Setup
Cubsat 50, DVBSky S960, RPi3
My Location
France
Hi @Captain Jack !

Thanks a lot for your reply.

Yes, I did notice that as well - I've no idea why it does this.
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?

I can even very briefly activate it by having a weaker signal to TV/decoder, which spontaneously scrambles the picture (while already decoding Syster).
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.
  • 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!)
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:
  1. The first hackrf does hacktv PAL TX with low gain, as usual
  2. Split the TX hackrf output in two new output lines with a tee
  3. One of the 2 split outputs is connected to the tuner / decoder, as usual
  4. At this stage, make sure the decoder is sometimes triggered in CNR decryption
  5. The other split output is connected to the second hackrf in RX mode
  6. 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.
  7. 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!
  8. 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.
  9. 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.
What hardware are you using? I've seen this before with a 'pirate' card but simply removing it and putting it back in sorts it. I never got to the bottom of it (though I never really investigated).
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.

  • This might be unrelated but: with a goldcard, why did I have to enable #define _OPT_PIC_CARD 1 for my decoder to stably decode over time? If I don't enable this define, decoding only lasts ~0.5s.
I did know the second frequency but cannot remember it. It's certainly not controlled by encryption. In fact, there's a pin on the TDA8xxx(?) chip in the decoder that you can set to high, which will enable this audio inversion.
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 :)

It's fairly simple to get the dump. You just need a capture device and preferably a Linux OS to make this easier. Then just run $ cat /dev/vbi0 > vbidata.dat for a few minutes.
Ok. My environment is Linux. I'll check if my capture hardware provides the /dev/vbi0 device.
The key to success is a good quality recording and a VCR with preferably TBC (timebase correction) function. This allows to stabilise a relatively fast data rate of Syster VBI.
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!
 
Last edited:
fsphil

fsphil

Member
Messages
97
My Satellite Setup
Still playing with analogue. Also running a Humax FOXSAT-HDR and a Thomson THS804.
My Location
UK
Hi all,

Do you know what's currently blocking hacktv --syster to work in SECAM?
This should work. What happens when you try?

With two hackrfs
It might be easier to randomise the VBI data in hacktv before it's transmitted. Most of the VBI data seems to be messages for the card/key, so that might help narrow down where the flag for cut-and-rotate is.

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
Interesting, this sounds like a single field is being decoded rather than the whole frame.

Without TBC, is the output of /dev/vbi0 still worth something?
Absolutely, it's worth a try.
 
solly

solly

Specialist Contributor
Messages
4,846
My Location
Tel Aviv, Israel
one channel still on line mnet channel on c band after meny year
 
Top