search

bb33bb / libnfc

Automatically exported from code.google.com/p/libnfc
GNU Lesser General Public License v3.0
0 stars 1 forks source link

nfc-mfclassic doesn't work when used with mifare 4k emulated #98

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 

I have the following tools:
- Feig Elettronics M02 reader e software tool.
- Reader ACR122U102 - PN532,
- Nokia 6212 with Mifare 4k,
- MIFARE 4k (emulated)
- Another Mifare 1k.

If I use the Feig and proprietary software for windows, I get the following 
dump:

Nokia 6212 phone - sector 0:
6b a0 22 02 .......... serial manufactor ......... etc ...
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
FF FF FF FF FF FF FF 07 80 69 00 00 00 00 00 00
.....
MIFARE 4K - sector 0:
B0 57 34 11 .......... serial manufactor ......... etc. ..
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
FF FF FF FF FF FF FF 07 80 69 00 00 00 00 00 00
.....
MIFARE 1K - sector 0:
c4 e3 06 0c .......... serial manufactor ......... etc. .....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
FF FF FF FF FF FF FF 07 80 69 00 00 00 00 00 00

work well.

If  use nfc-mfclassic, micmd  or another tools with libnfc and PN532:

Nokia 6212 phone - sector 0:
FF FF FF FF FF FF 6b a0 22 02 FF FF FF FF FF FF
FF FF FF FF FF FF 6b a0 22 02 FF FF FF FF FF FF
FF FF FF FF FF FF 6b a0 22 02 FF FF FF FF FF FF
FF FF FF FF FF FF 6b a0 22 02 FF FF FF FF FF FF
..... for all areas ....   note UID ! 

MIFARE 4K emulated - sector 0:
FF FF FF FF FF FF B0 57 34 11 FF FF FF FF FF FF
FF FF FF FF FF FF B0 57 34 11 FF FF FF FF FF FF
FF FF FF FF FF FF B0 57 34 11 FF FF FF FF FF FF
FF FF FF FF FF FF B0 57 34 11 FF FF FF FF FF FF
..... for all areas .... note UID !

MIFARE 1K - sector 0:
c4 e3 06 0c .......... serial manufactor ......... etc. .....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
FF FF FF FF FF FF FF 07 80 69 00 00 00 00 00 00
.... ok.

libnfc correctly read the Mifare 1k,  but the 4k filled with FF and the UID. 
This seems very strange .... libnfc Bug?

Original issue reported on code.google.com by zamby....@gmail.com on 11 Aug 2010 at 8:39

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
I am using libnfc 1.3.4, pcsc 1.6.4, ccid svn

I attach the dump Nokia.

Original comment by zamby....@gmail.com on 11 Aug 2010 at 8:56

Attachments:

GoogleCodeExporter commented 9 years ago 
Hello,
Thanks for report.

Could you try with current libnfc's trunk version ?

On which OS do you use libnfc ?

Original comment by romu...@libnfc.org on 12 Aug 2010 at 12:48

GoogleCodeExporter commented 9 years ago 
Thanks for the reply.

I used micmd in Windows XP.
Even with Ubuntu 10.04, libnfc 1.3.4 have the same problem.
Now i'm using Slackware 13 with libusb 1.0.0 because 1.0.8 have problems with 
stability with the reader.

However, try libnfc svn version in Slackware 13:

bash-3.1# nfc-list
nfc-list use libnfc 1.3.9 (r520)
Connected to NFC reader: ACS ACR 38U-CCID 00 00 / ACR122U102 - PN532 v1.4 (0x07)
1 ISO14443A passive targets was found:
    ATQA (SENS_RES): 00  02
       UID (NFCID1): 6b a0 22 02
      SAK (SEL_RES): 38
          ATS (ATR): 78  80  84  02  00  73  c8  40  13  00  90  00

bash-3.1# nfc-mfclassic r a nokiadump2svn.out
Connected to NFC reader: ACS ACR 38U-CCID 00 00 / ACR122U102 - PN532 v1.4 (0x07)
Found MIFARE Classic 4K card with UID: 0222a06b                               
Reading out 256 blocks |........................................|               
Done, 256 of 256 blocks read.                                                   
Writing data to file: nokiadump2svn.out ... Done.                               

bash-3.1# hexdump -C -v nokiadump2svn.out                                       
00000000  ff ff ff ff ff ff 6b a0 22 02 00 00 00 00 00 00  
|ÿÿÿÿÿÿ̪§T......|  
00000010  ff ff ff ff ff ff 6b a0 22 02 00 00 00 00 00 00  
|ÿÿÿÿÿÿ̪§T......|  
00000020  ff ff ff ff ff ff 6b a0 22 02 00 00 00 00 00 00  
|ÿÿÿÿÿÿ̪§T......|  
00000030  ff ff ff ff ff ff 6b a0 22 02 00 00 00 00 00 00  
|ÿÿÿÿÿÿ̪§T......|  
00000040  ff ff ff ff ff ff 6b a0 22 02 00 00 00 00 00 00  
|ÿÿÿÿÿÿ̪§T......|  
......

I attach the libnfc config log.

Original comment by zamby....@gmail.com on 12 Aug 2010 at 11:33

Attachments:

GoogleCodeExporter commented 9 years ago 
I'll take it!

Looks like the trunk is broken…  I could not have a proper dump using 
nfc-mfclassic.

Bogus 4k card dump:
00000000  ff ff ff ff ff ff cc 87  16 47 00 00 00 00 00 00  |.........G......|
*
00001000

Original comment by romain.t...@gmail.com on 13 Aug 2010 at 7:33

GoogleCodeExporter commented 9 years ago 
This issue was updated by revision r526.

This should fix the problem: because the response was not the expected length, 
the actual card data was not copied to the buffer, so it was always the same 16 
uninitialized bytes that where returned for any block.

PR:     Issue 98
Submitted by:   zamby.ing
Pointy hat to:  me

Original comment by rtarti...@il4p.fr on 13 Aug 2010 at 7:53

GoogleCodeExporter commented 9 years ago 
zamby.ing, can you please confirm that r526 fix the issue?

Thanks!

Original comment by romain.t...@gmail.com on 13 Aug 2010 at 7:56

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Negative.

bash-3.1# nfc-list
nfc-list use libnfc 1.3.9 (r526)
Connected to NFC reader: ACS ACR 38U-CCID 00 00 / ACR122U102 - PN532 v1.4 (0x07)
1 ISO14443A passive targets was found:
    ATQA (SENS_RES): 00  02
       UID (NFCID1): 6b a0 22 02
      SAK (SEL_RES): 38
          ATS (ATR): 78  80  84  02  00  73  c8  40  13  00  90  00

-------------------
bash-3.1# nfc-mfclassic r a test2.out
Connected to NFC reader: ACS ACR 38U-CCID 00 00 / ACR122U102 - PN532 v1.4 (0x07)
Found MIFARE Classic 4K card with UID: 0222a06b 
Reading out 256 blocks |........................................|
Done, 256 of 256 blocks read.
Writing data to file: test2.out ... Done.
bash-3.1# hexdump -C -v test2.out 
00000000  ff ff ff ff ff ff 6b a0  22 02 00 00 00 00 00 00  
|ÿÿÿÿÿÿ̪§T......|
00000010  ff ff ff ff ff ff 6b a0  22 02 00 00 00 00 00 00  
|ÿÿÿÿÿÿ̪§T......|
00000020  ff ff ff ff ff ff 6b a0  22 02 00 00 00 00 00 00  
|ÿÿÿÿÿÿ̪§T......|
00000030  ff ff ff ff ff ff 6b a0  22 02 00 00 00 00 00 00  
|ÿÿÿÿÿÿ̪§T......|
00000040  ff ff ff ff ff ff 6b a0  22 02 00 00 00 00 00 00  
|ÿÿÿÿÿÿ̪§T......|
00000050  ff ff ff ff ff ff 6b a0  22 02 00 00 00 00 00 00  
|ÿÿÿÿÿÿ̪§T......|
....

Original comment by zamby....@gmail.com on 15 Aug 2010 at 8:41

GoogleCodeExporter commented 9 years ago 
Meh. In this case, I can't reproduce the issue.

Please ensure:
  - You are using the code from trunk (e.g. svn info);
  - You are not running old versions of the examples (the best to ensure you run examples with the appropriate library is to run them using the wrappers in the examples directory (i.e. ./examples/nfc-list and so on).

You may also try with a non-emulated target (just in case)

Can you please add --enable-debug=yes to your ./configure flags and retry?

Thanks!

Original comment by romain.t...@gmail.com on 15 Aug 2010 at 9:40

GoogleCodeExporter commented 9 years ago 
With debug mode, binary in examples directory.

bash-3.1# svn info
Path: .
URL: http://libnfc.googlecode.com/svn/trunk
Repository Root: http://libnfc.googlecode.com/svn
Repository UUID: 45cb0fa4-f8fe-11dd-984d-ab748d24aa7e
Revision: 526
Node Kind: directory
Schedule: normal
Last Changed Author: rtartiere@il4p.fr
Last Changed Rev: 526
Last Changed Date: 2010-08-13 21:53:13 +0200 (Fri, 13 Aug 2010)

Attach:
 ./nfc-mfclassic  r a test3.out &>nfc-mfclassic.debug

thanks.

Original comment by zamby....@gmail.com on 15 Aug 2010 at 11:21

Attachments:

GoogleCodeExporter commented 9 years ago 
Sorry, but I have only 2 nokia 6212, external NFC Chip, 1k tag. I do not own 
tags 4k card type.

Original comment by zamby....@gmail.com on 15 Aug 2010 at 11:26

GoogleCodeExporter commented 9 years ago 
Thanks for the debug trace!  If I compare yours and mine I see something that 
looks like extra bytes in your case (e.g. I get: "RX: d5  41  00  90  00" when 
you have "RX: d5  41  00  6e  00  90  00". 

I'll hopefully come back to you soon with a fix / questions.

Original comment by romain.t...@gmail.com on 15 Aug 2010 at 11:40

GoogleCodeExporter commented 9 years ago 
Thank you very much and good work.
I remind you that sometimes I even stability problems. I do not know if there 
are traces of this. I will try in coming days to use Ubuntu because worked 
better.

I did a test with key b.

bash-3.1# hexdump -C -v dumpnokia-keyb.out |head -n 12
00000000  ff ff ff ff ff ff 6b a0  22 02 00 00 00 00 00 00  
|ÿÿÿÿÿÿk ".......|
00000010  ff ff ff ff ff ff 6b a0  22 02 00 00 00 00 00 00  
|ÿÿÿÿÿÿk ".......|
00000020  ff ff ff ff ff ff 6b a0  22 02 00 00 00 00 00 00  
|ÿÿÿÿÿÿk ".......|
00000030  00 00 00 00 00 00 6b a0  22 02 ff ff ff ff ff ff  
|......k ".ÿÿÿÿÿÿ|
00000040  ff ff ff ff ff ff 6b a0  22 02 00 00 00 00 00 00  
|ÿÿÿÿÿÿk ".......|
00000050  ff ff ff ff ff ff 6b a0  22 02 00 00 00 00 00 00  
|ÿÿÿÿÿÿk ".......|
00000060  ff ff ff ff ff ff 6b a0  22 02 00 00 00 00 00 00  
|ÿÿÿÿÿÿk ".......|
00000070  00 00 00 00 00 00 6b a0  22 02 ff ff ff ff ff ff  
|......k ".ÿÿÿÿÿÿ|
00000080  ff ff ff ff ff ff 6b a0  22 02 00 00 00 00 00 00  
|ÿÿÿÿÿÿk ".......|
00000090  ff ff ff ff ff ff 6b a0  22 02 00 00 00 00 00 00  
|ÿÿÿÿÿÿk ".......|
000000a0  ff ff ff ff ff ff 6b a0  22 02 00 00 00 00 00 00  
|ÿÿÿÿÿÿk ".......|
000000b0  00 00 00 00 00 00 6b a0  22 02 ff ff ff ff ff ff  
|......k ".ÿÿÿÿÿÿ|

Original comment by zamby....@gmail.com on 15 Aug 2010 at 12:13

Attachments:

GoogleCodeExporter commented 9 years ago 
Hum, no more luck but that does not surprise me: if authentication with Key A 
gives strange results, I feel better knowing that authentication with Key B 
also does the same :-)

A quick way to see if some data is actually read is to check the debug output: 
in your case, no RX lines contains data, while you should have looooooong RX 
lines such as:

 TX: ff  00  00  00  05  d4  40  01  30  07  
 RX: d5  41  00  00  00  00  00  00  00  ff  07  80  69  ff  ff  ff  ff  ff  ff  90  00  
 TX: ff  00  00  00  05  d4  40  01  30  06  
 RX: d5  41  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  90  00  
 TX: ff  00  00  00  05  d4  40  01  30  05  
 RX: d5  41  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  90  00  

In your case it's more like:

 TX: ff  00  00  00  05  d4  40  01  30  07  
 RX: d5  41  00  6f  00  90  00  
 TX: ff  00  00  00  05  d4  40  01  30  06  
 RX: d5  41  00  6f  00  90  00  
 TX: ff  00  00  00  05  d4  40  01  30  05  
 RX: d5  41  00  6f  00  90  00  

... I guess there is some error checking missing in the examples ;-)

Let's dig into your frames:

0xd541 is a reply to the 0xd540 command.  The next byte 0x00 is supposed to be 
the error status (0 = no error) and the rest should be the data returned by the 
card, according to the PN532 documentation.  Here it starts to be tricky, for a 
reply to a Mifare Classic "read" command:
  - The libfreefare comments says "No result.  The MIFARE tag just ACKed." and I was pretty sure there was no additional data at all (since I wrote that comment);
  - I have 0x9000 (meh … however, at the libfreefare's level I don't see this extra data. I just see it at the libnfc level. But I can't recall how these bytes are stripped... I'll have to look at this I guess since it does not work as I think it does);
  - You have 0x6e009000 and 0x6f009000 (which is even more weird).

Let's make it even a bit more funny, (with no search, so maybe it is 100 % 
irrelevant, but it's so unlikely I can't think it is a coincidence):
  - 0x9000 correspond to the status-byes in ISO/IEC 7816-4 for "Normal processing";
  - 0x6e00 is a "Class not supported" error in the same document, same table;
  - 0x6f00 is a "No precise diagnosis" error always in the same status-bytes table.

… Looks like an error frame (0 bytes of data followed by the error status 
"0x6x00") is transmitted "as-it" successfully (2 bytes of data "0x6x00" 
followed by the success status-code "0x9000")...

You said you have a passive 1k target? Can you please try to dump it and attach 
a trace like you did previously?  I would like to be sure about the extra bytes 
being send by the telephone emulating a NFC target (and not added by the NFC 
initiator) and that everything is fine when you use passive targets.

It might also be interesting to give the libfreefare's examples a try: they 
might fail "earlier" with more relevant error messages (not that my 
brain-embedded hexadecimal ADPU decoder is bad, but it might miss things).

And finally, have you ever got the examples working with the telephone 
emulating a target ?

Thanks!

Original comment by romain.t...@gmail.com on 15 Aug 2010 at 1:05

GoogleCodeExporter commented 9 years ago 
For the moment i attach the debug 1k tags.

Original comment by zamby....@gmail.com on 15 Aug 2010 at 7:42

Attachments:

GoogleCodeExporter commented 9 years ago 
Hey!

Looks like the uploaded debug trace is not the good file, but BTW, the dump 
looks-like much more what we expect!

So, I suspect a weirdness in the communication with the telephone (and not the 
device)…  Do you have some "advanced documentation" that way have useful 
information about "how emulation works" ?  I don't really know what you can 
look for exactly, but maybe you can "switch NFC communication modes" on the 
telephone, or maybe it is required to put the PN532 in a particular 
configuration… No real idea, mobile-phones or somewhat cursed devices as far 
as I can tell (I don't own one).

Thanks, and good luck!

Original comment by romain.t...@gmail.com on 15 Aug 2010 at 7:57

GoogleCodeExporter commented 9 years ago 
ops.

Original comment by zamby....@gmail.com on 15 Aug 2010 at 8:18

Attachments:

GoogleCodeExporter commented 9 years ago 
Thanks, I confirm that everything is fine and as-expected with your passive 
target.

Original comment by romain.t...@gmail.com on 15 Aug 2010 at 8:25

GoogleCodeExporter commented 9 years ago 
Hello zamby.ing,

Could you explains actions you do with your phone before putting it on device 
and read it ?
I have a 6212 Classic and I want to replay your case.

Original comment by romu...@libnfc.org on 16 Aug 2010 at 8:20

GoogleCodeExporter commented 9 years ago 
Reset owner: I can't reproduce the issue.

Original comment by romain.t...@gmail.com on 16 Aug 2010 at 7:01

GoogleCodeExporter commented 9 years ago 
1) I am sure that the phone is turned on. ;-)
   (Access to the secure element is to set free)
2) I write on the console  > nfc-mfclassic  r a  ....
3) I position my hand and phone near the reader (1 cm).
4) Press ENTER on the keyboard.
5) I stand while reading.
6) After the reading, take away the phone.
7) I read the result.

I attach a screenshot of the Feig reader and its software manager. The reading 
is correct.

Original comment by zamby....@gmail.com on 16 Aug 2010 at 7:11

Attachments:

GoogleCodeExporter commented 9 years ago 
Hey

I see a Protocol and ADPU tabs on the bottom on the screen.  I guess that the 
output can be relevant to us ;-)  Can you attach them?

Thanks

Original comment by romain.t...@gmail.com on 16 Aug 2010 at 7:19

GoogleCodeExporter commented 9 years ago 
Of course, I ask my friend to do it tomorrow.
But, what you used to reproduce the error? you have an NFC phone? working?

Original comment by zamby....@gmail.com on 16 Aug 2010 at 7:26

GoogleCodeExporter commented 9 years ago 
Got it!
Your note: "Access to the secure element is to set free" fix my setup ^^

Bug is now reproduced here.

Original comment by romu...@libnfc.org on 16 Aug 2010 at 7:51

GoogleCodeExporter commented 9 years ago 
Well, Romuald does have one, and we work together (while we are ~500 kilometers 
from each other) so the more data we have, the best it is for us to think 
together :-)

And since I suspect this is related to some protocol detection (let's say that 
the PN532 detect that the telephone is ISO-14443-4 compliant and start sending 
frames in the wrong format… somthing like that), having a trace of the 
exchanges of a working connection would help us to determine how we can detect 
and handle this the most efficiently.

Original comment by romain.t...@gmail.com on 16 Aug 2010 at 7:58

GoogleCodeExporter commented 9 years ago

Original comment by romu...@libnfc.org on 17 Aug 2010 at 10:22

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Hi,
sorry, I would ask questions to understand.

Mifare emulated problem is in the code of the nfc-mfclassic or libnfc?

LibFreeFare contains some tools, I'm not good in C language.
Exist an easy way to read the contents of the tag with libfreefare?.

I would like to format Nokia 6212 using the tool Mifare-Classic-format? could 
be risky?

If you need the APDU of Feige and documentations, send them to you in a few 
days. I don't have the reader.

I have a very expensive SDK, with many tags, but not 4k.
I would like to test with Mifare 4k (card). I can not find in internet. The 
kits are very expensive. I need only 3 or 4 tags. You have 4k tags? Can you 
send me some tags? I'll pay you. Or you know a company where I can buy 
individually?
I have other types of tags that do not use. DesFire, Icode, T.I. ISO 15693, are 
you interested?

Thanks for your help.

Andrea.

Original comment by zamby....@gmail.com on 18 Aug 2010 at 8:21

GoogleCodeExporter commented 9 years ago 
Hi,
This bug is related to both nfc-mfclassic and libnfc: nfc-mfclassic have to 
fail earlier on error (done in trunk) and libnfc use a chip function that 
choose sending protocol "automagically"... but the magic doesn't work with 
emulated mifare that presents itself as ISO14443-4 compliant.
If you don't understand what I'm talking about, consider that a simple libnfc 
bug.

libfreefare use same mecanism to "talk" with mifare, so currently you will have 
the same result with libfreefare: a big failure :)

About tags, at http://smartcardworld.com/ you can buy cards per unit nut the 
best if you want one or two cards is to find free samples: some device 
resellers offer samples or maybe NXP could send few tags, I don't know about it.
AFAIK, Icode and T.I. ISO 15693 aren't compliant with major NFC devices, that 
use other frequencies or modulations than ISO14443.

Original comment by romu...@libnfc.org on 19 Aug 2010 at 9:19

GoogleCodeExporter commented 9 years ago 
This is now fixed in trunk (r555).
BTW, I can't dump my Nokia's emulated Mifare Classic 4k because I don't know 
the authentication key.

Original comment by romu...@libnfc.org on 19 Aug 2010 at 12:28

GoogleCodeExporter commented 9 years ago 
I understand perfectly.
Thank you for your responses. Good luck and see you soon. Bye.

Original comment by zamby....@gmail.com on 20 Aug 2010 at 8:02