Ok so im having trouble

So, at this point, I think I need a magnet to disrupt the field around the lock, lol Is that really a thing?

Not really a magnet but a passive coil that basically re-resonates the field and should allow you to get a very read with an x-series chip sitting over that coil.

so an LED? @amal

No, a wire coil, but it would be designed to act as a passive element coupled to the antenna in your phone.

In practice that means a specific size and shape of wire coil placed in a specific spot.

so you are telling me I would have to put something betwwen my hand and the lock

Yes…

See here.

@amal and @satur9 have discussed making a product like this (but presumably as a pcb, and maybe better tuned) but that was only in the last few days.

You might want to check out this thread and if you have a diagnostic card try using that between your implant and your reader to see if it helps.

Hey hey hey,you do not underestimate my tuning! :wink: :rofl:

2 Likes

will not even read now. Im pretty sure this thing is bricked ,
I can wrote to it but HF Search brings back error
i really need help with this chip

I have briefly skimmed through the post to understand the trials and tribulations so far but most likely have missed something somewhere.

I have had similar difficulties with my xM1 previously.

I would be interested in learning the answers to the following questions:

  • What has lead you to believe that the tag is bricked? The more details the better
  • What have you wrote to it and how did you verify it was successful?
  • What errors do you encounter when you try hf search after writing to it?
  • Do you have any MFC Gen1a tags to practice/experiment with that isn’t an implant?
1 Like

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 .

it does get power as well, 1 -2v drop from hf tune

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 :thinking: 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

ubuntu_2021-08-17_09-26-08

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

Csetuid Eg
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`

hf 14a in eg
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
  1. 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.
  2. You’ll want to save the trace by issuing trace save -f ThisIsAFileName.
  3. Load the trace for viewing by issuing trace load -f ThisIsAFileName.
  4. View the trace by issuing trace list -t 14a -1
Physical Comms Sniffing with PM3 Example


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.

4 Likes

Hi, is there a way to fix this on a gen2 mifare chip. The hf mf csetuid -u command doesnt seem to work on gen2 :frowning:

Gen2 does not need anything special to write to any sector… They are all writable.

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)
  1. View current anti-collision configuration
    hf 14a config
  2. Disable BCC0 checking
    hf 14a config --bcc ignore
  3. 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
  4. Reset anti-collision to defaults
    hf 14a config --bcc st

Please try the above and let me know how it goes.

2 Likes

I appreicate your reply,

I tried the steps and when i ran hf 14a info after changing the hf 14a config it returned the following:

[#] BCC0 incorrect, got 0xff, expected 0x00
[#] Using BCC0=0xff to perform anticollision
[#] Card didn’t answer to CL2 select all
[#] Can’t select card

and I got this output for all commands following :frowning:

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.

1 Like

Ok, so this gives me a different output now…

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:

[=] Writing block no 0, key B - FFFFFFFFFFFF
[=] data: 01 02 03 04 04 08 04 00 00 00 4A 49 52 56 49 4E
[#] Auth error
[-] Write ( fail )
[?] Maybe access rights? Try specify keytype hf mf wrbl -a ... instead

Sorry I am very inexperienced with this device but thanks for the help!