It's called USSD, there's a short list on Wikipedia. A lot of them are carrier dependant, and some carrier models of certain handsets will block some codes.
Not the OP, but I remember these codes from my first phone, a Nokia 5110.
In addition to the already mentioned code of [STAR]3001#12345# there is also [STAR]#06# which will show your IMEI.
There were plenty of others (including spelling out 'WARRANTY' to get the manufacture date of the phone) but I forgot most of them.
Interestingly, on the iPhone, dialling anything of the format [STAR]# ...anything... # will cause the screen to go grey as if a separate app, then after a short delay tell you that your code was invalid.
This is good advice, but I'd like to point out that you could avoid the surveillance revealed in this project by simply using anything other than default SMS.
Would be interesting to deploy an app that can send encrypted/signed SMS. It would likely spike your messaging bill thought, as fitting all that in 140 would be hard, resulting in multiple SMSs going out pr message sent.
It was done before. See Signal's predecessor, Textsecure (before they added Signal protocol, pre-2.7.0).
If I recall it limited encrypted messages to 60 characters before splitting. It was also annoying in that you needed to initiate an OTR handshake to start messaging.
That handshake, or the initial exchange of public keys, is the one thing that seems to stymie general adoption of encryption for personal communication.
Current Signal fortunately doesn't make this apparent to the end user, it's install and go message whomever advertises support.
I'm ditching Pidgin-OTR today actually because of the OTR usability issues needing to handshake on every laptop restart. Will be going over to bitlbee terminating OTR on a server and then accessing my ZNC supporting push through TLS. Much less jarring.
OMEMO would be better than OTR for this, but not much supports it yet.
If only there was some robust, open, mature protocol supported by every device on the planet that supported encrypted sessions using an open, mature form of encryption.
Don't use a phone then. Identifying information is being collected and stored by the carrier for at least a month, which can then be handed to regular law enforcement upon subpoena. Federal level likely doesn't even need due process.
I'm not talking about carriers identifying you, I'm talking about people intercepting your IMEI and phone number and being able to uniquely identify you wherever you go. People have been drone strike'd based on the location of their phones.
Carriers being awful is a separate problem. My annoyance rests with the 2G protocol being awful.
I get that, and carriers are definitely stupid. But preventing people from gaining SS7 access is much easier than fixing a broken protocol in use by many devices. Blocking SS7 access is something carriers can do. Fixing 2G is just not possible, and anyone can break it, right at this very moment, with a tiny bit of hardware.
> Rather than confirming a target’s identity with operatives or informants on the ground, the CIA or the U.S. military then orders a strike based on the activity and location of the mobile phone a person is believed to be using.
You are right. This is very disturbing. I guess they do this a lot in Northern Pakistan / Waziristan area in the tribal lands and mountains? What if the Terrorist read stories like this, and gave their cell phone to mules who then get killed?
My father's family (he grew up in India in Bombay) got split in half during the Partition of India and Pakistan when the Brits left India. No wonder there is so much rage and anti-american sentiment in Pakistan (my Pakistani relatives complaint all the time on Skype)
