Reverse engineering a fraudulent mobile app

Last week on the blog, we walked through the reasons for Google’s new Play Referrer API. The API will provide additional data that gives us what we need to fight click injections, and we’re thrilled about that.

We dug a little deeper and conducted an investigation into an app that we suspected was bypassing the default method of click injections. We hypothesized that the app in question was sniffing out the Google Play Store downloads ‘repository’ (called the ‘Content Provider’ in Android terminology) to run clicks in the background even before the app finishes its installation.

This is a new approach to click injections. In the past, a more straightforward approach was to listen for any newly installed apps, wait for a new app to be installed, and then run clicks. It was the most straightforward method  because Android provided an out-of-the-box way for an app to know if a new app was  installed in the system (through the PACKAGE_ADDED broadcast). This way had a lot of flaws, mainly that the timestamp between a completed install and the beginning of the download was mismatched, which made it a very easy type of fraud to detect.

In this article, we’re analyzing how a fraudulent app  listened for  newly-installed downloads before the app completed its installation. Until now, this has been a more effective method of committing mobile ad fraud, as  detecting timestamp differences was not possible since the difference would be minuscule.

Environment and Methodology

The methods we used for this experiment were:

• Static code analysis with two different decompilers
• The attachment of an active debugger during interaction with the Google Play Store

The following scenarios were tested on an unrooted OnePlus One device. I used two decompilers to verify results and findings. For privacy reasons, we will not disclose the app’s name.  Hereafter we will call it AppZ. One noteworthy fact that we can share is that AppZ currently has over 500 million downloads.

Below is my attempt to make assumptions based on what I found. The codebase is over 100 classes long (which is considered to be very, very long) and the de-obfuscator could not extract most method names. Because the codebase is unreadable, these findings are not concrete and the assumptions I make below are assumptions. Please keep that in mind as you read on.

After running a traffic analyzer, it appears that calls to multiple APIs fire immediately after a package installs successfully. This means that the app is making some connections under the table with an unknown server without informing the user at all. The logic for AppZ is also selective: some apps would fire to different networks. Below is a screenshot from a Charles Proxy that shows the sequence of calls after a successful install for Subway Surfers, followed by one for the gaming app Gems & Genies:

Source

https://www.adjust.com/blog/reverse-engineering-a-fraudulent-app/