Writing to a card is only partially successfull #564
Comments
|
Hello, no problem here using the new and de old ACR122U with patch #535. Check that you do not have installed other libnfc in your system. I did this here: And the diff between lector-good-step3.mfd and lector-good-step4.mfd is ok. I tested it with "w" and "W". Regards, |
|
Thank you for testing. Good point. I'll double check that there is no system-lib related problem. I hadn't used the I'll close it for now as this is very likely to be the problem. I'll report back once I got around to testing it. |
|
All right, I'm back. I've cleaned up my system by uninstalling the package and manually installing the built version with the fix. Here's what I did: (I just use mfoc for dumps because I'm lazy, I cross validated the dumps using mfclassictool on my android phone, they check out) # Starting with a clean, freshly bought card.
> mfoc -O empty.mfd
> nfc-mfclassic w a u wantedData.mfd
NFC reader: ACS / ACR122U PICC Interface opened
Found MIFARE Classic card:
ISO/IEC 14443A (106 kbps) target:
ATQA (SENS_RES): 00 04
UID (NFCID1): 79 84 34 8e
SAK (SEL_RES): 08
Guessing size: seems to be a 1024-byte card
Writing 64 blocks |............................................................|
Done, 60 of 64 blocks written.
> nfc-mfclassic w a u wantedData.mfd empty.mfd # just to be sure
NFC reader: ACS / ACR122U PICC Interface opened
Found MIFARE Classic card:
ISO/IEC 14443A (106 kbps) target:
ATQA (SENS_RES): 00 04
UID (NFCID1): 79 84 34 8e
SAK (SEL_RES): 08
Guessing size: seems to be a 1024-byte card
Writing 64 blocks |............................................................|
Done, 60 of 64 blocks written.
> mfoc -O result.mfd
# ... found all sectors use default key ffffffffff, no errors in the outputThe Looking at the I tried this on two different card models, one of which is a magic card, the other was provided along with the reader. I added the three files as hex dumps to gist, if you want to look at it. Here's the output If someone could verify that the writing works completely, including keys and access bits, on their ACR122U-A9, I'll get some new cards and try again I guess. Here's the wantedData.mfd.gz. |
|
I can now say with confidence that it is not the card. I found another card I once got along with an arduino nfc module. It has data on it, I once wrote with my phone (including data in blocks other than the first block of each sector) and still only the first block of each sector is written by nfc-mfclassic. Still, this might also mean my reader is faulty rather than the library (or some system compatibility problem). I'm running ArchLinux 64bit on a Laptop. Kernel version: 5.3.1, glibc version: 2.29, gcc version: 9.1.0 |
|
Did you try with "W" instead of "w" in nfc-mfclassic W a u wantedData.mfd empty.mfd # just to be sure And your card must support writing the sector 0 |
|
I did with my magic card. Same result. This problem is not (directly) related to sector 0, block 0 though. (1k memory organized in 16 sectors with each 4 blocks of 16 bytes). It only writes successfully to the first block of each sector. So only to every 4th block if you will. The rest of the blocks remain untouched. Take a look at the dumps I posted in a gist. PS: I believe one of us is mixing up blocks and sectors. I don't know which is the canonical way, but the way I learned it initially is that a 1k card is organized in 16 sectors (largest unit), of 4 blocks each. Each block in turn consists of 16 bytes. Looking at the code this lib seems to have it the other way around most of the time, but it seems somewhat inconsistent throughout the code. |
|
I can now say with confidence that it is not the card. I found another card I once got along with an arduino nfc module. It has data on it, I once wrote with my phone (including data in blocks other than the first block of each sector) and still only the first block of each sector is written by nfc-mfclassic. Still, this might also mean my reader is faulty rather than the library (or some system compatibility problem). I'm running ArchLinux 64bit on a Laptop. Kernel version: 5.3.1, glibc version: 2.29, gcc version: 9.1.0 |
|
Me too, nfc-mfclassic only work with W write, the w command doesn't write anything. |
|
Same issue here, using an ACR122-A9 and @thekix 's fork of libnfc; as @targodan I am only able to write to block 0 of each sector (except sector 0) using the lower case w option. this is the output of uname -a:
also I do not think the cards are faulty since I am able to write them from my phone, just writing from the AC122-A9 doesn't work. |
|
Same issue here with a ACR122U-A9, writes are not complete (for example, keys stay unchanged). I'm using @thekix 's fork also. Unlike @tobiabocchi I have no error using w or W. |
|
Same issue for me, the problem isn't coming from the card because with MCT it works. Do you have some news, Thanks you in advance !!! |
|
i've a similar problem, the last part of each block (containing the keys) is not written by nfc-mfclassic, thus all written cards have still the default key A/B (all 0xFF) and default access bits set. eg. for W and a magic card I've verified that the dump The cards in question work fine as after writing the first block with I've checked with a diff and it's really only the keys and ACLs missing in each block, all other parts are written properly. I'm using debian with the following SW versions: |
|
Same problem. But in fact, only the first 4 blocks get written :
And this is what I get when I read what's inside : you can see that only the first 4 blocs (0 -> 3) are written.
|
|
Hello. I have exactly the same problem. Curiously on my Raspberry all the blocks are written but not on my Dell. I don't understand this issue. May be a future update ? |
That sounds interesting. @alan-maneg could you maybe check and post the versions (and ideally commit hash if self-compiled) of the following libs/packages/stuff for both your raspy and your dell?
I don't have a raspy running at the moment, so it might take some time, but I'll try to verify this once I have my raspy running again. |
|
Had another poke at this. I believe its either a problem in the ACR122U-A9 firmware or the driver for it. Because: I hacked my ACR122 because I got sick of these issues. I opened up the reader, cut the connections between the pn532 and the USB chip (they scrubbed the package so I have no part number I could give you). Then I bodged in the IO selection pins to select HSU (high speed UART) (I0 = 0 and I1 = 0) and soldered on some wires to exposed test pads for the serial IO. These I connected to an FTDI USB to UART converter. Now I can successfully write to the entire card (including sector 0, because magic card). That way I can at least guarantee that the RF hardware and the pn532 is not faulty. Of course I can still not guarantee that the USB chip isn't faulty in hard- or firmware. For additional hardware information: On the board was printed "REV 1.14C", the pn532 had the following writing on it (not sure which is the part number) On the left side of the chip where strange symbols, I presume a vendor logo. I could provide you with fotos if you're interested. |
|
It seem to have the same problem on a new ACR122U-A9. What is weird it that it worked with a really old 0 writable card I had but with the new cards (provided with the ACR) it only seem to copy half the blocks. The uuid is ok but the SAK is false (only with new card). I can correct the SAK with nfc-mfsetuid but it doesnt fix the partially writtend blocks. If I look at the badly writtend card it look like all key after block 4 are not written. |
|
I also use acr122u because when i was using libnfc5, it worked well, i start my script and copies was automatic without error, now i unfortunately did an update and it doesnt work, copies are wrong... So I use PCSC Mifare softwares on Windows but it takes very long time because I have to copy paste each bytes manually this is boring |
|
So for me it was not working on Kali with the 1.8. I juste installed a Buster Debian with version 1.7 and it is working like a charm. |
Merci t'es un boss, ça a fonctionné pour moi aussi j'ai bien fait de poster iciAs LeoBenoist said I just installed Debian (last version) and it's working now dont forget to do a "sudo modprobe -r pn533 nfc pn533_usb" to blacklist unwanted drivers |
|
@rrifi could you post some more information which version you of debian you tried and worked :) ? what was the "last version" (you meant latest?) that worked for you from debian?
just to be sure here |
|
@gebi like I said :) buster |
|
@gebi if you want, here is my Oracle VM Virtualbox exported machine (with mfoc and libnfc installed and ready to use) user debian:debian |
|
awesome thx! |
|
Hi, I can confirm that debian 10.9 with libnfc1.7.1 works (full writing capabilities). |
|
I was seeing this issue as well on Kali Linux and an ACR122U-A9. Using debian 10.10 and 10.8, I was getting "Connection timed out" errors when running |
|
So, the problem seems to be in the Kali/distro package, not in the upstream source code. IMO, this bug could be closed. |
|
Doubtful. When I opened the issue i was running ArchLinux 64 bit with Kernel version 5.3.1. Also someone tried it with Raspbian (see above). |
|
Yes it is on other distro! |
|
I can confirm it works for me on 1.7.1 release, however on 1.8.0 it doesn't. PN532 with UART |
|
Same issue here. Been trying lots of different ways, always the same result. I even tried the Debian VM image posted by @LeoBenoist but it won't see my ACR122U-A9 (beginning to wonder if there is simply a bad series of those?). |
|
In my case building from source from master helped. Reading and writing works flawlessly.
…-------- Original Message --------
On Oct 31, 2021, 11:54 PM, pierpierre wrote:
Same issue here. Been trying lots of different ways, always the same result. I even tried the Debian VM image posted by ***@***.***(https://github.com/LeoBenoist) but it won't see my ACR122U-A9 (beginning to wonder if there is simply a bad series of those?).
Are we the only one? Tempted to buy another one just to see, and return it in case...
—
You are receiving this because you commented.
Reply to this email directly, [view it on GitHub](#564 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AJ3APWFVJ27OJCZ5XLDUTLDUJXCJLANCNFSM4I3OP2AA).
|
|
@CDFN Did you start from the latest version? Or you built from 1.7.1? |
|
latest version, you must clone repository from master branch and build from there.
…-------- Original Message --------
On Nov 1, 2021, 9:59 AM, pierpierre wrote:
***@***.***(https://github.com/CDFN) Did you start from the latest version? Or you built from 1.7.1?
—
You are receiving this because you were mentioned.
Reply to this email directly, [view it on GitHub](#564 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AJ3APWG6ZTWBXDXRVOLAGRDUJZJG7ANCNFSM4I3OP2AA).
|
|
I confirm it worked when compiling from master on my 1.7.1 was not working (but slightly different errors). |
|
Thanks guys! |
|
🙄 |
|
Any updates on this ? I was facing the same issue and had to downgrade to 1.7.1 to make it work. Does anybody know why the 1.8 version doesn't work while the 1.7.1 does work ? |
|
It works, it's just the one on Kali repo and some other repo is crap. If you compile from scratch yourself, it works. That's what I ended up doing, with my very limited knowledge of Linux, and it now works. |
|
I'm on arch, and it doesn't work either ... As you can see, it downloads the binary from the github releases. So the problem is not from Kali. |
|
Because github releases has incorrect package. You have to git clone master branch and start from there 😄 |
|
user : debian
pass : debian
& for root
user : root
pass : toor
Le jeu. 3 mars 2022 à 04:51, vuongdat8007 ***@***.***> a
écrit :
… @gebi <https://github.com/gebi> here is the link
https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/ i downloaded
"debian-10.8.0-amd64-netinst.iso"
if you want, here is my Oracle VM Virtualbox exported machine (with mfoc
and libnfc installed and ready to use)
https://mega.nz/file/8o9FjKJQ#VnjxLO-59ARyzunQ5II57kPKND04kmSr2Tw64a3UD-A
user debian:debian & root:toor
Hello,
User and password did not work.
Can you recheck please?
Thanks a lot!
—
Reply to this email directly, view it on GitHub
<#564 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ARJUNRRE3KE7KNRF43NP56LU6AZNBANCNFSM4I3OP2AA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Can you tell me if the commands below are correct to clone an RFID card? To extract: To write on the blank card: Thanks |
Yes your commands seems to be correct Here is how i do to extract : mfoc -O extracted.dump To write : nfc-mfclassic W a dataToCopy.dump (i just specify the dump which contains the data i want to write in the blank tag) |
Thank you for your virtual machine, I will leave it as soon as I have time. Thank you for your response ^^ I just did a test with your debian VM. I extracted my original badge When I want to write on the blank card with the command: nfc-mfclassic W a u original.mfd blank.mfd f He tells me as a result How do I know if the blank card I have is with block O unlock sorry I'm a beginner |
This error appears when you can't write in the 0 block Is your tag UID Changeable ? If not, try with W but lower case* |
|
I tried with Kali and I also got an error, I think my blank card is not writing to block 0. Is there a trick to know if it's a good card or not? THANKS
|
Maybe it's an old badge that you found, and no longer had a use for, so you decided to write on it? Because if you use a tag which is not made to write data on it, you may meet some struggles (because some blocks can be write protected, etc. ) You should use Mifare 1K block 0 Changeable from Aliexpress The trick to know if uid is changeable or not : Take all the content of https://gist.githubusercontent.com/hiviah/199362d9b60e30e98ce06ad971d761a8/raw/05ee247cc5f7301e0de7788c7589fdf4543a847f/nfc-detect-rewritable-uid-mifare.c Save it in a file, like "detect.c" Compile it -> run the command "gcc detect.c -o detect -lnfc" Put your tag on the ACR122U, then run the program by launching the command "./detect" (which is the compiled program) |
|
Thanks , I made a backup of my wash card and would like to write on a blank card. I will try your advice to check if blank cards have block 0. If in doubt, I will order other cards on Aliexpress but I have doubts because it says Android MCT compatible: I just found this amazing item on AliExpress. Take a look there ! €2.02 22% off | 5pcs/lot 13.56Mhz RFID ID Card Sticker Keyfob Tag Changeable Night 0ampa NDavid Android MCT Copy Clone Duplicator |
|
Feedback
😭 |
I recently got an ACR122 and am also affected by #535. Can confirm, pull-request #563 solves the issue. I'm currently running a self compiled version based on commit f8b2852 with #535 merged in.
I do not know if this is related to the library, the pull-request or my reader/writer, but I'm having trouble writing a dump to a card. It only seems to successfully write the first block of each sector. It neither writes to the other sectors nor does it overwrite the keys or access bits.
I tried this with two types of cards, both the same problem, so I doubt it's the card(s) that are faulty.
Here's what I do:
No errors come up and in the end it outputs the following each time. (I know blocks 0-3 are locked unless its a magic card.)
After dumping the card again, the keys and access bits are unchanged and only the first block of each sector is overwritten.
My reader is a ACR122U-A9, I'm running ArchLinux 64 bit with Kernel version 5.3.1
The text was updated successfully, but these errors were encountered: