New API in Android 5.0 (lollipop)

[mohamed sabt]

Hello,

I've just noticed recently that the class TelephonyManager in Android API level 21 (Android 5.0) defines 4 interesting methods:
 * iccOpenLogicalChannelResponse iccOpenLogicalChannel(String AID);
 * byte[] iccExchangeSimIO(int fileID, int command, int p1, int p2, int p3, String filePath);
 * boolean iccCloseLogicalChannel(int channel);
 * String iccTransmitApduBasicChannel(int cla, int instruction, int p1, int p2, int p3, String data);
 * String iccTransmitApduLogicalChannel(int channel, int cla, int instruction, int p1, int p2, int p3, String data);

Unfortunately, they require MODIFY_PHONE_STATE permission, so they are not open for third-party applications.

My question concerns proprietary  RIL implementation. As far as I know, the baseband firmaware (RIL) of Nexus 4 (even 5) does not support sending plain APDU. To be more precise,  it does not support 4 AT commands: AT+CCHO, AT+CCHC, AT+CGLA, and AT+CSIM. It still supports the AT+CRSM command that allows a limited access to the sim. Do you know if Qualcomm updates their RIL implementation for Android 5.0 in order to support the new Android APIs (sending APDU to the UICC)?
Does anybody attempt to use SEEK-FOR-ANDROID in Nexus 4 (5) with the newly updated RIL of Qualcomm?

Thank you in advance.


Best regards,
Mohamed Sabt

[Anders Rundgren]

On 2014-12-09 10:58, mohamed sabt wrote:
>
> Hello,
>
> I've just noticed recently that the class TelephonyManager in Android API level 21 (Android 5.0) defines 4 interesting methods:
> * iccOpenLogicalChannelResponse iccOpenLogicalChannel(String AID);
> * byte[] iccExchangeSimIO(int fileID, int command, int p1, int p2, int p3, String filePath);
> * boolean iccCloseLogicalChannel(int channel);
> * String iccTransmitApduBasicChannel(int cla, int instruction, int p1, int p2, int p3, String data);
> * String iccTransmitApduLogicalChannel(int channel, int cla, int instruction, int p1, int p2, int p3, String data);
>
> Unfortunately, they require MODIFY_PHONE_STATE permission, so they are not open for third-party applications.

Isn't that the problem with seek-for-android as well?

Third parties were *deliberately* excluded from accessing the SIM since it is reserved for the MNO.
If you are an operator you can surely get the permission you need (otherwise the API who be entirely useless).

Anders

>
> My question concerns proprietary RIL implementation. As far as I know, the baseband firmaware (RIL) of Nexus 4 (even 5) does not support sending plain APDU. To be more precise, it does not support 4 AT commands: AT+CCHO, AT+CCHC, AT+CGLA, and AT+CSIM. It still supports the AT+CRSM command that allows a limited access to the sim. Do you know if Qualcomm updates their RIL implementation for Android 5.0 in order to support the new Android APIs (sending APDU to the UICC)?
> Does anybody attempt to use SEEK-FOR-ANDROID in Nexus 4 (5) with the newly updated RIL of Qualcomm?
>
> Thank you in advance.
>
>
> Best regards,
> Mohamed Sabt
>

> --
>
> ---
> You received this message because you are subscribed to the Google Groups "seek-for-android" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to seek-for-andro...@googlegroups.com <mailto:seek-for-andro...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

[marc.o...@gi-de.com]

We haven't tried yet, but will certainly do so. If someone tries, please feel free to share your experience here.

Regards,

Marc

> To unsubscribe from this group and stop receiving emails from it, send an email to seek-for-andro...@googlegroups.com <mailto:seek-for-android+unsub...@googlegroups.com>.

[mohamed sabt]

Hi!
I just want to share my experience on the new APIs of Android 5.

At the beginning, I had some doubts about this new API. Therefore, the first thing I did is to dig into the code of Android.
In the Java side, the first class that I looked was TelephonyManager (natural choice) that uses an object implementing the ITelephony interface
to send the APDUs. It is the PhoneInterfaceManager class that implements that interface. Digging more, I found that the ultimate class to see
was RIL. RIL implements the CommandsInterface interface. It communicates with the native implementation of ril (that is ril.cpp) using sockets,
namely the "rild" socket. ril.cpp sends the APDU commands to the manufacturer driver of the RIL. I did my experimentation on Nexus 5, so
the library was /system/lib/libril-qc-qmi-1.so.

I compared 2 versions of libril-qc-qmi-1.so: one of Android 4.4.4 and the other of Android 5.0.1. Basically, before and after the new APIs.
I did the comparison using only objdump because no implementation is available. They are almost identical. Both of them defines
qcril_qmi_uim_send_apdu and qcril_qmi_uim_logical_cha. I did not dig more and disassemble the libraries to see the difference
in their implementation.

ENOUGH OF TALKING  AND LET'S GO TO THE REAL THING.
snippet of code:
    String aid = "things in hexadecimal";
    String apdu = "things in hexadecimal";
    TelephonyManager tm = (TelephonyManager) getSystemService(Context.TELEPHONY_SERVICE);
    IccOpenLogicalChannelResponse logicalChannel = tm.iccOpenLogicalChannel(aid);
    tm.iccTransmitApduLogicalChannel(logicalChannel.getChannel(), apdu);
   
    /* strangely, I got the R-Apdu with status 600x (x was the length of the response.
    So, I sent another apdu to get the response. */
    String rApdu = tm.iccTransmitApduBasicChannel(0x00, 0xC0, 0x00, 0x00, 0x00, "");
    tm.iccCloseLogicalChannel(logicalChannel.getChannel());
   
    // Codes to work with rApdu


I installed the .apk as a system app by executing the following script on Windows (My sincere apologies to the Geek community)
  adb shell su -c mount -o remount,rw /system /system; su -c mv %src% %dst%; su -c chmod %dst%; su -c chown root:root %dst%; exit
 where %src% is where you put the .apk on the phone and %dst% is /system/priv-app/%apk_name%

Of course, not rooting the device was not an option because the privilege MODIFY_PHONE_STATE is required and it is not open for third-party applications.

Conclusions,
  #1 In theory, the patch of Seek for Android can work on all devices because now the RIL must implement implements the interface of Android;
  #2 (and most importantly) Google is opening to mobile operators that develop applications requiring communication with UICC (SIM cards). It is
  only one step, but for operators it is on the right direction no matter how small it is.

That's all folks.

Best regards,
Mohamed Sabt

[piyush singh]

Hi Sabt,

Thanks for sharing your observations. Do you now agree that:

1) Nexus 5 supports the new Android 5.0 API's for APDU communication ?

2) But it doesn't have support for AT commands: AT+CCHO, AT+CCHC, AT+CGLA, and AT+CSIM ?

That will be interesting to understand.

Regards,

Piyush

[mohamed sabt]

Hi!

I am sorry if I was not complete in my previous post.
Indeed, Nexus 5 (or any mobile phone that updates its RIL to be compatible with Android 5) supports the new Android 5.0 API's for APDU communication.
And, it does so by updating their RILs to support the 4 AT commands (AT+CCHO, AT+CCHC, AT+CGLA, and AT+CSIM) that are necessary to communicate
with UICC via the modem.

The JavaDoc of TelephonyManager (http://developer.android.com/reference/android/telephony/TelephonyManager.html#) confirms it:
   
    * iccOpenLogicalChannelResponse iccOpenLogicalChannel(String AID) --> AT+CCHO;
    * boolean iccCloseLogicalChannel(int channel) --> AT+CCHC;
    * String iccTransmitApduBasicChannel(int cla, int instruction, int p1, int p2, int p3, String data) --> AT+CSIM;

    * String iccTransmitApduLogicalChannel(int channel, int cla, int instruction, int p1, int p2, int p3, String data) --> AT+CGLA.

Regards,
Mohamed Sabt

[piyush singh]

Thanks that really clarified my doubt regarding implementation of new API's. There is no way other than the support for specified AT commands in vendor's RIL driver for these new API's to work.

Do you or anyone else have any idea if any phone other than Nexus 5 supporting these AT commands (CCHO, CCHC, CGLA) at RIL? 

Regards,

Piyush

[XDA EVA]

Thank you Mohamed for that useful info.

It's great to hear that this is supported in API 21, but most people in the world are still using phones with APIs less than that. Which is what this group is all about, I guess.

So I just want to report that we have made some progress by injecting and intercepting the phone process to get the equivalent of (above mentioned) AT commands. This is obviously also hardware and AOS API dependent, but at least it removes the ridiculous requirement of having to flash an entire custom ROM just to get and access this (already-built-in) functionality. We still haven't tried this method on an open Java Card, but see no reason why it wouldn't work.

Happy Hacking,

E:V:A

[Ahmad Shafiq]

http://developer.android.com/reference/android/telephony/TelephonyManager.html#