Changing LAC on same CID
He3556 opened this issue · 44 comments
The LAC (Location Area Code) describes a set of Cell Towers (with different IDs) like below:
Step 1 of the IMSI-Catcher (picture 1): Masquerade like a real BTS and send with more power than the original, so a cell phone would connect to it. But if the connection is established it is still using the TIMSI (Temporary IMSI).
Step 2 of the IMSI-Catcher (picture 2): One possibility to get the IMSI:
- Change the LAC of the BTS (picture 2), so that the Location Update Procedure is initiated.
If the MSC (Controller of a group of BTS) is also changing with this location update, then the phone would have to send the IMSI. Or if the location update fails it will also send the IMSI.
See Figure 4.1.1.1 [http://www.qtc.jp/3GPP/Specs/23012-520.pdf]
However, the Catcher-Catcher Project gives a yellow or a even a red flag if the LAC is changing, so we really should implement this. It is also quite simple to do, because we have the values LAC and CellID. If the CellID changes the LAC over the time – we can show a yellow flag – if it changes more than once we show a red flag. This happens while the IMSI-Catcher is catching IMSI’s – not when a call is established. So you don’t have to be the victim to detect a fake BTS.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
Thanks for opening this Issue, @He3556. Makes sense to me and is in line with the Status Icons. But should we really be showing Status Red when it changes more than once? Guess Orange for "HIGH" would be better in this case until we can add additional tests to verify that this particular user is being traced. @E3V3A, your opinion? @xLaMbChOpSx, how far away is this "easy" implementation for you?
yes right, we have orange, so let's use this first.
He3556 : Very clean and nice description. Thanks. We probably don't wanna make it "red" immediately (which is why we have that score table) because it could easily change under simple conditions such as:
- You're moving your phone around (don't be when using AIMSICD)
- You're just between two or more cell towers or inside a building where you have one on one side of the house and another on the other side.
- Your phone is connected to a UMTS cell and you just sat down at some place where there is also a GSM cell, and you have set your phone's settings to prefer GSM cells. (or vice versa)
Yes, so here is a good place we can actually use signal strength. Because when connected normally, you will have one, and if for some reason another one pops up with a completely new a better signal, with the same LAC/CID that is rather abnormal. So it's use would be a "relative" signal strength, that suddenly changes in time, but not place.
Wouldn't it (signal strength) belong to the statistic detection? Because you need data of the BTS history, so you can tell if the signal is changing in a abnormal way. A changing LAC you can detect immediately, event if you are in a new area and without data from the CellID db.
And than, if both values change (LAC and Signal Strength) you can be quite sure, that there is something going on.
So let's separate the 2 strategies and maybe open a new Issue "Detection 3: Changing Signal Strength"?
You're absolutely right!
First "rough" detection flow chart of this issue
HUGE THANKS flies out to @xLaMbChOpSx for commiting xLaMbChOpSx@43ae77e
...together with the CellID check we have something like this
@tobykurien, you said that this is implemented. Can you verify that we did a full implementation and that this Issue can be closed as solved? If not, what else has to be done to progress from here?
I have plenty of LAC change warnings every day - yellow icon
I would send you logged data for analysis but how to do it? I am on the edge of the range of any BTS because I live in the deep countryside. My GSM signal is almost null, one bar or nothing but when I walk or drive around with my phone I register yellow icon LAC change warning. I would help you but I don't know how to do it. I am not a target but I receive weak signal of some events. You should have OTR encrypted chat client with you.
@menschenfresser, danke für Deine Teilnahme am Projekt! I would very much welcome if you forward your findings to @E3V3A via E-Mail. Please see our README for how to get in touch with him.
As I said, right now the app is not suitable for moving around, since that obviously will connect you to a new LAC. Thus, until we have fixed the DB and CID relations, you'll have to stay put in one place, for reliable detection.
From looking at the code it basically does this:
- Every REFRESH_RATE seconds, get connected cell details
- Do we have cellId in our database?
- If not, add to our DB with it's LAC
- If yes, then is it's LAC the same as current LAC? If not, then show alert of changing LAC
So basically, it checks LAC against previous LAC for the CellId. This means that it should work fine even for moving around.
thanks for clarification :)
yes you are right - movement is no problem in this case. We have cellID in both db - local and openCellID. Next stepp is to check if the cid (local) is in the openCellid db.
Hi, if I understand it right the Police can't order the telecom company to wiretap us without court warrant and without prior evidences against us. Then the Police tries to capture some voice/data in illegal way by serving fake BTS or IMSI-Catcher. Police can also use such illegal hardware to sniff for random phone conversations and make raids at 6AM to illegally eavesdropped people only just because of incriminating conversation. Am I right?
The question is how far the telecom responsible for the network is involved in this illegal procedure?
- Telecom could allow to clone it's BTS and give encryption keys in secrecy. Policeman then drives to the target with almost official but portable BTS with proper encryption settings and he serves this BTS to us but in different location. Then this attack can be discovered only by the comparison of the databases of cell tower coordinates vs their LAC/CID/GPS real coordinates. Am I right?
- Even if the telecom is cooperative and give new, unique BTS data to the Police to create virgin fresh BTS then the database of known cell tower's coordinates immediately discovers new BTS which wasn't there yesterday and is not in the opencellid database. Am I right?
- So if BTS is cloned or created as new we can only discover it by its location and the database because encryption will/may be proper.
- Another attack could be conducted without operator consent. Simple IMSI-Catcher with disabled encryption and the call routed through another network. It will not show up in the billing.
What else?
@menschenfresser, to make it short: Do not "trust" any governmental agencies, the police or whatever to even do what the law "requires" them to do. They just do whatever is necessary to obtain needed data - the invention of IMSI-Catchers themselves is the best proof of that: They invented and used it until the device was publicly known too much and some sort of law had to be "put in place" to make the roaring crowd calm down. But do you think they actually follow "rules"? Forget it. Laws in itself are a joke.
I am thankful you are contributing to our project, but discussing such basic things is beyond the scope and not meant to be done in our Issues here. I've been reading multiple comments from you now and actually do understand why @E3V3A has been removing some of the things you've previously said. Please don't take that personally, but we're working hard to move forward on actually crafting this App, rather than just babble like everyone else does. If you'd really like to help us and show your support, please consider to fork our project and contribute pull requests. You will gain our respect for doing so!
But of course, if you have any questions or would just like to say "hi", please get in touch with me via E-Mail. You are always invited to ask me anything that might be unclear or chat away your boredom. Judging from your username, you are German. The Press Releases may answer your questions.
@E3V3A and @He3556, please clarify: Is this already fully implemented? Our Development Status is listing it in Already accomplished. If true, please tell me if I shall close this Issue or why not. Thanks.
Yes, the part with changing LAC is working, thats what i have checked. But we do have a problem on some phones (Nexus4 and some LG) with false alarm. Also a bad signal can cause this false alarms (@menschenfresser)
What's happening is: there is still the "old" LAC of the previous connected cell (as current LAC).
I can say that from reading the logs of Tor and some sources in the net about this behavior.
I asked Tor to add some waiting period before the LAC is checked. So there is a good chance to solve it soon. Then there is the check of the CellID in the local DB against the OpenCellDB. This is also inside the code already but i need to check if it is working. All this happens in the AdapterDB - what about moving it into another class (after the next release)? like detection.java ??
@He3556 could you add the sleep code and extra logging to the gode and push it? We should get it in for the next release so we can get some better feedback from other users.
We shouldn't put 2 detections in one Issue again. This was "Changing LAC" and "Wrong CID" - now that we are finished with it, i will keep it like it is.
But there is still a bug giving wrong alerts (changing LAC) under special conditions.
(more logcat added in the last release - hope that helps to find the bug)
We have an extra issue for that, so we could close this one here i guess.
We have an extra issue for that, so we could close this one here i guess.
Which one? Please reference the correct Issue and close this if really done.
I would like to give this a shot. What would be a suitable notification? "Cell ID does not exist in OpenCellID Database." ? Or should I use the log string?
Thanks for picking up this one. Yes "Cell ID does not exist in OpenCellID Database" would be great.
thank's to d-mariano - we got this Issue finished :)
We need to think about a solution for the notifications. If there are two detections at the same time, the first one will be overlapped by the second. Maybe we show an array of notifications in a loop?
Just mentioned it - so we don't forget about it.
thank's to d-mariano - we got this Issue finished :)
Thanks to @d-mariano for his funky pull request! @He3556, if this is really solved now, please close.
we can still enhance this but actually we are finished at that point. So i just close it :)
@d-mariano
Something is not right. Did you test it before making PR? Your code is causing the following problems:
- When app start for the first time, it immediately goes to YELLOW detection. Not good, but could be the right behavior, once the DB and BTS pin selection/coloring scheme is implemented.
- That annoying not possible to close/quit bug has returned... Not sure if it is only on my device.
@SecUpwN @He3556 @Ueland Please test!
Also, there seem to be no fallback to green after yellow. We may need a timeout there or what would be the most sensible thing to do?
There is everything ok with the code and i am absolutely sure, that @d-mariano tested it before ;)
I just added a reminder in another issue about the problem.
REMINDER: For the installation & setup wizard (for the first start of the app)
We need to wait until the db is downloaded before we check the CID against the data of OpenCellID. Otherwise we get a wrong alert just right after the installation.
@E3V3A, the new Issue for the immediate yellow flag is #290. And just to tell you: We already discussed it in the Testroom before you mentioned it here. So is this closed now, or how often do we need to re-open this? I am about to lock this. Please tell us exactly what else needs to be fixed. Thank you.
Should we rename this to "...Changing LAC on same CID"?
(Because CID detection is yet different.)
yes thats why i said - in the future we don't throw detections together, in one issue :) if you want pls rename it.
Great! (The problem was that I originally though of them as connected.)
Great! (The problem was that I originally though of them as connected.)
@E3V3A, I can't follow, please clarify. We had multiple Issues in here and this one is solved?
Hey there, I experience the following (as I already emailed you about, @SecUpwN ):
Without any change of location, seemingly random alerts for "Changing LAC" events (like in #439) happen on v0.1.37 on my non-LTE [sic] i9300 with CM 12.1 (without the OCID DBs downloaded due to #691). See the log for one of the events posted here: https://defuse.ca/b/jakoA5RPVujZdQ4JOMGEjr.
I'm not sure whether this may be related to #606 as only the time stamp, CID and LAC are showing values in the database viewer while PSC is shown as invalid, DF_id as 1. Lat, Lon and Accu however are all shown as 0. This is the case with all "Changing LAC" events (although the CID sometimes is different).
I experienced these events once or twice a day, with not having moved my phone for a while in all cases.
NB: Note that after updating on v0.1.38 and downloading the OCID DB, this stopped happening (at least it didn't in the past three days). So it may be due to this DB missing.
@Tonat there was a change in lac as seen your log
01-06 20:00:09.397 10221-10221/com.SecUpwN.AIMSICD I/a﹕ ALERT: Changing LAC on CID: xxxxx3001 LAC(API): abc48 LAC(DBi): abc58
It's possible that both these LAC locations have the same cell id but if there is no LAC abc58 in your area than I would class this as suspicious.
If this LAC suddenly disappears a few hours later that's even more suspicious.
Try open cell id to see if this lac and cid exist for your area or another website that shows lac and cid locations.
If you have this alerts on different CIDs it is the same old problem. Some devices read wrong LAC values from time to time.
Btw. a CID only changes its LAC when the network gets reconfigured - or when a fake BTS tries to trigger a location update, where your IMSI will be send.
But it is only 1 fake BTS (CID) with a changing LAC - thats why we should #628 (comment)