search

emsec / ChameleonMini

The ChameleonMini is a versatile contactless smartcard emulator compliant to NFC. The ChameleonMini was developed by https://kasper-oswald.de. The device is available at https://shop.kasper.it. For further information see the Getting Started Page https://rawgit.com/emsec/ChameleonMini/master/Doc/Doxygen/html/_page__getting_started.html or the Wiki tab above.
Other
1.74k stars 392 forks source link

ISO15693: Nothing detected by particular reader, no sniff #255

Closed hsanjuan closed 4 years ago

hsanjuan commented 4 years ago

I have an ISO15693 card here which the ChameleonMini is perfectly able to read and emulate.

However, the reader that I am trying to work with does not respond at all to the ChameleonMini emulating the tag (my phone reads it fine).

I can effectively sniff card communications when I read the card with my phone for example. But when the reader I am trying to work with does it, there is no trace in the sniffing logs.

Are there any transmission modes missing from the codec implementation? Or what else could be the cause?

cc @ceres-c (as co-author of the codec).

bosb commented 4 years ago

Could you give more information about the reader? What chips it is using? When I see my old records, the 'super' speed with single carrier might be a problem if that's the only mode used by the reader...

hsanjuan commented 4 years ago

Could you give more information about the reader? What chips it is using?

Unfortunately I cannot get access to the actual chip and the maker does not provide that information. :(

ceres-c commented 4 years ago

Hello, I'm not sure I understand what you're referring to when you talk about "sniffing logs". Is it the chameleon log? In that case I'd call it RX/TX/sniff log as it depends on the configuration in use, but there is no publicly available ISO15693 sniffing implementation, as far as I know.

Apart from this, yes, I can confirm what @bosb said: some readers and cards support a ultra-high data rate (page 21, "52 Kbps"), which effectively doubles ISO1563 standard high data rate (paragraphs 7.2 and 7.2.2, in particular). This would explain why you're not getting any data from the reader in your chameleon logs, if this is the case. I haven't come across clear documentation about how this data rate works and at the moment I don't have the time to to work on it, but maybe it's not too hard to implement.

On the other side, if you're correctly receiving commands from the reader and they are saved in the Chameleon log, it could be that the reader is expecting data to be modulated in dual subcarrier mode and, if I'm not mistaken, the Chameleon doesn't support modulation of signals to the reader in dual subcarrier mode. Me and @MrMoDDoM were working on ISO15693 sniffing with dual subcarrier mode as well, but other projects got in the way, so we haven't started to write code yet. We spent quite a lot of time trying to figure out a clever implementation and we have probably come up with a nice way to let the hardware do most of the heavy lifting.

I hope I haven't confused you further and I fear I explained myself terribly, but it's quite late and it has been a long day. I'll to make myself more clear tomorrow if some information weren't clear.

hsanjuan commented 4 years ago

RX/TX/sniff log as it depends on the configuration in use, but there is no publicly available ISO15693 sniffing implementation, as far as I know.

There's a ISO15693_SNIFF mode in the firmware. Undocumented though :)

I haven't come across clear documentation about how this data rate works and at the moment I don't have the time to to work on it, but maybe it's not too hard to implement.

No worries, just trying to figure out the reasons, not to get free work. I don't have access to the spec. The fast mode being in use seems like a good candidate for the problem here.

On the other side, if you're correctly receiving commands from the reader and they are saved in the Chameleon log, it could be that the reader is expecting data to be modulated in dual subcarrier mode and, if I'm not mistaken, the Chameleon doesn't support modulation of signals to the reader in dual subcarrier mode

Well, logs were completely empty even though the card was read fine.

I hope I haven't confused you further and I fear I explained myself terribly, but it's quite late and it has been a long day

No, it's pretty clear! And thanks for explaining!

fptrs commented 4 years ago

Hi @hsanjuan, the sniff mode in the firmware only sniffs the reader to card direction using the 'normal' emulation codec. This communication should be visible to you. When there is any communication (even if the reader is using a higher data rate) the Chameleon should pick up at least the SOFs and therefor show something in the log. Sometimes the Chameleon log is empty because the log mode was set to OFF, make sure by clearing the log and setting it to MEMORY in advance.

hsanjuan commented 4 years ago

Hi @hsanjuan, the sniff mode in the firmware only sniffs the reader to card direction using the 'normal' emulation codec. This communication should be visible to you. When there is any communication (even if the reader is using a higher data rate) the Chameleon should pick up at least the SOFs and therefor show something in the log. Sometimes the Chameleon log is empty because the log mode was set to OFF, make sure by clearing the log and setting it to MEMORY in advance.

Hi, I'm pretty sure I've been doing things properly. I tested with chamlog.py using a Proxmark 3 as reader. Live capture showed some data. Then moved to the problematic reader. It operated and read the card but live capture showed nothing. I have now triple-checked also using MEMORY mode and the log is empty (logdownload sends a 2048-byte file of 0s, and chamlog.py shows no output at all, live or not). I operated the reader a dozen times with the card and the Chameleon in several positions...

Chameleon should pick up at least the SOFs and therefor show something in the lo

Well it doesn't show anything so I have no idea what is going on... also, for curiosity, what are SOFs?

ceres-c commented 4 years ago

@fptrs I don't know which vendor we're talking about, but it is possible they are using a custom SOF for data from the reader to the card.

If I were you, @hsanjuan I'd try to acquire a reader for this system and start reverse engineering it from the ground up. You could see the signals with an oscilloscope and check what's wrong

By the way, SOF means Start Of Frame, a recognisable message to start communicatio between reader and tag and vice versa

hsanjuan commented 4 years ago

By the way, SOF means Start Of Frame, a recognisable message to start communicatio between reader and tag and vice versa

Thanks!

Unfortunately I don't have access to this reader anymore so I'll close this and will re-open if ever I regain access and have some more time. Thanks to everyone that chimed in!