Copy Link
Add to Bookmark
Report
BFi numero 12 file 06
==============================================================================
--------------------[ 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 <SteTry2001@katamail.com>
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 ]------------------------------------
==============================================================================
