Discussione Ufficiale Raccolta di STUDIO e RISOLUZIONE problemi con MyKey

[th3bl4ckd0g]

Io mi stupisco ogni giorno di quanta poca conoscenza ci sia in giro, anche sul funzionamento dei cloud ecc.
Provo a spiegare in breve il perché non è Nebular il problema dei ban:
- Se veramente il credito fosse controllato in cloud, altro che software 2.0, non ci sarebbe veramente speranza (no, nemmeno col cambio di UID, un semplice "IF" sarebbe sufficiente a imporre quello che è la normalità, ossia che una chiavetta vergine non presente nel DB abbia un credito a 0, invalidando le ricariche future)
- Se ci fosse una assenza di rete o disturbi che impediscono di comunicare il server, cosa farebbe la macchinetta? Ti consentirebbe di usare comunque la chiavetta? In caso tutte le sincronie sul db in cloud non sarebbero più consistenti, quindi sarebbe impossibile stabilire se la chiavetta è stata ricaricata regolarmente o meno. O magari bloccherebbe? Sarebbe ridicolo perdere degli "affari" per questa motivazione, soprattutto a causa dell'utilizzo di una rete non affidabile come GSM
- Col piffero che una chiavetta può essere reinverginata dopo un ban da Cloud (il ban si effettuerebbe su uid non modificabile, "anche i fermenti lattici lo sanno").

Dato che non voglio perdere troppo tempo, mi limito a queste tre validissime ragioni per cercare di comunicarvi il fatto che Nebular può essere usato solo a fini statistici, per tenere traccia di quello che succede (un pagamento può rimanere in un buffer, in attesa del ritorno della rete per essere inviato al server, ma il controllo sulla validità non può essere bloccante).

Ora, presento la realtà dei fatti.
Dopo innumerevoli rilevazioni (non dico come né quante, dico solo che ho svuotato un salvatadaio) posso dire con certezza che il fatidico aggiornamento che banna le chiavette è niente di più che una generazione e relativo controllo sui check di Credito Attuale e Credito Precedente (blocchi 0x25 e 0x27), che periodicamente vengono generati in maniera diversa tra macchinetta e software (la macchinetta, fallendo il check, brasa la chiavetta in sostanza).

Quindi, per favore, piantiamola di far girare allarmismi su controlli in cloud, che chiudono le menti di teste potenzialmente pensanti che potrebbero capire le basi del nuovo calcolo del check.

 

[th3bl4ckd0g]

Signore e signori

nuntio vobis gaudium magnum
Io e il buon @SEG0C ci siamo prodigati nell'impresa, e nella guerra abbiamo vinto una pesante battaglia.

Siamo riusciti a stabilire la legge parziale di generazione dei checksum su credito attuale (vale per i crediti multipli di 5, disponendo in futuro di dump con crediti non multipli di 5 proseguiremo gli studi), e la legge completa di generazione dei checksum su crediti precedenti. Non la scriverò qui perché non è semplice da spiegare, tuttavia il software di SEG0C "MIKAI" implementerà le nuove regole.
È inoltre in progetto di sviluppo la versione per windows (col nome di "MIK3") per i detentori di lettori ACR122U.
Per chi non detiene tale lettore, è anche in sviluppo una utility di "correzione" sulle scrittre effettuate da Myk* (inserendo il valore generato da MyK per i blocchi 0x21 e 0x23 genererà i corrispettivi 0x25 e 0x27 corretti, che andranno poi scritti a mano tramite Myk).

Detto questo, a breve forniremo aggiornamenti.
Buona giornata a tutti

 

[authfail3d]

Il mio software è per Windows. Scritto in linguaggio nativo windows. Utilizza librerie windows. Ci siamo quasi eh... Testo un'ultima cosa e ci sono.

Messaggio unito automaticamente: 15 Agosto 2020

Come promesso, ho finito! Ora mi occuperò di contattare chi di competenza per farmi da testers.

Messaggio unito automaticamente: 16 Agosto 2020

Ciao a tutti!
Chi volesse far parte dei tester di MIK3 mi scriva in privato, che provvederò a fornire il link del mio gruppo telegram, creato appositamente.

Grazie, e buona domenica a tutti.

 

[_Ptr_]

Su http://mikaiusaeno2wju5iwawhfq7cbpasrkpetmhhwzb266u7vcbnxxir7ad.onion/ c'è una spiegazioni più completa.

Ti mancano i blocchi 10, 11, 14 e 15.
Se vuoi ricostruirli è abbastanza semplice, basta prenderli da 3F in poi.

Giusto per completezza, visto che quei blocchi sono parzialmente descritti nella pagina su tor, i primi due byte del blocco 10 sono il numero di giorni fra il primo gennaio 1995 (1/1/95) e la data di produzione della chiavetta (quella che sta al blocco 8, nel suo caso è 15 03 11).

Usando un sito che ci facilita l'operazione, possiamo calcolare il numero di giorni (ricordatevi di togliere la spunta a "Include end date in calculation (1 day is added)")

Calculate Duration Between Two Dates – Results

Results page for Date Calculator. Shows number of days between two dates.

www.timeanddate.com

Che difatti risulta 5917 giorni, proprio il dato che si trova nei primi due byte (59 17). Occhio che non viene fatta nessuna conversione da decimale a esadecimale, il dato viene salvato proprio come se fosse un hex.

 

[SEG0C]

Io mi stupisco ogni giorno di quanta poca conoscenza ci sia in giro, anche sul funzionamento dei cloud ecc.
Provo a spiegare in breve il perché non è Nebular il problema dei ban:
- Se veramente il credito fosse controllato in cloud, altro che software 2.0, non ci sarebbe veramente speranza (no, nemmeno col cambio di UID, un semplice "IF" sarebbe sufficiente a imporre quello che è la normalità, ossia che una chiavetta vergine non presente nel DB abbia un credito a 0, invalidando le ricariche future)
- Se ci fosse una assenza di rete o disturbi che impediscono di comunicare il server, cosa farebbe la macchinetta? Ti consentirebbe di usare comunque la chiavetta? In caso tutte le sincronie sul db in cloud non sarebbero più consistenti, quindi sarebbe impossibile stabilire se la chiavetta è stata ricaricata regolarmente o meno. O magari bloccherebbe? Sarebbe ridicolo perdere degli "affari" per questa motivazione, soprattutto a causa dell'utilizzo di una rete non affidabile come GSM
- Col piffero che una chiavetta può essere reinverginata dopo un ban da Cloud (il ban si effettuerebbe su uid non modificabile, "anche i fermenti lattici lo sanno").

Dato che non voglio perdere troppo tempo, mi limito a queste tre validissime ragioni per cercare di comunicarvi il fatto che Nebular può essere usato solo a fini statistici, per tenere traccia di quello che succede (un pagamento può rimanere in un buffer, in attesa del ritorno della rete per essere inviato al server, ma il controllo sulla validità non può essere bloccante).

Ora, presento la realtà dei fatti.
Dopo innumerevoli rilevazioni (non dico come né quante, dico solo che ho svuotato un salvatadaio) posso dire con certezza che il fatidico aggiornamento che banna le chiavette è niente di più che una generazioen e relativo controllo sui check di Credito Attuale e Credito Precedente (blocchi 0x25 e 0x27), che periodicamente vengono generati in maniera diversa tra macchinetta e software (la macchinetta, fallendo il check, brasa la chiavetta in sostanza).

Quindi, per favore, piantiamola di far girare allarmismi su controlli in cloud, che chiudono le menti di teste potenzialmente pensanti che potrebbero capire le basi del nuovo calcolo del check.

Ho finito i Mi Piace giornalieri a quanto pare... spiegazione completa, perfetta.

L'allarmismo del cloud è solo per fare vendere la versione FAKE del software.

"MyKey AntiNebular 2020 XDXDXD" -cit. Pagliaccio

 

[jsell74]

Buongiorno a tutti, in vista dei cambiamenti avvenuti con gli aggiornamenti del software di COGES ci sarebbe da dedicarsi allo studio e alla condivisione al fine di trovare una soluzione PUBBLICA ai numerosi problemi , ovvio dirvi che questa non deve essere la sezione del mercatino, e che chi ha soluzioni già impacchettate e non le vuole condividere gratuitamente è pregato di rimanere esterno a questa discussione.

Grazie


AGGIORNAMENTO AL 09/02/2020


Penso sia il momento di fare il punto della situazione.

Più o meno ad ottobre/novembre hanno iniziato a fare aggiornamenti firmware dei lettori COGES con questo aggiornamento il calcolo del credito subisce livelli di verifica più approfonditi, il risultato che con MyKey la chiavetta va in blocco presentando la data in ff/ff/19ff e a volte anche il record 00 viene scritto con tutti gli 00 anziché le FF

In concomitanza di questo aggiornamento si sono fatti avanti una serie di speculatori che promettendo versioni aggiornate di MyKey ver. 2.0.0 o 2.0.1 “anti nebular” hanno preso la ver. 1.0.0 e modificato il nome vendendo il software a cifre da capogiro, in alcuni casi ci sono segnalazioni di addirittura 200€ che ad ogni modo erano tutte ver. FAKE

L’unica differenza reale da me riscontrata è sulla 1.0.0 la versione di Sgajianello che è totalmente buggata(alcuni pensano volontariamente) e quella di Rossi Roberto, probabilmente un nome di fantasia, che però si è dimostrata un po più stabile.

Di qui l’idea di SEGOC di una versione opensource, unica limitazione momentanea che funziona su linux(limitazione che a mio avviso è anche positiva) quindi non utilizzabile da tutti e difficilmente vendibile su eBay. Ricordo a tutti CHE MODIFICARE LE CHIAVETTE PER USUFRUIRE GRATIS DEI PRODOTTI DEI DISTRIBUTORI E' LA STESSA COSA CHE RUBARE QUEL PRODOTTO, QUINDI E’ UN AZIONE DEL TUTTO ILLEGALE PERSEGUIBILE DAL C.P.
Il solo vero aspetto del progetto MIKEI è la ricerca.

Il progetto MIKEI lo potete trovare al seguente LINK

http://mikaiusaeno2wju5iwawhfq7cbpasrkpetmhhwzb266u7vcbnxxir7ad.onion/

Raggiungibile solo tramite Browser TOR


Di qui non dico altro potete fare riferimento al Link se volete anche voi studiare questo progetto

 

[Inbocca]

Servono più dump simultanei, comunque per chi vuole buttar via 5 minuti questa è una buona lettura https://www.mouser.com/datasheet/2/389/CD00058071-224663.pdf

 

[SEG0C]

Quello è come il Virus Corona....quando te lo prendi è difficile debellarlo...io non ci sono riuscito anche se sul datasheet del srix4k è scritto che il campo 00 è ripristinabile

Ho fatto il tool apposta ./mikai-otp

 

[SEG0C]

Una volta che hai estratto i file su Linux devi andare nella cartella dei file dal terminale usando il comando cd.
Una volta dentro alla cartella dal terminale puoi digitate i vari comandi per fare le varie operazioni.
I comandi sono:
./mikai (legge la chiave dicendoti Key A Key B data di produzione UID ecc.)
./mikai-reset (inverginare)
./mikai-restore XXX.bin dove xxx è il nome del dump ripristina il dump
./mikai-read xxx.mkd -v
./mikai-diff xxx.mkd yyy.mkd - v (fa vedere le differenze tra 2 dump xxx e yyy)
./mikai-dump (crea un dump, non mi è chiaro se lo fa solo mkd o se ce la possibilità di farlo scrivere anche in bin)
./mikai-otp (rimette le FF se nei primi 5 campi hai degli 00)

Messaggio unito automaticamente: 2 Febbraio 2020

Ringrazio comunque jsell74 per la spiegazione dettagliata in italiano dei vari comandi

Scusate se non ho spiegato cosa fanno i comandi, ma mi sto concentrando sullo sviluppo rispetto alla documentazione.

Comandi (potete aggiungere -v ad ogni comando per vedere cosa sta facendo):
./mikai - Mostra i dettagli della chiavetta
./mikai -u - Aggiorna credito
./mikai-reset - Resetta allo stato di fabbrica (invergina)
./mikai-otp - Scrive FF nei primi 5 blocchi (OTP bits)
./mikai-dump <nomefile> - Crea un dump (Il file può avere l'estensione che preferite)
./mikai-dff <file1> <file2> - Mostra solo le differenze tra due dump
./mikai-dff <file1> <file2> -ac - Mostra le differenze tra due dump evidenzionadole con colori
./mikai-read <file> - Legge dump
./mikai-restore <file> - Ripristina il dump (è consigliato eseguire ./mikai-reset dopo questo)

 

[Inbocca]

io andando a vedere una serie di dump fatti 1x1 man mano che si utilizza la chiavetta in modo regolare ho notato che gli unici campi che cambiano su una base di 15 dump sono

06 contatore che diminuisce ad ogni registrazione 1 valore
12 contatore 1
16 contatore 2
21 credito attuale
23 credito precedente
25 credito attuale meno 40 sul terzo settore
27 credito precedente meno 40 sul terzo settore
e da 34 a 3b penso che siano lo storico delle ricariche con data annessa...

io penso che il problema sia in un calcolo tra i contatori.... poi sicuramente mi sbaglierò ma x le lacune che ho in informatica non riesco a trovare altro che possa far bloccare le chiavette...se dipendesse da Nebular connesso ad internet

1) non accetterebbe più chiavette bloccate anche se inverginate ...sarebbero bannate dal'UID che non può essere cambiato e quindi ci sarebbe solo da buttarle
2) se io carico la chiavetta da un distributore vecchio quindi senza nebular e poi la uso su uno nuovo non avendo registrato l'operazione sul server di nebular mi dovrebbe bannare (bloccare) la chiave e questo non può succedere, si prenderebbero denunce in giro...il principio delle chiavette è proprio quello, carico e uso da dove voglio.
potrebbe al massimo cambiare qualcosa al codice regione (fornitore del servizio) diciamo che ogni codice regione ha due codici in realtà quello di nebular e quello non nebular diciamo che in fase di ricarica magari cambia qualcosa anche li....
tutte supposizioni magari stro***te.

Credo tu abbia detto molte meno stro***te di quel che credi!
La questione nebular è stata molto enfatizzata da certi utenti che guarda caso avevano interesse nel vendere aggiornamenti, ma di base era uno specchietto per le allodole utile ad ingannare l'utenza che per questione di abilità/conoscenza si affidava al solo software per la ricarica.

 

[Elchavo96]

ci tenevo a far presente una cosa.
il pagliaccio qualche tempo fa mi scrisse, chiedendomi se ero interessato alla sua versione software di mykey, gli risposi che avevo già una versione fixata con invergina chiavetta e importa esporta gestore funzionante e che quindi non mi interessava.
quando seppe della mia versione mi chiese di passargliela per poterla studiare e implementarci dentro il fix "anti-ban nebular", siccome non ero al corrente del suo comportamento con gli altri utenti e del fatto che ero curioso della versione che possedeva, mi fidai di lui e gli passai la mia versione 1.0.2 di mykey e gli chiesi cosa faceva tale anti-ban visto che non capivo come poteva il software aggirare un controllo cloud del credito.
a questo quesito non mi ha mai risposto e mi ha messo pressione per passargli subito il software per poterlo "fixare" con la funzione anti-ban.
quando poi gliel'ho passato mi ha detto che non poteva essere fixata perche era stata gia fixata ma male.
alla luce dei fatti odierni possiamo dire che era tutta una menzogna per farsi passare la mia versione del software.
E se a qualcuno ha proposto il mykey 1.0.2 è perchè se la è fatta passare da me con l'inganno.

 

[dav26]

.

Messaggio unito automaticamente: 5 Febbraio 2020

ciao bellissimi;
si sono proprio io quello che vende il software su ebay.
personalmente mi sto interessando molto in questo mondo poiché credo che chi sappia decriptare ad esempio una key a e una key b di una mifare classic 1k abbia una enooorme arma in mano.
sarei ipocrita a nascondervi che lo sto facendo anche per scopi di lucro guadagnandoci ma non vi nascondo anche che sono terrorizzato dagli amici con la macchina nera e gialla.
sto combattendo errori e ritardati che vogliono la chiavetta quando io gli vendo solo il programma,però' alla fine ci guadagno quindi chissene.

vi posso confermare che io sono stato UNO dei Primi a vendere il software su ebay e mi danno quasi al pazzo persone come game_furios ed altri che cerano di copiarmi spudoratamente volendo vendere piu' di me...
potrà sembrare una cazzata ma io ho preso seriamente la sfida contro gamefurios inculan***o in vari modi.
il primo metodo appunto quello di abbassare il prezzo creandogli una concorrenza al limite della pazienza (inizialmente con la 1.0.0).
La seconda dopo aver visto che il tardo aveva comprato il programma a 200 euro per poi metterlo su ebay decisi bene di creare un annuncio fake di mykey 2.0 e la magagna riusci' bene nell intento, quel gran ritardato di furios abbassa il programma da 100 a 15 euro... veloce compro il programma da lui tramite un altro account poiché avevo una grande voglia di vedere se appunto questo programma esistesse, e posso confermarvi che esiste e funziona diciamo nei limiti della decenza.
Ho rischiato la mia parola poiché inizialmente non sapevo se il programma che vendeva furios fosse stata una semplice modifica alla label che sta su help da 1.0.0 a 2.0.1 oppure una reale soluzione al nebular...

nisba , il programma non risolve un bel c**zo di niente.
ho fatto questo perché penso che programmi di mer** tipo questo non debbano mai essere venduti al di sopra della 10 euro.
mi dispiace per la gente che lo ha comprato pure a 15 euro.

programmi opensource come mikai valgono 200 mila volte meglio, questo programma non risolve chiavette flippate.
posso darvi ulteriore conferma quindi che pagliaccio è un merd*iolo che non se ne intende di nulla e spara cagate.

spero non me ne vogliate anche perchè leggo qui ogni giorno e mi sembra comunque il caso di farvi sapere tutto, cose che altri non avrebbero mai fatto...

Tutto questo sta diventando surreale. Sinceramente non capisco perché delle soluzioni che noi stiamo pubblicando gratuitamente, vengano poi messe a pagamento dal primo che capita. Comunque sia, io sto seguendo molto attivamente la discussione, sto cercando nel mio piccolo di aiutare il più possibile, ma non essendo capace di fare molte delle cose che sanno fare gli altri, purtroppo sono limitato. Di conseguenza spero che qualcuno riesca a trovare e a capire come fixare i blocchi che causano il problema di MyKey. Non tanto per prendere un caffè gratis, visto che non mi cambia la vita, ma più che altro per capire il funzionamento e soprattutto perché (parlando personalmente) sono molto curioso di questo mondo... Detto ciò, buona serata a tutti. Attendo risposte future da qualche mente più sviluppata della mia

 

[dav26]

Io non sto divulgando informazioni che mettete qui gratis, sarebbe sleale.

Voglio semplicemente rispondere alla vostre domande.
Mykey 2.0.1 non è il santo graal, risolve solo dei bug ma per quanto riguarda sbannare le chiavette non funziona

Di questo ne eravamo già al corrente, ecco perché hanno creato Mikai. Perché risolve le ca**are che non sa risolvere MyKey

 

[megajump]

scusate gente ma mi pare di capire che qui nessuno abbia letto la bibbia sull'argomento... dovete leggere bfi. a voi cercare i 2 numeri giusti. spero sappiate usare un motore di ricerca

 

[Inbocca]

Con tutta probabilità il mondo "studio delle chiavette" è nato con loro, cos'era datata la Bibbia? 1997? Probabilmente stavo giocando a FIFA e MK3 col Mega Drive ..

 

[Inbocca]

Se il controllo fosse che la macchina ad ogni operazione manda al server l'uid associato al credito ed al contatore delle operazioni, si potrebbe far quel che si vuole, ma l'unica soluzione sarebbe quella di generare ogni volta un uid differente.
Da quel che si può capire del video/sito che ne spiega le funzioni così sembrerebbe.
Se così non fosse, e l'aggiornamento dati al server fosse sporadico, forse un altro modo ci sarebbe.

 

[Elchavo96]

secondo me il loro sistema cloud funziona in maniera molto più semplice.
nel senso che secondo me ogni qual volta viene eseguita un'operazione su un distributore collegato alla rete di nebular viene creato il log con UID della chiavetta e credito attuale di quel momento, al successivo utilizzo della chiavetta uguale e così via.
ne consegue che se si modificasse il credito con il programma si andrebbe a creare una differenza nel credito che è stato registrato sul server e quello che si ha attualmente, da lì il ban.
con i normali distributori questo non si puo fare perche anche se il singolo distributore avesse il log con UID della chiavetta e credito attuale di quel momento una persona potrebbe averla ricaricata su un altro distributore, magari quello di fianco, questa mancanza di comunicazione tra i distributori rende impossibile creare un ban efficace.
nebular andrebbe appunto a far comunicare i distributori tra di loro e questo renderebbe possibile sapere se la chiavetta è stata ricaricata altrove e non da un distributore.
ovviamente sono supposizioni ma penso che le soluzioni semplici, e quindi più economiche, sono di solito quelle che vengono utilizzate di più rispetto a sistemi più complessi.

 

[jsell74]

ho usato la funzione integrata nel software per importare il dump di una chiave vergine sperando di riuscire a inverginare un'altra chiavetta in un colpo solo.
è stato un esperimento per capire se venissero copiati tutti i dati oppure solo alcuni, anch'io avevo i miei dubbi.
comunque si è creato un codice anomalo nel primo blocco che dovrebbe invece essere vuoto e da lì non si può togliere visto che quel blocco non è scrivibile in teoria.
insieme a un altro utente ero riuscito a modificarne il valore portandolo 00 00 00 00 quando invece dovrebbe essere ff ff ff ff, al momento non funziona e non è neanche più scrivibile restituendo l'errore "dump danneggiato"

Io per risolvere il problema ho caricato il DUMP andando a portare in modo forzato i valori di 00 : 00 00 00 00 e così sono riuscito a riscrivere il dump....poi ho riverginato la chiavetta e il distributore me l'ha letta nuovamente caricandola ufficialmente ha ripreso a funzionare, poi il prurito alle mani mi ha fatto cambiare il terzo record della stinga 06(perchè qualcuno sul forum suggeriva una modifica del genere per poter riportare il settore 00 a ff ff ff ff e questo ha crato un blocco totale, che non sono riuscito più a risolvere....io penso che ora la macchinetta controlli altri settori rispetto prima che se non sono scritti nel modo corretto ti mettono la data a ff/ff/19ff da quello che mi è sembrato di capire la MasterKey è calcolata da UID e Data (considerando che l'UID non è modificabile) cambiando la data non si è in grado di recuperare più la chiavetta...certo che se abbiamo un DUPM precedente al blocco possiamo tornare in dietro.
Allego l'architettura del CHIP SRIX4K di qui si capisce cosa si può modificare e cosa non va toccato.

 

[Max Fridman]

sprando che non chiudono anche questa ?

La discussione è stata chiusa perché era vecchia / non si capiva più nulla. Non per censurare anzi...spero che il primo topic venga aggiornato con i problemi più comuni / soluzioni trovate.

Infatti concedo il rilievo e ringrazio @jsell74 per averla creata!

 

[jsell74]

Vedendo una serie di una ventina di log di una chiave usata regolarmente gli unici campi che variano sono
06 Che è un contatore progressivo che porta i valori man mano che si usa la chiavetta da FF a 00 (una volta a 00 non si può scrivere sulla chiavetta)
12 sembra un contatore
16 sembra un contatore
21 Credito
23 Credito precedente
25 Credito Backup (con terzo settore con scarto di 4)
27 Credito precedente Backup (con terzo settore con scarto di 4)
34
35
36
37
38
39
3a
3b

mi piacerebbe capire ogni singola voce a cosa corrispondi
tutto il resto rimane invariato

 

[SEG0C]

Vedendo una serie di una ventina di log di una chiave usata regolarmente gli unici campi che variano sono
06 Che è un contatore progressivo che porta i valori man mano che si usa la chiavetta da FF a 00 (una volta a 00 non si può scrivere sulla chiavetta)
12 sembra un contatore
16 sembra un contatore
21 Credito
23 Credito precedente
25 Credito Backup (con terzo settore con scarto di 4)
27 Credito precedente Backup (con terzo settore con scarto di 4)
34
35
36
37
38
39
3a
3b

mi piacerebbe capire ogni singola voce a cosa corrispondi
tutto il resto rimane invariato

Su http://mikaiusaeno2wju5iwawhfq7cbpasrkpetmhhwzb266u7vcbnxxir7ad.onion/ c'è una spiegazioni più completa.

Salve
Volevo confrontarmi con voi su i vari esperimenti(anche se sono veramente alle prime armi) che ho provato e provo a fare

Confrontando e ricariche tra distributore e mykey fatte con il solito importo ho notato che cambia qualcosa tra il conteggio del campo 21 e 25.
Cioe se aumentate con mykey per esempio di 0.50€ i campi sono cosi:
21: D2 66 60 43
25: D2 66 20 43
si nota un meno 40 tra la terza coppia, mentre se caricato 0.50€ con la macchinetta si legge questo
21: D2 66 60 43
25: D2 66 A0 43
invece di un meno 40 vi è l'opposto un piu 40 tra le terze coppie, il resto contatori credito precedente sembra tutto uguale.

Ho provato a ricaricare la chiavetta solo con mykey modificando la terza coppia di un valore +40 e per circa 4/5 volte con ricariche di 5€ ha sempre funzionato.
Si è bloccata quando ho provato ad effettuare due cariche consecutive con mykey senza spendere credito della chiave, cioe +5+1€.
Adesso sto provando sempre con la variazione manuale del valore+40 a fare una ricarica alla macchinetta(tipo 0.5€) e poi con mykey +5€ e per adesso sembra funzionare.
Questo mi fa pensare che nebular non memorizza la chiavetta nel blacklist perchè una volta bannata se la ripristino mi funziona per 4/5 volte con queste procedure.

Che ne pensate

Semplicemente che MyKey è stato scritto male e sbaglia a fare il calcolo del blocco 23 e 27, i blocchi di checksum del credito. Usa MIKAI.

Messaggio unito automaticamente: 31 Gennaio 2020

ho usato la funzione integrata nel software per importare il dump di una chiave vergine sperando di riuscire a inverginare un'altra chiavetta in un colpo solo.
è stato un esperimento per capire se venissero copiati tutti i dati oppure solo alcuni, anch'io avevo i miei dubbi.
comunque si è creato un codice anomalo nel primo blocco che dovrebbe invece essere vuoto e da lì non si può togliere visto che quel blocco non è scrivibile in teoria.
insieme a un altro utente ero riuscito a modificarne il valore portandolo 00 00 00 00 quando invece dovrebbe essere ff ff ff ff, al momento non funziona e non è neanche più scrivibile restituendo l'errore "dump danneggiato"

Ti mancano i blocchi 10, 11, 14 e 15.
Se vuoi ricostruirli è abbastanza semplice, basta prenderli da 3F in poi.

B10: CF 55 59 17
B11: D9 16 63 05
B14: CB 55 59 17
B15: D5 16 63 05

 

[jsell74]

Una volta che hai estratto i file su Linux devi andare nella cartella dei file dal terminale usando il comando cd.
Una volta dentro alla cartella dal terminale puoi digitate i vari comandi per fare le varie operazioni.
I comandi sono:
./mikai (legge la chiave dicendoti Key A Key B data di produzione UID ecc.)
./mikai-reset (inverginare)
./mikai-restore XXX.bin dove xxx è il nome del dump ripristina il dump
./mikai-read xxx.mkd -v
./mikai-diff xxx.mkd yyy.mkd - v (fa vedere le differenze tra 2 dump xxx e yyy)
./mikai-dump (crea un dump, non mi è chiaro se lo fa solo mkd o se ce la possibilità di farlo scrivere anche in bin)
./mikai-otp (rimette le FF se nei primi 5 campi hai degli 00)

Messaggio unito automaticamente: 2 Febbraio 2020

Ringrazio comunque jsell74 per la spiegazione dettagliata in italiano dei vari comandi

Il ringraziamento va a SEGOC, è lui che li ha spiegati a me

 

[megajump]

Un saluto a tutti, c'è qualcuno abbastanza esperto che mi possa dare una mano con la comunicazione pn532 <-> srix4k? Dovrei verificare il frame inviato/ricevuto.
Ho studiato questo sistema diversi anni fa ed è rimasta solo una cosa che ancora non ho scoperto per mancanza di tempo e abbandono dello studio, come viene calcolato il puntatore inserito nel blocco 0x3C che varia per ogni chiave. Se qualcuno ha suggerimenti a riguardo sarei felice di scambiare due chiacchiere.

Non ho sottomano gli appunti in questo momento quindi vado a memoria. il blocco 3C viene codificato usando il numero di serie della chiavetta, quello al blocco 07, poi mi ricordo che il primo byte puo valere 80 o C0 e in base al valore indica che il puntatore sta tra 34 e 37 oppure tra 38 e 3B

 

[jsell74]

io andando a vedere una serie di dump fatti 1x1 man mano che si utilizza la chiavetta in modo regolare ho notato che gli unici campi che cambiano su una base di 15 dump sono

06 contatore che diminuisce ad ogni registrazione 1 valore
12 contatore 1
16 contatore 2
21 credito attuale
23 credito precedente
25 credito attuale meno 40 sul terzo settore
27 credito precedente meno 40 sul terzo settore
e da 34 a 3b penso che siano lo storico delle ricariche con data annessa...

io penso che il problema sia in un calcolo tra i contatori.... poi sicuramente mi sbaglierò ma x le lacune che ho in informatica non riesco a trovare altro che possa far bloccare le chiavette...se dipendesse da Nebular connesso ad internet

1) non accetterebbe più chiavette bloccate anche se inverginate ...sarebbero bannate dal'UID che non può essere cambiato e quindi ci sarebbe solo da buttarle
2) se io carico la chiavetta da un distributore vecchio quindi senza nebular e poi la uso su uno nuovo non avendo registrato l'operazione sul server di nebular mi dovrebbe bannare (bloccare) la chiave e questo non può succedere, si prenderebbero denunce in giro...il principio delle chiavette è proprio quello, carico e uso da dove voglio.
potrebbe al massimo cambiare qualcosa al codice regione (fornitore del servizio) diciamo che ogni codice regione ha due codici in realtà quello di nebular e quello non nebular diciamo che in fase di ricarica magari cambia qualcosa anche li....
tutte supposizioni magari stro***te.

 

[SEG0C]

Posso chiarire un po' di cose?

1) Non esistono versioni maggiori della 1.0.0. Quelle che girano sono solo versioni con modifiche delle varie stringhe. [1]
2) Il blocco 21 e 25 si basano sulla session key che si basa sulla master key, quindi questi blocchi saranno diversa da chiavetta a chiavetta. Non potete trasferire i blocchi così come se niente fosse. Se volete potete trasferire i blocchi 23 e 27 (quelli del credito precedente) perché sono scritti in chiaro.
3) Non esiste un "ban" nebular. Può succedere che il distributore vi cancelli il contenuto della chiavetta, tranne i blocchi 7 e 8 che sono Read-Only. Per risolvere basta avere un backup e fare il restore con mikai-restore.

[1]: https://0bin.net/paste/QjjADS64DriODLsw#x9z1pUzKgANuV2lqSfbJHn+96n-aLU0jcz31jbLko13