Aggiornare a manina!
Ciao Ragazzi,
spero di fare cosa gradita aprendo questo thread che magari in futuro, se cambieranno le cose, potrà anche essere usato per tracciare le modifiche avvenute.
Spero potrà essere di riferimento per quanti, come me, hanno voglia di provare ad avere più controllo su quello che accade nel proprio decoder.
Allora, non perdiamo altro tempo e veniamo subito al dunque.
Per aggiornarsi la carta a manina prima bisogna loggare gli EMM che vengono dal cielo.
Ci sono molti modi per farlo, ma qui siamo sul sito di oscam e io mi occuperò di come farlo con la nostra cam preferita!
Quindi, come molti di voi sanno già, oscam ha una opzione da inserire in ciascun card reader (file oscam.server) che si chiama savenano.
Impostando savenano = all , TUTTI gli EMM diretti alla vostra carta verranno loggati sia su un file binario (readerlabel.bin) che su un file testuale (readerlabel.log).
I file si trovano in genere nella stessa cartella dove vengono inseriti quelli dei settings.
Ci sono due problemi attualmente con quest'opzione però:
1) la duplicazione dei dati in un file bin e in un file di testo occupa spazio inutilmente
2) Ultimamente vengono inviate montagne di EMM-G (inutili al nostro scopo) ma che vengono cmq memorizzati nel file e riempiono la flash in poche ore.
Se siamo interessati solo agli aggiornamenti, allora possiamo modificare la funzione che si occupa di gestire gli emm in oscam, per loggarci solo gli EMM-U e salvarli solo in un file binario. Scelgo (per voi) il file binario, perché vi sono montagne di software che poi permettono di leggere e filtrare i log di questo tipo (uno a caso, il
mio!).
La patch è una semplice modifica da fare alla funzione do_emm() di oscam.c : bisogna sostituire il blocco che inizia per "should this nano be saved" con il seguente codice....
Codice sorgente
if ( ( (1<<(ep->emm[0] % 0x80)) & aureader->s_nano ) && (ep->type == UNIQUE) ) { //should this nano be saved?
char token[256];
FILE *fp;
int32_t emm_length = ((ep->emm[1] & 0x0f) << 8) | ep->emm[2];
char buf[80];
snprintf (token, sizeof(token), "%s%s_emm.bin", cfg.emmlogdir?cfg.emmlogdir:cs_confdir, aureader->label);
if (!(fp = fopen (token, "ab"))) {
cs_log ("ERROR: Cannot open file '%s' (errno=%d: %s)\n", token, errno, strerror(errno));
} else {
if ((int)fwrite(ep->emm, 1, emm_length+3, fp) == emm_length+3) {
cs_log ("Successfully added binary EMM to %s.", token);
} else {
cs_log ("ERROR: Cannot write binary EMM to %s (errno=%d: %s)\n", token, errno, strerror(errno));
}
fclose (fp);
}
}
Allego la patch di oscam a questo post (è stata testata sulla versione OSCAM 1.20-unstable_svn build #5758) ma è talmente semplice da poter essere applicata su qualsiasi versione.
Una volta ottenuto un file di log, si può usare un programma per filtrarlo ed estrarre solo gli EMM che hanno uno specifico byte di LENGTH.
Per la cronaca, attualmente gli aggiornamenti inviati dal cielo hanno le seguenti LEN in esadecimale : 22, 32 e 42.
Per intenderci un aggiornamento normalmente viene veicolato con una len 32 per le 0919 che non hanno il service tier 000b.
Mentre per le altre carte o viene inviata una len 42 (che agggiorna sia tutti i tiers che il service 000b) oppure mediante due ins: una len 22 che aggiorna solo lo 000b e la 32 che aggiorna i tiers a cui siamo abbonati. Perché questo? Probabilmente una questione di compatibilità col passato... Inoltre lo fanno perché le len 22 veicolano anche le disattivazioni, quindi se la carta è in scadenza tocca andarci coi piedi di piombo!
E' difficile andare a confondere gli aggiornamenti con gli EMM killer, perché questi (diretti al decoder e non all'SC) per ora hanno una lunghezza di molto superiore (più di 80 hex - da non confondere con la lunghezza del nano 90 incriminato, al suo interno, che normalmente è 1A hex).
ATTENZIONE:
gli EMM memorizzati nel log di oscam sono "precam", quindi normalmente non c'è solo il vostro EMM dentro.
Che vuol dire questo? Gli EMM precam sono un blocco di bytes che inizia per 8230A750 dove gli ultimi due numeri indicano quanti EMM 'postcam' ci sono nell'intero blocco precam. (50=2 EMM, 60=3 EMM, 70=4 EMM...).
Per capirci meglio questo è un esempio di parsing di un EMM precam che contiene due ins per due card diverse.
8230A75000AC8B280132623B0000D302002290204402AA44BE63C77F8639D8F350CB8422BADFD5F114EBA3C0B6CC36A1C067AFCF00DB020032903044038E27D78CF356EAF66828316B52E6C237E1DC24BDB03613EC2C1E378063A996EAE3B172373F0CDB52DA73DEF1385600
8230A7(50) <<< 50 vuol dire 2 EMM
00AC8B28 = prima UA SC
0132623B = seconda UA SC
0000
D30200 qui sotto c'è la ins relativa alla prima UA (ha len 22 hex)
(22) 90204402AA44BE63C77F8639D8F350CB8422BADFD5F114EBA3C0B6CC36A1C067AFCF 00
DB0200 qui sotto c'è la ins relativa alla seconda UA (ha len 32 hex)
(32) 903044038E27D78CF356EAF66828316B52E6C237E1DC24BDB03613EC2C1E378063A996EAE3B172373F0CDB52DA73DEF13856 00
A questo punto immaginiamo che la vostra card sia la seconda, allora bisogna prendere i byte dal 32 al 56, e aggiungerci D0420000 in testa.
Quindi la vostra ins da inviare alla carta tramite
smartmouse sarà:
D042000032903044038E27D78CF356EAF66828316B52E6C237E1DC24BDB03613EC2C1E378063A996EAE3B172373F0CDB52DA73DEF13856
Se l'aggiornamento è andato a buon fine, avrete una risposta 9081 o 9181 (nel caso vada a scrivere qualcosa in ROM).
Se invece risponde 9080 vuol dire che la data dei tiers è la stessa di quelli contenuti nell'EMM.
Dimenticavo, per inviare le ins tramite
smartmouse ci sono vari programmi, io normalmente uso NTSite... cercatelo su google.
E fate bene attenzione che a seguire il byte di len (32, 22 o 42 che sia) ci siano il byte 90 e il byte LEN-2 (30, 20 o 40 a seconda della len che state usando) altrimenti quello non è un aggiornamento!
Ciao,
TWJ