ISO15693 Sniffing

[cacke-r]

Hello all,
I'm wondering if there is any update on the ISO15693 sniffing.
I'm currently working based on the iso15_sniff branch from the @ceres-c fork.
But it doesn't support card->reader sniff yet. I'm willing to add it - and currently digging
into the chameleon and Atmel details I'm not yet familiar with.
I'm wondering if there is already some further progress - that I've not yet found ?

Is there any reason, why the actual status is not yet merged to this repo here ?

Currently I'm fighting with activating the overflow-IRQ on the TCD0 channel.
Whenever I do so - it the device seems to be dead (no further log output - no reaction on the command interface) - is there any trick with the OVF-IRQ which needs to be considered ?
Thanks in advance for any support, cacke-r

[fptrs]

Hi @cacke-r,
@ceres-c did not submit a PR regarding ISO15693 sniffing and I'm not sure what's the status of his branch. But there is also no further progress that you've missed, so this might be a good starting point.

Does the red LED light up when the device seems dead? If so, then there is a problem with the ISR and the Chameleon does not recognize your ISR as the TCD0 OVF ISR and triggers BADISR_vect. If you can share the code I could take a look.

[cacke-r]

Hi @fptrs ,
thanks for your quick reply. OK, then I'll go ahead from the @ceres-c branch - and do what I can.
Thanks for the hint about BADISR_vect - I missed that I need to add it in SharedISR.S :-( .... just an Atmel newbi - so that part works now.

Then I'll go ahead and get the sniffing for card working (reader sniffing already works) - afterwards we may discuss how to get the whole package upstream ? Shall I start with raising PRs against @ceres-c repo first ? Or rather directly here ?
(don't hurry with answering - I would need some time anyhow :-))

Regards
cacke-r

[ceres-c]

Hi,
I just returned from a call with @MrMoDDoM about this, since we knew we were working on that branch, but due to the pandemic stopped all development and completely forgot about the current state of the project and the approach we were considering to implement VICC->VCD sniffing. Given that we haven't touched the codebase in 2 years now, we are a bit out of the loop, but we believe we might have figured out a general direction to follow.

(From now on I'm taking for granted that you have knowledge about iso15 air interface, which is defined in ISO15693-2.)

Our plan was to implement both high and low data rate with single and double subcarrier, thus we are looking for a generic solution. We don't know yet if this is feasible and we're assuming to reliably sample the pulses in VICC->VCD communication (strong assumption, one problem at a time, though).

We were thinking about using 2 interrupts: one counter and one timer.

• counter: attached to the input port, will count all the falling edges
• timer: invoke an ISR every and check the value of the counter. Depending on this value, we can determine if we're receiving 0, 8 or 9 pulses. This gives us the value of one bit.

We then need, every 8 bits, to save somewhere the value of a whole byte. This could either be handled in the aforementioned timer ISR, or via a third timer, but we have no idea yet which is preferable. That will come as we code, I guess.

This approach should cover all our needs, since we know a priori whether we need to demodulate high or low data rate and single or double subcarrier. The only change we might need would be to recalculate the timers when setting up the codec if using low data rate (multiply by 4, from the standard).

Edit: No, the above wouldn't work. Did I tell you we are out of the loop? I can confirm. It took us way too much to spot the issue here: f_c/4 is a too fine measurement and it would be impossible to differentiate the two frequencies; there would be only one falling edge per f_c/4 period with both f_c/28 and f_c/32.

We also recalled Xmega offers a frequency measurement feature via its event system, 8045A-AVR-02/08 § 6.3 suggests an algorithm to do so. We could then set up a:

• counter: attached to the input port, will count all the falling edges
• timer: every 18,58 μs (not 18,88), check the frequency of the data we've just received. Every 2 calls, check wether we got high->low or low->high frequencies and generate the corresponding bit. Also, if this is the first "half" of a bit and we received data on a high frequency account for additional 0,3 μs in current timer.

Have you already laid out a plan to implement VICC-VCD sniffing? Would you like to expose it here so we can exchange ideas? We'd love some criticism on our idea, so we can figure out any pitfall before we start to write code.

Given that we currently have some spare time, once we figure out a solid plan, we could start working together on this project. Would you mind firing me or @MrMoDDoM an email so we can maybe use a faster mean of communication?

PS My iso15_sniff hasn't been merged with the last commits in master, so give me some time to update it.

[cacke-r]

Hi @ceres-c , @MrMoDDoM ,

great to hear that you are also still willing to continue the paused activity.
To you question, yes I'm aware of the Air interface (ISO15693-2) - and I also already tried to understand your ideas from
the comments in the code.

For further discussions I'd raise an e-mail to both of you.
My plan as of now was to understand your ideas and get it working :-)

One big question I still have, which I was not able to figure out now:
The ISO15693-2 shows a nice digital signal for the VICC->VCD communication. But in fact
it is just the envelop of the modulated carrier. My question is - what signal do we see on the AVR port ?
(is the carrier already filter out by the demod HW) - or do we need to analyze the modulated carrier ?

[ceres-c]

You just reminded me that (luckily) we laid out our ideas from back then as comments in the sniff codec. Honestly, I did not remember this fact at all: turns out we almost reinvented the wheel today, since the ideas we tried to come up with were almost the same we had 2 years ago, and probably we fell into the same pitfall :)

I'm not sure @MrMoDDoM has a public email somewhere so, once you write me I'll add him to the conversation. @fptrs I guess you're busy, so we could either keep you posted writing relevant updates here, or add you to the conversation as well.

Yes, the MCU already sees demodulated output, but I'm pretty ignorant on the hardware details. I'll hook up my scope to the port one of these days

(Unrelated: I still have to buy a tonie and fix my branch for that)

--edit-- Just impulse bought a tonie. I guess that will be a good addition to the "stuff I hacked" box

[cacke-r]

Hi all,
pls find my latest changes to make the iso15xxx sniffing work for me (VCD->VICC only) here:
https://github.com/cacke-r/ChameleonMini/tree/iso15_sniff

I tried to create a PR on @ceres-c but failed tonight :-) will try again in the next days.

Regards
cacke-r

[fptrs]

Hi guys,
sorry for the late reply. @ceres-c did you already take some picture with the scope? I would like to join your conversation so that I can throw in a few ideas.

[ceres-c]

Yup, I've taken a lot of measurements in the last three weeks, and now have a fully working sniffer in my repo :)

I have tested my code with both my demo board (ST m24lr-discovery) and different phones with success. Moving the reader or the tag in the field did not yield any issue, as long as the chameleon was between the two. I had to abandon dual subcarrier due to issues with SOF identification: I could not identify a threshold to reliably count pulses, so it was impossible to know when the first 27 pulses ended and the 24 pulses started. Pulses counting proved to be unreliable when different tags were used: the slight differences in the shape of subcarrier pulses generated by different products would result in erroneous counts.

@cacke-r was having some issues with my code on a toniebox, so we're trying to debug it at this point.

BTW one Chameleon died in the process, I hope Peta won't come for me.

[fptrs]

@ceres-c Looks really good. I just tested it with my phone. If I understand correctly you use the ADC to determine a suitable threshold. It might be also a good idea to take a look at the difference between DEMOD-READER and DEMOD during transmission. I suggest taking scope pictures including both signals as well as their difference, for the dual subcarrier case and also for a response from a tonie. If you can share the scope pics I am happy to take a look.

[ceres-c]

Yes, I am using the ADC to both find a first suitable threshold and then increase the threshold once the chameleon starts to see pulses.

I've seen the two signals on a scope and I am indeed using both of them on purpose: first threshold is calculated from DEMOD, further on DEMOD-READER is used because, albeit different, it's easier to sample since it's not returning to zero and will then more likely yield useful data.

I don't have a toniebox to test, so I'm probably calling it a day right now. I'm going to play the "works on my machine" card and leave the fine tuning of the threshold to someone else. Getting to this point took already too many hours.

[fptrs]

My idea was to use the DEMOD-READER and DEMOD signal both as input to the AC, most of the time the signals are quite equal but since the DEMOD-READER signal passes an additional low pass filter it is slower and we might not need the DAC for a threshold. Anyway nice work @ceres-c and hopefully we get the tonies to work again.

[ceres-c]

I'll be damned, this is smart: I'm going to try it right now. Wait to merge the PR

[ceres-c]

Ok, it is indeed much more reliable when the signal is in a sensible range, but I'm not sure it'd help with smaller signals since it's still going to miss the first few pulses. Also, with a specific card (EM4233), the count is completely out of place: with high antenna coupling, the reading could vary from 21 to 40 pulses on first pause. With these results, it would be impossible to implement dual subcarrier anyway

I could indeed do without the DAC threshold, though, and retain current "heuristic" to decode single subcarrier, albeit simply changing the ADC source results in wrong decoding, so I might have to fix something else as well

--edit--
I've been playing around with this and due to the shape of signals, after a pause, when a signal is faint, there would be too few crossings of the two signals, thus it's even less reliable. At least with my setup and an EM4233 tag. It might be an unlucky specimen, but still with previous code it did work (without physically moving anything in the setup)

[ceres-c]

This is the last modulated bit-half of the SOF, as you can see READER-DEMOD is indeed not crossing DEMOD, so... I don't know.

[ceres-c]

@cacke-r do you mind testing this branch with the toniebox? If it fixes your issues, we can work with @fptrs idea