Cryptage "maison"

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 )

« jusqu’au bout » …

oh non, pas encore,il me reste à voir :
1-la linéarité (pourquoi le réglage est-il aussi difficile à faire et impossible à faire correctement ?)
je vais prendre des images de mire et faire des mesures à l’oscillo
particulièrement sur le collecteur et émetteur du transistor T6 (c’est lui qui fait le signal positif / négatif)

2-le clamp avec la diode D1 (je pense y mettre une bat42) pour voir la différence

3-revalider la table aléatoire et son balayage (actuellement, je suis en fixe « clrf clef » à chaque début de trame)

« pour éviter la case gravure CD » euh, en fait , j’ai un lecteur usb autonome (peekton little)
suffit que je le ressorte !

C’est par ce que à l’origine ce montage était destiné à la stricte inversion vidéo et non pas à la coexistence alternée de la vidéo directe et de son inverse.

A ce sujet, le truqueur vidéo décrit par Hervé Cadinot dans son bouquin « Montages électroniques pour vidéo » me semble plus approprié comme base de départ pour réaliser ce genre de codeur et/ou de décodeur étant donné que vidéo directe et inverse sont créées à partir d’un même amplificateur à entrées/sorties différentielles : le NE592. Avec ce type de composant, on est déjà assuré que les voies directe et inverse ne sont pas dissemblables, et qu’elles doivent avoir pratiquement les mêmes performances et caractéristiques.

ha, n’hésitez pas à m’envoyer le schéma !!

ceci dit : vous allez rire (si !) mais ma plaquette est mal câblée depuis qu’elle existe : 10 ans !
la visu à l’oscillo a été radicale : le signal inversé était tronqué !!!
j’avais oublié un fil « + » sur un émetteur de transistor.

problème corrigé : le signal est bien inversé ;
sur une mire de barre, il y a bien un escalier qui monte et l’autre qui descend exactement pareil MAINTENANT .

par contre,cette « réparation » m’a bousillé le réglage du gris moyen
donc je corrige ça, et j’espère faire une capture d’écran propre ce soir.

mais bon, passé 27° je suis exponentiellement moins efficace …

merci raffou
j’ai bien reçu le schéma , je le regarderai plus en détail , on en reparlera sans doute

j’ai donc pu modifier ma platine et avoir un réglage de gris moyen … correct et viable !

démonstration avec cette image cryptée:
vlcsnap-crypté.jpg

ne regardez que le haut de la mire :8 lignes + 8 lignes inversées
regardez le gris moyen (les carreaux de la mire) ils sont quasi inertes …

et voici la meme image DE-cryptée
vlcsnap-décrypté.jpg

ne regardez que le haut de la mire : j’ai (encore ?) un problème de décalage d’une ligne
regardez où j’ai mis le x : meme la couleur est bien décodée

et j’ai remis une table 8/8 lignes plus longue pour mieux voir
voici une vidéo où l’on me voit regler le niveau du gris :

dl.free.fr/j9v3rWuuL

toujours une ligne d’erreur …
EDIT :
et sans la ligne d’erreur , cela devient vraiment bien , non ?
reste un problème avec la couleur …

dl.free.fr/j9IXyjeFA

bon, j’ai fait un test avec le magnétoscope vhs
pour voir si ce problème de couleur venait de ma carte d’acquisition
vlcsnap-pb couleur PAL.jpg

Résultat : non , c’est pareil
à ce stade 2 possibilités

1- continuer la version ligne aléatoire en espérant que ce problème vienne de ma partie analogique

2- passer à l’inversion aléatoire par trame entière comme cela se faisait pour Filmnet
En effet, je n’ai pas connaissance de procédé de cryptage ayant utilisé l’inversion de ligne
mais il y en a eu utilisant l’inversion par trame entière (Satpack de filmnet)
Y aurait-il une raison fondamentale à cela ?

en attendant , je vais faire les 2 versions