Using modules in app development is a great concept: no one has to re-invent the wheel, bug fixes and implementation of improvements can be performed at a central place with multiple apps profiting from – and each developer can focus on what (s)he’s best at. That´s the idea behind many useful modules contributing to the apps’ functionalities – and so there are plenty of them: to deal with databases, GUI-elements, file handling, and so on. And then there are… Tracker, following all of our activities and reporting them „somewhere in the cloud“. As well as proprietary modules, their source code not openly available – and thus unclear what they really do. Both are usually at least potential dangers to privacy.
Beware of Greeks bearing gifts
„[…] timeo Danaos et dona ferentes“ Vergil’s priest Laokoon said in the Aeneis – „I fear the Danaans [Greeks], even those bearing gifts.“ Also a good many apps out of Google’s Play Store could rightly be called „Trojan Horses“. For example highly rated „Antivirus“ Apps, surfing Pornos in the background. Or other apps from the same developers, performing advertising fraud under the hood. Downloaded millions of times, rated above 4.5 stars – and still available at Google Play Store (as well as pre-installed on many Samsung devices).
App reviews on established portals (with few exceptions) only deal with „superficial“ aspects: graphic design, range of functions, and how well an app works. You rarely find out what happens behind the scenes. The question of how secure one’s own data is remains unanswered – and not only with regard to said background or better underground activities, but also with regard to data transmission and storage itself: Is the data transmitted and stored in encrypted form? Where is it stored? Who else has access to it? And what data is affected at all?
Danger zone: Tracker inside!
I have already reported about Exodus Privacy in my article Exodus Privacy: The Tracker-Checker – as a service dedicated to detecting tracking modules in Android apps. In Exodus’ statistics, there are numerous apps that contain more than 50 tracking modules. Who remembers the days when an app with more than 100 kilobytes was considered „pretty big“? Today, for example, the alarm clock app Alarmy has a size of more than 80 megabytes! Whether the 40 tracking modules included in the app might also have something to do with that, I think is a rhetorical question. Not-so-fun fact: The top 10 most widely used tracking modules consist entirely of candidates from just two companies. Not hard to guess which: Google and Facebook (see chart).
Not in the focus of Exodus are other proprietary components of apps. Proprietary in this context means: the source code is not (publicly) visible. So who can say what these modules do in practice – other than what their manufacturers pitch to us? Not even the provider of the respective app can guarantee that everything is above board. How can they? So here the user must trust not only the provider of the app, but also those of the corresponding modules. „Timeo Danaos“: These modules are largely offered for free by advertising companies (first and foremost Google). Any second thoughts?
Ingredients: Where are they declared?
If you expect to find information about this in the Google Play Store, you will surely believe that the stork brings the children. Google would spoil its own advertising business – especially since the excessive use of such "anti-features" might scare off some users. Such transparency can only be found at F-Droid, where anti-features are clearly stated. However, the number of available apps is much smaller there (currently the catalog lists just over 3,300 apps).
At Appbrain, the libraries used in an app („good“ as well as „bad“) are often listed. However, separating the wheat from the chaff is left to the visitor. Although a rough subdivision is made into „Ad network libraries“, „Social libraries“ and „Development tools“ – tracking modules are not explicitly identified as such; for example, the Facebook SDK (one of the largest collectors for the group of the same name) would fall into the „Social libraries“ section, or Flurry (a rather encroaching analysis service) under „Development tools“; the visitor must therefore already know what is hidden behind which name.
The situation is better with Exodus Privacy: Only tracking modules are taken into account here. There is also sometimes quite extensive information on the respective modules. Apps that are not yet known to the service can be submitted for live analysis (and you can wait for the results showing up a few minutes later). The catch: Only freely available apps that are either available in the Google Play Store or at F-Droid can be analyzed. Paid apps or apps that are only available in certain countries from the Google Play Store or even APK files that you have downloaded from other sources are unfortunately not supported.
The MobilSicher AppCheck is particularly recommended in this context. It not only performs automatic analyses: Numerous apps were (and are) also critically dissected by experts – for example, for their background activities, which data is accessed and where it is transferred to, whether storage and transfer are encrypted, and more. Again, only apps from F-Droid or the Google Play Store are considered.
Library Scanner to the rescue!
There are various projects that have been dedicated to this topic: How do I analyze an APK file to find out what’s „inside“ it? The methodology for this was discussed in the aforementioned Exodus article. Other examples of software that you can also use on your own computer would be for example
- LibRadar (Python based; unfortunately, development seems to have stopped after 12/2018)
- radare2 (actively developed forensics toolkit)
- Apktool (Java, actively developed)
- Androguard (Python, actively developed; used e.g. by Exodus and F-Droid)
- android-classyshark (used as base by many tools and apps)
- numerous other tools listed at android-security-awesome
These tools allow you to reverse engineer an APK file and take a look at its components. If you also have a database with library specifications at hand, you can derive a lot from it. The example of Apktool will be used to briefly demonstrate this in the following.
Since Apktool comes as a
*.jar file, Java is required to use it. Furthermore we will use the command line:
# create a directory to work in and change into it mkdir test cd test # Download Apktool and get it ready for use wget https://github.com/iBotPeaches/Apktool/releases/download/v2.5.0/apktool_2.5.0.jar wget https://github.com/iBotPeaches/Apktool/raw/master/scripts/linux/apktool chmod u+x apktool ln -s apktool_2.5.0.jar apktool.jar
Done. Now any APK file can be copied there and „disassembled“ by typing
/apktool d myApp.apk. The result is a directory with the name of the APK file (only without the
.apk extension) – in this case
myApp. Among other things, this contains a directory called
smali - which can be used to determine the libraries used in the app. If an app uses Google Mobile Services, for example, there is a directory called
So the foundation is there - but manual analysis is not only tedious, but you also need to know the package names to be searched for. Library definitions that assign the respective paths to module names as well as further details to the module names – and a small wrapper script that largely automates the analysis - would help here.
Using Library Definitions
A suitable collection of library definitions as well as a suitable wrapper script can be found, for example, in the GitLab repo of IzzyOnDroid. The script itself requires a command-line version of PHP including the associated JSON package (Debian/Ubuntu/Mint:
apt install php-cli php-json), but can be transferred to other languages quite easily with a little programming knowledge.
To easily keep the library definitions up to date1 in the future, it is recommended to clone the repo:
# clone the repo git clone https://gitlab.com/IzzyOnDroid/repo.git # create a directory for Apktool and move the apktool* files there mkdir -p repo/lib/radar/tool mv test/apktool* repo/lib/radar/tool # create an alias for ease of use alias scanapk=$(pwd)/repo/bin/scanapk.php
That’s it – now APK files can be analyzed automatically:
$ scanapk com.bhandari.music_190.apk Libraries detected: ------------------- * Android Design Support Library (/android/support/design): Utility * Android Support v4 (/android/support/v4): Development Framework * Android Support v7 (/android/support/v7): Development Framework * Androidx Core (/androidx/core): Utility * Media (/androidx/media): Utility * Butter Knife (/butterknife): Utility * Material Dialogs (/com/afollestad/materialdialogs): UI Component * Glide (/com/bumptech/glide): Utility * Google Ads (/com/google/ads): Advertisement Ads * FlexboxLayout (/com/google/android/flexbox): Utility * Google Mobile Services (/com/google/android/gms): Development Framework NonFreeDep * Firebase (/com/google/firebase): Utility NonFreeNet,NonFreeDep * Firebase Analytics (/com/google/firebase/analytics): Mobile Analytics Tracking * Google Gson (/com/google/gson): Utility * SnappySmoothScroller (/com/nshmura/snappysmoothscroller): UI Component * ShineButton (/com/sackcentury/shinebuttonlib): UI Component * RecyclerView-FastScroll (/com/simplecityapps/recyclerview_fastscroll): UI Component * Android Sliding Up Panel (/com/sothree/slidinguppanel): UI Component * OkHttp (/com/squareup/okhttp): Utility * Android Image Cropper (/com/theartofdev/edmodo/cropper): Utility * AVLoadingIndicatorView (/com/wang/avi): UI Component * MaterialProgressBar (/me/zhanghai/android/materialprogressbar): UI Component * jsoup (/org/jsoup): Utility * Calligraphy (/uk/co/chrisjenx/calligraphy): Utility Offending libs: --------------- * Google Ads (/com/google/ads): Ads * Google Mobile Services (/com/google/android/gms): NonFreeDep * Firebase (/com/google/firebase): NonFreeNet,NonFreeDep * Firebase Analytics (/com/google/firebase/analytics): Tracking 4 offenders.
As can be seen from the example, all identified libraries/modules are listed – and those known to be critical are summarized again at the end. For the latter, the associated anti-features are also listed, whose meaning can be looked up for example at F-Droid. Slightly different from the description there, however,
NonFreeDep here means that the corresponding module itself is "non-free" – as can be seen in the example of Google Mobile Services as well as Firebase.
By the way, details about the tracked down modules can be found in the file
lib/libinfo.txt if you search there for
"id":"<packageName>" (so e.g.
"id":"/com/google/firebase"): a short description, as well as a link to the respective project. And if this sounds familiar to you: Exactly, this is used in the F-Droid Repo by IzzyOnDroid.
in the aforementioned Git repo, they are regularly supplemented with new entries and also corrected if necessary; this happens about once or twice a month. ↩︎