-
Notifications
You must be signed in to change notification settings - Fork 948
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changing LAC with zero location? #606
Comments
@znakeeye Just FYI, you're more likely to get a positive response from the dev team when you follow https://github.com/SecUpwN/Android-IMSI-Catcher-Detector/wiki/Submitting-Issues .… |
Well. I thought I did. Are you saying that this is a known issue? |
@znakeeye I'm referring to
which all seems conspicuously absent from your report.… |
Welcome to our project, @znakeeye! We're sorry to hear you're experiencing this, but I can confirm what you see. I guess that this is likely a bug in the database, which still has glitches. @banjaxbanjo would you please have a look at this? @TPS, thanks for telling everyone to file proper bug reports, but please refrain from that in the future. This is my part and I would like to avoid ticking off our users. ;-) |
TPS is right. The bug report is simply to vague without more info... |
@SecUpwN @znakeeye I'd need a log to tell if this is a bug or not, and if you say that this only happens in a particular zone than maybe when you where monitoring the zone there was an imsic active using the bts cid and if you went back few days later than the original lac and cid would be active and the new lac would cause an alert. The gps coors don't have any affect on lac detection so having lat 0 and lon 0 won't set off false alarm. Simplest thing to do is look at the bts in db viewer and see is there 2 cids with different lacs and if so than its not a false alarm. |
What if there is a CID = -1? |
"is there 2 cids with different lacs and if so than its not a false alarm." You mean two log entries with identical CID and different LAC? |
Yes.
Previously using the app, doesn't prevent changing LAC detection. LAC detection is not fully re-implemented after DB overhaul (AFAIK), since we still need to rework some DB queries. |
@E3V3A from test I done changing lac is working,to test all you have to do is put a demo entry into the db with a know cid and a random lac and when it detects the real cid and lac it will alert. |
@banjaxbanjo Awesome and thanks for testing! |
No, there has to be a bug in the works. I looked through the Unique BTS Data and found at least two entries that could be the reason I'm seeing this (presumably) false alarm: CID: -1 Then... CID: -1 So where does this "-1" come from? |
The Lac with 12345 and cid 54321 is the demo inserted for example but if a cid -1 and lac of 12345 showed up than I find that strange. And also a LAC with 0. Maybe this is an android OS thing because I've logged a cid and lac of 0xffffffff before in a demo app and I notice that for a split second when changing to new bts that these values show . @E3V3A would a phone connect to a bts if the cid was -1? I think I've read somewhere that imsicatchers might use values like 0 before. |
My lac was not 12345. I wrote it to avoid showing the actual lac to the rest of the world :P Cid: -1 |
Ah silly me😁well it appears to be a bug but I don't think the app is the cause I think its android OS giving back these values. I guess we need to filter out -1 when comparing lac. But besides that it looks like the lac detection is working good |
@ga900 from your experience is it possible an imsi catcher can use 0 or -1 for lac or cid and would a phone connect to a imsic if it used those values? |
No it's not possible |
Not sure how to interpret this, but I keep getting "Changing LAC" events with Lon=0.0 Lat=0.0 Accu=0. This happens all the time when I'm visiting an area were I have actively used the app before.
Sure looks like unassigned values, causing an erroneous event?
The text was updated successfully, but these errors were encountered: