canalsat HD
- Thread starter lukas26
- Start date
Bonjour;
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 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 - - -
Bonjour;
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 ANALSAT 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, ANALSAT 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
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...
traduction google:
hrvatskifrancuskiengleskiAlpha
Hello;
The provider is completely out 022,610, even with sharing it no longer works .. 032 830 for the HD channels are out of sharing, and soon the SD channels that provider will be out .. Canal + has launched a new demo with the nano EO, which will prevent the sharing of its official maps, and as soon as that demo will be distributed to its subscribers, the sharing .. bye bye WITH ALL THIS THEN SPEAK AGAIN ON THIS CURSED CARD.
--- Updated ---
Hello;
Here again the net, they say the nano EO:
This is what we can summarize on nano E0. Retrieved on various forums including oscam forum.
For some HD channels do not work? Because ANALSAT now uses a new nano nano called E0.
A priori how this new nano (properly managed by the Canal Ready receivers stamped off)?
- The nano E0 performs post-processing on the Decrypt word from the map, that the decoder using the code pairing is correct to have the good.
- The nano E0 is called CTRL-ECM (control ECMs) using this nano ANALSAT secure the DCW so that it is not possible to share across the network.
How does the decoder Canal Ready is paired (ie a link is made between the card and the decoder has a unique address)?
1. The decoder is initialized and initializes all its module crypto CAS (see the menu information from your decoder. Library ACS Version)
2. The decoder will query the card to read the serial number, and the decoder is also sent him an identifier via the AC control 28.
Called pairing card (cardpairing in English)
The map knows its own serial number and an identifier for the decoder (serial number of the terminal and address only)
So the decoder knows his name and serial number of the card.
When changing channels, the decoder will parse the PMT (Program Map Table), check the conditional access and query the list of available IDENTs diffuser (those that have been read in this example map 032380, 032840 for CANALSAT ).
The decoder will extract the ECM stream (or by selecting a PID Packet IDentifier = packet identifier) ??-> and the treatment of ECM will start:
* The decoration will first verify that the nano D2 is not present. If this is the nano D2-> it will take the settings and PRE-treatment change after the nano bytes EA.
* It will check if the nano E0 exists, it will read the length of the nano and take the parameters of the nano and save them for later use.
The decoder will then send the command and contruire CA 88 (which will contain the body of the ECM from the stream (pid).
The decoder will check the status byte (command response. **** OK if eg 90 00) of the CA 88 is ok, if yes it will send a request to receive words of controls (DCW) to be used for decrypted image.
After receiving the DW maps, the decoder will check the flags and options that have been selected in the CA 88.
If nano E0 => decoder before sending DCW from the card to the demux (which will decrypt the signal and display sl'image) will operate complex operations related certainly serial number / ID card.
Why use a username / AU card as a treatment option.
Simply because, if the identifier of the decoder is posted publicly blacklisted Viaccess can ... send an update to disable the card facing the AU card (EMM) and in an array, disable this ID, and serial number of the card AU simply disallow update to this map. Hence the fact that some zozos no longer receive EMM what they do because they were grilled by C-ANAL-SAT so do not use the public cline, do not share with just anybody though all the cards movies ball: D
So if you share the DCW from a card that uses the CA 28 => if DCW are sent over the network without treatment, it is likely that Viaccess can identify those who share their map .... UA = serial number of the card. Card, a serial number. A serial num = **** a client. A customer **** name, a name, an address or even more
Then the possibilities that are offered to counter a mess?
Decoders may have parts which would allow to offend / bypass keys apparage .... but nothing says that techniques "like" has been used on the PS3 (the glitch at the bus controller RAM ;-)), is not applicable in both bus for jtag, the ram, the flash ... see use a dual RAM ;-), use Flash to allow the main boot switcher decoder and the second to launch a linux kernel tree + drivers ....
Or even a hardware attack type MiM (Man in the middle), so plain spy RAM. This type of attack should be possible with heavy equipment (FPGA, soldering station etc ...), that the common man does not have, you can have the ideas but not the tools.
Ready TNTSAT decoder was dumped with a simple interface Jtag / / (Strong SRT SD) This decor is not HD so nothing tells us that the nano is managed, except that the list of CLA init CAS viaccess, CA 28 command is present ;-). Just have to dump the machine and see what it has in the guts.
As for HD decoders, they Jtag port Locke / protected, so no salvation ... if based on the observation that the jtag connector is present on the mainboard, otherwise they must track pads SoC power and have alternative points.
Flashes of past generations are encrypted if they are unsoldered, not only must the hardware expensive to desolder the flash EBGA but it must not only hard to read (if encrypted .. another step c).
But hey if you have access to a decoder having a terminal shell (Series or network ;-)) is the open door, after the decoder can be used as a gateway to the worst that will distribute the card.
Hint for JTAG (c DSI30/21 as for the time T * P * S):
Materials needed:
1. Deco TNTSAT
2. JTAG (or sniffer Workbench)
For JTAG, cf. THE LINK IS HS (I removed)
Once the dump obtained:
1. Find a version of IDA Pro (* ttp :/ / fr.wikipedia.org / wiki / IDA_Pro_ 28logiciel%% 29)
2. Find the PDF of SoC (STi 71xx), install STlinux (www.stlinux.com) to have a DEV environment SH4 (ST40), to test some basic (C -> ASM) ASM code repay the firmware dumped .
3. Isolate the loader
4. Isolate the CAS (if there is no dynamic update ... for example ...).
To this, add the ability to emulate the code ST40 with ... mumm Qemu recompile linux ... you never know ... why not emulate the firmware deco in a virtual machine ...
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 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 - - -
Bonjour;
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 ANALSAT 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, ANALSAT 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
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...
traduction google:
hrvatskifrancuskiengleskiAlpha
Hello;
The provider is completely out 022,610, even with sharing it no longer works .. 032 830 for the HD channels are out of sharing, and soon the SD channels that provider will be out .. Canal + has launched a new demo with the nano EO, which will prevent the sharing of its official maps, and as soon as that demo will be distributed to its subscribers, the sharing .. bye bye WITH ALL THIS THEN SPEAK AGAIN ON THIS CURSED CARD.
--- Updated ---
Hello;
Here again the net, they say the nano EO:
This is what we can summarize on nano E0. Retrieved on various forums including oscam forum.
For some HD channels do not work? Because ANALSAT now uses a new nano nano called E0.
A priori how this new nano (properly managed by the Canal Ready receivers stamped off)?
- The nano E0 performs post-processing on the Decrypt word from the map, that the decoder using the code pairing is correct to have the good.
- The nano E0 is called CTRL-ECM (control ECMs) using this nano ANALSAT secure the DCW so that it is not possible to share across the network.
How does the decoder Canal Ready is paired (ie a link is made between the card and the decoder has a unique address)?
1. The decoder is initialized and initializes all its module crypto CAS (see the menu information from your decoder. Library ACS Version)
2. The decoder will query the card to read the serial number, and the decoder is also sent him an identifier via the AC control 28.
Called pairing card (cardpairing in English)
The map knows its own serial number and an identifier for the decoder (serial number of the terminal and address only)
So the decoder knows his name and serial number of the card.
When changing channels, the decoder will parse the PMT (Program Map Table), check the conditional access and query the list of available IDENTs diffuser (those that have been read in this example map 032380, 032840 for CANALSAT ).
The decoder will extract the ECM stream (or by selecting a PID Packet IDentifier = packet identifier) ??-> and the treatment of ECM will start:
* The decoration will first verify that the nano D2 is not present. If this is the nano D2-> it will take the settings and PRE-treatment change after the nano bytes EA.
* It will check if the nano E0 exists, it will read the length of the nano and take the parameters of the nano and save them for later use.
The decoder will then send the command and contruire CA 88 (which will contain the body of the ECM from the stream (pid).
The decoder will check the status byte (command response. **** OK if eg 90 00) of the CA 88 is ok, if yes it will send a request to receive words of controls (DCW) to be used for decrypted image.
After receiving the DW maps, the decoder will check the flags and options that have been selected in the CA 88.
If nano E0 => decoder before sending DCW from the card to the demux (which will decrypt the signal and display sl'image) will operate complex operations related certainly serial number / ID card.
Why use a username / AU card as a treatment option.
Simply because, if the identifier of the decoder is posted publicly blacklisted Viaccess can ... send an update to disable the card facing the AU card (EMM) and in an array, disable this ID, and serial number of the card AU simply disallow update to this map. Hence the fact that some zozos no longer receive EMM what they do because they were grilled by C-ANAL-SAT so do not use the public cline, do not share with just anybody though all the cards movies ball: D
So if you share the DCW from a card that uses the CA 28 => if DCW are sent over the network without treatment, it is likely that Viaccess can identify those who share their map .... UA = serial number of the card. Card, a serial number. A serial num = **** a client. A customer **** name, a name, an address or even more
Then the possibilities that are offered to counter a mess?
Decoders may have parts which would allow to offend / bypass keys apparage .... but nothing says that techniques "like" has been used on the PS3 (the glitch at the bus controller RAM ;-)), is not applicable in both bus for jtag, the ram, the flash ... see use a dual RAM ;-), use Flash to allow the main boot switcher decoder and the second to launch a linux kernel tree + drivers ....
Or even a hardware attack type MiM (Man in the middle), so plain spy RAM. This type of attack should be possible with heavy equipment (FPGA, soldering station etc ...), that the common man does not have, you can have the ideas but not the tools.
Ready TNTSAT decoder was dumped with a simple interface Jtag / / (Strong SRT SD) This decor is not HD so nothing tells us that the nano is managed, except that the list of CLA init CAS viaccess, CA 28 command is present ;-). Just have to dump the machine and see what it has in the guts.
As for HD decoders, they Jtag port Locke / protected, so no salvation ... if based on the observation that the jtag connector is present on the mainboard, otherwise they must track pads SoC power and have alternative points.
Flashes of past generations are encrypted if they are unsoldered, not only must the hardware expensive to desolder the flash EBGA but it must not only hard to read (if encrypted .. another step c).
But hey if you have access to a decoder having a terminal shell (Series or network ;-)) is the open door, after the decoder can be used as a gateway to the worst that will distribute the card.
Hint for JTAG (c DSI30/21 as for the time T * P * S):
Materials needed:
1. Deco TNTSAT
2. JTAG (or sniffer Workbench)
For JTAG, cf. THE LINK IS HS (I removed)
Once the dump obtained:
1. Find a version of IDA Pro (* ttp :/ / fr.wikipedia.org / wiki / IDA_Pro_ 28logiciel%% 29)
2. Find the PDF of SoC (STi 71xx), install STlinux (www.stlinux.com) to have a DEV environment SH4 (ST40), to test some basic (C -> ASM) ASM code repay the firmware dumped .
3. Isolate the loader
4. Isolate the CAS (if there is no dynamic update ... for example ...).
To this, add the ability to emulate the code ST40 with ... mumm Qemu recompile linux ... you never know ... why not emulate the firmware deco in a virtual machine ...
ELECTRIK DZ
VIP
- Messages
- 1,333