Doctsf (Modèles & Marques)
Annoncesetude sur les messages d’initialisation d’une cle dans un decodeur.
On remarquera que tous les octets en provenance du decodeur sont emis CODES
alors que la cle repond toujours en CLAIR !
(exceptes peut-etre les message nuls [FF] FF et les questions [5F] et [5E]).
En d’autres termes, les octets transmis a la cle sont cryptees alors que la
cle repond en clair (non crypte). Iil suffit de lire la reponse de la cle
dans n’importe quel message : [02] et [57] on y retrouve le numero de la cle
donc il n’y a pas de cryptage de ces infos. Commande [06], la cle repond des
octets pas completement au hasard. C’est un mot qui initialise un GPA dans le
deco. Le deco n’a pas de fonction de decryptage des messages alors que la cle
en un une.
L’appuis sur la touche message du decodeur envoye des questions [5F] pour
cles type C+ et deco 250F. En revanche, les cles du type C+ espagne se font
interroger par 5E. (voir ci-dessous pour la definition des cles).
LA SEQUENCE D’INITIALISATION:
Il existe plusieurs types de sequence d’initialisation. Les deux principaux
en france sont :
| Type msg | reponse cle C+ | reponse cle deco 250F |
|||____________________________|
| Msg[57]00 | gg hh ii 10 xx xx xx 00 | gg hh ii 10 xx xx xx 00 |
| 01 | 00 10 00 00 xx xx xx 00 | 01 10 00 00 xx xx xx 00 |
| 02 | gg hh ii 12 xx xx xx 00 | gg hh ii 12 xx xx xx 00 |
|||____________________________|
| Msg[02]00 | 0C 38 06 04 FF 14 80 83 | 18 38 12 00 FF 14 80 83 |
||_______________|____________________________|
Mais il en existe aussi pour C+ espagne par exemple avec, entre autre :
Msg[02]00 : 1C 38 0C 01 FF 14 E1 E5
Reponse au message [02] 00 :
Trois octets sont plus sensibles que les autres pour la sequence [02].
Msg [02]00 : jj 38 kk ll FF 14 80 83
Les trois octets jj, et kk determinent la reception ou non des infos
en provenance des ligne teletexte :
jj=0C kk=06 : seul les trames sur C+ sont recues.
jj=18 kk=12 : on recoit les trames sur C+ et sur CanalSat.
jj=1C kk=0C : on devrait recevoir les trames sur C+ espagne (pas teste).
Les aurers octets peuvent etre remplaces par des 00, et tout a l’air de se
passer comme normalement.
En fonction des deux octets jj et kk, on distingue 2 types de codage :
- en audience claire, la question [06] >03< se transforme en [06] >11< !!!
Les octets qui suivent cette question different eux aussi. - Les messages [05] 01 sont eux aussi differents.
- En revanche, si jj et kk sont les memes pour 2 cles, elles recevront
rigoureusement les memes messages [06] et [05] 01. - On remarquera tout de meme que pour deux differents messages [06] (en
fonction des octets jj et kk) recus simultanement, bien qu’ils soient
differents, les deux cle repondront la meme chose ! (cf fichiers log).
Ainsi, on peut penser qu’il existe deux « types de cles ». Il semble en effet
que ces deux types soient etroitement lies avec les deux possiblites de
s’abonner : un deco a carrouf ou un deco chez M. C+.
L’octet ll sert a determiner si les droits peuvent etre affiches ou non sur
la tele lors de la pression sur la touche Message du decodeur.
L’octet egal a 10 dans le Msg[57]01 determine si oui ou non on va recevoir
les trames [05] 01.
L’octet gg n’a pas de signification particuliere (?)
Seuls les octets hh et ii servent de pre-filtre au decodeur pour qu’il
envoie les trames [05] 00 a la cle. Et ce sont les trames [05] 00 qui sont
succeptibles de reactiver la cle. Une chose est sure, la reactivation d’une
cle s’est faite de la maniere suivante :
- [06] non decodes (reponse [0A])
- Reception [05] 00 —> pas n’importe le quel !!!
- [06] non decodes (reponse [0A])
- Message « pas tout a fait nul » !!! => [FF] FF [00]
- [06] decodes ! (cela commence au [06] apres le message [FF] FF [00]).
Faut-il en deduire que la reponse [00] de la cle est faite des qu’elle a
interprete la trame [05] 00. Une sorte d’accuse reception ? Pourquoi la
cle ferait-elle ce type de reponse ? Le decodeur ne fait aucun « codage » des
octets recus par les lignes teletexte.
TRAMES [05] 00:
Message [02] 00 : 0C 00 06 00 00 00 00 00
Message [57] 00 : 00 hh ii jj 00 00 00 00
Message [57] 01 : 00 00 00 00 00 00 00 00
Message [57] 02 : 00 00 00 00 00 00 00 00
Seuls les 3 octets hh ii et jj servent a determiner les messages [05]
00 a recevoir.
En effet, l’init ci-dessus permet de recevoir les memes trames que
l’init complet. En revanche, si on modifie un des bits, les messages
recus sont differents. Pourtant, si un de octets =00 alors plus aucun
message n’est recu (a reverifier) !
L’octet jj semble etre 10 sur Canal+ et 12 sur CanalSat mais je ne l’ai pas
reellement verifie. En effet, il peut se passer jusqu’a 30mn avant le prochain
message [05] 00 pour une cle donnee !
Les 2 octets sont les seuls qui servent a determiner les bons messages [05]
00 a recevoir.
Mais si on remplace les 3 octets hh,ii et jj par FF FF FF, on recoit des
messages [05] 00 entre chaque trame [06] !!! Malheureusement, les trames [05]
00 recues ne contiennent pas une seule trame valide pour la cle !
On remarque aussi que la cle ne semble pas pouvoir interpreter les messages
[05] 00 avec seulement 2 secondes d’intervalle. En effet, elle repond [38]
puis [48] aux octets de certains messages [05] 00. Cela n’a rien a voir avec
le [01] habituel ! (cd ‹ affodeco.txt › - merci Aberdeen)
Les lignes de teletexte doivent donc contenir plusieurs initialisations
de cles simultanement. Cela parrait normal car avec 1 trame toutes les
2 secondes, on ne peut pas balayer toutes les cles de tous les abonnes
en moins d’un mois !
Je tiens quand meme a rajouter ici qu’on m’a affirme qu’on recevait
beaucoup de messages [05] 00 par les lignes teletexte. On pourrait alors
ramener le temps de balayage de TOUS les abonnes a environ 1 semaine.
On pourrait peut-etre reactiver une cle en substituant ces trois octets par
ceux d’une autre cle; celle d’un abonne. Mais le numero de la cle est
certainement contenu dans le message [05] 00 ce qui lui permet de se reactiver
que si elle reconnait que le message est pour elle. Le deco est un premier
filtre, et la cle fini d’ecremer les derniers messages qui ne sont pas pour
elle.
De plus, une cle desactivee recoit quand meme des trames [05] 00, mais
elles ne permettent pas sa reactivation 
Il faut une information
supplementaire !).
TRAMES [05] 01:
Le numero de la cle ne semble pas affecter le codage de ce trames qui sont
envoyes en broadcast.
La reception des messages [05] 01 ne sont geres que par un seul octet :
C’est l’octet egal a 10 de la sequence d’initialisation suivante qui permet
de recevoir les trames [05] 01. Bien sur, selon les 2 octets du msg[02] qui
peuvent prendre la valeur 18 … 12 ou 0C … 06, le message [05] 01 recu n’est
pas le meme.
Msg02 : 0C 00 06 00 00 00 00 00
Msg57 : 00 00 00 00 00 00 00 00
00 10 00 00 00 00 00 00
00 00 00 00 00 00 00 00
Cette sequence permet de recevoir exactement les memes trames [05] 01
que ce que balance le decodeur si une vraie cle est inseree.
Une fois de plus, on peut voir que si on modifie l’octet egal a 06 par la
valeur 12, on ne recoit plus le meme message. Cela laisse penser qu’il y a en
effet deux « type de codage » du dialogue entre la cle et le deco.
LES MESSAGES [06]:
En bref, on peut dire que ces messages sont envoyes en broadcast et toutes
les cles les recoivent en meme temps pour deux cles de meme types d’init [02].
Comme cela se passait pour les messages [05] 01, il y a 2 types de messages
[06], en fonction de la valeur de l’octet kk du message [02] a l’init.
On ne sait toujours pas calculer la reponse de la cle apres ce message.
le message [06] est recu en double par les lignes teletexte.
Mais le decodeur est sense n’en envoyer
qu’un seul a la cle. Pourtant, il arrive qu’apres certaines initialisations
on recoive deux messages [06] identiques a 1 seconde d’intervalle, ce qui
reflete bien ce qui se passe sur les lignes teletexte.
En d’autres termes, 2 messages [06] identiques sont recus par les lignes
teletexte a 1s d’intervalle". Mais le decodeur n’en transmet qu’un a la cle !
C’est probablement pour une question de fiabilite de transmission des donnees de
decodage.
A d’autres moments, les messages [06] ne sont pas complets et contiennent des
00 juste apres une initialisation. Cela est certainement du a la mise en route
des algorithmes au sein du decodeur.
