Cryptage "maison"

[jmespe]

bonjour à tous,
suite au très prolifique sujet "décodeur canal +" sur ce même forum ,
je vous propose un cryptage "maison" ... à faire soi meme

Le gros problème, c'est le manque de décodeur officiel
J'avais il y a fort longtemps fait un inverseur vidéo paru dans le haut parleur :

Ce type de montage donne de bons résultats avec virtualdub et le filtre "invert"
on obtient un avi (xvid) inversé
et l'inverseur le dé-crypte sur la prise péritel :

[jmespe]

A l'époque, j'avais remplacé le transistor T2 (extracteur de synchro) par un TDA2595 bien plus robuste et précis.
Et comme je débutais en PIC, les monostables sont chez moi remplacés par un 16F84A (qui compte les lignes pour ne sélectionner que les lignes entre 30 et 255 d'où les marges en haut et bas)

cela donne ce genre d'image :

Or , je viens d'avoir l'idée de ne plus inverser les lignes de 30 à 255
mais des les inverser ... en jetant une pièce de monnaie !!!
inversée parfois et non-inversée les autres fois , on obtiens donc une vidéo comme celle ci :

http://dl.free.fr/frbDIcnjT

vous voyez où je veux en venir :
avec ce montage simple (qques trans un aop et un commut 4053) on peut faire un crypteur / décrypteur)

le crypteur est quasi fini il me reste à faire son cousin (proche)
car si on re-inverse les memes lignes , l'image est supposées redevenir normale , non ?

la suite quand il fera moins chaud
si certains sont interressés, qu'ils le fassent savoir !
commentaires ouverts !

cordialement ...

[Mannix54]

une capture d'écran depuis le fichier vidéo posté :

inverse.jpg (88.82 Kio) Vu 8797 fois

un petit coté artistique toutes ces couleurs inversées

[Raffou]

Le schéma tel qu'il avait été dessiné pour être contenu dans la largeur de page du HP n'est pas des plus compréhensible, c'est pourquoi un petit remaniement s'imposait :

Maintenant, c'est plus bien plus clair, un système de clamping permet bien d'obtenir sur l'émetteur de T5 un niveau du blanc asservi à celui du noir. Le problème est que ce premier niveau est tributaire du seuil de 3 diodes (D2, D3 et DEL2) et que le signal vidéo est d'une amplitude relativement faible pour masquer suffisamment leurs disparités cumulées.
Pour la reproductibilité du montage, peut-être eut-il valu mieux remplacer cet empilage de diodes par un régulateur shunt genre TL431 dont on peut ajuster la tension à ses bornes. Encore cela suppose-t-il que l'amplitude des signaux des différentes sources qui seront utilisées ne soient pas trop en deçà de la norme pour assurer des niveaux stables du noir et du blanc tout au long de la chaine de codage/décodage.

La vraie solution serait d'aligner le niveau du blanc sur l'amplitude réelle du blanc. Hors on est assuré de bien obtenir cette information pendant 5 µs sur le palier de l'impulsion B2 des signaux de test présents sur les lignes 17 et 330, et cerise sur le gateau, elle est même exempte de sous-porteuse PAL ou SECAM..

L'impulsion de clamping nécessaire devrait pouvoir se générer facilement avec le pic 16F84A compteur de lignes dont il était question dans le second message. Le souci est que cette référence n'est présente que 5 µs à chaque trame de 20 ms soit 1/4000ème du temps, rapport qui devient problématique pour un ajustement rapide de la charge/décharge lente du condensateur réservoir du système de clamping.

L'autre objection majeure est que les signaux de test ne sont pas forcément présents dans tous les signaux vidéo...

Il reste une autre solution moins évidente à mettre en oeuvre mais plus permanente puisque sa récurrence est celle de la fréquence ligne : la mesure de l'amplitude du top de synchronisation. Deux possibilités :

• La mesure du palier du noir par rapport au fond du top de synchronisation, le niveau du blanc vaudrait alors les 100/30 de cette amplitude par rapport au fond du top.
• La mesure du fond du top de synchronisation par rapport au niveau du noir, le niveau du blanc vaudrait alors les −70/30 de cette amplitude par rapport au niveau du noir.

Les solutions d'alignement sur le fond de top ainsi que celle de clamping sur le niveau du noir étant déjà connues, la production du niveau du blanc pourra être obtenue à partir de ces deux niveaux grâce à un amplificateur opérationnel dont on musellera le gain à 3,33 ou à −2,33 par des résistances de précision.

[jmespe]

bonjour raffou

dans le schéma ainsi que vous l'avez dessiné, c'est tout le bas qui disparait

le T2 sert à extraire la synchro : il est remplacé par un LM1881 ou, mieux, un TDA2595
les 2 monostables sont remplacés par le pic 16F84A

Par contre, dans votre dessin, vous avez oublié de noter le +5 V sur l'émetteur de T5
ce +5V issu d'un 7805 est stable, donc le courant dans les 3 diodes aussi .
Par contre, j'avais noté des disparités entre les signaux vidéos plus ou moins vigoureux suivant la source,
donc j'avais modifié un peu cette partie avec une res ajustable (il faudrait que je redessine ma plaquette , car depuis le temps , j'ai oublié !)
cette res ajustable permet de faire varier de qques % le niveau moyen du gris pour faire l'inversion
C'est à l'usage très simple et pratique

Les signaux de test que vous mentionnez ne sont plus trouvable nulle part !!!
et surtout pas en sortie d'une platine divx ou boitier multimédia

Le pic se contente de générer une impulsion de 1µsec en début de ligne
pour commander la patte 9 du 4053 : mémorisation du niveau du noir

il me reste à me concentrer sur le tatouage de la ligne

puis ce week end sur le décodeur !

bonne fraîcheur à tous d'ici là !

[Mannix54]

Bonjour,

Or , je viens d'avoir l'idée de ne plus inverser les lignes de 30 à 255
mais des les inverser ... en jetant une pièce de monnaie !!!
inversée parfois et non-inversée les autres fois , on obtiens donc une vidéo comme celle ci :

dans ce crypteur/decrypteur est-ce qu'il y aura un moyen pour l'utilisateur de contrôler l'aléatoire ?

par exemple un clavier en façade pour taper un code qui permettra d'initialiser le générateur pseudo-aléatoire à une valeur précise,

sans clavier je suppose alors que la séquence aléatoire est toujours la même

[FBG]

Bonjour

je suppose alors que la séquence aléatoire est toujours la même

bonne journée

[Mannix54]

sans possibilité de définir la valeur de départ du générateur de valeurs pseudo-aléatoires ( pour son initialisation ) alors la séquence générée sera toujours la même à chaque fois qu'on allume l'appareil, genre "6,1,7,4,3 etc..", on éteint et on rallume l'appareil : même séquence générée : "6,1,7,4,3 etc..", pas idéal dans le cadre d'un codeur/décodeur, les vidéos auront le même schéma d'inversion pour les lignes, c'est comme si tout le même monde avait la même serrure et même clé pour sa porte,

il n'y a jamais de vrai hasard dans un générateur de valeurs pseudo-aléatoires ( d'où le terme pseudo ), l'illusion de l'aléatoire vient du fait que la valeur d'initialisation ( seed en anglais ) du générateur n'est pas la même à chaque fois qu'on l'utilise, certains programmes utilisent le temps en secondes d'une horloge pour initialiser le générateur, mais c'est toujours la même suite de nombres qui est générée, le point de départ n'étant pas le même ça donne l'illusion du hasard, renforcée par le fait que la suite de nombres est très grande

[Raffou]

Ce fil de discussion est une bonne occasion pour se remémorer le système discret tel qu'il avait été conçu à l'origine car une de ses particularités était aussi d'inverser la polarité du signal vidéo.
Selon le brevet d'invention FR2330236 :

• Le signal de luminance seul était inversé selon la parité de la trame combinée avec un bit du GPA.
• Le signal de luminance subissait en plus un retard pseudo aléatoire alors que la chrominance (codage SECAM) subissait un retard fixe.
• La fonction de rebouclage du GPA d'une longueur de 10 bits n'était pas figée, elle pouvait être modifiée à chaque nouvelle image pour générer des séquences pseudo-aléatoires différentes d'une longueur inférieure ou égale à (2^10)-1 mais en tout cas supérieure au nombre de lignes d'une trame et ceci indépendamment du mot d'initialisation (seed) de ce même GPA à géométrie variable.
• La ligne à retard à CCD, une SAM64 Reticon, permettait de retarder le signal vidéo jusqu'à 5,33 µs. En pratique le cumul des retards élémentaires était limité à la moitié des 64 possibles, et même avec cette limitation on dépassait les 2 µs admises comme amputation maximale raisonnable de la largeur des images.

[jmespe]

bonjour
oui, il y a un générateur PSEUDO aléatoire qui pour l'instant est une table de chiffre (générés sur un site internet)

il n'y a aucun problème à mettre ensuite un clavier (euh, je vais être un peu juste en pattes sur le 16f84a)
ou alors
mettre des clés dans l'eeprom du pic
mettre les cles dan une 90c06 qui pourrait avoir la forme d'une carte à puce

mais dans ces 2 cas: programmateur
sinon, oui, clavier, on verra à la fin, on fera un sondage !!

à raffou; y a t il moyen de voir les 2 brevets dont il est question ( 2 128 760 et 2 195 139) ?

au fait, certains d'entre vous connaissent ils un cryptage ayant utilisé l'inversion ligne ?
(genre luxcrypt) ?

[Raffou]

y a t il moyen de voir les 2 brevets dont il est question ( 2 128 760 et 2 195 139) ?

Voici les liens vers les documents en question : FR2128760 et FR2195139

[jmespe]

oui, la lecture des brevets est essentiellement faite de verbiage
(suffisamment flou et global pour s'approprier tout ce qui ressemble à votre invention !)

bref, j'ai un peu avancé avec le tatouage
j'ai mis un octet sur une ligne en haut

laquelle ? ; je ne saurais trop le dire
-dans mon programme, j'ai mis le no21
-sur mon oscillo, c'est plutot la 25

en tout cas, elle est visible:

j'ai tatoué 8 bits : 1 0 1 x x x x x le xxxx étant le compteur trame sur 5 bits

c'est visible sur une capture vidéo :
http://dl.free.fr/fHJEccSD5

Il faut donc que je triche, car la vidéo influe clairement sur cette ligne
je vais me faire un fichier en "léger" 16/9

à suivre ...

[jmespe]

bon , très chaud aujourd'hui donc pas trop d'électronique ...

j'ai juste ajusté les marges et fait qques essais
j'ai des doutes sur les numéros des lignes vidéos ...
bref, le tatouage est visible sur cette image :

et j'ai augmenté le bitrate de ma carte de capture (qui , me semble-t-il, ne rends pas très bien)
comme on le voit sur cette vidéo en 10 000 de débit binaire (le maxi en réglage)

http://dl.free.fr/fbYxMNj8N

Il reste aussi à voir le niveau du gris d'inversion qui effectivement, n'est pas critique en décodage
mais le sera en codage

Demain, je commence le décodeur ....

[Raffou]

au fait, certains d'entre vous connaissent ils un cryptage ayant utilisé l'inversion ligne ?
(genre luxcrypt) ?

Est ce que "luxcript" ne serait pas plutôt la dénomination d'un logiciel ou d'un appareil à décoder les signaux SSAVI (Synch Suppression and Active Video Inversion) ?
Le lien vers la SSAVI Scrambling System FAQ
Les brevets connexes cités dans la page SSAVI Links and References : US4222068 et US4460922

Les pages accessibles sur google books concernant le bouquin "Video Scrambling & Descrambling for Satellite & Cable TV" font aussi état de ce système SSAVI à partir de la page 50, quelques pages plus loin il est aussi question du système VideoCypher II ™ ou VCII toujours à base d'inversion vidéo.

Quoi qu'il en soit, tous ces systèmes à base d'inversion vidéo insèrent à un moment donné des lignes, trames ou images un échantillon au niveau du blanc car cette information est essentielle au circuit d'alignement du réinverseur à la réception.

Dans le cas du système SSAVI, ce sont les lignes 22 et 335 qui véhiculent cet échantillon dont la durée détermine conjointement la polarité des lignes de la trame associée.

Source : http://www.kolumbus.fi/pami1/ssavi/invflg_fi.gif

invflg_fi[1].gif (4.08 Kio) Vu 8308 fois

[jmespe]

bonjour raffou

merci pour ces liens, quel dommage que le 2ème soit quasi vide de tous liens actifs
mais le premier est très intéressant

Le niveau du blanc semble être un problème, mais toutefois
Mon crypteur n'aura pas, quoi qu'il arrive, de référence de blanc(source = dvd)
Le décodeur pourrait l'avoir (si je le fabrique !!) , mais pour le décodeur c'est moins important ;
le réglage à l'oeil suffit ,par contre, pour le codeur, le réglage à l'oeil est moins évident
(ça paillote dans tous les sens)

bon, je me le mets dans un coin du cerveau ...
l'important est de faire le décodeur
j'ai fait aujourd'hui la lecture du tatouage av le montage issu du déco bien connu :

lecture luminance.jpg (54.26 Kio) Vu 8255 fois

et ça marche très bien sur une mire
ceci dit, il inverse (bon, je ferai un "comf" dans mon progr)
il reste à le tester sur la cassette enregistrée cryptée (avec le tatouage)
mais il me manque une rallonge péritel

bloqué donc pendant quelques jours