Register

Welcome to the RDI-Board Community.

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed.


Donate Now Goal amount for this month: 100 EUR, Received: 100 EUR (100%)
Donate to support this site...

Page 1 of 2 12 LastLast
Results 1 to 15 of 19

Thread: Sky Italy MOSC

  1. #1
    Junior Member Friend
    RDI - Board Default Avatar

    Join Date
    Jan 2003
    Location
    Italy
    Posts
    29
    Posts Thanks / Likes

    Default Sky Italy MOSC

    Come viaggiano i segnali nell'etere? Il provider (ad. es. D-) invia i dati in "uplink" al satellite utilizzando il protocollo DVB; il satellite li rispedisce indietro a tutte le parabole sintonizzate su quel satellite (sempre con il protocollo DVB).
    Che cos'è il protocollo DVB? Questo protocollo serve per "miscelare" tutti i dati digitali insieme separandone l'utilizzo (MPEG2 audio/video, ECM/EMM, teletext, ecc...).
    Cos'è il DEC? Il DEC è lo strumento che riceve dalla parabola i segnali analogici (ma in formato digitale), si sintonizza sulla frequenza giusta (in base al canale scelto) e distribuisce i dati in formato DVB ai vari componenti.
    Innanzitutto partiamo dal segnale audio/video analogico che viene convertito in digitale tramite il protocollo MPEG2... Per ritrasformare il segnale in analogico basta decodificare il segnale MPEG2... Così facendo, però, non si riuscirebbe a distinguere gli utenti tra chi ha pagato per un servizio e chi non... A questo punto interviene il DVB-CA, ossia la parte del protocollo DVB che si occupa del "CA" ( Controllo d'Accesso ). Questa parte è stata standardizzata per tutti i provider stabilendo che il flusso dati MPEG2 (che è quello che permette di vedere/sentire) deve essere criptato usando un algoritmo universale, il CSA (Common Scrambling Algorithm).
    Questo algoritmo "segretissimo un tempo" utilizza una chiave "key CSA" per eseguire le operazioni di crypt/decrypt. Quindi il provider (D-) deve eseguire il crypt dei dati MPEG2 con la "Key CSA" e il DESCRAMBLER (apposito chip che ha integrato il CSA ) che deve decrittare i dati deve conoscere la stessa chiave usata dal provider.
    Poich non c'è stato un accordo su come mettere a conoscenza il DESCRAMBLER di questa importantissima chiave, si è creato un metodo standard a cui tutti i sistemi di protezione
    ( SEKA , ****** , VIACESS ) devono attenersi. Questi sistemi di protezione servono, come PRIMISSIMA FUNZIONE, per trasmettere al DESCRAMBLER la "Key CSA" utilizzata in partenza. Questa parte hardware si chiama CAM e al suo interno è inserito il DESCRAMBLER. Quindi la CAM colloquia con la smartcard. I dati che arrivano alla CAM sono ECM/EMM e il "payload" (ossia il flusso dati MPEG2 criptato). I dati che escono dalla CAM sono il "payload" decrittato (se la CAM verifica che l'utente è abilitato) altrimenti buio.
    A cosa serve il CSA? Il CSA, come detto prima, serve per criptare/decriptare i dati MPEG2. E' stato scelto un UNICO ALGORITMO per tutti i provider per permettere, appunto, allo stesso provider di spedire i suoi dati utilizzando più sistemi di protezione (ossia suka+iridato insieme). In questo caso esisterà UN SOLO FLUSSO MPEG2 (dati/video) criptato con un UNICA KEY CSA.
    Saranno presenti, però, DUE ECM (uno suka, uno iridato) dove verrà comunicata alla CAM il modo per risalire alla "Key CSA".
    Il flusso dati MPEG2 audio/video di un canale (ES=Elementary Strymmy) viene suddiviso in più pacchetti di dimensione variabile. Questi pacchetti prendono il nome di PES ( Packetized Elementary Streamm ).
    I vari PES vengono ancora una volta "inscatolati" nel TS ( Transport Stream ) che è il "mezzo di trasporto" del protocollo DVB-MPEG2. I TS sono di lunghezza fissa (188 bytes) e composti d�una "header" di 4 bytes ed un "payload" di 184 bytes come segue:
    HEADER (4 bytes):
    sync_byte 8 bits
    transport_error_indicator 1 bit
    payload_unit_start_indicator (PUSI) 1 bit
    transport_priority 1 bit
    PID 13 bits
    transport_scrambling_control 2 bits
    adaptation_field_control 2 bits
    continuity_counter 4 bits
    PAYLOAD = 184 bytes

    Nel Payload ci sono i dati che servono ( PES ).
    L'inizio di un PES deve obbligatoriamente essere all'inizio di un TS e il TS che trasporta l'inizio di un PES contiene il campo PUSI = 1. Se, invece, il TS contiene dati di un PES ( ma non l'inizio ) allora il PUSI = 0.

    Scrambling
    Scrambling = metodo per "sporcare" i dati originali attraverso un algoritmo (CSA) ed una chiave (CW).
    Lo scrambling può essere di diverso tipo ed esistono, infatti, diversi standard (DVB-CSA, ATSC, MULTI2, ecc...).
    Per permettere al decoder una corretta interpretazione dei dati vengono utilizzati i bit TS_
    scrambling per indicare se il "payload" è stato "sporcato" o meno.

    TS_scrambling:
    00 = FTA (free to air). Sono i canali in chiaro
    01 = Key fissa
    10 = even key
    11 = odd key
    Quando un TS trasporta dati "scramblati" lo si vede, appunto, dalla header. In questo caso il demux invierà l'intero TS al descrambler per poi riprenderselo indietro "in chiaro".

    CW
    Per eseguire una corretta operazione di descrambling, il descrambler necessita di una CW (control word)
    con cui poter "inizializzare" l'algoritmo. Le CW possono variare frequentemente e generalmente variano a tempi costanti (nel nostro caso ogni 10 secondi). Poich la CW è un dato "fondamentale" per eseguire il descrambling viene inviata a tutti gli utenti in forma "criptata" negli ECM (entitlement control message). Nel suka1-2 gli ECM sono rappresentati dalla INS 3C del Seka e della INS D1 40 nel NDZ2.La CW criptata può essere decriptata in modo corretto solamente attraverso una SMARTCARD aggiornata che contenga le giuste chiavi ( OKxx ) ed i diritti per la visione (in base al canale oppure PPV).
    Se si è abilitati la smart provvederà e decriptare la CW restituendola al descrambler.
    Le CW sono di 8 bytes ed esistono CW even e CW odd.
    Le CW sono fatte in questo modo:
    a1 a2 a3 c1 b1 b2 b3 c2
    dove a1,a2,a3,b1,b2,b3 sono dati fondamentali per la visione, non permutabili e c1 e c2 sono invece dei checksum di controllo della chiave fatti in questo modo:

    c1 = a1 + a2 + a3
    c2 = b1 + b2 +b3

    La CW che determina il descrambling, quindi, è di 6 bytes (48 bits).

    CSA
    Il DVB-CSA è l'algoritmo usato per il descrambling in europa ed è "segretissimo".
    Il DVB-CSA è un algo simil-DES che permette uno " scrambling /descrambling" abbastanza veloce ed "economico" per non incidere troppo sui prezzi dei decoder.


    Simulcrypt
    L'algoritmo CSA è STANDARD ed è UGUALE per tutte le pay-tv europee. Ciò che serve per mettere in chiaro il segnale è quindi solo la CW. Questa, però, può essere "protetta" con diversi sistemi (suka, iridato, n*s) usando lo standard DVB-CA ( Control Access ) e il "Symulcript". Se una pay-tv vuole trasmettere con tutti e 3 i sistemi, ad esempio, cripterà il "payload" con l'algo CSA e una CW. La CW verrà poi criptata nei 3 modi diversi (suka, iridato, n*s) e verranno inviati 3 ECM legati allo stesso "payload".
    Ogni sistema userà il proprio ECM per passare dalla CW criptata alla CW per il descrambler.
    L'Answer To Reset ( ATR ) di una smartcard Vide*guard è (esempio ATR smartcard italia) :

    3F 7F 13 25 02 40 B0 0C 69 FF 4A 50 C0 00 00 52 53 00 00 00

    La struttura,secondo ISO 7816 :

    TS = 3F Indirect convention
    T0 = 0x7F Il HighNibble (0111) indica la presenza dei parametri TA1, TB1, TC1;
    Il LowNibble (1111) indica la presenza di 15 historical charatecters.
    TA1 = 0x13 FI (clock rate conversion factor) = 1 DI (bit rate adjustment factor) = 3
    TB1 = 0x25 I1 (Maximum programming current) = 2 (max 50 mA)
    P11 ( programming voltage ) = 5 volt
    TC1 = 0x02 N (extra guard time) = 2
    TD1 = 0x40 protocol T = 0 (asynchronous half duplex character transmission protocol): No
    TCK (check character): TC2 Transmitted
    TC2 = 0xB0 not specified in ISO, but used as guard time extension
    T1,T2,T3 = ??
    T6 ... T13 = Corrisponde al tipo di card e provider.


    BaudRate Reset (al avvio comunicazione CAM / Card).
    Dall' ATR (parametro TA1) lo standard ISO 7816 ci permete calcolare il BaudRate (da questo momento ResetRate) di negoziazione fra CAM/CARD durante l'ATR.
    Assumiamo un Clock pari a 3.579 Mhz (come quello fornito da un comune Smart Mouse).
    Durante questa fase lo standard ISO 7816 indica che l' Etu iniziale è pari a 372 / f (f = frequenza clock in Hertz) :

    fi = 3.579 Mhz (opp. 3579000 Hertz)

    StartEtu = 372 / 357900 Hertz = 0,00001039396 sec

    Quindi :

    ResetRate = 1 / 0,00001039396 = 9620 => 9600 b/s

    BaudRate negoziazione.
    Il BaudRate di negoziazione (da questo momento ByteReset) si calcola considerando il WorkingEtu (determinato in base al parametro TA1 dell'ATR) :

    WorkingEtu = (1/X) * (Y/fi) sec

    X e Y si ricavano in base al valore di F1 e D1 del parametro TA1(Vedere standard ISO 7816)
    fi è la frequenza di clock applicata, espressa in Hertz. Nel nostro caso quindi:

    X = 372
    Y = 4
    fi = 3579000 Hertz

    WorkingEtu = (1/3)*(372/3579000) = 0,0000259849 sec

    Quindi :
    Baud Rate = 1/0,0000259849 = 38484 cio 38400 b/s

    In parole povere,all'avvio la CAM invia un RTS alto e poi lo abassa(invia un impulso) alla smartcard(CARD).
    Lei risponde con i parametri per cominciare a negoziare(comunicare) con la CAM.Ma se all'ATR comunica o negozia a 9600 , la negoziazione vera e propia lo fa a 38400.

    Struttura delle INS del NDZ
    Il Comando NDS ha la seguente struttura :

    CLA TIPO P1 P2 Len DataPacket ( Dati + 67 08 SIGN )

    * CLA = Classe ( Per NDS1 --> 48 , NDS2 --> Dx )
    * Tipo = Tipo ( Determina il tipo di ins da negoziare ).Può essere un DataRequest( Dx
    74..),opp Entitlemet Control Message( Dx 40..) opp un Entitlemet Management
    Message ( Dx 42 )
    * P1 = Parametro 1 ( Da gestire secondo necessità )
    * P2 = Parametro 2 ( Da gestire secondo necessità )

    * LEN( ILen opp P3 ) = Lenght ins (in esadecimale)
    CLA + TIPO + P1 + P2 + Len = Header
    Se la negoziazione è andata a buon termine all'invio della header,la card risponde con un ACK o Eco.
    Il DataPacket è composto :
    Dati = Pacchetto-Dati che compone il Comando; non è uguale per ogni Comando. Per
    alcune istruzioni contiene Nano e uNano seguiti dai relativi dati.
    0x067 = nano che indica una firma elettronica (Signature)
    0x008 = len del nano che in teoria dovrebbe indicare una lungheza della firma elettronica
    (Signature)
    SIGN = firma elettronica (Signature).è composta di 8 byte.

    Esempio :
    dalla CAM alla CARD ( --> )
    dalla CARD alla CAM ( <-- )
    La "negoziazione" fra CAM --> CARD si sviluppa con questo mecanismo :
    CAM -> CARD -> CAM.
    Vale sia per le ECM ed EMM che per le DQR.La differenza risiede nella risposta della CARD.
    La stringa di risposta ha una len pari alla Len indicata nel P3 della header ( se P3 = 0x04C => 76 byte )
    I byte finali &egrave; lo statusbytes ( SW1 / SW2 ).Per maggiore informazione vedere StatusByte.

    ECM - Entitlemet Control Message ( Messaggio Controllo Diritti )
    EMM - Entitlemet Mangement Message ( Messaggio Gestione Diritti )
    DRQ - Data Request ( Richiesta Dati )

    Nei ECM ed EMM la negoziazione CAM -> CARD -> CAM intervengono i nani sia per eseguire una routine che per l'esecuzione dei dati da parte della CARD.I nani nei DRQ,invece,determinano dopo ogni nano una'info e la lunghezza del info.


    Esempio DRQ
    La CAM invia un DRQ alla CARD
    --> D0 58 00 00 4C
    La CARD risponde OK al messaggio
    <-- 58
    La CARD risponde con le info richieste
    <-- 15 48 25 00 UU UU UU 03 F1 E8 88 5E 00 00 00 00 00 00 00 00 30 5A 2C 00 09 19 00 UU
    UU UU FF FF FF FF 00 SH SH 00 FF FF FF 00 00 00 00 00 00 00 00 00 08 00 00 00 01 49
    54 41 00 00 49 54 41 4C 49 41 20 20 5F 0D 33 41 00 00 00 00
    La CARD risponde che le routine sono state eseguite
    <-- 90 20 (20,3000000008615millisecondi)
    ( no error / no update alocation / no update Eeprom / bit IRD no setted )

    Esempio EMM :
    La CAM invia l'EMM alla CARD
    --> D1 42 00 00 20
    La CARD risponde OK al messaggio
    <-- 42
    La CAM invia i nani e relativi dati
    --> 90 1E 44 02 F6 1B 5E 93 97 DA 3A 4B 08 26 B2 B3 39 7F 20 5D D3 C7 37 43 B4 5D 4B CA
    58 88 DB 2A
    La CARD processa i nani e dati,se OK:
    <-- 9xx1
    Rinviando il commando
    <-- 9xx0 ( in questo caso aggiornamento non necessario.Cio&egrave; l'aggio = a quello in Eeprom )
    Altrimenti:
    <-- 9xx0 ( in questo caso non aggiornamento )

    Esempio ECM :
    La CAM invia l'ECM alla CARD
    --> D1 40 00 80 5E
    La CARD risponde OK al messaggio
    <-- 40
    La CAM invia i nani e relativi dati ( crittati con index cmd90 )
    --> 00 7F 0A CE 92 62 4E 57 ED E2 08 00 00 90 4F C0 02 C7 6F BE 14 D9 DE B8 A2 05 04 5E
    8F CA DB 2B 03 B5 C9 1C FE 03 78 F3 E9 C5 0D 54 CC 2F 36 0D 7A FF 1B 2D AC DB
    61 E4 52 D9 0C 3F D4 F7 87 F0 07 CA 2A 38 41 46 15 CA E2 B0 D3 70 E5 4A 7F 55 DD
    4B E7 CD 38 9B 33 F8 9F 30 36 65 FE FC
    La CARD risponde che le routine sono state eseguite
    <-- 90 20
    La CAM invia adesso la richiesta di risposta sul controllo del abbo,e (se controllo OK) di decript del CWord con la stringa del DWord
    --> D3 54 00 00 3C
    La CARD risponde OK al messaggio
    <-- 54
    La CARD invia alla CAM il DWord.Prima di elaborare e risponde col Dword la CARD ha gi&agrave; eseguito il controllo del abbo .
    <-- EB 4C 4D B5 88 6F 46 84 48 49 9C E0 88 5E 0D 4A 0B 61 C9 97 83 D7 D6 99 C5 8B 08 C0
    4E 69 F9 ED 2E 79 BB B9 10 F5 84 A4 F7 AC 7F D9 F9 DB 65 C8 59 64 EB F4 1B 4D 14
    2E A8 3F B2 13
    Eseguito
    <-- 90 20
    Le classi sono quattro ed ognuna indica all'invio della Header se l'ins sar&agrave; crittata o meno.Se verr&agrave; crittata con quale parametri e se l'ASIC verr&agrave; impegnato o meno.
    La Classe ( Dx ) ha 4 livelli di elaborazione del algoritmo :
    x = 0 --> paccheto non crittato. ( * )
    x = 1 --> paccheto crittato secondo cmd90. ( ** )
    x = 2 --> paccheto crittato (ultimi 16 byte crittati). ( *** )
    x = 3 --> paccheto crittato ( **** )

    ( * ) Il paccheto non &egrave; in alcun modo crittato.Se richiesta di un DataEMM ( esempio : D0 BE ) non autorizatto in chiaro la card risponde con x byte a 0x000.
    ( ** )Se la Lenbody <> 00 determina un paccheto crittato dopo il CardByteGeneration.
    ( *** ) a che serve,bohhhhh.
    ( **** ) L'INS viene "coperta" da una SSE come nel Seka (RSA) da un sistema di crittatura pseudo-casuale.Qualunque INS viene crittata in SSE a richiesta della CAM con LowNibble della classe 1101 00 | 1 | 1 | . ( => corrispondente )
    Facendo un brutte sul LowNibble della Classe con Tipo BE ottengo :
    D0 ----> 1101 00| 0 | 0 | => D4 ----> 1101 01| 0 | 0 | => D8 ----> 1101 10| 0 | 0 | => DC ----> 1101 11| 0 | 0 |
    D1 ----> 1101 00| 0 | 1 | => D5 ----> 1101 01| 0 | 1 | => D9 ----> 1101 10| 0 | 1 | => DD ----> 1101 11| 0 | 1 |
    D2 ----> 1101 00| 1 | 0 | => D6 ----> 1101 01| 1 | 0 | => DA ----> 1101 10| 1 | 0 | => DE ----> 1101 11| 0 | 1 |
    D3 ----> 1101 00| 1 | 1 | => D7 ----> 1101 01| 1 | 1 |
    con LN :
    DB ----> 1101 10| 1 | 1 |
    DF ----> 1101 11| 1 | 1 |
    La CARD non risponde.
    Visto che un qualsiasi corrispondete da la stessa risposta ed StatusByte della classe "madre" si evince che i bit di richiamo del processo crittatura sono il 1 e 2 del LowNibble del byte della classe.Ma non &egrave; ammesso il 4 alzato nel LN,penna blocco della CARD ( quindi il puntatore dello Stack ne esce fuori ) e necessario Reset.
    La classe D3 agisce criptando tutto il DataPacket + la �signa� di 8 bytes.
    Il processo di cifratura per le classi D2 e D3 non usa l�ASIC ( Application Specific Integrated Circuit ,usato invece per cifrare i dati tramite il nano 90 ). Anche la classe D3 necessita una len minima >10 ( SSE in MD5 ?? ).
    Classe HighNibble LowNibble
    Dx 1 1 0 1 0 0 | 0 | 0
    | |_ _ _ True / False cmd90
    |_ _ _ _ _ True / False cmd90 + SSE

    Se 1 bit del LN = basso ( Classe D0 ) e 2 bit del LN = basso allora cmd90 --> Non in uso
    SSE --> Non in uso

    Se 1 bit del LN = alto ( Classe D1 ) e 2 bit del LN = basso allora cmd90 --> In uso
    SSE --> Non in uso

    Se 1 bit del LN = basso ( Classe D2 ) e 2 bit del LN = alto allora cmd90 --> Non in uso
    SSE --> In uso
    Se 1 bit del LN = alto ( Classe D3 ) e 2 bit del LN = alto allora cmd90 --> In uso
    SSE --> In uso

    Esempio Lenbody = 0x00 :
    --> D0 36 00 00 xx
    la card risponde con :
    <-- 90 ( 00 ) (04) 02 bb1...............................bbxx
    <-- 90 00
    ( 00 ) LenBody a 0x00,quindi nessun paccheto crittato
    ( 04 ) Indexkey.Notare mancante bit del HighNibble.
    Anche se abbiamo chiesto un D0 36 , la CARD ( sicuramente nella ROM ) sa che dovrebbe essere una D1 36.

    Esempio Lenbody <> 0x00 :
    --> D1 40 00 80 5E
    <-- 40
    --> 00 7F 0A ( 01 9F 34 31 67 38 B6 2E ) 00 00 ( 90 ) ( 4F ) ( C0 ) 02
    bb1............................................... .bbx
    <-- 9020
    dove :
    ( 90 ) -- Commando selezione key / Pacchetto Processo Crittatura
    ( 4F ) -- Lunghezza Pacchetto x P2 Card Generation
    ( C0 ) -- Bitmapkey ( vedere Struttura delle chiavi --> BitmapKey )
    ( 02 ) -- Card Generation ( 02 = P2 / 03 = P3 / 04 = P4 (bit 6 set -> plaintext packet ) )

    In questo caso al cmd90 segue un (4F) = 79 byte di paccheto crittato ( meno 0x002 del Card Generation --> 0x04F - 0x002 = 79 - 2 = 77 byte = 0x04D ).
    Il HighNibble del byte indexkey ( 0xC0 ) segue l'algo secondo punto 2).
    da notare che hanno lasciato la CW in chiaro prima del cmd90 ( 01 9F 34 31 67 38 B6 2E )


    Struttura dei Nani(commandi) nel NDZ

    I Nano(commandi) e Nano(indicatori) sono presenti nelle INS :
    1) ECM => Entitlemet Control Message ( INS Controllo Abbonamento )
    2) EMM => Entitlemet Mangement Message ( INS Gestione Abbonamento )
    3) DRQ => DataReQuest ( INS Richiesta Informazione )
    4) PEMM => PPV Entitlemet Mangement Message ( INS Gestione PayPerView
    dell'Abbonamento )
    I Nano(commandi) e Nani(indicatori) possono essere a lunghezza fissa opp a lunghezza variabile. Possiamo quindi avere i seguenti casi :

    Nano(commandi) o Nano(indicatori) a Len fissa ( Nf ) :
    Nf x1 .......... xn = Nf nano(commando) che esegue una routine o sub-routine .
    Seguono n byte ( valore fisso ) di dati.

    Nano(commandi) o Nano(indicatori) a Len variabile ( Nv_Nl ) :
    Nv_Nl x1 .......... xn = Nv nano(commando) che esegue una routine o sub-routine .
    Nl = dec( n ) => seguono n byte ( valore variabili ) di dati .

    Nf = Nano(commandi) o Nano(indicatori) a len fissa
    n = Valore dei byte che seguono al Nano(commando) o Nano(indicatoro) a len fissa
    Nv = Nano(commandi) o Nano(indicatori) a len variabile
    Nl = Valore dei byte che seguono al Nano(commando) o Nano(indicatoro) a len variabile

    A Len Fissa
    01 [04] - Setta Data&Time.
    02 [01] - Setta RatingByte.Solo ECM ( * )
    03 [03] - Check pacchetto tiers INS 40
    05 [20] - Nella INS 74 / P1 = 05,il byte 28 indica che la CARD &egrave; attiva ( 0x01 ) opp no ( 0x00 )
    09 [03] - initialise ASIC with specified key, flushes the command buffer ( no signature stay )
    10 [02] - Counter
    17 [04] - Nano(indicatore) Data&Time INS 74.
    19 [01] - Setta Codice Regionale
    1E [08] - Setta Codice Postale
    1D [08] - Nano(indicatore) Codice Postale INS 74
    24 [04] - Nano(indicatore) tiers presenti nella posizione secondo P1.Solo INS 76.
    24 [05] - Nano(indicatore) Data visione e status ( visto / non visto ).Solo INS 74.

    24 [00] - Flag chiusura.
    25 [02] - Flag chiusura / apertura Cancellazione Tier.
    2B [03] - Scrive 3 byte.Possono essere letti con INS 36
    2D[04] - Setta attivazione Date&Time
    30 [00] - Flag apertura
    31 [03] - Check il Numero Seriale o UniqueAddress
    32 [03] - Check il SharedAddress ( INS inviata al gruppo )
    3D [02] - Scrive il limite di spessa per la PPV spending limit, attivazione della CARD e
    FuseByte a 05.
    41 [04] - Scrive / Aggiorna Tier.
    42 [02] - Cancella Tier.
    48 [02] - Abilita alla preview a evento iniziato.
    4D [0B] - Indica qualle evento si sta vedendo,data d'acquisto,tipo di credito,costo,etc...
    4E [04] - Scrive 4 byte.
    6D [09] - Invia tramite EMM il numero tel. a cui si deve collegare il modem a fine credito.
    C0 [00] - Chiude pacchetto Tier.
    DE [28] - ??
    E9 [04] - Nano(indicatore) numero di tiers e scadenza.
    F3 [04] - Nano(indicatore) valore in esadecimale dell'IRD.
    5E [05] - Contattore dal momento di attivazione della CARD.????
    DF [04] - Nano(indicatore) della data in cui la CARD si collegher&agrave; al server.
    E2 [13] - Nano(indicatore) del PIN / PCB e se il Limite di spessa &egrave; attivo o meno,e quanto.
    EF [02] - Nano(indicatore) => la CARD &egrave; attiva ( 0x01 ) / non attiva ( 0x00 )
    F8 [24] - Nano(indicatore) dello slot in uso,del EventID in PPV,Data d'acquisto del EventID,
    Status della visione,tipo di credito,eventuale data e ora della preview.
    FA [08] - Nano(indicatore) di 8 bytes.??
    FD [11] - Nano(indicatore) numero dei provider,tipo d'acquisto,numero di record PPV,costo e
    credito disponibile.

    A Len Variabili
    33 24 - Check il SharedAddress ( INS inviata al gruppo ),processa il bitmap.
    38 09 - Check Codice Postale
    38 05 - Setta 5 byte
    38 03 - Setta 3 byte
    4D 0E - Setta alcuni dati, PPV related, both in PPV ECM e EMM
    67 08 - Indica che segue la firma
    6D 09 - Setta alcuni dati.Possono essere letti con INS 78
    6E 07 - Setta alcuni dati.
    72 02 - Setta alcuni dati.
    75 0F - Scrive alcuni dati Codice Regionale Locale.Possono essere letti con INS 58
    75 13 - Setta alcuni dati.related to postcode and region code
    7E 12 - Indica che segue la Control - Word.
    7F 12 - Indica che segue la Control - Word ( 2 ).Non in uso in Italia.
    CB 02 - Setta 2 byte
    (*)
    01 => 0000 000|1| => criptato standard
    02 => 0000 00|1|0 => canale ppv, evento iniziato non / aquistabile
    05 => 0000 0|1|0|1| => canale ppv, evento iniziato aquistabile.Preview terminata.
    81 => |1|000 000|1| => canale ppv, evento non iniziato / aquistabile.
    82 => |1|000 00|1|0 => canale ppv, evento iniziato / aquistabile.Preview in esecuzione.

    Struttura delle chiavi del NDZ

    Nel Sistema NDS esistono 3 tipi di chiavi:

    Public Key: per tutte le card. La Signature &egrave; valida per tutti i gruppi.
    Group Key: per un gruppo di 256 cards ( da 0x00 --> 0xFF / 00 --> 255 ) . La Signature &egrave; valida per tutto il gruppo.
    Private Key: per ogni card singola. La Signature &egrave; i valida solo per la card a cui appartiene la key privata.

    Le chiavi :
    Key 00 la primary public key
    Key 02 la primary group key ( non in uso attualmente )
    Key 04 la primary private key


    Bitmapkey :
    ( Bit del LowNibble )
    000|0| = 0x00 = Primary Public Key
    00|1|0 = 0x02 = Primary Group Key ( non in uso attualmente )
    0|1|00 = 0x04 = Primary Private Key

    ( Bit del HighNibble )
    00|00| = ??

    0|0|00 = settato = usa l'ASIC / non settato = non usa l'ASIC
    |0|000 - settato = Pacchetto Ins40/Ins46 / non settato = Pacchetto Ins42.
    Il 7 ed 8 bit vengono utilizati come nelle card HU.

    Esempio:
    INS D1 40 -- Bitmapkey = 0xC0 => |1|1|00 000|0|
    Il 8 bit &egrave; alzato ( HighNibble 0xCx = |1|100 => pacchetto ins 40/46 ) + 7 bit alzato ( 1|1|00 => uso dell'ASIC ).
    INS D1 42 -- Bitmapkey = 0x40 => 0|1|00 000|0|
    Il 8 bit &egrave; basso (HighNibble 0x4x = |0|100 => pacchetto ins 42 ) + 7 bit alzato ( 0|1|00 => uso dell'ASIC ).
    Status-Byte SW1 / SW2 ( Risposta della Carta )

    La forma generica degli Status Bytes &egrave; : 9X RR (SW1 / SW2)

    9X (SW1) &egrave; il primo dei due Status Bytes. Normalmente il valore &egrave; 90. Questo Status Byte normalmente indica che non ci sono state anomalie durante l'esecuzione del comando.Questo per&ograve; non significa che esso abbia avuto successo.In taluni casi, se durante l'esecuzione delle ins determinati nanocommandi presenti vengono eseguiti, il valore &egrave; 91.Nelle nuove smartcard NDZ2 viene osservato che dopo la esecuzione con modifica nello stato dei SW1 / SW2 con valore 91 A1 ( in genere con INS D1 42 ) le INS seguenti presentano uno status 91 x0.Solo un passaggio della INS D1 4C ( patch ??? ) ripristina lo statusbyte.
    Esempio :
    D1 42 00 00 20 ---> [91A1]
    D1 40 00 80 5E ---> [91A0]
    D3 54 00 00 3C ---> [91A0]
    D1 58 00 00 4A ---> [91A0]
    D1 4C 00 00 09 ---> [90A0] ---> ( Punto ripristino )
    D1 40 00 80 5E ---> [9020]
    D3 54 00 00 3C ---> [9020]

    Come si vede,questa situazione fa pensare a un pericoloso "galleggiare" del
    puntatore dello Stack.La CAM "osserva" l'erorre i fa riprendere la posizione allo Stack.
    Nello Status Byte SW2 solo tre bit sono significativi (si contano da destra verso sinistra):

    '''''''''''''''''''''''''''''''''''''''''''''''''' ''''''''''''''''''''''''''''''
    Bit 0 = 1 - Indica che durante l' esecuzione del comando, una modifica

    SW1 = 90 - Eeprom da (indirizzo) a (indirizzo) non modificato / SW2 = x1 - Eeprom Update
    SW1 = 91 - Eeprom da (indirizzo) a (indirizzo) modificato / SW2 = x1 - Eeprom Update

    ************************************************** ******************************


    1001000|0| 000|0|000|0| 90 00 no error/no update allocation/no update Eeprom/bit IRD no setted
    1001000|0| 000|0|000|1| 90 01 no error/no update allocation/update Eeprom/bit IRD no setted
    1001000|0| 000|0|001|0| 90 02 no error/? /no update allocation/no update Eeprom/bit IRD no setted
    1001000|0| 000|0|010|0| 90 04 no error/? /no update allocation/no update Eeprom/bit IRD no setted
    1001000|0| 000|0|100|0| 90 08 no error/? /no update allocation/no update Eeprom/bit IRD no setted
    1001000|0| 000|1|000|0| 90 10 error
    1001000|0| 001|0|000|0| 90 20 no error/no update allocation/no update Eeprom/bit IRD setted
    1001000|0| 001|0|000|1| 90 21 no error/no update allocation /update Eeprom/bit IRD setted
    1001000|0| 001|0|010|0| 90 24 no error/no update allocation /no update Eeprom/bit IRD setted
    1001000|0| 001|0|010|1| 90 25 no error/no update allocation /update Eeprom/bit IRD setted
    1001000|0| 010|0|000|0| 90 40 no error/no update allocation /no update Eeprom/bit IRD no setted
    / class error (D1 non abilitata)
    1001000|0| 100|0|000|0| 90 80 no error/no update allocation /no update Eeprom/bit IRD no setted
    1001000|0| 100|0|000|1| 90 81 no error/no update allocation /update Eeprom/bit IRD no setted
    1001000|0| 101|0|000|0| 90 A0 no error/no update allocation /no update Eeprom/bit IRD setted
    1001000|0| 101|0|000|1| 90 A1 no error/no update allocation /update Eeprom/bit IRD setted
    1001000|1| 000|0|000|0| 91 00 no error/update allocation /no update Eeprom/bit IRD no setted
    1001000|1| 000|0|000|1| 91 01 no error/update allocation /update Eeprom/bit IRD no setted
    1001000|1| 001|0|000|0| 91 20 no error/update allocation /no update Eeprom/bit IRD setted
    1001000|1| 001|0|000|1| 91 21 no error/update allocation /update Eeprom/bit IRD setted
    1001000|1| 100|0|000|0| 91 80 no error/update allocation /no update Eeprom/bit IRD no setted
    1001000|1| 100|0|000|1| 91 81 no error/update allocation /update Eeprom/bit IRD no setted
    1001000|1| 101|0|000|0| 91 A0 no error/update allocation /no update Eeprom/bit IRD setted
    1001000|1| 101|0|000|1| 91 A1 no error/update allocation /no update Eeprom/bit IRD setted


    SW2 = 1 bit modifica Eeprom
    SW2 = 5 bit error ( 5 bit alzato )
    SW2 = 7 bit class error ( 7 bit alzato )

    SW1 = 1 bit modifica allocation 0xZZZZ

    Comando 0x02 � Richiesta Tipo Card e ROM Version

    Parametri

    P1
    Non Significativo
    P2
    Non Significativo
    Len
    8

    Comando : D0 02 00 00 08
    Risposta : 49 54 54 56 02 00 4C 45 ( 90 20 )

    49 54 54 56 Card. Type
    02 00 4C 45 ROM Version

    Questo comando fornisce il Tipo di Card e la versione della ROM.


    Bytes
    Descrizione

    1-4
    Tipo Card

    48 55 54 56 HUTV
    53 59 41 56 SYAV
    52 53 54 56 RSTV
    49 54 54 56 ITTV



    5-8
    ROM Ver.

    02 00 48 33 Versione 2.0 � H3
    01 01 00 00 Versione 1.1
    01 00 48 43 Versione 1.0 � HC
    02 00 4C 45 Versione 2.0 � LE

    Comando 0x04

    Comando : D0 04 00 00 01 yy
    Risposta : ( 90 00 )

    Setta o scrive un byte in una locazione di memoria in EEPROM col valore inviato,come nelle H-Card. Pu&ograve; essere riletto con il Comando D0 06.

    Comando 0x06

    Parametri

    P1
    Non Significativo
    P2
    Non Significativo
    Len
    1

    Comando: D0 06 00 00 01
    Risposta : yy ( 90 20 )

    Legge un byte da una locazione della memoria EEPROM. Questo byte pu&ograve; essere settato dal Comando 48 04.




    Comando 0x0E

    Parametri

    P1
    Significativo vedere (*)
    P2
    Significativo vedere (*)
    Len
    Vedere (*)

    Comando: D0 0E P1 P2 LL
    Risposta : n1 ..................................... nlen ( 90 20 )

    L'ins 0E &egrave; legata alla PPV e all'ins 46, infatti appare solo dopo aver ricevuto una ins 46.
    Tra l'altro varia in relazione al contenuto dell'ins 46 che la precede e la determina.

    Se non &egrave; preceduta dalla ins 46, restituisce tutti 00 per valori di P2 pari, per valori di P2 dispari restituisce 09 se P2<80, restituisce 01 se P2>79.

    Sono significativi sia il P1 che il P2.

    I valori di P1 fin qui osservati vanno da 00 a 04.
    Da 01 a 03 vengono indicati i tiers dell'evento, con 04 invece vengono indicati i dati d'acquisto, con 00 non so (ma sembra che le risposte siano sempre uguali).

    I valori di P2 fin qui osservati presentano valori di low nibble=1,2; valori di high nibble=0,8.
    Il valore dell'high nibble 8, indica la len del comando successivo (che naturalmente deve presentare lo stesso low nibble e lo stesso P1).
    Il valore dell'high nibble 0, indica il contenuto della risposta del comando.
    Il valore del low nibble 1 si osserva soltanto accoppiato a P1=00, invece il valore 2 si osserva con tutti i valori di P1.

    Es:D1 0E 00 81 01 (0E) 06 [90 20]
    D1 0E 00 01 06 (0E) 00 05 05 05 05 00 [90 20]


    Si osserva che vengono inviate in serie queste ins 0E per ricevere informazioni sull'evento PPV:
    D1 0E 00 81 01 (0E) 06 [90 20]
    D1 0E 00 01 06 (0E) 00 05 05 05 05 00 [90 20]

    D1 0E 00 82 01 (0E) 0A [90 20]
    D1 0E 00 02 0A (0E) 00 05 05 1C 05 02 45 00 00 00 [90 20]

    D1 0E 01 82 01 (0E) 0A [90 20]
    D1 0E 01 02 0A (0E) 00 05 05 1C 05 00 03 00 00 00 [90 20]

    D1 0E 02 82 01 (0E) 0A [90 20]
    D1 0E 02 02 0A (0E) 00 05 05 1C 05 04 4F 00 00 00 [90 20]

    D1 0E 03 82 01 (0E) 0A [90 20]
    D1 0E 03 02 0A (0E) 00 05 05 1C 05 01 00 00 00 00 [90 20]

    D1 0E 04 82 01 (0E) 1E [90 20]
    D1 0E 04 02 1E (0E) 00 00 05 08 07 C4 9D 00 65 5E 05 80 09 04 80 02
    00 00 0A 06 00 00 00 01 F4 02 29 02 00 80 [90 20]


    Volendo fare un parsing:
    D1 0E 02 02 0A (0E)
    00 ??
    05 05 ??

    1C 05 ??
    04 4F 00 tier
    00 00 ??
    90 20 sw

    D1 0E 04 02 1E (0E)
    00 00 05 08 07 ??
    C4 9D PPV ev.ID
    00 65 tipo acquisto
    5E 05 mese e giorno dell�acquisto+1
    80 09 04 80 02 00 00 0A 06 00 00 00 ??
    01 F4 costo evento
    02 29 02 00 ??
    80 ??
    [90 20]

    Queste ins. vengono intervallate da ins. 46 ( che in questa fase dell'info sull'acquisto sono sempre uguali), e da ins. 74 05.



    Parametri

    P1
    Non Significativo
    P2
    Non Significativo
    Len
    8

    Comando: D0 12 00 00 08
    Risposta : 03 13 38 11 01 15 0C 01 ( 90 20 )

    0x03 ----> versione del CMS
    0x10 / 0x0F / 0x59-> Batch number
    0x02 ---> Wafer number
    0x0C / 0x0A ----> Die position
    0x02 ---> ROM version ( letto anche con INS 0x02 )


    Comando 0x1E

    Parametri

    P1
    Significativo
    P2
    Significativo
    Len
    Non Significativo

    Comando: D0 1E P1 P2 LEN
    Risposta : n1 ..................................... nlen ( 90 20 )

    ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,


    L'ins 1E &egrave; legata agli acquisti PPV, quindi segue sempre l'ins 46 che effettivamente scrive sulla card i valori dell'evento acquistato.

    In una card attiva senza acquisti PPV il valore di P1 sembra ininfluente.
    Il Valore di P2 fa variare la risposta:
    con low nibble di P2=2,3,6,7,A,B,E,F, d&agrave; 27 07 01 00 00 02 00 20 00 90 00;
    con low nibble di P2=0,1,4,5,8,9,C,D, d&agrave; 27 07 01 00 00 02 00 00 00 90 00.
    Come si vede varia l'8byte da 00 a 20. Il valore dell'high nibble di P2 &egrave; indifferente.
    Variando la classe non si notano differenze.

    Ma, come dicevamo, l'ins 1E indica (non scrive nulla, come conferma lo sw) lo stato della transazione PPV in corso, quindi va analizzata in relazione all'ins 46 di acquisto.

    I valori di P1 e P2 sono variabili, ma finora ho notato che sono uguali ai corrispondenti P1 e P2 dell'ins 46 che precede immediatamente l'ins 1E.
    Quindi &egrave; ipotizzabile che questi valori utilizzino lo stesso bitmap dei parametri dell'ins 46 (vedi ins 46).
    La len varia in relazione alle informazioni contenute.

    Ad esempio:
    - D1 46 20 02 3A (46) 00 00 FF 08 04 00 00 00 90 30 C0 02 3F 0E 85 A4
    9E 2C F4 D5 5B F6 49 A5 3E 91 C2 57 E1 3D EB C2
    0B 92 A3 8C A5 35 17 1B 3F 71 98 11 CA CC 25 48
    0E 84 3C B9 F7 A9 00 34 4A FE [91 21]
    - D1 1E 20 02 09 (1E) 27 07 00 00 70 02 00 00 00 [91 20]
    L'ins 46 effettua la scrittura del PPv record sulla card (vedi sw), l'ins 1E che segue presenta gli stessi valori di P1 e P2, ma non capisco il significato del corpo del comando.


    - D1 46 00 04 03 (46) 00 C4 9D [91 21]

    - D1 1E 00 04 09 (1E) 27 07 00 00 72 02 00 00 00 [91 20]

    In questo caso l'ins 46 cancella il PPV event ID precedentemente scritto (quando non si conferma l'acquisto), l'ins 1E che segue presenta il 5 byte diverso (da 70 a 72).


    Dal NDS2 ITALIAN COMMAND v1.1 / autore Fabar83
    ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,






    Comando 0x2E

    Parametri

    P1
    Significativo
    P2
    Non Significativo
    Len
    Vedere (*)

    Comando: D0 2E P1 P2 LEN DataPacket
    Risposta : ( 90 21 )

    Controllo visione PCB ( Parental Control Byte ) :
    D0 2E 01 00 04 80 00 00 pp ( Scrive il PCB con valore pp )
    0x00 = Tutti bloccatti
    0x02 = Presenza Adulti + 12 + 14 +18
    0x22 = Presenza Adulti + 12 + 14
    0x32 = Presenza Adulti + 12
    0x3A = Consigliata Presenza Adulto
    0x3C = Tutti programmi bloccati
    0x3E = Tutti programmi sbloccati

    Limite di spessa :
    D0 2E 02 00 03 00 sp1 sp2 ( Scrive il LimiteSpessa con valore sp1 sp2 )
    0x00 = Euro 0
    0x03 E8 = Euro 10
    0x07 D0 = Euro 20
    0xFF FF = Limite di spessa non abilitato ( OFF )

    PIN ( Numero accesso PCB ) :
    D0 2E 04 00 04 00 00 yy1 yy2 ( Scrive il PIN con valore yy1 yy2 )

    Totale PPV ( La CAM scrive nello slot PPV(x) della CARD il valore totale della spessa ) :
    D0 2E 05 00 04 vv vv vv vv

    Comando 0x32

    Parametri

    P1
    Non Significativo
    P2
    Non Significativo
    Len
    1

    Comando: D0 32 00 00 01 xx
    Risposta : ( 90 21 )

    Scrive un byte in EEPROM .




    Comando 0x36

    Parametri

    P1
    Vedere (*)
    P2
    Non Significativo
    Len
    Vedere (*)

    Comando: D0 36 P1 00 LEN
    Risposta : n1 ................. nx ( 90 20 )

    Il P1 viene stabilito a secondo se l'informazione pu&ograve; essere contenuta dentro la Len massima ammissibile ( cio&egrave; 0xFF = 256 byte ).In questo caso la restante informazione verr&agrave; richiesta con P1 = P1 + 1 .
    Esempio :
    --> D0 36 00 00 E4
    <-- 36
    <-- 90 00 04 02 00 UA UA UA 01 00 00 60 08 4E 6D DE 28 03 E8 03 E9 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 A8 24 64 14 55 C5 45 64 5D 38 A4 08 17 F5 9A 6B E9 04 04 00 61 3A FD 11 01 00 65 00 05 00 01 13 89 09 C5 00 00 00 00 00 00 F3 04 54 63 33 DF 60 0D 00 80 EF 00 00 E2 13 00 00 00 00 3E 2E 00 00 00 00 00 FF FF FF FF 00 00 04 4C FA C2 DA 2F 42 C5 C3 8F EC F8 24 00 CA DA 5E 1C BF 7D 01 F4 02 0C 01 80 5E 1B 8B D5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5E 1C 00 65 20 F8 24 01 C6 5F 5F 02 BF 7D 02 58 02 04 01 80 5F 01 BB 13 5F 01 BD 8D 00 00 00 00 00 00 00 00 00 00 5F 02 00 65 20 5E 05 00 4F 00 00 00 F6 02 00 00 00 00 00 00 00 00 67 08 F1 F1 81 0E 3E 9D 49 76
    <-- 90 00 (36,0000000000582millisecondi)
    ( no error / no update alocation / no update Eeprom / bit IRD no setted )

    90 00 04 02 ( vedere Classi NDZ2 ) ( in questo caso cmd90 abilitato / zero pacchetto crittato / key 04 / Card P2 )
    00 UA UA UA ( Numero seriale o UniqueAddress )
    01 ( 0x01 nanoindicatore Data&Time. nano lunghezza fissa )
    00 00 ( padding )
    60 08 4E 6D ( Data&Time )
    DE 28 ( 0x DE nanoindicatore . nano lunghezza secondo 0x28 = 40,quindi seguono 28 byte per questo nano

    03 E8 03 E9 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 A8 24 64 14 55 C5 45 64 5D 38 A4 08 17 F5 9A 6B ( In rosso 16 byte variabili ad ogni reset )
    E9 04 ( 0xE9 nanoindicatore Tiers&Data&Time . nano lunghezza secondo 0x04 = 4, quindi seguono 4 byte per
    questo nano)
    04 00 ( 0x04 = 4 tiers presenti )
    5D 0F ( Data scadenza 0x5D0F = 03/02/2005 )
    FD 11 ( 0xFD nanoindicatore . nano lunghezza secondo 0x11 = 17, quindi seguono 17 byte per questo nano)
    01 00 65 00 05 00 01 13 89 09 C5 00 00 00 00 00 00 ( * )
    F3 ( 0xF3 nanoindicatore Numero IRD. nano lunghezza fissa )
    IRD IRD IRD IRD Numero IRD in Esadecimale
    DF ( 0xDF nanoindicatore Data. nano lunghezza fissa )
    60 0D ( Data )
    00 80 ( ???? )
    EF ( 0xEF nanoindicatore StatusCard. nano lunghezza fissa )
    00 00 ( 0x00 = attiva / 0x01 = non attiva )
    E2 13 ( 0xE2 nanoindicatore . nano lunghezza secondo 0x13 = 19, quindi seguono 19 byte per questo nano)
    00 00 00 00 3E 2E 00 00 00 00 00 FF FF FF FF 00 00 04 4C
    FA ( 0xFA nanoindicatore . nano lunghezza fissa )
    C2 DA 2F 42 C5 C3 8F EC ( dicono signa,ma per me &egrave; di uso ignoto ????????????? )

    F8 24 ( 0xF8 nanoindicatore PPV . nano lunghezza secondo 0x24 = 36, quindi seguono 36 byte per questo nano)
    00 CA DA 5E 1C BF 7D 01 F4 02 0C 01 80 5E 1B 8B D5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5E 1C 00 65
    F8 24 ( 0xF8 nanoindicatore PPV . nano lunghezza secondo 0x24 = 36, quindi seguono 36 byte per questo nano)
    01 C6 5F 5F 02 BF 7D 02 58 02 04 01 80 5F 01 BB 13 5F 01 BD 8D 00 00 00 00 00 00 00 00 00 00 5F 02 00 65 20
    (**)

    5E 05 ( 0x5E nanoindicatore . nano lunghezza secondo 0x05 = 5, quindi seguono 5 byte per questo nano)
    00 4F 00 00 00 ( Contatore 0x01 al giorno => 0x4F = 79 giorni ??????? )
    F6 02 ( 0xF6 nanoindicatore . nano lunghezza secondo 0x02 = 2, quindi seguono 2 byte per questo nano)
    00 00
    00 00 00 00 00 00 ( padding )
    67 08 ( 0x67 nanoindicatore Signa . nano lunghezza secondo 0x08 = 8, quindi seguono 8 byte per questo nano)
    8 byte ( Signa )

    Appendice

    (*)
    Dove :
    01 Numero di provider presenti
    00 65 Tipo di credito
    00 05 Numero di record
    00 01 Costo evento PPV
    13 89 Credito totale ( 50 � )
    09 C5 Uguale alla meta del credito ( ???? )
    00 00 00 00 00 00 ( padding )

    ( ** ) F8 24 => Presente dopo uno o vari acquisti eventi PPV
    Dove :
    00 Slot
    CA DA EventID
    5E 1C Data acquisto
    BF 7D
    01 F4 Costo del evento ( 5 � )
    02 Status visione ( 00 : non visto / 01 : visto / 02 : non confermato l'acquisto )
    0C 01 80
    5E 1B 8B D5 Data&Time

    00 00 00 00 00 00 00 00 00 00 00 00 00
    5E 1C Data acquisto
    0065 Tipo di credito
    80 Status visione ( 80 : visto / 20 : non visto)







    Comando 0x38

    Parametri

    P1
    Significativo
    P2
    Non significativo
    Len
    Non significativo - Sempre uguale


    Comando : D0 38 P1 00 02
    Risposta : 0x02 ( 2 ) byte ( 90 20 )

    Se P1 = 80 => xx yy
    Dove :
    xx ---> Indica che ci sono 1 o piu' ins 36 per infoPPV.Indica anche il valore di P1 ( xx - 1 )
    dell'ins 36 attesa .
    yy ---> Indica la len della ins 36.
    Esempio :
    ----> D0 38 80 00 02
    <---- 38
    <---- 01 E4
    <---- 90 20
    0x01 ---> Una ins &egrave; attesa.L'ins attesa avr&agrave; P1 = 0x01 - 1 = 1 ( decimale ) - 1 = 0 .
    Quindi l'ins attesa = D1 36 00 00 E4 .
    0xE4 ---> Len della ins attesa.In questo caso 0xE4 = 228 byte al seguito.
    Si evince che con P1 = 0x80 risponde come l'ins 36 con P2 = 0x0C .

    Comando 0x40

    Parametri

    P1
    Significativo (1)
    P2
    Significativo
    Len
    Vedere (*)
    Comando: D1 40 P1 P2 LL PacketData
    Risposta : ( 90 20 )
    (1) Se PCB = OFF => P1 = 00 ; se PCB = ON => P1 = 20 / 40 / 80

    L�ins 0x40 ha nella sezione dati la Control - Word crittata di un canale del pacchetto.E' un ECM ( Entitlement Control Message ).
    La Len del ins &egrave; variabile e dipende , fra l'altro, da quanti Tier o pacchetti ( Channel Bundle ) sono presenti nella CARD.Il Tier ( Channel Bundle ) identifica univocamente un pacchetto. Tale Tier ha la forma di due Byte .
    Dovviamo sapere che la Control-Word crittata , che ritorna decrittata col comando 0x54 , sar&agrave; decrittata dalla CARD solo se la zona dati &egrave; completa e "integra" ( se contiene la signatura ed i / il Channel Bundle ) .

    La decrittatura della Control-Word comincia subito dopo il controllo della signatura e del controllo del Channel Bundle o Tier ( compressa la Data scadenza ) con la key di richiamo ( in questo caso la 0x00 ) + il Data&Time con un complesso algoritmo.

    NDZ2
    ---> D1 40 00 80 5E
    <--- 40
    ---> 00 7F 0A CF 1B 7D 97 58 4E 0D E2 00 00 90 4F C0 02 1C CE 26 1A 27 48 C8 41 5E 14 AF 3B A3 E0 C3 89 18 C5 7F 03
    CE 0D A9 23 33 AE 7A 2B C0 B1 6B A1 B3 7D 4D A9 E4 5D B6 6F BF BC 89 69 43 5A 19 42 5C 50 FB 38 C5 A6 5D 50
    E8 F0 10 C2 A0 BC 90 7D 96 8C F6 B0 01 F6 15 CE 01 26 E6 01
    <--- 90 20
    Dove il DataPacket :
    00
    7F 0A ( 0x7F nanoindicatoreCW . nano lunghezza secondo 0x0A = 10, quindi seguono 10 byte per questo nano)
    CF 1B 7D 97 58 4E 0D E2 ( CrittoWord )
    00 00 ( padding per len nano )
    90 ( CMD90.segue pacchetto )
    4F ( Len pacchetto crittato - 2 byte / 0x4F = 79,seguono 79 byte.meno 2 byte ( byte BitmapKey + un byte CardGeneration) )
    C0 ( BitmapKey )
    02 ( CardGeneration )
    1C CE .................................................. .......... E6 01 ( Corpo dati ) .

    Attualmente il sistema di crittatura non ci permette "spulciare" i nani e commandi contenuti nelle nuove ECM.Assumendo che sia stato mantenutto il corpo nanocommandi per questa INS vedremmo una INS ECM del NDZ1 :
    ---> 48 40 60 80 66
    <--- 40
    ---> 00 7E 12 00 00 00 00 00 00 00 00 C3 C4 9B 4E 66 75 98 97 00 00 09 10 10 00 01 4E 0E 00 77 02 00 03 00 42 00 03 00 43 00
    03 00 01 00 03 00 09 00 03 00 0A 00 03 02 30 00 03 01 00 00 03 01 00 00 03 01 00 00 03 01 00 00 03 01 00 00 03 01 00 00 03
    01 00 00 03 01 00 00 03 01 00 00 67 08 2D FA 77 37 C7 A8 F8 19
    <--- 90 20
    Dove il DataPacket :
    00
    7E 12 ( 0x7F nanoindicatoreCW . nano lunghezza secondo 0x12 = 18, quindi seguono 18 byte per questo nano)
    00 00 00 00 00 00 00 00 ( padding per len nano )

    C3 C4 9B 4E 66 75 98 97 ( Control - Word crittata )
    00 00 ( padding per len nano )
    09 10 10 ( Key Select )
    00 ( padding )
    01 ( 0x01 nanoindicatore Data&Time . nano lunghezza fissa,seguono 4 byte )
    4E 0E 00 77 ( Data&Time )
    02 01 ( Rating Level )
    03 00 42 00 .................................................. ... 03 01 00 00 ( Control Packet Entitlement )
    67 08 ( 0x67 nanoindicatore Signa . nano lunghezza secondo 0x08 = 8, quindi seguono 8 byte per questo nano)
    2D FA 77 37 C7 A8 F8 19 ( Signa )

    Segue una D3 54 00 00 3C per invio della Control - Word decrittata alla CAM

    Comando 0x42

    Parametri

    P1
    Significativo
    P2
    Significativo
    Len
    Significativo � La LEN cambia secondo i Nano dentro il DataPacket


    Comando: D1 42 P1 P2 LEN PacketData
    Risposta : ( 9x x1 )

    L'abbonamento viene gestito con l'ins 0x42.Con quest'ins si possono gestire la fine di un abbonamento o l'espansione, l'aggiornamento delle data di scadenza,etc...
    E' un EMM ( Entitlement Management Message ).
    Pu&ograve; essere indirizzata a una singola CARD ( attraverso la UniqueAddress - Indirizzo univoco o Card serial number).

    A una singola CARD di un gruppo ( attraverso la SharedAddres - Indirizzo condiviso o Card Group ) impiegando lo Shared Address ed il CUSTOMWORDPOINT ( CWP ) Byte.
    Lo SharedAddress ha un Bitmap di 256 bit ( 32 Bytes * 8 = 256).La posizione del byte del CWP e i bit in esso contenuti determinano l'indirizazione o meno di quella ins alla CARD in questione.
    UniqueAddress = xx xx xx 8D
    SharedAddress = xx xx xx
    CWP = 8D

    Posizione del byte = 0x8D / 8 = 11 => a cominciare dal primo byte del Bitmap la posizione &egrave; la 11.
    Il bit ( Se alzato l'ins &egrave; indirizatta a quella CARD ) &egrave; :
    Bit : 8 * 11 = 0x88 => 0x8D - 0x88 = 0x05 = 5 bit contando da Dx a Sx
    Se il 5 bit &egrave; = 1 => l'ins &egrave; indirizatta a la CARD
    Se il 5 bit &egrave; = 0 => l'ins non &egrave; indirizatta a la CARD
    Attualmente non in uso.

    Header :
    D1 42 00 00 LL
    DataPackect :
    90 ( LL- 2 ) xk 02 ( cmd90 - lenpacket - x = indice criptpacket / y = key in uso - CardGeneration )
    ( I valori sotto indicati sono teorici.Non ci &egrave; permesso,per adesso, lo "sgusciamento" )
    3x ( nano indicatore CWP Bitmap.len fissa,seguono 3 byte ) ( * )
    SN SN SN ( indica il SharedAddress ) ( * )
    n1 .................................... nx ( Zona del Bitmap del CWP ) ( * )
    41 ( nano indicatore Channel Entitlement.len fissa,seguono 4 byte )
    TT TT ( Tier o Channel Entitlement )
    DD DD ( nuova Data )
    C0 ( nano indicatore chiusura pacchetto tiers )
    25 ( nano indicatore cancellazione per questo CWP )
    42 ( nano indicatore Cancella Tiers per questo CWP.len fissa,seguono 2 byte )
    TT TT ( Tiers da cancellare )
    67 08 ( 0x67 nanoindicatore Signa . nano lunghezza secondo 0x08 = 8, quindi seguono 8 byte per questo nano)
    8 * 0xZZ ( Signa )

    L'INS 0x42 usano 3 tipi di key :
    1)Per tutte le CARD con chiave pubblica => 0x00 .
    2)Per un gruppo di CARD con chiave di gruppo => 0x02 ( al CWP bitmap ) ( non in uso )
    3)Per una singola CARD con chiave privata => 0x04 ( all'UniqueAddress ).
    (*) In caso di uso chiave 0x00 / 0x02




    Comando 0x46

    Parametri

    P1
    Significativo
    P2
    Significativo
    Len
    Significativo � La LEN cambia secondo i Nano dentro il DataPacket

    Comando: D0 46 P1 P2 LL PacketData
    Risposta : ( 90 20 )

    Header :
    D1 46 00 01 LL
    DataPackect :
    08 --> ?????
    90 ( LL- 2 ) xk 02 --> ( cmd90 - lenpacket - x = indice criptpacket / y = key in uso - CardGeneration )
    ( I valori sotto indicati sono teorici.Non ci &egrave; permesso,per adesso, lo "sgusciamento" )
    01 XX XX YY YY --> nano 01 ( Data&Time )
    02 85 --> nano 02
    48 02 05 --> nano 48 ( Abilitazione alla PPV )
    03 TT TT 00 --> nano 03 ( PacketTiers )
    *
    *
    *
    *
    4D_0B zz zz zz zz zz zz zz zz zz zz 00 --> nano 4D_0B ( StatusInfo PPV )
    67_08 8 byte * 0xZZ ( Signa )

    La Len del DataPacket &egrave; varia secondo i nanocommandi all'interno.E' un EMM utilizzato durante la negozizione di un EventID.Controlla tutto lo status del PPV.
    Bitmap P1
    0 | 0 | 0 | 0 | 0 | 0 | 0 | 0
    | | | | | | | |_ _ _ _ _ _
    | | | | | | |_ _ _ _ _ _ _ /
    | | | | | |_ _ _ _ _ _ _ _ / PPV slot number
    | | | | |_ _ _ _ _ _ _ _ _ /
    | | | |_ _ _ _ _ _ _ _ _ _ /
    | | |_ _ _ _ _ _ _ _ _ _ _ _ Se bit = basso allora confronta limite altrimenti no confronta
    | |_ _ _ _ _ _ _ _ _ _ _ _ _ _ Non in uso
    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Non in uso





    Bitmap P2
    0 | 0 | 0 | 0 | 0 | 0 | 0 | 0
    | | | | | | | |_ _ _ _ Se bit = basso allora confronta Tiers altrimenti no confronta
    | | | | | | |_ _ _ _ _ _ Se bit = basso allora non acquista altrimenti acquista
    | | | | | |_ _ _ _ _ _ _ Se bit = basso allora no cancella acquisto altrimenti cancella
    | | | | |_ _ _ _ _ _ _ _ _ Non in uso
    | | | |_ _ _ _ _ _ _ _ _ _ _ Se bit = basso allora permete ulteriori acquisti altrimenti no
    | | |_ _ _ _ _ _ _ _ _ _ _ _ Non in uso
    | |_ _ _ _ _ _ _ _ _ _ _ _ _ _ Non in uso
    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Non in uso


    Comando 0x4A

    Parametri

    P1
    Significativo
    P2
    Significativo
    Len
    Significativo � La LEN cambia secondo i Nano dentro il DataPacket


    Comando: D0 4A 15 01 01 01 ( indicatore seme )
    Risposta : ( 90 20 )

    L'IRD spedisce un indicatore di semi.La CARD genera un numero Random "R" che consegna all'IRD tramite all'ins info D0 5A. Viene sempre usato il solo seme 01.
    ( vedere caspitolo ZeroKnowLedge )




    Comando 0x4C

    Parametri

    P1
    Non Significativo
    P2
    Non Significativo
    Len
    Non Significativo


    Comando: D0 4C 00 00 09 Ird Ird Ird Ird 03 Tp Tp Tp 0x
    Risposta : ( 90 20 )

    Con questa ins la CAM invia il suo SerialNumber alla Card.Se non corrispondente con il SerialNumber scritto in Eeprom della CARD => 90 04.Se corrispondente => 90 20.Questo valore di SerialNumber viene scritto nella CARD al Booth di prima attivazione.
    Attualmente non in uso.

    Ird Ird Ird Ird = Valore del IRD in Hex
    03 = seguono 3 byte indicatore modello decoder
    Tp Tp Tp = Tipo di decoder in qui allogia l'IRD
    0x = Valore dello status FuseByte

    Dove : Tp Tp Tp
    00 00 05 = SkyBox PACE
    00 00 01 = Italtel

    00 09 16 = GoldBox Philips 6072
    00 00 03 = SkyBox Philips

    Bitmap 0x
    HighNibble LowNibble
    0 0 0 0 0 | 0 | 0 | 0
    |_ _ _ _ _ Se bit = basso allora FuseByte no modify
    Se bit = alto allora FuseByte modify


    Comando 0x4E

    Parametri

    P1
    Non Significativo
    P2
    Non Significativo
    Len
    Non Significativo


    Comando: D0 4E 00 00 05
    Risposta : 0x05 ( 5 ) byte ( 90 20 )

    La risposta cambia secondo le ins D1 42 precedenti .


    Comando 0x50

    Parametri

    P1
    Non Significativo
    P2
    Non Significativo
    Len
    Non Significativo


    Comando: D0 50 P1 P2 LL
    Risposta : LL byte ( 90 20 )


    Comando 0x54

    Parametri
    P1
    Non Significativo
    P2
    Non Significativo
    Len
    Non Significativo

    Comando: D3 54 00 00 3C
    Risposta : 0x3C ( 60 ) byte ( 90 20 )

    Viene eseguita immediatamente dopo la 0x40 ( se lo StatusByte &egrave; 90 20 ).
    La CARD invia alla CAM la Control - Word decrittata ( la Control - Word crittata &egrave; annidata nella ins 0x40 - nano 7F_xx ). Con la Control - Word decrittata la CAM decodifica il flusso MPEG-2 ( La Control - Word decrittata viene inviata al registro xx del Common Scrambling Algorithmus nella CAM ) .
    La Len della Control - Word decrittata ammonta sempre a 8 byte.P1 e P2 sono sempre 00.
    Esempio :
    Header
    D3 54 00 00 3C
    DataPackect
    ( I valori sotto indicati sono teorici.Non ci &egrave; permesso,per adesso, lo "sgusciamento" )
    YY YY YY YY YY YY YY YY 00 00
    00 00 00 01 00
    45 byte

    Dove :
    YY YY YY YY YY YY YY YY => la CW ( inviata dalla CAM tramite il ECM D1 40 )
    decrittata ----> DeCripted Control Words.
    00 00 => Padding della DCW
    00 00 => Padding ???
    00 => Control Byte FuseByte
    01 => Status del decript
    00 => Padding ???

    Status del decript rappresenta lo status del processo di Decript :

    Valore byte Descrizione
    0x00 ---------- Decript non eseguito.
    0x01 ---------- Decript eseguito con successo.
    0x03 ---------- Decript eseguito con successo.
    0x04 ---------- Decript non eseguito.



    Comando 0x58
    Parametri

    P1
    Non Significativo
    P2
    Non Significativo
    Len
    Non Significativo

    Comando: D0 58 00 00 4A
    Risposta : 0x4A ( 74 ) byte ( 90 20 )

    D0 58 00 00 4A
    DataPacket :
    15 48
    25 ---> FuseByte
    UU UU UU UU ---> Serial Number CARD
    03 ---> Significato ignoto
    72 FD 73 03 ---> Significato ignoto,cambiano ad ogni negoziazione CAM ---> CARD
    00 00 00 00 00 00 00 00 ---> Significato ignoto
    30 5A 2C ---> ByteRegister Client
    00 09 19 ---> Significato ignoto
    UU UU UU UU ---> Serial Number CARD
    FF FF FF FF ---> Significato ignoto
    Sh Sh Sh ---> SharedAddress
    00 FF FF FF ---> Significato ignoto
    00 00 00 00 00 00 00 00 ---> Significato ignoto
    00 08 00 00 00 01 ---> Significato ignoto
    49 54 41 ---> Codice Nazione o CountryCode ( Ascii --> ITA )
    00 00 ---> Vedere nano EF => INS36
    49 54 41 4C 49 41 20 20 ---> Codice Nazione o CountryCode ( Ascii --> ITALIA.. )
    60 0D ---> Vedere nano DF => INS36
    33 41 ---> Significato ignoto
    00 00 ---> Significato ignoto

    Bitmap FuseByte
    0 | 0 | 0 | 0 | 0 | 0 | 0 | 0
    | | | | | | | |_ _ _ _ Se bit = basso allora non attivo altrimenti attivo
    | | | | | | |_ _ _ _ _ _ Se bit = basso allora vetore di salto OFF altrimenti ON
    | | | | | |_ _ _ _ _ _ _ Se bit = basso allora vergine altrimenti no vergine
    | | | | |_ _ _ _ _ _ _ _ _ Se bit = basso allora no swap altrimenti swap
    | | | |_ _ _ _ _ _ _ _ _ _ _ Non in uso
    | | |_ _ _ _ _ _ _ _ _ _ _ _ Se bit = basso allora non married altrimenti married
    | |_ _ _ _ _ _ _ _ _ _ _ _ _ _ Non in uso
    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Non in uso




    Comando 0x5A
    Parametri

    P1
    Significativo
    P2
    Significativo
    Len
    Significativo - Dipende del valore di P1 e P2

    Comando: D0 5A P1 P2 LL
    Risposta : LL byte ( 90 20 )

    Se P1 = 15 and P2 = 01 allora LL = 0x10 = 16 byte.

    ------------------------------------NDZ2Faq-------------------------------------



    Altrimenti se P1 = 11 and P2 = 02 allora LL = 0x40 = 64 byte.

    La CAM con INS D0 4A e seme indicatore 01 chiede alla CARD una HashString da 96 bit + 4 byte di padding ( D0 5A 15 01 10 ) = R^2 mod N => N = P*Q ( Funzione di Eulero ) di 512 bit.
    P e Q sono due grandi numeri primi fra di loro.
    R &egrave; presente sia nella CAM che nella CARD ( ROM ). Nelle HUCard si trovano nell'indirizzo 11C3h - 1202h della ROM.
    La CAM con INS D0 4A e seme indicatore 01 chiede alla CARD una Plaintext da 504 bit + 1 byte di padding ( D0 5A 11 02 40 ) = R o R*S mod N ( dove S &egrave; un residuo quadratico )
    ( Vedere il ZeroKnowLedge )

    Comando 0x5C

    Parametri
    P1
    Non significativo
    P2
    Non significativo
    Len
    Non significativo

    Comando : D0 5C 00 00 04
    Risposta : 00 00 00 00 ( 90 20 )




    Comando 0x5E

    Parametri
    P1
    Non significativo
    P2
    Significativo
    Len
    Non significativo

    Comando : D0 5E 00 P2 LL
    Risposta : LL byte ( 90 20 )

    Se P2 = 0x0C => xx yy altrimenti => LL * 0x00 .
    Dove :
    xx ---> Indica che ci sono 1 o piu' ins 36 per infoPPV.Indica anche il valore di P1 ( xx - 1 )
    dell'ins 36 attesa .
    yy ---> Indica la len della ins 36.
    Esempio :
    ----> D0 5E 00 0C 02
    <---- 5E

    <---- 01 E4
    <---- 90 20
    0x01 ---> Una ins &egrave; attesa.L'ins attesa avr&agrave; P1 = 0x01 - 1 = 1 ( decimale ) - 1 = 0 .
    Quindi l'ins attesa = D1 36 00 00 E4 .
    0xE4 ---> Len della ins attesa.In questo caso 0xE4 = 228 byte al seguito.
    Si evince che con P2 = 0x0C risponde come l'ins 38 con P1 = 0x80 .




    Parametri
    P1
    ??
    P2
    ??
    Len
    ??

    Comando : D0 6A P1 P2 LL
    Risposta : LL byte ( 90 20 ) .???



    Comando 0x6C

    Parametri
    P1
    Vedere P2
    P2
    Significativo
    Len
    Variabile => P2

    Comando : D0 6C P1 P2 LL
    Risposta : LL byte ( 90 20 )

    Da risposta con P2: 01,11,21.
    LL con P2 =
    0x01 => 0x1C ( 28 byte ) .
    0x11 => 0x12 ( 18 byte ) .
    0x21 => 0x61 ( 97 byte ) .


    P2 = 0x01
    Risposta ( sulla mia CARD ) :
    6A 06 00 10 00 10 23 00 6B 08 00 00 00 08 00 00 00 01 6B 08 00 00 00 10 00 00 00 11
    Sempre uguale.P1 non significativo.

    P2 = 0x11
    P1 significativo se LowNibble :
    0 | 0 | 0 | 0 = 0x00
    0 | 0 | 1 | 0 = 0x02
    0 | 1 | 0 | 1 = 0x05
    Risponde con 6E 10 + 0x16 bytes diverse ad ogni riinvio.

    P2 = 0x21
    0 | 0 | 0 | 0
    | | | |_ _ _ _ _ Se bit = basso risposta Tipo I / Se bit = alto risposta Tipo II
    |_ |_ |_ _ _ _ _ _ Non significativi
    Risponde con 6F 60 + 0x60
    Risponde con LL byte a 0x00 dopo un riinvio della ins D0 6C P1 P2 61 senza Reset.
    Dove :
    0x6(x) ( NanoIndicatore range )
    0x(XX) ( Len del nano indicatore )

    Comando 0x70

    Parametri
    P1
    Significativo
    P2
    Significativo
    Len
    Significativo

    Comando : D0 70 P1 P2 25
    Risposta : 25 ( 37 ) byte ( 90 20 )

    Esempio :
    --> D0 70 02 80 01
    <-- 25
    <-- 90 20 (34,3999999997322millisecondi)
    ( no error / no update alocation / no update Eeprom / bit IRD setted )

    --> D0 70 02 00 25
    <-- 39 23 00 00 00 00 C0 41 00 00 00 00 00 00 00 00 00 00 00 00 20 00 00 00 00
    00 00 00 00 00 00 00 00 40 62 12 00
    <-- 90 20 (20,2999999994063millisecondi)
    ( no error / no update alocation / no update Eeprom / bit IRD setted )

    P2 = 7F and P1 = 0x00 ---> 0xFF risponde sempre :
    --> D0 70 01 7F 25
    <-- 70
    <-- 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00
    <-- 90 20 (34,375millisecondi)

    ( no error / no update alocation / no update Eeprom / bit IRD setted )
    Dove :
    C0 41 ??
    20 Byte null
    40 Indicatore Data scadenza
    62 12 Data scadenza tiers)


    Comando 0x72
    Parametri
    P1
    Significativo
    P2
    Non significativo
    Len
    Non significativo

    Comando : D0 72 P1 P2 23
    Risposta : 0x23 ( 35 ) byte ( 90 20 )

    P1 determina lo slot PPV.
    Legge dati del nano F8_24 della ins 36

    Esempio :
    --> D0 72 00 00 23
    <-- 72
    <-- 23 21 CA DA 5E 1C BF 7D 01 F4 02 0C 01 80 5E 1B 8B D5 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 5E 1C 20
    <-- 90 20 (35,9375 millisecondi)
    (no error/no update alocation/no update Eeprom/bit IRD setted)

    Dove:
    D0 72 0x 00 23 Header con P1 = 0x che legge Slot x
    23 Indicatore
    21 Len del indicatore
    CA DA EventId
    5E 1C Data acquisto
    BF 7D
    01 F4 Costo del evento ( 5� )
    02 Visione( 00 : non visto / 01 : visto / 02 : non confermato l'acquisto )
    0C 01 80
    5E 1B 8B D5 Data&Time
    00 00 00 00 00 00 00 Padding
    00 00 00 00 00 00 00 Padding
    5E 1C Data acquisto
    20 Byte = 00

    Comando 0x74

    Parametri
    P1
    Significativo
    P2
    Non significativo
    Len
    Significativo => P2 = 80

    Comando : D0 74 P1 00 LL
    Risposta : LL byte ( 90 20 )

    E' un DataRequest.
    Il P1 risponde con valore da 0x00 => 0x20
    Il valore di P1 determina l'informazione che la CAM chiede alla CARD :

    --> D0 74 P1 80 01
    <-- LL
    --> D0 74 P1 00 LL

    P1 = 0x00 => LL = 0x07 ( 7 ) byte
    <-- 24 05 03 20 5B 0A 20
    24 05 Controllo scadenza tier 03 20 ( Promotion packet )
    03 20 Tier 03 20 ( Promotion packet )
    5D 1A Data scadenza tier
    20 ?? Presente anche nella ins 76 ( 8 byte ) solo per questo tier


    P1 = 0x01 => LL = 0x7C ( 124 ) byte
    --> D0 74 01 00 7C
    <-- 74
    <-- 01 7A 1E 01 D0 0E FF 02 D0 1E 09 03 D0 2E FF 00 D0 32 01 01 D0 36 FF 02 D0 38 02 03 D0 40 FF 00 D0 42 FF 00 D0 44 35 01 D0 46 FF 00 D0 4A FF 00 D0 4C 09 01 D0 4E 05 03 D0 50 FF 02 D0 54 2C 03 D0 56 FF 02 D0 58 4A 03 D0 5A FF 02 D0 5C 04 03 D0 5E FF 02 D0 6A FF 00 D0 6C FF 02 D0 70 25 03 D0 72 23 03 D0 74 FF 02 D0 76 0A 03 D0 78 18 03 D0 B4 40 01 D0 BC 50 03 D0 BE 10 03
    <-- 90 20 (20,3999999997905millisecondi)
    ( no error / no update alocation / no update Eeprom / bit IRD setted )

    Dove :
    01 7A Indicatore + byte len 0x7A ( 122 ) al seguito
    1E Numero di ins elencate
    01 Inizio PageList

    INS LL Par
    D0 0E ---- FF ---- 02
    D0 1E ---- 09 ---- 03
    D0 2E ---- FF ---- 00
    D0 32 ---- 01 ---- 01
    D0 36 ---- FF ---- 02

    D0 38 ---- 02 ---- 03
    D0 40 ---- FF ---- 00
    D0 42 ---- FF ---- 00
    D0 44 ---- 35 ---- 01
    D0 46 ---- FF ---- 00
    D0 4A ---- FF ---- 00
    D0 4C ---- 09 ---- 01
    D0 4E ---- 05 ---- 03
    D0 50 ---- FF ---- 02
    D0 54 ---- 2C ---- 03
    D0 56 ---- FF ---- 02
    D0 58 ---- 4A ---- 03
    D0 5A ---- FF ---- 02
    D0 5C ---- 04 ---- 03
    D0 5E ---- FF ---- 02
    D0 6A ---- FF ---- 00
    D0 6C ---- FF ---- 02
    D0 70 ---- 25 ---- 03
    D0 72 ---- 23 ---- 03
    D0 74 ---- FF ---- 02
    D0 76 ---- 0A ---- 03
    D0 78 ---- 18 ---- 03
    D0 B4 ---- 40 ---- 01
    D0 BC ---- 50 ---- 03
    D0 BE ---- 10 ---- 03

    Il risultato &egrave; una PageList.
    Se il valore ricavato del'elenco LL dell'ins <> FF l'ins elencata ha una len fissa.
    Il Bitmap del Par ci viene in aiuto :
    | 0 | 0 | 0 | 0 |
    | | | |_ _ _ _ _ Se bit = alto allora Len fissa altrimenti variabile
    | | |_ _ _ _ _ _ _ Se bit = alto allora CARD ---> CAM altrimenti CAM ---> CARD
    |_ |_ _ _ _ _ _ _ _ _ Non significativo


    P1 = 0x02 => LL = 0x03 ( 3 ) byte
    --> D0 74 02 00 03
    <-- 74
    <-- 28 01 00
    <-- 90 20 (20,2999999994063millisecondi)
    ( no error / no update alocation / no update Eeprom / bit IRD setted )
    Dove :
    28 01 Indicatore + byte len 0x01 ( 1 ) al seguito
    00 ????
    P1 = 0x03 => LL = 0x04 ( 4 ) byte
    --> D0 74 03 00 04
    <-- 74
    <-- 03 02 01 F6
    <-- 90 20 (20,2999999994063millisecondi)
    ( no error / no update alocation / no update Eeprom / bit IRD setted )

    Dove :
    03 02 Indicatore + byte len 0x01 ( 1 ) al seguito
    01 F6 ????


    P1 = 0x04 => LL = 0x12 ( 18 ) byte
    --> D0 74 04 00 12
    <-- 74
    <-- 15 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    <-- 90 20 (20,2999999994063millisecondi)
    ( no error / no update alocation / no update Eeprom / bit IRD setted )
    Dove :
    15 10 Indicatore + byte len 0x10 ( 16 ) al seguito
    00 00 00 00 00 00 00 00 ????
    00 00 00 00 00 00 00 00 ????


    P1 = 0x05 => LL = 0x22 ( 34 ) byte
    --> D0 74 05 00 22
    <-- 74
    <-- 05 20 49 54 41 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00 00 00
    00 00 01 00 00 00 00 00 00
    <-- 90 20 (20,2999999994063millisecondi)
    ( no error / no update alocation / no update Eeprom / bit IRD setted )
    Dove :
    05 20 Indicatore + byte len 0x20 ( 32 ) al seguito
    49 54 41 Codice paese
    00 00 00 00 00 00 00 00 ??
    00 00 00 00 00 00 00 00 ??
    80 ??
    00 00 00 00 00 ??
    01 Se 0x01 = attivata / se 0x00 = non attiva
    00 00 00 00 00 00 ??


    P1 = da 0x06 ---> 0x08 => LL = 0x12 ( 18 ) byte
    --> D0 74 0x 00 12
    <-- 74
    <-- 1C 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    <-- 90 20 (20,3999999997905millisecondi)
    ( no error / no update alocation / no update Eeprom / bit IRD setted )
    Dove :
    1C 10 Indicatore + byte len 0x10 ( 16 ) al seguito
    00 00 00 00 00 00 00 00 ??
    00 00 00 00 00 00 00 00 ??
    P1 = 0x09 => LL = 0x4A ( 74 ) byte
    --> D0 74 09 00 4A
    <-- 74
    <-- 16 48 80 07 02 42 4F FF FF FF 80 07 02 42 4F FF FF FF FF FF FF FF FF FF FF
    FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

    FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FFFF FF FF FF FF FF FF FF
    <-- 90 20 (20,2999999994063millisecondi)
    ( no error / no update alocation / no update Eeprom / bit IRD setted )
    Dove :
    16 48 Indicatore + byte len 0x10 ( 16 ) al seguito
    80 07 02 42 4F FF FF FF 80 07 02 42 4F = 800 - 702424 ( Call Center )
    80 07 02 42 4F FF FF FF 80 07 02 42 4F = 800 - 702424 ( Call Center )
    FF FF FF FF FF FF FF FF Registro a 0xFF ( vuoto )
    FF FF FF FF FF FF FF FF Registro a 0xFF ( vuoto )
    FF FF FF FF FF FF FF FF Registro a 0xFF ( vuoto )
    FF FF FF FF FF FF FF FF Registro a 0xFF ( vuoto )
    FF FF FF FF FF FF FF FF Registro a 0xFF ( vuoto )
    FF FF FF FF FF FF FF FF Registro a 0xFF ( vuoto )
    FF FF FF FF FF FF FF FF Registro a 0xFF ( vuoto )


    P1 = da 0x0A ---> 0x0F => LL = 0x12 ( 18 ) byte
    --> D0 74 0x 00 12
    <-- 74
    <-- 1C 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    <-- 90 20 (20,3999999997905millisecondi)
    ( no error / no update alocation / no update Eeprom / bit IRD setted )
    Dove :
    1C 10 Indicatore + byte len 0x10 ( 16 ) al seguito
    00 00 00 00 00 00 00 00 ??
    00 00 00 00 00 00 00 00 ??


    P1 = da 0x17 ---> 0x19 and 0x1C => LL = 0x12 ( 18 ) byte
    --> D0 74 0x 00 12
    <-- 74
    <-- 1C 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    <-- 90 20 (20,3999999997905millisecondi)
    ( no error / no update alocation / no update Eeprom / bit IRD setted )
    Dove :
    1C 10 Indicatore + byte len 0x10 ( 16 ) al seguito
    00 00 00 00 00 00 00 00 ??
    00 00 00 00 00 00 00 00 ??


    P1 = da 0x0B => LL = 0x04 ( 4 ) byte
    --> D0 74 0B 00 04
    <-- 74
    <-- 18 02 00 00
    <-- 90 20 (20,2999999994063millisecondi)
    ( no error / no update alocation / no update Eeprom / bit IRD setted )
    Dove :
    18 02 Indicatore + byte len 0x02 ( 2 ) al seguito
    00 00 ??

    Le Ins D0 74 che seguono con P1 = 0x0C a 0x0E leggono la stringa del nano E2_13 :
    P1 = da 0x0C => LL = 0x06 ( 6 ) byte
    --> D0 74 0C 00 06
    <-- 74
    <-- 19 04 FF FF FF FF
    <-- 90 20 (20,2999999994063millisecondi)
    ( no error / no update alocat

  2. #2
    ER' MEJO Moderator - Expert
    Join Date
    Apr 2005
    Location
    CAPUT MUNDI
    Posts
    2,094
    Posts Thanks / Likes

    Default

    si ai probat?merge

  3. #3
    Nemtzică Expert
    Join Date
    Jan 2004
    Location
    "...cu peronu pe partea stngă !"
    Posts
    3,431
    Posts Thanks / Likes

    Default

    Va bene ...

  4. #4
    Junior Member Junior
    RDI - Board Default Avatar

    Join Date
    Oct 2007
    Posts
    2
    Posts Thanks / Likes

    Default

    potreste girarmii i comandi ..grazie

  5. #5
    Member Mentor
    RDI - Board Default Avatar

    Join Date
    Nov 2003
    Posts
    968
    Posts Thanks / Likes

    Default

    Ma ... ce vindeti aici ?
    Vreau si eu daca se gaseste pe undeva.

  6. #6
    Junior Member Junior
    RDI - Board Default Avatar

    Join Date
    Oct 2007
    Posts
    2
    Posts Thanks / Likes

    Default

    can you speak in english please

  7. #7
    ER' MEJO Moderator - Expert
    Join Date
    Apr 2005
    Location
    CAPUT MUNDI
    Posts
    2,094
    Posts Thanks / Likes

    Default

    it's fake
    lascia perdere.
    cine nu a avut ce face si a dezgropat asta?

  8. #8
    Member Mentor
    Join Date
    Dec 2004
    Location
    zona sud
    Posts
    539
    Posts Thanks / Likes

    Default

    adica? exista mosc sau nu?ca pina acum am tot auzit de povesti

  9. #9
    ER' MEJO Moderator - Expert
    Join Date
    Apr 2005
    Location
    CAPUT MUNDI
    Posts
    2,094
    Posts Thanks / Likes

    Default

    Quote Originally Posted by lore View Post
    adica? exista mosc sau nu?ca pina acum am tot auzit de povesti
    nu.si nimic altceva in afara de share.

  10. #10
    SUBpedia Expert
    Join Date
    Jan 1970
    Location
    P'aci, p'acolo...
    Posts
    3,285
    Posts Thanks / Likes

    Default

    Sunt 2 ani de cnd nu mai merg moscurile....

  11. #11
    Junior Member Junior
    RDI - Board Default Avatar

    Join Date
    Jan 2008
    Posts
    1
    Posts Thanks / Likes

    Default Giro comandi

    Potete girarmi i comandi anche a me
    Grazie mille

  12. #12
    zzzzzzzzzzzzz Expert
    Join Date
    Dec 2005
    Location
    rdi
    Posts
    4,384
    Posts Thanks / Likes

    Default

    ad averli


  13. #13
    Moderator Expert
    Join Date
    Jan 1970
    Location
    Austria
    Posts
    9,493
    Posts Thanks / Likes

    Default

    Am facut exact ce a scris Topolino mai sus si merge tot, dar uneori mi se blocheaza imaginea pe anumite canale. Cred ca televizorul e de vina.

  14. #14
    zzzzzzzzzzzzz Expert
    Join Date
    Dec 2005
    Location
    rdi
    Posts
    4,384
    Posts Thanks / Likes

    Default

    vezi ca o fii vreo cartita pe antena si buruiaza semnalul


  15. #15
    Junior Member Teacher
    RDI - Board Default Avatar

    Join Date
    Sep 2005
    Location
    Romania
    Posts
    340
    Posts Thanks / Likes

    Talking

    Quote Originally Posted by Kroky View Post
    Am facut exact ce a scris Topolino mai sus si merge tot, dar uneori mi se blocheaza imaginea pe anumite canale. Cred ca televizorul e de vina.
    Buna asta...daca zicea cocolino il mai credeam dar asa....

 

 

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. TWIN CARD SLY Italy MOSC and C+ Frensh
    By calcio90 in forum RDI - English
    Replies: 1
    Last Post: 9th August 2007, 13:12
  2. S**Y Italy...
    By v11 in forum RDI - Satelit
    Replies: 1
    Last Post: 7th November 2005, 13:39
  3. N2 , d+, sky, sky italy and more forum!
    By anticabo in forum Placi DVB
    Replies: 4
    Last Post: 12th September 2005, 18:10

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Back to Top