Copy Link
Add to Bookmark
Report
BFi numero 11 anno 6 file 14 di 15
==============================================================================
------------[ BFi numero 11, anno 6 - 23/12/2003 - file 14 di 15 ]------------
==============================================================================
-[ HACKiNG ]------------------------------------------------------------------
---[ C.0.G.E.S.: CHiAVETTE 0TTURATE Gi0i0SAMENTE ESTRATTE & STUDiATE
---[ dev-14, 27/11/2002
-----[ Cavallo de Cavallis <cavallo@s0ftpj.org>
DreadNought <dreadn@s0ftpj.org>
Chapter 000 : (ANAL) INTRODUCTION
Eccoci qui !
Vedo gia' lo stupore nei vostri occhi, non ve l'aspettavate, eh ?
Da quanto tempo non si leggeva un articolo scritto dall'equino che non fosse
la solita posta ?
Beh, visto la mutazione da bfi a bfi-dev e la scarsita' di e-mail interessanti
cui rispondere, mi e' sembrato il caso di partecipare in prima persona, e lo
faccio con questo articolo scritto a quattro mani (o a due ani, se preferite)
con l'amico DreadN.
Lo schema degli articoli di BFi (ma l'abbiamo inventato noi ? boh, non ho
voglia di controllare) ha ormai fatto la storia, con l'introduzione a base
di "consumi e musica ascoltata". In realta' mi sono rotto le palle di questo
schema, quindi non ci saranno consumi e la musica non sara' quella "ascoltata"
ma quella che (con il titolo) meglio descrive il capitolo.
TADAAAAA (effetto sonoro disponibile solo nella versione multimediale)
L'articolo e' stato diviso per comodita' in 2 parti, DreadN, in qualita' di
Mac-Gyver della situazione (tu invece suxxi NdDreadN), vi parlera' degli
aspetti hardware e "manuali" (hemm... no dai quelli no che mi
vergogno NdDreadN), mentre io mi occupero' della parte bondage e fistf.. ehm,
no, volevo dire, della parte software e della analisi dei dati.
NB: Le immagini jpg che trovate allegate in attachment/coges.zip sono "di
supporto" per far capire meglio alcuni passaggi. Sfortunatamente, dato che
sono state "scattate" usando il mio SCANNER (non sto scherzando, abbiamo usato
veramente uno scanner visto che non avevamo una fotocamera digitale per le
mani :D), non possono mostrare il procedimento di apertura e quindi sono utili
solo per dare un'idea di alcune cose. Speriamo vi siano comunque di aiuto.
[=- -=][=- -=][=- -=]
PART I - Author: DreadN
Chapter 001 : Ozzy Osbourne - No Easy Way Out
ovvero "Non ci passa un cazzo"
"You've got to tell me it's over now
I'm trapped inside of a dream
The crushing weight on my shoulders now
Is bearing down and it seems
There's just no easy way out
No easy way out"
Prova 1,2,3...Prova... OK, mi sentite? Si? Bene, allora passiamo ad analizzare
la parte tecnica su come diamine tirare fuori i dati da queste benedette
(maledette, direte dopo averci smanettato un po') chiavette.
Le chiavette sono contactless, ovvero non mostrano alcun contatto metallico
all'esterno, ma lo scambio di dati avviene tramite un campo magnetico fatto
vibrare su due frequenze differenti. Una per dare "portante" al circuito che
ovviamente non ha la batteria e una per leggere o scrivere dati all'indirizzo
desiderato. Il primo segnale e' quello del "clock" (tra virgolette perche' la
eeprom se non erro e' asincrona), catturato da un circuito oscillatorio e
trasmesso sul pin di clock e alimentazione della EEPROM, l'altro segnale viene
catturato da un'alto circuito oscillatorio con un'altra induttanza e un'altro
transistor; tramite quello i dati passano dalla chiave al lettore del
distributore e viceversa.
Vediamo ora la struttura interna del PCB (in formato SMD) della chiave tramite
l'aiuto di un mio caro amico che ha uno studio dentistico e mi ha gentilmente
fatto utilizzare l'impiantino RWG (sensore CCD che prende i raggi X un po'
come quello della macchina fotografica digitale). Dopo essermi irradiato un
po' i testicoli (potevi irradiarti anche il cervello chissa' mai che diventavi
un po' piu' intelligente NdCava) ho partorito 3 jpeg.
Nella jpeg si notano subito le due induttanze grandi ai lati, i due transistor
in centro (ricordate elettronica? Quelli che hanno Gate, Source e Drain... :))
e un po' di componenti sparsi in giro, tra cui un diodo Zener a destra in alto
collegato al piedino 7 [WriteProtect] (date un occhio all'altra jpeg per la
piedinatura) per evitare overvolt alla EEPROM. Penso che i vostri occhi da
hackers gia' siano attratti con un bel [Target: LOCK] dalla EEPROM in alto a
sinistra. Quella EEPROM non e' niente di speciale, e' di un formato molto
standard, a scapito della scritta -COGES07- che trovate su alcune, ed e' ben
piu' conosciuta come 24LC02, dove 24LC specifica il tipo di EEPROM e 02
specifica 2Kbit (2048bit) di dati contenuti all'interno.
Ora voi direte: perche' non apriamo la chiavetta e andiamo subito a smanettare
dentro al circuito? Troppo facile sarebbe!! Infatti se tentate di aprire la
chiave, qualche grammo di vetriolo schizzera' dalla prima fessura che farete e
vi colpira' immediatamente sul vostro occhio che piu' utilizzate con una
precisione millimetrica, scaldando l'acqua del liquido lacrimale in
superficie fino a far esplodere la vostra piccola orbita provocandovi dolori
atroci, oltre che la parziale cecita'.
Come ho fatto io dunque ad aprirla evitando questo trabocchetto? (pirla!, usa
gli occhiali protettivi, direte voi...) Innanzitutto vi prendevo in giro, non
c'e' alcun acido! solo 1.8 grammi di fulminato di mercurio che quando
penetrate la superficie con un cacciavite o una lama non troppo delicatamente,
esplode staccandovi l'indice o al massimo anche il medio, nessun problema
quindi. Ma no che scherzo! (qualcuno ora viene qua e mi suona di mazzate...)
(Io Io Io !! NdCava)
L'unica cosa che protegge il circuito e' una cazzutissima resina epossidica
monopolimerizzante, termoindurente. "E allora che ci vuole??" direte voi.
Occorrente per riuscire ad avere un PCB parzialmente pulito :
- Cacciavite a lama con punta da 4x0.5mm circa
- Cacciavite a lama con punta da 3mm fine e bella affilata
- Vite X metalli da 3x20mm a testa e punta piatta
- Vite X metalli da 3x60mm a testa e punta piatta
- Una Morsa da banco
- Attrezzi per la manicure
- 33cc di solvente (Cloroformio, Trielina, Acetone, Sverniciatore sembrano
essere i piu' utili, ma anche la salamoia del Giudice Morton di Roger Rabbit
ha un suo perche')
- Un vasetto di vetro da marmellata da 250gg ai mirtilli Equo-Solidale
(non era meglio Equino-Solidale ? NdCava :))
- 2 Bei maroni grossi
- 72 ore di tempo, di cui almeno 1h da dedicare al lavoro per farlo bene
[=- -=]
Chapter : 010 Megadeth - Symphony of Destruction
ovvero "come ti sventro la chiave"
"Acting like a robot,
Its metal brain corrodes
You try to take its pulse,
Before the head explodes
Explodes..."
[a] Togliere il cappuccio della chiave, facendo leva con il cacciavite da 4mm
tra la finestrella rettangolare grigia e la parte di plastica colorata dalla
parte dell'aggangio per l'anello da portachiavi.
(Questo perche' il cappuccio, pur muovendosi leggermente, e' saldato
(penso a ultrasuoni) nel punto [*], ergo bisogna spaccare NdCava)
(chettiediti le mie immagini in ASCII art? NdDreadN)
[Fig.1]
------------------------------------------------------------------------------
<-<- // <- Lama del Cacciavite [spingete nella direzione
// della freccia con
// movimento antiorario ]
// Plastica grigia ----.
.---------.//_____.-------.________________________________ |
|| [*]/----------------------------------------------\\ <-|
|| |/ \ [Resina] +====+ +--[ ]--+ || |
|| / ==============[PCB]=========== || |
|| -------------------------------------------------||<-°
°-------------------------°¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Cappuccio ^^^
------------------------------------------------------------------------------
[B] Ora che avete la chiave aperta dietro potete vedere la resina colata
dentro e farvi anche una idea di quanto sia dura e allo stesso tempo
inattaccabile con il calore (Quella puttana! NdCava).
Ora prendete la chiave, bloccatela nella morsa lateralmente e prendete il
cacciavite piccolo (da 3mm), puntatelo sul frontale della chiave, nel foro di
iniezione dello stampo fatelo girare con forza, fino a che non consumate la
plastica truciolo dopo truciolo e arrivate fino alla resina.
[Fig.2]
------------------------------------------------------------------------------
_____________________________________________________
----------------------------------------------------\\
\ [Resina] +====+ +--[ ]--+ || ____________
/ ==============[PCB]=========== |||
----------------------------------------------------|| ¯¯¯¯¯¯¯¯¯¯¯¯
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ Puntando il cacciavite
nel foro di iniezione
fatelo girare come la
punta di un Trapano
------------------------------------------------------------------------------
[c] Ora che avete fatto il buco infilate la vite da 3x20mm incastratela dentro
e mettete vite piu' chiave dentro la morsa, tenetela con 2 dita per non farla
scappare e stringete piano piano la morsa fino a che non staccate la resina
dalla plastica dall'interno e smuovete il tutto.
[Fig.3]
------------------------------------------------------------------------------
.------..-------. .--------. <- Ganascia (Uee' Ganassa!:) NdCava)
/ || |===||| \
/ |°-------° | \
/ .---° ^^ °---. \
/ / ^^ Vite \ \
/ / Chiave \ \
------------------------------------------------------------------------------
[D] Adesso, a mano, con la vite piu' lunga estraete tutto il blocco di resina
bordeaux (minchia sti francesi a scrivere sono proprio storti...) spingendo
sempre dal buco fatto al punto [b]
/* se un articolo non ha un po' di codice in C non e' un articolo */
// Salamoia.c
#include <PCB.h>
#include "TuaMamma.h"
int PCB_Clean(Coges *Chiavetta)
{
int n = 24;
while ((PCB.EEPROM != Pulito) && (PCB.Diodo.Zener != Pulito))
{
[E] Versate il solvente nel vasetto di vetro, ne basta un dito (ottima unita'
di misura vero?) (Nel tuo caso sono meglio due di dita, indovina dove...
NdCava) ci sbattete dentro il blocco PCB-resina e chiudete il tappo in modo
che non vi intossicate durante la notte, visto che i solventi evaporano bene.
Se usate il cloroformio abbiate cura di non svenirmi sul vasetto, oppure
di ammazzarvi lasciando il vasetto sul comodino, grazie!. Mettete il
vasetto all'aperto, magari fuori dalla finestra, ma lontano dalla luce
solare, perche' altrimenti invece del solvente trovate un liquido che dopo 20
ore di irradiazione e' diventato qualcos'altro (La Salamoia di cui sopra?
NdCava) Attendete almeno n ore. (come sei preciso... NdCava) (pirla, n e' la
variabile sta nello scope di questo ciclo! NdDreadN)
[f] Ora aprite il vasetto, estraete il blocco PCB-resina e dovreste vedere
che la resina almeno all'esterno e' diventata piu' morbida: togliete con un
attrezzo da manicure tutto quello che potete nella zona EEPROM senza togliere
nulla nella zona delle induttanze, anche perche' sono coperte di plastica
(oltre che mascherate da resistenze) e come il resto della resina si fondono,
se si dovesse fondere anche la vernice isolante attorno alle spire...
... Ciao Ciao chiave!
if (PCB.Induttanze == QuasiFuse) return -1;
n = (n>=4) ? (n-8) : 3;
} // End while
return 1; } // End PCB_Clean
[G] Se tutto e' andato bene ora avete il PCB bello pulito come nella jpeg che
vi abbiamo allegato con la EEPROM, bello scoperto e adatto a farci una
saldatura per un connettore.
[=- -=]
Chapter 011 : Iron Maiden - The prophecy
ovvero "possibilita' presenti e future"
"I'll take your life in my hands
Your fate your fortune's in my visions
Heed what I say and you'll see
What will be
Please listen to me"
Tutto questo casino non l'abbiamo mica fatto per vedere come e' fatto il
circuito e fargli una foto no? Ovviamente vogliamo fare qualcosa di piu',
come ad esempio prendere 5 lattine al giorno senza spendere una lira, dal
nostro malcapitato fornitore. (Ma no, non e' vero, cosa dici, lo facciamo
solo per la gloria e a fini di studio NdCava)(eh si!, dillo al raist!NdDreadN)
Come dobbiamo fare? Riguardiamo un attimino il pinout della EEPROM 24LC02,
notate che ci sono 8 piedini, gia' vi dico che i piedini 1,2,3 (chip select
per utilizzo di eeprom in serie), 4 (Vss) e 7 (hardware wp) sono completamente
in corto.
Potete quindi tranquillamente sfruttare solamente i piedini:
8 (Vcc)
7 (WriteProtect) (che va a massa con gli altri 4)
6 (Clock)
5 (Data I/O)
per fare tutto quello che volete.
(Per maggiori informazioni guardate [1] in fondo a questo articolo NdCava)
Vari modi sunt per bere et mangiare at gratis sine farsi sgamare et finire in
caella at marcire:
1) Sfruttare il fatto che il sistema macchina + chiavetta non tiene traccia
degli eventi passati, e' una semplice FSA deterministico, ed ogni stato e'
rappresentato dalla combinazione dei bit del credito piu' altra fuffa inutile.
Se riportate la macchina allo stato con piu' credito questa non se ne accorge
assolutamente.
PRO: Semplicissimo (tant'e' che lo fa gia' molta gente NdCava)
CONTRO: Ti devi riprogrammare tutto ogni volta che finisci il credito
2) Exploitare la write protection della eeprom distaccando il piedino 7 dalla
massa, metodo che potrebbe funzionare (dobbiamo ancora provare) anche se
sicuramente ci sono dei controlli fatti dalla macchina (del tipo: "se non
riesco a scrivere ti sputo in faccia e col cazzo che ti do la merendina!")
PRO: Hai una chiavetta infinita
CONTRO: Qualcuno prima o poi vi sgama perche' avete sempre lo stesso credito
(Aggiungerei come CONTRO : non funzionera' mai NdCava)
2a) Mettere un interruttore con un pulsante sul WProtect, in modo da attivarlo
a piacimento.
PRO: Hai una chiavetta infinita quando ti pare
CONTRO: Il pulsante prima o poi qualcuno ve lo vede
3) [Metodo molto l33t & hax0r] Mettere all'interno della chiavetta un bel
microcontrollore, magari uno con una mem interna e quando il credito scende
sotto un certo valore ci pensa lui a settare il credito come volete, magari
anche con una dozzina di valori diversi predefiniti. Rapido, silenzioso e
indolore.
PRO: Hai una chiavetta infinita, completamente antisgamo e autorigenerante.
CONTRO: Dovete alimentare il pic con una batteria interna (a secco spero),
abbastanza piccola da starci dentro, il tutto poi non deve consumare troppo,
altrimenti spendete piu' in batterie che quanto rubate alle macchinette.
(L'alternativa sarebbe cercare di far prendere l'alimentazione direttamente
dal distributore quando infiliamo dentro la chiavetta, in tal modo non c'e'
bisogno di una batteria ma, in ogni caso, lo spazio all'interno per mettere
un pic e' abbastanza limitato. NdCava)
3a) Come prima ma mettete un interruttore che ad ogni occasione mette dei
crediti prefissati, magari interno, cosi' dovete solo premerlo e riprogrammare
tutto con un dito.
PRO: Tutto molto figo, evitate pure di programmarvi il microcontrollore.
CONTRO: Come sopra, in piu' dovete ficcarci anche il pulsante e lo spazio non
e' molto.
4) [ancora meglio] Costruirsi un trasponder per programmare la chiave
per evitare quindi di dover morire per aprirla. Le possibilita' qui sono due:
a) Costruirsi un intero programmatore da interfacciare al PC per leggere e
scrivere la eeprom interna
b) Costruirsi un mini-circuito (magari controllato da un PIC) che sia in grado
di aggiungere tot credito con la pressione di un bottone (per es. loggando
con un oscilloscopio il campo che passa sulle induttanze all'inserimento di
1 euro)
PRO : Ottimo perche' permette di lavorare sulla chiave senza aprirla
CONTRO : Difficile da realizzare perche' bisogna studiare bene il funzionamento
dei trasponder contactless
[=- -=]
PART II - Author: Cavallo
Chapter 100 : Stereo MCs - Connected (dalla OST di Hackers)
ovvero "come ti connetto la eeprom al pc"
"gonna get myself, gonna get myself
gonna get myself connected"
Se avete seguito i dettami del mio compare, dovresti aver ottenuto una chiave
pulita, con i contatti della eeprom scoperti e magari con anche un bel
connettore per accedere con facilita' ai pin. Ok direte, ma come collego tale
chiave al PC?
La cosa e' molto semplice : usate un Multipipo.
La faro' breve, visto che molti di voi conosceranno gia' tale interfaccia
(dato che e' molto diffusa tra chi "opera" nel settore satellitare).
In sostanza si tratta di un programmatore su porta seriale che permette
di programmare PIC (tipicamente 16f84 e 16f876) e EEPROM (tipicamente
24lc16, 24lc32, 24lc64 e superiori). In realta', con tale interfaccia, e'
possibile operare anche con le piccole 24lc01 e 02 presenti nelle chiavi
COGES, quindi siamo a cavallo! (eheh) (pirla. NdDreadN)
L'unico sbattimento e' far combaciare i pin dell'eeprom con quelli del socket
relativo sul programmatore, ed e' infatti per questo che vi consigliamo di
costruirvi un connettore sulla chiave e un cavetto per semplificare le
operazioni.
Tralascio di entrare nel dettaglio su come usare questo programmatore, (e
sull'utilizzo dei software specifici). Vi consiglio comunque :
-IcProg sotto Windows
PS: ricordatevi di attivare sotto Options->I2C l'opzione "Enable MCLR as Vcc"
-Pic24c13 (ovvero Willem's Pic Programmer, www.willem.org) sotto DOS
Ovviamente in entrambi i software e' necessario selezionare la porta COM
corretta, il tipo di interfaccia utilizzata (Ludipipo per Pic24c13 e
JDM Programmer per IcProg) e il tipo di EEPROM (24lc02).
Per ulteriori informazioni sull'utilizzo di questi sw e dell'interfaccia
Multipipo, vi preghiamo di NON inviarci mail MA di cercare online (google
potrebbe essere un buon punto di partenza). (modo gentile per esprimere il
concetto "non rompeteci le palle per le vaccate!" NdDreadN)
[=- -=]
Chapter 101 : Queen - Gimme The Prize!
ovvero "e' il momento di avere il nostro premio"
"Here I am, I'm the master of your destiny,
I am the one the only one, I am the god of kingdom come,
Gimme the prize, just gimme the prize"
Arrivati a questo punto, dovreste aver capito come e' possibile accedere
fisicamente, leggere e scrivere la eeprom interna della chiave E.C.S.
"Beh, che altro c'e' da dire ?" - penseranno molti di voi - "Una volta che so
come copiare il contenuto della eeprom, posso fare un dump di N euro e
ricopiare quel dump sopra la chiave ogni volta che si esaurisce!"
Verissimo, ed in effetti questa pratica e' gia' ampiamente diffusa su [2], ma
il nostro obiettivo e' capire come funzionano le cose, e non tanto scroccare
qualche lattina di coca-cola (ma a chi la racconto?).
A questo punto, per poter capire il significato dei dati presenti nella
eeprom, e' necessario fare affidamento a quante piu' informazioni sia
possibile recuperare in rete su queste chiavi.
Partiamo dal sito officiale COGES [3] :
Capacita' di memoria: 1024 Bit (128 Byte)
Capacita' di credito: 65.000 unita'
Trasmissione dati: senza contatti
Identificazione tramite:
- Codice gestore
- Codice reparto
- Codice sezione
- Codice utente
- Codice gruppo di contabilita'
Dati memorizzabili:
- Credito della chiave
- Valore del credito precedente
- Numero matricola
- Giorno di produzione
- Numero di operazioni effettuate
Prendendo spunto da [2] invece, leggiamo notizie contrastanti tra di loro:
prima si parla di 24c01 (128byte), poi 24c02 (256Byte) usata per meta' dello
spazio, poi di 24c02 usata interamente, etc..
Io personalmente mi sono fatto questa idea: la memoria e' una 24c02, e
i 256byte sono suddivisi in 128B utilizzati per i dati e i restanti 128B
inutilizzati e disponibili per utilizzi futuri (tipo impronte digitali per gli
extracomunitari ? HIHIHI :-)))
(probabilmente le 24lc01 non le producono piu' e allora usano quello che passa
il convento NdDreadN)
Comunque, effetuando confronti progressivi tra alcuni dump (1.40, 1.06, 0.62),
ovviamente in esadecimale, possiamo notare che cambiano 19 byte cosi'
suddivisi:
- 3 byte agli indirizzi 00B, 018 e 001B
- una matrice di 4x4 byte a partire dall'indirizzo 044
I 3 byte hanno questa "progressione" (tenete conto che i dump sono di tre
operazioni progressive):
00B: C9 -> CA -> CB
018: D0 -> CF -> CE
01B: C9 -> CA -> CB
Sembra quindi che i byte 00B e 01B siano i contatori del numero di operazioni
effettuate di cui si parla sul sito, mentre l'altro byte che decresce puo'
essere un contatore di numero di operazioni restanti (ovviamente non abbiamo
conferma di questo, sono solo delle supposizioni)
Focalizziamoci ora sulle matrice 4x4:
1.40 Euro 1.06 Euro 0.62 Euro
=========== =========== ===========
82 80 43 C0 81 82 82 C2 80 83 83 82
82 83 02 00 82 40 C3 C0 81 82 02 C2
82 40 43 C0 81 42 82 C2 80 43 83 82
82 43 02 00 82 00 C3 C0 81 42 02 C2
Notate qualcosa di interessante?
Voglio qui aprire una piccola parentesi: leggendo questo articolo potreste
esclamare cose come "beh, facile", "che cazzata", "ah beh e' ovvio"
("sei un coglione!" NdDreadN).
Leggere e capire uno studio di questo tipo e' semplice, basta avere qualche
rudimento di informatica di base su bit-byte e simili.
Riuscire a capire come sono memorizzati i dati osservando solo questi dump,
beh, non e' cosi' facile.
A essere onesti, se guardate online o sui NG, non troverete un post di una
sola persona che dica "ho capito, i dati sono memorizzati cosi'"
Ora non voglio dire che NESSUNO ci sia riuscito, forse semplicemente si e'
tenuto l'informazione per se', ma resta il fatto che la maggior parte della
gente una volta capito che puo' dumpare la eeprom e ricopiarla sopra si e'
fermata li'.
Quindi la mia sfida e' questa, caro lettore:
se pensi di essere bravo o vuoi divertirti un po', cerca di capire da solo
come viene memorizzato il credito a partire dalle matrici di cui sopra o
usando i tuoi dump, altrimenti, prosegui la lettura da qui in poi :D
(e non rompere piu' le palle :-))
[=- -=]
Chapter 110 : Puddle of Mudd - Blurry
ovvero "facciamo luce nella nebbia"
"Everything's so blurry
and everyone's so fake
and everybody's empty
and everything is so messed up"
Cerchero' di seguire piu' o meno il filo logico che mi ha condotto
alla soluzione, ivi inclusi i miei errori:
Innanzi tutto, ecco cosa ho dedotto osservando quei dati:
- i byte iniziano sempre per 0,4,8 o C
- la prima riga e la terza differiscono di 40H sul 2ndo byte (*)
- la seconda riga e la quarta differiscono di 40H sul 2ndo byte (*)
- i byte finiscono sempre per 0,1,2 e 3 (+)
(*) questo schema e' ripetuto anche in altri punti della eeprom
(+) poi smentito da dump successivi, vedi dopo..
Mumble Mumble i neuroni iniziano a lavorare...
Dato che la chiave memorizza sia il credito attuale che quello precedente,
viene da pensare che quelle quattro righe siano in realta' il credito attuale
e quello precedente copiati due volte, per backup.
Questa ipotesi e' suffragata anche dal fatto che a seguito di alcuni errori
nelle operazioni con i distributori si e' comunque in grado di recuperare
il credito corretto nella chiave.
Ok quindi ci interessiamo solo delle prime due righe:
1.40 Euro
===========
82 80 43 C0
82 83 02 00
Sperando che le premesse siano esatte (ovvero che i dati ripetuti siano per
backup e non servano ad altro), come sara' memorizzato il credito?
Aggiungiamo l'ennesima premessa, sparando a caso, diciamo che la prima riga
e' il credito attuale e la seconda e' quello precedente (che tra l'altro
non sappiamo, essendo 1.40 il primo dump disponibile e visto che non ci
ricordiamo cosa e' stato comprato con la chiavetta prima dell'1.40,
i soliti smemorati...)
a questo punto come collegare 1.40 euro a 82 80 43 C0 ?
Potremmo avere varie alternative:
1- i dati sono memorizzati in base dieci, per esempio come decine di euro,
euro, decimi e centesimi, ma in che modo? (antani e tarapiatapioco?
NdDreadN)
2- i dati sono memorizzati in base 2, ma in che modo?
3- il credito non e' memorizzato "in chiaro", ma secondo qualche funzione
matematica abbastanza semplice, per esempio come somma/differenza da
un valore fisso.
esempio : come +/- rispetto a 1000
4- il credito e' memorizzato come combinazione tra la prima parte del byte e
la seconda parte.
esempio:
80 vuol dire 1
40 vuol dire 20
il credito e' memorizzato come 82 ? 43 ? cioe'
come 1 x 2euro - 3 x 20cent = 2 - 0.60 = 1.40
(Sbiribulzina direi, oppure come vicesindaco NdDreadN)
Questo giusto per far capire che seghe mentali mi sono fatto a cercar di
capire i dati :-)))
(Tanto se non ti fai quelle mentali ti fai le altre... :) NdDreadN)
D'altra parte, noi che ne sappiamo? Non ci resta che usare qualche dump di
piu' e sperare di capirci qualcosa:
1.40 Euro -> 1.06 Euro -> 0.62 Euro
=========== =========== ===========
82 80 43 C0 81 82 82 C2 80 83 83 82
82 83 02 00 82 40 C3 C0 81 82 02 C2
A seguire utilizzero' questa notazione (prendiamo C2 come esempio)
PS: un nibble = 4 bit
Low Nibble (LN) -> 2 (ovvero 0010)
High Nibble (HN) -> C (ovvero 1100)
e quindi per identificare i primi due bit e i secondi due
Hi(HN) = 11
Lo(HN) = 00
Hi(LN) = 00
Lo(LN) = 10
insieme formano C2 ovvero 11000010
Osservando i tre dump, si puo' osservare una cosa interessante, ovvero che i
LN del credito passano da un dump all'altro nel processo di "invecchiamento
del credito" senza cambiare:
Infatti 82 80 43 C0 credito attuale nel primo dump
diventa 82 40 C3 C0 credito vecchio nel secondo dump.
Inoltre 81 82 82 C2 credito attuale nel secondo dump
diventa 81 82 02 C2 credito vecchio nel terzo dump.
Questo *potrebbe* voler dire, forse, che il credito
viene rappresentato solo dai LN ovvero:
1.40 -> 2,0,3,0
1.06 -> 1,2,2,2
0.62 -> 0,3,3,2
A questo punto provo a prender spunto dal metodo di memorizzazione usato nelle
carte telefoniche estere, ovvero una cosa di questo tipo (metodo tra l'altro
da me gia' testato in diverse salse applicandolo ai byte invece che ai nibble
e con basi segate e quindi senza successo)
(tratto da [4])
The Counter area:
-----------------
The counter area stores the card's units. Its initial value is specified
by the card issuer and set during manufacturing.
The counter area is divided into a 5 stage abacus. The octal value of each
stage is defined by the number of bits set to '1' and this stage value must
be weighted by the coeficient 8^n ( where n is among [4..0] ).
Exemple: For a card with 15818 units (or money units) left.
--------
Byte9 Byte10 Byte11 Byte12 Byte13
--------------------------------------------------------------
00000111 - 00111111 - 01111111 - 00000001 - 00000011
--------------------------------------------------------------
(3)octal (6)octal (7)octal (1)octal (2)octal
--------------------------------------------------------------
Value = 3*8^4 + 6*8^3 + 7*8^2 + 1*8^1 + 2*8^
--------------------------------------------------------------
TOTAL = 15818 Units
Prendendo ispirazione da questo, con un po' di Zen, un po' di sano buco di
culo e la calcolatrice di Windows (che bel mix :P) arrivo a questo tentativo:
LN1 LN2 LN3 LN4
2 0 3 0
devo avere 140 ? uhm iniziamo a levare un bel 128
cioe' 64x2, mi restano 12, dodici dodici, e perche' non un bel 4x3 ?
quindi le prime basi potrebbero essere : 2^6 ? 2^2 ?
proviamo a metterci in mezzo 2^4 e 2^0 e vediamo se la cosa ha
senso anche x gli altri dump :
c\b | 64 | 16 | 4 | 1 |
=============================
140 | 2 | 0 | 3 | 0 | -> 64x2 + 16x0 + 4x3 + 1x0 = 140 OK
106 | 1 | 2 | 3 | 0 | -> 64x1 + 16x2 + 4x3 + 1x0 = 106 OK
062 | 0 | 3 | 3 | 2 | -> 64x0 + 16x3 + 4x3 + 1x2 = 62 OK
002 | 0 | 0 | 0 | 2 | -> 64x0 + 16x0 + 4x0 + 1x2 = 2 OK
YEAAAAAAAAAAAAAHHHHHHHHHHH TROVATO !!!!!!!!!!
(e' o non e' un genio il mio amico? NdDreadN)
Le basi usate sono 2^6 , 2^4 , 2^2 , 2^0
Pero' pero' pero'....
mi viene questo dubbio... per ora abbiamo trovato solo 0 1 2 3 come pesi da
assegnare, ma, dato che un nibble sono 4 bit, io potrei avere 16 valori....
Quindi ci sono due alternative:
-i valori del LN sono solo 0 1 2 3, ma a questo punto il massimo valore
memorizzabile in quelle posizioni sarebbe 255 (64x3 + 16x3 + 4x3 +1x3)
(e direi che 2.55 euro come credito massimo non e' possibile, visto poi
che il sito riporta 65.000 come massimo credito) questo vorrebbe dire che i
valori superiori andrebbero memorizzati da qualche altra parte, io ci credo
poco..
- i valori del LN coprono tutte le 16 opportunita' (da 0 a F), ma in che modo?
se moltiplicassi usando solo queste basi avrei:
64x15+ 16x15 + 4x15 + 1x15 = 1275 mmm ancora troppo poco...
Deve esserci qualche gioco di bit, qualche base diversa, ho una idea...
(attenzione! neuroni al lavoro NdDreadN)
Focalizziamoci sempre sul LN:
sono 4 bit come gia' detto, noi finora abbiamo visto
0 -> 0000
1 -> 0001
2 -> 0010
3 -> 0011
ma i primi due bit li vogliamo usare si o no?!?
Ho come l'impressione che siano usati come pesi per basi piu' alte...
...per controllare quindi, inseriamo due belle monete da 1 euro (DOH!) e
carichiamo la chiavetta partendo da 1.40 e raggiungendo cosi' 3.40 euro
(sforando cosi' il "limite" dei 2.55)
cosa otteniamo ? 81 C1 01 44
guardiamo i LN : 1 1 1 4
TOH, un quattro che non s'era mai visto...
passiamo al binario :
LN1 LN2 LN3 LN4
0001 0001 0001 0100
Splittiamo in high e low e vediamo un po':
con le basi che avevamo gia' trovato, otteniamo
lo(LN1) -> 01 -> 1 * 64 = 64 +
lo(LN2) -> 01 -> 1 * 16 = 16 +
lo(LN3) -> 01 -> 1 * 4 = 4 +
lo(LN4) -> 00 -> 0 * 1 = 0 +
e fin qui abbiamo: 84
Abbiamo usato 2^6 , 2^4 , 2^2 e 2^0 come potenze per arrivare fino a 255,
perche' non provare 2^14 , 2^12 , 2^10 e 2^8 come potenze per i due
bit "alti" ? :-)
hi(LN1) -> 00 -> 0 * 16384 = 0 +
hi(LN2) -> 00 -> 0 * 4096 = 0 +
hi(LN3) -> 00 -> 0 * 1024 = 0 +
hi(LN4) -> 01 -> 1 * 256 = 256 +
qui abbiamo : 256
256 + 84 = ? .... 340 !! OK :D
PAAPPAAAAPAAAAAAA
Squillino le trombe, trombino le squillo, ecco trovato come e' memorizzato il
dannato credito!
(ecco, e' andato, l'abbiamo perso... NdDreadN)
Chapter 111 : Linkin Park - In the End
ovvero "vicini alla soluzione, ma..."
"I tried so hard
And got so far
But in the end
It doesn't even matter
I had to fall
To lose it all
But in the end
It doesn't even matter"
Bene a questo punto sappiamo dove e come viene memorizzato il credito, ma qui
iniziano le grane. Al contrario delle vecchie chiavi a contatto, in queste
contactless il credito e' memorizzato con un meccanismo di checksum.
Questo vuol dire che mettere qualche F F F F qua e la' non ci porterebbe da
nessuna parte. Tra l'altro, quello che non sappiamo ancora e' da cosa possa
dipendere il checksum.
Uno dei casi peggiori (il caso pessimo che posso immaginare) potrebbe essere
questo:
ck(t+1) = f[ck(t), cr(t+1), cr(t), t, key[]]
ovvero il nuovo checksum potrebbe dipendere (nell'ordine) dal vecchio
checksum, dal credito da inserire, dal credito precedente, dal passo in cui ci
troviamo, da qualche dato specifico che identifica la chiavetta (cod.gestore,
cod.chiave) o che magari e' interno alla chiave e che si puo' variare (per
es. una matrice contenuta nei 128B finali).
Per capire un po' come funziona la cosa, abbiamo realizzato una serie di prove
mirate usando, sul posto, il mio vetusto portatile p90 con 16mb di ram
+ squallido ludipipo su millefori + sw di programmazione e editing dei file
sotto DOS (questo x far capire che non serve avere un athlon 2200+ per
combinare qualcosa di buono :-))
(anche una tastiera che non avesse problemi a digitare 'c''d''e''f''b' non
sarebbe stata affatto male, visto che nell'esadecimale le lettere usate vanno
dalla A alla F; poi, l'HD del portatile era mio, giusto per precisare...
perche' cava tiene l'hw un po' come un bambino tiene i LEGO nella cesta...poi
non va mai un cazzo... :) NdDreadN)
(dobbiamo invece parlare del portatile di DreadN da cui proveniva quell'hd,
preso apposta per fare lavori "sporchi" di questo tipo e con i due "piccoli"
difetti di avere una batteria NON funzionante (e quindi va lasciato attaccato
alla corrente perennemente) e di disporre di una seriale COMPLETAMENTE
sputtanata e che quindi NON serve a un cazzo? un saluto a blinking :) NdCava)
Le prove erano di questo tipo (elenco non esaustivo):
-modifica del credito con valori a muzzo
(risultato -> il distrib. s'e' incazzato :-))
(Sul display e' venuto fuori: "Non hai capito un cazzo." NdDreadN)
-modifica del byte che tiene conto del n. di operazioni effettuate
(risultato -> funziona)
-utilizzo di 4 byte "conosciuti" di una chiave mettendoli su un'altra
(risultato -> funziona)
-modifica del credito vecchio
(risultato -> se ne sbatte)
-arrivare a un valore conosciuto (es 1.40) da un "percorso" differente
(risultato -> il valore memorizzato e' identico a quello conosciuto)
Dopo questi e altri test, siamo giunti alla conclusione (al 99%) che
il check dipenda solo ed esclusivamente dal credito corrispondente (puff!)
(...e pant! oserei dire, vista la fatica e lo sgamo! NdDreadN)
A questo punto ci siamo dedicati ad effettuare test sui singoli byte per
vedere come variavano utilizzando crediti tipo 0000 0001 0002 0010 etc..
Per far questo abbiamo sfruttato a nostro favore il meccanismo di backup
di sicurezza del distributore:
modificando sia il dato primario che quello di backup, e' possibile effettuare
due test per volta (se infatti il dato primario e' errato ma e' giusto
quello di backup, il dato di backup viene ricopiato sopra al primario
correggendo l'errore). In tal modo il num. dei test viene dimezzato
(grazie amico distributore! :))
(grazie anche a me che mi e' venuta l'idea... :) NdDreadN)
Beh, non voglio tirarla in lungo, NON siamo riusciti a capire il meccanismo di
checksum. Abbiamo provato vari approcci e con uno (combinazione lineare) siamo
arrivati a determinare correttamente (almeno rispetto ai dati in nostro
possesso) il 4to check (ovvero HN4).
Il problema e' che cercando di applicare la stessa tecnica agli altri check
(e quindi impostando dei sistemi per trovare i pesi da assegnare alle singole
cifre del credito) si giunge a una conclusione impossibile.
Questo vuol dire che o l'approccio lineare e' sbagliato, o vale solo per
il quarto check.
Abbiamo provato anche qualche variante di CRC (per questo consiglio di dare
un occhio all'ottima guida [5]), ma senza risultato.
Per il momento abbiamo sospeso per impegni le ricerche, e quindi abbiamo
deciso di scrivere quest'articolo.
A questo punto non mi resta che lasciarvi, la sfida e' aperta, speriamo in
futuro di potervi proporre la soluzione del check o, perche' no, di pubblicare
come BFi-dev la soluzione trovata da voi al problema.
D'altra parte le parole della canzone descrivono bene la situazione attuale,
abbiamo provato duramente, siamo andati lontani, ma alla fine siamo caduti :/
Un paio di osservazioni finali:
- non allego codice al seguente articolo principalmente perche' il programma
di generazione/check a cui sto lavorando non e' concluso (mancando ancora
la generazione del check), ma anche perche' non ci sembra giusto rilasciare
un programma che permetta "al primo pirla" (calcisticamente parlando come
dicono i Gialappa's :-)) di inserirsi dentro la chiave 650 euro di credito.
(anche perche' sarebbe proprio coglione, non calcisticamente parlando, e lo
sgamerebbe anche la mamma di Angelo(R) che ha la chiavetta tarocca!NdDreadN)
Per questo, qualora scoprissimo il meccanismo di check, non pubblicheremmo
comunque il programma "completo", ma solo la descrizione del meccanismo e
un codicillo esemplificativo. Per questo, o vi accontentate delle
informazioni qui pubblicate, o vi conviene iniziare a studiare la cosa da
soli.
Ergo niente e-mail del tipo "avete finito il programma? me lo date?
mi passate tutti i vostri dump?"
Studiate un po' per i cz vostri, come abbiamo fatto noi (eccetto per gli
spunti provenienti dai NG o da qualche amico)
- ci sono altre cose interessanti su queste chiavi. Alcune le ha gia' espresse
DreadN nel capitolo 011, altre sono relative ai dump come il passaggio da
lire a euro etc... Molto interessante sarebbe capire anche il meccanismo
di autenticazione (ovvero trovare dove viene memorizzato il codice gestore
e simili) e capire dunque se esiste qualche modo (x es. un codice
universale) che permetta di utilizzare la chiave non solo sulle macchine di
quel dato ufficio/azienda/universita', ma su tutti i distributori di quel
tipo. Dunque, se avete voglia, c'e' da divertirsi... :)
Riferimenti
[1] http://www.microchip.com (per il datasheet delle eeprom 24lc02)
[2] newsgroup "it.hobby.elettronica"
[3] sito ufficiale coges: www.coges.it
[4] "How Chip works" (aka Telecard FAQ)
ftp://nic.funet.fi/pub/doc/telecom/phonecard/chips
[5] "Everything you wanted to know about CRC algorithms, but were afraid
to ask for fear that errors in your understanding might be detected."
(e gia' il titolo e' tutto un programma :))
ftp://ftp.adelaide.edu.au/pub/rocksoft/crc_v3.txt
Ringraziamenti
- silver per il supporto tecnico (connettori and so on.. :))
- elia per le radiografie
- Scatman e TinMan per i suggerimenti sull'apertura delle chiavi e per i dump
- recidjvo, raist_XOL, del0rean, valvoline per consigli, idee ed illazioni sul
metodo di memorizzazione del credito e del checksum
- Fra, Ste, Ang e +Mala per il supporto "sul campo"
- tutti quelli che abbiamo dimenticato
(- le tipe che me l'hanno data quando offrivo a gratis le merendine NdDreadN)
(se fosse vero... NdCava)
Un abbraccio ad Andrea A. che ci ha lasciato prematuramente, so che da lassu'
ci guardi...
Mi si dice di essere piu' esplicito, e quindi, siori e siore,
LANCIAMO IL CONTEST :
PAPPAPAAA PAPAPAPAAAAAAAAAAAAA
BFi lancia il contest per il breaking dell'algo di controllo per il credito,
chi riuscira' a brekkare l'algoritmo vincera' un viaggio alle Hawaii pagato
dalla redazione (forse) e (piu' probabilmente) la pubblicazione come BFi-dev
delle sue scoperte :)
Ovviamente i dump che abbiamo fornito sopra sono limitati (solo 3 di esempio,
quindi se volete studiare la cosa, o recuperate dei dump da qualche parte (non
da noi), o aprite una chiave e iniziate a studiarla o... vi fate bastare i 3
dump sopra :))
Un'ultima nota: DreadNought vuole far presente che lui non c'entra *NIENTE*
con tale Dreadnaut che scrive su OndaQuadra (http://www.ondaquadra.org).
Concludiamo con le e-mail, ovviamente per la soluzione del contest, domande e
suggerimenti intelligenti e non per gli "a me a me":
DreadNoughT : dreadn@s0ftpj.org
Cavallo de Cavallis : cavallo@s0ftpj.org
Posta di BFi : bfi@s0ftpj.org
[=- -=][=- -=][=- -=]
==============================================================================
--------------------------------[ EOF 14/15 ]---------------------------------
==============================================================================
