Snooping Encrypted Data On Android

Make sure you have a rooted device for this, as you will need to install some packages. For encrypted traffic, you will need to install a proxy called socat. To do this, use opkg, which will download and install packages to your android device. The link to the project is given below.

http://dan.drown.org/android/

First, download the application

http://dan.drown.org/android/opkg.tar.gz

 Then push the downloaded tar to the Android device

# adb push opkg.tar.gz /data/local

Unarchive the file

# adb shell tar /data/local/zxvf opkg.tar.gz

Now update and install the socat proxy

$ opkg-cl update opkg-cl install socat

Let's also say you want to proxy all traffic going to android.clients.google.com, which is where most of google generated traffic goes to. I won't go into it here, but you will need to generate your own keys and certs for the android.clients.google.com domain name (Make sure to also install the client crt to your android device to make it a trusted authority). By setting up this way, your device will trust the proxy on your device as a legitimate google server.

If there is another site you want to snoop, just generate new keys and change android.clients.google.com to the new site in the command below.

$ ./bin/socat -v OPENSSL-LISTEN:8443,reuseaddr,verify=0,cert=/data/local/server.crt,key=/data/local/server.key,cafile=/data/local/ca.crt,fork OPENSSL:android.clients.google.com:443,reuseaddr,verify=0

This command sets up the cert you will use, the key and cafile. The proxy listens on the device on port 8443. It forks another process and pushes the traffic to android.clients.google.com on port 443.  In this way, you can decrypt the traffic at the proxy. The -v option prints the decrypted data to standard out.

Now that you have the proxy setup on the device, you need to configure the iptables.

Before setting the iptables,  check the interfaces on your device:

$ ls /sys/class/net

     dummy0
     lo
     rmnet0
     rmnet1
     rmnet2
     sit0
     wlan0

lo is the local interface. For wifi, you should listen on wlan0. The rmnet(x) interfaces are for USB and GPRS/CDMA. sit0 is simple internet transition, which incapsulates ip6 in ip4. You will nat traffic on the wlan0 interface (although you could nat on any other interface the traffic is going through).

Next, you need to know which specific process you want to snoop. Let's check:

$ ps

with result

app_32    5862  139   470652 38304 S com.google.android.gm
app_120   5960  139   473708 38472 S com.google.android.talk
app_130   5981  139   478716 41476 S com.google.android.videos
app_138   6008  139   488688 41356 S com.google.android.youtube

com.google.android.gm has app_32 id. That is the one you want as you will use it when setting up the iptables.

Ok at this point, you know you want to nat traffic for app_32 on interface wlan0.

I’ll show how to use the iptables to direct traffic to the proxy. You need iptables to write NAT rules, so install it.

$ opkg-cl install iptables

The iptables command is going to look something like

$ iptables -t nat -A OUTPUT -p tcp -o wlan0 --dport 443 -d android.clients.google.com -j DNAT --to 127.0.0.1:8443 -m owner --uid-owner app_32

Notice that this command only directs the the traffic for app_32.  This is mapping any request for the google servers to the on-device proxy that you setup.

After this, you can use various google apps and watch the traffic print out in the logs (use logcat to see them).

On Why Google Glass Isn't So Interesting

1) Price - this is an easy barrier to see. $1500 plus say $300 for an attached Android device is a lot of money. This will hurt consumer adoption. The Xoom failed at $800 (this was just WiFi option) and Logitech Google TV failed at $300. Google needs to get this one right.

2) Not many developers translates to not many apps. Without apps, it's not an interesting consumer device. The price (1) is going to severely reduce the size of the developer community for Google Glass. I remember on the first day the Xoom was released, I was waiting for Best Buy to open. Another Android dev was waiting there as well and told me he was going to buy the Xoom, test his app and then return the Xoom. I only shelled out the money because I had a contract to develop an app on this specific device so the cost made sense. Most devs can't afford or justify a $1500 price point (particularly for an untested market).

Logitech Google TV is another good example of not having enough apps. Google gave away 10,000 units but only to web developers (I still don't know what Google was thinking). Android developers weren't in the picture so there were very few applications available for it. When I bought it, I was disappointed with everything but the YouTube app (this single app is awesome by the way). Google TV is a boring platform for both the developer and the consumer.

3) It's a web app, you can't create native apps. A lot (well maybe not a lot) of web developers are jumping with joy, but for developers who are traditionally in the mobile or embedded space, this is uninteresting. The only published way to develop an app is through a web service or site.

Let's take a look at what we can do. Google Glass has an API referred to as the Mirror API.

* Timeline - REST API for deleting, viewing and creating timelines
* Subscriptions (subscribe to timeline or locations)
* Locations (attached to a timeline)
* Contacts (People you know, phone number, other types of contact methods).

So you pretty much get the idea. Just about everything is tied to a timeline. You can add to it, scroll through it and be notified about it. There are some cool sounding applications like creating a Google Hangout, with live streaming video. It's all very social. But as a non-web developer, what can I really do with this device, besides jumping out of an airplane with it of course?

One idea I had was to use the glasses as sensor for another attached device. I could hack it and maybe build out an accessory (using say an Arduino Mega). The problem is that Google Glass is not that impressive as a set of external sensors. It has a Camera, Audio, and Bluetooth/WiFi. It doesn't contain a GPS chip, relying on an attached Android device for location. Since we can't develop native apps, hooking up additional external sensors to Google Glass is also not doable.

I'm not saying Google won't get it right before it releases the consumer version, but as it stands, it's a boring developer platform for all but a web developer. If Google opens up to allowing developers to write native apps (maybe adding a more impressive set of sensors that could be accessed through ADK), it would garner more development interest from us non-web folks. If Google Glass is going to become something more than Google+ on steroids, it will have to open up to native apps. ADK support will also be required to expand the limited sensors on the Glasses.

4) It's not an open platform. This goes beyond just building native apps or being able to tweak the platform itself because even the web apps are going to be tightly controlled. To further lock things down, Google adds in it's terms:

You may not publish or distribute API Clients outside of the official Google-hosted Google Mirror API Client distribution channel, unless otherwise approved in writing by Google.

Google wants developers to innovate under a lot of constraints...

5) Uncertain business model with the Glass platform. According to Mirror API terms and conditions:

No Fees. You may not charge end users any fees or collect any payments in order to download or access your API Client, or in connection with virtual goods or functionality of your API Client

No Ads. You may not serve or include any advertisements in your API Client

So I can't make money off anything using the Mirror API. I've already mentioned (3) that the Mirror API is currently the only way to build apps for Google Glass. This seems to be case closed, 'No Business Model' but in the 'Glass Platform Developer Policies':

Don't collect, store, or share sensitive personal information such as credit card, bank account, driver's license, or Social Security numbers, except as necessary to collect payment.

This seems to suggest there may be a way to make money in the future, just not through the Mirror API Google provides, which is currently the only way to develop for the platform.

To further muddy the waters, Google has setup the Glass Collective to fund entrepenuers in this area. I'm confused on how to start and fund a company when there is no model for making money. I'm sure KPCB will love such a business plan. The fastest way to fail a business is to believe that after building it, you will figure it out how to make money.

So to sum up, Google Glass is an expensive device that's going to have a limited number of web apps on a closed platform with limited sensors. Oh and I can't make money from my work. Now I do believe that there is a future potential for Google Glass, but this first generation is not exciting enough to be a serious developer platform.

Android Security Simply Explained

From an application perspective, Android security is very simple. Here’s the default security rules for when one application tries to access the component of another application. By component, we mean provider, service or receiver. 

1. If calling app is root or system, grant access
   
2. If calling app has same UID, grant access
   
3. If component not exported, deny access
   
4. If no permission, grant access
   
5. If permission, check calling app has permission
   

Some inferences from the above rules:

1. If you don’t export your component, only same uid and system can access it
   
2. It follows from (1), you can protect your application component against anything but system (or root) merely by not exporting it
   
3. If you export your component, the only way to protect it is by requiring a permission
   
4. Permissions aren’t checked/needed if the component is being called by an application with the same sharedUserId declared in its manifest.
   

Keep in mind the above rules are the default rules specified by the Android platform. You get them out of the box, just by configuring the manifest. However, an application developer may choose to programmatically enforce additional permission checks, or even programmatically reject anything that tries to bind against a component without having the same sharedUserId. This is particularly common among proprietary google applications that don’t want system applications accessing some of their services.