Questo documento e' dedicato alla pecora Dolly, con molto affetto

ATR e' l'acronimo ufficiale per "Answer To Reset" ovvero "risposta al reset" di una card. In una smartcard con contatti visibili, e' necessario stabilire una comunicazione direzionale; questo viene fatto tramite un impulso sulla linea di rese. Se nella card e' presente un microprocessore funzionante, allora il processore mandera' un ATR e l'applicazione che gestisce la card la identifichera' correttamente.

L'ATR e' composto da un massimo di 33 bytes; nell'ordine

IC carattere iniziale (obbligatorio)

FC carattere di formato (obbligatorio)

F1,F2,., F15 caratteri di interfaccia (opzionali)

H1,H2,.. H15 caratteri storici (opzionali)

CK checksum (condizionale)

Il carattere iniziale contiene informazioni sulle convenzioni logiche e la frequenza di trasmissione; la card ha un clock interno in cui l'unita' di tempo elementare e' 1/9600 secondi, che corrisponde a una frequenza di 9600 baud al secondo. Il clock esterno invece e' 3.57 Mhz, come tutti ben sappiamo. Con calcoli noiosi si vede che gli unici valori possibili per IC sono 3F e 3B, Come tutti sappiamo nel caso di cards Seka l"IC e' sempre 3B, che corrisponde alla convenzione logica diretta.

Il carattere FC fornisce informazioni su i caratteri opzionali che seguono, nel seguente modo. Se FC = [XY] allora

- il low nibble Y puo' essere visto comeun normale numero decimale che indica quanti caratteri storici sono presenti

- l'high nibble X invece e' un numero esadecimale che trasformato in binario ci dice quanti caratteri di interfaccia sono presenti in modo ricorsivo a gruppi di quattro.

Spieghiamo questo ultimo fatto; disponiamo i possibili 15 caratteri di interfaccia quattro a quattro:

F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12 F13 F14 F15

Supponiamo che l'high nibble di FC sia 5; passando in binario il numero diviene 0101

Il che indica che sono presenti i caratteri di interfaccia F2 e F4. Il carattere F4 e' particolarmente importante perche' stabilisce sia il tipo di protocollo per la trasmissione,

sia quanti e quali ulteriori caratteri di interfaccia siano presenti. Piu precisamente se

F4 = [XY] allora

- se Y=0 oppure F4 non e' presente allora la trasmissione e' a caratteri, asincrona e half-duplex

- se Y=1 allora la trasmissione e' a blocchi, asincrona e half-duplex

- Y=2,.,15 sono riservati per futuri usi.

Inoltre l'high nibble X di F4 ci dice, trasformato in binario, quali caratteri siano presenti tra F5, F6, F7 e F8. Il procedimento continua ricorsivamente in questo modo fino ad arrivare eventualmen 525d32f te ad F15. I caratteri di interfaccia F1, F2, F3 e F6 definiscono i parametri della trasmissione tramite un set di equazioni.

I caratteri storici H1,.,H15 sono usati dai produttori per specificare informazioni di vario tipo; nel caso delle card Seka contengono tra l'altro i bytes che specificano il livello di programmazione della card .

Infine il carattere di checksum viene calcolato in modo tale che lo xor di tutti i bytes da IC a CK sia 0; tale carattere non compare quando Y=0 (che poi vedremo essere il caso delle card Seka).

Applichiamo adesso queste nozioni all'ATR di una normale card Seka funzionante (ver 4.1)

3B F7 11 00 01 40 96 58 42 14 0E 6C B6 D6

IC FC F1 F2 F3 F4 F6 H1 H2 H3 H4 H5 H6 H7

L'high nibble di FC e' F, cioe' 1111 in binario, il che ci dice che sono presenti F1, F2, F3 e F4. Il low nibble e' invece 7 il che ci dice che sono presenti 7 caratteri storici. L'high nibble di F4 e' 4, cioe' 0100, il che ci dice che e' presente il carattere di interfaccia F6 e niente altro. Infine il low nibble di F4 e' 0, il che ci dice che la trasmissione e' a caratteri, asincrona e half-duplex e spiega anche l'assenza di ckecksum.

I primi tre caratteri storici indicano il sistema operativo della carta (e altre cosette??) mentre gli ultimi quattro determinano il livello di programmazione. Notiamo anche che come e' ovvio i primi sette bytes dell'ATR sono uguali per tutte le card in ogni versione del firmware. Infatti questo e' l'ATR di una ver. 4.0:

3B F7 11 00 01 40 96 54 30 04 0E 6C B6 D6

e questo di una ver. 3.0

3B F7 11 00 01 40 96 52 84 03 0E 6C B6 D6

Tutto quello che cambia sono i primi tre caratteri storici.

Abbiamo detto che gli ultimi 4 caratteri storici individuano il livello di programmazione della card. Piu' precisamente si individuano quattro livelli

- 0E 6C B6 D6 : Livello 1 o "Normal Program Mode"

- 9B 1B C2 A3 : Livello 2 o "Low Program Mode"

- A5 96 58 7C : Livello 3 o "High Program Mode"

- ogni altra combinazione : Livello 4 o "Coaster Mode" o "Livello sottobicchiere"

Al Livello 1 la card e' in normali condizioni di funzionamento, risponde correttamente alla CAM del decoder e per cosi' dire "fa il suo mestiere". Ai Livelli 2 e 3 la card non viene vista dal decoder, ma risponde a comandi specifici (diversi per ciascun livello). Al Livello 4 la card e' in coma profondo, risponde solo a pochissimi comandi e non e' piu' manipolabile.

Questo e' l'ATR di una ver 3.0 a Livello 3

3B F7 11 00 01 40 96 54 30 04 A5 96 58 7C

Come si vede cambiano solamente gli ultimi quattro caratteri storici

2. Passaggi di livello e lo zzbug

La meccanica dei passaggi di livello e' ancora largamente sconosciuta, sebbene molti risultati positivi siano stati ottenuti ultimamente. Appare comunque evidente alcuni cambi di livello dipendono in modo decisivo dal sistema operativo della card. Gli unici cambi di livello previsti sono quelli da livello 3 a livello 1 o 2 che andiamo quindi a descrivere. Tali cambi avvingono mediante l'istruzione C1 3C nel seguente modo: supponiamo che la nostra card sia a Livello 3.. Allora

C1 0C 00 00 08 U1 U2 U3 U4 U5 U6 U7 U8

scrive un nuovo UA (unique address) sulla card;

C1 0C 00 03 00

fa passare da Livello 3 a Livello 1;

C1 0C 00 04 00

fa passare da Livello 3 a Livello 2.

Il caso in cui P2 = 01 e' di particolare interesse, poiche' e' quello che riattiva il Provider 00 e scrive una Mk0x su di esso. Per criptare tale comando viene usata la ISSUER KEY che e' una chiave di 8 bytes scritta a partite dalla locazione di memoria $E010 (e quindi irraggiungibile con il dump della ROM). Specificatamente il comando

C1 0C 00 01 16 23 00 00 90 KI 8*[KK] 82 SIGN(Issuer Key)

compie le seguenti operazioni:

- decripta la key 8*[KK] con la issuer key

- azzera tutta la Eeprom da $E064 fino alla fine

- inizializza il Provider 00 e salva la key decriptata

- salva il nome del Provider nel buffer.

E' ovvio che tale serie ci permette di scrivere una card da zero ed e' fondamentale nella creazione di una copia di una particolare card (vedi sezioni successive). A priori la non conoscenza della issuer key e' un problema, ma vedremo in seguito come puo' essere aggirato; e' gia' noto per esempio che TUTTE le card ver 3.0 hanno la stessa issuer key

(per il momento ancora sconosciuta) ed e' stato ipotizzato che questa key sia in realta' la stessa per ogni versione. Ritorneremo sulla issuer key (e sulle ipotesi fatte sul suo uso) piu' avanti.

Il passaggio da Livello 1 o 2 al Livello 3 appare di difficile comprensione. Nonostante ci siano stati alcuni "reports" di card passate dal Livello 1 a Livello 3 in condizioni di particolare stress elettrico o di altro tipo, il primo resoconto sistematico di un passaggio di livello con metodi hardware si deve a Azanazan. Il suo metodo sfrutta il programma (nato per Irdeto !!) Cardwizard 1.515 e consiste nel far passare la card attraverso diversi cicli di rianimazione con contemporaneo sfila-infila della card nello slot dello smartmouse. Per quanto empirico sia il sistema, sperimentazioni successive hanno portato alla conclusione che esso funziona sicuramente per la ver. 3.0 (per cui ci sono addirittura reports di passaggio da Livello Coaster a Livello 3 !!??) e probabilmente per la versione 2.0. Per la ver. 4.0 c'e' un solo report di attendibilita' assai dubbia e non ci sono notizie di successo per la ver. 4.1.

Sempre a giudicare dalle varie notizie sparse per il web sembra che il passaggio dal Livello 1 al Livello 2 avvenga in modo "casuale" piu' facilmente rispetto al passaggio dal Livello 1 al Livello 3. Questo fatto tuttavia e' stato superato da alcuni recentissimi sviluppi che sfruttano un altro simpatico bug presente nella ver. 4.1 delle card Seka. Diciamo subito che il bug che andiamo a illustrare e' presento SOLO nella versione 4.1 dell card Seka. Questo non e' di per se' un limite, visto che la maggior parte della card in circolazione ha questa versione del firmware. Tuttavia questo limita fortemente tutte le possibili indagini teoriche, in quanto e' noto solo il dump dell ROM della ver. 4.0, nella quale in bug NON e' presente.

Lo scopritore ufficiale di questo bug e' Zztop, per cui chiameremo questo bug lo Zzbug.

Il bug (tanto per cambiare) e' basato su un buffer underflow o, se si preferisce, su un controllo mancato sulla lunghezza di un comando. Infatti nel comando

C1 3C P1 P2 LL

se l'high nibble di P2 e' 8,9,A,B,C,D,E o F viene invocata la routine di decriptazione dei dati (poiche' l'INS 3C supporta la superencryption). Tale routine sottrae 8 da LL senza fare alcun controllo sulla sua lunghezza e comincia a lavorare. Ne segue che se

LL = [0 la routine credera' che la lunghezza dei dati e' [F8] (cioe' 248 in decimale) e continuera' a decriptare ben oltre il buffer, andando a cacciarsi in un area in cui ci puo' essere di tutto ( registri fondamentali, puntatori e chi piu' ne ha piu' ne metta). E' ovvio che con queste premesse puo' scatenarsi di tutto; Zztop e' stato il primo a sperimentare lo Zzbug usando il comando

C1 3C 00 Fx 00

Tale comando invoca una decrittazione fatta con la chiave Fx del Provider 00 e gli effetti sperimentali osservati dipendono dal contenuto in chiaro della chiave inserita ma non dal keyindex; in altre parole la chiave puo' essere una Mk01, Mk02 e cosi' via..

Alcuni effetti osservati sono:

Key in chiaro Effetto

11 11 11 11 11 11 11 11 Scrive una specifica chiave 05, che in chiaro e' 03 13 E8 15 E8 23 13 E5

11 EF 00 00 00 00 00 00 Scrive una chiave 06 con keyindex= 16

11 11 0C 00 00 00 00 11 Scrive una chiave 04 con keyindex = 34

11 22 33 44 55 66 77 88 Scrive una chiave 09 con keyindex =89

Fin qui la cosa e' semplicemente curiosa, ma Zztop fu anche in grado di osservare che

Key in chiaro Effetto

0E 00 00 00 00 00 00 00 Fa passare la card a Livello 2

11 11 1C 00 00 00 00 00 Fa passare la card a Livello 2

11 1C 00 00 00 00 FF FF Fa passare la card a Livello Coaster[02 00 02 0

Era quindi chiaro che lo Zzbug poteva scatenare degli NMI e quindi causare dei passaggi di livello. Lo Zzbug e' stato a lungo sottovalutato ; le ragioni sono molteplici e sono da ricercare sia nella pericolosita' insita in una sperimentazione di questo tipo (dal Livello

Coaster per ora non si torna indietro.), sia nella scarsa attenzione ricevuta in quel momento dai cambi di livello. Ultimamente pero' con i metodi hardware per il passaggio da Livello 1 a Livello 3 (e la conseguente creazione di "cloni", vedi sezioni successive) l'interesse si e' ravvivato. Grazie agli sforzi comuni del SatTwins Group e'stato possibile riprendere a sperimentare sullo Zzbug nella speranza di ottenere un metodo "software" per il cambio di Livello da 1 a 3. Come spesso succede cercando una cosa se ne trova un'altra,forse anche piu' interessante.

Una scheda a Livello 2 non funziona correttamente, nel senso che il decoder non la riconosce; tuttavia sono abilitate (quasi) tutte le INS del Livello 1 piu' altre specifiche del Livello 2. In particolare la INS 3C funziona benissimo. Provando lo Zzbug su una card a Livello 2, Sassanqua ha trovato che

Key in chiaro Effetto

24 24 24 24 24 24 24 24 Fa passare la card da Livello 2 a Livello 1 ! ! ! ! !

Le conseguenze di questa scoperta sono ancora tutte da verificare; sicuramente si aprono nuove prospettive sullo studio delle INS per il Livello 2 e inoltre aumenta la speranza di trovare un metodo software per arrivare all'agognato Livello 3. A questo punto comunque appare indispensabile un dump della ROM della ver. 4.1.

3. Copie fisiche e copie logiche

E' possibile clonare una card Seka? In linea di principio la risposta e' si', ma con possibili eccezioni. In biologia un clono di un essere vivente e' semplicemente un altro essere vivente con l'identico patrimonio genetico del donatore, ovvero lo stesso DNA. In altre parole un clono biologico e' semplicemente un essere indistinguibile dal donatore in termini dell'analisi genetica.

Nel nostro caso quindi un clono di una card puo' essere definito come qualsiasi altra cosa che sia indistinguibile dalla card donatrice a livello del linguaggio Mediaguard; in altre parole un clono e' una copia logica di una card, dove la logica e' appunto quella del linguaggio. Si noti che non e' necessario che un clono sia una copia fisica della card; un emulatore ben fatto puo' benissimo risultare indistinguibile da una card. Un wafer contenente l'UA, le chiavi e le PPUA di una card sara' per molti versi indistinguibile dalla donatrice. Hardware piu' sofisticati, come la SimpleÓ di Antotracer o la EvilÓ di SkyDiver possono raggiungere un livello notevole di indistinguibilita' [e in qualche caso possono essere addirittura migliori dell'originale].

Prima quindi di definire il nostro concetto di clone bisogna chiarire bene cosa noi consideriamo una caratteristiche uniche della card. Pare ragionevole considerare

· Il sistema operativo (o firmware) della card

· L'UA della card

· Le chiavi dei providers

· I records e il loro ordine

Un hardware che condivide tutte queste caratteristiche con una card merita sicuramente di essere chiamato un clono. Qualora il supporto hardware sia lo stesso, saremmo molto vicini ad una copia fisica completa; quanto si sia vicini e' ancora oggetto di dibattito.

Se la nostra definizione e' questa, allora per ora le uniche card clonabili sono quelle con la ver. 3.0 del firmware. Infatti per il processo di scrittura dell'UA e' indispensabile raggiungere l'High Program Mode , cosa in questo momento possibile con continuita' solo su card con tale firmware. Definiamo quindi un concetto piu' debole:

un clono-a-la-Poker [dal nome di uno dei primi sperimentatori di questa tecnica] e' semplicemente qualsiasi hardware che sia indistinguibile dalla card "donatrice" dalla

CAM di un decoder.

Quanto e come sia indistinguibile sara' piu' chiaro nella prossima sezione; si noti che in questo senso la Evil di SkyDiver e' (almeno in prospettiva) un clono-a-la-Poker.

4. Clono a-la-Poker

Per comprendere a fondo la creazione di un clono-a-la-Poker bisogna avere ben chiara la sintassi dell'INS 3C nel caso la card sia livello 3, gia' descritta nella sez. 2. Una volta compreso questo l'unico problema e' dato dalla ISSUER KEY. Tale chiave e' tutt'ora sconosciuta ed e' stato ipotizzato che sia uguale per tutte le card.; sicuramente e' uguale per tutte le ver. 3.0.

E' chiaro tuttavia che non e' necessario conoscere la Issuer Key, ma e' sufficiente conoscere la SIGN mediante la issuer key nel comando

C1 0C 00 01 16 23 00 00 90 KI 8*[KK] 82 SIGN

Tale signature e' stata trovata mediante l'uso di Seti, un programma che sfrutta il "delay" di risposta della card nel restituire uno status byte di risposta al controllo della signature.

Dato che lo scopo di questo documento non e' spiegare il funzionamento di Seti, dimao solo una descrizione sommaria del procedimento. Poiche' il controllo della signature avviene byte per byte e' possibile valutare il tempo di risposta della card ( Seti = Seca Timer) e mettere da parte i bytes a cui la card risponde con piu' prontezza. Procedendo ciclicamente a questo modo eventualmente si trovera' la giusta signature. E' opportuno notare che il delay alla risposta si verivica sollo nelle card ver 2.0, 3.0, 3.1 e 4.0; nella 4.1

Seti, almeno con i settaggi di default, pare non funzionare.

Ritornando alla creazione del clono, supponiamo di avere una card 3.0 a livello 3. Allora

· si scrive l'UA della card donatrice;

· si crea il Prov. 00 00 con una Mk00 in chiaro uguale a [11 22 33 44 55 66 77 88] mediante il comando

C1 0C 00 01 16 23 00 00 90 F0 11 22 33 44 55 66 77 88 82 6D EE 52 F3 B3 40 61 5E

· si ritorna a livello 1

A questo punto la card e' pronta per ulteriori normali scritture dei Providers e delle chiavi della card donatrice e attivazione della card medesima.

Per verificare che si tratta effettivamente di un clono-a-la-Poker e' stata portata a buon fine la seguente procedura:

· creazione della card con i dati di una card "originale", ma senza attivazione

· richiesta telefonica di attivazione al Provider

· attivazione da parte del Provider

· aggiornamente di tutte le chiavi

In conclusione il clono cosi' ottenuto e' indistinguibile (almeno tramite CAM) dalla card donatrice.

5. L'ordine dei records

Questo e' il dump dei primi quattro records di una card Seka "regolare"

Provider 0

Record 0001 = 01 00 00 00 00 00 00 00 00 00 80 E0

Record 0002 = 00 04 02 00 1E 00 10 C9 05 25 A0 E0

Record 0003 = F0 FF FF FF FF FF FF FF FF 9E 00 80

Record 0004 = 50 FF FF FF FF FF FF FF FF 30 00 C0

Il primo record e' il Seka Startup Record e il secondo e' un Seka PPV record; seguono Mk00 primaria e secondaria. Questo ordine e' stato osservato identico in tutte le card considerate. Tuttavia con la procedura descritta nella sezione precedente chiaramente il Record 0001 verrebbe occupato dalla Mk00 [11 22 33 44 55 66 77 88] che abbiamo scritto per prima. Sono state fatte diverse ipotesi sul perche' di questa struttura e soprattutto come sia ottenibile con procedure software. L'ipotesi piu' attendibile pare quella di C0m4nch3 che riportiamo testualmente

<< ..immaginiamo di avere una card con a bordo una sola MK primaria e secondaria, questa avrà detta key in dei record che sono 1 e 2. Tenete presente che dico che la card, a bordo, non ha nient'altro che quei 2 record, ed inoltre, dato che la MK00 la immagino inserita dal provider come per le welcome accade con la MK01, la MK presente non è una 00, quindi immaggino la card in questo stato:

record 01: Fx FF FF FF FF FF FF FF FF 00 00 80

record 02: 5x FF FF FF FF FF FF FF FF 00 00 C0

con x != 0

chiaramente, come per le welcome, questa KEY è sempre identica, anche per permettere al provider che le inizializzerà di poter usare dei processi automatizzati. A questo punto il provider cosa potrebbe fare su queste card???? Se seguo il processo che avviene su una welcome, dovrebbe accadere qualcosa del tipo:

- scrittura MK00 (primaria e secondaria)

- cancellazione MK0x

- scrittura record seca (tipo 01 e 00)

Andando ad analizzare step by step quello che potrebbe succedere ai record troverò nelle varie fasi:

- scrittura MK00 (primaria e secondaria)

record 01: Fx FF FF FF FF FF FF FF FF 00 00 80

record 02: 5x FF FF FF FF FF FF FF FF 00 00 C0

record 03: F0 FF FF FF FF FF FF FF FF 00 00 80

record 04: 50 FF FF FF FF FF FF FF FF 00 00 C0

sempre con x != 0

Quindi la MK00 verrà scritta neri primi record disponibili, segue poi la fase in cui si cancella la KEY inserita dal produttore nel processo di masterizzazione card:

- cancellazione MK0x

record 03: F0 FF FF FF FF FF FF FF FF 00 00 80

record 04: 50 FF FF FF FF FF FF FF FF 00 00 C0

A questo punto la card rimane con la sola MK00 a bordo posizionata come sopra, ed il provider scriverà i 2 record Ex e questi occuperanno le prime posizioni libere sulla card (1 e 2):

- scrittura record seca (tipo 01 e 00)

record 01: 01 SS SS SS SS SS SS SS SS SS SS E0

record 02: 01 SS SS SS SS SS SS SS SS SS SS E0

record 03: F0 FF FF FF FF FF FF FF FF 00 00 80

record 04: 50 FF FF FF FF FF FF FF FF 00 00 C0

ecco come penso si arrivi alla situazione record che si trova su tutte le card, non solo, ma suppongo che a questo punto dato che questa key dipende dal ciclo produttivo, ho motivo di credere che sia la stessa che normalemte serva a verificare la signature per i comandi tipo 0C a livello 3, non avrebbe senso farle diverse.... >>

L'ipotesi di C0m4nch3 e' interessante e plausibile; Sassanqua ha osservato che due chiavi potrebbero essere non una coppia primaria/secondaria, ma bensi' due chiavi diverse

(di keyindex F2 e F3 per esempio, come a volte succede in altri Providers). Tale ipotesi e' stata anche messa in discussione; per esempio PippoPelodettoilPop ha sostenuto che

<< Mi dispiace ... ma il ragionamento non fila.

Prova ad imaginare il provider che scartoccia tutte le card e poi le riimpacchetta tutto questo perche' per inserire due record? Troppo antieconomico. Io credo che il provider non e' a conoscenza del modo per accedere al livello 3 perche' solo gestito dal produttore.>>

Per completezza riportiamo anche le risposte di C0m4nch3 a questa osservazione e ad altre dello stesso tenore:

<<. le card vengono fatte con un processo detto masterizzazione del chip, ma questo non lo fa il provider, il provider fa televisione, questo processo lo fa la STmicro e lo effettua con apparecchiature sofisticate su chip vergini non piu' riscrivibili. L'impedimento a scrivere tutto il resto è dato dal fatto che sarebbe molto insicuro affidare a terzi la gestione delle MK delle card, quindi il provider con tutta probabilità preferisce inserirle "solo". Non solo.... ma non è competenza del produttore scegliere parametri adeguati per startup e ppv record. Il produttore ti da il minimo indispensabile per poter gestire la card. Poi il provider effettua le sue scelte.... sarebbe da ridere un processo industriale ad alta tecnologia che prevede la scrittura dei chip uno per volta per inserire dati diversi (MK00). Più probabilmente il produttore inserisce una key per far gestire al cliente (provider) la card come meglio crede.>>

<<.... anche se è suca o chi vuoi tu a caricare la rom > 4000 con quello che vuoi tu, rimane il fatto che a possedere la MK00 finale della card deve esserne il possesore legale della card (il provider che mette la serigrafia non l'utente), se così non fosse si potrebbero attuare politiche di concorrenza sleali e non penso che uno che investe miliardi si voglia mettere a questo rischio. Ogni provider penso voglia la sicurezza che la MK00 della SUA card la sappia solo lui ... quindi sarà il provider a metterla su e non chi carica la rom. >>

Stabilire se la teoria sia corretta o meno non rientra tra gli scopi di questo documento. E' importante tuttavia notare che le considerazioni dell'indiano ci forniscono una procedura per scrivere i record di un clono-a-la Poker nel "giusto" ordine, facendo cosi' un ulteriore passo in avanti verso una copia fisica della card. La seguente procedura e' dovuta ancora una volta a Poker. Sempre partendo dal livello 3

· si scrive l'UA della card donatrice

· si scrive il Prov 00 e una Mk01 su di esso col comando

C1 0C 00 01 16 23 00 00 90 F1 11 22 33 44 55 66 77 88 82 9A EC 61 68 18 99 80 67

(signature ottenuta con Seti..) occupando il primo record

· si passa a livello 1

· si scrive una Mk02 firmando con la Mk01 occupando cosi' il secondo record

· si scrive la Mk00 primaria della card donatrice fimando con la Mk01, occupando cosi' il terzo record

· si scrive la Mk00 secondaria della card donatrice

· si cancellano i primi due records firmando con la nuova Mk00

· si inseriscono ai primi due posti il Seka Startup Record e il Seka PPV Record della donatrice

· si inseriscono tutti gli altri records della donatrice nell'ordine "giusto"

A questo punto siamo veramente vicini ad avere una copia fisica della card donatrice ; se poi la card donatrice e' una ver. 3.0 allora risulta veramente difficile immaginare in cosa potrebbero differire fisicamente l card e il suo clono. Sono state fatte alcune ipotesi al riguardo, ma per ora senza alcun sostegno teorico.

6. Problemi aperti

Sebbene molto sia stato fatto ultimamente, molto rimane ancora da fare. Crediamo che le questioni principali su cui sarebbe necessario fare progressi sono le seguenti.

· Abbiamo gia' visto che lo Zzbug scatena degli NMI sulla card provocando passaggi di livello. E' ipotizzabile che anche un passaggio di livello da 1 a 3 sia ottenibile in questo modo e bisognerebbe sperimentare. Ovviamente la sperimentazione e' bloccata dal fatto che molte combinazioni dello Zzbug portano la card al Coaster Mode, dal quale non si torna indietro (per ora). Un modo di aggirare questo problema sarebbe quello di costruirsi un "emulatore" della ver. 4.1, il che ci porta alla questione secondo me piu' importante in questo momento.

· E' NECESSARIO ottenere un dump della ROM della ver 4.1. In principio la cosa e' fattibile, ma presenta della notevoli difficolta' tecniche. E' tuttavia auspicabile un impegno di tutta la comunita' verso questo progetto, la cui realizzazione farebbe fare veramente un notevole salto di qualita' alla nostra conoscenza.