Minutes 2025-02-13

1. Presentation from Noah on creating MIFARE Classic polyglot cards!
   1. Brief primer of NFC and RFID
      

      Members hanging out around the round table
      1. HID and NXP duopoly
      2. Many organizations use credentials with broken or nonexistent encryption
   2. MIFARE
      1. MIFARE Classic
      2. MIFARE DESFire
      3. HID iClass
   3. MIFARE Classic
      1. Crypto1
         1. Security through obscurity
      2. MIT hackers break it overnight
         1. NXP attempts to sue, fails
      3. Used in lots of hotels and organizations that don't know any better
   4. Visual representation of data on a MIFARE Classic card
      

      Response to being photographed
      1. The '1K' in "MIFARE Classic 1K" is the total space
      2. There's only 720 bytes of usable space
      3. Block 0 is for manufacturer data
         1. First 4 bytes are the UID (serial number) of the card
      4. Blocks 2/3 are for the MAD (more on this later)
      5. the rest of the sectors are for data
   5. MIFARE Classic 1K is the cheapest version of these cards
      1. There exist 2K and 4K variants
      2. Not very useful since most orgs just store an ID number on them anyway, which takes like 10 bytes, and leave the rest blank
   6. Is this allowed @ Tech?
      1. In all of IT's and the Universities policies, nothing says you can't put your own data on a different medium
      2. But they do explicitly disallow unauthorized distribution, so don't hand out your card or share a copy of the data dump
      3. "not an issue until it becomes one"
         1. Don't otherwise abuse services or technology and it won't pose an issue
   7. How it works
      1. Key Diversification Function (KDF)
      2. Take the (in this case) four-byte UID
      3. 

         Logan cutting his card
         Plug into 'black-box' algorithm
      4. get keys for that sector
      5. We don't have the KDF for Schlage, but we can get a 1:1 copy of the data anyway
      6. The first sector is the one that we care about
   8. Orange bytes are access bits
      1. These define read/write permissions
      2. If the access bits are configured to never allow writing the access bits, they're 'bricked'; IE permanently locked and can never be changed
      3. For this reason, we use the access bits of 787788 instead of the OEM access bits of F0FF00 to keep the same KeyA/KeyB R/W permissions, but also allow re-writing the access bits again in the future
         1. Can be useful if anyone wants their LUG ID to be a different card in the future, like a hotel key or convention pass
   9. General purpose byte - not super important
   10. Weigand value is the one that were looking for
       1. Card numbers are printed on the card
       2. Wiegand values are all sequential in most systems
       3. These are both stupid
   11. The MIFARE Application Directory (MAD)
       

       Josh programming an ID
       1. Allows formatting the data in the card in special ways
       2. Designed to allow multi-tenant functionality
       3. The purpose was to use different sectors to store different 'types' of applications  (vending credits, bus passes, dorm access, etc)
          1. No one uses it like this
       4. But it also allows encoding data as NDEF (what we care about)
       5. NDEF
          1. Special type of standard by NXP, the company with a borderline monopoly on NFC
          2. Can store files, contacts, pictures and more
          3. Commonly used on NTAG chips (ex. NTAG215/216)
       6. MAD normally is in sector one, which on our cards, is where our ID numbers are
       7. Mobile devices look for mad in sector 0, then reads in sector 1 even when the MAD specifies otherwise
       8. Don't implement spec properly
       9. IOS is really strict with some aspects, but still doesn't implement it correctly
   12. What do we do?
       

       Closeup of the ID being programmed
       1. Allegion has our backs
       2. Schlage readers support a zillion card formats
       3. One of these formats is a card with the data in sector 15 (the last sector)
       4. we can just copy+paste our sector 1 data down to sector 15, and it works all the same
       5. This frees up sector 1 to be used to our MAD data
       6. This trick let's us make other kinds of Polyglot Cards
          1. Noah's Tech+Elements NFC (gen4) / RFID (t5577) Ring
   13. Dining halls and printers only use UID (really insecure)
       1. This means you can't write your data to an RFID tag, as they only work with a 13.56mHz NFC tag
   14. Onto the fun stuff!
       1. Josh literally just finished the script as presentation ended
       2. Not tested yet
2. Handed out materials to create IDs for people who haven't made them yet
   1. For people who already created theirs last meeting, started on the polyglot creation
   2. They work!
      1. They even work on iPhones!
3. Borrowed Ethan's Flipper Zero to check if the unlabeled stock of cards were gen1 or gen2
   

   Anika showing off the front and back of her two LUG IDs
   1. We ran out of pre-confirmed gen2 tags
   2. Didn't want to use gen1 tags, so members could rewrite cards with their phones at a later date
4. USG Budget Hearing @ 8:20 PM
   1. Took some quick pictures before leaving at 8:15 (the ones embedded in these minutes)
   2. Noah, Dane, Lucas, and Logan went
   3. Was only 10 minutes, meetings are very short
   4. Seems to have gone well
5. Returned to the meeting
   1. Helped finish up remaining cards
   2. Discussions about integrating LUG into RedTeam and some future plans for RedTeam's leadership as people slowly dispersed