Copy Link
Add to Bookmark
Report
BFi numero 08 anno 3 file 19 di 28
==============================================================================
------------[ BFi numero 8, anno 3 - 30/04/2000 - file 19 di 28 ]-------------
==============================================================================
-[ PHREAKiNG ]----------------------------------------------------------------
---[ CARD, CARDiNG? NO! PARTE II
-----[ RigoR MorteM <rigormortem@spippolatori.com> http://www.spippolatori.com
Siamo ancora alle prese con le smart card...
Beh, c'e' una novita': un nuovo kit di sviluppo per smart card contactless!
Date un po' un'occhiata a www.edsim2000.com , per 149,95 sterline, che sono
circa 450.000 lire, hanno in vendita un sistema di sviluppo per smart card
contactless veramente ben fatto. Il prezzo, pero', e' troppo alto per me...
Va bene, andiamo avanti con il discorso che avevo lasciato in sospeso l'altra
volta, adesso posso andare avanti tranquillo, sono le 6 del pomeriggio, non ho
nulla da fare stasera, la ragazza non c'e', posso scrivere fino a quando ne ho
voglia!
Ah, cazzo!
Sullo scorso articolo ho commesso un errore: ho detto che avrei parlato delle
smart asincrone piuttosto che delle sincrone, ma mi sono incasinato con le A:
parlo delle Sincrone, non delle Asincrone.
Corretto questo piccolo errore, andiamo a vedere di preciso come funziona in
byte il trasferimento di dati da card a lettore e viceversa, mi sa che di
temporizzazioni in millisecondi ne avete le palle piene, cosi' adesso vi rompo
le palle con i bit ed i byte :-]
/\Il Protocollo
\Descrizione generale
Allora, a questo punto avete capito cosa fanno e come fanno una card ed un
lettore a comunicare secondo le temporizzazioni stabilite, adesso vediamo
che pacchetti di dati si mandano. Una card che viene inserita in un lettore
subisce sempre un RST (ReSeT), in modo da determinare che card sia, e risponde
con un ATR (Answer To Reset), logicamente. Solo che l'ATR non ha una lunghezza
predefinita o standard, infatti puo' essere compresa fra 4 bit (come le schede
di memoria) ed i 32 bit. Tutto e' lasciato libero: ogni ditta puo' creare un
ATR della lunghezza che vuole, ma entro il minimo di 4 ed il massimo di 32 bit.
Questo da' gia' modo di determinare il produttore della card a seconda dell'ATR,
no? Dato che vi ho detto che e' usato il protocollo seriale, penso non ci siano
dubbi o domande, voglio solo ribadire che i due livelli possibili (0 oppure 1)
sono denominati Z (mark) oppure A (space).
\ETU e caratteri
Per quel che riguarda il baud rate, ovvero bit al secondo, in questo ambito
viene rimpiazzato con la misurazione in ETU. L'ETU non e' altro che l'acronimo
di Elementary Time Unit e non e' una misura fissa come puo' essere un secondo
o un metro, ma e' una misura dinamica che si ottiene dividendo la frequenza
del clock in MHz (CLK) per il numero 372. Infatti una smart quando fa un ATR
deve emettere un bit ogni ETU. Supponendo che la nostra smart abbia un micro
con clock semi standard (ovvero con clock di 3.5712 oppure 4.9195 MHz, che
sono i piu' diffusi e meno costosi) avremo un bit ogni 0.0096 secondi oppure
ogni 0.0132 secondi. Adesso che sappiamo che un bit dura un'ETU, un byte
(detto carattere) durera' 1 bit di start (detto TS), 8 bit di dati ed 1 bit
di parita', ovvero 10 ETU. Dopo l'invio e/o la ricezione di ogni carattere
(byte) c'e' una pausa standard di 2 ETU per elaborare le informazioni.
Durante questa pausa entrambi i dispositivi (card e lettore) sono in stato Z.
Per vedere se un dispositivo (sia card che lettore, indistintamente) sta
trasmettendo viene fatto il check della linea di I/O ogni 0.2 ETU ed appena
una trasmissione inizia viene mandato un carattere che ne notifica l'avvio.
Per convenzione il primo carattere inviato dalla card al lettore dopo l'ATR
e' la base di ogni futura comunicazione, cioe' e' il tipo di 'convenzione' di
invio dati; possono esserci due 'convenzioni', denominate convenzione diretta
oppure indiretta. Quella diretta prevede che il bit di start sia 1 (stato Z),
quindi il bit 0 assume lo stato A e bit meno significativo (LSB) per primo
(3B in esadecimale). In quella inversa invece il bit di start e' 0 (stato Z),
il bit 1 assume lo stato A ed il bit piu' significativo (MSB) per primo
(3F in esadecimale).
Capito questo rimane da comprendere il meccanismo che impedisce la perdita
di dati durante la transazione. In sostanza e' semplicissimo: si basa sul bit
di parita'! Infatti sia la card che il lettore prima di inviare un carattere
controllano i bit in stato 1 e se sono pari il bit di parita' e' 0, se invece
i bit a stato 1 sono dispari il bit di parita' saro' 0. Quindi se l'unita'
ricevente si trova un carattere con gli 1 dispari ed il bit di parita' a 1 sa
che la trasmissione e' sbagliata e quindi rifiuta senza problemi. E' banale,
veloce ed efficace: cosa volete di piu'?
Adesso addentriamoci nei bit della prima trasmissione, ci sono delle cosette
interessanti...
\I bit di ATR
I primi bit emessi dalla card servono al lettore per determinare una marea di
cose, non solo il protocollo! Servono per stabilire:
- valore di voltaggio in scrittura
- valore di amperaggio in scrittura
- velocita' di comunicazione
- trasmissione forzata di un carattere per volta (character mode)
- trasmissione forzata di piu' caratteri per volta (block mode)
- ETU di pausa fra trasmissione maggiori di 2 (guard time), ma mai superiori
a 12 ETU, di default e' 0
Schemino, che almeno ci si capisce meglio!
Reset
| _______________________________________ ___ _______
| | | | | | | | | | | | | | | | |
'-->| TS| T0|TA1|TB1|TC1|TD1|TA2|TB2|TC2|TD2| ......... | T1| ... | TK|TCK|
|___|___|___|___|___|___|___|___|___|___| |___| |__ |___|
TS : bit iniziale
TO : bit di definizione della convenzione (diretta/indiretta)
TAi : bit per l'interfaccia [determina voltaggio/amperaggio,codici FI,DI]
TBi : bit per l'interfaccia [determina velocita' futura di trasmissione
codici II,PI1]
TCi : bit per l'interfaccia [determina character/block mode,codice N]
TDi : bit per l'interfaccia [determina ETU di pausa,codici Yi+1, T]
T1-> TK : storico dei bit (massimo 15, una sorta di CRC)
TCK : bit di stop
Lo storico dei bit manda info generiche quali il prduttore della card, il
tipo di chip inserito, il tipo di ROM a bordo, lo stato della card
(quest'ultimo se la card e' del tipo 'a scalare'). Il ritardo massimo
ammissibile fra 2 bit (detto IWT, Initial Wait Time) in questa fase (e solo in
questa) e' pari a 9600 ETU. Se il ritardo supera questa soglia il terminale
terra' la card in sospeso fino al 40.000 ETU, dopodiche' resettera' la card e
riprovera'. Direi che in pochi bit c'e' gia' un mondo!
/\Il sistema operativo
\Risorse disponibili
Beh, si e' detto che le smart card hanno a bordo un micro, giusto? Hanno anche
a bordo una ROM ed una RAM quindi ci sono i presupposti per non stupirsi della
presenza di un sistema operativo...
Non c'e' logicamente nulla di assimilabile ad una shell oppure ad una GUI, ma
l'ISO parla di file, file system e di directory, quindi siamo a casa!
Ok, vediamo bene che risorse sono disponibili:
32 Kbyte ROM (assimilabile al bios)
1 Kbyte di RAM (assimilabile alla ram che avete sul vostro pc)
8 Kbyte di EEPROM (assimilabile al vostro hard disk)
Non molto, vero? Pero' funziona bene e l'enorme sviluppo che hanno le card
testimonia che le poche risorse a disposizione sono sufficienti a fare gia'
qualcosina...
Oddio, tenete presente che queste sono le risorse disponibili in una card ad
uso generale, in giro ci sono anche card con 256Kbyte di EEPROM oppure con
128Kbyte di ROM, lo scopo di questo articolo non e' analizzare TUTTE le card,
ma solo la loro struttura, quindi come esempio va piu' che bene!
\Filesystem
Adesso tenete bene a mente le corrispondenze elencate qui di seguito perche'
d'ora in poi usero' solo queste:
MF : Master File = root
DF : Dedicated File = directory
EF : Elementary File = file
Adesso i 4 comandamenti base per chi scrive sw per smart card:
1- In una card ci puo' essere un solo MF, ma puo' contenere sia EF che DF.
2- I DF possono essere nidificati (ma lo sono raramente).
3- I DF nidificati devono avere nomi diversi fra di loro e mai uguali agli EF
in essi contenuti.
4- Gli EF devono avere nomi diversi fra di loro se contenuti nello stesso DF.
Per i nomi si segue la convenzione di usare 2 byte in esadecimale che si
chiamano F_ID oppure FID che sta per File IDentifier. MF ha nome 3F00 per
compatibilita' con vecchie schede e il nome FFFF e' riservato per applicazioni
future ritenute utili secondo l'ISO.
Per aiutare la classificazione dei DF ci sono gli A_ID oppure AID, acronimi di
Application IDentifier, diciamo che sono una specie di descrizione dei DF.
Possono essere di lunghezza compresa tra 5 e 16 byte. Gli AID non sono
arbitrariamente attribuibili da chi programma la card, ma sono stabiliti anche
loro dall'ISO... purtroppo pero' su questo tipo di informazioni non sono
ancora riuscito a mettere le mani, appena lo faccio vi informo, mentre se ci
riuscite voi contattatemi via e-mail! Dicevamo... gli AID o A_ID servono ad
identificare il paese di provenienza della card, il numero di serie della
stessa e la descrizione dei permessi dei DF. Bingo! Capite? Se un DF ha
un'AID che permette solo la scrittura o non la lettura, siete capitati nel
posto giusto, ovvero dove risiedono le informazioni che la EEPROM passa alla
ROM per l'elaborazione dei dati. Nelle card predisposte per piu' utilizzi
(carte che permettono di pagare, ottenere sconti e segnare premi fedelta',
come in uso in molti supermercati in Inghilterra) ogni DF corrisponde ad una
specifica applicazione ed il suo accesso e' limitato ad una sola funzione per
volta.
Passiamo oltre. Per quel che riguarda gli EF la loro gestione e' lasciata
all'utente, tipo la creazione di una rubrica telefonica e similari.
Piccolo particolare molto utile: tutti i settori della card, compreso l'MF
possono essere settati in modalita' read-only e genericamente solo gli EF ed
alcuni DF deputati alla gestione degli EF che crea l'utente non sono in
read-only. I permessi di lettura/scrittura sono settati direttamente dal
produttore in maniera irreversibile...
\Accesso a MF, DF ed EF
Adesso che sapete cosa sono magari e' bene capire come vi si accede. Tutti i
permessi di accesso/lettura/scrittura ad un DF oppure ad un EF sono chiamati
FCI (File Control Information), ma bisogna prima capire il livello di
sicurezza richiesto dall'applicazione prima di modificare i permessi con
l'equivalente di chmod... Infatti se avete una card progettata per
un'identificazione a bassa o nessuna sicurezza (ovvero dove non dovete
pagare, ma solo presentare le vostre generalita', tipo una tessera-sconto) il
lettore puo' accedere alla scheda senza identificarsi come accreditato, in
quanto non e' richiesta l'identificazione. Invece per applicazioni a
media-alta sicurezza (telefonini, paytv, carte di credito) il terminale deve
sempre identificarsi. Per fare cio' viene usato un protocollo di
identificazione chiamato challenge protocol. L'uso di questo protocollo puo'
essere invocato sia dalla card che dal lettore in maniera simmetrica e si
basa sulla reciproca identificazione. In pratica il richiedente del challenge
genera una stringa di numeri (chiamata session key) e la memorizza nella RAM,
poi invia all'altra parte. L'altra parte, quando riceve la stringa la elabora
secondo il suo algoritmo interno e la rimanda indietro modificata. A questo
punto il richiedente del challenge sottopone la stringa in arrivo al suo
algoritmo interno e confronta il risultato dell'elaborazione con il numero
che ha in RAM. Se i due numeri corrispondono, la trasmissione dei dati e'
autorizzata, altrimenti viene disconnesso.
Un rapido esempio fittizio: io sono la card e \sPIRIT\ e' il lettore. Se mi
viene chiesto da \sPIRIT\ un challenge io chiedo... la lunghezza del suo cavo
telefonico diviso l'altezza della sua prima ragazza. Se \sPIRIT\ e' davvero
chi dice di essere mi dara' un numero X che corrisponde a quello che gia'
conosco, se non e' lui mi dira' al massimo la lunghezza del cavo...
Che cazzo di esempio, grazie a \sPIRIT\ che inconsapevolmente si trova tirato
in mezzo...
Beh, provate a pensare a \sPIRIT\ come al decoder della vostra tv via
satellite e vedrete che la cosa assume un altro aspetto, no? La card sa come
trattare i dati codificati, il decoder da solo no. Se voi analizzate i
segnali in ingresso ed in uscita in teoria avete lo schema di funzionamento
del micro, ma solo in teoria :-[
Questo esempio va bene per la maggior parte delle card, tranne quelle di
credito che sono in standard EMV (Europay-Mastercard-Visa) e quindi usano una
metodologia di accesso ai dati leggermente diversa.
Bene, adesso passiamo alle cose carine, ovvero a come provare a vedere come
si puo' forzare una card...
/\ Spippolare con le card...
\Premessa
Tutti i metodi che trovate qui esposti sono stati provati o da me o da
esperti di sicurezza delle ditte produttrici.
Se poi voi trovate un altro modo, anche se non funziona, sarei interessato a
venirne a conoscenza, tenetemi presente!
\Test di pre-commercializzazione
Come ho gia' detto, alcuni (la maggior parte, a dire il vero) di DF e di EF
sono read only, ma la loro funzionalita' (relativa all'accesso ai settori
della card ed allo storage dei dati) e sopratutto l'OS delle card deve prima
essere testato per non immettere nel mercato carte che non funzionano come
richiesto. Per questo motivo in fabbrica le card sono ancora accessibili sia
in lettura che in scrittura e solo dopo i test viene settata questa modalita'
in maniera irreversibile. Infatti le card hanno al loro interno una sorta di
fusibile che si chiama protection fuse il quale, una volta 'bruciato' non e'
piu' possibile ripristinare. Le card che non hanno questo fusibile bruciato
sono chiamate appunto test card e le hanno pochissimi tecnici che devono
testare il funzionamento di decoder nelle fabbriche di produzione di questi
ultimi.
\Ripristino del fusibile
Dato che l'area interessata alla bruciatura del fusibile e' relativamente
grande, se qualcuno ha l'abilita' tecnica e le attrezzature necessarie
potrebbe tentare una riconnessione, no? Forse tempo fa era possibile, ma
adesso sono stati implementati fusibili multipli e multistrato, ovvero su 2 o
piu' livelli del silicio del chip, quindi dimenticatelo...
Se per caso riusciste nella non facile impresa, ve la dovrete anche vedere
con i codici della EEPROM che creano un'ulteriore protezione software alla
card...
\Sniffare l'assorbimento di corrente
Questo ve lo potete dimenticare da subito. Infatti il micro assorbe sempre lo
stesso amperaggio e lo stesso voltaggio sia che processi dei dati, sia che non
faccia nulla. Quindi dimenticatevi il tester in millivolts o in milliampere:
tempo perso.
\Leggere la EEPROM
Beh, in linea del tutto teorica se levate i contatti dorati, accedete al chip
e levate la copertura dello stesso potete collegare la EEPROM ad un
programmatore e copiarvene tutto il contenuto. Qui il metodo di riuscita e'
sicuro al 99%. Peccato che sia stato previsto anche questo e di conseguenza le
EEPROM hanno dei registri di accesso molto, ma MOLTO, confusi per cui dovete
avere altrettanta pazienza. Inoltre questo metodo puo' diventare presto
obsoleto dato che in un prossimo futuro le card verrano sempre piu' spesso
prodotte con la tecnologia FeRAM che eliminera' la EEPROM. Le FeRAM
(Ferroelectric RAM) sono RAM silicio-metalliche che non perdono dati se viene
a mancare l'alimentazione e sono circa 3500 volte piu' veloci in
lettura/scrittura, consumano e costano pure meno.
\Leggere il silicio
E qui si fa sul serio. Procedete come per il punto sopra, ma non collegate
nulla alla EEPROM. Piuttosto procuratevi un buon microscopio e guardate bene
la ROM. Con un po' di culo potrete determinare lo stato logico (0 oppure 1)
di tutta la ROM. Logico che avete il 50% di possibilita' di sbagliare :-]
Purtroppo riuscirete a leggere solo il primo strato, perche' gli altri sono
tutti sul fondo e a meno di non sezionare il chip non li leggerete. Tuttavia
sezionando il chip si'!
\Sondare la RAM
Dimenticatevi tutti i tool che usate abitualmente...
Usate piuttosto delle sonde per cariche elettriche molto sensibili e mani
ferme. Servendovi di questo metodo potete sapere che minimo potenziale c'e'
in una determinata zona di silicio e da li' risalire ai livelli logici,
quindi al programma.
Se non fosse che sulla RAM da poco tempo e' depositato uno strato di
metalizzazione che ha lo scopo di fermare e dissipare le differenze di
potenziale, questo sarebbe un ottimo metodo :-[
\Rimozione chimico-chirurgica della metallizzazione
Impossibile, senza mezzi termini. Oddio, se mi smentite, meglio, ma nel
99.998% dei casi e' come ho detto. Anzi il coperchio metallizzato lo levate,
ma i contatti che ci sono sulla parte che tocca il silicio che fine fanno?
Si levano pure loro, quindi il lavoro e' inutile. Tenete presente che sono
anche operativi da 1 anno circa i sensori della metallizzazione, ovvero se i
sensori non trovano la metallizzazione il chip resta inibito.
\Underclocking
Ok, tutti sappiamo cosa e' l'overclocking, vero? Bene, immaginate
l'operazione inversa...
Cosa ottenete? La possibilita' di seguire passo passo tutti i segnali
all'interno dei circuiti :-]
Siete un pochino distratti... Gli omini dell'ISO hanno pensato pure a quello
e quindi se il clock scende sotto i 700Khz c'e' un RST e tutto il
divertimento sfuma prima di iniziare. Stessa cosa vale per la sovra/sotto
alimentazione...
/\Postfazione ovvero chiacchere ed appunti in rilassatezza...
Adesso che bene o male avete capito come sono e come funzionano le card
ritengo carino dirvi un paio di cose che potrebbero interessarvi, diciamo che
sono piccoli flash su cosine e progettini interessanti.
Oltre alle card monoservizio esistono anche card multiservizi (ovvero piu'
usi della card con piu' apparecchiature) che quindi incorporano al loro
interno diverse tipologie e metodologie di connessione. Per esempio la Visa
ha in progetto di produrre una card che permetta i pagamenti come avviene
adesso ed inoltre contenga sia dati personali (patente, documenti in genere)
sia dati medici (oltre al banale numero della mutua, al quale siamo oramai
abituati, anche tutte le nostre cartelle mediche) tramite applicazioni basate
su Java costruite da terze parti. Tutti i programmi Java scritti per
funzionare con le card sono chiamati con poca fantasia 'cardlet' e tutte le
card che si basano su Java usano delle runtime chiamate JCRE
(Java Card Runtime Environment) che si occupano totalmente della gestione
della carta. Le specifiche sono emanate dal JCF (Java Card Forum) e le card
con Java a bordo sono reperibili sul sito della GemPlus (www.gemplus.com) e
si chiamano GemXpresso e GemXplore 'Xpresso. Attualmente il progetto pilota
per questo tipo di applicazioni e' quello dell'Universita' del Michigan dove
60.000 persone (fra studenti, insegnanti e personale supplementare) e' in
possesso di una card ibrida magnetica-chip che permette sia l'identificazione
personale sia i prelievi bancari ed una serie di servizi supplementari tipo
fotocopie gratuite, accesso alla biblioteca, iscrizione agli esami e molto
altro ancora.
C'e' da aggiungere che anche lo Zio Bill ci sta provando con le card ed ha
sviluppato un suo OS chiamato SCW (Smart Card for Windows), ma non e' affatto
usato, Java pare molto piu' comodo (e non va in crash ogni 5 minuti... Pensate
un po' alla vostra carta con SCW a bordo, volete fare un prelievo per andare a
mangiare fuori con una bella topona appena rimorchiata e va in crash il
bancomat... Cristo, che terrore...). Se poi volete proprio usare SCW tenete
presente che potete programmare le card con tutta la suite di Visual Studio
usando l'apposito Smart Card for Windows Toolkit for Visual Basic 6.0.
Esistono anche estensioni specifiche di XML per le smart card che si chiamano
SmartX e servono per sviluppare applicazioni web-based con l'uso di smart
card, ma non ho ancora avuto tempo di leggermi bene la meccanica di
funzionamento.
Esistono anche associazioni che riuniscono produttori di card o di
applicazioni e sono tutte piu' o meno note. La meno conosciuta (ma che a mio
avviso va seguita con molta cura) si chiama M.U.S.C.L.E. (ovvero
Movement for the Use of Smart Card in a Linux Environment). Sul loro sito,
locato a http://www.linuxnet.com/docs.html, potete trovare dei documenti
molto interessanti come la documentazione sulle API considerate valide dal
consorzio PC/SC (formato nel 1996 da Bull, Gemplus, Hewlett-Packard, IBM,
Microsoft, Schlumberger, Siemens Nixdorf Information Systems,
Sun Microsystems, Toshiba e Verifone per l'uso delle smart card come
integrazione ai sistemi operativi) sia in ambito Linux sia le specifiche
originali di Microsoft. Oltre a cio' troverete anche diversi lettori e
scrittori di smart card e smart card vergini o con sistema crittografico gia'
precaricato.
Mah, che dire, la mia opinione e' che probabilmente il nostro futuro sara'
una tastiera con lettore di una o due smart card integrato. Modelli simili
gia' esistono (e mAyhEm che era con me allo SMAU ha visto come sono rimasto
di sasso a vederle dal vivo) prodotti dalla Cherry Keyboards (www.cherry.de).
Date un pochino un'occhiata al modello 6700 (reader singolo a standard ISO)
oppure a tutta la famiglia G-81, sia le 7000 che le 8000. Beh, sono tastiere
con 2 lettori di card ID-I oppure 4 in formato ID-000. Sono davvero una
figata, si possono leggere davvero tutte le card (sincrone ed asincrone, a
standard ISO e non, AFNOR... insomma: TUTTO), pure le card mediche tedesche
(notoriamente difficili da maneggiare). Piccola nota carina: il loro catalogo
completo e cartaceo e' disponibile gratuitamente su richiesta. Una valida faq
sulle smart card in generale la trovate on line su
http://www.ioc.ee/atsc/faq.html .
/\ Ma allora cosa si puo' fare?
Un sacco di cose... Davvero: un sacco.
Adesso che sapete come funzionano dovete girare un po' in rete, creare dei
programmatori, costruirli, provarli. Per gli smanettoni le card sono l'ultima
frontiera del divertimento!
I lettori che ci sono in commercio costano troppo, conviene costruirsene uno,
qui di seguito vi incollo un po di siti che se ne occupano, a voi non resta
che metterci il circuito stampato, il saldatore ed i componenti!
Come bonus ci metto pure i link piu' utili che ho sfruttato sull'argomento,
buona ricerca!
- BO LAVARE'S SMARTCARD SECURITY PAGE
http://www.geocities.com/ResearchTriangle/Lab/1578/smart.htm
- Card Europe Outputs & Articles - Standards
http://www.cardeurope.demon.co.uk/stds.htm
- CISA Security Products, Inc.
http://www.repla.com/
- Contactless Integrated Circuit(s) Cards
http://www.geocities.com/SiliconValley/Garage/9241/wg8.html
- CSI (Card Services International)
http://www.csi.ie/
- Cypherpunks Tonga
http://www.cypherpunks.to/
- Database card www.guarango.com
http://www.guarango.com/database/index.htm
- Datagrams
http://www.datagrams.com/
- Dumb Mouse
http://cuba.xs4all.nl/hip/dumbmouse.html
- EPSILON ELECTRONICS
http://www.eps.no/index.htm
- ETSI - Standardizing Telecommunications Products and Services
http://www.etsi.org/
- FAQ for alt.technology.smartcards
http://www.ioc.ee/atsc/faq.html
- Goran Vlaski's Software Page
http://vlaski.virtualave.net/
- GSM World Home of the GSM Association
http://www.gsmworld.com/
- Home of Decrypt
http://www.thoic.com/decrypt/
- M.U.S.C.L.E. Linux Smartcard Documentation
http://www.linuxnet.com/docs.html
- More smart secutiry links
http://home.earthlink.net/~papousa/security.html
- PC Smart Cards - Home page
http://www.cyberflex.austin.et.slb.com/cyberflex/pcsc/pcsc.html
- PC-SC Workgroup
http://www.smartcardsys.com/
- Phonecard, hacking, telecard, cloning, phonecard cracking news, clubs,
programs and more
http://members.tripod.com/telecardnews/index.html
- Ronny's Sim-Pic
http://simpic.tele-servizi.com/
- Schema mk13here
http://www.mk.jnet.it/zips/schema.zip
- SCHLUMBERGER - Smart Cards & Terminals
http://www.slb.com/smartcards/
- SM Range
http://www.gis.co.uk/products/sm/index.htm
- Smart Card Developer's Kit
http://www.scdk.com/
- Smart Card Forum Home page
http://www.smartcrd.com/
- Smart Card Hacking Index
http://cuba.xs4all.nl/~tim/sc-hp/index.html
- Smart Card Industry Association Website
http://www.scia.org/
- Smart Cards & Systems Weekly Volume 4 - Issue 18
http://www.cardshow.com/scs/v4.i18/
- Smartcard Developer Association
http://www.scard.org/
- Techfreakz.org
http://www.techfreakz.org/main.htm
- The Smartcard Gallery
http://homepages.pathfinder.gr/hitec/sat/gallery.htm
- The Telecard Crackers Club Recruitment Site
http://telecracks.freeservers.com/entrypage.htm
- BasicCard an inexpensive basic programmable smart card - program your own
smart card
http://www.basiccard.com/
- Leading Edge Technology
http://let.cambs.net/
- Plus Technologies Italia
http://www.plustechnologies.it/
- Smart Cards vendita lettori e card (Crownhill)
http://www.crownhill.co.uk/itmidx6.htm
Oltre a tutta questa roba potete dare anche un'okkiata a
http://neworder.box.sk per altre interfaccine carine oppure a
http://www.digitalsin.org dove vendono molte interfacce gia' fatte e a prezzi
molto contenuti, contanto il lavoro richiesto per farle e le bestemmie che
tirano quando non funzionano...
Con questo mi pare di aver detto tutto, voglio solo ringraziare tutta la
redazione di BFi che mi ha permesso di esprimermi in queste pallosissime
forme senza mai inkazzarsi, salutare e ringraziare Buttha per la sua
consulenza, dare un bacino a Mara che mi tiene i neuroni vivi ed un grosso
saluto a tutti i fratellini SpiPPoLaTorI.
Ok, ho finito davvero e per il momento mi ritiro in disparte; per chi ha
necessita' di chiarimenti sono reperibile mandando una mail a
rigormortem@spippolatori.com, ma non chiedetemi di farvi una card per vedere
Stream...
Salutoni.
==============================================================================
--------------------------------[ EOF 19/28 ]---------------------------------
==============================================================================
