New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hf mf sim after r845 #11

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

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

This comment has been minimized.

Show comment
Hide comment
@pwpiwi

pwpiwi Apr 2, 2014

Contributor

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)

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

This comment has been minimized.

Show comment
Hide comment
@holiman

holiman Apr 2, 2014

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@holiman

holiman Apr 2, 2014

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@holiman

holiman Apr 3, 2014

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@holiman

holiman Apr 3, 2014

Contributor

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

Contributor

holiman commented Apr 3, 2014

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

@pwpiwi

This comment has been minimized.

Show comment
Hide comment
@pwpiwi

pwpiwi Apr 3, 2014

Contributor

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 ?

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

This comment has been minimized.

Show comment
Hide comment
@holiman

holiman Apr 3, 2014

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@holiman

holiman Apr 4, 2014

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@holiman

holiman Apr 4, 2014

Contributor

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

Contributor

holiman commented Apr 4, 2014

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

@buggii

This comment has been minimized.

Show comment
Hide comment
@buggii

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

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

This comment has been minimized.

Show comment
Hide comment
@pwpiwi

pwpiwi Apr 4, 2014

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@holiman

holiman Apr 4, 2014

Contributor

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

Contributor

holiman commented Apr 4, 2014

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

@holiman

This comment has been minimized.

Show comment
Hide comment
@holiman

holiman Apr 4, 2014

Contributor

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;
    }
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

This comment has been minimized.

Show comment
Hide comment
@pwpiwi

pwpiwi Apr 4, 2014

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@holiman

holiman Apr 4, 2014

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@pwpiwi

pwpiwi Apr 5, 2014

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@holiman

holiman Apr 6, 2014

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@buggii

buggii 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

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

This comment has been minimized.

Show comment
Hide comment
@iceman1001

iceman1001 Jan 18, 2015

Member

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.

Member

iceman1001 commented Jan 18, 2015

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

This comment has been minimized.

Show comment
Hide comment
@holiman

holiman Jan 18, 2015

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@iceman1001

iceman1001 Jan 18, 2015

Member

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

Member

iceman1001 commented Jan 18, 2015

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

This comment has been minimized.

Show comment
Hide comment
@holiman

holiman Jan 18, 2015

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@holiman

holiman Jan 18, 2015

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@holiman

holiman Jan 18, 2015

Contributor

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

Contributor

holiman commented Jan 18, 2015

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

@iceman1001

This comment has been minimized.

Show comment
Hide comment
@iceman1001

iceman1001 Jan 18, 2015

Member

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

Member

iceman1001 commented Jan 18, 2015

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

This comment has been minimized.

Show comment
Hide comment
@iceman1001

iceman1001 Jan 18, 2015

Member

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

Member

iceman1001 commented Jan 18, 2015

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

This comment has been minimized.

Show comment
Hide comment
@buggii

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

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

This comment has been minimized.

Show comment
Hide comment
@pwpiwi

pwpiwi Jan 19, 2015

Contributor

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

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.

@pwpiwi

This comment has been minimized.

Show comment
Hide comment
@pwpiwi

pwpiwi Feb 5, 2015

Contributor

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().

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

This comment has been minimized.

Show comment
Hide comment
@iceman1001

iceman1001 Feb 5, 2015

Member

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

Member

iceman1001 commented Feb 5, 2015

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

@pwpiwi

This comment has been minimized.

Show comment
Hide comment
@pwpiwi

pwpiwi Feb 5, 2015

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@iceman1001

iceman1001 Feb 5, 2015

Member

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

Member

iceman1001 commented Feb 5, 2015

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

@holiman

This comment has been minimized.

Show comment
Hide comment
@holiman

holiman Feb 5, 2015

Contributor

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?

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

This comment has been minimized.

Show comment
Hide comment
@holiman

holiman Feb 5, 2015

Contributor

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?

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

This comment has been minimized.

Show comment
Hide comment
@pwpiwi

pwpiwi Feb 5, 2015

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@pwpiwi

pwpiwi Feb 5, 2015

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@holiman

holiman Feb 5, 2015

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@holiman

holiman Feb 5, 2015

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@holiman

holiman Feb 5, 2015

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@pwpiwi

pwpiwi Feb 6, 2015

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@holiman

holiman Feb 6, 2015

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@holiman

holiman Feb 6, 2015

Contributor

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?

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

This comment has been minimized.

Show comment
Hide comment
@pwpiwi

pwpiwi Feb 6, 2015

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@pwpiwi

pwpiwi Feb 6, 2015

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@pwpiwi

pwpiwi Feb 9, 2015

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@holiman

holiman Feb 10, 2015

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@iceman1001

iceman1001 Feb 10, 2015

Member

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

Member

iceman1001 commented Feb 10, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@pwpiwi

pwpiwi Feb 11, 2015

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@holiman

holiman Feb 11, 2015

Contributor

Any pictures?

Contributor

holiman commented Feb 11, 2015

Any pictures?

@pwpiwi

This comment has been minimized.

Show comment
Hide comment
@pwpiwi

pwpiwi Feb 11, 2015

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@pwpiwi

pwpiwi Feb 11, 2015

Contributor

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

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

@iceman1001

This comment has been minimized.

Show comment
Hide comment
@iceman1001

iceman1001 Feb 25, 2015

Member

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| ?

Member

iceman1001 commented Feb 25, 2015

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

This comment has been minimized.

Show comment
Hide comment
@pwpiwi

pwpiwi Feb 25, 2015

Contributor

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

Contributor

pwpiwi commented Feb 25, 2015

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

@iceman1001

This comment has been minimized.

Show comment
Hide comment
@iceman1001

iceman1001 Feb 25, 2015

Member

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

Member

iceman1001 commented Feb 25, 2015

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