Now that I can read, dump and clone cards, of course my natural inclinations lead me toward the next goalpost, which is determining what hidden data can be retrieved from the cards. All indications from that forums were that the issue date/time, expiration date/time and room number are stored somewhere on the card, so I knew vaguely what I was looking for, but still had some learning to do.
I wrote a quick script to dump what I know about the cards, which makes it easier to add further definitions as I learn the more detailed structure of the data:
Here’s what I’ve learned so far:
All of the MIFARE cards in my collection (63 of them at last count) have sixteen sector of data. Sector 0 is three blocks and if my understanding is correct, contains immutable manufacturer and other ata. This makes sense, as the very first thing in sector 0 is the UID of the card. What else is that hex data in sector 0? Dunno. Here’s a sector 0 example:
FD65D88ACA880400C825002000000017
E7C0995613BD20D15F58EA614C1020B6
8A000400010000000000000000000000
The bolded hex is the card’s UID.
Sectors 1 through 15 are all four blocks of hex, structured identically. The first block is the keys and access bits. For each sector, there are two keys defined. The access bits define which key or keys are required to read from, or write to, that sector. Example:
2A2C13CC242AFF078069FFFFFFFFFFFF
02D7C800000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
In this case, Key A is 2A2C13CC242A, Key B is FFFFFFFFFFFF, and the access bits field is FF078069, which I found is a very common schema.
The remaining three blocks are data, and here’s where it gets fuzzy. I believe that there is no structure whatsoever to that data. No standard, no default, no pattern. In fact, the bulk of cards had no data stored in most sectors. And I have yet to find a discernible pattern in the data that is stored. I have looked for hex-to-decimal date translations, and so far been unlucky.
Here’s the breakdown of “data stored in sectors”:
Of my 63 cards:
- 48 had data stored in Sector 1
- 34 had data stored in Sector 2
- 3 had data stored in Sector 4
- 5 in Sector 5
- 1 in Sector 6
- 1 in Sector 7
- Zero cards had data stored in Sector 3 or Sectors 8 through 15.
What I’d love to be able to do is to extract the “stay data” from all of these cards. Keep in mind that these are all actual cards from hotels that I and my family have stayed in over the past 4-5 years. So if the data is retrievable, I should be able to cross-reference it to a trip.
And now I just remembered that I have that batch of DEF CON room keys hanging in the basement that should scan and add to the collection.
So here’s my question for the hackers out there. How you determine, or CAN you determine the nature of hex data stored in blocks with no apparent standard of default structure?
The dumps are on https://github.com/dc540/hfdumps if you’re interested in exploring this data.
Here’s a surprising factoid, which is probably statistically significant:
Of my main batch of cards, only 6 of 63 have NO DATA beyond sector zero, block zero. In other words, sector zero blocks 1 and 2, and sectors 1 through 15, are all zeroes — unused.
Of my DEFCON batch, 10 of 13 (>75%) have no data beyond sector zero, block zero.
What’s the pattern here?
Initial thoughts: Since sector zero block zero is normally unwritable, the Vegas hotels are security-forward, using NOTHING in the writable zones for authentication. So that scammers armed with a Proxmark can’t easily wreak havoc on their systems. It’s also possible that since I picked a number of these cards up as souvenirs after the con on eBay, they may have been sold by a rogue hotel employee after being tossed — in other words, they may have never been issued in the first place, providing another explanation for lack of data past sector zero block zero.
It’s possible that the six non-DEFCON cards I have are also from Vegas hotels. Without more information, that’s hard to tell.