ChameleonMini
ChameleonMini copied to clipboard
emsec
Mifare Classic emulation not working with some readers (Galaxy S3)
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:
41 05 C8 75 7C AA 73 22 87 40 09 C8 77 93 70 7C AA 73 22 87 44 4A 41 03
C8 77 08 B6 DD 40 04 C8 90 50 00 57 CD 91 00 C8 90 40 01 C8 93 52 41 02
C8 93 04 00 40 09 C8 95 93 70 7C AA 73 22 87 44 4A 41 03 C8 95 08 B6 DD
40 04 C8 9C 50 00 57 CD 91 00 C8 9C 40 01 C8 9F 52 41 02 C8 9F 04 00 40
09 C8 A1 93 70 7C AA 73 22 87 44 4A 41 03 C8 A1 08 B6 DD 40 04 C8 A7 50
00 57 CD 91 00 C8 A7 40 01 C8 AB 52 41 02 C8 AB 04 00 40 09 C8 AD 93 70
7C AA 73 22 87 44 4A 41 03 C8 AD 08 B6 DD 40 04 C8 B3 60 01 7C 6A 90 02
C8 B3 60 01 41 04 C8 B4 57 F6 F8 04 40 04 C8 BA 50 00 57 CD A0 04 C8 BA
DC 63 A2 F4 C0 00 C8 BB 40 01 C8 BE 52 41 02 C8 BE 04 00 40 09 C8 BF 93
70 7C AA 73 22 87 44 4A 41 03 C8 C0 08 B6 DD 40 04 C8 C5 50 00 57 CD 91
00 C8 C5 40 01 C8 C9 52 41 02 C8 C9 04 00 40 09 C8 CB 93 70 7C AA 73 22
87 44 4A 41 03 C8 CB 08 B6 DD 40 04 C8 D1 60 01 7C 6A 90 02 C8 D2 60 01
41 04 C8 D2 99 34 DD E2 40 04 C8 D8 50 00 57 CD A0 04 C8 D9 02 58 4F 7C
C0 00 C8 D9 40 01 C8 DC 52 41 02 C8 DC 04 00 40 09 C8 DE 93 70 7C AA 73
22 87 44 4A 41 03 C8 DE 08 B6 DD 40 04 C8 E4 50 00 57 CD 91 00 C8 E4 40
01 C8 E7 52 41 02 C8 E7 04 00 40 09 C8 E9 93 70 7C AA 73 22 87 44 4A 41
03 C8 E9 08 B6 DD 40 04 C9 0A 50 00 57 CD 91 00 C9 0A 40 01 C9 0E 52 41
02 C9 0E 04 00 40 09 C9 10 93 70 7C AA 73 22 87 44 4A 41 03 C9 10 08 B6
DD 40 04 C9 17 50 00 57 CD 91 00 C9 17 40 01 C9 1A 52 41 02 C9 1A 04 00
40 09 C9 1C 93 70 7C AA 73 22 87 44 4A 41 03 C9 1C 08 B6 DD 40 04 C9 27
60 00 F5 7B 90 02 C9 27 60 00 41 04 C9 28 0F 16 2B 3A 40 04 C9 2F 50 00
57 CD A0 04 C9 30 87 EB 6B BB C0 00 C9 30 40 01 C9 33 52 41 02 C9 33 04
00 40 09 C9 35 93 70 7C AA 73 22 87 44 4A 41 03 C9 35 08 B6 DD 40 04 C9
3F 30 03 99 9A C2 00 C9 3F 41 01 C9 3F 04 40 04 C9 45 50 00 57 CD 40 01
C9 48 52 41 02 C9 48 04 00 40 09 C9 4A 93 70 7C AA 73 22 87 44 4A 41 03
C9 4A 08 B6 DD 40 04 C9 50 50 00 57 CD 91 00 C9 50 40 01 C9 54 52 41 02
C9 54 04 00 40 09 C9 56 93 70 7C AA 73 22 87 44 4A 41 03 C9 56 08 B6 DD
40 04 C9 69 50 00 57 CD 91 00 C9 69 40 01 C9 6D 52 41 02 C9 6D 04 00 40
09 C9 6F 93 70 7C AA 73 22 87 44 4A 41 03 C9 6F 08 B6 DD 40 04 C9 75 50
00 57 CD 91 00 C9 75 40 01 C9 79 52 41 02 C9 79 04 00 40 09 C9 7B 93 70
7C AA 73 22 87 44 4A 41 03 C9 7B 08 B6 DD 40 04 CA 08 50 00 57 CD 91 00
CA 08 40 01 CA 0B 52 41 02 CA 0B 04 00 40 09 CA 0D 93 70 7C AA 73 22 87
44 4A 41 03 CA 0D 08 B6 DD 40 04 CA 9A 50 00 57 CD 91 00 CA 9A 40 01 CA
9D 52 41 02 CA 9D 04 00 40 09 CA 9F 93 70 7C AA 73 22 87 44 4A 41 03 CA
9F 08 B6 DD 40 04 CB 2C 50 00 57 CD 91 00 CB 2C 40 01 CB 2F 52 41 02 CB
2F 04 00 40 09 CB 31 93 70 7C AA 73 22 87 44 4A 41 03 CB 31 08 B6 DD
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.
I have the same issue with
- MF_CLASSIC emulation
- battery powered or USB powered, doesn't matter
- dumping with NXP TagInfo on a Nexus S
- no matter if it's using default keys or keys unknown to NXP TagInfo
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. Emulating UL works flawlessly.
Are the S3 able for MyFare Classic? My S4 are not. The S4 can only support NDEF Tags.
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 https://github.com/emsec/ChameleonMini/issues/83#issuecomment-262511689, or mute the thread https://github.com/notifications/unsubscribe-auth/AFwu1TJ5ePf-HZ6XuF1kldv_XEfjxe8Jks5rBD7HgaJpZM4K522O .
Seems to be the same issue as #79. Behavior is the same, no matter if powered from battery or usb
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)
44945 ms <+44945 ms>:CODEC RX (1 bytes) [93]
44945 ms < +0 ms>:CODEC RX (2 bytes) [0300]
45351 ms < +406 ms>:CODEC RX (1 bytes) [52]
45353 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
45369 ms < +16 ms>:CODEC RX (4 bytes) [6000f57b]
45371 ms < +2 ms>:CODEC RX (8 bytes) [558c1c0d8f175823]
45438 ms < +67 ms>:CODEC RX (1 bytes) [52]
45440 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
47192 ms < +1752 ms>:CODEC RX (1 bytes) [52]
47194 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
revG <=> ACR (try2)
56407 ms <+56407 ms>:CODEC RX (1 bytes) [26]
56408 ms < +1 ms>:CODEC RX (1 bytes) [78]
56409 ms < +1 ms>:CODEC RX (1 bytes) [01]
56409 ms < +0 ms>:CODEC RX (1 bytes) [01]
56409 ms < +0 ms>:CODEC RX (1 bytes) [00]
56410 ms < +1 ms>:CODEC RX (1 bytes) [00]
56410 ms < +0 ms>:CODEC RX (1 bytes) [00]
56410 ms < +0 ms>:CODEC RX (1 bytes) [c6]
56411 ms < +1 ms>:CODEC RX (1 bytes) [85]
56411 ms < +0 ms>:CODEC RX (1 bytes) [ef]
56477 ms < +66 ms>:CODEC RX (2 bytes) [a908]
56478 ms < +1 ms>:CODEC RX (1 bytes) [d2]
56483 ms < +5 ms>:CODEC RX (2 bytes) [2c02]
56743 ms < +260 ms>:CODEC RX (1 bytes) [26]
56744 ms < +1 ms>:CODEC RX (2 bytes) [9320]
56747 ms < +3 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
57090 ms < +343 ms>:CODEC RX (1 bytes) [52]
57092 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
57167 ms < +75 ms>:CODEC RX (4 bytes) [6000f57b]
57169 ms < +2 ms>:CODEC RX (8 bytes) [be73224144432f21]
57236 ms < +67 ms>:CODEC RX (1 bytes) [52]
57238 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
revG <=> S3
09907 ms < +9907 ms>:CODEC RX (2 bytes) [fe0b]
09915 ms < +8 ms>:CODEC RX (1 bytes) [26]
09917 ms < +2 ms>:CODEC RX (2 bytes) [9320]
09918 ms < +1 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
09964 ms < +46 ms>:CODEC RX (4 bytes) [500057cd]
09968 ms < +4 ms>:CODEC RX (1 bytes) [52]
09970 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
09978 ms < +8 ms>:CODEC RX (4 bytes) [500057cd]
09982 ms < +4 ms>:CODEC RX (1 bytes) [52]
09984 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
09990 ms < +6 ms>:CODEC RX (4 bytes) [500057cd]
09993 ms < +3 ms>:CODEC RX (1 bytes) [52]
09995 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
10002 ms < +7 ms>:CODEC RX (4 bytes) [60017c6a]
10005 ms < +3 ms>:CODEC RX (8 bytes) [97e381eea30782d0]
10011 ms < +6 ms>:CODEC RX (4 bytes) [500057cd]
10014 ms < +3 ms>:CODEC RX (1 bytes) [52]
10016 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
10022 ms < +6 ms>:CODEC RX (4 bytes) [500057cd]
10026 ms < +4 ms>:CODEC RX (1 bytes) [52]
10028 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
10034 ms < +6 ms>:CODEC RX (4 bytes) [500057cd]
10037 ms < +3 ms>:CODEC RX (1 bytes) [52]
10039 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
10045 ms < +6 ms>:CODEC RX (4 bytes) [500057cd]
10049 ms < +4 ms>:CODEC RX (1 bytes) [52]
10050 ms < +1 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
10056 ms < +6 ms>:CODEC RX (4 bytes) [500057cd]
10060 ms < +4 ms>:CODEC RX (1 bytes) [52]
10062 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
10069 ms < +7 ms>:CODEC RX (4 bytes) [500057cd]
10072 ms < +3 ms>:CODEC RX (1 bytes) [52]
10074 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
10080 ms < +6 ms>:CODEC RX (4 bytes) [500057cd]
10084 ms < +4 ms>:CODEC RX (1 bytes) [52]
10086 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
10093 ms < +7 ms>:CODEC RX (4 bytes) [60017c6a]
10095 ms < +2 ms>:CODEC RX (8 bytes) [1aa9fda561aa8d4a]
10101 ms < +6 ms>:CODEC RX (4 bytes) [500057cd]
10105 ms < +4 ms>:CODEC RX (1 bytes) [52]
10106 ms < +1 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
10112 ms < +6 ms>:CODEC RX (4 bytes) [500057cd]
10116 ms < +4 ms>:CODEC RX (1 bytes) [52]
10118 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
10124 ms < +6 ms>:CODEC RX (4 bytes) [500057cd]
10128 ms < +4 ms>:CODEC RX (1 bytes) [52]
10130 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
10137 ms < +7 ms>:CODEC RX (4 bytes) [500057cd]
10140 ms < +3 ms>:CODEC RX (1 bytes) [52]
10142 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
10148 ms < +6 ms>:CODEC RX (4 bytes) [500057cd]
10152 ms < +4 ms>:CODEC RX (1 bytes) [52]
10154 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
10160 ms < +6 ms>:CODEC RX (4 bytes) [500057cd]
10164 ms < +4 ms>:CODEC RX (1 bytes) [52]
10166 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
10171 ms < +5 ms>:CODEC RX (4 bytes) [500057cd]
10175 ms < +4 ms>:CODEC RX (1 bytes) [52]
10177 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
10297 ms < +120 ms>:CODEC RX (4 bytes) [500057cd]
10301 ms < +4 ms>:CODEC RX (1 bytes) [52]
10303 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
10309 ms < +6 ms>:CODEC RX (4 bytes) [500057cd]
10312 ms < +3 ms>:CODEC RX (1 bytes) [52]
10314 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
10323 ms < +9 ms>:CODEC RX (4 bytes) [6000f57b]
10325 ms < +2 ms>:CODEC RX (8 bytes) [1a3622187b059043]
10331 ms < +6 ms>:CODEC RX (4 bytes) [500057cd]
10334 ms < +3 ms>:CODEC RX (1 bytes) [52]
10336 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
10342 ms < +6 ms>:CODEC RX (4 bytes) [500057cd]
10345 ms < +3 ms>:CODEC RX (1 bytes) [52]
10347 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
10358 ms < +11 ms>:CODEC RX (4 bytes) [6000f57b]
10360 ms < +2 ms>:CODEC RX (8 bytes) [17a537f2e7c0af3a]
10366 ms < +6 ms>:CODEC RX (4 bytes) [500057cd]
10369 ms < +3 ms>:CODEC RX (1 bytes) [52]
10371 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
10377 ms < +6 ms>:CODEC RX (4 bytes) [500057cd]
10381 ms < +4 ms>:CODEC RX (1 bytes) [52]
10383 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
10390 ms < +7 ms>:CODEC RX (4 bytes) [6000f57b]
10392 ms < +2 ms>:CODEC RX (8 bytes) [d737ba22b7f1134d]
10398 ms < +6 ms>:CODEC RX (4 bytes) [500057cd]
10402 ms < +4 ms>:CODEC RX (1 bytes) [52]
10404 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
10409 ms < +5 ms>:CODEC RX (4 bytes) [500057cd]
10413 ms < +4 ms>:CODEC RX (1 bytes) [52]
10415 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
10422 ms < +7 ms>:CODEC RX (4 bytes) [6000f57b]
10425 ms < +3 ms>:CODEC RX (8 bytes) [cea4933667b11221]
10431 ms < +6 ms>:CODEC RX (4 bytes) [500057cd]
10434 ms < +3 ms>:CODEC RX (1 bytes) [52]
10436 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
10442 ms < +6 ms>:CODEC RX (4 bytes) [500057cd]
10445 ms < +3 ms>:CODEC RX (1 bytes) [52]
10447 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
10458 ms < +11 ms>:CODEC RX (4 bytes) [6000f57b]
10460 ms < +2 ms>:CODEC RX (8 bytes) [3904636616a8e9ee]
10466 ms < +6 ms>:CODEC RX (4 bytes) [500057cd]
10470 ms < +4 ms>:CODEC RX (1 bytes) [52]
10472 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
10478 ms < +6 ms>:CODEC RX (4 bytes) [500057cd]
10481 ms < +3 ms>:CODEC RX (1 bytes) [52]
10483 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
10493 ms < +10 ms>:CODEC RX (4 bytes) [6000f57b]
10495 ms < +2 ms>:CODEC RX (8 bytes) [d96b7504f10d82a3]
10502 ms < +7 ms>:CODEC RX (4 bytes) [500057cd]
10505 ms < +3 ms>:CODEC RX (1 bytes) [52]
10507 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
10513 ms < +6 ms>:CODEC RX (4 bytes) [500057cd]
10516 ms < +3 ms>:CODEC RX (1 bytes) [52]
10518 ms < +2 ms>:CODEC RX (9 bytes) [9370c6f38fb3097930]
10528 ms < +10 ms>:CODEC RX (4 bytes) [61002d62]
10530 ms < +2 ms>:CODEC RX (8 bytes) [3698d0886c95cacd]
10536 ms < +6 ms>:CODEC RX (4 bytes) [500057cd]
10540 ms < +4 ms>:CODEC RX (1 bytes) [52]
i looked at more logs when reading with the S3 the emulated tag is an empty mfc with default A/B keys (FF FF FF FF FF FF)
first it does anticol:
26632 ms < +4 ms>:CODEC RX (1 bytes) [52]
26632 ms < +0 ms>:CODEC TX (2 bytes) [0400]
26633 ms < +1 ms>:CODEC RX (9 bytes) [9370d6a960b3ac403c]
26633 ms < +0 ms>:CODEC TX (3 bytes) [08b6dd]
26640 ms < +7 ms>:CODEC RX (4 bytes) [500057cd]
26640 ms < +0 ms>:APP HALT (0 bytes) []
for a few times (?)
then it tries to auth:
26916 ms < +4 ms>:CODEC RX (1 bytes) [52]
26916 ms < +0 ms>:CODEC TX (2 bytes) [0400]
26918 ms < +2 ms>:CODEC RX (9 bytes) [9370d6a960b3ac403c]
26918 ms < +0 ms>:CODEC TX (3 bytes) [08b6dd]
26928 ms < +10 ms>:CODEC RX (4 bytes) [6000f57b]
26928 ms < +0 ms>:APP AUTH (2 bytes) [6000]
26929 ms < +1 ms>:CODEC TX (4 bytes) [86b424f5]
26930 ms < +1 ms>:CODEC RX (8 bytes) [3feca192169786f4]
26931 ms < +1 ms>:APP AUTHING (4 bytes) [c734c87e]
26931 ms < +0 ms>:APP AUTHED (4 bytes) [fdea01c0]
26932 ms < +1 ms>:CODEC TX (4 bytes) [fdea01c0]
26937 ms < +5 ms>:CODEC RX (4 bytes) [500057cd]
26938 ms < +1 ms>:APP UNKNOWN (4 bytes) [9c91f4ba]
26941 ms < +3 ms>:CODEC RX (1 bytes) [52]
26941 ms < +0 ms>:CODEC TX (2 bytes) [0400]
26943 ms < +2 ms>:CODEC RX (9 bytes) [9370d6a960b3ac403c]
26943 ms < +0 ms>:CODEC TX (3 bytes) [08b6dd]
26952 ms < +9 ms>:CODEC RX (4 bytes) [3003999a]
26952 ms < +0 ms>:APP NOT AUTHED (0 bytes) []
26952 ms < +0 ms>:CODEC TX (1 bytes) [04]
26958 ms < +6 ms>:CODEC RX (4 bytes) [500057cd]
26961 ms < +3 ms>:CODEC RX (1 bytes) [52]
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?
18170 ms < +0 ms>:APP AUTH (2 bytes) [6001]
18170 ms < +0 ms>:CODEC TX (4 bytes) [ffffffff]
18172 ms < +2 ms>:CODEC RX (8 bytes) [6c5372533da964aa]
18173 ms < +1 ms>:APP AUTHING (4 bytes) [e6b8a071]
18173 ms < +0 ms>:APP AUTH FAILED (0 bytes) []
**18178 ms < +5 ms>:CODEC RX (4 bytes) [500057cd]**
and
32579 ms < +20 ms>:CODEC RX (4 bytes) [6000f57b]
32579 ms < +0 ms>:APP AUTH (2 bytes) [6000]
32580 ms < +1 ms>:CODEC TX (4 bytes) [ffffffff]
32582 ms < +2 ms>:CODEC RX (8 bytes) [6f0a616f3bb4ef8d]
32582 ms < +0 ms>:APP AUTHING (4 bytes) [d6268f72]
32583 ms < +1 ms>:APP AUTHED (4 bytes) [010baaba]
32583 ms < +0 ms>:CODEC TX (4 bytes) [010baaba]
**32588 ms < +5 ms>:CODEC RX (4 bytes) [500057cd]**
32588 ms < +0 ms>:APP UNKNOWN (4 bytes) [b9489e50]
(dont mind the fffffff nonce, i fixed the rng for testing)
after some testing i found similar behavior as #79: my PN532 reader randomly fails to auth when the revG is connected to usb, and reads correctly everytime when the revG is battery powered.
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. @doegox @gregor4005 : could you try this with your revGs?
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:
41571 ms < +1 ms>:APP AUTH (2 bytes) [6027]
41572 ms < +1 ms>:CODEC TX (4 bytes) [7c8b9291]
41573 ms < +1 ms>:CODEC RX (8 bytes) [f2755f2e0bb843c5]
41574 ms < +1 ms>:APP AUTHING (4 bytes) [4fbb2fdf]
41574 ms < +0 ms>:APP AUTHED (4 bytes) [cd715870]
41574 ms < +0 ms>:CODEC TX (4 bytes) [cd715870]
41587 ms < +13 ms>:CODEC RX (1 bytes) [52]
41587 ms < +0 ms>:APP UNKNOWN (1 bytes) [7e]
41593 ms < +6 ms>:CODEC RX (1 bytes) [52]
41593 ms < +0 ms>:CODEC TX (2 bytes) [0400]
41595 ms < +2 ms>:CODEC RX (9 bytes) [9370d6a960b3ac403c]
41595 ms < +0 ms>:CODEC TX (3 bytes) [08b6dd]
41610 ms < +15 ms>:CODEC RX (4 bytes) [6027482e]
41610 ms < +0 ms>:APP AUTH (2 bytes) [6027]
41611 ms < +1 ms>:CODEC TX (4 bytes) [fe1d79dc]
41612 ms < +1 ms>:CODEC RX (8 bytes) [7550303d0bd91367]
41613 ms < +1 ms>:APP AUTHING (4 bytes) [01623f37]
41613 ms < +0 ms>:APP AUTH FAILED (0 bytes) []
41681 ms < +68 ms>:CODEC RX (1 bytes) [52]
is there some kind of error in the crypto1 emulation? after some successful AUTHS, the rest fails either on the card side
41610 ms < +0 ms>:APP AUTH (2 bytes) [6027]
41611 ms < +1 ms>:CODEC TX (4 bytes) [fe1d79dc]
41612 ms < +1 ms>:CODEC RX (8 bytes) [7550303d0bd91367]
41613 ms < +1 ms>:APP AUTHING (4 bytes) [01623f37]
41613 ms < +0 ms>:APP AUTH FAILED (0 bytes) []
41681 ms < +68 ms>:CODEC RX (1 bytes) [52]
or on the reader side (i guess, because it answers with halt or wupa)
1571 ms < +1 ms>:APP AUTH (2 bytes) [6027]
41572 ms < +1 ms>:CODEC TX (4 bytes) [7c8b9291]
41573 ms < +1 ms>:CODEC RX (8 bytes) [f2755f2e0bb843c5]
41574 ms < +1 ms>:APP AUTHING (4 bytes) [4fbb2fdf]
41574 ms < +0 ms>:APP AUTHED (4 bytes) [cd715870]
41574 ms < +0 ms>:CODEC TX (4 bytes) [cd715870]
41587 ms < +13 ms>:CODEC RX (1 bytes) [52]
41587 ms < +0 ms>:APP UNKNOWN (1 bytes) [7e]
41593 ms < +6 ms>:CODEC RX (1 bytes) [52]
41593 ms < +0 ms>:CODEC TX (2 bytes) [0400]
the S3 seems to be able to AUTH correctly more often when the revG is placed in the reader field, and then powered on. @doegox @gregor4005 : could you try this with your revGs?
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?
@DrWummi
26928 ms < +10 ms>:CODEC RX (4 bytes) [6000f57b] 26928 ms < +0 ms>:APP AUTH (2 bytes) [6000] 26929 ms < +1 ms>:CODEC TX (4 bytes) [86b424f5] 26930 ms < +1 ms>:CODEC RX (8 bytes) [3feca192169786f4] 26931 ms < +1 ms>:APP AUTHING (4 bytes) [c734c87e] 26931 ms < +0 ms>:APP AUTHED (4 bytes) [fdea01c0] 26932 ms < +1 ms>:CODEC TX (4 bytes) [fdea01c0] 26937 ms < +5 ms>:CODEC RX (4 bytes) [500057cd]
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. As I write this, I remember that the timeout for the last message from PICC to PCD is about 1ms. In the log, at 26930 ms the Chameleon receives the reader challenge but answers at 26932 ms, which is more than 1ms later. Maybe some readers have no such timeout implemented and thus everything works, and some readers have this strict timeout?
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.
@geo-rg
i briefly looked at my logs and found one:
00387 ms < +7 ms>:CODEC RX (4 bytes) [6000f57b]
00387 ms < +0 ms>:APP AUTH (2 bytes) [6000]
00388 ms < +1 ms>:CODEC TX (4 bytes) [58f56bd6]
00389 ms < +1 ms>:CODEC RX (8 bytes) [af0b1b2094e07af9]
00390 ms < +1 ms>:APP AUTHING (4 bytes) [00d3383b]
00390 ms < +0 ms>:APP AUTHED (4 bytes) [fbbde03f]
00390 ms < +0 ms>:CODEC TX (4 bytes) [fbbde03f]
00396 ms < +6 ms>:CODEC RX (4 bytes) [87c2f3ac]
00396 ms < +0 ms>:APP READ (18 bytes) [ffffffffffffff078000ffffffffffff8a29]
00398 ms < +2 ms>:CODEC TX (18 bytes) [cf4106a6cec906a9b92e029b7306d5b2cbc9]
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
for (uint8_t i=0; i<4*8; i++)
Crypto1LFSR(0);
LogEntry(LOG_INFO_APP_AUTHING, &Buffer[4], 4);
if (true) {
/* Reader is authenticated. Encrypt the precalculated card response
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 Crypto1Auth(&Buffer[0]); // 5550 cycles 204uS Crypto1LFSR(0); // 83 cycles 3uS Buffer[i] = CardResponse[i] ^ Crypto1Byte(); // 1396 cycles 51uS
@doegox @DrWummi
Hi folks, there are some news on this! There was a contribution, which I pushed to a new branch MFClassic_patch. The author has changed the whole Crypto1 computation and says it is now faster. Also, he found out that the parity calculation within nested authentications was wrong, which also could have caused our error here.
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.
@geo-rg @DrWummi yes there is some speed improvement \o/
FDT of a reply to an authentication request:
-
old MFC
- 2004 = 15 * 128 + 84 cycles = 148 μs
-
new MFC
- 4308 = 33 * 128 + 84 cycles = 318 μs
-
ChameleonMini (current master)
- 11092 = 86 * 128 + 84 cycles = 818 μs
-
ChameleonMini (branch MFClassic_patch)
- 6868 = 53 * 128 + 84 cycles = 506 μs
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 the S3 now correctly reads with NFCTaginfo, NXP Taginfo and MFCTool.
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.
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 I just merged the MFClassic_patch branch into master as I think it is really more stable than the previous version. Also, there was a pull request that fixed access conditions for MFC 4K card. Can you test whether your problems are gone now?
@DrWummi @doegox Maybe you can test also?
Thanks @all for your very useful help!
Hi @twiddern, did you have time to verify it? I also made a new issue about the USB interface, maybe the Problems are caused by this.
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. ChameleonMini in emulation mode, which clock use?
@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 thanks for the update. The problem you described (not enough distance to the reader) is known to us and might be not software-related. This problem occurs with some, but not all readers.
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 ;)