How I Learned to Stop Worrying and Love the Green Pass
Che dati contiene la “Certificazione verde Covid-19“, detta Green Pass, corrispondente alla versione italiana dell’EU Digital COVID Certificate?
Il certificato ci viene consegnato tramite un QR Code, contenente i dati relativi alla vaccinazione ricevuta, il nostro nome e cognome, e la nostra data di nascita, informazioni che sono codificate secondo le specifiche tecniche dell’eHealth Network pubblicate dalla Commissione Europea, e firmate digitalmente per garantirne l’integrità e l’autenticità.
Decodifica del mio certificato
Seguendo le specifiche tecniche, ho implementato un semplice Proof Of Concept per poter leggere le informazioni codificate nel QR Code: eHealthDecoder.
Il software è rilasciato con licenza Open Source, liberamente scaricabile e modificabile, e il suo scopo è puramente didattico.
Codifica utilizzata per creare il QR Code del Green Pass
Il certificato non contiene altri dati oltre a quelli dichiarati dalla Commissione Europea, non c’è quindi alcun rischio a mostrarlo in aeroporto, ad esempio, poiché le compagnie conoscono già il vostro nome, cognome e data di nascita dal momento in cui avete acquistato il biglietto.
Per quanto riguarda la condivisione indiscriminata sui social, dipende dalla propria sensibilità.
Siate consapevoli della perdita totale di controllo su tutto ciò che pubblicate, che sia il QR Code del vaccino o la foto di vostro figlio che gioca in spiaggia.
DISCLAIMER: Post idiota ma con approccio scientifico! 🙂
Di che colore è l’alieno Xenomorfo in Alien 1979 di Ridley Scott? Qualcuno ha suggerito nero, ma non sono convinto.
Cercando in rete non ho trovato molto, se non dei riferimenti al 3° (Alien 3, David Fincher) e al 4° capitolo (Alien – La clonazione, Jean-Pierre Jeunet), che però uscirono rispettivamente 13 e 18 anni dopo e non furono diretti da Scott.
Alien 3: “Il design finale della versione adulta fu reso più organico e meno biomeccanico delle creature precedenti, con una sfumatura marrone invece che nera”;
Alien – La clonazione: “Il regista Jeunet insistette nel dargli un colore bruno verdastro conferendogli un aspetto più da insetto”.
Tutto, quindi, farebbe pensare che effettivamente le creature dei capitoli precedenti ad Alien 3 siano nere.
Gli ambienti “industrial” del film, però, sono molto scuri – tipico di R. Scott -, e la colorazione della pellicola è tendente al blu specialmente nelle ombre. Quindi, la forte dominante cromatica non permette una valutazione veloce e oggettiva del colore dell’Alien.
Urge uno studio approfondito per svelare l’arcano! Perché? Perché no? E’ estate, fuori fa caldo e, nonostante la pandemia, a me oggi va di scherzare! 😀
Cerco il film su un sito di streaming di pezzotti – ho il Blu-Ray originale, ‘sticazzi! – e inizio a skippare freneticamente alla ricerca di un’inquadratura in cui l’Alien è ripreso insieme a qualcosa di un colore sicuramente riconoscibile. Skippo, skippo, e TAAAC! Ripley – interpretata da Sigourney Weaver – si toglie la camicia e rimane in intimo: maglietta e mutandine.
Perfetto! Molto probabilmente il completino intimo di Ripley sarà bianco (da verificare tra poco). Metto in play e ZAAAC! Spunta l’Alien da dietro la console dell’astronave.
A questo punto mi basta:
bilanciare il bianco sulle mutande di Ripley in modo da rimuovere la dominante bluastra;
verificare che effettivamente l’intimo è di colore neutro osservando la credibilità cromatica dell’incarnato;
leggere finalmente il colore dell’Alien.
Facile, no? Al lavoro!
L’intimo di Ripley è veramente bianco? Valutiamolo dall’incarnato.
Ripley, colore pellicola
La vedete la dominante blu? Forse no, perché il nostro cervello è capace di compensare automaticamente le dominanti rifacendosi ai colori che ricorda. Non è affascinante e meraviglioso?
Proviamo a bilanciare il bianco ipotizzando che il colore del suo intimo sia neutro (che significa: nessuna componente cromatica prevalente, ovvero la quantità di Rosso, Verde, e Blu – sintesi additiva – si equivalgono) e valutiamo se il colore della sua pelle ci sembra più o meno naturale di prima.
Posizionando un paio di punti (#1 e #2) dello strumento “campionatore colore” di Photoshop sulle parti che ipotizziamo neutre, andiamo a leggere i valori RGB (Rosso, Verde, Blu) e vediamo una prevalenza di Verde e Blu (esempio sul primo punto R 85, G 98, B 109). Anche se il nostro cervello ci inganna, possiamo leggere la dominante dallo strumento campionatore con assoluta certezza.
Applichiamo quindi un layer di correzione colore tramite lo strumento “curve” e abbassiamo leggermente il canale del Blu e del Verde fino a leggere valori simili nei punti #1 e #2.
Ripley, colore bilanciato
Vi sembra più o meno naturale di prima? Ve le mostro assieme.
A sinistra l’immagine bilanciata, a destra quella originale.
Direi che l’incarnato è meno olivastro e più naturale nella parte bilanciata, quindi il colore del completino intimo è neutro! Bingo!
Ora che abbiamo dato in pasto al nostro cervello un colore “corretto”, non può più ingannarci!
Correggiamo la seconda inquadratura con la stessa tecnica.
Nascosto nel punto segnato in rosso c’è la testa dell’Alien, che un attimo dopo schizzerà fuori.Immagine bilanciata, nel punto #3 (testa dell’alieno) leggiamo R 8, G 12, B, 12, ovvero non un colore neutro (RGB uguali)!
Se questa analisi dovesse essere corretta, allora l’Alien non è nero, perché il nero è un colore neutro ed avrebbe i canali R, G, e B di valori identici (0, 0, 0 nero assoluto senza tener conto della luminosità).
Leggendo il punto #3 con un metodo colore differente (LAB) che separa il canale della luminosità dalle componenti cromatiche, si legge canale A -1, canale B 0.
Nello spazio colore LAB un colore neutro ha entrambi i canali A e B a 0. Anche questo metodo conferma quindi che lo Xenomorfo non è di colore neutro!
Un valore di A negativo indica uno spostamento cromatico verso il verde, così come nello spazio colore RGB una carenza del canale Rosso indica un colore tendente al verdognolo.
L’Alien è Verde!
Conclusioni
La verità è che questa analisi, oltre ad essere un esercizio sulla correzione delle dominanti in fotografia, e soprattutto un gioco, non credo possa essere considerata al 100% attendibile.
Questo perché ho effettuato il bilanciamento in due soli punti sul tenente Ripley: un punto in ombra e un punto in luce. Sulla scena però potrebbero esserci – e sicuramente ci sono – più luci di diversi colori come suggerito dall’immagine successiva (originale e non bilanciata da me).
Il volto di Ripley è illuminato da una luce abbastanza neutra, il colore della sua pelle non è olivastro come nelle altre inquadrature. L’Alien, allo stesso tempo, risulta fortemente blu.
Concludendo, da oggi penserò all’Alien come un essere verdognolo 🙂
The affected vendor did not answer to my responsible disclosure request, so I’m here to disclose this “hack” without revealing the name of the vendor itself.
The target machine uses an insecure NFC Card, MIFARE Classic 1k, that has been affected by multiple vulnerabilities so should not be used in important application. Furthermore, the user’s credit was stored on the card enabling different attack scenarios, from double spending to potential data tamper storing an arbitrary credit.
Useful notes from MIFARE Classic 1K datasheet:
EEPROM: 1 kB is organized in 16 sectors of 4 blocks. One block contains 16 bytes. The last block of each sector is called “trailer”, which contains two secret keys and programmable access conditions for each block in this sector.
Manufacturer block: This is the first data block (block 0) of the first sector (sector 0). It contains the IC manufacturer data. This block is read-only.
Data blocks: All sectors contain 3 blocks of 16 bytes for storing data (Sector 0 contains only two data blocks and the read-only manufacturer block). The data blocks can be configured by the access conditions bits as:
Read/Write blocks: fully arbitrary data, in arbitrary format
Value blocks: fixed data format which permits native error detection and correction and a backup management. A value block can only be generated through a write operation in value block format:
Value: Signifies a signed 4-byte value. The lowest significant byte of a value is stored in the lowest address byte. Negative values are stored in standard 2´s complement format. For reasons of data integrity and security, a value is stored three times, twice non-inverted and once inverted.
Adr: Signifies a 1-byte address, which can be used to save the storage address of a block, when implementing a powerful backup management. The address byte is stored four times, twice inverted and non-inverted.
Value block example for value 0x0012D687
Let’s start hacking:
In this post I did not show you how to crack the MIFARE Classic Keys needed to read/write the card, ’cause someone else has already disclosed it some time ago, so google is your friend. At last, please, use this post to skill yourself about the fascinating world of reverse engineering, and not for stealing stuffs.
In order to start the analysis I need some dump to compare. The requirements of this task are nfc-mfclassic tool included in libnfc, a NFC hardware interface like ACR122U, and a binary compare (aka binarydiff) tool like dhex.
Dumps:
Dump 0: Virgin card (not included in the screenshot below ’cause all data bytes were 0x00, except for the sector 0 that has UID and manufacturer information. These sector is read only, so these bytes are the same across dumps)
Dump 1: Card charged with single 0.10€ coin (Note that vending machine displays the balance with 3 decimals, 0.100€)
Dump 2: 0.00€ after spending the entire balance with 4 transactions of 0.025€ each
Blurred bytes are the MIFARE keys A and B, except for the 32 bytes at 0xE0 offset of which I don’t know their purpose. The 4 bytes between the keys are Access Condition and denotes which key must be used for read and write operation (A or B key) and the block type (“read/write block” or “value block”).
The tool mfdread is useful to decode the Access Condition bytes rapidly, and, in general, to display MIFARE Classic data divided by sectors and blocks:
Dump 1 with mfdread parser
Early analysis:
Note: from now on I will refer to the offsets with a [square parenthesis] and a value with no parenthesis.
Blocks 8, 9, 10, 12 and 13 can be used also as “value block”
Except for bytes between offsets [0x80] and [0x9F], only few bytes differ between dumps
Some data are redundant, for example [0x60 … 0x63] has the same values of [0xA0 … 0xA3]
Values at [0xC0], [0xD0], [0xC8], [0xD8] differ by 4 between 1st and 2nd dump (eg: 0xFE – 0xFA = 0x4) and differ by 1 between 2nd dump and 3rd dump (eg: 0xFA – 0xF9 = 0x1)
Values at [0xC4], [0xD4] differ by 4 between 1st and 2nd dump (eg: 0x05 – 0x01 = 0x4) and differ by 1 between 2nd and 3rd dump (eg: 0x06 – 0x05 = 0x1)
4 is the number of spent transaction made the first time, and 1 is the number of recharge transaction made the second time
Sum between yellow squared and red squared offsets has 0xFF value. In other words red squared is inverse (XOR with 0xFF) of yellow squared. For example:
0xFE ⊕ 0xFF = 0x01
0xFF ⊕ 0xFF = 0x00
…
0x7F ⊕ 0xFF = 0x80
Values at [0x60 … 0x63] are a UNIX TIMESTAMP in little endian notation:
Ok, we are not in the 90ies, but the time difference between transactions is correct, maybe the vending machine doesn’t have an UPS 🙂
Early findings:
Timestamp of the last transaction was stored as 32 bit integer at MIFARE block 6 and redundant at at MIFARE block 10
Only MIFARE blocks 12 and 13 has “Value block” format, and they are used to store the counter of remain transaction in 32 bit format. This counter starts from 0x7FFFFFFF (2.147.483.647) and is decreased at each transaction
Blocks 1, 4, and 14 contains some data that are fixed between dumps
Blocks 8 and 9 changes entirely at each transaction
The credit:
If there is credit stored on the card, it was encoded at blocks 8 and 9, and the number of bytes involved between small credit difference (for example between 0.00€ and 0.10€) could indicate that some cryptographic function is involved.
At this time, a double spending attack could confirm if the credit is really stored on the card. So, after spending all the credit, I have rewritten a previous dump on the card and I went to test it at the vending machine. The card was fully functional with the previous credit stored in that dump. Now, I’m certain that the credit is encoded (and probably encrypted) in the blocks 8 and 9.
Conclusion:
Even if the encoding format of the credit is still unknown, a double spending attack was possible.
This means that the vendor’s effort to obfuscate the credit is nullified 🙁
Adding some unique token on the card that are invalidated into back-end after each transaction, means that this token needs to be shared between all the vending machines of the vendor, but, if we add internet connection to the vending machine, there is no longer reason to store the credit on the card.
So, after all, the only remediation action that makes sense is: DO NOT STORE THE CREDIT ON THE CARD! And, more generally: DO NOT TRUST THE CLIENT!
Road to arbitrary credit:
Spending 1€ infinite times isn’t the scope of that hack. The only real scope is FUN! To continue this analysis I need to collect a large number of dumps to advance some hypothesis so, when I have other material I will make another post.
An example of easier card:
Some vendor has more easier approach by using the MIFARE “Value block” to store the credit without obfuscation or encryption.
Credit stored on the MIFARE Value Block
The above screenshot made with “MIFARE Classic Tool” on Android smartphone, represents a Value Block used to store the credit:
0x00000CE4 = 3300 is the value in Euro thousandths (3.30€).
This particular vendor do not use key A and the Key B is a default key 0xFFFFFFFFFFFFFFFF, so the attacker doesn’t need to crack anything.
Reverse engineering and cracking of a Vending Machine is always funny 🙂
