0

I'm currently working a project with Open Mobile API. Basically, I got this problem when i exchange apdu to the UICC, all my commands converted automatically to the extended logical APDU command (CLA : 0xC1). I'm using Samsung Galaxy S6 Edge during this test with android version : 5.0.2.

APDU > Header [CLA INS P1 P2] 00 70 00 00 194,69 etu MANAGE CHANNEL

< Outgoing data 01

< Return code [SW1 SW2] 90 00

APDU > Header [CLA INS P1 P2] 01 A4 04 00 194,69 etu SELECT

Incoming data A0 00 00 05 59 10 10 FF FF FF FF 89 00 00 01 00

< Outgoing data 6F 1A 84 10 A0 00 00 05 59 10 10 FF FF FF FF 89 

    00 00 01 00 A5 06 73 00 9F 65 01 FF

< Return code [SW1 SW2] 90 00

APDU > Header [CLA INS P1 P2] C1 E2 91 00 187,69 etu

Incoming data BF 2D 00

< Return code [SW1 SW2] 6D 00

APDU > Header [CLA INS P1 P2] 00 70 80 01 192,69 etu MANAGE CHANNEL

< Return code [SW1 SW2] 90 00

What could be a problem? Who is responsible to change my CLA command to 0xC1? Why the phone change the CLA command to 0xC1? Note : Based on my application log, I send this 81 E2 91 00 02 BF 2D 00

Thanks for your help.

heru762004
  • 46
  • 2
  • It might be helpful if you also revealed those parts of your code that are responsible for sending those APDUs. Also, where did you trace those command/response APDUs that you show in your post above? On the UICC? On the wire? In software on the phone itself? – Michael Roland Oct 04 '16 at 20:23
  • Hi @MichaelRoland I'm trace the command via eUICC trace tool, and on the tools, it show all the CLA changed into C1. Currently I'm using open mobile api to send apdu command to eUICC. In the end of every apdu command, Im always put close(); and shutdownSE(); – heru762004 Oct 25 '16 at 05:42
  • Again, you need to reveal the relevant parts of your code. Do you actually set the CLA byte to 0x81 in your code? Or do you let SEEK properly handle channel management? – Michael Roland Oct 25 '16 at 13:47

0 Answers0