Hacker News Reader

Comment by tzs | Hacker News Reader

The memo says "all major device vendors".

I would assume that the backdoor for Android devices is the Android Market itself.

Because Android is open source and each device manufacturer has its own build, it isn't really plausible to have a single backdoor within the core operating system. However, the closed-source Android Market application is the perfect candidate for such a mechanism; when you install an app via the market, all of the following happens:

1. You request the application from the Market and agree to any permissions requested.

2. The Market pushes an install instruction to the phone via Google's XMPP-based Android notification service.

3. The phone downloads and installs the .apk as instructed.

Step 3 requires no interaction from the user – this is how, for instance, you can send an app to your phone from the Market web site. But it also means that any government with sufficient leverage over Google can coerce them to use this mechanism to install an arbitrary SpyOnStuff.apk at any time.

But if this is the case it isn't entirely bad news for Android users, rather it yields two means of protecting yourself which aren't necessarily options on other platforms:

1. Use an open source Android build such as CyanogenMod, without the closed-source Market app installed.

2. Proxy Google's XMPP notification service and require user confirmation before pushed APKs are installed. I don't know of any Android mods that currently implement this capability, but it would be nice to see in future versions of Cyanogen or similar.

> I would assume that the backdoor for Android devices is the Android Market itself.

Not necessarily. The baseband firmware on your phone is probably more capable than you think. I played around with hacking my old HTC WinMo phone and with a little work I got the (Qualcomm) firmware to respond over USB. There's a complete file system on there that's nearly identical to the file system structure on my wife's dumb-phone (and accessed the same way). I assume they'd put everything they need at that level and don't have to insert anything into Android itself.

Yes, but even on devices where the baseband has full access to main system address space, the baseband device is something that varies from one Android phone to the next; on the other hand, the Android Market is a constant across almost all Android devices.

So which would you rather develop: a different backdoor mechanism for every Android baseband out there, or a single mechanism for all phones equipped with the Android Market?

This code probably doesn't vary that much. Across all the qualcomm phones I looked at (Smart and feature phone), it's clearly the same basic operating system. So this one underlying OS that's almost identical across all phones smart or feature that use the same chipset (in my case, they are all CDMA phones). So what's easier to develop, a backdoor mechanism that works for every phone (feature or smart) in exactly the same way using the same code or a different mechanism for each phone OS?

You don't develop either. All you do is tell whoever wants to sell the phone that they must include a backdoor. That means the backdoor almost certainly gets implemented in vendor-specific code (whether their firmware, their add-ons, or their branch of the core OS).

Can you post or point the way toward how to play with basebands? Or, how you got the baseband to respond over USB?

I'm very curious about how these end up working, and can't find much public work in the Android space of people trying to reverse basebands.

Edit:

I found the 28C3 presentation entitled "Reverse-engineering a Qualcomm baseband." [1]

[1] http://events.ccc.de/congress/2011/Fahrplan/events/4735.en.h...

> Because Android is open source and each device manufacturer has its own build, it isn't really plausible to have a single backdoor within the core operating system

I doubt they would be asking Google to put in a backdoor. They would be asking the individual device vendors to do so. After all, it is the device vendor, not Google, who has to get the particular phone approved for sale in India.

The market doesn't actually perform installations, though. Install is handed off to the package manager and you would need a backdoor there. But the package manager is part of AOSP.

Although, I have wondered if Google might have had more secret weapons to take out droiddream if necessary other than asking it nicely to delete itself. If not, boy were they lucky. I mean, it is pretty balsy to make an OS that for all appearances just assumes /system can't be compromised. It's a double edged sword of course any API a virus scanner might use is also a vector for attack. I guess possibly they're relying on being able to push a targeted OTA update? That's the best contingency I could come up with when pondering "what if droiddream wasn't retarded". But there are also ways to prevent OTA updates from being applied, so that's probably a one-time trick before the next malware blocks all OTAs (methods to block OTAs from auto-installing are all over places like XDA/rootzwiki).

Actually, given that the overwhelming majority of people _won't_ be running custom Android builds, it's also quite possible that Indian carriers are simply required to install whatever spyware the government requires, preferably without the knowledge of either manufacturers or Google. We're talking about a well-funded intelligence agency here, and you don't keep secrets by inviting unnecessary parties into the conspiracy, no matter how much you trust them or what "leverage" you have over them. Also, working with a global player like Google means Indian intelligence funds have effectively subsidized the development of tools that will in all likelihood be shopped to foreign spooks that spy on India. After all, it's not like they're going to get an exclusivity arrangement out of Google for this!

Reply on news.ycombinator.com