Décodeur et cryptage Discret 11

Pour pouvoir déterminer le nombre critique d’échantillons dont il est question dans le dernier message,
rien de mieux qu’une feuille du tableur Calc de LibreOffice pour la simulation.

Le fichier Calc de la feuille ci-dessus: TestRetards.rar.TXT (338 KB)
Après récupération du fichier, supprimer l’extension en .TXT puis le décompresser, seule l’extension en .ods doit subsister pour pouvoir le charger dans le tableur Calc LibreOffice.
La feuille est protégée sans mot de passe.

• Colonnes B à L: 4095 itérations sur les 11 bits du GPA pour le faire reboucler une deuxième fois sur le mot d’initialisation en ligne 4097, pour les besoins du comptage.
Double-cliquer dans les cellules B2 à L2 pour inverser l’état du bit correspondant dans le mot d’initialisation

• Colonne M: Indique le retard 0, 1 ou 2 généré par le GPA, ceux définis pour Z=0 sur les 3 premières trames du cycle.

• Colonnes N, O, P et Q: Simulation des échantillons prélevés respectivement aux instants B, C, F et G selon le diagramme en tête des colonnes. En parcourant ces dernières, on remarque immédiatement que les valeurs dans les cellules des colonnes F et G sont le complément binaire de celles des colonnes B et C.

• Colonnes R, S, T et U: associées respectivement aux échantillons prélevés aux instants B, C, F et G.
Chaque échantillon est comparé au résultat du XOR effectué entre le 2ème et le 11ème qui l’on précédés. Le résultat du XOR étant l’inverse de l’échantillon de référence pour ceux collectés en B et C sur une transition positive, la formule dans la cellule associée assure la correction nécessaire.
Ainsi les cellules des colonnes C et G sont toutes à 1 car toutes les comparaisons sont OK, ce qui est cohérent puisque les échantillons prélevés en G sont censés représenter le bit Y et ceux en C son inverse.

• Sont seuls intéressants maintenant les résultats dans les colonnes R et T associés aux échantillons B et F afin de déterminer le nombre critique d’exactitudes en dessus duquel on est assuré que les échantillons testés n’ont pu être prélevés qu’aux instants C ou G.
Chaque résultat dans une colonne étant le complément du correspondant dans l’autre, pour cette expérimentation, il est inutile de comptabiliser séparément les exactitudes dans chaque colonne. Le comptage s’effectuera uniquement à partir de la colonne R dans laquelle on va rechercher le nombre critique d’échantillons qui correspond à celui à partir duquel on a moins de cellules OK que de recensées.

• Colonnes V et suivantes: Dans chaque cellule, à partir de celle de même rang dans la colonne R, on compte le nombre de résultats OK (à zéro) sur un groupe de 16 cellules consécutives, de 17 pour la colonne suivante et ainsi de suite jusqu’à la dernière colonne du tableau.

• Ligne 1, Cellule V1 et suivantes: Nombre de comparaisons consécutives à vérifier, donc la taille de la suite ou regroupement d’échantillons dont elles sont issues.

• Ligne 2, Cellule V2 et suivantes: Comptabilisation du nombre de fois où l’on rencontre un groupe dont toutes les cellules sont OK, c’est à dire quand il y a autant de OK que de cellules dans le groupe.

• Finalement, ce n’est qu’à partir de 54 comparaisons OK que le nombre de groupes recensés devient nul, ils ne comportent plus autant de OK que de cellules consécutives.

Ce n’est qu’à partir de ce nombre 54 que l’on pourra faire la distinction entre une suite d’échantillons issus de la configuration B ou F de ceux issus de la configuration C ou G et que l’on sera absolument sûr que les échantillons de cette suite représentent bien les états successifs de Y.

Ce nombre critique représente une transition relativement haute dans l’image, il n’est pas sûr que l’on puisse capturer rapidement autant d’échantillons certifiés à la fois, même avec un nombre conséquent de prélèvements effectués à intervalles réguliers dans les lignes.
Ainsi pour minimiser les erreurs, un programme devra rechercher pour tous les intervalles, la suite d’échantillons qui offre le meilleur score à défaut d’une qui atteigne celui de 54.

Avec un nombre critique de 18, le programme de recherche du 68705 s’autorisait théoriquement 56 erreurs sur une suite d’échantillons issue de la configuration B ou F, soit un taux de 56 ÷ 2047 ce qui équivaut à presque 3%. Ce qui devait passer inaperçu et au pire la relance d’une nouvelle recherche aurait été tout à fait acceptable.

Maintenant, à partir d’un nombre d’échantillons certifiés suffisant (supérieur à 18?) et le plus proche possible de 54 pour être assimilables au bit Y, il ne reste plus qu’à itérer le GPA à rebours du nombre d’itérations qui va bien pour retrouver le mot de 11 bits qui l’a initialisé en ligne 336 de la 1ère trame du cycle.

J’ai vu un reportage ce soir sur le paradoxe de Fermi.

Si j’ai bien compris les propos de ce scientifique, il dit qu’il y a un nombre infini de planètes, d’étoiles, de systèmes et il se demande donc pourquoi nous sommes toujours seuls, pourquoi il n’y a aucune manifestation de vie ‹ extérieure › à la terre.

Ca m’a fait penser au D11, et à la question que je me pose depuis toujours:
il y a un nombre incensé de décodeurs officieux, basés sur des procs différents, des techniques différentes de décodage. Pourquoi aucun concepteur ne se manifeste sur aucun forum?
La peur de représailles je suppose, mais c’est dommage.

Pour le décodeur officiel, la question reste la même. C’était au début des années 80, il est fort probable que bien des membres des équipes qui ont conçu cet appareil soient toujours vivants.

Nous sommes vendredi soir, c’était mon moment décompression de fin de semaine.

Ceci dit, si quelqu’un a un avis, je prends.

[TDA4565]

merci à Raffou d’avoir posté les explications sur l’algorithme de recherche du 68705

ces personnes ont peut-être tourné la page ou ne sont malheureusement plus de ce monde,

pour le discret11 on sait qu’une partie de la recherche a été faite par le CCETT (centre commun d’études de télévision et télécommunications basé à Rennes), au milieu des années 70, ensuite ça a été repris par philips/RTIC, avec un cahier des charges moins ambitieux (pas de gestion VBI des droits, pas de carte d’accès, pas d’inversion négative de la vidéo) afin de réduire les coûts,

on peut voir des photos du décodeur expérimental « discret » dans le laboratoire du CCETT datant de 1976:

1976_06_00_BM_BM_021.jpg985×720 118 KB

1976_01_27_BM_BM_001.jpg1006×720 159 KB

1976_01_27_BM_BM_002.jpg989×720 174 KB

a3c7.fr/PhotoListPublic.php

on peut aussi se poser la question pour les autres systèmes de cryptage analogique, comme le syster, le videocrypt, l’eurocrypt, dans les années 2000 au début d’internet il y a eu quelques sites de hackeurs en électronique qui ont publié des montages électroniques pour ces décodeurs et dans les années 90 il y a eu un jeune chercheur en sciences qui a médiatisé ses tentatives de hacking du videocrypt et du syster, l’Allemand Markus G. Kuhn :

cl.cam.ac.uk/~mgk25/
cl.cam.ac.uk/~mgk25/tv-cryp … tisky.html
lien wikipédia

pour l’eurocrypt on peut se procurer les spécifications techniques du d2mac où l’eurocrypt y est expliqué il me semble :
etsi.org/deliver/etsi_i_ets … 50e01p.pdf

mais en effet il y a beaucoup d’anonymes parmi ces hackeurs des années 80 et 90, et encore beaucoup de secrets concernant des aspects comme la gestion du VBI, les puces et les firmwares cryptés des décodeurs syster, sans oublier le décodeur discret11 (ou 12) belge et islandais qui n’ont pas de clavier (gestion des droits par infos VBI)

Franchement, depuis plus de 30 ans, 99,99% des gens sont passés à autre chose, ce n’est pas plus compliqué que ça.
Et parmi les 0,01% restants, combien fréquentent ce forum ?
Et, comme le dit Mannix, sans parler bien sûr de ceux qui ne sont plus de ce monde …

Heureusement que j’ai écrit : « sur aucun forum ».

Beaucoup de gens sont passés à autre chose, très certainement. Et d’autres ne sont plus là, bien entendu.

Pour ce qui est de la catégorie ‹ officieuse › de décodeur, je reste perplexe. Avoir la capacité de concevoir un tel système est remarquable, et oublier un tel épisode d’une vie, je ne l’explique vraiment pas. [TDA4565]

Je ne sais pas exactement ce qu’a fait le CCETT mais avant la reprise par RTIC pour en faire un produit c’est le LEP (Laboratoire d’Electronique et de Physique de Limei-Brévannes) qui a étudié 2 versions de cryptage d’image.
-un destiné au départ à des applications professionnelles ne nécessitant pas une inintelligibilité totale de l’image, entièrement analogique.
-un autre où l’image était totalement inintelligible nécessitant la numérisation pour le traitement, plutôt destiné à des applications de TV payante grand public.
Etant donné le coût exorbitant des CAN / CNA vidéo et de la mémoire au début des années 80, c’est le premier système qui a été retenu pour devenir le Discret même s’il était loin d’être idéal.

PETIT APARTE: Pour mémoire, c’est également le LEP qui a développé le premier système de télécommande par infrarouge de Philips (baptisé TELCO) qui a été utilisé avant le RC5. De mémoire ce sytème permettait de transmettre 32 commandes, dont 6 pour les 3 fonctions analogiques pour un seul type d’appareil.
Les circuits intégrés développés pour ce système s’appelaient SAF1031 puis SAF1039 (émetteur) et SAF1032 (décodeur).

Bonjour
N’était-ce pas le code RC4 ?

Effectivement cela a été appelé RC4 par la suite, Telco c’était le nom de développement du système et des ICs.

les « concepteurs » ne sont pas tous mort !!! mais certains se sont retrouvés devant des tribunaux correctionnels et bien qu apres de rudes combats (tres couteux) avec l aide d avocats de 1er plan leurs condamnations s est révélé assez modeste (10000 euros contre 2 millions d euros réclamés) il est interdit de commenter une decision de justice nous concernant !!!
par contre autour d un verre au bar du commerce il est surement possible de raconter des histoires passionnantes !!!

Bonjour,

J’ai supprimé les messages qui ont fait suite à mon post sur l’attendu d’un message sur le forum (formule de politesse)

Je viens d’ouvrir un nouveau sujet ou vous pourrez vous exprimer sur le sujet

viewtopic.php?f=5&t=253086

Désolé d’avoir pollué votre sujet

Cordialement

L’Administrateur du Forum Radiofil

Bonjour tout le monde …

Juste pour mon information personnelle et sans commenter aucune décision que ce soit, l’action en justice sus-citée
concernait-elle la fabrication, commerce ou détention de décodeur C+ illicites ou bien le piratage de cartes C±Canalsat numériques ??
Merci de cette infos
Amitiés
Serge

Amélioration de l’algorithme de recherche

La lenteur et le peu de ressources internes du 68705 limitaient les performances de la recherche.
? Déjà rien qu’en portant le nombre de prélèvements par ligne à 16 au lieu de 4, soit un toutes les ?3µs, on quadruple le nombre de piles d’échantillons et on multiplie d’autant les espérances de succès .
? N’étant plus limité par la mémoire interne, on peut stocker les prélèvements d’une trame entière qu’il faudra cependant restreindre d’une cinquantaine de lignes en haut et en bas de l’image pour cause de bandes noires inhérentes aux films en cinémascope. On arrive ainsi à pratiquement doubler la hauteur des piles d’échantillons (sur 186 lignes au lieu de 94).
? En considérant à la fois les augmentations et les diminutions d’intensité, on double encore les chances de capturer des variations de luminosité dans l’image.

Avec de telles retouches, les espérances de succès se retrouveraient multipliées par 16, le hic c’est que le taux d’erreurs (?3%) reste le même si l’on se contente toujours de 18 échantillons consécutifs certifiés pour reconstituer le mot d’initialisation du GPA. Il en faudrait pas moins de 54 pour garantir un taux de réussite de 100% selon la feuille LibreOffice du précédent message.

Il va donc falloir rechercher, parmi toutes les piles de 186 échantillons, une série de 54 échantillons consécutifs certifiés pour atteindre cet objectif. Une image quelconque ne comportant pas nécessairement une zone quasi verticale de variation de luminosité d’une telle hauteur, à défaut, il va donc falloir se contenter de la série qui possèdera le meilleur score, en tout cas supérieur à 18, pour maximiser le taux de réussite.

Le classeur LibreOffice ci-dessous simule ce nouvel algorithme de recherche sur une seule pile d’échantillons. Dans la réalité la recherche devra se faire sur autant de piles que de prélèvements effectués à intervalles réguliers dans les 52µs actives de chaque ligne de la 1ère trame du cycle.

Recherche.New.ods.TXT (236 KB)
Ce classeur comporte 6 feuilles, elles sont toutes protégées sans mot de passe.

? La feuille « GPA »: Colonnes D à N, les itérations successives du GPA sur les 6 trames d’un cycle. En colonne O, le retard associé.
Le mot d’initialisation peut être modifié bit par bit: double-cliquer dans une des cellules D2 à N2 pour inverser à chaque fois l’état du bit correspondant.

? La feuille « Echantillons »: Colonnes D, E, F et G: Simulation des échantillons prélevés respectivement aux instants B, C, F et G selon le diagramme en tête des colonnes.

? Les feuilles « Echantillon_X »: Une feuille dédiée à la recherche pour chaque instant de prélèvement B, C, F ou G dans sa pile d’échantillons respective.
? Colonne D: les échantillons, les 50 premiers et 50 derniers de la trame sont ignorés. Pour créer des erreurs, chaque échantillon peut être inversé individuellement en double-cliquant dans la cellule associée, pour ce faire, la protection de la feuille doit provisoirement être inhibée. La couleur du fond de la cellule vire alors au rouge ou redevient neutre pour signaler s’il y a inversion ou pas,
? Colonne E: le résultat du XOR entre le 2ème et le 11ème échantillon après l’échantillon courant.
? Colonne F: le résultat de la comparaison entre le résultat du XOR et l’échantillon courant. (0 si « ? », 1 si « = »).
? Colonne G: comptabilisation des exactitudes et des inexactitudes consécutives. Afin de les distinguer, les premières sont comptées positivement et les secondes négativement. Le compte est réinitialisé à ±1 quand le résultat de la comparaison est inverse du précédent.
? Colonnes J à T: reconstitution des itérations à rebours du GPA jusqu’à la première ligne active (336) de la trame.

? Cellule G1: meilleur score sur les inexactitudes consécutives, négatif, ce score correspond à une augmentation de luminosité dans l’image.
? Cellule G2: meilleur score sur les exactitudes consécutives, il correspondent à une diminution de luminosité.
? Cellule H2: meilleur score des deux en valeur absolue, il est nul s’ils sont égaux.
? Cellule I2: numéro de la ligne où le contenu du GPA reconstitué devra être inséré, vaut celui de la 10éme ligne après celle affichant le meilleur score. Ce numéro est nul pour un score inférieur à 18.
? Cellules J2 à T2:: reconstitution du contenu du GPA à partir des 11 derniers échantillons appartenant au meilleur score. L’état des échantillons, donc celui des bits, est complémenté si ce score est négatif. Le contenu est vide si le score est inférieur à 18.

? Ligne pointée par la cellule I2: C’est la destinataire du contenu du GPA reconstitué dans les cellules J2 à T2 .
? Lignes en dessous de cette ligne: Le contenu des lignes suivantes demeure vide car il est indéterminé.
? Lignes au dessus de cette ligne: Le contenu est itéré à rebours pour toutes celles qui la précède jusqu’à la première ligne de la trame (la 336). Sur cette dernière ligne, on obtient finalement le mot clef qui a initialisé le GPA en début de cycle (cellules à couleur de fond jaune).

Sur cette feuille concernant une pile d’échantillons prélevés à l’instant « B » et avec le GPA initialisé à 072CH (111.0010.1100B) au départ, on obtient un score de 31, ce qui fausserait le résultat s’il était pris en compte. Il est donc impératif de réaliser un nombre conséquent de prélèvements à intervalles réguliers dans les lignes afin d’espérer trouver un score bien meilleur qui proviendrait d’une configuration telle que celles des instants « C » ou « G ». L’idéal serait qu’il soit supérieur ou égal à 54 pour obtenir 100% de réussite car on aurait alors la certitude absolue que les échantillons considérés sont assimilables à cet instant au contenu du GPA.

comme j’ai du temps libre je suis en train d’implémenter cette recherche du code utilisant l’algo du 68705, les explications postées par Raffou sont très utiles, je posterai les résultats prochainement,

sinon il y a le code source du 68705 de disponible, quelqu’un avait posté le code source assembleur dans l’ancien sujet, je l’ai retrouvé

68705.asm.txt (46.3 KB)

Excellent

Si tu as besoin de bêta testeur … [TDA4565]

Une question annexe, qui n’a rien à voir avec l’algo de recherche du code sur 68705.

Depuis la fin des années 80, je me demande quel est le procédé d’affichage des ‹ célèbres › fenêtres de recherche qui apparaissaient de façon très nettes à l’écran pendant la phase de recherche du code.

Le proc pilotait des commutateurs vers les lignes à retard, mais comment diable était-il possible d’afficher ces fenêtres en ‹ surimpression ›?

[TDA4565]

Peut-être par envoi d’un signal RVB…

Je ne pense pas, personne ne câblait les signaux RVB, la composite suffisait. [TDA4565]

Tout est dans le source « 68705.asm » récemment posté par Mannix54: sous-programme en L04DB et plus particulièrement en L04F6.
? En temps normal, les retards sont commutés pendant le HBI pour ne pas perturber l’image,
? En phase de recherche on alterne entre le retard nul et le retard 2 à 4 reprises au beau milieu de certaines lignes (387 à 481) ce qui ne manque pas de produire un certain effet visuel comme vous avez pu le constater.

Merci pour l’explication, c’est clair.

Et du coup, je comprends maintenant le rendu de cet effet visuel, sur lequel je me questionnais depuis si longtemps. [TDA4565]

j’ai publié une version beta de cryptimage (1.5.3) :
cryptimage.vot.pl/cryptimage.php

elle contient un mode de recherche de la clé 16 bits, pour l’instant ce n’est pas encore l’algo 68705, mais un mode « force brute », plus tard je rajouterai un second mode de recherche basé sur l’algo 68705, au final on aura le choix entre ces deux types de recherche de clé,

donc pour l’instant c’est la méthode de recherche par force brute :

ça va scanner le fichier vidéo et retrouver la clé de 16 bits, on peut spécifier le nombre de trames à scanner dans l’onglet « audio/vidéo → nombre de trames », au final ça affichera une fenêtre donnant les niveaux d’audiences trouvés, les mots de 11 bits (avec entre parenthèses la fréquence d’apparition du mot de 11 bits) et le mot de 16 bits, ici un exemple sur une vidéo « multicode » audience 6, 4, 2, 5 :

pour augmenter les chances de succès on peut régler le seuil de détection du blanc/noir pour les lignes 310/622, par défaut c’est réglé sur 80, si vous utilisez des bandes VHS comme source et qu’elles sont abimées alors il faut baisser le seuil vers 30~40 (pousser le curseur vers la gauche)

voici en guise de test des vidéos discret11 issues de cassettes VHS, créées par dreambox59 :
we.tl/t-HkxLnLiIVJ