j'ai lu ca :
CanalSat vient d'informer ses abonnés que la distribution des chaînes du bouquet se ferait exclusivement en Mpeg4/H.264 d'ici la fin du mois de juin 2015.
Dans un courrier adressé à ses abonnés, CanalSat a, en effet, expliqué qu'il allait graduellement migrer toutes ses chaînes vers le standard Mpeg4/H.264, ce qui permettra à un plus grand nombre de chaînes d'être diffusées en HD.
L'utilisation du codec Mpeg4 va ainsi permettre à l'opérateur d'économiser ses ressources satellitaires afin de pouvoir lancer de nouveaux services. L'ambition première étant, bien entendu, de diffuser toutes les chaînes du bouquet en haute définition.
CanalSat planche donc actuellement sur la mise à jour de tous les décodeurs déjà installés.
ce courrier annonce la mort de la diffusion en sd pour juillet 2015 le sharing va etre difficile car on a deja pas mal de difficulté avec les chaines en hd
Si ils font ce que certains providers ont fait, lier la carte au decodeur et avoir une solution 100% propriétaire, je crains fort que un bon nombre d'entre nous mettrons leur démo au placard
.png)
A tous les membres voici un nouveau article fait par camara un grand expert du cardsharing
Le provider 022610 est complètement out, même avec le sharing il ne fonctionne plus.. Pour le 032830, les chaines HD sont out en sharing, et bientôt les chaines SD de ce provider seront out.. Canal + a lancé un nouveau demo doté de la nano EO, qui va empêcher le partage de ses cartes officielles, et dès que ce démo sera distribué à ses abonnés, bye bye le sharing.. ALORS AVEC TOUT CELA ON PARLE ENCORE DE CETTE MAUDITE CARTE.
- - - Mise à jour - - -
Voila repris du net, ce qu'on dit de la nano EO:
Voilà ce qu'on peut résumer concernant la nano E0. Récupéré sur différents forums de discussion et notamment oscam forum.
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é (c'est 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 construire 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 CANAL-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
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
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...
à conclurer cette article je suis sûr sans aucun doute qu'on doit dump du box de canal et extraire la box key et rsa keys et utiliser dans nos Oscam
Mais le problème est que quells sont les outils nécessaire pour dump la box de canal et comment faire tout aide est la bienvenue merci par avance à tout ce qui ont donner leur point de vue et tout ce qui vont le faire aussi jusqu'à la résolution de ce problème
copier coller d une news d un forum
- - - Mise à jour - - -
j'espere qu'on aura des solutions plus tard car apres les bein sport , et canalsat ca portera le coup fatal la
CanalSat vient d'informer ses abonnés que la distribution des chaînes du bouquet se ferait exclusivement en Mpeg4/H.264 d'ici la fin du mois de juin 2015.
Dans un courrier adressé à ses abonnés, CanalSat a, en effet, expliqué qu'il allait graduellement migrer toutes ses chaînes vers le standard Mpeg4/H.264, ce qui permettra à un plus grand nombre de chaînes d'être diffusées en HD.
L'utilisation du codec Mpeg4 va ainsi permettre à l'opérateur d'économiser ses ressources satellitaires afin de pouvoir lancer de nouveaux services. L'ambition première étant, bien entendu, de diffuser toutes les chaînes du bouquet en haute définition.
CanalSat planche donc actuellement sur la mise à jour de tous les décodeurs déjà installés.
ce courrier annonce la mort de la diffusion en sd pour juillet 2015 le sharing va etre difficile car on a deja pas mal de difficulté avec les chaines en hd
Si ils font ce que certains providers ont fait, lier la carte au decodeur et avoir une solution 100% propriétaire, je crains fort que un bon nombre d'entre nous mettrons leur démo au placard
A tous les membres voici un nouveau article fait par camara un grand expert du cardsharing
Le provider 022610 est complètement out, même avec le sharing il ne fonctionne plus.. Pour le 032830, les chaines HD sont out en sharing, et bientôt les chaines SD de ce provider seront out.. Canal + a lancé un nouveau demo doté de la nano EO, qui va empêcher le partage de ses cartes officielles, et dès que ce démo sera distribué à ses abonnés, bye bye le sharing.. ALORS AVEC TOUT CELA ON PARLE ENCORE DE CETTE MAUDITE CARTE.
- - - Mise à jour - - -
Voila repris du net, ce qu'on dit de la nano EO:
Voilà ce qu'on peut résumer concernant la nano E0. Récupéré sur différents forums de discussion et notamment oscam forum.
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é (c'est 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 construire 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 CANAL-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
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
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...
à conclurer cette article je suis sûr sans aucun doute qu'on doit dump du box de canal et extraire la box key et rsa keys et utiliser dans nos Oscam
Mais le problème est que quells sont les outils nécessaire pour dump la box de canal et comment faire tout aide est la bienvenue merci par avance à tout ce qui ont donner leur point de vue et tout ce qui vont le faire aussi jusqu'à la résolution de ce problème
copier coller d une news d un forum
- - - Mise à jour - - -
j'espere qu'on aura des solutions plus tard car apres les bein sport , et canalsat ca portera le coup fatal la
