在重構某個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的生成邏輯。