Thoughts on the udid in iOS devices

What is a udid?
The full name of udid is unique device identifier. as its name implies, it is the unique identifier of Apple iOS devices. It consists of 40 characters of letters and numbers.

What is the use of udid?
Mobile Networks can use udids to identify mobile devices, such as iPhone and iPad. Udid is unique for each device, and thus becomes a practical tool for advertising companies, market analysis agencies, and app testing systems to track user behavior.

The main reasons for using udid are as follows:
1) used for statistics and analysis, such as third-party statistical tools flurry, umeng, and AdMob;
2) use udid as the user ID to uniquely identify the user, saving the user name, password, and other registration processes.

It can be seen that udid is a very important information for iOS app developers (although jailbreaking devices can use some tools to change the device's udid ). However, since ios5.0, Apple announced that it will no longer support obtaining the device's udid using the following methods.

[CPP] View plaincopy

1. [Uidevice currentdevice] uniqueidentifier];

Recently, it was reported that the Apple App Store prohibits access to udid applications. Therefore, developers should abandon udid as soon as possible to find another alternative.

I have also spent a lot of time looking for better alternatives, as shown below:
I. UUID alternative solution proposed by Apple

[CPP] View plaincopy

2. -(Nsstring *)UUID{
4. Cfuuidref puuid = cfuuidcreate (NiL );
6. Cfstringref uuidstring = cfuuidcreatestring (nil, puuid );
8. Nsstring * result = (nsstring *) cfstringcreatecopy (null, uuidstring );
10. Cfrelease (puuid );
12. Cfrelease (uuidstring );
14. Return[Result autorelease];
16. }

Apple recommends using the aboveCodeGenerate a unique identifier string for the application. The developer can call the SDK once when the application is started for the first time and store the string to replace the udid. Obviously, there are many problems with this method. If a user deletes the application and installs it again, a new string is generated, so the device cannot be uniquely identified. If you Back Up Files from an old device to a new device, the two devices have the same cfuuid. If you back up the operating system from a temporary file, different cfuuid may exist in one device.

2. openudid
The contributor said in the README document:
Openudid is a drop-in replacement for the deprecated [uidevice uniqueidentifier] a.k. A. udid on iOS, and otherwise is an industry-friendly equivalent for iOS and Android.
The agenda for this community driven project is to:-provide a reliable proxy and replacement for a universal unique device identifier. that is, persistent and sufficiently unique, on a per device basis. -Not use an obvious other sensitive unique identifier (like the MAC address) to avoid further deprecation and to protect device-level privacy concerns-enable the same openudid to be accessed by any app on the same device-supply open-source code to generate and access the openudid, for iOS and Android-incorporate, from the beginning, a system that will enable user opt-out to match Apple's initial intent.
The vision is good, and the MAC address is indeed not used. At the same time, different applications on the same device can use the same openudid. However, you can still find problems after careful analysis.

The code used to generate a unique identifier for openudid is:

[CPP] View plaincopy

2. UnsignedCharResult [16];
4. Const Char* CSTR = [[[nsprocessinfo processinfo] globallyuniquestring] utf8string];
6. Cc_md5 (CSTR, strlen (CSTR), result );
8. _ Openudid = [nsstringstringwithformat:
10. @"% 02x % 02x % 02x % 02x % 02x % 02x % 02x % 02x % 02x % 02x % 02x % 02x % 02x % 02x % 02x % 02x % 08x",
12. Result [0], result [1], result [2], result [3],
14. Result [4], result [5], result [6], result [7],
16. Result [8], result [9], result [10], result [11],
18. Result [12], result [13], result [14], result [15],
20. Arc4random () % 4294967295];

The nsprocessinfo class is used here.
When the first application on the device that uses the openudid solution is called for the first time, a unique identifier is generated. At the same time, in order to be the same as the number of digits of the official udid, an 8-bit random code is appended to the MD5 value. Then, this solution uses the nsuserdefaults class (application settings ). The application saves the obtained unique identifier to the application's userdefaults. IfProgramIn the future, you need to use a unique identifier to obtain it from userdefaults, so that you can obtain the same identifier. However, if the user deletes the application, userdefaults is also cleared. To avoid generating a unique identifier, the uipasteboard class (device clipboard) is used in this solution ). When the application saves the unique identifier to userdefaults, it also saves it to the uipasteboard marked with a special key. The Code is as follows:

[CPP] View plaincopy

1. Uipasteboard * slotpb = [uipasteboardpasteboardwithname: availableslotpbid create: Yes];
2. [Slotpb setdata: [nskeyedarchiver archiveddatawithrootobject: dict] forpasteboardtype: kopenudiddomain];

Availableslotpbid is a string key prefixed with org. openudid. slot. This number ranges from 0 to 99 by default (of course you can modify it ).Source code).
If the second application using the openudid solution is installed on the device, when the application calls the openudid generation method, the unique identifier (traversing the uipasteboard with the key from 0 to 99) will be obtained from the uipasteboard. Here, the first application is saved to the uipasteboard. That is to say, as long as an application using openudid exists on the user's device, if other apps subsequently installed obtain openudid, the one generated by the first application will be obtained.
It looks good and complicated. However, if you want to delete all the applications that use the openudid scheme and obtain the openudid again, the openudid is different from the previous one (I tested it, indeed ). We can see that this method is not safe.

Iii. Open-source secureudid

After reading the source code of secureudid, we found that it is similar to openudid, but the Unique Identification Code obtained at the beginning is slightly different. At the same time, we can see from the author's readme document that this solution also has many problems. As in the original article:
Is this a true udid replacement?
Secureudid has two properties that you shoshould know about before you use it. first, as indicated above, the identifier is not derived from hardware attributes. second, the persistence of an identifier cannot be guaranteed in all situations. this means that, while unlikely, it is technically possible for two distinct devices to report the same identifier, and for the same device to report different identifiers. consider this carefully in your application. here is a list of situations where this identifier will not exhibit the Uniqueness/persistence of a traditional udid.
* The user has opted-Out Of The secureudid system, in which case you will receive a well-formed string of zeroes.
* Device A is backed up and then restored to Device B, which is an identical model. this is common when someone breaks their phone, for example, and is likely desirable: you will receive device A's secureudid.
* The secureudid data is removed, via user intervention, uipasteboard data purge, or by a malicious application.
* The secureudid backing store becomes upload upt.
* All secureudid applications are uninstalled from a device, followed by a uipasteboard data purge.
I found that the previous openudid basically had the above problems, but the author did not write them out. It seems that the contributors of secureudid are more generous.

4. Related to wifi MAC addresses
There are also some alternative solutions related to wifi MAC addresses on the internet, mainly divided into three types: the first is to use "MAC address"; the second is to use "MD5 (MAC address )"; third, "MD5 (MAC address + cfbundleidentifier )". GitHub has an open-source project (UIDevice-with-UniqueIdentifier-for-iOS-5) that implements these methods.
There are also problems with using this method: 1. Some machines on the market (although the number is very small, but I have found this problem during use) cannot obtain the MAC address, some people say that this part of the machine is Unicom castrated without WiFi version, details are unknown. 2. the MAC address is the same as the udid, and there is a privacy issue. Apple now disables udid, which cannot guarantee that MAC addresses will not be disabled in the future.

Reference: http://blog.csdn.net/jwzbskywz/article/details/7703140