iClass sim command not working on all hardware revisions

carl55 · 2012-10-07 17:38:41

I am having a problem with using the "hf iclass sim" function on all of my newer revision iclass readers. It works great with my older RevA RW300 readers but will not work at all with my RevB or RevC readers (I've tried four). As shown below it simply turns on the amber LED and returns to the proxmark3 prompt whenever the sim command is issued.
Has anyone else ever had success with this command on RevB or RevC iclass hardware or does anyone have any suggestions as to why it may not be working. Unfortunately I only have one Proxmark3 so I am unable to snoop both sides of the communication sequence. Thanks.

A BAD SEQUENCE WITH 4 DIFFERENT REVB AND REVC READERS

proxmark3> hf iclass sim 0 000B0FFFF7FF12E0
--simtype:00 csn:00 0b 0f ff f7 ff 12 e0
proxmark3>

A GOOD SEQUENCE WITH A REVA RW300 READER

proxmark3> hf iclass sim 0 000B0FFFF7FF12E0
--simtype:00 csn:00 0b 0f ff f7 ff 12 e0
#db# READER AUTH (len=09): 05 05 25 46 9a 83 d3 f6 4b
#db# READER AUTH (len=09): 05 d5 d0 3e 77 48 e1 92 74
#db# READER AUTH (len=09): 05 ea 55 2d 33 b3 a1 d4 96
#db# READER AUTH (len=09): 05 33 b7 c0 9f 4b 5d 3e 52
#db# READER AUTH (len=09): 05 ea a0 2b 78 11 43 85 2c
#db# READER AUTH (len=09): 05 1b b3 d2 b0 85 f6 4e 2f
#db# READER AUTH (len=09): 05 98 f3 f1 ff d8 52 ad 49
#db# READER AUTH (len=09): 05 37 7a 21 18 00 08 26 0d
#db# READER AUTH (len=09): 05 99 3f b9 e8 0c 12 0b 2b
#db# READER AUTH (len=09): 05 22 a7 09 0b 49 6d 0c 9f
#db# READER AUTH (len=09): 05 7d d7 23 3f f0 a1 b5 42
#db# READER AUTH (len=09): 05 71 62 39 03 57 2f e6 78
#db# READER AUTH (len=09): 05 4d a4 a6 3f 8c 7f 03 44
#db# READER AUTH (len=09): 05 b5 d2 c7 38 13 79 b1 6c
#db# READER AUTH (len=09): 05 cc 54 33 18 1c 18 f1 44
#db# READER AUTH (len=09): 05 99 57 c0 9b b0 15 d9 f5
#db# READER AUTH (len=09): 05 99 ae bc 33 0c 16 fc 11
#db# READER AUTH (len=09): 05 bf 07 2a 68 67 7f cd 03
#db# READER AUTH (len=09): 05 ff 6a 2e 07 a8 45 15 57
#db# Trace full
#db# 89
proxmark3>

rule · 2012-10-09 10:36:45

Would be very interesting to fix these decoding/antenna problems. The current code seems not to work great for different types of iClass readers. But it is hard to determine the problem remotely. You could try to enable the (debug) messages (uncommenting the captured edge values that are put into the log). It probably comes down to some tweaking with threshold values, antenna positions and decoding timings.

Let me know if you are willing to help figuring this out, so we could maybe look into the problem together?

ps. if you do a "hf iclass list" afterwards, what will you see in the trace when talking to a "new" reader?

carl55 · 2012-10-09 17:27:00

Roel,
I am willing to help debug the problem in any way that I can. However, I have no C programming skills and I have limited experience with the Proxmark3 build environment. I am also willing to send you (donate) a brand new HID RK40 RevB iClass reader if that would help you debug the problem locally. Just let me know and I can ship it tomorrow at no cost to you.

I did try the "hf iclass list" command after the sim command fails but it simply puts out the following error message:

write failed: libusb0-dll:err [_usb_reap_async] timeout error
!
Trying to reopen device...

rule · 2012-10-10 19:46:07

Hey Carl,

Great to hear you are willing to share one of your readers. I'm working to get the emulation to work with a smaller OMNIKEY (pen) reader as well that someone else donated.

You probably have to cancel (press button on proxmark) the simulation process before you try to list the trace. At the moment the proxmark can not run in standalone mode (like emulation) and receive new commands at the same time.

Cheers,

Roel

wookiee88 · 2012-10-11 00:17:42

Hi,

I think I am running into the same problem as Carl. My HID reader is labeled RPK40C - does this mean I have a Rev. C reader?

When I run "hf iclass sim 0 031FEC8AF7FF12E0" I get a trace like the following:

+        0:     0:   TAG  0f
+        0:      :        0a
+        0:     0:   TAG  0f
+        0:      :        0a
+        0:     0:   TAG  0f
+        0:      :        0a
+        0:     0:   TAG  0f
+        0:      :        0a

Any ideas for getting emulation to work? It would be nice to get the proxmark to try to authenticate.

Thanks.

wookiee88 · 2012-10-12 16:22:20

Hi Roel,

On another reader (RP40C), I get the following trace:

+      0:    :     0a
+      0:   0: TAG 0f
+      0:    :     0c
+      0:   0: TAG e0  83  5d  f1  fe  5f  02  7c  55  3f
+      0:    :     0a
+      0:   0: TAG 0f
+      0:    :     0c
+      0:   0: TAG e0  83  5d  f1  fe  5f  02  7c  55  3f
+      0:    :     0a
+      0:   0: TAG 0f
+      0:    :     0a
+      0:   0: TAG 0f
+      0:    :     0a
+      0:   0: TAG 0f

I'm guessing this is a timing issue? It looks like the protocol gets stuck right as the proxmark is sending the 0x0f or the anti-collision CSN, so I guess the reader is not receiving at the right time.

Where in the code can I adjust the timing settings? Any suggestions for this?

Thanks!

0xFFFF · 2012-10-15 10:19:46

I have two PM3's, a few RW400's, a CP400 (HS), an OEM75 and a lot of cards. If you'd like me to test anything in particular, please let me know.
I'm familiar with the serial protocol for these devices. If anyone is after the RS232 module, I have one kicking around I'm happy to send out.

My trace results vary like wookiee88's. I have not seen anything like what carl55 has. I have not tried all of my readers though.

wookiee88 · 2012-10-18 18:05:35

roel wrote:

You could try to enable the (debug) messages (uncommenting the captured edge values that are put into the log). It probably comes down to some tweaking with threshold values, antenna positions and decoding timings.

Hi,

Where in the code can I enable the debug messages and change the threshold values and decoding timings? I looked at the code, but it was not obvious.

I have confirmed that I can snoop authentication between the readers and iClass cards. I noticed that if I set the delay to 0 in TransmitIClassCommand() in in iclass.c, I can get the same trace on RPK40 reader that I got on the RP40 reader. It still gets stuck at the anti-collision stage.

Thanks for your help!

carl55 · 2012-11-30 17:50:02

In an attempt to investigate why the Proxmark3 “hf iclass sim” command does not currently work with iclass RevB or RevC readers I have recently completed a few experiments using two different readers.
1. HID RW300 RevA iclass reader (P/N 6111AKN0000)
2. HID R40 RevC iclass reader (P/N 6120CKN0000)
I built up some special test hardware that allowed me to monitor the RF signal and to decode the ISO 15693 communication sequence.

RF Electrical Comparison:

1. The two readers each appear to generate a similar RF field. The RF carrier amplitude was approximately 18 Vpp for both readers.
2. The 13.56 Mhz carrier was activated at approximately 100 msec intervals on each reader. (Note: The 10 percent duty cycle is HID’s attempt to reduce the overall operating power of the reader.)
3. While polling for a card, the duration of the carrier activation time is longer for the RevC reader than for the RevA reader (12.6 msec for the RevC reader versus 7.7 msec for the RevA reader).
4. The first 15693 VCD SOF in the RevC reader does not occur until approximately 8.8msec after the RF field has been activated. The first SOF for the RevA reader occurs in less than 1 msec.

Communication sequence Comparison:

(Note: these sequences reflect a "standard" reader attempting to authenticate with a high security card. That was done so that the card would NOT authenticate, thus being more representitive of how the Proxmark3 "sim" command would work.)
The main difference appears to be that the RevC reader includes the use of a PAGESEL command that isn't present in the RevA reader.
The sequences below only show the "Reader to Card" transmission, the "Card to Reader" responses are NOT shown.

[RevC R40 Communication Sequence]

ACTALL		0A 
IDENTIFY	0C 
SELECT		81 36 D0 1D E0 FE 5F 02 3C
HALT		00
SELECT		81 B1 81 EE 00 FF F7 FF 12 E0
PAGESEL		84 00 73 33
READCHECK	88 02
CHECK		05 E2 CF 7E 04 69 91 CE D0
ACTALL		0A
SELECT		81 B1 81 EE 00 FF F7 FF 12 E0 
PAGESEL		84 00 73 33 
READCHECK	88 02 
CHECK		05 8D 9C 5B 12 C0 33 DD B7 
ACTALL		0A 
IDENTIFY	0C
 .
 .
 .
Repeat

[RW300 RevA Communication  Sequence]

ACTALL		0A
IDENTIFY	0C 
SELECT		81 36 D0 1D E0 FE 5F 02 3C  
READCHECK	88 02 
CHECK		05 E3 11 74 44 85 F9 C4 91 
READCHECK	88 02 
CHECK		05 9F 80 F2 3E FB 5E 3C 20 
READCHECK	88 02 
CHECK		05 6E 13 1F 18 B7 40 3A 6B 
READCHECK	88 02 
CHECK		05 15 DE C4 C7 19 9C 88 13 
HALT		00
ACTALL		0A
IDENTIFY	0C
 .
 .
 .
Repeat

Maybe this information can help determine what the problem might be in the current code.

carl55 · 2012-12-17 01:31:22

As a follow-up to the earlier posts I believe that I have determined the root cause of why the Proxmark "hf iclass sim" command does not work with the newer iclass readers. To aid in my troubleshooting effort I built up some specialized hardware circuitry that allowed me to communicate with an iclass reader. After many hours of experimentation I have successfully been able to simulate an iclass credential with this hardware on both the older RevA and newer (RevB and RevC) readers. I have found the problem with the Proxmark software implementation to be as follows:

In order to simulate a credential the proxmark code currently utilizes a "fixed" anti-collision serial number (ACSN) that is used as a response during the 0x0C "IDENTIFY" command sequence. When the reader responds with an 0x81 "SELECT" command sequence the proxmark responds with the CSN that was input by the user . The fact that the user CSN and ACSN are not a matched pair is not enforced by the older RevA reader. However the newer RevB and RevC readers will not respond with a "SELECT" command if it determines that the ACSN was not correctly derived from the CSN that was sent back during the "IDENTIFY" command. To solve the problem the proxmark software must calculate a new (and proper) ACSN for each user selected CSN that is to be simulated. I have found (through experimentation) that when this rule is followed the newer readers will continue on with the normal communication sequence and will send the next proper series of commands (READCHECK and CHECK).

Unfortunately I do not have the programming skills to correct the Proxmark software myself but hopefully this information will help someone who does.

rule · 2012-12-18 21:27:53

VERY GOOD WORK! Sorry I wasn't able to help, to many things on my plate right now....

Do you have some ACSN examples that the proxmark transmitted for your cards serial number CSN and the ones that it should be? I think this is easy to fix

carl55 · 2012-12-19 01:33:00

Roel,
The proxmark code appears to use 0x031FEC8AF7FF12E0 as the value for the anti-collision serial number (ACSN). The correct value should be derived from the actual CSN. I have generated a chart that shows how the ACSN is generated from the CSN along with an example conversion. The chart can be found here:
http://www.proxclone.com/pdfs/picopass_acsn.pdf

rule · 2012-12-19 09:04:27

Thank you for the clear example! I've quicly looked into it, but it seems that the proxmark is doing exactly this....
The function that performs this rotate is called rotateCSN(). I took it out of the proxmark code and put it into a simple example program. The source code of acsn.c is listed below:

#include <stdio.h>
#include <stdint.h>

void rotateCSN(uint8_t* originalCSN, uint8_t* rotatedCSN) {
  size_t i;
  for(i = 0; i < 8; i++) {
    rotatedCSN[i] = (originalCSN[i] >> 3) | (originalCSN[(i+1)%8] << 5);
  }

  printf(" csn: ");
  for(i=0; i<8; i++) {
    printf("%02x",originalCSN[i]);
  }
  printf("\n");

  printf("acsn: ");
  for(i=0; i<8; i++) {
    printf("%02x",rotatedCSN[i]);
  }
  printf("\n");

}

int main() {

  uint8_t response2[] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
  uint8_t response3[] = { 0x03, 0x1f, 0xec, 0x8a, 0xf7, 0xff, 0x12, 0xe0, 0x00, 0x00 };

  uint8_t example_r[] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
  uint8_t example[]   = { 0x12, 0x15, 0xaf, 0x00, 0xf7, 0xff, 0x12, 0xe0, 0x00, 0x00 };

  rotateCSN(response3,response2);
  printf("\n");
  rotateCSN(example,example_r);
  printf("\n");

  return 0;
}

You can compile this code with the following line (under linux/mac/mingw):

$gcc -o acsn acsn.c

To execute the program, just run and look at the output.

$./acsn
 csn: 031fec8af7ff12e0
acsn: e0835df1fe5f027c

 csn: 1215af00f7ff12e0
acsn: a2e215e0fe5f025c

It seems to generate exactly the same as your example right? Does this mean we mixed upped the buffers in the proxmark somewhere, so that we are sending the incorrect message back to reader? Or do we need to send a different/leave-out the CRC for the acsn message?

carl55 · 2012-12-19 18:06:40

I guess I am confused also. Unfortunately my microcontroller code is only capable of "decoding" the reader-to-card 15693 transmission and "encoding" the card-to-reader response. I am unable to decode the proxmark-to-reader modulated transmission. I will have to see what my other options are.
The ACSN response DOES require the CRC to be appended. Maybe that is being messed up.
The crc that I calculated and used in a successful transmission is as follows:

 csn: 031fec8af7ff12e0  crc = ae 86
acsn: e0835df1fe5f027c  crc = 55 3f

 csn: 1215af00f7ff12e0  crc = 6f 7d
acsn: a2e215e0fe5f025c  crc = 14 d7

I will continue to look into it to see what I can learn.

rule · 2012-12-20 13:12:34

Took the CRC functions out of the proxmark repository as well and updated the code:

#include <stdio.h>
#include <stdint.h>

#define CRC_14443_A     0x6363  /* ITU-V.41 */
#define CRC_14443_B     0xFFFF  /* ISO/IEC 13239 (formerly ISO/IEC 3309) */
#define CRC_ICLASS      0xE012  /* ICLASS PRERFIX */

static unsigned short UpdateCrc14443(unsigned char ch, unsigned short *lpwCrc)
{
  ch = (ch ^ (unsigned char) ((*lpwCrc) & 0x00FF));
  ch = (ch ^ (ch << 4));
  *lpwCrc = (*lpwCrc >> 8) ^ ((unsigned short) ch << 8) ^
  ((unsigned short) ch << 3) ^ ((unsigned short) ch >> 4);
  return (*lpwCrc);
}

void ComputeCrc14443(int CrcType, const unsigned char *Data, int Length, unsigned char *TransmitFirst, unsigned char *TransmitSecond) {
  unsigned char chBlock;
  unsigned short wCrc=CrcType;

  do {
    chBlock = *Data++;
    UpdateCrc14443(chBlock, &wCrc);
  } while (--Length);
  
  if (CrcType == CRC_14443_B)  wCrc = ~wCrc;
  *TransmitFirst = (unsigned char) (wCrc & 0xFF);
  *TransmitSecond = (unsigned char) ((wCrc >> 8) & 0xFF);
  return;
}

void rotateCSN(uint8_t* originalCSN, uint8_t* rotatedCSN) {
  size_t i; 
  for(i = 0; i < 8; i++) {
    rotatedCSN[i] = (originalCSN[i] >> 3) | (originalCSN[(i+1)%8] << 5);
  }

  // Compute CRC on both CSNs
  ComputeCrc14443(CRC_ICLASS, originalCSN, 8, &originalCSN[8], &originalCSN[9]);
  ComputeCrc14443(CRC_ICLASS, rotatedCSN, 8, &rotatedCSN[8], &rotatedCSN[9]);

  printf(" csn: ");
  for(i=0; i<10; i++) {
    printf("%02x",originalCSN[i]);
  }
  printf("\n");

  printf("acsn: ");
  for(i=0; i<10; i++) {
    printf("%02x",rotatedCSN[i]);
  }
  printf("\n");

}

int main() {

  uint8_t response2[] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
  uint8_t response3[] = { 0x03, 0x1f, 0xec, 0x8a, 0xf7, 0xff, 0x12, 0xe0, 0x00, 0x00 };

  uint8_t example_r[] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
  uint8_t example[]   = { 0x12, 0x15, 0xaf, 0x00, 0xf7, 0xff, 0x12, 0xe0, 0x00, 0x00 };

  rotateCSN(response3,response2);
  printf("\n");
  rotateCSN(example,example_r);
  printf("\n");
  
  return 0;
}

The output is now:

 csn: 031fec8af7ff12e0ae86
acsn: e0835df1fe5f027c553f

 csn: 1215af00f7ff12e06f7d
acsn: a2e215e0fe5f025c14d7

Which is again, exactly as you posted. I think the message in itself is correct, but probably b/c of timing it get interpreted incorrectly. Could you see a (timing) difference with the oscilloscope looking responses of your (working) device and the proxmark?

Cheers,

Roel

carl55 · 2012-12-20 18:36:19

Roel,
I captured a couple of oscilloscope traces of an actual iclass cards response and the Proxmark's response to an iclass readers IDENTIFY sequence.
Here is a link to a writeup (and photos) that summarize the results. http://www.proxclone.com/pdfs/iclass_id … timing.pdf

holiman · 2014-04-26 13:55:27

So the only difference you saw was a 332us versus 284 us delay between IDENTITY and tag SOF ? I am experimenting with varying the pm3 delay times, but has not had much luck so far..

carl55 · 2014-04-26 15:46:18

Holiman,
That was the only obvious difference that I saw. However, when I was building up and testing my own CSN simulator circuit I noticed that the HID readers were "very" sensitive with regards to the timing of the 423.75 khz subcarrier pulses that are used in the logic one and logic zero ISO15693 card-to-reader data sequences. (See section "8.4.1 Bit coding when using one subcarrier" of the ISO15693-2 specification.)

http://www.waazaa.org/15693/

It is very difficult to maintain tight timing when you are using a microcontroller instead of a dedicated hardware circuit since the delays introduced by looping, subroutine calls, subroutine returns, etc. must be properly accounted for. If the pulse train duty cycles or unmodulated times were only slightly off then the reader would abort the entire communication sequence.

holiman · 2014-04-30 09:48:55

Thanks for the info. I'm going to investigate the FPGA-parts a bit more, and do some more measurements on the signals. The FPGA clock is not (as far as I know) dependant on the ARM, so we should be able to get exact timing there. Piwi managed to get the timing so exact in mifare that he was able to time exactly on 65536 cycles...

Proxmark3 community

Announcement

#1 2012-10-07 17:38:41

iClass sim command not working on all hardware revisions

#2 2012-10-09 10:36:45

Re: iClass sim command not working on all hardware revisions

#3 2012-10-09 17:27:00

Re: iClass sim command not working on all hardware revisions

#4 2012-10-10 19:46:07

Re: iClass sim command not working on all hardware revisions

#5 2012-10-11 00:17:42

Re: iClass sim command not working on all hardware revisions

#6 2012-10-12 16:22:20

Re: iClass sim command not working on all hardware revisions

#7 2012-10-15 10:19:46

Re: iClass sim command not working on all hardware revisions

#8 2012-10-18 18:05:35

Re: iClass sim command not working on all hardware revisions

#9 2012-11-30 17:50:02

Re: iClass sim command not working on all hardware revisions

#10 2012-12-17 01:31:22

Re: iClass sim command not working on all hardware revisions

#11 2012-12-18 21:27:53

Re: iClass sim command not working on all hardware revisions

#12 2012-12-19 01:33:00

Re: iClass sim command not working on all hardware revisions

#13 2012-12-19 09:04:27

Re: iClass sim command not working on all hardware revisions

#14 2012-12-19 18:06:40

Re: iClass sim command not working on all hardware revisions

#15 2012-12-20 13:12:34

Re: iClass sim command not working on all hardware revisions

#16 2012-12-20 18:36:19

Re: iClass sim command not working on all hardware revisions

#17 2014-04-26 13:55:27

Re: iClass sim command not working on all hardware revisions

#18 2014-04-26 15:46:18

Re: iClass sim command not working on all hardware revisions

#19 2014-04-30 09:48:55

Re: iClass sim command not working on all hardware revisions

Board footer