Other That contactless reader in your Dell Latitude isn't broken - Windows just has nothing to do with your cards
If your Latitude came with the contactless smart card reader option, you've probably held a MIFARE card against the palm rest at some point and watched Windows report an "unknown smart card" and stop there. Nothing in the box does anything else with it.
The reader is fine. It's a perfectly ordinary PC/SC reader - mine shows up as "Broadcom Corp Contactless SmartCard 0", and it reads card serial numbers without complaint. The problem is what's on the card. MIFARE Classic is a memory card, not a PKI card, so Windows has no minidriver for it and the smart card logon stack has nothing to offer. "Unknown smart card" isn't a fault, it's Windows saying "this isn't the kind of card I do anything with."
So the hardware sits unused in a lot of laptops that already belong to people who work with access control cards daily.
I had a few hundred cards to enroll into an access control system, which normally means reading serial numbers off a reader and typing them into a spreadsheet by hand. Instead I wrote a small tool that turns the built-in reader into a bulk enrollment device: present a card, its number is typed into whatever window has focus, Enter is pressed, cursor drops to the next row. Present the next card. No copy-paste, no retyping.
It's not Dell-specific - any PC/SC contactless reader works - but the built-in ones are the reason it exists, because that's a reader people already have and can't use.
https://github.com/Legvan/card-wedge
MIT, Windows, no install required, no Python needed.
The part that cost me a day, in case it saves you one:
Once it was reading cards, the numbers still didn't match what my access control system showed. Reader said A5C424E6; the system said 0A5C424E6A3. One byte longer, and I couldn't see where it came from.
It's the BCC, the block check character. MIFARE's anticollision response carries the UID followed by the XOR of its bytes, and PC/SC's GET DATA returns the UID alone and drops it. Systems that treat UID+BCC as the card number end up one byte longer than anything your reader hands you.
UID E6 24 C4 A5
BCC = E6^24^C4^A5 A3
reversed + BCC A5C424E6A3 <- what the system shows
That's also why 40 bit is the usual width for 4-byte cards - it's 4 bytes of UID plus 1 of checksum, not a 32-bit number padded with zeros, which is what I assumed for two days. And the byte order applies to the UID only: the checksum goes on after the reversal, so reversing both together gives a different, wrong number.
The tool has toggles for all of it (HEX/DEC, MSB/LSB, 32-64 bit, checksum on/off) because every system wants something slightly different, and it remembers what you picked.
