Well it’s really late right now, and I’ve been working on a ton of thing, though I thought I’d release this.

This is a decompile version of Vending.odex (Vending.apk/Market.apk) for the G1. It was done using a slightly modified DeDexer by Gabor, mentioned in previous posts.

Enjoy — I’ll post more on it later!

Vending.rar

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.

Success! It seems completely possible, though quiet a pain to inject new code into existing dex files. This doesn’t not appear like it would easily be done ON a device, though in the development setting it seems perfectly possible and completely do-able.

I’m working on a nice proof-of-concept example to show, though I don’t think this is a “backdoor” to malware. Android has been set up well enough that to properly inject things it would require many things to be done, making it in my opinion extremely hard to do it on the fly on the device. I had to inject the code directly to the dex, resigned both the signature and hash makings for the file, then resign the whole package before reinstalling (after a complete uninstall since we don’t have the same keys as the original package) onto the device. This is a long way away from actually being able to do nasty things with it, which is clearly a good thing, since we don’t want that to happen. This does have practical uses of course, though it seems Google has done security rather well so that this process would most likely only be done by an actual developer for a user to not notice an injected file… Otherwise they would have to allow unknown sources, packages would complain about key, so on and so on…

Hopefully more to come on this subject soon!