Discussione Sicurezza delle COGES MyKey

Kaspyk

Utente Iron
18 Maggio 2025
5
1
1
7
Buonasera. Recentemente mi sono appassionato allo studio e al reverse engineering dei sistemi di pagamento per i distributori automatici. Ho studiato le Mifare, infami per la scarsa sicurezza, mentre ora mi sto approcciando alle COGES. Ciò che mi stupisce del sistema è che mi sembra estremamente poco sicuro, ma potrebbe trattarsi del fatto che ho frainteso qualcosa.
Partiamo dal presupposto che le chiavette in questione sono nate per essere offline, quindi contengono esse stesse il credito; i distributori - attuate le dovute verifiche - tendono a "fidarsi" dei dati inseriti. Il fatto è che i dati delle Coges sono accessibili tramite comandi triviali su diversi lettori disponibili al pubblico, e pure economici (io uso un Proxmark 3).
La sicurezza delle chiavi si affida a:
  1. Il credito attuale, "cifrato" (non ho investigato molto, ma sembra essere una cifratura triviale)
  2. Uno storico in chiaro delle transazioni con date e crediti passati
  3. Un contatore in decrement, da cui deriva un checksum
  4. Un UID lockato
Eventuali incongruenze portano al ban dell'UID o all'azzeramento del contatore. Ora, siccome per scrivere o leggere un blocco su queste chiavette basta un comando, cosa mi impedisce di fare un backup di una chiavetta caricata legittimamente in un distributore (ex. inserendo 5€) e ripristinando il dump dopo aver speso i soldi? Non sarebbe neppure necessario conoscere la cifratura. Il contatore si può ripristinare, non è come nelle Mifare che c'è un lock hardware. L'unico modo perché il sistema rilevi una modifica, a mio avviso, è che sia connesso online e tenga registro di tutte le transazioni, ma questo è improbabile in quanto:

  1. Presupporrebbe l'assenza totale di distributori offline, i quali non potrebbero aggiornare la chiavetta perché risulterebbe fuori sincronia col server
  2. Sarebbe illogico: se il sistema si appoggiasse interamente ai server, il credito potrebbe andare direttamente nel cloud senza rischiare manomissioni
La mia teoria è che ho frainteso: il contatore non è modificabile (da cui il checksum). E' così oppure la sicurezza è davvero così scarsa?
 
Buonasera. Recentemente mi sono appassionato allo studio e al reverse engineering dei sistemi di pagamento per i distributori automatici. Ho studiato le Mifare, infami per la scarsa sicurezza, mentre ora mi sto approcciando alle COGES. Ciò che mi stupisce del sistema è che mi sembra estremamente poco sicuro, ma potrebbe trattarsi del fatto che ho frainteso qualcosa.
Partiamo dal presupposto che le chiavette in questione sono nate per essere offline, quindi contengono esse stesse il credito; i distributori - attuate le dovute verifiche - tendono a "fidarsi" dei dati inseriti. Il fatto è che i dati delle Coges sono accessibili tramite comandi triviali su diversi lettori disponibili al pubblico, e pure economici (io uso un Proxmark 3).
La sicurezza delle chiavi si affida a:
  1. Il credito attuale, "cifrato" (non ho investigato molto, ma sembra essere una cifratura triviale)
  2. Uno storico in chiaro delle transazioni con date e crediti passati
  3. Un contatore in decrement, da cui deriva un checksum
  4. Un UID lockato
Eventuali incongruenze portano al ban dell'UID o all'azzeramento del contatore. Ora, siccome per scrivere o leggere un blocco su queste chiavette basta un comando, cosa mi impedisce di fare un backup di una chiavetta caricata legittimamente in un distributore (ex. inserendo 5€) e ripristinando il dump dopo aver speso i soldi? Non sarebbe neppure necessario conoscere la cifratura. Il contatore si può ripristinare, non è come nelle Mifare che c'è un lock hardware. L'unico modo perché il sistema rilevi una modifica, a mio avviso, è che sia connesso online e tenga registro di tutte le transazioni, ma questo è improbabile in quanto:

  1. Presupporrebbe l'assenza totale di distributori offline, i quali non potrebbero aggiornare la chiavetta perché risulterebbe fuori sincronia col server
  2. Sarebbe illogico: se il sistema si appoggiasse interamente ai server, il credito potrebbe andare direttamente nel cloud senza rischiare manomissioni
La mia teoria è che ho frainteso: il contatore non è modificabile (da cui il checksum). E' così oppure la sicurezza è davvero così scarsa?
Non confondere il sistema con il supporto. Tu stai studiando i tag non il sistema. Le mifare desfire non mi sembrano male comunque
 
Buonasera. Recentemente mi sono appassionato allo studio e al reverse engineering dei sistemi di pagamento per i distributori automatici. Ho studiato le Mifare, infami per la scarsa sicurezza, mentre ora mi sto approcciando alle COGES. Ciò che mi stupisce del sistema è che mi sembra estremamente poco sicuro, ma potrebbe trattarsi del fatto che ho frainteso qualcosa.
Partiamo dal presupposto che le chiavette in questione sono nate per essere offline, quindi contengono esse stesse il credito; i distributori - attuate le dovute verifiche - tendono a "fidarsi" dei dati inseriti. Il fatto è che i dati delle Coges sono accessibili tramite comandi triviali su diversi lettori disponibili al pubblico, e pure economici (io uso un Proxmark 3).
La sicurezza delle chiavi si affida a:
  1. Il credito attuale, "cifrato" (non ho investigato molto, ma sembra essere una cifratura triviale)
  2. Uno storico in chiaro delle transazioni con date e crediti passati
  3. Un contatore in decrement, da cui deriva un checksum
  4. Un UID lockato
Eventuali incongruenze portano al ban dell'UID o all'azzeramento del contatore. Ora, siccome per scrivere o leggere un blocco su queste chiavette basta un comando, cosa mi impedisce di fare un backup di una chiavetta caricata legittimamente in un distributore (ex. inserendo 5€) e ripristinando il dump dopo aver speso i soldi? Non sarebbe neppure necessario conoscere la cifratura. Il contatore si può ripristinare, non è come nelle Mifare che c'è un lock hardware. L'unico modo perché il sistema rilevi una modifica, a mio avviso, è che sia connesso online e tenga registro di tutte le transazioni, ma questo è improbabile in quanto:

  1. Presupporrebbe l'assenza totale di distributori offline, i quali non potrebbero aggiornare la chiavetta perché risulterebbe fuori sincronia col server
  2. Sarebbe illogico: se il sistema si appoggiasse interamente ai server, il credito potrebbe andare direttamente nel cloud senza rischiare manomissioni
La mia teoria è che ho frainteso: il contatore non è modificabile (da cui il checksum). E' così oppure la sicurezza è davvero così scarsa?
Come ripristini un dump se il contatore delle operazioni è solo decrementale e non modificabile (o meglio il contatore si può variare con il tearing), ma devi ottenere lo stesso valore del dump che hai salvato. E' più la scomodità che il resto
 
Come ripristini un dump se il contatore delle operazioni è solo decrementale e non modificabile (o meglio il contatore si può variare con il tearing), ma devi ottenere lo stesso valore del dump che hai salvato. E' più la scomodità che il resto
Sì ignoranza mia, ho ripescato il datasheet delle SRIX4K e ho visto che hanno un contatore decrementale. Tutto cambia.
 
Buonasera. Recentemente mi sono appassionato allo studio e al reverse engineering dei sistemi di pagamento per i distributori automatici. Ho studiato le Mifare, infami per la scarsa sicurezza, mentre ora mi sto approcciando alle COGES. Ciò che mi stupisce del sistema è che mi sembra estremamente poco sicuro, ma potrebbe trattarsi del fatto che ho frainteso qualcosa.
Partiamo dal presupposto che le chiavette in questione sono nate per essere offline, quindi contengono esse stesse il credito; i distributori - attuate le dovute verifiche - tendono a "fidarsi" dei dati inseriti. Il fatto è che i dati delle Coges sono accessibili tramite comandi triviali su diversi lettori disponibili al pubblico, e pure economici (io uso un Proxmark 3).
La sicurezza delle chiavi si affida a:
  1. Il credito attuale, "cifrato" (non ho investigato molto, ma sembra essere una cifratura triviale)
  2. Uno storico in chiaro delle transazioni con date e crediti passati
  3. Un contatore in decrement, da cui deriva un checksum
  4. Un UID lockato
Eventuali incongruenze portano al ban dell'UID o all'azzeramento del contatore. Ora, siccome per scrivere o leggere un blocco su queste chiavette basta un comando, cosa mi impedisce di fare un backup di una chiavetta caricata legittimamente in un distributore (ex. inserendo 5€) e ripristinando il dump dopo aver speso i soldi? Non sarebbe neppure necessario conoscere la cifratura. Il contatore si può ripristinare, non è come nelle Mifare che c'è un lock hardware. L'unico modo perché il sistema rilevi una modifica, a mio avviso, è che sia connesso online e tenga registro di tutte le transazioni, ma questo è improbabile in quanto:

  1. Presupporrebbe l'assenza totale di distributori offline, i quali non potrebbero aggiornare la chiavetta perché risulterebbe fuori sincronia col server
  2. Sarebbe illogico: se il sistema si appoggiasse interamente ai server, il credito potrebbe andare direttamente nel cloud senza rischiare manomissioni
La mia teoria è che ho frainteso: il contatore non è modificabile (da cui il checksum). E' così oppure la sicurezza è davvero così scarsa?
Non puoi ripristinare un dump, sia nella versione con lock id sia nella versione senza lock id, poichè alcuni blocchi sono funzione di un contatore solo decrescente, il blocco 0x06. Puoi ripristinare la maggior parte dei blocchi, ma non il blocco 0x06, con una scrittura diretta.

ah..non avevo visto la tua ultima risposta, ci sei arrivato da solo :D
 
ripristinare NON ha mai funzionato su questo sistema, perchè viene tenuto traccia del seriale/uid e del numero transazioni (entrambi).
Molta gente si è lamentata per i ban.
Poi studiare cosa se esiste già un software open source che dimostra tutto? Giusto per sfida.
 
ripristinare NON ha mai funzionato su questo sistema, perchè viene tenuto traccia del seriale/uid e del numero transazioni (entrambi).
Molta gente si è lamentata per i ban.
Poi studiare cosa se esiste già un software open source che dimostra tutto? Giusto per sfida.
quale sarebbe il software?
 
Indietro
Top Bottom