CODEWITHSUNDEEP
nfcsmartcardapdu
TMH92
TMH92

Reputation: 21

APDU always get response trailer SW1 SW2 = 0x67 0x00

I'm working on PN5180 module to read data from my ePassport (ICAO 9303). I can send RATS - ATS, PPS, so technically, now i can exchange data using APDU command. Firstly, i tried to select LDS1 but however i tried, i always get SW1 SW2 = 0x67 0x00, which means "Wrong length".

Here my code trace:

RATS: 0xE0 0x80

ATS: 0E 78 77 D4 03 4D 4B 6A 43 4F 53 2D 33 37

PPS: 0xD0 0x11 0x00

PPS_resp: 0xD0

APDU_SELECT: 0x0A 0x00 0x00 0x00 0xA4 0x04 0x0C 0x07 0xA0 0x00 0x00 0x02 0x47 0x10 0x01

APDU_SELECT_resp: 0x0A 0x00 0x67 0x00

So maybe my INF in APDU_SELECT is incorrect, but the problem is i have used PN532 to communicate, i could read my ePassport with the same INF (using InlistPassiveTarget and InDataExchange).

If anyone see this post and worked with PN5180 or smart card before, pls let me know.

Upvotes: 1

Views: 1151

Answers (2)

TMH92
TMH92

Reputation: 21

To everybody who is stuck in this problem like me,

It was my fault because i have read the ISO14443-4 version 2001 but ISO has updated it to ISO14443-4 2018 version. So the difference is about the Block format.

Take a look at Block format, in v2018, it's appended one byte as the first byte of the Block. It's Length byte!, when v2001 doesn't include it in its Format.

That's why whatever i tried, my ePassport always take 0x0c (right before 0x07, which is the true Lc) as the Lc. So that, it returned '6700' "Wrong length" all the time.

Link about ISO14443-4 2018.

Good luck to everybody read my post, thank you so so so much Maarten Bodewes!

Upvotes: 1

Maarten Bodewes
Maarten Bodewes

Reputation: 94038

I'm going to make a bit of a guess here; it may be the answer and it doesn't fit in a comment.

If you look at the I-block then the final nibble is defined as such:

  • b4 : CID following, if bit is set to 1
  • b3 : NAD following, if bit is set to 1
  • b2 shall be set to 1
  • b1 : Block number

I presume that this is the first APDU so the block number is probably the one initialized. However, as you both provide a CID and a NAT I presume that you need to set both of those to 1. That would make a nibble with value 1110 which translates to E, not A. To the card I would assume that the start of the APDU is off by one byte, receiving a 0x0C instead of a 0x07 as Lc.

I don't see anything particularly wrong with the APDU, so I presume that the error lies outside of it.

Upvotes: 0

Related Questions