... and we need a GSM firewall ... and a SIM card firewall ... and quite a few other basic command line tools to manipulate a mobile phone from the command line ...
-b, --baudrate baudrate to use for device (default: 38400)
-c, --concatenate ID for concatenated SMS messages
-C, --sca SMS service centre address
-d, --device sets the destination device to connect to
-h, --help prints this message
-I, --init device AT init sequence
-r, --requeststat request SMS status report
-t, --test convert text to GSM alphabet and vice
versa, no SMS message is sent
-v, --version prints version and exits
-X, --xonxoff switch on software handshake
phonenumber recipient's phone number
text optional text of the SMS message
if omitted: read from stdin
I'm curious what you'd consider a GSM or SIM firewall to look like. Typically from the perspective of Linux, a "old and busted" telephony devices will appear as a TTY which a (relatively) privileged process can use as a control channel and/or to set up a PPP interface. On devices supporting "the new hotness", you get a special character device that speaks the MBIM or QMI protocols for a control channel, and an "ethernet" interface for IP traffic.
In both cases, access to the SIM is limited to processes that can speak to the telephony device's control channel, and the data side is firewalled with iptables like any other network interface. To further restrict access to telephony device capabilities you can break out ModemManager or oFono along with Polkit.
Things get a little wonky when you start to talk about voice calls, as there isn't a lot of standardization in how to get the audio channel in/out of linux on telephony devices yet, but ofono and telepathy seem to have made strides in that direction.
Oh, I do agree. The problem is - who's going to write it? I'm an one-man army so far, this is going to change once people get their hardware from the first batch I'm finishing now, but for now the project still needs contributors.
It's great to see projects like this as they provide an excellent starting point for neat hardware add-ons, such as long-range radios using unlicensed bands (as in https://wiki.soprani.ca/ThePlan#Long-range_radios for example).
I'm hoping that efforts like https://soprani.ca/ work out - it would be great to not have to use the cellular network for simple communication with people that are only a few kilometres away from you.
Yep, that's one of the side effects - you can plug some 2.4G transceivers (like NRF24L01, using an adapter) in the expansion port to talk to 2.4GHz stuff, or use some TI sub-GHz chips for 433/900/868. Also, I'm wondering about POGSAC (the networking standard that pagers use) - somebody on Hackaday suggested it to me, and soon, when I'll have some free time, I'll get some POGSAC receivers and will make a test environment (as in, imitate a POGSAC basestation for testing).
Awesome! I'm really curious to hear how that goes. Is it best to follow https://crimier.wordpress.com/ for such things and/or do you tend to post about your projects elsewhere?
I generally post all things ZeroPhone on Hackaday.io - https://hackaday.io/project/19035 - the blog is just for short random notes that might be useful to someone.
The 2G GSM modem seems like a non-starter for those in the U.S. since AT&T (and apparently T-Mobile too, at least locally) has disabled such technology on their towers. I'm a bit surprised a 3G modem wasn't made standard, with an option to upgrade to LTE (even if it were to cost a tad more).
I'm working on a 3G modem board this week, based on SIM5320 (as suggested in a HackerNews comment, IIRC) - the way I'm designing it, it's pin-compatible with 2G modem I have now, so should be a drop-in replacement. Hope to have the PCBs in a month, and I'm also planning to release a timelapse of me drawing this board (with comments) - for educational value.
Weirdly here in Norway we are taking a different approach. Turning off UMTS but leaving GSM in place. Apparently this is because there are a whole lot of "IoT" installed that use GSM.
Interesting project. No apparent mention of battery life. If funding presents an issue, it could be marketed on darknet markets as a hack-resistant burner phone.
The battery life is still unoptimized - I haven't even played with CPU clock scaling, WiFi is always on and its power management is at default settings, and there are a couple more things I can do that'll improve battery life (like, putting GSM modem in low power mode and adapting my GSM code to work with it). Right now, it lives for about 20 hours from a 4000mAh battery - playing music all the time, WiFi connected to something, with SSH open on my laptop. I just put it on a charger overnight, and like that, its uptime is 6 days now - if I ever forget to charge the batteries, I can just use spares to get through another day =)
Did you ever consider an e-ink display? Are displays even a big power draw from mobile or is it mostly cpu/wifi/GSM?
My ideal phone would be iPhone 5 form factor with an e-ink display running FreeBSD with nothing but calling, SMS, a text based browser, and a terminal. Minimize absolutely everything and jam a 6000maH battery in there.
The display is an OLED, and its power draw is kinda negligible - so the worst offenders are still CPU, WiFi and GSM. I'm going to add an E-Ink display someday - mostly for experimentation, as hardware upgrades like this will require somebody developing and maintaining the softwaree, but it could very well be a really good addon.
As for "your ideal phone" - something similar might just be my next year's project, though sourcing the parts will be hard, for sure =)
You may want to consider for future development other boards such as the NanoPI Neo Air and other similar H2/3 based boards. Availability aside, some folks at Armbian forums have done experiments with cpu throttling and the results are very promising: H2 and H3 CPU are a lot faster than the BCM in the RPI but can be optimized to draw less power. If you get one of these boards, don't use the images at the manufacturers site but go straight to Armbian where they host highly optimized images for most known boards.
Each time ZeroPhone comes up on HackerNews, I learn something new that helps me go on =) Thank you, will be researching it when I'll be working "alternatives to Pi" topic =)
Burner phones should be cheap and off the shelf.
You can use a custom rom, with an open radio.
If Qualcomm, QXDM/QPST to modify radio rom settings including modifying ESN/MEID/IMEI/Bluetooth Serial, etc.
You pick a off the shelf model that's easy to unlock, and flash.
You customize your own rom, and flash it. You eliminate all possible vectors of "hacks" e.g. oem apps and downloaded APK'.
Then the telecom service itself is where it'd e most vulnerable, in fingerprinting your geophysical location and such.
You can modify the GPS, to throw it off, sure. That's already done with rooted devices and you can eve thrown in a few mile obscurity, but, the tower location will ultimately pinpoint you through triangulation.
You're mostly right on your assessment - I don't intend it to be a good burner phone. There's the possibility to swap in GSM modems (thus changing IMEI) - except that the "manufacturer" part in IMEI is going to stay the same, or very similar, so it'd be like that story about a guy who sent in a bomb threat on his college campus through Tor, and it turned out he was the only one using Tor on the campus. IMO characteristics for a good burner phone are just like you're describing, and best practice is to throw those out or destroy them, after all.
And keep in mind that there's also the fact that you have to buy the phones somewhere - that can be tracked, whether it's a package from eBay with 10 similar phones or just a guy buying the cheapest prepaid phones in a supermarket.
Does this phone have a IMEI number? In my country, it is not possible to use a phone without a valid IMEI, let alone the fact that that it is illegal. How does the process of assigning IMEI work?
More fun but definitely not reliable. Twilio interconnects directly with carriers and handles most of the gory details to make sure your texts reach their destination unmolested.
Sending directly from a SIM can have undesired side effects, deliverability issues, mangled text, etc.. and the carrier probably won't be too happy with you "abusing" their service (you'd be surprised how fussy they can be about 160 bytes of data).
The baseband OS is separate from the Linux running on the Raspberry Pi, the modem can be put in hardware RESET state - so, there's unlikely to be a way to execute malicious code on the Linux side by using a modem exploit, if that's what you're interested in =) And yes, the OS has access to GPIOs that control the GSM modem, so that's entirely possible.
Well, I was thinking more that I would want to set up the phone so that the baseband OS is only operational at the time I decide I want to make a phone call. Would something like that be possible and practical?
There's a GSM hardware switch - https://hackaday.io/project/19035/log/60071 - so this is the way to go then, simple as that =) So far, the software is going to assume that the modem is on at all times - however, I'll solve that in the next PCB revision.
I don't think that any commercially available GSM modems actually have open-source GSM implementations - SIM5320 isn't an exception, sadly =( So, compared to AOSP, the main difference is that this project is open hardware (excluding the Pi Zero, mainly).
You can use a spare Bluetooth keyboard (or even a USB one), and I hope to produce a QWERTY keyboard attachment for ZeroPhone this year. In general, this is going to be one of the most important addons I'll be working on this year - both in hardware and in software.
My estimates show about 5 hours for the assembly time, so unless you get paid $1000/hour, this is not going to cost that much =) As for the time invested in software and hardware development - yep, it takes time, like any project is going to.
Answering to your "GSM not open" comment - yes, the GSM baseband itself is not open-source, and I won't be able to change that alone - I have neither skills nor time. My plan is to make all the other parts of the phone open-source, so that when an open-source baseband appears, there's a platform to attach it to.
It's a mighty goal and you're probably more than capable developer but even bigger organizations have failed to produce working phone sw stacks while leveraging open source components.
Therefore while it's a great tinkering project I'm really sceptical about the actual value this could have for "end users" unless the value is the tinkering itself ;-)
+1 for this. A GSM/3G/LTE stack isn't something you can write in an afternoon. I'm on such a project for my company for several months now and I'm probably still a year away from just being able to push a single IP packet through it.
That's why I won't be doing it myself - I'm just going to provide the platform, there are already people working on an open-source baseband, and they're much smarter than me =)
We should be able to do things like:
... and we need a GSM firewall ... and a SIM card firewall ... and quite a few other basic command line tools to manipulate a mobile phone from the command line ...