Cryptage "maison"

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 :
Inverseur video PAL 01.jpg
Inverseur video PAL 02.jpg
Inverseur video PAL 03-.jpg

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 :
Photo0907.jpg

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 :
Photo0910.jpg

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 :

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 …

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

inverse.jpg

un petit coté artistique toutes ces couleurs inversées

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 :

InvVid.GIF
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…

LignesTest.New.JPG
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.

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à !

Bonjour,

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

Bonjour

:question: :question: :unamused:

bonne journée

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

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.

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

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

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:
pic_2_2.jpg
pic_2_1.jpg

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

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 :
vlcsnap-2016-08-27-22h09m46s765.jpg

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)

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 …

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.
invflg_fi[1].gif

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

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

bloqué donc pendant quelques jours

non ! pas bloqué, j’ai sacrifié un cable péritel pour me faire ma rallonge

et voici donc le résultat :
pic_6_2.jpg
pic_6_1.jpg
pic_5_3.jpg

le pic peut donc bien lire le message tatoué sur la ligne 21 (ou environ !)

problème : le magnétoscope ne fait pas marcher sa péritel « décodeur » en lecture k7
seule la péritel 1 « TV » marche; j’ai donc du déconnecter le tv pour voir ces images .

Mais alors, le but de la péritel :
-envoie du signal crypté
-retour du signal clair
-commutation lente

n’a pas d’objet , est-ce qu’il y a une « norme » que les constructeur de magnéto ont mis pour ne pas permettre le décodage sur k7 ???

n

bonsoir , je continue mon petit bonhomme de chemin …

le décrypteur lisait la cassette enregistrée cryptée, et je voyais clairement un sur-cryptage
… grattge de cheveux, puis, aux vues des captures plus haut, je me dis, il y a peut être un problème de lecture
des bits de synchro

Je décide donc de modifier le code : la ligne 23 = seulement 5 bits
1 0 1 X Y ; le 101 étant le code d’identification , le X étant le raz compteur pour synchroniser la table et le Y … une option future …

évidemment les bits grossissent et deviennent plus facile à lire :
ici : 101 et x à 0 puis 1 Y étant figé à 1
pic_13_1.jpg
pic_13_2.jpg

et ça ne marche toujours pas … je vois toujours du sur-cryptage

je me décide donc à faire une table beaucoup plus simple 255,0,255,0,255… etc …
pour avoir toujours 8 lignes en clair et 8 lignes inversées

surprise !!
mes 8 lignes ont un peu la gigue !!! or, avec une seule ligne , c’est le décalage dans la table = sur cryptage .
Re-grattage de cheveux, et j’ai fini par trouver le coupable : qques instructions en trop qui dépassent de la ligne active et mordent le top synchro ligne suivant ; certaines lignes « ratent le train » du top synchro
et c’est le décalage de lignes .
Correction, et voila une image cryptée stable (8 lignes positives ;8 lignes inversées)
je fais pareil au décrypteur ,… et j’ai vu mes premiers résultats à l’écran ce soir !!!

je ferai des captures demain pour que vous puissiez voir

par contre, il apparait à l’écran que la question du blanc est effectivement importante …

voici juste qques photos d’écran :

d’abord, les photos cryptées (j’ai remis la table aléatoire, mais elle est fixe)
Photo0912.jpg
Photo0914.jpg

et les photos dé-cryptées :
Photo0916.jpg
Photo0919.jpg

le procédé logiciel est donc 100% validé
mais en analogique, il y a un léger problème la couleur ne suit pas vraiment …

evidemment, j 'utilise une cassette vhs et un modulateur UHF, ce n’est peut être pas génial …

à suivre …

bon , je progresse (très) lentement …

j’ai abandonné le magnétoscope et le modulateur UHF : trop de problème et d’incertitudes sur la qualité glogale

je suis passé à ma carte d’acquisition sur pc : j’enregistre sur pc la vidéo cryptée
puis je la grave sur un cd RW et je peux la relire sur ma platine dvd pour le décrypter

j’ai été obligé de passer à la ligne 25 (le 23 n’est pas à l’écran …)

du coup vous pouvez voir les captures en bonne qualité (maxi 4000 bits sec sinon ma platine saccade)

je suis repassé en 8 lignes normales (positives) et 8 lignes négatives

ça aide à voir
et je me suis aperçu que j’avais encore un décalage d’une seule ligne:
vlcsnap-2016-08-31-20h53m07s109.jpg

et l’extrait vidéo :
dl.free.fr/ifbk3fZXm

c’est bien d’être allé jusqu’au bout de l’idée de créer ce crypteur, bravo,

pour éviter la case gravure CD il y la possibilité d’utiliser une clé USB si vous avez un adaptateur TNT équipé d’un port USB pour la lecture de fichiers vidéos, 30 euros et ça peut servir de magnétoscope numérique ( sans DRM contrairement à une TV LCD équipée d’un port USB )