ISO 15693 Read/Write Commands Non-Functional (Broken on 06/12/2015)

[digitalentropy]

I've been working with TI Tag-It's recently and I've noticed that while I used to have quite reliable reads and writes, they somehow got broken at some point.

On v2.0.0 I can dump a whole tag via "hf 15 dumpmemory" quite reliably on several tags. Reads and writes via "hf 15 cmd" also seem to work great. However, on any recent builds I get either no communication with the tag, or a CRC error at best. At most I can grab the UID, but that's it.

[marshmellow42]

hmmm i'll try to take a look in a bit. it doesn't look like much has changed here in years so i don't see anything obvious..

looking at the code a little i am not sure what (int8_t)AT91C_BASE_SSC->SSC_RHR returns but if it is ever > 64 or < -64 we might have an issue with lines: 322, 460, 629, 683 (but if it is an issue it has been that way a long time)

as int8_t r = ABS(b) + ABS(prev); (adding the absolute value of 2 int8_t(s) might overload an int8_t) @pwpiwi shouldn't r be a uint8_t?

[marshmellow42]

@digitalentropy can you confirm that it is broken on release v2.1.0 and above?

[digitalentropy]

I don’t have a Tag-It handy with me at the moment but I can test again when I get home next week. I know for sure 2.2.0 is broken, and I’m reasonably certain 2.1.0 was broken as well but I am not 100% sure. I also have some other ISO 15 tags that I check with at home, as I imagine it’s broken for that as well since they use the same protocol.

On Apr 19, 2017, at 6:26 PM, marshmellow42 notifications@github.com wrote:

@digitalentropy https://github.com/digitalentropy can you confirm that it is broken on release v2.1.0 and above?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Proxmark/proxmark3/issues/280#issuecomment-295530859, or mute the thread https://github.com/notifications/unsubscribe-auth/ABWMvsWGJ98K5lHNW66sZqg9pXei7a8oks5rxrQ4gaJpZM4NAFyy.

[marshmellow42]

It looks like the BigBuf changes and the lf hf split happened around then, maybe there is an array clearing got moved that messes with the timing. I'll look closer and test with some tags tomorrow.

[digitalentropy]

Sounds good. If it’s unclear, I will re-test as soon as I get back.

On Apr 19, 2017, at 6:37 PM, marshmellow42 notifications@github.com wrote:

It looks like the BigBuf changes and the lf hf split happened around then, maybe there is an array clearing got moved that messes with the timing. I'll look closer and test with some tags tomorrow.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Proxmark/proxmark3/issues/280#issuecomment-295534476, or mute the thread https://github.com/notifications/unsubscribe-auth/ABWMvtqYk6BXc7Aun8XijRWgkb4yXDADks5rxrbggaJpZM4NAFyy.

[iceman1001]

it looks like a combo of BigBuff changes (fixed mem_offsets used) and the IQ pairs.

ABS(int8_max) would be 127. So a uint8_t will fit 127+127.

And demod is done both on client and on device side. Seems like the hf 15 is done on client, and hf 15 cmd is done on device

[pwpiwi]

uint8_t would be correct. However, this shouldn't be the root cause of this issue, because it had been an int8_t since ages.

[marshmellow42]

ok so it is fully related to the fixes to 14b pwpiwi made a long time ago. it functioned at commit c3dca45 but didn't at 705bfa1 and i noticed they share a fpga mode that was changed: FPGA_MAJOR_MODE_HF_READER_RX_XCORR https://github.com/Proxmark/proxmark3/commit/705bfa1058837ae60f014458b0a01e88cdf5839d#diff-52f7e8375be7bccc09a5aeeeb476df79 @pwpiwi, thoughts? i'll try to narrow down the exact commit.

[marshmellow42]

yep so 51d4f6f mostly broke 15693. and i bet it is due to the shared xcorr fpga code.

[pwpiwi]

Yeah, I remember. When fixing 14b I stripped some parts of xcorr in order to exclude fpga issues. I then forgot to add it back in and nobody cared for years.

I have ordered some iso 15693 tags today...

[iceman1001]

Don't confuse the possiblity to use an older firmware with no caring. We've got issue #20 since 2014. Very few ppl knows how to fix fpga related issues and I've not seen @pwpiwi and @holiman being active for a while. One year? two years? 2015 was the last time when we had many active contributors.

With @pwpiwi back, there is a good chance of getting this one right again.

[pwpiwi]

You mean it wasn't working even before my Fpga changes?

[marshmellow42]

Sim wasn't working, but reading was.

[iceman1001]

your changes broke the reading most likely. There are some oldstyle usage of bigbuff with offsets instead of yr new bigbuf_malloc, which is one part of the problem. The other part could be fpga changes.

Or has someone identified the cause of failure?

[digitalentropy]

Okay, after many compiles and re-flashes, I've confirmed @marshmellow42 comment above and narrowed down the commit that broke the 15 command-set. Reading and writing to ISO 15 tags before @pwpiwi commited 51d4f6f1 on 06/12/15 works. Beginning with that commit, it doesn't appear detect 15 tags properly, let alone read them.

[pwpiwi]

Okay, after many compiles andt re-flashes, I've confirmed @marshmellow42 comment above

I am sorry that you wasted so much time. I thought that I was clear enough above: I had removed ISO15693 FPGA code in 51d4f6f. I need to add it back in. I have ordered some ISO15693 tags for testing. They didn't arrive yet.

[digitalentropy]

@pwpiwi No apologies needed of course. I somehow missed that comment before but narrowing it down was a good exercise anyway.

Where are you based? I can possibly send you some tags/hardware as well.