Mifare Classic emulation not working with some readers (Galaxy S3) #83
Comments
|
Maybe related to #79 |
|
I have the same issue with
communication typically fails after reading a few sectors. Sometimes it can't read any, sometimes up to 6 sectors are read. Reading with other devices such as PN532 works flawlessly. |
|
Are the S3 able for MyFare Classic? |
|
Yes, that's actually the reason i kept the old S3, because it can read MFC.
It reads real cards just fine
Am 24.11.2016 19:48 schrieb "AndreasBujok" <[email protected]>:
… Are the S3 able for MyFare Classic?
My S4 are not. The S4 can only support NDEF Tags.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#83 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFwu1TJ5ePf-HZ6XuF1kldv_XEfjxe8Jks5rBD7HgaJpZM4K522O>
.
|
|
Seems to be the same issue as #79. |
|
I have the same issue with the ACR122U -> I can read the UID but not the sectors. I tried it with the battery only and with a connected power supply. |
|
we sniffed communcation betweeen the revG and the ACR and S3 with a second revG this are the logs: revg <=> ACR (try1) revG <=> ACR (try2) revG <=> S3 |
|
i looked at more logs when reading with the S3 first it does anticol: for a few times (?) then it tries to auth: something wonky happens during authenticated state |
|
after looking some more, the reader seems to send a HALT after 5ms, regardless if it recieves a nonce or not. maybe the response is too slow? and (dont mind the fffffff nonce, i fixed the rng for testing) |
|
after some testing i found similar behavior as #79: on another note, the S3 seems to be able to AUTH correctly more often when the revG is placed in the reader field, and then powered on. i think maybe some kind of interrupt is responsible for the problem (would explain different results on usb and without) with the P532 reader and the revG on USB, sometimes the auth just fails: is there some kind of error in the crypto1 emulation? after some successful AUTHS, the rest fails either on the card side or on the reader side (i guess, because it answers with halt or wupa) |
Hmm I tried but didn't see much difference |
|
@gregor4005 I just tried nfc-mfclassic with an ACR122U on a RevG and it worked flawlessly (upload card and read it out) both with cable and battery only. Can you describe what exactly you did?
To me, this looks like the Chameleon thinks the reader has authenticated himself successfully, but the reader somehow thinks the Chameleons answer was no good. We could verify this by logging the communication between an MFClassic emulating Chameleon and a reader (where reading actually works) during authentication. If we find authentication processes, where the answer from the Chameleon to the 8-byte reader message takes more than 1ms, this is an indicator that this theory is correct. On the other side, we should log communication between a reader where it does not work (e.g. S3) and the Chameleon and check whether we find single authentications that are accepted by these readers. I just logged the communication between ACR122U and Chameleon and I have found some authentication answers from the Chameleon that took more than 1 ms. The next step would be to identify what the Chameleon does during this time (1ms = 27120 clock cycles) and to make this faster. |
|
i briefly looked at my logs and found one: this is the revG emulating the same card as before, with the S3 as reader and a successfull auth (powering the revG on while in the reader field) here, the exchange is ~ 1ms i think your hunch is right that the response is coming too slowly. (this would also explain why some android apps display a "card has been removed" error) im not too familiar with the XMEGAs - is there an option of in-circuit debugging via usb? |
|
i finally got this thing running in the atmel simulator, and it seems from STATE_AUTHING to STATE AUTHED_IDLE it takes 17466 cycles (~650uS) Most time is taken by Crypto1Byte() (i think especially Crypto1LFSR) i temporarly removed the auth check in STATE_AUTHING by doing and now the response comes faster, and authentication works more reliable, its however not fast enough all the time. my code-fu however is not strong enough to optimize/see whats happening in Crypto1Byte to try and fix it. hopefully sombody else has any idea from the simulator |
|
@doegox @DrWummi I have had only the time to test if the new implementation of Crypto1 works basically (it does), but not if this error is fixes with it. So could you please check this? It would be also interesting, if the new implementation really is faster than the old one. |
|
looks promisiing, i'm gonna test this soon and report back |
|
@geo-rg @DrWummi yes there is some speed improvement \o/ FDT of a reply to an authentication request:
There is still a risk that some readers reject the ChameleonMini emulation but this is already much better. (Note that even some old MFC readers are rejecting new MFC or MFP SL1 because of the increased delay). I could use NXP TagInfo and TagWriter against the new ChameleonMini emulation successfully with a Nexus S. |
|
....works for me =) i haven't looked at the details of the patch yet, but |
|
It's also now working fine here with an Oneplus 3. 👍 I'll also test it against an access control system later, which wasn't working yet. |
|
How do I upload the new firmware please? I am using Linux |
|
I will answer my own silly question. Follow the initial wiki instructions as that points to the latest firmware. Sorry |
|
Is there anybody who is not happy with the solution? If not so, we could close this issue finally :) |
|
To be honest, I'm not 100% satisfied, still noticed some times, but very rare missing block when checking with my mobile. Also the access control system and vending machine still don't recognized it. But not 100% sure if related with this. |
|
OK, then I will leave it open, maybe there are still other problems with the MF Classic emulation. |
|
@twiddern Do you have any news on the problems that still occur? What are the exact steps you do, so we can reproduce the problem? |
|
My experience until today, I'm able to clone cards and trick the system with a clone card (magic card, set my own card serial). However the system refuses the card when I use the dump within the chameleon and still don't know why. I still see sometimes some missing rows when I scan the card with an NFC app on my Oneplus 3. |
|
Hi @twiddern @DrWummi @doegox Maybe you can test also? Thanks @ALL for your very useful help! |
|
Thanks for the mention, please give me some days time to verify it. |
|
Hi @twiddern, |
|
Hey @geo-rg, I'm sorry not yet. Haven't managed to flash the firmware yet and also not next week because of the #sha2017 event where I would be able to flash, but not to test. |
|
I don't have a ChameleonMini and I'm evaluating to buy it. I have a PM3 which has a similar issue. I don't know if the issue is the time or something else. I opened a issue and someone tell me PM3 use internal clock also for emulation, and if the clock of reader is not equal to clock of PM3 there is a problem with comunication. |
|
Hi @etmatrix, |
|
@geo-rg I was finally able to test the latest firmware and it works good on my OnePlus3. However I noticed interruptions when there was not enough distance. 1cm distance is already fine to get a good result. My next test with a company owned vending machine will follow |
|
Hi @twiddern |
|
I was also aware of this before, however for me it's a pro because I can put it into a case and have an excellent signal quality ;) |
mifare emulation works flawlessly with my pn532 reader, however my S3 is not able to read the cahmelion.
UID/ATQA/SAK can be read, after that the phone thinks that the tag has been removed and can't read any data (sometimes it manages to read block 0 before it thinks the tag has been removed)
log from such a transaction:
is there a known timing problem? where should i start to look? i have a DSO on hand if that could help me figure something out.
The text was updated successfully, but these errors were encountered: