Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up

Mifare 1k/4k dumps parser in human readable format

License

NotificationsYou must be signed in to change notification settings

zhovner/mfdread

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

55 Commits
 
 
 
 
 
 
 
 

Repository files navigation

Mifare Classic 1k/4k and Mifare Mini (320 bytes) dumps parser in human readable format.
Dumps can be grabbed withmfterm,mfoc or nfc-mfclassic tools from libnfc.org
Dump file size must be 1024 or 4096 bytes.

Includeddump.mfd -- Mifare 4k dump for testing.

Another tools

  • 010 Editor — hex editor that has Mifare template. Very handy for editingmfd files.
  • mfterm — Mifare terminal. Also can view and editmfd dumps.

Dependencies:

easy_install bitstring
or
pip install bitstring

Usage:

mfdread.py ./dump.mfd

Mifare mfd dump parser

The total memory of 1024 bytes in Mifare Classic (1k) and 4096 bytes in Mifare 4k is divided into 16 sectors of 64 bytes, each of the sectors is divided into 4 blocks of 16 bytes. Blocks 0, 1 and 2 of each sector can store data and block 3 is used to store keys and access bits (the exception is the ‘Manufacturer Block’ which can not store data).Mifare memory structure

The memory of 1KB and 4KB MIFARE Classic cards is ordered in a similar way. On both cards the first block (block 0) contains the UID, BCC, SAK, ATQA and Manufacturer data. This block is locked and cannot be altered. But some times it can be ;)
Mifare zero block structure

Access bits

Access bits define the way the data in the sector trailer and the data blocks can be accessed. Access bits are stored twice – inverted and non-inverted in the sector trailer as shown in the images.Mifare zero block structure

Some examples:

Data stored in the sector trailer:
01 02 03 04 05 06 FF 07 80 69 11 12 13 14 15 16
01 02 03 04 05 06 – Key A
FF 07 80 69 – Access bits
11 12 13 14 15 16 – Key B (or data if Key B is not used)

Bytes 6, 7, 8 are access data
FF 07 80

Binary representation:
11111111 = FF
(0)0000111 = 07
**(1)000(0)**000 = 80

The bits that are bolded and in parentheses are the ones that define access to keys (C13, C23, C33 in the image above) and they form the 001 sequence. The bits that are bolded and not in parentheses are the same bits inverted. They form, as expected, the sequence 110.

From the table above I can see that 001 means that Key A can not be read, but can be written and Key B may be read. This is the "transport configuration" and was read from the card that was never used.

Another example where access bits 6,7,8 are 0x78 0x77 0x88
mifare access bits explanation

Terms

AbbreviationMeaning
T=CLISO 14443-4 protocol
T=0ISO 7816-3 character-level protocol
T=1ISO 7816-3 block-level protocol
UIDUnique Identifier, Type A
RIDRandom ID, typically dynamically generated at Power-on Reset (UID0 = “0x08”, Random number in UID1… UID3)
NUIDNon-Unique Identifier
ATQAAnswer To Request, type A
ATQBAnswer To Request, type B
SAKSelect Acknowledge, Type A
RATSRequest for Answer To Select
ATSAnswer To Select
ATRAnser To ResetWhat's really ATR means
APDUApplication Protocol Data Unit
DIFDual Interface (cards)
COSCard Operating System
CLCascade Level acc. to ISO/IEC 14443-3
CTCascade Tag, Type A
NFCNear Field Communication
PCDProximity Coupling Device (“Contactless Reader”)
PICCProximity Integrated Circuit (“Contactless Card”)
PKEPublic Key Encryption (like RSA or ECC)
REQARequest Command, Type A (command 0x26)
WUPAWake-up type A (command 0x52)
SELSelect Command, Type A
RFUReserved for future use

SAK (Select Acknowledge, Type A) parsing

SAK response is 1 bytes length and 2 bytes CRC16.

Bit 3 is cascade bit indicates that UID is not complete and additional select needed.

The bit 6 in the SAK indicates, whether the PICC is compliant to the ISO/IEC14443-4 or not. However, itdoes not necessarily indicate, whether the PICC supports the MIFARE Protocol or not.

Other bits in SAK (b1, b2, b4, b5, b7, b8) is not described in ISO 14443-3.

What's really ATR means

ATR is for contact cards and is specified in ISO 7816. For contacless cards, it is the PC/SC reader (IFD) that generates the ATR.

The ATR is constructed based on:

ATS (Answer to Select) for ISO 14443 Type A cardsATQB and ATTRIB bytes for ISO 14443 Type B cardsThe ATR will be of the form 3B 8X 80 01 HB_ATS Parity_Byte where X is the number of bytes of Historical Bytes of ATS (HB_ATS).

The exact construction of ATR for contactless cards is given in section 3.1.3.2.3 of the PC/SC spec.

Given that the only variable is ATS, it should be the same regardless of the reader.

About

Mifare 1k/4k dumps parser in human readable format

Resources

License

Stars

Watchers

Forks

Packages

No packages published

Languages


[8]ページ先頭

©2009-2025 Movatter.jp