Develop Reference

APDU commands to get data from NFC tag using ISODEP

I am trying to read the information stored on my German Sparkasse Girocard. My app successfully recognizes the (ISODEP) tag. To read the stored information, I need to send a sequence of APDU commands, but I am not sure which.
From my understanding I need to send a SELECT command first:
byte[] SELECT = {
(byte) 0x00, // CLA Class
(byte) 0xA4, // INS Instruction
(byte) 0x04, // P1 Parameter 1
(byte) 0x00, // P2 Parameter 2
(byte) 0x09, // Lc
(byte) 0xD2,0x76,0x00,0x00,0x25,0x47,0x41,0x01,0x00, // AID
(byte) 0x00 //Le
};
Tag tagFromIntent = intent.getParcelableExtra(NfcAdapter.EXTRA_TAG);
IsoDep tag = IsoDep.get(tagFromIntent);
tag.connect();
byte[] result = tag.transceive(SELECT);
text.setText(Integer.toHexString(result[0]) + ", " + Integer.toHexString(result[1]));
The status response should be 9000 if it works. I am getting 6F44 which indicates that there was some sort of error (I think). I am also not quite sure if I am using the correct AID, but it has also not worked using others, which I thought could be correct.
What is my error and which commands do I have to send to retrieve the data?
Thanks in advance.

Getting data from an EMV card (e.g. Girocard, Mastercard, Visacard) is more a "question and answer" puzzle - you are asking the card, get a response, analyze the data and ask the next question.
The analyzing part is done here by using the "TLV Utilities" from emvlab.org (https://emvlab.org/tlvutils/).
To get more information about the Application Identifier ("AID"s) see the complete list at: https://www.eftlab.com/knowledge-base/211-emv-aid-rid-pix/.
Here is an example of reading a German Girocard (mine is from a "Volksbank"):
Step 1: ask the card which applications are on the card using the "select PPSE" command. The 2 bytes at the end "90 00" say that the answer is successfull:
selectPpseCommand: 00 A4 04 00 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00
selectPpseResponse: 6F 67 84 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 A5 55 BF 0C 52 61 19 4F 09 A0 00 00 00 59 45 43 01 00 87 01 01 9F 0A 08 00 01 05 01 00 00 00 00 61 1A 4F 0A A0 00 00 03 59 10 10 02 80 01 87 01 01 9F 0A 08 00 01 05 01 00 00 00 00 61 19 4F 09 D2 76 00 00 25 47 41 01 00 87 01 01 9F 0A 08 00 01 05 01 00 00 00 00 90 00
Parsed response:
6F File Control Information (FCI) Template
84 Dedicated File (DF) Name
325041592E5359532E4444463031
A5 File Control Information (FCI) Proprietary Template
BF0C File Control Information (FCI) Issuer Discretionary Data
61 Application Template
4F Application Identifier (AID) – card
A00000005945430100
87 Application Priority Indicator
01
9F0A Unknown tag
0001050100000000
61 Application Template
4F Application Identifier (AID) – card
A0000003591010028001
87 Application Priority Indicator
01
9F0A Unknown tag
0001050100000000
61 Application Template
4F Application Identifier (AID) – card
D27600002547410100
87 Application Priority Indicator
01
9F0A Unknown tag
0001050100000000
There are 3 applications with 3 different AIDs available on the card:
A00000005945430100: Zentraler Kreditausschuss (ZKA) Germany Girocard Electronic Cash
A0000003591010028001: Euro Alliance of Payment Schemes s.c.r.l. – EAPS Belgium Girocard EAPS ZKA (Germany)
D27600002547410100: ZKA Germany Girocard ATM
Step 2: Now I'm reading the first AID using the "Select AID" command - the AID is 18 characters = 9 bytes long:
selectAidCommand: 00 A4 04 00 09 A0 00 00 00 59 45 43 01 00 00
selectAidResponse: 6F 47 84 09 A0 00 00 00 59 45 43 01 00 A5 3A 50 08 67 69 72 6F 63 61 72 64 87 01 01 9F 38 06 9F 02 06 9F 1D 02 5F 2D 04 64 65 65 6E BF 0C 1A 9F 4D 02 19 0A 9F 6E 07 02 80 00 00 30 30 00 9F 0A 08 00 01 05 01 00 00 00 00 90 00
Parsed response:
6F File Control Information (FCI) Template
84 Dedicated File (DF) Name
A00000005945430100
A5 File Control Information (FCI) Proprietary Template
50 Application Label
g i r o c a r d
87 Application Priority Indicator
01
9F38 Processing Options Data Object List (PDOL)
9F02 06
9F1D 02
5F2D Language Preference
d e e n
BF0C File Control Information (FCI) Issuer Discretionary Data
9F4D Log Entry
190A
9F6E Unknown tag
02800000303000
9F0A Unknown tag
0001050100000000
Step 3: get the processing options to read the card details
This is the first "tricky" point as it is not easy how to explain to get the right data for your card/AID. In the above response there is a section for the Processing Options Data Object List (PDOL) the card is requesting and the length of the fields - here we do have 2 fields with a length of 6 and 2 bytes, in total 8 bytes. The 8 bytes are just 8 "x00"s with the "header" 83 08, so the complete length is 10 bytes = x0A:
9F38 Processing Options Data Object List (PDOL)
9F02 06
9F1D 02
A more detailed explanation can be found here: https://stackoverflow.com/a/20810855/8166854
getProcessingOptionsCommand: 80 A8 00 00 0A 83 08 00 00 00 00 00 01 00 00 00
getProcessingOptionsResponse: 77 1E 82 02 19 80 94 18 18 01 01 00 20 01 01 00 20 04 04 00 08 05 05 01 08 07 07 01 08 03 03 01
Parsed response:
77 Response Message Template Format 2
82 Application Interchange Profile
1980
94 Application File Locator (AFL)
18010100 20010100 20040400 08050501 08070701 08030301
The most important part for the next step is the "Application File Locator (AFL)" - we need to read the file system with the data that are coded in these 4 byte blocks.
Step 4: read the records from the card
This is the part where I get lost when trying to read the card. You need to get the SFI and RECORD from the first 3 bytes of an AFL block and run a read record command. The following command reads the 4th sector of the AFL list - the command may work or not with your card and if it works you may get different data from your card.
WARNING: providing the response data to an internet form may reveal data like account number or
credit card number - my response is masked so the account number is not 1111111111:
readRecordCommand: 00 B2 05 0C 00
readRecordResponse: 70 38 5F 24 03 21 12 31 5A 0A 67 26 42 89 11 11 11 11 11 7F 5F 34 01 02 5F 28 02 02 80 9F 07 02 FF C0 9F 0D 05 FC 40 A4 80 00 9F 0E 05 00 10 18 00 00 9F 0F 05 FC 40 A4 98 00 90 00
Parsed response:
70 EMV Proprietary Template
5F24 Application Expiration Date
211231
5A Application Primary Account Number (PAN)
6726428911111111117F
5F34 Application Primary Account Number (PAN) Sequence Number
02
5F28 Issuer Country Code
0280
9F07 Application Usage Control
FFC0
9F0D Issuer Action Code – Default
FC40A48000
9F0E Issuer Action Code – Denial
0010180000
9F0F Issuer Action Code – Online
FC40A49800
I strongly recommend that you use a library for the steps 3 and 4; I'm using
https://github.com/devnied/EMV-NFC-Paycard-Enrollment
for this.
This is just a basic explanation for the first steps but now you get some useful responds from your card - good luck for your next steps.
A complete Android example app for the above mentioned library is here (disclaimer: I'm the author):
https://github.com/AndroidCrypto/Android-EMV-NFC-Paycard-Example

detect ibeacon with android beacon library

Trying to detect an iBeacon setup on raspberry PI using the android beacon library (with xamarin bindings)
Wondering what Im doing wrong here:
sudo hcitool -i hci0 cmd 0x08 0x0008 1E 02 01 1A 1A FF 4C 00 02 15 E2 0A 39 F4 73 F5 4B C4 A1 2F 17 D1 AD 07 A9 61 00 01 00 00 C8 00
And setting up Beacon Parser like so
beaconManager.BeaconParsers.Add(new BeaconParser().SetBeaconLayout("m:0-3=0215,i:4-19,i:20-21,i:22-23,p:24-24"));
I can detect this beacon with for example "BeaconScope" on Android but I can not get it detected using the android beacon library.
I can see the following output from debug
[BeaconParser] Processing pdu type FF: 02011a1aff4c000215e20a39f473f54bc4a12f17d1ad07a96100010000c80000000000000000000000000000000000000000000000000000000000000000 with startIndex: 5, endIndex: 29
[BeaconParser] Ignoring pdu type 06
[BeaconParser] This is not a matching Beacon advertisement. (Was expecting be ac. The bytes I see are: 02011a1aff4c000215e20a39f473f54bc4a12f17d1ad07a96100010000c80000000000000000000000000000000000000000000000000000000000000000
Setting up as AltBeacon works!
sudo hcitool -i hci0 cmd 0x08 0x0008 1F 02 01 1A 1B FF 18 01 BE AC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 01 C5 01
This one the library detects.
What am I missing?
I detect a RadButton setup as iBeacon but can not get it to work from raspberry PI

Try changing this:
"m:0-3=0215,i:4-19,i:20-21,i:22-23,p:24-24"
to this:
"m:2-3=0215,i:4-19,i:20-21,i:22-23,p:24-24"
Note the first digit is a 2 instead of a 0

H264 RTP video stream corrupted with MediaCodec

I am able to see the video playing in my TextureView but it is fairly corrupted. I have verified that I am receiving complete packets in the correct order. I have been able to parse the RTP header correctly. I believe my issue is related to the SPS and PPS and the MediaCodec.
My understanding is that you are supposed to strip the RTP header from the message and insert an RTP start code of 0x00000001 to the start of your message so that your input buffer to the decoder is of the form 0x00000001[sps] 0x00000001[pps] 0x00000001[video data].
My confusion is that the MediaCodec appears to require a MediaFormat with the SPS and PPS manually defined separately. I have found this example that I am currently using along with the message format I have defined above:
MediaFormat format = MediaFormat.createVideoFormat(MediaFormat.MIMETYPE_VIDEO_AVC, width, height);
// from avconv, when streaming sample.h264.mp4 from disk
byte[] header_sps = {0, 0, 0, 1, 0x67, 0x64, (byte) 0x00, 0x1e, (byte) 0xac, (byte) 0xd9, 0x40, (byte) 0xa0, 0x3d,
(byte) 0xa1, 0x00, 0x00, (byte) 0x03, 0x00, 0x01, 0x00, 0x00, 0x03, 0x00, 0x3C, 0x0F, 0x16, 0x2D, (byte) 0x96}; // sps
byte[] header_pps = {0, 0, 0, 1, 0x68, (byte) 0xeb, (byte) 0xec, (byte) 0xb2, 0x2C}; // pps
format.setByteBuffer(CSD_0, ByteBuffer.wrap(header_sps));
format.setByteBuffer(CSD_1, ByteBuffer.wrap(header_pps));
As you can see, I am not providing the MediaFormat with the SPS and PPS from my video stream, but instead using a hard coded set from an internet example. I've tried to find sources explaining how to extract the SPS and PPS from a packet, but haven't been able to find anything.
Questions:
Am I supposed to strip the SPS and PPS from my buffer before passing it to the MediaCodec if the MediaFormat is already being provided the SPS and PPS?
How do you correctly parse the SPS and PPS from a message?
Here's the first few bytes of one of my RTP packets with the header included:
80 a1 4c c3 32 2c 24 7a f5 5c 9f bb 47 40 44 3a 40 0 ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0 0 1 c0 0 71 80 80
5 21 0 5d d6 d9 ff fb 12 c4 e7 0 5 5c 41 71 2c 30 c1 30 b1 88 6c
f5 84 98 2c 82 f5 84 82 44 96 72 45 ca 96 30 35 91 83 86 42 e4 90
28 b1 81 1a 6 57 a8 37 b0 60 56 81 72 71 5c 58 a7 4e af 67 bd 10
13 1 af e9 71 15 13 da a0 15 d5 72 38 36 2e 35 11 31 10 a4 12 1e
26 28 40 b5 3b 65 8c 30 54 8a 96 1b c5 a7 b5 84 cb a9 aa 3d d4 53
47 0 45 34 55 0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff bf 9 95 2b 73 93 4e c3 f9 b1 d0 5f f5 de c9 9e f7 f8 23 ab
a5 aa

Yes you are correct that the mediacodec requires the SPS and PPS to be initialized first. You must extract the SPS/PPS from the SDP response which is the reply from the DESCRIBE command sent to the server(camera) during the RTSP handshake. Within the SDP response there is a sprop parameter set which contains the SPS/PPS. You can see them on WireShark as:
Media format specific parameters: sprop-parameter-sets=Z2QAKKwbGoB4AiflwFuAgICgAAB9AAAOph0MAHz4AAjJdd5caGAD58AARkuu8uFAAA==,aO44MAA=
They are separated by comma and must be decoded using Base64. See this for an explanation: How to decode sprop-parameter-sets in a H264 SDP?

Get Bluetooth Lowenergy RSP scan in Android

I am developing a semi standard ibeacon, need to use the RSP broadcast field, I am using TI CC2541 broadcasting both Adv and RSP, working fine as from TI Packet Sniffer result attached.
I fail to get the RSP test data {0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF} scan on my Samsung Note3, Android 4.4.2, using example from http://developer.android.com/guide/topics/connectivity/bluetooth-le.html ,my added Log.d code is:
// Device scan callback.
private BluetoothAdapter.LeScanCallback mLeScanCallback =
new BluetoothAdapter.LeScanCallback() {
#Override
public void onLeScan(final BluetoothDevice device, int rssi, byte[] scanRecord) {
runOnUiThread(new Runnable() {
#Override
public void run() {
mLeDeviceListAdapter.addDevice(device);
mLeDeviceListAdapter.notifyDataSetChanged();
}
});
Log.d("Tag101: ", device.getAddress() + "||"+Integer.toString(rssi) + "||"+toHexadecimal(scanRecord));
}
};
Result:
10-15 21:07:28.066 19840-19853/com.example.android.bluetoothlegatt
D/Tag101:: 20:CD:39:B1:52:C2||-52||02 01 06 1a ff 4c 00 02 15 e2 c5 6d
b5 df fb 48 d2 b0 60 d0 f5 a7 10 96 e0 00 01 00 02 cd 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 10-15 21:07:28.286
19840-19840/com.example.android.bluetoothlegatt D/dalvikvm:
GC_FOR_ALLOC freed 514K, 13% free 10104K/11604K, paused 15ms, total
15ms 10-15 21:07:28.571
19840-19852/com.example.android.bluetoothlegatt D/BluetoothAdapter:
onScanResult() - Device=20:CD:39:B1:52:C2 RSSI=-52 10-15 21:07:28.571
19840-19852/com.example.android.bluetoothlegatt D/Tag101::
20:CD:39:B1:52:C2||-52||02 01 06 1a ff 4c 00 02 15 e2 c5 6d b5 df fb
48 d2 b0 60 d0 f5 a7 10 96 e0 00 01 00 02 cd 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 10-15 21:07:29.081 19840-2874/com.example.android.bluetoothlegatt
D/BluetoothAdapter: onScanResult() - Device=20:CD:39:B1:52:C2 RSSI=-51
10-15 21:07:29.081 19840-2874/com.example.android.bluetoothlegatt
D/Tag101:: 20:CD:39:B1:52:C2||-51||02 01 06 1a ff 4c 00 02 15 e2 c5 6d
b5 df fb 48 d2 b0 60 d0 f5 a7 10 96 e0 00 01 00 02 cd 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 10-15 21:07:29.581
19840-2873/com.example.android.bluetoothlegatt D/BluetoothAdapter:
onScanResult() - Device=20:CD:39:B1:52:C2 RSSI=-51
The Test Data can be scan correctly by TI Packet Sniffer:
enter image description here
Can anyone one advise on how to get the RSP in Android code, do I need to init scan-request?
Some example code will be great. Thanks.

Android normally requests a scan response all by itself, and when received, it appends the scanRecord with the PDU for the scan response. I see this is not happening in the scan record output you show.
You might try transmitting connectable advertisements and see if this makes a difference. It is possible Android only requests and processes the scan response for connectable advertisements.

try this Kotlin class to parse RSA data
also you could translate it to Java
finally you'll got a Map Array with all necessary RSA data
enum class EBLE {
EBLE_ZERO, // Zero element
EBLE_FLAGS, //«Flags» Bluetooth Core Specification:
EBLE_16BitUUIDInc, //«Incomplete List of 16-bit Service Class UUIDs» Bluetooth Core Specification:
EBLE_16BitUUIDCom, //«Complete List of 16-bit Service Class UUIDs» Bluetooth Core Specification:
EBLE_32BitUUIDInc,//«Incomplete List of 32-bit Service Class UUIDs» Bluetooth Core Specification:
EBLE_32BitUUIDCom,//«Complete List of 32-bit Service Class UUIDs» Bluetooth Core Specification:
EBLE_128BitUUIDInc,//«Incomplete List of 128-bit Service Class UUIDs» Bluetooth Core Specification:
EBLE_128BitUUIDCom,//«Complete List of 128-bit Service Class UUIDs» Bluetooth Core Specification:
EBLE_SHORTNAME,//«Shortened Local Name» Bluetooth Core Specification:
EBLE_LOCALNAME,//«Complete Local Name» Bluetooth Core Specification:
EBLE_TXPOWERLEVEL,//«Tx Power Level» Bluetooth Core Specification:
EBLE_DEVICECLASS,//«Class of Device» Bluetooth Core Specification:
EBLE_SIMPLEPAIRHASH,//«Simple Pairing Hash C» Bluetooth Core Specification:​«Simple Pairing Hash C-192» ​Core Specification Supplement, Part A, section 1.6
EBLE_SIMPLEPAIRRAND,//«Simple Pairing Randomizer R» Bluetooth Core Specification:​«Simple Pairing Randomizer R-192» ​Core Specification Supplement, Part A, section 1.6
EBLE_DEVICEID,//«Device ID» Device ID Profile v1.3 or later,«Security Manager TK Value» Bluetooth Core Specification:
EBLE_SECURITYMANAGER,//«Security Manager Out of Band Flags» Bluetooth Core Specification:
EBLE_SLAVEINTERVALRA,//«Slave Connection Interval Range» Bluetooth Core Specification:
EBLE_16BitSSUUID,//«List of 16-bit Service Solicitation UUIDs» Bluetooth Core Specification:
EBLE_128BitSSUUID, //«List of 128-bit Service Solicitation UUIDs» Bluetooth Core Specification:
EBLE_SERVICEDATA,//«Service Data» Bluetooth Core Specification:​«Service Data - 16-bit UUID» ​Core Specification Supplement, Part A, section 1.11
EBLE_PTADDRESS,//«Public Target Address» Bluetooth Core Specification:
EBLE_RTADDRESS,//«Random Target Address» Bluetooth Core Specification:
EBLE_APPEARANCE,//«Appearance» Bluetooth Core Specification:
EBLE_DEVADDRESS,//«​LE Bluetooth Device Address» ​Core Specification Supplement, Part A, section 1.16
EBLE_LEROLE,//«​LE Role» ​Core Specification Supplement, Part A, section 1.17
EBLE_PAIRINGHASH,//«​Simple Pairing Hash C-256» ​Core Specification Supplement, Part A, section 1.6
EBLE_PAIRINGRAND,//«​Simple Pairing Randomizer R-256» ​Core Specification Supplement, Part A, section 1.6
EBLE_32BitSSUUID,//​«List of 32-bit Service Solicitation UUIDs» ​Core Specification Supplement, Part A, section 1.10
EBLE_32BitSERDATA,//​«Service Data - 32-bit UUID» ​Core Specification Supplement, Part A, section 1.11
EBLE_128BitSERDATA,//​«Service Data - 128-bit UUID» ​Core Specification Supplement, Part A, section 1.11
EBLE_SECCONCONF,//​«​LE Secure Connections Confirmation Value» ​Core Specification Supplement Part A, Section 1.6
EBLE_SECCONRAND,//​​«​LE Secure Connections Random Value» ​Core Specification Supplement Part A, Section 1.6​
EBLE_3DINFDATA, //​​«3D Information Data» ​3D Synchronization Profile, v1.0 or later
EBLE_MANDATA; //«Manufacturer Specific Data» Bluetooth Core Specification:
companion object {
private val map = EBLE.values()
fun fromInt(type: Int) = if (type > 0) map[type] else EBLE_MANDATA
fun getDistance(rssi: Int, txPower: Int) = {
/*
* RSSI = TxPower - 10 * n * lg(d)
* n = 2 (in free space)
*
* d = 10 ^ ((TxPower - RSSI) / (10 * n))
*/
Math.pow(10.0, (txPower.toDouble() - rssi) / (10 * 2))
}
/*
BLE Scan record parsing
*/
fun parseRecord(scanRecord: ByteArray): Map<EBLE, ByteArray> {
val ret = HashMap<EBLE, ByteArray>()
var index = 0
while (index < scanRecord.size) {
val length = scanRecord[index++].toInt()
//Zero value indicates that we are done with the record now
if (length == 0) break
val type = scanRecord[index].toInt()
//if the type is zero, then we are pass the significant section of the data,
// and we are thud done
if (type == 0) break
Arrays.copyOfRange(scanRecord, index + 1, index + length)?.let {
ret[EBLE.fromInt(type)] = it //HexUtil.formatHexString(it)
}
index += length
}
return ret
}
fun getServiceUUID(record: Map<EBLE, ByteArray>): String {
return when {
record.containsKey(EBLE.EBLE_128BitUUIDCom) -> {
val tmpString = HexUtil.formatHexString(record[EBLE.EBLE_128BitUUIDCom]?.reversedArray())
tmpString.substring(0, 8) + "-" + tmpString.substring(8, 12) + "-" + tmpString.substring(12, 16) + "-" + tmpString.substring(16, 20) + "-" + tmpString.substring(20, tmpString.length)
}
record.containsKey(EBLE.EBLE_32BitUUIDCom) -> {
HexUtil.formatHexString(record[EBLE.EBLE_32BitUUIDCom]?.reversedArray()) + "-0000-1000-8000-00805f9b34fb"
}
record.containsKey(EBLE.EBLE_128BitUUIDInc) -> { // Todo: Remove after bugfix !!!
val tmpString = HexUtil.formatHexString(record[EBLE.EBLE_128BitUUIDInc]?.reversedArray())
tmpString.substring(0, 8) + "-" + tmpString.substring(8, 12) + "-" + tmpString.substring(12, 16) + "-" + tmpString.substring(16, 20) + "-" + tmpString.substring(20, tmpString.length)
}
else -> {
"undefined"
}
}
}
fun getServiceUUID(scanRecord: ByteArray): String {
return getServiceUUID(parseRecord(scanRecord))
}
}
Gist link

I have solve the problem, I need to specified the length of scan_RSP:
// GAP - SCAN RSP data (max size = 31 bytes)
{
0x05, 0xAA, 0xBB, 0xCC, 0xDD, 0xEE
};
Log.d result:
Device=20:CD:39:B1:52:C2 RSSI=-47 10-15 23:20:29.416
4780-4792/com.example.android.bluetoothlegatt D/Tag101::
20:CD:39:B1:52:C2||-47||02 01 06 1a ff 4c 00 02 15 e2 c5 6d b5 df fb
48 d2 b0 60 d0 f5 a7 10 96 e0 00 01 00 02 cd 05 aa bb cc dd ee 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 10-15 23:20:29.921 4780-4791/com.example.android.bluetoothlegatt
D/BluetoothAdapter: onScanResult() - Device=20:CD:39:B1:52:C2 RSSI=-47
10-15 23:20:29.921 4780-4791/com.example.android.bluetoothlegatt
D/Tag101:: 20:CD:39:B1:52:C2||-47||02 01 06 1a ff 4c 00 02 15 e2 c5 6d
b5 df fb 48 d2 b0 60 d0 f5 a7 10 96 e0 00 01 00 02 cd 05 aa bb cc dd
ee 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00

Android isoDep.transceive on Generate AC command always returns 6D00 unsupported

I'm trying to emulate a PoS, point of sale :), system and complete a transaction with Google wallet running on a 2013 Nexus 7 (no secure element) v4.4.2.
My PoS prototype is also running on a 2013 Nexus 7 v4.4.2.
I'm able to get NFC responses from the 2PAY_SYS_DDF01 request.
I'm able to select the MasterCard application ID.
I'm able to get Processing Options.
When I Read Records it doesn't look like Google wallet is returning all the mandatory EMV fields.
And finally when I request the Generate AC command it always returns 6D00 unsupported.
Area of the code that is a problem:
//set P1 to '40', to request an Transaction Certificate (offline transaction)
//and execute the Generate AC command.
byte[] generateAC = new byte[] {(byte)0x80, (byte)0xAE, 0x40, 0x00,
0x1D, //data length
0x00, 0x00, 0x00, 0x00, 0x00, 0x01, //amount1
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, //amount2
0x08, 0x40, //term country
0x00, 0x00, 0x00, 0x00, 0x00, //tvr
0x09, 0x62, //tx curr
0x14, 0x04, 0x1B, //tx date
0x00, //tx type
0x12, 0x34, 0x56, 0x78, //random
0x00}; //le
response = isoDep.transceive(generateAC);
I was following Tim Beckers video
https://www.youtube.com/watch?v=qqobg1-HrfY
approx. 46 minutes in.
and Tim Beckers code sample:
https://github.com/a2800276/29c3/blob/master/smartshell.rb
UPDATE:
The response to the GPO command (80 a8 00 00 02 83 00 00) is
770a820200009404080101009000
77 Response Message Template Format 2
82 Application Interchange Profile
0000
94 Application File Locator (AFL)
08010100
UPDATE:
I tried:
byte[] computeCC = new byte[] {
(byte)0x80, // CLA = proprietary
(byte)0x2A, // INS = COMPUTE CRYPTOGRAPHIC CHECKSUM
(byte)0x8E, // P1
(byte)0x80, // P2
(byte)0x04, // Lc
(byte)0x00, 0x00, (byte)0x00, (byte)0x99, // Unpredicatable Number (numeric)
(byte)0x00, // Le
};
response = isoDep.transceive(computeCC);
hoping to at least get an error that indicated the wrong unpredictable number but I got 6700 incorrect length returned.
Earlier I got a response to Read Record 00 B2 01 0C 00
Part of that response is
Card Authentication Related Data [9F69]:
Data (Binary): XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
fDDA Version Number: 9F
(Card) Unpredictable Number: 6A 04 9F 7E
So I tried that Unpredictable number
byte[] computeCC = new byte[] {
(byte)0x80, // CLA = proprietary
(byte)0x2A, // INS = COMPUTE CRYPTOGRAPHIC CHECKSUM
(byte)0x8E, // P1
(byte)0x80, // P2
(byte)0x04, // Lc
(byte)0x6A, 0x04, (byte)0x9F, (byte)0x7E, // Unpredicatable Number (numeric)
(byte)0x00, // Le
};
response = isoDep.transceive(computeCC);
But I still get 6700 wrong length
UPDATE:
The response to READ RECORD (Record = 1, SFI = 1) command (00 B2 01 0C 00)
is:
70 7c 9f 6c 02
00 01 9f 62 06
00 00 00 00 00
38 9f 63 06 00
00 00 00 03 c6
56 29 42 35 33
39 36 XX XX XX
XX 31 XX XX 39
XX XX XX XX 5e
20 2f 5e 31 34
30 37 31 30 31
34 30 31 30 30
30 30 30 30 30
30 30 30 9f 64
01 04 9f 65 02
00 38 9f 66 02
03 c6 9f 6b 13
53 96 XX XX 1X
X9 XX XX d1 40
71 01 40 10 00
00 00 00 0f 9f
67 01 04 9f 69
0f 9f 6a 04 9f
7e 01 9f 02 06
5f 2a 02 9f 1a
02 90 00
--------------------------TLV-------------------------------
Output:
READ RECORD Response Message Template [70]:
Card Transaction Qualifiers (CTQ) [9F6C]:
Data (Binary): 00 01
Bit flags set:
1Bxb8: 0 - Online PIN not Required
1Bxb7: 0 - Signature Not Required
1Bxb6: 0 - Not applicable: Go Online if Offline Data Authentication Fails and Reader is online capable.
1Bxb5: 0 - Not applicable: Switch Interface if Offline Data Authentication fails and Reader supports VIS.
1Bxb4: 0 - Not applicable: Go Online if Application Expired
1Bxb3: 0 - Not applicable: Switch Interface for Cash Transactions
1Bxb2: 0 - Not applicable: Switch Interface for Cashback Transactions
1Bxb1: 0 - RFU
2Bxb8: 0 - Consumer Device CVM not Performed
2Bxb7: 0 - Card doesn't support Issuer Update Processing at the POS
2Bxb6: 0 - RFU
2Bxb5: 0 - RFU
2Bxb4: 0 - RFU
2Bxb3: 0 - RFU
2Bxb2: 0 - RFU
2Bxb1: 1 - RFU
PCVC3 (Track1) [9F62]:
Data (Binary): 00 00 00 00 00 38
Offline Counter Initial Value [9F63]:
Data (Binary): 00 00 00 00 03 C6
Track 1 Data [56]:
Data (ASCII): B5396XXXXXXXXXXXX^ /^14071014010000000000
NATC (Track1) [9F64]:
Data (Binary): 04
PCVC3 (Track2) [9F65]:
Data (Binary): 00 38
Terminal Transaction Qualifiers (TTQ) [9F66]:
Data (Binary): 03 C6
Card CVM Limit [9F6B]:
Data (Binary): 53 96 48 50 17 69 62 32 D1 40 71 01 40 10 00 00 00 00 0F
MSD Offset [9F67]:
Data (Binary): 04
Card Authentication Related Data [9F69]:
Data (Binary): 9F 6A 04 9F 7E 01 9F 02 06 5F 2A 02 9F 1A 02
fDDA Version Number: 9F
(Card) Unpredictable Number: 6A 04 9F 7E
Card Transaction Qualifiers: 01 9F
----------------------------------------

The response to the GET PROCESSING OPTIONS command indicates the following Application Interchange Profile (AIP):
82 Application Interchange Profile
0000
Google Wallet is basically a MasterCard (EMV contactless kernel 2), so decoding the AIP according to the rules of Kernel 2 results in the following:
Byte 1, b7 = 0: no SDA supported
b6 = 0: no DDA supported
b5 = 0: no cardholder verification supported
b4 = 0: no terminal risk management to be performed
b3 = 0: no issuer authentication supported
b2 = 0: no on-device cardholder verification supported
b1 = 0: no CDA supported
Byte 2, b8 = 0: no EMV mode supported
The important part is byte 2, bit 8: It indicates that your card does not support EMV mode. Hence, your card/Google Wallet is a PayPass card that supports only Mag-Stripe mode. Therefore, you cannot authenticate transactions using GENERATE AC. Instead, you can only let the card generate dynamic card verification codes (CVC3) using COMPUTE CRYPTOGRAPHIC CHECKSUM:
byte[] computeCC = new byte[] {
(byte)0x80, // CLA = proprietary
(byte)0x2A, // INS = COMPUTE CRYPTOGRAPHIC CHECKSUM
(byte)0x8E, // P1
(byte)0x80, // P2
(byte)0x04, // Lc
(byte)0xWW, (byte)0xXX, (byte)0xYY, (byte)0xZZ, // Unpredicatable Number (numeric)
(byte)0x00, // Le
};
response = isoDep.transceive(computeCC);
Note that the data field of the COMPUTE CRYPTOGRAPHIC CHECKSUM command must be filled with values according to the UDOL (in case there is no UDOL, the default UDOL is 9F6A04, indicating the unpredictable number, numeric).
The unpredictable number (numeric) is a BCD coded number in the range that is defined by the mag-stripe data file (see the AFL). In the past, for Google Wallet, this was a value between 0 and 99 (i.e. WW='00', XX='00', YY='00', ZZ='00'..'99').
UPDATE:
The data read from the card decodes as follows:
70 7c
9f6c 02 Mag-stripe application version number = Version 1
00 01
9f62 06 Track 1 bit map for CVC3
00 00 00 00 00 38
9f63 06 Track 1 bit map for UN and ATC
00 00 00 00 03 c6
56 29 Track 1 data
42 ISO/IEC 7813 structure "B" format
35333936 XXXXXXXX 31XXXX39 XXXXXXXX PAN (ASCII)
5e Field separator "^"
202f Cardholder name " /" (empty, see MC requirements)
5e Field separator "^"
31343037 Expiry date "14"/"07"
313031 Service code "101"
34303130303030303030303030 Track 1 discretionary data
9f64 01 Track 1 number of ATC digits
04
9f65 02 Track 2 bit map for CVC3
00 38
9f66 02 Track 2 bit map for UN and ATC
03 c6
9f6b 13 Track 2 data
5396 XXXX 1XX9 XXXX PAN (BCD)
d Field separator
1407 Expiry date
101 Service code
4010000000000 Track 2 discretionary data
f Padding
9f67 01 Track 2 number of ATC digits
04
9f69 0f UDOL
9f6a 04 Unpredictable number (numeric)
9f7e 01 Mobile support indicator
9f02 06 Amount authorized (numeric)
5f2a 02 Transaction currency code
9f1a 02 Terminal country code
So the card does provide a UDOL. Therefore, the COMPUTE CRYPTOGRAPHIC CHECKSUM command has to be adapted accordingly:
byte[] computeCC = new byte[] {
(byte)0x80, // CLA = proprietary
(byte)0x2A, // INS = COMPUTE CRYPTOGRAPHIC CHECKSUM
(byte)0x8E, // P1
(byte)0x80, // P2
(byte)0x0F, // Lc
// 9f6a 04 Unpredictable number (numeric)
(byte)0x00, (byte)0x00, (byte)0x00, (byte)0x12, // two digits according to UN/ATC bit map and number of ATC digits: 6 - 4 = 2
// 9f7e 01 Mobile support indicator
(byte)0x00, // no offline PIN required, no mobile support
// 9f02 06 Amount authorized (numeric)
(byte)0x00, (byte)0x00, (byte)0x00, (byte)0x00, (byte)0x01, (byte)0x00, // 1.00
// 5f2a 02 Transaction currency code
(byte)0x09, (byte)0x78, // Euro
// 9f1a 02 Terminal country code
(byte)0x00, (byte)0x40, // Austria
(byte)0x00, // Le
};
response = isoDep.transceive(computeCC);