I don't know how maintained this is anymore, but I think a warning note about the Access Control Bits in the sector trailer should be added somehow (either in the code or the readme here on github).
There is a rundown of how they work here, but basically the last block of a sector contains the authentication keys and bit pattern used to set access rights. Overwriting this with random data will most likely destroy that sector forever as there is no way to write back a new pattern if you don't have proper access. I also suspect this is the reason for some of the people are reporting unexpected authentication errors on the issue tracker, as trying to read a garbled sector will trip the auth check.
It could also be smart to mention that the very first block contains manufacturer info and is read-only, basically staying out of the first sector all together is probably smart unless you really need the space.
_tl;dr: Do not use MFRC522Write with location 3, 7, 11, 15, 19, 23, ..., etc. unless you know EXACTLY what you are doing. They are used for important stuff, and overwriting them makes the whole sector UNREADABLE FOREVER!
Also note: There also seems to be a mismatch in the code output about what a block/sector is, each block is 16 byte, each sector is 4 blocks (with the last block being reserved for the access control). The read/write commands of this library operates on block level, but the read prints it as sector, which can be confusing.
I don't know how maintained this is anymore, but I think a warning note about the Access Control Bits in the sector trailer should be added somehow (either in the code or the readme here on github).
There is a rundown of how they work here, but basically the last block of a sector contains the authentication keys and bit pattern used to set access rights. Overwriting this with random data will most likely destroy that sector forever as there is no way to write back a new pattern if you don't have proper access. I also suspect this is the reason for some of the people are reporting unexpected authentication errors on the issue tracker, as trying to read a garbled sector will trip the auth check.
It could also be smart to mention that the very first block contains manufacturer info and is read-only, basically staying out of the first sector all together is probably smart unless you really need the space.
_tl;dr: Do not use MFRC522Write with location 3, 7, 11, 15, 19, 23, ..., etc. unless you know EXACTLY what you are doing. They are used for important stuff, and overwriting them makes the whole sector UNREADABLE FOREVER!
Also note: There also seems to be a mismatch in the code output about what a block/sector is, each block is 16 byte, each sector is 4 blocks (with the last block being reserved for the access control). The read/write commands of this library operates on block level, but the read prints it as sector, which can be confusing.