Skip to content

Instantly share code, notes, and snippets.

@bettse
Last active October 14, 2024 01:10
Show Gist options
  • Save bettse/36f25f9a2fcca74d773587cc8e780766 to your computer and use it in GitHub Desktop.
Save bettse/36f25f9a2fcca74d773587cc8e780766 to your computer and use it in GitHub Desktop.
iClass

iClass

Legacy

Picopass hardware. The PACS is blocks 6, 7, 8, 9. 6 is a config, 7 is the pacs data, but can overflow to 8. 9 has PIN, if applicable.

7, 8, 9 can be encrypted and if 3des, the key is 16 bytes and leaked. This is not the same as the key to read data from the card.

Keys to read data (even if encrypted) off card

These are 8 bytes

  • Standard

    This has been leaked. You can copy the 6-9 blocks between cards without decryption to duplicate credential

  • Elite

    Sometimes thought of as 'custom', but by defintion these are generated by HID. There is a list of ~700 that as been leaked from iCopyX (https://pastebin.com/KWcu0ch6).

    The loclass attack can be used to derive the key from sample emulated UIDs. It is rumored some readers have been upgraded to block the default UIDs, but others can be generated.

  • Custom

    These are keys the customer generates. Some of the keys in the iCopyX leak (https://pastebin.com/KWcu0ch6) might be custom keys. If the key is long (AES length) the SE KDF is used; If the key is short (64bit), the standard KDF is used. This means loclass won't work against custom keyed systems.

Data layout

Block 6: Config

TL;DR: if the last byte is 0x17 then block 7, 8, 9 are encrypted. Use https://iclass.ericbetts.dev/ to decrypt

b7 >> 4 & 0xF -> ApplicationSubType 1=Standard, 2=Config, other values reserved for future use
b7>>2 & 0x3 -> ApplicationType 1=AccessControl, 2=ConfigCardBase, 3=ConfigCardExtension, 0=RFU
b7 & 0x03 -> EncryptionType, 0=None, 1=DES, 2=2K3DES, others RFU
b6>>7 & 0x01 -> HasSentinelBit Flag
b6>>5 & 0x03 -> UserIDBlockOffset
b6 & 0xF -> PinSize
b5 & 0x3 -> PasswordEncryptionType, 0=None, 1=DES, 2=2K3DES, others RFU
b5>>2 & 0x3 -> FolderNumber
b4>>5 & 0x7 -> PageNumber
b4 & 0x1F -> BlockNumber
Block 7

PACS bits with sentinel bit (unless pacs continued in next block)

Block 8

PACS bits continued (technically I think it is started here)

Block 9

other stuff and PIN

SR

Transitional credential. Keys and block 6, 7, 8, 9 are like Legacy, but there is a SIO (like SE) blocks 10+ An example is that you are at a place where some readers are legacy iclass readers and some are newer "SE" capable readers (SE meaning they can read an SIO). So the card has both the legacy credential and the SIO. Newer readers wlll try to read the SIO, older readers only look for the legacy credential.

SE

Standard key and KDF have not been leaked. The loclass attack doesn't work. The contents of 6+ are an SIO (Secure Identity Object). Can be Standard or Elite keyed like Legacy.

See also So, you correctly identified you have a iClass SE or SEOS credential.

Seos

Not Picopass. Javacard (smartcard), 14443a (aka NFC-A). Contains an SIO, but cannot be accessed without HID reader or HID SAM

Readers

There are lots of readers, and different readers have the potential to support different types of credentials. This shows what they can support at most. Some of these readers can be further configured to reduce what technologies they support.

reader prox iclass MFC iClass SR MFC SR iClass SE MFC SIO Desfire Seos
prox X
iClass X X X X
multiClass X X X X X
iClass SE X X X X X X X X
multiClass SE X X X X X X X X X
Signo X X X X X X X X X

SIO

If you've only got an SIO and you wonder what the length of the credential is, this information, experimentally derived and provided on Discord, may help.

SIO Payload Length PACS Minimum Size PACS Maximum Size
21 Bytes 25 bits 32 bits
22 Bytes 33 bits 40 bits
23 Bytes 41 bits 48 bits
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment