Salve.
Penso sia il fulcro della crittografia delle chiavette.
Ad ogni ricarica vengono aggiornati alcuni registri (ho avuto sotto mano un caso dove si sono aggiornati 6 registri e uno in cui se ne sono aggiornati 8), di cui:
- Tre contatori (sicuramente uno è il 0x6, e presumibilmente anche il 0x12 e il 0x16)
- Gli 0x21 e 0x25 che cambiano (quasi) totalmente valore (dunque mi viene da dire che sono hashati, suppongo siano importanti quindi)
- 0x3C che non comprendo
Poi in un dump mi sono visto aggiornare anche lo 0x23, lo 0x27 e lo 0x34, in un altro invece mi hanno aggiornato lo 0x35.
A breve provo un'altra ricarica (vera) e voglio vedere quali registri vengono cambiati, tengo lo storico.
Sarebbe interessante cercare di capire quali di questi dati vanno ad influire nella generazione della chiave di cifratura (sicuramente ci sono ID della chiavetta e il contatore 0x6, che è solo decrementale, e per questo denominato "OTP").
Se hai qualche novità condividi pure!
Penso sia il fulcro della crittografia delle chiavette.
Ad ogni ricarica vengono aggiornati alcuni registri (ho avuto sotto mano un caso dove si sono aggiornati 6 registri e uno in cui se ne sono aggiornati 8), di cui:
- Tre contatori (sicuramente uno è il 0x6, e presumibilmente anche il 0x12 e il 0x16)
- Gli 0x21 e 0x25 che cambiano (quasi) totalmente valore (dunque mi viene da dire che sono hashati, suppongo siano importanti quindi)
- 0x3C che non comprendo
Poi in un dump mi sono visto aggiornare anche lo 0x23, lo 0x27 e lo 0x34, in un altro invece mi hanno aggiornato lo 0x35.
A breve provo un'altra ricarica (vera) e voglio vedere quali registri vengono cambiati, tengo lo storico.
Sarebbe interessante cercare di capire quali di questi dati vanno ad influire nella generazione della chiave di cifratura (sicuramente ci sono ID della chiavetta e il contatore 0x6, che è solo decrementale, e per questo denominato "OTP").
Se hai qualche novità condividi pure!
Salve @Elchavo96
Ci sono tutte queste informazioni, ma sono cifrate.
Viene aumentato, inoltre, incrementalmente il numero di registri modificati dalla prima ricarica di due in due (credito precedente, e data cambiamento) fino ad un massimo di 12 (tenendo traccia quindi delle 6 operazioni passate e delle relative date, oltre al credito attuale).
Se avrò qualche sviluppo, mi farò sentire.
Buona giornata
theblackdog
Ci sono tutte queste informazioni, ma sono cifrate.
Viene aumentato, inoltre, incrementalmente il numero di registri modificati dalla prima ricarica di due in due (credito precedente, e data cambiamento) fino ad un massimo di 12 (tenendo traccia quindi delle 6 operazioni passate e delle relative date, oltre al credito attuale).
Se avrò qualche sviluppo, mi farò sentire.
Buona giornata
theblackdog
Finalmente qualcuno che sta curiosando e non cerca solo la pappa pronta.
Quello che ho scoperto fino adesso è che come si diceva qui sopra il blocco 0x06 è (come da specifiche srix4k) il contatore che decrementa ad ogni operazione fatta sulla chiavetta. Poi nel mio dump i blocchi 0x12 e 0x16 sono due contatori che si incrementano ad ogni operazione, nel mio caso hanno lo stesso valore, ma in un dump che ho recuperato online sono diversi. Non so perchè siano due ma è cosi. I blocchi da 0x34 a 0x3B conengono lo storico delle ultime 8 operazioni con importo e data, il blocco 0x3C contiene il puntatore per sapere quale delle 8 posizioni è l'ultima scritta. I blocchi 0x23 e 0x27 contengono il credito precedente. Il credito attuale è salvato nei blocchi 0x21 e 0x25 e sono gli ultimi che mi manca di capire come sono codificati. Gli altri credo di aver capito come sono codificati (online si trova ancora qualche cosa... si fa fatica ma qualche cosa si riesce a trovare, e poi... dai non ci credo che nessuno abbia fatto un reverse di m*ke* ...)
Ultimamente mi hanno cambiato le chiavi, quindi niente più possibilità di fare dump e prove, e la cosa è passata un po in secondo piano però la curiosità di capire il resto mi rimane
Quello che ho scoperto fino adesso è che come si diceva qui sopra il blocco 0x06 è (come da specifiche srix4k) il contatore che decrementa ad ogni operazione fatta sulla chiavetta. Poi nel mio dump i blocchi 0x12 e 0x16 sono due contatori che si incrementano ad ogni operazione, nel mio caso hanno lo stesso valore, ma in un dump che ho recuperato online sono diversi. Non so perchè siano due ma è cosi. I blocchi da 0x34 a 0x3B conengono lo storico delle ultime 8 operazioni con importo e data, il blocco 0x3C contiene il puntatore per sapere quale delle 8 posizioni è l'ultima scritta. I blocchi 0x23 e 0x27 contengono il credito precedente. Il credito attuale è salvato nei blocchi 0x21 e 0x25 e sono gli ultimi che mi manca di capire come sono codificati. Gli altri credo di aver capito come sono codificati (online si trova ancora qualche cosa... si fa fatica ma qualche cosa si riesce a trovare, e poi... dai non ci credo che nessuno abbia fatto un reverse di m*ke* ...)
Ultimamente mi hanno cambiato le chiavi, quindi niente più possibilità di fare dump e prove, e la cosa è passata un po in secondo piano però la curiosità di capire il resto mi rimane
Salve @megajump
Molto bene, ottimi elementi su cui lavorare.
Lo studio più interessante sarebbe capire dalle variazioni dei valori cifrati come vengono codificate le informazioni (bucare la crittografia dovrebbe essere molto istruttivo, e porre le basi di approccio per ogni tipo di crittografia a basso livello, e non solo le mk).
Non penso quindi farò un reverse engineering del software, sarebbe su per giù come avere la pappa pronta (in senso molto lato) ahah
Però se non ci cavassi gli zampetti a lungo andare, si potrebbe anche prendere in condierazione, e imparare dalla "sconfitta", guardando la chiave e ipotizzando come viene generata.
Non è qualche caffè gratis che dovrebbe essere interessante, ma lo spunto per ottenre padronanza in materie spinose come la crittografia.
Molto bene, ottimi elementi su cui lavorare.
Lo studio più interessante sarebbe capire dalle variazioni dei valori cifrati come vengono codificate le informazioni (bucare la crittografia dovrebbe essere molto istruttivo, e porre le basi di approccio per ogni tipo di crittografia a basso livello, e non solo le mk).
Non penso quindi farò un reverse engineering del software, sarebbe su per giù come avere la pappa pronta (in senso molto lato) ahah
Però se non ci cavassi gli zampetti a lungo andare, si potrebbe anche prendere in condierazione, e imparare dalla "sconfitta", guardando la chiave e ipotizzando come viene generata.
Non è qualche caffè gratis che dovrebbe essere interessante, ma lo spunto per ottenre padronanza in materie spinose come la crittografia.
Ciao ragazzi! Mi sto anche io addentrando nello studio delle mk dal momento che il software mk1.0 nel mio caso non è efficace. Sarebbe bello riuscire a trovare delle SRIX4K cinesi in stile Mifare 1K con uid rewriteable 
. Basterebbe dumpare la chiavetta sulla nuova memoria per essere a posto! Purtroppo cercando in rete non ho trovato nulla a riguardo. In ogni caso questo pomeriggio inizio con lo studio dei dump e se ho qualche info vi faccio sapere!
. Basterebbe dumpare la chiavetta sulla nuova memoria per essere a posto! Purtroppo cercando in rete non ho trovato nulla a riguardo. In ogni caso questo pomeriggio inizio con lo studio dei dump e se ho qualche info vi faccio sapere!Salve a tutti. Vi seguo da un po e sto apprezzando qst nuovo thread che vuole studiare gli algoritmi delle m*k*y, anzichè sprecare tempo a scrivere post con affermazioni eclatanti (mai supportate da prove) o richieste stupide, inutili o x nulla costruttive, spesso reiterate, solo xkè nn si ha la pazienza di andarsi a leggere i post precedenti.
Sono un appassionato di matematica ma nn so nulla di algoritmi, però ho deciso di contribuire postando i dump effettuati in qst giorni, magari nella speranza che possano fornire anche solo un piccolo spunto a qlcuno più illuminato di me.
osservazioni nuova chiavetta
-----------------------------
-acquistata vergine
-inserita nel distributore senza mettere soldi:
-dump:
campi modificati:
06 cambia da: 06: FF FF FF FF a 06: FE FF FF FF
18 e 19 cambiano da: 18: 8F CD 0F 48 C0 82 00 07 a 18: C1 45 C0 47 C6 0C C8 45
1c e 1d cambiano da: 1c: 8F 8D CF 48 C0 42 C0 07 a 1c: C1 45 80 47 C6 0C 88 45
21 cambia da: 2A EA 49 A0 a F6 CE D8 A0
25 cambia da: 2A EA 09 A0 a F6 CE 98 A0
- torno al distributore e carico 1 euro:
-dump:
06 cambia da: 06: FE FF FF FF a 06: FD FF FF FF
0e cambia da: 0e: FF FF FF FF a 0e: C0 C0 00 40
12 cambia da: 12: EC 00 00 01 a 12: EB 00 00 02
16 cambia da: 16: E8 00 00 01 a 16: E7 00 00 02
21 cambia da: F6 CE D8 A0 a 10 97 65 30
25 cambia da: F6 CE 98 A0 a 10 97 25 30
35 cambia da: FF FF FF FF a 5E 13 00 64
3c cambia da: 3c: FF FF FF FF a 3c: C0 05 99 83
tutti gli altri campi che nn ho citato sono rimasti come qnd la chiavetta era vergine.
Da qst dati deduco con certezza che il campo 06 è quello che decrementa ad ogni operazione.
Su tutti gli altri ho ancora buio assoluto. Nei prossimi giorni proverò scalando credito, ed eseguirò il dump ad ogni passaggio. Quando ho novità vi aggiorno
Sono un appassionato di matematica ma nn so nulla di algoritmi, però ho deciso di contribuire postando i dump effettuati in qst giorni, magari nella speranza che possano fornire anche solo un piccolo spunto a qlcuno più illuminato di me.
osservazioni nuova chiavetta
-----------------------------
-acquistata vergine
-inserita nel distributore senza mettere soldi:
-dump:
campi modificati:
06 cambia da: 06: FF FF FF FF a 06: FE FF FF FF
18 e 19 cambiano da: 18: 8F CD 0F 48 C0 82 00 07 a 18: C1 45 C0 47 C6 0C C8 45
1c e 1d cambiano da: 1c: 8F 8D CF 48 C0 42 C0 07 a 1c: C1 45 80 47 C6 0C 88 45
21 cambia da: 2A EA 49 A0 a F6 CE D8 A0
25 cambia da: 2A EA 09 A0 a F6 CE 98 A0
- torno al distributore e carico 1 euro:
-dump:
06 cambia da: 06: FE FF FF FF a 06: FD FF FF FF
0e cambia da: 0e: FF FF FF FF a 0e: C0 C0 00 40
12 cambia da: 12: EC 00 00 01 a 12: EB 00 00 02
16 cambia da: 16: E8 00 00 01 a 16: E7 00 00 02
21 cambia da: F6 CE D8 A0 a 10 97 65 30
25 cambia da: F6 CE 98 A0 a 10 97 25 30
35 cambia da: FF FF FF FF a 5E 13 00 64
3c cambia da: 3c: FF FF FF FF a 3c: C0 05 99 83
tutti gli altri campi che nn ho citato sono rimasti come qnd la chiavetta era vergine.
Da qst dati deduco con certezza che il campo 06 è quello che decrementa ad ogni operazione.
Su tutti gli altri ho ancora buio assoluto. Nei prossimi giorni proverò scalando credito, ed eseguirò il dump ad ogni passaggio. Quando ho novità vi aggiorno
Settore 35
- prima parte: 5E13 è la data di oggi. Non ho ben capito il meccanismo completo ma ieri era 5613 e l’altro ieri era 4E13 . Sembra che i primi due esadecimali vengano aumentati di 8 di volta in volta.
- seconda parte: 0064 è il credito attuale. Convertito da esadecimale in decimale è 100. Che equivale a €1 (100 centesimi).
Questo è ciò che ho capito al momento.
Buon giorno @lopoengmi
Tag Srix4k con UID ricambiabile non esistono, ma non sono sicuro sia l'uid della chiavetta di cui viene tenuto conto (magari mi sbaglio eh).
I blocchi 0x7 e 0x8 sono un UID che nelle chiavette vergini sono già presenti e non ricambiabili (anche se fanno parte dei blocchi cambiabili sono bloccati tramite una particolare impostazione del blocco 255, che una volta settata non prevede ritorno indietro.
Quindi tecnicamente sarebbe sufficiente avere un tag della stessa forma a cui viene bloccata quella zona di memoria con uno UID scelto e impostato prima, e dunque ricalcolati tutti i vari blocchi in base alle key generate da quel UID, cosa che si potrebbe fare anche semplicemente scrivendo brutalmente un dump sopra un tag nuovo e poi impostando il blocco 255.
Con una buona ablità a smontare e rimontare le chiavette si potrebbe forse fare. Forse.
Tag Srix4k con UID ricambiabile non esistono, ma non sono sicuro sia l'uid della chiavetta di cui viene tenuto conto (magari mi sbaglio eh).
I blocchi 0x7 e 0x8 sono un UID che nelle chiavette vergini sono già presenti e non ricambiabili (anche se fanno parte dei blocchi cambiabili sono bloccati tramite una particolare impostazione del blocco 255, che una volta settata non prevede ritorno indietro.
Quindi tecnicamente sarebbe sufficiente avere un tag della stessa forma a cui viene bloccata quella zona di memoria con uno UID scelto e impostato prima, e dunque ricalcolati tutti i vari blocchi in base alle key generate da quel UID, cosa che si potrebbe fare anche semplicemente scrivendo brutalmente un dump sopra un tag nuovo e poi impostando il blocco 255.
Con una buona ablità a smontare e rimontare le chiavette si potrebbe forse fare. Forse.
Buonasera @th3bl4ckd0g !
Sei stato illuminante, grazie! Mi sono letto anche la parte iniziale del documento sulle SRIX4K ed effettivamente la tua idea potrebbe funzionare.
La cosa che non mi è chiara è come fare a leggere (ed eventualmente modificare) il blocco 255 con il MyKey1.0
...
Un'altra cosa.. ho notato che ogni volta che ricarico la mia chiavetta cambia anche la data associata ad essa e assume valori non standard tipo 5d/19/1951 , sai per caso dove è salvata la data "di produzione" relativa alla chiavetta?
Buona serata!
Sei stato illuminante, grazie! Mi sono letto anche la parte iniziale del documento sulle SRIX4K ed effettivamente la tua idea potrebbe funzionare.
La cosa che non mi è chiara è come fare a leggere (ed eventualmente modificare) il blocco 255 con il MyKey1.0
...Un'altra cosa.. ho notato che ogni volta che ricarico la mia chiavetta cambia anche la data associata ad essa e assume valori non standard tipo 5d/19/1951 , sai per caso dove è salvata la data "di produzione" relativa alla chiavetta?
Buona serata!
La data di produzione è salvata nel blocco 08.
Il blocco 3C punta ad un blocco tra 34 e 3B per sapere qual è il blocco più recente.
Per calcolare la data di ogni transazione basta prendere i primi due byte di un blocco tra 34 e 3B, convertirli in binario e poi prendere le prime 5 cifre per il giorno, le prossime 4 per il mese e le ultime 7 per l'anno. Poi basta convertire da binario a decimale e formattare seguendo il seguente schema GG/MM/20YY.
Mentre per il credito, come già detto, basta convertire in decimale gli ultimi due byte e dividere per 100.
Il blocco 3C punta ad un blocco tra 34 e 3B per sapere qual è il blocco più recente.
Per calcolare la data di ogni transazione basta prendere i primi due byte di un blocco tra 34 e 3B, convertirli in binario e poi prendere le prime 5 cifre per il giorno, le prossime 4 per il mese e le ultime 7 per l'anno. Poi basta convertire da binario a decimale e formattare seguendo il seguente schema GG/MM/20YY.
Mentre per il credito, come già detto, basta convertire in decimale gli ultimi due byte e dividere per 100.
Interessante. Domani controllo i miei dump se la cosa funziona anche sulle ultime macchinette che ci sono in giro.
Se stai lavorando a qualcosa e ti servono ho alcuni dump di 2 chiavette fatti in varie occasioni. In entrambe NON si vede lo storico del credito dal pc, ma solo quello attuale e il precedente (ovviamente le chiavi sono funzionanti)
Onestamente non lo so. Come lo vedo?
Se posso dare una mano fai un fischio, anche in privato. Conoscenze di programmazione le ho, anche se non sviluppo più da un po di tempo
Sono quelli grigi e rettangolari, quelli per le vecchie chiavette.
Comunque guarda qui per info sul software: https://www.inforge.net/forum/threads/inverginare-chiavette-mykey.556132/post-5062442
Ho già tutto per ricreare MyKey da zero, però devo sistemare alcune cose
Questo dovrebbe essere un lettore di quelli vecchi insieme alle chiavette di vecchia generazione
Ultima modifica:
Si. Dove faccio le prove il lettore è di quelli li
Edit:
Piu tardi quando sono a un computer ci guardo
Messaggio unito automaticamente:
Edit:
Piu tardi quando sono a un computer ci guardo
Ricordo di aver letto qualche giorno fa qui sul forum che la data è salvata sul blocco 8 (Non vorrei sbagliarmi dovrei ritrovare il thread per esserne certo), quindi se fai un dump della chiavetta, modifichi quel blocco, e lo carichi con linux, potresti risolvere il problema data (Non è detto che poi la chiavetta vada)
DISCUSSIONI SIMILI
- In evidenza
-
- 2
-
- 983
- In evidenza
-
- 35
-
- 3K