Merci Merci:  6
Likes Likes:  0
Dislikes Dislikes:  0
Affiche les résultats de 1 à 8 sur 8

Sujet : le principe de auto-update


  1. #1
    V.I.P
    Inscrit
    Sep 2007
    Âge
    35
    Messages
    171
    Récepteur
    DM
    TV
    SAMSOUNG
    Remerciement / J'aime

    le principe de auto-update

    mieux comprendre le fonctionnement d'auto update

    http://www.zshare.net/download/53775116faca3588/

    @+........azm

  2. Merci raziano disent merci

  3. #2
    DZSatien Habitué
    Inscrit
    Jul 2008
    Lieu
    ALGER
    Messages
    260
    Récepteur
    GEANT -STARSAT -
    TV
    ENTV
    Remerciement / J'aime
    principe

    --------------------------------------------------------------------------------
    Le fonctionnement général :
    On sait qu'en fonctionnement normal, une carte mémorise 3 clefs de décryptage du flux MPEG.
    Ces trois clefs : 0C - 0D - 0E ont une fonction très simple.
    A intervalles réguliers (environ toutes les 10 secondes), une trame est émise par le satellite, elle transite par le terminal et finit sa course dans la carte. Cette trame qui débute par C1 3C contient deux mots codés ainsi que l'indice de la clef à utiliser (0C, 0D, 0E) pour les décoder.
    Lors de la trame suivante une C1 3A, le terminal viendra récupérer les mots décodés et les utilisera pour afficher l'image et restituer le son. Si les mots restitués ne correspondent pas aux valeurs attendues, c'est l'écran noir.
    Parmi ces trois clefs, la dernière (0E) est très particulière. Elle ne change jamais. A la base, cette clef est utilisée pour les émissions gratuites, les bandes-annonces, la mosaïque, C+ en clair. C'est pourquoi une carte d'abonné qui n'est plus valide permet toujours de voir ces émissions. Elle est également utilisée dans d'autres cas particuliers.
    Les deux autres clefs sont dites " Clefs mensuelles ", car cela correspond à leur période de validité.
    Prenons un exemple concret.
    Imaginons que nous sommes le 15 janvier, et que nous avons un abonnement valide (on peut bien rire).
    Notre carte contient les trois clefs. La date de fin de droits est au 28 février. Elle utilise normalement la clef 0C.
    Vieillissons un peu:
    Nous passons au 1° février. La clef utilisée alors est la Clé 0D. Tiens ! Tiens ! Voilà une trame de mise à jour (C1 40 01 81 4E) qui a du voir de la lumière et qui est passée par-là. Elle a remplacé la valeur de la clef 0C devenue obsolète par une toute nouvelle valeur qui sera utilisée au mois de mars. En passant, elle a également mis la date de fin de droits au 31 mars. Formidable non !
    Ce mécanisme s'appelle " L'Auto-update " (mise à jour automatique en français) et nous l'appellerons l'AU.
    En résumé :

    --------------------------------------------------------------------------------
    Comment est-on arrivé là :
    Alors ! Me direz-vous, ces fameuses clef, elles arrivent comment ?
    Ben, on y vient. On va enfin parler de PPUA et de MK1.
    Essayons de rester dans le concret. Disons que nous avons une carte d'abonné valide avec un fournisseur d'accès comme C+
    Notre chère carte (dans les deux sens du terme) contient certaines informations nous reliant à ce provider(fournisseur de service).
    1. Le célèbre et fameux PPUA.Que l'on peut assimiler à au N° client chez C+. Il n'a pas deux clients avec le même PPUA.
    2. La non moins célèbre MK1.
    Maintenant C+ est confronté à un dilemme.
    D'un côté, si C+ veut envoyer les trames d'AU à chaque abonné, sachant qu'il envoie ces trames d'AU toutes les 20 minutes et connaissant le nombre de généreux donateurs qui contribuent à son chiffre d'affaire, ça ferait beaucoup, pour ne pas dire trop. De l'autre coté, ces trames d'AU, pour être prises en compte, devront être décodées avec une clef, la MK1.
    Envoyer la même trame à tous les abonnés implique qu'ils aient tous la même MK1. Cela n'est pas bon et nous nous retrouverions comme avec nos 0C, 0D, 0E. Il suffirait qu'un gugusse les mette sur le net et vous voyez le résultat.
    A ce stade de la réflexion il faut prendre en compte une autre particularité du système SECA/MÉDIAGUARD. A l'allumage de notre terminal, celui ci questionne notre carte bien aimée et lui demande certaines informations, telle que son N° de série et aussi le PPUA. Il est ensuite capable de filtrer certaines trames, c'est-à-dire de ne pas transmettre à la carte les trames qui ne la concernent pas.
    Par exemple, les trames de réactivation sont émises à destination d'un N° de série. Hors piratage, une seule carte réceptionne la trame.
    Alors, que fait-on ? On tronçonne le PPUA (4 octets) pour le scinder en un bloc de 3 octets appelés la SA (Shared Adress ou Adresse Partagée). Le quatrième octet, appelé le CUSTWP (CUSTom Word Pointer) identifiera un abonné parmi les 256 qui, potentiellement, partagent le même SA.
    En final, voilà l'astuce.
    Les trames D'AU sont émises et filtrées par le terminal, qui ne laissera passer à la carte que les trames correspondantes à la SA. De fait, une même trame pourra mettre à jour jusqu'à 256 cartes d'abonnés d'un coup. Certes, ces 256 abonnés partageront la même clef MK1, mais cela n'est pas très grave. C'est du moins ce qu'ont pensé les concepteurs du SECA/MÉDIAGUARD.

    Si mon PPUA est 12 34 56 78 (quatre octets),
    mon SA est donc 12 34 56 (trois premiers octets) et
    mon CUSTWP est égal à 78 (le quatrième et dernier octet).
    Si ma clef de décodage des trames d'AU (ma MK1) est
    FE DC BA 98 76 54 32 10
    et sachant que tous les abonnés dont le PPUA commence par 12 34 56 ont la même clef MK1 (décodage des trames d'AU),
    et si tous les CUSTWP du SA 12 34 56 sont valides,
    Nous sommes donc 256 abonnés à avoir la même MK1.

    Les choses concrètes :

    --------------------------------------------------------------------------------

    On en arrive aux choses concrètes. Ces trames comment sont-elles construites ? Nous allons sauter une étape pour mieux y revenir ensuite, et décortiquer une trame lorsqu'elle est exploitable. Attention les yeux ! En voici une !
    C1 40 01 81 4E 40 F0 FB FF FF FF BE FF FF FB FB FF FF FF AD FF FF DF D7 FF 5E FC ED 9F 3F CF F7 EF FF FF FF 7F FE FF 22 16 5C 21 16 9E 90 5D 0F 68 6C 50 57 B4 49 41 90 5C 23 72 E7 A9 49 D3 D5 F9 90 5E B1 53 19 FF CA B1 46 D1 82 32 B0 99 6D 9B 3E 2A 77 97 3C
    88 octets ! Ben merde alors !!!
    Non, non ! Ce n'est pas si compliqué que ça. Toutes les trames respectent des règles bien définies. Mettons cette trame en forme et commentons là.
    En fait, on découpe la trame en " Nano " qui sont des informations complémentaires. Les nanos sont répertoriées. Le premier octet l'identifie et donne sa longueur avec son premier caractère. Ici, il ne s'agit pas d'interprétation : il faut tout simplement se reporter à un tableau des nanos répertoriées (convention).
    Décortiquons, décortiquons :
    C1 40 0x 81 4E: est une commande.
    Elle signifie simplement : " Trame d'AU sur le fournisseur X ". X étant égal à 1, il s'agit du premier provider présent sur ma carte après le provider SECA.
    40 est appelé l'écho : il reprend l'octet suivant C1, rien de plus.
    F0(Nano de 32 octets : détermination des CUSTWP FB FF FF FF BE FF FF FB FB FF FF FF AD FF FF DF D7 FF 5E FC ED 9F 3F CF F7 EF FF FF FF 7F FE FF
    22( Nano de 2 octets : Vérifie la date de fin de droits ) 16 5C = 28/02/2001
    21( Nano de 2 octets : Fixe la date de fin de droits ) 16 9E = 31/03/2001
    90(Nano de 9 octets suivie par l'index clé et la clé primaire codée) 5C
    (Après Décryptage, on obtient : 0C = 33 98 8E D4 0F 8B CB 9F)
    90(Nano de 9 octets suivie par l'index clé et la clé primaire codée) 5D
    (Après Décryptage on obtient : 0D = 53 82 25 50 45 8D 16 CD)
    90(Nano de 9 octets suivie par l'index clé et la clé primaire codée) 5E
    (Après Décryptage on obtient : 0E = 42 64 5B 70 0D CD 69 89)
    82(8 octets suivis de la signature ) :32 B0 99 6D 9B 3E 2A 77
    97 3C : Octets de statut

    LA NANO F0.
    F0 (Nano de 32 octets : détermination des CUSTWP FB FF FF FF BE FF FF FB FB FF FF FF AD FF FF DF D7 FF 5E FC ED 9F 3F CF F7 EF FF FF FF 7F FE FF
    La nano F0 est très importante. Nous avons vu précédemment que cette trame peut potentiellement aller jusqu'à 256 cartes. C'est cette nano qui permet à la carte de savoir si elle est concernée. Comment ? Très simple.
    Si nous convertissons cette chaîne hexadécimale en binaire, nous obtenons une suite de 256 valeurs 1 ou 0. Puis, nous comptons à partir de la droite vers la gauche.
    Le premier bit correspond au CUSTWP 00, le second au CUSTWP 01, le troisième au CUSTWP 02, …, le 11° au CUSTWP 0A, le 256° au CUSTWP FF. Lorsque le bit est à 1, la carte est concernée, si le bit est à 0, elle ne l'est pas et l'AU ne se fera pas.
    Exemple : si la chaîne traduite était :
    001011101011001…00101101001101
    Nous aurions donc (de gauche à droite) :
    Bit FF : valeur 0 donc pas concernée
    Bit FE : valeur 0 donc pas concernée
    Bit FD : valeur 1 donc concernée
    Bit …
    Bit 02 : valeur 1 donc concernée
    Bit 01 : valeur 0 donc pas concernée, et enfin
    Bit 00 : valeur 1 donc concernée.
    Il existe des utilitaires donnant la liste des CUSTWP valides à partir d'une nano F0, ce qui évite de faire ce travail manuellement. Citons, par exemple, Angel qui intègre un grand nombre d'utilitaires dont celui-ci.
    Le Truc du pirate :
    J'ai récupéré une carte qui n'est plus valide, Je veux en faire une MOSC (Modified Original Smart Card).
    Avec tous les outils disponibles, j'ai extrait la MK1. La mise à jour ne fonctionne pas. Normal, me dites-vous : cette carte n'est plus valide.
    Qu'à cela ne tienne, je logue une trame d'AU et je décode la nano F0. Ca y est, je connais tous les CUSTWP valides. Je n'ai donc plus qu'à remplacer le mien par un autre valide et je goûte au plaisir de l'AU, ma MK1 étant commune à tous ceux qui réceptionnent cette trame.
    LA NANO 22
    22( Nano de 2 octets : Vérifie la date de fin de droits ) 16 5C = 28/02/2001
    La nano 22 comporte simplement la date de fin de droit, tel que nous pouvons l'apercevoir sur notre petit écran en faisant PERSO-6. Elle est ici représentée sous sa forme hexadécimale en respectant les conventions de date SECA.
    Pourquoi cette information ?
    Simplement parce qu'une carte officielle la vérifie et, n'effectuera le mise à jour des clefs que si cette date n'est pas échue.
    Voici l'explication d'un phénomène connu :
    Je m'absente plus de deux mois, et, à mon retour, lorsque j'allume mon terminal, rien ne passe (écran noir). J'attends le passage des trames d'AU (une demi-heure sans zapper sur une chaîne codée), mais elles n'ont aucun effet. La date de fin de droit mémorisée dans ma carte est dépassée. Je n'ai plus qu'une solution : appeler la hot-line de C+ et leur demander d'envoyer une trame de réactivation.
    LA NANO 21.
    21(Nano de 2 octets : Fixe la date de fin de droits )
    16 9E = 31/03/2001
    Là, pas besoin de sortir de Saint-Cyr pour deviner. C'est tout simplement la nouvelle date de fin de droits que devra mémoriser la carte si cette trame est bien exécutée. Comme la précédente, elle respecte le même format.
    LA NANO 90
    90(Nano de 9 octets suivie par l'index clé et la clé primaire codée) 5C
    Les nanos 90, les bonnes nanos 90, devrai-je dire. Celles pour lesquelles nous décortiquons le mécanisme.
    Elles comportent l'objet de toutes nos convoitises. Le premier octet suivant le 90 indique la clef dont la valeur va suivre, les 8 octets suivants sont sa valeur. On voit donc que la trame d'AU réactualise l'ensemble des clefs mensuelles.
    Lorsque le 1° octet vaut 5C il s'agit de la clef 0C, 5D, c'est la 0D, et bien sûr 5E, la 0E.
    Pour compliquer les choses, ces clefs ne sont pas données en clair. Il va falloir les faire passer à la torture, leur appliquer l'algorithme SECA en utilisant notre MK1.
    Je ne développerai pas ici l'algorithme. Sans mes notes j'en serais bien incapable. Mais il s'agit simplement d'une suite de calculs, d'opérations logiques dans lesquelles les valeurs de départ sont d'une part, la valeur donnée par la trame dans la nano 90 et, d'autre part, la MK1. Au final on obtient comme résultat une nouvelle valeur hexadécimale de 8 octets qui constitue la valeur réelle de la clef mensuelle.
    Pour reprendre l'exemple de la 1ère nano 90 :
    90 5D 0F 68 6C 50 57 B4 49 41
    Elle concerne la clef OD, la valeur cryptée de la clef est " 0F 68 6C 50 57 B4 49 41 ". Après décryptage de cette valeur avec notre MK1, nous obtenons la clef suivante :
    " 53 82 25 50 45 8D 16 CD " qui est la nouvelle valeur à mémoriser dans la carte.
    LA NANO 82
    82 (8 octets suivis de la signature ) : 32 B0 99 6D 9B 3E 2A 77
    La nano 82 c'est la signature. Celle-là, elle porte bien son nom, car il résume bien sa fonction. Le rôle de la signature est très simple : il authentifie la validité de la commande.
    La signature est calculée sur la trame de base, soit
    C1 40 01 81 4E 40 F0 FB FF FF FF BE FF FF FB FB FF FF FF AD FF FF DF D7 FF 5E FC ED 9F 3F CF F7 EF FF FF FF 7F FE FF 22 16 5C 21 16 9E 90 5D 0F 68 6C 50 57 B4 49 41 90 5C 23 72 E7 A9 49 D3 D5 F9 90 5E B1 53 19 FF CA B1 46 D1
    Elle utilise l'algorithme de calcul de signature SECA (qui est différent de l'algorithme de décryptage), d'une part, et la MK1 dans le cas des trames d'AU, d'autre part.
    LES OCTETS DE STATUT
    97 3C : Octets de statut
    Les octets de statut forment la réponse renvoyée par la carte. Ce statut est différent en fonction de ce que la carte à fait de la commande. Les réponses possibles sont :
    90 00 : La mise à jour vient de se faire. (Réponse normale à la 1° trame).
    97 XX : La mise à jour est déjà présente.
    93 01 : Date de validité dépassée Mise à jour non effectuée.
    90 09 : CUSTWP non valide Mise à jour non effectuée.
    90 02 : Signature absente ou erronée Mise à jour non effectuée.

    En conclusion :
    Nous avons déjà fait un bon tour du sujet, mais rappelez-vous lorsque je vous ai montré pour la 1° fois notre trame, j'ai précisé que nous sautions une étape, mais que nous y reviendrons.
    Cet instant est arrivé. Car, jusqu'à présent, tout le monde a suivi. C'était donc trop simple.
    SECA, dans sa grande bonté, a compliqué un tantinet les choses. En effet, si vous surveillez le dialogue entre carte et terminal, vous ne verrez jamais passer une telle trame.
    Le début, oui (C1 40 01 81 4E), mais pas la suite. Vous retrouveriez le même nombre de caractères, mais pas moyen d'identifier les nanos
    en resumé

    --------------------------------------------------------------------------------
    " KESKECQSEBORDEL !! "
    La trame, lorsqu'elle est émise, est cryptée. Et toujours avec notre MK1. N'entrons pas dans le détail, mais disons seulement que C+ prend la trame que nous avons analysée, la coupe en blocs de 8 octets, applique à chaque bloc l'algorithme inversé et envoie le résultat par le satellite.
    Résumé:
    Le système de mise à jour automatique est basé sur les 3 premiers octets du PPUA (en fait, la Shared Address). C'est sa valeur qui détermine les trames que le terminal laissera passer jusqu'à la carte. Tous les possesseurs d'une même SA possèdent également la même MK1, qui est utilisée pour décrypter la trame et en extraire les clefs mensuelles.
    Le travail qu'effectue notre belle carte officielle lorsqu'elle reçoit un C1 40 0x 81 4E .. .....
    1° Je décrypte cette trame.
    2° Je contrôle si la signature est valide.
    3° Je vérifie que la date de fin des droits n'est pas dépassée.
    Et si tout cela est OK :
    4° Je décode les clefs contenues dans les nanos 90.
    5° Je mets à jour les infos de ma mémoire (Clefs plus nouvelle date de fin des droits).
    6° Je renvoi les 2 octets de statut.
    Il reste encore une question que je sens poindre dans vos esprits assoiffés.
    " MK1 oui, mais on entend toujours parler des clés primaires et des clés secondaires ? Alors ? "
    Et bien, oui ! Toutes les clés (que se soit les clés de décodage mensuelles ou les MKx) sont organisées en deux blocs de 8 octets. Le provider, suivant la manière dont la trame est envoyée, peut demander la mise en œuvre de la clé primaire ou de la clé primaire ET la clé secondaire.
    Mais notre bon C+ a un problème. Depuis le nombre d'années qu'il diffuse des programmes payant, il a fait évoluer son système et c'est la raison pour laquelle on entend parler de " Version de cartes ". Et seules les cartes à partir de la version 4.0 sont aptes à utiliser pleinement les clés primaires et les clés secondaires. Le parc d'abonnés utilisant des versions 3.0 et 3.1 est encore important. n'utilise donc pas encore cette possibilité.
    On comprend l'importance de ces clefs secondaires lors de l'extraction des informations d'une carte officielle. Même si ça ne sert pas aujourd'hui, pour continuer à profiter de l'AU demain, ce sera impératif
    On peut penser que cette évolution ne se fera pas brutalement. Il est tout à fait possible à C+ de déplacer des abonnés équipés de cartes homogènes vers des SA identiques, et ainsi de commencer à utiliser cette " Superencryption ".
    POUR LES CARTES NON OFFICIELLES
    Là, nous touchons un point particulier.
    Prenons le cas des cartes WAFFER. A l'origine, il a fallu comprendre le système et écrire des programmes pour ce bon PIC16F84. Au départ, l'AU n'était pas géré, on avait donc recours à la programmation, puis à la mise à jour par la télécommande.
    Avec l'arrivée des premiers couples PPUA MK public, les petits génies de la programmation ont implémenté dans le PIC, les fonctions permettant de gérer l'AU. Mais pas comme le font les cartes officielles : seul le décodage des nanos 90 étaient assurés et c'était bien là le principal.
    Et les ennuis ont commencé. En effet, que se passe-t-il si C+ émet une trame destinée à ces fameux PPUA publics en utilisant des clefs fausses et une signature erronée ?
    Simple : ses abonnés ne sont pas perturbés, toutes les cartes WAFFER sont plantées avec des fausses clés. Idem s'il envoie une trame en la datant au 1° janvier 2010. Ces informations ne sont en effet pas gérées dans le code des PIC.
    L'évolution est telle que des nouveaux programmes sortent tous les jours. Ils se rapprochent de plus en plus du fonctionnement des cartes officielles et il est très difficile de connaître ce qu'ils gèrent et ce qu'ils ne gèrent pas. Mais, comme nous ne connaissons pas encore toutes les fonctionnalités des cartes officielles, nous aurons toujours un temps de retard.
    L'autre inconvénient de la WAFFER est engendré par la capacité des composants qu'elle utilise. Au début il n'y avait pas de problèmes. Mais à force d'implémenter de nouveaux contrôles, d'affiner certaines fonctions, de prévoir des réponses aux nouvelles trames qui apparaissent, le PIC16F84 n'a plus assez de capacité.
    Sa durée de vie en tant que carte complète est sans aucun doute compromise, à moins de faire des coupes sombres dans les fonctions programmées, car en définitive : il faut moins de 5 minutes pour reprogrammer une Eeprom. 5 minutes par mois justifie-t-il l'AU ? Est-ce si important que cela ?
    Je ne le pense pas. L'attrait essentiel de l'AU réside dans sa compréhension.
    Grand merci à David vincent pour cette excellente synthèse
    Geant 2500 HD


  4. #3
    Nouveau
    Inscrit
    Apr 2008
    Âge
    44
    Messages
    31
    Remerciement / J'aime
    passionnent et instructif

    merci

  5. #4
    DZSatien Confirmé Avatar de mondouble
    Inscrit
    Nov 2007
    Lieu
    SW france
    Âge
    73
    Messages
    59
    Récepteur
    spiderbox HD9000
    TV
    panasonic G20
    Remerciement / J'aime
    instructif - merci l'ami
    "AUSSI HAUT QUE L'ON SOIT ASSIS ON EST ASSIS QUE SUR SON CUL"
    HITECHBOX HB9000 cas3+ et curiosité..

  6. #5
    DZSatien Habitué
    Inscrit
    Feb 2008
    Messages
    189
    Récepteur
    dm800se
    TV
    samsung32"
    Remerciement / J'aime
    merci frere

  7. #6
    Membre Donateur
    Inscrit
    Nov 2008
    Âge
    51
    Messages
    6
    Remerciement / J'aime
    merci tres interressant pour la comprehension
    pas simple
    Salutations Did

  8. #7
    DZSatien Initié
    Inscrit
    Mar 2008
    Âge
    47
    Messages
    598
    Récepteur
    dm
    TV
    sam
    Remerciement / J'aime
    salut merci pour lexplication

  9. #8
    Nouveau
    Inscrit
    Feb 2010
    Messages
    15
    Récepteur
    DM800 HD
    TV
    Samsung
    Remerciement / J'aime
    Merci pour l'explication. Est-ce que c'est valable pour d'autres systèmes, comme le via ?
    Je n'ai pas compris pourquoi la nano F0 a une longueur de 32 octets

Règles des messages

  • Vous ne pouvez pas créer de sujets
  • Vous ne pouvez pas répondre aux sujets
  • Vous ne pouvez pas importer de fichiers joints
  • Vous ne pouvez pas modifier vos messages
  •  
Nous contacter | DZSat | Archives | Haut de page