============================================================================== --------------------[ BFi12-dev - file 06 - 29/06/2003 ]---------------------- ============================================================================== -[ 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. EXP0SED -----[ SteTry Chapter 000 : INTRODUCTION Ciao a tutti ! Non avrei mai pensato di ritrovarmi a scrivere un articolo ma, visto che ho risolto, con un po' di culo, il problema dei check delle famose coges, eccomi qui! La cosa sorprendente e' che Cavallo de Cavallis ha risposto alla mia mail dicendomi che in quello stesso giorno, qualcuno lo aveva contattato con la risposta al medesimo "enigma". Che si tratti di intercessione divina o di pura e semplice casualita' (espressione di Cavallo de Cavallis), questo non lo so ma ecco la mia versione! Possiamo cominciare! P.S. Con "ART1" faccio riferimento all'articolo BFi11-dev-14 scritto da Cavallo de Cavallis e DreadNought (http://bfi.s0ftpj.org/dev/BFi11-dev-14). Chapter 001 - CREDITO ATTUALE, CREDITO PRECEDENTE Mi sono imbattuto nell'articolo che tratta le coges praticamente per caso. Stavo cercando documentazione sulla hook injection e in particolare sull'API "CreateRemoteThread" e sono finito sul sito di BFi. Dato uno sguardo agli altri articoli e non sapendo cosa fosse C.o.g.e.s., ho iniziato una sana lettura e dopo circa una settimana stavo gia' smanettando con scheda su porta COM e chiavetta propriamente sciolta. Non avendo a disposizione molti valori, ho pensato che trovare una relazione tra "credito attuale" e "credito precedente" mi avrebbe permesso di aumentare le possibilita' di individuare una qualche soluzione dei checksum. Ho iniziato cosi' raccogliendo i dati presenti nell'ART1 e ne ho aggiunto qualcuno di mio: C. attuale C. precedente Euro 82 80 43 C0 82 40 C3 C0 1.40 81 82 82 C2 81 82 02 C2 1.06 80 83 83 82 80 83 81 82 0.62 80 C3 40 43 80 83 C0 43 0.51 Come potete notare ovviamente i LN rimangono gli stessi. Gli HN invece sembrano cambiare sempre. Ma in che modo? Prima di tutto gli HN assumono solo i valori: 0 4 8 C di conseguenza si tratta di una base quattro. Convertendo i valori in binario: 0 -> 0000 4 -> 0100 8 -> 1000 C -> 1100 Forse risulta piu' semplice lavorare solo sui primi due bit (visto che i rimanenti sono sempre zero) e quindi: 00 -> 0 01 -> 1 10 -> 2 11 -> 3 Vediamo cosa ne viene fuori unendo tutti i primi due bit degli HN e considerando un unico numero di 4 cifre: C. attuale C. precedente Euro 2213 2133 1.40 2223 2203 1.06 2222 2202 0.62 2311 2231 0.51 Non serve molto per capire che tra il c. attuale e il c. precedente c'e' una differenza di 20. Ho verificato cosi' la relazione trovata con altri crediti e tutto sembra funzionare. E ora avanti! Chapter 010 : STRANI VALORI DECRESCENTI Grazie alla relazione trovata, ho potuto quasi raddoppiare i valori di credito in mio possesso. Sono giunto cosi' ad alcune conclusioni: - dato che il primo dei quattro nybble rimaneva sempre 8, ho assunto che per qualsiasi valore rimanesse costante (La mia idea era che per valori bassi cio' fosse vero, ma che potesse cambiare per valori piu' alti. In realta' poi ho verificato che HN1 e' sempre 8 anche se.. lo vedrete dopo). - dato che per due valori diversi (0,51 e 0,96) avevo gli stessi nybble (8C44) non avrei potuto procedere come e' stato fatto nell'ART1 e cioe' partire dai bit e ricavarmi il credito, ma solamente partire dal credito e ricavarmi i checksum. Considerando che la relazione tra c. attuale e c. precedente stabisce che i 4 nybble non sono indipendenti, ma che costituiscono insieme un certo numero, ho assunto che cio' fosse vero anche nella mia successiva ricerca. Visto che non sono bravo a ragionare in base quattro (e penso neanche voi), ho aperto il mio buon Excel e mi sono costruito una semplice tabella di conversione (ho tralasciato di scrivere il primo nybble visto che come ho detto lo assumo costante): 0 <-> 000 16 <-> 400 32 <-> 800 48 <-> C00 1 <-> 004 17 <-> 404 33 <-> 804 49 <-> C04 2 <-> 008 18 <-> 408 34 <-> 808 50 <-> C08 3 <-> 00C 19 <-> 40C 35 <-> 80C 51 <-> C0C 4 <-> 040 20 <-> 440 36 <-> 840 52 <-> C40 5 <-> 044 21 <-> 444 37 <-> 844 53 <-> C44 6 <-> 048 22 <-> 448 38 <-> 848 54 <-> C48 7 <-> 04C 23 <-> 44C 39 <-> 84C 55 <-> C4C 8 <-> 080 24 <-> 480 40 <-> 880 56 <-> C80 9 <-> 084 25 <-> 884 41 <-> 884 57 <-> C84 10 <-> 088 26 <-> 488 42 <-> 888 58 <-> C88 11 <-> 08C 27 <-> 48C 43 <-> 88C 59 <-> C8C 12 <-> 0C0 28 <-> 4C0 44 <-> 8C0 60 <-> CC0 13 <-> 0C4 29 <-> 4C4 45 <-> 8C4 61 <-> CC4 14 <-> 0C8 30 <-> 4C8 46 <-> 8C8 62 <-> CC8 15 <-> 0CC 31 <-> 4CC 47 <-> 8CC 63 <-> CCC Diamo un'occhiata ai valori che avevo a disposizione: Euro Checksum Conversione 0.00 C8C 59 0.20 C48 54 0.23 C0C 51 0.31 88C 43 0.32 C84 57 0.51 C44 53 0.54 C08 50 0.59 8C4 45 0.62 888 42 0.96 C44 53 0.99 C08 50 1.04 8C4 45 1.06 88C 43 1.28 C0C 51 1.40 84C 39 1.48 8C8 46 Notate qualcosa di strano? I numeri sembrano decrescere in modo regolare e dopo un certo punto tornare a valori alti e ridecrescere. Mmmmm proviamo un po': 023 - 020 = 3 --> 54 - 51 = 3 054 - 051 = 3 --> 53 - 50 = 3 106 - 104 = 2 --> 45 - 43 = 2 104 - 099 = 5 --> 50 - 45 = 5 Non puo' essere una coincidenza!!! Ma tra 0.32 e 0.31, due crediti consecutivi, le cose sembrano andare diversamente e anche in altri punti. In che modo i checksum sono portati a valori piu' alti? Chapter 011 : SALI E SCENDI Andando un po' per tentativi e un po' per culo mi sono accorto che i cambi avvengono per multipli di 16 o meglio di 2^4. I miei unici valori consecutivi coincidevano proprio con uno di questi cambi (tra 0.31 e 0.32). A questo punto la domanda successiva e': come faccio a stabilire da che numero partire? Mmmmm... diamo un'occhiata ai termini che ho a disposizione: Euro Checksum Conversione 0.00 C8C 59 0.16 ? ? 0.32 C84 57 0.48 ? ? 0.64 ? ? 0.80 ? ? 0.96 C44 53 1.12 ? ? 1.28 C0C 51 Credo che sia evidente che, anche in questo caso, ci troviamo di fronte a dei numeri decrescenti! Facciamo una verifica veloce... Prendiamo per esempio 0.48 e scendiamo fino a 0.51, credito conosciuto. 0.48 dovrebbe valere 56 quindi... 0.49 55 0.50 54 0.51 53 Ok ci siamo! Ok direte voi e' tutto risolto! No, non tutto... Che succede quando si arriva a zero? Non ci si avvicina nemmeno al limite dei 655.35! Apriamo una parentesi e sgommiamo verso l'alto e vediamo cosa succede per 3.40 euro. 340 / 16 = 21 resto 4 4 / 1 = 4 resto 0 Quindi se non sbaglio per trovare il nostro valore di checksum.. 59 - (21 + 4) = 34 Bella la formuletta! L'avete capita? Per ogni multiplo di 16 il valore, partendo da 59, decresce quindi, se considero 16 * 21, il valore 59 sara' sceso di 21. A questo punto sono arrivato a 3.36 euro. Altri 4 centesimi in piu' sono altri 4 numeri da sottrarre a 59 per tutto quello che abbiamo visto prima! Comodo no? Peccato che non funzioni per 3.40. Infatti riprendendo i byte dati da ART1: 81 C1 01 44 -> percio': C04 -> 49 Chapter 100 : LA SOLUZIONE FINO A 655.34 Allora... Non facciamo le cose a caso... Abbiamo visto che c'e' questa regolarita' nei valori che decrescono... Per multipli di 16 pero' qualcosa cambia... E se ci fosse una variazione della regola anche tra i valori di cambio? Se il ragionamento non e' stupido probabilmente questa variazione avviene dopo il sedicesimo numero in gioco. Forse e' piu' chiaro scrivendo un po' di numeri. Prima i checksum decrescevano cosi': Euro Conversione Euro Conversione 0.00 59 0.10 49 0.01 58 0.11 48 0.02 57 0.12 47 0.03 56 0.13 46 0.04 55 0.14 45 0.05 54 0.15 44 0.06 53 0.16 58 <- primo cambio a 16 0.07 52 0.17 57 0.08 51 0.18 56 0.09 50 0.19 ... Ma se considero multipli di sedici la cosa e' analoga: Euro Conversione Euro Conversione 0.00 59 1.60 49 0.16 58 1.76 48 0.32 57 1.92 47 0.48 56 2.08 46 0.64 55 2.24 45 0.80 54 2.40 44 0.96 53 2.56 58 <- primo cambio a 16 * 16 1.12 52 2.72 57 1.28 51 2.88 56 1.44 50 3.04 ... 256 ... Wow vi ricorda qualcosa questo valore??? Vediamo se questa volta la regoletta funziona: 340 / 256 = 1 resto 84 84 / 16 = 5 resto 4 4 / 1 = 4 resto 0 Quindi si sommeranno 1, 5 e 4 59 - (1 + 5 + 4) = 49 !!!!! Ci siamo!!! Ma abbiamo veramente finito? Una domanda nasce spontanea... Vediamo se... 256 * 16 = 4096 Mmmm un po' pochini 40 euro, proseguiamo... 4096 * 16 = 65536 Eccolo!!!!!!! Abbiamo trovato il limite che cercavamo! E visto che ci piace mettere tutto come esponenziali di due riscriviamo la regoletta: credito / 2^12 = v1 resto r1 r1 / 2^8 = v2 resto r2 r2 / 2^4 = v3 resto r3 r3 / 2^0 = v4 resto 0 59 - (v1 + v2 + v3 + v4) = valore decimale da convertire in base 4 ecc... (vedi tabella) NOTA: Per facilitare i calcoli ho utilizzato quasi esclusivamente numeri in base 10. In realta' la formula trovata non e' altro che una conversione del credito in esadecimale, una sottrazione e una conversione in base 4. Infatti 340 non e' altro che 154 in esadecimale. Quindi basterebbe poi sottrarre a 3B (59 in hex) la somma delle sue cifre e cioe' (1 + 5 + 4) e quindi ottenere 31 (49 in hex). Essendo 16 un multiplo di 4 * 4 e' piu' semplice anche la conversione in base 4 infatti basta considerare esclusivamente le singole cifre. Si capisce bene continuando con l'esempio: 31 -> 03 01 -> 03 01 -> sposto i bit a sinistra di due e ottengo C04 se fosse stato: 2A -> 02 0A -> 02 22 -> sposto i bit a sinistra di due e ottengo 888 (22 corrisponde ad A in base 4) o ancora: 18 -> 01 07 -> 01 13 -> sposto i bit a sinistra di due e ottengo 44C Per chi e' piu' pratico con questo tipo di calcoli indubbiamente le cose diventato piu' semplici. Nel capitolo successivo continuero' comunque in base 10. Chapter 100 : I VALORI DI CREDITO PRECEDENTE E DI BACKUP PER VALORI LIMITE Visto che praticamente non avevo nessun valore superiore ai 5 euro, ho fatto una ricerca sui gruppi di discussione per vedere se qualcuno avesse postato i byte corrispondenti a crediti superiori. Mi sono sorpreso nel trovare che un genio aveva scritto i sui numeretti per un valore di 157.00 euro!!! Ma come cavolo ha fatto a mettere tanti soldi in un pezzo di plastica? Poi Cavallo de Cavallis mi ha fatto notare che il post era vecchio e in realta' quel valore era da considerarsi in lire. Comunque dato che il credito veniva memorizzato nello stesso modo, quelle 15 mila lire oggi sono diventate 157.00 euro! Il giochetto sembra essere correto anche per quel credito e per il credito precedente propriamente modificato (57.00 euro). Rimane pero' un problema che forse ai piu attenti non sara' sfuggito. Cosa succede per il valore limite 65535? Se infatti calcolo: 65535 / 2^12 = 15 resto 4095 4095 / 2^8 = 15 resto 255 255 / 2^4 = 15 resto 15 15 / 2^0 = 15 resto 0 59 - (15 + 15+ 15 + 15) = -1 !!!! Il checksum 000 lo ottengo per 655.34 mentre per 655.35 che faccio??? A che checksum corrisponde -1 ??? Se consideriamo il limite dato dal calcolo dell'ART1 ci sono 655.36 possibili crediti da 0 a 655.35 . Il 59 impone invece 655.35 termini da 0 a 655.34 . Perche' ora non far partire il conto da 60 e ottenere lo stesso numero di possibilita'? Daro' una risposta anche a questo nel capitolo 111. Inoltre ci sono altri due problemi. Prima di tutto vi ricordate la storia del credito attuale e del credito precedente? Ammesso che qualcuno riuscisse a trovare una macchinetta che gli permettesse di portarsi a casa navi di merendine per un valore di 655.34, cosa succede la prima volta che preleva qualcosa? Ragionando in base 4 abbiamo visto che bisogna sottrarre 20 (ovvero 8 in decimale). Il valore di checksum a rischio e' quindi quello che corrisponde a 7 e cioe' 04C. C'e' un metodo veloce per trovare il credito piu' basso in cui compare questo checksum? Abbiamo una formula, serviamocene nel modo inverso: 59 - 7 = 52 questo sara' la somma dei risultati delle divisioni 52 - 15 = 37 togliamo sempre il valore piu' grande 37 - 15 = 22 finche' c'e' permesso 22 - 15 = 7 ok Utilizziamo il 7 per moltiplicare il numero piu' grande che abbiamo a disposizione (4096) in modo che tra tutte le combinazioni il risultato finale sia quello piu' basso. Quindi se la matematica non e' un'opinione: 0 + (15 * 1 ) = 15 15 + (15 * 16 ) = 255 255 + (15 * 256) = 4095 4095 + (7 * 4096) = 32767 Di conseguenza il limite si sposta a 327.66. Mmmm... sospetto... In secondo luogo che succede al valore di backup? Diamo un'occhiata alla classica terna: 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 Se notate il solo nybble che cambia e' il secondo. Decresce sempre di 4 (se considero quel tipo di numerazione ovvero di uno). Ma allora il mio checksum non potrebbe raggiungere ne' scendere sotto il valore 0CC. Calcolatrice alla mano (rifaccio il procedimento di prima), la prima volta che ottengo questo checksum e' per 3839. Mmmmm ancora piu' sospetto... Se poi uniamo insieme le due cose il limite scende ancora piu' in basso. Prendiamo infatti 44C: diventa credito precedente --> 0CC e che compare nel backup? La prima volta che si crea questo problema e' per 17.91, troppo poco!!! E qui le cose si complicano o forse no... Ricordate il nostro HN1 che abbiamo considerato costante per tutto il tempo? E se in realta' si dovesse ragionare con un numero di 4 cifre e non di tre? Le prove fatte (sono riuscito a caricare in una macchinetta anche i famigerati 655.35 euro, in altre il limite e' invece 9.99) confermano questa ipotesi. Di conseguenza la formula finale sara': credito / 2^12 = v1 resto r1 r1 / 2^8 = v2 resto r2 r2 / 2^4 = v3 resto r3 r3 / 2^0 = v4 resto 0 187 - (v1 + v2 + v3 + v4) = valore decimale da convertire in base 4 ecc... oppure se il credito viene convertito in esadecimale: BB - ( somma delle cifre del credito in hex) = valore hex da converire in base 4 ecc... Chapter 101 : IL CONTATORE Nell'ART1 si accennava ad altri tre byte e cioe' quelli presenti agli indirizzi: 00B, 018 e 01B. Dai dati in mio possesso, effettivamente, i byte 00B e 01B sembrano essere i contatori del numero di operazioni. Ne ho avuto maggiore certezza quando nell'acquisto di una nuova chiavetta quei due byte valevano entrambi 00. Superata la FF-esima operazione entrano in causa anche i byte 00A e 01A che fino a quel momento erano rimasti a 00. Quindi semplicemente il contatore prosegue: ... 00FE 00FF 0100 0101 ... Discorso diverso per cio' che riguarda il byte 018 (che chiameremo "contatore-"). In una chiavetta ancora vergine questo byte e' settato a E7. Quindi bisogna capire in che modo esso decresce e se il suo comportamento e' regolare come per 00B e 01B. Ecco alcuni valori che avevo a disposizione presi anche da diverse chiavi e confrontati con il valore del contatore (contatore+): contatore+ contatore- 0001 E6 004A D9 004B D8 0050 E2 0053 DF 012A DA Anche qui sembrerebbe esserci un rapporto di decrescita e crescita trovato per i checksum del credito. Per le verifiche che ho potuto effettuare, infatti, sembra che il comportamento del byte 018 sia molto simile. Ho azzardato anche qui una formula (che questa volta ho lasciato in esadecimale visto che risulta piu' semplice fare i calcoli, non ci sono altre conversioni e il contatore+ e' dato proprio in esadecimale): contatore- = E7 - (cifre numeriche del contatore+) Proviamo con alcuni numeri: 4A: E7 - (4 + A) = D9 OK! 50: E7 - (5) = E2 OK!! 12A: E7 - ( 1 + 2 + A) = DA OK!!! Diamo ora una controllatina al valore limite FFFF: E7 - (F + F + F + F) = AB ---> Sembrano non esserci problemi E se qualche affezionato consumatore superasse le 65535 operazioni, da prove effettuate, verranno utilizzati anche i byte 009 e 019 e in quel caso il limite si sposta a FFFFFF quindi: E7 - (F + F + F + F + F + F) = 8D ---> Sembrano non esserci problemi nemmeno qua Ok se non vi accontentate ancora vi dico che superato tale numuro tutto riparte da 0. Ne avete abbastanza? Si'? Allora concludete qua la lettura altrimenti... Chapter 110 : GLI ALTRI BYTE... Nell'analisi che ho potuto fare su 3 chiavette diverse (2 dello stesso produttore e una terza di diversa provenienza) sono giunto alle seguenti conclusioni: 1) Nelle chiavette sono memorizzati 40 byte di informazioni mentre i rimanenti sono dati di backup. 2) Appare oppurtuno dividere questi 40 byte in 10 dati di 4 byte ciascuno che identificano un certo valore corrispondente a (e' ragionevole pensare ai dati indicati sul sito della coges considerato che sono proprio 10): - Codice gestore - Codice reparto - Codice sezione - Codice utente - Codice gruppo di continuita' - Credito della chiave - Valore del credito precedente - Numero di matricola - Giorno di produzione - Numero di operazioni effettuate Gli indirizzi dei 10 dati che ho preso in considerazione (ho scelto come valori "normali" i byte che compaiono per primi in ordine di indirizzo) sono: 0) 000 ?? valore variabile su ogni chiavetta ?? 1) 004 ?? valore variabile su ogni chiavetta ?? 2) 00C ?? valore costante per tutte le chiavette ?? 3) 018 Numero di operazioni effettuate (in 008 non compare il checksum) 4) 020 ?? valore costante per le chiavette dello stesso produttore ?? 5) 028 ?? valore costante per tutte le chiavette ?? 6) 040 ?? valore costante per tutte le chiavette ?? 7) 044 Credito della chiave 8) 048 ?? valore variabile su ogni chiavetta ?? 9) 04C Valore del credito precedente Un'osservazione va fatta per l'indirizzo 020. Dato che il valore memorizzato cambia solo nel caso si utilizzi una chiavetta di un diverso produttore e' possibile che questo dato sia il "Codice gestore" anche se ovviamente non ne posso avere la certezza. Il fatto interessante e' che se applico a questi 4 byte il metodo per individuare il credito e infine ne verifico il checksum ottengo un risultato coerente con cio' che mi aspetterei dalle formule viste precedentemente (del credito). L'unica differenza e' che nel calcolo del checksum, nella sottrazione, non compare piu' 187, ma 223 . Avendo a disposizione solo due termini (due produttori diversi) non posso essere certo che cio' sia corretto, ma se non fosse cosi' sarei incappato in una curiosa coincidenza. Non e' tutto! Dato che 3 dei dati osservati (credito chiavetta, credito precedente, codice gestore) seguono una precisa regola (quella del credito trovata nell'ART1 con il calcolo del checksm visto in questo documento) mi sono chiesto se ci fossero altri gruppi di 4 byte dipendenti invece dalla regola individuata nel contatore. Ho verificato che in effetti i dati agli indirizzi 000, 004 (e probabilmente anche 00C, ma essendo costante per tutte e tre le chiavette non ho potuto verificarlo) utilizzano lo schema "contatore- contatore+". In particolare il valore iniziale per 000 e' FF (non piu' quindi E7) mentre il valore per 004 e' FB (se valesse la stessa regola anche per 00C sarebbe F3). Lo potete verificare velocemente anche voi semplicemente sommando al numero esadecimale presente nel primo byte le cifre dei restanti 6 nybble. Ad esempio: 000: E4 05 18 58 E4 + 0 + 5 + 1 + 8 + 5 + 8 = FF Nonostante abbia avuto solo tre dati su cui verificare questo comportamento dubito che si tratti di una semplice coincidenza visto che rispecchierebbe esattamente cio' che avevo osservato anche per il contatore. Percio' molto probabilmente il valore (che sia codice matricola o codice utente o altro non lo so) da tenere in considerazione e' quello creato dai 3 byte finali mentre il primo byte e' una sorta di checksum. Nell'esempio fatto il valore e' quindi 51858. Ad avvalorare invece la tesi che anche per l'indirizzo 00C ci sia una regola di tipo "contatore" e' il termine di backup che risulta modificato (un decremento di 10 in base esadecimale come del resto anche per i backup di 000 e 004) solo per il primo byte. In tutti i casi considerati infatti l'unico valore che viene modificato nei byte di backup e' sempre (e se ne capisce ovviamente la ragione) il checksum. Ma siamo sicuri che con queste due formule (quella del credito e del contatore) abbiamo risolto ogni cosa? Osserviamo i 4 byte presenti all'indirizzo 048 di una delle chiavette: 048: 80 81 84 EE A prima vista sembrerebbe un dato memorizzatto con il sistema del credito. C'e' pero' una differenza: il quarto byte!!! Abbiamo visto che tutti gli HN assumo valori 0, 4, 8, C mentre qui compare per la prima volta un E. Si tratta di un dato memorizzato con una nuova regola o e' lo stessa formula del credito? Anche se tutto cio' che e' stato detto nell'ART1 e nel capito che tratta i checksum e' corretto c'e' una precisazione da fare. Nel calcolo del credito venivano utilizzati i LN e i check erano gli HN. In realta' il check utilizza solo i primi due bit degli HN e i rimanenti bit servono per la scrittura di numeri ancora superiori a 65535 (gli esponenziali continuano 2^16, 2^18, 2^20, 2^22). Vediamo questo esempio (il checksum di partenza trovato qui vale B7): 048: 80 81 84 EE in binario --> 10 00 00 00 10 00 00 01 10 00 01 00 11 10 11 10 ^^ ^^ ^^ ^^ \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / 1010 1011 hex: A B \__________ ____________/ Checksum: AB *2^22 *2^6 *2^20 *2^4 *2^18 *2^2 *2^16 *2^0 \ / \ / \ / \ / 00 00 00 00 00 01 00 01 00 10 11 10 \ \ \ \ *2^14 *2^12 *2^10 *2^8 lo(LN1) -> 00 -> 0 * 64 = 00 + lo(LN2) -> 01 -> 1 * 16 = 16 + lo(LN3) -> 00 -> 0 * 4 = 0 + lo(LN4) -> 10 -> 2 * 1 = 2 + primo passo: 18 hi(LN1) -> 00 -> 0 * 16384 = 0 + hi(LN2) -> 00 -> 0 * 4096 = 0 + hi(LN3) -> 01 -> 1 * 1024 = 1024 + hi(LN4) -> 11 -> 3 * 256 = 768 + secondo passo : 1792 lo(HN1) -> 00 -> 0 * 4194304 = 0 + lo(HN2) -> 00 -> 0 * 1048576 = 0 + lo(HN3) -> 00 -> 0 * 262144 = 0 + lo(HN4) -> 10 -> 2 * 65536 = 131072 + terzo passo : 131072 Sommo tutto: 18 + 1792 + 131072 = 132882 Converto in esadecimale 132882 -> 20712 Applico la formula finale: B7 - ( 2 + 0 + 7 + 1 + 2 ) = AB -> il nostro checksum!!! OK! Ho osservato inoltre che questo dato potrebbe o quasi sicuramente e' il giorno di produzione. Per le tre chiavette ho ottenuto questi valori espressi in esadecimale: 20712 10516 120 Vediamo se cosi' vi dicono qualcosa: 2002 - 07 - 12 2001 - 05 - 16 2000 - 01 - 20 Che ne dite.. potrebbe essere? Riscriviamo un po' le cose: 0) 000 ?? valore variabile su ogni chiavetta ?? 1) 004 ?? valore variabile su ogni chiavetta ?? 2) 00C ?? valore costante per tutte le chiavette ( =20013 ) ?? 3) 018 Numero di operazioni effettuate 4) 020 Codice gestore 5) 028 ?? valore costante per tutte le chiavette ( =0 ) ?? 6) 040 ?? valore costante per tutte le chiavette ( =65536 ) ?? 7) 044 Credito della chiave 8) 048 Giorno di produzione 9) 04C Valore del credito precedente Il capitolo successivo svelera' perche' tutto quello che ho detto fin qui e' senza ombra di dubbio corretto e ha anche una sua precisa spiegazione-regola. Chapter 111 : IL MISTERO E' SVELATO PER TUTTI I BYTE Abbiamo visto come tutti i valori memorizzati nella chiavetta hanno un proprio checksum. Abbiamo anche visto che questo checksum, nonostante non segua le stesse regole, ha sempre un suo valore di partenza. Scriviamo i primi termini in ordine di indirizzo valutando anche i check dei backup: indirizzo checksum 000: FF 004: FB 008: ? 00C: F3 010: EF 014: EB 018: E7 01C: E3 Notate nulla di strano? Visto che sono alla fine non ho voglia di spendere ancora tante parole percio' vi diro' semplicemente la soluzione. Tutti i 10 valori considerati (e quelli di backup) hanno un proprio checksum di partenza. Vale questa regola: checksum di partenza = FF - indirizzo del valore Quindi se osservo i valori termini precedenti: 00 + FF = FF 04 + FB = FF 08 + F3 = FF 10 + EF = FF ... Anche il nostro 187 nasce proprio da questa regola: 187 ->> in hex ->> BB ->> BB+ 44 = FF Se notate infine FF (256) e' la capacita' della nostra memoria EEPROM (anche se gli ultimi 128 byte non vengono utilizzati). Riassumendo possiamo dividere (i primi 128 byte) in 4 sezioni: - da 000 a 01C compreso, sono presenti 4 dati che seguono la regola del contatore (i rimanenti si possono considerare temini di backup escludendo 008 in cui non compare il checksum); - da 020 a 03C compreso, sono presenti 2 dati che seguono la regola del credito (i rimanenti si possono considerare temini di backup); - da 040 a 05C compreso, sono presenti 4 dati che seguono la regola del credito (i rimanenti si possono considerare temini di backup); - da 060 a 07C compreso, non e' presente nessun dato, ma solo tante FF. Dopo questo passo avanti, tutti i discorsi fatti precedentemente, se pur corretti, assumono una prospettiva diversa. E' ora possibile individuare per tutti i termini (i gruppi di 4 bit) un preciso valore che assumera', a seconda della posizione, un preciso significato. Dei dieci dati presenti ne sono stati rivelati 4 (5 se 020 e' il codice gestore). A voi i rimanenti! Chapter 1000 : THE END E I RINGRAZIAMENTI Credo di avere detto proprio tutto! Spero che in futuro qualcuno possa aggiungere un altro tassello per la conoscenza completa delle chiavette coges. Ringrazio Cavallo de Cavallis e DreadNought per il loro ART1 altrimenti col ca**o che mi tiravo 'ste menate. Ringrazio in particolare Cavallo de Cavallis per i suoi suggerimenti e correzioni. Ringrazio il mio "clone coges-simbiotico" che ha risolto il problema dei checksum nel mio stesso giorno! Magari c'e' un altro modo di vedere le cose! Boh! Ringrazio Marco per aver portato la sua "schedina" all'UNI e per avermi cosi' permesso di fare le ultime prove, piu' rapidamente. Ringrazio infine i miei due amici Pat e Silvia. Il primo per tutte le volte che pazientemente ascolta le mie "nuove scoperte". La seconda perche' sempre sopporta i vari discorsi d'informatica che le risultano incomprensibili. Che rimane? Ciao a tutti e alla prossima (se ci sara')!!! -[ WEB ]---------------------------------------------------------------------- http://www.bfi.cx http://bfi.freaknet.org 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 ]------------------------------------ ==============================================================================