MIFARE Classic Sector Dump: What the Hex Actually Says

2026-11-02 · 1118 words

A card dump is the only description of a credential that does not depend on trusting somebody's reader. Every other form — the number printed on the card, the value the panel shows, the frame on the wire — has already been through a conversion that somebody chose. The dump has not. It is the bytes as they sit in the card's memory.

That also makes it the form people misread most often, because nothing in it is labelled and three of its conventions run against intuition.

The 1K layout, in one paragraph

A MIFARE Classic 1K card holds 1024 bytes, organised as 16 sectors of 4 blocks, and each block is 16 bytes. Blocks are addressed from 0 to 63. In every sector, the last block is special: block 3 of sector 0, block 7 of sector 1, block 11 of sector 2, and so on. Data lives in the other three blocks of each sector; the fourth holds the keys and the permissions for that sector.

So a full dump is 64 lines of 16 bytes if your tool prints one block per line, or 1024 bytes of continuous hex if it does not. When a dump arrives as one long string with no line breaks, the first thing to do is re-split it at 16 bytes — otherwise every offset you compute from it will be wrong, and wrong in a way that still produces plausible-looking numbers.

Sector 0, block 0 is not like the others

The first block of the first sector is the manufacturer block, and it is read-only. Its bytes are laid out roughly like this:

• bytes 0 to 3 (or 0 to 6, or 0 to 9): the UID
• the byte after the UID: the BCC, a checksum computed as the XOR of the UID bytes
• the next byte: SAK
• the next two bytes: ATQA
• the rest: manufacturer data

Two consequences follow. First, you cannot change a card's UID by writing to it — that block refuses writes, which is why "UID changeable" cards are a separate product with a different chip inside, not a setting. Second, a 4-byte UID and a 7-byte UID produce different layouts inside the same block, so a script that hardcodes offsets 0 to 3 will read a 7-byte card's UID as "the first four bytes" and silently drop three.

The UID is stored backwards

This is the part that costs people the most time. MIFARE stores the UID least significant byte first, while most readers, panels and printed card numbers show it most significant byte first. A card whose dump begins E1 5A 3C 04 is the card a reader calls 043C5AE1.

Anyone who has compared two readers already knows this failure mode from the other direction — see why card number formats differ for the same problem in decimal and in 125 kHz readers. The dump does not have a convention of its own; it simply preserves the chip's byte order, and every layer above it may or may not reverse that order before showing you a number.

The BCC byte is a useful check here. XOR the UID bytes together and compare: if the result does not match the byte following the UID, either the UID length is not what you assumed, or the dump is not the block you think it is. It is a one-line check that catches the most common misreading.

The trailer block is three fields, not one

The last block of each sector contains, in order: 6 bytes of Key A, 4 bytes of access bits, 1 general-purpose byte, and 6 bytes of Key B. That is 17 fields' worth of meaning packed into 16 bytes, and the reason a "key" is never a 16-byte value no matter how often it is described that way.

Three things surprise people here:

Keys cannot be read back. The card will tell you whether a key is correct, and nothing else. A dump therefore never contains the keys in the sense of revealing them — the tool that produced the dump either already knew them or the sector is showing its factory defaults.

The access bits are stored three times. The four bytes hold the permission bits plus two inverted copies, so that a single flipped bit can be detected rather than obeyed. That is why the same configuration shows up as FF 07 80 in almost every tutorial: it is not a magic constant, it is one particular set of permissions written into all three copies.

A factory-fresh card is recognisable. When a sector has never been configured, its trailer usually still reads FF FF FF FF FF FF FF 07 80 69 FF FF FF FF FF FF. If you see that in a sector you expected to be in use, the card has not been personalised — or somebody reset it, which for a credential is worse news than a wrong number.

The 4K cards break the pattern

A 4K card is not "1K times four". It holds 4096 bytes in 40 sectors: sectors 0 to 31 are four blocks each, exactly like the 1K layout, and sectors 32 to 39 are sixteen blocks each. Block numbering continues past 63 instead of stopping there, and the trailer of a 16-block sector is block 15 of that sector, not block 3.

Any code that assumes "16 sectors" or "the trailer is at index 3" works perfectly on the card it was tested with and produces quietly wrong results on the other one. That is the same failure shape as reading a 34-bit credential with a 26-bit parser: no error, just a different and entirely plausible answer.

Three readings to distrust

• A number that looks clean. If a UID reads as a round decimal or a familiar pattern, check the byte order before believing it.
• A dump shorter than you expected. Truncated dumps are common; a 1K card is 1024 bytes and a 4K card is 4096, so count before analysing.
• A sector with no trailer. If your dump has 15 bytes in a block, the tool dropped one and every offset after it has shifted.

Where this connects to the wire

The dump is the card side; the Wiegand frame is the wire side, and the two disagree in ways that matter. A panel often stores only the low bytes of a UID, or converts it through a facility-code layout that was designed for a different card generation. When a card "works everywhere except one door", the useful comparison is dump bytes against frame bits — not the numbers printed on two different screens.

If you also have a file whose type you are inferring from its first bytes, reading signatures covers the same discipline for a different kind of binary: the first bytes are evidence, and the extension is not.