DESCRIPTION DÉTAILLÉE DU PROCÈS DE DECODIFICA NDS
Le système NDS Direct TV se base sur les paquets de données avec envoyés aux decoder respectifs les données vidéo. Quelques-uns de ces données sont sélectionnés par le ricevitore/decoder avant de les passer au smart card de façon à former une unie individuellement autorisée. En pratique certaine tu dates seulement entre millions les ils passent pouvoir été passé à ton smart card.
De cette manière à ton smart card n'arriveront pas tous ces tu dates inutile tourne aux autres smart card/decoder. Pas mal de paquets de données passeront vers le smart de toute façon card. Il y aie en aux douzaines et entre ceux-ci quelques-uns ils sont d'importance vitale!
Le paquet vital premier est le 4840, qu'il est combien on obtient immédiatement après qu'on syntonise un nouveau canal, et aussi aux entractes réguliers. Un exemple pourrait être comme celui-ci:
48 40 00 00 XX 40 09 10 10 00 01 4a 12 34 02 41 03 33 42 00 0c aa bb cc dd ee
rompons-le en parties:
48 40 00 00 XX LE deux byte 48 40 décrit le type de paquet et XX il indique le numéro de byte qu'ils suivent;
40 est un écho du card vers le decoder pour indiquer qu'il est en train de fonctionner;
09 10 10 00 09 est ici le commandement qui secte le key qui sera utilisée successivement. Dans ce cas elle est indiquée la 10 que c'est un key vague utilisé par tous les smart card. Le smart card utilise un algorithme qu'il engendre 10, en chiffre décimal?; NdT, byte chaque fois qu'un nouveau byte est acquis. Pour ce 10 byte il utilise la valeur précédente et la nouvelle valeur mémorisées dans le registre À ou accumulateur. Une fois émise le commandement 09, presque chaque byte lu passe à travers cet algorithme successivement en produisant un nouveau set de 10 byte. La manière unique pour connaître en avance ce 10 byte est subie ainsi après qu'un commandement 09 vient envoyé au smart card. L'algorithme est complexe suffisamment à découvrir, il demanderait ans d'élaboration aussi aux ordinateurs plus rapides super!!
01 4a 12 34 Le commandement 01 charge l'heure et la date, où 4a représente le mois et 12 34 l'heure digitale, pas nécessairement corrélationnele par 24 heures. il doit être fait remarquer, après la description précédente du "10 bytes key", que l'acquisition de ce 4 byte engendrera un "10 bytes absolument key" seule et pas répétable en tout ce que lié aux valeurs temporales. Ensuite chaque interception ou tentative de changer vous vous consacrez il traduira dans une émission de clé erronée.
02 41: Le commandement 02 fournit l'état de visibilité du programme. Dans le cas le byte qui suit le "4" signifie que pour la vision l'abonnement est nécessaire, pendant que si fosses "8 la vision est gratuite ou en preview. Le second chiffre représente le "parental rating", interdit aux moins plus petits; NdT. il va répété De toute façon que chaque tentative d'intercepter et changer la 41 (vision avec abonnement) en 81, vision gratuite engendrera un "10 byte key" erroné qui réfutera tous nos efforts.
03 33 42 00: Le commandement 03 vérification que notre abonnement permette la vision du canal syntonisé, dans ce cas le 33 42, Ch-id; NdT. ET à ce point que smart card répondra de manière différente à la seconde si nous avons ou nous n'avons pas le certificat d'aptitude à la vision du canal à l'intérieur de notre smart card. Aussi dans ce cas il n'est pas possible d'intercepter et changer l'identificateur de canal pour faire croire au card d'avoir l'abonnement, sans altérer et ensuite réfuter la citée 10 bytes key. Le commandement 03 peut être répété plusieurs fois en combien chaque canal unique peut avoir différents Ch-id à lui associé et un de ceux-ci viendra reconnu ou moins de notre smart card. , Ceci a été fait pour simplifier et optimiser l'offre des abonnements aux paquets différents de programmes. Dans les événements Pay Pour View (PPW) le commandement 03 est remplacé de 06, le résultat est le même de toute façon. , Seul que dans ce cas le certificat d'aptitude à la vision du canal est temporaire! NdT.
0c aa bb cc dd ee: 0c est le commandement qui vérifie l'intégrité de tous les bytes reçue après la 09 initiale fine à l'ee compris. Les cinq bytes après le 0c, aa bb cc dd ee est comparé avec les premier 5 bytes du "10 bytes key" issu et mémorisée dans l'accumulateur du smart card, comme nous avons vu à chaque byte acquis il paie un nouveau "10 bytes key”;NdT. Si pour n'importe quel raison, dérangements e/o tentatives d'intercettazione/modifica, ces 5 bytes ne coïncident pas, le procès de génération du key ne sera pas activé d'il décode. Il n'est pas facile deviner ce byte en outre en combien d'il y a 256x256x256x256x256 combinaisons, ils sont nombreuses. De cette manière il termine le paquet 4840.
Le smart card se remet dans l'attente du prochain paquet. Ce qu'a de toute façon été mémorisé, c'est un set de 10 bytes et l'état de visibilité ou non à la vision du canal. Jusqu'à présent le ricevitore/decoder ne connaît pas encore le status de visibilité et il ne montre aucun signal vidéo.
L'autre paquet d'importance vitale vient ainsi, immédiatement après: le 48 54. Cela a un format plus simple: 48 54 00 00 00 et rien de plus. Le smart card reconnaît le 48 54 et il fait écho avec un 54. Puis il fait usage des données créé avec le paquet précédent 48 40 pour engendrer une autre version du "10 bytes key" et "il mixe le tout de manière HARDWARE, de sorte à rendre la chose compliquée avec un émule, aussi du point de vue de la vitesse; NdT.
Il fait ensuite un cryptaggio logiciel et il l'envoie si obtenue "10 bytes key" et le status de visibilité au ricevitore/decoder.
Pour cet autre "smanazzamento" de key, à peine décrit, le status juste est nécessaire cependant pour ce canal à ce moment-là, autrement envoyée le "10 bytes key" viendra obtenue par le paquet précédent 48 40 qu'il comporte l'accès nié au canal.
Si tout est de toute façon D'ACCORD le "10 bytes key" vient envoyée au decoder MPEG qu'il nous fournira enfin le signal vidéo. , Le son ne vient pas codifié mais il reste en "meutes" tant que l'il codifie écran elle n'est pas correct.
À ce point nous avons appris que: ces deux paquets sont fondamentaux, si nous lançons n'importe quel byte du pachetto 48 40 entre le commando 09 et la fin du paquet, nous aurons le "10 bytes key" erroné avec personne il décode.
Maintenant nous pouvons ajouter autres commandements au-delà au paquet 4840 aux simple 01, l'heure et date, 02 (visibilité du programme), 03 (vérification des données d'abonnement), au pacte que le résultat final du 5 byte de vérification ils soient correct et corrélationnels aux commandements envoyés au smart card. Nous pouvons inclure le commandement par exemple 60 suivi par un lacet de sottocomanto BF:
60 BF 81 23 01
Ce commandement les fait que le "10 bytes key" vienne issu de nouveau pour 8 fois, une fois pour chaque byte à partir de trouvé dans l'EEPROM la location 81 23. Et possible spécifier le numéro de blocs de 8 bytes à vérifier, l'exemple il montre 01 seulement pour un bloc, ou une liste d'adresses à vérifier. L'adresse effective pourrait ne pas être 8123 mais une autre adresse, ou il borde d'adresses, dans la zone 8xxx qu'il correspond aux codes altérés par les "pirates!"
Si nous adressons une zone de l'eeprom dans laquelle nous savons qu'il y a des valeurs fixes en chaque smart légitime card, alors chaque smart légitime card engendrera le même "10 bytes key" valide pour le decoding, mais si, comme dans le cas des card pirate, aussi un byte seul fût différent, nous obtiendrons des clés incorrectes et personne ne décode ensuite.
NdT: puis ils suivent des considérations sur fait que ce dernier je contrôle il n'est pas exécuté évidemment car ils sont en tour depuis mois card pirate, D*S-DirectTV, funzionanti pendant qu'avec ce contrôle tous KO seraient mis. Et un choix du broadcaster? Peut-être?
Précis en outre que combien sur il se réfère au système N*S américain et comme type pourrait différer de la version européenne légèrement.
