In fact there is a company that sells re-modded S3's at a decent price for this exact purpose .
Save some money and find an old handset and load on free IMSI catcher detection software. 
EDIT: It seems SnoopSnitch  which is used in the SeaGlass project works on rooted Android phones with that use Qualcomm chipsets.
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:
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...
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 it would be reasonably cost effective.
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 ...
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.
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.
That helps with the eavesdropping problem, but doesnt help with the imsi catching part.
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.
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.
>Partnering with ride-sharing drivers allowed us to collect millions of measurements across both cities.
">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.
It's messy but it works, if that bothers you then you should read about how inefficient compilers can be.
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.
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.
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.
It would be interesting to see how they validate their findings which should be a challenge I guess.
EDIT: Based on another top-level comment, someone's already running with a similar idea.
Also, IOS is the name for the switch OS by Cisco,,, amirite?