ISO14443A_READER

[enporter]

So I am having a little trouble with the Reader function. I am trying to display information on a card. Now its not a Mifare Ultralight card but it is ISO1443A standard. I want to analyze the information on the card but sniffing the card with a reader does return anything in the terminal with LIVEMODE so I activate reader but which command returns the information on the card? I'm assuming DUMP_MFU only works with Mifare cards specifically? GETUID command works and returns: ATQA:0400 UID:BF8BE6C1 SAK:20

Setup: Windows 7 Tera Term Chameleon

[geo-rg]

OK, first of all: The sniff mode currently only supports sniffing the reader->card direction - only with 106 kbit/s.

Regarding the reader mode: on application layer, there is not so much implemented. The DUMP_MFU command only can dump the contents of MiFare Ultralight cards. Then there is GETUID, which only gets the UID. And then there is IDENTIFY, which tries to identify the cards type.

So what you can do now is:

• implement a protocol on the Chameleon, which reads information/data from your card. Therefor, you could start with a look at Firmware/Chameleon-Mini/Application/Reader14443A.c
• implement a protocol on your PC using python. So for this case I would encourage you first to experiment around with SEND and SEND_RAW (see documentation) and then write a python script (or any language which has access to serial ports) to communicate with the Chameleon and use these commands. On the python-side you might start with the python scripts provided in the Software folder of this project.

The second idea might be your only choice, if your card uses other cryptography than AES or DES, since you would need to implement this on Chameleon for the first case.

If you plan on doing this, I also would like to encourage you to make your development open on GitHub, so others can join you, which would make your development much easier and also we would love to use your contribution on the main project.

[brcangs]

I have a similar problem that I don't get a response from a pretty old card using the functions GETUID or IDENTIFY. I am quite positive the card is either MIFARE or LEGIC.

What could be the potential reasons for not receiving a response? (for instance, could the cryptography prohibit a response or, although I doubt it, might the card use low frequency if it's not one of the above). Finally, where could I start with SEND / SEND_RAW? I have been going through the documentation and scripts, but this didn't help me much unfortunately. Is there any literature you could recommend to learn more about the byte strings for smart cards?

Thank you!

[geo-rg]

I'm not completely sure whether LEGIC uses ISO 14443A or ISO 14443B. If it is a LEGIC card and LEGIC uses type B, the configuration ISO14443A_READER cannot talk to it.

The card selection process is not secured by any cryptography. Most likely your card does not speak ISO 14443A. You could start with SEND 26 (which is the request command, every ISO 14443A card can answer to that).

There are the standards. Read - for example - the ISO standard 14443 parts 3 and 4 to understand the communication. They should be found somewhere in the internet.

[geo-rg]

Hi @enporter and @brcangs Do you have still any questions?

[enporter]

Oh I still have questions of course! But I had to put the project on hold for a higher priority project so I haven't even had the chance to work on it.

Enporter

On Wed, Jul 12, 2017 at 8:04 PM, Georg Land notifications@github.com wrote:

Hi @enporter https://github.com/enporter and @brcangs https://github.com/brcangs Do you have still any questions?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/emsec/ChameleonMini/issues/97#issuecomment-314735874, or mute the thread https://github.com/notifications/unsubscribe-auth/AX70pEfzmmcML8oY9Oe5EABF71jxpfE_ks5sNKgsgaJpZM4MBZK_ .

[Coffeecup201]

Hi all, I'm pretty shure that LEGIC PRIME uses ISO 14443A. I still have Problems to read or sniff a LEGIC PRIME key. Do you know any commands to get information from the key?

[david-oswald]

To my knowledge Legic Prime uses an own standard, which they actually tried to standardise as ISO14443 F, see https://events.ccc.de/congress/2009/Fahrplan/attachments/1506_legic-slides.pdf. You will need to write a corresponding codec to sniff or emulate. Please open a separate issue for this.

[robfullagar]

Hi all I just upgraded to the latest version - ChameleonMini RevG 170712 using LUFA 151115 compiled with AVR-GCC 4.9.2. Based on the open-source NFC tool ChameleonMini. https://github.com/emsec/ChameleonMini commit 3c0435c

I set the chameleon to config=ISO14443A_READER and after that when I issue identify or getuid for the cards below I get time out error, I have increased the time out but when it get over timeout=100 the chameleon reboots. Cards tested - mf_classic 1k mf_classic 4k mf_ultralight

They all read fine in cardpeek mifair reader.

I dont recall using this mode before the upgrade so cant say if it worked before I upgraded.

Any pointers?

Rob

[geo-rg]

Hi @robfullagar I just flashed the firmware you write about and did the following right after boot: config=ISO14443A_READER identify I did this with about 10 MF Classic 1K and about 10 MF Ultralights even with different form factors. Every identify was finished successfully with no sensible delay. Thus, it is no software error.

Is your Chameleon a self-built one? Where did you buy it from? Please note that we cannot give profound support for self-built Chameleons or Chameleons from any other distributor than Kasper & Oswald since in these cases we do not know their hardware constitution.

[robfullagar]

Hi Georg

Thanks for the reply.

I bought the Chameleon from the K&O webshop (ChameleonMini RevG Standard (red)) on the 7th Feb 2017 for 99.96 Euros, I have the invoice number if needed.

We have just changed offices and wanted to identify and clone the cards from the new office if possible.

I have MF classic 1k and 4k and some MF ultralight cards, they all read fine using the ACR1251 reader.

I can set the Chameleon to emulate any of the cards change the UID and have the ACR1251 read the chameleon and display the UID so that part seems to be working fine. Also with the chameleon resting on the ACR reader RSSI? returns a value (11mv) dont know is that is what is expected

If I change the timeout or threshold values to much, during the getuid or identify command the Chameleon seems to drop the Com port and I have to reconnect, so I have stopped playing with those and left them at default.

I am running windows 10 Pro 64bit, and teraterm or parallex terminal, same resuts with both dropping the comm port and reconnecting again.

I also tried using a powered hub, but no change.

Cheers

Rob

On 9 November 2017 at 08:48, Georg Land notifications@github.com wrote:

Hi @robfullagar https://github.com/robfullagar I just flashed the firmware you write about and did the following right after boot: config=ISO14443A_READER identify I did this with about 10 MF Classic 1K and about 10 MF Ultralights even with different form factors. Every identify was finished successfully with no sensible delay. Thus, it is no software error.

Is your Chameleon a self-built one? Where did you buy it from? Please note that we cannot give profound support for self-built Chameleons or Chameleons from any other distributor than Kasper & Oswald since in these cases we do not know their hardware constitution.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/emsec/ChameleonMini/issues/97#issuecomment-343086679, or mute the thread https://github.com/notifications/unsubscribe-auth/AYe4Dk-hDPgUgzU3x_4A97KE4O1p2QlKks5s0rxogaJpZM4MBZK_ .

[geo-rg]

Hi @robfullagar no offense, I just wanted to clarify that Chameleon replicas can be very different - we appreciate your support for the original project!

The behavior you describe is very unusual. The Chameleon should not simply drop the COM port. Even when I play around with timeout (set it to 100, set it to 0) or with the threshold, the Chameleon does not crash.

What exactly causes the crash (which exact procedure causes the behavior you describe)? Please set logmode=memory, then cause another crash, reconnect and then run logdownload (or use chamlog.py for downloading and displaying the log) - append the result to your answer.

To me currently it seems like a hardware problem.

[robfullagar]

crash.log

Georg

Attached is the log, this is with timeout=150 and threshold=100, using a mf classic 1k card on the chameleon and running identify

C:\temp\ChameleonMini-master\ChameleonMini-master\Software>c:\PYTHON361\python.exe CHAMLOG.PY -p com5 -v > crash.log [2017-11-09 11:59:48.070402] Opening serial port com5 succeeded [2017-11-09 11:59:48.074289] Executing <VERSION?>: 101:OK WITH TEXT [2017-11-09 11:59:48.078195] Response: ChameleonMini RevG 170712 using LUFA 151115 compiled with AVR-GCC 4.9.2. Based on the open-source NFC tool ChameleonMini. https://github.com/emsec/ChameleonMini commit 3c0435c [2017-11-09 11:59:48.082109] Executing : 101:OK WITH TEXT [2017-11-09 11:59:48.082109] Response: NONE,MF_ULTRALIGHT,MF_CLASSIC_1K,MF_CLASSIC_1K_7B,MF_CLASSIC_4K,MF_CLASSIC_4K_7B,ISO14443A_SNIFF,ISO14443A_READER [2017-11-09 11:59:48.086007] Executing : 110:WAITING FOR XMODEM [2017-11-09 11:59:48.086007] Starting XMODEM Reception [2017-11-09 11:59:48.230431] 17152 Bytes received in 0.14 sec. (118762 B/s) [2017-11-09 11:59:48.230431] Closing serial port

You will notice last entry is boot.

Cheers

Rob

On 9 November 2017 at 10:10, Georg Land notifications@github.com wrote:

Hi @robfullagar https://github.com/robfullagar no offense, I just wanted to clarify that Chameleon replicas can be very different - we appreciate your support for the original project!

The behavior you describe is very unusual. The Chameleon should not simply drop the COM port. Even when I play around with timeout (set it to 100, set it to 0) or with the threshold, the Chameleon does not crash.

What exactly causes the crash (which exact procedure causes the behavior you describe)? Please set logmode=memory, then cause another crash, reconnect and then run logdownload (or use chamlog.py for downloading and displaying the log) - append the result to your answer.

To me currently it seems like a hardware problem.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/emsec/ChameleonMini/issues/97#issuecomment-343107925, or mute the thread https://github.com/notifications/unsubscribe-auth/AYe4DpRPuL7bMf2vMVgcDz2Ua2jYFtVDks5s0s-sgaJpZM4MBZK_ .

[robfullagar]

Georg

Same card read using cardpeek and ACR12511U-M1, see image.

Cheers

Rob

[image: Inline images 1]

On 9 November 2017 at 10:10, Georg Land notifications@github.com wrote:

Hi @robfullagar https://github.com/robfullagar no offense, I just wanted to clarify that Chameleon replicas can be very different - we appreciate your support for the original project!

The behavior you describe is very unusual. The Chameleon should not simply drop the COM port. Even when I play around with timeout (set it to 100, set it to 0) or with the threshold, the Chameleon does not crash.

What exactly causes the crash (which exact procedure causes the behavior you describe)? Please set logmode=memory, then cause another crash, reconnect and then run logdownload (or use chamlog.py for downloading and displaying the log) - append the result to your answer.

To me currently it seems like a hardware problem.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/emsec/ChameleonMini/issues/97#issuecomment-343107925, or mute the thread https://github.com/notifications/unsubscribe-auth/AYe4DpRPuL7bMf2vMVgcDz2Ua2jYFtVDks5s0s-sgaJpZM4MBZK_ .

[robfullagar]

Georg

Did you get the log and screen shot I sent?

Cheers

Rob

On 9 November 2017 at 10:10, Georg Land notifications@github.com wrote:

Hi @robfullagar https://github.com/robfullagar no offense, I just wanted to clarify that Chameleon replicas can be very different - we appreciate your support for the original project!

The behavior you describe is very unusual. The Chameleon should not simply drop the COM port. Even when I play around with timeout (set it to 100, set it to 0) or with the threshold, the Chameleon does not crash.

What exactly causes the crash (which exact procedure causes the behavior you describe)? Please set logmode=memory, then cause another crash, reconnect and then run logdownload (or use chamlog.py for downloading and displaying the log) - append the result to your answer.

To me currently it seems like a hardware problem.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/emsec/ChameleonMini/issues/97#issuecomment-343107925, or mute the thread https://github.com/notifications/unsubscribe-auth/AYe4DpRPuL7bMf2vMVgcDz2Ua2jYFtVDks5s0s-sgaJpZM4MBZK_ .

[geo-rg]

Hi @robfullagar, I have seen both log and screen shot. I assume you did not reboot the Chameleon yourself and you are NOT using the Chameleon only powered with the Battery? Please run an autocalibrate in reader mode with any card on top of the Chameleon and with logmode=memory and send the log.

[robfullagar]

autocalibrate.log Georg

I am powering the Chameleon over USB and no I didnt reboot it, it drops the comm and then it reconnects during the identify command causing it to fail.

Log attached.

Cheers

Rob

C:\temp\ChameleonMini-master\ChameleonMini-master\Software>c:\PYTHON361\python.exe CHAMLOG.PY -p com5 -v > autocalibrate.log [2017-11-13 09:28:38.457940] Opening serial port com5 succeeded [2017-11-13 09:28:38.457940] Executing <VERSION?>: 101:OK WITH TEXT [2017-11-13 09:28:38.457940] Response: ChameleonMini RevG 170712 using LUFA 151115 compiled with AVR-GCC 4.9.2. Based on the open-source NFC tool ChameleonMini. https://github.com/emsec/ChameleonMini commit 3c0435c [2017-11-13 09:28:38.457940] Executing : 101:OK WITH TEXT [2017-11-13 09:28:38.473562] Response: NONE,MF_ULTRALIGHT,MF_CLASSIC_1K,MF_CLASSIC_1K_7B,MF_CLASSIC_4K,MF_CLASSIC_4K_7B,ISO14443A_SNIFF,ISO14443A_READER [2017-11-13 09:28:38.473562] Executing : 110:WAITING FOR XMODEM [2017-11-13 09:28:38.473562] Starting XMODEM Reception [2017-11-13 09:28:38.615167] 18432 Bytes received in 0.14 sec. (130165 B/s) [2017-11-13 09:28:38.615167] Closing serial port

On 13 November 2017 at 09:17, Georg Land notifications@github.com wrote:

Hi @robfullagar https://github.com/robfullagar, I have seen both log and screen shot. I assume you did not reboot the Chameleon yourself and you are NOT using the Chameleon only powered with the Battery? Please run an autocalibrate in reader mode with any card on top of the Chameleon and with logmode=memory and send the log.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/emsec/ChameleonMini/issues/97#issuecomment-343858255, or mute the thread https://github.com/notifications/unsubscribe-auth/AYe4DmJU5CblKj-AukUvsis0U5Y8yEBsks5s2AlBgaJpZM4MBZK_ .

[geo-rg]

OK, I really think that this might be a hardware problem. Could you please send an e-mail to chameleon@kasper-oswald.de and we'll arrange an exchange.

[robfullagar]

Georg

What do you want in the email..reference to this thread and my postal address?

Rob

On 13 November 2017 at 09:48, Georg Land notifications@github.com wrote:

OK, I really think that this might be a hardware problem. Could you please send an e-mail to chameleon@kasper-oswald.de and we'll arrange an exchange.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/emsec/ChameleonMini/issues/97#issuecomment-343866171, or mute the thread https://github.com/notifications/unsubscribe-auth/AYe4DqO9O3sMjvRB0iMHdRk3pguMnsD9ks5s2BBngaJpZM4MBZK_ .

[geo-rg]

@robfullagar Yes, only postal address should be ok. Sorry, forgot to mention this ;)

[geo-rg]

I suppose all the questions have been answered. If not so, please re-open this issue.