-
Notifications
You must be signed in to change notification settings - Fork 941
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SIM card File System Access #96
Comments
Perhaps users like: @chronomex , @illarionov , @andr3jx can be of help with this issue? |
The approaches for extracting Kc and TMSI I found use AT+CSIM command to issue raw APDUs. We can't send APDUs to the SIM, because AT-commands like +CSIM are not supported in Android. It is necessary to modify the RIL to make them work, which is what Seek for Android does. SIM IO commands in android are issued using +CRSM, look into reference-ril.c code. We can't use STK because we can't install JavaCard applets onto SIM without a key, which only the operator of the SIM has. You can only install an applet if you have a developer SIM where you know the key or if you have somehow the luck to get a SIM where you don't need the key. So I looked into +CRSM command to see how it works and what it can do. We use this command already to obtain the ciphering indicator. I managed to read TMSI and LAI. For T3212 value I got 00. Demo:
176 is for READ Binary, 28542 is decimal representation of EF fileid 0x6F7E. Other parameters should specify the record number and length of response. This should read Kc from file 0x6F20, doesn't work on my SIM
This should obtain BCCH info from file 0x6F74, also doesn't work on my SIM:
When I issue this commands I get 106, 130 as reply.
AT+CRSM - Restricted SIM access
ReferencesCRSM No APDU support: Most RIL (radio interface layer) implementation for Android is relying on the +CRSM (restricted SIM access) AT command for providing SIM IO service. I was wondering if anyone knows a Android RIL implementation (and platform) that does use something other than +CRSM (like +CSIM, or some other type of raw SIM access). - source you can see how requestSIM_IO () method reads sim card contacts, the android code uses the AT+CRSM command. AT commands can be seen in 3gpp 27.007 document - source translated AT+CSIM Command: This one is the eldest and most well-known command: some phones allow you to use one of the standard-defined-but-not-always-implemented AT command AT+CSIM which let’s you to send raw APDUs (=”commands”) to the SIM-card via the modem. The amount of phones supporting this is very limited, according to some people older Siemens and Alcatel phones let you do this. Also older iPhone’s (3GS/3G/2G) let you do this if you are jailbroken (you need to install minicom from Cydia then connect to the device /dev/tty.debug). Newer iPhone’s don’t really let you do this, iPhone 5 owners – we all are out of luck. - source Seek for Android: In order to access card applications on the SIM card like any other Secure Element using the SmartcardAPI the baseband processor must provide some additional AT commands to enable transparent APDU exchange. For security reasons the APDU exchange must be limited to logical channels between the Android world and the card applications. The basic channel of the UICC must be reserved to the baseband processor. The AT+CSIM command transmits the command APDU to the SIM card, and returns the response APDU to the caller. This command allows exchange of any APDU, and should be handled with great care. The baseband must limit the range of command APDUs to the essential needs. - source The RIL implementation on current Android phones do not support the required AT commands. For this reason the UICC patch includes an emulator extension (emulator.patch), which adds support for the required AT commands to the emulator's RIL implementation (reference-ril). On real devices, the proprietary RIL library is very restrictive in terms of APDU access to the SIM or STK support and (normally) needs to be extended. However, on the emulator a patch can be applied in order to provide full SIM access through the host PC/SC system. - source Android RIL supported AT commands for SIM IO: Installing JavaCard applet onto SIM: Loading Java Card Apps:
"All apps are loaded and authorized by the Issuer Security Domain – in practice this means that you can’t load apps onto a card you didn’t issue yourself :( The AOSP version of Android does not provide a standard API to use the SIM card as a SE, but many vendors do, and as long as the device baseband and RIL support APDU exchange, one can be added by using the SEEK for Android patches. This allows to improve the security of Android apps by using the SIM as a secure element and both store sensitive data and implement critical functionality inside it. Commercial SIM do not allow for installing arbitrary user applications, but applets can be automatically loaded by the carrier using the SIM OTA mechanism and apps that take advantage of those applets can be distributed through regular channels, such as the Play Store. - source "You just need a valid SIM with the correct PKCS#15 access control rules set for your applet, http://code.google.com/p/seek-for-android/wiki/AccessControlIntroduction or an Access Rule Application (ARA) that allows all apps to send APDUs to any AIDs." Before loading an applet, you must to do an authentication with the Card Manager on Smartcard. In order to do the authentication, you have to know the card issuer keys. There is a limit number of attempt to authenticate. Usually this number is 10. If you exceed this limit, the card will block. Once you do a successfully authentication this limit is reset. - source Vodafone UK do not allow any third party to load any SIM Toolkit applications to any of their SIM cards. This is also 1 for most Vodafone companies around the world but please check with your local company for confirmation. The main reasons for this are: 1) The SIM card belongs to Vodafone and is a secure device that is protecting our revenue. Applications on the SIM could compromise this security. [...] - source Really strange for me but I did this without entering any key. - source SIM cards for cellular networks: An introduction to SIM card application development - Uploading / Installing an applet to the SIM (page 34 / doc-page 41) Java Card applet developer guide: Java Card Applet Installation (page 33) |
I know now why I couldn't obtain Kc and BCCH. I have a USIM which has an other file structure. I could obtain Kc using
The file for CPBCCH is also present, but it needs additional parameters to read it. |
Interesting stuff! Is there a way of detecting which type of SIM someone has? How do you issue those commands, @andr3jx? Via the AT Command Injector of AIMSICD, or through an ADB root shell? |
@SecUpwN
I simply used MTK engineer app to send commands and logcat to read the response. But we had already the discussions about how to send AT commands and I'm sure every Android RIL should have support for +CRSM command. |
I went through EVAs post about the CRSM command. Reading the ciphering indicator works, but the command for enabling the ciphering indicator doesn't change anything. When I execute EDIT: It is not possible to write / change EF-AD from outside. The reason is that the access condition for updating this file is ADM (Administrative). So we can't do this without having a special key, which only the operator has. The same problem as with installing javacard applets. |
That's correct. You need a JavaCard (or whatever else they call them) and copy your original card to it, including keys etc. For this you need special SIM MiTM tools. This, however, is out far beyond what we're trying to do here. We only want to read the SIM files (already mentioned above). @andr3jx You're using the MTK based modem, which are more properly corresponding to AT Command set 3GPP standards, therefore you have no problem reading EFs using +CRSM. However, on the Snapdragon MSM8974/8960/8930 modems, there seem to be something else going on. As already mentioned above, these are probably "blocked" in either AOS, RIL or in Modem. It is very unlikely they are blocked in modem, since one way of blocking is by using PIN2 as is indicated in the ril sources: From comments in: ril.cpp Line: 696
and from ril_commands.h Line: 45
But most Network Operator supplied SIMs doesn't come with a PIN2/PUK2 these days, so I simply don't have it, and is investigating how Qualcomm is dealing with EF reading. |
For example, on my MSM8930 device: # say at+cpin?
at+cpin?
+CPIN: READY
OK
# say at\$qcsimstat?
at$qcsimstat?
$QCSIMSTAT: 0,SIM INIT COMPLETED
OK
# say AT+CRSM=176,28542,0,0,11
AT+CRSM=176,28542,0,0,11
ERROR
# say at\$qcpinstat?
at$qcpinstat?
$QCPINSTAT: READY,READY,READY,READY,READY,READY,SIM PIN2
OK
# say at+qcpwd=?
at+qcpwd=?
+QCPWD: ("SC",8),("P2",8)
OK
# say at+cpwd=?
at+cpwd=?
+CPWD: ("AB",4),("AC",4),("AG",4),("AI",4),("AO",4),("IR",4),("OI",4),("OX",4),("SC",8),("P2",8)
OK There we see that we need to supply PIN2 on item 7, and that SC (PIN1 change) and P2 (PIN2) are 8 characters long. (This need confirmation.) The items from the AT$QCPINSTAT command, sends to the ME the status of all PINs for all cards, like this:
|
The thing with PIN2 is not a problem because PIN2 can be NULL.
in ril.h, you have also this comment:
|
Maybe I am missing something, but I don't see the need to implement this with AT commands or manual SIM IO. Android's telephony layer already has SIM file access, for example loadEFTransparent() issues the READ BINARY command with a file ID and size, as you are doing with AT commands. fetchSimRecords() reads several files this way. It's probably not exposed to normal apps, but this app requires root, right? Seems like it should be easier to gain access to these code paths, than implementing modem-specific stuff for all the vendors. Once it gets down to the closed-source RIL libraries, they probably issue AT commands, but I don't see why you need to know how that works in order to use it from Java. Or have you tried these API's, and maybe access to the files you want is restricted by the RIL? Sorry if I'm not suggesting anything new, or this conversation is out of date. |
Welcome @scintill! Thanks for your input. What you're seeing is a rather clueless and desperate development team, who's trying to figure out how to access the EF files mentioned below. We haven't even tried to use the internal functions, since we simply do not know how to use them properly. So this conversation is certainly not out of date. Just to summarize. We would simply like to READ from any commercial SIM card, the following EF files:
Any suggestions, guidance or help on how to do this would be extremely appreciated. |
Ha, well I feel clueless too, as I've now realized how hard my idea would be to do. I'm pretty sure those objects are living in the com.android.phone process. It would be one thing to define some reflection wrappers to get ahold of otherwise-hidden classes, it's another to cross the process boundary and invoke stuff inside another VM. I think an Xposed module might allow us to inject some code into that process, but would you want to have that dependency? Something to think about. Luckily, other options you've discussed seem feasible: the SEEK API, or injecting RIL_REQUEST_SIM_IO in the ril socket. I will start with SEEK, because CyanogenMod 11 is supposed to support SEEK and I have that. If it does work, it would probably be the most stable way to go, but it won't be supported on all devices. We could then try adding the RIL socket request method, or Xposed injection, as a fallback for devices without SEEK. |
@scintill Yes, we just had an Xposed discussion. We like Xposed very much, but we are worried about this code dependence, and would like to avoid it if possible. In addition, we still don't understand their code or how to implement it in our case. In addition, we were also hoping to be able to run our App on stock firmware without root, in the future, and Xposed requires root. Also, I think we're already hooking some internal stuff using OEM_HOOK_RAW, but I don't know to what extent this can be used for SIM EF access. I've also been "looking" at trying to better understand how and if SEEK can be used. But so far no particular clarity or success. I'm trying to get some help on the SEEK for Android email list, but so far no breakthrough, and things are moving too slow. What is strange with your original post, is that there is no reference in API's lower than 21, to use those calls, even if present in JB4.2.2, and somewhat explained here: /**
* This class is responsible for keeping all knowledge about
* Universal Integrated Circuit Card (UICC), also know as SIM's,
* in the system. It is also used as API to get appropriate
* applications to pass them to phone and service trackers.
*
* UiccController is created with the call to make() function.
* UiccController is a singleton and make() must only be called once
* and throws an exception if called multiple times.
*
* Once created UiccController registers with RIL for "on" and "unsol_sim_status_changed"
* notifications. When such notification arrives UiccController will call
* getIccCardStatus (GET_SIM_STATUS). Based on the response of GET_SIM_STATUS
* request appropriate tree of uicc objects will be created.
*
* Following is class diagram for uicc classes:
*
* UiccController
* #
* |
* UiccCard
* # #
* | ------------------
* UiccCardApplication CatService
* # #
* | |
* IccRecords IccFileHandler
* ^ ^ ^ ^ ^ ^ ^ ^
* SIMRecords---| | | | | | | |---SIMFileHandler
* RuimRecords--- | | | | | |----RuimFileHandler
* IsimUiccRecords--| | | |-----UsimFileHandler
* | |------CsimFileHandler
* |----IsimFileHandler
*
* Legend: # stands for Composition
* ^ stands for Generalization
*
* See also {@link com.android.internal.telephony.IccCard}
* and {@link com.android.internal.telephony.IccCardProxy}
*/ |
Yeah, I agree it's good to avoid requiring root or Xposed. I see in your SEEK post that you apparently have its SmartcardService installed, so hopefully that's at least one other person who can test anything I manage to produce. Right, those APIs are not part of the public API. We could use them with reflection or API .jar hacking, but it doesn't do a lot of good, since we eventually need the live RIL to actually do the SIM I/O anyway. What I am working on now is copying these classes into AIMSICD, and implementing a minimal "RIL" to use SEEK's UiccTerminal.simIOExchange() to send the file-reading commands. The benefit of using the telephony classes is that they already handle the parsing, and a bit of structure for different types of SIMs. Perhaps once I get something working, I'll be able to strip down the telephony classes to only require what we need. I linked to CyanogenMod's SEEK -- I'm a bit uncertain if SIM I/O will be supported in all versions of SEEK, but I guess we'll find out. |
API 21 is for Android 5 and it is good news to see that there is now a public API for transmitting APDUs. |
@scintill Awesome! But what are you saying here?
From my logcat in that SEEK thread, it seem that something is indeed working but not finding something else...
(logcat from running PerformanceTester.apk ) I've also tried running the OMAPIsuite.apk from SIMalliance. (But you need signup there, so you can get hundreds of of other documents.) That kind of works to some extent. See: For easy access you can download all of above, consisting of: NOTE: Unless you have a developer SIM/SC you probably cannot upload the applets to your SIM. |
I don't know why this should be relevant. Stock ROMs don't offer a SmartCard API so you can't communicate with the SIM card. Without patching Android source code for Smartcard API you won't be able to talk to the SIM card. |
I mean it's not as straightforward as I originally thought, because you can't simply re-use those objects in the app, since the RIL is in another process. I'm trying to adapt the classes to SEEK, though.
I don't know how prevalent stock support is, but at least Galaxy S3 reportedly has this API in stock. |
Right, according to this doc - slide 8 the API should be available on these devices, but the list could also just refer to NFC support, so not sure:
I don't know how many percent of the android market these devices make up so not sure if it is worth it. Still I'm optimistic about Android 5's new API. |
Ok, either I'm very confused here, or you are, but more likely all of us. :D First, @andr3jx we're not doing any form of authentication, so that document is irrelevant for this issue. We're just trying to read from SIM card. That's it. Every phone obviously supports some kind of SIM card reading and access mechanisms. We just have to find out to what extent this has been standardized, and try to hook into it, or find out how RIL is communicating with it, and try to circumvent any restrictions. In addition we're trying to support from API 17 and up, so what is only available on "L" (API 21), is not so interesting at this point. All what they have done there, is making some of the already existing binary code available to the AOS API. The SIMAlliance's Open Mobile API (OMAPI) seem to be the current and future way of UICC communication. So if you have a stock device, please try to install and run the app I posted and let me know what happens. It should go through an arsenal of ~100 tests and present the results. In addition the source code, used for each test is shown in the app. That app probably requires the device to use the SmartcardService: On my Samsung S4 mini (GT-I9195) I have the following SIM related packages:
On my GT-I9100, AOSP KK4.4.2, this doesn't even install, and fails with:
Then trying SIM lock from settings (still on I9100), I find this in the logs:
which show that its accessing ICC through settings, while the radio logcat indicates that most RIL logs are originating from the com.android.phone app, started by zygote. So what I'm saying here, is that there must be a smarter way to do this than compiling AOS from sources, just to get SEEK to work, so we can read a damn simple EF card. |
@scintill Yes! I've seen that post as well, look very promising. They provide code and explanation. In addition, some guy also post code on both SEEK and Stackexchange. And with the post explaining how to Accessing Smart Card File Structure, we should be able to write an idiot-proof PoC app that does, only one thing. For example, reading the EF-LOCI file. We can then use this to extend functionality on other models and phones using other standards. Finally implementing it into our app. |
@E3V3A I know we don't do authentication but I searched for a list of devices which have Open Mobile API available, which they mention there because it enables communication with a Secure Element ( and SIM cards are Secure Elements). I don't have a device where the SmartCard Service is installed, so PerformenceTester.apk doesn't work and there is also no Open Mobile API available. I assume only a small number of devices offers them. If the device offers Open Mobile API then you can use it to communicate with the SIM card. |
@E3V3A and @andr3jx, not sure if this helps us any, but have you seen the UICCTester by @PMTM? |
First off, I posted some really rough code here (direct link to SIM I/O part), in the form of a patch to the app that tries to logcat out a file's contents. See the commit message at the top for rundown of what it does and needs to do. If you're familiar with Binder, or the "service" command-line app and its output, I could use your help. I suggest we keep discussion about that code on its commit page, to keep this thread clear. Some good information here. Nice spotting the Android 5 API -- we could use it when it's available, but it would be nice to have fallbacks too. So, I found that the OpenMobile service in CyanogenMod 11 is not built by default, and I couldn't get it to build when I enabled it. Seems to depend on some closed-source stuff that CM doesn't handle right now. However, stock Android 4.4.4 on Sony Xperia Z1 Compact has it. I tried out the test apps. PerformanceTester app crashes with this:
A 1.8GB String?! I guess it's a mismatch between the version it was built for, and what I have. The service APK's version is 3.1.0. The OMAPISuite seems to work, as well as it can. What I mean is, it seems to be written for certain smartcards that we don't necessarily have (for example, some tests try to connect to certain Application IDs [reference to apps running on the card] that seem to be test applications that won't be on our SIM cards). Some tests also fail with errors like this in logcat:
I tracked that down to here, and the comment makes me believe this is more of a problem with my SIM than anything else, but I think all SIMs would have this problem, unless they are meant to also be used as a secure element, as mentioned. We can't really depend on that. Even then, it might not grant us access to the SIM's actual GSM application, which is what we want. Interestingly, this security limitation appears to be a later addition to the services, so maybe some of you have an older version that won't enforce it. You can try out the disabled OpenMobile code in my patch linked at the top. Nice find on the UICCTester. It gives me the same access-denied error, though. |
I just read my phone number from the SIM card with SIM I/O! New code here. Requires root and SEEK (but not OpenMobile service), and probably adjustment of the user ID that calls the service. I know the phone number isn't very exciting, but it was the easy test case, and I don't have more time tonight to try others. It should be fairly straightforward to read the other files now... Unfortunately, I'm thinking root is an unavoidable requirement for reading these files, unless some devices allow access through the OpenMobile API, or someone figures out how my test of that was flawed (there's disabled code for it in my last commit.) Or maybe there are less-privileged vendor-specific ways. |
There is no way to do this reliably, unless you are using a custom ROM and are running as system or some other privileged user. The OpenMobile API won't allow you to open a basic channel (it's reserved for the phone application), and even if you manage to open a logical channel you are subject to access control restrictions. The rules are encoded in the SIM, so you can't change them. You can only patch OpenMobile to ignore them, again back to custom ROM. If you tried really hard, you could probably get a root daemon started on boot (ala SuperSU) and pipe commands to it via a local socket. But this would be a giant hack, probably device dependent also. Access to the daemon might be subject on SELinux restrictions on newer devices and be blocked though. If you tried even harder, you could write a privileged native Binder service (ala keystore) and access it through Binder. But that's basically installing a backdoor on your device, again back to custom ROM. Not clear what the end goal is here, but even if you got reliable file read access, you still won't be able to read protected files. |
Both PerformanceTester and the OMAPIsuite relies on trying to install some accompanying applets (*.cap) on to the USIM card, for some of the tests. This will obviously fail on MNO provided SIM cards as we do not have the key to install to those. So don't expect all tests to pass, unless you have a developer JavaCard (or whatever they call them.) The permission denied issue is lightly related to the issue above, and is almost the same problem as I had when trying to run PerformanceTester above. The common logcat error:
The structure is something like this:
And thanks to Daniel Alberts SEEK forum post you can create this structure yourself (on compatible developer cards.), in order to grant full APDU access for all applications on devices, modify the card in this way:
(Provided only for reference, since this is overkill and OT for this project.) Having root is one of our requirements. Trying your service call without doing anything on my I9195, will result in this: u0_a202@MSM8960:home # service call phone 55 i32 28480 i32 178 i32 1 i32 4 i32 64 s16 3F007F10
Result: Parcel(
0x00000000: ffffffff 00000022 006e004f 0079006c '...."...O.n.l.y.'
0x00000010: 00530020 0061006d 00740072 00610063 ' .S.m.a.r.t.c.a.'
0x00000020: 00640072 00410020 00490050 006d0020 'r.d. .A.P.I. .m.'
0x00000030: 00790061 00610020 00630063 00730065 'a.y. .a.c.c.e.s.'
0x00000040: 00200073 00490055 00430043 00000000 's. .U.I.C.C.....') (I also tried by prefixing with In regard to all this, it seems that a modified version of "SEEK adaptations in RIL for Galaxy S3" method may be the way to go. We're already using RIL_REQUEST_OEM_HOOK_RAW in our multi-client-ril adaptation in SamsungMulticlientRilExecutor.java and OemRilExecutor.java. |
@E3V3A There are two basic ways to get privileged access on Android: [1] be signed with the platform certificate and [2] be a system app (i.e. reside on the system partition). You cannot generally fake a platform signature, so that leaves [us to use (2), by] installing stuff on the system partition. You can only do that reliably via an OTA package in recovery (like how SuperSU is installed), but this, of course, requires an unlocked bootloader. You cannot patch OpenMobile [apk] in place without invalidating the signature, so that leaves replacing the whole thing, which would change the package signature and might break some of the builtin vendor apps. If you don't care about this, you should be able to get your app working with a patched SmartcardService.apk installed via OTA. There might be differences in different devices though, so you have to account for that. [3] The third way is to start a privileged service daemon on startup (like daemonsu). You will be able to specify the user the service runs as, so you can choose one that is allowed to connect to telephony and read the SIM. You cannot inject SELinux polices without modifying the boot image, which is another can of worms. Once you do this, you are getting even closer to a custom ROM... [E:V:As EDIT's in square brackets, for readability. Sorry, but we're all new to this.] |
Read http://www.globalplatform.org/specificationform.asp?fid=7825 regarding access control/ARA Also this code regarding the meaning of 'signature'. 'Signature' here means the signature/certificate of the app (APK) that is a client of the OpenMobile API. What the SmartCardService does is read the access rules from the SIM and compare the certificate of each client application with the one in the rules. That is why vendor apps work (because their signing certificate is referenced in the access rules, on the SIM), and 'homebrew' ones get access denied. |
When reading a file from UICC, you are actually talking to file serving app, which means you are selecting AID of that file serving app. Actually there are multiple aproaches to reach the UICC, AT commands is just one of them, but there are also pipes and binary commands doing the same depending on how the control channel to the UICC is established. PKCS#15 files that contain access control (old way) or ARA-C/M (trying to hide the file structure and extend it to merge model where Security domains might provide their sub ACLs). PKCS#15 contains besides Java SATSA, Android AC also Certs and keys - thus interesting for other uses. Thus some structures might be available without AC because those are used for AC itself (yes it is weird!) All that depends on how good design and modularization was done in the OS, actually user app should never get access to the files directly, unfortunately either rooting or poor design could cause to cause failure to those attempt to protect the UICC against malicious attacks. There is also one funny thing. It is called basic and logical channel. As the UICC aging technology tried to resurect itself the manufacturers tried to bring USB (2 additional pads - bottom ones when having UICC/smart card contact pads) to serve faster connection and ethernet over USB - search for supersim presentations - webserver on sim (SCWS - simtoolkit 2.0), also SWP aka use of UICC for CLF/NFC secure element is such attempt... but comming back to ...channels. The sim card has actually one ISO 7816 interface through which you can access its contents, it has no interrupt line towards host/card reader this notifications has to be pulled from the card (same as USB device/peripheral). But the ISO 7816 was enhanced with so called logical channel that extended the ability to select multiple applets on sim while running multiple OS applications (but still limited to few 3-16 depending on setup and card manufacturer). The worst message comes that applets cannot be usually selected twice. Thus as many things is handled through single applet even attempt to access such applet while being in use by GSM modem (auth algo) or so might cause either fail of both or fail of your app or unpredictable behavior... and at the end your data connection might break in such case. Safe way is to stop RIL in certain cases = drop connection and have full access to the UICC. |
To the how to sign an app: to get current CERT has to put there use: keytool -list -keystore $HOME/.android/debug.keystore -v -storepass android then the line like: SHA1: 11:ED:DB:7F:44:24:17:F0:7D:9F:92:8A:7E:E8:77:00:B9:28:1D:D9 lists the SHA1 which should land in android AC together with either wildcard or particular AID, optionally you could also replace the hash with wildcard but not sure whether any-hash to any-aid is generally supported. |
not always AT commands search for "/dev/qmi"... |
@nelenkov and @PMTM:
What does that mean? I think you're referring to the Qualcom QMI interface, and trying to use that to read USIM, but if we have that, then we don't need to read SIM, as all we need is present in that API. So yes, we're interested in looking into that very soon... Ok, so apart from trying option (2) or (3) from Nikolay, it seems rather futile trying this, while other experiments seem to show some possibility...but very hard to manage. So what would you suggest doing? |
There is currently no portable way to do this. Two basic options:
|
@nelenkov I've essentially written Option 2, targeting TelephonyService. See here. The short explanation is that I use the "service call phone ..." command line utility, run under the privileged UID (which is the only access check in this endpoint, in the implementations I've seen) with I'm now tinkering with using ddi to inject code into |
It seem that development on this topic has stopped completely. Perhaps we could have a status update from @andr3jx and @scintill, who was working on this? If not, perhaps @thomascannon could have some valuable knowledge about how to get this working? In addition it seem that we may need the following permissions to be able to use the NFC device path to get to SE. <uses-permission android:name="android.permission.NFC"/>
...
<service android:name=".MyOffHostApduService" android:exported="true"
android:permission="android.permission.BIND_NFC_SERVICE"> and some more...to select AID. |
I have a solution with ddi injecting into the com.android.phone process, code here (the repository is now mis-named, as the active code doesn't use SEEK.) It's been tested on 3-5 phones. As I recall, on one it silently fails injecting (logs show part of the process working, then no further logs and the SIM file reading doesn't work; I was stumped by this several weeks ago and haven't looked at it again.) I also have a report (and maybe seen for myself a time or two) that it doesn't work for the first time, but does if the test activity is re-launched. This may just be a timing issue, of not waiting long enough between injecting and trying to call the new service. I am thinking I will have the injected code signal back to the application when it's ready, which could help. In theory it could work on all pre-Lollipop devices (I assume ART breaks ddi) with root, but may need adjustment on some versions, or for vendors that change the telephony code (such as Mediatek, which is accounted for in the current code.) So, we've got something working, but it needs more polishing, and I haven't really had the time or insight to do it yet. If we get AT commands working robustly on most devices, we might implement SIM file reading on top of that instead. The code is structured to be adaptable to different methods of SIM I/O. |
Joey, Was that on my phone? Did you try it on other Samsungs? (Which?)
We will use both (and more). We'll have to use whatever is available on the device AIMSICD is running on, and for whatever stuff we want to look at. |
I currently do not have anything technical to add yet beyond the great work and opinions expressed here. But wanted to add some other thoughts. It is hard now to access the SIM directly, and will surely get harder. The SIM is sometimes used as a secure element for things like 2FA precisely because it is hard for malware to access it, so it is in the user's interest for Google to protect access to it. So I think a lot of energy will be burned trying to find and maintain workarounds for a menagerie of handsets. Another option is to select one or a few devices that will be fully researched and developed for, and every year or so select the next device in the upgrade path. Selection criteria would highly rate any device which is more easily hackable, such as MTK based. The energy saved could be better spent developing new features and making a more complete solution. One downside is that the target device might not be your daily driver, and while it can operate as a standalone solution, you might need to discover if your daily driver is being specifically targeted with IMSI selection. |
@E3V3A can you please share the GlobalPlatformOrg.7z again? |
May I ask you if you're just interested in that |
@rena2019, we've already got SIM access, so we just need someone to do the code. So those doc's are not gonna help you and you can download them yourself at their website. (They've been updated.) |
WoW, I haven't understand anything up there, how can get a course to read this??? |
What was that?? |
hi i want to work with file systems of sim cards ,how i can access to som files like ef imsi that i need the adm access wich key is ralated to this ??please help me thanks |
do you have any resource to i read about keys in sim and usim |
I try |
Is it possible to mount the sim card filesystem so that android can write to it as if it was an external card? |
Hello there, |
we were trying to extract the Kc from the SIM card on an Android A72 - A7 using minicom on ubuntu 20.04 connected with the charger cable.
|
@hayabaq Maybe you can try an other command instead of READ BINARY. Read Binary requires "transparent" structure of file, not sure if this can be a problem here. Try READ RECORD / GET STATUS / GET RESPONSE to understand what is going on. Also check this reply. Another possibility might be that the file has beed deactivated for whatever reason. In this case only the SELECT command will work and you should be able to use ACTIVATE / REHABILITATE command to activate the file. You can also try to run the GSM algorithm which provides Kc as response. |
We need to be able to access the SIM card filesystem in order to work some magic while collecting relevant and necessary network data, not available from AOS API.
There may be many ways to read the file system on a SIM card. We have previously looked at the possibility of using the modem AT command interface, but we need other alternatives in those cases when baseband does not present an available and proper AT command interface. There are 3 other alternatives for reading the SIM EF / DF (Elemenary Files / Dedicated Files):
https://android.googlesource.com/platform/packages/apps/Stk.git/+/master
The preferred way would probably be to incorporate (1) into our app, since it is already written in Java, but would need to circumvent the signatures in the same way as the ServiceMode "multiRIL-client" does its access. But (1) is risking to use non-available or OEM dependent STK.apks. Thus (2) might actually be a better choice, from simplicity point of view....
If you have any better or further insight, please let us know ASAP!
https://code.google.com/p/seek-for-android/wiki/SCAPI_modules_png
![scapi_modules 1](https://cloud.githubusercontent.com/assets/194392/3788211/745b2954-1a58-11e4-846b-52b499b18839.png)
References:
http://www.kandroid.org/online-pdk/guide/stk.html
http://osxr.org/android/source/packages/apps/Stk/src/com/android/stk/StkAppService.java?!v=android-4.4.4_r1
http://simhacks.github.io/android-emulator/#introduction
https://github.com/shadytel/sim-tools
https://code.google.com/p/seek-for-android/wiki/EmulatorExtension
https://code.google.com/p/seek-for-android/wiki/SecureFileManager
https://groups.google.com/forum/#!forum/seek-for-android
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
The text was updated successfully, but these errors were encountered: