Di seguito è riportato uno studio del paring hardware di Sky italia con la ins7e.
Partiamo dal vecchio sistema nds, che sarebbe stato quello delle 0919 degli anni 2005-2009 circa.
Il pairing non è stato mai applicato in italia, ma se lo fosse stato, si sarebbe parlato di pairing software.
Esso come alcuni nds stranieri insegnano, funzionava con l'invio del seriale del decoder tramite ins4c; in pratica se la card riconosceva quel seriale come quello suo del married, dava decrypt corretto, altrimenti si avrebbe avuta una non corretta dw dell'ecm (0f 04 00 10..).
Il nuovo pairing, invece, che definiamo hardware, richiederebbe per la sua risoluzione la lettura di un qualcosa che sta scritto all'interno del decoder e quasi più certamente nel criptoprocessore stesso.
Partiamo dalle prime differenze sostanziali tra vecchio e nuovo sistema.
La ins4c non restituisce più il seriale del decoder, ma un altro valore presente nel menu del decoder che è l'sbt_id.
Inoltre invece del solo sbt_id, nel nuovo sistema viene inviato anche un nuovo comando chiamato ins7e
Ecco un esempio con dati che potete prendere come reali del nuovo sistema.
[13.10.38]:
D0 4C 00 00 09 (4C) AA 4B 1F C7 03 00 00 11 64 [90 00]
(...)
[13.10.41]:
D1 4C 00 00 09 (4C) AA 4B 1F C7 03 00 00 11 65 [90 00]
[13.10.41]:
D1 7E 10 00 1A (7E) 42 73 25 10 31 EC DD 48 2A 4B 1F C7 00 00 00 00
00 01 00 02 03 00 02 02 02 03 [90 01]
Questa è parte del normale boot, di un pace 831 hd (decoder molto comune)
Nei due invii della ins4c in classe D0 e in classe D1, si vede che quel sbt_id è ben conosciuto dalla card (status byte 90 00).
Quindi arriviamo al dato più importante, relativo al pairing hardware, l'invio della ins7e.
Essa, chiamata appunto anche marry info, è la vera novità introdotta e che sta alla base di tutti i nostri guai sugli hd
Come si vede sopra dal solo invio in classe D1 e la risposta [90 01] essa dopo ogni reset viene sempre riscritta in eeprom e usata appunto qual ora la metodologia del pairing sia applicata all'ecm.
Ma prima di provare a spiegarla, incollo le parole che mi ha detto uno che aveva una conoscenza del sistema, quando me ne parlò un giorno:
...Non farti ingannare dai documenti o da altro. L'invio della 4c è un qualcosa di indispensabile nel sistema nds, altrimenti il sistema non funziona correttamente, ma quel dato non è più praticamente necessario ora
Il vero dato che conta è la ins7e. Qualcuno parla di quella ins, come un dato superfluo , ma quel dato è invece fondamentale!
Questo perché la ins7e contiene già al suo interno l'sbt_id ed è per questo che ti dico, con un gioco di parole, che paradossalmente la 4c è indispensabile, ma non necessaria.
Ti farò un esempio semplice, che ti rimarrà per sempre nella testa. Pensa a quando 20 anni fa per noi era obbligatorio per le transazioni bancarie ricordare il nostro numero di conto corrente. Adesso online si usa semplicemente l'iban.
Bene, la ins7e è l'iban nell'nds
Prendiamo la ins7e precedente e analizziamola nel dettaglio.
42 73 25 10 31 EC DD 48 2A 4B 1F C7 00 00 00 00 00 01 00 02 03 00 02 02 02 03
I primi 4 byte sono relazionati al tipo di processore del decoder e in questo caso, indicano un pace 831
42
73 25
10
Sono dati fissi, ma cambiando il processore, oltre ai due byte centrali, può cambiare anche tutto il resto
quindi abbiamo 4 byte, di cui non conosciamo il significato, ma sappiamo essere univoci per ogni ins7e, quasi fossero il suo seriale
quindi i 4 byte dell'sbt_id (per questo si diceva che la 4c è indispensabile ma non necessaria) con il primo byte a xor/80 (AA -> 2A).
Quindi 4 byte generalmente a 00, ma che potrebbero essere anche scritti, perché di proprietà del processore
e una parte finale composta da due serie di 5 byte ( 00 01 00 02 03 / 00 02 02 02 03 ) che vengono impostate in modo fisso dal provider tramite un particolare emm diretto all'sbt_id.
Per capirsi, se la ins7e descritta in precedenza, non si fosse presentanta in quello stato, ma come:
42 73 25 10 31 EC DD 48 2A 4B 1F C7 00 00 00 00 00 00 00 00 00 00 00 00 00 00
avremmo avuto al momento in cui si sintonizzava un canale hd la scritta errore 07 a video.
Dopo la telefonata, sperando di aver parlato con un operatore decente, mandata quella che potremmo chiamare l'attivazione della marry info, avremmo avuto la ins7e corretta, come:
42 73 25 10 31 EC DD 48 2A 4B 1F C7 00 00 00 00 00 01 00 02 03 00 02 02 02 03
e la visione sui canali hd (sempre e solo su skybox, s'intende )
********
Andiamo ora al concreto
Credo sia evidente che l'invio di questo dato da solo non conta nulla.
Quando nel nov 2013, il pairing hw è entrato in vigore, c'è stata una certa corsa da parte di alcuni, per scoprire con un blocker o un logger quale fosse la propria ins7e e per farne implementare l'invio nei sorgenti di oscam.
In realtà l'invio di quel dato su oscam ad una carta 09cd non serve praticamente a nulla. Anzi, in verità fa solo danni (come freeze, blocchi, etc), perché il suo invio innesta un processo nella card che poi non viene correttamente gestito.
Questo perché la ins7e è solo la prima parte, la parte a noi visibile del processo di decrypt del pairing, ma in realtà essa fa parte di un sistema che ovviamente richiede anche un dato o altri dati nascosti, che risiedono nel criptoprocessore e che entrano in gioco al momento della creazione della temporanea chiave di decrypt.
Se non siamo al momento capaci di estrarre quanto serva dal decoder e riuscire ad inserirlo nel processo di decrypt del nostro emulatore, siamo destinata al maledetto errore di pairing di continuo (0f 0x 00 10..)
Questa un po' la base su cui partire nel thread e ragionare.
Partiamo dal vecchio sistema nds, che sarebbe stato quello delle 0919 degli anni 2005-2009 circa.
Il pairing non è stato mai applicato in italia, ma se lo fosse stato, si sarebbe parlato di pairing software.
Esso come alcuni nds stranieri insegnano, funzionava con l'invio del seriale del decoder tramite ins4c; in pratica se la card riconosceva quel seriale come quello suo del married, dava decrypt corretto, altrimenti si avrebbe avuta una non corretta dw dell'ecm (0f 04 00 10..).
Il nuovo pairing, invece, che definiamo hardware, richiederebbe per la sua risoluzione la lettura di un qualcosa che sta scritto all'interno del decoder e quasi più certamente nel criptoprocessore stesso.
Partiamo dalle prime differenze sostanziali tra vecchio e nuovo sistema.
La ins4c non restituisce più il seriale del decoder, ma un altro valore presente nel menu del decoder che è l'sbt_id.
Inoltre invece del solo sbt_id, nel nuovo sistema viene inviato anche un nuovo comando chiamato ins7e
Ecco un esempio con dati che potete prendere come reali del nuovo sistema.
[13.10.38]:
D0 4C 00 00 09 (4C) AA 4B 1F C7 03 00 00 11 64 [90 00]
(...)
[13.10.41]:
D1 4C 00 00 09 (4C) AA 4B 1F C7 03 00 00 11 65 [90 00]
[13.10.41]:
D1 7E 10 00 1A (7E) 42 73 25 10 31 EC DD 48 2A 4B 1F C7 00 00 00 00
00 01 00 02 03 00 02 02 02 03 [90 01]
Questa è parte del normale boot, di un pace 831 hd (decoder molto comune)
Nei due invii della ins4c in classe D0 e in classe D1, si vede che quel sbt_id è ben conosciuto dalla card (status byte 90 00).
Quindi arriviamo al dato più importante, relativo al pairing hardware, l'invio della ins7e.
Essa, chiamata appunto anche marry info, è la vera novità introdotta e che sta alla base di tutti i nostri guai sugli hd
Come si vede sopra dal solo invio in classe D1 e la risposta [90 01] essa dopo ogni reset viene sempre riscritta in eeprom e usata appunto qual ora la metodologia del pairing sia applicata all'ecm.
Ma prima di provare a spiegarla, incollo le parole che mi ha detto uno che aveva una conoscenza del sistema, quando me ne parlò un giorno:
...Non farti ingannare dai documenti o da altro. L'invio della 4c è un qualcosa di indispensabile nel sistema nds, altrimenti il sistema non funziona correttamente, ma quel dato non è più praticamente necessario ora
Il vero dato che conta è la ins7e. Qualcuno parla di quella ins, come un dato superfluo , ma quel dato è invece fondamentale!
Questo perché la ins7e contiene già al suo interno l'sbt_id ed è per questo che ti dico, con un gioco di parole, che paradossalmente la 4c è indispensabile, ma non necessaria.
Ti farò un esempio semplice, che ti rimarrà per sempre nella testa. Pensa a quando 20 anni fa per noi era obbligatorio per le transazioni bancarie ricordare il nostro numero di conto corrente. Adesso online si usa semplicemente l'iban.
Bene, la ins7e è l'iban nell'nds
Prendiamo la ins7e precedente e analizziamola nel dettaglio.
42 73 25 10 31 EC DD 48 2A 4B 1F C7 00 00 00 00 00 01 00 02 03 00 02 02 02 03
I primi 4 byte sono relazionati al tipo di processore del decoder e in questo caso, indicano un pace 831
42
73 25
10
Sono dati fissi, ma cambiando il processore, oltre ai due byte centrali, può cambiare anche tutto il resto
quindi abbiamo 4 byte, di cui non conosciamo il significato, ma sappiamo essere univoci per ogni ins7e, quasi fossero il suo seriale
quindi i 4 byte dell'sbt_id (per questo si diceva che la 4c è indispensabile ma non necessaria) con il primo byte a xor/80 (AA -> 2A).
Quindi 4 byte generalmente a 00, ma che potrebbero essere anche scritti, perché di proprietà del processore
e una parte finale composta da due serie di 5 byte ( 00 01 00 02 03 / 00 02 02 02 03 ) che vengono impostate in modo fisso dal provider tramite un particolare emm diretto all'sbt_id.
Per capirsi, se la ins7e descritta in precedenza, non si fosse presentanta in quello stato, ma come:
42 73 25 10 31 EC DD 48 2A 4B 1F C7 00 00 00 00 00 00 00 00 00 00 00 00 00 00
avremmo avuto al momento in cui si sintonizzava un canale hd la scritta errore 07 a video.
Dopo la telefonata, sperando di aver parlato con un operatore decente, mandata quella che potremmo chiamare l'attivazione della marry info, avremmo avuto la ins7e corretta, come:
42 73 25 10 31 EC DD 48 2A 4B 1F C7 00 00 00 00 00 01 00 02 03 00 02 02 02 03
e la visione sui canali hd (sempre e solo su skybox, s'intende )
********
Andiamo ora al concreto
Credo sia evidente che l'invio di questo dato da solo non conta nulla.
Quando nel nov 2013, il pairing hw è entrato in vigore, c'è stata una certa corsa da parte di alcuni, per scoprire con un blocker o un logger quale fosse la propria ins7e e per farne implementare l'invio nei sorgenti di oscam.
In realtà l'invio di quel dato su oscam ad una carta 09cd non serve praticamente a nulla. Anzi, in verità fa solo danni (come freeze, blocchi, etc), perché il suo invio innesta un processo nella card che poi non viene correttamente gestito.
Questo perché la ins7e è solo la prima parte, la parte a noi visibile del processo di decrypt del pairing, ma in realtà essa fa parte di un sistema che ovviamente richiede anche un dato o altri dati nascosti, che risiedono nel criptoprocessore e che entrano in gioco al momento della creazione della temporanea chiave di decrypt.
Se non siamo al momento capaci di estrarre quanto serva dal decoder e riuscire ad inserirlo nel processo di decrypt del nostro emulatore, siamo destinata al maledetto errore di pairing di continuo (0f 0x 00 10..)
Questa un po' la base su cui partire nel thread e ragionare.
RSS Feed
