Comments (10)
[deleted comment]
from libfreefare.
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 [email protected]
on 8 Nov 2013 at 9:33
from libfreefare.
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 [email protected]
on 8 Nov 2013 at 10:03
from libfreefare.
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 [email protected]
on 11 Nov 2013 at 8:37
Attachments:
from libfreefare.
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 [email protected]
on 11 Nov 2013 at 9:05
from libfreefare.
Hello,
here's the promised Excel file...
Bye, Eike
Original comment by [email protected]
on 11 Nov 2013 at 9:06
Attachments:
from libfreefare.
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 [email protected]
on 11 Nov 2013 at 9:33
from libfreefare.
Hi Eike,
Thank you for your findings. We are looking into this issue and contact you
regarding the resolution.
Regards,
ACS
Original comment by [email protected]
on 11 Nov 2013 at 10:02
from libfreefare.
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 [email protected]
on 12 Nov 2013 at 9:22
from libfreefare.
Thanks for this thorough analysis!
Could you provide such warning patch?
I'll be happy to apply it to the repository.
Original comment by [email protected]
on 12 Nov 2013 at 9:47
- Added labels: Type-Other, OpSys-All, Usability
- Removed labels: Type-Defect
from libfreefare.
Related Issues (20)
- Get some flexibility in the tag type detection
- Support for SmartMX based mifare card emulation HOT 1
- Dual interface cards with MF Classic emulation authentication problem HOT 6
- mifare_ultralightc_authenticate(): Set errno when authentication fails. HOT 3
- Improve memory allocation for MifareDESFireKeys
- Generalized API and PC/SC support HOT 4
- Some functions in mifare_classic.c apparently don't check input data HOT 1
- mifare_application_free() doesn't perform a NULL pointer check. HOT 5
- freefare_get_tag_uid() doesn't check if malloc() fails HOT 1
- Wrong types (probably a typo) in two desfire functions HOT 1
- Cross compilation issue HOT 2
- mifare_desfire_read_data() reads behind end of buffer HOT 3
- How can i format mifare-classic card with dynamic key and how to change the default access bit. HOT 1
- ./configure --prefix=/usr Fails on Raspberry Pi due to missing pkg-config HOT 14
- mifare-classic-write-ndef fails with Symbol not found: _htole32 on OS X 10.9 HOT 1
- aes authentication problem?
- mifare_desfire.c: buffer overflow at read_data
- autoreconf -vis error while installing on RasPi
- mifare_desfire_debit/credit not working
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from libfreefare.