============================================================================== --------------------[ BFi11-dev - file 14 - 27/11/2002 ]---------------------- ============================================================================== -[ DiSCLAiMER ]--------------------------------------------------------------- Tutto il materiale contenuto in BFi ha fini esclusivamente informativi ed educativi. Gli autori di BFi non si riterranno in alcun modo responsabili per danni perpetrati a cose o persone causati dall'uso di codice, programmi, informazioni, tecniche contenuti all'interno della rivista. BFi e' libero e autonomo mezzo di espressione; come noi autori siamo liberi di scrivere BFi, tu sei libero di continuare a leggere oppure di fermarti qui. Pertanto, se ti ritieni offeso dai temi trattati e/o dal modo in cui lo sono, * interrompi immediatamente la lettura e cancella questi file dal tuo computer * . Proseguendo tu, lettore, ti assumi ogni genere di responsabilita` per l'uso che farai delle informazioni contenute in BFi. Si vieta il posting di BFi in newsgroup e la diffusione di *parti* della rivista: distribuite BFi nella sua forma integrale ed originale. ------------------------------------------------------------------------------ -[ HACKiNG ]------------------------------------------------------------------ ---[ C.0.G.E.S.: CHiAVETTE 0TTURATE Gi0i0SAMENTE ESTRATTE & STUDiATE -----[ Cavallo de Cavallis DreadNought 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 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 #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 [=- -=][=- -=][=- -=] -[ WEB ]---------------------------------------------------------------------- http://www.bfi.cx http://www.s0ftpj.org/bfi/ -[ E-MAiL ]------------------------------------------------------------------- bfi@s0ftpj.org -[ PGP ]---------------------------------------------------------------------- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3i mQENAzZsSu8AAAEIAM5FrActPz32W1AbxJ/LDG7bB371rhB1aG7/AzDEkXH67nni DrMRyP+0u4tCTGizOGof0s/YDm2hH4jh+aGO9djJBzIEU8p1dvY677uw6oVCM374 nkjbyDjvBeuJVooKo+J6yGZuUq7jVgBKsR0uklfe5/0TUXsVva9b1pBfxqynK5OO lQGJuq7g79jTSTqsa0mbFFxAlFq5GZmL+fnZdjWGI0c2pZrz+Tdj2+Ic3dl9dWax iuy9Bp4Bq+H0mpCmnvwTMVdS2c+99s9unfnbzGvO6KqiwZzIWU9pQeK+v7W6vPa3 TbGHwwH4iaAWQH0mm7v+KdpMzqUPucgvfugfx+kABRO0FUJmSTk4IDxiZmk5OEB1 c2EubmV0PokBFQMFEDZsSu+5yC9+6B/H6QEBb6EIAMRP40T7m4Y1arNkj5enWC/b a6M4oog42xr9UHOd8X2cOBBNB8qTe+dhBIhPX0fDJnnCr0WuEQ+eiw0YHJKyk5ql GB/UkRH/hR4IpA0alUUjEYjTqL5HZmW9phMA9xiTAqoNhmXaIh7MVaYmcxhXwoOo WYOaYoklxxA5qZxOwIXRxlmaN48SKsQuPrSrHwTdKxd+qB7QDU83h8nQ7dB4MAse gDvMUdspekxAX8XBikXLvVuT0ai4xd8o8owWNR5fQAsNkbrdjOUWrOs0dbFx2K9J l3XqeKl3XEgLvVG8JyhloKl65h9rUyw6Ek5hvb5ROuyS/lAGGWvxv2YJrN8ABLo= =o7CG -----END PGP PUBLIC KEY BLOCK----- ============================================================================== -----------------------------------[ EOF ]------------------------------------ ==============================================================================