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 :
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 :
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 !
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.
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
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) ?
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
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)
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.
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 :
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
non ! pas bloqué, j’ai sacrifié un cable péritel pour me faire ma rallonge
et voici donc le résultat :
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 ???
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
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 …
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:
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 )