added ISO15693 emulation codec

[geo-rg]

We have a first draft of ISO 15693 emulation codec! We could verify that two readers actually can talk to the Chameleon.
The following things are new with this update:

• VCD->VICC both encodings (1-out-of-256 and 1-out-of-4)
• VICC->VCD both data rates, both encodings (single / dual subcarrier)

Please don't expect a perfectly working codec/application right now, the following things are still to do, in order of importance:

1. Testing of the dual subcarrier encoding, which has to be requested by a reader
2. Testing of the low data rate
3. Testing with various readers
4. Implementation of the application layer for various cards

After testing, a short report with the used reader name would be very nice and helpful.

[m2otech]

That's great news, thanks! Will take a look asap.

[geo-rg]

I forgot to mention: dual subcarrier and low data rate have not been tested yet! That's why testing this has a high priority.

[m2otech]

Hi @geo-rg I started looking at the code. First I flashed the Chameleon with the eep/hex file from the Firmware/Chameleon-Mini/Latest. The command CONFIG=? in the serial console does not return ISO15693, is this still a todo? How should I go about testing?

I also tried to compile the code myself, without success so far, but I'll figure that out... I used Eclipse with AVR Plugin, is that a good idea or is there anything better?

[vdwel]

I set the config to vicinity. Then as a first test, try to see if anything gets detected by my phone (Huawei P8 lite), but nothing gets detected. I am very sure my phone supports ISO15693. Any ideas?

[m2otech]

Hi @vdwel I also cannot detect anything, maybe we also need a correct dump? Right now I use the card-mifare-sample.bin (but that's a Mifare dump). Trying to figure out how to produce an ISO15693 dump. I don't think Chameleon can be used for this as it only works as ISO14443 reader. Maybe I'll try with the Proxmark...

[vdwel]

I also have a m24lr discovery board, which seems to communicate quite well. :-) I also have some iso15693 tags and chips here. Will do some more testing...

[edit] Did some more testing by implementing iso15693_SNIFF. When sniffing the MLR24-discovery board, I see understandable data, in all speeds (high, low, 10%, 100%, dual SC).. But when sniffing the communication between a tag and the phone, I get one command readable, and the rest is garbage:
19419 ms <+19419 ms>:CODEC RX (5 bytes) [260100f60a]
19432 ms <+19432 ms>:CODEC RX (12 bytes) [222b78d3f43f500104e08851]
19463 ms <+19463 ms>:CODEC RX (13 bytes) [222078d3f43f500104e00029e5]
19603 ms <+19603 ms>:CODEC RX (13 bytes) [26014078d3f43f500104e0924a]

[edit] It seems that this is not garbage. 22 2b (get sys info for specific tag), the bytes following is the UID of my tag. So it's simply not implemented in the appProcess yet. :-) Good job!! Let's build iso15693 tags now.

[vdwel]

I am implementing a tag now. When trying to send a lot of bytes (around 40 or more) with command "ISO15693_CMD_READ_MULTIPLE 0x23", read errors start to occur. With my m24lr and my phone as a reader. Any idea what could be the cause? I looks like some kind of timing issue.

[m2otech]

@vdwel Glad to hear you've done some progress. I haven't really found the time to look at the code seriously. If you don't mind sharing your code so far (those two implementations) and helping me get up to speed we can do this together and hopefully I can contribute my part ;-)

[vdwel]

@m2otech I actually have no clue how to fork a branch of a fork... So I'll just share a link with a zipfile to my source: http://www.fuzzybunny.eu/iso15693.zip

I've added: ISO15693_SNIFF and SL2S2002
Also added a dump of a SL2S2002 tag in dumps, called libraryBook.dump (it's a book from the Smurfs)

[m2otech]

Ok, thanks a lot. Will work on it today. Once we figure ISO15693 I'm sure we can figure Github too ;)

[m2otech]

@vdwel I've installed your FW and uploaded your dump... it works! Up to the point were the reader says it can't read the whole tag, that must be what you also mention. I will now try to implement one of the tags I want to emulate, following your approach and then investigate the issue. One question, how did you create the dump?

[vdwel]

@m2otech I got a book from the library.. they have iso15693 tags. Dumped it with my phone. But I can also dump it with the m24lr discovery kit. Very handy tool for debugging the chameleon. 😊

[m2otech]

Which app do you use? Haven't found one yet that can dump... I see that m24lr is not even that expensive, will probably get one.

[vdwel]

@m2otech I am using nxp taginfo on Android to scan/dump tags.

[m2otech]

I use that too, but I only see a text dump/report, no binary dump...

[vdwel]

Simply write a python script to covert to binary.

[m2otech]

Ok so that's basically a byte array of the memory content...

[m2otech]

So I've finally start to dig into the code, will continue tomorrow...

[geo-rg]

This looks like awesome progess! The problems you have described really sound like timing issues. I will try to reproduce the problem later this week and see what I can do.

[geo-rg]

@vdwel You may also add pull requests to my fork (feature-ISO15693 branch), which then could be added here. Also, we could discuss there better, since we could open an issue for every problem that occurs.

[vdwel]

@geo-rg I would love to do that.. But somehow I can't figure out how to fork your branch.. :S

[geo-rg]

@vdwel I just tried simply clicking Fork on the top right corner of my fork, which worked. Then I was able to change the files in the feature-ISO15693 branch in my own (new) account and create a pull request to my (old accounts) fork. When I accept this pull request it should be added to this pull request automatically (it has to be a pull request to branch feature-ISO15693).

[vdwel]

@geo-rg Hmm that’s interesting, maybe it’s because I already have a fork of emsec.. I just tried again with my phone, no luck. Will try again later today.

[geo-rg]

OK, I can see the problem. When I now try to fork the original rep with the new account, I am simply redirected to my geo-rg fork-fork.
I guess the solution is:

1. Create a new branch (e.g. feature-ISO15693) on your fork from emsec/ChameleonMini.
2. Download my fork-branch (geo-rg/ChameleonMini/feature-ISO15693 to your new feature-ISO15693 branch and commit this. Now you have an equal branch in your fork and thus effectively forked my fork.
3. You can now create pull requests to my fork: base fork is geo-rg/ChameleonMini with "base" feature-ISO15693 and head fork is vdwel/ChameleonMini with "compare" feature-ISO15693 (or any other name you give your branch).

[vdwel]

@geo-rg That's funny, I just did what you described, and then read your message. Couldn't wait until tonight.

[geo-rg]

@vdwel I noticed that my fork was not really up-to-date with the emsec repository, so I updated it. Now my fork (and also the feature-ISO15693 branch) contain all the changes that have been made in the original rep (e.g. automatic FRAM usage of the log function). This means that the code you have uploaded here has diverged from my feature-ISO15693 branch, but I don't think that it will be difficult to merge your changes to the updated branch.

[geo-rg]

Short update:
I fixed some problems, now TagInfo can read the emulated card. There were multiple problems:

• it's PageAddressCount, not PageAddressEnd, and the respective protocol field means the block count minus 1 (so a value of 0x00 means 1 block, 0x01 means 2 blocks etc.)
• the GetSystemInformation response was wrong at one similar point, so the app expected 5-byte-blocks, since the response said for block size 0x04, which means an actual size of 5 bytes, but later the emulation sent only 4 per block.
• when the option flag is set, the read command also has to respond with the block security information

Nonetheless, the app shows sometimes that there has occurred a communication problem.

The nfc-tools app can read the Chameleon, but does not stop at the end and wants to read more blocks. The emulation at this point cannot handle this and returns the FRAM contents. --> We need to add the error handling soon.

[vdwel]

Hmmm that's interesting, because I was using responses sniffed from a working set-up. So you'd expect those values are good.

[phillipnasher]

Hi people.

Sorry if is not relevant but I'm currently working on supporting the Chameleon Mini project (made a fork on my account) and I've made a start in implementing ISO15693 reader support. I've some spare time free this week and I hope to make some progress in implementing this feature. I've already defined the base code and added the option to allow you to identify an ISO15693 tag. ISO15693 codec reader support will be the main focus for this week.

Thanks

[geo-rg]

Hi @phillipnasher
it is relevant, but not really for this thread ;) Thanks for the information, we appreciate your contributions!

[geo-rg]

@vdwel How do you implement the iCode features? I found the data sheet directly on the nxp website: https://www.nxp.com/docs/en/data-sheet/SL136430.pdf It contains all the information needed for implementing the optional commands.

I can also implement some things but I would rather continue with the codecs since this is more complicated. Now, how should we proceed with the application layer?

[vdwel]

@geo-rg I would love to implement further features of the application. It's all a matter of finding time. I am still having problems when trying to read the emulated tag because it gets unstable when transferring more than 6 blocks of 4 bytes. With the read multiple blocks command (0x23). That makes debugging a little difficult.

I am not a specialist on this field.. Until now I was just reverse engineering the communication that I sniffed. So I haven't looked into iCode yet.

It would be great if you could fix the codec somehow so that this works... :-) I'll look into the application then.

[kaliginium]

Hi,

is it possible edit sniffing code in order to sniff both direction of communication? Even I can participate, but now I have no idea what is needed to do so.

[m2otech]

Hi @geo-rg any news on your side (codecs)? I am implementing EM42xx tags, I have problems similar to @vdwel (only a few bytes are read from the emulated tag). In which file(s) should I be looking if I wanted to try to do something about the codecs?

[kaliginium]

Hi,
I am trying to emulate EM4036 tag. So start to change sl2s2002.c:
I changed BYTES_PER_CHANGE to 8 and change readfunction to:

else if (Command == ISO15693_CMD_READ_SINGLE) {
if (ISO15693Addressed(FrameBuf, Sl2s2002Uid)) {
uint8_t PageAddress = FrameBuf[10];
FrameBuf[0] = 0; /* Flags */
MemoryReadBlock(FrameBuf + 1, PageAddress * BYTES_PER_PAGE, BYTES_PER_PAGE);
ResponseByteCount = 9;

As I want to emulate a writefunction too I did it like this:

else if (Command == ISO15693_CMD_WRITE_SINGLE) {
if (ISO15693Addressed(FrameBuf, Sl2s2002Uid)) {
uint8_t PageAddress = FrameBuf[10];
FrameBuf[0] = 0; /* Flags */
MemoryWriteBlock(FrameBuf + 10, PageAddress * BYTES_PER_PAGE, BYTES_PER_PAGE);
ResponseByteCount = 5;
}

But there must be some bug elsewhere, because when I try this functions with proxmark reader this

happen:
proxmark3> hf 15 cmd write -2 u 0 00 00 00 00 00 00 00 00
OK
proxmark3>
proxmark3> hf 15 cmd read -2 u 0
00 64 24 00 00 D3 A5 00 .d$.....
proxmark3>
proxmark3> hf 15 cmd read -2 u 0
E2 F1 78 BC DE 6F 37 9B ..x..o7.
proxmark3>
proxmark3> hf 15 cmd read -2 u 0
2A 15 8A 45 22 11 88 C4 *..E"...
proxmark3>

Any Ideas.

[ceres-c]

Do you guys have any update on iso 15 implementation? :)

[Rickventura]

This is my report related to 15693 emulation testing with chameleon mini rev G.
As a reader I used an Android 5 Asus zenfone 2 deluxe
cpu Intel Atom 2.3GHz
memory 4G
Software:
NFC-V READER version 5.0 (for LRi and M24LR products)
NFC Tools PRO edition 4.1
A reader aboard of a public device supposed to read Texas Tag-it tags was also tested.
I used a pc with ubuntu linux to compile the sources and flash the Chamelion mini.
The same pc was used with MS Windows 7 pro.
BELOW A FEW SCREEN SHOTS FROM TERATERM
VERSION?
101:OK WITH TEXT
ChameleonMini RevG 181002 using LUFA 151115 compiled with AVR-GCC 4.9.2. Based on the open-source NFC tool ChameleonMini. https://github.com/emsec/ChameleonMini commit e8500b5
SETTING?
101:OK WITH TEXT
2
CONFIG?
101:OK WITH TEXT
SL2S2002

ALL Chameleon COMMANDS available with the present release of the 15693 codecs seems to work correctly.
I have a few texas tag-it standard cards I wanted to emulate
Texas Instruments tag-it standard devices have 8 x 4 bytes( 32 bits) = 32 bytes of user memory
plus a 64 bits UID. Please refer to the link for more information http://www.ti.com/lit/an/sloa166a/sloa166a.pdf.
I uploaded the chameleon with the known contents of one of the cards.
I verified that the Chameleon's memory was correctly set by both downloading the memory content and using chameleon Mini Rebooted GUI.
I also changed the UID of the chameleon with the card's UID which bears the texas signature 0xE0 0x07 0xC0 + 5 bytes of factory generated UID.
Both The NFC Tools pro and the NFC-V recognized the chameleon as a texas tag along with the correct UID.
The NFC Tools pro could read the chameleon memory correctly all bytes were there.
the NFC-V apps couldn't read the content of the chameleon while it can correctly read the content of the real tag.
The reader aboard the public device didn't recognize the tag.

[Rickventura]

I've tested the iso 15693 SL2S2002 emulation with Chameleon mini rev G and the STMicroelectronics RF transceiver demo board . I uploaded the Chameleon Mini with the memory content of texas Tag-it standard tag.
The transceiver inventory request works and returns the correct tag's UID, although I couldn't figure why it returns an IC ref = 95. The transceiver is unable to read the memory content. The behavior is consistent with the previous tests where I was using an android cell phone STMicroelectronics-reader .
Note: The "TI tag-it standard" has only the reading single block command.

[ceres-c]

Time to close this merge?
Given that a PR based on this one has been merged, this is now mostly useless #182

[fptrs]

Hi @ceres-c ,
yes you are right. It is finally time to close this issue 😄