Wish App reverse analysis app_device_id Field Generation Algorithm

Wish App reverse analysis app_device_id Field Generation Algorithm
Overview

This article decompiled the Wish App and reverse analyzed the algorithm used to generate the app_device_id field in the App.
The tools used include:
1. Apktool: Get the resource file and smali disassembly code
2. dex2jar: decompile the apk and convert classes. dex to a jar file.
3. jd-gui: Open the jar file and view the java source code.
Decompilation environment: mac osx

Get java code and smali disassembly code through apk Decompilation

1. Download wish.apk from google Play

2. Use dex2jar to unpack the apk and convert classes. dex to a jar file. <喎?http: www.bkjia.com kf ware vc " target="_blank" class="keylink"> Vc3Ryb25nPjxiciAvPg0KtPK/qtbvtsujna00ndd/keys = "" src = "http://www.bkjia.com/uploads/allimg/160423/04110a145-1.png" title = "\"/>

3. Use jd-gui to view the Wish-dex2jar.jar file, that is, the java source code
Open the Wish-dex2jar.jar file in jd-gui to get the Java source code, such:

4. decompile the apk using Apktool to obtain the smali disassembly code.
Terminal:Apktool d-f Wish.apk-o WishSuch:

In this case, you can get the Wish folder, which contains the resource files such as xml and graph cutting in the apk and the code decompiled by smali for analysis.

Analyze the algorithm for generating the app_device_id Field

1. Quickly locate the Code Location of the app_device_id Field
Jd-gui uses the search function to quickly locate the position of app_device_id in the code, for example:

The key code is:

ParamHttpRequestParams. put ("app_device_id", getDeviceId ());

The app uploads the app_device_id field for each network request. The value of the field is the value returned by the getDeviceId () method. Therefore, we will analyze this method.

2. getDeviceId () method analysis
Let's first look at the code implementation of getDeviceId:

From the code, we can clearly divide the entire process of obtaining DeviceId into three parts:
(1) retrieve the DeviceUuid from the SharedPreferences storage.
The code segment is:

(2) If the DeviceUuid value is not saved in SharedPreferences, retrieve it from the local folder. The specific file address is/Document/Wish/device_data _. If you get the value, save it with SharedPreferences.
The code segment is:

(3) If the local file does not exist, create one (this is the same as the first entry after the application is installed ). The creation process uses the random generation method, that is, the randomUUID () method provided in the java. util. UUID class. The format is 23c2add6-aa30-4442-97c8-81930766f089. Save the obtained value as SharedPreferences.
The code segment is:

After obtaining the random value, the new thread stores the value in the local fixed Folder/Docment/Wish/device_data.
The code segment is:

Because/Error/, The code in the run () method cannot be decompiled. Therefore, smali is used for verification.

3. smali code analysis the process of saving the DeviceUuid value in the new thread to the local device_data
The smali folder contains the following files:

Find WishApi. smali in com. contextlogic. wish. api. core, open the file, and locate it under the getDeviceId method. (the code is too large, so it is omitted in the middle .)

Gradually locate the code of the new thread:

From the code, we can see that a local variable writeableDeviceId is defined to save the DeviceUuid value, and a thread is started to jump to the WishApi 2. Go to smali. Open WishApi 2. smali code,

There is only one run () method in the code.

In the run () method, two tasks are done in total,
(1) locate/Document/Wish/device_data. If yes, you can directly locate the file. If no, you can create a new Wish folder and a new device_data folder.

(2) Open FileOutputStream to write the value to the device_data _ file.

Overall process

The general flowchart is as follows:

The value saved in the path/Docment/Wish/devicedata on the mobile phone:

It is consistent with the packet capture value:

Summary:

Because the value of the app_device_id field is randomly generated, the above code analysis shows that the app_device_id field is sent every time you access the network. This requires that the corresponding value be unique, to ensure that the device to be operated is safe. Here, the only way to achieve this is to generate the value at random once, and save the values separately through SharedPreferences and File. The app_device_id value is randomly generated only when the application is uninstalled and re-installed and the local file device_data is deleted, generally, the user does not find and delete the path of the file stored by the Application When deleting the application. This makes the device ID unique.