Support for HID iClass Cards

[mburrough]

Feature Request: add support for HID iClass Prox cards. These appear to use ISO 15693 and/or 14443B.

References: http://www.openpcd.org/HID_iClass_demystified http://www.openpcd.org/OpenPICC_SnifferOnly_13.56MHz http://www.openpcd.org/git-view/iclass-security/tree/iCLASS-RFID-sniffer https://www.hidglobal.com/sites/default/files/resource_files/iclass-card-ds-en.pdf

[inglefusion]

+1....million. :)

[xman5735]

+1 all day

[cmiaji]

Yes, please!! I've been waiting for so long for some reasonably priced hardware for working with HID cards. I believe it's possible with the Chameleon hardware. Does anyone know if that's correct?

[geo-rg]

Hey guys, sorry for the late reply. The HID iClass cards use ISO 14443B, don't they? Unfortunately, this codec is currently not supported by the firmware. So the first step for HID iClass support would be ISO14443B support, which we are not working on currently.

However, we have this in our sights, but please don't expect a ready solution in the next few months from our side. Maybe somebody else can implement the ISO14443B codec sooner - some thoughts on how to start:

1. Initiate communication from an arbitrary NFC reader and an ISO14443B tag.
2. Position the Chameleon directly between the reader and the tag and probe (using an oscilloscope) the DEMOD and DEMOD-READER pin. Now you know how the Chameleon sees the communication.
3. You may look at the ISO14443A codec to know how emulation is done there.

[inglefusion]

geo-rg

Is the capability there to your knowledge? Probing the card doesn't offer much information and the documentation for the ISO14443A codec isn't very clear on what's expected by the Chameleon to develop a codec.

Do you have any additional insight for the codec development process and capabilities?

Thanks!

[geo-rg]

@inglefusion To our knowledge, the hardware should be able to support ISO14443B as well as ISO15693 (I'm not sure why I thought that iClass uses ISO14443B, it actually uses ISO15693, right?).

Writing a codec is not something you can do straightforwardly. It is not possible to do without doing some tests with an oscilloscope looking how the DEMOD signal behaves when it receives an ISO{14443B,15693} signal. When you know this, you can start thinking about how to decode this.

For example the ISO14443A reader codec waits after it has finished sending the message until the first rising edge (detected with an analog comparator [AC]) in DEMOD signal. On the beginning of waiting for this edge, two timers are started. One is configured such, that it is reset automatically by the event system on every rising edge detected by the AC. This timer also has an interrupt when it reaches a specific time. With this timer, the length of the pauses between the modulations can be detected. The other timer is used to know the duration of the modulations. When we know the duration of one modulation and its following modulation pause, we know which bit is coded.

As you can see, this is nothing I could have explained or developed before looking how the DEMOD signal reacts to the cards answer. So far the receiving part.

Sending in ISO14443A reader mode is just turning the field off and on again at the correct time. Now that is something where it is obvious to do this with timer interrupts. But sending within an emulation codec will be harder, as most likely some ASK or PSK is used.

For ISO15693, there is another thread/issue, where somebody is already working on it. Maybe you can join him?

[Supercodegames]

Any updates on this?

[fptrs]

Hi @Supercodegames, we recently merged the ISO15693 branch into the master. This seems to be a good starting point for developing an iClass application. We are happy about contributions. If you need some assistance don't hesitate to contact me.

[SLiNv]

Hi just following up after 5 years of the original request. It looks like Chameleon still can't emulate iClass?

[david-oswald]

Hi @SLiNv yes this is correct - however as you can see from this thread the underlying ISO15693 support is there, so if someone feels like picking up the implementation of this feature then that's a good basis.

[nvx]

For reference, I have recently implemented ICLASS support in the RRG repo. I imagine it'd be fairly straightforward to port it over to this repo if someone was interested.

I've only got a Chameleon Tiny Pro, hence my development efforts were against the RRG repo instead of this one.

[david-oswald]

This is great @nvx - is there a PR to the RRG repo that you can post here? As the codebase is indeed very similar, it might be possible to merge it quite easily.

[nvx]

This is great @nvx - is there a PR to the RRG repo that you can post here? As the codebase is indeed very similar, it might be possible to merge it quite easily.

The main PR is https://github.com/RfidResearchGroup/ChameleonMini/pull/91, but there was a follow-up with a fix in https://github.com/RfidResearchGroup/ChameleonMini/pull/94 too.

Note that some readers might not work still though as the Chameleon 15693 support only allows for VCD->VICC using 100% modulation index and not 10% modulation index which is required by the spec (and PicoPass cards support). In practice this seems to only be an issue on super old readers though. This of course affects all 15693-based cards, not just iClass.

[nvx]

Note since PicoPass only implements some parts of 15693 some special handling was needed in the codec for it. I also had to do some hacks with the crypto because the AVR is too slow, so I start encoding the response while I'm still calculating the crypto (the start of frame preamble takes long enough to encode to buy enough time that the reader doesn't time out).

I haven't looked into how similar the 15693 codec implementations are between the repos, but that'd probably be where most of the effort would be.