Toolkit

We implement a tester app to automatically extract all data through the identified documented and undocumented channels, including system properties, system settings and system services.

The tester app can be downloaded through as follows: [APK file, Source]. You can use adb command to install the APK file to a connected Android device, as shown below.

adb install [DIR_OF_DOWNLOADED_APK]/getAllId.apk

Once installed on your device, the tester app request a few common sensitive permissions first to attempt access of UUI through documented channels. Since those runtime permission granting does not affect the access mechanism of undocumented channels, you can just go ahead granting permissions to the app.

There are four buttons displayed in the app’s main interface. The four buttons are corresponding to different processes:

1. GETID: click to retrive all entry points of three undocumented channels. The query of system property and system setting is also performed. A text file will be generated once the process is completed.
2. CHECK SDCARD: perform a filesys forensic and check if there is any (known) UUI stored by comparing with the genuie UUI values obtained through legal API access (that is why the tester app asks many sensitive permission at the first time launching).
3. APPINFO: display the app's information and MD5 on the screen.
4. BINDER SERVICE: given all entry points of system services obtained by clicking the first button, clicking this button triggers the tester app to bind all active system services and invoke all their interfaces as long as they are publicly defined.

You can click another button, after a notice text saying “done” of each button click. The data retrieval of all identified undocumented channels can be done in the background. All the data, including key-value pairs of system settings, names and values of all system properties, and public methods’ output of all the active system services, are saved in a text file in the device storage.

You may encounter a series of app not responding and device restart while binding all system services and invoking all their public interfaces. It is normal and you don't need to worry. The binding progress is saved so you can just resume binding once your device is back from a system restart. A "done" message will show on the screen once all binding tasks are completed.

There are two text files, com.privacy.getudid.txt and invokeRe.txt, containing results where potential unknown UUIs are stored inside. The former contains all retrival results from system properties and system settings, and the latter lists out all public functions defined in system services, and their invocation results. You can just use adb command to simply pull files to your PC, like:

adb pull sdcard/bindertest/[FILE_YOU_WANT_TO_PULL] [YOUR_LOCAL_DIR]

In below, a few screenshots are shown to demonstrate how the txt files look like. The tested device is Google Pixel 3A installed with Android 11.

Consider a UUI can be found by runing the tester app before and after factory reset of one device, there will be two text files generated by the tester app to be analyzed. To perform analysis, a differential analysis idea is adopted. This step aims to find out which data retrieved by our tester app remains unchanged even after system reset, and meanwhile comes with a non-trivial size (>4 bytes) to be able to sufficiently and uniquely idenfy a device.

The screenshot of the text file (com.privacy.getudid.txt) showing the system properties retrived

The screenshot of the text file (com.privacy.getudid.txt) showing the system settings retrived

The screenshot of the text file (invokeRe.txt) showing the system service functions invoked and corresponding return values

The complete static analysis toolkit can be download through this link. It is over 500MB and requests JDK 11 to execute.