Analogue Nagravision (Syster) encoder

Captain Jack

Burnt out human
Joined
Oct 21, 2006
Messages
11,797
Reaction score
7,980
Points
113
My Satellite Setup
See signature
My Location
North Somerset
All the decoders I tried did D11 in free mode (audience 7).

There are certainly differences between decoders - I have a whole pile of them and they all have their own perks.
 

fsphil

Member
Joined
Apr 27, 2017
Messages
112
Reaction score
52
Points
28
My Satellite Setup
Still playing with analogue. Also running a Humax FOXSAT-HDR and a Thomson THS804.
My Location
UK
Maybe 3D42 is a polynom in the context of a Crc16 computation

I'm starting to think function 3D42 is referring to code in the Syster decoder firmware. All I've found so far is that all the bytes of the EMM payload and the signature (so not including the four bytes address) all XOR'd together equals 0x00 (or sometimes 0xFF for Premiere).

I don't suppose anyone has a copy of the decoder firmware? :-)
 

neo7530

Member
Joined
Nov 27, 2019
Messages
14
Reaction score
4
Points
3
Age
45
My Satellite Setup
Cable / Hacktv
My Location
Berlin
Hey,
I have tried some Thing. With VBI data 49 FE 29 B1 00 00 00 00 00 00 00 00 00 FF FF FF … and MSG2[0] set to 74 my Terminal kicks in with cut and rotate and no Syster. If msg2[0] is set to 72, both encryption schemes are active. The PRBS for cut and rotate will initialized with the Nagra-Controlword. (only a guess) if i transmit 0x00 as controlword, i will get a static pattern. anything else will give a random pattern every halfframe.

Rgds, Neo.
 

fsphil

Member
Joined
Apr 27, 2017
Messages
112
Reaction score
52
Points
28
My Satellite Setup
Still playing with analogue. Also running a Humax FOXSAT-HDR and a Thomson THS804.
My Location
UK
The PRBS for cut and rotate will initialized with the Nagra-Controlword. (only a guess) if i transmit 0x00 as controlword, i will get a static pattern. anything else will give a random pattern every halfframe.

Also the cut points seem to be in sync with the PAL sub-carrier as the rotated lines don't change colour. This aspect is similar to Discret 11. The line shuffle sequence does not change when cut-and-rotate is enabled, but I'm not sure if the rotation is done before or after the line is shuffled.
 

neo7530

Member
Joined
Nov 27, 2019
Messages
14
Reaction score
4
Points
3
Age
45
My Satellite Setup
Cable / Hacktv
My Location
Berlin
It has to be done before, because the carrier wouldn't match after that… or… i don't know. Sometimes line shuffle loses ist sync, while c/r stays active.
 

homercartman

Member
Joined
Oct 25, 2019
Messages
42
Reaction score
6
Points
8
My Satellite Setup
Cubsat 50, DVBSky S960, RPi3
My Location
France
Hardware-wise, on the decoder , assuming decoder line buffers allows random read access, cnr after line shuffle is almost for free. On the contrary case (cnr before ls), an additional line of ram would be required.
 

neo7530

Member
Joined
Nov 27, 2019
Messages
14
Reaction score
4
Points
3
Age
45
My Satellite Setup
Cable / Hacktv
My Location
Berlin
Maybe it will be rotated while it will read out of the line-buffer... makes sense. When cnr is active, the decrypted video shifts to the left a couple of pixels, i guess this is to met the carrier-frequency...
 

neo7530

Member
Joined
Nov 27, 2019
Messages
14
Reaction score
4
Points
3
Age
45
My Satellite Setup
Cable / Hacktv
My Location
Berlin
@fsphil how about this?:
important note:
each byte of a line is equal to the XOR of the same bytes of each of the
4 other lines of the same group (49, 02, 15, 5E, 73) or (A1, EA, FD, B6, 9:cool:
possible correction from the procedures 15-FD, and 73-9B hence the presence of bytes of
filling that serve no purpose other than correcting any error.
In the decoder there are 2 buffers of 210 bytes. one is in use while the other is
filled on arrival of Ltxt. The address of the buffer in use is stored in a register
named here pBuf.
Each buffer behaves like a sequence of 210 bytes in use, and as a
following 10 lines of 21 bytes during loading.
I have (arbitrarily) divided according to these 10 lines, each called according to the indicative of the
line she receives.
The pairs of Ltxt are loaded in the reverse order of their arrival, ie the
73-9B couple is loaded down the buffer, and the last couple received is 15-FD.

Maybe this is the issue that some decos are unable to hold the sync?
 

fsphil

Member
Joined
Apr 27, 2017
Messages
112
Reaction score
52
Points
28
My Satellite Setup
Still playing with analogue. Also running a Humax FOXSAT-HDR and a Thomson THS804.
My Location
UK
I have code to generate these XOR lines, and it runs well on all my decoders now. It's not all finished but I'll try to push what I have to github tonight.
 

fsphil

Member
Joined
Apr 27, 2017
Messages
112
Reaction score
52
Points
28
My Satellite Setup
Still playing with analogue. Also running a Humax FOXSAT-HDR and a Thomson THS804.
My Location
UK
OK, pushed now. This update needs either a working Premiere key or an appropriate pirate card. The update includes the PRBS for line shuffling, correct XOR lines in the VBI and a sample of Premiere ECMs. It sends an EMM that gets broadcast to all cards periodically. I'm not sure what function this has, but all the channels seem to do something similar.

What's still to do is add more channel examples (Canal+ FR and PL at least) and to re-add the "Premiere Bug" mode which works even with deactivated cards. I'm also still stuck on how the EMM CRC works.
 

neo7530

Member
Joined
Nov 27, 2019
Messages
14
Reaction score
4
Points
3
Age
45
My Satellite Setup
Cable / Hacktv
My Location
Berlin
Sadly it does nothing on my SCART-based decoder. The cable decoder does his job fine :)
 

fsphil

Member
Joined
Apr 27, 2017
Messages
112
Reaction score
52
Points
28
My Satellite Setup
Still playing with analogue. Also running a Humax FOXSAT-HDR and a Thomson THS804.
My Location
UK
With the same key? That's odd. Did it work before with the old version?
 

neo7530

Member
Joined
Nov 27, 2019
Messages
14
Reaction score
4
Points
3
Age
45
My Satellite Setup
Cable / Hacktv
My Location
Berlin
Yepp... this should fix it:

@fsphil The VBI sequences seems to be wrong. each byte of a line is equal to the XOR of the same bytes of each of the
4 other lines of the same group ( 49, 02, 15, 5E, 73 ) or ( A1, EA, FD, B6, 9B )

This is what hacktv produces:

15 72 00 10 |0E| 4C AB 9A |22| 44 8E AD 00
73 8C 2F 54 |35| 67 73 86 |F0| 9E C5 99 00
5E 4D 4D 59 |45| 4D 4D 44 |55| 4D 4D 59 45
49 FE 28 B1 |00| 00 00 00 |00| 00 00 00 00
02 4D 4D 59 |45| 4D 4D 44 |55| 4D 4D 59 45

first line from top to bottom:
0e xor 35 xor 45 xor 00 !=45
next line:
22 xor F0 xor 55 xor 00 !=55


So this should be right this way: (see Syster VBI paper from zip)

15 7b 02 35 |86| 47 f9 d6 |dc| 0c 7b fb ...
02 4D 4D 59 |45| 4d 4d 44 |55| 4d 4d 59...
49 7F 08 B1 |00| 00 00 00 |00| 00 00 00 ...
5E FF 21 01 |00| F6 FE F0 |E3| F0 A1 00 ...
73 B6 66 DC |C3| FC 4A 62 |6A| 41 25 52 ...

86 xor 45 xor 00 xor 00 == C3
or:
dc xor 55 xor 00 xor e3 == 6A

73 can be random data, so the only thing we have to calculate are the data for 5E... the other lines are fixed patterns... this is for error correction and seems to confuse some decoders.
 

neo7530

Member
Joined
Nov 27, 2019
Messages
14
Reaction score
4
Points
3
Age
45
My Satellite Setup
Cable / Hacktv
My Location
Berlin
Just another remark: the class 15 should have a checksum after the controlword, but it seems to be always 0x00 in hacktv. This can be an issue too for the decoder. But good work for the prbs. How did you find this?
 

fsphil

Member
Joined
Apr 27, 2017
Messages
112
Reaction score
52
Points
28
My Satellite Setup
Still playing with analogue. Also running a Humax FOXSAT-HDR and a Thomson THS804.
My Location
UK
The XOR lines 73 and 9B are transmitted first, I think you're using the lines from the subsequent block. It should look like this as transmitted:

73 8C 28 A1 0E 4C AB 9A 22 44 8E AD 00 00 00 00 00 00 00 00 00 00
9B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
5E 4D 4D 59 45 4D 4D 44 55 4D 4D 59 45 4D 4D 44 55 4D 4D 59 45 4D
B6 4D 44 55 4D 4D 59 45 4D 4D 44 55 4D 4D 59 45 4D 4D 9E 4D DC F0
49 FE 28 B1 00 00 00 00 00 00 00 00 00 FF FF FF FF 44 55 4D 4D 59
A1 45 4D 4D 44 55 4D 4D 59 45 4D 4D 44 55 4D 4D 59 45 4D 4D 44 55
02 4D 4D 59 45 4D 4D 44 55 4D 4D 59 45 4D 4D 44 55 4D 4D 59 45 4D
EA 4D 44 55 4D 4D 59 45 4D 4D 44 55 4D 4D 59 45 4D 4D 9E 4D DC F0
15 72 00 10 0E 4C AB 9A 22 44 8E AD 00 FF FF FF FF 44 55 4D 4D 59
FD 45 4D 4D 44 55 4D 4D 59 45 4D 4D 44 55 4D 4D 59 45 4D 4D 44 55

This matches the samples captured from VHS, for example here's one from Premiere:

73 23 25 CD 34 AB D0 4E 5C 69 EB 4F C2 7C 88 22 4C 6A D3 6D B2 10
9B 24 2D 6A 7B CA E5 0B 81 4B A1 48 AD 86 4C 3B 0D 66 71 28 E2 50
5E 13 06 88 70 AF B4 92 74 E7 4C 5F FE EC EC 1D BD E5 31 BC 0F C5
B6 79 9E 27 42 14 12 66 93 06 AF 8F 71 18 59 59 09 6E 22 D8 20 CA
49 FE 28 B1 00 00 00 00 00 00 00 00 00 00 FC 08 40 11 42 53 70 00
A1 E8 4F A0 50 04 39 B8 B7 4E 3E 2E 6A 3F B4 AC C1 D7 92 5B 04 8C
02 BC 0A 51 F1 5D 4D AD 1F A8 91 7A C3 90 65 3F F1 C2 0F BD 2B AB
EA 48 6B 08 F0 FF 07 8E 72 38 A4 F1 92 97 22 41 91 34 6F F0 CF D1
15 72 01 A5 B5 59 29 71 37 26 36 6A FF 00 FD 08 40 5C AF 3F E6 7E
FD FD 97 E5 99 25 C9 5B D7 3B 94 18 24 36 83 8F 54 EB AE 5B 09 C7
 

neo7530

Member
Joined
Nov 27, 2019
Messages
14
Reaction score
4
Points
3
Age
45
My Satellite Setup
Cable / Hacktv
My Location
Berlin
Ahh, sorry Phil, got it wrong. You are right. this should work then. So then i don't have any clue why the terminal won't kick in :( My Cable Decoders are working perfectly.
 

homercartman

Member
Joined
Oct 25, 2019
Messages
42
Reaction score
6
Points
8
My Satellite Setup
Cubsat 50, DVBSky S960, RPi3
My Location
France
Hi @fsphil

Just to let you know:

I tested your commit ed6d42089c64b67557ec278f2dfa21af88a94566 against previous one (ab38871135008a5bfbcf3790e951d470179119ab).

Of the two French C+ boxes I tested, both with the PIC Card, both are kicking stably, but none are descrambling properly. Also verified this is not a table1/2 problem.

On your previous commit, both would kick stably and descramble for 1 second. This is the #define _OPT_PIC_CARD problem that @Captain Jack addressed on his hacktv fork, setting this define to 1 works for both boxes with PIC card (at commit ff45a14d730901f7cddf3242d2419fdd25c73c8f).

Cheers!
 
Last edited:

neo7530

Member
Joined
Nov 27, 2019
Messages
14
Reaction score
4
Points
3
Age
45
My Satellite Setup
Cable / Hacktv
My Location
Berlin
@fsphil how do you get the byte sequence for class 15 for the next round? The first round contains the first 8 bytes of the ecm. After 10 lines the class 15 contains other values. After 25 frames it is the first part of ecm unmodified... I am a little confused about that part... The last commit sends the cw every 10 lines with no change, with that my terminal is happy and kicks in. Do you have tried my funcard file? With that it is better to trace, what's going on, because it replies the first 8 bytes of the ecm. Interesting part, the terminal sends the ecm to card and receive the correct answer, but never kicks in.
 

neo7530

Member
Joined
Nov 27, 2019
Messages
14
Reaction score
4
Points
3
Age
45
My Satellite Setup
Cable / Hacktv
My Location
Berlin
I have some sort of success with the new version. If I set the checksum for class 15 correct, I get my decoder to kick in. If I set it back to checksum hack table it won't kick in anymore.
 

fsphil

Member
Joined
Apr 27, 2017
Messages
112
Reaction score
52
Points
28
My Satellite Setup
Still playing with analogue. Also running a Humax FOXSAT-HDR and a Thomson THS804.
My Location
UK
ECMs are transmitted several times before they're used by the decoder. I guess this is to provide some redundancy. The order they're transmitted is somewhat shuffled. The two bytes before the ECM on line 15 indicate which ECM part is being transmitted (ignoring the lower 4 bits, the range is 0x00 - 0x7F - each part is half an ECM so the decoder stores 64 ECMs in total, 0x00 and 0x01 are the two halfs of the first ECM).

The previous version transmitted the same 8 bytes every time, so all 64 ECMs would be the same 8 bytes repeated twice. But those ECMs where ignored due to what we called the Premiere Bug, where the decoder would use its own CW every time (0x0800A8002800A800). This mode can still be used if you change msg2[1] to:

msg2[ 1] = 0x76;

And also change all of the CWs in the table to 0x0800A8002800A800.

I haven't tested this.
 
Top