Décodeur canal + de 1984

Echanges d’informations et d’astuces techniques dédiées à la télévision et à la vidéo anciennes.

Modérateur: jrob

Re: Décodeur canal + de 1984

Messagepar Mannix54 » Dim 3 Déc 2017 11h23

Domi-Niaque a écrit:Petite question: j'imagine que le codeur utilisé par STV via FR3 avait donc une clé 16 bits différente de celui de C+, est-ce fort possible ?
Etait-ce en audience fixe ou tournante, avec ou sans masquage des bords ?


apparemment d'après les vidéos youtube c'est exactement le même système de cryptage que celui de canal+ du discret11,

c'est à dire un système basé sur un mot de 16 bits qu'on doit entrer indirectement dans le décodeur via un code clavier à 8 chiffres ( le firmware calcule ensuite le mot de 16 bits à partir du code clavier à 8 chiffres et du numéro de série à 8 chiffres enregistré dans la rom du décodeur ), au final tous les décodeurs des abonnés SVT travailleront sur le même mot de 16 bits,

le mot de 16 bits de la société STV peut très bien être différent de celui de canal+, l'essentiel c'est que le décodeur travaille sur le bon mot de 16 bits et que les lignes 310 et 622 soient bien visibles par le décodeur ( pour trouver le bon niveau audience parmi les 6 possibles pour extraire le bon mot de 11 bits ),

pour simplifier ils peuvent aussi utiliser l'audience 7 ( code de fin de mois ) qui donne toujours le même mot de 11 bits ( 1337 ), ce qui permet à l'abonné "STV" de ne pas entrer de code clavier,

pour savoir si la société SVT s'est pris la tête en utilisant le "multicode" ( multiple niveau d'audience ) il faudrait trouver des enregistrements VHS d'époque, mais ça m'étonnerait, ils ont dû faire au plus simple, un seul niveau d'audience tous les mois
http://cryptimage.vot.pl

dernière version : 1.4.5 du 23 août 2017
Mannix54
 
Messages: 1068
Inscription: Jeu 7 Aoû 2014 14h56

Re: Décodeur canal + de 1984

Messagepar dreambox59 » Dim 3 Déc 2017 11h45

ta methode par correlation ça s apparente a la methode "brute force" et c est efficace.
mais il suffit que tu recupere 11 retards successifs dans une trame avec le n° de ligne du 1er retard recupéré pour calculer facilement le mot de 11 bits de depart (moi je recuperais 16 retards = 16 bits les 5 en "rabe" servaient a comfirmer le mot de 11 trouvé par calcul)
le retard s exprime sur 2 bits (0 1 2 : 00 01 10) un seul des 2 bits est coherent avec l algo.

il faut creer un algo a l envers qui effectue le meme nombre de pas que le n°de ligne utile (n°reel - 22) .
si tu vas dans cette direction je te ferais un topo avec exemples.
il faut que tu ais une remise en place de l image sur au moins 11 lignes consecutives n importe ou dans les 286 mais de preference dans le haut.
bien sur si tu sais si on est dans la trame 1 c est mieux parce que le calcul est different dans les trames 4 5 6
dreambox59
 
Messages: 242
Inscription: Ven 25 Juil 2014 09h42
Localisation: bourgogne

Re: Décodeur canal + de 1984

Messagepar Mannix54 » Dim 3 Déc 2017 12h44

un truc que je n'ai pas compris : comment faisait le décodeur pirate pour être certain d'évaluer le bon retard ( 0, 902, 1804ns ) appliqué dans une ligne ?

il se base sur 2 lignes adjacentes ( n et n-1 ) qu'il découpe en petits échantillons, il compare ensuite chaque échantillon par rapport à la ligne du dessus en espérant trouver une rupture franche en terme de couleurs/luminosité pour en déduire le retard ?
ça semble un peu hasardeux si l'image est trop uniforme ( image complètement noire, couleur uniforme, une pelouse d'un terrain de foot )
http://cryptimage.vot.pl

dernière version : 1.4.5 du 23 août 2017
Mannix54
 
Messages: 1068
Inscription: Jeu 7 Aoû 2014 14h56

Re: Décodeur canal + de 1984

Messagepar marceljack » Dim 3 Déc 2017 16h37

Mannix54 a écrit:un truc que je n'ai pas compris : comment faisait le décodeur pirate pour être certain d'évaluer le bon retard ( 0, 902, 1804ns ) appliqué dans une ligne ?
Au début du Discret, la vidéo et la sous porteuse SECAM commençaient avec le même retard que la ligne décalée et il n'y avait pas de signal sur les premères 902 ou 1804 ns des lignes décalées.
Il suffisait donc de générer deux impulsions allant taper au mileu de la première et de la 2ème période de 902 ns pour voir s'il y avait ou non de la chroma et on pouvait en déduire le retard de la ligne:
-chroma sur les 2 périodes: 0 retard
-pas de chroma sur la première mais chroma sur la 2ème : 1 retard
-pas de chroma sur les deux : 2 retards

Mais canal s'est vite rendu compte de la faille et a rajouté de la vidéo et de la chroma artificielles de manière à ce que toutes les lignes démarrent au même point, ce qui a rendu les premiers déco inutilisables.
marceljack
 
Messages: 1740
Inscription: Ven 17 Juil 2009 11h40

Re: Décodeur canal + de 1984

Messagepar dreambox59 » Dim 3 Déc 2017 20h29

je ne sais pas comment faisait le 68705 mais sur le 6802 avec carte auto :
tu lis le niveau de la video de façon simpliste (c est a dire un seuil a mi course de l amplitude video) en dessous c est "0" au dessus c est "1".
dans mon systeme tu lis a 20us apres la synchro ligne (a droite sur l ecran) et entre la ligne (22+32)54 et (22+32+16)70.
chaque bit est mis dans un registre de 16 par decallage circulaire.
ça te donne un mot de 16bits dont tu prends les 11 premiers pour initialiser l algo :P(X) = X11 + X9 + 1 puis tu le fais tourner 5 pas et les 5 bits de poids faibles qui en resultent doivent matcher les 5 bits obtenu avant.
si c est bon c est forcement le bon resultat sinon on recommence a la sequence de 6 trames suivante.
concretement : des qu une transition un peu marqué (comme un balayage du paysage de gauche a droite) passait sur l ecran ça trouvait le code 11 bits .
ça a marche pendant longtemps et ça dependait de l image mais la plupart des jingle d emission declenchait le resultat
dreambox59
 
Messages: 242
Inscription: Ven 25 Juil 2014 09h42
Localisation: bourgogne

Re: Décodeur canal + de 1984

Messagepar Raffou » Dim 3 Déc 2017 20h40

Le détecteur de lignes blanches qui sert à se synchroniser sur les cycles (lignes 310) et à déterminer le niveau d'audience (lignes 622) est aussi mis à contribution pour générer les échantillons binaires dont on à besoin. Il est calibré pour être sensible à un certain niveau de luminance , par exemple 70% du niveau du blanc, ce qui correspond à un gris soutenu. En dessous de cette valeur, il indique "0", au dessus il indique "1".

Pour que l'algorithme qui était utilisé pour le 68705 soit efficace, il sera certainement nécessaire de désaturer la 1ère trame du cycle en ne conservant que la luminance, c'est à dire en transformant les couleurs en niveaux de gris.

Sinon les explications données sont toujours d'actualité :
Raffou a écrit:La recherche proprement dite.
  1. Le principe est en gros celui esquissé par dreambox59 (viewtopic.php?f=15&t=236877&start=1425#p363191) basé sur la détection d'une transition verticale franche. En effet pour les 3 premières trames du cycle, la table des retards est telle que le retard 2 (1804 ns) ne dépend que du paramètre Y (dénomination issue des articles de Science et Vie de Janvier 85 et Janvier 87).
  2. Si l'échantillonnage d'une ligne de la trame zéro survient entre une transition retardée de 902 ns et la même transition retardée de 1804 ns, le détecteur de niveau du blanc donnera un résultat (0 ou 1) différent et ce dernier sera alors assimilable au paramètre Y.
  3. Pour accroitre les chances de capturer une transition verticale qui peut survenir à n'importe quel endroit de l'image alors que l'échantillonnage se fait à période fixe, chaque ligne est échantillonnée à 4 reprises à des intervalles de 14 µs.
  4. Les 48 premières lignes de la trame zéro sont ignorées (bande noire des films en cinémascope) alors que les 92 suivantes sont échantillonnées et le résultat stocké par quartet en mémoire RAM :
    • L'on pourrait stocker jusqu'à 8 échantillons par ligne pour doubler les probabilités de capture mais la vitesse du 68705 n'en autorise que 4.
    • Le nombre de lignes échantillonnées est limité à 92 car la RAM interne ne comporte que 112 octets.
  5. La redondance du générateur pseudo aléatoire est telle que le bit Y pour une ligne donnée résulte du XOR (ou exclusif) entre les bits Y qui ont engendrés les retards 9 et 11 lignes plus haut dans l'image.
  6. A partir de la dernière ligne échantillonnée, on exécute le XOR entre la valeur binaire d'un échantillon de cette ligne et celle de l'échantillon correspondant capturé 9 lignes plus haut dans l'image. Le résultat est comparé avec l'échantillon prélevé 11 lignes plus haut et un compteur est incrémenté si le résultat est positif sinon il est reseté.
    • Cette opération est réitérée à partir de l'échantillon de la ligne précédente jusqu'à ce que le début de la mémoire de stockage soit atteinte.
    • Si cette opération est positive 18 fois de suite, on considère que l'on a capturé une transition et le résultat du XOR n'est plus comparé avec l'échantillon 11 lignes plus haut mais est stocké à sa place. Ce qui va permettre de remplacer l'échantillon des lignes plus en avant, qui n'a pas forcément été affecté par la transition verticale, par un bit régénéré à partir de deux autres qui ont été certifiés lors de précédents XOR.
  7. Quand le début de la mémoire de stockage est atteinte :
    • Si le résultat est négatif, on change de série d'échantillons et on réitère l'opération. Si le résultat est toujours négatif pour les 4 séries d'échantillons, la recherche est poursuivie et un nouvel échantillonnage sera effectué sur la trame zéro du cycle suivant.
    • Si le résultat est positif, le contenu du générateur pseudo aléatoire est reconstitué à partir des 11 derniers échantillons stockés (régénérés) et le générateur est itéré à l'envers d'un nombre de fois correspondant à celui des lignes omises en début de trame. Le contenu correspond alors à la clef qui est sauvegardée en fonction du niveau d'audience d'appartenance.

Le principe est d'échantillonner la ligne à intervalles réguliers en espérant qu'une transition verticale de luminosité survienne à un de ces moments là. Ainsi par exemple, pour une transition clair vers sombre, un échantillon de même rang pourra avoir pour valeur "0" avec un retard de ligne nul ou égal à 902 ns alors qu'il aurait la valeur la "1" si la même ligne avait subit un retard de 1804 ns.
La table des retards étant définie comme suit pour les 3 premières trames du cycle :
▪ retard nul pour XY = 00,
▪ retard 902 ns pour XY = 10,
▪ retard 1804 ns pour Y = 1 quelque soit X.
Pour une transition verticale de luminosité affectant une même zone de l'image, ceci implique que si les échantillons de même rang ont changé d'état entre deux lignes consécutives, c'est que le paramètre "Y" a probablement changé d'état lui aussi. On peut même assimiler la valeur binaire de "Y" à celle de l'échantillon (paragraphe §1 et surtout le §2).
L'algorithme du 68705 ne pouvait prélever que 4 échantillons par ligne à cause de sa faible vitesse d'exécution et se contentait de le faire que sur seulement 92 lignes à cause de ses ressources limitées en mémoire interne. Un programme sur PC doit être à même de prélever beaucoup plus d'échantillons par ligne (8, 16, 32...) et ce sur un nombre de lignes plus important (≈180 pour éviter d'échantillonner les bandes noires des films en cinémascope) afin d'accroitre ses chances de tomber sur la transition de luminance qui va bien et retrouver le mot d'initialisation du GPA plus rapidement.

L'astuce utilisée (§5) ensuite est une exploitation des conséquences de la redondance du GPA. Elle consiste à s'assurer que dans une suite d'échantillons de même rang (18 lignes consécutives), chaque échantillon pris séparément correspond au résultat du OU exclusif entre deux autres échantillons particuliers (le 9ème et le 11ème qui l'ont précédé). Si une suite d'échantillons de même rang correspond à tous ces critères (§6), tous les échantillons qui la précède sont recalculés et remplacés un à un en remontant dans le buffer jusqu'au tout premier grâce au OU exclusif entre échantillons déjà connus quelques lignes plus loin dans la trame.

Au §7, l'algorithme du 68705 était contraint de reconstituer le contenu du GPA tel qu'il l'aurait été pour la première ligne échantillonnée et ensuite de le faire itérer 48 fois à l'envers pour prendre en compte les premières lignes non échantillonnées afin de retrouver le mot d'initialisation du GPA.
Cette contrainte est due au manque de mémoire du 68705 car il aurait fallu 48 octets supplémentaires en début de buffer pour continuer à reconstituer la suite de bits par le OU exclusif et finalement obtenir le mot d'initialisation du GPA. Il n'est donc pas nécessaire de faire itérer le GPA à l'envers si l'on est pas limité par la mémoire disponible, il suffit de prévoir ces 48 lignes mémoire qui ne recevront aucun échantillon issus du détecteur mais serviront à reconstituer la suite de bits jusqu'à la première ligne visible de la trame.
Image
Raffou
 
Messages: 518
Inscription: Jeu 15 Mai 2014 18h17

Re: Décodeur canal + de 1984

Messagepar Mannix54 » Lun 4 Déc 2017 07h38

en tout cas j'ai modifié cryptimage pour qu'il puisse reconnaitre les lignes 310 et 622 même lorsqu'elles sont peu lumineuses ( capture de cassette VHS ),

ce qui m'a permis de trouver le mot de 11 bits utilisé dans la vidéo de TDA4565 ( vieux film de 1985 ) : 1220, audience 4,

le mot de 16 bits est donc : 18252

voici donc le décodage en mode classique par cryptimage de la cassette V2000 de TDA4565 ( pas de force brute, c'est vraiment un décodage manuel en entrant le mot de 16 bits ) :

https://youtu.be/xa0UkESzOBA ( pour rappel le fichier crypté d'origine est ici : https://we.tl/GGXAaPEfyF )

il n'y a pas de son car TDA4565 a probablement oublié de capturer le son lors de la numérisation, normalement il faut relier la sortie audio de la péritel du magnétoscope à l'entrée "line" ( ligne ) de la carte son, puis configurer le logiciel de capture pour qu'il numérise le son depuis l'entrée ligne de la carte son ( bien régler le niveau d'enregistrement de l'entrée ligne, ni trop fort, ni trop faible ), puis utiliser le format wav ou le codec mp3 avec un très bon taux ( 192 kbs ou 320, fréquence d'échantillonage 44100 hz ou 48000 hz ),

on peut aussi utiliser audacity pour numériser séparément le son, puis ensuite ajouter ce fichier son à la vidéo ( la difficulté sera de le synchroniser avec la piste vidéo ), certaines clés USB d'acquisition vidéo peuvent aussi capturer le son ( fiches audio RCA ),

la prochaine version de cryptimage contiendra ces améliorations ( meilleure détection des lignes 310/622, et nouveau mode de décodage s'inspirant des décodeurs pirates )
http://cryptimage.vot.pl

dernière version : 1.4.5 du 23 août 2017
Mannix54
 
Messages: 1068
Inscription: Jeu 7 Aoû 2014 14h56

Re: Décodeur canal + de 1984

Messagepar Domi-Niaque » Lun 4 Déc 2017 13h00

@Mannix54:
Pour ta prochaine mouture, que prévois-tu sur le plan esthétique et/ou graphique ?
Comme t'inspirer des photos de l'armoire d'encryptage pour coller au plus près de l'époque...
...ainsi que réutiliser la typographie emblématique de la chaîne
http://blog.lenodal.com/index.php?/archives/035-Typographie-Canal+.html
au besoin en mettant un disclaimer pour éviter tout ennui.
RFL5933
Troc:
Sauf mention contraire, prix franco de port
Règlement: https://www.paypal.me ou chèque à mon ordre
Domi-Niaque
 
Messages: 1381
Inscription: Lun 21 Déc 2009 19h20
Localisation: Sud-Est de l'IdF

Re: Décodeur canal + de 1984

Messagepar Mannix54 » Lun 4 Déc 2017 13h50

justement je veux éviter tout risque de rapprochement avec la chaine et les problèmes de copyright, d'où l'absence de police de caractères et du logo canal+ :mrgreen:

par contre l'idée d'imiter en terme de graphisme ( boutons, leds, interrupteurs ) un objet physique type armoire de codage/décodage est intéressante, peut-être pour plus tard, pour l'instant je me concentre sur les fonctionnalités et la fiabilité du logiciel,

sinon pour le film de TDA4565 il daterait plutôt de 1987, donc une diffusion à l'époque vers 1988 ou 1989 sur canal+ :

https://en.wikipedia.org/wiki/Surrender_(1987_film)

https://www.youtube.com/watch?v=dJTGkb0h0rg
http://cryptimage.vot.pl

dernière version : 1.4.5 du 23 août 2017
Mannix54
 
Messages: 1068
Inscription: Jeu 7 Aoû 2014 14h56

Re: Décodeur canal + de 1984

Messagepar TDA4565 » Lun 4 Déc 2017 22h39

En ce qui concerne le son, c'est tout bête: le câble qui le véhicule a son âme cassée, il faudra que je répare.

Le film semble en effet dater de 87. Il est écrit 85 sur la cassette mais c'est donc une erreur.
Ceci dit, je ne m'explique pas l'absence de la contre-mesure visant le décodeur Radio Plans, 3 ans après ...
TDA4565
 
Messages: 66
Inscription: Jeu 13 Juil 2017 21h31

Re: Décodeur canal + de 1984

Messagepar Mannix54 » Mar 5 Déc 2017 00h54

en terme de rareté ce serait intéressant de voir si tu as dans tes cassettes des émissions de canal+ cryptées, des émissions de plateau, des bandes-annonces, des clips, documentaires, le genre de choses dont on est sûr qu'on ne trouvera pas la version en DVD,
la chaîne faisait parfois des soirées thématiques, avec des documentaires, des interludes entre 2 films où ils en profitaient pour diffuser un court-métrage ( une séquence "surprises" qui avait son propre jingle ),

à l'ina les archives de canal+ ne sont pas disponibles au grand public, seules les émissions du service public ( et la cinq ) sont proposées en streaming
http://cryptimage.vot.pl

dernière version : 1.4.5 du 23 août 2017
Mannix54
 
Messages: 1068
Inscription: Jeu 7 Aoû 2014 14h56

Re: Décodeur canal + de 1984

Messagepar TDA4565 » Mer 6 Déc 2017 20h55

Extrait d'une cassette VCC-540 (format V2000).

9 heures de stockage, ce qui me fait réaliser que sur un V2000 2x8 on passe donc à 18 heures, chapeau pour l'époque...

@Mannix54: des annonces et un jingle, je ne sais pas si c'est ce genre de chose que tu cherches.
Sur cette vidéo on voit très bien que le décodeur Radio Plans n'a pas la moindre chance.

A noter qu'on a une transition 'clair -> crypté', les décos se comportent bien (pas une trame cryptée trop tôt ni une trame décryptée trop tard), que fait cryptimage dans cette situation?

https://we.tl/PDjfRVG7nt
TDA4565
 
Messages: 66
Inscription: Jeu 13 Juil 2017 21h31

Re: Décodeur canal + de 1984

Messagepar Mannix54 » Mer 6 Déc 2017 23h15

à priori il doit se comporter comme le décodeur officiel, je vais faire le test :)
http://cryptimage.vot.pl

dernière version : 1.4.5 du 23 août 2017
Mannix54
 
Messages: 1068
Inscription: Jeu 7 Aoû 2014 14h56

Re: Décodeur canal + de 1984

Messagepar Mannix54 » Jeu 7 Déc 2017 00h28

je viens de tester, les lignes 310 et 622 sont vraiment très très peu lumineuses, du coup cryptimage galère,

quel est le niveau d'audience trouvé par tes décodeurs ?
le niveau 3 ?

ou bien c'est du multi-audience ?
http://cryptimage.vot.pl

dernière version : 1.4.5 du 23 août 2017
Mannix54
 
Messages: 1068
Inscription: Jeu 7 Aoû 2014 14h56

Re: Décodeur canal + de 1984

Messagepar Mannix54 » Jeu 7 Déc 2017 04h53

après plusieurs tests il s'agit bien d'une vidéo avec plusieurs niveaux d'audience,

j'ai fini par trouver le mot de 16 bits utilisé : 30422, plusieurs niveaux d'audience ( 3, 1 et 2 ), voici le résultat :

https://www.youtube.com/watch?v=65kp7_pAzNA

ça décroche à quelques reprises pendant moins d'une seconde ( parfois juste une demi-trame qui n'est pas décodée ), je pense que ça vient de la bande magnétique qui est en mauvaise état, quelque chose qui crée une mauvaise géométrie ( image instable verticalement ? la clé USB d'acquisition vidéo qui zappe de temps en temps une demi-trame ? ),

j'ai aussi dû changer la sensibilité de détection des lignes 310 et 622 dans cryptimage ( à mon avis il va falloir donner à l'utilisateur la possibilité de régler le seuil de tolérance pour la détection, un curseur de réglage dans l'interface ), car sur cette vidéo les lignes sont pas assez lumineuses, surtout la ligne 622, on la distingue à peine, normalement elle doit être bien blanche, mais à cause de la bande magnétique abîmée ça tire vers une couleur bleu/violet sombre
http://cryptimage.vot.pl

dernière version : 1.4.5 du 23 août 2017
Mannix54
 
Messages: 1068
Inscription: Jeu 7 Aoû 2014 14h56

PrécédenteSuivante

Retourner vers Technique TV et vidéo

Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 3 invités

cron