Tag-Archive for » unique id «

Monday, December 01st, 2008 | Author: Tim

So it was a long, long weekend - hope everyone enjoyed it and had a good turkey day. Sorry for the lack of updates, but snowboarding took precedence over blogging. I’ve stumbled across some more identifiers that can be used for the Android OS, even better since these are obtained without special permissions.

This one comes from android.os.Build.

import android.os.Build;
...
        StringBuilder Buffer = new StringBuilder();
        String NEW_LINE = System.getProperty("line.separator");

        Buffer.append("Model: "+ (Build.MODEL).toString() + NEW_LINE);
        Buffer.append("Device: "+ (Build.DEVICE).toString() + NEW_LINE);
        Buffer.append("Fingerprint: "+ (Build.FINGERPRINT).toString() + NEW_LINE);
        Buffer.append("Board: "+ (Build.BOARD).toString() + NEW_LINE);
        Buffer.append("Brand: "+ (Build.BRAND).toString() + NEW_LINE);
        Buffer.append("ID: "+ (Build.ID).toString() + NEW_LINE);
        Buffer.append("Host: "+ (Build.HOST).toString() + NEW_LINE);
        Buffer.append("Product: "+ (Build.PRODUCT).toString() + NEW_LINE);
        Buffer.append("Tags: "+ (Build.TAGS).toString() + NEW_LINE);
        Buffer.append("User: "+ (Build.USER).toString() + NEW_LINE);
        Buffer.append("Type: "+ (Build.TYPE).toString() + NEW_LINE);
        Buffer.append("Time: "+ (Build.TIME) + NEW_LINE);

Now the output from the emulator will look something like this;

Model: generic
Device: generic
Fingerprint: generic/generic/generic/:1.0/110632/110632:sdk/test-keys
Board: unknown
Brand: generic
ID: 110632
Host: undroid12.corp.google.com
Product: generic
Tags: test-keys
User: android-build
Type: sdk
Time: 1222115712000

When I get on my developer machine I will provide a dump of what these values look like on a G1 device. Though by looking at this output quickly, I wonder if the “fingerprint” would be able to provide a way of seeing if a phone is rooted or not? I guess we’ll see — I’ll be interested to see what the differences in all these results are between my phone and my bothers phone; mine being rooted and his not.

Anyway, with these values, combined with past values we’ve found both with special permissions and no special permissions, you should be able to hash something together for a unique identifier.

updated on December 1, 2008 at 9:00pm
From a rooted G1 device:

Model: T-Mobile G1
Device: dream
Fingerprint: tmobile/kila/dream/trout:1.0/TC4-RC30/116143:user/xda-dev
Board: trout
Brand: tmobile
ID: TC4-RC30
Host: undroid11.corp.google.com
Product: kila
Tags: ota-rel-keys,release-keys
User: android-build
Type: user
Time: 12255048530

Interesting results… :)

Category: android, coding  | Tags: , , , , , , , , ,  | Comments off
Wednesday, November 26th, 2008 | Author: Tim

Previously I wrote about how to uniquely identify Android devices without special permissions. However, maybe you want to get into the nitty-gritty and get an even more unique identifier for the device. This can be done, but you need special permissions. Essentially what I mean by “special permissions” is that the user will be prompted when installing that “this application tries to do this”. “This” referring to (in this specific case) Reading Phone State. This doesn’t mean it’s doing anything bad, however users might be turned off if your calculator wants to read the phones state etc. This is just how Google has set up the installation of applications, so that a user is properly notified of what an application is given permission to do.

What are the kind of identifiers we can get with this special permission? We can grade the “Device ID” which is the IMEI number, the phone number, Software Version (not sure if it’s currently being used?), Sim Serial Number and Subscriber ID.

That should be enough unique identifiers for anyone to come up with some hash! Heck, phone number alone should be enough since it would be readily known by a customer and easy to use.

To get these values add the following somewhere in your program;

import android.telephony.*;

...

		TelephonyManager mTelephonyMgr =
        	(TelephonyManager)getSystemService(TELEPHONY_SERVICE); 

		String imei = mTelephonyMgr.getDeviceId(); // Requires READ_PHONE_STATE
        String phoneNumber=mTelephonyMgr.getLine1Number(); // Requires READ_PHONE_STATE
        String softwareVer = mTelephonyMgr.getDeviceSoftwareVersion(); // Requires READ_PHONE_STATE
        String simSerial = mTelephonyMgr.getSimSerialNumber(); // Requires READ_PHONE_STATE
        String subscriberId = mTelephonyMgr.getSubscriberId(); // Requires READ_PHONE_STATE

Note that you MUST add permission access to android.permission.READ_PHONE_STATE otherwise your program will force close. This is added in the AndroidManifest.xml like the following;

<uses-permission android:name="android.permission.READ_PHONE_STATE"></uses-permission>

On the emulator it will output things like the following;

DeviceId(IMEI) = 000000000000000
DeviceSoftwareVersion = null
Line1Number = 15555218135
SimSerialNumber = 89014103211118510720
SubscriberId(IMSI) = 310995000000000

One should also note that a real device currently returns “00″ for Device Software Version, so it’s possible that this is something reserved for future use. These could all easily be used in some type of registration algorithm that you want to tie to a certain device. Also if you choose your identifiers properly you could allow your registration code to be complaint across all versions of your product. Using a phone number for example could allow a user to use your application on any phone they put their SIM card into. If you want to prevent this you could tie it to both the device ID and the phone number.

Monday, November 24th, 2008 | Author: Tim

Something that you always come across in writing algorithms for devices that you want to lock down is getting a grasp of the actual device it is intended to be on. Sometimes programmers want to lock a registration code not only to a name for registration, but also to a device. This can cut down on “sharing” of serial numbers etc. I was doing some research and looking for device specific information when I stumbled upon a few things. They are right out there in the open, but here they are just in case you have not seen them yet.

In Android.Provider.Settings.System we have some interesting values that could be of use, one specifically is “Android_ID”. From the documentation it is the following;

String ANDROID_ID The Android ID (a unique 64-bit value) as a hex string. “android_id”

Though while this is considered a “unique key”, please keep in mind that if a program has write access to the Settings, which is possible, this could be changed easily. Though it could be a safe assuming that it should not be changed, and upon normal program usage it wouldn’t be changed. Anyway, to retrieve this ID you just use the following snip-it of code;

import Android.Provider.Settings.System;
...
String Android_ID = System.getString(this.getContentResolver(), System.ANDROID_ID);

Also, note that in an emulator this will return “null”, though a real device will return an actual value. The nice thing about this tid-bit of code is that you are not required any special permissions to call it, since it’s essentially a passive call to get information. No write access is (obviously) required.