在重構某個apk的時候，偶然發現了友盟在使用一個叫utdid的庫，感覺是生成UUID用的，剛好對UUID的生成邏輯比較感興趣，就有了下文。
一、utdid實現過程分析
publicstatic String getUtdid(Context arg2)是utdid庫對外調用的接口, 在com.ta.utdid2.device.UTDevice類裏
具體代碼如下圖:
主要功能在com.ta.utdid2.device.UTUtdid.getValue()裏面
utdid主要獲取和生成流程如下:
1.從Setting.System讀取"mqBRboGZkQPcAkyk"，如果有值，則直接作爲utid使用，如果獲取失敗，繼續讀"dxCRMxhQkdGePGnp",這裏面的值是utid使用aes加密後，再進行base64編譯的結果，對其進行解密，即可得到utid,並將"mqBRboGZkQPcAkyk"的值，修改正確。失敗則進行下一步
2.從name爲"Alvin2"的SharedPreferences讀取UTDID做爲utdid,對其進行讀取校驗，失敗就從name爲"ContextData"的SharedPreferences裏讀取K_1171477665，對讀取值進行解密，如果解密後的結果正確，則將其作爲utdid返回
3.上面的緩存都失敗了，那就只有生成了。
生成函數爲:com.ta.utdid2.device.UTUtdid. _generateUtdid()
生成的時候會引入兩個隨機值，一個是時間，一個是Random，然後跟IMEI串聯起來，IMEI如果獲取不成功就再用一個Random.這裏的生成因子其實就是兩個隨機值外加IMEI。
IMEI的獲取是相當不穩定的。部分安全軟件會攔截此值的獲取，小米手機很早就可以設置讓此值返回爲空。6.0系統以後，在targetSDKVersion爲23的條件下，IMEI默認也是獲取不到的。
所以這裏來源因子比較弱，很大可能最終結果就是一個隨機值。
二、utdid可能存在的風險
個人認爲這種唯一性ID生成方式是有安全問題的
1.從Setting.System讀取到的"mqBRboGZkQPcAkyk"值即是utdid，而Setting.System無任何權限的情況下也可以讀取，這樣第三方app都可以去讀取。這樣會導致utdid外泄。
2.第三方app甚至可以讓用戶手機上的阿里utdid設置成他想要的值，只要添加<uses-permissionandroid:name="android.permission.WRITE_SETTINGS"/>即可。
大概擼了幾個阿里的apk看了一下，使用的有友盟、蝦米音樂、阿里小智、老版本的支付寶、淘寶等
public static String getUtdid(Context arg2)
下面的兩幅圖是隨便找了兩個app，用jeb分析getUtdid接口的交叉引用，可以看到哪些模塊再調用這個接口
比較了支付寶的不同的版本，一個是去年的8.4.0.120608，一個是今年的9.3.1.120312，發現8.4時候，支付寶的唯一性id使用的還是這個庫，9.3版本已經不再使用這個庫了，而是從libsecuritysdk-x.x.x.so這個so庫來生成一個加密的uuid。支付寶可能也是意識到這樣的安全問題，所以做了更改。後面有時間再分析一下libsecuritysdk.so裏utdid的生成邏輯。
