0

I am testing sending APDU commands on S3's and S4's.

On my S3 I send out the APDU and get back 9000. Knowing that my response also has 8 bytes of data i do: 80C0000010

On my S4 I send out the same APDU as above and get 6108 (61 data available - 08 , 8 bytes of data)

Sending out 80C0000010 or 80C0000000 both return 6F00 (internal error). The S4 is up to date running 4.3.

My suspicion is that something is going wrong in the version of SEEK my S4 is running as I have this working on other devices.

Has anyone else experienced this issue and have any resolution or any suggestions of things for me to try?

Termininja
  • 6,620
  • 12
  • 48
  • 49
Doolali
  • 956
  • 9
  • 13
  • Am I correct when I assume that you are talking about sending APDU commands to a secure element (presumably a UICC-based one) through the SEEK Smart Card API? – Michael Roland Nov 28 '13 at 12:31
  • Also could you clarify if you get 6F00 or 6108 in response to 80C0000010 on the S4? If 6F00, what APDU resulted in 6108 on the S4? – Michael Roland Nov 28 '13 at 12:33

1 Answers1

1

It would be nice to have the exact APDU, but what you're seen is caused by a more strict implementation of ISO7816 on the S4 than on the S3. When you expect data in return (case 2, case 4 APDUs), then the ISO7816-4 mandates the use of the Le byte, which you set to 00.

Try adding 0x00 as Le byte at the end of your APDU, it should work on both the S3 and the S4.

Toluene
  • 751
  • 3
  • 9