Private unique device identifier in iOS

Question

We\'re working on a project with my colleagues which involves using a lot of private and non official code. This is not intended for AppStore use.

The f

Answer 1

What about this: https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIDevice_Class/#//apple_ref/occ/instp/UIDevice/identifierForVendor

An alphanumeric string that uniquely identifies a device to the app’s vendor. (read-only)

The value of this property is the same for apps that come from the same vendor running on the same device. A different value is returned for apps on the same device that come from different vendors, and for apps on different devices regardless of vendor.

Since iOS 6 and current in iOS 8

This meets your requirement of:

any permanent hardware identifier unique enough to identify a device that would persist in spite of device wipes and amongst different iOS versions

This is documented to be unique per device and persistent whether from app store or enterprise delivered.

Normally, the vendor is determined by data provided by the App Store. If the app was not installed from the app store (such as enterprise apps and apps still in development), then a vendor identifier is calculated based on the app’s bundle ID. The bundle ID is assumed to be in reverse-DNS format.

Answer 2

I don't know if commercial solutions are of interest to you but check out http://www.appsflyer.com

I'm not affiliated with them but we used their SDK at my previous employer. They have a device fingerprint technology which does work.

Note: If the user resets the IDFA then AppsFlyer will see this as a new device. However, and its been awhile so I can't remember, I think you can use their SDK, not use AdSupport.framework, and then they won't have the IDFA available to them. So I'm guessing that their device fingerprinting may work.

They also have competitors, search for device fingerprinting. Check out Yozio and branch.io, they both claim to do this. I've not used their product, just seen their websites.

Answer 3

You could try accessing lockdownd API directly, via libMobileGestalt.dylib.

Header here. The basic code to access the UDID should be: (you still need to load the dylib)

CFStringRef udid = (CFStringRef)MGCopyAnswer(kMGUniqueDeviceID);

taken (&slightly modified) from here.

For further information on libMobileGestalt , look here.

If this fails you could still try communicating with lockdownd via an SSL Socket( see here ), no idea how that works though, but you might figure it out.

As you may have noticed though, all stuff on this is years old. Still worth a try i guess.

Answer 4

Are you allowed to ask the user for their MSISDN's? (international phone numbers) Like what whatsApp is doing when you first login with them by confirming with a SMS code sent to the user msisdn. If you know the MSISDN's of your users, you can keep them in your servers DB and only allow a white-listed msisdn to register and use your services. If you want to be more secure you can send the SMS's more often however there is a way to understand SIM-card change (this is for t-mobile and europe use i guess) from within the APP so that the user cant fool you by enetering SMS for a different MSISDN and then change to his/her real MSISDN sim card.

MSISDNs are unique worldwide and they are secured by the telecom operators so i guess this solution is strictly secure. What do you say? good luck

update: actually upon reading your question carefully again, I think you dont want the user to login any info right? if thats the case sorry for the wrong answer:/

note: why cant you use

[[[ASIdentifierManager sharedManager] advertisingIdentifier] UUIDString]

the advertising identifier is unique to the device and permanent i guess. I dont know if you can use it privately though..

Answer 5

I am unsure of your full intentions but would it be enough to have the app generate and store your own unique ID within the app on installation? Then perhaps have the app send that ID to a server and store the IP it came from. Perhaps also have some logic to have the app phone home every so often so you can store additional IP's if they change. Obviously this is not foolproof but it may be the beginnings of a workaround.

Answer 6

Actually i don't know this solution is helpful or not. but after removed support of UDID. i have manage Unique device identity following way. with help of Vendor ID. Here what we did that.

As initial while application will run, i will check out that weather vendor ID for specific app is stored in key chain or not. if it not stored then i will store that vendor ID in key chain. so second time once my app is going to check again that weather vendor ID for specific app it stored of not in key chain. if stored then bring it from key chain and doing action on same according to requirement. so here alway vendor ID is unique for device.

Here are the steps that we keep uniqueness of device with help of vendor ID.

Step 1 : Integrate Lockbox in your project. that will help you to stored/retrived vendor ID in/from key chain.

Step 2 : Here are the code that perform action of checking vendor ID and retrieving vendor ID from key chain.

-(NSString*)getidentifierForVendor{
    NSString *aStrExisting = [Lockbox stringForKey:[[[NSBundle mainBundle] infoDictionary] objectForKey:(NSString*)kCFBundleIdentifierKey]];

    if (aStrExisting == Nil) {
        NSString *aVendorID = [[[UIDevice currentDevice]identifierForVendor]UUIDString];
        aStrExisting=aVendorID;
        [Lockbox setString:aVendorID forKey:[[[NSBundle mainBundle] infoDictionary] objectForKey:(NSString*)kCFBundleIdentifierKey]];
        return aVendorID;
    }else{
        return aStrExisting;
    }

With help of above steps, you always get uniqueness of device. because key chain is never deleted. it always updated.

Hope this help you...