Database Info

Phone Dialer # Format incorret

I have a ROM that I am in the process of porting from Korea to a US model. All hardware works properly. One of the small bugs I still have is the phone number format. It appears to remain in the international format not in the US. I have corrected the region info in the build.prop & rummaged through most of the framework-res.apk and can not find how to get this resolved. More Locale 2 & several other locale apps on the market do not correct this either.
So for the US one would expect:
123-456-7890
123=area code
456=prefix
7890=user assigned #
Instead it shows
12-3456-7890
Phone dials the proper contact and for all purposes functions as it should. But if I post a ROM with this nuisance the complaints will be endless.
Any ideas?
Thanks in advance for all constructive & suggested advice.

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

UPDATE: 2015-01-14IMPORTANT!
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...
​
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
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.
​

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:
Write an application that present the current ciphering status. (Easy)
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)
Make and use a copy of your SIM card that has CI enabled. (Hard)
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!)
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?

Also interested

+1 (never know what can happen in a state governed by Sarkozy... :S )

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?

XdxH62 said:
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?
Click to expand...
Click to collapse
been reading up on this.. quite fascinating.

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)
Click to expand...
Click to collapse
---
Old original post/message:
XdxH62 said:
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?
Click to expand...
Click to collapse
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.
Click to expand...
Click to collapse

ghost stations
XdxH62 said:
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?
Click to expand...
Click to collapse
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)
*#197328640# | General Service Mode GT-S5360 Galaxy Y : -1-7-3-1-1- in LA4 modem Fw.
*#745# | RIL Dump Menu

mai77 said:
sure, that would make perfect sense. this way you would immediately spot "ghost base stations" that miraculously appear for one day only ...
Click to expand...
Click to collapse
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.

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 :

mai77 said:
...
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.
Click to expand...
Click to collapse
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://forum.xda-developers.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...

atdebug.apk
at-command debug tool on android
http://forum.xda-developers.com/showpost.php?p=19485757&postcount=1
you have to know the device name though

mai77 said:
at-command debug tool on android
http://forum.xda-developers.com/showpost.php?p=19485757&postcount=1
you have to know the device name though
Click to expand...
Click to collapse
Yeah, I saw that, but it doesn't work, because the developer is making false assumptions on both which serial device is used, and it's permissions...

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. still possible, though

mai77 said:
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. still possible, though
Click to expand...
Click to collapse
News ?
Sent from my Galaxy Nexus using xda premium

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.

mai77 said:
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. still possible, though
Click to expand...
Click to collapse
You could probably use "reflection" to get and use those methods... try googling/stackexchange for that.. We appreciate you attempt!

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.

I am very much impressed with the informative and interesting discussion. Thanks for sharing such great content with us.

mai77 said:
AT+CRSM=176,28589,0,0,3
results in error code on a Galaxy...
Click to expand...
Click to collapse
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.

[DEC.05.2011] Instantaneous GPS Fixation v1.2! *FOR ALL ANDROIDS PHONES!*

12.05.2011
I would like to take this time to thank everyone that has helped in making this a success, I would like to also thank Rom Makers that have felt that my work was worth adding to their roms, and also to the Users that have taken my work with my permission, and expanded on it.
I am currently looking at adding more locations to the list soon, so keep an eye out
If anyone can help my next project and is Good at programming APK's please PM me.
12.05.12 REGIONAL VERSIONS 1.2 FINAL RELEASED!
USA & International & REGIONAL CWR!
UPDATE:
I would like to thank everyone that has tried this, most of you have had very good success, and some of you have not, do understand that a rom can make the difference, as well as your location, and despite popular belief; weather.
Greetings All,
As some of you have know the long await GPS Script that some have been seeing me speak about. I'll explain how this has come to surface.
As we all know since Windows Mobile we all have had issues at one time or another with the GPS working correctly. Now in Android, we find ourselves in the same boat, with GPS not working, or working some days and not so much on other days. One of the biggest complaints I think that we all have had is LONG wait times. So I went on a quest to find out exactly how this worked And some of what I found out in my opinion is surprising. It seems that as we all know the "GPS.conf" is the helpful source for our locks.
Now I dont mean to give everyone a lesson on GPS but I am sure I'm not 100% right, but from what I have read and seen, neither is our gps.conf file. The file is a generic code and customized to use google as our source. Then we had extra options to add which again were in my book generalized but somewhat helpful. I checked this against US carriers (Such as: AT&T, Verizon, T-Mobile) and found, they all had similar files doing the same thing, some claim success, and others didnt.
One of the problems with our files is the fact its been dumbed down, to the point its TOO General, and the reason for this is cause Developers (Not referring to XDA) have done this to avoid possible errors or conflicts with other parts of the phone or software, so my opinion is they made it simple, but simple doesnt always work. We all know this to be the case cause how many times have we had generic drivers, or files that are used, so that this way "it works". The GPS basically sends signals down to earth and earth sends signals up to the Satellite to determine locations, this as we all have come to know as "PINGS". And obviously the faster the ping, the closer it is. And the closer it is, the faster the lock. The file works the same way. The generic file is using the same servers worldwide no matter were you are and are generic, so the long lock times are cause we are all using the same locations, and as well when a server is overloaded, or as I have seen too many ping requests it has a filter to deny any further requests for "x" period of time, and overloaded systems have a longer response time.
Think of it this way, GPS's send their information to for the most part one location, and it is primarily from what I have read controled by the Navy (at least here in the states), their are 3 tiers to the GPS signal:
1st Tier, Direct; 2nd Tier, Stratum 1; 3rd Tier, Stratum 2, All time servers. There is one more category that GPS's have, and that is they are also ATOMIC CLOCKS which sync with Earth bound Atomic clocks. So why are all the developers using only a generic script, pinging probably 1 sub-par time server expecting that they are going to get any solid results? And using only 1 time server and overloading it? So to get the best possible locks and signal the concept is to utilize every tier, to get the best possible lock. As well there is numerous commands that have been left out of the scrtipt which further enables the GPS to get a faster lock, and going through all the commands from searching the different sites, I compiled different scripts so that i could get the best possible lock.
Big Thanks to SLBENZ for helping out with testing and giving feedback to the scripts I made and helping making the scripts the best possible to work with any region. Also thanks to WarlockW for also testing out the scripts and confirming what I was hoping to hear. Thanks to Pinnacle Another tester not part of these forums, for also testing and giving feedback. Thanks to Carl1961 and WarlockW Carl for making a CWR script for WarlockW and Warlock for allowing me to use the script. Also a Thanks and the jesture to CMYLXGO who also tested the script gave input and has my script in his rom. The Scripts are broken down into 9 Regions and they are as follows:
Africa, Asia, Europe, Oceania, UK, South America, US Mid-East, US Mid-West (Located on post #2), and North America. Local UK Only (Post #2), LOCAL FLORIDA ONLY (Post#2), SuplRootCert (Post #2)
The North America Script should be used by people in Mexico, Puerto Rico, Venezula, Costa Rica, and Canada. The only other person who should use this script is a person who travels to different states for work purposes, and should not be used by someone who doesnt travel often.
Huge Thanks for Carl1961 for fixing the CWR files so they can load as intended. All files have been replaced and can now be installed using CWR.
Install Instructions:
1) Download the ZIP file for your region or close to your region.
2) DO NOT UNZIP the file.
3) Place the file on your SDCARD.
4) DO NOT USE MAGDLR, or CWR to copy the file to your SDCard. Use either your computer, or put Android into Disk Drive mode to avoid corruption.
5) Reboot your phone into CWR.
6) Choose Install ZIP from Sdcard
7) Choose install Zip file
8) Let it run
9) Reboot
10) If you prefer install the GPS Status App attached to post #2
a) If you do, hit the home key then go to settings then Display &Tools.
b) Choose the last one "Show time to GPS fix".
If you have Wifi turned on it will download the AGPS file which will help with the locks but is not needed.
GPS locks will vary, There is no guarantee and I can not give you one, but based on testing, your locks should occur in the following:
First Lock: 30 seconds to possibly 3 mins (3mins if the weather is bad, or there is something going on with the GPS sats, most occur under 80 seconds)
Second and all subsequent locks: 4 seconds to 30 seconds. (Unless GPS is not used for more then 2 days, then refer to First Lock)
Please also post comments of good bad or ugly, Please USE the THANKS BUTTON and use the posts for problems suggestions, or requests.
All of the v1.1 & 1.2 files are CWR files! Since there is 62 countries that have been done, I cant attach them here. So I decided to host all of them on my own personal server. There is no waiting for files. Please if for whatever reason you dont connect just refresh and it will download.
If you dont see your Country, please ask. As I said some countries have no choice but to use the 1.0 versions attached to Post 1 & 2. There are no time servers in every country and some countries (also not in the list) which either are restricted, or have not been maintained.
If the files work for you, and if your feeling generous, or appreciate the hours put into the work so far, feel free to donate. Coffee does wonders to keep me awake.
12.05.11 GPS Scripts v1.2 REGIONAL
All the 1.0 files that are attached to in Post #1 & #2 are now Updated to 1.2 and are located on the FTP in the Regional Folder.
4.24.11 GPS Scripts v1.2 4.25.2011
Argentina, Australia, Austria, Belarus, Belgium, Bosnia and Herzegovina, Bulgaria, Cambodia, Canada, China, Croatia, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hong Kong, Hungary, India, Indonesia, Iran, Ireland, Italy, Japan, Korea, Kyrgyzstan, Latvia, Lithuania (Now Available: 1.1 & 1.2), Luxembourg, Macedonia, Malaysia, Mexico, Moldova, Netherlands, New Caledonia, New Zealand, Norway, Panama, Philippines, Poland, Portugal, Qatar, Republic of Serbia,
Romania, Russia, Singapore, Slovakia, Slovenia, Spain, Sri Lanka, Sweden, Switzerland, Taiwan, Thailand, Turkey, Ukraine, United Kingdom, Uzbekistan, Vietnam, Yugoslavia.
All Countries 1.1 Files Also Located on the site.
4.24.11 USA GPS Scripts v1.2. 4.25.2011
As I promised I have broken down the US into Six Regions:
North East: Michigan to Maine, Illinois to Virginia
South East: Tenn. to Miss, North Carolina to Florida
North Mid States: North Dakota to Wisconsin, Nebraska to Iowa
South Mid States: Colorado to Missouri, Louisiana to New Mexico
North West: Montana to Washington, Wyoming to Oregon
South West: California to Utah & New Mexico
If you look at a USA map how I broke it down will make sense to you.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Thanks Carl1961!
South West, North East, South East, South Mid States, North Mid States, North West, Hawaii Only.
USA 1.1 Files Also located on the site.
XDA Members Click Here
Please do not re-post ftp link. please link to this post. Thank You.
You Tube Video taken by TxRedneck of the script in action:
GPS Script In Action
*** Running Donators List ***
feloccio
tilleke
steve_gr
9646gt
jjrumph
Sharp Rock
inneyeseakay
Tenbeau
boomerod
Thank you for your Donations.
Files Below are 1.0 versions, if you dont see your country in the list above then you need one of the files from below or in post #2.

Mar.29.2011 UPDATE:
If anyone has been keeping track of the Dev forum Post, you will see we are making progress in the GPS/AGPS development. One of the key things that has surfaced thank to MEMIN1857 is the GPSFix.0.1.apk file, which can be downloaded from his post: GPSFIX-0.1.apk. Install this on your phone, and then run it after install, there is no gui, it will download the necessary "xtra.bin" file that is needed by the GPS/AGPS, and after 30 seconds it will say fixed. This is one of the cruiel parts of the GPS that has been missing. Also I found through lots of searching you should add the following lines to the end of your GPS.conf file located in /system/etc. Add the following to the end of the file:
AGPS=/data/xtra.bin
XTRA_SERVER_1=/data/xtra.bin
Also jaba_cz had a line in theory which I will post here which you can add at the end as well, all three lines will not break anything, so its safe to add this line too, I just cant confirm results as of yet:
AGPS=http://xtra1.gpsonextra.net/xtra.bin
Many people are working on this with alot of info I am hoping soon we will get the gps working for everyone in an acceptable manner.
USA & International v1.2 Released!
Todo List: for V1.2
New command codes Adding New Code to Gps.Conf file! *DONE V1.2*
AGPS Aiding *IN PROGRESS* Looking to make Library implimentation THANKS ARNE182!
Faster First Locks *DONE V1.1 & 1.2*
Narrowing GPS searches for countries *DONE V1.1*
Splitting USA into 6 regions for locks *DONE V1.1*
1.2 RELEASE 4/24/2011 Change Log:
Fixed All Banners for all Zip files.
Added More command codes.
Rearranged command sequences.
Added Line by jaba_cz.
1.1 Second Release Change Log:
Added commands for xtra.bin to point to phone.
Added more commands for faster fix.
1.0 Initial Release
ROMS TESTED: (Either by or by Users)
Raidroid HD Sense v1.2 - Desire HD Base
Rafdroid 2.3 & Rafdroid 3.0 & 4.0
Motoman PCB Desire Build v0.1
CMYLXGOs Stock Desire HD v1.0.9n & v1.1.4
Unofficial CM7 Nightlies
GPC_hd2_gingerbread_v1.7
TyphooN CyanogenMod 7 RC2 v2.6 (2.3.3)
Motoman234 Black & Blue Remix V1.0
NexusHD2 Gingerbread v2.3
HyperDroidGBX-v9 2.3.3 with Hyperkernel v 5.0
ROMS FAILED:
imilka's RAM Desire HD (Erratic lock times for two days)
HyperdroidGBX 7.0 (Have not gotten any locks for 10 minutes)
KERNELS TESTED:
GPC226 Kernel
GPC215 Kernel
CM7 Kernel (Nightlies)
Gauner 1.29.11 Kernel
Rafpigna 1.7OC Kernel
TyTungR2 Kernel
MDJ 10.3OC Kernel
Raidroid Kernel
GL Kernel V6
GL Kernel V10
KERNELS FAILED:
NONE
WARNING: THE FILE "SUPLROOTCERT" COULD POSSIBLY INCREASE YOUR LOCK TIMES, IT IS ORIGINALLY PULLED FROM AN AT&T PHONE, IF YOU INSTALLED THIS FILE AND EXPERIENCE LONGER LOCK TIMES PLEASE DELETE THE FILE. YOU CAN DELETE THE LINE ALSO IN THE CONF FILE BUT IT ISNT REQUIRED.
SuplRootCert - CWR: Thanks Carl1961 again!
http://forum.xda-developers.com/showpost.php?p=11364559&postcount=64
For anyone that doesnt have CWR,Thanks to WarlockW here'sa link to do an ADB push from your computer.
http://forum.xda-developers.com/showpost.php?p=11371825&postcount=78

I apologize ahead of time for this post, since this Original Post was copied from its original location due to the fact that this mod seems to increase GPS locks by increasing the amount of Sats, and also shorten lock times, across all Android Devices with GPS. I thought it was owed at least a front view for the people who have not tried or seen this yet.
AngelDeath

Any chance to flash the Europe.zip file without CMR but a custom cyanogen recovery? I tried but it fails....
Thanks in advance

You can open the zip with a file manager and then manually copy the gps.conf file to the system/etc location (make sure you have RW permissions to write the file) and then reboot the phone after copying to the location.
Make a copy of your original file just incase.

Verizon SM-T387V to T-Mobile SM-T387T (carrier cahnges)

Hello all,
I always root my phones and tablets, unlock bootloaders and install custom roms; but only doing with my ex carrier big red vzw; I finally left and switch over t-mobile.
I was able to unbranded my vzw HTC 10 and now it’s fully unlocked. My question now is for my Samsung tablets:
I was reading and learning about Samsung CSC codes on droidnews site; and it says this:
https://www.**********.com/how-to-change-csc-in-samsung-galaxy-phones/
What’s CSC on Samsung?
CSC is the abbreviated form of “Consumer Software Customization” or “Country Specific Code “. CSC is an essential component of Samsung firmware binaries and it contains customized settings, system configurations, localizations and geo-specific things such as the system language, APN settings, and carrier-branding.
That’s is say, Samsung may release the same model of a phone in a country or region with different CSCs. For example, if you live in the United States and own a Samsung Galaxy phone, the CSC or product code of your device may be one of the following depending on the fact whether it is unlocked, open or carrier branded.
Here is my question:
Is it possible to flash the full t-mobile software (all4 files) and change my vzw tablet to t-mobile?
Like it says above “Samsung may release the same model of a phone in a country or region with different CSCs.”
Original Verizon model SM-T387V
Original T-Mobile model SM-T387T
Thanks

CellBroadcast and Emergency Warnings on Android - is it a mess?

Hey,
Germany is implementing EU-Alert (ETSI TS 102 900 [1]) at the moment and referring to the local News, it is a huge mess [2].
But let's start at the beginning.
CellBroadcast is a core component of each mobile network generation (2G,3G,4G,5G,...) and part of the 3GPP spec. CellBroadcast basically allows the network to send a simple SMS to all mobile phones connected to a specific base station. Thes SMS-CB are sent with a Message Identifier (aka Channel, aka Topic) which gives them a special purpose by convention. e.g. ID / Channel 50 is often used for area related information [3], while channel 207 might broadcast local weather information. Since not all Channels are standardized, there is also the option to broadcast an Index that lists all channels with a description. And since users probably don't want any message broadcasted, users have to subscribe to these channels.
Since decades now, CellBroadcast is also used for public Emergency Warnings. This means that, by definition of a country, a specific channel is used to broadcast Emergency Warnings. Long time ago, in many countries it looks like Channel 919 was used for this purpose. For this to work properly, mobile phones were instructed to subscribe to channel 919 by default and also use a special ringtone (even if muted) to alert such a message.
Later - over 12 years ago - additional channels from 4370-4399 were standardized in ETSI TS 123 041 [4] for public warning systems like CMAS, EU-Alert, KPAS. All using the same channels which is beneficial for global roaming.
Android of course supports these public warning systems specified in ETSI TS 123 041 [4] since at least Android 4.2.2 [5]. And nations that use these systems already, like CMAS in the US, report very high and reliable coverage.
However, referring to German news [2] and government, not many phones that are currently on the market will actually support EU-Alert in Germany, despite already supporting EU-Alert in Netherlands or CMAS in the US.
How is this possible when exactly the same SMS-CB is broadcasted, just in a different country?
Golem [2] says that Samsung and Google already confirmed that EU-Alert is currently not supported in Germany, but updates will be rolled out to recent devices.
This strongly suggests to me that OEMs like Samsung and Google actually added country specific filters/configurations for these public warning systems to their phones without deploying a reasonable fallback. Public warning systems based on ETSI TS 123 041 [4] thus may only work in countries that were known to use these systems when the phone was released.
Isn't this an obvious issue?
Google said, starting with Android 11+ it will be possible to update the CellBroadcastReceiver App via Google Play. So devices with Android 11+ will likely receive an update to support EU-Alert in Germany. For Android 10 and older, OEMs will have to supply updates.
What also confuses me is the fact that all Android Phones I own (Nexus 4 with Android 5, Nexus 5X with Android 8, Pixel 3a with Android 12) here in Germany do actually offer the setting for Emergency Warnings and they are already enabled by default. So I assume they would work? Did Google actually deploy a sane default configuration here already?
But if they did - why isn't it working on ALL Android 11+ Phones already? I'm pretty sure my Pixel 3a uses Googles CellBroadcastReceiver App which is provided through the Play Store. So all Android 11+ phones should already use the exact same App?! Or am I wrong here? So what is this update Google actually needs to provide?
And does this also mean that with Android 11+ OEMs are not allowed / cannot implement their own Emergency Warning CellBroadcastReceiver?
This topic is really confusing to me
Shouldn't it be really simple?
All phones, regardless of the OEM, should have a proper SMS-CB Application which allows you to subscribe to custom channels, view the index, and manage your SMS-CB Messages.
Phones should also be aware of special channels to apply special ringtones etc if needed, but they should have a sane fallbacks!
A phone that knows about NL-Alert and CMAS may call messages on Channel 4370 received in the Netherlands "NL-Alert". But when it receives the same message in Germany, it shouldn't just drop it! It should display it as warning and call it whatever it wants. And if it doesn't know about CMAS / EU-Alert, it should just receive it as regular SMS-CB.
Can't be that hard?
Interestingly enough, Samsung phones allow you to subscribe to custom channels. Google phones do not :/
Should there be a better / more enforced standard, so that a country that wants to implement CMAS/EU-Alert in the future doesn't have to rely on OEMs help?
And finally some technical Questions:
I found zero Apps for Android that would allow me to subscribe to custom CellBroadcast Channels on my Google Android phones. Is this even possible?
Also, is it possible to test these CellBroadcasts somehow? Is it possible to write an App that can inject SMS-CB into the system?
Sorry for the long post, but I think this an important Topic.
Let me know what you think
Do you have experience with these Emergency Warnings already?
[1] https://www.etsi.org/deliver/etsi_ts/102900_102999/102900/
[2] https://www.golem.de/news/cell-broadcast-warum-es-am-warntag-ruhig-bleiben-koennte-2206-165822.html
[3] https://source.android.com/devices/architecture/modular-system/cellbroadcast#channel-50
[4] https://www.etsi.org/deliver/etsi_ts/123000_123099/123041/11.04.00_60/ts_123041v110400p.pdf
[5] https://cs.android.com/android/plat...ternal/telephony/gsm/SmsCbConstants.java;l=58

Hey! I was just researching something about this. Thanks for your detailed post.
I am from Chile and, in my case, my operator had subscriptions to two channels: 919 and 920.
In order to see the Cell Broadcast menu in the Messages app, I had to override a CSC setting (I use a Samsung device), particularly "CarrierFeature_Message_DisableMenuCBMessage") because it seems some Chilean operators ordered Samsung to hide it.
Even then, the Google Cell Broadcast app would not let me modify settings other than test alerts.
In my country these emergency alerts are quite unreliable and are often sent by mistake or to the wrong place (i.e. sending a tsunami alert to an area more than 100 km away from the coast).

Shooting Star Max said:
Hey! I was just researching something about this. Thanks for your detailed post.
I am from Chile and, in my case, my operator had subscriptions to two channels: 919 and 920.
In order to see the Cell Broadcast menu in the Messages app, I had to override a CSC setting (I use a Samsung device), particularly "CarrierFeature_Message_DisableMenuCBMessage") because it seems some Chilean operators ordered Samsung to hide it.
Even then, the Google Cell Broadcast app would not let me modify settings other than test alerts.
In my country these emergency alerts are quite unreliable and are often sent by mistake or to the wrong place (i.e. sending a tsunami alert to an area more than 100 km away from the coast).
Click to expand...
Click to collapse
Can you explain how you disabled this CSC setting and on what samsung phone/os?
You can see Googles/Androids latest default configuration for Chile (MCC 730) here:
https://cs.android.com/android/plat...apps/CellBroadcastReceiver/res/values-mcc730/
The config.xml really has some restrictive features enabled :/

Thanks for your reply!
Please note that all the following information assumes you have rooted your device. It's impossible to override this configuration otherwise.
My device is a Galaxy Note20 Ultra (Exynos version, SM‑N985F) running Android 12, One UI 4.1.
As you might know, Samsung devices include several packages named “CSC”, which define settings according to a sales code matching with a region. For example, a device sold in Chile without a carrier uses the sales code CHO, while one sold by operator Movistar uses the sales code CHT.
In the Galaxy Note20 Ultra, the CSC packages are stored in /optics/config/carriers/single (older Samsung devices might use /omc/).
Once you find the sales code matching with your current configuration, you can grab two files: cscfeature.xml and customer_carrier_feature.json. Taking CHO again as an example, the files would be /optics/config/carriers/single/CHO/conf/system/cscfeature.xml and/optics/config/carriers/single/CHO/conf/system/customer_carrier_feature.json.
These files are encoded, but OmcTextDecoder can take care of that.
In the case of CHO, customer_carrier_feature.json has the value "CarrierFeature_Message_DisableMenuCBMessage":"TRUE", which hides the cell broadcast menu in the stock Messages application. Just replace “TRUE” with “FALSE”, save the file and push it to its location. The next time you reboot your system, it will be applied.
Regarding the link you sent, I think we could get around that configuration by decompiling the GoogleCellBroadcastApp.apk through Apktool, modifying the restrictive values, and then pushing the APK to the device, replacing the original version.

Thank you!
Let me know if you managed to patch your original CellBroadcastReceiver.apk!
I actually tried using Runtime Resource Overlays (RROs) which is described on the official docu about CellBroadcast in Android.
You can find the result here: https://github.com/xsrf/android-de-alert
However, I didn't quite get these RROs. It looked like in Oreo you can use RROs to overlay any resource of any app without any permissions or matching signatures, which is quite a surprise to me?!
On my phones with more recent OS, I get signature mismatch errors and also it looks like apps now have to define what resources can be overlayed ...