The difference
The beginning of sector 0 looked like this:
Original:
FE E9 73 49 2D 08 04 00 46 8F 35 50 55 50 24 10
Clone:
FE E9 73 49 2D 88 04 00 46 8F 35 50 55 50 24 10
Only one byte differs:
08 -> 88
Or, in binary:
08 = 00001000
88 = 10001000
^
Only bit 7 has changed.
Everything else in the dump is identical.
UID and BCC are correct
For a 4-byte UID, the first bytes of block 0 contain:
FE E9 73 49 2D ...
The UID is:
FE E9 73 49
and the following byte is the BCC:
FE XOR E9 XOR 73 XOR 49 = 2D
So the UID and its checksum are correct on both cards.
Both cards report SAK 08
What made the situation confusing is that MCT's Tag Info screen reports:
SAK: 08
for both the original badge and the Gen2 clone.
This is perfectly possible.
There are two slightly different things involved:
- the values stored in the manufacturer block;
- the values actually returned by the RFID chip during ISO 14443-A anticollision/select.
On a genuine MIFARE Classic chip these are closely related, but clone chips do not necessarily implement the internal behaviour in exactly the same way.
A Gen2/CUID card may therefore contain:
... 2D 88 04 00 ...
in block 0 while still answering:
SAK = 08
over RF.
The important point is that rewriting block 0 does not turn a Gen2 clone into genuine NXP silicon.
The visible memory can be almost byte-for-byte identical, while the internal controller remains a clone implementation.
Why the Gen2 card is still "magic"
A normal genuine MIFARE Classic card does not allow the manufacturer block (block 0) to be rewritten.
A Gen2/CUID card does.
That ability is implemented inside the chip itself; it is not simply a flag stored somewhere in the 16 bytes of block 0.
So even after copying the complete manufacturer block:
original memory -> clone memory
the cards are still internally different:
Original:
[MIFARE memory] + [original chip logic]
Gen2 clone:
[same MIFARE memory] + [clone chip logic]
This can explain small differences in behaviour that are invisible in an ordinary dump.
In my case the only visible difference after cloning is the 08 / 88 byte, and the resulting badge works normally.
What does MCT's 08778F option do?
MCT has another option on the "Write dump" screen:
Apply these Access Conditions to all sectors
with the default value:
08778F
This option is not related to the 08 → 88 difference.
A MIFARE Classic sector ends with a sector trailer.
For example:
Sector 0:
Block 0 Manufacturer block
Block 1 Data
Block 2 Data
Block 3 Sector trailer
Sector 1:
Block 4 Data
Block 5 Data
Block 6 Data
Block 7 Sector trailer
The sector trailer contains, roughly:
Key A
Access Conditions
General-purpose byte
Key B
The three Access Condition bytes occupy bytes 6, 7 and 8 of the sector trailer.
08778F is simply a set of MIFARE Classic access-condition bytes.
If the MCT option is enabled, MCT replaces the access-condition bytes in every sector trailer with:
08 77 8F
instead of preserving the values from the source dump.
Therefore, if the goal is to make a clone as close as possible to the original, this option should normally remain unchecked:
[ ] Apply 08778F Access Conditions to all sectors
while the option allowing block 0 to be written must of course be enabled for a Gen2/CUID card:
[x] Advanced: enable writing to block 0
Result
After several reads and writes, the result was consistent:
Original block 0: ... 2D 08 04 00 ...
Gen2 block 0: ... 2D 88 04 00 ...
MCT nevertheless reports:
SAK 08
for both cards.
And, most importantly, the copies work perfectly.
So the conclusion is:
- the dump is essentially identical;
- the UID and BCC are correct;
- the Gen2 card remains internally different from the original chip;
- the
08/88discrepancy appears to be a clone-chip implementation detail; - MCT's
08778Foption affects sector access conditions, not this byte in block 0.
In other words: a byte-for-byte memory clone does not necessarily imply byte-for-byte identical chip behaviour — and in this case that difference does not prevent the cloned badge from working.