Closed hsanjuan closed 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...
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. :(
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.
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!
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 @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?
@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
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!
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).