Detection 3: Changing Signal Strength
E3V3A opened this issue · comments
A rapid change in signal strength when phone is not rapidly moving or "accelerating" and when the currently connected technology (LAC/CID/channel etc) remains the same, would indicate an abnormal and suspicious behavior.
However, a changing signal strength is a very bad indicator all by itself, at least for any phone not laying perfectly still, with people around staying perfectly still, which is a very unlikely scenario. Just waving your hand in front of your phone laying on a table can easily change the received signal strength.
Thus signal signal strength will not be used alone, but in combination with other variables.
Device dependence.
Unfortunately signal strengths is device dependent and thus pretty useless, apart showing your signal bars. In order to make any use of this, a relative signal strength may be more appropriate, where relative changes of several dBm would be more interesting.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
Another idea for this: Celltower report.
If you can get a full celltower report a single highly volatile dbm (while other dbm measurements are stable) would indicate a "mobile" tower.
Thanks for chiming in, @rtreffer. This sounds interesting, how to get a full celltower report?
Any code or projects you can recommend us to be reviewing or people to talk to about this?
@SecUpwN See getNeighboringCellInfo() and getAllCellInfo ().
This won't work on all phones. The result should be the same as a celltower report (strength of all cells around you).
If you poll that data you'll be able to find cells that move differently than most others. If you participate in a demonstration an IMSI-Catcher might have a stable dbm count while all other cells should be more unstable (or move out of sight).
Needs careful sensing of device movement, which may mean lots of GPS polling.
@AlexHarrowell Not really. Detailed tower information is a working substitude for GPS. I've written https://github.com/rtreffer/LocalGSMLocationProvider which does exactly that (although I'll have to write a more battery friendly version). But yeah, the celltower report is a battery hog.
Nice GitHub, @rtreffer - following you now! So you are basically saying that your LocalGSMLocationProvider does exactly provide the query of the full cell tower report? Not wanting to push you or anything, but could you have a look at our codebase, please? Would love to receive your pull request for this, I'm sure @E3V3A can provide some more insights if this approach is useful or not.
@rtreffer Can you post an example output from getNeighboringCellInfo() and getAllCellInfo ()? I doubt this will work an API <19. It doesn't provide any info on my API 17...
Sorry for the noise, it is used by Android-IMSI-Catcher-Detector, at least for the Neighboring Cells fragment. This won't work as implemented though, as the call to getNeighboringCells() may return an empty result (although it works well on my Nexus 4 after some time).
I've created a pull request that calls the getNeighboringCells more aggresively. Note that Samsung devices are known to ignore the call.
The pull request makes it possible to see neighboring cells directly after bootup (after a short lag).
PS: The layout is somehow b0rked on my N4?
This is a first simple draft to start implementing this issue.
- It's important to (statistical) evaluate the results of the measurement also regarding different devices.
- Export raw data to a file to calculate the average deviation and short peak levels with a given standard software.
@He3556, that's an awesome draft! Voting to include it in the General Overview.
At least for me the Tower Collector app work well presenting the Signal Strengths. And according to several sources, the getNeighboringCells() call doesn't work on most Samsung devices. In addition, on those Smasungs it is possible that not all SignalStrength functions work either. There are 5+1 of them:
SignalStrength
CellSignalStrength
CellSignalStrengthCdma
CellSignalStrengthGsm
CellSignalStrengthLte
CellSignalStrengthWcdma (API 18)
@He3556 , I'm confused.... I guess since Signal Strength changes a lot because of many variables, @E3V3A wants to get Signal Strength with other elements.. And I guess you made a draft to solve this question.. Ultimately it seems that we need to get Detection Table from the draft. But I have a question... What is the reason for detecting strange signal strength values and getting dbm difference to av. Signal Strength + absolute value on Signal Strength Table and Positive detection Table? And What is the reason for getting average deviation?? Could you explain a little bit? Thank you.
Hi @jh2910, and welcome to our discussion. The answer to your question is: "Why Shouldn't we?" I would be quite worried if I was sitting at my local spy hangout with a signal of 5 and suddenly my signal goes to 10 from the "same" BTS. The signal strength detection feature is really a show-stopper for portable IMSI-catchers, as they can do nothing about it, apart trying to measure RSSI at every possible location of an area to be under surveillance, or already be there since some time before. In fact, setting your phone to prefer weaker or average cells, over stronger ones, would be a great advantage for detection.
Thank you for explaining this a little bit better, @E3V3A. I am aiming at putting clarifications like yours about detection methods into our General Overview. In fact, please don't hesitate to edit that file!
In fact, setting your phone to prefer weaker or average cells, over stronger ones, would be a great advantage for detection.
Oh, I would love our App to be able to set the preferred signal strength values! Awesome feature!
What is the current status of this? Is the draft still being considered, is it under implementation or is it "up for grabs" to implement?
@Ueland If there's nothing written here in the last 10+ days its definitely up for grabs!
Aight, i will sit down and code it then do a PR when i got something to show you guys, then i will let you guys check and see if it is as wanted or not. The first thing i have noticed is that we should decide what time period a and b is.
I will use 10 and 30 seconds during development for easier debugging, bit i have no strong options on what it should be afterwards
I have just asked @He3556 (who made the flowchart) to further clarify the purpose of T_A and T_B.
I suspect that T_A was intended to loop the test, but that should be done from the main detection "looper" (whatever its called and wherever that one is?). And that perhaps T_B is some kind of settling time for DB updates to finish or something. (So basically I have no clear idea.)
sorry for my delay. A is the time between the single measurements of signal strength. In this time the array gets filled up (loop at the left side while B is not finished). B is the time when the array is full and calculation (functions in the green box) takes place. I hope i could help you.
And like i wrote under "Development Status" > "prepared working package":
Detection of changing Signal Strength: Besides implementation, this needs lot’s of reasearch and testing, if this is a possible way for detection and how it works on different phones (meassurement of signal strength)
So do you see this as a parallel thread to main detection loop then? Because, if not, it will block all other detections while running? (Perhaps I'm just missing something how these things are usually done in Java.)
We could also implement it inside the loop. Counting the loops (A) before calculation (B) takes place. But then we will have a big rate of measurements. This would be better if we have to detect a short peak in the signal (see the red flash in the diagram) But for the calculation of average values (green box) it is not really necessary. And it will consume more computing power. So a thread for measurements (green box) would be better and the detection (red flash) we could place inside the loop.
What does @Ueland and @tobykurien think about that approach?
The CellTracker has a listener that triggers when signal strength change is detected, my suggestion is to let that class send the new signal to a SignalMonitor class that takes it in, but only stores it for later processing if last received signal strength was >=T_A seconds ago. The same function will also process all saved signal entries when appropriate time T_B has gone by. (The SignalMonitor should also only save signal changes received while the device is not moving, but that will also require a T_C, time without movement before saving signal measurements)
Yep, the movement thing has to be handled correctly. Many measurements are useless when device is moving, so in general we should have a no-movement requirement when doing an accurate scan. For movements we can only hope to collect some of the items on the Detection List (# 230).
yes sounds good. we already check movement when we get the current location. Maybe we can interact with that function?
I have started writing some code for this feature here:
https://github.com/Ueland/Android-IMSI-Catcher-Detector/blob/SignalStrengthMonitor/app/src/main/java/com/SecUpwN/AIMSICD/utils/SignalStrengthMonitor.java
This will let CellTracker send new signals each time they change, but it will decide for it self if it want to use them based on last data recieved and device movement status.
wow, that was quick. And everything is well commented. Can't find anything missing. Now we just need to compare the average value and the current signal strength, so the boolean "isMysterious" can result in "true". Or did i miss anything?
FYI, The AccelerometerMonitor is a movement sensor - I added that specifically to save battery power by not doing GPS requests when the device isn't moving. I am sure it can be repurposed here.
@He3556 Correct, it is just pretty much skeleton code now, not sure how much i can get done with it before the week end though.
@tobykurien Hopefully :) Use the accelerometer if present, fall back to GPS if not.
I have gone a bit off from the original draft after i started coding and looking into it, i will (for now) save the cell signal data in DB then calculate the average strength when needed (then cache it)
I have also noticed that i always get 99DB as the signal strength from the CellTracker, while RF Signal Tracker gives more expected results. Gotta check that out.
Thanks for digging deeper into this and polishing up our code, @Ueland!
Should i push my changes when ready straight into this repository or do you want me to keep it in a pull request for now? :)
The cell signal strength monitor now works for me, and is ready to be pushed into the repo if wanted. Now we only need to figure out how/where/what we are going to use it ;)
@Ueland, please stay with pull requests until @tobykurien has reviewed some more of your commits. I know your code is always awesome, but I'd like to have at least one professional coder have a look at it before merging directly. Once @E3V3A and @tobykurien allow you to always push directly, you are very welcome to do so. Please make sure you describe pull requests and merges thoroughly and add good code comments (I know you do). After you've pushed your latest changes I will bump the version and make a plan on which Issues to fix next. I cannot thank you enough for keeping such fast pace. 👍
Aight, no problem :)
@Ueland thank's a lot!
I know you are also a professional coder but it is good when somebody else take a look.
Is there any output to the log?
As the LAC detetection is happening in the AIMSICDDBAdapter.java - maybe we can put all the detections in a extra class?
Let me know what you think about it @Ueland and @tobykurien ?
Agreed :)
And yes, loads of log data tagged with SignalStrengthMonitor, both informal and debugging levels.
Yes, we have to first check how it logs the signal strength, then we have to give it a score to add to the final detection status.
I just want to add some new OCID info from here.
GSM RSSI in dBm in the range of [-51 to -113] or ASU in the range of [0 to 31]
UMTS RSCP in dBm in the range of [-25 to -121] or ASU in the range of [-5 to 91]
LTE RSRP in dBm in the range of [-45 to -137] or ASU in the range of [0 to 95]
CDMA RSSI in dBm in the range of [-75 to -100] or ASU in the range of [1 to 16]
RSSI = Received Signal Strength Indication
RSCP = Received Signal Code Power
RSRP = Reference Signal Recieved Power
RSRQ = Reference Signal Received Quality (N x RSRP / RSSI)
[1] http://en.wikipedia.org/wiki/Received_signal_strength_indication
[2] http://en.wikipedia.org/wiki/Received_signal_code_power
[3] http://www.sharetechnote.com/html/Handbook_LTE_RSRP.html
[4] http://s4gru.com/index.php?/blog/1/entry-308-rssi-vs-rsrp-a-brief-lte-signal-strength-primer/
[5] http://www.laroccasolutions.com/training/78-rsrp-and-rsrq-measurement-in-lte
But I don't suggest to do anything about this, right now. Just keep in mind that this SS business is not so trivial when considering different RAT, especially if phone get downgraded from 3/4G to 2G, or connects to a different BTS. So if we compare SS values, we have to compare them for the same RAT, which make the use of the EventLog and DBi_measure::rx_level tables crucial.
@E3V3A from the previous comment is this Implemented ? How do we get RSCP ? I think getting RSCP is more precise ans RSSI for the signal strength will also consider noise in the path.
3GPP TS 27.007 REL10 Section 8.69 will surely help in this regards. Can we extend android.telephony.CellSignalStrengthWcdma() based on this ?
Some project in which to immerse myself to measure the intensity of the cellular signal, I was looking for NetMonster that is the ideal in github but it is not available in its repository. Does anyone know of any?