Topic: nfc-emulate-tag

I tried running this built-in example as is in the latest stable release and it doesn't work.

I'm using a PN533.

When I run it, I can get the other initiator to see the 'tag' (the PN533) and they go through the ATQA and the everything else just fine. The initiator then sends a MifareAuthA command, but when replying I get a 'Invalid DEP State' error and the command never gets sent back.

Upon further debugging I've found that the library incorrectly tries to do TX/RX using TGSetData and TGGetData instead of TGResponseToInitiator and TGGetInitiatorCommand (these are commands to PN533). TGSetData and TGGetData are only allowed in DEP mode -- which this is not.

I made the change and at least the command gets sent correctly however I get a response of 50 00 from the other Initiator -- which I can't find anywhere in any NFC/ISO14443 or any other spec.


Has anyone ever successfully used the nfc-emulate-tag?! It seems the code that is checked in is buggy  -- you at least have to change the TX/RX commands.

Thanks.

Re: nfc-emulate-tag

Helle Jmax,

Jmax wrote:

Upon further debugging I've found that the library incorrectly tries to do TX/RX using TGSetData and TGGetData instead of TGResponseToInitiator and TGGetInitiatorCommand (these are commands to PN533).

You made a good job, you find the first problem source.

Jmax wrote:

TGSetData and TGGetData are only allowed in DEP mode -- which this is not.

In fact, that's not only for DEP while using it on a PN532:

NXP wrote:

This command is used in case of the PN532 configured as target for Data Exchange Protocol (DEP) or for ISO/IEC14443-4 protocol when PN532 is activated in ISO/IEC14443-4 PICC emulated

BTW, you can toogle the usage of TgSetData/TgResponseToInitiator with NDO_EASY_FRAMING option.

Jmax wrote:

I made the change and at least the command gets sent correctly however I get a response of 50 00 from the other Initiator -- which I can't find anywhere in any NFC/ISO14443 or any other spec.

I've commited a little fix to disable NDO_EASY_FRAMING when trying to emulate a non-ISO14443-4 target.
After this commit, it continue to fail due to CRC error but that's normal: Mifare Classic CRC is not implemented in the example. AFAIK, to emulate a Mifare Classic, you have to implement Crypto1 and some commands.

Jmax wrote:

Has anyone ever successfully used the nfc-emulate-tag?! It seems the code that is checked in is buggy  -- you at least have to change the TX/RX commands.

Yes, I do but I was emulating a ISO14443-4 device on a PN532 device...
nfc-emulate-tag doesn't provide a ready-to-use emulation, this is a simple C code to show how to emulate using libnfc's API but if you want to improve it and provide a ready-to-use Mifare Classic emulation, you are more than welcome!

Could you test the nfc-emulate-tag from trunk ? it should ended by something like that (in debug mode):

 TX: 32  00  00  ff  02  fe  d4  88  a4  00  
 RX: 00  00  ff  00  ff  00  00  00  ff  03  fd  d5  89  02  a0  00  
nfc_target_receive_bytes: CRC Error
nfc_target_emulate_tag: CRC Error

Note: tested with Nokia 6212 Classic as initiator.

I hope it helps,
Many thanks for this excellent bug report!

Romuald Conty

Re: nfc-emulate-tag

I'm also getting CRC Error and couldn't figure out why.

I thought PN532 would generate the correct CRC. I'm emulating a MiFare Ultralight, should I just disable CRC and generate my own CRC?

Re: nfc-emulate-tag

Jmax wrote:

I'm emulating a MiFare Ultralight, should I just disable CRC and generate my own CRC?

First, you have to know that you can't emulate an ultralight due to UID: its 7 bytes long when PN53x emulation only allow 4 bytes long with fixed first byte (0x08).
Before the last revision (r857), libnfc silently truncated UID and don't care about the first byte. Now, an error is raised if you want to emulated an target with an "unemulable" (with PN53x) UID. This way should be less confusing.

Jmax wrote:

I'm also getting CRC Error and couldn't figure out why.

I talked to yobibe and he did some investigations (I'm only reporting here what we talked about, I didn't experiment so far myself):
- some Mifare commands was missing, but that's now fixed (you should look at r855 and r856 commit diffs)
- it seems that PN53x don't handle correctly some low-level commands in ISO14443-3 emulation
- finally, multiple tries doesn't give the same result, that seems to be related to timing issue

Note: to be able to implement emulation, its recommend to have some equipment like proxmark3

I hope it helps.

Romuald Conty

Re: nfc-emulate-tag

My initiator doesn't care about the UID. It accepts the 4 byte UID because after autocoll is finished it gives me a 30 02 (read page 2).

However after I give it the 16 bytes of data it gives me a 50 00 (i.e. SLEEP). But this doesn't happen all the time, every once in a while it will give me a 30 04 (i.e. read page 4) and when I give it that data it returns 50 00.

If everything goes correctly the sequence should be:
Initiator -> 30 02
Target (me) -> 16 bytes of data
Initiator -> 30 04
Target (me) -> 16 bytes of data
Initiator -> 30 06
Target (me) -> 16 bytes of data
Initiator -> 30 08
Target (me) -> 16 bytes of data
Initiator -> 50 00

The initiator code is good and works. It is a Nexus S and I can get it to read the *exact* same data from an actual Ultralight. They are using the NXP provided HAL for PN544 and the code is available in Android tree -- and I looked through it, everything is going as part of the sequence.


I can't understand why most times it stops after 30 02, and other times I get to 30 04 but it stops after that.

The only thing I can think of is that the CRC or something else is set incorrectly.

Is there a way to put another PN53x into sniff mode, or any other way to see what *exactly* is being sent out of the PN53x and what the initiator is sending it?

I even tried disabling CRC by setting NDO_HANDLE_CRC to false and generating my own CRC but the result was the same.

I know this isn't a proximity or quality issue because the antenna are right next to each other and both the PN53x and the Nexus S can read a regular Ultralight just fine.

Any ideas?!

Re: nfc-emulate-tag

Hello,

Jmax wrote:

Is there a way to put another PN53x into sniff mode, or any other way to see what *exactly* is being sent out of the PN53x and what the initiator is sending it?

To be able to sniff on-air, you couldn't use a PN53x. There is an open source RFID sniffer that can sniff @13,56MHz:
Proxmark3: http://proxmark3.com/

Romuald Conty

Re: nfc-emulate-tag

Jmax wrote:

My initiator doesn't care about the UID. It accepts the 4 byte UID because after autocoll is finished it gives me a 30 02 (read page 2).

However after I give it the 16 bytes of data it gives me a 50 00 (i.e. SLEEP). But this doesn't happen all the time, every once in a while it will give me a 30 04 (i.e. read page 4) and when I give it that data it returns 50 00.

....

I know this isn't a proximity or quality issue because the antenna are right next to each other and both the PN53x and the Nexus S can read a regular Ultralight just fine.

Any ideas?!

Having the same problem. Suggestions? Jmax, did you eventually get this working?

Re: nfc-emulate-tag

I have similar issues when I tried to run card emulation on a PN532, both with my own code (coded from scratch for an embedded MCU) and this libnfc example (nfc-emulate-tag). 

This is my setup:

A PN532 was connected to a PC running libnfc example nfc-emulate-tag.exe
A second PN532 was connected to MCU in the role of initiator.  The following is executed in the MCU:
     InListPassiveTarget -> to gather target information (SENS_REQ, SEL_RES, Target number...)
     InDataExchange -> Pass it the Target #, FFFFFFFFFFFF as Key A, 0x60 for authenticate w/ keyA, block 0x04

This is the result using nfc-emulate-tag of libnfc v1.5.1:
------------------------------------------------------------

nfc-emulate-tag:     In: 60 04  ->
                              Out: 12 34  ->  'Random' nonce sent by libnfc
                              nfc_target_receive_bytes : Parity Error
                              nfc_target_emulate_tag: Parity Error

InDataExchange returns status = 0x14, which is a MIFARE authentication error

CONCLUSION: This makes sense since the nonce shall be 4 bytes according to sources online. (for example: http://www.proxmark.org/documents/mifare_weakness.pdf

Therefore, I modified the code to send a 4 byte nonce:  I modified  nfc-emulate-tag.c around line 101:
     WAS:
          case 0x60: // Mifare authA
          case 0x61: // Mifare authB
        // Let's give back a very random nonce...
        *pszOutput = 2;
        pbtOutput[0] = 0x12;
        pbtOutput[1] = 0x34;

     IS:     
      case 0x60: // Mifare authA
      case 0x61: // Mifare authB
        // Let's give back a very random nonce...
        *pszOutput = 4;
        pbtOutput[0] = 0x12;
        pbtOutput[1] = 0x34;
        pbtOutput[2] = 0x56;
    pbtOutput[3] = 0x78;



This is the result using nfc-emulate-tag of libnfc v1.5.1, bit modified to send a 4 byte nonce:
---------------------------------------------------------------------------------------------------

nfc-emulate-tag:     In: 60 04  ->
                              Out: 12  34  56  78 -> new 4 byte nonce
                              In:
                              nfc_target_receive_bytes: Target Release
                              nfc_target_emulate_tag: Target Released

What I am expecting is the initiator to respond with 8 bytes, the first 4 are the response to the challenge (the original 4 byte nonce encrypted with the CRYPTO1 and KeyA). The last 4 bytes are a second nonce from the initiator
 
InDataExchange returns status = 0x14, which is a MIFARE authentication error, and nfc-emulate-tag.exe simply hangs waiting for a response. When I remove the PN532 target from the initiator field, I then see the 'Target Release' message from nfc-emulate-tag.exe.


Does anyone know why there is no response to the Nonce from the initiator?

Any help would be appreciated. I'm not sure the Proxmark would help me in this situation since I have seen many snoop traces from a Proxmark Online and they all show more or less the same 4 byte nonce with an 8 byte response. 

Any help would be greatly appreciated.

Re: nfc-emulate-tag

Hi Papyrus

Mifare challenge-response is without CRC and without parity check after the 60xx auth command.
nfc-emulate-tag.c was replying two bytes because CRC is still appended so in total 4 bytes are really sent to the initiator.
The initiator replies with the continuation of the authentication, still without crc & parity and the PN532 fails with a parity error because it expects the initiator to still use parity.
So everything happens as expected :-)
If you want to do auth manually you have to disable CRC and parity.

Now you tried to send a challenge of 4 bytes, + 2 of CRC = 6 bytes and there the initiator is not happy of the card response and you get a target release.
So everything happens again as expected

I hope this helps understanding what happened with your tests.
Phil

Re: nfc-emulate-tag

Hi Phil

Thanks very much, this makes a lot of sense.  Now I guess I know what nfc-emulate-tag is doing with all those PN532 register reads/writes.  From most of the commands it seems that the default register settings are simply being re-written in case the PN532 was in some weird state previously.  That said there are some that do deviate from the default settings so that could be the settings being changed. 

We will try to set the registers accordingly to disable the CRC and parity during the MIFARE authentication and see where that gets us.

About the challenge though (and assuming the parity thing fixes the initial problem), I was wondering how you would suggest implementing the CRYPTO1. The PN532 only does it in reader/writer mode, not emulation mode (unless you've got a SAM connected).  I see that I would have to implement it in C starting from the the various online and academic papers that have reverse engineered it symbolically.  Thing is that I'm an electrical engineer, not a software guy per se.  I could eventually implement it in C, but eventually being the key thing, think anyone has an example in C for me to start from?

11 (edited by anhpham 2013-01-15 09:06:17)

Re: nfc-emulate-tag

msobell wrote:
Jmax wrote:

My initiator doesn't care about the UID. It accepts the 4 byte UID because after autocoll is finished it gives me a 30 02 (read page 2).

However after I give it the 16 bytes of data it gives me a 50 00 (i.e. SLEEP). But this doesn't happen all the time, every once in a while it will give me a 30 04 (i.e. read page 4) and when I give it that data it returns 50 00.

....

I know this isn't a proximity or quality issue because the antenna are right next to each other and both the PN53x and the Nexus S can read a regular Ultralight just fine.

Any ideas?!

Having the same problem. Suggestions? Jmax, did you eventually get this working?

Hello,
I am trying to emulate a mifare ultralight card and have got the same problem. After getting 30 02 command from the initiator, I respond with 16 bytes of data and 2 bytes CRC. However, I have never got a positive response from the initiator. Sometimes I got CRC error, or  50 00 though I did implement a function to calculate CRC. I am using ACR122 device.

Could any one give me a suggestion to solve this problem? Jmax, msobell, did you get this working?

Thank you.
anhpham

Re: nfc-emulate-tag

I've been busy with this too and still don't get how to solve the problem. I use a PN512 instead and I got the Mifare Classic emulation working but then comes the next step of transferring data. I receive a 0x60 and a 0x01 directly after setting up the connection. So I know that it wants to authenticate itself.

Anybody fixed this meanwhile? I know I'm kinda late. tongue