That makes sense I suppose.
I know they can potentially use different locking tech, but from what I read it sounds like MFC is overwhelmingly more common than others (though I have a Mifaire Ultralight hotel key from a convention I never figured out how to access with a PM3 beyond basic search-detect)
It sounds like “probably” the good starting point would be the “magic” Mifaire Classic until I find something else in the wild I can’t use it on?
This perfectly highlights another aspect of dealing with any technology… The intersection of technical information versus marketing information. Mifare is more of a marketing term than a description of a technical aspect of the product. Mifare “classic” and Mifare ultralight work to completely different ways. Actually, ntag chips could be considered the next evolution of mifare ultralight… and like ntag vs mifare classic, mifare ultralight is incompatible with mifare classic based applications.
To add more complexity, RFID transponders have memory that can be split up between writable and read-only. Most high frequency transponders have a unique ID or UID, which is located in a section of memory that is read only and cannot be changed. In addition to this memory containing the serial number, there is also typically user memory which contains user programmable memory blocks and pages and sectors… The terminology of which depends on the design of the tag. Mifare classic uses sectors, while mifare ultralight and ntag chips use blocks in pages.
Adding even more complexity, a lot of applications only care about the serial number or UID of the tag, and don’t actually use any of the user programmable memory or the features contained therein. In this way, sometimes an ultralight and a mifare classic tag can both work with the same application because the application only cares about the UID.
Want more complexity? Here you go. The mifare classic chips have a four byte UID while ultralight and ntag chips have a 7 bye UID. The way that ISO 14443A works is that these transponders will respond with their UID to a standard select command, so the application doesn’t have to read the UID out of memory it can just perform a standard select command and get the serial number that way instead of having to know how the memory is arranged and perform the correct read commands to get the UID. But, a lot of software developers for embedded systems use libraries and some of those libraries are designed to read a specific kind of tag only and don’t use this universal approach, making their application narrowly compatible with only one type of chip.
Complexity? You got it. Even if the application gets the UID from the standard ISO 14443A select command, there’s still no guarantee it will handle a 7 byte UID if it’s written to only deal with four byte UIDs. This is extremely common in applications like home deadbolt lock designs where the company only cares about mifare classic because those are the types of fobs they’re including with their lock. Why use this old technology? Because it’s the cheapest chip to put into a fob. Why not support other newer types of chips? Because they don’t give a crap about that they’re selling a lock with some fobs and they don’t care what your plans are.
So now you have a little taste of why RFID is such a tangled mess and people end up with multiple implants… I’d say this is about 10% of the actual spaghetti making up the RFID technology industry.
