[SECURITY] [APP][WIP] IMSI Catcher/Spy Detector

Status
Not open for further replies.
Search This thread

E:V:A

Inactive Recognized Developer
Dec 6, 2011
1,447
2,222
-∇ϕ
UPDATE: 2015-01-14
IMPORTANT!

Although this thread is still open, it is no longer updated with relevant info.
Please go to our official GitHub Site for the latest developer news and join
our development efforts in our back rooms...




attachment.php
For all the latest changes see our CHANGELOG.
For all the latest WIP alpha releases, see RELEASES.

The minimum supported AOS API version is 16, thus
AIMSICD will only work on Jelly Bean 4.1 or later.
---

Call for help to develop an IMSI catcher detector application for Android OS.

Q: What is an IMSI catcher?
A: It is a fake cell tower (aka. Base Transceiver Station, BTS) used to track and monitor specific (groups of) people in the near vicinity of that BTS.


In the light of last years highly publicized events in the many Arabic nations and the German state sponsored rootkit discovery, etc etc. It is of the highest priority to start developing anti/counter-spy applications for the people living in rogue states such as Syria, Iran etc. In addition, it may play an important role in finding (and preventing) other rogue applications that attempt to send silent SMS's to high-cost premium services.

Recently there have been some publicity surrounding the Osmocom BB's, application patch known as "Catcher Catcher" which is used to detect mobile phone tracking and spying, originating from the Mobile Phone Service Provider side. (I.e. something that generally can only be provided by state sponsored government and security forces.)

Relevant links include:
http://bb.osmocom.org/trac/
http://www.youtube.com/watch?v=YWdHSJsEOck
http://events.ccc.de/congress/2011/Fahrplan/events/4736.en.html
http://gsmmap.org/cgi-bin/gsmmap.fcgi?risk=1
http://lab.ks.uni-freiburg.de/projects/imsi-catcher-detection/wiki/Software
http://opensource.srlabs.de/projects/catcher/wiki

For a tutorial on how to compile and help populate the Gsmmap database, see here.

In the News:
http://www.h-online.com/security/ne...iles-and-security-measures-shown-1401668.html
http://www.actualtoday.com/gsm-hacking-osmocom-patch-discovered-silent-sms-and-eavesdropping

This information started 2010 and was extended to last years 28C3 event...

How can you help?

I would very much like to have contact with anyone who can provide more in-depth knowledge how this could possibly be implemented on the AOS. There are several way you can help, eventhough you may not be an expert on HW or even android.


  • Help populate the Gsmmap database.
  • Follow and help/develop the OsmocomBB project.
  • Compile OsmocomBB for an Android phone, so that it can be used as a USB host. (Preferably for one of the more popular models like the Samsung galaxy S.)
  • Help mapping out the Android baseband AT command set or the internal RIL function, so that we can obtain as many GSM radio parameters as possible.
  • Reverse engineer the vendor RIL of the phone above.
  • Reverse engineer the Modem firmware so that we can use the phone as a native catcher-catcher.
  • Find provide documentation of the closed source modem(s) most used in androids.
  • Share other relevant experience you may have in this matter.
  • Find or provide links to documentation of anything baseband related, not already widely known!
  • Stay legal, or this project will close really quickly!


NOTE: This is not to prevent IMSI catchers, but to inform the "victims" that they are being subject to tracking/monitoring.



A few other items:

  • For the Software Change Log, our Github.
  • For Phone Support Log, see Post #7 below.
  • We have contacted EFF and The Guardian Project and hope to join their efforts and provide support to counter illegal tracking and tapping.
  • Thanks to SecUpwN, we now have our own GitHub HERE.
  • Have made a preliminary Developer Roadmap.
  • Added some important links.
  • Licensing Proposal: This will be a community project licensed under a GPLv3 license:
---
Glossary: (Harald Welte)

The BSS (Base Station Subsystem)
MS (Mobile Station): Your phone
BTS (Base Transceiver Station): The cell tower
BSC (Base Station Controller): Controlling up to hundreds of BTS
BP/CP (Baseband/Cellular Processor): Your phone radio/modem processor (usually an ARM 7/9)

The NSS (Network Sub System)
MSC (Mobile Switching Center): The central switch
HLR (Home Location Register): Database of subscribers
AUC (Authentication Center): Database of authentication keys
VLR (Visitor Location Register): For roaming users
EIR (Equipment Identity Register): To block stolen phones


Our Support:

We have as a goal to become a strong supporter of the EFF and The Guardian Project.
Part of all future donations will go to EFF. Intellectual and technological support will
also be given where possible.




 

Attachments

  • AIMSICD_icons_600x.png
    AIMSICD_icons_600x.png
    45.1 KB · Views: 41,945
Last edited:

E:V:A

Inactive Recognized Developer
Dec 6, 2011
1,447
2,222
-∇ϕ
The GSM Ciphering Indicator

According to the 3GPP GSM standards/specifications [1] for handsets,
there should be a Ciphering Indicator (CI) showing the user when the
GSM phone/data connection is not using encryption. Unfortunately for
many people in the rest of the world, this feature have not been
properly (if at all) implemented in the Android OS, AFAIK [2]. The
second culprit is the fact that your cellular service provider have
disabled showing this CI on the vast majority of SIM cards issued
around the world.

The only options for circumventing these privacy problems are:

  1. Write an application that present the current ciphering status. (Easy)
  2. Write an application that hijacks the baseband processor (modem)
    SIM binary-code (in the firmware) to force-enable CI and possibly
    also the use of A5/3. (Hard)
  3. Make and use a copy of your SIM card that has CI enabled. (Hard)
  4. Lobby your cellular service provider to always use A5/3 ciphering. (Hard)
    (A5/1 was never used and A5/2 can be cracked on-the-fly!)
  5. Force Google to fix the issue! This is hard, since the issue is
    already >2 years old at "medium priority", and in addition it
    does not resolve the service provider disabled CI in their SIM
    cards.
As you can see the issue at hand does not look to be resolved
anytime soon. So I lobby for (1) or (2). But to do that we need
some background knowledge. Then I will show you how to read the
CI setting from your SIM card. Then we will figure out how to
write such an application!

References:
[1] 3GPP GSM 02.07: http://www.3gpp.org/ftp/Specs/archive/02_series/02.07/0207-710.zip
[2] Android Issue 5353: https://code.google.com/p/android/issues/detail?id=5353
[3] Dieter Spaar's Blog: http://www.mirider.com/weblog/2010/08/03/#20100803-ciphering_indicator
[4] 3GPP GSM 11.11: ???

Some 3GPP GSM Terminology:
Code:
EF      - Elementary Files 
AD      - Administrative (Data) Field
BCD     - Binary-Coded Decimal (compressed) 
CHV     - Card Holder Verification (usually your SIM code)
TLV     - Tag, Length, Value
BER-TLV - Object that conform to the Basic Encoding Rules (BER)
RFU     - Reserved for Future Use
Background:

[1] § B.1.26 Ciphering Indicator

The ciphering indicator feature allows the ME to detect that
ciphering is not switched on and to indicate this to the user,
as defined in GSM 02.09.

The ciphering indicator feature may be disabled by the home network
operator setting data in the "administrative data" field (EF-AD) in
the SIM, as defined in GSM 11.11.

If this feature is not disabled by the SIM, then whenever a
connection is in place, which is, or becomes unenciphered,
an indication shall be given to the user.

Ciphering itself is unaffected by this feature, and the user can
choose how to proceed.

[3] Ciphering Indicator in mobile phones

According to GSM 02.07 B.1.26, there should be a Ciphering Indicator
in the ME to allow a user to detect if ciphering is not switched on.
The Ciphering Indicator can be turned off by the network operator
clearing (what is formerly known as) the OFM (Operational Feature
Monitor) bit in the "administrative data" field of the SIM.
(See GSM 11.11, 10.3.18)

Usually the Ciphering Indicator is turned off, at least in those SIMs
I have seen so far. And you usually cannot modify the administrative
data in the SIM. But would a phone actually display something if the
Ciphering Indicator is enabled and ciphering is not on?

[4] § 10.2.18 The SIM Administrative Data field

All data on your SIM card is stored in a special filesystem hierarchy.
To not delve too far into the murky depths of SIM data storage, we
jump straight to the particular file we are interested in. It is an
elementary file (EF) called Administrative Data (AD), whose
filename/identifier is just a number, like always in the SIM-card
filesystem. In this case it is known '6FAD' (Hex for 28589).

"
This EF contains information concerning the mode of operation according
to the type of SIM, such as normal (to be used by PLMN subscribers for
GSM operations), type approval (to allow specific use of the ME during
type approval procedures of e.g. the radio equipment), cell testing
(to allow testing of a cellbefore commercial use of this cell),
manufacturer specific (to allow the ME manufacturer to perform specific
proprietary auto-test in its ME during e.g. maintenance phases).

"

Technical Summary:
Code:
-----------------------------------------------------------
Name:           EFAD (Administrative Data)
Identifier:     '6FAD' (28589)  
File size:      3+X bytes
-----------------------------------------------------------
Byte    Description
-----------------------------------------------------------
1       UE operation mode
2-3     Additional information (incl. cipher indication)
4       Length of MNC of IMSI
5-X     RFU
-----------------------------------------------------------
UE Operation Mode:              (byte 1)
-----------------------------------------------------------
This is the mode of operation for the MS.

Coding: (Initial value)
'00'    - normal operation
'80'    - type approval operations
'01'    - normal operation + specific facilities
'81'    - type approval operations + specific facilities
'02'    - maintenance (off line)
'04'    - cell test operation
NOTE: All other values are RFU (reserved for future) use 
-----------------------------------------------------------
Additional Information:         (byte 2-3)
-----------------------------------------------------------
Coding:
- Specific facilities code              (if b1=1 in byte 1);
- ME manufacturer specific information  (if b2=1 in byte 1).

Ciphering indication is enabled by enabling both the specific 
facilities bit (b1) in byte-1 AND the cipher indicator bit (b1) 
in byte-3. Thus the administrative data field has to be:

Byte-1: 0x01    0000 0001
Byte-2: 0x00    0000 0000
Byte-3: 0x01    0000 0001
Byte-4: 0x02/3  0000 001x  
-----------------------------------------------------------
Length of MNC in the IMSI:      (byte 4)
-----------------------------------------------------------
The length indicator refers to the number of digits, 
used for extracting the MNC from the IMSI.

This value codes the number of digits of the MNC in
the IMSI. Only the values (b1-b2) '0010' and '0011' are
currently specified, all other values are reserved
for future use.
-----------------------------------------------------------
Relevant Documents:
TS 22.101
TS 31.102
TS 33.102
-----------------------------------------------------------
How to read the Ciphering Indicator in your SIM

Since there is no API call (AFAIK) for directly reading the SIM data
fields, we are going to use your modems standard AT commands. You can
normally do this in two ways. (1) By connecting your phone via USB to
your PC and use a terminal application to send AT commands (ATCs)
directly to the Baseband Processor (BP), aka "modem". (b) To connect
directly to the modem "device" via some terminal program within the
Android Operating System (AOS). For all the details surrounding this,
please see this thread.

Once you've got an AT command terminal session working, you are free
to issue the relevant AT commands to read from your SIM card. The
particular command we are interested in, is the +CRSM command. This
command can read/write various data directly from SIM card files.

==================================================
If you know of any equivalent or valid AOS API call for reading
this type of SIM data, please let us know!

==================================================

The +CRSM syntax is as follows:
Code:
AT+CRSM=<command>[,<fileid> [,<P1>,<P2>,<P3> [,<data> [,<pathid>]]]]

<command>       This is the operation to be performed:

        176 READ BINARY
        178 READ RECORD
        192 GET RESPONSE
        214 UPDATE BINARY
        220 UPDATE RECORD
        242 STATUS

<fileid>        This is an integer which is the identifier of a elementary
                datafile (EF) on SIM. Mandatory for every command except 
                STATUS and may be e.g.:

        Hex     Dec     File
        ---------------------
        6F37    28471   ACMmax
        6F07    28423   IMSI
        6F39    28473   ACM 
        6F41    28481   PUKT
        6F42    28482   SMS

Structure:
[CLA INS  P1  P2  P3 Data]

The bytes have the following meaning:

CLA             Is the class of instruction (ISO/IEC 7816-3 [25]), 'A0' is used in the GSM application;
INS             Is the instruction code (ISO/IEC 7816-3 [25]) as defined in this subclause for each command;
P1, P2, P3      Are parameters for the instruction. They are specified in table 9. 'FF' is a valid value for
                P1, P2 and P3. P3 gives the length of the data element. P3='00' introduces a 256 byte data transfer
                from the SIM in an outgoing data transfer command (response direction). In an ingoing data transfer
                command (command direction), P3='00' introduces no transfer of data.
SW1 and SW2     Are the Status Words indicating the successful or unsuccessful outcome of the command.

-------------------------------------------------------------------------------
Dec.    <sw1> <sw2>     Description
-------------------------------------------------------------------------------
144     0x90 0x00 normal entry of the command, indicating OK 

103     0x67 0xXX incorrect parameter P3
        0x6B 0xXX incorrect parameter P1 or P2
        0x6D 0xXX unknown instruction code given in the command
        0x6E 0xXX wrong instruction class given in the command
        0x6F 0xXX technical problem with no diagnostic given

        0x9F 0xXX length XX of the response data
        0x92 0x0X update successful but after using an internal retry routine X times
        0x92 0x40 memory problem
        
        0x94 0x00 no EF selected
        0x94 0x02 out of range (invalid address)
        0x94 0x04 file ID not found; pattern not found
        0x94 0x08 file is inconsistent with the command

        0x98 0x02 no CHV initialized
        0x98 0x04 Access condition not fullfiled / unsucc. CHV verify / authent.failed
        0x98 0x08 in contradiction with CHV status
        0x98 0x10 in contradiction with invalidation status
        0x98 0x40 Unsuccessful CHV-verification. Or UNBLOCK CHF / CHV blocked /UNBL.blocked
        0x98 0x50 Increase cannot be performed. Max. value reached
-------------------------------------------------------------------------------
For example, you could also read your IMSI code from your SIM card,
but this is a little more tricky as that operation involves a parity
bit-field in the second byte, while using a compressed BCD coding.

Reading the AD field (containing cipher indication)
Also see +CSIM and +CSCS
Code:
[B]AT+CRSM=176,28589,0,0,3[/B]
+CRSM: 144,0,"000000"

==> Bytes: 1-3 = 00,00,00
    byte1: "MS operation mode" 
    byte2: "Specific facilities" B1
    byte3: "Specific facilities" B2 (+ cipher indication)
==> [COLOR=Red]Ciphering indication is disabled[/COLOR]

Note: a response like this "+CRSM: 103,3" indicates that there is 
      a problem with P3 and that the value for P3 should be 3.
How to write AD and enable the Cipher Indicator in your SIM

Now, this is the most tricky part while being poorly documented.
The problem is that since this is an "administrative operation", it
may require something called a "facility lock password". However it
is not clear to me what this is. Is it just a CHV PIN/PUK or is it
something only known to the OEM or cellular service provider?
Anyone who could provide proper guidance here, will be offered
a beer! (Also see: +CLCK, +CPWD, +CSIM for reference.)

Going through the reading hoops above, we guess that the
proper write command should be like this:

Code:
AT+CRSM=214,28589,0,0,3,"010001"
However, we know from reading other SIM files (IMSI) that sometimes
the data is returned in compressed BCD format. That is, it could be
that the 1st and last pairs of 01's should be swapped to 10's.
So that we have:

Code:
AT+CRSM=214,28589,0,0,3,"100010"

Any ideas?
 
Last edited:

XdxH62

Member
Jan 20, 2012
34
18
Wouldn't it help to use a Database like openbmap.org (I'm not allowed to link yet) to distinguish an IMSI-Catcher from a base station?
 

E:V:A

Inactive Recognized Developer
Dec 6, 2011
1,447
2,222
-∇ϕ
Phone Support Log

This is a list of phones that have been claimed (but not verified) to work with AIMSICD. If you absolutely want to post success stories, do include exact phone model, API level (AOS version), and whether your using a special ROM, and the result from "uname -a" command.

DO NOT POST IF THE AIMSICD DOESN'T WORK FOR YOU!

This App is not even Beta version yet, so we don't expect it to work for anyone than
ourselves at the moment. As soon as this changes, you will find out here!

Current AIMSICD Version: 0.1.6-alpha
Code:
GT-I9100T  Android 4.1.2 Official stocked, rooted
Samsung Galaxy Nexus, CM 11.0 M5
HTC ONE M7 (PN0710000) AOKP M7 Generic (KitKat 4.4.2)
---

Old original post/message:
Wouldn't it help to use a Database like openbmap.org (I'm not allowed to link yet) to distinguish an IMSI-Catcher from a base station?
Unfortunately not. If you had followed the links above, you would have seen gsmmap... It does help trying to map the likelyhood that someone outside an intelligence organization is using one, but you can technically fake any such valid BTS as well. You need other methods... See refs/docs.
 
Last edited:

mai77

Senior Member
Nov 16, 2011
1,429
580
ghost stations

Wouldn't it help to use a Database like openbmap.org (I'm not allowed to link yet) to distinguish an IMSI-Catcher from a base station?

sure, that would make perfect sense. this way you would immediately spot "ghost base stations" that miraculously appear for one day only ... ;)

*#0011# | Network Info
*#32489# | Cipher Info <--- does anybody get anything out of this (OFM-bit) :confused:
*#197328640# | General Service Mode GT-S5360 Galaxy Y : -1-7-3-1-1- in LA4 modem Fw.
*#745# | RIL Dump Menu
 

Attachments

  • imsi.jpg
    imsi.jpg
    30.6 KB · Views: 99,232
Last edited:

E:V:A

Inactive Recognized Developer
Dec 6, 2011
1,447
2,222
-∇ϕ
sure, that would make perfect sense. this way you would immediately spot "ghost base stations" that miraculously appear for one day only ... ;)

That's partially correct, but you need to ensure (at least) two things.
1. That the "detector" you're using is not moving around!
2. That the database you're comparing with have not already been corrupted.

Therefore, you can (and should use a database), but you need a much more advanced algorithm for determining when and how this BTS appeared combined with other criteria.
 

mai77

Senior Member
Nov 16, 2011
1,429
580
in 97%+ of real cases, an IMSI catcher would be in operation for a short while only. this change should be detectable by comparing cell IDs and such of some area in a town, which hardly changes over time.

On an i9000 the code to access the engineering menu (*#197328640# in Dialer) worked – I’m assuming it’s standard across all recent Samsungs, not just the Galaxy S series.

Menu 1,8,3,1 displays the current ciphering status, i.e. whether or not your current call is currently encrypted.

from youtube :

attachment.php
 
Last edited:

E:V:A

Inactive Recognized Developer
Dec 6, 2011
1,447
2,222
-∇ϕ
...
On an i9000 but the code to access the engineering menu (*#197328640# in Dialer) worked just the same – I’m assuming it’s standard across all recent Samsungs, not just the Galaxy S series.

Menu 1,8,3,1 displays the current ciphering status, i.e. whether or not your current call is currently encrypted.

Right, and that's why I have been trying to reverse engineer the Service Mode application, to find out where all that info is coming from, including other parts needed from that app. But I'm new to all this Android stuff, so... Instead this led me to the RIL, but since the interesting parts of the RIL is closed source I tried to figure out what is happening in the modem. This finally led me to post this new thread:

"How to talk to the Modem with AT commands":
http://xdaforums.com/showthread.php?t=1471241

Any tips/ideas how to get this info would be great!

I suspect there will be several different way to get to this, but all may prove relevant...
 
Last edited:

mai77

Senior Member
Nov 16, 2011
1,429
580
http://developer.android.com/reference/android/telephony/gsm/GsmCellLocation.html

to monitor cell data


import com.android.internal.telephony.Phone
import com.android.internal.telephony.PhoneFactory
...
PhoneFactory.makeDefaultPhones(this)
Phone phone = PhoneFactory.getDefaultPhone()



then error:
The com.android.internal.telephony.Phone can not be resolved.
The com.android.internal.telephony.PhoneFactory can not be resolved, because it is a private API. no easy way to use it. :mad: still possible, though
 
Last edited:

kerberos7

Senior Member
Oct 6, 2010
129
31
http://developer.android.com/reference/android/telephony/gsm/GsmCellLocation.html

to monitor cell data


import com.android.internal.telephony.Phone
import com.android.internal.telephony.PhoneFactory
...
PhoneFactory.makeDefaultPhones(this)
Phone phone = PhoneFactory.getDefaultPhone()



then error:
The com.android.internal.telephony.Phone can not be resolved.
The com.android.internal.telephony.PhoneFactory can not be resolved, because it is a private API. no easy way to use it. :mad: still possible, though

News ?

Sent from my Galaxy Nexus using xda premium
 

E:V:A

Inactive Recognized Developer
Dec 6, 2011
1,447
2,222
-∇ϕ
I just updated original post #2 with the procedure for finding out if the ciphering indicator is enabled/disabled on your SIM card. However, this procedure need to be implemented in code/application for practical use. Alternatively, there may be some IPC calls that could be used to get these data...if we knew where to look.
 
Last edited:

E:V:A

Inactive Recognized Developer
Dec 6, 2011
1,447
2,222
-∇ϕ
then error:
The com.android.internal.telephony.Phone can not be resolved.
The com.android.internal.telephony.PhoneFactory can not be resolved, because it is a private API. no easy way to use it. :mad: still possible, though

You could probably use "reflection" to get and use those methods... try googling/stackexchange for that.. We appreciate you attempt! :)
 

mai77

Senior Member
Nov 16, 2011
1,429
580
AT+CRSM=176,28589,0,0,3
results in error code on a Galaxy.

quite some number of xda members have found their entry "Ciphering" ON/OFF in the engineering menu of their phones, e.g. Galaxies. But I didnt come across a reliable report of success. Galaxy Y contains that entry too, but the bit appears unchangeable and might be a placebo menu entry alongside some other placebo toggles. :(
 
Last edited:

E:V:A

Inactive Recognized Developer
Dec 6, 2011
1,447
2,222
-∇ϕ
AT+CRSM=176,28589,0,0,3
results in error code on a Galaxy...

Hi, Sorry for late reply. You have a GT-S5360 (FCC ID: a3lgts5360), but these come in several different versions. What baseband processor is this using? If it's a X-GOLD-based one (XMM 6x60), the command above should work. If on the other you have some other modem, like Qualcomm etc, there is no telling what would happen, even though the +CRSM is a GPP 27.00x "standard". What error do you get, and how do you connect to your phone? (I.e. Make sure you're actually talking to your phone modem and not to some other internal modem device in your PC.)

Also, like I already mentioned in #2:
1) the bit is not changeable on most SIM cards.
2) the actual ServiceMode menu functionality is contained in the Baseband firmware on X-GOLD, for Qualcomm, I don't know, even if it available.
 
Last edited:
Status
Not open for further replies.

Top Liked Posts

  • There are no posts matching your filters.
  • 83
    UPDATE: 2015-01-14
    IMPORTANT!

    Although this thread is still open, it is no longer updated with relevant info.
    Please go to our official GitHub Site for the latest developer news and join
    our development efforts in our back rooms...




    attachment.php
    For all the latest changes see our CHANGELOG.
    For all the latest WIP alpha releases, see RELEASES.

    The minimum supported AOS API version is 16, thus
    AIMSICD will only work on Jelly Bean 4.1 or later.
    ---

    Call for help to develop an IMSI catcher detector application for Android OS.

    Q: What is an IMSI catcher?
    A: It is a fake cell tower (aka. Base Transceiver Station, BTS) used to track and monitor specific (groups of) people in the near vicinity of that BTS.


    In the light of last years highly publicized events in the many Arabic nations and the German state sponsored rootkit discovery, etc etc. It is of the highest priority to start developing anti/counter-spy applications for the people living in rogue states such as Syria, Iran etc. In addition, it may play an important role in finding (and preventing) other rogue applications that attempt to send silent SMS's to high-cost premium services.

    Recently there have been some publicity surrounding the Osmocom BB's, application patch known as "Catcher Catcher" which is used to detect mobile phone tracking and spying, originating from the Mobile Phone Service Provider side. (I.e. something that generally can only be provided by state sponsored government and security forces.)

    Relevant links include:
    http://bb.osmocom.org/trac/
    http://www.youtube.com/watch?v=YWdHSJsEOck
    http://events.ccc.de/congress/2011/Fahrplan/events/4736.en.html
    http://gsmmap.org/cgi-bin/gsmmap.fcgi?risk=1
    http://lab.ks.uni-freiburg.de/projects/imsi-catcher-detection/wiki/Software
    http://opensource.srlabs.de/projects/catcher/wiki

    For a tutorial on how to compile and help populate the Gsmmap database, see here.

    In the News:
    http://www.h-online.com/security/ne...iles-and-security-measures-shown-1401668.html
    http://www.actualtoday.com/gsm-hacking-osmocom-patch-discovered-silent-sms-and-eavesdropping

    This information started 2010 and was extended to last years 28C3 event...

    How can you help?

    I would very much like to have contact with anyone who can provide more in-depth knowledge how this could possibly be implemented on the AOS. There are several way you can help, eventhough you may not be an expert on HW or even android.


    • Help populate the Gsmmap database.
    • Follow and help/develop the OsmocomBB project.
    • Compile OsmocomBB for an Android phone, so that it can be used as a USB host. (Preferably for one of the more popular models like the Samsung galaxy S.)
    • Help mapping out the Android baseband AT command set or the internal RIL function, so that we can obtain as many GSM radio parameters as possible.
    • Reverse engineer the vendor RIL of the phone above.
    • Reverse engineer the Modem firmware so that we can use the phone as a native catcher-catcher.
    • Find provide documentation of the closed source modem(s) most used in androids.
    • Share other relevant experience you may have in this matter.
    • Find or provide links to documentation of anything baseband related, not already widely known!
    • Stay legal, or this project will close really quickly!


    NOTE: This is not to prevent IMSI catchers, but to inform the "victims" that they are being subject to tracking/monitoring.



    A few other items:

    • For the Software Change Log, our Github.
    • For Phone Support Log, see Post #7 below.
    • We have contacted EFF and The Guardian Project and hope to join their efforts and provide support to counter illegal tracking and tapping.
    • Thanks to SecUpwN, we now have our own GitHub HERE.
    • Have made a preliminary Developer Roadmap.
    • Added some important links.
    • Licensing Proposal: This will be a community project licensed under a GPLv3 license:
    ---
    Glossary: (Harald Welte)

    The BSS (Base Station Subsystem)
    MS (Mobile Station): Your phone
    BTS (Base Transceiver Station): The cell tower
    BSC (Base Station Controller): Controlling up to hundreds of BTS
    BP/CP (Baseband/Cellular Processor): Your phone radio/modem processor (usually an ARM 7/9)

    The NSS (Network Sub System)
    MSC (Mobile Switching Center): The central switch
    HLR (Home Location Register): Database of subscribers
    AUC (Authentication Center): Database of authentication keys
    VLR (Visitor Location Register): For roaming users
    EIR (Equipment Identity Register): To block stolen phones


    Our Support:

    We have as a goal to become a strong supporter of the EFF and The Guardian Project.
    Part of all future donations will go to EFF. Intellectual and technological support will
    also be given where possible.




    34
    The GSM Ciphering Indicator

    According to the 3GPP GSM standards/specifications [1] for handsets,
    there should be a Ciphering Indicator (CI) showing the user when the
    GSM phone/data connection is not using encryption. Unfortunately for
    many people in the rest of the world, this feature have not been
    properly (if at all) implemented in the Android OS, AFAIK [2]. The
    second culprit is the fact that your cellular service provider have
    disabled showing this CI on the vast majority of SIM cards issued
    around the world.

    The only options for circumventing these privacy problems are:

    1. Write an application that present the current ciphering status. (Easy)
    2. Write an application that hijacks the baseband processor (modem)
      SIM binary-code (in the firmware) to force-enable CI and possibly
      also the use of A5/3. (Hard)
    3. Make and use a copy of your SIM card that has CI enabled. (Hard)
    4. Lobby your cellular service provider to always use A5/3 ciphering. (Hard)
      (A5/1 was never used and A5/2 can be cracked on-the-fly!)
    5. Force Google to fix the issue! This is hard, since the issue is
      already >2 years old at "medium priority", and in addition it
      does not resolve the service provider disabled CI in their SIM
      cards.
    As you can see the issue at hand does not look to be resolved
    anytime soon. So I lobby for (1) or (2). But to do that we need
    some background knowledge. Then I will show you how to read the
    CI setting from your SIM card. Then we will figure out how to
    write such an application!

    References:
    [1] 3GPP GSM 02.07: http://www.3gpp.org/ftp/Specs/archive/02_series/02.07/0207-710.zip
    [2] Android Issue 5353: https://code.google.com/p/android/issues/detail?id=5353
    [3] Dieter Spaar's Blog: http://www.mirider.com/weblog/2010/08/03/#20100803-ciphering_indicator
    [4] 3GPP GSM 11.11: ???

    Some 3GPP GSM Terminology:
    Code:
    EF      - Elementary Files 
    AD      - Administrative (Data) Field
    BCD     - Binary-Coded Decimal (compressed) 
    CHV     - Card Holder Verification (usually your SIM code)
    TLV     - Tag, Length, Value
    BER-TLV - Object that conform to the Basic Encoding Rules (BER)
    RFU     - Reserved for Future Use
    Background:

    [1] § B.1.26 Ciphering Indicator

    The ciphering indicator feature allows the ME to detect that
    ciphering is not switched on and to indicate this to the user,
    as defined in GSM 02.09.

    The ciphering indicator feature may be disabled by the home network
    operator setting data in the "administrative data" field (EF-AD) in
    the SIM, as defined in GSM 11.11.

    If this feature is not disabled by the SIM, then whenever a
    connection is in place, which is, or becomes unenciphered,
    an indication shall be given to the user.

    Ciphering itself is unaffected by this feature, and the user can
    choose how to proceed.

    [3] Ciphering Indicator in mobile phones

    According to GSM 02.07 B.1.26, there should be a Ciphering Indicator
    in the ME to allow a user to detect if ciphering is not switched on.
    The Ciphering Indicator can be turned off by the network operator
    clearing (what is formerly known as) the OFM (Operational Feature
    Monitor) bit in the "administrative data" field of the SIM.
    (See GSM 11.11, 10.3.18)

    Usually the Ciphering Indicator is turned off, at least in those SIMs
    I have seen so far. And you usually cannot modify the administrative
    data in the SIM. But would a phone actually display something if the
    Ciphering Indicator is enabled and ciphering is not on?

    [4] § 10.2.18 The SIM Administrative Data field

    All data on your SIM card is stored in a special filesystem hierarchy.
    To not delve too far into the murky depths of SIM data storage, we
    jump straight to the particular file we are interested in. It is an
    elementary file (EF) called Administrative Data (AD), whose
    filename/identifier is just a number, like always in the SIM-card
    filesystem. In this case it is known '6FAD' (Hex for 28589).

    "
    This EF contains information concerning the mode of operation according
    to the type of SIM, such as normal (to be used by PLMN subscribers for
    GSM operations), type approval (to allow specific use of the ME during
    type approval procedures of e.g. the radio equipment), cell testing
    (to allow testing of a cellbefore commercial use of this cell),
    manufacturer specific (to allow the ME manufacturer to perform specific
    proprietary auto-test in its ME during e.g. maintenance phases).

    "

    Technical Summary:
    Code:
    -----------------------------------------------------------
    Name:           EFAD (Administrative Data)
    Identifier:     '6FAD' (28589)  
    File size:      3+X bytes
    -----------------------------------------------------------
    Byte    Description
    -----------------------------------------------------------
    1       UE operation mode
    2-3     Additional information (incl. cipher indication)
    4       Length of MNC of IMSI
    5-X     RFU
    -----------------------------------------------------------
    UE Operation Mode:              (byte 1)
    -----------------------------------------------------------
    This is the mode of operation for the MS.
    
    Coding: (Initial value)
    '00'    - normal operation
    '80'    - type approval operations
    '01'    - normal operation + specific facilities
    '81'    - type approval operations + specific facilities
    '02'    - maintenance (off line)
    '04'    - cell test operation
    NOTE: All other values are RFU (reserved for future) use 
    -----------------------------------------------------------
    Additional Information:         (byte 2-3)
    -----------------------------------------------------------
    Coding:
    - Specific facilities code              (if b1=1 in byte 1);
    - ME manufacturer specific information  (if b2=1 in byte 1).
    
    Ciphering indication is enabled by enabling both the specific 
    facilities bit (b1) in byte-1 AND the cipher indicator bit (b1) 
    in byte-3. Thus the administrative data field has to be:
    
    Byte-1: 0x01    0000 0001
    Byte-2: 0x00    0000 0000
    Byte-3: 0x01    0000 0001
    Byte-4: 0x02/3  0000 001x  
    -----------------------------------------------------------
    Length of MNC in the IMSI:      (byte 4)
    -----------------------------------------------------------
    The length indicator refers to the number of digits, 
    used for extracting the MNC from the IMSI.
    
    This value codes the number of digits of the MNC in
    the IMSI. Only the values (b1-b2) '0010' and '0011' are
    currently specified, all other values are reserved
    for future use.
    -----------------------------------------------------------
    Relevant Documents:
    TS 22.101
    TS 31.102
    TS 33.102
    -----------------------------------------------------------
    How to read the Ciphering Indicator in your SIM

    Since there is no API call (AFAIK) for directly reading the SIM data
    fields, we are going to use your modems standard AT commands. You can
    normally do this in two ways. (1) By connecting your phone via USB to
    your PC and use a terminal application to send AT commands (ATCs)
    directly to the Baseband Processor (BP), aka "modem". (b) To connect
    directly to the modem "device" via some terminal program within the
    Android Operating System (AOS). For all the details surrounding this,
    please see this thread.

    Once you've got an AT command terminal session working, you are free
    to issue the relevant AT commands to read from your SIM card. The
    particular command we are interested in, is the +CRSM command. This
    command can read/write various data directly from SIM card files.

    ==================================================
    If you know of any equivalent or valid AOS API call for reading
    this type of SIM data, please let us know!

    ==================================================

    The +CRSM syntax is as follows:
    Code:
    AT+CRSM=<command>[,<fileid> [,<P1>,<P2>,<P3> [,<data> [,<pathid>]]]]
    
    <command>       This is the operation to be performed:
    
            176 READ BINARY
            178 READ RECORD
            192 GET RESPONSE
            214 UPDATE BINARY
            220 UPDATE RECORD
            242 STATUS
    
    <fileid>        This is an integer which is the identifier of a elementary
                    datafile (EF) on SIM. Mandatory for every command except 
                    STATUS and may be e.g.:
    
            Hex     Dec     File
            ---------------------
            6F37    28471   ACMmax
            6F07    28423   IMSI
            6F39    28473   ACM 
            6F41    28481   PUKT
            6F42    28482   SMS
    
    Structure:
    [CLA INS  P1  P2  P3 Data]
    
    The bytes have the following meaning:
    
    CLA             Is the class of instruction (ISO/IEC 7816-3 [25]), 'A0' is used in the GSM application;
    INS             Is the instruction code (ISO/IEC 7816-3 [25]) as defined in this subclause for each command;
    P1, P2, P3      Are parameters for the instruction. They are specified in table 9. 'FF' is a valid value for
                    P1, P2 and P3. P3 gives the length of the data element. P3='00' introduces a 256 byte data transfer
                    from the SIM in an outgoing data transfer command (response direction). In an ingoing data transfer
                    command (command direction), P3='00' introduces no transfer of data.
    SW1 and SW2     Are the Status Words indicating the successful or unsuccessful outcome of the command.
    
    -------------------------------------------------------------------------------
    Dec.    <sw1> <sw2>     Description
    -------------------------------------------------------------------------------
    144     0x90 0x00 normal entry of the command, indicating OK 
    
    103     0x67 0xXX incorrect parameter P3
            0x6B 0xXX incorrect parameter P1 or P2
            0x6D 0xXX unknown instruction code given in the command
            0x6E 0xXX wrong instruction class given in the command
            0x6F 0xXX technical problem with no diagnostic given
    
            0x9F 0xXX length XX of the response data
            0x92 0x0X update successful but after using an internal retry routine X times
            0x92 0x40 memory problem
            
            0x94 0x00 no EF selected
            0x94 0x02 out of range (invalid address)
            0x94 0x04 file ID not found; pattern not found
            0x94 0x08 file is inconsistent with the command
    
            0x98 0x02 no CHV initialized
            0x98 0x04 Access condition not fullfiled / unsucc. CHV verify / authent.failed
            0x98 0x08 in contradiction with CHV status
            0x98 0x10 in contradiction with invalidation status
            0x98 0x40 Unsuccessful CHV-verification. Or UNBLOCK CHF / CHV blocked /UNBL.blocked
            0x98 0x50 Increase cannot be performed. Max. value reached
    -------------------------------------------------------------------------------
    For example, you could also read your IMSI code from your SIM card,
    but this is a little more tricky as that operation involves a parity
    bit-field in the second byte, while using a compressed BCD coding.

    Reading the AD field (containing cipher indication)
    Also see +CSIM and +CSCS
    Code:
    [B]AT+CRSM=176,28589,0,0,3[/B]
    +CRSM: 144,0,"000000"
    
    ==> Bytes: 1-3 = 00,00,00
        byte1: "MS operation mode" 
        byte2: "Specific facilities" B1
        byte3: "Specific facilities" B2 (+ cipher indication)
    ==> [COLOR=Red]Ciphering indication is disabled[/COLOR]
    
    Note: a response like this "+CRSM: 103,3" indicates that there is 
          a problem with P3 and that the value for P3 should be 3.
    How to write AD and enable the Cipher Indicator in your SIM

    Now, this is the most tricky part while being poorly documented.
    The problem is that since this is an "administrative operation", it
    may require something called a "facility lock password". However it
    is not clear to me what this is. Is it just a CHV PIN/PUK or is it
    something only known to the OEM or cellular service provider?
    Anyone who could provide proper guidance here, will be offered
    a beer! (Also see: +CLCK, +CPWD, +CSIM for reference.)

    Going through the reading hoops above, we guess that the
    proper write command should be like this:

    Code:
    AT+CRSM=214,28589,0,0,3,"010001"
    However, we know from reading other SIM files (IMSI) that sometimes
    the data is returned in compressed BCD format. That is, it could be
    that the 1st and last pairs of 01's should be swapped to 10's.
    So that we have:

    Code:
    AT+CRSM=214,28589,0,0,3,"100010"

    Any ideas?
    13
    THIS THREAD IS CLOSED UNTIL FURTHER NOTICE!

    Due to lack of development and no progress in resolving critical issues, combined with the low level of development-relevant posts in this thread, I have decided to close this thread until further notice. We are restructuring the maintenance and development of this App and thus it will remain closed until other developers can step up and carry on this project. We are also looking into other funding possibilities to hire professional developers.

    BUT, THIS DOES NOT MEAN THE PROJECT IS DEAD!

    On the contrary, it means we're taking this project more seriously than ever. In addition, our development ideology has changed in the wake of recent copy/paste projects and scientific publications/articles, not even mentioning our efforts, even though it is fairly clear that most information have been directly obtained from this thread and relevant discussions on our GitHub.

    From now on, all our development notes and discussions will remain closed to public, but open for any serious developer/hacker to join. When Beta release will be available, so will all the supporting documentation.

    If you have any information or other ways to help directly contribute to this project, please contact me or @SecUpwN via email or PM. Any news and successful updates will be posted on our GiHub.
    9
    Hi @SecUpwN

    Now don't get too excited but I have made some updates to the base RawPhone application you have in your repo... These changes are still very early stages of bringing RawPhone to a point where it can possibly do some of things that you have been capturing within this thread.

    To save me typing everything a second time I have pasted below the commit comments which I hope captures everything I have done so far, but please be mindful that this is the first tiny step :eek:

    I will make a pull request but if you would prefer to test this by cherry-picking then just close the request and pull the commit directly from my Github.

    There is so much more to do and some of things I have rolling around my head include being able to identify possible suitable serial devices available on the phone, a database of AT commands and of course the ability to issue custom commands. Also possibly the extension of the Android telephony manager service to access or capture data relevant to this project.

    One thing I did realise I forgot about in my message was that I began to create a ATCommand class to process and interpret responses if the microcom applet was to fail but this is basically useless at the moment :D More to come on that once I get back to it!!

    Initial Development Commit Comments
    I don't really know where to start with this but here goes, there is a
    MAJOR amount of work still required to bring RawPhone even close to what is
    hoped for but I think this gives a solid base to start with even if it is still
    very rough! :)

    This commit makes a number of significant changes to the original base
    RawPhone application each of which will be explained in detail below IF
    I can remember them all...

    1. Device information was split into a new class to allow easy modifications
    in the future, all items such as IMEI, Operator etc are now contained within
    this class.

    2. RootTools library added to provide access to helper functions such as
    checking for the provision of root, and offering installation of BusyBox if
    it is not detected.

    3. CMDProcessor - The AOKP CMDProcessor has been added to RawPhone allowing
    shell commands and various helper functions to be executed, I find this library
    to be very stable and it works very well. Some items already added with this
    include checking for Busybox installation and the util Microcom which should
    allow some form of serial communication on the device (NOT TESTED YET!).

    4. Microcom applet - This is an applet available through Busybox which has been
    included and RawPhone will prompt to install this if it is not located, initial
    reading regarding this points to the fact it is supposed to allow for the
    issuing of basic AT serial commands ON THE DEVICE. Very interesting indeed but
    as yet this is untested as I have not written the methods to issue the AT
    commands using the applet.

    5. Initial changes have also been made for a revamp of the UI but as yet this
    has not been implemented.


    I am sure there is so much I have forgotten to mention but it is getting late and if I don't go to bed soon I shall never get up for work tomorrow, but like I said this is very rough but at least some progress although from looking at the application once launched you would not really know it. I will hopefully update some of code tomorrow to bring it more in line with Android code standards and also work on some more of UI etc.

    I will check back in tomorrow at work if I get a change but if not once I get home.
    8
    !!! HAPPY BIRTHDAY AIMSICD !!!


    Today we celebrate our first anniversary of having opened our GitHub!
    Come join the party and give your low level baseband knowledge a kick
    in the rear.