Open GoogleCodeExporter opened 9 years ago
[deleted comment]
Hello,
okay, here are further details. Despite my first suspicion the problem may
arise one step earlier, that is to say when the file is created. I compiled
libnfc with debug to get the transacted APDUs.
Here the sequence with firmware 2.10:
debug libnfc.driver.acr122_pcsc TX: ff 00 00 00 10 d4 40 01 90 cd 00 00 07 01
03 00 00 20 00 00 00
debug libnfc.driver.acr122_pcsc RX: d5 41 00 e6 72 1c 6e 84 1e cc da 91 00 90
00
Here the corresponding line with Firmware 2.13, please note the different
content in the answer (which might be okay):
debug libnfc.driver.acr122_pcsc TX: ff 00 00 00 10 d4 40 01 90 cd 00 00 07 01
03 00 00 20 00 00 00
debug libnfc.driver.acr122_pcsc RX: d5 41 00 68 4d f0 f0 bc d1 0b c1 91 00 90
00
libfreefare tells me by returning a value of 0 in both cases that the file has
been created successfully - that could be indeed verified by using a different
reader and software, the file has actually been created logically. But after
completing the file creation the reader seems to stop responding, because no
further commands are sent to the reader by libfreefare, although I executed the
succeeding command mifare_desfire_create_std_data_file(), which then returns
with returncode -1.
The question is: When is the debug of libnfc generated? I still believe that in
the end the reader stops responding when it receives the following sequence
(recording originates from firmware 2.10):
debug libnfc.driver.acr122_pcsc TX: ff 00 00 00 3f d4 40 01 90 3d 00 00 36 01
00 00 00 20 00 00 6e 8f 77 6a b9 aa 64 5d 04 19 1b 9c 34 8e a5 d9 4a 8a 3b 42
1e 21 dd 41 c6 6f 61 88 2b 17 5b d9 b3 83 9c c6 b4 d9 e1 23 3e 22 1c f6 df 12
d1 00
I will try to get more debug out of libnfc to track down this issue.
Thank you and best regards,
Eike
Original comment by chevi...@gmail.com
on 8 Nov 2013 at 9:33
Hi
If you want to have more traces at usb level you can also try sniff-pn532:
https://code.google.com/p/nfc-tools/source/browse/trunk/dev-tools/sniff-pn53x.sh
It will tap directly into the usb stack to recover the same frames but you can
also get more insight on the usb protocol itself.
it has also helpful basic parsing of the pn532 commands so it's a bit easier to
follow.
Note that sniffed frames are truncated so don't be surprised if it looks like
you're missing bytes.
Thanks for tracking down that problem! as you've both fw in your hands you're
unfortunately almost on your own to dig into that issue.
Phil
Original comment by yob...@gmail.com
on 8 Nov 2013 at 10:03
Hello,
I made some traces using USBlyzer under Windows. Attached you'll find the
results in csv-format. At the moment I'm not able to see any difference in the
answer of both firmware versions to the file write command.
Bye, Eike
Original comment by chevi...@gmail.com
on 11 Nov 2013 at 8:37
Attachments:
Hello,
attached the traced data in a more readable form (Excel format). Please note
the differences in the data sent (!) by libnfc listed in the sequence numbers
414 and above in firmware 2.10 (respective sequence numbers 406 and above in
firmware 2.13). For what reason libnfc sends telegrams of different sizes (25
bytes for 2.10 versus 18 bytes for 2.13)? Is this a problem with the preceding
answer? I have to work myself into DESFire and the corresponding APDUs in order
to analyse the data traffic between host and reader. Any help would be
appreciated.
Bye, Eike
Original comment by chevi...@gmail.com
on 11 Nov 2013 at 9:05
Hello,
here's the promised Excel file...
Bye, Eike
Original comment by chevi...@gmail.com
on 11 Nov 2013 at 9:06
Attachments:
Hello,
in the end, I got it: Following the sequence 04 00 00 FF in the outgoing
package stands some kind of sequence number. Considering this, the firmware
2.13 will answer to this particular DESFure command 0x3F (create file) in case
of AES encryption with a wrong sequence number. The sequence number is always
decremented by 1! For example:
Beginning of outgoing command:
6F 44 00 00 00 00 8B 04 00 00 FF 00 00 00 3F D4
^^
Beginning of incoming answer:
80 07 00 00 00 00 8A
^^
I was able to verify this issue by comparing the messages to the data transfer
of firmware 2.10, where the sequence numbers of request and answer are always
identical.
So in my opinion the firmware 2.13 is definitly broken in this aspect.
Furthermore, this issue resembles a problem mentioned in another forum:
http://musclecard.996296.n3.nabble.com/ACR122U-response-frames-contain-wrong-seq
uence-numbers-td5002.html
In order to provide a patch for libnfc, someone has to check the firmware
version of the connected ACR122U reader and, after sending particular commands,
accept answers with a decremented sequence number. I'll take a look into the
corresponding source files in the next two weeks. If anyone could provide a
patch for libnfc quicker, it would be very apprectiated! Thanks in advance!
To ACS: Please provide a firmware downgrade utility! I was happy with release
2.10!
Bye, Eike
Original comment by chevi...@gmail.com
on 11 Nov 2013 at 9:33
Hi Eike,
Thank you for your findings. We are looking into this issue and contact you
regarding the resolution.
Regards,
ACS
Original comment by Advanced...@gmail.com
on 11 Nov 2013 at 10:02
Hello,
one last addition: IMHO this issue can't be fixed in libnfc (just checked it),
because the sequence number is already processed one stage lower, that is to
say on USB driver level. The decreased sequence number seems to be responded in
all cases when the APDU is larger than 54 bytes (according to Mr. Eugene
Crosser, see the link in my last post to the corresponding thread). This is
neither a failure in libfreefare nor in libnfc, but I think this information
should be kept for providing an optional patch for libnfc warning of issues in
combination with f/w release 2.13.
Kind regards,
Eike
Original comment by chevi...@gmail.com
on 12 Nov 2013 at 9:22
Thanks for this thorough analysis!
Could you provide such warning patch?
I'll be happy to apply it to the repository.
Original comment by yob...@gmail.com
on 12 Nov 2013 at 9:47
Original issue reported on code.google.com by
chevi...@gmail.com
on 7 Nov 2013 at 1:30