Smashing Bugs for WIP-Release v0.1.25-alpha about android-imsi-catcher-detector HOT 74 CLOSED

@SecUpwN Thanks for taking the time to re-fresh this list. I've been too busy lately looking into these details again. Indeed many of these have not yet been resolved, I checked-off a few, but I have not checked all of them, since these checks require a clean/first install without any data. Please feel free to test yourself.
@xLaMbChOpSx Hope you're enjoying the beginning of the summer. But if we could get some up-to-date feedback from you, that would be really great. Don't worry, we don't expect you to work on this any more than you feel like, but it would be excellent to hear a sign of life from you, even if it is just "I'm too busy right now." Which is perfectly fine too. 👍

from android-imsi-catcher-detector.

@E3V3A and @SecUpwN: Hey guys sorry I have been MIA recently but I have my final two assignments due this week which are the last for this semester followed by exams in June, I will be able to spend more time on this after Wednesday this week.

Unfortunately I am not enjoying the beginning of summer but the beginning of Winter and although it has not started yet it is already getting pretty damn cold!

I will go through this and the other issues to bring them up to date and will try and address the majority of these outstanding bugs with the next release, one thing I was working on and I believe I am close to getting implemented is the AT command injection but it does use the Samsung MultiRil methods which I have extended to use the Strings method. As you know this is Samsung specific so for full compatibility we really need some other method such as terminal execution etc but this might give us the first step in the AT command direction.

from android-imsi-catcher-detector.

@xLaMbChOpSx Excellent! Good to hear and good luck for all your exams. I'll try to not bother you again until we hear from you next time.
@SecUpwN Perhaps you can ask, on the main XDA thread, if people with other (non-Samsung) devices, can try to find if they have AT access to one or more of the /dev/ devices?

from android-imsi-catcher-detector.

Thank you for your short update @xLaMbChOpSx - this relieves the feeling that you got tired of developing or are mad ad someone here. You know, people from the XDA community tend to think people are dead if they don't update a thread for several weeks.. 😄 @E3V3A, yes, indeed I will! As you can see, all is good and everybody here is just having a life. Man, I can't wait to see the full scope of your draft proposal being implemented - we're gonna punch the bad guys so hard! ^^

from android-imsi-catcher-detector.

Ok here we go with the bug smashing, I have ticked some items but will fully explain everything below:
Reported bugs from WIP-Release 0.1.8-alpha, Issue #44

• All radio button now display either the default item or the saved preference, including Map Viewer since the update to a full preference fragment.
• Returning from Map Viewer does not disable tracking, I don't believe it actually disabled tracking but rather did not correctly display the icon states as this version was still using the lower SDK target. This functions as intended and when returning to the main activity the icons correctly represent the tracking states.
• Database helper has been significantly updated to ensure only unique entries are inserted, entries that already exist will be updated with the new information such as changed signal strength etc.
• Signal strength table has been removed so issue with empty csv is no longer a problem

Reported bugs from WIP-Release 0.1.10-alpha, Issue #49

• View angle removed from Map Viewer so default display now does not utilise any form of view angle
• Preference fragment has been implemented for the Map Viewer type selection so this is now persistent.
• OpenCellID data is now stored within a database table instead of being loaded dynamically each time it is downloaded so any data received will be displayed. Further to this checks have been incorporated to ensure only unique CellID records are stored.

Reported bugs from WIP-Release 0.1.11-alpha, Issue #53

• Database helper upgrades have removed the possibility of inserting Cell ID's with the initial value of -1, only once the Cell ID variable has been successfully populated will a record be inserted into the database.

Reported bugs from WIP-Release 0.1.13-alpha, Issue #58

• Disabling of Cell tracking now also automatically disables Location tracking if it is active, disabling Location tracking will NOT disable Cell Tracking.

Reported bugs from WIP-Release 0.1.14-alpha, Issue #62

• Neighbouring cell details refresh whenever the fragment is displayed so when the fragment becomes visible it will invoke a refresh. The refresh button can also be used to force manual refresh.

from android-imsi-catcher-detector.

@xLaMbChOpSx Hello! Excellent, but a few comments/corrections.

In 0.1.13-alpha, Issue #58: This explanation was poorly written by me. (Please have another look the comment therein.) The issue is that collecting cell data without an accompanying accurate GPS location, is useless without further radio variables, and even then still not sure. So the idea behind the issue is that enabling cell tracking, must be accompanied with the requirement of also enabling GPS location tracking, and when I say tracking here, I mean to actually save the GPS data in our DB tables (as is done). However, disabling cell tracking, should not automatically disable GPS functionality/location determination on the device, since the user may run other programs using this feature. That's why I said that the extra "location" icon may be redundant, since if GPS is turned on, it is already present on top/menu bar. Thus the reverse logic of what you wrote above, is correct behavior.

For 0.1.8-alpha, Issue #44: You wrote: "Database helper has been significantly updated to ensure only unique entries are inserted, entries that already exist will be updated with the new information such as changed signal strength etc."

This doesn't seem correct at first thought. Can you clarify what you mean with unique?
Clearly not everything can be unique, since it would defeat the purpose of what these tables are to be used for, namely to look for cell towers with unusual behavior, in time, which means changed location, signal strengths, encryption method, timing advance etc, when measured from the same location. So the preferred way to update the AIMSICD cell tower DB, is to only add records when something other than time has changed.

"...If only time-stamp has changed since last entry, an nothing else, then try to keep only the 1st and the last [consecutive] entries. This gives us a time-span to work with, without filling DB."

This is in fact unusual, and probably only possible for a phone laying on a table, so there need to be some kind of timer of let's say 1-10 minutes that checks and adds a "last seen" DB record, in case nothing else has changed.

I hope this helps clarifying. But I'd be happy to discuss more if necessary.

from android-imsi-catcher-detector.

Ok I will redo the things you mentioned tomorrow I need to get some sleep.

from android-imsi-catcher-detector.

@xLaMbChOpSx, awesome work squashing mentioned bugs! I'm sure all these will have vanished with version 0.1.20-alpha. Hold your head up high, I'm proud of you! 👑 @E3V3A, thanks for clarifying.

from android-imsi-catcher-detector.

@E3V3A Ok I now understand correctly what you mean regarding the Cell/Location tracking basically if cell tracking is enabled then location services must all be enabled so when tracking Cell ID information an accompanying longitude and latitude is recorded.

I will make this update tonight but will also remove the location tracking database and my reasoning behind this is that from the original Raw Phone setup which we began with we had a table for Cell information and a table for location information which captured the same detail yet were enabled through the two different functions. So basically if location was off and cell tracking was enabled the cell table would contain cell id information with 0.0 for the location details, then when location tracking was enabled the location table would contain cell id details and the appropriate location details.

With this change we will have a single table that holds all the current information we capture but it will ensure any entry contains ALL fields (Cell ID, Longitude, Latitude etc).

I will post another comment once this part is finished to discuss the second issue and what I propose for that, I will try and fully implement the timer functions so this can be tied into this section and also what we agree as the minimum value to be used for considering what is a change in location e.g. 10 metres etc so we don't have thousands of entries with insignificant GPS movements etc.

from android-imsi-catcher-detector.

@xLaMbChOpSx Exellent.

Yes, this can be very confusing. The main reason for confusion is probably the difference between the "real" CellTower location, the "perceived" cell tower location and your phone "exact" GPS location. This could also be the reason behind the separate tables in the RawPhone app. So at the end of the day, we should end up with at least 2 (and maybe 3) lat/lon location values, in our DB tables, each set representing:

1. "real/actual" cell tower location [lat/lon]. This is the hard part to get easily, which could involve google or mozilla (or other) data mining.
2. The phone (TE) "exact" GPS location. I.e. where you are in relation to cell tower.
3. "perceived/quorum" cell tower location [lat/lon]. This is likely the data we get from OpenCellID, which I believe is a combination of (1) and (2), and can be very unreliable. This requires further study.

PS. It is also very important to distinguish GPS location and lat/lon location. I admit I have been sloppy and mixing these two terms in other/older posts. GPS is a measured value that can easily get thrown off by geomagnetic storms and government interference etc., while lot/lon is a fixed map coordinate, that doesn't change unless there's tectonic plate movements...

from android-imsi-catcher-detector.

@xLaMbChOpSx I've got an FC due to out of date Google Play servies. (see OP) Are you still using SlimKat?

from android-imsi-catcher-detector.

@xLaMbChOpSx Are you sure you uploaded the right version? It seem to have the same problems as the previous version...including the version number!

from android-imsi-catcher-detector.

@E3V3A, I noticed that, too. Hope @xLaMbChOpSx can somehow update his submitted release..

from android-imsi-catcher-detector.

@E3V3A @SecUpwN Sorry I don't know what happened with the release I have deleted the attached apk then added the current version.

from android-imsi-catcher-detector.

@E3V3A @SecUpwN About the OpenCellID issue added I can provide the following information, basically without some form of location data it is impossible to request anything from the OpenCellID database as the API requests require geo coordinates in our case a bounding coordinate for a specific point.

Current AIMSICD attempts to find any form of cached location before showing the message that location services are required, it attempts to find the cached location through the Location Manager method of getLastKnownLocation which initially tries the GPS_PROVIDER and falls back to the NETWORK_PROVIDER if nothing has been found. If at this point no cached location data has been found then I have no other option then to request the user enables location services so a location can be found.

The Google Play services library which is currently used for the Map Viewer provides an updated fused location service which will provide locations from any of the providers but it faces the same issue if getLastKnownLocation is null then the only option that is available to get a location is through enabling location services.

The telephony manager class provides a method for retrieving a location (lat/lng) from CDMA devices through the CDMACellLocation object BUT from looking at this function in the AOSP source the location component of this is removed if the user has disabled location services which again leads us back to the need at some point for location services to be enabled.

If there is another way to gain a location that I have missed I would be more then happy to implement that solution into the app but at the moment I know no other way then what I have detailed above.

from android-imsi-catcher-detector.

@xLaMbChOpSx ... Aha, I see. So it looks as we're back to Google/Mozilla and LAC/CID positioning again... Oh, no wait, we can also try IP address location. That should work sufficiently, at least when we are not using VPN. Also, I updated OP with problem of app not closing (at all) on my I9100 4.4.2.

from android-imsi-catcher-detector.

Not sure if this is possible, but maybe we can improve positioning to be battery friendly? When running around with GPS turned on, my phone is dead within a few hours, whereas it normaly lasts all day long...

from android-imsi-catcher-detector.

@xLaMbChOpSx @SecUpwN : I don't know what is going on, but some more things are broken in this version. xLaMbChOpSx, Did you actually test this before uploading? [Edit: inappropriate location for humor.]

Bugs from WIP-Release 0.1.18-alpha, (not reported)
On: S4-mini GT-I9195 stock 4.2.2 SELinux Enforcing

EDIT by @SecUpwN: Bugs merged into OP for final review.

Summary: This version is harder to test on this device. Possibly because of the Enforcing mode, which prevent access to many file locations and other operations. More tests needed with SELinux settings in Enforcing versus Permissive modes, including setting full access to (via EFS files) to the ServiceMenu items.

EDIT: 2014-06-15
On: GT-I9100, SlimKat 4.4.2b4

EDIT by @SecUpwN: Bugs merged into OP for final review.

Summary: Most things that was causing crashes for the I9195 above, is working on this device, apart what is mentioned above. Neighboring cells look better and more clear. More testing needed. (I have a very bad battery and no gps-lock near outlet.)

from android-imsi-catcher-detector.

@E3V3A No I never test anything I contribute I just write random shit until the app successfully compiles, you have a very strange way of dealing with people who are contributing to your project especially now that I have had the chance to read the xda thread.

Sorry you feel I have been withholding the AT command access from you but as ALL of my commit messages, release comments and issues comments have stated it currently DOES NOT FUNCTION hence the reason it is disabled, I have attempted to extend the MultiRil implementation to incorporate the OEM_STRINGS method and also investigated how to convert the AT command string into an acceptable OEM_RAW request but have not been successful.

Good luck with your project.

from android-imsi-catcher-detector.

@xLaMbChOpSx i feel with you. But "I just write random shit until the app successfully compiles" sorry, i had to [edited] - smile a little bit - . Good to see you still have sense of humor.

from android-imsi-catcher-detector.

@He3556, even though it sounds funny, this is very serious. We're about to lose our best man here.

Dear @xLaMbChOpSx, on behalf of @E3V3A and all other team members, I would like you to accept my SINCERE APOLOGIES for the lack of communcation that obviously has happened between the two of you. I deeply feel sorry for all this bullshit in between, I really DO NOT want to lose you as developer, as contributor and collaborator. You've been driving this project forward, constantly, always with superb commit messages, polished code (although you never really coded on such a large projects before) and even with that little spare time you had. I am extremely thankful for all the things you've been accomplishing so far, otherwise we'd probably still be discussing theories of this App on XDA.

I'm sure @E3V3A will make also make his point clear here, but let me say this: I have been receiving multiple PMs by him via XDA where he expressed his ongoing worries and emotions on not getting any sign of life through his messages to you. I know that he felt like being left alone, but maybe you just didn't lurk around on XDA too often. Which other (better) way of communicating should we have chosen? People are emotional beings, hence why he slowly thought you might not be with us any more. Clearly a lack of communication, added by emotions and thoughts circulating around the question what's going on.

So please, DO NOT LEAVE US. We've got a bright future ahead of us and I really want to experience it together with you. Please forgive the strong voice @E3V3A has at times, he says from himself to be very emotional at times. We all have to work on something, right? If there's anything we can do to make communication among members and collaboration on coding better in the future, let me know ASAP! I would like to keep my promise and send you the first donation NOW. What's your DarkCoin address?

from android-imsi-catcher-detector.

I installed it today on a HTC Wildfire (custom rom) and everything looks great (ok the neighboring cells just shows the number of found cells) i guess the problems depend on the devices people are using. i just found a place for us where we can communicate (private)

from android-imsi-catcher-detector.

@xLaMbChOpSx

Well I'm very sorry to hear that you feel that way. But I also have to insist that I have tried to contact you on several occasions in the last 2 months. Both via XDA PM and the Email you proivided to me, where you also wrote: "Happy to use email for any discussions."

After that I sent you 5 more emails, the first one on May 2 and the last one just yesterday, none of which you responded to. I have also sent you PMs which you also did not fully responded to. The only PM I've received from you, was on 17 April, AFAICT, where you said you were going to answer other questions the next day.

A similar concern has also been made by @SecUpwN . So regardless of how you like me to verbally respond or express myself, what you say just doesn't add up, when there is no communication at all. And if you're busy or tired, all you'd need to say is, "Guys, I need a break." But say something. Surely clear and effective communication is the the foundation of any team project, and the lack thereof is the main cause of failures in most projects.

And Github is not a good place to have developer discussions. We have both surely written one too many repeated questions and answers there, because of the lack of simple overview, and the inherent poor organization of open/closed comments here.

It is clear that my verbal diplomatic skills are below average, which is also why @SecUpwN is our designated PR person for this project. But that being said, does not mean I do not greatly appreciate what you or other people are doing or have already done, on the contrary. But I show my love in different ways. In this kind of remote project, that means, by providing as much technical support and assistance as I possibly can. But it also means I do not kiss up to people who volunteer to participate, regardless of what they do or where they come from. Everyone is free to come and go as they please. And the reason is very simple: I'm simply the initiator of the project. You are not serving me or anyone in particular, but you are serving the greater good for a great many people. So you just have to do what you feel is right.

But more importantly, it also means that I take a purely technical point of view under my own ethical standards. That is, I'll try to leave emotional opinions and moral issues completely out of the project. As SecUpwN already mentioned, this is perhaps not ideal, as people in general and developers in particular, are very emotional beings. But it is the only way, as I see it, to filter out non-sense discussions and moving forward. It also ensures that I will never use you or step over other people to get my own way. I will give you full credit for all you have done.
(Here I use the English word "you", to refer to anyone, and not "you" in particular.)

Finally, I'm all for working out and solving whatever inter-personal issues or relational problems we may encounter, rather than running away. It's the only way to learn about and improve ourselves.

from android-imsi-catcher-detector.

please let me moderate something. There is no way to leave out emotions when you communicate with people. In situations like this, I always try to get the people to read about the "Four-sides_model" + to understand how hard it is, when you are communication with text messages only!
Please take 10 min. and read this - it will help to improve ourselves...
http://en.wikipedia.org/wiki/Four-sides_model

from android-imsi-catcher-detector.

@He3556 Very nice. I now see that I am communicating more like an obtuse triangle, missing much of the relationship layer, in this modus. Perhaps remote communication induce some light form of Asperger's in its participants?

from android-imsi-catcher-detector.

@xLaMbChOpSx I would like to apologize for being insensitive and also for having made a very inappropriate location and attempt to be "funny" in my latest bug-report (above.) This was certainly out of place.

To confuse the current testing situation even more, the latest version behave very differently on the two devices I have access to. Thinking further about this, it is actually expected, since they really are two very different devices in all aspects. My first report was for the i9195 which I also did not make clear at that time. I have now edited the report accordingly.

from android-imsi-catcher-detector.

@E3V3A, I added the bugs you mentioned for WIP-Release 0.1.18-alpha to the OP and really hope @acidtonic will help us squash as many as possible of these. Thanks for your patience!

@xLaMbChOpSx and @E3V3A, since we're on version 0.1.19-alpha now, shall I raise the Milestone on fixing all the collected Issues here or do you think we'll make it until 0.1.20-alpha?

from android-imsi-catcher-detector.

@E3V3A @SecUpwN @He3556 and everybody else watching

I really wanted to address all of these issues before v0.1.20 so to give myself a day or two more I am going to link to an external version of the app to let me incorporate more bug fixes and the AT Command functions prior to the next official release which is 20 unless of course I go to v0.1.19.1... only joking :)

So if you wanted to check out the new UI and addition of the timer handler you can find the application here at my dev-host

Let me know what you think and tomorrow watch out for the next version with the AT Command Injection using the terminal process documented on xda.

from android-imsi-catcher-detector.

@xLaMbChOpSx @SecUpwN Ooops, I accidentally deleted the v18 bugreport from OP while adding the v19 report. No problem, most bugs was fixed anyway, and fortunately I posted the v18 separately to look at. I'll have a look at your alpha-alpha! :D Also, @Chainfire has updated SuperSU to 2.00. Always good to keep that updated.

from android-imsi-catcher-detector.

@xLaMbChOpSx, don't rush! If you implement something and need more time, just tell us. I've raised the milestone to v0.1.22-alpha and re-added the bugs from 0.1.18-alpha to the OP. Please take your time nuking these - we better have stuff working for good instead of fixing it three times. 👍

from android-imsi-catcher-detector.

EDIT 15:19

@xLaMbChOpSx I just tried (on I9100) your new UI from dev-host link above, and realized something. First off, I think we've confusing each other about the "refresh rate". There are two:

1. For the first page "device info" (which probably should be automatic set to ~5 s.)
2. For the 2nd page "neighboring cells" display. The preference I have been talking about concerns this one. Automatic refresh now works on this one.

About the UI, it is working with the menu on the left, but I really prefer the side slide to clicking on menus. Now that doesn't mean we can't keep it that way, but it could be confusing to user with two menus on navigation bar? But if its possible to also keep the side-slide with your new menu, that would be better. What do you think? I still have to test on the I9195...

EDIT by @SecUpwN: Bugs merged into OP for final review.

from android-imsi-catcher-detector.

@E3V3A yes I wasn't sure if I should have put the refresh on the device fragment as that will always refresh when ever it is displayed I can remove it from there but thought as I was implementing it to throw it into that one as well. I am happy to remove it from there if you like and have that fragment just refresh every time it is opened.

About the UI I had not fully removed the action bar icons as yet but I was going to remove the Map Viewer and Database Viewer entries from there as they are now accessible through the pull-out or touch menu, I was thinking of just leaving the other items although I agree it could cause confusion so these should probably be all moved into the menu and the menu itself sectioned off for clarity.

I can look at making an option if possible to switch between the two different interaction methods so a user could select between the drawer style and swipe style, the fragments themselves have been significantly updated to work with this new layout which I believe results in a much more memory friendly implementation then what we had before.

The "Line Number" should actually be displaying your mobile number which really adds no value as users should really know what that is :) If you are happy for that to be removed I can take that off for the next release.

from android-imsi-catcher-detector.

@xLaMbChOpSx
I actually like the drawer, now that I know how to use it! I had no idea what was happening, because of the black theme I have in my ROM, I could not see the border. I agree with all your points above, including removal of "line number".

Bugs from WIP-Release 0.1.20-alpha, (not reported)

EDIT by @SecUpwN: Bugs merged into OP for final review.

TBA

from android-imsi-catcher-detector.

And here are my two cents on the above points:

• We should stop adding Issues to this Issue to prevent never being able to close this one
• I like the new menu on the left side much more than having to swipe for an hour
• We should have ONE UNIFIED MENU to prevent confusion (I like the one from SD Maid)
• Why remove line number? Might be useful to keep it - especially for people with Multi-SIM phones

I have added the Iatest Issues to the OP, but I strongly propose a freeze for new stuff to be added.

from android-imsi-catcher-detector.

@SecUpwN This thread is good, for having everything in one place. Also, since we're copy pasting old bugs into new reports, I don't wanna have to search for hours to get to find the last bug report. You updated it to 0.1.22, so I'd expect I can add stuff here until then. But I agree we need to freeze this issue soon. Let's do it at 0.1.22. Also, we need to focus on solving problems, not prematurely closing github issues, just because of its name.

We can't satisfy everyone, line number is only useful for a very few, for everyone else, it is showing the wrong information as that field is not always implemented. In addition, that field is in the wrong place anyway, and should go under SIM information and then developer would have to spend more time programing to checking for multiple SIMs etc. Let's remove it!

from android-imsi-catcher-detector.

Ok, if showing the phone number bothers you, we shall remove it.
How about using a menu like SD Maid is using it, @E3V3A?

from android-imsi-catcher-detector.

@SecUpwN Yes, menu will be fixed, dev is on it.

from android-imsi-catcher-detector.

@E3V3A, I reviewed all Bugs in this Issue and merged them into the OP for final resolution.
@xLaMbChOpSx, please review the OP. Do you think you'll be able to nuke all these? 👍

from android-imsi-catcher-detector.

@SecUpwN Please don't edit my posts! I link to these on- and off-line, all the time, for easy access. If you need to correct spelling or tables, that's fine, but just don't remove anything!

from android-imsi-catcher-detector.

@xLaMbChOpSx
Bugs from WIP-Release 0.1.21-alpha, (not reported)

On: GT-I9195:

• Crashes when entering Map Viewer without initial GPS-lock/location
• Need roller/spinner for informing on the status of OCI download
• DB:LocationData has 0x7FFFFFFF values (shown in dec) for CID and LAC
• Cell Inforamtion:NeighboringCells has 0x7FFFFFFF values (shown in dec) for all fields
• Cell Inforamtion:NeighboringCells show no indication of refresh

AT command injector works perfectly!

from android-imsi-catcher-detector.

@E3V3A, thank you for being so honest to tell me what ticks you off. I respect that and will avoid any edits without prior asking in the future. I added your bugs to the OP, but please don't add any more.

from android-imsi-catcher-detector.

@E3V3A Thanks for the new info I was looking at the bug you raised for the CID & LAC displaying incorrectly, I just tracked cell details most of the way to work and had no issues. It is possible I might have already corrected that issue with the other stuff I have pushed it have locally. I will look at these tonight then publish a new release.

from android-imsi-catcher-detector.

@xLaMbChOpSx No, for the I9100 there are no issues for the LAC/SID display. Only for the I9195.

from android-imsi-catcher-detector.

Thanks for working so hard on all the bugs here, everyone! @xLaMbChOpSx, do you think you can clean the list until the upcoming WIP-Release v0.1.22-alpha? Or shall I raise the version again?

from android-imsi-catcher-detector.

@SecUpwN Yep I think we need to bump the milestone to address everything I have a couple of things I can implement that will address some of the longer outstanding issues such as retrieval of location based on CID so that the OpenCellID data can be updated without location services (GPS) enabled and this can also assist with the initial starting location within the Map Viewer.

Also @SecUpwN do you like the revamped drawer style menu now it has had a bit of awesome added to it? :)

@E3V3A Can you let me know if the CID & LAC are now displaying correctly on the i9195 with the latest release.

As always let me know how things go and I will continue to work on the items listed here with the goal being to have them all addressed within the next 1-2 releases so this monster issue could be put to rest.

from android-imsi-catcher-detector.

Huge thanks @xLaMbChOpSx! Bumped to WIP-Release v0.1.25-alpha. I love the new menu!

from android-imsi-catcher-detector.

@xLaMbChOpSx
Bugs from WIP-Release 0.1.23-alpha, (not reported)

On: GT-I9195:

• Device Details: LAC/SID only show 2147483647 (0x7FFFFFFF) values
• AT command injector now only works intermittently (9/10 fails), as opposed from 0.1.21 version, which was close to perfect.
• AT command injector seem to ask only occasionally about SU... (and it seem that those are the times the commands are most likely to work.) Ideally SU should be asked upon Application start and not for every (different) operation.
• AT command injector: Repeatedly hitting "Execute" cause APP crash.
• Settings:Get OpenCellID Data: Fails
• DB:CellData: has 0x7FFFFFFF values (shown in dec) for SignalStrength
• DB:LocationData: has 0x7FFFFFFF values (shown in dec) for CID and LAC
• Cell Information:NeighboringCells: has 0x7FFFFFFF values (shown in dec as 2147483647) for all fields
• Cell Information:NeighboringCells: show no indication of refresh
• Crashes when entering Map Viewer without initial GPS-lock/location (Not tested!)

On: GT-I9100: TBA

Summary:
Sorry I have not had time to test and follow up on this as much as I have wished. Something changed to the worse for AT injector since 0.1.21, but since I never finished testing 0.1.22, I don't know when this happened. I also started writing on a debug shell script to automatically email us relevant debug info. But at this point I'm not sure that is very easy to use. Also email sending from command line seem rather crippled, and seem to require hacks.

from android-imsi-catcher-detector.

@SecUpwN @E3V3A @He3556 @illarionov Hi guys sorry I have been away for so long I have had a little chance to finish off some items from ages ago and will have more time now to catch up on all that I have missed and continue to help moving the project forward.

I have pushed a couple of commits and a pre-release version can be downloaded from my Dev-Host for testing.

I will check back in tomorrow and start trying to address more bugs and seriously look at the detection items you have all posted.

from android-imsi-catcher-detector.

Thanks for letting us know, you don't have to apologize @xLaMbChOpSx - great to have you back! 👍 I am honest: I'd be happy if you could resolve all bugs mentioned in this huge Issue here. THANK YOU!

from android-imsi-catcher-detector.

@SecUpwN No problems I will work on these as much as possible and try and address as many as I can over the next day or two.

The pre-release version I attached should address a couple of the issues which I can detail when I get home, in particular OpenCellID download and upload should now function correctly, the CID/LAC issues of displaying the Integer MAX value should also be corrected along with the neighbouring cell details.

I will go through the entire list and try and get them all sorted so we can close this massive issue once and for all!

from android-imsi-catcher-detector.

I want to say BIG THANK'S to @xLaMbChOpSx ,too!! Really cool that you have time to spend on this project. Please let me know what you think about the implementation of #91 when the time is right for you.

from android-imsi-catcher-detector.

@xLaMbChOpSx Wow wow! Great to hear, and unless SecUpwN has already spilled his guts, we have more good news for you...

from android-imsi-catcher-detector.

I think I already sent @xLaMbChOpSx an E-Mail about my latest accomplishments.

from android-imsi-catcher-detector.

@xLaMbChOpSx
Bugs from WIP-Release 0.1.24-alpha, (not reported)
On: GT-I9195: All issues remain the same as for 0.1.23 with the difference that the AT injector now doesn't work at all...

from android-imsi-catcher-detector.

On: HTC One M7 (rooted AOS 4.4.2)

• Page "Cell Information": 1 neighbouring cell is shown 2 times in the list with LAC = 0 and a CellID i could not find with another App (RF Signal Tracker) i use to check.
• Page "Database Viewer" - "Cell Data": 1 Cell is shown 11 times, the lat/lon and sign. strength has a different values. After 10 mon. there is another Cell in the list.
• Page "Database Viewer" - "Location Data": when i click Load Data nothing happens.
• Page "Get OpenCellID Data": Message - Error receiving data from OpenCellID

Do you need a logcat?

from android-imsi-catcher-detector.

This Issue keeps growing and growing. We need to stop this, now! @xLaMbChOpSx, since you've promised to erase all these within the upcoming week, let me know if you need anything!

from android-imsi-catcher-detector.

Another test version is available at my Dev-Host which should hopefully address the CID/LAC + other invalid display issues.

Uploading & Download methods for OpenCellID have been rewritten and tested ALTHOUGH our API key is not white-listed so is not allowing downloads, I did request a new key as suggested after the previous one was disclosed but it has not been white-listed as yet.

I also reverted two changes to the AT Command Injector to try and return its operation back to the state that was experienced with the v0.1.21 release, if there are still issues I can revert all AT Command changes right back to that version to hopefully restore the previous level of stability.

from android-imsi-catcher-detector.

Newer build is available

from android-imsi-catcher-detector.

Ok, so the problem with not being able to download the OCID data is because we don't have a key. Bad. I don't have time to contact "them" right now. Would it be possible to obtain a personal key that can be used in app? Perhaps a way for each user to get his/her own? By entering somewhere in App?

Yeah, the AT is behaving weird, or not at all. I have no idea what is going on there. Also there are 2 /dev/smd0 devs listed on mine... Also for eveyone's info, I think you'll have to reboot phone if you've used it previously, since the smd0 device access is "blocked" by whatever PID it was using. AT least that's what happens on command line. The way to see it is using: jobs -a.
Or does the app take care of that?

PS. Please also make sure you change the version in the app, just so that we can make sure we're running the right one. Easy to make mistakes...

from android-imsi-catcher-detector.

@E3V3A, if I read that right, @xLaMbChOpSx has already requested a new key with c2dc93b and I'm sure it will be included within the next release. Regarding the AT Command Injector: My ROM seems to lack the binary radio, rather another binary radio_feedback is available. I'm not sure if that's the same binary under a different name - renaming radio_feedback to radio did not cause any Issues. How to validate if it's the same? Finally for the version number: I know that @xLaMbChOpSx keeps changing that as thoroughly as possible, but I propose the following two things for a better overview:

1. Add the version number to the main screen aside "AIMSICD" (it says AIMSICD 0.1.24-alpha then)
2. Change the strings method so that only one place has to be edited to change the current versioning both on the main screen as well as in the About-Section. That should simply things a bit.

from android-imsi-catcher-detector.

@SecUpwN I really have no idea what you're talking about there. You have a binary called "radio" in your /system/bin/ ??

Also, I suggest that for minimal and incremental updates that are produced, that their names are appended with something like:

AIMSICD 0.1.24-alpha_b1
AIMSICD 0.1.24-alpha_b2

etc.

from android-imsi-catcher-detector.

@xLaMbChOpSx You posted several minor test version updates, can you also write one line what issue you tried to address on those (or what change we should expect), so we know what to look for?

• 2014-08-13 http://d-h.st/zHX (?)
• 2014-08-19 http://d-h.st/4jG (CID/LAC display issues)
• 2014-08-19 http://d-h.st/93J (???)

You can edit this post.

from android-imsi-catcher-detector.

@E3V3A, my idea was simply to add the version number to the main screen beneath the word "AIMSICD" as well to make it more easy finding it. By adding some sort of "master string", both the version number of the main screen as well as in the About-Tab should be changeable: Means, only change the "master string" to change the version number across the whole App.

Regarding my issue with radio: Yes, I do not have the binary radio in my ROM, just a binary called radio_feedback. And now I wanted to know how to test if that is actually my "radio".

Regarding the versioning of minor incremental updates: I think it is a good idea to explain what the minimal changes are, but since they are minor updates and no real releases, don't you think that this just places another hurdle in development onto the shoulders of developers? Not sure about this. If you really like the nameing of AIMSICD 0.1.24-alpha_b1 and such, ok - but they can stay on Dev-Host and the link + explanation posted in the relevant Issue, we don't need another branch for that.

from android-imsi-catcher-detector.

Well, alphas imho, is all about minor updates, but without an ongoing discussion with developer about what is being fixed and not, it is impossible to test in any sensible manner. We need more feedback here.

from android-imsi-catcher-detector.

The current internal test release solved one more bug on my device. I am happy to notice that the list is melting! @xLaMbChOpSx and @andr3jx could you please be so nice to digg into the remaining list to fix these?

from android-imsi-catcher-detector.

Proposed some more changes in #112 including rewritten AT Command Injection, notification icon display corrections and correct handling of location services (GPS) settings with Cell Tracking enabled.

AT Command Injection does not work on either of my devices so requires testing but I am hoping these changes at least restore the earlier level of functionality.

A compiled version for testing can be found here

from android-imsi-catcher-detector.

@xLaMbChOpSx Found bugs, AT need fixin', please see #23.

from android-imsi-catcher-detector.

Bugs for WIP-Release 0.1.24-alpha_b6

On: GT-I9195: (See device details here.)

• AT Command Injector: Not working, see previous post.
• Cell Information: force close!
• Crashes when entering Map Viewer without initial GPS-lock/location.
• Change Network Information text of "Primary Scrambling Code" to "PSC".
• Change Settings text of "Cell Information" to "Neighbouring Cells". (If that is the correct intention of this?)
• Database Viewer: In "Cell Data" and "Location Data", non available signal strength is shown as "2147483647" (0x7FFFFFFF)
• Database Viewer: In "Cell Data" and "Location Data", change display names from:
  "CellID" to "CID"
  "Latitude" to "LAT"
  "Longitude" to "LON"
  "Signal Strenths" to "RSSI"
• When the service restarts after FC's, the app starts with "Monitoring Cell Details" turned off. Make sure its ON, if the user had it ON.
• Returning from Map Viewer, stops "Monitoring Cell Details". (At least when OCID is not available.)
• Clarify the difference between: "Device Details" and "Lookup Current Cell Details"

On: GT-I9100:

• Crashes when entering "Map Viewer" without initial GPS-lock/location

from android-imsi-catcher-detector.

@tobykurien, if you have a "free minute" (yeah, I know..), can you see if you can tackle some of the remaining Issues here? I am sure those are interconnected to other separate Issues we've already filed on our GitHub - once solved, we'll have cleared up another huge bunch of junk. Thank you so much!

@E3V3A and @andr3jx, please use the current build of our App to check against all remaining Issues here. I want this to be SOLVED, please don't add any new Issues here, rather open new ones. Thanks!

from android-imsi-catcher-detector.

@SecUpwN
All issues here are outdated, miss understood, fixed or not applicable to the latest development version v0.1.25-alpha-b3. So let's close this issue and get on with the latest bug-list. I know this is a bit out of our reular rules of operation, but since the last alphas has had so many changes, it is more messy trying to track all old issues down and check, rather than just starting to check on latest version from scratch. Which is also why we need to start using a testing protocol as in #173.

from android-imsi-catcher-detector.

See I knew this would happen. We create monster Issues like this, I try to track and reverify everything for every version and and then you just close it because it is too much work and outdated. Have you even tried to check all these bugs again, @E3V3A? Because the way I see it, we will end up double-listing them again. 😠

from android-imsi-catcher-detector.

Yes, I did check them, did you?

from android-imsi-catcher-detector.

Yes, I did check them, did you?

For the majority, yes. But the most Issues you filed here are difficult to check because I cannot see what you did on certain occasions. Should we really let this be closed and check from the ground up?

from android-imsi-catcher-detector.

I did try to check them from ground up, only to discover what I said above. In some cases the issues were not well worded and defined which means that parts of it has been fixed and others not.

from android-imsi-catcher-detector.