nfc-emulate-tag

Helle Jmax,

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

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

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

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.

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!

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.

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.

Hello,

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/

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.

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?

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.