APDU commands

Returning to the document I was referencing earlier, it explains an APDU as follows. "Smart cards generally work using a set of commands, sent from the application to the card in a block known as an APDU (Application Protocol Data Unit), and which the card will respond to with an APDU response. The response may be a simple “Ok – done that” confirmation message, or it might be some data, for example the contents of a particular file on the card, or an encrypted version of some data, using a secret key."

So this is where we need to go next. We need to understand what commands we can send, and what responses we receive.

ACR1552U Manual

Something that I discovered and downloaded some time back is the PDF Reference Manual for the precise card reader (the ACR-1552U) I am using. It has a lot of information in it, most of which made no sense when I first scrolled through it, but it is slowly starting to come into focus.

For example, section 5.3.1 describes the "ATR Protocol" which now makes (some) sense in light of what happened in the last episode, and 5.3.9 lists a bunch of ATRs that are returned by different cards.

Meanwhile, sections 5.3.2-5.3.8 describe APDU commands in various categories. Given that I have an APDU program at my fingertips, let's see what happens if we try using some of these commands.

Reading data off a Card

Section 5.3.3.1 describes an APDU command described as "Get Data (FF CA)" (where I presume "FFCA" refers to the leading two bytes of the command).

Based on the table, I think that a five-byte command "FF CA 00 00 00" should return the "UID/PUPI/SN of the Card" whatever that may be.

So, let's try that:

$ go run apdu/main.go


>> ff ca 00 00 00
<< 32BEA6C1 9000

Note: I tried to do this from within VSCode, but kept on just getting back "Unable to process `evaluate`: debuggee is running", so I think I was interacting with the debugger, not the program, but I couldn't figure out what magic was required to allow me to interact with the program.

Do I know what this means? No, I do not. I do know that the response is divided into two parts. The first four bytes are the response (the UID, PUPI and/or SN) and the other two bytes are the status - in this case 90 00 means "all good".

Time to pull in another Google hit. This article talks about "EMV" (whatever that is) and seems to have some level of understanding of what is going on, although also adds to my confusion because either two things are very similar, or there are typos. It talks about "selecting PSA" and then says "PSE". Are these the same, different, or is one a typo for the other? All the more confusing if "PSA" does indeed stand for Payment Systems Environment. Later on it gives the example of "SELECT CANDIDATE": is that the same thing or a different thing? If it is a candidate, does that mean there is a list somewhere?

Anyway, it has some bytes that look like a plausible APDU. Let's try that:With the room key:

>> 00 A4 04 00 0F 31 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00
<< 6A81

What does that mean? Well, if it's not 9000 it's an error code. There is a list of those (referenced in the article above) and it would seem that 6A81 means "Function not supported". Fair enough, it's a room key. Let's try it with the phone or with a real bank card:

>> 00 A4 04 00 0F 31 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00
<< 6A82

Different, but still an error: "File not found". OK, so given the description of what I'm trying to do, it would seem that the problem is that the folder I am trying to select is not there. Reading over the description in the article, it says that "there is a directory on the card commonly named “1PAY.SYS.DDF01” in the case a contact chip and “2PAY.SYS.DDF01” is always present on a contactless chip". Now, for those of you who don't read HEX ASCII well, the above is:

00 A4 04 00 - SELECT DSA (or DSE)
0F - 15 characters of data follow
31 50 41 59 2E 53 59 53 2E 44 44 46 30 31 - 1PAY.SYS.DDF01
00 - 00 response bytes expected

So, if the description above is to believed, I want to be looking for 2PAY not 1PAY. Let's try that (i.e. byte 6 changes from 31 to 32:

>> 00 A4 04 00 0F 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00
<< 6A82

No, that makes no difference at all. So it would seem that my attempts to write a "cd" command have failed - what I need is some version of an "ls" command - what folders are on the card?

(While I'm here, the EFTLab Knowledge Base has quite a few "complete list of" documents; at some point, I may be in need of a complete list of something; right now, I just want to get started.)

OK, Google, let's try some of the suggestions I found here.

It starts off with the same "SELECT PSE" thing I tried and failed with above. But it specifically notes that I may receive a 6A 82, in which case you need to "guess" what the AID is. In its sample code, it suggests values for VISA, AMEX and MC. Since I have a physical MasterCard here, let me try that:

$ go run apdu/main.go
>> 00 A4 04 00 07 A0 00 00 00 04 10 10
<< 9000

Very good! I am finally getting somewhere.

Does it work with the phone?

$ go run apdu/main.go
>> 00 A4 04 00 07 A0 00 00 00 04 10 10
<< 6A82

No. This is a little strange since I have "a" MC loaded onto my phone. Let's try the code for VISA, which is the default card on my phone:

>> 00 A4 04 00 07 A0000000031010
<< 6A82

No, still nothing. Oh, wait a moment, do I need to turn my phone on, like I would do if I were really trying to pay in a shop?

>> 00 A4 04 00 07 A0000000031010
<< 6F00

OK. That's different. And the phone lights up and says "Hey, using your VISA card". So, with the phone on, let's try the MC again:

>> 00 A4 04 00 07 A0 00 00 00 04 10 10
<< 6A82

But the screen lights up and says "You can't use that card here". It shows me a picture of my VISA card, so I don't know if this is just a level of complexity beyond where I am or what. But I have somethhing working.

OK, going back to the "working" VISA signal, I received a 6F 00 response, which is not 90 00. What does that mean? Turning back to the list of all responses, I see:

6F 00 Command aborted – more exact diagnosis not possible (e.g., operating system error).

OK, well, at least something happened. I'm not sure how far I want to go down this bunnyhole anyway, because I'm not actually interested in payments processing - I want to do data transfer. And I think that requires a completely different set of APDU commands - and possibly not even ADPU at all.

Conclusion

I have flailed around at length and have learnt quite a bit about this field. The outlines of what I'm trying to do are starting to take shape. So, the next question is: what do I really want to do, and what does that look like? I think it's time to turn to Android, which research suggests means using NDEF, whatever that is.

Actually, let's regroup next and list out some of the alphabet soup I've come across.