-
Notifications
You must be signed in to change notification settings - Fork 439
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CRC errors when writing a MIFARE Classic 1K using USB_PN53x #410
Comments
Wow! If I understand correctly, you are using this device? I do have one and just run the Mifare Classic related tests from the libfreefare test suite with it and 2 Mifare Classic 4K:
So, your device look like defective. I may suggest reproducing the failure running the test suite as I did in order to confirm your problem before contacting the seller. In case the test suite does not fail, please provide a sample application that reproduces the error. |
Hi smortex, Thanks for your fast reply! I have a similiar device. So, I just ran the libfreefare test suite and here are the results:
I tested only one device so far. However, I know the problem exists with at least one other device. I can try up to 10 devices tomorrow, but I guess it's not just a single defective device. Any ideas? Best, |
I just run the test suite a few time successfully with the device you used… If the problem persist with multiple devices and multiple cards you try, maybe the environment is prone to errors (some kind of interference)? |
So, it looks like the tags (1k, round, 47mm) are the main problem. I just tried different 1k tags (blue keyfobs, as well as black keyfobs and cards by Digital Logic). Absolutely no problem! Your test suite does not throw any errors. On the other hand, surprisingly, running the test suite with my round tags and the SPI device results in errors, too. Maybe it's their shape, maybe they're just garbage. I have other round 1k tags in the storage room (other manufacturer, 45mm). I will try these tags tomorrow to see if they are better! Thanks for the idea with your test suite. This will help to prevent such problems! |
Note that some MFC clones are of poor quality and errors are more frequent with them. |
Ah, cool @TeeTrizZz ! I'm happy you found out what was going wrong. Maybe everything is not lost with your tags: if the use case is compatible with this, checking that all operations succeed and restarting on failure may have an acceptable time penality? @doegox, do you know how NXP's applications guess tags origin? Response-time based? |
@smortex several indicators are used for fingerprinting, I don't know all details. |
@doegox Thanks for the advice! My Galaxy S7 can't read MFC but I have a HTC in my office which can. I will check if the app detects if the tag is a clone. |
So, I tested my new tags, my old tags, different keyfobs and plastic cards. The thing is: They are actually all okay (i.e. your test suite reports no failures!), but I can "brick" them with your test suite (-> the test suite always reports 2 or more failures after that). The smaller the tag, the harder it is to brick the tag (45mm round tag, easy. 20mm keyfob, not so easy). And this is also the reason why the test with the SPI reported failures, too. The tag was already bricked. I guess if an error is raised while writing data / formating the tag, the tag is not failure-free anymore. It also looks like the rotation and/or the position of the tag is important. And this might be the reason why smaller tags are harder to brick: It's easier to "misplace" a larger tag. Now this makes it a bit harder to find the "real" issue. Breaking the tag probably doesn't say too much about my problems writing FF FF FF etc. Maybe the device (in combination with my tags) is still the real issue here (or nfc-mfclassic? or the driver? etc.) . What kind of tags did you use, @smortex? Shape, size? I'm going to rerun the test with the SPI device to see if I can brick the tags with this device, too. The only problem is that they are not really comparable. Their antenna is totally different, it's a different chip, etc. I will also test if my new tags have the FF FF FF problem (or if its less frequent). Any ideas? |
One more information: The two keyfobs are bricked because writing their trailor failed, so that the authentication now fails. Using nfc-mfclassic, I can't read all blocks. This is totally understandable. The card, however, is a totally different case. I can read all blocks with nfc-mfclassic. No problems. But this is the result from your test suite:
Sometimes I even get 7 failures! What is going on here? |
Maybe I am confused, but isn't the card integrity supposed to be guaranteed? As far as I am concerned, I would expect a write failure on a trailer block to have no impact on it's content, that is the sector is still accessible with the same keys as before. And if the CRC error is detected in the response by the PCD, then the command may have succeeded and using the old or new keys is supposed to act as expected. |
Interesting! In this case, this seems even stranger. I'm especially surprised about the different situations: readable but non-writable (?) plastic card (although the access bits are still standard), non-readable but somehow writable key fobs, strangly-behaving stickers... |
So, I finally found a solution. Placing a ferrite sheet directly below the antenna of the DL533N, decreases the error rate significantly. Writing the tag is now successfully, even if the tag isn't place properly. I read through a lot of different antenna and NFC documents and it seems that feritte below the antenna focuses the magnetic field above the antenna. Maybe this helps if someone has similiar problems as I had. |
Indeed ! Lifting the tag just a bit finaly allowed me to write it. |
Hi guys,
I have problems writing data to MIFARE Classik 1K tags with a USB_PN53x device (DL533N flat/OEM) due to CRC errors. This does not happen when using a SPI_PN532 device. Writing via SPI works flawlessly.
When writing data to a MIFARE Classik 1K tag, the nfc-mfclassic tool (almost) always stopped with a "failed to write trailer block" message. Sometimes it was block 3, sometimes block 7 (or any other trailor block), sometimes it worked with no problems at all. I checked the libnfc debug messages and found the reason: the chip reported an CRC error / transmission error. I was wondering why this only happened when writing the trailer block. So I tried to write similar data to other blocks, e.g. FF FF FF FF FF FF to the second block. Surprisingly, the result was a CRC error when writing the second block.
Long story short: When writing stuff like FF FF FF or 7F 7F 7F or any other data, which, in binary, represents a lot of ones, the chip will most likely crash with a CRC error. This is of course pretty unfortunate as FF FF FF FF FF is the MIFARE default key.
I already tried to change some of the settings in the chip's source code (i.e. disabling CRC, enabling/disabling easy framing) but to be honest, I don't even know what these settings do. Before wasting time: Is this a bug with the library, the chip, or the device? Is it a timing problem? Is there any way to fix this?
Unfortunately, I cannot use the SPI device as an alternative. So, I hope you guys can help me!
Thanks!
Best,
Fabian
The text was updated successfully, but these errors were encountered: