Decodeur et Cryptage NAGRAVISION SYSTER (1995-2005)

https://forum.retrotechnique.org/t/decodeur-et-cryptage-nagravision-syster-1995-2005/78393

lorenzo44
mars 2018



LA CLE
1.1. Communication avec la clef
L’échange entre la clef et le décodeur se compose toujours de 3 octets :
2 du décodeur vers la clef, constituant la « question » (qui n’en est pas toujours une)
1 de la clef vers le décodeur, constituant la « réponse ».
Chaque communication débute après le top trame du signal vidéo.
Il n’y a qu’une communication par trame (1 par 20ms)
Une succession de communications non nulles sera appelée ‘dialogue’.
Il y a 4 types de communication habituels :
1°) Mode d’attente, ou communication nulle, circule entre deux échanges de donnée :
Le décodeur envoie 2 fois 0xFF, la clef répond 0x01
2°) Mode question ou mode d’introduction de code
Le décodeur envoie les salves par paquet de 2 octets, la clef répond 0x01
3°) Mode réponse
Le décodeur envoie 2 fois 0xFF, la clef génère une réponse, 1 octet à la fois
4°) Mode réponse immédiate
Le décodeur envoie 2 octets non nul, et la clef répond 1 octet.
Ce cas arrive rarement.
PROTOCOLE DE COMMUNICATION
Liaison RS232, 9453 Bauds, un start bit, 8 bits de datas, 9ème bit, et stop bit
9453 Bauds est une vitesse non normalisée, mais cela n’a aucune importance.
Cette vitesse est générée par la fréquence d’horloge appliquée à la clef, elle-même issue du
générateur d’horloge du décodeur : F = 26,625 MHz / 7 = 3,8036 MHz environ.
Chaque trame vidéo (20ms) génère un envoi de 2 octets vers la clef, qui provoque à son tour, une
réponse de la clef sur 1 octet.
Les dialogues avec la clef sont assimilables à des commandes, entraînant des réponses.
Si l’on élimine les temps morts (3 octets seulement par trames), on a la configuration suivante :
Commande -??Réponse.
La commande est constituée elle-même
d’un octet ID identificateur de commande, bit 9 à 1
d’un octet A 1er paramètre, que j’appelle ici audience, bit 9 à 0
quelquefois d’un ou 2 octets de paramétrage de la question, bit 9 à 0
La réponse est constituée :
d’un octet ID identificateur de réponse, bit 9 à 1
de plusieurs octets contenant la réponse, bit 9 à 0
d’un octet de fin de réponse bit 9 à 1
Plusieurs types de dialogues sont utilisés :
Mode attente,
le décodeur envoi 2 octets à FF, ID = FF, A = FF.
La clef répond par 01, si elle n’a rien de spécifique à dire.
Mode Question
La question est envoyée par le décodeur par groupe de 2 octets.
1 octet ID commande: 02, 05, 06, 57, etc.
1 octet A précisant le type de la question : 57 00, 57 01, 57 02
n octets M0…Mn, porteurs de l’info, nombre dépendant de la question
1 octet END de fin, en général, 0.
Mode réponse:
La réponse peut, suivant les questions, varier, de 1 à 18 octets.
Elle intervient évidemment après la fin de l’arrivée de la totalité des octets de la question.
Le décodeur passe alors en mode attente (FF FF) et la clef répond un octet à la fois
Ces modes sont résumé par la figure 5.
Fig. 5 : Types de d’échange clé <> décodeur
En période d’attente, et en période d’acquisition de question, elle répond 01, 9ème bit à 0
Lorsque la clef à terminé son calcul, la réponse est envoyée sous la forme suivante (toujours 1 octet
par trame):
1 octet ID de la réponse : soit le type de réponse (06), soit l’indicatif de réponse 02.
n octets de réponse
1 octet END de fin de réponse, en général 02.
L’octet ID et END ont le bit 9 à 1, les autres à 0.
TYPES DE DIALOGUE
Il y a plusieurs types de dialogue.

Le dialogue « DECODAGE », qui à lieu toutes les 100 trames, soit 2 secondes:
Mode d’introduction de code pour 18 octets, soit 9 paquets de 2.
Le 1er paquet est constant
Le 1er octet du 1er paquet est l’indicatif 0x06.
le 2ème octet est l’audience de l’émission (0x11 pour audience libre, 00 ou 0x20 pour PRESTATAIRE
2, 02 pour les autres émissions de Prestataire 1).
Ensuite suivent 16 octets (128 bits) représentant le texte crypté
Pendant cette transmission, la clef répond toujours 0x01.
Après réception du dernier octet, la clef répond autre chose (entre 2 et 6, jamais vu plus haut),
probablement un accusé de réception.
Mode échange nul pour 6 échanges (6 trames).
Si la clef est en mesure de décoder (abonnement valable, bonne audience…) :
Mode réponse pour 10 octets:
1er octet est l’indicatif 0x06, indicatif de la réponse de décryptage
8 octets correspondant à une partie du texte décodé (l’autre partie étant utilisée aux fins de
vérifications d’autorisations).
1 octet de fin de transmission, égal à 0x02.
Si la clef ne peut décoder:
Mode réponse pour 1 octet:
1 octet indicatif 0x0A, signifiant ‘pas de réponse’.
L’intervalle entre chaque dialogue « DECODAGE », est occupé soit par 90 communications nulles,
soit par un dialogue « INTRODUCTION » ci-dessous, le reste étant comblé par des échanges nuls.
Le dialogue « INTRODUCTION DE DONNEES »,
qui à lieu toutes les 19 dialogues « DECODAGE » en moyenne, soit toutes les 38 à 40 secondes.
Ce sont des questions, comme les questions pour le décryptage, mais leur rôle est différent. Elles
servent essentiellement à la maintenance de la clef (réactualisation, annulation, initialisation, etc. )
La clef répond toujours 0x01 pendant la transmission.
Selon l’ID de la question, le temps de calcul est plus ou moins long, et la réponse est longue, dans le
cas de demande de renseignements, ou inexistante dans le cas d’intervention sur la clef.
Dans le premier cas, la clef répond comme pour les questions de décryptage, 1 octet par trame après
le calcul, et dans le deuxième cas, en général, un accusé de réception, 0 ou 8, selon que la question
est acceptée, ou refusée.

Le dialogue « INITIALISATION »,
qui à lieu à la mise sous tension, ou à l’introduction de la clef A la mise sous tension, le décodeur
adresse à la clef, une question 02 00.
A cette première salve, la clef répond 0xA0, indiquant la RAZ effectuée du processeur de la clef.
Ensuite, la clef répond avec 10 octets, le premier étant comme d’habitude, 02.
Suivent ensuite 3 question 57.
La configuration du dialogue est une succession de mode question et de mode réponse, sans
échanges nuls intercalés, suivant la structure ci-dessous:
Q = question du décodeur R = réponse de la clef. Le 02 en premier octet de réponse ressemble au
STX classique des liaisons série. (tous les octets représentés sont en hexadécimal)
Q =02, 00
R = A0,
R = 02, 18, 38, 12, 00, FF, 14, YY, ZZ, 00
Q = 57, 00
R = 02, AA, BB, CC, 10, N° clef 3 octets, 00, 00
Q = 57, 01
R = 02, 00, DD, 00, 00, N° clef 3 octets, 00, 00
Q = 57, 02
R = 02, AA, BB, CC, 12, N° clef 3 octets, 00, 00
Les octets remplacés par des doubles lettres dépendent de la clef.
La première salve de réponse dépend du type de clef. (chapitre de l’initialisation, programme 8397)
Prestataire 2 utilise 2 types de clefs
. Le 2ème type répond 0C et 06 à la place de 18 et 12.
Prestataire 3 utilise 16 – 10 et Prestataire 4 utilise 12 – 0C
Ces valeurs donnent l’emplacement de la fenêtre pour les lignes DIDON
YY et ZZ ont toujours été vu à 80 et 83, ou E3 et E5
Les octets de ces salves seront détaillés dans les paragraphes suivants.
Le dialogue « LECTURE DE DROIT »
Elle se compose de plusieurs salves.
La première, déclenchée par le premier appui sur le bouton comporte 2 salves :
Q = 02 00 question du décodeur
R = 01 02 0C 38 06 04 FF 14 80 83 00 réponse de la clef
Q = 5F 00 00 00
R = 02 01 FF FF C0 75 3F 8A 41 89 00
Ensuite, chaque appui sur le bouton génère une salve.
Q = 5F 00 01 00
R = 02 01 FF FF A3 75 5C 8A 61 89 00
(2) FF FF 01
Q = 5F 00 02 00
R = 02 01 FF FF 20 76 DF 89 81 89 00
(2) FF FF 01
Q = 5F 00 03 00
R = 02 01 FF FF C0 75 3F 8A A1 89 00
(2) FF FF 01
Q = 5F 00 04 00
R = 7A
R = 02 01 FF FF C0 75 3F 8A 41 89 00
(1) FF FF 01
Q = 5F 00 01 00
R = 02 01 FF FF A3 75 5C 8A 61 89 00
Les 4 derniers octets représentent, à chaque appel, une plage de validité, avec la date de fin, par ex
8A5C, et la date de début : 8961 l’octet de poids fort est à retirer. On obtient alors 0A5C, qui donne
28/02/95, 0961 qui donne 01/09/94, etc.
Le format de la date :
0000AAAS MMMJJJJJ
AAA = année + 90
S = semestre
MMM = mois
JJJJJ = jour
Ex : 0961 ??00001001 01100001 ??0000100 1 011 00001
4 1 3 1
année 90+4, semestre 1, mois 3 +( semestre * 6) = 9, jour = 1 : 01/09/94
La clef est prévue pour répondre à 32 types de question différentes.
Par contre, le décodeur tel qu’il est actuellement ne comporte pas toutes ces possibilités.
Voici les questions possibles relevées. Le premier nombre est l’indicatif de la question en
hexadécimal, et le second, le nombre total d’octets envoyé, en décimal, ID et A compris
01:10 - 02:02 - 05:66 - 06:18
4E:02 - 4F:02
50:02 - 51:10 - 52:02 - 53:12 - 54:12 - 55:34 - 56:18 - 57:02 - 58:66
59:02 - 5A:02 - 5B:02 - 5C:02 - 5D:10 - 5E:04 - 5F:04
60:18 - 61:18 - 62:20 - 63:10 - 64:18 - 65:34 - 66:66 - 67:10 - 68:18
69:34 - 6A:20
FF:02
En effet, FF (dialogue nulle) doit être considéré comme une question, avec un paramètre d’audience
(le 2ème FF).

Concernant la cléf blanche il y a possibilité de la reprogrammer ou bien de passer par une wafercard pour decoder Canal sans abonnement.

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 :frowning: 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.

dialogue entre
8397 et clef
2 octets du
8397 et 1 octet
de reponse clef

…
[FF] FF [01]
[02] 00 [01] * touche « MESS » pressee pour le premiere fois

[FF] FF [02] * debut de reponse de la clef
[FF] FF 0C * - Toutes le clefs
[FF] FF 38 * - repondent le meme
[FF] FF 06 * - message …
[FF] FF 04 * - message qui est
[FF] FF FF * - identique a l’init
[FF] FF 14 * - lors d’une raz clef
[FF] FF 80 * - peut etre identification
[FF] FF 83 * - que c est une clef C+ ?
[FF] FF [00] * fin de reponse de la clef

[5F] 00 [01] * demande zone d’abonnement « 0 » ?
00 00 [01] * demande plage « 0 » de date dans la zone « 0 » ?

[FF] FF [02] * debut de reponse de la clef
[FF] FF 01 * ?? a priori toujours - Toutes les clefs
[FF] FF FF * ?? 01 FF FF pour C+ - livrees avec les
[FF] FF FF * ?? identif programme ? - boitiers a 250 F
[FF] FF A3 * ?? - donnent la meme
[FF] FF 7D * ?? - reponse
[FF] FF 5C * LSB date de fin plage 0 - droits du 01.01.91
[FF] FF 82 * MSB date de fin plage 0 - au 28.02.91
[FF] FF 21 * LSB date de debut plage 0 -
[FF] FF 82 * MSB date de debut plage 0 -
[FF] FF [00] * fin de reponse de la clef -

[FF] FF [01]
… * Message affiche « bienvenue sur… MESS consultation… »
… * x wait states en attendant « MESS » ou fin de tempo
[FF] FF [01]

[5F] 00 [01] * 2 eme pression sur le touche « MESS » : dem. zone « 0 » ?
01 00 [01] * demande plage « 1 » de date dans la zone « 0 » ?

[FF] FF [02] * debut de reponse de la clef
[FF] FF 01 * - toujours pareil
[FF] FF FF * - quelque soit la clef
[FF] FF FF * - 01 FF FF

[FF] FF C4 * ?? lie a la date de validite ?
[FF] FF 6F * ?? pas trouve de corelation

[FF] FF 3B * LSB date de fin plage 1
[FF] FF 90 * MSB date de fin plage 1
[FF] FF 2B * LSB date de debut plage 1
[FF] FF 90 * MSB date de debut plage 1
[FF] FF [00] * fin de reponse de la clef

[5F] 00 [01] * demande zone « 0 » ?
02 00 [01] * demande plage « 2 » de date dans la zone « 0 » ?

[FF] FF [7A] * reponse de la clef : y en a pas

[5F] 02 [01] * demande de zone « 2 » ?
00 00 [01] * demande plage « 0 » de date dans la zone « 2 » ?

[FF] FF [7A] * reponse de la clef : y en a pas

[5F] 03 [01] * demande de zone « 3 » ?
00 00 [01] * demande plage « 0 » de date dans la zone « 3 » ?

[FF] FF [7A] * reponse de la clef : y en a pas

[5F] 04 [01] * demande de zone « 4 » ?
00 00 [01] * demande plage « 0 » de date dans la zone « 4 » ?

[FF] FF [4A] * reponse de la clef : y en a pas + derniere zone
[FF] FF [01]
… * message affiche : liste des droits 2 lignes de droits

x wait states en attente pression touche « MESS »
2 cas : si plus de droits a afficher retour au programme
si encore des droits lecture et affichage 2 lignes
par 2 lignes …
Si on prend comme reference le 01.01.91 => $8221 = 33313
il semble qu’un annee soit composee de 16 mois de 32 jours…
16 * 32 = 512

REMARQUES :
Cela veut donc dire que ni la clef, ni le 8397 ne gerent de calendrier !!
Lors de l’activation, l’emetteur doit donc envoyer la date du jour courant

un increment variable pour l’affichage correct de fin de validite (mois
a 31 / 30 / 28 jours). Cela se verifie sur une zone de validite « a cheval »
sur deux mois en particulier fevrier 98 a mars 98.
La date maxi pouvant etre geree est $FFFF c’est a dire 65536

pour calculer la date :

X - 33313 = Y
Y / 512 = nombre d’annee (avec le reste m)
m / 32 = nombre de mois (avec le reste j)
j = nombre de jours
ajouter les valeurs trouvees au 01.01.91

(la date maxi serait donc vers l’an 2053…)

exemples :

$825C => 33372
33372 - 33313 = 59
59 / 512 = 0 reste 59
59 / 32 = 1 reste 27
27
soit 0 an, 1 mois, 27 jours a ajouter au 01.01.91
ce qui fait le 28.02.91

$902B => 36907
36907 - 33313 = 3594
3594 / 512 = 7 reste 10
10 / 32 = 0 reste 10
10
soit 7 ans, 0 mois, 10 jours a ajouter au 01.01.91
ce qui fait le 11.01.98

$903B => 36923
36923 - 33313 = 3610
3610 / 512 = 7 reste 26
26 / 32 = 0 reste 26
26
soit 7 ans, 0 mois, 26 jours a ajouter au 01.01.91
ce qui fait le 27.01.98

en appliquant cette formule avec plusieurs clefs on arrive a un resultat
correct avec des mois en debut d’annee

une clef valable du 17.12.97 au 26.12.97 donne comme valeurs

$8FD1 => 36817
36817 - 33313 = 3504
3504 / 512 = 6 reste 432
432 / 32 = 13 reste 16
16
soit 6 ans, 13 mois, 16 jours a ajouter au 01.01.91
ce qui fait 17.14.98 (pour 17.12.98)

$8FDA => 36826
36826 - 33313 = 3513
3513 / 512 = 6 reste 441
441 / 32 = 13 reste 25
25
soit 6 ans, 13 mois, 25 jours a ajouter au 01.01.91
ce qui fait 26.14.98 (pour 26.12.98)

Fichier hex a mettre dans 1 pic 16f84 pour émuler les clefs c+ syster nagravision

:100000006322C9018316FF3086000030810083120D
:1000100022224508023A03192728553A03192F28A6
:10002000513A03194E28F93A03192428A13A031921
:100030002A28013A03192A2828222222450A031DC8
:100040001C28460A031D1C2801302E220828B03027
:10005000CD003D282822272222224A302528B830E8
:10006000CD004608003A03193D28C030CD004608AF
:10007000013A03193D28C830CD000830C7002822B6
:10008000222202302E2202308A00222276222C22C4
:10009000CD0AC70B45282222030125280830CF00AE
:1000A0000030CD000630C7006922460603195E28DD
:1000B000CD0A4F08083ECF00C70B542828220C3029
:1000C00084000830C7004E228000840A4E2280003F
:1000D000840A2822C70B63280C30B40098202722FA
:1000E0001430B40098208420222206302E2224309E
:1000F00084000830C700222200082C22840AC70B83
:100100007B282222023025281808A4001908A500FF
:100110001A08A6001B087F39A7001B0D0C0DA800AC
:100120000D0DA9000E0DAA000F0D1F39AB00080020
:100130004F08CD000830C7006922CE0CA40DCE0CAC
:10014000A70DCE0CA60DCE0CA50DCE0CA80DCE0C79
:10015000A90DCE0CAA0DCE0CAB0DCD0AC70B9C2859
:10016000280EF039A400340884000830C700800C41
:10017000A00D800C9C0D800CA10D800C9D0D800CA1
:10018000A20D800C9E0D800CA30D800C9F0D840A87
:10019000C70BB72802308A00BF30CC007E30CB00BE
:1001A0001030CA00BC01271A3C14A71BBC14271826
:1001B0003C152519BC1526193C16251BBC16BB0180
:1001C000A41B3B142719BB14241A3B15A61ABB15F4
:1001D000A5193B162618BB16BA01251A3A14A719F9
:1001E000BA14A51B3A15A518BA15261A3A16271BD4
:1001F000BA16B901A41A3914A51AB914A61B3915CF
:10020000A71AB91525183916A619B916B8012B1B46
:100210003814AA19B814291A3815A81AB815AB1821
:1002200038162A18B816B7012B183714281BB7141C
:100230002B1A37152A1AB715A91A3716A918B7167F
:10024000B6012A1B3614A919B6142B193615AA188B
:10025000B615281A3616AB1AB616B501AB193514F1
:10026000AB1BB51429183515AA1AB515A91B3516D7
:100270002A19B516C4019F1B44141C18C4149C18D9
:1002800044151C19C4159C1944161C1AC416C30124
:100290009C1943141C1AC3149C1A43151C1BC31528
:1002A0009C1B43161D18C316C2019C1B42141D182B
:1002B000C2149D1842151D19C2159D1942161D1A0A
:1002C000C216C1019D1941141D1AC1149D1A411570
:1002D0001D1BC1159D1B41161E18C116C0019D1B7B
:1002E00040141E18C0149E1840151E19C0159E19E2
:1002F00040161E1AC016BF019E193F141E1ABF14C5
:100300009E1A3F151E1BBF159E1B3F161F18BF16BA
:10031000BE019E1B3E141F18BE149F183E151F19C8
:10032000BE159F193E161F1ABE16BD019F193D141A
:100330001F1ABD149F1A3D151F1BBD159F1B3D168F
:100340001C18BD162030C700AC012C083D3E8400AF
:100350000008AD00F830840700082D063F39AD00D5
:100360007822AE002D0C2E040A147F220A10AE0053
:100370002D1CBD292E0EF039AE000430C8004703F5
:100380007E22AF000339303E84002F0E7B22AE0D5B
:10039000031CCD29FF3A8005CE298004C703031929
:1003A000D529C80BBF29AC0AA5292308B306220802
:1003B000B2062108B1062008B0061C08A0001D08DE
:1003C000A1001E08A2001F08A30030089C003108ED
:1003D0009D0032089E0033089F00CA030319FA29C2
:1003E0001322CC0CCB0C031813224A08083A031929
:1003F0002722D2280830C7003408073E8400A30C07
:10040000800D9F0C800DA20C800D9E0C800DA10C08
:10041000800D9D0C800DA00C800D9C0C800D840324
:10042000C70BFF2908000310241A0314A70CA60CFD
:10043000A50CA40C0310281A0314AB0CAA0CA90CCD
:10044000A80C08004E22C5004E22C6000800222239
:100450000130491CA0302E2AC913302AC91749146B
:10046000B2001F306422861383168613831208306D
:10047000B3006322B20C320C803906068606B30B39
:10048000392A63220301C91B8030060686061F3005
:10049000642283168617831263220800861B4E2A65
:1004A0002E3064220930B30000000310861B0314B1
:1004B000B20C6322B30B552AB20DC9130318C91726
:1004C0006322320808001D30B100B10B652A0034E8
:1004D000CD004D08000089000000831600000000D8
:1004E0000814831208080000CE0008004D0882009E
:1004F0002C08D03E82000739D83E8200E03E8200C0
:10050000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3FFB
:10051000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3FEB
:10052000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3FDB
:10053000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3FCB
:10054000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3FBB
:10055000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3FAB
:100560001834383412340034FF3414348034833473
:1005700042349334013431341234343456347834C0
:100580000034313400340034123434345634783486
:10059000423493340134333412343434563478349E
:1005A0000034E034C034A03480346034403420342B
:1005B000013402340434083410342034403480349C
:1005C000313412345034333413342134423400344F
:1005D000513452343034433453347034223403347D
:1005E00073346234413460342334203402340134AF
:1005F0006134633440343234103411347134723421
:100600001F34B0342834EB34D1340D3442347E34CA
:10061000C534593493343434A6346A34FC348734C2
:10062000B034E33417347D342B349634DE3448341C
:100630000A3434346C348134C5345F34A934F23430
:100640002E34D0347234B73495340C344834EB340F
:1006500053346A34C9341434AF34F13436348D34FD
:100660008D344E34B134E8346B3435341734D234ED
:10067000F034933456342F340C34CA34A9347434DF
:10068000B2344F34D43418340B34F6347E34253439
:10069000C1343C346A348334AD3450349734E93453
:1006A000E934B434423427343E34CB3485341834FE
:1006B00056340A349F347034F134AD346C34D3344E
:1006C0003534E0345B340D346834D33496347A34C2
:1006D000F9342E34C234B1341F348434AC3447344A
:1006E0006B341C340D34A334D6347A343034C534EE
:1006F0008434F134BE345834E9342F3447349234DE
:10070000D1343434BD34E3348B34583442349E34E1
:100710007A34AF34C03405342C34F63417346934A9
:10072000B434D734E33448345E3421348D347234F5
:10073000093460343F34A6349534CB34FA341C3455
:10074000823427341434CA34F93490346F345C342E
:10075000EB34D8347D34A3344E343534B1340634DC
:100760005C3490346F34F93435344E348234273469
:100770000634EB34CA341434A334D8347D34B13461
:100780005234F8346F3416349C34CB340934A534E5
:10079000ED3427343A3481344334B434D0347E34A5
:1007A0002E349534B2346F3479340634C734F83487
:1007B0004B34E034D1343C34A4345A341D348334C3
:1007C0000C34E2347B34183490344D34C734B134B3
:1007D00063348F34DE3425343934F634A4345A3457
:1007E000F234173485344E345C34B0342B34ED3469
:1007F000A4347934383493346F34CA34D134063461
:084000000000020000000200B4
:02400E00F93F78
:10420000000020001100300000000000FF00FF004F
:104210000000040002002D002C00E0001E00010040
:10422000000016009200080053001C00B500370083
:10423000C400A500A800180074009300C700650022
:104240006800AE000C00E9006400160078008D00E4
:104250000000360085008E008100B0007D00BF00A8
:1042600000008B00C600EC006600E200A300F30033
:10427000210001008100AB00150004005400C600BD
:00000001FF

http://cryptimage.vot.pl/cryptimage.php





Pour le dump d’une clef type 2 uniquement celà va de soi:

Vous avez besoin de cpluche 2.24, d’une interface Phoenix avec le quartz adéquat & de RSAPLUS:

faire un reset
envoyer une cmde 5000 et lire la réponse:
==> 2 possibilités:
type2=4B 45 59 2D 32 00 00 00

type3=4B 65 79 2D 33 20 54 49

envoyer une cmde 5701 et lire la réponse:
aprés l’octet 02 vous notez les 4 octects qui suivent, c’est le PPUA !!! les 4 derniers octets sont le numéro de série à l’envers.

2 possibiltés en général: 00 10 00 00 ou 01 10 00 00

Ouvrez ensuite RSA+:

Sur le provider N°1, entrez la PK & VK publique utilisée pour décrypter les anciennes 0501 (activation de 7 jours !!)

Ensuite placez l’EMM suivante dans le champs adéquat:

7E8FC6CDBC9A5CC6139B5F420B61555B31F5F96D03CB72723307EC57AEBC087FA3DD5AD2752C6FAE96965A76B093C196C9C3309BC3A34CB53D0508904B931083

Lancer le déchiffrage !!!

Dans le bloc 0:

0A 00 00 01 PP UU AA SA càd 0A 00 00 01 00 10 00 00 OU 0A 00 00 01 01 10 00 00

Sélectionner le bloc 1 & signer (FIRMAR)

Rechiffrer l’EMM modifiée à votre clef !!!

COPIER/COLLER

Ouvrez cpluche 2.24, paramétrez le correctement (COM X):

section dial avec la clef

Coller l’EMM obtenue à la suite de la commnde 0501:

Cliquez sur envoir de la command avec une longeur de 10 a 11
puis ensuite cliquer sur effacement des données et du buffer
puis mettre en haut a gauche FF et juste a cote a droite laisser 01
et en haut a droite mettre 512 voir 1024 et envoie de la commande:

Aprés une série de 01, le DUMP de la clef commence aprés l’octet AB !!

Il ne vous reste plus qu’à copier coller le résultat avec bloc note du DUMP sous forme ASCII et l’interpréter avec CANALBLIND par exemple !!!

une fois fait note manufacturer key puis dans operator 0 NOTE KEY=PK + LA SIGNATURE=VK
puis avec la cles qui doit etre active logg plusieurs trames 0500 et avec rsa dans provider 0
note pk et vk de la cles dans rsa et clique sur descifrar et dans le bloque 0 note les 4 dernier
octets qui et un user actif.
puis avec cpluche2.24 sections clef off metre manufacturer key et l’user groupe trouve et pk et vk
puis clicque sur modifier le provider xx puis metre la cles dans le demo et attendre 5 min a 1h