hf mf sim after r845 #11

Closed
holiman opened this Issue Apr 2, 2014 · 117 comments

Projects

None yet

5 participants

@holiman
Contributor
holiman commented Apr 2, 2014

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
Contributor
pwpiwi commented Apr 2, 2014

Because you are reporting issues with snoop as well, I would expect a problem with receiving the reader commands. Do you have the possibility to measure the signal at TP1 while snooping? Or can you try Enio's "PM3 as Digital Storage Oscilloscope" hack? Does hf 14a snoop give you any results?

Can you clarify which version did work last for you (you mention "after r845" in the subject and "with r844 and later" in your comment)

@pwpiwi pwpiwi closed this Apr 2, 2014
@pwpiwi pwpiwi reopened this Apr 2, 2014
@holiman
Contributor
holiman commented Apr 2, 2014

r844 was just cosmetics, what I mean is r845 and later does not work.
Some background: A while ago, I was working a bit with 'hf mf sim' r840-r844 for a pen-test on mifare-based access control system. It worked fine on their readers. Today I got the chance to test the same reader again, and confirmed that any version post r844 did not work anymore (for that reader).

Some more context:
At that place, they have three readers, all are same model and make.
Reader 1: No commuication with either pre-845 or post-845. No led-light.
Reader 2: pre-845 works, post-845 blinks yellow.
Reader 3: pre-845 works, post-845 blinks yellow.

I will be able to test again thursday and friday, after that it will be difficult to perform tests. I'll try get the time to make a special debug-build and get some more info on what is happening.

Does hf 14a snoop give you any results?

Not that I can recall, I can test that tomorrow. hf mf sniff with a legitimate card does not produce anything. I have actually never gotten anything out of hf mf sniff, so I don't even know what to expect :)

Do you have the possibility to measure the signal at TP1 while snooping?
No.

Or can you try Enio's "PM3 as Digital Storage Oscilloscope" hack?
What do I have to do? Is there a codebase somewhere I can use to just flash the device, or is it something more complicated? I can do tests the next two days.

@holiman
Contributor
holiman commented Apr 2, 2014

Some more thoughts, it's the yellow light that blinks, (LED_A), and that light is really only used at one place in Mifare1kSim:

    if (cardSTATE == MFEMUL_NOFIELD) {
        vHf = (33000 * AvgAdc(ADC_CHAN_HF)) >> 10;
        if (vHf > MF_MINFIELDV) {
            cardSTATE_TO_IDLE();
            LED_A_ON();
        }
    } 

So, my feeling is that somehow the readers sensitivity got worse, and it does not even leave go into the simulation-logic. I'll add some debug printouts and check that later.

@holiman
Contributor
holiman commented Apr 3, 2014

I did a modification to print out the measured reader field:

    // find reader field
    // Vref = 3300mV, and an 10:1 voltage divider on the input
    // can measure voltages up to 33000 mV
    if (cardSTATE == MFEMUL_NOFIELD) {
        vHf = (33000 * AvgAdc(ADC_CHAN_HF)) >> 10;
        if (vHf > MF_MINFIELDV) {
            cardSTATE_TO_IDLE();
            LED_A_ON();
        }else
        {
            if(i++ % 10 == 0) Dbprintf("No field found, vhf = %d", vHf);
        }
    } 

results:

#db# No field found, vhf = 3125                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 64                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 3544                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 3512                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 193                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 2739                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 805                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 2126                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 1579                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 1385                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 2255                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 741                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 2803                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 64                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 3287                 
#db# No field found, vhf = 64                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 3319                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 2932                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 515                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 2320                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 64                 
#db# No field found, vhf = 1160                 
#db# No field found, vhf = 96                 
#db# No field found, vhf = 1708                 
#db# No field found, vhf = 64                 
#db# No field found, vhf = 96                 
[...]     

Next modification, ignore vHf value, rely only on the reader-field check which is built into EmGetCmd:

    // find reader field
    // Vref = 3300mV, and an 10:1 voltage divider on the input
    // can measure voltages up to 33000 mV
    if (cardSTATE == MFEMUL_NOFIELD) {
        vHf = (33000 * AvgAdc(ADC_CHAN_HF)) >> 10;
        if (vHf > MF_MINFIELDV || true) {
            cardSTATE_TO_IDLE();
            LED_A_ON();
        }else
        {
            if(i++ % 10 == 0) Dbprintf("No field found, vhf = %d", vHf);
        }
    } 
    if(cardSTATE == MFEMUL_NOFIELD) continue;
    DbpString("Field found, commencing sampling");
    //Now, get data

    res = EmGetCmd(receivedCmd, &len);
    if (res == 2) { //Field is off!
        cardSTATE = MFEMUL_NOFIELD;
        LEDsoff();
        DbpString("EmGetCmd returned 2: no field");
        continue;
    } else if (res == 1) {
        break;  //return value 1 means button press
    }
    DbpString("EmGetCmd ok, continuing");

results

#db# Field found, commencing sampling                 
#db# EmGetCmd ok, continuing                 
#db# Field found, commencing sampling                 
#db# EmGetCmd ok, continuing                 
#db# Field found, commencing sampling                 
#db# EmGetCmd ok, continuing                 
#db# Field found, commencing sampling                 
#db# EmGetCmd ok, continuing                 
#db# Field found, commencing sampling                 
#db# EmGetCmd ok, continuing                 
#db# Field found, commencing sampling                 
#db# EmGetCmd ok, continuing                 
#db# Field found, commencing sampling                 
#db# EmGetCmd ok, continuing                 
#db# Field found, commencing sampling                 
#db# EmGetCmd ok, continuing                 
#db# Field found, commencing sampling                 
#db# EmGetCmd ok, continuing                 
#db# Field found, commencing sampling                 
#db# EmGetCmd ok, continuing                 
#db# Field found, commencing sampling                 
#db# EmGetCmd ok, continuing                 
#db# Field found, commencing sampling                 
#db# EmGetCmd ok, continuing                 
#db# Field found, commencing sampling                 
#db# EmGetCmd ok, continuing             
[...]

db# Emulator stopped. Tracing: 0  trace length: 2994                  
proxmark3> hf 14a list
Recorded Activity          

Start = Start of Start Bit, End = End of last modulation. Src = Source of Transfer          
All times are in carrier periods (1/13.56Mhz)          

     Start |       End | Src | Data          
-----------|-----------|-----|--------          
         0 |       992 | Rdr | 52              
     11508 |     13876 | Tag | 04  00              
    680226 |    681218 | Rdr | 52              
    691606 |    693974 | Tag | 04  00              
    727040 |    729504 | Rdr | 93  20              
    740724 |    746612 | Tag | e6  84  87  f3  16              
    785152 |    795616 | Rdr | 93  70  e6  84  87  f3  16  5e  35              
    807156 |    811828 | Tag | 08  b6  dd  00              
   1500160 |   1501152 | Rdr | 52              
   1512692 |   1515060 | Tag | 04  00              
   1547136 |   1549600 | Rdr | 93  20              
   1560180 |   1566068 | Tag | e6  84  87  f3  16              
   1605198 |   1615662 | Rdr | 93  70  e6  84  87  f3  16  5e  35              
   1626370 |   1631042 | Tag | 08  b6  dd  00              
   2319104 |   2320096 | Rdr | 52              

That looks good. Next change:

    // find reader field
    // Vref = 3300mV, and an 10:1 voltage divider on the input
    // can measure voltages up to 33000 mV
    /**
      Ignore this: EmGetCmd checks for a field internally
    if (cardSTATE == MFEMUL_NOFIELD) {
        vHf = (33000 * AvgAdc(ADC_CHAN_HF)) >> 10;
        if (vHf > MF_MINFIELDV || true) {
            cardSTATE_TO_IDLE();
            LED_A_ON();
        }else
        {
            if(i++ % 10 == 0) Dbprintf("No field found, vhf = %d", vHf);
        }
    } 
    if(cardSTATE == MFEMUL_NOFIELD) continue;
    DbpString("Field found, commencing sampling");
    //Now, get data
    **/
    res = EmGetCmd(receivedCmd, &len);
    if (res == 2) { //Field is off!
        cardSTATE = MFEMUL_NOFIELD;
        LEDsoff();
        DbpString("EmGetCmd returned 2: no field");
        continue;
    } else if (res == 1) {
        break;  //return value 1 means button press
    }else
    {// Read ok
        DbpString("EmGetCmd ok, continuing");
        cardSTATE_TO_IDLE();
    }

Result:

#db# EmGetCmd ok, continuing                 
#db# EmGetCmd ok, continuing                 
#db# EmGetCmd returned 2: no field                 
#db# EmGetCmd ok, continuing                 
#db# EmGetCmd ok, continuing                 
#db# EmGetCmd returned 2: no field                 
#db# EmGetCmd ok, continuing                 
#db# EmGetCmd ok, continuing                 
#db# EmGetCmd returned 2: no field                 
#db# EmGetCmd ok, continuing                 
#db# EmGetCmd ok, continuing                 
#db# EmGetCmd returned 2: no field                 
#db# EmGetCmd ok, continuing                 
#db# EmGetCmd ok, continuing                 
#db# EmGetCmd returned 2: no field                 
#db# EmGetCmd ok, continuing                 
#db# EmGetCmd ok, continuing                 
#db# EmGetCmd returned 2: no field                 
#db# EmGetCmd ok, continuing                 
#db# EmGetCmd ok, continuing                 
#db# EmGetCmd returned 2: no field    
[...]

proxmark3> hf 14a list
Recorded Activity          

Start = Start of Start Bit, End = End of last modulation. Src = Source of Transfer          
All times are in carrier periods (1/13.56Mhz)          

     Start |       End | Src | Data          
-----------|-----------|-----|--------          
         0 |       992 | Rdr | 52              
     11380 |     13748 | Tag | 04  00              
    679522 |    680514 | Rdr | 52              
    691094 |    693462 | Tag | 04  00              
   1361956 |   1362948 | Rdr | 52              
   1374616 |   1376984 | Tag | 04  00              
   1409024 |   1411488 | Rdr | 93  20              
   2179426 |   2180418 | Rdr | 52              
   2192150 |   2194518 | Tag | 04  00              
   2226560 |   2229024 | Rdr | 93  20              
   2996834 |   2997826 | Rdr | 52              
   3008278 |   3010646 | Tag | 04  00              
   3043696 |   3046160 | Rdr | 93  20              
   3815936 |   3816928 | Rdr | 52              
   3828212 |   3830580 | Tag | 04  00              
   3862768 |   3865232 | Rdr | 93  20              
   4632960 |   4633952 | Rdr | 52              
   4645620 |   4647988 | Tag | 04  00              
   4680160 |   4682624 | Rdr | 93  20              
   5452030 |   5453022 | Rdr | 52             
[...]

It appears that we're just on the edge of detecting the field. Sometimes it works, sometimes it does not. I'll try to test more later, with the older fpga-setup.

@holiman
Contributor
holiman commented Apr 3, 2014

Interestingly, hf 14a sim 1 45454545 worked like a charm...

@pwpiwi
Contributor
pwpiwi commented Apr 3, 2014

It appears that we're just on the edge of detecting the field. Sometimes it works, sometimes it does not. I'll try to test more later, with the older fpga-setup.

Detecting the field has nothing to do with the FPGA. This is measured by the ARM's internal A/D Converter. Did you try to lower MF_MINFIELDV ?

@holiman
Contributor
holiman commented Apr 3, 2014

I'll try that.
Related question; the hf 14a sim uses
static int GetIso14443aCommandFromReader(uint8_t *received, int *len, int maxLen) and does not bother to even check the field. Seems much simpler to me.. :)
I don't know why we would keep
static int EmGetCmd(uint8_t *received, int *len) at all.
I'll see if I can test a bit more tomorrow.

@holiman
Contributor
holiman commented Apr 4, 2014

I replaced the EmGetCmd and field-detection with GetIso14443aCommandFromReader. Relevant parts:

while (!BUTTON_PRESS() && !finished) {
    WDT_HIT();

    if(!GetIso14443aCommandFromReader(receivedCmd, &len, 0))
    {
        break;// Button press
    }
    //cardSTATE_TO_IDLE();

    // REQ or WUP request in ANY state and WUP in HALTED state
    if (len == 1 && ((receivedCmd[0] == 0x26 && cardSTATE != MFEMUL_HALTED) || receivedCmd[0] == 0x52)) {

EDIT; made an error when compiling/flashing. Here are the results:

proxmark3> hf mf sim i x
uid:N/A, numreads:0, flags:9 (0x09)
Press pm3-button to abort simulation
#db# 4B UID: 246c828a
#db# Failed to obtain two AR/NR pairs!
#db# Emulator stopped. Tracing: 0 trace length: 2994
proxmark3> hf 14a list
Recorded Activity

Start = Start of Start Bit, End = End of last modulation. Src = Source of Transfer
All times are in carrier periods (1/13.56Mhz)

Start End Src Data
0 992 Rdr 52
2548 4916 Tag 04 00
682082 683074 Rdr 52
684694 687062 Tag 04 00
718050 720514 Rdr 93 20
722070 727958 Tag 24 6c 82 8a 40
768000 778528 Rdr 93 70 24 6c 82 8a 40 21 10
780020 784692 Tag 08 b6 dd 00
1500386 1501378 Rdr 52
1502998 1505366 Tag 04 00
1536512 1538976 Rdr 93 20
1540468 1546356 Tag 24 6c 82 8a 40
1586750 1597278 Rdr 93 70 24 6c 82 8a 40 21 10
1598834 1603506 Tag 08 b6 dd 00
2319296 2320288 Rdr 52
2321780 2324148 Tag 04 00
2355392 2357856 Rdr 93 20
2359412 2365300 Tag 24 6c 82 8a 40
2405694 2416222 Rdr 93 70 24 6c 82 8a 40 21 10
2417778 2422450 Tag 08 b6 dd 00
3137342 3138334 Rdr 52
3139954 3142322 Tag 04 00
3173566 3176030 Rdr 93 20
3177586 3183474 Tag 24 6c 82 8a 40
3224028 3234556 Rdr 93 70 24 6c 82 8a 40 21 10
3236048 3240720 Tag 08 b6 dd 00
3955902 3956894 Rdr 52
3958386 3960754 Tag 04 00
3992284 3994748 Rdr 93 20
3996240 4002128 Tag 24 6c 82 8a 40
4042524 4053052 Rdr 93 70 24 6c 82 8a 40 21 10
4054608 4059280 Tag 08 b6 dd 00
4775644 4776636 Rdr 52
4778192 4780560 Tag 04 00
4811932 4814396 Rdr 93 20
4815952 4821840 Tag 24 6c 82 8a 40
4862106 4872634 Rdr 93 70 24 6c 82 8a 40 21 10
4874190 4878862 Tag 08 b6 dd 00
5594010 5595002 Rdr 52
5596494 5598862 Tag 04 00
5630362 5632826 Rdr 93 20
5634382 5640270 Tag 24 6c 82 8a 40
5680696 5691224 Rdr 93 70 24 6c 82 8a 40 21 10
5692716 5697388 Tag 08 b6 dd 00
6412186 6413178 Rdr 52

So, it looks pretty good. Not quite there, fr some reason the reader does not like the rSAK or we are not picking up the answer quickly enough..

@holiman
Contributor
holiman commented Apr 4, 2014

Btw, I like it that the new trace-format is github-flavored-markdown-friendly :)

@buggii
buggii commented Apr 4, 2014

I think that user Jonor may be a good help in this kind of discussions; can someone please add him? I don't know if the mail he used to register on the forum is active but what i know is that he is good at arm programming.

-----Original Message-----
From: Martin Holst Swende notifications@github.com
To: Proxmark/proxmark3 proxmark3@noreply.github.com
Sent: ven, 04 apr 2014 11:23
Subject: Re: [proxmark3] hf mf sim after r845 (#11)

Btw, I like it that the new trace-format is github-flavored-markdown-friendly :)


Reply to this email directly or view it on GitHub:
#11 (comment)

@pwpiwi
Contributor
pwpiwi commented Apr 4, 2014

Related question; the hf 14a sim uses
static int GetIso14443aCommandFromReader(uint8_t *received, int *len, int maxLen) and does not bother to even check the field. Seems much simpler to me.. :)

Detecting the reader field is required to reset the card state when a field loss is detected.

@holiman
Contributor
holiman commented Apr 4, 2014

I dont thinks so, a wupa will reset the state for US anyway...

@holiman
Contributor
holiman commented Apr 4, 2014

Clarification. Latest code, which produced the listing above.

    if(!GetIso14443aCommandFromReader(receivedCmd, &len, 0))
    {
        break;// Button press
    }
    //cardSTATE_TO_IDLE();
    // REQ or WUP request in ANY state and WUP in HALTED state
    if (len == 1 && ((receivedCmd[0] == 0x26 && cardSTATE != MFEMUL_HALTED) || receivedCmd[0] == 0x52)) {
        selTimer = GetTickCount();
        EmSendCmdEx(rATQA, sizeof(rATQA), (receivedCmd[0] == 0x52));
        cardSTATE = MFEMUL_SELECT1;

        // init crypto block
        LED_B_OFF();
        LED_C_OFF();
        crypto1_destroy(pcs);
        cardAUTHKEY = 0xff;
        continue;
    }
@pwpiwi
Contributor
pwpiwi commented Apr 4, 2014

I dont thinks so, a wupa will reset the state for us anyway...

Yes, but a field loss should do so as well. E.g. If the "card" is temporarily removed.

@holiman
Contributor
holiman commented Apr 4, 2014

I don't think I understand why. If the card is removed,

  1. Without field-detecion, it will stall in GetIso14443aCommandFromReader until either button is pressed, or the card is put in the field again, and read is successfull. The read will most probably be a wup, and the algo will continue.
  2. WIth field-detection, it will stall in field-detector, until either button is pressed or card is put in the field again. And then it will read.

To me, it seems the exact same things will happen, but in the first case we will always read if possible, and in the second case we will only read if the signal strength is above a certain (arbitrary) threshold.

@pwpiwi
Contributor
pwpiwi commented Apr 5, 2014

The read will most probably be a wup

... which would indeed not be a problem. But often it will be REQA, which would be ignored in HALTED state.
(quite unlikely) it could even be any other command - which should be ignored after a field interruption.

if the signal strength is above a certain (arbitrary) threshold.

We only need to detect a field loss, not to measure its strength. An arbitrary threshold indeed simulates "real life". Some real cards would work with weaker fields than others.

@holiman
Contributor
holiman commented Apr 6, 2014

If we should have field detection (I'm still not fully convinced), it should be set to only signal field loss when there's absolutely no chance of false positive (i.e, when we actually may perform a successfull read). So, we'll just lower the threshold then?
I'll make some measurements, and maybe add a 'measure'-command so people can try with different pm3:s and antennas, to make sure we find a good value.

Also, I've ordered an acr122u reader now, to be able to experiment more thoroughly with simulation.

@buggii
buggii commented Apr 13, 2014

http://item.taobao.com/item.htm?spm=2013.1.0.0.4zTeH4&scm=1007.10009.518.0&id=37210916744&pvid=14d6b057-4f34-4b87-961a-9b9fa407ece1
I think it is an interface in which you put a contact smartcard and the chip inside an NFC card log "something" (only pin?all the transaction?); in practice you use the interface together with a blank rfid card (which contains a memory chip or some more complex cpu <-- more probable) and then you put in the contact smartcard; so the interface is composed by the contact smartcard hardware+rfid card in which you put a contact smartcard and then you put everything inside a contact smartacrd reader. If it logs transactions (and not only pins) it will be a great product (logging pin only is possible because the card can be programmed to log only pin-related commands).

It is produced (apparently) by the same guy who made the 1st mifare changeable UID cards (the ones requiring special command to be sector0-written).

Asper

__________ Information from ESET NOD32 Antivirus, version of virus signature database 9670 (20140412) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

@iceman1001
Contributor

Buming this issue again.
I tried the "hf mf sim" and it's not working. If that has something to do with the discussions about field-detecting or not I leave to the hardware gurus.
But its not working.

@holiman
Contributor
holiman commented Jan 18, 2015

If you'd like to help out, you could experiment with setting MF_MINFIELDV to a lower value, first much lower, and see if it works. Then set it back up, and find out where it stops working. When you have found that, post both your antenna characteristics (voltage) and what the MF_MINFIELDV threshold for working/not working is.

@iceman1001
Contributor

OK, I tried: 1000, 500, 200
It detects the tag & reader trafic but it only captures 37 bytes.
Its not the detection that is the major issue. It is the sniffing. It should have been sniffing several kb of traffic.

pm3 --> hf mf sniff l e

Executing command.
Press the key on the proxmark3 device to abort both proxmark3 and client.
Press the key on pc keyboard to abort the client.
...>
received trace len: 37 packages: 1
tag select uid:46 b8 77 b1 atqa:0x0f01 sak:0x01
RDR(1):50 00 57 cd

@holiman
Contributor
holiman commented Jan 18, 2015

This bug is about hf mf sim. It would be good if we could keep different issues apart...

@holiman
Contributor
holiman commented Jan 18, 2015

The reason being that for sim, the issue may be that the simulator finds the reader-field to be too weak, and does not start simming (or aborts sim). For sniffing, I think the mechanism is a bit different, probably with a different root cause.
If we could

a) verify that MF_MINFIELDV is indeed the problem and
b) find a empirically good value which works for most common antennas,

Then we could probably close this.

@holiman
Contributor
holiman commented Jan 18, 2015

Oh, and don't forget to submit your antenna characteristics.

@iceman1001
Contributor

The detection is working with piwi's 4000. The problem with "hf mf sim" is that it doesn't capture all traffic between reader and tag. When I compare a trace from hf14asim vs hfmfsim there is several commands that the "hfmfsim" missed. When I look at the response on the reader, the reaction is much faster with "hf14asim".. I'm sniffing a wii-portal (skylanders) and a toytag. So the visual response from the reader is shown on the screen. You can see the difference. I'm guessing here, but could it be that the "hfmfsim" is slower with the decoding parts?

MF_MINFIELDV 500, 1000, 2000, 4000

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: 11.73 V @ 13.56 MHz

@iceman1001
Contributor

You can see from the tag-response (01020304) nonce that there is reader/tag communication missing. And the time is off, so it looks like the "auth" part of the "hfmfsim" code is too slow but the reader seems to accept it and tries to read a block.

-- trace snippet --

0 | 992 | Rdr | 52 | | WUPA
2612 | 4980 | Tag | 01 0f | |
11806 | 14270 | Rdr | 93 20 | | ANTICOLL
15890 | 21714 | Tag | 46 b2 77 01 82 | |
31782 | 42246 | Rdr | 93 70 46 b2 77 01 82 d3 c9 | | ANTICOLL
43866 | 47450 | Tag | 01 77 40 | |
53454 | 58222 | Rdr | 50 00 57 cd | | HALT
200686 | 201742 | Rdr | 26 | | REQA
472450 | 473442 | Rdr | 52 | | WUPA
475062 | 477430 | Tag | 01 0f | |
485946 | 496410 | Rdr | 93 70 46 b2 77 01 82 d3 c9 | | ANTICOLL
497902 | 501486 | Tag | 01 77 40 | |
516702 | 521406 | Rdr | 60 00 f5 7b | | AUTH-A
525714 | 530450 | Tag | 01 02 03 04 | |
683342 | 688110 | Rdr | 30 00 02 a8 | | READBLOCK(0)
2321694 | 2322686 | Rdr | 52 | | WUPA
2324242 | 2326610 | Tag | 01 0f | |
2335204 | 2345668 | Rdr | 93 70 46 b2 77 01 82 d3 c9 | | ANTICOLL

@buggii
buggii commented Jan 18, 2015

Well after the auth there must be the crypto sequence, not 01020304...

-----Original Message-----
From: Iceman notifications@github.com
To: Proxmark/proxmark3 proxmark3@noreply.github.com
Cc: buggii buggii@hotmail.com
Sent: Dom, 18 Gen 2015 22:52
Subject: Re: [proxmark3] hf mf sim after r845 (#11)

You can see from the tag-response (01020304) nonce that there is reader/tag communication missing. And the time is off, so it looks like the "auth" part of the "hfmfsim" code is too slow but the reader seems to accept it and tries to read a block.

-- trace snippet --

Start | End | Src | Data (! denotes parity error) | CRC | Annotation |

---------|-----------|-----|-----------------------------------------------------------------|-----|--------------------|

   0 |       992 | Rdr | 52                                                              |     | WUPA
2612 |      4980 | Tag | 01  0f                                                          |     |

11806 | 14270 | Rdr | 93 20 | | ANTICOLL
15890 | 21714 | Tag | 46 b2 77 01 82 | |
31782 | 42246 | Rdr | 93 70 46 b2 77 01 82 d3 c9 | | ANTICOLL
43866 | 47450 | Tag | 01 77 40 | |
53454 | 58222 | Rdr | 50 00 57 cd | | HALT
200686 | 201742 | Rdr | 26 | | REQA
472450 | 473442 | Rdr | 52 | | WUPA
475062 | 477430 | Tag | 01 0f | |
485946 | 496410 | Rdr | 93 70 46 b2 77 01 82 d3 c9 | | ANTICOLL
497902 | 501486 | Tag | 01 77 40 | |
516702 | 521406 | Rdr | 60 00 f5 7b | | AUTH-A
525714 | 530450 | Tag | 01 02 03 04 | |
683342 | 688110 | Rdr | 30 00 02 a8 | | READBLOCK(0)
2321694 | 2322686 | Rdr | 52 | | WUPA
2324242 | 2326610 | Tag | 01 0f | |
2335204 | 2345668 | Rdr | 93 70 46 b2 77 01 82 d3 c9 | | ANTICOLL


Reply to this email directly or view it on GitHub:
#11 (comment)

@pwpiwi
Contributor
pwpiwi commented Jan 19, 2015

@iceman: just to be sure: your hf list is after hf mf sim?
missing tag responses (like in your case) could indeed be an indicator of a false positive field loss detection.

hf mf sim is indeed "slower". hf 14a sim uses "precompiled" responses (see prepare_tag_modulation()).

Oh, and btw, the 4000 are not "mine". They had been there before I started digging into the code and I still try to understand what the correct value would be.

@marshmellow42
Contributor

is it possible to either, log when a tag disconnects (drops below 4000) or make a command to read out that value so we can do some "testing" on the value to see if it should be adjusted ( and/or see if one antenna works a lot differently than another )?

@iceman1001
Contributor

@buggii , the tag-nonce can be anything. especially since we are in control of it.
@pwpiwi yes, the list is after the sim. and you made a compelling argument for the 4000 so I consider it yours ;) even if it was there since Roel.
@marshmellow42 the print if drops below is a good suggestion. I will try that.

@iceman1001
Contributor

Now, thats interesting. The value is no towards zero, Holiman. Good to know.

pm3 --> hf mf sim u 46b877b1
uid:46 b8 77 b1 , numreads:0, flags:2 (0x02)
#db# 4B UID: 46b877b1
#db# field dropped below limit 4000 - value 9990
#db# field dropped below limit 4000 - value 9990
#db# field dropped below limit 4000 - value 8475
#db# field dropped below limit 4000 - value 10022
#db# field dropped below limit 4000 - value 10022
#db# field dropped below limit 4000 - value 5639
#db# field dropped below limit 4000 - value 9603
#db# field dropped below limit 4000 - value 9603
#db# field dropped below limit 4000 - value 9055
#db# field dropped below limit 4000 - value 7541
#db# field dropped below limit 4000 - value 9055
#db# field dropped below limit 4000 - value 6638
#db# field dropped below limit 4000 - value 7541
#db# field dropped below limit 4000 - value 4737
#db# field dropped below limit 4000 - value 9603
#db# field dropped below limit 4000 - value 4253
#db# field dropped below limit 4000 - value 9055
#db# field dropped below limit 4000 - value 7218
#db# field dropped below limit 4000 - value 9055
#db# field dropped below limit 4000 - value 9055
#db# field dropped below limit 4000 - value 4576
#db# field dropped below limit 4000 - value 8733
#db# field dropped below limit 4000 - value 9055
#db# field dropped below limit 4000 - value 8991
#db# field dropped below limit 4000 - value 9055
#db# Emulator stopped. Tracing: 0 trace length: 2997

@iceman1001
Contributor

Tried: 6000.

pm3 --> hf mf sim u 46b877b1 x
uid:46 b8 77 b1 , numreads:0, flags:10 (0x0a)
#db# 4B UID: 46b877b1
#db# field dropped below limit 6000 - value 9796
#db# field dropped below limit 6000 - value 8701
#db# field dropped below limit 6000 - value 8991
#db# Failed to obtain two AR/NR pairs!
#db# Emulator stopped. Tracing: 0 trace length: 2994
pm3 --> hf list 14a
Recorded Activity

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 |       992 | Rdr | 52                                                              |     | WUPA
  2612 |      4980 | Tag | 01  0f                                                          |     |
 12450 |     14914 | Rdr | 93  20                                                          |     | ANTICOLL
 16598 |     22486 | Tag | 46  b8  77  b1  38                                              |     |
 32292 |     42756 | Rdr | 93  70  46  b8  77  b1  38  c2  35                              |     | ANTICOLL
 44376 |     47960 | Tag | 01  77  40                                                      |     |
 54508 |     59276 | Rdr | 50  00  57  cd                                                  |     | HALT
200748 |    201804 | Rdr | 26                                                              |     | REQA
472640 |    473632 | Rdr | 52                                                              |     | WUPA
475188 |    477556 | Tag | 01  0f                                                          |     |
485978 |    496442 | Rdr | 93  70  46  b8  77  b1  38  c2  35                              |     | ANTICOLL
497934 |    501518 | Tag | 01  77  40                                                      |     |
517054 |    521758 | Rdr | 60  00  f5  7b                                                  |     | AUTH-A
526258 |    530994 | Tag | 01  02  03  04                                                  |     |
683964 |    688732 | Rdr | 30  00  02  a8                                                  |     | READBLOCK(0)

2308316 | 2309308 | Rdr | 52 | | WUPA
2310928 | 2313296 | Tag | 01 0f | |
2321600 | 2332064 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
2333748 | 2337332 | Tag | 01 77 40 | |
2352420 | 2357124 | Rdr | 60 00 f5 7b | | AUTH-A
2361560 | 2366296 | Tag | 01 02 03 04 | |
2518812 | 2523580 | Rdr | 30 00 02 a8 | | READBLOCK(0)
4143650 | 4144642 | Rdr | 52 | | WUPA
4146262 | 4148630 | Tag | 01 0f | |
4157084 | 4167548 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
4169104 | 4172688 | Tag | 01 77 40 | |
4188294 | 4192998 | Rdr | 60 00 f5 7b | | AUTH-A
4197498 | 4202234 | Tag | 01 02 03 04 | |
4355164 | 4359932 | Rdr | 30 00 02 a8 | | READBLOCK(0)
5979262 | 5980254 | Rdr | 52 | | WUPA
5981874 | 5984242 | Tag | 01 0f | |
5992612 | 6003076 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
6004696 | 6008280 | Tag | 01 77 40 | |
6023744 | 6028448 | Rdr | 60 00 f5 7b | | AUTH-A
6032948 | 6037684 | Tag | 01 02 03 04 | |
6190028 | 6194796 | Rdr | 30 00 02 a8 | | READBLOCK(0)
7814776 | 7815768 | Rdr | 52 | | WUPA
7817324 | 7819692 | Tag | 01 0f | |
7828352 | 7838816 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
7840436 | 7844020 | Tag | 01 77 40 | |
7859932 | 7864636 | Rdr | 60 00 f5 7b | | AUTH-A
7868816 | 7873552 | Tag | 01 02 03 04 | |
8026300 | 8031068 | Rdr | 30 00 02 a8 | | READBLOCK(0)
9650210 | 9651202 | Rdr | 52 | | WUPA
9652822 | 9655190 | Tag | 01 0f | |
9664348 | 9674812 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
9676304 | 9679888 | Tag | 01 77 40 | |
9695032 | 9699736 | Rdr | 60 00 f5 7b | | AUTH-A
9704044 | 9708780 | Tag | 01 02 03 04 | |
9861452 | 9866220 | Rdr | 30 00 02 a8 | | READBLOCK(0)
11485950 | 11486942 | Rdr | 52 | | WUPA
11488562 | 11490930 | Tag | 01 0f | |
11499556 | 11510020 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
11511640 | 11515224 | Tag | 01 77 40 | |
11530176 | 11534880 | Rdr | 60 00 f5 7b | | AUTH-A
11539380 | 11544116 | Tag | 01 02 03 04 | |
11696428 | 11701196 | Rdr | 30 00 02 a8 | | READBLOCK(0)
14534014 | 14535006 | Rdr | 52 | | WUPA
14536626 | 14538994 | Tag | 01 0f | |
14546040 | 14548504 | Rdr | 93 20 | | ANTICOLL
14550124 | 14556012 | Tag | 46 b8 77 b1 38 | |
14566022 | 14576486 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
14578170 | 14581754 | Tag | 01 77 40 | |
14587996 | 14592764 | Rdr | 50 00 57 cd | | HALT
14735522 | 14736514 | Rdr | 52 | | WUPA
14738134 | 14740502 | Tag | 01 0f | |
14749404 | 14759868 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
14761360 | 14764944 | Tag | 01 77 40 | |
14770700 | 14775468 | Rdr | 50 00 57 cd | | HALT
14912060 | 14913116 | Rdr | 26 | | REQA
15184290 | 15185282 | Rdr | 52 | | WUPA
15186902 | 15189270 | Tag | 01 0f | |
15198108 | 15208572 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
15210128 | 15213712 | Tag | 01 77 40 | |
15219516 | 15224284 | Rdr | 50 00 57 cd | | HALT
15360812 | 15361868 | Rdr | 26 | | REQA
15496924 | 15497916 | Rdr | 52 | | WUPA
15499536 | 15501904 | Tag | 01 0f | |
15503614 | 15504606 | Rdr | 52 | | WUPA
15506226 | 15508594 | Tag | 01 0f | |
15517504 | 15527968 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
15529652 | 15533236 | Tag | 01 77 40 | |
15538956 | 15543724 | Rdr | 50 00 57 cd | | HALT
15687052 | 15688108 | Rdr | 26 | | REQA
15959324 | 15960316 | Rdr | 52 | | WUPA
15961872 | 15964240 | Tag | 01 0f | |
15973092 | 15983556 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
15985240 | 15988824 | Tag | 01 77 40 | |
15995084 | 15999852 | Rdr | 50 00 57 cd | | HALT
16135804 | 16136860 | Rdr | 26 | | REQA
16272070 | 16273062 | Rdr | 52 | | WUPA
16274682 | 16277050 | Tag | 01 0f | |
16278692 | 16279684 | Rdr | 52 | | WUPA
16281304 | 16283672 | Tag | 01 0f | |
16292572 | 16303036 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
16304528 | 16308112 | Tag | 01 77 40 | |
16313916 | 16318684 | Rdr | 50 00 57 cd | | HALT
16462252 | 16463308 | Rdr | 26 | | REQA
16734308 | 16735300 | Rdr | 52 | | WUPA
16736856 | 16739224 | Tag | 01 0f | |
16748058 | 16758522 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
16760078 | 16763662 | Tag | 01 77 40 | |
16769468 | 16774236 | Rdr | 50 00 57 cd | | HALT
16910796 | 16911852 | Rdr | 26 | | REQA
17047160 | 17048152 | Rdr | 52 | | WUPA
17049708 | 17052076 | Tag | 01 0f | |
17053944 | 17054936 | Rdr | 52 | | WUPA
17056492 | 17058860 | Tag | 01 0f | |
17067812 | 17078276 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
17079896 | 17083480 | Tag | 01 77 40 | |
17089980 | 17094748 | Rdr | 50 00 57 cd | | HALT
17237148 | 17238204 | Rdr | 26 | | REQA
17509496 | 17510488 | Rdr | 52 | | WUPA
17512044 | 17514412 | Tag | 01 0f | |
17523042 | 17533506 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
17535190 | 17538774 | Tag | 01 77 40 | |
17544428 | 17549196 | Rdr | 50 00 57 cd | | HALT
17685740 | 17686796 | Rdr | 26 | | REQA
17821988 | 17822980 | Rdr | 52 | | WUPA
17824600 | 17826968 | Tag | 01 0f | |
17828642 | 17829634 | Rdr | 52 | | WUPA
17831254 | 17833622 | Tag | 01 0f | |
17842458 | 17852922 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
17854478 | 17858062 | Tag | 01 77 40 | |
17864124 | 17868892 | Rdr | 50 00 57 cd | | HALT
18012188 | 18013244 | Rdr | 26 | | REQA
18284444 | 18285436 | Rdr | 52 | | WUPA
18286992 | 18289360 | Tag | 01 0f | |
18298074 | 18308538 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
18310030 | 18313614 | Tag | 01 77 40 | |
18319420 | 18324188 | Rdr | 50 00 57 cd | | HALT
18460876 | 18461932 | Rdr | 26 | | REQA
18732992 | 18733984 | Rdr | 52 | | WUPA
18735540 | 18737908 | Tag | 01 0f | |
18746780 | 18757244 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
18758800 | 18762384 | Tag | 01 77 40 | |
18768172 | 18772940 | Rdr | 50 00 57 cd | | HALT
18909516 | 18910572 | Rdr | 26 | | REQA
19045724 | 19046716 | Rdr | 52 | | WUPA
19048336 | 19050704 | Tag | 01 0f | |
19052378 | 19053370 | Rdr | 52 | | WUPA
19054990 | 19057358 | Tag | 01 0f | |
19066240 | 19076704 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
19078324 | 19081908 | Tag | 01 77 40 | |
19088428 | 19093196 | Rdr | 50 00 57 cd | | HALT
19235852 | 19236908 | Rdr | 26 | | REQA
19508094 | 19509086 | Rdr | 52 | | WUPA
19510706 | 19513074 | Tag | 01 0f | |
19521982 | 19532446 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
19534130 | 19537714 | Tag | 01 77 40 | |
19544572 | 19549340 | Rdr | 50 00 57 cd | | HALT
19684636 | 19685692 | Rdr | 26 | | REQA
19820800 | 19821792 | Rdr | 52 | | WUPA
19823412 | 19825780 | Tag | 01 0f | |
19827584 | 19828576 | Rdr | 52 | | WUPA
19830196 | 19832564 | Tag | 01 0f | |
19841414 | 19851878 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
19853562 | 19857146 | Tag | 01 77 40 | |
19862860 | 19867628 | Rdr | 50 00 57 cd | | HALT
20010892 | 20011948 | Rdr | 26 | | REQA
20283170 | 20284162 | Rdr | 52 | | WUPA
20285782 | 20288150 | Tag | 01 0f | |
20297016 | 20307480 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
20308972 | 20312556 | Tag | 01 77 40 | |
20318396 | 20323164 | Rdr | 50 00 57 cd | | HALT
20459724 | 20460780 | Rdr | 26 | | REQA
20595802 | 20596794 | Rdr | 52 | | WUPA
20598414 | 20600782 | Tag | 01 0f | |
20602458 | 20603450 | Rdr | 52 | | WUPA
20605070 | 20607438 | Tag | 01 0f | |
20616162 | 20626626 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
20628310 | 20631894 | Tag | 01 77 40 | |
20638028 | 20642796 | Rdr | 50 00 57 cd | | HALT
20772380 | 20773436 | Rdr | 26 | | REQA
21044570 | 21045562 | Rdr | 52 | | WUPA
21047182 | 21049550 | Tag | 01 0f | |
21058402 | 21068866 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
21070550 | 21074134 | Tag | 01 77 40 | |
21080380 | 21085148 | Rdr | 50 00 57 cd | | HALT
21221116 | 21222172 | Rdr | 26 | | REQA
21357220 | 21358212 | Rdr | 52 | | WUPA
21359832 | 21362200 | Tag | 01 0f | |
21364002 | 21364994 | Rdr | 52 | | WUPA
21366614 | 21368982 | Tag | 01 0f | |
21377818 | 21388282 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
21389838 | 21393422 | Tag | 01 77 40 | |
21399228 | 21403996 | Rdr | 50 00 57 cd | | HALT
21547484 | 21548540 | Rdr | 26 | | REQA
21819556 | 21820548 | Rdr | 52 | | WUPA
21822168 | 21824536 | Tag | 01 0f | |
21833400 | 21843864 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
21845356 | 21848940 | Tag | 01 77 40 | |
21854764 | 21859532 | Rdr | 50 00 57 cd | | HALT
21996092 | 21997148 | Rdr | 26 | | REQA
22132316 | 22133308 | Rdr | 52 | | WUPA
22134928 | 22137296 | Tag | 01 0f | |
22138970 | 22139962 | Rdr | 52 | | WUPA
22141582 | 22143950 | Tag | 01 0f | |
22152832 | 22163296 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
22164916 | 22168500 | Tag | 01 77 40 | |
22174956 | 22179724 | Rdr | 50 00 57 cd | | HALT
22322540 | 22323596 | Rdr | 26 | | REQA
22594686 | 22595678 | Rdr | 52 | | WUPA
22597298 | 22599666 | Tag | 01 0f | |
22608574 | 22619038 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
22620722 | 22624306 | Tag | 01 77 40 | |
22630588 | 22635356 | Rdr | 50 00 57 cd | | HALT
22771212 | 22772268 | Rdr | 26 | | REQA
22907390 | 22908382 | Rdr | 52 | | WUPA
22910002 | 22912370 | Tag | 01 0f | |
22914174 | 22915166 | Rdr | 52 | | WUPA
22916786 | 22919154 | Tag | 01 0f | |
22928056 | 22938520 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
22940012 | 22943596 | Tag | 01 77 40 | |
22949692 | 22954460 | Rdr | 50 00 57 cd | | HALT
23097420 | 23098476 | Rdr | 26 | | REQA
23369692 | 23370684 | Rdr | 52 | | WUPA
23372304 | 23374672 | Tag | 01 0f | |
23383352 | 23393816 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
23395308 | 23398892 | Tag | 01 77 40 | |
23404972 | 23409740 | Rdr | 50 00 57 cd | | HALT
23546188 | 23547244 | Rdr | 26 | | REQA
23682340 | 23683332 | Rdr | 52 | | WUPA
23684952 | 23687320 | Tag | 01 0f | |
23688902 | 23689894 | Rdr | 52 | | WUPA
23691514 | 23693882 | Tag | 01 0f | |
23702718 | 23713182 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
23714866 | 23718450 | Tag | 01 77 40 | |
23724412 | 23729180 | Rdr | 50 00 57 cd | | HALT
23872492 | 23873548 | Rdr | 26 | | REQA
24144674 | 24145666 | Rdr | 52 | | WUPA
24147286 | 24149654 | Tag | 01 0f | |
24158336 | 24168800 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
24170420 | 24174004 | Tag | 01 77 40 | |
24180220 | 24184988 | Rdr | 50 00 57 cd | | HALT
24321228 | 24322284 | Rdr | 26 | | REQA
24457342 | 24458334 | Rdr | 52 | | WUPA
24459954 | 24462322 | Tag | 01 0f | |
24464034 | 24465026 | Rdr | 52 | | WUPA
24466646 | 24469014 | Tag | 01 0f | |
24477752 | 24488216 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
pm3 -->

@iceman1001
Contributor

the more I look at it, the more it looks like somewhere the happenings just after Auth-A, since the reader is responding very fast. (when I look at a sniffed trace) It seems to be too slow.

@holiman
Contributor
holiman commented Jan 19, 2015

Hmm...
" field dropped below limit 4000 - value 9990"

I don't understand.. 9990 is above 4000... ?? Or is one of them hex and the other base10 ?
Also, one thing to be aware of is debug printouts in the middle of tag to reader communications. The usb operation stalls the arm for a while, so be careful not to disturb the sequence with too many of those.

Also.. My original report is that this happened after r845. r845 had nothing to do with HF_MINFIELD, but something else appears to have happened there.

@iceman1001
Contributor

Looking at the Google.code svn.. It looks like Holimans r841 -> r842 made some major changes in the "hf mf sim".. the r843,r844, r845 is minor changes.

@holiman
Contributor
holiman commented Jan 19, 2015

r845 is minor?? https://code.google.com/p/proxmark3/source/detail?r=845

Anyway, I don't want to blame piwi or something, but I tested each revision and came to that conclusion. Don't have any more notes/evidence than are already in this bug report though. It's great if more minds are focusing on it.

@iceman1001
Contributor

Well, it is minor if you look inside the "Mifare1ksim" function compared to your r842 :)
It is major looking at other stuff.. However, he added traces... it could be that which is messing with the timing.
Or the "Emxxxxx" sending commands...

@holiman
Contributor
holiman commented Jan 19, 2015

There's quite some FPGA-action aswell....

@iceman1001
Contributor

Looking at the frame-delay-times..
A) hf mf sim
B) hf 14a sim

For A it's around an average 1620, but for the Auth is 4500
For B it's around an average 1200, even for a Auth..

It looks like the Auth-response takes too long time

--- SNIPP AStart End Src Data (! denotes parity error) CRC Annotation
     0 |       992 | Rdr | 52                                                              |     | WUPA
   992 |      2548 |     | fdt (Frame Delay Time): 1556
  2548 |      4916 | Tag | 01  0f                                                          |     |
 11710 |     14174 | Rdr | 93  20                                                          |     | ANTICOLL
 14174 |     15858 |     | fdt (Frame Delay Time): 1684
 15858 |     21746 | Tag | 46  b8  77  b1  38                                              |     |
 31778 |     42242 | Rdr | 93  70  46  b8  77  b1  38  c2  35                              |     | ANTICOLL
 42242 |     43926 |     | fdt (Frame Delay Time): 1684
 43926 |     47510 | Tag | 01  77  40                                                      |     |
 53436 |     58204 | Rdr | 50  00  57  cd                                                  |     | HALT
200704 |    201696 | Rdr | 52                                                              |     | WUPA
201696 |    203252 |     | fdt (Frame Delay Time): 1556
203252 |    205620 | Tag | 01  0f                                                          |     |
214436 |    224900 | Rdr | 93  70  46  b8  77  b1  38  c2  35                              |     | ANTICOLL
224900 |    226584 |     | fdt (Frame Delay Time): 1684
226584 |    230168 | Tag | 01  77  40                                                      |     |
236700 |    241468 | Rdr | 50  00  57  cd                                                  |     | HALT
377150 |    378142 | Rdr | 52                                                              |     | WUPA
378142 |    379762 |     | fdt (Frame Delay Time): 1620
379762 |    382130 | Tag | 01  0f                                                          |     |
513030 |    514022 | Rdr | 52                                                              |     | WUPA
514022 |    515642 |     | fdt (Frame Delay Time): 1620
515642 |    518010 | Tag | 01  0f                                                          |     |
526554 |    537018 | Rdr | 93  70  46  b8  77  b1  38  c2  35                              |     | ANTICOLL
537018 |    538574 |     | fdt (Frame Delay Time): 1556
538574 |    542158 | Tag | 01  77  40                                                      |     |
557474 |    562178 | Rdr | 60  00  f5  7b                                                  |     | AUTH-A
562178 |    566678 |     | fdt (Frame Delay Time): 4500
566678 |    571414 | Tag | 01  02  03  04                                                  |     |
724236 |    729004 | Rdr | 30  00  02  a8                                                  |     | READBLOCK(0)

1410872 | 1411864 | Rdr | 52 | | WUPA
1411864 | 1413420 | | fdt (Frame Delay Time): 1556
1413420 | 1415788 | Tag | 01 0f | |
1424638 | 1435102 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
1435102 | 1436658 | | fdt (Frame Delay Time): 1556
1436658 | 1440242 | Tag | 01 77 40 | |
1446348 | 1451116 | Rdr | 50 00 57 cd | | HALT
1587372 | 1588428 | Rdr | 26 | | REQA
1723710 | 1724702 | Rdr | 52 | | WUPA
1724702 | 1726322 | | fdt (Frame Delay Time): 1620
1726322 | 1728690 | Tag | 01 0f | |
1730752 | 1731744 | Rdr | 52 | | WUPA
1731744 | 1733364 | | fdt (Frame Delay Time): 1620
1733364 | 1735732 | Tag | 01 0f | |
1744376 | 1754840 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
1754840 | 1756332 | | fdt (Frame Delay Time): 1492
1756332 | 1759916 | Tag | 01 77 40 | |
1766316 | 1771084 | Rdr | 50 00 57 cd | | HALT
1900108 | 1901164 | Rdr | 26 | | REQA
2171968 | 2172960 | Rdr | 52 | | WUPA
2172960 | 2174580 | | fdt (Frame Delay Time): 1620
2174580 | 2176948 | Tag | 01 0f | |
2185508 | 2195972 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
2195972 | 2197656 | | fdt (Frame Delay Time): 1684
2197656 | 2201240 | Tag | 01 77 40 | |
2216190 | 2220894 | Rdr | 60 00 f5 7b | | AUTH-A
2220894 | 2225266 | | fdt (Frame Delay Time): 4372
2225266 | 2230002 | Tag | 01 02 03 04 | |
2382940 | 2387708 | Rdr | 30 00 02 a8 | | READBLOCK(0)
4021020 | 4022012 | Rdr | 52 | | WUPA
4022012 | 4023632 | | fdt (Frame Delay Time): 1620
4023632 | 4026000 | Tag | 01 0f | |
4034588 | 4045052 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
4045052 | 4046544 | | fdt (Frame Delay Time): 1492
4046544 | 4050128 | Tag | 01 77 40 | |
4065508 | 4070212 | Rdr | 60 00 f5 7b | | AUTH-A
4070212 | 4074648 | | fdt (Frame Delay Time): 4436
4074648 | 4079384 | Tag | 01 02 03 04 | |
4232236 | 4237004 | Rdr | 30 00 02 a8 | | READBLOCK(0)
5870342 | 5871334 | Rdr | 52 | | WUPA
5871334 | 5872954 | | fdt (Frame Delay Time): 1620
5872954 | 5875322 | Tag | 01 0f | |
5883846 | 5894310 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
5894310 | 5895994 | | fdt (Frame Delay Time): 1684
5895994 | 5899578 | Tag | 01 77 40 | |
5915298 | 5920002 | Rdr | 60 00 f5 7b | | AUTH-A
5920002 | 5924502 | | fdt (Frame Delay Time): 4500
5924502 | 5929238 | Tag | 01 02 03 04 | |
6081804 | 6086572 | Rdr | 30 00 02 a8 | | READBLOCK(0)
7719460 | 7720452 | Rdr | 52 | | WUPA
7720452 | 7722008 | | fdt (Frame Delay Time): 1556
7722008 | 7724376 | Tag | 01 0f | |
7732862 | 7743326 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
7743326 | 7745010 | | fdt (Frame Delay Time): 1684
7745010 | 7748594 | Tag | 01 77 40 | |
7882624 | 7883616 | Rdr | 52 | | WUPA
7883616 | 7885172 | | fdt (Frame Delay Time): 1556
7885172 | 7887540 | Tag | 01 0f | |
7896100 | 7906564 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
7906564 | 7908248 | | fdt (Frame Delay Time): 1684
7908248 | 7911832 | Tag | 01 77 40 | |
7927004 | 7931708 | Rdr | 60 00 f5 7b | | AUTH-A
7931708 | 7936080 | | fdt (Frame Delay Time): 4372
7936080 | 7940816 | Tag | 01 02 03 04 | |
8093532 | 8098300 | Rdr | 30 00 02 a8 | | READBLOCK(0)
9731682 | 9732674 | Rdr | 52 | | WUPA
9732674 | 9734294 | | fdt (Frame Delay Time): 1620

------ SNIPPET B
567480 | 568472 | Rdr | 52 | | WUPA
568472 | 569708 | | fdt (Frame Delay Time): 1236
569708 | 572076 | Tag | 01 0f | |
703634 | 704626 | Rdr | 52 | | WUPA
704626 | 705862 | | fdt (Frame Delay Time): 1236
705862 | 708230 | Tag | 01 0f | |
717190 | 727654 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
727654 | 728826 | | fdt (Frame Delay Time): 1172
728826 | 732410 | Tag | 01 77 40 | |
748096 | 752800 | Rdr | 60 00 f5 7b | | AUTH-A
752800 | 753972 | | fdt (Frame Delay Time): 1172
753972 | 758708 | Tag | 01 01 01 01 | |
911644 | 916412 | Rdr | 30 00 02 a8 | | READBLOCK(0)
916412 | 918928 | | fdt (Frame Delay Time): 2516
918928 | 937424 | Tag | 46 b8 77 b1 38 81 01 0f c3 85 14 96 59 10 18 12 | !crc|
1070740 | 1071732 | Rdr | 52 | | WUPA

@pwpiwi
Contributor
pwpiwi commented Jan 25, 2015

Its a bit off topic, but nevertheless: fdt needs to be exact for WUPA, REQA, SELECT and ANTICOLL only (1172 or 1236). For all other commands (e.g. AUTH) it can be n * 64 + 20. Any n>18 is OK.

hf 14a sim is faster because it uses pre-encoded tag answers (even for AUTH, which it doesn't fully support). hf mf sim encodes on the fly - which is too slow.

This would only be a problem if the reader is very fishy about the tag's answer timing on WUPA, REQA, SELECT and ANTICOLL.

@iceman1001
Contributor

Is there no upper limit for ( n * 64 + 20 ) before the reader resets the communication and starts over?

I don't think the reader is very strict, seeing that it continue down the select-path. However our simulated response to the reader and answer is never caught in the trace. I can't figure out if it is sent or the reader resets before it receives it.

@pwpiwi
Contributor
pwpiwi commented Jan 26, 2015

You are trailing off again. This is about hf mf sim and MF_MINFIELDV, not about the Skylander toy.

@iceman1001
Contributor

Well, I disagree with you there.
It is about "hf mf sim" not working. the mf_ minfieldv issue is the sidethread.

When I test the "hf mf sim" against a reader (in this case the portal) the command is not working.
No more to it. It seems to be like that since r845, I can't verify it so I let that stand for @holiman

I only want the "hf mf sim" command to work against any random selected reader. If someone here who can give insights to get it back to working that would be nice.

@pwpiwi
Contributor
pwpiwi commented Jan 26, 2015

@iceman0001: I just want to propose not to use tags and readers which we currently don't fully unterstand if we are looking for sim or snoop issues. How should we know if unexpected behaviour isn't caused by tag or reader?

@iceman1001
Contributor

Well, given that this issue was registrated on the 2 april 2014, I would like to wait for someone who has a standard reader available and wants to look into it but it seems not to be too much interest in it given the start date. But I guess you are right, I'll wait until someone else looks into this issue again. However, meanwhile it sure would be nice of the one who did r845 to give some feedback on what was done.

@holiman
Contributor
holiman commented Jan 26, 2015

I re-read my original report, and the steps I took to investigate. I found one odd thing, which I also mentioned earlier, but which we kind of dropped.

Currently, in mf sim. We do a field-detection:

    // find reader field
    // Vref = 3300mV, and an 10:1 voltage divider on the input
    // can measure voltages up to 33000 mV
    if (cardSTATE == MFEMUL_NOFIELD) {
        vHf = (33000 * AvgAdc(ADC_CHAN_HF)) >> 10;
        if (vHf > MF_MINFIELDV) {
            cardSTATE_TO_IDLE();
            LED_A_ON();
        }
    } 

If the field detection is ok, it continues: reading the tag, using the method EmGetCmd:

    res = EmGetCmd(receivedCmd, &len, receivedCmd_par);

The method EmGetCmd also checks the reader field, using what appears to be a more complex/elaborate construct:

// Set ADC to read field strength
AT91C_BASE_ADC->ADC_CR = AT91C_ADC_SWRST;
AT91C_BASE_ADC->ADC_MR =
            ADC_MODE_PRESCALE(32) |
            ADC_MODE_STARTUP_TIME(16) |
            ADC_MODE_SAMPLE_HOLD_TIME(8);
AT91C_BASE_ADC->ADC_CHER = ADC_CHANNEL(ADC_CHAN_HF);
// start ADC
AT91C_BASE_ADC->ADC_CR = AT91C_ADC_START;
 [...] 
if (AT91C_BASE_ADC->ADC_SR & ADC_END_OF_CONVERSION(ADC_CHAN_HF)) {
        analogCnt++;
        analogAVG += AT91C_BASE_ADC->ADC_CDR[ADC_CHAN_HF];
        AT91C_BASE_ADC->ADC_CR = AT91C_ADC_START;
        if (analogCnt >= 32) {
            if ((33000 * (analogAVG / analogCnt) >> 10) < MF_MINFIELDV) {
                vtime = GetTickCount();
                if (!timer) timer = vtime;
                // 50ms no field --> card to idle state
                if (vtime - timer > 50) return 2;
            } else
                if (timer) timer = 0;
            analogCnt = 0;
            analogAVG = 0;
        }
    } 

Thus, for some reason, we are using two different implementations of checking if the field exists. If a field-loss is detected by EmGetCmd, we continue with the same (?) state as if it had been happened in the check before:

    res = EmGetCmd(receivedCmd, &len, receivedCmd_par);
    if (res == 2) { //Field is off!
        cardSTATE = MFEMUL_NOFIELD;
        LEDsoff();
        continue;

From what I could tell in my earlier comment on April 3rd, I got better results with only the latter field-check.

Any ideas why there are two such checks?

I'm a bit busy with other parts of the code now, but I'll try to experiment a bit more with this when I get the time.

@iceman1001
Contributor

I've divided into the EmSendCmd route.

EmSendCmd -> EmSendCmdExPar -> EmSendCmd14443aRaw..
Where I find https://github.com/Proxmark/proxmark3/blob/master/armsrc/iso14443a.c#L1513
What is the purpose of this double while?

// clear receiving shift register and holding register
while(!(AT91C_BASE_SSC->SSC_SR & AT91C_SSC_RXRDY));
b = AT91C_BASE_SSC->SSC_RHR; (void) b;
while(!(AT91C_BASE_SSC->SSC_SR & AT91C_SSC_RXRDY));
b = AT91C_BASE_SSC->SSC_RHR; (void) b;

@pwpiwi
Contributor
pwpiwi commented Jan 27, 2015

@holiman: in fact both checks are implemented roughly the same way. Have a look at AvgAdc(). However AvgAdc() waits for 32 samples before it returns the average. The implementation in EmGetCmd doesn't.

@iceman1001: both while loops do the same: they wait for the READY signal, the following command then reads the holding register. Both shift and holding register may contain rubbish which is cleared by two reads.

@iceman1001
Contributor

@pwpiwi but why are they the same? On other places I've seen "SSC_RHR" / "SSC_THR" being cleared.

@pwpiwi
Contributor
pwpiwi commented Jan 27, 2015

On other places we just clear the already triggered RDY signals to get the timing right. Here we want to get rid of void data in the registers.

@pwpiwi
Contributor
pwpiwi commented Jan 29, 2015

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
Contributor

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
Contributor

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
Contributor
pwpiwi commented Jan 29, 2015

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
buggii commented Jan 29, 2015

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:
#11 (comment)

@pwpiwi
Contributor
pwpiwi commented Jan 29, 2015

I cannot afford two PM3s 😃 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
Contributor
holiman commented Jan 29, 2015

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):
saleae_2

Here it is again, with a bit more zoom:
saleae_3

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
Contributor
pwpiwi commented Jan 29, 2015

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
Contributor
holiman commented Jan 31, 2015

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
Contributor
pwpiwi commented Feb 1, 2015

Thanks holiman! I did send you an upload link.

@holiman
Contributor
holiman commented Feb 1, 2015

Files uploaded...

@pwpiwi
Contributor
pwpiwi commented Feb 1, 2015

Files downloaded...

@pwpiwi
Contributor
pwpiwi commented Feb 1, 2015
  • 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
Contributor
holiman commented Feb 1, 2015

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
Contributor
pwpiwi commented Feb 2, 2015

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
Contributor
holiman commented Feb 2, 2015

@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
Contributor
holiman commented Feb 2, 2015

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

extra_bit

That extra bit is clearly shown on the above right side

@holiman
Contributor
holiman commented Feb 2, 2015

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

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
Contributor
holiman commented Feb 2, 2015

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.

zoom_missing_tagresp

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
Contributor
pwpiwi commented Feb 2, 2015

... 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
Contributor
holiman commented Feb 2, 2015

... 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
Contributor
pwpiwi commented Feb 2, 2015

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
Contributor
holiman commented Feb 2, 2015

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
Contributor
pwpiwi commented Feb 2, 2015

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 😄)

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
Contributor
holiman commented Feb 2, 2015

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
Contributor
pwpiwi commented Feb 2, 2015

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

@pwpiwi
Contributor
pwpiwi commented Feb 3, 2015

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
Contributor
holiman commented Feb 3, 2015

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
Contributor
pwpiwi commented Feb 3, 2015

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
Contributor
holiman commented Feb 3, 2015

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
Contributor
holiman commented Feb 3, 2015

Nevermind, that's only done if in MFEMUL_NOFIELD

@holiman
Contributor
holiman commented Feb 3, 2015

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.
other_antenna_pm3_above_tag_below

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:
tag_response

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
Contributor
holiman commented Feb 3, 2015

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.

bad_sim_antenna

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
Contributor
pwpiwi commented Feb 4, 2015

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
Contributor
holiman commented Feb 4, 2015

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
Contributor
pwpiwi commented Feb 4, 2015

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
Contributor
holiman commented Feb 4, 2015

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

@pwpiwi
Contributor
pwpiwi commented Feb 4, 2015

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
Contributor
pwpiwi commented Feb 4, 2015

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
Contributor
holiman commented Feb 4, 2015

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
Contributor
pwpiwi commented Feb 4, 2015

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
Contributor
pwpiwi commented Feb 5, 2015

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
Contributor

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

@pwpiwi
Contributor
pwpiwi commented Feb 5, 2015

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

@iceman1001
Contributor

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

@holiman
Contributor
holiman commented Feb 5, 2015

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
Contributor
holiman commented Feb 5, 2015

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
Contributor
pwpiwi commented Feb 5, 2015

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
Contributor
pwpiwi commented Feb 5, 2015

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
Contributor
holiman commented Feb 5, 2015

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.

@holiman
Contributor
holiman commented Feb 5, 2015

I committed the first fix. I'm thinking of adding some way to lower the HF_MINFIELD threshold from the client-side.

@holiman
Contributor
holiman commented Feb 5, 2015

@pwpiwi , to be clear; you're talking about the current hf list 14a as opposed to the old one? The old list function wasn't very robust when data was malformed, e.g. zero-length data and stuff like that.

@pwpiwi
Contributor
pwpiwi commented Feb 6, 2015

yes, I do have the current hf list 14a. Please find below some examples of what I think are the results of a wrong synchronization in the Miller decoder. The wrong reader commands are marked in bold.

Example 1 (repeated Rdr 26, Tag 0400):

2687944 2689000 Rdr 26
2690556 2692924 Tag 04 00
2700424 2702888 Rdr 93 20
2704636 2710460 Tag aa bb cc dd 00
2718244 2728772 Rdr 93 70 aa bb cc dd 00 03 9e
2730328 2733848 Tag 08 b6 dd
2842178 2846946 Rdr e0 81 b8 62
2848310 2848950 Tag 04
3188508 3189564 Rdr 26
3190928 3193296 Tag 04 00
5100224 5101280 Rdr 26
5102516 5104884 Tag 04 00
5488128 5489184 Rdr 26
5490612 5492980 Tag 04 00
7399874 7400930 Rdr 26
7402166 7404534 Tag 04 00
7787840 7788896 Rdr 26
7790260 7792628 Tag 04 00
7800130 7802594 Rdr 93 20
7804214 7810038 Tag aa bb cc dd 00

Example 2 (weird Reader response after RATS):

7941824 7946592 Rdr e0 81 b8 62
7947956 7948596 Tag 04
8288462 8288814 Rdr 02
10186398 10187454 Rdr 26
10188818 10191186 Tag 04 00

Example 3 (weird Reader response after SELECT):

11075046 11076102 Rdr 26
11077594 11079962 Tag 04 00
11087462 11089926 Rdr 93 20
11091674 11097498 Tag aa bb cc dd 00
11105346 11115874 Rdr 93 70 aa bb cc dd 00 03 9e
11117366 11120886 Tag 08 b6 dd
11562542 11563150 Rdr 09
12649190 12650246 Rdr 26
12651738 12654106 Tag 04 00

Example 4 (weird Reader response after AUTH):

27660638 27665342 Rdr 60 00 f5 7b
27669522 27674258 Tag 01 02 03 04
27850910 27860286 Rdr 22 a2 0e 05 7f 8f d9 71 !crc
28525518 28525870 Rdr 02
29260964 29262020 Rdr 26
29263320 29265688 Tag 04 00

Examples 5 and 6 (corrupted AUTH (?) after SELECT)

34856192 34857248 Rdr 26
34858676 34861044 Tag 04 00
34868544 34871008 Rdr 93 20
34872628 34878452 Tag aa bb cc dd 00
34886266 34896794 Rdr 93 70 aa bb cc dd 00 03 9e
34898286 34901806 Tag 08 b6 dd
35644958 35649342 Rdr 2a e0 4a 19 !crc
35650834 35651474 Tag 04
35766750 35771518 Rdr 50 00 57 cd
35898638 35899694 Rdr 26
43216356 43217412 Rdr 26
43218648 43221016 Tag 04 00
43228518 43230982 Rdr 93 20
43232730 43238554 Tag aa bb cc dd 00
43246402 43256930 Rdr 93 70 aa bb cc dd 00 03 9e
43258422 43261942 Tag 08 b6 dd
43374622 43379006 Rdr 6c 20 0b 05 !crc
43380370 43381010 Tag 04
@holiman
Contributor
holiman commented Feb 6, 2015

I tested a couple of times only. Do these error appear frequently? Regarding corruptions during auth/post-auth, it's difficult without knowing the expected result, but regarding the other errors; one thing struck me.
The 09 could have been 26 rightshifted twice.
The 02 could have been 26 rightshifted four times (or half a byte).
Why it got stuck in 26/0400-loop is really weird.. I wonder if the demod-buffer (or parts thereof) is not been properly cleared in all situations..

@holiman
Contributor
holiman commented Feb 6, 2015

Isn't this strange also:

Example 4 (weird Reader response after AUTH):

27660638 27665342 Rdr 60 00 f5 7b
27669522 27674258 Tag 01 02 03 04
27850910 27860286 Rdr 22 a2 0e 05 7f 8f d9 71 !crc
28525518 28525870 Rdr 02

The reader sends AR/NR, but the tag doesn't answer, instead the reader issues 02 (or, possibly something else). Why doesn't the tag answer earlier?

@pwpiwi
Contributor
pwpiwi commented Feb 6, 2015

Regarding corruptions during auth/post-auth, it's difficult without knowing the expected result,

I should have added more information: The last examples show the start of the authentication sequence (with a NON valid key), i.e. still nothing encrypted. The expected reader command at this point in the communication would be 60 00 f5 7b (AUTH-A(0), see beginning of example 4).

@pwpiwi
Contributor
pwpiwi commented Feb 6, 2015

The 02in the example 4 should most probably be 26after a timeout. The tag doesn't respond because the authentication fails (wrong key).

@pwpiwi
Contributor
pwpiwi commented Feb 9, 2015

I have committed a fix in 0c8d25e. As discussed above the major point is reducing the waiting time for a stable (i.e. unmodulated) signal in the Miller decoder before looking for a start bit.

In addition I saved some more waiting cycles in EmSend14443Raw(). The FPGA has an internal delay queue which takes care of the required n*64+20 carrier clock cycles delay between reader command and tag answer. Up to now we assumed the worst case (queue full) and waited enough time that it can be emptied (sent to the reader) before switching the FPGA mode back to TAGSIM_LISTEN. Now checking how much of the queue has really been used and waiting accordingly.

Finally I have made the start bit detection more strict. Up to now we had accepted a sequence of at least 64 ones, followed by two to 11 zeroes followed by at least four ones as a start bit (pattern ....1111111xxxxxxx00xx1111xxxxxxxxxx). Changed to at least 24 ones, followed by two or three zeroes followed by at least five ones (pattern .....1111111100x11111xxxxxxx).

@holiman
Contributor
holiman commented Feb 10, 2015

Nice!

I just tested this, as far as I can tell, it works. At least, simming works against the readers I have access to now, and I think we've looked deep enough at this issue that I don't believe we've left anything out. A job well done.

@iceman1001 , could you also confirm that the functionality which didn't work for you earlier now works? I'm itching to finally close this one...

@iceman1001
Contributor

@holiman Sadly I can't since I don't have access to the aformentioned reader. But I have trust in yours and piwis good work.

@pwpiwi
Contributor
pwpiwi commented Feb 11, 2015

I'm itching to finally close this one...

Please keep it open for a few days more. I confirmed that there is a phase error "on air" and I am about to fix it.

@holiman
Contributor
holiman commented Feb 11, 2015

Any pictures?

@pwpiwi
Contributor
pwpiwi commented Feb 11, 2015

Any pictures?

Not yet. Still a long way to become friend with the DSO 😠 😡 💥. But if you look at your own pictures comparing simulated tag and snooped real tag you get the idea.

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

And that was a good thought as well. The field on air is indeed inverted - both simulated and real tag.

@pwpiwi
Contributor
pwpiwi commented Feb 11, 2015

I have some pictures now. The captures had been made with a coil of three loops directly connected to the DSO probe. Reader was an HID Omnikey 5427 CK.

Screenshot 1: A real tag. The fat yellow areas are the 13,56MHz carrier. Left is (the end of) the reader request, right is (the beginning of) the tag's answer:
voltcraft6_1

Screenshot 2: An emulated tag (hf 14a sim 1 ). You can see that the tag's answer to the right is inverted. Otherwise (timing) its perfect:
voltcraft6_2

Although it seems to have no impact, I have committed a fix as 7554370.

Screenshot 3: hf 14a sim after the fix:
voltcraft6_3

@pwpiwi pwpiwi closed this Feb 11, 2015
@iceman1001
Contributor

Well, i got my hands on a device again and could test @holiman @pwpiwi changes.
It looks like the response from reader is received, which is good during Auth. Which is good.
but it fails in next step..
(side issue, it seems now also that the "hf mf sniff" has stopped working, but I will have to do further tests to verify it)

---start snippet from a "HF MF SIM u x" session.

Recorded Activity (TraceLen = 10185 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 |       992 | Rdr | 52                                                              |     | WUPA
  2612 |      4980 | Tag | 04  00                                                          |     |
 37958 |     40422 | Rdr | 93  20                                                          |     | ANTICOLL
 42234 |     48058 | Tag | af  be  e9  ef  17                                              |     |
 83356 |     93884 | Rdr | 93  70  af  be  e9  ef  17  aa  0d                              |     | SELECT_UID
 95376 |     98896 | Tag | 08  b6  dd                                                      |     |
127436 |    132204 | Rdr | 50  00  57  cd                                                  |     | HALT
295586 |    296578 | Rdr | 52                                                              |     | WUPA
298070 |    300438 | Tag | 04  00                                                          |     |
335558 |    346086 | Rdr | 93  70  af  be  e9  ef  17  aa  0d                              |     | SELECT_UID
347770 |    351290 | Tag | 08  b6  dd                                                      |     |
408268 |    413036 | Rdr | 50  00  57  cd                                                  |     | HALT
581788 |    582844 | Rdr | 26                                                              |     | REQA
868764 |    869756 | Rdr | 52                                                              |     | WUPA
871312 |    873680 | Tag | 04  00                                                          |     |
910078 |    920606 | Rdr | 93  70  af  be  e9  ef  17  aa  0d                              |     | SELECT_UID
922162 |    925682 | Tag | 08  b6  dd                                                      |     |
955308 |    960076 | Rdr | 50  00  57  cd                                                  |     | HALT

1128092 | 1129148 | Rdr | 26 | | REQA
1415458 | 1416450 | Rdr | 52 | | WUPA
1417942 | 1420310 | Tag | 04 00 | |
1455430 | 1465958 | Rdr | 93 70 af be e9 ef 17 aa 0d | | SELECT_UID
1467642 | 1471162 | Tag | 08 b6 dd | |
1511628 | 1516396 | Rdr | 50 00 57 cd | | HALT
1674412 | 1675468 | Rdr | 26 | | REQA
1961250 | 1962242 | Rdr | 52 | | WUPA
1963862 | 1966230 | Tag | 04 00 | |
2005246 | 2015774 | Rdr | 93 70 af be e9 ef 17 aa 0d | | SELECT_UID
2017330 | 2020850 | Tag | 08 b6 dd | |
2086908 | 2091676 | Rdr | 50 00 57 cd | | HALT
2247388 | 2248380 | Rdr | 52 | | WUPA
2250000 | 2252368 | Tag | 04 00 | |
2288766 | 2299294 | Rdr | 93 70 af be e9 ef 17 aa 0d | | SELECT_UID
2300850 | 2304370 | Tag | 08 b6 dd | |
2373760 | 2378464 | Rdr | 60 00 f5 7b | | AUTH-A(0)
2382900 | 2387636 | Tag | 01 02 03 04 | |
2388524 | 2397900 | Rdr | 5e 59 fa 21 a4 b5 66 5f | !crc| ?
5948252 | 5949244 | Rdr | 52 | | WUPA
5950864 | 5953232 | Tag | 04 00 | |
5989830 | 6000358 | Rdr | 93 70 af be e9 ef 17 aa 0d | | SELECT_UID
6002042 | 6005562 | Tag | 08 b6 dd | |
6072512 | 6077216 | Rdr | 60 00 f5 7b | | AUTH-A(0)
6081716 | 6086452 | Tag | 01 02 03 04 | |
6087340 | 6096652 | Rdr | 3b 6f 81 06 11 b0 1c 3d | !crc| ?

@pwpiwi
Contributor
pwpiwi commented Feb 25, 2015

Looks pretty good. This is how an unsuccessful authentication looks like.

@iceman1001
Contributor

I stand corrected, I was using a faulty dump.
The "hf mf sim" works perfect.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment