Thank you for your answers to the questions I posed.
BCC0 incorrect, got 0xff, expected 0xd8
Example Image showing error on a PM3
The above error shoudnt be seen as a card failure but more so as a misconfiguration which can be corrected. BCC stands for Block Check Character which is just a fancy additional check that needs to be correct to ensure that the UID has been written correctly. For more info see section 2 in AN10927
Quick steps to fix a bad BCC using a PM3
0 - Identify bad BCC
Very easily done by issuing the command hf 14a info
If bad BCC is present the output will read: BCC0 incorrect, got 0xNN, expected 0xNN (Where N is a hex byte; this response will differ per card due to the UID)
If a good BCC is present then the output will be details pertaining to the card.
1 - Write the correct BCC value
With a gen1a one can use the command hf mf csetuid -u NNNN to re-set the UID which will automatically calculate and write the correct BCC0 value. (Where N is a hex byte meaning that NNNN in the command would be the UID to be written; see hf mf csetuid -h for help)
Example Image Showing csetuid Command
Outlined in red is the BCC0 value. Note the difference in the old, bad value compared to the new, correct value.
2 - Validate the newly written information
Very easily done by issuing hf 14a info
This should now return the cards details as expected.
Example image of card details following `hf 14a info`
Notice the UID, SAK and ATQA values. All of this is expected info for a MFC.
─────────────────────────────────────────────────
Card didn’t answer to CL1 select all
The above error shouldnt be seen as a bad/broken/bricked card.
From my experience with the proxmark and MFC cards, this is usually an indication of bad coupling between the card’s antenna and the PM3 antenna.
The easy fix for this is to introduce some space/a gap between the card and PM3. This is usually enough to offset the badly tuned antenna of the card to couple better with the PM3 antenna.
I would be interested in seeing the proxmark logs when you were trying to write/read/clone cards.
─────────────────────────────────────────────────
Im not too sure how or why there would be an electromagnetic field around the lock. Plus given that passive RFID cards (like MFC) are powered from the electromagnetic field given off by the reader, this is actually a good thing. If there was no EMF given off by the reader then a passive RFID tag wouldnt be powered thus no communication would be happen.
─────────────────────────────────────────────────
To understand how the reader and card are communicating with each other, you can ‘sniff’ or eavesdrop on their conversation. This is sometimes known as sniffing the comms or ‘getting a trace’.
This can be done by telling the proxmark to listen to the communications and record them which can be played back at a later date.
Quick Steps for Sniffing Comms
- The command for this would be
hf 14a sniffto put the proxmark into an active listening state. Once sniffing is complete, just press the button on the proxmark to stop. - You’ll want to save the trace by issuing
trace save -f ThisIsAFileName. - Load the trace for viewing by issuing
trace load -f ThisIsAFileName. - View the trace by issuing
trace list -t 14a -1
