How I fought adware on google play and lost

Over the past day, hundreds of news sites ( clack and tyts ) reprint one interesting news telling about the detection of the next malicious applications on Google Play. This time adware showed annoying ads every time the device was unblocked and billions of phones and tablets were installed on billions . Fortunately, the anti-virus company Avast detected the threat in time and the applications were removed.

Under the cut, I will tell my version of events: how I calculated and searched for adware on Google Play, decompiled adware sdk code, can I wait for a response from Google support, why mobile antiviruses are useless and how they manage to make a good free adware on the hot information desk.

"Your Android version is out of date"

One evening my more humanitarian and wonderful half came to me in the question - why she cannot install the update on the phone, although the phone is constantly asking for it. A browser tab was opened on the screen with a tempting suggestion to install this update. When closing the tab, it turned out that more than 80 of these pages were open in the browser. After a brief interrogation, it turned out that no suspicious applications were installed on the phone, in fact, in the settings, the ability to install from third-party sources was even disabled. As it turned out, every time the phone was unlocked, a link with an advertisement or an AdMob banner banner on top of the launcher was opened in the browser.
')


The story became interesting as the application came clearly from Google Play. Taking the phone in one hand and LogCat in the other, I began to find out who launches this advertisement.

// TODO: Disable logging in the release

The hero of the occasion was installed very quickly - as it turned out, the developers did not care at all about disabling logging in the release version. Each time when locking or unlocking the screen, LogCat received detailed information about the result of the request to the server for advertising and other debugging data. It looked like this:

Intent started the process with PID 3020. It only remained to find out which package owns this PID. The team “ps | grep 3020 " , made in adb shell. I received the answer unequivocal:

It turned out that behind this was the World History app. The application has more than 5 thousand installations. And it was installed from Google Play for a long time, but advertising began to crumble recently. After removing the application, advertising certainly ceased to call the eyes.
Well, it was not difficult, but you can not just leave it. It's time to dissect the APK and get inside the code.

"Scalpel, clamp ..."

As for the tools, I will not tell you anything new - I used dex2jar to get the code in jar, apktool to decompile xml resources (and he also knows how to smali, but that's another story) and Luyten to decompile jar. The latter, by the way, is highly recommended - Luyten is just a GUI for Procyon , which in turn is very cool. At least, compared to JD, which I used before, I liked Procyon more.

Habrovchane familiar with the development under Android, have already realized that the application clearly registers a broadcast receiver to the events android.intent.action.SCREEN_OFF and android.intent.action.SCREEN_ON to display such tricky advertising. You can subscribe to these actions only from the code, so there’s nothing interesting in the manifest. But still, let's take a look and go there (not for nothing, it was decompiled, in the end) - there were some interesting components in the manifesto. One of the broadcast receivers has been subscribed to android.intent.action.BOOT_COMPLETED . It was called mobi.dash.overapp.DisplayCheckRebootReceiver - with it I started to study the code:

As you can see from the code, after the first reboot, the AdsOverappRunner.ping method will be called . The specified method loads the settings from the ads_settings.json file, which is located in the resources in the raw folder, and starts the wait. And how long this waiting will last is indicated in the file ads_settings.json. Then everything is extremely simple - from this moment, through the AlarmManager with a frequency of 15 minutes, the application will pull all the same DisplayCheckRebootReceiver and check whether the incubation period has come out. After the wait is over, mobi.dash.overapp.DisplayCheckService will be launched, which will already delight the user with advertising.

In principle, so far nothing unusual, if it were not for one fact - all this was not the work of the author of the application, but was clearly a third-party SDK. And even without any further analysis, it already inspired confidence, in the mobi.dash package there were about 200 classes.

Each time the screen was locked, the SDK made a request to the server and received in the response an advertisement that should be shown. At the same time, different types of advertising were supported:

On a command from the server, the SDK could show a dialog with the specified texts, open links in a browser, show ads for AdMob, Mopub or Chartboost, throw notifications.

In addition, inside there was a more interesting functionality - the SDK was able to change the dns server in the wi-fi connection settings:

Most likely, this was done in order to redirect users to the necessary advertising sites.
Also, the SDK could create fake desktop shortcuts that led the user through the links that came from the server. Well, perhaps the last interesting functionality - the ability to change the home page in the browser. The code responsible for this turned out to be the only protected place in the SDK - everything else, how can be replaced, was not even obfuscated. Browsers are different, so the SDK uses three different methods. At the same time, the names of the intents or the URIs of the paths in the content resolver, which were used to change the home page, were encrypted with a crypto-resistant XOR encryption algorithm and initially looked like an array of bytes:

After a simple operation, it turned into plain text:

And then rushed to the broadcast with such an action and extra-parameter. It's likely that on LG phones this really changes the home page. Most likely this is done to protect against antivirus scanning. At least virustotal confidently stated that the application is absolutely safe.

Their name is legion

Since the SDK looked very good, it was unlikely that it was written only to integrate it into an application with 5 thousand installations. First of all, I checked the rest of the applications of the same author. As it turned out, in each of them was built advertising mobi.dash. And the author had a lot of applications:



Of course, basically they had very few installations, but one of them had over 50 thousand installations. But of course, this publisher should not be limited to a single publisher. Since the SDK went for advertising on the ad1.mads.bz server , I decided to look for someone else who had this problem. It turned out that on w3bsit3-dns.com there is a whole topic , where users are fighting with such an advertisement. There I found references to two more applications that pulled ads from ad1.mads.bz. These applications have turned out to be much more popular:



More than 5 million and more than 1 million installations - a good audience reach. The card game "Fool" with such a number of installations should have tens of thousands of active users daily. The reviews had a lot of negative comments about the fact that the game shows ads, but antiviruses do not determine anything. This was rather strange, given the antiviruses swear even on the AirPush SDK, the ads that are clearly less annoying. By the way, the first mention that I found was mobi.dash sdk is dated October 1, 2013 . Probably after a year and a half and hundreds of user complaints, should someone take action? What else can a regular user do (hardresset, of course) if such an advertisement has settled in him, if not to look for help from mobile antiviruses. I checked three mobile antiviruses: Avast Mobile Security, Dr. Web and Kaspersky Internet Security. The opinion was unanimous:



Someone thought my phone was all right. Perhaps it was necessary to do something with it.

"Enough tolerating this!"

By this time, I already had extensive information about the capabilities of the SDK, and what applications it carries in itself. So the first thing I decided to do was report it on Google. Under each application on Google Play there is a link “Flag as inappropriate” (it was there, by the way, not always and appeared only in the summer of 2014), by clicking on which everyone can report a violation. Google takes these complaints so seriously that it even draws cartoons about how serious it is about it. Having passed not the easiest way from the Flag as inappropriate link to the field for entering the text of my complaint, I briefly stated the whole point. A minute later, a reply came to me from the bot who asked me to describe in more detail what kind of rules the application violated and attach additional materials (screenshots, etc.) that would help them. In response, I issued a long and detailed letter in which I explained that 4 rules from the Google Play Content Policy had been violated:

For complete understanding, I even recorded a video to show how this ad looks like:

I described in detail my research on the advertising SDK and its capabilities, as well as provided a list of applications. I wrote detailed instructions on how to quickly achieve advertising by simply translating the date. The letter left me on January 22.
I think that no one will be surprised that I have not received any answer to him and have not achieved any result from Google. Unfortunately, in Google, Mr. Box deals with handling complaints from users and they are deposited in the far box.

Antivirus

Nevertheless, even if the applications remain in Google (and there are 140 of them, by the way), it would be nice if the antiviruses somehow warned the SDK about this. I created threads on the Avast, Dr. Web and Kaspersky, in which he pointed out that antiviruses do not react to such advertising in any way and it would be nice to add it to the databases. While it is extremely simple to do this - because in the manifest of such applications, the components mobi.dash are declared . On the forum, Kaspersky responded very quickly, promised to sort it out and even donated a one-year subscription. Moderator on the forum Dr. Web suggested that I send the file for analysis to an antivirus lab. Avast responded 3 days later and promised to sort it out. I no longer had any activity on the forum topics.


Today, 10 days after my forum posts, suddenly, comments began to appear under the video with a demonstration of advertising. This was somewhat strange, considering that the video was private. Even more strange was the fact that the video had 10 thousand views (and at the moment it has already exceeded 20 thousand). It turned out that Avast posted an application article on the blog with this ad SDK. There was nothing new, except for what I wrote, in this article, unless an advertisement was added for the premium version of Avast antivirus, which already defines this advertisement. Apparently, the story turned out to be interesting and press releases hit the mark. Somehow it happened that after I posted links to applications and SDK analysis on the forum, the news about how Avast and analyst Filip Chytry discovered malicious applications on Google Play hit many large information resources. And here the company Avast and analyst Philip Kitry, it would seem.

Six hours after posting to the blog, all the applications I mentioned were removed from Google Play:

Google spokeswoman speaks about three hours after this post went live.

Happy end

Let my fight against adware specifically end in nothing - my complaint was ignored by Google and Avast turned out to be the saviors, but still the result was achieved. True, I have a very mediocre attitude to this result - it turned out to be impossible to reach Google, and antivirus vendors are not very interested in improving mobile products, if they did not pay attention to such a problem in 1.5 years. Nevertheless, I want to believe that for many users the results of this story will make life a little easier in the future.