Posts Tagged with Android_ID
Detecting an emulator, and getting around detection

So recently I got an email asking about spoofing your Android ID, normally I just redirect people to my other articles, but I guess this one was different. The person specifically was looking to test applications on their emulator, and needed to avoid “emulator detection”. It didn’t seem like anything tricky – but I googled quick with not many results returned. The things that where returned where pretty… Well – overcomplicated. My first thought was that this should just be located in one of the many sqlite3 db’s – and it turns out it was. Simple little work around yet again, have to love those!

First off, lets see how most applications detect emulators. It’s done using a simple call to Secure.getString() using Secure.ANDROID_ID (previously this was done using System.getString() and System.ANDROID_ID, though these methods are now deprecated). The “detection” often relies on this returning null when it is read inside an emulator. With this said, below is a normal emulator detection snippet;

Very simple, doesn’t do anything to complicated, just checks for null being returned. So how can we get this to not return null in an emulator? Easy — just a simple sqlite3 insert command!

Open a shell to your emulator, and navigate to /data/data/, open up the db in sqlite3 and insert a value using ‘androidid’ as the key, like the following;

That’s all you need to do. Now all programs that use that method for detecting if it is an emulator will be returned the value you’ve entered as the Android_id.

More spoofing of the android id…

Finding the Android ID

Finding the Android ID (img blacked out)

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 “”. 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/
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.

Spoofing your Android_ID

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/

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…

Uniquely Identifying Android Devices without special permissions.

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;

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.