Open He3556 opened 10 years ago
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)
@E3V3A: Rather "Impossible" since I always run AIMSICD while on the move. @He3556 does it, too.
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 https://github.com/xLaMbChOpSx/Android-IMSI-Catcher-Detector/commit/43ae77e2a0cad10dfd50f92da5a998f9ece95b38
...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?
@SecUpwN Please see internal chat discussions. @He3556 Did some testing... In the meantime I'm rewriting the DB structure for easier development and detection implementation.
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:
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?
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.
@SecUpwN We're still working on this, I've updated that Dev Stat page, but dev's should check #230.
@He3556 You did some testing, is it working?
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.
I just posted detailed instructions here in the "App Test Protocol" #173 issue, on how to test changing LAC.
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:
@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.
@He3556 Ok, great, but you put it in #181, which is not the right place, since it has to do with the first time use text. Please open a separate issue.
@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 https://github.com/SecUpwN/Android-IMSI-Catcher-Detector/issues/439) happen on v0.1.37 on my non-LTE [sic] i9300 with CM 12.1 (without the OCID DBs downloaded due to https://github.com/SecUpwN/Android-IMSI-Catcher-Detector/issues/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 https://github.com/SecUpwN/Android-IMSI-Catcher-Detector/issues/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 https://github.com/SecUpwN/Android-IMSI-Catcher-Detector/issues/628#issuecomment-156695686
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:
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.