Tag-Archive for » Android_ID «

Thursday, April 09th, 2009 | Author: Tim

Finding the Android ID

Finding the Android ID (img blacked out)


Your Ad Here
In a previous article I had posted some information about how it is possible to spoof the Android ID that is returned when calling the Settings.System.Android_ID function. Though I had noted at the end of my post the following;

Note that this will NOT change the android id used by google products since they use one that is linked to your gmail account that the phone is associated with…

This bugged me a little bit because I wanted to know how the google applications where using and getting the android information - did they pull it directly from the hardware? Where they just using private API that was more secure? So after a little research, I found exactly what was going on, and again how it would be possible to spoof the id.

Essentially the google applications use googleapps to store the android id, this is the program on the phone named “com.google.android.googleapps”. This is a very interesting program that sadly developers do not have access to as of yet, though hopefully this will change shortly.

Anyway, this program is also susceptible to being force-fed spoofed values. The method is essentially the same as the previous one, though just performed on a different database. From within adb or the shell, do the following;

$sqlite3 /data/data/com.google.android.googleapps/databases/accounts.db
update system set value=’deadbeef0000badf00d’ where name=’androidId’;

This program also store in that table the imsi number linked to the phone, for simcard tracking purposes.

Friday, March 20th, 2009 | Author: Tim

Your Ad Here
With the (hopefully) eminent release of the cupcake update for the android os - this is supposed to be fixed with the addition of Settings.Secure; though I guess we won’t know until it gets released?

Anyway — basically you can modify system values in a specific database, so any program that calls Settings.System.Android_ID can be given any id of your choosing.

Just load up adb and navigate to the sqlite database: /data/data/com.android.providers.settings/databases/settings.db

Run the query;
select * from system;
You’ll see plenty of information which can then be changed;

Running the following;
update system set value=’dead00beef’ where name=’android_id’;
Would give you an ultra-slick android_id of dead00beef’ :)

Note that this will NOT change the android id used by google products since they use one that is linked to your gmail account that the phone is associated with…

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.