IMSI-Catchers cause power drain issue?

[rjh427]

I confess to not following all the discussions here as closely as I should, but this recently came across the cypherpunks list - I thought it was relevant:

"In a previous note on Cypherpunks, I believe I read that exposure to one of these Stingrays causes a cell phone to emit its signal at maximum power, causing a battery drain. This suggests that a simple Stingray-detector could be built, using an old cell-phone, a power-supply with a current-limit-detector connected to an alarm. If the cell phone emits maximum RF-signal, it will use a considerable DC power, which could be set to trigger the DC-current alarm. (Am I correct in thinking that the old cell-phone doesn't even have to be 'active', meaning that it doesn't have to have a contracted service associated with it?)"

So my thought is, either as an augment to what is already being tested for or as an alternate test that may or may not indicate IMSI-Catchers in the area, if power draw suddenly spikes and stays spiked then I for one would want some sort of notification.

If this has already been or is already being addressed, just close this issue and carry on.

[E3V3A]

@rjh427 That is certainly a fairly good check, but it need to be cross correlated to prevent false-positives in case of any active applications and automatic services. But, unfortunately if you're in an area with low coverage your phone will also be on max power. there are simply too many possible scenarios where this could happen.

[rjh427]

Certainly that is true, my thought was that users would consult the app frequently with an eye towards noticing abrupt changes. I would expect the device to consume more power if I'm some distance away from a legitimate cell tower, but if I'm at a known location next to a cell tower and power consumption suddenly spikes for no reason (such as one stingray in a van across the street and a second, handheld stingray being walked down the hallways while someone triangulates the drug dealer in the apartment beside me or the brothel on the floor above, it's something that would be easy to take note of. Perhaps it would be better-suited as a standalone app than as a helper app.

Consider this scenario: you tag frequently visited places, the app notes the lat & long and current power consumption rate(s). Thereafter, if you are within N radius of that tagged location and power consumption spikes w/out warning, it could be indicative of a stingray being turned on or being moved into range.

OTOH, you may not want to record the lat & long of your frequented places in case your device is stolen or hacked. In which case, the app could merely note abrupt changes in power consumption without commensurate change in location. I don't know, there are several ways it could be handled and I have not thought them all through.

[AlexHarrowell]

For an IMSI-Catcher to work, the target device has to prefer it to all the others it can hear. Mobile devices pick cells from the list of those they can hear on the basis of signal strength, and configuration values. For example, a typical carrier SIM will contain among much else a list of allowable networks, and probably also a list of preferred roaming partners. We can think of this as a list of (network, preference) pairs where preference can = 0, i.e. barred.

When the device does a CC_SETUP, it will populate this list and pick the strongest signal out of the allowable networks, provided that another one is not more preferred. The simplest case of this is international roaming; in international roaming, all the networks are available, and as a result, some carriers will deliberately boost the TX power near airports in order to acquire roamers. However, your carrier will often have a "preferred" roaming partner, presumably because they have a business relationship.

In the IMSI-Catcher context, it remains true that you have to be the strongest signal out of the set of available, allowable networks to acquire the target device. Even if you do something funky like interrupting the set-up process, rather than just blasting away with raw power, it is true that the device will pick the strongest of the signals that it can connect to. (If you stop it logging on to network X, it will try the next network in the list sorted by strength * preference).

What am I driving at? Well, I'd be really surprised if power consumption going up was a marker of IMSI-Catcher activity, because cellular devices try to reduce their power consumption and a marker of being close to the tower is that the signal is strong. Also, the timing offset is an estimate of range. An IMSI-Catcher has to be either powerful, or close, so it could well reduce the power draw. If it is deliberately jamming other networks, there might be an initial rise in mobile station TX power as the device responds to worsening SNR, but I'd not rely on that for anything.

[rjh427]

This cuts straight back to the comment from the cpunks list. Does something about the IMSI-Catcher/Stingray cause devices to return a signal at full strength or not? If yes, then sudden spikes or plunges with no change in location or other app usage could constitute one way to detect stingray deployments and withdrawals. I agree that this is not a reliable indicator, but it is still an indicator. If OTOH the answer is no, then the phenomenon does not occur and this thread is a wild goose chase. Either way, what legitimate cell towers do should not be used to test whether our nascent app will detect an IMSI-Catcher or not, we need to detect what IMSI-Catchers do differently. If there is no difference then this is all a fool's errand anyway since things like MAC addresses can be spoofed and what an easy way to defeat a database lookup of known stingray hardware IDs.

[He3556]

you will find some indicators here:
(table at the end of the page)

https://opensource.srlabs.de/projects/mobile-network-assessment-tools/wiki/CatcherCatcher

[SecUpwN]

Thanks for this very useful discussion, @rjh427! Since I have first hand information from trustful sources (please do not reveal your identify, if you read this) that our Project is closely monitored since the very beginning by people of Rohde & Schwarz (who develop IMSI-Catchers) and other secret agencies, I would very much prefer if we could get in touch with a whistleblower who could help us collecting information on how to successfully identify the newest models of IMSI-Catchers and Stingrays. That would be perfect.

I know it sounds crazy, but if anyone of you reading this knows of developers working for mentioned company or other IMSI-Catcher/Stingray producers which I could reach out to by E-Mail or other means, please let me know ASAP. I am still working on setting up our official funding address and must say that I am more than willing to donate money for any valuable information pushing our Project forward. But until then, I'm happy that people like @He3556 are here to contribute stuff as best as possible. Keep it up!

[AlexHarrowell]

On 6/10/14, He3556 notifications@github.com wrote:

you will find some indicators here:
(table at the end of the page)

https://opensource.srlabs.de/projects/mobile-network-assessment-tools/wiki/CatcherCatcher

That is an excellent list, and demonstrates the presence of GSM clue conclusively:-).

---

Reply to this email directly or view it on GitHub:
#70 (comment)

[He3556]

Yes, these guys are top! But it works on Osmocom mobiles only. And we haven't found a way to get the data on an Android device. We would need a developer who is working on the baseband part on the realtime OS. Did you ever see somebody here on Github or somewhere else? I was looking everywhere and asked a lot of people but they prefer to do their own thing I guess.

[E3V3A]

@AlexHarrowell Hi Alex, part of our (temporarily) hidden developer documentation has this list as part of the project. We have many details, but we need people willing to try to implement them. As I have already told @Gitschubser in #73, we also have some of the timers, although missing a few. I'm sure we can do well without those for the time being.

[TPS]

FWIW, #898 contains docs with some Stingray details.