1* What has lead you to believe that the tag is bricked? The more details the better
will not read at all after wipe
2* What have you wrote to it and how did you verify it was successful?
wrote a key to it, wrote to card first and worked on card, not on chip
3* What errors do you encounter when you try hf search after writing to it?
pm3 → hf search
[/] Searching for ISO14443-A tag…[#] BCC0 incorrect, got 0xff, expected 0x00
[#] Aborting
[!] No known/supported 13.56 MHz tags found
[usb] pm3 → hf search
[|] Searching for ISO14443-A tag…[#] Card didn’t answer to CL1 select all
[!] No known/supported 13.56 MHz tags found
[usb] pm3 → hf search
[!] No known/supported 13.56 MHz tags found
4* Do you have any MFC Gen1a tags to practice/experiment with that isn’t an implant?
wrote to a CUID card and works, not on chip.
I think we have came to the conclusion thazt the ldoor will not allow the chip to be read, becasue of an electromagnetic field around the lock, I have thought about buying a magnet but they say I need a passive antenea which is pointless I might as well carry the fob around. Im actually kinda pissed about the situation and havent even messed with it again until today.
Still doesnt read or write, and you are the only person that has even asked a question in a month .
The xSeries are a great range of implants, but, where the provide ease of install, discreet placement and minimal realestate, they have a trade off with range and coupling to a reader.
I wonder if a FlexM1 would yield better results for your situation either gen1a or gen2
Have you considered that?
OR
If you were up for it, a FlexMT should almost certainly have the range you are requiring for your reader
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 sniff to 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.
The above image shows how to physically position the PM3 and card in relation to the reader as a suggestion.
Image is suggesting: Reader - PM3 - Card
Reader is at the bottom, PM3 in the middle and card on the top.
Yes it is possible to fix this issue on a Gen2. Only difference being is that you have to rewrite all of B0 using the normal write command hf mf wrbl
The only limiting factor which can prevent fixing this issue on a Gen2 would be if the sector bits (control write/read access to sector) are set in a way that restrict modifying S0.
I’m also assuming you are having the same issue as above with a bad BCC0 only.
In order to understand the issue further and be able to try to get some data from the card, we can disable anti-collision which is the feature that give this error.
Steps to disable anti-collision & write good B0 data (no backdoor commands)
View current anti-collision configuration hf 14a config
Disable BCC0 checking hf 14a config --bcc ignore
Try to read card data hf 14a info
2.1 If above command works, read S0 contents hf mf rdsc -s <Sector number> -k <key|12Hex> 2.1.1 Write good B0 to fix BCC0 issue hf mf wrbl --blk 0 -k <key|12Hex> -d <data|16hex>`
Example data/good B0: 010203040408040000004A495256494E
Reset anti-collision to defaults hf 14a config --bcc st
Looks like more issues than just BCC0. Usually a ‘CL2 select’ issue can be down to card-PM3 antenna coupling so try some distance and try to read the card again.
Just in case there are other anti-collision issues, you could disable all anti-collision checks to be sure.
Fully disable all anti-collision checks: hf 14a config --atqa skip hf 14a config --bcc ignore hf 14a config --cl2 skip hf 14a config --cl3 skip hf 14a config --rats skip
Double check all checks are off: hf 14a config
Try reading the card again: hf 14a info
If you get some response now, you should be able to try re-writing B0 with good values (see previous reply).
Once done, re-enable anti-collision checks: hf 14a config --std
If you don’t get any response after fully disabling anti-collision, try some distance between the card and the PM3.
If still not successful, let me know how far you got and we can troubleshoot more.
hf 14a info produces this:
[=] Card doesn’t support standard iso14443-3 anticollision
[+] ATQA: ff ff
However, when I run rdsc I am getting an auth error, I have tried the default key which was FFFFFFFFFFFF. and also the key of the card I cloned which was A0A1A2A3A4A5 and neither that or the b key B0B1B2B3B4B5 work so I must have changed it without realising… or maybe the access conditions are locked and preventing me from reading. And writing has a similar error:
From what youve said all we can really conclude so far is that B0 is messed up and needs fixed.
I am somewhat interested in what the card operations were before you got this issue.
Im assuming we have some unknown keys for S0, so we can try and recover the keys.
Completely disable all anti-collision checks again.
Lets check all sectors against a pre-existing dictionary file containing a list of known keys and dump any found keys to a file: hf mf chk -f mfc_default_keys.dic -d
Based on the output from the above, we can either move on to reading/writing B0 or we will have to recover the keys using another technique.
Please let me know what the above command outputs and we can take it from there.
In the previous command, the -d was supposed to be --dump; my mistake.
I purposely didn’t specify --blk 0 in the command to see the results from the rest of the card’s sectors.
Given we have no keys, a way to get some keys would be to use some recovery techniques in the proxmark.
Without knowing what PRNG type the card has, we dont know what specific recovery method to use.
Thankfully the proxmark client has an automated process to recover keys that runs through all recovery methods and uses the most appropriate one. I usually wouldn’t recommend using it since it doesnt teach anything but this use case seems like a good exception.
To automatically crack keys from the card trying those in the pre-existing dictionary: hf mf autopwn -f mfc_default_keys
Do note that the above command is targeting all keys and all sectors for a 1k card.
I am still interested in seeing the keys from the rest of the card to understand how the keys are setup. Its common to see only sectors containing user/written information with non-default keys.
I am also still interested in the card operations before you started to get this error. Please share any details you have about what stuff you tried before getting this type of response. If you dont recall, you can share the log files from the client and I can have a look through them for you.
Okay i re-ran the previous command it didnt find any keys… they all came back as -------------. I think my last acion on the card was to write the data as hf mf wrbl --blk 0 -k FFFFFFFFFFFF -d FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFor FFFFFFFFFFFFFF078069FFFFFFFFFFFF. I wanted to copy a sector to see what it did to sector 7 but forgot to edit the command from --blk 0 to --blk 7 :/, and wasn’t really thinking about the access conditions. Where are the access conditions in the following data?
The auto pwn has been running for like an hour now so not looking too positive
If you only wrote data to B0 then it should be fine. Assuming the keys to S0 is default/unchanged, you could try writing the good B0 using key FFFFFFFFFFFF. This is based on your previous command working using the same key for writing to B0.
The access bits are stored within the sector trailer of each sector. The sector trailer is located in the 4th blocked per sector and takes the format <KeyA|12Hex> <AccessBits|4Hex> <GeneralPurpose|2Hex> <KeyB|12Hex>.
Since you only wrote to B0, your sector trailer should be unchanged and still in a good configuration.
Was this card blank before you write the bad B0 to it?
Ok I really thought I had tried that earlier but I just wrote to the block and it worked as expected with the key as FFFFFFFFFFFF… :D. So just to confirm in future I can actually write any data with the wrbl -d and it won’t change the actual access conditions? for example I have a dump of key in json and it has a section like so:
"blocks": {
"0": "16bytes of hex",
"1": "16bytes of different hex",
...
}
Do blocks 0-3 all represent sector 1 with the block 3 being the trailing block with keys?
Therefore I can just leave every fourth block as is and copy over other sectors?.
Glad that fixed it! Remember to enable all anti-collision checks again.
Yes, you can use hf mf wrbl to write any block give you have the correct keys. You’ll only modify the access conditions of that sector if you are writing to the sector trailer.
Yes, for sector 0 the blocks are 0-3, with block 3 being thr sector trailer which contains the access conditions. For sector 1, it would be 4-7 with blocks 4-6 being data blocks (can contain user defined data) and block 7 being the sector trailer.
either gen1a or gen2
