Hacker News new | past | comments | ask | show | jobs | submit login
SeaGlass – Enabling City-Wide IMSI-Catcher Detection (washington.edu)
363 points by risk on June 3, 2017 | hide | past | favorite | 36 comments



You could possibly achieve interesting results with a single handset to keep in your pocket as you go about your day. The Samsung Galaxy S3 is ideal due to the fact that Android apps are written to access low level data from it's baseband which is normally not available to end-user applications.

In fact there is a company that sells re-modded S3's at a decent price for this exact purpose [1].

Save some money and find an old handset and load on free IMSI catcher detection software. [2]

EDIT: It seems SnoopSnitch [3] which is used in the SeaGlass project works on rooted Android phones with that use Qualcomm chipsets.

[1] https://www.wired.com/2014/09/cryptophone-firewall-identifie...

[2] https://cellularprivacy.github.io/Android-IMSI-Catcher-Detec...

[3] https://opensource.srlabs.de/projects/snoopsnitch


"You could possibly achieve interesting results with a single handset to keep in your pocket as you go about your day. The Samsung Galaxy S3 is ideal due to the fact that Android apps are written to access low level data from it's baseband which is normally not available to end-user applications."

I don't understand why this is done with apps on mobile phones. It seems to me that all of the "metrics" that we use to determine an IMSI catcher are easily obtained with an SDR - even a cheap RTL-SDR.

Take a look at the scoring system for snoopsnitch:

https://opensource.srlabs.de/projects/snoopsnitch/wiki/IMSI_...

Almost all of those indicators can be easily seen with an SDR and various tools like kal/kalibrate, airprobe, gr-gsm, and so on ... further, I suspect there are many more deeper indicators (think nmap, but for GSM stations) that would be seen with an SDR that could not be with a mobile phone, although that is just conjecture...


Almost entirely because cell phones are both a radio and a computer platform in one battery powered unit. No additional work, and they are small. And generally they get thrown away alot so there are cheap ones on the market.

But to your point, it would be straight forward to build imsi catcher catchers (ic^2 :-) with an SDR setup and with something like the ADALM-PLUTO[1] it would be reasonably cost effective.

[1] http://www.analog.com/en/design-center/evaluation-hardware-a...


"Almost entirely because cell phones are both a radio and a computer platform in one battery powered unit."

Well, sure - but what I am looking at in the article is a phone connected to a rPi, right ?

snoopsnitch does indeed provide a phone-only solution, which is very nice, but the solution in the article does not.

My own testbed is a gigabyte BRIX with a BladeRF attached, but obviously you could go much smaller with a Pi-sized device and an RTL-SDR dongle ...



because just about everyone has a smart phone now, and a high percentage of them have an old smart phone (esp in this community). Not everyone has a SDR, which can cost as much as a smart phone. Not everyone wants to build and deploy code vs just download an app. Eg why apple is more popular than linux for desktops. (I use linux).


Very early android (I bought 2 G1's the first day they were available) there weren't many apps. One popular app would show you where you were, where the tower you were connected to was, a bunch of related metadata, and a link to the FCC database for the tower. Not sure if that data is still available though.

Seaglass seems like basically the same thing, but they track the metadata across carriers, cities, and of course over time. That way they can track changes in the tower, unusual towers, or unusual signal strengths.


For non-rooted devices, http://wilysis.com/networkcellinfo do some nice apps that show the current cell tower location and can log that with a map. Whilst it won't flag up a fake tower, they will stick out.

There are also apps that alert you to fake cell towers, but they depend upon knowing what the legit ones are so the ones I have played with require you to log the local towers you use as a white list. Otherwise how do you or the app know the difference between a fake and a real tower.

But the aspect that cell towers do not have trusted certificates or any form of proving they are from X,Y or Z carrier is a bit of a problem.

One solution is to use VOIP instead of cellulare voice comm's and a VPN. That way the ability of a fake tower will be reduced in what it can glean from you.


We had a program manager on our team who used this app. She didn't understand that it flags repeaters and boosters which we have in our building and made the claim that we were running an illegal OpenLTE network as part of our security research. It was an uncomfortable situation to say the least. Ultimately I don't think these tools are very useful to end users and am encouraged by the SeaGlass project because they are collecting lots of data and correlating it with professionals analyzing the data.


Oh heard of worse examples of tech in the wrong hands. Friend worked in infosec for an online casino. Got called in late sunday evening with boss shocked that port 25 was open on the firewall (he'd just played with a chintzy port scanner app). Friend explained how email works, next day he was terminated with no recourse. Management with a little knowledge is dangerous.


>One solution is to use VOIP instead of cellulare voice comm's and a VPN. That way the ability of a fake tower will be reduced in what it can glean from you.

That helps with the eavesdropping problem, but doesnt help with the imsi catching part.


I think the app you refer to is 'Antennas', and I ran it on my G1 also. It worked as advertised in North America and I used it for a while in Europe, and it worked there as well. Obviously not part of the FCC database, so there must have been more than one in use. Sadly it's no longer maintained.

https://play.google.com/store/apps/details?id=com.technolatr...


There's also Snoopsnitch from SRLabs (Nohl et al).

Most of these software seems to suffer from the combination of hardware dependencies and device churn/neglect. Neither have received updates in a while.

We really need to gather all these resources together if we want software that works. Ideally, there should also be a simple way to know that it's working.


This can also be done on CDMA via Qualcomm QXDM and qCAT for logging, enabling you to just have a single cell phone, a laptop and some scripting in QXDM to log.

Of course this would mean you have access to unlicensed Qualcomm software, know a bit about interfacing with the radio of CDMA phones and qCAT will correctly parse it to meaningful data.

On the other hand, you can also log numbers being actively dialed and even intercept text messages on the SMS paging channel if you happen to have the correct UM/AN on the phone (ESN/MEID not needed)

But with the eventual shut down of CDMA, this sort of phreaking is long lost and over.


It would be interesting to push this out to the crowd of people interested in privacy. Maybe we could put a setup like this in our own cars, or at least run an app on our phones. It would really harm their surveillance efforts if 1000's of people were contributing to a global map.


Excellent idea, but one step further would be to find some amenable Uber / taxi drivers to drive them around. They'd be likely to get coverage of a fairly broad area for a more continuous period than a private driver


I thought thats what they were already doing?

>Partnering with ride-sharing drivers allowed us to collect millions of measurements across both cities.


Awesome - I actually saw this idea posed on Reddit recently:

">So there are factory methods in each cellphoe where you can get the tower ID and RSSI and other data from the tower... what is needed is an app that actively logs ALL that data with the GPS location of the phone regularly and pushes it to a DB in AWS - and you keep capturing all that data, and you compare geo-loc from al the phones and the towers they see/connect to when within that cells signal domain - the app should be able, after time, to "know" which tower it should be connected to based on GPS as it moves into and out f each cell... you get an alert if the phone connects to the non-predicted cell signature.

Simple."


It would be nice if there was a way for cellphones to reject connection with the anomalous "base towers"


It would also be nice if they could get sued/jailed for the use of stingrays


Are they really running a DC->AC inverter, and then plugging SMPS AC->DC converters into it?


Multiple stable 2.5amp sources for a Pi and other devices is important and not always reliable with many 12v->5v converters or even with (how I would probably do it) with a power bank that acts as a buffer and is charged via 12v.

It's messy but it works, if that bothers you then you should read about how inefficient compilers can be.


compilers are pretty dumb, but it's inching towards perfection every second.


This is a data-acquisition tool made by academics that lives in an environment (hybrid passenger automobile) where some extra weight and some conversion loss is utterly fine.

What matters here is reliability -- the device runs without being attended, and needs to keep working otherwise data gets lost / doesn't get collected. These researchers don't really have the inclination to faff around with designing a DC-DC converter system, they're trying to study IMSI catchers!

Were this to be made an actual polished product or deployed in an environment (like in a UAV) where weight/loss matters, I'm sure that someone could design a DC-DC conversion system that's tolerant of the nasty transients on automobile 12V bus and also supplies all needed voltages, without any needless conversions.


it's not efficient, but who cares? using the bricks that come with your equipment and parts you can get at the hardware store solves problems quickly


A simple DC-DC converter from ebay would do the trick a save you a lot of space and money.


Would that handle the noise and transients in an automotive electrical system?


Especially the transients are a problem. IIRC certified-for-automotive parts have to endure >100V input, which e.g. may happen when the battery connection is flaky and the engine is running, due to the sudden load drop.

What's missing on this setup imho is a) a solid power connection (those 12V sockets are known for being loose because of wildly varying manufactoring tolerance) and b) the lack of a supercap+diode setup to prevent brownouts during engine start.


The vast majority of aftermarket electronics won't survive a load-dump transient. This includes every AC inverter, every USB charger, every laptop PSU, whatever you find at the store.

Most 12v-targeted electronics are good to about 30v transients. The DC-DC converters would likely be no more or less susceptible than the DC-AC inverter used here. Just quieter, smaller, and more efficient.


Are the collected datasets available publicly?


Clone that github repo while you can.


How come there hasn't been a serious hack or heist involving criminals with IMSI catchers?


Wow, this feels like something similar to the mechanism Batman uses to find Joker at the end of the dark knight movie. Instead of Joker, it's IMSI-Catchers.

It would be interesting to see how they validate their findings which should be a challenge I guess.


I think that would be more them packaging their algorithms into a (preferably free) smartphone app, which (optionally) silently collects "anomaly signatures" until it's on a trusted network, where it uploads its findings for analysis. (It's probably dangerous in some places to do anything that might overtly indicate you're onto "them"...)

EDIT: Based on another top-level comment, someone's already running with a similar idea.


Off-topic, but I'm so sick of this website theme. Can you please make more than one sentence fit on the screen?


I really do despise iOS for removing the "zoom" feature from the browsers. Not really sure about Android...

Also, IOS is the name for the switch OS by Cisco,,, amirite?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: