voilà ce qu'on peut résumer concernant la nano E0. Récupéré sur différents forums de discussion
Pour certaines chaines HD ne fonctionnent pas ? Parce que CANALSAT utilise désormais une nouvelle nano dite nano E0.
Comment fonctionne a priori cette nouvelle nano (correctement gérée par les démodulateurs off estampillés Canal Ready) ?
- La nano E0 procède à un post traitement sur le Decrypt word issu de la carte, ce que le décodeur à l'aide de son code de pairing va rectifier afin d'avoir le bon.
- La nano E0 est appelée CTRL-ECM (contrôle des ECMs ), à l'aide de cette nano, CANALSAT sécurisent le DCW afin qu'il ne soit pas possible de le partager à travers le réseau.
Comment fonctionne le décodeur Canal Ready qui est appairé (çàd qu'un lien est fait entre la carte et le décodeur qui a une adresse unique) ?
1. Le décodeur s'initialise et initialise tout son module crypto CAS (cf. dans le menu information de votre décodeur. Version de la librairie ACS)
2. Le décodeur va interroger la carte pour lire le numéro de série , et le décodeur va lui aussi lui envoyé un identifiant par l'intermédiaire de la commande CA 28.
Ce qu'on appelle l'appairage de carte (cardpairing en Anglais)
La carte connait son propre numéro de série et un identifiant concernant le décodeur (numéro de série du terminal et adresse unique)
Donc le décodeur connait son identifiant et le numéro de série de la carte.
Lors d'un changement de chaîne, le décodeur va parser la PMT (Program Map Table) , vérifier les accès conditionnel présent, et interroger la liste des IDENTs diffuseur disponibles (ceux qui ont été lus dans la carte présente exemple 032380, 032840 pour CANALSAT).
Le décodeur va extraire l'ECM du flux (en sélectionnant un PID ou Packet IDentifier = identifiant de paquet) -> et le traitement de l'ECM va démarrer :
* Le déco va vérifier d'abord que la nano D2 n'est pas présente. Si la nano D2 est présente-> il va prendre les paramètres et si PRE-traitement , modifier les bytes après la nano EA.
* Il va vérifier si la nano E0 existe , il va lire la longueur de la nano, et prendre les paramètres de la nano et les sauvegarder pour une utilisation ultérieure.
Le décodeur va envoyer et contruire ensuite la commande CA 88 ( qui va contenir la corps de l'ECM issu du flux ( pid ).
Le décodeur va vérifier que le status byte (réponse à la commande. si OK >> 90 00 par ex) de la CA 88 est ok , si Oui il va envoyer une demande de réception des mots de controls ( DCW ) qui seront utilisés pour décrypté l'image.
Après réception des DW de la cartes, le décodeur va vérifier les Flags et options qui ont été sélectionné dans la CA 88.
Si nano E0 => le décodeur avant d'envoyer les DCW issus de la carte vers le demux ( qui va décrypter le signal et faire apparaître sl'image ) va opérer des opérations complexes liées certainement au numéro de série / identifiant de la carte.
Pourquoi utiliser un identifiant / UA de carte comme option de traitement.
Parce que tout simplement, si l'identifiant du décodeur est posté publiquement, Viaccess peut le blacklisté ... envoyer une mise à jour de désactivation à la carte dirigé vers l'UA de la carte ( EMM ) et selon une matrice , désactiver cet ID , et pour le numéro de série de la carte UA , tout simplement ne plus autoriser de mise à jour vers cette carte. D'où le fait que certains zozos ne reçoivent plus d'EMM quoi qu'ils fassent car ils ont été grillé par C-ANAL-SAT donc n'utilisez pas les cline publiques, ne partagez pas avec le premier venu même s'il a toutes les cartes de films de boule
Donc si on partage des DCW issus d'une carte qui utilise la CA 28 => si les DCW sont envoyé sur le réseau sans traitement , il est fort probable que Viaccess puisse identifier ceux qui partagent leur carte .... UA = numéro de série de la carte. Une carte, un numéro de série. Un num de série =>> un client. Un client >> un nom, un prénom, une adresse voire plus Wink
Ensuite, les possibilités qui vous sont offertes pour contrer le bordel ?
Les décodeurs ont sans doute des parties qui permettent d'offusquer/contourner les clefs d'apparage .... mais rien ne dit que des techniques "similaires" ayant été utilisées sur la PS3 ( le glitch au niveau du controlleur du bus de la RAM ;-) ) , ne soit pas applicables tant au niveau du bus pour le jtag, que la ram , la flash... voir utiliser une double RAM ;-) , utiliser la Flash principal pour autoriser le boot du décodeur et switcher sur la seconde pour lancer un kernel tree linux + drivers ....
Voir même une attaque hardware de type MiM ( Man in the middle ), donc en clair espionner la RAM. Ce type d'attaque devrait pouvoir se faire à l'aide d'un équipement lourd (FPGA , station de soudure etc... ), ce que le commun des mortels ne possède pas, on peut avoir les idées mais pas les outils.
Le décodeur TNTsat Ready a été dumpé avec une simple interface Jtag // ( Strong SRT SD ), Ce déco n'est pas HD donc rien ne nous dit que la nano y est gérée, sauf que dans la liste des CLA de l'init du CAS viaccess, la commande CA 28 est bien présente ;-) . Suffit donc de dumper la machine et voir ce qu'elle a dans les tripes.
Quant aux décodeurs HD, ils ont le port Jtag locké/protégé, donc pas de salut... si en partant du constat que le connecteur jtag est présent sur la carte mére, dans le cas contraire ils faut retracer les pads du SoC et pouvoir avoir des points alternatifs.
Les flashes de dernières générations sont cryptées, si elle sont dessoudées, donc non seulement il faut du hardware onéreux pour dessouder la flash Ebga mais non seulement il faut le hard pour la lire ( si cryptée ..c une autre étape ).
Mais bon si on a accès à un décodeur ayant un terminal shell ( Série ou réseau ;-) ) c'est la porte ouverte, aprés on peut utiliser le décodeur au pire comme passerelle qui va distribuer la carte.
Petit indice pour le JTAG (c comme pour les DSI30/21 de l'époque T*P*S):
Matériel nécessaire :
1. Déco TNTSAT
2. JTAG (ou sniffer de Workbench)
Pour le JTAG, cf. LE LIEN EST HS (je l'ai retiré)
Une fois le dump obtenu :
1. Trouver une version d' IDA pro ( *ttp://fr.wikipedia.org/wiki/IDA_Pro_%28logiciel%29 )
2. Trouver le PDF du SoC ( STi 71xx ) , installer STlinux ( w-w-w.stlinux.com ), pour avoir un environnement de DEV SH4 ( ST40 ) , pour faire quelque test basic ( C -> ASM ) ,reverser le code ASM du firmware dumpé.
3. Isoler le loader
4. Isoler le CAS ( s'il n'y pas de mise à jour dynamique ... par exemple ... ).
A cela, ajouter la possibilité d'émuler du code ST40 avec ... mumm Qemu recompiler sous linux ... on sait jamais ... pourquoi ne pas émuler le firmware du déco dans une machine virtuelle...
Merci à .....
Vous trouvez ce message utile ? Votez !
