hf mf sim after r845

[holiman]

With r844 and later, I am unable to do 'hf mf sim' and related commands (snoop) on one type of readers found in 'real-world'. The yellow led blinks, but nothing happens and even with 'hf mf dbg 4', there is nothing sent back from the device.

[pwpiwi]

Interim status:

I have checked if there is a timing issue with the PM3 eventually not being able to pick up a reader command which comes very fast after the last simulated tag response. There isn't. It just takes approx 180 (13,56MHz) clock ticks until the PM3 starts polling the FPGA again. This is fast enough even for iceman0001's Skylander base which sends the ar/nr faster than ISO14443-3 would allow. I have a reader which needs quite some time to send ar/nr (approx 20000). Nevertheless, the PM3 doesn't trace a ar/nr as response to nt from time to time when simulating. Sniffing on the other hand is OK.

So if the PM3 wouldn't miss the next reader's command, but we don't see any, then the reader might not have been able to pick up the previous tag's response and indeed didn't send a new command. I currently have no clue why this seems to happen only with the AUTH sequence nt - ar/nr.

To further narrow down the issue and exclude MF_MINFIELDV: @iceman1001: Can you please clarify what you did with the dbprintf() (holiman's question). Your "Field dropped below limit" and "value" printouts are contradicting.

[iceman1001]

Indeed contradicting. I dont remember what I did anymore. but it was in the line that I thought the MIN_FIELD use be lowered, from 4000 to a smaller ie 2000,1000,500. But when I dbprinted the actual value vhf it was larger the 4000 So my text "below" is wrong" It should have said "above", which I didn't realise at the moment.

[iceman1001]

We can't assume that it is only the AUTH sequence nt - ar/nt that it happens to. Since we don't get the auth to work, we can't test the other commands following it. But it seems not to be influencing the commands given before the AUTH sequence.

[pwpiwi]

In my case AUTH works OK in approx 50% of all cases when simulating. The following encrypted reads are OK and the preceding anticollission is OK.

[buggii]

Maybe using 2 pm3s to study the simulation?

-----Original Message----- From: pwpiwi notifications@github.com To: Proxmark/proxmark3 proxmark3@noreply.github.com Cc: buggii buggii@hotmail.com Sent: Gio, 29 Gen 2015 12:08 Subject: Re: [proxmark3] hf mf sim after r845 (#11)

In my case AUTH works OK in approx 50% of all cases when simulating. The following encrypted reads are OK and the preceding anticollission is OK.

---

Reply to this email directly or view it on GitHub: https://github.com/Proxmark/proxmark3/issues/11#issuecomment-72007501

[pwpiwi]

I cannot afford two PM3s :smiley: And I prefer to have at least one component which I can assume to work correctly. I am trying to get hold of a DSO.

I have one suspicion. I remember having seen in one of Enio's or gaucho's DSO screenshots that the phase of the subcarrier modulation differs between real and simulated tag. If this is really the case it may confuse some readers. Still don't know though why AUTH would be so special.

[holiman]

Regarding why AUTH would be special; my original report didn't particularly point out AUTH, it just didn't work.

Regarding DSO, I recently got a Saleae Logic Pro 8 (https://www.saleae.com/), and found it very useful during my recent FPGA-changes to iclass. It was very simple to connect the device to testpoints, record samples during one second and then observe the communications. A lot easier than doing the same thing a while back with my Rigol DS1074 scope.

Here's an iclass SOF (the reader signal are the small notches):

Here it is again, with a bit more zoom:

I could try to do something similar here, but it'd be good to narrow down a specific scenario, so I can correlate a particular error and the corresponding capture. Possibly by lighting a LED from ARM if the error occurs, and then we can measure also over the LED and use it to find the relevant parts of the signal. Or, @pwpiwi, if you can elaborate a bit more about the phase error, I can try to take some 'images' of it.

And one last thing, here's a feature to test the reader field.

#git diff
diff --git a/armsrc/appmain.c b/armsrc/appmain.c
index 88ade85..1370519 100644
--- a/armsrc/appmain.c
+++ b/armsrc/appmain.c
@@ -620,6 +620,18 @@ void ListenReaderField(int limit)
                }
        }
 }
+void MeasureReaderField()
+{
+       int vHf = 0;
+       int oldValue =0 ;
+       while(!BUTTON_PRESS())
+       {
+               WDT_HIT();
+               vHf = (33000 * AvgAdc(ADC_CHAN_HF)) >> 10;
+               if(abs(oldValue - vHf) > 10) Dbprintf("%d mV", vHf);
+               oldValue = vHf;
+       }
+}

 void UsbPacketReceived(uint8_t *packet, int len)
 {
@@ -903,7 +915,8 @@ void UsbPacketReceived(uint8_t *packet, int len)
                        break;

                case CMD_LISTEN_READER_FIELD:
-                       ListenReaderField(c->arg[0]);
+//                     ListenReaderField(c->arg[0]);
+                       MeasureReaderField();
                        break;

                case CMD_FPGA_MAJOR_MODE_OFF:           // ## FPGA Control

You can then issue 'hw measure' (I think it was) and see what values are returned from various readers, on off and on-state. Then we could compare it a bit. For example, I noticed that when I placed the antenna flat against my ACR122u without any field, the reader field was just below 4000 mV (which sounds correct). Just holding the antenna in the air gave me ~9000 mV.

[pwpiwi]

What I would like to check: compare a real tag and hf 14a sim "on the air": the time between the last reader modulation of a WUPA and the first tag modulation, and how the start of the tag's answer (let's say 2 us) looks like.

[holiman]

I've now made four recordings. They are about 500 Mb each - do you have any ssh where I can upload it ? Shoot me an email. Otherwise I'll try to find something. The recordings can be opened with the saleae software and analyzed in depth. I can also post some images here, but not right now, I'll have to correlate the data a bit first and pick out the interesting pieces.

Files:

1-25 MHz, 50 M Samples [12]_acs_acr122u_reading_allblocks_mifare_tag.logicdata
2-25 MHz, 50 M Samples [12]_acs_acr122u_trying_to_read_allblocks_from_pm3_sim14a_same_uid.logicdata
3-25 MHz, 50 M Samples [12]_acs_acr122u_trying_to_read_allblocks_from_pm3_sim_hfmf_same_uid_but_no_tag_response.logicdata
4-25 MHz, 50 M Samples [12]_acs_acr122u_trying_to_read_allblocks_from_pm3_sim_hfmf_same_uid_minfieldvalue2000_authfail.logicdata

• 1 is a reading from a std reader, reading all blocks from a standard mifare classic tag. UID is 92C0456B.eml, all keys are FFFFFFFFFFFF
• 2 is a reading from the same reader, trying to do the same thing again against a 'hf 14a sim 92C0456B'.
• 3 is a reading when loading the 92C0456B-tag dump into pm3 emulator mem, then doing 'hf mf sim'. The tag never responds (does not see the reader commands)
• 4 is the same setup as 3, except I changed MF_MINFIELDV to 2000. The reader and tag now communicates, but for some reason auth fails. Trace is below.

PM3 trace after [4]:

proxmark3> hf list 14a
Recorded Activity (TraceLen = 1784 bytes)          

Start = Start of Start Bit, End = End of last modulation. Src = Source of Transfer          
iso14443a - All times are in carrier periods (1/13.56Mhz)          
iClass    - Timings are not as accurate          

     Start |       End | Src | Data (! denotes parity error)                                   | CRC | Annotation         |          
-----------|-----------|-----|-----------------------------------------------------------------|-----|--------------------|          
         0 |      1056 | Rdr | 26                                                              |     | REQA          
      2484 |      4852 | Tag | 04  00                                                          |     |           
     13404 |     15868 | Rdr | 93  20                                                          |     | ANTICOLL          
     17552 |     23440 | Tag | 92  c0  45  6b  7c                                              |     |           
     44792 |     55320 | Rdr | 93  70  92  c0  45  6b  7c  05  cd                              |     | SELECT_UID          
     56812 |     60332 | Tag | 08  b6  dd                                                      |     |           
    192284 |    196988 | Rdr | e0  50  bc  a5                                                  |     | RATS          
    198672 |    199312 | Tag | 04                                                              |     |           
    335992 |    337048 | Rdr | 26                                                              |     | REQA          
    338412 |    340780 | Tag | 04  00                                                          |     |           
    349476 |    351940 | Rdr | 93  20                                                          |     | ANTICOLL          
    353752 |    359640 | Tag | 92  c0  45  6b  7c                                              |     |           
    380930 |    391458 | Rdr | 93  70  92  c0  45  6b  7c  05  cd                              |     | SELECT_UID          
    393014 |    396534 | Tag | 08  b6  dd                                                      |     |           
    566934 |    571638 | Rdr | 60  3f  81  b2                                                  |     | AUTH-A(63)          
    575946 |    580682 | Tag | 01  02  03  04                                                  |     |           
   1433984 |   1434976 | Rdr | 52                                                              |     | WUPA          
   1436596 |   1438964 | Tag | 04  00                                                          |     |           
   1452254 |   1462782 | Rdr | 93  70  92  c0  45  6b  7c  05  cd                              |     | SELECT_UID          
   1464338 |   1467858 | Tag | 08  b6  dd                                                      |     |           
   1637440 |   1642144 | Rdr | 60  3f  81  b2                                                  |     | AUTH-A(63)          
   1646644 |   1651380 | Tag | 01  02  03  04                                                  |     |           
   2503034 |   2504026 | Rdr | 52                                                              |     | WUPA          
   2505582 |   2507950 | Tag | 04  00                                                          |     |           
   2521272 |   2531800 | Rdr | 93  70  92  c0  45  6b  7c  05  cd                              |     | SELECT_UID          
   2533356 |   2536876 | Tag | 08  b6  dd                                                      |     |           
   2705594 |   2710298 | Rdr | 60  3f  81  b2                                                  |     | AUTH-A(63)          
   2714606 |   2719342 | Tag | 01  02  03  04                                                  |     |           
   3571876 |   3572868 | Rdr | 52                                                              |     | WUPA          
   3574616 |   3576984 | Tag | 04  00                                                          |     |           
   3590146 |   3600674 | Rdr | 93  70  92  c0  45  6b  7c  05  cd                              |     | SELECT_UID          
   3602230 |   3605750 | Tag | 08  b6  dd                                                      |     |           
   3775332 |   3780036 | Rdr | 60  3f  81  b2                                                  |     | AUTH-A(63)          
   3784536 |   3789272 | Tag | 01  02  03  04                                                  |     |           
   4641694 |   4642686 | Rdr | 52                                                              |     | WUPA          
   4644242 |   4646610 | Tag | 04  00                                                          |     |           
   4659932 |   4670460 | Rdr | 93  70  92  c0  45  6b  7c  05  cd                              |     | SELECT_UID          
   4672016 |   4675536 | Tag | 08  b6  dd                                                      |     |           
   4845790 |   4850494 | Rdr | 60  3f  81  b2                                                  |     | AUTH-A(63)          
   4854930 |   4859666 | Tag | 01  02  03  04                                                  |     |           
   5712120 |   5713112 | Rdr | 52                                                              |     | WUPA          
   5714668 |   5717036 | Tag | 04  00                                                          |     |           
   5730390 |   5740918 | Rdr | 93  70  92  c0  45  6b  7c  05  cd                              |     | SELECT_UID          
   5742410 |   5745930 | Tag | 08  b6  dd                                                      |     |           
   5915576 |   5920280 | Rdr | 60  3f  81  b2                                                  |     | AUTH-A(63)          
   5924588 |   5929324 | Tag | 01  02  03  04                                                  |     |           
   6780226 |   6781218 | Rdr | 52                                                              |     | WUPA          
   6782774 |   6785142 | Tag | 04  00                                                          |     |           
   6798464 |   6808992 | Rdr | 93  70  92  c0  45  6b  7c  05  cd                              |     | SELECT_UID          
   6810548 |   6814068 | Tag | 08  b6  dd                                                      |     |           
   6983682 |   6988386 | Rdr | 60  3f  81  b2                                                  |     | AUTH-A(63)          
   6992822 |   6997558 | Tag | 01  02  03  04                                                  |     |           
   7849948 |   7850940 | Rdr | 52                                                              |     | WUPA          
   7852560 |   7854928 | Tag | 04  00                                                          |     |           
   7868218 |   7878746 | Rdr | 93  70  92  c0  45  6b  7c  05  cd                              |     | SELECT_UID          
   7880302 |   7883822 | Tag | 08  b6  dd                                                      |     |           
   8053404 |   8058108 | Rdr | 60  3f  81  b2                                                  |     | AUTH-A(63)          
   8062608 |   8067344 | Tag | 01  02  03  04                                                  |     |           
   8918998 |   8919990 | Rdr | 52                                                              |     | WUPA          
   8921546 |   8923914 | Tag | 04  00                                                          |     |           
   8937124 |   8947652 | Rdr | 93  70  92  c0  45  6b  7c  05  cd                              |     | SELECT_UID          
   8949208 |   8952728 | Tag | 08  b6  dd                                                      |     |           
   9122326 |   9127030 | Rdr | 60  3f  81  b2                                                  |     | AUTH-A(63)          
   9131338 |   9136074 | Tag | 01  02  03  04                                                  |     |           
   9986944 |   9987936 | Rdr | 52                                                              |     | WUPA          
   9989556 |   9991924 | Tag | 04  00                                                          |     |           
  10005214 |  10015742 | Rdr | 93  70  92  c0  45  6b  7c  05  cd                              |     | SELECT_UID          
  10017298 |  10020818 | Tag | 08  b6  dd                                                      |     |           
  10206682 |  10211450 | Rdr | 50  00  57  cd                                                  |     | HALT          
 190994468 | 190995524 | Rdr | 26                                                              |     | REQA          
 190996952 | 190999320 | Tag | 04  00                                                          |     |           
 191008000 | 191010464 | Rdr | 93  20                                                          |     | ANTICOLL          
 191012148 | 191018036 | Tag | 92  c0  45  6b  7c                                              |     |           
 191039324 | 191049852 | Rdr | 93  70  92  c0  45  6b  7c  05  cd                              |     | SELECT_UID          
 191051408 | 191054928 | Tag | 08  b6  dd                                                      |     |           
 191184448 | 191189152 | Rdr | e0  50  bc  a5                                                  |     | RATS          
 191190836 | 191191476 | Tag | 04                                                              |     |           
 191327324 | 191328380 | Rdr | 26                                                              |     | REQA          
 191329808 | 191332176 | Tag | 04  00                                                          |     |           
 191340920 | 191343384 | Rdr | 93  20                                                          |     | ANTICOLL          
 191345004 | 191350892 | Tag | 92  c0  45  6b  7c                                              |     |           
 191372196 | 191382724 | Rdr | 93  70  92  c0  45  6b  7c  05  cd                              |     | SELECT_UID          
 191384408 | 191387928 | Tag | 08  b6  dd                                                      |     |           
 191555896 | 191560600 | Rdr | 60  3f  81  b2                                                  |     | AUTH-A(63)          
 191564908 | 191569644 | Tag | 01  02  03  04                                                  |     |           
 192419778 | 192420770 | Rdr | 52                                                              |     | WUPA          
 192422326 | 192424694 | Tag | 04  00                                                          |     |           
 192438046 | 192448574 | Rdr | 93  70  92  c0  45  6b  7c  05  cd                              |     | SELECT_UID          
 192450066 | 192453586 | Tag | 08  b6  dd                                                      |     |           
 192621570 | 192626274 | Rdr | 60  3f  81  b2                                                  |     | AUTH-A(63)          
 192630710 | 192635446 | Tag | 01  02  03  04                                                  |     |           
 193485404 | 193486396 | Rdr | 52                                                              |     | WUPA          
 193488016 | 193490384 | Tag | 04  00                                                          |     |           
 193503674 | 193514202 | Rdr | 93  70  92  c0  45  6b  7c  05  cd                              |     | SELECT_UID          
 193515758 | 193519278 | Tag | 08  b6  dd                                                      |     |           
 193687324 | 193692028 | Rdr | 60  3f  81  b2                                                  |     | AUTH-A(63)          
 193696528 | 193701264 | Tag | 01  02  03  04                                                  |     |           
 194551254 | 194552246 | Rdr | 52                                                              |     | WUPA          
 194553802 | 194556170 | Tag | 04  00                                                          |     |           
 194569508 | 194580036 | Rdr | 93  70  92  c0  45  6b  7c  05  cd                              |     | SELECT_UID          
 194581592 | 194585112 | Tag | 08  b6  dd                                                      |     |           
 194753046 | 194757750 | Rdr | 60  3f  81  b2                                                  |     | AUTH-A(63)          
 194762058 | 194766794 | Tag | 01  02  03  04                                                  |     |           
 195616768 | 195617760 | Rdr | 52                                                              |     | WUPA          
 195619380 | 195621748 | Tag | 04  00                                                          |     |           
 195635038 | 195645566 | Rdr | 93  70  92  c0  45  6b  7c  05  cd                              |     | SELECT_UID          
 195647122 | 195650642 | Tag | 08  b6  dd                                                      |     |           
 195818560 | 195823264 | Rdr | 60  3f  81  b2                                                  |     | AUTH-A(63)          
 195827764 | 195832500 | Tag | 01  02  03  04                                                  |     |           
 196682618 | 196683610 | Rdr | 52                                                              |     | WUPA          
 196685166 | 196687534 | Tag | 04  00                                                          |     |           
 196700856 | 196711384 | Rdr | 93  70  92  c0  45  6b  7c  05  cd                              |     | SELECT_UID          
 196712940 | 196716460 | Tag | 08  b6  dd                                                      |     |           
 196884410 | 196889114 | Rdr | 60  3f  81  b2                                                  |     | AUTH-A(63)          
 196893422 | 196898158 | Tag | 01  02  03  04                                                  |     |           
 197748260 | 197749252 | Rdr | 52                                                              |     | WUPA          
 197751000 | 197753368 | Tag | 04  00                                                          |     |           
 197766658 | 197777186 | Rdr | 93  70  92  c0  45  6b  7c  05  cd                              |     | SELECT_UID          
 197778742 | 197782262 | Tag | 08  b6  dd                                                      |     |           
 197950308 | 197955012 | Rdr | 60  3f  81  b2                                                  |     | AUTH-A(63)          
 197959512 | 197964248 | Tag | 01  02  03  04                                                  |     |           
 198814366 | 198815358 | Rdr | 52                                                              |     | WUPA          
 198816914 | 198819282 | Tag | 04  00                                                          |     |           
 198832604 | 198843132 | Rdr | 93  70  92  c0  45  6b  7c  05  cd                              |     | SELECT_UID          
 198844688 | 198848208 | Tag | 08  b6  dd                                                      |     |           
 199016158 | 199020862 | Rdr | 60  3f  81  b2                                                  |     | AUTH-A(63)          
 199025298 | 199030034 | Tag | 01  02  03  04                                                  |     |           
 199880056 | 199881048 | Rdr | 52                                                              |     | WUPA          
 199882604 | 199884972 | Tag | 04  00                                                          |     |           
 199898198 | 199908726 | Rdr | 93  70  92  c0  45  6b  7c  05  cd                              |     | SELECT_UID          
 199910218 | 199913738 | Tag | 08  b6  dd                                                      |     |           
 200081720 | 200086424 | Rdr | 60  3f  81  b2                                                  |     | AUTH-A(63)          
 200090732 | 200095468 | Tag | 01  02  03  04                                                  |     |           
 200945474 | 200946466 | Rdr | 52                                                              |     | WUPA          
 200948022 | 200950390 | Tag | 04  00                                                          |     |           
 200963584 | 200974112 | Rdr | 93  70  92  c0  45  6b  7c  05  cd                              |     | SELECT_UID          
 200975668 | 200979188 | Tag | 08  b6  dd                                                      |     |           
 201161706 | 201166474 | Rdr | 50  00  57  cd                                                  |     | HALT   

Reader output:

#./nfc-mfclassic r a dump.mfd
NFC reader: ACS / ACR122U PICC Interface opened
Found MIFARE Classic card:
ISO/IEC 14443A (106 kbps) target:
    ATQA (SENS_RES): 00  04  
       UID (NFCID1): 92  c0  45  6b  
      SAK (SEL_RES): 08  
Guessing size: seems to be a 1024-byte card
Reading out 64 blocks |nfc_initiator_transceive_bytes: Mifare Authentication Failed
nfc_initiator_transceive_bytes: Mifare Authentication Failed
nfc_initiator_transceive_bytes: Mifare Authentication Failed
nfc_initiator_transceive_bytes: Mifare Authentication Failed
nfc_initiator_transceive_bytes: Mifare Authentication Failed
nfc_initiator_transceive_bytes: Mifare Authentication Failed
nfc_initiator_transceive_bytes: Mifare Authentication Failed
nfc_initiator_transceive_bytes: Mifare Authentication Failed
nfc_initiator_transceive_bytes: Mifare Authentication Failed
!
Error: authentication failed for block 0x3f

Antenna characteristics (admittedly bad):

proxmark3> hw tune

Measuring antenna characteristics, please wait.........          
# LF antenna:  0,00 V @   125.00 kHz          
# LF antenna:  0,00 V @   134.00 kHz          
# LF optimal:  0,00 V @ 12000,00 kHz          
# HF antenna:  6,45 V @    13.56 MHz          
# Your LF antenna is unusable.          
Done! Divisor 89 is 134khz, 95 is 125khz.

[pwpiwi]

Thanks holiman! I did send you an upload link.

[holiman]

Files uploaded...

[pwpiwi]

Files downloaded...

[pwpiwi]

• 1 is a reading from a std reader, reading all blocks from a standard mifare classic tag. UID is 92C0456B.eml, all keys are FFFFFFFFFFFF
• 2 is a reading from the same reader, trying to do the same thing again against a 'hf 14a sim 92C0456B'.
• 3 is a reading when loading the 92C0456B-tag dump into pm3 emulator mem, then doing 'hf mf sim'. The tag never responds (does not see the reader commands)
• 4 is the same setup as 3, except I changed MF_MINFIELDV to 2000. The reader and tag now communicates, but for some reason auth fails. Trace is below.

Questions: all measurements are done using a separate "probe" PM3 (running hf 14a snoop?) and having the probes on ADC_IN (TP1) and the FPGA debug bin (TP7)? Or did you use a single PM3 running different commands in each setup? I am wondering because the FPGA debug output looks different for different setups.

[holiman]

All measurements done on TP1 and TP7, yes. I also tested using TP4/TP3, which sometimes works, but I've found AD input to be better/more stable both when the pm3 is in active and passive mode.

All measurements done using a single pm3 connected to a hf-antenna. I didn't move anything around until 3, when I moved the antenna around to try to get the reading to work, but I didn't change any attached cables.

In the first reading, I placed the pm3 in snoop-mode (hf 14a snoop), so it wouldn't disturb the tag<->reader comms. I didn't save the pm3-trace for that, I didn't think of that. So yes, different commands in each setup (well, 3 and 4 are the same)

[pwpiwi]

First Observations:

• @holiman: the amplitude in 1 is quite low compared to the others. Did you have the antenna in the same position / distance to the reader? Or did you have the card in between?
• when simulating, the PM3 sends an erroneous additional bit after the stop bit. Easy to fix but doesn't solve the issue.
• The reader does continue with nr/ar after nt. I.e. it does receive the tag response on the AUTH command and responds despite the erroneous bit.

To be continued...

[holiman]

@holiman: the amplitude in 1 is quite low compared to the others. Did you have the antenna in the same position / distance to the reader? Or did you have the card in between?

I had the reader at the bottom. On top of that, the rhyscorp antenna with the tag on top of that. The rhyscorp antenna is only flat on one side, some components on the other. The bulky side was against the reader, so there was a bit of a distance there. The tag was flat against the antenna. All held together with some rubber strings.

In hindsight; it would perhaps have been better to have reader->tag->antenna with 'bulky' side up. I don't know offhand why the amplitude is low on the first one. I don't think I changed anything, except for when I tried to get (3) to work.

when simulating, the PM3 sends an erroneous additional bit after the stop bit. Easy to fix but doesn't solve the issue.

Simple to spot once you know what to look for: https://github.com/Proxmark/proxmark3/blob/master/armsrc/iso14443a.c#L1537

That may not be the issue, but it may definitely be one cause to problems with certain readers. Depends on what happens to be in the buffer at that point in time (a 0 doesn't matter), which becomes set during compilation, I suppose.

Incidentally, it stems from here, a.k.a "7bc95e2", a.k.a r845...

[holiman]

For anyone without access to the data, here's a picture. Above is sim, below is snoop. Both at the first tag response

That extra bit is clearly shown on the above right side

[holiman]

And here, I think, is where the pm3-simulated tag does not respond to the AR/NR.

The reader-command here is quite fast, I measured it to ~90 uS from tag EOT. At no point, earlier in the trace, is the gap between tag response and reader command that small.

[holiman]

Additionally, it appears that our extra bit is taken from our time. When the reader has read what it wants to read, it ignores the rest of the tag response (our extra '1'). So we lose an additional 10 uS, having only ~80uS to get the reading going properly.

Edit: actually, I placed the lower right timing marker a bit off, it's more like 79,7uS versus 98,7 uS, so the bit "costs" 19 uS.

[pwpiwi]

... and you can clearly see as well what I meant with the phase error. The modulation is inverted. Again this was easy to fix but didn't solve the issue.

[holiman]

... and you can clearly see as well what I meant with the phase error. The modulation is inverted. Again this was easy to fix but didn't solve the issue.

Ah, I just thought that was an artefact from doing measurements on the same board we're generating the signals from or something. I don't know how the voltage on our antenna is supposed to be affected by the driving of the coils, so I didn't think that was of interest.

[pwpiwi]

Ah, I just thought that was an artefact from doing measurements on the same board we're generating the signals from or something.

Hmmm - I cannot exclude that. I thought the measurements in the forum had been done "on the air"but I can be wrong. To be sure: could you please do a quick comparison of reader-tag vs. reader-PM3 on the air? You just need to connect a simple antenna (three rectangular windings a little bit smaller than card size) directly to your Logic Pro 8. No need to dump, just interested in "inverted" or "not inverted".

[holiman]

You just need to connect a simple antenna (three rectangular windings a little bit smaller than card size) directly to your Logic Pro 8.

Sure, I'll try. If I use regular small wire, I don't need to trim off the plastic cover, right?

Any thoughts about the 80uS time before next command-thing?

[pwpiwi]

Sure, I'll try. If I use regular small wire, I don't need to trim off the plastic cover, right?

Right. (except at the two ends :smile:)

Any thoughts about the 80uS time before next command-thing?

Shouldn't be an issue. After sending the tag response the PM3 is ready for the next reader command in approx 20us (it just does the tracing in this time).

[holiman]

I tried and failed, I think I made the coil too small. I'll give it another go tomorrow. Should both ends be connected to the input (short-circuiting the coil), or only one end?

[pwpiwi]

You need to connect one end to the input, the other end to the GND connector.

[pwpiwi]

Additional hints: "on air" you will have the 13,56MHz carrier signal with a strong modulation by the reader but a much weaker modulation by the tag. 25MSamples/sec might be too slow to identify something. If this is the case you need either increase the sampling frequency or switch on a lowpass filter (whatever the Logic Pro 8 provides).

[holiman]

The tool supports up to 50Msps for analog, should be fine.

Oh, and beside tracing, it also does ad averaging before reading. 32 reads from ad. If that is done at ARM clockspeed it's no issue (?), but I don't know if that's slowed down by waiting on any external signals or something? From the looks of it, setting ADC_MODE_SAMPLE_HOLD_TIME, STARTUP_TIME etc it looks like it could take a bit of time.

[pwpiwi]

If you are talking about emgetcmd: it doesn't wait for the ADC. If ADC isn't ready, it continues reading from the FPGA. The field strength measurement therefore doesn't slow down the reading.

Another question regarding your captures: did you modify the FPGA configuration? The debug output should be connected to neg_edge_cnt[3] which should be a signal at a constant frequency. In your captures it looks weird.

[holiman]

Nope, talking about the other in the main loop. The one I've been advocating is unnecessary.

And nope, it's clean from github (only modded minfield)

[holiman]

Nevermind, that's only done if in MFEMUL_NOFIELD

[holiman]

Ok, so I wound together a HF antenna which I used to sniff both the pm3 in sim-mode and a regular tag, same setup as before; identical UID and tag data. Here are a couple of images.

On the upper part is pm3, below is tag. The only thing that really stands out is that the pm3 antenna (or, at least, my pm3-antenna) does not produce as deep modulations as the regular tag. I did a couple of different readings here, moving the antenna a few millimeters left and right, to ensure that it was aligned properly with my homemade snooper-antenna, but it didn't really seem to matter.

The capture is from sometime in the beginning, though I'm not 100% sure what commands they correspond to.

Second image, I zoomed in on the tag responses:

Here it's even more obvious that the amplitude is very low. It's hard to say anything about the phase without any better voltage levels.

The FPGA signal looks good (perhaps I was sloppy with the ground-connections earlier).

[holiman]

I also removed the extra bit, and tested if it made any difference. As can be seen, the bit is gone, we now have ~98uS instead of ~80uS. However, as can also be seen, it didn't make any difference.

Curious indeed! I wonder if the error is on the ARM-side or the FPGA-side. Two suggestions: 1) We light up a led when we're receiving bits from the ARM, before doing UART-demodulation (or is it Demod, I always mix them up). That way, if I place a probe on it, we could see what the FPGA delivers, and when. 2) We just do some more printouts in the demodulator. Could it for some reason it wind up in a bad state and just skip the rest of the message? We could even set a global flag after sending the nonce, to enable some form of ARM-side debug log.

Any other ideas?

[pwpiwi]

To see what the FPGA delivers, it should be enough to change the last line of hi_iso14443a.v to assign dbg = ssp_din;. You would then see on TP1 the input to the FPGA and on TP7 the demodulated output. This is when the reader is sending. During the simulated tag response TP7 should show internal timing information:

• the fdt_indicator should signal when the ARM can send its first data - this should be set to logic 1 a constant time after the last reader modulation.
• later it should show timing information on the FPGAs internal delay queue (8 Bits, repeating a few times)

I will have a DSO on next weekend so that I can support holiman with measurements.

[holiman]

I'll debug the data flowing into the miller decoder later, unable to right now.

However, I saw that if start is two zeroes followe by 5 ones (instead of 6), it'll fail. E.g fe7d. Is that expected? I mean that it must be either two/six or three/five ?

[pwpiwi]

The Miller decoder accepts any pattern of 8 Bits starting with 2 zeroes and ending with 4 ones as a start bit. So yes, your example would fail. Which is OK because in Miller encoding you have a modulation (i.e. a sequence of zeroes) in either the first or the second half of the (in our case) 8 Bit pattern. Your example fe7d is 1111111001111101 in binary. You have 2 zeroes and a single 0 in this pattern. One of it must be wrong when looking for a start bit (a modulation in the first 4 bits, no modulation in the second 4 bits). It is therefore not accepted.

After we have identified the start bit, the decoder is more relaxed. We then know where our 8 Bit patterns start in the bitstream and accept any sequence of 2 or 3 zeroes as modulation. The single zeroe of your pattern would then be ignored and interpreted as "no modulation".

I have observed that the first "pause" usually consists of 3 zeroes, all the following of only 2 zeroes.

[holiman]

How about fe7c then? The latter zeroes could be the start of the message, no?

[pwpiwi]

fe7c = 1111111001111100 would be an error as well. If you cut this in 4 Bit Pieces it is x111 1111 0011 1110 0xxx Again, you have a modulation in two following halfs which isn't a valid Miller coding. Valid are

• 0011 1111 (modulation in first half): this is either the start bit or a logic zero (if following the start bit or another logic zero))
• 1111 0011 (modulation in second half): this is a logic one
• 1111 1111 (no modulation): this is a logic zero (if following after a logic one) or the stop bit (if following a logic zero) or no information (if repeated)

[pwpiwi]

The FPGA signal looks good (perhaps I was sloppy with the ground-connections earlier).

You mean that on TP7 is now a rectangular, regular wave when simulating - like in your snooping capture?

[holiman]

Finally, I've made some proper progress !

Once the pm3 entered MFEMUL_AUTH1-state, I toggled a flag to debug the miller decoder. So each uint8_t "bit" fed into the miller decoder was captured. This is the result:

uint8_t bitsin = [0x27,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xf8,0xff,0x8f,0x8f,0xf8,0xf8,0xf8,0xff,0x8f,0xff,0x8f,0x8f,0xf8,0xf8,0xff,0x8f,0xf8,0xff,0x8f,0xf8,0xff,0x8f,0xff,0x8f,0xf8,0xf8,0xf8,0xff,0x8f,0xf8,0xf8,0xf8,0xff,0x8f,0xf8,0xf8,0xf8,0xf8,0xff,0x8f,0x8f,0xf8,0xff,0x8f,0xff,0x8f,0xf8,0xf8,0xf8,0xff,0x8f,0x8f,0x8f,0xff,0x8f,0xff,0x8f,0x8f,0xf8,0xff,0x8f,0x8f,0x8f,0x8f,0xff,0x8f,0x8f,0xf8,0xf8,0xf8,0xf8,0xff,0x8f,0xf8,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff];

I then placed that array into the arm-source, and tested decoding it using the miller decoder. It failed, as expected. The reason is this:

if (Uart.state == STATE_UNSYNCD) {                                              // not yet synced

    if (Uart.highCnt < 7) {                                                 // wait for a stable unmodulated signal
        if (Uart.twoBits == 0xffff) {
            Uart.highCnt++;
        } else {
            Uart.highCnt = 0;
        }
    } else {    

It expects a 'stable unmodulated signal', but the starting 0x27 is not stable enough. If I change that into 0xFF instead, the follownig is produced:

#db# f8 -> state(3)                 
#db# ff -> state(4)                 
#db# Miller decoding successfull after 83 'bits'                 
#db# Decoded len 8                 
#db# Decoded data 06 00 00 ea ...                 
#db# ff -> state(0)                 

That is, the AR/NR pair is hiding in the data :)

So, I think it's the short time between tag and reader which haunts us after all. The FPGA is ready and delivering, but we're expecting a too long unmodulated signal. If we shorten that, we should be fine. I don't know what the protocol specs says...?

Oh, and I did a few runs, similar results every time. 0x27, or 0x17 several times.

[pwpiwi]

The 0x27 itself isn't the problem. The Miller decoder would skip that. The problem is the short sequence of 0xff after a fast reader response. I had found the same and changed the Uart.highCnt < 7 to smaller values. In your example 6 would have been low enough, but I have observed that sometimes it can be required to be as low as 2 (even faster reader response, only three consecutive 0xff). However, if I lower it, the decoding becomes less reliable in general (hf list 14a looks not very good anymore) - and I don't know yet why this is the case.

But we are getting closer...

[pwpiwi]

BTW: 0x17 and 0x27 are remainders of the last EmSendCmd14443aRaw(). In TAGSIM_MOD mode the FPGA feeds back timing information on its internal delay queue. This information is still in the receiving register when we call EmGetCmd().

[iceman1001]

So the remainders information should be cleared like its done in EmSendCmd14443aRaw?

[pwpiwi]

Doesn't matter. The Miller-Demodulator waits for a sequence of 0xff anyway before starting to decode and therefore skips preceding garbage.

[iceman1001]

And the problem now is that the sequence of 0xff (ones) is not long enough?

[holiman]

Yes, as I wrote: we're e expecting a too long unmodulated signal. @piwi, in what circumstances are shorter 'runs' problematic? Can you show the output from list with false positives?

Also, what does 0xff correspond to in real time, is that 256 x 1/13.56m seconds or what?

[holiman]

Looking at the comments in the old miller decoder, there's this comment:

should have been high or at least (4*128)/fc
according to iso this should be at least (9*128+20)/fc

The latter is 86us. I think we should aim for around 60us, having some margin but still not too many FPs. Don't know what that translates to though?

[pwpiwi]

Can you show the output from list with false positives?

Not now. But it contained sequences of repeated Rdr 26 / Tag 0400, and things like Rdr 1a, Rdr 06. Weird.

Also, what does 0xff correspond to in real time, is that 256 x 1/13.56m seconds or what?

Its 8 x 16 x 1/13,56MHz = 9,44us

[pwpiwi]

Looking at the comments in the old miller decoder, there's this comment:

should have been high or at least (4*128)/fc
according to iso this should be at least (9*128+20)/fc

The latter is 86us. I think we should aim for around 60us, having some margin but still not too many FPs. Don't know what that translates to though?

The comments are correct. One byte 0xff is 128/fc (fc is the carrier frequency 13,56MHz). The 8 x 4 Bits waiting time of the old decoder would have translated to 3 overlapping 0xffff in the new one. But I had the same issue with "false positives" at that time and therefore increased to 7. To keep up with the fast reader responses it now should be as low as 2 (corresponding to 2 overlapping 0xffff, which is three 0xff).

[holiman]

For me, it works perfectly with < 2.

    #define MILLER_STARTSEQ 2
    [...]
    if (Uart.highCnt < MILLER_STARTSEQ) {                                                   // wait for a stable unmodulated signal
        if (Uart.twoBits == 0xffff) {
            Uart.highCnt++;
        } else {
            Uart.highCnt = 0;
        }

I guess also the places were Uart.highCnt = 6 should also be set to MILLER_STARTSEQ-1? I've not seen any false positives.