⚠️ DO NOT USE THIS! READ BELOW! ⚠️

Due to a flaw of nfcpy (or maybe not?) tags enrolled by this script will have the capability bit set to 0x31. This for some reason makes the NDEF payload only compatible with Android phones!

This script can be used to enroll your NFC tags in the badge system. Effectively, it will:

1. Enable the READ_CNT flag, to enable the read counter
2. Add a NDEF Uri so that the badge can be scanned by attendants
3. Protect the badge with a password, generated uniquely for every tag
4. Log the UID and badge type, so you can import it in your backend

Requirements

1. Check the requirements.txt file for python lib requirements
2. Install mpv to play a sound at the end of every succesfull write, or don't (and remove the row)
3. Change the SALT to a very secure password and adjust the iteration count to a sensible number for your computer
4. Connect a PN532 scanner via USB
5. Enjoy!

Run the script

python3 enroll.py [badge/coin] [initial balance]

The badge/coin changes the url, while initial balance changes the column on the data export (the log_*.txt files)

The ASCII mirror!

You will notice that every badge has a generic "https://go.foxo.me/fz23/bxxxxxxxxxxxxxxxxxxxxx" url written to it. This is on purpose since after this write the UID + COUNT mirror is enabled. This is a function of the NDEF tags that lets you "mirror" various registers in ascii format to other arbitrary addresses. The code following the ndef part will effectively make so that when you read the link will actually become "/fz23/b[TAG IDENTIFIER]x[READ COUNT]" (e.g. "/fz23/b048E77929A7181x0000EB") without any manual intervention and in a completely tear-free way.

The "toys" folder

Inside of the toys folder there are two files which were a proof of concept for the storage of monetary transactions inside of NFC tags, for use to buy drinks and similar. Eventually, the system was moved completely server-side (due to slowness in writing the cards and risk of tearing), and the entire system scrapped.

The system consisted in ed25519-based transaction signatures, where offline clients (aka the PoS) would be able to verify and write transactions. The cards would actually store two transactions and then change a pointer atomically to prevent half-written transaction from being considered.

The transaction format is as follows:

[   CA$H   ]
[signature ] * 16
[load][used]
[keyi][txid]
[timestamp ]
[   uuid   ]
[   F0X0   ]

• CA$H and F0X0 are header and footer of the transaction (4 bytes each)
• signature = ed25519 signature of the transaction (4 * 16 = 64 bytes)
• load (2 bytes) + used (2 bytes) = the amount of loaded and used money. These two values can only increase and the balance is calculated from subtracting them so that "replay" attacks are harder
• keyi = id of the key used to sign the transaction (2 bytes)
• txid = increasing id of the transaction (2 bytes)
• timestamp = unix ts of the transaction (4 bytes)
• uuid = a custom uuid to identify the card (this was added because at one point we accidentally bought counterfeit cards with duplicated NFC identifiers)