Fail to read some Singapore cards (EZLink, NETS Flashpay)

[ianeinser]

Please read the guidelines for contributions (CONTRIBUTING.md) before submitting new issues to this tracker. Failure to adhere to these guidelines may cause offense.

Unsupported card requests

If the card is not presently supported by Metrodroid:

• [* ] I have read and acknowledged the New cards wiki page
• [* ] I can provide dumps, transaction history, and balance records for more than one card from the operator.
• [ *] I have attempted to understand the card format on my own.
• [* ] I have provided notes on what I've found so far.

Description of the issue

Singapore EZLink, Hong Kong Octopus and Indonesia KMT cards cannot be read but all of them can be read using Farebot.

For card-specific issues

• Name of the card type: NfcA, NfcB and Isodep
• Name of the transit operator: EZ Link, Octopus and KMT
• Location: Singapore, Hong Kong and Indonesia

For all issues reading a currently supported card format (eg: balance shown is incorrect), please export a card dump from Metrodroid and email it to me privately.

Steps to reproduce

1. Just tap any EZ Link card.. I tried with 4 different EZ Link cards but none can be read
2. Just tap any Octopus card.. app can identify the card but no content can be read
3. Just tap any KMT card.. it cannot be read

Expected behaviour

It shows balance and/or (routes)

Actual behaviour

Data dump function is called but none is shown

Workarounds (if any)

Logs

Generate a bug report ZIP using the instructions here: https://developer.android.com/studio/debug/bug-report.html

Please do not attach it to this issue. You may be asked for a copy later via private email.

Details from About screen:

• Version: 2.9.37-208
• Model: Mi 5
• Manufacturer: Xiaomi
• Android OS version: 8.0
• NFC: enabled
• MIFARE Classic: supported

FYI: all those cards can be read using Farebot though the app is not stable and crashes many times until it can read the cards

[micolous]

Please provide the missing details from the About screen. I am unable to troubleshoot your issue without this information.

[ianeinser]

Please provide the missing details from the About screen. I am unable to troubleshoot your issue without this information.

@micolous Thanks for the attention. Do you need to see the log file? I tried to use Farebot to read those cards and the app can read and show the balance and/or routes but it crashes many times

[micolous]

Yup, the log file would also help. Thanks!

Can you read any card successfully (ie: cards other than the ones you mentioned)?

Are you running any application that reads NFC cards from the background? (eg: Tasker)

Do you have a case on the phone? Does the issue continue if you remove it from the case?

What I'm thinking at the moment:

The Octopus and KMT issues might be #41 (FeliCa cards seem to drop out more than others).

I've accidentally broken EZ-Link in the past -- I don't have one of these cards, and its CEPAS implementation doesn't support ISO7816 application selection properly (so I have to try to check for this first).

As you're building from git master, it should give communication traces, as long as ISO7816Protocol.ENABLE_TRACING = true.

[micolous]

FYI, I can't find any log from you in my emails.

However, @phcoder and I have recently acquired some Singapore CEPAS cards (of different types), so we've had more opportunities to test this.

I'm currently working from the merge of #370 with the rewrite of FeliCa and KS X 6924 support patched on it, but for CEPAS this shouldn't matter.

Both of these CEPAS cards appear to be ISO 14B cards (I didn't realise this earlier).

• EZLink: read successfully, and it looks like all the files are read
• NETS FlashPay: does not read (phone doesn't make a sound!) -- but has some interesting errors from Android:

22:16:45.911 D/NativeNfcTag: Connect to a tech with a different handle
22:16:46.013 E/libnfc_nci: [ERROR:NativeNfcManager.cpp(319)] nfaConnectionCallback: NFA_SELECT_RESULT_EVT error: status = 3
22:16:46.014 E/libnfc_nci: [ERROR:NativeNfcTag.cpp(672)] reSelect: tag is not active
22:16:46.014 E/libnfc_nci: [ERROR:NativeNfcTag.cpp(1167)] nativeNfcTag_doCheckNdef: tag already deactivated
22:16:46.014 D/NativeNfcTag: Check NDEF Failed - status = 3
22:16:46.014 E/libnfc_nci: [ERROR:NativeNfcTag.cpp(540)] nativeNfcTag_doConnect: tag already deactivated
22:16:46.014 D/NativeNfcTag: Connect Failed - status = 255
22:16:46.014 E/libnfc_nci: [ERROR:NativeNfcTag.cpp(738)] nativeNfcTag_doReconnect: tag already deactivated
22:16:46.014 E/libnfc_nci: [ERROR:NativeNfcTag.cpp(801)] nativeNfcTag_doDisconnect: tag already deactivated

I see similar behaviour on a Nexus 5X and a Pixel 1. I can't even make NXP TagInfo read the NETS FlashPay card, even when it is in "Reader Mode".

Both cards are readable by a Proxmark3.

A quick glance at the differences using hf 14b snoop (on the PM3), I can see that the card appears to be failing part of the handshake. Looking at the NETS FlashPay:

Start	End	Src	Data	CRC	Annotation
1726111	1726111	Rdr	05 00 00 71 ff	ok	REQB
1726545	1726545	Tag	50 c9 2c e8 cc 1c 91 26 11 f7 71 85 84 27	ok
1726957	1726957	Rdr	1d c9 2c e8 cc 00 08 01 00 be d3	ok	ATTRIB
1727171	1727171	Tag	00 78 f0	ok
1727960	1727960	Rdr	c2 66 15	ok	?
...	...	Tag	(no response from tag)
1729224	1729224	Rdr	c2 66 15	ok	?
1729367	1729367	Tag	c2 66 15	ok

The whole process then restarts with another REQB.

Compared to a working EZ-Link card:

Start	End	Src	Data	CRC	Annotation
1186337	1186337	Rdr	05 00 00 71 ff	ok	REQB
1186741	1186741	Tag	50 c7 3e 57 8a 1c 00 00 11 77 81 85 83 ae	ok
1187152	1187152	Rdr	1d c7 3e 57 8a 00 08 01 00 80 64	ok	ATTRIB
1187337	1187337	Tag	00 78 f0	ok
1188119	1188119	Rdr	c2 66 15	ok	?
1188289	1188289	Tag	c2 66 15	ok	success here!
1231938	1231938	Rdr	05 00 00 71 ff	ok	REQB
1232336	1232336	Tag	50 c7 3e 57 8a 1c 00 00 11 77 81 85 83 ae	ok
1232746	1232746	Rdr	1d c7 3e 57 8a 00 08 01 00 80 64	ok	ATTRIB
1232928	1232928	Tag	00 78 f0	ok
1234451	1234451	Rdr	c2 66 15	ok	?
1234616	1234616	Tag	c2 66 15	ok	success here again!
1236338	1236338	Rdr	05 00 08 39 73	ok	REQB
1236736	1236736	Tag	50 c7 3e 57 8a 1c 00 00 11 77 81 85 83 ae	ok
1237129	1237129	Rdr	1d c7 3e 57 8a 00 08 01 00 80 64	ok	ATTRIB
1237310	1237310	Tag	00 78 f0	ok
1238501	1238501	Rdr	02 00 a4 04 00 07 d2 76 00 00 85 01 01 00 b7 d4	ok	Android selects AID d2760000850101 (NDEFv2)
1244896	1244896	Tag	02 6a 82 4b 4c	ok
1245998	1245998	Rdr	03 00 a4 04 00 07 d2 76 00 00 85 01 00 51 f1	ok	?
1251010	1251010	Tag	03 6a 82 97 16	ok	Android selects AID d2760000850100 (NDEFv1)

Both of these traces are from a Nexus 5X.

Based on what I can see:

• The NETS FlashPay card is not responding to c26615 (probably part of negotiation process) on the first attempt.
• It appears that the Android re-tries this command, but still treats it as a failure even if it later succeeded.
• Android always attempts to select an NDEF AID for IsoDep cards.
• CEPAS cards don't like selecting AID (I can't recall if it was "some" or "all"), and requires that you use the implicit default application. Metrodroid special cases CEPAS reading to handle this.

This is a combination of Android bugs and card bugs -- which I don't think we can do anything about.

I've been talking with @phcoder, and he also sees similar card reading failures on the Singapore Tourist Pass (also CEPAS and ISO 14443B).

(Edited: I didn't notice at first, but the AID used for the NDEF application changed on the first and second attempts -- I updated the trace notes accordingly.)

[micolous]

Also, I found this bug reported to Samsung, it appears their Broadcom NFC driver has a fair bit more debugging info, and the thread specifically mentions Singapore cards.

The errors they're getting there in the NDEF check are consistent behaviour with CEPAS cards.

I also found this other report which seems to indicate it may be a regression in Android 8.0, but given the traces, it doesn't appear that it's even getting to NDEF selection. And the phone I got the working EZ-Link trace from was running Android 8.1.

[micolous]

I've tried the NETS Flashpay card again with NXP TagInfo, but with Reader Mode, NDEF detection off, and force-restarted the app.

TagInfo just repeatedly detects the card again and again...

11:27:06.403D/NativeNfcTag: Starting background presence check
11:27:06.411D/NativeNfcTag: Connect to a tech with a different handle
11:27:06.610E/libnfc_nci: [ERROR:NativeNfcManager.cpp(319)] nfaConnectionCallback: NFA_SELECT_RESULT_EVT error: status = 3
11:27:06.610E/libnfc_nci: [ERROR:NativeNfcTag.cpp(672)] reSelect: tag is not active
11:27:06.613E/libnfc_nci: [ERROR:NativeNfcTag.cpp(540)] nativeNfcTag_doConnect: tag already deactivated
11:27:06.617E/libnfc_nci: [ERROR:NativeNfcTag.cpp(738)] nativeNfcTag_doReconnect: tag already deactivated

On the traces, it still looks like there's no response to the command after ATTRIB, but it now looks like TagInfo still tries to probe for NDEF AIDs (and others...)

Start	End	Src	Data (! denotes parity error)	CRC	Annotation
0	0	Rdr	05 00 00 71 ff	ok	REQB
433	433	Tag	50 b5 88 a7 b4 1c 91 26 11 f7 71 85 e0 f0	ok
844	844	Rdr	1d b5 88 a7 b4 00 08 01 00 c6 9a	ok	ATTRIB
1057	1057	Tag	00 78 f0	ok
1709	1709	Rdr	c2 66 15	ok	?
...	...	Tag	tag doesn't respond!
2974	2974	Rdr	c2 66 15	ok	?
3115	3115	Tag	c2 66 15	ok	responds on second try
41775	41775	Rdr	05 00 00 71 ff	ok	REQB
42209	42209	Tag	50 96 35 17 b0 1c 91 26 11 f7 71 85 fe 1f	ok
42619	42619	Rdr	1d 96 35 17 b0 00 08 01 00 9c 37	ok	ATTRIB
42832	42832	Tag	00 78 f0	ok
46822	46822	Rdr	02 00 a4 04 00 07 d2 76 00 00 85 01 01 00 b7 d4	ok	Select AID d2760000850101 (NDEF v2)
49354	49354	Tag	02 6a 82 4b 4c	ok	not found
50532	50532	Rdr	03 00 a4 04 00 07 d2 76 00 00 85 01 00 51 f1	ok	Select AID d2760000850100 (NDEF v1)
51362	51362	Tag	03 6a 82 97 16	ok	not found
52640	52640	Rdr	02 00 a4 02 00 02 2f 00 00 29 d8	ok	Select EF 2f00
53546	53546	Tag	02 6a 82 4b 4c	ok	not found
54765	54765	Rdr	03 00 a4 02 0c 02 2f 00 32 0d	ok	Select EF 2f00 with no FCI response
55558	55558	Tag	03 6a 86 b3 50	ok	incorrect parameters
56697	56697	Rdr	02 00 a4 02 04 02 2f 00 55 69	ok	Select EF 2f00 with FCP response
57602	57602	Tag	02 6a 82 4b 4c	ok	not found

(Communications continue with different variations, and then repeat.)

[micolous]

I've also found a plastic EZ-Link card which appears to have the same symptoms this NETS Flashpay card.

It appears that this is a bug in the cards themselves.

[matthew5025]

@micolous @phcoder May I ask how old are the cards that you had this problem with? I've had problems with reading older CEPAS cards using phones, but have not encountered many problems with newer cards.

[micolous]

@micolous @phcoder May I ask how old are the cards that you had this problem with?

I got some cards that were from 2019 that had this bug.