Check CID via Mozilla Location Service about android-imsi-catcher-detector HOT 53 OPEN

thanks for your info! i was checking the MozStumbler a few days ago. but pls help me - what does "accurancy : 1200.4" mean? 1200.4 meters or feet? if so, maybe they should call it inaccurancy :)
the lat/lon is a constant value from a database... so accurancy is the distance to this BTS, right? No2 would make sense to me. so you are around 1200 meters away from the BTS. and if you check 3 BTS you can calculate your positition with triangulation. So if we use the (lat/lon) data from the GPS (A-GPS) inside our Smartphone and we have the lat/lon of all the BTS from the database, we can calculate the distance between. That could help - at least maybe for a small indication of an IMSI-Catcher. But more important is the plausibility check of cellid and all other info we can get.

from android-imsi-catcher-detector.

Smile, i think range or inacurracy sounds better. :-)
Here the description from the api:

The latitude and longitude are numbers, with seven decimal places of actual precision. The coordinate reference system is WGS 84. The accuracy is an integer measured in meters and defines a circle around the location.

If you are inside the circle with the given accuracy this is the right place where the cellid is "at home".
If you are outside the circle with the given accuracy the cellid is maybe used from an IMSI-Catcher and have not the right lat/lon/accuracy. That works only if the cellid is collected and in the database with enough measurements for calculation the accuracy. A good picture that explains this:

http://winfwiki.wi-fom.de/index.php/Bild:Coo.png
The tower is in the middle of the calculated lat/lon and the mobile phone is inside the circle (accuracy).

That sounds good, Mozilla Location Service wants to release their cellular data so we can use them offline.
M1 (Due: 2014 June 30)
Target: Expansion

Databases:
    Release cellular data 

from android-imsi-catcher-detector.

@He3556 @Gitschubser @SecUpwN @xLaMbChOpSx
Just a Note:
The problem (we have) with OpenCellID (OCI) is that we have no idea how this data was collected, and its reliability. It merely provide a pointer to possible Cells in the area we're in. As I said in another Github post, more likely the OCI data relies on or is a combination of current device GPS locations and less likely using any kind of triangulation of sets of BTS locations, to improve their location. We should contact the developers of OCI to find out what exactly they do.

from android-imsi-catcher-detector.

We should contact the developers of OCI to find out what exactly they do.

I would love to take this part. But since I do not have a working E-Mail address at this moment, would you please takle this, @E3V3A? I'll be talking to developers as soon as I have a new mail provider. Promised!

from android-imsi-catcher-detector.

Here is the wiki from opencellid:
http://wiki.opencellid.org/wiki/Main_Page

Maybe for any question you can find an answer. :-)
Here are apps which use data from opencellid and collect data for the project:
http://wiki.opencellid.org/wiki/Data_sources

I use TowerCollector to collect measurements because i think for me it is the best app. In the API you can find more interesting answers in example about the collected measurements and which data are included there. http://wiki.opencellid.org/wiki/API

Opencellid calculates the middle of latitude/longitude, not the real place from the base station, using all measurements from a unique cellid. I think to check the position of a cellid we should use more than one source because

• the cellid could not exist in the database of the opencellid/Mozilla Location Service
• the measurement is maybe from an IMSI-Catcher :-)
• dont trust only one source, better use two (maybe opencellid and Mozilla Location Service or google geolocation)

Triangulation is only possible when your mobile phone gives you the neighbour cells.
My Samsung Galaxy S3 does not have this option. It only shows the ARFCN from the neighbours cells.

from android-imsi-catcher-detector.

@SecUpwN @Gitschubser So there we have our answer:

In many cases it is difficult to record the exact position of a cell tower because it is not visible, or not accessible. Therefore OpenCellID has chosen the approach to record as many as possible GPS positions where the radio signal of a certain GSM cell tower can be received. Each GPS position consists of a latitude value and a longitude value. The average value of all recorded latitude values is computed and used for the latitude of the cell tower. The average value of all recorded longitude values is computed and used for the longitude of the cell tower. Then the computed latitude and the computed longitude are used for creating the computed GPS position of the cell tower. Due to the way how the data is generated this computed GPS position of a cell tower is not 100% precise. Anyhow in many cases it is pretty ok to be used for GSM cell tracking.

This means that most city tower locations are way off and wrong, since most cell towers are directional, so that you get a "cell tower" centered to where there are most users, such as in shops, cafees and restaurants.

from android-imsi-catcher-detector.

Means, we'd have to collect all data by ourselves, @E3V3A?
Or is there a free service which has data that is 100 % precise?

from android-imsi-catcher-detector.

@SecUpwN That is what this thread is about. If you recall, we have recently discussed this in #13 and other threads (issues). Basically we can use Google (which you hate, but which has the best and easiest API) or that provided by Mozilla. If you can find any other alternatives, that would be just great. We don't need to collect ALL data, we can use OCI to get an idea about the cell neighborhood and then use the above mentioned APIs to get their exact locations, in the region and for the cells we're interested in.

from android-imsi-catcher-detector.

The most city tower locations are not wrong they are not very accurate if there are not much measurements available. The most measurements exists on streets where people drive with car or walk. See map Mozilla Location Service. For triangulation there is used the middle from all measurements and the range (see patent google).

Triangulation with the real position from the base station i think is not possible. If there is only one measurement from the position of the cellid you can not calculate a accurate position from the base station (middle lat/lon, 360 degree radius, exact range). All projects live from the people that help to support with measurements. If you want to use the accurate position you need expensive equipment which measures the run time and calculates the exact position and the direction too.

I think we should use existing projects and look how we can use the existing data for the project or build a own database with the real locations like http://senderliste.de/ or http://gsm.yz.to/.

Data which we can use for free and that exist are the best data at this time. Help to collect data for this projects and the positions would be better and let us use them how it is possible at the moment. ;-)

from android-imsi-catcher-detector.

@Gitschubser Perhaps I misunderstand some of what you say, but just to reiterate, we can not build our own database with all cell towers, because that is an entirely different project, in addition it is useless, since we're only interested in towers in the immediate rural neighborhood (neighboring cells) and the history of those. Also I don't see how the links you provide can help us? Are you related to those sites?

We have to use the simplest tools/APIs available to the best of our abilities, and keep things as simple and on track as possible. We're not going anywhere by expanding this project into unmanageable realms. Also normal triangulation is obviously (since we do not have direction) not possible without additional accurate variables such as one or more of: signal strength, exact current location, TA, TX/RX power.

Also, the average of peoples GPS locations, give you exactly that. The center where people are, which is very different from that of the BTS tower.

from android-imsi-catcher-detector.

Well i like the stuff @Gitschubser is talking about. I think he is talking about supporting Services like OpenCellID with the data we are collecting. Maybe too early to think about that, ok. But I have a CellID App and sent data a few month ago, but now there are no towers in my area :( But something else, maybe we could set options in the menu if people want to use Google, Mozilla or CellID. I think this is better than kicking out all the code if we think we want to use another service.

from android-imsi-catcher-detector.

i just got our App working on my HTC Wildfire :) and i see there are options for different maps - realy cool! and i have a list with neighboring cells. yeah!

from android-imsi-catcher-detector.

Congrats, @He3556! Keep recommending our App to others and test it thoroughly! 👍

from android-imsi-catcher-detector.

@He3556 I'm definitely not throwing out any ideas, I think OCI is great, but that our App cannot rely on that data alone. When we get this app going, we should definitely upload our better and corrected data to OCI's DBs.

from android-imsi-catcher-detector.

I'm sceptical of location as an indicator; carriers move their stuff about,
and with small cells they will do so much more.

from android-imsi-catcher-detector.

@AlexHarrowell You can be as skeptical you want, but unless you can come up with, and present a better and simpler solution, that's how we will do it.

from android-imsi-catcher-detector.

Hi, my name is Markus. I´m the maintainer of opencellid.org. I was asked by E:V:A to join this discussion. Regarding the precision of the cell tower positions the above made statements are correct: we just average the GPS positions of all measurements of a cell and this is not necessarily giving a good estimation of the real position of the cell tower, but the best what we can provide based on the currently existing information.

There is one option which is not obvious: approx. 3% of all known cell towers in the OCID database have a precise position, for ex. most of the towers in Poland. This is the case because we got donations of some data that provided such information. Some of the guys active on senderliste.de also provided us with precise cell tower information, some of them unfortunately refused to do so mainly because the OpenCellID license allows to use the collected data commercially.

As you might know I took over the maintainer-ship of the OpenCellID project approx. 1 year ago after the project was a bit sleepy for a while. The first thing we did was rebuilding the backend which took approx. 1 year full-time development. This was necessary because the amount of data is huge: currently we have 845 million records in our database and approx. 2 million records are added every single day. This initially most important task is done now and the MongoDB cluster is up and running providing the fastest OpenCellID UI that ever existed.

Now the next step is cleaning up the database: It holds some information which is obviously wrong, e.g. a cell with MCC 262 (Germany) in Africa. This will take another 3 months or so because of the huge computation that must be executed and the pretty complex algorithm to be implemented.
At the same time we integrate CDMA and LTE support, which does not exist today.

As soon as this is done, we are ready for the future.
We are still open to discuss which features to implement then, but it seems that

• support of WiFi and iBeacon
• storing neighbouring cells and fingerprints (based on signal strength)
• combining multiple directional sector antenna data into one tower information

are the three most promising things to be implemented for better accuracy in many cases.
But the main problem will remain: It cannot be guaranteed, that each cell was seen from all 4 sides. If someone has a solution for that, I´d love to discuss it with you. Cheers, Markus

from android-imsi-catcher-detector.

@msemm Welcome Markus!
Thanks for an awesome site and service, that is globally appreciated! I'm very happy you found your way over here to clarify things. The OCI DB is a very impressive feat, and I used your App just today to fetch some more towers outside my city. In fact I have had a few questions for some time, so I will just fire off right away.

1. Does your database maintain other (potentially) useful variables, not currently shown or provided. For example Timing Advance (TA) and such things? (You mentioned fingerprints and neighboring cells?)
2. If one can assume that people who provide data, have their GPS on, we should have fairly accurate position info from them. Is there any quality assessment of the GPS positions maintained in the DB as well?
3. Do you keep separate (in the DB tables) peoples GPS positions and the exact tower positions?
4. How about for BTS positions, (For example, you said that you have exact tower positions for Poland.)

Also, I think "guaranteed" is a grave overstatement, in regard to the BTS signal from all 4 directions. I can say for sure that will never happen in an urban area. BTS antennas are highly directional and only the RF engineers are able to tell how they have been multiplexed together, to get their beam profile. But I think you already know this far better than me. So I think the only way to improve the BTS positioning average procedure, is to also use TA and signal strength as a weight, when performing the average. (I.e. a 2D-average embedded in a 3D space :)

from android-imsi-catcher-detector.

Thanks @msemm for joining this discussion. Like @E3V3A asked in no. 2 "Is there any quality assessment of the GPS positions maintained in the DB as well?" This could be provided by a value how many degree around the BTS are scanned by the App user. For example, if the BTS was seen from all 4 sides (N-W-S-E) the value is 360°. But that would be lots of calculation for 2 million new records a day.

But as long as there are enough fingerprint measurements from each Cell (also the distance), a fake BTS would have a totally different fingerprint (location & signal strength). So we should try to collect as many data we can. I wish there was a App for the iPhone to do this.

from android-imsi-catcher-detector.

EDIT: EVA for readability

Answers:

1. All currently stored data is described in the OCI API Wiki. We are currently compiling here potential future enhancements of the database. Feel free to request access to the OpenCellID wiki for participating in the discussion. In this case please send an email to: [email protected]. In regards of the collected data we have to keep in mind what we can get. iPhones and Windows phones for ex. do not allow collecting OpenCellID relevant data at all. Apple and Microsoft try to build their own database. Then there are a few smartphone platforms not really relevant due to their market share (but capable to collect CellID data) and finally there is Android which is by far the most important smartphone platform contributing data to OpenCellID. As far as we know currently TA is not provided by the relevant Android functions. If you have better information, this would be great! Fingerprints: as I said before: This is not existing today but storing fingerprints will be implemented later this year.
2. Yes, we check all incoming data against a set of rules and every day we discard thousands of uploaded measurements because they failed passing all checks. Never-the-less it is possible to add fake data to the database. We are aware of that. At the moment this filter has not yet been applied to all data older than 3 months, but this will happen during this year. At the same time we´ll also further improve the filter. Just to give you one example: We are planning to implement a check which creates a parallel line around each border line of each country world wide with a distance of 32 km (max reach of GSM signal). Then we´ll check every single measurement if it is inside the country with the given MCC (plus 32km in each direction). This was not done in the past so we´ll have to apply this extremely computing power intense check to all 800 million existing measurements. Feel free to compile a list with checks that you think would be relevant for assuring maximum quality of the OpenCellID data. We´ll be more than happy to discuss it with you.
3. yes
4. Unfortunately I don´t understand your question.

Signal strength : This is not as easy as it sounds: Imagine you are in front of a concrete building or behind. Both positions are just e.g. 10m away from each other. But in case the base station is behind the house, then the signal strength in front of the house might be very different from the signal strength behind the house. This is why we believe that fingerprinting is a much better approach than just computing the distance of the handset to the cell tower based on the signal strength, because in this case the big difference in signal strength outlined in the example above is an advantage instead of a disadvantage because it allows to find out if you are in front of the house or behind. The same is true for TA: Due to reflections these values might also deviate from the TA value the direct line of sight would give you. We have implemented such a fingerprinting software for WiFi, then equipped our offices with a WiFi repeater in each corner of the building. Then we recorded the fingerprints and later used these fingerprints to compare them with the actual signal strength of each repeater. This allowed us to achieve a 2-3m accuracy inside our office.

EDIT: E:V:A removed email footer

from android-imsi-catcher-detector.

@He3556 Degree around the BTS: Can be considered. Please discuss this and potential other ideas regarding data quality and come back with a list of ideas. May be we can then even organize a Skype chat for summarizing the next steps (if any). Servers: Don´t worry about that issue, we´ll handle it. Currently we have 6 servers for OpenCellID, each with 128 GB RAM, 4TB SSD, Raid and 2x8 cores, so there is some room for additional computation especially as long as it can be parallelized.

Let´s focus on the quality of the data:

• during the collection process
• during post processing/filtering

Unfortunately I cannot be as active on this mailing list as it might be appropriate due to other obligations: We are currently launching ginstr which feeds my family and pays for the OpenCellID infrastructure as well and therefore has priority. Sorry for that. I´ll try to follow the discussion here as good as I can because I like your project idea!

[ EDIT: E:V:A removed email footer]

from android-imsi-catcher-detector.

@msemm Thanks for quick response. I'll join the Wiki discussions and add my input. But here is my response fo the current discussion.

1. You say "iPhones and Windows phones for ex. do not allow collecting OpenCellID relevant data". What do you mean with allow? Certainly windows mobiles have the capability to collect this radio info just as Android do. (There are Apps doing this as indirectly linked to in #78.) Also Android supports TA since AOS 4.2 - Jelly Bean with (API 17).
2. I'm not sure you answered the question. Let me try to rephrase it. When a person upload a GPS position, there should be a way to also give the accuracy of this data. I.e. (Lat 0.2400000 is probably not the same as Lat 0.2412345, depending how you treat truncated decimals.). How are these differences accounted for? In your wiki you mention a "rating", but no further details are given. Can you expand on this?
3. Ok.
4. Is almost the same question as (3), because from what we're trying to do (with your data), ideally we need to have 3 DB tables with the position information from any given BTS.
   i) The exact Lat/Lon position as given to you by the tower service provider. (Rarely available)
   ii) The calculated GPS position of the BTS as given by some averaging procedure.
   iii) The proximity GPS position of the BTS given by each user. (I.e. same as mobile handset GPS).
5. Regarding signal strength, that is understood. And another way to help this accuracy is by trying to get the TX power used by the handset. We're working on this. Each handset modem also has a thermal sensor in the RF front end, that can be used to estimate TX power...

Thanks again for taking your time.

from android-imsi-catcher-detector.

@He3556 Have you figured out what is that Accuracy yet?
@Gitschubser Can you provide a link to that "Mozilla Location Service" data release? Should we wait for that?

from android-imsi-catcher-detector.

1. For Android: My devs confirmed your information and will implement it in the very next version.
   For Windows phone: Please follow http://wiki.opencellid.org/wiki/Data_sources#Windows_Phone_smartphone_apps and let me know if these two links provide wrong information.
2. We save as many decimal places as the contributor provides. It might be a good idea to implement an additional field with the GPS accuracy the GPS receiver reported.
3. iii : seems I do not really understand this option. Please clarify further.
4. TX power: cool idea! Let me know when you have a working implementation for that. We´ll use it for sure. Unfortunately this value might depend on the handset model (quality of antenna…). Therefore we are planning to store the handset model as well.

It is a pleasure for me contributing to this very friendly and professional discussion.

[EDIT: E:V:A removed email footer]

from android-imsi-catcher-detector.

@msemm First of all, don't trust Stackoverflow answers. But, I also see the dilemma with WP. Technically it is clear that WP also have to provide for full RIL support and everything you would need, but it has been very well hidden from the API in WP7-8. All WP phones are based on the Qualcomm chip-sets:

QSD8650/8250            ==> WP 7        (CE 7.07)
MSM8255T/8655T/APQ8050  ==> WP 7.5      (CE 7.10) 
MSM8260A/8227/8960/T    ==> WP 8        (NT)

I've seen code in that firmware, so it's just a matter of "talking nicely to the modem in the right way". Not that it is going to be easy without an API, but certainly possible. I'm sure they have all this functionality in Service Mode application and elsewhere. The lack of instructions may also have something to do with MS WP App Market certification.

from android-imsi-catcher-detector.

Can you provide a link to that "Mozilla Location Service" data release? Should we wait for that?

Link:
https://wiki.mozilla.org/CloudServices/Location/Roadmap

M1 (Due: 2014 June 30)

Databases:
    Release cellular data 

from android-imsi-catcher-detector.

@Gitschubser Is it related to this MozStumbler?

from android-imsi-catcher-detector.

Yes.

Server:
https://github.com/mozilla/ichnaea

App for android:
https://github.com/mozilla/MozStumbler/

Map:
https://location.services.mozilla.com/map

Statistics for each country:
https://location.services.mozilla.com/stats/countries

API:
https://mozilla-ichnaea.readthedocs.org/en/latest/

Maybe here are people that would help to collect data for this project.

from android-imsi-catcher-detector.

@msemm

1. Is it possible to update your apps Keypad-Mapper 3 and inViu OpenCellid that they collect the value "rating" and "act"?
2. Is it possible to integrate the new value altitude in the measurements?
3. I think it make no sense to do a mix in the database between calculated and real position from the base station. Is this possible to make a own database for the real position, in example from clf-files and add this value to the cell_towers.csv?
4. Is it possible to calculate the bounding box from a cellid (lat, lon, range) similar Mozilla Location Service and add the value in the cell_towers.csv?
   https://github.com/mozilla/ichnaea
5. Is it possible to add the api from Mozilla Location Service and google, so it would be compatible
   and easier to use for another apps and projects.

https://mozilla-ichnaea.readthedocs.org/en/latest/api/index.html

Thanks.

from android-imsi-catcher-detector.

Ref 1 and 2:
which value are you talking about?

Ref 3:
It is NOT a mix. We have both values available.
Currently we export only the better value, but I can imagine to provide 2 columns in the future in the export files, one for the calculated value and one for the real value. http://wiki.opencellid.org/wiki/Menu_map_view#measurements_.3F_CSV_file_format explains how precise values are marked. It is already possible today to upload CLF3 files and indicate the positions in the file to be real positions. This is a hidden feature only avail for the OCID admins for protecting the database. If you have such files, pls send them to me.

Ref 4:
do you mean calculating the GPS coords of the corners of a rectangle that surrounds all measurements of this cell tower or do you mean a circle?

[EDIT: E:V:A removed email footer]

from android-imsi-catcher-detector.

Accuracy is the radius arround the given Cell. If you are inside of this radius you might be connected to this cell. Like @Gitschubser said this sounds interessting for us. But its hard to check it out, if it realy helps under real conditions. Did some body think about this "problem" yet?

from android-imsi-catcher-detector.

@He3556 I did, and it is really complicated, because of what's already mentioned. Which is why we need 3 db tables, for cell and user location data. The question remain, what we will do with them. Certainly we have to come up with a combination of these with other collected data and the history.

from android-imsi-catcher-detector.

yes we need to collect data from each cell from different positions (of the smartphone). If we had 5 - 10 measurements we could calculate something like a fingerprint. It is the same with real fingerprints - where you only need a few points not the whole picture of the finger. Then we would need to update this data because providers are changing antennas and cells and update the hardware. Not easy to do.
There is a "professional" solution for this. i dont want to post the link, but if you copy and past "Automatic BTS localization for 2G and 3G mobile radio networks" you will find it quickly. Maybe interessting to read about it... Anyway, i can put this to the list of functions we would like to have from Open Cell ID :)
Or we could try to implement it localy "on the phone". Most people stay in one or two areas the whole day. So it is not that much data. This would belong to some kind of statistical detection.

from android-imsi-catcher-detector.

@msemm

Ref 1 and 2: which value are you talking about?

I talk about the value "rating" and "act"?
See http://wiki.opencellid.org/wiki/API

rating = GPS quality/accuracy information (metres)
act = Network access type; currently supported: 1xRTT, CDMA, eHRPD, EVDO_0, EVDO_A, EVDO_B, UMTS, HSPA+, HSDPA, HSUPA, HSPA, LTE, iDEN, EDGE, GPRS

Sorry, my failure to Ref 2, I mean the value altitude.

Ref 3: It is NOT a mix. We have both values available. Currently we export only the better value, but I can imagine to provide 2 columns in the future in the export files, one for the calculated value and one for the real value. http://wiki.opencellid.org/wiki/Menu_map_view#measurements_.3F_CSV_file_format explains how precise values are marked. It is already possible today to upload CLF3 files and indicate the positions in the file to be real positions. This is a hidden feature only avail for the OCID admins for protecting the database. If you have such files, pls send them to me.

Ok, you have both but in the cell_towers.csv it is a mix? :-)

See in the wiki
changeable=1: average of longitude values of all related measurements
changeable=0: exact GPS position of the tower

Two columns in the future sounds very good.

Ref 4: do you mean calculating the GPS coords of the corners of a rectangle that surrounds all measurements of this cell tower or do you mean a circle?

I mean a circle (test this: http://www.open-electronics.org/celltrack/) but other better ideas are not false. :-)

from android-imsi-catcher-detector.

@He3556 The only interesting text in that marketing garbage, are the following passages:

Although the receiver's position can be identified using GPS, for BTS localization the distance between the BTS and the receiver is acquired by determining the signal delay. Typical GSM and UMTS signal components from the frame structure are decoded and used to determine when the signals were output by the BTS. Multiple measurement values recorded at various positions allow the BTS to be localized using approximation methods.
...
Depending on the technology selected, i.e. GSM or UMTS, a list of detected base stations is presented in the respective windows. If the approximation algorithm acquires sufficient usable data, the calculated geographic BTS data is immediately entered in the fields displayed by our too expensive application.

Obviously AIMSICD will do much better than that, for free.

from android-imsi-catcher-detector.

This post was moved from issue #87 to here, and have been duplicated in a new issue #88.
It was copied to here for reference. Original by: @andr3jx

@E3V3A @SecUpwN @He3556
I did some digging in GMaps. Here some info:

• I used my Nexus 7 with Android 4.4.4, GApps full updated (yey, my device is 100% approved for spying).
• In location settings I can use Battery saving mode: "Use Wifi and mobile netowrks to determine location"
• When I zoom near enough, I can use the option "Save map to use offline". But this option isn't available everywhere, in Israel for example it displays "Area unavailable". Still it looks like it works for many countries.
• I saved an offline map of my area and went for a short walk. Without Wifi scanning it couldn't determine my position. In advanced Wifi settings I can enable "Scanning always available - Let Google scan for networks". Sometimes it locates me, sometimes not and sometimes the location was inaccurate, I need to investigate here further how well it works.

We know that Google has more accurate information about cell towers in comparison to OpenCellID. I did some research on their non-public api. I downloaded Gmaps.apk and decompiled it to smali. There I found a url "http://www.google.com/glm/mmap", which I googled. Here info how to use this api (redundant):

http://www.open-electronics.org/how-to-find-the-location-with-gsm-cells/ (later I realized that it was already posted here).
https://code.google.com/p/birdnest/source/browse/branches/gae/birdnest/glm.py?spec=svn82&r=82
https://gist.github.com/creotiv/3713832
http://www.codeproject.com/Articles/31965/Learn-How-to-Find-GPS-Location-on-Any-SmartPhone-a
https://code.google.com/p/mwop/source/browse/sandbox/server/mwop-server/src/com/mwop/server/cellID/AbstractCellIDProvider.java?r=18
http://cdacians.blogspot.de/2012/08/convert-celllocation-to-real-location.html

So what we can do is simply use their hidden api to check if they have a particular cell in their database and if they do we can get GPS coordinates of the cell + submit it to OpenCellID. We can also get the coordinates of Neighbour-Cells and calculate a more or less precise location based on signal strength of the cells. The question is how reliable is Googles mobile network info? If we have a cell which is not in Google's database, it could be an indicator that it is an IMSI-Catcher.

It would be better if we could download all mobile network info in an area. I'm interested which data is stored in Google's offline maps and if it is possible to access this data somehow. I tried to intercept offline maps data but couldn't bypass SSL encryption (Certificate pinning and other problems). But I found these tools so I'm sure there is a way to bypass SSL or attach a debugger to GMaps.

from android-imsi-catcher-detector.

moved from issue #87

very interesting observations. Not only to save energy - but to get important info about the location of the cell towers. To your question how reliable the google data is:
"Very often cellular network towers have GPS receivers (or a base station nearby) and those receivers are constantly pulling down satellite information and computing the data. This data is then passed on to the cellular phone (when requested) and acts like a cheat since the relevant satellites to your location are already identified and all that GPS computations is handled by 3rd party computers. This is the result of such a system, to you the end user*" (http://m.wpcentral.com/gps-vs-agps-quick-tutorial) Just to show the connection between cell tower and GPS location.

I am still thinking about a way to get the exact lon/lat. of the BTS directly, without scanning the whole area around the BTS. Google Server for assisted GPS (SUPL_HOST=supl.google.com or also Nokia SUPL_HOST=supl.nokia.com) sends data about the satellite positions to the mobile. (So there is no need to receive it from the satellite directly.) But the satellites are seen from the location of the BTS. So we could calculate the lan/lat of the BTS "backwards". There is only one point i am not sure about. They also know the location of the mobile (triangulation) and could correct the lon/lat towards the mobile.

• query Google location server
  http://www.cell2gps.com

UPDATE: no German Telecom cell towers found in the query, so i can't check my local towers

So i would try to check the coordinates from different sources against each other.

• There are official sides for some countries like: http://sitefinder.ofcom.org.uk/search (UK)

UPDATE: didn't find any proved/official geolocations of towers, so i can not check agains the db.

UPDATE: Still nothing found about Tower coordinates when providing Provider Network AGPS.

from android-imsi-catcher-detector.

@Gitschubser I was just checking:
https://mozilla-ichnaea.readthedocs.org/en/latest/
https://mozilla-ichnaea.readthedocs.org/en/latest/api/index.html
https://github.com/mozilla/ichnaea/tree/master/docs

But:

1. I can't find out how to get an API key.
2. I can't find the DB they have supposedly released.
   Any ideas?

from android-imsi-catcher-detector.

@E3V3A Hi, Hanno from Mozilla here, I'm in charge of running the technical side of the Mozilla Location Service (MLS).

1. I've added some new information recently at https://location.services.mozilla.com/api which mentions API keys. Basically send me an email at hschlichting at mozilla.com and I'll get you a key.
2. We are a bit late with releasing the cell database. It's still on our todo list, and I'm hopeful we'll get to it during this month or the next. We'll release the data under a CC-0 license, so you'll be able to use it in whatever way you want.

In general many of the things @msemm said about OCI also apply to MLS. We calculate averages over all reports as the aggregate estimate. This means the position estimate is more likely the center of the covered cell area, and certainly not the position of the tower / antenna.

If you send us multiple cells, and we have data for them, we'll to trilateration over all cells. We also use WiFi, cell, cell location areas and GeoIP to provide a position estimate. So you might get accuracies up to several thousands of kilometers in the worst case, where we only know you are either in China or Russia based on GeoIP data.

If you have specific questions on MLS, feel free to reach out or mention me directly in a github issue.

from android-imsi-catcher-detector.

@hannosch @msemm
What do you think about submitting LAC and CID to Google's Location API or Skyhook API and use the returned GPS coordinates for your database? Users can collect only LAC and CIDs without GPS and the data will be still useful.

from android-imsi-catcher-detector.

@andr3jx That would be against their terms of service. You aren't allowed to use their API and then store the result and use it in your own service or distribute it. These companies rely on keeping their databases private today. Both our projects try to change that and make sure these datasets become a free, public resource.

from android-imsi-catcher-detector.

@andr3jx Please don't violate the terms of these companies. Doing so doesn't help anyone. If you submitted stolen data to one of the open projects, you'd just force us to deal with law suits and waste a lot of our time and potentially money.

I want to get to an open dataset, but we need to do so based on a community effort from the ground up, not by stealing data. Openstreetmap has shown that this works, it just takes a while longer.

from android-imsi-catcher-detector.

@hannosch Don't worry I won't, It was just a thought. I hope Mozilla can build a big community for this task.

from android-imsi-catcher-detector.

@hannosch Thank you so much for getting in contact with us, it is very much appreciated. I'll send you a private email, while we wait for the DB. Then we'll have to figure out which DB to use, if not both OCI and MLS.

from android-imsi-catcher-detector.

OpenCellID (OCID) and Mozilla Location Services (MLS/Ichnaea) will now support sharing of data as well as using the same data formats. mozilla/ichnaea#282 and mozilla/ichnaea#283

from android-imsi-catcher-detector.

A map that shows the cellids from MLS - MLS Cell Network Map: https://carto.rudloff.pro/gsm
Code at GitHub: https://github.com/Rudloff/mls-cell-map

from android-imsi-catcher-detector.

@hannosch and @banjaxbanjo, I would like to fix this Issue to also solve #349. Here is my idea: We already have this button Download Local BTS Data in the Navigation Drawer of our app. When pressing it, our app is contacting the OCID servers to download the OCID DB. Would it be possible to let this button also let download the MLS DB so that our app would perform two checks if the connected CID is a valid one? Please correct me if I'm thinking in the wrong direction here, I just want to get us on track again - I feel like noone is interested in working with us any more. No good feeling. Please help me.

from android-imsi-catcher-detector.

@SecUpwN I won't mind if you add such a feature to your app and download the MLS cell data.

But both the OCID cell data and MLS data are about 170mb each in compressed form. It's probably rather inefficient to let every app user download and parse this data for the apps purposes. You might want to stand up some service that gets the data from both sources, combines it and offers it in a more suitable form, maybe make it possible to only get the data for a certain country or even a limited number of operators (mnc's).

from android-imsi-catcher-detector.

I see little point in doing both since MLS is based on -- or using OCID data. Either one or the other, but not both.

from android-imsi-catcher-detector.

It depends on what you do. If you do an online query using the MLS API, you'll get results from both data sources. But if you download the dataset yourself, then MLS only publishes its own dataset and OCID publishes theirs. Each of them is about 7 million cells these days, last I checked the overlap is only around one million between those.

We do have to keep the datasets separate on the storage level, as they have different license terms attached to them. OCID has historically inherited CC-BY-SA 3.0 for their project, whereas MLS has started out under public domain (CC-0).

from android-imsi-catcher-detector.

Thanks for clarifying @hannosch. I've been following your wetting procedures closely, and would probably trust your data set more, since it is transparent to what you do.

In either case I would like to see a possibility to download your data separately from within our app. For example by using a setting of:

External BTS data source(s): 
( ) OCID only
( ) MLS only
(o) both OCID and MLS

from android-imsi-catcher-detector.

sorry we have to close a few issues - i this still needs clarification pls let me know.

from android-imsi-catcher-detector.

This is an enhancement.
Please add a "enhancement" tag and "sometimes later" milestone

from android-imsi-catcher-detector.