Décodeur et cryptage Discret 11

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.

2onglets.PNG
? 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).

Onglet_B.PNG
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 :smiley:

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 ›?

:question: [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 :

options.jpg

ç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 :

infos_key.jpg

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

j’ai réuni dans un zip les captures de cassettes V2000 qu’avait faites TDA4565 et qui ont plus de 30 ans d’âge, il avait capturé que l’image, son cable RCA (ou la péritel) ayant un souci pour la partie son :
we.tl/t-kdNGFnuu8B

la recherche de clé fonctionne avec cryptimage, à condition de mettre le curseur de niveau de blanc sur la valeur 40,

  • vidéo « bande-annonces »
    annonces.jpg
    il faut scanner tout le fichier pour la recherche de clé, car il y a un changement d’audience dans les dernières secondes (vidéo multicode)

  • match de foot Nantes - Marseille
    nantes-marseille.jpg
    audience 7, perte de synchronisation pendant quelques trames

  • un film
    film.jpg
    pas trop de souci, audience 4

Le décodeur à 400 euros attend toujours désespérément un acquéreur :laughing:

leboncoin.fr/collection/1397968635.htm/

Bonjour à tous,

Message pour Mannix54.

ça fait plusieurs années que tu bosse sur ce logiciel de cryptage, grâce à lui, certains d’entre nous ont pu faire revivre le bon vieux D11 !

Alors…, pour te remercier de ton total dévouement je t’ai préparé un petit cadeau, une vidéo « Générique CRYPTIMAGE » sur le thème Ellipse que tu connais bien, qui est certes pas grand chose mais qui je l’espère te fera plaisir…

Ainsi il pourra éventuellement intégrer la page d’accueil de ton site comme vidéo de présentation… :wink:
wetransfer.com/downloads/9d0c4d … ient_email

Cryptimage.PNG

merci, c’est bien réalisé :wink:

Nous n’avons plus de nouvelles du membre humeur … c’est bien dommage d’autant qu’il possède quelque chose de jamais vu dans l’histoire du D11.

Si humeur passe ici … [TDA4565]

il nous avait laissé un cadeau sympa à la fin de l’année dernière :
youtube.com/watch?v=bIdxGcU … e=youtu.be

ça me fait penser qu’en 1987 un camarade de classe m’avait affirmé qu’une de ses connaissances avait réussi à décoder canal+ avec un micro-ordinateur thomson MO5, probablement avec le même type de périphérique utilisé par l’exelvision exl 1000, mais il ne m’avait jamais donné de détails précis, juste que la séquence des retards étaient sauvegardée sur cassette audio,

je pense que cet attelage « ordi 8 bits + périphérique de décodage » a été très vite délaissé au profit des décodeurs pirates classiques entièrement automatiques à base de microcontroleur 68705, d’où sa rareté

Ah … la légende du MO5 décryptant du D11.

Je l’ai eue aussi à l’époque, mais sous une autre forme. Il utilisait soit disant le module d’incrustation, sauf que dans les docs de ce module, il ne mentionnaient aucune entrée vidéo. J’avais classé ça dans les intox.

Et comme depuis je n’avais jamais rien vu sur le décodage via un ordinateur, j’ai trouvé le sujet de humeur particulièrement intéressant, on avait enfin quelque chose de tangible. [TDA4565]

Bonjour
Ce n’était pas une intox, le module d’incrustation du MO5 permettait bien d’incruster une image venant de l’ordinateur par dessus un programme TV. J’ai utilisé ce module, mais pas pour décrypter du D11.
Je n’ai pas la doc du MO5 et son module sous la main, mais je peux la chercher si ça intéresse quelqu’un :wink:

Entendons nous bien: ce que j’avais qualifié d’intox, c’est le décodage du D11 via ce module d’incrustation.

Le module, je l’ai utilisé un peu dans un magasin d’informatique près de chez moi, ça me fascinait à l’époque de pouvoir mixer l’image du MO5 et de la TV. [TDA4565]

le MO5 avait un port d’extension à l’arrière à 2x19 broches, ce qui permet aux bidouilleurs d’interfacer l’ordinateur avec des cartes de leur propre fabrication,

mo5_extension.jpg

l’article de science et vie (numéro 808) donne des détails sur la manière d’utiliser un ordi 8 bits pour décrypter canal+, ça consiste à numériser ligne par ligne une trame, via un périphérique, quelques lignes s’affichaient sur l’écran de l’ordi, l’utilisateur devait ensuite aligner chaque ligne avec son clavier, en entrant un des 3 retards, c’est expliqué en page 4 de ce pdf :

we.tl/t-oAVgPRJhv0

d’après un article un module de numérisation d’image était vendu par thomson (650 francs à l’époque) :

mo5.jpg

le-grenier-informatique.fr/m … svm6-4.jpg

Je connais l’article science et vie, que j’ai toujours trouvé évasif.

Techniquement, rien n’empêchait à l’époque via un hardware additionnel, à un micro-ordinateur de décrypter du D11, mais à nouveau, je n’ai jamais rien vu de concret.

Et ce science et vie ne prouve rien à mes yeux, le ton employé me fait plus penser à ‹ ce qu’il faudrait faire ›, même si ils disent qu’ils ont réalisé une carte. Une photo du hardware en question ne les engageait à rien, et ne les aurait pas mis en danger.

Ton article sur le module de numérisation est intéressant, je ne connaissais pas ce module. Si un tel module a vraiment permis l’acquisition d’image, ça change la donne. [TDA4565]