Hacker News new | past | comments | ask | show | jobs | submit login
Motorola Moto E modifications for anti-surveillance (torproject.org)
170 points by zmanian on Jan 12, 2015 | hide | past | favorite | 48 comments



A Samsung GTI9300 is a better choice as you can install Replicant on it, and the Intel baseband at least gives you access to radio logs so you can determine GSM encryption and silent SMS attacks https://github.com/darshakframework/darshak

Replicant isn't going to be ported to Motorola E/G or new Nexus devices, too many proprietary binaries.

It would be nice to have a totally free software tablet, and use a USB OTG baseband to priv seg it from the device. When you want to change radio identifier just buy a new internet usb stick.


It seems the Moto E was chosen just because it's a current phone that was cheap to buy.

Anyone think a Project Ara phone could be an option? http://www.projectara.com/

I like the idea of buying one configured as a Wi-Fi phone with no baseband or GPS module and with the right secure communication app could be "secure" enough. Maybe someone could see a market for a "open" baseband module for it and make one?


I found the choice of device rather odd for the use case, since it's still running proprietary baseband code. Open source baseband software like OsmocomBB on a compatible device[1] seems more suitable.

[1]: http://bb.osmocom.org/trac/wiki/Hardware/Phones


Yes, this seems like a very good choise, since the baseband is already owned. I've picked one myself from ebay with the filter rework modification, and I can even run my own BTS!!!


I'm kind of surprised that the phone was still able to function with so many component removed - that's cool.

One thing that stood out under the "TODO" list was "Reprogram the IMEI." - I was under the impression that doing so was illegal? (not that knowing how necessarily is).


Yes, changing IMEI is illegal in certain countries:

http://en.wikipedia.org/wiki/International_Mobile_Station_Eq...

But if I were trying to make an "anti-surveillance" phone, I'd probably look into one of the more anonymous unbranded Chinese devices out there - especially the ones based on MTK chipsets, which have some full schematics available.


Some Chinese phones reportedly have spyware/malware that shares information back with servers in China, which transmits data regardless whether you want to or not, even without a SIM card. It's possible that there are also firmware level backdoors which can't be blocked by rooting the phone or unlocking the bootloader.

[1] http://www.wantchinatimes.com/news-subclass-cnt.aspx?id=2014...


Schematics on such specialized, highly integrated chips with unknown internals are almost useless from a security standpoint.


Yes, very good point.

In fact IMO "highly integrated chips" such as SoCs are usually so complicated that no single individual really knows what's in them. And that's even when a chip is designed totally in house. However, most chips have lots of 3rd party Intellectual Property in them.

If my life depended on it (e.g. being a dissident in Iran or Syria) I wouldn't trust any cellphone.

If pressed, I would probably use a relatively old laptop and run OpenBSD. With no GUI, just a text login. And then I'd still be concerned that there are 10 exploits that TLAs could use against me, that they keep under tight wraps.

It's not paranoia if there really are people out to kill or imprison you. "The man" has so much power nowadays that I'm glad I'm living a sedentary life in a random suburb, and I'm not playing any sort of "You Bet Your Life" game.


It makes sense that the phone would work with components removed. People break phone components all the time, it'd be unreasonable to disable the whole phone if a component stopped working.


I don't belive it is illegal, unless you have stolen a phone. Doing so breaks the stolen phone databases a.k.a. Equipment Identity Registrar.


English law: http://www.legislation.gov.uk/ukpga/2002/31/section/1

You can change the information if you are the manufacturer or you have the written permission of the manufacturer. Owning the phone is not enough.

I don't know what the laws are like for other countries, or if other countries even have such specific laws.


TY for the correction. American here, so I should have stated that my belief is based on my understanding of that marketplace. The legislation in this arena is admittedly more aggressive in Europe.


Quoting Stallman: "Theoretically it is possible to create a free phone, but practically it is not. [...] The phone modem cannot run free software because the specifications are unknown and a certificate of the manufacturer is required to flash the software. [...] Backdoors in the modem make it possible to flash non-free software to the application processor."


Install f-droid and use the phone without a Google account.

One unfortunate complication with this is that using the phone without a Google account means one will likely miss out on security updates. As Google fights android fragementation by moving more functionality into user-upgradeable apps, not having a Google account means one cannot update things like Google Play Services. I imagine there are security fixes which go into those updates.

Of course, one could disable those specific apps. However, in the example I used—Play Services—disabling (or having an old version of) it means TextSecure's push messaging does not work, for example. Going off on a bit of a tangent, I would be interested to see a discussion between Moxie and Jacob about this aspect of things. Is it worth having a Google account if it means you have encrypted push messaging? Is is worth not having a Google account if it means you cannot have encrypted push messaging? (Yes, encrypted sms would still work without the Google account).

In the event someone points out the TextSecure APK is only distributed within Google Play, it is relatively straightforward to build TextSecure from source. So, not having a Google account does not preclude one from using TextSecure. And one can use the push messaging via Play Services without a Google account, provided a compatible version of Play Services is on the phone.


If the number one priority is having a secure phone, why would you want to install the notoriously leaky Google apps? Google uses dark patterns and opt-out all over the place to send tons of data back to HQ.

Once again, if security and privacy are your number one priority, why wouldn't you compile TextSecure yourself, or at least get it from a trusted source?


My point was that it is not a simple trade-off between "privacy and security" and a lack of those things. In order to get software updates for critical components of the phone, you may need to get a google account, sacrificing some of the "privacy" for software "security". Obviously it does not have to be this way, but it is the way Google has mandated it in their ecosystem.

Edit: One can make the case that it's better to use encrypted SMS with TextSecure, rather than using the push messaging. But, from a metadata standpoint, I believe the push messaging might be better. SMS metadata seems to be automatically handed over to the US government, while they would likely need to issue a NSL, warrant, etc. to get that same information from Google. So using the push messaging may side-step some of the metadata collection that is happening.


There's always the ug (micro-g) GAPPs replacements, still waiting for someone to release compiled binaries and a guide so I can try it out for myself.

https://github.com/microg


the thing I never got is why is having the Google account an issue if you never use their apps?


I think because they still collect information from your phone and correlate it under your Google Account. I created an account solely to install software (security) updates to the built-in components, and it greedily grabbed my contacts from my OwnCloud instance and sync'ed them to my Google Account. As colordrops mentioned in another reply, they are very sneaky about building a user profile.


And they always upload usage data, how many times you opened which app, how long it stayed in background and how often you used it in foreground, overall use time, etc.

For all installed apps, all the time.


Unlocking the bootloader is not enough, you'll need sunshine or similar for the rom to be completely unlocked.

But forget the security mods, I am impressed they made a user-removable battery mod on a motorola.


From the article "It is currently unclear how isolated the baseband processor is from the rest of the system's hardware."

Is this a problem? I was under the impression that the baseband controller was regarded as one of the more likely areas to insert "extra functionality", but I'm only going on info from security conference presentations.

EDIT: First Item in the TODO section: "Reverse engineer details relating to the Qualcomm MSM8610 baseband processor." Good to know they're on it.


Nothing in the posted web page inspires confidence that Appelbaum has any idea what he's doing. Everything on the page is something a primary school kid might do after reading XDA. Anything requiring skill is in the TODO.


Agreed, although I respect Appelbaum very much for his work on TOR. His time and knowledge would be more effectively spent on TOR, while letting the people with Replicant, Osmocom, OpenMoko, and hardware hackers who know what they're doing focus on freeing telephones.


Appelbaum is a software guy. I suspect that he is out of his depth here.


Jacob Appelbaum is known for overstating his abilities and trying to pass himself off as someone who knows what he's doing. Glad to see others are realizing this.


Yeah, you don't exactly see 'lawful intercept' code getting checked into AOSP. It's basically all handled by the baseband AFAIK.

The risk is reduced here though because they have removed almost all the sensors, so even if you used the baseband to transmit the mic it wouldn't achieve much. Your position could still be accurately tracked though.


>Your position could still be accurately tracked though.

If by triangulation alone...


Seems like adding a (nationwide) pager to the loop could improve that situation. Phone is in airplane mode, gets a page, user decides to exit airplane mode or not, if they do, phone calls outbound to a personal PBX and is patched in. All while the inbound caller hears ringing.


I applause the effort, but anti-surveillance device is not possible unless we have truly open hardware. There's more than enough space for backdoors in baseband alone, I'm not even talking about modern MCUs that power tablets, smartphones etc. and run closed firmware on multiple levels. I hope one day to see a strong open hardware movement, so we can be the real owners of our devices.


That's a frequent argument: "it's no point being secure if you can't be 100% secure". Being a little more secure still has value.

You can even disable the gsm function in the phone and use it as a wifi voip device with a VPN you control in between.


Assuming that the WiFi controller isn't compromised...

They're usually 100% closed firmware blobs containing vast amounts of non trivial software.


I'm not saying that there's no point. I just highlight the real problem -- integrated MCUs running firmware and drivers' binary blolbs that can do pretty much anything without user even noticing, and this project does not address these issues. Sure, you can secure device to a certain degree to make blanket surveillance more costly, but there's nothing now that protects against targeted attacks.


True ... if you are Iranian dissident that tries to protect himself while in US. If you are trying to protect yourself from state actor while in the state - then security and anonymity is binary. You either have them or don't.


You can at least increase costs as far as mass surveillance is concerned. Facing a targeted attack is rather hard, even with proper crypto and procedures in place.


If this is used just as an AP, how much harm can a baseband backdoor do? I mean, there are no interesting sensors, the other side already knows the (approximate) location ... assuming the user uses proper crypto (not on the same device, of course).


Does anyone know why the GPS wasn't removed?


Wouldn't much matter. In most cases the cellular location data and the nearby wifi networks are nearly as good.


GPS is usually integrated in modem, it's not possible to remove it separately. Though, one could shield it's antenna or feed white noise to it I suppose.


I believe GPS in most modern smartphones are now integrated directly in the SoC, and can't really be removed without removing the whole CPU.


iPhone 6 also works with microphones and front camera removed.


The idea that you can make an open / anti-surveillance device out of an iPhone does not seem likely to me. I was under the impression that you're stuck with Apple's proprietary firmware and OS regardless of what you do to the hardware.

If I'm incorrect here, I'd love to hear it.


You can jailbreak iOS if you want to run custom software. You can't be as certain that the device does not contain some remotely activatable backdoor as with free software (which does not mean you can't be certain at all; the whole premise of jailbreaking is that binaries are inspectable, and you can obviously sniff traffic coming from devices), but it would be somewhat odd for Apple to maintain such a backdoor at the same time it's getting the FBI pissed off at it for improving disk encryption (thwarting efforts to retrieve data from physically obtained phones). The baseband cannot DMA into main memory, last I checked, which at least mitigates a common concern.

Perhaps more importantly, I consider the whole issue of backdoors pretty moot (in a bad way), because every smartphone contains a web browser with many remotely exploitable vulnerabilities - that's just the way browsers work in 2015 - and it is not that hard to get someone to click on your link. If you're an intelligence agency, why would you even bother deploying a backdoor that could get you in trouble when you can accomplish the same thing through normal vulnerabilities?


By jailbreak you mean execute an unknown binary from a (probably?) untrustworthy website which exploits an unpatched local privilege escalation in the operating system, right?

Doesn't sound like a great start to securing your system.


Depends. The unpatched local privilege escalation is usually not remotely exploitable, and the initial entry point is typically over USB and requires getting past the USB pairing process (i.e. you need the passcode), so it shouldn't matter that much; in any case, the 'real' bad guys have 0-days, so it doesn't matter that much whether there is a non-0-day present.

As you say, there is then the potential risk from the jailbreaks themselves, which recently have all been Chinese (yeah, yeah). I don't think the real, practical risk of this is very high, as long as you ensure your binary is actually the same as everyone else's rather than some tampered item, but it exists. I do think jailbreaks should be open source; sadly I think there have been none since my last jailbreak, written back in 2011, and while a non-obfuscated binary is perhaps even better than source for analysis purposes in such a community (since analyzing the binary directly obviates the need for reproducible builds), jailbreak binaries have also recently been heavily obfuscated for no good reason. So there is definitely room for improvement, if anyone cares about this. isios7jailbrokenyet.com is still holding onto a $30k bounty for an open source jailbreak...


> I was under the impression that you're stuck with Apple's proprietary firmware and OS regardless of what you do to the hardware.

If the physical microphone is removed, the firmware and OS can no longer record ambient audio, unless an external microphone is attached. This would not create an "open / anti-surveillance device", but it would prevent remote audio surveillance.


>The idea that you can make an open / anti-surveillance device out of an iPhone does not seem likely to me.

I'm honestly more worried about the closed baseband processors present in all current phones, Android phones included.




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

Search: