A tool for detecting external third party libraries used in Android apps. It does this by comparing the structure and bytecode of the APK's of interest against diff files generated by the LibDiff tool.
When library maintainers update their library, developers who use that library may not be aware of the updates. Depending on the content of the update, developers who do not update that library in their applications may be compromising the integrity of their app. In the worst case scenario, the update could be a security patch. This means that not keeping up-to-date with the library may be elevating the risk of malicious attack on the app's users. With LibDiff and LibDetector, we first aim to explore how prevalent it is for developers to use outdated libraries in their apps. Ultimately, we want to provide a means for developers to automatically check for updates to libraries in their applciations. The methodology is as follows:
- Java 1.7+
- dex2jar-2.1
Simply clone this repository to your local machine.
The easiest way to use this tool is by creating a runnable Jar. To do so:
-
Import this project into Eclipse:
File > Import > General > Existing Projects into Workspace Select the folder where the tool is cloned to Click "Finish" to import this project into Eclipse
-
Create a runnable JAR file:
File > Export > Java > Runnable JAR file Choose a destination and name for the JAR(such as LibDetector.jar) Click "Finish" to create the runnable JAR
This tool works in conjunction with the LibDiff tool, which computes the diffs between successive versions of a given library. Therefore, as a prerequisite the user must first collect libraries of interest and run the LibDiff tool on that collection before using the LibDetector tool. More about the LibDiff tool and how to use it can be found in the LibDiff documentation. After having satisfied this requirement, the steps to running the tool and obtaining results on APKs are as follows:
-
Choose any directory to be the tool's working directory.
-
In that working directory, create another directory named
"Android_APKs". Note that the name must be exact so that the LibDetector tool and locate it. -
Collect any APK's that you would like the tool to analyze, and place them in the Android_APKs folder as is.
-
Place the dex2jar folder included with the tool in the working directory.
-
Place the runnable LibDetector.jar file in the working directory next to the Android_APKs folder. An example of the folder structure is shown below. Note that in this example, the libraries whitelist is in the same directory as well. While this is NOT a requirement, it is recommended.
-
In the command line, make sure that you have moved to the working directory. Then, issue the following command to run the tool:
java -jar LibDetector.jar PATH/TO/WHITELIST_LIBRARIESNote that the tool expects one argument, which is the path to the libraries whitelist. This is the same whitelist that is being used and maintained by the LibDiff tool.
-
The tool will then create an
"Extracted_APKs"folder. For each APK, it will create a folder in the"Extracted_APKs"folder named after the APK, and extract the bytecode of the APK to this folder. It will then scan the bytecode and try to find matches to any libraries in the provided libraries whitelist. The results will be outputted to alibraryMatchResults.txtfile.
We have included the results of analyzing nearly 21,000 APK's by LibDetector in May of 2016 in the Results and Analysis folder of this repository. The contents of the files are as follows:
LibDetector Results Per App.zip: The library match results per APK reported by LibDetectorLibUse.txt: Counts the number of APKs consuming each version of a library, and lists them for each versionAPKLibUse.xslx: Combines the library use report from LibDetector with each APK's meta dataLibVersionUseFrequency.xlsx: Plots the frequency of use of each version of a library. Multiple versions of an app are filtered out.LibUseTable.xlsx: Shows the proportion of apps using a version of a library that is 1 minor version, and 1 major version behind.Mann Whitney.xlsx: Reports the rating of apps which use newer versions of a library versus those that use an older version. The comparison is done using the Mann Whitney U Test. Apps with fewer than 10 ratings are filtered out to minimize rating skews.Figures Directory: Contains all of the tables and figures generated from the data.
The libraryMatchResults.txt mentions the term "Levenshtein Ratio". This refers to the ratio of the Levenshtein distance between the class files of a library in the whitelist and the library that exists in the APK to the total size of those files. A ratio of 1.0 means that the files are completely different, and therefore the app most likely does not use that library. However, a ratio of 0.0 means that the files are complete copies, and therefore the app most likely IS using that library.
Some APK's have class files that coincide with reserved keywords of the Windows OS (such as "con" or "aux"). Therefore, running the tool on a Windows machine will throw a FileNotFoundException when it comes across such files, because it cannot create the class file on the disk when it tries to extract out the class files from the APK. The result is that for these APK's, the tool may partially extract out valid class files before it runs into this error, at which point the APK will get skipped for the library scan.

